交握

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

使用者命令: 透過使用者介面或視窗訊息,應用程式會瞭解本機使用者想要變更媒體類型。 例如,使用者已告知新的目標應用程式 (尚未成為擁有者) ,以取得傳輸資料的現有語音通話。 目標應用程式現在必須控制呼叫。 在此情況下,目前的擁有者會注意到擁有者數目增加,然後放棄其對呼叫的控制。 或者,使用者可以指示呼叫的目前擁有者將其交給可處理新媒體類型的應用程式。

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

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

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

  • 呼叫會提供給另一個應用程式, (SUCCESS) 。
  • 交出應用程式本身是 TARGETSELF (目標) 。
  • 轉送失敗 (TARGETNOTFOUND) 。

如果接收交接呼叫的應用程式已經有呼叫的呼叫控制碼,則會使用這個舊的呼叫控制碼。 否則,會建立新的呼叫控制碼。 在這兩種情況下,應用程式最後會有呼叫的擁有者許可權。 每當交接應用程式與目標應用程式不同時,就會通知目標在會話狀態訊息中的交接,就像收到新的呼叫一樣。

如果目前的擁有者應用程式被告知變更媒體類型,它會藉由將呼叫交給用於目標媒體類型的應用程式來執行此動作。 有兩種類型的通話交接說明于 「導向 的交接」和 「媒體」類型「交接」中。

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

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

TAPI 3.x: 請參閱 ITBasicCallControl::HandoffDirectITBasicCallControl::HandoffIndirect

導向遞交

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

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

媒體類型交接

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

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

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

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

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

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

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

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