JP5437255B2 - Ｔｃｐトランスポートプロトコルの一時使用によってｓｉｐ信号メッセージ用アドレス変換装置を通過する方法 - Google Patents

Description

本発明は通信ネットワークに関する。より正確には、本発明はＮＡＴ（「ネットワークアドレス変換」）装置などのアドレス変換装置を介して信号メッセージを伝送する問題に関する。

現在の通信ネットワークは、Ｈ．３２３、ＭＧＣＰ（メディアゲートウェイ制御プロトコル）、またはＳＩＰ（セッション開始プロトコル）およびＳＤＰ（セッション記述プロトコル）などの信号プロトコルによる通信セッションの確立を可能にする。

このＳＩＰプロトコルは、ＩＥＴＦ（インターネット技術標準化委員会）によって発行されたＲＦＣ３２６１によって定義され、その二重目的は、
−２者が交信できるようにすることと、
−ＳＤＰプロトコルを介して、確立されるべきセッションの特性（ビデオビットレート、どの符号器（ＣＯＤＥＣ）を使用すべきか、など）のネゴシエーションを可能にすること、である。

セッション特性のネゴシエーションは、ＲＦＣ３２６４、表題「ＳＤＰ ｏｆｆｅｒ／ａｎｓｗｅｒ ｍｏｄｅｌ」によって指定される。

相手を呼び出したいと願う発呼者は、発呼者の個人アドレス、発呼者の端末（または、より一般的に言えばクライアント）の物理アドレス、および呼び出されている相手の個人アドレスを含む、「プロキシ」として知られる信号要素に、信号メッセージ（「Ｉｎｖｉｔｅ」）を送信できる。信号要素は、呼び出されている相手の個人アドレスを対応する端末の物理アドレスにマッチングさせるための手段（「ｒｅｇｉｓｔｒａｒ」）を有する。このマッチングによって、呼び出されている相手に信号メッセージがルーティングできるようになる。

相手が呼を受け入れると、その相手は端末またはクライアントの物理アドレスを含む新しい信号メッセージで応答する。このようにして、両端末が相手の物理アドレスを知ると、両端末はデータ（音声、ビデオなど）を伝送するためのＩＰ（インターネットプロトコル）接続を確立できる。

しかし、ＲＦＣ１６３１「Ｔｈｅ ＩＰ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ」において、およびＲＦＣ３０２２「Ｔｒａｄｉｔｉｏｎａｌ ＩＰ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ（Ｔｒａｄｉｔｉｏｎａｌ ＮＡＴ）」において定義される、ＮＡＴ（「ネットワークアドレス変換」）またはＮＡＰＴ（「ネットワークアドレスポート変換」）装置として知られるアドレス変換装置に問題が生じる。これらの装置は、第１ネットワーク（一般にはプライベートネットワーク）と第２ネットワーク（パブリックインターネットネットワークなど）をインタフェースさせるように設計されている。

第１ネットワークの装置（端末）は、有効性がその第１ネットワークに限定される物理ＩＰアドレスを有する。第１ネットワークの装置が、その第１ネットワークの外部に位置する装置との通信の確立を望む場合、アドレス変換装置が第２ネットワークに有効な一時第２アドレスを割り当てて、クライアントの第１アドレスと第２アドレスとの間の関連性を保つ。

したがって、ＮＡＴアドレス変換装置は２つの通信ネットワーク間で伝送されたメッセージを：
−送信メッセージ、すなわち第１ネットワークからパブリック第２ネットワークに送信されているメッセージのＩＰヘッダ内の、端末の第１アドレスを第２アドレスに変換することによって、および、
−着信メッセージ、すなわち第２ネットワークから第１ネットワークに送信されているメッセージのＩＰヘッダ内の、端末の第２アドレスを第１アドレスに変換することによって、オンザフライで修正する。

したがって、アドレス変換装置、すなわちＮＡＴ装置は、第１アドレスと第２アドレスとをマッチアップさせるために使用される表を所有する。これらのマッチアップは一時的なものであり、接続またはセッションが終了すると削除される。これらの関連性またはマッチアップは、従来「バインディング」として知られる。

したがって、ＳＩＰ／ＳＤＰ信号メッセージ（あるいはＨ．３２３、またはその他）がアドレス変換装置を通過するときに問題が生じる。この問題は、「ＮＡＴ通過」として知られる。

ＮＡＴ通過は、とりわけオープンコンテント百科事典「ウィキペディア」、アドレス：「ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＮＡＴ＿ｔｒａｖｅｒｓａｌ．ｈｔｍｌ」において説明されており、ＩＥＴＦによって発行されたＲＦＣ３２３５、表題「Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ（ＮＡＴ）−Ｆｒｉｅｎｄｌｙ Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｓｉｇｎ Ｇｕｉｄｅｌｉｎｅｓ」において言及されている。

