JP5209061B2 - Ｓｉｐ応答メッセージの送信インターフェースの制御 - Google Patents

Description

本発明は、データ通信ネットワーク上でマルチメディアセッションを確立することを可能にするシグナリングに関する。より詳細には、本発明は、ＩＥＴＦ（インターネットエンジニアリングタスクフォース）のＲＦＣ３２６１によって定義されるＳＩＰ（セッションインビテーションプロトコル（Ｓｅｓｓｉｏｎ Ｉｎｖｉｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ））プロトコルに関する。

図１は、ＳＩＰプロトコルを実装している簡素化されたアーキテクチャを示す。端末など、２つの通信要素ＣおよびＳは、通信ネットワークＮを経由して互いに接続される。これらの通信要素は、Ｐ_ＣおよびＰ_Ｓと呼ばれる中継通信要素に接続されることが可能である。

要素Ｃは、通信要素Ｓと通信セッションを確立することを望むと仮定する。そのために、要素Ｃは、要素Ｃが接続されたプロキシサーバＰ_Ｃにシグナリングメッセージｍを送信する。この第１のメッセージは、通常、「Ｉｎｖｉｔｅ」ＳＩＰメッセージである。

次いで、シグナリングメッセージは、通信要素Ｓが接続された中継要素Ｐ_Ｓに達する前に、図示されない一連の中継要素によって送信されることが可能である。このシグナリングメッセージｍは、次いで、その受信側要素Ｓに送達される。

第１の通信要素Ｃは「クライアント」と呼ばれ、第２の通信要素は「サーバ」と呼ばれるが、これらは機能的用語、すなわち、環境に応じて、通信要素が負うことが可能な役割である。クライアントは、サーバにシグナリングメッセージを送っており、当該サーバから応答を待つ要素である。

通信クライアントおよび通信サーバは、図１の例におけるような通信端末であってよいが、通信クライアントおよび通信サーバは、ＩＭＳ（「ＩＰマルチメディアサブシステム」）アーキテクチャ内でＣＳＣＦ（「呼セッション制御機能」）機能を実装しているサーバなど、アプリケーションサーバまたはシグナリングサーバであってもよい。

ＳＩＰシグナリングメッセージは、通信ネットワーク内でそれが経路指定されていることを確実にするための複数のヘッダ、ならびに、当事者がマルチメディアセッションを確立することを可能にする情報を備える。

これらのヘッダの中に、シグナリングメッセージの送信インターフェースおよび受信インターフェースを示すヘッダがある。

「インターフェース」は、ＩＰアドレス（ＩＰｖ４またはＩＰｖ６）およびポート番号によって形成される対を指す。単一の通信要素は、複数のインターフェースを有し得る。単一の通信要素が、複数の通信ネットワークに属する場合、単一の通信要素は、複数のＩＰアドレスを有し得る。

図２は、この状況の図を示す。

２つの通信要素ＣおよびＳは、２つの通信ネットワークＮ_１およびＮ_２を経由して接続される。したがって、クライアントＣは、それぞれ、ネットワークＮ_１およびＮ_２に関して使用される２個のアドレスＨ_Ｃ１およびＨ_Ｃ２を有する。同様に、サーバは、それぞれ、ネットワークＮ_１およびＮ_２に関して使用される２個のＩＰアドレス、Ｈ_Ｓ１およびＨ_Ｓ２を有する。

これらの要素のそれぞれは、複数の部分を有する。すなわち、クライアントＣは、ポートＰ_Ｃ１、Ｐ_Ｃ２、Ｐ_Ｃ３、Ｐ_Ｃ４、Ｐ_Ｃ５、Ｐ_Ｃ６を含み、サーバＳはＰ_Ｓ１、Ｐ_Ｓ２、Ｐ_Ｓ３、Ｐ_Ｓ４、Ｐ_Ｓ５、Ｐ_Ｓ６を含む。

クライアントＣがシグナリングメッセージＭを送信するときはいつでも、クライアントＣは、ヘッダ内にサーバＳの識別子を示す。この識別子は、中継要素によって変換されることになる論理アドレスであってよく、または直接的にアドレスもしくは物理インターフェースであってもよい（すなわち、ポートが指定されてもよく、または指定されなくてもよい）。この識別子は、クライアントＣがそこからメッセージを送信するインターフェース、ならびにクライアントＣが応答を受信することを望むインターフェースも示す。これらの２つのインターフェースは、同じであってよく、または異なってもよい。

図２の例では、シグナリングメッセージＭは、インターフェースＨ_Ｃ１／Ｐ_Ｃ２からインターフェースＨ_Ｓ１／Ｐ_Ｓ２に送信され、その応答がインターフェースＨ_Ｃ１／Ｐ_Ｃ３に達することが所望されることを指定する。サーバＳは、所望されるインターフェースＨ_Ｃ１／Ｐ_Ｃ３によって受信されることになるインターフェースＨ_Ｓ１／Ｐ_Ｓ３から送信された応答シグナリングメッセージＲを用いて応答する。

