基于SIP的模擬器設(shè)計與開發(fā)

1、福州大學(xué)本科畢業(yè)設(shè)計（論文） 本科生畢業(yè)設(shè)計（論文）題 目： SIP業(yè)務(wù)模擬器工具的 設(shè)計與研究 姓 名： 羅發(fā)龍 學(xué) 號： 030701328 學(xué) 院： 數(shù)學(xué)與計算機科學(xué)學(xué)院 專 業(yè)： 信息與計算科學(xué) 年 級： 2007級 指導(dǎo)教師： （簽名）2011 年 06 月16 日 SIP業(yè)務(wù)模擬器工具設(shè)計和研究中文摘要本文討論了關(guān)于下一代網(wǎng)絡(luò)（NGN）的應(yīng)用開發(fā)的問題，它是基于SIP業(yè)務(wù)的開發(fā)，SIP（會話初始化協(xié)議）的開發(fā)目的是用來幫助提供跨越因特網(wǎng)的高級電話業(yè)務(wù)。本文設(shè)計了一個SIP呼處理的模擬器。開始描述了SIP基本術(shù)語，所需要的基本原理以及模擬器工具的系統(tǒng)架構(gòu)，并使用MFC開發(fā)出相關(guān)的界面

2、。接著對于呼處理的模塊設(shè)計，其需要兩部分完成，一個是SIP消息本身的解析模塊設(shè)計，另一個是SIP消息腳本的解析模塊設(shè)計。對于SIP消息本身的解析模塊設(shè)計，采用了按行的解析算法思想以及C+實現(xiàn)，和按字節(jié)的解析算法思想相比，即保證了消息的完整性又具有整體直觀性，也提高了程序的運行效率。而SIP消息腳本通過XML編寫，故是實現(xiàn)XML腳本的解析，此解析算法思想是采用串行解析技術(shù)，并通過形成鏈表和樹形結(jié)構(gòu)，完成對關(guān)鍵字的提取。此模擬器工具是在Window 使用Visual C+ 6.0來實現(xiàn)，在Winsock的編程原理基礎(chǔ)上，即客戶機-服務(wù)器的通信模式，采用改進的流套接字編程方法，實現(xiàn)SIP基本呼叫建立

3、過程。最后通過對此模擬器工具的進行了性能測試來說明其對驗證大量的準正常和異常case的效果。關(guān)鍵字：SIP消息、解析算法、呼處理 The development of simulative tool based on SIP professional work Abstract目 錄中文摘要IIAbstractIII第1章 緒論11.1 背景知識11.2 SIP協(xié)議簡介11.3 工具開發(fā)概要31.4 本文主要研究內(nèi)容3第2章 系統(tǒng)架構(gòu)及界面開發(fā)42.1 系統(tǒng)架構(gòu)42.2 主界面及子界面5第3章 SIP消息解析模塊設(shè)計93.1 SIP消息引言93.2 SIP消息解析策略及初步模型103.3 SI

4、P解析模型改進11第4章 XML腳本解析模塊設(shè)計134.1 解析技術(shù)134.2 腳本格式及特點134.3 腳本解析模型及特點17第5章 模擬器測試及結(jié)果分析195.1 模擬器呼叫模塊及結(jié)果195.2 性能測試及結(jié)果205.3 結(jié)果分析21結(jié)論21謝辭22參考文獻23IV第1章 緒論1.1 背景知識隨著VoIP（網(wǎng)絡(luò)電話）的迅猛發(fā)展，通訊技術(shù)數(shù)字化已成為現(xiàn)代通信技術(shù)的基本特征和最突出的發(fā)展趨勢。而網(wǎng)絡(luò)的下一個發(fā)展目標就是NGN，NGN是下一代網(wǎng)絡(luò)，又稱為次世代網(wǎng)絡(luò)，它使得新一代網(wǎng)絡(luò)上語音、視頻、數(shù)據(jù)等綜合業(yè)務(wù)成為了可能。而SIP協(xié)議是NGN中的重要協(xié)議，SIP稱為會話初始化協(xié)議，它的開發(fā)目的是用

