JP4351449B2 - Ｉｐテレフォニーを実行するためのシステムおよび方法 - Google Patents

Description

本発明は、テレフォニーの分野に関し、より詳細には、インターネット・プロトコル（ＩＰ）ベースのテレフォニーに関する。

インターネット・プロトコル上での音声通信（ＶｏＩＰ）とは、適切なサービス品質（ＱｏＳ）と優れたコスト／利益を有するＩＰベースのデータ・ネットワークを介して電話を掛け、ファックスを送信するための技術のことである。ＶｏＩＰ開発の主要な理由は以下のように要約することができる。

コスト削減：ＶｏＩＰ技術は長距離電話のコストを大幅に節約することができる。これは、大部分の企業、特に国際市場を相手にする企業にとっては非常に重要なことである。

簡素化：統合された音声／データ・ネットワークはさらに標準化を進め、全体的な機器の必要性を低減する。

整理統合：故障点を除去し、アカウンティング・システムを整理統合し、オペレーションを結合し、より効率的なオペレーションを提供する機能。

拡張型アプリケーション：ＶｏＩＰの長期に渡る利点には、現在の電話システムにはそのための装備がなされていないマルチメディアおよびマルチサービス・アプリケーションに対するサポートが含まれる。

近い将来にＶｏＩＰ市場が著しく成長することが期待される。しかし、ＶｏＩＰ機器の開発者には、音声品質、待ち時間、およびパケット損失と、呼制御およびシステム管理のどちらの点でも多くの課題が残されている。主な課題は、登録済みＩＰバージョン４アドレスの取得および使用に関する厳しい制約、これによって生じるネットワーク・アドレス変換（ＮＡＴ）および関連技術を使用する必要性、既存のファイアーウォール技術の限界、およびＭＥＧＡＣＯ、ＲＴＰおよびＲＴＣＰのようなＶｏＩＰプロトコルのアプリケーション層の規定である。

インターネット番号用米国登録（ＡＲＩＮ）は、インターネットの人気の高まりと、残存する使用可能なアドレスの急速な枯渇により、経路指定可能なパブリックＩＰアドレスの割り振りに厳しい制約を科した。アドレス空間を保存するために、ＡＲＩＮはエンド・ユーザにアドレス空間を保存するようＮＡＴ技術を使用することを強く奨励している。ＮＡＴの最も一般的な実施態様はＮＡＰＴ、すなわちネットワーク・アドレス・ポート変換である。これにより単一のパブリックＩＰアドレスを、プライベート（ＲＦＣ１９１８）アドレスを使用する数千ものホストをサポートするために使用することができる。ＮＡＴの主な問題は、ＩＰヘッダーのソースＩＰアドレスとポート情報だけを変更し、ペイロードのどこも変更しないということである。典型的なＶｏＩＰプロトコルは、発呼者の識別および呼の経路指定のためにペイロード中のホストのＩＰとポート情報とを使用する。したがって、メディア・ゲートウェイ・コントローラ（ＭＧＣ）またはトランキング・ゲートウェイ（ＴＧ）が、情報の衝突するエンド・ノードから通信を受信する際、非常に多くの問題が生じる危険性がある。本明細書で使用する「トランキング・ゲートウェイ」という用語は、複数のアナログ入力を同時に受信し、この信号を複数の対応するＩＰデータ・ストリームにエンコードする任意のデバイスを意味することに留意されたい。トランキング・ゲートウェイは、複数のＩＰデータ・ストリームにエンコードされた複数の信号を同時に取り、それを複数の対応するアナログ信号に変換する逆の機能を実行することもできる。

ＮＡＴプロセスは動的でもあるので、進行中のセッションの期間だけホストに特定のポート番号が関連付けられることになる。次のセッションはほぼ確実に別のポートを介することになる。この問題は、直接通信する必要のある２つのエンド・ノードが同一のプライベートＩＰアドレスを使用している可能性があることによりさらに深刻化する。

別の問題はファイアーウォールに関するものである。ファイアーウォールは、通常、外部ネットワークから内部ネットワークを保護するように設計されており、一般に、ネットワークが脆弱な状態で放置されないようセッションが何時オープンし、何時クローズするかを知る必要がある。インターネットで使用されるほとんどのプロトコルはＴＣＰベースであり、したがってファイアーウォールは、ＳＹＮおよびＦＩＮメッセージに基づいて何時セッションがオープンし、何時クローズしたかを決定することができる。残念ながら、ほとんどのＶｏＩＰプロトコルはＵＤＰベースであり、したがってファイアーウォールが検出できるＳＹＮおよびＦＩＮメッセージを使用しない。さらに複雑な問題は、ＶｏＩＰプロトコルが、ネットワーク内部と外部の両方から開始される通信用に対のポートを使用することがしばしばあることである。ファイアーウォールは、どちらかと言えば内部から開始された単一ポート通信のみをサポートするものである。さらに、ＩＰ電話間の三角化した通信は、後述する「三角問題」と称される特定の問題を提起する。

ＮＡＴで機能しない上位層プロトコルに対する従来の解決策は、アプリケーション・レベル・ゲートウェイ（ＡＬＧ）である。ＡＬＧは、標準ＮＡＴ機能によって置き換えられる情報と一致するように使用される様々なプロトコル（ＭＥＧＡＣＯ、ＲＴＰ、ＲＴＣＰ）のペイロードのＩＰアドレスとヘッダー情報とを変更することによりプロキシとして動作する。さらに、ＡＬＧは、通常、これらのプロトコルをサポートするために必須の任意の特定ポートまたはポート範囲を予約するためＮＡＴゲートウェイと「交渉」する。これは、ＩＣＭＰおよびＦＴＰ、また最近ではＨ．３２３およびＳＩＰ（先行する２つのＶｏＩＰ標準）のような様々なプロトコルに対して行われており、パブリックＩＰからプライベートＩＰへの通信の基本的な問題を解決するものである。対応されないのは、図１に示す三角化した経路指定のようなさらに複雑な対話である。図１に示すように、メディア・ゲートウェイ・コントローラ（ＭＧＣ）５０は、アプリケーション・レベル・ゲートウェイ７０に結合されている。ＡＧＬ７０は、２つのＩＰ電話２０Ａと２０Ｂにそれぞれ結合されている。ＩＰ電話２０は相互にも直接的に結合されている。ＩＰ電話２０ＡがＡＬＧ７０を介した呼セットアップのためにメディア・ゲートウェイ・コントローラ５０に接触し、ＭＧＣ５０はＡＬＧ７０を介して（ＩＰ電話２０Ａと同じネットワーク上の）ＩＰ電話２０Ｂに接触し、ＩＰ電話２０Ｂがローカル・ネットワーク上のＩＰ電話２０Ａへの接触を試みる場合、ＩＰ電話２０Ａと２０Ｂの間のＡＬＧ７０はプライベート・アドレス情報を適宜訂正するだけで十分なところまで性能を高める必要がある。

ＡＬＧ７０がすべての内部ホスト（ＩＰ電話２０）のローカル・テーブルを維持し、ＭＧＣ５０から着信する呼宛先アドレス情報を検査し、それを内部ホスト２０に経路指定する際にそれを変更するか否かを判断する必要があることを考慮すると、上記の問題は非常に複雑化する。代替形態は、宛先が内部ネットワーク内にあるか否かに関わらずＡＬＧ７０を介してすべてのトラフィックを経路指定し、ＡＬＧ機能を実行し、次いでＮＡＴ機能を２回、次にＡＬＧ機能を再び実行し、次いでそれを同じインターフェースに経路指定して戻す。この非常に複雑なプロセスがすべての単一のパケットに対して要求され、システムは非常に非効率的になる。

したがって、ＩＰテレフォニーに関する改善されたシステムおよび方法が望まれる。

本発明は、ＩＰテレフォニーを実行するためのシステムおよび方法の様々な実施態様を含む。一実施態様では、システムは、ネットワーク、ＩＰ電話またはトランキング・ゲートウェイのような少なくとも１つのメディア・ゲートウェイ、ネットワークを介してメディア・ゲートウェイに結合するよう動作可能なサービス・ゲートウェイ、ネットワークを介してサービス・ゲートウェイと少なくとも１つのメディア・ゲートウェイに結合するよう動作可能なメディア・ゲートウェイ・コントローラを含む。

一実施態様では、メディア・ゲートウェイはＩＰ（インターネット・プロトコル）電話である。ＩＰ電話をまず起動する。これに応答して、サービス・ゲートウェイはＩＰ電話とクライアントＤＨＣＰリースを交渉する。サービス・ゲートウェイは、ＩＰ電話に割り当てるポート番号の範囲を決定するためにＩＰ電話の識別子、例えばベンダーＩＤを使用する。すなわち、サービス・ゲートウェイは、ＩＰ電話からその識別子を受信し、その識別子が有効な場合は、そのポート範囲をそのＩＰ電話に割り当てる。一実施態様で、サービス・ゲートウェイは、ベンダーＩＤに加えてＩＰ電話のＭＡＣ ＩＤを受信する。サービス・ゲートウェイは、ＩＰ電話に対するＭＡＣ ＩＤが有効であるか否かを判定し、そのＭＡＣ ＩＤが有効であると判定された場合は、その識別子が有効であるか否かを判定する。

ポート番号の範囲は、他のＩＰプロトコルが使用するために予約されていない１つまたは複数のポート番号を含む。クライアントＤＨＣＰリース交渉は、サービス・ゲートウェイに対してＤＨＣＰ発見メッセージを発行するＩＰ電話を含み、その識別子が有効であると判定された場合、サービス・ゲートウェイはＩＰ電話にＤＨＣＰオファーを発行する。ＤＨＣＰオファーは、ポート番号の範囲のような検証された識別子とそのＩＰ電話に対する動作可能なソフトウェアを示す情報とに基づくＤＨＣＰリース情報を含む。サービス・ゲートウェイはＤＨＣＰリース情報を記憶する。ＩＰ電話は、ＤＨＣＰリース情報を記憶し、そのＤＨＣＰリース情報に含まれるＤＨＣＰ設定を可能にする。

次いでサービス・ゲートウェイおよびＩＰ電話はＩＰ電話を初期化するよう動作する。一実施態様では、ＩＰ通信を可能にするために指示されたオペレーショナル・ソフトウェアを実行することによってＩＰ電話を初期化する。一実施態様では、ＩＰ電話はオペレーショナル・ソフトウェアに対する要求を発行し、その後、サービス・ゲートウェイはそのオペレーショナル・ソフトウェアをＩＰ電話に提供し、次いでそのＩＰ電話はその提供されたオペレーショナル・ソフトウェアを実行してＩＰ通信を可能にする。一実施態様では、ＩＰ電話は、ファイル転送サーバ、例えば簡易ファイル転送プロトコル（ＴＦＴＰ）サーバなどに対してオペレーショナル・ソフトウェアの読取要求を発行し、次いでそのファイル転送サーバはそのオペレーション・ソフトウェアをＩＰ電話に提供する。一実施態様では、ファイル転送サーバはサービス・ゲートウェイに含まれる。

一実施態様では、ＩＰ電話は、呼セットアップ・プロセスの前に、例えばメディア・ゲートウェイ・コントローラによってシステムにより登録する。例えば、ＩＰ電話はＩＰ電話のパブリックＩＰアドレスをメディア・ゲートウェイ・コントローラに送信し、メディア・ゲートウェイ・コントローラはそのＩＰ電話のパブリックＩＰアドレスを受信して記憶する。一実施態様では、ＩＰ電話は、ＩＰ電話のプライベートＩＰアドレスをメディア・ゲートウェイ・コントローラに送信することもでき、そのメディア・ゲートウェイ・コントローラはＩＰ電話のプライベートＩＰアドレスを受信して記憶する。メディア・ゲートウェイ・コントローラは、例えばルックアップ・テーブルを使用することによってプライベートＩＰアドレスを決定するためにパブリックＩＰアドレスとポート範囲を使用するよう動作可能であってよい。

登録後、割り当てられたポート範囲内の１つまたは複数のポートを使用してＩＰ電話を使用したＩＰ通信を行うことができる。例えばサービス・ゲートウェイは、ＩＰ電話と、他のＩＰ電話または特にトランキング・ゲートウェイのようなＩＰデバイスとの間のＩＰ通信を仲裁することができる。

一実施態様では、ＩＰ電話を使用したＩＰ通信を実行するステップは、サービス・ゲートウェイが、プライベート・ソースＩＰアドレス、割り当てられたポート番号の範囲内のソース・ポート番号、およびＩＰデバイスに関連付けられた宛先情報を含むデータ・パケットをＩＰ電話から受信するステップを含む。次いでサービス・ゲートウェイは、そのデータ・パケットに対してネットワーク・アドレス永続ポート変換（ＮＡＰＰＴ）を実行し、そのデータ・パケットをＩＰデバイスに送信する。データ・パケットに対してＮＡＰＰＴを実行するステップは、ソース・ポート番号は変更せずに残しながらプライベート・ソースＩＰアドレスをパブリック・ソースＩＰアドレスに変更するステップを含み、パブリック・ソースＩＰアドレスとソース・ポート番号はＩＰ電話を一意に識別するために使用される。

別の実施態様では、ＩＰ電話を使用したＩＰ通信を実行するステップは、サービス・ゲートウェイが、パブリック宛先ＩＰアドレス、割り当てられたポート番号の範囲内の宛先ポート番号、およびソース情報を含むデータ・パケットをＩＰデバイスから受信するステップを含み、ＩＰ電話を一意に識別するためにパブリック宛先ＩＰアドレスと宛先ポート番号を使用する。次いでサービス・ゲートウェイは、そのデータ・パケットに対してネットワーク・アドレス永続ポート変換（ＮＡＰＰＴ）を実行し、そのデータ・パケットをＩＰ電話に送信する。宛先から受信したデータ・パケットに対してＮＡＰＰＴを実行するステップは、ＩＰ電話を一意に識別するためにパブリック宛先ＩＰアドレスと宛先ポート番号を使用するステップと、宛先ポート番号を変更せずに残したままＩＰ電話のパブリック宛先ＩＰアドレスをプライベート・ソースＩＰアドレスに変更するステップとを含む。

一実施態様では、上記方法の様々な実施態様をメモリ媒体に含めることができる。別の実施態様では、上記方法の様々な実施態様を複数のメモリ媒体に含めることができる。この複数のメモリ媒体は、ＩＰ電話プログラム命令を記憶する１つまたは複数のＩＰ電話メモリ媒体、サービス・ゲートウェイ・プログラム命令を記憶するサービス・ゲートウェイ・メモリ媒体、およびメディア・ゲートウェイ・コントローラ・プログラム命令を記憶するメディア・ゲートウェイ・コントローラ・メモリ媒体を含み、これら複数のメモリ媒体に含まれるプログラム命令は上記方法の様々な実施態様を実行するよう実行可能である。

一実施態様では、システムは、ネットワーク、ネットワークを介して結合された複数のメディア・ゲートウェイ、並びにネットワークを介してメディア・ゲートウェイに結合されたメディア・ゲートウェイ・コントローラを含む。

一実施態様では、メディア・ゲートウェイ・コントローラは、ソースＩＰアドレスと宛先電話番号とを含む呼セットアップ要求を受信する。メディア・ゲートウェイ・コントローラは、ソースＩＰアドレスに基づいて第１のメディア・ゲートウェイを選択し、宛先電話番号に基づいて第２のメディア・ゲートウェイを選択する。

メディア・ゲートウェイ・コントローラは、第１のメディア・ゲートウェイのパブリックＩＰアドレスを第２のメディア・ゲートウェイのパブリックＩＰアドレスと比較し、第１のメディア・ゲートウェイのパブリックＩＰアドレスが第２のメディア・ゲートウェイのパブリックＩＰアドレスと同一である場合、呼セットアップのために第１のメディア・ゲートウェイのプライベートＩＰアドレスと第２のメディア・ゲートウェイのプライベートＩＰアドレスとを選択する。メディア・ゲートウェイのパブリックＩＰアドレスが同一である場合、これらはシステムの内部であるということに留意されたい。第１のメディア・ゲートウェイのパブリックＩＰアドレスが第２のメディア・ゲートウェイのパブリックＩＰアドレスと同一でない場合、メディア・ゲートウェイ・コントローラは、呼セットアップのために第１のメディア・ゲートウェイのパブリックＩＰアドレスと第２のメディア・ゲートウェイのパブリックＩＰアドレスとを選択する。これは、コール・セッションが、内部ＩＰ電話（例えば第１のメディア・ゲートウェイ）と電話のような外部デバイスとの間でトランキング・ゲートウェイ（例えば第２のメディア・ゲートウェイ）を介して通信している場合について説明している。したがって一実施態様で、第１のメディア・ゲートウェイと第２のメディア・ゲートウェイは、それぞれにＩＰ電話またはトランキング・ゲートウェイの１つを含み、トランキング・ゲートウェイは公衆交換電話網（ＰＳＴＮ）に対するインターフェースを含んでいる。

