JP5089701B2

JP5089701B2 - アドレス情報の冗長構成によるｓｉｐプロトコルシグナリングメッセージのｎａｔアドレス変換設備の通過

Info

Publication number: JP5089701B2
Application number: JP2009533773A
Authority: JP
Inventors: ヒリバーレン，ヴィンセント; レヴィ，トーマス
Original assignee: アルカテル−ルーセント
Priority date: 2006-10-26
Filing date: 2007-10-05
Publication date: 2012-12-05
Anticipated expiration: 2027-10-05
Also published as: EP1916825A1; CN101170556A; JP2010507949A; FR2908001A1; US20080101389A1; US8233484B2; FR2908001B1; WO2008049717A1

Description

本発明は通信ネットワークに関する。より詳しくは、本発明は「ＮＡＴ」などのアドレス変換装置を介したシグナリングメッセージの伝送の問題に関する。

現在の通信ネットワークはＨ．３２３、ＭＧＣＰ（Media Gateway Control Protocol）、又はＳＩＰ（セッション確立プロトコル：Session Initiation Protocol）及びＳＤＰ（セッション記述プロトコル：Session Description Protocol）などの信号プロトコルを使用して通信セッションの確立を可能にしている。

このＳＩＰプロトコルはＩＥＴＦ（インターネット技術タスクフォース：Internet Engineering Task Force）発表のＲＦＣ３２６１に定義されており、その２つの目的は以下のとおりである。
− ２人の当業者の交信を可能にする。
− ＳＤＰプロトコルを介して確立されるセッションの特性（ビデオビットレート、エンコーダの種類（使用するＣＯＤＥＣなど）についてのネゴシエーションを可能にする。

別の当業者に発信することを望む発呼側当業者は、発呼側当業者の個人アドレス、その端末（又は、より一般的に言えばクライアント）の物理アドレス、及び被呼側当業者の個人アドレスを含むシグナリングメッセージ（「Invite」）を、「プロキシ」として知られているシグナリング要素に送信することができる。シグナリング要素は、被呼側当業者の個人アドレスを対応する端末の物理アドレスと照合する手段（「レジストラ」）を有する。この照合によって、シグナリングメッセージが発呼側当業者にルーティングされることが可能になる。

その当業者は、発信を受け入れた場合、端末又はクライアントの物理アドレスを含む新しいシグナリングメッセージで応答する。このように、両方の端末が他方の当業者の物理アドレスを知っているので、両者はデータ（音声、ビデオなど）を伝送するためのＩＰ（Internet Protocol）接続を確立することができる。

しかし、ＲＦＣ１６３１、「The IP Network Address Translator」、及びＲＦＣ３０２２、「Traditional IP Network Address Translator (Traditional NAT)」で定義されている、ＮＡＴ（「ネットワークアドレス変換：Network Address Translation」）装置又はＮＡＰＴ（「ネットワークアドレスポート変換：Network Address Port Translation」）装置として知られているアドレス変換装置では、ある問題が生じる。これらの装置はサブネットワーク（典型的にはプライベートネットワーク）をパブリックインターネットネットワークに接続するためのものである。サブネットワークの装置（端末）はその物理ＩＰアドレスの妥当性がサブネットワークに限定されている。それらの装置（端末）がサブネットワークの外に位置する装置との通信をセットアップしようとするとき、アドレス変換装置はパブリックネットワークに対して有効な一時的なパブリックアドレスをそれらに割り当て、クライアントのプライベートアドレスとその一時的なパブリックアドレスとの間の関連を記憶する。

従って、ＮＡＴアドレス変換装置は、
− 発信メッセージ、言い換えればプライベートネットワークからパブリックネットワークに行くメッセージのＩＰヘッダ中で端末のプライベートアドレスをパブリックアドレスに変換することにより、及び
− 着信メッセージ、言い換えればパブリックネットワークからプライベートネットワークに行くメッセージのＩＰヘッダ中で端末のパブリックアドレスをプライベートアドレスに変換することにより、
プライベートネットワークとパブリックネットワークとの間で伝送されるメッセージをオンザフライで修正する。

従って、ＳＩＰ／ＳＤＰシグナリングメッセージ（若しくはＨ．３２３又は他のもの）がアドレス変換装置を通過するとき、問題が生じる。この問題は「ＮＡＴ通過（NAT traversal）」として知られている。