ＳＩＰおよびＳＤＰなどの信号プロトコルは、アプリケーションプロトコルと考えられる。ＳＩＰ／ＳＤＰプロトコルは、たとえば、それら自体がプロトコルスタック内のＩＰの上に位置するＴＣＰまたはＵＤＰプロトコルを介して伝送されてよい。したがって、実際にはＳＩＰメッセージは、それ自体がＩＰメッセージ内に含まれたＴＣＰまたはＵＤＰメッセージ内に含まれた、パラメータの連続である。

ＮＡＴアドレス変換装置は、ＩＰ層内で発見されたパラメータだけを編集して、上位層内で発見されたパラメータはそのままにしておく。

言い換えれば、ＩＰヘッダ内に含まれるアドレスとは違って、ＳＩＰおよびＳＤＰメッセージ内に含まれる物理アドレスは、アドレス変換装置によって編集されない。

その結果、信号メッセージの受信者（呼び出されているクライアント）は、発呼クライアントの第１アドレスしか知ることができない。しかし、このアドレスが有意味なのは第１ネットワーク内だけなので、どのような通信セッションも確立できない。

この問題はよく知られているので、解決するために数多くのソリューションが提案されてきた。この問題を解決するための２つの主な手法がある。発呼クライアントに基づく手法、および通信ネットワークのサーバまたは装置に基づく手法である。

第１カテゴリは、ＲＦＣ３４８９で説明された、ＳＴＵＮ（「Ｓｉｍｐｌｅ Ｔｒａｖｅｒｓａｌ ｏｆ ＵＤＰ ｔｈｒｏｕｇｈ ＮＡＴｓ」）メカニズムを特に含む。このメカニズムによって、クライアント（または端末）は第２アドレスを知ることができるようになる。この方法では、発呼クライアントは、第２通信ネットワーク（たとえば、パブリックネットワーク）に送信されているメッセージよりも前に、この第２ネットワーク内に位置するＳＴＵＮサーバに要求を伝送する。このネットワークは、クライアント、すなわちクライアントの第２アドレスを「見る」アドレス（およびポート）を含むメッセージで応答する。

次いで、クライアントは、ＳＤＰプロトコルを介して応答を受信するためにどのアドレスを使用したいかを示すために、この第２アドレスを使用してよい。

しかし、数多くのＮＡＴ装置が「対称型」で、１組の通話者に第２アドレスをバインディングすると言われるので、このソリューションは重要な制限に悩まされることになる。さらに、ＮＡＴ装置によってクライアントに割り当てられた第２アドレスは、ＳＴＵＮサーバとの通信と、相手と確立されるべきセッションとでは異なる場合がある。同様の場合、クライアントと相手との間の通信は確立できない。

この状況を改善するために、ＴＵＲＮ（「Ｔｒａｖｅｒｓａｌ Ｕｓｉｎｇ Ｒｅｌａｙ ＮＡＴ」）メカニズムなどの他の提案が、同じ原則に基づいて作成された。ＴＵＲＮメカニズムの仕様は、ウェブアドレスｈｔｔｐ：／／ｉｅｔｆｒｅｐｏｒｔ．ｉｓｏｃ．ｏｒｇ／ｉｄｒｅｆ／ｄｒａｆｔ−ｒｏｓｅｎｂｅｒｇ−ｍｉｄｃｏｍ−ｔｕｒｎ／で入手可能である。

しかし、ＳＴＵＮメカニズムとＴＵＲＮメカニズムのどちらもＳＩＰプロトコルに適していない。

さらに、ＳＩＰ信号メッセージを通過に適するようにするために、新しいメカニズムであるＩＣＥ（「Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ Ｅｓｔａｂｌｉｓｈｍｅｎｔ」）が提案された。ＩＣＥは、ＳＴＵＮおよびＴＵＲＮメカニズムを適合させることによって、ＳＴＵＮおよびＴＵＲＮメカニズムに基づく。

ＩＣＥメカニズムの仕様は、ウェブアドレスｈｔｔｐ：／／ｉｅｔｆｒｅｐｏｒｔ．ｉｓｏｃ．ｏｒｇ／ｉｄｒｅｆ／ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｉｃｅ／で入手可能である。

ソリューションの第２カテゴリは、通信ネットワーク内の装置に依存する。最も初期のソリューションはネットワーク内にサーバ（たとえば、ＳＴＵＮサーバ）を実装したが、クライアントがイニシアチブを有する点に留意されたい。しかし、ソリューションのこの第２ファミリでは、イニシアチブおよびＮＡＴ通過ソリューションの実装は、両方ともネットワーク装置に課せられた義務である。

