利用網路電話系統整合電視頻道之研究
68
0
0
全文
(2)
(3) 利用網路電話系統整合電視頻道之研究. 指導教授：梁明正 博士 國立高雄大學電機工程學系. 學生：黃興文 國立高雄大學電機工程學系碩士班. 摘要 網路電話從推出至今已經有無數的專家學者為其努力，不論在效能或是穩定性上 都已經十分成熟。但是始終沒有人研究一傳多且可傳送影像的架構，因為這點開發了 一傳多的影音系統。隨著網路的崛起，網路電話能見度逐漸變高，MSN、Google 都分 別提供網路電話服務，Skype 也成為當紅的網路電話代表。然而，網路電話對一般民 眾誘因不足，導致用戶數一直無法突破，僅限制於企業和一般民眾節費使用。本論文 致力於電視系統和網路電話的結合，透過在各社區或公司設置區域性伺服器，配合區 域性伺服器和影音伺服器取得電視訊號。希望以結合大眾常用的電視系統做為契機， 推廣網路電話給大眾。. 關鍵字： 網路電話、廣播、電視頻道、會議初始協定。. i.
(4) The Integration of Digital TV Using VOIP System. Advisor：Dr. Ming-Cheng Liang Institute of Electrical Engineering National University of Kaohsiung. Student：Huang, Xing-Wen Institute of Electrical Engineering National University of Kaohsiung. ABSTRACT There are so many people working on the VoIP so far, no matter efficiency or reliability are very mature in VoIP system.Since these people who work to this field earlier, we can integrate the Digital TV into the VoIP system.Causing the internet being popular, VoIP is more and more popular around us.There are many Internet Telephony Service Provider(ITSP) such as MSN, Google, Skype, all of them are provide the VoIP to serve us. However VoIP is not attractive to the public, so the number of user is not much. In this paper, to promote system usage, we integrate TV application into Voip.The TV system is very common in home, so that we use the TV application integrate into VoIP to popularize the whole system. Keywords: VOIP, SIP, Broadcast,Digital TV.. ii.
(5) 致謝 要感謝我的父母、大姐、大哥、二姐，在這金融海嘯時期願意支持我繼續就讀研 究所，取得學位。 最要感謝的就是我的指導教授梁明正老師，在這兩年的研究生涯中，老師不停歇 的為我指引明路。愛之深、責之切，不斷的提醒我，不能滿足於現在的成就，要能繼 續努力把事情做得更加完善。並且感謝吳國棟老師時常提供充滿人生哲學的啟發。 接下來要感謝實驗室的大家庭對我的照顧，學長:李敬文、王一成、陳信宏、黃崑 益、許良維、卓育旗。同學:蔡宗榮、葉志翔。學弟:蔡仁澤、張鈞凱、吳晉亨。對我 的幫助。得之於人者太多，要感謝者實在太多，無法一一列出。感謝每一位在我人生 中幫助過我的人。 黃興文 於高雄大學 2010 年 6 月. iii.
(6) 目錄 目錄 ..................................................................................................................................... iv 圖目錄 ................................................................................................................................. vi 表目錄 ............................................................................................................................... viii 第一章 緒論 ............................................................................................................... 1 1.1 研究背景 ....................................................................................................... 1 1.2 1.3 1.4 第二章. 研究動機 ....................................................................................................... 2 本論文之研究架構圖 .................................................................................... 3 論文架構 ....................................................................................................... 3 相關研究 ....................................................................................................... 4. 2.1. 2.2.. SIP ................................................................................................................ 4 SIP 元件 ........................................................................................................ 6 2.2.1 用戶代理 (User Agent) ........................................................................ 6 2.2.2 代理伺服器 (Proxy Server) ................................................................. 7 2.2.3 重定向伺服器 (Redirect Server) ......................................................... 7 2.2.4 註冊伺服器 (Register Server) ............................................................. 8. 2.2.5 位置伺服器 (Location Server) ............................................................. 9 2.3. 會議建立 ..................................................................................................... 10 2.3.1. Start Line 和 Message Header ........................................................... 10 2.3.2. 會談描述協議...................................................................................... 14 2.4. 多媒體傳輸模式 ......................................................................................... 15 2.4.1.. 主從式架構 ......................................................................................... 15. 2.4.2. Peer-to-Peer ........................................................................................ 16 2.5. 負載平衡 ..................................................................................................... 17 2.5.1. 2.5.2.. Round robin ........................................................................................ 18 Weighted round robin ........................................................................ 18. 2.5.3. Least-Connection ................................................................................ 19 2.5.4. Weighted Least-Connection ............................................................... 20 2.6 Asterisk ....................................................................................................... 21 2.7 現有系統架構 ............................................................................................. 22 2.7.1 一對一通訊模式 .................................................................................. 22 2.7.2 2.7.3 2.7.4 2.7.5 2.8. 硬體電話多人會議模式 ...................................................................... 23 多人會議系統...................................................................................... 23 群組廣播系統...................................................................................... 24 多人應用的問題 .................................................................................. 26. IPTV ........................................................................................................... 27 iv.
(7) 第三章 3.1 3.2. 系統架構 ..................................................................................................... 28 架構元件 ..................................................................................................... 30 運作流程圖 ................................................................................................. 31. 3.3 3.4 3.5. 伺服器程式 ................................................................................................. 33 系統特點 ..................................................................................................... 37 架構比較 ..................................................................................................... 38 3.5.1 網路電話架構...................................................................................... 38 數據量測和數據分析 .................................................................................. 40. 第四章 4.1.. 系統負載測試 ............................................................................................. 40 4.1.1. 240 通 .................................................................................................. 41 4.1.2. 220 通 .................................................................................................. 43 4.1.3. 200 通 .................................................................................................. 44 4.1.4. 180 通 .................................................................................................. 45. 4.1.5. 160 通 .................................................................................................. 47 4.2. 數據分析 ..................................................................................................... 49 4.3. 多媒體服務品質測試 .................................................................................. 50 4.3.1. 測試架構 ............................................................................................. 50 4.3.2. 數據與分析 ......................................................................................... 53 第五章 5.1. 5.2.. 第六章. 結論與未來工作 ......................................................................................... 56 結論 ............................................................................................................. 56 未來工作 ..................................................................................................... 56 5.2.1. 負載平衡-演算法 ................................................................................ 56 5.2.2. 互動分享機制...................................................................................... 56 5.2.3. 群播能力 ............................................................................................. 56 5.2.4. 整合 IPV6 ........................................................................................... 56 參考文獻 ..................................................................................................... 57. v.
(8) 圖目錄 圖 1-1 研究架構圖............................................................................................................. 3 圖 圖 圖 圖 圖. 2-1 2-2 2-3 2-4 2-5. UA .......................................................................................................................... 6 PROXY SERVER ........................................................................................................ 7 REDIRECT SERVER.................................................................................................... 8 REGISTRAR SERVER.................................................................................................. 8 LOCATION SERVER ................................................................................................... 9. 圖 圖 圖 圖 圖. 2-6 2-7 2-8 2-9 2-10. 會議建立............................................................................................................... 10 主從式架構........................................................................................................... 15 PEER-TO-PEER........................................................................................................ 16 負載平衡............................................................................................................... 17 ROUND ROBIN ....................................................................................................... 18. 圖 圖 圖 圖 圖. 2-11 2-12 2-13 2-14 2-15. WEIGHTED ROUND ROBIN...................................................................................... 19 LEAST-CONNECTION ............................................................................................. 19 WEIGHTED LEAST-CONNECTION ........................................................................... 20 一對一通訊 ......................................................................................................... 22 硬體電話多方會議 ............................................................................................. 23. 圖 圖 圖 圖 圖. 2-16 2-17 2-18 2-19 3-1. 多方會議系統 ..................................................................................................... 24 單向廣播系統 ..................................................................................................... 25 雙向廣播系統 ..................................................................................................... 26 典型 IPTV 發展模型 .......................................................................................... 27 系統架構圖........................................................................................................... 28. 圖 圖 圖 圖 圖. 3-2 3-3 3-4 3-5 3-6. 影音伺服器區塊 ................................................................................................... 29 運作流程............................................................................................................... 31 簡易系統示意圖 ................................................................................................... 32 主流程圖............................................................................................................... 34 接收端流程圖 ....................................................................................................... 35. 圖 圖 圖 圖 圖. 3-7 4-1 4-2 4-3 4-4. 傳送端流程圖 ....................................................................................................... 36 測試架構圖........................................................................................................... 40 240 通成功通數比較 ............................................................................................ 42 240 通 CPU 使用率比較 ....................................................................................... 42 240 通記憶體比較 ................................................................................................ 42. 圖 圖 圖 圖. 4-5 4-6 4-7 4-8. 220 通成功通數比較 ............................................................................................ 43 220 通 CPU 使用率比較 ....................................................................................... 43 220 記憶體比較 .................................................................................................... 44 200 通成功通數比較 ............................................................................................ 44. 圖 4-9 200 通 CPU 使用率比較 ....................................................................................... 45 vi.
(9) 圖 4-10 200 通記憶體比較 .............................................................................................. 45 圖 4-11 180 通成功通數比較 .......................................................................................... 46 圖 4-12 180 通 CPU 使用率比較 ..................................................................................... 46 圖 圖 圖 圖 圖. 4-13 4-14 4-15 4-16 4-17. 180 通記憶體比較 .............................................................................................. 46 160 通成功通數比較 .......................................................................................... 47 160 通 CPU 使用率比較 ..................................................................................... 47 160 通記憶體比較 .............................................................................................. 48 320 通 CPU 使用率 ............................................................................................ 48. 圖 圖 圖 圖 圖. 4-18 4-19 4-20 4-21 4-22. 320 通記憶體使用量 .......................................................................................... 49 共用頻寬架構圖(一)........................................................................................... 51 共用頻寬架構圖(二)........................................................................................... 51 獨立頻寬架構圖 ................................................................................................. 52 WIFI 架構圖(一).................................................................................................. 52. 圖 4-23 WIFI 架構圖(二).................................................................................................. 53 圖 4-24 伺服器負載對用戶影響測試架構圖 .................................................................. 53. vii.
(10) 表目錄 表 表 表 表. 2-1 2-2 2-3 2-4. SIP 封包 ................................................................................................................ 11 請求方法............................................................................................................... 12 狀態碼 .................................................................................................................. 12 SIP 標頭 ................................................................................................................ 13. 表 表 表 表 表. 2-5 2-6 2-7 2-8 2-9. SDP 欄位解說....................................................................................................... 14 ROUND ROBIN ......................................................................................................... 18 一對一特性........................................................................................................... 23 硬體多對多特性 ................................................................................................... 23 多人會議特性 ....................................................................................................... 24. 表 表 表 表 表. 2-10 2-11 3-1 4-1 4-2. 單向廣播特性 ..................................................................................................... 25 雙向廣播特性 ..................................................................................................... 26 架構比較表........................................................................................................... 39 伺服器規格........................................................................................................... 41 測試項目............................................................................................................... 41. 表 表 表 表 表. 4-3 4-4 4-5 4-6 4-7. 設備 A 數據整理 .................................................................................................. 49 設備 B 數據整理 .................................................................................................. 50 共用頻寬架構 ....................................................................................................... 54 獨立頻寬架構 ....................................................................................................... 54 WIFI 架構 (一) ...................................................................................................... 54. 表 4-8 WIFI 架構 (二) ...................................................................................................... 54 表 4-9 設備 A 封包延遲數據表 ....................................................................................... 55 表 4-10 設備 B 封包延遲數據表 ..................................................................................... 55. viii.
(11) 第一章 緒論 1.1 研究背景 電視廣播系統已經行之有年，從早期的類比時期到現在的數位電視歷久不衰。 電視廣播系統提供了一個良好的平台給電視台業者，民眾可以利用電視廣播系統 觀看新聞、娛樂節目、教育節目…等等。電視廣播系統不論傳統的類比或是現在 的數位都是採用無線廣播，民眾要接收電視訊號時必定要使用天線接收，因為訊 號在傳送途中經過各種干擾，到用戶家中時也許訊號強度已經不足。同時在有限 的頻帶下能傳送的節目有限，因此第四台業者推出了有線電視系統。 隨著網路頻寬逐漸加大，利用網路來做傳輸媒介的平台越來越多。這些平台 在網路上提供影音服務讓用戶可以利用網路收看，不論是遠距離教學、隨選視訊、 遠距離看護…等，都已經在使用。做為一個傳輸系統的 IPTV(Internet Protocol Television)由許多組織提出[1-4]，MOD（Multimedia on Demand）便是使用此架構 建立的服務平台，目前也穩定的運行中。使用網路傳輸有許多優點，可以享有較 大的傳輸頻寬，因此可以傳送高畫質的影像，使用網路傳輸同時可以降低訊號失 真的問題...等等。 網路電話也是拜網路之賜而發展出的系統，網路電話相較於傳統電話擁有更 多優勢，網路電話顧名思義是運用網路當作傳輸的媒介，透過網路點對點的語音、 影像傳輸。而傳統電話 PSTN 是使用傳統交換機系統，採用電路交換系統，在通 話時會占用線路，提高了通話的成本。網路電話將語音、影像取樣後轉為數位訊 號放入封包透過網路傳輸到目的端，目的端再把封包還原成語音或影像，因為傳 輸路徑是使用大眾網路系統並不需要額外的費用因此費用較為低廉。在國際電話 中電信業者也有使用網路電話來做跨洲傳輸的動作，且網路電話在行動通訊上也 可使用自如，可使用的範圍更加廣泛。網路電話的通訊協定的演進從早期的 1.
(12) H.323[5]到現在普遍使用的 SIP(Session Initiation Protocol; SIP)[7]相較於最明顯的 優勢在於和 HTTP (Hypertext Transfer Protocol)一樣採用明文編碼的方式。因此開 發人員在作開發、除錯時更加快速方便。. 1.2 研究動機 近年來在網路上的應用越來越多，網路上的遠距離教學、隨選影片系統、網 路電視系統和遠距離看護系統等都因應而生。目前 Sony、Microsoft 都已經推出隨 選視訊的功能，還有即將加入戰局的 Google TV。在網路架構上傳送影音已經成 為一個大趨勢。 網路電話目前提供的服務是一對一型式的通話或是語音信箱…等，或是多對 多的語音會議系統。沒有一傳多的影音傳輸系統，同時電視產品搭配機上盒也有 網路通訊的能力了。網路電話和電視廣播系統一個極力開發多媒體應用，一個大 眾普遍收看的媒體資訊，何不將兩者整合在一起。在網路電話下加入電視廣播系 統，不但可以維持現有的通訊業務，同時也可以增加電視頻道的服務給用戶。因 此在此架構下的用戶可以同時享有通訊和電視頻道的服務。循著這個想法我們採 用了 Asterisk 當作我們這次架構的開發主軸，開發一個適合傳送影音訊號的應用 程式。透過現有的網路電話架構，整合網路電話和電視頻道。使用網路電話系統 整合數位電視頻道有以下優點: 1.. 運用網路傳輸不需額外佈置線路。. 2.. 如要提高用戶承載量，可利用負載平衡架構。. 3.. 可配合數位機上盒結合電視銀幕，提高使用網路電話意願。. 4.. 使用網路電話現有架構，不做大幅度修改. 2.
(13) 1.3 本論文之研究架構圖 圖 1-1 中所展現的是我們論文的研究架構圖，主要有兩個主要功能要完成: . 一對多影像語音傳輸. 一傳多影像功能是系統的骨幹，透過這個應用來支持我們整個系統的運作。 . 伺服器的影像語音轉傳功能. 透過階層式的資料傳輸只需要一個影音來源就可以供給龐大的用戶使用。. 影音伺服器. 訊號 用戶. VOIP 伺服器. VOIP 伺服器. VOIP 伺服器. VOIP 伺服器. VOIP 伺服器. VOIP 伺服器. VOIP 伺服器. …………… 用戶. 用戶. 用戶 圖 1-1. 用戶. 用戶. 用戶. 研究架構圖. 1.4 論文架構 在第二章我們會介紹網路電話的基礎、運作流程。第三章介紹我們的系統架 構並且和現有的系統架構做比較。第四章是數據量測結果和數據分析，第五章對 我們的系統做個總結並且說明未來可發展的方向。 3.
(14) 第二章 相關研究 在網際網路上許多程式有用來建立、管理會議，協助客戶端溝通、交換所需 資訊的功能，不論用戶分不在哪種網路型態下都可以運作，或是處理在會議中彼 此使用不同媒體的複雜資訊。在這些協定中的會議起始協定(SIP[7])就是用來解決 協調的工作，透過 Proxy Server 處理使用者註冊，會議邀請..等等功能。SIP 小巧 且多用途，它可以獨立運作在基礎的傳輸協定上來完成建立、改變和終止會議的 的工作。 在 2.1 中將會介紹網路電話協定中的 SIP，在 2.2 到 2.4 會介紹 SIP 的基本元 件、封包欄位和運作流程和多媒體串流的型態。SIP 是目前受大家所採用的協定， 透過 2.1 到 2.4 的介紹可以清楚了解到整個網路電話信令溝通的整個流程，建立基 礎認之。在 2.5 則介紹網路電話中常用來增加服務量的負載平衡機制。2.6 則介紹 我們採用的網路電話伺服器開源軟體 Asterisk，這個軟體使用者非常廣泛，許多 業界產品也是採用此款進行開發。2.7 則對網路電話現在使用的通訊模式做分析與 比較。而本系統是建立在一傳多且可傳送影像和聲音的架構下。. 2.1. SIP 在 1999 年 IETF 發布了 RFC 2543 ，在發布後 IETF 開始注意到 SIP[2]的容 易開發、內容簡潔以及擴充性高…等優點。並在 2002 年發布目前最新規範 RFC 3261 。SIP 是建立在應用層上的一個協定，用於建立、改變和終止多媒體通訊。 SIP 能邀請使用者進入現存的會議中，例如多方會談的會議，且在進行的會議中 改變使用的媒體。除此之外，也支援名稱映射和重導的服務。而行動裝置的使用 者無論身處何種網路環境下，仍可提供一個可供外界網路聯繫的 IP 位址。 SIP 透過五方面的資訊來完成建立、結束通話的任務 4.
(15) 用戶位址. :決定該次通話的終端系統. 用戶可用度. :caller 是否願意接受通話. 用戶能力. :會議中客戶端可使用的多媒體資訊. 會議安排. :從 180 “ringing”，到完成協調多媒體能力. 會議管理. :包括了轉移和終止會議和改變會議參數. 雖然 SIP 有這麼多的優點，但它不是垂直整合的通訊系統。SIP 需要其他 IETF 協定的幫助下才能建立一個完整的多媒體系統架構。一般來說，這架構裡面包含 了 Real-time Transport Protocol (RTP) RFC 1889[6]用來傳輸及時資料和做 QOS 的 回報機制，Real-Time Streaming Protocol (RTSP) RFC 2326[8]用來控制傳送串流， Media Gateway Control Protocol (MGCP[10]) RFC 3015 控制 Public Switched Telephone Network (PSTN) 和 SIP 的閘道器，和 Session Description Protocol (SDP[9]) RFC 2327 用來攜帶多媒體資訊。所以 SIP 可以透過連結各協定來為用戶 提供完整的服務，不論如何，SIP 基本的功能和運作是可以獨立運行的。因此， 雖然 SIP 是無法為用戶提供任何多媒體服務，但是他可以運用其他的協定來提供 服務。SIP 可以找到用戶並且傳送訊息到他現有的位址，並且運用 SDP 來協調要 使用的多媒體參數。同樣的，SIP 也沒有提供會議室控制的服務，但是 SIP 可以 運用其他會議室控制協定。SIP 為了使用者的安全性，提供合適的安全服務，例 如預防阻斷式攻擊，認證，加密等完整性的保護。並且在網路日益發達的情形下 也支援了下世代的 IPV6，所以可以運行在 IPV4 和 IPV6 上。 SIP 的元件主要有 UA(User Agent)、Proxy Server、Redirect Server、Registry Server。SIP 相較於其他協定的重大變革在於使用明文傳輸訊息，使用明文可以讓 開發者簡單的觀察 SIP 的封包內容以利除錯。其中 SIP 封包裡包含了 Start Line、 Message Header、Message Body 三的部分。因為我們的系統架構在 SIP 環境中， 所以 SIP 的元件、SIP 的信令溝通和 SIP 使用的 SDP 我們在以下章節說明。. 5.
(16) 2.2.. SIP元件. 因為我們的系夠架構在SIP的環境中，所以當我們要會議建立時必頇要用到多 個SIP元件，而其中主要有以下四個基礎元件。用戶代理(User Agent)、註冊伺服器 (Registration)、代理伺服器(Proxy Server)和重新定向伺服器( Redirect Server)，以下 對這些元件做介紹。. 2.2.1用戶代理 (User Agent) User Agents簡稱為UA，用戶端通常是硬體電話、個人電腦或手機上的軟體電 話，他代替使用者處理各協定的相關事務。UA最主要的功能為當使用者設定註冊 資訊時發出註冊請求，撥號時發出通話請求、接收到訊息時回應要求、掛上電話 時停止通話。如圖2-1所示，用戶代理在邏輯上它包含有User Agent Client (UAC) 以 及 User Agent Server (UAS) 兩種角色，當一個訊息要被傳送到其他地方時，必定 會有一個UAC和UAS，其中UAC負責發送請求(Request)以及接收UAS傳來的回應 (Response)，而UAS負責接收UAC發送的請求(Request)以及依照請求發送回應 (Response)。每個UA都同時是UAC和UAS，如果UA目前處於的是呼叫者(Caller) 的位置，這時該UA就是處於UAC的位置，反之UA所處於的是接聽者(Callee)的位 置，這時該UA則處於UAS的位置。. Caller. UAC. Proxy Server INVITE. Callee INVITE. UAS. UAC. UAS. UAS. UAC. BYE. 圖 2-1 6. UA.
(17) 2.2.2代理伺服器 (Proxy Server) Proxy Server是SIP運作的核心元件，為了因應需求，它同時帶有伺服器端和客 戶端雙重身分，他的工作是把UA發出的請求或是其他的Proxy Server收到的請求代 為轉送到應該傳送的位置。如圖2-2 所示，當Alice送出連線請求時並不一定知道 請求連線的對象其IP位址究竟位於何處，此時便需要將請求傳送給Proxy Server， Proxy Server再透過查詢Location Server得知John相關位址資訊，才能轉送到正確的 John位置。從Alice發出請求連線時，有可能經由Proxy Server層層轉送後才將請求 訊息傳送到目的端的John。因此，每台Proxy Server都會預設該傳送的路由，依照 目的端傳送到對應的Proxy Server並且對請求訊息做適當的修改處理以利訊息的傳 遞。John發送回應訊息時，也是經過相同的路徑但是順序相反將回應結果給請求端 的Alice。. Registrar. Query. Proxy Server INVITE. STORE Resp. REGISTER. Location Service. Alice. INVITE John. 圖 2-2. Proxy Server. 2.2.3重定向伺服器 (Redirect Server) 重定向伺服器(如圖2-3)和Proxy Server十分類似，但他的工作卻和Proxy Server 大不相同，Redirect Server只負責為呼叫者找尋目前接聽者的位置，並把查尋結果 回傳給呼叫者，讓呼叫者知道需要將連線請求重新導向接聽者目前的位置，而不 會轉遞任何訊息到其他伺服器。在網路環境中DNS Server的功能就是回傳正確的IP 7.
(18) 位置給使用者，所以又有一說Redirect Server像是SIP中的DNS，專門回傳SIP的IP 位址。. Redirect Service INVITE John. 302 Moved Temporarily. Alice. 圖 2-3. Redirect Server. 2.2.4註冊伺服器 (Register Server) 註冊伺服器(如圖2-4)當使用者要使用軟體或是硬體電話時一定要輸入註冊的 相關訊息，當UA啟動時會發送註冊訊息到Register Server，如果伺服器驗證無誤， 相關資料會被轉存到位置伺服器中。當有使用者要撥號時就可以透過查詢的方式 或是代理伺服器協助從位置伺服器中找到受話端。所以在使用者使用SIP上的服務 之前在開機或是開啟程式的第一件事情就是UA會代替使用者做註冊的動作，因此 Registrar Server還兼具有使用者身份認證的功能，註冊完畢後該用戶資訊就會在位 置伺服器上更新，其他用戶就可以查詢及呼叫他了。 Registrar. Query. Proxy Server INVITE. STORE Resp. REGISTER. Location Service. Alice. INVITE John. 圖 2-4. Registrar Server 8.
(19) 2.2.5位置伺服器 (Location Server) 位置伺服器(如圖2-5)就像是SIP的資料庫，負責把UA傳給Register Server 的註冊資訊儲存，其中有：URI、IP、顯示來電名稱、特性等等。接受註冊 伺服器的用戶資料，並提供給代理伺服器和轉向伺服器使用。通常位置伺服 器、註冊伺服器都是代理伺服器的一部分，少數大規模的電信等級服務設施， 才會因效能考量區分開。 Registrar. Query. Proxy Server INVITE. STORE Resp. REGISTER. Location Service. Alice. INVITE John. 圖 2-5. Location Server. 9.
(20) 2.3. 會議建立 服務提供商最重要的事情就是確保會議可以順利的建立。在會議建立的信令 溝通中，相關資訊放置在封包中的各欄位，透過這些資訊來建立這次的會議。封 包中主要分為Start Line、Message Header、Message Body。在2.3.1中會介紹Start line 和Message，在2.3.2則介紹Message Body，Message Body的部分是另外的協定SDP。. 2.3.1. Start Line和Message Header 當一個會議要建立時，必頇經過一系列的信令溝通後才能順利完成。如圖2-6 所示，當John撥號給Alice時UA會先發出1. INVITE(通常包含了SDP的訊息)的請求 訊息給Alice，當Alice的UA收到此請求時會先回傳2. 180 Ringing的暫時訊息給John 表示已經收到請求訊息，避免John重複傳送請求訊息。當Alice接起電話時UA會傳 送3. 200 OK的訊息(通常在此會帶有SDP訊息)給John，此時John的UA收到後會傳送 4. ACK給Alice(1.INVITE. 2.200OK 4.ACK即是SIP中的三向握手)。5.多媒體串流. 會依照SDP中帶的訊息在Alice和John建立通道傳送影像、聲音或DTMF。當Alice 想結束對話掛上電話時，UA就會傳送6. BYE給John，當John收到BYE的訊息時回 應7. 200 OK給Alice。. 1 INVITE. 2 180 Ringing 3 200 OK 4 ACK 5 Media Session. 6 BYE 7 200 OK 圖 2-6. 會議建立 10.
(21) 在表2-1中，可以看到SIP封包實際的欄位訊息，在封包的開頭會有Start Line， 主要紀錄這次請求或是狀態回覆碼。其次Message Header部分紀錄了此封包來源和 前往的目的端等資訊。Message Body則是記錄了多媒體資訊的相關參數。. • INVITE sip:[email protected] SIP/2.0 Start Line. • • • • • • • • • •. Via: SIP/2.0/UDP 192.168.2.138:7340; Branch=z9hG4bK-d8754z-953c536658c39074-1---d8754zContact: <sip:[email protected]:7340> To: <sip:[email protected] > From: "Alice"<sip:[email protected]>;tag=b3afab63 Call-ID: [email protected] CSeq: 1 INVITE Content-Type: application/sdp User-Agent: X-Lite Beta release 4.0 Beta 2 stamp 56233 Content-Lenght: 444 Message Header. • • • • • • • • • • • • • • •. (v): 0 (o): IN IP4 192.168.2.138 (s): CounterPath X-Lite 4.0 (c): IN IP4 192.168.2.138 (t): 0 0 (m): audio 58560 RTP/AVP 8 101 (a): sendrecv (a): rtpmap:101 telephone-event/8000 (a): fmtp:101 0-15 (m): video 21382 RTP/AVP 115 34 (a): sendrecv (a): rtpmap:115 H263-1998/90000 (a): fmtp:115 QCIF=1;CIF=1;I=1;J=1;T=1 (a): rtpmap:34 H263/90000 (a): fmtp:34 QCIF=1;CIF=1. Message Body. 表 2-1. SIP 封包. 如表2-2、表2-3中所表示，SIP在作會議建立時會使用SIP請求方法，最常使用 是INVITE、ACK、BYE、INFO。而在回應訊息方面SIP也有個別定義回應代碼， 每種代碼依照開頭有不同類別的訊息。此欄位即是SIP封包中的Start Line部分。 11.
(22) 請求方法. 說明 發起會議的邀請(通常會帶有 SDP). INVITE ACK. 收到回應 INVITE 訊息後的答應. BYE. 用來結束目前的會議 用來取消尚未建立的會議. CANCEL REGISTER. 透過 UA 把使用者帳號和網路相關資 訊傳送給伺服器. OPTION INFO. 用來查詢媒體能力和訊息 在會議中傳送信號，而不會改變會議 狀態 表 2-2. 狀態碼 1xx(Provisional). 請求方法. 說明 收到請求，正在處理請求中。暫時性的回應訊息讓傳 送端知道發出的要求已經被收到不要再重覆傳送請 求。. 2xx(Success). 成功接受請求。表示確認無誤並接受此請求. 3xx(Redirection). 沒辦法滿足請求，需要重導到適當位址. 4xx(Client Error). 客戶端傳送來的請求內容有錯，或無法滿伺服器需要 的資訊。. 5xx(Server Error) 6xx(Global Failure). 伺服器的錯誤，無法接受客戶端的請求 整體環境的錯誤或是請求不被接受 表 2-3. 狀態碼. 如表 2-4 所表示，在發送請求訊息時 Message Header 中會代有許多欄位。一 個正確的 SIP 請求至少要包含六個標頭: To, From, CSeq, Call-ID, Max-Forwards,. 12.
(23) 和 Via。這六種標頭是建立 SIP 請求的基本，他們最重要的功用就是提供路由服 務，包含了位址訊息，路由回應和該次通話的認證碼給伺服器和 UA。 標頭. 說明 To. 受話端的 SIP URI 通常顯示名字. From. 發話端的 SIP URI，伺服器可用來做來電警衛等服務. CSeq. 作識別各請求的用途，透過 CSeq 可以知曉回應的是哪 次的呼叫。. Call-ID. 是個唯一值用來識別發話端，在一次通話中必頇使用 一致的值作為認證，並且在每次註冊時亦是用同組字 串做認證。. Max-Forwards. 最大轉送次數，每經過一次轉送依序減一。到達目標 前到 0 會回送 483(Too Many Hops)回應。. Via. 紀錄經過的代理伺服器 表 2-4. SIP 標頭. 13.
(24) 2.3.2. 會談描述協議 SDP[9]全名為 Session Description Protocol ，IEFT1998 年發布 RFC 2327。 SDP 協助可預期的參與者發布和溝通會議建立的資訊。SDP 只是一個單純的格式 來做會議的描述，並不是傳輸協定，而和 SIP 一樣使用其他合適的協定(Session Initiation Protocol、Real- Time Streaming Protocol、Hypertext Transport Protocol 等) 來完成工作。SDP 是以多功能來設計的，所以可以在不同網路環境和不同應用成 是使用。 在 SIP 中，當我們要建立一個多媒體通話時，通話的參與者需要交換彼 此的多媒體資訊，例如媒體的傳輸位置、傳輸埠，語音和影像要使用何種編碼傳 送等。在 SIP 中要建立一個會議時會因為本身無法攜帶多媒體資訊，因此需要 SDP 攜帶堆媒體資訊。通常我們會在發送 INVITE 時就把 Caller 的多媒體資訊放入 SDP 一起傳給 Callee，而 Callee 在接受此通話後，會在 200 OK 回應中攜帶 Callee 可 接受的多媒體資訊。SDP 就是表 1 中的 Message Body 的區塊，區塊中的欄位如同 表 2-5 的欄位解說。 欄位. 說明 v. SDP 的版本，目前只用 0. o. 紀錄請求端的訊息 (IP 版本 、IP ). s. 主叫端用來描述會議名稱. c. 發送端的連線資訊 (網路型態 、IP). b. 使用的頻寬情形. a. 可使用的媒體編碼和資訊. t. 會議可進行的時間. m. 影像或聲音的連線資訊(Port、使用的協定、可用 的編碼) 表 2-5. SDP 欄位解說. 14.
(25) 2.4. 多媒體傳輸模式 當我們了解 2.3 和 2.4 所講的會議建立流程後，要介紹的就是多媒體串流的建 立。當用戶間的 SIP[7]信令溝通結束後，系統會依據 SDP[9]中的傳送 IP 位址、阜 號…等等資訊建立傳輸的通道。其中傳輸的型態又分為兩種，主從式(Client/Server) 架構和 P2P(Peer-to-Peer)架構。. 2.4.1. 主從式架構 使用主從式架構時，任何訊息都會經由伺服器後才轉送到用戶端。如圖2-7 所 示John發出的所有訊息都由Proxy Server分析後代為轉送到目的端，多媒體串流也 經過伺服器後轉送到目的端。. Proxy. John. Alice. INVITE INVITE 100 Trying. 180 Ringing 180 Ringing. 200 OK. 200 OK ACK. ACK. Media Session 圖 2-7. Media Session 主從式架構. 15.
(26) 2.4.2. Peer-to-Peer 如圖 2-8Peer-to-Peer 架構下 Proxy 並不負責多媒體傳輸，因此多媒體串流直接 在用戶間傳遞並不會經過伺服器。. Proxy. John. Alice. 1 INVITE. 2 INVITE 3 100 Trying. 4 180 Ringing 5 180 Ringing. 6 200 OK. 7 200 OK 8 ACK. 9 Media Session. 圖 2-8. Peer-to-Peer. 16.
(27) 2.5. 負載平衡 負載平衡已經有許多文獻探討[12-19]，其中 [19]已經對各種情形做過測試。 當伺服器上在線的用戶量超過系統總承載量時，新進的通話就沒有辦法受到伺服 器的服務，甚至在線上的所有使用者會因為系統不穩定的原因造成品質不佳等影 響。這是做為一個服務平台沒有辦法避免的事情。這個問題有許多解決的方法最 簡單的就是增加伺服器的承載量，不斷的提高伺服器效能。但是到一個極限時效 能也就不能提高，且高效能伺服器成本昂貴。因此有人提出負載平衡(如圖 2-9)， 透過上下層分工，上層(Master)主導此次通話該傳遞給下層(Slave)哪台伺服器，下 層伺服器接受上層分派的工作並且完成任務。. Slave. User. Master 圖 2-9. 負載平衡. 以下小節將介紹基本的 Round robin、Least-connection 和有權重的 Weighted Round robin、Weighted Least-connection 等基礎的演算法。. 17.
(28) 2.5.1. Round robin 如圖 2-10 所示當新的請求進來時會依序傳給底下的所有伺服器，當全部伺服 器都傳送過後又從第一台伺服器開始，持續不斷。. User. Master. Server2. Server1 1. 4. 2. 圖 2-10. 5. Server3 3. 6. 801. round robin. 2.5.2. Weighted round robin Server. Weight. Server1. 10. Server2. 5. Server3. 5. 表 2-6 round robin 有權重機制可以更靈活的調配伺服器，如表 2-6、圖 2-11 所示每 20 個服務請求進 來轉給 Server1 的會有 10 通，Server2 和 Server3 各三通。. 18.
(29) User. Master. Server1. Server2. Server3. 0.5. 0.25. 0.25. 圖 2-11. 801. Weighted round robin. 2.5.3. Least-Connection Least-Connection 必頇要和伺服器做連接獲取資訊，依照獲得的相關訊息來決 定通話要轉交給哪一台伺服器。當有新的服務請求進來時，會轉送請求給目前建 立通話數比較少的伺服器。如圖 2-12 所示 Server3 通話量最少，所以轉給 Server3。. User. Master. Server1. Server2. Hi. Med. 圖 2-12. Server3 Low. Least-Connection 19. 801.
(30) 2.5.4. Weighted Least-Connection Weight Least-Connection 和 Least-Connection 必頇要和伺服器做連接獲取資訊， 依照獲得的相關訊息來決定通話要轉交給哪一台伺服器，但是多了權重比。當有 新的服務請求進來時，會轉送請求給目前建立通話數比較少的伺服器，權重比較 高的會接收到較多的請求。如圖 2-13 所示 Server3 通話量最少，所以轉給 Server3。. User. Master. Server1. Server2. Load. Hi. Low. Low. Weight. Hi. Med. High. 圖 2-13. Server3. Weighted Least-Connection. 20. 801.
(31) 2.6 Asterisk Asterisk 是一套以 Linux 作業系統為基準且為開放式的來源軟體 PBX，由 Digium 公司與不斷成長的使用者還有開發團隊的基礎共同創造，Digium 公司主要 投資在 Asterisk 原始碼和與 Asterisk 合作的低成本電話機製造法硬體兩者的發展。 Asterisk 不需要額外的硬體設備就可以執行網路電話的服務，來處理外撥和撥 入的通話。並且整合了數位和類比的電信設備，支援許多硬體設備，例如 E1 和 T1 的介面卡，並且還支援 FXO 和 FXS 等介面卡。並且可以將這些介面卡整合進 LAN 中並且成為 Asterisk 中可利用的設備。Asterisk 擁有整合性的服務能力，伺服 器間彼此互相聯繫，可以建立龐大的服務網絡，主要提供語音信箱目錄服務，視 訊會議，互動語音回應，呼叫排列。它有支援三方通話，來電顯示服務 因為 Asterisk 的模組開發能力，我們選定了 Asterisk 做為我們的系統。利用這 個模組開發能力，開發出了我們系統使用的一對多影音語音傳送程式來當作我們 系統架構的主骨幹。. 21.
(32) 2.7 現有系統架構 在現在的網路電話架構中已經有許多通訊模式[24-26]，一對一通訊模式、硬 體電話多對多、多人會議系統和群組廣播系統都是已經在使用的通訊模式，以下 小節將會逐一介紹。. 2.7.1一對一通訊模式 用戶一般撥打電話時都是採用一對一通訊模式[24]，發話端和受話端的連線狀 態會被伺服器記錄下來，如果在通話之中有新的通話請求進入，則會顯示插播。 因此無法支援多方通話的功能，但是一對一通訊模式中只要雙方條件許可下便可 以開啟影像傳輸的功能。. 用戶 801 RTP 伺服器. SIP 用戶 600. 用戶 800. 圖 2-14. 一對一通訊. 如圖 2-14 所示，用戶 800 和用戶 801 已經在進行通話，此時用戶 600 撥號給 用戶 800，用戶 800 會收到有新通話請求的訊息是否接受。如果接受原有的通話會 被中斷或是保留通話，並建立新的通道和用戶 600 連接。 從表 2-7 中我們可以看到此通訊模式的特性，用戶使用此架構時屬於較簡單的 部分，只需撥打號碼給想要對方就可以進行通訊過程。並且通話是雙方都可聽或 看到對方，影像部分則要是雙方支援的影像編碼決定。 22.
(33) 架構. 通訊模式 操作難易度 一對一. 簡單. 單/雙向. 成本. 串流能力. 雙向. 低廉. 影像、語音. 表 2-7. 與會型式. 一對一特性. 2.7.2硬體電話多人會議模式 因為一對一通訊模式無法滿足特定的需求，所以有廠商[25]對硬體電話的通訊 能力做進一步的提升。這些電話增加多點處理單元(MCU)，可跟使用相同產品的 用戶進行多人會議的能力，所以可以使用硬體電話進行多人會議模式。 IP Phone (MCU). IP Phone. IP Phone. IP Phone. 圖 2-15 硬體電話多方會議 如圖 2-15 所示，硬體電話用戶進行多人會議時，需要一台價格昂貴的硬體電 話做為會議中心，因為內建了硬體的編解碼器所以可以進行相對人數的多人視訊 會議。在表 2-8 中可以看到此架構是集中是架構，所有的通話都傳送至有ＭＣＵ的 電話，經處理後再轉送至各電話。操作方式比較簡單且是雙向的影音傳輸，但是 因為有ＭＣＵ的電話昂貴，所以成本昂貴。參與會議有撥打指定號碼進入和建立 會議室後由會議室外撥給指定的用戶加入。. 架構. 通訊模式. 操作難易度. 單/雙向. 成本. 串流能力. 集中式. 多對多. 簡單. 雙向. 昂貴. 影像、語音. 表 2-8. 與會型式 撥入. 硬體多對多特性. 2.7.3多人會議系統 上節所講的硬體電話多人會議系統[24][24]有先天性的缺點，就是只能使用同 公司且有支援多方會議的電話機台才能進行多方會議。網路電話伺服器程式提供 23. 外撥.
(34) 了一個多方會議的平台供人使用，只要是伺服器的用戶經過認證後都可以使用這 個功能，不論是電腦、智慧型手機上的軟體電話或是不同公司廠牌的硬體電話都 可以使用。因為伺服器效能的問題，至今仍只有提供語音會議的功能。如圖 2-16 所示，參與會議用戶的多媒體串流傳到伺服器後，伺服器會做混音的動作，再把 混音後的多媒體串流傳送至各用戶完成多方會議的功能。如表 2-9 所示同樣是集中 式的架構，且因為功能眾多，想要使用必頇經過繁瑣操作，因此操作較困難。通 訊型式則是只能語音的雙向溝通，因為是伺服器內建功能所以不需額外花費，參 與會議型式同樣有撥入跟外撥兩種。. 伺服器. 硬體電話. 硬體電話. 硬體電話. 硬體電話. 圖 2-16. 多方會議系統. 架構. 通訊模式. 操作難易度. 單/雙向. 成本. 串流能力. 集中式. 多對多. 困難. 雙向. 低廉. 語音. 表 2-9. 與會型式 撥入. 多人會議特性. 2.7.4群組廣播系統 因為 2.6.2 講的硬體電話會議功能價格高昂，所以業界[26]也做了群組廣播系 統的功能出來，架構在原有的伺服器上頭。只需要在網頁介面設定好相關參數， 立刻可以使用群組廣播系統。這個群組廣播系統和 2.6.3 的多人會議系統極為相似， 經由設定後用戶可使用此功能。群組廣播系統分為兩大方面，如圖 2-17 所示，第 一個方面是單向廣播功能，當用戶使用此功能時，會依據設定的參數內容把用戶 的訊息傳送至指定的其他用戶。因為是單向廣播，所以只能由一個用戶傳到其他 24. 外撥.
(35) 用戶，其他用戶在這次的廣播中是無法傳送出任何訊息的。如表 2-10 所示，一樣 是集中式架構且操作簡單的一對多單向傳輸。採用伺服器的應用程式不需額外設 備。參與者是由伺服器外撥後進行單項語音傳輸。. 伺服器. 用戶 用戶. 用戶 用戶 用戶 圖 2-17 單向廣播系統. 架構. 通訊模式. 操作難易度. 單/雙向. 成本. 串流能力. 與會型式. 集中式. 一對多. 簡單. 單向. 低廉. 語音. 外撥. 表 2-10. 單向廣播特性. 25.
(36) 如圖 2-18 所示，在伺服器上也支援了雙向的廣播系統功能和 3.3.3 的多人會議系統 相似，因為是雙向廣播功能，所以每位用戶只要參與會議都可以暢所欲言。在表 2-10 和表 2-11 中可以清楚看到兩者差異只在於雙向溝通和撥入加入會議的型式不 同。. 用戶. 用戶 用戶 伺服器. 用戶 用戶 用戶 圖 2-18. 雙向廣播系統. 架構. 通訊模式. 操作難易度. 單/雙向. 成本. 串流能力. 與會型式. 集中式. 多對多. 簡單. 雙向. 低廉. 語音. 撥入. 表 2-11. 2.7.5. 雙向廣播特性. 多人應用的問題. 在這幾個架構中，除了硬體電話外，只要是多人應用的部分都沒辦法傳送影 像，即使採用了昂貴的硬體電話當作 MCU 也只能做少路的影像傳輸。沒有影像的 多媒體服務就失去了多媒體應用的優勢所在。. 26.
(37) 2.8 IPTV IPTV 由[1-4]制定規範，並且正在商業運轉中。IPTV 採用網路封包交換網路 取代傳統電視用無線傳輸或是第四台業者用專線傳輸。 採用 IPTV 有以下優缺點 優點: . 採用網路傳輸可使用頻寬較大、提供高畫質節目. . 只需傳送用戶正在觀看的節目節省頻寬. . 節省第四台業者架設專線的費用. . 可和其他網路服務整合. 缺點: . 對頻寬有較高的要求. . 對網路延遲敏感. . 用戶觀看節目行為被業者掌握. IPTV 主要的發展模型如圖 2-19，分為四大區塊:內容提供商將內容交給服務提 供者後再藉由網路提傳送給 IPTV 用戶的電腦或是機上盒。. Content Provider. Service Provider. Network Provider. IPTV Consumer. 圖 2-19 典型 IPTV 發展模型 IPTV 主要以提供電視廣播、隨選視訊作為服務項目。電視廣播採用 IGMP 在 IPV4 下作 Multicast stream。而隨選視訊則是用 RTSP 來做為串流控制。IPTV 近來 也提出改良架構，採用 SIP 管理會議建立。並且結合 IMS(IP Multimedia Subsystem) 提供更多元的多媒體服務。. 27.
(38) 第三章 系統架構. 網路電話的應用都是在個人使用方面，如同第二章介紹的多人的架構缺乏多 媒體應用，造成網路電話用量沒有大幅度的上升。本研究中著重在圖 1-1 的一傳多 的影像傳輸服務。我們的系統架構和現有網路電話相容。使用同樣的網路電話元 件和協定。在本研究中伺服器端只需要透過 UA 提供的電視頻道訊號源，就可以 提供多名使用者觀看的系統。如圖 3-1 所示整個系統分成兩大部分[16]，影音伺服 器群組的伺服器區塊和提供區域性服務的伺服器區塊所組合起來。當用戶只需本 地服務時不連接到影音伺服器區塊，和一般正常使用無異。如果需要和影音伺服 器群組連線時，則透過區域性伺服器和影音伺服器群組建立連線再把影音訊息轉 傳給用戶。. 影音伺服 器群組. 路由器. 硬體電 話用戶. 社區網路. 公眾網路 區域性 伺服器. 軟體電話 用戶. 路由器. 路由器. 軟體電話 用戶. 區域性 伺服器. 公司校園 內部網路 軟體電話 用戶. 軟體電話 用戶. 圖 3-1. 系統架構圖. 28.
(39) 影音伺服器群組可採用負載平衡提高服務量，如圖 3-2，當用戶透過區域性伺服器 轉送請求到影音伺服器區塊時，該請求會先傳送至 Master 再轉送到適當的 Slave， 由 Slave 為用戶提供正確的服務。當 Master 不堪負荷時則透過備援機制啟動備援 的 Master 加入服務舒緩系統承載，Slave 超過承載時也會起動備用的 Slave 來提供 服務。. 備用 Slave. 訊號用戶. 備用 Master Slave. Master. Router 圖 3-2. 影音伺服器區塊. 29.
(40) 3.1 架構元件 在本研究中使用到了一些基本的 SIP 元件，註冊伺服器、位置伺服器…等等。 以下將分別對區域性和影音伺服器群組兩區塊使用元件做介紹，其中的註冊伺服 器和位置伺服器兩個區塊都會使用。 . 註冊伺服器. 註冊伺服器在這邊提供用戶的 User Agent 做註冊的動作，用戶所註冊的相關資料 皆存至位置伺服器中儲存。 . 位置伺服器. 存放用戶 User Agent 做註冊時傳送的相關資料。當用戶做任何會議請求時，階會 和位置伺服器做溝通以取得所需要的用戶資料。當用戶離開時也會把用戶資料做 進一步的更新。. 3.1.1區域性伺服器 . SIP Server. 是最主要的核心，提供用戶一切的服務。用戶做會議請求或是任何服務時’都是透 過此伺服器運行。SIP Server 也扮演一個區域和影音伺服器群組溝通的橋樑，如用 戶的需求是要影音伺服器的功能時，便會代為轉送。 . User Agent. 用戶的代理程式或是硬體，用戶的軟體電話、數位機上盒或是硬體的 IP Phone。. 3.1.2影音伺服器群組 . SIP Server. 分為 Master 和 Slave 兩部分，Master 主要做分散負載到底下 Slave 的工作。Slave 則 是提供電視廣播的服務給使用者。另外有備源的 Master 和 Slave 當運轉中的伺服 器承載量過大時，則啟用備援伺服器。 . 訊號提供者. 提供電視影音訊號的角色，透過 UA 對影音伺服器提供影像。. 30.
(41) 3.2 運作流程圖 用戶. 區域伺服器. 伺服器. INVITE INVITE. 100 Trying 200 OK. 100 Trying 200 OK ACK. ACK Media Stream. Media Stream. 圖 3-3. 運作流程. 如圖 3-3，已註冊在伺服器上的用戶撥特定號碼到伺服器請求服務。 . 用戶發出 INVITE 訊息給區域伺服器. . 區域伺服器發現需要影音伺服器支援，轉送給影音伺服器. . 影音伺服器收到請求訊息後回傳 100 Trying 給區域伺服器. . 區域伺服器接收到影音伺服器 100Trying 後轉送給用戶. . 影音伺服器確認可提供服務時回傳 200 OK 表時可提供服務. . 區域性伺服器收到 200 OK 時轉傳給用戶. . 用戶發送 ACK 表示收到 200OK 的訊息. . 區域性伺服器轉傳給影音伺服器 用戶的 200OK 訊息. . 用戶和伺服器間建立多媒體串流，開始影音服務. 31.
(42) 透過圖 3-4 的簡易系統示意圖，來講解我們程式運作的流程: . 訊號提供者透過先透過撥號和伺服器做連接. . 伺服器儲存電台資訊在伺服器中. . 用戶撥打指定的號碼進入伺服器，想使用本研究的服務. . 伺服器驗證使用者群組身分，判別可使用的服務. . 伺服器將用戶資訊儲存至電台用戶中. . 伺服器開始建立和用戶間的串流通道，並且開始傳輸. 當每個用戶所想觀賞的是同一頻道時，伺服器會把同一份頻道影音轉傳給觀 看這頻道的用戶，以達到一傳多的目的。. 圖 3-4. 簡易系統示意圖. 32.
(43) 3.3 伺服器程式 我們使用的 VOIP Server 系統是 Asterisk 1.6.0.25 版本，在 Asterisk 中並沒有我 們需要的功能。我們必頇自行撰寫所需功能的程式，並且加掛在 Asterisk 上運行。 我們使用了 channel Structure 當作我們傳送通道的主體，並且採用訊號源和接收用 戶獨立處理的方式完成了這個程式。並且異於他人之處就是我們的程式可以傳送 影像，絕大多數的程式都只能做語音的多人傳送，經過我們的努力後終於完成了 這個影音傳輸系統。 當用戶發出請求給伺服器要起動電視影音服務時，會先經過伺服器內部驗證用戶 資格，如果條件符合會轉至相對應的服務流程。如圖 3-5 所示用戶已經開始執行影 音服務的程式了，系統會先擷取參數，並且驗證參數是否正確。並且從其中資訊 判別為影音用戶，便進入到接收影音程式。 如圖 3-6 進入影音接收程式同樣會先擷取所需參數並且驗證參數正確性，隨後 檢查影音提供平台是否已經在運行，如果尚未運行則等待一定時間後再繼續檢查 平台是否建立了，當嘗試失敗次數過時多則結束程式。如電台已經建立，則把所 需用戶資料登入到平台資訊中，並且開始運行影音接收。 同樣的，如圖 3-7 影音平台的訊號提供者也要經過伺服器認證後才能進入程式。 執行影音傳送程式時，會經過檢測影音平台是否重複，如重複會立刻離開程式。 如果尚未建立影音平台，則立刻建立平台相關資訊，並檢測是否有用戶進入，如 果尚未有用戶進入程式則進入休眠一定時間再檢測，如有用戶則開始影音傳送程 式。. 33.
(44) 圖 3-5. 主流程圖. 34.
(45) 圖 3-6. 接收端流程圖. 35.
(46) 圖 3-7. 傳送端流程圖. 36.
(47) 3.4 系統特點 一對多 傳統網路電話單一話機只能同時跟一個用戶連線，所以當想做多人應用的服 務時，只能採用一對一的服務，增加資源負擔。過系統可以將一筆資源同時使用 在多個用戶上，節省負擔。. 影像傳送 一般網路電話在一傳多的狀態下只能傳送語音，或是利用價格昂貴有多點處 理單元(MCU)功能的硬體電話來做中央控管，此類電話價格昂貴且能參語的人數 極少。使用我們的系統只需要有跟訊號源一樣的編碼即可收看。. 用戶端操作模式不變 依循舊有的操作模式，同時也和大家平常所熟悉的傳統電話(PSTN)系統的使 用模式相同。只需撥打指定的頻道號碼，也就是一般使用遙控器選台一樣。. 系統架構不變 系統架構和傳統網路電話系統一致，只在 SIP Server 上增加一傳多的服務應用 程式。用戶區域性伺服器和影音伺服器群組做溝通。. 可透過平衡負載增加服務量 透過平衡負載機制，將請求建立的會議傳送給適當的伺服器處理。透過這個 機制就可以提高系統容量。. 37.
(48) 3.5 架構比較 3.5.1. 網路電話架構. 透過表 3-1 我們可以了解目前多方會議除了有昂貴多點處理單元(MCU)的硬體，並 沒有其它可以提供影像的服務。. 一對一 網路電話最常見的服務模式 優點:一對一通話下提供邊碼配對功能 缺點:只能一對一，無法對多人服務. 硬體多對多 提供少人數的影音會議 優點:在多人會議中提供了影像傳送，採用硬體解碼、處理效能高 缺點:多點處理單元(MCU)的機台昂貴，最大通話決定於數硬體解碼器數量. 多人會議 最普遍的會議系統 優點:簡單易用的系統 缺點:沒有影像傳輸功能. 群組廣播 新型態的多方會議應用 優點:單方和雙向廣播設定簡單 缺點:沒有影像. 本論文 本論文所提出系統架構 優點:有影像傳輸 缺點:用戶必頇採用訊號源一樣的編碼才能收看. 38.
(49) 架構. 一對一. 硬體多 對多. 多人會 議. 群組廣 播. 電視廣 播. 通訊模 設定難. 單/雙. 式. 易度. 向. 一對一. 簡單. 雙向. 集中式 多對多. 簡單. 成本. 低. 雙向. 高. 串流能 力. 影像 語音. 影像 語音. 適用情境. 與會型式. 一般通話. 撥入 多方會談 撥出 撥入. 集中式 多對多. 困難. 雙向. 低. 語音. 多方會談 撥出. 一對多 集中式. 單向 簡單. 多對多. 集中式 一對多. 低. 單向. 表 3-1. 低. 架構比較表. 39. 撥出. 多方會談. 撥入. 語音. 雙向. 簡單. 校園廣播. 影像. 電視廣播. 語音. 單向分享. 撥入.
(50) 第四章 數據量測和數據分析. 在本章節中主要測試伺服器端的系統承載能力和客戶端的多媒體服務品質， 伺服器端透過模擬用戶對伺服器進行模擬通畫方式測試。客戶端則透過擷取 RTP 封包方式，檢測 RTP 封包遺失、延遲和延遲抖動等參數。. 4.1. 系統負載測試 本測試主要目標是找出影響伺服器服務量的主要原因，測試一台伺服器後再 對另一台伺服器做測試以驗證我們的想法。測試設備有表 4-1 的設備 A 和設備 B， 因設備 A 最到達高上限時 CPU 使用量滿載，因此透過設備 B 以較高的同時在線數 量驗證出影響負載量的主因是 CPU。 圖例. 頻道1號 串流 伺服器 頻道2號 串流 頻道3號 串流 頻道4號 串流. 交換器 訊號用戶. ……… 模擬用戶. 圖 4-1. 測試架構圖. 我們測試系統架構如圖 4-1 所示，訊號用戶做為頻道的訊號來源，而模擬用戶 則是使用 SIPp 做為這次測試的程式，SIPp 具有 UAC 和 UAS 的能力並且可以傳送 和接收 SIP 封包。模擬用戶分別向伺服器要求建立連線，分別要求和頻道 1 至頻 道 4 建立連線。SIPp 會記錄連線建立的相關資訊在電腦中，提供使用者觀察、分 40.
(51) 析結果。其中伺服器規格如表 4-1 所標明。表 4-2 標明我們這次測試的項目，測試 的總通數為 1500 通，測試的頻道為單、雙、四頻道，同時在線數 240 通、220 通、 200 通、180 通、160 通. 設備 CPU RAM. A. B. Intel Celeron D. Intel Core 2. 3.2GHZ. Duo E7500. 512MB. 2048MB. OS. CentOS 5.4. SIP proxy. Asterisk 1.6.0.25 表 4-1. 伺服器規格. 測試總通數 測試頻道數 測試在線數 測試編碼. 1500 通 單頻道 240 通. 雙頻道 220 通. PCMA. 200 通. 四頻道 180 通. 160 通. H.263. 表 4-2 測試項目 設備 A 雙頻道在 240 通、220 通測試伺服器皆無法穩定執行，四頻道在 240 通、 220 通、200 通測試伺服器皆無法穩定執行，以上伺服器無法穩定執行者皆因無參 考價值不列出數據。. 4.1.1. 240 通 我們測試通數從 240 開始是因為超過 240 後，伺服器會錯誤過多無法穩定運 行所以從伺服器可以持續運行的 240 通開始討論我們量測的數據成功通數如圖 4-2 所示，1500 通中成功 1483 通，失敗 17 通。CPU 使用率如圖 4-3 所示，CPU 使用 率達到 100%後，就維持在 100%不變的高速運轉狀態下。而記憶體使用量如圖 4-4 所示，大約使用了 30MB 的記憶體空間。. 41.
(52) 240通成功通數 1483. 1500. 1000 通 數. 成功. 500. 失敗 17 0 單頻道 測試頻道數. 圖 4-2. 240 通成功通數比較. 240通CPU比較 100 C P U. 80. %. 20. 60 40 單頻道. 0 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241 經過時間(秒). 圖 4-3. 240 通 CPU 使用率比較. 240通MEM比較 350000 記 340000 憶 330000 體 320000 K B. 310000. 單頻道. 300000 290000 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241 經過時間(秒). 圖 4-4. 240 通記憶體比較 42.
(53) 4.1.2. 220 通 220 通成功通數如圖 4-5 所示，成功通數 1499 通，失敗 1 通。比起 240 通失敗 通數已經降到剩下一通。CPU 使用率如圖 4-6 所示，CPU 使用率到達 100%後仍然 維持在 100%高速運轉狀態下。而記憶體使用量如圖 4-7 所示，記憶體使用量大約 是 25MB。. 220通成功通數 1499. 1500. 1000 通 數. 成功. 500. 失敗 1 0 單頻道 測試頻道數. 圖 4-5. 220 通成功通數比較. 220通CPU比較 100 C P U. 80. %. 20. 60 40 單頻道. 0 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241 經過時間(秒). 圖 4-6. 220 通 CPU 使用率比較. 43.
(54) 220通記憶體比較 320000 記 310000 憶 300000 體 290000 K B. 280000. 單頻道. 270000. 260000 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241 經過時間(秒). 圖 4-7. 220 記憶體比較. 4.1.3. 200 通 200 通時雙頻道已經伺服器可以穩定運作但是錯誤率極高。200 通成功通數如 圖 4-8 所示，單頻道的成功通數達到 1500 通。而雙頻道成功通數 580 通，失敗 920 通，失敗的通數遠高於成功通數。CPU 使用率如圖 4-9 所示，單頻道和雙頻道使 用率到了 100%後一樣維持 100%的高負載不變。記憶體使用量如圖 4-10 所示，單 頻道和雙頻道都使用大約 20MB 的記憶體空間。. 測試200通比較 1500. 1500. 920. 1000. 通 數. 580 500. 成功 失敗. 0. 0. 單頻道. 雙頻道 測試頻道數. 圖 4-8. 200 通成功通數比較 44.
(55) 200通CPU比較 100 C P U %. 80 60 40. 單頻道. 20. 雙頻道. 0 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241 經過時間(秒). 圖 4-9. 200 通 CPU 使用率比較. 200通記憶體比較 310000 記 300000 憶 290000 體 280000 K B. 270000. 單頻道. 260000. 雙頻道. 250000 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241 經過時間(秒). 圖 4-10. 200 通記憶體比較. 4.1.4. 180 通 到了 180 通單頻道、雙頻道和四頻道伺服器都穩定運作，雙頻道相較於 200 通的高錯誤率有明顯改善。成功通數如圖 4-11 所示，單頻道 1500 通成功，雙頻道 成功通數 1008 超越了失敗通數 492 通，成功通數是失敗通數的兩倍。四頻道則是 成功 475 通，失敗 1025 通，失敗為成功的 2 倍。CPU 使用率如圖 4-12 所示，單 頻道使用率在 80%~100%之間震盪，雙頻道和四頻道則維持 100%高速運轉。記憶 體方面如圖 4-13 所示，不論單頻道、雙頻道和四頻道都大約使用 20MB 的記憶體 空間。. 45.
(56) 測試180通比較 1500. 1500. 1025. 1008 1000 通 數. 492. 500. 475. 成功 失敗. 0. 0. 單頻道. 雙頻道. 四頻道. 測試頻道數. 圖 4-11. 180 通成功通數比較. 180通CPU比較 100 C P U. 80. %. 20. 60 單頻道. 40. 雙頻道 四頻道. 0 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241. 經過時間(秒). 圖 4-12. 180 通 CPU 使用率比較. 180通記憶體比較 310000 記 300000 憶 290000 體 280000 K B. 單頻道. 270000. 雙頻道. 260000. 四頻道. 250000 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241. 經過時間(秒). 圖 4-13. 180 通記憶體比較 46.
(57) 4.1.5. 160 通 到了 160 通單頻道和雙頻道表現良好，四頻道錯誤通數也大幅下降。 成功通數如圖 4-14 所示，雙頻道失敗通數急遽下降至 8 通，而四頻道失敗通數也 降至 171 通，四頻道的失敗通數比起測試 180 時的 1025 通有相當大的差距。 CPU 使用率如圖 4-15 所示，單頻道和雙頻道 CPU 使用率在 70%附近震盪，而四 頻道仍然維持在 100%的負載。記憶體使用率如圖 4-16 所示，大約使用 15MB 的 記憶體空間。. 測試160通比較 1500. 1500. 1492 1329. 1000 通 數. 成功. 500 171 0. 8. 單頻道. 雙頻道. 0. 失敗. 四頻道. 測試頻道數. 圖 4-14. 160 通成功通數比較. 160通CPU比較 120 C P U. 100. 80 60. 單頻道. 40 %. 雙頻道. 20. 四頻道. 0 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241 經過時間(秒). 圖 4-15. 160 通 CPU 使用率比較. 47.
(58) 160通記憶體比較 310000 記 300000 憶 290000 體 280000 K B. 單頻道. 270000. 雙頻道. 260000. 四頻道. 250000 1. 21. 41. 61. 81 101 121 141 161 181 201 221 241 經過時間(秒). 圖 4-16. 4.2.6. 160 通記憶體比較. 320 通. 透過圖 4-17、4-17，設備 B 的 CPU 使用率在 320 通分別測試單頻道、雙頻道、 四頻道下的 CPU 使用率，單頻道使用率平均值大約分別在 1%、雙頻道 CPU 使用 率在 5%和四頻道 CPU 使用率在 15%附近。由此可見，CPU 的效能決定了系統用 戶的乘載量，而記憶體使用量在 40MB 附近所以此服務對記憶體需求不高。圖中 有脈衝型式的圖形，是因為我們設定用戶進入等待 60 秒後會離開在進入，造成伺 服器瞬間的負載。. 320通CPU比較 60 C P U 使 用 率 %. 50 40 30. 單頻道. 20. 雙頻道. 10. 四頻道. 0. 1. 21. 41. 61. 81. 101. 121. 141. 161. 181. 經 過時間(秒). 圖 4-17. 320 通 CPU 使用率. 48. 201. 221. 241.
(59) 320通記憶體比較 記 憶 體 K B. 1980000 1970000 1960000 1950000 1940000 1930000 1920000 1910000 1900000 1890000. 單頻道 雙頻道 四頻道. 1. 21. 41. 61. 81. 101. 121. 141. 161. 181. 201. 221. 241. 經 過時間(秒). 圖 4-18. 320 通記憶體使用量. 4.2. 數據分析 經由表 4-3 的數據告訴我們，成功通數取決於 CPU 處理能力，如果 CPU 使用 率到達 100%時，在往上增加通數會造成錯誤率的提升。並且透過數據我們可以得 知單頻道在 200 通時可以達到 100%的成功率，雙頻道在 160 通時 CPU 使用率低 於 100%，所以測試結果也接近 100%的成功率，而四頻道在 160 通 CPU 使用率仍 然維持在 100%，並且有 171 通的錯誤。透過表 4-4 的設備 B 數據，我們可以證實 我們的說法無誤，效能較好的 CPU 可以提供較多服務量。 測試通數 頻道數 單頻道. 240 通 17 通 100%. 220 通. 200 通. 180 通. 160 通. 1通. 0通. 0通. 0通. 100%. 100% 920 通. 雙頻道. 100%. 80~100%. 70~80%. 492 通. 8通. 100% 1025. 四頻道. 100% 表 4-3. 設備 A 數據整理. 49. 70~80% 171 通 100%.
(60) 測試通數 頻道數. 320 通 0通. 單頻道 1%. 0通. 雙頻道 5%. 0通. 四頻道 15% 表 4-4. 設備 B 數據整理. 4.3. 多媒體服務品質測試 在本節中是測試用戶端的多媒體服務品質，透過封包擷取的方式量測出影響 服務品質的”封包遺失”和”封包延遲”，並且在不同網路架構下進行測試動作，以期 望達到模擬用戶於實際使用服務下各種網路架構的情形。在本測驗中除了單獨使 用服務外，另外主要採用不限制 FTP 的流量來造成對客戶端的影響，以此做為大 流量對客戶端的影響。. 4.3.1. 測試架構 我們所選的測試架構主要以 24-port 交換器做為骨幹的基礎下更變用戶端所使 用的網路環境，有如圖 4-19、圖 4-20 採用 Hub 模擬的架構和圖 4-21 採用交換器 以及圖 4-22、圖 4-23 在 WiFi 網路架構下的數據量測。 在圖 4-19 中 FTP 用戶在共用頻寬處做下載的動作，而圖 4-20 則是 FTP 伺服 器在共用頻寬處做上傳動做，以此做為流量在不同方向下對用戶端造成的影響做 分析。. 50.
(61) 交換器. Hub. FTP用戶. VOIP伺服器. 硬體電話. FTP伺服器 圖 4-19. 共用頻寬架構圖(一). 交換器. Hub FTP用戶. VOIP伺服器. 硬體電話 封包擷取. FTP伺服器. 圖 4-20 共用頻寬架構圖(二) 圖 4-21 則是獨立頻寬架構下利用 FTP 做下載流量對用戶造成影響的數據量測。 圖 4-22 除了原有的交換器外，又接上一台 8-port 交換器模擬用戶端再使用同一個 非企業用交換器對外連接的情形。. 51.
(62) 交換器. VOIP伺服器. FTP、VOIP 用戶. FTP伺服器 圖 4-21. 獨立頻寬架構圖. 圖 4-22 和圖 4-23 在 WiFi 環境下對服務品質做測試，在圖 4-23 中使用同一台 電腦做服務品質測試和使用 FTP 流量影響。在圖 4-24 中則是將 FTP 用戶獨立出來 到另一台電腦，希望量得無線網路封包碰撞造成的影響。圖 4-24 中是測試伺服器 在高負載狀況下對用戶造成的影響。. 交換器 WiFi VOIP伺服器. FTP、VOIP 用戶. FTP伺服器 圖 4-22. WiFi 架構圖(一). 52.
(63) 交換器 WiFi VOIP伺服器. VOIP用戶 FTP伺服器. FTP用戶 圖 4-23. WiFi 架構圖(二). 交換器. Hub. FTP用戶. VOIP伺服器. 硬體電話. FTP伺服器 圖 4-24. 伺服器負載對用戶影響測試架構圖. 4.3.2. 數據與分析 在表 4-5 中可以看出共用頻寬的情形下，在有大流量的情形造成 RTP 封 包嚴重發生的錯誤，並且在高於 256K 的流量時會造成 RTP 封包的中斷，導 致通話結束。在表 4-6 中因為是獨立頻寬的情形，不限速度的 FTP 流量對用 戶的影音品質造成的影響不大，只有在 FTP 開始傳輸的瞬間造成短暫的封包 遺失。而表 4-7 和表 4-8 的 WiFi 架構不限 FTP 的速度下，造成的影響也不大， 最嚴重只有 1.1%的封包遺失。. 53.
(64) 編碼. 封包遺失(%). 最大延遲(ms). 最大抖動(ms). H.263. 0. 25.51. 26.02. PCMU. 0. 29.89. 3.79. 建立通話後大 H.263. 4.2. 197.95. 28.63. 流量(256K). 3.9. 142.46. 6.21. 建立通話前大 H.263. 14.7. 166.36. 31.45. 流量(256K). 15.2. 185.91. 5.91. 一般. PCMU. PCMU 編碼. 表 4-5 共用頻寬架構 封包遺失(%) 最大延遲(ms). 最大抖動(ms). H.263. 0. 72.85. 31.83. PCMU. 0. 41.48. 5.05. 建立通話後大 H.263. 3.3. 274.22. 32.94. 流量. 3. 243.81. 6.87. 建立通話前大 H.263. 2.5. 176.18. 34.54. 流量. 2.6. 138.50. 5.05. 一般. PCMU. PCMU 編碼. 表 4-6 獨立頻寬架構 封包遺失(%) 最大延遲(ms). 最大抖動(ms). H.263. 0. 67.45. 30.76. PCMU. 0. 36.56. 5.31. 建立通話後大 H.263. 1.1. 306.7. 46.15. 流量. 1.1. 303.7. 23.42. 建立通話前大 H.263. 0. 83.98. 36.76. 流量. 0. 72.45. 8.96. 一般. PCMU. PCMU. 表 4-7 編碼. WiFi 架構 (一). 封包遺失(%). 最大延遲(ms). 最大抖動(ms). 建立通話後大 H.263. 0. 123.82. 34.43. 流量. 0. 129.31. 17.68. 建立通話前大 H.263. 0. 42.26. 32.04. 流量. 0. 32.94. 4.92. PCMU. PCMU. 表 4-8. WiFi 架構 (二) 54.
(65) 透過表 4-9 和表 4-10 的封包延遲數據可以了解到，封包最大延遲都在 100ms 以下， 伺服器的負載對於使用者的影響不會太大。. 項目 測試通數 單頻道 240 雙頻道 200 四頻道 180 項目 測試通數 單頻道 320 雙頻道 320 四頻道 320. 最大封包延遲 最大封包抖動 (ms) (ms) H.263 84.45 32.78 PMCA 51.93 6.09 H.263 88.35 40.73 PMCA 75.94 11.83 H.263 91.62 35.81 PMCA 62.22 9.52 表 4-9 設備 A 封包延遲數據表 最大封包延遲 最大封包抖動 編碼 (ms) (ms) H.263 92.26 31.59 PMCA 69.93 10.58 H.263 97.19 34.29 PMCA 86.84 16.04 H.263 86.06 32.54 PMCA 97.19 17.51 表 4-10 設備 B 封包延遲數據表 編碼. 55. 平均封包抖動 (ms) 27.70 3.68 38.72 4.74 35.49 4.67 平均封包抖動 (ms) 27.60 6.64 27.24 11.53 30.13 13.66.
數據
+7
相關文件
2013 Workshop on Nonlinear Analysis, Optimization and Their Applications, De- partment of Mathematics, National Kaohsiung Normal University, Kaohsiung, Tai- wan, December 30,
Professor of Computer Science and Information Engineering National Chung Cheng University. Chair
2 Department of Materials Science and Engineering, National Chung Hsing University, Taichung, Taiwan.. 3 Department of Materials Science and Engineering, National Tsing Hua
Department of Physics and Institute of nanoscience, NCHU, Taiwan School of Physics and Engineering, Zhengzhou University, Henan.. International Laboratory for Quantum
Assistant Professor, Industrial Engineering and Management Chaoyang University of Technology. Chen Siao Gong JULY 13 , 2009 Chen
電機工程學系暨研究所（ EE ） 光電工程學研究所(GIPO) 電信工程學研究所(GICE) 電子工程學研究所(GIEE) 資訊工程學系暨研究所（CS IE ）
The criterion for securing consistence in bilateral vicinities is to rule out the pairs which consist of two cliff cell edges with different slope inclination but the pairs
ADSL（A symmetric D igital S ubscriber L ine ，非對稱數位
