江 凇,王寶海,趙金城,宋 江,段佳秀
1(國網江蘇省電力有限公司 信息通信分公司,南京 210024)
2(南京南瑞信息通信科技有限公司,南京 210003)
3(南京郵電大學,南京 210003)
基于電力IMS[1]交換網的電話業務是國家電網公司內部重要的通信業務之一,為國家電網員工提供了高效便捷的語音通話服務.在一些重要的部門、崗位以及重要的電話會議等場景中,通常要求對通話進行錄音,以記錄來電的內容.通話錄音的內容既可以用于追蹤業務的進度,也可用于事后回溯以避免業務糾紛.因此,在電力IMS 交換網實施電話錄音的行為可以完善電網內部的電話管理制度,提高業務的監管水平.
隨著電話交換技術由電路交換向分組交換演進,三網融合需求的呼聲越來越高,而IP 多媒體子系統(IMS)技術可以支持話音,電視媒體,數據這三種業務的傳輸,還具有統一的平臺和接口,分層的架構設計,集中的業務控制與管理,可保證的QOS 等優點.此外,傳統的基于電路交換的電話錄音技術因其系統復雜,存儲的不便捷和非實時性的特點,已經無法滿足新時代行政辦公對高效,統一,即時的通話錄音需求.因此,本文設計出一種基于電力IMS 交換網的電話實時錄音系統,該系統可為電力IMS 交換網中的各類終端(IP,POTS,PC 等)提供即時、高動態、高質量的錄音服務,并通過系統后臺將錄音記錄即時推送至軟件終端,以便IMS 終端用戶隨時查閱錄音.
該系統借助基于IMS 核心交換機的端口鏡像技術實現對整個網絡的監控管理,并能夠及時抓取所需要的數據,借助一致性哈希算法來查找緩存服務器,利用Ckafka 高性能消息隊列來保證消息消費的有序性和負載均衡.最終,設計與實現一種基于會話初始(SIP)協議[2]的高動態即時錄音系統,其系統框圖如圖1所示.

圖1 系統框圖
系統的實現流程如下:
步驟1.主叫話機A 向被叫話機B 發起呼叫請求,主叫話機A 經由核心交換機、SBC(邊界會話控制器)、電力IMS 交換網、再回到核心交換機,向被叫話機B 發送SIP 協議中的invite 信令[3].
步驟2.在被叫話機B 接收到invite 信令后,給主叫話機A 發送應答消息,主叫話機A 確認應答消息后,開啟與被叫話機B 的通話.
步驟3.IMS 軟件終端與被叫話機B 聯動,當主叫話機A 與被叫話機B 的通話開啟時,IMS 軟件終端通知錄音服務器開啟錄音.
步驟4.錄音服務器從核心交換機的鏡像端口獲取信令包,再根據from、to 等標簽,對信令包進行SIP 包解析,獲取主被叫話機號碼、IP、媒體端口及語音編碼.解析RTP(媒體流)報文后,針對g.711a、g.711u、g.729、g.726、iLBC 等不同編碼方式[4,5],將錄音文件解碼,通過Ckafka 消息隊列將解碼的數據緩存至高性能緩存服務器.
步驟5.通話需要結束時,主叫話機A 經由核心交換機、SBC(邊界會話控制器)、電力IMS 交換網、再回到核心交換機,向被叫話機B 發送SIP 協議中的bye 信令.
步驟6.被叫話機B 接收到bye 信令后,給主叫話機A 發送應答消息,主叫話機A 確認應答消息后,結束與被叫話機B 的通話.
步驟7.錄音服務器取時間或集將主被叫話機的錄音進行混音并存儲為PCM 格式.錄音服務器將通過系統后臺將錄音記錄即時推送至PC/Web 終端,以便用戶隨時查閱通話錄音.
通過對SIP 報文中信令的解析,并從媒體端口得到通話雙方的音頻流,采用Ckafka 消息隊列構建實時數據通道,同時提供對數據流的處理,然后將得到的音頻流傳送至高性能內存數據庫以保存數據.在數據庫和錄音服務器之間插入分布式緩存[6],使錄音服務器不必頻繁訪問數據庫,而是直接從緩存存取數據,從而縮短了數據的訪問時間,提高了數據庫的訪問性能.對于分布式緩存服務器的查找采用的是一致性哈希算法,它極大的提高了緩存命中率,以及減少在增刪節點時數據遷移的成本.
Ckafka 技術[7]是一種消息隊列的技術,它基于Apache Kafka 消息隊列引擎,具有強大的吞吐量和可擴展性能強的特點,主要用于高性能的流式處理、消息傳輸等場景,并且完全兼容Kafka.其詳細特性如下:
(1)可擴展性:該框架可輕松擴展,無需停機.
(2)高容量:旨在處理大量數據,并能對數據進行壓縮.
(3)可靠性:具有可恢復能力和一定的容錯能力.(4)數據轉換:可以把從信息源獲取的數據流轉化成要求的數據流格式.
(5)低延遲:專注于傳統消息傳遞以實現低時延.
(6)順序讀寫:和大部分的消息隊列一致,Ckafka可以保證數據按照順序進行處理,極大提升磁盤效率.
(7)異步通信:在無需立即處理消息的場景下,當訪問量高時Ckafka 僅將消息放入隊列中,等訪問量降低后再對消息進行處理,以降低系統負荷[8].
本系統為集中錄音系統,要求并行處理的能力強,由上面的介紹可知Ckafka 消息隊列具有強大的吞吐量,多線程的流式處理,具備數據壓縮的特性以節約存儲空間,對于高并發數據流,支持在線的水平擴展和消息的自平衡,在最佳的情況下,插入和刪除數據的時間復雜度能降為O(1),這極大的降低系統的復雜度,提高系統運行的穩定性,同時結合一致性哈希算法可以實現對服務器集群請求的均衡處理,所以本文采用該技術來對錄音系統的信令流和音頻流進行處理,可輕松實現毫秒級的消息處理,極大的降低系統的時延,提高系統的實時性.
一致性哈希算法最初是由Karger D 等提出的一種散列算法.其最初是為了解決服務器集群中的熱點問題,整個算法的過程如圖2所示[9,10],但是該算法具有一定的局限性,當服務器的節點數較少,那么對于多個請求可能會導致散列環上的數據傾斜以及服務器分配不均的問題,因此在散列空間和物理節點之間加入虛擬節點[11],通過對虛擬節點的分配,把多個虛擬節點與相對應的物理節點進行映射,并在散列環上分布恰當的虛擬節點數目,從而每臺服務器都能達到均衡處理請求的目的.
本文提出的一致性哈希算法是在普通哈希算法上進行改進,因為環形散列環大小為232,因此對目標利用哈希函數運算之后,再進行模232運算,即可將目標的Key分布在整個散列環上,如式(1)所示.


