以SIP為基礎結合Web界面的分散式多功能服務系統

全文

(1)逢. 甲. 大. 學. 資訊工程學系專題報告以SIP為基礎結合Web界面的分散式多功能服務系統. 學. 生：曾秉鈞鄭龍凱蕭煒翰林聖凱. (四丁) (四丁) (四丁) (四丁). 指導教授：李維聰中華民國九十二年十月.

(2) 以SIP為基礎結合Web界面的分散式多功能服務系統. 目. 錄. 第一章前言 ...................................... 2 第二章研究動機及目的 ....................... 3 第三章系統原理及分析 ....................... 4 3.1 SIP 協定 .............................. 4 3.2 SOCKS 協定 ........................... 12 3.3 JMF架構及研究......................... 15 3.4 NAT 與區域網路的限制與解決方式 ....... 30 3.5 Java Web Start架構說明 ................. 38 第四章系統架構及實作 ....................... 40 4.1 整體架構概觀 .......................... 40 4.2 端點協定 .............................. 41 4.3 模組管理系統 .......................... 61 4.4 視訊會議系統 .......................... 66 4.5 影音留言系統 .......................... 80 4.6 檔案傳送系統 .......................... 101 4.7 電子白板系統 .......................... 103 4.8 線上投票系統 .......................... 109 第五章實驗結果及比較 ....................... 112 第六章操作手冊 ................................ 114 第七章貢獻 ...................................... 126 第八章感言 ...................................... 127 參考文獻 .......................................... 128. 1. 逢甲大學 e-Paper (92學年度).

(3) 以SIP為基礎結合Web界面的分散式多功能服務系統. 第一章. 前. 言. 隨著寬頻網路的逐漸普及，一些以往因為頻寬限制所做不到的多媒體傳輸在頻寬上已經不成問題，許多與此有關的應用軟體也越來越多﹝如：MSN Messanger、NetMeeting、Yahoo Messanger…等﹞。雖然這些應用軟體的功能都很強大，但是仍然有一些更理想的功能可以達到，本專題就是為此而產生，希望能夠完成一套功能更完整的視訊會議軟體。. 2. 逢甲大學 e-Paper (92學年度).

(4) 以SIP為基礎結合Web界面的分散式多功能服務系統. 第二章. 研究動機及目的. 隨著寬頻網路的逐漸普及，一些以往因為頻寬限制所做不到的多媒體傳輸在頻寬上已經不成問題，許多與此有關的應用軟體也越來越多﹝如： NetMeeting、msn…等﹞。雖然這些應用軟體的功能都很強大，但是仍然有一些更理想的功能可以達到，本計畫就是為此而產生，希望能夠完成一套功能更完整的視訊會議軟體。本計畫所希望達到的目的除了一般視訊會議所需的多媒體即時傳輸、電子白板之外，還包括了影音留言服務、本地端多媒體串流紀錄服務、線上會議投票服務、檔案傳遞服務、網路電話、多人混音，使得整個會議能夠有更完整、更方便的功能，除此之外更希望能夠穿越防火牆以及 NAT 之間的互相連結。 Ø Ø Ø. Ø Ø Ø. Ø. 多媒體即時傳輸：使用者們可以即時看到對方的影像、聲音，更能拉進彼此之間的距離。電子白板：提供繪圖界面，並將本地所繪圖的資訊傳至多個遠端使用者。影音留言服務：當使用者不在的時候，其他人可以透過此服務留下影音訊息給使用者，而當使用者上線時除了可以透過本軟體收下訊息外、亦可以透過網頁觀看訊息，以達到只要有網路的地方就不怕會漏掉任何一筆重要的訊息。並且，使用者也可以透過此服務達到類似答錄機的功能。本地端多媒體串流服務：由於是視訊會議，所以讓使用者可以隨時錄下會議中的影像及聲音，以供日後參考。線上會議投票服務：在會議中，不免會需要投票，所以讓與會者可進行即時的線上投票並且馬上可以得到投票的結果。檔案傳遞服務：以檔案分割的方式，將分享的檔案是格式化的方式，切成不同的片段，加快了檔案傳遞的速度，以達到只要有其檔案片段的來源就可以同時向不同來源下載其所需的檔案內容。網路電話：藉由網際網路無遠弗界的特性，以專有的通話協定建立、結束並管理通話期間的影音串流，因為網際網路的廣域性，使用者無須透過越洋電話與其他人聯絡，因而減低通話的成本。. 3. 逢甲大學 e-Paper (92學年度).

(5) 以SIP為基礎結合Web界面的分散式多功能服務系統. 第三章系統原理及分析 3.1 SIP 協定概觀與實作架構 3.1.1 SIP 協定概觀 Session Initiation Protocol﹝SIP﹞是一套定義於應用層的連線控制協定，其主要功能在於多個參與者之間會議的建立、修改以及終止，會議可包含網路視訊會議、網路電話連線以及多媒體資源的散佈，會議裡參與者可透過群播、單點傳播甚至是合倂兩者的機制與其他參與者溝通。 SIP 通訊協定的訊息格式十分類似 HTTP﹝Hypertext Transport Protocol﹞，這個通訊協定的訊息是以 ISO10646 UTF-8 的純文字格式編碼，以該方式做為傳遞的訊息格式，其優點在於無作業系統平台上的限制，因而實作者無須考慮到發展平台之間的相異處，使用 Java、Tcl 和 Perl 等程式語言皆可輕易實作出來，而 SIP 通訊協定最大的優勢是在它的彈性及延伸性，加上 SIP 的主要功能在建立視訊會議，相較於視訊會議期間的大量媒體串流，建立會議之前所需要的額外 SIP 控制訊息便不影響連線的品質。 SIP 訊息可分為請求﹝Request﹞和回應﹝Response﹞訊息，它是使用 RFC822 所定義的通用訊息格式﹝Generic-Message Format﹞，兩種訊息皆包括起始行﹝start line﹞、一個以上的標頭欄位﹝headers﹞、一行空白行 ﹝僅包括 CRLF﹞以及選擇性(可有可無)的訊息內容﹝message body﹞，下圖是通用訊息格式的 ABNF。. generic-message = start-line *message-header CRLF [ message-body ] start-line. = request-Line | status-Line. message-header = ﹝ general-header | request-header | response-header | entity-header ﹞. 4. 逢甲大學 e-Paper (92學年度).

(6) 以SIP為基礎結合Web界面的分散式多功能服務系統. a.. 請求訊息﹝Request﹞ 請求訊息的格式如下圖： Request = Request-Line *﹝ general-header | request-header | entity-header ﹞ CRLF [ message-body ] 請求訊息的方法可分為：ACK、BYE、CANCEL、INVITE、OPTIONS、 REGISTER。當發話端欲初始一個通話連線，可傳送一個 INVITE 的 SIP 請求訊息；終止一個通話連線則可傳送一個 BYE 的 SIP 請求訊息：下圖即為兩個端點之間的簡易呼叫流程範例：. n. 呼叫流程說明如上圖所示，發話端 A 欲透過兩個代理伺服器(Proxy1 和 Proxy2) 向使用者 B 要求建立通話連線，Proxy1 的進行訊息轉傳前需要使用者進行認證手續，但發話端 A 起初並未將認證資訊(F1)存放在訊息之中，因此代理伺服器回傳一個認證需求的回應訊息通知發話端進行下次的認證步驟(F2)。當發話端 A 再次傳送含有認證資訊的邀請訊息後(F4)，使用者 B 接受該通話請求並開始進行通話，而後，當使用者 B 傳送 BYE 請求訊息之後，通話連線便結束。. 5. 逢甲大學 e-Paper (92學年度).

(7) 以SIP為基礎結合Web界面的分散式多功能服務系統 ². F1 - INVITE A -> Proxy 1 通話連線的開始是透過某個端點傳送 INVITE 請求訊息，其訊息內容如下圖所示，在這個訊息傳遞流程的範例中，要求訊息內容包括了會議描述請求(Session Description Request)。 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-ID: [email protected] CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000. ². F2 - 407 Proxy Authorization Required Proxy 1 -> User A SIP 協定是以請求―回應模式進行訊息的傳遞，在這個範例中，Proxy1 要求發話端 A 需先進行認證步驟。 SIP/2.0 407 Proxy Authorization Required Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-ID: [email protected] CSeq: 1 INVITE Proxy-Authenticate: Digest realm="MCI WorldCom SIP", domain="wcom.com", nonce="wf84f1ceczx41ae6cbe5aea9c8e88d359", opaque="", stale="FALSE", algorithm="MD5". 6. 逢甲大學 e-Paper (92學年度).

(8) 以SIP為基礎結合Web界面的分散式多功能服務系統. ². F17 ACK Proxy2 -> UserB 當我們察看呼叫流程的下方，可發現實際的聲音串流傳送是以 Realtime Transport Protocol(RTP)處理。 ACK sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP ss2.wcom.com:5060 Via: SIP/2.0/UDP ss1.wcom.com:5060 Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy ;tag=314159 Call-ID: [email protected] CSeq: 1 ACK Content-Length: 0. ². F18 BYE UserB -> Proxy2 通話連線是透過傳送 BYE 請求給接收端終止。 BYE sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP there.com:5060 Route: , From: LittleGuy ;tag=314159 To: BigGuy Call-ID: [email protected] CSeq: 1 BYE Content-Length: 0. 7. 逢甲大學 e-Paper (92學年度).

