JP5043392B2 - Ｓｉｐ通信セッションをセットアップする方法、並びに、そのシステム及びコンピュータ・プログラム - Google Patents

Description

本発明は、ＳＩＰシグナリングの暗号化を検証するための方法および装置に関する。

ＳＩＰ（session initiation protocol）は、１つまたは複数の参加者とのセッションを作成し、変更し、終了させることのできるインターネット・プロトコルである。ＳＩＰは、ポイント・ツー・ポイントまたはマルチパーティ・セッションのための音声およびビデオ・コールに使用される。それは、例えば、通常、ＲＴＰ（real-time transport protocol） ｏｖｅｒ ＵＤＰ（user datagram protocol）を使用するメディア・トランスポートから独立している。ＳＩＰはまた、インスタント・メッセージングおよびプレゼンス検出にも使用される。ＳＩＰにより、複数のエンドポイントが相互にメディア・セッションを確立することができる。ＳＩＰは、エンドポイントの位置を特定し、セッションを確立し、次いで、メディア・セッションが完了した後、そのセッションを終了させることをサポートする。ＳＩＰは、最近では、インスタント・メッセージングおよびコラボレーションのために、また移動体使用者間のプッシュ・ツー・トーク（push-to-talk）サービスのために、企業内にＶｏＩＰ（voice overinternet protocol）などの新しいサービスを
導入する有線サービス・プロバイダの間で広く受け入れられ展開されてきている。ＳＩＰを、ＩＰネットワークを介する集中した通信のための最適のプロトコルとして受け入れる業界は広範囲に及んでいる。図１に示すように、ＳＩＰのインフラストラクチャは、クライアント１０Ａ、１０Ｂ、ＳＩＰプロキシ１２Ａ、１２Ｂ、１２Ｃ、ならびにドメイン・ネットワーク１６Ａ、１６Ｂおよびネットワーク１６Ｃ（例えば、インターネット）にわたり展開されるドメイン・ディレクトリ・サーバ１４Ａ、１４Ｂからなる。クライアント１０Ａは、セッションのセットアップ、およびメディア転送を制御するＳＩＰエンドポイントである。クライアント１０Ａは、ＳＩＰ ＵＲＩ（uniform resource identifier）により識別され、それは、ＨＴＴＰ（hypertext transport protocol）と同様のsip:client@domainの形式の固有ＵＲＩである。すべてのユーザ・エージェントは、そのＩＰアドレスで、（ＳＩＰプロキシ１２の１つと同じ場所に配置できる）ＳＩＰディレクトリ・サーバ１４Ａ、１４Ｂ、または１４Ｃに登録することができる。ユーザにより登録されたデバイスのＩＰアドレスに対するＵＲＩのマッピングは、セッションのセットアップ・プロセスの一部分として中間のＳＩＰプロキシおよびディレクトリ・サーバを用いて行われる。ＳＩＰプロトコルの詳細は、J. Rosenberg et al. SIP: Session Initiation Protocol. RFC 3261.IETF, June 2002で見ることができる。ＳＩＰは、クライアント相互間でデータ・セッションをセットアップするための、図５に示すＯＰＴＩＯＮ １００、２００ ＯＫ、３００ ＩＮＶＩＴＥ、ＲＩＮＧＩＮＧ、ＡＣＫ、ＢＹＥなどの一組の制御信号を定義する。それらの信号は、ネットワーク中に展開されるＳＩＰプロキシを介して経路指定される。ドメイン・ディレクトリ・サーバ中のＤＮＳ ＳＲＶ（Domain name system for services）レコードは、特定のドメインに対する名前のＩＰアドレスを見つけるのに使用されるが、そのプロセスは、いくつかの、またしばしば複数のＳＩＰプロキシを使用することができる。

３００ ＩＮＶＩＴＥなど発信クライアントからのすべての要求は、３００ ＩＮＶＩＴＥ信号中に含まれる宛先ＳＩＰ ＵＲＩに基づいて、プロキシにより適切な宛先クライアントに経路指定される。プロキシは、ＳＩＰ ＵＲＩの現在のバインディングを判定するために、ディレクトリ・サーバに照会することができる。メディア交換のために適切なエンドポイントを突き止めるために、クライアント、プロキシ、およびディレクトリ・サーバの間で信号が交換される。スケーラビリティのため、シグナリング負荷を分散させるように複数のプロキシが使用される。通常のセッションは、３００ ＩＮＶＩＴＥ、２０１ ＯＫ応答、およびその応答に対するＡＣＫからなるＳＩＰシグナリングを介して、２つのクライアント間でセットアップされる。コールのセットアップに引き続いて、ＲＴＰ（real time transport protocol）を用いてメディア交換が行われる。セッションは、５００ ＢＹＥおよび２０２ ＯＫメッセージの交換により切断される。図５は、本実施形態による適合された一組のシーケンスを示す。

ＳＩＰは、セッション確立のプロセスと実際のセッションとを区別する。基本的なＳＩＰの理念は、メディア（ＲＴＰストリーム）メッセージからシグナリング（制御）を分離することである。制御信号は、メディア・パスがエンド・ツー・エンドである間、通常、プロキシを介して経路指定される。ＩＮＶＩＴＥのような信号は、メッセージ本体中に、ＳＤＰ（Session Description Protocol）を用いたユーザ・パラメータを含む（Handley, M. and V. Jacobson, SDP: Session Description Protocol, RFC2327, IETF Apr 1998）。ＳＤＰは、メディア・タイプのためのパラメータ、トランスポート・プロトコル、エンドポイントのＩＰアドレスおよびポート番号などセッションに関する情報を提供する。ＳＤＰを介して交換されるＩＰアドレスおよびポート番号は、セッションのための実際のデータ伝送（メディア・パス）に使用される。それらのパラメータのいずれも、すでに存在するセッション内で行うことができるという以外は３００ ＩＮＶＩＴＥ信号と同じであるＲＥ−ＩＮＶＩＴＥメッセージにより、進行しているセッション中に変更することができる。さらに、クライアントは、既存のセッションを、ＲＥＦＥＲ信号を用いて転送することができる。その信号は、既存のセッションの他のエンドポイントに対して、第３のクライアントとＩＮＶＩＴＥ／ＯＫ／ＡＣＫ交換を開始し、（ＲＥＦＥＲ信号の送信者との）既存のセッションを終了するように命令する。

