一種寬帶集群系統(tǒng)錄音服務器會話數(shù)據(jù)的存儲策略

竇春斌，肖志輝，陳一山

（1.西南交通大學信息科學與技術學院 成都610031；2.邁普通信技術股份有限公司 成都610041）

1 引言

集群系統(tǒng)是為了滿足行業(yè)指揮調(diào)度的需求而開發(fā)的、面向多種行業(yè)應用的專用無線通信系統(tǒng)，經(jīng)歷了從模擬、數(shù)字到數(shù)字集群加寬帶接入系統(tǒng)的歷程。隨著無線高速數(shù)據(jù)業(yè)務的飛速發(fā)展，集群系統(tǒng)將向數(shù)據(jù)寬帶化、業(yè)務多樣化，即寬帶集群通信系統(tǒng)的方向發(fā)展。寬帶集群系統(tǒng)支持多會話業(yè)務功能，如呼叫保持、多路終端音/視頻通話、單呼、組呼等。系統(tǒng)架構如圖1所示，分為4個層次：終端、接入子系統(tǒng)、交換控制平臺、調(diào)度應用平臺。其中，多樣化終端之間，通過接入子系統(tǒng)與交換控制平臺實現(xiàn)相互通信。調(diào)度應用平臺是集群系統(tǒng)中的安全運營支撐子系統(tǒng)，包括多媒體調(diào)度臺、錄音服務器、安全服務器等。

錄音服務器系統(tǒng)用于實時監(jiān)控和記錄通信信息，包括呼叫號碼、呼叫時間、通話內(nèi)容等，起著服務質(zhì)量監(jiān)督、解決糾紛等重要作用。錄音服務器的發(fā)展也經(jīng)歷了從模擬到數(shù)字的發(fā)展歷程。但現(xiàn)在市場上的許多錄音服務器在支持業(yè)務類型方面具有一定的局限性，往往僅能支持單一類型，如果想滿足多會話業(yè)務能力，就必須購買多套錄音服務器系統(tǒng)。為了滿足寬帶集群系統(tǒng)的多業(yè)務需求，錄音系統(tǒng)必須朝著在基于網(wǎng)絡支持的同時處理語音、高速數(shù)據(jù)、移動圖像等多會話業(yè)務方向發(fā)展。

圖1 寬帶多媒體集群系統(tǒng)架構

如圖1所示的寬帶多媒體集群系統(tǒng)架構中，錄音服務器控制并保存來自交換控制平臺的數(shù)據(jù)，實現(xiàn)事后查詢與實時監(jiān)控。錄音服務器功能實現(xiàn)分為控制平面和業(yè)務平面。本文研究了寬帶集群系統(tǒng)錄音服務器的業(yè)務平面，提出了一種存儲會話數(shù)據(jù)的策略，可以在同一時間完成多組會話數(shù)據(jù)存儲，并且支持單呼、組呼、音頻、視頻等特殊業(yè)務的需求。

2 實時傳輸協(xié)議

錄音服務器需要處理的是寬帶集群系統(tǒng)通信中的會話數(shù)據(jù)，由實時傳輸協(xié)議（real-time transport protocol，RTP）傳送。其中，RTP是一種在Internet上處理多媒體數(shù)據(jù)流的網(wǎng)絡協(xié)議，用UDP分組來承載。RTP數(shù)據(jù)報文分組格式如圖2所示。

RTP頭部報文格式如圖3所示。其中，載荷類型（PT），7 bit，標識了RTP載荷的類型；序列號（SN），16 bit，發(fā)送方每發(fā)送完一個RTP分組就將該域的值增加1，接收方可以由該域檢測分組的丟失及恢復分組序列，序列號的初始值是隨機的；同步源標識符（SSRC），32 bit，同步源指RTP分組流的來源，在同一個RTP會話中不能有兩個相同的SSRC值。

3 存儲策略

據(jù)統(tǒng)計，寬帶集群系統(tǒng)錄音服務器平均1 s約存儲50 KB會話數(shù)據(jù)，一天約4 320 MB，如果磁盤空間按160 GB計算，則錄音服務器可以存儲約40天的會話數(shù)據(jù)。進行錄音服務器后期查詢時，主要的查詢條件是：時間、呼叫人和呼叫類型（單呼、組呼、音頻、視頻）。

