ＳＩＰシグナリングの暗号化を検証するための方法および装置
【課題】ＳＩＰシグナリングの暗号化の検証のための方法および装置を提供する。
【解決手段】宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを突き止めること、発呼側クライアントＳＩＰノードとプロキシＳＩＰノードの間でセキュア信号接続をセットアップすること、宛先クライアント名およびドメインを用いて、プロキシＳＩＰノードから宛先クライアントＩＰアドレスを特定すること、前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより、セキュア信号接続および追加のセキュア信号接続がセキュア信号パスを形成すること、宛先クライアントＳＩＰノードに、セキュア信号パスを介してそのＩＰアドレスを返すように要求すること、および返されたＩＰアドレスを用いて、発呼側クライアントＳＩＰノードと宛先クライアントＳＩＰノードの間でデータ接続をセットアップする。
【解決手段】宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを突き止めること、発呼側クライアントＳＩＰノードとプロキシＳＩＰノードの間でセキュア信号接続をセットアップすること、宛先クライアント名およびドメインを用いて、プロキシＳＩＰノードから宛先クライアントＩＰアドレスを特定すること、前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより、セキュア信号接続および追加のセキュア信号接続がセキュア信号パスを形成すること、宛先クライアントＳＩＰノードに、セキュア信号パスを介してそのＩＰアドレスを返すように要求すること、および返されたＩＰアドレスを用いて、発呼側クライアントＳＩＰノードと宛先クライアントＳＩＰノードの間でデータ接続をセットアップする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＩＰシグナリングの暗号化を検証するための方法および装置に関する。
【背景技術】
【０００２】
ＳＩＰ（session initiation protocol）は、１つまたは複数の参加者とのセッションを作成し、変更し、終了させることのできるインターネット・プロトコルである。ＳＩＰは、ポイント・ツー・ポイントまたはマルチパーティ・セッションのための音声およびビデオ・コールに使用される。それは、例えば、通常、ＲＴＰ（real-timetransport protocol） ｏｖｅｒ ＵＤＰ（user datagram protocol）を使用するメディア・トランスポートから独立している。ＳＩＰはまた、インスタント・メッセージングおよびプレゼンス検出にも使用される。ＳＩＰにより、複数のエンドポイントが相互にメディア・セッションを確立することができる。ＳＩＰは、エンドポイントの位置を特定し、セッションを確立し、次いで、メディア・セッションが完了した後、そのセッションを終了させることをサポートする。ＳＩＰは、最近では、インスタント・メッセージングおよびコラボレーションのために、また移動体使用者間のプッシュ・ツー・トーク（push-to-talk）サービスのために、企業内にＶｏＩＰ（voiceover internet protocol）などの新しいサービスを導入する有線サービス・プロバイダの間で広く受け入れられ展開されてきている。ＳＩＰを、ＩＰネットワークを介する集中した通信のための最適のプロトコルとして受け入れる業界は広範囲に及んでいる。図１に示すように、ＳＩＰのインフラストラクチャは、クライアント１０Ａ、１０Ｂ、ＳＩＰプロキシ１２Ａ、１２Ｂ、１２Ｃ、ならびにドメイン・ネットワーク１６Ａ、１６Ｂおよびネットワーク１６Ｃ（例えば、インターネット）にわたり展開されるドメイン・ディレクトリ・サーバ１４Ａ、１４Ｂからなる。クライアント１０Ａは、セッションのセットアップ、およびメディア転送を制御するＳＩＰエンドポイントである。クライアント１０Ａは、ＳＩＰ ＵＲＩ（uniformresource identifier）により識別され、それは、ＨＴＴＰ（hypertext transport protocol）と同様のsip:client@domainの形式の固有ＵＲＩである。すべてのユーザ・エージェントは、そのＩＰアドレスで、（ＳＩＰプロキシ１２の１つと同じ場所に配置できる）ＳＩＰディレクトリ・サーバ１４Ａ、１４Ｂ、または１４Ｃに登録することができる。ユーザにより登録されたデバイスのＩＰアドレスに対するＵＲＩのマッピングは、セッションのセットアップ・プロセスの一部分として中間のＳＩＰプロキシおよびディレクトリ・サーバを用いて行われる。ＳＩＰプロトコルの詳細は、J.Rosenberg et al. SIP: Session Initiation Protocol. RFC 3261. IETF, June 2002で見ることができる。ＳＩＰは、クライアント相互間でデータ・セッションをセットアップするための、図５に示すＯＰＴＩＯＮ １００、２００ ＯＫ、３００ ＩＮＶＩＴＥ、ＲＩＮＧＩＮＧ、ＡＣＫ、ＢＹＥなどの一組の制御信号を定義する。それらの信号は、ネットワーク中に展開されるＳＩＰプロキシを介して経路指定される。ドメイン・ディレクトリ・サーバ中のＤＮＳ ＳＲＶ（Domainname system for services）レコードは、特定のドメインに対する名前のＩＰアドレスを見つけるのに使用されるが、そのプロセスは、いくつかの、またしばしば複数のＳＩＰプロキシを使用することができる。
【０００３】
３００ ＩＮＶＩＴＥなど発信クライアントからのすべての要求は、３００ ＩＮＶＩＴＥ信号中に含まれる宛先ＳＩＰ ＵＲＩに基づいて、プロキシにより適切な宛先クライアントに経路指定される。プロキシは、ＳＩＰ ＵＲＩの現在のバインディングを判定するために、ディレクトリ・サーバに照会することができる。メディア交換のために適切なエンドポイントを突き止めるために、クライアント、プロキシ、およびディレクトリ・サーバの間で信号が交換される。スケーラビリティのため、シグナリング負荷を分散させるように複数のプロキシが使用される。通常のセッションは、３００ ＩＮＶＩＴＥ、２０１ ＯＫ応答、およびその応答に対するＡＣＫからなるＳＩＰシグナリングを介して、２つのクライアント間でセットアップされる。コールのセットアップに引き続いて、ＲＴＰ（real time transport protocol）を用いてメディア交換が行われる。セッションは、５００ ＢＹＥおよび２０２ ＯＫメッセージの交換により切断される。図５は、本実施形態による適合された一組のシーケンスを示す。
【０００４】
ＳＩＰは、セッション確立のプロセスと実際のセッションとを区別する。基本的なＳＩＰの理念は、メディア（ＲＴＰストリーム）メッセージからシグナリング（制御）を分離することである。制御信号は、メディア・パスがエンド・ツー・エンドである間、通常、プロキシを介して経路指定される。ＩＮＶＩＴＥのような信号は、メッセージ本体中に、ＳＤＰ（Session Description Protocol）を用いたユーザ・パラメータを含む（Handley, M. and V.Jacobson, SDP: Session Description Protocol, RFC 2327, IETF Apr 1998）。ＳＤＰは、メディア・タイプのためのパラメータ、トランスポート・プロトコル、エンドポイントのＩＰアドレスおよびポート番号などセッションに関する情報を提供する。ＳＤＰを介して交換されるＩＰアドレスおよびポート番号は、セッションのための実際のデータ伝送（メディア・パス）に使用される。それらのパラメータのいずれも、すでに存在するセッション内で行うことができるという以外は３００ ＩＮＶＩＴＥ信号と同じであるＲＥ−ＩＮＶＩＴＥメッセージにより、進行しているセッション中に変更することができる。さらに、クライアントは、既存のセッションを、ＲＥＦＥＲ信号を用いて転送することができる。その信号は、既存のセッションの他のエンドポイントに対して、第３のクライアントとＩＮＶＩＴＥ／ＯＫ／ＡＣＫ交換を開始し、（ＲＥＦＥＲ信号の送信者との）既存のセッションを終了するように命令する。
【０００５】
ＳＩＰ信号は、それが機密情報を含んでいたとしても、デフォルトで、ＵＴＦ−８プレーン・テキスト・エンコード方式を用いて送信される。しかし、プライバシを維持するために、ＳＩＰコールの２つのＩＰコンポーネント、すなわち信号およびデータ・ストリームを暗号化することができる。発呼側クライアントは、第１のプロキシとのシグナリングの暗号化を要求することができるが、その信号を次のＳＩＰサーバが確実に暗号化するための機構がない。シグナリングが暗号化されていない場合、プロキシ間のシグナリングを傍受する任意のＩＰルータが、両方の当事者の識別およびインターネット・プロトコル・アドレスなどのコール情報を識別することも可能である。発呼側クライアントは、信号がネットワーク上をプレーン・テキストで送信されたことに気がつかないはずである。データ・ストリームは、コールのエンドポイントで暗号化され、暗号化解除されることだけが必要であり、それにより、その機密性に高い信頼度が得られるようになる。
【０００６】
代替の解決策は、シグナリングを部分的に暗号化することであり、中間プロキシに必須のＳＩＰヘッダだけをプレーン・テキストで送信する。それは、通常、Ｓ／ＭＩＭＥ（Secure Multipurpose Internet Mail Extension、すなわち、インターネット・メッセージにシグネチャまたは暗号化サービスあるいはその両方を追加するためのフォーマットおよびプロトコル）を用いて実施される。この代替方法は２つの欠点を有する。第１に、部分的な暗号化を使用しているだけなので、機密レベルが完全な暗号化を使用する場合よりも低くなることである。第２に、ＲＦＣ３２６１に記されているように、「しかし、ＳＩＰメッセージ（特にＳＤＰ）の本体を閲覧または変更することを利用する（典型的なプロキシ・サーバではない）ネットワーク中間物はまれであり、したがって、セキュアＭＩＭＥは、その種の中間物が機能するのを妨げる可能性のあることに実施者は留意すべきである。」
【０００７】
最後に、ＳＩＰＳ ＵＲＩを使用することにより、ユーザは、エンド・ツー・エンドの暗号化された移送が保証されないことに留意すべきである。ユーザは、「発呼者から被呼者のドメインまで」（ＲＦＣ３２６１、セクション４．２）の暗号化された移送が保証されるだけである。
【０００８】
ネットワークにおいて通信チャネルを開くために、第１の側が、第２の側に送信勧誘（invitation）を送ることが知られている。プロトコルが合意された後、通信チャネルは安全になり得るが、第１および第２の側のＩＤなどの機密情報を含む最初の送信勧誘は安全ではない。「Securitymechanism 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 agreementfor SIP", RFC3329(http://www.ietf.org/rfc/rfc3329.text)
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従って、本発明の目的は、ＳＩＰシグナリングの暗号化の検証のための方法及び装置を提供することにある。
【課題を解決するための手段】
【００１０】
本発明の第１の態様によると、宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを突き止めること、発呼側クライアントＳＩＰノードとプロキシＳＩＰノードの間でセキュア信号接続をセットアップすること、宛先クライアント名およびドメインを用いて、プロキシＳＩＰノードから宛先クライアントＩＰアドレスを突き止めること、前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより、セキュア信号接続および追加のセキュア信号接続がセキュア信号パスを形成すること、宛先クライアントＳＩＰノードに、セキュア信号パスを介してそのＩＰアドレスを返すように要求すること、および返されたＩＰアドレスを用いて、発呼側クライアントＳＩＰノードと宛先クライアントＳＩＰノードの間でデータ接続をセットアップすることを含む、少なくとも１つのプロキシＳＩＰノードを介して、少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションを開始する方法が提供される。
【００１１】
通信の安全性をさらに改善するために、返されたＩＰアドレスは、特定された宛先ＩＰアドレスと同じではなく、したがって、クライアントの実際のＩＰアドレスは、ディレクトリ中に決して公開されないようにする。
【００１２】
追加のセキュア信号接続をセットアップするのに使われる時間が閾値時間を超えた場合、新しいプロキシＳＩＰの位置が特定されると有利である。セキュア信号接続のセットアップが、セキュア信号接続のためのオプションを含むようにＳＩＰ ＯＰＴＩＯＮＳ信号を拡張するとさらに有利である。
【００１３】
各セキュア信号接続は暗号化されることが好ましい。より好ましくは、ＳＩＰノード間の各接続は、識別のためのセッション・キーを使用し、任意選択で、そのセッション・キーはセキュア信号接続の暗号化の一部分である。
【００１４】
適切には、プロキシから宛先クライアントＩＰアドレスを突き止めるステップが、１つまたは複数の次のプロキシを突き止めることを含み、セキュア信号接続を拡張するステップが、次のプロキシを介してセキュア信号接続を拡張することを含む。
【００１５】
本発明の他の態様によれば、ＳＩＰノードにおけるセキュアＳＩＰ通信方法が提供される。すなわち、ダウンストリームＳＩＰノードから、セキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップすること、宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めること、アップストリームＳＩＰノードへのセキュア信号接続をセットアップすること、およびセキュア信号接続上でＳＩＰ信号を受信し、転送することである。
【００１６】
本発明の他の態様によれば、ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップするためのオプション・フォワーダと、宛先名およびドメインを用いて、アップストリームＳＩＰノードＩＰアドレスを突き止めるためのセキュア・クライアント・ロケータと、アップストリームＳＩＰノードへのセキュア信号接続をセットアップし、かつセキュア信号接続上でＳＩＰ信号を受信し転送するためのインバイト・フォワーダとを備える、ＳＩＰノードにおけるセキュアＳＩＰ通信のシステムが提供される。
【００１７】
本発明の他の態様によると、ＳＩＰノードにおけるセキュアＳＩＰ通信のためのコンピュータ・プログラムであって、コンピュータに、ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信しダウンストリーム接続をセットアップするステップと、宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めるステップと、アップストリームＳＩＰノードへのセキュア信号接続をセットアップするステップと、セキュア信号接続上でＳＩＰ信号を受信し転送するステップとを実行させるためのコンピュータ・プログラムが提供される。
【００１８】
このような方法を用いることにより、コール・セットアップのホップ・バイ・ホップ（完全な暗号化）方法のクライアントは、シグナリングが常に暗号化された形で送信されていたことを検証することができる。検証機構が実施された場合、ＳＩＰ ＵＡおよびプロキシ開発者は、そのコールの暗号化状況に対するユーザ・フィードバックを与えるような機能、またはさらに非暗号化コールが行われるのを妨害し、プレーン・テキストのシグナリングが送信されないようにする機能を追加することができる。
【００１９】
本発明の諸実施形態を、例としてだけであるが、添付の図面を参照し次に説明する。
【発明を実施するための最良の形態】
【００２０】
図１は、ＳＩＰクライアント１０Ａ、１０Ｂ、プロキシ１２Ａ〜１２Ｃ、ドメイン・ネットワーク１６Ａ、１６Ｂ、および外部ネットワーク１８の概略図である。各ネットワーク中に１つのプロキシだけがラベル付けされているが、いくつかのプロキシの任意の１つがネットワーク中に存在し、セキュア・ネットワークを形成するために使用することができる。ＳＩＰクライアント１０Ａ、１０Ｂおよびその各プロキシ１２Ａ、１２Ｂ、およびドメイン・ディレクトリ・サーバ１４Ａ、１４Ｂは、各ドメイン１６Ａおよび１６Ｂ（例えば、会社のイントラネット）中に位置する。ドメイン１６Ａおよび１６Ｂは、ネットワーク１８（例えば、インターネット）を介して共に接続されている。本発明のコンテキストでは、クライアント１０Ａは、最初は、クライアント１０Ｂの名前およびドメイン（例えば、client10B@domain16B）を知っているだけであり、クライアント１０ＢのＩＰアドレス（例えば、123.546.789.000）は知っておらず、したがって、コールをセットアップする前に１０Ｂを突き止める必要がある。突き止めプロセス中に、クライアント１０Ａ、ドメイン１６Ａのプロキシ、例えば１２Ａ、ネットワーク１８のプロキシ、例えば、プロキシ１２Ｃ、ドメイン１６Ｂのプロキシ、例えば、プロキシ１２Ｂ、およびクライアント１０Ｂの間で、通常、接続がセットアップされる。突き止めプロセスからＩＰアドレスが取得されると、データを送信するために、非プロキシ接続１９をセットアップすることができる。宛先クライアント１０ＢのＩＰアドレスを突き止めるために、プロキシ１２Ｂによってドメイン・ディレクトリ・サーバ１４Ｂが使用される。ドメイン１６Ａに対して、ドメイン・ディレクトリ・サーバ１４Ａも同様に行う。このプロキシおよびクライアントの構成は、一例に過ぎず、例えば、２つのクライアントと単一のプロキシ、またはカンファレンス・コールにおける複数のクライアント間など、複数のセキュア接続が必要な場合も、本発明を実施することができる。
【００２１】
図２は、本実施形態のクライアント１０Ａ、プロキシ・サーバ１２Ａ、およびドメイン・ディレクトリ・サーバ１４Ａの概略図である。クライアント１０Ａは、コール・セットアップ・コンポーネント２０、セキュア・プロキシ・ロケータ２２、オプション・トランシーバ２４、タイマ２６、インバイト・トランシーバ２８、ＶｏＩＰデータ・トランシーバ３０、およびコール・シャットダウン・コンポーネント３２を備える。
【００２２】
コール・セットアップ・コンポーネント２０は、他のクライアントとのコールのセットアップを制御する。
【００２３】
セキュア・プロキシ・ロケータ２２は、プロキシとの通信を管理する。それは、そのプロキシを直接、またはメモリに照会することにより、セキュア接続に関して既知のプロキシをフィルタリングする。
【００２４】
オプション・トランシーバ２４は、ＯＰＴＩＯＮ １００信号（図５を参照）を送信し、受信する。ＯＰＴＩＯＮ信号は、コールのセットアップにおいて使用される最初の信号の１つであり、特定のオプション、すなわち、本実施形態の場合は、ＶＥＳＰ（verified encryption secure path：検証済み暗号化セキュア・パス）オプションをプロキシに求める要求を含む。ＶＥＳＰオプションを含むオプション要求が受信され、ＳＩＰクライアントがＶＥＳＰ互換のある場合、オプション・トランシーバ２４は、コール・セットアップの要求を先に進めてＶＥＳＰサポートを示す２００ ＯＫ信号で応答することになる（図５を参照）。そうではない場合、ＳＩＰクライアントは、オプション要求に２００ ＯＫで応答しない。オプション・トランシーバが、２００ ＯＫ信号を受信した場合、制御はインバイト・トランシーバ２８に渡される。
【００２５】
タイマ２６は、ＯＰＴＩＯＮ １００メッセージが送信されたときから、２００ ＯＫ信号が戻って受信されるまでの時間を測定開始する。コール・セットアップ・プロセスは、応答時間がある閾値を超えた場合に時間切れ中止とすることができる。時間切れ中止が生じた場合、オプション・トランシーバ２４は、他のセキュアＳＩＰプロキシを選択し、他のＯＰＴＩＯＮ １００信号を送信する。もはやセキュア・プロキシが存在しない場合、セキュア・コール・セットアップは取り消される。タイマはまた、インバイト・トランシーバ２８中の応答の時間を測るためにも使用される。
【００２６】
インバイト・トランシーバ２８は、インバイト・メッセージおよびセッション・トークンを、ＶＥＳＰ準拠のプロキシに送り、２０１ ＯＫおよびＩＰアドレスを待つ。タイマ２６はまた、待ち時間を測定し、閾値に達した場合は時間切れ中止する。プロセスが時間切れ中止された場合、再度、他のセキュア・プロキシが選択され、またはセキュア・セットアップが取り消される。
【００２７】
ＶｏＩＰデータ・トランシーバ３０は、ＩＰアドレスが発見された後、クライアント間のネットワークを介したＶｏＩＰデータの直接送信を制御する。
【００２８】
コール・シャットダウン・コンポーネント３２は、コールが終了したとき、コールの切断を制御する。
【００２９】
各プロキシ１２は、オプション・フォワーダ３４、セキュア・クライアント・ロケータ３６、インバイト・フォワーダ３８、およびタイマ４０を備える。
【００３０】
オプション・フォワーダ３４は、ＯＰＴＩＯＮ １００信号を受信し、転送する（図５参照）。ＶＥＳＰオプションを含むオプション要求が受信されたとき、オプション・フォワーダ３４は、ＶＥＳＰオプションがセキュア・コール・セットアップを要求していることに気付き、セキュア・クライアントまたはプロキシを突き止めるようにセキュア・クライアント・ロケータ３６に通知する。オプション・フォワーダは、応答として２００ ＯＫ信号を受信し、それをＯＰＴＩＯＮ １００信号の送信者に転送して戻す。
【００３１】
セキュア・クライアント・ロケータ３６は、クライアントのＩＰアドレスを求めてディレクトリ・サーバに照会する。クライアントが突き止められた場合、クライアントＩＰアドレスがプロキシに返される。そうでない場合、他のプロキシのＩＰアドレスが、さらなる照会およびさらなるセキュア・コール・セットアップに対して返される。
【００３２】
セキュア・プロキシ・パスがセットアップされると、ＩＮＶＩＴＥ信号が発信ＳＩＰクライアントにより送られ、またインバイト・フォワーダ３８によって受信される。インバイト・フォワーダは、セキュア・パスに沿ってＩＮＶＩＴＥ信号を転送し、そのパスに沿ってＯＫ信号を返す。
【００３３】
タイマ４０は、オプション・フォワーダ３４およびインバイト・フォワーダの応答待ち時間を計測し、したがって、いずれも閾値を超える期間待つことはない。
【００３４】
各ディレクトリ・サーバ１４は、ＩＰアドレス・リゾルバ４４、およびＩＰアドレス・データ４６を備える。
【００３５】
ＩＰアドレス・リゾルバ４４は、クライアント１０またはプロキシ１２からクライアント名およびドメインを含む要求を受信し、ＩＰアドレスと、名前およびドメインをマッチさせるように試みる。ＩＰアドレス・データ４６からマッチが見つかった場合、それは要求者に送り返される。
【００３６】
図３は、本実施形態によるＳＩＰコール・セットアップの第１の部分の概略図である。
【００３７】
方法１０１は、発呼側クライアント・セットアップ・プロセスを定義する。
【００３８】
ステップ１０４で、セキュア・コール・セットアップは、被呼側クライアント名（例えば、クライアント１０Ｂ）および被呼側クライアント・ドメイン（例えばドメイン１６Ｂ）を用いて、発呼側クライアント・セットアップ・コンポーネント２０中で定義される。
【００３９】
ステップ１０６で、セキュア・プロキシ・ロケータ２２は、既知のプロキシのリストを照会することにより、送出プロキシを突き止める。ＶＥＳＰ互換のないプロキシの名前を必ず知っている必要があり、また各プロキシは、セキュア接続をセットアップする能力が検査されていなければならない。
【００４０】
ステップ１０８では、オプション・トランシーバ２４は、セキュア・プロキシの１つにＯＰＴＩＯＮ １００信号を送信する。ＯＰＴＩＯＮ １００信号は、ＶＥＳＰ互換のあるプロキシに対するオプションを含む。
【００４１】
方法１０９は、ＳＩＰプロキシ・セットアップ・プロセスを定義し、ステップ１１０、１１２、１１４、１２０、１２２および１２４を含む。
【００４２】
ステップ１１０で、ＳＩＰクライアントからのＯＰＴＩＯＮ １００信号が、オプション・フォワーダ３４により受信される。プロキシがＶＥＳＰ互換である場合、ＯＰＴＩＯＮ信号は受け入れられ、制御が次のステップに渡される。
【００４３】
ステップ１１２では、セキュア・クライアント・ロケータ３６は、ディレクトリ・サーバを照会することにより、クライアントＢを突き止めようと試みる。クライアント１０Ｂが突き止められない場合、クライアントのドメインのより近くに存在し、クライアントのＩＰアドレスを知っている可能性のある他のセキュア・プロキシが突き止められる。ドメイン・プロキシは、通常そのドメイン中のクライアントのＩＰアドレスを有する。
【００４４】
ステップ１１４では、ディレクトリ・サーバがクライアントのＩＰアドレスを知っている場合、ＯＰＴＩＯＮ信号（および名前）が、セキュア・クライアントＢに転送される（方法１１６のＳＩＰ被呼側クライアント・セットアップ）。関連するディレクトリ・サーバが、クライアントＢのＩＰアドレスを知らない場合、ＯＰＴＩＯＮ信号は、クライアントのＩＰアドレスを突き止めることができる可能性を有する他のプロキシに転送される（方法１１５の追加の等価なプロキシ・セットアップ）。
【００４５】
プロセス１１５は、等価な諸ステップ１１０、１１２、１１４、１２２、１２０、および１２４を有する最初の１０９ＳＩＰプロキシ・セットアップと等価な１つまたは複数の追加の等価なプロキシ・セットアップを示す。そのプロセスは、被呼側クライアントを突き止めるために必要なプロキシ・サーバの数に応じて、０からｎ回行われる。
【００４６】
方法１１６は、ステップ１１７および１１８を含む被呼側クライアント・セットアップ・プロセスである。
【００４７】
ステップ１１７で、ＯＰＴＩＯＮ信号１００がＳＩＰプロキシから受信される。クライアントがＶＥＳＰ互換である場合、それを受け入れ、プロセスは先に進む。
【００４８】
ステップ１１８で、セッション・トークンが含まれた、返しＯＫ ２００信号が、接続しているプロキシを介してＳＩＰノードに送信される。
【００４９】
方法１１５は、接続中に複数の返しプロキシが存在する場合、ＯＫ ２００信号を転送する。
【００５０】
プロキシ・セットアップ１０９方法（または等価な１１５プロキシ・セットアップ）におけるステップ１２０は、２００ ＯＫ信号を待ち、ステップ１２４に進む。待ち時間切れになった場合、プロセスはステップ１２２に進む。
【００５１】
ステップ１２２は、関連するディレクトリ・サーバから他のセキュア・プロキシを選択し、ステップ１１４で、再度、ＯＰＴＩＯＮ信号を送る。
【００５２】
方法１０９で、ステップ１２４は、ＳＩＰクライアント１０にＯＫ信号を返す。等価なプロキシ・セットアップ方法１１５で、等価なステップ１２４は接続しているプロキシにＯＫ信号を返す。
【００５３】
発呼側クライアント・セットアップ方法１０１のステップ１２６は、２００ ＯＫ信号を待ち、ステップ１３０に進む。セキュア接続パスは、いまや完了し、返されたセッション・トークンによりマーク付けされる。ステップ１２６が時間切れになった場合、プロセスはステップ１２８に進む。
【００５４】
ステップ１２８は、関連するディレクトリから、他のセキュア・プロキシを選択し、ステップ１０８で、再度、ＯＰＴＩＯＮ信号を送る。
【００５５】
ステップ１３０で、プロセス制御は方法３００に進む。
【００５６】
図４は、本実施形態によるＳＩＰコール・セットアップの第２の部分の概略図である。
【００５７】
方法３００は、インバイト・トランシーバ２８において実施されるステップ３０２、３２０、３２２を含む発呼側電話インバイト・プロセスである。
【００５８】
ステップ３０２は、セキュア接続パス中の第１のセキュア・プロキシにセッション・トークンを含むＩＮＶＩＴＥ信号を送る。
【００５９】
方法３０３は、セキュア接続パス中の第１および次のプロキシ中のインバイト・フォワーダ３８で実施されるステップ３０４、３０６、３０８、３１６、および３１８を含むプロキシ・インバイト・プロセスである。
【００６０】
ステップ３０４は、セキュア・クライアントからセッション・トークンを含むＩＮＶＩＴＥ信号を受信する。
【００６１】
ステップ３０６は、割り当てられたセキュア接続パスでセッション・トークンを検査する。接続パス中の次のプロキシまたはクライアントが突き止められる。
【００６２】
ステップ３０８は、セキュア接続パス中の次のセキュア・プロキシにセッション・トークンを含むＩＮＶＩＴＥ信号を転送する。
【００６３】
プロセス３０９は、等価なステップ３０４、３０６、３０８、３１６、および３１８を有する最初の３０３プロキシ・インバイトと等価な１つまたは複数の追加の等価のプロキシ・インバイトを示す。そのプロセスは、必要とされるプロキシ・サーバの数に応じて０からｎ回行われる。
【００６４】
プロセス３１０は、クライアント・インバイト・トランシーバ２８により実施される、またステップ３１２および３１４を含む被呼側クライアント・インバイト方法である。セッション・トークンを含むＩＮＶＩＴＥは、クライアントを突き止めるのに必要な数に応じて１つまたは複数のプロキシから受信される。
【００６５】
ステップ３１２では、インバイト・トランシーバが、セキュアＳＩＰクライアントからセッション・トークンを含むＩＮＶＩＴＥ信号を受信する。そのセッションが受入れ可能であれば、プロセスは先に進む。
【００６６】
ステップ３１４で、インバイト・トランシーバは、被呼側クライアントのＩＰアドレスおよびセッション・キーを含むＯＫ信号２０１で応答する。
【００６７】
プロキシ・インバイト方法３０３で、ステップ３１６は、ＯＫ信号２０１を待つ。等価なプロキシ・インバイト方法３０９では、等価なステップ３１６は１２４のＯＫ信号２０１を待つ。待ち時間切れの場合、接続は失敗する。
【００６８】
ステップ３１８は、ＯＫ信号２０１、ＩＰアドレス、およびセッション・キーを発呼側ＳＩＰクライアントに返す。
【００６９】
発呼側クライアント・インバイト方法のステップ３２０は、ＯＫ信号２０１、ＩＰアドレス、およびセッション・トークンを待つ。待ち時間切れになった場合、プロセスはステップ３２２に進む。その待ちが成功した場合、プロセスは進んで、４０１でＶｏＩＰデータを送信する。
【００７０】
ステップ３２２は、コール・セットアップを他のプロキシ・サーバにセットし直す。
【００７１】
ステップ４０１および４０３は、発呼側クライアント１０Ａおよび被呼側クライアント１０Ｂにおける各ＶｏＩＰトランシーバにより実施される。
【００７２】
発呼側クライアントＶｏＩＰデータ・トランシーバにおけるステップ４０１は、どのプロキシも必要とせずにネットワークを介して被呼側クライアントに直接送信し、また被呼側クライアントから直接受信する。ＶｏＩＰデータ・セッションが作成される。ＶｏＩＰデータは、特別な安全性のために暗号化することもできる。
【００７３】
被呼側クライアントＶｏＰＩデータ・トランシーバにおけるステップ４０３は、作成されたデータ・セッションを用いて発呼側クライアントから受信し、またそれに送信する。
【００７４】
ステップ５０１および５０３は、発呼側クライアントおよび被呼側クライアントにおける各コール・シャットダウン・コンポーネント３２により実施される。この例および実施形態では、発呼側クライアントが終了を開始しているが、いずれのクライアントも終了を開始できる。
【００７５】
ステップ５０１で、終了セッション信号が被呼側クライアントにセキュア・パスに沿って送信される。２０２ ＯＫ信号が受信された後、発呼側クライアント中のデータ・セッションおよびセキュア・パス・セッションは取り消される。
【００７６】
ステップ５０３では、被呼側クライアントは、発呼側クライアントに２０２ ＯＫおよびセッション・トークンを送信し、データ・セッションおよびセキュア・セッションを終了する。
【００７７】
図５は、本実施形態および例によるイベント図である。コール・セットアップ中、ＯＰＴＩＯＮ １００信号が発呼側クライアント１０Ａから、プロキシを介して被呼側クライアント１０Ｂに送られる。２００ ＯＫ＋セッション・キーが、被呼側クライアントから発呼側クライアントに返される。３００ ＩＮＶＩＴＥ＋セッション・キーが、発呼側クライアントから被呼側クライアントに送信される。２０１ ＯＫ＋セッション・キー＋ＩＰアドレスが、被呼側クライアントから発呼側クライアントに送られる。データ・ストリーム４００が、返されたＩＰアドレスを用いてクライアント間に作成される。コールの終了で、５００ ＢＹＥ信号が、一方のクライアントから、プロキシを介して他方のクライアントに送信される。２０２ ＯＫ信号が送り返され、セキュア・セッションおよびデータ・セッションが終了する。
【００７８】
本発明の方法は、図１の例以外の他の論理装置でも適切に実施することができ、またそのような論理手段は、ハードウェア・コンポーネントまたはファームウェア・コンポーネントを含み得ることは当業者には明らかであろう。
【００７９】
本発明の論理構成は、図３および４の例以外の方法の諸ステップを実施するための論理手段を含む論理装置で適切に実施することができ、またこのような論理手段が、例えば、プログラム可能な論理アレイ中に論理ゲートなどのコンポーネントを備え得ることは、当業者には同様に明らかであろう。このような論理構成はさらに、固定されたまたは送信可能な担持体媒体を用いて記憶することが可能な、例えば、仮想ハードウェア記述言語を用いたアレイなどに、一時的にまたは恒久的に論理構造を確立できる手段で実施することができる。
【００８０】
上述の方法はまた、１つまたは複数のプロセッサ（図示せず）で動作するソフトウェア中で完全にまたは部分的に、適切に実施することができ、またそのソフトウェアは、磁気的または光学的なコンピュータ・ディスクなど任意の適切なデータ担持体（これも図示せず）上で担持されるコンピュータ・プログラム・エレメントとして提供され得ることも理解されたい。データ送信用チャネルは同様に、すべての記述を記憶する媒体、ならびに有線または無線の信号媒体などの信号搬送媒体を含むことができる。
【００８１】
本発明は、コンピュータ・システムで用いるためのコンピュータ・プログラムとして適切に実施することができる。このような実装形態は、コンピュータ可読媒体、例えば、ディスケット、ＣＤ−ＲＯＭ、ＲＯＭ、ハードディスクなどの有形な媒体上に固定された、あるいはモデムもしくは他のインターフェース・デバイスを経由して、それだけに限らないが、光もしくはアナログ通信回線を含む有形の媒体を介して、またはそれだけに限らないがマイクロ波、赤外線もしくは他の伝送技法を含む無線技法を用いた無形の媒体を介してコンピュータ・システムに送信可能な、一連のコンピュータ可読命令を含むことができる。一連のコンピュータ可読命令は、本明細書で前述した機能のすべて、または一部分を実施する。
【００８２】
このようなコンピュータ可読命令は、多くのコンピュータ・アーキテクチャまたはオペレーティング・システムで使用するためのいくつかのプログラミング言語で記述できることを当業者であれば理解されたい。さらに、このような命令は、それだけに限らないが、半導体、磁気、もしくは光を含む、現在もしくは将来の任意のメモリ技術を用いて記憶することができ、あるいはそれだけに限らないが、光、赤外線もしくはマイクロ波を含む、現在もしくは将来の任意の通信技術を用いて送信することができる。このようなコンピュータ・プログラムは、添付の印刷もしくは電子文書を有する取外し可能媒体、例えば、収縮包装されたソフトウェアとして分配され、コンピュータ・システムに、例えば、システムＲＯＭもしくは固定ディスク上に事前にロードされ、あるいはサーバもしくはネットワーク、例えば、インターネットもしくはワールド・ワイド・ウェブを介した電子掲示板から分配され得ることが企図されている。
【００８３】
本発明の諸実施形態は、サービスをオンデマンドで提供するために、ユーザに向けて展開されるサービスの形で提供できることがさらに理解されよう。
【００８４】
当業者であれば、上記の好ましい実施形態に対する他の様々な変更形態も明らかであることがさらに理解されよう。
【図面の簡単な説明】
【００８５】
【図１】典型的なＳＩＰクライアント、プロキシ、およびネットワーク構成の概略図である。
【図２】本実施形態のクライアント、プロキシ・サーバ、およびディレクトリ・サーバの概略図である。
【図３】本実施形態によるＳＩＰコール・セットアップのうちのＩＰ突き止め部分の概略図である。
【図４】本実施形態によるＳＩＰコール・セットアップのうちの送信勧誘部分の概略図である。
【図５】本実施形態によるイベント図である。
【符号の説明】
【００８６】
１０Ａ ＳＩＰクライアント、発呼側クライアント
１０Ｂ ＳＩＰクライアント、被呼側クライアント、宛先クライアント
１２Ａ ＳＩＰプロキシ、プロキシ・サーバ
１２Ｂ ＳＩＰプロキシ、プロキシ・サーバ
１２Ｃ ＳＩＰプロキシ、プロキシ・サーバ
１４Ａ ドメイン・ディレクトリ・サーバ、ＳＩＰディレクトリ・サーバ
１４Ｂ ドメイン・ディレクトリ・サーバ、ＳＩＰディレクトリ・サーバ
１４Ｃ ドメイン・ディレクトリ・サーバ、ＳＩＰディレクトリ・サーバ
１６Ａ ドメイン、ドメイン・ネットワーク
１６Ｂ ドメイン、ドメイン・ネットワーク
１６Ｃ ネットワーク
１８ ネットワーク
２０ コール・セットアップ・コンポーネント
２２ セキュア・プロキシ・ロケータ
２４ オプション・トランシーバ
２６ タイマ
２８ インバイト・トランシーバ
３０ ＶｏＩＰデータ・トランシーバ
３２ コール・シャットダウン・コンポーネント
３４ オプション・フォワーダ
３６ セキュア・クライアント・ロケータ
３８ インバイト・フォワーダ
４０ タイマ
４４ ＩＰアドレス・リゾルバ
４６ ＩＰアドレス・データ
【技術分野】
【０００１】
本発明は、ＳＩＰシグナリングの暗号化を検証するための方法および装置に関する。
【背景技術】
【０００２】
ＳＩＰ（session initiation protocol）は、１つまたは複数の参加者とのセッションを作成し、変更し、終了させることのできるインターネット・プロトコルである。ＳＩＰは、ポイント・ツー・ポイントまたはマルチパーティ・セッションのための音声およびビデオ・コールに使用される。それは、例えば、通常、ＲＴＰ（real-timetransport protocol） ｏｖｅｒ ＵＤＰ（user datagram protocol）を使用するメディア・トランスポートから独立している。ＳＩＰはまた、インスタント・メッセージングおよびプレゼンス検出にも使用される。ＳＩＰにより、複数のエンドポイントが相互にメディア・セッションを確立することができる。ＳＩＰは、エンドポイントの位置を特定し、セッションを確立し、次いで、メディア・セッションが完了した後、そのセッションを終了させることをサポートする。ＳＩＰは、最近では、インスタント・メッセージングおよびコラボレーションのために、また移動体使用者間のプッシュ・ツー・トーク（push-to-talk）サービスのために、企業内にＶｏＩＰ（voiceover internet protocol）などの新しいサービスを導入する有線サービス・プロバイダの間で広く受け入れられ展開されてきている。ＳＩＰを、ＩＰネットワークを介する集中した通信のための最適のプロトコルとして受け入れる業界は広範囲に及んでいる。図１に示すように、ＳＩＰのインフラストラクチャは、クライアント１０Ａ、１０Ｂ、ＳＩＰプロキシ１２Ａ、１２Ｂ、１２Ｃ、ならびにドメイン・ネットワーク１６Ａ、１６Ｂおよびネットワーク１６Ｃ（例えば、インターネット）にわたり展開されるドメイン・ディレクトリ・サーバ１４Ａ、１４Ｂからなる。クライアント１０Ａは、セッションのセットアップ、およびメディア転送を制御するＳＩＰエンドポイントである。クライアント１０Ａは、ＳＩＰ ＵＲＩ（uniformresource identifier）により識別され、それは、ＨＴＴＰ（hypertext transport protocol）と同様のsip:client@domainの形式の固有ＵＲＩである。すべてのユーザ・エージェントは、そのＩＰアドレスで、（ＳＩＰプロキシ１２の１つと同じ場所に配置できる）ＳＩＰディレクトリ・サーバ１４Ａ、１４Ｂ、または１４Ｃに登録することができる。ユーザにより登録されたデバイスのＩＰアドレスに対するＵＲＩのマッピングは、セッションのセットアップ・プロセスの一部分として中間のＳＩＰプロキシおよびディレクトリ・サーバを用いて行われる。ＳＩＰプロトコルの詳細は、J.Rosenberg et al. SIP: Session Initiation Protocol. RFC 3261. IETF, June 2002で見ることができる。ＳＩＰは、クライアント相互間でデータ・セッションをセットアップするための、図５に示すＯＰＴＩＯＮ １００、２００ ＯＫ、３００ ＩＮＶＩＴＥ、ＲＩＮＧＩＮＧ、ＡＣＫ、ＢＹＥなどの一組の制御信号を定義する。それらの信号は、ネットワーク中に展開されるＳＩＰプロキシを介して経路指定される。ドメイン・ディレクトリ・サーバ中のＤＮＳ ＳＲＶ（Domainname system for services）レコードは、特定のドメインに対する名前のＩＰアドレスを見つけるのに使用されるが、そのプロセスは、いくつかの、またしばしば複数のＳＩＰプロキシを使用することができる。
【０００３】
３００ ＩＮＶＩＴＥなど発信クライアントからのすべての要求は、３００ ＩＮＶＩＴＥ信号中に含まれる宛先ＳＩＰ ＵＲＩに基づいて、プロキシにより適切な宛先クライアントに経路指定される。プロキシは、ＳＩＰ ＵＲＩの現在のバインディングを判定するために、ディレクトリ・サーバに照会することができる。メディア交換のために適切なエンドポイントを突き止めるために、クライアント、プロキシ、およびディレクトリ・サーバの間で信号が交換される。スケーラビリティのため、シグナリング負荷を分散させるように複数のプロキシが使用される。通常のセッションは、３００ ＩＮＶＩＴＥ、２０１ ＯＫ応答、およびその応答に対するＡＣＫからなるＳＩＰシグナリングを介して、２つのクライアント間でセットアップされる。コールのセットアップに引き続いて、ＲＴＰ（real time transport protocol）を用いてメディア交換が行われる。セッションは、５００ ＢＹＥおよび２０２ ＯＫメッセージの交換により切断される。図５は、本実施形態による適合された一組のシーケンスを示す。
【０００４】
ＳＩＰは、セッション確立のプロセスと実際のセッションとを区別する。基本的なＳＩＰの理念は、メディア（ＲＴＰストリーム）メッセージからシグナリング（制御）を分離することである。制御信号は、メディア・パスがエンド・ツー・エンドである間、通常、プロキシを介して経路指定される。ＩＮＶＩＴＥのような信号は、メッセージ本体中に、ＳＤＰ（Session Description Protocol）を用いたユーザ・パラメータを含む（Handley, M. and V.Jacobson, SDP: Session Description Protocol, RFC 2327, IETF Apr 1998）。ＳＤＰは、メディア・タイプのためのパラメータ、トランスポート・プロトコル、エンドポイントのＩＰアドレスおよびポート番号などセッションに関する情報を提供する。ＳＤＰを介して交換されるＩＰアドレスおよびポート番号は、セッションのための実際のデータ伝送（メディア・パス）に使用される。それらのパラメータのいずれも、すでに存在するセッション内で行うことができるという以外は３００ ＩＮＶＩＴＥ信号と同じであるＲＥ−ＩＮＶＩＴＥメッセージにより、進行しているセッション中に変更することができる。さらに、クライアントは、既存のセッションを、ＲＥＦＥＲ信号を用いて転送することができる。その信号は、既存のセッションの他のエンドポイントに対して、第３のクライアントとＩＮＶＩＴＥ／ＯＫ／ＡＣＫ交換を開始し、（ＲＥＦＥＲ信号の送信者との）既存のセッションを終了するように命令する。
【０００５】
ＳＩＰ信号は、それが機密情報を含んでいたとしても、デフォルトで、ＵＴＦ−８プレーン・テキスト・エンコード方式を用いて送信される。しかし、プライバシを維持するために、ＳＩＰコールの２つのＩＰコンポーネント、すなわち信号およびデータ・ストリームを暗号化することができる。発呼側クライアントは、第１のプロキシとのシグナリングの暗号化を要求することができるが、その信号を次のＳＩＰサーバが確実に暗号化するための機構がない。シグナリングが暗号化されていない場合、プロキシ間のシグナリングを傍受する任意のＩＰルータが、両方の当事者の識別およびインターネット・プロトコル・アドレスなどのコール情報を識別することも可能である。発呼側クライアントは、信号がネットワーク上をプレーン・テキストで送信されたことに気がつかないはずである。データ・ストリームは、コールのエンドポイントで暗号化され、暗号化解除されることだけが必要であり、それにより、その機密性に高い信頼度が得られるようになる。
【０００６】
代替の解決策は、シグナリングを部分的に暗号化することであり、中間プロキシに必須のＳＩＰヘッダだけをプレーン・テキストで送信する。それは、通常、Ｓ／ＭＩＭＥ（Secure Multipurpose Internet Mail Extension、すなわち、インターネット・メッセージにシグネチャまたは暗号化サービスあるいはその両方を追加するためのフォーマットおよびプロトコル）を用いて実施される。この代替方法は２つの欠点を有する。第１に、部分的な暗号化を使用しているだけなので、機密レベルが完全な暗号化を使用する場合よりも低くなることである。第２に、ＲＦＣ３２６１に記されているように、「しかし、ＳＩＰメッセージ（特にＳＤＰ）の本体を閲覧または変更することを利用する（典型的なプロキシ・サーバではない）ネットワーク中間物はまれであり、したがって、セキュアＭＩＭＥは、その種の中間物が機能するのを妨げる可能性のあることに実施者は留意すべきである。」
【０００７】
最後に、ＳＩＰＳ ＵＲＩを使用することにより、ユーザは、エンド・ツー・エンドの暗号化された移送が保証されないことに留意すべきである。ユーザは、「発呼者から被呼者のドメインまで」（ＲＦＣ３２６１、セクション４．２）の暗号化された移送が保証されるだけである。
【０００８】
ネットワークにおいて通信チャネルを開くために、第１の側が、第２の側に送信勧誘（invitation）を送ることが知られている。プロトコルが合意された後、通信チャネルは安全になり得るが、第１および第２の側のＩＤなどの機密情報を含む最初の送信勧誘は安全ではない。「Securitymechanism 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 agreementfor SIP", RFC3329(http://www.ietf.org/rfc/rfc3329.text)
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従って、本発明の目的は、ＳＩＰシグナリングの暗号化の検証のための方法及び装置を提供することにある。
【課題を解決するための手段】
【００１０】
本発明の第１の態様によると、宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを突き止めること、発呼側クライアントＳＩＰノードとプロキシＳＩＰノードの間でセキュア信号接続をセットアップすること、宛先クライアント名およびドメインを用いて、プロキシＳＩＰノードから宛先クライアントＩＰアドレスを突き止めること、前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより、セキュア信号接続および追加のセキュア信号接続がセキュア信号パスを形成すること、宛先クライアントＳＩＰノードに、セキュア信号パスを介してそのＩＰアドレスを返すように要求すること、および返されたＩＰアドレスを用いて、発呼側クライアントＳＩＰノードと宛先クライアントＳＩＰノードの間でデータ接続をセットアップすることを含む、少なくとも１つのプロキシＳＩＰノードを介して、少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションを開始する方法が提供される。
【００１１】
通信の安全性をさらに改善するために、返されたＩＰアドレスは、特定された宛先ＩＰアドレスと同じではなく、したがって、クライアントの実際のＩＰアドレスは、ディレクトリ中に決して公開されないようにする。
【００１２】
追加のセキュア信号接続をセットアップするのに使われる時間が閾値時間を超えた場合、新しいプロキシＳＩＰの位置が特定されると有利である。セキュア信号接続のセットアップが、セキュア信号接続のためのオプションを含むようにＳＩＰ ＯＰＴＩＯＮＳ信号を拡張するとさらに有利である。
【００１３】
各セキュア信号接続は暗号化されることが好ましい。より好ましくは、ＳＩＰノード間の各接続は、識別のためのセッション・キーを使用し、任意選択で、そのセッション・キーはセキュア信号接続の暗号化の一部分である。
【００１４】
適切には、プロキシから宛先クライアントＩＰアドレスを突き止めるステップが、１つまたは複数の次のプロキシを突き止めることを含み、セキュア信号接続を拡張するステップが、次のプロキシを介してセキュア信号接続を拡張することを含む。
【００１５】
本発明の他の態様によれば、ＳＩＰノードにおけるセキュアＳＩＰ通信方法が提供される。すなわち、ダウンストリームＳＩＰノードから、セキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップすること、宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めること、アップストリームＳＩＰノードへのセキュア信号接続をセットアップすること、およびセキュア信号接続上でＳＩＰ信号を受信し、転送することである。
【００１６】
本発明の他の態様によれば、ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップするためのオプション・フォワーダと、宛先名およびドメインを用いて、アップストリームＳＩＰノードＩＰアドレスを突き止めるためのセキュア・クライアント・ロケータと、アップストリームＳＩＰノードへのセキュア信号接続をセットアップし、かつセキュア信号接続上でＳＩＰ信号を受信し転送するためのインバイト・フォワーダとを備える、ＳＩＰノードにおけるセキュアＳＩＰ通信のシステムが提供される。
【００１７】
本発明の他の態様によると、ＳＩＰノードにおけるセキュアＳＩＰ通信のためのコンピュータ・プログラムであって、コンピュータに、ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信しダウンストリーム接続をセットアップするステップと、宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めるステップと、アップストリームＳＩＰノードへのセキュア信号接続をセットアップするステップと、セキュア信号接続上でＳＩＰ信号を受信し転送するステップとを実行させるためのコンピュータ・プログラムが提供される。
【００１８】
このような方法を用いることにより、コール・セットアップのホップ・バイ・ホップ（完全な暗号化）方法のクライアントは、シグナリングが常に暗号化された形で送信されていたことを検証することができる。検証機構が実施された場合、ＳＩＰ ＵＡおよびプロキシ開発者は、そのコールの暗号化状況に対するユーザ・フィードバックを与えるような機能、またはさらに非暗号化コールが行われるのを妨害し、プレーン・テキストのシグナリングが送信されないようにする機能を追加することができる。
【００１９】
本発明の諸実施形態を、例としてだけであるが、添付の図面を参照し次に説明する。
【発明を実施するための最良の形態】
【００２０】
図１は、ＳＩＰクライアント１０Ａ、１０Ｂ、プロキシ１２Ａ〜１２Ｃ、ドメイン・ネットワーク１６Ａ、１６Ｂ、および外部ネットワーク１８の概略図である。各ネットワーク中に１つのプロキシだけがラベル付けされているが、いくつかのプロキシの任意の１つがネットワーク中に存在し、セキュア・ネットワークを形成するために使用することができる。ＳＩＰクライアント１０Ａ、１０Ｂおよびその各プロキシ１２Ａ、１２Ｂ、およびドメイン・ディレクトリ・サーバ１４Ａ、１４Ｂは、各ドメイン１６Ａおよび１６Ｂ（例えば、会社のイントラネット）中に位置する。ドメイン１６Ａおよび１６Ｂは、ネットワーク１８（例えば、インターネット）を介して共に接続されている。本発明のコンテキストでは、クライアント１０Ａは、最初は、クライアント１０Ｂの名前およびドメイン（例えば、client10B@domain16B）を知っているだけであり、クライアント１０ＢのＩＰアドレス（例えば、123.546.789.000）は知っておらず、したがって、コールをセットアップする前に１０Ｂを突き止める必要がある。突き止めプロセス中に、クライアント１０Ａ、ドメイン１６Ａのプロキシ、例えば１２Ａ、ネットワーク１８のプロキシ、例えば、プロキシ１２Ｃ、ドメイン１６Ｂのプロキシ、例えば、プロキシ１２Ｂ、およびクライアント１０Ｂの間で、通常、接続がセットアップされる。突き止めプロセスからＩＰアドレスが取得されると、データを送信するために、非プロキシ接続１９をセットアップすることができる。宛先クライアント１０ＢのＩＰアドレスを突き止めるために、プロキシ１２Ｂによってドメイン・ディレクトリ・サーバ１４Ｂが使用される。ドメイン１６Ａに対して、ドメイン・ディレクトリ・サーバ１４Ａも同様に行う。このプロキシおよびクライアントの構成は、一例に過ぎず、例えば、２つのクライアントと単一のプロキシ、またはカンファレンス・コールにおける複数のクライアント間など、複数のセキュア接続が必要な場合も、本発明を実施することができる。
【００２１】
図２は、本実施形態のクライアント１０Ａ、プロキシ・サーバ１２Ａ、およびドメイン・ディレクトリ・サーバ１４Ａの概略図である。クライアント１０Ａは、コール・セットアップ・コンポーネント２０、セキュア・プロキシ・ロケータ２２、オプション・トランシーバ２４、タイマ２６、インバイト・トランシーバ２８、ＶｏＩＰデータ・トランシーバ３０、およびコール・シャットダウン・コンポーネント３２を備える。
【００２２】
コール・セットアップ・コンポーネント２０は、他のクライアントとのコールのセットアップを制御する。
【００２３】
セキュア・プロキシ・ロケータ２２は、プロキシとの通信を管理する。それは、そのプロキシを直接、またはメモリに照会することにより、セキュア接続に関して既知のプロキシをフィルタリングする。
【００２４】
オプション・トランシーバ２４は、ＯＰＴＩＯＮ １００信号（図５を参照）を送信し、受信する。ＯＰＴＩＯＮ信号は、コールのセットアップにおいて使用される最初の信号の１つであり、特定のオプション、すなわち、本実施形態の場合は、ＶＥＳＰ（verified encryption secure path：検証済み暗号化セキュア・パス）オプションをプロキシに求める要求を含む。ＶＥＳＰオプションを含むオプション要求が受信され、ＳＩＰクライアントがＶＥＳＰ互換のある場合、オプション・トランシーバ２４は、コール・セットアップの要求を先に進めてＶＥＳＰサポートを示す２００ ＯＫ信号で応答することになる（図５を参照）。そうではない場合、ＳＩＰクライアントは、オプション要求に２００ ＯＫで応答しない。オプション・トランシーバが、２００ ＯＫ信号を受信した場合、制御はインバイト・トランシーバ２８に渡される。
【００２５】
タイマ２６は、ＯＰＴＩＯＮ １００メッセージが送信されたときから、２００ ＯＫ信号が戻って受信されるまでの時間を測定開始する。コール・セットアップ・プロセスは、応答時間がある閾値を超えた場合に時間切れ中止とすることができる。時間切れ中止が生じた場合、オプション・トランシーバ２４は、他のセキュアＳＩＰプロキシを選択し、他のＯＰＴＩＯＮ １００信号を送信する。もはやセキュア・プロキシが存在しない場合、セキュア・コール・セットアップは取り消される。タイマはまた、インバイト・トランシーバ２８中の応答の時間を測るためにも使用される。
【００２６】
インバイト・トランシーバ２８は、インバイト・メッセージおよびセッション・トークンを、ＶＥＳＰ準拠のプロキシに送り、２０１ ＯＫおよびＩＰアドレスを待つ。タイマ２６はまた、待ち時間を測定し、閾値に達した場合は時間切れ中止する。プロセスが時間切れ中止された場合、再度、他のセキュア・プロキシが選択され、またはセキュア・セットアップが取り消される。
【００２７】
ＶｏＩＰデータ・トランシーバ３０は、ＩＰアドレスが発見された後、クライアント間のネットワークを介したＶｏＩＰデータの直接送信を制御する。
【００２８】
コール・シャットダウン・コンポーネント３２は、コールが終了したとき、コールの切断を制御する。
【００２９】
各プロキシ１２は、オプション・フォワーダ３４、セキュア・クライアント・ロケータ３６、インバイト・フォワーダ３８、およびタイマ４０を備える。
【００３０】
オプション・フォワーダ３４は、ＯＰＴＩＯＮ １００信号を受信し、転送する（図５参照）。ＶＥＳＰオプションを含むオプション要求が受信されたとき、オプション・フォワーダ３４は、ＶＥＳＰオプションがセキュア・コール・セットアップを要求していることに気付き、セキュア・クライアントまたはプロキシを突き止めるようにセキュア・クライアント・ロケータ３６に通知する。オプション・フォワーダは、応答として２００ ＯＫ信号を受信し、それをＯＰＴＩＯＮ １００信号の送信者に転送して戻す。
【００３１】
セキュア・クライアント・ロケータ３６は、クライアントのＩＰアドレスを求めてディレクトリ・サーバに照会する。クライアントが突き止められた場合、クライアントＩＰアドレスがプロキシに返される。そうでない場合、他のプロキシのＩＰアドレスが、さらなる照会およびさらなるセキュア・コール・セットアップに対して返される。
【００３２】
セキュア・プロキシ・パスがセットアップされると、ＩＮＶＩＴＥ信号が発信ＳＩＰクライアントにより送られ、またインバイト・フォワーダ３８によって受信される。インバイト・フォワーダは、セキュア・パスに沿ってＩＮＶＩＴＥ信号を転送し、そのパスに沿ってＯＫ信号を返す。
【００３３】
タイマ４０は、オプション・フォワーダ３４およびインバイト・フォワーダの応答待ち時間を計測し、したがって、いずれも閾値を超える期間待つことはない。
【００３４】
各ディレクトリ・サーバ１４は、ＩＰアドレス・リゾルバ４４、およびＩＰアドレス・データ４６を備える。
【００３５】
ＩＰアドレス・リゾルバ４４は、クライアント１０またはプロキシ１２からクライアント名およびドメインを含む要求を受信し、ＩＰアドレスと、名前およびドメインをマッチさせるように試みる。ＩＰアドレス・データ４６からマッチが見つかった場合、それは要求者に送り返される。
【００３６】
図３は、本実施形態によるＳＩＰコール・セットアップの第１の部分の概略図である。
【００３７】
方法１０１は、発呼側クライアント・セットアップ・プロセスを定義する。
【００３８】
ステップ１０４で、セキュア・コール・セットアップは、被呼側クライアント名（例えば、クライアント１０Ｂ）および被呼側クライアント・ドメイン（例えばドメイン１６Ｂ）を用いて、発呼側クライアント・セットアップ・コンポーネント２０中で定義される。
【００３９】
ステップ１０６で、セキュア・プロキシ・ロケータ２２は、既知のプロキシのリストを照会することにより、送出プロキシを突き止める。ＶＥＳＰ互換のないプロキシの名前を必ず知っている必要があり、また各プロキシは、セキュア接続をセットアップする能力が検査されていなければならない。
【００４０】
ステップ１０８では、オプション・トランシーバ２４は、セキュア・プロキシの１つにＯＰＴＩＯＮ １００信号を送信する。ＯＰＴＩＯＮ １００信号は、ＶＥＳＰ互換のあるプロキシに対するオプションを含む。
【００４１】
方法１０９は、ＳＩＰプロキシ・セットアップ・プロセスを定義し、ステップ１１０、１１２、１１４、１２０、１２２および１２４を含む。
【００４２】
ステップ１１０で、ＳＩＰクライアントからのＯＰＴＩＯＮ １００信号が、オプション・フォワーダ３４により受信される。プロキシがＶＥＳＰ互換である場合、ＯＰＴＩＯＮ信号は受け入れられ、制御が次のステップに渡される。
【００４３】
ステップ１１２では、セキュア・クライアント・ロケータ３６は、ディレクトリ・サーバを照会することにより、クライアントＢを突き止めようと試みる。クライアント１０Ｂが突き止められない場合、クライアントのドメインのより近くに存在し、クライアントのＩＰアドレスを知っている可能性のある他のセキュア・プロキシが突き止められる。ドメイン・プロキシは、通常そのドメイン中のクライアントのＩＰアドレスを有する。
【００４４】
ステップ１１４では、ディレクトリ・サーバがクライアントのＩＰアドレスを知っている場合、ＯＰＴＩＯＮ信号（および名前）が、セキュア・クライアントＢに転送される（方法１１６のＳＩＰ被呼側クライアント・セットアップ）。関連するディレクトリ・サーバが、クライアントＢのＩＰアドレスを知らない場合、ＯＰＴＩＯＮ信号は、クライアントのＩＰアドレスを突き止めることができる可能性を有する他のプロキシに転送される（方法１１５の追加の等価なプロキシ・セットアップ）。
【００４５】
プロセス１１５は、等価な諸ステップ１１０、１１２、１１４、１２２、１２０、および１２４を有する最初の１０９ＳＩＰプロキシ・セットアップと等価な１つまたは複数の追加の等価なプロキシ・セットアップを示す。そのプロセスは、被呼側クライアントを突き止めるために必要なプロキシ・サーバの数に応じて、０からｎ回行われる。
【００４６】
方法１１６は、ステップ１１７および１１８を含む被呼側クライアント・セットアップ・プロセスである。
【００４７】
ステップ１１７で、ＯＰＴＩＯＮ信号１００がＳＩＰプロキシから受信される。クライアントがＶＥＳＰ互換である場合、それを受け入れ、プロセスは先に進む。
【００４８】
ステップ１１８で、セッション・トークンが含まれた、返しＯＫ ２００信号が、接続しているプロキシを介してＳＩＰノードに送信される。
【００４９】
方法１１５は、接続中に複数の返しプロキシが存在する場合、ＯＫ ２００信号を転送する。
【００５０】
プロキシ・セットアップ１０９方法（または等価な１１５プロキシ・セットアップ）におけるステップ１２０は、２００ ＯＫ信号を待ち、ステップ１２４に進む。待ち時間切れになった場合、プロセスはステップ１２２に進む。
【００５１】
ステップ１２２は、関連するディレクトリ・サーバから他のセキュア・プロキシを選択し、ステップ１１４で、再度、ＯＰＴＩＯＮ信号を送る。
【００５２】
方法１０９で、ステップ１２４は、ＳＩＰクライアント１０にＯＫ信号を返す。等価なプロキシ・セットアップ方法１１５で、等価なステップ１２４は接続しているプロキシにＯＫ信号を返す。
【００５３】
発呼側クライアント・セットアップ方法１０１のステップ１２６は、２００ ＯＫ信号を待ち、ステップ１３０に進む。セキュア接続パスは、いまや完了し、返されたセッション・トークンによりマーク付けされる。ステップ１２６が時間切れになった場合、プロセスはステップ１２８に進む。
【００５４】
ステップ１２８は、関連するディレクトリから、他のセキュア・プロキシを選択し、ステップ１０８で、再度、ＯＰＴＩＯＮ信号を送る。
【００５５】
ステップ１３０で、プロセス制御は方法３００に進む。
【００５６】
図４は、本実施形態によるＳＩＰコール・セットアップの第２の部分の概略図である。
【００５７】
方法３００は、インバイト・トランシーバ２８において実施されるステップ３０２、３２０、３２２を含む発呼側電話インバイト・プロセスである。
【００５８】
ステップ３０２は、セキュア接続パス中の第１のセキュア・プロキシにセッション・トークンを含むＩＮＶＩＴＥ信号を送る。
【００５９】
方法３０３は、セキュア接続パス中の第１および次のプロキシ中のインバイト・フォワーダ３８で実施されるステップ３０４、３０６、３０８、３１６、および３１８を含むプロキシ・インバイト・プロセスである。
【００６０】
ステップ３０４は、セキュア・クライアントからセッション・トークンを含むＩＮＶＩＴＥ信号を受信する。
【００６１】
ステップ３０６は、割り当てられたセキュア接続パスでセッション・トークンを検査する。接続パス中の次のプロキシまたはクライアントが突き止められる。
【００６２】
ステップ３０８は、セキュア接続パス中の次のセキュア・プロキシにセッション・トークンを含むＩＮＶＩＴＥ信号を転送する。
【００６３】
プロセス３０９は、等価なステップ３０４、３０６、３０８、３１６、および３１８を有する最初の３０３プロキシ・インバイトと等価な１つまたは複数の追加の等価のプロキシ・インバイトを示す。そのプロセスは、必要とされるプロキシ・サーバの数に応じて０からｎ回行われる。
【００６４】
プロセス３１０は、クライアント・インバイト・トランシーバ２８により実施される、またステップ３１２および３１４を含む被呼側クライアント・インバイト方法である。セッション・トークンを含むＩＮＶＩＴＥは、クライアントを突き止めるのに必要な数に応じて１つまたは複数のプロキシから受信される。
【００６５】
ステップ３１２では、インバイト・トランシーバが、セキュアＳＩＰクライアントからセッション・トークンを含むＩＮＶＩＴＥ信号を受信する。そのセッションが受入れ可能であれば、プロセスは先に進む。
【００６６】
ステップ３１４で、インバイト・トランシーバは、被呼側クライアントのＩＰアドレスおよびセッション・キーを含むＯＫ信号２０１で応答する。
【００６７】
プロキシ・インバイト方法３０３で、ステップ３１６は、ＯＫ信号２０１を待つ。等価なプロキシ・インバイト方法３０９では、等価なステップ３１６は１２４のＯＫ信号２０１を待つ。待ち時間切れの場合、接続は失敗する。
【００６８】
ステップ３１８は、ＯＫ信号２０１、ＩＰアドレス、およびセッション・キーを発呼側ＳＩＰクライアントに返す。
【００６９】
発呼側クライアント・インバイト方法のステップ３２０は、ＯＫ信号２０１、ＩＰアドレス、およびセッション・トークンを待つ。待ち時間切れになった場合、プロセスはステップ３２２に進む。その待ちが成功した場合、プロセスは進んで、４０１でＶｏＩＰデータを送信する。
【００７０】
ステップ３２２は、コール・セットアップを他のプロキシ・サーバにセットし直す。
【００７１】
ステップ４０１および４０３は、発呼側クライアント１０Ａおよび被呼側クライアント１０Ｂにおける各ＶｏＩＰトランシーバにより実施される。
【００７２】
発呼側クライアントＶｏＩＰデータ・トランシーバにおけるステップ４０１は、どのプロキシも必要とせずにネットワークを介して被呼側クライアントに直接送信し、また被呼側クライアントから直接受信する。ＶｏＩＰデータ・セッションが作成される。ＶｏＩＰデータは、特別な安全性のために暗号化することもできる。
【００７３】
被呼側クライアントＶｏＰＩデータ・トランシーバにおけるステップ４０３は、作成されたデータ・セッションを用いて発呼側クライアントから受信し、またそれに送信する。
【００７４】
ステップ５０１および５０３は、発呼側クライアントおよび被呼側クライアントにおける各コール・シャットダウン・コンポーネント３２により実施される。この例および実施形態では、発呼側クライアントが終了を開始しているが、いずれのクライアントも終了を開始できる。
【００７５】
ステップ５０１で、終了セッション信号が被呼側クライアントにセキュア・パスに沿って送信される。２０２ ＯＫ信号が受信された後、発呼側クライアント中のデータ・セッションおよびセキュア・パス・セッションは取り消される。
【００７６】
ステップ５０３では、被呼側クライアントは、発呼側クライアントに２０２ ＯＫおよびセッション・トークンを送信し、データ・セッションおよびセキュア・セッションを終了する。
【００７７】
図５は、本実施形態および例によるイベント図である。コール・セットアップ中、ＯＰＴＩＯＮ １００信号が発呼側クライアント１０Ａから、プロキシを介して被呼側クライアント１０Ｂに送られる。２００ ＯＫ＋セッション・キーが、被呼側クライアントから発呼側クライアントに返される。３００ ＩＮＶＩＴＥ＋セッション・キーが、発呼側クライアントから被呼側クライアントに送信される。２０１ ＯＫ＋セッション・キー＋ＩＰアドレスが、被呼側クライアントから発呼側クライアントに送られる。データ・ストリーム４００が、返されたＩＰアドレスを用いてクライアント間に作成される。コールの終了で、５００ ＢＹＥ信号が、一方のクライアントから、プロキシを介して他方のクライアントに送信される。２０２ ＯＫ信号が送り返され、セキュア・セッションおよびデータ・セッションが終了する。
【００７８】
本発明の方法は、図１の例以外の他の論理装置でも適切に実施することができ、またそのような論理手段は、ハードウェア・コンポーネントまたはファームウェア・コンポーネントを含み得ることは当業者には明らかであろう。
【００７９】
本発明の論理構成は、図３および４の例以外の方法の諸ステップを実施するための論理手段を含む論理装置で適切に実施することができ、またこのような論理手段が、例えば、プログラム可能な論理アレイ中に論理ゲートなどのコンポーネントを備え得ることは、当業者には同様に明らかであろう。このような論理構成はさらに、固定されたまたは送信可能な担持体媒体を用いて記憶することが可能な、例えば、仮想ハードウェア記述言語を用いたアレイなどに、一時的にまたは恒久的に論理構造を確立できる手段で実施することができる。
【００８０】
上述の方法はまた、１つまたは複数のプロセッサ（図示せず）で動作するソフトウェア中で完全にまたは部分的に、適切に実施することができ、またそのソフトウェアは、磁気的または光学的なコンピュータ・ディスクなど任意の適切なデータ担持体（これも図示せず）上で担持されるコンピュータ・プログラム・エレメントとして提供され得ることも理解されたい。データ送信用チャネルは同様に、すべての記述を記憶する媒体、ならびに有線または無線の信号媒体などの信号搬送媒体を含むことができる。
【００８１】
本発明は、コンピュータ・システムで用いるためのコンピュータ・プログラムとして適切に実施することができる。このような実装形態は、コンピュータ可読媒体、例えば、ディスケット、ＣＤ−ＲＯＭ、ＲＯＭ、ハードディスクなどの有形な媒体上に固定された、あるいはモデムもしくは他のインターフェース・デバイスを経由して、それだけに限らないが、光もしくはアナログ通信回線を含む有形の媒体を介して、またはそれだけに限らないがマイクロ波、赤外線もしくは他の伝送技法を含む無線技法を用いた無形の媒体を介してコンピュータ・システムに送信可能な、一連のコンピュータ可読命令を含むことができる。一連のコンピュータ可読命令は、本明細書で前述した機能のすべて、または一部分を実施する。
【００８２】
このようなコンピュータ可読命令は、多くのコンピュータ・アーキテクチャまたはオペレーティング・システムで使用するためのいくつかのプログラミング言語で記述できることを当業者であれば理解されたい。さらに、このような命令は、それだけに限らないが、半導体、磁気、もしくは光を含む、現在もしくは将来の任意のメモリ技術を用いて記憶することができ、あるいはそれだけに限らないが、光、赤外線もしくはマイクロ波を含む、現在もしくは将来の任意の通信技術を用いて送信することができる。このようなコンピュータ・プログラムは、添付の印刷もしくは電子文書を有する取外し可能媒体、例えば、収縮包装されたソフトウェアとして分配され、コンピュータ・システムに、例えば、システムＲＯＭもしくは固定ディスク上に事前にロードされ、あるいはサーバもしくはネットワーク、例えば、インターネットもしくはワールド・ワイド・ウェブを介した電子掲示板から分配され得ることが企図されている。
【００８３】
本発明の諸実施形態は、サービスをオンデマンドで提供するために、ユーザに向けて展開されるサービスの形で提供できることがさらに理解されよう。
【００８４】
当業者であれば、上記の好ましい実施形態に対する他の様々な変更形態も明らかであることがさらに理解されよう。
【図面の簡単な説明】
【００８５】
【図１】典型的なＳＩＰクライアント、プロキシ、およびネットワーク構成の概略図である。
【図２】本実施形態のクライアント、プロキシ・サーバ、およびディレクトリ・サーバの概略図である。
【図３】本実施形態によるＳＩＰコール・セットアップのうちのＩＰ突き止め部分の概略図である。
【図４】本実施形態によるＳＩＰコール・セットアップのうちの送信勧誘部分の概略図である。
【図５】本実施形態によるイベント図である。
【符号の説明】
【００８６】
１０Ａ ＳＩＰクライアント、発呼側クライアント
１０Ｂ ＳＩＰクライアント、被呼側クライアント、宛先クライアント
１２Ａ ＳＩＰプロキシ、プロキシ・サーバ
１２Ｂ ＳＩＰプロキシ、プロキシ・サーバ
１２Ｃ ＳＩＰプロキシ、プロキシ・サーバ
１４Ａ ドメイン・ディレクトリ・サーバ、ＳＩＰディレクトリ・サーバ
１４Ｂ ドメイン・ディレクトリ・サーバ、ＳＩＰディレクトリ・サーバ
１４Ｃ ドメイン・ディレクトリ・サーバ、ＳＩＰディレクトリ・サーバ
１６Ａ ドメイン、ドメイン・ネットワーク
１６Ｂ ドメイン、ドメイン・ネットワーク
１６Ｃ ネットワーク
１８ ネットワーク
２０ コール・セットアップ・コンポーネント
２２ セキュア・プロキシ・ロケータ
２４ オプション・トランシーバ
２６ タイマ
２８ インバイト・トランシーバ
３０ ＶｏＩＰデータ・トランシーバ
３２ コール・シャットダウン・コンポーネント
３４ オプション・フォワーダ
３６ セキュア・クライアント・ロケータ
３８ インバイト・フォワーダ
４０ タイマ
４４ ＩＰアドレス・リゾルバ
４６ ＩＰアドレス・データ
【特許請求の範囲】
【請求項１】
少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションをセットアップする方法であって、
宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを突き止めるステップと、
発呼側クライアントＳＩＰノードと前記プロキシＳＩＰノードの間でセキュア信号接続をセットアップするステップと、
前記宛先クライアント名およびドメインを用いて、前記プロキシＳＩＰノードから宛先クライアントＩＰアドレスを突き止めるステップと、
前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより、前記セキュア信号接続および前記追加のセキュア信号接続がセキュア信号パスを形成するステップと、
前記宛先クライアントＳＩＰノードに、前記セキュア信号パスを介してそのＩＰアドレスを返すように要求するステップと、
返されたＩＰアドレスを用いて、前記発呼側クライアントＳＩＰノードと前記宛先クライアントＳＩＰノードの間でデータ接続をセットアップするステップと
を含む方法。
【請求項２】
前記返されたＩＰアドレスが、特定された宛先ＩＰアドレスと同じではない、請求項１に記載の方法。
【請求項３】
追加のセキュア信号接続をセットアップするのに使われる時間が閾値時間を超えた場合、新しいプロキシＳＩＰが突き止められる、請求項１または２に記載の方法。
【請求項４】
前記セキュア信号接続のセットアップが、セキュア信号接続のためのオプションを含むようにＳＩＰ ＯＰＴＩＯＮＳ信号を拡張する、請求項１、２または３に記載の方法。
【請求項５】
各セキュア信号接続が暗号化される、請求項１ないし４のいずれか一項に記載の方法。
【請求項６】
ＳＩＰノード間の各接続が、識別のためのセッション・キーを使用する、請求項１ないし５のいずれか一項に記載の方法。
【請求項７】
前記セッション・キーが、前記セキュア信号接続の暗号化の一部分である、請求項６に記載の方法。
【請求項８】
前記プロキシから宛先クライアントＩＰアドレスを突き止めるステップが、１つまたは複数の次のプロキシを突き止めるステップを含み、前記セキュア信号接続を拡張するステップが、前記次のプロキシを介して前記セキュア信号接続を拡張するステップを含む、請求項１ないし７のいずれか一項に記載の方法。
【請求項９】
２つ以上の宛先クライアントがある場合、２つ以上のセキュア・パスがセットアップされる、請求項１ないし８のいずれか一項に記載の方法。
【請求項１０】
少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションをセットアップするためのシステムであって、
宛先クライアント名およびドメインに基づいて、プロキシＳＩＰノードを突き止めるためのプロキシ・ロケータと、
発呼側クライアントＳＩＰノードと前記プロキシＳＩＰノードの間でセキュア信号接続をセットアップするためのオプション・トランシーバと、
前記宛先クライアント名およびドメインを用いて、前記プロキシＳＩＰノードで、宛先クライアントＩＰアドレスを突き止めるためのクライアント・ロケータと、
前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより前記セキュア信号接続および前記追加のセキュア信号接続がセキュア信号パスを形成するためのオプション・フォワーダと、
前記宛先クライアントＳＩＰノードに、前記セキュア信号パスを介してそのＩＰアドレスを返すように要求するためのインバイト・トランシーバと、
前記発呼側クライアントＳＩＰノードと前記宛先クライアントＳＩＰノードの間でデータ接続をセットアップするように、返されたＩＰアドレスを使用するためのＶｏＩＰデータ・トランシーバと
を備えるシステム。
【請求項１１】
少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノード間でＳＩＰ通信セッションをセットアップするためのコンピュータ・プログラムであって、コンピュータに、
宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを突き止めるステップと、
発呼側クライアントＳＩＰノードと前記プロキシＳＩＰノードの間でセキュア信号接続をセットアップするステップと、
前記宛先クライアント名およびドメインを用いて、前記プロキシＳＩＰノードから前記宛先クライアントＩＰアドレスを突き止めるステップと、
前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより、前記セキュア信号接続および前記追加のセキュア信号接続が、セキュア信号パスを形成するステップと、
前記宛先クライアントＳＩＰノードに前記セキュア信号パスを介してそのＩＰアドレスを返すように要求するステップと、
前記返されたＩＰアドレスを用いて、前記発呼側クライアントＳＩＰノードと前記宛先クライアントＳＩＰノードの間でデータ接続をセットアップするステップと
を実行させるためのコンピュータ・プログラム。
【請求項１２】
ＳＩＰノードにおけるセキュアＳＩＰ通信の方法であって、
ダウンストリームＳＩＰノードから、セキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップするステップと、
宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めるステップと、
前記アップストリームＳＩＰノードへのセキュア信号接続をセットアップするステップと、
前記セキュア信号接続上でＳＩＰ信号を受信し、転送するステップを含む方法。
【請求項１３】
ＳＩＰノードにおけるセキュアＳＩＰ通信のシステムであって、
ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップするためのオプション・フォワーダと、
宛先名およびドメインを用いて、アップストリームＳＩＰノードＩＰアドレスを突き止めるためのセキュア・クライアント・ロケータと、
前記アップストリームＳＩＰノードへのセキュア信号接続をセットアップし、かつ前記セキュア信号接続上でＳＩＰ信号を受信し転送するためのインバイト・フォワーダとを備えるシステム。
【請求項１４】
ＳＩＰノードにおけるセキュアＳＩＰ通信のためのコンピュータ・プログラムであって、コンピュータに、
ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信し、前記ダウンストリーム接続をセットアップするステップと、
宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めるステップと、
前記アップストリームＳＩＰノードへのセキュア信号接続をセットアップするステップと、
前記セキュア信号接続上でＳＩＰ信号を受信し転送するステップと
を実行させるためのコンピュータ・プログラム。
【請求項１】
少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションをセットアップする方法であって、
宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを突き止めるステップと、
発呼側クライアントＳＩＰノードと前記プロキシＳＩＰノードの間でセキュア信号接続をセットアップするステップと、
前記宛先クライアント名およびドメインを用いて、前記プロキシＳＩＰノードから宛先クライアントＩＰアドレスを突き止めるステップと、
前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより、前記セキュア信号接続および前記追加のセキュア信号接続がセキュア信号パスを形成するステップと、
前記宛先クライアントＳＩＰノードに、前記セキュア信号パスを介してそのＩＰアドレスを返すように要求するステップと、
返されたＩＰアドレスを用いて、前記発呼側クライアントＳＩＰノードと前記宛先クライアントＳＩＰノードの間でデータ接続をセットアップするステップと
を含む方法。
【請求項２】
前記返されたＩＰアドレスが、特定された宛先ＩＰアドレスと同じではない、請求項１に記載の方法。
【請求項３】
追加のセキュア信号接続をセットアップするのに使われる時間が閾値時間を超えた場合、新しいプロキシＳＩＰが突き止められる、請求項１または２に記載の方法。
【請求項４】
前記セキュア信号接続のセットアップが、セキュア信号接続のためのオプションを含むようにＳＩＰ ＯＰＴＩＯＮＳ信号を拡張する、請求項１、２または３に記載の方法。
【請求項５】
各セキュア信号接続が暗号化される、請求項１ないし４のいずれか一項に記載の方法。
【請求項６】
ＳＩＰノード間の各接続が、識別のためのセッション・キーを使用する、請求項１ないし５のいずれか一項に記載の方法。
【請求項７】
前記セッション・キーが、前記セキュア信号接続の暗号化の一部分である、請求項６に記載の方法。
【請求項８】
前記プロキシから宛先クライアントＩＰアドレスを突き止めるステップが、１つまたは複数の次のプロキシを突き止めるステップを含み、前記セキュア信号接続を拡張するステップが、前記次のプロキシを介して前記セキュア信号接続を拡張するステップを含む、請求項１ないし７のいずれか一項に記載の方法。
【請求項９】
２つ以上の宛先クライアントがある場合、２つ以上のセキュア・パスがセットアップされる、請求項１ないし８のいずれか一項に記載の方法。
【請求項１０】
少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノードの間でＳＩＰ通信セッションをセットアップするためのシステムであって、
宛先クライアント名およびドメインに基づいて、プロキシＳＩＰノードを突き止めるためのプロキシ・ロケータと、
発呼側クライアントＳＩＰノードと前記プロキシＳＩＰノードの間でセキュア信号接続をセットアップするためのオプション・トランシーバと、
前記宛先クライアント名およびドメインを用いて、前記プロキシＳＩＰノードで、宛先クライアントＩＰアドレスを突き止めるためのクライアント・ロケータと、
前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより前記セキュア信号接続および前記追加のセキュア信号接続がセキュア信号パスを形成するためのオプション・フォワーダと、
前記宛先クライアントＳＩＰノードに、前記セキュア信号パスを介してそのＩＰアドレスを返すように要求するためのインバイト・トランシーバと、
前記発呼側クライアントＳＩＰノードと前記宛先クライアントＳＩＰノードの間でデータ接続をセットアップするように、返されたＩＰアドレスを使用するためのＶｏＩＰデータ・トランシーバと
を備えるシステム。
【請求項１１】
少なくとも１つのプロキシＳＩＰノードを介して少なくとも２つのクライアントＳＩＰノード間でＳＩＰ通信セッションをセットアップするためのコンピュータ・プログラムであって、コンピュータに、
宛先クライアント名およびドメインに基づいてプロキシＳＩＰノードを突き止めるステップと、
発呼側クライアントＳＩＰノードと前記プロキシＳＩＰノードの間でセキュア信号接続をセットアップするステップと、
前記宛先クライアント名およびドメインを用いて、前記プロキシＳＩＰノードから前記宛先クライアントＩＰアドレスを突き止めるステップと、
前記プロキシＳＩＰノードから被呼側クライアントＳＩＰノードまで、追加のセキュア信号接続をセットアップし、それにより、前記セキュア信号接続および前記追加のセキュア信号接続が、セキュア信号パスを形成するステップと、
前記宛先クライアントＳＩＰノードに前記セキュア信号パスを介してそのＩＰアドレスを返すように要求するステップと、
前記返されたＩＰアドレスを用いて、前記発呼側クライアントＳＩＰノードと前記宛先クライアントＳＩＰノードの間でデータ接続をセットアップするステップと
を実行させるためのコンピュータ・プログラム。
【請求項１２】
ＳＩＰノードにおけるセキュアＳＩＰ通信の方法であって、
ダウンストリームＳＩＰノードから、セキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップするステップと、
宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めるステップと、
前記アップストリームＳＩＰノードへのセキュア信号接続をセットアップするステップと、
前記セキュア信号接続上でＳＩＰ信号を受信し、転送するステップを含む方法。
【請求項１３】
ＳＩＰノードにおけるセキュアＳＩＰ通信のシステムであって、
ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信し、ダウンストリーム接続をセットアップするためのオプション・フォワーダと、
宛先名およびドメインを用いて、アップストリームＳＩＰノードＩＰアドレスを突き止めるためのセキュア・クライアント・ロケータと、
前記アップストリームＳＩＰノードへのセキュア信号接続をセットアップし、かつ前記セキュア信号接続上でＳＩＰ信号を受信し転送するためのインバイト・フォワーダとを備えるシステム。
【請求項１４】
ＳＩＰノードにおけるセキュアＳＩＰ通信のためのコンピュータ・プログラムであって、コンピュータに、
ダウンストリームＳＩＰノードからセキュア信号接続をセットアップするための要求を受信し、前記ダウンストリーム接続をセットアップするステップと、
宛先名およびドメインを用いてアップストリームＳＩＰノードＩＰアドレスを突き止めるステップと、
前記アップストリームＳＩＰノードへのセキュア信号接続をセットアップするステップと、
前記セキュア信号接続上でＳＩＰ信号を受信し転送するステップと
を実行させるためのコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００７−１１０７０５（Ｐ２００７−１１０７０５Ａ）
【公開日】平成１９年４月２６日（２００７．４．２６）
【国際特許分類】
【出願番号】特願２００６−２５８１２９（Ｐ２００６−２５８１２９）
【出願日】平成１８年９月２２日（２００６．９．２２）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公開日】平成１９年４月２６日（２００７．４．２６）
【国際特許分類】
【出願日】平成１８年９月２２日（２００６．９．２２）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]