この問題は、とりわけ公開の百科事典「Wikipedia」のアドレス「http://en.wikipedia.org/wiki/NAT_traversal」に記載されており、ＩＥＴＦのＲＦＣ３２３５、表題「Network Address Translation(NAT)-Friendly Application Design Guidelines」に言及されている。

ＳＩＰ及びＳＤＰなどの信号プロトコルはアプリケーションプロトコルとみなされる。例えば、ＳＩＰ／ＳＤＰプロトコルはＴＣＰ又はＵＤＰプロトコルを介して伝送されることもあり、ＴＣＰ又はＵＤＰプロトコル自体はプロトコルスタックでＩＰの上に配置されている。従って、ＳＩＰメッセージは実際にはＴＣＰ又はＵＤＰメッセージ中にカプセル化された一連のパラメータであり、ＴＣＰ又はＵＤＰメッセージ自体がＩＰメッセージ中にカプセル化されている。

ＮＡＴアドレス変換装置はＩＰ層内にあるパラメータを編集するのみで、より上の層内にあるパラメータについては元のままにしておく。

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

その結果、シグナリングメッセージの受信者（被呼側クライアント）は発呼側クライアントのプライベートアドレスを知るだけである。しかし、これはプライベートネットワークでしか意味がないので通信セッションをセットアップすることはできない。

この問題はよく知られているので、それを解決するために数々の解決策が進められてきた。この問題を解決するために、２つの主要なアプローチ、即ち、発呼側クライアントベースのアプローチ、及び通信ネットワークのサーバ又は装置ベースのアプローチがある。

最初のカテゴリには、ＲＦＣ３４８９に記載されているＳＴＵＮ（「Simple Traversal of UDP through NAT」）機構が含まれる。この機構は、クライアント（又は端末）がそのパブリックアドレスを得ることを可能にする。従って、メッセージがパブリックネットワークへ放出される前に、発呼側クライアントはこのパブリックネットワーク中に位置するＳＴＵＮサーバに要求を送信する。このサーバは、クライアントがそこで「見える」アドレス（及びポート）、言い換えればそのパブリックアドレスを含むメッセージで応答する。

従ってクライアントは、このパブリックアドレスを使用して、ＳＤＰプロトコルを介して応答をそこで受信したいと望むアドレスを示すことができる。

しかし多くのＮＡＴが「対称的」であると言われ、１つのパブリックアドレスを１対の当業者に関連付けるので、この解決策は重要な限界がある。従って、ＮＡＴによりクライアントに割り当てられるパブリックアドレスは、ＳＴＵＮサーバとの通信と、セットアップされる他方の当業者とのセッションとで異なることがある。この場合、クライアントと他方の当業者との間の通信は確立することができない。

同じ原則に基づき、この状況を改善するために、ＴＵＲＮ（「Traversal Using Relay NAT」）機構などの他の提案がなされてきた。ＴＵＲＮ機構は「draft-rosenberg-midcom-turn-09.txt」文書、２００６年３月発表、ＩＥＴＦサイトに記載されている。

しかし、ＳＴＵＮ機構又はＴＵＲＮ機構のどちらもＳＩＰプロトコルには適していない。

従って、新しい機構であるＩＣＥ（「双方向接続性確立：Interactive Connectivity Establishment」）が、ＳＩＰシグナリングメッセージを通過に適したものにするために提案されている。ＩＣＥはＳＴＵＮ及びＴＵＲＮ機構に基づき、それらを手直ししたものである。ＩＣＥ機構も、ＩＥＴＦサイト、２００６年６月発表、「draft-ietf-mmusic-ice-09.txt」文書、表題「Interactive Connectivity Establishment: A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols」に記載されている。

解決策の第２のカテゴリは通信ネットワーク内の装置を利用するものである。初期の解決策ではネットワーク内にサーバ（例えば、ＳＴＵＮサーバ）を実装したが、クライアントがイニシアチブをもっていたことに留意されたい。しかし、この第２の系統の解決策では、ＮＡＴ通過解決策のイニシアチブも実装もネットワーク装置の責任である。

例えば、この系統に属する第１の解決策はアプリケーションゲートウェイをＮＡＴアドレス変換装置に結合するものである。この機構は「Application Layer Gateway」又は「Application-Level Gateway」の略であるＡＬＧとして知られており、ＲＦＣ２６６３の段落２．９、表題「IP Network Address Translator(NAT) Terminology and Considerations」、１９９９年８月発表に定義されている。

