(57)【要約】着信シグナリング・メッセージのパラメータのセットから前記着信シグナリング・メッセージのシグネチャを計算することと、このシグネチャを着信シグナリング・メッセージの特定のパラメータに挿入される値と比較することによってループを検出することとからなるループ検出機構（ＬＤ）を含むＳＩＰプロキシであって、前記送信手段（ＥＭＳ）が、シグネチャを、着信シグナリング・メッセージ（ｍｅ）に対応する発信シグナリング・メッセージ（ｍｓ）の特定のパラメータに挿入することを特徴とするＳＩＰプロキシ。これは、ＩＭＳタイプの通信アーキテクチャに適用可能である。
2009540711.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワーク（Ｎ）から発するＳＩＰプロトコルに従う着信シグナリング・メッセージ「ｍｅ」用の受信手段（ＲＣＰ）と、前記着信シグナリング・メッセージのパラメータのうちのいくつかをおそらくは変更する、前記着信シグナリング・メッセージから発信シグナリング・メッセージ（ｍｓ）を提供する処理手段（ＴＲＴ）と、前記通信ネットワーク（Ｎ）上に前記発信シグナリング・メッセージ（ｍｓ）を送信する送信手段（ＥＭＳ）とを含むＳＩＰプロキシであって、前記受信手段が、着信シグナリング・メッセージのパラメータのセットから前記着信シグナリング・メッセージのシグネチャを計算することと、前記シグネチャを前記着信シグナリング・メッセージの特定のパラメータに挿入された値と比較することによってループを検出することとからなるループ検出機構を含み、前記送信手段（ＥＭＳ）が、前記シグネチャを前記着信シグナリング・メッセージ（ｍｅ）に対応する前記発信シグナリング・メッセージ（ｍｓ）の前記特定のパラメータに挿入することを特徴とする、ＳＩＰプロキシ。
【請求項２】
前記特定のパラメータが、「ｂｒａｎｃｈ」パラメータであり、前記シグネチャが、英数字ストリングである、請求項１に記載のプロキシ。
【請求項３】
パラメータの前記セットが、単一のランダム識別子を除外した「ｖｉａ」パラメータを含む、請求項１または２に記載のプロキシ。
【請求項４】
パラメータの前記セットが、少なくとも、「Ｆｒｏｍ」、「Ｔｏ」、「Ｃａｌｌ  Ｉｄ」、「Ｒｏｕｔｅ」、「Ｖｉａ」、「Ｑｕｅｒｙ  ＵＲＩ」、「Ｐｒｏｘｙ  Ａｕｔｈｏｒｉｚａｔｉｏｎ」、「Ｐｒｏｘｙ  ｒｅｑｕｉｒｅ」、「ＣＳｅｑ」を含む、請求項３に記載のプロキシ。
【請求項５】
パラメータの前記セットが、「ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｆｏｒｋ−ｌｏｏｐ−ｆｉｘ−０４．ｔｘｔ」に従う、請求項１または２に記載のプロキシ。
【請求項６】
前記シグネチャが、ダッシュなどのセパレータによって前記「ｂｒａｎｃｈ」パラメータの他の値から分離される、請求項１乃至５のいずれか１項に記載のプロキシ。
【請求項７】
前記プロキシを表しこれを一義に識別するマーカーを前記発信メッセージに挿入する手段と、着信シグナリング・メッセージ内に前記プロキシを識別するマーカーがない場合に前記着信シグナリング・メッセージの前記計算を合図しない手段とをも有する、請求項１乃至６のいずれか１項に記載のプロキシ。
【請求項８】
前記マーカーが、前記プロキシの物理アドレスに基づく、請求項７に記載のプロキシ。
【請求項９】
前記マーカーが、ネーミング・サーバから入手される、請求項７に記載のプロキシ。
【請求項１０】
ＩＭＳ標準規格に従い、複数のＰ−ＣＳＣＦ、Ｉ−ＣＳＣＦ、およびＳ−ＣＳＣＦタイプのプロキシを含み、前記プロキシのうちの少なくとも１つが請求項１乃至９のいずれか１項に従うことを特徴とする通信アーキテクチャ。
【請求項１１】
通過される各プロキシが、着信シグナリング・メッセージを受信し、おそらくは前記着信シグナリング・メッセージのいくつかのパラメータを変更して、前記着信シグナリング・メッセージから発信シグナリング・メッセージを出力し、前記発信シグナリング・メッセージを送信する、通信ネットワーク内のプロキシのセット内で、特にＳＩＰプロトコルに従うシグナリング・メッセージを送信する方法であって、前記着信シグナリング・メッセージのパラメータのセットから始めてシグネチャを計算することと、前記シグネチャを前記着信シグナリング・メッセージの特定のパラメータに挿入された値と比較することによってループを検出することとからなるループ検出機構が使用される方法であって、前記シグネチャが、前記着信シグナリング・メッセージに対応する前記発信シグナリング・メッセージの前記特定のパラメータに挿入されることを特徴とする方法。
【請求項１２】
前記特定のパラメータが、「ｂｒａｎｃｈ」パラメータであり、前記シグネチャが、英数字ストリングである、請求項１１に記載の方法。
【請求項１３】
パラメータの前記セットが、単一のランダム識別子を除外した「ｖｉａ」パラメータを含む、請求項１１または１２に記載の方法。
【請求項１４】
パラメータの前記セットが、少なくとも、「Ｆｒｏｍ」、「Ｔｏ」、「Ｃａｌｌ  Ｉｄ」、「Ｒｏｕｔｅ」、「Ｖｉａ」、「Ｑｕｅｒｙ  ＵＲＩ」、「Ｐｒｏｘｙ  Ａｕｔｈｏｒｉｚａｔｉｏｎ」、「Ｐｒｏｘｙ  ｒｅｑｕｉｒｅ」、「ＣＳｅｑ」を含む、請求項１３に記載の方法。
【請求項１５】
パラメータの前記セットが、「ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｆｏｒｋ−ｌｏｏｐ−ｆｉｘ−０４．ｔｘｔ」に従う、請求項１１または１２に記載の方法。
【請求項１６】
前記シグネチャが、セパレータまたはダッシュによって前記「ｂｒａｎｃｈ」パラメータの他の値から分離される、請求項１３乃至１５のいずれか１項に記載の方法。
【請求項１７】
前記プロキシを表しこれを一義に識別するマーカーが、前記発信メッセージに挿入され、前記着信シグナリング・メッセージ内に前記プロキシを識別するマーカーがない場合に前記着信シグナリング・メッセージのシグネチャ計算が行われない、請求項１１乃至１６のいずれか１項に記載の方法。
【請求項１８】
前記マーカーが、前記プロキシの物理アドレスに基づく、請求項１７に記載の方法。
【請求項１９】
前記マーカーが、ネーミング・サーバから入手される、請求項１７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット通信ネットワークでマルチメディア・セッションをセット・アップするためのシグナリングに関し、より具体的には、そのようなネットワークでのＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）プロトコルの使用に関する。
【０００２】
本発明の一特定の応用は、排他的シグナリング・プロトコルとしてＳＩＰプロトコルを推奨する３ＧＰＰ標準化組織およびＴｉＳｐａｎ標準化組織によって定義されるようなＩＭＳ（Ｉｎｔｅｒｎｅｔ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）タイプのネットワーク・アーキテクチャにある。
【背景技術】
【０００３】
このＳＩＰプロトコルは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）によって作られたＲＦＣ  ３２６１に記載されている。その目的は、ＩＰ（インターネット・プロトコル）プロトコル・スタック上で動作するパケット通信ネットワークでのマルチメディア・セッションのセット・アップおよび制御（変更、終了など）を可能にすることである。ＳＩＰプロトコルは、マルチメディア・セッションの両方の当事者が互いを認証し、互いの位置を判定し、おそらくはセッション自体のトランスポートに使用できるメディアのタイプを折衝することを可能にする。
【０００４】
ＩＴＵ（国際電気通信連合）によって確立されたＭＧＣＰまたはＨ．３２３など、類似する目的を有する他のプロトコルがあるが、ＳＩＰプロトコルは、今や、特に３ＧＰＰによるＩＭＳアーキテクチャ用のシグナリング・プロトコルとしての選択に起因して、現在優勢になりつつある。
【０００５】
ＳＩＰプロトコルは、通信ネットワーク内で使用される本質的に２タイプの要素すなわち「ユーザ・エージェント」および「ＳＩＰプロキシ」を認識する。ユーザ・エージェントは、主に、マイクロコンピュータ、ＳＩＰ電話機、または携帯情報端末（ＰＤＡ）などの端末である。
【０００６】
これらの端末は、メッセージを「物理的に」突き止め、ルーティングするＩＰ（インターネット・プロトコル）アドレスを有し、また、より抽象的な識別子であり、物理的ＩＰアドレスと独立に端末を識別するのに使用されるＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ（ＵＲＩ）を有する。
【０００７】
発呼端末が、それが呼び出すことを求める端末のＩＰアドレスを知っている場合に、その発呼端末は、そのＩＰアドレスにＳＩＰ照会を送信することによってセッションを開始することができる。しかし、一般的に言って、端末は、そのＵＲＩを介して相互にお互いを知るのみである。
【０００８】
第２のタイプのネットワーク要素が、ＳＩＰプロキシである。従来、ＳＩＰメッセージは、ＩＰアドレスとＵＲＩとの間の関連付けを行うという主な仕事を有するこれらのＳＩＰプロキシを介して通過する。したがって、送信端末は、被呼端末のＵＲＩにメッセージを送信し、ＩＰアドレスとＵＲＩアドレスとの間の関連付けにアクセスできるＳＩＰプロキシ（１つまたは複数）は、被呼端末にメッセージをルーティングすることができる。
【０００９】
ＳＩＰプロキシのもう１つの役割は、アプリケーション・サーバを呼び出すことである。これらのアプリケーションは、非常にさまざまなタイプを有するものである場合がある。例には、送り状作成アプリケーション、呼制御アプリケーション（フィルタリング、着信転送、ボイス・ボックスなど）、ゲーム、複数のプロトコルの間の相互作用を引き起こすことができるコンバージェンス・アプリケーション（ｃｏｎｖｅｒｇｅｎｃｅ  ａｐｐｌｉｃａｔｉｏｎ）などが含まれる。
【００１０】
図１に、２つのネットワークＮ１およびＮ２を含む典型的なＩＭＳタイプ・アーキテクチャを示す。端末Ａは、第１ネットワークに接続され、端末Ｂは、第２ネットワークに接続される。
【００１１】
端末ＡおよびＢは、それぞれＳＩＰプロキシＰ−ＣＳＣＦ１およびＰ−ＣＳＣＦ２を介して、それぞれに対応するネットワークに接続される。ＳＩＰプロキシＰ−ＣＳＣＦすなわち「Ｐｒｏｘｙ  −  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ」の主な仕事は、端末に入力点を提供することである。
【００１２】
２つのネットワークＮ１およびＮ２は、それぞれ、他の通信ネットワークへのインターフェースを提供することを目的とするＳＩＰプロキシＩ−ＣＳＣＦ１およびＩ−ＣＳＣＦ２すなわち「Ｉｎｔｅｒｒｏｇａｔｉｎｇ  −  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ」、ならびに、上で述べたように異なるタイプのサービスを含む１つまたは複数のアプリケーション・サーバＡＰ２と遠隔通信ネットワークとをインターフェースするＳＩＰプロキシＳ−ＣＳＣＦ１およびＳ−ＣＳＣＦ２すなわち「Ｓｅｒｖｉｎｇ  −  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ」をも含む。
【００１３】
ＳＩＰクエリが、端末Ｂとのセッションをセット・アップするために端末Ａによって送信される。このＳＩＰクエリは、端末ＢのＵＲＩを含む「ゲスト」クエリである。このクエリは、端末Ａの唯一の既知の入力点である機能プロキシＰ−ＣＳＣＦ１に送信される。端末Ａは、端末Ｂが通信ネットワークＮ１内にないと判定し、したがって、このクエリをＩ−ＣＳＣＦ１機能プロキシに送信し、Ｉ−ＣＳＣＦ１機能プロキシ自体は、このクエリを通信ネットワークＮ２内のその分身であるＩ−ＣＳＣＦ２に送信する。通信ネットワークＮ２は、このＳＩＰクエリを機能プロキシＳ−ＣＳＣＦ２に送信し、その結果、端末Ｂ（存在する場合に）のために提供されるサービスを実施できるようになる（支払い、フィルタリング、着信転送など）。
【００１４】
提供されるサービスごとに、変更されたＳＩＰクエリが、アプリケーション・サーバＡＰ２に送信される。図１の例では、３つのクエリｍ１、ｍ２、およびｍ３が送信され、アプリケーション・サーバからの３つの応答ｒ１、ｒ２、およびｒ３を生成する。
【００１５】
通信ネットワークは、特に接続できる端末および使用可能なサービスの個数の増加に起因して、より複雑になる傾向があり、したがって、より多くのＳＩＰシグナリングが、必要になりつつあり、より制御しにくくなりつつある。
【００１６】
いくつかの場合に、ＳＩＰメッセージが、変更されずに同一のＳＩＰプロキシを複数回通過することがありえる。スパイラル内の「ループ」と通常は呼ばれるこの現象を認識することが重要である。スパイラル内では、ＳＩＰメッセージは、やはり同一プロキシを複数回通過するが、各通過中に変更される。したがって、ＳＩＰメッセージｍ１、ｍ２、ｍ３、ｒ１、ｒ２、およびｒ３がＳＩＰプロキシＳ−ＣＳＣＦ２とアプリケーション・サーバＡＰ２との間で交換される図１に示された状況は、通常のスパイラル・ケースである。
【００１７】
スパイラルは、ＳＩＰシグナリングの正常な挙動であるが、ループは、異常な現象である。
【００１８】
ＲＦＣ  ３２６１のセクション６「Ｄｅｆｉｎｉｔｉｏｎｓ」に、これらのループおよびスパイラル現象の定義が含まれる。
【００１９】
上で述べたＲＦＣ  ３２６１は、セクション１６．３および１６．６でＳＩＰプロキシによるループ検出手段の使用を許容した。
【００２０】
説明した原理を、図２に概略的に示す。
【００２１】
ＳＩＰプロキシは、着信シグナリング・メッセージ「ｍｅ」用の受信手段ＲＣＰ、前記着信シグナリング・メッセージ「ｍｅ」から発信シグナリング・メッセージ「ｍｓ」を作り、おそらくはそのパラメータの一部を変更する、処理手段ＴＲＴ、および発信シグナリング・メッセージ（ｍｓ）を通信ネットワークに再送信する送信手段ＥＭＳを含む。
【００２２】
ループは、それぞれ着信メッセージ（ｍｅ）および発信メッセージ（ｍｓ）のパラメータのセットに関するシグネチャを計算する２つのモジュールＳＲおよびＳＥを受信手段に含めることによって検出される。
【００２３】
モジュールＳＲからの出力に、受信手段は、シグネチャ計算の結果を着信メッセージの特定のパラメータに挿入された値と比較するモジュールＣＭＰを含む。
【００２４】
計算されたシグネチャがこの値と等しい場合には、同一のメッセージが既に受信されており、ループ（スパイラルではなく）が発生している。その後、この着信メッセージを破壊することができ、ループ検出エラー・メッセージを送信側に送信することができる。
【００２５】
そうではない場合には、着信メッセージが、本質的に処理手段によって既知の形で処理され、発信メッセージに変換され、この発信メッセージは、正常な挙動中には、１つまたは複数のパラメータの値において着信メッセージと異ならなければならない。したがって、メッセージのたどる経路を定義するパラメータが、通常は変更されなければならない。
【００２６】
ＳＥモジュールは、これらの変更されたパラメータに基づいて新しいシグネチャを計算し、挿入モジュールＩＮＳが、このシグネチャを特定のパラメータに挿入する。
【００２７】
したがって、ループは、シグナリング・メッセージ・パラメータ（具体的には、たどられる経路に関するパラメータ）の変化の欠如によって検出される。
【００２８】
しかし、ＩＥＴＦ  ＲＦＣは、この機構をオプションと考えている。この機構は、機械リソースに関して極端に高価なので、明らかに一度も実施されたことがない。
【００２９】
ＲＦＣ  ３２６１によって推奨されるループ検出機構は、モジュールＳＲおよびＳＥでの２つのシグネチャ計算を必要とするという主要な不利益を有する。これらのシグネチャ計算は、複雑な演算である。ＳＩＰプロトコルは、テキスト・プロトコルなので、長い文字列の操作を必要とし、この操作は、ＳＩＰプロキシの機械リソースに関して高価である。
【００３０】
ＳＩＰプロキシが使用されるたびに「Ｍａｘ  Ｆｏｒｗａｒｄ」カウンタを減分することと、このカウンタが０まで減分されたならばメッセージがループを作らなければならず、その再送信に割り込まなければならないと考えることとからなる、もう１つのはるかにより単純な機構が、必ず使用される。この機構も、ＲＦＣ  ３２６１に記載されている。
【００３１】
しかし、ごく最近に、ＳＩＰシグナリングでループを制限することが極端に重要であることと、反復カウンタ機構が非常に不適切であることとが観察された。２００６年３月に公表され、ＩＥＴＦインターネット・サイトで入手可能なｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｆｏｒｋ−ｌｏｏｐ−ｆｉｘ−０１．ｔｘｔ文書は、悪意のある人が非常に少ない努力で通信ネットワークをブロックできる状況を提示している。特定の構成の２つのＳＩＰプロキシを用いて２つの端末を記録することによって、これらの端末宛の各メッセージが、ＳＩＰプロキシによって複製され、他方のＳＩＰプロキシに転送される。この転送および複製の手順は、「Ｍａｘ  Ｆｏｒｗａｒｄ」カウンタによってのみ制限される組合せ爆発を引き起こす。伝統的に、このカウンタは、８０と等しい値に固定され、この値は、あるＳＩＰメッセージが通常挙動中に受け入れることのできるＳＩＰプロキシの個数と、ループの異常な挙動中に発生するものとの間のよい妥協を与える。
【００３２】
この大きさの値を用いると、最終結果は、合計２７０個のＳＩＰメッセージであり、これは、数時間にわたって通信ネットワークをブロックすることができる。
【００３３】
悪意のある攻撃のこの極端だが可能なケースとは別に、この文書は、ＳＩＰプロトコルに基づくアーキテクチャの脆弱性を記述している。
【００３４】
したがって、ＳＩＰプロキシ内でループ検出機構をセット・アップすることが、最優先の重要性を有する。
【非特許文献１】ＲＦＣ  ３２６１
【非特許文献２】ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｆｏｒｋ−ｌｏｏｐ−ｆｉｘ−０１．ｔｘｔ
【非特許文献３】ＲＦＣ  ３２６５
【非特許文献４】ＲＦＣ  ３２６２
【非特許文献５】ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｆｏｒｋ−ｌｏｏｐ−ｆｉｘ−０４．ｔｘｔ
【非特許文献６】ＲＦＣ  １３２１
【非特許文献７】ｄｒａｆｔ−ｃａｍｐｅｎ−ｓｉｐｐｉｎｇ−ｓｔａｃｋ−ｌｏｏｐ−ｄｅｔｅｃｔ−００．ｔｘｔ
【非特許文献８】ＲＦＣ  ３６０８
【発明の開示】
【発明が解決しようとする課題】
【００３５】
本発明の目的は、より少ない機械リソースを必要とするという利益を有するループ検出機構を提示することである。
【課題を解決するための手段】
【００３６】
より正確には、本発明の第１目的は、
−ＳＩＰプロトコルに従い、通信ネットワークから発する着信シグナリング・メッセージの受信の手段と、
−これらの着信シグナリング・メッセージのパラメータのうちのいくつかをおそらくは変更する、これらの着信シグナリング・メッセージから発信シグナリング・メッセージを提供する処理手段と、
−着信シグナリング・メッセージのパラメータのセットからこのメッセージのシグネチャを計算することと、このシグネチャを着信シグナリング・メッセージの特定のパラメータに挿入された値と比較することによってループを検出することとからなるループ検出機構を含む、通信ネットワーク上に発信シグナリング・メッセージを送信する送信手段と
を含むＳＩＰプロキシである。
【００３７】
本発明によるＳＩＰプロキシは、送信手段が、シグネチャを着信シグナリング・メッセージに対応する発信シグナリング・メッセージの特定のパラメータに挿入することにおいて革新的である。
【００３８】
したがって、単一のシグネチャ計算が、ＳＩＰプロキシによって、受信手段内で実行される。
【００３９】
これは、ループの検出に伴う余分なコストのほとんどを表し、したがって、本発明による機構は、この余分なコストを半分だけ減らす。
【００４０】
次に、通常のＳＩＰシグナリング・トラフィックでの余分なコストを最小にすることによって、ループ検出機構を実施することが可能になる。
【００４１】
本発明の第２の目的は、ＩＭＳ標準規格に従い、複数のＰ−ＣＳＣＦ、Ｉ−ＣＳＣＦ、およびＳ−ＣＳＣＦタイプのＳＩＰプロキシを含み、少なくとも１つのＳＩＰプロキシが上で説明した本発明の第１目的に従う、通信アーキテクチャである。
【００４２】
本発明の第３の目的は、通過される各ＳＩＰプロキシが、
−着信シグナリング・メッセージを受信し、
−おそらくはこの着信シグナリング・メッセージのいくつかのパラメータを変更して、この着信シグナリング・メッセージから発信シグナリング・メッセージを出力し、
−発信シグナリング・メッセージを送信する、
通信ネットワーク内のＳＩＰプロキシのセット内での、特にＳＩＰプロトコルに従うシグナリング・メッセージの送信のプロセスである。
【００４３】
着信シグナリング・メッセージのパラメータのセットから始めてシグネチャを計算することと、このシグネチャを着信シグナリング・メッセージの特定のパラメータに挿入された値と比較することによってループを検出することとからなるループ検出機構が使用される。
【００４４】
本発明による方法は、シグネチャが、着信シグナリング・メッセージに対応する発信シグナリング・メッセージの特定のパラメータに挿入されることを特徴とする。
【００４５】
本発明およびその利益は、関連する図面に関する次の説明からより明瞭になる。
【発明を実施するための最良の形態】
【００４６】
本質的に既知の形で、ＳＩＰプロキシを、受信手段ＲＣＰ、処理手段ＴＲＴ、および送信手段ＥＭＳに機能的に分割することができる。
【００４７】
受信手段ＲＣＰは、ＳＩＰプロキシの入力インターフェースを介して通信ネットワークから発するシグナリング・メッセージ「ｍｅ」を受信する。
【００４８】
これらのシグナリング・メッセージ「ｍｅ」は、現在ＩＥＴＦ  ＲＦＣ  ３２６１によっておよびこの基本プロトコルを強化する拡張によって定義されるＳＩＰプロトコルに従う。ＳＩＰプロトコルに対する拡張の例は、ＲＦＣ  ３２６５、「Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  （ＳＩＰ）  −  Ｓｐｅｃｉｆｉｃ  Ｅｖｅｎｔ  Ｎｏｔｉｆｉｃａｔｉｏｎ」、およびＲＦＣ  ３２６２、「Ｒｅｌｉａｂｉｌｉｔｙ  ｏｆ  Ｐｒｏｖｉｓｉｏｎａｌ  Ｒｅｓｐｏｎｓｅｓ  ｉｎ  ｔｈｅ  Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  （ＳＩＰ）」を含む。
【００４９】
受信手段ＲＣＰは、着信シグナリング・メッセージ・パラメータのセットからシグネチャを計算するモジュールＳＲを含む。
【００５０】
このパラメータのセットは、ＲＦＣ  ３２６１によって供給される。このセットは、次からなる。
−シグナリング・メッセージの送信側および宛先の論理名を識別する「Ｆｒｏｍ」パラメータおよび「Ｔｏ」パラメータのタグ。
−２つの当事者の間のセッションを識別する「Ｃａｌｌ  ＩＤ」パラメータ。
−メッセージをその最終的な宛先にルーティングするために従うべき経路を与える「Ｒｏｕｔｅ」パラメータ。
−宛先のＵＲＩを与える「Ｑｕｅｒｙ  ＵＲＩ」パラメータ。「Ｒｏｕｔｅ」パラメータがない場合に、このパラメータは、ルーティングを達成するために、次に到達すべきＳＩＰプロキシに対応する値によって各ホップで変更され、メッセージは、その最終的な宛先のより近くに徐々に移動する。
−あるセッション内のシグナリング・メッセージの順序番号を示すＣＳｅｑパラメータ。
−それぞれ２つのＳＩＰプロキシの間またはＳＩＰプロキシとアプリケーション・サーバとの間でのサービスおよび認証の折衝に使用される「Ｐｒｏｘｙ  ｒｅｑｕｉｒｅ」パラメータおよび「ｐｒｏｘｙ  ａｕｔｈｏｒｉｚａｔｉｏｎ」パラメータ。
−および、前のＳＩＰプロキシに関する情報を含む、このリストの最後の「Ｖｉａ」パラメータ。
【００５１】
これらのパラメータは、本明細書でさらには説明しないが、当業者は、これらの異なるパラメータの内容および使用をよりよく理解するために、ＲＦＣ  ３２６１またはＳＩＰプロトコルに関する任意の他の文書を参照することができるはずである。
【００５２】
しかし、「Ｖｉａ」パラメータは、より詳細な調査に値する。各ＳＩＰプロキシは、少なくとも、それが応答を受信することを望むアドレスと、応答と送信されたメッセージとを相関させるのにそのＳＩＰプロキシが使用する単一の（「ｂｒａｎｃｈ」）識別子とを含む新しい「Ｖｉａ」パラメータを追加する。この一意識別子は、部分的にランダムに生成される。
【００５３】
したがって、シグナリング・メッセージは、「Ｖｉａ」パラメータ・リストを含む。このリストの最後は、シグナリング・メッセージが通過する最後のＳＩＰプロキシに対応する。
【００５４】
ＳＩＰシグナリング・メッセージ（またはＳＩＰシグナリング・メッセージの先頭）の例を、下に与える。
（コマンド）
【００５５】
ＲＦＣ  ３２６１によれば、リスト内の最後の「Ｖｉａ」パラメータは、その全体を解釈されなければならない。しかし、このより詳細な調査は、一意識別子を、検討されるパラメータのセットから抽出しなければならないことを示す。この一意識別子は、部分的にランダムに生成されるので、毎回異なる。この「ｂｒａｎｃｈ」パラメータの値によってのみ変更されるメッセージは、ループ状況にあるはずである。したがって、ＲＦＣ  ３２６１によって提案されるアルゴリズムは、ループを検出することができず、変更されなければならない。
【００５６】
本発明の一実施形態によれば、検討されなければならないすべてのパラメータは、この単一のランダム識別子を除く、リスト内の最後の「Ｖｉａ」パラメータを含む。
【００５７】
さらに、このパラメータのセットは、好ましくは、上で述べたパラメータのセットからならなければならないが、ＳＩＰプロトコルに対する拡張によって定義される任意の他のパラメータが、ネットワーク内のＳＩＰメッセージのルーティングに影響する場合には、そのパラメータをこのリストに追加することが、それでも可能である。
【００５８】
本願の優先日以降のより最近の研究に、シグネチャを計算するために考慮に入れなければならないリストが記載されている。この研究は、現在ＲＦＣ（Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔ）になろうとしているＩＥＴＦドラフト「ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｆｏｒｋ−ｌｏｏｐ−ｆｉｘ−０４．ｔｘｔ」で現在提示されている。
【００５９】
この文書は、シグネチャ計算を使用するループ検出機構をセット・アップすることを、したがって上で説明した問題をより重要にすることを義務にする。
【００６０】
したがって、本発明の一実施形態によれば、すべてのパラメータが、「ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｆｏｒｋ−ｌｏｏｐ−ｆｉｘ−０４．ｔｘｔ」（および後続ＲＦＣ）に従う。
【００６１】
次に、シグネチャは、このパラメータのセットから開始して計算される。シグネチャは、このパラメータのセットの縮小データ表現である。同一パラメータのセットについて、シグネチャは、必ず同一になり、その結果、シグネチャの値を調査することが、すべてのパラメータの変動に関する結論を引き出すのに十分になる。
【００６２】
この計算は、通常、ＩＥＴＦ  ＲＦＣ  １３２１、名称「ＭＤ５  −  Ｍｅｓｓａｇｅ  Ｄｉｇｅｓｔ  Ａｌｇｏｒｉｔｈｍ  ５」に従う。次に、シグネチャは、検討されるすべてのパラメータの１６進ストリング表現である。
【００６３】
このＣＭＰモジュールの目的は、このシグネチャを着信シグナリング・メッセージ「ｍｅ」の特定のパラメータに挿入された値のリストと比較することである。
【００６４】
この特定のパラメータは、「Ｖｉａ」パラメータの「ｂｒａｎｃｈ」パラメータとすることができ、その値は、明瞭に定義された位置で、たとえば上で述べた識別子に続き、ダッシュによってこの識別子から区切られて、このパラメータに挿入することができる。
【００６５】
この２つの値が等しい場合には、着信シグナリング・メッセージ「ｍｅ」は、ＳＩＰプロキシによって最後に処理された時以降に変更されていない。考慮に入れられるパラメータのセットは、メッセージの機能的宛先要素のアドレスを含むので、これは、最終的な処理が、このメッセージを現在もう一度処理している現在のプロキシと同一のＳＩＰプロキシによって行われたことを意味する。したがって、我々は、現在ループ内にいる。
【００６６】
次に、着信シグナリング・メッセージ「ｍｅ」を破壊することができ、エラー・メッセージを送信側に送信することができる。たとえば、このエラー・メッセージを、タイプ４８２（「Ｌｏｏｐ  Ｄｅｔｅｃｔｅｄ」）エラー・メッセージとすることができる。
【００６７】
シグネチャと着信シグナリング・メッセージ「ｍｅ」の特定のパラメータに挿入される値とが異なる場合には、我々は、ループ内にはおらず、その着信シグナリング・メッセージは、処理手段ＴＲＴに送られる。それと同時に、シグネチャが、ＢＵＦメモリ内に記憶される。
【００６８】
処理モジュールＴＲＴによって行われる処理は、最先端技術およびＲＦＣ  ３２６１で与えられる情報に従う。
【００６９】
着信シグナリング・メッセージは、通常、発信シグナリング・メッセージｍｓを与えるために変更される。変更は、シグナリング・メッセージのルーティングに関するパラメータを扱い、上で見たように、ＳＩＰプロトコルに固有の機構は、シグナリング・メッセージをその最終的な宛先に向けてルーティングするために、各ホップでいくつかのパラメータを変更することからなる。
【００７０】
したがって、パラメータのセットを変更できないことは、異常なループ挙動と考えることができる。
【００７１】
その後、発信シグナリング・メッセージ（ｍｓ）が、送信手段ＥＭＳに送られる。これらの送信手段は、本質的に、ＢＵＦメモリに記憶されたシグネチャを、そのシグネチャを計算するのに使用された着信シグナリング・メッセージに対応する発信シグナリング・メッセージの特定のパラメータに挿入するという目的を有する挿入モジュールＩＮＳを含む。
【００７２】
特定のパラメータおよびこの特定のパラメータ内の正確な位置は、比較モジュールＣＭＰによる比較に使用されるものと同一である。
【００７３】
ＲＦＣ  ３２６１で提示される最先端技術と比較して、単一のシグネチャ計算が、ＳＩＰプロキシによって実行される。これが可能にされるのは、入力として行われる計算が出力としての挿入に使用されるからである。
【００７４】
当業者は、発信シグナリング・メッセージｍｓに挿入されるシグネチャが、検討されるパラメータのセットの値と一貫しないことを認めるであろう。したがって、先験的に、本発明は、期待される結果を提供しない。
【００７５】
しかし、図４に示された例は、本発明によるＳＩＰプロキシの動作のさらなる詳細を与えることができる。シグナリング・メッセージが、パラメータのセットＰ１と共にＳＩＰプロキシＳＰに入る。ＳＩＰプロキシＳＰは、このパラメータのセットＰ１に対するシグネチャＳ［Ｐ１］を計算し、次に、これらのパラメータをパラメータの第２セットＰ２に変更し、最後に、パラメータのセットＰ２およびシグネチャＳ［Ｐ１］を含む発信シグナリング・メッセージを送信する。
【００７６】
このシグナリング・メッセージは、その後、直接にまたは他のＳＩＰプロキシ（図示せず）を介してのいずれかで、同一のＳＩＰプロキシＳＰに送信される。
【００７７】
次に、新しいシグネチャＳ［Ｐ２］が計算され、ＳＩＰプロキシは、このシグネチャＳ［Ｐ２］を着信メッセージの特定のパラメータに含まれるシグネチャＳ［Ｐ１］と比較する。これらのシグネチャは異なるので、ループは検出されないが、ＲＦＣ  ３２６１に記載の機構に従うＳＩＰプロキシは、これを検出しているはずである。
【００７８】
したがって、このメッセージは、処理手段に送られる。しかし、我々はループ状況にいるので、パラメータＰ２の一部は変更されず、したがって、発信シグナリング・メッセージは、入力で計算されたシグネチャＳ［Ｐ２］と共に、同一のパラメータのセットＰ２を含む。
【００７９】
このメッセージがもう一度入力される時に、ＳＩＰプロキシは、シグナリング・メッセージの全パラメータＰ２に対して計算されたシグネチャとそれに含まれるシグネチャとが同一であることを検出する。このＳＩＰプロキシは、ループを検出し、メッセージの処理に割り込むことができる。
【００８０】
次に、このＳＩＰプロキシは、ループ検出エラー・メッセージを送信することができ、このメッセージは、シグナリング・メッセージが従った経路に沿って戻る。
【００８１】
したがって、最後に、本発明によるＳＩＰプロキシは、ループを検出することができる。追加のループが作られるが、この追加ループと、それが表す不必要なシグナリング・トラフィックとのコストは、単一のシグネチャ計算に起因する計算リソースにおける利益と比較して、あまり有用ではないと考えられる。
【００８２】
本発明の一特定の実施形態によれば、発信メッセージ内にマーカーを挿入し、着信シグナリング・メッセージ内に識別子マーカーがない場合にはシグネチャ計算を行わないものとすることによって、追加の最適化が可能である。
【００８３】
たとえば、この機構は、ＩＥＴＦの「ｄｒａｆｔ−ｃａｍｐｅｎ−ｓｉｐｐｉｎｇ−ｓｔａｃｋ−ｌｏｏｐ−ｄｅｔｅｃｔ−００．ｔｘｔ」ドラフトに関する議論に記載されている。
【００８４】
これは、メッセージがそのマーカーを含まない場合に、そのメッセージがそのＳＩＰプロキシを一度も通過しておらず、したがってループ内にはないという概念に基づく。
【００８５】
本発明によれば、このマーカーは、ＳＩＰプロキシを表すマーカーでなければならず、そのＳＩＰプロキシを通信ネットワーク内で一義的に表さなければならない。したがって、公衆ネットワークに属するＳＩＰプロキシの場合に、このマーカーは、この公衆ネットワーク全体を通じて一義のマーカーでなければならない。したがって、このマーカーは、全世界で一義でなければならない。
【００８６】
したがって、マーカーを含むメッセージを受信する要素は、そのメッセージがその要素を既に通過したか否かを曖昧さなしに判定することができる。
【００８７】
たとえば、マーカーは、ＳＩＰプロキシの物理アドレスに基づくものとすることができる。たとえば、マーカーは、そのＭＡＣすなわち「媒体アクセス制御」アドレスとすることができる。複数のタイプのＭＡＣアドレスがあり、これらを、具体的にはＩＥＥＥ（電気電子技術者協会）によって定義されるＭＡＣ−４８、ＥＵＩ−４８、およびＥＵＩ−６４を使用することができる。
【００８８】
マーカーは、ＳＩＰプロキシのＩＰアドレスに基づくものとすることもできる。
【００８９】
マーカーは、この物理アドレス（ＭＡＣまたはＩＰまたは他）と正確に等しいものとすることができ、あるいは、他のパラメータと共にそれを含むことができ、あるいは、物理アドレスの一義の性質を保つ変換によって物理アドレスから演繹することができる。
【００９０】
マーカーは、専用のネーミング・サーバから入手することもでき、このネーミング・サーバの役割は、すべてのＳＰＩプロキシに一義識別子を割り当てることである。
【００９１】
このマーカーを、シグナリング・メッセージ内の異なる位置に挿入することができる。
【００９２】
第１の実施形態によれば、マーカーは、シグナリング・メッセージ（着信および発信）の標準的な一意の位置に挿入される。これは、ＩＥＴＦによって標準化された、ＳＩＰプロトコルの特定のヘッダとすることができる。しかし、そのような実施態様は、すべての既存通信端末を、この新しい標準化に従い、受信されたシグナリング・メッセージの解釈およびシグナリング・メッセージ自体の生成ができるものにするために変更することを必要とするはずである。
【００９３】
したがって、本発明は、ＳＩＰプロトコルの現在の標準化に従ったままであり、インストール済み端末を変更することを必要にはしない、第２の実施形態を提案する。
【００９４】
たとえば、マーカーを、シグネチャに似て「ｂｒａｎｃｈ」パラメータとすることのできる、シグナリング・メッセージの特定のパラメータ内に挿入することができる。
【００９５】
通常、これは、各発信シグナリング・メッセージの（年代順に）最後の「Ｖｉａ」ヘッダの「ｂｒａｎｃｈ」パラメータである。
【００９６】
いくつかの場合に、いくつかの「プロキシ」シグナリング要素は、「Ｒｅｃｏｒｄ  Ｒｏｕｔｅ」ヘッダをも変更し、通信ネットワーク内の応答メッセージのルーティングは、これらの「Ｒｅｃｏｒｄ  Ｒｏｕｔｅ」ヘッダに基づく。この場合に、マーカーを、各発信シグナリング・メッセージのｒｅｃｏｒｄ  ｒｏｕｔｅヘッダのパラメータ内に挿入することもできる。
【００９７】
ＳＩＰ端末要素は、「Ｒｅｃｏｒｄ−Ｒｏｕｔｅ」ヘッダを使用して、順方向経路に対するクエリを行ったノードを介して後続メッセージをルーティングする。
【００９８】
「Ｂ２ＢＵＡ」（ｂａｃｋ−ｔｏ−ｂａｃｋ  Ｕｓｅｒ  Ａｇｅｎｔ）タイプのシグナリング要素の場合に、マーカーを、サーバの役割に適合する（ＵＡＳすなわちＵｓｅｒ  Ａｇｅｎｔ  Ｓｅｒｖｅｒ）時には「Ｔｏ」ヘッダ内に挿入し、クライアントの役割に適合する（ＵＡＣ）時には「Ｆｒｏｍ」ヘッダ内に挿入することができる。
【００９９】
マーカーを、ＩＭＳアーキテクチャ内でＳ−ＣＳＣＦプロキシの役割を有するシグナリング・プロキシによって「Ｓｅｒｖｉｃｅ  Ｒｏｕｔｅ」ヘッダ内に含めることもできる。この「Ｓｅｒｖｉｃｅ  Ｒｏｕｔｅ」ヘッダは、ＩＥＦＴ  ＲＦＣ  ３６０８、名称「Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  （ＳＩＰ）  Ｅｘｔｅｎｓｉｏｎ  Ｈｅａｄｅｒ  Ｆｉｅｌｄ  ｆｏｒ  Ｓｅｒｖｉｃｅ  Ｒｏｕｔｅ  Ｄｉｓｃｏｖｅｒｙ  Ｄｕｒｉｎｇ  Ｒｅｇｉｓｔｒａｔｉｏｎ」、２００３年１０月公表で定義されている。
【０１００】
これらの場合のすべてにおいて、マーカーを、セパレータ（ＳＩＰプロトコルの文法に従って「；」）の使用によって挿入し、特定のキーワード（たとえば、「ｍａｒｋｅｒ＝」ストリング）によって導入することができる。マーカーを、キーワードを使用せずに挿入することもできる。
【０１０１】
マーカーの挿入およびマーカーの存在の検証からなるこの追加の最適化が、ＲＦＣ  ３２６１に示されているように２つのシグネチャ計算が行われる事例でも適用可能であることに留意されたい。
【０１０２】
１つの変形形態で、ＲＣＰ受信手段内でシグネチャ計算を系統的に行うが、着信メッセージ「ｍｅ」がＳＩＰプロキシ識別マーカーを含まない場合にのみ比較をトリガすることも可能である。
【図面の簡単な説明】
【０１０３】
【図１】ＩＭＳタイプネットワークアーキテクチャを示す図である。
【図２】ＩＥＴＦ  ＲＦＣ  ３２６１に記載の最先端技術によるＳＩＰプロキシ内のループ検出に使用されるデータ・ストリームを概略的に示す図である。
【図３】本発明によるＳＩＰプロキシについて可能なデータ・ストリームおよび機能アーキテクチャを概略的に示す図である。
【図４】本発明によるＳＩＰプロキシによる例のループ検出を示す図である。
【図１】
2009540711.tif 000003
【図２】
2009540711.tif 000004
【図３】
2009540711.tif 000005
【図４】
2009540711.tif 000006
【国際調査報告】
2009540711.tif 000007
2009540711.tif 000008