ハンドオフ
アプリケーションが通信セッションに対する所有者 特権 を持っている場合、アプリケーションは所有権を別のアプリケーションに譲渡することを選択できます。 ハンドオフ操作は通常、呼び出しのメディアの種類を変更するために使用されます。 新しいメディアタイプの最も優先度の高いアプリケーションは、呼び出しを受け取って処理する必要があります。 メディアの種類の変更は、通常、次のいずれかの理由で発生します。
ユーザー コマンド: アプリケーションは、ユーザー インターフェイスまたはウィンドウ メッセージを通じて、ローカル ユーザーがメディアの種類を変更することを学習します。 たとえば、ユーザーは新しいターゲット アプリケーション (まだ所有者ではありません) に、データを送信するための既存の音声呼び出しを取得するように伝えます。 これで、ターゲット アプリケーションが呼び出しを制御する必要があります。 この場合、現在の所有者は所有者の数の増加に気付き、呼び出しの制御を放棄します。 または、ユーザーは、呼び出しの現在の所有者に、新しいメディアの種類を処理できるアプリケーションに渡すように指示することもできます。
メディアの種類の変更: サービス プロバイダーは、メディアの種類の変更を検出できます。 たとえば、ローカル アプリケーションは、発信者に録音された音声メッセージを再生しています。 このメッセージの間、発信者は自発的に FAX 通話音を送信することを決定し、ローカル アプリケーションはメディアの種類を FAX に変更し、必要に応じて通話を FAX アプリケーションに渡すことで、それに応じて応答できます。 もう 1 つの方法は、監視アプリケーションがメディアの種類の監視を有効にし、関心のあるメディアの種類が呼び出しで検出されると、呼び出しの所有権を要求できることです。 このメカニズムにより、すべてのアプリケーションがメディアの種類ごとにすべての呼び出しを監視する必要が生じありません。
リモート パーティ コマンド: リモート パーティは、ローカル アプリケーションがリモート呼び出し元による DTMF 入力を監視している場合など、既存の呼び出し中にメディアの種類の変更を対話形式で示すことができます。 この監視を通じて、発信者は FAX が送信されようとしていることを示します。 呼び出し元がローカル アプリケーションを制御できるその他の方法は、他のデータ接続および ISDN ユーザー情報メッセージを介して受信したコマンドを使用する方法です。
通話のハンドオフには、次のいずれかの結果があります。
- 呼び出しは、別のアプリケーション (SUCCESS) に渡されます。
- ハンドオフ アプリケーション自体がターゲット (TARGETSELF) です。
- ハンドオフが失敗する (TARGETNOTFOUND)。
ハンドオフ呼び出しを受信しているアプリケーションに呼び出しの呼び出しハンドルが既にある場合は、この古い呼び出しハンドルが使用されます。 それ以外の場合は、新しい呼び出しハンドルが作成されます。 どちらの場合も、アプリケーションは呼び出しに対する所有者特権で終了します。 ハンドオフ アプリケーションがターゲット アプリケーションと同じでない場合は常に、新しい呼び出しを受信したかのように、セッション状態メッセージのハンドオフについてターゲットに通知されます。
現在の所有者アプリケーションがメディアの種類を変更するように言われた場合は、ターゲット メディアの種類に使用されるアプリケーションの呼び出しを渡すことによって行われます。 2 種類のコール ハンドオフについては、「 ダイレクト ハンドオフ 」と「 メディアタイプハンドオフ」を参照してください。
すべてのサービス プロバイダーがこの操作の使用をサポートしているわけではありません。
TAPI 2.x:直接ハンドオフの場合は lpszFileName をアプリケーション名に設定し、間接ハンドオフの場合は dwMediaMode を 1 つのメディアタイプに設定した lineHandoff を参照してください。
TAPI 3.x:ITBasicCallControl::HandoffDirect、ITBasicCallControl::HandoffIndirect を参照してください。
ダイレクト ハンドオフ
ダイレクト ハンドオフは、ターゲット アプリケーションが元のアプリケーションに名前で認識されたときに行われます。 この状況は、たとえば、同じベンダーによって作成された一連のアプリケーションの中で発生します。 ユーザーは通常、ダイレクト ハンドオフの制御を構成できます。 このようなハンドオフでは、呼び出しが存在する行を開いた場合、指定されたアプリケーションに呼び出しが渡されます。 アプリケーションが行を開いた時点で指定されたメディア・タイプは無視されます。 一般的な例の 1 つは、音声通話の後に同じ通話で FAX 送信が続く場合です。 ダイレクト ハンドオフは、他の方法でもリンクされているのと同じ開発者のアプリケーションで最も頻繁に使用されます。
ダイレクト ハンドオフは、同じメディアタイプの着信呼び出しを待機する複数のアプリケーションを裁定するプロセスの一環として、将来のバージョンでも使用される可能性があります。また、メディアタイプではなくデータリンクまたは上位レベルのプロトコル検出に基づいて呼び出しを処理するアプリケーションを選択します。 その使用例として、リモート引き継ぎ、掲示板、リモート ネットワーク アクセス、リモート電子メール アクセスなどのアプリケーションが同時に待機している受信データ モデム回線があります。
メディアタイプのハンドオフ
メディアの種類のハンドオフは、新しいターゲット メディアの種類がある場合に行われます。通常、所有するアプリケーションが、呼び出しに必要なメディアの種類が存在しないか、変更しようとしていると判断した場合です。
メディアタイプ UNKNOWN ビットがオンの場合、メディア依存ハンドオフのプロセスはプローブプロセスになる可能性があります。 メディアの種類を順番に切り替えて最も優先度の高いアプリケーションを見つけるのは、所有するアプリケーションの役割です。 TAPI は、最初の所有者を見つけるために、最初の着信呼び出しでのみこの循環を行います。 ハンドオフ操作ではこれを行いません。 それ以外の場合、ハンドオフは、アプリケーションへの呼び出しの最初の割り当てと実質的に同じです。 違いは、間接 (メディアタイプ) ハンドオフに設定できるメディアタイプは 1 つだけであるという事実です。
指定できるメディア・タイプ・ビットは 1 つだけであるため、そのメディア・タイプの最も優先順位の高いアプリケーションに呼び出しが与えられます。 ただし、ハンドオフでは、複数のメディア タイプが考慮される可能性があります。 この場合、ハンドオフ アプリケーションでは、使用可能なメディアの種類の最も高い優先順位をパラメーターとして指定する必要があります。
メディアタイプハンドオフの実行時にアプリケーションが UNKNOWN ビットを指定し、ハンドオフが失敗した場合、これは、メディアタイプ判定を実行できる不明なアプリケーションが現在実行されていないことを意味します。 次に、引き継ぐアプリケーションは、次に上位のメディアタイプに登録されている最も優先度の高いアプリケーションにコールオフを渡す必要があります。
受信アプリケーションが呼び出しを担当するようになりました。 これで、呼び出しの実際のメディアの種類がプローブされます。 アプリケーションが呼び出しのメディアの種類を処理できる場合は、そのメディアの種類に登録されている最も優先度の高いアプリケーションであることを確認する必要があります。 その場合は、呼び出しを保持し、正常に処理します。 そうでない場合は、そのメディアタイプに登録されている別のアプリケーションにコールオフします。
ただし、そのメディアタイプのプローブが失敗した場合、アプリケーションは再びプローブし、残りのメディアモードの可能性を試みます。 最初に現在のメディアタイプビットをオフにしてから、別のタイプのハンドオフを試す必要があります。
このプローブと引き渡しのプロセスは続き、残りのメディアの種類は 1 つずつ削除されます。 その過程で、アプリケーションの 1 つで、処理するメディアの種類が呼び出し中であり、ハンドオフが成功していることがわかります。
その後、アプリケーションで正しいメディアの種類を設定し、他のすべてのメディアタイプビットをクリアする必要があります。 これにより、他の関心のあるアプリケーションに正しいメディアの種類が通知されます。 これらの他のアプリケーションは、呼び出しのメディアの種類が変更されたことを示すイベント通知メッセージを受け取ります。