<p id="l1pda"></p>
<track id="l1pda"></track>
      1. 您當前的位置是:  首頁 > 資訊 > 文章精選 >
         首頁 > 資訊 > 文章精選 >

        基于SIP協議的媒體錄音規范(SIPREC)完整技術概述-1

        2019-09-02 11:06:05   作者:james.zhu    來源:Asterisk開源派   評論:0  點擊:


          在當前的語音通信環境中,除了用戶非常重視呼叫的用戶體驗,同時對其他第三方的業務要求也有了新的要求。特別是在某些金融領域,法律咨詢領域和人力資源領域,雙方電話溝通需要有完整的通話錄音,這些錄音可能會幫助雙方對某些歧義進行進一步的佐證。但是,隨著呼叫中心,IPPBX部署方式的技術革命,很多呼叫中心,IPPBX已經實現了云部署的方式,以前傳統的錄音方式基本上很難滿足用戶的需求,市場份額也正在萎縮。在當前主流的部署方式中,使用SBC對接其他業務應用是大家正在逐步使用的主要的部署方式。關于SBC的背景介紹,我們在以前的文章中做過非常多的關于SBC以及其功能的介紹,筆者也發表過關于開源OpenSIPS電話錄音的分享。
        • 如何通過SBC實現公網注冊SIP話機演示,實現聯通COP對接通話
        • 圖解邊界會話控制器(SBC)的20個最常用功能
        • SIP系列講座-邊界會話控制器-SBC全面剖析
        • 基于OpenSIPS實現電話錄音解決方案探討
          為了進一步完善SIP呼叫錄音的討論,今天,筆者在以前的錄音分享技術討論的基礎上,進一步討論一些和SIP電話呼叫中的一些非常細節的說明和其相關的行業規范,通過規范和解決方案的示例討論,讀者獲得更多關于SIP呼叫錄音的技術策略和部署方式。
          更多技術分享,關注SIP技術學習
          筆者這里主要討論的內容包括:錄音解決方案背景介紹,關于SIPREC的技術細節說明(Session Recording Protocol),相關技術架構討論,基于SIP的媒體錄音場景規范(SIPREC)以及數據規范的討論,SBC對SIPREC的支持和以及其他問題討論。
          1、錄音解決方案背景介紹
          呼叫中心或IPPBX是幫助企業用戶和客戶主要溝通的工具。根據一家美國公司對市場的調查中,在最近幾年,語音仍然是企業用戶和客戶互動的首先方式。
          以下部分圖片來自于互聯網
          在呼叫中心或者語音使用比較高的行業中,服務行業是一個需求非常旺盛的行業,客服中心是非常關鍵的部門。為了保證其服務和其他業務那個在一種可控的環境下進行,雙方的錄音是最好的憑證。另外,語音呼叫結合電話錄音也是服務行業的一個必然的趨勢,以下是美國行業調查數據:
          資料來源:https://www.telemessage.com/voice-call-recording-latest-market-and-compliancetrends-infographic/
          當然,錄音也不僅僅局限于客服的一種需求,其他行業也存在巨大的市場。以下示例說明了各種環境下對錄音的需求:
          但是,隨著呼叫中心或客服中心技術的不斷發展,很多呼叫中心和客服中心的技術也發生了巨大的變化,從很早的本地部署方式逐漸升級為基于云的部署方式,客服或坐席人員也出現了分布式的部署方式。因此,隨著呼叫中心或客服中心技術和管理方式的變化導致了錄音解決方案的變化。我們知道,傳統的PSTN的錄音或者IP錄音是通過高阻三通方式或鏡像錄音實現呼叫錄音,但是,這些部署很難滿足對現代云部署技術的支撐,它們也滿足不了非常細節的業務功能。因此,傳統的錄音設備或者本地錄音方式面臨著很大的挑戰。
          隨著呼叫中心或客服系統朝云平臺的遷移,基于云平臺的錄音解決方案也逐漸形成了自己的市場。同時,錄音解決方案可以非常方便地和人工智能的接口實現無縫對接支持。因此,基于云的呼叫中心配合云錄音方案將更加普及。
          在基于云部署的呼叫中心的使用場景中,絕大部分的呼叫中心使用了基于SIP協議的解決方案。目前,基于SIP協議的技術架構中,基于SIP協議對媒體錄音的規范是SBC,軟交換,媒體服務器部署時需要支持的協議規范(SIPREC)。一些比較主流的SBC廠家,媒體服務器都已經支持了SIPREC-基于SIP的媒體錄音協議。這看來也是一個市場發展的必然趨勢。為了更快了解這些相關的技術和規范,在本文章中,筆者在接下來的章節中會逐步介紹SIPREC相關的技術規范,它們包括:
          RFC5341-基于SIP的媒體錄音使用場景規范:
          Use Cases and Requirements for SIP-Based Media Recording (SIPREC)
          RFC7245-SIP媒體錄音技術架構:
          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
          因為篇幅的關系,我們不可能在一篇文章中涵蓋所有的技術細節,除了簡略介紹以上規范以外,筆者還要結合目前主流的SBC應用場景和其他的問題進行多方面的討論來完善目前關于基于SIP媒體錄音解決方案的討論。
          2、SIPREC背景知識
          根據前面章節的介紹,因為某些商業環境的要求,系統可能需要對呼叫會話進行錄音。SIPREC是基于SIP協議對媒體錄音的場景規范(RFC6341)。其全名為:
          Use Cases and Requirements for SIP-Based Media Recording (SIPREC)
          在整個SIPREC的規范中,包括了SRC和SRS兩個核心部分。它們之間的通信會話包括了錄音內容本身和一些相關的metadata,通過錄音內容和metadata的關聯,系統就可以實現對SIP呼叫的媒體錄音的完成流程處理。因為對SIP呼叫的錄音,涉及了很多的業務模式和其他相關的技術,因此,其規范也相對比較寬泛,不可能嚴格限定到非常細節的技術范疇。讀者一定要清楚,一些其他業務要求和技術要素不在此官方的說明范圍之內。這些要素包括:
        • 關于法律強制錄音的規定流程不在此規范討論范圍之內
        • 關于媒體注入,編碼轉換,安全問題不在本規范討論范圍之內
        • 通過網絡鏡像方式錄音Passive 錄音方式不在本規范討論范圍之內
          此規范僅討論active 錄音方式,和如何通過SRC對SRS發送媒體流的處理場景。以下是一個關于SIPREC和SIP呼叫流程的圖例說明:
          在以上的圖例中,用戶端可以是SIP終端, 呼叫中心,或者IPPBX,通過一個B2BUA實現對外網呼叫。這里的SRC是SBC,SRC客戶端再發送通信會話包括SIPREC metadata和RTP到第三方的SIPREC服務器端。在呼叫環境中,涉及了各種環境場景和控制流程,具體細節和各種錄音場景我們在第四章節中做具體說明。
          3、技術架構討論-RFC7245
          在上面的章節中,我們介紹了關于SIPREC的一些背景知識和規范的局限性。SIPREC的工作方式是基于SIP媒體會話錄音的技術架構來實現的。因此,我們有必要針對媒體錄音技術架構進行討論包括。關于SIP媒體會話錄音的技術架構,RFC7245對此有明確的規范說明。在RFC7245中,官方協議中首先定義了多個關鍵詞,然后說明了技術架構中具體的結構,創建錄音會話和記錄metadata數據。
          在RFC7245中所規定的幾個關鍵詞包括:
        1. 支持錄音意識用戶代理- Recording-aware User Agent (UA):此UA可以意識到其拓展已經關聯到了通信會話(CS)。其拓展參數可以通知其UA錄音會話已啟動或表示其狀態,可以啟動,暫停和完全停止等消息。
        2. 無錄音意識用戶代理-Recording-unaware User Agent (UA):此UA意識不到其拓展已經關聯到了通信會話(CS)。無錄音意識代理將通過其他手段通知其UA錄音會話已啟動或表示其狀態,可以啟動,暫停和完全停止等消息。
        3. Recording Metadata:描述SRS服務器端需要的相關錄音身份確認數據,包括通信會話和dialog狀態信息等。一般情況下,這些metadata會和復制媒體錄音一起發送到SRS服務器端。
        4. Replicated Media:由SRC客戶端創建的媒體流復制數據流,發送到SRS服務器端。它可能包括語音和視頻數據。
          其他幾個概念在下面的章節中會加以說明,包括:Session Recording Server,Session Recording Client,Communication Session (CS)和Recording Session (RS)。
          對于介于SRS和SRC之間的錄音會話來說,它仍然借助了SIP dialogs和SDP的正常處理流程來進行處理。但是,它又對SIP拓展了其他的頭域值(例如,headers,tags等)來滿足媒體錄音的需求。在此規范中規定,復制的媒體數據需要通過實時方式發送到SRS服務器端,不能使用SRC緩存方式發送。
          從媒體錄音的技術架構來說,SRC是一個邏輯構件,它可以介于多個應用部署的環境中。它本身必須是一個B2BUA的結構,這樣SRC才能對RTP媒體,對SIP信令進行控制,最重要的是可以對會話進行管理。關于B2BUA的概念,讀者可以查閱筆者的歷史文檔來進一步學習,這里不再做過多解釋。另外,特別提醒讀者,SIP proxy不能作為SRC來工作,因為proxy不能touch到媒體語音流。這就是為什么opensips如果需要支持SIPREC時,opensips必須加載B2BUA模塊,作為一個B2BUA來使用。
          當然,SIP endpoints也可以作為一個SRC,這種情況下,終端會對SRS發送復制的媒體。如果終端需要對SRS服務器端發送錄音時,它可以發送一個INVITE請求,創建會話后發送,SRC對SRS發送媒體錄音。同樣,如果SRS需要啟動錄音時,它可以對SRC終端發送INVITE會話,然后開始錄音。
          錄音會話可以由SRS或者SRC創建。SRC創建的錄音會話的目的是對SRS發送媒體錄音流數據。如果有SRC創建錄音會話時,它主要執行以下幾個步驟:
        1. SRC查詢定位SRS的URL地址,按照解析方式來解析SRS地址。
        2. 發送INVITE請求,創建一個dialog,然后發送到SRS。
        3. 在INVITE請求中包括一個錄音指示,表示會話已經創建,希望發送媒體錄音。
        4. 如果馬上要發送復制媒體時,在SDP中包含一個“a=sendonly”,表示馬上發送媒體錄音。如果還沒有準備好發送媒體的話,包含一個“a=inactive”。
        5. 復制的媒體流被錄音然后發送到SRS服務器端。
          同樣,SRS也可以對SRC發送請求來啟動一個錄音會話,它需要執行以下幾個流程:
          SRS查詢SRC URL地址,通過地址解析后獲取SRC地址。
          SRS對SRC發送INVITE請求。
          在SRS發送的INVITE中包括一個媒體錄音指示,表示要創建一個錄音會話來進行媒體錄音。
          確認會話數據內容。在實際環境中,確認消息取決于SRC的策略設置。
          如果馬上要發送復制媒體時,在SDP中包含一個“a=sendonly”,表示馬上發送媒體錄音。如果還沒有準備好發送媒體的話,包含一個“a=inactive”。
          如果SRS服務器端不知道哪個媒體會話需要錄音的話,SRS服務器端可以執行一個協商機制,它可以先對SRC發送一個無實際意義的INVITE,然后SRC客戶端對其發送一個初始的offer。
          在媒體錄音進行過程中,SRS或者SRC任意一方可以暫;蛘咧匦聠愉浺。通過SDP中包含一個inactive來暫停錄音,或者通過SDP中包含“recvonly”或“sendonly”重新啟動錄音。
          通常情況下,在一個簡單的會話中,在SRC客戶端,RTP媒體流可能包含兩個媒體數據流。這些媒體流必須在發送到SRS服務器端之前進行混音。如果沒有混音的媒體發送到SRS時,需要同時分開發送兩個媒體流的metadata。
          在實際部署環境中,雙方媒體可能需要進行媒體轉換處理,B2BUA可以執行此功能。如果SRC端不能執行媒體轉換處理的話,它需要對SRS發送不同的媒體格式,SRS服務器端需要支持多種媒體格式。
          4、SIPREC使用場景討論
        • 在SIPREC的規范中,它說明了幾個基于SIP的錄音使用場景。這些場景都可以支持SIPREC規范RFC6341。在此規范中,一些必要的定義需要再次說明一下:
        • SRS-全稱是Session Recording Server,它是一個具體的媒體服務器或媒體采集服務器,是一個用戶代理,同時匯總各種媒體流的metadata。SRS典型的部署方式是一個多口可拓展的服務器類型。
        • SRC-全稱是Session Recording Client,它是一個SIP用戶代理,負責對服務器端發送媒體流數據,它本身是一個邏輯功能單元,可以支持多個物理設備,在實際應用環境中,SRC可以是SIP終端話機,媒體網關或者SBC。SRC同時對SRS服務器發送metadata。
        • Communication Session (CS),通信會話創建于一個SIP或者多個用戶代理之間的會話,是一個正在被錄音的會話對象。
        • Recording Session (RS):為通信會話(CS)錄音目的創建的介于SRS和SRC之間的SIP會話。
          關于SRS,SRC和CS直接的關系,讀者可查閱此示例:
          在RFC6341中說明了12個應用場景,每一種場景都包含了具體的描述。
        • 全時錄音:對RS對一個CS(參考以下示例),系統對所有呼叫進行錄音,典型的應用場景包括呼叫中心,企業客服和金融呼叫流程等。
        • 選擇性錄音:當CS錄音創建后,啟動RS錄音。如果CS沒有啟動,系統不會錄音。
        • 停止啟動錄音:當呼叫在CS期間時,可以啟動停止RS錄音。系統可以通過用戶界面按鈕或者其他熱鍵啟動錄音。這里注意,在CS期間,可能會生成一個或者多個RS錄音。
        • 持續錄音:一個RS可以捕捉一個或多個CS錄音。此錄音方式通常應用于某些場景中,例如前臺總機,轉每個特定的分機號碼或者呼叫。整個RS需要對多個環節中的終端錄音,包括了轉接時的靜音等。最后,這些錄音的metadata可以關聯在一起,錄音文件可以合并。這里可能涉及了編碼協商的流程。
        • 實時錄音控制:在RS錄音期間,如果有特別業務要求,某些個人隱私或者安全信息不能錄音時,實時錄音控制方式可以停止對某一段時間內的錄音暫停/關閉,需要時重新開啟。信用卡信息輸入就是一個比較常見的例子,如果用戶需要對系統服務人員報信用卡或者其他身份信息時就要暫停錄音。
        • IVR入口錄音:對系統IVR進行錄音,包括其metadata等。
        • 企業移動端錄音:系統對企業辦公人員進行錄音。這些員工可能經常不在辦公室環境中上班,他們經常使用移動端和企業呼叫中心或者通信系統進行溝通,這些員工的呼叫需要被錄音。比較常見的場景包括銷售人員,保險銷售等。
        • 分布式錄音或集中式錄音:一些企業,銀行,連鎖機構等辦公系統的電話呼叫需要通過部署在不同地區或者集中管理的電話系統進行呼叫。系統需要對呼叫進行錄音,并且對其每個RS的metadata進行存儲。這樣方便管理每一個呼叫和其相關人分機。
        • 復雜呼叫流程:復雜呼叫流程是一個比較抽象的說法,沒有特別具體的定義,此場景比較靈活,寬泛。簡單來說,一個呼叫進入到系統用戶,客戶電話可能首先被前臺人員接聽,然后轉到具體的坐席人員。如果坐席人員不能回答客戶問題的話,坐席人員可能需要再呼叫坐席主管,主管來接聽客戶的電話。坐席人員在此呼叫流程中需要首先執行呼叫?,然后再呼叫他/她的主管,主管接聽客戶電話以后,坐席掛機。整個流程稱之為復雜呼叫流程,所有的呼叫都需要錄音,并且SRC需要對SRS發送所有的metadata數據。
        • 高可靠性和持續錄音:根據用戶的需求,此應用場景需要SRS服務器端一直保持工作狀態,失效還原功能。所有創建的呼叫都能錄音。此場景要求SRS服務器端必須持續工作,無呼叫錄音服務丟失。
        • 對通道和多會話錄音:一些應用場景要求媒體錄音是一個或者多個文件,可以實現同步存儲或者回放等功能。語音識別引擎可以對其明顯特定的媒體執行ASR/TTS處理。一些多渠道融合的呼叫中心或者IPPBX環境中可能需要對視頻,IM,其他數據文件進行存儲。為了節省存儲空間,一些應用場景中可能需要僅多某些終端在某個特定時間段進行錄音。
        • 實時媒體處理:此場景在當前的呼叫中心或客服系統中實時質檢環境中使用比較廣泛。SRS服務器端必須有能力支持語音識別引擎工具,這些偵查工具可以對某一段媒體進行ASR和以及相關語義識別,情緒分析等工具處理,如果發現其錄音中帶有比較敏感的詞,或者客服人員態度語氣有問題,應用系統的主管人員可以及時處理。通過SIPREC的metadata可以非常方便快捷地查詢到客服人員的電話座席。
          當然,實現以上基于SIPREC錄音解決方案的話,此規范有31個要求。筆者這里不立場31個具體的要求,讀者可以查閱RFC6341。
          另外,除了31個要求以外,此規范討論了關于錄音存儲和metadata的安全問題,讀者也可以查閱RFC6341來進一步學習。
          戶簽權認證處理和存儲空間回放文件的處理。這些機制都和其他的安全機制是一致的。用戶可以查閱其他協議的安全處理機制來執行。
          參考資料:
          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@知識星球學習SIP語音相關技術
          asterisk@知識星球免費獲取關于Asterisk的完整知識資料
          關注微信公眾號:asterisk-cn,獲得有價值的Asterisk行業分享
          Asterisk freepbx,FreeSBC技術文檔: www.freepbx.org.cn
          融合通信商業解決方案,協同解決方案首選產品:www.hiastar.com
          Asterisk/FreePBX中國合作伙伴,官方qq技術分享群(3000人):589995817
        【免責聲明】本文僅代表作者本人觀點,與CTI論壇無關。CTI論壇對文中陳述、觀點判斷保持中立,不對所包含內容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。

        專題

        CTI論壇會員企業

        欧美性爱欧美
        <p id="l1pda"></p>
        <track id="l1pda"></track>