ＳＩＰ信号は、それが機密情報を含んでいたとしても、デフォルトで、ＵＴＦ−８プレーン・テキスト・エンコード方式を用いて送信される。しかし、プライバシを維持するために、ＳＩＰコールの２つのＩＰコンポーネント、すなわち信号およびデータ・ストリームを暗号化することができる。発呼側クライアントは、第１のプロキシとのシグナリングの暗号化を要求することができるが、その信号を次のＳＩＰサーバが確実に暗号化するための機構がない。シグナリングが暗号化されていない場合、プロキシ間のシグナリングを傍受する任意のＩＰルータが、両方の当事者の識別およびインターネット・プロトコル・アドレスなどのコール情報を識別することも可能である。発呼側クライアントは、信号がネットワーク上をプレーン・テキストで送信されたことに気がつかないはずである。データ・ストリームは、コールのエンドポイントで暗号化され、暗号化解除されることだけが必要であり、それにより、その機密性に高い信頼度が得られるようになる。

代替の解決策は、シグナリングを部分的に暗号化することであり、中間プロキシに必須のＳＩＰヘッダだけをプレーン・テキストで送信する。それは、通常、Ｓ／ＭＩＭＥ（Secure Multipurpose Internet Mail Extension、すなわち、インターネット・メッセージにシグネチャまたは暗号化サービスあるいはその両方を追加するためのフォーマットおよびプロトコル）を用いて実施される。この代替方法は２つの欠点を有する。第１に、部分的な暗号化を使用しているだけなので、機密レベルが完全な暗号化を使用する場合よりも低くなることである。第２に、ＲＦＣ３２６１に記されているように、「しかし、ＳＩＰメッセージ（特にＳＤＰ）の本体を閲覧または変更することを利用する（典型的なプロキシ・サーバではない）ネットワーク中間物はまれであり、したがって、セキュアＭＩＭＥは、その種の中間物が機能するのを妨げる可能性のあることに実施者は留意すべきである。」

最後に、ＳＩＰＳ ＵＲＩを使用することにより、ユーザは、エンド・ツー・エンドの暗号化された移送が保証されないことに留意すべきである。ユーザは、「発呼者から被呼者のドメインまで」（ＲＦＣ３２６１、セクション４．２）の暗号化された移送が保証されるだけである。

