(57)【要約】  本発明は、少なくとも１つのアドレス変換設備（ＮＡＴ１、ＮＡＴ２）を備える通信ネットワーク（ＳＮ１、ＳＮ、ＳＮ２）を介する、発呼側通信クライアント（Ｃ１）と着信側通信クライアント（Ｃ２）の間の通信セッション（ｆｍ）を確立する方法に関する。この方法は、アドレス変換設備を通過するシグナリングメッセージ（ｆｓ）を伝送するステップ、及び通信セッションを確立するために通信クライアントの物理アドレスの交換を可能にするステップを含む。この方法は、少なくとも１つのクライアントが、第１の位置に物理アドレスを、第２の別の位置に同じ物理アドレスを含むコード化された情報を含む、少なくとも１つのシグナリングメッセージを伝送することを特徴とする。
2010507949.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのアドレス変換装置（ＮＡＴ１、ＮＡＴ２）を含む通信ネットワーク（ＳＮ１、ＳＮ、ＳＮ２）を介して、発呼側通信クライアント（Ｃ１）と被呼側通信クライアント（Ｃ２）との間の通信セッション（ｆｍ）をセットアップする方法であって、シグナリングメッセージ（ｆｓ）を伝送する段階、前記少なくとも１つのアドレス変換装置を通過する段階、及び前記通信セッションをセットアップするために前記通信クライアントの物理アドレスの交換を可能にする段階からなり、少なくとも１つの通信クライアントが第１の位置に物理アドレスを含む少なくとも１つのシグナリングメッセージを送信し、前記物理アドレスがアドレス変換装置通過手段によって事前に取得されており、前記通信クライアントが異なる第２の位置に前記物理アドレスに対応する冗長なエンコード済み情報を付加することを特徴とする方法。
【請求項２】
請求項１記載の方法において、前記物理アドレスが、前記少なくとも１つの通信クライアントによって実装されているアドレス変換装置通過解決策を介して取得される方法。
【請求項３】
請求項１乃至２いずれか１項に記載の方法において、前記少なくとも１つのシグナリングメッセージがまた、１以上のポート番号を第１のポート位置に、前記ポート番号を含む１以上のエンコード済み情報項目を異なる第２のポート位置に含む方法。
【請求項４】
請求項１乃至３いずれか１項に記載の方法において、前記位置が前記シグナリングメッセージのＳＤＰプロトコルに準拠している部分のフィールドであり、前記シグナリングメッセージがＳＩＰプロトコルに準拠している方法。
【請求項５】
前記第２の位置が前記ＳＤＰプロトコルの属性フィールドである請求項４記載の方法。
【請求項６】
少なくとも１つの他の通信クライアント（Ｃ２）との通信セッション（ｆｍ）をセットアップするためにシグナリングメッセージ（ｆｓ）を送信する手段、及びアドレス変換装置を通過する手段を有する通信クライアント（Ｃ１）であって、通信クライアント（Ｃ１）が、シグナリングメッセージを送信する前に、前記メッセージ内にアドレス変換装置を通過する前記手段によって事前に取得された物理アドレスに対応する冗長なエンコード済み情報を付加する手段を有することを特徴とする通信クライアント（Ｃ１）。
【請求項７】
請求項６記載の通信クライアントにおいて、前記手段が、ポート番号を含むエンコード済み情報を付加することにも適している通信クライアント。
【請求項８】
請求項６記載の通信クライアントにおいて、前記エンコード済み情報が、ＳＩＰプロトコルに準拠しているシグナリングメッセージの、ＳＤＰプロトコルに準拠している部分のフィールドに付加される通信クライアント。
【請求項９】
請求項６乃至８いずれか１項に記載の通信クライアントを含む通信ネットワーク。
【請求項１０】
請求項１乃至５いずれか１項に記載の方法を実装するように設計されているソフトウェア製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信ネットワークに関する。より詳しくは、本発明は「ＮＡＴ」などのアドレス変換装置を介したシグナリングメッセージの伝送の問題に関する。
【背景技術】
【０００２】
現在の通信ネットワークはＨ．３２３、ＭＧＣＰ（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）でよい。
【００９３】
従って、これらの装置はＳＩＰシグナリングメッセージのＳＤＰ部分に含まれる物理アドレス及びポート番号を変更することができる。従って、「ｍ」、「ｃ」及び「ｏ」フィールドに含まれるアドレスは通信クライアントＣ２に到着する前に変更されることがある。ある「ａ」フィールドが、例の第４の「ａ」フィールドの場合のように、エンコードされていないポート番号又は物理アドレスを含むときは、その「ａ」フィールドも変更されることがある。
【００９４】
しかし、「ａ」フィールドに含まれるポート番号及び物理アドレスはエンコードされているので、「ａ」フィールドに含まれるポート番号及び物理アドレスはこれらの装置では変更することができない。それらが通信クライアントＣ２に変更されずに到着し、このクライアントが、変更された可能性のある他方のフィールドに含まれる物理アドレス及びポート番号の代わりにそれらを使用できることが好ましい。
【００９５】
同様に、他のシグナリングメッセージもまた、それらが通信クライアントＣ１によって送信されたメッセージであれ、又は通信クライアントＣ２によって送信されたメッセージであれ、エンコード済み物理アドレス及びポート番号を含んでいてよい。従って、信号フローｆｓ全体が上述のことに従っていてよい。
【００９６】
物理アドレス及びポート番号をこのように構成することによって、それらが変更されていないことが保証され、２つの通信クライアントが通信セッション、及び１つ（又は複数）のメディアフローｆｍをセットアップすることができる。
【図１】
2010507949.tif 000003
【国際調査報告】
2010507949.tif 000004
2010507949.tif 000005
2010507949.tif 000006
2010507949.tif 000007