圖2 一致性哈希算法
在SIP 報文中,Call-ID 可以作為這通會話的全局識別號,因此可以作為該通電話的唯一標識符;而對于不同的緩存服務器,其IP 地址也都不同,因此可以利用緩存服務器的IP 地址作為它的唯一標識符.在不考慮虛擬節點的情況下,本文提出的一致性哈希算法的步驟如下:
步驟1.利用每一臺緩存服務器的IP 地址作為哈希運算的對象并進行哈希運算,然后把得到的結果進行模232運算,得到相應的鍵值Ks1,Ks2,···,Ksn,至此,已經將每一臺緩存服務器都映射到散列環[12]上,對于3 臺服務器在散列環上映射情況如圖3所示.

圖3 3 臺服務器映射到散列環
步驟2.對當前打進來的某一通電話的Call-ID 進行哈希運算,然后再對運算結果進行模232運算,得到對應的鍵值Kc,并映射到步驟1 所示的散列環上,現將緩存服務器和某一通電話都映射到散列環上,其映射情況如圖4所示.
步驟3.從該通電話在散列環上映射的位置開始,按順時針方向,找到最近的那一臺服務器A,那么該通電話的媒體流就緩存到服務器A,如圖5所示.

圖5 尋找緩存服務器過程
對于多路通話,亦可采用上述方法快速尋找到對應的緩存服務器.若多路通話均映射到散列環相對固定的位置,那么最終他們都會按順時針尋找到最近的那臺服務器緩存數據,這將導致另外兩個服務器空閑,而當前服務器負載量過大甚至宕機.對此,采用虛擬節點技術[13],根據通話映射在散列表的位置關系,利用物理節點復制出多個虛擬節點,然后在散列環中安放多個虛擬節點.隨著虛擬節點的增多,散列環上總的節點數就越多,節點均勻分布的可能性就越大,當多個請求同時到來時,緩存服務器的負載就能更加均衡[14–16],如圖6所示,深色的表示物理節點,淺色的表示復制出的虛擬節點.由圖分析可得:若不引入虛擬節點技術,將會有五通電話的請求將直接流向服務器A,一通電話的請求流向服務器B,服務器C 處于空閑狀態,這樣的分配方式極不平衡,這將導致服務器A 的負荷過大,系統處理能力降低,而引入虛擬節點技術,每臺服務器都分到2 個請求,這樣可以充分發揮每臺服務器的性能,提高系統的處理能力.