(9) 以SIP為基礎結合Web界面的分散式多功能服務系統. b. 回應訊息﹝Response﹞ Response = Status-Line *﹝ general-header | response-header | entity-header ﹞ CRLF [ message-body ] 其狀態碼依受話端的情況可分為： 1xx: Informational 表示伺服器或代理伺服器正在處理某些動作而且尚未有任何確切的回應。 n 2xx: Success 請求成功而且必須終止該搜尋。 n 3xx: Redirection 提供使用者的新位址或其他能滿足該請求的服務。 n 4xx: Client Error 該類型狀態是由特定伺服器傳回的確切失敗回應。 n 5xx: Server Error 該類型狀態是因為伺服器本身發生錯誤而傳回的失敗回應。 n 6xx: Global Failure 表示伺服器含有某些使用者確切資訊 n. 3.1.2 SIP 實作架構本專題架構底層即是以 SIP 通訊協定來完成訊息的溝通，為了能符合業界之規格標準，實作方面是採用 JAIN(Java Application Integrated Network)計劃中的 SIP 協定堆疊架構，其中 JAIN 這個組織主要的負責的工作在於制定各種通訊協定(特別是網路電話方面的協定)的呼叫介面，讓各廠商能依照其規定的呼叫流程實作其下的動作。本專題在這個部分則是依照該呼叫介面將實作的功能完成，以銜接上層的端點協定(Peer Protocol)。 JAIN APIs 是一系列以 Java 虛擬機器為平台的網路通訊技術，以該技術為基礎平台所發展的應用程式從網路連線或存取資料便能擁有足夠的可攜性、完整性以及安全性。 JAIN 提供了抽象與關聯性的介面，可在公眾交換電話網路﹝Public Switched Telephone Network – PSTN﹞、封包交換網路 ﹝例如 Internet Protocol﹝IP﹞或 Asynchronous Transfer Mode﹝ATM﹞﹞和無線網路之間建立服務元件，這便是所謂的整合式網路，除此之外，允許 Java 應用程式在安全的網路裡存取資源的優勢在於能夠同時提供各種功能不相同服務元件。因此，相較於其他以單一網路架構為基礎的封閉式系統，JAIN 技術改變了電話通信市場的思維，它使用服務元件的建立和配置更為簡便。 8. 逢甲大學 e-Paper (92學年度).

(10) 以SIP為基礎結合Web界面的分散式多功能服務系統. JAIN 技術是 Java 平台的一種延伸，它的發展是在昇陽公司的 Java Specification Participation Agreement﹝JSPA﹞、Java Community ProcessSM﹝JCP﹞和 Community Source Code Licensing﹝SCSL﹞規範下進行的，進一步的資訊可連接至 http://jcp.org 參考。. 1. 2.. JAIN 的發展提案包括兩種 API 規格類型：協定 API 規格定義了有線、無線與 IP 協定訊息。應用程式 API 規格訂定了以協定 API 規格為基礎架構的服務元件建立。. 該套件依照 Session Initiation Protocol(SIP) - RFC2543 的通訊協定規格制訂了一套完整的訊息呼叫流程。下圖為 SIP 的事件處理模型：. 9. 逢甲大學 e-Paper (92學年度).

(11) 以SIP為基礎結合Web界面的分散式多功能服務系統. JAIN SIP API Specification 的模組套件名稱可依功能分為： n. jain.protocol.ip.sip 定義該套件中的核心元件：SipStack、SipProvider、ListeningPoint。 SipStack 功能在於建立、摧毀和管理其下所屬的 SipProvider 物件， SipProvider 和 ListeningPoint 為一對一的關係，每個 SipProvider 僅擁有單一 ListeningPoint，該類別負責解析接收到的協定訊息並將事件(SipEvent)傳至上層聆聽者(SipListener)。. n. jain.protocol.ip.sip.address 負責 SIP 通訊協定的定址，包括三種定址格式：URI、SipURL、 NameAddress。. n. jain.protocol.ip.sip.header 定義 SIP 通訊協定訊息的各類型標頭資訊，依照其功能可分為： General、Request、Response 和 Entity Header，而其建立方式需透過 HeaderFactory 來執行。. n. jain.protocol.ip.sip.message 定義 SIP 通訊協定的請求(Request)和回應(Response)訊息，依照兩種協定訊息的特性可放入特定功能的標頭資訊，例如請求訊息可包括 General、Request 和 Entity Header；回應訊息可包括 General、 Response 和 Entity Header，其詳細規格可參考 RFC2543。. 在本專題實作 JAIN-SIP 規格介面期間，發現到以上幾種功能上的缺失，造成上層建立其物件時會造成不易於使用的問題，以下幾點為這個版本所無法支援的問題及本專題提供的解決方案： 1.. 協定規格僅支援 RFC2543，而未支援目前最新的 RFC3261 本專題實作規格之版本編號是 JAIN/SIP 1.0，儘管目前已公佈最新的規格 JAIN/SIP 1.1，但是當時專案正在實作期間，因此無法及時更新至這個版本。另外，因為本專題主要的功能在於端點間的訊息傳遞，並沒有建立通話連線的需求，所以使用的請求方法類型為其後提出的 MESSAGE，而舊有版本中並未定義此方法，因此本專題特定為此加入該訊息類型，並遵循 RFC3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging 的規範實作簡短訊息的傳遞。. 10. 逢甲大學 e-Paper (92學年度).

(12) 以SIP為基礎結合Web界面的分散式多功能服務系統. 2.. 不提供訊息交易層(Transaction)架構的功能本專題所實作的版本並未提供交易層的機制，即管理該請求訊息傳送或接收之後的狀態監控與訊息重傳，此版本對交易機制僅僅利用一個長整數值做為鍵值的方式管理，因此使用者在呼叫或管理上會帶來不便，為此，本專題又另外參考新版本的做法將交易機制納入原舊有版本之中，以下為交易層之 UML 架構圖：. TransactionManager getId() : long getInstance() : TransactionManager getProvider() : SipProvider getTransaction() : Transaction removeTransaction() : Transaction getClientTransaction() : ClientTransaction getServerTransaction() : ServerTransaction createClientTransaction() : ClientTransaction createServerTransaction() : ServerTransaction. Transaction isServer() : boolean getId() : long getManager() : TransactionManager getRequest() : Request getResponse() : Response getConnection() : Connection setConnection() : void sendBye() : void doBYE() : void. ClientTransaction. ServerTransaction. sendAck() : void sendAck) : void sendAck() : void sendCancel() : void sendRequest() : void receiveResponse() : void. 3.. sendResponse() : void sendResponse() : void sendResponse() : void sendResponse() : void doAck() : void doCancel() : void receiveRequest() : void. 對於 SipStack、SipProvider 的建立無法依所需設定其運作方式因為這個版本的標準規格在建立以上兩種物件時並無法設定其屬性和運作方式，例如底層傳輸的類型或是否將該端點向鄰近的註冊管理者(Registrar)進行註冊。面對這個問題，舊有版本的介面中並未包含任何選項設定的方法，也因此必須對原規格做稍微的修改，即加上建立 SipStack 時的選項設定，此法不但能讓使用者能依照自己所需設定物件的運作方式，實作廠商也能將本身擁有的額外服務功能加至其中供使用者叫用。. 11. 逢甲大學 e-Paper (92學年度).

(13) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.2 SOCKS 協定及實作 3.2.1 SOCKS 協定緣由由於現今網路組態常使用防火牆使內部網路隔離於外部網路或使用網路位址轉譯器(NAT)建立虛擬私有網路(VPN)，這些防火牆系統可提供傳統的協定如 HTTP、TELNET、FTP 隧穿無虞，但對於其它提供特定應用的協定則會出現功能障礙，為了提升網路的透通性，SOCKS 提供了標準化、安全化的機制。. 3.2.2 SOCKS 協定簡介 SOCKS 定義三種指令，connect、bind、udp associate，分別介紹如下： a. Connect – connect 指令封包指示 client 欲連往的目標主機位置及埠號，SOCKS Server 負責連往目標主機並為雙方建立連線。 b. Bind – bind 命令 SOCKS Server 開啟指定的埠號，並等候指定的目標主機連入，一旦目標機連入 SOCKS Server 開啟之埠號，即為雙方建立連線。 c. UDP Associate – 類似 bind 指令運作方式，不過此時負責轉傳的是 UDP Datagram。 SOCKS 又分兩種版本，version 4 及 5，在 version 5 中，SOCKS Server 執行命令前，必須通過認証機制，而主機位置也可以是 IPv4、IPv6、Domain name。. 12. 逢甲大學 e-Paper (92學年度).

(14) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.2.3 SOCKS 實作 ProxyServer UDPRelayServer SocksSocket. Authentication. ProxyMessage. Socks5DatagramSocket. SocksServerSocke. 圖 3.2.3.1 SOCKS Server系統堆疊圖. START. ACCETP. PIPE. ABORT. 圖 3.2.3.2 ProxyServer狀態流程圖. 運作流程 ProxyServer 開啟 SOCKS 公認埠，一般為 1080，當收到連線後，首先判別該請求為 SOCKSv4 或 SOCKSv5，若為 version 5 則進行 SOCKS Server 有實作之認証程序，認証通過後將依指令進行對應動作。 a. Connect) ProxyServer 連線至 ProxyMessage 指示之目標位置及埠號，再產生一 ProxyServer 物件，該物件進入 Pipe Mode，負責兩端點雙向資料傳輸。. ProxyServer(START) 產生 ProxyServer(PIPE). 圖 3.2.3.3. 13. 逢甲大學 e-Paper (92學年度).