5、來幫助提供跨越因特網(wǎng)的高級電話業(yè)務(wù)。因特網(wǎng)電話正在向一種正式的商業(yè)電話模式演進，SIP就是用來確保這種演進實現(xiàn)而需要的NGN序列協(xié)議中重要的一員。目前，單一的業(yè)務(wù)已經(jīng)無法滿足人們的需求了，而轉(zhuǎn)變?yōu)橐环N綜合的業(yè)務(wù)，它融合了文本數(shù)據(jù)業(yè)務(wù)、語音數(shù)據(jù)業(yè)務(wù)、多媒體視頻數(shù)據(jù)業(yè)務(wù)。為了建設(shè)投資小、效益高、可共享的網(wǎng)絡(luò)，以電話網(wǎng)為代表的電信網(wǎng)和以因特網(wǎng)為代表的數(shù)據(jù)網(wǎng)絡(luò)的互通和融合進程正在快速發(fā)展。加上以前被我們視為瓶頸的帶寬和服務(wù)質(zhì)量問題已得到解決，大大推動了 IP 技術(shù)的發(fā)展，帶動各種應(yīng)用向 IP靠攏。SIP (Session Initiation Protocol，會話初始協(xié)議)是由 IETF ( The

6、 Internet Engi2neering Task Force，互聯(lián)網(wǎng)工程任務(wù)組) 于1999 年提出的一個基于 IP 網(wǎng)絡(luò)的一種實時通信應(yīng)用信令協(xié)議1。因為 SIP協(xié)議具有Internet協(xié)議簡單、靈活、擴展性好等特點，目前已得到越來越廣泛的應(yīng)用。因此，對基于 SIP業(yè)務(wù)的應(yīng)用軟件工具進行相關(guān)的開發(fā)及測試也就十分重要。1.2 SIP協(xié)議簡介SIP（Session Initiation Protocol）會話初始協(xié)議是IETF制定的，用于多方多媒體的通信。SIP是一個基于文本的應(yīng)用層控制協(xié)議，獨立于底層傳輸協(xié)議TCP/UDP/SCTP，用于建立、修改和終止IP網(wǎng)上的雙方或者多方多媒體會話。

7、SIP協(xié)議借鑒了HTTP、SMTP等協(xié)議，支持代理、重定向及登記定位用戶等功能，支持用戶移動。通過與RTP/RTCP、SDP、RTSP等協(xié)議及DNS配合，SIP支持語音、視頻、數(shù)據(jù)、E-mail、狀態(tài)、IM、聊天、游戲等。SIP 可以用來對會話進行初始化, 也可以邀請成員加入經(jīng)其他手段建立或公布的會話。SIP 支持建立和終止多媒體通信方面的功能有：l 用戶端定位( user locat ion)：對在通信中使用的端系統(tǒng)的位置的確定。l 用戶能力( user capabilties)：決定在通信中要使用的媒體和媒體參數(shù)。l 用戶可行性( user availability )：確定被呼叫方是否愿

8、意加入通信。l 呼叫建立( call setup)：呼叫方和被呼叫方雙方建立呼叫參數(shù)。l 呼叫處理( call handling)：包括轉(zhuǎn)移和結(jié)束呼叫。SIP的終端系統(tǒng)稱為用戶代理（User Agent，簡稱UA），含用戶代理客戶機UAC（User Agent Client）以及用戶代理服務(wù)器UAS（User Agent Server）兩部分，呼叫過程即是UAC和UAS通信的過程。一個呼叫建立過程如圖1.1。用戶代理客戶端（UAC）用戶代理服務(wù)器（UAS）INVITE180200ACKBYE200圖1.1 SIP業(yè)務(wù)模擬器基本呼叫建立過程SIP協(xié)議把一個呼叫分為三個階段：呼叫建立，呼叫保持，呼

9、叫釋放。圖1.1所示的是一個呼叫建立的信令過程。首先要建立呼叫信令信道，即一個UDP或者TCP連接。則，由服務(wù)器的IP地址和端口號建立客戶端和服務(wù)器端之間的呼叫信令信道。然后，客戶端向服務(wù)器端發(fā)送INVITE消息，如果服務(wù)器端同意建立呼叫，發(fā)送180、200消息，其中180狀態(tài)碼表示請求已經(jīng)收到，正在處理中，200表示請求已經(jīng)成功。此時，如果客戶端突然不想?yún)⒓哟舜螘挘梢韵蚍?wù)器端發(fā)送BYE消息，此次呼叫結(jié)束；如果客戶端仍然想?yún)⒓哟舜螘?，就向服?wù)器端發(fā)送ACK消息，確認客戶端已經(jīng)收到了對INVITE請求的最終響應(yīng)(200)，經(jīng)過三次握手機制后，基本呼叫建立完成，進入呼叫保持階段。當(dāng)雙方通信