一実施態様では、メディア・ゲートウェイ・コントローラは、第１のメディア・ゲートウェイの選択されたＩＰアドレスを第２のメディア・ゲートウェイに送信し、第２のメディア・ゲートウェイの選択されたＩＰアドレスを第１のメディア・ゲートウェイに送信する。この場合、第１のメディア・ゲートウェイは、第２のメディア・ゲートウェイの選択されたＩＰアドレスを使用して第２のメディア・ゲートウェイにデータを送信し、第２のメディア・ゲートウェイは、第１のメディア・ゲートウェイの選択されたＩＰアドレスを使用して第１のメディア・ゲートウェイにデータを送信する。

一実施態様では、メディア・ゲートウェイ・コントローラは、上述のように呼セットアップ要求を受信する前に第１および第２のメディア・ゲートウェイを登録する。一実施態様では、メディア・ゲートウェイを登録するステップは、各メディア・ゲートウェイのパブリックＩＰアドレスを受信して記憶するステップを含む。別の実施態様では、メディア・ゲートウェイを登録するステップは、各メディア・ゲートウェイのプライベートＩＰアドレスを受信して記憶するステップも含む。

したがって、上記のシステムおよび方法の様々な実施態様は、２つの内部ＩＰ電話が関与するコール・セッションと、内部ＩＰ電話と例えば外部電話のような外部デバイスとインターフェースするトランキング・ゲートウェイのコール・セッションとを区別する。

以下の図面と共に以下の好ましい実施形態の詳細な説明を検討することにより本発明をよりよく理解することができよう。

本発明には様々な修正形態および代替形態が可能であるが、その具体的な実施形態を一例として図示し、本明細書で詳細に説明する。しかしこれら図面および詳細な説明は開示される特定の形態に本発明を限定することを意図するものではなく、反対に首記の特許請求の範囲によって定義される本発明の趣旨および範囲内のすべての修正形態、等価形態、および代替形態を対象とすることを意図するものであるということを理解されたい。

図２：ＶｏＩＰシステム
図２は、企業または他の組織に対してＩＰテレフォニー・サービスを提供するＶｏＩＰシステムの一実施形態を示している。図２のシステムは、１つまたは複数のＩＰ電話１２０Ａおよび１２０Ｂを含んでいる。本明細書で使用する「ＩＰ電話」および「メディア・ゲートウェイ」という用語は、インターネット・プロトコル（ＩＰ）のようなネットワーク・プロトコルを使用するよう動作する任意のテレフォニー・デバイスまたは通信デバイスを含むことを意図している。したがってＩＰ電話１２０は、トランキング・ゲートウェイのようなメディア・ゲートウェイである。換言すれば、ＩＰ電話またはメディア・ゲートウェイは、アナログ入力を受信して、その信号をＩＰデータ・ストリームにエンコードするデバイスである。このデバイスは、ＩＰデータ・ストリームにエンコードされた信号を取り、それをアナログ信号に変換する逆の機能を実行することもできる。好ましい実施形態でＩＰは使用されるネットワーク・プロトコルであるが、他のネットワーク・プロトコルの使用も想定される。本発明の無線の実施形態も想定されることに留意されたい。ＶｏＩＰシステムのいくつかの実施形態では、ＩＰ電話１２０とＩＰデバイスの間で通信を仲裁することができる。ＩＰデバイスはインターネット・プロトコルのパケットを送受信することのできるインターフェースを有する、別のＩＰ電話を含む任意のデバイスであってよいということにも留意されたい。

図２に示すように、ＩＰ電話１２０Ａと１２０Ｂはサービス・ゲートウェイ（ＳＧ）１７０に結合されている。本明細書で使用する「サービス・ゲートウェイ」という用語は、ＩＰ電話１２０の間（または他のメディア・ゲートウェイの間）、並びにＩＰ電話１２０と、他のネットワークの電話、トランキング・ゲートウェイ、または中でもＰＳＴＮ（公衆交換電話網）、ＩＳＤＮ（統合サービス・デジタル・ネットワーク）、またはＦＤＤＩ（光ファイバー分散データ・インターフェース）の電話またはデバイスのような外部デバイス（例えばＩＰデバイス）との間の電話呼び出しなどの遠隔通信を仲裁するよう動作する任意のシステムまたはデバイスを含むことを意図している。

一実施形態では、ＩＰ電話１２０ＡはＩＰ電話１２０Ｂにも結合されている。サービス・ゲートウェイ１７０は、図示するようにメディア・ゲートウェイ・コントローラ（ＭＧＣ）１５０に結合されている。一実施形態では、ＩＰ電話１２０、サービス・ゲートウェイ１７０、およびメディア・ゲートウェイ・コントローラ１５０は、それぞれに本発明の一実施形態の少なくとも一部を実行するソフトウェアおよび／またはハードウェアを含む。例えば、上記の「三角形分割」問題に対処するため、ＳＧ１７０は、企業のネットワーク外で発信され、または終了する呼から内部の呼を識別するように動作可能な論理またはソフトウェアを含む。このプロセスの詳細を図３Ａから１１を参照して以下に説明する。

一実施形態で、システムは、高度な可用性／故障耐性のＩＰテレフォニー・ネットワークを提供するために登録済みＩＰアドレスを使用してプライベートＩＰバックボーンを実施する。システムは、急速な成長を容易にする拡大縮小可能な設計を有することができ、ネットワークの輻輳を低減または防止するためにキャパシティ・プラニングを実施することができる。さらに、システムは、将来の用途をサポートするために柔軟な設計を有する。例えば、様々な実施形態で、システムはほぼすべてのアクセス技術に対するサポートを提供することが想定される。システムは、効率的で対費用効果の高い高品質なＩＰベースの遠隔通信システムを提供するために、データ経路、帯域幅割り振り、および待ち時間／ジッターを制御する、ＱｏＳ（サービス品質）、ＭＰＬＳ（マルチプル・プロトコル・ラベル・スイッチング）、ＲＳＶＰ（資源予約プロトコル）などのトラフィック・エンジニアリングをさらに使用する。

様々な実施形態で、国内のＩＰテレフォニー・システムまたは国際的なＩＰテレフォニー・システムさえも提供するためにシステムを使用するということも想定されている。システムは、ポイント・オブ・プレゼンス（ＰｏＰ）を介して顧客とシステムの間を接続するために、すなわち各チャネル・パートナーへの接続やローカルＰＳＴＮネットワークへの接続の接続点となるために、各メトロポリタン・サービス・エリア（ＭＳＡ）のローカル・インターネット・サービス・プロバイダ（本明細書ではチャネル・パートナーと称する）と提携する。

例えば、一実施形態では、各ＭＳＡに対するＶｏＩＰネットワーク・コンポーネントは、ポイント・オブ・プレゼンス（ＰｏＰ）、Ｃｏｒｅまたは地域集約点、および様々なソフト・スイッチ・エレメント、ＳＳ７ゲートウェイ、トランキング・ゲートウェイなどを含むＡｐｐを含む。一実施形態では、ＡｐｐおよびＣｏｒｅはコ・ロケート(co-locate)される。ネットワーク・ハードウェア・コンポーネントに関するさらなる詳細を図３Ａおよび３Ｂを参照して以下に示す。

図３Ａ：基本的なサービス・ゲートウェイおよびＶＰＮの図面
図３Ａは、サービス・ゲートウェイ１７０およびバーチャル・プライベート・ネットワーク（ＶＰＮ）を含む本システムの一実施形態の図面である。図３Ａに示すように、システムの少なくとも一部は顧客施設３００に実装される。システムの他の態様では、顧客施設３００の外で、例えば図示するようにシステムのＰｏＰ３５０内に実装される。

図３Ａに示すように、顧客施設３００にあるシステムのコンポーネントは、ＩＰ電話１２０Ａおよび１２０Ｂのような１つまたは複数のＩＰ電話１２０を含む。ＩＰ電話１２０はそれぞれ、イーサネット（登録商標）・スイッチ１３４Ａを介してサービス・ゲートウェイ１７０に結合されている。サービス・ゲートウェイは、図示するように第２のイーサネット・スイッチ１３４Ｂを介して顧客のファイアーウォール１３２に結合されている。顧客のファイアーウォール１３２は、第３のイーサネット・スイッチ１３４Ｃを介して顧客のルータ１３０に結合されている。

一実施形態では、顧客のルータ１３０はシステムの施設外コンポーネント、すなわちＶｏＩＰ ＰｏＰ３５０へアクセスするチャネル・パートナー１４０に結合されるように動作可能である。上述のように、チャネル・パートナー１４０は、インターネット・アクセスなどのネットワーク・アクセスを顧客に提供するように動作可能なインターネット・サービス・プロバイダを含むことが好ましい。システムのＰｏＰ部分は、チャネル・パートナー１４０に結合されるように動作可能なＰｏＰルータ１３８を含む。ＰｏＰルータ１３８は、イーサネット・スイッチ１３４Ｄを介してＶＰＮコンセントレータ１３６に結合されている。（コンセントレータは、すべての個々のチャネルが同時にアクティブであることが可能な方法で複数のチャネルを単一の伝送媒体に結合している一種のマルチプレクサである。）最後に、ＶＰＮコンセントレータはイーサネット・スイッチ１３４Ｅを介してメディア・ゲートウェイ・コントローラ１５０に結合されている。上記の構成は１つの例であって、他の構成を想定できるということに留意されたい。例えば、様々な実施形態に本システムを実装するために、図面より少ないか、または多いイーサネット・スイッチ１３４を使用する。

上述のように、サービス・ゲートウェイ１７０は、システムの一部を実現する論理および／またはソフトウェアを含む。ＳＧ １７０はＡＬＧ ７０（従来技術）とは大幅に異なることに留意されたい。例えば、ＳＧ １７０に高レベルのプロトコルを認識させて複雑な判定を実行するのではなく、動的ホスト・コントローラ・プロトコル（ＤＨＣＰ）および他のサービスと共に修正されたＮＡＰＴ機能のためにＳＧ １７０を使用する。各主要機能の実施形態を以下で詳述する。

ハードウェア・プラットフォーム
一実施形態では、ＳＧ １７０は、組み込み型交流電源機構を有する小型ファクター・デバイスまたはラック取付可能（１９”ラック）ユニットであってよい。ＳＧ １７０は、少なくとも２つの１０Ｍビットのイーサネット・インターフェース、好ましくは１０／１００Ｍビットを提供する。このインターフェースは８０２．１ｑＶＬＡＮトランキングをサポートする。このユニットは、必要に応じてＳＮＭＰ管理、テルネット・アクセス、最低２Ｍバイトのフラッシュ・メモリ、およびコマンド行アクセス用シリアル・インターフェースも含む。

ＳＧアドレス指定
ＳＧ １７０は、ＩＰＳｅｃ ＶＰＮトンネルに対するソースおよび宛先アドレスとして単一のパブリックＩＰアドレスを使用する。このアドレスは、アクティブなＳＧ １７０と待機ＳＧ １７０間で共有する。ＳＧ １７０は、ＶｏＩＰプロトコル・サポートを必要とするすべての内部ホストに対してＮＡＴサポートを提供するために単一のパブリックＩＰアドレスを使用する。ＩＰ電話１２０などの多数の内部ホストをサポートするために追加のＮＡＴアドレスを使用することもできる。このアドレスもアクティブなＳＧ １７０と待機ＳＧ １７０間で共有する。内部インターフェースの場合、ＳＧ １７０は各ＶＬＡＮインターフェースに対するバーチャルＩＰアドレスをサポートする必要がある。

経路指定
ゲートウェイおよびＶＰＮデバイスとして、ＳＧ １７０は様々な経路指定機能をサポートしている。具体的には、無数の静的ルート（例えば少なくとも１００）に対するサポートを提供する。さらなる経路指定プロトコルのサポート（例えばＯＳＰＦおよびＲＩＰバージョン２）を想定することもできる。ＳＧ １７０はすべてのＩＰ電話１２０に対するディフォルトのゲートウェイであり、したがってトラフィックがどこに経路指定されるべきか、すなわちそれがＮＡＴされ（またはＮＡＰＰＴされ）て、ＶＰＮインターフェースが送信されるべきか、または内部物理インターフェース（イーサネット）または論理インターフェース（ＶＬＡＮ）に経路指定されるべきかを判定する。

ＮＡＴ／ＮＡＰＴ／ＮＡＰＰＴ
ポートをＩＰ電話に動的に割り当てる代わりに、ＳＧ １７０は、図５Ａおよび５Ｂを参照して後述するＤＨＣＰプロセス中にＳＧ １７０がＳＧ １７０のリースを取得する際に各ＩＰ電話１２０に対してポート番号を割り当てることができる。ＳＧ １７０は、内部ホストおよびポートに対する外部ＩＰアドレスおよびポートの半永続的マッピングのテーブルを維持する。ＳＧ １７０は、内部の、すなわちプライベート・ソースＩＰアドレスをＮＡＴした外部ソースＩＰアドレスで置き換え続けることができる。しかし、正しい内部ホストが割り当てられたポート範囲を使用していることを保証するようにこれを検証することはできるが、ポート情報を修正することはできない。このようなネットワーク・アドレス変換をネットワーク・アドレス永続ポート変換（ＮＡＰＰＴ）と称する。

ＤＨＣＰ
一実施形態では、ＳＧ １７０はＤＨＣＰに対するサポートを提供する。ＳＧ １７０は、ＳＧサービスを提供するホストに対するＤＨＣＰサーバであってよい。ＳＧ １７０は、複数のＩＰサブネット（８０２．１ｑトランクを介してアクセスされる各ＶＬＡＮにつき１つのサブネット）に対して複数の範囲をサポートする。具体的には、ＤＨＣＰを介してＳＧ １７０は次の１つまたは複数を実行する。すなわち、ＩＰアドレスおよびネットワーク・マスクを割り当てること、ＳＧ １７０をディフォルトのゲートウェイに設定すること、ＤＮＳドメインを適切な値に設定すること、ＳＧ １７０をＴＦＴＰ／ＢＯＯＴＰサーバに設定すること、ブート・イメージに対して経路およびファイル名を提供すること、およびホスト名を設定することである。

一実施形態では、ＳＧ １７０は２つのその時点では未定義のＤＨＣＰオプションを発行することもできる。これらは未定義なので、割り当てられていないＤＨＣＰオプション番号（１２７−２５５）を使用する。ＳＧ １７０は、それ自体が使用するために各ＩＰ電話にＩＰポートの範囲を割り当て、ソフト・スイッチのＩＰアドレスを提供する。一実施形態では、ＳＧ １７０は、ＳＧ １７０がそれらのトラフィックのためにどのＮＡＴアドレスが使用中であるかをＩＰ電話１２０に通知する。

一実施形態では、ＤＨＣＰサービスはＭＡＣベースの予約を実行することもできる。例えば、これは、割り当てる前にはＩＰアドレスを使用しないことを保証する（ピン検証）。別の実施形態として、これは、特定のクライアントＩＤを有するホストにのみアドレスを割り当てるよう動作可能である（他のホストがアドレスを取得するのを防止するために）。一実施形態では、ＳＧ １７０はＭＡＣ範囲内にないホストから着信したＤＨＣＰリース要求を無視する。冗長性をサポートするために、アクティブなＳＧ １７０の故障が発生した場合にすべての登録の整合性を確保するためにＤＨＣＰリース情報を待機ＳＧ １７０と同期させる。

