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

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

        2019-09-03 13:58:31   作者: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服務器端。在呼叫環境中,涉及了各種環境場景和控制流程,具體細節和各種錄音場景我們在第四章節中做具體說明。
          劇透時間:可能是東半球網關銷售量最大的廠家即將震撼發布一系列融合通信產品,完成融合通信產品生態鏈部局。
          www.dinstar.cn
          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發送請求來啟動一個錄音會話,它需要執行以下幾個流程:
        1. SRS查詢SRC URL地址,通過地址解析后獲取SRC地址。
        2. SRS對SRC發送INVITE請求。
        3. 在SRS發送的INVITE中包括一個媒體錄音指示,表示要創建一個錄音會話來進行媒體錄音。
        4. 確認會話數據內容。在實際環境中,確認消息取決于SRC的策略設置。
        5. 如果馬上要發送復制媒體時,在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個應用場景,每一種場景都包含了具體的描述。
        1. 全時錄音:對RS對一個CS(參考以下示例),系統對所有呼叫進行錄音,典型的應用場景包括呼叫中心,企業客服和金融呼叫流程等。
        2. 選擇性錄音:當CS錄音創建后,啟動RS錄音。如果CS沒有啟動,系統不會錄音。
        3. 停止啟動錄音:當呼叫在CS期間時,可以啟動停止RS錄音。系統可以通過用戶界面按鈕或者其他熱鍵啟動錄音。這里注意,在CS期間,可能會生成一個或者多個RS錄音。
        4. 持續錄音:一個RS可以捕捉一個或多個CS錄音。此錄音方式通常應用于某些場景中,例如前臺總機,轉每個特定的分機號碼或者呼叫。整個RS需要對多個環節中的終端錄音,包括了轉接時的靜音等。最后,這些錄音的metadata可以關聯在一起,錄音文件可以合并。這里可能涉及了編碼協商的流程。
          
          5.實時錄音控制:在RS錄音期間,如果有特別業務要求,某些個人隱私或者安全信息不能錄音時,實時錄音控制方式可以停止對某一段時間內的錄音暫停/關閉,需要時重新開啟。信用卡信息輸入就是一個比較常見的例子,如果用戶需要對系統服務人員報信用卡或者其他身份信息時就要暫停錄音。
          6.IVR入口錄音:對系統IVR進行錄音,包括其metadata等。
          7.企業移動端錄音:系統對企業辦公人員進行錄音。這些員工可能經常不在辦公室環境中上班,他們經常使用移動端和企業呼叫中心或者通信系統進行溝通,這些員工的呼叫需要被錄音。比較常見的場景包括銷售人員,保險銷售等。
          8.分布式錄音或集中式錄音:一些企業,銀行,連鎖機構等辦公系統的電話呼叫需要通過部署在不同地區或者集中管理的電話系統進行呼叫。系統需要對呼叫進行錄音,并且對其每個RS的metadata進行存儲。這樣方便管理每一個呼叫和其相關人分機。
          9.復雜呼叫流程:復雜呼叫流程是一個比較抽象的說法,沒有特別具體的定義,此場景比較靈活,寬泛。簡單來說,一個呼叫進入到系統用戶,客戶電話可能首先被前臺人員接聽,然后轉到具體的坐席人員。如果坐席人員不能回答客戶問題的話,坐席人員可能需要再呼叫坐席主管,主管來接聽客戶的電話。坐席人員在此呼叫流程中需要首先執行呼叫?,然后再呼叫他/她的主管,主管接聽客戶電話以后,坐席掛機。整個流程稱之為復雜呼叫流程,所有的呼叫都需要錄音,并且SRC需要對SRS發送所有的metadata數據。
          10.高可靠性和持續錄音:根據用戶的需求,此應用場景需要SRS服務器端一直保持工作狀態,失效還原功能。所有創建的呼叫都能錄音。此場景要求SRS服務器端必須持續工作,無呼叫錄音服務丟失。
          11.對通道和多會話錄音:一些應用場景要求媒體錄音是一個或者多個文件,可以實現同步存儲或者回放等功能。語音識別引擎可以對其明顯特定的媒體執行ASR/TTS處理。一些多渠道融合的呼叫中心或者IPPBX環境中可能需要對視頻,IM,其他數據文件進行存儲。為了節省存儲空間,一些應用場景中可能需要僅多某些終端在某個特定時間段進行錄音。
          12.實時媒體處理:此場景在當前的呼叫中心或客服系統中實時質檢環境中使用比較廣泛。SRS服務器端必須有能力支持語音識別引擎工具,這些偵查工具可以對某一段媒體進行ASR和以及相關語義識別,情緒分析等工具處理,如果發現其錄音中帶有比較敏感的詞,或者客服人員態度語氣有問題,應用系統的主管人員可以及時處理。通過SIPREC的metadata可以非常方便快捷地查詢到客服人員的電話座席。以下示例是寧衛開發的基于ASR的實時質系統。系統用戶可以根據自己的業務需求添加一些敏感詞。如果客服人員和客戶之間的溝通有危險詞匯或者不禮貌用語,系統直接提示其狀態(紅色標識)。此對話過程可通過短信,郵箱或者其他第三方接口實時推送給坐席主管現在的狀態告警。

          當然,實現以上基于SIPREC錄音解決方案的話,此規范有31個要求。筆者這里不立場31個具體的要求,讀者可以查閱RFC6341。
          另外,除了31個要求以外,此規范討論了關于錄音存儲和metadata的安全問題,讀者也可以查閱RFC6341來進一步學習。
          5、SIP錄音時的metadata
          SIP錄音時的metadata涉及到了錄音會話的相關參數的綁定。這些數據通過SRC發送到SRS服務器端。RFC7865主要針對通信會話的錄音文件進行了規范,其核心包括SRS服務器端的metadata數據模式和數據錄音格式規范描述。在RFC7865中涵蓋了幾個主要的定義,它們分別是:
        • Metedata model:以UML為基礎的抽象metadata表達方式
        • Metedada class:模式中的每一塊為一個class
        • Attributes:class的屬性
        • Linkages:模式中每個class之間的相關性,每個linkage表示class之間的一個邏輯相關性
          以下示例表示了各種class自己的相互關系和其相關性,讀者可以查閱RFC7865進一步了解這個數據模式。另外,讀者也可以學習UML或者軟件工程相關的文章了解UML背景知識。
          在metadata的數據格式方面,涉及了從SRC到SRS的發送格式。通過XML的格式來表示metadata的內容。
          錄音文件的metadata有分為不同的class。每個class有著自己不同的屬性參數設置和相關性設置。這些class包括:
        1. Recording session:錄音會話類別,在XML中使用“recording”,它依賴于SIP和SDP所關聯的屬性。
        2. Commnucation session group: 關聯一組通信會話,例如坐席通過幾次電話轉接?恳院蟮囊幌盗邢嚓P呼叫。它在XML中使用“group”表示。
        3. Commnucation session:通信會話表示其通信屬性和metadata,其屬性包括:session_id,sipSession_ID, group-ref,start-time,stop-time。
        4. CS-RS Association :表示通信會話和錄音會話的關聯性,屬性包括關聯時間,斷開時間和session_id。
        5. Participant:錄音參與者進入到錄音會話的雙方,包括終端描述,Participant_id等。
        6. Participant-CS Association:參與者和通信會話的關聯性綁定關系。關聯性描述參與者和通信會話關聯時間,session_id,斷開時間等屬性。
        7. Media Stream:描述SRC發送到SRS服務器端的媒體屬性,包括label,stream_id和session_id等屬性設置。
        8. Participant-Stream Association:描述參與者和媒體之間的綁定關系和時間段,參與者可能是發送方,接收方或者兩者角色都支持。
        9. Syntax of XML Elements for Date and Time:定義XML文件中日期和時間段規范,包括關聯時間,斷開時間,啟動錄音時間,停止錄音時間等相關的時間規范。此時間標準需要遵從RFC3339的格式規范。時間戳必須使用一個大寫的T或者Z。
        10. Format of Unique ID:描述了生成UUID的步驟和解析規范。UUID解析必須遵從RFC4648。
        11. Metadata Version Indicator:version指示幫助SRC和SRS確認使用的XML文件版本是否一致。目前規定的是雙方都使用版本1。如果版本不一致的話,可能導致傳輸失敗,目前的規范中沒有支持任何的協商機制。
          因為本身metadata的數據結構比較復雜,另外,如果SRS處理大量數據的時候需要消耗很多的計算資源和帶寬。因此,SRS可以明確通知SRC發送一個關于錄音的metadata的概要或者部分相關內容,而不需要發送一個完整的XML文件。具體的語法格式如下:
        1. SRS internal error
        2.  
          完整的metadata格式包含了大量的XML數據,文件相對比較大,這里不再介紹,讀者可以查閱RFC7865-8的完整SIP 錄音metadata 示例。
          6、SIP會話錄音協議
          前面的討論中,筆者已經介紹了錄音技術架構,使用場景和metadata。在這一章節,我們重點介紹一下會話錄音協議-Session Recording Protocol。此協議主要規定了SR之間的實時媒體發送和metadata發生的邏輯流程,包括SIP使用, SDP使用和RTP的處理規范。再次說明,此協議僅支持active 錄音模式,不支持passive 錄音模式(鏡像錄音)。在此協議中,主要規范了幾個方面的處理流程:
          基本操作流程規定,SIP處理流程定義,SDP處理流程定義。RTP處理流程定義,metadata處理,持續錄音處理和安全處理機制處理。
          基本操作流程規定中介紹了關于傳輸媒體流,傳輸metadata,接收錄音指示和提供錄音優先設置。在傳輸媒體流的模式討論中,規范了兩種傳輸方式。一種傳輸方式是SRC以B2BUA的方式傳輸,一種是以SRC以endpoint的方式來傳輸。SRC以endpoint的模式傳輸媒體:
          以下是SRC以B2BUA的模式傳輸,電話會議就是此工作方式的表現形式。
          除了傳輸媒體流錄音以外,metadata也需要實時隨著媒體的發送傳輸到SRS服務器端。SRC負責傳輸metadata,SRC也可以通過起始的CS的INVITE請求提供初始媒體流錄音的metadata數據消息,后續的metadata可以通過媒體事件的UPDATE(查閱rfc3311)來傳遞,也可以通過SRC發送到re-INVITE發送。傳輸metadata通常是逐步遞增的,消息內容可能會不斷增加,文件也可能非常大。因此,SRC發可以根據自己的策略重新發送metadata。meatadata通過INVITE或者UPDATE的消息體來傳輸。一些媒體流的屬性需要通過RS的SDP傳輸。在SRC和SRS傳輸過程中,可能出現其他的故障,丟失了metedata。SRS可以通過一個失敗消息對SRC要求重新傳輸metadata,SRS和SRC可以保持數據的同步。以下是一個通過SIP UPDATE重新傳輸的流程實例:
          在CS傳輸過程中,SRC負責對所有的參與者提供錄音指示消息內容。一些支持錄音狀態意識到UA會收到一個SDP帶“a=record”消息,表示SRC開始發送錄音,同樣UA會在SDP中設定一個“a=recordpref”表示錄音的優先偏好設置。如果UA暫時因為各種原因不能錄音,則可忽略這個優先偏好設置。以下示例介紹了一個UA A作為SRC呼叫 終端B的流程,終端A呼叫并且開始錄音,UA B則看到對方錄音,UA B回復了一個off狀態,不想對呼叫進行錄音。最后,UA A重新發送消息,停止呼叫錄音。
          錄音會話中同樣涉及了SIP處理,它是一個SIP 會話的拓展,很多的消息會包含在SRS和SRC中。當SRC或者SRS收到一個SIP會話時,它不是錄音會話的話,處理流程完全取決于SRC或者SRS自己。SRC通過SIP INVITE請求對SRS發起一個錄音會話,無論是SRS還是SRC都是通過SIP的To或From頭來定義。SRC必須在Contact URL的功能標簽添加一個“+sip.src”來表示其拓展。在通過路由代理時,呼叫方可以添加一個標簽“siprec”表示錄音會話需要路由到SRC或者SRS服務器端。SRC收到一個新的INVITE呼叫時,它必須通過INVITE中的兩個功能標簽才能確認是一個錄音會話呼叫,一個是“+sip.srs”和“siprec”。同樣的原則,當SRS服務器端收到一個新的INVITE以后,它必須確認是否包含兩個標簽“+sip.src”和“siprec”才能確認是一個SRC發送到錄音請求。有意識錄音UA(recording-aware UA)可以通過標簽字段的形式支持是否錄音,重新啟動錄音或者暫停錄音。一些網關或者終端通過界面來實現對DTMF控制也是一種錄音方式。
          除了對會話的控制以外,媒體錄音也需要metadata傳輸等機制,因此需要涉及到SDP的控制處理策略。在SDP處理模式上,SRC/SRS都遵守SDP offer/answer模式,具體規范查閱(RFC3264),筆者也曾經做過介紹,讀者可對照學習。在SRC和SRS媒體發送過程中,SRC客戶端本身不希望從SRS服務器端收到媒體流數據,它僅是一個發送端,因此對SRC在SDP的設置中a字段設置為“a=sendonly”。SRC對每個發送到SRS服務器端的媒體錄音參與者必須都提供一個標識“a=label”,以此來確認每個媒體流的metadata。具體標識的規范讀者查閱RFC4574。以下示例是一個標識的示例,包括了具體的內容介紹,這里的 是可選的。
          媒體錄音也需要處理,因為各種原因,SRC可能增加或者刪除一些錄音會話。刪除增加會話需要根據RFC3264的規范來處理。RS暫停會話需要在SDP offer中增加一個a字段“a=inactive”。
          在通信會話中,目前的機制對通信會話錄音是播放一個語音提示音或者播放一個廣播,提醒需要UA需要錄音。在SDP中增加了一個“record”屬性參數。通過SDP的a字段“a=record”來處理各種環境的變化設置,其具體的語法如下:
          當SRC收到一個錄音優先級/偏好時,SRC通過設定a字段的屬性來控制是否錄音“a=record”,off或者on。
          前面我們討論的是SRC的SDP控制,在SRS端的處理流程其實也具有相同的處理流程和邏輯,可能有一些正好是一個相反的設置機制。SRS通常情況下只是從SRC端接收RTP流,因此其SDP的a字段設置為“a=recvonly”。示例如下:
          在SRS的SDP處理中,對有錄音意識UA,錄音指示和優先級/偏好設置和SRC基本類似,讀者可參考SRC配置說明,這里不再做過多介紹。
          RTP處理也是錄音會話協議中非常重要的一個部分。其規范推薦了RTP/RTCP在SIPREC中的使用機制,保證SRS,SRC和有錄音意識終端那個通過這些推薦的處理機制來正常工作。在RTP的處理機制中,推薦了RTCP在SIPREC的兩種功能(數據分發反饋處理機制,包括持續的傳輸層身份確認(SSRC)),RTP屬性支持能力,SSRC,CSRC,SDES,Keepalive等機制處理方式。這些處理方式保證了語音傳輸,加密,穩定性處理,活動偵測,帶寬優化,異步傳輸等處理機制,用戶在實際本身時可靈活調整其參數來達到最佳的RTP處理解決方案。
          SRC可以扮演多種角色,它可能是一個UA也可能是一個B2BUA代理。因此,在RTP的處理上就會導致不同的處理方式,也可以靈活運用在不同的錄音場景中。SRC可以作為一個RTP流的轉移功能模塊,實現直接轉發RTP,或者可以作為一個RTP媒體的編碼轉換模塊,它可以針對不同的媒體格式進行轉碼處理。SRC也可以作為一個媒體混音單元,讀者可查閱RFC3550對混音單元的規范做進一步學習。
          SRC也可以作為一個RTP的endpoint,這些我們在前面做過介紹,這里不再討論。
          在錄音會話中,metadata屬性參數包含在了SDP描述中,其他數據包含在了application/rs-metadata。"recording-session"值包含了SRS需要處理的metadata。在SRC的示例如下:
          SRS發送到UPDATE消息如下:
          在錄音會話時,規范做對持續錄音的場景做了一些規范推薦。在持續錄音時,關于SRC和SRS的處理機制可以按照前面的流程處理。一些特殊情況,可能需要用戶針對特殊環境做進一步處理,例如NAT環境中端口活動檢測,如果是支持ICE的終端可能可以解決這個問題,如果是不支持ICE的終端,用戶需要按照RFC6263來處理SRC和SRS的端口綁定。
          在錄音會話環境中,規范推薦了一些相關的安全問題的討論,比如,SRC/SRS必須都支持加密,必須考慮RTP加密,metadata的安全處理,用戶簽權認證處理和存儲空間回放文件的處理。這些機制都和其他的安全機制是一致的。用戶可以查閱其他協議的安全處理機制來執行。
          7、SBC對SIPREC的支持
          在前面的章節中,筆者介紹了SIPREC的使用背景,錄音協議,錄音流程,技術架構和metadata等比較底層的技術概念。在實際應用場景中,SBC對SIPREC支持是非常典型的應用案例。目前,國外一些主流的SBC廠家產品都已經支持了SIPREC(包括FreeSBC即將發布SIPREC高級功能),這樣就為SIP呼叫媒體錄音部署提供了可靠的技術環境。SBC支持SIPREC主要的應用場景包括:
          SBC企業本地部署支持SIPREC: 企業IPPBX或者呼叫中心和SBC/SRC連接,SRC通過SIPREC和SRS連接。錄音服務器可以通過終端以各種訪問形式進行訪問,運營商和SBC進行對接,然后呼叫到用戶終端。
          多租戶企業IPPBX錄音解決方案: 托管型的IPPBX或呼叫中心可以通過遠端終端呼叫SBC/SRC,然后通過SBC呼叫托管中心的PBX,IPPBX呼叫語音商線路出局。SRC同時對SRS發送RTP媒體流和metadata數據。
          高可靠性SIPREC錄音解決方案:SIPREC同樣規范了高可靠性的處理方式,SRS必須實現媒體流存儲無丟失機制。所以,SRS可以通過主從處理的方式同步媒體流和metadata數據。
          同樣,SRS的負載也是非常重要的技術要素。一些SBC做了均衡負載的處理,例如奧科SBC支持了類似的功能:
          以上應用場景是比較典型的部署方式,SIPREC規范相對比較新,廠家仍然需要不斷更新支持一些SIPREC規范的高級功能。
          8、其他問題討論
          前面我們討論了關于SIPREC錄音的官方協議和應用場景。SIPREC相當于鏡像錄音來說,其部署方式更符合目前SIP大型應用環境,云平臺的處理方式。但是,因為SIPREC是基于其他規范基礎發展而來的,因此其他規范的使用限制了一些SRC/SRS工作環境。另外,一些終端產品還沒有支持SIPREC,只有大部分SBC產品支持了SIPREC,SRS服務器端的功能仍然處于發展階段,一些商業產品支持了基本的SIPREC功能,一些高級功能仍然受到了限制。大家比較關心的問題包括:
        • SRC客戶端發送到metadata文件大小影響傳輸結果和SRS的負載,SRC可能需要支持更多的傳輸策略來解決類似的問題。
        • SRC是否支持混音,如果SBC測來處理這些需求的話,會導致SBC負載非常高,直接影響SBC的性能。
        • SRS服務器端的高可靠性設置問題也是需要用戶面對的問題?赡芤恍⿵S家的SBC很好解決了此問題,但是需要真正實際驗證。
        • SRC是否很好支持了metadata的拓展支持決定了和SIP會話處理。如果很好支持很多拓展字段,可能會幫助SRS服務器端更加準確管理metedata和通信會話處理。另外,SIP會話的處理也需要終端和其他設備能夠很好配合,保證其具有良好的兼容性,從而保證metadata的準確性。
        •  
        •   
        • 隨著融合通信的發展,用戶溝通增加了更多媒體支持,包括IM消息,共享文件和視頻格式。如何更好處理這些文件和其metadata也是一個非常大的挑戰。
          9、總結
          在本文章中,筆者首先介紹了SIPREC的規范和其相關的細節;赟IP協議的媒體錄音應用已經非常廣泛,從銀行到企業客服,保險業務推廣,法律機構和政府要求都需要電話錄音。這些錄音文件需要和其具體的通信會話相關人員進行正確綁定才能符合真正的客戶要求。然后,筆者針對SIPREC和其他相關協議做了完整介紹,例如12個使用場景,錄音協議,metadata規范,呼叫流程規范。然后,筆者針對目前SRC使用最廣泛的SBC做了介紹,通過SBC的集成,企業客戶可以實現SIPREC錄音解決方案。最后,筆者討論了目前使用SIPREC可能面對的挑戰和一些相關問題,為讀者提供了相對比較完整的專業建議。當然,隨著技術的不斷發展,SIPREC的功能會更加完善,云平臺的使用越來越多,SBC部署的廣大,支持的終端也可能越來越多,SIPREC的需求也會逐漸增加。
          以上就是筆者針對基于SIP協議的媒體錄音規范和應用方面的概述。這里沒有過度討論各種錄音方式的特點。這些討論通常根據用戶的需求來決定,所以筆者認為沒有必要做過多討論。另外,關于SIPREC的場景討論也可能遺漏了其他方面的要素,望讀者諒解?傊,此文章已經基本涵蓋了基于SIP協議做媒體錄音的大部分內容和規范,也完整敘述了其相關規范所有的技術要點,對于讀者快速了解這些技術有著非常大的幫助。
          參考資料:
          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論壇對文中陳述、觀點判斷保持中立,不對所包含內容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。

        相關熱詞搜索: SIP協議 SIPREC

        上一篇:小議聯絡中心的AI發展方向-1

        下一篇:最后一頁

        專題

        CTI論壇會員企業

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