このゲートウェイ（又はこのようなゲートウェイと同じ機能を有するＮＡＴ装置）は、メッセージによって使用されるアプリケーションプロトコルを理解する手段を有する。具体的には、それは、シグナリングメッセージの内容を理解することができ、当業者が自分のパブリックアドレスを交換し、自分のプライベートアドレスは交換しないように、ＳＤＰメッセージに含まれる物理アドレスを変換することができ、それにより、通信セッションをセットアップすることを可能にする。

この解決策の１つの変形は、シグナリングメッセージのパスに沿って配置されるセッションコントローラ又はＳＢＣ（「Session Border Controller」）を使用することからなる。このタイプの製品は、両方のネットワーク間での通信セッション及びシグナリングメッセージの伝送を制御することを可能にする。より正確には、ＳＢＣは、Ｍｅｇａｃｏなどのプロトコルを介してメディアを伝送する手段（「メディアプロキシ」）を制御することができるＳＩＰ「プロキシ」シグナリング要素の役割を果たすことができ、その結果、通信セッションを当業者間で適切に確立することができる。

これらの大きなカテゴリのそれぞれにさらなる解決策が存在し、それらのどれも他より決定的に優越してはいない。

従って、単一の通信ネットワークで、複数の解決策を同時に実装することができる。通信クライアントは、先験的に、それが関連付けられているネットワークが通過の解決策を実装しているかどうかを知らない。その場合、ネットワークがＡＬＧ又はＳＢＣタイプの解決策を実装するのに対し、通信クライアントはＩＣＥタイプの解決策を実装することもある。

２つの解決策を配備することは冗長であり、リソースの損失をもたらすが、さらにそれらの解決策が相互に破壊的になり、通信ネットワークの間違った動作をもたらすことがある。即ち、ＳＩＰ／ＳＤＰシグナリングメッセージに含まれるアドレスが、ＡＬＧ若しくはＳＢＣ装置により、不適切に、又は変更が必要でないときに、変更されることがある。結局、通信セッションをセットアップすることができない。

この問題は今までに生じていないようである。

提案され得る１つの解決策は、ＳＩＰクライアント（ＩＣＥ、ＳＴＵＮ、ＴＵＲＮなど）が、クライアント自身がＳＢＣ又はＡＬＧゲートウェイに接続されていることを知っているとき、このクライアントによって実装される機構を手動でディスエーブルすることである。

しかし、このような処理は実装するには複雑である。クライアントが、それがＡＬＧゲートウェイ又はＳＢＣに接続されていることを知るには、クライアントがそのアクセスプロバイダのネットワークのトポロジーを知っていなければならない。加えて、クライアントが新しいネットワークに接続されるたびにその構成が手動で変更されなければならない。

さらに、このアプローチは、ＡＬＧゲートウェイ又はＳＢＣベースの解決策が配備されると、それがクライアントベースの解決策よりも構築の点で好まれるので最適ではない。しかし、この後者の解決策は、クライアントが通信セッションのセットアップを制御することを可能にし、ＳＢＣ又はＡＬＧ解決策のようなメディアリレーを実装しないので、一般に最適なのはこの後者の解決策である。

ＩＥＴＦ（インターネット技術タスクフォース：Internet Engineering Task Force）発表のＲＦＣ３２６１ＲＦＣ１６３１、「The IP Network Address Translator」ＲＦＣ３０２２、「Traditional IP Network Address Translator (Traditional NAT)」公開の百科事典「Wikipedia」のアドレス「http://en.wikipedia.org/wiki/NAT_traversal」ＩＥＴＦのＲＦＣ３２３５、表題「Network Address Translation(NAT)-Friendly Application Design Guidelines」ＲＦＣ３４８９「draft-rosenberg-midcom-turn-09.txt」文書、２００６年３月発表、ＩＥＴＦサイトＩＥＴＦサイト、２００６年６月発表、「draft-ietf-mmusic-ice-09.txt」文書、表題「Interactive Connectivity Establishment:A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols」ＲＦＣ２６６３の段落２．９、表題「IP Network Address Translator(NAT) Terminology and Considerations」、１９９９年８月発表ＩＥＴＦのＲＦＣ２３２７、表題「SDP:Session Description Protocol」ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ３５４８

本発明の狙いは、クライアントベースの解決策と通信ネットワーク（ＡＬＧ、ＳＢＣなど）ベースの解決策の最適な共存のための方法を提案することにより、これらの欠点を克服することである。

