JP4433206B2 - コネクションを確立し維持する方法 - Google Patents

Description

本発明は、好ましくはボイスオーバーＩＰ（ＶｏＩＰ）通信用のコネクションを使用するために、少なくとも１つの端末と少なくとも１つの通信サーバとの間にコネクションを確立し維持する方法に関する。ここで端末および通信サーバはネットワークにより相互接続され、コネクションの確立および維持はプロトコルにより制御され、コネクションのパラメータはコンフィグレーションにより設定可能である。

インターネット上の通信がますます重要になっている。伝送レートの上昇およびインターネットアクセスの利用可能性の向上に伴い、インターネットの利用は、かなり前から、テキストのみの送信にはもはや限定されなくなっている。インターネット電話（ボイスオーバーＩＰ、ＶｏＩＰ）やテレビ会議のようなリアルタイム通信システムがますます重要になりつつある。特に、ＶｏＩＰは、もはや企業だけでなく、このような技術を家庭で利用する一般顧客の関心も引きつけている。

従来の電話網と同様、ＶｏＩＰの場合も、呼の確立および音声データの送信という２つの段階を基本的に区別することができる。現在、呼の確立にはセッション開始プロトコル（ＳＩＰ）が用いられ、音声の送信にはリアルタイムプロトコル（ＲＴＰ）が最も広く用いられている。ＳＩＰの仕事は、通信セッション中に複数の参加者間にコネクションを作成することである。インターネットにおいて通信参加者を見つけるだけでなく、個々の参加者間の対応する通信パスを見つけなければならない。通信パスは、通信に必要な個々のサーバおよびノードを含む。ここで、ＩＰデータパケットの場合に一般的なように、ＩＰデータパケットの正確なパスは予測できない。

呼の確立の場合に、ほとんどのネットワーク構造に必要なネットワークアドレストランスレータ（ＮＡＴ）やファイアウォールのようなさまざまなコンポーネントによって、特に問題が生じる。ここで、参加者間でＶｏＩＰパケットおよびシグナリングを安全に交換できるためには、対応する解決手段を見出さなければならない。この場合、例えば、ＳＴＵＮ（Simple Traversal of UDP through NATs）サーバが使用される。

一般に、通信セッションの開始時に、端末は、その端末に割り当てられている通信サーバに登録を行う。例えばＳＩＰの場合、端末はＳＩＰプロキシサーバにＳＩＰプロトコルメッセージを送信する。登録が成功すると（すなわち、有効な認証データ、端末の既知の識別子等の正しい情報の場合）、通信サーバは対応する確認応答メッセージを端末に返送する。これにより通信サーバは、ある決まった期間に対し、どの端末へ、そして（該当する場合には）どのパスで、特定の参加者識別子に対する入呼を送信しなければならないかを知る。登録はエージェントに実行させることができるので、端末のユーザはこれに煩わされない。

登録時にはまず、通信サーバが端末のユーザエージェントによって探索される。このために、ＤＮＳ（ドメインネームサーバ）エントリ、ＤＨＣＰ（動的ホスト構成プロトコル）サーバによって保存されている情報、データベース等の手段が適用可能である。こうして、プロトコルメッセージを、端末に割り当てられた通信サーバへ送信することができる。場合によっては、ＮＡＴまたはファイアウォール越しにプロトコルメッセージを送信するために、ＳＴＵＮサーバに関する情報を使用する必要がある。通信参加者へデータパケットを送信するためには、さらに、その通信参加者がファイアウォールおよび／またはＮＡＴ経由でしか到達できないかどうかを知る必要がある。ファイアウォールおよび／またはＮＡＴ経由でしか到達できない場合には、データ送信時に、対応するリレーサーバを使用することがおそらく必要となる。

ＶｏＩＰ端末のセットアップ時には、ＳＩＰによるコネクション確立の安全な動作のために多くのコンフィグレーション作業が必要であり、これは手動で行わなければならない。コンフィグレーションファイルを調整する必要があり、良くてもグラフィックインタフェースを通じてコンフィグレーションを入力する必要がある。このような作業は、ＶｏＩＰデバイスを新規にインストールする時や、あるネットワーク環境から別のネットワーク環境に移動しなければならない時には必ず行う必要がある。コンフィグレーションには、例えばＳＩＰプロキシサーバのアドレスデータや、ＮＡＴ、ファイアウォール、ＲＴＰサーバあるいは伝送レートに関する情報が含まれる。これに加えて、サービス固有のコンフィグレーション、例えば、利用可能なプレゼンスサーバや到達可能な会議サーバに関する情報も重要となり得る。