(15) 以SIP為基礎結合Web界面的分散式多功能服務系統. b.. Bind) ProxyServer 於本地開啟一聆聽埠，並將埠號包成 Response 告知 Client，產生一執行緒負責等候遠端的連線，當正確的遠端連線後，該執行緒再次回傳 Response 告知，並再產生一執行緒，共兩執行緒負責雙向資料傳輸。. ProxyServer(START) 轉換 ProxyServer(ACCEPT) 產生 ProxyServer(PIPE). 圖 3.2.3.4. c.. UDP Associate) ProxyServer 產生 UDPRelayServer，其於本地開啟 Socks5DatagramSocket 聆聽埠，回傳該 Response 告知其聆聽埠，當收到雙方的 KEEP Datagram 後，即產生兩執行緒負責雙向資料傳輸，KEEP Datagram 用來保留雙方真實網路繞路資訊，以便傳輸 UDP Datagram。. ProxyServer(START) 轉換 ProxyServer(ACCEPT) 產生 UDPRelayServer. 圖 3.2.3.5. 14. 逢甲大學 e-Paper (92學年度).

(16) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3 JMF 架構及研究 JMF 是一種應用程式介面，整合了 time-based media 到 Java applications 和 Applet。如果程式設計者，對 JMF 的格式興趣也可以自行延伸 JMF，以 plug-in 的方式加入新的 media-supported type，並可自行實作設計 transport-layer 層的傳輸方式。以下是 JMF 的設計目標 • • • • • •. 3.3.1. 容易去設計。對於 Capture device media 的存取。使 Java 能傳輸多媒體串流和網路電話的程式提供進階程式師和技術去實作和延伸。提供對 raw media data 存取能力。提供發展 downloadable demultiplexers, codecs, effects processors, multiplexers, and renderers 的能力。. High-Level Architecture. 像 tape decks 和 VCRs 這此裝置，提供了常見的 recording model， processing、和呈現 time-based media。當我們用 VCR 播放 movie，我們藉由放入 video tape 來提供 media stream，而 VCR 讀取和解釋在 tape 中會資料，然後傳送適合的訊號到 TV 和 Speaker.. JMF 使用和這一種相同的 basic model，Data source 結合入 media stream 如同 tape，Player 就如同 VCR 控制和處理的機器，而 Playing 和 Capturing audio 和 video 的輸入裝置和輸出裝置就是如同 microphones, cameras, speakers, and monitors。. 15. 逢甲大學 e-Paper (92學年度).

(17) 以SIP為基礎結合Web界面的分散式多功能服務系統. Data sources 和 players 是 JMF's high-level API 中不可或缺的部份，來處理 Caputre Device,及呈現和運作以時間為基礎的多媒豐。JMF 也提供了低階的 API，使設計者可以進而延伸和作細部的設計。. High-level JMF achitecture.. 3.3.2 Players Player 處理 media data 的 input stream 和以精確的時間呈現它。 DataSource 被用來來傳送 input media-stream 到 Player，而 render 則依靠多媒體的形態來呈現。. JMF player model. Player 沒有提供任何在控制和如何處理呈現 media data。而 Player 提供了一個標準化的 User Control 和藉由 Clock 和 Controller 來簡作上層的控制。. JMF players. 16. 逢甲大學 e-Paper (92學年度).

(18) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3.2.1. Player States. 一個 Player 可以有 6 個 state. Clock介面定義了 2 個主要 state: Stopped and Started.為了要使資源的管理容易，所以 Controller 分開了 Stopped state 到 5 個 tates: Unrealized, Realizing, Realized, Prefetching, and Prefetched.. Unrealized. Realizing. Realized. Prefectching. prefetched. Started. Player states.. 在正常的運作過程，一個 Player 可以到達每一個 state 直到 Started State: l. l. l. l. Player 在 Unrealized state 被起始化，但對 media 的資訊還不了解，當 Player 被建立後，它就在 Unrealized State. 常 realize 被呼叫，Player 開始由 Unrealized state 移到 Realizing state，Realizing Player 是處理決定資源的需求，在 realization 階段，Player 得到它只需得到一次的資源，可能包含呈現資源，一個 Realizing Player 常由網路得到這些資訊。當 Player 完成 Realizing，它移動到 Realized state， Realized Player 了解那些資源需要和資訊，由於 Realized Player 了解如何去呈現，所以可以得到 visual components and controls 的資訊。當 prefetch 被呼叫，Player 由 Realized state 到 Prefetching state，Player 正準備去呈現 media ，在這一階段，Player 會先 load 它的 media 資料，和惟一使用的資料，Prefetching 如果 Player 回到先前的狀態，會再發生，因此 Player 需要額外的 buffer，來交換狀態。. 17. 逢甲大學 e-Paper (92學年度).

(19) 以SIP為基礎結合Web界面的分散式多功能服務系統. l l. 當 Player 完成 Prefetching，它移到 Prefetched state， Prefetched Player 就進去等待開始的狀態。呼叫 start 使 Player 進入 Started state.，Started Player 的 time-base time 和 media time 作 mapping 的動作，且 clock 也開始 running，即使 Player 可能還在等待一個特定的時間去呈現。. 3.3.3 Processors Processors 也可以用來呈現 media data.Processor 只是一種 Player 的特別形態，提供了處理 input media stream。Processor 提供了所有和 Player 一樣的 controls。. JMF processor model. 除了呈現 media data 到輸出裝置，Processor 可以輸出 media data 以 DataSource 的方式，將 DataSource 指定到下一個 Player or Processor，更進一步 Processor 可以傳送另一目的地，如傳送到 File 中。. 3.3.3.1 Processing Processor 是一種 Player 以 DatatSource 為輸入，執行一些使用者定的程序在 media data，然後輸出和處理 media data. JMF processors. Processor 可以送輸出資料到資料呈現的裝置或輸出到 DataSource，如果資料是輸出到 DataSource，DataSource 可以被使用如同另一個 Player 或 Processor 的輸入，也可以輸出到 DataSink。. 18. 逢甲大學 e-Paper (92學年度).

(20) 以SIP為基礎結合Web界面的分散式多功能服務系統. 當由 Player 處理執行之前所定義的工作，Processor 允許應用程式發展者去定義處理的形態，對應到相對的 media data，它使得應用程式的 effects、mixing、compositing 以即時的方式來處理。. 處理 media data 分為下列幾個 stages. Processor stages. ² ² ² ² ² ². Demultiplexing 是 parsing input stream 的過程，如果 stream 包含了多個 tracks，它們分出和輸出個別地。 Pre-Processing 是處理 effect algorithms 到 tracks 抽出到 input stream. Transcoding 是處理轉換每一 media data 的 track 的過程，當 data stream 從 compressed type 到 uncompressed type。 Post-Processing 處理加入有效率的演算以去 decoded tracks. Multiplexing 是處理內部轉碼 media tracks 到單獨的 output stream Rendering 處理資料給 the user.. 19. 逢甲大學 e-Paper (92學年度).

(21) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3.3.2. Processor States. Processor 有二個額外的等待 state, Configuring and Configured，它們發生在 Procssor 進入 Realizing state 之前。. Unrealized. Configing. Configed. Realizing. Realized. Prefecth. Prefetch. Started. Processor states. Ø. Ø. Ø. 當 configure 被叫 Processor 進入 Configuring state，. 它連接到 DataSource, demultiplexes 的 input Stream，且存取關於輸入資料的格式資料。當已連接到 DataSource，Processor 移到 Configured state，且資料的格式已經決定，當 Pocessor 到達 Configured state，會發生 ConfigureCompleteEvent。當 Realize 被呼叫，Processor 轉到 Realized state， Processor 只會有一次建構完整的 Realized State.. 20. 逢甲大學 e-Paper (92學年度).

(22) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3.4 Real-Time Transport Protocol 在 JMF 中也提供了 RTP(Realtime Transport Protocol)的運作控制，RTP 提供了點對點的及時性資料傳輸 Service。RTP 是和網路和 transport-protocol 獨立的協定，即使它一般是以 UDP 來傳輸。. :RTP architecture. RTP 可以被使用在 unicast and multicast 的網路 Service.藉由 unicast network 的 Service 環境，可以分別資料複製由來源到每一個目的端。藉由 unicast network 的 Service 環境，可以傳送 Stable 的多個目的地。Multicasting 對於許多多媒體應用程式是相當有效率的，如在多人的視訊會議。在標準的 Internet Protocol (IP)對於 multicasting 的提供。. 3.3.4.1. RTP Services. RTP 可以給使用者定義要被傳送的資料型態，決定每一資料封包要以何種順序來傳送，和如何同步來自於不同的多媒體來源。 RTP 資料封包並不保證到達的順序和它們的送出的順序相同，事實上，它們一點也不保證是否到達目的地。再來就是在接收端必需藉由加在封包 header 的資訊去重新建構傳送端的封包順序，並偵測遺失的封包由於 RTP 沒有提供任何機智去保證即時性的傳輸或提供其它 Service 的品質，因此它加入了 control protocol (RTCP)，使用者可以 monitor 資料傳輸的品質，RTCP 也提供了對於 RTP 傳輸的控制和定義機智。如果 Service 的品質對於特別的應用程式是必需的，RTP 可以使用 resource reservation protocol 來提供 connection-oriented 的 Service。. 21. 逢甲大學 e-Paper (92學年度).

