JP2006094488A - 経路情報に関するストレージ要件の軽減 - Google Patents

Abstract

【課題】プレゼンスサーバの修正をせずにストレージ要件を軽減し、プロキシサーバ及びレジストラなど既存のＳＩＰサーバと同時に使用する技術を提供する。
【解決手段】プロキシノードの通信システムは、ダイアログ中にソースエンドポイントから宛先エンドポイントへ送られるリクエストを受け取り、宛先エンドポイントからソースエンドポイントへのリクエストが、プロキシノードに到着したのちに進む、ノードのパスを示す経路情報を含む。リクエストを受け取った後、プロキシノードは、経路情報へのダイアログのマッピングを生成することができ、プロキシノードは、その経路情報のみを有するリクエストを、宛先エンドポイントに転送する。プロキシノードは宛先エンドポイントからソースエンドポイントへのリクエストを受け取る場合、格納された経路情報をリクエストに追加し、リクエストはソースエンドポイントへの元のリクエストと同じ経路に沿って移動する。
【選択図】図２

Description

本発明はネットワーク上で通信を行なうための方法に関する。

アプリケーションは、コンピューティングデバイス間のセッションを確立し管理することが必要なことがある。セッションは、ある期間にわたり行われるコンピューティングデバイス間の一連の対話である。例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）Ｍｅｓｓｅｎｇｅｒまたはボイスオーバインターネットプロトコル（「ＶｏＩＰ」）などのリアルタイム通信アプリケーションが、ユーザに代わり、通信を行うデバイスの間でセッションを確立する。これらのアプリケーションは、セッションを確立するために、「セッション開始プロトコル（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）」（「ＳＩＰ」）など、様々なメカニズムを使用することができる。ＳＩＰは、デバイスが、互いのデバイスを発見し、デバイス間のセッションの確立、変更、終了を行うために使用することができるアプリケーション層の制御プロトコルである。ＳＩＰは、インターネット提案規格（Ｉｎｔｅｒｎｅｔ ｐｒｏｐｏｓｅｄ ｓｔａｎｄａｒｄ）である。その仕様の「ＲＦＣ３２６１」は、入手可能である（例えば、非特許文献１参照）。ＳＩＰのイベント通知に関する拡張の仕様である「ＲＦＣ３２６５」は、入手可能である（例えば、非特許文献２参照）。この両方の仕様は、その全体が参考として本明細書に援用される。

ＳＩＰネットワークは、クライアント、サーバ、または両方として、ダイアログに参加することができるエンティティを含む。ＳＩＰは、４つのタイプのエンティティ、すなわち、ユーザエージェント、プロキシサーバ、リダイレクトサーバ、およびレジスタをサポートする。ユーザエージェントは、他のＳＩＰエンティティとメッセージを交換することによってダイアログを開始および終了する。ユーザエージェントは、ＳＩＰリクエストを開始するデバイスであるユーザエージェントクライアント（「ＵＡＣ」）、または、ＳＩＰリクエストを受け取りそれに応答するデバイスであるユーザエージェントサーバ（「ＵＡＳ」）となることができる。例えば、「ＩＰ電話」、ＰＤＡ、および他の任意のデバイスを、ユーザエージェントとすることができる。１つのデバイスは、あるダイアログにおいてＵＡＣであり別のダイアログにおいてはＵＡＳであることも可能であり、ダイアログ中に役割を変更してもよい。プロキシサーバは、クライアントに対してサーバとして、サーバに対してはクライアントとして機能するデバイスである。その際、プロキシサーバは、ＵＡＣとＵＡＳの間でのメッセージのインタセプト、解釈、または転送を行う。リダイレクトサーバは、ＳＩＰリクエストを受け入れ、代わりのネットワークリソースに連絡するためにリクエストを送るＵＡＣに向けて送る応答を生成する。レジスタは、ユーザエージェントから登録情報を受け入れ、受け取った登録情報をロケーションサービスに通知する。

ＳＩＰは、リクエストに応答する場合、２つのメッセージタイプ、すなわち、ＵＡＣからＵＡＳに送られるリクエストと、ＵＡＳからＵＡＣに送られる応答をサポートする。ＳＩＰメッセージは、３つの部分から構成される。ＳＩＰメッセージ第１の部分は、メッセージメソッド（例えば、ＩＮＶＩＴＥ）を示すフィールドを含む「リクエスト行（ｒｅｑｕｅｓｔ ｌｉｎｅ）」、および、リクエストが送られる先のユーザまたはサーバを識別する（示す）リクエストＵＲＩである。ＳＩＰメッセージの第２の部分は、その値が名前値のペアとして表されるヘッダを含む。ＳＩＰメッセージの第３の部分は、開始されるセッションを記述するのに使用され、つまりセッションに関連するデータを含む、メッセージの本体である。メッセージ本体は、リクエストまたは応答において現れることがある。

