このトピックでは、TSP 操作の概要を説明します。
セッションとは、特定の構成が有効なままであり、テレフォニー操作が実行される時間です。サービス プロバイダーは、最初に読み込まれてから最終的に解放されてからの間に、多くのセッションをサポートできます。 セッションごとに、TAPI はインターフェイスのバージョンをネゴシエートし、セッションを開始し、操作を実行して、最終的にセッションをシャットダウンします。 サービス プロバイダーは、セッション間で情報を保持することはできません。
インターフェイスのバージョンがわかったら、TAPI は TSPI_providerInit 関数を呼び出して、すべての操作パラメーターを設定します。 サービス プロバイダーは、TSPI_providerInit 関数が呼び出されたときに、レジストリ内のすべての構成情報が安定していることを確認します。 ほとんどのサービス プロバイダーは、その時点ですべての構成情報を読み取ります。
通常の操作は、サービス プロバイダーが初期化された後、任意の順序で続行できます。
TAPI は、デバイスごとにデバイス固有の情報をネゴシエートします。 TAPI とサービス プロバイダーは、デバイスを開いたときにバージョンにコミットします。
サービス プロバイダーは、拡張機能のバージョンを選択して取り消す要求を受け取ることができます。 拡張機能のバージョンが選択されている間、デバイスはそのデバイス固有の拡張機能のバージョンに厳密に従って動作します。
デバイス固有の拡張機能バージョンのネゴシエーションは、デバイスが開かれる前と後の両方で複数回発生する可能性があります。 TAPI はバージョン範囲を渡し、サービス プロバイダーはこの範囲の値を選択して返します。 通常、サービス プロバイダーでは、デバイス固有の拡張機能が無効になっています。
これにより、TAPI とサービス プロバイダーの両方が、選択が取り消されるまで、その拡張機能のバージョン レベルで動作するようにコミットされます。 デバイス固有の拡張機能が有効になっている間、拡張機能のバージョン レベルをネゴシエートしようとすると、現在有効になっているバージョン レベルのみが許可されます。 デバイス固有の拡張機能が取り消されると、別のバージョンをネゴシエートして選択できます。
次の図に、の [開く] と [閉じる] のペア内の電話操作を示します。 これらの操作の一部は同期的で、他の操作は非同期です。 操作が非同期に完了した場合、最初のレポートが完了する前に別の操作を要求できます。 したがって、操作は何らかの方法で重複する可能性があります。 サービス プロバイダーは、要求された非同期操作の完了を最終的に報告する必要があります。 電話を閉じると、未処理の非同期操作が強制的に完了します ("失敗" の兆候がある可能性があります)。
回線デバイスのライフ サイクルは、電話のライフ サイクルに似ていますが、回線には独自のネゴシエーション、初期化、オープン、クローズの手順があります。 開いている行に対する操作は、独自の Open/Close ペアによって角かっこで囲まれます。 このペアは、電話 開く/閉じると同じ 初期化/シャットダウン ペアの間でかっこで囲まれます。
呼び出しのライフ サイクルは、それらの呼び出しを含む行の Open/Close の間で厳密にかっこで囲まれます。 呼び出しの有効期間は、いくつかの方法で開始できます。
- lineMakeCall、lineSetupTransfer、lineSetupConferenceなどの関数を介して TAPI から要求されます。
- サービス プロバイダーでは、新しい着信通話、接続された電話受話器でのユーザー開始呼び出し、または既存の通話の保留などの他の操作の副作用として生成された呼び出しとして、サービス プロバイダーで発生します。
同じ行内の個別の呼び出しの有効期間は、どのような方法でも相互に重複する可能性があります。 すべての呼び出しは、TSPI 関数 TSPI_lineCloseCall が呼び出されたときに有効期間を終了します。 次の図に、複数の呼び出しのライフ サイクルを示します。
呼び出しは、MakeCall/CloseCall ペアで示されているように TAPI で発信できます。 呼び出しは、サービス プロバイダーから発信することもできます。 サービス プロバイダーは、TAPI が提供するコールバック プロシージャに LINE_NEWCALL メッセージでこれを読み上げる。 このような場合、TAPI は呼び出しの識別子を返します。これは、呼び出しで発生したイベントを報告する後続のコールバックに含まれます。 TAPI で有効期間が発生した呼び出しの場合、この識別子は、呼び出しを作成する TSPI 操作に含まれます。
呼び出しの有効期間を開始するすべての操作では、TAPI とサービス プロバイダーが新しい呼び出しの識別子を交換します。 TAPI が発信した呼び出しの場合、TAPI はその識別子を渡し、戻り値パラメーターとしてサービス プロバイダーの識別子を受け取ります。 サービス プロバイダーで呼び出しが発生した場合、サービス プロバイダーはその識別子を TAPI に渡し、戻り値パラメーターとして TAPI 識別子を受け取ります。
次の図は、サービス プロバイダーのインストール、構成、および削除の概要を示しています。多くのセッションにまたがるライフサイクル シーケンス。 これらの操作の一般的なライフ サイクルは、次のタイム ラインで示すことができます。
サービス プロバイダー
一般的なインストールと削除のライフ サイクルが表示され、複数のセッションにまたがる。 インストール と Remove プロシージャの呼び出しは厳密にペアになり、重複しません。 Config プロシージャの呼び出しは、このペア内で複数回発生する可能性があります。 1 つは通常、サービス プロバイダーによって、回線と電話のエントリを作成するための Install プロシージャの内部副作用として行われます。 Config プロシージャは、他の時点で呼び出して既存のセットアップを変更できます。 インストール 手順は、他の TSPI 機能を許可する前に実行する必要があります。 理想的なシナリオでは、すべてのセッションが Install/Remove プロシージャ ペア内 厳密に入れ子になります。
関数 TSPI_providerInstall、TSPI_providerConfig、および TSPI_providerRemove は、特定のデバイスではなく、サービス プロバイダー自体と対話します。 これらは、複数のセッション間で存続する静的構成情報に影響を与え、他の操作を続行するために存在する必要があります。 したがって、他のすべての操作は、TSPI_providerInstall の呼び出しと一致する TSPI_providerRemoveの完了の間に入れ子になります。 通常、これら 2 つの操作は非常に離れて発生します。ほとんどの場合、サービス プロバイダーの負荷が異なるか、コンピューターのブートが異なります。 Config 関数を外部で呼び出すことは省略可能です。これは、インストール プロシージャに、Config の動作を含める必要があるためです。 外部から呼び出す通常の理由は、既存の構成を変更することです。
TSPI_providerRemove 操作の完了の概念には微妙な部分が埋め込まれています。 テレフォニー操作 (セッション) が進行中であっても、ユーザーがテレフォニー サービスに付属のテレフォニー コントロール パネル ユーティリティを実行してサービス プロバイダーの構成を変更できるようにすることが望ましいです。 そのため、未処理のセッションがある間は、TSPI_providerConfig 仕様と TSPI_providerRemove 仕様の両方で呼び出しが可能になります。 ただし、構成に対する変更は、テレフォニー操作がシャットダウンされて再起動されるまで遅延する必要があります。 したがって、厳密に言えば、TSPI_providerConfig または TSPI_providerRemove 操作の完了は、セッションの外部で行われます。 プロシージャの呼び出しが少し異なる順序で表示される場合でも、アクションの入れ子は図のように表示されます。 サービス プロバイダーは、操作の進行中に Config または Remove を許可しますが、ユーザーにはダイアログ ボックスで通知する必要があります。 少なくとも操作のサブセットを許可する、よりわかりやすい実装をお勧めします。
これらの のインストール、構成、および 操作の削除はすべて、実行中のテレフォニー アプリケーションに通知する副作用があり、その結果、テレフォニー サービスの使用がシャットダウンされます。 これにより、サービス プロバイダーのすべての未処理のセッションが終了します。 これは、新しいセッションの開始時に新しいレジストリ構成を読み取る必要があることをサービス プロバイダーに示します。 構成 または操作の進行中にを削除が原因で保留中であったすべての変更が有効になります。