しかし、クライアントＣは、クライアントＣがそこからサーバがクライアントＣに応答ＭメッセージＲを送信することを望むインターフェースを指定しなくてもよい。クライアントＣがどのアウトプットインターフェースを使用するかを決定する方式は、実装形態に依存する。

しかし、場合によっては、あるインターフェースを別のインターフェースの代わりに使用する必要があることが判明する場合がある。例えば、これは、（「ネットワークアドレス変換」を指す）ＮＡＴアドレス変換デバイスがクライアントＣとサーバＳとの間に配置される場合、またはシグナリングメッセージをトランスポートするために、ＩＰｓｅｃなどのセキュアな通信プロトコルが使用される場合に当てはまる。

サーバがシグナリングメッセージに応答するためにどのインターフェースを使用するかを決定することを検査するための機構を通信クライアントに提供する必要が存在する。

本発明の目的は、この欠如に対処することである。

本発明の第１の対象は、通信サーバの第１のインターフェースに、ＳＩＰプロトコルに従ってシグナリングメッセージを送信するための少なくとも１つの送信インターフェースを備えた通信クライアントである。当該クライアントおよび当該サーバは、通信ネットワークによって接続される。本発明のクライアントは、その応答シグナリングメッセージを送信するために、通信サーバによって使用されるインターフェースに関する指示をシグナリングメッセージ内に挿入するのに適していることを特徴とする。

本発明の一実施形態では、この指示は、その応答シグナリングメッセージを送信するために通信サーバによって使用されるアドレスを含む。

この指示は、通信サーバがその応答シグナリングメッセージを送信するために使用するアドレスを選択するときに適合するための挙動を指定する予約語を含み得る。

この予約語は、少なくとも、
− 使用するアドレスが、第１のインターフェースのアドレスと同じであることを指定する予約語と、
− 使用するアドレスが、ランダムに決定されなければならないことを指定する予約語と、
− 使用するアドレスを決定するための意味的基準を示す予約語と
を含むグループの中から選択されることが可能である。

この指示は、通信サーバがその応答シグナリングメッセージを送信するために使用するポート番号をさらに含み得る。

この指示は、通信サーバが、その応答シグナリングメッセージを送信するために使用するポート番号を選択するときに適合する挙動を指定する予約語も含み得る。

この予約語は、少なくとも、
− 使用されるポート番号が、第１のインターフェースのポート番号と同じであることを指定する予約語と、
− 使用するポート番号が、ランダムに決定されなければならないことを指定する予約語と、
− 使用するポート番号を決定するための意味的基準を示す予約語と
を含むグループの中から選択されることが可能である。

同様に、通信クライアントが、シグナリングメッセージに応答するためにサーバによって使用される移送プロトコルを決定することを検査することを可能にすることに関して問題が生じる。

通信クライアントは、サーバが、その応答シグナリングメッセージを送信するために使用するためのプロトコルに関する第２の指示を挿入するように設計されることが可能である。

この第２の指示は、インターフェース関連の指示に加えて送信されることが可能であり、または単独で送信されることも可能である。

この指示および／または第２の指示は、例えば、「Ｖｉａ」ヘッダ内に挿入されることが可能である。

本発明のもう１つの対象は、通信ネットワークから着信シグナリングメッセージを受信するための少なくとも１つのインターフェースと、応答シグナリングメッセージを送信するための第２のインターフェースとを備える通信サーバである。

このサーバは、着信シグナリングメッセージ内に含まれた指示に基づいて、第２のインターフェースを決定するようにさらに設計されることを特徴とする。

この指示は、第２のインターフェースに対応するアドレス、または第２のインターフェースに対応するアドレスを選択するために実行するための挙動を指定する予約語を含み得る。

後者の場合、予約語は少なくとも、
− 当該アドレスが、第１のインターフェースのアドレスを同じであることを指定する予約語と、
− 当該アドレスが、ランダムに決定されなければならないことを指定する予約語と、
− 当該アドレスを決定するための意味的基準を示す予約語と、
を含むグループの中から選択されることが可能である。

この指示は、その第２のインターフェースに対応するポート番号も含み得る。

この指示は、第２のインターフェースに対応するポート番号を選択するために実行するための挙動を指定する予約語を含み得る。

この予約語は、少なくとも、
− 当該ポート番号が、第１のインターフェースのポート番号と同じであることを指定する予約語と、
− 当該ポート番号が、ランダムに決定されなければならないことを指定する予約語と、
− 当該ポート番号を決定するための意味的基準を示す予約語と
を含むグループの中から選択されることが可能である。

サーバは、着信シグナリングメッセージ内に含まれた第２の指示に基づいて、応答シグナリングメッセージを送信するために使用するためのプロトコルを決定するようにさらに設計されることが可能である。

この指示および／または第２の指示は、「Ｖｉａ」ヘッダ内に挿入され得る。

本発明のもう１つの対象は、クライアントが、シグナリングメッセージをサーバに送信する第１のステップと、このサーバが、インターフェースからそのクライアントに応答メッセージを送信する第２のステップとを備える、通信ネットワークによって接続されたクライアントとサーバとの間でシグナリングメッセージを通信するための方法である。