(23) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3.4.2 RTP Architecture 一個 RTP session 是以 RTP 應用程式的傳輸關聯性集合， session 是以網路位置和一組 ports 組成。一個 port 是使用在多媒體資料，另一個是用來傳輸 control (RTCP)資料。 Participant 是一個單獨的運作個體，或是使用者 participating 在這一個 session 中，Participant 在 session 中可以由被動的接受資料，主動的傳送資料組成。每一種多媒體形態以不定的 session 來傳輸。所以如果在網路電話會議中如果包含了 audio 和 video ，一個 session 用來傳輸 audio 資料，另外一個 session 用來傳輸 video 資料。因此它使得 participants 可以去選擇他們想接收那一種多媒體形態，如果某人只有一個 low-bandwidth 的網路連線環境，他可能只要接收網路電話會議得 audio 部份。. 3.3.5 Data Packets 一個 session 的多媒體資料傳輸如同一連串的封包。一連串的封包資料是以 RTP stream 來自某一特定的來源。每一個 RTP 在 Stream 中資料封包含二個部份，一個是結構化的 header，和另一個真正的資料 (packet's payload)。. RTP data-packet header format.. 22. 逢甲大學 e-Paper (92學年度).

(24) 以SIP為基礎結合Web界面的分散式多功能服務系統. RTP 資料的 header 包含了以下容: • •. •. • • •. • • • •. •. The RTP version number (V): 2 bits. 目前的 Version 是 2.0 Padding (P): 1 bit 如果 padding bit 是一個集合，有一個 or 多個 bytes 在封包的後面，它不是 payload 的一部份，在封包中的最後一個 byte 指出了 padding 的 byte 數目。在 padding 的部份是以一些加密的演算法來使用。 Extension (X): 1 bit. 如果 extension 的 bit 被設定，固定的 header 會隨著另一 header extension。Extension 的機智使得加入資訊在 header 得以完成 CSRC Count (CC): 4 bits. CSRC 的數字定義了接下來固定的 header，如果 CSRC Count 是 0，同時性的來源是來源的 payload Marker (M): 1 bit. Marker bit 以特別的多媒體資料定義 Payload Type (PT): 7 bits. 在 media profile table 的 index ，描述 payload 的格式，Payload 對應於 audio 和 video 在 RFC 1890。 Sequence Number: 16 bits. 一個惟一的 packet number 用來定義在封包中的位置須序。Packet number 的每送一次增加一次。 Timestamp: 32 bits. 表達在 payload 中的第一個取樣的 byte 。如果它們在 logic 上是相同時間的，一些連續的封包可以有相同的 timestamp，像是全部相同部的 video frame。 SSRC: 32 bits. 同義了同時性的來源，如果 CSRC count 是 0， payload source 就是同時性的 source，如果 CSRC count 是非 0，SSRC 則定義為 mixer。 CSRC: 32 bits each. 定義了貢獻給 payload 的來源， contributing sources 的數目在 CSRC count 欄位中指出，可以達到 26 個 contributing sources，如果有許多部份所組成的 contributing sources，則 payload 就是那些 sources 的 mixed 資料。. 23. 逢甲大學 e-Paper (92學年度).

(25) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3.6 Control Packets 除了在 session 多媒體資料之外，control data (RTCP)也是週期性傳給所有在 session 的 participants，RTCP packets 可以包含給 session participants 的 Service 品質資訊，來源資訊在 data port 傳輸，統計目前已傳的的資料。 RTCP packets 有下列的形態 • • • • •. Sender Report Receiver Report Source Description Bye Application-specific. RTCP packets 是可以堆疊的，它傳送了混合的封包，包含了至少二個封包，一個是 report packet，另一個是 source description packet。所有在 session 的 participants 傳送 RTCP packets，一個最近有傳送的資料封包的的 participant，會產生 sender report。Sender report (SR) 的內容包括了全部數的封包和 byte 數目，如同資訊會被使用來自不同 session 的同步多媒體串流 Session participants 會週期性地產生 receiver reports 給所有接收資料封包的來源，Receiver report (RR)的內容包括了關於封包遺失的數目，最大已接收的 sequence number，和一個 timestamp，可以用來減少在 Sender 和 Receiver 之間來回的 delay。在混點的第一個 RTCP packet 必需是 report packet，即使沒有資料被傳送 or 接收，在這一種情況，一個空的 receiver report 被傳送了。所有混合的 RTCP packets 必需包含了有定義來源的 canonical name (CNAME) 的 source description (SDES) 元素。除此之外，資訊可能包含在 source description，像是 source 的名稱,電子郵件的位址，電話號碼，來源的位址,應用程式名稱, or 訊息內容，來描述目前的來源狀態。當來源不再運作時，它傳送一個 RTCP BYE packet。在 BYE 說明它離開 session 的原因。 RTCP APP packets 提供了給應用程式定義了資訊經由 RTP control port 傳送的機智。. 24. 逢甲大學 e-Paper (92學年度).

(26) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3.6.1 Receiving Media Streams From the Network 一些形態的應用程式必需能夠接收 RTP streams，如: l l l. 網路電話會議必需能夠接收來自 RTP session 的 media stream，並且在使用者的控制環境下呈現。電話答錄機應用程必需能多接收來自 RTP session 的 media stream，並儲存成檔案。一個紀錄交談內容或網路電話會議必需能夠接收來自 RTP session 的 media stream，可以在使用者的控制環境下呈現，且能儲存到檔案。. 3.3.6.2 Transmitting Media Streams Across the Network RTP Server 應用程式傳送由 capture device 所得到的資料或由已儲存的 media streams 到網路。例如: 在網路電話會議應用程式中，其中一個 media stream 可能擷取來自 video camera，然後傳送出一個或多個 RTP session。且 media streams 可能被碥碼成複合的多媒體格式，然再以送出幾個 RTP session 到網路電話會議不同形式的接收者，多人網路電話會議以許多的 unicast RTP session 來實作 multicat。. 25. 逢甲大學 e-Paper (92學年度).

(27) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3.8 H.263 與 H.261 的差異事實上，H.263 只是 H.261 的進一步延伸，而延伸方式則採用了類似 MPEG 的方法，其間差異主要在於兩者目標的不同： l. l. 兩者鎖定的目標位元率(Target Bit-rate)不同，H.261 是 px64Kbps，H.263 則希望在 64Kbps 以下，這是因為前者係利用 ISDN，而後者則希望透過現有的電話線網路來做傳輸。 H.263 與 H.261 影像的格式不同，H.261 只提供 CIF 或 QCIF 的影像格式，而 H.263 則提供更多選擇，希望將來在不同傳輸媒介上的影像資訊都能夠互通。. 除了上述這兩個明顯的差別外，在系統上，H.263 也做了很多的改變以增進編碼效率，在這裡我們把幾個比較重要的特色說明一下： ². 位移估計(Motion Estimation)的精確度可以到達半個像點(Half-pixelaccuracy)；這種方式和 MPEG 所使用的方式類似，主要是因為人眼視覺的特性，使得我們可以利用這種方法將位移估計的準確度提高。也就是說，利用影像在時間上的相關性將影像作更多壓縮。. ². 可重疊式的區塊位移補償(Overlapped Block Motion Compensation;OBMC)；當我們利用位移估計找出最相似的區塊後，在傳統的方法中就直接把這個區塊貼回，再加上估計的誤差就成為目前之影像。然而在 H.263 中，所有目前的區塊都會是三個區塊之加權平均值再加上誤差，而這三個區塊具有相鄰的關係。在利用了這種方式之後，區塊的大小就不再是傳統 16×16 的大小而成為 8×8 了。也就是說，這會使得壓縮後的影像品質更佳清晰，但是卻還能夠保持極佳的壓縮比。這些動作規定於 H.263 中一個新的增強模式中(AdvancedPrediction Mode;AP)。. 26. 逢甲大學 e-Paper (92學年度).

(28) 以SIP為基礎結合Web界面的分散式多功能服務系統. ². 算術編碼方式；以往的壓縮方式在對付統計上的多餘性，通常是利用霍夫曼編碼(Huffman Coding)來達成可變長度編碼(Variable Length Coding)，但是使用了新的算術式編碼可以更有效地把資料壓縮到接近其亂度 (Entropy)，因此在 H.263 中有一個增強模式 (Syntax-based Arithmetic Coding Mode;SAC)是可以使用此種新的編碼方式。. ². 無限制的位移向量模式(Unrestricted Motion Vector Mode ; UMV)；使用這個模式的話，位移向量將可以指到超過螢幕範圍的位置，當然，有些像點的值是用類似內插之方法得到。這個增強模式在螢幕畫面不大時相當有用，例如 sub-QCIF 或 QCIF 等可能用在液晶顯示的影像格式，因為當影像不大時，我們會發現影像中大部份的區塊都是位於邊緣位置。也就是說，當我們在做位移估計時，若使用傳統方式，有許多區塊的搜尋範圍會變少，所以這種增強模式將能夠彌補這方面的問題，如果影像中的東西正好是在螢幕邊緣位置移動時，影像品質的改善會更加明顯。. PB-frame 模式是類似 MPEG 中 B-frame 的一種方法。在 MPEG 中，P-frame 就是利用以前的影像來預測目前影像之方法，但是除了這種方式之外，還有一種 B-frame 會利用以往或其後的影像來做預測，這樣雖然付出了硬體或是複雜度的代價，卻換來高壓縮比以及更好的影像品質。在 H.263 中，也有一種類似的增強模式－PB-frame。顧名思義，一個 PB-frame 包含了一個 P-frame 和一個 B-frame，不過不像傳統的 B-frame 會利用之前或之後的影像計算位移向量，H.263 中 B-frame 的兩個向量都是利用 P-frame 的位移向量內插來得到，雖然這樣做會損失一些影像的品質，但是卻可以提高影像壓縮比大約一倍左右。. 27. 逢甲大學 e-Paper (92學年度).

(29) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3.9 其他編碼方法 3.3.9.1. G.723.1[10]及G.729[11]. 這兩種編碼方式，與G.711 的編碼方法有很大差異。G.711 的編碼方法，基本上是根據時間軸上的聲音波形來編碼，像這種編碼方式一般可稱之為聲源編碼器(Waveform Coders)，其特性是壓縮率不大，但運算也不致太複雜。此外，我們也可以根據聲音的特性來編碼。研究人員根據人類發聲的原理，建立適當的模型和參數，在收到聲音訊號時，試著分析其中的模型參數之值，利用這些參數值和模型，可以將聲音做近似的還原。取出這些參數值的過程稱為分析 (Analyze)，可視之為編碼的過程，接收端接到這些參數後，利用模型將這些參數值還原為聲音，此過程稱之為合成 (Synthesis)，為解碼的過程。像這種編碼器一般亦稱之為語音編碼器(Vocoders) ，典型的代表為線偵測編碼演算法 (LinearPredictive Coding Algorithm) 。除此之外，還可以混合以上兩種編碼方式的特長來編碼，稱之為混合編碼器(Hybrid Coders) 。其基本原理是利用分析方法先找出一部份聲音特徵，再利用合成的方式，從各種可能的參數之合成結果，中，尋找最接近原來聲音波形的參數組合，這種過程稱為以合成方式所作分析 (Analysis-by-Synthesis) 。由於在尋找參數的過程，中必須做聲音的合成，而此部份正是解碼所做的動作，因此在編碼器即含有解碼器的單元。典型的代表是編碼激發線偵測(Code-Excited LinearPredictive；CELP)編碼，像G.723.1、G.728 和G.729 均屬於此類。關於CELP 的編碼方式，其原理簡述如下。在語音合成的部分(即解碼器)，解碼器根據聲音的參數選擇適當的字碼 (Codeword)，而後取其總和，以形成適當的激發源（這部份可視為模擬人體發體的氣息來源，以及聲帶週期性的振動），而後將此激發源經過一個適當的濾波器(可視為經過聲道、嘴唇、鼻腔等發聲器官產生的效果)，並給多適當的能量大小，即產生合成的輸出聲波。關於語音分析的部分（即編碼器），因為解碼器會根據聲波的一個框架，利用線性偵測演算法，找出適當的濾波器參數，來模擬此段聲波的波包部分（去掉週期性的振動部分所餘之波包，可視為發聲器官產生的效果），得到這些參數之後，再逐一選擇字碼組合為激發源，將其合成輸出聲波，再將此合成之聲波與原來之聲波比對，並根據人耳對音感之認知調整加權，以計算其差異。如此對所有可能的字碼組合一一試過，最後找出最合適之編碼參數，即完成編碼動作。. 28. 逢甲大學 e-Paper (92學年度).

(30) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.3.9.2. G.711. G.711[9]之編碼即脈衝編碼調變，其編碼率為64 Kpbs，這是最基本的語音編碼，廣泛用在世界各地。PCM 係將輸入之聲波，以每秒8K 的取樣速度，對每一取樣值使用8 bits 做不等量之量化來編碼。根據研究指出，人耳對於同樣的聲音變化，在不同的環境下，會有不同的感受。在安靜的環境下，人耳能感受到細微的變化；而在吵雜的環境下，只能感受到較大的變化。因此在對聲波取樣時，在振幅小的地方應該使用較小的量化值(Quantization Size)，而在振幅大的地方，則使用較大的量化值。若以橫軸為聲波之值，縱軸為取樣之值，則兩者的關係類似一對數曲線，故有時亦稱 log-PCM 編碼。一般又將其細分成兩種，稱為A-law 和μ-law，目前在美國和日本、台灣使用的都是μ-law。. 29. 逢甲大學 e-Paper (92學年度).

(31) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.4 NAT 與區域網路的限制與解決方式區域網路架構遭遇之限制與困難處本專題架構底層所實作的 SIP 通訊協定並沒有明確定義區域網路內與其他端點進行協定訊息上傳遞的標準流程，也因此 SIP 通訊協定在這個環境之下也遇到了許多問題，加上區域網路內的使用者無法對防火牆或 NAT 進行操控，在這個環境裡解決使用者對外溝通的情況也變得相當具有挑戰性。現今已經有 IPv6 協定標準的制定，因此解決這個問題的時候，會希望 NAT 會因整個網路架構皆支援此標準而無用武之地，但是這種情況並不可能，因為許多企業或組織會利用此架構來達到安全的機制。若本身 NAT 架構無法改變的話，解決此問題的另外一個方法是讓 NAT 或防火牆能支援 SIP 協定的 ALG(Application Level Gateway)，但是目前就算是支援最完整的網路裝置仍未必支援其協定封包的處理，因此絕大部分網路裝置皆無法判斷這類型封包的標頭資訊，若要完成大部分網路裝置對此封包的支援，或許還須等待幾年的時間，這種解決方式絕非明智之舉，也因此我們必須另外尋求其他解決方案。. 解決方式我們對此問題的解決方案是以不改變目前網路架構的考量之下進行，因此在實作上必須尋找其他針對該協定擴充的方法，而本專題針對此問題做出的解決方式則是採用 Internet Engineering Task Force SIP Work Group 由 J.Rosenberg,H.Schulzrinne 所提出的 SIP Traversal through Residential and Enterprise NATs and Firewalls，其所處的網路架構如下圖所示：. SIP Proxy X. SIP Proxy Y. FW/NAT. FW/NAT. SIP UA Joe. SIP UA Bob. 30. 逢甲大學 e-Paper (92學年度).

(32) 以SIP為基礎結合Web界面的分散式多功能服務系統. 其解決方案的說明分為「訊息傳送方面」、「訊息接收方面」與「串流傳輸方面」，因此本章節也將分為這三個部分做說明。 n. 訊息傳送方面傳送端將協定訊息透過 NAT/Firewall 傳送至代理伺服器令其轉送並接收代理伺服器傳回的回應訊息。區域網路內部的 NAT 允許 TCP 和 UDP 封包傳送至外部網路的通訊埠 5060，因此傳送請求訊息並不會遇到任何問題；然而，接收回應訊息方面卻會有下面的問題：根據協定規格對 UDP 傳輸情況所述，回應訊息回傳送至封包中 Via Header 的位址與通訊訊埠，但是封包的標頭已經被 NAT 修改，所以此標頭的位址資訊是錯誤的，也就是回應訊息無法正常傳回至傳送端；對於 TCP 傳輸情況，回應訊息是傳送至接收到請求訊息時所使用的原來連線，因此在這個情況之下可以成功將回應訊息傳回。根據上面的結論，傳送端以 TCP 傳輸方式進行，傳送與接收並無問題；若以 UDP 傳輸方式進行，接收請求訊息者(User Agent Server)可將動作改成將回應訊息傳送至原接收請求訊息的來源位址和通訊埠，儘管這改變會使流程不符合協定規格，但是卻可以解決這種情況所遇到的問題。. n. 訊息接收方面接收訊息的情況並不如同前者狀況這樣簡單，因此需要更多處理該問題的步驟。為了解決這個情況的問題，使用者需要先對註冊管理者進行註冊 (Register)訊息的傳送進行註冊手續，如上圖之網路架構所示，傳送端 Bob 會先對註冊管理者(這個裝置與代理伺服 X 部署在同一網域內) 傳送註冊訊息，下以即為註冊訊息的內容： REGISTER sip:Y.com SIP/2.0 From: sip:[email protected] To: sip:[email protected] Contact: sip:[email protected] 很明顯地協定訊息中之 Contact 標頭所記錄的並非廣域的位址，因此其他使用者無法將請求訊息傳送給該使用者，為了解決這個問題，使用者必須以 TCP 傳輸方式傳送註冊訊息並將這個連線保持開啟，以接收代理伺服器轉送過來的請求訊息，而註冊管理者與代理伺服器共存的裝置則在接收到註冊訊息之後，將其連線記錄在連線記錄表之中，其連線記錄包含三個欄位(M, N, O)，其中 M 為網路位址； N 為通訊埠；O 為傳輸方式，這個表格是用來往後查詢特定連線所須。. 31. 逢甲大學 e-Paper (92學年度).

(33) 以SIP為基礎結合Web界面的分散式多功能服務系統. 此時，與使用者 Bob 進行訊息上之連線已經建立完成，而這個連線的鍵值為 sip:[email protected]，然而這個位址在往後查詢時會轉換為 sip:[email protected]，這並非正確的網路位址，因此註冊管理者在接收註冊訊息時須另外判斷使用者正確的來源位址並建立更正後的 Contact 標頭，由於大部分使用者皆無法確切了解其正確的網路位址，因此在傳送註冊訊息時需告知註冊管理者本身無法知道自己的網路位址，為了解決這個方面的問題，本方案是要求使用者在註冊時在 Contact 標頭的設定為 jibufobutbmpu 以告知註冊管理者，有趣的是這個字串所意思是「I hate NATs a lot」，即每個字元往後位移，以這個方式傳送的註冊訊息便是如下所示： REGISTER sip:Y.com SIP/2.0 From: sip:[email protected] To: sip:[email protected] Contact: sip:bob@jibufobutbmpu 註冊管理者接收到這個註冊訊息之後便會將 Contact 標頭資訊更改為連線的來源位址與通訊息埠，並將此資訊存入連線記錄表，往後如果有其他使用者把請求訊息傳送至 sip:[email protected] 時，代理伺服器會轉換為 sip:[email protected]:2397 並對應至正確的連線以進行傳送。. n. 串流傳輸方面前面兩個主題說明的 SIP 訊息傳遞是屬於較單純的情況，但是對於串流傳輸方面卻顯得複雜許多，本章節之參考文章所討論的利用 SDP 描述建立 RTP 串流之方式亦可應用在一般資料串流的建立上，因此本專題所實作的方式還是使用原文所討論的解決方案，以下將針對兩種種情況分別做介紹與解決方式之說明。在對這兩種情況做說明之前，有兩個前提必須遵循方能達成此問題之解決方案：1. 位於區域網路內部的使用者必須主動傳送第一個封包以告知 NAT 建立內外網域的繫結；2. 串流的傳送與接收都使用相同的一條通道或管線。. 32. 逢甲大學 e-Paper (92學年度).

(34) 以SIP為基礎結合Web界面的分散式多功能服務系統. ². 其中一個使用者位於區域網路內部若傳送者位於區域網路內部，其請求訊息中包括 active 標記說明傳送端欲主動(Active)對接收端建立連線可告知接收者建立被動(Passive)的連線，而接收者在完成建立被動連線之後，可在回應訊息中加入此被動連線的網路位址與通訊埠，下圖為表示兩個使用者間進行串流建立的流程。. Request : active. 傳送端. Response : passive + host/port. 接收端. 此情況必須確定傳送端是位於區域網路內部，若無法確定其真的網路架構，則須將此視為第二種情況。. 33. 逢甲大學 e-Paper (92學年度).

(35) 以SIP為基礎結合Web界面的分散式多功能服務系統. ². 兩個使用者皆位於區域網路內部在這種更為複雜的情況之下，整個網路協定架構必須稍做功能上的加強，即代理伺服器必須支援協定訊息內容的解析，並判斷傳送端的網路狀況決定其運作的流程，我們將處理這個運作流程的元件稱為 Stream Translator(原文所稱為 RTP Translator，但本專題所討論的是一般資料串流的建立，因而如此稱之)。當傳送端欲與接收端進行串流的建立，可在請求訊息中加上 both 標記告知傳送端之 Stream Translator 判斷傳送端之網路特性將此標記做適當的修改(active/passive)再轉送至接收端之 Stream Translator 進行下一步的判斷及標記的修正，最後再將該請求訊息傳送給接收端並建立資料串流。下圖的網路架構與前面所提及的相近，主要差別僅在於傳送端與接收端的帶理伺服皆支援 Stream Translator 的功能，如下所示：. SIP Proxy X With Stream Translator. SIP Proxy Y With Stream Translator. FW/NAT. FW/NAT. SIP UA Joe. SIP UA Bob. Stream Translator 會根據四種狀況來進行訊息的處理，其處理流程將以順序圖來表示：. 34. 逢甲大學 e-Paper (92學年度).

(36) 以SIP為基礎結合Web界面的分散式多功能服務系統. 1.. 兩者皆位於廣域網路 Joe. Proxy X. Proxy Y. Bob. both both both both both both. 請求訊息回應訊息. 2.. 傳送端位於區域網路，而接收端位於廣域網路 Joe. Proxy X. Proxy Y. Bob. both active active passive passive passive. 請求訊息回應訊息. 35. 逢甲大學 e-Paper (92學年度).

(37) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.. 傳送端位於廣域網路，而接收端位於區域網路 Joe. Proxy X. Proxy Y. Bob. both active passive active passive passive. 請求訊息回應訊息. 4.. 兩者皆位於區域網路 Joe. Proxy X. Proxy Y. Bob. both passive passive active active active. 請求訊息回應訊息. 36. 逢甲大學 e-Paper (92學年度).

(38) 以SIP為基礎結合Web界面的分散式多功能服務系統. 本專題所使用的 SIP 協定架構中，其訊息內容並非使用原文討論的 SDP(Session Description Protocol)，而是另外定義之端點協定，其中，處理本部分串流傳輸的服務元件即為管線服務元件(Pipe Service)，因為對上層來說，用來傳送串流資料的媒介皆為本服務元件所封裝的管線物件(Pipe)，因此並無這方面的問題，而處理端點間的管線建立之流程即是參考本節之解決方案，其說明會在端點協定一章提出並介紹其使用方式與運作流程。. 37. 逢甲大學 e-Paper (92學年度).

(39) 以SIP為基礎結合Web界面的分散式多功能服務系統. 3.5 Java Web Start 架構說明 Java Web Start 是一種能和瀏覽器產生相關聯的輔助性應用程式，當使用者在網頁中點選一個指向某個特殊啟動檔案(JNLP 檔案)的連結時，瀏覽器就會執行 Java Web Start 並從啟動檔案所描述的路徑下載或是從快取目錄中執行以這種技術為基礎的應用程式。當然，前面提到的 JNLP URLs 可以從 JAWS 應用程式管理員(JAWS Application Manager)直接開啟並儲存到書籤，此種檔案的副檔名甚至也可以是.html 或.jnlp。從一個技術的立場來說，Java Web Start 在佈署應用程式方面之所成為一個吸引人的平台在於以下幾種關鍵優勢： l. Java Web Start 的功能在於啟動由 Java 2 SE 平台發展而成的應用程式，因此，每個應用程式可存放在網頁伺服器以供使用者存取，這種方法的好處在於程式發展者可以將應用程式佈署在各種作業平台中，包括 Windows98/NT/2000/ME/XP、Linux 和 SalarisTM 。由於這樣的跨平台特性，以此為開發平台的應用程式便相當地強軔且具生產力，加上發展與測試的花費減低，便節省了許多發展經費。. l. Java Web Start 支援多種版本的 Java 2 SE 平台，因此應用程式可以要求它所需要的特定平台版本，例如 J2SETM 1.4.0。在 Java Web Start 之上的各種應用程式可各自以不同版本的平台同時執行而且不會導致之間的衝突，如果應用程式發現用戶端並沒有安裝所需要的平台版本時，Java Web Start 也可以自動下載並重新安裝平台的更新版。. l. Java Web Start 允許應用程式由瀏覽器各自獨立執行，當瀏覽器關閉或是之後再次啟動特定應用程式時，它也可以用來處理這些功能，因為從瀏覽器呼叫 Java Web Start 並間接啟動特定應用程式對使用者來說是相當不方便且不可行的。. l. l. Java Web Start 直接沿用 Java 平台安全性的優點，應用程式預設上是在保護模式的環境(sandbox)之下執行，所有本地端磁碟和網路資源的存取都會受到限制，當應用程式並未受到信任時，使用者仍可執行該應用程式而無安全上的虞慮。透過 Java Web Start 執行的應用程式是在本地端快取的，因此先前已經下載過的應用程式便直接在本地端快取目錄呼叫。 38. 逢甲大學 e-Paper (92學年度).

(40) 以SIP為基礎結合Web界面的分散式多功能服務系統. Java Web Start 架構圖. 39. 逢甲大學 e-Paper (92學年度).

(41) 以SIP為基礎結合Web界面的分散式多功能服務系統. 第四章. 系統架構及實作. 4.1 整體架構概觀整體系統堆疊架構圖. Application Conference Module. Whiteboard Module. Polling Module. Mail Module. File Deliver Module. Message Module. Module Manager Information Service. Pipe Service. Rendezvous Service. Resolve Service. Search Service. Other Services. Peer Provider SIP Provider TCP. UDP. 40. 逢甲大學 e-Paper (92學年度).

(42) 以SIP為基礎結合Web界面的分散式多功能服務系統. 4.2 端點協定本專題底層端點協定架構是建構在 SIP 通訊協定之上，而在端點訊息的傳遞流程與基礎服務功能上是參考 JXTA 之端點協定技術，以下將對 JXTA 技術與本專題參考實作的架構做進一步的介紹。 JXTA 端點技術提供了一系列開放式通訊協定，該通訊協定允許小至手機和 PDA、大至個人電腦和伺服器等連線裝置的點對點通訊。在 JXTA 端點所建立的虛擬網路之內，即使有些端點位於防火牆或 NAT 之後或是使用不同架構的通訊協定，任何一個端點仍然可以直接和其他端點和資源溝通。. JXTA 整體軟體架構共分為三種層次： n 平台層(Platform Layer) 平台層又稱為 JXTA 的核心，其主要是將所有 P2P 網路架構所必須支援的共通基礎功能封裝其中，包括端點搜尋、媒體傳輸(例如通過防火牆之管控)、端點與端點群組之建立及其他安全性的機制。 n. 服務層(Service Layer) 服務層包括 P2P 網路內部必須支援才能正常運作的網路服務，但是不同的 P2P 環境內皆有不同支援程度的各類服務，其服務包括搜尋、建立目錄索引、儲存系統、檔案分享與分散式檔案系統、資源集結與租用、協定間之轉換、認證與 PKI(Public Key Infrastructure)等服務。. n. 應用層(Application Layer) 應用層包括功能整合的應用程式之實作，例如點對點訊息傳送、文件與資源分享、娛樂媒體內容管理與發佈、點對點電子郵件、分散式拍賣系統以及其他可在端點網路上發揮的功能。 41. 逢甲大學 e-Paper (92學年度).

(43) 以SIP為基礎結合Web界面的分散式多功能服務系統. JXTA 網路中是由一群相互連結的節點(或稱為端點)所組成，而端點之間可選擇與其他端點組成一個具有共通服務之端點群組，端點群組提供的服務則包括文件分享與聊天等。JXTA 端點發佈其支援服務是利用 XML 文件處理，該文件稱為 Advertisement，其主要功能在於讓其他端點能透過其他描述瞭解如何對該端點服務進行連線。關於訊息的傳遞方面，JXTA 端點是利用其特有的管線(pipe)將訊息傳遞給其他端點，管線是一種非同步且不具方向性的傳送機制，端點服務便是透過該機制進行溝通，其溝通的訊息也是一種將路由、摘要與憑證資訊封裝其中的 XML 文件，另外，管線是與特定端點(Endpoint)繫結而成，及 TCP 通訊埠及其位址。 JXTA 協定架構的主要特色：以下三種特色是 JXTA 協定架構與其他分散式運算架構之主要相異處。 n 以 XML 文件描述(Advertisement)特定端點所提供的網路資源。 n 以特定的抽象介面提供給上層使用(Pipe -> Peer -> Endpoint)。 n 統一的端點定址方式(Peer IDs) 本計畫著重於點對點之間的直接通訊，有鑑於 JXTA 技術的架構因必須處理各技術領域內通用的溝通機制，致使整體架構相當龐大，加上該技術有部分端點協定並不適用本計畫的實作(如端點群組的機制)，因而，本計畫以 JXTA 技術架構作為範本再加以簡化，發展出自訂的點對點通訊協定 ﹝JEMI Peer Protocol﹞。. 本端點協定架構是由各自分散的端點所組成，當一個端點欲向其他端點請求服務時，可對之進行直接的要求，但是因為端點在進入端點網路時無法得知其他端點的實際位址，所以端點網路內需要一個負責管理各端點的中央伺服器，其功能主要負責存放加入該端點網路的所有端點清單，當一個端點欲向其他端點請求服務前，必須對中央伺服器請求該遠端端點的位址﹝本地端點也可在快取目錄中搜尋該端點的位址以減低搜尋時間﹞，方能對其他端點進行服務請求，但是該快取的端點位址須設定其有效的時限，以防止某特定端點位址並非實際的目標位址。. 42. 逢甲大學 e-Paper (92學年度).

(44) 以SIP為基礎結合Web界面的分散式多功能服務系統. 4.2.1.. 端點位址之表示方式﹝Peer Addressing﹞ 本專題所設計的端點協定架構中並沒有特定的實作方式，因此在端點定址上僅提供一個簡單的端點位址物件(Peer Address)表示，該物件提供兩個存取位址資訊的方法：端點識別子(Identifier)與端點位址之解析資訊(Resolved Data)，這兩個端點位址資訊會因為底層實作上的不同而有所差異，為了避免上層架構會因為實作上的不同而導致有平台相依的問題，因此僅提供這個物件給上層元件使用，藉此降低使用上的困難度及管理上的複雜度，以下是端點位址之格式： PeerAddress := Identifier @[ ResolvedData ] Identifier := (A-za-z0-9)+ ResolvedData := URI. 4.2.2.. 端點協定訊息﹝Peer Protocol Message﹞. 本專題所使用的端點協定訊息傳遞格式也是 XML-based，其優點在於無作業平台之間的差異性，因而具有足夠的可攜性與延伸性，加上協定訊息裡的資訊是以人類可以辨識的文字表示，所以對於發展上層應用程式的測試與除錯，無疑是一大幫助。端點協定訊息資訊是存放在 SIP 協定訊息的訊息內容﹝message body﹞之內，共分為請求訊息﹝Request﹞和回應訊息﹝Response﹞，一般而言，傳送請求訊息並接收回應訊息期間稱為一個會議 ﹝Session﹞，協定封包訊息裡的標頭功能在於控制該封包訊息的傳送流程：來源端點位址﹝FromAddress﹞表示建立並傳送該封包訊息的端點位址；目的端點位址﹝ToAddress﹞則表示傳送欲傳送至的端點位址；轉送位址﹝ViaAddress﹞記錄該協定封包訊息傳送經過的端點位址；每個協定封包訊息皆有屬於封包訊息的識別碼﹝SessionId﹞，藉以辨識出每個封包訊息所在的會議編號，以下為端點協定訊息的標頭資訊列表： FromAddress ― 傳送該協定封包訊息的端點位址。 2. ToAddress ― 接收該協定封包訊息的端點位址。 3. SessionId ― 該協定封包訊息的唯一識別碼。 4. Parameter ― 該協定封包訊息的參數。. 1.. 43. 逢甲大學 e-Paper (92學年度).

(45) 以SIP為基礎結合Web界面的分散式多功能服務系統 ü. 請求訊息﹝Request﹞ 請求訊息除了共通之基本協定訊息標頭外，另外加上請求訊息所特有的兩種訊息標頭，以指定請求之服務名稱與方法： n 端點服務名稱﹝Request Service﹞ 指定端點欲對其他端點進行請求的服務名稱。 n 服務請求方法﹝Request Method﹞ 指定請求端點服務的方法類型。. 下圖為請求訊息之範例： <?xml version="1.0" encoding="utf-8"?> <Msg Type="Req"> <FromAddr>jemi:lamer@[sip:Presario700:3035]</FromAddr> <ToAddr>jemi:server@[sip:Presario700:5080]</ToAddr> <SID>bT272jlYCkHxemAo3inkXHh5VLB321B7</SID> <Srv>jemi.peer.rendezvous.RendezvousService</Srv> <Mthd>LOGIN</Mthd> <Param> <RdvIvl-0>***</RdvIvl-0> <RdvInm>UserId</RdvInm> </Param> </Msg>. 44. 逢甲大學 e-Paper (92學年度).

(46) 以SIP為基礎結合Web界面的分散式多功能服務系統 ü. 回應訊息﹝Response﹞ 回應訊息除了共通之基本協定訊息標頭外，另外加上回應訊息所特有的兩種訊息標頭，以指明回應服務之名稱與狀態： n. 端點服務名稱﹝Response Service﹞ 指明被要求之端點服務所回應的服務名稱。. n. 服務回應狀態﹝Response Status﹞ 指明被要求之端點服務所回應之狀態，該狀態為 4 bytes 的整數，其數字格式為「0xdddddd」。在本專題之端點協定架構中，共有以下幾種內建的回應狀態： ² ² ² ² ² ² ² ² ² ² ² ² ² ². STATUS_SUCCESS(0x00) 表示服務處理請求完成。 STATUS_MESSAGE_FORMAT_UNKNOWN(0x10) 表示無法解析請求訊息之格式。 STATUS_MESSAGE_TYPE_UNKNOWN(0x11) 表示無法分辨接收訊息之類型。 STATUS_MESSAGE_VERSION_UNSUPPORTED(0x12) 表示不支援訊息之版本編號。 STATUS_MESSAGE_INCOMPLETE(0x13) 表示接收到的訊息不完整。 STATUS_MESSAGE_TOO_LONG(0x14) 表示接收到得訊息長度過長。 STATUS_ADDRESS_CONFLICT(0x15) 表示訊息中含有衝突的位址。 STATUS_PEER_NOT_FOUND(0x20) 表示欲傳送的端點位址不存在。 STATUS_PEER_TIMEOUT(0x21) 表示無法在特定時間內收到回應訊息。 STATUS_SERVICE_NOT_FOUND(0x30) 表示端點中找不到指定的服務。 STATUS_SERVICE_METHOD_UNKNOWN(0x31) 表示服務不支援指定的請求法。 STATUS_SERVICE_PARAMETER_REQUIRED(0x32) 表示服務需要取得特定參數才能正常運作。 STATUS_SERVICE_ERROR(0x33) 表示服務處理期間發生錯誤。 STATUS_UNAUTHORIZED(0x40) 表示端點需通過認可才能執行某服務之功能。. 45. 逢甲大學 e-Paper (92學年度).

(47) 以SIP為基礎結合Web界面的分散式多功能服務系統. 下圖是回應訊息之範例： <?xml version="1.0" encoding="utf-8"?> <Msg Type="Res"> <FromAddr>jemi:lamer@[sip:Presario700:3511]</FromAddr> <ToAddr>jemi:server@[sip:Presario700:5080]</ToAddr> <SID>9J1GRGrb30D9RWC4GZzUD8iPXnttCL19</SID> <Srv>jemi.peer.rendezvous.RendezvousService</Srv> <Stat>0x00000000</Stat> <Param> <RdvIvl-4>%C2%BEG</RdvIvl-4> <RdvIvl-3>%C3%80s%C2%B3%C3%8D</RdvIvl-3> <RdvIvl-2>LaMer</RdvIvl-2> <RdvIvl-1>%22SKL2%22+%3Cskl2%3E</RdvIvl-1> <RdvIvl-0>0</RdvIvl-0> <RdvInm>Gender</RdvInm> <RdvInm>ContactUsers</RdvInm> <RdvInm>NickName</RdvInm> <RdvInm>LastName</RdvInm> <RdvInm>FirstName</RdvInm> </Param> </Msg>. 46. 逢甲大學 e-Paper (92學年度).

(48) 以SIP為基礎結合Web界面的分散式多功能服務系統. 4.2.3.. 端點堆疊﹝Peer Stack﹞ 端點堆疊的功能在於建立、刪除並管理其下所有的端點提供者，建立端點提供者期間，上層程式可對端點堆疊進行選項設定，以對端點提供者控制其連線或運作流程，例如端點繫結的位址和通訊埠、傳輸模式、位址解析伺服器與代理伺服器等設定，以下是端點堆疊的基本選項： n n n n n n. PATH：端點堆疊指定建立的實作類別。 HOST：端點繫結的位址。 PORT：端點繫結的通訊埠。 TRANSPORT：端點訊息的傳輸模式。 RESOLVER：端點進行位址解析的伺服器位址。 PROXY：端點所使用的代理伺服器位址。. 下圖即為端點堆疊與其上層端點提供者之所屬關係：. Service. Service. PeerProvider. Service. Service. PeerProvider. Service. Service. PeerProvider. PeerStack. 47. 逢甲大學 e-Paper (92學年度).

(49) 以SIP為基礎結合Web界面的分散式多功能服務系統. 4.2.4.. 端點提供者﹝Peer Provider﹞. 端點提供者是本專題中整體端點架構中的核心元件，即表示一個端點的主體，其功能主要有以下兩種： n. 管理、建立與刪除其下的服務元件因為端點提供主要功能在於接收訊息並傳遞至上層的特定服務元件，所以端點提供者在建立服務元件時須提供服務元件進行端點訊息聆聽的介面，以完成訊息的傳遞的機制。另外，端點提供者在建立時皆會預先建立五種內建的服務元件，InformationService、PipeService、ResolveService、 RendezvousService 及 SearchService，上層程式可利用端點提供者提供的五種方法取得這些內建服務元件： ² ² ² ² ². getInformationService() : InformationService getPipeService() : PipeService getResolveService() : ResolveService getRendezvousService() : RendezvousService getSearchService() : SearchService. 若端點提供者欲搜尋或取得其他單一服務或是所有服務名稱清單，以下有存取各服務元件的方法： ² ² ² ². getServiceNames() : String[] hasServices() : boolean hasService(String serviceName) : boolean getService(String serviceName) : Service. 端點提供者另外提供了新增或刪除特定服務元件的方法，以下即為完成這些功能的方法： ² ² ². addService(String serviceName) : Service removeService(String serviceName) : Service removeServices() : void. 48. 逢甲大學 e-Paper (92學年度).

(50) 以SIP為基礎結合Web界面的分散式多功能服務系統. n. 傳送及接收其他端點的協定訊息上層服務元件對端點提供者提出的要求主要是協定訊息的傳遞，這也是端點提供者工作量最為頻繁的動作之一，提供傳遞之訊息類型有要求訊息(Request)及回應訊息(Response)，而其提供之方有為下列兩種(請求/回應)： ² ² ². sendRequest(Request request) : void sendResponse(Response response) : void. 端點提供者也負責聆聽下層 SipProvider 所傳送的事件，當端點提供者被底層告知接收到 SipRequest 和 SipResponse 協定訊息，則從 SIP 協定訊息內容中解析出端點協定訊息，當端點提供者成功解析出正確的訊息後，便判斷該端點協定中如請求或回應等訊息類型，端點提供者需依照端點訊息指示請求或回應的服務名稱將接收到的訊息傳至上層的進服務層，以下為端點提供者對訊息(分為請求與回應兩種情況說明)進行處理的順序圖：處理請求訊息的順序圖： SipProider. PeerProvider. Service. processRequest (SipEvent). processRequest (Request). 處理回應訊息的順序圖： SipProider. PeerProvider. Service. processResponse (SipEvent) processResponse (Response). 49. 逢甲大學 e-Paper (92學年度).

(51) 以SIP為基礎結合Web界面的分散式多功能服務系統. 4.2.5.. 服務元件﹝Service﹞ 服務元件位於端點提供者之上的服務層，該層中包含端點支援所有服務的集合，服務元件的呼叫透過端點提供者進行，服務元件的建立、摧毀或對服務元件本身的其他管理也是由端點提供者負責，而服務元件與端點提供者之間的訊息傳遞可由下圖表示：. Service. sendRequest(Request) sendResponse(Response). PeerProvider. processRequest(Request) processResponse(Response). 本端點協定架構依照端點支援的內建或額外服務分為六種服務類型，以下將對這六種服務元件做完整的介紹： 4.2.5.1. 資訊服務元件(Information Service) 資訊服務元件主要功能在提供端點查看其他端點所擁有的資訊，如端點名稱、使用者基本資料、端點協定版本編號、登入端點網域名稱、可支援服務清單與功能等，另外，應用程式也可依照本身需求將其他特定的應用程式資訊也加至其中以供其他程式取得，下圖為端點對其他端點取得資訊的順序圖。. Main. Information Service. Information. PeerProvider. getInformation new. getInformation sendRequest processResponse. 50. 逢甲大學 e-Paper (92學年度).

(52) 以SIP為基礎結合Web界面的分散式多功能服務系統. 4.2.5.2. 管線服務元件(Pipe Service) 管線服務元件負責管理端點和其他端點之間傳送資料串流的所有管線，其功能有建立、摧毀及查詢目前所開啟的管線資訊，這個服務元件也是整個端點架構中使用最為頻繁的部分，因為端點在與其他端點以特定資料做相互溝通時，必須彼此建立對等的通道以進行訊息的傳送與接收，常用的資料傳送有文字訊息、檔案傳輸甚至是影音媒體串流的傳遞等。. 管線服務元件所支援的管線類型共有三種：輸入管線(Input Pipe)、輸出管線(Output Pipe)及雙向管線(Bidirectional Pipe)，與其他端點建立管線的方式皆分為兩種類型：同步 (Synchronous)與非同步(Asynchronous)建立類型，此兩種建立方式的差別僅在於準備管線時是否註冊聆聽管線之事件及呼叫開啟管線時是否指定管線建立的時限，以下為這兩種管線建立類型之執行順序圖(三種管線類型的建立方式皆相同，所以此順序圖適用所有類型之管線建立)。. 同步類型管線建立之順序圖：. Pipe Service. Main. *Pipe. PeerProvider. Prepare*Pipe new. open sendRequest processResponse. 51. 逢甲大學 e-Paper (92學年度).

(53) 以SIP為基礎結合Web界面的分散式多功能服務系統. 非同步類型管線建立之順序圖：. Pipe Service. Main. *Pipe. PeerProvider. Prepare*Pipe new. addPipeListener open sendRequest processResponse pipeOpened / pipeCannotOpened. 端點與端點之所建立的管線會依使用者呼叫不同的方法而有狀態的轉變，下圖即為管線之狀態轉換圖：. PREPARE open OPENING. destroy OPENED. DESTROYING. DESTROYED. 52. 逢甲大學 e-Paper (92學年度).

(54) 以SIP為基礎結合Web界面的分散式多功能服務系統. 4.2.5.3. 集結服務元件(Rendezvous Service) 集結服務元件提供端點向鄰近端點管理者進行端點網路內的登入、登出或註冊之服務，其支援的方法有 LOGIN、LOGOUT、 MODIFY 及 REGISTER 等，功能分別為登入、登出、修改及註冊，另外，集結在傳遞資訊時是利用 RendezvousContext 存放，藉以指示其他端點需提供的服務項目。這個服務元件所管理的物件又可分為兩種類型：請求者 (Requester)與回應者(Responsor)兩種，故名思義這兩種物件的功能分別為對其他端點請求服務與提供其他端點對服務的請求，而集結服務元件對於以上兩種物件之管理如下： 1.. 請求者的取得方式 getRequester(PeerAddress) : Requester 【註】這個方法呼叫時所使用的參數為端點位址，表示請求者欲進行集結服務請求的對象。. 2.. 回應者的取得與設定方式 hasResponsor() : boolean getResponsor() : Responsor setResponsor(Responsor) : void removeResponsor() : void 【註】回應者所提供的服務可依照實作者的需求而有所不同，因此端點間須事先知道彼此所使用的實作是否相同。. 請求者和要求者在支援的方法上提供相對的呼叫方式，以下即為兩者在支援的方法上的執行順序圖(四種方法的流程皆相同)。. 53. 逢甲大學 e-Paper (92學年度).

(55) 以SIP為基礎結合Web界面的分散式多功能服務系統. 請求者之執行順序圖：. Requester Listener. Rendezvous Service. Requester. PeerProvider. getRequester new. addRequesterListener Login / logout / modify / register sendRequest processResponse processRequesterEvent. 回應者之執行順序圖：. PeerProvider. Rendezvous Service. Responsor. processRequest doLogin / doLogout doModify / doRegister. sendResponsor. 54. 逢甲大學 e-Paper (92學年度).

(56) 以SIP為基礎結合Web界面的分散式多功能服務系統. 4.2.5.4. 解析服務元件(Resolve Service) 解析服務元件通常不直接提供服務給上層元件使用端點，其使用情況是當傳送協定訊息時發現目的端點位址尚未取得解析後的資料，端點提供者會透過其本身所有的解析服務元件對其他端點管理者(通常是端點所登入端點網路之管理者)請求該端點位址的解析服務，而後完成該協定訊息的傳送，其解析的功能便是端點位址對應至實際網路位址的轉換，負責的物件即為 Resolver，同樣地，該物件的處理方式會因為端點網路架構的實作不同而有所差異。以下是解析服務元件在執行時的順序圖：請求端點位址解析之執行順序圖：. Main / PeerProvider. Resolve Service. PeerProvider. resolve sendRequest processResponse. 解析者處理端點位址之執行順序圖：. Resolve Service. PeerProvider. Resolver. processRequest resolve. sendResponse. 55. 逢甲大學 e-Paper (92學年度).