JP2004515164A - 通信システム - Google Patents

Abstract

本発明はマルチメディア呼や音声呼を例とする通信セッションを処理するための通信システム（１）に関わる。通信システム（１）はローカル端末（１０）、外部サーバ（４０）、端末（１０）と共有されたネットワーク（２０）との間のプロキシインターフェイスエージェント（ＰＩＡ）（１１）を含む。通信手段は通信セッションが必ず通過するＮＡＴ機能を備えている。通信セッションはネットワーク（２０）上で端末（１０）と外部サーバ（４０）との間の１つ以上の論理チャネルを用いて行われ、その間、第１のＮＡＴ機能（３２）は端末のトランスポートアドレス（１４）に対してネットワークアドレスマッピングを行う。ＰＩＡ（１１）は外部サーバ（４０）との通信において端末の代理として動作し、サーバへのアウトバウンドコネクションの論理チャネルを設定する。これはＰＩＡ（１１）とサーバ（４０）との間の制御チャネルとなる。ＰＩＡ（１１）はサーバ（４０）への動的なアウトバウンドコネクションを確立し、サーバからの要求に応じて、あるいはＰＩＡ自身（１１）からの要求に応じて、端末のトランスポートアドレス（１４）とＰＩＡ−サーバ間の識別可能な論理チャンネルとの間の１つ以上の関連付けを行う。これらの識別可能な論理チャネルはＰＩＡ（１１）からサーバ（４０）への１つ以上の動的なアウトバウンドコネクションによって設定される。
【選択図】図１

Description