この方法は、クライアントが、第１のステップに先立って、シグナリングメッセージ内に指示を挿入し、サーバが、前記第２のステップに先立って、この指示に基づいてインターフェースを決定することを特徴とする。

本発明のもう１つの対象は、先に説明された通信クライアントまたは通信サーバを実装するように設計された通信端末である。

本発明のもう１つの対象は、少なくとも１つのかかる端末を備えた通信ネットワークである。

通信サーバおよび／または通信クライアントは、ＩＭＳアーキテクチャの仕様に従って、ＣＳＣＦ機能を実装している要素であり得る。

本発明のもう１つの対象は、通信デバイスが、ＴＣＰプロトコルによって伝送された、アドレス変換デバイスの背後に配置された第２の通信デバイス向けの着信シグナリングメッセージを受信するとき、通信デバイスが、ＵＤＰプロトコルを使用して、第２のデバイスがＴＣＰプロトコルを使用して応答を当該通信デバイスに送信し、応答メッセージを受信した後で、この着信シグナリングメッセージを送信しなければならないことを指定する指示を含むシグナリングメッセージをその第２のデバイスに送信するように設計された通信デバイスである。

指示のこの追加は、ＲＦＣ３２６１によって定義されたＳＩＰプロトコルに依然として完全に適合する点に留意されたい。この追加は、「Ａｎ ｅｘｔｅｎｓｉｏｎ ｔｏ Ｔｈｅ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ）ｆｏｒ Ｓｙｍｍｅｔｒｉｃ Ｒｅｓｐｏｎｓｅ Ｒｏｕｔｉｎｇ」という表題の、ＲＦＣ３５８１によって定義されたＳＩＰプロトコルに対する拡張にも適合する。このＲＦＣは、シグナリングメッセージを受信するためにサーバによって使用されるインターフェースに関する追加のパラメータ、すなわち、「ｒｅｃｅｉｖｅｄ」および「ｒｐｏｒｔ」を定義する。したがって、これらは、サーバが使用するためのインターフェースに関する指示とは異なるパラメータである。この指示およびＲＦＣ３５８１のパラメータは、シグナリングメッセージ内に共存することが可能であり、または別々に使用されることも可能である。

本発明およびその利点は、添付の図面を参照することにより、以下の説明においてより明瞭に明らかになるであろう。

通信サーバと通信クライアントとを互いに通信させる簡素化されたアーキテクチャを示す上述の図である。 それぞれが複数の通信インターフェースを有するクライアントとサーバとの間の通信を示す図である。 本発明の機構のアプリケーションを示す図である。 本発明の機構のアプリケーションを示す図である。 本発明の機構のアプリケーションを示す図である。 アドレス変換デバイス横断（ｔｒａｖｅｒｓａｌ）の問題に関して、本発明の方法の使用を示す図である。

ＳＩＰプロトコルに適合するシグナリングメッセージは、複数のヘッダを含む。

「Ｆｒｏｍ」ヘッダ、「Ｔｏ」ヘッダ、および「Ｃｏｎｔａｃｔ」ヘッダは、シグナリングメッセージを送受信する要素に関する。図１に示される例では、送信要素はクライアントＣであり、受信要素は要素Ｓであると推定する。

プロキシサーバＰ_ＣおよびＰ_Ｓなど、それぞれの中継要素は、再送信されたシグナリングメッセージに「Ｖｉａ」ヘッダを追加する。

この「Ｖｉａ」ヘッダは、それにより、ネットワーク内でシグナリングメッセージによって利用された経路にマーキングすることを可能にする。次いで、応答メッセージは、「Ｖｉａ」ヘッダを使用して、同じ経路を逆方向に利用することが可能である。このように交差するそれぞれの中間要素は、それ自身に関する「Ｖｉａ」ヘッダを取り除く。

図２では、通信クライアントＣは、シグナリングメッセージＭの送信側である。通信クライアントＣは、例えば、通信端末、または、より一般的には、ＵＡＣ（「ユーザエージェントクライアント」）、もしくはアプリケーションサーバなどであってよい。

通信クライアントＣは、「ＳＩＰプロキシ」中継要素であってもよい。

同様に、通信サーバＳは、シグナリングメッセージの受信側であってよく、端末、アプリケーションサーバ、シグナリングサーバなどであってよい。

通信サーバＳは、「ＳＩＰプロキシ」中継要素の役割を果たすことも可能である。

ＩＭＳ（「ＩＰマルチメディアサブシステム」）アーキテクチャの場合、これらの通信要素は、ＣＳＣＦ（「呼セッション制御機能」）機能を実装しているシグナリング要素であり得る。

念のため、「クライアント」および「サーバ」という用語は、シグナリングメッセージを送信するという状況に関して使用される。同じ通信要素が、クライアントとサーバの両方の役割を果たすことが可能である。例えば、端末は、別の当事者と通信セッションを開始するためのインビテーションメッセージを送信するときクライアントであり、次いで、別の端末からインビテーションメッセージを受信するときサーバになることが可能である。