圖6 虛擬節點
為了驗證錄音服務器的性能,本文通過運行多臺虛擬機來模擬錄音服務器、緩存服務器集群以及數據庫服務器集群,并將采用一致性哈希算法和Ckafka 消息隊列技術的服務器與采用普通的哈希算法的服務器進行比較,利用JMeter 工具來模擬用戶的通話錄音請求,并根據服務器的響應時間、吞吐量、容錯能力以及錄音推送至客戶端的最大時延這4 項指標作為其評估性能的依據,最后根據測試結果,使用Matlab 繪制相應的圖表進行分析,結果如圖7所示.
圖7顯示出錄音服務器中同時錄音的請求數與其響應時間的關系,由圖可得請求數在900 以下,采用一致性哈希算法和Ckafka 技術的響應時間與采用普通哈希算法的響應時間基本一致,但隨著同時錄音請求數的增多,這兩種方案響應時間的差距開始變大,當錄音請求數達到1300 時,采用一致性哈希算法和Ckafka技術的錄音服務器明顯要好于另一種方案,說明本設計的錄音服務器對于高并發的處理能力要強于一般服務器,其負載調度也更為合理.
圖8顯示出分布式錄音服務器系統中服務器個數對整個系統吞吐量的關系,由圖可得服務器個數在4 個以內,兩種方案的吞吐量基本一致,當服務器個數大于4 時,隨著服務器個數增多兩者性能差距越來越明顯,服務器個數為8 時,兩者差距最大,約為14.29%,說明本設計的錄音服務器適合做成大規模的分布式系統,其系統吞吐量的優勢越顯著.

圖7 請求數與響應時間關系

圖8 服務器個數與吞吐量的關系
對于服務器集群停機情況,本文構建了一個包含6 個服務器的集群.當群集正常接收模擬請求時,突然關閉一個錄音服務器,并觀察群集無法正常響應的錯誤率趨勢.實驗結果如圖9所示.模擬錯誤發生的時間在1 s 時刻,從圖中可以看出,兩個方案在1 s 到3 s 的錯誤率處于上升階段,基本上沒有差別.然而,在3 s到5 s 內,采用普通哈希算法的服務器集群錯誤率幾乎不變,但采用一致性哈希算法+Ckafka 技術的錄音服務器的錯誤率顯著降低.5 s 后,兩個方案的錯誤率開始下降,直到錯誤率為0%.因此,可以得出結論:當集群系統有部分服務器停機時,采用一致性哈希算法和Ckafka 技術的錄音服務器可以在一定程度上降低集群錯誤率.
當通話結束,錄音服務器取時間或集將主叫和被叫通話的語音進行混音,并保存為PCM 格式,隨后立即將語音消息推送至PC/Web 終端.利用通用定時器,記錄從通話結束開始到PC/Web 終端收到語音消息所用的最大時延,并控制錄音時間相同的通話個數,繪制服務器同時處理通話數與終端收到推送的最大時延的關系圖,如圖10所示.由圖分析可得:當通話數小于150 時,兩種方案基本保持一致,當通話數大于150 時,差距開始拉大,并且隨著通話數的增多,差距越來越大.當通話數達到350 時,基于一致性哈希算法和Ckafka技術的錄音服務器的最大時延為600 多毫秒,而另一種方案的最大時延已經遠超過1 s,實時性得不到保證.通過以上分析,再結合圖7錄音請求數和響應時間的關系,可以得出結論:相比于傳統電話終端錄音的推送慢,查找難,不便捷的缺點,本系統在一定通話數下的響應、處理、推送時間可以控制在1 s 以內,突顯出其實時性強的特點,又因為是集中式錄音,不存在終端修改錄音的情況,其安全性也得到了保障.

圖9 服務器發生錯誤持續時間與錯誤率關系

圖10 同時處理通話數與最大時延的關系
本文通過分析電力IMS 交換網中電話終端的實時錄音業務需求,借助基于IMS 核心交換機的端口鏡像技術、一致性哈希算法和Ckafka 高性能數據緩存技術,設計出一種基于電力IMS 交換網的即時錄音系統.該即時錄音系統為旁路系統,實現靜默錄音,不會對生產系統產生影響,可以為電力IMS 交換網的IP 終端、POTS 終端及軟件終端(PC,Web)等各類終端提供即時、無差異的錄音服務[17],并通過系統后臺將錄音記錄即時推送至軟件終端,以便IMS 終端用戶隨時查閱錄音.文章最后,將基于一致性哈希算法和Ckafka 技術的服務器與基于普通哈希算法的服務器就響應時間、吞吐量、容錯能力和推送的最大時延這四項指標對其進行比較,分析得出,本文設計的錄音服務器具有高并發的數據處理能力,高吞吐量,響應時間短,容錯力和實時性強并能實現負載均衡.此外本文的算法還可用于大規模分布式服務器的查找,分布式存儲等領域[18].