【０００１】
本発明はマルチメディア呼（ｍｕｌｔｉｍｅｄｉａ ｃａｌｌ）や音声呼（ｖｏｉｃｅ ｃａｌｌ）を例とする通信セッションを操作する通信システムに関する。
【０００２】
本明細書の提示する発明は、異なる安全なプライベートＩＰデータネットワークに属するエンドポイント間において（Ｈ．３２３、ＳＩＰ、ＭＧＣＰなどのリアルタイムプロトコルを用いて）、個々のプライベートネットワークのデータプライバシーやデータセキュリティを損なうことなく互いに通信を行うことを可能にする。本発明は例えばファイアウォールなどの既存のセキュリティ機能や、ファイアウォール機能において実行されるであろうＮＡＰＴ（ネットワークアドレスポート変換）機能、ルータ、プロキシといった既存のセキュリティ機能と協働して機能するという利点を有する。本発明の利点は、それらの機器をプロトコル（例えばＨ．３２３）に完全に適合するようにアップグレードするコストまたはプロトコル（例えばＨ．３２３）を認識する付加的な機器を配備するコストをかけずにすむところにある。本明細書の提示する発明は、プライベートネットワークの端部においてシンプル（一対一の）ＮＡＴ（ネットワークアドレス変換）マッピングが適用されている構成、および／または、プライベートネットワークの端部においてＮＡＰＴ（ネットワークアドレスおよびポート変換）が行われている構成に適用される。これら２つの構成は共存することも可能であり、本発明の装置により、一方の構成を有するプライベートネットワークと他方の構成を有するプライベートネットワーク間での通信を行わせることができる。同様に、単一ネットワーク内でも、いくつかの端末（例えば専用ルームシステム）は一方の構成を用い、他の端末（例えばデスクトップのクライアントＰＣ）は第２の構成を用いるものであってもよい。なお、本明細書においては、ＮＡＴという用語はすべての形式のネットワークアドレス変換を意味するものとする。
【０００３】
本明細書で提示する発明の説明はＩＴＵのＨ．３２３スタンダードに関連して行うが、これはＨ．３２３がＩＰネットワークを含むパケットネットワーク上のリアルタイムマルチメディア通信で広く行われているスタンダードであるからである。しかし本発明は双方向に情報を送るためにポートを動的に割り当てる必要のある他のスタンダードあるいは方法（例えばＩＥＴＦのセッション開始プロトコルＳＩＰ）にも同様に適用することができる。本発明の主要な利点は、プライベートネットワークのインフラストラクチュア（ファイアウォールおよびルータ）がリアルタイム通信に用いられるプロトコルを認識する必要がなく、かつプライベートネットワーク内外にトラフィックを通過させる方法もまたプロトコルを認知しなくてよいという点にある。これにより、企業はプロトコルを顧慮することなく装置を配備することができる。だからといって何らかの装置がセキュリティ上の理由やその他の理由でプロトコルのチェックをおこなうというわけではない。
【０００４】
急速に発展するＩＰ（インターネットプロトコル）データネットワークはマルチメディアおよび音声通信サービスプロバイダにとっての新たな機会と課題を作りだしている。現在営業しているテレコミュニケーション運営者、および次世代の通信事業者やサービスプロバイダによって、データネットワークバックボーンへの、未曾有の投資がなされている。同時にＤＳＬやケーブルモデムといったブロードバンドアクセス技術が広範囲のユーザーに高速なインターネットアクセスを提供している。サービスプロバイダは、ＩＰデータネットワークを利用して新たな音声・ビデオサービスおよびデータサービスを高速インターネットと平行してデスクトップ、オフィス、家庭に直接届けることを目指している。
【０００５】
Ｈ．３２３スタンダードはそのサービス品質に保証のないパケットベースのネットワーク上でのマルチメディア通信に適用される。それは背景にあるトランスポートネットワークおよびプロトコルからは独立して設計されている。今日ＩＰデータネットワークはデフォールト（既定の）かつユビキタスな（遍在する）パケットネットワークであり、Ｈ．３２３の導入はその大部分が（全部ではないにせよ）ＩＰデータネットワーク上でのものである。ＳＩＰやＭＧＣＰを例とする他のリアルタイム（音声およびビデオ）通信用のプロトコルも、呼シグナリングおよびメディアのトランスポートにＩＰデータネットワークを用いている。更に、ＩＰデータネットワーク上でのリアルタイムでの音声ビデオのトランスポートに関連する新たなアプリケーションのための新たなプロトコルも開発されるものと予測される。本発明において提供される方法はそれらのプロトコルや１回のセッションで複数のトラフィックフローを要求する他のプロトコルにもまた適用されるものである。
【０００６】
広域通信において、異なる製造業者による端末が相互運用される場合には、スタンダード（標準）が根本的な重要性を有する。マルチメディア分野において、パケットネットワーク（例えばＩＰデータネットワーク）上でのリアルタイム通信に関する現在のスタンダードはＩＴＵスタンダードＨ．３２３である。Ｈ．３２３は現在では比較的成熟したスタンダードであり、マイクロソフト社、シスコ社、インテル社などの企業を含むマルチメディア通信業界の支持を得ている。例えばパーソナルコンピュータの７５％にマイクロソフト社のＮｅｔＭｅｅｔｉｎｇ（商標）プログラムがインストールされていると推計される。ＮｅｔＭｅｅｔｉｎｇはＨ．３２３に準拠したマルチメディア（音声、ビデオおよびデータ）通信用のアプリケーションソフトウエアである。現在では異なる製造業者による装置間での相互運用性（互換性）が達成されている。Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｎｓｏｒｔｉｕｍ （ＩＭＴＣ）の主催する最近の相互運用性イベントには世界の１２０を越える企業が参加した。このＩＭＴＣはマルチメディア通信装置の相互運用性を促進するための独立組織である。このイベントは製造業者が相互動作問題をテストし、かつ解決するために定期的に行われている。
【０００７】
これまで、マルチメディア（特にビデオ）通信を大規模に取り込むには数多くの障害があった。かつては利用の簡便性、品質、コスト、通信帯域幅のすべてが市場の成長を妨げていた。しかし、ビデオエンコーディング技術の進歩、安価なＩＰアクセスがどこでも得られる状況、およびデータネットワークへの現在の投資が、ＤＳＬやＩＳＤＮやケーブルモデムの浸透と結びついて、現在ではほとんどの問題をある程度解決し、マルチメディア通信および音声通信を可能にしている。
【０００８】
Ｈ．３２３がスタンダードとして策定された際には、プライベートネットワーク間の広いエリアにおけるトランスポートのためにＨ．３２３をＨ．３２０に変換するＨ．３２３−Ｈ．３２０ゲートウェイがネットワークドメインの端部に作られるものと想定されていた。したがってＩＰ上のＨ．３２３の導入は単一ネットワーク内の通信に集中していた。
【０００９】
しかしながら、ＩＰは広域プロトコルとして愛顧を受け続けている。ますます多くの組織が、データネットワーク全体についてＩＰに基礎を置き続けている。高速インターネットアクセス、管理されたイントラネット、ヴァーチャル・プライベート・ネットワークス（ＶＰＮｓ）のすべてにおいてＩＰに基礎を置くことが普通である。このＩＰトレンドがＨ．３２０のマルチメディアプロトコルとしての衰退を引き起こしている。市場の要求はＨ．３２０を完全にＩＰ上のＨ．３２３に置き換えることにある。しかしＷＡＮ（ワイドエリアネットワーク）を通過して行うＩＰ上のリアルタイム通信のトランスポートに関して、市場を最も活性化させているものはおそらく音声である。Ｈ．３２３やＳＩＰなどのスタンダードを用いることにより、ユーザーは自らのコンピュータを介して、インターネットを安価な音声呼に用いるようになってきた。これは全く新たなＶｏｉｃｅ ｏｖｅｒ ＩＰ（ＶｏＬＰ）産業の誕生をはっきりと示したものであり、この産業はイーサネット（登録商標）電話、ＩＰ ＰＢＸ、ソフトスイッチ、ＩＰ／ＰＳＴＮゲートウェイを含む新たなＶｏＩＰ製品の発達を見越しており、これらすべてが企業とユーザーの間での途切れることのないＶｏＩＰと結びついている。ここではＨ．３２３、ＳＩＰおよびＭＧＣＰが支配的なスタンダードとなることが予想される。
【００１０】
残念ながら、Ｈ．３２３およびＳＩＰの実際の広域配備には、予見できなかった技術的諸障害がいまなお存在する。この技術的諸障害はＩＰデータネットワークの境界における通信インフラストラクチュアに関するものである。
【００１１】
したがって、今日成功しているＩＰ上のマルチメディアおよび音声通信はイントラネット即ちプライベートに管理されたＩＰネットワークに限られている。
【００１２】
問題は２つのＩＰ技術から生じている、即ちネットワークアドレス変換（ＮＡＴ）およびファイアウォールである。これらの問題の解決を考える際にはセキュリティも課題となる。データネットワーク上でのリアルタイム通信の導入が共有されたネットワーク（例えば公共のインターネット）上に及ぶ場合には、企業はデータセキュリティになんら危険がないことを確実なものとしなければならない。現在の上記の諸問題の解決方法においては、企業の外部ＩＰアドレスを該企業が通信しようとする者（音声通信は通常すべての者を含む）に対して公にする必要がある。ここに提示する本発明はこの欠点を有しておらず、企業の外部ＩＰアドレスを「信頼された」サービスプロバイダにのみ知らしめればよい。これは公共インターネットが大きく発展してきたやり方である。
【００１３】
ＮＡＴは「アドレス不足問題」を解決するために導入された。ＩＰネットワークのいずれのエンドポイントあるいは「ホスト」も、該エンドポイントを識別（同定ｉｄｅｎｔｉｆｙ）するひとつの「ＩＰアドレス」を有しており、データパケットは正確にそこに送られるすなわちそこにルート付けされることができ、かつそこで受け取られたパケットがどこからやってきたのかを識別することができる。ＩＰアドレスフィールドを規定した時点では、誰もデスクトップ装置の広大な成長を予見することができなかった。グローバルＩＰの展開の何年後かに、ＩＰプロトコルを用いて通信を求めるエンドポイントの数がアドレスフィールドにおいて可能な固有ＩＰアドレスの数を越えることが明らかになった。アドレスフィールドを増やし、より多くのアドレスを利用可能とするには、ＩＰインフラストラクチュア全体を更新することが必要であった（当業界はある点において、これをＩＰバージョン６によって行うことを計画している。）
【００１４】
今日のソリューション（解決方法）は現在ＮＡＴと呼ばれているものである。ＩＥＴＦ ＲＦＣ１６３１で規定されたシンプルＮＡＴ（Ｓｉｍｐｌｅ ＮＡＴ）と呼ばれる最初のＮＡＴソリューションは一対一マッピングを利用しており、ワールド・ワイド・ウェブが存在する前の、組織内のいくつかのホスト（例えばＥ−メールサーバやファイル転送サーバ）のみが組織外部と通信する必要があった頃に生まれたものである。ＮＡＴにより企業内にプライベートＩＰネットワークを構築することが可能となるが、そこでは該企業内の各エンドポイントはその企業内のみで唯一固有（ｕｎｉｑｕｅ）であるが、グローバルには唯一固有ではないアドレスを有している。すなわちこれらはプライベートＩＰアドレスである。このことにより、ある組織内の各ホストは該組織内の任意の他のホストと通信する（すなわちアドレスする）ことが可能である。外部と通信するためには、パブリックな（公の）すなわちグローバルに唯一固有のＩＰアドレスが必要である。こうしたプライベートＩＰネットワークの端部にはプライベートＩＰアドレスとパブリックＩＰアドレスとを相互変換するＮＡＴ機能を行う装置が配備される。企業はその企業に独占的に（排他的に）属するひとつ以上のパブリックアドレスを有するが、一般的には必要なパブリックアドレスの数はホストの数よりも少ない。その理由は、外部と通信する必要があるのはいくつかのホストのみであるか、あるいは同時に外部通信する数はホスト数よりも少ないからである。より洗練された形態のＮＡＴはパブリックアドレスのプールを有し、それらのパブリックＩＰアドレスをファーストカム−ファーストサーブド方式（先着順方式）で外部通信を必要とするホストに動的（流動的）に割り当てている。外部装置が特定の内部装置に勝手にパケットを送る必要がある場合には固定ネットワークアドレス規則が必要となる。
【００１５】
今日ほとんどのプライベートネットワークは１０．ｘ．ｘ．ｘアドレスレンジからのプライベートＩＰアドレスを使用している。外部通信はたいていの場合管理されたあるいは共有されたＩＰネットワークまたは公共のインターネットを介したサービスを提供するサービスプロバイダを介している。各ネットワークの境界において、アドレスをパケットが伝達されるＩＰネットワーク内で唯一固有のものとするためのＮＡＴが用いられる。シンプル ＮＡＴは完全なＩＰアドレスを一対一マッピングによって変換している。このマッピングは固定的なものであってもよいし、当該通信セッションが続く間だけ動的に与えられるものであってもよい。
【００１６】
ウェブサーバ、メールサーバ、および外部サーバなどが、それらに到達する外部通信を許容するために静的な（ｓｔａｔｉｃ）一対一ＮＡＴマッピングを必要とするホストの例である。
【００１７】
ＮＡＴを用いることによって、ホストのＩＰアドレスは外部から不可視となる。これによってセキュリティレベルが向上する。
【００１８】
シンプルＮＡＴのひとつの拡張版は、変換マッピングにポートを付加的に用いるものであり、多くの場合ＮＡＰＴ（ネットワークアドレスポート変換）またはＰＡＴ（ポートアドレス変換）と呼ばれる。ポートは２つのホスト間のポイント対ポイントのトランスポートコネクションの一方の端を識別（アイデンティファイ）する。ワールド・ワイド・ウェブ（ＷＷＷ）への大量アクセスに伴い、ＩＰアドレス不足が再び生じている。これは現在多くのデスクトップマシーンがプライベートネットワークの外へ通信する必要があるからである。ＩＥＴＦのＲＦＣ １６３１に記載された解決方法は、プライベートＩＰアドレスとパブリックＩＰアドレスとの間の多対一のマッピングを許容し、その代わり、プライベートデバイスから外部のパブリックネットワーク即ち共有されたネットワークへとなされる各コネクション（接続）のパブリックＩＰアドレスについて唯一固有の（ｕｎｉｑｕｅな）ポート割り当てを用いている（理論的には各ＩＰアドレスに対して６４ｋの固有ポートがある）。インターネットの発展により、ＰＡＴはアドレス変換の一般的な手法となっている。
【００１９】
ＰＡＴのひとつの特徴はプライベートＩＰアドレス／ポートマッピングのパブリックＩＰアドレス／ポートへの割り当てが動的になされ、一般的にはプライベートデバイスがパブリックネットワークへのアウトバウンド（外向き／発信）接続を行うたびごとになされることである。ＰＡＴを用いると、前もって発信方向の接続によりそのようなＰＡＴ割り当てが行われていない限り、データはインバウンド方向（内向き方向／着信方向）に進行することはできない、即ちパブリックネットワークからプライベートネットワークへと進行することはできない。通常、ＰＡＴデバイスはＰＡＴ割当てを恒久的に行わない。所定の「沈黙」期間が経過すると、言い換えるとアウトバウンドで（外向きに）開始された接続に対して着信データがもはや受信されなくなったときに、当該接続に対するＰＡＴ割り当てが解放され、当該ポートが自由に新たなコネクションに割り当てられるようになる。
【００２０】
普通のＩＰプロトコルを介したコンピュータとネットワークとの接続の方がより容易であるが、これは同時にプライバシーとセキュリティの侵害をも更に容易にする。比較的少ないコンピュータスキルによりプライベートなあるいは内密なデータおよびファイルにアクセスすることが可能となり、そうしたビジネス情報を不正に悪用することも可能となる。当業界においてそのような攻撃に対する対策はプライベートネットワークの境界にファイアウォールを配備することである。
【００２１】
ファイアウォールはプライベートＩＰネットワークとパブリックのＩＰネットワークとの間を通過するＩＰトラフィックの種類を制限するすなわち「フィルタする（ろ過する）」ようになされている。ファイアウォールはいくつかのレベルの規則によって制限を課することができる。制限は、ＩＰアドレス、ポート、ＩＰトランスポートプロトコル（たとえばＴＣＰやＵＤＰ）またはアプリケーションに対して課することができる。制限は対称ではない。すなわち典型的にはプライベートネットワーク側（ファイアウォールの内側）からパブリックネットワーク側（ファイアウォールの外側）に向かう方向に関しては、その反対方向よりも多くの通信を許容する。
【００２２】
ファイアウォール規則をＩＰアドレスだけに適用することは難しい。内部のホスト（すなわちあなたのＰＣ）のいずれもが地球上に点在するいずれかの外部ホスト（ウェブサーバ）に接続することを望むかもしれないからである。この問題に対しては「ｗｅｌｌ−ｋｎｏｗｎ ｐｏｒｔ（よく知られたポート）」の概念が適用される。ポートは２つのホスト間のポイント対ポイントのトランスポートコネクションにおける一方の端部を識別（同定）する。「よく知られたポート」はひとつの「既知の（知られた）」種類のトラフィックを担うものである。ＩＡＮＡすなわちＩｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒ Ａｕｔｈｏｒｉｔｙはあらかじめ割り当てられたよく知られたポートおよびそれらポートの担うトラフィックの種類を特定している。例えばポート８０はウェブサーフィン（ｈｔｔｐプロトコル）トラフィックに割り当てられ、ポート２５はシンプル・メール・トランスポート・プロトコル（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）に割り当てられる、等である。
【００２３】
ウェブサーフィンに対するファイアウォールのフィルタリング規則の例は以下のようなものである：
どの内部ＩＰアドレス／ポート番号（ｐｏｒｔ ｎｕｍｂｅｒ）も、ＴＣＰ（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｎｅｃｔｉｏｎ ｐｒｏｔｏｃｏｌ）およびＨＴＴＰ（ウェブサーフィン用のアプリケーションプロトコル）を用いて、どの外部ＩＰアドレス／ポート８０に接続してもよい。
【００２４】
この接続は双方向的であり、したがってトラフィックはウェブサーバから同一の経路を逆に流れることができる。ポイントとなるのは接続は内部側から開始されなければならないという点である。
【００２５】
ｅ−メール用のファイアウォールフィルタリング規則の例は以下のようなものである：
どの外部ＩＰアドレス／どのポート番号も、ＴＣＰおよびＳＭＴＰを用いてＩＰアドレス１９２．３．４．５／ポート２５に接続してよい。
（同時に、ＮＡＴ機能は送信先ＩＰアドレス１９２．３．４．５をメールサーバの内部アドレスである１０．６．７．８に変換してもよい。）
【００２６】
「どの内部ＩＰアドレス／どのポート番号もＴＣＰおよびＵＤＰのためにどの外部アドレス／どのポート番号と接続してもよい、逆もまた可」といったフィルタ規則はフィルタとしては広すぎるものであり、ファイアウォールを解放して直接接続するのと同じことになってしまう。ＩＴ管理者はこのような規則を敬遠する。
【００２７】
Ｈ．３２３は背景となるネットワークおよびトランスポートプロトコルとは独立して設計されてきた。それでもＨ．３２３のＩＰネットワークへの導入は以下の主要概念の対応付けによって可能となる。
Ｈ．３２３アドレス　　　　　：　　　ＩＰアドレス
Ｈ．３２３論理チャネル　：　　　ＴＣＰ／ＵＤＰポートコネクション
【００２８】
ＩＰ上でのＨ．３２３の導入においては、Ｈ．３２３プロトコルメッセージはＴＣＰまたはＵＤＰのいずれかを用いてＩＰパケットのペイロードとして送信される。多くのＨ．３２３メッセージは送信元のエンドポイントまたは送信先のエンドポイントあるいはその両方のエンドポイントのＨ．３２３アドレスを含む。ＳＩＰなどの他のシグナリングプロトコル（ｓｉｇｎａｌｉｎｇ ｐｒｏｔｏｃｏｌ）もまたシグナリングプロトコルペイロード内にＩＰアドレスを埋め込む。
【００２９】
しかしながら、ＮＡＴ機能は送信元および送信先ホストの見かけのＩＰアドレス（ａｐｐａｒｅｎｔ ＩＰ ａｄｄｒｅｓｓ）（およびポート）を変換するが、Ｈ．３２３ペイロード内のＨ．３２３アドレスは変更しない。ホストはＨ．３２３ペイロード内で交換されるＨ．３２３アドレスおよびポートを用いて、受信した様々なデータパケットを呼（コール）に関連づけているので、上記のようなＮＡＴ機能はＨ．３２３プロトコルの破壊を引き起こすものであり、Ｈ．３２３ペイロードアドレスを取り扱うには媒介インテリジェンス（ｉｎｔｅｒｍｅｄｉａｒｙ ｉｎｔｅｌｌｉｇｅｎｃｅ）が必要となる。
【００３０】
マルチメディア通信の複雑性により、Ｈ．３２３はエンドポイント間にいくつかの論理チャネルを開くことを要求する。論理チャネルは、呼制御、能力交換（ｃａｐａｂｉｌｉｔｉｅｓ ｅｘｃｈａｎｇｅ）、オーディオ、ビデオ、データについて必要である。オーディオとビデオのみを含む単純なポイント対ポイントのＨ．３２３マルチメディアセッションにおいては、少なくとも６つの論理チャネルが必要となる。Ｈ．３２３のＩＰ配備においては、論理チャネルはＴＣＰまたはＵＤＰポートコネクションにマッピングされ、それらの多くは動的に割り当てられる。
【００３１】
ファイアウォール機能は規則の設定されていないポート上のトラフィックをフィルタによって排除してしまうので、ファイアウォールを開放するか（この場合ファイアウォールの目的が無効になる）、あるいは多くのＨ．３２３トラフィックが通過不能になるか、の二つに一つとなってしまう。
【００３２】
従って、エンドポイント間に存在するＮＡＴおよびファイアウォール機能は共にＨ．３２３（およびＳＩＰやＭＧＣＰなどのその他のリアルタイムプロトコル）通信の動作を阻害する。これは両エンドポイントが異なるプライベートネットワークに属する場合、または一方のエンドポイントがプライベートネットワーク内にあり他方のエンドポイントがインターネット内にある場合、または両エンドポイントが別々に管理されたＩＰネットワークナインにある場合には一般的に起こることである。
【００３３】
従ってＨ．３２３（およびＳＩＰ、ＭＧＣＰなどの）通信はファイアウォールにとって忌むべきものである。ファイアウォールがＨ．３２３を認識できるようにするか、あるいは何らかの媒介インテリジェンスがポート割り当てを安全なやり方で操作するようにしなければならない。
【００３４】
この問題の可能な解決方法のひとつは完全なＩＰ Ｈ．３２３アップグレード（ｃｏｍｐｌｅｔｅ ＩＰ Ｈ．３２３ ｕｐｇｒａｄｅ）である。これは以下のことを要求する：
・　各ＩＰネットワーク境界にあるＮＡＴ機能に対するＨ．３２３アップグレード。ＮＡＴ機能はすべてのＨ．３２３ペイロードを走査し、一貫性をもってＩＰアドレスを変換しなければならない。
・　各ＩＰネットワーク境界にあるファイアウォール機能に対するＨ．３２３アップグレード。ファイアウォールは、動的に割り当てられるポートを開くことができるようにすべてのＨ．３２３通信を認識しおよび監視し、かつそれらポート上のすべての非Ｈ．３２３トラフィックをフィルタしなければならない。
・　境界あるいは共有されたＩＰネットワーク内においてＨ．３２３インテリジェンスを配備し、アドレスを分析しかつ調停すること（ｒｅｓｏｌｖｅ ａｎｄ ａｒｂｉｔｒａｔｅ ａｄｄｒｅｓｓｅｓ）。ユーザーがＩＰアドレスを直接用いることはほとんどない。実際には別名ＩＰアドレス（エイリアス）を用いる。インテリジェンスはエイリアスをＩＰアドレスに分析する必要がある。このＨ．３２３機能はゲートキーパと呼ばれるＨ．３２３要素（Ｈ．３２３ ｅｎｔｉｔｉｅｓ）に含まれる。
【００３５】
この可能な解決方法の短所は以下の通りである：
・　Ｈ．３２３通信を実現するには、各組織／プライベートネットワークは同一レベルのアップグレードを有さなければならない。
・　アップグレードには費用がかかる。新たな機能性または新たな装置を購入し、計画し、配備しなければならない。ＩＴ管理者はＨ．３２３について学習しなければならない。
・　そのような設備を該設備に対する要請に適合させることは容易ではない。なぜなら当該技術は漸進的に導入されるものであり、当初の（おそらくは実験的な）要請よりもより大規模でコストのかかる初期設備が必要となるからである。
・　シンプル ＮＡＴおよびファイアウォール機能を分析する間断ないＨ．３２３パケット解析は各ネットワーク境界において信号に待ち時間を課す。そしてオーディオおよびビデオに対する待ち時間の許容量はきわめて小さい。
・リアルタイム通信のスタンダードは複数あり、それらのスタンダードのシグナリングプロトコルは異なっているので、企業は複数の、即ち用いようとするプロトコルの各々について一つずつのアップグレードを行う必要がある。
・メディアは２つの企業の間、または一つの企業とパブリックネットワーク内の一つのデバイスとの間を直接進行すると考えられる。このことにより、企業のＩＰアドレスが公知のものとなる。これはセキュリティを危うくするものと考えられる。なぜなら、潜在的攻撃者は攻撃を始める第１段階として企業のＩＰアドレスを発見する必要があるからである。
【００３６】
これらの諸問題により、ファイアウォールおよび／またはネットワークアドレス変換（ＮＡＴ）が存在する場合にはＨ．３２３プロトコルは用いられていない。一つの解決案はＨ．３２３システムをファイアウォールおよびＮＡＴ機能のパブリック側に置く、というものであった。これにより、Ｈ．３２３を用いると共に、ネットワークのそれ以外の部分を保護することが可能となる。この方法の短所は以下のようなものである：
１．最も普及している（ユビキタスな）ビデオ通信装置はデスクトップＰＣである。そしてすべてのデスクトップコンピュータをパブリック側に置くのはナンセンスである。
２．ファイアウォールのパブリック側では、Ｈ．３２３システムは攻撃者から保護されない。
３．特別なシステムのみがＨ．３２３通信を許されることになるので、各団体はＨ．３２３の潜在的遍在性の利点を享受できない。
４．ファイアウォールがＨ．３２３システムのデータアクセスを妨げるので、各団体はＨ．３２３のデータ共有機能をフルに活用することができない。Ｈ．３２３システムからのデータ転送機能を可能とするためにファイアウォールを開放することはできない。なぜならその場合、攻撃者がＨ．３２３システムをリレー（中継器）として用いることができるからである。
５．形成されつつあるＶｏｉｃｅ ｏｖｅｒ ＩＰ（ＶｏＩＰ）市場においては、イーサネット（登録商標）電話やＩＰ ＰＢＸを例とするデータネットワークに直接接続する電話機器の市場が存在する。それらはその性質上デスクトップ機器であるので、ファイアウォールやＮＡＴ機能の背後のプライベートネットワーク上に配備される。従って上に述べた諸問題を解決することなしには、これらの機器を用いた電話機能は企業のプライベートネットワーク即ちイントラネットに限られるか、または外部世界に到達するためにＩＰ−ＰＳＴＮゲートウェイを通過しなければならない。
【００３７】
音声・ビデオおよびデータ用に企業へのブロードバンド接続を便宜よく利用するにはこれらの問題についての安全な解決が必要となる。
本発明の目的はこれらの問題に対処することである。
【００３８】
本発明は、送信先通信システムとの通信セッションを処理する通信システムを提供するものであり、該システムは、第１のローカル端末と、外部サーバと、第１のローカル端末と外部サーバとの間において共有された通信ネットワーク上で通信セッションを伝送するための１つ以上の論理チャネルとを有し、前記通信ネットワークは通信セッションが必ず通過する第１のＮＡＴ機能を備え、
ａ）　第１のローカル端末は通信セッション用の少なくとも一つのトランスポートアドレスを有し；
ｂ）　第１のＮＡＴ機能は第１の端末と共有通信ネットワークとの間のコネクションにおけるトランスポートアドレスに対してネットワークアドレスマッピングを施し；
ｃ）　該システムは外部サーバとの通信において第１のローカル端末の代理として動作するように構成された第１のプロキシインターフェイスエージェント（ｐｒｏｘｙ ｉｎｔｅｒｆａｃｅ ａｇｅｎｔ）を備え；
ｄ）　第１のプロキシインターフェイスエージェントは外部サーバへの１つ以上のアウトバウンドコネクションにおいて論理チャネルを設定（確立）することができ、前記論理チャネルは第１のプロキシインターフェイスエージェントと外部サーバとの間の制御チャネルであり；
ｅ）　前記アウトバウンドコネクションは第１のプロキシインターフェイスエージェントによって確立される動的なアウトバウンドコネクションであり；
ｆ）　第１のプロキシインターフェイスエージェントは、第１のローカル端末のトランスポートアドレスと第１のプロキシインターフェイスエージェント−外部サーバ間の識別可能な論理チャネルとの間の関連付けを行うように構成されており、前記識別可能な論理チャネル（ｉｄｅｎｔｉｆｉａｂｌｅ ｌｏｇｉｃａｌ ｃｈａｎｎｅｌ（ｓ））はプロキシインターフェイスエージェントから外部サーバへの１つ以上の前記動的アウトバウンドコネクションにおいて設定される、ことを特徴とする。
【００３９】
また本発明は、通信システムの通信セッションを処理する方法を提供するものであり、該方法において、該通信システムは第１のローカル端末と、外部サーバと、第１のローカル端末と共有されたネットワークとの間のプロキシインターフェイスエージェントを有し、前記通信ネットワークは通信セッションが必ず通過する第１のＮＡＴ機能を備えており、該方法は以下のステップを含むことを特徴とする、即ち：
ｉ）　第１のローカル端末と外部サーバとの間において共有通信ネットワーク上で１つ以上の論理チャネルで通信セッションを伝送するステップ、該第１のローカル端末は通信セッション用の少なくとも一つのトランスポートアドレスを有する；
ｉｉ）　第１のＮＡＴ機能が第１の端末と共有されたネットワークとの間のコネクションについてのトランスポートアドレスに対してネットワークアドレスマッピングを持続的に適用することを許容するステップ；
ｉｉｉ）　 第１のプロキシインターフェイスエージェントを用いて、外部サーバとの通信において第１のローカル端末を代理して動作させるステップ；
ｉｖ）　第１のプロキシインターフェイスエージェントを用いて、外部サーバに対する１つ以上のアウトバウンドコネクションにおいて論理チャネルを設定するステップ、該論理チャネルは第１のプロキシインターフェイスエージェントと外部サーバとの間の制御チャネルである；
ｖ）　第１のプロキシインターフェイスエージェントを用いて外部サーバへの動的なアウトバウンドコネクションを確立するステップ；
ｖｉ）　第１のプロキシインターフェイスエージェントを用いて第１のローカル端末のトランスポートアドレスと第１のプロキシインターフェイスエージェント−外部サーバ間の識別可能な論理チャネルとの間の関連付けを行うステップ、前記識別可能な論理チャネルはプロキシインターフェイスエージェントから外部サーバへの１つ以上の前記動的アウトバウンドコネクションにおいて設定される。
【００４０】
論理チャネルは全体で通信セッションを提供し、アウトバウンドコネクションにより、必要なＮＡＴマッピングが生成されて端末と外部サーバとの間のインバウンド（内向きまたは着信）およびアウトバウンド（外向きまたは発信）通信が可能となる。第１のローカル端末からの通信は第１のプロキシインターフェイスエージェントにより識別可能な論理チャネル上に素通しでマッピングされる。外部サーバは送信先通信システムと、あたかも第１の端末であるかのように通信する。従って、この通信システムを用いて第１の端末と送信先通信システムとの間の素通しの通信手段（ｔｒａｎｓｐａｒｅｎｔ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｍｅａｎｓ）を構成することができ、外部サーバが先方へ向かう通信の転送を担う。
【００４１】
ＴＣＰでのインバウンド通信を可能とするために、あらかじめ確立された双方向アウトバウンドコネクションを形成してＮＡＴマッピングを確立する。
【００４２】
ＵＤＰでのインバウンド通信を可能にするため、プローブパケットを送ってＮＡＴマッピングを確立する。
【００４３】
通信セッションの間、第１のＮＡＴ機能は第１のプロキシインターフェイスエージェントと外部サーバとの間の接続にネットワークアドレスマッピングを継続的に施す。
識別可能な論理チャネルを、通常の多重化手法を用いて１つ以上のコネクションに多重化してもよい。
【００４４】
トランスポートアドレスの一例は、ＩＰアドレスとポートである。従って一般的にネットワークアドレスマッピングはＩＰアドレスおよび／またはポートのマッピングである。
【００４５】
本発明の一実施形態において、第１のプロキシインターフェイスエージェントは前記の関連付けを、外部サーバからの要求に応じて行う。
【００４６】
本発明の別の一実施形態においては、第１のプロキシインターフェイスエージェントは前記の関連付けを第１プロキシインターフェイスエージェント自身の要求に応じて行う。
【００４７】
外部サーバ自身が（あるいは第１のプロキシインターフェイスエージェントが）外部サーバに対して、前記の識別可能な論理チャネルと外部サーバおよび送信先端末などの送信先通信システム間の通信の論理チャネルとの間の対応付けを行うことを要求するようにしてもよい。
【００４８】
好適には、第１のローカル端末のトランスポートアドレスは動的に割り当てられる。同様に外部サーバのトランスポートアドレスも動的に割り当てるようにしてもよい。
【００４９】
あるいは外部サーバのトランスポートアドレスをいずれも動的には割り当てないようにしてもよい。
【００５０】
この通信システムは通信セッションが必ず通る（通らなければならない）第１のファイアウォールを備えてもよい。その場合、第１のファイアウォールは第１のローカル端末と共有されたネットワークとの間のあるタイプの通信を制限し、かつ第１のプロキシインターフェイスエージェントと外部サーバとの間の通信は制限しないように構成される。
【００５１】
外部サーバのトランスポートアドレスの少なくとも一つは、少なくとも一つのあらかじめ割り当てられたポート（これは「よく知られた（ｗｅｌｌ−ｋｎｏｗｎ）」ポートと呼ばれる場合もある）を含んでいる。そして、第１のプロキシインターフェイスエージェントから外部サーバへ向かうアウトバウンドコネクションは上記のあらかじめ割り当てられたポートを用いる。
【００５２】
好適には、第１のプロキシインターフェイスエージェントから外部サーバへの上記のアウトバウンドコネクションが接続する外部サーバのすべてのトランスポートアドレスはあらかじめ割り当てられたポートを有する。この場合、外部サーバのすべてのトランスポートアドレスは最大で２つのあらかじめ割り当てられたポートを有してよい。
【００５３】
外部サーバのあらかじめ割り当てられたポートの数は端末に動的に割り当てられたポートの総数以下である。たとえば外部サーバは３つのあらかじめ割り当てられたポートを有してよく、そのうち一つはＴＣＰ用で、２つはＵＤＰ用である。
【００５４】
この通信システムは第２のローカル端末を含んでもよく、外部サーバは第１の端末と第２の端末の間で通信セッションの期間、各端末に対して他方の端末のプロキシ（代理）として動作するプロキシサーバである。
【００５５】
多くの場合、通信セッションが必ず通過する第２のファイアウォールおよび／または第２のＮＡＴを有する第２のローカル端末が存在する。そして第２のファイアウォールは第２の端末と共有されたネットワークとの間のあるタイプの通信を制限するように構成される。外部サーバは端末と通信するための論理通信ポートを有し、該論理通信ポートは第２の端末と通信するための１つ以上のあらかじめ割り当てられたポートを含んでいる。そのとき第２のファイアウォールは第２の端末とプロキシサーバのあらかじめ割り当てられたポートとの間の通信は制限しないように構成してよく、かつ第２のプロキシインターフェイスエージェントを配備して外部サーバとの通信において第２の端末の代理として動作するようにする。第２のローカル端末は上に述べたものと同様の手順により、第２のプロキシインターフェイスエージェントとの通信セッションに従事するようにできる。
【００５６】
また、第２の端末および第２のプロキシインターフェイスエージェントは第２の外部サーバと接続するようにしてもよい。外部サーバは公共の、即ち共有されたネットワークを介して通信する。
【００５７】
共有された通信ネットワークは一般的に公共の通信ネットワークおよび／またはインターネットを含む。
【００５８】
プロキシインターフェイスエージェントはローカル端末と同じ場所にあってもよいし、あるいはローカル端末から離れたところにあってもよい。
【００５９】
本発明はプロキシインターフェイスエージェント毎に２つ以上のローカル端末がある場合にも有用である。その場合、プロキシインターフェイスエージェントは同一のあるいは異なるリアルタイム（または非リアルタイム）プロトコルを用いて（たとえばＨ．３２３とＳＩＰの両方を用いて）複数の端末を同時に代理して動作することができる。好適には、シグナリングゲートウェイ機能（ｓｉｇｎａｌｉｎｇ ｇａｔｅｗａｙ ｆｕｎｃｔｉｏｎａｌｉｔｙ）（たとえばＨ．３２３とＳＩＰとの間の）を外部サーバまたはプロキシインターフェイスエージェントのいずれかの内に設ける。
【００６０】
プロキシインターフェイスエージェントおよび外部サーバによって、エンドポイントからは不可視のその他の付加的な特徴および機能性（たとえばＱＯＳおよび／または暗号化によるセキュリティ）を付加してもよい。
【００６１】
このようなシステムは国際電気通信連合（ＩＴＵ）のＨ．３２３スタンダードによる音声呼またはマルチメディア呼を行うために用いることができる。またはこのシステムをインターネット・エンジニアリング・タスク・フォースのＳＩＰスタンダードによる音声呼またはマルチメディア呼に用いてもよい。このようなシステムおよび方法はまた、たとえばファイル転送などの、リアルタイムプロトコルを用いたファイアウォールおよびＮＡＴを介した他のタイプの通信セッションであって、動作する際にＮＡＴ機能によって変更されないトランスポートアドレスによって識別される論理チャネルの動的な設定をおこなうような通信セッションの設定に用いてもよい。またこの通信システムは混在するプロトコル環境をサポートするようにしてもよい。
【００６２】
プロキシインターフェイスエージェントはエンドポイントと同じ場所にあってもよいし、それが代理として動作するエンドポイントとは別のデバイス内に設けてもよい。
【００６３】
端末はマルチメディア信号を関連するマルチメディア制御信号と共に送信および／または受信するように構成し、制御信号はあらかじめ割り当てられたポートの一つに送り、メディア信号はその他のあらかじめ割り当てられたポートに送るように構成してもよい。
【００６４】
好適には少なくとも一つの論理通信ポートはあらかじめ割り当てられたポートであり、前記要求は通信セッションを開始する開始要求としてあらかじめ割り当てられたポートに送られる。
【００６５】
通信手段は音声呼またはマルチメディア呼を少なくとも部分的にはインターネットを介して行うように構成することができ、その場合、外部サーバはパブリックなインターネットプロトコルアドレスを有し、それによって一方または両方の端末が外部サーバと通信し、ファイアウォールは端末と外部サーバのあらかじめ割り当てられたポートとの間の通信は制限しないように構成される。
【００６６】
本発明は１つ以上の第１端末の組および第２端末の組が存在する場合に適用できる。たとえば一つのサイトにあるいくつかの第１の音声またはマルチメディア端末のそれぞれが他の様々なサイトの対応する他の第２の音声またはマルチメディア端末に接続することができる。
【００６７】
本発明により、別個のプライベートネットワーク内にある２つの端末が共通の公共ネットワーク（即ち共有されたネットワーク）を介して通信することが可能となり、その際プライベートネットワークの一方または両方はあるタイプの通信を制限するファイアウォールおよび／またはＮＡＴを介して公共ネットワークに接続される。同様に、本発明によりプライベートネットワーク内の一つの端末が公共ネットワークの端末と通信することが可能となり、その際２つのネットワークはあるタイプの通信を制限するファイアウォールおよび／またはＮＡＴを介して接続される。
【００６８】
本発明の説明は、ここで第１のローカル端末と呼んでいる第１のエンドポイントとここで外部サーバと呼んでいる媒介サーバとの間の動作のみについて行う。しかし第２の端末と外部サーバとの間の動作は第１の端末と外部サーバとの間の動作と同様である。また、第２の端末が公共ネットワークに直接接続される場合というのは、該端末がファイアウォールおよびＮＡＴ設備が全く何も機能しないプライベートネットワークに接続される場合と等価になる。つまりそれは、ファイアウォールがどんなコネクションも制限せず、またＮＡＴが与えられたコネクションに対して変換の両側（前後）で同じアドレスを用いる場合である。
【００６９】
本発明では、共有された即ち公共の（パブリック）ネットワーク内の外部サーバとプライベートネットワーク内のプロキシインターフェイスエージェントとを配備する。外部サーバは公共のサービスプロバイダによって所有され運営されるものであってよい。従ってそれは典型的にはある企業がプライベート／パブリック（公共）のネットワーク境界を通過してＨ．３２３通信を展開しようとする前に、すでに配備されていることであろう。プロキシインターフェイスエージェントは端末の一部として設けられてもよいし、端末と同じデバイス上で動作するが端末の実行とは独立させるようにしてもよく、さらにまた別個のデバイスにインストールしてもよい。
【００７０】
プロキシインターフェイスエージェントは有効（オン）となると、外部サーバへのＴＣＰコネクションを確立する。このコネクションはファイアウォールおよびＮＡＴのいずれかまたは両方が備わっている場合にはそれらの一方または両方を介して行われることになる。そのため、ファイアウォールは外部サーバのアドレスおよびよく知られたポートへの外向きの（発信方向の）ＴＣＰコネクションを許容する必要がある。ＮＡＴはプライベートからパブリックへのアドレスマッピング（そしてその逆も）を施すことができる。なぜならコネクションがアウトバウンド方向（発信方向）に形成されたからである。設定プロセスの一部として、外部サーバは自身をプロキシインターフェイスエージェントに対して認証してよく、かつ接続を暗号化してよい。このコネクション上で動作するプロトコルは複数のシグナリングプロトコルの多重化を許容する。このようなシグナリングプロトコルとしてはＨ．２２５ ＲＡＳ、Ｈ．２２５コールシグナリング、Ｈ．２４５、ＳＩＰがあるが、これらに限られるものではない。このコネクションは実に、ＴＣＰコネクションの性能特性で間に合うすべての第１のローカル端末−外部サーバ間の通信に対して十分なものである。ひとたび確立されてしまえば、この多重化されたコネクションは、外向きまたは内向きの呼試行がなされるまでの間、定期的な登録メッセージをのぞいては大部分休眠状態となる。セキュリティを更に高めるために、このコネクションの設定を継続的に行い、一定の（短い）間隔でコネクションを切るようにしてもよい。コネクションの設定の度毎にＮＡＴ機能において異なるポート割り当てがなされ、かつ暗号化キーが更新される可能性がある。従って攻撃者がこのコネクションを利用する可能性が低減される。
【００７１】
しかしながら多重化コネクションのトランスポート特性はオーディオおよびビデオのようなリアルタイムメディアにはふさわしいものではない。これらのメディアには、プロキシインターフェイスエージェントと外部サーバとの間にＵＤＰベースのＲＴＰ／ＲＴＣＰコネクションを確立することが必要となる。インバウンドおよびアウトバウンド両方のＲＴＰ／ＲＴＣＰコネクションについて、両方向のＵＤＰトラフィックが必要である。外部サーバを介して端末から公共ネットワークにメディアを送るために、外部サーバは端末に（多重化されたコネクションを用いてプロキシインターフェイスエージェントを介して）端末がそのメディアをプロキシインターフェイスエージェントに送るよう指令するＨ．３２３メッセージを送る。（これはＨ．３２３メッセージの様々なデータフィールドに、端末とプロキシインターフェイスエージェントとがＨ．３２３呼の両エンドであるような見かけを与えるアドレスおよびポートの値を入れることにより、スタンダードなＨ．３２３プロセスを用いて行うことができる。）続いてプロキシインターフェイスエージェントはファイアウォールおよび／またはＮＡＴを介して外部サーバへ向かうおよび外部サーバからやって来る両方のＵＤＰデータ交換を確立しなければならない。
【００７２】
基本的には、プロキシインターフェイスエージェントは単に外部サーバのアドレスおよびよく知られたポートにＵＤＰパケットを送るだけで、外部サーバへのＵＤＰコネクションを確立することができる。ファイアウォールはこのトラフィックを通過させるように設定でき、またコネクションがアウトバウンド方向に形成されるのでＮＡＴはプライベートからパブリックへのアドレスマッピングを行うことができる。しかしながら（外部サーバのように）多くのＵＤＰコネクションを伴う複数の呼を処理するデバイスは、一般的にＩＰ送信先アドレスおよびポート、および／または、ＩＰ送信元アドレスおよびポートを用いてＵＤＰ情報を適切な呼と関連付けする。この外部サーバの場合、すべてのＵＤＰデータはファイアウォールの通過を許可されるために、同一のＩＰアドレスおよびよく知られたポートに送られなければならない。従って、様々なＵＤＰコネクションを区別するためにＩＰ送信先アドレスおよびポートを用いることはできない。また、外部サーバの視点から見れば、ＮＡＴはそれが送るＵＤＰパケットに事実上ランダムに送信元ＩＰアドレスを割り当てていることになる。この結果、外部サーバにやってくるＵＤＰデータのＩＰ送信元アドレスおよびポートは外部サーバ（あるいはプロキシインターフェイスエージェント）が様々なシグナリングチャネルを通じて取り決めていたメディアチャネルのいずれとも対応することがない。
【００７３】
この関連付けの問題を解決するために、外部サーバ（あるいはプロキシインターフェイスエージェント）はプロキシインターフェイスエージェントに、その接続に対して以降にプロキシインターフェイスエージェントがＵＤＰデータを送るであろう同じＩＰ送信元および送信先アドレスおよびポートを用いてプローブパケットを外部サーバに送るように（ＴＣＰベースの多重化されたコネクションを介して）指令する。プローブパケットは外部サーバ（あるいはプロキシインターフェイスエージェント）によって選択された固有のトークンを含んでおり、これにより外部サーバは受け取ったプローブパケットを適切なＵＤＰコネクションと関連付けることができる。そして更に、外部サーバはプローブパケットのＩＰ送信元および送信先アドレスおよびポートをＵＤＰコネクションと関連付けることができる。このアドレスおよびポート情報を得たことにより、外部サーバはこれらのＩＰアドレスおよびポートで以降に受け取るＵＤＰデータを、適切な呼と関連付け、外部サーバが送信先通信システムへおよび送信先通信システムから正しく転送できるようにすることができる。本発明の別の実施形態では、トークン情報は送信される各ＵＤＰパケットと共に多重化することができる。また、複数の論理チャネルを同じＵＤＰコネクション上に多重化することができる。このような手法の利点はプロキシインターフェイスエージェントにおけるポートの使用を維持することである。もう一つの利点は、通常はすべてのＲＴＰ／ＲＴＣＰパケットに乗って送られるＵＤＰヘッダ情報によってとられる帯域幅を節約することである。論理チャネルを多重化することによって使用されるＴＣＰおよびＵＤＰコネクションの数が少なくなれば、それらのコネクションをプロキシインターフェイスエージェントのあらかじめ割り当てられたポートまたはよく知られたポートに配置することができる。これにより、ファイアウォール規則をより狭めることが可能となる。
【００７４】
データを外部サーバからプロキシインターフェイスエージェントに送るためには、ＮＡＴにおいてプライベートからパブリックへのアドレスマッピングが必要である。これは普通一対多のマッピングであるので、ＮＡＴは一般的にそうしたマッピングを動的に行うことはできない。しかし、プロキシインターフェイスエージェントから外部サーバへの外向き（発信方向）ＵＤＰコネクションを行うときに確立されるネットワーク経路は実際上本来双方向的であると考えられる。従って、外部サーバからプロキシインターフェイスエージェントへのＵＤＰコネクションを確立するためには、プロキシインターフェイスエージェントから外部サーバへのＵＤＰコネクションを確立するのと同じ手順がとられる。しかし、アドレスとポートの関連付けがなされてしまえば、外部サーバはこの情報をＵＤＰデータを受け取るのではなく送るために用いる。その後プロキシインターフェイスエージェントがＵＤＰデータを端末に送る。適切なアドレスおよびポート値を用いたスタンダードなＨ．３２３シグナリングを用いて、プロキシインターフェイスエージェントからＵＤＰデータを受け取るよう端末を設定することができる。
【００７５】
以上に説明したように、第１のプロキシインターフェイスエージェントおよび外部サーバにより、第１の端末がＮＡＴおよびファイアウォールを介して、それらのＮＡＴおよびファイアウォールを改変することなく送信先通信システムと通信することを可能にする通信システムおよび通信方法が提供される。これは以下によって成し遂げられる、即ち：
ａ）　端末が第１のプロキシインターフェイスエージェントとあたかもそれが送信先の通信システムであるかのように通信しかつ送信先通信システムが外部サーバとそれがあたかも第１の端末であるかのように通信するように、プロトコル（Ｈ．３２３やＳＩＰなど）内のアドレスを変更すること、および
ｂ）　１）第１の端末の用いる論理チャネルと、２）第１のプロキシインターフェイスエージェントから外部サーバへ至る識別可能な論理チャネルであって第１のプロキシインターフェイスエージェントから外部サーバへの動的なアウトバウンドコネクションにおいて設定される識別可能な論理チャネルと、３）外部サーバと送信先通信システムとの間の論理チャネルと、の関連付けを動的に行うこと、である。
【００７６】
プロトコル内のアドレスの変更は外部サーバによって行ってもよいし、第１のプロキシインターフェイスエージェントによって行ってもよく、またはそれら両方によって行ってもよい。この変更が行われるときはいつも、上記の動的な関連付けを行うことができるように、第１のプロキシインターフェイスエージェントと外部サーバとの間で要求および指令が通信される必要がある。要求と指令は第１のプロキシインターフェイスエージェント（クライアント）および外部サーバ（サーバ）の間のクライアント−サーバ・プロトコル内で送られる。このクライアント−サーバ・プロトコルは第１のプロキシインターフェイスエージェントから外部サーバへのアウトバウンドコネクションにおいて開かれる制御チャネル上において伝送される。
【００７７】
外部サーバがプロトコルのアドレス変更を行う場合には、外部サーバをクライアント−サーバ・プロトコルのマスターと言い、第１のプロキシインターフェイスエージェントをスレーブと言う。
【００７８】
また第１のプロキシインターフェイスエージェントがプロトコルのアドレス変更を行う場合には、第１のプロキシインターフェイスエージェントをクライアント−サーバ・プロトコルのマスターと言い外部サーバをスレーブと言う。
【００７９】
第１のプロキシインターフェイスエージェントおよび外部サーバの両方がプロトコルの変更を行う場合、一方がマスターとなり他方がスレーブとなるよう両者で取り決めるかまたはそのように構成しておくことができる。
【００８０】
１つ以上の呼についての第１のプロキシインターフェイスエージェントからの１つ以上のアウトバウンドコネクションが外部サーバの同一のトランスポートアドレスに届くこと、およびそれらのアウトバウンド接続はそのアウトバウンドコネクションの送信元アドレスをランダム化する１つ以上のＮＡＴを通過しているであろうことから、上記アウトバウンドコネクションを確立するために既知の識別子を含むプローブパケットを用いる。該識別子は第１のプロキシインターフェイスエージェントと外部サーバとの間（またはその逆）で交換される。この識別子によって、外部サーバは必要な関連付けを完遂することができ、呼を送信先通信システムへまた送信先通信システムから正しく転送することができる。
【００８１】
完全なＨ．３２３アップグレードに代わるものの一例を、図１を参照して説明する。この図は第１の企業２と第２の企業４を含む通信システム１を示す。各企業はプライベートネットワーク６，８を有しており、それらネットワークは共に一つ以上のＨ．３２３端末１０，１２を有している。各プライベートネットワーク６，８は共に、同じ１０．ｘ．ｘ．ｘアドレスレンジ内のプライベートＩＰアドレス１４，１６を有している。プライベートＩＰアドレス１４，１６は静的（固定的）に割り当てられたものであってもよいし、通常のＤＨＣＰプロセスによって動的（流動的）に割り当てられたものであってもよい。プライベートネットワーク６，８内には端末１０，１２をそれぞれ代理して動作するプロキシインターフェイスエージェント（ｐｒｏｘｙ ｉｎｔｅｒｆａｃｅ ａｇｅｎｔ：プロキシインターフェイス代理装置）１１，１３が含まれている。プロキシインターフェイスエージェントが、それぞれに対応する端末と同じ場所にない場合には、プロキシインターフェイスエージェントはそれぞれに対応するプライベートネットワーク１４，１６のレンジ内の唯一固有のＩＰアドレスを有するものとする。そのような場合、各プロキシインターフェイスエージェント１１，１３は複数の端末１０，１２の代理として動作してもよい。図１においては、プロキシインターフェイスエージェントが同じ場所にある場合を示しており、また図２はプロキシインターフェイスエージェントが同じ場所にない場合を示している。外部通信は共有されたあるいは管理されたあるいは公共のインターネット２０を介して行われる。外部通信用として、第１の企業２はたとえば１９２．１．１．１に始まるレンジの１つ以上のパブリックＩＰアドレス２２を有し、第２の企業４はたとえば２０６．１．１．１に始まるレンジの１つ以上のパブリックＩＰアドレス２４を有する。各企業はルータ３２，３４を有しており、該ルータ３２，３４はネットワークアドレスポート変換を行って、内部ＩＰアドレス１４，１６およびそれらアドレス（プライベート）上のポート番号と外部ＩＰアドレス２２，２４の内の一つおよび選択されたそのＩＰアドレス（パブリック）上のポート番号とのマッピング（対応付け）をおこなう。
【００８２】
各プライベートネットワーク６，８はオプションとして、それらの端部においてファイアウォール機能２６，２８によって保護される。ファイアウォール機能は表１に示す規則によって構成されＨ．３２３などをベースとするリアルタイム通信を許容する。この規則は先行する発明によって提案された２つ以上の新たなよく知られたポート（ｗｅｌｌ ｋｎｏｗｎ ｐｏｒｔ）を取り入れており、それらの新たなよく知られたポートはＸ，Ｙ，Ｚで示している。ポートＺは実際にはＸまたはＹのいずれかと等しくてもよい。
【００８３】
【表１】