これらの定義は、ＩＥＴＦのＲＦＣ３２６１の第６項に適合する。

通信クライアントＣは、通信ネットワークＮ_１上でシグナリングメッセージＭをサーバＳに送信するための少なくとも１つの送信インターフェースを備える。

クライアントＣがシグナリングメッセージＭを送信するとき、クライアントＣは「Ｖｉａ」ヘッダを挿入する。クライアントＣがメッセージの送信側ではなく、中継要素として機能している場合、クライアントＣは、このヘッダをすでに提示された「Ｖｉａ」ヘッダのリストに追加する。

このヘッダは、メッセージを送信するために使用される移送プロトコルを示して、クライアントが応答を受信することを望むインターフェースを識別する。

この「Ｖｉａ」ヘッダは、そのいくつかは必須であり、その他はオプションである、複数のパラメータを備える。

ＲＦＣ３２６１によって提示された例に基づいて、「Ｖｉａ」ヘッダは、次の形態であり得る：
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ ｅｒｌａｎｇ．ｂｅｌｌ−ｔｅｌｅｐｈｏｎｅ．ｃｏｍ：５０６０；
ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫａ７ｃ６ａ８ｄｌｚｅ；

「ｅｒｌａｎｇ．ｂｅｌｌ−ｔｅｌｅｐｈｏｎｅ．ｃｏｍ：５０６０」パラメータは、それぞれ、クライアントＣのアドレスと、クライアントＣが当該応答を受信することを望むポートとを表す。パラメータ「ＳＩＰ／２．０／ＵＤＰ」は、それぞれ、使用されたＳＩＰプロトコルのバージョンと、クライアントとサーバとの間でシグナリングメッセージを送信するために使用された移送プロトコルとを決定する。

図２の例では、かかる「Ｖｉａ」ヘッダは次の値を有し得る：
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ Ｈ_Ｃ１：Ｐ_Ｃ３；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫａ７ｃ６ａ８ｄｌｚｅ；

本発明によれば、クライアントは、サーバがその応答シグナリングメッセージを送信するために使用するためのインターフェース（すなわち、シグナリングメッセージを受信しているネットワーク要素）に関する指示を挿入するようにさらに設計されることが可能である。

このインターフェースは、サーバが、１個だけのＩＰアドレスを所有するとき、ポートによって決定されることが可能であり、またはサーバが、複数のＩＰアドレスを有する場合、ＩＰアドレス／ポートの対によって決定されることが可能である。

その結果、この指示は、１つまたは２つの部分で構成されることが可能である。すなわち、１つはＩＰアドレス（「ネットワークインターフェース」）に関し、もう１つはポートに関する。

したがって、この指示は、アドレス、特に、ＩＰ（インターネットプロトコル）アドレス、または、ＳＩＰプロトコルに適合するＵＲＩ（「ユニバーサルリソース識別子」）などの論理識別子を含む。

この指示は、ポート番号も含み得る。

この指示の様々な部分は、キーワードによってもたらされることが可能である。例として、キーワード「ｒｐａｔｈＨｏｓｔ」および「ｒｐａｔｈＰｏｒｔ」は、それぞれ、アドレス関連の部分と、ポート関連の部分とをもたらすために使用され得る。

図２の例では、１つの可能な「Ｖｉａ」ヘッダは、以下であろう：
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ Ｈ_Ｃ１：Ｐ_Ｃ３；ｂｒａｎｃｈ＝ｚ９ｈＧ４ｂＫａ７ｃ６ａ８ｄｌｚｅ；ｒｐａｔｈＨｏｓｔ＝Ｈ_Ｓ１；ｒｐａｔｈＰｏｒｔ＝Ｐ_Ｓ３；

これらの２つの部分は、アドレス識別子またはポート番号ではなく、予約語を含んでもよい。この予約語は、通信サーバが、その応答シグナリングメッセージを送信するために使用するためのインターフェース（すなわち、アドレスおよび／またはポート）を選択するために実行する挙動を指定する。

かかる予約語は、使用するアドレスまたはポートが、サーバがメッセージを受信したアドレスまたはポートと同じであることを指定することが可能である。

かかる予約語は、使用するアドレスまたはポートが、ランダムに決定されなければならないことを指定することが可能である。

かかる予約語は、使用するアドレスまたはポートを決定するための意味的基準を示すことも可能である。

サーバが複数のアドレスを所有するとき、アドレス関連の部分だけに関して、もしくはポート関連の部分に関して、またはそれらの両方に関して、かかる予約語を使用することが当然可能である。後者の場合、予約語は、アドレスおよびポートと同一であってよく、または異なってもよい。

さらに、通信クライアントは、サーバが、その応答シグナリングメッセージを送信するために使用するためのプロトコルに関する第２の指示を挿入するように設計されることが可能である。

この指示は、プロトコル識別子であり得る。この識別子は、利用可能な移送プロトコルのうちの１つの識別子、すなわち、ＴＣＰ、ＵＤＰなどであり得る。