たとえば、このファミリに属する第１ソリューションは、アプリケーションゲートウェイをＮＡＴアドレス変換装置にバインディングしている。このメカニズムは、「Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ Ｇａｔｅｗａｙ」または「Ａｐｐｌｉｃａｔｉｏｎ−Ｌｅｖｅｌ Ｇａｔｅｗａｙ」を意味するＡＬＧとして知られ、１９９９年８月に発行されたＲＦＣ２６６３、表題「ＩＰ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ（ＮＡＴ）Ｔｅｒｍｉｎｏｌｏｇｙ ａｎｄ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ」のパラグラフ２．９で定義される。

このゲートウェイ（または、このようなゲートウェイと同じ機能を有するＮＡＴ装置）は、メッセージによって使用されるアプリケーションプロトコルを理解するための手段を有する。特に、このゲートウェイは信号メッセージのコンテンツを理解でき、通話者が自分の第１アドレスではなく第２アドレスを交換して、それによって通信セッションを確立できるように、ＳＤＰメッセージ内に含まれる物理アドレスを変換できる。

このソリューションのある変形形態は、信号メッセージの経路に沿って位置することになるセッションコントローラ、すなわちＳＢＣ（「Ｓｅｓｓｉｏｎ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌｌｅｒ」を意味する）を使用することで構成される。このタイプの製品により、両ネットワーク間の通信セッションおよび信号メッセージの送信を制御することが可能になる。より正確には、ＳＢＣは、通話者間で通信セッションが適切に確立されうるように、Ｍｅｇａｃｏなどのプロトコルを介してメディアを伝送する手段（「メディアプロキシ」）を制御できる、ＳＩＰ「プロキシ」信号要素の役割を担うことができる。

しかし、接続またはセッションの終了後、ＮＡＴアドレス変換装置は第１および第２アドレス内のバインディングを保存しないので、他の技術的な問題が生じる。

ＳＩＰ信号メッセージは、ＴＣＰ（伝送制御プロトコル）またはＵＤＰ（ユーザデータグラムプロトコル）プロトコルによってトランスポートされうる。ＴＣＰプロトコルは、セッションを終了させるための操作が行われるまでオープン接続を保つ。さらに、ＴＣＰを使用するＳＩＰセッションが使用される場合、ＴＣＰ接続が終了するまでＮＡＴアドレス変換装置がバインディングを保存することになる。

しかし、ＵＤＰプロトコルについてはどのような接続も確立されない。さらに、ＮＡＴアドレス変換装置はバインディングを一時的に、すなわちあらかじめ定められた長さの期限が切れるまで保存するにすぎない。

したがって、ＳＩＰ信号をトランスポートするためのＵＤＰプロトコルの使用は、ＮＡＴアドレス変換装置通過にとって重大な問題を引き起こす。

しかし、ＴＣＰプロトコルを使用することも、オープン接続を保存するためにさまざまな参加者を必要とするので、問題を引き起こす。このような場合、サーバまたはプロキシは、通信をしているＳＩＰ端末、すなわちクライアントと同数のオープン接続が保存されるように保たなければならない。

それぞれのＴＣＰ接続がかなりの量のコンテキストデータを表すので、これはＳＩＰプロキシにとって重大な負担である。通信ネットワークの設計者は、Ｌｉｎｕｘなどのオペレーティングシステムが操作できるＴＣＰ接続の最大限度（６５５３６の同時接続数）などの、非常に明確な問題に直面していることにも気づくだろう。

さらに、現在ほとんどのＳＩＰアーキテクチャはＵＤＰトランスポートプロトコルに基づいている。

第１アドレスと第２アドレスとの間のバインディングの一時的な性質を矯正するために、バインディングをアクティブに保つことを唯一の目的として、両者間で定期的に信号メッセージが伝送される。

これらの信号メッセージは通常ＳＩＰプロトコルの「Ｒｅｇｉｓｔｅｒ」メッセージであり、バインディングの有効期限値を含む「Ｅｘｐｉｒｅｓ」ヘッダを含む。この有効期間は、クライアントとサーバまたはプロキシとの間でネゴシエーションされうる。たとえば、第１の「Ｒｅｇｉｓｔｅｒ」メッセージ内で、クライアントが第１の値を示す。サーバまたはプロキシは「Ｅｘｐｉｒｅｓ」ヘッダ内に第２の値を含む「２００ Ｏｋ」メッセージで応答する。標準によれば、クライアントは次いでこの第２の値を有効期間として使用しなければならない。次いで、クライアントはこの第２の値によって決定された一定の間隔で「Ｒｅｇｉｓｔｅｒ」メッセージを送信することになる。

この手法は「ＵＤＰホールパンチング」として知られる。

しかしＴＣＰプロトコルには、ある種のアプリケーションにとってＴＣＰプロトコルを必要なものにする利点がある。