ユーザエージェントは、ＳＩＰダイアログの際にＳＩＰメッセージを送ることにより通信することができる。ＳＩＰダイアログは、ある時間存続する２つのユーザエージェントの間のピアツーピアの関係である。ダイアログは、ＵＡＣがＩＮＶＩＴＥリクエストをＵＡＳに送り、ＵＡＳが２００ ＯＫ応答により応答する場合に確立することができる。ダイアログは、コール識別子（ｃａｌｌ ｉｄｅｎｔｉｆｉｅｒ）、ローカルタグ、およびリモートタグを含むダイアログ識別子によって一意的に識別される。ユーザエージェントは、そのダイアログの将来のリクエストを送る場合に必要とされる、ダイアログについての状態情報を、維持する。状態情報は、ダイアログ識別子、ローカルＵＲＩ、リモートＵＲＩ、および経路集合（ｒｏｕｔｅ ｓｅｔ）を含む。経路集合は、リクエストがそのダイアログの他方のユーザエージェントに送られた場合にトラバースされる必要がある、プロキシサーバのリストである。ＵＡＳがＩＮＶＩＴＥリクエストを受け取り、また、ＵＡＣがＩＮＶＩＴＥ応答を受け取る場合、それらは、それぞれダイアログについての状態情報を初期化する。

ＩＮＶＩＴＥリクエストは、Ｔｏ、Ｆｒｏｍ、Ｃａｌｌ−ＩＤ、Ｖｉａ、Ｃｏｎｔａｃｔ、およびＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを含むことができる。Ｔｏヘッダは、リクエストの受信側の論理ＩＤを示す。Ｆｒｏｍヘッダは、リクエストの開始側の論理ＩＤを示す。Ｃａｌｌ−ＩＤヘッダは、メッセージのグループを一意的に識別し、１つのダイアログにおけるすべてのメッセージについてＣａｌｌ−ＩＤヘッダは同じである。ダイアログは、Ｃａｌｌ−ＩＤヘッダからのＣａｌｌ−ＩＤ値、ならびに、ＦｒｏｍヘッダおよびＴｏヘッダからのローカルタグおよびリモートタグを含む、ダイアログ識別子によって、一意的に識別される。Ｖｉａヘッダは、リクエストがたどったパス（例えば、リクエストが通過した一連のデバイスのネットワークアドレス（「ＵＲＩ」））、および、対応する応答がたどるパスを示す。リクエストを開始するＵＡＣ、およびリクエストを受け取る各プロキシサーバは、そのＵＲＩを含むＶｉａヘッダの追加をする。応答を受け取った各プロキシサーバは、次のＶｉａヘッダによって示されるデバイスに応答を転送する。Ｃｏｎｔａｃｔヘッダは、メッセージの送信者のＵＲＩを含み、プロキシサーバがダイアログにおける後続のメッセージの受信を求めることを示すまで、ダイアログの後続するリクエストは、そのＵＲＩに直接送ることができる。リクエストのＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダは、デバイス（プロキシサーバ）のＵＲＩを規定し、それにより、ダイアログの後続するリクエストが、経路指定される。ＩＮＶＩＴＥリクエストを送るＵＡＣは、そのＵＲＩを示すＣｏｎｔａｃｔヘッダを追加することができる。プロキシサーバは、ダイアログのパスに加わろうとする場合、そのＵＲＩを有するＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダを、ＩＮＶＩＴＥリクエストの転送に先立って、そのリクエスト内に挿入する。

ＵＡＳは、ＩＮＶＩＴＥリクエストを受け取る場合、ダイアログについての状態情報を格納する。ＵＡＳは、リモートＵＲＩを、ＣｏｎｔａｃｔヘッダのＵＲＩに設定し、経路集合がある場合それを、リクエストのＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダに設定する。そうでない場合、ＵＡＳは、この記録の集合をヌルに設定する。

ＵＡＳが、ＩＮＶＩＴＥリクエストへの応答を送る場合、ＵＡＳは、この応答に対して、経路集合のコピー、それ自体のＣｏｎｔａｃｔヘッダの追加、および、Ｖｉａヘッダのコピーなどを行う。次いで、この応答を、最終のＶｉａヘッダによって識別される（示される）デバイスに転送する。応答を受け取る各プロキシサーバは、次のＶｉａヘッダによって識別されるデバイスに、応答を転送する。

ＵＡＣは、リクエストを受け取った場合、ダイアログにおけるその経路集合がある場合はその逆の順序で、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダを格納し、リモートＵＲＩをＣｏｎｔａｃｔヘッダのＵＲＩに設定する
いずれかのユーザエージェントがダイアログの後続のリクエストを送る場合、ユーザエージェントは、Ｒｏｕｔｅヘッダを、ダイアログにおける格納された経路集合に対応するリクエストに追加し、リモートＵＲＩをリクエストＵＲＩ内に格納する。次いで、ユーザエージェントは、第１のＲｏｕｔｅヘッダにより識別される（示される）デバイスがある場合それにリクエストを送り、そうでない場合、リクエストＵＲＩによって識別されるデバイスに送る。各プロキシサーバは、先頭のＲｏｕｔｅヘッダを除去し、リクエストを、次のＲｏｕｔｅヘッダによって識別されるデバイスがある場合それに転送し、そうでない場合、リクエストＵＲＩによって識別されるデバイスに転送する。