簡易ファイル転送プロトコル（ＴＦＴＰ）
一実施形態では、ＳＧ １７０は、ＴＦＴＰサーバなどのファイル転送サーバとして動作することもできる。ＩＰ電話１２０は、ブート時にＳＧ １７０から初期化ソフトウェアなどのソフトウェアをダウンロードする。したがってＳＧ １７０は、この初期化ソフトウェアを記憶するために少なくとも２メガバイトのフラッシュ・メモリなどのメモリを含む。アクティブなＳＧ １７０のフラッシュは待機ＳＧ １７０のフラッシュに自動的に、または手動によりコピーする。

バーチャル・プライベート・ネットワーク（ＶＰＮ）
呼セットアップおよび進行中の呼のセキュリティのため、並びに経路指定アーキテクチャを簡素化するために、一実施形態により複数のＩＰＳｅｃ（ＩＰセキュリティ）ＶＰＮ ＥＳＰ（セキュリティ・ペイロード・カプセル化）トンネルに対するサポートを提供する。ＳＧ １７０の外部インターフェースはこのトンネルの一端であってよく、ＶＰＮコンセントレータ１３６はこのトンネルの他端（顧客の都市に使用されているＰｏＰに置かれる）であってよい。さらに、顧客のプライベート・ネットワークの範囲内にある二次ＶＰＮコンセントレータ１３６と他のＳＧ １７０を有するトンネルを維持する機能を提供する。ＶＰＮトンネルに対して使用される外部ＩＰアドレスは、ＮＡＴ機能に対して使用される外部ＩＰアドレスとは異なる場合がある。顧客の解決策およびシステム・ネットワークの経路指定アーキテクチャを簡素化するために、顧客が使用するＳＧ １７０とＶＰＮコンセントレータ１３６のパブリックＩＰアドレスは、その顧客のインターネット・サービス・プロバイダ（ＩＳＰ）に割り振られた同じアドレス・ブロックのものとする。

ファイアーウォール
一実施形態により、基本的なファイアーウォール機能が、公衆網上に配置するＳＧ １７０として提供されている。パフォーマンスの理由から、ステートフル・インスペクション、サービス保護の拒否、侵入検出、およびパケット・フィルタリングのうちの１つまたは複数を回線速度で実行する。

サービス品質（ＱｏＳ）
一実施形態では、顧客のネットワークおよび顧客のサービス・プロバイダのネットワーク・インフラストラクチャ内の高レベルのパフォーマンスを確保するために、ＳＧ １７０は、デバイスを横断する任意のＩＰヘッダー内の設定によりサービスのタイプ（ＴＯＳ）を維持することができ、そのデバイスを出るすべてのＩＰＳｅｃをＴＯＳまたは差異化サービス（ＤｉｆｆＳｅｒｖ）設定により「マーク付け」することができ、それによってネットワーク上の他のトラフィックを介したＳＧに優先順位付けすることに役立つ。

冗長性
さらに、一実施形態によれば、ＳＧ １７０が実行する各機能に対して完全な冗長性を提供する。このバックグラウンドで、一次ＳＧ １７０は、すべてのＮＡＴセッション、ＤＨＣＰリース、およびＶＰＮトンネルに関する接続状態テーブルを維持する。この機能は、直接イーサネット接続を介して、または内部ネットワーク・インターフェースによって実行する。そのＩＰアドレスを到達可能な状態に保つために、フェイルオーバーの場合にローカル・インターフェース上で無料ＡＲＰ（アドレス解決プロトコル）の使用を利用する。

さらなる機能：
同様に想定されるいくつかの追加機能は、特に、ＣＲＴＰ（圧縮リアルタイム・プロトコル）に対するサポート、１９”ラック取付可能形式ファクタ、より多くのイーサネット・インターフェース、内蔵モデム、ＲＳＶＰサポート、およびＭＰＬＳサポートを含む。

ＳＧ機能の概要
サービス・ゲートウェイ１７０の機能の概要を以下に示す。この機能リストは一例であり、サービス・ゲートウェイ１７０の機能セットを限定することを意図するものではないということに留意されたい。むしろ、様々な実施形態で、システム設計の柔軟性は、関連技術の開発に伴い、別の機能、すなわち追加の機能が、拡張された将来のＩＰベースの遠隔通信サービスを提供することを容易にすることが想定される。
サービス・ゲートウェイ（ＳＧ）機能：
パフォーマンス：
・ワイヤレート・パフォーマンス、５ミリ秒より短いユニット全体の合計待ち時間
ＩＰＳｅｃトンネル
・２０＋、ワイヤ・スピード３−ＤＥＳのＩＰＳｅｃトンネルに対するサポート
・各トンネルに対する一意のＩＰアドレス
ファイアーウォール：
・ステートフル・インスペクション
・ソース／宛先ＩＰアドレス
・ソース／宛先ポート
・サービス保護の拒否
ＩＰ経路指定：
・静的ルート（１００＋）
・ＯＳＰＦ
・ＲＩＰｖ．２
・トンネル横断経路指定
高い可用性：
・任意選択
・クラスタ化またはロード・バランシングに対するサポート
・アクティブ／待機構成に対するＯＲサポート
・冗長性、超高速フェイルオーバー
・すべての機能（ＮＡＰＴ、ＤＨＣＰなど）に対するＨＡピア間の接続状態転送
インターフェース・サポート：
・１０Ｍｂのイーサネット、１００Ｍｂのイーサネット、全二重に対するサポート
・「外部」および「内部」インターフェースに対する８０２．１ｑおよび８０２．１ｐのサポート
ポート変換：
・バーチャルＩＰアドレス
・ポート番号を変更しない基本的ＮＡＴトランスレーション（プライベートＩＰからパブリックＩＰへ）の提供
・複数のＮＡＴアドレスのサポート
・ＩＰＳｅｃによる暗号化以前のＮＡＴ機能の実行
・ＶＰＮ「以前に」ＮＡＴ／ＮＡＰＴを転送すること
・内部ホストと割り当てられたポートの間で永続的なポート・マッピングを維持すること
ＤＨＣＰサービス：
・標準機能：
・更新を伴う永久リース
・ＩＰアドレス
・マスク
・ディフォルト・ゲートウェイ
・ドメイン名
・ホスト名
・ＤＮＳサーバ
・割り当てる前にアドレスを検証すること
・ＭＡＣベースの予約
・ブート・ファイル名
・ブート・ファイル位置
・オプション：
・ＮＡＰＴテーブルで予約されたホストへのポート範囲の割り当て
・ソフト・スイッチ・アドレスの割り当て
・ＤＨＣＰテーブルの待機デバイスとの同期
・追加のＤＨＣＰ機能：
・複数のスコープおよびスーパースコープのサポート
・ＭＡＣベースの予約に対するサポート
・クラス識別子に基づくリースのサポート（非電話からの要求を無視する）
・クライアント識別子に基づくリースの発行（非電話からの要求を無視する）
・標準ＤＨＣＰオプションのサポート：
・オプション１（サブネット・マスク）
・オプション３（ルータ・オプション）
・オプション４（タイム・サーバ・オプション）
・オプション１３（ブート・ファイル・サイズ・オプション）
・オプション１７（ルート・パス）
・オプション５０（要求されたＩＰアドレス）
・オプション５４（サーバ識別子）
・オプション６６（ＴＦＴＰサーバ名）
・オプション４３（ベンダーの固有情報）
・ベンダーの固有オプション：
・ＤＨＣＰクライアントに一意のポート範囲を割り当てる
・一次／バックアップＭＧＣ ＩＰアドレスを割り当てる
・ＮＡＴアドレスを割り当てる
トラフィック・エンジニアリング：
・ＱｏＳ／ＴｏＳ
・維持されているホスト・トラフィック内でのＴＯＳビットの統合
・ＩＰＳｅｃトラフィックに対するＴＯＳビットの設定
・ＲＳＶＰ
・ＭＰＬＳ
・レート制限／キューイング
ＴＦＴＰサービス：
・ＴＦＴＰサービス、ＴＦＴＰサーバのサポート
・多くのイメージ用のストレージ（３０〜１００メガバイト）
・ＩＰ電話への読取／書込みに対するサポート
・ＩＰ電話からのエラー・ロギングに対するサポート
管理：
・ベーシックＳＮＭＰ
・トンネル固有のＭＩＢ
・テルネット
・シリアル・インターフェース
他のＳＧ機能：
・ＶＰＮ（ＩＰＳｅｃ、３ＤＥＳ、手動キー、ハードウェア暗号化／暗号解読、ＥＳＰトンネル）
・ワイヤ・スピードでの複数同時ＶＰＮトンネル終了（３＋トンネル）
・ＣＲＴＰサポート
・ＢＯＯＴＰ／ＴＦＴＰ
・最低２メガバイトのフラッシュが解放されている
・ＳＮＭＰ管理
・テルネット・アクセス
・シリアル・インターフェース
・２×１０／１００Ｍｂのイーサネット・インターフェース
・ラック取付可能（１９”）が好ましい

ＶｏＩＰ ＩＰ電話
一実施形態では、内部ホスト、すなわちＩＰ電話は、ＳＧ ＤＨＣＰサービスによって割り当てられたプライベートＩＰアドレスをすべてのＩＰヘッダーに対して通常の方法で使用する。本明細書で使用する「プライベートＩＰアドレス」という用語は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）のリクエスト・フォー・コメント（ＲＦＣ）１９１８に記載されている範囲のＩＰアドレス、並びにアドレスを使用して組織に対するいかなる地域インターネット・レジストリによっても割り当てられていない任意のＩＰアドレスを意味することに留意されたい。本明細書で使用する「パブリックＩＰアドレス」という用語は、アドレスを使用して組織に対する任意の地域インターネット・レジストリによって割り当てられた任意のＩＰアドレスを意味するということにも留意されたい。

各ＩＰ電話１２０は、ＤＨＣＰプロセスの一部としてＳＧ １７０によってそれに割り当てられたポート番号を使用する。ＤＨＣＰリースを要求する際、ＩＰ電話１２０は、それ自体をネットワークの他のホストと区別するためにクライアント識別子を指定する。ＩＰ電話１２０は、すべてのそのトラフィックがＮＡＴしているパブリックＩＰアドレスも知ることができ、その結果、ＩＰ電話１２０は、後述する登録プロセス中にソフト・スイッチを通知する。

ソフト・スイッチ
一実施形態では、「ソフト・スイッチ」は、実際には、様々な機能を実行するために多くのアプリケーションを実行している一群のシステムである。例えば、ＩＰ電話１２０とソフト・スイッチの間の対話を処理するソフト・スイッチの一部を、本明細書ではメディア・ゲートウェイ・コントローラ（ＭＧＣ）１５０（その対話に対するＭＥＧＡＣＯ標準で使用される用語から）と称する。ＭＧＣ １５０は、その標準機能以外にも、ＩＰ電話１２０およびＳＧ１７０と適切に相互動作するために１つまたは複数の特殊なタスクを実行する。そのような特殊なタスクの一例は、ＭＥＧＯＣＯプロトコルを使用する一実施形態に関して説明される。すなわち、ＩＰ電話１２０がＭＧＣ １５０に登録した際、ＭＧＣ １５０はＭＥＧＡＣＯヘッダーに提供されているＩＰ電話１２０のプライベート・アドレス、並びにＩＰヘッダーでＳＧ １７０によって使用されているＮＡＴしたＩＰアドレスを記憶することができ、あるいはＩＰ電話１２０は登録中にその情報を渡すことができる。ＭＧＣ １５０は、どのＩＰアドレス（パブリックまたはプライベート）を呼の関係者に伝達する必要があるかを判定するためにこの情報を使用することができ、また、同じ内部ネットワーク上の２つのＩＰ電話１２０または異なるネットワーク上のＩＰ電話に対する呼セットアップ要求間を区別する際に特に有用である場合がある。ＩＰ電話１２０は同じ顧客施設３００上にあるが２つの異なるＳＧ １７０を介して動作している場合、パブリック・アドレスを使用するためにＲＴＰセッションを導くことができる。

ＶＰＮコンセントレータ
ＰｏＰで、ＶＰＮコンセントレータはＳＧ １７０から開始されたＶＰＮトンネルの他端を終了する。このデバイスは、ワイヤ・スピードで少なくとも１０００ＩＰＳｅｃ、３ＤＥＳ、ＥＳＰトンネルを処理するように動作可能であり、ＳＧ １７０のような基本的な経路指定およびファイアーウォール機能、並びに８０２．１ｑ／ｐをサポートすることもできる。ＶＰＮコンセントレータ１３６は、アクティブなデバイスの故障がすべての既存のトンネルの破壊を生じない場合に、非常に可用性の高い解決策も提供する。これが技術的に実現可能でない場合、各ＳＧ １７０は２つのアクティブなＶＰＮトンネルを常時維持する。

基本的なＶＰＮコンセントレータ機能の概要
ＶＰＮコンセントレータ１３６の機能の概要を以下で説明する。機能リストは一例であり、ＶＰＮコンセントレータ１３６の想定される機能セットを限定することを意図するものではないということに留意されたい。むしろ、システム設計の柔軟性が、関連技術の開発に伴い、追加の機能が拡張された将来のＩＰベースの遠隔通信サービスを提供することを容易にするということが想定される。
ＶＰＮコンセントレータ機能：
ファイアーウォール
・ソース／宛先ＩＰアドレス
・ソース／宛先ポート
・サービス保護の拒否
ＩＰ経路指定
・静的ルート（１０００＋）
・ＯＳＰＦ
・トンネル横断経路指定
高い可用性
・クラスタ化またはロード・バランシングに対するサポート
・アクティブ／待機構成に対するＯＲサポート
・冗長性、超高速フェイルオーバー
・ＨＡピア間の接続状態転送
インターフェース・サポート
・１００Ｍｂのイーサネット、ギガビットのイーサネット、全二重に対するサポート
・「外部」および「内部」インターフェースに対する８０２．１ｑおよび８０２．１ｐのサポート
トラフィック・エンジニアリング
・ＱｏＳ／ＴｏＳ
・ＲＳＶＰ
・ＭＰＬＳ
・レート制限／キューイング
ＩＰＳｅｃトンネル
・１０００＋、ワイヤ・スピード３−ＤＥＳのＩＰＳｅｃトンネルに対するサポート
・各トンネルに対する一意のＩＰアドレス
他の機能：
・ＣＲＴＰサポート
・ワイヤ・スピードでの複数同時ＶＰＮトンネル終了（１０００トンネル＋）
・複数ＶＰＮ宛先アドレス
ＶＰＮコンセントレータ管理機能：
・基本ＳＮＭＰ
・トンネル固有のＭＩＢ
・テルネット
・シリアル・インターフェース
・集中管理
・集中供給
・グローバル・キー管理

顧客ファイアーウォール
一実施形態では、セキュリティの目的で顧客のファイアーウォール１３２が顧客施設上に常駐することができ、これが顧客の内部ネットワークと外部システムとを分離している。顧客施設にあるこのファイアーウォール１３２は、ＳＧ １７０と協同して作業するために特定の機能をサポートするように動作可能である。ファイアーウォール１３２がこれらの機能をサポートしない場合、ＳＧ １７０をファイアーウォール１３２の背後ではなくファイアーウォール１３２と並列に配置する。

ＳＧ １７０がＩＰＳｅｃセッションに参加しているので、そのＩＰパケットの出所をパブリックＩＰアドレスによって明示することができ、ＩＰパケットがファイアーウォール１３２を通過する際にそのＩＰパケットを変更されずに維持する。ヘッダーにいかなる変更が起こっても他端でＶＰＮデバイスによるＩＰＳｅｃトラフィックの破棄を生じる可能性があるので、いずれにしてもＩＰヘッダーには変更をまったく含まない。

システム内の各デバイスに関して上記で説明した機能は、ＶｏＩＰテレフォニーに効率的で柔軟な解決策を提供する。さらに、システムの様々な実施形態は、顧客環境においてシステムの実施形態に関するいくつかの問題に対する解決策を提供するアーキテクチャを含む。

