(57)【特許請求の範囲】
【請求項１】
パケット・ベースの通信ネットワークにホーム・アドレスで接続されたパーソナル・ホストを有する被呼側が、宛先アドレスを持つネットワークに接続された外部ホストにおいて、もともと発呼側ホストから前記パーソナル・ホストに宛てたマルチメディア呼を受信できるようにするパーソナル移動方法において、
ａ）前記被呼側が前記呼リダイレクタ・アプリケーションを起動するステップと、
ｂ）前記被呼側が、前記外部ホストからパーソナル・ホストへの登録要求を介して、前記呼リダイレクタによって前記宛先アドレスを登録するステップと、
ｃ）前記パーソナル・ホスト上で動作する呼リダイレクタ・アプリケーションが、前記発呼側ホストからの呼設定要求に対して、前記宛先アドレスを含む呼設定応答によって応答するステップと、
ｄ）前記発呼側ホストが、前記宛先アドレスにある前記外部ホストに呼設定要求を送るステップと、
ｅ）前記外部ホストが呼設定応答を送ることで、前記発呼側ホストと外部ホストとの間にリンクを張るのに要する呼シグナリングを完了するステップとを備えることを特徴とするパーソナル移動方法。
【請求項２】
前記パーソナル・ホストが、前記登録要求が首尾よく受信されたことを示す登録応答を前記外部ホストに送るステップをさらに備えることを特徴とする請求項１記載のパーソナル移動方法。
【請求項３】
記呼リダイレクタが起動された後であって、前記被呼側が前記外部ホストからの前記宛先アドレスを登録する前に、呼が補助の呼ハンドリング・プラットフォームに送られることを特徴とする請求項１記載のパーソナル移動方法。
【請求項４】
前記補助の呼ハンドリング・プラットフォームは、マルチメディア音声メール・サーバを備えることを特徴とする請求項３記載のパーソナル移動方法。
【請求項５】
前記ステップａ）は、前記被呼側によって、前記パーソナル・ホスト上で直接、実行されることを特徴とする請求項１記載のパーソナル移動方法。
【請求項６】
前記ステップａ）は、前記外部ホストによって実行されることを特徴とする請求項１記載のパーソナル移動方法。
【請求項７】
前記登録要求は認証情報を含んでおり、前記パーソナル・ホストは、この登録要求を正当であるとして受け入れる前に、前記認証情報に対する確認ステップを実行することを特徴とする請求項２記載のパーソナル移動方法。
【請求項８】
前記被呼側が前記パーソナル・ホストに戻る場合、前記外部ホストが、このパーソナル・ホストに登録解除要求を送り、そして、前記パーソナル・ホストが、登録解除応答によって、前記登録解除要求に応答するステップをさらに備えることを特徴とする請求項２記載のパーソナル移動方法。
【請求項９】
パケット・ベースの通信ネットワークにホーム・アドレスで接続された移動ホストを有する被呼側が、宛先アドレスで接続された移動ホストにおいて、もともと発呼側ホストからパーソナル・ホストに宛てたマルチメディア呼を受信できるようにする端末移動方法において、
ａ）前記被呼側が、前記ネットワークに送られた起動要求メッセージによって、前記シャドー・ホスト上で前記呼リダイレクタ・アプリケーションを起動するステップと、
ｂ）前記被呼側が、前記宛先アドレスにおいて接続された移動ホストから前記パーソナル・ホストへの登録要求を介して、前記呼リダイレクタによって前記宛先アドレスを登録するステップとを実行し、
さらに、
ｃ）シャドー・ホスト上で動作する呼リダイレクタ・アプリケーションが、前記宛先アドレスを含む呼設定応答によって、前記発呼側ホストから前記パーソナル・ホストにアドレス指定された呼設定要求を傍受するステップと、
ｄ）前記発呼側ホストが、前記宛先アドレスにある前記移動ホストに呼設定要求を送るステップと、
ｅ）前記移動ホストが呼設定応答を送ることで、前記発呼側ホストと移動ホストとの間にリンクを張るのに要する呼シグナリングを完了するステップとを備えることを特徴とする端末移動方法。
【請求項１０】
前記シャドー・ホストが、前記登録要求が首尾よく受信されたことを示す登録応答を前記移動ホストに送るステップをさらに備えることを特徴とする請求項９記載の端末移動方法。
【請求項１１】
前記呼リダイレクタが起動された後であって、前記被呼側が前記移動ホストからの前記宛先アドレスを登録する前に、呼が補助の呼ハンドリング・プラットフォームに送られることを特徴とする請求項９記載の端末移動方法。
【請求項１２】
前記補助の呼ハンドリング・プラットフォームは、マルチメディア音声メール・サーバを備えることを特徴とする請求項１１記載の端末移動方法。
【請求項１３】
前記登録要求は認証情報を含んでおり、前記シャドー・ホストは、この登録要求を正当であるとして受け入れる前に、前記認証情報に対する確認ステップを実行することを特徴とする請求項１０記載の端末移動方法。
【請求項１４】
前記被呼側が前記移動ホストをホーム・アドレスに再接続する場合、この移動ホストが前記シャドー・ホストに登録解除要求を送り、そして、このシャドー・ホストが、登録解除応答によって、前記登録解除要求に応答するステップをさらに備えることを特徴とする請求項１０記載の端末移動方法。
【請求項１５】
前記シャドー・ホストはホーム・ネットワークに接続され、前記移動ホストのホーム・アドレスは同一ホーム・ネットワーク上にあり、さらに、前記シャドー・ホストが、ＩＰエイリアシング技術を使って、前記移動ホストのホーム・アドレス宛ての全てのパケットを傍受し、かつ処理するステップを備えることを特徴とする請求項９記載の端末移動方法。
【請求項１６】
パケット・ベースの通信ネットワークに接続された複数のピア・コンピュータ装置にマルチメディア呼を分配する呼分配方法であって、各コンピュータ装置はアドレスを持ち、前記ピア・コンピュータ装置の１つはメイン・アドレスを持つと共に呼リダイレクタ・アプリケーションを備える、当該呼分配方法において、
ａ）前記メイン・アドレスを持つ前記コンピュータ装置上で動作する前記呼リダイレクタ・アプリケーションが、前記複数のピア・コンピュータ装置の１つのアドレスからなるリダイレト・アドレスを含む呼設定応答によって、前記発呼側ホストからの呼設定要求に応答するステップと、
ｂ）前記発呼側ホストが、前記リダイレト・アドレスに前記呼設定要求を送るステップと、
ｃ）前記複数のコンピュータ装置の１つが呼設定応答を送ることで、前記発呼側ホストと複数のコンピュータ装置の１つとの間にリンクを張るのに要する呼シグナリングを完了するステップとを備えることを特徴とする呼分配方法。
【請求項１７】
前記呼リダイレクタが、前記複数のコンピュータ装置に、呼を受け入れる申し出を含むメッセージを送るステップと、
１あるいはそれ以上の前記ピア・コンピュータ装置が、呼受け入れメッセージによって前記申し出に応答するステップと、
前記呼リダイレクタが、呼受け入れメッセージによって応答した前記ピア・コンピュータ装置の１つのアドレスを、転送アドレスとして選択するステップとをさらに備えることを特徴とする請求項１６記載の呼分配方法。
【請求項１８】
前記呼リダイレクタは、どのピア・コンピュータ装置が前記呼を受け取ることになっているかを自動的に判定することを特徴とする請求項１６記載の呼分配方法。
【請求項１９】
前記ピア・コンピュータ装置が呼を受け取れる状態にあるとき、これらピア・コンピュータ装置が、前記呼リダイレクタに利用可能性を示すメッセージを送るステップをさらに備え、この呼リダイレクタは、利用可能なピア・コンピュータ装置のリストを維持して、そのリストに基づいて前記転送アドレスを選択することを特徴とする請求項１８記載の呼分配方法。
【請求項２０】
前記呼をリダイレクトする前に、前記発呼側ホストと、前記メイン・アドレスを持つ前記コンピュータ装置との間に媒体チャネルが確立されることを特徴とする請求項１６記載の呼分配方法。
【請求項２１】
パケット・ベースの通信ネットワークに接続された複数のピア・コンピュータ装置にマルチメディア呼を分配する呼分配方法であって、各コンピュータ装置はアドレスを持ち、前記ピア・コンピュータ装置の１つはメイン・アドレスを持つと共に呼リダイレクタ・アプリケーションを備える、当該呼分配方法において、
ａ）前記メイン・アドレスを持つ前記コンピュータ装置上で動作する前記呼リダイレクタ・アプリケーションが、呼設定応答によって、前記発呼側ホストからの呼設定要求に応答するステップと、
ｂ）前記複数のピア・コンピュータ装置の１つが、前記メイン・アドレスを持つコンピュータ装置に呼設定要求を送って、前記ピア・コンピュータ装置が利用可能であることを示すステップと、
ｃ）前記メイン・アドレスを持つコンピュータ装置が、前記発呼側ホストのアドレスを含む呼設定応答によって応答するステップと、
ｄ）前記複数のコンピュータ装置の１つが、前記発呼側ホストに呼設定要求を送るステップと、
ｅ）前記発呼側ホストが呼設定応答によって応答することで、この発呼側ホストと、前記複数のコンピュータ装置の１つとの間にリンクを張るのに要する呼シグナリングを完了するステップと、
ｆ）前記発呼側端末が、前記メイン・アドレスを持つ装置に切断メッセージを送るステップとを備えることを特徴とする呼分配方法。
【発明の詳細な説明】
発明の分野
本発明は、パケット・ベース・マルチメディア通信網における呼リダイレクトの方法と適用に関する。
従来技術
今日では、交換機ベース電話網が一般的である。これは、通常、加入者単位で、呼の送出および呼の分配のようなリダイレクト・サービスを提供している。デフォルトＤＮ（電話番号）を有する加入者が呼を送出したときには、例えば、加入者が送出するＤＮを入力すると、加入者の電話とネットワーク・ノード間でシグナリング手続きが行われる。このネットワーク・ノードは、例えば、電話ネットワークスイッチ、またはＡＩＮ（最新のインテリジェント・ネットワーク）ベースのＳＳＰ（サービス交換ポイント）であってもよい。その後、ネットワーク・ノードは、最初に加入者のデフォルトＤＮに送られた呼のリダイレクトを制御して、それらの呼が送出ＤＮで受信されるようにする。このように、加入者にこれらの機能を供給する中央機構においては、動作、管理、保守機能のために莫大な投資が必要となる。
マルチメディア通信の役割を有する、ＩＰ（インターネット・プロトコル）、ＩＳＤＮ（統合サービス・ディジタル網）またはＡＴＭ（非同期転送モード）ベースのＬＡＮ（ローカル・エリヤ・ネットワーク）またはＷＡＮ（広域エリヤ・ネットワーク）に接続されたコンピュータ装置の使用は近年急速に増加している。この例として、パーソナル・イントラネットや公衆インターネットを介する音声通信やビデオ会議通信が挙げられる。通常の電話加入者に利用可能な機能と同様に、このようなマルチメディア通信メデイア呼リダイレクト機能を、ユーザに提供できることは好ましい。例えば、特定のＬＡＮ内で通常のアドレスを持つデフォルト位置に普通に接続されているコンピュータを持つエンド・ユーザが、異なる既知の場所に移動して、異なるアドレスを持つ他のコンピュータにアクセスするときには、エンド・ユーザの通常のアドレスにあるマルチメディア呼を、異なるアドレスに送れることは有益である。専用のコンピュータ装置またはサーバが要求された呼リダイレクト機能を多数のエンド・ユーザに供給するために用いられてもよい。この「サーバ・ベース」のアプローチは、関連動作、管理、保守機能を必要とし、またエンド・ユーザのコンピュータ装置から専用のコンピュータ装置へのアドレス翻訳および関連シグナリングが必要となる。これらは、複雑な動作となり、管理者の立場からすると好ましくない。さらに、専用装置に呼リダイレクト機能があると、制限されたエンド・ユーザの制御および呼の送出方法に関するカスタマイズを供給できる。
ＩＥＴＦ（インターネット・エンジニアリング・タスク・フォース）内の移動ＩＰワーク・グループによって定義された移動ＩＰは、インターネット／イントラネット内の端末移動に対する既存のＩＰ（ネットワーク）レイヤ手続きである（パーキンス，Ｃ．編集、「ＩＰ移動サポート」、ＲＦＣ  ２２０２，１９９６年１０月発行）。しかしながら、このプロトコルでは、ＩＰカプセル化またはトンネリングを扱うホーム・ルータの移動ホストＩＰスタックの修正、ホーム・エージェントの機能をサポートするホーム・ルータＩＰスタックの修正（すなわち、両呼シグナリングへのカプセル化／カプセル分解とトンネリング、および宛て先アドレスへのメディア・パケット）、遠端でのＩＰカプセル化／カプセル分解およびトンネリングを扱うための外部ネットワーク（ルータ）上の外部エージェントの存在、ホーム・エージェントおよび外部エージェントを発見して登録する手続き、および発呼側の移動ホストがファイアウォールの後のサブネットワークに属しているとき、ファイアウォールへアクセスする手続きが必要となる。
包括的に広範囲に渡って現在受け入れられているにもかかわらず、移動ＩＰプロトコルでは、端末機を移動する前に、ホーム・ネットワーク・ルータと外部ネットワーク・ルータの両方のＩＰスタック、および移動ホストのＩＰスタックを修正する必要がある。呼リダイレクトがルータ内のＩＰレイヤで実行されるために、エンドユーザは自己の呼がどのようにリダイレクトされるかをほとんど制御できないことになる。
発明の目的
本発明の目的は、上述の不利益の１以上を、未然に防ぐ、または、緩和させることにある。
発明の概要
本発明の第１の側面によれば、本発明は、パケット・ベースの通信ネットワークにホーム・アドレスで接続されたパーソナル・ホストを有する被呼側が、宛先アドレスを持つネットワークに接続された外部ホストにおいて、もともと発呼側ホストから前記パーソナル・ホストに宛てたマルチメディア呼を受信できるようにするパーソナル移動方法において、ａ）前記パーソナル・ホスト上で動作する呼リダイレクタ・アプリケーションが、前記発呼側ホストからの呼設定要求に対して、前記宛先アドレスを含む呼設定応答によって応答するステップと、ｂ）前記発呼側ホストが、前記宛先アドレスにある前記外部ホストに呼設定要求を送るステップと、ｃ）前記外部ホストが呼設定応答を送ることで、前記発呼側ホストと外部ホストとの間にリンクを張るのに要する呼シグナリングを完了するステップとを備えるように構成される。
本発明の第２の側面によれば、本発明は、通常、パケット・ベースの通信ネットワークにホーム・アドレスで接続された移動ホストを有する被呼側が、宛先アドレスで接続された移動ホストにおいて、もともと発呼側ホストからパーソナル・ホストに宛てたマルチメディア呼を受信できるようにする端末移動方法において、ａ）シャドー・ホスト上で動作する呼リダイレクタ・アプリケーションが、前記宛先アドレスを含む呼設定応答によって、前記発呼側ホストから前記パーソナル・ホストにアドレス指定された呼設定要求を傍受するステップと、ｂ）前記発呼側ホストが、前記宛先アドレスにある前記移動ホストに呼設定要求を送るステップと、ｃ）前記移動ホストが呼設定応答を送ることで、前記発呼側ホストと移動ホストとの間にリンクを張るのに要する呼シグナリングを完了するステップとを備えるように構成される。
本発明の第３の側面によれば、本発明は、パケット・ベースの通信ネットワークに接続された複数のピア・コンピュータ装置にマルチメディア呼を分配する呼分配方法であって、各コンピュータ装置はアドレスを持ち、前記ピア・コンピュータ装置の１つはメイン・アドレスを持つと共に呼リダイレクタ・アプリケーションを備える、当該呼分配方法において、ａ）前記メイン・アドレスを持つ前記コンピュータ装置上で動作する前記呼リダイレクタ・アプリケーションが、前記複数のピア・コンピュータ装置の１つのアドレスからなるリダイレト・アドレスを含む呼設定応答によって、前記発呼側ホストからの呼設定要求に応答するステップと、ｂ）前記発呼側ホストが、前記リダイレト・アドレスに前記呼設定要求を送るステップと、ｃ）前記複数のコンピュータ装置の１つが呼設定応答を送ることで、前記発呼側ホストと複数のコンピュータ装置の１つとの間にリンクを張るのに要する呼シグナリングを完了するステップとを備えるように構成される。
本発明の第４の側面によれば、本発明は、パケット・ベースの通信ネットワークに接続された複数のピア・コンピュータ装置にマルチメディア呼を分配する呼分配方法であって、各コンピュータ装置はアドレスを持ち、前記ピア・コンピュータ装置の１つはメイン・アドレスを持つと共に呼リダイレクタ・アプリケーションを備える、当該呼分配方法において、ａ）前記メイン・アドレスを持つ前記コンピュータ装置上で動作する前記呼リダイレクタ・アプリケーションが、呼設定応答によって、前記発呼側ホストからの呼設定要求に応答するステップと、ｂ）前記複数のピア・コンピュータ装置の１つが、前記メイン・アドレスを持つコンピュータ装置に呼設定要求を送って、前記ピア・コンピュータ装置が利用可能であることを示すステップと、ｃ）前記メイン・アドレスを持つコンピュータ装置が、前記発呼側ホストのアドレスを含む呼設定応答によって応答するステップと、ｄ）前記複数のコンピュータ装置の１つが、前記発呼側ホストに呼設定要求を送るステップと、ｅ）前記発呼側ホストが呼設定応答によって応答することで、この発呼側ホストと、前記複数のコンピュータ装置の１つとの間にリンクを張るのに要する呼シグナリングを完了するステップと、ｆ）前記発呼側端末が、前記メイン・アドレスを持つ装置に切断メッセージを送るステップとを備えるように構成される。
インターネット内の端末移動のために提案された上述の移動ＩＰプロトコルとは異なり、本発明の端末移動は、単純で簡単なソリューションを提供し、多くのエンドユーザ・サービス制御とカスタマイズとを提供できる。
本発明の端末移動は、移動ＩＰプロトコル・ソリューションが端末移動を実現するために必要とする機能または機能を必要としない。本発明は、アプリケーション・レイヤ・ソリューションであるので、エンドユーザに、多数の制御と呼がどのようにどこにリダイレクトされるかをカスタマイズする能力とを与えるだけでなく、このサービス機能をパッケージ化して、適切なインタフェースを介して、新たなマルチメディア・ベースのサービスを供給することも可能になる。
【図面の簡単な説明】
本発明の好適な実施の形態について、図面を用いて説明する。
図１は、パケット・ベース通信網内の基本的なブロック図である。
図２は、呼リダイレクトのフロー図である。
図３は、本発明のパーソナル移動のネットワークの概略図である。
図４は、パーソナル移動の信号フロー図である。
図５は、パーソナル移動の特定の実施の形態のフロー図である。
図６は、本発明の端末移動のネットワークの概略図である。
図７は、端末移動の信号フロー図である。
図８および図９は、端末移動の特定の実施の形態の信号フロー図である。
図１０は、本発明の自動呼分配の概略図である。
図１１は、本発明の自動呼分配の第１のタイプの信号フロー図である。
図１２は、本発明の自動呼分配の第２のタイプの信号フロー図である。
発明の実施の形態
２つのコンピュータ装置間でマルチメディア接続を確立する基本的なステップには、呼設定シグナリング、機能が交換されている間の交渉階段、音声／テキスト／ビデオ送信の接続確立、および最終的なメディア・ストリームの実際の送信までが含まれる。本発明は、種々の方法で、マルチ・メディア呼をリダイレクトする呼設定シグナリング段階間で用いられる方法を提供する。
呼リダイレクトの基本的な考えは、「品質保証のないサービスを供給するローカル・エリヤ・ネットワーク用の可視電話システムおよび装置」というタイトルのＩＴＵ−Ｔ勧告Ｈ．３２３に対する既存案中の概念的なレベルに含まれる。ＩＴＵ−Ｔは、国際的な条約によって確立された団体であり、相互動作の観点から通信サービスや手続きを勧告する。Ｈ．３２３勧告案は、マルチメディア呼がネットワーク・ルータなしにリダイレクトされるリダイレクト機能を提供する。以下に述べる本発明の種々の実施の形態は、Ｈ．３２３標準で提案された呼リダイレクト機能を用いて、パーソナル移動、端末移動、および呼の分配からなるマルチメディアリダイレクト機能を実現する。
まず、図１と図２を用いて、呼リダイレクトの概念について説明する。図１は、パケット・ベース・ネットワーク１６（実際には、ネットワークのネットワークである）の端に接続された第１、第２、第３のコンピュータ装置１０，１２，１４を示す。各々のコンピュータ装置は、他の任意のコンピュータ装置に対し、マルチメディア呼を生成する。ネットワーク１６は、例えば、ＩＰベースの公衆インターネット、ＩＰベースのイントラネット、ＩＳＤＮまたはＡＴＭネットワークである。各コンピュータ装置１０，１２，１４は、ネットワーク内に、例えば、ＩＰアドレスのような送出アドレスを持っている。各コンピュータ装置１０，１２，１４は、発呼者がネットワーク１６を介してマルチメディア呼を送受信する「基本サービス」アプリケーションを備える。図示の関係上、第２のコンピュータ装置１２には、「呼リダイレクタ」機能コンポーネント１８が備わっているものとする。呼リダイレクタ機能コンポーネント１８は、第２のコンピュータ装置１２上で走るアプリケーションであり、同じコンピュータ装置上を走る基本サービス・アプリケーションとインタフェースされる。呼リダイレクタ機能コンポーネント１８は、起動するときにあらかじめ構成され、呼リダイレクト機能が要求されるときには、別のコンピュータ装置の送出アドレス、例えば、第３のコンピュータ装置１４の送出アドレスを供給する。
図２を用いて、呼リダイレクト・シナリオ中で発生する基本ステップを説明する。信号フロー線５０，５２，５４は、コンピュータ装置１０，１２，１４間の信号またはメッセージの流れを表している。
初めに、第１のコンピュータ装置１０のエンドユーザは、第２のコンピュータ装置１２のエンドユーザと共に、マルチメディア通信制御セッションを開始することを決める。このために、第１のコンピュータ装置１０の基本サービスは、第２のコンピュータ装置１２の送出アドレスに対して、呼設定要求５０を開始する。コンピュータ装置１０は、また、リダイレクトを行うために用いられるプロトコルの特性に依存して、メッセージを送って最初の接続要求を取り消す。
呼設定要求５０は、第２のコンピュータ装置１２の基本サービスによって処理される。第２のコンピュータ装置１２が呼リダイレクタが起動されたと判断すれば、指示が、呼リダイレクタ機能コンポーネント１８に送られ、別の送出アドレスが参照される。この例では、別の送出アドレスは、呼設定要求５０がリダイレクトされるべき第３のコンピュータ装置１４の送出アドレスである。第２のコンピュータ装置１２の基本サービスは、第３のコンピュータ装置１４の送出アドレスを示すメッセージ部分を含む第１のコンピュータ装置１０に対して呼設定応答５２を開始する。第２のコンピュータ装置１２が、呼のリダイレクトが行われないと判断すれば、第２のコンピュータ装置１２は、単に、受信呼または理由メッセージ付きの拒否呼を含む呼設定応答に応じる。
呼設定応答５２は、第１のコンピュータ装置の基本サービスによって処理される。呼設定応答５２のメッセージ部中の送出アドレスを抽出した後、第１のコンピュータ装置１０の基本サービスは、第３のコンピュータ装置１４の送出アドレスに対して、新しい呼設定要求５４を開始する。
本発明の第１の実施の形態のパーソナル移動を、図３と図４を用いて説明する。また、特定の既存のプロトコルと標準に関する特有の実行については、図５で説明する。パーソナル移動を用いると、被呼側は、発呼側から発呼され、最初は被呼側パーソナルまたは最も頻繁に使われるコンピュータ装置に向けられ、その後異なるコンピュータ装置にリダイレクトされるマルチメディア呼を持つことができる。まずは、ネットワーク１６がＩＰベースのイントラネットである場合の用語を定義する。
ホーム・アドレスは、延長期間に対して、コンピュータ装置に割り当てられるＩＰアドレスを意味する。これは、ネットワーク上の被呼側の永久ＩＰアドレスを表す。
宛先アドレスは、移動被呼側にたどり着けるようにコンピュータ装置に割り当てられたＩＰアドレスである。これは、ホーム・ネットワークまたは外部ネットワークのどちらかの被呼側の一時的なＩＰアドレスを表す。
ホーム・ネットワークとは、被呼側のホーム・アドレスのプレフィックスと一致するネットワーク・プレフィックスを有するサブネットワークである。被呼側のホーム・アドレスに向けられたすべてのパケットは、このサブネットワークに供給される。
外部ネットワークは、被呼側のホーム・ネットワーク以外のサブネットワーク等をいう。
ＰＨ（パーソナル・ホスト）は、ホーム・アドレスが割り当てられた固定のコンピュータ装置である。
ＦＨ（外部のホスト）は、宛先アドレスが割り当てられた固定のコンピュータ装置である。ＰＨとＦＨは、ネットワーク内の同じまたは別のサブネットワークに接続されていてもよい。
ＣＨ（発呼側のホスト）は、発呼側が、そこから呼を被呼側に開始する固定または移動ホスト（かならずしも発呼側に所有される必要はない）である。
呼リダイレクタは、上述のリダイレクト機能を供給するアプリケーションであり、図１と図２に示される。被呼側がＦＨに移動したとき、被呼側宛ての呼をリダイレクトするために、ＰＨ上には、ソフトウェアの一部が置かれる。呼リダイレクタは、基本サービスとインタフェースして、パーソナル移動サービス機能を供給する。
上述のように、基本サービスは、アプリケーション・ソフトウェア（好ましくは、ＧＵＩ（グラフィック・ユーザ・インタフェース）機能）からなる。このソフトウェアによって、発呼側は、関連ネットワークを介して、音声、データ、またはビデオ呼の送受信をする。基本サービスは、ＰＨ、ＦＨ、ＣＨにインストールされる。
ＰＭＡ（パーソナル移動アプリケーション）は、パーソナル移動に必要なメッセージを処理できる基本サービスの特別版のアプリケーション・ソフトウェアである。ＰＭＡは、ＰＨ、ＦＨ、ＣＨ上にインストールされなければならない。これは、呼リダイレクタ・コンポーネントを含む。
パーソナル移動は、アプリケーション・レイヤ・サービス機能によって供給される。この機能は、上記のリダイレクト・シグナリング手順を用いて、ＰＨによって受信された音声、データまたはビデオ呼を、エンドユーザによってあらかじめ特定されたＦＨにリダイレクトする。この手順は、ＰＨ上にある呼リダイレクタ機能コンポーネントによって調整される。上述のように、呼リダイレクタは、基本サービスとインタフェースし、ユーザは、例えば、基本サービスＧＵＩを介して、呼リダイレクタの動作を制御できる。ＦＨは、エンドユーザの登録機能を有していなければならない。これは、例えば、基本サービスＧＵＩの一部を形成する。登録ＧＵＩとして実行される。
図３には、一例として、ホーム・ネットワーク７２に接続されたＣＨ７０が示される。被呼側のＰＨ７４は、同じホーム・ネットワーク７２に接続され、呼リダイレクタ・コンポーネント１８が備わっている。被呼側が現在登録されている（宛先アドレス）ＦＨ７６も、同じホーム・ネットワーク７２に接続される。また、外部ネットワーク７７も、ルータ７８を含む接続ネットワークを介して、ホーム・ネットワーク７２に接続される。もっと一般的には、多数のホーム・ネットワークが、非常に大規模のネットワークのサブネットワークとして、ルータを介して一緒に接続されてもよいし、または、非常に大規模のネットワークの端に接続されたネットワークとして、ルータを介して、一緒に接続されてもよい。大規模ネットワークとは、例えば、公衆インターネットであってもよい。被呼側のＰＨ７４、被呼側のＦＨ７６、ＣＨ７０が同じホーム・ネットワークに接続される特定の方法は単なる一例である。より一般的には、これらの装置は、それぞれ、異なるホーム・ネットワークか、またはサブネットワークに接続される。異なるホーム・ネットワークが用いられている場合には、異なるネットワークに接続されたユニット間に置かれるような方法でマルチメディア呼が接続されるだけである。
図４で、パーソナル移動機能を実行するステップのシーケンスについて説明する。信号フロー線８０〜１００は、ＣＨ７０，被呼側のＰＨ７４，ＦＨ７６の間のシグナリングまたはメッセージ・フローを表している。
パーソナル移動機能を実行する前には、被呼側は、典型的には自己のＰＨ７４にいる。この間、呼リダイレクタ１８は起動されていないので、被呼側に対するすべての呼は、自己のＰＨ７４で受信される。
最初ＰＨ７４にいる被呼側が、ＦＨ７６に移動することを決めると、被呼側は、呼リダイレクタ１８を起動させて、移動被呼側からの両要求を処理し、被呼側のホーム・アドレスに向けられた全ての呼設定要求を処理する。これは、起動コマンド８０を送出する被呼側によって基本サービスＧＵＩを介して行われ、次に、このコマンドは呼リダイレクタ１８に与えられる。呼リダイレクタ１８は、今起動したことを示す起動応答８１を戻してもよい。起動の後、被呼側は、自己のＰＨ７４から安全に移動する。ＦＨ７６からの登録要求がＰＨ７４によって受け取られるまで、ＰＨ７４は呼を待ち続ける。
ここで、被呼側はＦＨ７６に移動し、そのＦＨ７６上で、基本サービスによって供給された再登録ＧＵＩを使用して、自己のＦＨ７４に登録要求８２を送ったものと仮定する。登録要求８２は、ＦＨ７６のアドレスを含む。このＦＨ７６のアドレスは、宛先アドレスになり、将来の呼はＦＨにリダイレクトされることを示す。ＰＨ７４上の呼リダイレクタ１８は、この登録要求８２を受けとり、登録応答８４を戻す。
発呼側によって、ＣＨ７０から被呼側ＰＨ７４に送られた後続の呼設定要求８６は、処理のため、ＰＨ内の呼リダイレクタ１８に送られる。呼リダイレクタ１８は、次に、移動被呼側への新しい宛先アドレスを示す呼設定応答８８をＣＨ７０へ送出する。新しい宛先アドレスは、ＦＨ７６のアドレスである。ＣＨ７０の基本サービスは、この呼設定応答８８を受け取り、それによって、第２の呼設定要求９０を、供給された宛先アドレスに送る必要があるかどうかを決定する。このＦＨ７６は、呼設定要求９０を受け取り、呼を受領し、呼設定応答９２をＣＨ７０に送る。この時点で、マルチメディア呼の確立に必要な設定シグナリングのステップは完了する。
この後、前述の従来の付加的ステップ（交渉、メディア・チャネル確立など）が実行されて、最終的には、ＣＨ７０とＦＨ７６間の音声通信９４のようなメディア・ストリーム接続が行われる。
ＦＨ７６に再配置された被呼側が出力呼を開始すると決めると、呼設定要求は、標準のＩＰルーティングを用いて、ＦＨ７６から宛先ＩＰアドレスに直接送られる。
移動サービスが要求されなくなると、移動被呼側は、ＦＨ７６の基本サービスによって供給された再登録ＧＵＩを用いて、最初、ＰＨ７４に登録されていた現在の宛先アドレスの登録を解除する。これは、登録解除要求メッセージ９６と登録解除応答メッセージ９８の交換を介して行われる。
移動被呼側が別のＦＨに移動すると、被呼側は、他の登録要求と登録応答メッセージの交換を介して、ＦＨのアドレスを自己のＰＨ７４のアドレスとして登録してもよい。また、移動被呼側が自己のＰＨ７４に戻ったら、被呼側は、呼リダイレクタ１８（１００）を停止して、パーソナル移動サービスを中止してもよい。
好ましくは、被呼側は、呼リダイレクタ１８（自己のＰＨにある）を構成して、例えば、後続の選別手続きによって、選択的に、呼を自己の新しい位置にリダイレクトしてもよい。
また、好ましくは、被呼側は、移動しようとするＦＨ７６のＩＰアドレス（宛先アドレス）を前もって知っていれば、ＰＨ７４から、呼リダイレクタ１８に登録してもよい。
本発明のパーソナル移動を上記のように説明したが、これは、現在または将来出てくるどのような標準および要求とも無関係である。しかしながら、エンドポイントが、Ｑ．９３１およびＩＳＯ  ＱＳＩＧ標準で定義された補助的なサービスを使用できるように、Ｈ．３２３内で準備が行われている。Ｑ．９３１およびＩＳＯ  ＱＳＩＧ標準は以下の通りである。
Ｑ．９３１：ＩＴＵ−Ｔ勧告Ｑ．９３１，「ディジタル加入者シグナリング・システム１（ＤＳＳ１）  −  基本呼制御のためのＩＳＤＮユーザ・ネットワーク・インタフェース・レイヤ３仕様書」、
ＩＳＯ  ＱＳＩＧ標準：ＱＳＩＧは、Ｑ基準点でのシグナリングに関し、この基準は次の標準を含む。すなわち、
ＩＳＯ／ＩＥＣ  １１５８３：「情報技術  −  システム間の電気通信および情報の交換  −  パーソナル統合サービス・ネットワーク  −  補助的なサービスのサポート用の一般的機能プロトコル  −  内部交換シグナリング手順およびプロトコル」、
ＩＳＯ／ＩＥＣ１３８７２：「情報技術  −  システム間の電気通信と情報の交換  −  パーソナル的統合サービス・ネットワーク  −  サービス記述、機能的性能および情報の流れ  −  転送補助サービス」、
ＩＳＯ／ＩＥＣ  １３８７３：「情報技術  −  システム間の電気通信および情報の交換  −  パーソナル統合サービス・ネットワーク  −  内部交換シグナリング・プロトコル  −  呼転送補助サービス」である。
これらの標準は、呼シグナリング・チャネルとＱ．９３１メッセージング・プロトコルを供給する。Ｑ．９３１メッセージング・プロトコルは、以下に述べる他の機能と共に、上述のパーソナル移動機能の特定の実行を行うために用いられてもよい。これらには、端末移動および呼分配が含まれる。
Ｈ．３２３のようなパーソナル移動機能を実現する一例を説明する。Ｈ．３２３における補助的なサービスの動作の説明については、まだ標準化されていないため、以下の詳細な説明は、新しい標準とは異なることに注意されたい。この実施の形態は、ＩＰベースのイントラネットおよびインターネットを念頭に入れている。Ｈ．２２５（ＩＴＵ−Ｔ勧告Ｈ．２２５，「メディア・ストリーム・パケット化および品質が保証されないＬＡＮサービスにおける可視電話システムの同期化」）装置の情報エレメントは、ＩＳＯ／ＩＥＣ  １３８７３のセクション６．３．２に基づいて用いられる。装置情報エレメントは、ＩＴＵ−Ｔ  Ｈ．２２５で特定されるメッセージ中で運ばれる。
この勧告で、ＰＭＡは、ＱＳＩＧメッセージの情報を処理できるアプリケーション・ソフトウェアから構成される。先に示したように、ＰＭＡは、ＰＨ７４，ＦＨ７６，ＣＨ７０上にインストールされる。公知のポート番号は、ＰＭＡポートと呼ばれ、他のＰＭＡに情報エレメントを送り、また他のＰＭＡから情報エレメントを受け取るために使われる。ＰＭＡ自身は、ソフトウェアのスタンドアロン部であってもよいし、または、ユーザが音声、データまたはビデオ呼を、ＩＰネットワークを介して送りまたは受信する基本サービス・マルチメディア・アプリケーションとインタフェースしてもよい。ＰＭＡは呼リダイレクタ機能コンポーネントを含む。被呼側のＰＨ７４上の呼リダイレクタ１８はルックアップ・テーブルを有し、そのルックアップ・テーブルは、被呼側ＩＤ、移動被呼側が現在位置しているまたは位置すると予想されるＦＨ７６の宛先アドレス、および光選別フィールドからなる。被呼側は、ＦＨ７６に移動する前に、ＰＨ７４上にインストールされた呼リダイレクタ１８を起動してもよいし、または遠隔で起動してもよい。呼リダイレクタ１８の起動の後で移動被呼側から登録を受信するより前に、呼がＰＨ７４に到着する場合には、呼は、マルチメディア音声メール／留守番電話のような補助呼処理プラットフォームに随時送られてもよい。
例えば、
ＰＭＡは以下のＱＳＩＧ動作を処理できる。
・divertingLegInformation2.inv：受信された呼がリダイレクトされた呼であることを、ＦＨ７０の移動被呼側に示すために使われる。
・divertingLegInformation3.rr：リダイレクトされた呼が移動被呼側に送られたことを、ＦＨ７０の発呼側に示すために使われる。
・callRerouting.inv：特定の呼に対するリダイレクト要求をするために使われる。
・callRerouting.rr：呼リダイレクトの結果を確認するために使われる。
ＰＭＡは情報エレメントを呼リダイレクタ１８に送り処理する。
・activeDiversionQ.inv：登録要求を表示するために使われる。
・activeDiversionQ.rr：登録要求に応答するために使われる。
・deactiveDiversionQ.inv：登録解除要求を表示するために使われる。
・deactiveDiversionQ.rr：登録解除要求に応答するために使われる。
図５は、図４と類似し、特定のＱＳＩＧ／Ｈ．３２３環境で各ステップを実行するために必要な特定のメッセージ・タイプを示す図である。図５の信号フローは、図４の信号フローの特定の等価な機能を示し、同じステップは参照番号で表示される。
パーソナル移動に対してどのようなステップを実行するかについて、引き続き説明するよりも、ＰＨ７４，ＣＨ７０，ＦＨ７６の各々で起こる動作について、ＰＨから、個々に説明する。
まず始めに、遠隔登録に対してＰＨ７４で起こる動作について説明する。ＰＨ７４が、ＦＨから、設定メッセージ８２中のactiveDiversionQ.inv ＡＰＤＵ（アプリケーション・プロトコル・データ・ユニット）を受け取ると、呼リダイレクタ１８は、いくつかのローカル認証技術を用いて、移動被呼側のＩＤと受け取った情報エレメント中のパスワード・エレメントの信頼性をチェックする。移動被呼側に信頼性があると分かれば、呼リダイレクタ１８は、接続メッセージ８４内のactiveDiversionQ.rr ＡＰＤＵに応答する。呼リダイレクタ１８は、登録ルックアップ・テーブルの中に、移動被呼側のＩＤと、現在の宛先アドレスと、設定メッセージ８２で受け取られた他の選別フィールドとを登録する。
次に、登録解除時にＰＨ７４で起こる動作について説明する。設定メッセージ９６中のdeactiveDiversionQ.inv ＡＤＰＵを受け取ると、呼リダイレクタ１８は、再度、移動被呼側の信頼性をチェックする。信頼性があると確認されると、呼リダイレクタ１８は、接続メッセージ中９８のdeactiveDiversionQ.rr ＡＤＰＵを使って設定メッセージに応答する。その後、呼リダイレクタ１８は、登録ルックアップ・テーブルから、移動被呼側の登録に関する情報を除去する。
次に、呼リダイレクタ１８がいったん動作した後のＰＨ７４における動作について説明する。呼リダイレクタ１８がいったん動作すると、ＰＨで受け取られるすべての設定メッセージ中の情報エレメントは、ＰＭＡによって調査される。いくつかのメッセージが、非呼関連シグナリングでなく実際の呼設定に関するものであれば、呼リダイレクタ１８は、登録ルックアップ・テーブルを調べる。もし、移動被呼側が、現在の自己の宛先アドレスが登録済みであれば、呼リダイレクタ１８は、ローカル呼選別技術を用いて、発呼側に、移動被呼側の宛先アドレスを提供するかどうかを判断する。テーブル入力の宛先アドレスに関する選別フィールドは、この目的のために使われる。発呼側が選別されれば、ＰＨ７４は機能メッセージ８８中のcallRerouting.inv ＡＰＤＵを送る。このcallRerouting情報エレメントは、要求された他の情報エレメントと共に、移動被呼側の現在の宛先アドレスを含む。ＰＨ７４は、その後解放完了メッセージ８９中のcallRerouting.rr ＡＰＤＵを受け取って、ＣＨ７０からの宛先アドレスの受領を確認する。
次に、ＣＨ７０で発生する動作について説明する。ＣＨ７０はＰＨ７４から受け取った機能メッセージ８８中のcallRerouting.inv ＡＤＰＵを受け取ると、解放完了メッセージ８９中のcallRerouting.rr ＡＰＤＵを使って応答を返す。この解放完了メッセージ８９は、ＰＨ７４への呼の終端も行う。その後、ＣＨ７０は、呼がリダイレクトされたことおよび呼がリダイレクトされる対応の宛先アドレスを、発呼側に通知する。
その後、ＣＨ７０は、新しい宛先アドレスに対し、新しい呼の確立を始める。新しい呼の確立に関する設定メッセージ９０は、他の必要な情報エレメントと共に、divertingLegInformation2.inv ＡＤＰＵを含んでいる。
発呼側は、接続メッセージ９２中のdivertingLegInformation3.inv ＡＤＰＵを受け取ると、メッセージ中の追加の情報エレメントが課されたどの条件をも満たしている場合、リダイレクトが成功したことを知る。
次に、ＦＨ７６で起きる動作について説明する。（ＰＭＡを介して）移動被呼側から内部登録を受け取ると、ＦＨ７６は、設定メッセージ８２でactiveDiversionQ.inv ＡＰＤＵをＰＨ７４に送る。「内部メッセージ」は遠隔端末から受け取るのではなく、ユーザの動作によってローカルに得られる。activeDiversionQ情報エレメントは、移動被呼側のＩＤ、アクセス・パスワード、現在の宛先アドレス、所望の選別フィールド、および他のエレメントを含んでいる。ＰＨ７４から接続メッセージ８４中のactiveDiversionQ.rr ＡＰＤＵを受け取ると、移動被呼側７６は、登録が成功したことを知る。その後、ＦＨ７６は、解放完了メッセージ８５を用いて、ＰＨ７４との呼を終了させる。
（また、ＰＭＡを介して）移動被呼側から、内部登録解除要求を受け取ると、ＦＨ７６は、設定メッセージ９６中のdeactiveDiversionQ.inv ＡＰＤＵを、ＰＨ７４に送る。deactiveDiversionQ情報エレメントは、再度、移動被呼側のＩＤ、アクセス・パスワード、現在の宛先アドレス、および他のエレメントを含む。ＰＨ７４から接続メッセージ９８中のdeactiveDiversionQ.rr ＡＰＤＵを受け取ると、移動被呼側は、登録解除が成功したことを知る。ＦＨ７６は、解放完了メッセージ９９を用いて、ＰＨ７４との呼を終了させる。
設定メッセージ９０中のdivertingLegInformation2.inv ＡＰＤＵを受け取ると、ＦＨ７６は、ＣＨ７０からの入力情報について移動被呼側に通知する。それに対して、ＦＨ７６は、接続メッセージ９２でdivertingLegInformation3.rr ＡＰＤＵをＣＨ７０に返送する。DivertingLegInformation3は宛先アドレスを示し、また、他のエレメントに加えて、ＣＨ７０上の発呼側にその提供が制限されているかどうかを示す。
図６と図７は、本発明の第２の実施の形態の端末移動を説明する図である。また、前述のプロトコルと標準に対する特定の実施の形態については、図８と図９を用いて説明する。端末移動は、通常ホーム・アドレスの端末に接続されたポータブル・コンピュータであり、そのポータブル・コンピュータを新しい場所に移動させ、そこに接続し、元々ホーム・アドレスに送られたマルチメディア呼を新しい位置で受け取ることができる被呼側の能力を有する。まず、いくつかの新しい用語について定義する。パーソナル移動に関して先に定義された用語については、ここでも同じであるので、ここでは繰り返さない。
ハードウエア・アドレスは、４８ビットのアドレスであり、イーサネットに接続されたホストのネットワーク・インタフェースを識別する。
ＭＨ（移動ホスト）は、ネットワークまたはサブネットワークであるポイントから他のポイントへ接続ポイントを変更するパーソナル・ホストである。
ＳＨ（シャドー・ホスト）は、被呼側がそのＭＨを移動したとき、移動被呼側に送られた呼を傍受してリダイレクトするために、ＭＨのホーム・ネットワークに接続されたままでいる静止ホストである。以下に詳しく述べるように、被呼側は、ホーム・ネットワーク上のどの静止ホストを選んで自己のＳＨとしてもよい。
ＡＲＰ（アドレス決定プロトコル）は、ＩＰアドレスをホストのハードウエア・アドレスに拘束するネットワーク・インタフェース・レイヤ・プロトコルを指す。無料のＡＲＰメッセージは、ホーム・ネットワークに接続されたすべてのホストのＡＲＰキャッシュを更新するローカル放送メッセージであり、メッセージ中の所望のＩＰアドレスおよびメッセージを放送するホストのハードウエア・アドレス間の拘束を反映する。
パケット・ハンドラは、ＳＨ上にあるソフトウェアの一部で、被呼側のホーム・アドレスに向けられた入力パケットを傍受し、処理する。パケット・ハンドラは、この目的のために、ＳＨのＩＰスタックとインタフェースする。また、呼リダイレクタ１８は、無料ＡＲＰメッセージを開始するために、パケット・ハンドラをトリガする。
ＩＰベースのネットワークにおいては、ＩＰエイリアシングとして知られる技術は、シャドウ・ホスト端末の１つの物理インタフェース／ポートが、２以上のＩＰアドレスに応答することを可能にさせる。その１つは、端末自身のＩＰアドレスであり、他は、１以上のＩＰエイリアス・アドレスである。ＩＰエイリアシングは、１つの物理的ポートに対し、複数のＩＰアドレスを割り当てるオペレーティング・システム特定ソフトウェアをインストールすることによって行ってもよい。各ＩＰエイリアス・アドレスに向けられたパケットは、個々のサーバ・プロセスによって処理されてもよい。ＩＰエイリアシングは、ホーム・アドレスを、付加的なＩＰエイリアス・アドレスとしてＳＨの物理ポートに割り当てるために用いられる。
ＴＭＡ（端末移動アプリケーション）は、端末移動を実行するために必要なメッセージの処理ができる基本サービスの特別版であるソフトウェアの一部である。ＴＭＡは、ＳＨ、ＭＨ、ＣＨ上にインストールされ、機能的には、前述のＰＭＡに似ている。
端末移動は、被呼側となり、自己のＭＨに沿って、外部ネットワークに移動し、なお自己のパーソナル通信サービスにアクセスできる能力が与えられる。本発明は、アプリケーションレイヤ端末移動サービス機能に関する。この機能は、上述のリダイレクト・シグナリング手順を使い、元々被呼側のホーム・アドレスに向けられていた音声、データまたはビデオ呼を、外部ネットワーク上にある現在の被呼側の宛先アドレスにリダイレクトする。その手順は、ＳＨ内にある呼リダイレクタ機能コンポーネントによって実行される。ＳＨはホーム・ネットワークに接続されるが、被呼側のＭＨはＩＰベースのネットワーク内のホーム・ネットワーク以外のサブネットワークに接続される。
ＳＨ１２２上の呼リダイレクタ１８を起動させた後、いったんＭＨがホーム・ネットワークから移動すると、ＭＨのホーム・アドレスのＳＨのハードウエア・アドレスに拘束するために、ＳＨはホーム・ネットワーク上に無料のＡＲＰメッセージを放送する。この機能は、被呼側のホーム・アドレスに向けられた呼に対する元々の呼シグナリングをＳＨが扱うことを同一ホーム・ネットワーク上のホスト／ルータに知らせる。ＳＨ（パケット・ハンドラを有する）は、その後、ホーム・アドレスに向けられたすべての呼要求パケットを傍受し、ＳＨ上の呼リダイレクタに処理の通知を行う。次に、呼リダイレクタは、発呼側に、外部ネットワーク上の被呼側の宛先アドレスを提供する。被呼側は、呼要求を、被呼側の宛先アドレスに直接送ることによって、移動被呼側と接触する。ここで、端末移動を達成するためのシグナリング手順は、発呼側と被呼側の両方に対しトランスペアレントである。
本発明のこの実施の形態は、エンド・ユーザに、自己のＭＨを取り外し、複数のサブネットワークをローミングする新しい機会を提供する。一方、マルチメディア呼を送受することはまだ可能である。また、本実施の形態は、柔軟（いつでも、どこからでも、エンド・ユーザのパーソナル通信サービスをアクセスできるという意味）で、信頼性の高い（呼シグナリングおよび呼パスは、ワイヤ線のイントラネット／インターネットを介するため）アプリケーション・レイヤサービス機能を提供する。このサービス機能は、適切なインタフェースを介して、新しいマルチメディア基本サービスに統合される。
被呼側は、自己のホーム・ネットワーク上で任意のホストを選んで、ＳＨとして使う。被呼側は、呼リダイレクタとパケット・ハンドラが、ローミングをする前に選択されたＳＨにインストールされるのを確認しさえずればよい。その後、被呼側は、自己のパーソナル呼が、ローカルか遠隔かのどちらかでＳＨ上に呼リダイレクタを構成することによってリダイレクトされるべき宛先アドレスを（任意の好ましい基準に基づいて）特定する。
図６は、ホーム・ネットワーク７２上にホーム・アドレス１２０を有するＭＨを有する被呼側を例示する。このＭＨは実際にはそのホーム・アドレスに接続されていないことが示されている。ＣＨ７０は同じホーム・ネットワーク７２に接続されている。同じホーム・ネットワーク７２上の他の端末は、ＳＨ１２２と表わされており、呼リダイレクタ機能コンポーネント１８および上述のパケット・ハンドラの機能も備えている。被呼側のＭＨ１２４は、外部ネットワーク７７に接続され、ＳＨ１２２に登録される宛先アドレスを有している。
図７は、ＩＰベースのイントラネット／インターネット環境における本発明の端末移動の実行を含むステップを示す。１３０から１６０までの信号の流れは、ホーム・アドレス１２０に接続されているときのＭＨ、ＣＨ７０、外部ネットワーク７７に接続されているときのＭＨ、およびＳＨ１２２の間におけるシグナリングまたはメッセージの流れを表している。
被呼側のＭＨがホーム・ネットワーク７２中のホーム・アドレス１２０に接続されているときは、ＳＨ１２２内の呼リダイレクタ１８は起動されていない（すなわち、被呼側は移動サービス無しに動作する）。
元々ホーム・ネットワーク７２に接続された被呼側が自己のＭＨに沿って移動することを決定すると、その被呼側は、起動要求１３０をＳＨに送ることによって、ＳＨ１２２内で呼リダイレクタ１８を起動させる。ＳＨ１２２の基本サービスは、起動要求１３０を受け取り、呼リダイレクタ１８を起動させる。ユーザがＳＨ１２２と物理的にインタフェースする必要はない。そのときに、第三者がＳＨ１２２を使用いていれば、彼らに割り込んで、呼リダイレクタ１８が起動されているという事実を知らせる必要はない。起動要求１３０に応じて、呼リダイレクタ１８は、起動応答１３２をＭＨに送り、呼リダイレクタ１８が起動したことを確認する。被呼側は、このメッセージを受け取ると、ホーム・アドレス１２０から、自己のＭＨを安全に切り離す。ＳＨ１２２は、被呼側が移動している間、移動被呼側からの登録要求および被呼側のホーム・アドレスに向けられたすべての呼設定要求の両方を処理するように準備する。
その後、呼リダイレクタ１８は、パケット・ハンドラをトリガし、無料ＡＲＰ放送メッセージ１３４をホーム・ネットワーク上に放送し、被呼側のホーム・アドレスをＳＨのハードウエア・アドレスに拘束する。それによって、ＳＨ１２２は、被呼側が移動している間、被呼側のホーム・アドレス１２０に向けられたすべての呼設定要求を傍受し処理する。放送メッセージ１３４は、ホーム・ネットワーク７２に接続された各ホスト上のＡＲＰキャッシュを自動的に更新して、拘束を反映させる。この放送メッセージ１３４は、信頼性を増すために、少なくとも３回は繰り返されることが望ましい。その後、ＳＨ１２２は、ＭＨを擬制する。
被呼側が、自己のＭＨ１２４を一度外部ネットワーク７７に接続すると、被呼側は、基本サービスによって提供される登録ＧＵＩを用いて、自己の宛先アドレスをＳＨ１２２に登録する。登録は、登録要求メッセージ１３６と登録応答メッセージ１３８との交換によって行われる。
宛先アドレスは、外部ネットワーク７７に接続された動的ホスト構成プロトコル（ＤＨＣＰ）ホスト（図示せず）によって、自動的に、被呼側のＭＨ１２４に割り当てられる。
ＭＨ１２４が移動中で、どのネットワークにも接続されていない間、ＳＨは、例えば、ＭＨ１２４に対して傍受された呼を、マルチメディア音声メール・サーバのような補助的呼処理プラットフォームに送るように構成してもよい。
ＣＨ７０によって、被呼側のホーム・アドレスに送られた呼設定要求１４０は、ＳＨ１２２によって傍受され、処理のために呼リダイレクタ１８に渡される。呼リダイレクタ１８は、ＣＨ７０に呼設定応答１４２を開始し、移動被呼側に到着される新しい宛先アドレスを示す。ＣＨ７０はこの宛先アドレスを用いて、直接被呼側の宛先アドレスに対し、呼設定要求１４４を開始する。この時点で、マルチメディア呼の確立のために要求された設定シグナリング・ステップは完了する。その後、前述の従来の付加的ステップ（交渉、媒体チャネル確立など）が行われて、ＣＨ７０とＭＨ１２４間で音声通信１４８のようなメディア・ストリーム接続が行われる。
移動被呼側は、出力呼の開始を決定すると、呼設定要求は、標準ＩＰルーティング・メッセージを用いて、ＭＨから宛先ＩＰアドレスに直接送られる。
移動サービスが要求されなくなると、移動被呼側は、基本サービスによって提供された登録ＧＵＩを用いて、ＳＨ１２２に元々ファイルされていた自己の現在の宛先アドレスの登録を解除する。登録解除は、登録解除要求メッセージ１５０と登録解除応答メッセージ１５２とを交換することによって行われる。
移動被呼側が、異なる外部ネットワークに移動すると、被呼側は、他の登録要求と登録応答メッセージを交換することによって、自己の新しい宛先アドレスを、ＳＨ１２２に再登録する。この再登録に続き、ＳＨ１２２に登録されている古い宛先アドレスは、新しい宛先アドレスによって上書きされる（登録解除をしないで、被呼側が新しい外部ネットワークに移動した場合）。
移動被呼側がホームに戻り、自己のＭＨをホーム・ネットワーク７２に接続すると、被呼側のＭＨは、（ブートストラッピングをしている間）、無料ＡＲＰメッセージ１５４を送って、被呼側のホーム・アドレス１２０を、ＭＨのアドレス自身に拘束する。その後、被呼側は、ＳＨ１２２上の呼リダイレクタ１８を停止し、停止要求メッセージ１５６と停止応答メッセージ１５８とを交換することによって、端末移動サービスを中止する。
呼リダイレクタ１８が停止した後、呼リダイレクタ１８はパケット・ハンドラをトリガし、ホーム・ネットワーク上に無料ＡＲＰ放送１６０を送って、ＳＨのＩＰアドレスを、ＳＨのハードウエア・アドレスに戻す。この放送は、信頼性を高めるために、少なくとも３回繰り返される。被呼側のホーム・アドレス１２０に向けられたすべての呼設定要求は、ＳＨ１２２によってもはや傍受されることはない。
本発明による端末移動の特定の実現の一例を、パーソナル移動に対して前述したと同じ内容で、図８と図９を用いて説明する。
この明細書では、ＴＭＡはＱＳＩＧメッセージの情報エレメントを処理できるアプリケーション・ソフトウェアの一部である。前述したように、ＴＭＡは、ＳＨ１２２、ＭＨ１２４、ＣＨ７０にインストールされなけれならない。公知のポート番号は、ＴＭＡポートと呼ばれ、ＴＭＡへ情報エレメントを分配し、ＴＭＡから情報エレメントを受け取るために用いられる。ＴＭＡは、それ自身、ソフトウェアのスタンドアロン部分であるか、または発呼側／被呼側に、音声、データまたはビデオ呼を、ＩＰネットワークを介して送信／受信させるマルチメディア基本サービス・アプリケーションの部分を形成する。ＴＭＡは、パケット・ハンドラ機能コンポーネントと呼リダイレクタ機能コンポーネントとを含む。呼リダイレクタ１８は、移動被呼側のホーム・アドレスに向けられたすべてのまたは特定の入力呼（光選別処理の後の）が、発呼側にリダイレクトされるようにし、その後、被呼側のＭＨにリダイレクトされるようにする。リダイレクトされた呼は、移動被呼側が現在位置している宛先アドレスを運ぶ。このため、呼リダイレクタ１８は、パーソナル移動の実施の形態において先に説明されたように、登録ルックアップ・テーブルを維持する。被呼側は、外部ネットワーク７７に移動する前に、ＳＨ１２２上にインストールされた呼リダイレクタ１８を、遠隔的に起動する。
ＴＭＡは、パーソナル移動についての実施の形態中でＰＭＡに関して上述したように、ＱＳＩＧメッセージの情報エレメントを処理できるように作られている。ＴＭＡは、また、今はＱＳＩＧに存在していないが、本発明において新たに提供された新しいエレメントである以下の情報エレメントの処理もできる。
・activeCR.inv：ＳＨ内で、呼リダイレクタ１８を起動するのに使われる。
・activeCR.rr：呼リダイレクタ１８を起動した結果を確認するために使われる。
・deactiveCR.inv：ＳＨ内で、呼リダイレクタ１８を停止するために使われる。
・deactiveCR.rr：呼リダイレクタ１８を停止した結果を確認するために使われる。
ＴＭＡは、以下の情報エレメントを、処理のために呼リダイレクタ１８に渡す。その情報エレメントとは、activeDiversionQ.inv、activeDiversionQ.rr、deactiveDiversionQ.inv、deactiveDiversionQ.rrであり、これらは、ＰＭＡが呼リダイレクタ１８に渡す同じ情報エレメントである。
図８と図９は、両方とも図７に類似しているが、図８と図９には、特定のＱＳＩＧ／Ｈ．３２３環境の各ステップを実行するために必要な特定のメッセージ・タイプが識別される。図８と図９の信号の流れのうち、図７の信号に相当する特定の機能と等価なものは、図７と同じ参照番号で表されている。
ＭＨ１２４，ＣＨ７０，ＳＨ１２２で起きる各動作について説明する。最初にＳＨ１２２に関し、ＳＨ上の呼リダイレクタ機能コンポーネントが起動している間、また停止している間に起こる動作について説明する。
設定メッセージ１３０内でactiveCR.inv ＡＰＤＵを受け取ったとき、ＳＨ１２２上のＴＭＡは、メッセージ中で受信された情報エレメントについて、特に、発呼側ＩＤエレメントとパスワード・エレメントについて調査し、これらの信頼性を確認する。信頼性が確認できれば、ＴＭＡはＳＨ１２２内の呼リダイレクタ１８を起動させる。その後、ＴＭＡは、接続メッセージ１３２内のactiveCR.rr ＡＰＤＵをＭＨ１２４に送る。移動被呼側は、このとき、ホーム・ネットワーク７２上のホーム・アドレス１２０に接続されたＭＨ１２４を有している。ＭＨから解放完了メッセージ１３３を受け取ると、呼リダイレクタ１８は、移動被呼側のホーム・アドレス１２０に向けられたすべてのパケットを傍受して処理するために、パケット・ハンドラを起動する。いったん起動すると、ＳＨ上の呼リダイレクタ１８は、上述のパーソナル移動に関する実施の形態における登録／登録解除に関する情報エレメントを処理するＰＨ７４と同じ方法で、同じＱＳＩＧコマンドを用いて、登録／登録解除に関する情報エレメントを処理する。これについては、説明を省略する。
いったん、ＳＨ内の呼リダイレクタ１８が起動すると、ＳＨ１２２によって順次受け取られたすべての設定メッセージ中の情報エレメントは、ＴＭＡによって調べられる。もし受け取られた情報エレメントが、activeCRでもdeactiveCRでもなく、また、activeDiversionQでもdeactiveDiversionQでもない場合、呼リダイレクタ１８は、登録ルックアップ・テーブルに助言を求める。もし移動被呼側がすでに現在の宛先アドレスを登録していたら、呼リダイレクタ１８は、いくつかのローカル呼選別技術を用いて、発呼側に、移動被呼側の宛先アドレスを与えるかどうかを判断する。テーブル入力の宛先アドレスに関する選別フィールドは、この目的のために用いられる。発呼側が選別されると、ＳＨ１２２は、装置メッセージ１４２中でcallRerouting.inv ＡＰＤＵを送る。callRerouting情報エレメントは、他のエレメントと共に、移動被呼側の現在の宛先アドレスを含む。その後、ＳＨ１２２は、解放完了メッセージ１４３中でcallRerouting.rr ＡＰＤＵを受け取り、宛先アドレスの受領を確認する。
次に、ＣＨ７０で起こる動作について説明する。移動被呼側に発呼したいと思っている発呼側は、設定メッセージ１４０を、移動被呼側のホーム・アドレスに送る。発呼側は、移動被呼側に対して最小の呼を確立している間は、移動被呼側の現在位置には気づかない。ＳＨ１２２から、機能メッセージ１４２中で（移動被呼側の現在宛先アドレスを含む）callRerouting.inv ＡＰＤＵを受け取ると、ＣＨ７０は、解放完了メッセージ１４３中でcallRerouting.rr ＡＰＤＵを送る。ＣＨ７０によって送られた解放完了メッセージは、また、ＳＨ１２２との呼を終了させる。ＣＨ７０は、適宜に、呼がリダイレクトされたことを発呼側に知らせ、callRerouting.inv ＡＰＤＵ１４２で受け取られた限定エレメントがそのようにすることを許可した場合、呼がリダイレクトされるべき対応宛先アドレスを示す。
いったん、発呼側に通知されると、ＣＨ７０は、新しい宛先アドレスに対して新しい呼の確立を開始する。新しい呼の確立に対する設定メッセージ１４４は、他の必要な情報エレメントと共に、divertingLegInformation2.inv ＡＰＤＵを含む。
接続メッセージ１４６中でdivertingLegInformation3.rr ＡＰＤＵを受け取ると、発呼側は、メッセージ中の付加の情報エレメントがそのようにすることを許可した場合、リダイレクトが成功したことを知る。
次に、ホーム・アドレス１２０に接続されているときおよび外部ネットワーク７７内の遠隔位置に接続されているときの両方の場合に、ＭＨ１２４で起こる動作について説明する。（ＴＭＡを介して）移動被呼側から、内部（イントラ・ノード）起動要求を受け取ると、ＭＨは、設定メッセージ１３０中のactiveCR.inv ＡＰＤＵを、ＳＨ１２２に送る。activeCR情報エレメントは、移動被呼側のＩＤ、アクセス・パスワード、および他のエレメントを含む。ＳＨ１２２から、接続メッセージ１３２中でactiveCR.rr ＡＰＤＵを受け取ると、移動被呼側は、ＳＨ内で呼リダイレクタ１８の起動が成功したことを知る。ＭＨ１２０は、解放完了メッセージ１３３を用いて、ＳＨ１２２との呼を終了させる。移動被呼側は、ＭＨと共に、外部ネットワークに移動してもよい。
（ＴＭＡを介して）、移動被呼側から、内部（イントラ・ノード）の停止要求を受け取ると、ＭＨは、設定メッセージ１５６中でdeactiveCR.inv ＡＰＤＵをＳＨ１２２に送る。deactiveCR情報エレメントは、再び、移動被呼側のＩＤ、アクセス・パスワード、および他のエレメントを含む。ＳＨ１２２から、接続メッセージ１５８中でdeactiveCR.rr ＡＰＤＵを受け取ると、移動被呼側は、呼リダイレクタ１８の停止が成功したことを知る。その後、ＭＨは、解放完了メッセージ１５９を用いてＳＨ１２２との呼を終了する。移動被呼側のホーム・アドレス１２０に向けられたすべてのパケットは、もはやＳＨによって傍受されることはない。
ここで、ＭＨ１２４は、外部ネットワーク７７に再接続されていると仮定する。いったん（ＴＭＡを介して）移動被呼側から、内部登録要求を受け取ると、ＭＨ１２４は、設定メッセージ１３６中のactiveDiversionQ.inv ＡＰＤＵをＳＨ１２２に送る。ＳＨ１２２から、接続メッセージ１３８中のactiveDiversionQ.rr ＡＰＤＵを受け取ると、移動被呼側は、登録が成功したことを知る。その後、ＭＨ１２４は、解放完了メッセージ１３９を用いて、ＳＨ１２２との呼を終了させる。
（ＴＭＡを介して）移動被呼側から、内部停止要求を受け取ると、ＭＨ１２４は、設定メッセージ１５０中のdeactiveDiversionQ.inv ＡＰＤＵを、ＳＨ１２２に送る。ＳＨ１２２から、接続メッセージ１５２中のdeactiveDiversionQ.rr ＡＰＤＵを受け取ると、移動被呼側は、登録解除が成功したことを知る。ＭＨ１２４は、解放完了メッセージ１５３を用いて、ＳＨ１２２との呼を終了させる。
設定メッセージ１４４中のdivertingLegInformation2.inv ＡＰＤＵを受け取ると、ＭＨ１２４は、ＣＨ７０からの入力呼に関して、移動被呼側に通知する。次に、ＭＨ１２４は、接続メッセージ１４６中のdivertingLegInformation3.rr ＡＰＤＵを、ＣＨ７０に戻す。divertingLegInformation3は、宛先アドレスを示し、他のエレメントに加えて、ＣＨ７０上の発呼側へのその表示が制限されているかどうかを示す。
ＭＨ１２４は、外部ネットワーク７７上の動的ホスト構成プロトコル（ＤＨＣＰ）ホストによって自動的に割り当てられた宛先アドレスであってもよい。
本発明の第３の実施の形態について、図１０，図１１，図１２を用いて説明する。第３の実施の形態は、呼分配方法のシリーズを提供する。
以下に示す呼分配の問題解決方法は、呼を受信するための特定ピアの選択が、ピア演算装置間の通信を介して行われるために、独自のものとなっている。従来の呼分配方法では、状態についての知識と各クライアントの履歴を用いて、呼を受信したり、その呼を多くのクライアントの一つに送信するサーバ装置が必要である。さらに、呼は、そのサーバを介してクライアントに送られる。このため、管理できる呼の数は、エージェントの数とサーバの容量の両方で決まる。
最初の要求を受け取る演算装置は、その呼を扱う演算装置へパケットを送出することができる。このような解決方法は、今日の音声交換ネットワークで提示されているサーバークライアント解決方法と類似している。しかしながら、この解決方法は、２つの好ましくない結果をもたらす。
１）サーバがボトルネックになる。あらゆる媒体のストリーム・パケットが、そこを通る。クライアントの数が増加すれば、サーバに対する帯域も広げなければならない。実際にはピア演算装置の１つである協動演算装置が、呼シグナリング・パケットのみを受信するため、本発明は、この問題を回避できる。この問題は、一旦、呼設定が完結すると生起する大量の媒体ストリーム・パケットには生じない。
２）クライアントにパケットを送出する動作には、時間がかかる。遅延は、パケット電話技術にとって重大な問題である。中継、つまりサーバのリダイレクトが意味するところは、パケットの移動時間は、そのパケットのルーティングをするサーバの取り扱いによっては増大しない、ということである。
なお、パケット電話技術では、発呼側が、その呼を実際に取り扱うエージェント端末に接続される前に、発呼端末と受信端末との間において、媒体ストリーム接続が既に確立されているかどうかによって、呼分配方法を異なったものにできる。媒体ストリームを受信することは、発呼端末と受信端末との間で、媒体ストリーム接続が既に確立されていることを意味する。本発明は、メッセージ・シーケンスを少し修正するだけで、いずれの方法もサポートできる。いずれの場合も、発呼端末と受信端末との間で呼シグナリング・チャネルが設定される。変形例として、媒体ストリーム接続が確立された場合に呼転送メッセージを使用するものに対して、確立される媒体ストリーム接続がないときに呼リダイレクト・メッセージを使用するものがあり、その場合、発呼端末と受信端末との間には、呼シグナリング接続のみが確立される。
図１０は、本発明の実施の形態に係る呼分配を実行するためのネットワークを概略的に例示する図である。同図には、外部ネットワーク７７に接続された発呼端末すなわちＣＨ７０、ホーム・ネットワーク７２に接続され、呼の再振り向け機能要素を備えた受信端末とも呼ばれるＣＲＤＴ（呼受信および分配端末）２００、そして、４つのエージェント端末２００，２０２，２０４，２０６が示されている。これらの端末の内、３つはホーム・ネットワーク７２に接続され、残りの１つは、外部ネットワーク７７に接続されている。この外部ネットワーク７７は、エージェント端末２０６のホーム・ネットワークとなる。ＣＲＤＴ２００とエージェント端末２００は、物理的には同じ装置であるため、同じ参照番号が付されているが、別々の装置として動作させてもよい。ＣＲＤＴ２００とエージェント端末２００，２０２，２０４，２０６は、呼設定と呼終了に直接関係しない情報メッセージを、これらの装置間で送受信するメッセージ機能を有する。いずれの場合でも、これらのメッセージは「情報メッセージ」と呼ばれる。
ＣＨ７０、エージェント端末２００，２０２，２０４，２０６がホーム・ネットワーク７２と外部ネットワーク７７に接続されているとした特定の方法は、単なる例示である。もっと一般的には、多数のホーム・ネットワークが、より大きいネットワークのサブネットワークとして、ルータを介してひとまとめに接続するようにしてもよいし、または、より大きいネットワークの端部に接続されたネットワークとして、ルータを介してひとまとめに接続するようにしてもよい。より大きいネットワークとは、例えば、公衆インターネットである。これらの装置各々は、それぞれの異なるホーム・ネットワークまたはサブネットワークに接続されるようにしてもよい。異なるホーム・ネットワークを用いる場合、それらが、異なるネットワークに接続された装置間でマルチメディア呼が生起されるような方法で接続されることのみが要求される。
発呼端末７０とＣＲＤＴ２００との間で、媒体ストリーム接続が確立されない場合の呼分配についてまず説明する。発呼端末７０、ＣＲＤＴ２００、およびエージェント端末２００，２０２，２０４，２０６の役割について説明する。エージェント端末２００，２０２，２０４，２０６の中から特定した１つを端末Ｘと呼ぶ。
発呼端末７０は、呼設定要求を「ヘルプ・デスク」に送り、リダイレクト・メッセージを受け取って、その呼を端末Ｘに送り、呼設定要求を端末Ｘに送り、この端末Ｘから接続メッセージを受け取り、端末Ｘに応答して媒体ストリーム接続が確立されるようにし、そして、切断メッセージをＣＲＤＴ２００に送る。
ＣＲＤＴ２００は、発呼端末７０から設定要求を受け取り、呼分配論理を実行し、呼が端末Ｘにリダイレクトされつつあるという情報メッセージを送り、リダイレクト・メッセージを発呼端末に送り、発呼端末７０からの切断メッセージを受け取る。
端末Ｘは、呼が端末にリダイレクトされつつあるという情報メッセージを受け取り、他の情報メッセージと共に、その情報メッセージを確認し、発呼端末７０から設定要求を受け取り、設定応答を発呼端末に送って、媒介ストリーム・パスが確立される。
メッセージ・シーケンスをまとめると、以下の表のようになる。
0003892486.tif 000002
呼分配論理は、ＣＲＤＴ上で実行され、呼が提供される、すなわち、呼の方向付けがなされる端末を選択する。例えば、ハント・グループ論理やＡＣＤ（自動呼分配）論理を含む、特定の論理によって、今日の音声交換ネットワークによって、現在、サポートされている多くの分配形態をエミュレートできる。
ハント・グループ呼分配論理は、巡回や最長のアイドル状態を含む複数の基準に従って、呼を１つの端末に送る。巡回という基準によって、呼の受信の意志表示をした全ての端末が、リストに記入される。続く各々の呼が、リスト上で次に使用できる端末に送られる。最長のアイドル状態という基準によって、この論理は、アイドル状態が最長の端末に呼を送る。この論理の意味するところは、ハント・グループの各端末が、分配端末が空いているときに通知を行い、その情報は、利用可能な端末のリストに記録される、ということである。
ＡＣＤ論理は、ハント・グループ論理よりもさらに複雑である。ＡＣＤ論理は、各端末に登録されたエージェントの能力に従って、受信端末をサブ・グループに編成することができる。よって、各々の呼は、解析されて、発呼側のアドレスのような、いくつかの基準に従って、特定のサブグループに送られる。
呼分配論理は、「エージェント・ベース」、または「発呼側ベース」の論理である。「エージェント・ベース」の呼分配によって、ＣＲＤＴ２００は、端末Ｘが発呼端末７０に呼設定要求を送るようになっていることを示すリダイレクト・メッセージを端末Ｘに与える。「発呼側ベース」の呼分配によって、ＣＲＤＴ２００は、発呼端末が端末Ｘに呼設定要求を送るようになっていることを示すリダイレクト・メッセージを発呼側に提供する。
図１１を参照して、本発明に係る実施の形態の例を段階的に説明する。この例では、分配器ベースの呼分配論理を用いており、この論理は、各エージェントに呼を提供し、呼の受領を待ってから、どのエージェントが、その呼を受け取るかを決め、続いて、その呼をリダイレクトする。エージェント端末２００，２０２，２０４，２０６各々には、ＡＢＣ社に雇われたエージェントが配置されているものとする。
１）ＣＨ７０の発呼者は、ＡＢＣ社の誰かと話したがっている。これらの者は、呼設定要求メッセージを送ることによって、会社の公のパケット・アドレスに対してパケット音声呼を発する。そのアドレスは、ＣＲＤＴ２００のアドレスであるが、上述したように、演算装置もまた、ＡＢＣ社のエージェントの要求に応える。公のアドレスは、例えば、ヘルプ・デスクのアドレスであってもよい。呼設定要求には、被呼者の名前、この場合は「ヘルプ・デスク」を示すユーザ・ツー・ユーザのデータ・フィールドが含まれる。
２）ＣＲＤＴ２００は、呼設定要求を受け取り、その呼設定要求内の情報を解析して、その接続がＡＢＣ社に対するものであって、特に、エージェント端末２００に配置されたエージェントに対するものではないことを判断する。この判断によって、ＣＲＤＴ２００上にソフトウェアとしてインストールされている呼分配器が起動する。
ＣＲＤＴ２００は、会社のどの職員に、その呼が提供されるべきかを判断する呼分配論理を有している。選ばれた職員には、その呼を表す情報を含む呼提供メッセージが送られる。図１１の説明では、エージェント端末２０２，２０４，２０６各々に配置されたエージェントに、その呼が与えられるものとする。
３）呼提供情報は、各エージェントの端末に表示される。提供を受けたエージェントは誰でも、呼の受け入れを選択できる。受け入れる旨を示すと、これらの者の演算装置は、呼を提供した者、つまり、ＣＲＤＴ２００に呼受領メッセージを送る。各エージェントは、呼を提供されても無視したり、拒絶したりすることもできる。
４）ＣＲＤＴ２００は、ユーザが制御できる時間に、全ての受領メッセージを収集し、その呼分配論理を用いて、エージェント端末から受信した任意の呼受領メッセージに基づいて、どの演算装置に、その呼をリダイレクトするかを判断する。１以上の端末が呼を受け入れるようにし、この場合、どの端末が呼を受けるべきか、という決定がなされなければならない。今日では、このような決定をするための論理アルゴリズムが多数あるが、本開示には、それらは含まれない。この例では、端末２０４のエージェントは、呼受領メッセージを送り、その結果、呼分配器２００は、その呼を端末２０４にリダイレクトする。そして、呼分配器２００は、端末２０４を除く、その提供を受けた全ての装置にメッセージを送って、その提供を取り消す。
５）同時に、端末２０４に肯定応答が送られる。
６）呼のリダイレクトを行うため、呼分配器２００は、最初の発呼側７０にリダイレクト・メッセージを送る。そのメッセージには、その呼を受けるべき者の端末２０４のアドレスが含まれる。
７）発呼側の演算装置は、端末２０４に接続要求を送る。端末２０４は、発呼者名のような、いくつかの属性、または、呼参照ＩＤのようなユーザ・ツー・ユーザ・データ項目をつき合わせて、この接続が、ステップ４で受け入れられたものであることを確認する。
次に、発呼端末と受信端末との間で、媒体ストリーム接続が確立されている場合の呼分配について説明する。発呼端末７０、ＣＲＤＴ２００、およびエージェント端末２００，２０２，２０４，２０６の役割について説明する。上述したように、エージェント端末２００，２０２，２０４，２０６の内、特定の１つを端末Ｘと呼ぶ。
発呼端末は、「ヘルプ・デスク」アドレスに呼設定要求を送り、受信端末から接続メッセージを受け取り、発呼端末と受信端末との間で媒体ストリームを確立し、端末Ｘと識別される受信端末から呼転送メッセージを受け取り、設定要求を端末Ｘに送り、そして、端末Ｘから設定応答メッセージを受け取ることで、媒体ストリーム・パスが確立される。その後、発呼端末は、受信端末に切断メッセージを送る。
受信端末は、発呼端末から「設定要求」メッセージを受け取り、発呼端末に接続メッセージを送り、呼分配論理を実行し、呼が転送されつつあるという情報メッセージを端末Ｘに送り、発呼端末に転送メッセージを送り、発呼端末から切断メッセージを受け取る。
端末Ｘは、呼が、その端末に転送されされつつあるという情報メッセージを受けて、他の情報メッセージと共に、そのメッセージを確認し、発呼端末から設定要求を受け取り、発呼端末に設定応答メッセージを送り、その結果、媒体ストリーム・パスが確立される。
なお、受信端末から端末Ｘへの呼の転送もまた、３者通話サービス、あるいは会議ブリッジを用いることによっても生じる。
メッセージ・シーケンスをまとめると、以下の表のようになる。
0003892486.tif 000003
図１２を参照して、媒体ストリームが確立されず、また、エージェント・ベースの呼分配論理を使って、前にその利用可能性について示したエージェント端末に呼を分配する例を説明する。
１）ＣＨ７０の発呼者は、ＡＢＣ社の誰かと話したがっている。これらの者は、呼設定要求メッセージを送ることによって、会社の公のパケット音声アドレスにパケット音声呼を発する。上述したように、この呼設定要求には、被呼側名、この場合は「ヘルプ・デスク」を含む、ユーザ・ツー・ユーザのデータ・フィールドが含まれる。
２）ＣＲＤＴ２００は、呼設定要求を受け取り、この呼設定要求内の情報を解析して、その接続がＡＢＣ社に対するものであって、特に、エージェント端末２００に配置されたエージェントに対するものではないことを判断する。この判断によって、ＣＲＤＴ２００上にソフトウェアとしてインストールされている呼分配論理が起動する。この呼分配によって、発呼端末７０には、「お待ちください」のメッセージと共に呼設定応答が、あるいは、まもなく接続されることを示す、他のいくつかのメッセージが送られる。このメッセージを受け取ると、発呼端末はＣＲＤＴとの呼を切断する。この発呼者は、自分が他のことをしている間、ＡＢＣ社からのエージェントが補償するのを待つ。
この呼分配論理は、次に、エージェント端末２００，２０２，２０４，２０６の内の１つが、呼設定要求を呼分配器に送るのを待って、そのエージェントの利用可能性を示す。これは、特定のエージェント端末上のエージェントが、先の呼を完了させ、他の呼を受けられるようになったときに起こる。図示した実施の形態では、エージェント端末２０４のエージェントが最初に空きになり、そのエージェントは、利用可能性を示すものを送る。
３）呼分配器は、発呼側のアドレスを持つリダイレクション指示を含んだ呼設定応答を、空いたエージェント端末２０４に送り、この空きエージェント端末２０４の利用可能性の確認もする。これに対して、空きのエージェント端末２０４は、呼分配器２００に呼解放メッセージを送る。
４）空きのエージェント端末２０４は、発呼側の端末７０に呼設定要求を送る。
５）発呼側の端末は、その要求を受け取り、呼設定応答メッセージに応答するので、発呼側の端末と空きのエージェント端末２０４との間に媒体チャネルが確立する。
上述の教示の観点から、本発明についての多くの変形や変更が考えられる。よって、以下のクレームの範囲内において、本発明は、ここに特に記載されたものとは異なる方法で実施できることが分かる。
上述した各例では、「エージェント・ベース」の呼分配論理か、あるいは、「発呼側ベース」の呼分配論理のいずれかを使っている。各例は、呼転送メッセージ（媒体ストリームが、前もって確立されている場合）か、呼リダイレクション・メッセージ（媒体ストリームが、前もって確立されていない場合）のどちらかを用いている。本発明は、例として挙げた特定の順序に限定されるわけではない。さらに、他のタイプの呼分配論理を用いてもよい。
【図１】
0003892486.tif 000004
【図２】
0003892486.tif 000005
【図３】
0003892486.tif 000006
【図６】
0003892486.tif 000007
【図４】
0003892486.tif 000008
【図５】
0003892486.tif 000009
【図７】
0003892486.tif 000010
【図８】
0003892486.tif 000011
【図１０】
0003892486.tif 000012
【図９】
0003892486.tif 000013
【図１１】
0003892486.tif 000014
【図１２】
0003892486.tif 000015