10、一段時間后，任何一方可以發(fā)送BYE消息來結(jié)束此次會話的呼叫。1.3 工具開發(fā)概要SipServer呼處理相關(guān)業(yè)務(wù)測試過程中需要驗證大量的準正常和異常case,這些case在設(shè)備正常呼叫過程中很難出現(xiàn)，測試的難度較大。需要一種測試業(yè)務(wù)模擬工具，它實現(xiàn)了UAC（用戶代理客戶端）功能，能夠根據(jù)用戶配置的腳本，自動生成相應(yīng)的呼叫流程，發(fā)送和接收相應(yīng)的SIP消息，并報告執(zhí)行結(jié)果。1.4 本文主要研究內(nèi)容很多的SIP測試工具器是基于DOS命令并在Linux下的，本文設(shè)計了一個在Windows下的SIP業(yè)務(wù)模擬器工具，是一個呼叫處理工具，該工具和DOS命令下的界面相比，更簡潔直觀，優(yōu)化了命令的傳輸形式。一開

11、始描述了系統(tǒng)構(gòu)架并完成相關(guān)的界面；其次研究了SIP消息解析模塊的設(shè)計，提出一中按行解析的新思路，而其編碼是基于擴展的巴基科范式（ABNF）2；而后對腳本解析的設(shè)計和實現(xiàn)，在原有的XML解析算法流程進行擴展，以達到滿足項目需求；最后通過Visual C+6.0 實現(xiàn)模擬器工具以及采用Winsock的原理實現(xiàn)基本呼叫的過程。最后一章通過實驗數(shù)據(jù)來表明該模擬器工具的性能。第2章 系統(tǒng)架構(gòu)及界面開發(fā)2.1 系統(tǒng)架構(gòu)數(shù)據(jù)對象腳本文件對象類Sip消息對象類配置參數(shù)對象類統(tǒng)計數(shù)據(jù)對象類。呼處理控制腳本解析呼處理控制Sip消息解析統(tǒng)計數(shù)據(jù)收集。界面和數(shù)據(jù)展示消息窗口統(tǒng)計窗口案例展示窗口配置窗口。 圖2.1 系

12、統(tǒng)架構(gòu)圖2.2 主界面及子界面 圖2.2 主界面圖2.2.1 工具欄工具欄上有4個功能按鈕，每個按鈕需求說明如下：1) Start test：啟動測試，默認狀態(tài)：disabled ，只有scenario被選擇，狀態(tài)才轉(zhuǎn)為enabled2) Stop test：停止測試，默認狀態(tài)：disabled，只有start test開始了，狀態(tài)才轉(zhuǎn)為enabled3) Select scenario：選擇測試方案，點擊后彈出文件選擇框，選擇 scenario，在Scenario window 顯示4) Option：設(shè)置測試選項，點擊后彈出測試選項對話框，完成后選項配置要保存到配置文件中。2.2.2 Sc

13、enario window情景窗口（圖2.3）需要實現(xiàn)的內(nèi)容為：1) 允許編輯，修改2) 提供右鍵彈出菜單，來保存用戶修改3) 腳本的格式參考sipp的腳本格式 圖2.3 情景窗口：顯示腳本內(nèi)容2.2.3 Message window消息窗口（圖2.4）需要實現(xiàn)的內(nèi)容為：1) 顯示當(dāng)前接收發(fā)送的消息2) 提供右鍵彈出菜單，來保存log功能 圖2.4 消息顯示窗口2.2.4 Statistic window統(tǒng)計窗口(圖2.5)顯示測試的統(tǒng)計信息：測試方案執(zhí)行次數(shù)，成功次數(shù)，失敗次數(shù)，預(yù)期消息，未預(yù)期的消息 圖2.5 消息統(tǒng)計窗口2.2.5 Option window軟件的運行參數(shù)配置如圖2.6：

14、該配置提供本地IP和本地端口以及遠程IP和遠程端口。 圖2.6軟件運行參數(shù)配置如下內(nèi)容將自動保存到配置文件中：Option.iniPRODUCT_INFOMultiCalls=1RIP=RPort=5060LIP=LPort=5060MaxCallNum=1000Log=1第3章 SIP消息解析模塊設(shè)計3.1 SIP消息引言SIP采用C/S結(jié)果的消息機制，分布式控制。SIP消息分為兩大類：從客戶端到服務(wù)器的請求（Request）和從服務(wù)器到客戶端的響應(yīng)（Response）。SIP基于HTTP，是一中文本型請求響應(yīng)吸引：客戶端發(fā)起請求，服務(wù)器端回送響應(yīng)。一次SIP事務(wù)