到達不可能なアドレスの発行は、当技術分野で周知のようにＮＡＰＴ技術を使用して対処する。各ＳＧ １７０に対して少数の経路指定可能なアドレスを使用することは、ＡＲＩＮ（インターネット番号米国登録）の目標および方法と調和する適切かつ適正な方法である。ＶＰＮ技術およびＳＧ １７０をすべてのＩＰ電話１２０に対するディフォルト・ゲートウェイとして使用することにより、ＶｏＩＰ解決策の経路指定アーキテクチャを簡素化する。ＵＤＰ、複数の連続したポート数、およびネットワーク外部から開始されたセッションを使用するアプリケーション層プロトコルをサポートする問題は、ＳＧ １７０によって対処する。ＳＧ １７０によって維持される永続するＮＡＰＴテーブルは、動的なポート数の従来からある問題を解決する。上記の「三角形分割」問題は、ポート範囲の割り振りおよびＮＡＰＰＴプロセスと組み合わせてソフト・スイッチの情報によって解決する。ＶｏＩＰネットワーク専用のＤＨＣＰ解決策を実施することにより、顧客およびサービス・プロバイダのネットワークＤＨＣＰ資源（信頼性に疑問がある場合がある）は必要なくなる。

ＶｏＩＰテレフォニーに関するいくつかの具体的な問題について、本発明の様々な実施形態によって提供される実現可能な対応する解決策と併せて以下で説明する。本発明の様々な実施形態は、それぞれ以下に列挙する問題の一部またはすべてに対処する場合があるか、あるいはどれにも対処しない場合があるということに留意されたい。

経路指定の問題
問題：
顧客施設から発信されるアプリケーション・トラフィックは予測可能な経路を取ることが望ましく、好適には待ち時間およびジッターの少ないチャネル・パートナーのネットワークを横断する最短経路を取ることが望ましい。これは次の理由から難題となる可能性がある。
１）ＱｏＳ技術はサービス・プロバイダのネットワークによって大きく異なる。
２）チャネル・パートナー（ＩＳＰ）は、通常、通告を要する多数の小さな経路指定通告を受理しない（／３２、／３０、／２９、など）。
３）システムは様々なサービス・プロバイダ間で中継接続として動作できない。
４）したがって、システムはチャネル・パートナーとＢＧＰを実行することができない。

経路指定解決策
１）ＰｏＰルータへのインターフェースに対処するために各チャネル・パートナーから小さなパブリックＩＰブロックを取得する。
２）ＩＰ電話に対するディフォルト・ゲートウェイとして使用するためにサービス・ゲートウェイを顧客施設内に置く。
３）ＭＥＧＡＣＯおよびＲＴＰトラフィックを顧客／チャネル・パートナーのネットワークを横断してトンネリングするためにＶＰＮ技術を使用する。
４）チャネル・パートナーのネットワーク上のトラフィックを確保するためにＶＰＮコンセントレータ上のチャネル・パートナーＩＰアドレスを使用する。
５）それらのネットワークに対する適切なトラフィック・エンジニアリング技術によりチャネル・パートナーからのＶＰＮトラフィック（ソース／宛先アドレス）のサービス保障を交渉する。

ファイアーウォール問題
現在のファイアーウォール製品は、システムが利用するプロトコル、すなわちＭＥＧＡＣＯ、ＲＴＰ、ＲＴＣＰをサポートしない。
根本的な問題は、
１）ＩＰアドレスを保護するためにＮＡＰＴが必要である（ＡＲＩＮはＩＰ電話用登録済みＩＰアドレスを提供しない）。
２）ＩＰ／ポート情報がペイロードにある。
３）これらのプロトコルは複数のＵＤＰポートを使用する。
４）ファイアーウォールはＵＤＰセッションを十分にサポートしない。
５）ＵＤＰセッションは外部の／信頼性のないネットワークから開始される。
６）ＩＰ電話はＩＰおよびサポート番号が永続的であることを見込んで登録する。
７）ＮＡＰＴはポートの動的割り振りを実行する。

ファイアーウォール解決策
１）顧客のルータを完全にバイパスする、または
２）ＶＰＮトラフィックを顧客のファイアーウォールにトンネリングさせる。これはファイアーウォール内に小さな「穴」（ＴＣＰセッション、限定されたソース／宛先対）を与え、すべてのサポートされていないプロトコルをファイアーウォールから隠す。
３）ファイアーウォールがトラフィックを通過させるよう経路指定するだけでよいように暗号化以前にＮＡＰＴ機能を実行する。

図３Ｂ：ＩＰ電話対ＩＰ電話のネットワークへの図面
図３Ｂは、２つの異なるＬＡＮのＩＰ電話間の、すなわち異なる顧客施設のＩＰ電話間１２０の通信に提供されるＶｏＩＰネットワークの図である。図３Ｂに示すシステムは、図３Ａを参照して上記で説明したシステムの効果的な双方向性の実施形態である。

図３Ｂに示すように、ＩＰ電話１２０Ａと１２０ＢはＳＧ １７０Ａに結合されており、ＳＧ １７０Ａは顧客のファイアーウォール１３２Ａに結合されている。顧客のファイアーウォール１３２Ａは、チャネル・パートナー（ＩＳＰ）１７０Ａへアクセスする顧客のルータ１３０Ａに結合されている。したがって、顧客Ａにとって、ＶｏＩＰシステムのオンサイト・コンポーネントは、ＩＰ電話１２０、ＳＧ １７０Ａ、ファイアーウォール１３０Ａ、およびルータ１３０Ａ、並びに１つまたは複数のイーサネット・スイッチ（図示せず）などのような他のサポート設備を含む。

一実施形態では、コンポーネントの対応するセットは、図示するように顧客Ｂの施設内にある場合がある。具体的には、ＩＰ電話１２０Ｃおよび１２０Ｄ、ＳＧ １７０Ｂ、ファイアーウォール１３０Ｂ、およびルータ１３０Ｂは上記のように相互に結合され、顧客のルータ１３０Ｂはチャネル・パートナー（ＩＳＰ）１４０Ｂに結合されている。

各顧客のチャネル・パートナーは、システムＰｏＰコンポーネントへアクセスするそれぞれのＰｏＰルータ３３０に結合されている。より具体的には、チャネル・パートナー１４０Ａに結合されているＰｏＰルータ３３０は、ＶＰＮコンセントレータ１３６Ａとトランキング・ゲートウェイ１６０Ａとに結合されている。ＰｏＰルータ３３０は、別のＰｏＰルータ３３０を介してさらにメディア・ゲートウェイ・コントローラ１５０に結合されており、これによってＩＰ電話１２０Ａと１２０Ｂは顧客Ａ用のシステムＰｏＰコンポーネントに通信結合される。同様に、チャネル・パートナー１４０Ｂに結合されているＰｏＰルータ３３０もＶＰＮコンセントレータ１３６Ｂとトランキング・ゲートウェイ１６０Ｂに結合されている。ＰｏＰルータ３３０はさらにＰｏＰルータ３３０を介してメディア・ゲートウェイ・コントローラ１５０に結合されており、これによってＩＰ電話１２０Ｃと１２０Ｄは顧客Ｂ用のシステムＰｏＰコンポーネントに通信結合される。

図４Ａおよび４Ｂ：ＩＰ電話の初期化構成および使用
図４Ａおよび４Ｂは、本発明の一実施形態によるＩＰ電話１２０（または他のメディア・ゲートウェイ）の初期化、構成、および使用の流れ図である。図４Ａおよび４Ｂは、ＩＰ電話１２０の構成と動作を必要に応じて本発明の様々な他の方法を使用して実行する一実施形態を示しているということに留意されたい。図示する様々なステップは別の順番で実行しても、または省略してもよく、あるいは必要に応じて様々な追加のステップを実行することもできるということにさらに留意されたい。

図４Ａは高レベルＩＰテレフォニー・プロセスの流れ図である。図示するように、ステップ４２０でＩＰ電話１２０に電源投入する、すなわちこれを起動する。ステップ４０２は、ＩＰ電話１２０が最初にクライアントの位置にインストールされた際に、すなわち最初にインストールされて電源投入された際に行うことができる。あるいは、ステップ４０２は、定期的に、すなわち毎朝ユーザがＩＰ電話１２０に電源投入した際に実行する。一実施形態では、ＩＰ電話の起動は、ＩＰ電話、ＩＰ電話に結合されている外部システム、またはこれらの両方で実行されているソフトウェアによってプログラム化して実行する。

ステップ４０４で、クライアントＤＨＣＰリース交渉を実行する。一実施形態によれば、ステップ４０４で、ＩＰ電話１２０は、ＤＨＣＰ割り当てＩＰアドレスを要求しているサービス・ゲートウェイ１７０に接触する。これに応答して、クライアントＤＨＣＰリース交渉をステップ４０４で実行する。ここでＤＨＣＰリース交渉の一部として、サービス・ゲートウェイ１７０はＩＰ電話１２０を初期化するためにＩＰ電話１２０に対するＴＦＴＰ転送を実行する。これは、ＩＰ電話１２０を構成またはブートするために、ブートおよび／または構成データの、ＩＰ電話１２０に配置されているメモリ、例えばＥＥＰＲＯＭへの転送を伴う。一実施形態では、ＴＦＴＰプロセスは、ＩＰ電話の第１のブーティング、次いでＩＰテレフォニーを実行するために実行可能なアプリケーションのローディングを含む。ステップ４０４で実行されたクライアントＤＨＣＰリース交渉は、図５Ａおよび５Ｂの流れ図で詳細に説明する。

ステップ４０６で、メディア・ゲートウェイ・コントローラ（ＭＧＣ）１５０とＩＰ電話１２０はＩＰ電話１２０の登録を実行する。これはＩＰ電話１２０をＭＧＣ１５０に登録することを含み、またＭＧＣ１５０とＩＰ電話１２０の間で登録情報を送信することを含む。ＭＥＧＡＣＯ標準を利用するＩＰ電話登録プロセスの一実施形態は、図６Ａ、６Ｂ、および６Ｃの流れ図に関して以下でさらに詳細に説明する。

ステップ４０８でユーザはＩＰ電話１２０にログインする。ユーザのログインは任意選択であってよく、さらにユーザのログインはステップ４０８でのＩＰ電話登録以前に実際に実行するということに留意されたい。ユーザがログインして任意の必須のパスワードが提供された後は、ＩＰ電話１２０は動作すなわち使用の準備が整った状態である。したがって、ステップ４１０で、ユーザはＩＰ電話１２０を使用して呼を発信し、受信することができる。ここでＳＧ １７０などのシステムはＩＰ電話とＩＰデバイスの間でＩＰ通信を仲裁することができ、またＩＰ電話はＩＰ通信を送受信するためにポート番号の範囲の少なくとも１つのサブセットを使用する。

図４Ｂは、図４Ａに関して上記で説明したプロセスの一実施形態をさらに詳細に流れ図で表現している。図４Ｂに示すように、４０２では、上記のようにＩＰ電話に電源投入することができ、次いで４０４ではＤＨＣＰ／ＴＦＴＰプロセスを実行する。一実施形態では、サービス・ゲートウェイ１７０などのシステムはＩＰ電話１２０から識別子を受信する。一実施形態では、この識別子はベンダー・クラスＩＤを含む。次いでＳＧ １７０は、その識別子が有効か否かを判定することができ、その識別子が有効である場合、その識別子に基づいてポート番号の範囲をＩＰ電話１２０に割り当てることができる。次いでＩＰ電話１２０は、ＩＰ通信を送受信するためにポート番号の範囲の少なくとも１つのサブセットを使用する。一実施形態では、システムはＩＰ電話に対するＭＡＣ ＩＤも受信することができ、そのＭＡＣ ＩＤが有効であるとシステムが判定した場合、システムはそのＩＰ電話識別子が有効であるか否かを判定する。４５２にＤＨＣＰ／ＴＦＴＰプロセス４０４のさらなる詳細を示す。

４５２に示すように、一実施形態では、システムは、ＤＨＣＰリース情報、ポート範囲割り振り、およびＭＧＣアドレスなどのメディア・ゲートウェイ・コントローラ（ＭＧＣ）情報を、ベンダー・クラスＩＤなどの識別子に基づいてＩＰ電話１２０に提供する。

一実施形態では、ＩＰ電話１２０の識別子は、ＩＰ電話１２０によってＳＧ １７０に発行されたＤＨＣＰ発見メッセージに含めることができる。この場合、ＳＧ １７０はＩＰ電話に対するＤＨＣＰオファーによって応答する（識別子が有効であると判定された場合）。ここでＤＨＣＰオファーは検証された識別子に基づいてＤＨＣＰリース情報を含めることができる。次いでＩＰ電話１２０は、発行されたＤＨＣＰオファーに応えてＤＨＣＰ要求を発行する。この場合ＳＧ １７０とＩＰ電話１２０はそれぞれＤＨＣＰリース情報を記憶しており、ＩＰ電話１２０はＤＨＣＰリース情報に含まれるＤＨＣＰ設定をイネーブルする。一実施形態では、ＤＨＣＰリース情報は、ポート番号の範囲並びにＩＰ電話１２０に対するオペレーショナル・ソフトウェアを指示する情報を含む。次いでＩＰ電話１２０は、ＩＰ通信を可能にするために指示されたオペレーショナル・ソフトウェアを実行する。別の実施形態では、ＩＰ電話１２０は、指示されたオペレーショナル・ソフトウェアに対する要求を、例えば簡易ファイル転送プロトコル（ＴＦＴＰ）サーバのようなファイル転送サーバに読取要求を発行することによって発行する。ファイル転送サーバは、この要求に応えてＩＰ電話１２０にオペレーショナル・ソフトウェアを提供することができ、次いでＩＰ電話１２０はＩＰ通信を可能にするためにオペレーショナル・ソフトウェアを実行する。

ポートの割り振りは、ポート範囲を１つのポートではなくＩＰ電話１２０に割り振ることを含み、この場合ポート範囲はＩＰ電話１２０の識別子、例えばベンダー・クラスＩＤによって異なるということに留意されたい。例えば、複数の電話回線を使用することのできるＩＰ電話１２０は、１回線のＩＰ電話よりも幅広いポート範囲に割り当てることができる。一実施形態では、１つのポートが着信情報用であり、１つのポートが発信情報用である各双方向通信チャネルのそれぞれに２つのポートを割り当てることができる。現在は定義されておらず、または実用されていない将来のデジタル遠隔通信サービスを含めて同一のインフラストラクチャで多岐にわたるデジタル遠隔通信サービスを提供するように、追加のポートをページングなどのような他のサービスに割り当てることができる。一実施形態では、ＩＰ電話１２０に割り当てられたポート番号の範囲は、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）によりＦＴＰ、ＨＴＴＰなどのような他のＩＰプロトコルが使用するために予約されていないポートを含む。

図４Ａの４０４を参照して上記で説明したように、方法は、ＴＦＴＰを介してＩＰ電１２０話に初期化情報をダウンロードすることをさらに含む。

４０６で、４６２〜４６６でさらに詳細に説明するようにクライアント登録を実行する。４６２で、ＩＰ電話１２０は、上記４０４のＤＨＣＰリースから受信した割り当て済みポート範囲を使用してＭＧＣ １５０に登録する。ＩＰ電話１２０は、上記の４５２で提供されたＭＧＣ情報（例えばＭＧＣ １５０のアドレス）を使用してＭＧＣ １５０に接触するということに留意されたい。次いで４６４で、サービス・ゲートウェイ１７０（ＮＡＴサービスとして）は、ＩＰソース・アドレスを例えばプライベートからパブリックに変更することはできるが、ポート情報は変更しないまま維持する。４６６で、ＭＧＣ １５０は、ＩＰ電話のパブリックＩＰおよびポート情報、すなわちＩＰ電話の登録情報を使用してＩＰ電話１２０を登録する。一実施形態では、登録情報はＩＰ電話のプライベートＩＰ情報も含む。すなわち、ＭＧＣ １５０は、ＩＰ電話を登録するためにＩＰ電話のプライベートＩＰ情報（例えばプライベートＩＰアドレス）を使用することもできる。一実施形態では、ＭＧＣ １５０は後述する呼セットアップで使用するために受信した登録情報を記憶するということに留意されたい。

一実施形態では、４８０〜４９４で後述するプロセスは図４Ａの４０８および４１０で説明されるプロセスを十分に説明したものであり、ここでユーザは任意選択でシステムにログインし、次いで電話の呼を発信し、または受信するということに留意されたい。４８０では呼セットアップ・プロセスを実行する。具体的には、４８２でＩＰ電話１２０は上記の４０４でＤＨＣＰリースから受信した割り当て済みポート範囲とＭＧＣアドレスを使用して、ＭＧＣ １５０に信号を送信するＭＥＧＡＣＯにより呼を開始する。４８４で、サービス・ゲートウェイ１７０（ＮＡＴサービスとして）はＩＰソース・アドレスを、例えばプライベートからパブリックに変更するが、ポート情報は変更しないまま維持する。次いで４８６でＭＧＣ １５０は、パブリックＩＰ、プライベートＩＰ、および／またはポート情報を使用して、例えばＩＰデバイスなどの呼の宛先を信号送信する。