この指示は、プロトコル識別子ではなく、予約語であってもよい。この予約語は、通信サーバが、その応答シグナリングメッセージを送信するために使用するためのプロトコルを選択するときに実行するための挙動を指定する。

かかる予約語は、使用するためのプロトコルが、シグナリングメッセージＭに関して使用されたプロトコルと同じであることを指定することが可能である。かかる予約語は、使用されるプロトコルがランダムに決定されなければならないことを指定することが可能である。かかる予約語は、どのプロトコルを使用するかを決定するための意味的基準を示すことも可能である。

図３、図４、および図５は、その指示によって指定された、サーバの様々な挙動の図を示す。これらの例では、説明をより明瞭にする目的で、クライアントＵＡＣおよびサーバＵＡＳは、１個のアドレスだけを有する。

この場合、インターフェースの概念は、ポートと組み合わされる。同様に、移送プロトコルに関する第２の指示は説明されない。しかし、これらの説明は、サーバＵＡＳが複数のアドレスを有する状況と、必要な変更を加えて、移送プロトコルとにも適用されるように、一般化されなければならない。

図３、図４、および図５のこれらの例のすべてにおいて、クライアントＵＡＣは、シグナリングメッセージＭをサーバＵＡＳのポート５０６０に送信する。そのＩＰアドレスは、１９２．１６８．０．１である。

図３に示された状況において、「Ｖｉａ」ヘッダは、それにより、以下であり得る：
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ１９２．１６８．０．１：５０６０；ｒｐａｔｈＰｏｒｔ＝ｉｎｃｏｍｉｎｇ；

この例において、「ｉｎｃｏｍｉｎｇ」という語は、サーバＵＡＳが、メッセージＭを受信したポートと同じポートから応答メッセージＲをクライアントＵＡＣに送信することをクライアントＵＡＣが要求していることを指定する予約語である。したがって、サーバＵＡＳは、この予約語を使用することによって、送信ポートを決定し、したがって、ポート５０６０から応答メッセージＲを送信する。

かかる挙動は、ＮＡＴ（「ネットワークアドレストランスレータ」）アドレス変換デバイスまたはファイアウォールがサーバＵＡＳとクライアントＵＡＣとの間に配置された場合に要求され得る。これらのデバイスは、トラヒックが決定されたトランザクションに対応するときだけ、前記トラヒックが送信されることを可能にする。トランザクションが受け入れられると、対応するトラヒックはデバイスを横断することが可能であるが、任意のその他のメッセージは拒否される。したがって、応答シグナリングメッセージＲが、アドレス変換デバイスによって、シグナリングメッセージＭと同じトランザクションに属しているとみなされることが重要である。したがって、同じ経路、すなわち、同じアドレスおよび同じポートを利用することが必須である。

したがって、「ｉｎｃｏｍｉｎｇ」という予約語は、応答メッセージが、確かに同じ経路を利用すること、したがって、これらのタイプのデバイスを横断することを可能にすることを確実にするために使用される。

図４に示される状況において、「Ｖｉａ」ヘッダは、それにより、以下であり得る：
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ１９２．１６８．０．１：５０６０；ｒｐａｔｈＰｏｒｔ＝ａｎｙ
「ａｎｙ」というこの予約語は、クライアントＵＡＣが、サーバＵＡＳが応答Ｒを送信するためのポートをランダムに決定することを要求することを指定する。この例では、サーバＵＡＳは、応答メッセージＲをクライアントＵＡＣのポート５０６０に送信するためのポート４５６７をランダムに選択する。

これは、クライアントＵＡＣが、ＩＰＳＥＣに関してセキュアな経路など、サーバによって予約された経路を使用することを事前に知っていることを可能にし得る。

その他のサーバ挙動モデルがクライアントによって要求される可能性があることも想像され得る。例えば、クライアントは、サーバによって使用されるポートが受信ポートと異なることを要求する可能性があることが想像され得る。

予約語は、使用するポートを決定するための意味的基準を示すことも可能である。この意味的基準は、例えば、特定のポートを要求する機構であり得る。

かかる機構は、ＲＦＣ２４０１によって定義されるようなＩＰｓｅｃ（「インターネットプロトコルセキュリティ」）であり得る。この例は、図５によって示される。１つの可能な「Ｖｉａ」ヘッダは、以下である：
Ｖｉａ：ＳＩＰ／２．０／ＵＤＰ１９２．１６８．０．１：５０６０；ｒｐａｔｈＰｏｒｔ＝ｉｐｓｅｃ；

予約語は「ＩＰＳＥＣ」であってよく、かかる予約語を備えるメッセージＭを受信しているサーバＵＡＳは、どのポートがこのＩＰｓｅｃ機構と関連付けられるかを決定し、ＩＰＳＥＣプロトコルの仕様によって求められるように、応答メッセージＲをこのポートから送信する。