たとえば、メッセージのサイズが大きい場合、ＵＤＰプロトコルはそのメッセージをより小さいデータグラムに分解するので、断片化問題を引き起こすことがある。しきい値は通信ネットワークに依存し、通信ネットワークの最大伝送ユニット（すなわちＭＴＵ）によって決定される。このしきい値は、イーサネット（登録商標）ネットワーク（ＴＭ）では１３００バイトである。

ＲＦＣ３２６１のパラグラフ１８．１．１で説明されるように、一旦ＳＩＰメッセージがこのしきい値からバッファ値２００バイトを引いたものに対応するサイズを越えると、ＵＤＰプロトコルはもはや使用できない。このような場合、ＴＣＰプロトコル（または、輻輳制御を可能にする他のプロトコル）が使用されなければならない。

ＩＥＴＦ（インターネット技術標準化委員会）によって発行されたＲＦＣ３２６１ ＲＦＣ３２６４、表題「ＳＤＰ ｏｆｆｅｒ／ａｎｓｗｅｒ ｍｏｄｅｌ」 ＲＦＣ１６３１「Ｔｈｅ ＩＰ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ」 ＲＦＣ３０２２「Ｔｒａｄｉｔｉｏｎａｌ ＩＰ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ（Ｔｒａｄｉｔｉｏｎａｌ ＮＡＴ）」 オープンコンテント百科事典「ウィキペディア」、「ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＮＡＴ＿ｔｒａｖｅｒｓａｌ．ｈｔｍｌ」 ＩＥＴＦによって発行されたＲＦＣ３２３５、表題「Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ（ＮＡＴ）−Ｆｒｉｅｎｄｌｙ Ａｐｐｌｉｃａｔｉｏｎ Ｄｅｓｉｇｎ Ｇｕｉｄｅｌｉｎｅｓ」 ＲＦＣ３４８９ ＴＵＲＮメカニズムの仕様、ｈｔｔｐ：／／ｉｅｔｆｒｅｐｏｒｔ．ｉｓｏｃ．ｏｒｇ／ｉｄｒｅｆ／ｄｒａｆｔ−ｒｏｓｅｎｂｅｒｇ−ｍｉｄｃｏｍ−ｔｕｒｎ／ ＩＣＥメカニズムの仕様、ｈｔｔｐ：／／ｉｅｔｆｒｅｐｏｒｔ．ｉｓｏｃ．ｏｒｇ／ｉｄｒｅｆ／ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｉｃｅ／ １９９９年８月に発行されたＲＦＣ２６６３、表題「ＩＰ Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ（ＮＡＴ）Ｔｅｒｍｉｎｏｌｏｇｙ ａｎｄ Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ」のパラグラフ２．９

ＵＤＰプロトコルの使用とＴＣＰプロトコルの使用のどちらも満足のいくものではなく、両方の知られているソリューションによって生じる技術的な問題を矯正するソリューションが必要である。本発明の目的は、このようなソリューションを提案することである。

そのためには、本発明の第１の目的は、第１ネットワークとは異なる第２通信ネットワーク内に位置し、アドレス変換装置を介して第１ネットワークに接続されている信号サーバを用いて、第１通信ネットワーク内に位置する第１通信クライアントと、第２通信クライアントとの間の通信セッションを確立するための方法である。

この方法は、前記第１通信クライアントに、通信サーバに登録メッセージを伝送させることによって、アドレス変換装置内の第１通信クライアントの第１アドレスと第２アドレスとをバインディングするステップで構成される。

本方法は、信号サーバが：
−第２通信クライアントから送信された、第１通信クライアント宛ての着信信号メッセージを保存し、
−後続の登録メッセ−ジに、第１通信クライアントがＴＣＰプロトコルを使用して新しい登録メッセージを送信することを要求する応答メッセージで応答し、
−新しい登録メッセージが受信された後で、以前保存された着信信号メッセージを配信することを特徴とする。

たとえば、第１通信ネットワークは、プライベートネットワークでよく、第２通信ネットワークは、パブリック通信ネットワークでよい。

登録メッセージおよび応答メッセージは、ＵＤＰプロトコルによって搬送されてよい。

本発明の一実施形態では、信号サーバは、「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」メッセージを伝送するＴＣＰプロトコルを使用して、新しい登録メッセージを送信することを要求する。

この「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」メッセージは、「ＴＣＰ」に設定された「Ｔｒａｎｓｐｏｒｔ」パラメータを含む「Ｃｏｎｔａｃｔ」ヘッダを含む。

最後に、本発明の一実施形態では、信号メッセージはＳＩＰ信号メッセージ「Ｉｎｖｉｔｅ」、「Ｓｕｂｓｃｒｉｂｅ」、「Ｐｕｂｌｉｓｈ」、「Ｒｅｆｅｒ」、および「Ｍｅｓｓａｇｅ」を含むグループの中から選択される、ＳＩＰプロトコルによる最初のメッセージでよい。