リアルタイム会話の一般的形態は、インスタントメッセージングサービスによって提供される。インスタントメッセージングサービスにより、エンドポイントにおける参加者がメッセージを送り、会話に参加している他の参加者が、そのメッセージを１秒ないし２秒以内に受け取ることが可能になる。次いで、それを受け取った参加者が、応答メッセージを同様に他の参加者に送ることができる。効率的にするため、リアルタイム会話では、参加者が、非常に迅速に、受け取ったメッセージを認識し、検討し、それに応答することが期待されている。このような迅速な応答は、電子メールの受信者が都合の良い時間にメッセージに応答する従来の電子メールシステムとは対照的である。

リアルタイム会話を開始しようとする場合、開始側の参加者は、対象となる参加者が、メッセージに対してリアルタイムで応答することが可能かどうかを知る必要がある。可能でない場合は、従来の電子メール、ボイスメール、または他のある種のメカニズムを介した通信が、より適切となり得る。例えば、対象となる参加者のコンピュータの電源が現在オフにされている場合は、リアルタイム会話は不可能になる。更に、コンピュータの電源が現在オンにされていても、対象となる参加者が、コンピュータから離れた所にいる場合、やはりリアルタイム会話は不可能である。開始側の参加者は、適切な通信の形態を決定することができるように、対象となる参加者が応じられるかどうかの可用性を知りたいと考える。

コンピュータシステム（すなわちエンドポイント）、またはコンピュータシステムに関連するユーザなどのエンティティについての上述のような可用性の状況は、「プレゼンス情報（ｐｒｅｓｅｎｃｅ ｉｎｆｏｒｍａｔｉｏｎ）」と呼ばれる。プレゼンス情報は、ユーザの現在の「プレゼンス状態（ｐｒｅｓｅｎｃｅ ｓｔａｔｅ）」を示す。ユーザが、自身のプレゼンス情報を利用可能にすることにより、このユーザとどのように通信することができるかを他のユーザが決定できるようになる。例えば、プレゼンス情報は、ユーザが、インスタントメッセージングサーバにログオンしているか（「オンライン」）、あるいはそれからログオフしているか（「オフライン」）を示すことができる。プレゼンス情報は、ユーザの可用性についてのより詳細な情報も提供することができる。例えば、ユーザは、オンラインであっても、コンピュータから離れてミーティング中の場合がある。このような場合、プレゼンス状態は、「ｏｎｌｉｎｅ（オンライン）」、ならびに「Ｉｎ ａ ｍｅｅｔｉｎｇ（ミーティング中）」を示すことができる。

インスタントメッセージングのコンテキストでは、パブリッシング（ｐｕｂｌｉｓｈｉｎｇ）ユーザ（「バプリッシャ（ｐｕｂｌｉｓｈｅｒ）」）は、自身のプレゼンス情報を、プレゼンスサーバに提供することができ、次いで、プレゼンスサーバは、プレゼンス情報を、サブスクライビング（ｓｕｂｓｃｒｉｂｉｎｇ）ユーザ（「サブスクライバ（ｓｕｂｓｃｒｉｂｅｒ）」）に提供する。したがって、プレゼンスサーバは、サブスクライバ／パブリッシャモデルを使用して、プレゼンスサービスのユーザについてのプレゼンス情報を提供することができる。ユーザのプレゼンス情報が変更するときはいつでも、ユーザのコンピュータシステムにより、その変更がプレゼンスサーバに通知され、次いで、プレゼンスサーバにより、サブスクライビングユーザに変更が通知される。次いで、サブスクライビングユーザは、対象となる参加者のプレゼンス情報に基づいてインスタントメッセージングの会話を開始するかどうかを決定することができる。例えば、プレゼンス情報が、現時点にパブリッシングユーザが電話会議で通話中であることを示している場合、サブスクライビングユーザは、パブリッシングユーザに電話をかけずにインスタントメッセージを送ることを決定することができる。しかし、パブリッシングユーザに電話をして話す必要がある場合、サブスクライビングユーザは、いつ電話をかけることができるかを知るために、パブリッシングユーザのプレゼンス情報を監視する必要がある。サブスクライビングユーザは、パブリッシングユーザのプレゼンス情報が、電話会議が終了していることを示していることに気付いたとき、電話をかけることができる。

http://www.ietf.org/rfc/rfc3261.txt, RFC 3261 http://www.ietf.org/rfc/rfc3265.txt, RFC 3265