コンフィグレーションに関するこれらの作業は煩雑であり、非常に誤りを生じやすい。また、このような情報は通常、平均的ユーザには知られていない。特に、無線ネットワーク、例えばＩＥＥＥ８０２．１１に準拠したＷＬＡＮ（無線ローカルエリアネットワーク）でＶｏＩＰ端末を使用する場合、ＶｏＩＰ端末が動き回る間にコンフィグレーションは絶え間なく変化する。ＶｏＩＰ端末で一般的な手動コンフィグレーションは、このような状況においてはあまり実用的でない。

そこで、本発明は、上記のようなコネクションを確立し維持する方法において、平均的ユーザによって実行可能なできるだけ簡単なコンフィグレーションを実現し、さらに改良するという課題を解決しようとするものである。

本発明によれば、上記の課題は請求項１に記載の特徴を備えた方法によって解決される。これによれば、コネクションを確立し維持する本方法は、コンフィグレーションが自動的に実行され、コネクションのコンフィグレーションのためのコンフィグレーション情報が、標準仕様による既存のプロトコルのメッセージで送信されることを特徴とする。

本発明により初めて認識されたこととして、自動コンフィグレーションは、手動コンフィグレーションの作用を引き継ぐことができる。また、自動コンフィグレーションの場合、追加的なプロトコルは不要である。すなわち、標準仕様により利用可能なメッセージで、端末のコンフィグレーションに必要なコンフィグレーション情報を送信することができる。このコンフィグレーション情報を用いて、最終的に１つ以上の端末あるいは通信参加者とのコネクションをそれぞれ確立するために、端末と、端末に割り当てられた通信サーバとの間のコネクションを確立することができる。よって、ユーザは、コンフィグレーションからほぼ完全に解放されることが可能である。一般に、ユーザは、認証情報やデフォルトで使用する通信サーバのような少数の基本設定を指示しなければならない。しかし、これらは比較的長期間有効であり、再設定の必要はない。

本発明による方法を使用するための前提条件は、端末が既に正しいＩＰコンフィグレーションを有し、通信サーバが原理的に発見可能であることだけである。ＩＰコンフィグレーションは、端末に直接入力しても、ＤＨＣＰサーバから、あるいは当業者に既知の他の任意の方法で取得してもよい。通信サーバを発見するためには、ＤＮＳサーバエントリ、ＤＨＣＰサーバから受信した情報、あるいはその他の当業者に既知の方法が利用可能である。

有利な態様として、自動コンフィグレーションを実行するために上記のプロトコルメッセージを用いることができる。本発明の好ましい実施形態では、本発明による方法がＳＩＰプロトコルとともに適用される。この場合、端末はＳＩＰ電話機を含み、通信サーバはＳＩＰプロキシサーバを含む。本発明による方法は、他のプロトコルと組み合わせて使用することも可能である。単なる一例として、ＩＴＵ−Ｔ標準Ｈ．３２３が挙げられるが、この例に限定されない。

有利な態様として、端末がまず、通信サーバへのコネクションの確立を要求する。このために、端末は、通信サーバへ登録メッセージを送信する。これにより、端末へコンフィグレーション情報を送信するよう求める要求が登録メッセージとともに送信される。この要求は、登録メッセージ内に適当なフラグを実装することによって最も容易に実現可能である。

同様に、既存のコネクションの場合、変更したパラメータへのコネクションの最適化および／または調整が必要なことがある。このような場合、端末は、通信サーバへ適当なプロトコルメッセージを送信し、それにより最新のコンフィグレーション情報を要求することができる。

コンフィグレーション情報の送信を求める要求とともに、端末は、いくつかの基本設定を送信することができる。これには例えば、端末の位置に関する情報、可能な最大データ伝送レート、ＱｏＳ（サービス品質）情報等の情報が挙げられる。こうして送信される情報に基づいて、通信サーバは、コンフィグレーション情報を収集することができる。ここで、コンフィグレーション情報は、通信サーバに既知の情報と、コネクションの確立または維持に必要な情報とからなる。全体として、コンフィグレーション情報は、端末と通信サーバの間のコネクションに必要なすべてのデータを含み得る。

そして、コンフィグレーション情報は、端末の要求に対する確認応答とともにまとめて送信されることが可能である。このために、標準に準拠して適用されるプロトコルで利用可能なプロトコルメッセージを、登録メッセージの確認応答として用いることができる。セキュリティ上の理由から、コンフィグレーション情報を端末へ送信するのは、通信サーバへの登録またはログインが成功した場合に限ることができる。したがって、コンフィグレーション情報を添付することに意味があるのは肯定確認応答メッセージに対してだけであり、否定確認応答メッセージはコンフィグレーション情報を含まない。

