JP2001513962A - パケット・ベース通信網内でのリダイレクト方法 - Google Patents

Abstract

(57)【要約】 本発明は、呼のリダイレクトを用いて、インターネットまたはイントラネットのようなパケット・ベース・ネットワーク中に、パーソナル移動、端末移動および呼分配のようなサービスを提供する方法を開示している。

Description

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

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，Ｍ Ｗ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，Ｅ Ｓ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ，ＩＤ ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ， ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，Ｍ Ｇ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ， ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，Ｙ Ｕ，ＺＷ (72)発明者 フランク・アラン・エス カナダ国，ケイ２ジー ４シー１，オンタ リオ，ネピーン，ウェード コート 11 (72)発明者 テイラー・ポール・トーマス カナダ国，ケイ１エイチ ６ゼット８，オ ンタリオ，オタワ，ローレイン アベニュ ー 1852

Claims (1)

1. 【特許請求の範囲】 １． パケット・ベースの通信ネットワークにホーム・アドレスで接続されたパ ーソナル・ホストを有する被呼側が、宛先アドレスを持つネットワークに接続さ れた外部ホストにおいて、もともと発呼側ホストから前記パーソナル・ホストに 宛てたマルチメディア呼を受信できるようにするパーソナル移動方法において、 ａ）前記パーソナル・ホスト上で動作する呼リダイレクタ・アプリケーション が、前記発呼側ホストからの呼設定要求に対して、前記宛先アドレスを含む呼設 定応答によって応答するステップと、 ｂ）前記発呼側ホストが、前記宛先アドレスにある前記外部ホストに呼設定要 求を送るステップと、 ｃ）前記外部ホストが呼設定応答を送ることで、前記発呼側ホストと外部ホス トとの間にリンクを張るのに要する呼シグナリングを完了するステップとを備え ることを特徴とするパーソナル移動方法。 ２． １）前記被呼側が前記呼リダイレクタ・アプリケーションを起動するステ ップと、 ２）前記被呼側が、前記外部ホストからパーソナル・ホストへの登録要求を介 して、前記呼リダイレクタによって前記宛先アドレスを登録するステップとを実 行して、当該パーソナル移動方法を最初に設定することを特徴とする請求項１記 載のパーソナル移動方法。 ３． 前記パーソナル・ホストが、前記登録要求が首尾よく受信されたことを示 す登録応答を前記外部ホストに送るステップをさらに備えることを特徴とする請 求項２記載のパーソナル移動方法。 ４． 前記呼リダイレクタが起動された後であって、前記被呼側が前記外部ホス トからの前記宛先アドレスを登録する前に、呼が補助の呼ハンドリング・プラッ トフォームに送られることを特徴とする請求項２記載のパーソナル移動方法。 ５． 前記補助の呼ハンドリング・プラットフォームは、マルチメディア音声メ ール・サーバを備えることを特徴とする請求項４記載のパーソナル移動方法。 ６． 前記ステップ１）は、前記被呼側によって、前記パーソナル・ホスト上で 直接、実行されることを特徴とする請求項２記載のパーソナル移動方法。 ７． 前記ステップ１）は、前記外部ホストによって実行されることを特徴とす る請求項２記載のパーソナル移動方法。 ８． 前記登録要求は認証情報を含んでおり、前記パーソナル・ホストは、この 登録要求を正当であるとして受け入れる前に、前記認証情報に対する確認ステッ プを実行することを特徴とする請求項３記載のパーソナル移動方法。 ９． 前記被呼側が前記パーソナル・ホストに戻る場合、前記外部ホストが、こ のパーソナル・ホストに登録解除要求を送り、そして、前記パーソナル・ホスト が、登録解除応答によって、前記登録解除要求に応答するステップをさらに備え ることを特徴とする請求項３記載のパーソナル移動方法。 １０． 前記パーソナル・ホストと外部ホストは、同じホーム・ネットワーク上 、あるいは異なるホーム・ネットワーク上にあることを特徴とする請求項１記載 のパーソナル移動方法。 １１． 通常、パケット・ベースの通信ネットワークにホーム・アドレスで接続 された移動ホストを有する被呼側が、宛先アドレスで接続された移動ホストにお いて、もともと発呼側ホストからパーソナル・ホストに宛てたマルチメディア呼 を受信できるようにする端末移動方法において、 ａ）シャドー・ホスト上で動作する呼リダイレクタ・アプリケーションが、前 記宛先アドレスを含む呼設定応答によって、前記発呼側ホストから前記パーソナ ル・ホストにアドレス指定された呼設定要求を傍受するステップと、 ｂ）前記発呼側ホストが、前記宛先アドレスにある前記移動ホストに呼設定要 求を送るステップと、 ｃ）前記移動ホストが呼設定応答を送ることで、前記発呼側ホストと移動ホス トとの間にリンクを張るのに要する呼シグナリングを完了するステップとを備え ることを特徴とする端末移動方法。 １２． １）前記被呼側が、前記ネットワークに送られた起動要求メッセージに よって、前記シャドー・ホスト上で前記呼リダイレクタ・アプリケーションを起 動するステップと、 ２）前記被呼側が、前記宛先アドレスにおいて接続された移動ホストから前記 パーソナル・ホストへの登録要求を介して、前記呼リダイレクタによって前記宛 先アドレスを登録するステップと を実行して、当該端末移動方法を最初に設定することを特徴とする請求項１１記 載の端末移動方法。 １３． 前記シャドー・ホストが、前記登録要求が首尾よく受信されたことを示 す登録応答を前記移動ホストに送るステップをさらに備えることを特徴とする請 求項１２記載の端末移動方法。 １４． 前記呼リダイレクタが起動された後であって、前記被呼側が前記移動ホ ストからの前記宛先アドレスを登録する前に、呼が補助の呼ハンドリング・プラ ットフォームに送られることを特徴とする請求項１２記載の端末移動方法。 １５． 前記補助の呼ハンドリング・プラットフォームは、マルチメディア音声 メール・サーバを備えることを特徴とする請求項１４記載の端末移動方法。 １６． 前記登録要求は認証情報を含んでおり、前記シャドー・ホストは、この 登録要求を正当であるとして受け入れる前に、前記認証情報に対する確認ステッ プを実行することを特徴とする請求項１３記載の端末移動方法。 １７． 前記被呼側が前記移動ホストをホーム・アドレスに再接続する場合、こ の移動ホストが前記シャドー・ホストに登録解除要求を送り、そして、このシャ ドー・ホストが、登録解除応答によって、前記登録解除要求に応答するステップ をさらに備えることを特徴とする請求項１３記載の端末移動方法。 １８． 前記シャドー・ホストはホーム・ネットワークに接続され、前記移動ホ ストのホーム・アドレスは同一ホーム・ネットワーク上にあり、さらに、前記シ ャドー・ホストが、ＩＰエイリアシング技術を使って、前記移動ホストのホーム ・アドレス宛ての全てのパケットを傍受し、かつ処理するステップを備えること を特徴とする請求項１２記載の端末移動方法。 １９． パケット・ベースの通信ネットワークに接続された複数のピア・コンピ ュータ装置にマルチメディア呼を分配する呼分配方法であって、各コンピュータ 装置はアドレスを持ち、前記ピア・コンピュータ装置の１つはメイン・アドレス を持つと共に呼リダイレクタ・アプリケーションを備える、当該呼分配方法にお いて、 ａ）前記メイン・アドレスを持つ前記コンピュータ装置上で動作する前記呼リ ダイレクタ・アプリケーションが、前記複数のピア・コンピュータ装置の１つの アドレスからなるリダイレト・アドレスを含む呼設定応答によって、前記発呼側 ホストからの呼設定要求に応答するステップと、 ｂ）前記発呼側ホストが、前記リダイレト・アドレスに前記呼設定要求を送る ステップと、 ｃ）前記複数のコンピュータ装置の１つが呼設定応答を送ることで、前記発呼 側ホストと複数のコンピュータ装置の１つとの間にリンクを張るのに要する呼シ グナリングを完了するステップとを備えることを特徴とする呼分配方法。 ２０． 前記呼リダイレクタが、前記複数のコンピュータ装置に、呼を受け入れ る申し出を含むメッセージを送るステップと、 １あるいはそれ以上の前記ピア・コンピュータ装置が、呼受け入れメッセージ によって前記申し出に応答するステップと、 前記呼リダイレクタが、呼受け入れメッセージによって応答した前記ピア・コ ンピュータ装置の１つのアドレスを、転送アドレスとして選択するステップとを さらに備えることを特徴とする請求項１９記載の呼分配方法。 ２１． 前記呼リダイレクタは、どのピア・コンピュータ装置が前記呼を受け取 ることになっているかを自動的に判定することを特徴とする請求項１９記載の呼 分配方法。 ２２． 前記ピア・コンピュータ装置が呼を受け取れる状態にあるとき、これら ピア・コンピュータ装置が、前記呼リダイレクタに利用可能性を示すメッセージ を送るステップをさらに備え、この呼リダイレクタは、利用可能なピア・コンピ ュータ装置のリストを維持して、そのリストに基づいて前記転送アドレスを選択 することを特徴とする請求項２１記載の呼分配方法。 ２３． 前記呼をリダイレクトする前に、前記発呼側ホストと、前記メイン・ア ドレスを持つ前記コンピュータ装置との間に媒体チャネルが確立されることを特 徴とする請求項１９記載の呼分配方法。 ２４． パケット・ベースの通信ネットワークに接続された複数のピア・コンピ ュータ装置にマルチメディア呼を分配する呼分配方法であって、各コンピュータ 装置はアドレスを持ち、前記ピア・コンピュータ装置の１つはメイン・アドレス を持つと共に呼リダイレクタ・アプリケーションを備える、当該呼分配方法にお いて、 ａ）前記メイン・アドレスを持つ前記コンピュータ装置上で動作する前記呼リ ダイレクタ・アプリケーションが、呼設定応答によって、前記発呼側ホストから の呼設定要求に応答するステップと、 ｂ）前記複数のピア・コンピュータ装置の１つが、前記メイン・アドレスを持 つコンピュータ装置に呼設定要求を送って、前記ピア・コンピュータ装置が利用 可能であることを示すステップと、 ｃ）前記メイン・アドレスを持つコンピュータ装置が、前記発呼側ホストのア ドレスを含む呼設定応答によって応答するステップと、 ｄ）前記複数のコンピュータ装置の１つが、前記発呼側ホストに呼設定要求を 送るステップと、 ｅ）前記発呼側ホストが呼設定応答によって応答することで、この発呼側ホス トと、前記複数のコンピュータ装置の１つとの間にリンクを張るのに要する呼シ グナリングを完了するステップと、 ｆ）前記発呼側端末が、前記メイン・アドレスを持つ装置に切断メッセージを 送るステップとを備えることを特徴とする呼分配方法。