摘 要： 結合Android平臺的NDK集合，設計及開發了在Android平臺上使用SIP協議的軟件使之能通過SIP軟交換服務器進行通話，并針對性地提出以太網數據包的過濾策略，完善了數據包解析模塊，實現了SIP軟交換系統的功能擴展。系統將C語言開發的模塊全部改用跨平臺的Java來編寫，較傳統的SIP軟交換系統而言，其可移植性更強。
關鍵詞： SIP；數據包過濾；Android
傳統程控交換使用硬件電路實現硬交換，而軟交換是指用軟件實現電話交換能力，軟交換則采用服務器+軟件的形式實現電話的尋號/接續/呼叫流程處理。VoIP（Voice over Internet Protocol）是一種建立在互聯網上的數字化或分組化的語音傳輸技術，會話發起協議（SIP）是VoIP中常用的控制協議。移動互聯網時代，移動設備用戶可根據需要連接互聯網。當今移動設備終端中最流行的操作系統是Android系統，因此，只要在Android系統上開發支持SIP協議的軟件，就能夠運用VoIP技術實現語音通話。
目前已有的SIP軟交換系統的硬件由SIP服務器、網絡連接設備（如交換機）和SIP電話機構成，因此存在成本過高、終端設備易損壞、攜帶不便等缺點，而本研究實現的系統則由SIP服務器、Wi-Fi和智能手機構成。這樣使智能手機軟件代替了終端設備的電話機，節省了成本，軟件實現方面，本系統結合SIP軟交換系統和SIP數據包的結構，運用Android系統的軟件開發技術實現移動終端設備的語音通話功能，擴展了SIP軟交換系統的功能和服務質量[1-2]。
1 系統需求分析
從功能可將系統劃分為以下兩部分。
（1）服務器功能。服務器是為用戶提供信息交換和信息處理而開發的，所以它必須具備信息處理功能和信息交換功能。
（2）Android客戶端功能。客戶端必須具備連接服務器IP地址的功能、發送語音消息功能以及解析收到的數據并把數據還原為語音消息的功能。
頂層數據流圖如圖1所示。
2 系統設計
2.1 Proxy Server的運作模式
以圖2為例，A（201@192.168.6.5）先送出一個INVITE信息呼叫B（201@192.168.6.3），Proxy Server收到后則進行查詢，由查詢結果可知目前B實際的地址為202@192.168.6.3，于是Proxy Server便會再以202@192.168.6.3發出INVITE信息，B在回復200 OK時（200表示服務器回送的響應狀態碼，OK表示請求成功），會將200 OK的Response（響應）傳給Proxy Server，再由Proxy Server轉送給A。
2.2 Android外線呼叫運作模式
Android外線呼叫運作模式如圖3所示。其關鍵步驟與內線呼叫類似，主要區別步驟在于：F8、F9網關向Proxy回送183 Session Progress響應，表示呼叫已在處理[3]。
2.3 系統可移植性
軟件的可移植性是指在一定程度上，軟件從一種環境移植到另一種環境后還能正常工作的能力，屬于軟件質量的范疇，良好的可移植性可延長軟件的生命周期。
原有的SIP軟交換系統大部分模塊均采用跨平臺的Java開發，但也有部分模塊或局部地區是采用C開發的，如版權認證模塊。要實現系統整體的可移植性，最簡單的方法就是完全采用Java來開發該系統。
版權認證模塊的改良與設計：對于服務器軟件，版權認證最重要的就是能試用于多網卡和群服務器，并且認證文件不被篡改、破解，這里使用serial（序列號）+MAC（地址）+max（最大用戶數）+expiration（到期日期）+key（許可證密匙）的認證方式，通過license.xml文件來承載認證信息，將license.xml文件傳給客戶，復制到系統的特定位置，系統啟動時通過構造XML解析器來解析license.xml文件核對信息完成認證[4]。
3 數據庫設計
3.1 系統E-R圖
SIP服務器的實體E-R圖如圖4所示。
其主要屬性如下。（1）Android客戶：記錄每個連接到服務器的客戶端IP地址；（2）IP地址：SIP服務器IP地址；（3）客戶端編號：客戶端連接服務器后，服務器將分配一個短號給客戶端，客戶端可通過短號相互呼叫；（4）最大連接數：連接到服務器的客戶端最大數量；（5）時間：服務器啟動的時間；（6）服務器記錄：記錄服務器運行信息；（7）網關：撥打外線電話時，需要通過網關。
Android客戶端實體E-R圖如圖5所示。
其主要屬性如下。（1）手機IP：每個連入網絡的手機都分配唯一的IP地址。（2）服務器地址：SIP服務器IP地址。（3）被尋呼者：記錄被呼叫的另外一個客戶端別名（編號）。（4）客戶端編號：本手機的客戶端編號。（5）服務器類型：即SIP服務器。（6）解碼編碼器：客戶端撥打電話時，需要將語音消息編碼成二進制代碼，而被呼叫的客戶端收到信息時需要將二進制代碼解碼為原來的語音消息。
3.2 數據表的結構
本系統一共使用了47張數據表，由于表與表之間的關系過于復雜，因此只選出其中具有代表性的兩張表。注意SIP服務器表和Android客戶端的表并沒有列出來，以下的兩張表足以說明SIP服務器和Android客戶端的關系，spm_job表用于保存服務器運行時的信息，id為主鍵。如表1所示。
t_gw_extension主要用來保存網關信息記錄，gw_id為主鍵，如表2所示。
4 系統運行與測試
4.1 SIP軟交換系統健壯性和穩定性運行與測試
在以太網錯綜復雜的環境下，SIP軟交換系統作為服務器軟件，必須能穩定運行并對用戶提供可靠高效的服務。系統除了能處理正常業務數據，還應該能夠及時識別和丟棄以太網中“非法”的無用數據包，即系統本身應該具有數據包的過濾方法與策略。
為研究SIP數據包的格式，本設計抓取某SIP軟交換系統服務器網卡收發的SIP協議的數據包。利用網絡抓包工具Wireshark（一款免費的網絡協議檢測程序）。抓取數據包的步驟如下。（1）選取抓獲網絡設備列表；（2）打開一個接口開始捕獲數據包；（3）數據包的過濾設置；（4）捕獲數據包；（5）在捕獲到所需數據包后，根據需要進行后續工作[5]。
在接收到一個以太網數據幀時，在協議棧的數據從底部啟動，同時消除對報文協議報頭的層。協議必須檢查每一個數據包的協議標識符頭，以確定上層協議來接收數據，然后分析可定制的規則事先需要的內容，如數據包的源IP、目的IP和源端口號等，如圖6所示。
4.2 SIP數據包的預過濾策略的測試和運行
參照SIP數據包的分析，只有請求消息是SIP終端發向服務器的，即對服務器存在的數據包只可能是請求消息。因而只需要解析請求消息，在服務器正式解析之前提前識別并過濾有可能影響系統正常運行的數據包，保證系統穩定運行[6]。具體步驟如下。
（1）解析前預處理方法：限制“合法”數據包最小長度，小于最小長度的數據包全部丟棄，最小長度應根據實際情況靈活確定。
（2）檢索數據是否含有行結束標志CRLF（Windows）或者LF（UNIX/Linux）。
（3）檢索Request-Line中是否含有SIP版本信息（如SIP/2.0）。
（4）檢索Request-Line中是否包含Method關鍵字。
（5）檢索Request-Line中Request-URI是否符合規定格式。
SIP系統本身也要對正常業務的數據包進行解析，在解析的過程中發現數據包異常并及時丟棄，這樣既能保證系統的健壯性，又能節約系統解析這些異常數據包時的開銷，保證系統穩定運行的同時也保證了系統的執行效率。服務器接收到的數據包經過濾策略處理后，基本可以過濾掉非SIP數據包，接下來的“非法”數據包應該就是偽SIP包或者是因為某種原因導致失效的SIP數據包，而這一類數據包暫時不必進行過濾，可將其視為正常數據包[7]。運行效果如圖7所示。
圖7說明SIP軟交換系統能抓取所有的網絡流量，過濾出SIP消息，測試SIP消息能否能順利發出。
本研究對SIP軟交換系統在Android平臺上的實現始終遵循審視問題、分析問題、升華問題、解決問題、總結擴展的方針路線，從軟件品質擴展的角度對SIP軟交換系統進行改進，系統中采用數據包過濾策略可對服務器軟件的維護、網絡安全的構筑提供參考和借鑒。而系統硬件則由SIP服務器、Wi-Fi和智能手機構成，可實現中小企業網內智能手機免費通話，同時也可撥打外線電話，可降低企業內通信成本，具有進一步挖掘的市場潛力。
參考文獻
[1] 蔣紹林，王金雙，張濤，等.Android安全研究綜述[J].計算機應用與軟件，2012，10（29）：205-210.
[2] 吳綱.IP包處理技術淺析與展望[J].計算機與網絡，2010，5（3）：257-260.
[3] 朱劍鋒.基于SIP的IP-PBX呼叫保留功能的實現[J].信息與電腦，2009，9（12）：27-31.
[4] 林海泉，楊磊，朱劍鋒.SIP軟交換系統的版權認證[J].瓊州學院學報，2012，9（3）：47-53.
[5] 張振剛.移動通信軟交換網絡安全機制研究[J].網絡與通信，2004，6（36）：37-41.
[6] 劉應平.局域網異常數據包監控與處理系統的設計[J].電腦開發與運用，2010，9（12）：21-25.
[7] 廖永紅，李洛，黃戰.基于IP包內容的Windows包過濾技術的實現[J].電腦與信息技術，2001，5（3）：4-7.