本発明の他の目的は：
−信号サーバが位置する第２通信ネットワークと異なり、アドレス変換装置を介して前記サーバに接続している第１通信ネットワーク内に位置する少なくとも１つの通信クライアントと信号メッセージを交換するための第１インタフェースと、
−第２通信ネットワーク内に位置する他の装置とともに信号メッセージを伝送するための第２インタフェースとを含む、信号サーバである。

第１インタフェースは、通信クライアントから送信された登録メッセージを受信するように設計されており、アドレス変換装置内の通信クライアントの第１アドレスと第２アドレスとの間のバインディングを維持することを目的としている。

この通信サーバは：
−第２インタフェースから通信クライアントに送信された着信信号メッセージを保存するためのメモリをさらに含むことと、
−第１インタフェースが、着信信号メッセージの到着後、通信サーバが、後続の登録メッセージに、通信クライアントがＴＣＰプロトコルを使用して新しい登録メッセージを送信することを要求する応答メッセージで応答して、この新しい登録メッセージの受信に続いて、着信信号メッセージ（以前に保存された）を配信できるように設計されていることとを特徴とする。

最後に、本発明の第３の目的は、このような通信サーバ実装する少なくとも１つのＣＳＣＦ（「呼セッション制御機能」）機能要素を含む、ＩＭＳ（「ＩＰマルチメディアサブシステム」）アーキテクチャである。

この方法では、必要な場合のみＴＣＰ接続が確立され、通信セッションごとに同時に１つのＴＣＰ接続をアクティブに保つ必要はない。したがって過剰なＴＣＰ接続によってもたらされる問題が生じず、しかしＴＣＰ接続を「オンデマンド」で確立することによってＵＤＰプロトコルに関する不足が解決する。

本発明のソリューションの唯一の欠点は、ＴＣＰ接続が確立されるまで着信信号メッセージを保存することによって、遅延が生成される可能性があることである。この遅延は、リフレッシュ時間によって決定される。

本発明、本発明の諸特徴、および本発明の諸利点は、添付の図面に関連して以下の説明で明らかになるだろう。

本発明の信号サーバが配備されうるアーキテクチャを示す図である。 通信クライアントと本発明の信号サーバとの間で実装されうる、例示的対話のダイアグラムを示す図である。

図１に示した例示的ネットワークアーキテクチャにおいて、２つの通信クライアントＣ_１およびＣ_２が通信ネットワークＮに接続されている。通信クライアントＣ_１は第１通信ネットワークＮ_１に属し、第１通信ネットワークＮ_１はアドレス変換装置ＮＡＴ_１を介して第２通信ネットワークＮに接続されている。

通信クライアントＣ_１は、第１通信ネットワークＮ_１内で使用されうる第１アドレスを所有している。通信クライアントＣ_１は、この第１アドレスをこの第１ネットワーク（装置ＮＡＴ_１を含む）に属する装置と通信するために使用できるが、外部の装置と通信するためには使用できない。これらの外部の装置と通信するためには、アドレス変換装置ＮＡＴ_１によって第２アドレスが通信クライアントＣ_１に一時的に割り当てられる。

したがって、このアドレス変換装置ＮＡＴ_１は、クライアントＣ_１の第１アドレスと第２アドレスと間のバインディングを維持する。このクライアントＣ_１からの、またはそこへのメッセージが分析されて、第１アドレスが第２アドレスに、およびその逆に変換される。

第１通信ネットワークは、たとえば、プライベート通信ネットワークでよく、第２通信ネットワークはパブリックネットワークでよい。

通信クライアントＣ_１は、信号サーバＳを介して通信クライアントＣ_２に接続できる。この信号サーバは、一般にＳＩＰプロキシサーバである。３ＧＰＰまたはＴＩＳＰＮＡ標準機構によって指定されたＩＭＳ（ＩＰマルチメディアサブシステム）アーキテクチャがあれば、このサーバまたはプロキシサーバはＣＳＣＦ（呼セッション制御機能）要素でよい。

信号サーバＳはＳＧＣ（セッションボーダコントローラ）でもよい。

以下の説明では、クライアントＣ_１と信号サーバとの間の接続だけを主に取り扱う。したがって、クライアントＣ_２とサーバＳとの間の接続は詳細に説明しない。

図１に示された例は、本発明をより良く理解するために、ある非常に単純化された実施形態を表している。この方法では、通信クライアントＣ_２は、第２アドレス変換装置ＮＡＴ_２を介して第２通信ネットワークＮに接続された、第３ネットワークＮ_２に属する。

実際の配備では、信号サーバＳと通信クライアントＣ_２との間に他の装置が存在してよい。たとえば、通信クライアントＣ_２は他の信号サーバに接続してよく、両信号サーバは直接または他のサーバを介して通信してよい。

しかし、図１に示される例は、本発明の精神から逸脱することなしに、また本発明において直接的な役割を担わない装置に焦点を合わせることなしに、本発明を理解することを可能にする。