４９０では、ＩＰ電話の呼に関連したＲＴＰフローを管理する。例えば４９２で示したように、一実施形態では、ＩＰ電話は上記の４０４のＤＨＣＰリースから受信した割り当て済みポート範囲から１つまたは複数のポートを使用してＲＴＰを交換する。次いで４６４および４８４で説明したように、４９４でサービス・ゲートウェイ１７０（ＮＡＴサービスとして）はＩＰソース・アドレスを、例えばプライベートからパブリックに変更するが、ポート情報は変更しないまま維持する。より具体的には、ＳＧ １７０は、ＩＰ電話１２０からデータ・パケットを受信し、そのデータ・パケットに対してネットワーク・アドレス永続ポート変換（ＮＡＰＰＴ）を実行し、ＮＡＰＰＴしたデータ・パケットを宛先ＩＰデバイスに送信する。上記のように、データ・パケットは、ＩＰ電話１２０のプライベート・ソースＩＰアドレス、ソース・ポート番号（ＩＰ電話の割り当て済みのポート番号範囲から）、およびＩＰデバイスに関連付けられた宛先情報を含む。一実施形態では、データ・パケットに対してＮＡＰＰＴを実行することは、ソース・ポート番号を変更せずに残しながらプライベート・ソースＩＰアドレスをパブリック・ソースＩＰアドレスに変更することを含む。この場合、ＩＰ電話１２０を一意に識別するためにパブリック・ソースＩＰアドレスとソース・ポート番号を使用する。

反対に、ＳＧ １７０がＩＰデバイスからＩＰ電話１２０宛のデータ・パケットを受信する場合、データ・パケットは、パブリック宛先ＩＰアドレス、宛先ポート番号、およびＩＰデバイスに関連付けられたソース情報を含むことができ、ここで宛先ポート番号はＩＰ電話１２０に割り当てられたポート番号の範囲内である。一実施形態では、ＩＰ電話１２０を一意に識別するためにパブリック宛先ＩＰアドレスおよび宛先ポート番号を使用する。データ・パケットに対してＮＡＰＰＴを実行することは、ＩＰ電話１２０を一意に識別するためにパブリック宛先ＩＰアドレスと宛先ポート番号を使用すること、および宛先ポート番号を変更せずに残しながらパブリック宛先ＩＰアドレスをプライベート宛先ＩＰアドレスに変更することを含む。この実施形態では、プライベートＩＰアドレスはＩＰ電話１２０のＩＰアドレスであってよいということに留意されたい。データ・パケットをＮＡＰＰＴした後、ＳＧ １７０はデータ・パケットをＩＰ電話１２０に送信する。

したがって、上記プロセスで、ＳＧ １７０は、ポート範囲をクライアントＩＰ電話に割り当てることによって、また対応するポート情報を変更せずに残しながらパケットＩＰソース／宛先アドレスをＮＡＰＰＴすることによってＩＰテレフォニー・プロセスを容易にし、仲裁することができる。これらの機能は、内部と外部のＩＰ電話接続の間を区別する「三角」問題に対処しながら、システムの大幅な柔軟性と将来における拡張を見込むことができる。

これらサブプロセスのそれぞれを、図５Ａ〜１０Ｂを参照して以下でさらに詳細に説明する。

図５Ａおよび５Ｂ：クライアントＤＨＣＰリース交渉
図５Ａおよび５Ｂは、本発明の一実施形態による上記４０４で実行されたクライアントＤＨＣＰリース交渉の一実施形態を示している。図５Ａおよび５Ｂはこれらリース交渉の一実施例を示しており、これらの交渉は本発明により様々な方法で実行できるということに留意されたい。図示する様々なステップは別の順番で実行しても、または省略してもよく、あるいは必要に応じて様々な追加のステップを実行することもできるということにさらに留意されたい。

図示するように、ステップ５０２でクライアントＩＰ電話１２０はブート・アプリケーションの実行を開始する。これは、ＥＥＰＲＯＭなどのＩＰ電話１２０のメモリに記憶されているアプリケーションの実行を開始することを伴う場合がある。

ステップ５０４でＩＰ電話１２０はＩＰアドレスまたはＩＰ情報が静的に割り当てられているか否かを判定する。ステップ５０４で判定されたようにＩＰ情報が静的に割り当てられている場合、動作は後述するステップ５４２に進むことができる。ステップ５０４でＩＰ情報が静的に割り当てられていないと判定された場合、ステップ５０６でクライアントＩＰ電話１２０はクラス識別子、例えばベンダー・クラス識別子を含むＤＨＣＰ発見コマンドを発行する。このＤＨＣＰ発見要求は、ＤＨＣＰの動的に割り当てられたＩＰアドレスを要求するように動作する。

ステップ５０８で、サーバ、例えばサービス・ゲートウェイ１７０は、ＤＨＣＰ発見コマンドを受信する。ステップ５１０で、サービス・ゲートウェイ１７０はＩＰ電話１２０のＭａｃ ＩＤが有効か否かを判定する。有効でない場合、動作は後述するステップ５３４に進む。ステップ５１０でＭａｃ ＩＤが有効であると判定された場合、ステップ５１２でサービス・ゲートウェイ１７０は、識別子、例えばベンダー・クラスＩＤが有効であるか否かを判定する。ベンダー・クラスＩＤが有効でない場合、オペレーションは後述するステップ５３２に進む。

ステップ５１２でベンダー・クラスＩＤが有効であると判定された場合、ステップ５１４でサーバ、すなわちサービス・ゲートウェイ１７０はリース情報を有するＤＨＣＰオファーを発行する。ステップ５１６でクライアントはこのＤＨＣＰオファーを受信する。上記のように、一実施形態では、ＤＨＣＰオファーはＩＰ電話１２０に関するＤＨＣＰリース情報を含む。

ステップ５１８で、ＩＰ電話１２０はそのリースがＩＰ電話１２０の動作に関するすべての必須オプションを含んでいるか否かを判定する。ステップ５１８の判定の際にリースがすべての必須オプションを含んでいないと判定された場合、ステップ５２０でＩＰ電話１２０はＤＨＣＰオファーを無視し、動作はステップ５３８に進むことができる。

ステップ５３８でＩＰ電話１２０は、ある期間、例えば待機間隔だけ待機することができ、次いでステップ５０６でベンダー・クラスＩＤによってＤＨＣＰ発見コマンドを再発行することができ、上記動作は反復する。

ステップ５１０でＭＡＣ ＩＤが有効でないと判定された場合、ステップ５３４でサービス・ゲートウェイ１７０はＤＨＣＰ発見コマンドを無視する。すなわちＤＨＣＰオファーを全く提供しないことができる。５３６でクライアントはＤＨＣＰオファーを１つも受信することはできない。

ステップ５１２でベンダー・クラスＩＤが有効でないと判定された場合、ステップ５３２でサービス・ゲートウェイ１７０はＤＨＣＰ発見コマンドを無視し、したがってステップ５３６でクライアントはＤＨＣＰオファーを受信することはできない。ステップ５３２または５３６の後のインスタンスで、ＩＰ電話１２０が、ある期間、すなわちステップ５３８の待機間隔の後にＤＨＣＰオファーを受信しない場合、ステップ５０６でクライアントはベンダー・クラスＩＤによってＤＨＣＰ発見コマンドを再発行することができ、上記オペレーションは反復する。

ステップ５１８でリースがすべての必須オプションを含んでいるとＩＰ電話１２０が判定した場合、ステップ５２２でクライアントはＤＨＣＰ要求を発行する。ステップ５２２でＤＨＣＰ要求を発行した後、オペレーションは後述する流れ図のステップ５６２に進むことができる。

ステップ５０４でＩＰ情報が静的に割り当てられているとクライアントのＩＰ電話１２０が判定した場合、動作はステップ５４２に進むことができる。図示するように、ステップ５４２でクライアントのＩＰ電話１２０はブート・イメージがローカルであるか否か、すなわちＩＰ電話用のオペレーショナル・ソフトウェアがローカルに記憶されているか否かを判定する。ステップ５４２でブート・イメージがローカルであると判定された場合、ステップ５９０でクライアントはＩＰ電話をブートアップするためにブート・イメージを実行することができ、次いで終了を行うことができ、ここで動作は完了する。

ステップ５４２でブート・イメージがローカルでないと判定された場合、ステップ５４４でクライアントは簡易ファイル転送プロトコル（ＴＦＴＰ）の活動を開始する。ステップ５４６でクライアントは、好適にはＤＨＣＰによって提供されたアドレスを使用して、ＲＲＱ（例えば読取要求）をＴＦＴＰサーバに発行する。ステップ５４８でＴＦＴＰサーバはＲＲＱを受信する（操作符号１）。ステップ５５０でＴＦＴＰサーバは、ファイルがローカル・フラッシュ内にあるか否かを判定する。ローカル・フラッシュ内にある場合、ステップ５５２でＴＦＴＰサーバはクライアントのＩＰ電話１２０に肯定応答を発行することができ（操作符号４）、ステップ５５４でクライアントのＩＰ電話１２０はイメージをメモリに記憶する。すなわち、ステップ５５４でＴＦＴＰサーバはそのイメージをクライアントのＩＰ電話に転送することができ、クライアントのＩＰ電話１２０はこのイメージをメモリに記憶する。

ステップ５５６でクライアントのＩＰ電話１２０は転送が終了または完了したか否かを判定する。終了または完了している場合、クライアントのＩＰ電話１２０はステップ５５４で受信され、記憶されたブート・イメージを実行することができ、動作は終了または完了する。

ステップ５５６で転送が完了していないとＩＰ電話１２０が判定した場合、動作はステップ５８２に進むことができる。ステップ５８２でＴＦＴＰが何らかの他の指定された閾値（例えば４回）よりも多く試行している場合、クライアントのＩＰ電話１２０はステップ５８４でＴＦＴＰ活動を異常終了し、動作はステップ５０２に進む。ＴＦＴＰ転送が４回よりも多く試行されていない場合、動作はステップ５４６に進むことができ、上記オペレーションは反復する。

ステップ５５０でファイルがローカル・フラッシュでないとＴＦＴＰサーバが判定した場合、ステップ５８０でＴＦＴＰサーバはエラーが発見されなかったファイルをクライアントのＩＰ電話１２０に発行することができ（出力５エラー・コード１）、動作はステップ５８２に進むことができる。

ステップ５２２でクライアントがＤＨＣＰ要求を発行すると、上記で指摘したように動作はステップ５６２に進むことができる。ステップ５６２でサーバはＤＨＣＰ要求を受信する。ステップ５６４でサーバは永続データにリースを、すなわちサーバ上の不揮発性メモリにリースを記憶する。ステップ５６６でサーバはＤＨＣＰ肯定応答（ＤＨＣＰ ＡＣＫ）を発行する。ステップ５６８でクライアントはＤＨＣＰ肯定応答を受信する。ステップ５７０でクライアントは、サーバから受信したリース情報を記憶する。ステップ５７２でクライアントは受信したリース値（すなわち、ＤＨＣＰ設定）をイネーブルする。ステップ５７４でクライアントはこれ以上のＤＨＣＰ肯定応答を無視することができ、動作はステップ５４２に進むことができる。ステップ５７０のリース情報は、プライベートＩＰアドレスおよびクライアント・システムのローカル・ネットワーク上でＩＰ電話１２０のオペレーションをイネーブルする他のリース情報を含む。

したがって、ＤＨＣＰリース交渉および登録で、ＩＰ電話のベンダー・クラスＩＤに応じて、ＩＰ電話を、使用するポートの範囲に割り当てることができる。例えば、複数の電話回線を使用するＩＰ電話は、単一回線のＩＰ電話よりも多くのポート範囲に割り当てることができる。好ましい実施形態では、１つのポートが着信情報用であり、１つのポートが発信情報用である各双方向通信チャネルに２つのポートを割り当てることができる。同一のインフラストラクチャで多岐にわたるデジタル遠隔通信サービスを提供するように、追加のポートをページングなどのような他のサービスに割り当てることができる。システムは、呼に関与している１つ以上のＩＰ電話に関連付けられた情報を検査することによって内部呼接続と外部呼接続の間を区別する。

図６Ａ、６Ｂ、および６Ｃ：ＩＰ電話登録プロセス
図６Ａ、６Ｂ、および６Ｃは、一実施形態による、上記図４Ａおよび４Ｂを参照して説明した４０６のＩＰ電話登録プロセスの流れ図である。この具体的な実施形態はＭＥＧＡＣＯ標準を使用しているが、必要に応じて他のプロトコルおよび標準を実施することもできる。図示する様々なステップは別の順番で実行しても、または省略してもよく、あるいは必要に応じて様々な追加のステップを実行することもできるということにさらに留意されたい。

図示するように、ＤＨＣＰ／ＴＦＰＰプロセス４０４が完了した後、ステップ６０２でクライアントは登録プロセスを開始する。

ステップ６０４でシステムはＩＰポートが登録のために使用可能であるか否かを判定する。ＩＰポートが登録のために使用可能でない場合、ステップ６０６で登録は失敗し、プロセスが終了する。

ＩＰポートが登録のために使用可能である場合、ステップ６０８でシステムはメディア・ゲートウェイ・コントローラのアドレスがＤＨＣＰによって提供されているか否かを判定する。ＭＧＣアドレスがＤＨＣＰによって提供されていなかった場合、ステップ６０６で登録は再度失敗し、プロセスが終了する。

ＭＧＣアドレスがＤＨＣＰによって提供された場合、ステップ６１０でクライアントはＭＥＧＡＣＯに対してポート番号を選択する。次いでステップ６１２で、クライアントは登録する一次ＭＧＣアドレスを選択する。

ステップ６１４でクライアントはサービス・チェンジ・コマンドをＭＧＣ１５０に送信する。パケット・ヘッダーの一例が６１４の一部として示されている。このパケット・ヘッダーは、プライベートと示されたソースＩＰアドレス、指示されたように割り当て済みポート範囲から選択されたソース・ポート、ここでは一次ＭＧＣアドレスと示した宛先ＩＰアドレス、および任意の一例としての値５５５５５で示す宛先ポートから構成される。ステップ６１６で、サービス・ゲートウェイ（ＳＧ）１７０はこの要求を受信する。次いでステップ６１８で、システム、例えばＳＧは、ＩＰ宛先が内部か、または外部、すなわち遠隔かを判定する。

ＩＰ宛先が内部であると判定された場合、ステップ６２０でデータ（パケット）をローカル・インターフェースに転送することができ、ステップ６２２でパケットをドロップする。

ステップ６２４で電話は要求に対してタイムアウトする。ステップ６２６で、システムは二次ＭＧＣアドレスの使用が試行されたか否かを判定し、二次が試行された場合、ステップ６０６で登録は失敗し、プロセスが終了する。二次が試行されていない場合、ステップ６２８でクライアントは登録する二次ＭＧＣアドレスを選択し、上記のようにステップ６１４でプロセスは再度続行される。

ステップ６１８を再度参照して、ＩＰ宛先が外部であると判定された場合、ステップ６３４でサービス・ゲートウェイ１７０は宛先ＩＰアドレスに基づいて宛先トンネルを選択する。次いでステップ６３６で、システムは選択されたトンネルが動作可能であるか否かを判定する。トンネルが動作可能でない場合、ステップ６２２でパケットをドロップし、上記で説明したようにプロセスはステップ６２４を続行する。

トンネルが動作可能である場合、ステップ６３８でサービス・ゲートウェイ１７０はネットワーク・アドレス永続ポート変換、すなわちＮＡＰＰＴを実行する。示してあるように、この段階のパケット・ヘッダー情報は次の方法で変更する。すなわち、ソース・ポートを「未変更」のまま残しながらソースＩＰアドレスをプライベートからパブリックに変更すし、宛先ＩＰアドレスを一次ＭＧＣアドレスに設定したまま残し、宛先ポートを一例である値５５５５５に維持する。

