(57)【要約】【課題】  ネットワーク間の中間手段として基盤構成要素を提供する。【解決手段】  ＶｏＩＰ通信システムおよび方法の構成要素は、管理システムだけでなくマルチプロトコルセッションコントローラおよびマルチプロトコルシグナリングスイッチを含む。セッションコントローラは、呼を処理し、中を流れる呼に関与する。セッションコントローラは、ネットワークのエッジまたはＶｏＩＰネットワークのコアに存在する呼を処理する。セッションコントローラは、流入呼ピアとして着呼に対する呼ピアおよび流出呼ピアとして発呼に対する呼ピアにおいて呼を互いに対応付ける。呼ルーティングポリシーの集中化データベースは、セッションコントローラに設けられている。セッションコントローラは、音声と映像の両方に対するＳＩＰネットワーク（３０）からＨ．３２３ネットワーク（２８）への呼の、費用管理、トポロジ隠蔽、および相互作用または変換を提供する。【選択図】  図１
2008527798.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのネットワークに接続され、処理される呼に対する流入呼ピアを対応付けるように動作可能な少なくとも１つのセッションコントローラであって、当該呼に対する流出呼ピアを識別するように当該流入呼ピアをポリシーと一致させるように動作可能であるセッションコントローラと、
当該少なくとも１つのセッションコントローラに接続されているシグナリングスイッチと、
当該少なくとも１つのセッションコントローラの性能データを記録するために当該少なくとも１つのセッションコントローラに接続されている管理システムと、
呼のグループに対するポリシーを定義するために当該少なくとも１つのセッションコントローラによりアクセス可能なデータベースとを含み、
当該セッションコントローラが選択的メディアルーティングを行い、当該選択的メディアルーティングが、ピアおよびピアグループおよびレルムのうち少なくとも１つごとにメディアルーティングを設定するメディアルーティングポリシーの適用を含み、当該セッションコントローラが、（ピア／ピアグループ／レルム）内の呼に対する（ピア／ピアグループ／レルム）内ルーティングおよび（ピア／ピアグループ／レルム）間の呼に対する（ピア／ピアグループ／レルム）間ルーティングのうち１つを指定する、ネットワーク上のパケットデータのリアルタイム通信のルーティングを行うシステム。
【請求項２】
メディア呼のルーティングに対するピアメディアルーティングおよびピアグループメディアルーティングおよびレルムメディアルーティングのうち１つに関連したポリシーを適用するステップと、
ドメインが当該ピアおよび当該ピアグループおよび当該レルムのうち１つであるドメイン間およびドメイン内呼のうち１つに関連したポリシーを適用するステップとを含み、
当該ポリシーが、ポリシー優先順位に対するポリシー定義値およびポリシーのオンまたはオフに対するポリシー定義値を有するポリシー定義を含み、当該ポリシー優先順位が、各ドメインに対する優先順位値の最高ランキング優先順位値を用いて相対優先順位値を比較できるランキング値を含む、リアルタイムパケット交換接続上のメディア呼のルーティングを行う方法。
【請求項３】
ネットワークに接続されるセッションコントローラを設けるステップと、
当該セッションコントローラに接続されるシグナリングスイッチを設けるステップと、
当該セッションコントローラに接続される管理システムを設けるステップと、
当該セッションコントローラを用いて前記ネットワークにおける呼ルーティングを制御するステップとを含み、当該呼ルーティング制御が７層モデルのうち少なくとも２層において要素に対する識別子を含み、当該呼ルーティング制御が呼用のコーデックに対する基本設定を含み、同じ発信元および宛先を有する前呼からの平均オピニオン評点修飾子を考慮して当該呼ルーティングを行う、リアルタイムパケット交換接続上のメディア呼のルーティングを行う方法。
【請求項４】
当該呼ルーティング制御が、７層モデルのうち第２層および第３層において構成要素に対する識別子を含む、請求項３に記載のメディア呼のルーティングを行う方法。
【請求項５】
ネットワークに接続されるセッションコントローラを設けるステップと、
ファイアウォールおよびメディアサーバおよびエッジルータのうち少なくとも１つにメディアファイアウォール制御プロトコルを設けるステップと、
当該メディアファイアウォール制御プロトコルを受信するために接続されるメディアファイアウォール制御プロトコルゲートウェイを設けるステップとを含み、当該メディアファイアウォール制御プロトコルゲートウェイが当該ファイアウォールおよびメディアサーバおよびエッジルータのそれぞれの制御プロトコルに当該メディアファイアウォール制御プロトコルを変換するように動作可能である、リアルタイムパケット交換接続上のメディア呼のルーティングを行う方法。
【請求項６】
当該メディアファイアウォール制御プロトコルゲートウェイが論理エンティティである、請求項５に記載の方法。
【請求項７】
コアコントローラとしてネットワークに接続されるセッションコントローラを設けるステップと、
当該セッションコントローラに接続されるシグナリングスイッチを設けるステップと、
当該セッションコントローラに接続される管理システムを設けるステップと、
当該セッションコントローラにより相互作用機能呼を実行するステップとを含み、当該相互作用機能がセッション開始プロトコル呼とＨ．３２３プロトコル呼との間のメディア変換を行う、リアルタイムパケット交換接続上のメディア呼のルーティングを行う方法。
【請求項８】
当該相互作用がセッション開始プロトコル呼とＨ．３２３プロトコル呼との間の映像の変換を含む、請求項７に記載の方法。
【請求項９】
ネットワークに接続されるセッションコントローラを設けるステップと、
当該セッションコントローラに接続されるシグナリングスイッチを設けるステップと、
当該セッションコントローラに接続される管理システムを設けるステップと、
前記ネットワークを通る複数の経路に対する速度に応じて呼をルーティングするネットワークオペレータにより設定されるポリシーに基づいて前記ネットワークを通る呼をルーティングするステップとを含み、前記ネットワークを通る最小費用ルートにより当該ルーティングを判定する、リアルタイムパケット交換接続上のメディア呼のルーティングを行う方法。
【請求項１０】
ネットワークに接続されるセッションコントローラを設けるステップと、
当該セッションコントローラに接続されるシグナリングスイッチを設けるステップと、
当該セッションコントローラに接続される管理システムを設けるステップと、
呼終了および呼発信に対する費用と前記ネットワークを通る複数の経路に対する費用とに応じて呼をルーティングするネットワークオペレータにより設定されるポリシーに基づいて前記ネットワークを通る呼をルーティングするステップとを含み、前記ネットワークを通る最大収益ルートにより当該ルーティングを判定する、リアルタイムパケット交換接続上のメディア呼のルーティングを行う方法。
【請求項１１】
少なくとも１つのネットワークに接続され、呼を処理するように動作可能であり、処理される各呼の呼明細レコードを与える少なくとも１つのセッションコントローラと、
当該少なくとも１つのセッションコントローラに接続されているシグナリングスイッチと、
当該少なくとも１つのセッションコントローラにより処理される前記呼の前記呼明細レコードを受信するために当該少なくとも１つのセッションコントローラに接続されている管理システムであって、当該管理システムが呼処理に対するポリシーのデータベースを含み、当該管理システムが当該データベースから当該セッションコントローラに適用可能ポリシーを与える、管理システムとを含み、
当該セッションコントローラが境界コントローラおよびコアコントローラのうち１つとして配置され、当該セッションコントローラが当該少なくとも１つのネットワークへのメディアフローを制御し、当該セッションコントローラが当該少なくとも１つのネットワークに対する遠端ネットワークアドレス変換を行う、ネットワーク上のパケットデータのリアルタイム通信のルーティングを行うシステム。
【請求項１２】
セッションコントローラにより着呼に対する呼ピアを見つけるステップと、
当該セッションコントローラにより流入呼ピアに呼を対応付けるステップと、
当該セッションコントローラによりデータベースにおけるポリシーと当該流入呼ピアを一致させるステップと、
デバイス上で呼を登録するステップと、
当該呼ピアを用いて終了シグナリングを指定するステップと、
当該呼ピアにおけるサービスのクラスを指定するステップと、
を含む、インターネットプロトコルシステム上でリアルタイムで呼を切り換える方法。
【請求項１３】
設定呼パラメータおよび着呼、発呼、一致呼にパラメータを与えるステップをさらに含む、請求項１２に記載の方法。
【請求項１４】
ネットワークに接続されるセッションコントローラを設けるステップと、
当該セッションコントローラに接続されるシグナリングスイッチを設けるステップと、
当該セッションコントローラに接続される管理システムを設けるステップと、
高速呼処理用のメモリ内データベースを設けるステップであって、当該メモリ内データベースがハードディスクメモリ上に記憶される永続データベースの要約を含み、当該要約を揮発性メモリに記憶するステップと、
当該データベースにおける任意のデータとは無関係に当該メモリ内データベースと当該永続データベースとの間にデータを非同期的に書き込むステップと、
を含む、インターネットプロトコルシステム上でリアルタイムで呼を切り換える方法。
【請求項１５】
複数のセッションコントローラをさらに含み、当該セッションコントローラのうち少なくとも１つが境界コントローラとして配置され、当該セッションのうち少なくとも１つがコアコントローラである、請求項１１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の背景
発明の分野
本発明は一般に、パケット交換網を介して音声遠隔通信などのリアルタイムサービスを運ぶ方法と装置に関し、特に、インターネットプロトコル（ＩＰ）通信構成要素上における音声、ファクシミリおよびマルチメディア用の装置と方法に関する。
【背景技術】
【０００２】
関連技術の説明
音声遠隔通信は従来、ユーザの電話間で音声信号を伝送する有線または無線接続および電話交換局を利用した専用電話網を介して行われている。公衆交換電話網（ＰＳＴＮ）を用いたそのような遠隔通信を、回線認定通信と呼ぶことができる。インターネットプロトコル上の音声技術（ＶｏＩＰ）では、デジタル化音声情報の個別パケットを使用して音声信号を伝送する代替音声遠隔通信手段を提供する。パケットは、公衆インターネット上でまたはイントラネット内で伝送される。
【０００３】
典型的なＶｏＩＰネットワーク基盤は、ゲートウェイ、ゲートキーパ、プロキシサーバ、ソフトスイッチ、セッション境界コントローラなどを含む。ネットワーク資源の最適化および特定の設計のために、ネットワークオペレータは、多数の基盤構成要素を１つの物理構成要素上に配置できるように個別構成要素の機能を選択して互いに統合してもよい。
【０００４】
ネットワークオペレータが自分たちの顧客に有意義なサービスを提供できるようにＶｏＩＰネットワーク基盤構成要素をネットワークに設計することが望ましい。
【０００５】
下記の用語をこの開示で使用する。
【０００６】
ゲートウェイ：ネットワーク間で相互接続する、または「ゲートウェイ」としての機能を果たすことができるエンティティ。ＶｏＩＰでは通常、従来の公衆交換電話網（ＰＳＴＮ）とＶｏＩＰネットワークとの間で「ゲートウェイ」として機能できるデバイスを意味する。
【０００７】
ゲートキーパ：ＶｏＩＰ呼を処理する方法を判定するためにゲートウェイと共同して作用するエンティティ。ゲートキーパは、呼経路内にあるか、またはあらゆる呼で協議的な役割のみを果たすことができる。ゲートキーパは通常、Ｈ．３２３プロトコルを用いてＶｏＩＰ呼セットアップを処理するだけである。
【０００８】
プロキシサーバ：ＶｏＩＰ呼を処理する方法を判定する、ゲートキーパと機能が同様な中間エンティティ。プロキシサーバは通常、セッション開始プロトコル（ＳＩＰ）を用いてＶｏＩＰ呼セットアップを処理するだけである。
【０００９】
ユーザエージェント：通常ＳＩＰプロトコル（セッション開始プロトコル）に基づいてＶｏＩＰ呼を配置または受信できるエンティティ。
【００１０】
境界要素：境界要素は、ネットワークエッジ要素とも呼ばれている。これは通常、ポリシー定義または運営管理制御が変わる場合である。ポリシーは、７層開放型システム間相互接続（ＯＳＩ）モデルにおける実質的にすべての層で定義可能である。例えば、７層モデルの第３層で、ポリシーを通常、ピアのルーティング、ＩＰ広告経路などに関して記述することができる。ルータは通常、そのようなポリシーがネットワーク間で変わる境界要素としての機能を果たす。ネットワークアドレス変換機構（ＮＡＴ）は、２つ以上のルーティング不可能アドレスドメインを接続する境界要素としての機能を果たす。ファイアウォールは、運営管理制御が変わる境界要素として（第３層とそれ以上に対して）ポリシー制御を実施する。アプリケーション層も通常、下層（例えば、ネットワーク層およびトランスポート層）でフローを使用する。アプリケーション層の制御は、下層での微小フローの制御を可能にする場合がある。例えば、第３層の同一特性を有するＳＩＰ呼に対する個々のメディアストリームは、異なるポリシーによって変わることがある。セッション層境界制御（ＳＢＣ）によって、他の境界要素（ルータ、ＮＡＴ／ファイアウォール、サービス品質ブローカなど）がこれらの微小フローを理解し、より細かい粒度の基準で適切なポリシーを与えることができる。独立型要素として、ＳＢＣは、アプリケーション層におけるポリシー制御を簡単に行うことができる。
【００１１】
７層ＯＳＩモデルは、第１層として物理層、第２層としてデータリンク層、第３層としてネットワーク層、第４層としてトランスポート層、第５層としてセッション層、第６層としてプレゼンテーション層、第７層としてアプリケーション層を含むものと定義される。
【００１２】
セッション制御：セッション制御は、アプリケーション層におけるポリシー制御を意味する。セッション制御を、ネットワークの境界でまたはネットワークのコア内で適用してもよい。被制御要素は、ＮＡＴ／ファイアウォール、サービス品質ブローカ、ルータまたはメディア資源（トランスコーダまたはメディアサーバ）であってもよい。被制御要素により行われるポリシー制御に加えて、セッションコントローラは、ポリシーが管理されている方法に応じて「ホップツーホップ」（ピアレベルとも呼ぶ）または「エンドツーエンド」の２つのやり方でセッションの制御を可能にすることができる。プライバシ、セキュリティ、トポロジ予備選択、認証、許可および課金（ＡＡＡ）、および法令施行支援（ＣＡＬＥＡ、通信傍受法）は、セッション制御機能の一部である。
【００１３】
呼ルーティング：呼ルーティングは、（７層ＯＳＩモデルの）第５層パラメータ（ＤＮＩＳ、ＡＮＩ、Ｈ．３２３ＩＤ、トランクグループ、ＣＩＣなど）を使用して呼に対する第３層終了を選択することである。
【００１４】
呼変換：呼を流出エンティティに渡す前の、着信第５層パラメータ（ＤＮＩＳ（電話番号識別サービス）、ＡＮＩ（自動番号識別）、トランクグループ、Ｈ．３２３ＩＤ、ＣＩＣ（呼照会コマンド）など）の変換。ハンドオーバは、宛先に特有であり、呼ルーティングの処理に影響を及ぼさない。
【００１５】
ソース選択：セッションコントローラは、第３層および第５層の情報を用いてポリシーを呼に割当てることができる。そのような割当てが流入呼ピアで行われた場合、ソース選択が行われる。ソース選択によって、管理者は、データベース内の単一の場所でソース呼ピアに共通のポリシーを設定することができる。
【００１６】
レルム：レルムは、マルチプロトコルセッションコントローラにより与えられるエンドポイントの幾つかの論理グループ化のうち１つである。他のグループ化機構（ｉエッジグループ、ゾーンなど）と比較すると、レルムによって、マルチプロトコルセッションコントローラは、（仮想ＳＩＰサーバを生成する）セッション開始プロトコルと（仮想Ｈ．３２３ゲートウェイおよびゲートキーパを生成する）Ｈ．３２３の両方に別々の論理シグナリングアドレスを与えることができる。これによって、マルチプロトコルセッションコントローラは、第３層プライベートネットワークの上にレルムグループを階層化することができる。
【００１７】
サブネット：サブネットは、レルム内のＩＰ（インターネットプロトコル）サブネットワークである。
【００１８】
呼ピア：呼ピアは、呼に対する論理グループ化である。呼ピアは、（管理者により生成される）静的または（マルチプロトコルセッションコントローラにより実行時に生成される）動的であってもよい。呼ピアは、単一のデバイスに属する必要があり、１つ以上の呼ピアグループに属してもよい。下記に定義されるような２種類の呼ピア（流入呼ピアおよび流出呼ピア）がある。
【００１９】
流入呼ピア：流入呼ピアは、呼の着信に対応付けられる呼ピアである。
【００２０】
流出呼ピア：流出呼ピアは、呼の発信に対応付けられる呼ピアである。
【００２１】
呼ピアグループ：呼ピアグループは、ポリシー（ビジネスポリシー、例えば、企業資源の割当てまたはサービスレベル保証）に基づく呼ピアの（論理）グループ化であり、例えば、サイトまたはピアである。
【００２２】
デバイス：デバイスは、呼ピアの集まりである。デバイスは、（呼ピアと第３層アドレスとの間の固定結合を有する）静的または（プロトコル登録が呼ピアと第３層アドレスとの間の結合を生成することである場合）動的であってもよい。動的デバイスは、静的または動的呼ピアを有してもよい。静的デバイスは、静的呼ピアを有するだけである。
【００２３】
テンプレート：テンプレートは、サブネットなどの呼ピアおよびデバイスを動的に管理するために使用される規則セットである。
【００２４】
ＩＷＦ：ＳＩＰ／Ｈ．３２３相互作用機能
Ａ−Ｏ−Ｒ  ＳＩＰ：レコードのアドレス（ＲＦＣ３２６１）
ＡＡＡ：認証、許可および課金。これらは、ユーザの通話を認証し、ネットワーク内の資源を利用する許可をユーザに与え、資源利用の課金を行う、あらゆる呼に対して実行される３つの機能を意味する。
【発明の開示】
【発明が解決しようとする課題】
【００２５】
発明の概要
本発明は、ネットワークオペレータが自分たちのサービスを住宅用顧客だけでなく、他のネットワークオペレータ、他の企業顧客に与えることができるような基盤を提供する。これは、キャリア−キャリアのピアリング、キャリア−企業のピアリングおよびキャリア−住宅のピアリングをそれぞれ含む。
【課題を解決するための手段】
【００２６】
本発明は、マルチプロトコルシグナリングスイッチおよびマルチプロトコルセッションコントローラを含むパケット交換音声遠隔通信用のセッションコントローラと、セッションコントローラ用の総合管理システムとを含むシステムを提供する。管理システムは、セッションコントローラの動作に関する報告を行うだけでなく、セッションコントローラに情報を供給することもできる。
【００２７】
セッションコントローラ（ＳＣ）製品群をセッションコントローラ用の総合管理システムと一緒に提供することが好ましい。管理システムは、セッションコントローラの動作に関する報告を行うだけでなく、セッションコントローラに情報を供給することもできる。
【００２８】
ネットワークの全アーキテクチャに組み込まれた場合、セッションコントローラは通常、呼を処理し、従って中を流れるすべての呼に関与する。セッションコントローラにより処理されるあらゆる呼は、その呼が動作支援システム（ＯＳＳ）および／または管理システムに安全かつ確実に移送されるまで、セッションコントローラ上に局所的に記憶される呼明細レコード（ＣＤＲ）を生成する。また、管理システムは、生成されるあらゆる呼明細レコードのコピーを受信する。管理システムの解析エンジン（ＡＥ）は、呼明細レコードを処理して、技術レポートを生成し、アラームおよび例外を生成し、ビジネスポリシーに基づいてセッションコントローラ用のルーティング規則を生成する。
【発明を実施するための最良の形態】
【００２９】
好ましい実施形態の詳細な説明
図１は、インターネットプロトコル電話サービス上における音声を提供する本発明の管理システムおよびセッションコントローラを用いたシステムの全ネットワークアーキテクチャを例示する。インターネットプロトコル上における音声（ＶｏＩＰ）という用語は、音声通信だけでなく、ファックスデータ、マルチメディアデータおよび他のリアルタイムまたは略リアルタイムサービスも含む。これらのサービスは、総称してメディア呼として知られている場合もある。図１において全体を符号２０で示すシステムは、公衆交換電話網（ＰＳＴＮ）２２と、広帯域ネットワークアドレス変換機構（ＮＡＴ）トラバーサル２４と、企業ピアリング２６と、Ｈ．３２３ネットワーク２８と、セッション開始プロトコル（ＳＩＰ）ソフトスイッチネットワーク３０との間のインタフェースを提供する。説明として、公衆交換電話網２２は、回線交換音声網を用いた従来の公衆電話システムである。Ｈ．３２３ネットワーク２８は、音声伝送を含む情報のパケットによる転送用のＨ．３２３規格を利用したネットワーク、特に回線交換音声伝送とパケット交換音声伝送との間のインタフェースを意味する。例えば、Ｈ．３２３ネットワークは、インターネットであってもよい。ソフトスイッチネットワークは、ネットワークソフトウェアからネットワークハードウェアが分離しているスイッチを用いたネットワークを意味する。ＳＩＰソフトスイッチネットワークおよびＨ．３２３ネットワークは、キャリアピアリングを利用する。ピアリングは、通信システムにおいて他の装置と同じプロトコル層を用いた中央コントローラを有しないネットワークにおけるノードを介した情報の交換を意味する。企業ピアリングは、そのような企業内通信を意味する。
【００３０】
公衆交換電話網２２は、ソフトスイッチ３２を介してシステム２０に接続できる。広帯域ネットワークアドレス変換機構（ＮＡＴ）トラバーサル２４とシステム２０との間のインタフェースは、広帯域システム３４およびマルチプロトコルセッションコントローラ（ＭＳＣ）３６を介している。企業ピアリングシステム２６は、マルチプロトコルセッションコントローラ（ＭＳＣ）３８を介して本システム２０と通信する。単一のマルチプロトコルセッションコントローラ（ＭＳＣ）４０は、Ｈ．３２３ネットワーク２８およびセッション開始プロトコル（ＳＩＰ）ソフトスイッチネットワーク３０に設けられている。
【００３１】
システム２０内で、マルチプロトコルセッションコントローラ３６、３８および４０とソフトスイッチ３２とは、マルチプロトコルシグナリングスイッチ（ＭＳＷ）４２と通信する。マルチプロトコルシグナリングスイッチ４２とマルチプロトコルセッションコントローラ３６、３８および４０とは、管理システム４４により制御される。管理システム４４は、セッションコントローラの動作に関するレポートだけでなくセッションコントローラ３６、３８および４０への情報提供を行うように動作可能である。セッションコントローラ３６、３８および４０は、呼を処理し、それぞれのセッションコントローラ内を流れるすべての呼に関与する。セッションコントローラ３６、３８および４０により処理された呼は、セッションコントローラ上に局所的に記憶されてから管理システムに伝送される呼明細レコード（ＣＤＲ）に記録される。また、管理システムは、セッションコントローラの各々により生成されたあらゆる呼明細レコードのコピーを受信し、呼明細レコードを処理して技術レポートを生成し、アラームおよび例外を生成し、ビジネスポリシーに基づいてセッションコントローラ用のルーティング規則を生成する。
【００３２】
セッションコントローラは、ネットワークのエッジまたはＶｏＩＰネットワークのコアにある呼を生成する。セッションコントローラが、他のネットワークとピアリングしてＶｏＩＰネットワークのエッジに配置されている場合、その機能は、境界セッションコントローラ（ＢＳＣ）またはセッション境界コントローラ（ＳＢＣ）と呼ばれている。ネットワークのコアにおけるセッションコントローラは、呼ルーティングおよび集約呼許可制御（ＣＡＣ）などの機能を与え、コアセッションコントローラ（ＣＳＣ）と呼ばれている。
【００３３】
マルチプロトコルセッションコントローラ３６、３８および４０は、ネットワークにおいてコアセッションコントローラまたは境界セッションコントローラとしての機能を果たすことができる。サポートされる機能について簡単に後述する。
【００３４】
コアセッションコントローラとしてのセッションコントローラの配置において、例えば、コントローラは、呼ルーティングを行い、ハンティングエンジンとしての機能を果たす。コアセッションコントローラとして配置されると、そのコントローラは、マルチプロトコルセッションコントローラを介してすべての呼をルーティングするコア呼コントローラとしての機能も果たす。マルチプロトコルセッションコントローラ３６、３８および４０は、外部機構およびアプリケーションサーバを必要とする呼を識別する。さらに、マルチプロトコルセッションコントローラ３６、３８および４０は、アプリケーションサーバ上のエンドポイントアクセスサービス用のセッション開始プロトコル（ＳＩＰ）アウトバウンドプロキシとしての機能を果たすことができる。実行される別の機能は、マルチプロトコルセッションコントローラ３６、３８および４０がリモート認証ダイヤルインユーザサーバ（ＲＡＤＩＵＳ）を用いて認証、許可および課金を使用可能にできる認証、許可および課金（ＡＡＡ）である。局所パスワード認証および呼明細レコードロギングも使用することができる。また、コアセッションコントローラは、調整ネットワーク容量などのコアネットワーク呼許可制御を行う。マルチプロトコルセッションコントローラ３６、３８および４０は、テレフォニールーティング情報プロトコル（ＴＲＩＰ）メッセージを他のドメインと交換して、ルートを告知及び覚える。最後に、マルチプロトコルセッションコントローラは、３ＧＰＰ  Ｓ−ＣＳＣＦ（第３世代提携プロジェクトサービス呼セッション制御機能）としての働きをすることができる．
第２の配置シナリオにおいて、セッションコントローラは、トポロジ隠蔽を行う境界セッションコントローラとしての機能を果たす。マルチプロトコルセッションコントローラ３６、３８または４０を、通常ＳＩＰ（セッション開始プロトコル）とＨ．３２３ネットワークとの間の相互作用機能呼に従事させることができる。これは、マルチプロトコルセッションコントローラ３６、３８または４０がＨ．３２３エンティティをその中に有する種々のアクセスネットワークに接続できるからである。ＳＩＰとＨ．３２３との間の変換は、相互作用機能（ＩＷＦ）と呼ばれている。相互作用機能は、音声呼で周知である。本セッションコントローラは、映像呼用の相互作用機能を含む。特に、本セッションコントローラは、音声呼に対するそのような相互作用機能サポートを有するだけでなく、Ｈ．３２３エンドポイントとＳＩＰエンドポイントとの間の映像呼に対するサポートも有する。
【００３５】
また、マルチプロトコルセッションコントローラ３６、３８または４０は、ネットワークにおいて相互運用性機能を与えている。コントローラは、帯域幅制御などのアクセスネットワーク呼許可制御を行う。そのコントローラに直接登録するネットワークの場合、マルチプロトコルセッションコントローラは、呼予備選択およびユーザ認証を使用可能にできる。マルチプロトコルセッションコントローラ３６、３８または４０は、ＲＡＤＩＵＳ（リモート認証ダイヤルインユーザサーバ）またはＤＩＡＭＥＴＥＲ（認証、許可および課金用のＲＡＤＩＵＳと同様なプロトコル）によるＳＩＰ（セッション開始プロトコル）認証を使用することができる。
【００３６】
マルチプロトコルセッションコントローラ３６、３８または４０の追加機能は、アクセスネットワーク間のメディアフローを制御することである。マルチプロトコルセッションコントローラは、アクセスネットワークに遠端ネットワークアドレス変換トラバーサルを与える。マルチプロトコルセッションコントローラは、アクセスネットワークに発信する呼にネットワークにおけるトランスコーディングサービスを提供することができる。トランスコーディングメディアサーバ資源を、ネットワークに集中化したり、（例えば、境界で）マルチプロトコルセッションコントローラと配置したりすることができる。また、マルチプロトコルセッションコントローラは、（１９９４年の）ＣＡＬＥＡ（通信傍受法）に対するコンテンツ傍受アクセスポイントおよび傍受関連情報（ＩＲＩ）傍受アクセスポイントとしての機能を果たす。さらに、マルチプロトコルセッションコントローラ３６、３８または４０は、メディアストリーム用の呼ジッタと平均オピニオン評点とに監視を与える。
【００３７】
サービス品質の監視は、マルチプロトコルセッションコントローラがＤｉｆｆｓｅｒｖ（差別化サービス）境界要素としての機能を果たす境界セッションコントローラにより行われる。差別化サービスコードポイント（ＤＳＣＰ）は、呼ごとに制御可能である。また、マルチプロトコルセッションコントローラは、仮想ローカルエリアネットワークタグおよび優先ビットを挿入および／または修正する処理を行う。仮想ローカルエリアネットワークタグはレルムごとに制御され、仮想ローカルエリアネットワーク優先順位値は呼ごとに制御される。また、コントローラは、３ＧＰＰ（第３世代提携プロジェクト）プロキシ呼セッション制御機能（Ｐ−ＣＳＣＦ）、問い合わせ呼セッション制御機能（Ｉ−ＣＳＣＦ）およびブレイクアウトゲートウェイ制御機能（ＢＧＣＦ）を与える。最後に、境界コントローラとして、マルチプロトコルセッションコントローラは、第三者アプリケーションサーバに登録されるエンドポイント用のＳＩＰアウトバウンドプロキシとしての機能を果たすことができる。
【００３８】
ネットワーク内のすべてのマルチプロトコルセッションコントローラ（境界コントローラとコアコントローラの両方）は、ｉＶＭＳ管理システム（本出願の譲受人の専用管理システム）上に記憶された集中化区分データベーススキーマからそれぞれのデータベースをダウンロードする。課金の目的で、マルチプロトコルセッションコントローラを課金用のＲＡＤＩＵＳサーバ（リモート認証ダイヤルインユーザサーバ）と統合することもできる。ＳＮＭＰ（単純ネットワーク管理プロトコル）エージェントは、ｉＶＭＳ管理システム上だけでなくマルチプロトコルセッションコントローラ上で動く。
【００３９】
図２は、マルチプロトコルセッションコントローラポリシーデータベースを示す。テンプレート５０を使用して、（動的生成デバイスである）動的デバイス５２、呼ピア５４および結合５６を管理する。テンプレート５０を用いた呼ピアグループ５８との動的対応付けを、線６０で示す。静的デバイス６２を示す。
【００４０】
呼ピア５４は、呼の処理においてはるかに最も重要な要素である。上述のように、呼ピアは、呼の論理グループ化であり、着呼の流入呼ピアまたは発呼の流出呼ピアであることができる。マルチプロトコルセッションコントローラは、処理すべき各呼に対する丁度１つの流入呼ピアを対応付ける。呼ルーティングの処理は、丁度１つの流出呼ピアを呼に対応付けることを確実にする。図３は、これを概念的に示す。着または流入呼ピア６８は、データベースに設定された呼ピア７０と一致される。流入呼ピア６８は、呼／セッション処理をトリガしたプロトコルメッセージを通常見ることにより、マルチプロトコルセッションコントローラでインスタンス化される。ＯＳＩ７層モデルの第３層〜第７層における情報を解析してこのインスタンス化を生成する。発または流出呼ピア７２は、データベースに構成されたルーティングポリシー７４によりインスタンス化される。特に、一旦流入呼ピア６８が生成されると、マルチプロトコルセッションコントローラは、データベース（またはポリシー）においてこの呼ピアに対する一致を探す。一致が認められない場合、アクセス制御が無効にされていると、呼をまだ受け付けるであろう。しかし、通常の構成下で、そのような呼は捨てられる。呼ルーティングの処理は、データベースの中でループし、呼レッグに対する流出呼ピア７２をインスタンス化する。資源が使用できないまたはユーザポリシーが妨げる場合、マルチプロトコルセッションコントローラは呼レッグに対する流出呼ピア７２を対応付けることができないことがある。
【００４１】
通話を発信または終了しない中間システムのように、本システムは、通話を切り換えるのに通話の経路に関与している。各呼は、中間構成要素から見ると、着呼レッグおよび発呼レッグの２つの呼レッグを有する。
【００４２】
流入呼ピア６８をポリシー７４に設定された呼ピアと一致させる処理は、呼ピア、デバイスおよびテンプレートを定義する方法に左右される。一致処理によって、流入呼ピア６８をデータベースに定義された呼ピアに割当てることができ、従って、後者が呼のグループに関するポリシーを定義できるようになる。
【００４３】
以下、呼ピアという用語はデータベースに定義された呼ピアを意味すると仮定する。呼ルーティングの処理を、図４に簡単に表す。
【００４４】
呼ピア６８の例を幾つか挙げる。被呼者番号（またはパターン）または発呼者番号（またはパターン）により識別される呼、単一シグナリングエンティティから発する呼、例えばＨ．３２３−ＩＤまたはレコードのアドレス、あるいはトランクグループによりグループ化済みの呼。
【００４５】
デバイスは、１つ以上の呼ピアを含む（および少なくとも１つ含む）。包含関係は、結合と呼ばれている。この結合とデバイスの両方は、静的または動的であることができる。デバイスは通常、マルチプロトコルセッションコントローラの周囲のネットワークにおける物体、例えば、ゲートウェイ、端末、ゲートキーパ、マルチポート会議ユニット（ＭＣＵ）、会議サーバ、構内交換機（ＰＢＸ）プロキシサーバに対応する。
【００４６】
呼のデバイスへの対応付けは、堅苦しい規則ではない。下記の制約が当てはまる。各登録は、一意のデバイスに対応する必要がある。マルチプロトコルセッションコントローラでは、デバイスが連続してまたは多数の登録メッセージで登録できない。これにより、登録管理、キャッシング、および登録を使用するデバイスのタイムアウトが簡略化される。
【００４７】
一つの登録により、登録を使用するデバイス上の全呼ピアが起動される。最初の登録が到着するまで、呼ピア、デバイスおよび結合は、無効であるとみなされる。
【００４８】
マルチプロトコルセッションコントローラにより使用されるデバイスベースの識別基準の例を挙げる。第１のセッション開始プロトコル（ＳＩＰ）ＩＮＶＩＴＥにおけるｖｉａアドレスの解決値（先のホッププロキシを識別する−ホップツーホップ識別）、Ｈ．３２３  ＳＥＴＵＰにおけるソースシグナリングアドレスまたは第１のＳＩＰ  ＩＮＶＩＴＥにおけるコンタクト統一資源識別子（ＵＲＩ）の解決値（先のホップ連続ユーザエージェントまたはエンドユーザエージェント／エンドポイント／ゲートウェイを識別する−エンドごとの識別）、および入力ＳＩＰ  ＩＮＶＩＴＥまたはＨ．３２３  ＳＥＴＵＰのソースＩＰ（インターネットプロトコル）アドレス（先のホップネットワークアドレス変換または中間ボックスを識別する）。
【００４９】
呼ピアグループ５８は、多数の呼ピアが共通ポリシー仕様の一部であることを可能にする。
【００５０】
テンプレート５０は、多数の機能を有する。特に、テンプレート５０は、マルチプロトコルセッションコントローラ上に明示的に設定されていない呼ピアおよびデバイスへのポリシーの適用を管理する規則セットとしての機能を果たす。テンプレート５０は、マルチプロトコルセッションコントローラに登録するデバイスへのポリシーの適用を管理する規則セットとしての機能を果たす。これらの両方の機能について詳しく後述する。
【００５１】
あらゆる呼に関して、流入での呼ピアの存在により、下記の機能を実行することができる。
【００５２】
呼許可制御は、呼レッグまたは帯域幅に基づいている。アクセス制御を使用可能にし、流入呼ピアが見つからない、または動的に呼ピアの生成を可能にするテンプレートが存在しない場合、呼を拒否する。呼ピアが見つかった場合、使用される呼レッグおよび帯域幅は、限界に対して比較される。
【００５３】
また、流入での呼ピアにより、あらゆる呼に対する呼明細レコードにピアを記録することができる。さらに、メディアルーティングポリシーを呼に与える。その上、呼に対するプライバシポリシー（ＳＩＰ  ＰｒｉｖａｃｙおよびＨ．３２３プレゼンテーションおよび予備選択標識）を与える。
【００５４】
呼ピアは、ピア上のシグナリングを発信または終了するための関連情報の相互作用を可能にする。具体的には、発呼ピアは、ピア上の呼を終了するためにどんな種類のシグナリングを使用するかを指定する（これはデバイスピアにも当てはまる、下記参照）。
【００５５】
呼ピアにより許可されるさらに別の機能は、呼ピアから発信する呼に対する（段階的サービスモデルにおける）サービスのクラスの指定である。トランクグループ、ゾーン、呼ハンティングタイムアウトおよび試みなどを用いて、サービスのクラスを指定する。
【００５６】
ある実施形態では制限もあり、例えば、マルチプロトコルセッションコントローラは現行リリースでデバイスピアおよびサブネットピアに対する豊富なサポートを欠いている。しかし、これらの考えの大部分は、現行データベースおよびポリシー設定において明白である。ｒｅｇ−ｉｄ／ｕ−ｐｏｒｔは呼ピアとしての機能を果たし、ｒｅｇ−ｉｄ（レジストリ識別）はデバイスホルダとしての機能を果たす。また、デバイスと呼ピアとの間の明白な区別もない。デバイスに特有の構成は、デバイスの一部である各呼ピアの一部である。例えば、ＩＰアドレス情報は、同じデバイスの一部とみなされる全ｒｅｇ−ｉｄ／ｕ−ｐｏｒｔ上で静的に構成される。ｉエッジ（ｉ−ｅｄｇｅ）グループは、定義される唯一の呼ピアグループである。
【００５７】
さらに、マルチプロトコルセッションコントローラは、デバイスおよび呼ピアの明示的設定を必要としない。マルチプロトコルセッションコントローラをアウトバウンドプロキシとして用いてＳＩＰユーザエージェントが第三者ＳＩＰサーバ上のサービスにアクセスするシナリオにおいて、マルチプロトコルセッションコントローラは、呼ピアまたはデバイスとして明示的に設定されるようにユーザエージェントに要求しない。これらのデバイスはサーバに登録する必要があり、マルチプロトコルセッションコントローラは、これらの登録に基づいて動的デバイスおよび呼ピアを生成する。また、マルチプロトコルセッションコントローラは、テンプレートを用いてこれらの動的デバイス／ピアに対するポリシーをインスタンス化する。この場合、テンプレート５０（サブネットに基づく）を使用して、ｉエッジグループとの対応付けおよびこれらの動的呼ピアおよびデバイスの生成を指示することができる。各テンプレートは、ｒｅｇ−ｉｄ／ｕ−ｐｏｒｔを有する。
【００５８】
ゲートウェイ／ユーザエージェントを、（移動性を与えて）移動することもある。マルチプロトコルセッションコントローラは、登録を介してのみ移動性を検出する。移動デバイスを、マルチプロトコルセッションコントローラまたは第三者サーバ上に登録（従って構成）してもよい。テンプレート５０は、両方の場合に関するポリシーのインスタンス化を管理する。
【００５９】
以下、呼ピア上のポリシー構成について説明する。
【００６０】
各呼ピア上のマルチプロトコルセッションコントローラポリシーおよび構成パラメータは、４つの概略カテゴリであると仮定する。カテゴリ化は２通りあり、即ち、着呼を求めるパラメータまたは流入呼ピア上に定義されるパラメータを表すＩＮおよび発呼を求めるパラメータまたは流出呼ピア上に定義されるパラメータを表すＯＵＴである。これらのカテゴリの各々の範囲内で、２つのカテゴリ、即ち、呼を一致させるのに使用されるパラメータＭＡＴＣＨ（これらは、プロトコルパラメータ、第３層（ネットワーク）パラメータまたはアプリケーションエイリアスであってもよい）、または呼パラメータの修正に使用されるパラメータＳＥＴ（これらは、プロトコルパラメータ、第３層パラメータまたはアプリケーションエイリアスであってもよい）がある。
【００６１】
これらのパラメータの使用について、呼ルーティングの節でさらに説明する。ＩＮ／ＭＡＴＣＨパラメータは、呼を流入呼ピアに対応付ける機能を果たす。同じパラメータを多数のカテゴリに対応付けた場合（例えば、ＩＮ／ＳＥＴだけでなくＩＮ／ＭＡＴＣＨ）、他のカテゴリと関係ない各カテゴリにおいてパラメータの一意のインスタンスであるとみなされる。
【００６２】
動的呼ピアは、ＳＩＰアウトバウンドプロキシとして機能する場合にマルチプロトコルセッションコントローラにより動的に生成される呼ピアである。
【００６３】
以下、テンプレートを含む場合の使用について説明する。
【００６４】
移動性、ネットワークアドレス変換（ＮＡＴ）およびアウトバウンドプロキシ（ＯＢＰ）を含む例において、移動エンドポイントは、サブネット１内のアドレスに登録する。エンドポイントは常時、（幾つかの他の同様なエンドポイントと一緒に）ネットワークアドレス変換機構（ＮＡＴ）の後ろにあり、マルチプロトコルセッションコントローラを介して第三者ＳＩＰサーバに登録している。エンドポイントは後で、サブネット２に移動する。この場合、マルチプロトコルセッションコントローラは、各登録に対して動的にデバイスおよび呼ピアを生成し、サブネット特定ポリシーを適用して、呼ピアをインスタンス化する。ネットワークアドレス変換機構の後ろのそのような各エンドポイントは、マルチプロトコルセッションコントローラにより動的に生成される一意のｒｅｇ−ｉｄ（レジストリ識別）を有する。
【００６５】
アウトバウンドプロキシを除いて上記と同じ例において、エンドポイントは、マルチプロトコルセッションコントローラに登録している。この場合、ユーザは、エンドポイントに対する定義済みｒｅｇ−ｉｄ（レジストリ識別）を有する。サブネットに基づくテンプレートは、エンドポイントが移動する場合にポリシーインスタンス化を管理する。
【００６６】
別の例において、サブネット内のゲートウェイは、呼を生成しようとする。テンプレートに基づくサブネットによって、マルチプロトコルセッションコントローラは、呼ピアグループだけでなく呼ピアも呼に対応付けることができる。
【００６７】
図５に示すようなマルチプロトコルセッションコントローラにより使用される呼処理アルゴリズムまたは方法は、４つのステップを含む。ステップ１では、ＩＦというラベル付きの参照番号８０は、（上述のＩＮ／ＭＡＴＣＨパラメータを用いて）流入に関する呼にフィルタをかける。ステップ２では、ＩＸというラベル付きの参照番号８２は、（上述のＩＮ／ＳＥＴパラメータを用いて）流入に関する呼を変換する。ステップ３では、ＥＦというラベル付きの参照番号８４は、（上述のＯＵＴ／ＭＡＴＣＨパラメータを用いて）流出に関する呼にフィルタをかける。ステップ４では、ＥＸというラベル付きの参照番号８６は、（上述のＯＵＴ／ＳＥＴパラメータを用いて）流出に関する呼を変換する。
【００６８】
より詳細には、ステップ１の参照番号８０は、ソース識別の処理および共通ソースポリシーの適用である。ステップ２および３の参照番号８２および８４は共に、呼の「ルーティング」を行う。また、ステップ２の参照番号８２はタグ付けとも呼ばれ、ステップ３の参照番号８４は一致と呼ばれている。従って、ルーティングは、タグ付けと一致の結合処理である。ステップ４の参照番号８６は、呼のハンドオフを行う。
【００６９】
ステップ３（ルーティング）を除く全ステップは、オプションである。一般に、２種類の呼がある。第１の種類の呼は、特定のエンドポイント（レコードのアドレス、特定の電話または特定のＨ．３２３識別）に向けられる呼である。これらの呼は、ステップ３のみを実行し、直接エンドポイント呼と呼ばれている。第２の種類の呼は、マルチプロトコルセッションコントローラ上の呼ハンティングを必要とする呼である。呼ハンティングは、マルチプロトコルセッションコントローラが呼に対する宛先の識別グループの中で最適の宛先を見つける処理である。
【００７０】
呼ハンティングでは、下記の基準を使用する。フィルタ優先順位、呼ピア優先順位、フィルタ一致強度、（時刻フィルタリングのような）フィルタまたは呼ピアに関する管理ポリシー、負荷平衡（最長時間未使用またはパーセント利用）、およびＩＳＤＮ／ＳＩＰ応答コード／宛先変更などの実行時基準。同様に、ソース識別では、下記の基準を使用する。フィルタ優先順位、呼ピア優先順位、フィルタ一致強度、および（時刻のような）フィルタまたは呼ピアに関する管理ポリシー。
【００７１】
マルチプロトコルセッションコントローラにより戻される誤りコードの制御は、次の通りである。ＳＩＰおよびＨ．３２３呼は両方とも、呼が落ちた理由を合図する幾つかの誤りコードを使用する。マルチプロトコルセッションコントローラは、誤りコードを発呼側に戻した場合、誤りコードのマッピングおよび誤りコードに基づく呼ハンティング処理の制御を可能にする。一般に、停止（これ以上の試みが呼に必要でなく、マルチプロトコルセッションコントローラもこの解釈を失敗した直接エンドポイント呼に使用する）、一時的失敗（試み続ける）、または宛先変更（宛先の添付リストを試みる）として誤りコードを解釈できる。
【００７２】
図６は、誤りコード取り扱い処理を例示する。
【００７３】
誤りコード９０をマッピング９２して発呼側に送信する前に、呼ハンティングポリシー８８を適用する。誤りコードマッピング９２は、直接エンドポイント呼に対して行われない。マルチプロトコルセッションコントローラは、誤りコードを呼ハンティングポリシーにより使用する方法に関するデフォルトポリシーを使用する。デフォルト設定により、プロトコル相互作用が必要でない限り、誤りコードマッピングを適用しない。また、相互作用誤りコードマップは、インまたは流入ピア（デバイスピア）上の完全誤りコードマップの一部と定義される。
【００７４】
以下、呼ルーティングおよびハンティングについて説明する。上述のポリシーは、下記のモードのルーティングを可能にする。
【００７５】
自動番号識別（ＡＮＩ）によるルーティング。マルチプロトコルセッションコントローラは、多数の方法で自動番号識別によるルーティングを行うことができる。ＡＮＩポリシーは呼発信に特有であるが全終了に共通である場合、ＩＮ／ＭＡＴＣＨパラメータを使用して、流入における自動番号識別にフィルタをかける（上述の呼ルーティングのステップ１）。呼にタグを付ける（ステップ２）。このタグを、続くＯＵＴ／ＭＡＴＣＨステップ用のフィルタとして使用する。タグ付けステップで付けられたタグにフィルタをかける（これは、呼ルーティングのステップ３である）。呼ルーティングにおけるステップ４およびステップ１の一部として変換を適用してもよい。
【００７６】
自動番号識別ポリシーは呼終了に特有であるが全発信に共通である場合、ＯＵＴ／ＭＡＴＣＨパラメータを使用して、流出における自動番号識別にフィルタをかける（呼ルーティングのステップ３）。呼ルーティングにおけるステップ４の一部として変換を適用してもよい。
【００７７】
マルチプロトコルセッションコントローラは、自動番号識別を使用して呼の真の発信を識別することができる。例えば、マルチプロトコルセッションコントローラがセッション開始プロトコルアウトバウンドプロキシとしての機能を果たすシナリオにおいて、セッション開始プロトコルサーバに登録されたエンドポイントにより発信された呼は、マルチプロトコルセッションコントローラを介してヘアピン止めすることができる。ヘアピン止めインスタンスは、元の着呼と共通するセッション開始プロトコルヘッダを有しないこともある（例えば、セッション開始プロトコルサーバは連続ユーザエージェントである）。そのような呼の場合、マルチプロトコルセッションコントローラは、呼を発信する真のアクセスネットワークを識別するセレクタとして自動番号識別を使用することができる。このようにして、マルチプロトコルセッションコントローラに登録された任意の公衆交換電話網ゲートウェイの方へ呼を定める場合、発信アクセスネットワークに基づいてポリシーを選択することができる。任意のアプリケーションサービスを必要とするかを判定するアクセスネットワーク自体から到着する呼上のマルチプロトコルセッションコントローラにより、自動番号識別による呼ルーティングを使用することもできる。アプリケーションサービスを必要としない呼を、他の登録エンドポイント（例えば、公衆交換電話網エンドポイント）に直接ルーティングしてもよい。
【００７８】
トランクグループによるルーティングでは、トランクグループを多数の方法でマルチプロトコルセッションコントローラ上で使用することができる。第１に、発信側は、トランクグループ識別子を有するマルチプロトコルセッションコントローラを設けることにより終了ポリシーを指定することができる。第２に、サービスのクラスの場合、呼ルーティング処理におけるタグ付けステップを使用して、サービスの所要のクラスに基づいて呼にタグを付けることができる。第３に、呼発信側を１つ以上の終了側に接続する幾分ダムパッチパネルのように、区分ルーティングまたは相互接続を使用する。第４に、簡単な自動番号識別または電話番号識別サービスによるルーティングの場合、フィルタリング機構（ルーティングのステップ１）を用いて、自動番号識別または電話番号識別サービスに基づいて呼にタグを付けることができる。次に、ステップ３では、これらのタグに基づいて終了側を選択する。
【００７９】
すべての呼ピアポートをゾーンに配置することができる。ゾーンＡ内にいる発信者を、同じゾーン内の他の相手のみに話すようにできる。
【００８０】
呼ハンティング処理の制御は、マルチプロトコルセッションコントローラで行われる。特に、（呼ソースに適用されるポリシーを特徴付ける）呼発信に特有な制御が行われる。これは、呼ソースに対して認められる最大試行回数およびソースに対して指定される最大ポストダイヤル遅延を含む。ポストダイヤル遅延（ＰＤＤ）タイマは、宛先が呼処置または１００試行に応答すると終了することもできる。１００試行は、ＲＦＣ８２２に従ってフォーマットされたＳＩＰメッセージコードである。この場合、マルチプロトコルセッションコントローラは、呼試行を破棄する。
【００８１】
さらに、マルチプロトコルセッションコントローラは、到達不可能な任意のインターネット制御メッセージプロトコル（ＩＣＭＰ）宛先が保留の要求に応答して入ってくると規定することにより呼ハンティング処理を制御する（ＳＩＰおよびＨ．３２３の両方）。
【００８２】
呼ハンティング処理の制御用の別の機構は、宛先ごとに指定されるハントタイムアウトを与える（ＳＩＰおよびＨ．３２３）。このタイムアウトは、いつマルチプロトコルセッションコントローラが試行を失敗したとみなし、次の代替ルートを試行するかを判定する。
【００８３】
呼ハンティングのさらなる制御として、スティッキールートを使用する。スティッキールートは、呼ハンティング処理で使用された最終ルートとして定義される。要するに、スティッキールートを使用する試行が失敗した場合に呼を終了するためにスティッキールートを使用する。スティッキールートは、一般的なハント処理に対する優れた例外機構としての機能を果たし、呼終了側が呼ハンティングアルゴリズムを判定して終了するのを可能にする。
【００８４】
すべての呼に共通の変換およびフィルタを、通過ルート（特殊なルート）の一部として適用できる。
【００８５】
マルチプロトコルセッションコントローラは、外部アプリケーションサーバと対話する。
【００８６】
アプリケーションサーバに直接登録されるエンドポイントの場合、マルチプロトコルセッションコントローラは、アプリケーションサーバに呼を直接渡す。アプリケーションサーバは、（マルチプロトコルセッションコントローラを通過できる）音声メールサーバに、またはマルチプロトコルセッションコントローラを通る別の登録エンドポイント（ヘアピン）に呼を向けることができる。
【００８７】
また、マルチプロトコルセッションコントローラは、アプリケーションサーバに定められた各登録に対する動的エンドポイント状態を生成する。動的状態は、登録が開始され、これらのエンドポイントから発信および終了する全ての呼がレルムのメディアルーティング特性を帯びるレルム上に生成される。
【００８８】
また、マルチプロトコルセッションコントローラは、セッション開始プロトコルミラープロキシ機能を使用して同じ事を実現する。マルチプロトコルセッションコントローラによって、呼ピアごとにミラープロキシを割当てることができる。
【００８９】
マルチプロトコルセッションコントローラは、（マルチプロトコルセッションコントローラにより識別される呼のソースで設定される）それぞれのミラープロキシへのミラープロキシ機能を用いて全エンドポイントに対する呼および登録をルーティングする。
【００９０】
また、マルチプロトコルセッションコントローラは、セッション開始プロトコル（ＳＩＰ）アウトバウンドプロキシとしての機能を果たす。アウトバウンドプロキシの概念は、ＳＩＰプロトコルのみに対して定義され、マルチプロトコルセッションコントローラを中間要素として用いて第三者セッション開始プロトコルサーバからアクセスされるサービスまたは呼に当てはまる。
【００９１】
流入セッション開始プロトコル呼／登録は、マルチプロトコルセッションコントローラにより２つのカテゴリに分類される。第１に、マルチプロトコルセッションコントローラは、プロキシ／レジストラとしての機能を果たす。この場合、呼／登録は、マルチプロトコルセッションコントローラの認証／ルーティングサービスにアクセスしている。登録用の統一資源識別子の要求を、マルチプロトコルセッションコントローラに宛てる必要がある。しかし、呼用の統一資源識別子の要求を、マルチプロトコルセッションコントローラに宛てなくてもよい。また、マルチプロトコルセッションコントローラは、ＳＩＰ３ｘｘメッセージを発呼側にハンドオーバすることなく局所的にＳＩＰ３ｘｘメッセージを処理する。
【００９２】
第２に、マルチプロトコルセッションコントローラは、アウトバウンドプロキシとしての機能を果たす。登録の場合、要求統一資源識別子を第三者ＳＩＰサーバに宛てる。マルチプロトコルセッションコントローラに宛てられずそのようなエンドポイントから来るすべての呼は、アウトバウンドプロキシ呼として扱われる。マルチプロトコルセッションコントローラに宛てられた呼は、上述のプロキシモードと同様にさらにルーティングされる。マルチプロトコルセッションコントローラは常時、この場合の発呼側にすべてのＳＩＰ最終応答（ＳＩＰメッセージの宛先変更応答に関する３ｘｘメッセージコードを含む）を中継する。この結果、同様にマルチプロトコルセッションコントローラ上でハンティングサービスが提供されない。（これは、外部サーバ上で実現されるハンティングアルゴリズムに過度の影響がないだけでなく、認証が各ハント試行上で適切に機能することを確実にする。）
上述のように、マルチプロトコルセッションコントローラは、セッション制御のコアだけでなく境界の両方においてＳＩＰアウトバウンドプロキシとしての機能を果たすことができる。ＳＩＰアウトバウンドプロキシとして機能する境界コントローラは、登録およびシグナリングメッセージをエンドサーバに直接転送する。そのようなエンドサーバ（ドメイン名サーバ（ＤＮＳ）、例えばＲＦＣ３２６３を用いて）の位置は通常、マルチプロトコルセッションコントローラをアウトバウンドプロキシとして用いてエンドポイントから隠されている。また、マルチプロトコルセッションコントローラは、位置処理の一部としてサーバの局所構成リストを介してハントする呼ハンティングを使用することができる。マルチプロトコルセッションコントローラ上でＳＩＰ３ｘｘ宛先変更メッセージコードの処理も実行される。
【００９３】
マルチプロトコルセッションコントローラは、２つの方法でアウトバウンドプロキシ呼として呼を処理することができる。第１の方法では、第三者レジストラに登録されるエンドポイントからの呼に対するＳＩＰ要求−統一資源識別子による転送を使用する。この方法では、ＳＩＰサーバにアクセスするエンドシステムは、アウトバウンドプロキシとしてマルチプロトコルセッションコントローラの存在を知っている。マルチプロトコルセッションコントローラが（コアコントローラとして）コアセッション制御機能を実行する場合、この方法は望ましい。第２の方法では、マルチプロトコルセッションコントローラ上でミラープロキシ機能を使用する。この方法では、ＳＩＰサーバにアクセスするエンドシステムは、サービスがマルチプロトコルセッションコントローラにより提供されていると推定する。ミラープロキシ機能は、登録されるエンドポイントのみに当てはまることに留意せよ。マルチプロトコルセッションコントローラは、エンドシステムとサーバとの間で透過的にすべての登録およびシグナリングメッセージを転送する。マルチプロトコルセッションコントローラが（境界コントローラとして）境界セッション制御機能を実行する場合、この方法は好ましい。ミラープロキシ機能は、未確認ＳＩＰエンドポイント上の管理者による制御をさらに可能にする。
【００９４】
図７は、境界制御およびコアセッション制御が同じ要素上になく、両方の方法をシステムに同時に配置できるシナリオを例示する。特に、境界コントローラ１００は、プロキシをコアコントローラ１０２に配置し、次にプロキシをアプリケーションサーバ１０４に設ける。
【００９５】
ミラープロキシを、境界コントローラ上に配置してもよい。要求−統一資源識別子による転送は、コアに配置される。また、呼ハンティングはコアで実行される。
【００９６】
以下、動的ピアの管理および生成について開示する。
【００９７】
マルチプロトコルセッションコントローラは、（動的エンドポイントとしても知られている）動的ピアを使用して、第三者レジストラに登録するユーザエージェントに対する呼および登録を管理する。デバイスおよび呼ピアの両方とも、実行時に生成および管理される。下記のステップでは、この状態を管理する方法について説明する。
【００９８】
ステップ１では、レジストラが２００ＯＫを返した場合、状態を成功登録上に生成する。２００ＯＫは、応答がうまく処理されていることを示すＳＩＰメッセージコードを意味する。登録が進行中である間、一時的な状態を維持する。動的呼ピアおよびデバイスを生成するために使用されるプロファイルは、テンプレートが見つかったかどうか、またはデフォルトが使用されているかどうかによって変わることがある。
【００９９】
ステップ２では、状態をあらゆる登録上でリフレッシュする。マルチプロトコルセッションコントローラは、レジスタに返された２００ＯＫメッセージに基づいてタイムアウトを維持する。エンドポイントがリフレッシュしない場合、それを削除する。
【０１００】
ステップ３では、状態を未登録上で削除する。
【０１０１】
ステップ４では、マルチプロトコルセッションコントローラは常時、レジストラにより割当てられる値および局所構成値の最小である（２００ＯＫメッセージに応答した）タイムアウト値を割当てる。
【０１０２】
ステップ５では、ネットワークアドレス変換状態は、動的デバイスに記憶され、ユーザエージェントに戻って呼をルーティングするシグナリング情報を維持する。
【０１０３】
ステップ６では、呼をルーティングする前回のホップをユーザエージェントに制限することにより、暗黙アクセス制御をすべての動的呼ピアに対して可能にすることができる。マルチプロトコルセッションコントローラは、エンドポイントが登録するプロキシ／レジストラに前回のホップをオープンまたは制限することを可能にする。
【０１０４】
ステップ７では、マルチプロトコルセッションコントローラ上でユーザエージェントにアクセスできる統一資源識別子は、ｕｓｅｒ＠ＭＳＣ−Ｒｅａｌｍ（ただし、登録はｕｓｅｒ＠ｐｒｏｘｙ用である）の形式である。
【０１０５】
ステップ８では、各動的呼ピアおよびデバイスは、一意のセッション開始プロトコル登録に対応し、一意のｒｅｇ−ｉｄ（およびゼロのポート）を有する。これによって、ユーザエージェントは、特にユーザエージェントとマルチプロトコルセッションコントローラとの間にネットワークアドレス変換機構がある場合、あるネットワークから別のネットワークに移動することができる。
【０１０６】
ステップ９では、動的エンドポイントは、登録が到着するレルムに属する。エンドポイントが移動し、レルムが変わる場合、マルチプロトコルセッションコントローラは、次の成功登録上でそのエンドポイントを更新する。
【０１０７】
テンプレートは、下記の機能を与える。第三者セッション開始プロトコルレジストラが登録に対する２００ＯＫメッセージに応答した場合、動的呼ピアを生成する。管理者は、これらの動的生成ピアに当てはまるポリシーを対応付けることができる。例えば、登録がどのサブネットから発信するかによって、これらのデバイスから来る呼をサイト特定メディアまたは呼許可制御ポリシーに対応付けることは、本発明の範囲内である。テンプレートが見つからない場合、マルチプロトコルセッションコントローラは、デフォルトパラメータを用いてデバイスおよび呼ピアを生成することが好ましい。
【０１０８】
テンプレートは、２つの主な機能を有する。第１の機能は、登録情報に基づいて非活動デバイスおよびバウンド呼ピアにポリシーを割当てることである。第２の機能は、登録情報に基づいて存在しないデバイスおよび呼ピアにポリシーを割当てることである。
【０１０９】
例えば、テンプレートは、そのＩＮ／ＭＡＴＣＨ基準としてサブネットＩＰアドレスおよびマスクを含むことができる。このサブネットからの第１の登録に関して、２つの可能性がある。
【０１１０】
呼ピアは、設置され、登録エイリアスを保持する。この場合、マルチプロトコルセッションコントローラは、テンプレートＩＮ／ＳＥＴおよびＯＵＴ／ＳＥＴパラメータを使用して、デバイスおよび呼ピア上の既存のパラメータを修正することができる。これは、例えば、ユーザエージェントがあるサブネットから別のサブネットに移動し、システムがそのサブネットから来る呼に新しいメディアルーティングポリシーを適用する場合に使用される。
【０１１１】
デバイスだけでなく呼ピアも存在しない場合、マルチプロトコルセッションコントローラは、ＩＮ／ＳＥＴおよびＯＵＴ／ＳＥＴパラメータを使用して、呼ピアおよびデバイスをインスタンス化する。ＩＮ／ＭＡＴＣＨおよびＯＵＴ／ＭＡＴＣＨパラメータは、プロトコルパラメータおよび生成状態に基づいてマルチプロトコルセッションコントローラにより初期化される。これは、例えば、セッション開始プロトコルユーザエージェントが第三者セッション開始プロトコルサーバに登録している場合に使用される。この場合のＯＵＴ／ＭＡＴＣＨパラメータは、セッション開始プロトコルＡ−Ｏ−Ｒ＝ｕｓｅｒ＠ＭＳＣ−Ｒｅａｌｍである。ＩＮ／ＭＡＴＣＨパラメータは、セッション開始プロトコルコンタクトアドレス＝ｕｓｅｒ＠Ｐｒｉｖａｔｅ−Ａｄｄｒｅｓｓであり、ユーザエージェントから来る呼をグループ化するために使用される。
【０１１２】
また、本マルチプロトコルセッションコントローラ（ＭＳＣ）は、課金の問題に取り組む。マルチプロトコルセッションコントローラは、すべての呼をルーティングするネットワークにおける中心点としての機能を果たすことができる。呼明細レコードは、ＡＳＣＩＩ／ＲＡＤＩＵＳを用いて各呼に対して生成され、ログ記録される。アプリケーションサーバ（ＡＳ）によりヘアピン止めされた（呼ＩＤまたはＣａｌｌｉｄにより識別される）呼の場合、呼フローは次の通りである。
【０１１３】
Ｃａｌｌｉｄ１→ＭＳＣ→Ｃａｌｌｉｄ２→ＡＳ→Ｃａｌｌｉｄ３→ＭＳＣ→Ｃａｌｌｉｄ４
そのような呼に対して生成される呼明細レコード（ＣＤＲ）は次の通りである。
【０１１４】
ＣＤＲ１（ＭＳＣ上）：Ｃａｌｌｉｄ１、Ｃａｌｌｉｄ２
ＣＤＲ２（ＡＳ上）：Ｃａｌｌｉｄ２、Ｃａｌｌｉｄ３
ＣＤＲ３（ＭＳＣ上）：Ｃａｌｌｉｄ３、Ｃａｌｌｉｄ４
所望の特別ＣＤＲ：Ｃａｌｌｉｄ１、Ｃａｌｌｉｄ４。すべてのこれらの呼明細レコードは、デバッグして全呼レッグを課金できることが望ましい。
【０１１５】
呼明細レコードを仲介して単一の呼明細レコードを生成できるために、幾つかの方法をとることができる。マルチプロトコルセッションコントローラは、ＩＭＳ料金ＩＤ（３ＧＰＰ）を実施し、それをＰ料金ベクトル（ＲＦＣ３４５５）の一部として挿入することができる。アプリケーションサーバは、このヘッダをサポートし、それをマルチプロトコルセッションコントローラに戻って中継する必要がある。これは、最善の解決策である。困ったことに、（ほとんどの場合、連続ユーザエージェントである）アプリケーションサーバはこのヘッダを未修正で渡す必要がある。この場合、マルチプロトコルセッションコントローラは、中間呼明細レコード（ＣＤＲ）としてＣＤＲ１〜３に特別に印を付け、最終呼明細レコードを生成する。
【０１１６】
３つの呼明細レコードを外部システム上に仲介して、最終呼明細レコードを生成することができる。
【０１１７】
トポロジ隠蔽機能を、マルチプロトコルセッションコントローラに直接登録された全エンドポイントに与える。マルチプロトコルセッションコントローラは、レルム間を行く呼、レルム内の呼、レルム間に流れるメディア、およびレルム内に流れるメディア（必要ならば）にこれらの機能を与える。
【０１１８】
相互運用性および相互作用機能の見出しで、下記が当てはまる。境界制御の場合、マルチプロトコルセッションコントローラは、セッション開始プロトコル連続ユーザエージェントおよびＨ．３２３連続ゲートウェイをアーキテクチャの構成要素として使用する。
【０１１９】
図８では、プロトコルスタックとも呼ばれているセッション制御アーキテクチャは、境界セッション制御機能（ＢＳＣＦ）ポリシー１０６が境界セッション制御機能（ＢＳＣＦ）１０８を与えると規定する。コアセッション制御機能（ＣＳＣＦ）１１２も同様である。ＢＳＣＦ１０８は、Ｈ．３２３ルーテッドゲートキーパ（ＧＫ）１１４、セッション開始プロトコル（ＳＩＰ）／Ｈ．３２３相互作用機能（ＩＷＦ）１１６、セッション開始プロトコル（ＳＩＰ）プロキシ／レジストラ１１８、およびセッション開始プロトコル（ＳＩＰ）アウトバウンドプロキシ（ＯＢＰ）１２０を生じさせる。一方、コアセッション制御機能（ＣＳＣＦ）１１２は、ＳＩＰプロキシ／レジストラ１１８およびＳＩＰ  ＯＢＰ１２０のみを生じさせる。
【０１２０】
Ｈ．３２３ルーテッドゲートキーパ１１４は、Ｈ．３２３ゲートキーパ１２２およびＨ．３２３ゲートウェイ１２４にアクセスする。ＳＩＰ／Ｈ．３２３相互作用機能は、Ｈ．３２３ゲートウェイ１２４およびＳＩＰユーザエージェント（ＵＡ）１２６にアクセスする。ＳＩＰユーザエージェントは、セッション記述プロトコル（ＳＤＰ）またはＳＩＰ−Ｔ（テレフォニー用セッション開始プロトコル）とも呼ばれている。ＳＩＰプロキシ／レジストラ１１８は、ＳＩＰレジストラ１３０にアクセスするだけでなく、ＳＩＰユーザエージェント１２６の上に位置する連続ユーザエージェント１２８にアクセスする。ＳＩＰアウトバウンドプロキシ（ＯＢＰ）１２０は、連続ユーザエージェント１２８にアクセスするだけである。
【０１２１】
Ｈ．３２３ゲートキーパ１２２、Ｈ．３２３ゲートウェイ１２４、ＳＩＰユーザエージェント１２６およびＳＩＰレジストラ１３０は、Ｈ．２２５／Ｈ．２３５／Ｈ．２４５構成要素１３２およびＳＩＰ  ＴＳＭ構成要素１３４により形成される層の上に位置する層を形成する。Ｈ．２２５／Ｈ．２３５／Ｈ．２４５構成要素は、Ｈ．２２５が狭帯域テレビ電話サービスを扱い、Ｈ．２３５がセキュリティおよび認証と関係し、Ｈ．２４５がチャネル使用法および性能を取り決めるＨ．２３２プロトコルスイートを記述する。
【０１２２】
このプロトコルアーキテクチャは、ＴＣＰ／ＵＤＰ層１３６、ＩＰ４とＩＰ６層１３８と１４０、および（底に）メディア処理層１４２を与える。
【０１２３】
図９は、ルックアップサーバ１４６、コーリングプランと仮想私設網（ＶＰＮ）１４８、およびレルム／ＣＡＣ（呼許可制御）１５０を含むポリシー１４４にアクセスするＳＩＰレジストラ１３０およびＨ．３２３ゲートキーパ１２２を含むポリシー構造を示す。
【０１２４】
図８のアーキテクチャは、ユーザ識別（ユーザ名および電話番号）、ネットワークトポロジ（ホスト名ドメイン）およびＳＩＰプロトコルヘッダ（「から」、「に」、「プライバシ」を含む）などのプロトコル情報だけでなく、アプリケーションの柔軟なマッピングを提供する。
【０１２５】
また、アーキテクチャは、ＳＩＰメッセージ、タイマ、状態機械および呼フローの十分な制御を提供する。これは、呼当事者とは無関係にメッセージの送出を可能にし、種々のアプリケーションにより使用される第三者制御（３ｐｃｃ）を可能にする。
【０１２６】
また、図８のアーキテクチャは、Ｈ．２２５およびＨ．２４５状態機械の十分な制御を提供する。初期Ｈ．２４５との相互作用、Ｈ．２４５トンネリング、Ｈ．３２３高速接続およびＨ．３２３  ｖ１（シスコ（Ｃｉｓｃｏ）呼マネージャにより使用されるスロースタート呼など）が提供される。アバヤ（Ａｖａｙａ）ＰＢＸなどのＨ．４６０．６に従う拡張高速接続を実現するエンドポイントとの相互作用も提供される。
【０１２７】
また、本アーキテクチャは、ＳＩＰとＨ．３２３との間の柔軟な相互作用を提供する。詳細には、映像などの先進サービスだけでなく、上述の特徴のうち何れかを使用する普通の音声呼を相互作用させることができる。Ｔ．３８ファックス相互作用などのファックス伝送もサポートされる。
【０１２８】
アクセスネットワーク呼許可制御は、呼ルーティング負荷平衡、提供サービスレベル保証（ＳＬＡ）を超える呼の拒否、またはオーバフロー呼に対する最善努力サービスの提供に使用される。ここで、呼ルーティングは、呼の宛先選択を意味する。
【０１２９】
マルチプロトコルセッションコントローラは、呼ピアおよび呼ピアグループに対する帯域幅制御だけでなく、呼ピアおよび呼ピアグループを含むシグナリング資源に対する高度な呼許可制御を提供する。シグナリング資源は、マルチプロトコルセッションコントローラ上で活動状態にある呼レッグ数を意味する。
【０１３０】
帯域幅測定は、エンドポイント（またはレルムまたはサブネットまたはｉエッジグループ）から発信または終了する呼レッグに基づいていない。例えば、ソフトスイッチ（エンドポイント）はＭＳＣを介してヘアピン止めされた呼を生成でき、メディアはエンドポイントを決して離れない。この場合、使用帯域幅はゼロであるけれども（関係している帯域幅間はゼロであるが、帯域幅内はゼロでない）、エンドポイント上に２つの呼レッグ（発信および終了呼レッグ）がある。
【０１３１】
ＭＳＣは、メディアが基礎ネットワークに流れる方法の制御下またはメディア経路にない場合でも、帯域幅制御を提供する。メディアを、ＭＳＣにより直接ルーティングする、または第三者メディアサーバを用いて制御することができる。ネットワークトポロジが、帯域幅制御に対して生成される論理グループに非常に似ている場合（上記ａ〜ｄ）、ＭＳＣは、帯域幅を使用する方法の制御を提供する。例えば、管理者は、サブネット１とサブネット２との間でメディアをルーティングする固定ネットワーク資源を有することができ、ＭＰＬＳネットワークを介してそれらのサブネットを接続できる。
【０１３２】
図１０では、ピアグループは、サブネットを束ねるのに使用され、サブネットのグループに基づいて呼許可制御を提供する。呼許可制御を、ピアレベルまたはピアグループレベルで実施することができる。
【０１３３】
メディアルーティングポリシーの設定は、本発明に従って与えられる。マルチプロトコルセッションコントローラによって、ピア、ピアグループおよびレルムの各々にメディアルーティングポリシーを設定することができる。各レベルで、２種類の異なるメディアルーティングポリシー、即ち、Ｘ内メディアルーティングおよびＸ間メディアルーティングを指定する。ここで、Ｘは、ピア、ピアグループまたはレルムのうち１つである。以下、これらのポリシーについて説明する。
【０１３４】
Ｘ内メディアルーティング下のピアポリシーの場合、ヘアピン止め呼に対するメディアルーティングポリシーを与える。ヘアピン止め呼は、発信および終了ピアが同じである呼である。Ｘ間メディアルーティング下のピアポリシーの場合、この呼と残りのピアとの間の呼に対するメディアルーティングポリシーを与える。
【０１３５】
Ｘ内メディアルーティング下のピアグループポリシーの場合、発信および終了ピアが同じピアグループにある呼に対してメディアルーティングポリシーを与える。Ｘ間メディアルーティング下のピアグループポリシーの場合、発信および終了ピアが異なるピアグループにある呼に対してメディアルーティングポリシーを与える。Ｘ内メディアルーティング下のレルムポリシーの場合、発信および終了ピアが同じレルムにある呼に対してメディアルーティングポリシーを与える。Ｘ間メディアルーティング下のレルムポリシーの場合、発信および終了ピアが異なるレルムにある呼に対してメディアルーティングポリシーを与える。
【０１３６】
これらの各々の場合、ポリシー定義は、２つの値、ポリシー優先順位およびポリシーのオン／オフから成る。優先順位は数値（整数）であり、高い値は高い優先順位を意味する。
【０１３７】
図１１では、ピアＡからピアＢへの呼の場合、元および宛先ピアに対する関連ポリシーを最初に判定する。例えば、呼は、同じピアグループ内の異なるピア間にあるが異なるレルム間にある場合もある。これは、元および宛先ピア上で、呼が下記のポリシー、ピア間ＭＲ（メディアルーティング）、ピアグループ内ＭＲまたはレルム間ＭＲによって変わることを意味する。次に、下記の階層構造を適用して、元または宛先ピアに適用できるメディアルーティングポリシーを判定する。ピアが指定メディアルーティング（ＭＲ）ポリシーを有する場合、そのポリシーを使用する。ピアグループが指定メディアルーティング（ＭＲ）ポリシーを有する場合、そのポリシーを使用する。レルムが指定メディアルーティング（ＭＲ）ポリシーを有する場合、そのポリシーを使用する。
【０１３８】
一旦各ピアに対するメディアルーティングポリシーを判定すると、優先順位（整数値）を使用して、どのポリシーが勝つかを判定する。
【０１３９】
図１１は、メディアルーティングポリシー構成の例を与える。ピアＡとピアＣとの間の不信頼リンク（上の例）１６４がオンの場合、ピアＢはオフであるが、ピアＡとＣはオンである。ＡとＢとの間およびＡとＣとの間のリンクがオンである不信頼ネットワーク（下の例）１６６の場合、ピアＡはオン、ピアＢとＣはオフである。
【０１４０】
以下、遠端ネットワークアドレス変換トラバーサルについて説明する。図１２に示すマルチプロトコルセッションコントローラ１７０は、セッション開始プロトコルアクセスネットワーク１７２上の任意の種類の一般ネットワークアドレス変換／ファイアウォール１７１（対称、完全円錐、制限円錐など）とインタフェースすることができる。ネットワークアドレス変換／ファイアウォールは、プロバイダの私設網１８２に、またはゲートウェイ１８０を介して公衆インターネットに企業／キャリア１７４、１７６および１７８を接続していることができる。
【０１４１】
すべてのセッション開始プロトコル要求メッセージの場合、メッセージのソースＩＰアドレスに経由ヘッダを一致させることにより、ネットワークアドレス変換機構自体の存在を検出する。そのような要求に対する応答は常時、要求が来るポートおよびソースＩＰに送り返される。また、マルチプロトコルセッションコントローラは、コンタクトを適切に登録するファイアウォールの後ろのセッション開始プロトコルユーザエージェントにより使用可能なＲＦＣ３５８１を実施する。
【０１４２】
セッション開始プロトコル登録は、次のように与えられる。マルチプロトコルセッションコントローラは、登録が来るポートおよびソースＩＰにファイアウォールの後ろのセッション開始プロトコルエンドポイントにより登録されるコンタクトをマッピングする。マルチプロトコルセッションコントローラは、シグナリングピンホールをオープンに保つ下記の機構を実施する。
【０１４３】
マルチプロトコルセッションコントローラは、登録がネットワークアドレス変換機構の後ろから来ていることを検出すると、マルチプロトコルセッションコントローラは、エンドポイントに割当てられた満了タイムアウトを下方に微調整する。使用されるデフォルトタイムアウトは、（管理者により設定可能な）２分である。他の方法と比べてこの方法を採用する考慮事項は幾つかある。ユーザデータグラムプロトコル（ＵＤＰ）結合をリフレッシュするネットワークアドレス変換機構用の提案機構は、アウトバウンドトラフィック（トラフィックは、ファイアウォールの後ろから来て、ネットワークアドレス変換機構の公衆側に行く）である。これは、結合がクローズされたずっと後に一部のハッカーが結合をオープンに保とうと試みることができる点で普通は安全の懸念がある。
【０１４４】
多数のメッセージおよびマルチプロトコルセッションコントローラ上に解析され生成されるべきメッセージを必要とするので、この方法はマルチプロトコルセッションコントローラにかなり高い負荷を持ち込むことがある。登録をアプリケーションサーバに定めた場合、登録は、アプリケーションサーバにも多くの負荷を生成することがある。マルチプロトコルセッションコントローラは、これらの登録をアプリケーションサーバに送信する周波数を低くするフィルタリング機構を提供する。また、マルチプロトコルセッションコントローラは、これらの登録を監視して、登録の何れが例外処理を必要とし、アプリケーションサーバに送信される必要があるかを調べる（例えば、ｃａｌｌｉｄ（呼ＩＤ）またはコンタクトまたは任意の他の登録統一資源識別子／コンタクトパラメータが変化している）。アプリケーションサーバ側のタイムアウトは、（アプリケーションサーバ構成に基づいてアプリケーションサーバにより下方に微調節可能な）１日である。例えば、アプリケーションサーバが６０分のタイムアウトを割当てた場合、マルチプロトコルセッションコントローラは、ネットワークアドレス変換機構の側で２分のタイムアウトが与えられると、結局３０回の登録ごとに転送することになる。
【０１４５】
また、マルチプロトコルセッションコントローラは、ＯＰＴＩＯＮＳパケットを用いてネットワークアドレス変換タイムアウトを検出する機構を提供することができる。ＯＰＴＩＯＮＳは、資源上で行われるべき方法に関連した要求ポケットヘッダ内のコマンドを意味する。可能な方法は、知られているように、Ｉｎｖｉｔｅ、Ａｃｈ、ｅｙｅ、Ｃａｎｃｅｌ、Ｏｐｔｉｏｎｓ、Ｒｅｇｉｓｔｅｒを含む。この機構は、理論的に可能であるが、ネットワークアドレス変換機構の非確定的な挙動が与えられると、確定的に作動する保証がない。ネットワークアドレス変換トラバーサルに対するエンドポイント／サブネット／レルムごとのタイムアウトが好ましい。
【０１４６】
静的エンドポイントは、登録しないがサポートされるセッション開始プロトコルゲートウェイである。静的ピンホールを、インバウンドシグナリングを通らせるファイアウォール上に設定する必要がある。
【０１４７】
メディアネットワークアドレス変換トラバーサルとシグナリングとの間の分離は、遠端シグナリングおよびメディアネットワークアドレス変換トラバーサルであり、図１３に示す。マルチプロトコルセッションコントローラは、シグナリングエンドＮＡＴトラバーサルから遠端ＮＡＴトラバーサルを分離し、構成によって制御される。例えば、マルチプロトコルセッションコントローラを図１３に示す構成で配置することができる。
【０１４８】
さて、ネットワークアドレス変換トラバーサルおよびメディアルーティングポリシーの独立性について説明する。エンドポイント上でネットワークアドレス変換機構トラバーサルを使用可能にすることは、マルチプロトコルセッションコントローラが、定められ、発信するすべての呼に対するメディアルーティングを制御することを意味しない。
【０１４９】
ネットワークアドレス変換機構トラバーサルのシナリオについて図１４、１５および１６を参照せよ。これらの各シナリオにおいて、管理者は、ネットワークアドレス変換機構トラバーサルを呼ピア上で使用可能にさせる。エンドポイントが動的であるシナリオでは、ネットワークアドレス変換機構トラバーサル用のそれらの構成を、大域構成ファイルまたはテンプレートから継承する。この構成は、シグナリングネットワークアドレス変換機構トラバーサルを使用可能にする。次に、呼ピアが一部である呼ピアグループ用のメディアルーティング構成を適用して、どのようにメディアをルーティングする必要があるかを判定する。
【０１５０】
ところで、リングバック問題（１８３→２００）について説明する。番号１８３および２００は、応答用のメッセージコードを意味する。ＳＩＰにおいて、メッセージコード１８３は、呼び出される電話の呼出音を意味し、メッセージコード２００は、ユーザが電話に出ており、始めた通話を終了することを意味する。２００ＯＫメッセージは、通話開始電話に送信される。マルチプロトコルセッションコントローラは、オプションとして、ＳＩＰ１８３メッセージを発信者に２００として合図して、リングバック問題を回避することを可能にする。このシグナリングを使用し、接続しない呼を、通常の方法で報告する。呼明細レコードの唯一の変更は、発信者に送信された最後のメッセージが２００ＯＫを示すことである。このシナリオにおいて発信者側で課金を行うことは望ましくない。この特徴は、テンプレートポートまたは実際の電話ポート上で構成可能である。この特徴をＳＴＵＮ（ＮＡＴを介したＵＤＰの単純トラバーサル）対応のクライアントに使用することは勧められない。これは、アプリケーションがネットワークアドレス変換機構の存在および種類を見つけるのを可能にするプロトコルである。
【０１５１】
ネットワークアドレス変換機構に関する問題は、発信者がメディアを送信する前に被呼者により送信される任意のメディアが短縮される場合があることを含む。上述の１８３→２００の変換は、被呼者が送信前でなく１８３と一緒にメディアを送信する場合、この問題を軽減する。上述の１８３→２００の変換に関して、２００以外の他の最終応答を被呼者側で受信した場合、マルチプロトコルセッションコントローラは発呼者の電話を切る。適切な理由ヘッダを、ＢＹＥメッセージで使用してもよい。１８３の後に来る３ｘｘ応答を続行しないことに留意せよ。
【０１５２】
これに対する別の解決策は、メディアサーバ／アプリケーションサーバを使用することである。マルチプロトコルセッションコントローラは、呼がネットワークアドレス変換機構の後ろのデバイスから来たことを検出した後に、呼をアプリケーションサーバにルーティングすることができる。アプリケーションサーバは、呼をメディアサーバに接続し、呼の第２のレッグでハントする。
【０１５３】
ＳＴＵＮ／ＩＣＥによるシステムとの対話：マルチプロトコルセッションコントローラ上で実施される遠端ＮＡＴトラバーサルは、ＲＦＣ３５８１を使用することもできるＳＴＵＮ／ＩＣＥによるシステムと完全互換性がある。
【０１５４】
以下、ジュニパ（Ｊｕｎｉｐｅｒ）ネットワークサービス配置システムとの統合およびサービス品質について説明する。
【０１５５】
マルチプロトコルセッションコントローラ１７０を、ジュニパネットワークＳＤＸシステムと統合することができる。ＳＤＸは、ＤＳＬ、Ｃａｂｌｅなどの種々のブロードバンドアクセス技術によってサービスを加入者に提供することができる。ＳＤＸは、ジュニパネットワークエッジルータ（ＥＲＸ）と連動し、必要に応じてサービスを起動できる。マルチプロトコルセッションコントローラ１７０は、（コアネットワークを所有し管理する）卸売業者または（加入者またはサービスを管理できる）小売業者により所有されることもある。図１７は、そのようなシステムにおけるマルチプロトコルセッションコントローラの位置決めを例示する。
【０１５６】
ＳＤＸゲートウェイ１９０は、外部構成要素が単純オブジェクトアクセスプロトコル（ＳＯＡＰ）インタフェース１９２を介してＳＤＸ構成要素と対話できるＳＤＸシステムの構成要素である（マルチプロトコルセッションコントローラは、コンテンツプロバイダウェブアプリケーションを使用する）。ＳＤＸゲートウェイは、ＥＲＸ（ジュニパネットワークＥＲＸシリーズエッジルータ）１９８を設定してネットワークを流れるメディアのために資源を確保するために共通オブジェクトポリシーサービス（ＣＯＰＳ）１９６を使用するＳＡＥ１９４にポリシーを通信する。
【０１５７】
簡単なセッション開始プロトコル呼フローを概説する。マルチプロトコルセッションコントローラがポリシーをＳＤＸに通信する前に流れ始めるメディアは、処理の正しいクラスを得ることができないかもしれない。Ｈ．３２３の場合、設定は同様である。マルチプロトコルセッションコントローラは、このシナリオで呼明細レコードにメディア／サービス品質統計データを記録しない。
【０１５８】
サービス品質および呼統計データの記録は、下記のように行われる。マルチプロトコルセッションコントローラは、品質記録および診断機能を可能にするために、下記のサービス品質および呼統計データを記録する。マルチプロトコルセッションコントローラがネットワーク内のメディアフローを制御している場合のみ、これらの統計データが記録される。
【表１】
2008527798.tif 000003
【表２】
2008527798.tif 000004
【０１５９】
音声およびファックスまたはファクシミリの場合、ＭＳＣをトランスコーディングすることが、音声およびファックスに対するトランスコーディングエンジンとしての機能を果たすことができる。トランスコーディングサービスは、流入ネットワークにより使用されるのと比べて異なるレベルの圧縮を必要とするアクセスネットワークに渡される呼に提供される。マルチプロトコルセッションコントローラは、外部メディア資源を配置してトランスコーディングを行うことができる。これらの資源を、アクセスネットワークに配置し、またはネットワークコアに集中してもよい。
【０１６０】
図１８に示すように、マルチプロトコルセッションコントローラ１７０は、下記のトランスコーディング機能、Ｇ．７２９⇔Ｇ．７１１、Ｔ．３８ファックス⇔Ｇ．７１１通過ファックス、およびＤＴＭＦ（デュアルトーン多周波数）トランスコーディング（ＲＦＣ２８３３によるＤＴＭＦ⇔Ｇ．７１１帯域内ＤＴＭＦ）を与える。
【０１６１】
トランスコーディング機能は、ＲＦＣ３５５０で定義されるＲＴＰ変換機構に準拠する。トランスコーディング機能は、セッション開始プロトコルおよびＨ．３２３呼の両方に使用可能であり、呼ごとに実行される。
【０１６２】
トランスコーディング資源の配置を、アクセスネットワークまたはコアネットワークに行ってもよい。マルチプロトコルセッションコントローラ１７０は、トランスコーディング資源をマルチプロトコルセッションコントローラにより制御することができるＭＳＣＰ（メディアサービス制御プロトコル）２００を使用することにより、トランスコーディング資源を制御する。マルチプロトコルセッションコントローラは常時、メディアがアクセスネットワークに出入りする点としての機能を果たす。
【０１６３】
マルチプロトコルセッションコントローラは、トランスコーディングの目的で下記のメディアゲートウェイを使用することができる。
【表３】
2008527798.tif 000005
【０１６４】
呼フローについて説明する。また、これらのフローは、ＭＳＣＰと独占ＴＰＮＣＰ（オーディオコード）との間で変換するＭＳＣＰゲートウェイを使用する。
【０１６５】
従って、本発明は、選択的メディアルーティング、第２層および第３層と、コーデック（符号化および復号化）と、ＭＯＳ（平均オピニオン評点）修飾子とを有する呼ルーティング、ＭＦＣＰおよびＭＦＣＰゲートウェイ、相互作用機能（ＩＷＦ）および映像、最小費用呼ルーティング用の統合システム、および最大収益呼ルーティング用の統合システムを含む改良を提供する。本発明の実施形態に特有のこれらの特徴は、この技術に重要な差別化を与える。
【０１６６】
平均オピニオン評点（ＭＯＳ）は、通信ネットワーク上の音声を聴取する人のユーザにより主観的に知覚されるものと音声通信の相対的品質を判定する段階評価である。一方向の遅延および信号損失は、平均オピニオン評点の重要な係数であるが、他の係数も人のユーザの知覚を生じさせる。
【０１６７】
選択的メディアルーティングが提供されている。本技術は、シグナリングおよび伝達ネットワークの分離を可能にする。しかし、通常、シグナリングおよび／または伝達は、ある特定のネットワーク要素を介して、サービス品質を監視して実施し、ネットワークルートなどを最適化するようにさせる。
【０１６８】
選択的メディアルーティングは、最小量の構成で動的に呼ルーティングを行うネットワークサービスプロバイダに制御を提供する。選択的メディアルーティングポリシーは、流入または流出呼ピアポリシーに基づく。優先順位値およびオン／オフの両方に対する基準は、信頼境界の生成に基づくネットワーク設計である。ピアがネットワークオペレータの信頼境界内にすべて存在する場合、メディアルーティングを行う必要はない。従って、信頼境界内で呼を処理するように設計されているピアの大部分は、「オフ」に設定されたポリシーに対するデフォルト値を有する。しかし、ネットワークのエッジにおけるピアは、不信頼ネットワークからルーティングされた呼を有する場合もある。呼が不信頼ネットワークから来た場合、そのような呼は、ルーティングされたメディアであるべきである。その結果、優先順位値をエッジピアに設定する。優先順位値の値が不信頼ピアの優先順位値よりも低い場合、不信頼ピアのメディアルーティングポリシーは引き継ぎ、メディアルーティングが行われる。
【０１６９】
マルチプロトコルセッションコントローラ１７０を信頼境界２４０で接続し、信頼境界を越えてエンドポイントＣ２４２にメディア通信を提供する例について、図２０を参照せよ。エンドポイントＡおよびＢ２４４および２４６は、信頼境界２４０内にある。エンドポイントＣ用の優先順位は、値がオンに設定された状態で１０であるが、エンドポイントＡ２４４用の優先順位は、値がオフで５であり、エンドポイントＢ用の優先順位は、値がオフで５である。
【０１７０】
下記の表は、信頼ネットワークと不信頼ネットワークとの間の通信でメディアルーティングを使用するか否かの概要を与える。
【表４】
2008527798.tif 000006
【０１７１】
図１９に移って、同図はマルチプロトコルセッションコントローラ１７０の物理アーキテクチャを示す。二重ＣＰＵ処理装置２１０は、ネットワークプロセッサカード２１２と適合する。動作構成要素は、メディアファイアウォール制御プロトコル（ＭＦＣＰ）２１８とのインタフェースとしてファイアウォール制御エンティティ（ＦＣＥ）２１６を有する呼処理装置２１４を含む。ＭＦＣＰ２１８は、シグナリングおよび伝達チャネルの分離を可能にする、ｉＸＰ２４００（２２２）上のセッションフィルタとＭＦＣＰサーバ２２０を介して通信する。
【０１７２】
メディアルーティング機能は、この明細書においてその他の箇所で説明されている。
【０１７３】
さて、修飾子を有する呼ルーティングについて説明する。呼ルーティングの従来の概念は、呼に対する電話番号に基づいてどのトランクを「スイッチ」オンにするかに関する決定、および／または発信トランクを含む。しかし、ＶｏＩＰによる呼ルーティングでは、本発明は、ＶＬＡＮ  ＩＤ（仮想ＬＡＮ識別子）などの第２層の識別子と、ＤｉｆｆＳｅｒｖ／ＴＯＳマーキングなどの第３層の識別子と、呼に対するコーデック（符号化および復号化デバイス）基本設定と、宛先／発信へのおよび／またはからの前の呼に対する平均オピニオン評点（ＭＯＳ）修飾子とを有する呼ルーティングを含むようにその概念を広げている。本呼ルーティングは、呼ルーティングを制御することにより、呼の高いサービス品質を保証することができる。
【０１７４】
修飾子を有する呼ルーティングでは、基準を使用して第２層および第３層の構成要素を識別する。第２層および第３層の修飾子を使用して、ソースを識別すると共に、流出ネットワーク用のマーカを設定し、そのサービス品質用に使用する。通常の第２層修飾子は、ＶＬＡＮタグおよび優先ビットである。ＶＬＡＮタグはＩＥＥＥ規格８０２．１Ｑで指定され、優先ビットはＩＥＥＥ規格８０２．１ｐで指定される。ＶＬＡＮタグを用いて、本マルチプロトコルセッションコントローラは、所与の呼ピアから呼およびメディアのソースを識別することができる。一旦流入呼ピアを識別すると、適切なポリシーを呼に適用することができる。第３層の識別子は通常、一意に識別可能なＩＰアドレスおよびＩＰサブネットアドレスである。
【０１７５】
平均オピニオン評点（ＭＯＳ）は、マルチプロトコルセッションコントローラにより使用され、着信メディアストリームを見て、ジッタ、待ち時間およびパケット損失を測定することにより得られる。ＭＯＳ評点の計算は、ＩＴＵ−Ｔ規格Ｅ−モデル（Ｇ．１０７）に基づいている。図２１は、ＭＯＳおよびＥ−モデル用の音声品質測定を例示する。マルチプロトコルセッションコントローラ１７０は、アクセスネットワーク２５２上のエンドポイントＡ２５０とプロバイダネットワーク２５６上のエンドポイントＢ２５４との間に設けられている。呼品質の測定は、ジッタおよびパケット損失に基づいており、エンドポイントＡ２５０からエンドポイントＢ２５４への通信に対する順方向測定およびエンドポイントＢ２５４からエンドポイントＡ２５０への通信に対する逆方向測定として行われる。
【０１７６】
メディアファイアウォール制御プロトコル（ＭＦＣＰ）ゲートウェイが設けられる。シグナリングおよびメディアネットワークを分離し、シグナリングおよびメディアを独立して基準化するために、「制御」プロトコルを指定した。この制御プロトコルは、メディアファイアウォール制御プロトコル（ＭＦＣＰ）２１８と呼ばれている。メディアファイアウォール制御プロトコルを使用して、ファイアウォール、メディアサーバおよびエッジルータを制御することができる。しかし、ファイアウォール、メディアサーバおよびエッジルータは、それらのシステムに対するポリシーを更新するそれら自身の制御プロトコルを実施していることがある。本発明は、ＭＦＣＰを入力として取り、そのＭＦＣＰをファイアウォール、メディアサーバまたはエッジルータの適切な制御プロトコルに変換するＭＦＣＰゲートウェイと呼ばれる論理エンティティを提供する。
【０１７７】
相互作用機能（ＩＷＦ）および映像が与えられる。相互作用機能（ＩＷＦ）は、ＶｏＩＰレルムにおける呼をセットアップするために広く使用されるＳＩＰおよびＨ．３２３呼セットアッププロトコル間の変換を含む。ＳＩＰとＨ．３２３との間のマッピングは、あまり簡単ではなく、これまで大まかに指定されている。本技術は、ＳＩＰとＨ．３２３との間のシームレス変換、またその逆も提供する。しかし、メディアとして映像および音声を送信することを伴う呼または映像呼は、解決するのが困難な問題である。ＳＩＰとＨ．３２３との間の映像機能のマッピングは、まだ十分にわからず、まだ十分に文書化されていない。本技術は、映像呼用のＳＩＰ−Ｈ．３２３  ＩＷＦも含む。
【０１７８】
本発明は、最小費用呼ルーティング用の統合システムを提供する。呼ルーティングの費用には、ポストダイヤル遅延（ＰＤＤ）、応答起動率（ＡＳＲ）、平均オピニオン評点（ＭＯＳ）などの品質パラメータだけでなく、ルートを売買する実際のドル費用を含む多くの要因がある。ルートを売買する実際のドル費用は、ネットワーク管理者により知られており、ネットワーク管理者により入力され、セッションコントローラにより利用される。品質要因を測定することができ、測定値はセッションコントローラにより利用される。本セッションコントローラは、（ＰＤＤ、ＡＳＲ、ＭＯＳなどの品質パラメータにより測定されるような）ユーザの経験だけでなく（そのルート上で）仕事をするネットワークオペレータの実際の費用を含む費用のこの複合的な考えを利用するので、ネットワークオペレータは、収益と操作の両方に対して非常に最適化されたネットワークを有することができる。
【０１７９】
自分たちの顧客への主要なサービスがネットワーク通過であるネットワークオペレータは、通話を伝える自分たちの費用が、ＶｏＩＰ呼を定める場所に左右され、その呼が自分たちの相手のネットワークを通るだけでなく自分たちのネットワークを通る経路によって変わることが分かる。従って、ネットワークオペレータは、最小費用ルーティング（ＬＣＲ）と呼ばれる技法を用いて自分たちのネットワークを通る呼ごとに通過しようとする。
【０１８０】
ｉＶＭＳ付きの本セッションコントローラは、ＬＣＲを行う方法を提供する。本セッションコントローラは、ネットワークオペレータによりセットアップされるポリシーに基づいてすべてのＶｏＩＰ呼をルーティングする。ｉＶＭＳシステムは実際に、ネットワークを通る種々の経路に対する料金を取り入れ、本セッションコントローラが処理するあらゆる呼の最小費用ルーティングをもたらす最適な組のポリシーを計算することができる。
【０１８１】
本発明は、最大収益呼ルーティング用の統合システムを提供する。一旦ネットワークオペレータが最小費用ルーティング（ＬＣＲ）を行う正しいポリシーを有すると、ネットワークオペレータは、自分たちのネットワークを通るあらゆる呼で得られる収益を考慮する必要もある。収益を最大にするために、ネットワークオペレータは、自分たちのネットワークを通る輸送または終了用の最小費用ルーティングだけでなく、発信収入も考慮する必要がある。この動作モードは、終了の総合費用の考慮を含み、ＬＣＲの上にポリシー層を与えるが、それと直交する場合もある。
【０１８２】
ｉＶＭＳ付きの本セッションコントローラは、最大収益ルーティング（ＭＰＲ）を行う方法を提供する。本セッションコントローラは、ネットワークオペレータによりセットアップされるポリシーに基づいてすべてのＶｏＩＰ呼をルーティングする。ｉＶＭＳシステムは、種々の通過および／または終了に対するドル相場だけでなく、発信に対する料金も入力として取り入れ、ＭＰＲをもたらす適切なポリシーを計算することができる。次に、これらのポリシーをｉＶＭＳから直接セッションコントローラに入力し、ネットワークオペレータ用のＭＰＲをもたらす。
【０１８３】
好ましい実施形態の別の特徴において、システムは、メモリ内データベースを使用する。図２２では、マルチプロトコルセッションコントローラポリシーデータベース（以下、単に「データベース」と呼ぶ）を、マルチプロトコルセッションコントローラを実行するために使用される計算プラットフォームのランダムアクセスメモリ（ＲＡＭ）のメモリ内およびハードドライブディスク上の永続データベースとして実行時マルチプロトコルセッションコントローラ上に２つの形態で記憶する。マルチプロトコルセッションコントローラのアプリケーションを起動すると、ディスク上の永続データベース（「Ｐ−ＤＢ」）を、読取り、マルチプロトコルセッションコントローラにより取り扱われる各呼を処理するために必要なポリシー情報の高速照会用のメモリ（「Ｍ−ＤＢ」）内に記憶する。
【０１８４】
マルチプロトコルセッションコントローラにより取り扱われるあらゆる呼は、ポリシールックアップを必要とする。メモリ内データベースＭ−ＤＢは、呼を処理するために必要なポリシー情報用のリポジトリを与える。高性能がマルチプロトコルセッションコントローラに要求されるので、これらのポリシールックアップは下記の特性を有する必要がある。問い合わせ時間は、最小である必要があり、システムにおける他の活動のために同じ負荷条件下で変わってはならず、取り扱われる同時呼の数の増加につれて、問い合わせ時間は直線的または指数的に増加すべきでない。
【０１８５】
メモリ内データベースＭ−ＤＢは、これらの制約を満たすように設計された。メモリ内データベースを多数の「データベーステーブル」に編成して、ポリシーデータを構成する。メモリ内データベースは、ＳＱＬなどの標準の問い合わせ言語インタフェースを他のプログラムにさらさない。プログラム的アプリケーションプログラミングインタフェース（ＡＰＩ）は、ＧＩＳ（呼プロセッサ）、Ｊｓｅｒｖｅｒ（設定エージェント）およびＣＬＩ（コマンドラインインタフェース）などの、マルチプロトコルセッションコントローラの構成要素により使用される永続データベースＰ−ＤＢ上に原子動作を与える。１つの実施形態において、メモリ内データベースは、下記のテーブル、呼ルートテーブル、エンドポイントテーブル、呼プラン結合テーブル、呼許可制御（ＣＡＣ）テーブル、トリガテーブル、ＶＰＮテーブル、およびレルムテーブルを含む。
【０１８６】
出来るだけ迅速にデータベースを問い合わせるために、各テーブルに多数回索引を付け、（従来のデータベース専門用語で）多数「キー」をもたらす。このテーブル構造の革新的な面は、電話番号などの幾つかのキーが一意であっても各キーが一意である必要がないことである。これらの各キーに対する探索技法は異なることもある。メモリ内データベースＭ−ＤＢ内で使用される探索技法には、二分探索、ハッシュ探索、および三分探索木がある。
【表５】
2008527798.tif 000007
【０１８７】
本システムの態様によれば、非同期ライトスルーが与えられる。永続データベースＰ−ＤＢは、メモリ内データベースＭ−ＤＢに記憶された情報に永続性を与える。従って、Ｍ−ＤＢおよびＰ−ＤＢ内の情報は、同じであるはずであり、非常に長く同期が取れなくなることはない。任意の時点で、稼働中のマルチプロトコルセッションコントローラでは、メモリ内データベースＭ−ＤＢは、永続データベースＰ−ＤＢよりも信頼できる情報を保持する。そういうものだから、どんな情報を永続データベースＰ−ＤＢに書き込もうとも、メモリ内データベースＭ−ＤＢにも情報を書き込む必要があり、またその逆もある。しかしながら、永続データベースＰ−ＤＢから読取るおよび永続データベースＰ−ＤＢを更新するいくつかの方法がある。一般的なアプリケーションプログラミングインタフェース（ＡＰＩ）を使用して、データベースとインタフェースをとる。永続データベースＰ−ＤＢとのＡＰＩは、ＣＬＩ（コマンドラインインタフェース）、ＧＩＳ（呼プロセッサ）およびＪｓｅｒｖｅｒ（設定エージェント）処理により使用される。
【０１８８】
これは、メモリ内データベースＭ−ＤＢの「ライトスルー」を介して永続データベースＰ−ＤＢを更新する処理である。メモリ内データベースＭ−ＤＢは常時、永続データベースＰ−ＤＢを更新する前にまず更新される。
【０１８９】
永続データベースＰ−ＤＢとのＡＰＩは、透過的にメモリ内データベースＭ−ＤＢを更新する。また、ＡＰＩは、永続データベースＰ−ＤＢを更新する前にまずメモリ内データベースＭ−ＤＢを更新する。この副作用は、Ｐ−ＤＢを実際に更新する前にＭ−ＤＢの同じテーブルへの多くの完遂が行われる場合があることである。そのような場合、永続データベースＰ−ＤＢは、完遂された最後の最も信頼できる更新を有するだけである。これは、２つの原理、非同期性およびデータ独立更新を用いてＡＰＩにより実現される。
【０１９０】
非同期性を用いた更新において、ＡＰＩは情報の非同期更新を行う。データベースに完遂するＡＰＩに与えられる任意の情報は、最初にメモリ内データベースＭ−ＤＢに更新され、次に永続データベースＰ−ＤＢへの更新用のキューに入れられる。ディスク更新はオペレーティングシステムスケジューリング介入を必要とするので、キューイングは必要であり、ディスクの大量更新は、ディスクへの複数散発的書込みよりも効率的である。しかし、情報は、メモリ内データベースＭ−ＤＢにすでに完遂されており、従って、キューイング用のすべての処理に利用できる。
【０１９１】
メモリ内データベースＭ−ＤＢを更新する場合、ＡＰＩは、キーをテーブルに使用するだけであり、データ自体を知らない。従来のデータベース構造化照会言語（ＳＱＬ）によるシステムにおいて、完遂コマンドも、更新されるべきデータを伝送する。しかし、ここでＡＰＩは、キーを知るだけであり、データ自体を知らない。データはＡＰＩを通さない。ＡＰＩがキーを使用して正しい項目を見つけるとすぐに、データの完遂が１つの操作で行われる。以後の完遂が同じキー上で動作すると、永続データベースＰ−ＤＢへの完遂キューが終了する前でも、メモリ内データベースＭ−ＤＢ内のデータは再度更新される。
【０１９２】
データベースの非同期ライトスルー手続きは、情報が高性能アプリケーションに常時利用できること、連続性および情報の保全性を維持すること、および情報の永続性を透過的に維持することを含む多くの利益を与える。
【０１９３】
従って、パケット交換網上の音声およびリアルタイムまたは少なくとも略リアルタイム通信用のシステムと方法が提供される。本システムは、コアコントローラまたは境界コントローラとして配置可能なマルチプロトコルセッションコントローラを含む。本セッションコントローラは、選択的メディアルーティング、第２層および第３層と、コーデック（符号化および復号化）と、ＭＯＳ（平均オピニオン評点）修飾子とを有する呼ルーティング、ＭＦＣＰおよびＭＦＣＰゲートウェイ、相互作用機能（ＩＷＦ）および映像、最小費用呼ルーティング用の統合システム、最大収益呼ルーティング用の統合システム、およびメモリ内データベースを提供する。
【０１９４】
当業者によって他の修正および変更を示唆することができるけれども、業界に対する寄与の範囲内に合理的かつ適切に入るように、ここで保証される特許の範囲内ですべての変更および修正を具体化することは、発明者の意図するところである。
【図面の簡単な説明】
【０１９５】
【図１】本発明の原理による遠隔通信システムアーキテクチャの略図である。
【図２】呼ピア、グループ、デバイスおよびテンプレートを含む、マルチプロトコルセッションコントローラポリシーデータベースの要素のブロック図である。
【図３】呼ルーティング処理における１つの流入呼ピアおよび１つの流出呼ピアの対応付けを示すブロック図である。
【図４】呼ルーティング処理用のデータベースポリシーモデルのブロック図である。
【図５】マルチプロトコルセッションコントローラ上の呼ルーティングのブロック図である。
【図６】誤りコード取り扱い処理のブロック図である。
【図７】セッションおよび境界制御を同時に配置するシステムのブロック図である。
【図８】セッション制御アーキテクチャのブロック図である。
【図９】ポリシーのブロック図である。
【図１０】ピアグループごとの呼許可制御の略図である。
【図１１】メディアルーティングポリシー構成の略図である。
【図１２】マルチプロトコルセッションコントローラ上のファイアウォールトラバーサルの略図である。
【図１３】遠端ネットワークアドレス変換機構トラバーサル上のメディアと信号との間の分離の略図である。
【図１４】単一のファイアウォールを介したネットワークアドレス変換機構トラバーサル用の第１のシナリオの略図である。
【図１５】分散型ファイアウォールを介したネットワークアドレス変換機構トラバーサル用の第２のシナリオの略図である。
【図１６】２つのファイアウォールを介したネットワークアドレス変換機構トラバーサル用の第３のシナリオの略図である。
【図１７】ＳＤＸゲートウェイクライアントとしてのマルチプロトコルセッションコントローラの略図である。
【図１８】ネットワークコアにおける共用トランスコーディング資源の略図である。
【図１９】本発明によるマルチプロトコルセッションコントローラの物理アーキテクチャの図である。
【図２０】不信頼ネットワークにメディア通信を提供する信頼ネットワーク内のセッションコントローラの略図である。
【図２１】本セッションコントローラを用いた呼品質の測定の略図である。
【図２２】メモリ内データベースの略図である。
【図１】
2008527798.tif 000008
【図２】
2008527798.tif 000009
【図３】
2008527798.tif 000010
【図４】
2008527798.tif 000011
【図５】
2008527798.tif 000012
【図６】
2008527798.tif 000013
【図７】
2008527798.tif 000014
【図８】
2008527798.tif 000015
【図９】
2008527798.tif 000016
【図１０】
2008527798.tif 000017
【図１１】
2008527798.tif 000018
【図１２】
2008527798.tif 000019
【図１３】
2008527798.tif 000020
【図１４】
2008527798.tif 000021
【図１５】
2008527798.tif 000022
【図１６】
2008527798.tif 000023
【図１７】
2008527798.tif 000024
【図１８】
2008527798.tif 000025
【図１９】
2008527798.tif 000026
【図２０】
2008527798.tif 000027
【図２１】
2008527798.tif 000028
【図２２】
2008527798.tif 000029
【手続補正書】
【提出日】平成19年8月29日(2007.8.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークと通信するように構成され、呼に対する流入呼ピアをポリシーに対応付けるように構成されているセッションコントローラであって、前記呼に対する流出呼ピアを識別するように構成されているセッションコントローラと、
前記セッションコントローラと通信するように構成されているシグナリングスイッチと、
前記セッションコントローラと通信するように構成されている管理システムであって、前記セッションコントローラに関する性能データを記録するように構成されている管理システムと、
前記セッションコントローラによりアクセスされるように構成されているデータベースであって、複数の呼に対応付けられるポリシーを記憶するように構成されているデータベースとを含み、
前記セッションコントローラがメディアルーティングポリシーに基づいて選択的メディアルーティングを行うように構成され、前記選択的メディアルーティングが、ピア、ピアグループまたはレルムのうち少なくとも１つごとにメディアルーティングを設定することを含み、
前記セッションコントローラが、（ピア／ピアグループ／レルム）内の呼に対する（ピア／ピアグループ／レルム）内ルーティングおよび（ピア／ピアグループ／レルム）間の呼に対する（ピア／ピアグループ／レルム）間ルーティングのうち少なくとも１つを指定するように構成されている、装置。
【請求項２】
ネットワークと通信するように構成されるセッションコントローラを設けるステップと、
前記セッションコントローラと通信するように構成されるシグナリングスイッチを設けるステップと、
前記セッションコントローラと通信するように構成される管理システムを設けるステップと、
７層開放型システム間相互接続（ＯＳＩ）モデルのうち第１の層に対応付けられる第１の要素に対応付けられる識別子、前記７層ＯＳＩモデルのうち第２の層に対応付けられる第２の要素に対応付けられる識別子、呼に対応付けられるコーデック基本設定、および前記呼に対する発信元デバイスおよび宛先デバイスに対応付けられる複数の前呼に対応付けられる平均オピニオン評点修飾子に基づいて前記ネットワーク内で呼のルートを前記セッションコントローラで制御するステップとを含む、方法。
【請求項３】
前記第１の層が前記７層ＯＳＩモデルのうち第２層であり、前記第２の層が前記７層ＯＳＩモデルのうち第３層である、請求項２に記載の方法。
【請求項４】
ネットワークと通信するように構成されているセッションコントローラと、
ファイアウォール、メディアサーバ、またはエッジルータのうち少なくとも１つに定義されているメディアファイアウォール制御プロトコルを受信するように構成されているメディアファイアウォール制御プロトコルゲートウェイであって、前記ファイアウォールに対応付けられる制御プロトコル、前記メディアサーバに対応付けられる制御プロトコル、または前記エッジルータに対応付けられる制御プロトコルのうち少なくとも１つに前記メディアファイアウォール制御プロトコルを変換するように構成されているメディアファイアウォール制御プロトコルゲートウェイとを含む、装置。
【請求項５】
前記メディアファイアウォール制御プロトコルゲートウェイが論理エンティティである、請求項４に記載の装置。
【請求項６】
コアコントローラとしてネットワークと通信するように構成されるセッションコントローラを設けるステップと、
前記セッションコントローラと通信するように構成されるシグナリングスイッチを設けるステップと、
前記セッションコントローラと通信するように構成される管理システムを設けるステップと、
セッション開始プロトコルエンドポイントとＨ．３２３エンドポイントとの間で複数の呼に対応付けられるメディアを変換することを含む相互作用機能を前記セッションコントローラで実行するステップとを含む、方法。
【請求項７】
前記相互作用機能が、前記セッション開始プロトコルエンドポイントと前記Ｈ．３２３エンドポイントとの間の前記複数の呼に対する映像の変換を含む、請求項６に記載の方法。
【請求項８】
ネットワークと通信するように構成されているセッションコントローラであって、流入呼を受信するように構成されているセッションコントローラと、
前記セッションコントローラが、ネットワーク容量、呼ピア帯域幅、またはそれぞれの閾値に対して前記流入呼に対応付けられる多くの活動呼レッグのうち少なくとも１つを比較するようにさらに構成されており、
前記セッションコントローラが、前記それぞれの閾値を超えた場合、前記流入呼を拒否するようにさらに構成されており、
前記セッションコントローラと通信するように構成されているシグナリングスイッチと、
前記セッションコントローラと通信するように構成されている管理システムと、
高速呼処理に対応付けられるメモリ内データベースであって、前記メモリ内データベースがハードディスクメモリ上に記憶される永続データベースの一部を含み、前記一部が揮発性メモリに記憶され、前記セッションコントローラが前記メモリ内データベースまたは前記永続データベースのうち少なくとも１つにおける任意のデータとは無関係に前記メモリ内データベースと前記永続データベースとの間にデータを非同期的に書き込むように構成されている、メモリ内データベースとを含む、装置。
【請求項９】
前記セッションコントローラが、前記流入呼が設定サービスレベル保証を超えた場合に前記流入呼を拒否するようにさらに構成されている、請求項８に記載の装置。
【請求項１０】
前記セッションコントローラが、呼負荷バランスの表示に基づいて前記流入呼を拒否するようにさらに構成されている、請求項８に記載の装置。
【請求項１１】
前記セッションコントローラが、最善努力サービスレベルの表示に基づいて前記流入呼を拒否するようにさらに構成されている、請求項８に記載の装置。
【請求項１２】
ネットワークと通信するように構成されているセッションコントローラと、
高速呼処理に対応付けられるメモリ内データベースであって、前記メモリ内データベースがハードディスクメモリ上に記憶される永続データベースの一部を含み、前記一部が揮発性メモリに記憶され、前記セッションコントローラが前記メモリ内データベースまたは前記永続データベースのうち少なくとも１つにおける任意のデータとは無関係に前記メモリ内データベースと前記永続データベースとの間にデータを非同期的に書き込むように構成されている、メモリ内データベースと、
前記セッションコントローラが、流入呼を受信するように構成されており、
前記セッションコントローラが、前記流入呼に対応付けられる流入呼ピアに対して前記メモリ内データベースまたは前記永続データベースのうち少なくとも１つを問い合わせるようにさらに構成されており、
前記セッションコントローラが、前記メモリ内データベースまたは前記永続データベースのうち少なくとも１つの問い合わせ時に前記流入呼ピアが識別されない場合、前記流入呼に対応付けられる動的ピア定義テンプレートに対して前記メモリ内データベースまたは前記永続データベースのうち少なくとも１つを問い合わせるようにさらに構成されており、
前記セッションコントローラが、前記メモリ内データベースまたは前記永続データベースのうち少なくとも１つの問い合わせ時に前記動的ピア定義テンプレートが識別されない場合、前記流入呼を拒否するようにさらに構成されており、
前記セッションコントローラと通信するように構成されているシグナリングスイッチと、
前記セッションコントローラと通信するように構成されている管理システムとを含む、装置。
【請求項１３】
前記セッションコントローラが、前記流入呼に対応付けられる流入呼ピアグループに対して前記メモリ内データベースまたは前記永続データベースのうち少なくとも１つを問い合わせるようにさらに構成されており、前記流入呼ピアグループに対する前記データベースの問い合わせ時に前記流入呼ピアグループが識別されない場合、前記動的ピア定義テンプレートに対して前記メモリ内データベースまたは前記永続データベースのうち少なくとも１つを問い合わせるようにさらに構成されている、請求項１２に記載の装置。
【請求項１４】
前記セッションコントローラが、呼負荷バランス閾値に基づいて前記流入呼を拒否するようにさらに構成されている、請求項１２に記載の装置。
【請求項１５】
前記セッションコントローラが、オーバフロー呼に対応付けられる最善努力サービス閾値に基づいて前記流入呼を拒否するようにさらに構成されている、請求項１２に記載の装置。
【請求項１６】
ネットワークと通信するように構成されているセッションコントローラと、
前記セッションコントローラと通信するように構成されているシグナリングスイッチと、
前記セッションコントローラと通信するように構成されている管理システムと、
高速呼処理用のメモリ内データベースであって、前記メモリ内データベースがハードディスクメモリ上に記憶される永続データベースの一部を含み、前記一部が揮発性メモリに記憶され、前記セッションコントローラが前記メモリ内データベースまたは前記永続データベースのうち少なくとも１つにおける任意のデータとは無関係に前記メモリ内データベースと前記永続データベースとの間にデータを非同期的に書き込むように構成されている、メモリ内データベースとを含む、装置。
【請求項１７】
前記セッションコントローラが、ミラープロキシまたはアウトバウンドプロキシのうち少なくとも１つの機能を果たすように構成されている、請求項１６に記載の装置。
【国際調査報告】
2008527798.tif 000030