15、處理包括一個客戶端的請求、沒有多個臨時響應(yīng)，以及一個來自服務(wù)器端的最終響應(yīng)。SIP消息 = 開始行消息頭CRLF消息體開始行 = 請求行/狀態(tài)行 圖3.1 SIP消息格式圖3.1顯示了SIP消息格式，它以起始行開始，請求消息中稱為請求行，響應(yīng)消息中稱狀態(tài)行。起始行后面是一些標題區(qū)域，包括格式name：value以及一個空行將標題區(qū)域和可選信息實體分隔開。消息頭由域名和域值并加上中間的”:”組成的，例如：From：<sip:alice>。消息體由SDP消息構(gòu)成，SDP消息是文本信息，采用UTF-8編碼中的ISO10646字符集，但SIP消息中不一定都有SDP消息。一個由UAC發(fā)出的合

16、法SIP請求必須包含的最小頭字段如下：To，F(xiàn)rom，CSeq，Call-ID，Max-Forwards，Via所有這些頭字段在SIP請求中都是強制的。這六個域是構(gòu)成SIP消息的基本塊，它們聯(lián)合提供大多數(shù)的消息路由服務(wù)，包括消息尋址、響應(yīng)路由、限制消息傳播、消息定制、唯一性鑒定事務(wù)。這些頭字段還追加了一些強制請求行包括方法、請求地址、SIP版本。3.2 SIP消息解析策略及初步模型SIP消息是采用C+面向?qū)ο髞韺崿F(xiàn)的，根據(jù)C+面向?qū)ο蟮奶攸c，以及SIP協(xié)議自身的特點，提出了一種按行解析的新思路產(chǎn)生SIP協(xié)議棧來保存SIP消息。 按行解析式是相對于按字節(jié)解析的，一個字節(jié)、一個字節(jié)讀取時按照字節(jié)解

17、析的；而所謂按行解析，是把SIP消息中的每個行當(dāng)作一個整體來處理，通過逐行解析，來完成整個消息的解析。但是SIP消息每一行的格式和類型又是不盡相同，不可能用一個函數(shù)解析到底，針對這一點，結(jié)合C+語言的繼承性和多態(tài)性可以完全解決這個問題。繼承性使得能夠?qū)IP消息看作一個整體來對待，多態(tài)性則將其中請求消息與相應(yīng)消息的不同的細節(jié)問題解決得比較完善，通過建立在繼承性和多態(tài)性的基礎(chǔ)上，完成按行解析的過程。解析模塊完成兩大功能：第一是正向消息解析，完成文本（字符串）到協(xié)議規(guī)定的消息格式的轉(zhuǎn)換，主要是在接收消息時候調(diào)用。第二是逆向消息編碼，完成消息到字符串的轉(zhuǎn)換，主要在發(fā)送消息時候調(diào)用?；趩尉€程的解析模

18、型算法流程圖如圖3.1。解析起始行開始收到消息解析頭字段解析SIP版本號÷狀態(tài)碼和解釋信息解析請求方法÷請求URI和版本解析消息體SIP消息？消息體？ 結(jié)束圖3.1 SIP消息解析流程圖有是無否SIP消息解析算法描述：當(dāng)UA接收到一個SIP消息后，首先對字符串形式的消息進行整體的判斷和分解。當(dāng)對行結(jié)束符以及回車換行的識別，判斷消息是否合法。如果合法，再將消息分成三個部分分別進行判斷和解析。先是對開始行進行分析判斷，判斷收到的消息是請求還是響應(yīng)，而后對其進行解析，同時提取相關(guān)信息（SIP URI和版本號）；隨后對各個頭字段進行解析，提取相關(guān)信息；當(dāng)遇到空行（CRLF）后，調(diào)用

19、對消息體的解析函數(shù)；最后完成消息的解析。3.3 SIP解析模型改進在實現(xiàn)單線程解析的基礎(chǔ)上，采用ABNF語法規(guī)則2。我們可以設(shè)計一個多線程的消息處理模型來提高解析效率，即系統(tǒng)解析SIP消息時，可以同時從開始行、頭字段、消息體解析。在消息頭種類比較多時，可以快速匹配到對應(yīng)的消息頭解析函數(shù)。在詞法解析算法中3,標準LR算法是可以同時處理多個進程，系統(tǒng)可能會并行地存在幾組樹結(jié)構(gòu)棧，大大縮減計算量；在解析過程中采用共享子樹結(jié)構(gòu)來表現(xiàn)局部分析結(jié)果，節(jié)省空間開銷；通過節(jié)點合并，壓縮局部歧義。SIP消息解析時，解析模塊從輸入消息的句首順次“移入”SIP消息的開始行、頭字段、消息體，并根據(jù)語法中的重寫規(guī)則逐級