プレゼンスサーバがＳＩＰプロトコルを使用する場合、ＳＩＰダイアログのリクエストメッセージを、サブスクライブリクエストメッセージと同じパスを逆方向にたどって送ることができるように、プレゼンスサーバは、サブスクライバのための経路情報を維持する必要がある。その結果として、プレゼンスサーバは、パブリッシャごとに、パブリッシャのプレゼンス情報の各サブスクライバごとの経路情報を格納することがある。プレゼンスサーバは、何千ものパブリッシャおよびサブスクライバをサポートする可能性があるため、膨大な経路情報を格納することが必要になり得る。したがって、プレゼンスサーバの修正を必要とせずにプレゼンスサーバのストレージ要件を軽減し、プロキシサーバおよびレジストラなど既存のＳＩＰサーバと同時に使用することができる技術が望まれる。

ダイアログ中にソースエンドポイントと宛先エンドポイントの間で転送されるメッセージをプロキシするための通信ネットワークのプロキシノードにおける方法およびシステム。この通信システムは、ソースエンドポイントから宛先エンドポイントへ送られるリクエストメッセージを受け取る。リクエストメッセージは、ノードのパス、すなわち、宛先エンドポイントからソースエンドポイントへのリクエストメッセージが、プロキシノードに到着したのちに進む、ノードのパスを示す（ｉｄｅｎｔｉｆｙ）経路情報を含む。プロキシノードは、リクエストメッセージを受け取った後、経路情報へのダイアログのマッピングを生成することができる。次いで、プロキシノードは、その経路情報のみを有するリクエストメッセージを宛先エンドポイントに転送し、格納された経路情報を除去する。宛先エンドポイントがリクエストメッセージを受け取る場合、リクエストメッセージは、経路情報を格納したプロキシノード、ならびにプロキシノードと宛先エンドポイントの間の任意の中間プロキシノードについての経路情報のみを含む。したがって、宛先エンドポイントは、すべてのプロキシノードについてではなく、プロキシノードと、もしも存在する場合は中間プロキシノードに関係する経路情報のみ格納する必要がある。プロキシノードは、宛先エンドポイントからソースエンドポイントに送られる、ダイアログのリクエストメッセージを受け取る場合、ソースエンドポイントへの元のリクエストメッセージと同じ経路をリクエストメッセージが移動することができるように、格納された経路情報をリクエストメッセージに追加することができる。

上記の要約は、一連の概念を単純な形態で導入するために示されているが、これらは以下の詳細な説明において更に説明される。上記の要約は、特許請求の範囲の対象の鍵となる特徴または本質的特徴を特定することも、特許請求の範囲の対象の範囲を決定する助けとして用いることも目的としていない。

ダイアログ中にソースエンドポイントと宛先エンドポイントの間で転送されているメッセージをプロキシするための、通信ネットワークのプロキシノードにおける方法およびシステム。一実施形態では、通信システムは、ソースエンドポイントから宛先エンドポイントへ送られるリクエストメッセージを受け取る。リクエストメッセージは、宛先エンドポイントからソースエンドポイントへのリクエストメッセージが、プロキシノードに到着したのちに進む、ノードのパスを示す経路情報を含む。例えば、通信システムが、セッション開始プロトコル（「ＳＩＰ」）を使用する場合、プロキシノードは、プロキシサーバを実装することができ、宛先エンドポイントは、ユーザエージェントを実装することができる。リクエストメッセージを受け取った後、プロキシノードは、経路情報へのダイアログのマッピングを生成することができる。ＳＩＰが使用されている場合、経路情報は、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの情報を含む。次いで、プロキシノードは、プロキシノードの経路情報のみを有するリクエストメッセージを、場合によっては中間プロキシノードを介して、宛先エンドポイントに転送する。宛先エンドポイントが、リクエストメッセージを受け取る場合、メッセージは、プロキシノードについてと、そのプロキシノードと宛先エンドポイントの間の中間プロキシノードについての経路情報のみを含む。プロキシノードは、宛先エンドポイントからソースエンドポイントに送られる、ダイアログのリクエストメッセージを受け取る場合、リクエストメッセージが、ソースエンドポイントへの元のリクエストメッセージと同じ経路を移動することができるように、格納された経路情報をリクエストメッセージに追加することができる。例えば、ＳＩＰが使用される場合、プロキシノードは、元のリクエストメッセージのＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダごとに、Ｒｏｕｔｅヘッダを追加する。したがって、宛先エンドポイントは、プロキシノード、および存在する場合は中間プロキシノードに関係する経路情報のみを格納する必要がある。宛先エンドポイントがプレゼンスサーバの場合、プレゼンスサーバの経路情報に関するストレージ要件を軽減することができる。更に、プロキシノードによって変更されたＳＩＰメッセージは、ＳＩＰに準拠するので、プロキシノードは、ＳＩＰに準拠するノードと互換性がある。

