無線區域網路之軟式電話系統的研究與設計
A Research and Design for Soft Phone Systems in Wireless LANs
韓鑫偉
2葉生正
1*詹凱富
1 1銘傳大學 資訊傳播工程學系
2銘傳大學 資訊傳播工程研究所
*桃園縣 333 龜山鄉大同村德明路 5 號
*peteryeh@mcu.edu.tw
摘要
本論文於 IEEE 802.11 無線區域網路環境中， 以目前看來應在未來異質網路間成為共同連線訊 號標準的 SIP 協定為基礎，進行視訊軟式電話系統 的研究與開發。其研究結果顯示，本論文所研發的 系統在多流量競爭情況下，仍可維持一定程度的語 音通話和視訊傳輸之服務品質，且亦整合了文字訊 息的交談服務。另外，本研究也與其它以 SIP 為基 礎的軟式電話系統進行互通性測試，結果無論是發 話或受話的測試皆能成功地建立語音的連線通話。 關鍵詞：無 線 區 域 網 路 、 SIP、 VoIP、 RTP、 軟 式電話。Abstract
This paper provides a research and
development of the video soft phone system based on IEEE 802.11 WLANs. Moreover, it applies the potential networks signaling standard
called SIP. The paper also shows that as
competing with other traffic flows, the integrated voice, video, and message data transmission could still afford acceptable QoS. Additionally,
the proposed system could successfully
interoperate with the other SIP soft phones passing through the calling and callee test.
Keywords: WLAN、SIP、VoIP、RTP、Soft phone.
本研究中採用了 SIP 做為整個連線訊號的通訊 基礎。一方面藉由 SIP 制定的管理機制來提供 VoIP 用戶間連線訊號傳遞的服務；另一方面，藉由 SIP 較為簡單的連線訊號處理架構，提升建立多媒體服 務連線的效率。更希望能與各種已採用 SIP 協定開 發的通訊設備，無論是硬體或軟體形式的網路電話 嘗試建立良好的互通性。 綜上所述，如何在無線區域網路現有的架構之 下，不以高階的設備為開發平台，而以現有普及且 容易取得的通訊設備，整合並實現 VoIP 系統的應 用與互通性，並提供順暢的語音、視訊及文字訊息 的交談服務，便是本研究論文的重點。 本論文的 Section 2 將會探討相關的協定與技 術，其中包含連線訊號基礎 SIP 協定的介紹，並闡 述音訊傳輸所使用的即時傳輸協定(RTP)，以及歸納 分析 VoIP 視訊電話的相關技術。Section 3 則對本 研究論文的系統架構、研究方法與研究成果等詳細 敘述。Section 4 將進行本論文研發之視訊電話系統 的效能分析與討論。最後是提出本研究的結論與未 來相關議題之展望。
2.相關的協定與技術
2.1 SIP(Session Initial Protocol)協定
SIP 協 定 是 由 IETF(Internet Engineering Task Force)在1999年所制訂，基本上為一規範建立、定 義、終結多媒體連線的通訊協定，且SIP只負責將連 線建立起來，之後看個人的需求去實作需要的連線 內容。又因為SIP僅搭建需要的多媒體連線，並沒有 定義後續的媒體傳輸，故SIP 可以支援網際網路多 媒體、多方會談、電話、訊息傳遞亦或遊戲等服務。 另外，SIP被認為是一種輕量級協議，因為SIP使用 的是能被終端設備輕易生成並分析的簡單文本命 令，即單純的文字訊息架構，並僅使用6個指令進 行管理與控制資訊[4][5]。 SIP 主要邏輯元件分為兩個群體，如圖 1 所示， 用戶端代理元件(User Agents)與伺服器(Servers)。 圖1 SIP 邏輯元件概念圖
其中 User Agent 指的是以 SIP 為基礎的用戶端
Registrar & Redirect Server Proxy Server UAC Proxy Server Registrar & Redirect Server UAS Q u e r y Q u e r y RTP Media Stream :SIP SIGNAL
代理元件。在 VoIP 的領域裡可以是軟體形式的 SoftPhone，也可以是有電話外觀的 HardPhone。而 User Agent 又細分為客戶端使用者(UAC)與伺服器 端使用者(UAS)兩個元件。定義上，UAC 指的是啟 始連線的一方，也就是發話端；相對的，UAS 則是 受話端。 Servers 就是伺服器。SIP 伺服器基本分為代理 伺服器(Proxy Server)、重新導向伺服器(Redirect Server)與註冊伺服器(Registrar)三種。 SIP 控制訊息以類似 HTTP 訊息的文字格式傳 遞，文字訊息比較簡單明瞭，但相對的是必須使用 較多的頻寬。SIP 控制訊息的基本格式為: message = Start-line *message-header CRLF
[message-body]
其中 Start-line = Request-line | Status-line 。 從 SIP 控 制 訊 息 的 格 式 中 可 以 發 現 ， 在 Start-line 中就記載著 SIP 控制訊息的類型，基本的 SIP 控制訊息分為要求(Request)與回應(Response)兩 種(回應以 Status-line 表示)。而 message-header 中則 記載著有關於 Request 或 Response 訊息的附加資 訊，例如發話者與受話者的名稱與位置、負責轉送 此訊息的代理伺服器、此訊息的 message-body 類型 描述等資料。至於 message-body 則記載著此次建立 的連線類型描述。最常見的 message-body 結構是使 用 SDP(Session Description Protocol)[6]，而這個部 分的訊息只有被真正連線的節點所使用。 Request 類型中包含了六種方法(method)，其用 途如表 1 所示。 表 1 SIP Request 的六種方法 INVITE 發起一個 session ACK 回應一個 request，確認收到訊息 BYE 結束連線 CANCEL 結束一個尚未得到回應的 request REGISTER 用戶端向 Registrar 註冊 OPTIONS 查詢 server 相關訊息及功能 除了上述六種之外，在其他的 RFC 中還有定義 擴充的方法，例如可以在連線已建立的狀態下傳送 資訊的 INFO 方法；控制訊息的 message-body 中放 入 實 際 要 傳 給 對 方 的 文 字 而 不 是 SDP 訊 息 的 MESSAGE 方法等等[3]。 Response 類型中，定義了六個類別的狀態碼 (status code)，如表 2 所示。Status code 由三位元的 數字組成，在這六個類別中，除了 1xx 開頭的類別 是屬於 Provisional Response(暫時的)，其餘都是 Final Response(最終的)，其差異在於 Final Response 送出後需要等待對方回傳 ACK 做確認。 表 2 SIP 的狀態碼說明 狀態碼 主要的意義說明 1xx 暫時的回應(Provisional) 收到 request，並繼續處理 request 2xx 成功的回應(Final) 表示動作已完成執行 3xx 轉向的回應(Redirect) 表示訊息需要轉向、轉送 4xx 用戶端失敗的回應(Client Error) 代表用戶端發出不正確或 server 無 法理解的訊息 5xx 伺服器端失敗的回應(Server Error) 代表訊息正確但伺服器端無法處 理，請找別台伺服器 6xx 完全失敗的回應(Global Error) 代表任何伺服器都無法處理此訊息
2.2 即 時 傳 輸 協 定 (Real-time Transport
Protocol, RTP)
RTP 是由 IETF 在 RFC 1889 中制訂，是一傳輸 影像及聲音資料使用的通訊協定。在 VoIP 應用中， 由於 SIP 只負責建立連線，在 SIP 建立完連線之後， 便以 RTP 做語音及影像資料的傳輸。RTP 是架構 在 UDP/IP 上傳送的，與其他協定的關係如圖 2-2 所示。在本研究中音訊傳輸的部分即採用 RTP。在 本研究系統成功建立連線之後，使用者即可以 RTP 連線做即時的語音傳輸[2]。 圖 2 RTP protocol stack RTP 的 主 要 特 色 為 使 用 序 列 號 碼 (Sequence Number)與時間標記(Time Stamp)，茲說明如下: 1) 序列號碼 在大多數傳輸即時影音資料的場合，對資料即 時性要求比正確性高，因為當發現資料錯誤時，新 資料早已接踵而至。所以一般會選擇使用 UDP 而 非 TCP。UDP 不做確認及重傳的特性減少了延遲， 但帶來另一個問題：使用 UDP 不保證接受端能否 依序接收到封包。為解決此問題，使用提供序列號 碼資訊的 RTP 封包來補 UDP 的不足，透過序列號 碼接收方即可核對封包的順序。 2) 時間標記 一個多媒體的連線建立後，有可能需要同時傳 輸多重的資料串流，但多重串流是彼此獨立傳輸 IP UDP RTP SIP的，此時透過時間標記就可達成多重串流的同步控 制，解決不同步的問題。 但僅有 RTP 的應用並未完全解決網路服務品 質(QoS)的問題，故 RTP 控制協定(RTP Control Protocol, RTCP)便因應而生。RTCP 是相伴著 RTP 的協定，只有在 RTP 連線開啟之後才能使用。且 RTCP 於連線的用戶端間負責提供例如封包遺失 率、延遲等網路效能之相關資訊。所以 RTCP 提供 的資訊可讓使用者適性地調整影音壓縮的比率，或 其它可以符合目前通訊網路 QoS 需求的設定。 RTCP 在使用上應控制在整體連線頻寬的一小 部分，因為過多的 RTCP 封包反而會佔據原本資料 傳輸所使用的頻寬，但相對地也不應太少而導致不 足以進行即時的 QoS 控制。
2.3 語音傳輸技術
VoIP 的基本運作原理是將原本的類比聲音訊 號，透過設備轉換成 IP 封包，在 IP 網路上載送， 再傳到對方的設備中還原回原本的類比音訊。VoIP 標 準 的 音 訊 壓 縮 編 碼 技 術 目 前 以 ITU-T 標 準 G.711、G.723、G.729 為主，大部分的 VoIP 應用都 支援這三種壓縮編碼方式，其中壓縮比率越高的方 式，使用的頻寬越小，但相對其編解碼花費時間越 長，其編碼方式與延遲的關係如表 3 所示[9]。 表 3 主要語音編碼規格 參數 編碼方式 Bits rate （K bps） 編碼延遲 時間（ms） G.711 64 0.75 G.723.1(5.3K) 5.3 30 G.723.1(6.3K) 6.3 30 G.729 8 103.以 SIP 為基礎的軟式電話系統開發
在此將詳述本研究論文開發之網路視訊電話 系統，其包括系統平台之架構、SIP 用戶端代理(User Agent)軟體介面與 SIP 伺服器的開發方法與步驟， 以及其運作方式與功能。最後並闡述量測系統效能 所使用的工具與方法。3.1 系統架構與裝置
本系統的基本研究平台，以 IEEE802.11 a/b/g 無線存取站(Access Point, AP)為基地台，並以有線 方式連結 SIP 伺服器，無線方式連結用戶端裝置， 系統架構如圖 3 所示。圖 3 系統架構示意圖
本研究以筆記型電腦搭配支援 IEEE 802.11 a/b/g 等規格的 PCMCIA 無線網路卡做為 User Agent 的行動裝置，採用 CCD 攝影機來擷取影像，並以 耳機麥克風進行錄放音的工作以降低回音(Echo)效 應。
3.2 SIP 用戶端代理軟體
本研究的 User Agent 介面採用 Borland C++ Builder 來設計開發，如圖 4 和圖 5 所示。其區分 為兩個主頁面，一為 SIP 連線訊息使用的介面，包 含登入、建立連線、接受連線、結束連線等功能。 二為連線建立後，傳送接收語音、影像、文字等多 媒體交談的使用者介面。接下來將分別敘述處理連 線訊號、語音傳輸、影像與文字訊息傳輸的研究方 法。 圖 4 連線介面 圖 5 交談介面 1) 處理連線訊號 電話的用戶端在撥打電話前，並無法得知對方 的正確所在位址，此時雙方的連線訊息，就必須透 過中介者來轉送。在傳統的 PSTN 電話系統中是透 過電信局的局端設備來做轉送；但在網路電話系統 中，是透過架構在使用者網路中間的伺服器來完成 轉送的工作。且在此建立通話的步驟中，SIP 協定 是以文字模式的訊息傳送來完成。而本研究系統之 用戶端代理軟體(UA)與伺服器的註冊與連線建立 等行為，皆依循 SIP 協定所制訂的標準格式開發， 其流程如圖 6 所示。
圖 6 SIP 呼叫流程 首先 UA 必須先能發送註冊以及建立連線的訊 息，並能針對 SIP 伺服器或其它 UA 發出的 SIP 訊 息，作出適當的回應。所以 UA 在 SIP 訊息部分的 開發重點在於發送 SIP 訊息以及正確解碼收到的訊 息，並作出回應。 表 5 即為在本研究系統中 SIP UA 建立一成功 連線時，所使用的相關基本 SIP 訊息的處理流程說 明。首先 UA 登入伺服器，讓伺服器知道使用者已 上線，並記錄使用者位置資訊，經過此一登入動作 後 UA 便可以開始啟始連線要求，並透過伺服器的 轉送將訊息傳遞到另一 UA。對方如接受連線要求 便回應訊息，並且等待啟始連線的一方做確認。直 到收到確認訊息後，連線才算建立。若其中一方欲 終止連線時，便發出終止訊息並等待回應，接著， 就完成中斷連線的程序。 SIP 訊息內需要本機 IP 位址、伺服器 IP 位址 與使用者帳號等三個欄位。本機 IP 位址欄位由軟體 啟動時以 BCB 的 PowerSock 元件向作業系統查詢 取得，使適用於由 DHCP 伺服器動態配發 IP 位址 的網路環境。剩下兩個欄位則由使用者自行輸入。 傳送與接收 SIP 訊息時，以 BCB 提供之 NMUDP 元件實作完成，並且使用 SIP 設定的 5060 通訊埠。 由於 SIP 是以文字形式傳輸，在 SIP 訊息封裝上直 接以字串方式處理。 表 5 基本 SIP 連線訊息交換流程 SIP 訊息 發出/接受 下一動作 期待回應 REGISTER 發出 INVITE 或無 OK INVITE 發出 若 成 功發 送 ACK Trying/ Ringing INVITE 接受 RINGING and OK ACK BYE 發出 無 OK BYE 接受 OK 無 2) 語音傳輸 本研究系統的語音傳輸部分以 RTP 協定並應 用 Vovida 的 WinRTP 元件開發[10]。本地端 UA 的 語音在透過標準 CODEC 處理後，封裝為 RTP 封 包，再經由指定的 RTP 通訊埠傳送語音封包到另一 個 UA 端。同時，本地端 UA 亦將對方傳來的語音 封包接收存入緩衝區內並播放出來。 WinRTP 是由 Vovida 組織提供的開放原始碼元 件，是由 C++程式語言編寫而成，並且包裝為容易 呼叫的 COM 介面元件。故本研究系統的語音傳輸 主要將錄放音、編解碼、RTP 封裝等語音訊號處理 程序透過 WinRTP 元件來完成。即令錄音傳送與接 收放音分為兩個獨立的模組，以表 6 所列方式完成 WinRTP 函數的呼叫。其首先必須先啟始化 WinRTP 物件，接著經由傳入參數的方式設定接收模組的通 訊埠號、使用的 Codec 種類與傳輸週期等。傳送模 組亦透過相同的方式設定上述參數與對方的 IP 位 址。參數設定完成後即可藉由開始傳送與開始接收 兩指令啟始 RTP 語音交談。另外，因為傳送與接收 模組獨立，可設定 UA 僅具備傳送或接收之單一功 能。 表 6 WinRTP 元件函數呼叫方式 函數名稱 功能 Initialize() 啟始化 WinRTP 物件 SetAudioCodecRx() 設定接收端 Codec 類型 與傳輸週期 SetAudioReceivePort() 設定接收端接收埠號 SetAudioCodexTx() 設定傳送端 Codec 類型 與傳輸週期 SetAudioDestination() 設定接收端 IP 位址與 埠號 StartRx() 開始接收並放音 StartTx() 開始錄音並傳送 SetSpeakerVolume() 設定揚聲器音量 SetMicrophoneVolume() 設定麥克風音量 StopRx() 停止接收與放音 StopTx() 停止錄音與傳送 UnInitialize() 結束 WinRTP 物件使用 3) 視訊與文字傳輸 本研究系統以單張影像連續傳送的方式來實 現視訊傳輸的功能，如圖 7 所示。在基本實作方法 上，先經由 Windows 的 VFW 函式庫驅動 CCD 並 呈現本地端之預覽畫面，再以 BCB 之 Timer 元件控 制 CCD 擷取單張影像。至於擷取後之影像資料則 透過標準 JPEG 壓縮法，將 160*120 像素大小的影
像壓縮到約 5 Kbytes 大小，並封裝成 UDP 資料封 包。UDP 傳輸使用 BCB 的 NMUDP 元件完成，在 雙方成功建立連線後，經由 SIP 訊息內的 Contact Address 設定對方的 IP 位址，並由預設之通訊埠傳 送出去。等到接收端收到 UDP 封包後，再將封包 內之影像資料以 BCB 的 PaintBox 元件，呈現在操 作介面上。 至於文字訊息傳輸部分在此以 TCP 方式進 行，即利用 BCB Winsock 元件中的 ServerSocket 與 ClientSocket 元件來達成。基本上，當雙方透過 SIP 建立連線後，同樣可藉由 SIP 訊息內之 Contact Address 設定 ClientSocket 的目的端 IP 位址，並設 定 ServerSocket 為監聽(listen)狀態後，便可隨時雙 向傳輸文字訊息，其實作結果如圖 8 所示。 圖 7 影像傳輸介面 圖 8 文字傳輸介面
3.3 SIP 伺服器的架設與安裝
本研究系統之 SIP 伺服器主要是應用 IPTEL 開 發的 SIP Express Router (SER)套裝程式[7]。SER 依 循著 SIP 標準開發，可設定為 SIP 代理伺服器、重 新導向伺服器與轉址伺服器，亦可結合資料庫來執 行完整的使用者身份認證。SER 是以 C 程式語言 所編寫的自由軟體(Freeware)，適用在 BSD、Linux、 Solaris 等 Unix-like 作業系統平台。而且 SER 與市 場上多家 SIP 軟體公司提供的 SIP UA，其彼此間 執行效率與互通性良好。本研究系統之伺服器平台 採用 Fedora Core4 版本之 Linux 作業系統，並安裝 設定對應的 SER 版本，且利用 MySql 登錄與查閱 使用者之連線狀態。因為 SER 以套件形式發佈，各 Linux 平台有其對應的套件版本，所以基本上安裝 完成後，在終端機視窗鍵入 SER 即可啟動伺服器服 務，並能在伺服器的網路介面上監聽 SIP 訊息4.系統效能分析與探討
在此將對本研究開發之視訊電話系統的效能 以實測方式進行分析與評估。4.1 節探討本研究系 統架構下，無線區域網路使用者彼此通訊間的相互 影響。4.2 節則進行本研究系統與其他 SIP 軟式電 話系統的互通性測試。4.1 在競爭下之語音傳輸效能
在本研究系統架構下，無線網路服務使用者皆 透過無線網路存取點進行連線，本節探討無線網路 服務使用者經由存取點傳輸所產生的競爭對於語 音傳輸效能的影響。並根據本系統架構，規劃出以 下四種實驗情境: Scenario1:一 AP 底下有兩名使用者。 Scenario2:一 AP 底下有四名使用者。 Scenario3:兩 AP 底下各有一名使用者。 Scenario4:兩 AP 底下各有兩名使用者。 實驗結果如圖 9 所示，以固定相同節點所接收 到的 RTP 語音封包進行平均延遲變異量(Jitter)的評 估分析，其中四個情境下都沒有封包遺失的情形發 生。且結果顯示在橫跨兩個 AP 傳輸的實驗情境下 (Scenario3、4)，其平均延遲變異量皆較在單一 AP 下傳輸(Scenario 1、2)為高。但在 AP 未更動且節點 數增加的情境下(Scenario2、4)，其平均延遲變異量 亦會隨之提升。故測量結果驗證在無線區域網路服 務節點增加時，即使 IEEE 802.11 無線區域網路採 用 CSMA/CA 的 MAC 協定，但仍無法完全排除碰 撞的現象發生，且在橫跨 AP 進行傳輸的情形下， 其產生的延遲變異程度更高。 各Scenario之平均延遲變異量 0.467197 0.931606 0.954583 1.088175 0 0.2 0.4 0.6 0.8 1 1.2Scenario1 Scenario2 Scenario3 scenario4
jitter(ms)
圖 9 各 Scenario 下語音封包之平均延遲變異量
4.2 互通性測試
本研究系統採用 SIP 為連線訊號基礎開發，為 測試其開發的完整度，採用工研院電通所以 SIP 為 基礎開發的 CCL PCA Soft Phone 用戶端代理軟體 (以下稱 CCL PCA)以及 Xten 公司開發的免費 SIP 用戶端代理軟體 X-Lite 與本系統研究開發的 SIP 用 戶端代理軟體做互通性測試 [1] [11]。測試分別以 本研究系統做為發話方與受話方進行，並觀察受話 方在響鈴、來電辨識、接聽來電後回應、語音連線 等項目是否工作正常，其測試結果如下:
1) 受話測試 個別以 CCL PCA 和 X-Lite 網路電話系統為發 話方，本研究系統為受話方進行測試。測試結果如 表 7 所示，本系統在四個測試項目中皆工作正常， 都能成功地建立通話連線。 表 7 受話測試結果 結果(O/X) 測試項目 CCL PCA X-Lite 響鈴 O O 來電辨識 O O 接聽後回應 O O 語音連線 O O 2) 發話測試
在發話測試同樣與 CCL PCA Soft phone 及 X-Lite 兩軟體進行互通測試，由本研究系統做為發 話方，觀察兩軟體在測試項目的表現。測試結果如 表 8 所示，本研究系統做為發話方時與兩軟體在四 個測試項目上亦工作正常且連線正確建立。 表 8 發話測試結果 結果(O/X) 測試項目 CCL PCA X-Lite 響鈴 O O 來電辨識 O O 接聽後回應 O O 語音連線 O O 本研究系統在互通性測試上與 CCL PCA 及 X-Lite 系統之測試結果良好，且與本系統的 SIP 連 線訊號皆能透過 SIP 伺服器的正確進行轉送，並成 功地建立語音的連線通話。
5.結論與未來展望
現今市面上已有販售標榜可支援 Skype 無線網 路語音通訊服務的 PDA 行動裝置，以及兼具 IEEE 802.11 無線區域網路功能與 GSM 行動電話服務的 雙模手機問世。再加上國內五家電信業者陸續推展 的 3G 行動寬頻服務，這些訊息透露出一個高頻寬 的無線服務世代的來臨，人們在遠距的訊息溝通上 也即將邁入一個新的紀元。但首當其衝的便是多媒 體整合服務與異質網路互通性的問題，故本研究論 文的目的即在無線區域網路環境下，進行視訊、語 音與文字等多媒體傳輸服務的整合系統開發，並以 未來訊號控制標準 SIP 協定為基礎，透過 SER 伺服 器提供用戶端建立連線，達成視訊、語音與文字訊 息得以在 WLAN 環境中整合傳輸，並能與其他以 SIP 為基礎的網路電話系統有良好的互通性。 本研究系統的語音傳輸效能表現在多流量競 爭之下，仍可維持一定程度的通訊品質。而視訊傳 輸效能方面，亦提供不致於犧牲太多解析度仍具流 暢度的傳輸品質；但以單張影像傳輸方式並不能與 其它的標準相容。未來應以通用的壓縮技術，如 MPEG4 壓縮標準，並以 RTP 方式來達成視訊傳輸 的互通性。另外，本研究論文在 SIP 控制訊號互通 性的測試分析方面，與受測的軟式電話系統 CCL PCA 及 X-Lite 互通性良好，實現了 SIP 協定成為網 路共同連線標準的精神。並由於 SIP 是一適用於異 質網路的通訊協定，未來期望能與以 SIP 為基礎的 硬式通訊設備( SIP Hard phone)測試其互通性。同 時，建議 Signaling 訊息的包裝及處理程序應採用制 式的 SIP library 開發，才能完成更高的相容性[8]。 面對未來一個嶄新的無線通訊世代，相信在有 更高的傳輸頻寬之後，除了提供高傳真的多媒體整 合服務品質之外，更要能帶給使用者具互通性、加 值性、娛樂性和實用性的便利與效率。參考文獻
[1] 工 研 院 電 腦 與 通 訊 研 究 所 ， http://www.ccl.itri.org.tw/[2] H. Schulzrinne, S. Casner, R. Frederick , V. Jacobson, “RTP:A Transport Protocol for
Real-Time Applications,” RFC 1889, IETF,
January 1996.
[3] J.Rosenberg and H.Schulzrinne,”Guidelinesfor Authors of Extensions to the Session Initial Protocol(SIP),”June2002.
[4] J. Rosenberg, H. Schulzrine, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, ”SIP:Session Initial Protocol,” RFC 3261, IETF, June 2002.
[5] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg,”SIP:Session InitialProtocol,”RFC 2543, IETF, March 1999.
[6] M. Handley, V. Jacobson, ” SDP: Session Description Protocol,” RFC 2327,IETF, April 1998.
[7] SIP Express Router, http://www.iptel.org/ser/ [8] The JAVA API for SIP Signaling,http:// jain.
-sip.dev.java.net/
[9] U. Varshiney, A. Snow, M. McGivern, and C. Howard,”VoiceoverIP,”Communicationsofthe ACM , Vol.45, pp.89-96, Jan.2002.
[10] VOVIDA, http://www.vovida.org/ [11] X-TEN, http://www.xten.com/
