語音電話答錄機BASED ON TAPI

逢 甲 大 學

資訊工程學系專題報告

語音電話答錄機 BASED ON TAPI

學生：楊志鴻(四甲)

黃聖坤(四甲)

許哲榮(四甲)

許嘉興(四甲)

林坤達(四甲)

指導教授：李維聰 老師

中華民國九十年十二月

目錄 圖表目錄---v 摘要---1 第一章 導論---2 1.1 專題製作動機---3 1.2 專題製作目的---3 1.3 系統簡介---3 1.4 環境需求---4 1.5 工作分配---4 第二章背景知識---6 2.1 IP 電話服務---7 2.2 TAPI 1.4~2.X 的架構---8 2.2.1 TAPI 所提供的服務---10 2.2.2 TAPI 兩 TSPI 間的系統架構---11 2.2.3 TAPI 所提供的主從式架構---12 2.3 TAPI 3.0---14 2.3.1 TAPI 的特色---36 2.3.2 選擇 TAPI 的原因---37 2.4 H.323 的探討---37

2.4.1 H.323 的特色---37 2.4.2---37 2.4.2.1 終端機---38 2.4.2.2 閘道---39 2.4.2.3 閘道管理者---39 2.4.2.4 多方會談控制元件---40 2.4.3 H.323 的相關協定---40 2.4.3.1 RAS 協定---40 2.4.3.2 Q.931 通話建立協定---41 2.4.3.3 H.245 控制協定---42 第三章 系統分析與設計---44 3.1 系統需求---45 3.2系統架構圖---45

3.2.1 錄音

3.2.2 聊天室

3.2.3 傳檔

3.2.4 收檔

3.2.5 電話功能

第四章 系統功能---59 4.1 即時通話功能---60 4.2 錄音留言功能---60 4.3 檔案傳輸功能---60 4.4 文字聊天功能---61 4.5 網頁電話雛型---62 第五章系統評估與未來發展---63 5.1 系統特色---64 5.2系統評估---64 5.3 未來發展---64 5.3.1 使功能更加完備---64 5.3.2 Click-to-Call---64 5.3.3 TTS/STT(Text-to-Speech/Speech-to-Text)---65 第六章結論與專題研究過程回顧---66 6.1 結論---67 6.2 遭遇問題與解決方法---67 6.3 心得感想---67 6.3.1 楊志鴻---67 6.3.2 黃聖坤---67

6.3.3 許哲榮---69

6.3.4 許嘉興---69

6.3.5 林坤達---70

圖表目錄 圖 2.1-1 媒體集中：聲音、資料和視訊---8 表 2.2-1 TAPI 演進過程表---9 圖 2.2-1 TAPI 的網路架構圖---10 圖 2.2-2 TAPI 服務分類---10 圖 2.2-3 TAPI 與 TSPI 間系統架構圖---12 圖 2.3-1 TAPI 2.1 系統架構---13 圖 2.3-1 IP 和 PSTN 電話服務的集中---14 圖 2.3-2 TAPI 結構---15 圖 2.3-3 TAPI 3.0 物件關係---16 圖 2.3-4 「呼叫」與「呼叫中心」物件的關係---17 圖 2.3-5 是使用者和核心模式元件的 DirectShow 篩選器圖表範例 ---18 圖 2.3-6 H.323 結構---19 圖 2.3-7 H.323 元件---20 圖 2.3-8 H.323 TSP 結構---21 圖 2.3-9 Alice 登錄並重新整理其 IP 位址---22 圖 2.3-10 John 查詢 Alice 的 IP 位址---22 圖 2.3-11 一旦完成功能協商，會議就開始了---22

圖 2.3-12 網路拓樸：寄件者的檢視---23 圖 2.3-13 實際網路拓樸---24 圖 2.3-14 使用擴展樹的 IP 多點傳送---25 圖 2.3-15 IP 多點傳送會議架構---26 圖 2.3-16 John 加入 SDP 工作階段描述字元---27 圖 2.3-17 Jim 查詢 ILS 會議伺服器---27 圖 2.3-18 Mary 和 Alice 加入會議---28 圖 2.3-19 使用會合控制加入會議---28 圖 2.3-20 一般 SDP 屬性---29 圖 2.3-21 SDP 和 ACL---30 圖 2.3-22 SDP 分發---30 圖 2.3-23 加密多點傳送資料流---31 圖 2.3-24 用 TAPI 3.0 保留資源---33 圖 2.3-30 TAPI 3.0 和 NetMeeting 2.0 相互操作---36 圖 2.4-1 H.323 系統架構---38 圖 2.4-2 H.323 的終端機---39

圖 2.4-3 Direct Call Signaling---41

圖 2.4-4 Gatekeeper Routed Call Signaling---41

圖 3.2.1 錄音---45 圖 3.2.2 聊天室---46 圖 3.2.3 傳檔---49 圖 3.2.4 收檔---50 圖 3.2.5 電話功能---51~58 Form_load ( ) ---51 btnInitial_dial( ) ---52 btnDial_Click( ) ---53 btnAnswer_Click( ) ---54 btnDisconnect_Click( ) ---55 SupportH.323( ) ---56 圖 4.1 即時通話功能---60 圖 4.2 錄音留言功能---60 圖 4.3 檔案傳輸功能---61 圖 4.4 文字聊天功能---61 圖 4.5 網頁電話雛型---62

摘要 為提供電話整合業者一個友善、方便的介面，Microsoft 提出 TAPI 程 式介面，但是先前的版本偏重於通話控制(call control),所以沒有受 到太大的重視。隨著網際網路的蓬勃發展，網際通訊服務成為大家致 力追求的目標。而 TAPI 3.0 正提供了這樣的服務，且簡化了 H.323 通 訊協定所必須經歷的繁複過程，是否 TAPI3.0 將因此而步入坦途而廣 為採用？本文將深入探討 TAPI 的過去與末來。 TAPI 3.0 是集合傳統式 PSTN 電話服務和 IP 電話服務的漸進式 API。IP 電話服務是新方興的技術，能夠在現有的區域網路、廣域網 路 和 Internet 上融合聲音、資料和視訊。 TAPI 3.0 讓 IP 電話服 務在 Microsoft® Windows® 作業系統上成為可能﹔這方法可以簡單而 普通的方法結合二或多部電腦，並存取這種連接上所包涵的所有媒體 資料流。 TAPI 3.0 支援標準的 H.323 會議和 IP 多點傳送會議。它使用 Windows 2000 作業系統的 Active Directory 服務來簡化公司內的部 署，包含服務品質 (QoS) 支援，以提高會議品質，使網路易於管理。

第一章 導論 1.1 專題製作動機 1.2 專題製作目的 1.3 系統簡介 1.4 環境需求 1.5 工作分配

1.1 專題製作動機 近幾年來來，Internet 的蓬勃發展，使得人們可以藉由 Internet 的功能來簡化一些繁瑣的事情，如通信、開會等。而現今我們所使用 的電話系統乃是傳統式的 PSTN 電話服務，傳統電話傳輸在通話前需要 先建立線路，此線路只提供雙方使用，直到通話完畢，但由於現在網 路的發達，我們能將聲音透過網路來傳輸，因為能降低大量通訊費用， 而且能同時傳輸資訊、影像會議( Vedio Conference )，執行多種應 用程式，所以能在電腦通訊市場上備受矚目且迅速發展。 而由 Microsoft 公司所提出的 TAPI 3.0 漸進式電話服務應用程式 介面，集合了傳統式 PSTN 電話服務和 IP 電話服務，因此我們想藉由 TAPI 3.0 來整合各項服務做出軟體電話，將電話功能資訊化、電腦化， 使大眾能在通話方面減少諸多不便。 所以我們希望這套系統能夠提供： 1. 簡易明瞭的操作介面。 2. 多項網路功能服務，如通話、傳檔、留言、文字聊天。 基於上述幾項概念，我們想著手於電話這一產品的 e 化，因此我 們開始思考並討論系統的組織架構，以製作此一軟體，以期提供大家 對於電話使用的方便性。 1.2 專題製作目的 關於我們的電話語音答錄機，我們規劃了四項主要功能： 1. 網路電話功能： (1) 利用現有網路以及 TAPI 3.0 提供通話功能。 (2) 大幅減少在傳統電話的花費 2. 語音留言以及撥放功能： (1) 將現今日常生活的答錄機功能予以軟體化。 3. 檔案傳輸功能： (1) 如同時下的一些軟體的檔案傳輸功能，如 MSN。 4. 文字聊天訊息： (1) 類似 ICQ 文字訊息傳送功能。 (2) 如同網路聊天室的介面。 我們的目標是藉由組合各功能完成一個完整的軟體電話，減少在 傳統電話上的費用，並且善用網路的聊天及檔案交流功能。 1.3 系統簡介

我們這一套系統基本上是由 Visual Basic6.0 所撰寫完成的。然而 此系統也包括了兩個方面的程式，一個是 TAPI 方面的技術，而另一個 則是 Winsock 方面的相關技術。TAPI 方面，主要是負責語音電話部分 的功能，而在 Winsock 方面則是負責關於私人聊天室、傳送以及接收 語音留言檔的部分。 在我們的系統中，還包含了以下幾個子功能： 1. 網路電話功能：讓網路上的兩個 client 端電腦可以經由此功能達到 語音溝通的效果。 2. 私人聊天室功能：讓網路上的兩台電腦可以透過文字互相傳送來達 到雙方文字溝通的效果。 3. 語音留言功能：如遇對方不在時，可透過此功能做語音留話給對方， 等候對方返回時，可以聽取留言。 4. 傳送檔案功能：可以利用此功能，將檔案傳送給網路上的另一台電 腦，以達到檔案分享的功能。 1.4 環境須求 為了讓本系統可以正確地且順利執行，所以在此列出了客戶端 (Client)與伺服端(Sever)它們所須要的基本軟硬體須求。但在本系統 中，基本上每一個終端機(Terminal)，即每一台電腦，皆有可能扮演 客戶端與伺服端的功能。因為當我們在傳送檔案給另一方時，此時傳 送檔案的這一端，即為客戶端，然而接收檔案的那一端即為伺服端。

