(57)【特許請求の範囲】
【請求項１】
第１通信ネットワーク（Ｎ１）とは異なる第２通信ネットワーク（Ｎ）内に位置し、アドレス変換装置（ＮＡＴ１）を介して前記第１ネットワークに接続されている信号サーバ（Ｓ）を介して、前記第１通信ネットワーク（Ｎ１）内に位置する第１通信クライアント（Ｃ１）と、第２通信クライアント（Ｃ２）との間の通信セッションを確立するための方法であって、前記第１通信クライアントに、ＵＤＰプロトコルに従って信号サーバに登録メッセージを伝送させることによって、前記アドレス変換装置内の前記第１通信クライアントの第１アドレスと第２アドレスとをバインディングするステップを含み、前記方法が、
−第２通信クライアントから送信された、第１通信クライアント宛ての着信信号メッセージを信号サーバで保存することと、
−信号サーバにより、保存された着信信号メッセージに後続する第１通信クライアントからの登録メッセ−ジに、第１通信クライアントがＴＣＰプロトコルを使用して新しい登録メッセージ（ＭＮ＋１）を送信することを要求する応答メッセージ（ＲＮ）で応答することと、
−ＴＣＰプロトコルを使用した前記新しい登録メッセージが信号サーバにより受信された後に、信号サーバにより前記着信信号メッセージ（ＭＩ）を第１通信クライアントへ配信することを有することを特徴とする、方法。
【請求項２】
前記第１通信ネットワークがプライベートネットワークであり、前記第２通信ネットワークがパブリック通信ネットワークである、請求項１に記載の方法。
【請求項３】
前記応答メッセージがＵＤＰプロトコルによって搬送される、請求項１または２に記載の方法。
【請求項４】
前記信号サーバが、「３０２  Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ」メッセージを伝送するＴＣＰプロトコルを使用して、新しい登録メッセージが送信されることを要求する、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記「３０２  Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ」メッセージが、「ＴＣＰ」に設定された「Ｔｒａｎｓｐｏｒｔ」パラメータを含む「Ｃｏｎｔａｃｔ」ヘッダを含む、請求項４に記載の方法。
【請求項６】
前記信号メッセージがＳＩＰプロトコルによる最初のメッセージであり、「Ｉｎｖｉｔｅ」、「Ｓｕｂｓｃｒｉｂｅ」、「Ｐｕｂｌｉｓｈ」、「Ｒｅｆｅｒ」、および「Ｍｅｓｓａｇｅ」を含むグループの中から選択される、請求項１から５のいずれか一項に記載の方法。
【請求項７】
信号サーバ（Ｓ）であって、
前記信号サーバが位置する第２通信ネットワーク（Ｎ）と異なり、アドレス変換装置（ＮＡＴ１）を介して前記信号サーバに接続している第１通信ネットワーク（Ｎ１）内に位置する少なくとも１つの通信クライアント（Ｃ１）と信号メッセージを交換するように構成された第１インタフェース（Ｉ１）を含み、前記第１インタフェースが、通信クライアントから送信された登録メッセージを受信するように設計されており、前記アドレス変換装置内の前記通信クライアントの第１アドレスと第２アドレスとをバインディングすることを目的とし、
前記第２通信ネットワーク内に位置する他の装置とともに信号メッセージを伝送するように構成された第２インタフェース（Ｉ２）と、
前記第２インタフェースから前記通信クライアントに送信された着信信号メッセージ（ＭＩ）を保存するように構成されたメモリ（Ｍ）を含み、
前記第１インタフェースは、前記着信信号メッセージのうちの１つの到着に続いて、前記第１インタフェースがが、前記通信クライアント（Ｃ１）がＴＣＰプロトコルを使用して新しい登録メッセージ（ＭＮ＋１）を送信することを要求する応答メッセージ（ＲＮ）で通信クライアントからのＵＤＰプロトコル登録メッセージに応答し、前記第１インタフェースが、通信クライアントからのＴＣＰプロトコルを使用した前記新しい登録メッセージの受信に続いて、通信クライアントへ前記着信信号メッセージ（ＭＩ）を配信するように、設計されていることを特徴とする、信号サーバ。
【請求項８】
前記第１通信ネットワークがプライベートネットワークであり、前記第２通信ネットワークがパブリック通信ネットワークである、請求項７に記載の信号サーバ。
【請求項９】
前記応答メッセージがＵＤＰプロトコルによって搬送される、請求項７または８に記載の信号サーバ。
【請求項１０】
前記第１インタフェースが、「３０２  Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ」メッセージを伝送するＴＣＰプロトコルを使用して、新しい登録メッセージが送信されることを要求するように設計された、請求項７から９のいずれか一項に記載の信号サーバ。
【請求項１１】
前記「３０２  Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ」メッセージが、「ＴＣＰ」に設定された「Ｔｒａｎｓｐｏｒｔ」パラメータを含む「Ｃｏｎｔａｃｔ」ヘッダを含む、請求項１０に記載の信号サーバ。
【請求項１２】
前記信号メッセージが、ＳＩＰプロトコルによる最初のメッセージであり、「Ｉｎｖｉｔｅ」、「Ｓｕｂｓｃｒｉｂｅ」、「Ｐｕｂｌｉｓｈ」、「Ｒｅｆｅｒ」、および「Ｍｅｓｓａｇｅ」を含むグループの中から選択される、請求項７から９のいずれか一項に記載の信号サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信ネットワークに関する。より正確には、本発明はＮＡＴ（「ネットワークアドレス変換」）装置などのアドレス変換装置を介して信号メッセージを伝送する問題に関する。
【背景技術】
【０００２】
現在の通信ネットワークは、Ｈ．３２３、ＭＧＣＰ（メディアゲートウェイ制御プロトコル）、またはＳＩＰ（セッション開始プロトコル）およびＳＤＰ（セッション記述プロトコル）などの信号プロトコルによる通信セッションの確立を可能にする。
【０００３】
このＳＩＰプロトコルは、ＩＥＴＦ（インターネット技術標準化委員会）によって発行されたＲＦＣ３２６１によって定義され、その二重目的は、
−２者が交信できるようにすることと、
−ＳＤＰプロトコルを介して、確立されるべきセッションの特性（ビデオビットレート、どの符号器（ＣＯＤＥＣ）を使用すべきか、など）のネゴシエーションを可能にすること、である。
【０００４】
セッション特性のネゴシエーションは、ＲＦＣ３２６４、表題「ＳＤＰ  ｏｆｆｅｒ／ａｎｓｗｅｒ  ｍｏｄｅｌ」によって指定される。
【０００５】
相手を呼び出したいと願う発呼者は、発呼者の個人アドレス、発呼者の端末（または、より一般的に言えばクライアント）の物理アドレス、および呼び出されている相手の個人アドレスを含む、「プロキシ」として知られる信号要素に、信号メッセージ（「Ｉｎｖｉｔｅ」）を送信できる。信号要素は、呼び出されている相手の個人アドレスを対応する端末の物理アドレスにマッチングさせるための手段（「ｒｅｇｉｓｔｒａｒ」）を有する。このマッチングによって、呼び出されている相手に信号メッセージがルーティングできるようになる。
【０００６】
相手が呼を受け入れると、その相手は端末またはクライアントの物理アドレスを含む新しい信号メッセージで応答する。このようにして、両端末が相手の物理アドレスを知ると、両端末はデータ（音声、ビデオなど）を伝送するためのＩＰ（インターネットプロトコル）接続を確立できる。
【０００７】
しかし、ＲＦＣ１６３１「Ｔｈｅ  ＩＰ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ」において、およびＲＦＣ３０２２「Ｔｒａｄｉｔｉｏｎａｌ  ＩＰ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ（Ｔｒａｄｉｔｉｏｎａｌ  ＮＡＴ）」において定義される、ＮＡＴ（「ネットワークアドレス変換」）またはＮＡＰＴ（「ネットワークアドレスポート変換」）装置として知られるアドレス変換装置に問題が生じる。これらの装置は、第１ネットワーク（一般にはプライベートネットワーク）と第２ネットワーク（パブリックインターネットネットワークなど）をインタフェースさせるように設計されている。
【０００８】
第１ネットワークの装置（端末）は、有効性がその第１ネットワークに限定される物理ＩＰアドレスを有する。第１ネットワークの装置が、その第１ネットワークの外部に位置する装置との通信の確立を望む場合、アドレス変換装置が第２ネットワークに有効な一時第２アドレスを割り当てて、クライアントの第１アドレスと第２アドレスとの間の関連性を保つ。
【０００９】
したがって、ＮＡＴアドレス変換装置は２つの通信ネットワーク間で伝送されたメッセージを：
−送信メッセージ、すなわち第１ネットワークからパブリック第２ネットワークに送信されているメッセージのＩＰヘッダ内の、端末の第１アドレスを第２アドレスに変換することによって、および、
−着信メッセージ、すなわち第２ネットワークから第１ネットワークに送信されているメッセージのＩＰヘッダ内の、端末の第２アドレスを第１アドレスに変換することによって、オンザフライで修正する。
【００１０】
したがって、アドレス変換装置、すなわちＮＡＴ装置は、第１アドレスと第２アドレスとをマッチアップさせるために使用される表を所有する。これらのマッチアップは一時的なものであり、接続またはセッションが終了すると削除される。これらの関連性またはマッチアップは、従来「バインディング」として知られる。
【００１１】
したがって、ＳＩＰ／ＳＤＰ信号メッセージ（あるいはＨ．３２３、またはその他）がアドレス変換装置を通過するときに問題が生じる。この問題は、「ＮＡＴ通過」として知られる。
【００１２】
ＮＡＴ通過は、とりわけオープンコンテント百科事典「ウィキペディア」、アドレス：「ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＮＡＴ＿ｔｒａｖｅｒｓａｌ．ｈｔｍｌ」において説明されており、ＩＥＴＦによって発行されたＲＦＣ３２３５、表題「Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ（ＮＡＴ）−Ｆｒｉｅｎｄｌｙ  Ａｐｐｌｉｃａｔｉｏｎ  Ｄｅｓｉｇｎ  Ｇｕｉｄｅｌｉｎｅｓ」において言及されている。
【００１３】
ＳＩＰおよびＳＤＰなどの信号プロトコルは、アプリケーションプロトコルと考えられる。ＳＩＰ／ＳＤＰプロトコルは、たとえば、それら自体がプロトコルスタック内のＩＰの上に位置するＴＣＰまたはＵＤＰプロトコルを介して伝送されてよい。したがって、実際にはＳＩＰメッセージは、それ自体がＩＰメッセージ内に含まれたＴＣＰまたはＵＤＰメッセージ内に含まれた、パラメータの連続である。
【００１４】
ＮＡＴアドレス変換装置は、ＩＰ層内で発見されたパラメータだけを編集して、上位層内で発見されたパラメータはそのままにしておく。
【００１５】
言い換えれば、ＩＰヘッダ内に含まれるアドレスとは違って、ＳＩＰおよびＳＤＰメッセージ内に含まれる物理アドレスは、アドレス変換装置によって編集されない。
【００１６】
その結果、信号メッセージの受信者（呼び出されているクライアント）は、発呼クライアントの第１アドレスしか知ることができない。しかし、このアドレスが有意味なのは第１ネットワーク内だけなので、どのような通信セッションも確立できない。
【００１７】
この問題はよく知られているので、解決するために数多くのソリューションが提案されてきた。この問題を解決するための２つの主な手法がある。発呼クライアントに基づく手法、および通信ネットワークのサーバまたは装置に基づく手法である。
【００１８】
第１カテゴリは、ＲＦＣ３４８９で説明された、ＳＴＵＮ（「Ｓｉｍｐｌｅ  Ｔｒａｖｅｒｓａｌ  ｏｆ  ＵＤＰ  ｔｈｒｏｕｇｈ  ＮＡＴｓ」）メカニズムを特に含む。このメカニズムによって、クライアント（または端末）は第２アドレスを知ることができるようになる。この方法では、発呼クライアントは、第２通信ネットワーク（たとえば、パブリックネットワーク）に送信されているメッセージよりも前に、この第２ネットワーク内に位置するＳＴＵＮサーバに要求を伝送する。このネットワークは、クライアント、すなわちクライアントの第２アドレスを「見る」アドレス（およびポート）を含むメッセージで応答する。
【００１９】
次いで、クライアントは、ＳＤＰプロトコルを介して応答を受信するためにどのアドレスを使用したいかを示すために、この第２アドレスを使用してよい。
【００２０】
しかし、数多くのＮＡＴ装置が「対称型」で、１組の通話者に第２アドレスをバインディングすると言われるので、このソリューションは重要な制限に悩まされることになる。さらに、ＮＡＴ装置によってクライアントに割り当てられた第２アドレスは、ＳＴＵＮサーバとの通信と、相手と確立されるべきセッションとでは異なる場合がある。同様の場合、クライアントと相手との間の通信は確立できない。
【００２１】
この状況を改善するために、ＴＵＲＮ（「Ｔｒａｖｅｒｓａｌ  Ｕｓｉｎｇ  Ｒｅｌａｙ  ＮＡＴ」）メカニズムなどの他の提案が、同じ原則に基づいて作成された。ＴＵＲＮメカニズムの仕様は、ウェブアドレスｈｔｔｐ：／／ｉｅｔｆｒｅｐｏｒｔ．ｉｓｏｃ．ｏｒｇ／ｉｄｒｅｆ／ｄｒａｆｔ−ｒｏｓｅｎｂｅｒｇ−ｍｉｄｃｏｍ−ｔｕｒｎ／で入手可能である。
【００２２】
しかし、ＳＴＵＮメカニズムとＴＵＲＮメカニズムのどちらもＳＩＰプロトコルに適していない。
【００２３】
さらに、ＳＩＰ信号メッセージを通過に適するようにするために、新しいメカニズムであるＩＣＥ（「Ｉｎｔｅｒａｃｔｉｖｅ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ」）が提案された。ＩＣＥは、ＳＴＵＮおよびＴＵＲＮメカニズムを適合させることによって、ＳＴＵＮおよびＴＵＲＮメカニズムに基づく。
【００２４】
ＩＣＥメカニズムの仕様は、ウェブアドレスｈｔｔｐ：／／ｉｅｔｆｒｅｐｏｒｔ．ｉｓｏｃ．ｏｒｇ／ｉｄｒｅｆ／ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｉｃｅ／で入手可能である。
【００２５】
ソリューションの第２カテゴリは、通信ネットワーク内の装置に依存する。最も初期のソリューションはネットワーク内にサーバ（たとえば、ＳＴＵＮサーバ）を実装したが、クライアントがイニシアチブを有する点に留意されたい。しかし、ソリューションのこの第２ファミリでは、イニシアチブおよびＮＡＴ通過ソリューションの実装は、両方ともネットワーク装置に課せられた義務である。
【００２６】
たとえば、このファミリに属する第１ソリューションは、アプリケーションゲートウェイをＮＡＴアドレス変換装置にバインディングしている。このメカニズムは、「Ａｐｐｌｉｃａｔｉｏｎ  Ｌａｙｅｒ  Ｇａｔｅｗａｙ」または「Ａｐｐｌｉｃａｔｉｏｎ−Ｌｅｖｅｌ  Ｇａｔｅｗａｙ」を意味するＡＬＧとして知られ、１９９９年８月に発行されたＲＦＣ２６６３、表題「ＩＰ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ（ＮＡＴ）Ｔｅｒｍｉｎｏｌｏｇｙ  ａｎｄ  Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ」のパラグラフ２．９で定義される。
【００２７】
このゲートウェイ（または、このようなゲートウェイと同じ機能を有するＮＡＴ装置）は、メッセージによって使用されるアプリケーションプロトコルを理解するための手段を有する。特に、このゲートウェイは信号メッセージのコンテンツを理解でき、通話者が自分の第１アドレスではなく第２アドレスを交換して、それによって通信セッションを確立できるように、ＳＤＰメッセージ内に含まれる物理アドレスを変換できる。
【００２８】
このソリューションのある変形形態は、信号メッセージの経路に沿って位置することになるセッションコントローラ、すなわちＳＢＣ（「Ｓｅｓｓｉｏｎ  Ｂｏｒｄｅｒ  Ｃｏｎｔｒｏｌｌｅｒ」を意味する）を使用することで構成される。このタイプの製品により、両ネットワーク間の通信セッションおよび信号メッセージの送信を制御することが可能になる。より正確には、ＳＢＣは、通話者間で通信セッションが適切に確立されうるように、Ｍｅｇａｃｏなどのプロトコルを介してメディアを伝送する手段（「メディアプロキシ」）を制御できる、ＳＩＰ「プロキシ」信号要素の役割を担うことができる。
【００２９】
しかし、接続またはセッションの終了後、ＮＡＴアドレス変換装置は第１および第２アドレス内のバインディングを保存しないので、他の技術的な問題が生じる。
【００３０】
ＳＩＰ信号メッセージは、ＴＣＰ（伝送制御プロトコル）またはＵＤＰ（ユーザデータグラムプロトコル）プロトコルによってトランスポートされうる。ＴＣＰプロトコルは、セッションを終了させるための操作が行われるまでオープン接続を保つ。さらに、ＴＣＰを使用するＳＩＰセッションが使用される場合、ＴＣＰ接続が終了するまでＮＡＴアドレス変換装置がバインディングを保存することになる。
【００３１】
しかし、ＵＤＰプロトコルについてはどのような接続も確立されない。さらに、ＮＡＴアドレス変換装置はバインディングを一時的に、すなわちあらかじめ定められた長さの期限が切れるまで保存するにすぎない。
【００３２】
したがって、ＳＩＰ信号をトランスポートするためのＵＤＰプロトコルの使用は、ＮＡＴアドレス変換装置通過にとって重大な問題を引き起こす。
【００３３】
しかし、ＴＣＰプロトコルを使用することも、オープン接続を保存するためにさまざまな参加者を必要とするので、問題を引き起こす。このような場合、サーバまたはプロキシは、通信をしているＳＩＰ端末、すなわちクライアントと同数のオープン接続が保存されるように保たなければならない。
【００３４】
それぞれのＴＣＰ接続がかなりの量のコンテキストデータを表すので、これはＳＩＰプロキシにとって重大な負担である。通信ネットワークの設計者は、Ｌｉｎｕｘなどのオペレーティングシステムが操作できるＴＣＰ接続の最大限度（６５５３６の同時接続数）などの、非常に明確な問題に直面していることにも気づくだろう。
【００３５】
さらに、現在ほとんどのＳＩＰアーキテクチャはＵＤＰトランスポートプロトコルに基づいている。
【００３６】
第１アドレスと第２アドレスとの間のバインディングの一時的な性質を矯正するために、バインディングをアクティブに保つことを唯一の目的として、両者間で定期的に信号メッセージが伝送される。
【００３７】
これらの信号メッセージは通常ＳＩＰプロトコルの「Ｒｅｇｉｓｔｅｒ」メッセージであり、バインディングの有効期限値を含む「Ｅｘｐｉｒｅｓ」ヘッダを含む。この有効期間は、クライアントとサーバまたはプロキシとの間でネゴシエーションされうる。たとえば、第１の「Ｒｅｇｉｓｔｅｒ」メッセージ内で、クライアントが第１の値を示す。サーバまたはプロキシは「Ｅｘｐｉｒｅｓ」ヘッダ内に第２の値を含む「２００  Ｏｋ」メッセージで応答する。標準によれば、クライアントは次いでこの第２の値を有効期間として使用しなければならない。次いで、クライアントはこの第２の値によって決定された一定の間隔で「Ｒｅｇｉｓｔｅｒ」メッセージを送信することになる。
【００３８】
この手法は「ＵＤＰホールパンチング」として知られる。
【００３９】
しかしＴＣＰプロトコルには、ある種のアプリケーションにとってＴＣＰプロトコルを必要なものにする利点がある。
【００４０】
たとえば、メッセージのサイズが大きい場合、ＵＤＰプロトコルはそのメッセージをより小さいデータグラムに分解するので、断片化問題を引き起こすことがある。しきい値は通信ネットワークに依存し、通信ネットワークの最大伝送ユニット（すなわちＭＴＵ）によって決定される。このしきい値は、イーサネット（登録商標）ネットワーク（ＴＭ）では１３００バイトである。
【００４１】
ＲＦＣ３２６１のパラグラフ１８．１．１で説明されるように、一旦ＳＩＰメッセージがこのしきい値からバッファ値２００バイトを引いたものに対応するサイズを越えると、ＵＤＰプロトコルはもはや使用できない。このような場合、ＴＣＰプロトコル（または、輻輳制御を可能にする他のプロトコル）が使用されなければならない。
【先行技術文献】
【非特許文献】
【００４２】
【非特許文献１】ＩＥＴＦ（インターネット技術標準化委員会）によって発行されたＲＦＣ３２６１
【非特許文献２】ＲＦＣ３２６４、表題「ＳＤＰ  ｏｆｆｅｒ／ａｎｓｗｅｒ  ｍｏｄｅｌ」
【非特許文献３】ＲＦＣ１６３１「Ｔｈｅ  ＩＰ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ」
【非特許文献４】ＲＦＣ３０２２「Ｔｒａｄｉｔｉｏｎａｌ  ＩＰ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ（Ｔｒａｄｉｔｉｏｎａｌ  ＮＡＴ）」
【非特許文献５】オープンコンテント百科事典「ウィキペディア」、「ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＮＡＴ＿ｔｒａｖｅｒｓａｌ．ｈｔｍｌ」
【非特許文献６】ＩＥＴＦによって発行されたＲＦＣ３２３５、表題「Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ（ＮＡＴ）−Ｆｒｉｅｎｄｌｙ  Ａｐｐｌｉｃａｔｉｏｎ  Ｄｅｓｉｇｎ  Ｇｕｉｄｅｌｉｎｅｓ」
【非特許文献７】ＲＦＣ３４８９
【非特許文献８】ＴＵＲＮメカニズムの仕様、ｈｔｔｐ：／／ｉｅｔｆｒｅｐｏｒｔ．ｉｓｏｃ．ｏｒｇ／ｉｄｒｅｆ／ｄｒａｆｔ−ｒｏｓｅｎｂｅｒｇ−ｍｉｄｃｏｍ−ｔｕｒｎ／
【非特許文献９】ＩＣＥメカニズムの仕様、ｈｔｔｐ：／／ｉｅｔｆｒｅｐｏｒｔ．ｉｓｏｃ．ｏｒｇ／ｉｄｒｅｆ／ｄｒａｆｔ−ｉｅｔｆ−ｍｍｕｓｉｃ−ｉｃｅ／
【非特許文献１０】１９９９年８月に発行されたＲＦＣ２６６３、表題「ＩＰ  Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｏｒ（ＮＡＴ）Ｔｅｒｍｉｎｏｌｏｇｙ  ａｎｄ  Ｃｏｎｓｉｄｅｒａｔｉｏｎｓ」のパラグラフ２．９
【発明の概要】
【発明が解決しようとする課題】
【００４３】
ＵＤＰプロトコルの使用とＴＣＰプロトコルの使用のどちらも満足のいくものではなく、両方の知られているソリューションによって生じる技術的な問題を矯正するソリューションが必要である。本発明の目的は、このようなソリューションを提案することである。
【課題を解決するための手段】
【００４４】
そのためには、本発明の第１の目的は、第１ネットワークとは異なる第２通信ネットワーク内に位置し、アドレス変換装置を介して第１ネットワークに接続されている信号サーバを用いて、第１通信ネットワーク内に位置する第１通信クライアントと、第２通信クライアントとの間の通信セッションを確立するための方法である。
【００４５】
この方法は、前記第１通信クライアントに、通信サーバに登録メッセージを伝送させることによって、アドレス変換装置内の第１通信クライアントの第１アドレスと第２アドレスとをバインディングするステップで構成される。
【００４６】
本方法は、信号サーバが：
−第２通信クライアントから送信された、第１通信クライアント宛ての着信信号メッセージを保存し、
−後続の登録メッセ−ジに、第１通信クライアントがＴＣＰプロトコルを使用して新しい登録メッセージを送信することを要求する応答メッセージで応答し、
−新しい登録メッセージが受信された後で、以前保存された着信信号メッセージを配信することを特徴とする。
【００４７】
たとえば、第１通信ネットワークは、プライベートネットワークでよく、第２通信ネットワークは、パブリック通信ネットワークでよい。
【００４８】
登録メッセージおよび応答メッセージは、ＵＤＰプロトコルによって搬送されてよい。
【００４９】
本発明の一実施形態では、信号サーバは、「３０２  Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ」メッセージを伝送するＴＣＰプロトコルを使用して、新しい登録メッセージを送信することを要求する。
【００５０】
この「３０２  Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ」メッセージは、「ＴＣＰ」に設定された「Ｔｒａｎｓｐｏｒｔ」パラメータを含む「Ｃｏｎｔａｃｔ」ヘッダを含む。
【００５１】
最後に、本発明の一実施形態では、信号メッセージはＳＩＰ信号メッセージ「Ｉｎｖｉｔｅ」、「Ｓｕｂｓｃｒｉｂｅ」、「Ｐｕｂｌｉｓｈ」、「Ｒｅｆｅｒ」、および「Ｍｅｓｓａｇｅ」を含むグループの中から選択される、ＳＩＰプロトコルによる最初のメッセージでよい。
【００５２】
本発明の他の目的は：
−信号サーバが位置する第２通信ネットワークと異なり、アドレス変換装置を介して前記サーバに接続している第１通信ネットワーク内に位置する少なくとも１つの通信クライアントと信号メッセージを交換するための第１インタフェースと、
−第２通信ネットワーク内に位置する他の装置とともに信号メッセージを伝送するための第２インタフェースとを含む、信号サーバである。
【００５３】
第１インタフェースは、通信クライアントから送信された登録メッセージを受信するように設計されており、アドレス変換装置内の通信クライアントの第１アドレスと第２アドレスとの間のバインディングを維持することを目的としている。
【００５４】
この通信サーバは：
−第２インタフェースから通信クライアントに送信された着信信号メッセージを保存するためのメモリをさらに含むことと、
−第１インタフェースが、着信信号メッセージの到着後、通信サーバが、後続の登録メッセージに、通信クライアントがＴＣＰプロトコルを使用して新しい登録メッセージを送信することを要求する応答メッセージで応答して、この新しい登録メッセージの受信に続いて、着信信号メッセージ（以前に保存された）を配信できるように設計されていることとを特徴とする。
【００５５】
最後に、本発明の第３の目的は、このような通信サーバ実装する少なくとも１つのＣＳＣＦ（「呼セッション制御機能」）機能要素を含む、ＩＭＳ（「ＩＰマルチメディアサブシステム」）アーキテクチャである。
【００５６】
この方法では、必要な場合のみＴＣＰ接続が確立され、通信セッションごとに同時に１つのＴＣＰ接続をアクティブに保つ必要はない。したがって過剰なＴＣＰ接続によってもたらされる問題が生じず、しかしＴＣＰ接続を「オンデマンド」で確立することによってＵＤＰプロトコルに関する不足が解決する。
【００５７】
本発明のソリューションの唯一の欠点は、ＴＣＰ接続が確立されるまで着信信号メッセージを保存することによって、遅延が生成される可能性があることである。この遅延は、リフレッシュ時間によって決定される。
【００５８】
本発明、本発明の諸特徴、および本発明の諸利点は、添付の図面に関連して以下の説明で明らかになるだろう。
【図面の簡単な説明】
【００５９】
【図１】本発明の信号サーバが配備されうるアーキテクチャを示す図である。
【図２】通信クライアントと本発明の信号サーバとの間で実装されうる、例示的対話のダイアグラムを示す図である。
【発明を実施するための形態】
【００６０】
図１に示した例示的ネットワークアーキテクチャにおいて、２つの通信クライアントＣ１およびＣ２が通信ネットワークＮに接続されている。通信クライアントＣ１は第１通信ネットワークＮ１に属し、第１通信ネットワークＮ１はアドレス変換装置ＮＡＴ１を介して第２通信ネットワークＮに接続されている。
【００６１】
通信クライアントＣ１は、第１通信ネットワークＮ１内で使用されうる第１アドレスを所有している。通信クライアントＣ１は、この第１アドレスをこの第１ネットワーク（装置ＮＡＴ１を含む）に属する装置と通信するために使用できるが、外部の装置と通信するためには使用できない。これらの外部の装置と通信するためには、アドレス変換装置ＮＡＴ１によって第２アドレスが通信クライアントＣ１に一時的に割り当てられる。
【００６２】
したがって、このアドレス変換装置ＮＡＴ１は、クライアントＣ１の第１アドレスと第２アドレスと間のバインディングを維持する。このクライアントＣ１からの、またはそこへのメッセージが分析されて、第１アドレスが第２アドレスに、およびその逆に変換される。
【００６３】
第１通信ネットワークは、たとえば、プライベート通信ネットワークでよく、第２通信ネットワークはパブリックネットワークでよい。
【００６４】
通信クライアントＣ１は、信号サーバＳを介して通信クライアントＣ２に接続できる。この信号サーバは、一般にＳＩＰプロキシサーバである。３ＧＰＰまたはＴＩＳＰＮＡ標準機構によって指定されたＩＭＳ（ＩＰマルチメディアサブシステム）アーキテクチャがあれば、このサーバまたはプロキシサーバはＣＳＣＦ（呼セッション制御機能）要素でよい。
【００６５】
信号サーバＳはＳＧＣ（セッションボーダコントローラ）でもよい。
【００６６】
以下の説明では、クライアントＣ１と信号サーバとの間の接続だけを主に取り扱う。したがって、クライアントＣ２とサーバＳとの間の接続は詳細に説明しない。
【００６７】
図１に示された例は、本発明をより良く理解するために、ある非常に単純化された実施形態を表している。この方法では、通信クライアントＣ２は、第２アドレス変換装置ＮＡＴ２を介して第２通信ネットワークＮに接続された、第３ネットワークＮ２に属する。
【００６８】
実際の配備では、信号サーバＳと通信クライアントＣ２との間に他の装置が存在してよい。たとえば、通信クライアントＣ２は他の信号サーバに接続してよく、両信号サーバは直接または他のサーバを介して通信してよい。
【００６９】
しかし、図１に示される例は、本発明の精神から逸脱することなしに、また本発明において直接的な役割を担わない装置に焦点を合わせることなしに、本発明を理解することを可能にする。
【００７０】
第１および第２アドレスをバインディングするために、通信クライアントＣ１は登録メッセージを信号サーバＳに伝送する。これらのメッセージは、一般に定期的に、場合によってはネゴシエーション後に伝送される。
【００７１】
図２は、クライアントＣ１と信号サーバＳとの間の交換を示している。それぞれの縦軸はネットワーク要素を表しており、それぞれＣ１、アドレス変換装置ＮＡＴ１、および信号サーバＳである。線が下方に移動するにつれて時間が増加する。水平矢印は、これらの要素間で交換された信号メッセージを表している。
【００７２】
登録メッセージＭ１は、最初の登録メッセージである。登録メッセージＭ１は、リフレッシュ時間のための第１の値を指定する。この第１の値は高くてよく、たとえば３６００秒でよい。
【００７３】
信号サーバＳは、第２の値、たとえば３０秒を含んでよい、応答メッセージＲ１で応答する。
【００７４】
次いで、クライアントＣ１は、応答メッセージＲ１内で伝送されたこの第２の値を基礎として使用してよい。第２の値がない場合は、クライアントＣ１は、以前に自分で決定した第１の値を基礎として使用する。
【００７５】
このようにして決定されたこのリフレッシュ時間値に対応するインターバルΔがある場合、通信クライアントＣ１は信号メッセージＭ２、Ｍ３、Ｍ４．．．を信号サーバＳに伝送し、信号サーバＳはそれぞれ応答メッセージＲ２、Ｒ３、Ｒ４．．．でそれらのメッセージに応答する。
【００７６】
信号サーバは、これらの登録メッセージを受信して応答メッセージで応答するように設計された、インタフェースＩ１を有する。
【００７７】
これらの登録メッセージは、ＳＩＰプロトコルに適合する「Ｒｅｇｉｓｔｅｒ」メッセージでよい。リフレッシュ時間は、これらのメッセージの「Ｅｘｐｉｒｅ」ヘッダ内に含まれてよい。応答メッセージは、ＳＩＰプロトコルの「２００  ＯＫ」メッセージでよく、リフレッシュ時間がもしあれば、「Ｅｘｐｉｒｅ」ヘッダ内に含まれてよい。
【００７８】
これらの登録メッセージＭ１、Ｍ２、Ｍ３、Ｍ４．．．および応答メッセージＲ１、Ｒ２、Ｒ３、Ｒ４．．．は全てが、ＵＤＰプロトコルによって搬送される。「Ｖｉａ」ヘッダ内で、登録メッセージが、トランスポートプロトコルはＵＤＰでなければならないと指定する。
【００７９】
この種のＶｉａヘッダは以下のようでよい：
Ｖｉａ：ＳＩＰ／２．０／ＴＣＰ  ｃｌｉｅｎｔ．ａ．ｅｘａｍｐｌｅ．ｃｏｍ：５６２０；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫ７４ｂｆ９
【００８０】
したがって、これらの信号サーバＳは、クライアントＣ１との接続を処理するために、どのようなＴＣＰ接続もオープンに維持しない。
【００８１】
所与の時間に、信号サーバＳは、第２通信クライアントＣ２から送信された着信信号メッセージＭＩを受信してよい。着信信号メッセージＭＩは、「Ｉｎｖｉｔｅ」、「Ｓｕｂｓｃｒｉｂｅ」、「Ｐｕｂｌｉｓｈ」、「Ｒｅｆｅｒ」、または「Ｍｅｓｓａｇｅ」メッセージなどの、ＳＩＰプロトコルによる「最初の」信号メッセージでよい。「Ｉｎｖｉｔｅ」メッセージの目的は、発呼通信クライアントＣ２との通信セッションの確立を受け入れるために、通信クライアントＣ１をインバイトすることである。
【００８２】
この通信は、ＴＣＰプロトコルの使用を必要とすることがある。
【００８３】
これらの要求が体系的であり、クライアントＣ２から送信されたそれぞれのインビテーションが、確立すべきセッションを搬送するためのＴＣＰ接続の作成につながることが可能である。
【００８４】
ＴＣＰプロトコルとＵＤＰプロトコルとの間で選択が行われるも可能性もある。この選択は、この着信信号メッセージＭＩ内のパラメータによって決定されてよい。このパラメータは、ＳＩＰプロトコルによる「ｃｏｎｔａｃｔ」ヘッダ内に挿入されてよい。
【００８５】
選択は、場合によっては、着信信号メッセージＭＩ内に挿入されたパラメータを考慮に入れることによって、信号サーバＳによって決定されてもよい。
【００８６】
通信セッションがＴＣＰトランスポートプロトコルの使用を必要とすると仮定する。
【００８７】
着信信号メッセージは、信号サーバＳのインタフェースＩ２によって受信されて、メモリＭ内に一時的に保存される。応答メッセージＲＮ−１を送信後、信号サーバＳはそれに続く登録メッセージＭＮを待つ。したがって、着信信号メッセージＭＩを処理するための待ち時間δは、リフレッシュ時間Δより少ない。
【００８８】
サーバＳは、通信クライアントＣ１がＴＣＰプロトコルを使用して新しい登録メッセージを送信することを要求する応答メッセージＲＮで、登録メッセージＭＮに応答する。
【００８９】
一実施形態では、この応答メッセージは、ＳＩＰプロトコルによる「３０２  Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ」メッセージでよい。
【００９０】
このタイプのメッセージは、交信されるべきホストの新しいＵＲＩ（ユニバーサルリソース識別子）を指定する「Ｃｏｎｔａｃｔ」ヘッダを含む。このタイプのメッセージは、それを使ってホストが交信されなければならないトランスポートプロトコルを指定するパラメータも含む。
【００９１】
このパラメータは、ＲＦＣ３２６１のセクション２０．１０によって定義されているように、「Ｔｒａｎｓｐｏｒｔ」パラメータでよい。
【００９２】
「Ｃｏｎｔａｃｔ」ヘッダは、たとえば以下のようでよい：
Ｃｏｎｔａｃｔ：＜ｓｉｐ：ｂｏｂ＠１９２．０．２．４；ｔｒａｎｓｐｏｒｔ＝ＵＤＰ＞；ｅｘｐｉｒｅｓ＝６０
【００９３】
本発明のコンテキスト内で、これはアドレスの真の変更として働かず、したがってこのヘッダは、信号サーバＳのアドレスを含む。トランスポートプロトコルを指定するパラメータの値は「ＴＣＰ」である。
【００９４】
したがって、「３０２  Ｍｏｖｅｄ  Ｔｅｍｐｏｒａｒｉｌｙ」メッセージタイプの使用は、既存のＳＩＰプロトコルに新しいタイプのメッセージが追加される必要なしに、必要とされる情報を伝送することを可能にする。
【００９５】
この応答メッセージＲＮは、ＴＣＰプロトコルを使用して送信されるべき、新しい登録メッセージＭＮ＋１をもたらす。
【００９６】
この新しい登録メッセージは、応答メッセージＲＮの受信直後に、すなわち、以前のようにリフレッシュ時間Δが切れるのを待たずに伝送されてよい。これにより、着信信号メッセージＭＩを処理するための待ち時間を減らすことが可能になる。
【００９７】
登録メッセージＭＮ＋１によって、アドレス変換装置ＮＡＴ１を介して通信クライアントＣ１と信号サーバＳとの間のＴＣＰ接続をオープンできるようになる。
【００９８】
一旦ＴＣＰ接続が確立されると、信号サーバは信号メッセージＭＩを受信側通信クライアントＣ１に配信できる。次いで、信号サーバＳのメモリＭから信号メッセージＭＩが削除される。
【００９９】
通信セッションが終了する（たとえば、２つの通信クライアントのうちの１つを切る）と、信号サーバは終了メッセージを通信クライアントＣ１に伝送してよい。
【０１００】
次いで、ＴＣＰ接続は終了してよい。
【０１０１】
次いで、アドレス変換装置ＮＡＴ１内のバインディングを維持するために、通信クライアントＣ１が、頻度ΔでＵＤＰプロトコルによって搬送された登録メッセージの伝送を再開する。
【０１０２】
上記のように、ＴＣＰ接続はある種のＴＣＰプロトコルアプリケーションの要求を満たす。
【０１０３】
さらに、ＴＣＰ接続により、状況によっては不可能なはずの着信信号メッセージＭＩの送信が可能になる。実際、ある種のアドレス変換装置はファイアウォール機能を有する。それらのアドレス変換装置は、第１ネットワークＮ１またはＴＣＰ接続の一部から送信されたメッセージに応答しない限り、パブリックネットワークＮから送信されたメッセージの伝送を可能にしない。
【０１０４】
このような場合、ＴＣＰ接続の確立により、ファイアウォールＮＡＴ１を介してインビテーションメッセージＭＩを伝送することが可能になる。したがって、本発明はこのさらなる技術的な問題を解決する。
【０１０５】
本発明の結果、ＴＣＰ接続は通信セッションの間のみオープンになる。残りの時間、すなわち通信クライアントは待っているだけだが、インビテーションメッセージを送受信するために利用可能である場合、通常のＵＤＰプロトコル交換が信号サーバとの接続を維持することを可能にする。
【０１０６】
したがって、本発明は、ＳＩＰプロトコルのもとで、ＵＤＰおよびＴＣＰプロトコルのそれぞれの諸利点の恩恵を受けるために、それらのプロトコルの使用を最適化することを可能にする。
【図１】
0005437255.tif 000002
【図２】
0005437255.tif 000003