20、向上按條件“規(guī)約”，直到構(gòu)造出表示SIP消息結(jié)構(gòu)的整個推到樹。在移入和歸約過程中SIP信息以棧的形式存放，棧中存放解析過程的有關(guān)“歷史”信息，在解析時根據(jù)這些歷史信息和當(dāng)前正在處理的符合來決定究竟是移入還是歸約3。SIP算法解析過程：1) 從輸入消息的左端將一個未處理過的終結(jié)符移入棧頂，并等待更多的信息到了之后再做決定；2) 根據(jù)上下文無關(guān)語法的ABNF規(guī)則，用該規(guī)則左邊的符合來取代棧頂?shù)呐c規(guī)則右邊相匹配的符合；3) 對棧中符合和輸入符合串進行處理，輸入串處理完成，且棧中只剩下一個符號S，分析成功，然后結(jié)束；4) 若棧中并非只有一個符合S或者輸入的字符串中的符號沒有處理完成，也不能進行任何的規(guī)

21、約操作，分析失敗結(jié)束。SIP解析改進算法流程如圖4所示5。開 始輸入ABNF規(guī)則輸入SIP消息i = 1取第i個條件的信息電子詞典LR分析表i+按LR分析表處理，如果出現(xiàn)多種操作，啟動多線程是否出錯？是否接受？是否歸約？移 進打印出錯信 息打印出錯信 息輸出分析樹結(jié) 束合一算法生成子樹成功否？是否否否是是否是圖3.2 改進SIP解析算法流程圖第4章 XML腳本解析模塊設(shè)計4.1 解析技術(shù)XML解析技術(shù)分為串行解析技術(shù)和并行解析技術(shù)。其中串行解析技術(shù)是指解析XML文檔過程中采用單線程方式，即解析相關(guān)操作按照順序執(zhí)行的解析技術(shù)。而本文的XML解析模塊的設(shè)計采用串行解析技術(shù)的原理，在此基礎(chǔ)上通過基于

22、預(yù)處理技術(shù)，可以提高解析性能，同時可以保持應(yīng)用程序編程接口的兼容性。4.2 腳本格式及特點腳本實際上是一個sipp的xml配置文件，XML腳本不但提供了SIP消息本身，而且通過XML元素的屬性提供了對這些消息的處理控制信息，這些處理控制信息包括重傳時間、是否是必須的消息、及時開始和結(jié)束等。目前ph1階段我們只支持其中一部分功能，可以認為我們的腳本文件是sipp的一個子集。格式：所有的腳本都是以下方式開始<?xml version="1.0" encoding="UTF-8" ?><scenario name="Basic Si

23、pstone UAC">以</scenario>結(jié)束。一個客戶機（UAC）的腳本結(jié)構(gòu)內(nèi)容是以“send”關(guān)鍵字開始的，在“”和“”之間的內(nèi)容稱為關(guān)鍵字，如下： <send> <!CDATA INVITE sip:serviceremote_ip:remote_port SIP/2.0 Via: SIP/2.0/transport local_ip:local_port From: sipp <sip:sipplocal_ip:local_port>tag=call_number To: sut <sip:serviceremote

24、_ip:remote_port> Call-ID: call_id Cseq: 1 INVITE Contact: sip:sipplocal_ip:local_port Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: len v=0 o=user1 53655765 2353687637 IN IPlocal_ip_type local_ip s=- t=0 0 c=IN IPmedia_ip_type media_ip m=audio media_port

25、 RTP/AVP 0 a=rtpmap:0 PCMU/8000 > </send>一個服務(wù)器（UAS）的腳本結(jié)構(gòu)內(nèi)容如下：<recv response="100" optional = "true"> </recv> <send> <!CDATA SIP/2.0 180 Ringing last_Via: last_From: last_To:;tag=call_number last_Call-ID: last_CSeq: Contact: <sip:local_ip:local_por