上述分析表明，集群系統(tǒng)錄音服務器所面臨的數(shù)據(jù)特點是數(shù)量龐大，但數(shù)據(jù)間關系相對簡單。大數(shù)據(jù)量在處理時容易出現(xiàn)數(shù)據(jù)囤積、丟失等問題。根據(jù)錄音服務器的數(shù)據(jù)特點和面臨的問題，集群系統(tǒng)錄音服務器需要實現(xiàn)兩大功能：快速提取會話數(shù)據(jù)、實時存儲大量數(shù)據(jù)。錄音服務器怎樣實現(xiàn)這兩大功能，高效地完成從接收、處理到存儲數(shù)據(jù)的過程，需要考慮如下兩點。

（1）實時處理，快速接收數(shù)據(jù)，不囤積數(shù)據(jù)，避免數(shù)據(jù)丟失

順序接收技術是將同一時間收到的所有數(shù)據(jù)存于一個大的緩存中，按照時間的先后順序依次接收；按照某個接收規(guī)則，在接收時判斷優(yōu)先級，優(yōu)先級高的數(shù)據(jù)先被接收。兩種方法顯然都不適合實時處理的思想。多線程接收技術，是為了同步完成多項接收任務，提高資源使用效率以及系統(tǒng)的性能。錄音服務器運用多線程接收技術，設定系統(tǒng)性能可接受的線程數(shù)目，每個存儲會話數(shù)據(jù)請求對應一個接收線程，每一個接收線程對應一個處理線程。為了保證數(shù)據(jù)無丟失，錄音服務器運用緩存機制，將未處理的數(shù)據(jù)存于緩存中，并及時清空已處理的數(shù)據(jù)緩存空間。

（2）實現(xiàn)高效存儲，便于事后查詢

針對錄音服務器“數(shù)據(jù)量龐大、數(shù)據(jù)間關系相對簡單”的特點，如果用復雜的分布式存儲，反而會降低存儲效率，采用比較簡單的分級目錄及文件存儲的形式，可以達到高效存儲的目的。根據(jù)單呼、組呼的會話類型，目錄層級設為“/日期/主叫號/被叫號/”（單呼）或“/日期/組號/”（組呼）；根據(jù)音頻、視頻的會話類型，可以將文件后綴類型設為“.artp”（單呼）或“.vrtp”（組呼）。考慮到分級目錄的查詢效率很低，先選擇數(shù)據(jù)庫存儲會話信息，再定位存儲路徑的方法，有利于事后的查詢工作。

綜上所述，寬帶集群系統(tǒng)錄音服務器可以采用“多線程+緩存機制+分級目錄文件存儲形式+數(shù)據(jù)庫存儲會話信息”的存儲策略。

4 存儲策略實現(xiàn)

4.1 會話數(shù)據(jù)的獲取方法

錄音服務器功能實現(xiàn)分為控制平面和業(yè)務平面。如圖4所示，當需要錄音時，交換控制平臺向錄音服務器的控制平面發(fā)送“錄音開始請求”協(xié)議報文，協(xié)商成功則控制平面分配port地址，同時生成新的RecordItem對象（RecordItem中存儲錄音的相關數(shù)據(jù)，包括主叫號、被叫號、會話類型、分配的端口號等），并用此port地址作為RecordItem的鍵值存入RecordItemMap緩存中。

業(yè)務平面一直處在監(jiān)聽狀態(tài)，當RecordItemMap中有新的RecordItem時，會添加新的接收RTP任務到任務池，如圖5所示。

圖4 業(yè)務平面與控制平面的交互

圖5 業(yè)務平面數(shù)據(jù)緩存分析

當有新任務時，業(yè)務平面任務池的接收線程會利用多線程并發(fā)方式，使協(xié)商好的地址（RecordItem）接收來自交換控制平臺的所有RTP數(shù)據(jù)流，并將會話數(shù)據(jù)放入緩沖池（RecordData>）中，每一個端口號對應一個會話的數(shù)據(jù)流。

4.2 文件存儲規(guī)則

如圖5所示，存儲線程從緩沖區(qū)獲取會話數(shù)據(jù)，解析RTP頭報文，按固定格式存儲payload數(shù)據(jù)（RTP分組中的有效載荷）到文件中，文件格式為“RTP數(shù)據(jù)長度+RTP payload數(shù)據(jù)”。每一個文件都有RTP管理頭，存儲當前記錄數(shù)據(jù)的文件長度和時間信息等。