特に、既存のコネクションの最適化および／または調整の場合（ただしこの場合に限定されない）、コンフィグレーション情報は、代替コンフィグレーションを含む追加情報によって補完されることが可能である。このような情報には、例えば、使用されている通信サーバの代わりに使用可能な１つまたは複数の代替通信サーバのアドレスを含めることができる。また、可能な代替通信サーバについて、それぞれの通信サーバにとって好ましい、または受容可能なトランスポートプロトコルおよび／またはポート番号のリストを、コンフィグレーション情報に含めることができる。

このような情報を用いると、例えば通信サーバが過負荷の場合、端末と通信サーバの間のコネクションの遅延が大きく、もしくはＱｏＳが悪すぎる場合等、コネクションに対する悪影響がある場合には、代替通信サーバを選択し、代替通信サーバのうちの１つに対して登録を実行することができる。これにより、端末と通信サーバの間のコネクションを絶えず最適化することができる。

端末では、送信されたコンフィグレーション情報が端末のコンフィグレーションに変換され、それに応じて通信サーバへのコネクションが調整される。代替コンフィグレーション情報の場合、端末は、対応する最も適当なコンフィグレーション情報を選択し、ある一定のポリシーに従って端末のコンフィグレーションを調整する。

このようなコネクションの確立および使用可能なコンフィグレーションのネゴシエーションを完全にカプセル化するために、コンフィグレーションは、端末上で実行されるプログラムによって、ユーザによる手動の介入なしで自動的に実行することができる。好ましくは、この作業を実行するためにエージェントが使用される。

通信サーバがコネクションの確立を求める要求に反応しない場合、通信サーバは、選択した方法では到達不能であると仮定することができる。ネットワーク内には、端末に割り当てられた通信サーバの代わりに接続可能な１つまたは複数のリレーサーバが存在する場合がある。通常の通信サーバとは異なり、リレーサーバは、好ましくは、複数のポートを通じて、および／または相異なるトランスポートプロトコルを用いて、到達可能である。これにより、端末は、比較的任意のポートおよび／または比較的任意のトランスポートプロトコルを選択し、それに対応して、通信サーバへの登録を求める要求をリレーサーバへ送信することができる。リレーサーバは、どうすれば要求された通信サーバに到達できるかの情報を有する。リレーサーバは、選択可能なポート、受容されるトランスポートプロトコル、および／または、通信サーバに到達するためのインフラストラクチャに関する情報のような、通信サーバについて知っているデータを用いて、端末の要求を通信サーバに転送することができる。そして、リレーサーバは、通信サーバのコンフィグレーション情報を端末に転送する。

通信サーバへのコネクションが確立できる場合に、２つの端末間で実際にデータ送信が可能であることは一般には保証されない。そこで、確立されたコネクションのコンフィグレーションをテストすることができる追加的メカニズムが提供される。コネクションのコンフィグレーションをテストすることができるメディアテストサーバ等の自動化されたデバイスがネットワーク内で利用可能であることが好ましい。コネクションをテストするためには、まず、端末または端末で実行されるエージェントがメディアテストサーバへのテスト呼出しを開始し、その後、あるビットパターンを再生してメディアテストサーバへ送信する。端末およびメディアテストサーバにはこのビットパターンが既知であることが好ましい。そこで、受信したビットパターンと保存されているビットパターンを比較することにより、コネクションが正しく動作しているかどうかを確認する第１のテストを実行することができる。また、ビットパターンは、人間が理解可能なように設計することができる。

メディアテストサーバは、ビットパターンを正しく受信し、保存されているビットパターンと比較した後、受信したビットパターンまたは保存されているビットパターンを端末へ返送することができる。これにより、端末は、データが正しく転送されたかどうかをチェックすることができる。

別法として、テストは、単に自動的に実行するのではなく、人間のユーザによって直接に開始および／または実行されることも可能である。この場合、ユーザは、自動化されたテストの場合と全く同様にして、好ましくは所定のメッセージを端末に向かって話し、話したメッセージのコピーが戻ってくるのを受信する。これにより、ユーザは、コネクションを自分でテストすることができる。ユーザは、音声シーケンスを誤りなしで受信した場合、対応する確認応答により、テストの成功をメディアテストサーバに通知することができる。

これに加えて、テストが端末またはそのユーザによって起動されるのではなく、メディアテストサーバが対応するテストを開始することも可能である。目的とするテストの種類によっては、これが有効な場合がある。