本発明のこの例示的な実施形態は、今まで不十分に処理されてきた技術的な問題を解決する。知られている技法は、着信シグナリングメッセージを解析して、ＩＰＳＥＣ機構が求められるかどうかを決定するために、ＵＡＳサーバ内（したがって、潜在的に、ＳＩＰプロトコルを実装している任意のデバイス内）で追加のソフトウェア手段を実装することからなる。そうである場合、サーバＵＡＳは、ＩＰＳＥＣに関連するポートを使用する。

したがって、この解決法は、ＳＩＰシグナリグメッセージの処理に負担を生み出すソフトウェア手段が追加されることを必要とする。

この場合、本発明は、これらのソフトウェア手段を迂回し、デバイスがＩＰＳＥＣ機構を知っていることを単に要求することを可能にする。

その他の意味的基準に対応するその他の予約語を設定することも可能である。例えば、ある種の予約語は、（「ＶｏＩＰ」、「インスタントメッセージング」．．．のような）トラヒックのタイプに対応することが可能であり、それにより、データフローが分類されることを可能にする。かかる実施形態は、ポートだけを調べて、データフローに関して、制御を容易に実行すること、または統計を作成することを可能にし得る。例えば、問題になる可能性のあるフローが、対応するポートを閉鎖することによって中断されることが可能である。

同様に、第２の指示は、通信サーバによって使用されなければならない移送プロトコルを指定することを可能にする。

したがって、通信クライアントは、サーバがその応答シグナリングメッセージを送信するために使用するためのプロトコルに関するこの第２の指示をシグナリングメッセージ内に挿入するように設計されることが可能である。通信サーバは、同様に、着信シグナリングメッセージ内に含まれた第２の指示に基づいて、応答シグナリングメッセージを送信するために使用するためのプロトコルを決定するように設計されることが可能である。

この第２の指示は、「ｒｐａｔｈＴｒａｎｓｐｏｒｔ」などのキーワードによってもたらされることが可能であり、プロトコル識別子（ＴＣＰ、ＵＤＰなど）またはサーバが実行するための挙動を指定する予約語からなり得る。

これらの予約語は、第１の指示に関して使用された予約語と類似してよい。

別の予約語（例えば、「ｎｏｃｈａｎｇｅ」）は、応答メッセージが、初期のシグナリングメッセージに関して使用されたプロトコルと同じプロトコルによって伝送されることになる旨を示すことが可能である。特に、このプロトコルがＵＤＰである状況において、予約語「ｎｏｃｈａｎｇｅ」は、この応答メッセージの長さが、それを超えるとＳＩＰメッセージの送信が通常ＴＣＰにスイッチングするしきい値（通常、１３００バイト）を超える場合でも、ＵＤＰ移送プロトコルが応答メッセージに関して使用されることになる旨を示す。

したがって、第２の指示を使用することは、デフォルト機構を迂回して、特定の挙動を負わせることを可能にする。

本発明は、適切な形で、ＮＡＴアドレス変換デバイスの横断および／またはファイアウォールの横断の問題を解決することも可能にする。

図６は、これらの目的のための本発明の一実施形態を示す。

アドレス変換デバイスＮＡＴは、スペース、すなわち、私設ネットワークＰＲＩと、公共スペースＰＵＢとを定義する。

私設ネットワークＰＲＩ内に配置されたデバイスＡは、厳密に言えば、任意の公共アドレスを有さない。公共ネットワークと（または、その他の私設ネットワークとではあるが、公共ネットワークの中継を介して）通信するために、これらのデバイスは、ＮＡＴアドレス変換デバイスを介してそれらのメッセージを送信しなければならない。このデバイスは、それらのメッセージに公共アドレスを動的に割り当てて、プライベートアドレスが動的に割り当てられた公共アドレスに置き換えられるように、発信メッセージに必要な変更を行う。

ＮＡＴデバイスは、公共ネットワークから到着しているメッセージを経路指定することが可能であるように、プライベートアドレスと公共アドレスとの間の結合を保存する。プライベートアドレスは、知られておらず、私設ネットワークＰＲＩの外部では意味を持たないため、これらのメッセージは、実際には、デバイスＡの公共アドレスだけを含む。逆に、ＮＡＴデバイスによって動的に割り当てられたこの公共アドレスは、メッセージが私設ネットワークＰＲＩ内に経路指定されることを可能にしない。ＮＡＴデバイスは、アドレス変換を逆に実行して、公共アドレスをプライベートアドレスに置き換えるために、保存された結合を使用する。

しかし、これらの結合は一時値を有する。

ＴＣＰ（「トランスポート制御プロトコル」）プロトコル内で、最後のＴＣＰ接続メッセージから一定の期間が経過すると、この結合は、ＮＡＴデバイスによって削除されることになる。

さらに、期限切れ時間を新たにする以外に理由もなく、メッセージを送信することによって、ＴＣＰ接続を人工的に維持することは有害な可能性がある。実際には、ＴＣＰ接続は、当事者のそれぞれの中にリソースを必要とし、デバイスが大量のＴＣＰ接続を管理しなければならなくなると、配備問題が生じる。

