TAPI與TSP

2.2 COM的介紹

2.2.1 COM的基本認知 2.2.2 COM的運作方式 2.2.3 COM介面

2.2.4 COM基礎介面的介紹 2.3 與TAPI相容的語音MODEM

第二章 相關技術簡介 前言

TAPI 3.0 是集合傳統式PSTN 電話服務和IP 電話服務的漸進式 應用程式介面(API)。IP 電話服務可讓公司和個人降低現有服務成 本(例如聲音和廣播電視)，同時增加傳輸方法，以納入現代視訊會 議、應用程式共用和白板工具。

過去，公司部署個別的網路來處理傳統的聲音、資料和視訊傳輸。

每個網路都有不同的傳輸要求，安裝、維護和重新組態這些網路的花 費很大。而且，由於這些網路在實體上截然不同，即便可能，整合也 很困難，以致限制其潛在的用途。

IP 電話服務藉由指定每個聲音、視訊和資料的公用傳輸、IP，將這三種 網路混合成一個。結果使網路更易於管理，降低支援費用，形成新型合作工具 並提高了生產力。

IP 電話服務的可能應用包括遠端交換、即時文件合作、遠距教學、人員 訓練、視訊會議、視訊郵件和可視需要取得的視訊。

TAPI 的歷史演進及搭配的作業系統可由圖2-1所示。由表中可 以看出TAPI 的發展可區為兩個階段，區分點介於TAPI 2.1 版及TAPI

3.0 版之間。主要的差別在從TAPI 3.0 版後開始提供網際網路電信服務。

表 2.0-1 TAPI 版本的演進 2.1 TAPI的介紹

2.1.1 TAPI與TSP

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

圖 2.1.1-1 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 伺服程式便會做妥善的 管理相對應裝置的使用權限及使用狀況。

資料也必須以標準方式供應用程式使用。TAPI 3.0 提供了簡單而普通的方 法，能夠結合兩部或多部電腦，並存取這種結合所涵蓋的任何媒體資料流。它 摘錄了呼叫控制功能，讓不同而看似不相容的傳輸通訊協定提供應用程式使用 的公用介面。

當公司開始從昂貴而缺乏彈性的電路交換公用電話網路轉移至有智慧、彈 性而且便宜的IP 網路時，IP 電話服務能夠自若地面對爆炸性的成長。

Microsoft 預料到這個趨勢，所以建立了強健的電腦電話服務基礎結構TAPI。

目前TAPI 的第三個主要版本，適合快速、簡單地部署IP 電話服務應用程式。

見下圖

圖 2.1.2-1 TAPI 與傳統電話服務的架構圖

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

式，例如C/C++ 或MicrosoftR Visual BasicR 。

除了支援傳統的電話服務提供程式，TAPI 3.0 還支援標準H.323

會議和IP 多點傳送會議。TAPI 3.0 使用WindowsR 2000 Active Directory 服 務來簡化公司內的部署，支援服務品質(QoS) 功能，提

高會議品質，使網路易於管理。

圖 2.1.2-2 TAPI 的架構圖

TAPI 3.0 有四個主要元件：

TAPI 3.0 COM API TAPI 伺服器

電話服務提供程式

TAPI 3.0 提供TAPI 2.1TSP 回溯相容性。兩個IP 電話服務提供程式(及其相 關的MSP)在

出廠時就提供TAPI 3.0：H.323 TSP 和IP 多點傳送會議TSP 將在後 面討論。

TAPI 3.0 提供統一的方式從呼叫中的存取媒體資料流，此方式支援 DirectShowTM API 作為主要的媒體資料流處理程式。TAPI「媒體資料流提供 程式(MSP)」為特殊的TSP 的建置了DirectShow 介面，

而任何利用DirectShow 資料流的電話服務都需要這個介面。一般的 資料流由應用程式處理。

圖 2.1.2-3 TAPI 的物件關係

TAPI 3.0 API 中包含五個物件：

圖 2.1.2-4 呼叫與呼叫中心位址關係圖

2.1.3 TAPI 的運作

發出呼叫

1. 建立和啟動TAPI 物件。

2. 使用TAPI 物件列舉電腦上所有可用的「位址」物件(例如網路卡、資 料機和ISDN 線路)。

3. 列舉各「位址」物件所支援的位址類型(例如電話號碼、IP 位 址等等)。

4. 根據適當媒體(語音、視訊等) 和位址類型的支援查詢來選擇