このことを行うために、本発明の第１の目的は、少なくとも１つのアドレス変換装置（ＮＡＴ、ＮＡＰＴ、ＳＢＣ、．．．）を含む通信ネットワークを介して、発呼側通信クライアントと被呼側通信クライアントとの間の通信セッションをセットアップする方法である。

それ自体公知のように、この方法は、シグナリングメッセージを伝送する段階、アドレス変換装置を通過する段階、及び通信セッションをセットアップするために通信クライアントの物理アドレスの交換を可能にする段階を含む。

本発明による方法は、革新的であり、少なくとも１つのクライアントが、
− 第１の位置にある物理アドレス、及び
− 異なる第２の位置にあり、この同じ物理アドレスを含むエンコード済み情報
を含む、少なくとも１つのシグナリングメッセージを送信することを特徴とする。

物理アドレスを含む情報は、エンコードされているので、アドレス変換装置（ＮＡＴ、ＮＡＰＴ、ＳＢＣなど）によって変更できない。この場合、シグナリングメッセージの受信側通信クライアントは、送信側クライアントの未変更の物理アドレスを有する。変更されていないことが保証されているこのアドレスを使用することが好ましいことがある。

さらに、エンコードされていないアドレスを削除せずに、エンコードされたアドレスが冗長的に追加されることにより、ＩＥＴＦ及び様々なアドレス変換装置の現在の仕様に適合しているままであることが可能になる。

この物理アドレスは、前述の通信クライアントによって実装されるアドレス変換装置通過解決策を介して取得することができる。この解決策は、例えば、ＳＴＵＮ機構でよい。

従って、本発明は、ＩＣＥ又はＳＴＵＮなどのアドレス変換装置通過機構を使用するアーキテクチャが直面する技術的問題を解決する。

本発明の一変形形態によれば、シグナリングメッセージはまた、
− 第１のポート位置にあるポート番号、及び
− 異なるポートの第２の位置にあり、前記ポート番号を含むエンコードされた情報の１つ又は複数の項目
も含む。

本発明の諸実装形態によれば、これらの異なる位置は、ＩＥＴＦのＲＦＣ２３２７によって定義されるＳＤＰプロトコルのフィールドである。第２の位置（アドレス用、及び必要ならポート番号用）は、このＳＤＰプロトコルの属性フィールド、言い換えればＲＦＣ２３２７の段落６で定義されている「ａ」フィールドである。

本発明はまた、少なくとも１つの他の通信クライアントとの通信セッションをセットアップするためのシグナリングメッセージを送信する手段、及びアドレス変換装置を通過する手段を有する通信クライアントを目的とする。

このクライアントは、シグナリングメッセージを送信する前にこのメッセージ内に、これらのアドレス変換装置通過手段によって取得される物理アドレスを含むエンコードされた情報を付加する手段を有することを特徴とする。

これらの手段はポート番号を含むエンコードされた情報を付加するのに適したものでもよい。

このエンコードされた情報は、ＳＩＰプロトコルに準拠しているシグナリングメッセージの、ＳＤＰプロトコルに準拠している部分のフィールド、特に属性フィールド「ａ」に付加されてよい。

本発明はまた、先に説明した通信クライアントを実装している通信ネットワーク、及び前述の方法を実装しているソフトウェア製品を提供することも目的とする。

本発明は添付の図とともに以下に記載する実装形態の説明からより明らかになるであろう。

本発明を実装できる通信ネットワークを示す図である。

図１のこの例では、通信ネットワークは、２つのアドレス変換装置ＮＡＴ_１及びＮＡＴ_２によって接続された３つのネットワークＳＮ_１、ＳＮ_２及びＳＮから構成される。これは各通信クライアントＣ_１及びＣ_２がそれぞれプライベートサブネットワークＳＮ_１及びＳＮ_２に接続されている標準的なシナリオである。これらのプライベートサブネットワークのそれぞれは、アドレス変換装置ＮＡＴ_１及びＮＡＴ_２をそれぞれ使用して、パブリックネットワークＳＮに接続されている。

しかし、他のシナリオも可能である。例えば、単一のＮＡＴアドレス変換装置が、ある会社の２人の当業者に属する２つのプライベートサブネットワークの間に配備されてもよい。２つのクライアントの一方がＮＡＴを使用せずにプライベートサブネットワークに接続されている状況も考えることができる。この場合、他方のプライベートサブネットワークとパブリックサブネットワークとの間で、１つのＮＡＴアドレス変換装置だけが使用される。