端末が、設定されたコンフィグレーションを使用することによってメディアテストサーバにアクセスできない場合にも、メディアアクセスサーバに接続するためにリレーサーバを使用することができる。この場合、端末は、メディアテストサーバに直接要求を送信するのではなく、リレーサーバへデータを送信し、これに応じてリレーサーバが、他のトランスポートプロトコル手段によってメディアテストサーバへデータを転送する。

他の端末への移行をできるだけ容易にすること（ポータビリティ）に関して、端末のユーザは、基本設定や、ユーザプロファイル内のその他の情報をユーザプレファレンスとして保存することができる。そして、これらのユーザプレファレンスは通信サーバに保存される。すなわち、ユーザは、複数の端末からこのプレファレンスにアクセスすることができる。

本発明を有利に実施し改良するためのいくつかの選択肢がある。これに関しては、一方で請求項１に従属する請求項を参照し、他方で図面とともに本発明の好ましい実施例に関する以下の説明を参照されたい。本発明の好ましい実施例および図面の説明においては、一般的に好ましい実施形態および改良形態も説明される。

図１〜図３は、ＳＩＰプロトコルの使用例を示し、ＳＩＰを用いたシグナリングのプロセスを明示している。まず、図１は、端末または端末上で実行されるエージェント１と、ＳＩＰプロキシサーバ２との間でどのように情報あるいはメッセージが交換されるかを模式的に示している。

まず、エージェント１が、ＳＩＰプロキシサーバ２へ登録メッセージ「ＲＥＧＩＳＴＥＲ」３を送信する。この登録メッセージ３とともに、エージェント１は、コンフィグレーション情報を作成し送信するよう求める要求をＳＩＰプロキシサーバ２へ送信する。さらに、エージェントは、例えば認証データのような他の情報を送信する。また、登録メッセージ３には、個々のユーザプレファレンスおよび他の必要な設定を添付することができる。別法として、この情報をＳＩＰプロキシサーバ２に保存し、端末の認証が成功した後、これらのユーザプレファレンスに反映させてもよい。

ＳＩＰプロキシサーバ２に利用可能な情報に基づいて、コンフィグレーション情報が作成され、エージェント１に送信される。これを行うため、この場合、確認応答メッセージ「２００ ＯＫ」４がエージェント１に送信される。登録が失敗した場合、コンフィグレーション情報なしで確認応答メッセージ「４０１ ＵＮＡＵＴＨＯＲＩＺＥＤ」が返送される。

図２は、ＳＩＰプロキシサーバ２と、端末上で実行されるエージェント１との間の通信を示す概略図である。これらの２つのデバイスは、インターネット５および内部ネットワーク６を通じて相互接続されている。内部ネットワーク６は、ＳＩＰプロキシサーバ２、ならびにＳＴＵＮサーバ７、メディアリレーサーバ８およびメディアテストサーバ９を備える。ＳＩＰプロキシサーバ２が端末１から直接到達できない場合、ＳＩＰリレーサーバ１０へのトンネリングされたＳＩＰシグナリングコネクション１１が確立される。このパス上で、登録メッセージがまずＳＩＰリレーサーバ１０へ送信され、ＳＩＰリレーサーバ１０が、登録メッセージをＳＩＰプロキシサーバ２によって受容されるデータに変換する。ＳＩＰリレーサーバ１０は、転送された登録メッセージ１２をＳＩＰプロキシサーバ２へ転送し、このパス上に、エージェントとＳＩＰプロキシサーバ２との間のコネクションを確立する。

最後に、図３に、テストプロセスを模式的に示す。原理的に動作するコンフィグレーションが既にエージェント１とＳＩＰプロキシサーバ２の間でネゴシエートされ、このようにして設定されたコネクションを用いてメディアテストサーバ９に到達可能である。

これは、メディアテストサーバがＳＩＰプロキシサーバと同じ内部ネットワーク６に属する場合には保証される。ここで、このコンフィグレーションを用いて、メディアテストサーバ９との間にコネクションが確立され、テスト中にテストを実行するための音声データ１４がエージェント１とメディアテストサーバ９の間で交換される。これにより、ネゴシエートされたコンフィグレーションが実際に動作するかどうかをチェックすることができる。

最後に、特に指摘しておくが、本発明による教示の上記実施例は、全く任意に選択されたものであり、本発明による教示の実例としての役割を果たすに過ぎず、本発明を上記実施例に限定するものでは全くない。

端末と通信サーバの間の信号フローの概略図である。 リレーサーバを通じてのプロトコルメッセージの送信の概略図である。 コネクションをテストする際の通信の概略図である。

符号の説明