「位址」物件。

5. 使用「位址」物件的建立呼叫方法來建立與特定位址相關的「呼叫」

物件。

6. 在「呼叫」物件上選擇適當的終端機。

7. 呼叫「呼叫」物件的結合方法以找到呼叫。

應答呼叫

1. 建立並啟動TAPI 物件。

2. 使用TAPI 物件列舉電腦上所有可用的「位址」物件(例如網

路卡、資料機和ISDN 線路) 。

6. 以「位址」物件登錄呼叫事件處理程式(亦即建置ITCallNotification 介面)。

7. TAPI 透過ITCallNotification 通知應用程式有新的呼叫，然後建立

「呼叫」物件。

8. 在「呼叫」物件上選擇適當的終端機。

9. 呼叫「呼叫」物件的結合方法以找出呼叫。

10. 呼叫「呼叫」物件的結合方法以應答呼叫。

為了有效控制和操作媒體資料流，Windows R 作業系統提供可擴展的構 架，稱為DirectShow。DirectShow 透過公開的COM 介面提供

TAPI 3.0 統一的資料流控制。

COM 物件通常暴露於使用者模式的程式下，DirectShow 資料流結構包含 Windows 驅動程式模式的擴展，這個模式可在裝置驅動程式層直接結合媒體資 料流。下圖顯示簡單的PSTN 至IP 橋接器。來自ISDN 線路的64 Kbps 聲音資 料流壓縮成G.723 語音資料流，然後送到RTP 負載處理程式，再傳送到網路上。

圖 2.1.3-1使用者和核心模式元件的DirectShow 篩選器圖表範例

使用者複雜性：使用者必須知道想要交談的每個使用者的位 置，這會限制其大小的調適性和容錯功能，並增加使用者參 與和退出會議的困難。

浪費頻寬：當某個使用者想把資料傳播給n 個使用者時，必 須透過n 個連接，如下圖所示：

圖 2.1.4-1 網路拓樸(以傳送者的視點

)

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

圖 2.1.4-2 實際的網路拓樸

IP 多點傳送建置的是輕型、工作階段傳輸模式，這種模式給會議使用者 的負擔相當小。利用IP 多點傳送時，使用者只需將一份資訊副本傳送到可送 達所有收件者的一個群組IP 位址即可。IP 多點傳送的設計會隨與會者人數的 增加而調適，使用者的增加並不會增加對應數量的頻寬。多點傳送還能大大降 低傳送伺服器的負載。藉由擴展樹形的建立，IP 多點傳送可以有效的傳送這 些一對多的資料流。在這樹型中，一個路由器到其它任何一個路由器都只有一 條路徑。只在當路徑分叉時，資料流才需要複製：

圖 2.1.4-3 使用擴展樹來實行多點傳播

如果沒有多點傳送，相同的資料就必須多次在網路上傳輸、每位收件者傳 輸一次或傳播給網路上的每個人，這會消耗不必要的頻寬和處理。

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 的「指定編號」，其位址是：

大約五年歷史，目前負責IETF 會議、NASA 太空梭發射、音樂、音樂會和許多 其它實況會議和演出。

IP 多點傳送會議TSP 主要負責使用儲存在ILS「動態目錄會議伺 服器」上的「工作階段描述通訊協定(SDP)」會議描述字元來解析電 腦名稱的IP 多點傳送位址。它由「會合」會議控制來補足，說明如 下。IP 多點傳送會議MSP 負責為IP 多點傳送連接(包含RTP、RTP 有效負載處理器、編解碼器、接收器和篩選器) 建立適當的

DirectShow 篩選器圖表。

圖 2.1.4-4 IP 多點傳送的會議架構

2.1.5 H.323

H.323 是一種複雜的國際電信聯盟(ITU) 標準，適用於服務品質無法 保證的無連接網路的多媒體傳輸(聲音、視訊和資料)，例如IP 網路

和Internet 等。它提供點對點和多點會議的呼叫控制、多媒體管理 和頻寬管理。H.323 指令支援標準語音和視訊碼，支援透過T.120 的 資料共享。而且，H.323 標準獨立於網路、作業平台和應用程式，使 任何H.323 相容的終端機與其它任何終端機進行相互操作。

H.323 可以在現行封包交換網路上傳送多媒體資料流。為了減小區

個指令和控制通訊協定：

個指令和控制通訊協定：