1.4.1 Client 端 & Sever 端環境

軟體須求：

Windows2000/Windows XP Visual Basic6.0

硬體須求：

CPU：基本上可以正常執行 Windows2000 & Windows XP 即可。 RAM:建議 128MB 以上或 256MB。 硬碟空間：至少 2GB。 須具備有一個 Speaker(喇叭)及 MicroPhone(麥克風)。 1.5 工作分配 1. 資料收集 (1) TAPI 3.0 相關文件

楊志鴻、許嘉興、許哲榮、林坤達、黃聖坤 (2) H.323 相關文件 林坤達、許嘉興 (3) 程式參考資料( 電話、錄音、傳檔、聊天 ) 電話 － 許哲榮、林坤達、楊志鴻、黃聖坤 錄音 － 許嘉興 傳檔、聊天 － 黃聖坤 2. 程式架構 整體 － 楊志鴻 電話 － 許哲榮、林坤達 錄音 － 許嘉興 傳檔、聊天 － 許嘉興、林坤達 3. 程式撰寫 電話 － 許哲榮、林坤達、楊志鴻、黃聖坤、許嘉興 錄音 － 許嘉興 傳檔、聊天 － 黃聖坤

第二章 背景知識 2.1 IP 電話服務 2.2 TAPI 1.4~2.X 的架構 2.2.1 TAPI 所提供的服務 2.2.2 TAPI 與 TSPI 間的系統架構 2.2.3 TAPI 所提供的主從式架構 2.3 TAPI 3.0 2.3.1 TAPI 的特色 2.3.2 選擇 TAPI 的原因 2.4 H.323 的探討 2.4.1 H.323 的特色 2.4.2 終端機、閘道、閘道管理者、多方會談控制元件 2.4.3 H.323 的相關協定 2.4.3.1 RAS 協定 2.4.3.2 Q.931 通話建立協定 2.4.3.3 H.245 控制協定

前言

電話應用程式介面(Telephony Application Programming Interface;TAPI)是由個人電腦業界的兩大巨人微軟及英特爾兩家公 司於 1994 年所提出的標準介面希望藉由這一標準統一電腦應用程式與 底層通訊硬体間的溝通介面。但是在提出 TAPI 1.3 版附加於

Windows3.1 後，並沒有如願地廣為採用，連硬体廠商也沒有全面的配 合提供電腦應用程式之驅動程式(Telephony Severice

Provider;TSP)。但是在 TAPI 1.4 版隨著 Microsoft Windows 95 的風 行普及，及功能更加完整的 TAPI 2.0 版隨著 Microsoft Windows NT 4.0 上市，TAPI 逐漸廣為大家所重視。

網際網路與電信服務的結合是最近一股新興科技潮流，例網際電 話(internet Phone)、網際傳真(Internet Fax)及訊息整合系統 (Unified Message System;UMS)等系統的風行網路上的電信服務勢必 對傳統的電信業造成巨大的衝擊。TAPI 介面也符合潮流的腳步，將隨 著 Windows 2000 推出 TAPI 3.0 版，簡化了標準通訊協定中繁複的通 訊步驟，提供網際網路上的電信服務。 本文將針對 TAPI 介面的演進，從 1.4 版到 3.0 版逐一的介紹其系 統架構及演進歷程，並進一步的探討 TAPI 末來的發展趨勢，尋求出日 後電腦電話整合應用程式展的契機。 2.1 IP 電話服務 IP 電話服務是新興的技術，能夠在現有的區域網路、 廣域網路和 Internet 上融合聲音、資料和視訊。 尤其 IP 電話服務使用開放的 IETF 和 ITU 標準，讓多媒體傳輸 在任何使用 IP 的網路上移動，提供使用者在媒體實體 (例如 POTS 線路、ADSL、ISDN、專線、同軸電纜、人造衛星和雙絞線) 和實體位 置的彈性。因此，同一個傳送 Web、電子郵件和資料傳輸的遍佈網路， 可用來連接世界各地的個人、企業、學校和政府。 TAPI 3.0 是集合傳統式 PSTN 電話服務和 IP 電話服務的漸進式 應用程式介面 (API)。 IP 電話服務可讓公司和個人降低現有服務成 本 (例如聲音和廣播電視)，同時增加傳輸方法，以納入現代視訊會 議、應用程式共用和白板工具。 過去，公司部署個別的網路來處理傳統的聲音、資料和視訊傳輸。 每個網路都有不同的傳輸要求，安裝、維護和重新組態這些網路的花 費很大。而且，由於這些網路在實體上截然不同，即便可能，整合也 很困難，以致限制其潛在的用途。 IP 電話服務藉由指定每個聲音、視訊和資料的公用傳輸、IP，將

這三種網路混合成一個。結果使網路更易於管理，降低支援費用，形 成新型合作工具並提高了生產力。 IP 電話服務的可能應用包括遠端交換、即時文件合作、遠距教學、 人員訓練、視訊會議、視訊郵件和可視需要取得的視訊。 圖 2.1-1 媒體集中：聲音、資料和視訊 2.2 TAPI 1.4~2.X 的架構 TAPI 的歷史演進及搭配的作業系統可由表 2.2-1 所示。由表中可 以看出 TAPI 的發展可區為兩個階段，區分點介於 TAPI 2.1 版及 TAPI 3.0 版之間。主要的差別在從 TAPI 3.0 版後開始提供網際網路電信服 務。在這一段落中，我們將針對 TAPI 2.X 版之前的架構作一說明，至 於 TAPI 3.0 版將於下一章節中說明。

TAPI 的網路角色定位可由圖 2.2-1 所示，在網路的國際開放通訊 標準模型(International Organization for Standardization Open Systems Interconnection;ISO/OSI)中，TAPI 是介於網路傳輸層 (Network Layer)及資料傳輸層(Data-link layer)之間。這意味著 TAPI 的發展依舊是循著視窗開放式環境架構(Windows Open System

Architecture;WOSA)所發剝出來的。對於一個電腦電話整合程式設計 開發者而言，必須瞭解的就只是 TAPI 程式介面，而不需去瞭解底層各 個硬体所提供的介面，就能夠使用各個硬体所提供的功能。相對的，

對於一個硬体廠商而言，所必須提供的就是依照電話用程式之驅動程 式介面(Telephony Service Provider Interface ;TSPI)所開發出來 的電話應用程式驅動程式 TSP，這樣就可以 TAPI 掌控到底層所有的硬 体設備。在這樣的架構下，對於程式設計開發者與硬体廠商都減輕不 少負擔，不顧慮太多的，而扮演橋樑角色的 TAPI 介面就負起了管理與 溝通的角色，讓資源能夠妥善的共享並發揮效能。

TAPI 版本 要點及特性

TAPI 1.3 1.Microsoft 及 Intel 於 1994 年 提出 2.附加於 Windows 3.1 TAPI 1.4 1. 隨 Windows 95 提出(1995 第四 季) 2. 提供 32 位元的應用程式發展 環境 TAPI 2.0 1. 隨 Windows NT 4.0 提出(1996 第三季) 2. 更新部分功能，提供話務中心 介面 3. 提供 UniCode 環境 TAPI 2.1 1. 可附加於 Windows 95 及 Windows NT 4.0 之，但 Windows 95 只可以執行客服端(cline)，伺服 器端(sever)必須執行於 Windows NT 4.0 Severler 2. 真正提供主從式架構 (Cline-Sever Architecture) TAPI 3.0 1. 隨 Windows 2000 上市 2. 提供網際網路電信服務 表 2.2-1 TAPI 演進過程表

Application layer Presentation layer Session layer Transport layer Network layer Data-link layer Physical layer 圖 2.2-1 TAPI 的網路架構圖 2.2.1 TAPI 所提供的服務 圖 2.2-2 TAPI 服務分類 TAPI 所提供的服務可區分為兩大類，如圖 2.2-2 所示，一為協助 電話傳輸功能(Assisted Telephony)，這一類功能只有提供四個簡單 的介面給應用程式使用，主要的作用在於提供應用程式快速簡單的電 Application

other TAPI Unimodem

Serial device Serial port Assisted 透過簡單的機制提供應用程式能夠達到 Telephony 通話或資料傳輸服務 Basic Services 相當於一般傳統電話機所有的通話功能 Supplementary Services 提供增補的功服務，例如交換機上供的特殊 服務，如轉接、代接等功能

Extended Services 提供擴充功能的機制，用在 TAPI 所沒有定義而硬 体廠商所提供的專有功能

