亚洲综合伊人,成人欧美一区二区三区视频不卡,欧美日韩在线高清,日韩国产午夜一区二区三区,大胆美女艺术,一级毛片毛片**毛片毛片,你瞅啥图片

您當前的位置是:  首頁 > 資訊 > 文章精選 >
 首頁 > 資訊 > 文章精選 >

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

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


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

專題

CTI論壇會員企業(yè)

民勤县| 法库县| 龙胜| 谢通门县| 炎陵县| 镶黄旗| 鹤岗市| 莒南县| 白沙| 济南市| 达拉特旗| 清河县| 北票市| 兴业县| 中阳县| 信宜市| 巧家县| 渝中区| 黎川县| 柘城县| 定日县| 延安市| 石门县| 台东市| 特克斯县| 宾阳县| 黔南| 梁平县| 平塘县| 武平县| 达拉特旗| 宜宾市| 迭部县| 凌源市| 加查县| 讷河市| 光泽县| 芒康县| 公主岭市| 枣阳市| 淮南市|