很多廠家對電話錄音解決方案的問題也非常頭疼，因為錄音不單單是一個電話錄音本身，還要涉及管理，安全，備份，存儲問題，媒體服務器負載等等相關的技術解決方案。
開源軟交換平臺OpenSIPS及時感覺到了用戶的痛點，在本身交換的能力上，對電話錄音和媒體處理做了處理調(diào)度，通過OpenSIPS加一個第三方開源錄音服務器實現(xiàn)對電話的錄音�，F(xiàn)在，我們通過官方文檔的安裝指導，首先解讀一下安裝配置的設置，然后分析一下關于此錄音解決方案和其他第三方解決方案，最后，我們介紹了關于SIPREC標準之間的沖突或容易引起歧義的地方。
關于SIPREC標準介紹
SIPREC是一個對SIP錄音標準的協(xié)議規(guī)范。它使用非干預的外部錄音服務器對媒體進行實時錄音，不影響真正的RTP語音流。根據(jù)RFC3245的定義，它主要的兩個核心模塊是：
Session Recording Server （SRS），它是一個SIP 錄音服務器，接收forked 過來SRC，存儲在SRS服務器。這里的SRS是OrecX-開源的錄音服務器。
Session Recording Client （SRC），它負責在SIP session 路徑上觸發(fā)錄音服務。這里的SRC就是OpenSIPS。
錄音實現(xiàn)架構
現(xiàn)在，讓我們看看如何通過OpenSIPS結合第三方開源錄音服務器實現(xiàn)錄音的實現(xiàn)原理。
在這個SIP開源錄音服務器的實現(xiàn)架構中：
- OpenSIPS工作方式是SRC，提供SIP呼叫的所需metadata，這些metadata 會保存到錄音服務器，以方便將來對錄音的文件的匹配和管理。
- Oreka對forked的呼叫進行錄音，執(zhí)行錄音服務。
- RTPProxy將會分拆RTP語音流量到錄音服務器。
根據(jù)以上的架構圖，我們可以看出，兩個SIP分機直接可以互相呼叫，現(xiàn)在本身終端沒有任何錄音功能支持。正常情況下，終端會發(fā)生SIP信令到OpenSIPS，然后RTPProxy負責創(chuàng)建一個媒體流。
在我們的案例中：
- 當發(fā)起一個呼叫以后，OpenSIPS需要通知SRS，并且對SRS啟動一個SIPREC會話，在SDP中提供雙方的metadata 描述，媒體消息描述。通過SDP描述，SRS決定是否對此呼叫啟動錄音。
- 如果需要錄音，則發(fā)送200 OK消息，消息中包含一個fork的消息，通知在什么地方分拆媒體流
- 當OpenSIPS收到消息以后，它通知RTPProxy把客戶端的RTP語音流分拆給SRS服務器，對分拆出來的語音進行錄音。
- 當通話結束后，OpenSIPS SIPREC結束會話，然后結束錄音。
配置方法
此案例不會列出如何安裝OpenSIPS，如何安裝RTPProxy和Oreka，請用戶按照文檔的提示什么自行安裝。
這里需要說明的是，根據(jù)RFC7245的規(guī)定，B2BUA可以支持SRC，終端也可以實現(xiàn)SRC，但是SIP Proxy不能實現(xiàn)SRC，因為它不能訪問媒體流。因此，這里的OpenSIPs需要加載b2b模塊。
以下流程圖解釋了B2BUA如何配合SRS實現(xiàn)錄音的過程。終端錄音的實現(xiàn)方式有所不同，我們這里不做討論。
為了實現(xiàn)OpenSIPS對呼叫進行錄音的調(diào)度，用戶必須首先加載所需的模塊，這些模塊包括：
loadmodule "dialog.so" // 對會話確認
loadmodule "b2b_entities.so" // 設置為B2B模式支持，管理SIPREC Session。
loadmodule "siprec.so" // 設置SIPREC模塊
loadmodule "rtpproxy.so"// 設置RTP引擎模塊
其次，確認對接RTP 引擎的接口：
modparam（"rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7899"）
最后修改INVITE消息檢測，執(zhí)行INVITE的以后的流程處理。這里，假設所有用戶錄音。
# account only INVITEs
if （is_method（"INVITE"）） { // 如果是INVITE
create_dialog（）; // 創(chuàng)建dialog來管理呼叫。
rtpproxy_engage（）;// 啟動RTP引擎，創(chuàng)建語音流
siprec_start_recording（"sip:127.0.0.1:5090"）; // 啟動SIPREC 錄音
do_accounting（"log"）;// 記錄log日志。
}
這里我們僅列出需要關注的配置選項部分，因為OpenSIPS的配置文件比較長，不宜與在這里全部展現(xiàn)，請讀者訪問參考資料的鏈接獲取。
高級配置
高級配置選項里面可以支持幾個選項的配置：
修改UDP傳輸支持TCP傳輸。一般情況下，如果使用RTP傳輸還能承受數(shù)據(jù)的負載，實現(xiàn)輕量級的傳輸。如果通過SIPREC添加比較大的數(shù)據(jù) payload，或者metadata XML數(shù)據(jù)，則可能超過最大傳輸單元MTU的限制（不能大于1500字節(jié)），這樣可能導致數(shù)據(jù)丟失或者數(shù)據(jù)受損。關于使用UCP還是TCP的傳輸方式，我們在以前的討論中也做過介紹。以下圖例是SIP消息中的xml數(shù)據(jù)。
以上這些數(shù)據(jù)都會加大數(shù)據(jù)流量。對于UDP傳輸則可能出現(xiàn)很多問題，TCP傳輸則避免了類似的問題。為了解決這個問題，用戶可以通過修改傳輸方式來支持TCP傳輸而不使用UDP傳輸。
當然，用戶首先需要加載TCP模塊：
loadmodule "proto_tcp.so"
然后監(jiān)聽TCP端口，最后配置模塊參數(shù)。
listen = tcp:127.0.0.1:5060
最后，修改SRC URL：
siprec_start_recording（"sip:127.0.0.1:5090;transport=tcp"）;
第二種配置選項就是修改特別指定接口和SRS進行通信，強制使用此接口。
force_send_socket（tcp:127.0.0.1:5060）;
siprec_start_recording（"sip:127.0.0.1:5060;transport=tcp"）;
force_send_socket（udp:127.0.0.1:5060）; #這里必須強制發(fā)送 restore the initial interface
第三種高級設置是支持對指定用戶組進行錄音。通常來說，RTP引擎一般對所有用戶進行錄音，如果用戶需要對某些特定組進行錄音時，可以使用以下設置方式，通過可信任的SDP中的IP地址進行分組管理：
rtpproxy_offer（,,"5"）;
siprec_start_recording（"sip:127.0.0.1:5060;transport=tcp",,,,"5"）;
注意，這里的組都是5。
第四種高級設置，修改呼叫參與方的metadata支持更多業(yè)務需求。在默認配置中，OpenSIPS僅支持from頭和to頭。在實際應用環(huán)境中，用戶可能還需要收到的DID號碼，用戶別名等消息。用戶可以開啟另外兩個傳輸支持傳輸其他的metadata內(nèi)容：
$var（caller） = "\"John Doe\" <sip:john@opensips.org>\r\n";
$var（callee） = "\"Jane Doe\" <sip:jane@opensips.org>\r\n";
siprec_start_recording（"sip:127.0.0.1:5060;transport=tcp",, "$var（caller）", "$var（callee）"）;
通過參數(shù)3和參數(shù)4支持了呼叫方和被呼叫方的號碼信息。此功能也支持呼叫分組的功能，根據(jù)rfc7865的定義添加一個標簽（第二個參數(shù)）：
siprec_start_recording（"sip:127.0.0.1:5060;transport=tcp", "regular", "$var（caller）", "$var（callee）"）;
語法規(guī)則：
- srs - a comma-separated list of SRS URIs. These URIs are used in the order specified. See siprec_srs_failover for more information.
- group （optional） - an opaque values used by the SIPREC protocol to group calls in certain profiles.
- caller （optional） - a nameaddr header containing information about the caller. If absent, the From header is used.
- callee （optional） - a nameaddr header containing information about the callee. If absent, the To header is used.
- rtpproxy_set （optional） - the RTPProxy set used for this call. If absent, the default set provisioned in the rtpproxy module is used.
SRS 錄音服務器逃生設置
通信系統(tǒng)一般都是全天候工作，如果出現(xiàn)任何的故障都會導致整個通信系統(tǒng)或者公司日常業(yè)務不能正常工作。所以，部署一套可靠的系統(tǒng)支持逃生處理是非常重要的任務。SRC錄音可以支持多臺錄音服務器進行調(diào)度。使用方式如下：
siprec_start_recording（"sip:127.0.0.1:5060;transport=tcp, sip:127.0.0.1:5060"）;
這里假設第一臺錄音服務器使用的是TCP的傳輸方式，如果第一臺服務器不能正常工作，則自動啟動第二臺服務器，第二臺錄音服務器默認使用的是UDP傳輸方式。
這里需要大家注意，默認的錄音服務器之間的切換是通過SRS的協(xié)商響應來實現(xiàn)的。在實際生產(chǎn)環(huán)境中，用戶可以自定義其他的響應消息來實現(xiàn)響應的逃生處理。
在以上標注的紅色的逃生處理中，只有收到5xx或者6xx才執(zhí)行逃生。
SIPREC模塊更多討論
SIPERC是一個比較大的技術范疇，不僅僅局限于SRC或SRS，這里還要涉及安全問題，轉碼問題，和錄音控制等問題。SIPREC模塊局限性的問題，根據(jù)OpenSIPS官方的解釋，目前SIPREC模塊仍然存在兩個方面的局限性：
- 不支持對被呼叫方播放語音提示音。根據(jù)很多國家的相關法律規(guī)定，如果電話系統(tǒng)需要對用戶錄音時，必須首先對用戶播放錄音提示，否則，視為違法。所以在一般的商業(yè)環(huán)境中，如果需要對通話進行錄音時，系統(tǒng)必須提前對被呼叫方提示，例如，你的通話將被錄音等類似的提示。
- 不能支持由SRS 錄音服務器發(fā)起的錄音會話。如果錄音服務器突然在會話中途開啟錄音的話，這是不能支持的。此局限性和RFC 7245中的規(guī)定有差距。
根據(jù)RFC 7245的規(guī)定，SRC或SRS（May）可能可以支持錄音暫�；蛑貑ⅰ９P者在官方的模塊文檔和SRS Oreka錄音服務器中還沒有發(fā)現(xiàn)如何設置此功能。
根據(jù)RFC標準的規(guī)定，可以通過SRS錄音轉碼，Oreka滿足了這一要求。
SIPREC模塊的局限性中提到，它本身不能支持有SRS發(fā)起的錄音，但是在RFC 7245中規(guī)定了由SRS發(fā)起錄音的相關流程規(guī)定，所以這個功能有待于進一步提高。
SIPREC的模塊中，沒有提到關于關于安全方面的設置。根據(jù)RFC 7866的規(guī)定，應該支持TLS。同時，RFC7866規(guī)定，SRC和SRS應該同時支持同樣的安全策略。
關于認證和簽權的設置，在RFC7866中規(guī)定，SRC和SRS必須使用TLS，但是在內(nèi)網(wǎng)環(huán)境中，RFC7866則允許使用其他的認證策略。在這一點上，SIPREC模塊似乎可以滿足用戶的需求。
通過對OpenSIPS結合第三方開源錄音服務器Oreka的介紹，讀者可以了解了如何通過OpenSIPS，TTPProxy和Oreka的錄音功能，筆者在本討論中也探討了錄音環(huán)境下的一些參數(shù)優(yōu)化，最后討論了一些和RFC規(guī)定相關的技術要求�？傮w來說，這個方案可以基本滿足通過OpenSIPS對接第三方的錄音服務器的要求，但是更多對支持RFC的功能還要有待進一步的完善。
另外，除了我們正在討論的使用OpenSIPS加第三方錄音以外，基于其他開源的媒體服務器或者結合錄音服務器也可以實現(xiàn)電話錄音功能，但是不一定滿足SIPREC 標準，例如：
- Asterisk+Oreka方式，使用Asterisk作為媒體服務器，通過Oreka實現(xiàn)錄音服務器功能。
- FreeSWITCH+Oreka方式，使用FreeSWITCH作為媒體服務器，通過Oreka實現(xiàn)電話錄音功能。
- 直接通過抓包的方式來實現(xiàn)電話錄音的獲取，這樣的優(yōu)勢在于不涉及媒體服務器，部署簡單。筆者朋友也提供了類似的解決方案，用戶可以下載測試。
以上前兩種方式，都是通過一個Oreka模塊，通過IP地址和端口來監(jiān)聽語音流，然后添加需要的自定義的metadata實現(xiàn)對每個呼叫的號碼對應，通過是否混音來通知服務器混音處理。
關于SIPREC模塊的配置，OpenSIPS官方有非常詳細地的說明，筆者引用了部分的文檔內(nèi)容，結合RFC標準對此解決方案進行的探討，更多關于SIPREC的問題，請讀者參考以下鏈接。
參考鏈接：
https://tools.ietf.org/html/rfc7245
https://tools.ietf.org/html/rfc6341
https://tools.ietf.org/html/rfc7866
OpenSIPS錄音配置文件：http://opensips.org/pub/opensips-scripts/2017/opensips-siprec.cfg
http://oreka.sourceforge.net/
http://www.opensips.org/Documentation/Tutorials-SIPREC-2-4
錄音服務器ISO光盤下載：https://pan.baidu.com/s/1o7Ng66i
關注微信號：asterisk-cn 獲得更多行業(yè)技術信息，訪問技術論壇很多更多關于開源IPPBX的技術幫助：www.issabel.cn/forum