【００８４】
表１に示したポート番号Ｘ，Ｙ，Ｚは理想的にはＩＡＮＡによって合意されたスタンダードに従って登録されたポート番号である。これらのポートが業界のスタンダードなポートであることの利点は、ファイアウォールなどの媒介装置が関連メディアがリアルタイムトラフィックであることを認識し、それを適切に取り扱うことができることである。たとえば、ルータが遅延を最小にするように当該トラフィックに上位の優先性を与える、といったことができる。
【００８５】
第１の企業２のＨ．３２３端末１０が第２の企業４の他のＨ．３２３端末１２と通信するためには、外部サーバ４０がたとえばルータ３８を介して接続されている共有されたネットワーク２０が存在しなければならない。外部サーバ４０はたとえば４５．６．７．８というパブリックのＩＰアドレス４４を有する。外部サーバ４４はまた、よく知られたポート番号Ｘ，Ｙ，Ｚ４６を有している。これらよく知られたポート番号は、あらかじめＩＡＮＡにおいて合意され登録されていなければならない。
【００８６】
図３は第１の端末、第１のプロキシインターフェイス１１、第１のファイアウォール２６、第１のＮＡＰＴルータ３２および外部サーバ４０に着目した様々な要素間の通信経路を示している。この図には、プロキシインターフェイスエージェント１１と外部サーバ４０との間のファイアウォール２６およびＮＡＰＴルータ３２を介した多重コネクション５１が示されている。この多重コネクション５１内には１つ以上の論理チャネル５２，５３がある。それらのうちの一つは制御チャネル５２であり、それ以外のチャネル５３はＨ．２２５ ＲＡＳ、Ｈ．２２５コールシグナリング、Ｈ．２４５、ＳＩＰ、ＭＧＣＰなどのシグナリングプロトコルを伝送している。その動作の一部を以下に説明するが、プロキシインターフェイスエージェント１１は外部サーバにプローブパケット（ｐｒｏｂｅ ｐａｃｋｅｔｓ）５５を送り、端末１０と外部サーバ４０との間のＵＤＰコネクション５６，５７を確立する。１つ以上の論理チャネルをＵＤＰコネクション５６，５７内に多重化し、たとえばＲＴＰおよびＲＴＣＰをなどのメディアを伝送するようにしてもよい。
【００８７】
プロキシインターフェイスエージェント１１は、動作条件に応じて数あるモードの一つで動作するようにできる。プロキシインターフェイスエージェント１１は原理的にプロトコルを認識しないか（ｐｒｏｔｏｃｏｌ ａｇｎｏｓｔｉｃ）認識するか（ｐｒｏｔｏｃｏｌ ａｗａｒｅ）のいずれかでありうる。プロトコルを認識しない場合には、外部サーバ４０はプロキシインターフェイスエージェント１１に任意の必要なＵＤＰソケットを開閉するように命じる。このモードは最も柔軟なモードであり、プロキシインターフェイスエージェント１１をアップグレードすることなしに、プライベートネットワークに加える新たなプロトコルを端末が採用することを可能にするものである。しかしながら、払うべき注意を怠れば、このモードはセキュリティを脅かすものとなる。なぜなら、第三者が不法な目的でプロキシインターフェイスエージェントにＵＤＰチャネルを開かせることができるかもしれないからである。そのためこのモードを採用する場合には、最低限プロキシインターフェイスエージェント１１が何らかのチェック（監査）を行うようにすることが推奨される。プロキシインターフェイスエージェント１１がプロトコルを認識する場合には、外部サーバ４０に命じられた際にポートを割り当てることができるが、それらポートが承認されたアプリケーションに用いられることを示す適宜のプロトコルシグナリングを認めるまではリレー（中継）機能を行うことができない。更に、プロキシインターフェイスエージェントがプロトコルを認識する場合には、外部サーバはプロトコルを認識するものである必要がない。なぜなら、その場合プロキシインターフェイスエージェントが、外部サーバに必要な関連づけを行うよう要求するすべてのインテリジェンスを有しているからであり、従ってプロキシインターフェイスエージェントはプロキシインターフェイスエージェントから外部サーバへのアウトバウンドコネクションにおいて設定される論理チャネルと送信先の通信システムとの間の正しい転送（即ち呼）を提供する。このモードは安全性において勝るが、新たなアプリケーションを導入する場合またはアプリケーションをアップグレードする場合の柔軟性において劣っている。簡便化するため、以下に説明する例ではプロキシインターフェイスエージェント１１はプロトコルを認識しないモードで動作するものと仮定する。
【００８８】
プロキシインターフェイスエージェント１１が有効になされると、プロキシインターフェイスエージェント１１は外部サーバのアドレスおよびポート４４，４６へのアウトバウンドＴＣＰコネクションを開始することによって外部サーバ４０への通信チャネルとしての多重コネクション５１を確立する（このコネクションは、一般的に認証式とされまた暗号化されるものであるが、こうした点は本明細書で述べるべき範囲を越えている。）
【００８９】
多重コネクション５１は複数のＴＣＰおよびＵＤＰセッション５２，５３に関する情報をトランスポート可能である。多重コネクション５１内のいくつかの論理チャネル、特に制御チャネル５２は固定的に割り当てられる。他の論理チャネルは必要に応じて動的に作成することができる。いくつかの論理チャネル５３はプロキシインターフェイスエージェント１１によって端末１０へ／端末１０からリレーされる。プロキシインターフェイスエージェント１１は（構成によっては外部サーバが）このような論理チャネルの各々に対して、プロキシインターフェイスエージェント１１と端末１０との間で用いられる特定のＴＣＰまたはＵＤＰコネクションのＩＰアドレスおよびポートを関連付けする。言い換えると、プロキシインターフェイスエージェントは端末の一つのトランスポートアドレスと一つの論理チャネルの自分側端部のトランスポートアドレスとの間の関連付けを行う。
【００９０】
初期設定の一部として、外部サーバ４０はプロキシインターフェイスエージェント１１にソケットを作成させ端末１０からの外向き呼試行（ｏｕｔｇｏｉｎｇ ｃａｌｌ ａｔｔｅｍｐｔｓ）および登録情報を待ち受けるようにしてもよい。
【００９１】
端末１０がその後ゲートキーパ／サーバに登録しようとする場合、そのようなメッセージ（Ｈ．２２５ ＲＡＳ、ＳＩＰ ＲＥＧＩＳＴＥＲなど）がプロキシインターフェイスエージェント１１に送られる。プロキシインターフェイスエージェント１１は論理チャネル５２，５３を介して外部サーバ４０に登録メッセージを転送する。応答は逆の経路を用いて送られる。外部サーバ４０は端末のプライベートトランスポートアドレス１４を、該登録が受理された多重コネクション５１の識別（ｉｄｅｎｔｉｔｙ）即ちトランスポートアドレスと共に記憶する。この情報があれば着信呼（ｉｎｃｏｍｉｎｇ ｃａｌｌ）を必要に応じて端末に転送することができる。
【００９２】
着信呼を確立するためには、外部サーバ４０はプロキシインターフェイスエージェント１１を介して端末１０へ向かう呼制御チャネル（Ｈ．３２３またはＳＩＰに対するＨ．２２５呼制御）を設定する必要がある。外部サーバ４０とプロキシインターフェイスエージェント１１との間に適宜の論理チャネル５３が存在していない場合には、そのような論理チャネルが作例される（ｉｎｓｔａｎｔｉａｔｅｄ）。このプロセスの一部として、プロキシインターフェイスエージェント１１がそれに対してＴＣＰまたはＵＤＰコネクション５４を作成すべき端末のトランスポートアドレス（ＩＰアドレスおよびポート）が特定される。論理チャネル５３を作成するために必要なメッセージが外部サーバ４０とプロキシインターフェイスエージェント１１との間で制御論理チャネル５２を用いて交換される。
【００９３】
呼制御シグナリング用の論理チャネルが形成されたなら、外部サーバ４０はＨ．３２３／ＳＩＰ呼生成メッセージ（Ｈ．３２３／ＳＩＰ ｃｒｅａｔｅ ｃａｌｌ ｍｅｓｓａｇｅ）（Ｈ．３２３用のＳｅｔｕｐ、ＳＩＰ用のＩＮＶＩＴＥなど）をプロキシインターフェイスエージェント１１に送ることができる。そしてプロキシインターフェイスエージェントは、論理チャネル５３が形成された際に確立したＴＣＰまたはＵＤＰコネクション５４を用いて、このメッセージを端末１０にリレーする。
【００９４】
Ｈ．３２３の場合には、外部サーバ４０と端末１０との間にＨ．２４５コネクションを確立する必要があるだろう。このコネクションが接続される端末内のアドレスは端末１０が外部サーバ４０に送り返す応答に含まれる。外部サーバ４０がこのようなＨ．２４５セッションを確立することを選択する場合には外部サーバ４０は呼シグナリングチャネルを作成したのと同じ手法で新たな論理チャネル５３を作成する。このプロセスの一部として、プロキシインターフェイスエージェント１１は端末の応答中で特定されたプライベートＩＰアドレスおよびポートに対するＴＣＰコネクションを確立する。
【００９５】
端末１０がプロキシインターフェイスエージェント１１に接続し、呼生成メッセージ（Ｈ．３２３用のＳｅｔｕｐ、ＳＩＰ用のＩＮＶＩＴＥなど）を送る際には、発信呼（ｏｕｔｇｏｉｎｇ ｃａｌｌ）に対するシグナリング経路が端末１０と外部サーバ４０間に形成され得る。この種のコネクション用の論理チャネルが多重コネクション５１内に存在していない場合は、プロキシインターフェイスエージェント１１が制御チャネル５２を用いてそのような論理チャネルを作成する。そしてプロキシインターフェイスエージェント１１はメッセージを外部サーバ４０にリレーする。
【００９６】
別個のＨ．２４５コネクションが発信呼に必要な場合は、外部サーバ４０は多重コネクション５１内に新たな論理チャネル５３を形成し、プロキシインターフェイスエージェント１１に待ち受けソケット（ｌｉｓｔｅｎｉｎｇ ｓｏｃｋｅｔ）を作成するよう指令する。作成されたソケットのアドレスとポートの数値は外部サーバ４０に返送される。なおこれはセットアップメッセージ（Ｓｅｔｕｐ ｍｅｓｓａｇｅ）に応答して送られるＨ．３２３シグナリングに含まれる。この情報により、端末１０がプロキシインターフェイスエージェント１１の作成した待ち受けソケットに接続することが可能になる。
【００９７】
ひとたび必要な着信および発信呼制御経路が設定されたならば、アウトバウンドおよびインバウンドのメディア経路（ｍｅｄｉａ ｐａｔｈｓ）を設定することが必要となるであろう。前に述べたように、現在規定されているすべてのＩＰベースのメディアアプリケーション（Ｈ．３２３、ＳＩＰ、ＭＧＣＰを含む）のメディア経路はＲＴＰを用いている。ＲＴＰはＵＤＰに基づいており、一方向ＲＴＰコネクションは送り方向と反対方向両方のＵＤＰ経路（ＵＤＰパス）の設定を要求する。従って、端末１０からプロキシインターフェイスエージェント１１を介して外部サーバ４０に至るＵＤＰ経路、および外部サーバ４０からまたプロキシインターフェイスエージェント１１を介して端末１０へ至るＵＤＰ経路を設定する必要がある。更に、ＲＴＰおよびＲＴＣＰコネクションはそれらが用いるポート間に固定した関係を要求する。従って、一度に単一のポートを開くことが可能であるのみならず、必要とされるＲＴＰ／ＲＴＣＰポート番号関係を有するＵＤＰポート対（複数）を開くことが可能である必要がある。従って、以下の説明では単一の接続を開くことを説明しているが、同様の原理を、同時にポート対（複数）を要求し、開くことに用いることができる。
【００９８】
以下の説明においては、Ｈ．３２３プロトコルを用いるものと仮定している。プロトコルメッセージと制御メッセージとのシーケンスは他のプロトコル（ＳＩＰやＭＧＣＰなど）では異なったものとなりうるが、原理は同一である。
【００９９】
端末１０と外部サーバ４０との間にＵＤＰ経路を設定するために、外部サーバ４０はプロキシインターフェイスエージェント１１に、端末１０が接続可能なＵＤＰポート（あるいはポート対）を開くよう指令する。外部サーバ４０はまたプロキシインターフェイスエージェント１１がコネクションと関連付けるべきトークン（ｔｏｋｅｎ）を特定する。
【０１００】
ポートが首尾よく開くと、プロキシインターフェイスエージェント１１は外部サーバ４０にポートの識別（ｉｄｅｎｔｉｔｙ）を示す。次に外部サーバは、端末１０がそのＵＤＰデータを送るべきプロキシインターフェイスエージェント１１のプライベートＩＰアドレスおよびポートを含むメディアチャネルを開くのに必要なシグナリングコマンドを発する（たとえばＨ．３２３の場合にはＨ．２４５開論理チャネル）。このコマンド（命令）を受信すると、プロキシインターフェイスエージェントは該コマンドをこの目的のためにあらかじめ確立されていたコネクションを用いて端末にリレーする。
【０１０１】
かくして端末１０はプロキシインターフェイスエージェント１１にＲＴＰ、ＲＴＣＰ、ＵＤＰパケット５６を送り始めることができる。しかし、これらのパケットを外部サーバ４０に転送する前に、プロキシインターフェイスエージェント１１はコネクションが最初に形成された時に外部サーバ４０によって特定されたトークンを含むプローブパケット５５を送らなければならない。ＮＡＰＴにおいてプライベートからパブリックへのアドレスマッピング（アドレスの対応付け）が作成されることに加えて、トークンの存在により、外部サーバ４０はこれらプローブパケット５５のソースから受け取ったＵＤＰパケット５７を正しい論理メディアチャネルと関連付けることができる。なお、プローブパケット５５を送るのが早すぎると、メディアデータ５６を送らないうちにＮＡＴによって作成されたアドレスマッピングがタイムアウトとなってしまうので、プローブパケット５５の送信をできる限り遅らせたほうがよい。また、プローブパケット５５はＵＤＰであるので、失われることがあり得ることに注意する必要がある。従って所与のコネクションに対して２つ以上のプローブパケット５５を送る機能を持つ必要がある。ひとたびプローブパケット５５が送られると、プロキシインターフェイスエージェントは受信したＵＤＰデータを外部サーバ４０にリレーすることができる（５７として示される）。別のやり方としては、トークン情報を、送られる各ＵＤＰパケットに多重化することもできる。更に、複数の論理チャネルを１つ以上のＵＤＰコネクションに多重化してもよい。
【０１０２】
動作方法はインバウンドＵＤＰコネクションに対しても同様である。外部サーバ４０プロキシインターフェイスエージェント１１に対して端末１０にＵＤＰデータを送ることのできるポート（あるいはポート対）を開くよう指令する。プロキシインターフェイスエージェント１１は外部サーバ４０にこのポートの識別（ｉｄｅｎｔｉｔｙ）を知らせる。そこで外部サーバはこの情報を、プロキシインターフェイスエージェント１１を介して端末１０に送られるメディアチャネルを開かせるためのプロトコル特定シグナリングコマンド（ｐｒｏｔｏｃｏｌ ｓｐｅｃｉｆｉｃ ｓｉｇｎａｌｉｎｇ ｃｏｍｍａｎｄ）の中に含ませる（たとえばＨ．３２３の場合はＨ．２４５開論理チャネル）。端末１０はこのコマンドに応答してそのコネクションにおいてＵＤＰデータを受信しようとするプライベートＩＰアドレスおよびポートを与える。このメッセージは外部サーバ４０へとリレー返送される。そこで外部サーバ４０はプロキシインターフェイスエージェント１１に、このコネクションにおいてプロキシインターフェイスエージェントがＵＤＰデータをリレーすべきアドレスを知らせる。更に、ＮＡＴにおけるパブリック対プライベートのアドレスマッピングを作成するために、外部サーバ４０はプロキシインターフェイスエージェント１１がトークンを含む当該コネクションについてのプローブパケット５５を外部サーバ４０に送ることを要求する。これによりプライベートからパブリックへのアドレスマッピングが作成され、そしてそれはまた逆方向に送られるデータのためのパブリックからプライベートへのアドレスマッピングとして機能する。外部サーバ４０はプローブパケット５５内のトークンを用いてこのセッション５７に対してどのＮＡＴアドレスおよびポートにＵＤＰデータを送るべきかを決定する。こうして外部サーバ４０はこのアドレスにＵＤＰメディアを送ることができるようになる。ＮＡＴはこれをプロキシインターフェイスエージェント１１にリレーし、そして今度はプロキシインターフェイスエージェント１１がこれを端末１０にリレーする（５６として示される）。かくしてコネクションが完了する。
【０１０３】
ＵＤＰコネクションがこれ以上要求されない場合、外部サーバ４０はプロキシインターフェイスエージェント１１に関連するソケットを閉じるように指令する。ＮＡＰＴのプライベートからパブリックへのアドレスマッピングは、情報が通過しないと、いずれタイムアウトとなる。
【０１０４】
以上の説明では外部サーバが単一のＩＰアドレスを有する単一のデバイスであると仮定したが、本発明の別の実施形態では「外部サーバ」は協働するいくつかのデバイスであってもよい。また、各外部サーバデバイス（単数または複数）は１つあるいは複数のＩＰアドレスを有してよい。複数のＩＰアドレスを用いる場合には、普通にはそれらを単一のサブネットから割り当て、そしてファイアウォール規則を個々のＩＰアドレスではなくサブネットの出入りに許容されたポートを特定するものとなるようにプログラミングする。
【０１０５】
なお、Ｈ．３２３端末のプライベートＩＰアドレスおよびポート番号は、実際上それがマッピングされるパブリックＩＰアドレスおよびポート番号と同一であってもよい。この場合マッピングは素通し（ｔｒａｎｓｐａｒｅｎｔ）となる。
【０１０６】
以上に説明した解決の利点は以下の通りである：
・ＮＡＴおよびファイアウォール機能をアップグレードする必要がない。
・信号の待ち時間が最小になる。
・各組織で必要となるのはプロトコルを認識しないプロキシインターフェイスエージェント（一つまたは複数）のみであり、そしてそれはどの適宜のリアルタイムプロトコルとも一緒に用いることができる。
・企業のＩＰアドレス（１つまたは複数）はその企業に対して呼を行うプロセスにおいて公知となることがない。
・サービス品質およびその他の使用法に基づく方針（たとえば帯域幅の利用）を断片的に行うことができ、首尾一貫した単一の解決手段を必要としない。たとえば、外部サーバはプロキシインターフェイスエージェントに対して、或るＱＯＳレベルの呼内のメディアストリームをプロキシインターフェイスエージェントと外部サーバとの間のコネクションに対して適切な方法を用いて処理するように指令し、そして外部サーバはそれをコアネットワーク内で外部サーバが獲得できる対応するＱＯＳレベルに対して対応付けすることができる。同様に、プロキシインターフェイスエージェントと外部サーバとの間において、呼の他の部分（区間（ｌｅｇｓ））に対して用いられるセキュリティ機構とは独立にある暗号化方式を用いてもよい。
【０１０７】
総括すれば、本発明はプライベートネットワーク内に配置されたＨ．３２３（あるいはその他のリアルタイムプロトコルに適合するエンドポイント）端末を許容する方法およびシステムであって：既存のセキュリティ手続きおよびセキュリティ方法を損なうことがなく；既存のファイアウォール、ルータ、プロキシをアップグレードする必要がなく；使用されている通信プロトコルを解釈するまたは認識するＮＡＴ機能なしにＩＰ接続に完全なＮＡＴを適用することを許容するようなものを提供する。本発明はまた、一つのプライベートネットワーク内にあるスタンダードなＨ．３２３装置が同じプライベートネットワークまたは異なるプライベートネットワークおよび／または公共の（パブリックな）ＩＰネットワーク内の他のＨ．３２３端末と、共有された即ち公共のＩＰネットワークを用いて、プロトコルに依存しないプロキシインターフェイスエージェントおよびＨ．３２３プロキシサーバを介して通信することを可能にするものである。
【０１０８】
従って事業体は共有されたＩＰネットワークの共有されたリソースを加入契約利用することができる。コストは最小限のものであり、セキュリティが損なわれることもない。
【図面の簡単な説明】
【図１】
２つの企業間において音声呼またはマルチメディア呼を行うための本発明による通信システムの図式的な説明図であり、プロキシインターフェイスエージェントがエンドポイントと同じ場所にある場合を示している。
【図２】
図１と同様の図式的説明図であるが、プロキシインターフェイスエージェントがエンドポイントから離れたところにある点で相違している。
【図３】
図１および図２に示す通信システムの図式的説明図であり、アウトバウンド通信およびインバウンド通信の両方に対するアウトバウンド接続の論理チャネルを、一つの企業のローカル端末と外部サーバの間について示す図である。

Claims (27)

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. プロキシインターフェイスエージェントに対して２つ以上のローカル端末が存在する請求項２乃至２４のいずれかに記載の方法。
26. プロキシインターフェイスエージェントは異なるリアルタイムまたは非リアルタイムのプロトコルを用いて、同時に複数の端末を代理して動作する請求項２乃至２５のいずれかに記載の方法。
27. 外部サーバは異なるリアルタイムまたは非リアルタイムのプロトコルを用いて、同時に複数の端末および／または複数のプロキシインターフェイスエージェントの代理として動作する請求項２乃至２６のいずれかに記載の方法。

Images