在當前的語音通信環境中，除了用戶非常重視呼叫的用戶體驗，同時對其他第三方的業務要求也有了新的要求。特別是在某些金融領域，法律諮詢領域和人力資源領域，雙方電話溝通需要有完整的通話錄音，這些錄音可能會幫助雙方對某些歧義進行進一步的佐證。但是，隨著呼叫中心，IPPBX部署方式的技術革命，很多呼叫中心，IPPBX已經實現了雲部署的方式，以前傳統的錄音方式基本上很難滿足用戶的需求，市場份額也正在萎縮。在當前主流的部署方式中，使用SBC對接其他業務應用是大家正在逐步使用的主要的部署方式。關於SBC的背景介紹，我們在以前的文章中做過非常多的關於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呼叫的錄音，涉及了很多的業務模式和其他相關的技術，因此，其規範也相對比較寬泛，不可能嚴格限定到非常細節的技術範疇。讀者一定要清楚，一些其他業務要求和技術要素不在此官方的說明範圍之內。這些要素包括：
此規範僅討論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中所規定的幾個關鍵詞包括：
其他幾個概念在下面的章節中會加以說明，包括：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創建錄音會話時，它主要執行以下幾個步驟：
同樣，SRS也可以對SRC發送請求來啟動一個錄音會話，它需要執行以下幾個流程：
如果SRS伺服器端不知道哪個媒體會話需要錄音的話，SRS伺服器端可以執行一個協商機制，它可以先對SRC發送一個無實際意義的INVITE，然後SRC客戶端對其發送一個初始的offer。
在媒體錄音進行過程中，SRS或者SRC任意一方可以暫停或者重新啟動錄音。通過SDP中包含一個inactive來暫停錄音，或者通過SDP中包含「recvonly」或「sendonly」重新啟動錄音。
通常情況下，在一個簡單的會話中，在SRC客戶端，RTP媒體流可能包含兩個媒體數據流。這些媒體流必須在發送到SRS伺服器端之前進行混音。如果沒有混音的媒體發送到SRS時，需要同時分開發送兩個媒體流的metadata。
在實際部署環境中，雙方媒體可能需要進行媒體轉換處理，B2BUA可以執行此功能。如果SRC端不能執行媒體轉換處理的話，它需要對SRS發送不同的媒體格式，SRS伺服器端需要支持多種媒體格式。
4、SIPREC使用場景討論
關於SRS，SRC和CS直接的關係，讀者可查閱此示例：
在RFC6341中說明了12個應用場景，每一種場景都包含了具體的描述。
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中涵蓋了幾個主要的定義，它們分別是：
以下示例表示了各種class自己的相互關係和其相關性，讀者可以查閱RFC7865進一步了解這個數據模式。另外，讀者也可以學習UML或者軟體工程相關的文章了解UML背景知識。
在metadata的數據格式方面，涉及了從SRC到SRS的發送格式。通過XML的格式來表示metadata的內容。
錄音文件的metadata有分為不同的class。每個class有著自己不同的屬性參數設置和相關性設置。這些class包括：
因為本身metadata的數據結構比較複雜，另外，如果SRS處理大量數據的時候需要消耗很多的計算資源和帶寬。因此，SRS可以明確通知SRC發送一個關於錄音的metadata的概要或者部分相關內容，而不需要發送一個完整的XML文件。具體的語法格式如下：
完整的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功能，一些高級功能仍然受到了限制。大家比較關心的問題包括：
9、總結
在本文章中，筆者首先介紹了SIPREC的規範和其相關的細節。基於SIP協議的媒體錄音應用已經非常廣泛，從銀行到企業客服，保險業務推廣，法律機構和政府要求都需要電話錄音。這些錄音文件需要和其具體的通信會話相關人員進行正確綁定才能符合真正的客戶要求。然後，筆者針對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