通信ネットワーク（主にＳＮパブリックネットワーク）は少なくとも１つの装置を含む。これらの装置は、ルータなどのＩＰ伝送ノードでよいか、サーバ、シグナリング要素、ＳＩＰプロキシ、コールサーバなどでもよい。図１には、わかりやすいように、ＮＡＴ_１及びＮＡＴ_２アドレス変換装置のみがコールサーバＣＳとともに示されている。

このコールサーバＣＳは以下では最も一般的な意味でみなされ、従って「ＳＩＰプロキシ」シグナリング要素、ソフトスイッチ、コールコントローラ、ＩＭＳ（IP Multimedia Subsystem）アーキテクチャにおけるＣＳＣＦ（呼セッション制御機能：Call Session Control Function）などをカバーする。

通信セッションのセットアップは専門家によく知られている、現在の最新技術の一部をなす。図では、それは２つの通信クライアントＣ_１とＣ_２の間でシグナリングメッセージを伝送する段階からなる。この信号フローｆｓはパブリックネットワークＳＮに位置するコールサーバＣＳによって送信される。前述のようにシグナリングメッセージのこうした伝送により、通信クライアントＣ_１及びＣ_２の物理アドレスの交換が可能になり、それにより２つの通信クライアントの間で通信セッションｆｍをセットアップすることが可能になる。次いで、メディアフロー（音声、データ、ビデオなど）ｆｍは、２つのクライアントの間でこれらの交換された物理アドレスを使用して送信することができる。

シグナリングメッセージはアドレス変換装置ＮＡＴ_１及びＮＡＴ_２を通過する。従って、２つの通信クライアントＣ_１及びＣ_２はそれぞれ、それが結合されているアドレス変換装置によって割り当てられ、そのプライベート物理アドレスとは異なるパブリック物理アドレスを（セッション中に）有する。

通信セッションｆｍの確立を可能にするために、２つのクライアントはそれらのパブリック物理アドレス（それらのプライベート物理アドレスではない）を交換しなければならない。

図１の例で、発呼側通信クライアントＣ_１はアドレス変換装置通過解決策（「ＮＡＴ通過：NAT Traversal」）を実装しているものと想定する。「実装」という用語は、クライアントがアドレス変換装置を通過する手段を有することだけでなく、これらの手段がイネーブルされることをも意味する。実際、これらの手段が様々な理由から（失敗する、ユーザがこれらの手段が性能不足であると考えたため手動で構成から外すなどで）ディスエーブルされる状況を想像することができる。

これらの通過手段は、既存の及び将来の最新技術で利用可能で、通信クライアントベースの様々な解決策に従うものでよい。前述のＳＴＵＮ、ＴＵＲＮ又はＩＣＥと同じ機構をここであげることができる。

シグナリングメッセージを送信する前に、発呼側通信クライアントＣ_１はこのメッセージに
− その物理アドレス、特にアドレス変換装置通過解決策を介して取得されたものでよい、そのパブリック物理アドレス、及び
− この物理アドレスを含むエンコードされた情報
を付加する。

従って、本発明の１つの特徴は、受信側当業者向けのシグナリングメッセージの物理アドレスに対応する、エンコードされた冗長な情報を付加することにある。

ＳＩＰプロトコルを使用する実装という状況では、このシグナリングメッセージは通常「INVITE」メッセージである。この「INVITE」シグナリングメッセージは、ＳＤＰプロトコルに準拠し、通信セッションの記述を実装することを可能にする部分を含む。ＳＤＰプロトコルはＩＥＴＦのＲＦＣ２３２７、表題「ＳＤＰ：Session Description Protocol」に記載されている。

通信クライアントＣ_１は、このＳＤＰ部分に（あるいは、複数のＳＤＰ部分を含むシグナリングメッセージの場合はＳＤＰ部分のうちの別の部分に）そのパブリック物理アドレスと、必要ならばポート番号を、この目的のためにプロトコルで意図されている位置に付加する。

ＳＤＰプロトコルでは実際、それぞれがサブフィールドを含むことができるいくつかのフィールドを計画している。これらのフィールドは、以下の２つのカテゴリに分けることができる。