話撥通方式，至於其他的控制就沒有完整的解決方案。所以對於一般 通訊控制應用程式並不適用，而且不可與正規的 TAPI 應用程式介面混 合使用，因為這一部分的功能並不透過 TAPI 正常的管道來使用硬体設 備，若混合著使用將會對於硬体資源造成錯亂，無法確切的掌控硬体 資源。而另一大類為完整的電話傳輸功能，其中區分為三類服務：基 本電話傳輸服務(Basic Telephone Service)、增補電話傳輸服務 (Supplementary Telephony Service)及擴充電話傳輸服務(Extended Telephony Service)等三種模式。基本電話傳輸服務包含的功能為一 般電話機所有的基本功能，例如打一通話話(Make Call)、掛電話(Drop call)等等。當然在這一部分中也包含了 TAPI 應用程式的初始化、結 束機制及訊息傳遞的管設定等功能。至於增補電話傳輸服務部分，則 是提供交換機上增加的友善服務，例如：代接(Pickup Call)、轉接 (Transfer Call)、保留(Hold Call)、三方通話(Conference Call)等 功能。而對於電話機的控制部分，例如：話機聲音控制、燈號顯示等 功能也屬於這一類服務。而充電話傳輸服務部分，則留下一個彈性空 間給提供電話傳輸驅動程式的硬体廠商。若有一些特殊的功能，在 TAPI 介面中並沒有定義者，硬体廠商就可以於此類提供獨家特殊的以務。 從 TAPI 的服務分類中，我們可以看出此時的 TAPI 功能著動於通話 控制(Call Control)部分，對於語音媒体(Mdia)的處理是完全沒有的。 那麼是到 TAPI 可以用來傳送語音、可以用來製作答錄機又如何達成的 呢？因為在 TAPI 還沒尚末提出時，微軟公司在作業系統即包含有一組 媒体控制程式介面(Media Control Interface ;MCI)。因為有這麼一 組程式介面存在，所 在 TAPI 介面中就沒有關於媒体控制介面，完全 依附於之前的標準介面，採用同樣的運作方式，因為沒有必要重複做 同樣的功能。因此對於需要處理的媒体控制，就必須有硬体廠商的配 合，提供相對應的媒体控制驅動程式，如此方能配點完成語音媒体控 制的功能。 2.2.2 TAPI 與 TSPI 間的系統架構

簡單的說 TAPI 與 TSPI 的架構關係是：TSPI 是介於 TAPI 與硬体間 的一個標準溝通介面。對上能夠提供 TAPI 所要求的服務，而對下則是 對硬体發出命令，以期能夠達成應用程式透過 TAPI 所要求的服務。如 此一來，對於應用程式而言，就不需要擔心底層所用的硬体是何廠商 所提供的，只商有提供符合 TAPI 版本的 TSP 即可。而對於硬体廠商而 言，只要提供相對應的電話傳輸驅動程式版本(TSP)，即可符合所有的 TAPI 應用程式，而且不需考慮到資源的管理工作，因為若是硬体廠商 自行提供驅動程式時，必須考慮到多個應用程式都用到同一個硬体設