26、t;transport=transport> Content-Length: 0 > </send>在“send”命令中，我們把SIP的消息封裝到“<!CDATA”和”>”標簽之間。在這兩個標簽里的內(nèi)容將會被發(fā)送到遠程系統(tǒng)。這些關(guān)鍵字是用來說明SIPp該做什么事情。關(guān)鍵字列表說明如表1： 表1 SIP消息關(guān)鍵字說明關(guān)鍵字默認值說明serviceservice服務(wù)字段，通過命令 s service_name傳遞remote_ip-遠程IP地址，通過命令行傳遞remote_port5060遠程IP端口，通過命令行傳遞。你可以增加一個已經(jīng)計算過的偏移量remote

27、_port + 3 來賦給這個值。transportUDP取決于t 參數(shù)的值，將獲得值“UDP”或者“TCP”local_ipPrimary host IP address獲得-i參數(shù)的值local_ip_type-取決于-i參數(shù)地址類型（IPv4或IPv6），local_ip_type 的值若是4則為IPv4，若為6則為IPv6local_portRandom獲得-p參數(shù)的值，你可以增加一個已經(jīng)經(jīng)過計算的偏移量(localport+3)賦給這個值。len-計算SIP消息體的長度。用在“Content-Length”字段中，你可以增加一個已經(jīng)經(jīng)過計算的偏移量(len+3) 賦給這個值。call

28、_number-索引。從1開始，每出現(xiàn)一個呼叫增加一。cseq-該值是自動生成的，初始值是1，可以通過使用-base_cseq命令行選擇來改變它。call_id-SIPp每一個新的呼叫就會產(chǎn)生一個call-id，一個這個值識別一個呼叫。在客戶模塊中，它通過SIPp中的Call-ID字段值的形成來強制使用。否者，由于成為一個已經(jīng)存在的呼叫的一部分使得SIPp無法識別該應(yīng)答哪一個消息的發(fā)送。注：call-id可以通過三斜杠字符串/來識別。如：Call-ID：ABCDEFGHIJ/call_id，則sipp仍然可以識別并當(dāng)作是同一個呼叫部分。media_ip-取決于-mi參數(shù)的值，它是本地IP地址對

29、RTP的回應(yīng)值。media_ip_type-取決于-mi參數(shù)的地址類型（IPv4或IPv6），media_ip_type 的值若是4則為IPv4，若為6則為IPv6media_port-取決于-mp參數(shù)的值，它設(shè)置了本地RTP回聲值。RTP/UDP包接收它們的發(fā)送者。你可以增加一個已經(jīng)經(jīng)過計算的偏移量(media_port +3) 賦給這個值。auto_media_port-僅使用在pcap中。從-mp參數(shù)的值開始來設(shè)置它的端口，使用含10000組建（為pcap_play限制10000個當(dāng)前RTP會話）的周期系統(tǒng)來改變每個呼叫。last_*-如果接收的消息是最后一個，則last_*關(guān)鍵字會被自

30、動的加到這個當(dāng)前消息的特定字段中（除了復(fù)傳送的消息外）。如果這個頭字段不是當(dāng)前的或者該消息已經(jīng)被接收，則該關(guān)鍵字被丟棄，且是值到最后一行的所有字節(jié)都會被丟棄。若一個消息中出現(xiàn)該頭字段多次，所有該情況連續(xù)使用last_*關(guān)鍵字來代替。field0-n-從外部CSV文件寫入該值。$n-用于寫入呼叫變量數(shù)n值。authentication-用于設(shè)置鑒別字段，該字段可以有參數(shù)，如下：authentication username=myusernamepassword=mypassword.如果username沒有提供，則從-s命令行參數(shù)中取得。如果password沒有提供，則從-ap命令行參數(shù)中取得。

31、pid-提供SIPp主線程的進程ID號routes-如果“rrs”屬性在recv命令中被設(shè)置成“true”，則接收消息中的“Record-Route”頭字段被存儲并可以使用該關(guān)鍵字進行重呼叫。next_url-如果“rrs”屬性在recv命令中被設(shè)置成“true”，則該字段含有Cantact字段的文本內(nèi)容（該內(nèi)容在Cantact中使用<和>包含）。branch-提供一個分支值，它在情景中由一串z9hG4bK+呼叫數(shù)+消息索引組成。msg_index-為情景提供消息數(shù)量cseq-提供最后請求接收的CSeq值。這個值可以增大（如：cseq+1，為最后請求的CSeq值增一）。在XML腳本