一般に、ＮＡＴアドレス変換デバイスは、公共領域ＰＵＢ内に配置されたデバイスＢから来るＴＣＰ接続を禁じるファイアウォールも実装する。このデバイスＢは、ＴＣＰプロトコルによって伝送されるメッセージを私設領域ＰＲＩ内に配置されたデバイスＡに送信するが、デバイスＡの主導で作成された既存のＴＣＰ接続を介してだけ送信する。

ＳＩＰプロトコルは、前述のように、様々なプロトコルによって伝送されることが可能であるが、ＴＣＰプロトコルは、ある種のアプリケーションおよびある種の状況に関して、ＴＣＰプロトコルを不可欠にする様々な利点を有する。

したがって、デバイスＢが、事前に存在している任意のＴＣＰ接続なしに、ＴＣＰプロトコルによって伝送されるＳＩＰシグナリングメッセージをデバイスＡに送信することを望むとき、問題が生じる。

例えば、これは、デバイスＢが「ＳＩＰプロキシ」中継シグナリング要素であるときに当てはまる。例えば、これはＰ−ＣＳＣＦ（「プロキシ−呼セッション制御機能」）要素であり得る。

この要素は、デバイスＡ向けのインビテーションメッセージを受信する。このインビテーションメッセージは、通常、その目的がインビテーションメッセージの送信側との通信セッションを受け入れるようデバイスに要求するＳＩＰ「Ｉｎｖｉｔｅ」メッセージ（図示せず）である。このＴＣＰ要求メッセージは、ＴＣＰプロトコルによって伝送され、このＴＣＰプロトコルを使用して、被呼者に送信されなければならないと推定する。

その場合、デバイスＢは、デバイスＡ向けのシグナリングメッセージＭを送信する。

ＮＡＴアドレス変換デバイスを横断するために、デバイスＢは、接続を必要としないＵＤＰ（「ユーザデータグラムプロトコル≫）プロトコルを使用して、このメッセージＭを送信する。

デバイスＢは、このメッセージ内に、デバイスＡが移送プロトコルとしてＴＣＰプロトコルを使用して、応答を送信しなければならないことを指定する指示を挿入する。本発明の一実施形態では、デバイスＢは、「ｒｐａｔｈＴｒａｎｓｐｏｒｔ＝ＴＣＰ」パラメータを「Ｖｉａ」ヘッダ内に挿入する。

ＵＡＳサーバとして機能しているデバイスＢは、応答メッセージＲをＵＡＣクライアントとして機能しているデバイスＡに送信する。

この応答メッセージＲは、２個のデバイスの間にＴＣＰ接続を生み出す。

応答メッセージＲが受信されると、次いで、デバイスＢは、先に受信された要求メッセージＭＩを送信する。

応答メッセージＲによって接続がすでに開かれているため、この要求メッセージＭＩは、ＴＣＰプロトコルを使用して送信されることが可能である。

本発明は、したがって、「Ｖｉａ」ヘッダは元のメッセージプロトコルと、応答に関して要求されたプロトコルの両方を指定するため、「Ｖｉａ」ヘッダが可能にしなかった、元のメッセージに関して使用されたプロトコルとは別の移送プロトコルを使用して、応答を要求することを可能にする。

したがって、本発明は、ＮＡＴの背後に配置されたデバイスに対して、ＴＣＰを使用して、ＳＩＰ要求メッセージを送信する問題を解決することを可能にする。

Claims (25)

1. 通信サーバ（Ｓ）の第１のインターフェースに、ＳＩＰプロトコルに従ってシグナリングメッセージ（Ｍ）を送信するための少なくとも１つの送信インターフェースを備える通信クライアント（Ｃ）であって、前記クライアントおよび前記サーバが、通信ネットワーク（Ｎ）を経由して互いに接続されており、その応答シグナリングメッセージ（Ｒ）を送信するために使用される前記サーバの第２のインターフェースに関する指示をシグナリングメッセージ内に挿入するように設計されることを特徴とする、通信クライアント。
2. 前記指示が、前記通信サーバがその応答シグナリングメッセージを送信するために使用するアドレスを含む、請求項１に記載の通信クライアント。
3. 前記指示が、前記通信サーバが、その応答シグナリングメッセージを送信するためにどのアドレスを使用するかを選択するために実行するための挙動を指定する予約語を含む、請求項１に記載の通信クライアント。
4. 前記予約語が、少なくとも、
   − 前記使用されるアドレスが、前記第１のインターフェースのアドレスと同じであることを指定する予約語と、
   − 前記使用するアドレスが、ランダムに決定されなければならないことを指定する予約語と、
   − 前記使用するアドレスを決定するための意味的基準を示す予約語と
   を含むグループから選択される、請求項３に記載の通信クライアント。