実装されるセッションの記述を目的とするフィールドは、以下のとおりである。
ｖプロトコルのバージョン
ｏセッションの所有者／作成者及び識別
ｓセッション名称
ｉセッション情報
ｕ記述のＵＲＩ
ｅＵＲＬ（ｅメール）
ｐ電話番号
ｃ接続情報
ｂ帯域幅情報
ｔセッションの有効性の継続期間
ｒ繰返し周波数
ｚ時間帯調整
ｋ暗号キー
ａ属性

第２のフィールドカテゴリにはメディアの記述に関するフィールドが含まれ、それらは以下のとおりである。
ｍメディアの名称及び移送アドレス
ｉメディアのタイトル
ｃ接続情報
ｂ帯域幅情報
ｋ暗号キー
ａ属性

ＳＤＰプロトコルの仕様によれば、これらのフィールドは、通信クライアントのプロトコルインターフェースによる読取りがより速くより効率的になるように配列される。

あるフィールドは通信クライアントが物理アドレスを付加してもよい、又は付加すべき位置を含む。他の位置は複数のポートを含むように計画される。

従って、「ｏ」フィールドは、ＲＦＣ２３２７に明記されているように次のサブフィールド：＜ユーザ名＞、＜セッションＩＤ＞、＜バージョン＞、＜ネットワークタイプ＞、＜アドレスタイプ＞、＜アドレス＞を含む。

＜アドレス＞サブフィールドは通信クライアントＣ_１の物理アドレスを含む。通信クライアントＣ_１が利用可能な複数の物理アドレスを有する場合、対象の物理アドレスは通信クライアントＣ_１が通信セッションをそこでセットアップしたいと望む物理アドレスである。これは、好ましくは、そのパブリック物理アドレス、言い換えれば、知られておりＳＮ通信ネットワーク内で使用できるパブリック物理アドレスであるべきである。

「ｍ」フィールドは、サブフィールド＜メディア＞、＜ポート＞、＜移送＞、＜ｆｍｔｌｉｓｔ＞を含んでよい。従って、第２のサブフィールドはポート番号を含んでよい。

「ｃ」フィールドは、サブフィールド＜ネットワークタイプ＞、＜アドレスタイプ＞、＜接続アドレス＞を含んでよい。

属性フィールド「ａ」は＜属性＞及び＜値＞の２つのサブフィールドを含み、オープンフィールドである。これは物理アドレスも含んでよい。

本発明によれば、通信クライアントは第１の位置とは異なる第２の位置に物理アドレスを含むエンコードされた情報を付加する。言い換えれば、物理アドレスを、第１の位置（エンコードされていない形式で）、及び第２の位置（エンコードされた形式で）の両方に含んでよい。

この第２の位置は属性フィールド「ａ」でよい。これは、選択された任意の、しかし通信セッションにおける当業者となる可能性のある全通信クライアントに知られている属性名を含んでよい。次の例では、この属性名は「ｒｄｄ」である。

ＳＤＰプロトコルのフィールドの順序が指定されていることによって生じる問題を念頭において、第２の位置を次に可能な位置に付加してよい。物理アドレス又はポート番号が「ｏ」、「ｃ」又は「ｍ」フィールドである第１の位置に含まれる場合、第２の位置は後続の最初の「ａ」フィールドである。第１の位置が「ａ」フィールドの場合、第２の位置は、すぐ次の「ａ」フィールドである。

これらの規則は、シグナリングメッセージを受信する通信クライアントＣ_２のプロトコルインターフェースの設計を容易にするために使用される。

物理アドレス及びポート番号のこの冗長な付加は、シグナリングメッセージに含まれる全ての物理アドレス及び全てのポート番号に対して行っても、それらの一部分だけに対して行ってもよい。

本発明の一実施形態によれば、アドレス及びポート番号は個別にエンコードされる。フィールド（言い換えれば「行」）が物理アドレスを含むときは、物理アドレスのみがエンコードされ、このフィールドに対応する第２の位置に付加される。

別の実施形態によれば、フィールドの全体がエンコードされ、第２の位置に付加される。このように、単一のフィールドがポート番号及び物理アドレスの両方を含む場合、エンコードは１回だけ要求され、情報の全てを単一の第２の位置（言い換えれば単一の「ａ」フィールド）に容易に付加することができる。

言い換えれば、エンコード済み情報は（エンコード済み）物理アドレス又は（エンコード済み）ポート番号のみを含んでもよく、他の情報を含んでもよい（特にポート番号及び物理アドレスの両方を含んでよい）。