ステップ６４０で、サービス・ゲートウェイ１７０はパケットに対してＩＰセキュリティ暗号化を実行する。図示するように、元のパケットは、サービス・ゲートウェイの外部インターフェース・アドレスのソース・アドレスおよびＶＰＮコンセントレータの宛先アドレスと共に新パケットにカプセル化される。サービス・ゲートウェイ１７０はデータ（パケット）を選択したトンネルで転送する。

ステップ６４６で、トラフィックは、チャネル・パートナーのネットワーク、すなわちインターネット・サービス・プロバイダ（ＩＳＰ）によって提供されたネットワークを横断する。データ・トラフィック（パケット）がチャネル・パートナー・ネットワークを横断した後、ステップ６４８でデータ・トラフィックはバーチャル・プライベート・ネットワーク・コンセントレータ、すなわちＶＰＮコンセントレータ１３６に到達する。

ステップ６５０で、ＶＰＮコンセントレータ１３６はデータ・トラフィックを暗号解読し、ステップ６５２に示すように、データ・トラフィックをローカル・ルータに経路指定する。図示するように、一実施形態では、この時点におけるデータ・パケット・ヘッダー情報は、パブリックと示されたソースＩＰアドレス、図示するように「未変更」のまま残っているソース・ポート、ＭＧＣの一次アドレスに設定された宛先ＩＰアドレス、および一例である値５５５５５を有する宛先ポートを含む。

ステップ６５４でローカル・ルータはデータ・トラフィックをＭＧＣ １５０に転送する。次いでステップ６５６でシステムは、ＭＧＣ １５０がデータを受信するか否か、すなわちアドレス解決プロトコル（ＡＲＰ）に応答するか否かを判定する。ＭＧＣ １５０がそのデータを受信しない場合、ステップ６２２でプロセスはそのパケットをドロップして、上記のように続行する。

ＭＧＣ １５０がパケットを受信する場合、すなわちＡＲＰに応答する場合、ステップ６５８でＭＧＣ １５０は登録を処理する。ステップ６６０でＭＧＣ １５０は登録に応じて情報を記憶する。記憶される情報の一例を６６０の一部に示す。この情報は、電話１２０に対するサービス・ゲートウェイのパブリックＩＰアドレスと称する、ＳＧパブリックと示したＩＰ電話のＩＰアドレス、ここでは「未変更」と示したＭＥＧＡＣＯポート、およびＳＧパブリックと示したＳＧ ＩＰを含んでいる。

ステップ６６２でＭＧＣ １５０はサービス・チェンジで応答する。これはパケットをソースＩＰ電話に返信することを含む。すなわち６６２に示すように、一実施形態では、この段階のデータ用のパケット・ヘッダーが、一次ＭＧＣアドレスに設定されたソースＩＰアドレスおよびポートと一例である値５５５５５、すなわち上記６１４で説明した前回パケットの宛先情報を含む。指摘したように、宛先情報は、ＳＧパブリック・アドレスに設定された宛先ＩＰアドレスと、「未変更」のまま残っている宛先ポートを含む。ステップ６６４でローカル・ルータはトラフィックをＶＰＮコンセントレータ１３６に転送する。ステップ６６６でＶＰＮコンセントレータ１３６はＩＰセキュリティの暗号化を実行する。ステップ６６８でＶＰＮコンセントレータ１３６はそのデータを別のローカル・ルータに経路指定する。次いでステップ６７０でこのデータは、チャネル・パートナー・ネットワーク、すなわちＩＳＰによって提供されたネットワークを横断する。

ステップ６７２でデータはサービス・ゲートウェイ１７０に到達する。次いでサービス・ゲートウェイ１７０は、ステップ６７４に示すようにこのデータを解読する。次にステップ６７６でサービス・ゲートウェイ１７０はネットワーク・アドレス永続ポート変換（ＮＡＰＰＴ）を実行する。ステップ６７６で示すように、ソースＩＰアドレスが一次ＭＧＣアドレスに設定され、ソース・ポートが一例である値５５５５５に設定され、宛先ＩＰアドレスがパブリックからプライベートに変更され、宛先ポートが「未変更」のまま残っているように、パケット・ヘッダー情報を変更する。次いでステップ６７８で、ＳＧはそのデータをローカル・インターフェースを介して外に転送する。

ステップ６８０でシステムは、電話がアドレス解決プロトコルに応答するか否か、すなわち電話がそのデータを受信するか否かを判定する。電話がデータを受信しない場合、プロセスは上記のステップ６２４を進むことができる。電話がデータを受信する場合、ステップ６８２で電話１２０はこの登録を処理する。

ステップ６８４でシステムはその登録情報が有効であるか否かを判定する。登録情報が無効である場合、登録は６０６に示すように失敗し、プロセスが終了する。

登録情報が有効である場合、ステップ６８６でＭＥＧＡＣＯ登録プロセス交換がデータ交換が完了するまで続行する。次いで図示するようにプロセスが終了する。

これでサービス・ゲートウェイ１７０は、ＩＰ電話１２０を使用しているクライアントと、登録を実行するメディア・ゲートウェイ・コントローラ１５０との間で遠隔登録プロセスを仲裁することができる。

本発明のシステムの１つの利点は、顧客のシステム・コンポーネントを、システムから新しいソフトウェアをダウンロードすることによって遠隔に構成かつ／または再構成することである。すなわち本発明のシステムおよび方法によってサービスのアップグレードまたは修正に対する複雑なオンサイト・サービスを低減または解消するという点である。

図７Ａ、７Ｂ、および７Ｃ：ＩＰ電話のクライアントの呼セットアップ・プロセス
図７Ａ、７Ｂ、および７Ｃは、本発明の一実施形態によるクライアントの呼セットアップ・プロセスの流れ図である。図示するように、呼セットアップ・プロセスは、上記のＤＨＣＰ／ＴＦＴＰプロセス４０４とクライアント登録プロセス４０６の後で実行されることが好ましい。この具体的な実施形態はＭＥＧＡＣＯ標準を使用するが、必要に応じて他のプロトコルおよび標準を使用するということに留意されたい。図示する様々なステップは別の順番で実行しても、または省略してもよく、あるいは必要に応じて様々な追加のステップを実行することもできるということにさらに留意されたい。

ステップ７０２でクライアントの呼を開始する。好ましい実施形態では、呼は、ＩＰ電話１２０を起動しているクライアントによって、すなわち受話器を取り上げて宛先の電話番号をダイヤルすることによって開始する。

ステップ７０４でシステムは、ＩＰポートがＭＥＧＡＣＯのために使用可能であるか否かを判定し、ＩＰポートが使用可能でない場合、ステップ７０６で呼セットアップは失敗し、プロセスを終了する。

ＩＰポートが使用可能である場合、ステップ７０８でシステムはメディア・ゲートウェイ・コントローラ（ＭＧＣ）アドレスがＤＨＣＰによって提供されたか否かを判定する。ＭＧＣが提供されなかった場合、ステップ７０６で示すように呼セットアップは失敗し、プロセスが終了する。

ＭＧＣアドレスがＤＨＣＰによって提供された場合、ステップ７１０でクライアントはＭＥＧＡＣＯ信号送信用のポート番号を選択する。好ましい実施形態で、ポート番号は、図５Ａおよび５Ｂを参照して上記で説明するように、ＤＨＣＰリース交渉プロセス４０４でＩＰ電話のクライアントに割り当てられるポート番号の範囲から選択する。

ステップ７１２でクライアントは接触する一次ＭＧＣアドレスを選択することができ、ステップ７１４でサービス・チェンジ・コマンドをＭＧＣ １５０に送信する。パケット・ヘッダーの一例を７１４の一部に示す。このパケット・ヘッダーは、プライベートと示したソースＩＰアドレス、指示されるような割り当て済みポート範囲から選択されたソース・ポート、ここでは一次ＭＧＣアドレスと示す宛先ＩＰアドレス、およびここでは任意の一例としての値５５５５５で示す宛先ポートを含んでいる。

ステップ７１６でサービス・ゲートウェイ（ＳＧ）１７０はサービス・チェンジ・コマンドまたは要求を受信する。次いでステップ７１８でＳＧ １７０はＩＰ宛先がローカルかまたは遠隔かを判定する。「ローカル」および「遠隔」という用語は、それぞれに発呼側ＩＰ電話のＩＰサブネットの内部または外部である顧客ネットワーク内の呼の宛先を意味する。すなわち、宛先がローカルである場合、呼は、サービス・ゲートウェイ１７０に送信することを必要とせずに宛先ＩＰ電話１２０に直接送信する。

ＩＰ宛先がローカルである場合、ステップ７２０で呼セットアップ・データをローカル・インターフェースの外に転送し、ステップ７２２でパケットをドロップする。次いでステップ７２４で適切な待機期間の後、ＩＰ電話１２０はその要求に関してタイムアウトする。

ＩＰ電話１２０が要求に関してタイムアウトした後で、ステップ７２６でシステムは二次が試行されているか否か、すなわち二次ＭＧＣアドレスが試されているか否かを判定する。

二次ＭＧＣが試行されている場合、ステップ７０６で示すように呼セットアップは失敗し、プロセスが終了する。

二次ＭＧＣアドレスが試行されていない場合、７２８でクライアントは接触する二次ＭＧＣアドレスを選択し、上記のようにプロセスはステップ７１４を続行する。

再度ステップ７１８を参照すると、ＩＰ宛先が遠隔であると判定された場合、７３４でサービス・ゲートウェイ１７０は宛先ＩＰアドレスに基づいて宛先トンネルを選択する。

ステップ７３６でシステムは選択されたトンネルが動作可能か否かを判定する。トンネルが動作可能でない場合、７２２に示すようにパケット（呼セットアップ・データ）をドロップし、上記に示すようにプロセスを続行する。

トンネルが動作可能である場合、ステップ７３８でサービス・ゲートウェイ１７０は、呼セットアップ・データに関してネットワーク・アドレス永続ポート変換（ＮＡＰＰＴ）を実行する。示してあるように、この段階のパケット・ヘッダー情報は次の方法で変更する。すなわち、ソース・ポートを「未変更」のまま残しながらソースＩＰアドレスをプライベートから公開に変更し、宛先ＩＰアドレスを一次ＭＧＣアドレスに設定したまま残し、宛先ポートを一例である値５５５５５を維持する。

ステップ７４０で、サービス・ゲートウェイ１７０は呼セットアップ・データに対してＩＰセキュリティ（ＩＰＳｅｃ）暗号化を実行する。一実施形態では、パケット・ヘッダー情報は次の変更を含む。すなわち、ソースＩＰアドレスをパブリックＮＡＴアドレスに設定し、宛先ＩＰアドレスをＶＰＮコンセントレータに設定する。ソースおよび宛先ポート情報は変更せずに残す。

ステップ７４４でサービス・ゲートウェイ１７０は、選択したトンネルで呼セットアップ・データを転送する。この場合、呼セットアップ・データはチャネル・パートナー・ネットワーク、例えばステップ７４６に示すようにＩＳＰのネットワークを横断する。

ステップ７４８で呼セットアップ・データは、ステップ７５０で示すように呼セットアップ・データを解読するバーチャル・プライベート・ネットワーク（ＶＰＮ）コンセントレータ１３６に到達する。次いでステップ７５２でＶＰＮコンセントレータ１３６は、呼セットアップ・データをローカル・ルータに経路指定する。図示するように、一実施形態では、この時点でのデータ・パケット・ヘッダー情報は、パブリックと示されるソースＩＰアドレス、図示するように「未変更」のまま残っているソース・ポート、ＭＧＣの一次アドレスに設定された宛先ＩＰアドレス、および一例としての値５５５５５を有する宛先ポートを含む。
次いでローカル・ルータは、ステップ７５４に示すようにＭＧＣ １５０に呼セットアップ・データを転送する。

ステップ７５６でシステムは、ＭＧＣ １５０がアドレス解決プロトコル（ＡＲＰ）に応答するか否か、すなわちＭＧＣ １５０が呼セットアップ・データを受信するか否かを判定する。ＭＧＣ １５０が呼セットアップ・データを受信しない場合、ステップ７２２でパケット（呼セットアップ・データ）をドロップし、上記のようにプロセスを続行する。

ＭＧＣ １５０が呼セットアップ・データを受信する場合、ステップ７５８でＭＧＣ １５０は呼セットアップ要求を処理し、ステップ７６０でサービス・チェンジによって応答する。一実施形態では、この時点のデータに対するパケット・ヘッダーはこの段階で一次ＭＧＣアドレスに設定されたソースＩＰアドレスとポート、および一例である値５５５５５を含む。示してあるように、宛先情報は、ＳＧパブリック・アドレスに設定された宛先ＩＰアドレスと「未変更」のまま残された宛先ポートを含む。

ステップ７６２でローカル・ルータは呼セットアップ・データをＶＰＮコンセントレータ１３６に転送し、ＶＰＮコンセントレータ１３６は、ステップ７６４に示すようにそのデータに対してＩＰＳｅｃ暗号化を実行する。次いでＶＰＮコンセントレータ１３６は、ステップ７６６に示すように呼セットアップ・データをローカル・ルータに経路指定する。

ステップ７６８で呼セットアップ・データはチャネル・パートナー・ネットワーク、すなわちＩＳＰのネットワークを横断し、ステップ７７０でサービス・ゲートウェイ１７０に到達する。ステップ７２２でサービス・ゲートウェイ１７０は呼セットアップ・データを解読し、次いでステップ７７４に示すようにネットワーク・アドレス永続ポート変換（ＮＡＰＰＴ）を実行する。ソースＩＰアドレスが一次ＭＧＣアドレスに設定され、ソース・ポートが一例である値５５５５５に設定され、宛先ＩＰアドレスがパブリックからプライベートに変更され、宛先ポートが「未変更」のまま残されるように、パケット・ヘッダー情報を修正する。

次いでＳＧ１７０は、ステップ７７６に示すように呼セットアップ・データをローカル・インターフェースの外に転送する。

ステップ７７８でシステムは、ＩＰ電話１２０がアドレス解決プロトコル（ＡＲＰ）に応答するか否か、すなわち呼セットアップ・データを受信するか否かを判定する。ＩＰ電話１２０が呼セットアップ・データを受信しない場合、上記のようにプロセスはステップ７２２を続行する。ＩＰ電話１２０が呼セットアップ・データを受信する場合、７８０でＩＰ電話１２０はこの情報、すなわち呼セットアップ・データを処理する。

ステップ７８２でＩＰ電話は、呼セットアップ情報が有効であるか否かを判定する。呼セットアップ情報が有効でない場合、７０６で呼セットアップは失敗し、プロセスが終了する。呼セットアップ情報が有効である場合、ステップ７８４でＭＥＧＡＣＯ交換プロセス交換はデータ交換が完了するまで続行し、プロセスが終了する。

図８Ａ、８Ｂ、および８Ｃ：内部ＩＰ電話から内部ＩＰ電話へのＲＴＰのフロー
図８Ａ、８Ｂ、および８Ｃは、第１の内部ＩＰ電話１２０Ａによって開始された呼に関して第１の内部ＩＰ電話１２０Ａと第２の内部ＩＰ電話１２０Ｂの間のリアルタイム転送プロトコル（ＲＴＰ）データ・フローを流れ図で示している。ＲＴＰは、オーディオおよびビデオのようなリアルタイム・データを送信するためのインターネット・プロトコルである。ＲＴＰ自体はデータのリアルタイムによる配信を保証しないが、ストリーミング・データをサポートするためにアプリケーションを送受信するための機構を提供する。通常、ＲＴＰはＵＤＰプロトコルの最上位で実行されるが、この規格は他の転送プロトコルをサポートするには十分に一般的である。図８Ａ、８Ｂ、および８Ｃはデータ・フローの一実施形態を示しており、このフローは本発明による様々な方法で実行するということに留意されたい。図示する様々なステップは別の順番で実行しても、または省略してもよく、あるいは必要に応じて様々な追加のステップを実行することもできるということにさらに留意されたい。

図示するように、ＲＴＰコール・プロセスは、図５Ａ〜７Ｃを参照して上記で説明したように、ＤＨＣＰ／ＴＦＴＰプロセス４０４、クライアント登録プロセス４０６、および呼セットアップ・プロセス４８０の後で実行されることが好ましい。