32、中，元素的屬性表示對此消息的處理控制的方法。例如：optional屬性說明這個消息是否是必需的。XML的CDATA部分表示了SIP消息的一個框架，可以看到在方括號中的內(nèi)容代表了一個變量，這些變量由用戶配置文件中給出，如remote_ip、local_ip、transport等，或者由模擬器工具自己生成，如call_id、call_number、tag等。通過這種方式，用戶可以方便地編寫出針對某類系統(tǒng)具有普遍適用性的測試實例。4.3 腳本解析模型及特點4.3.1 串行解析技術(shù) 根據(jù)對XML實例進行驗證的模式，可以將串行解析技術(shù)進一步分為獨立解析和解析與驗證集兩種解析模式。獨立解析的模式指將解析過

33、程與驗證過程彼此獨立、驗證過程處于解析過程之后的處理模式。文檔對象模型DOM6是獨立解析模式的一種，是W3C推薦的一種獨立于語言和平臺的標準，并且是一種基于樹型的解析技術(shù)，其目標是提供一個可以通用于各種程序語言、操作系統(tǒng)和應(yīng)用程序的編程接口。DOM模型在解析XML文檔時先將整個XML文檔掃描一遍，得到獨立的元素、屬性和注釋等然后以節(jié)點樹的形式在內(nèi)存中創(chuàng)建XML文檔的表示，是以層次結(jié)構(gòu)組織的節(jié)點或信息片段的集合，每個節(jié)點代表一個可以與之交互的對象，用戶可以通過結(jié)點樹訪問文檔內(nèi)容。 此模型的優(yōu)點是在內(nèi)存中保留整個文檔的所有信息，用戶可以隨意訪問任意位置的節(jié)點信息或是對之進行修改，開發(fā)人員可以方便編

34、寫程序。4.3.2 解析模型描述在串行技術(shù)的基礎(chǔ)上，又根據(jù)SIP腳本的內(nèi)容特點，對有些特定的字符串進行預(yù)處理，預(yù)過濾技術(shù)根據(jù)一定的規(guī)則、機制，在解析之前對XML文檔進行預(yù)處理，將用戶真正需要的部分過濾出來然后執(zhí)行解析，從而降低了解析的工作量，提高了解析的性能。在解析XML文檔DOM解析技術(shù)的基礎(chǔ)上，采用C+面向?qū)ο蟮姆椒▽崿F(xiàn)對XML的解析，其定義了一系列的對象和方法對DOM樹的節(jié)點進行各種隨機操作：1) CXmlDocument對象：作為樹的最高節(jié)點，是解析XML文檔的入口。2) CXmlAttrList對象和CXmlAttrElement對象：這些節(jié)點對象都是文檔某一部分的映射，節(jié)點的定級層

35、次恰好反映了文檔的結(jié)構(gòu)。3) CXmlNode對象是節(jié)點類，用于保存信息；而CXmlUtil對象是內(nèi)部轉(zhuǎn)換封裝類，用于對有用信息轉(zhuǎn)換。以下描述在解析過程中對節(jié)點和屬性的遍歷，先獲取腳本的內(nèi)容：在解析過程中，腳本文件的內(nèi)容通過節(jié)點的遍歷會保存到子節(jié)點的標簽值中，則可以先獲得根節(jié)點的地址，在找出相應(yīng)的子節(jié)點的地址，最后通過子節(jié)點中的GetTagValue()獲取腳本的內(nèi)容。在遍歷xml的節(jié)點：通過解析，可以生成根節(jié)點，而根節(jié)點下會有相應(yīng)的子節(jié)點,通過循環(huán)會生成子節(jié)點鏈表；故可以通過定義根節(jié)點，找到子節(jié)點的頭節(jié)點，再通過鏈表的遍歷，尋找出相應(yīng)的節(jié)點。最后可獲取xml的屬性值：解析過程中，通過CXml

36、AttrElement類的SetAttrName()和SetAttrValue()來保存相應(yīng)的屬性，若成功，則會通過CXmlAttrList:AddAttrElement()函數(shù)添加到屬性鏈表中，故可以在節(jié)點下的屬性鏈表中獲取相應(yīng)元素屬性的地址，從而可以獲取屬性值。 對得到的屬性和屬性值進行擴展解析，與滿足用戶的需求，由于SIP消息是封包在“<!CDATA”和“>”之間，故需要獲得相關(guān)的值，再進行對其進一步解析，由UAC結(jié)構(gòu)中可知我們需要提取的是關(guān)鍵字，因關(guān)鍵字的特殊性，可采用按字節(jié)解析的算法對其進行提取。XML解析算法過程如下：1) 輸入XML文檔內(nèi)容；2) 進行預(yù)處理，取得用戶