一実施形態では、通信システムは、登録サービスを含むプロキシノード上で実装される。例えば、プロキシノードは、ＳＩＰプロキシサーバ、およびＳＩＰレジストラを含む。ＳＩＰレジストラは、プロキシノードとエンドポイントの間のパスに関する経路情報を含むエンドポイントへのユーザのマッピングを維持する。ＳＩＰレジストラは、経路情報を維持し、それにより、エンドポイントに送られるリクエストメッセージに経路情報を含めることができる。ＳＩＰプロキシサーバが、ＳＩＰレジストラと同一位置にある場合、ＳＩＰプロキシは、ＳＩＰレジストラで維持される経路情報を利用することができる。特に、ＳＩＰプロキシサーバは、リクエストメッセージを受け取る場合、ＳＩＰレジストラの情報を検査して、ソースエンドポイントについての情報が格納されているかどうかを決定するためにことができる。それが格納されている場合、ＳＩＰプロキシサーバは、そのソースエンドポイントについての経路情報を格納する必要がない。ソースエンドポイントに向かうことになっているリクエストメッセージが、ＳＩＰプロキシサーバによって受け取られた場合、ＳＩＰプロキシサーバは、ＳＩＰレジストラの情報から、ソースエンドポイントについての経路情報を取り出す。次いで、ＳＩＰプロキシサーバは、リクエストメッセージに経路情報を追加し、そのメッセージを転送する。このようにして、通信システムは、冗長な経路情報を格納することを回避することができる。

一実施形態では、登録サーバを含むプロキシノードは、ユーザのエンドポイントからプレゼンスサーバへのパスにおける最後のプロキシノードである。パスのこのような特徴は、登録サーバがプレゼンスサーバの位置を決定することができる通信ネットワークにおいて可能である。プレゼンスサーバで実装されるパスストレージシステムの態様では、この特徴を、登録サーバとプレゼンスサーバが同じドメイン内にある場合に利用することができる。その場合、プレゼンスサーバは、登録サーバが同じドメインにあることを検出することができ、経路情報を格納することはできない。プレゼンスサーバは、リクエストメッセージを送る場合、登録サーバからエンドポイントへのパスを発見するために、登録データベースにアクセスすることができる。プレゼンスサーバは、パスから導き出した経路情報を、そのメッセージに追加することができる。その場合、プレゼンスサーバは、メッセージの経路情報を格納するのを回避し、代わりに登録データベースを利用することができる。

一実施形態では、ドメインに対するアクセスポイントが、他のドメインからそれらのアクセスポイントへのマッピングを維持する。このマッピングは、アクセスポイントにより、他のドメインのエンドポイントにメッセージを経路指定するために使用される。アクセスポイントノードが、プロキシサーバを含む場合、プロキシサーバは、アクセスポイントのマッピングを利用して、格納する必要がある経路情報を少なくすることができる。プロキシサーバは、別のドメインのエンドポイントからメッセージを受け取る場合、この別のドメインのアクセスポイントについての経路情報を格納する必要がない。プロキシサーバは、他のドメインに送られるリクエストメッセージを受け取る場合、経路情報の一部分を生成するための情報を取り出すために、ソースエンドポイントのドメインを使用することができる。このようにすると、プロキシサーバがアクセスポイントと同じノードにインストールされている場合、プロキシサーバは、アクセスポイントに既に格納された経路記録の冗長な部分を格納することを回避することができる。

図１は、一実施形態における、通信システムがパス情報を格納する環境を示すブロック図である。この環境は、通信リンク１１０を介して登録サーバ１０２に接続されたクライアントエンドポイント１０１を含み、登録サーバ１０２は、通信リンク１１１を介してプレゼンスサーバ１０３に接続されている。各登録サーバは、登録サーバからユーザに関連するクライアントエンドポイントにリクエストが送られる経路に、ユーザをマップする登録データベース１０４を含む。登録サーバは、クライアントエンドポイントから登録リクエストを受け取る場合、登録データベースにリクエストの経路情報を格納する。プレゼンスサーバは、プレゼンス情報のパブリッシャをそのサブスクライバにマップするプレゼンスデータベース１０５を維持する。このマッピングは、各サブスクライバの経路情報を含む。パブリッシャのプレゼンス情報が変更される場合、プレゼンスサーバは、そのパブリッシャの各サブスクライバにリクエストを送る。各リクエストは、サブスクライバの経路情報を含む。通信システムが、登録サーバと同一の位置でプロキシサーバに実装される場合、プロキシサーバは、クライアントエンドポイントから受け取ったサブスクライブリクエストから経路情報を除去することができる。次いで、プロキシサーバは、その経路情報をサブスクライブリクエストに追加し、プレゼンスサーバにリクエストを転送する。プレゼンスサーバは、リクエストを受け取る場合、サブスクライブリクエストの経路情報を、通常通り格納する。しかし、サブスクライブリクエストの経路情報は、登録サーバからプレゼンスサーバへの経路情報のみを含む。プレゼンスサーバが、クライアントエンドポイントにリクエスト（を送る例えば、パブリッシャのプレゼンス情報の変更を示す）場合、リクエストを受け取ったプロキシサーバは、登録データベースからユーザについての経路情報を取り出し、リクエスト内に経路情報を格納する。次いで、プロキシサーバは、クライアントエンドポイントへ経路情報を有するリクエストを転送する。