ステップ８０２でＩＰ電話１２０ＡはＩＰ電話１２０ＢへのＲＴＰコールを開始する。上記で指摘したように、この実施形態では、どちらのＩＰ電話１２０もローカル・ネットワーク内部にある。

ステップ８０４でシステムは、ＭＧＣ １５０が宛先ＩＰアドレスおよびポートを提供したか否かを判定する。ＭＧＣ １５０が宛先ＩＰアドレスおよびポートを提供しなかった場合、ステップ８０６でセッションは失敗し、プロセスが終了する。ＭＧＣ １５０が宛先ＩＰアドレスおよびポートを提供した場合、ステップ８０８でシステムはＩＰアドレスがローカルか遠隔かを判定する。「ローカル」および「遠隔」という用語は、それぞれに発呼側ＩＰ電話のＩＰサブネットの内部または外部である顧客のネットワークの呼の宛先を意味する。すなわち、宛先がローカルである場合、サービス・ゲートウェイ１７０を介して送信することを必要とせずに呼を宛先ＩＰ電話１２０に直接送信する。

ＩＰアドレスが遠隔である場合、ステップ８１０でＩＰ電話１２０ＡはＲＴＰパケットをサービス・ゲートウェイ（ＳＧ）１７０Ａに送信する。サービス・ゲートウェイ（ＳＧ）１７０Ａは、ステップ８１２でパケットを受信し、ステップ８１４に示すように宛先ＩＰアドレスに基づいて宛先トンネルを選択する。

ステップ８１６でＳＧ１７０Ａは宛先トンネルが動作可能であるか否かを判定する。宛先トンネルが動作可能でない場合、８１８でＳＧ １７０Ａは代替トンネルが動作可能であるか否かを判定する。使用可能な代替トンネルがない場合、ステップ８２０でパケットをドロップし、ステップ８０６に示すようにセッションは失敗し、プロセスが終了する。

代替トンネルが使用可能である場合、後述するようにプロセスはステップ８２２を続行する。

ステップ８１６を再度参照して、宛先トンネルが動作可能である場合、ステップ８２２でＳＧ １７０Ａは宛先トンネル内のデータをＮＡＴすべきか否か、すなわちデータに対してネットワーク・アドレス変換を実行すべきか否かを判定する。データをＮＡＴすべき場合、パケットは外部宛先を有しており、したがって誤ったインターフェース（ローカル）に不適切に経路指定されたものと見なすことができることに留意されたい。したがって、ＮＡＴを実行すべき場合、ステップ８２４で呼は無効のＩＰ情報が原因で失敗し、ステップ８０６に示すようにセッションは失敗し、プロセスが終了する。

宛先トンネルをＮＡＴする必要がない場合、ステップ８２６でＳＧ １７０Ａはデータ（パケット）に対してＩＰＳｅｃ暗号化を実行し、ステップ８２８に示すように選択したトンネルを介してそのデータを転送する。ステップ８３０でデータは顧客ネットワークを横断し、ステップ８３２に示すように第２のサービス・ゲートウェイ１７０Ｂに達する。

ステップ８３４でＳＧ １７０Ｂはデータを解読し、ステップ８３６でＩＰ電話１２０Ｂに対してＡＲＰする。ステップ８３８でシステムは、ＩＰ電話１２０ＢがＡＲＰに応答するか否かを判定する。ＩＰ電話１２０ＢがＡＲＰに応答しない場合、ステップ８４０でパケットをドロップし、ステップ８４２に示すようにセッションは失敗し、プロセスが終了する。

ＩＰ電話１２０ＢがＡＲＰに応答する場合、ステップ８４４でＳＧ １７０ＢはデータをＩＰ電話１２０Ｂに転送する。ステップ８４６でＩＰ電話１２０ＢはＩＰ電話１２０ＡにＲＴＰパケットによって応答する。ステップ８４８でシステムは、ＲＴＰセッションが成功したか否かを判定する。ＲＴＰセッションが成功しなかった場合、ステップ８４２に示すようにセッションは失敗し、プロセスが終了する。

ＲＴＰセッションが成功した場合、ステップ８５０でデータ交換が完了するまでＲＴＰ交換を続行する。

再度ステップ８０８を参照して、ＩＰアドレスがローカルであると判定された場合、ステップ８５２でＩＰ電話１２０ＡはＩＰ電話１２０Ｂに対してＡＲＰする。

ステップ８５４でシステムは、ＩＰ電話１２０ＢがＡＲＰに応答するか否かを判定する。ＩＰ電話１２０ＢがＡＲＰに応答しない場合、ステップ８４０でパケットをドロップし、ステップ８４２に示すようにセッションは失敗し、プロセスが終了する。

ＩＰ電話１２０ＢがＡＲＰに応答する場合、ステップ８５６でＩＰ電話１２０ＡはＲＴＰパケットをＩＰ電話１２０Ｂに送信する。パケット・ヘッダーの一例を８５６の一部に示す。このパケット・ヘッダーの一例は、電話１プライベートと示されているソースＩＰアドレス、示してあるように呼セットアップ・プロセス４８０中に割り当てられたポート範囲から選択されたソース・ポート、ここでは呼セットアップ・プロセス中にＭＧＣによって示された電話２プライベートと示されている宛先ＩＰアドレス、および呼セットアップ・プロセス中にＭＧＣによって示された電話２ポートと示されている宛先ポートを含んでいる。

ステップ８５８でＩＰ電話１２０ＢはＲＴＰパケットを受信し、ステップ８４６でＩＰ電話１２０ＢはＩＰ電話１２０ＡにＲＴＰパケットによって応答する。一実施形態では、パケット・ヘッダーはこの段階で、電話２プライベートと示されたソースＩＰアドレス、示されたように呼セットアップ・プロセス４８０中に割り当てられたポート範囲から選択されたソース・ポート、ここでは呼セットアップ・プロセス中にＭＧＣによって示された電話１プライベートと示されている宛先ＩＰアドレス、および呼セットアップ・プロセス中にＭＧＣによって示された電話１ポートとして示されている宛先ポートを含む。

ステップ８４８でシステムは、ＲＴＰセッションが成功したか否かを判定する。ＲＴＰセッションが成功しなかった場合、ステップ８４２に示したようにセッションは失敗し、プロセスが終了する。

ＲＴＰセッションが成功した場合、ステップ８５０ではデータ交換が完了するまでＲＴＰ交換が続行し、そこでプロセスが終了する。

したがって、一実施形態では、同一ＩＰサブネット内の内部ＩＰ電話の呼は、別のＩＰサブネット内の内部ＩＰ電話１２０間で行われるＩＰ電話の呼をサービス・ゲートウェイ１７０を介して経路指定するよう維持しながら、ＩＰ電話１２０間で直接送信する。

図９Ａ、９Ｂ、および９Ｃ：ＩＰ電話からトランキング・ゲートウェイへのＲＴＰフロー
図９Ａ、９Ｂ、および９Ｃは、クライアントが開始したＩＰ電話の呼に関してＩＰ電話１２０からトランキング・ゲートウェイ１６０までのＲＴＰデータ・フローを流れ図で示している。図９Ａ、９Ｂ、および９Ｃはデータ・フローの一例を示したものであり、このフローは本発明による様々な方法で実行するということに留意されたい。図示する様々なステップは別の順番で実行しても、または省略してもよく、あるいは必要に応じて様々な追加のステップを実行することもできるということにさらに留意されたい。

図示するように、ＲＴＰコール・プロセスは、図５Ａ〜７Ｃを参照して上記で説明したＤＨＣＰ／ＴＦＴＰプロセス４０４、クライアント登録プロセス４０６、および呼セットアップ・プロセス４８０の後で実行することが好ましい。

ステップ９０２でクライアントはＲＴＰの呼を開始する。好ましい実施形態では、クライアントはＩＰ電話１２０を介して呼を開始する。

ステップ９０４でシステムは、ＭＧＣ １５０が宛先ＩＰアドレスおよびポートを提供したか否かを判定する。ＭＧＣ １５０が宛先ＩＰアドレスおよびポートを提供しなかった場合、ステップ９０６でセッションは失敗し、プロセスが終了する。ＭＧＣ １５０が宛先ＩＰアドレスおよびポートを提供した場合、ステップ９０８でクライアントはＲＴＰパケットを宛先トランキング・ゲートウェイ（ＴＧ）１６０に送信する。パケット・ヘッダーの一例を９０８の一部に示す。このパケット・ヘッダーの一例は、電話１プライベートと示されたソースＩＰアドレス、示されたように呼セットアップ・プロセス４８０中に割り当てられたポート範囲から選択されたソース・ポート、ここでは呼セットアップ・プロセス中にＭＧＣによって示されたＴＧパブリックと示してある宛先ＩＰアドレス、および呼セットアップ・プロセス中にＭＧＣによって示されたＴＧポートと示されている宛先ポートを含む。

ステップ９１０でサービス・ゲートウェイ１７０はＲＴＰパケットを受信し、ステップ９１２でＩＰ宛先がローカルか遠隔かを判定する。ＩＰ宛先がローカルであると判定された場合、ステップ９１４でデータ（パケット）をローカル・インターフェースによって転送し、ステップ９０６でセッションは失敗し、プロセスが終了する。

ＩＰ宛先が遠隔である場合、ステップ９１６でＳＧ １７０は宛先ＩＰアドレスに基づいて宛先トンネルを選択する。ステップ９１８でＳＧ １７０は宛先トンネルが動作可能であるか否かを判定する。宛先トンネルが動作可能でない場合、９２０でＳＧ １７０は代替トンネルが使用可能であるか否かを判定する。使用可能な代替トンネルがない場合、ステップ９２２でパケットをドロップし、ステップ９０６に示すようにセッションは失敗し、プロセスが終了する。

代替トンネルが使用可能である場合、プロセスは後述するステップ９２４を続行する。

ステップ９１８を再度参照して、宛先トンネルが動作可能である場合、ステップ９２４でＳＧ １７０はデータに対してＮＡＰＰＴ（ネットワーク・アドレス永続ポート変換）を実行する。一実施形態では、ソースＩＰアドレスが電話１プライベートから電話１パブリックに設定され、ソース・ポートが「未変更」のまま残され、宛先ＩＰアドレスがＴＧパブリック・アドレスに設定され、宛先ポートがＴＧによって示されるように、パケット・ヘッダー情報を変更する。

ステップ９２６でＳＧ １７０はデータに対してＩＰＳｅｃ暗号化を実行する。一実施形態では、パケット・ヘッダー情報は次の変更を含む。すなわち、ソースＩＰアドレスはパブリックＮＡＴアドレスに設定され、宛先ＩＰアドレスはＶＰＮコンセントレータのアドレスに設定されることを含む。ソースおよび宛先ポート情報は変更せずに残される。

ステップ９２８でＳＧ １７０は選択されたトンネルを介してデータを転送する。次いでステップ９３０でデータはチャネル・パートナー・ネットワーク、すなわちＩＳＰのネットワークを横断し、ステップ９３２でデータはＶＰＮコンセントレータ１３６に到達する。ＶＰＮコンセントレータ１３６はステップ９３４に示すようにデータを解読し、次いでステップ９３６でそのデータをローカル・ルータに転送する。

ステップ９３８でデータはＴＧ １６０に到達する。ステップ９４０でシステムはＴＧ １６０がデータを受信するか否かを判定する。ＴＧ １６０がデータに応答しない場合、ステップ９２２に示すようにパケットをドロップし、ステップ９０６でセッションは失敗し、プロセスが終了する。

ＴＧ １６０がデータを受信する場合、ステップ９４２でＴＧはＲＴＰデータを処理する。ステップ９４４でシステムはＴＧ １６０が応答するか否かを判定する。ＴＧ １６０が応答しない場合、ステップ９０６に示すようにセッションは失敗し、プロセスが終了する。

ＴＧ １６０が応答する場合、ステップ９４６に示すようにシステムはＲＴＰセッションが成功するか否かを判定する。ＲＴＰセッションが成功する場合、ステップ９４８でＲＴＰ交換はデータ交換が完了するまで続行し、プロセスが終了する。

図１０Ａおよび１０Ｂ：ＩＰ電話から外部ＩＰ電話ＲＴＰへのＲＴＰフロー
図１０Ａおよび１０Ｂは、第１の内部ＩＰ電話１２０Ａによって開始された呼に関する内部ＩＰ電話１２０Ａと外部ＩＰ電話１２０Ｃの間のＲＴＰデータ・フローを流れ図で示している。図１０Ａおよび１０Ｂはデータ・フローの一例を示したものであり、このフローは本発明による様々な方法で実行するということに留意されたい。図示する様々なステップは別の順番で実行しても、または省略してもよく、あるいは必要に応じて様々な追加のステップを実行することもできるということにさらに留意されたい。

図示するように、ＲＴＰコール・プロセスは、図５Ａ〜７Ｃを参照して上記で説明したＤＨＣＰ／ＴＦＴＰ４０４、クライアント登録プロセス４０６、および呼セットアップ・プロセス４８０の後で実行することが好ましい。

ステップ１００２でＩＰ電話１２０Ａは外部ＩＰ電話１２０Ｃに対してＲＴＰコールを開始する。

ステップ１００４でシステムは、ＭＧＣ １５０が宛先ＩＰアドレスおよびポートを提供したか否かを判定する。ＭＧＣ １５０が宛先ＩＰアドレスおよびポートを提供しなかった場合、ステップ１００６でセッションは失敗し、プロセスが終了する。ＭＧＣ １５０が宛先ＩＰアドレスおよびポートを提供した場合、ステップ１００８でクライアントは、ＲＴＰパケットを宛先の電話、すなわちＩＰ電話１２０Ｃに送信する。一実施形態では、データに対するパケット・ヘッダーはこの段階で、電話１プライベートに設定されたソースＩＰアドレス、呼セットアップ・プロセス中に選択されたポートに設定されたＲＴＰポート、呼セットアップ・プロセス中にＭＧＣによって示された電話２パブリックに設定された宛先ＩＰアドレス、および呼セットアップ・プロセス中にＭＧＣによって示された電話２ポートに設定された宛先ポートを含む。

ステップ１０１０でサービス・ゲートウェイ（ＳＧ）１７０はＲＴＰ（パケット）を受信し、ステップ１０１２でＩＰ宛先がローカルか遠隔かを判定する。「ローカル」および「遠隔」という用語は、それぞれに発呼側ＩＰ電話のＩＰサブネットの内部または外部である顧客ネットワーク内の呼の宛先を意味する。すなわち、宛先がローカルである場合、サービス・ゲートウェイ１７０を介して送信することを必要とせずに呼を宛先ＩＰ電話１２０に直接送信する。

ＩＰ宛先がローカルである場合、ステップ１０１４でローカル・インターフェースを介してパケットを転送し、１００６で示したようにセッションは失敗し、プロセスが終了する。

ＩＰアドレスが遠隔であると判定された場合、ステップ１０１６でＳＧ １７０は宛先ＩＰアドレスに基づいて宛先トンネルを選択する。

ステップ１０１８でＳＧ １７０は宛先トンネルが動作可能か否かを判定する。宛先トンネルが動作可能でない場合、１０２０でＳＧ １７０は代替トンネルが使用可能であるか否かを判定する。使用可能な代替トンネルがない場合、ステップ１０２２でパケットをドロップし、ステップ１００６で示したようにセッションは失敗し、プロセスが終了する。

代替トンネルが使用可能である場合、プロセスは後述するステップ１０２４を続行する。

ステップ１０１６を再度参照して、宛先トンネルが動作可能である場合、ステップ１０２４でＳＧ １７０はコール・データ、すなわちパケットに対してＮＡＰＰＴを実行する。一実施形態では、パケット・ヘッダー情報は次のように変更する。すなわち、示してあるように、ソースＩＰアドレスは電話１プライベートから電話１パブリックに変更し、ソース・ポートは「未変更」のまま残し、宛先ＩＰアドレスは電話２パブリックに設定し、宛先ポートは電話２に設定する。