第１および第２アドレスをバインディングするために、通信クライアントＣ_１は登録メッセージを信号サーバＳに伝送する。これらのメッセージは、一般に定期的に、場合によってはネゴシエーション後に伝送される。

図２は、クライアントＣ_１と信号サーバＳとの間の交換を示している。それぞれの縦軸はネットワーク要素を表しており、それぞれＣ_１、アドレス変換装置ＮＡＴ_１、および信号サーバＳである。線が下方に移動するにつれて時間が増加する。水平矢印は、これらの要素間で交換された信号メッセージを表している。

登録メッセージＭ_１は、最初の登録メッセージである。登録メッセージＭ_１は、リフレッシュ時間のための第１の値を指定する。この第１の値は高くてよく、たとえば３６００秒でよい。

信号サーバＳは、第２の値、たとえば３０秒を含んでよい、応答メッセージＲ_１で応答する。

次いで、クライアントＣ_１は、応答メッセージＲ_１内で伝送されたこの第２の値を基礎として使用してよい。第２の値がない場合は、クライアントＣ_１は、以前に自分で決定した第１の値を基礎として使用する。

このようにして決定されたこのリフレッシュ時間値に対応するインターバルΔがある場合、通信クライアントＣ_１は信号メッセージＭ_２、Ｍ_３、Ｍ_４．．．を信号サーバＳに伝送し、信号サーバＳはそれぞれ応答メッセージＲ_２、Ｒ_３、Ｒ_４．．．でそれらのメッセージに応答する。

信号サーバは、これらの登録メッセージを受信して応答メッセージで応答するように設計された、インタフェースＩ_１を有する。

これらの登録メッセージは、ＳＩＰプロトコルに適合する「Ｒｅｇｉｓｔｅｒ」メッセージでよい。リフレッシュ時間は、これらのメッセージの「Ｅｘｐｉｒｅ」ヘッダ内に含まれてよい。応答メッセージは、ＳＩＰプロトコルの「２００ ＯＫ」メッセージでよく、リフレッシュ時間がもしあれば、「Ｅｘｐｉｒｅ」ヘッダ内に含まれてよい。

これらの登録メッセージＭ_１、Ｍ_２、Ｍ_３、Ｍ_４．．．および応答メッセージＲ_１、Ｒ_２、Ｒ_３、Ｒ_４．．．は全てが、ＵＤＰプロトコルによって搬送される。「Ｖｉａ」ヘッダ内で、登録メッセージが、トランスポートプロトコルはＵＤＰでなければならないと指定する。

この種のＶｉａヘッダは以下のようでよい：
Ｖｉａ：ＳＩＰ／２．０／ＴＣＰ ｃｌｉｅｎｔ．ａ．ｅｘａｍｐｌｅ．ｃｏｍ：５６２０；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫ７４ｂｆ９

したがって、これらの信号サーバＳは、クライアントＣ_１との接続を処理するために、どのようなＴＣＰ接続もオープンに維持しない。

所与の時間に、信号サーバＳは、第２通信クライアントＣ_２から送信された着信信号メッセージＭＩを受信してよい。着信信号メッセージＭＩは、「Ｉｎｖｉｔｅ」、「Ｓｕｂｓｃｒｉｂｅ」、「Ｐｕｂｌｉｓｈ」、「Ｒｅｆｅｒ」、または「Ｍｅｓｓａｇｅ」メッセージなどの、ＳＩＰプロトコルによる「最初の」信号メッセージでよい。「Ｉｎｖｉｔｅ」メッセージの目的は、発呼通信クライアントＣ_２との通信セッションの確立を受け入れるために、通信クライアントＣ_１をインバイトすることである。

この通信は、ＴＣＰプロトコルの使用を必要とすることがある。

これらの要求が体系的であり、クライアントＣ_２から送信されたそれぞれのインビテーションが、確立すべきセッションを搬送するためのＴＣＰ接続の作成につながることが可能である。

ＴＣＰプロトコルとＵＤＰプロトコルとの間で選択が行われるも可能性もある。この選択は、この着信信号メッセージＭＩ内のパラメータによって決定されてよい。このパラメータは、ＳＩＰプロトコルによる「ｃｏｎｔａｃｔ」ヘッダ内に挿入されてよい。

選択は、場合によっては、着信信号メッセージＭＩ内に挿入されたパラメータを考慮に入れることによって、信号サーバＳによって決定されてもよい。

通信セッションがＴＣＰトランスポートプロトコルの使用を必要とすると仮定する。

着信信号メッセージは、信号サーバＳのインタフェースＩ２によって受信されて、メモリＭ内に一時的に保存される。応答メッセージＲ_Ｎ−１を送信後、信号サーバＳはそれに続く登録メッセージＭ_Ｎを待つ。したがって、着信信号メッセージＭＩを処理するための待ち時間δは、リフレッシュ時間Δより少ない。