通信システムが実装されるコンピューティングデバイスには、中央処理装置、メモリ、入力装置（例えば、キーボード、ポインティングデバイス）、出力装置（例えば、表示装置）、および記憶装置（例えば、ディスクドライブ）が含まれ得る。メモリおよび記憶装置は、コンピュータ可読媒体であり、通信システムを実装する命令を含むことができる。更に、データ構造およびメッセージ構造は、通信リンク上の信号などのデータ伝送媒体により格納または伝送することができる。インターネット、ＬＡＮ、ＷＡＮ、ポイントツーポイントダイヤルアップ接続、および携帯電話ネットワークなどの様々な通信リンクが使用され得る。

通信システムの実施形態は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能家庭用電化製品、デジタルカメラ、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ならびに、これらの任意のシステムまたはデバイスを含む分散コンピューティング環境などを含めた様々な動作環境で実装することができる。これらのコンピュータシステムは、携帯電話、ＰＤＡ、スマートフォン、パーソナルコンピュータ、プログラム可能家庭用電化製品、およびデジタルカメラなどにすることができる。

通信システムは、１つまたは複数のコンピュータあるいは他のデバイスで実行されるプログラムモジュールなどコンピュータ可読命令の一般的コンテキストで説明することができる。一般に、プログラムモジュールは、特定のタスクを実行しまたは特定の抽象データタイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、およびデータ構造などを含む。通常、プログラムモジュールの機能は、様々な実施形態において、所望に応じて組み合わせるまたは分散させることができる。

図２は、一実施形態における、ソースからソースリクエストを受け取るプロキシサーバのコンポーネントの処理を示す流れ図である。この実施形態では、プロキシサーバは、他のサービス（例えば、ＳＩＰレジストラ）によって生成される経路情報のデータベースにアクセスすることができないので、リクエストの経路情報からそれ自体のデータベースを作成する。ブロック２０１で、コンポーネントは、リクエストから経路記録を除去する。ブロック２０２で、コンポーネントは、リクエストのダイアログ識別子によってインデックス付けされた経路記録を格納する。ブロック２０３で、コンポーネントは、プロキシサーバの経路情報（例えば、Ｃｏｎｔａｃｔヘッダ）をリクエストに追加する。ブロック２０４で、コンポーネントはリクエストを転送し、次いで終了する。

図３は、一実施形態における、宛先から宛先リクエストを受け取るプロキシサーバのコンポーネントの処理を示す流れ図である。この実施形態では、プロキシサーバは、他のサービスによって生成された経路情報のデータベースにアクセスすることができない。ブロック３０１で、コンポーネントは、リクエストのダイアログ識別子に関して経路記録を取り出す。ブロック３０２で、コンポーネントは、経路記録をリクエストに追加する。ブロック３０３で、コンポーネントは、経路情報の第１の経路記録によって示されるノードにリクエストを転送し、次いで終了する。

図４は、通信システムが他のサービスによって格納される経路情報を使用する様々な環境を例示するブロック図である。クライアントエンドポイント４０１、登録サーバ４０２、およびプレゼンスサーバ４０３は、アクセスポイント４０４を介して通信リンクに接続されている。アクセスポイント４０４は、ドメインのユーザが通信リンク４１０を介してアクセス可能であるアクセスポイント４０６および４０８への経路に、ドメインをマップする、データベースを維持することができる。例えば、アクセスポイント４０４は、あるドメインをアクセスポイント４０６への経路にマップし、他のドメインをアクセスポイント４０８への経路にマップする、アクセスポイントデータベース４０５を維持することができる。アクセスポイントはまた、ドメインのユーザからその登録サーバへのマッピングを維持することもできる。アクセスポイント４０６および４０８は、ドメインから経路への同様のマッピング４０７および４０９を維持することができる。通信システムは、同じドメイン内のアクセスポイントデータベースの情報を使用することにより、他のドメインのクライアントエンドポイントから受け取ったＳＩＰリクエストについての経路情報を格納する必要を回避することができる。更に、プレゼンスサーバ（または他のＳＩＰノード）が登録サーバと同じドメインに位置する場合、プレゼンスサーバは、登録サーバに既に格納されている経路情報を格納する必要を回避することができる。

