(57)【要約】スクリーニングによって、複数のネットワークを通るリアルタイムトランスポートプロトコルフローの制御を補助するシステムが示されている。このシステムは、送受信機と、このシステムによって実行される機能を定義するロジックが格納されたメモリ、およびプロセッサを利用する。このプロセッサは、メモリにより、次の機能を実行できる。即ち、送受信機が受信したルート情報が、外部からのものか、内部からのものかを決定する機能と、もし、ルート情報が外部からのものであれば、ルート情報の第１の内部スクリーンを適用し、受信ルート情報により定義されている終点アドレスを、第１の内部スクリーンにより定義されているローカル終点アドレスと比較する機能と、もし、ルート情報が内部からのものであれば、ルート情報の第２の内部スクリーンを適用し、受信ルート情報により定義されている起点アドレスを、第２の内部スクリーンにより定義されているローカルの起点アドレスと比較する機能である。
2005502219.tif 000002
【特許請求の範囲】
【請求項１】
リアルタイムトランスポートプロトコルによるルートを、前記ルートとローカルポリシーとの比較の前に、スクリーニングするシステムであって、
送受信機と、
前記システムによって実行される機能を持ったソフトウエアと、
前記送受信機が受信したルート情報が、外部からのものか、内部からのものかを決定するステップと、前記ルート情報が外部からのものであれば、前記ルート情報の第１の内部スクリーンを適用し、前記受信ルート情報により定義されている終点アドレスを、前記第１の内部スクリーンにより定義されているローカル終点アドレスと比較するステップと、前記ルート情報が内部からのものであれば、前記ルート情報の第２の内部スクリーンを適用し、前記受信ルート情報により定義されている起点アドレスを、前記第２の内部スクリーンにより定義されているローカルの起点アドレスと比較するステップを実行する前記ソフトウエアが実装されたプロセッサ
とからなるシステム。
【請求項２】
前記プロセッサは、前記ソフトウエアによって、前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスと一致しない場合、この前記受信ルート情報を破棄するステップを更に含む請求項１のシステム。
【請求項３】
前記プロセッサは、前記ソフトウエアによって、前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスの一部と一致する場合、前記受信ルート情報により定義されている前記終点アドレスと、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスのどちらがより限定されたものであるかを決定するステップを更に含む請求項１のシステム。
【請求項４】
前記プロセッサは、前記ソフトウエアによって、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスが、前記受信ルート情報により定義されている前記終点アドレスより限定された終点アドレスである場合、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスを保持し、前記受信ルート情報により定義されている前記終点アドレスを破棄するステップを更に含む請求項３のシステム。
【請求項５】
前記プロセッサは、前記ソフトウエアによって、前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスより限定された終点アドレスである場合、前記受信ルート情報により定義されている前記終点アドレスを、後でローカルポリシーと比較する為に記憶するステップを更に含む請求項３のシステム。
【請求項６】
前記終点アドレスのフォーマットは、Ｅ．１６４スタイルのアドレス、インターネットスタイルのアドレス、ＳＩＰ電話スタイルのアドレス、又は非ＳＩＰ電話スタイルのアドレスである請求項１のシステム。
【請求項７】
前記プロセッサは、前記ソフトウエアによって、前記受信ルート情報が前記起点アドレスを含まない場合、前記受信ルート情報を、後でローカルポリシーと比較する為に記憶するステップを更に含む請求項１のシステム。
【請求項８】
前記プロセッサは、前記ソフトウエアによって、前記受信ルート情報により定義されている前記起点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスと一致しない場合、この前記受信ルート情報を破棄するステップを更に含む請求項１のシステム。
【請求項９】
前記プロセッサは、前記ソフトウエアによって、前記受信ルート情報により定義されている前記起点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスの一部と一致する場合、前記受信ルート情報により定義されている前記起点アドレスと、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスのどちらがより限定されたものであるかを決定するステップを更に含む請求項１のシステム。
【請求項１０】
前記プロセッサは、前記ソフトウエアによって、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスが、前記受信ルート情報により定義されている前記起点アドレスより限定された起点アドレスである場合、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスを保持し、前記受信ルート情報により定義されている前記起点アドレスを破棄するステップを更に含む請求項９のシステム。
【請求項１１】
前記プロセッサは、前記ソフトウエアによって、前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスより限定された終点アドレスである場合、前記受信ルート情報により定義されている前記終点アドレスを、後でローカルポリシーと比較する為に記憶するステップを更に含む請求項９のシステム。
【請求項１２】
前記プロセッサは、前記ソフトウエアによって、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報により提供されている受信キャリア属性を読み込むステップを更に含み、前記受信キャリア属性には、前記受信ルート情報の起点が記載されている請求項１のシステム。
【請求項１３】
前記プロセッサは、前記ソフトウエアによって、前記受信キャリア属性により定義されている受信キャリア名が、ローカルキャリア名と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを更に含む請求項１２のシステム。
【請求項１４】
前記プロセッサは、前記ソフトウエアによって、前記受信キャリア属性により定義されている受信キャリア利用可能日が、ローカルキャリア利用可能日と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを更に含む請求項１２のシステム。
【請求項１５】
前記プロセッサは、前記ソフトウエアによって、前記受信キャリア属性により定義されている時間単位受信キャリア利用可能時間が、時間単位ローカルキャリア利用可能時間と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを更に含む請求項１２のシステム。
【請求項１６】
前記プロセッサは、前記ソフトウエアによって、前記受信キャリア属性により定義されている受信キャリア利用可能時間が、ローカルキャリア利用可能時間と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを更に含む請求項１２のシステム。
【請求項１７】
前記プロセッサは、前記ソフトウエアによって、前記受信キャリア属性により定義されている受信キャリアコストが、ローカルキャリアコストと一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを更に含む請求項１２のシステム。
【請求項１８】
前記起点アドレスのフォーマットは、Ｅ．１６４スタイルのアドレス、インターネットスタイルのアドレス、ＳＩＰ電話スタイルのアドレス、又は非ＳＩＰ電話スタイルのアドレスである請求項１のシステム。
【請求項１９】
前記ルート情報は、テレフォニールーティングインターネットプロトコル（ＴＲＩＰ）のアップデートメッセージによって提供される請求項１のシステム。
【請求項２０】
リアルタイムトランスポートプロトコルによるルートを、前記ルートとローカルポリシーと比較する前に、スクリーニングを行う方法であって、
第一のエンドポイントから第２のエンドポイントへの前記ルートを記述するルート情報を受け取るステップと、
前記ルート情報が、外部から受け取ったものか、内部から受け取ったものかを決定するステップと、
前記ルート情報が外部からのものであれば、前記ルート情報の第１の内部スクリーンを適用し、前記受信ルート情報により定義されている終点アドレスを、前記第１の内部スクリーンにより定義されているローカル終点アドレスと比較するステップと、前記ルート情報が内部からのものであれば、前記ルート情報の第２の内部スクリーンを適用し、前記受信ルート情報により定義されている起点アドレスを、前記第２の内部スクリーンにより定義されているローカルの起点アドレスと比較されるステップ
とからなるスクリーニングを行う方法。
【請求項２１】
前記受信ルート情報により定義されている終点アドレスを、前記第１の内部スクリーンにより定義されているローカル終点アドレスと比較する前記ステップは、前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスと一致しない場合、この前記受信ルート情報を破棄するステップを含む請求項２０の方法。
【請求項２２】
前記受信ルート情報により定義されている終点アドレスを、前記第１の内部スクリーンにより定義されているローカル終点アドレスと比較する前記ステップは、前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスの一部と一致する場合、前記受信ルート情報により定義されている前記終点アドレスと、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスのどちらがより限定されたものであるかを決定するステップを含む請求項２０の方法。
【請求項２３】
前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスの一部と一致する場合、前記受信ルート情報により定義されている前記終点アドレスと、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスのどちらがより限定されたものであるかを決定するステップを更に含む請求項２２の方法。
【請求項２４】
前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスより限定された終点アドレスである場合、前記受信ルート情報により定義されている前記終点アドレスを、後でローカルポリシーと比較する為に記憶するステップを更に含む請求項２２の方法。
【請求項２５】
前記終点アドレスのフォーマットは、Ｅ．１６４スタイルのアドレス、インターネットスタイルのアドレス、ＳＩＰ電話スタイルのアドレス、又は非ＳＩＰ電話スタイルのアドレスである請求項２０の方法。
【請求項２６】
前記受信ルート情報が前記起点アドレスを含まない場合、前記受信ルート情報を、後でローカルポリシーと比較する為に記憶するステップを更に含む請求項２０の方法。
【請求項２７】
前記受信ルート情報により定義されている起点アドレスを、前記第１の内部スクリーンにより定義されているローカル起点アドレスと比較する前記ステップは、 前記受信ルート情報により定義されている前記起点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスと一致しない場合、この前記受信ルート情報を破棄するステップを含む請求項２０の方法。
【請求項２８】
前記受信ルート情報により定義されている起点アドレスを、前記第１の内部スクリーンにより定義されているローカル起点アドレスと比較する前記ステップは、 前記受信ルート情報により定義されている前記起点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスの一部と一致する場合、前記受信ルート情報により定義されている前記起点アドレスと、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスのどちらがより限定されたものであるかを決定するステップを含む請求項２０の方法。
【請求項２９】
前記受信ルート情報により定義されている前記起点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスの一部と一致する場合、前記受信ルート情報により定義されている前記起点アドレスと、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスのどちらがより限定されたものであるかを決定するステップを更に含む請求項２８の方法。
【請求項３０】
前記受信ルート情報により定義されている前記起点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスより限定された起点アドレスである場合、前記受信ルート情報により定義されている前記起点アドレスを、後でローカルポリシーと比較する為に記憶するステップを更に含む請求項２８の方法。
【請求項３１】
前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報により提供されている受信キャリア属性を読み込むステップを更に含み、前記受信キャリア属性には、前記受信ルート情報の起点が記載されている請求項２０の方法。
【請求項３２】
前記受信キャリア属性により定義されている受信キャリア名が、ローカルキャリア名と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを更に含む請求項３１の方法。
【請求項３３】
前記受信キャリア属性により定義されている受信キャリア利用可能日が、ローカルキャリア利用可能日と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを含む請求項３１の方法。
【請求項３４】
前記受信キャリア属性により定義されている時間単位受信キャリア利用可能時間が、時間単位ローカルキャリア利用可能時間と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを更に含む請求項３１の方法。
【請求項３５】
前記受信キャリア属性により定義されている受信キャリア利用可能時間が、ローカルキャリア利用可能時間と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを更に含む請求項３１の方法。
【請求項３６】
前記受信キャリア属性により定義されている受信キャリアコストが、ローカルキャリアコストと一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄するステップを更に含む請求項３１の方法。
【請求項３７】
リアルタイムトランスポートプロトコルによるルートを、前記ルートとローカルポリシーと比較する前に、スクリーニングするシステムであって、
第一のエンドポイントから第２のエンドポイントへのルートを記述するルート情報を受け取る受取手段と、
前記ルート情報が、外部から受け取ったものか、内部から受け取ったものかを決定し、前記受取手段に論理的に接続されている決定手段と、
前記ルート情報の第１の内部スクリーンを適用し、前記受信ルート情報により定義されている終点アドレスを、前記第１の内部スクリーンにより定義されているローカル終点アドレスと比較し、前記受取手段と前記決定手段に論理的に接続されている決定手段と、
前記ルート情報の第２の内部スクリーンを適用し、前記受信ルート情報により定義されている起点アドレスを、前記第２の内部スクリーンにより定義されているローカルの起点アドレスと比較し、前記受取手段、
前記決定手段及び前記適用手段に論理的に接続されている適用手段
とを備えているシステム。
【請求項３８】
前記ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスと一致しない場合、この前記受信ルート情報を破棄する手段を更に含む請求項３７のシステム。
【請求項３９】
前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスの一部と一致する場合、前記受信ルート情報により定義されている前記終点アドレスと、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスのどちらがより限定されたものであるかを決定する手段を更に含む請求項３７のシステム。
【請求項４０】
前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスが、前記受信ルート情報により定義されている前記終点アドレスより限定された終点アドレスである場合、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスを保持し、前記受信ルート情報により定義されている前記終点アドレスを破棄する手段を更に含む請求項３９のシステム。
【請求項４１】
前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスより限定された終点アドレスである場合、前記受信ルート情報により定義されている前記終点アドレスを、後でローカルポリシーと比較する為に記憶する手段を更に含む請求項３９のシステム。
【請求項４２】
前記終点アドレスのフォーマットは、Ｅ．１６４スタイルのアドレス、インターネットスタイルのアドレス、ＳＩＰ電話スタイルのアドレス、又は非ＳＩＰ電話スタイルのアドレスである請求項３７のシステム。
【請求項４３】
前記受信ルート情報が前記起点アドレスを含まない場合、前記受信ルート情報を、後でローカルポリシーと比較する為に記憶する手段を更に含む請求項３７のシステム。
【請求項４４】
前記受信ルート情報により定義されている前記起点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスと一致しない場合、この前記受信ルート情報を破棄する手段を更に含む請求項３７のシステム。
【請求項４５】
前記受信ルート情報により定義されている前記起点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスの一部と一致する場合、前記受信ルート情報により定義されている前記起点アドレスと、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスのどちらがより限定されたものであるかを決定する手段を更に含む請求項３７のシステム。
【請求項４６】
前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスが、前記受信ルート情報により定義されている前記起点アドレスより限定された起点アドレスである場合、前記第１の内部スクリーンにより定義されている前記ローカル起点アドレスを保持し、前記受信ルート情報により定義されている前記起点アドレスを破棄する手段を更に含む請求項４５のシステム。
【請求項４７】
前記受信ルート情報により定義されている前記終点アドレスが、前記第１の内部スクリーンにより定義されている前記ローカル終点アドレスより限定された終点アドレスである場合、前記受信ルート情報により定義されている前記終点アドレスを、後でローカルポリシーと比較する為に記憶する手段を更に含む請求項４５のシステム。
【請求項４８】
前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報により提供されている受信キャリア属性を読み込む手段を更に含み、前記受信キャリア属性には、前記受信ルート情報の起点が記載されている請求項３７のシステム。
【請求項４９】
前記受信キャリア属性により定義されている受信キャリア名が、ローカルキャリア名と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄する第１の手段を更に含む請求項４８のシステム。
【請求項５０】
前記受信キャリア属性により定義されている受信キャリア利用可能日が、ローカルキャリア利用可能日と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄する第２の手段を更に含む請求項４８のシステム。
【請求項５１】
前記受信キャリア属性により定義されている時間単位受信キャリア利用可能時間が、時間単位ローカルキャリア利用可能時間と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄する第３の手段を更に含む請求項４８のシステム。
【請求項５２】
前記受信キャリア属性により定義されている受信キャリア利用可能時間が、ローカルキャリア利用可能時間と一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄する第４の手段を更に含む請求項４８のシステム。
【請求項５３】
前記受信キャリア属性により定義されている受信キャリアコストが、ローカルキャリアコストと一致しない場合、前記受信ルート情報と前記ローカルポリシーとを比較する前に、前記受信ルート情報を破棄する第５の手段を更に含む請求項４８のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の相互参照）
この出願は、２０００年１２月１１日に出願され、「通信セッション開始の為のルーティング方法および装置」の名称を持つ、米国仮出願番号第６０／２４，８４０号の優先権を主張するとともに、その全内容をこの出願の一部とする。
【０００２】
本発明は、一般に電気通信ネットワークに関するものであり、特に、複数のネットワークを通って流れるリアルタイムトランスポートプロトコルのフロー制御を支援する為の、受信ルート情報をスクリーニングするシステムと方法に関する。
【背景技術】
【０００３】
（発明の背景）
公衆電話交換網（ＰＳＴＮ）は、効率的で、リアルタイム処理の可能な、マルチメディア通信セッションツールへと発展し、そこでは、ユーザーは、ほぼ１０億台の電話のうちのいずれでも選ぶことができ、ほぼ１０億のエンドポイントのどの１つへでも、ダイヤルすることができる。いくつかの研究開発によって、番号割り当て計画、分散電子交換およびルーティング、ネットワーク化されたシグナリングシステムといった、自動ネットワークが可能となった。
【０００４】
番号割り当て計画は、地方、地域、および国の関係当局の後援により、数年にわたって発展していった。現在、Ｅ．１６４と呼ばれるＩＴＵ−Ｔ標準に基く、これらの番号割り当て計画によって、呼び出しのルーティングを可能とする、一般的で階層的な計画が提供されている。以下に、北アメリカの番号割り当て計画（ＮＡＮＰ）の階層の例を示す。電話番号１−９７８−９３３−６１６６を考えると、１は、この電話番号がＮＡＮＰのものであることを示す。９７８は、それがマサチューセッツのエリアコードであることを示す。９３３は、それがウォーバーン（マサチューセッツ）の交換局番号であることを示す。また、６１６６は、それがニューボストン街１３０番のアクメパケットに割り当てられた番号であることを示す。
【０００５】
同様にして、すべての電話番号は世界で、同様の番号要素に分解でき、地理的には、どのネットワーク要素（例えば、電話交換機）で、通信が完了させられるかによって決定される。近年、ポータブル番号の技術が実装され、企業が、その電話番号を機器毎に移動可能とすること、例えば、移動させたり、再度、割当て行うことができるようになっている。最初、この技術は、料金無料の電話番号（例えば１−８００−ＦＬＯＷＥＲＳ（ＴＭ））に利用され、所有者が長距離通信会社に変更することを可能にした。このポータブル番号の発展により、８００番の交換番号は、フリーダイヤル交換局として認知され、データベース（つまりサービス制御点（ＳＣＰ））で、固定階層に結びついた実際のネットワーク番号に変換される。８００番或いは料金無料の電話番号を実際の番号（シャドウアドレス）に分解するプロセスは、よく知られている。
【０００６】
更に、最近、ローカルの番号をポータブルにする開発が行われている。この技術は、交換番号がポータブルであると宣言され、データベース（つまりＳＣＰ）が、実際の番号の場所を特定する為に利用されるという点で、上述のような無料技術と類似している。返される場所は、実際には、終端切換スイッチの電話番号である。そして、その呼び出しは、シグナリングシステム＃７（ＳＳ７）のネットワークの仮想番号に対応付けられ、初期アドレスメッセージ（ＩＡＭ）中のエンドポイントへの個別の情報要素としての、実番号に受動的に当てられる。再度、呼び出しを送る為に使用される番号は、固定階層に準じた実番号であった。このローカル番号のポータビリティ（ＬＮＰ）も、よく知られている。
【０００７】
無線のネットワークで、ホームロケーション登録（ＨＬＲ）およびビジッタロケーション登録（ＶＬＲ）メカニズムが使用される。無線のネットワーク内では、電話は、それが通信することができるネットワーク上で、繰り返し登録すべきである。ユーザーに適切に呼び出しを向けることができるように、この登録は、電話位置をネットワークに通知する。ローカルのシステム（つまり非ローミング）内にある電話への呼び出しを送る為に、対応する設備は、正確なベースステーションからの呼び出し又はベースステーションへの呼び出しをルーティングさせることができるようになっている。システム間の呼び出しを送る為に、仮想番号が割り付けられており、新しい呼び出しは新システムへ向けられ、その後、それは新しいエンドポイントに電話を接続する。無線のネットワークでは、割当てられた仮想番号が、確立された階層に結びつけられる。
【０００８】
残念ながら、現在、ＰＳＴＮは、ＰＳＴＮの中にある階層に対応するアドレス以外には、実際の通信セッションをルーティングさせることができない。なぜなら、電話番号やその一部は、通信のエンドポイントへのパスを発見する為に使用されるからである。ポータビリティメカニズムは、ネットワークを通って通信を方向付けする為に仮想番号またはシャドウ番号を使用する。
【０００９】
ＰＳＴＮの階層に基づく方法に似て、インターネットはインターネットプロトコル（ＩＰ）に基づいている。ＩＰメッセージは、１つのリンクから次のリンクへ（つまりデータフローの始点からデータフローの終点まで）、ルーティング又は転送される。各ＩＰパケットは、ＩＰアドレス（インターネットプロトコルバージョン４（ＩＰｖ４）では、３２ビット）を含んでいる。各ＩＰアドレスは、さらに、ネットワーク部分を示すビットと、ホスト部分を示すビットを有している。
【００１０】
ＩＰルータは、１つのネットワーク（あるいはリンク）からパケットを受け、かつ別のネットワーク（あるいはリンク）へにそれを渡すために使用される。ＩＰルータの内には、テーブルが設けられており、そのテーブルには、パケットの最適のルーティングを決定するのに利用できる情報あるいは基準を含んでいる。この情報の例はネットワークリンクの状態およびプログラムされた距離表示である。残念ながら、典型的に、ＩＰルータは、終点ＩＰアドレス（それは転送のための適切なルートの探索には役立たない）によってパケットのルーティングを行う。一方、このルーティングシステムのいくつかの例外がある。ネットワークドメインの両側でインテリジェントな装置を使用することによって、ネットワークを通ってパケットを転送する為に一時的なアドレスを割り付け、かつネットワークの向こう側でパケットが、ネットワークを離れた時に、オリジナルのアドレスを回復することは可能である。これは多くの現在のヴァーチャルプライベートネットワーク（ＶＰＮ）の基礎であり、業界でよく知られている。
【００１１】
ルーティングさせるシステムのもう１つの例外は、マルチプロトコルラベルスイッチング（ＭＰＬＳ）である。ＭＰＬＳは、タグスイッチングと呼ばれ、カリフォルニア洲サンノゼのシスコシステムズによって開発された技術に基づいている。ＩＰパケットをルーティングさせるこの方法は、パケットがネットワークを通って現実にとるルートと、終点ＩＰアドレスとを潜在的に分離することを可能にする。ＭＰＬＳの最適の用途のうちの１つは、ＶＰＮ或いはヴァーチャルリーズドラインズ（ＶＬＬ）を作成することである。ＭＰＬＳタグは、ネットワークを通ったデータパケットのルーティングを有効にカプセル化することを可能とする。
【００１２】
つまり、データネットワークは、ＩＰ終点に基づいて、実際のすべてのＩＰパケットフォワーディングを行うということである。一方、ＩＰ終点は、ネットワークトポロジーに関係していて、電話ネットワークのように、パケットを運ぶために使用される。ＭＰＬＳタグおよびパスは、ルーティングに用いられ、ＩＰアドレス部分に結び付けられる一組のルール、例えば、同一ラベル転送クラス（フォワードエキュイバレンスクラス：ＦＥＣ）に基づいて、ＩＰパケットのためにオーバーライドフォワーディングを可能とする。
【００１３】
分散されたスイッチング及びルーティングは、要求されたサイズのネットワークスケールを構成する為に重要である。分散されたスイッチングルーティングの為の電子設備は、通信セッションに一定の役割を持つ必要がある。もしすべてのエンドポイントが各エンドポイント毎に接続を管理しなければならなければ、ネットワークのスケーリングはできないであろう。階層的スキームの中への制御を分配すれば、下層のアドレシングの変更に伴う困難を、さらに増大させることになる。
【００１４】
それらは、ネットワーク要素（例えば電話ネットワーク中のスイッチやデータネットワーク中のルータ）による関連するタスクの実行を保証する為に、それらは、隣接した通信リンクおよび利用可能なルートのステータスを知っていなければならず、シグナリングシステムはこの情報を提供する為に使用される。電話ネットワークでは、使用されるシグナリングシステムは、ＳＳ７のいずれか、あるいはＳＳ７と等価なものである。シグナリングシステムは、個々のリンク、リンクセット、ルートなどに関する情報を示す。データネットワークでは、ボーダーゲートウェイプロトコル（ＢＧＰ）、内部のゲートウェイプロトコル（ＩＧＰ）、オープンショーテストパスファースト（ＯＳＰＦ）などのようなプロトコルは、リンク状態およびルートを決定する為に使用される。
【００１５】
電話ネットワークでは、シグナリングシステムは、ネットワーク経由で「ｅｎｄ−ｔｏ−ｅｎｄ」パス（即ち、ＩＳＵＰ：ＩＳＤＮユーザパート）を確立するのに使用される。残念ながら、ＩＰネットワークでは、「ｅｎｄ−ｔｏ−ｅｎｄ」のパス割付けは存在しない。代わりに、通信セッションを処理する為に、名前または目的にエンドポイントを関連付けるシステムがなければならない。
【００１６】
今日の電話ネットワークは、イエローページ、ホワイトページ、４１１のディレクトリーシステムおよび、他のネットワークのユーザーが目的の場所を見つけるのを助けるディレクトリーサービスを使用する。ビジネスの電話番号が変更されるか、人々が移動すれば、ディレクトリーは更新される。さらに、ほとんどの電話ネットワークは、呼び出しを転送するか、ユーザーのアドレスが新しくなったことを、発信側に伝えるであろう。同様に、今日のデータネットワークは、ユーザーが他のインターネットユーザーを見つけるのを助ける為に、オンラインディレクトリーを使用する。しかし、これらのディレクトリーは多くの理由で不十分である。例えば、これらの理由としては、次のようなものがある。即ち、ほとんどのディレクトリーが電子メール（電子メール）サーバから構築されるので、情報の質は低い。又、ビリングプロセスの一部として維持されていないので、それはほとんどの電子メールシステムで古くなったエントリを生じさせる。更に、すべての電子メールシステムが、ディレクトリー供給者にデータを供給するわけではない。
【００１７】
加えて、もしディレクトリーエントリが手動で入力されない限り、地理的な位置はインターネットドメインアドレスの一部ではないので、インターネットディレクトリは地理的な位置を含んでいない。電話ネットワークのユーザーの場所を特定しようとする場合、都市か町が知られていれば、探索を限定的にすることができる。しかし、この種類の探索は、インターネットディレクトリにおいては、同じようには容易ではない。ユニフォームリソースロケーター（ＵＲＬ）は、典型的にはインターネット上のエンドポイントあるいは位置を示す。ドメイン名に付けられたユーザー名は、ユーザーのアドレスを得る、現在の方法である。そこで、ドメイン名は、ユーザーにそれを使用させている組織によって所有されている。
【００１８】
インターネット上に、包括的なレジストリは現在知られていない。ドメイン名E164.comを備えた包括的なレジストリが、マサチューセッツローウェルのＮＥＴＮＵＭＢＥＲ．ＣＯＭ社によって提案された。この包括的なレジストリの開発は、ＮＵＥＳＴＡＲ社の提案に基づいている。ＮＵＥＳＴＡＲ社は、今ＮＡＮＰの管理を行っている。この提案は、現在のドメイン名サービスを利用し、ＤＮＳサーバで解決できるように、番号のフォーマットをＵＲＬへ変換する。この方法では、各電話番号をＤＮＳサーバへ登録し、他のすべてのＤＮＳサーバへ配布する。ＤＮＳクエリの末端は、例えば、リソースレコードであり、それは、ライトウェイトディレクトリーアクセスプロトコル（ＬＤＡＰ）のディレクトリーサーバである。
【００１９】
従来の有線電話番号とのオーバーラップを回避する為に、ＩＰエンドポイントの包括的なポータブル電話（ＵＰＴ）番号の使用が、ＩＴＵにより提案されているが、これは有効であり、アドレス可能なＩＰエンドポイントを実現する。インターネットとＰＳＴＮ間での呼び出しを可能にする、上記の２つの提案を組み合わせることは可能である。残念ながら、この技術にいくつかの制限がある。これらの制限は次のものを含んでいる。即ち、ＤＮＳの分配および複製はかなりの待ち時間を持っている。又、ＤＮＳアドレス解決は、遅くなることがある。更に、ＤＮＳサーバは、向けられた数のアドレスをすべて扱う能力を持つとは限らない。更に、ＤＮＳサーバは、ラウンドロビンを使わない限り、複製のエントリを管理することができない。更に、ＤＮＳは、並列の更新メカニズムを使用しており、意図しない複製のエントリを生成する可能性がある。更に、プライベートネットワークアドレスあるいはそのアドレッシングを行うゲートウェイは、複製のエントリあるいはそのマッチングを生じさせる可能性がある。更に、要求された資源を扱うポリシーが存在しない。更に、ＰＳＴＮとデータネットワークの間の数値のオーバーラップを解決する手段が無い。
【００２０】
ＰＳＴＮベースのシステムでサービスを受けている今現在の電気通信ネットワークエンドポイントの為に、ゲートウェイを使用して、パケットデータネットワークとＰＳＴＮの間のメディアフローが促進される。ゲートウェイは、データネットワークおよび音声ネットワークの境界にインストールされ、そこで、ゲートウェイはメディア、またシグナリング、を変換し、通信を確実にするのに使用される。ゲートウェイで受けた呼び出しを、この業界で知られた他のゲートウェイへ、ルーティングするいくつかのストラテジーがある。これらのストラテジーの２つは、フルメッシュルーティングと階層型ルーティングである。フルメッシュルーティングは、ほとんどのソフトスイッチングアーキテクチャーに記述された標準の方法である。セッションイニシエイションプロトコル（ＳＩＰ）は、任意の場所の間のシグナリングをサポートするので、ソフトスイッチ間シグナリングシステムである。このモデルでは、すべてのソフトスイッチが、呼び出しを完了する為に、他のすべてのソフトスイッチに対して、仮想接続を行っている。ソフトスイッチメーカーによって提供されるポリシーに基づくソフトスイッチへ、トラヒックを向ける為に使用することができるルーティングテーブルが実装されている。
【００２１】
残念ながら、多くのソフトスイッチから成るネットワークを稼働する場合、ネットワークの所有者は、フルメッシュを作成する為に維持される必要のある、多くの異なるポリシー管理ポイントを抱えている。そのようなポリシー管理問題は、各ソフトスイッチが「他のソフトスイッチの各々のＩＰアドレスと、それらが接続している電話番号やＰＳＴＮを知っている」ことを確実にする問題を含んでいる。複数のベンダーからのソフトスイッチを稼働する場合、さらなる管理問題が発生する。管理問題は、設備が異なるインターフェースを通って管理される場合より複雑となる。
【００２２】
配置されたソフトスイッチの数が大きい場合、異なるルートの共有が起こりやすくなる。フルメッシュルーティングアレンジメントでは、いくつかの異なる出力ソフトスイッチが一杯であるか機能していないかもしれないので、呼び出しのルーティングが困難となることもある。例えば、キャリアが、国内長距離電話を扱うことができる３０のソフトスイッチを備えており、ネットワークが、約５０％で稼働している場合、塞がっていないルートを備えた一つのソフトスイッチを見つける為に、各々の起点ソフトスイッチは、平均１５の別個のソフトスイッチを試みなければならない。純粋なランダム分散が実装されれば、この探索努力は大幅に縮小されるが、いくつかのルートが、コストまたは質の問題で、他のものよりも優先的に扱われ、そのために、その問題を悪化させることも考えられる。
【００２３】
例えば、ＣＩＳＣＯ  ＡＳ５３００のように、単純なゲートウェイの場合、ＳＩＰベースの呼び出し要求を、ＳＩＰプロキシサーバに転送できる。残念ながら、これらのゲートウェイは、密度が低く、ルーティングポリシーをセットアップする場合には、しばしば、機能性に劣る。したがって、これらのルータは、ソフトスイッチコントローラーがなくては、ネットワークを形成する為に相互に連結することができない。
【００２４】
階層型ルーティングでは、ネットワークが異なるレイヤーへ分けられている。これらのレイヤーは、任意の場所へのルーティングを可能とするピラミッド型へ、相互接続されている。この方法は現在のＰＳＴＮの基礎である。階層型ルーティング方法は、階層モデルを使用しており、そこでは、階層中の層の数は、ネットワークのサイズに依存する。今日のインターネットは、このような階層モデルには、なじまない。実際、ある場所から別の場所へ行く、多くの可能なルートと共に、インターネットの多くをフルメッシュと見做すことができる。ＢＧＰの主要な設計ゴールのうちの１つは、どれくらい多くの異なる相互連結が存在するかを示している複数の遠回りのルートを回避することである。
【００２５】
ＰＳＴＮにおいて、ネットワークへの階層的アプローチは、ローカル、国内長距離および国際的電話のネットワークに基づく標準としてふさわしく、ビジネスおよび政治的境界は、この階層的モデルを支援している。標準のＨ．３２３プロトコルベースの、ボイスオーバインターネットプロトコル（ＶｏＩＰ）の初期の実装は、全体の配備にあたって、階層的モデルの方へ傾いていた、
残念ながら、今日のピア環境にそれを適用しようとする場合、階層的モデルは複雑になる。ビジネスか政治的な状況から、階層のより高いレベルが、あるエンティティによって所有され、データネットワークが階層を厳守しない場合、どのように所有権およびピアの問題を解決することができるかを想像することは困難である。データネットワーク所有者が同じビジネスで競争しているので、ピアを行う準備（それらは互いに有益ではない）を確立することはありそうもない。階層的モデルは、さらにより大きな波及効果に結びつく、シングルポイント障害を生み出す。パブリックデータネットワークＰＤＮは、シングルポイント障害なしで発展しており、分散ピア配置に多くの出資を行っている。これを考慮すると、シングルソフトスイッチは、ネットワークの大きな部分に影響を与える可能性があり、賢明でない。
【００２６】
階層的モデルは、階層のすべてのポイントで、ルートコンフィギュレーションを注意深く使用する。即ち、どの２つのソフトスイッチも、同じコンフィギュレーションを持つことができず、どの２つのソフトスイッチも、特定の通信が通過するルートを予測することができない。したがって、階層型ルーティングシステムは、信じられないほどに統合された方法で、分散ルート計画を使用する。最後に、階層的モデルは、「ｅｎｄ−ｔｏ−ｅｎｄ」の適切なルーティングを保証するように、ベンダーが、同様のシグナリングシステムに従うようにする。例えば、適切なルーティングを可能にする為に、各ソフトスイッチは、回路利用可能性に関する情報を共有し、保証するべきネットワークが一杯になっても、適切な迂回機能を保証しなければならない。現在、これを遂行する為の基準がないので、ベンダーは独自の方法を構築している。これらの独自の方法では、正しい相互運用が可能とは限らない。
【発明の開示】
【発明を解決するための手段】
【００２７】
（発明の要約）
上記の通り、本発明の好ましい実施形態は、一般に、複数のネットワークを通るリアルタイムトランスポートプロトコルフローの制御を支援する為に、受信ルート情報をスクリーニングを行うシステムと方法に関する。
【００２８】
一般に、このシステムは、スクリーニングを行うシステムの構造に関し、送受信機と、このシステムによって実行される機能を定義するロジックが格納されたメモリ、およびプロセッサを利用する。プロセッサは、メモリにより、次の機能を実行できる。即ち、送受信機が受信したルート情報が、外部からのものか、内部からのものかを決定する機能と、もし、ルート情報が外部からのものであれば、ルート情報の第１の内部スクリーンを適用し、受信ルート情報により定義されている終点アドレスを、第１の内部スクリーンにより定義されているローカル終点アドレスと比較する機能と、もし、ルート情報が内部からのものであれば、ルート情報の第２の内部スクリーンを適用し、受信ルート情報により定義されている起点アドレスを、第２の内部スクリーンにより定義されているローカルの起点アドレスと比較する機能である。
【００２９】
一方、本発明は、複数のネットワークを通るリアルタイムトランスポートプロトコルフローの制御を支援する為に、受信ルート情報をスクリーニングを行う方法としてみることもできる。この点から、この方法は、次のステップによって要約できる。即ち、第一のエンドポイントから第２のエンドポイントへのルートを記述するルーティング情報を受け取るステップと、ルート情報が、外部から受け取ったものか、内部から受け取ったものかを決定するステップと、もし、ルート情報が外部からのものであれば、ルート情報の第１の内部スクリーンを適用し、受信ルート情報により定義されている終点アドレスを、第１の内部スクリーンにより定義されているローカル終点アドレスと比較するステップと、もし、ルート情報が内部からのものであれば、ルート情報の第２の内部スクリーンを適用し、受信ルート情報により定義されている起点アドレスを、第２の内部スクリーンにより定義されているローカルの起点アドレスと比較されるステップである。
【００３０】
本発明の他のシステムおよび方法は、次の図面および詳細な記述を読めば、当業者にとって明白である。そのような更なるシステム、方法、特徴、利点のすべては、この記載および本発明の範囲に含まれ、かつ添付のクレームによって保護されるべきである。
【００３１】
（好適な実施形態の詳細な説明）
本発明によって、複数のネットワークを流れるリアルタイムトランスポートプロトコルを制御するのを支援する制御システムが提供される。本発明の制御システムは、ソフトウェア、ファームウェア、ハードウェア、あるいはそれらの組み合わせとして実装することができる。本発明の好ましい実施形態において、制御システムの一部は、例えば、パソコン、ワークステーション、ミニコンピュータあるいはメインフレームコンピュータ等で実行されるソフトウェアによって、実装することができる。しかし、この実施形態に限定されるものではない。
【００３２】
制御システムの、ロジック機能を実装する実行可能な命令の列であるソフトウェア部分は、コンピュータベースのシステムプロセッサを含むシステム等の命令実行システム、装置、または機器や、あるいは、命令実行システム、装置、または機器からの命令を取り込み、命令を実行できる他のシステムによって、使用されるか、またはこれらと共に使用される任意のコンピュータ読み取り可能な記録媒体にて実現することができる。本明細書では、「コンピュータ読み取り可能な記録媒体」とは、命令実行システム、装置、または機器によって使用されるか、またはこれらと共に使用されるプログラムを含有、格納、伝達、伝播、または伝送することのできる任意の手段とする。コンピュータ読み取り可能な記録媒体とは、例えば、電子、磁気、光、電磁気、赤外線、または半導体のシステム、機器、または装置、或いは、伝播媒体である。もちろん、これに限定はされない。コンピュータ読み取り可能な記録媒体のより具体的な例（ただし、完全に列挙していない）としては、１本以上のワイヤを有する電気接続機器（電子）、携帯可能なコンピュータディスク（磁気）、ランダムアクセスメモリ（ＲＡＭ）（磁気）、リードオンリメモリ（ＲＯＭ）（磁気）、消去可能プログラム可能リードオンリメモリ（ＥＰＲＯＭまたはフラッシュメモリ）（磁気）、光ファイバ（光）、および携帯可能なコンパクトディスクリードオンリメモリ（ＣＤ ＲＯＭ）（光）が挙げられる。ただし、コンピュータ読み取り可能な記録媒体はプログラムが印刷された紙や他の適当な媒体でもよく、プログラムは、例えば紙や他の媒体のオプティカルスキャニングによって電子的に取込まれ、その後コンパイルされ、解釈されるかまたは適当な方法で処理され、その後、必要であればコンピュータのメモリに格納される。
【００３３】
図１は、発明の好ましい実施形態による複数のドメインを含む通信ネットワーク１００を示すブロックダイヤグラムである。基本的に、図１はボイスオーバインターネットプロトコル（ＶｏＩＰ）の実装で用いられるインターネットワーキングの典型的な例の多くを代表するものである。第１のおよび第２の自律システム（ＡＳ）１０２、１０４は、第１のセッションルータ１２２によって、互いに接続されている。この分野で良く知られているように、１つの自律システム（ＡＳ）は、１つの技術的な管理下におけるルータの集まりであり、パケットルーティングの為に、ＡＳ内で共通の重み付けの基準を持つインターリオールゲートウェイプロトコルを用いるとともに、他のＡＳへのパケットルーティングに外部ゲートウェイプロトコルを使用する。典型的には、ＡＳは共通の管理権限によってグループ化されたボーダーゲートウェイプロトコル−４（ＢＧＰ−４）ルータの集まりである。しかし、ＡＳは、インターネット電話管理ドメイン（ＩＴＡＤ）となり得る。ＩＴＡＤはＢＧＰ−４のＡＳに似ているが、それらはセッションルーティングのための共通の管理エンティティを共有する、テレフォニールーティングインターネットプロトコル（ＴＲＩＰ）ルータ（以下に詳細を記述）上のグループを示すために使用される。以下、ＡＳ１０２および１０４ではなく、それぞれＩＴＡＤ１０２および１０４として参照するが、ＩＴＡＤへの参照は、ＡＳで交換可能であることに理解すべきである。
【００３４】
第１の管理ステーション１１２は第１のＩＴＡＤ１０２の内に設けられている。また、第２の管理ステーション１１４は第２のＩＴＡＤ１０４の内に設けられている。管理ステーション１１２、１１４は準備機能、モニタリング、およびそれぞれのＩＴＡＤ１０２、１０４の内のセッションルータの診断機能を示す。好ましくは、管理ステーション１１２、１１４はＪＡＶＡ仮想マシンを実行し、セッションルータからＪＡＶＡアプリケーションを受け取る。Ｊａｖａアプリケーションは、リクエストおよび処理レスポンスをＸＭＬフォーマットの形式にして、通信を行う。
【００３５】
ＩＰキャリア（通信会社）１４２は第２のセッションルータ１２４によって第１のＩＴＡＤ１０２に接続されている。ＩＰキャリア１４２は、第３のセッションルータ１２６によって第２のＩＴＡＤ１０４にも接続される。第１のセッションルータ１２２によって、第１のＩＴＡＤ１０２と第２のＩＴＡＤ１０４とが互いにピアの関係となっていることを理解すべきである。さらに、第２のセッションルータ１２４は、第１のＩＴＡＤ１０２とＩＰキャリア１４２の間のピアの関係を示す。また、第３のセッションルータ１２６は、第２のＩＴＡＤ１０４とＩＰキャリア１４２の間のピアの関係を示す。
【００３６】
第１の長距離キャリア１５２は第１のゲートウェイ１７２経由で第１のＩＴＡＤ１０２に接続されている。好ましくは、ここでの長距離キャリアはＰＳＴＮシステムを用いており、そこではアナログで音声データを運ぶ銅線によって電話システムが構築されている。別の実装では、長距離キャリアは、ディジタルデータあるいはアナログおよびディジタルデータの組み合わせを扱ってもよい。さらに、好ましくは、ここでのゲートウェイは、ＰＳＴＮベースのネットワークとパケットベースのデータネットワークの間のメディアゲートウェイとシグナリングゲートウェイの両方をサポートする。第１の既存地域キャリア１６２も第２のゲートウェイ１７４経由で第１のＩＴＡＤ１０２に接続されている。第１のＩＴＡＤ１０２の内にある第１のソフトスイッチ（コールエージェント）２０２は、第１と第２のゲートウェイ１７２、１７４経由で、第１の長距離キャリア１５２および第１の既存地域キャリア１６２の両方にそれぞれ接続される。ここでのソフトスイッチは、メディアゲートウェイコミュニケーションプロトコル（ＭＧＣＰ）あるいは同等のプロトコルによって、ゲートウェイの制御を行う。別の実装では、インテリジェントゲートウェイは、ソフトスイッチを必要としないこともある、その場合、ソフトスイッチを使わない電話呼び出しに基づくセッション開始プロトコル（ＳＩＰ）により、ＩＴＡＤと直接通信することになる。
【００３７】
ＳＩＰは多くのキーメカニズムを定義するプロトコルである。第１のＳＩＰメカニズムは「登録」メッセージと呼ばれる。ＳＩＰプロキシサーバに送られた時、このメッセージは、エンドポイントが特定のユーザーのために通信を受けることができることを示す。この「登録」メッセージは、物理的なＩＰアドレスを、そのＩＰアドレスを使用するユーザーにバインドする。第２のＳＩＰメカニズムは「招待（ＩＮＶＩＴＥ：インバイト）」メッセージである。このメッセージは通信セッションを要求するルータにもう一方のエンドポイントに送られる。「招待」メッセージは、着信側のエンドポイントまで送られる。その後、「招待」の着信側は、通信が受理されたことを示す「ＯＫ」メッセージで応答する。エンドポイントが少なくない場合や、あるいはある特徴を必要とするエンドポイントがある場合、ＳＩＰプロキシサーバは仲介役として機能する。ＳＩＰプロキシサーバは、前もって「登録」メッセージを送信したユーザーのために、「招待」メッセージを受け取り、これを転送する。
【００３８】
図２は、ＳＩＰプロキシを介して行われる２つのＳＩＰエージェント間の対話を示す詳細図である。例えば、ユーザーが第１のＳＩＰユーザーエージェント２４４から「登録」メッセージ２４２を送れば、ＳＩＰプロキシサーバ２４６はその「登録」を受理する。そして、第２のＳＩＰユーザーエージェント２４８が、「登録」メッセージ２４２を送信したユーザーのために、第一の「招待」メッセージ２５２を送れば、この第一の「招待」メッセージ２５２は、ＳＩＰプロキシサーバ２４６によって受理される。その後、ＳＩＰプロキシサーバ２４６は第１のＳＩＰユーザーエージェント２４４へ第２の「招待」メッセージ２５４を転送する。第１のＳＩＰユーザーエージェント２４４が第２のＳＩＰユーザーエージェント２４８からコミュニケーションを受理する意志があれば、第１のＳＩＰユーザーエージェント２４４は、ＳＩＰプロキシサーバ２４６に、承認のメッセージを送信し、その後、ＳＩＰプロキシサーバ２４６は、その承認のメッセージを第２のＳＩＰユーザーエージェント２４８に送信する。
【００３９】
第３のＳＩＰメカニズムは「バイ（ＢＹＥ）」メッセージであり、それは一方的にコミュニケーションセッションを送り、使用中のネットワークリソースをすべて解放するものである。コミュニケーションのいずれの側も、いつでも「ＢＹＥ」メッセージを送ることができる。ＳＩＰアーキテクチャーで実装されたものは、ユーザーがそこで任意のＩＰアドレスあるいは位置から彼のホームＳＩＰプロキシサーバにユーザーが「登録」メッセージを送ることができ、通信を受け始めることができるという、可動性を備えているということである。ＳＩＰの詳細な記述は、ＨＡＮＤＬＥＹらによって「ＳＩＰ：セッション開始プロトコル」として提供されている。これは、１９９９年３月の日付でドラフト番号ｒｆｃ２５４３を持つインターネットのドラフトであり、その内容をこの出願の一部とする。以下に、このＳＩＰプロトコルを、更に論じることとする。
【００４０】
図１に戻って、エンタープライズネットワーク１９２は第４のセッションルータ１２８によって第１のＩＴＡＤに接続されている。エンタープライズネットワーク１９２は、第１の構内交換機（ＰＢＸ）２１２に接続する第３のゲートウェイ１７６を含んでいる。当業者に知られているように、ＰＢＸのユーザーは、ＰＢＸの外部との電話の呼び出しを行うための幾つかの外線を共有している。例えば、エンタープライズネットワーク１９２は、第４のセッションルータ１２８によって第１のＩＴＡＤに接続されており、マサチューセッツ州のＰＩＮＧＴＥＬ社で製造されているようなＳＩＰ電話２２２、およびニュージャージー州のＤＹＮＡＭＩＣＳＯＦＴ社で製造されているようなＳＩＰユーザーエージェント２３２（つまり、コンピュータ）を含んでいる。
【００４１】
第２の長距離キャリア１５４は第４のゲートウェイ１７８経由で第２のＩＴＡＤ１０４に接続されている。さらに、第２の既存地域キャリア１６４は第５のゲートウェイ１８２経由で第２のＩＴＡＤ１０４に接続されている。又、第２のソフトスイッチ（或いはコールエージェント）２０４が、第２のＩＴＡＤ１０４の内に設けられており、第４と第５のゲートウェイ１７８、１８２を介して、第２の長距離キャリア１５４および第２の既存地域キャリア１６４の両方にそれぞれ接続されている。第１のＩＴＡＤ１０２との関連で説明したように、インテリジェントゲートウェイは、ソフトスイッチを必要としないこともある、その場合、ソフトスイッチを使わないＳＩＰベースの電話呼び出しを生成することによって、ＩＴＡＤと直接通信することになる。
【００４２】
第２のＰＢＸ２１４は第６のゲートウェイ１８４経由で第２のＩＴＡＤ１０４に接続されている。さらに、例えば、第２のＳＩＰユーザーエージェント２３４および第２のＳＩＰ電話２２４は、第２のＩＴＡＤ１０４に接続されている。セッションルータ、ＩＰキャリア、長距離キャリア、既存地域キャリア、エンタープライズネットワーク、ＰＢＸ、ＳＩＰ電話、ＳＩＰユーザーエージェント、ＩＴＡＤ、管理ステーションおよびゲートウェイは、数においても、又、図１との関係においても、特に限定されない。そして、上述の装置は、それぞれ幾つ設けてもかまわない。実際、装置の幾つかは省略されていると考えられる場合も有り、その場合でも、やはりマルチドメイン通信ネットワークのカテゴリーに含まれる。
【００４３】
各セッションルータ１２２、１２４、１２６および１２８は、いくつかのプロトコルを利用する。これらのプロトコルには、ＳＩＰ（上述の通りであるが、後に更に論じる）、セッション記述プロトコル（ＳＤＰ）、ユーザー／ユニバーサルデータグラムプロトコル（ＵＤＰ）およびインターネットプロトコル上の電話ルーティング（ＴＲＩＰ）が含まれているが、もちろん、これに限定はされない。ＳＤＰは、エンドポイントで用いられるセッションエンドポイントおよびリソースについて記述する。したがって、ＳＤＰは、オープンな方法で、メディアエンドポイントと対話する為の柔軟性のある方法となっている。ＵＤＰは、ＳＩＰユーザーエージェントおよびＳＩＰプロキシサーバを含む１つのシグナリングポイントから、別のシグナリングポイントまでＳＩＰメッセージを送信する為に使用されるプロトコルである。
【００４４】
現在、ＴＲＩＰはインターネットドラフトフォームに含まれている。ＴＲＩＰの提案は、ポリシーに基づいて、ドメインを超えて到達可能な電話先に関する情報を共有する為に、ＢＧＰ−４に似たプロトコルを使用することである。更に、その提案では、ドメイン内のルーティング情報を共有する内部システムについて記述されている。ＢＧＰ−４のように、このプロトコルは、接続されているエンティティ間でルートの集成および伝達（注流：フラッディング）をサポートする。これらの特徴は、電話番号ルーティングのためのスケーラブルなソルーションを示す。ＴＲＩＰは、ＩＰネットワーク上の電話で呼び出しを行った側が、ＰＳＴＮへのゲートウェイを見いだせるように設計された。加えて、このプロトコルは、特定のポリシーに基づいて、呼び出しをデータネットワークへ入れ、そして、最適の出口のゲートウェイ見いだすことをサポートする。
【００４５】
ＴＲＩＰは、以下のように、簡潔に記述することができる幾つかの属性を備えている。ＴＲＩＰの第１の属性はルート広告である。サポートされたルートが、各ＴＲＩＰサーバに提供され。そこでは、サポートされたルートは、ＴＲＩＰの「更新された（ｕｐｄａｔｅ）」メッセージの一部として、各隣接したサーバに広告される。ＴＲＩＰの第２の属性はルート集成である。特に、異なるネットワークから、これらのルートが隣接するネットワークに広告される場合、入力ルートの集りは、隣への情報の転送を簡単にする為に集成される。ＴＲＩＰの第３の属性は境界でのポリシーである。各ルータは、広告されたルートのプログラム可能なセットを持つことができ、各境界ルータは、受け取ったルートを受理するか否かをプログラムできるので、完全なポリシー管理システムが実現する。
【００４６】
現在のところ、残念ながら、ＴＲＩＰは次のものをサポートしない。即ち、発着ペア（つまり発信側と受信側）によるルーティング、要求側のキャリアによるルーティング、時間や曜日によるルーティング、ドメイン記述（つまり、ドットで区分された記述））を用いて逆にＤＮＳ／ＥＮＵＭ着信側へ解決すること（ここで、ＥＮＵＭはＥ．１６４番号（国際電話番号割り当て計画））、そして、現在のエンドポイントのキャパシティーベースのルーティングである。さらに、ＴＲＩＰは、ある位置から別の位置へのＳＩＰメッセージを送る為に、どのようにＴＲＩＰ情報を使用すべきかに関しては規定していない。したがって、ＴＲＩＰによって送受信された情報を使用するシステムのインプリメンテーションは、公開されない。
【００４７】
発明の好ましい実施形態によるＴＲＩＰの使用は、これらＴＲＩＰの問題点を解決するものである。実際、発明の好ましい実施例では、Ｅ．１６４スタイルの番号割り当て、インターネットスタイルのエンドポイントアドレス（ＵＲＩ）、および従来の電話アドレス（ＳＩＰおよび非ＳＩＰ）を含む範囲の、ネットワークルートの利用可能性を広告する。以下に言及されるように、エンドポイントへの最適のルートは、コスト、時刻およびサービスの質に基づいて選択されている。さらに、発着ペア（つまり発信側と受信側）によるルーティング、要求側のキャリアによるルーティングが提供される。さらに、発明の好ましい実施形態によれば、ポリシーが広告されるか否かに関して、将来の日付をセットできる。
【００４８】
セッションルータが、ＳＩＰ招待を正確な位置へ送る為に、電話ルーティング情報ベース（ＴＲＩＢ）が、各フォワーディングポイントで、あるいは発明の好ましい実施形態によれば各セッションルータで構築される。このＴＲＩＢは、ＳＩＰ招待を受け取った際に処理する一組のポリシーを含み、これにより、可能な適用規則の一組が選択される。発明の好ましい実施形態によれば、１つのポリシーは、１つ以上の着信側アドレス、共通の次の転送先および１つ以上のキャリアを共有する１つ以上の起点アドレスを含んでいる。
【００４９】
ＴＲＩＢを計算する為に、ローカルポリシーを定義し確立する必要がある。図３Ａおよび３Ｂは、発明の好ましい実施形態によるセッションルータ上に格納されたポリシーを示すデータマップを示す。図３Ａおよび３Ｂによって示されているように、ポリシーは次のデータオブジェクトを含んでいる。即ち、キャリア３０２、管理アカウント３３２、隣接したルータ３４２、セッションルータ３６２、ＳＩＰエージェント４０２、ＳＩＰエージェントグループ４３２、そしてローカルポリシー４６２である。
【００５０】
キャリアデータオブジェクト３０２は、上流と下流のネットワークの関係を構成し管理する為に使用され、コンフィギュレーションの行われた１つのエンティティである。各キャリアは、他のデータオブジェクトで参照される名前３０４が与えられている。例えば、参照線３０１、３０３は、キャリア名３０４が、ローカルポリシー４６２の定義の中で、どのように使用されるかを示す。キャリア記述３０６は、キャリアに関するユーザー数やその他の記述を含む情報のために使用される。有効／無効フラグ（ＥＮＡＢＬＥＤ／ＤＩＳＡＢＬＥＤ）３０８は、キャリアおよび一カ所におかれた関連する全ポリシー属性４８６の有効／無効を設定する為に使用される。この機能はキャリア間の契約を管理するのに役立つ。キャリアインジケータコード（ＣＩＣ）（ＰＳＴＮ）３１２では、利用されている番号割り当て計画で、キャリアを識別する為にＰＳＴＮによって使用されるユニークな一連の数字が定義される。例えば、北アメリカでは、ＣＩＣは、ＮＡＮＰによって決定され割り付けられている（例えば、ＡＴ＆Ｔ社は、１０１０２８８のＣＩＣを備えている）。ＳＤＰ／ＦＩＲＥＷＡＬＬ／ＭＰＬＳフィールド３１４は、ＳＤＰフォーマット命令を含み、発信側や、各ネットワーク境界での使用される。
【００５１】
管理アカウントデータオブジェクト３３２は、ＳＲ（セッションルータ）を修正または形成しようとしているユーザーのために、その管理能力を定義する為に使用される。個々の管理ユーザーは異なるアクセス権３３４を持つことができる。発明の好ましい実施形態によれば、アクセス権３３４は、管理ステーション１１２、１１４（図１）を介してアドミニストレータがアクセスし自身を認証した時に決められ、後は、インターフェースとして参照される。発明の好ましい実施形態によれば、アドミニストレータは現在のルータを管理し維持する。ユーザーＩＤ３３６はアドミニストレータを認証する為にパスワード３３８と組み合わせて使用される。さらに、業界で知られているように、ＲＡＤＩＵＳ認証を使用することも可能である。参照線３０７は、セッションルータコンフィギュレーションの一部として含まれるアカウントのリストへの参照を示す。ここで、セッションルータは、セッションデータオブジェクト３６２によって識別される。又、各セッションデータオブジェクト３６２は、１つ以上の管理アカウント３３２を備えている。
【表１】
2005502219.tif 000003
【００５２】
隣接ルータデータオブジェクト３４２は、現在のＳＲに隣接しているＳＲについて記述する。このオブジェクトは、すべてのＳＲのＴＲＩＰピアについて記述する為に使用される。ここで、ピアは、内部ピア（つまり同じＩＴＡＤ１１２、１１４の内のピア）および外部ピアの両方を含んでいる。ドメインアドレスフィールド３４４は、ＴＲＩＰデータの交換のためにＴＣＰ／ＩＰ接続を確立する必要のあるアドレス（ドメイン名あるいはドットで区切られたＩＰアドレスのいずれか）を示す。ＴＲＩＰ識別子フィールド３４６も、隣接ルータデータオブジェクト３４２（それは同じＩＴＡＤ１１２、１１４の内でＳＲ番号がローカルに割り当てられている）内で使用される。どんな整数値もＴＲＩＰ識別子３４６として使用することができる。しかし、好ましくは、ＴＲＩＰ識別子３４６は４オクテットの符号なし整数値である。ＩＴＡＤ識別子３４８は、隣接ルータデータオブジェクト３４２内に設けられており、好ましくは、整数値である。
【００５３】
ＳＲデータオブジェクト３６２は、特定のＳＲ（すなわち現在のＳＲ）のためのコンフィギュレーションについて記述する。そこでは、各ＳＲは、１つのＳＲデータオブジェクト３６２のみを備えている。ドメインアドレスフィールド３６４は、現在のＳＲが動作しているアドレスを格納する。好ましくは、各ＳＲは、ドメインアドレス上のＴＲＩＰ接続をポート６０６９でリッスンする。さらに、ドメインアドレス３６４は、推奨されるＳＩＰポート、好ましくはポスト５０６０でＳＩＰメッセージを送受信する為に使用される。ＴＲＩＰ識別子３６６は、同一のＩＴＡＤ１１２、１１４の中ではユニークな現在のＳＲに割り当てられた整数値である。ＩＴＡＤ識別子３６８は、ＳＲデータオブジェクト３６２内に設けられ、識別目的の整数値を与える。名前（ＮＡＭＥ）フィールド３７２は、ＳＲデータオブジェクト３６２内に設けられており、現在のＳＲに与えられたテキスト名を含んでいる。管理ステーション１１２、１１４は、プレゼンテーションの目的に、テキスト名３７２を使用する。
【００５４】
記述フィールド３７４は、さらにＳＲについての記述を行うために使用され、ＳＲと関係する任意のテキストを含むことができる。位置フィールド３７６は、地理的（緯度と経度）なコンフィギュレーションを含み、管理ステーション１１２、１１４から、適切にＳＲの位置を特定する為に使用される。ＴＲＩＰバージョンフィールド３７８は、ＳＲでサポートされた現在のＴＲＩＰプロトコルバージョンである。ＳＩＰバージョンフィールド３８２では、ＳＲでサポートされた現在のＳＩＰバージョンが参照される。ルータバージョン３８４では、ＳＲを構築するサーバおよびクライアントのためにインストールされたソフトウェアバージョンが参照される。管理アカウントフィールド３８６は、参照線３０７によって示されているように、現在のＳＲにアクセスする、管理アカウントの配列を示す。参照線３０５によって示されているように、隣接ルータフィールド３８８は、現在のＳＲに対して隣接するルータ３４２の配列を示す。既知のＳＩＰエージェントフィールド（Known Sip Agents）３９２は、現在のＳＲに知られているＳＩＰエージェントの配列を示す。通信を行うどんなＳＩＰエージェントも、このリストに載っているべきである。なぜなら、このリストは、通信の為に設けられているからである。有効／無効フィールド３９４は、現在のＳＲが、例えば、ＳＩＰエージェント４０２を含むそのピアおよび隣接したルータ３８８と、アクティブで対話可能か否かを示すフラグを含んでいる。
【００５５】
ＳＲに設けられているＳＩＰエージェントデータオブジェクト４０２は、ＳＩＰ電話あるいはＳＩＰユーザーエージェントのような（これらに限定されない）特定のＳＩＰエンドポイントについて記述する。好ましくは、ＳＩＰエンドポイントはプロキシサーバである。プロキシサーバは、ステートフルであっても、ステートレスであってもかまわない。ステートフルの場合、プロキシは、出力リクエストを生成した入力リクエストと、その出力リクエストを保持する。ステートレスのプロキシは、一旦出力リクエストが生成されれば、情報をすべて忘れる。例えば、分岐するプロキシと、ＴＣＰ接続を受け入れるプロキシは、ステートフルであるべきである。ＳＩＰエンドポイントはさらにユーザーエージェントであることもある。ドメインアドレスフィールド４０４は、ＳＩＰエンドポイントのインターネットアドレスを示す。名前（ＮＡＭＥ）フィールド４０６は、ＳＩＰエンドポイントのテキスト名を提供し、管理目的のために使用される。ＳＩＰエージェントデータオブジェクト４０２内の記述フィールド４０８は、ＳＩＰエンドポイントに関する付加的なユーザー数に関する情報を示す。登録間隔フィールド４１２はＳＲで登録しているＳＩＰエージェントの予想される登録間隔を示す。この間隔を超過した場合、ＳＲは、ＳＩＰエンドポイントは使用停止しているとみなすことが好ましい。したがって、０でない登録間隔４１２が与えられた各ＳＩＰエージェント４０２では、トラヒックの為に、「登録」メッセージが、登録間隔フィールド４１２によって定義された間隔内に受理された場合に、エンドポイントは利用可能と見なされる。間隔が０にセットされたエンドポイントについては、登録が期待されないか要求されない。
【００５６】
キャリアフィールド４１４は、ＳＩＰエージェントデータオブジェクト４０２内に設けられている。ここで、参照線３０９によって示されているように、ＳＩＰエージェントデータオブジェクト４０２は、キャリア名３０４の配列を備えている。キャリア名のリストは、ＳＩＰエンドポイントからの境界内のトラヒックに関連する、１つ以上のキャリアの配置を示す為に利用してもよい。以下に示されているように、キャリア配置は、境界外のルートのキャリア属性と比較された時、ルーティングポリシーを得る為に使用することができる。キャリア配置は、境界内のセッションの為に、特定のＣＩＣ３１２をシードする為に使用することができる。でなければ、そのようなものは１つもない。境界内のセッションを正しくルーティングする為に、ＣＩＣを使用する場合、キャリアフィールド４１４によって定義された配列中の第１のキャリアはＣＩＣを示すために使用される。制約フィールド４１６は、現在のエージェントのための任意の既知の制約の定義を含んでいる。好ましくは、各エージェントには、少なくとも１つの制約が定義されている。以下のテーブル２は、制約の例を示す。もちろん、他の制約が考慮される場合もあり得る。
【表２】
2005502219.tif 000004
【００５７】
ＳＩＰエージェントグループ４３２のデータオブジェクトも、ＳＲ（それは１つ以上のＳＩＰエージェント４０２のコレクションを定義する）の内に設けられている。又、ＳＩＰエージェントグループ４３２のデータオブジェクトは、グループ名４３１および記述４３３によって識別されるＳＩＰエージェントの使用のストラテジーを、グループ化し特定する手段を示す。通信リクエストをルーティングさせる場合、ＳＩＰエージェントグループ４３２のデータオブジェクト内にあるストラテジーフィールド（ＳＴＲＡＴＥＧＹ）４３４は、ＳＩＰエージェント４０２の選択の方法を示す。ＳＩＰエージェントグループに複数のメンバがある場合、ストラテジーフィールドは適用可能である。以下に示されるテーブル３は、ルーティング先のＳＩＰエージェントを選ぶためのストラテジーの例を示す。
【表３】
2005502219.tif 000005
【００５８】
ＳＩＰエージェントグループ４３２のデータオブジェクトに戻って、エージェントフィールド４３６の数は、ＳＩＰエージェントグループのメンバの数を示す。必須ではないが、最小のフィールド値は好ましくは１である。最小のフィールド値が零（０）である場合、グループは、空で無意味であると考えられる。エージェントタイプフィールド４３８ａ、４３８ｂは、そのエージェントがＳＩＰエージェントあるいはＳＩＰエージェントグループのいずれであるかを指定する。エージェントタイプフィールドの可能な値は、グループまたはエージェントであることもある。ＳＩＰエージェントグループ４３２は、そのエージェントリスト内の別のエージェントグループを含むことができる。このグループのネスティングは、スケーラブルな配置を可能とする。そこでは、ＳＩＰエージェントがクラスタに分けることができ、又、クラスタは再度クラスタに分けることができる。以下同様である。ＳＩＰエージェントフィールド４３９ａ、４３９ｂは、参照線３１１で示されているように、別のＳＩＰエージェントグループあるいは実際のＳＩＰエージェントコンフィギュレーションへのポインターを示す。コンフィギュレーションの行われたＳＩＰエージェントへのアクセスする為のこの方法例は、柔軟なコンフィギュレーションを可能とする。一つのＳＩＰエージェントは、いくつかのＳＩＰエージェントグループの中に含まれことがあり、そして、このＳＩＰエージェントに変更（例えば、そのドメインアドレス４０４の変更）があれば、すべてのグループの参照は同時に更新される。このメカニズムは、省メモリで、重複が回避されるものである。
【００５９】
ローカルポリシーデータオブジェクト４６２は、現在のＳＲによって使用されるポリシーについて記述する。ポリシーは管理ステーション１１２、１１４を使って、追加、削除される。作成者フィールド４６４は、アドミニストレータの名前を含むか、そうでなければユーザーＩＤ３３６として参照される。アドミニストレータはシステムから削除され得るが、ポリシーのインスタンスは使用され続けるので、作成者フィールド４６４は、ポインターや参照ではない。追加日フィールド４６６は、ポリシーがＳＲに加えられた実際の日付を記述する。有効日付／時間フィールド４６８は、ピアと共有されるポリシーが有効となる正確な日付および時間を含んでいる。これは、現在有効でないポリシーの生成を可能とする。無効日付／時間フィールド４７２は、ネットワークからポリシーを取り下げたり削除する正確な日付および時間を示す。
【００６０】
発信アドレスフィールド４７４は、一様で一般的なリソース識別子（ＵＲＩ）のような、発信アドレスの一部を記述する。これは、ＴＲＩＰの場合、電話番号の一部である。その発信アドレス４７４は、任意の有効なネットワークアドレスでもよい。単なる電話番号でないポリシーを導入し、その実例を示すことによって、以下に記述されるように、本発明はＴＲＩＰの現在のバージョンに関する本質的な改良を行う。
【００６１】
発信アドレス４７４は、オプションの「アップデート」メッセージに関連した属性である。発信アドレス属性が、「アップデート」メッセージに含まれない場合、ポリシーは「任意の発信（ａｎｙ  ａｒｒｅｎｇｍｅｎｔ）」に利用される。しかし、発信アドレス属性が存在する場合、ポリシーやルートは、上に記述された部分的な一致が完全である時のみ、通信に用いられる。アドレス属性は、アドレスファミリーフィールド、アプリケーションプロトコルフィールド、長さフィールド、発信アドレスフィールドから構成される。アドレスファミリーフィールドは、発信アドレス属性に、アドレスのタイプを設ける。２つの標準のアドレスファミリーの例は、昔からの普通の電話サービス（ＰＯＴＳ）番号およびルーティング番号である。インターネットスタイルの発信アドレス（つまり起点アドレス）のサポートのために、（ＵＲＩとして参照される）ドメインアドレスの部分アドレス用に、アドレスファミリーコード２５４が追加されている。
【００６２】
好ましくは、部分ドメインアドレスはユーザー名を含んでいない（つまり、username@sr.acmepacket.comの形式ではない）。sr.acmepacket.comは有効なアドレスである。更に、好ましくは、アドレスは１９２．１６８．０．１のような生のＩＰアドレスを含んでいない。
【００６３】
アプリケーションプロトコルフィールドは、発信アドレス４７４を用いるプロトコルを示す。プロトコルの例としては、ＳＩＰやＨ．３２３−Ｈ．２２５．０−Ｑ．９３１がある。しかし、これらに制限されない、 この発明の好適な実施形態では、ＳＩＰベースのシグナリングシステムを取り上げているので、アプリケーションプロトコルはＳＩＰとしてある。長さフィールドは、好ましくはバイト単位で、発信アドレスフィールドの長さを示している。その、発信アドレスフィールドは、アップデートポリシーやルートが、完全な発信アドレス又はその一部として利用するアドレスを示している。
【００６４】
着信アドレスフィールド４７６は、特定のポリシーのための着信側を示す部分的なアドレスである。このアドレスも、電話番号あるいは他の有効なＵＲＩのいずれかでもかまわない。発信アドレス４７４と着信アドレス４７６の組み合わせは、有効なポリシーの選択のために使用される。好ましくは、ワイルドカードのようなエントリを利用する為に、発信アドレス４７４や着信アドレス４７６の空欄が、””、ＮＵＬＬ、”＊”あるいは空のフィールドを示す他の一般的なやり方で指定される。
【００６５】
ポリシーで、起点アドレスと終点アドレスとのマッチングを行う場合、最適と最長である一致が求められる。アドレスが電話番号である場合、数字は左から右に一致させる。又、セッションアドレスとポリシーでのアドレスは左側の数字が一致するべきである。一致した最多の数字を備えた電話アドレスは最長であり、最適である。又、もしアドレスがドメインアドレスであれば、ホスト名の中のワード全体（ドットによって区分された）は右から左に一致させる。
【００６６】
ローカルポリシーデータオブジェクト４６２内にあるＳＩＰエージェントグループフィールド４７８は、現在のポリシーのための次の転送先サーバであるＳＩＰエージェントについて記述する。ＳＩＰエージェントグループデータオブジェクト４３２で指定されるＳＩＰエージェントグループは、１つまたは複数のＳＩＰエージェント４０２を含んでいる。さらに、複数のＳＩＰエージェントがあれば、適切なエージェントを選ぶために上記のストラテジーが使用される。有効／無効フィールド４８２は、ポリシーが使用されるかどうか示す。もし、フィールド４８２が有効の場合、ポリシーは使用されるが、フィールド４８２が無効の場合、ポリシーは使用されない。
【００６７】
ポリシー属性フィールド４８４の数は、発信アドレス４７４、着信アドレス４７６、ＳＩＰエージェントグループ４７８、有効／無効フィールド４８２によって定義されるポリシー属性の数を示す。ポリシー属性は同等のポリシーを比較する為に使用される。各ポリシー属性４８６ａ、４８６ｂ（すなわち、第１のポリシー属性４８６ａからｎ番目のポリシー属性４８６ｂ）は、これらの同等のポリシーを比較する為に使用される情報を含んでいる。以下に説明するフィールドは第１のポリシー属性４８６ａからｎ番目のポリシー属性４８６ｂの各々の内に設けられている。
【００６８】
キャリアフィールド４８８ａ、４８８ｂは、ポリシーに含まれるべき所望された或いは要求されたキャリアの１つと一致するべきものである。キャリアフィールド（それはオプションである）は、ユーザーによるキャリアの選択に基づくルーティングポリシーを示す。キャリアフィールドは、広告されたパスの一部としてキャリアを指定する手段を提供する。到達可能なルートの生成者は、時間および曜日のパラメタによって利用可能なキャリアを示すことができる。さらに、各ルート生成者は、ルートに相対的なコスト属性を割り当てることができる。それは、低コストルートを選択することを可能とする。又、各ルート生成者は、さらにルートにＱＯＳ属性を割り当てることができる。それは、ルートに最適の品質を選択することを可能とする。単一のキャリア属性に複数のキャリアエントリを加えることができることを理解すべきである。しかし、「アップデート」メッセージにつき１つのキャリア属性だけが許されることが好ましい。追加のキャリアエントリは、前のキャリアエントリへ単に追加される。
【００６９】
各キャリアフィールド４８８ａ、４８８ｂは、以下のキャリア属性に関連していてもよい。即ち、キャリア長さ、キャリア、時刻長さ、時刻、曜日の長さ、曜日、コスト、ＱＯＳ待ち時間／ＱｏＳジッタしてＱＯＳエンコーディングスキームである。キャリア長さ属性は、好ましくはバイトで、キャリアエントリの長さを示す。キャリア属性は、キャリアについて記述するテキストエントリ（英数字）を含んでいる。キャリアの詳細のコンフィギュレーションは、管理ステーションインターフェースを使用して、ＳＲベースで、確立することができる。特に、ＳＲがＣＩＣを生成するかあるいはキャリアに関連した特定のＭＰＬＳを行う必要がある場合に、キャリアデータオブジェクト３０２（図３Ａおよび３Ｂ）が存在する。
【００７０】
時刻長さ属性４９２ａ、４９２ｂは、時刻属性の長さ（バイト）を含んでいる。時刻属性は２４時間表示時刻をコンマに区分した時間範囲のリストである。そのフォーマットは「００００−２４００」時間範囲を含んでおり、２４００が１日のエントリの終わりである。時間範囲はコンマによって区分され、境界を除いて、オーバーラップはしない。例えば、「００００−０７００，０７００−２４００」は、たとえ第１の範囲の０７００が第２の範囲の０７００とオーバーラップしても、有効なエントリである。しかしながら、一般に、これらの範囲はオーバーラップしない。又、範囲の数に制限はない。
【００７１】
曜日長さ属性４９４ａ、４９４ｂは、曜日属性の長さ（バイト）を含んでいる。曜日属性は、コンマに区分した週日範囲のリストを含んでいる。以下は、各曜日を指定する為に使用される文字の例である。即ち、Ｕは日曜、Ｍは月曜、Ｔは火曜、Ｗは水曜、Ｈは木曜、Ｆは金曜そしてＳは土曜である。曜日属性のエントリは、オーバーラップしない範囲を含んでいる。例えば、Ｕ−Ｓのエントリは、その週（週末を含んで）のすべて含んでいる。Ｍ−Ｆはすべての平日を示す。Ｍ、Ｈ、Ｓは月曜、木曜および土曜を示す。Ｕ−Ｗ、Ｆ−Ｓは、木曜日以外の、その週のすべてを示す。
【００７２】
コスト属性４９６ａ、４９６ｂは、好ましくは、３２ビットの整数値をコスト値として含んでいる。この値は実際の通貨値を反映する為に、システム全体で有効な除数を利用してもよい。ルートを広告する目的で、１つのユニバーサルな通貨を用いるが、小数点は使わない。ルートの生成者は任意のコストでルートを示すことができる、そこでは、より低いコストが、より望ましいルートである。ＱＯＳ属性４９８ａ、４９８ｂは、２つの部分、すなわち相対的なＱＯＳインジケータ、利用可能な圧縮のインジケータを含んでいる。
【００７３】
ＱＯＳ待ち時間／ＱｏＳジッタ４９８ａ、４９８ｂは、このルートが広告される時の、利用可能な品質のレベルを含んでいる。このフィールドに対する値は、次のグループから選ばれる。即ち、１−最高の高品質（ＳＨＱ）（ジッタがほぼ０で１００ミリセカンドの以下の待ち時間）、２−高品質（ＨＱ）（ジッタが小さく、２００ミリセカンドの以下の待ち時間）、３−通常品質（ＮＱ）（時々ジッタ有り、３００ミリセカンドの以下の待ち時間）、４−低品質（ＬＱ）（頻繁なジッタ、５００ミリセカンドの以下の待ち時間）、そして５−非常に低品質（ＶＬＱ）（頻繁なジッタ、１０００ミリセカンドの以下の待ち時間）のグループである。
【００７４】
ＱＯＳエンコーディングスキーム属性は、広告されたルート上の通信の推奨されたエンコーディングスキームを含む。好ましくは、広告されたポリシーより圧縮の低いレベルを要求するリクエストはルーティングさせない。例として、Ｇ．７１１が要求されるが、ルートはＧ．７２９のみをサポートする場合、セッションリクエストは別のルートを探す必要がある。
【００７５】
時刻４９２ａ、４９２ｂフィールドおよび曜日フィールド４９４ａ、４９４ｂ、キャリア／コストペアが有効か利用可能かどうかを確かめる為に使用される。時刻フィールド４９２ａ、４９２ｂは、好ましくは、２４時間表示時刻をコンマに区分した時間範囲のリストを備えたテキスト文字列を含んでいる。一日の終わりは２４００で示される。それは有効な時間でないが、一日の最後の秒を示す。例として、時刻エントリは「００００−０７００」、または「１７００−２４００」ということもある。曜日フィールド４９４ａ、４９４ｂは、週日のコンマに区分された範囲のリストを含んでいる。好ましくは、このフィールドでは、Ｕは日曜日を指定する。また、Ｈは木曜日を指定する。例として、週エントリの有効な日は、Ｕ（日曜を示す）、Ｔ−Ｈ（火曜日から木曜日を示す）、Ｓ（土曜を示す）等である。
【００７６】
コストフィールド４９６ａ、４９６ｂは、様々なポリシーの相対的なコストあるいは選択に関する表示を含む１０進の整数値である。サービスの質（ＱｏＳ）フィールド４９８ａ、４９８ｂは、ポリシー属性によって期待された最小のＱＯＳについて記述された情報を含んでいる。以下に示されるテーブル４は、ＱＯＳフィールド４９８ａ、４９８ｂ含まれている表示タイプの例を示す。
【表４】
2005502219.tif 000006
【００７７】
上記のテーブルは、すべてを網羅するものではなく、多くのタイプの品質が考慮可能である。ＳＩＰ「招待」メッセージが受け取られた時、以下に更に定義する「招待」メッセージのＳＤＰ部分が、メディアタイプおよび帯域幅インジケータの両方を示す。境界内のメディアタイプおよび帯域幅インジケータを調査し、特定のポリシーによって提示されたＱＯＳフィールド４９８ａおよび４９８ｂと比較することによって、ポリシーを現在のものに加えるべきか、低く不十分な品質により拒絶されるべきかどうかが決められる。最後に、有効／無効フィールド４９９ａ、４９９ｂは、特定のポリシー属性が有効又は無効になるようにセットする為に使用することができる。
【００７８】
成功したＳＩＰ招待は、２つのリクエスト、即ち「ＡＣＫ」が続く「招待」からなっている。その「招待」リクエストは、特定の会議に参加してくれるか、あるいは二者の会話を確立してくれるように着信側に依頼する。着信側が呼び出しに対して、参加することに合意した後、着信側は「ＡＣＫ」リクエストを送ることにより、それがそのレスポンスを受け取ったことを確認する。着信側が呼び出しに対して、参加したくなければ、「ＡＣＫ」の代わりに「ＢＹＥ」リクエストを送る。「招待」リクエストは、典型的には例えばセッション記述を含んでいる。それは、例えば、ＳＤＰフォーマットで書かれて、セッションに加わる為に十分な情報を、着信側に提供する。マルチキャストセッションのために、セッション記述では、そのセッションに配布可能なメディアタイプおよびフォーマットが列挙される。ユニキャストセッションのために、セッション記述では、着信側がメディアデータを送るのに利用したいメディアタイプおよびフォーマットが列挙される。いずれの場合も、着信側が呼び出しを受理したい場合、使用したいメディアのリストを含む同様の記述を返すことにより、「招待」に答える。マルチキャストセッションのために、着信側の記述で示されたメディアを受け取ることができないか、ユニキャストによってデータを受け取りたい場合には、着信側は単にセッション記述を返すべきである。
【００７９】
セッションルータ上に格納されたポリシー（図３Ａ）について記述したが、図４はセッションルータ装置の構造を示すブロックダイヤグラムである。セッションルータ１２２、１２４、１２６、１２８（図１）は、ＴＣＰ／ＩＰデータや他のデータの送受信の可能な、少なくとも１つのイーサネットインターフェース６０２あるいは他のパケットインターフェースを備えているコンピュータである。好ましくは、コンピュータは２つ以上のイーサネットインターフェースを含んでいる。コンピュータの１つの例は、ＩＵラックマウントユニット内に設けられたペンティアムＩＩＩベースのコンピュータシステムである。ニューヨーク州アーモンクのインターナショナルビジネスマシーンズコーポレーション（ＩＢＭ）、テキサス州ヒューストンのコンパックコンピュータコーポレーション、あるいは、ターンキー１Ｕコンピュータシステムの他のメーカーのＩＵユニットも、セッションルータ（ＳＲ）として利用するのに十分である。別の実施形態では、ＳＲは、メディア通信のために、追加の専用イーサネットサブシステムを持つことができるであろう。更に別の実施形態では、ＳＲは、例えばＶＸＷＯＲＫＳのような組み込みオペレーティングシステムを使用する高速２プロセッサからなる。
【００８０】
ここでは、ＳＲ１２２（図１）は、任意の関連データ、コンピュータオペレーティングシステム或いはＳＲソフトウェアの格納のために、ローカルの記憶装置６０４を含んでいる。ＳＲ１２２（図１）はさらにプロセッサ６０６を含んでいる。このプロセッサ６０６は、ローカルメモリ６０８に設けられているロジックを実行する。フラッシュメモリ装置６１２はコンフィギュレーションデータを格納する為に設けられ、バックアップや機能の回復に利用される。ハードディスクコントローラー６１５は、ローカルの記憶装置６０４およびフラッシュメモリ装置６１２と通信する為に、ＳＲ１２２（図１）に設けられている。フロッピーディスクドライブ６１４およびフロッピーディスクコントローラー６１６はＳＲ１２２（図１）の内にメンテナンス目的に設けられる。ビデオアダプター６１８もＳＲ１２２（図１）の内にローカルのメンテナンス目的に設けられる。ＳＲ１２２（図１）の内に他の構造の要素が提供され得ることは理解すべきである。そのような要素は、例えば、当業者に知られた計算上の要素、２次キャッシュ、数値のコプロセッサあるいはネットワークプロセサ等である。好ましくは、ローカルメモリ６０８、イーサネットインターフェース６０２、ハードディスクコントローラー６１２、フロッピーディスクコントローラー６１６、ビデオアダプター６１８およびプロセッサ６０６は、ＰＣＩバス６１３経由で、ＳＲ１２２（図１）の内で通信を行う。パワークイックプロセッサを使用した時のＰＯＷＥＲ  ＰＣバス等、別のバス構造を使用することもできる。
【００８１】
図５は、ＳＲのローカルメモリ６０８（図４）内に常駐するソフトウェアシステム、又はプロトコルを示すブロックダイヤグラムである。オペレーティングシステム６３２は、ＳＲの機能を制御する為に設けられている。任意のオペレーティングシステムを、ＳＲに利用することが可能である。メモリ６０８（図４）内のオペレーティングシステムとしてＬＩＮＵＸが好ましいが、ＬＹＮＸ、ＰＳＯＳ、ＳＯＬＡＲＩＳあるいはＶＸＷＯＲＫＳのようなリアルタイム組み込みオペレーティングシステム等の他のオペレーティングシステムを利用可能である。好ましくは、メモリ６０８（図４）に設けられているソフトウェアプロトコルは、ＩＰ６３５を利用する。
【００８２】
ＴＲＩＰ６３４の（ＴＲＩＰロケーションサーバによって実行される）処理は、ソケットベースの送信コントロールプロトコル（ＴＣＰ）６３６上で、ＳＲによって実行され得る。（ＳＩＰプロキシサーバによって実行される）ＳＩＰ６３８処理、ライトウェイトディレクトリーアクセスプロトコル（ＬＤＡＰ）６４２およびエクステンシブルマークアップランゲージ（ＸＭＬ）６４４は、好ましくは、ユーザー／ユニバーサルデータグラムプロトコル（ＵＤＰ）６４６を利用する。ＵＤＰはコネクションレスである。独自仕様のポリシーベースのルーティングアルゴリズムも利用可能である。それらは、ＴＲＩＰ６３４、ＳＩＰ６３８およびＬＤＡＰ６４２に基づき、同様に統計的技法を用いることが可能である。好ましくは、ポリシーを管理する為に、管理ステーション１１２、１１４（図１）はＵＤＰ６４６のデータグラムの中でＸＭＬ６４４を使用して、ＳＲ１２２（図１）と通信する。
【００８３】
図６は、稼働開始の際に、セッションルータによって実行される動作を示すフローチャートである。ここに記述されたすべてのフローチャートに関して、各ブロックは所定の論理的な機能を実装する為の１つ以上の実行可能な命令を含む、モジュール、セグメントあるいはコード部分を表す。いくつかのインプリメンテーションでは、ブロックに書かれた機能は、これとは異なる順序となり得ることを理解すべきである。例えば、連続して示された２つのブロックが実質的に同時に実行されることもある。あるいは、ブロックは、その機能によっては、逆の順に実行されることもあり得る。
【００８４】
ブロック６７２によって示されているように、ＳＲは、電源を入れた時に、オペレーティングシステム６３２（図５）を立ち上げる。好ましくは、オペレーティングシステムはＬＩＮＵＸであるが、ＬＹＮＸ、ＰＳＯＳ、ＳＯＬＡＲＩＳあるいはＶＸＷＯＲＫＳのような他のオペレーティングシステムも利用可能である。その後、ブロック６７４によって示されているように、ＳＲ稼働開始スクリプトは、オペレーティングシステムのブートアッププロセスの一部として実行される。診断モード（オペレーターが介在するまで処理を進めないモード）でＳＲを立ち上げることを可能にする為に、診断モードに対するテスト（ブロック６７６）が完了される。ＳＲが診断のモードでスタートしない場合、特定のデーモンやプロセスが実行するように設定されているかどうかを、系統的にチェックされる（ブロック６７８、６８２、６８４）。特に、システムロギングメカニズム（ブロック６８６）を開始した後に、ＳＲが、ＴＲＩＰ（ブロック６７８）、ＳＩＰ（ブロック６８２）およびＬＤＡＰ（ブロック６８４）を実行するかどうかを決定される。その後、ＳＲがデーモンを実行した時（ブロック６８８、６９２、６９４）、それぞれのデーモンがサービスを開始する。
【００８５】
稼働開始スクリプトがＴＲＩＰロケーションサーバ（ＬＳ）６３４の動作を開始する場合（ブロック６８８）、ＴＲＩＰ ＬＳ６３４はＳＲのためのルーティング情報を処理し出力する。ＴＲＩＰ ＬＳ ６３４の最初の処理の１つは、格納されたコンフィギュレーションから隣接したルータレコード３４２（図３Ａ）を読むことである。基本的に、ＴＲＩＰ ＬＳ ６３４は、他のＴＲＩＰ ＬＳから受け取ったルーティング情報に基づいて、エンドポイント照合リクエストに答える。夫々の隣接したルータレコード３４２（図３Ａ）については、それらが内部ルータであるか外部ルータかを確かめる検査がある。内部であれば、ＩＴＡＤ識別子３４８（図３Ａ）が、このＳＲのＩＴＡＤ識別子３６８と等しいことを示す。２つのＩＴＡＤ識別子が等しくない場合、隣接したルータは、外部のものとして分類される。
【００８６】
その後、ＴＲＩＰ ＬＳ ６３４は特定のＴＲＩＢを初期化し始める。ＴＲＩＢの各々は、頻繁に修正される一時データを含んでいる。動的な特性を持ったこれらのデータベースに格納するメカニズムは、メモリ内の２重にリンクしたリスト、ＩＳＡＭ（Indexed Sequential Access Method）によるデータベース、あるいは他の、高速アクセスを提供すると共に各挿入および削除に対応するメカニズムである。発明の好ましい実施形態によれば、標準のテンプレートライブラリーリストが使用される。ＴＲＩＢの初期化は、ライブラリーリストを使用する場合、空のリストの初期化を含んでいる。初期化が完了すると、１つのＴＲＩＢが外部の隣接したルータの夫々のために存在し、１つのＴＲＩＢが内部で隣接したルータの夫々ために存在し、１つの出力ＴＲＩＢが存在し、また、１つのローカルＴＲＩＢが存在する。それらのすべては空であり、新たなエントリの受け入れ準備ができている。
【００８７】
その後、一連の格納された（ローカル）ポリシーデータベースは個々のポリシーを保持しており、ポリシーデータベースは開かれる。このデータベースは、ＳＱＬ（Structured Query Language）によるデータベースサーバあるいはＩＳＡＭデータベースを含む固定記憶の任意の形式で構築される。そして、カード型（フラットファイル）、あるいはＸＭＬデータとして、それらを格納することができる。好ましい実施形態によれば、ＳＱＬサーバが使用される。一旦、クライアント（この場合、ＴＲＩＰ ＬＳ ６３４）が、ＳＱＬクライアントインターフェースを介して、ＳＱＬデータベースを開けば、ローカルポリシー４６２（図３Ａ）が一つずつ読まれる。まず、ポリシーがチェックされ、それらが現在アクティブかどうか確かめられる。このチェックは、ローカルポリシーデータオブジェクト４６２（図３Ａ）にある有効日付／時間フィールド４６８（図３Ａ）と現在の日付／時間を比較することで行われる。ポリシーでの有効日付／時間フィールド４６８（図３Ａ）が、現在の日付／時間未満である場合、ポリシーはアクティブであるとわかる。そうでなければ、ポリシーは将来の活性化の為に保留される。ポリシーがアクティブな場合、そのポリシーは処理に回される。ポリシーが将来の活性化の為に保留されている場合、タイマーが特定の日付／時間にポリシーを活性化する為にセットされる。一旦タイマーがセットされれば、プロセスは処理の残りをスキップし、直接、次のポリシーに進む。タイマーの時間がくると、ポリシーはその将来の時間に処理される。
【００８８】
好ましい実施形態で使用されルータイマーは、典型的なタイムアウトキューメカニズムである。データオブジェクトのアドレスは、一体になったタイムアウトリストに加えることができる。また、将来、タイマーの時間がくると、データオブジェクトが参照される。有効日付／時間４６８（図３Ａ）の値がゼロ（０）であれば、ポリシーが直ちにアクティブであることを示す。ローカルポリシーデータオブジェクト４６２の中の無効日付／時間フィールド４７２がゼロ（０）以外の場合、ポリシーの非活性化が、キューに入れられる。ポリシーが非活性化される場合、ＳＱＬデータベースによって管理され、格納されたローカルポリシーからそのポリシーが取り除かれ、有効になりえないポリシーが処理されないようにしている。無効日付／時間フィールド４７２（図３Ａ）値がゼロ（０）でなく、かつ無効日付／時間フィールド４７２（図３Ａ）の値が現在の日付／時間未満である場合、そのレコードは削除され、このレコードのための処理はスキップされる。無効日付／時間フィールド４７２が現在の日付／時間より大きな場合、タイマーはセットされ、後にこのポリシーを自動的に非活性化する。一旦、ポリシーの為にタイマーがセットされ、このポリシーが現在アクティブである場合、ポリシーはローカルＴＲＩＢに加えられる。その後、ポリシーは、それらが外部と共有されるかどうか決める為に、コンフィギュレーションと照合される。よりよくこのチェックを理解する為に、ＩＴＡＤベースのポリシーの詳細な記述を以下に設ける。
【００８９】
上に記述されているように、ＴＲＩＢは、ＴＲＩＰ ＬＳによって使用され、生のポリシー情報に対してどのような変更をおこなったかを、決定プロセスによって「思い出す」。下記は、発明の好ましい実施形態による、ＴＲＩＢおよびＴＲＩＰ決定プロセスの実行に関する情報を示す。好ましくは、各ＴＲＩＢは、下記の要素のすべて又は一部を含んでいる。
【表５】
2005502219.tif 000007
【００９０】
ＴＲＩＢ ＴＲＩＰ ＩＤリストリンク、同じ受信ポリシーリンク、集成クラス、活性期間開始および活性期間終了の各エントリは、特定の実行に依存することもあるし、依存しないこともある。
【００９１】
すべてのポリシーが、外部と共有されるとは限らない。ポリシーが外部と共有されることになっていても、ポリシースクリーンがチェックされ、ポリシーが外部と共有されることになっているか、外部のＩＴＡＤから受理されたかどうかに関して確認される。図７は、発明の好ましい実施形態によるポリシースクリーンを示すブロックダイヤグラムである。これらのポリシースクリーンもポリシー情報ベース（ＰＩＢ）と呼ばれる。これらのデータオブジェクトは、図３Ａおよび３Ｂの中でＳＲデータが用意されるのと同じ方法で用意される。しかしながら、これらのデータオブジェクトは、発信側か着信側のいずれかの境界外のＩＴＡＤのための、境界内又は境界外のデータポリシーをスクリーンする為に使用される。図３Ａおよび３Ｂに示されているような、ＳＲのコンフィギュレーションと同じ方法で、ＳＲの各クラスタのためにデータテーブルのコンフィギュレーションが行われる。
【００９２】
好ましくは、各ＩＴＡＤは、ＩＡＮＡ（Internet Assigned Numbers Authority）によって割り当てられる３２ビットの整数値によって定義される。各ＳＲ（クラスタ）は、境界外のＩＴＡＤから送受信され、広告されたルートの集合を管理する為に使用されるポリシースクリーンのコンフィギュレーションの行われたセットを備えている。図７を参照すれば、隣接ＩＴＡＤ７０２のデータオブジェクトは、隣接ルータ３４２（図３Ａ）のデータオブジェクトに含まれているＩＴＡＤ識別子３４８（図３Ａ）に類似した、外来ＩＴＡＤ識別子７０４を含んでいる。コンフィギュレーションの行われた隣接ＩＴＡＤ７０２のデータオブジェクトがない場合、ルートはＩＴＡＤの外部で広告されず、また、境界外のＩＴＡＤからの受信されたルートは使用されない。必要があれば、これはルーティングアルゴリズム上の高いセキュリティを提供する。個々の隣接したＩＴＡＤ７０２コンフィギュレーションについては、そのＩＴＡＤについて記述する名前フィールド７０６および記述フィールド７０８がある。これらのフィールドは記述的な目的だけのために使用され、アルゴリズムの結果に影響しない。
【００９３】
個々の隣接したＩＴＡＤ７０２は、ポインター７１２によって参照される境界内のポリシースクリーン７１４のデータオブジェクトの配列を備えている。この配列は、作成者フィールド７２４、追加日フィールド７２６、活性化日付／時間フィールド７２８、非活性化日付／時間フィールド７３２、許可／拒絶フィールド７３６、部分的着信アドレスフィールド７３６、そしてポリシー属性数フィールド７４２を含む、ポリシーと同じ属性のうちのいくつかを備えている。「アップデート」メッセージが境界外のＴＲＩＰサーバから受け取られると、着信アドレス７３６の一部と比較された到達可能なルートアドレス上の最長の一致は、次の状況のうちの１つに当てはまる。即ち、部分的な一致も見つけられないか、部分的な一致は見つけられたが許可／拒絶フィールド７３６は拒絶となっているか、あるいは、部分的な一致は見つけら許可／拒絶フィールド７３６は許可となっている、というものの１つに当てはまる。
【００９４】
この第１と第２の状況で、「アップデート」メッセージは廃棄され、変更はローカルのルーティングさせるデータベース（つまりＴＲＩＢ）に対して行なわれない。第３の状況では、広告されたルートは受理され、ＴＲＩＢデータベースに加えらる。部分的な一致が生じる場合、キャリア７５４、７６８、時刻７５６、７７２、曜日７５８、７７４、コスト７６２、７７６、およびＱＯＳ７６４、７７８を含む、すべてのデフォルト（ポリシー）属性７５２ａ、７５２ｂのセッティングは、ポリシー属性７６６、７８２が有効な場合、すべてルートの為のデフォルトとして扱われる。加えて、デフォルトの発信アドレスフィールド７３８は、デフォルト発信アドレス（例えばＵＲＩ）を割り当てる為に使用される。これは、すべてのルーティングの決定が完全に同等のルーティングデータを持ち得ることを保証することにより、機能強化なソースベースのルーティングを可能とする。この種類のルーティングポリシーの例の動作が、以下に示される。
【００９５】
発明の好ましい実施形態では、可能な２種類の部分的な一致が示される。部分的な一致の第１の種類では、ＴＲＩＰピアサーバから送られて受信した「アップデート」メッセージの中の広告された到達可能なルートアドレスは、部分的な着信アドレス７３６より長い。部分的な一致の第２の種類では、ＴＲＩＰピアサーバから送られて受信した「アップデート」メッセージの中の広告された到達可能なルートアドレスは、部分的な着信アドレス７３６より短い。部分的な一致の第２の種類によれば、ポリシーが境界外のＩＴＡＤから受け取ったポリシーより狭い（限定的な）状況が生じる。この場合、「アップデート」メッセージ中のより広い値の代わりに、（より狭い）部分アドレス７３６をルートポリシーとして用いることで、ポリシーがより狭くなる。
【００９６】
隣接したルータ３４２（図３Ａ）が、境界外のＩＴＡＤ識別子３４８（図３Ａ）（境界外のＩＴＡＤは、ＳＲのベースコンフィギュレーション３６２（図３Ｂ）の中で、ＩＴＡＤ識別子３６８（図３Ｂ）と等しくないＩＴＡＤである）と共に、ＳＲに設けられている場合、その境界外のＩＴＡＤにエクスポートされる広告を制御する為の特別な規則が存在する。これらの規則は、図７の境界外ポリシースクリーン８０２のデータオブジェクト内に定義されている。図３Ａおよび図３Ｂの中のＳＲデータと同じ方法で、このデータは、このＳＲの中で用意される。隣接ＩＴＡＤ７０２のデータオブジェクトは、ポインター８０４によって指されるＩＴＡＤ識別子７０４毎に、境界外のポリシースクリーン８０２のレコードの配列を備えている。この配列は、作成者フィールド８０６、追加日フィールド８０８、活性化日付／時間フィールド８１２、非活性化日付／時間フィールド８１４を含むポリシーと同じ属性のうちのいくつかを備えている。許可／拒絶パラメタ８１６は、ポリシーがピアに広告されることになっているかどうかを制御する為に使用される。
【００９７】
境界外のポリシースクリーン８０２を介して広告されるＴＲＩＢポリシーとの関係においても、３つの可能性が生じる。第１の可能性は、ＴＲＩＢ内の到達可能なルートと、スクリーンの着信アドレス８１８との、部分的な一致が存在しないというものである。第２の可能性は、ＴＲＩＢ内の到達可能なルートと、スクリーンの着信アドレス８１８との、最適（部分的）な一致が存在し、許可／拒絶フィールド８１６が拒絶にセットされているというものである。第３の可能性は、ＴＲＩＢ内の到達可能なルートと、スクリーンの着信アドレス８１８との、最適（部分的）な一致が存在し、許可／拒絶フィールド８１６が許可にセットされているというものである。ポリシー属性フィールド８１７の数も、境界内のポリシースクリーン７２２に含まれるポリシー属性フィールド７４２の数と同様の目的のために設けられている。
【００９８】
第１と第２のケースでは、ＴＲＩＢポリシーと関係する広告は、境界外のＩＴＡＤに対して行われない。しかしながら、第３のケースでは、２つの可能性がある。第１の可能性は、着信アドレスが、部分的な着信アドレス８１８より長い又は同じというものである。この状況で、境界外のＩＴＡＤへ広告されたポリシーは、集成された到達可能なルートを含んでいる。第２の可能性は、着信アドレスが、部分的なアドレス８１８より短いというものである。この状況で、境界外のＩＴＡＤへの広告されたポリシーは、より狭い（つまり、より限定的な）部分的な着信アドレス８１８を含んでいる。
【００９９】
境界外のポリシースクリーンのポリシーの（ＰＯＴＳあるいはルーティング番号アドレスのための）最適の一致というものは、ポリシーの到達可能なルート属性アドレスと境界外のポリシースクリーン８０２の属性とが、左からスタートして、最も連続して一致する文字を共有するようなものであることを理解すべきである。境界外のポリシースクリーン８０２の属性８１９、８２１は、キャリアフィールド８２２、８３６、時刻フィールド８２４、８３８、曜日フィールド８２６、８４２、コスト基準フィールド８２８、８４４、およびＱＯＳ基準フィールド８３２、８４６によって定義され、ルートの属性とのマッチングも行われている。ルートの各キャリアについては、境界外のスクリーン属性（つまりキャリア、時刻、曜日、コスト基準およびＱＯＳ基準）との一致があるべきである。一致が正確でない場合、境界外のスクリーンのより狭い（つまり、より限定的な）属性が適用される。例えば、与えられたキャリア用に、ルートとして、Ｍ−Ｆ、００００−２４００が定義され、境界外のスクリーンはＴ−Ｆ、０７００−１７００を定義するかもしれない。この場合、境界外のスクリーンによって定義された、より狭い属性が使用されるルートである。
【０１００】
属性が一致し、一致した属性の組み合わせについて、有効／無効フィールド８３４、８４８が有効にセットされており、外部のＩＴＡＤに広告されたポリシー属性が境界外のスクリーン中のものの一部であることが保証されるならば、そのルートは利用可能である。さらに、上記の通り、部分的な着信アドレス８１８自体は、外部に広告された到達可能なルート属性アドレスに影響を及ぼすこともある。この機能性は、境界外のスクリーンで特定される属性に基づいてルート広告を制御する、いくつかの発明性のあるオプションを提供する。
【０１０１】
個々の隣接した内部ルータについて、ＴＣＰ／ＩＰソケットが開かれ、また、隣接したルータは「オープン」メッセージを使用して、ネゴシエーションを開始する。固定サイズのＴＲＩＰヘッダーに加えて、「オープン」メッセージは次のフィールドを含んでいる。即ち、バージョン、ホールド時間、自身のＩＴＡＤ、ＴＲＩＰ識別子、オプションパラメタの長さ、またその他のオプションパラメタである。これらのフィールドの詳細な記述は、Ｒｏｓｅｎｂｅｒｇらによって、「ＩＰの上のテレフォニールーティング（ＴＲＩＰ）」の中で提供されており、そのセクション４．２は、ドラフト番号draft-ietf-iptel-trip-04.txtと２０００年１１月の日付を備え、インターネットドラフトの１つであり、その内容をこの出願の一部とする。
【０１０２】
この時点で、有効なコミュニケーションソケットが、同じＩＴＡＤの内の、すべての利用可能なローカルピア、あるいはセッションルータの間に存在する。有効な接続がなされた後、ポリシーの交換が行われる。そして、ポリシーは「アップデート」メッセージを使用して交換される。ＴＲＩＰヘッダーに加えて、「アップデート」メッセージは、ルーティング属性のリストを含んでいる。これらの属性は下記のものを含む。即ち、取り下げられたルート、到達可能なルート、次の転送先サーバ（ＳＩＰプロキシアドレス）、広告パス、ルートパス、要素の集成、ローカルの優先度、コミュニティー、多重出口弁別子、ＩＴＡＤトポロジーおよび認証である。発明の好ましい実施形態によれば、次の属性も、ルーティング属性の「アップデート」メッセージリストに含まれている。即ち、発信アドレス（ＵＲＩ）、キャリア、時刻、曜日、コスト、およびＱＯＳである。
【０１０３】
ポリシーコミュニケーションの主要な手段として、発信アドレス（ＵＲＩ）、キャリア、時刻、曜日、コスト、およびＱＯＳに加えて、取り下げられたルート、到達可能なルートおよび次の転送先サーバ（ＳＩＰプロキシアドレス）も利用される。どのようにＴＲＩＰ「アップデート」メッセージを処理することができるか、また、それがどのようにローカルポリシー４６２（図３Ａ）を生成することができるか、が以下に明確にされる。
【０１０４】
広告パス、ルートパス、要素の集成、ＩＴＡＤトポロジーおよび認証属性は、すべて「アップデート」メッセージの受理か拒絶を管理する為に使用される属性である。広告パスおよびルートパス属性は二重の広告および循環的な参照を検知する為に使用される。これはＢＧＰ−４の二重検知方法に似ている。要素集成の属性は、発信側によって受け取られた他の別々の広告から広告が再構成されたことを外部のＩＴＡＤに示す。発明の好ましい実施形態によれば、集成は、要素集成の属性によって提供される方法では実行されない。しかしながら、その属性が受け取られる場合、それは次のルータに渡される。「アップデート」メッセージに含まれたＩＴＡＤトポロジー属性は、同じＩＴＡＤの内のローカルサーバへの情報を注流させる為に使用される。送信側は認証を実行し、受信側は認証を理解する。そして、広告に対して変更されることなく受理されることが保証される。これらのパラメタのどれも、実際の格納されたポリシーには影響しない。
【０１０５】
発明の好ましい実施形態によれば、ローカルの優先度、コミュニティーおよび多重出口弁別子属性は、ポリシー管理のいくつかの方法を示すためにＴＲＩＰによって使用されるが、現在のネットワーク１００（図１）によって計画されるルーティングの種類には適していない。さらに、これらのパラメタは、ＩＴＡＤ境界を超えて一般に共有されない。
【０１０６】
ルーティングさせる属性の詳細な記述は、Ｒｏｓｅｎｂｅｒｇらによって、「ＩＰ（ＴＲＩＰ）の上のテレフォニールーティング」の中で提供されており、そのセクション４．３は、ドラフト番号draft-ietf-iptel-trip-04.txtと２０００年１１月の日付を備え、インターネットドラフトの１つであり、その内容をこの出願の一部とする。交換されるＴＲＩＢの例が、以下に示される。上に記述された、現在のＩＴＡＤベースのスクリーンメカニズムは、ポリシーが共有されることになっているかどうかを決める為に使用される。ＴＣＰ／ＩＰによる有効な通信セッションを得て、「アップデート」メッセージによってポリシーを交換する上記のプロセスは、隣接した外部ルータで繰り返される。
【０１０７】
そして、ＴＲＩＢはすべて初期化され実装される。その後、ＴＲＩＰサーバは受信ルートを処理し、ＳＩＰプロキシサーバの、セッションリクエストをルーティングに使用するローカルＴＲＩＢを計算する。さらに、外部ＴＲＩＢが、個々の境界外のＩＴＡＤピアのために作成される。
【０１０８】
図８は、ＴＲＩＰ決定プロセスによって定義されたロジックを示すブロックダイヤグラムである。図８によって示されているように、楕円枠８５２、８５４、８５６、８５８、８６２および８６４は、様々なＴＲＩＢを表わす。また、ブロック８７２、８７４、８７６および８７８は、ＴＲＩＰによって定義された決定プロセスの様々な段階を表わす。楕円枠８５２は、ローカルポリシーであり、ローカルのＳＲで定義されたルートのセットを表わす。楕円枠８５６は、Ａｄｊ−ＴＲＩＢ−Ｉｎ（外部）であり、外部のＴＲＩＰピアから受け取ったルート広告のセットを表わす。好ましくは、各外部ピアに１つのＡｄｊ−ＴＲＩＢ−Ｉｎ（外部）８５６がある。
【０１０９】
楕円枠８５８は、Ａｄｊ−ＴＲＩＢ−Ｉｎ（内部）であり、内部ＴＲＩＰピアから受信したルート広告のセットを表わす。好ましくは、ＩＴＡＤ（ＴＲＩＰ注流メカニズムによって占められた）の内に、ＴＲＩＰの各インスタンスについて、１つのＡｄｊ−ＴＲＩＢ−Ｉｎ（内部）８５８がある。これらの内部ＴＲＩＢの内容は、すべての内部ピアに広告される。これらは、図８においてＡｄｊ−ＴＲＩＢ−Ｉｎ（内部）８５８から出る矢印「内部ピア」によって示されている。楕円枠８５４は、Ｅｘｔ−ＴＲＩＢであり、内部ピアに広告される境界外のＩＴＡＤから受け取った、ローカルポリシー８５２からのルートのセットを示す。楕円枠８６２は、Ｌｏｃ−ＴＲＩＢであり、ＳＲの内のルーティング決定を行うために使用されるルートのセットを表わす。楕円枠８６４は、Ａｄｊ−ＴＲＩＢ−Ｏｕｔであり、外部ピアに広告されるルートのセットを表わす。好ましくは、そこに、１つの外部ピアに対して、１つのＡｄｊ−ＴＲＩＢ−Ｏｕｔ８６４が存在する。
【０１１０】
ＴＲＩＰは、数値の値としてローカルの優先度を定義し、それはローカルルートへ組み込まれ、内部ピアに渡される。この優先度は、同じ終点へのルートのセット間での選択に利用できる。発明の好ましい実施形態によれば、ＴＲＩＰは、発信アドレス、キャリア、曜日、時刻、コストおよびＱＯＳ含む多くの属性を、ルートへ加えることにより機能強化が行われた。ルート属性へのセッション招待の属性のマッチングが含まれているので、セッション招待へのこれらの属性の適用は、好ましくは、実行時間で行われる。個別のルート（つまり発信アドレス、着信アドレスおよび次の転送先サーバのアドレス）のすべては、（ルートに優先度の値を適用し、優先度の最も高いルートだけを選択する代わりに）、ＴＲＩＢの中で保持される。基本的に、すべてのルートに対する優先度は同じである。
【０１１１】
ＴＲＩＰ決定プロセスの第１段階では、優先度の値を決定する為にＳＲに定義されたＰＩＢが使用される。しかしながら、優先度の値を適用する代わりに、境界内のスクリーニングは、境界内のスクリーンデータを使用して実行される。このスクリーンデータは、受理可能な受信ルートを選択し、それらにデフォルト属性を加える為に、境界内のポリシースクリーン７２２（図７）に設けられている。Ａｄｊ−ＴＲＩＢ−Ｉｎ（外部）８５６が変更された時にのみ、第１段階が実行されることに注意されたい。さらに、境界外スクリーニング８０２（図７）は、境界外のスクリーンデータを使用して実行され、このスクリーンデータは境界外のポリシースクリーン８０２（図７）内に設けられている。
【０１１２】
そのスクリーニングされた外部ルートのセットは、ローカルポリシースクリーニングに加えて、決定プロセスの第２段階の第１の部分の入力となる。以前のＴＲＩＰ仕様によれば、この段階では、優先度の最も高いルートが選択される。ルートがすべてＳＲ内で等しい優先度を持つので、この段階ではＥｘｔ−ＴＲＩＢ８５４をロードする為に、ローカルポリシーにスクリーニングされた外部ルートが加えられる。この段階では、さらに、ローカルポリシーによって参照されたＳＩＰエージェントが使用されているかどうかが考慮される。ここでは、アクティブでサービス中のＳＩＰエージェントのためのルートだけが含まれている。その後、このルートのセットは、すべての内部ピアに広告される。ローカルポリシー８５２又はＡｄｊ−ＴＲＩＢ−Ｉｎ（外部）８５６が変更された時にのみ、第２段階の第１の部分が実行されることに注意されたい。
【０１１３】
Ｅｘｔ−ＴＲＩＢ８５４とＡｄｊ−ＴＲＩＢ−Ｉｎ（内部）８５８は、決定プロセスの第２段階の第２の部分への入力を含んでいる。ＴＲＩＰ仕様によれば、この段階では、優先度の最も高いルートが選択される。ＳＲについては、入力ＴＲＩＢが、Ｌｏｃ−ＴＲＩＢ８６２の出力を作成する為にマージされる。このルートのセットは、セッション招待を送る為に使用される。
【０１１４】
外部ピアに広告するルートのセットを生成する為に、決定プロセスの第３の段階が、Ｌｏｃ−ＴＲＩＢ８６２上で動作する。この段階では、各外部ピア（つまりＡｄｊ−ＴＲＩＢ−Ｏｕｔ８６４）に一組のルートを選ぶために、ＰＩＢに定義された境界外のスクリーン８８４が用いられる。この段階はさらにルートの集成を行う。ローカルポリシー８５２のいずれか或いはＡｄｊ−ＴＲＩＢ−Ｉｎ８５６、８５８の１つについて、入力ルートが、追加、変更、撤去されるごとに、決定プロセスの３つの段階が実行される。
【０１１５】
システムリソース上の負担となり得る、この決定プロセスの実行が余りに頻繁となることを回避する為に、好ましくは、入力ＴＲＩＢが変更された場合に、ＴＲＩＰ ＬＳは、短いタイマー（例えば数秒のオーダー）をセットする。このタイマーが終了（作動）した時、決定プロセスが実行されルータイマーが終了する前に、別の変更が生じる場合、タイマーはリセットされる。第１の変更が生じる場合、別のタイマー（それは第１のタイマーより長い）がセットされる。このより短いタイマーが終了し、決定プロセスが実行される場合、この第２のタイマーは取り消される。短いタイマーが連続的な変更のために繰り返しリセットされる場合、より長いタイマーは結局終了し、決定プロセスが実行される。より長いタイマーは、適切な時間内に走ることを決定プロセスに強いて、短いタイマーがずっと決定プロセスの実行を遅らせるのを防げる。決定プロセスが実行されている間に、入力ＴＲＩＢを変更することができないように、入力ＴＲＩＢへの変更の処理と決定プロセスの処理は同一スレッドで実行される。
【０１１６】
図９Ａおよび９Ｂは、発明の好ましい実施形態によるＴＲＩＰ「アップデート」メッセージの主なコンポーネントを示すブロックダイヤグラムである。メッセージ９０２はいくつかの属性（９０８、９１２、９１４）を含んでいる。メッセージの全長は、長さフィールド９０４で定義される。また、メッセージタイプはタイプフィールド９０６で定義される。好ましくは、属性の数に制限はないが、最大のメッセージサイズで制限される。各メッセージは、単一のポリシーの一部である一組の属性の通信の為に、設けられている。
【０１１７】
メッセージがＴＲＩＰサーバデーモンに入力されると、解析される。好ましくは、Ｃ＋＋ソフトウェアが、メッセージおよびそれらの属性を解析する為に使用される。属性フラグ９２４および属性タイプコード９２６の解析により一旦属性が解析されれば、それら属性は、取り下げられたルート９４２、到達可能なルート９６２、次の転送先サーバ９８２、発信アドレス９９２およびキャリア１０１２のタイプを含む図９Ａおよび９Ｂの中で識別されたタイプのうちの１つへ抽出される。属性長さフィールド９２８は、解析部（パーサ）が可変長さの属性を受け入れるか、或いは未知の属性をスキップすることができるように、後続の属性の長さを決定する為に使用される。
【０１１８】
そして、解析された属性は、受け取られた順に処理される。したがって、好ましくは、取り下げられたルート９４２の属性は、到達可能なルート９６２の属性の前に処理される。取り下げられたルート９４２、到達可能なルート９６２、および発信アドレス９９２の属性は、すべては同じフォーマットを備えている。アドレスファミリーフィールド９４４、９６４および９９４は、ＰＯＴＳあるいはルーティング番号を参照する。２５４のアドレスファミリーコードは、ＵＲＩアドレスを示すために付け加えられた。プロトコルフィールド９４６、９６６および９９６は、通常、ＳＩＰあるいは値１にセットされる。長さフィールド９４８、９６８および９９８は、アドレス部分９５２、９７２および１００２の実際の長さ（好ましくは、バイトで）を示す。以前に述べたように、アドレス部分は部分的な電話番号あるいは部分的なＵＲＩのいずれかでもよい。次の転送先サーバ９８２およびキャリア１０１２のタイプが、同様の方法で解析されることに注意されたい。
【０１１９】
下記は、ＴＲＩＰ「アップデート」メッセージの例を示す。なお、どのように「アップデート」メッセージが処理されるかを説明する為に、ここでは、ＴＲＩＢと「アップデート」メッセージの内容は、実際に用いられるバイナリのデータの代わりに単純なテキストとして、示しているということに注意されたい。
【０１２０】
例：
ＴＲＩＰアップデート
取り下げられたルート： none
到達可能なルート： 1 [seq. Num.: 1, origin TRIP ID: 111]
次の転送先サーバ： sip:server.com
ＩＴＡＤトポロジー： 222
発信アドレス： tel:1-617
キャリア； NextGen/0000-2400/U-S/0.50/SHQ G.711
【０１２１】
この例では、発信アドレス９９２はＵＲＩであり、到達可能なルート９６２は、部分的な電話番号であるということを理解すべきである。さらに、キャリア１０１２は、５つの部分、即ち、名前／時間／日／コスト／品質を備えていることも理解すべきである。到達可能なルート９６２の属性の隣の鍵括弧内のテキストは、リンク状態属性のシーケンス番号および起点ＴＲＩＰ ＩＤを示す。この例においては、取り下げられたルートはないので、対応するテキストは省略される。
【０１２２】
ポリシーがロードされ、決定と広告が行われ、ＴＲＩＢの各々への変更が、好ましくは、以下のフォーマットによって行なわれる。
【表６】
2005502219.tif 000008
【０１２３】
この処理例について更に議論する前に、そのルータトポロジーを定義する必要がある。トポロジーは次のＳＲを含む。
【０１２４】
・sr.acme.comに設けられているＩＴＡＤ２０２４のＴＲＩＰ ＩＤ１１１。
・sr2.acme.comに設けられているＩＴＡＤ２０２４のＴＲＩＰ ＩＤ２２２。
・sr3.acme.comに設けられているＩＴＡＤ２０２４のＴＲＩＰ ＩＤ３３３。
・external.carrier.comに設けられているＩＴＡＤ２０５５のＴＲＩＰ ＩＤ７８９。
【０１２５】
図１０は、ＩＴＡＤトポロジーの例を示すブロックダイヤグラムである。必要な場合、ＩＴＡＤおよびＴＲＩＰ ＩＤの組み合わせは、ここでは、＜ＩＴＡＤ＞：＜ＴＲＩＰ ＩＤ＞のように表わされる。したがって、ＩＴＡＤ１０２４とＴＲＩＰ ＩＤ１１１の組み合わせは１０２４：１１１として書かれることになる。この例の全体にわたって、ＳＲは、それらのドメインアドレス３６４（図３Ｂ）、或いはそれらのＴＲＩＰ識別子３６６（図３Ｂ）およびＩＴＡＤ識別子３６８（図３Ｂ）のいずれかによって識別される。ＳＲ１０２４：２２２および５５５：７８９は１０２４：１１１に隣接している。また、ＳＲ１０２４：２２２および１０２４：３３３は互いに隣接している。
【０１２６】
この例では、ＴＲＩＰ ＩＤ１１１を有するＩＴＡＤ２０２４におけるＳＲ（sr.acme.com）２０００から見た、ＴＲＩＢの初期化と処理について記述する。ＳＲ（sr.acme.com）２０００は、２つの隣接したピア（ＳＲ１０２４：２２２および５５５：７８９）、１つの外部ピア（ＴＲＩＰ ＩＤ７８９を有するＩＴＡＤ２０５５におけるexternal.carrier.com ２００３）および１つの内部ピア（ＴＲＩＰ ＩＤ２２２を有するsr2.acme.com ２００１）を備えている。ＳＲ（sr.acme.com）およびＳＲ（sr2.acme.com）が内部ＴＲＩＰピアであるので、それらは同じＩＴＡＤ番号を備えている。さらに、ＩＴＡＤ２０２４は、もう１つ別のＳＲ（すなわちＴＲＩＰ ＩＤ３３３を有するＳＲ（sr3.acme.com）２００２であり、それは、ＴＲＩＰ ＩＤ２２２を有するsr2.acme.com ２００１にのみ隣接している）を有している。
【０１２７】
ＳＲ（sr.acme.com）２０００のローカルポリシー情報は、ルータ初期化の一部として以下に論ずる。この例の目的から、以下のことを述べておく。
【０１２８】
・sr2.acme.com ２００１はローカルポリシー情報を持っていない。
・sr3.acme.com ２００２は、土曜日または日曜日の任意の時間に、０．１０のコストで遠いキャリアを使用するゲートウェイＤ ２００６経由で、任意のアドレスから、１−９７８で始まる任意の番号へのアクセスを許可するローカルポリシーを備えている。
・external.carrier.com ２００３（外部である為、この例では、この時点で、sr.acme.com ２０００にとって未知である）は、月曜日から金曜日の任意の時間に、０．５０のコストで、この外部キャリアを使用するゲートウェイＥ２００７経由で、任意のアドレスから、１で始まる任意の番号へのアクセスを許可するローカルポリシーを備えている。
【０１２９】
現在の例において、５つのＴＲＩＢ（その各々はＳＲ２０００との関連から説明される）がある。隣接ＴＲＩＢ入力（Ａｄｊ−ＴＲＩＢ−Ｉｎ）は、外部の隣接ＴＲＩＢ入力（Ｅｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎ）および内部の隣接ＴＲＩＢ入力（Ｉｎｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎ）へ分解される。これは、様々なポリシー入力がどのように処理されるかについて更に詳しく議論することを可能とする。１つの外部（ＩＴＡＤへの）ピア当たり、１つのＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎがあり、したがって、ＳＲは、Ｅｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎを１つを持つ。同様に、１つの内部ＳＲ当たり、１つのＩＮＴ−Ａｄｊ−ＴＲＩＢ−Ｉｎがあり、したがって、この例は１つのＩＮＴ−Ａｄｊ−ＴＲＩＢ−Ｉｎから始めることができる。
【０１３０】
内部ピアへの広告のために、処理済みの外部ルート情報とローカルのルート情報を含む１つの外部ＴＲＩＢ（Ｅｘｔ−ＴＲＩＢ）と、ルーティング決定を下すためにこのルータによって使用されるルーティング情報を含んでいる１つのローカルＴＲＩＢと、外部ピアへの広告のために処理済みのルートを含んでいる１つの隣接ＴＲＩＢ出力（Ａｄｊ−ＴＲＩＢ−Ｏｕｔ）が存在する。
【０１３１】
この時点で、ＴＲＩＢがすべて初期化される。ＳＲが２つのピア（１つは外部、１つは内部）を持つので、初期化されたＴＲＩＢは以下のとおりである。
【表７】
2005502219.tif 000009
【０１３２】
初期化では、サーバは、そこに格納されているすべてのポリシー読み込み、ｌｏｃａｌ−ＴＲＩＢ、Ｅｘｔ−ＴＲＩＢおよび Ａｄｊ−ＴＲＩＢ−Ｏｕｔを実装する。この例では、次のローカルのコンフィギュレーションデータを仮定する。
【０１３３】
キャリア： NextGen
名前： NextGen
記述： Local NextGen Carrier
サービス状態： 有効
ID: 10107654
キャリア： LastGen
名前： LastGen
記述： Local LastGen Carrier
サービス状態： 有効
ID: 10107655
キャリア： Enterprise
名前： Enterprise
記述： Local Enterprise Carrier
サービス状態： 有効
ID: 10107656
キャリア： External
名前： External
記述： Default Carrier associated with Inbound
ITAD 2055からアップデート
サービス状態： 有効
ID: 10109999
管理アカウント
ユーザーＩＤ：Cliff
パスワード： Rocket
アクセス権： Super User
隣接ルータ
第１エントリ
名前： external
ドメインアドレス： external.carrier.com
ＴＲＩＰ識別子： 789
ＩＴＡＤ識別子： 2055
第２エントリ
名前： sr2
ドメインアドレス： sr2.acme.com
ＴＲＩＰ識別子： 222
ＩＴＡＤ識別子： 2024
ＳＩＰエージェント
第１エントリ
ドメインアドレス： gateway1.acme.com
名前： Gateway A
記述： Gateway to NextGen Carrier
登録間隔： 30
キャリア[ ]: { NextGen }
第２エントリ
ドメインアドレス： gateway2.acme.com
名前： Gateway B
記述： Gateway to NextGen, LastGen Carriers
登録間隔： 30
キャリア[ ]: { LastGen, NextGen }
第３エントリ
ドメインアドレス： gateway3.acme.com
名前： Gateway C
記述： Gateway to Business
登録間隔： 30
キャリア[ ]: { Enterprise }
ＳＩＰエージェントグループ： Group A
ストラテジー： Hunt
エージェント数： 1
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway A
ＳＩＰエージェントグループ： Group B
ストラテジー： Hunt
エージェント数： 1
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway B
ＳＩＰエージェントグループ： Group C
ストラテジー： Hunt
エージェント数： 1
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway C
ＳＩＰエージェントグループ： Group A+B
ストラテジー： Hunt
エージェント数： 2
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway A
エージェントタイプ： SIP Endpoint
ＳＩＰエージェント： Gateway B
ＳＲ
ドメインアドレス： sr.acme.com
ＴＲＩＰ識別子： 111
ＩＴＡＤ識別子： 2024
名前： Acme SR
記述： SR for Acme Packet
場所： 130 New Boston Street; Woburn MA
ＴＲＩＰバージョン： 1.0
ＳＩＰバージョン： 2.0
ルータバージョン： 0.1
管理アカウント[ ]: { Cliff }
隣接ルータ[ ]: { external.carrier.com, sr2.acme.com }
ＳＩＰエージェント[ ]: { Gateway A, Gateway B, Gateway C}
ローカルポリシー
第１エントリ
作成者： Cliff
追加日： 10:/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： tel:1-781
次の転送先： Group B
サービス状態： 有効
ルート属性数： 2
第１属性
キャリア： NextGen
サービス状態： 有効
時間： 0000-2400
曜日： S
コスト: 0.10
QoS: SHQ G.711
第２属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U
コスト: 0.15
QoS: SHQ G.711
第２エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： tel:1-781
次の転送先： Group A
サービス状態： 有効
ルート属性数： 2
第１属性
キャリア： NextGen
サービス状態： 有効
時間：0000-0700,1700-2400
曜日： M-F
コスト: 0.20
QoS: SHQ G.711
第２属性
キャリア： NextGen
サービス状態： 有効
時間：0700-1700
曜日： M-F
コスト: 0.30
QoS: SHQ,G.711
第３エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： tel:1-781-933
次の転送先： Group C
サービス状態： 有効
ルート属性数： 1
第１属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-0700,1700-2400
曜日： M-F
コスト: 0.25
QoS: SHQ G.711
第４エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： acme.com
次の転送先： Group C
サービス状態： 有効
ルート属性数： 1
第１属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-2400
曜日： M-F
コスト: 0.25
QoS: SHQ G.711
第５エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： tel.1-617
次の転送先： Group A+B
サービス状態： 有効
ルート属性数： 1
第１属性
キャリア： NextGen
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト: 0.25
QoS: SHQ G.711
隣接ＩＴＡＤ
ＩＴＡＤ識別子： 555
名前： External Network
記述： External ITAD
境界内スクリーン：
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： *
ポリシー属性数： 1
第１ポリシー属性
キャリア： External
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト: 0.20
QoS: SHQ G.711
境界外スクリーン：
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分着信アドレス（ＵＲＩ）： 1-781
ポリシー属性数： 2
第１ポリシー属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
第２ポリシー属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
スクリーン#2:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分着信アドレス（ＵＲＩ）： 1-978
ポリシー属性数： 0
【０１３４】
以下に示される「アップデート」メッセージ処理のより詳細な説明に先立って、上に定義したローカルポリシーの説明を行う。ローカルポリシーの、キャリア以外の他の属性にも、焦点を合わせることに注意されたい。定義された第１の３つのキャリア（つまりＮｅｘｔｇｅｎ、ＬａｓｔｇｅｎおよびＥｎｔｅｒｐｒｉｓｅ）は、ローカルのＳＲポリシー定義のために使用される。最後のキャリア（つまりＥｘｔｅｒｎａｌ）は、ＩＴＡＤ２０５５からの「アップデート」メッセージによってＩＴＡＤ２０２４に入る任意のルートに割り当てられるデフォルトキャリアとして使用される。
【０１３５】
隣接したルータは、内部および外部ピアsr.acme.com ２０００ ＴＲＩＰに関する情報を含んでいる。そしてこの情報は、接続を開始し、かつメッセージ内容を有効にする為に使用される。隣接したＳＩＰエージェントは、このＳＲが、アクセスを制御する３つのゲートウェイを示す。定義された３つのＳＩＰエージェントグループ（つまりグループＡ、ＢおよびＣ）は、単に単一のエージェントグループであり、ゲートウェイ毎に１つ存在する。最後のＳＩＰエージェントグループ（グループＡ＋Ｂ ２００９）は、ゲートウェイＡ ２００４およびゲートウェイＢ ２００５の両方を含んでいる。複数のエージェントを有するグループのコンフィギュレーションは、同じポリシーをサービスするゲートウェイに対して、異なるストラテジー（例えばハント（Ｈｕｎｔ）、ラウンドロビンなど）および基準（例えばアクティブセッションの数のような制約）を使用してアクセスすることを可能とする。
【０１３６】
ＳＲは、このセッションルータに特有のデータ（つまり、稼働開始、メッセージ評価および「アップデート」メッセージ処理のために使用されるデータ）について記述する。ローカルポリシーは、好ましくは、ＳＲに隣接しているゲートウェイに関係する。キャリアＮｅｘｔＧｅｎ、ＬａｓｔＧｅｎおよびＥｎｔｅｒｐｒｉｓｅはＳＲsr.acme.com ２０００のために定義されている。第１から第４のポリシーは、関連する時間フレームおよびコストに依存して、特定の発信アドレスから特定の着信アドレスへセッションが送ることができる、隣接したゲートウェイを通るルートを示す。隣接したＩＴＡＤのエントリは、現在のルータとポリシーを交換する外部のＩＴＡＤを示す。
【０１３７】
スクリーン（境界内の７２２（図７）、および境界外の８０２（図７））は、このＩＴＡＤ２０２４と、このＳＲ２０００が通信できる外部のＩＴＡＤの間の情報のフィルータリングを行うために使用される。この時、外部のＩＴＡＤがキャリア属性を送信したり処理しないので、外部デフォルトキャリアが、ＩＴＡＤ２０５５から受け取ったポリシーを拡張する為に確立される。この例のＩＴＡＤ２０２４は、これらの属性を処理する。境界内のスクリーンは、任意の番号（＊によって表示された）に関連付けられたポリシーを受理する為に確立される。これらのポリシーが受理される場合、それらは、ポリシーの時刻または曜日の制限にかかわらず、キャリアＥｘｔｅｒｎａｌに関連付けられる。このルーティングされたネットワークは、ゲートウェイＣ ２００８と名付けられたビジネスゲートウェイと、ゲートウェイＡ ２００４およびゲートウェイＢ ２００５と名付けられた２つのキャリアゲートウェイ、およびゲートウェイＥ ２００７（それは、外部キャリアによって表わされる外部のＩＴＡＤ内にある）の間のポリシーベースのルーティングが行われる。キャリアＬａｓｔｇｅｎおよびＥｎｔｅｒｐｒｉｓｅを使用し、１−７８１で始まる番号を持ち、所定の時間フレーム内のポリシーだけが、ＩＴＡＤ２０５５に広告されるように、１つの境界外のスクリーンが設定される。異なるＩＴＡＤエントリは同じ部分着信アドレスのスクリーンと異なるポリシー属性を持てるが、各ＩＴＡＤエントリは、好ましくは、与えられた部分着信アドレスのスクリーンをただ１つだけ備えている。（隣接＝ピア）。
【０１３８】
任意のキャリアを使用し、１−９７８で始まる番号へのポリシーだけが、ＩＴＡＤ２０５５へ広告されるように、別の境界外のスクリーンが定義される、 特定のキャリアエントリが無いということは、どんなキャリアもスクリーンを通れることを示す。スクリーンの使用は、ルート決定段階およびルート配布に更なる柔軟性と制御性を与える。ＴＲＩＰサーバがローカルポリシーデータベースを開き、ポリシーをロードし始めた後、以下に詳述される次のような状況が生じる。
【０１３９】
格納されたローカルポリシーデータベース中の第１のポリシーは次のとおりである。
【０１４０】
第１エントリ
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩ）： tel:1-781
次の転送先： Group B
サービス状態： 有効
ルート属性数： 2
第１属性
キャリア： NextGen
サービス状態： 有効
時間： 0000-2400
曜日： S
コスト: 0.10
QoS SHQ G.711
第２属性
キャリア： LastGen
サービス状態： 有効
有効
時間： 0000-2400
曜日： U
コスト: 0.15
QoS: SHQ G.711
【０１４１】
第１のポリシーは、現在の時間と活性化日付／時間の比較によりそれがアクティブだったかどうか確かめる為に再検討される。ポリシーが現在アクティブでない場合、将来の特定の時間に、格納されたローカルポリシーデータベースから、このポリシーを再注入する為に、タイマーがセットされる。ポリシーが現在アクティブでない場合、それ以前に処理は行われない。同じ発信アドレスフィールド４７４（図３Ａ）および着信アドレスフィールド４７６（図３Ａ）を備えたポリシーの中から、１つのポリシーが選択されていた場合、将来の特定の時間に、そのルートが取り下げられるように、非活性化タイマーをスタートさせることができる。ここでは、有効日付／時間４６８（図３Ａ）の値が０であり、および無効日付／時間４７２（図３Ａ）の値が０であるので、ポリシーは常にアクティブである。したがって、ポリシーは、直ちにＥｘｔ−ＴＲＩＢに加えられるべきである。
【０１４２】
ＴＲＩＰ ＬＳは、決定段階１で、１つのルートを他のものより優先したりはしない。「招待」メッセージが処理される場合、これらの決定はＳＩＰプロキシサーバに委ねられる。これは、等価と見なされるルート上の分配パターン或いは日時のような基準に基づく、より複雑なルート選択を可能とする。好ましくは、ローカルの優先度属性は一つの値５にセットされる。ＴＲＩＰ ＳＲの稼働開始シナリオは、決定段階１の特定の場合および決定段階２の第１の部分であり、ピア接続がまだ開かれていないので、Ａｄｊ−ＴＲＩＢ−ＩｎＳはすべて空である。発明の好ましい実施形態によれば、ここに記述されるようなルートが、標準のＴＲＩＰやＢＧＰ−４のルートよりも多くの情報を含み得るので、終点アドレスのみについて、ルートが多少とも特定されたりはしないと考えられる。
【表８】
2005502219.tif 000010
【０１４３】
ＳＲが起動プロセス中なので、まだ、広告すべきものはなく、Ｅｘｔ−ＴＲＩＢの中のエントリは、内部ピアに対して広告されない。更に、ＩＮＴ−Ａｄｊ−ＴＲＩＢ−Ｉｎからの入力はなく、したがって、第２段階の第２の部分は、Ｅｘｔ−ＴＲＩＢと同じｌｏｃａｌ−ＴＲＩＢを生成する。発明の好ましい実施形態により使用される決定段階は、標準のＴＲＩＰの実行によって使用されるものとは違っている。
【表９】
2005502219.tif 000011
【０１４４】
他の属性が同じである限り、このルートについて、マルチキャリアルーティングを行うために必要とされる数のキャリアエントリが設けられることに注意されたい。ここでも、ピア接続がまだ開かれていないので、各々のＩｎｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎは空であり、無視することができる。次のステップは、このポリシーが外部と共有されることになっているかどうか確かめることである。これをする為に、ＩＴＡＤ２０５５（ポリシー交換対象である唯一のＩＴＡＤ）の境界外のポリシースクリーンを調べる。
【０１４５】
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-781
ポリシー属性数： 2
第１ポリシー属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
第２ポリシー属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
スクリーン#2:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-978
ポリシー属性数： 0
【０１４６】
第１のスクリーンの部分的着信アドレスが、第１のローカルポリシーの着信アドレスの最初の４バイトに一致するので、これが最長且つ最適な一致であり、外部と共有すべきかどうか決める為に、この境界外のポリシースクリーンが選択される。（第２のスクリーンの部分的着信アドレスは、第２の桁（ディジット）で一致しない。）図１１は、与えられたポリシーが外部に広告されるかどうか決める為に、最適のマッチングスクリーンを使用するプロセスを示すフローチャートである。ブロック２１０２によって示されているように、スクリーンの活性化日付／時間と非活性化日付／時間を決める為にチェックがなされる。活性化日付／時間と非活性化日付／時間が両方とも０であるので、現在のポリシーはアクティブなままである。その後、ブロック２１０４によって示されているように、スクリーンの許可／拒絶状態を決めるチェックが行われる。許可／拒絶属性は許可にセットされているので、現在のポリシーはアクティブなままである。
【０１４７】
その後、ブロック２１０６によって示されているように、外部のＩＴＡＤ２０５５の最も良く一致する境界外のポリシースクリーンの属性に対して、現在のポリシーの属性を決める為のチェックが行われる。最も良く一致するスクリーンは、そのキャリアリストにＬａｓｔＧｅｎキャリアを持ち、ＬａｓｔＧｅｎキャリアが有効になっているので、現在のポリシーはアクティブなままである。ＮｅｘｔＧｅｎキャリアは、ＩＴＡＤ２０５５に対して選択された境界外のポリシースクリーンの中にない。したがって、ルートはアクティブなままで、キャリア属性なしで外部的に広告されることとなる。ＩＡＮＡがキャリア属性を承認した場合には、このポリシーは、ＬａｓｔＧｅｎキャリアを含むがＮｅｘｔＧｅｎキャリアは含まない形で広告されることとなる。
【０１４８】
ブロック２１０８によって示されているように、それらがより限定的な場合、時刻および曜日を有効にして、ポリシーは隣接ＴＲＩＢ出力へ追加される。このケースでは、時刻、曜日、コストおよびＱｏＳ（品質）属性は、境界外のポリシースクリーンにおいて限定的ではない。したがって、ポリシーのキャリア属性は変えられることなく、隣接したルータに送られる。
【０１４９】
外部のＴＲＩＰピアがキャリア属性を処理することができるような状況で、ポリシーの内容は、次のとおりとなる。
【０１５０】
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
発信アドレス（ＵＲＩ）： *
着信アドレス（ＵＲＩＪ）： tel:1-781
次の転送先： gateway2.acme.com
サービス状態： 有効
ルート属性数： 1
第１属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U
コスト: 0.15
QoS: SHQ G.711
【０１５１】
好ましくは、ポリシーおよびキャリアエントリのサービス状態フィールドは、広告されたポリシーでなく、ローカルのコンフィギュレーションの一部である。ポリシーあるいはそのキャリアのうちの１つが無効である場合、そのポリシー又はその部分は、任意のＴＲＩＢに入力されず広告もされない。ＳＲは、それが制御するゲートウェイに流れ込むトラヒックを把握している必要があるので、広告（つまり、外部広告、あるいは内部広告）が行われる場合、ローカルゲートウェイの次の転送先サーバアドレスがＳＲに置き換えられる。
【０１５２】
前のスクリーニング例と対比して、次のスクリーニングシナリオを説明する。ＩＴＡＤ２０５５のための第１の境界外のポリシースクリーンが次の通りと仮定する。
【０１５３】
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-781
ポリシー属性数： 2
第１ポリシー属性
キャリア： Enterprise
サービス状態： 有効
時間： 0700-1500
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
第２ポリシー属性
キャリア： LastGen
サービス状態： 有効
時間： 0700-1500
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
【０１５４】
この場合、生成されるポリシーはより、限定的なオペレーションの許可時間に合わせて変更される。したがって、このポリシーは、外部のＴＲＩＰサーバに適用されるとともに、次のキャリア属性を含む。（下記のものは広告されたポリシーであるので、サービス状態フィールドが除かれていることに注意されたい）
【０１５５】
第１属性
キャリア： LastGen
時間： 0700-1500
曜日： U
コスト: 0.15
QoS: SHQ, G.711
【０１５６】
境界外のポリシースクリーニングは、どのポリシーをエクスポートすべきかを制御する為の強力なツールである。エクスポートされる為に、このポリシーは、これらのテストすべてに合格しなければならないので、それは多くの柔軟性を必要とする。さらに、到達可能なルートや着信アドレス属性を絞ることが可能であることに注意されたい。したがって、この従前のポリシーは１−７８１を参照することができたが、境界外のスクリーンは１−７８１−９３３を参照することができていた。この場合、エクスポートされたポリシーは、１−７８１ではなく、より絞られた１−７８１−９３３を広告されることとなる。
【０１５７】
下記は上記の例を拡張し、Ａｄｊ−ＴＲＩＢ−Ｏｕｔのエントリを参照する。
【表１０】
2005502219.tif 000012
【０１５８】
ＩＡＮＡがキャリアおよびＱＯＳ属性のＴＲＩＰ拡張を承認するまで、上記、発信アドレスおよびキャリアの列は、外部ピアへは送られないことに注意されたい。他の４つのルートに同じプロセスを適用した後に、sr.acme.comのＴＲＩＢは以下のようになる。
【表１１】
2005502219.tif 000013
【表１２】
2005502219.tif 000014
【表１３】
2005502219.tif 000015
【表１４】
2005502219.tif 000016
【表１５】
2005502219.tif 000017
【０１５９】
グループＡ＋Ｂ １００９が、現実に２つのゲートウェイを参照することに注意されたい。「招待」が到着し、そのために選ばれた最適のポリシーが、次の転送先サーバとしてグループＡ＋Ｂ２００９を有している場合、各ゲートウェイの現在および以前のセッションに関する統計値情報は、セッションリクエストがどのゲートウェイに向けられるか決める為に使用される。そして、ローカルに格納されたポリシーと共に、Ｅｘｔ−ＴＲＩＢ、ローカルＴＲＩＢおよびＡｄｊ−ＴＲＩＢ−Ｏｕｔの初期化が完了する。
【０１６０】
次のステップはピアに接続を開くことである。好ましくは、次の２種類のピアがある。つまり、ローカルピアおよび外部ピアである。ローカルピアはsr.acme.com ２０００と、そのローカルポリシーを共有する為に、注流スキームを使用する。例えば、ＴＲＩＰの注流プロセスは以下のように記述される。ＴＲＩＰ ＬＳが、内部ピアから「アップデート」メッセージを受け取る場合、ＴＲＩＰ ＬＳは、そのメッセージからの新しい情報を、他のすべての内部ピアに注流させる。注流は、ドメインの内部トポロジーへのどんな制約も加えることなく、ドメイン内のＴＲＩＰ ＬＳのすべてを効率的に同期させる為に用いられる。
【０１６１】
内部ＳＲピアへの接続が開かれる。ソケットが開かれ、ＴＲＩＰ「オープン」メッセージとバージョンネゴシエーションが実行された後、「アップデート」メッセージは、両方向に注流され始める。sr2.acme.com ２００１からのメッセージは、そのＥｘｔ−ＴＲＩＢエントリのすべてをsr.acme.com ２０００と共有し、sr.acme.com ２０００の方へ向かって送られ始める。反対に、sr.acme.comは、sr2.acme.com ２００１に、そのＥｘｔ−ＴＲＩＢエントリをすべて送り始める。このように、内部ＳＲは、Ｅｘｔ−ＴＲＩＢエントリを交換し、新しくアクセス可能なピアへの他の内部ピアのためのＩＮＴ−Ａｄｊ−ＴＲＩＢ−ＩｎＳの中の任意のエントリを伝搬させる。同様に、外部に隣接したＳＲは、Ａｄｊ−ＴＲＩＢ−Ｏｕｔエントリを交換する。この時、「アップデート」メッセージは、Ｅｘｔ−ＴＲＩＢの中のエントリの為に、次の内容で内部ピアへ送られる。
【０１６２】
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-781 [Sequence Number: 1,TRIP ID: 111]
次の転送先サーバ： sr.acme.com
ＩＴＡＤトポロジー： 222
発信アドレス： *
キャリア： NextGen/0000-2400/S/O.10/SHQ G.711
キャリア： NextGen/0000-0700, 1700-2400/M-F/0.20/SHQ G.711
キャリア： NextGen/0700-1700/M-F/.30/SHQ G.711
キャリア： LastGen/0000-2400/U/0.15/SHQ G.711
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-781-933 [Sequence Number: 1,TRIP ID: 111]
次の転送先サーバ： sr.acme.com
発信アドレス： *
キャリア： Enterprise/0000-0700,1700-2400/M-F/0.25/SHQ G.711
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： acme.com [Sequence Number: 1,TRIP ID: 111]
次の転送先サーバ： sr.acme.com
発信アドレス： *
キャリア： Enterprise/0000-2400/M-F/0.25/SHQ G.711
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-617 [Sequence Number: 1,TRIP ID: 111]
次の転送先サーバ： sr.acme.com
発信アドレス： *
キャリア： NextGen/0000-2400/U-S/0.10/SHQ G.711
【０１６３】
「アップデート」メッセージヘッダーでは、シーケンス番号と呼ばれる生成／バージョン番号が含まれることに注意されたい。ＴＲＩＰによって定義されるように、シーケンス番号は、ルートの１つのバージョンが、ルートの別のバージョンより新しくなる時を決める為に使用される。より大きなシーケンス番号はより新しいバージョンを示す。シーケンス番号は、ローカルＩＴＡＤへルートを生成するＴＲＩＰ ＬＳによって割り当てられる。
【０１６４】
ＳＲがルート（例えば、新しいレートを持ったキャリアを含むもの）の新しいインスタンスを生成する場合は常に、バージョン番号は１だけインクリメントされる。この番号は、注流中（そこで同じＩＴＡＤの内のＳＲはルートのインスタンスを受け取る）に重複を検知する為に、ＴＲＩＰ ＩＤと組み合わせて使用される。さらに、ここでは、この隣接したエージェントに送られた最初の「アップデート」メッセージなので、すべての既知の内部隣接ルータの完全なリストである現在のＩＴＡＤトポロジーが含まれている。好ましくは、ＳＲのそのローカルのトポロジーに対する知識が変わる場合、これが利用される。
【０１６５】
ＳＲはそれ自身（sr.acme.com ２０００）、内部広告中の実際のゲートウェイを置き換える。上記第２の「アップデート」メッセージでは、gateway3.acme.com ２００８の次の転送先サーバの代わりに、次の転送先サーバは、sr.acme.com ２０００にセットされる。しかしながら、ＴＲＩＰ ＬＳは、その決定のために、本当の次の転送先サーバ（ゲートウェイ）を使用する。最初の２つのルートが同じ発信アドレスと同じ着信アドレスを持つので、（たとえＥｘｔ−ＴＲＩＢに５つの「アップデート」メッセージがあっても）４つの「アップデート」メッセージ（つまりルート）だけが送られる。次の転送先サーバが、ＴＲＩＰ ＬＳのドメインアドレスと置き換えられる場合、キーとなるフィールドの３つがすべて同じなので、これらの２つのルートは一つへ結合される。
【０１６６】
新しいキャリアと発信アドレス属性がある場合、ＴＲＩＰ ＬＳが、「アップデート」メッセージを使って、一度に複数のルートに送る可能性は少ない。「アップデート」メッセージの内容に含まれる制限に加えて、「アップデート」メッセージに含まれた各ルートは、同じ発信アドレスとキャリアエントリを備えている。しかしながら、取り下げられたルートおよび到達可能なルート属性は、同じ「アップデート」メッセージの中に含まれることは可能である、 別の可能性は、より一般的なルートの取り下げ、および正確に同じ属性を備えた１つ以上の特定のルートによる置き換えである。srsr2.acme.com 2001は、sr.acme.com ２０００で使用する為に、Ｅｘｔ−ＴＲＩＢエントリを注流し始める。ローカルピアとの接続が確立された後、外部ピアとの接続が進む。
【０１６７】
sr2.acme.com ２００１からの次の「アップデート」メッセージを考慮されたい。
【０１６８】
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-978 [Sequence Number: 1, TRIP ID: 333]
次の転送先サーバ： sr3.acme.com
ＩＴＡＤトポロジー： 111, 333
発信アドレス： *
キャリア： Faraway/0000-2400/U,S/0.10/SHQ G.711
【０１６９】
この「アップデート」メッセージがsr2.acme.com ２００１から受け取られた場合、そのバージョンを１とする（それはルート生成者がそれをちょうど作成したばかりであることを示す）。さらに、例えば、（sr.acme.comに隣接していない）新しいローカルのルータの存在を示す、ＩＴＡＤトポロジー、をＴＲＩＰ ＩＤ３３３と共に送る。このトポロジーの変更は、ＴＲＩＰ ＩＤ３３３から（ＴＲＩＰ ＩＤ２２２あるいはsr2.acme.com経由で）sr.acme.comがＥｘｔ−ＴＲＩＢポリシーの注流を受け取るという点で重要である。そして、ＳＲ（sr.acme.com）２０００は、新しく発見された内部ＳＲ（sr3.acme.com）２００２のために、新しいＡｄｊ−ＴＲＩＢ−Ｉｎ、を作成する。
【表１６】
2005502219.tif 000018
【０１７０】
仮に未知のキャリア名が受け取られれば、インテリジェントデフォルトを備えたローカルでサポートされたキャリアのリストに、エントリが加えられなければならないこととなる。このイベントはトラップされ、管理ステーションへ転送される。
【０１７１】
sr2.acme.com ２００１（ＴＲＩＰ ＩＤ２２２）は、sr.acme.com ２０００からの「アップデート」メッセージの注流を受け取るので、それらはsr3.acme.com ２００２へ転送される。同様に、sr3.acme.com ２００２からsr2.acme.com ２００１へ送られた付加的な「アップデート」メッセージも、sr.acme.com ２０００へ転送される。ここでも、各ＴＲＩＰ ＬＳは、ローカルピアへのルート広告を生成する前に、そのローカルポリシーの中で、本当の次の転送先サーバをそれ自体で置き換える。
【０１７２】
この時、新しく作成されたＩＮＴ−Ａｄｊ−ＴＲＩＢ−Ｉｎから、この新しいポリシー情報が、修正済の決定段階に送られる。（ＴＲＩＰ ＩＤ２２２およびＴＲＩＰ ＩＤ３３３のための）Ｉｎ−Ａｄｊ−ＴＲＩＢ−ＩｎとＥｘｔ−ＴＲＩＢは、着信アドレスや発信アドレスのフィールドと一致する他のポリシーを含まないので、選択の問題はない。たとえ一致しても、すべてポリシーはまだ選択されており、ＳＩＰプロキシサーバによって照会された時、ＴＲＩＰ ＬＳは最終選択を行なう。ローカルポリシーが既に使用され、２０５５：７８９のためのＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎはまだ空なので、Ｅｘｔ−ＴＲＩＢの内容は、このプロセスの間に変わらない。
【０１７３】
sr.acme.comのためのローカルＴＲＩＢの内容は、現時点で、次のとおりである。
【表１７】
2005502219.tif 000019
【０１７４】
その後、ローカルＴＲＩＢは、決定段階３で処理される。決定段階３の一部として、境界外のスクリーンコンフィギュレーションは、このローカルポリシーを外部ピアへ広告することが可能かどうかを確かめる為に調べられる。このプロセスは、前に、ローカルポリシーが受理された時、この例の中で説明した。そして、この同じプロセスが行われる場合、このルート（それはスクリーンより限定的である）が、ＳＲのすべての外部ピアに広告されるべきことが分かる。ここでのＡｄｊ−ＴＲＩＢ−Ｏｕｔの内容は、次のテーブルの中で示されるようなものである。
【表１８】
2005502219.tif 000020
【０１７５】
以下に、ＩＴＡＤ２０５５の為のスクリーンを示す。
【０１７６】
スクリーン#1:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-781
ポリシー属性数： 2
第１ポリシー属性
キャリア： Enterprise
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.5 0
ＱＯＳ基準： SHQ G.711
第２ポリシー属性
キャリア： LastGen
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト基準： 0.00-0.50
ＱＯＳ基準： SHQ G.711
【０１７７】
スクリーン＃１は、次のものからのポリシーを許可する。即ち、「発信：＊」、「着信：電話番号：１−７８１」、「グループＢ」、しかし、キャリアＬａｓｔｇｅｎが好ましい。
【０１７８】
ＩＴＡＤ２０５５のためのＡｄｊ−ＴＲＩＢ−Ｏｕｔからは、「発信：＊」、「着信：電話番号：１−７８１」、「グループＢ」のポリシーは、除外される。なぜなら、一致するキャリアが無いからである。キャリア（Ｅｎｔｅｒｐｒｉｓｅ）は、スクリーンを通過できルータだ一つのキャリアなので、「発信：＊」、「着信：電話番号：１−７８１−９３３」、「グループＣ」のポリシーは、その全体に追加される。
【０１７９】
「発信：＊」、「着信：acme.com」、「グループＣ」のポリシーと、「発信：＊」、「着信：電話番号：１−６１７」、「グループＡ＋Ｂ」のポリシーは、一致する部分的着信アドレスが定義されていないので除外される。下記は、ＩＴＡＤ２０５５のためのスクリーン＃２に関する情報である。
【０１８０】
スクリーン#2:
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： 1-978
ポリシー属性数： 0
【０１８１】
第２の境界外のスクリーンが、マッチすべきキャリアを何も指定していないので、スクリーン＃２は、「発信：＊」、「着信：１−９７８」、「グループＣ」のポリシーを許可する。したがって、この時、たとえ遠いキャリアが、sr.acme.com ２０００に知られていなくても、このポリシーはスクリーンを通ることが許される。中にキャリアを含まないスクリーンは、そのポリシーがどのキャリアを含んでいるかには関係なく、どんなマッチングポリシーも通ることが許される。同様に、中にキャリアを含まないポリシーは、自由なセッションアクセス（つまり、何時でも、コスト無しで使用可能なアクセス）に対応する。
【０１８２】
ここに詳述していないが、Ａｄｊ−ＴＲＩＢ−Ｏｕｔを作成するとき、効率の為にルートの集成を行うことも可能である。この手続きの詳細な記述は、Ｒｏｓｅｎｂｅｒｇらによって、「ＩＰ（ＴＲＩＰ）の上のテレフォニールーティング」、ＩＰＴＥＬワーキンググループインターネットドラフト（２０００年１１月）の中で提供されており、その内容をこの出願の一部とする。例えば、１−９７８のルートおよび１−９７８−２４６のルートが受け取られる場合、他のすべての属性が同じなら、それらは、より限定的でない１−９７８のルートへと結合される。１−９７８−２４０、１−９７８−２４１、１−９７８−２４２、１−９７８−２４３、１−９７８−２４４、１−９７８−２４５、１−９７８−２４７、１−９７８−２４８および１−９７８−２４９のポリシーが存在し、ここに無い１−９７８−２４６が受け取られた場合、それらは集成される。集成が行われた場合、ポリシーへの次の変更が行なわれる。即ち、もはや要求されないエントリは、除去され、より新しいエントリと置き換えらる。又、次の転送先サーバが、このサーバに変更される。更に、要素集成の属性がセットされる。
【０１８３】
この集成では、外部と共有可能なポリシーは等しい必要がある。キャリア、時刻、曜日、コストおよびＱＯＳ属性が、外部ピアと通信するのに使用されない場合、これらは集成の際に考慮されない。
【０１８４】
一旦、内部初期化が完了したならば、すべてのローカルピアからの、すべての注流が完了したと仮定して、その時、ＴＲＩＢ内容がすべて調べられる。
【表１９】
2005502219.tif 000021
【表２０】
2005502219.tif 000022
【表２１】
2005502219.tif 000023
【表２２】
2005502219.tif 000024
【表２３】
2005502219.tif 000025
【表２４】
2005502219.tif 000026
【０１８５】
隣接したピアから受けたポリシーはローカルＴＲＩＢだけに入力されるので、Ｅｘｔ−ＴＲＩＢおよびローカルＴＲＩＢは、最後のルート（つまり、「発信：＊」、「着信：１−９７８」、sr3.acme.com）を除いて同一である。いずれの決定処理が適用される前に、それらは他のすべてのローカルピアに伝搬される。ローカルＴＲＩＢエントリのすべてが、（同じＩＴＡＤの内の）ローカルピアのすべてに送られた場合、次のステップは、外部のポリシーを交換するプロセスを始めることである。外部ポリシーの交換は、シーケンス番号が含まれていないことを除いて、注流プロセスと同様である。また、スクリーニングプロセスを経て残ったポリシーの各々は、ローカルで使用されるすべての属性が削除され、外部ピアへ送られる。外部のＳＲがＳＲ２０００に接続した場合、次の「アップデート」メッセージは、sr.acme.com ２０００年から、アドレスexternal.carrier.com ２００３を持つ外部のＳＲまで送られる。
【０１８６】
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-781 []
次の転送先サーバ： sip:sr.acme.com
広告パス： 2024
ルートパス： 2024
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-781-933 []
次の転送先サーバ： sip:sr.acme.com
広告パス： 2024
ルートパス： 2024
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1-978 []
次の転送先サーバ： sip:sr3.acme.com
広告パス： 2024
ルートパス： 2024
【０１８７】
このピアと共有するルートを含んでいる外部ピアの夫々に対して、１つのＡｄｊ−ＴＲＩＢ−Ｏｕｔが存在する。ＩＡＮＡがまだＴＲＩＰに対する現在の拡張を採用していないので、発信アドレスとキャリアの属性は、「アップデート」メッセージから除外される。もし、ポリシーの着信アドレス（ＵＲＩ）のアドレスファミリーコードが「ｔｅｌ：」の形式で２５４だったとすると、到達可能なルート属性にそれを加える前に、それはＰＯＴＳあるいはルーティング番号フォーマットに変換されなければならない。インターネットアドレスを含むポリシーの着信アドレスが、「ｔｅｌ：」の形式でなければ、到達可能なルート属性を実装できない。到達可能なルート属性を実装できない場合、「アップデート」メッセージは送られない。もし、以前のＴＲＩＰ仕様に記述されたバージョンネゴシエーション中に、このピアで、それらのパラメタが処理可能であったとすれば、それらはそのまま送られる。
【０１８８】
外部のＩＴＡＤにポリシーを送る為に、（外部のＩＴＡＤに理解されない）キャリア属性が削除される場合、この属性によって定義され許可された時間フレームが、その外部ピアに何らかの形で送られることを保証する為に、起点ＩＴＡＤのＳＲに対して追加の処理が行われる。この処理は、現在の時間がキャリア属性で定義された時間フレームに入る時に、外部のＩＴＡＤへのポリシーを広告することと、現在の時間がキャリア属性で定義された時間フレームを過ぎた場合、ＩＴＡＤからポリシーを取り下げることを含む。
【０１８９】
上記の第１の「アップデート」メッセージに関して、ＩＴＡＤ２０５５に広告されたポリシーは、「到達可能：１−７８１」であるが、それが基づいた実際の内部ポリシーは、土曜日（一日中）だけ有効なキャリアエントリ（ＬａｓｔＧｅｎ）を含んでいる。したがって、土曜日の午前１２：００に、このポリシーはＩＴＡＤ２０５５に広告され、そして、日曜日の午前１２：００に、取り下げられる。キャリア属性のＩＡＮＡ承認は、この追加処理の必要性は除外するかもしれない。承認に際して、異なるＩＴＡＤによって定義され、同じ名前を持つキャリアを識別する何らかの方法が必要となる（例えば、キャリアを識別する為にＩＴＡＤおよびキャリア名を使用する等）。
【０１９０】
広告パスおよびルートパス属性は、後で、ＴＲＩＰ「アップデート」メッセージの中で詳述される（それらは、ローカルポリシー管理において無意味であるので、これまでは省略された）。基本的に、ルートパス属性は、このルートを使用してメッセージを送る際に通過するＩＴＡＤを識別しており、広告パス属性は、広告に含まれるルーティング情報を通過させたＩＴＡＤを識別する。基本的に、このパス中のＩＴＡＤは、広告パス中のものの部分集合である。
【０１９１】
これらのポリシーを受け取ってから、external.carrier.comのＴＲＩＰサーバは、ネットワークを介して、sr.acme.comのサーバへ、マッチングアドレスを伴う呼び出しを送る。さらに、外部キャリアからのポリシーは、 我々のＳＲ、sr.acme.comに送られる。ここで、ＳＲは、次の「アップデート」メッセージを受け取ると仮定されている。
【０１９２】
ＴＲＩＰアップデート：
取り下げられたルート： None
到達可能なルート： 1
次の転送先サーバ： sip:external.carrier.com
広告パス： 2055
ルートパス： 2055
【０１９３】
この外部の、或いは外のポリシーの処理は、次のステップからなる。
１．適切なＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎへ、ポリシー（生の形式）を加える。
２．現在のＳＲ２０００への参照又は／および巡回参照の為のスキャンを行う。
３．情報を、境界内のポリシースクリーンと比較して、要求される受信ポリシーの受理や制限を行う。
４．受理されれば、ポリシーにデフォルトパラメタ（例えば、デフォルトの発信アドレス、キャリア、時刻、曜日、コストおよびＱＯＳ）をすべて加えて、指定の通りに、受信ルートへローカルポリシーを加える。もし、ポリシーのデフォルト属性が有効であれば、キャリア、時刻、曜日、コストおよびＱＯＳのデフォルトパラメタは、単に、追加されるだけである。
５．ＳＲ２０００のＥｘｔ−ＴＲＩＢにポリシーを加えること。
６．ＳＲ２０００の現在の内部ピアのすべてにポリシーを送ること。
【０１９４】
上記の第一のステップで、ポリシー（生の形式で）がＳＲ２０５５：７８９ ２００３のＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎに追加される。重複を検知するシーケンス番号がないので、既にＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎにポリシーが既に存在する可能性がある。第一のステップでは、Ｅｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎをスキャンし、重複エントリがないことを確認する。外部ピアから受け取った要素は、このポリシーにとって同一であれば、すべて重複とされる。すべての検知された重複が廃棄される。そうでなければ、以下に示された通り、ポリシーはＥｘｔ−Ａｄｊ−ＴＲＩＢ−Ｉｎに追加される。
【表２５】
2005502219.tif 000027
【０１９５】
広告パスおよびルートパス属性も、Ｅｘｔ−ＴＲＩＢに格納される。第２のステップは、循環的なパスを検知する為に、これらの属性を調べる。それは、リスト（それはルートがループしていることを示す可能性がある）中の現在のＩＴＡＤの存在を探すことである。ループが検知された場合、そのルートはＥｘｔ−ＴＲＩＢから取り除かれる。最短のパスを選択する為に、他のタイプのスキャンを実行することもある。特定のＩＴＡＤへのより短いパスが見つかった場合、より長いエントリの広告パスは、より短いパスへアップデートできる。このアップデートは、内部で処理されるルーティングエントリの数を小さくし、ルーティングポリシーには影響しない。第３のステップでは、このＳＲのための入力スクリーニングコンフィギュレーションが調べられる。ＩＴＡＤ２０５５のための境界内のポリシースクリーンデータは以下のとおりである：
【０１９６】
境界内スクリーン#1
作成者： Cliff
追加日： 10/01/2000
有効日付／時間： 0
無効日付／時間： 0
許可
部分的着信アドレス： *
ポリシー属性数： 1
第１ポリシー属性
キャリア： External
サービス状態： 有効
時間： 0000-2400
曜日： U-S
コスト: 0.20
QoS: SHQ, G.711
【０１９７】
この境界内のポリシースクリーンに対して、受け取られ、格納されたポリシーを処理する際に、好ましくは、下記タスクが実行される。
【０１９８】
・部分的着信アドレスのマッチングを実行する。部分的な一致がない場合は、Ｅｘｔ−ＴＲＩＢにポリシーを加えない。
・境界内ポリシーでの許可／拒絶パラメタをチェックする。
・パラメタが拒絶にセットされている場合、Ｅｘｔ−ＴＲＩＢにポリシーを加えない。
・このポリシーと共に受信される無効でないキャリアが、境界内のスクリーン属性にリストされていない場合、Ｅｘｔ−ＴＲＩＢにポリシーを加えない。
【０１９９】
発信アドレスが存在しない場合（もし、外部ピアが、同じように拡張されたＴＲＩＰを使用していない限り、この場合が成り立つ）、ポリシー内の発信アドレスを、境界内のポリシースクリーン内の発信アドレスにセットする。又、発信アドレスが存在しない場合、＊のワイルドカードインジケータをセットする。
【０２００】
・もし、受信ポリシーでまだ実装されていなければ、境界内のポリシーから、有効日付／時間、非活性化日付／時間およびデフォルトの属性に値を入れる。
【０２０１】
・もし、受信ポリシーがこれらのパラメタのうちのいくつかを備えている場合、最も限定的な（つまり、最新の活性化日付／時間、その、最も早い非活性化日付／時間、最も高いＱＯＳ、最も限定的な時刻／曜日パラメタおよび最も高いコスト）ものをパラメタに使用する。
【０２０２】
境界内のポリシースクリーンに対して、デフォルトセッティング（キャリア属性を含んで）および最も限定的な処理を用いて、この格納されたポリシーが調べられた後、ポリシーはＥｘｔ−ＴＲＩＢに追加される。
【表２６】
2005502219.tif 000028
【０２０３】
これらのポリシーの各々がＥｘｔ−ＴＲＩＢに加えられる時、このＳＲは、次の転送先として置き換えられ、ポリシーの各々は、「アップデート」メッセージによって、注流メカニズムを使用する内部ピアの各々へ転送される。ＳＩＰプロキシサーバが生成したルートクエリを満たすために、このＳＲの上でＴＲＩＰ ＬＳによって使用されるローカルＴＲＩＢは、外部ピアと内部ピアからの処理されたルートを含んでいる。
【表２７】
2005502219.tif 000029
【０２０４】
複数の外部ピアがある場合、上記のように、境界外のスクリーニング基準に基づく外部ポリシーからではない夫々の外部ピアのＡｄｊ−ＴＲＩＢ−Ｏｕｔに、ポリシーが追加される。この例においては、１つの外部のＩＴＡＤだけがあるので、外部のＩＴＡＤ２０５５のポリシー（「発信：＊」、「着信：１」、external.carrier.com）は、ＩＴＡＤ２０５５のＡｄｊ−ＴＲＩＢ−Ｏｕｔに追加されない。
【表２８】
2005502219.tif 000030
【０２０５】
現在のシステムに含まれる可能性のある２つの追加のポリシー変更として、ルートポリシーの取消し、隣接通信エラーポリシーがある。ルートポリシー取消しの変更は、そのルートがサービスから取り除かれるということ以外は、ルートを加えることと同一である。新しいルートの広告のように、集成のプロセスおよびピアのアップデートが同じように生じる。アドミニストレータはいつでもルートを取り消すことができる。
【０２０６】
ＴＲＩＰサーバが、ルートを利用不可能と宣言する程長い間、ピアと通信することができず、隣接通信エラーポリシー変更は、ルートを除去する。この状況の結果、この隣接したルータによって管理された、次の転送先サーバを利用するか通過するすべてのルートが除去される。
【０２０７】
下記は、ＳＩＰプロキシサーバおよびその機能の詳細な記述である。既に図６の中で示されているように、ＳＩＰプロキシサーバのコンフィギュレーションが行われているかどうか確かめる為に、チェックが実行される。ＳＲが、任意の通信セッションの管理を行うことになると、ＳＩＰプロキシサーバのコンフィギュレーションが行われ、そのＳＩＰプロキシサーバは有効とされる。ＳＩＰプロキシサーバは、業界標準として一般に認められている。
【０２０８】
ＳＩＰプロキシサーバはＳＩＰメッセージを受け取り、それらを処理する。発明の好ましい実施形態と関係のある特定の処理は、集めたＴＲＩＢデータベースの「招待」、および「ＢＹＥ」メッセージを処理する為のメカニズムに関する。加えて、一旦、通信セッションが確立された場合に、後続のＲＴＰパケットのフローの制御を行うための方法および装置の詳しい説明が提供される。別の発明性のある特徴は、統計的方法の実装、および他のインテリジェントなルーティングとルート迂回方法である。それらは、この説明の中で列挙される。さらに、下記は、ダウンタイムを最小限にし、スケーラビリティを最大にし、メンテナンス中のルートフラッピングを防ぐために、ＳＩＰプロキシサーバのクラスタコンフィギュレーションを管理する方法について記述する。
【０２０９】
図１２Ａおよび１２Ｂは、ＳＲの内に含まれているＳＩＰプロキシサーバによって使用されるハイレベルの処理ステップを示すフローチャートである。発明の好ましい実施形態によれば、ＳＲは、パラメタ「ｅｎｄ＿ｏｆ＿ｓｔａｒｔｕｐ＿ｇｕａｒｄ＿ｔｉｍｅ」によってプログラム可能な一定時間の間待機する（ブロック２２０２）。好ましくは、一定時間が指定されない場合、６０秒のデフォルトがある。この遅れは、ＴＲＩＰ ＬＳが、まだ受け取られていない他の内部ピアから注流させられているすべてのルートを受け取ることを可能にする。
【０２１０】
ブロック２２０４に示されているように、一旦、ＴＲＩＢが受け取られ処理され、ＳＲが所定の時間、待機したならば、ＳＲのＳＩＰプロキシサーバはそのＵＤＰソケットを開きリッスンを開始する。好ましくは、ＳＲが準備できる前に受け取られたリクエストは、サービスが利用不可能であることを示すレスポンスで答える。ＳＲが準備できた後、ＳＲは、ＳＩＰメッセージが到着（２４７）するのを待ち受ける為のリッスンを開始する（ブロック２２０６）。
【０２１１】
ＳＩＰメッセージの受け取ってから、受け取られたＳＩＰメッセージのタイプに基づいて、１つの分岐が実行される。メッセージタイプは「招待」（ブロック２２０８）。「ＢＹＥ」（ブロック２２１２）、「登録」（ブロック２２１４）。「ＡＣＫ」（ブロック２２１６）、「キャンセル」（ブロック２２１８）および「オプション」（ブロック２２２２）を含んでいる。ブロック２２２３によって示されているように、「招待」メッセージ以外のメッセージは、標準のＳＩＰに従って処理される。本発明の主な目的のうちの１つは、ＳＩＰ「招待」メッセージを送ることである。「招待」分岐は、図１２Ｂに記載されている。図１２Ｂを参照すれば、次のステップは、ＳＩＰ「招待」メッセージを解析し、ルーティング（ブロック２２３２）のために使用できるコンポーネントのすべてを得ることである。特に、発信アドレスと着信アドレスが抽出される。ルートの選択に用いられる他の情報は、「招待」メッセージのＳＤＰ部分からのデータ、要求されたメディアフローのタイプ、所望の符号づけのタイプ等を含む。
【０２１２】
そして、ブロック２２３４によって示されているように、受理可能なルートのリストを見つける為に、ローカルＴＲＩＢがスキャンされる。受理可能なルートは、次の基準を満たすものを含んでいる。即ち、部分的発信アドレスが一致したルート、部分的着信アドレスが一致したルート、時間や曜日のエントリを持つキャリアの少なくとも１つを持つルートとキャリアのいずれかを含むルート、或いはＱＯＳの最小の要求を満たすルートである。この時点で、取得可能なルートがすべて得られている。その後、可能なルートは優先度の順にソートされる。
【０２１３】
可能なルートの優先度順のソートは、次の規則のセットに基づく。
【０２１４】
１．発信アドレスフィールドの中の、最適または最長の一致を持つルートは、トップへソートされる。この規則によれば、逆の順にドットで区分されたドメイン名とのマッチングを行うアドレス／ＵＲＩマッチングスキームあるいは部分的な電話番号マッチングのいずれかを、最長の一致を得る為に使用される。下記は、このマッチングスキームの例を示す。
【０２１５】
電話番号１−６１７−２４６−１２３４からの「招待」が到着し、コンフィギュレーションの行われたポリシーは次のものを含んでいれば、１−６１７−２４は最適で最長の一致と考えられる。
【０２１６】
・tel:1
・tel:1-617
・tel: 1-617-24
・tel: 1-617-247
【０２１７】
ドメインアドレスについては、最適または最長である一致は、（逆順で）等しいドメインに基いている。
【０２１８】
したがって、「招待」が発信側表示、sip:patrick@acmepacket.comを含み、コンフィギュレーションの行われたポリシーは次のものを含んでいる場合、ベースドメイン「com」が等しく、さらに、次に高いアドレス「acmepacket」が等しいので、アドレスsip:patrick@acmepacket.comは、最適と最長である一致と考えられる。
【０２１９】
・sip:com
・sip:acme.com
・sip:acmepacket.com
・sip: sales.acmepacket.com
発信アドレスから、次の場合、acme.comは、この発信アドレスをソートする為に使用される。
・1-781-933-6166@acme.com
【０２２０】
もし、「招待」メッセージの発信アドレスが、部分的に一致する起点電話番号と、部分的に一致するドメインアドレスの組み合わせを有するならば、好ましくは、ドメインアドレスのマッチングが、ソートのために使用される。
【０２２１】
２．同じ発信アドレスを持ったルートの各セット内で、着信アドレスフィールドが最適または最長の一致を持つルートがソートされる。もし、「招待」メッセージの着信アドレスが、部分的に一致する起点電話番号と部分的に一致するドメインアドレスの組み合わせを有している場合、ドメインアドレスのマッチングが、ソートのために使用される。
【０２２２】
３．発信アドレスと着信アドレスの同一のフィールド値を持つルート内では、ルートは、最も高いコストから最も低いコストに、コストによってソートされる。
【０２２３】
４．同一の発信アドレスと着信アドレスおよびコストを持つルートの各セット内では、次の転送先サーバとしてこのＳＲを持つルートがソートされる。これらはこのＳＲのゲートウェイのうちの１つで終了する、ローカルルートである。ローカルルートを常に最初に選ぶことによって、リクエストをローカルに送らずに、２つのＳＲが、セッションリクエストを投げ合うという、潜在的なピンポンシナリオが回避される。
【０２２４】
５．既に「招待」リクエストの処理に関係したＳＲに関連付けられたルートは除去される。これは、ローカルの制約を超えたので既に「招待」を転送したＳＲに、その「招待」が戻されるのを防ぐ。そうでなければ、第２のピンポンシナリオが、生じることがある。即ち、最適の選択のＳＲが過重負担となり、そうとは知らない別のＳＲへ「招待」を転送し、その結果、それを送り返したりする。
【０２２５】
そして、優先の順にソートされた可能なルートのリストがある。このリスト中の各ルートは有効なルート（ブロック２２３６）である。しかし、いくらかは、他のものより、質あるいはコストの異なるレベルを持つものもある。例えば、キャリアＭＣＩを使用し、sr4.itad.comで処理され、１−７８１−９３３−６１６６（発信アドレス）から開始され、１−６１７−５５５−１２１２（着信アドレス）終了するセッションのルート捜索から、次のような可能なルートのリストが考えられる。
【０２２６】
FROM: 1-781  TO: 1  NEXT HOP: SR4.ITAD.  MCI/U-S/0000-2400/COM$0.02/SHQ-G711
FROM: 1-78  TO: 1-617  NEXT HOP: SR2.ITAD.  MCI/U-S/0000-2400/COM$0.01/SHQ-G711
FROM: 1-78  TO: 1-617  NEXT HOP: SR4.ITAD.  MCI/U-S/0000-2400/COM$0.02/SHQ-G711
FROM: 1-78  TO: 1-617  NEXT HOP: SR3.ITAD.  MCI/U-S/0000-2400/COM$0.02/SHQ-G729
FROM: 1-78  TO: 1  NEXT HOP: SR4.ITAD.  MCI/U-S/0000-2400/COM$0.02/SHQ-G711
FROM: 1  TO: 1-6  NEXT HOP: SR4.ITAD.  MCI/U-S/0000-2400/COM$0.02/SHQ-G711
FROM: 1  TO: 1  NEXT HOP: SR4.ITAD.  MCI/U-S/0000-2400/COM$0.02/SHQ-G711
【０２２７】
上記のリストによれば、終点で部分的に一致すると共に、発信アドレス（つまり起点番号）に最適に一致したルートは、トップへソートされている。上記のテーブル中の第２と第３のエントリは同じ発信アドレスと着信アドレスを持つが、異なる次の転送先サーバを持つことに注意されたい。ローカルの次の転送先サーバはリストのトップへソートされる。さらに、もし、このセッション「招待」リクエストが、以前にsr3.itad.comにあったならば、テーブル中の第３のエントリが廃棄されていたと考えられる。
【０２２８】
上記ソートプロセスの後に利用可能なルートがない場合、セッション「招待」は、利用可能なルートがないという通信内容を伴って発信側に返される。図１２Ｂは、ブロック２２４２および２２４４としてこのシナリオを示している。利用可能なルートがスキャンされた後、１つ以上のルートが残されている場合、プロセスはステップ２２３８に進められる。
【０２２９】
ブロック２２３８によって示されているように、最適のルートから始めて（ソートされたオーダーで）、各ルートは一度に１回づつ調べられる。各ルートは、そのルートがローカルかどうかを決める為に分析される（ブロック２２４２）。それは、このＳＲが、直接ＳＩＰエージェントを管理していることを意味する。次の転送先サーバが、その中にＳＩＰエージェントグループを持っていれば、ルートはローカルであり、ブロック２２４６で示されているように制御が移る。そうでなければ、ルートはリモートであり、ブロック２２４４によって示されているように制御が移る。
【０２３０】
例えば、ハントストラテジーが使用されており、そこに、ＳＩＰエージェントグループの中に複数のＳＩＰエージェントがあれば、グループ中の最初のＳＩＰエージェントは、グループ中の第２のＳＩＰエージェントを探す前に、その制約を完全に適用すべきである。制約４１６（図３Ｂ）は、物理的制限に必ずしも結び付けられない勧告的制限であるが、ネットワーク立案ベースの、コンフィギュレーションに結び付けられている。例えば、一方通行の境界外の呼び出しを受け入れ可能な設定を持つ２４のポートを備えたゲートウェイは、２４という値を持つ勧告的制限を有しており、２方向の呼び出しを受け入れ可能な設定を持つ同じゲートウェイは、１２という値を持つ勧告的制限を有している。この制約は、このＳＩＰエージェントのサポート可能なセッションの整数値である。
【０２３１】
特定のＳＩＰエージェントのセッションの数を決定する為に、ＳＲは、どれだけのセッションが特定のＳＩＰエージェントに対して設定されるかに関する統計値を保持しなければならない。したがって、データテーブルが、各ＳＲの内に保持される必要がある。
【表２９】
2005502219.tif 000031
【０２３２】
表２９に示すテーブル６は、特定のＳＩＰエージェントのキャパシティーに関する統計値を示す。特定のＳＩＰエージェントをスキップする為に、勧告的制限が使用されることに注意されたい。したがって、制約のいずれかを超えた場合、その制約を超えなくなるまで、そのＳＩＰエージェントは考慮されない。
【０２３３】
起こりうる制約は、これまでにも特定しているが、テーブル６の統計値の組み合わせも含まれている。もし、制約が形成されておらず、ＳＩＰエージェントグループ中の最初のＳＩＰエージェントが、利用可能なリソースがないという通信を返す場合、そのＳＩＰエージェントグループは一定期間の間、無効になる。この期間はプログラム可能で、上記テーブルの中で再開時間として示されている。ルートが選択されるかどうか決める為に統計値（上記のテーブル中の）を調査する段階は、図１２Ｂの中のブロック２２４８として示されている。
【０２３４】
図１３Ａおよび１３Ｂは、発明の好ましい実施形態による、ルートを転送するＳＩＰエージェントのグループ内の特定のＳＩＰエージェントを決める為のアルゴリズムを示すフローチャートである。ブロック２３０２によって示されているように、現在の日付および時間が得られる。現在の時間は２つの別個の用途のために使用される。現在の時間の第１の用途は、特定のＳＩＰエージェントの包含か排除に関する情報用のセッションルータデータテーブル中の再開時間の欄と、現在の時間を比較することである。現在の時間の第２の用途は、そのＳＩＰエージェントが選ばれた後、特定のＳＩＰエージェントのためのセッションルータデータテーブル中の最後の使用の欄に日付を入力することである。ブロック２３０４によって示されているように、次のステップは、ＳＩＰエージェントグループを、分解して、ＳＩＰエージェントの完全に解決されたリストを得ることである。各グループは追加のグループあるいはＳＩＰエージェントを含んでいる。好ましくは、ＳＩＰエージェントのこのリストは、ＳＩＰエージェントグループのエージェントリスト内で、ＳＩＰエージェントが出現する順番で、保持される。いくつかのグループの中で、ＳＩＰエージェントの参照がある場合、それは一度だけリストされる。
【０２３５】
例：
Group 1: Hunt
1. Gateway 1
2. Gateway 2
3. Gateway 3
Group 2: Proportional Distribution
1. Gateway 1
2. Gateway 2
Group 3: Least Busy
1. Group 1
2. Group 2
【０２３６】
上記の通りリストされた理論的なグループでは、グループ１がハントストラテジーを使用し、３つのゲートウェイを備えており、グループ２は比例分配ストラテジー（最も古いものの利用）を使用し、２つのゲートウェイを備えており、グループ３は最暇ストラテジーを使用し、２つのグループを含んでいる。完全にグループ３を解決する場合、下記は、そのＳＩＰエージェントグループの分解を示す。
【０２３７】
Group 3: Least Busy
1. Gateway 1
2. Gateway 2
3. Gateway 3
【０２３８】
上記の例において、ゲートウェイ１およびゲートウェイ２は繰り返されない。どれほど多くのグループのネスティングが生じても、当初のＳＩＰエージェントグループストラテジーだけが使用されることに注意されたい これにより、ブロック２３０４で実行されたプロセスの終わりに、ＳＩＰエージェントグループの完全なリストがある（夫々のグループが、それを含むＳＩＰエージェントグループの中で参照される順番でリストされる）。その後、ブロック２３０６によって示されているように、ＳＩＰエージェントのリストが使用される。順番付けされたリスト中の各ＳＩＰエージェントのために、コンフィギュレーションの行われた制約の確認がなされる（ブロック２３０８）。この確認は、次の可能な制約を評価することを含んでいる。即ち、再開時間値が、現在の時間の後あるいは等しいことと、ＳＩＰエージェントのバーストレートは、確立された限界を超えるか等しいことと、ＳＩＰエージェントの保持されたセッションリクエストレートは限界を超えるか等しいことと、セッションカウントの合計は、確立された限界を超えるか等しいことである。各ＳＩＰエージェントのために適用される他のタイプの制約も存在することに注意されたい。例えば、観察される最大ジッタ、観察される最大待ち時間、およびパケット往復時間を、各セッションセットアップで確認されるべき制約としてセットしてもよい。
【０２３９】
可能な制約のプール中のいずれかの制約を超えた場合、現在のＳＩＰエージェントは、ＳＩＰエージェントのリストから除去される（ブロック２３１２）。ＳＩＰエージェントが削除された後、リスト中でこれ以上のＳＩＰエージェントがなくなるまで、ブロック２３０６の機能は、次のＳＩＰエージェントを調べる為に繰り返される。制約を超えない場合、ＳＩＰエージェントはリストに残る。また、プロセスは次のＳＩＰエージェント（ブロック２３１４）を見続ける。すべてのＳＩＰエージェントについて、制約の評価が行われた時、その結果は、確立している制約のうちのどれも超えていないＳＩＰエージェントのリストとなる。その後、ブロック２３１６によって示されているように、チェックを行って、制約チェックをパスした少なくとも１つのＳＩＰエージェントがあるかどうか決める。ＳＩＰエージェントがみな制約テストに失敗したならば、制御がブロック２３１８へ移る。そこでは、ルートが利用可能ではないことを示す。ブロック２３１８は、図１２Ｂの中のブロック２２５２に関係する。このシナリオの次の処理は、ルートの除去と、次の可能なルートの使用である（ブロック２２５２、図１２Ｂ）。１つのＳＩＰエージェントがリストに残れば、制御がストラテジーのタイプに基づいて適所に移動される（ブロック２３２２）。ハントストラテジーを使用する場合、ブロック２３２４の中で示されているように、第１のＳＩＰエージェントが選ばれる。ラウンドロビンストラテジーを使用する場合、使用頻度が最低か最も古い「最後の使用時間」を持ったＳＩＰエージェントが選ばれる（ブロック２３２６）。比例する分配ストラテジーについては、各ＳＩＰエージェントは、最大の同時のセッションの為のコンフィギュレーションの行われた制約を備えている。同時セッションは、最大の累積的なセッションを得る為に蓄積される（ブロック２３２８）。
【０２４０】
例：
Gateway 1:10-session limit; Cumulative Sessions: 10
Gateway 2: 20-session limit; Cumulative Sessions: 30
Gateway 3: 15-session limit; Cumulative Sessions: 45
【０２４１】
上記の例によれば、リスト中のＳＩＰエージェントが、すべて累積リストに加えられるまで、上記プロセスは継続する。二度以上現われるＳＩＰエージェントは、現われるだけカウントされる。最大の累積的なセッション数は、好ましくは、リスト中の最後のＳＩＰエージェントに属する累積的なセッションの数である。１と最大の累積セッション数の間のランダムな数が選ばれる。上記例において、これは、同程度の可能性のある、１から４５の中の１つのランダムな数である。１から１０については、ゲートウェイ１が選ばれ、１１から３０については、ゲートウェイ２が選ばれ、３１から４５については、ゲートウェイ３が選ばれる。
【０２４２】
上記プロセスは、コンフィギュレーションの行われたセッションの数に基づいて、比例分配を行う。これは、各ＳＩＰエージェントのポートの数に比例する、セッションリクエストの分配を可能とする。ブロック２３３２は、最暇ストラテジーを示し、そこでは、許可されたセッションの合計に対するアクティブなセッションの比率が最低であるＳＩＰエージェントを、リスト中のＳＩＰエージェントのすべてから調べられる。好ましくは、この比率は、境界内と境界外のセッションを加え、その結果を許可されたセッションの合計で割ることで、計算される。
【０２４３】
ブロック２３３４は、最低持続レートストラテジーを示す。このストラテジーでは、確立されているセッションに対して、最低持続レートのＳＩＰエージェントを、リスト中のＳＩＰエージェントのすべてから調べられる。ＳＩＰエージェントは、ストラテジーに基づいて使用する為に選ばれているので、ブロック２３３６によって示されているように、ＳＩＰエージェントの中の統計値を更新して、試みのために選ばれているＳＩＰエージェントに反映させる。より詳しくは、例えば、統計値は以下のとおりである。
【０２４４】
・再開するべき時間：変更はない。
・最後の使用：現在の時間へのセット
・境界外のセッションの番号：インクリメントされた。
・最後５分間内での現在の持続レート：スライディングウィンドウに加える。
・最後の３０秒間内でのバースト  ・レート：スライディングウィンドウに加える。
・リソース利用不可能と検知された最後の日時：変更はない。
・利用可能なリソースが検知しなかった時、セッションズの合計変更はない。
【０２４５】
ブロック２３３８によって示されているように、統計値を更新した後、制御は、図１２Ｂの処理へ戻され、そこで利用可能なルートが選択される。特に、ブロック２３３８は、図１２Ｂのブロック２２５４に関連し、そこで利用可能なルートが返される。その結果、ローカルのＳＩＰエージェントへのルートが生成される（ブロック２２５４（図１２Ｂ））。ＳＩＰプロキシサーバは、返されたＳＩＰエージェントに関連したＳＩＰプロキシサーバへ、「招待」メッセージを転送する。直線パス上のＳＩＰプロキシへのパス上の複数のＳＩＰエージェント経由で、着信側ＳＩＰエージェントへ、ＩＮＶＩＴＥメッセージが送信され得る。
【０２４６】
「ＢＹＥ」メッセージが以前に設立されたセッションのために受け取られる場合、アクティブなセッションのカウンターがデクリメントされる。ルート記録機能によって、「招待」メッセージによって得られた同じ直線パスによって、「ＢＹＥ」メッセージが返されることが保証される。
【０２４７】
要約すれば、上記の開示により、順番に、複数のルートを選択し処理する機能が教示される。そこでは、様々な配布ストラテジーを使用して、一組の（さもなければ同等の）ＳＩＰエージェントから選択が行われる。このプロセスは、その後のＲＴＰフローのパスの管理に引き続く。
【０２４８】
（メディアフロールーティング）
次に、多重ドメインネットワークを通るパスの選択を説明する。あるしきい値（それは、様々なＩＰネットワーク間の高品質境界を作る為に使用される）によって、リアルタイムパケットフローをガイドすることが可能である。このメカニズムなしでは、パケットが、ネットワークが許すどの方向へでも向かってしまう。パケットがとる実際のルートを制御する為のいくつかの技術がある。ここで使用される最も有望なメカニズムは、多重プロトコルラベルスイッチング（ＭＰＬＳ）である。
【０２４９】
ＭＰＬＳが遭遇した問題のうちの１つは、ネットワーク進入ポイントで、通常、前方の同値クラス（ＦＥＣ）に結び付けられるということである。業界で知られているように、前方の同値クラス（ＦＥＣ）とは、その輸送のための同じ条件を共有するパケットのグループを表現するものである。そのようなグループ中のパケットはすべて、終点に向かう途中、同じ処理を受ける。従来のＩＰフォワーディングに対立するものとして、ＭＰＬＳでは、パケットがネットワークに入る際に、特定のＦＥＣへの特定のパケットの割り当ては１度だけ行われる。
【０２５０】
現在のシステムにサポートされた通信装置の多くは、他の目的のために使用される。例えば、ウェブを「サーフィンする」一方で、リアルタイムセッション指向のコミュニケーションを行うために、コンピュータが使用される。残念ながら、ＭＰＬＳタグを、どのようなケースを適用すべきかが明らかではない場合がある。したがって、パケットにタグを付けるアプリケーション特有の性質は、現在のシステムの多くの利点のうちの１つといえる。さらに、このシステムは、非ＭＰＬＳベースのネットワークのためにも解決策を示す。
【０２５１】
ＲＴＰフローが、どのように管理可能かを理解する為には、ＳＩＰシグナリングによるセッションリクエストベースに基づくネットワークアドレストランスレーションを実行する機能も理解すべきである。図１４は、ＳＲの中のメディアルーティングを通じて、ＲＴＰフローがどのように管理されるかを示すブロックダイヤグラムである。メディアルーティングでは、ＳＩＰシグナリングによるセッションリクエストベースの、ネットワークアドレストランスレーション（ＮＡＴ）およびポートアドレストランスレーション（ＰＡＴ）と同等の機能が提供される。各ＳＲを通過する「ｅｎｄ−ｔｏ−ｅｎｄ」のコミュニケーションがある。使用するＳＲおよびゲートウェイの選択は、上記の通りに実行される。
【０２５２】
個別の高品質ネットワークを介してセッションのメディアフローのルーティングを行う為に、ＳＲは２つの別個のネットワークに接続されている。１つのネットワークはＳＩＰプロキシサーバと通信し、別のネットワークインターフェイスが高品質トランスポートネットワークに接続されている。ＳＲの内では、メディアフローのために使用される１組のＴＣＰ／ＩＰポートが形成される。好ましくは、各ネットワーク毎に１組のポートがある。これらのポートは、ＳＩＰプロキシサーバによって開始されたセッションのＲＴＰメディアフローの送受信のために割り付けられている。
【０２５３】
図１４は、それぞれのＳＲ２４０６、２４０８を介して、高品質トランスポートネットワーク経由で流れる、第１のエンドポイント２４０２と第２のエンドポイント２４０４（つまり、ＳＩＰ電話）の間のメディアフローを示す。好ましくは、ＳＩＰプロキシサーバが、各ＳＲ２４０６、２４０８の中に存在する。ラベルＡ、Ｂ、Ｃ、Ｄ、ＥおよびＦは、ＲＴＰパケットの送受信に使われるＲＴＰポートを示す。これらのポートはＩＰアドレスとポートの番号によって定義されるＴＣＰ／ＩＰポートである。エンドポイントが「招待」メッセージを送る場合、「招待」は起点エンドポイント２４０２のＲＴＰポートを含むＳＤＰ本体を含んでいる。終点エンドポイントからの「招待」に対するレスポンスは、ＳＤＰ本体（それは終点ＲＴＰポートＦを指定する）を含む。
【０２５４】
もしエンドポイントが直接通信すれば、第１のエンドポイント２４０２と第２のエンドポイント２４０４の間に１つのＲＴＰフローがある。パケットは、好ましくは、正常なＩＰルーティングによって（例えば公開のインターネットを介して）、エンドポイント間に流れる。メディアルーティングが含まれる場合、３つのＲＴＰフローがある。即ち、１）ＡとＢの間、２）ＣとＤの間、３）そしてＥとＦの間である。第１のエンドポイント２４０２でセッションが開始したと仮定すると、ＳＩＰ「招待」は、ＡとしてＲＴＰポートを指定する。第１のＳＲ２４０６のＳＩＰプロキシサーバが「招待」を処理する場合、それはメディアフローのために、ＲＴＰポートＢおよびＣを、第１のＳＲ２４０６に割り付ける。第１のＳＲ２４０６のＳＩＰプロキシサーバから、第２のＳＲ２４０８のＳＩＰプロキシサーバへ転送される「招待」中のＲＴＰポートは、Ｃにセットされる。第２のＳＲ２４０８のＳＩＰプロキシサーバが「招待」リクエストを処理する場合、ＲＴＰポートＤおよびＥは、第２のＳＲ２４０８に割り付けられる。第２のＳＲ２４０８のＳＩＰプロキシサーバから送られ、第２のエンドポイント２４０４に到着する「招待」は、ＲＴＰポートをＥとして指定する。第２のエンドポイント２４０４は、「招待」メッセージへのレスポンスの中で、ＦのＲＴＰポートを指定する。そして、第２のＳＲ２４０８のＳＩＰプロキシサーバは、第１のＳＲ２４０６のＳＩＰプロキシサーバに、レスポンスを返し、ＲＴＰポートをＤに変更する。その後、第１のＳＲ２４０６のＳＩＰプロキシサーバは、第１のエンドポイント２４０２、レスポンスを渡し、ＲＴＰポートをＢに変更する。第１のエンドポイント２４０２から見れば、フローはＡとＢの間にある。しかしながら、第２のエンドポイント２４０４から見れば、フローはＥとＦの間にある。したがって、エンドポイント２４０２、２４０４は、ＳＲが介在することに気づきない。
【０２５５】
ＳＲがＲＴＰフローをモニターし、待ち時間およびジッタを測定することに注意されたい。さらに、それらは、ＲＴＰフローがいつ終わるか検知し、その結果、ＳＩＰプロキシサーバでは、「ＢＹＥ」メッセージを送信する。
【０２５６】
（クラスタリング）
データベースサーバの採用によって、複数のＳＲは、コンフィギュレーションとポリシーのデータを共有することができる。ＳＲは、データベースサーバの中のコンフィギュレーションとポリシーデータの特定のセットを「予約」することができる。ネットワークの冗長性、信頼度およびスケーラビリティは、同じローカルポリシーを共有するＳＲをクラスタに分けることにより、達成することができる。したがって、複数のＳＲが、一組のＳＩＰエージェント（つまりゲートウェイ）の為に動作している時、単一のＳＲの損失は、ネットワークのルーティング能力に影響しない。
【０２５７】
図１５は、ＳＲＡ、Ｂ、Ｃのみを含むネットワークを示すブロックダイヤグラムである。ＳＲＡはゲートウェイＡＧ１およびＡＧ２に接続される。ＳＲＢはゲートウェイＢＧに接続される。そし、ＳＲＣはゲートウェイＣＧ１およびＣＧ２に接続される。図１６はルータＡ、Ｂ、Ｃのクラスタを使用した、同じネットワークをブロックダイヤグラムである。図１６では、クラスタＡがゲートウェイＡＧ１およびＡＧ２に接続され、クラスタＢはゲートウェイＢＧに接続され、クラスタＣはゲートウェイＣＧ１およびＣＧ２に接続されている。つまり、これらの例では、図１５が、Ａ、ＢおよびＣの３つのＳＲを含み、図１６は、夫々、３つのＳＲからなる３つのクラスタＡ、ＢおよびＣを含む。しかしながら、ネットワークやクラスタに存在するＳＲの数に制限がないことは理解すべきである。図１５および図１６は、単に例として設けられている。
【０２５８】
好ましくは、クラスタ中のＳＲは、クラスタ用のポリシーが格納されるデータベースサーバ（図１６では示されていない）を共有する。クラスタ中のＳＲは、基本的に同一であるが、ＳＩＰおよびＴＲＩＰフレームワークの内の独立したＳＲとして機能する。図１６によれば、３つのＳＲはすべて、他のＴＲＩＰピアである。しかしながら、クラスタ中に４つ以上のＳＲがあれば、クラスタを通過するルート広告の為に、少なくとも２つのパスがあり冗長性を確保するように、十分なＴＲＩＰ接続性が必要となる。各クラスタ間に２つのＴＲＩＰ接続があり、ルート広告を内部ＴＲＩＰ ＬＳに注流させるように２つのパスがあることに注意されたい。
【０２５９】
好ましくは、クラスタ中のゲートウェイおよびＳＲはゲートウェイは、それらゲートウェイが、クラスタのために単一のドメインアドレスを持つように、ＤＮＳラウンドロビンと同様の方法を使用するように、セットアップされる。ＳＩＰプロキシサーバがラウンドロビンリクエストを受け取る場合、セッションの将来のリクエストが適切なＳＲに行くように、その特定のアドレスによってゲートウェイへ応答する。
【０２６０】
本発明の上記実施形態、特に、任意の「好ましい」実施形態は、インプリメンテーションの単に可能な例であり、単に発明の原理についての明瞭な理解のために記載されている。多くの変形例および修正例が、発明の精神および原理から基本的に外れずに、発明の上記の実施形態に対してなし得る。そのような修正および変化はすべて、この開示の範囲および本発明に含まれ、かつ以下のクレームによって保護されるものである。
【０２６１】
本発明は図面に参照すれば、一層よく理解することができる。図面の要素は、大きさは必ずしも重要でなく、本発明の原理を明瞭に示すことに重点が置かれている。さらに、同様の参照番号がいくつかの図面の中で対応する要素を示す為に用いられている。
【図面の簡単な説明】
【０２６２】
【図１】図１は、発明の好ましい実施形態による複数のドメインを含む通信ネットワークを示すブロックダイヤグラムである。
【図２】図２は、ＳＩＰプロトコルを介して行われる対話を示すブロックダイヤグラムである。
【図３Ａ】図３Ａは、図１のネットワーク内にあるセッションルータ上に格納されたポリシーを示すデータマップのブロックダイヤグラムである。
【図３Ｂ】図３Ｂは、図３Ａに示されたデータマップの続きを示すブロックダイヤグラムである。
【図４】図４は、図１のネットワーク内にあるセッションルータ装置の構造を示すブロックダイヤグラムである。
【図５】図５は、図１および図４に示されたセッションルータのローカルメモリ内に常駐するソフトウェアシステム、又はプロトコルを示すブロックダイヤグラムである。
【図６】図６は、図１および図４のセッションルータの動作開始の際に、実行される動作を示すフローチャートである。
【図７】図７は、図１および図４のセッションルータによって使用されるポリシースクリーンを示すブロックダイヤグラムである。
【図８】図８は、図１および図４のセッションルータによって実行されるＴＲＩＰ決定プロセスによって定義されたロジックを示すブロックダイヤグラムである。
【図９Ａ】図９Ａは、図１および図４のセッションルータから送信されるか、あるいはそのルータに受け取られるＴＲＩＰ「アップデート」メッセージの主なコンポーネントを示すブロックダイヤグラムである。
【図９Ｂ】図９Ｂは、図９Ａの続きであるブロックダイヤグラムである。
【図１０】図１０は、図１および図４に示されているような、セッションルータを含むＩＴＡＤトポロジーの例を示すブロックダイヤグラムである。
【図１１】図１１は、与えられたポリシーが外部に広告されるかどうか決める為に、最適のマッチングスクリーンを使用し、図１および図４のセッションルータによって実行されるプロセスを示すフローチャートである。
【図１２Ａ】図１２Ａは、ＳＩＰメッセージを解析する為に、ＳＩＰプロキシによって行われる処理ステップを示すフローチャートである。
【図１２Ｂ】図１２Ｂは、図１１Ａの続きを示すフローチャートである。
【図１３Ａ】図１３Ａは、ルートを転送するＳＩＰエージェントのグループ内の特定のＳＩＰエージェントを決める為に行われるステップを示すフローチャートである。
【図１３Ｂ】図１３Ｂは、図１３Ａの続きを示すフローチャートである。
【図１４】図１４は、図１および図４のＳＲの中のメディアルーティングを通じて、ＲＴＰフローがどのように管理されるかを示すブロックダイヤグラムである。
【図１５】図１５は、図１および図４に示されているような、セッションルータを含むネットワークを示すブロックダイヤグラムである。
【図１６】図１６は、図１および図４に示されているような、ルータのクラスタを含むネットワークを示すブロックダイヤグラムである。
【図２】
2005502219.tif 000032
【図３Ａ】
2005502219.tif 000033
【図３Ｂ】
2005502219.tif 000034
【図４】
2005502219.tif 000035
【図５】
2005502219.tif 000036
【図６】
2005502219.tif 000037
【図７】
2005502219.tif 000038
【図８】
2005502219.tif 000039
【図９Ａ】
2005502219.tif 000040
【図９Ｂ】
2005502219.tif 000041
【図１０】
2005502219.tif 000042
【図１１】
2005502219.tif 000043
【図１２Ａ】
2005502219.tif 000044
【図１２Ｂ】
2005502219.tif 000045
【図１３Ａ】
2005502219.tif 000046
【図１３Ｂ】
2005502219.tif 000047
【図１４】
2005502219.tif 000048
【国際公開パンフレット】
2005502219.tif 000049
2005502219.tif 000050
2005502219.tif 000051
2005502219.tif 000052
2005502219.tif 000053
2005502219.tif 000054
2005502219.tif 000055
2005502219.tif 000056
2005502219.tif 000057
2005502219.tif 000058
2005502219.tif 000059
2005502219.tif 000060
2005502219.tif 000061
2005502219.tif 000062
2005502219.tif 000063
2005502219.tif 000064
2005502219.tif 000065
2005502219.tif 000066
2005502219.tif 000067
2005502219.tif 000068
2005502219.tif 000069
2005502219.tif 000070
2005502219.tif 000071
2005502219.tif 000072
2005502219.tif 000073
2005502219.tif 000074
2005502219.tif 000075
2005502219.tif 000076
2005502219.tif 000077
2005502219.tif 000078
2005502219.tif 000079
2005502219.tif 000080
2005502219.tif 000081
2005502219.tif 000082
2005502219.tif 000083
2005502219.tif 000084
2005502219.tif 000085
2005502219.tif 000086
2005502219.tif 000087
2005502219.tif 000088
2005502219.tif 000089
2005502219.tif 000090
2005502219.tif 000091
2005502219.tif 000092
2005502219.tif 000093
2005502219.tif 000094
2005502219.tif 000095
2005502219.tif 000096
2005502219.tif 000097
2005502219.tif 000098
2005502219.tif 000099
2005502219.tif 000100
2005502219.tif 000101
2005502219.tif 000102
2005502219.tif 000103
2005502219.tif 000104
2005502219.tif 000105
2005502219.tif 000106
2005502219.tif 000107
2005502219.tif 000108
2005502219.tif 000109
2005502219.tif 000110
2005502219.tif 000111
2005502219.tif 000112
2005502219.tif 000113
2005502219.tif 000114
2005502219.tif 000115
2005502219.tif 000116
2005502219.tif 000117
2005502219.tif 000118
2005502219.tif 000119
2005502219.tif 000120
2005502219.tif 000121
2005502219.tif 000122
2005502219.tif 000123
2005502219.tif 000124
2005502219.tif 000125
2005502219.tif 000126
2005502219.tif 000127
2005502219.tif 000128
2005502219.tif 000129
2005502219.tif 000130
2005502219.tif 000131
2005502219.tif 000132
2005502219.tif 000133
2005502219.tif 000134
2005502219.tif 000135
2005502219.tif 000136
2005502219.tif 000137
2005502219.tif 000138
2005502219.tif 000139
2005502219.tif 000140
2005502219.tif 000141
2005502219.tif 000142
2005502219.tif 000143
2005502219.tif 000144
2005502219.tif 000145
2005502219.tif 000146
2005502219.tif 000147
2005502219.tif 000148
2005502219.tif 000149
2005502219.tif 000150
2005502219.tif 000151
2005502219.tif 000152
2005502219.tif 000153
2005502219.tif 000154
2005502219.tif 000155
2005502219.tif 000156
2005502219.tif 000157
2005502219.tif 000158
2005502219.tif 000159
2005502219.tif 000160
2005502219.tif 000161
2005502219.tif 000162
2005502219.tif 000163
2005502219.tif 000164
2005502219.tif 000165
2005502219.tif 000166
2005502219.tif 000167
2005502219.tif 000168
2005502219.tif 000169
2005502219.tif 000170
2005502219.tif 000171
2005502219.tif 000172
2005502219.tif 000173
2005502219.tif 000174
2005502219.tif 000175
2005502219.tif 000176
2005502219.tif 000177
2005502219.tif 000178
2005502219.tif 000179
2005502219.tif 000180
2005502219.tif 000181
2005502219.tif 000182
2005502219.tif 000183
2005502219.tif 000184
2005502219.tif 000185
2005502219.tif 000186
2005502219.tif 000187
【国際調査報告】
2005502219.tif 000188
2005502219.tif 000189
2005502219.tif 000190