37、所需要的信息；3) 解析開始部分內(nèi)容，得到版本號和編碼代號，如果失敗，則結(jié)束，否則進入下一步；4) 進行子內(nèi)容的解析，通過調(diào)用接口函數(shù)可獲得XML的節(jié)點和XML屬性值；5) 判斷是否有下一個字內(nèi)容，若有則返回上一步，否則結(jié)束。解析模型流程如圖4.1：輸入腳本內(nèi)容開始解析版本號和編碼成功？解析消息內(nèi)容子消息？結(jié)束有無是否圖4.1 XML解析算法流程圖預(yù)處理第5章 模擬器測試及結(jié)果分析5.1 模擬器呼叫模塊及結(jié)果此模擬器呼叫是單路呼叫，單路呼叫的運行線程模擬一個SIP用戶代理，單路呼叫模塊既可以動態(tài)配置成UAC，也可以配置成UAS，通過SIP服務(wù)器與其它的SIP用戶代理進行會話。與真正的用戶代理不

38、同，單路呼叫模塊只進行會話的信令交換，不進行真實的會話媒體流的交換。單路呼叫模塊的結(jié)構(gòu)如圖5.1,由呼處理控制和SIP消息解編碼器兩個子模塊組成。呼處理控制SIP呼叫信息解碼編碼解編碼器圖5.1 模擬器呼叫模塊moni呼叫處理控制子模塊根據(jù)單路呼叫模塊的運行線程在會話扮演的角色是UAS還是UAC，通過選擇相應(yīng)的呼叫流程對呼叫進行控制，此模擬器只支持典型流程的呼叫。預(yù)期每次呼叫，都會有一定數(shù)量的準正常和異常case，其指標由呼叫失敗率和忙時最高呼處理能力BHCA（Busy Hour Call Attempt）值等來說明。通過呼叫測試獲得的統(tǒng)計信息如表2所示。序號總呼叫次數(shù)成功呼叫次數(shù)失敗呼叫次數(shù)

39、BHCA(次/秒)失敗率110000800020002736020%27000600010002862014%3500042507502146015%440003600400956010%5.2 性能測試及結(jié)果通過SIP業(yè)務(wù)模擬器對SIP服務(wù)器性能的測試，是模擬通話高峰時的情況，對SIP服務(wù)器施加話務(wù)壓力，監(jiān)測SIP服務(wù)器此時的性能，而性能指標一般包括呼叫高峰時呼損率和忙時最高呼處理能力BHCA（Busy Hour Call Attempt）值等。測試的目標是監(jiān)測SIP模擬器工具實現(xiàn)的BHCA值，呼叫高峰時呼損率，以及支持并發(fā)呼叫的能力。該軟交換設(shè)備的預(yù)期性能是BHCA大于140萬，呼叫高峰時

40、呼損率小于0.0034%，每秒鐘至少能夠同時支持200路并發(fā)呼叫。首先測試單臺PC作為呼叫器實施業(yè)務(wù)壓力的能力，單個呼叫器在30路并發(fā)時每小時能夠?qū)浗粨Q成功呼叫33萬次。在實際的測試環(huán)境中利用1臺PC作為控制器，10臺PC作為呼叫器，這樣能夠確保測試系統(tǒng)本身能夠達到測試必需的性能。在測試中對軟交換四次呼叫，每次總呼叫次數(shù)為100萬，并發(fā)路數(shù)的依次為100,150,200,250，測試運行結(jié)果如表3所示。 表3 SipServer呼處理測試結(jié)果序號并發(fā)路數(shù) 單路呼叫次數(shù)時間(s)BHCA(次/小時)失敗數(shù)(呼損率)1100=10×10100002442148萬43(0.004%)2150=10×1566672363152萬125(0.01%)3200=10×2050003084117萬4285(0.4%)4250=10×254000593961 萬74356(7.4%)5.3 結(jié)果分析從表3 可以看出，在100路到150路并發(fā)的情況下，BHCA值大于140萬和呼損率小于0.0034%，待測系統(tǒng)的性能超過預(yù)期要求的性能。但是并發(fā)的路數(shù)增加達到200 路和250 路時，軟交換的性能指標下降，不能達到預(yù)期性能，并隨著并發(fā)路數(shù)增加