錄音服務器接收到的數(shù)據(jù)有以下幾種類型，根據(jù)不同的通話類型，需要用不同的方法進行存儲。

（1）雙向音頻通話

雙向音頻通話，即單呼音頻會話類型，記錄的信息是雙向的。如圖6所示，通話雙方的RTP數(shù)據(jù)均存儲在一個文件中，如果雙方都不說話，則插入相應的靜音。當RTP屬性更改（如編碼協(xié)商、呼叫保持/恢復或達到限定文件大小）時，存入另一個文件。

根據(jù)SSRC對RTP流進行分段處理，避免SSRC發(fā)生變化時，可能存在時間間隔不一致的問題。對雙向音頻通話的RTP流報文采用“10個報文之后，如果新出現(xiàn)SSRC，則進行分段”的策略進行分段，分段示意如圖7所示。在11個報文后，出現(xiàn)了SSRC為4的報文，在此種情況下，解碼流程將對RTP報文進行分段處理，各分段報文解碼后，直接拼接即可。

圖6 雙向視頻通話存儲

（2）集群音頻通話

如圖8所示，集群音頻通話類型為單向通話。同一時間只有一個用戶可以發(fā)言，故用戶每一次發(fā)言記錄一個數(shù)據(jù)文件。

根據(jù)SSRC對集群音頻通話進行分類處理。由于是單向通話，每一個用戶發(fā)言時，其他用戶沒有發(fā)言權，故該用戶在發(fā)言時，只有一個SSRC標識源的RTP數(shù)據(jù)流，一旦變更用戶發(fā)言，RTP數(shù)據(jù)流的SSRC也會隨之改變。圖9描述了3個用戶進行集群音頻通話的情景，橫向為時間軸，每個用戶在發(fā)言時，其他用戶處于等待發(fā)言狀態(tài)。此通話需要存4個文件，其中SSRC為3的用戶由于中間有中斷，屬于兩次發(fā)言，需要存兩個文件。

圖9 SSRC集群分組

（3）集群視頻通話

根據(jù)SSRC對集群視頻通話進行分類處理，如圖10所示。由于是單向通話，每一個用戶發(fā)言時，其他用戶沒有發(fā)言權，但與集群音頻通話不同的是，每人說話時需要存儲兩個數(shù)據(jù)文件，一個為音頻，一個為視頻。故該用戶在發(fā)言時，有兩個SSRC標識源的RTP數(shù)據(jù)流，一個是音頻，一個是視頻。一旦變更用戶發(fā)言，RTP數(shù)據(jù)流的兩個SSRC也會隨之改變。

4.3 文件路徑及文件名策略

根據(jù)會話類型的不同，數(shù)據(jù)文件利用分級目錄名、文件名表示錄音的時間及時間段下的呼叫類型，存儲于磁盤中。

所有的錄音文件放在統(tǒng)一的路徑（如../record/）下，按“日期”進行分布存儲，如圖11所示。日期以天為單位，按“年—月—日”規(guī)則命名文件夾。每一個待存儲的數(shù)據(jù)文件按照日期找到自己所屬的路徑，接下來判斷目標文件記錄的是雙向通話數(shù)據(jù)還是群組呼叫記錄。

圖11 文件路徑關系

單呼只有兩個發(fā)言人，為了清楚地標記出主叫號和被叫號，單呼記錄文件路徑設定為“../主叫號/被叫號/”。圖11中，主叫號是“3000”，被叫號是“2000”。單呼存儲時兩路存于一個文檔中，考慮到文件大小及音頻、視頻文件類型，單呼文件命名規(guī)則是：如果是音頻文件，以“時間_序號.artp”格式命名；如果是視頻文件，以“時間_序號.vrtp”格式命名。如圖12所示的某日某主叫與被叫之間的音頻會話記錄，包括3個時間段，其中“16∶16”時段，會話時間較長，保存了3個文件。

圖12 單呼記錄文件

對于每一個組呼會話，都有固定的群組號，為了區(qū)分不同時間段的會話，將“/會話群組號/時間段/”作為組呼的文件存儲路徑。如圖13所示，組號為“0012”在“2012年10月22日”的3個時間段的會話記錄存儲路徑。

圖13 組呼記錄文件