１ エージェント
２ ＳＩＰプロキシサーバ
３ 登録メッセージ
４ 確認応答メッセージ
５ インターネット
６ 内部ネットワーク
７ ＳＴＵＮサーバ
８ メディアリレーサーバ
９ メディアテストサーバ
１０ ＳＩＰリレーサーバ
１１ トンネリングされたＳＩＰシグナリングコネクション
１２ 転送されたＳＩＰシグナリング
１３ ＳＩＰシグナリング
１４ テストを実行するための音声データ

Claims (19)

1. 無線ネットワークにおいて使用される少なくとも１つの移動可能な端末が既に正しいＩＰコンフィグレーションを有し、少なくとも１つの通信サーバを発見可能であることを前提とした通信の場合であって、前記端末と前記通信サーバとの間にコネクションを確立し維持する方法において、前記端末および前記通信サーバはネットワークを通じて接続され、前記コネクションの確立および維持はプロトコルにより制御され、前記コネクションのパラメータはコンフィグレーションにより調整可能であり、
   前記端末が動き回る間に絶え間なく変化する前記コンフィグレーションが自動的に実行され、前記コネクションのコンフィグレーションのためのコンフィグレーション情報が、標準仕様による既存のプロトコルのメッセージで送信され、
   前記コンフィグレーション情報が、少なくとも前記端末の位置を含む前記端末の基本設定に基づいて作成されることを特徴とする、コネクションを確立し維持する方法。
2. 前記プロトコルがＳＩＰ（セッション開始プロトコル）プロトコルを含むことを特徴とする請求項１に記載の方法。
3. 前記通信サーバがＳＩＰプロキシサーバを含むことを特徴とする請求項１または２に記載の方法。
4. 前記端末が、前記通信サーバへのコネクションを要求する際にコンフィグレーション情報の送信を要求することを特徴とする請求項１〜３のいずれか１項に記載の方法。
5. 既に確立されたコネクションの場合、変更されたパラメータに該コネクションを最適化し調整するために現在のコンフィグレーション情報が要求されることを特徴とする請求項１〜３のいずれか１項に記載の方法。
6. 前記通信サーバが、前記端末の要求に対する確認応答とともに前記コンフィグレーション情報を送信することを特徴とする請求項１〜５のいずれか１項に記載の方法。
7. 前記コンフィグレーション情報が、前記端末の位置、可能な最大データ伝送レートおよびＱｏＳ（サービス品質）情報を含む前記端末の基本設定に基づいて作成されることを特徴とする請求項１〜６のいずれか１項に記載の方法。
8. 前記コンフィグレーション情報が、前記コネクションを最適化するための代替コンフィグレーションを含む追加的情報を含むことを特徴とする請求項１〜７のいずれか１項に記載の方法。
9. 前記コンフィグレーション情報が、前記端末上で実行されるプログラムによって前記コネクションのコンフィグレーションに変換されることを特徴とする請求項１〜８のいずれか１項に記載の方法。
10. 前記端末上で実行されるプログラムがエージェントを含むことを特徴とする請求項９に記載の方法。
11. 通信サーバに到達不能の場合、前記要求がリレーサーバへ送信されることを特徴とする請求項１〜１０のいずれか１項に記載の方法。
12. 前記リレーサーバが、複数のポートで、および／または相異なるトランスポートプロトコルを用いて到達可能であることを特徴とする請求項１１に記載の方法。
13. 前記リレーサーバが、選択可能なポート、受容されるトランスポートプロトコル、および／または、前記通信サーバに到達するためのインフラストラクチャに関する情報につい
    ての、要求された通信サーバについて前記リレーサーバで知られているデータを用いて、データパケットに対する要求を転送することを特徴とする請求項１１または１２に記載の方法。
14. 前記通信サーバへのコネクションが前記リレーサーバを通じて確立されることを特徴とする請求項１１〜１３のいずれか１項に記載の方法。
15. 確立されたコネクションをテストすることが可能な追加的メカニズムが利用可能であることを特徴とする請求項１〜１４のいずれか１項に記載の方法。
16. 前記テストを実行するために前記ネットワーク内でメディアテストサーバが利用可能であることを特徴とする請求項１５に記載の方法。
17. テストに失敗した場合、前記メディアテストサーバに別のリレーサーバを通じて接続されることを特徴とする請求項１５または１６に記載の方法。
18. 前記コネクションの品質が十分でない場合、それに応じて前記コンフィグレーションが最適化されることを特徴とする請求項１〜１７のいずれか１項に記載の方法。
19. 前記端末の基本設定および／または前記端末のユーザのプレファレンスが前記通信サーバに保存されることを特徴とする請求項１〜１８のいずれか１項に記載の方法。

Images