図５は、一実施形態における、リクエストを受け取るプレゼンスサーバのコンポーネントの処理を示す流れ図である。この実施形態では、プレゼンスサーバは、登録サーバが同じドメインにあるかどうかを決定し、同じドメインにある場合は、受け取ったリクエストに関連する経路情報を格納することを回避する。判断ブロック５０１で、登録サーバが同じドメインにある場合、コンポーネントは、ブロック５０２に進み、そうでない場合、ブロック５０３に進む。ブロック５０２では、コンポーネントは、登録サーバが同じドメインにあることを示すフラグを設定し、リクエストの経路情報を格納しない。ブロック５０３では、コンポーネントは、リクエストの経路記録およびｃｏｎｔａｃｔを格納する。次いで、コンポーネントは終了する。

図６は、一実施形態における、リクエストを送るプレゼンスサーバのコンポーネントの処理を示す流れ図である。この実施形態では、プレゼンスサーバは、登録サーバが同じドメインにあるかどうかを決定し、同じドメインにある場合、登録サーバに経路情報を要求する。ブロック６０１で、ユーザの登録サーバが同じドメインにある場合、コンポーネントは、ブロック６０２に進み、そうでない場合は、ブロック６０５に進む。ブロック６０２で、コンポーネントは、例えばＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙから、ユーザの登録サーバを識別する。ブロック６０４で、コンポーネントは、リクエストを登録サーバに転送する。登録サーバは、プロキシサーバと同一の場所に配置することもできる。次いで、コンポーネントは終了する。ブロック６０５で、コンポーネントは、クライアントエンドポイントについての経路記録およびｃｏｎｔａｃｔ情報を取り出す。ブロック６０６で、コンポーネントは、リクエストに経路記録を追加する。ブロック６０８で、コンポーネントは、取り出された経路記録によって示される第１のノードにリクエストを送り、次いで終了する。

図７は、一実施形態における、アクセスポイントにおいてソースリクエストを受け取る通信システムのコンポーネントの処理を示す流れ図である。この実施形態では、コンポーネントは、アクセスポイントと同一の場所に位置するプロキシサーバの一部分である。ブロック７０１で、コンポーネントは、ｔｏフィールドからドメインを取り出す。ブロック７０２で、コンポーネントは、取り出したドメインにリクエストを送る場合に使用するために、そのドメインから経路情報へのマッピングを確保する。ブロック７０３で、コンポーネントは、経路情報をリクエストから除去する。ブロック７０４で、コンポーネントは、経路情報としてアクセスポイントをリクエストに追加する。ブロック７０５で、コンポーネントは、登録サーバにリクエストを転送する。次いで、コンポーネントは終了する。

図８は、一実施形態における、アクセスポイントにおいて宛先リクエストを受け取る通信システムのコンポーネントの処理を示す流れ図である。ブロック８０１で、コンポーネントは、ｔｏフィールドからドメインを取り出す。ブロック８０２で、コンポーネントは、そのドメインについての経路情報を取り出す。ブロック８０３で、コンポーネントは、アクセスポイントの経路情報をリクエストに追加する。ブロック８０４で、コンポーネントは、経路情報によって示される第１（最初）のノードにリクエストを転送し、次いで終了する。

以上、本明細書では、例示のために、特定の通信システムの実施形態について説明したが、本発明の趣旨および範囲から逸脱することなく、様々な変更形態が可能であることは認識されよう。したがって、本発明は、添付の特許請求の範囲による場合を除き限定されない。

一実施形態における、通信システムがパス情報を格納する環境を示すブロック図である。 一実施形態における、ソースからソースリクエストを受け取るプロキシサーバのコンポーネントの処理を示す流れ図である。 一実施形態における、宛先から宛先リクエストを受け取るプロキシサーバのコンポーネントの処理を示す流れ図である。 通信システムが、他のサービスによって格納される経路情報を使用することができる、様々な環境を示すブロック図である。 一実施形態における、リクエストを受け取るプレゼンスサーバのコンポーネントの処理を示す流れ図である。 一実施形態における、リクエストを送るプレゼンスサーバのコンポーネントの処理を示す流れ図である。 一実施形態における、アクセスポイントでソースリクエストを受け取る通信システムのコンポーネントの処理を示すブロック図である。 一実施形態における、アクセスポイントで宛先リクエストを受け取る通信システムのコンポーネントの処理を示すブロック図である。

符号の説明

１０１ クライアント０
１０１ クライアントＮ
１０２ 登録サーバ０
１０２ 登録サーバｌ
１０３ プレゼンスサーバ
１０４ 登録ＤＢ
１０５ プレゼンスＤＢ
１１０ 通信リンク
１１１ 通信リンク

Claims (20)

