交接

當應用程式擁有者 通訊會話的許可權 時，應用程式可以選擇將擁有權移交給另一個應用程式。 交接作業通常用來允許變更呼叫的媒體類型。 新媒體類型的最高優先順序應用程式應該接受並處理呼叫。 媒體類型變更通常會因為下列其中一個原因而發生。

User 命令： 透過使用者介面或視窗訊息，應用程式會瞭解本機使用者想要變更媒體類型。 例如，使用者已告訴新的目標應用程式（尚不是擁有者），以取得傳輸數據的現有語音通話。 目標應用程式現在必須控制呼叫。 在此情況下，目前的擁有者注意到擁有者人數增加，然後放棄對通話的控制。 或者，使用者可以指示呼叫的目前擁有者將它交給可以處理新媒體類型的應用程式。

媒體類型變更： 服務提供者可以偵測媒體類型變更。 例如，本機應用程式正在對來電者播放錄製的語音訊息。 在此訊息中，來電者自發決定傳輸傳真通話音，而本機應用程式可以藉由將媒體類型變更為傳真來回應，並在必要時將電話交給傳真應用程式。 另一種運作方式是監視應用程式啟用媒體類型監視，而且，當呼叫上偵測到它感興趣的媒體類型時，它可以要求呼叫的擁有權。 此機制讓每個應用程式都不需要監視每個媒體類型的每個呼叫。

遠端合作物件命令： 遠端合作物件可以在現有呼叫期間以互動方式指出媒體類型變更，例如本機應用程式是否監視遠端呼叫端的 DTMF 輸入。 透過這項監視，呼叫端會指出即將傳送傳真。 呼叫端可以控制本機應用程式的其他方式，是透過ISDN使用者資訊訊息接收其他資料連線上的命令。

通話交接將會有下列其中一個結果：

• 呼叫會提供給另一個應用程式（SUCCESS）。
• 交接應用程式本身是目標 （TARGETSELF）。
• 交接失敗（TARGETNOTFOUND）。

如果接收交接呼叫的應用程式已經有呼叫的呼叫句柄，則會使用這個舊的呼叫句柄。 否則，會建立新的呼叫句柄。 不論是哪一種情況，應用程式最後都具有呼叫的擁有者許可權。 每當交接應用程式與目標應用程式不同時，就會通知目標在會話狀態訊息中的交接情況，就好像收到新呼叫一樣。

如果目前的擁有者應用程式被告知要變更媒體類型，則會藉由將呼叫交給目標媒體類型所使用的應用程式來這麼做。 這兩種類型的通話交接說明於 導向接接 和 媒體類型「交接」。

並非所有服務提供者都支援使用此作業。

TAPI 2.x： 請參閱 lineHandoff，其中 lpszFileName 設定為直接交接的應用程式名稱，或將 dwMediaMode dwMediaMode 設為一種間接交接的媒體類型。

TAPI 3.x： 請參閱 ITBasicCallControl：：HandoffDirect，ITBasicCallControl：：HandoffIndirect。

導向交接

當目標應用程式的名稱已知原始應用程式時，就會發生 導向交接。 例如，這種情況會發生在同一個廠商所撰寫的一組應用程式之間。 使用者通常可以設定導向交接的控制。 使用這類交接時，如果已開啟呼叫所在的行，則會將呼叫提供給指定的應用程式。 應用程式開啟行時指定的媒體類型會被忽略。 其中一個常見範例是語音通話，後面接著相同通話中的傳真傳輸。 導向交接最常由來自相同開發人員的應用程式使用，這些開發人員也會以其他方式連結。

未來版本也可能會使用導向交接，作為仲裁多個應用程式等待相同媒體類型的來電程式的一部分，並選取應用程式來處理以數據連結或更高層級通訊協定偵測為基礎的呼叫，而不是媒體類型。 其使用範例是一條內送數據數據數據機線路，其中包含遠端接管、布告欄、遠端網路存取和遠端電子郵件存取等應用程式，同時等候通話。

媒體類型交接

當有新的目標媒體類型時，媒體類型交接，通常是當擁有的應用程式判斷呼叫所需的媒體類型不存在或即將變更時。

如果媒體類型 UNKNOWN 位開啟，則媒體相依交接的程式可以是探查程式。 擁有應用程式負責循環處理媒體類型，以尋找最高優先順序的應用程式。 TAPI 只會在初始來電中執行這項迴圈，以尋找第一個擁有者。 它不會進行交接作業。 否則，交接幾乎與對應用程式呼叫的初始指派相同。 差異在於，只能針對間接（媒體類型）交接設定一個媒體類型。

因為只能指定單一媒體類型位，因此會針對該媒體類型，將呼叫指定給最高優先順序的應用程式。 不過，可以考慮多個媒體類型來進行交接。 在此情況下，交接應用程式應將可能媒體類型的最高優先順序指定為參數。

如果應用程式在執行媒體類型交接時指定 UNKNOWN 位，且交接失敗，這表示無法執行媒體類型判斷的未知應用程式目前並未執行。 接著，正在遞交的應用程式應該嘗試將呼叫交給針對下一個較高媒體類型註冊的最高優先順序應用程式。

接收應用程式現在負責呼叫。 它現在會探查呼叫的實際媒體類型。 如果應用程式可以處理呼叫的媒體類型，它必須確定它是針對該媒體類型註冊的最高優先順序應用程式。 如果是，它會保留呼叫，並正常處理它。 如果沒有，它會將呼叫交給為該媒體類型註冊的另一個應用程式。

不過，如果該媒體類型的探查失敗，應用程式會再次探查，嘗試剩餘的媒體模式可能性。 它必須先關閉目前的媒體類型位，然後再嘗試另一個不同類型的交接。

此探查和移交程式會繼續進行，其餘媒體類型會逐一消除。 一路上，其中一個應用程式可能會看到它處理的媒體類型是在呼叫上，而且交接成功。

然後，應用程式應該設定正確的媒體類型，並清除所有其他媒體類型位。 這會通知其他感興趣的應用程式正確的媒體類型。 這些其他應用程式會收到事件通知訊息，指出呼叫的媒體類型已變更。