備時應如何處理，何者具有優先權，但 TSPI 中並不需要考慮這些問題， 為 TAPI 會統一管理這些硬体裝置，決定應式使用裝置的優先順序。 TAPI 介面 TSPI 介面 圖 2.2-3 TAPI 與 TSPI 間系統架構圖 圖 2.2-3 所示為 TAPI 與 TSPI 系統架構圖。由圖中可看出當一個應 用程式使用到 TAPI 時，不管是 16 位元 32 位元的應用程式均會呼叫到 TAPI 的重態連結程式庫—TAPI32.DLL(若為 16 位元的應用程式會先透 過一中間轉換媒介”Thunk”，將 16 位元轉換成 32 位元再呼叫 TAPI32.DLL)。而 TAPI 的動態連結程式庫會將應用程式所發出的服務 要求傳到 TAPI 伺服程式—TAPISRV.EXE，由 TAPI 伺能程式解譯其中的 要求，再決定往下向 TSP 要求服務或直接處理回應，在這裡 TAPI 即是 扮演統一管理的角色。而在登記註冊編輯器(registry)中則記錄有各 家硬体驅動園式及其硬体的相關資訊，如硬体 A 卡提供有四條通訊線、 硬体 B 卡提供有一備通訊線，則在登記註冊編輯器中就會有每一條通 訊線的資訊，包含在系統中的硬体裝置編號、特性等相關訊息。因為 應用程式在進入 TAPI 使用環境後就會對所有的裝置搜尋過一次，瞭解 所有的裝置的特性，並採用合適的裝置。這樣的機制對於硬体提供者 而言是相當的方体，因為不需要額做資源管里的工作，TAPI 伺服程式 便會做妥善的管理相對應裝置的使用權限及使用狀況。 2.2.3 TAPI 所提供的主從式架構 對於剛接觸 TAPI 2.0 的使用者而言，一定會對於 TAPI 2.0 手冊上 16 位元 TAPI 應 用程式 TAPI 3.2DLL TAPI.DLL(16 位 元 Thunk TAPI 3.2DLL 32 位元 TAPI 應 用程式 32 位元 TAPI 伺服程式 TSP 1 TSP n TAPISRV.EXE TSP 1 Kernel Mode 驅動程 式 TSP n Kernel Mode 驅動程 式 電話傳輸控制台 編號特性設定等等 登記註冊 編輯器

的說明感到疑惑，為什麼 TAPI 2.0 說有提供主從式的架構，為什麼在 架構上顯現不出這特性呢？這原因在於 TAPI2.0 所謂的主從式的架構 是指由 TSP 本身提供的主從式，而非微軟公司的 TAPI 系統所提供的主 從式架構。也就是說對於一個硬備商所提供的電話傳輸驅動程式式本 身就必須具備有主從式架構，廠商必須提供伺服器端的伺服程式以提 供資訊傳遞轉換服務。如此一來自然可謂為主從式架構。這樣的說法 自然只是微軟公司的一時權宜之計，也被眾多使用者所詬病。所以在 後來便提出 TAPI 2.1 版的架構，來真正達到主從式的架構。如圖 2.3-1 所示便是 TAPI 2.1 系統架構圖。 客服端 伺服器端 圖 2.3-1 TAPI 2.1 系統架構 TAPI 2.1 是近續 TAPI 2.0 的架構，但是為了滿足主從式架構下的 產物，它並不是隨著哪一個作業系統一起推出，因此必須額外做安裝 設定的工作，因此在執行上有些限制。客服端可以在 Windows 95/98 鐹 Windows NT 4.0 上執行，而伺服器端就必須在 NT 4.0 Sever 端方 可執行，主要的原因在於提供了管理使用權限的功能，必須利用 NT Sever 的使用者管理工具方能達成。 在客服端我們可以看到微軟公司提供一個遠端電話傳輸驅動程式 (Remote Service Provider)，它用來與遠端的伺服器端連結溝通。將 客服端應用程式所下的命令傳送到伺服器端，並將接收伺服器端執行 的結果回傳給相對應的應用程式。 而在伺服器端，我們發現了以前沒有的兩個模組：系統管理員 (Administrator)及客服端管理規則(Client Manager)。系統管理員由 電話傳輸應用程式 TAPI Service 電話傳輸應用程式 TAPI Service 電話傳輸驅動程式 系統管理員 客服端管理規則 電話傳輸硬体 Remote SP

微軟公司提供，與 NT Server 的使用者管理員結合在一起，如此便可 以設定使用者可以享用的服務有那些，例如設定某些硬体或哪幾條通 訊線可為某人使用。而客服端管理規則則是由軟体廠商提供，例如某 家軟体廠商可以設定其傳送的路徑，在尖峰時段經由 A 路徑連接，而 離峰時段經由 B 路徑連接。客服端規則是可以安裝多個的，決定權在 於伺服器端的管理者，但是後續安裝的規則會擁有較高的優先權，因 此可能會更改了先前安裝設定的管理規則，因為系統是依照安裝順序 執行管理規則，後面的命令會覆蓋掉前面的命令。 由此可以說明 TAPI 2.1 的運作方式依舊是依 TAPI 2.0 的系統架 構，只是將客服端及伺服器端區分出來。之前的電話傳輸驅動程式依 舊可以執行於伺服器端，而客服端經過適當的註冊過程，就可透過網 路享用伺服器端的資源，兩者間的傳輸過程透過 TAPI 2.1 的主從式架 構達成，對於使用者而言並未感受到任何的不同。 2.3 TAPI 3.0 隨著電話服務和呼叫控制在桌上型電腦中的普及，需要用一般電話 服務介面讓應用程式可以存取任意電腦上可用的所有電話服務選項。 呼叫上的媒體或資料也必須以標準方式供應用程式使用。 TAPI 3.0 提供了簡單而普通的方法，能夠結合兩部或多部電腦， 並存取這種結合所涵蓋的任何媒體資料流。它摘錄了呼叫控制功能， 讓不同而看似不相容的傳輸通訊協定提供應用程式使用的公用介面。 當公司開始從昂貴而缺乏彈性的電路交換公用電話網路轉移至有智 慧、彈性而且便宜的 IP 網路時，IP 電話服務能夠自若地面對爆炸性 的成長。Microsoft 預料到這個趨勢，所以建立了強健的電腦電話服 務基礎結構 TAPI。目前 TAPI 的第三個主要版本，適合快速、簡單地 部署 IP 電話服務應用程式。

圖 2.3-1 IP 和 PSTN 電話服務的集中

TAPI 3.0 整合多媒體資料流控制和傳統電話服務。此外，它是從 TAPI 2.1 API 到 COM 模式的改進，可用任何語言編寫 TAPI 應用程 式，例如 C/C++ 或 Microsoft® Visual Basic® 。

除了支援傳統的電話服務提供程式，TAPI 3.0 還支援標準 H.323 會議和 IP 多點傳送會議。TAPI 3.0 使用 Windows® 2000 Active Directory 服務來簡化公司內的部署，支援服務品質 (QoS) 功能，提 高會議品質，使網路易於管理。

圖 2.3-2 TAPI 結構 TAPI 3.0 有四個主要元件：

l TAPI 3.0 COM API l TAPI 伺服器

l 電話服務提供程式 l 媒體資料流提供程式

與 TAPI 2.1 相比，TAPI 3.0 API 是以一組 COM 物件來建置的。 將 TAPI 移到 COM 模式可讓 TAPI 功能的元件升級，也可讓開發者使 用任何語言來編寫啟動 TAPI 的應用程式。

TAPI 伺服器程序 (TAPISRV.EXE) 從 TAPI 3.0 和 TAPI 2.1 摘錄 TSPI (TAPI 服務提供程式介面)，讓 TAPI 2.1「電話服務提供程式」 搭配 TAPI 3.0 使用，以維護 TAPI 的內部狀態。 「電話服務提供程式 (TSP)」負責將 TAPI 中與通訊協定無關的呼 叫模式融入通訊協定專用的呼叫控制機制中。TAPI 3.0 提供 TAPI 2.1 TSP 回溯相容性。 兩個 IP 電話服務提供程式 (及其相關的 MSP)在 出廠時就提供 TAPI 3.0：H.323 TSP 和 IP 多點傳送會議 TSP 將在後 面討論。 TAPI 3.0 提供統一的方式從呼叫中的存取媒體資料流，此方式支 援 DirectShowTM API 作為主要的媒體資料流處理程式。TAPI「媒體 資料流提供程式 (MSP)」為特殊的 TSP 的建置了 DirectShow 介面， 而任何利用 DirectShow 資料流的電話服務都需要這個介面。一般的 資料流由應用程式處理。

圖 2.3-3 TAPI 3.0 物件關係 TAPI 3.0 API 中包含五個物件： l TAPI l 位址 l 終端機 l 呼叫 l 呼叫中心 TAPI 物件是 TAPI 3.0 的應用程式入口。這個物件代表本機電腦 可以存取的所有電話服務的資源，並容許應用程式行列出所有本機和 遠端的位址。 位址物件代表呼叫來源或目的地。而從這個物件可以找到位址功能 (例如媒體和終端機支援)。應用程式可以在「位址」物件等候呼叫， 或從「位址」物件建立撥出呼叫物件。 終端機物件代表在連線終點或起點的接收器或轉換器。「終端機」 物件可以映射到作為人機介面的硬體，例如電話或麥克風，但也可以 是一個檔案，或是可接受輸入或建立輸出的其它任何裝置。 「呼叫」物件代表本機位址和一或多個其它位址之間的位址連接。 (這個連接可以是直接，或是透過「呼叫中心」連接的) 。你可以將「呼 叫」物件想像成電話呼叫的第一組檢視。所有呼叫控制都透過「呼叫」 物件來完成。「呼叫中心」的每個成員都有一個呼叫物件。 呼叫中心物件代表一組相關的呼叫。「呼叫中心」物件不能由應用 程式直接建立，它是在透過 TAPI 3.0 接收撥入的呼叫時間接建立的。 使用者可用「呼叫中心」物件，在一個呼叫或會議中列舉其它的與會 者，而且如果有足夠的許可權，也可以 (由於 COM 的位置獨立特性) 在與這些使用者相關的遠端「呼叫」物件上執行呼叫控制。 圖 2.3-4 「呼叫」與「呼叫中心」物件的關係

發出呼叫 1. 建立和啟動 TAPI 物件。 2. 使用 TAPI 物件列舉電腦上所有可用的「位址」物件 (例如網 路卡、資料機和 ISDN 線路)。 3. 列舉各「位址」物件所支援的位址類型 (例如電話號碼、IP 位 址等等)。 4. 根據適當媒體 (語音、視訊等) 和位址類型的支援查詢來選擇 「位址」物件。 5. 使用「位址」物件的建立呼叫方法來建立與特定位址相關的「呼 叫」物件。 6. 在「呼叫」物件上選擇適當的終端機。 7. 呼叫「呼叫」物件的結合方法以找到呼叫。 應答呼叫 1. 建立並啟動 TAPI 物件。 2. 使用 TAPI 物件列舉電腦上所有可用的「位址」物件 (例如網 路卡、資料機和 ISDN 線路) 。 3. 列舉各「位址」物件所支援的位址類型 (例如電話號碼、IP 位 址等等) 。 4. 根據適當媒體 (語音、視訊等) 和位址類型的支援查詢來選擇 「位址」物件。 5. 以適當的「位址」物件在特定媒體類型中登錄有興趣的物件。 6. 以「位址」物件登錄呼叫事件處理程式 (亦即建置 ITCallNotification 介面)。 7. TAPI 透過 ITCallNotification 通知應用程式有新的呼叫，然 後建立「呼叫」物件。 8. 在「呼叫」物件上選擇適當的終端機。 9. 呼叫「呼叫」物件的結合方法以找出呼叫。 10. 呼叫「呼叫」物件的結合方法以應答呼叫。 為了有效控制和操作媒體資料流，Windows ® 作業系統提供可擴展 的構架，稱為 DirectShow。DirectShow 透過暴露的 COM 介面提供 TAPI 3.0 統一的資料流控制。 DirectShow 的中心是稱為篩選器的可插入元件的模組化系統，它 安排在稱為篩選器圖表的組態中。稱為篩選器圖表管理員的元件監視 這些篩選器的結合，並控制資料流的資料流動。每個篩選器的功能由 一些稱為 PIN 的特殊 COM 介面來說明。每個 PIN 執行個體都能消滅 或產生資料流資料，例如數位語音。

COM 物件通常暴露於使用者模式的程式下，DirectShow 資料流結 構包含 Windows 驅動程式模式的擴展，這個模式可在裝置驅動程式層

直接結合媒體資料流。下面的圖 6 顯示簡單的 PSTN 至 IP 橋接器。 來自 ISDN 線路的 64 Kbps 聲音資料流壓縮成 G.723 語音資料流， 然後送到 RTP 負載處理程式，再傳送到網路上。 圖 2.3-5 是使用者和核心模式元件的 DirectShow 篩選器圖表範例 TAPI 3.0 中的 H.323 傳輸 H.323 是一種複雜的國際電信聯盟 (ITU) 標準，適用於服務品質無法 保證的無連接網路的多媒體傳輸 (聲音、視訊和資料)，例如 IP 網路 和 Internet 等。它提供點對點和多點會議的呼叫控制、多媒體管理 和頻寬管理。H.323 指令支援標準語音和視訊碼，支援透過 T.120 的 資料共享。而且，H.323 標準獨立於網路、作業平台和應用程式，使 任何 H.323 相容的終端機與其它任何終端機進行相互操作。 圖 2.3-6 H.323 結構 H.323 可以在現行封包交換網路上傳送多媒體資料流。為了減小區 域網路反應時間的影響，H.323 可當作「即時傳輸通訊協定 (RTP)」 使用，RTP 是設計用來處理 Internet 上即時語音和視訊資料流需求 的 IETF 標準。

H.323 標準指定三個指令和控制通訊協定： l 呼叫控制的 H.245 l 呼叫訊號傳輸的 Q.931 l RAS (登錄、許可權和狀態) 訊號傳輸功能 H.245 控制通道負責控制 H.323 終端機操作的控制資訊，包含功 能交換、指令和指導。Q.931 可用來在兩個終端機之間建立連接，RAS 控制登錄、許可權及端點與閘道守衛 (如果沒有閘道守衛，不能使用 RAS) 之間的頻寬功能。若需有關閘道守衛的詳細資訊，請參閱下節。 H.323 定義四個主要元件，這些元件都以 H.323 傳輸系統為基礎。 l 終端機 l 閘道 l 閘道守衛 l 多點控制單元 (MCU) 終端機是指網路用戶端的端點。所有終端機都必須支援聲音傳輸； 視訊和資料支援則是選擇性的。 閘道是 H.323 會議的選擇性元件。閘道將 H.323 會議橋接到其它 網路、傳輸通訊協定和多媒體格式。如果不需要結合其它網路或非 H.323 相容終端機，就不需要閘道。 閘道守衛執行協助維持網路強健性的兩項重要功能：位址轉換和頻 寬管理。閘道守衛將區域網路 別名映射到 IP 位址，然後在需要時提 供位址搜索。閘道守衛還執行呼叫控制功能，以限制 H.323 區域內的 H.323 連接的數量和這些連接使用的總頻寬。H.323 系統不需要閘道 守衛；但如果有閘道守衛，終端機就必須使用此服務。 圖 2.3-7 H.323 元件 多點控制單元 (MCU) 支援三個或更多端點之間的會議。MCU 由必

要的多點控制器 (MC) 和 0 個或多個多點處理器 (MP) 組成。MC 執 行所有終端機之間的 H.245 協商，以決定一般語音和視訊處理功能， 而多點處理器 (MP) 在終端機的端點間傳輸語音、視訊和資料流。 保證任何 H.323 用戶端都支援下列標準：H.261 和 G.711。H.261 是 ITU 標準的視訊編解碼器，用來傳輸速度為 64 Kbps、解析度為 176x44 圖素 (QCIF) 的壓縮視訊。G.711 是 ITU 的標準語音編解碼 器，設計用來傳輸速度為 48、56 和 64 Kbps 的 A-law 和 -law PCM 的語音。 H.323 用戶端可以選擇性地支援其它編解碼器：H.263 和 G.723。 H.263 是以 H.261 為基礎並與其相容的 ITU 標準視訊編解碼器。它 提供優於 H.261 的壓縮功能，並以 176 x 44 圖素 (QCIF) 解析度傳 輸視訊。G.723 是設計用於低位元速率操作的 ITU 標準語音編解碼 器。 H.323「電話服務提供程式」(及其相關的「媒體資料流提供程式」) 可讓啟用 TAPI 的應用程式使用區域網路上任何 H.323 相容的終端 機來參與多媒體工作階段。 特別的是 H.323「電話服務提供程式 (TSP)」建置了 H.323 訊號 傳輸堆疊 TSP 接受許多不同的位址格式，包含姓名、電腦名稱和電子 郵件位址。 H.323 MSP 負責建立 H.323 連接 (包含 RTP、RTP 有效負載處理 器、編解碼器、接收器和篩選器) 的 DirectShow 篩選器圖表。 圖 2.3-8 H.323 TSP 結構

由於使用者的網路位址 (在這種情況下是使用者的 IP 位址) 非 常不穩定，在 H.323 工作階段期間不能保證維持不變，所以 H.323 電 話服務是非常複雜。TAPI H.323 TSP 使用 Windows 2000 Active Directory 服務執行使用者至 IP 的位址解析。特別的是使用

「Internet 定位器服務 (ILS) 動態目錄」(Active Directory 的即 時伺服器元件)，來儲存和不斷重新整理使用者至 IP 的映射資訊。 下列使用者分析藍本說明 H.323 TSP 中的 IP 位址解析： 1. John 希望啟動與區域網路上另一位使用者 Alice 的 H.323 會 議。當 Alice 的視訊會議應用程式建立位址物件並使它成為接聽 模式之後，Alice 的 IP 位址就由 H.323 TSP 加到 Windows 2000 Active Directory 中。這個資訊的生存時間 (TTL) 有限，會定期 透過「輕型目錄存取通訊協定 (LDAP)」來重新整理。 圖 2.3-9 Alice 登錄並重新整理其 IP 位址

2. John 的 H.323 TSP 隨後查詢 ILS 動態目錄伺服器中 Alice 的 IP 位址。特別的是 John 在 Alice 的相關目錄中查詢任何和所有 RTPerson 物件。

3. 有了 Alice 的最新 IP 位址，John 就開始呼叫 Alice 電腦的 H.323，然後兩部電腦上的同等 TSP 之間就會出現 H.323 標準的 協商和媒體選擇。一旦完成功能協商，兩個 H.323「媒體資料流提 供程式 (MSP)」都會建立適當的 DirectShow 篩選器圖表，所有媒 體資料流都送到 DirectShow 處理。然後會議就開始了。 圖 2.3-11 一旦完成功能協商，會議就開始了 TAPI 3.0 中的 IP 多點傳送會議 IP 多點傳送是 IP 的一種延伸, 可進行有效率的群組傳輸。IP 多 點傳送是應對輕型、大小可調適的會議解決方案需要而產生的，它可 以解決在帶位址的最佳資料網上作即時傳輸時的相關問題。使用 IP 多點傳送還有許多優點：調適性、容錯、強健且易於安裝。 IP 多點傳送會議模式包含下列重要功能： l 從會議加入和刪除成員時不需要全員協調。 l 要送資料到多點傳送群組時，使用者只需把資料送到多點傳送 IP 位址中的一個，而不需要瞭解群組中的其他使用者。 l 要接收資料時，使用者只須在支援多點傳送路由器的特定多點 傳送 IP 位址登錄自己感興趣的項目，而不需要瞭解群組中的 其他使用者。 l 路由器會對使用者隱藏多點傳送建置的詳細資訊。 傳統連接導向的會議會遇到許多問題： l 使用者複雜性：使用者必須知道想要交談的每個使用者的位 置，這會限制其大小的調適性和容錯功能，並增加使用者參 與和退出會議的困難。 l 浪費頻寬：當某個使用者想把資料傳播給 n 個使用者時，必 須透過 n 個連接，如下圖所示：

圖 2.3-12 網路拓樸：寄件者的檢視

如果多方會議中的所有使用者都傳送資料，所需的總頻寬會以與會 者數量的平方增加，而可能導致嚴重的調適性問題。IP 多點傳送利用 實際網路拓樸的優勢來消除相同傳輸連結上的額外資料的傳輸。

IP 多點傳送建置的是輕型、工作階段傳輸模式，這種模式給會議 使用者的負擔相當小。利用 IP 多點傳送時，使用者只需將一份資訊 副本傳送到可送達所有收件者的一個群組 IP 位址即可。IP 多點傳送 的設計會隨與會者人數的增加而調適，使用者的增加並不會增加對應 數量的頻寬。多點傳送還能大大降低傳送伺服器的負載。 藉由擴展樹形的建立，IP 多點傳送可以有效的傳送這些一對多的 資料流。在這樹型中，一個路由器到其它任何一個路由器都只有一條 路徑。只在當路徑分叉時，資料流才需要複製： 圖 2.3-14 使用擴展樹的 IP 多點傳送 如果沒有多點傳送，相同的資料就必須多次在網路上傳輸、每位收 件者傳輸一次或傳播給網路上的每個人，這會消耗不必要的頻寬和處 理。 IP 多點傳送使用 D 級 IP 位址來指定多點傳送主機群組，其範圍 自 224.0.0.0 至 239.255.255.255。永久和暫時群組位址都支援。永 久位址由「Internet 編號管理局 (IANA)」來指定，其中包含 224.0.0.1 (亦即用來賦予區域網路上所有多點傳送主機位址的全體主 機群組) 和 224.0.0.2 (賦予區域網路上所有路由器位址)。224.0.0.0 和 224.0.0.255 之間的位址範圍保留供路由及其它低等級網路傳輸 協定使用。其它位址和範圍已經保留供應用程式使用，例如 224.0.13.000 至 224.0.13.255 保留給 Net News (若需詳細資訊， 請參閱 RFC 1700 的「指定編號」，其位址是：

ftp://ftp.internic.net/rfc/rfc1700.txt) 。 IP 多點傳送的傳輸通訊協定是 RTP (即時傳輸通訊協定)，可以產 生提供時間戳記、順序編號和有效負載格式資訊的標準多媒體標題。 IP 多點傳送的應用包含視訊和語音會議、遠端交換、資料庫和 Web 站台複製、遠距教學、股票報價分發和協同計算。目前最大的 IP 多 點傳送功能示範是 Internet MBONE (多點傳送骨幹網)。 MBONE 是在實際 Internet 上分層的實驗性全域多點傳送網路。它 已經有大約五年歷史，目前負責 IETF 會議、NASA 太空梭發射、音樂、 音樂會和許多其它實況會議和演出 。 IP 多點傳送會議 TSP 主要負責使用儲存在 ILS「動態目錄會議伺 服器」上的「工作階段描述通訊協定 (SDP)」會議描述字元來解析電 腦名稱的 IP 多點傳送位址。它由「會合」會議控制來補足，說明如 下。 IP 多點傳送會議 MSP 負責為 IP 多點傳送連接 (包含 RTP、RTP 有效負載處理器、編解碼器、接收器和篩選器) 建立適當的 DirectShow 篩選器圖表。 圖 2.3-15 IP 多點傳送會議架構 TAPI 3.0 使用 IETF 標準的「工作階段描述通訊協」定在企業公

佈 IP 多點傳送會議。SDP 描述字元儲存在 Windows 2000 Active Directory 中，特別是 ILS「動態目錄會議伺服器」。稍後將詳細討論 SDP。相對於 H.323 TSP 使用的「動態目錄伺服器」，每個企業只有一 個 ILS「會議伺服器」，因為會議公告並未連續重新整理，所以只消耗 很少的頻寬。 TAPI 3.0 的 IP 多點傳送會議機制如下列分析藍本的說明，John 希望啟動多點傳送會議： 1. John 的 TAPI 3.0 應用程式使用「會合控制」(稍後將詳細討論) 在 ILS「會議伺服器」上建立 SDP 工作階段描述字元。SDP 描述字元 還包含會議名稱、開始和結束時間、會議的 IP 多點傳送位址和會 議使用的媒體類型。 圖 2.3-16 John 加入 SDP 工作階段描述字元 2. Jim 向 ILS「會議伺服器」查詢符合其規則的會議的 SDP 描述字 元： 圖 2.3-17 Jim 查詢 ILS 會議伺服器 3. Mary 和 Alice 執行類似查詢，並使用他們收到的 SDP 資訊來決定 加入 John 的會議。有了會議的多點傳送 IP 位址，她們即可加入

多點傳送主機組： 圖 2.3-18 Mary 和 Alice 加入會議 「會合控制」是一組 COM 元件，其中摘錄會議目錄概念，並提供 公佈新多點傳送會議和發現現有會議的機制。它們提供會議公告、可 編寫 Script 的介面、身份驗證、加密和存取控制功能的公用模式 (SDP)。 圖 2.3-19 使用會合控制加入會議

使用者可以透過「會合控制」加入、刪除和列舉儲存在 ILS「會議 伺服器」上的多點傳送會議。這些控制透過「輕型目錄存取通訊協定 (LDAP)」來處理會議資料。 加入會議請參閱上述圖 2.3-19 的說明。會議應用程式使用「會合 控制」來取得符合使用者規則 (1,2) 的工作階段描述字元。使用權控 制清單 (ACL) 保護每個儲存的會議公告，並視使用者的憑據來決定公 告是否可見和可存取。 一旦使用者選擇會議 (3)，使用者應用程式就會搜尋所有支援位址 類型為「多點傳送會議名稱」的位址物件。然後應用程式使用 SDP 描 述字元的會議名稱當作適當位址物件 (4) 中「建立呼叫」方法的參 數，將適當的「終端」物件傳送給傳回的「呼叫」物件，然後呼叫 Call-> Connect。 「會合控制」在 ILS「會議伺服器」上儲存會議資訊，其格式由「工 作階段描述通訊協定 (SDP)」定義，SDP 是公告多媒體會議的 IETF 標 準。SDP 的目的是公開足夠的會議資訊 (時間、媒體和位置資訊)，使 得只要使用者選擇就可以參與。SDP 最初設計為在 Internet MBONE (IP 多點傳送骨幹網) 上操作，SDP 已透過 TAPI 3.0 與 Windows 2000 Active Directory 整合，使其功能擴展到區域網路上。 SDP 描述字元公佈下列會議資訊： 圖 2.3-20 一般 SDP 屬性 工作階段描述分為三個主要部分：單一工作階段描述、0 個或多個 時間描述和 0 個或多個媒體描述。工作階段描述包含應用於整個會議 或所有媒體資料流的全域屬性。時間描述包含會議開始、停止和重複

時間資訊，媒體描述包含特定媒體資料流專用的詳細資訊。

在 MBONE 上操作的傳統 IP 多點傳送會議使用以「工作階段公告 通訊協定 (SAP)」為基礎的推送模式來公佈會議，TAPI 3.0 使用 Windows 2000 Active Directory 服務，以提取方式來公佈會議。這 種方法有很多好處，其中包括頻寬保留和簡化管理。若需詳細資訊， 請參閱 <整合 Windows 2000 Active Directory>。

TAPI 3.0 會議安全系統提出下列需求： l 控制誰可以建立、刪除和檢視會議公告。 l 防止竊聽會議。

TAPI 3.0 使用 Windows 2000 Active Directory 和 LDAP 的安全 功能提供非安全網路 (例如 Internet) 上的安全會議。Active Directory 中的每個物件都可以關聯至使用權控制清單 (ACL)，ACL 指定使用者或群組的物件使用權。藉由關聯 ACL 和 SDP 會議描述字 元，會議建立者可以指定誰可以列舉和檢視會議公告。使用者身份驗 證由 Windows 2000 安全子系統提供。 圖 2.3-21 SDP 和 ACL 「工作階段描述字元」透過 LDAP 以加密型式從 ILS「會議伺服器」 傳輸到使用者，透過 Secure Sockets Layer (SSL) 連接，可確保 SDP 不會遭到竊聽。

圖 2.3-22 SDP 分發 IP 多點傳送不提供使用者的身份驗證；任何使用者都可以匿名加 入多點傳送主機群組。為了保證會議的隱私性，TAPI 3.0 允許使用會 議描述字元分發的加密基碼將 IP 多點傳送會議加密。只有具有足夠 許可權的使用者才能存取 SDP 描述字元，繼而存取多點傳送加密基 碼。一旦經過身份驗證的使用者取得加密基碼，就可以參加會議。 圖 2.3-23 加密多點傳送資料流 服務品質 相對於傳統的資料傳輸方式，多媒體資料流 (例如 IP 電話服務或 視訊會議) 可能對頻寬和延遲極端敏感，而傳輸這些資料流的網路在 服務品質 (QoS) 就必須特別要求。不幸的是，無連接、儘量遞送模式 的 IP 並不保證依序、適時遞送封包，或根本無法保證。為了要使部

署即時應用程式的 IP 網路能有一定的品質，網路必須保證能達到特 定的頻寬、反應時間和緊湊度要求，這樣多媒體傳輸才可能與傳統資 料共存於一個網路。 頻寬：多媒體資料 (尤其是視訊) 需要遠超出傳統網路處理功能的 頻寬。例如，未經壓縮的 NTSC 視訊資料流需要每秒 220 百萬位元以 上。即使經過壓縮，只有少數多媒體資料流能完全壓過網路上的任何 其它傳輸。 反應時間：多媒體封包從來源到目標 (反應時間) 所需的時間，對 呼叫品質的感覺有很重要影響。反應時間長短影響因素有很多，包含 傳輸延遲、網路裝置中的佇列延遲和主機通訊協定堆疊中的延遲。為 了保持一定程度的互動，避免對話中的不自然停頓，必須將反應時間 減到最短。 緊湊度：相對於資料傳輸，即時多媒體封包必須依序準時到達供接 收者使用。封包到達時間的變化 (緊湊度) 必須在特定臨界值之下， 以避免遺失封包 (會導致通話中的尖聲和間距) 。緊湊度也會因為接 收緩衝區的大小而影響反應時間。 共存：相較於多媒體傳輸，資料傳輸相對較突發，會有不可預知的大 量傳輸出現 (例如，有人開啟 Web 網頁或從 FTP 站台下載檔案時)。 這種突發的集中會阻塞路由器，導致多媒體會議間斷，而網路上的每 個人對呼叫都無能為力 (包含其它 IP 電話服務使用者) 。必須保護 多媒體頻寬不受資料傳輸影響，反之亦然。 公用交換電話網路透過為每個電話分配靜態電路，以保證服務的最 低品質。這種方法易於建置，但浪費頻寬，不夠強健，而且使聲音、 視訊和資料難以整合。而且，使用無連接網路 (例如 IP) 不可能建立 電路交換資料路徑。 IP 網路上的 QoS 支援提供下列優點： l 支援即時多媒體應用程式。 l 保證及時傳送大量資料。 l 共用網路的功能，可避免應用程式缺乏頻寬。 TAPI 3.0 的服務品質透過 DirectShow RTP 篩選器來處理，該篩 選器根據特定媒體資料流相關的 DirectShow 編解碼器的需求，與網 路協商頻寬功能。這些需求由編解碼器透過自己的 QoS 介面向 RTP 篩選器提示。然後 RTP 篩選器使用 COM Winsock2 GQoS 介面以抽象 的型式向 Winsock2 QoS 服務提供程式 (QoS SP) 提示其 QoS 需要。 QoS SP 依次呼叫適於應用程式、基礎媒體和網路的各種 QoS 機制， 以保證適當的端對端 QoS。這些機制包括：

本機傳輸控制： l 封包排程 l 802.1p l 適當的第 2 層訊號傳輸機制 l 服務的 IP 類型和 DTR 標題設定 「資源保留通訊協定 (RSVP)」是 IETF 標準，設計在不同拓樸和 媒體的網路中支援資源 (例如頻寬) 保留。使用者透過 RSVP 將 QoS 請求沿資料路徑傳播至所有路由器，讓網路重新設定自己 (在所有網 路層次)，以符合想得到的服務等級。 RSVP 通訊協定透過建立貫穿網路的資料流來使用網路資源。資料 流是指關於一個或多個寄件者、一個或多個收件者和特定 QoS 的網路 路徑。希望傳送資料的傳送主機，需要特定的 QoS 透過啟用 RSVP 的 Winsock 服務提供程式，將路徑訊息傳送給預期的收件者。這些路徑 訊息描述頻寬需求和傳送資料的相關參數，它會傳播至該路徑沿途的 所有中間路由器。 對這些特定資料感興趣的接收主機，透過網路傳送說明應自寄件者 接收的資料的頻寬特性的保留訊息，來確認資料流 (和網路路徑)。這 些保留訊息將傳回給寄件者，中間路由器根據頻寬功能來決定是否接 受提議的保留及提送資源。如果做出肯定的決定，則會提送資源，保 留訊息會在路徑上自來源到目標而傳播到下一站。 「資源保留通訊協定 (RSVP)」是 IETF 標準，設計在不同拓樸和 媒體的網路中支援資源 (例如頻寬) 保留。使用者透過 RSVP 將 QoS 請求沿資料路徑傳播至所有路由器，讓網路重新設定自己 (在所有網 路層次)，以符合想得到的服務等級。 RSVP 通訊協定透過建立貫穿網路的資料流來使用網路資源。資料 流是指關於一個或多個寄件者、一個或多個收件者和特定 QoS 的網路 路徑。希望傳送資料的傳送主機，需要特定的 QoS 透過啟用 RSVP 的 Winsock 服務提供程式，將路徑訊息傳送給預期的收件者。這些路徑 訊息描述頻寬需求和傳送資料的相關參數，它會傳播至該路徑沿途的 所有中間路由器。 對這些特定資料感興趣的接收主機，透過網路傳送說明應自寄件者 接收的資料的頻寬特性的保留訊息，來確認資料流 (和網路路徑)。這 些保留訊息將傳回給寄件者，中間路由器根據頻寬功能來決定是否接 受提議的保留及提送資源。如果做出肯定的決定，則會提送資源，保 留訊息會在路徑上自來源到目標而傳播到下一站。

圖 2.3-24 用 TAPI 3.0 保留資源 封包排程這種機制可搭配 RSVP (若承載網路啟用 RSVP) 使用，或 不搭配 RSVP 使用。傳輸可識別為屬於某資料流或另一個資料流，各 資料流的封包會依照資料流的傳輸控制參數來排程。這些參數一般包 含排定的速率 (token 儲存參數) 和一些優先順序的說明。前者用於 測量封包傳輸到網路的速度。後者用來確定擁塞發生時提交封包至網 路的順序。 「801.2p」：傳輸控制也可用來決定關於各傳輸封包的 802.1 使用 者優先順序值 (用來指明相關封包優先順序的 MAC 標題欄位)。如果 在資料連結層等級提供額外的 QoS 支援，則啟用 802.1p 的切換參數 可以優先處理特定封包。

第 2 層訊號傳輸機制：回應 Winsock 2 QoS APIs 時，QoS 服務 提供程式可能呼叫其它傳輸控制機制，這取決於特定的下方資料連結 層。它可以發出下方 ATM 網路的訊號，例如，為每個流建立適當的虛 擬電路。當下方媒體為傳統式 802 共用媒體網路時，QoS 服務提供程 式可以擴展標準 RSVP 機制，以發出「子網頻寬管理員 (SBM)」的訊 號。SBM 在共用網路上提供集中的頻寬管理。 每個 IP 封包都包含表示其優先順序的三位元「優先」欄位。其它欄 位可用來表示網路的延遲、輸貫量或可靠性細項設定。本機傳輸控制 可用來在特定資料流的封包 IP 標題中設定這些位元。結果屬於資料 流的封包隨後由網路上的三個裝置進行適當的處理。這些欄位與 802.1p 優先順序設定類似，但由更高層次的網路裝置來解譯。

TAPI 3.0 和 NetMeeting

Microsoft NetMeeting 是設計用於 Internet 或 Intranet 的會 議和合作工具。NetMeeting 同時還為提供可在應用程式加入會議功能 的一套程式發展介面。它協助大小公司透過連接 IP 電話服務和會議 功能，將 Internet 或公司 Intranet 隨處可及的優勢充分用於即時 傳輸和合作。使用 Microsoft Internet Locator Server (ILS) 可以 簡化與其它 NetMeeting 使用者的連接，使與會者可以從 NetMeeting 或 Web 網頁中的動態目錄互相打電話。連接到 Internet 或公司 Intranet 時，與會者可以進行語音和視訊傳輸、在任何 Windows 應 用程式上一起工作、在電子白板上交換或標示圖形、傳送檔案或使用 文字聊天程式。 Microsoft NetMeeting 2.0 有下列功能： 符合 H.323 標準的語音和視訊會議。Internet 或公司 Intranet 上的即時、點對點語音會議，讓使用者可以打電話給世界各地的合作 人和公司。NetMeeting 語音會議提供許多功能，包含即時工作階段的 半雙工和全雙工語音支援、保證會議與會者相互聽清楚的自動麥克風 靈敏度水平設定和讓使用者控制打電話時傳送的語音訊號的麥克風靜 音功能。這個語音會議支援網路 TCP/IP 連接。 對 H.323 通訊協定的支援可讓 NetMeeting 2.0 和其它 H.323 相容的語音用戶端之間可相互操作。 H.323 通訊協定支援 ITU G.711 和 G.723 語音標準和 IETF RTP 及 RTCP 規範，以控制語音資料流而 提高聲音品質。在啟用 MMX 的電腦上，NetMeeting 使用啟用 MMX 的 聲音編解碼器來改善聲音壓縮和解壓縮演算法的效能。如此可降低 CPU 使用，提高通話時的聲音品質。 使用者可利用 NetMeeting 2.0 以任何 Windows 相容裝置與另一 個與會者傳送和接收即時視覺影像。他們可以面對面分享想法和資 訊，並使用攝影機立即檢視項目，例如使用者選擇在鏡頭前顯示的硬 體或裝置。結合 NetMeeting 2.0 的視訊和資料功能，使用者既可以 看到和聽到其他與會者，還可以共用資訊和應用程式。這個符合 H.323 標準的視訊技術還與 H.261 和 H.263 視訊編解碼相容。 使用 T.120 的多點資料會議兩個或更多使用者可以當作群組來進 行即時通訊和合作。與會者可以共用應用程式、透過共用剪貼簿交換 資訊、傳閱檔案、在共用白板上合作及使用文字聊天功能。支援 T.120 資料會議標準還可以與其它符合 T.120 的產品和服務相互操作。多點 資料會議包含下列功能：

應用程式共用：使用者可以與其他與會者共同在一部電腦上執行的 程式。與會者可以檢視相同的資料或資訊，看到共用應用程式的人在 程式上工作時的操作 (例如編輯目錄或捲動資訊)。與會者可以透明地 共用 Windows 應用程式，而毋需任何有關應用程式功能的特殊知識。 共用應用程式的人可以選擇與其他與會者合作，輪流編輯或控制應 用程式。只有共用程式的人需要在他們的電腦上安裝指定的應用程式。 共用剪貼簿：共用剪貼簿可讓使用者使用熟悉的剪下、複製和貼上 操作，與其他與會者交換剪貼簿內容 。例如，與會者能夠從本機文件 複製資訊，並將它當作群組合作的一部份來貼入共用應用程式中。 檔案傳送：使用者可利用檔案傳送功能在背景將檔案傳送給一個或 所有與會者。如果使用者將檔案拖入主視窗，檔案會自動傳送給會議 中的每個人，他們可以接受或拒絕接受。這個檔案傳送功能與 T.127 標準完全相容。 白板：多個使用者可以同時合作使用白板檢查、建立和更新圖形資 訊。白板為物件導向 (相對於圖素導向)，與會者可以用滑鼠點按和拖 曳來處理內容。此外，與會者還可以使用遠端指標或反白工具指出共 用頁面的特定內容或區段。 聊天：使用者可以鍵入文字訊息與其它與會者分享想法或話題，或 記錄會議附註或動作項目作為合作程式的一部份。在沒有語音支援 時，與會者也可使用聊天來進行通訊。悄悄話功能讓使用者可以在群 組聊天工作階段中，與另一個人進行單獨的、私密的對話。 NetMeeting 2.0 軟體發展工具包這個 SDK 讓開發人員能夠將這 個會議功能與他們的應用程式或 Web 網頁直接整合。這種開放式的開 發環境支援國際傳輸和會議標準，讓來自多個供應商的產品和服務可 相互操作。 NetMeeting SDK 中還具有加入非標準編解碼器和透過 LDAP 存取 ILS 伺服器的 API，以及簡化新增 Web 網頁的會議功能的 ActiveX™ 控制。 TAPI 3.0 和 NetMeeting 2.0 都支援核心 IP 電話服務功能。每 個平台都提供獨特的優勢：TAPI 3.0 可以無縫地整合傳統電話服務和 IP 電話服務，提供以 COM 為基礎而獨立於傳輸通訊協定的呼叫控制 和資料流基礎結構。除了 IP 電話服務之外，NetMeeting 2.0 SDK 還 支援 T.120 會議和應用程式共用。使用 TAPI 3.0 和 NetMeeting 2.0 API 的應用程式，以 H.323 語音和視訊會議進行相互操作。

圖 2.3-30 TAPI 3.0 和 NetMeeting 2.0 相互操作 由於 TAPI 3.0 和 NetMeeting 2.0 都支援核心 IP 電話服務功能 (包含支援 H.323)，因此開發人員在選擇 API 作為他們 IP 電話服務 的應用程式時，可能要考慮下列指導方針： TAPI 3.0.如果在應用程式中使用 IP 電話服務，這就是該用的 API。TAPI 3.0 在用戶端/伺服器電腦電話服務的整合環境中特別有價 值，因為連接 IP 電話服務和傳統電話服務，以及聲音和視訊的 IP 多 點傳送功能。 NetMeeting 2.0 API.如果正在進行即時合作，並想要將聲音、視訊和 資料會議整合到應用程式中，這就是該用的 API。NetMeeting API 對 要整合應用程式共用、白板功能和多點檔案傳送與聲音和視訊工作階 段的應用程式非常有用。 2.3.1 TAPI 的特色： TAPI 3.0 是集合傳統式 PSTN 電話服務和 IP 電話服務的漸進式 API。IP 電話服務能夠在現有的區域網路、廣域網路 和 Internet 上 融合聲音、資料和視訊。TAPI 3.0 支援標準的 H.323 會議和 IP 多 點傳送會議。IP 電話服務可讓公司和個人降低現有服務成本 (例如聲 音和廣播電視)，同時增加傳輸方法，以納入現代視訊會議、應用程式 共用和白板工具。 TAPI 3.0 提供了簡單而普通的方法，能夠結合兩部或多部電腦， 並存取這種結合所涵蓋的任何媒體資料流。它摘錄了呼叫控制功能， 讓不同而看似不相容的傳輸通訊協定提供應用程式使用的公用介面。 當公司開始從昂貴而缺乏彈性的電路交換公用電話網路轉移至有智 慧、彈性而且便宜的 IP 網路時，IP 電話服務將可節省公司廣大的開 銷。 2.3.2 選擇 TAPI 的原因：

隨著網際網路的蓬勃發展，網際通訊服務成為大家致力追求的目 標。因 TAPI 提供電話整合的服務，且簡化了 H.323 通訊協定所必須經 歷的繁複過程，它可以降低現有服務成本，用以代替傳統電話所需要 昂貴花費。也方便住在外面沒有自己的室內電話的學生，可以利用 TAPI 來進行通話。 2.4 H.323 的探討 2.4. 1 H.323 概述 H.323 基本上就是一個標準，它定義了在分封交換網路上，終端機 之間的壓縮解壓縮標、通話的程序以及媒體傳輸等協定，使得不同廠 商所開發的終端機也能彼此交語音、視訊以及資料。 由於網路的快速興起，每個人都能坐在電腦前面就能存取世界各地 的資料。然而，人們追求進孫的慾望是無止境的，除了能利用網路來 存取資料外，還希望能透過網路來傳遞語音及影像，在 1995 年以色列 的 vocaltec 公司開發出網路電話之後，這個夢想便實現了。 雖然網路電話能讓雙方透過網路電話來達到談話的目地，可是這必 須在一個前提之下，那就是他們都必須要相的公司所開發出的軟體， 為了解決這個問題，就必須要制定一套統一的標準，然而根據這一個 標準所作出的網路電話，即使是不同的軟體公司所作出來的網路電 話，也能彼此互相連接通話。而這套標準就是由國際電信聯盟(ITU)所 制定的 H.323。 H.323 除了規範了網路上即時性的語音傳遞，同時也對網路上視訊 的傳遞也制定了一套標準。如此一來，我們便能發展出功能強大的網 路視訊電話，甚至是多方視訊通話來組成一個網際網路的會議。透過 H.323 除了能連接網路上的電話之外，還可以連接傳統的一般電話。 2.4.2 H.323 架構 一個 H.323 的架構裡可能包含了終端機(Terminal)、閘道 (Gateway)、閘道管理者(Gatekeeper)以及多方會談控制單元(MCU) 等……這些主要的元件。H.323 描述出這些元件是如何彼此溝通連接及 其訊息傳遞順序，圖 2.4-1 是整個 H.323 的架構圖以及 H.323 規範中 的其他外界元件。以下我們將簡單的介紹 H.323 主要的元件。 2.4.2.1 終端機

終端機主要的功能就是能讓使用者在網路上傳遞即時性的語音、 影像和非即時性的資料(如傳訊 message 及檔案)，就如同在電腦上安 裝網際網路電話的軟體(如 Netmeeting)，因此，終端機是由軟體和硬 體共同組合而成的，其架構圖如圖 2.4-2。終端機至少要有 G.711 語音 壓縮和解壓縮的能力，H.261 視訊壓縮和解壓縮的能力，然而 T.120 資料傳輸協定則是選配裝置。為了讓終端機在彼此之間能有標準的溝 通模式，終端機必須支援 ITU 所訂定的 H.245 控制協定、Q.931 通話建 立協定以及 RAS 協定。

2.4.2.2 閘道 閘道是 H.323 要與外界溝通的橋梁，由於不同系統內的溝通方式 與訊息傳遞的模式大都不相同。因此，當 H.323 的內部元件想和其他 不同系統做溝通的時候就必須透過閘道。它負責轉換兩種不網路(例 如：封包交換網路和線路交換網路)之間傳輸格式，以及溝通上程序上 的差異；也有可能負責語音和視訊壓縮、解壓縮的轉換。 2.4.2.3 閘道管理者 閘道管理者由字面的意思來看，就可以看出它其中的一項功能， 那就是管理 Gateway。除了管理閘道外，它還可管理終端機和多方會談 控制單元。閘道管理者包含了兩項主要的動作：位址的轉換和頻寬的 管理。位址的轉換就好像查號台一樣，由於 H.323 的元件在上線之後， 第一個的動作就是向閘道管理者提出註冊，這個時候 H.323 元件就必 須告知閘道管理者自已的 IP 和識別名稱。因此，當遠端有人要呼叫自 已的時候，便可透過閘道管理者利用自已的網路識別稱來查詢自已的 IP Address，再進行連線。頻寬的管理則是在說：當有人提出連線要

求的時候，必須先向閘道管理者提出頻寬要求，這時候閘道管理者就 可視當時的網路流量而定，是否讓請求通過。 2.4.2.4 多方會談控制元件 多方會談控制元件是指當有三台以上的終端機要進行同時的彼此 談話交流，這個時候就必須要有一個中心元件來作協調溝通，而這個 中心元件也就被稱為多方會談控制元件。其最主要做得事情就是居中 做為其他元件協調中心。比如說：在會談開始前就必須決定每一個多 方會談元件要用的壓縮和解壓縮格式；也必須決定會談中的語音、視 訊和資料是單點傳輸還是多點傳輸。 2.4.3 H.323 的相關協定 在前面已經大略的提出 H.323 相關協定，包含了 RAS 協定、Q.931 通話建立協定、H.245 控制協定以及媒體傳輸協定。 2.4.3.1 RAS 協定 RAS 協定主要是制定 H.323 各種元件和閘道管理者的溝通機制。因 此，只有閘道管理者存在的時候才需要這個協定。這個協定包含了三 大功能及其所需訊息： R：註冊(Registration)，當有 H.323 元件啟動時，必須向閘道管理者 提出註冊，就是要告知閘道管理者此 H.323 元件的 IP 和網路識別。 ~註冊時的訊息~ RRQ：要求註冊 RCF：同意註冊 RRJ：拒絕註冊 URQ：要求取消註冊 UCF：同意取消註冊 URJ：拒絕取消註冊 A：加入(Admission)，當 H.323 元件想要和其它 H.323 元件建立通話 的時候，必須先向閘道管理者提出所需頻寬及對方的網路識別。此時 閘道管理者可視情看來准許或否決其要求，這一連串的過程就叫加入。 ~加入的訊息~ ARQ：要求加入 ACF：同意加入 ARJ：拒絕加入

S：狀態查詢(Status)，閘道管理者可以查詢 H.323 元件是否正常運作 和狀態，這種動作就叫查詢。 ~狀態的查詢~ IRQ：查詢狀態 IRR：回報狀態 我們可利用圖 2.4-3 及圖 2.4-4 來了解 RAS 的各種訊息用於何處。

2.4.3.2 Q.931 通話建立協定 Q.931 通話建立協定其目地最主要的就是在於建立 H.323 元件相 互之間的通話管道，其主要的訊息如下： Setup：要求建立通話管道 Call Proceeding：通話管道建立中 Alerting：振鈴中 Connect：通話管道建立成功 Release Complete：中斷通話管道 Q.931 的訊息傳遞方式有兩種，第一種是兩個 H.323 元件直接互相 傳遞(Direct Call Signaling)，如圖 2.4-3。第二種是透過閘道管理 者 來 進 行 間 接 傳 遞 (Gatekeeper Routed Call Signaling) ， 如 圖 2.4-4。由這兩個圖我們可以比較容易去了解 RAS 協定和 Q.931 通話控 制協定是用於何處。 2.2.3.3 H.245 控制協定 H.245 控制協定包含三個主要的功能： 1、交換能力資訊：由於每一個 H.323 元件，都有包含有很多種壓縮和 解壓縮的能力，因此在實際傳訊語音、視訊和資料之前，必須先溝通 好兩個 H.323 元件之間的傳輸格式，才能進行傳輸。

2、決定主從關侏：由於多方會談只能由一個多點控制單元來進協調， 假如雙方人馬各有一個多方會談控制單元時，就必須決定要遵從哪一 個多方會談控制單元。 3、開關邏輯管道：通話雙方若要傳輸語音、視訊或資料時，必須打開 邏輯管道以及媒體管道。一般來說邏輯管道都會伴隨著一個媒體管 道，而且邏輯管道都是單向的，因此要進行雙向傳輸就必須打開兩條 邏輯管道。 圖 2.4-6 是當兩個 H.323 元件要進行資料間的相互傳輸時，所用各個 通訊定及其順序：

第三章 系統分析與設計 3.1 系統需求 3.2 系統架構圖

3.2.1 錄音

3.2.2 聊天室

3.2.3 傳檔

3.2.4 收檔

3.2.5 電話功能

3.1 系統需求

作業系統：Win2000、XP

硬體設備：個人電腦、麥克風、喇叭。

start Winsock 是否處 於 connected 狀 起始 winsock 動作 設定即將被傳送的 檔案總位元組數量 設定 Bffer 陣列元 素總量 maxbyte 以 srcFile 變數內容 為檔案名稱的讀取 管道 通知伺服器準備 用戶端準備傳檔 將要傳送的檔名送 給伺服器，並要求 伺服器允許進行檔 案傳送 是否按取消 否 是 否 是 end

nloop+maxby te+1<LnFile 否 是 nloop=LnFile-nlo op+1 每次讀取 1024 個 位元組 重新定義 Buffer 元素大小為 nloop 每次讀取 1024 個 位元組 通知伺服器在檔案 傳輸管道之數據資 料即為檔案內容 伺服器回 傳”Ready” WAIT 否 是 將已讀取的檔案 內容傳出去 通知伺服器在檔案 傳輸管道之數據資 料即為檔案內容 伺服器回 傳”Ready” 否 WAIT 是 將已讀取的檔案內容傳 出去並且 nloop=nloop+maxbyte+

判斷是否屬於 使用者取消 否 是 送”SendComplete ”通知伺服器，同 時不允許按取消鍵 送” Cancel“給 伺服器且更新相關 變數內容 關閉傳輸 管道 end

3.2.3 傳檔

Start Form_load ( ) 設定所有按鍵起始狀 態 宣告 TAPI 物件 初始化 TAPI 物件 設定 TAPI 物件中的 EventFilter 參數 設定 gobjTapiWithEvents 物件 設定本機與遠端主機的 port number 及狀態 End

start btnInitial_dial( ) 設定 objCollAddresses(位址 集合)物件為 TAPI 物件中可 用的位址 呼叫 SupportH.323 函式 來找出可用位址 檢查是否找到可 用位址 顯示無可用位址訊息 利用可用的 Address 物件產生終 端機支援(objTerSupport)物件， 並由此物件產生在本機上抓 取、產生媒體資料流的預設 terminal。 Release objTerSupport 物件 檢查 gobjReceived- CallInfo 是否為 Nothing 是 否

顯示"Don't do this in the middle of a call"訊息

否

檢查 glRegistration-Token≠0 設定 fOwnerd、fMonitor、 lMediaTypes、 lCallbackInstance 等參數。 呼叫 TAPI 物件中的 RegistrationCall-Notifications，並將其值傳給 glRegist-rationToken.。 呼叫 TAPI 的 UnregistrationNotific- ations，並將 glRestration 值設為 0 註冊成功 End 是 否

btnDial_Click( ) start 檢查 gobjCall 物件 是否為 Nothing 顯示"Can't connect new call."訊息 抓取使用者輸入的 IP 位址 輸入的 IP 位址 ＝NOTHING 顯示"Enter destination address"訊息 是 是 否 否 設定位址型態、媒體資料流 型態 利用 Address 物件中的 CreatCall 來產生呼叫，並建立連線 End

Start btnAnswer_Click( ) 檢查 objReceived- CallInfo 是否為 Nothing 檢查 Call State 是否 為 CS_OFFERING 設定 objCallControl 物 件 Set objStreamCtrl= gobjReceivedCallInfo SelectTer gobjReceiv- edCallInfo Realease objCallCo- ntrol 物件 End

顯示"A call can't con- nect without offering state"訊息 將 objStreamCtrl 設為 Nothing 是 是 否 否 呼叫 objCallControl. Answer 來建立連線

btnDisconnect_Click( ) start 檢查 gobjCall 物件是否為 nothing 檢查 gobjReceivedCallInfo 物件是否為 nothing 使用 gobjCall 物件的 Disconnect 正常斷線 宣告 ITBasicCallControl2 物件，指 定給 gobjReceivedCallInfo 物件，再 正常斷線。 顯示”There is no call to be disconnected” 訊息。 End