5. 前記指示が、前記通信サーバがその応答シグナリングメッセージを送信するために使用するポート番号を含む、請求項１から４のいずれか一項に記載の通信クライアント。
6. 前記指示が、前記通信サーバがその応答シグナリングメッセージを送信するためにどのポート番号を使用するかを選択するために実行するための挙動を指定する予約語を含む、請求項５に記載の通信クライアント。
7. 前記予約語が、少なくとも、
   − 前記使用されるポート番号が、第１のインターフェースのポート番号と同じであることを指定する予約語と、
   − 前記使用するポート番号が、ランダムに決定されなければならないことを指定する予約語と、
   − 前記使用するポート番号を決定するための意味的基準を示す予約語と
   を含むグループから選択される、請求項６に記載の通信クライアント。
8. その応答シグナリングメッセージを送信するために前記通信サーバによって使用されるためのプロトコルに関する第２の指示をシグナリングメッセージ内に挿入するように設計された、請求項１から７のいずれか一項に記載の通信クライアント。
9. 前記指示が「Ｖｉａ」ヘッダ内に挿入される、請求項１から８のいずれか一項に記載の通信クライアント。
10. 通信ネットワーク（Ｎ_１）からの着信シグナリングメッセージ（Ｍ）を受信するための少なくとも１つのインターフェースと、応答シグナリングメッセージを送信するための第２のインターフェースとを備えた通信サーバ（Ｓ）であって、前記着信シグナリングメッセージ（Ｍ）内に含まれた指示に基づいて、前記第２のインターフェースを決定するようにさらに設計されることを特徴とする、通信サーバ（Ｓ）。
11. 前記指示が、前記第２のインターフェースに対応するアドレスを含む、請求項１０に記載の通信サーバ。
12. 前記指示が、前記第２のインターフェースに対応するアドレスを選択するために実行するための挙動を指定する予約語を含む、請求項１０に記載の通信サーバ。
13. 前記予約語が、少なくとも、
    − 前記アドレスが、前記第１のインターフェースのアドレスと同じであることを指定する予約語と、
    − 前記アドレスが、ランダムに決定されなければならないことを指定する予約語と、
    − 前記アドレスを決定するための意味的基準を示す予約語と
    を含むグループから選択される、請求項１２に記載の通信サーバ。
14. 前記指示が、前記第２のインターフェースに対応するポート番号を含む、請求項１０から１３のいずれか一項に記載の通信サーバ。
15. 前記指示が、前記第２のインターフェースに対応するポート番号を選択するために実行するための挙動を指定する予約語を含む、請求項１４に記載の通信サーバ。
16. 前記予約語が、少なくとも、
    − 前記ポート番号が、第１のインターフェースと同じであることを指定する予約語と、
    − 前記ポート番号が、ランダムに決定されなければならないことを指定する予約語と、
    − ポート番号を決定するための意味的基準を示す予約語と
    を含むグループから選択される、請求項１５に記載の通信サーバ。
17. 前記着信シグナリングメッセージ（Ｍ）内に含まれた第２の指示に基づいて、前記応答シグナリングメッセージを送信するために使用するためのプロトコルを決定するように設計された、請求項１０から１６のいずれか一項に記載の通信サーバ。
18. 前記指示が「Ｖｉａ」ヘッダ内に挿入される、請求項１０から１７のいずれか一項に記載の通信サーバ。
19. クライアントが、シグナリングメッセージをサーバに送信する第１のステップと、前記サーバが、応答メッセージをインターフェースから前記クライアントに送信する第２のステップとを備えた、通信ネットワークによって互いに接続された前記クライアントと前記サーバとの間でシグナリングメッセージを通信するための方法であって、前記クライアントが、前記第１のステップに先立って、前記シグナリングメッセージ内に指示を挿入し、前記サーバが、前記第２のステップに先立って、前記指示に基づいて、前記インターフェースを決定することを特徴とする、方法。
20. 請求項１から９のいずれか一項に記載の通信クライアントおよび／または請求項１０から１８のいずれか一項に記載の通信サーバを実装するように設計された通信端末。
21. 請求項２０に記載の少なくとも１個の端末を備える通信ネットワーク。
22. 前記通信サーバおよび／または前記通信クライアントが、ＩＭＳアーキテクチャの仕様に従って、ＣＳＣＦ機能を実装している要素である、請求項２１に記載の通信ネットワーク。
23. ＴＣＰプロトコルによって伝送された、アドレス変換デバイス（ＮＡＴ）の背後に配置された第２の通信デバイス（Ａ）向けの着信シグナリングメッセージ（ＭＩ）を受信するとき、ＵＤＰプロトコルを使用して、応答（Ｒ）を通信デバイスに送信するために使用される前記第２のデバイス（Ａ）向けのインターフェースに関する指示を含むシグナリングメッセージ（Ｍ）を前記第２のデバイスに送信し、前記応答メッセージを受信した後で、前記着信シグナリングメッセージ（ＭＩ）を送信するように設計され、前記指示が、前記応答がＴＣＰプロトコルを使用しなければならないことを指定する、通信デバイス（Ｂ）。
24. 前記第２のデバイスが、請求項１７または１８のいずれか一項によるサーバである、請求項２３に記載の通信デバイスを含む通信システム。
25. 前記指示が「Ｖｉａ」ヘッダ内に挿入される、請求項２４に記載の通信システム。

Images