(57)【特許請求の範囲】
【請求項１】
送信先通信システムとの通信セッションを処理する通信システムであって、第１のローカル端末と、外部サーバと、第１のローカル端末と外部サーバとの間において共有通信ネットワーク上で通信セッションを伝送するための１つ以上の論理チャネルとを有し、前記通信ネットワークは通信セッションが必ず通過する第１のネットワークアドレス変換（以下、NATと称する）機能を備えており、
i)  第１のローカル端末は通信セッション用の少なくとも一つのトランスポートアドレスを有し；
ii)  第１のNAT機能は第１の端末と共有通信ネットワークとの間のコネクションにおけるトランスポートアドレスに対してネットワークアドレスマッピングを施し；
iii)  該システムは外部サーバとの通信において第１のローカル端末の代理として動作するようになされた第１のプロキシインターフェイスエージェントを備え；
iv)  第１のプロキシインターフェイスエージェントは外部サーバへの１つ以上のアウトバウンドコネクションにおいて論理チャネルを確立することができ、前記論理チャネルは第１のプロキシインターフェイスエージェントと外部サーバとの間の制御チャネルであり；
ｖ）  前記アウトバウンドコネクションは第１のプロキシインターフェイスエージェントによって確立される動的なアウトバウンドコネクションであり；
vi)  第１のプロキシインターフェイスエージェントは、第１のローカル端末のトランスポートアドレスと第１のプロキシインターフェイスエージェント−外部サーバ間の識別可能な論理チャネルとの間の関連付けを行うように構成されており、前記識別可能な論理チャネルはプロキシインターフェイスエージェントから外部サーバへの１つ以上の前記動的アウトバウンドコネクションにおいて確立される、
ことを特徴とする通信システム。
【請求項２】
通信システムの通信セッションを処理する方法であって、該通信システムは第１のローカル端末と、外部サーバと、第１のローカル端末と共有されたネットワークとの間の第１のプロキシインターフェイスエージェントとを有し、前記通信ネットワークは通信セッションが必ず通過する第１のNAT機能を備えており、該方法は、
i)  第１のローカル端末と外部サーバとの間において共有通信ネットワーク上で１つ以上の論理チャネルで通信セッションを伝送するステップであって、該第１のローカル端末は通信セッション用の少なくとも一つのトランスポートアドレスを有するステップ；
ii)  第１のNAT機能が第１の端末と共有されたネットワークとの間のコネクションにおけるトランスポートアドレスに対してネットワークアドレスマッピングを持続的に適用することを許容するステップ；
iii)   第１のプロキシインターフェイスエージェントを用いて、外部サーバとの通信において第１のローカル端末を代理して動作させるステップ；
iv)  第１のプロキシインターフェイスエージェントを用いて、外部サーバに対する１つ以上のアウトバウンドコネクションにおいて論理チャネルを確立するステップであって、該論理チャネルは第１のプロキシインターフェイスエージェントと外部サーバとの間の制御チャネルであるステップ；
ｖ）  第１のプロキシインターフェイスエージェントを用いて外部サーバへの動的なアウトバウンドコネクションを確立するステップ；
vi)  第１のプロキシインターフェイスエージェントを用いて、第１のローカル端末のトランスポートアドレスと、第１のプロキシインターフェイスエージェント−外部サーバ間の識別可能な論理チャネルとの間に、一つ以上の関連付けを行うステップであって、前記識別可能な論理チャネルは第一のプロキシインターフェイスエージェントから外部サーバへの１つ以上の前記動的なアウトバウンドコネクションにおいて確立されるステップを含むことを特徴とする方法。
【請求項３】
第１のプロキシインターフェイスエージェントは外部サーバからの要求に応じて前記関連付けを行う請求項２記載の方法。
【請求項４】
第１のプロキシインターフェイスエージェントは該第１のプロキシインターフェイスエージェントが発生する要求に応じて前記関連付けを行う請求項２記載の方法。
【請求項５】
外部サーバ自身が（あるいは第１のプロキシインターフェイスエージェントが）外部サーバに前記識別可能な論理チャネルと送信先端末の如き送信先通信システムとの通信の論理チャネルとの対応付けを行うよう要求するように構成されている請求項２乃至４のいずれかに記載の方法。
【請求項６】
通信システムは制御チャネル上のクライアント−サーバ・プロトコルを備え、
i)  制御チャネル上の該クライアント−サーバ・プロトコルを用いて、（a)  第１の端末によって用いられる通信論理チャネルと、(b)  第１のプロキシインターフェイスエージェントと外部サーバの間の識別可能な論理チャネルであって第１のプロキシインターフェイスエージェントから外部サーバへの１つ以上の前記アウトバウンドコネクションにおいて確立される識別可能な論理チャネルと、(c)  外部サーバと送信先通信システムとの間の通信論理チャネルとの動的な関連付けを可能とし、その結果、第１の端末が外部サーバのトランスポートアドレスに位置しかつ送信先通信システムが第１のプロキシインターフェイストランスポートアドレスに位置するような見かけを与える請求項２乃至５のいずれかに記載の方法。
【請求項７】
外部サーバはクライアント−サーバプロトコルのマスターとなるように構成され、かつ外部サーバはまた、第１の端末が第１のプロキシインターフェイスエージェントとあたかもそれが送信先通信システムであるかのように通信し、かつ、送信先通信システムが外部サーバとあたかもそれが第１端末であるかのように通信するようにすべく、リアルタイム（あるいは非リアルタイム）プロトコル内で搬送されるトランスポートアドレスを変更するように構成されている請求項６記載の方法。
【請求項８】
第１のプロキシインターフェイスエージェントはクライアント−サーバプロトコルのマスターとなるように構成され、かつプロキシインターフェイスエージェントはまた、第１の端末が第１のプロキシインターフェイスエージェントとあたかもそれが送信先通信システムであるかのように通信し、かつ、送信先通信システムが外部サーバとあたかもそれが第１端末であるかのように通信するようにすべく、リアルタイム（あるいは非リアルタイム）プロトコル内で搬送されるトランスポートアドレスを変更するように構成されている請求項６記載の方法。
【請求項９】
第１のローカル端末のトランスポートアドレスは動的に割り当てられる請求項２乃至８のいずれかに記載の方法。
【請求項１０】
外部サーバのトランスポートアドレスは動的に割り当てられる請求項２乃至９のいずれかに記載の方法。
【請求項１１】
外部サーバのトランスポートアドレスはいずれも動的には割り当てられない請求項２乃至９のいずれかに記載の方法。
【請求項１２】
前記通信システムは、通信セッションが必ず通過する第１のファイアウォールを備え、該ファイアウォールは第１のローカル端末と共有通信ネットワークとの間のあるタイプの通信を制限するように構成され、かつ第１のプロキシインターフェイスエージェントと外部サーバとの間の通信は制限しないように構成されている請求項２乃至１１のいずれかに記載の方法。
【請求項１３】
外部サーバのトランスポートアドレスのうちの少なくとも一つは少なくとも一つのあらかじめ割り当てられたポートを有し、かつ第１のプロキシインターフェイスエージェントから外部サーバへのアウトバウンドコネクションは前記あらかじめ割り当てられたポートを用いる請求項２乃至１２のいずれかに記載の方法。
【請求項１４】
外部サーバのすべてのトランスポートアドレスはあらかじめ割り当てられたポートを有する請求項１３記載の方法。
【請求項１５】
外部サーバのすべてのトランスポートアドレスは最大で２つのあらかじめ割り当てられたポートを有する請求項１４記載の方法。
【請求項１６】
プロキシインターフェイスエージェントのすべてのトランスポートアドレスは動的に割り当てられる請求項２乃至１５のいずれかに記載の方法。
【請求項１７】
プロキシインターフェイスエージェントの少なくとも一つのトランスポートアドレスはあらかじめ割り当てられたポートを用いる請求項２乃至１５のいずれかに記載の方法。
【請求項１８】
プロキシインターフェイスエージェントのすべてのトランスポートアドレスはあらかじめ割り当てられたポートを用いる請求項２乃至１５のいずれかに記載の方法。
【請求項１９】
前記通信システムは第２のローカル端末を備え、外部サーバは第１の端末と第２の端末との間にあるプロキシサーバであって通信セッションが続く間、各端末に対して他方の端末のプロキシとして動作する請求項２乃至１８のいずれかに記載の方法。
【請求項２０】
前記通信システムは第２のローカル端末と第２の外部サーバとを備え、該第２の外部サーバは第２の端末のプロキシとして動作し、かつ第１の外部サーバと第２の外部サーバとの間の通信は公共ネットワークあるいは共有されたネットワークを介してなされる請求項２乃至１８のいずれかに記載の方法。
【請求項２１】
共有されたネットワークは公共通信ネットワークを含む請求項２乃至２０のいずれかに記載の方法。
【請求項２２】
共有されたネットワークはインターネットを含む請求項２乃至２１のいずれかに記載の方法。
【請求項２３】
プロキシインターフェイスエージェントはローカル端末と同じ場所にある請求項２乃至２２のいずれかに記載の方法。
【請求項２４】
プロキシインターフェイスエージェントはローカル端末から離れた場所にある請求項２乃至２２のいずれかに記載の方法。
【請求項２５】
プロキシインターフェイスエージェントに対して２つ以上のローカル端末が存在する請求項２乃至２４のいずれかに記載の方法。
【請求項２６】
プロキシインターフェイスエージェントは異なるリアルタイムまたは非リアルタイムのプロトコルを用いて、同時に複数の端末を代理して動作する請求項２乃至２５のいずれかに記載の方法。
【請求項２７】
外部サーバは異なるリアルタイムまたは非リアルタイムのプロトコルを用いて、同時に複数の端末および／または複数のプロキシインターフェイスエージェントの代理として動作する請求項２乃至２６のいずれかに記載の方法。
【発明の詳細な説明】
【０００１】
本発明はマルチメディア呼（multimedia call)や音声呼(voice call)を例とする通信セッションを操作する通信システムに関する。
【０００２】
本明細書の提示する発明は、異なる安全なプライベートIPデータネットワークに属するエンドポイント間において（H.323、SIP、MGCPなどのリアルタイムプロトコルを用いて）、個々のプライベートネットワークのデータプライバシーやデータセキュリティを損なうことなく互いに通信を行うことを可能にする。本発明は例えばファイアウォールなどの既存のセキュリティ機能や、ファイアウォール機能において実行されるであろうNAPT（ネットワークアドレスポート変換）機能、ルータ、プロキシといった既存のセキュリティ機能と協働して機能するという利点を有する。本発明の利点は、それらの機器をプロトコル(例えばH.323）に完全に適合するようにアップグレードするコストまたはプロトコル（例えばH.323)を認識する付加的な機器を配備するコストをかけずにすむところにある。本明細書の提示する発明は、プライベートネットワークの端部においてシンプル（一対一の）NAT（ネットワークアドレス変換）マッピングが適用されている構成、および／または、プライベートネットワークの端部においてNAPT（ネットワークアドレスおよびポート変換）が行われている構成に適用される。これら２つの構成は共存することも可能であり、本発明の装置により、一方の構成を有するプライベートネットワークと他方の構成を有するプライベートネットワーク間での通信を行わせることができる。同様に、単一ネットワーク内でも、いくつかの端末（例えば専用ルームシステム）は一方の構成を用い、他の端末（例えばデスクトップのクライアントPC)は第２の構成を用いるものであってもよい。なお、本明細書においては、NATという用語はすべての形式のネットワークアドレス変換を意味するものとする。
【０００３】
本明細書で提示する発明の説明はITUのH.323スタンダードに関連して行うが、これはH.323がIPネットワークを含むパケットネットワーク上のリアルタイムマルチメディア通信で広く行われているスタンダードであるからである。しかし本発明は双方向に情報を送るためにポートを動的に割り当てる必要のある他のスタンダードあるいは方法（例えばIETFのセッション開始プロトコルSIP)にも同様に適用することができる。本発明の主要な利点は、プライベートネットワークのインフラストラクチュア（ファイアウォールおよびルータ）がリアルタイム通信に用いられるプロトコルを認識する必要がなく、かつプライベートネットワーク内外にトラフィックを通過させる方法もまたプロトコルを認知しなくてよいという点にある。これにより、企業はプロトコルを顧慮することなく装置を配備することができる。だからといって何らかの装置がセキュリティ上の理由やその他の理由でプロトコルのチェックをおこなうというわけではない。
【０００４】
急速に発展するIP（インターネットプロトコル）データネットワークはマルチメディアおよび音声通信サービスプロバイダにとっての新たな機会と課題を作りだしている。現在営業しているテレコミュニケーション運営者、および次世代の通信事業者やサービスプロバイダによって、データネットワークバックボーンへの、未曾有の投資がなされている。同時にDSLやケーブルモデムといったブロードバンドアクセス技術が広範囲のユーザーに高速なインターネットアクセスを提供している。サービスプロバイダは、IPデータネットワークを利用して新たな音声・ビデオサービスおよびデータサービスを高速インターネットと平行してデスクトップ、オフィス、家庭に直接届けることを目指している。
【０００５】
H.323スタンダードはそのサービス品質に保証のないパケットベースのネットワーク上でのマルチメディア通信に適用される。それは背景にあるトランスポートネットワークおよびプロトコルからは独立して設計されている。今日IPデータネットワークはデフォールト（既定の）かつユビキタスな（遍在する）パケットネットワークであり、H.323の導入はその大部分が（全部ではないにせよ）IPデータネットワーク上でのものである。SIPやMGCPを例とする他のリアルタイム（音声およびビデオ）通信用のプロトコルも、呼シグナリングおよびメディアのトランスポートにIPデータネットワークを用いている。更に、IPデータネットワーク上でのリアルタイムでの音声ビデオのトランスポートに関連する新たなアプリケーションのための新たなプロトコルも開発されるものと予測される。本発明において提供される方法はそれらのプロトコルや１回のセッションで複数のトラフィックフローを要求する他のプロトコルにもまた適用されるものである。
【０００６】
広域通信において、異なる製造業者による端末が相互運用される場合には、スタンダード（標準）が根本的な重要性を有する。マルチメディア分野において、パケットネットワーク（例えばIPデータネットワーク）上でのリアルタイム通信に関する現在のスタンダードはITUスタンダードH.323である。H.323は現在では比較的成熟したスタンダードであり、マイクロソフト社、シスコ社、インテル社などの企業を含むマルチメディア通信業界の支持を得ている。例えばパーソナルコンピュータの７５％にマイクロソフト社のNetMeeting（商標）プログラムがインストールされていると推計される。NetMeetingはH.323に準拠したマルチメディア（音声、ビデオおよびデータ）通信用のアプリケーションソフトウエアである。現在では異なる製造業者による装置間での相互運用性（互換性）が達成されている。International Multimedia Communication Consortium (IMTC)の主催する最近の相互運用性イベントには世界の１２０を越える企業が参加した。このIMTCはマルチメディア通信装置の相互運用性を促進するための独立組織である。このイベントは製造業者が相互動作問題をテストし、かつ解決するために定期的に行われている。
【０００７】
これまで、マルチメディア（特にビデオ）通信を大規模に取り込むには数多くの障害があった。かつては利用の簡便性、品質、コスト、通信帯域幅のすべてが市場の成長を妨げていた。しかし、ビデオエンコーディング技術の進歩、安価なIPアクセスがどこでも得られる状況、およびデータネットワークへの現在の投資が、DSLやISDNやケーブルモデムの浸透と結びついて、現在ではほとんどの問題をある程度解決し、マルチメディア通信および音声通信を可能にしている。
【０００８】
H.323がスタンダードとして策定された際には、プライベートネットワーク間の広いエリアにおけるトランスポートのためにH.323をH.320に変換するH.323-H.320ゲートウェイがネットワークドメインの端部に作られるものと想定されていた。したがってIP上のH.323の導入は単一ネットワーク内の通信に集中していた。
【０００９】
しかしながら、IPは広域プロトコルとして愛顧を受け続けている。ますます多くの組織が、データネットワーク全体についてIPに基礎を置き続けている。高速インターネットアクセス、管理されたイントラネット、ヴァーチャル・プライベート・ネットワークス（VPNｓ）のすべてにおいてIPに基礎を置くことが普通である。このIPトレンドがH.320のマルチメディアプロトコルとしての衰退を引き起こしている。市場の要求はH.320を完全にIP上のH.323に置き換えることにある。しかしWAN（ワイドエリアネットワーク）を通過して行うIP上のリアルタイム通信のトランスポートに関して、市場を最も活性化させているものはおそらく音声である。H.323やSIPなどのスタンダードを用いることにより、ユーザーは自らのコンピュータを介して、インターネットを安価な音声呼に用いるようになってきた。これは全く新たなVoice over IP(VoLP）産業の誕生をはっきりと示したものであり、この産業はイーサネット（登録商標）電話、IP PBX、ソフトスイッチ、IP/PSTNゲートウェイを含む新たなVoIP製品の発達を見越しており、これらすべてが企業とユーザーの間での途切れることのないVoIPと結びついている。ここではH.323、SIPおよびMGCPが支配的なスタンダードとなることが予想される。
【００１０】
残念ながら、H.323およびSIPの実際の広域配備には、予見できなかった技術的諸障害がいまなお存在する。この技術的諸障害はIPデータネットワークの境界における通信インフラストラクチュアに関するものである。
【００１１】
したがって、今日成功しているIP上のマルチメディアおよび音声通信はイントラネット即ちプライベートに管理されたIPネットワークに限られている。
【００１２】
問題は２つのIP技術から生じている、即ちネットワークアドレス変換（NAT)およびファイアウォールである。これらの問題の解決を考える際にはセキュリティも課題となる。データネットワーク上でのリアルタイム通信の導入が共有されたネットワーク（例えば公共のインターネット）上に及ぶ場合には、企業はデータセキュリティになんら危険がないことを確実なものとしなければならない。現在の上記の諸問題の解決方法においては、企業の外部IPアドレスを該企業が通信しようとする者（音声通信は通常すべての者を含む）に対して公にする必要がある。ここに提示する本発明はこの欠点を有しておらず、企業の外部IPアドレスを「信頼された」サービスプロバイダにのみ知らしめればよい。これは公共インターネットが大きく発展してきたやり方である。
【００１３】
NATは「アドレス不足問題」を解決するために導入された。IPネットワークのいずれのエンドポイントあるいは「ホスト」も、該エンドポイントを識別（同定identify）するひとつの「IPアドレス」を有しており、データパケットは正確にそこに送られるすなわちそこにルート付けされることができ、かつそこで受け取られたパケットがどこからやってきたのかを識別することができる。IPアドレスフィールドを規定した時点では、誰もデスクトップ装置の広大な成長を予見することができなかった。グローバルIPの展開の何年後かに、IPプロトコルを用いて通信を求めるエンドポイントの数がアドレスフィールドにおいて可能な固有IPアドレスの数を越えることが明らかになった。アドレスフィールドを増やし、より多くのアドレスを利用可能とするには、IPインフラストラクチュア全体を更新することが必要であった（当業界はある点において、これをIPバージョン６によって行うことを計画している。）
【００１４】
今日のソリューション（解決方法）は現在NATと呼ばれているものである。IETF RFC1631で規定されたシンプルNAT（Simple NAT）と呼ばれる最初のNATソリューションは一対一マッピングを利用しており、ワールド・ワイド・ウェブが存在する前の、組織内のいくつかのホスト（例えばE−メールサーバやファイル転送サーバ）のみが組織外部と通信する必要があった頃に生まれたものである。NATにより企業内にプライベートIPネットワークを構築することが可能となるが、そこでは該企業内の各エンドポイントはその企業内のみで唯一固有（unique）であるが、グローバルには唯一固有ではないアドレスを有している。すなわちこれらはプライベートIPアドレスである。このことにより、ある組織内の各ホストは該組織内の任意の他のホストと通信する（すなわちアドレスする）ことが可能である。外部と通信するためには、パブリックな（公の）すなわちグローバルに唯一固有のIPアドレスが必要である。こうしたプライベートIPネットワークの端部にはプライベートIPアドレスとパブリックIPアドレスとを相互変換するNAT機能を行う装置が配備される。企業はその企業に独占的に（排他的に）属するひとつ以上のパブリックアドレスを有するが、一般的には必要なパブリックアドレスの数はホストの数よりも少ない。その理由は、外部と通信する必要があるのはいくつかのホストのみであるか、あるいは同時に外部通信する数はホスト数よりも少ないからである。より洗練された形態のNATはパブリックアドレスのプールを有し、それらのパブリックIPアドレスをファーストカム−ファーストサーブド方式（先着順方式）で外部通信を必要とするホストに動的（流動的）に割り当てている。外部装置が特定の内部装置に勝手にパケットを送る必要がある場合には固定ネットワークアドレス規則が必要となる。
【００１５】
今日ほとんどのプライベートネットワークは10.x.x.xアドレスレンジからのプライベートIPアドレスを使用している。外部通信はたいていの場合管理されたあるいは共有されたIPネットワークまたは公共のインターネットを介したサービスを提供するサービスプロバイダを介している。各ネットワークの境界において、アドレスをパケットが伝達されるIPネットワーク内で唯一固有のものとするためのNATが用いられる。シンプル NATは完全なIPアドレスを一対一マッピングによって変換している。このマッピングは固定的なものであってもよいし、当該通信セッションが続く間だけ動的に与えられるものであってもよい。
【００１６】
ウェブサーバ、メールサーバ、および外部サーバなどが、それらに到達する外部通信を許容するために静的な（static）一対一NATマッピングを必要とするホストの例である。
【００１７】
NATを用いることによって、ホストのIPアドレスは外部から不可視となる。これによってセキュリティレベルが向上する。
【００１８】
シンプルNATのひとつの拡張版は、変換マッピングにポートを付加的に用いるものであり、多くの場合NAPT（ネットワークアドレスポート変換）またはPAT（ポートアドレス変換）と呼ばれる。ポートは２つのホスト間のポイント対ポイントのトランスポートコネクションの一方の端を識別（アイデンティファイ）する。ワールド・ワイド・ウェブ（WWW)への大量アクセスに伴い、IPアドレス不足が再び生じている。これは現在多くのデスクトップマシーンがプライベートネットワークの外へ通信する必要があるからである。IETFのRFC 1631に記載された解決方法は、プライベートIPアドレスとパブリックIPアドレスとの間の多対一のマッピングを許容し、その代わり、プライベートデバイスから外部のパブリックネットワーク即ち共有されたネットワークへとなされる各コネクション（接続）のパブリックIPアドレスについて唯一固有の（uniqueな）ポート割り当てを用いている（理論的には各IPアドレスに対して６４ｋの固有ポートがある）。インターネットの発展により、PATはアドレス変換の一般的な手法となっている。
【００１９】
PATのひとつの特徴はプライベートIPアドレス／ポートマッピングのパブリックIPアドレス／ポートへの割り当てが動的になされ、一般的にはプライベートデバイスがパブリックネットワークへのアウトバウンド（外向き／発信）接続を行うたびごとになされることである。PATを用いると、前もって発信方向の接続によりそのようなPAT割り当てが行われていない限り、データはインバウンド方向(内向き方向／着信方向）に進行することはできない、即ちパブリックネットワークからプライベートネットワークへと進行することはできない。通常、PATデバイスはPAT割当てを恒久的に行わない。所定の「沈黙」期間が経過すると、言い換えるとアウトバウンドで（外向きに）開始された接続に対して着信データがもはや受信されなくなったときに、当該接続に対するPAT割り当てが解放され、当該ポートが自由に新たなコネクションに割り当てられるようになる。
【００２０】
普通のIPプロトコルを介したコンピュータとネットワークとの接続の方がより容易であるが、これは同時にプライバシーとセキュリティの侵害をも更に容易にする。比較的少ないコンピュータスキルによりプライベートなあるいは内密なデータおよびファイルにアクセスすることが可能となり、そうしたビジネス情報を不正に悪用することも可能となる。当業界においてそのような攻撃に対する対策はプライベートネットワークの境界にファイアウォールを配備することである。
【００２１】
ファイアウォールはプライベートIPネットワークとパブリックのIPネットワークとの間を通過するIPトラフィックの種類を制限するすなわち「フィルタする（ろ過する）」ようになされている。ファイアウォールはいくつかのレベルの規則によって制限を課することができる。制限は、IPアドレス、ポート、IPトランスポートプロトコル（たとえばTCPやUDP）またはアプリケーションに対して課することができる。制限は対称ではない。すなわち典型的にはプライベートネットワーク側（ファイアウォールの内側）からパブリックネットワーク側（ファイアウォールの外側）に向かう方向に関しては、その反対方向よりも多くの通信を許容する。
【００２２】
ファイアウォール規則をIPアドレスだけに適用することは難しい。内部のホスト（すなわちあなたのPC）のいずれもが地球上に点在するいずれかの外部ホスト（ウェブサーバ）に接続することを望むかもしれないからである。この問題に対しては「well-known port（よく知られたポート）」の概念が適用される。ポートは2つのホスト間のポイント対ポイントのトランスポートコネクションにおける一方の端部を識別（同定）する。「よく知られたポート」はひとつの「既知の(知られた)」種類のトラフィックを担うものである。IANAすなわちInternet Assigned Number Authorityはあらかじめ割り当てられたよく知られたポートおよびそれらポートの担うトラフィックの種類を特定している。例えばポート８０はウェブサーフィン（httpプロトコル）トラフィックに割り当てられ、ポート２５はシンプル・メール・トランスポート・プロトコル(Simple Mail Transport Protocol)に割り当てられる、等である。
【００２３】
ウェブサーフィンに対するファイアウォールのフィルタリング規則の例は以下のようなものである：
どの内部IPアドレス／ポート番号（port number）も、TCP（Transport Connection protocol）およびHTTP（ウェブサーフィン用のアプリケーションプロトコル）を用いて、どの外部IPアドレス／ポート８０に接続してもよい。
【００２４】
この接続は双方向的であり、したがってトラフィックはウェブサーバから同一の経路を逆に流れることができる。ポイントとなるのは接続は内部側から開始されなければならないという点である。
【００２５】
ｅ−メール用のファイアウォールフィルタリング規則の例は以下のようなものである：
どの外部IPアドレス／どのポート番号も、TCPおよびSMTPを用いてIPアドレス192.3.4.5／ポート25に接続してよい。
（同時に、NAT機能は送信先IPアドレス192.3.4.5をメールサーバの内部アドレスである10.6.7.8に変換してもよい。）
【００２６】
「どの内部IPアドレス／どのポート番号もTCPおよびUDPのためにどの外部アドレス／どのポート番号と接続してもよい、逆もまた可」といったフィルタ規則はフィルタとしては広すぎるものであり、ファイアウォールを解放して直接接続するのと同じことになってしまう。IT管理者はこのような規則を敬遠する。
【００２７】
H.323は背景となるネットワークおよびトランスポートプロトコルとは独立して設計されてきた。それでもH.323のIPネットワークへの導入は以下の主要概念の対応付けによって可能となる。
H.323アドレス          :      IPアドレス
H.323論理チャネル  :      TCP／UDPポートコネクション
【００２８】
IP上でのH.323の導入においては、H.323プロトコルメッセージはTCPまたはUDPのいずれかを用いてIPパケットのペイロードとして送信される。多くのH.323メッセージは送信元のエンドポイントまたは送信先のエンドポイントあるいはその両方のエンドポイントのH.323アドレスを含む。SIPなどの他のシグナリングプロトコル(signaling protocol)もまたシグナリングプロトコルペイロード内にIPアドレスを埋め込む。
【００２９】
しかしながら、NAT機能は送信元および送信先ホストの見かけのIPアドレス(apparent IP address)（およびポート）を変換するが、H.323ペイロード内のH.323アドレスは変更しない。ホストはH.323ペイロード内で交換されるH.323アドレスおよびポートを用いて、受信した様々なデータパケットを呼（コール）に関連づけているので、上記のようなNAT機能はH.323プロトコルの破壊を引き起こすものであり、H.323ペイロードアドレスを取り扱うには媒介インテリジェンス（intermediary intelligence）が必要となる。
【００３０】
マルチメディア通信の複雑性により、H.323はエンドポイント間にいくつかの論理チャネルを開くことを要求する。論理チャネルは、呼制御、能力交換（capabilities exchange）、オーディオ、ビデオ、データについて必要である。オーディオとビデオのみを含む単純なポイント対ポイントのH.323マルチメディアセッションにおいては、少なくとも６つの論理チャネルが必要となる。H.323のIP配備においては、論理チャネルはTCPまたはUDPポートコネクションにマッピングされ、それらの多くは動的に割り当てられる。
【００３１】
ファイアウォール機能は規則の設定されていないポート上のトラフィックをフィルタによって排除してしまうので、ファイアウォールを開放するか（この場合ファイアウォールの目的が無効になる）、あるいは多くのH.323トラフィックが通過不能になるか、の二つに一つとなってしまう。
【００３２】
従って、エンドポイント間に存在するNATおよびファイアウォール機能は共にH.323（およびSIPやMGCPなどのその他のリアルタイムプロトコル）通信の動作を阻害する。これは両エンドポイントが異なるプライベートネットワークに属する場合、または一方のエンドポイントがプライベートネットワーク内にあり他方のエンドポイントがインターネット内にある場合、または両エンドポイントが別々に管理されたIPネットワークナインにある場合には一般的に起こることである。
【００３３】
従ってH.323（およびSIP、MGCPなどの）通信はファイアウォールにとって忌むべきものである。ファイアウォールがH.323を認識できるようにするか、あるいは何らかの媒介インテリジェンスがポート割り当てを安全なやり方で操作するようにしなければならない。
【００３４】
この問題の可能な解決方法のひとつは完全なIP H.323アップグレード（complete IP H.323 upgrade）である。これは以下のことを要求する：
・  各IPネットワーク境界にあるNAT機能に対するH.323アップグレード。NAT機能はすべてのH.323ペイロードを走査し、一貫性をもってIPアドレスを変換しなければならない。
・  各IPネットワーク境界にあるファイアウォール機能に対するH.323アップグレード。ファイアウォールは、動的に割り当てられるポートを開くことができるようにすべてのH.323通信を認識しおよび監視し、かつそれらポート上のすべての非H.323トラフィックをフィルタしなければならない。
・  境界あるいは共有されたIPネットワーク内においてH.323インテリジェンスを配備し、アドレスを分析しかつ調停すること（resolve and arbitrate addresses）。ユーザーがIPアドレスを直接用いることはほとんどない。実際には別名IPアドレス（エイリアス）を用いる。インテリジェンスはエイリアスをIPアドレスに分析する必要がある。このH.323機能はゲートキーパと呼ばれるH.323要素（H.323 entities）に含まれる。
【００３５】
この可能な解決方法の短所は以下の通りである：
・  H.323通信を実現するには、各組織／プライベートネットワークは同一レベルのアップグレードを有さなければならない。
・  アップグレードには費用がかかる。新たな機能性または新たな装置を購入し、計画し、配備しなければならない。IT管理者はH.323について学習しなければならない。
・  そのような設備を該設備に対する要請に適合させることは容易ではない。なぜなら当該技術は漸進的に導入されるものであり、当初の（おそらくは実験的な）要請よりもより大規模でコストのかかる初期設備が必要となるからである。
・  シンプル NATおよびファイアウォール機能を分析する間断ないH.323パケット解析は各ネットワーク境界において信号に待ち時間を課す。そしてオーディオおよびビデオに対する待ち時間の許容量はきわめて小さい。
・リアルタイム通信のスタンダードは複数あり、それらのスタンダードのシグナリングプロトコルは異なっているので、企業は複数の、即ち用いようとするプロトコルの各々について一つずつのアップグレードを行う必要がある。
・メディアは２つの企業の間、または一つの企業とパブリックネットワーク内の一つのデバイスとの間を直接進行すると考えられる。このことにより、企業のIPアドレスが公知のものとなる。これはセキュリティを危うくするものと考えられる。なぜなら、潜在的攻撃者は攻撃を始める第１段階として企業のIPアドレスを発見する必要があるからである。
【００３６】
これらの諸問題により、ファイアウォールおよび／またはネットワークアドレス変換（NAT)が存在する場合にはH.323プロトコルは用いられていない。一つの解決案はH.323システムをファイアウォールおよびNAT機能のパブリック側に置く、というものであった。これにより、H.323を用いると共に、ネットワークのそれ以外の部分を保護することが可能となる。この方法の短所は以下のようなものである：
１．最も普及している（ユビキタスな）ビデオ通信装置はデスクトップPCである。そしてすべてのデスクトップコンピュータをパブリック側に置くのはナンセンスである。
２．ファイアウォールのパブリック側では、H.323システムは攻撃者から保護されない。
３．特別なシステムのみがH.323通信を許されることになるので、各団体はH.323の潜在的遍在性の利点を享受できない。
４．ファイアウォールがH.323システムのデータアクセスを妨げるので、各団体はH.323のデータ共有機能をフルに活用することができない。H.323システムからのデータ転送機能を可能とするためにファイアウォールを開放することはできない。なぜならその場合、攻撃者がH.323システムをリレー（中継器）として用いることができるからである。
５．形成されつつあるVoice over IP(VoIP)市場においては、イーサネット（登録商標）電話やIP PBXを例とするデータネットワークに直接接続する電話機器の市場が存在する。それらはその性質上デスクトップ機器であるので、ファイアウォールやNAT機能の背後のプライベートネットワーク上に配備される。従って上に述べた諸問題を解決することなしには、これらの機器を用いた電話機能は企業のプライベートネットワーク即ちイントラネットに限られるか、または外部世界に到達するためにIP-PSTNゲートウェイを通過しなければならない。
【００３７】
音声・ビデオおよびデータ用に企業へのブロードバンド接続を便宜よく利用するにはこれらの問題についての安全な解決が必要となる。
本発明の目的はこれらの問題に対処することである。
【００３８】
本発明は、送信先通信システムとの通信セッションを処理する通信システムを提供するものであり、該システムは、第１のローカル端末と、外部サーバと、第１のローカル端末と外部サーバとの間において共有された通信ネットワーク上で通信セッションを伝送するための１つ以上の論理チャネルとを有し、前記通信ネットワークは通信セッションが必ず通過する第１のNAT機能を備え、
a)  第１のローカル端末は通信セッション用の少なくとも一つのトランスポートアドレスを有し；
b)  第１のNAT機能は第１の端末と共有通信ネットワークとの間のコネクションにおけるトランスポートアドレスに対してネットワークアドレスマッピングを施し；
c)  該システムは外部サーバとの通信において第１のローカル端末の代理として動作するように構成された第１のプロキシインターフェイスエージェント(proxy interface agent)を備え；
d)  第１のプロキシインターフェイスエージェントは外部サーバへの１つ以上のアウトバウンドコネクションにおいて論理チャネルを設定（確立）することができ、前記論理チャネルは第１のプロキシインターフェイスエージェントと外部サーバとの間の制御チャネルであり；
e）  前記アウトバウンドコネクションは第１のプロキシインターフェイスエージェントによって確立される動的なアウトバウンドコネクションであり；
f)  第１のプロキシインターフェイスエージェントは、第１のローカル端末のトランスポートアドレスと第１のプロキシインターフェイスエージェント−外部サーバ間の識別可能な論理チャネルとの間の関連付けを行うように構成されており、前記識別可能な論理チャネル（identifiable logical channel(s))はプロキシインターフェイスエージェントから外部サーバへの１つ以上の前記動的アウトバウンドコネクションにおいて設定される、ことを特徴とする。
【００３９】
また本発明は、通信システムの通信セッションを処理する方法を提供するものであり、該方法において、該通信システムは第１のローカル端末と、外部サーバと、第１のローカル端末と共有されたネットワークとの間のプロキシインターフェイスエージェントを有し、前記通信ネットワークは通信セッションが必ず通過する第１のNAT機能を備えており、該方法は以下のステップを含むことを特徴とする、即ち：
i)  第１のローカル端末と外部サーバとの間において共有通信ネットワーク上で１つ以上の論理チャネルで通信セッションを伝送するステップ、該第１のローカル端末は通信セッション用の少なくとも一つのトランスポートアドレスを有する；
ii)  第１のNAT機能が第１の端末と共有されたネットワークとの間のコネクションについてのトランスポートアドレスに対してネットワークアドレスマッピングを持続的に適用することを許容するステップ；
iii)   第１のプロキシインターフェイスエージェントを用いて、外部サーバとの通信において第１のローカル端末を代理して動作させるステップ；
iv)  第１のプロキシインターフェイスエージェントを用いて、外部サーバに対する１つ以上のアウトバウンドコネクションにおいて論理チャネルを設定するステップ、該論理チャネルは第１のプロキシインターフェイスエージェントと外部サーバとの間の制御チャネルである；
ｖ）  第１のプロキシインターフェイスエージェントを用いて外部サーバへの動的なアウトバウンドコネクションを確立するステップ；
vi)  第１のプロキシインターフェイスエージェントを用いて第１のローカル端末のトランスポートアドレスと第１のプロキシインターフェイスエージェント−外部サーバ間の識別可能な論理チャネルとの間の関連付けを行うステップ、前記識別可能な論理チャネルはプロキシインターフェイスエージェントから外部サーバへの１つ以上の前記動的アウトバウンドコネクションにおいて設定される。
【００４０】
論理チャネルは全体で通信セッションを提供し、アウトバウンドコネクションにより、必要なNATマッピングが生成されて端末と外部サーバとの間のインバウンド（内向きまたは着信）およびアウトバウンド（外向きまたは発信）通信が可能となる。第１のローカル端末からの通信は第１のプロキシインターフェイスエージェントにより識別可能な論理チャネル上に素通しでマッピングされる。外部サーバは送信先通信システムと、あたかも第１の端末であるかのように通信する。従って、この通信システムを用いて第１の端末と送信先通信システムとの間の素通しの通信手段(transparent communications means)を構成することができ、外部サーバが先方へ向かう通信の転送を担う。
【００４１】
TCPでのインバウンド通信を可能とするために、あらかじめ確立された双方向アウトバウンドコネクションを形成してNATマッピングを確立する。
【００４２】
UDPでのインバウンド通信を可能にするため、プローブパケットを送ってNATマッピングを確立する。
【００４３】
通信セッションの間、第１のNAT機能は第１のプロキシインターフェイスエージェントと外部サーバとの間の接続にネットワークアドレスマッピングを継続的に施す。
識別可能な論理チャネルを、通常の多重化手法を用いて１つ以上のコネクションに多重化してもよい。
【００４４】
トランスポートアドレスの一例は、IPアドレスとポートである。従って一般的にネットワークアドレスマッピングはIPアドレスおよび／またはポートのマッピングである。
【００４５】
本発明の一実施形態において、第１のプロキシインターフェイスエージェントは前記の関連付けを、外部サーバからの要求に応じて行う。
【００４６】
本発明の別の一実施形態においては、第１のプロキシインターフェイスエージェントは前記の関連付けを第１プロキシインターフェイスエージェント自身の要求に応じて行う。
【００４７】
外部サーバ自身が（あるいは第１のプロキシインターフェイスエージェントが）外部サーバに対して、前記の識別可能な論理チャネルと外部サーバおよび送信先端末などの送信先通信システム間の通信の論理チャネルとの間の対応付けを行うことを要求するようにしてもよい。
【００４８】
好適には、第１のローカル端末のトランスポートアドレスは動的に割り当てられる。同様に外部サーバのトランスポートアドレスも動的に割り当てるようにしてもよい。
【００４９】
あるいは外部サーバのトランスポートアドレスをいずれも動的には割り当てないようにしてもよい。
【００５０】
この通信システムは通信セッションが必ず通る（通らなければならない）第１のファイアウォールを備えてもよい。その場合、第１のファイアウォールは第１のローカル端末と共有されたネットワークとの間のあるタイプの通信を制限し、かつ第１のプロキシインターフェイスエージェントと外部サーバとの間の通信は制限しないように構成される。
【００５１】
外部サーバのトランスポートアドレスの少なくとも一つは、少なくとも一つのあらかじめ割り当てられたポート（これは「よく知られた（well-known）」ポートと呼ばれる場合もある）を含んでいる。そして、第１のプロキシインターフェイスエージェントから外部サーバへ向かうアウトバウンドコネクションは上記のあらかじめ割り当てられたポートを用いる。
【００５２】
好適には、第１のプロキシインターフェイスエージェントから外部サーバへの上記のアウトバウンドコネクションが接続する外部サーバのすべてのトランスポートアドレスはあらかじめ割り当てられたポートを有する。この場合、外部サーバのすべてのトランスポートアドレスは最大で２つのあらかじめ割り当てられたポートを有してよい。
【００５３】
外部サーバのあらかじめ割り当てられたポートの数は端末に動的に割り当てられたポートの総数以下である。たとえば外部サーバは３つのあらかじめ割り当てられたポートを有してよく、そのうち一つはTCP用で、２つはUDP用である。
【００５４】
この通信システムは第２のローカル端末を含んでもよく、外部サーバは第１の端末と第２の端末の間で通信セッションの期間、各端末に対して他方の端末のプロキシ（代理）として動作するプロキシサーバである。
【００５５】
多くの場合、通信セッションが必ず通過する第２のファイアウォールおよび／または第２のNATを有する第２のローカル端末が存在する。そして第２のファイアウォールは第２の端末と共有されたネットワークとの間のあるタイプの通信を制限するように構成される。外部サーバは端末と通信するための論理通信ポートを有し、該論理通信ポートは第２の端末と通信するための１つ以上のあらかじめ割り当てられたポートを含んでいる。そのとき第２のファイアウォールは第２の端末とプロキシサーバのあらかじめ割り当てられたポートとの間の通信は制限しないように構成してよく、かつ第２のプロキシインターフェイスエージェントを配備して外部サーバとの通信において第２の端末の代理として動作するようにする。第２のローカル端末は上に述べたものと同様の手順により、第２のプロキシインターフェイスエージェントとの通信セッションに従事するようにできる。
【００５６】
また、第２の端末および第２のプロキシインターフェイスエージェントは第２の外部サーバと接続するようにしてもよい。外部サーバは公共の、即ち共有されたネットワークを介して通信する。
【００５７】
共有された通信ネットワークは一般的に公共の通信ネットワークおよび／またはインターネットを含む。
【００５８】
プロキシインターフェイスエージェントはローカル端末と同じ場所にあってもよいし、あるいはローカル端末から離れたところにあってもよい。
【００５９】
本発明はプロキシインターフェイスエージェント毎に２つ以上のローカル端末がある場合にも有用である。その場合、プロキシインターフェイスエージェントは同一のあるいは異なるリアルタイム（または非リアルタイム）プロトコルを用いて（たとえばH.323とSIPの両方を用いて）複数の端末を同時に代理して動作することができる。好適には、シグナリングゲートウェイ機能（signaling gateway functionality）（たとえばH.323とSIPとの間の）を外部サーバまたはプロキシインターフェイスエージェントのいずれかの内に設ける。
【００６０】
プロキシインターフェイスエージェントおよび外部サーバによって、エンドポイントからは不可視のその他の付加的な特徴および機能性（たとえばQOSおよび／または暗号化によるセキュリティ）を付加してもよい。
【００６１】
このようなシステムは国際電気通信連合（ITU）のH.323スタンダードによる音声呼またはマルチメディア呼を行うために用いることができる。またはこのシステムをインターネット・エンジニアリング・タスク・フォースのSIPスタンダードによる音声呼またはマルチメディア呼に用いてもよい。このようなシステムおよび方法はまた、たとえばファイル転送などの、リアルタイムプロトコルを用いたファイアウォールおよびNATを介した他のタイプの通信セッションであって、動作する際にNAT機能によって変更されないトランスポートアドレスによって識別される論理チャネルの動的な設定をおこなうような通信セッションの設定に用いてもよい。またこの通信システムは混在するプロトコル環境をサポートするようにしてもよい。
【００６２】
プロキシインターフェイスエージェントはエンドポイントと同じ場所にあってもよいし、それが代理として動作するエンドポイントとは別のデバイス内に設けてもよい。
【００６３】
端末はマルチメディア信号を関連するマルチメディア制御信号と共に送信および／または受信するように構成し、制御信号はあらかじめ割り当てられたポートの一つに送り、メディア信号はその他のあらかじめ割り当てられたポートに送るように構成してもよい。
【００６４】
好適には少なくとも一つの論理通信ポートはあらかじめ割り当てられたポートであり、前記要求は通信セッションを開始する開始要求としてあらかじめ割り当てられたポートに送られる。
【００６５】
通信手段は音声呼またはマルチメディア呼を少なくとも部分的にはインターネットを介して行うように構成することができ、その場合、外部サーバはパブリックなインターネットプロトコルアドレスを有し、それによって一方または両方の端末が外部サーバと通信し、ファイアウォールは端末と外部サーバのあらかじめ割り当てられたポートとの間の通信は制限しないように構成される。
【００６６】
本発明は１つ以上の第１端末の組および第２端末の組が存在する場合に適用できる。たとえば一つのサイトにあるいくつかの第１の音声またはマルチメディア端末のそれぞれが他の様々なサイトの対応する他の第２の音声またはマルチメディア端末に接続することができる。
【００６７】
本発明により、別個のプライベートネットワーク内にある２つの端末が共通の公共ネットワーク（即ち共有されたネットワーク）を介して通信することが可能となり、その際プライベートネットワークの一方または両方はあるタイプの通信を制限するファイアウォールおよび／またはNATを介して公共ネットワークに接続される。同様に、本発明によりプライベートネットワーク内の一つの端末が公共ネットワークの端末と通信することが可能となり、その際２つのネットワークはあるタイプの通信を制限するファイアウォールおよび／またはNATを介して接続される。
【００６８】
本発明の説明は、ここで第１のローカル端末と呼んでいる第１のエンドポイントとここで外部サーバと呼んでいる媒介サーバとの間の動作のみについて行う。しかし第２の端末と外部サーバとの間の動作は第１の端末と外部サーバとの間の動作と同様である。また、第２の端末が公共ネットワークに直接接続される場合というのは、該端末がファイアウォールおよびNAT設備が全く何も機能しないプライベートネットワークに接続される場合と等価になる。つまりそれは、ファイアウォールがどんなコネクションも制限せず、またNATが与えられたコネクションに対して変換の両側（前後）で同じアドレスを用いる場合である。
【００６９】
本発明では、共有された即ち公共の（パブリック）ネットワーク内の外部サーバとプライベートネットワーク内のプロキシインターフェイスエージェントとを配備する。外部サーバは公共のサービスプロバイダによって所有され運営されるものであってよい。従ってそれは典型的にはある企業がプライベート／パブリック（公共）のネットワーク境界を通過してH.323通信を展開しようとする前に、すでに配備されていることであろう。プロキシインターフェイスエージェントは端末の一部として設けられてもよいし、端末と同じデバイス上で動作するが端末の実行とは独立させるようにしてもよく、さらにまた別個のデバイスにインストールしてもよい。
【００７０】
プロキシインターフェイスエージェントは有効（オン）となると、外部サーバへのTCPコネクションを確立する。このコネクションはファイアウォールおよびNATのいずれかまたは両方が備わっている場合にはそれらの一方または両方を介して行われることになる。そのため、ファイアウォールは外部サーバのアドレスおよびよく知られたポートへの外向きの（発信方向の）TCPコネクションを許容する必要がある。NATはプライベートからパブリックへのアドレスマッピング（そしてその逆も）を施すことができる。なぜならコネクションがアウトバウンド方向（発信方向）に形成されたからである。設定プロセスの一部として、外部サーバは自身をプロキシインターフェイスエージェントに対して認証してよく、かつ接続を暗号化してよい。このコネクション上で動作するプロトコルは複数のシグナリングプロトコルの多重化を許容する。このようなシグナリングプロトコルとしてはH.225 RAS、H.225コールシグナリング、H.245、SIPがあるが、これらに限られるものではない。このコネクションは実に、TCPコネクションの性能特性で間に合うすべての第１のローカル端末−外部サーバ間の通信に対して十分なものである。ひとたび確立されてしまえば、この多重化されたコネクションは、外向きまたは内向きの呼試行がなされるまでの間、定期的な登録メッセージをのぞいては大部分休眠状態となる。セキュリティを更に高めるために、このコネクションの設定を継続的に行い、一定の（短い）間隔でコネクションを切るようにしてもよい。コネクションの設定の度毎にNAT機能において異なるポート割り当てがなされ、かつ暗号化キーが更新される可能性がある。従って攻撃者がこのコネクションを利用する可能性が低減される。
【００７１】
しかしながら多重化コネクションのトランスポート特性はオーディオおよびビデオのようなリアルタイムメディアにはふさわしいものではない。これらのメディアには、プロキシインターフェイスエージェントと外部サーバとの間にUDPベースのRTP/RTCPコネクションを確立することが必要となる。インバウンドおよびアウトバウンド両方のRTP/RTCPコネクションについて、両方向のUDPトラフィックが必要である。外部サーバを介して端末から公共ネットワークにメディアを送るために、外部サーバは端末に（多重化されたコネクションを用いてプロキシインターフェイスエージェントを介して）端末がそのメディアをプロキシインターフェイスエージェントに送るよう指令するH.323メッセージを送る。（これはH.323メッセージの様々なデータフィールドに、端末とプロキシインターフェイスエージェントとがH.323呼の両エンドであるような見かけを与えるアドレスおよびポートの値を入れることにより、スタンダードなH.323プロセスを用いて行うことができる。）続いてプロキシインターフェイスエージェントはファイアウォールおよび／またはNATを介して外部サーバへ向かうおよび外部サーバからやって来る両方のUDPデータ交換を確立しなければならない。
【００７２】
基本的には、プロキシインターフェイスエージェントは単に外部サーバのアドレスおよびよく知られたポートにUDPパケットを送るだけで、外部サーバへのUDPコネクションを確立することができる。ファイアウォールはこのトラフィックを通過させるように設定でき、またコネクションがアウトバウンド方向に形成されるのでNATはプライベートからパブリックへのアドレスマッピングを行うことができる。しかしながら（外部サーバのように）多くのUDPコネクションを伴う複数の呼を処理するデバイスは、一般的にIP送信先アドレスおよびポート、および／または、IP送信元アドレスおよびポートを用いてUDP情報を適切な呼と関連付けする。この外部サーバの場合、すべてのUDPデータはファイアウォールの通過を許可されるために、同一のIPアドレスおよびよく知られたポートに送られなければならない。従って、様々なUDPコネクションを区別するためにIP送信先アドレスおよびポートを用いることはできない。また、外部サーバの視点から見れば、NATはそれが送るUDPパケットに事実上ランダムに送信元IPアドレスを割り当てていることになる。この結果、外部サーバにやってくるUDPデータのIP送信元アドレスおよびポートは外部サーバ（あるいはプロキシインターフェイスエージェント）が様々なシグナリングチャネルを通じて取り決めていたメディアチャネルのいずれとも対応することがない。
【００７３】
この関連付けの問題を解決するために、外部サーバ（あるいはプロキシインターフェイスエージェント）はプロキシインターフェイスエージェントに、その接続に対して以降にプロキシインターフェイスエージェントがUDPデータを送るであろう同じIP送信元および送信先アドレスおよびポートを用いてプローブパケットを外部サーバに送るように（TCPベースの多重化されたコネクションを介して）指令する。プローブパケットは外部サーバ（あるいはプロキシインターフェイスエージェント）によって選択された固有のトークンを含んでおり、これにより外部サーバは受け取ったプローブパケットを適切なUDPコネクションと関連付けることができる。そして更に、外部サーバはプローブパケットのIP送信元および送信先アドレスおよびポートをUDPコネクションと関連付けることができる。このアドレスおよびポート情報を得たことにより、外部サーバはこれらのIPアドレスおよびポートで以降に受け取るUDPデータを、適切な呼と関連付け、外部サーバが送信先通信システムへおよび送信先通信システムから正しく転送できるようにすることができる。本発明の別の実施形態では、トークン情報は送信される各UDPパケットと共に多重化することができる。また、複数の論理チャネルを同じUDPコネクション上に多重化することができる。このような手法の利点はプロキシインターフェイスエージェントにおけるポートの使用を維持することである。もう一つの利点は、通常はすべてのRTP/RTCPパケットに乗って送られるUDPヘッダ情報によってとられる帯域幅を節約することである。論理チャネルを多重化することによって使用されるTCPおよびUDPコネクションの数が少なくなれば、それらのコネクションをプロキシインターフェイスエージェントのあらかじめ割り当てられたポートまたはよく知られたポートに配置することができる。これにより、ファイアウォール規則をより狭めることが可能となる。
【００７４】
データを外部サーバからプロキシインターフェイスエージェントに送るためには、NATにおいてプライベートからパブリックへのアドレスマッピングが必要である。これは普通一対多のマッピングであるので、NATは一般的にそうしたマッピングを動的に行うことはできない。しかし、プロキシインターフェイスエージェントから外部サーバへの外向き（発信方向）UDPコネクションを行うときに確立されるネットワーク経路は実際上本来双方向的であると考えられる。従って、外部サーバからプロキシインターフェイスエージェントへのUDPコネクションを確立するためには、プロキシインターフェイスエージェントから外部サーバへのUDPコネクションを確立するのと同じ手順がとられる。しかし、アドレスとポートの関連付けがなされてしまえば、外部サーバはこの情報をUDPデータを受け取るのではなく送るために用いる。その後プロキシインターフェイスエージェントがUDPデータを端末に送る。適切なアドレスおよびポート値を用いたスタンダードなH.323シグナリングを用いて、プロキシインターフェイスエージェントからUDPデータを受け取るよう端末を設定することができる。
【００７５】
以上に説明したように、第１のプロキシインターフェイスエージェントおよび外部サーバにより、第１の端末がNATおよびファイアウォールを介して、それらのNATおよびファイアウォールを改変することなく送信先通信システムと通信することを可能にする通信システムおよび通信方法が提供される。これは以下によって成し遂げられる、即ち：
ａ）  端末が第１のプロキシインターフェイスエージェントとあたかもそれが送信先の通信システムであるかのように通信しかつ送信先通信システムが外部サーバとそれがあたかも第１の端末であるかのように通信するように、プロトコル（H.323やSIPなど）内のアドレスを変更すること、および
ｂ）  １）第１の端末の用いる論理チャネルと、２）第１のプロキシインターフェイスエージェントから外部サーバへ至る識別可能な論理チャネルであって第１のプロキシインターフェイスエージェントから外部サーバへの動的なアウトバウンドコネクションにおいて設定される識別可能な論理チャネルと、３）外部サーバと送信先通信システムとの間の論理チャネルと、の関連付けを動的に行うこと、である。
【００７６】
プロトコル内のアドレスの変更は外部サーバによって行ってもよいし、第１のプロキシインターフェイスエージェントによって行ってもよく、またはそれら両方によって行ってもよい。この変更が行われるときはいつも、上記の動的な関連付けを行うことができるように、第１のプロキシインターフェイスエージェントと外部サーバとの間で要求および指令が通信される必要がある。要求と指令は第１のプロキシインターフェイスエージェント（クライアント）および外部サーバ（サーバ）の間のクライアント−サーバ・プロトコル内で送られる。このクライアント−サーバ・プロトコルは第１のプロキシインターフェイスエージェントから外部サーバへのアウトバウンドコネクションにおいて開かれる制御チャネル上において伝送される。
【００７７】
外部サーバがプロトコルのアドレス変更を行う場合には、外部サーバをクライアント−サーバ・プロトコルのマスターと言い、第１のプロキシインターフェイスエージェントをスレーブと言う。
【００７８】
また第１のプロキシインターフェイスエージェントがプロトコルのアドレス変更を行う場合には、第１のプロキシインターフェイスエージェントをクライアント−サーバ・プロトコルのマスターと言い外部サーバをスレーブと言う。
【００７９】
第１のプロキシインターフェイスエージェントおよび外部サーバの両方がプロトコルの変更を行う場合、一方がマスターとなり他方がスレーブとなるよう両者で取り決めるかまたはそのように構成しておくことができる。
【００８０】
１つ以上の呼についての第１のプロキシインターフェイスエージェントからの１つ以上のアウトバウンドコネクションが外部サーバの同一のトランスポートアドレスに届くこと、およびそれらのアウトバウンド接続はそのアウトバウンドコネクションの送信元アドレスをランダム化する１つ以上のNATを通過しているであろうことから、上記アウトバウンドコネクションを確立するために既知の識別子を含むプローブパケットを用いる。該識別子は第１のプロキシインターフェイスエージェントと外部サーバとの間（またはその逆）で交換される。この識別子によって、外部サーバは必要な関連付けを完遂することができ、呼を送信先通信システムへまた送信先通信システムから正しく転送することができる。
【００８１】
完全なH.323アップグレードに代わるものの一例を、図１を参照して説明する。この図は第１の企業２と第２の企業４を含む通信システム１を示す。各企業はプライベートネットワーク６，８を有しており、それらネットワークは共に一つ以上のH.323端末１０，１２を有している。各プライベートネットワーク６，８は共に、同じ10.x.x.xアドレスレンジ内のプライベートIPアドレス１４，１６を有している。プライベートIPアドレス１４，１６は静的（固定的）に割り当てられたものであってもよいし、通常のDHCPプロセスによって動的（流動的）に割り当てられたものであってもよい。プライベートネットワーク６，８内には端末１０，１２をそれぞれ代理して動作するプロキシインターフェイスエージェント（proxy interface agent：プロキシインターフェイス代理装置）１１，１３が含まれている。プロキシインターフェイスエージェントが、それぞれに対応する端末と同じ場所にない場合には、プロキシインターフェイスエージェントはそれぞれに対応するプライベートネットワーク１４，１６のレンジ内の唯一固有のIPアドレスを有するものとする。そのような場合、各プロキシインターフェイスエージェント１１，１３は複数の端末１０，１２の代理として動作してもよい。図１においては、プロキシインターフェイスエージェントが同じ場所にある場合を示しており、また図２はプロキシインターフェイスエージェントが同じ場所にない場合を示している。外部通信は共有されたあるいは管理されたあるいは公共のインターネット２０を介して行われる。外部通信用として、第１の企業２はたとえば192.1.1.1に始まるレンジの１つ以上のパブリックIPアドレス２２を有し、第２の企業４はたとえば206.1.1.1に始まるレンジの１つ以上のパブリックIPアドレス２４を有する。各企業はルータ３２，３４を有しており、該ルータ３２，３４はネットワークアドレスポート変換を行って、内部IPアドレス１４，１６およびそれらアドレス（プライベート）上のポート番号と外部IPアドレス２２，２４の内の一つおよび選択されたそのIPアドレス（パブリック）上のポート番号とのマッピング（対応付け）をおこなう。
【００８２】
各プライベートネットワーク６，８はオプションとして、それらの端部においてファイアウォール機能２６，２８によって保護される。ファイアウォール機能は表１に示す規則によって構成されH.323などをベースとするリアルタイム通信を許容する。この規則は先行する発明によって提案された２つ以上の新たなよく知られたポート(well known port)を取り入れており、それらの新たなよく知られたポートはX,Y,Zで示している。ポートZは実際にはXまたはYのいずれかと等しくてもよい。
【００８３】
【表１】
0003757399.tif 000002
【００８４】
表１に示したポート番号X,Y,Zは理想的にはIANAによって合意されたスタンダードに従って登録されたポート番号である。これらのポートが業界のスタンダードなポートであることの利点は、ファイアウォールなどの媒介装置が関連メディアがリアルタイムトラフィックであることを認識し、それを適切に取り扱うことができることである。たとえば、ルータが遅延を最小にするように当該トラフィックに上位の優先性を与える、といったことができる。
【００８５】
第１の企業２のH.323端末１０が第２の企業４の他のH.323端末１２と通信するためには、外部サーバ４０がたとえばルータ３８を介して接続されている共有されたネットワーク２０が存在しなければならない。外部サーバ４０はたとえば45.6.7.8というパブリックのIPアドレス４４を有する。外部サーバ４４はまた、よく知られたポート番号X,Y,Z４６を有している。これらよく知られたポート番号は、あらかじめIANAにおいて合意され登録されていなければならない。
【００８６】
図３は第１の端末、第１のプロキシインターフェイス１１、第１のファイアウォール２６、第１のNAPTルータ３２および外部サーバ４０に着目した様々な要素間の通信経路を示している。この図には、プロキシインターフェイスエージェント１１と外部サーバ４０との間のファイアウォール２６およびNAPTルータ３２を介した多重コネクション５１が示されている。この多重コネクション５１内には１つ以上の論理チャネル５２，５３がある。それらのうちの一つは制御チャネル５２であり、それ以外のチャネル５３はH.225 RAS、H.225コールシグナリング、H.245、SIP、MGCPなどのシグナリングプロトコルを伝送している。その動作の一部を以下に説明するが、プロキシインターフェイスエージェント１１は外部サーバにプローブパケット（probe packets）５５を送り、端末１０と外部サーバ４０との間のUDPコネクション５６，５７を確立する。１つ以上の論理チャネルをUDPコネクション５６，５７内に多重化し、たとえばRTPおよびRTCPをなどのメディアを伝送するようにしてもよい。
【００８７】
プロキシインターフェイスエージェント１１は、動作条件に応じて数あるモードの一つで動作するようにできる。プロキシインターフェイスエージェント１１は原理的にプロトコルを認識しないか(protocol agnostic)認識するか(protocol aware)のいずれかでありうる。プロトコルを認識しない場合には、外部サーバ４０はプロキシインターフェイスエージェント１１に任意の必要なUDPソケットを開閉するように命じる。このモードは最も柔軟なモードであり、プロキシインターフェイスエージェント１１をアップグレードすることなしに、プライベートネットワークに加える新たなプロトコルを端末が採用することを可能にするものである。しかしながら、払うべき注意を怠れば、このモードはセキュリティを脅かすものとなる。なぜなら、第三者が不法な目的でプロキシインターフェイスエージェントにUDPチャネルを開かせることができるかもしれないからである。そのためこのモードを採用する場合には、最低限プロキシインターフェイスエージェント１１が何らかのチェック（監査）を行うようにすることが推奨される。プロキシインターフェイスエージェント１１がプロトコルを認識する場合には、外部サーバ４０に命じられた際にポートを割り当てることができるが、それらポートが承認されたアプリケーションに用いられることを示す適宜のプロトコルシグナリングを認めるまではリレー（中継）機能を行うことができない。更に、プロキシインターフェイスエージェントがプロトコルを認識する場合には、外部サーバはプロトコルを認識するものである必要がない。なぜなら、その場合プロキシインターフェイスエージェントが、外部サーバに必要な関連づけを行うよう要求するすべてのインテリジェンスを有しているからであり、従ってプロキシインターフェイスエージェントはプロキシインターフェイスエージェントから外部サーバへのアウトバウンドコネクションにおいて設定される論理チャネルと送信先の通信システムとの間の正しい転送（即ち呼）を提供する。このモードは安全性において勝るが、新たなアプリケーションを導入する場合またはアプリケーションをアップグレードする場合の柔軟性において劣っている。簡便化するため、以下に説明する例ではプロキシインターフェイスエージェント１１はプロトコルを認識しないモードで動作するものと仮定する。
【００８８】
プロキシインターフェイスエージェント１１が有効になされると、プロキシインターフェイスエージェント１１は外部サーバのアドレスおよびポート４４，４６へのアウトバウンドTCPコネクションを開始することによって外部サーバ４０への通信チャネルとしての多重コネクション５１を確立する（このコネクションは、一般的に認証式とされまた暗号化されるものであるが、こうした点は本明細書で述べるべき範囲を越えている。）
【００８９】
多重コネクション５１は複数のTCPおよびUDPセッション５２，５３に関する情報をトランスポート可能である。多重コネクション５１内のいくつかの論理チャネル、特に制御チャネル５２は固定的に割り当てられる。他の論理チャネルは必要に応じて動的に作成することができる。いくつかの論理チャネル５３はプロキシインターフェイスエージェント１１によって端末１０へ／端末１０からリレーされる。プロキシインターフェイスエージェント１１は（構成によっては外部サーバが）このような論理チャネルの各々に対して、プロキシインターフェイスエージェント１１と端末１０との間で用いられる特定のTCPまたはUDPコネクションのIPアドレスおよびポートを関連付けする。言い換えると、プロキシインターフェイスエージェントは端末の一つのトランスポートアドレスと一つの論理チャネルの自分側端部のトランスポートアドレスとの間の関連付けを行う。
【００９０】
初期設定の一部として、外部サーバ４０はプロキシインターフェイスエージェント１１にソケットを作成させ端末１０からの外向き呼試行（outgoing call attempts）および登録情報を待ち受けるようにしてもよい。
【００９１】
端末１０がその後ゲートキーパ／サーバに登録しようとする場合、そのようなメッセージ（H.225 RAS、SIP REGISTERなど）がプロキシインターフェイスエージェント１１に送られる。プロキシインターフェイスエージェント１１は論理チャネル５２，５３を介して外部サーバ４０に登録メッセージを転送する。応答は逆の経路を用いて送られる。外部サーバ４０は端末のプライベートトランスポートアドレス１４を、該登録が受理された多重コネクション５１の識別(identity)即ちトランスポートアドレスと共に記憶する。この情報があれば着信呼(incoming call)を必要に応じて端末に転送することができる。
【００９２】
着信呼を確立するためには、外部サーバ４０はプロキシインターフェイスエージェント１１を介して端末１０へ向かう呼制御チャネル（H.323またはSIPに対するH.225呼制御）を設定する必要がある。外部サーバ４０とプロキシインターフェイスエージェント１１との間に適宜の論理チャネル５３が存在していない場合には、そのような論理チャネルが作例される(instantiated)。このプロセスの一部として、プロキシインターフェイスエージェント１１がそれに対してTCPまたはUDPコネクション５４を作成すべき端末のトランスポートアドレス（IPアドレスおよびポート）が特定される。論理チャネル５３を作成するために必要なメッセージが外部サーバ４０とプロキシインターフェイスエージェント１１との間で制御論理チャネル５２を用いて交換される。
【００９３】
呼制御シグナリング用の論理チャネルが形成されたなら、外部サーバ４０はH.323/SIP呼生成メッセージ（H.323/SIP create call message）(H.323用のSetup、SIP用のINVITEなど)をプロキシインターフェイスエージェント１１に送ることができる。そしてプロキシインターフェイスエージェントは、論理チャネル５３が形成された際に確立したTCPまたはUDPコネクション５４を用いて、このメッセージを端末１０にリレーする。
【００９４】
H.323の場合には、外部サーバ４０と端末１０との間にH.245コネクションを確立する必要があるだろう。このコネクションが接続される端末内のアドレスは端末１０が外部サーバ４０に送り返す応答に含まれる。外部サーバ４０がこのようなH.245セッションを確立することを選択する場合には外部サーバ４０は呼シグナリングチャネルを作成したのと同じ手法で新たな論理チャネル５３を作成する。このプロセスの一部として、プロキシインターフェイスエージェント１１は端末の応答中で特定されたプライベートIPアドレスおよびポートに対するTCPコネクションを確立する。
【００９５】
端末１０がプロキシインターフェイスエージェント１１に接続し、呼生成メッセージ(H.323用のSetup、SIP用のINVITEなど)を送る際には、発信呼(outgoing call)に対するシグナリング経路が端末１０と外部サーバ４０間に形成され得る。この種のコネクション用の論理チャネルが多重コネクション５１内に存在していない場合は、プロキシインターフェイスエージェント１１が制御チャネル５２を用いてそのような論理チャネルを作成する。そしてプロキシインターフェイスエージェント１１はメッセージを外部サーバ４０にリレーする。
【００９６】
別個のH.245コネクションが発信呼に必要な場合は、外部サーバ４０は多重コネクション５１内に新たな論理チャネル５３を形成し、プロキシインターフェイスエージェント１１に待ち受けソケット（listening socket）を作成するよう指令する。作成されたソケットのアドレスとポートの数値は外部サーバ４０に返送される。なおこれはセットアップメッセージ（Setup message）に応答して送られるH.323シグナリングに含まれる。この情報により、端末１０がプロキシインターフェイスエージェント１１の作成した待ち受けソケットに接続することが可能になる。
【００９７】
ひとたび必要な着信および発信呼制御経路が設定されたならば、アウトバウンドおよびインバウンドのメディア経路（media paths）を設定することが必要となるであろう。前に述べたように、現在規定されているすべてのIPベースのメディアアプリケーション（H.323、SIP、MGCPを含む）のメディア経路はRTPを用いている。RTPはUDPに基づいており、一方向RTPコネクションは送り方向と反対方向両方のUDP経路（UDPパス）の設定を要求する。従って、端末１０からプロキシインターフェイスエージェント１１を介して外部サーバ４０に至るUDP経路、および外部サーバ４０からまたプロキシインターフェイスエージェント１１を介して端末１０へ至るUDP経路を設定する必要がある。更に、RTPおよびRTCPコネクションはそれらが用いるポート間に固定した関係を要求する。従って、一度に単一のポートを開くことが可能であるのみならず、必要とされるRTP/RTCPポート番号関係を有するUDPポート対（複数）を開くことが可能である必要がある。従って、以下の説明では単一の接続を開くことを説明しているが、同様の原理を、同時にポート対（複数）を要求し、開くことに用いることができる。
【００９８】
以下の説明においては、H.323プロトコルを用いるものと仮定している。プロトコルメッセージと制御メッセージとのシーケンスは他のプロトコル（SIPやMGCPなど）では異なったものとなりうるが、原理は同一である。
【００９９】
端末１０と外部サーバ４０との間にUDP経路を設定するために、外部サーバ４０はプロキシインターフェイスエージェント１１に、端末１０が接続可能なUDPポート（あるいはポート対）を開くよう指令する。外部サーバ４０はまたプロキシインターフェイスエージェント１１がコネクションと関連付けるべきトークン(token)を特定する。
【０１００】
ポートが首尾よく開くと、プロキシインターフェイスエージェント１１は外部サーバ４０にポートの識別(identity)を示す。次に外部サーバは、端末１０がそのUDPデータを送るべきプロキシインターフェイスエージェント１１のプライベートIPアドレスおよびポートを含むメディアチャネルを開くのに必要なシグナリングコマンドを発する（たとえばH.323の場合にはH.245開論理チャネル）。このコマンド（命令）を受信すると、プロキシインターフェイスエージェントは該コマンドをこの目的のためにあらかじめ確立されていたコネクションを用いて端末にリレーする。
【０１０１】
かくして端末１０はプロキシインターフェイスエージェント１１にRTP、RTCP、UDPパケット５６を送り始めることができる。しかし、これらのパケットを外部サーバ４０に転送する前に、プロキシインターフェイスエージェント１１はコネクションが最初に形成された時に外部サーバ４０によって特定されたトークンを含むプローブパケット５５を送らなければならない。NAPTにおいてプライベートからパブリックへのアドレスマッピング（アドレスの対応付け）が作成されることに加えて、トークンの存在により、外部サーバ４０はこれらプローブパケット５５のソースから受け取ったUDPパケット５７を正しい論理メディアチャネルと関連付けることができる。なお、プローブパケット５５を送るのが早すぎると、メディアデータ５６を送らないうちにNATによって作成されたアドレスマッピングがタイムアウトとなってしまうので、プローブパケット５５の送信をできる限り遅らせたほうがよい。また、プローブパケット５５はUDPであるので、失われることがあり得ることに注意する必要がある。従って所与のコネクションに対して２つ以上のプローブパケット５５を送る機能を持つ必要がある。ひとたびプローブパケット５５が送られると、プロキシインターフェイスエージェントは受信したUDPデータを外部サーバ４０にリレーすることができる（５７として示される）。別のやり方としては、トークン情報を、送られる各UDPパケットに多重化することもできる。更に、複数の論理チャネルを１つ以上のUDPコネクションに多重化してもよい。
【０１０２】
動作方法はインバウンドUDPコネクションに対しても同様である。外部サーバ４０プロキシインターフェイスエージェント１１に対して端末１０にUDPデータを送ることのできるポート（あるいはポート対）を開くよう指令する。プロキシインターフェイスエージェント１１は外部サーバ４０にこのポートの識別(identity)を知らせる。そこで外部サーバはこの情報を、プロキシインターフェイスエージェント１１を介して端末１０に送られるメディアチャネルを開かせるためのプロトコル特定シグナリングコマンド(protocol specific signaling command)の中に含ませる（たとえばH.323の場合はH.245開論理チャネル）。端末１０はこのコマンドに応答してそのコネクションにおいてUDPデータを受信しようとするプライベートIPアドレスおよびポートを与える。このメッセージは外部サーバ４０へとリレー返送される。そこで外部サーバ４０はプロキシインターフェイスエージェント１１に、このコネクションにおいてプロキシインターフェイスエージェントがUDPデータをリレーすべきアドレスを知らせる。更に、NATにおけるパブリック対プライベートのアドレスマッピングを作成するために、外部サーバ４０はプロキシインターフェイスエージェント１１がトークンを含む当該コネクションについてのプローブパケット５５を外部サーバ４０に送ることを要求する。これによりプライベートからパブリックへのアドレスマッピングが作成され、そしてそれはまた逆方向に送られるデータのためのパブリックからプライベートへのアドレスマッピングとして機能する。外部サーバ４０はプローブパケット５５内のトークンを用いてこのセッション５７に対してどのNATアドレスおよびポートにUDPデータを送るべきかを決定する。こうして外部サーバ４０はこのアドレスにUDPメディアを送ることができるようになる。NATはこれをプロキシインターフェイスエージェント１１にリレーし、そして今度はプロキシインターフェイスエージェント１１がこれを端末１０にリレーする（５６として示される）。かくしてコネクションが完了する。
【０１０３】
UDPコネクションがこれ以上要求されない場合、外部サーバ４０はプロキシインターフェイスエージェント１１に関連するソケットを閉じるように指令する。NAPTのプライベートからパブリックへのアドレスマッピングは、情報が通過しないと、いずれタイムアウトとなる。
【０１０４】
以上の説明では外部サーバが単一のIPアドレスを有する単一のデバイスであると仮定したが、本発明の別の実施形態では「外部サーバ」は協働するいくつかのデバイスであってもよい。また、各外部サーバデバイス（単数または複数）は１つあるいは複数のIPアドレスを有してよい。複数のIPアドレスを用いる場合には、普通にはそれらを単一のサブネットから割り当て、そしてファイアウォール規則を個々のIPアドレスではなくサブネットの出入りに許容されたポートを特定するものとなるようにプログラミングする。
【０１０５】
なお、H.323端末のプライベートIPアドレスおよびポート番号は、実際上それがマッピングされるパブリックIPアドレスおよびポート番号と同一であってもよい。この場合マッピングは素通し(transparent)となる。
【０１０６】
以上に説明した解決の利点は以下の通りである：
・NATおよびファイアウォール機能をアップグレードする必要がない。
・信号の待ち時間が最小になる。
・各組織で必要となるのはプロトコルを認識しないプロキシインターフェイスエージェント（一つまたは複数）のみであり、そしてそれはどの適宜のリアルタイムプロトコルとも一緒に用いることができる。
・企業のIPアドレス（１つまたは複数）はその企業に対して呼を行うプロセスにおいて公知となることがない。
・サービス品質およびその他の使用法に基づく方針（たとえば帯域幅の利用）を断片的に行うことができ、首尾一貫した単一の解決手段を必要としない。たとえば、外部サーバはプロキシインターフェイスエージェントに対して、或るQOSレベルの呼内のメディアストリームをプロキシインターフェイスエージェントと外部サーバとの間のコネクションに対して適切な方法を用いて処理するように指令し、そして外部サーバはそれをコアネットワーク内で外部サーバが獲得できる対応するQOSレベルに対して対応付けすることができる。同様に、プロキシインターフェイスエージェントと外部サーバとの間において、呼の他の部分（区間(legs)）に対して用いられるセキュリティ機構とは独立にある暗号化方式を用いてもよい。
【０１０７】
総括すれば、本発明はプライベートネットワーク内に配置されたH.323（あるいはその他のリアルタイムプロトコルに適合するエンドポイント）端末を許容する方法およびシステムであって：既存のセキュリティ手続きおよびセキュリティ方法を損なうことがなく；既存のファイアウォール、ルータ、プロキシをアップグレードする必要がなく；使用されている通信プロトコルを解釈するまたは認識するNAT機能なしにIP接続に完全なNATを適用することを許容するようなものを提供する。本発明はまた、一つのプライベートネットワーク内にあるスタンダードなH.323装置が同じプライベートネットワークまたは異なるプライベートネットワークおよび／または公共の（パブリックな）IPネットワーク内の他のH.323端末と、共有された即ち公共のIPネットワークを用いて、プロトコルに依存しないプロキシインターフェイスエージェントおよびH.323プロキシサーバを介して通信することを可能にするものである。
【０１０８】
従って事業体は共有されたIPネットワークの共有されたリソースを加入契約利用することができる。コストは最小限のものであり、セキュリティが損なわれることもない。
【図面の簡単な説明】
【図１】  ２つの企業間において音声呼またはマルチメディア呼を行うための本発明による通信システムの図式的な説明図であり、プロキシインターフェイスエージェントがエンドポイントと同じ場所にある場合を示している。
【図２】  図１と同様の図式的説明図であるが、プロキシインターフェイスエージェントがエンドポイントから離れたところにある点で相違している。
【図３】  図１および図２に示す通信システムの図式的説明図であり、アウトバウンド通信およびインバウンド通信の両方に対するアウトバウンド接続の論理チャネルを、一つの企業のローカル端末と外部サーバの間について示す図である。
【図１】
0003757399.tif 000003
【図２】
0003757399.tif 000004
【図３】
0003757399.tif 000005