本発明のこの第２の実施形態によるＳＩＰシグナリングメッセージのＳＤＰ部分の例は、以下のとおりである。
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
i=A Seminar on the session description protocol
c=IN IP4 224.2.17.12/127
a=rdd:bz1taGFuZGxleSAyODkwODQ0NTI2IDI4OTA4NDI4MDcgSU4gSVA0IDEyNi4xNi42NC40
a=rdd:Yz1JTiBJUDQgMjl0LjluMTcuMTIvMTI3
m=audio 49170 RTP/AVP 0
a=rdd:bT1hdWRpbyA0OTE3MCBSVFAvQVZQIDA=
a=rtcp:53020
a=rdd:YT1ydGNwOjUzMDIw
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
m=application 32416 udp wb
a=rdd:bT1hcHBsaWNhdGlvbiAzMjQxNiB1ZHAgd2l=

前述の規則によれば、最初の「ａ」フィールドは、「ｏ」フィールド中に含まれるアドレスに対する第２の位置である。第２の「ａ」フィールドは、「ｃ」フィールド中に含まれる物理アドレスに対する第２の位置である。第３の「ａ」フィールドは、第１の「ｍ」フィールド中に含まれるポート番号（４９１７０）に対する第２の位置である。第５の「ａ」フィールドは、第４の「ａ」フィールド中に含まれるポート番号（５３０２０）に対する第２の位置である。最後に、最後の「ａ」フィールドは、直前の「ｍ」フィールド中に含まれるポート番号（３２４１６）に対する第２の位置である。

しかし、これらの全てのフィールドで、エンコードされるのは物理アドレス又はポート番号を含む行全体である。言い換えれば、エンコードされるのは物理アドレス及び／又はポート番号を含むフィールドであり、物理アドレス又はポート番号は個別にエンコードされない。

従って、エンコード済み情報の「rdd:bz1taGFuZGxleSAyODkwODQ0NTI2IDI4OTA4NDI4MDcgSU4gSVA0IDEyNi4xNi42NC40」は、物理アドレス「１２６．１６．６４．４」だけでなく、フィールド「o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4」中に存在する他のデータも含む。

この例では、物理アドレス及びポート番号はbase 64でエンコードされる。このタイプのエンコードは、例えばＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ３５４８に記載されているが、別の変形形態も存在する。

しかし、全てのタイプのエンコードが可能である。とはいえ、様々な部分が、使用されるエンコードのタイプ（及び必要ならばそのキー）に関する知識を共有すること、及びそれらがポート番号及び／又は物理アドレスであることをネットワーク装置（ＮＡＰＴ、ＮＡＴ、ＳＢＣなど）が認識できないことが必要である。

ある場合では、より高度な暗号化技術を実装することが重要になることもある。

シグナリングメッセージ内で、エンコードのタイプ、及び必要ならばキーに関係する情報、又は受信側のＣ_２通信クライアントによるデコードを可能にする同じ性質の他の情報を搬送することを計画することもできる。

物理アドレス及びポート番号のみがエンコードされる実施形態では、これらは通信ネットワーク装置をだますために簡単に変更されてもよい。

物理ＩＰアドレスについて、単にドットをスラッシュに変換する場合もあり得る。従って、アドレス「１２６．１６．６４．４」は、「１２６／１６／６４／４」となる。物理アドレスの各数字を対応するランクの文字に変換することも可能である。従って、この例のアドレスは「ａｂｆ．ａｆ．ｆｄ．ｄ」となる。

シグナリングメッセージは、一度送信されると、アドレス変換装置ＮＡＴ_１に伝送され、次いでパブリックネットワークＳＮの他の装置にも伝送される。必要ならば、アドレス変換装置ＮＡＴ_１に到達する前に、シグナリングメッセージはプライベートサブネットワークＳＮ_１の装置も通過していてよい。

これらの装置のいくつかは、アドレス変換装置を通過する手段を有していてよい。これらの手段は前述の解決策に従うものでよい。これはＡＬＧゲートウェイ（Application Layer Gateway）又はＳＢＣサーバ（Session Border Controller）でよい。

従って、これらの装置はＳＩＰシグナリングメッセージのＳＤＰ部分に含まれる物理アドレス及びポート番号を変更することができる。従って、「ｍ」、「ｃ」及び「ｏ」フィールドに含まれるアドレスは通信クライアントＣ_２に到着する前に変更されることがある。ある「ａ」フィールドが、例の第４の「ａ」フィールドの場合のように、エンコードされていないポート番号又は物理アドレスを含むときは、その「ａ」フィールドも変更されることがある。