由于群組呼叫的每一個會話中，會出現(xiàn)2個及以上發(fā)言人的情況，且每個發(fā)言人有可能會存儲多個文件，所以文件命名需要區(qū)分發(fā)言人及發(fā)言的先后順序，考慮到文件大小及音頻、視頻文件類型，按照“發(fā)言序列號_caller_序號.artp”的格式命名音頻文件，按照“發(fā)言序列號_caller_序號.vrtp”的格式命名視頻文件。某日某時間段的某會話組的呼叫記錄如圖14所示。例如“2_028-105_2.artp”，代表此文件是callID為028-105發(fā)言的音頻數(shù)據(jù)，它在當前會話中是第2個發(fā)言人，因為發(fā)言數(shù)據(jù)過長，此文件是028-105當前發(fā)言的第2個文件。

圖14 組呼記錄文件

4.4 錄音信息存儲

為了提供方便的查詢，利用數(shù)據(jù)庫存儲錄音信息，設表名為RecordInform，SQL語句如下所述。

CREATE TABLE RecordInform

(

callID character varying(20),

starttime timestamp without time zone,

stoptime timestamp without time zone,

calltype character varying(5),

callernum character varying(20),

calleenum character varying(20),

audiotype character varying(5),

videotype character varying(5),

filepath character varying(100)

)

callID是一個會話的唯一標識；starttime和stoptime是會話的開始和結束時間；calltype是會話類型，有單呼、組呼兩種；callernum和calleenum是會話的主叫和被叫，如果會話類型是組呼，則被叫號為組號；audiotype是話音的編碼類型；videotype是視頻的編碼類型；filepath是當前會話文件的存儲路徑。

有查詢需求時，查詢數(shù)據(jù)庫RecordInform表，定位文件存儲路徑，將查詢結果（包括錄音開始時間、錄音結束時間、數(shù)據(jù)文件及信息列表）返回給客戶端，如果客戶端要回放文件，則調(diào)用解碼庫函數(shù)，將得到的RTP數(shù)據(jù)解析，得到音頻或視頻。

5 實驗結果

筆者對本文提出的方法進行了實驗：主要在IP語音電話雙方、群聊的通話過程中，錄音服務器在協(xié)商好的通話端口號下抓取語音數(shù)據(jù)，分組提取解析RTP報文，并保存于文件中。錄音服務器處理1、2、5、10路語音數(shù)據(jù)（10 s/G.711語音格式）所用時間見表1。可以看出，4組實驗耗時基本相同，為15～16 s。其中，錄音開始時間是服務器接收到第一個會話記錄的時間；錄音結束時間是將會話數(shù)據(jù)存儲到指定文件結束的時間。

表1 錄音服務器存儲多路會話消耗的時間

通過數(shù)據(jù)庫查詢“時間”/“呼叫人”條件定位目標文件。實驗中通過數(shù)據(jù)庫查找到的一路語音數(shù)據(jù)，經(jīng)解碼所得的Wav文件波形如圖14所示，回放時基本沒有失真。

圖14 回放波形

6 結束語

本文簡單分析了寬帶集群系統(tǒng)中錄音服務器對多會話業(yè)務的需求，提出了一種存儲策略，并驗證了方法的可行性。但由于RTP的多樣性，需要分別處理；寬帶集群系統(tǒng)的數(shù)據(jù)量大，需要考慮錄音服務器的性能問題；視頻數(shù)據(jù)需要考慮同步問題等。因此，在實際研究工作中，對錄音服務器會話數(shù)據(jù)的處理及存儲方法需要進一步分析。

1 吳微,黃焱.IP over DVB中RTP音頻數(shù)據(jù)的提取與恢復.信息工程大學學報,2009(3)

2 RFC3550.RTP:a Transport Protocol for Real-Time Applications,2003

3 嚴俊,馬小駿,顧冠群.RTP的研究與實現(xiàn).計算機工程與應用,2000,36(9)

4 王備戰(zhàn),牛振喜,樓潤瑜等.基于RTP的IP實時音頻傳輸研究.西北工業(yè)大學學報,2001,19(1):48～51

5 劉佳翔.RTP流媒體識別算法的設計與實現(xiàn).電腦知識與技術,2011(2)

6 趙浩然.論數(shù)據(jù)分區(qū)對海量數(shù)據(jù)處理的必要性.科學之友,2011(11)