ネットワークにおいて通信チャネルを開くために、第１の側が、第２の側に送信勧誘（invitation）を送ることが知られている。プロトコルが合意された後、通信チャネルは安全になり得るが、第１および第２の側のＩＤなどの機密情報を含む最初の送信勧誘は安全ではない。「Security mechanism agreement for SIP」がＲＦＣ３３２９に記載されている（http://www.ietf.org/rfc/rfc3329.textを参照のこと）。ＲＦＣ３３２９の目的は、２つのＳＩＰネットワーク・コンポーネントの間でどの暗号化を使用するか、すなわち、２点間で低、中間、または高度に暗号化されたリンクのどれを使用するかを折衝することである。そのＲＦＣは、ＳＩＰヘッダ・フィールドのシンタックスを記述するために、ワード・トークンを用いる。しかし、その発行物は、１つまたは複数のプロキシを介する安全なパスを作成することを記述していない。
J. Rosenberg et al.SIP: Session Initiation Protocol. RFC 3261. IETF, June 2002 Handley, M. and V. Jacobson, SDP: Session Description Protocol, RFC 2327, IETF Apr 1998 "Security mechanism agreement for SIP", RFC3329(http://www.ietf.org/rfc/rfc3329.text)

従って、本発明の目的は、ＳＩＰシグナリングの暗号化の検証のための方法及び装置を提供することにある。

本発明の第１の態様によると、宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを突き止めること、発呼側クライアントＳＩＰノードとプロキシＳＩＰノードの間でセキュア信号接続をセットアップすること、宛先クライアント名およびドメインを用いて、プロキシＳＩＰノードから宛先クライアントＩＰアドレスを突き止めること、前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより、セキュア信号接続および追加のセキュア信号接続がセキュア信号パスを形成すること、宛先クライアントＳＩＰノードに、セキュア信号パスを介してそのＩＰアドレスを返すように要求すること、および返されたＩＰアドレスを用いて、発呼側クライアントＳＩＰノードと宛先クライアントＳＩＰノードの間でデータ接続をセットアップすることを含む、少なくとも１つのプロキシＳＩＰノードを介して、少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションを開始する方法が提供される。

通信の安全性をさらに改善するために、返されたＩＰアドレスは、特定された宛先ＩＰアドレスと同じではなく、したがって、クライアントの実際のＩＰアドレスは、ディレクトリ中に決して公開されないようにする。

追加のセキュア信号接続をセットアップするのに使われる時間が閾値時間を超えた場合、新しいプロキシＳＩＰの位置が特定されると有利である。セキュア信号接続のセットアップが、セキュア信号接続のためのオプションを含むようにＳＩＰ ＯＰＴＩＯＮＳ信号を拡張するとさらに有利である。

各セキュア信号接続は暗号化されることが好ましい。より好ましくは、ＳＩＰノード間の各接続は、識別のためのセッション・キーを使用し、任意選択で、そのセッション・キーはセキュア信号接続の暗号化の一部分である。

適切には、プロキシから宛先クライアントＩＰアドレスを突き止めるステップが、１つまたは複数の次のプロキシを突き止めることを含み、セキュア信号接続を拡張するステップが、次のプロキシを介してセキュア信号接続を拡張することを含む。

本発明の他の態様によれば、ＳＩＰノードにおけるセキュアＳＩＰ通信方法が提供される。すなわち、ダウンストリームＳＩＰノードから、セキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップすること、宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めること、アップストリームＳＩＰノードへのセキュア信号接続をセットアップすること、およびセキュア信号接続上でＳＩＰ信号を受信し、転送することである。

本発明の他の態様によれば、ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップするためのオプション・フォワーダと、宛先名およびドメインを用いて、アップストリームＳＩＰノードＩＰアドレスを突き止めるためのセキュア・クライアント・ロケータと、アップストリームＳＩＰノードへのセキュア信号接続をセットアップし、かつセキュア信号接続上でＳＩＰ信号を受信し転送するためのインバイト・フォワーダとを備える、ＳＩＰノードにおけるセキュアＳＩＰ通信のシステムが提供される。

本発明の他の態様によると、ＳＩＰノードにおけるセキュアＳＩＰ通信のためのコンピュータ・プログラムであって、コンピュータに、ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信しダウンストリーム接続をセットアップするステップと、宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めるステップと、アップストリームＳＩＰノードへのセキュア信号接続をセットアップするステップと、セキュア信号接続上でＳＩＰ信号を受信し転送するステップとを実行させるためのコンピュータ・プログラムが提供される。

このような方法を用いることにより、コール・セットアップのホップ・バイ・ホップ（完全な暗号化）方法のクライアントは、シグナリングが常に暗号化された形で送信されていたことを検証することができる。検証機構が実施された場合、ＳＩＰ ＵＡおよびプロキシ開発者は、そのコールの暗号化状況に対するユーザ・フィードバックを与えるような機能、またはさらに非暗号化コールが行われるのを妨害し、プレーン・テキストのシグナリングが送信されないようにする機能を追加することができる。

本発明の諸実施形態を、例としてだけであるが、添付の図面を参照し次に説明する。

図１は、ＳＩＰクライアント１０Ａおよび１０Ｂ、プロキシ・サーバ１２Ａ〜１２Ｃ、ドメイン・ネットワーク１６Ａ、１６Ｂ、および外部ネットワーク１８の概略図である。各ネットワーク中に１つのプロキシ・サーバだけがラベル付けされているが、いくつかのプロキシ・サーバの任意の１つがネットワーク中に存在し、セキュア・ネットワークを形成するために使用することができる。ＳＩＰクライアント１０Ａ、１０Ｂおよびその各プロキシ・サーバ１２Ａ、１２Ｂ、およびドメイン・ディレクトリ・サーバ１４Ａおよび１４Ｂは、各ドメイン１６Ａおよび１６Ｂ（例えば、会社のイントラネット）中に位置する。ドメイン１６Ａおよび１６Ｂは、ネットワーク１８（例えば、インターネット）を介して共に接続されている。本発明のコンテキストでは、ＳＩＰクライアント１０Ａは、最初は、ＳＩＰクライアント１０Ｂの名前およびドメイン（例えば、client10B@domain16B）を知っているだけであり、ＳＩＰクライアント１０ＢのＩＰアドレス（例えば、123.546.789.000）は知っておらず、したがって、コールをセットアップする前に１０Ｂを突き止める必要がある。突き止めプロセス中に、ＳＩＰクライアント１０Ａ、ドメイン１６Ａのプロキシ・サーバ、例えばプロキシ・サーバ１２Ａ、ネットワーク１８のプロキシ・サーバ、例えばプロキシ・サーバ１２Ｃ、ドメイン１６Ｂのプロキシ・サーバ、例えばプロキシ・サーバ１２Ｂ、およびＳＩＰクライアント１０Ｂの間で、通常、接続がセットアップされる。突き止めプロセスからＩＰアドレスが取得されると、データを送信するために、非プロキシ接続１９をセットアップすることができる。宛先クライアント１０ＢのＩＰアドレスを突き止めるために、プロキシ・サーバ１２Ｂによってドメイン・ディレクトリ・サーバ１４Ｂが使用される。ドメイン１６Ａに対して、ドメイン・ディレクトリ・サーバ１４Ａも同様に行う。このプロキシ・サーバおよびＳＩＰクライアントの構成は、一例に過ぎず、例えば、２つのＳＩＰクライアントと単一のプロキシ・サーバ、またはカンファレンス・コールにおける複数のＳＩＰクライアント間など、複数のセキュア接続が必要な場合も、本発明を実施することができる。

図２は、本実施形態のＳＩＰクライアント１０Ａ、プロキシ・サーバ１２Ａ、およびドメイン・ディレクトリ・サーバ１４Ａの概略図である。ＳＩＰクライアント１０Ａは、コール・セットアップ・コンポーネント２０、セキュア・プロキシ・ロケータ２２、オプション・トランシーバ２４、タイマ２６、インバイト・トランシーバ２８、ＶｏＩＰデータ・トランシーバ３０、およびコール・シャットダウン・コンポーネント３２を備える。

コール・セットアップ・コンポーネント２０は、他のＳＩＰクライアントとのコールのセットアップを制御する。

セキュア・プロキシ・ロケータ２２は、プロキシ・サーバとの通信を管理する。それは、そのプロキシ・サーバを直接、またはメモリに照会することにより、セキュア接続に関して既知のプロキシ・サーバをフィルタリングする。

オプション・トランシーバ２４は、ＯＰＴＩＯＮ １００信号（図５を参照）を送信し、受信する。ＯＰＴＩＯＮ信号は、コールのセットアップにおいて使用される最初の信号の１つであり、特定のオプション、すなわち、本実施形態の場合は、ＶＥＳＰ（verified encryption secure path：検証済み暗号化セキュア・パス）オプションをプロキシ・サーバに求める要求を含む。ＶＥＳＰオプションを含むオプション要求が受信され、ＳＩＰクライアントがＶＥＳＰ互換のある場合、オプション・トランシーバ２４は、コール・セットアップの要求を先に進めてＶＥＳＰサポートを示す２００ ＯＫ信号で応答することになる（図５を参照）。そうではない場合、ＳＩＰクライアントは、オプション要求に２００ ＯＫで応答しない。オプション・トランシーバが、２００ ＯＫ信号を受信した場合、制御はインバイト・トランシーバ２８に渡される。

タイマ２６は、ＯＰＴＩＯＮ １００メッセージが送信されたときから、２００ ＯＫ信号が戻って受信されるまでの時間を測定開始する。コール・セットアップ・プロセスは、応答時間がある閾値を超えた場合に時間切れ中止とすることができる。時間切れ中止が生じた場合、オプション・トランシーバ２４は、他のセキュアＳＩＰプロキシ・サーバを選択し、他のＯＰＴＩＯＮ １００信号を送信する。もはやセキュア・プロキシ・サーバが存在しない場合、セキュア・コール・セットアップは取り消される。タイマはまた、インバイト・トランシーバ２８中の応答の時間を測るためにも使用される。

インバイト・トランシーバ２８は、インバイト・メッセージおよびセッション・キーを、ＶＥＳＰ準拠のプロキシ・サーバに送り、２０１ ＯＫおよびＩＰアドレスを待つ。タイマ２６はまた、待ち時間を測定し、閾値に達した場合は時間切れ中止する。プロセスが時間切れ中止された場合、再度、他のセキュア・プロキシ・サーバが選択され、またはセキュア・セットアップが取り消される。

ＶｏＩＰデータ・トランシーバ３０は、ＩＰアドレスが発見された後、ＳＩＰクライアント間のネットワークを介したＶｏＩＰデータの直接送信を制御する。

コール・シャットダウン・コンポーネント３２は、コールが終了したとき、コールの切断を制御する。

各プロキシ・サーバ１２は、オプション・フォワーダ３４、セキュア・クライアント・ロケータ３６、インバイト・フォワーダ３８、およびタイマ４０を備える。

オプション・フォワーダ３４は、ＯＰＴＩＯＮ １００信号を受信し、転送する（図５参照）。ＶＥＳＰオプションを含むオプション要求が受信されたとき、オプション・フォワーダ３４は、ＶＥＳＰオプションがセキュア・コール・セットアップを要求していることに気付き、セキュア・クライアントまたはプロキシ・サーバを突き止めるようにセキュア・クライアント・ロケータ３６に通知する。オプション・フォワーダは、応答として２００ ＯＫ信号を受信し、それをＯＰＴＩＯＮ １００信号の送信者に転送して戻す。

セキュア・クライアント・ロケータ３６は、ＳＩＰクライアントのＩＰアドレスを求めてディレクトリ・サーバに照会する。ＳＩＰクライアントが突き止められた場合、ＳＩＰクライアントＩＰアドレスがプロキシ・サーバに返される。そうでない場合、他のプロキシ・サーバのＩＰアドレスが、さらなる照会およびさらなるセキュア・コール・セットアップに対して返される。

セキュア・プロキシ・パスがセットアップされると、ＩＮＶＩＴＥ信号が発信ＳＩＰクライアントにより送られ、またインバイト・フォワーダ３８によって受信される。インバイト・フォワーダ３８は、セキュア・パスに沿ってＩＮＶＩＴＥ信号を転送し、そのパスに沿ってＯＫ信号を返す。

タイマ４０は、オプション・フォワーダ３４およびインバイト・フォワーダ３８の応答待ち時間を計測し、したがって、いずれも閾値を超える期間待つことはない。

各ドメイン・ディレクトリ・サーバ１４は、ＩＰアドレス・リゾルバ４４、およびＩＰアドレス・データ４６を備える。

ＩＰアドレス・リゾルバ４４は、ＳＩＰクライアント１０またはプロキシ・サーバ１２からクライアント名およびドメインを含む要求を受信し、ＩＰアドレスと、名前およびドメインをマッチさせるように試みる。ＩＰアドレス・データ４６からマッチが見つかった場合、それは要求者に送り返される。

図３は、本実施形態によるＳＩＰコール・セットアップの第１の部分の概略図である。

方法１０１は、発呼側クライアント・セットアップ・プロセスを定義する。

ステップ１０４で、セキュア・コール・セットアップは、被呼側クライアント名（例えば、ＳＩＰクライアント１０Ｂ）および被呼側クライアント・ドメイン（例えばドメイン１６Ｂ）を用いて、発呼側クライアント・セットアップ・コンポーネント２０中で定義される。

ステップ１０６で、セキュア・プロキシ・ロケータ２２は、既知のプロキシ・サーバのリストを照会することにより、送出プロキシ・サーバを突き止める。ＶＥＳＰ互換のないプロキシ・サーバの名前を必ず知っている必要があり、また各プロキシ・サーバは、セキュア接続をセットアップする能力が検査されていなければならない。

ステップ１０８では、オプション・トランシーバ２４は、セキュア・プロキシの１つにＯＰＴＩＯＮ １００信号を送信する。ＯＰＴＩＯＮ １００信号は、ＶＥＳＰ互換のあるプロキシ・サーバに対するオプションを含む。

方法１０９は、ＳＩＰプロキシ・セットアップ・プロセスを定義し、ステップ１１０、１１２、１１４、１２０、１２２および１２４を含む。

ステップ１１０で、ＳＩＰクライアントからのＯＰＴＩＯＮ １００信号が、オプション・フォワーダ３４により受信される。プロキシ・サーバがＶＥＳＰ互換である場合、ＯＰＴＩＯＮ信号は受け入れられ、制御が次のステップに渡される。

ステップ１１２では、セキュア・クライアント・ロケータ３６は、ディレクトリ・サーバを照会することにより、ＳＩＰクライアント１０Ｂを突き止めようと試みる。ＳＩＰクライアント１０Ｂが突き止められない場合、ＳＩＰクライアントのドメインのより近くに存在し、ＳＩＰクライアントのＩＰアドレスを知っている可能性のある他のセキュア・プロキシ・サーバが突き止められる。ドメイン・プロキシ・サーバは、通常そのドメイン中のＳＩＰクライアントのＩＰアドレスを有する。

ステップ１１４では、ディレクトリ・サーバがＳＩＰクライアントのＩＰアドレスを知っている場合、ＯＰＴＩＯＮ信号（および名前）が、セキュア・クライアントＢに転送される（方法１１６のＳＩＰ被呼側クライアント・セットアップ）。関連するディレクトリ・サーバが、セキュア・クライアントＢのＩＰアドレスを知らない場合、ＯＰＴＩＯＮ信号は、セキュア・クライアントＢのＩＰアドレスを突き止めることができる可能性を有する他のプロキシ・サーバに転送される（方法１１５の追加の等価なプロキシ・セットアップ）。

プロセス１１５は、等価な諸ステップ１１０、１１２、１１４、１２２、１２０、および１２４を有する最初の１０９ＳＩＰプロキシ・セットアップと等価な１つまたは複数の追加の等価なプロキシ・セットアップを示す。そのプロセスは、被呼側クライアントを突き止めるために必要なプロキシ・サーバの数に応じて、０からｎ回行われる。

方法１１６は、ステップ１１７および１１８を含む被呼側クライアント・セットアップ・プロセスである。

ステップ１１７で、ＯＰＴＩＯＮ信号１００がＳＩＰプロキシ・サーバから受信される。ＳＩＰクライアントがＶＥＳＰ互換である場合、それを受け入れ、プロセスは先に進む。

ステップ１１８で、セッション・キーが含まれた、返しＯＫ ２００信号が、接続しているプロキシ・サーバを介してＳＩＰノードに送信される。

方法１１５は、接続中に複数の返しプロキシ・サーバが存在する場合、ＯＫ ２００信号を転送する。

プロキシ・セットアップ方法１０９（または等価なプロキシ・セットアップ１１５）におけるステップ１２０は、２００ ＯＫ信号を待ち、ステップ１２４に進む。待ち時間切れになった場合、プロセスはステップ１２２に進む。

ステップ１２２は、関連するディレクトリ・サーバから他のセキュア・プロキシ・サーバを選択し、ステップ１１４で、再度、ＯＰＴＩＯＮ信号を送る。

方法１０９で、ステップ１２４は、ＳＩＰクライアント１０にＯＫ信号を返す。等価なプロキシ・セットアップ方法１１５で、等価なステップ１２４は接続しているプロキシ・サーバにＯＫ信号を返す。

発呼側クライアント・セットアップ方法１０１のステップ１２６は、２００ ＯＫ信号を待ち、ステップ１３０に進む。セキュア接続パスは、いまや完了し、返されたセッション・キーによりマーク付けされる。ステップ１２６が時間切れになった場合、プロセスはステップ１２８に進む。

ステップ１２８は、関連するディレクトリから、他のセキュア・プロキシを選択し、ステップ１０８で、再度、ＯＰＴＩＯＮ信号を送る。

ステップ１３０で、プロセス制御は方法３００に進む。

図４は、本実施形態によるＳＩＰコール・セットアップの第２の部分の概略図である。

方法３００は、インバイト・トランシーバ２８において実施されるステップ３０２、３２０、３２２を含む発呼側電話インバイト・プロセスである。

ステップ３０２は、セキュア接続パス中の第１のセキュア・プロキシ・サーバにセッション・キーを含むＩＮＶＩＴＥ信号を送る。

方法３０３は、セキュア接続パス中の第１および次のプロキシ・サーバ中のインバイト・フォワーダ３８で実施されるステップ３０４、３０６、３０８、３１６、および３１８を含むプロキシ・インバイト・プロセスである。

ステップ３０４は、セキュア・クライアントからセッション・キーを含むＩＮＶＩＴＥ信号を受信する。

ステップ３０６は、割り当てられたセキュア接続パスでセッション・キーを検査する。接続パス中の次のプロキシ・サーバまたはクライアントが突き止められる。

ステップ３０８は、セキュア接続パス中の次のセキュア・プロキシ・サーバにセッション・キーを含むＩＮＶＩＴＥ信号を転送する。

プロセス３０９は、等価なステップ３０４、３０６、３０８、３１６、および３１８を有する最初の３０３プロキシ・インバイトと等価な１つまたは複数の追加の等価のプロキシ・インバイトを示す。そのプロセスは、必要とされるプロキシ・サーバの数に応じて０からｎ回行われる。

プロセス３１０は、クライアント・インバイト・トランシーバ２８により実施される、またステップ３１２および３１４を含む被呼側クライアント・インバイト方法である。セッション・キーを含むＩＮＶＩＴＥは、クライアントを突き止めるのに必要な数に応じて１つまたは複数のプロキシ・サーバから受信される。

ステップ３１２では、インバイト・トランシーバが、セキュアＳＩＰクライアントからセッション・キーを含むＩＮＶＩＴＥ信号を受信する。そのセッションが受入れ可能であれば、プロセスは先に進む。

ステップ３１４で、インバイト・トランシーバは、被呼側クライアントのＩＰアドレスおよびセッション・キーを含むＯＫ信号２０１で応答する。

プロキシ・インバイト方法３０３で、ステップ３１６は、ＯＫ信号２０１を待つ。等価なプロキシ・インバイト方法３０９では、等価なステップ３１６は１２４のＯＫ信号２０１を待つ。待ち時間切れの場合、接続は失敗する。

ステップ３１８は、ＯＫ信号２０１、ＩＰアドレス、およびセッション・キーを発呼側ＳＩＰクライアントに返す。

発呼側クライアント・インバイト方法のステップ３２０は、ＯＫ信号２０１、ＩＰアドレス、およびセッション・キーを待つ。待ち時間切れになった場合、プロセスはステップ３２２に進む。その待ちが成功した場合、プロセスは進んで、４０１でＶｏＩＰデータを送信する。

ステップ３２２は、コール・セットアップを他のプロキシ・サーバにセットし直す。

ステップ４０１および４０３は、発呼側クライアント１０Ａおよび被呼側クライアント１０Ｂにおける各ＶｏＩＰトランシーバにより実施される。

発呼側クライアントＶｏＩＰデータ・トランシーバにおけるステップ４０１は、どのプロキシ・サーバも必要とせずにネットワークを介して被呼側クライアントに直接送信し、また被呼側クライアントから直接受信する。ＶｏＩＰデータ・セッションが作成される。ＶｏＩＰデータは、特別な安全性のために暗号化することもできる。

被呼側クライアントＶｏＰＩデータ・トランシーバにおけるステップ４０３は、作成されたデータ・セッションを用いて発呼側クライアントから受信し、またそれに送信する。

ステップ５０１および５０３は、発呼側クライアントおよび被呼側クライアントにおける各コール・シャットダウン・コンポーネント３２により実施される。この例および実施形態では、発呼側クライアントが終了を開始しているが、いずれのクライアントも終了を開始できる。

ステップ５０１で、終了セッション信号が被呼側クライアントにセキュア・パスに沿って送信される。２０２ ＯＫ信号が受信された後、発呼側クライアント中のデータ・セッションおよびセキュア・パス・セッションは取り消される。

ステップ５０３では、被呼側クライアントは、発呼側クライアントに２０２ ＯＫおよびセッション・キーを送信し、データ・セッションおよびセキュア・セッションを終了する。

図５は、本実施形態および例によるイベント図である。コール・セットアップ中、ＯＰＴＩＯＮ １００信号が発呼側クライアント１０Ａから、プロキシ・サーバを介して被呼側クライアント１０Ｂに送られる。２００ ＯＫ＋セッション・キーが、被呼側クライアントから発呼側クライアントに返される。３００ ＩＮＶＩＴＥ＋セッション・キーが、発呼側クライアントから被呼側クライアントに送信される。２０１ ＯＫ＋セッション・キー＋ＩＰアドレスが、被呼側クライアントから発呼側クライアントに送られる。データ・ストリーム４００が、返されたＩＰアドレスを用いてクライアント間に作成される。コールの終了で、５００ ＢＹＥ信号が、一方のクライアントから、プロキシ・サーバを介して他方のクライアントに送信される。２０２ ＯＫ信号が送り返され、セキュア・セッションおよびデータ・セッションが終了する。

本発明の方法は、図１の例以外の他の論理装置でも適切に実施することができ、またそのような論理手段は、ハードウェア・コンポーネントまたはファームウェア・コンポーネントを含み得ることは当業者には明らかであろう。

本発明の論理構成は、図３および４の例以外の方法の諸ステップを実施するための論理手段を含む論理装置で適切に実施することができ、またこのような論理手段が、例えば、プログラム可能な論理アレイ中に論理ゲートなどのコンポーネントを備え得ることは、当業者には同様に明らかであろう。このような論理構成はさらに、固定されたまたは送信可能な担持体媒体を用いて記憶することが可能な、例えば、仮想ハードウェア記述言語を用いたアレイなどに、一時的にまたは恒久的に論理構造を確立できる手段で実施することができる。

上述の方法はまた、１つまたは複数のプロセッサ（図示せず）で動作するソフトウェア中で完全にまたは部分的に、適切に実施することができ、またそのソフトウェアは、磁気的または光学的なコンピュータ・ディスクなど任意の適切なデータ担持体（これも図示せず）上で担持されるコンピュータ・プログラム・エレメントとして提供され得ることも理解されたい。データ送信用チャネルは同様に、すべての記述を記憶する媒体、ならびに有線または無線の信号媒体などの信号搬送媒体を含むことができる。

本発明は、コンピュータ・システムで用いるためのコンピュータ・プログラムとして適切に実施することができる。このような実装形態は、コンピュータ可読媒体、例えば、ディスケット、ＣＤ−ＲＯＭ、ＲＯＭ、ハードディスクなどの有形な媒体上に固定された、あるいはモデムもしくは他のインターフェース・デバイスを経由して、それだけに限らないが、光もしくはアナログ通信回線を含む有形の媒体を介して、またはそれだけに限らないがマイクロ波、赤外線もしくは他の伝送技法を含む無線技法を用いた無形の媒体を介してコンピュータ・システムに送信可能な、一連のコンピュータ可読命令を含むことができる。一連のコンピュータ可読命令は、本明細書で前述した機能のすべて、または一部分を実施する。

このようなコンピュータ可読命令は、多くのコンピュータ・アーキテクチャまたはオペレーティング・システムで使用するためのいくつかのプログラミング言語で記述できることを当業者であれば理解されたい。さらに、このような命令は、それだけに限らないが、半導体、磁気、もしくは光を含む、現在もしくは将来の任意のメモリ技術を用いて記憶することができ、あるいはそれだけに限らないが、光、赤外線もしくはマイクロ波を含む、現在もしくは将来の任意の通信技術を用いて送信することができる。このようなコンピュータ・プログラムは、添付の印刷もしくは電子文書を有する取外し可能媒体、例えば、収縮包装されたソフトウェアとして分配され、コンピュータ・システムに、例えば、システムＲＯＭもしくは固定ディスク上に事前にロードされ、あるいはサーバもしくはネットワーク、例えば、インターネットもしくはワールド・ワイド・ウェブを介した電子掲示板から分配され得ることが企図されている。

本発明の諸実施形態は、サービスをオンデマンドで提供するために、ユーザに向けて展開されるサービスの形で提供できることがさらに理解されよう。

当業者であれば、上記の好ましい実施形態に対する他の様々な変更形態も明らかであることがさらに理解されよう。

典型的なＳＩＰクライアント、プロキシ・サーバ、およびネットワーク構成の概略図である。 本実施形態のクライアント、プロキシ・サーバ、およびディレクトリ・サーバの概略図である。 本実施形態によるＳＩＰコール・セットアップのうちのＩＰ突き止め部分の概略図である。 本実施形態によるＳＩＰコール・セットアップのうちの送信勧誘部分の概略図である。 本実施形態によるイベント図である。

１０Ａ ＳＩＰクライアント、発呼側クライアント
１０Ｂ ＳＩＰクライアント、被呼側クライアント、宛先クライアント
１２Ａ ＳＩＰプロキシ、プロキシ・サーバ
１２Ｂ ＳＩＰプロキシ、プロキシ・サーバ
１２Ｃ ＳＩＰプロキシ、プロキシ・サーバ
１４Ａ ドメイン・ディレクトリ・サーバ、ＳＩＰディレクトリ・サーバ
１４Ｂ ドメイン・ディレクトリ・サーバ、ＳＩＰディレクトリ・サーバ
１４Ｃ ドメイン・ディレクトリ・サーバ、ＳＩＰディレクトリ・サーバ
１６Ａ ドメイン、ドメイン・ネットワーク
１６Ｂ ドメイン、ドメイン・ネットワーク
１６Ｃ ネットワーク
１８ ネットワーク
２０ コール・セットアップ・コンポーネント
２２ セキュア・プロキシ・ロケータ
２４ オプション・トランシーバ
２６ タイマ
２８ インバイト・トランシーバ
３０ ＶｏＩＰデータ・トランシーバ
３２ コール・シャットダウン・コンポーネント
３４ オプション・フォワーダ
３６ セキュア・クライアント・ロケータ
３８ インバイト・フォワーダ
４０ タイマ
４４ ＩＰアドレス・リゾルバ
４６ ＩＰアドレス・データ

Claims (14)

1. 少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションをセットアップする方法であって、
   宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを、ドメイン・ディレクトリ・サーバを参照して突き止めるステップと、
   発呼側クライアントＳＩＰノードと前記プロキシＳＩＰノードとの間でセキュア信号接続をセットアップするステップと、
   前記宛先クライアント名およびドメインを用いて、前記プロキシＳＩＰノードから宛先クライアントＳＩＰノードのＩＰアドレスを、ドメイン・ディレクトリ・サーバを参照して突き止めるステップと、
   前記プロキシＳＩＰノードから宛先クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップするステップであって、それにより、前記セキュア信号接続および前記追加のセキュア信号接続がセキュア信号パスを形成する、前記セットアップするステップと、
   前記宛先クライアントＳＩＰノードに、前記セキュア信号パスを介してそのＩＰアドレスを返すように要求するステップであって、前記要求によって返されたＩＰアドレスが、前記宛先クライアントＳＩＰノードの前記突き止められたＩＰアドレスと同じではない、前記要求するステップと、
   前記返されたＩＰアドレスを用いて、前記発呼側クライアントＳＩＰノードと前記宛先クライアントＳＩＰノードとの間でデータ接続をセットアップするステップと
   を含む、前記方法。
2. 追加のセキュア信号接続をセットアップするのに使われる時間が閾値時間を超えた場合、新しいプロキシＳＩＰノードが突き止められる、請求項１に記載の方法。
3. 各セキュア信号接続が暗号化される、請求項１又は２に記載の方法。
4. ＳＩＰノード間の各接続が、識別のためのセッション・キーを使用する、請求項１〜３のいずれか一項に記載の方法。
5. 前記セッション・キーが、前記セキュア信号接続の暗号化の一部分である、請求項４に記載の方法。
6. 前記プロキシＳＩＰノードから前記宛先クライアントＳＩＰノードのＩＰアドレスを突き止めるステップが、１つまたは複数の次のプロキシＳＩＰノードを突き止めるステップを含み、前記１つまたは複数の次のプロキシを介して前記セキュア信号接続が拡張される、請求項１〜５のいずれか一項に記載の方法。
7. ２つ以上の宛先クライアントＳＩＰノードがある場合、２つ以上のセキュア・パスがセットアップされる、請求項１〜６のいずれか一項に記載の方法。
8. 少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションをセットアップするためのシステムであって、
   宛先クライアント名およびドメインに基づいて、プロキシＳＩＰノードを、ドメイン・ディレクトリ・サーバを参照して突き止めるためのプロキシ・ロケータと、
   発呼側クライアントＳＩＰノードと前記プロキシＳＩＰノードとの間でセキュア信号接続をセットアップするためのオプション・トランシーバと、
   前記宛先クライアント名およびドメインを用いて、前記プロキシＳＩＰノードで、宛先クライアントＳＩＰノードのＩＰアドレスを、ドメイン・ディレクトリ・サーバを参照して突き止めるためのクライアント・ロケータと、
   前記プロキシＳＩＰノードから宛先クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップするためのオプション・フォワーダであって、し、それにより前記セキュア信号接続および前記追加のセキュア信号接続がセキュア信号パスを形成する、前記オプション・フォワーダと、
   前記宛先クライアントＳＩＰノードに、前記セキュア信号パスを介してそのＩＰアドレスを返すように要求するためのインバイト・トランシーバであって、前記要求によって返されたＩＰアドレスが、前記宛先クライアントＳＩＰノードの前記突き止められたＩＰアドレスと同じではない、前記インバイト・トランシーバと、
   前記発呼側クライアントＳＩＰノードと前記宛先クライアントＳＩＰノードとの間でデータ接続をセットアップするように、前記返されたＩＰアドレスを使用するためのＶｏＩＰデータ・トランシーバと
   を備えている、前記システム。
9. 少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションをセットアップする方法であって、
   発呼側クライアントＳＩＰノードが、宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを、ドメイン・ディレクトリ・サーバを参照して突き止めるステップと、
   発呼側クライアントＳＩＰノードが、前記突き止められたプロキシＳＩＰノードにＯＰＴＩＯＮ信号を送信するステップと、
   前記突き止められたプロキシＳＩＰノードが、前記発呼側クライアントＳＩＰノードから送信されたＯＰＴＩＯＮ信号を受信するステップであって、前記突き止められたプロキシＳＩＰノードは検証済み暗号化セキュア・パス（ＶＥＳＰ）互換である、前記受信するステップと、
   前記突き止められたプロキシＳＩＰノードが、前記宛先クライアント名およびドメインを用いて、宛先クライアントＳＩＰノードのＩＰアドレスを、ドメイン・ディレクトリ・サーバを参照して突き止めるステップと、
   前記突き止められたプロキシＳＩＰノードが、前記受信したＯＰＴＩＯＮ信号を前記突き止められた宛先クライアントＳＩＰノードに転送するステップと、
   前記突き止められた宛先クライアントＳＩＰノードが、前記転送されたＯＰＴＩＯＮ信号を受信するステップであって、前記突き止められた宛先クライアントＳＩＰノードは検証済み暗号化セキュア・パス（ＶＥＳＰ）互換である、前記受信するステップと、
   前記突き止められた宛先クライアントＳＩＰノードが検証済み暗号化セキュア・パス（ＶＥＳＰ）互換であることに応じて、前記突き止められた宛先クライアントＳＩＰノードがＯＫ信号及びセッション・キーを前記突き止められたプロキシＳＩＰノードに返すステップと、
   前記突き止められたプロキシＳＩＰノードが、前記ＯＫ信号及びセッション・キーを前記発呼側クライアントＳＩＰノードに返すステップと、
   前記発呼側クライアントＳＩＰノードが、前記ＯＫ信号及び前記セッション・キーを受信するステップと、
   前記発呼側クライアントＳＩＰノードが、前記セッション・キーを含むＩＮＶＩＴＥ信号を、当該セッション・キー中に定義されたプロキシＳＩＰノードに送信するステップと、
   前記定義されたプロキシＳＩＰノードが、前記発呼側クライアントＳＩＰノードから送信された前記ＩＮＶＩＴＥ信号を受信するステップと、
   前記定義されたプロキシＳＩＰノードが、前記受信したＩＮＶＩＴＥ信号中の前記セッション・キー中に定義された前記宛先クライアントＳＩＰノードに前記受信したＩＮＶＩＴＥ信号を転送するステップと、
   前記定義された宛先クライアントＳＩＰノードが、前記定義されたプロキシＳＩＰノードから送信された前記ＩＮＶＩＴＥ信号を受信するステップと、
   前記定義された宛先クライアントＳＩＰノードが、当該定義された宛先クライアントＳＩＰノードのＩＰアドレス及びセッション・キーを含むＯＫ信号を、前記定義されたプロキシＳＩＰノードに返すステップであって、前記ＯＫ信号中のＩＰアドレスが、前記宛先クライアントＳＩＰノードの前記突き止められたＩＰアドレスと同じではない、前記返すステップと、
   前記定義されたプロキシＳＩＰノードが、前記ＩＰアドレス及び前記セッション・キーを含む前記ＯＫ信号を、前記定義された宛先クライアントＳＩＰノードから受信するステップと、
   前記定義されたプロキシＳＩＰノードが、前記受信した前記ＩＰアドレス及び前記セッション・キーを含む前記ＯＫ信号を、前記発呼側クライアントＳＩＰノードに返すステップと、
   前記発呼側クライアントＳＩＰノードが、前記ＩＰアドレス及び前記セッション・キーを含む前記ＯＫ信号を、前記定義されたプロキシＳＩＰノードから受信するステップと、
   前記発呼側クライアントＳＩＰノードが、前記受信したＯＫ信号中の前記ＩＰアドレスを使用して、前記定義された宛先クライアントＳＩＰノードとＶｏＩＰデータを直接送受信するステップと
   を含む、前記方法。
10. 前記突き止められたプロキシＳＩＰノードが、前記突き止められたプロキシＳＩＰノードからのＯＫ信号を待ち、待ち時間切れになった場合に、他のプロキシＳＩＰノードを選択するステップと、
    前記突き止められたプロキシＳＩＰノードが、前記選択された他のプロキシＳＩＰノードにＯＰＴＩＯＮ信号を送信するステップと、
    前記選択されたプロキシＳＩＰノードが、前記突き止められたプロキシＳＩＰノードから送信されたＯＰＴＩＯＮ信号を受信するステップであって、前記選択されたプロキシＳＩＰノードは検証済み暗号化セキュア・パス（ＶＥＳＰ）互換である、前記受信するステップと、
    前記選択されたプロキシＳＩＰノードが、前記宛先クライアント名およびドメインを用いて、宛先クライアントＳＩＰノードのＩＰアドレスを、ドメイン・ディレクトリ・サーバを参照して突き止めるステップと、
    前記選択されたプロキシＳＩＰノードが、前記受信したＯＰＴＩＯＮ信号を前記突き止められた宛先クライアントＳＩＰノードに転送するステップと、
    前記突き止められた宛先クライアントＳＩＰノードが、前記転送されたＯＰＴＩＯＮ信号を受信するステップであって、前記突き止められた宛先クライアントＳＩＰノードは検証済み暗号化セキュア・パス（ＶＥＳＰ）互換である、前記受信するステップと、
    前記突き止められた宛先クライアントＳＩＰノードが検証済み暗号化セキュア・パス（ＶＥＳＰ）互換であることに応じて、前記突き止められた宛先クライアントＳＩＰノードがＯＫ信号及びセッション・キーを前記選択されたプロキシＳＩＰノードに返すステップと
    をさらに含む、請求項９に記載の方法。
11. 前記定義されたプロキシＳＩＰノードが、前記受信したＩＮＶＩＴＥ信号中の前記セッション・キー中に定義された前記宛先クライアントＳＩＰノードに前記受信したＩＮＶＩＴＥ信号を転送するステップ
    をさらに含む、請求項１０に記載の方法。
12. 前記宛先クライアントＳＩＰノードが、前記受信したＩＮＶＩＴＥ信号中の前記セッション・キー中に定義された前記定義されたプロキシＳＩＰノードに前記受信したＩＮＶＩＴＥ信号を転送するステップ
    をさらに含む、請求項１１に記載の方法。
13. 少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションをセットアップするためのシステムであって、
    発呼側クライアントＳＩＰノードが、宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを、ドメイン・ディレクトリ・サーバを参照して突き止め、
    発呼側クライアントＳＩＰノードが、前記突き止められたプロキシＳＩＰノードにＯＰＴＩＯＮ信号を送信し、
    前記突き止められたプロキシＳＩＰノードが、前記発呼側クライアントＳＩＰノードから送信されたＯＰＴＩＯＮ信号を受信し、ここで、前記突き止められたプロキシＳＩＰノードは検証済み暗号化セキュア・パス（ＶＥＳＰ）互換であり、
    前記突き止められたプロキシＳＩＰノードが、前記宛先クライアント名およびドメインを用いて、宛先クライアントＳＩＰノードのＩＰアドレスを、ドメイン・ディレクトリ・サーバを参照して突き止め、
    前記突き止められたプロキシＳＩＰノードが、前記受信したＯＰＴＩＯＮ信号を前記突き止められた宛先クライアントＳＩＰノードに転送し、
    前記突き止められた宛先クライアントＳＩＰノードが、前記転送されたＯＰＴＩＯＮ信号を受信し、ここで、前記突き止められた宛先クライアントＳＩＰノードは検証済み暗号化セキュア・パス（ＶＥＳＰ）互換であり、
    前記突き止められた宛先クライアントＳＩＰノードが検証済み暗号化セキュア・パス（ＶＥＳＰ）互換であることに応じて、前記突き止められた宛先クライアントＳＩＰノードがＯＫ信号及びセッション・キーを前記突き止められたプロキシＳＩＰノードに返し、
    前記突き止められたプロキシＳＩＰノードが、前記ＯＫ信号及びセッション・キーを前記発呼側クライアントＳＩＰノードに返し、
    前記発呼側クライアントＳＩＰノードが、前記ＯＫ信号及び前記セッション・キーを受信し、
    前記発呼側クライアントＳＩＰノードが、前記セッション・キーを含むＩＮＶＩＴＥ信号を、当該セッション・キー中に定義されたプロキシＳＩＰノードに送信し、
    前記定義されたプロキシＳＩＰノードが、前記発呼側クライアントＳＩＰノードから送信された前記ＩＮＶＩＴＥ信号を受信し、
    前記定義されたプロキシＳＩＰノードが、前記受信したＩＮＶＩＴＥ信号中の前記セッション・キー中に定義された前記宛先クライアントＳＩＰノードに前記受信したＩＮＶＩＴＥ信号を転送し、
    前記定義された宛先クライアントＳＩＰノードが、前記定義されたプロキシＳＩＰノードから送信された前記ＩＮＶＩＴＥ信号を受信し、
    前記定義された宛先クライアントＳＩＰノードが、当該定義された宛先クライアントＳＩＰノードのＩＰアドレス及びセッション・キーを含むＯＫ信号を、前記定義されたプロキシＳＩＰノードに返し、ここで、前記ＯＫ信号中のＩＰアドレスが、前記宛先クライアントＳＩＰノードの前記突き止められたＩＰアドレスと同じではない、
    前記定義されたプロキシＳＩＰノードが、前記ＩＰアドレス及び前記セッション・キーを含む前記ＯＫ信号を、前記定義された宛先クライアントＳＩＰノードから受信し、
    前記定義されたプロキシＳＩＰノードが、前記受信した前記ＩＰアドレス及び前記セッション・キーを含む前記ＯＫ信号を、前記発呼側クライアントＳＩＰノードに返し、
    前記発呼側クライアントＳＩＰノードが、前記ＩＰアドレス及び前記セッション・キーを含む前記ＯＫ信号を、前記定義されたプロキシＳＩＰノードから受信し、
    前記発呼側クライアントＳＩＰノードが、前記受信したＯＫ信号中の前記ＩＰアドレスを使用して、前記定義された宛先クライアントＳＩＰノードとＶｏＩＰデータを直接送受信する、
    前記システム。
14. 少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノード間でＳＩＰ通信セッションをセットアップするためのコンピュータ・プログラムであって、コンピュータに、請求項１〜７のいずれか一項に記載の方法の各ステップを実行させる前記コンピュータ・プログラム。

Images