1. ダイアログのメッセージを処理するためのネットワークのノードにおける方法であって、
   ソースノードから宛先ノードに送られる前記ダイアログの第１のリクエストを受け取るステップであって、前記第１のリクエストは、前記宛先ノードから前記ソースノードへのリクエストが前記ノードに到着したのちに進む、ノードのパスを示す経路情報を含むステップと、
   前記経路情報への前記ダイアログのマッピングを提供するステップと、
   前記ノードの前記経路情報のみを有する前記第１のリクエストを、前記宛先ノードに転送するステップと、
   前記ソースノードに送られた前記ダイアログの第２のリクエストを受け取るステップと、
   前記マッピングから、前記第２のリクエストにおいて示される前記ダイアログについての前記経路情報を取り出すステップと、
   取り出された前記経路情報を有する前記第２のリクエストを、前記ソースノードに転送するステップと
   を含むことを特徴とする方法。
2. 前記マッピングを提供するステップは、前記ノードで前記リクエストが受け取られた後に実行されることを特徴とする請求項１に記載の方法。
3. 同じドメインからのソースノードは、同じ経路情報を有し、前記マッピングは、前記ソースノードの前記ドメインを、前記経路情報にマップすることを特徴とする請求項１に記載の方法。
4. 前記ノードは、ドメインのアクセスポイントノードであることを特徴とする請求項３に記載の方法。
5. 前記メッセージは、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に準拠し、前記経路情報は、Ｒｅｃｏｒｄ−ＲｏｕｔｅｒおよびＣｏｎｔａｃｔヘッダから導出されることを特徴とする請求項１に記載の方法。
6. 前記第２のリクエストを転送するステップは、前記経路情報によって示される第１のノードにリクエストを送るステップを含むことを特徴とする請求項５に記載の方法。
7. 前記経路情報は、前記リクエストが前記ソースノードから前記ノードに移動する前記ノードのパスを示すことを特徴とする請求項１に記載の方法。
8. 前記リクエストは、ＳＩＰに準拠し、前記ノードは、登録サーバであり、提供された前記マッピングは、登録マッピングであることを特徴とする請求項１に記載の方法。
9. 前記宛先ノードは、プレゼンスサーバであることを特徴とする請求項８に記載の方法。
10. ソースノードから宛先ノードへのダイアログの第１のリクエストを受け取るステップであって、前記第１のリクエストは、経路情報を有するステップと、
    前記ソースノードから前記経路情報へのマッピングを生成するステップと、
    前記ノードを示す経路情報を有し、マップされた前記経路情報を有していない前記第１のリクエストを転送するステップと、
    前記ソースノードに送られた前記ダイアログの第２のリクエストを受け取るステップと、
    前記マッピングから、前記第２のリクエストにおいて示される前記ダイアログについての前記経路情報を取り出すステップと、
    取り出された前記経路情報を、前記第２のリクエストに追加するステップと、
    前記第２のリクエストを、取り出された前記経路情報によって示される前記ノードに転送するステップと
    を含む方法により、ＳＩＰを使用してメッセージを処理するためにネットワークのノードを制御するための命令を含むことを特徴とするコンピュータ可読媒体。
11. 前記リクエストが前記ノードで受け取られた後に、前記マッピングを生成するステップが実行されることを特徴とする請求項１０に記載のコンピュータ可読媒体。
12. 同じドメインにおけるソースノードは、同じ経路情報を有し、前記マッピングは、前記ソースノードの前記ドメインを前記経路情報にマップすることを特徴とする請求項１０に記載のコンピュータ可読媒体。
13. 前記ノードは、登録サーバであり、生成された前記マッピングは、登録マッピングであることを特徴とする請求項１０に記載のコンピュータ可読媒体。
14. 前記ソースノードが前記ノードに登録された場合、前記マッピングが生成されることを特徴とする請求項１３に記載のコンピュータ可読媒体。
15. 前記宛先ノードは、プレゼンスサーバであることを特徴とする請求項１４に記載のコンピュータ可読媒体。
16. 前記第２のリクエストが、前記プレゼンスサーバと同じドメイン内の登録サーバから受け取られた場合、前記ノードは、マッピングを生成しないことを特徴とする請求項１５に記載のコンピュータ可読媒体。
17. メッセージを処理するための、ネットワークの宛先ノードにおける方法であって、
    ユーザを有するソースノードから前記宛先ノードへの第１のリクエストを、登録ノードから受け取るステップと、
    前記宛先ノードと前記登録ノードが、同じドメイン内にある場合、
    ユーザから登録ノードへのマッピングから、前記ユーザの前記登録ノードの指示（ｉｎｄｉｃａｔｉｏｎ）を取り出すステップと、
    前記マッピングによって示される前記登録ノードに、前記ソースノードへのリクエストを転送するステップと
    を含むことを特徴とする方法。
18. 前記宛先ノードは、プレゼンスサーバであることを特徴とする請求項１７に記載の方法。
19. 前記メッセージは、ＳＩＰに準拠することを特徴とする請求項１７に記載の方法。
20. 前記登録ノードは、登録されたユーザについての経路情報を維持することを特徴とする請求項１７に記載の方法。
    
    

Images