ステップ１０２６でＳＧ １７０は、コール・データ（パケット）に対してＩＰＳｅｃ暗号化を実行する。元のパケットは、サービス・ゲートウェイの外部インターフェース・アドレスのソース・アドレスとＶＰＮコンセントレータ上の宛先アドレスと共に新パケットにカプセル化する。１０３０でＳＧ １７０は、選択されたトンネルを介してこのデータを転送する。ステップ１０３２でこのデータは顧客ネットワークを横断し、ステップ１０３４に示すようにＶＰＮコンセントレータ１３６Ａに到達する。ステップ１０３６でＶＰＮコンセントレータ１３６Ａは、このコール・データを解読する。

ステップ１０３８でＶＰＮコンセントレータ１３６Ａは、宛先のルートがローカルかトンネルにあるかを判定する。使用される宛先ルートがローカル・ゲートウェイかトンネルかにより、第２のＶＰＮコンセントレータ１３６Ｂまたは第１のＶＰＮコンセントレータ１３６Ａはそれぞれに、図示するようにステップ１０４６および１０４８を実行するということに留意されたい。

宛先ルートがローカル・ゲートウェイを使用する場合、ステップ１０４０でＶＰＮコンセントレータ１３６Ａは、コール・データをローカル・ルータに経路指定する。ローカル・ルータは、ステップ１０４２に示すようにデータを第２のＶＰＮコンセントレータ１３６Ｂに転送する。ステップ１０４４でデータは第２のＶＰＮコンセントレータ１３６Ｂに到達する。ＶＰＮコンセントレータ１３６Ｂは、ステップ１０４６に示すように宛先ＩＰアドレスに基づいて宛先トンネルを選択する。ステップ１０４８で第２のＶＰＮコンセントレータ１３６Ｂは、データに対してＩＰＳｅｃ暗号化を実行する。

ステップ１０３８を再度参照して、宛先ルートがトンネルにある場合、ステップ１０４６でＶＰＮコンセントレータ１３６Ａは、ステップ１０４６に示すように宛先ＩＰアドレスに基づいて宛先トンネルを選択する。ステップ１０４８でＶＰＮコンセントレータ１３６Ａは、データに対してＩＰＳｅｃ暗号化を実行する。

ステップ１０５０で、データを選択されたトンネルを介して転送する。次いでステップ１０５８でデータはチャネル・パートナーのネットワークを横断し、ステップ１０６０で第２のＳＧ １７０Ｂに到達する。第２のＳＧ １７０Ｂは、ステップ１０６２に示すようにデータを解読し、ステップ１０６４でＮＡＰＰＴを実行する。一実施形態では、パケット・ヘッダーはこの段階で、電話１パブリックＮＡＴに設定されたソースＩＰアドレス、未変更電話１ポートのまま残されたソース・ポート、電話２パブリックから電話２プライベートに変更された宛先ＩＰアドレス、および未変更電話２ポートのまま残された宛先ポートを含む。

次いで第２のＳＧ １７０Ｂは、ステップ１０６６に示すようにローカル・インターフェースを介してデータを外に転送する。

ステップ１０６８でシステムは、ＩＰ電話１２０Ａがデータを受信するか否か、すなわちＡＲＰに応答するか否かを判定する。ＩＰ電話１２０Ａがデータを受信しない場合、ステップ１０２２に示すようにパケットをドロップし、セッションは失敗し、プロセスが終了する。ＩＰ電話１２０Ａがデータを受信する場合、ステップ１０７０で第２のＩＰ電話１２０ＢはＲＴＰデータを処理する。

ステップ１０７２でシステムは、ＩＰ電話１２０Ｂが応答するか否か、すなわちデータを受信するか否かを判定する。ＩＰ電話１２０Ｂが応答しない場合、ステップ１００６に示すようにセッションは失敗し、プロセスが終了する。ＩＰ電話１２０Ｂが応答する場合、ステップ１０７４でシステムは、ＲＴＰセッションが成功するか否かを判定する。

ＲＴＰセッションが成功する場合、ステップ１０７６でＲＴＰ交換は、データ交換が完了するまで続行し、プロセスが終了する。

図１１：三角問題への解決策
図１１は、本発明の様々な実施形態によって実施する、上記の三角問題に対する解決策の一実施形態を示す図である。図１１は三角問題解決策プロセスの一実施形態を示したものであり、この解決策プロセスは本発明による様々な方法で実行するということに留意されたい。図示する様々なステップは別の順番で実行しても、または省略してもよく、あるいは必要に応じて様々な追加のステップを実行することもできるということにさらに留意されたい。

図１１に示すように、１１０２で呼セットアップ要求を受信する。一実施形態では、呼セットアップ要求はソースＩＰアドレスと宛先の電話番号とを含む。

１１０４では、第１のメディア・ゲートウェイをソースＩＰアドレスに基づいて選択する。例えば一実施形態では、第１のメディア・ゲートウェイは、ソースＩＰアドレスと対応するメディア・ゲートウェイの間の関連を記憶するテーブル・ルックアップによって選択される。

１１０６で、宛先電話番号に基づいて第２のメディア・ゲートウェイを選択する。一実施形態では、宛先電話番号と対応するメディア・ゲートウェイの間の関連を記憶するテーブル・ルックアップによって第２のメディア・ゲートウェイを選択することもできる。

様々な実施形態で、第１および／または第２のメディア・ゲートウェイは、ＩＰ電話、トランキング・ゲートウェイ、ファックス機器、ページャ、または任意の他のタイプのメディア・ゲートウェイであってよいということに留意されたい。メディア・ゲートウェイのうちの１つがトランキング・ゲートウェイである一実施形態では、トランキング・ゲートウェイは、公衆交換電話網（ＰＳＴＮ）へのインターフェースを提供し、これによって外部テレフォニー・デバイスとの通信を実行する。

１１０８で第１のメディア・ゲートウェイのパブリックＩＰアドレスを第２のメディア・ゲートウェイのパブリックＩＰアドレスと比較し、第１のメディア・ゲートウェイのパブリックＩＰアドレスが第２のメディア・ゲートウェイのパブリックＩＰアドレスと同一である場合、１１１０で第１のメディア・ゲートウェイのプライベートＩＰアドレスと第２のメディア・ゲートウェイのプライベートＩＰアドレスを呼セットアップのために選択する。

第１のメディア・ゲートウェイのパブリックＩＰアドレスが第２のメディア・ゲートウェイのパブリックＩＰアドレスと同一でない場合、１１１２で第１のメディア・ゲートウェイのパブリックＩＰアドレスと第２のメディア・ゲートウェイのパブリックＩＰアドレスを呼セットアップのために選択する。

一実施形態によれば、１１１４で第１のメディア・ゲートウェイの選択されたＩＰアドレス（プライベートでもパブリックでも）を第２のメディア・ゲートウェイに送信し、第２のメディア・ゲートウェイの選択されたＩＰアドレスを第１のメディア・ゲートウェイに送信する。したがって、メディア・ゲートウェイには、現在のコール・セッションに対するそれぞれの宛先ＩＰアドレスを提供する。一実施形態では、図４Ａ、４Ｂ、６Ａ、６Ｂを参照して上記で説明したように呼セットアップ要求以前の登録プロセスによってＩＰアドレスを提供する。例えば一実施形態では、メディア・ゲートウェイは、メディア・ゲートウェイのパブリックＩＰアドレスを送信することによってメディア・ゲートウェイ・コントローラ１５０に登録する。パブリックＩＰアドレスは、後で呼セットアップ・プロセスで参照するために受信し、記憶する（例えばメディア・ゲートウェイ・コントローラ１５０によって）。メディア・ゲートウェイがシステム内部にある場合（外部ＩＰデバイスに導くトランキング・ゲートウェイとは反対に）、（例えばメディア・ゲートウェイ・コントローラ１５０に）メディア・ゲートウェイを登録することは、上記のように使用するためにメディア・ゲートウェイのプライベートＩＰアドレスを送信すること、およびこのプライベートＩＰアドレスを記憶することも含む。

最後に、１１１６で第１のメディア・ゲートウェイは、第２のメディア・ゲートウェイの選択されたＩＰアドレスを使用してデータを第２のメディア・ゲートウェイに送信し、第２のメディア・ゲートウェイは、第１のメディア・ゲートウェイの選択されたＩＰアドレスを使用してデータを第１のメディア・ゲートウェイに送信する。すなわち、２つのメディア・ゲートウェイ間のコール・セッションを進める。

したがって、中でもＩＰアドレスおよび関連付けられた電話番号のようなメディア・ゲートウェイに関する区別情報を受信して記憶することにより、この方法は、双方向の内部コール・セッションと、内部ＩＰ電話と外部デバイス、例えば内部ＩＰ電話にトランキング・ゲートウェイを介してインターフェースしている外部電話が関与するコール・セッションとを区別する。

図２〜１１は、本発明を使用する様々な適用例を示している。しかし、本発明はこれら適用例に限定されるものではなく、むしろ様々な適用例のどれにでも使用するということに留意されたい。

メモリおよび搬送媒体
システムは、本発明の一実施形態によるソフトウェアを記憶するメモリ媒体を含むことが好ましい。「メモリ媒体」という用語は、ＣＤ−ＲＯＭ、フロッピー（登録商標）・ディスク、テープ・デバイスなどのインストール媒体、ＤＲＡＭ、ＳＲＡＭ、ＥＤＯ ＲＡＭ、ＲＲＡＭなどのようなコンピュータ・システム・メモリまたはランダム・アクセス・メモリ（ＲＡＭ）、またはハードドライブなどの磁気媒体または光記憶装置のような不揮発性メモリを含むことを意図している。メモリ媒体は、同様に他のタイプのメモリまたはこれらの組み合わせを含む。

さらに、メモリ媒体は、ソフトウェア・プログラムを記憶または実行する第１のコンピュータに配置しても、あるいはインターネットのようなネットワークを介して第１のコンピュータに接続する第２の別のコンピュータに配置してもよい。後者の場合、第２のコンピュータは第１のコンピュータが実行するためのプログラム命令を提供する。またコンピュータ・システムは、パーソナル・コンピュータ・システム、メインフレーム・コンピュータ・システム、ワークステーション、ネットワーク機器、インターネット機器、パーソナル・デジタル・アシスタント（ＰＤＡ）、テレビジョン・セットトップ・ボックス、または他のデバイスを含めて様々な形態を取ることができる。一般に、「コンピュータ・システム」という用語は、メモリ媒体からの命令を実行する少なくとも１つのプロセッサを有する任意のデバイス、または方法またはアルゴリズムを実行するように構成可能なプログラム可能論理を含む任意のデバイスを包含するものと広義に定義する。

様々な実施形態は、搬送媒体上で上記説明に従って実現される命令および／またはデータを受信し、または記憶することをさらに含む。適切な搬送媒体は、上記のようなメモリ媒体、並びにネットワークおよび／または無線リンクのような通信媒体を介して搬送される電気信号、電磁信号、またはデジタル信号のような信号を含む。

以上、上記実施形態を非常に詳細に説明したが、当業者には、上記の開示を完全に理解すれば多数の変形形態および修正形態は明らかになろう。首記の特許請求の範囲は、このような変形形態および修正形態のすべてを包含するものと解釈されることを意図している。

従来技術によるＩＰテレフォニー・システムを示す図である。 本発明の一実施形態によるＩＰテレフォニー・システムを示す図である。 本発明の一実施形態による基本的なサービス・ゲートウェイ／ＶＰＮを示す図面である。 本発明の一実施形態によるＩＰテレフォニー・ネットワークを示す図である。 一実施形態によるＩＰ電話の初期化、構成、および使用の流れ図である。 一実施形態によるクライアントＤＨＣＰリース交渉プロセスの流れ図である。 本発明の一実施形態によるＩＰ電話登録プロセスの流れ図である。 本発明の一実施形態による呼セットアップ・プロセスの流れ図である。 本発明の一実施形態による内部ＩＰ電話から内部ＩＰ電話へのＲＴＰフローの流れ図である。 本発明の一実施形態によるＩＰ電話からトランキング・ゲートウェイへのＲＴＰフローの流れ図である。 本発明の一実施形態による内部ＩＰ電話から外部ＩＰ電話へのＲＴＰフローの流れ図である。 一実施形態による三角問題に対する解決策の流れ図である。

Claims (5)

1. ＩＰ電話とサービス・ゲートウェイを含むネットワークを有するシステムであって、前記サービス・ゲートウェイが前記ＩＰ電話の前記ネットワーク内外の通信装置とのＩＰ通信を提供するよう構成されたシステムにおいて、ＩＰ電話とサービス・ゲートウェイとでＩＰテレフォニーを実行する方法において、
   起動された前記ＩＰ電話と前記サービス・ゲートウェイとによりＤＨＣＰプロセスを実行するステップであって、
   （１）前記ＩＰ電話から前記サービス・ゲートウェイに自己の識別子を送信することと、
   （２）前記サービス・ゲートウェイが前記識別子を送信したＩＰ電話に、該識別子に基づいて割り当てられるポート番号の範囲であって使用予約されていない複数のポート番号を含んだポート番号の範囲を示すポート情報を送信することと
   を含むＤＨＣＰプロセスを実行するステップと、
   前記ＩＰ電話が、該受信したポート情報にしたがって、前記複数のポート番号が付された複数のポートを複数のサービスのそれぞれに割り当てて使用可能にして、前記ＩＰ電話を使用したＩＰ通信を可能にするステップと
   を含む方法。
2. ＩＰテレフォニーを実行するシステムにおいて、
   ネットワークと、
   ＩＰ電話と、
   前記ネットワークを介して前記ＩＰ電話に結合されたサービス・ゲートウェイと、
   を含み、
   前記ＩＰ電話と前記サービス・ゲートウェイとの間でＤＨＣＰプロセスを実行可能であり、このＤＨＣＰプロセスが、
   （１）前記ＩＰ電話から前記サービス・ゲートウェイに自己の識別子を送信することと、
   （２）前記サービス・ゲートウェイが前記識別子を送信したＩＰ電話に、該識別子に基づいて割り当てられるポート番号の範囲であって使用予約されていない複数のポート番号を含んだポート番号の範囲を示すポート情報を送信することと
   を有しており、
   前記ＩＰ電話が、該受信したポート情報にしたがって、前記複数のポート番号が付された複数のポートを複数のサービスのそれぞれに割り当てて使用可能にして、前記ＩＰ電話を使用したＩＰ通信を可能にするよう構成した
   システム。
3. ＩＰ電話とサービス・ゲートウェイを含むネットワークを有するシステムであって、前記サービス・ゲートウェイが前記ＩＰ電話の前記ネットワーク内外の通信装置とのＩＰ通信を提供するよう構成されたコンピュータ・システムにおいて、ＩＰ電話とサービス・ゲートウェイとでＩＰテレフォニーを実行させるためのプログラムであって、前記コンピュータ・システムに、
   起動されたＩＰ電話とサービス・ゲートウェイとの間で、
   （１）前記ＩＰ電話から前記サービス・ゲートウェイに自己の識別子を送信することと、
   （２）前記サービス・ゲートウェイが前記識別子を送信したＩＰ電話に、該識別子に基づいて割り当てられるポート番号の範囲であって使用予約されていない複数のポート番号を含んだポート番号の範囲を示すポート情報を送信することと
   を含むＤＨＣＰプロセスを実行させることと、
   前記ＩＰ電話が、該受信したポート情報にしたがって、前記複数のポート番号が付された複数のポートを複数のサービスのそれぞれに割り当てて使用可能にさせるようにして、前記ＩＰ電話を使用したＩＰ通信を可能にさせることと
   を実行させるためのプログラム。
4. ＩＰ電話を登録するステップをさらに含んでおり、このステップが、
   ＩＰ電話が自己のパブリックＩＰアドレスをメディア・ゲートウェイ・コントローラに送信するステップと、
   前記メディア・ゲートウェイ・コントローラが該ＩＰ電話のパブリックＩＰアドレスを受信して記憶するステップと
   を含む、請求項１に記載の方法。
5. ＩＰ電話を登録する前記ステップが、
   前記ＩＰ電話が自己のプライベートＩＰアドレスを前記メディア・ゲートウェイ・コントローラに送信するステップと、
   前記メディア・ゲートウェイ・コントローラが該ＩＰ電話のプライベートＩＰアドレスを受信して記憶するステップと
   をさらに含み、
   前記プライベートＩＰアドレスを決定するために前記パブリックＩＰアドレスと前記ポート番号の範囲が使用可能である請求項４に記載の方法。

Images