Design and Implementation of SIP VoIP Monitoring System
7
0
0
全文
(2) 查詢請求時，會先由受話方的電話號碼判斷是否屬於 自己所負責的範圍。如果受話方號碼為此一伺服器所 管轄，伺服器就會去資料庫找尋其對應的 IP 位址；如 果受話方號碼（如傳統電話網路號碼 02-25663000） 不是此伺服器所負責的，則此伺服器將根據其所設定 的轉接規則，將請求轉給其他伺服器或是轉至語音閘 道器。依照上述的規則，本計畫向 SIP/ENUM 申請前 置 碼 為 0944021 的 電 話 號 碼 ， 共 一 千 門 號 碼 從 0944021000 到 0944021999。網路電話號碼的指派方法 是將號碼 0944021300 到 0944021399 分配給新竹地 區，號碼 0944021200 到 0944021299 分配給台北地區。 因此 SIP 伺服器可以從電話號碼的前置碼判斷出，此 一通電話應該轉送給哪一台 SIP 伺服器處理。. 換中心作監控。 SIPv6 Analyzer（如圖二所示）是一套 SIP 分析軟體， 由交通大學資工系 VoIP 實驗室的賴建利等人開發。 其功能包括繪出 SIP 信令流程圖以及播放 RTP 所承載 的多媒體資料流等。這套分析軟體對於開發 SIP 相關 應用服務，提供了一套簡單易用的工具。此一工具可 以應用於第一類的監控類型。但若要達到完整的監控 功能，則監控手續將非常繁雜。原因是 SIPv6 Analyzer 若要能監控一段通話，必須能擷取該電腦所發出的所 有封包，才能做進一步過濾分析的動作。因此 SIPv6 Analyzer 必須與網路電話安裝於同一台電腦，或是和 該網路電話位於同一集線器（Hub）或交換器上。換 句話說，每當受監控者位置移動，如換了一台電腦， SIPv6 Analyzer 就必須跟其一起移動，造成監聽工作 的不便。而且在受監控者使用無線網路電話的情況 下，要掌握受監控者的移動情形將更加困難。因此本 論文所提出的監控系統，是將受監控者的 RTP 封包導 向至監控中心的監聽設備來進行監控，故可解決上述 的問題。. 以下舉例說明網路電話的運作，從網路電話 0944021300 撥打至市話 02-25663000，訊息會先傳給 交大的 SIP 伺服器，SIP 伺服器由前置碼 02 判斷出此 通電話是台北地區的號碼，就將訊息轉送給台大的 SIP 伺服器，台大的 SIP 伺服器發現號碼並非 0944021 開頭，因此送給 PSTN 閘道器轉接至市話。如果從交 大網路電話 0944021300 撥打 0944021200，台大伺服 器收到封包後，就可以判斷 09440212 開頭的電話是自 己負責的號碼，接著就會查詢 0944021200 號碼所對應 的 IP 位址，最後轉接至台大之網路電話。 1.2. Problem Definition 雖然目前國內 SIP VoIP 實驗平台功能已經相當完整， 能夠提供網路電話與網路電話，或網路電話與市話或 手機的通話能力，但這套系統仍欠缺了一套監控的機 制。且在商用網路電話的運作中，檢調機關會要求提 供合法的監聽機制，以免網路電話成為犯罪的媒介。 完整的監控系統應包含以下功能。第一、提供完整的 通聯紀錄；第二、將指定的某通電話語音錄下，供檢 調人員調閱。因此本論文的目標就是研發 SIP VoIP 監 控系統，並在電信國家型計畫實驗平台架構上，驗證 出上述兩項功能。. 圖二、使用 SIPv6 Analyzer 監聽 由於網路電話在真正開始進行通話之前，一定會先用 SIP 通訊協定和網路電話伺服器進行溝通。因此本論 文提出透過增加網路電話伺服器的功能，讓 SIP 封包 在經過網路電話伺服器時，網路電話伺服器可以修改 SIP 封包中所帶的 SDP（Session Description Protocol [1]）資訊。之後受監控者的網路電話照著被修改過的 SDP 資訊建立傳送語音的 RTP 資料流，就會被導向至 本論文所開發的 RTP Proxy 上。RTP Proxy 收到 RTP 封包之後，複製一份並轉成 WAV 檔存下。而在網路 電話建立通話時，網路電話伺服器會將 SDP 中發話方 與受話方的資訊（位址與埠）交給 RTP Proxy，讓 RTP Proxy 可以正確地將封包送給通話的另一端。. 在設計這套監控系統的過程中，本論文還發現了一項 具 有 研 究 價 值 的 議 題 。 在 一 般 的 情 況 下 ， RTP （Real-time Transport Protocol [4]）資料流的流量遠大 於 SIP 控制訊號的流量。由於 RTP 資料流由 RTP Proxy 來負責，而 SIP 控制訊號則由網路電話伺服器來控 制，因此 RTP Proxy 是系統效能的瓶頸。故本論文使 用多台 RTP Proxy 建構成的負載平衡系統來提升系統 效能，並使用數學模型來找出系統最適合的 RTP Proxy 數量。. 2. Related Works. 由於電信國家型計畫 VoIP 平台所使用之網路電話伺 服器 Iptel SER [5]的功能並無法滿足監控的需求，為 了產生通聯記錄，本論文整合 Auth 模組與 Acc 模組， 來 設 計 一 個 的 監 聽 控 制 模 組 （ Monitoring Control Module），以達到上述修改 SDP 之功能。此外，在監 聽網路電話部分，本論文研發了 RTP Proxy 擷取 RTP 封包，並轉換成可播放之 WAV 檔案格式。最後，為. 分析目前網路監控系統，可分為兩個主要的類型，第 一 類 是 讓 網 路 上 所 有 的 交 換 器 （ 如 ： Switches 或 Routers）支援監控功能，檢調機關必須事先知道路由 並將監控系統連接上該交換器作監控。第二類是讓所 有的網路資訊都匯集至交換中心，檢調單位可以在交 2.
(3) 了提供通知的功能與集中管理之網頁介面，本論文研 發網路電話監控中心（Monitoring Portal），一方面與 網路電話伺服器溝通以設定監控對象；另一方面集中 儲存 RTP Proxy 所錄下之 WAV 檔，並於完成後以即 時訊息（Instant Message）來通知檢調人員。為了提升 系統整體效能，本論文採用負載平衡系統，利用多台 的 RTP Proxy 來平均分攤 RTP 語音資料流的流量。因 為每次連線的 RTP Proxy 不同，本監控系統不易被受 監聽者得知被監控。. 3-1. 網路電話伺服器. 網路電話伺服器主要的功能有二，其一是使用者認證並 產生通聯記錄，其二是將要監聽的通話導向至RTP Proxy。目前電信國家型計畫所採用的網路電話伺服器 中，已經有部分的功能可以直接套用於本文所描述的監 控系統，因此我們直接採用這些現有的模組，並對其加 以設定，以達到本論文所需之功能。 針對上述的兩項功能，本論文提出了以下的設計（圖 四） 。圖中的上半部份是SER原有的模組（圖四中○ b ○ c. 3. SIP VoIP Monitoring System. ○ ，如前項所述，本論文對此部分進行研究，改變 d ○ e ） 其設定來達到所需的功能。但由於SER中並沒有提供監 控相關的機制，因此必須自行開發其中的的監聽控制模 組，也就是圖四○ f 的部份。. 以下介紹監控系統中各個元件的功能及其在此系統中 e ）在每 所扮演的角色。網路電話（User Agent；圖三○ 次開機或取得新的 IP 位址時，都必須向網路電話伺服 b ）做註冊和更新的動作。網路電話伺服器 器（圖三○ 和 AAA（Authentication Authorization Accounting） 伺 a ）用 RADIUS （Remote Authentication 服器（圖三○ Dial In User Service [6]）來做認證的動作，以確認使 用者的身份。爾後網路電話在撥打或接聽電話時，都 會經由網路電話伺服器來做轉接，而網路電話伺服器 在做轉送的同時，也會和 AAA 伺服器交換資訊以產 生通聯記錄。. 圖四、網路電話伺服器內部模組設計圖 接下來針對圖四來說明其中各模組的功能及運作流 程。 (1) 通聯記錄產生的流程 所有經過網路電話伺服器的 SIP 封包都會先經過 SER e ） b ）確認 ，經由認證模組（圖四○ 的核心模組（圖四○ c ）來記 完使用者的身份之後，再交由記錄模組（圖四○ 下使用者的動作，以便於最後產生通聯記錄。這兩個模 組裡面皆包含 RADIUS 介面，會以 RADIUS 通訊協定 來和 AAA 伺服器做溝通。最後查詢使用者位址表（圖 d ）來找到此封包受話端的位址，將此位址填入該封 四○ 包後送出。. 圖三、SIP-based VoIP 監控系統 此外，網路電話伺服器還必須設法將語音的資料流 f ）上，因此網路電話伺服 導到 RTP Proxy（圖三○ 器和 RTP Proxy 之間必須要互相交換資訊，這兩者 之間的溝通採用 MGCP（Media Gateway Control Protocol [3]）通訊協定。RTP Proxy 則必須將收到 的 RTP 封包，正確的轉送給另一端的通話者，並 將語音資料存下來，當錄音完成之後，使用 FTP g ） （File Transfer Protocol）傳到監控中心（圖三○ h ） 上，監控中心存檔完畢之後，檢調人員（圖三○ 就可以經由網路瀏覽器（Web Browser）來取得語 音資料。. (2) 監聽的流程 也就是將通話導到 RTP Proxy 的過程。當封包通過 SER 的核心模組時，核心模組會將使用者的資料交由本論文 f ） 所開發的監聽控制模組（圖四○ 。該模組會先在 URL g ）中查詢這通電話的通話者是不是在表中， 表（圖四○ 來判斷這通電話是否需要監聽。不需監聽的通話，就可 以由 SER 核心模組查詢使用者位址表後，直接將封包 j ） 送出；需要監聽的通話，則經由 MGCP 介面（圖四○ l ）交換必要的資訊，交回給監聽 和 RTP Proxy（圖四○ 控制模組去修改 SIP 封包中的 SDP 資訊後，再交回 SER 核心模組將修改後的封包送出。. c ）則扮演另一個 SIP 網 此例中語音閘道器（圖三○ 路電話的角色，其會建立起另一個與傳統電話（圖 d ）之間的連線並轉換訊號。在此範例中，本監 三○ 控系統可以監聽由 VoIP 撥到市話或手機之通訊。 接下來說明網路電話伺服器、RTP Proxy 與監控中 心之功能：. (3) 網路電話伺服器和 RTP Proxy 間 MGCP 的溝通過程 3.
(4) 網路電話伺服器中已事先設定 RTP Proxy 所使用的 IP 位址和埠。以下說明這兩者間的溝通過程： ①.. (2) 將RTP封包轉成WAV格式儲存的流程. 網路電話伺服器收到來自受話端 SIP 200 OK 的訊 息後，向 RTP Proxy 發出 MGCP 的 CRCX（Create Connection）命令，裡面包含了： . 兩個使用者的 IP 位址和通訊埠. . 兩端協定後所使用的語音編碼. . 此次通話的序號（Serial ID）. ②.. RTP Proxy 收到由網路電話伺服器發出的命令，為 此通話做準備動作，完成後回應 200 OK 給網路 電話伺服器，確認準備動作完成。. ③.. 此時網路電話伺服器才轉送受話端使用者 SIP 200 OK 的訊息給發話端，正式開始通話。. ④.. 網路電話伺服器收到使用者 SIP BYE 的訊息，在 另一個使用者確認通話結束後，向 RTP Proxy 發 出 MGCP 的 DLCX（Delete Connection）命令， 以結束這一次的通話以及監聽動作。. ⑤.. 的目的位址和埠後送出。. 轉送模組收到RTP封包時，會將此封包複製一份，由 RTP2WAV模組（圖五○ d ）將之轉成WAV檔格式，並暫 存在WAV暫存器（圖五○ e ）中。等到RTP Proxy閒置時， WAV暫存器再用FTP將錄音檔上傳到監控中心。. 圖五、RTP Proxy 內部模組設計圖 (3) RTP Proxy中之位址對應表 位址對應表有幾個要點，由於 RTP Proxy 所收到的每 個 RTP 封包，都必須查一次位址對應表以取得目的地 位址和埠。由此可見，位址對應表查詢的次數會相當 頻繁。RTP Proxy 針對一通電話，只需對位址對應表 做一次新增和一次刪除的動作，但可能會查詢數千次 以上。因此我們進行位址對應表的設計時，把重點放 在增進查詢的效能。. RTP Proxy 收到由網路電話伺服器發出的命令，結 束轉送 RTP 封包並進行後續的處理動作，正式結 束這一次的監聽。. (4) 監控對象的設定 關於監控對象的設定，檢調人員可以在監控中 k 的部份） 心（圖四○ ，直接將要監聽的對象寫 g ）中。 入監聽控制模組的 URL 表（圖四○ 3-2. RTP Proxy. RTP Proxy的主要功能有二：第一是RTP封包的轉送 （Forwarding），第二是將收集到的RTP封包轉成WAV 檔存下。RTP Proxy中轉送的功能，包括轉送模組、位 址對應表和MGCP介面。轉送模組內部採用UDP Socket 來實作收送RTP封包的部份，UDP Socket可根據收到之 sockaddr結構中之sin_addr與sin_port欄位，來獲取用戶 端之位址和埠。轉送模組內部分成兩個不同的行程，其 一負責收，另一則專門處理送的部份。行程之間的通 訊 ， 由 於 Unix 系 統 中 常 用 的 IPC （ Inter-Process Communication）方式中，pipe和FIFO均無法由程式設 計 者 來 管 理其 緩 衝 區 大小 ， 因 此 本論 文 採 用 shared memory的方式，來達到不同行程之間的通訊。本論文 所設計的RTP Proxy內部模組圖如圖五所示，接下來針 對圖五來說明其中各模組的功能及運作流程。. 圖六、位址對應表的實作－普通的 hash table 位址對應表最初是以普通的hash table來實作（圖六）， 但由於RTP資料流是雙向的，由一個位址和埠查到另一 個位址和埠後，還需要從另一個位址和埠反查回來。因 此若使用普通的hash table來實作，就必須要存兩份資 料，因而造成空間的浪費。故我們提出了新作法。此新 作法之資料結構如圖七所示，每個連結串列的節點除了 有位址和埠的資料外，還包含了兩個指標，第一個指標 指向搜尋的結果，第二個指標用來搜尋用。以第一個欄 位為例，當搜尋到第一個節點時，如果addr（圖七○ a ） 和port（圖七○ b ）和所要搜尋的位址和埠相同，則用第 一個指標（圖七○ c ）來取得結果，否則則用第二個指標 （圖七○ d ）來繼續搜尋下一個節點，以此類推。. (1) 轉送RTP封包的流程. 最後的問題是hash function的設計。論文[7]詳細研究了 以實體位址（MAC address）為輸入的hash function，分 析並比較了如取前幾位元、CRC、checksum、XOR等 方式的效能好壞，參考此篇論文，本論文中hash function 目前採用CRC輸出16位元來當hash table的key。. 網路電話伺服器會經由MGCP介面（圖五○ ，把RTP a ） 封包的來源與目的的位址和埠寫入位址對應表（圖五 ○ 。當轉送模組（圖五○ b ） c ）收到RTP封包時，會根據 該封包中的來源位址和埠，從位址對應表中查到該封包 真正的目的位址和埠，並將查到的位址和埠填入原封包 4.
(5) 員。在收到通知後檢調人員透過HTTP（Hyper-Text Transfer Protocol）伺服器（圖八○ e ）上的網頁介面 和監控中心連線。HTTP伺服器提供檢調人員以 Web的方式存取WAV Storage中要收聽的錄音檔。關 於設定監聽目標的部份，檢調人員透過網頁介面設 定要監聽的對象，HTTP伺服器會以CGI（Common Gateway Interface）的方式控制監控模組客戶端（圖 八○ f ）將檢調人員的要求輸入網路電話伺服器（圖 八○ 。監控模組客戶端將監聽對象之URL寫入網 g ） 路電話伺服器中監聽控制模組的URL表，即可完成 設定。. 圖七、位址對應表的實作使用雙重指標的hash table 3-3. 監控中心. 圖八、監控中心內部模組設計圖 監控中心的主要功能有二：第一是集中儲存錄音檔案。 為了解決RTP Proxy同時處理許多通話而造成的高負荷 的問題，本監控系統會採用多台RTP Proxy之架構，來 平均分散RTP 的流量。但這也使單一受監控者的錄音 檔分散於各個RTP Proxy中，造成管理上的不便。且監 控人員如直接存取RTP Proxy上的錄音檔案，可能會影 響到RTP Proxy的效能，因此需要一個地方（即監控中 心）來集中儲存管理所有的對話錄音檔案。. 圖九、監控中心網路管理主選單介面. 4.Results and Performance Evaluation 圖十是 SIP-based 監控系統之展示環境，其中 UA1（圖 a ）、UA2（圖十○ c ）為兩個網路電話使用者，AP 十○ b ）為無線網路存取點，SIP Proxy（圖十○ d ） （圖十○ e 為網路電話伺服器，RTP Proxy（圖十○），Monitoring f ）為監控中心，Supervisor（圖十六○ g ） Portal（圖十○ 為檢調人員。. 第二是通知的功能及網路管理介面。當錄音檔案儲存完 畢之後，可以透過Notify Agent（圖八○ ，以即時訊息 d ） 的方式，通知檢調人員，在檢調人員收到通知後，可以 經由網頁介面來存取通話的錄音記錄。根據上述的功 能，我們所設計之監控中心內部模組如圖十ㄧ所示，接 下來說明其中各模組的功能及運作流程：. RA DI US. SIP. SIP. P RT. (1) 集中存取通聯記錄與錄音檔案. P RT. P FT. 通聯記錄儲存在AAA伺服器（圖八○ h ）上的資料庫中， 監控中心透過SQL Client（圖八○ ）以網頁介面提供管 i 理者查詢此一記錄（圖九） 。 圖十、展示環境介紹 RTP Proxy（圖八○ a ）完成錄音的工作後可以將錄音檔 成果展示步驟說明如下： 透過FTP上傳至監控中心上的FTP伺服器（圖八○ ；而 步驟一：檢調人員使用瀏覽器透過HTTP（圖十○），在 b ） 10 FTP伺服器將錄音檔案存入WAV Storage（圖八○ c ）中。 監 控 中 心 加 入 使 用 者 User01 和 User02 。 假 設 待檔案接收完成，FTP伺服器中的Notify Agent Plug-in User01使用UA1，User02使用UA2，UA1與UA2 會啟動Notify Agent（圖八○ ，以通知檢調人員。 d ） 向網路電話伺服器註冊。檢調人員在監控中心 設定UA1為受監控對象，UA2為一般使用者，設 (2) 通知的功能及網路管理介面 定介面如圖十一所示。 步驟二：受監測者開始撥打電話，SIP信令由UA1經過網 Notify Agent會以SIP即時訊息的方式通知檢調人 5.
(6) 路電話伺服器，與UA2交換RTP資訊（路徑為圖 。此時網路電話伺服器以RADIUS（圖 十○ 1 ○ 3 ○ 5 ） 十○ 8 ）在監控中心產生通聯記錄。收到SIP 200 OK訊息時，網路電話伺服器以MGCP（圖十○ 7 ） 要求RTP Proxy準備開啟RTP的連線。 步驟三：SIP信令完成後，UA1與UA2透過RTP Proxy進 行通話（路徑為圖十○ 。 2 ○ 4 ○ 6 ） 步驟四：通話完畢時，UA2送出SIP BYE訊息。網路電話 伺 服 器 收 到 BYE 訊 息 時 ， 以 MGCP 通 知 RTP Proxy結束RTP連線，並以RADIUS通知監控中 心，紀錄通話時間。 步驟五：結束通話後，RTP Proxy將通話錄音檔案以FTP （圖十○ 9 ）傳送至監控中心。監控中心以SIP即 時訊息（圖十○ 11 ）通知檢調人員。SIP即時訊息 結果如圖十二所示。 步驟六：檢調人員收到監控中心發出的SIP即時訊息後， 可以從監控中心調出UA1的通聯記錄及該通話 的錄音檔案（如圖十三）。. 圖十三、通聯記錄與錄音檔案下載介面 分析負載平衡系統架構之效能 針對負載平衡架構，我們最感興趣的是當RTP Proxy的 數量可控制時，每個封包處理時間的期望值. R = E [R, i > 0] 為多少。假設RTP封包進入RTP Proxy. 的速率λ是以Poisson Distribution的方式分布，而RTP Proxy 處 理 單 一 封 包 的 時 間 t s 是 以 平 均 值 為 1/ μ 的 General Distribution的方式分布。由於有i台RTP Proxy， 故對每一台RTP Proxy而言，封包進入的速率為λi =λ /i。且由於每台RTP Proxy均是獨立運作，故每一台RTP Proxy的行為可以用M/G/1來進行模擬。根據M/G/1的特 性。參考[8]， E R, i 可推導成下式：. [ ]. E [R, i ] =. 圖十一、在監控中心設定User01、User02監聽狀態. where ρ i 其中. =. ρ i (1 + cv2 ) 1 + , 2 µ (1 − ρ i ) µ. λi λ = µ iµ. (1). cv = µ Var[t s ] ， Var[t s ] 為 t s 的 變 異 數. R(1/µ). （variance） 。根據上式，選擇不同的λ和cv，可得到以 下的結果： 55 50 45 40 35 30 25 20 15 10 5 0. λ= 0.5µ, cv = 5 λ= 0.5µ, cv = 1 λ= 0.5µ, cv = 0.1 λ= 0.8µ, cv = 5 λ= 0.8µ, cv = 1 λ= 0.8µ, cv = 0.1. 1. 2. 3. 4. 5. 6. 7. 8. i. 圖十二、收到監控中心發出之 SIP 即時訊息通知. 圖十四、RTP Proxy處理封包的效能模擬. 6. 9. 10.
(7) 圖十四描繪出在特定負載量下 (即：. ρ = 0.8 或. ρ = 0.5 )，給定不同的cv對於平均封包停留在系統之時 間R (包含處理及等待時間)的影響。如圖所示，當cv值 較大時 (即: cv=5)及負載量 ρ = 0.8 時，由單一Proxy Server來處理所有的RTP 封包時，其停留在系統之時間 R高逹50多倍之平均封包處理時間 (1/μ)。在經由提供 多台之RTP Proxy後，我們可以大幅的減少其停留在系 統之時間。例如當RTP Proxy由一台増加到兩台時，其 效能可以提高約5倍，這是由於當只有單一伺服器時， 較容易出現某個需要較多處理時間的RTP封包阻擋其 後序封包的處理，造成其後序封包的等待時間大幅增 加。另一方面，當cv值較小時，則對於R之影響較小。 經由此圖所示的結果，可提供我們了解在特定系統狀態 下，我們需要多少台的RTP Proxy，才能在整個系統處 理封包的效能較不會受到負載量與cv的影響。例如當我 們的VoIP系統可以忍受的平均停留在系統之時間為4/ μ以下時，在 ρ = 0.8 及cv=5時，本系統可選擇使用五 台RTP Proxy，以符合系統之效能。. 5. Conclusions 本論文研發之監控系統，已成功地在電信國家型計畫 VoIP 平台上加入了 SIP VoIP 監控的機制，提供通連記 錄、網路電話監聽，以及即時訊息通知等功能。此一 系統之實作已獲得 2005 年教育部通訊教育程式設計 競賽大專組冠軍。關於系統效能部分，經過針對多台 RTP 伺服器之架構之效能評估，本論文發現建置五台 RTP 伺服器系統可以較不會受到負載量與處理時間變 異數的影響。. 6. References [1] M. Handley, V. Jacobson, RFC 2327 SDP: Session Description Protocol, April 1998. [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, RFC 3261 SIP: Session Initiation Protocol. June 2002. [3] F. Andreasen, B. Foster, RFC 3435 Media Gateway Control Protocol（MGCP）Version 1.0, January 2003. [4] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RFC 3550 RTP: A Transport Protocol for Real-Time Applications, July 2003. [5] Iptel SER網站（http://www.iptel.org/ser） [6] FreeRADIUS網站（http://www.freeradius.org） [7] Raj Jain, A Comparison of Hashing Schemes for Address Lookup in Computer Networks, October 1992. [8] S.M. Ross. Introduction to Probability Models. Harcount/Academic Press, 2000. 7.
(8)
相關文件
• SIPv6 Analyzer provides several functions (e.g., SIP Viewer and RTP Spy) for the users who attempt to debug the SIP VoIP network or the SIP devices. • SIPv6 Analyzer can
“For Mother Tongue Education to be successful we need to help CMI students learn English
n SCTP ensures that messages are delivered to the SCTP user in sequence within a given stream. n SCTP provides a mechanism for bypassing the sequenced
n Another important usage is when reserving network resources as part of a SIP session establishment... Integration of SIP Signaling and Resource
“More Joel on Software : Further Thoughts on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those
Type case as pattern matching on values Type safe dynamic value (existential types).. How can we
Skype provide better security than most VoIP system and PSTN. – Just because most VoIP system and PSTN do not provide any
Huan Liu and Dan Orban, “Cloud MapReduce: a MapReduce Implementation on top of a Cloud Operating System,” IEEE/ACM International Symposium on Cluster, Cloud and
