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