サーバＳは、通信クライアントＣ_１がＴＣＰプロトコルを使用して新しい登録メッセージを送信することを要求する応答メッセージＲ_Ｎで、登録メッセージＭ_Ｎに応答する。

一実施形態では、この応答メッセージは、ＳＩＰプロトコルによる「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」メッセージでよい。

このタイプのメッセージは、交信されるべきホストの新しいＵＲＩ（ユニバーサルリソース識別子）を指定する「Ｃｏｎｔａｃｔ」ヘッダを含む。このタイプのメッセージは、それを使ってホストが交信されなければならないトランスポートプロトコルを指定するパラメータも含む。

このパラメータは、ＲＦＣ３２６１のセクション２０．１０によって定義されているように、「Ｔｒａｎｓｐｏｒｔ」パラメータでよい。

「Ｃｏｎｔａｃｔ」ヘッダは、たとえば以下のようでよい：
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ｂｏｂ＠１９２．０．２．４；ｔｒａｎｓｐｏｒｔ＝ＵＤＰ＞；ｅｘｐｉｒｅｓ＝６０

本発明のコンテキスト内で、これはアドレスの真の変更として働かず、したがってこのヘッダは、信号サーバＳのアドレスを含む。トランスポートプロトコルを指定するパラメータの値は「ＴＣＰ」である。

したがって、「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」メッセージタイプの使用は、既存のＳＩＰプロトコルに新しいタイプのメッセージが追加される必要なしに、必要とされる情報を伝送することを可能にする。

この応答メッセージＲ_Ｎは、ＴＣＰプロトコルを使用して送信されるべき、新しい登録メッセージＭ_Ｎ＋１をもたらす。

この新しい登録メッセージは、応答メッセージＲ_Ｎの受信直後に、すなわち、以前のようにリフレッシュ時間Δが切れるのを待たずに伝送されてよい。これにより、着信信号メッセージＭＩを処理するための待ち時間を減らすことが可能になる。

登録メッセージＭ_Ｎ＋１によって、アドレス変換装置ＮＡＴ_１を介して通信クライアントＣ１と信号サーバＳとの間のＴＣＰ接続をオープンできるようになる。

一旦ＴＣＰ接続が確立されると、信号サーバは信号メッセージＭＩを受信側通信クライアントＣ_１に配信できる。次いで、信号サーバＳのメモリＭから信号メッセージＭＩが削除される。

通信セッションが終了する（たとえば、２つの通信クライアントのうちの１つを切る）と、信号サーバは終了メッセージを通信クライアントＣ_１に伝送してよい。

次いで、ＴＣＰ接続は終了してよい。

次いで、アドレス変換装置ＮＡＴ_１内のバインディングを維持するために、通信クライアントＣ_１が、頻度ΔでＵＤＰプロトコルによって搬送された登録メッセージの伝送を再開する。

上記のように、ＴＣＰ接続はある種のＴＣＰプロトコルアプリケーションの要求を満たす。

さらに、ＴＣＰ接続により、状況によっては不可能なはずの着信信号メッセージＭＩの送信が可能になる。実際、ある種のアドレス変換装置はファイアウォール機能を有する。それらのアドレス変換装置は、第１ネットワークＮ_１またはＴＣＰ接続の一部から送信されたメッセージに応答しない限り、パブリックネットワークＮから送信されたメッセージの伝送を可能にしない。

このような場合、ＴＣＰ接続の確立により、ファイアウォールＮＡＴ_１を介してインビテーションメッセージＭＩを伝送することが可能になる。したがって、本発明はこのさらなる技術的な問題を解決する。

本発明の結果、ＴＣＰ接続は通信セッションの間のみオープンになる。残りの時間、すなわち通信クライアントは待っているだけだが、インビテーションメッセージを送受信するために利用可能である場合、通常のＵＤＰプロトコル交換が信号サーバとの接続を維持することを可能にする。

したがって、本発明は、ＳＩＰプロトコルのもとで、ＵＤＰおよびＴＣＰプロトコルのそれぞれの諸利点の恩恵を受けるために、それらのプロトコルの使用を最適化することを可能にする。

Claims (12)