しかし、「ａ」フィールドに含まれるポート番号及び物理アドレスはエンコードされているので、「ａ」フィールドに含まれるポート番号及び物理アドレスはこれらの装置では変更することができない。それらが通信クライアントＣ_２に変更されずに到着し、このクライアントが、変更された可能性のある他方のフィールドに含まれる物理アドレス及びポート番号の代わりにそれらを使用できることが好ましい。

同様に、他のシグナリングメッセージもまた、それらが通信クライアントＣ_１によって送信されたメッセージであれ、又は通信クライアントＣ_２によって送信されたメッセージであれ、エンコード済み物理アドレス及びポート番号を含んでいてよい。従って、信号フローｆｓ全体が上述のことに従っていてよい。

物理アドレス及びポート番号をこのように構成することによって、それらが変更されていないことが保証され、２つの通信クライアントが通信セッション、及び１つ（又は複数）のメディアフローｆｍをセットアップすることができる。

Claims

少なくとも１つのアドレス変換装置（ＮＡＴ_１、ＮＡＴ_２）を含む通信ネットワーク（ＳＮ_１、ＳＮ、ＳＮ_２）を介して、発呼側通信クライアント（Ｃ_１）と被呼側通信クライアント（Ｃ_２）との間の通信セッション（ｆｍ）をセットアップする方法であって、
シグナリングメッセージ（ｆｓ）を伝送する段階、前記少なくとも１つのアドレス変換装置を通過する段階、及び前記通信セッションをセットアップするために前記通信クライアントのパブリック物理アドレスの交換を可能にする段階からなり、
少なくとも１つの通信クライアントが、第１の位置にパブリック物理アドレスを含む少なくとも１つのシグナリングメッセージを送信し、前記パブリック物理アドレスはアドレス変換装置通過手段によって事前に取得されており、
前記通信クライアントが、前記シグナリングメッセージを伝送する前に前記パブリック物理アドレスに対応する情報をエンコードし、異なる第２の位置に前記パブリック物理アドレスに対応する冗長な前記エンコード済み情報を付加することを特徴とする方法。
請求項１記載の方法において、前記パブリック物理アドレスが、前記少なくとも１つの通信クライアントによって実装されているアドレス変換装置通過解決策を介して取得される方法。
請求項１乃至２いずれか１項に記載の方法において、前記少なくとも１つのシグナリングメッセージがまた、１以上のポート番号を第１のポート位置に、前記ポート番号を含む１以上のエンコード済み情報項目を異なる第２のポート位置に含む方法。
請求項１乃至３いずれか１項に記載の方法において、前記位置が前記シグナリングメッセージのＳＤＰプロトコルに準拠している部分のフィールドであり、前記シグナリングメッセージがＳＩＰプロトコルに準拠している方法。
前記第２の位置が前記ＳＤＰプロトコルの属性フィールドである請求項４記載の方法。
少なくとも１つの他の通信クライアント（Ｃ_２）との通信セッション（ｆｍ）をセットアップするためにシグナリングメッセージ（ｆｓ）を送信する手段、及びアドレス変換装置を通過する手段を有する通信クライアント（Ｃ_１）であって、
前記シグナリングメッセージが、第１の位置に前記通信クライアントのパブリック物理アドレスを含み、前記パブリック物理アドレスは、前記アドレス変換装置を通過する手段によって事前に取得されており、
前記通信クライアント（Ｃ_１）が、前記シグナリングメッセージを送信する前に、前記パブリック物理アドレスに対応する情報をエンコードし、前記シグナリングメッセージの異なる第２の位置に前記パブリック物理アドレスに対応する冗長な前記エンコード済み情報を付加する手段を有することを特徴とする通信クライアント（Ｃ_１）。
請求項６記載の通信クライアントにおいて、前記手段が、ポート番号を含むエンコード済み情報を付加することにも適している通信クライアント。
請求項６記載の通信クライアントにおいて、前記エンコード済み情報が、ＳＩＰプロトコルに準拠しているシグナリングメッセージの、ＳＤＰプロトコルに準拠している部分のフィールドに付加される通信クライアント。
請求項６乃至８いずれか１項に記載の通信クライアントを含む通信ネットワーク。
請求項１乃至５いずれか１項に記載の方法をコンピュータに実行させるためのコンピュータプログラム。