1. 第１通信ネットワーク（Ｎ_１）とは異なる第２通信ネットワーク（Ｎ）内に位置し、アドレス変換装置（ＮＡＴ_１）を介して前記第１ネットワークに接続されている信号サーバ（Ｓ）を介して、前記第１通信ネットワーク（Ｎ_１）内に位置する第１通信クライアント（Ｃ_１）と、第２通信クライアント（Ｃ_２）との間の通信セッションを確立するための方法であって、前記第１通信クライアントに、ＵＤＰプロトコルに従って信号サーバに登録メッセージを伝送させることによって、前記アドレス変換装置内の前記第１通信クライアントの第１アドレスと第２アドレスとをバインディングするステップを含み、前記方法が、
   −第２通信クライアントから送信された、第１通信クライアント宛ての着信信号メッセージを信号サーバで保存することと、
   −信号サーバにより、保存された着信信号メッセージに後続する第１通信クライアントからの登録メッセ−ジに、第１通信クライアントがＴＣＰプロトコルを使用して新しい登録メッセージ（Ｍ_Ｎ＋１）を送信することを要求する応答メッセージ（Ｒ_Ｎ）で応答することと、
   −ＴＣＰプロトコルを使用した前記新しい登録メッセージが信号サーバにより受信された後に、信号サーバにより前記着信信号メッセージ（ＭＩ）を第１通信クライアントへ配信することを有することを特徴とする、方法。
2. 前記第１通信ネットワークがプライベートネットワークであり、前記第２通信ネットワークがパブリック通信ネットワークである、請求項１に記載の方法。
3. 前記応答メッセージがＵＤＰプロトコルによって搬送される、請求項１または２に記載の方法。
4. 前記信号サーバが、「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」メッセージを伝送するＴＣＰプロトコルを使用して、新しい登録メッセージが送信されることを要求する、請求項１から３のいずれか一項に記載の方法。
5. 前記「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」メッセージが、「ＴＣＰ」に設定された「Ｔｒａｎｓｐｏｒｔ」パラメータを含む「Ｃｏｎｔａｃｔ」ヘッダを含む、請求項４に記載の方法。
6. 前記信号メッセージがＳＩＰプロトコルによる最初のメッセージであり、「Ｉｎｖｉｔｅ」、「Ｓｕｂｓｃｒｉｂｅ」、「Ｐｕｂｌｉｓｈ」、「Ｒｅｆｅｒ」、および「Ｍｅｓｓａｇｅ」を含むグループの中から選択される、請求項１から５のいずれか一項に記載の方法。
7. 信号サーバ（Ｓ）であって、
   前記信号サーバが位置する第２通信ネットワーク（Ｎ）と異なり、アドレス変換装置（ＮＡＴ_１）を介して前記信号サーバに接続している第１通信ネットワーク（Ｎ_１）内に位置する少なくとも１つの通信クライアント（Ｃ_１）と信号メッセージを交換するように構成された第１インタフェース（Ｉ_１）を含み、前記第１インタフェースが、通信クライアントから送信された登録メッセージを受信するように設計されており、前記アドレス変換装置内の前記通信クライアントの第１アドレスと第２アドレスとをバインディングすることを目的とし、
   前記第２通信ネットワーク内に位置する他の装置とともに信号メッセージを伝送するように構成された第２インタフェース（Ｉ_２）と、
   前記第２インタフェースから前記通信クライアントに送信された着信信号メッセージ（ＭＩ）を保存するように構成されたメモリ（Ｍ）を含み、
   前記第１インタフェースは、前記着信信号メッセージのうちの１つの到着に続いて、前記第１インタフェースがが、前記通信クライアント（Ｃ_１）がＴＣＰプロトコルを使用して新しい登録メッセージ（Ｍ_Ｎ＋１）を送信することを要求する応答メッセージ（Ｒ_Ｎ）で通信クライアントからのＵＤＰプロトコル登録メッセージに応答し、前記第１インタフェースが、通信クライアントからのＴＣＰプロトコルを使用した前記新しい登録メッセージの受信に続いて、通信クライアントへ前記着信信号メッセージ（ＭＩ）を配信するように、設計されていることを特徴とする、信号サーバ。
8. 前記第１通信ネットワークがプライベートネットワークであり、前記第２通信ネットワークがパブリック通信ネットワークである、請求項７に記載の信号サーバ。
9. 前記応答メッセージがＵＤＰプロトコルによって搬送される、請求項７または８に記載の信号サーバ。
10. 前記第１インタフェースが、「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」メッセージを伝送するＴＣＰプロトコルを使用して、新しい登録メッセージが送信されることを要求するように設計された、請求項７から９のいずれか一項に記載の信号サーバ。
11. 前記「３０２ Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ」メッセージが、「ＴＣＰ」に設定された「Ｔｒａｎｓｐｏｒｔ」パラメータを含む「Ｃｏｎｔａｃｔ」ヘッダを含む、請求項１０に記載の信号サーバ。
12. 前記信号メッセージが、ＳＩＰプロトコルによる最初のメッセージであり、「Ｉｎｖｉｔｅ」、「Ｓｕｂｓｃｒｉｂｅ」、「Ｐｕｂｌｉｓｈ」、「Ｒｅｆｅｒ」、および「Ｍｅｓｓａｇｅ」を含むグループの中から選択される、請求項７から９のいずれか一項に記載の信号サーバ。

Images