(57)【要約】メディア・サーバ・リソースを管理する方法を開示する。或る実施形態では、メディア・サーバ・リソース・ブローカ（１４０）が、メディア・サーバ・リソース・セットを求める要求をアプリケーション・サーバ（１２０）から受信する。メディア・サーバ・リソース・ブローカは、そのサービス要求が、第１のメディア・サーバ（１６０）によって扱われるべきことを、要求のタイプ、および第１のメディア・サーバの利用可能性に基づいて決定し、第１のメディア・サーバのアドレスをアプリケーション・サーバに提供する。別の実施形態では、ＩＰノード（２１０）が、サービス要求を提供する。アプリケーション・サーバ（１２０）が、そのサービス要求を受信し、メディア・サーバ・リソースを求める要求をメディア・サーバ・リソース・ブローカ（１４０）に送信する。メディア・サーバ・リソース・ブローカは、その要求が、第１のメディア・サーバ（１６０）によって扱われるべきであると判定する。メディア・サーバ・リソース・ブローカは、第１のメディア・サーバに問い合わせて、ＩＰノードと第１のメディア・サーバの間でコールを確立する際に使用するためのＩＰアドレスおよびポート番号を獲得する。次に、メディア・サーバ・リソース・ブローカは、ＩＰノードが、メディア・サーバ上の適切なポートとコールを確立することができるように、ＩＰノードに信号を提供する。【特許請求の範囲】
【請求項１】
ＩＰノード（２１０）にサービスを提供する方法であって、
（ａ）アプリケーション  サーバ（１２０）において前記ＩＰノードからサービス要求を受信すること、
（ｂ）前記サービス要求に応答して、メディア  サーバ  リソース  ブローカ（１４０）からメディア  サーバ  リソースを要求すること、
（ｃ）前記メディア  サーバ  リソース  ブローカを使用して、第１のメディア  サーバ（１６０）の選択を前記アプリケーション  サーバに提供し、前記メディア  サーバ  リソース  ブローカは、メディア  サーバ  セットからの前記第１のメディア  サーバを、メディア  サーバ  リソースを求める前記要求、および前記メディア  サーバ  セットの中のメディア  サーバの利用と関係する１つまたは複数のパラメータに応答して、選択すること、
（ｄ）前記ＩＰノードと前記第１のメディア  サーバの間でコールを確立すること、ならびに
（ｅ）前記アプリケーション  サーバから前記第１のメディア  サーバに前記コールを管理するための命令を提供することを含む方法。
【請求項２】
前記メディア  サーバ  セットは、別々の地理的区域におけるメディア  サーバを含む請求項１に記載の方法。
【請求項３】
（ａ）における前記サービス要求は、セッション開始プロトコル、Ｈ．３２３、メディア  ゲートウェイ制御プロトコル、スキニー  クライアント制御プロトコル、ＭｉＮｅｔ、ＣｏｒＮｅｔ−ＩＰ、Ｉｎｔｅｒ−Ａｓｔｅｒｉｓｋ  ｅＸｃｈａｎｇｅプロトコル、Ｓｋｙｐｅ、およびＪａｊａｈから成るリストから選択されるプロトコルで提供される請求項１に記載の方法。
【請求項４】
（ｂ）における前記要求することは、ハイパーテキスト  トランスポート  プロトコルを使用して、前記アプリケーション  サーバから前記メディア  サーバ  リソース  ブローカに直接に行われる請求項１に記載の方法。
【請求項５】
（ｂ）における前記要求することは、
（ｉ）コール制御要素にＩＮＶＩＴＥメッセージを送信すること、および
（ｉｉ）前記コール制御要素から前記メディア  サーバ  リソース  ブローカに第２のＩＮＶＩＴＥメッセージを送信することを含む請求項１に記載の方法。
【請求項６】
（ｂ）における前記要求することは、メディア  サーバ使用の性質、必要とされるポートの数、顧客が契約したサービスのタイプ、必要とされるポートの特性、ポート使用の時間、会議コール識別、メディア  サーバのロケーションの地理的選好、および使用されるべき制御プロトコルの選好から成るリストから選択される１つまたは複数の属性を含む請求項１に記載の方法。
【請求項７】
（ｃ）における前記１つまたは複数のパラメータの１つは、前記セットの中の各メディア  サーバの能力、前記セットの中の各メディア  サーバにおいて利用可能なポートの数、前記セットの中の各メディア  サーバの地理的ロケーション、前記セットの中の各メディア  サーバの現在の利用、前記セットの中の各メディア  サーバのスケジュールされた利用から成るリストから選択される請求項１に記載の方法。
【請求項８】
（ｅ）における前記コールを前記確立することは、リアルタイム  トランスポート  プロトコルを使用する請求項１に記載の方法。
【請求項９】
前記第１のメディア  サーバは、複数のメディア  サーバを含む請求項１に記載の方法。
【請求項１０】
（ｅ）における命令を前記提供することは、
（ｉ）メディア  セッション  マークアップ言語、メディア  オブジェクト  マークアップ言語、メディア  サーバ制御マークアップ言語、音声拡張マークアップ言語、コール制御拡張マークアップ言語、およびメディア  リソース制御プロトコルから成るリストから選択される言語を使用して、コマンドを送信することを含む請求項１に記載の方法。
【請求項１１】
（ｃ）における前記選択することは、
（ｉ）前記第１のメディア  サーバが、前記要求されたメディア  サーバ  リソースを提供すべきことを、前記メディア  サーバ  セットの中のメディア  サーバのそれぞれにおいて、前記要求されたメディア  サーバ  リソースを提供するのに適した利用可能なポートの数に基づいて、判定することを含む請求項１に記載の方法。
【請求項１２】
メディア  サーバ  セットの利用を制御する方法であって、
（ａ）メディア  サーバ  リソースを求める要求をメディア  サーバ  リソース  ブローカ（１４０）において受信すること、
（ｂ）前記メディア  サーバ  セットの中の各メディア  サーバに関して、前記要求されたメディア  サーバ  リソースの利用可能性を判定すること、
（ｃ）選択された第１のメディア  サーバ（１６０）のアドレスを提供し、前記メディア  サーバ  リソース  ブローカは、前記判定された利用可能性に基づき、前記メディア  サーバ  セットから前記第１のメディア  サーバを選択すること、および
（ｄ）前記メディア  サーバ  リソースを求める前記要求に基づく、前記第１のメディア  サーバの割り当てレベルの変化を追跡することを含む方法。
【請求項１３】
（ａ）における前記要求は、メディア  サーバ使用の性質、必要とされるポートの数、顧客が契約したサービスのタイプ、必要とされるポートの特性、ポート使用の時間、会議コール識別、メディア  サーバのロケーションの地理的選好、および使用されるべき制御プロトコルの選好から成るリストから選択される１つまたは複数の属性を含む請求項１２に記載の方法。
【請求項１４】
前記メディア  サーバ  リソース  ブローカは、データベース  モジュールに結合された少なくとも１つのサーバを含み、（ｄ）における前記追跡することは、
（ｉ）前記データベース  モジュールの中に格納された前記第１のメディア  サーバの前記割り当てレベルのレコードを更新することを含む請求項１２に記載の方法。
【請求項１５】
前記メディア  サーバ  セットは、異なる地域に位置する複数のメディア  サーバを含む請求項１２に記載の方法。
【請求項１６】
（ｂ）における利用可能性を前記判定することは、
（ｉ）要求されたポートの数およびタイプを、前記メディア  サーバ  セットの中の各メディア  サーバにおいて利用可能なポートの数およびタイプと比較すること、ならびに
（ｉｉ）前記要求された量およびタイプを満たす十分なポートを提供することができるメディア  サーバに関して、前記要求された数のポートを提供した後に、最大レベルの予備のポートが利用可能であるメディア  サーバとして、前記第１のメディア  サーバを選択することを含む請求項１２に記載の方法。
【請求項１７】
（ｅ）前記メディア  サーバの利用レベルに関する更新を受信し、前記更新は、メディア  サーバ（１６）およびオペレーション  サポート  システム（１７０）から成るリストから選択されるモジュールから来ることをさらに含む請求項１２に記載の方法。
【請求項１８】
前記利用レベルの前記更新は、計画されたダウン時間、計画外のダウン時間、装置追加、装置削除、サービスごとの予約、会議ごとの予約、およびメディア  サーバ利用ステータスから成るリストから選択される少なくとも１つのファクタを含む請求項１７に記載の方法。
【請求項１９】
（ｅ）将来のメディア  サーバ  リソースを求める要求を前記メディア  サーバ  リソース  ブローカから受信すること、および
（ｆ）将来のメディア  サーバ  リソースを求める前記要求に関連する計画された割り当てをデータベース  モジュール（１５０）の中に格納することをさらに含み、（ｂ）における前記メディア  サーバ  セットの中のメディア  サーバの利用可能性を前記判定することは、前記計画された割り当てを含む請求項１２に記載の方法。
【請求項２０】
ネットワークを介してテレビ会議コール  レグを処理する方法であって、
（ａ）第１のコール発信デバイス（２１０）に関連する境界要素（２１５）から受信された着信コール要求に基づき、アプリケーション  サーバ（１２０）に、前記アプリケーション  サーバによって制御される会議に接続されるべき第１の要求を提供すること、
（ｂ）前記第１の要求に応答して、メディア  サーバ  リソースを求める第１のリソース要求をメディア  サーバ  リソース  ブローカ（１４０）に提供すること、
（ｃ）前記メディア  サーバ  リソース  ブローカから、前記ネットワーク上の第１のメディア  サーバ（１６０）のアドレスを受信すること、および
（ｄ）前記第１のコール発信デバイスと前記第１のメディア  サーバの間で第１のコール  レグを確立することを含む方法。
【請求項２１】
（ｃ）における前記受信することは、
（ｉ）前記メディア  サーバ  リソース  ブローカを使用して、前記第１のメディア  サーバが、前記要求を扱うのに利用可能であることを判定すること、および
（ｉｉ）前記第１のメディア  サーバのアドレスを提供することを含む請求項２０に記載の方法。
【請求項２２】
（ｂ）における前記提供することは、
（ｉ）メディア  サーバ  リソースを求める要求をアプリケーション  サーバから受信すること、および
（ｉｉ）前記要求を前記メディア  サーバ  リソース  ブローカに提供することを含み、前記要求は、要求されるポートの数、および地理的ロケーションの選好を含む請求項２０に記載の方法。
【請求項２３】
（ｅ）前記会議コールをサポートするのに必要とされるリソースのパラメータを変更する第２のリソース要求を前記メディア  サーバ  リソース  ブローカに提供することをさらに含む請求項２０に記載の方法。
【請求項２４】
（ｅ）前記アプリケーション  サーバにおいて、第２のコール発信デバイス（２１２）からの、前記会議コールに接続されるべき第２の要求を受信すること、および
（ｆ）前記第１のメディア  サーバと前記第２のコール発信デバイスの間で、前記メディア  サーバ  リソース  ブローカに問い合わせることなしに確立される第２のコール  レグを確立することをさらに含む請求項２０に記載の方法。
【請求項２５】
ＩＰノード（２１０）にサービスを提供する方法であって、
（ａ）アプリケーション  サーバ（１２０）において前記ＩＰノードからサービス要求を受信すること、
（ｂ）前記サービス要求に応答して、メディア  サーバ  リソース  ブローカ（１４０）からメディア  サーバ  リソースを要求すること、
（ｃ）前記メディア  サービス  リソース  ブローカを使用して、第１のメディア  サーバ（１６０）が、前記サービス要求を満たすのに利用可能であると判定し、前記第１のメディア  サーバは、メディア  サーバ  セットから、メディア  サーバ  リソースを求める前記要求、および前記メディア  サーバ  セットの中のメディア  サーバの利用と関係する１つまたは複数のパラメータに応答して選択されること、
（ｄ）前記メディア  サーバ  リソース  ブローカを介して、前記第１のメディア  サーバを前記ＩＰノードと接続し、前記接続は、前記第１のメディア  サーバと前記ＩＰノードの間でコールを確立する際に使用するためのＩＰアドレスおよびポート番号を提供すること、
（ｅ）前記ＩＰノードと前記第１のメディア  サーバの間でコールを確立すること、ならびに
（ｆ）前記アプリケーション  サーバから前記第１のメディア  サーバに前記コールを管理するための命令を提供することを含む方法。
【請求項２６】
前記メディア  サーバ  セットは、別々の地理的区域に位置するメディア  サーバを含む請求項２５に記載の方法。
【請求項２７】
（ａ）における前記サービス要求は、セッション開始プロトコル、Ｈ．３２３、メディア  ゲートウェイ制御プロトコル、スキニー  クライアント制御プロトコル、ＭｉＮｅｔ、ＣｏｒＮｅｔ−ＩＰ、Ｉｎｔｅｒ−Ａｓｔｅｒｉｓｋ  ｅＸｃｈａｎｇｅプロトコル、Ｓｋｙｐｅ、およびＪａｊａｈから成るリストから選択されるプロトコルで提供される請求項２５に記載の方法。
【請求項２８】
（ｂ）における前記要求することは、ハイパーテキスト  トランスポート  プロトコルを使用して、前記アプリケーション  サーバから前記メディア  サーバ  リソース  ブローカに直接に行われる請求項２５に記載の方法。
【請求項２９】
（ｂ）における前記要求することは、
（ｉ）コール制御要素（１３０）にＩＮＶＩＴＥメッセージを送信すること、および
（ｉｉ）前記コール制御要素から前記メディア  サーバ  リソース  ブローカに第２のＩＮＶＩＴＥメッセージを送信することを含む請求項２５に記載の方法。
【請求項３０】
（ｂ）における前記要求することは、メディア  サーバ使用の性質、必要とされるポートの数、顧客が契約したサービスのタイプ、必要とされるポートの特性、ポート使用の時間、会議コール識別、メディア  サーバのロケーションの地理的選好、および使用されるべき制御プロトコルの選好から成るリストから選択される１つまたは複数の属性を含む請求項２５に記載の方法。
【請求項３１】
（ｃ）における前記１つまたは複数のパラメータの１つは、前記セットの中の各メディア  サーバの能力、前記セットの中の各メディア  サーバにおいて利用可能なポートの数、前記セットの中の各メディア  サーバの地理的ロケーション、前記セットの中の各メディア  サーバの現在の利用、前記セットの中の各メディア  サーバのスケジュールされた利用から成るリストから選択される請求項２５に記載の方法。
【請求項３２】
（ｅ）における前記コールを前記確立することは、リアルタイム  トランスポート  プロトコルを使用する請求項２５に記載の方法。
【請求項３３】
前記第１のメディア  サーバは、複数のメディア  サーバを含む請求項２５に記載の方法。
【請求項３４】
（ｆ）における命令を前記提供することは、
（ｉ）メディア  セッション  マークアップ言語、メディア  オブジェクト  マークアップ言語、メディア  サーバ制御マークアップ言語、音声拡張マークアップ言語、コール制御拡張マークアップ言語、およびメディア  リソース制御プロトコルから成るリストから選択される言語を使用して、コマンドを送信することを含む請求項２５に記載の方法。
【請求項３５】
（ｃ）における前記判定することは、前記メディア  サーバ  セットの中のメディア  サーバのそれぞれにおいて、前記要求されたメディア  サーバ  リソースを提供するのに適した利用可能なポートの数に基づく請求項２５に記載の方法。
【請求項３６】
メディア  サーバ  セットの利用を制御する方法であって、
（ａ）メディア  サーバ  リソースを求める要求をメディア  サーバ  リソース  ブローカ（１４０）において受信すること、
（ｂ）前記メディア  サーバ  セットの中の各メディア  サーバ（１６０）に関して、前記要求されたメディア  サーバ  リソースの利用可能性を判定すること、
（ｃ）前記第１のメディア  サーバのＩＰアドレスおよびポート番号をＩＰノード（２１０）に提供すること、ならびに
（ｄ）前記メディア  サーバ  リソースを求める前記要求に基づく、前記第１のメディア  サーバの割り当てレベルの変化を追跡することを含む方法。
【請求項３７】
（ａ）における前記要求は、セッション開始プロトコルで提供される請求項３６に記載の方法。
【請求項３８】
（ａ）における前記要求は、メディア  サーバ使用の性質、必要とされるポートの数、顧客が契約したサービスのタイプ、必要とされるポートの特性、ポート使用の時間、会議コール識別、メディア  サーバのロケーションの地理的選好、および使用されるべき制御プロトコルの選好から成るリストから選択される１つまたは複数の属性を含む請求項３６に記載の方法。
【請求項３９】
前記メディア  サーバ  リソース  ブローカは、データベース  モジュールに結合された少なくとも１つのサーバを含み、（ｄ）における前記追跡することは、
（ｉ）前記データベース  モジュールの中に格納された前記第１のメディア  サーバの前記割り当てレベルのレコードを更新することを含む請求項３６に記載の方法。
【請求項４０】
前記メディア  サーバ  セットは、異なる地域に位置する複数のメディア  サーバを含む請求項３６に記載の方法。
【請求項４１】
（ｂ）における利用可能性を前記判定することは、
（ｉ）要求されたポートの数およびタイプを、前記メディア  サーバ  セットの中の各メディア  サーバにおいて利用可能なポートの数およびタイプと比較すること、ならびに
（ｉｉ）前記要求された量およびタイプを満たす十分なポートを提供することができるメディア  サーバに関して、前記要求された数のポートを提供した後に、最大レベルの予備のポートが利用可能であるメディア  サーバとして、前記第１のメディア  サーバを選択することを含む請求項３６に記載の方法。
【請求項４２】
（ｅ）前記メディア  サーバの利用レベルに関する更新を受信し、前記更新は、メディア  サーバ（１６０）およびオペレーション  サポート  システム（１７０）から成るリストから選択されるモジュールから来ることをさらに含む請求項３６に記載の方法。
【請求項４３】
前記利用レベルの前記更新は、計画されたダウン時間、計画外のダウン時間、装置追加、装置削除、サービスごとの予約、会議ごとの予約、およびメディア  サーバ利用ステータスから成るリストから選択される少なくとも１つのファクタを含む請求項４２に記載の方法。
【請求項４４】
（ｅ）将来のメディア  サーバ  リソースを求める要求を前記メディア  サーバ  リソース  ブローカから受信すること、および
（ｆ）前記要求の計画された利用をデータベース  モジュール（１５０）の中に格納することをさらに含み、（ｂ）における利用可能性を前記判定することは、前記計画された利用を含む請求項３６に記載の方法。
【請求項４５】
ＶｏＩＰネットワークを介して対話型音声応答コールを処理する方法であって、
（ａ）ＶｏＩＰ電話機（２１０）に関連する境界要素（２１５）から受信されるサービス要求をアプリケーション  サーバ（１２０）に提供すること、
（ｂ）メディア  サーバ  リソースを求める要求をメディア  サーバ  リソース  ブローカ（１４０）に提供すること、
（ｃ）前記ＶｏＩＰネットワーク上の第１のメディア  サーバ（１６０）のＩＰアドレスを特定すること、
（ｄ）前記メディア  サーバ  リソース  ブローカを使用して、前記第１のメディア  サーバに問い合わせて、ＩＰアドレスおよびポート番号を特定すること、
（ｅ）前記メディア  サーバ  リソース  ブローカを介して前記第１のメディア  サーバを前記境界要素に接続すること、ならびに
（ｆ）前記ＶｏＩＰ電話機と前記第１のメディア  サーバの間でコールを確立することを含む方法。
【請求項４６】
（ｃ）における前記判定することは、および
（ｉ）メディア  サーバ  リソースを求める前記要求をメディア  サーバ  セットの利用可能性と比較すること、および
（ｉｉ）前記メディア  サーバ  セットからの前記第１のメディア  サーバを選択して、前記メディア  サーバ  リソースを提供することを含む請求項４５に記載の方法。
【請求項４７】
（ｉｉ）における前記選択することは、
（１）前記第１のメディア  サーバが、前記メディア  サーバ  セットの中の、その他のメディア  サーバよりも低い割り当てレベルを有すると判定することを含む請求項４６に記載の方法。
【請求項４８】
（ｆ）における前記コールを前記確立することは、リアルタイム  トランスポート  プロトコルを使用する請求項４５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＶｏＩＰで使用するために構成されたネットワークにおけるメディア  サーバ  リソースの管理の分野に関する。
【背景技術】
【０００２】
本国際出願は、２００５年４月２２に出願した仮出願第６０／６７４，２４４号の利益を主張し、２００５年１２月２９日に出願した米国特許出願第１１／３２１，７６０号の優先権を主張し、２００５年１２月２９日に出願した米国特許出願第１１／３２１，７３４号の優先権をさらに主張する。
【０００３】
ＶｏＩＰの使用は既知である。基本的に、ＶｏＩＰは、個人の可聴の会話（アナログである）を符号化して、データ  パケット（デジタルである）にして、デジタル  パケットが、ＩＰ（インターネット  プロトコル）ネットワークを介して送信されることが可能であるようにする、μ−ｌａｗを使用するＧ．７１１などの、ただし、それには限定されないコーデックを使用することにかかわる。周知のとおり、ＩＰネットワークは、音声の他にも、データ  サービス（ファイル転送、電子メール、インスタント  メッセージングなど）に加えて、ビデオまたはファックスなどの、他の種類のトラフィックを伝送することができる。そのような収斂した、または統合されたネットワークは、ネットワーク  プロバイダおよびユーザへの経済的利点、および運用上の利点がある。
【０００４】
ＶｏＩＰサービスには、ネットワーク内の装置との、通常、メディア  サーバとのメディア  ベースの発呼者対話がかかわることが可能である。そのような対話は、例えば、ただし、限定なしに、二重トーンマルチ周波数（ｄｕａｌ  ｔｏｎｅ  ｍｕｌｔｉ−ｆｒｅｑｕｅｎｃｙ：ＤＴＭＦ）ルーチンまたは音声プロンプト−コレクト  ルーチン（例えば、フリーダイヤル  サービスのため、またはボイスメールを取り出すために使用されることが可能）のため、告知を聞くため、あるいは電話会議コールに参加するためであることが可能である。この概念は、例えば、限定なしに、ファックス  ストア  アンド  フォワードまたはテレビ会議を含むことが可能なＳｏＩＰ（Ｓｅｒｖｉｃｅｓ  ｏｖｅｒ  ＩＰ）として、より一般的に知られる、ＶｏＩＰ以外のサービスにまで一般化される。
【非特許文献１】「Ｃｏｍｍｏｎ  ＶｏＩＰ  Ａｒｃｈｉｔｅｃｔｕｒｅ」（ＡＴ＆Ｔ  Ｐｏｉｎｔ  Ｏｆ  Ｖｉｅｗ／ＶｏＩＰ、２００３年１２月２２日）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
メディア  サーバが特定のサービスをどのように提供するかを操縦するロジックが、アプリケーション  サーバによって提供されることが可能である。メディア  サーバに対してアプリケーション  サーバを使用するための基本的なアーキテクチャは、周知である。しかし、より多数のメディア  サーバを扱う多数のアプリケーション  サーバが、存在することが可能である。したがって、様々なアプリケーション  サーバに関してメディア  サーバの利用を管理するのに、何かが必要とされている。
【課題を解決するための手段】
【０００６】
本発明の諸態様は、ＶｏＩＰコールに、より一般的には、ＳｏＩＰコールに割り当てられたメディア  サーバ  リソースを管理するための方法に関する。或る実施形態では、アプリケーション  サーバは、ＶｏＩＰ電話機、または他の顧客装置などのＩＰノードを発信元とするサービス要求を受信する。これに応答して、アプリケーション  サーバは、要求されたサービスを提供するメディア  サーバ  リソースを要求する。メディア  サーバ  リソース要求は、メディア  サーバ  リソース  ブローカに送られることが可能である。メディア  サーバ  リソース  ブローカは、要求されたサービスを提供する適切なメディア  サーバを決定し、その情報をアプリケーション  サーバに提供する。すると、アプリケーション  サーバは、メディア  サーバとＩＰノードが接続されるようにすることができ、アプリケーション  サーバは、メディア  サーバが、必要に応じて、ＩＰノードと対話することを可能にするロジックを提供する。
【０００７】
別の実施形態では、アプリケーション  サーバは、ＶｏＩＰ電話機、または他の顧客装置などのＩＰノードを発信元とするサービス要求を受信する。これに応答して、アプリケーション  サーバは、要求されたサービスを提供するメディア  サーバ  リソースを要求する。メディア  サーバ  リソース要求は、メディア  サーバ  リソース  ブローカに送られることが可能である。メディア  サーバ  リソース  ブローカは、要求されたサービスを提供する適切なメディア  サーバを決定し、そのメディア  サーバに問い合わせて、ＩＰアドレスを特定する。すると、メディア  サーバ  リソース  ブローカは、メディア  サーバが、ＩＰノードに接続されるようにすることができる。次に、アプリケーション  サーバが、メディア  サーバが、ＩＰノードとのコールを管理することを可能にするロジックを提供することができる。
【０００８】
本発明は、同様の符号が同様の要素を示す添付の図において、例として示されているが、それには限定されない。
【発明を実施するための最良の形態】
【０００９】
前述したとおり、ＶｏＩＰを提供するためのアーキテクチャは、周知であり、一例が、「Ｃｏｍｍｏｎ  ＶｏＩＰ  Ａｒｃｈｉｔｅｃｔｕｒｅ」という名称の白書、ＡＴ＆Ｔ  Ｐｏｉｎｔ  Ｏｆ  Ｖｉｅｗ／ＶｏＩＰ、２００３年１２月２２日において開示されており、この白書は、参照により全体が本明細書に組み込まれている。しかし、共有することの利点に動機付けられて、ＭＳ（メディア  サーバ）の共有プールを扱う様々なサービスをサポートする多数のＡＳ（アプリケーション  サーバ）が、存在することが可能である。
【００１０】
ＭＳの共有プールの使用により、ＶｏＩＰを提供するのに使用されるリソースのより効率的な使用が可能になる。例えば、ＭＳリソースが、地域レベルで管理される場合、より高い効率が可能である。管理されるＭＳの数が増加し、ＭＳのロケーションがより分散されるにつれ、得られることが可能な効率は、さらにより顕著になる。
【００１１】
図１を参照すると、システムの高レベルの概略図が、開示されている。システム内に示される要素のそれぞれは、一緒にリンクされた１つまたは複数の物理的要素または論理的要素を含むモジュールであることが可能であることに留意されたい。ＡＳ１２０が、ＣＣＥ（コール制御要素）１３０に接続されているのが示されている。一般に、ＡＳは、電話システムのユーザに、ボイスメールなどのサービスを提供することができ、それらのサービスは、ＬＤＡＰ（ライトウェイト  ディレクトリ  アクセス  プロトコル）ルックアップなどのネットワーク  リソースを含むことが可能である。また、ＡＳは、複数のパーティをマルチキャスト会議に接続するロジックを背景で扱うこともでき、可聴のプロンプトの提供、およびそれらのプロンプトへの応答の収集を介してユーザと対話するためのスクリプトを提供することができる。したがって、ＡＳは、所望されるサービスを発呼者に提供するのに必要なロジックを提供することができ、他のデバイスと通信する際の特定のプロトコルの使用に限定されない。通常、ＡＳは、特定の機能のためにプログラミングされる。このため、或る実施形態では、ＡＳは、１つまたは複数の記録されたメッセージを生成する命令を提供することにより、コール  センタへのコールを扱うのに必要とされるロジックを提供し、ユーザ入力に構造化された応答を提供し、ＩＶＲ（対話型音声応答）インタフェースにおいて一般的であるように、受け取られた数字を処理するようにプログラミングされることが可能である。
【００１２】
通常、ＡＳ１２０は、エンド  ユーザ自体とメディア対話を実行しないが、代わりに、ＭＳ１６０に命令を与えることができる。或る実施形態では、ＭＳ１６０は、音声認識エンジンと、会議ブリッジと、ＴＴＳ（テキスト  ツー  音声）エンジンとを含むことが可能であり、あるいは記録されたメッセージを再生し、発呼者によって入力された数字を収集して、個人が、ＡＳ１２０によって提供されるロジックと対話することができるようにすることが可能である。
【００１３】
ＡＳ１２０は、潜在的に、ＳＩＰ（セッション開始プロトコル）を使用して提供されることが可能な、着信コールから受け取られた信号と直接に対話することもできる。しかし、ＡＳ１２０は、好ましくは、ＡＳ１２０のためのプロキシの役割をするようにＣＣＥ（コール制御要素）を使用することができる。したがって、着信コールは、ＣＣＥによってルーティングされることが可能であり、コール  レグは、所望に応じて、ＡＳにおけるサービス  ロジックの誘導の下で、ＣＣＥによって追加される、変更される、または削除されることが可能である。このため、図１に示されるとおり、ＣＣＥ１３０は、どのようにコールが、ネットワークにアクセスするか、またはネットワークから出て行くかについての詳細を、ＡＳ１２０が無視することを可能にし、したがって、ＡＳ１２０は、代わりに、どのようにコールが扱われるかについての論理に集中することができる。
【００１４】
ＡＳ１２０は、着信コールを直接に扱わないように構成されることが可能であるが、着信コールからの或る量の情報が、所望されるサービスを提供するのに役立つ可能性がある。このため、ＡＳ１２０は、ＣＣＥ１３０と通信するように構成されることが可能である。ＡＳとＣＣＥ１３０の間で通信する一方法は、ＳＩＰの使用である。さらに、ＡＳ１２０は、ＭＳ１６０と通信して、発呼者とのメディア対話に関してどのようにするかについて、ＭＳ１６０に命令するように構成されることが可能である。そのような通信には、例えば、限定なしに、ＭＳＭＬ（メディア  セッション  マークアップ言語）およびＭＯＭＬ（メディア  オブジェクト  マークアップ言語）、またはＶＸＭＬ（音声拡張マークアップ言語）がかかわることが可能である。
【００１５】
ＡＳ１２０、ＣＣＥ１３０、およびＭＳ１６０は、命令、およびコールを処理することの詳細を扱う。しかし、図８に示されるとおり、ＡＳ１２０ａは、ＭＳモジュール１６１〜１６６と対話することができ、各ＭＳモジュールは、異なる地域に位置している。本明細書で使用される、各ＭＳモジュールは、１つまたは複数の物理サーバから成ることが可能であり、地域は、物理的場所、市、郡、州、または国から成ることが可能である。このため、地域レベルにおける管理は、２つ以上の地域を管理する。異なる地域においてＭＳを提供することは、広大な距離をまたぐ必要なしに、それらの地域近く、またはそれらの地域内に位置する個人にサービスを提供することができるという利点を有することに留意されたい。しかし、様々なＭＳの効率的な利用は、或る特定の地域において何が起きているかを単に認識していることにより、すべての地域における全体の利用可能なＭＳリソースが効率的に利用されていることは確実にならないため、より複雑となる。
【００１６】
また、ＡＳ１２０ｂのような追加のＡＳが、ＭＳ１６１〜１６６を使用することも可能である（より明瞭にするため、図８内のＡＳ１２０ｂとＭＳの間の接続は、示されていない）。しかし、ＡＳ１０２ａとＡＳ１２０ｂは、独立に動作していることが可能であり、異なるサービスをサポートすることが可能であり、異なるサービス  プロバイダによって提供されることが可能であるので、ＡＳ１２０ａも、ＡＳ１２０ｂも、ＭＳ１６１も、他のＭＳと比べてＭＳ１６１にかかる負荷を認識しているものと見込むことはできない。
【００１７】
したがって、リソース利用を向上させるのを助けるのに、ＭＳＲＢ（メディア  サーバ  リソース  ブローカ）１４０が、利用されることが可能である。ＭＳＲＢ１４０は、ＭＳサービスを求める要求を受信し、その要求、およびＭＳの現在の利用に応じて、要求されたサービスを提供する適切なＭＳを決定する。ＭＳＲＢ１４０は、コールの地理的発信元、様々なＭＳに対するコールの発信元の近さ、ＭＳの能力、サポートされる必要があるコール  レグの数、必要とされるリソースのタイプ（例えば、音声認識エンジンまたは数字収集が要求されるかどうか）、コール  レグが活性である時間の長さ、将来の予約（例えば、所与のサービス、または来るべき、スケジュールされた会議コールのための最小容量）、およびＭＳの利用に影響を与える可能性があり、したがって、所望されるサービスのデリバリに影響を与える可能性がある他の任意のパラメータなどの、ただし、以上には限定されない、利用可能な帯域幅の使用の単なるパーセンテージ以外の、利用と関係するさらなるパラメータも考慮することができる。ＭＳリソースを選択するためにＭＳＲＢ１４０が使用する情報の一部は、ポートに関して必要とされるコーデックのタイプ、ポート使用の見込まれる時間、地理的選好、必要とされるポートの数、制御プロトコル（ＶＸＭＬ、またはＭＳＣＭＬ（メディア  サーバ制御マークアップ言語）、またはＭＲＣＰ（メディア  リソース制御プロトコル）などの）に関する選好、会議識別番号（スケジュールされた会議コールに関する）、要求が行われている顧客サービス、あるいはＤＴＭＦ収集が必要とされているか、または或るタイプの音声認識が必要とされているかなどの、ただし、以上には限定されない、ＡＳ１２０からの要求の属性として入手されることが可能である。
【００１８】
例えば、図１に戻ると、ＭＳＲＢ  ＳＩＰコントローラ１４５は、音声認識能力を有するＭＳを求める要求を受信することが可能である。その要求は、２時間という期間にわたって１００のポートを求めるデマンドを含むことが可能である。本明細書で使用される、ポートという用語は、物理ポートに限定されず、代わりに、論理ポートを指すことに留意されたい。このため、ポートは、各着信コールに関して、所望されるサービスを提供するために十分な帯域幅、および処理能力、および諸能力の単位であると考えられることが可能である。したがって、１００の論理ポートの必要性は、１００以上のコールを同時に扱うのに十分な能力を有する単一の物理ポートの一部分を使用して満たされることが可能である。さらに、ＭＳＲＢが、個々のポートの割り当てを識別し、追跡しているのではなく、所望されるタイプのポートにアクセスすることがでるＭＳアドレスを識別し、そのレベルにおけるリソース割り当てを追跡するだけで十分である。
【００１９】
サーバであることが可能なＭＳＲＢ  ＳＩＰコントローラ１４５は、ＭＳＲＢデータベース１５０に問い合わせて、ネットワークにおけるすべての利用可能なＭＳの現在の利用、計画された利用、および容量を特定することができる。前述の例を続けると、ＭＳ１６０が、２時間にわたって１００のポートを提供する十分な容量を有することを特定した後、ＭＳ１６０のアドレスが、ＣＣＥ１３０を介してＡＳ１２０に提供されることが可能である。或る実施形態では、ＡＳおよびＣＣＥは、次に、接続１２２および１６４を介してＭＳ１６０を直接に相手にして、ＭＳＲＢ１４０のさらなる関与なしに、ＭＳ１６０に至るコール  レグをセットアップする。代替の実施形態では、信号は、ＣＣＥ１３０を通ってＭＳＲＢ１４０に流れた後、ＭＳ１６０まで流れる。以上２つの方法を、以下により詳細に説明する。
【００２０】
ＭＳＲＢ１４０が、要求されたサービスを提供することができるＭＳのＩＤをＡＳに提供する際、ＭＳＲＢ１４０は、そのＭＳの使用をＭＳＲＢデータベース１５０の中に格納する。このため、前述の例を続けると、ＭＳサービスを求める将来の要求は、ＭＳ１６０が、２時間の期間にわたって割り当てられた１００のポートを有するという事実を考慮に入れる。ＭＳＲＢ１４０は、ネットワーク上のＭＳのセットを使用するすべてのＡＳに関する要求を受信し、ＭＳＲＢ１４０は、現在の要求、および予約に基づく、ネットワーク上のすべてのＭＳの割り当てを把握しているので、ＭＳＲＢ１４０は、各ＡＳによって必要とされるサービスが提供されることを確実にしながら、様々なＭＳのより高い利用をもたらすことができる。
【００２１】
前述の例では、２時間という期間にわたって１００のポートが要求されたが、１時間後、ほとんどすべてのポートが空いていることが可能である。例えば、ＭＳ１６０が、インフォマーシャルなどの広告に応答して発呼した顧客にＩＶＲを提供していた場合、インフォマーシャルの終了により、着信コールの数が、大幅に減ることが生じることが可能である。ＡＳ１２０は、コール信号通知パスにあるため、任意の時点で、いくつのコール  レグが、ＭＳ１６０に接続されているかを認識している。１時間後、インフォマーシャルに関するコールを扱うＡＳ１２０は、着信コール量が、最後の１時間にわたって４０のポートしか必要とされないようなものである判定することが可能であり、したがって、ＡＳ１２０は、その時点で、ポートのうち６０個が、ＭＳアイドル  プールに戻されることが可能であることをＭＳＲＢ１４０に通知することにより、それだけの数のポートを解放することができる。このアプローチは、ＭＳＲＢが、ネットワーク  リソースをより効率的に管理することを可能にすることができ、その他の潜在的な利点をもたらすこともできる。図示されるとおり、ＭＳＲＢ１４０と、ＡＳのセットとが、信号通知エラーまたはＡＳ障害などの事態により、同期しなくなることに対する対策として、ＭＳＲＢが、実際のＭＳ利用を把握しているように、１つまたは複数のＯＳＳ（オペレーション  サポート  システム）１７０とＭＳＲＢ１４０との間で通信パス１７５が提供される。ＯＳＳは、サービスごとの予約、会議ごとの予約、ＭＳの計画されたダウン時間、ＭＳの計画外のダウン時間、ＭＳ装置追加、およびＭＳ装置削除などのファクタを含む利用更新を提供することが可能である。或る実施形態では、ＭＳ利用情報は、パス１８０を使用して、ＯＳＳ１７０経由でＭＳ１６０からＭＳＲＢ１４０に来ることが可能である。代替の実施形態では、利用情報は、パス１６２を使用して、直接に提供されてもよい。
【００２２】
或る実施形態では、割り当てられたポートの数を減らす代わりに、ＡＳ１２０は、例えば、観察されるコール量が、予期されていたよりも多い場合、ＭＳＲＢ１４０から、追加のポートを代わりに要求することができる。
【００２３】
しかし、すべての要求が、完全に満たされるわけではない可能性があることに留意されたい。例えば、第１のＡＳに関してＸ個のポートを求める要求が、第２のＡＳからの、Ｙ個のポートを求める要求、および第３のＡＳからの、Ｚ個のポートを求める要求と一緒に受信される可能性があり、ＸとＹとＺの合計が、ＭＳ上で利用可能なＮ個のポートという容量を超える可能性がある。理解することができるように、異なるＭＳには、異なる数のポートが利用可能であり、したがって、異なる利用レベルを有することが可能である。第１のＡＳからのＸ個のポートを求める要求が会議コールと関係しており、その他の要求がＩＶＲと関係している場合、可能な１つの応答は、Ｘ個のポートを求める要求をそのＡＳに許可し、Ｙ個のポートを求める要求、およびＺ個のポートを求める要求の一部を、第２のＡＳおよび第３のＡＳに許可することである。すると、第２のＡＳおよび第３のＡＳは、その部分的な提供を受け入れるかどうかを決定することができる。第２のＡＳと第３のＡＳがともにその部分的な提供を受け入れるものと想定すると、ＭＳＲＢは、各ＡＳ要求に関して割り当てられたポートの数を記録に留める。
【００２４】
さらに、会議コールをサポートするようにＸ個のポートを求める要求が、接続する発呼者の数を過大評価（または過小評価）する可能性があり、コールが接続される時間も過大評価（または過小評価）する可能性がある。さらに、ＡＳは、いくつのポートをＡＳが所望するか、またはＡＳが所望するポートのタイプに関して、ＭＳＲＢに対するＡＳの要求を変更することができる。また、ＭＳＲＢは、他のＡＳによる、提供されたポートの利用についても認識している。このため、ポートが利用可能になると、それらのポートは、適宜、別のＡＳをサポートするように移されることが可能である。
【００２５】
図１に示されるとおり、ＯＳＳ（オペレーション  サポート  システム）１７０が、ＭＳＲＢ１４０に接続される。或る実施形態では、ＯＳＳ１７０は、将来のサービスを求める要求に応答して、リソースの将来の利用をスケジュールするよう、ＭＳＲＢに要求することができる。例えば、２０００のコール  レグを有する大規模な会議コールを行うことを計画している個人は、前もって、その会議コールをスケジュールして、その会議コールに参加することを計画している２０００名すべての人々が、その会議コールに実際に加わることができることを確実にしたいと所望する可能性がある。ＭＳＲＢは、前にスケジュールされた任意の利用に基づき、その会議コールを扱う好ましいＭＳを決定することもできる。また、ＭＳＲＢは、ＭＳのスケジュールされた使用を調整して、各ＭＳのより一貫した利用レベルがもたらされるようにすることもできることに留意されたい。このため、第１のＭＳ、および第２のＭＳを伴う或る実施形態では、ＭＳＲＢは、第１のＭＳの前にスケジュールされた利用を第２のＭＳに移し、新規の要求を扱うよう、第１のＭＳをスケジュールすることができる。また、様々な優先順位（例えば、或る会議コールへのポートの割り当てが、ＩＶＲへのポートの割り当てよりも高い優先順位を有することが可能である）に応じて、変更が行われることも可能である。ＭＳが失われたことなどの技術問題に応答して、さらなる変更が行われてもよい。このため、ＭＳＲＢは、ネットワーク上でＭＳを利用する堅牢で、効率的な手段を提供する。
【００２６】
ＶｏＩＰ技術の使用において周知のとおり、ＢＥ、ＣＣＥ、ＭＳ、およびＡＳのネットワーク要素の間、およびＢＥとＳＩＰ電話機との間の基礎をなす信号通知は、複数のプロトコル、例えば、限定なしに、ＳＩＰ、Ｈ．３２３、またはＭＧＣＰ（メディア  ゲートウェイ制御プロトコル）の何らかの組み合わせである。前述の要素の任意の２つの間で使用されることが可能なＳＩＰを使用する或る実施形態では、一連の要求メッセージ（例えば、ＩＮＶＩＴＥ、ＢＹＥ、ＡＣＫ）および応答メッセージ（例えば、１８０  Ａｌｅｒｔｉｎｇ、２００  ＯＫ）を使用して、メディア  セッションが確立されること、およびクリアされることが可能である。ＳＩＰメッセージは、例えば、ＳＩＰ  ＵＲＩの形態で、ＳＩＰ信号通知エンティティを識別するアドレス情報を伝送する。また、ＳＩＰメッセージは、ＳＤＰ（セッション記述プロトコル）を使用して、メディア情報を含め、様々なタイプのペイロード情報を伝送することもでき、その場合、ＳＤＰコンテンツは、メディア受信ＩＰアドレス、およびメディア  エンドポイントのポート番号、およびメディアの特性（例えば、Ｇ．７２６符号化されたオーディオ）のような事物を示す。メディア  アドレスの交換により、メディア接続が確立される。メディア自体は、ＲＴＰ（リアルタイム  トランスポート  プロトコル）のようなプロトコルを使用して転送される。
【００２７】
さらに、図１は、ＶｏＩＰネットワークの図である。ＢＥ、ＣＣＥ、ＡＳ、およびＭＳなどの要素は、ＶｏＩＰネットワークにおいて見られる機能の、いくつかの典型的なグループ化を具体化する。したがって、それらの要素は、開示される諸実施形態に限定されるべきではなく、むしろ、説明される諸機能を実行する諸要素を対象とする。例えば、或る実施形態では、ＢＥは、セッション境界コントローラであることが可能であり、ネットワーク内部アドレスとネットワーク外部アドレスとの間の変換を含むことが可能な、ネットワーク外部エンティティに関する様々なセキュリティ機能、ポリシー機能、ならびにプロトコル  インタワーキング−トランスコーディング機能を実行することが可能である。或る実施形態では、ＣＣＥは、コール  エージェントまたはソフトスイッチであることが可能であり、ルーティング、またはＡＳ呼び出しおよびＡＳ対話などの、基本的なコール処理機能を実行することが可能である。理解することができるように、以上の要素は、そのように限定されず、様々な要素の他の既知の変種が、適宜、使用されてもよい。
【００２８】
図２および図３を参照すると、着信コールを扱う方法の実施形態が示されている。最初に、工程３０５で、ＩＰノードの例である電話機２１０が、ＳＩＰにおいて使用されるフォーマットであるＩＮＶＩＴＥメッセージをＢＥ２１５に送信する。このメッセージは、他の任意の既知のプロトコルで提供されることも可能であり、このメッセージは、サービス要求の例である。ＩＮＶＩＴＥメッセージは、宛先アドレス、および／または所望されるサービスのタイプの何らかの指示を含むことが可能である。次に、ＢＥ２１５が、ローカル  ポリシー（例えば、着信信号通知が、許されたＩＰアドレスからであるかどうか、または要求されたコール帯域幅が、許されるパラメータの範囲内にあるかどうか）に基づき、そのコールを受け付けるかどうかを決定する。ＳＩＰ電話機（Ｌｉｎｋｓｙｓ  ＲＴ４１Ｐ２のような、ただし、これに限定されない）は、コール発信デバイスの一例であり、コール発信デバイスは、ネットワークに直接に接続されても、中間ネットワークを介して接続されてもよい。
【００２９】
次に、コールを受け付けた後、ＢＥ２１５は、工程３１０で、ＣＣＥ１３０にＩＮＶＩＴＥメッセージを送信する。そのメッセージを受信すると、ＣＣＥ１３０は、ＳＢ（サービス  ブローカ）に問い合わせて、ＩＮＶＩＴＥの中のＴＮ（電話番号）または他の情報に関連するサービス  フィーチャが存在するかどうかを確認する。ＳＢは、適切なＡＳのアドレスで応答することができる。次に、工程３１５で、ＣＣＥ１３０が、ＩＮＶＩＴＥの中に含まれるＴＮまたは他の情報に関連するＡＳである、ＡＳ１２０にＩＮＶＩＴＥメッセージを送信する。
【００３０】
工程３２０で、ＡＳ１２０は、ＮＳ（ネットワーク  サーバ）２２０から、さらなる情報を要求する。ディレクトリ要求であることが可能な、この要求は、ＳＯＡＰ、ＬＤＡＰ、ＳＭＴＰ、または他の何らかのプロトコルによって提供されることが可能であり、ＭＳＲＢによってサポートされるネットワーク内のサーバに向けられることが可能であり、またはネットワークの外部（例えば、インターネット上のどこか）であることが可能である。
【００３１】
工程３２５で、ＡＳ１２０が、ＭＳリソース、および所望されるＭＳ属性を要求するＩＮＶＩＴＥメッセージをＣＣＥ１３０に送信する。工程３４０で、ＣＣＥ１３０が、その要求をＭＳＲＢ１４０に転送する。ＭＳＲＢ１４０は、複数のサーバから成ることが可能であり、ＣＣＥ１２０は、ラウンドロビンのやり方で、異なるサーバにメッセージを送信することが可能であるが、ＭＳＲＢ１４０が、すべてのＭＳリソースの活動を把握しておくことができるように、ＭＳＲＢ１４０に関連する、すべてのＭＳに関する活動の単一の論理データベースが、要求されることに留意されたい。つまり、異なるＭＳＲＢが、同一のＭＳリソースを使用することができてはならない。
【００３２】
工程３４５で、ＭＳＲＢ１４０が、要求、および現在の／計画された利用レベルに鑑みて、適切なＭＳを決定する。会議コールの場合、所与の会議に関するすべてのコール  レグを扱うのに、単一のＭＳを使用することが好ましい可能性がある。しかし、ＩＶＲタイプのコールの場合、複数のＭＳが、効率的に使用されることが可能であり、したがって、ＭＳＲＢ１４０は、様々なＭＳが、それらの様々なＭＳの既存の利用に応じて、純粋な分割で、または重み付き割り当てで、要求されたポートの一部を提供することができると判定することが可能である。
【００３３】
工程３５０で、ＭＳＲＢ１４０が、ＣＣＥ１３０を介して、ＡＳ１２０にＭＳアドレス、および他の任意の適切な情報を提供する。ＡＳ要求が、表明されるとおりに許可されることが可能でない場合、ＭＳＲＢは、代替で応答することが可能である（例えば、要求が、米国東部において１００のポートを求めていたのに対して、５０のポートが、米国西部におけるＭＳにおいて提供されることが可能である）。工程３５５で、ＡＳ１２０は、ＭＳ１６０に対するコール  レグをセットアップするよう、ＣＣＥ１３０に命令する。工程３６０で、ＣＣＥ１３０は、コールに参加するよう、ＭＳ１６０に要求するＩＮＶＩＴＥメッセージをＭＳ１６０に送信する。工程３６５で、ＭＳ１６０は、コールを受け付ける応答をＣＣＥ１３０に送信する。工程３７０で、ＣＣＥ１３０は、応答をＢＥ２１５に中継する。工程３７５で、ＢＥは、応答を電話機２１０に送信して、電話機２１０とＭＳ１６０が、メディア  リンクを確立するようにする。工程３８０で、ＡＳ１２０が、２１０からの電話コールを扱うための命令をＭＳ１６０に与える。ＭＳリソースの一部またはすべてが、もはや必要とされていない、例えば、コールまたは会議が終了した、またはより少ないポートが必要とされているとＡＳ１２０が判定した場合、ＡＳ１２０は、ＭＳＲＢ１４０と通信して、全部の数の、またはいくつかの数のポートをＭＳアイドル  リソース  プールに戻させることができる。或る実施形態では、ＡＳは、ポートの現在の必要性が、ポートの数、タイプ、またはタイプの取り合わせを求める初期の要求と一致しないと判定することが可能である。さらに、現在の割り当てられたポートが、追加の期間にわたって必要とされる可能性がある。例えば、ＡＳが、最初、Ｇ．７１１コーディングを使用するいくつかのポートを要求し、その後の何らかの時点で、３／４のＧ．７１１ポートと１／４のＧ．７２６ポートの取り合わせが、要求されると判定することが可能である。ＡＳは、その新たな取り合わせを要求する新規の要求をＭＳＲＢに送信することができる。どのようなＭＳリソースが利用可能であるか、および会議に現在、割り当てられているＭＳリソースが、Ｇ．７２６もサポートすることができるかどうかに依存して、ＭＳＲＢは、同一のＭＳリソースからの、または異なるＭＳリソースからの、要求されたＧ．７２６ポートでＡＳに応答することができる。
【００３４】
実際のメディア  ストリームは、リンク２８０を介して（ＢＥ２１５を介して）、電話機２１０とＭＳ１６０の間で伝送され、このため、前段の説明は、ＲＴＰ（リアルタイム  トランスポート  プロトコル）で提供されることが可能な実際のメディア  ストリームのルーティングではなく、サービスを求める要求、およびサービスを提供することと関係する信号のルーティングに関することに留意されたい。
【００３５】
理解することができるように、前述の方法は、ＭＳＲＢが、Ｘ個までのレグに関する会議コールのための適切なＭＳの初期決定を行い、その情報をＡＳに提供することを可能にする。その時点以降、その会議コールに加わろうと試みるさらなるコール  レグは、その会議を扱うＭＳリソースの既知のＭＳアドレスに、ＡＳによって単に送信されることが可能である。ＡＳは、個別の各コールに関して、ＭＳＲＢに要求を行わなくてもよい。ＡＳが、ＭＳリソースをＭＳＲＢに要求し、ＭＳへのコール  レグをセットアップする工程、またはＭＳからのコール  レグをクリアする工程からの別々の工程において、ＭＳリソースが、もはや使用されなくなると、ＭＳＲＢに通知する、ＭＳＲＢを利用する、この「間接」方法は、他の方法に優るいくつかの利点を有する。可能な利点のいくつかには、（１）割り当てられたＭＳリソースが、もはや必要とされていない場合、そのことを判定するのが、コール  クリア  メッセージから、そのことを推測するＭＳＲＢではなく、ＡＳであることを可能にすること、これは、例えば、会議の状況において役立つ可能性がある、（２）或るコール、またはコールの集合に関して、より多い、またはより少ないリソース、あるいは異なるリソースを求めて、ＡＳが、要求を変更することを可能にすること、（３）ＡＳとＭＳＲＢの間のリソース  ネゴシエーションを可能にすること、（４）会議コールが、複数のＭＳ物理ユニットにまたがり、ＡＳが、それらのユニットをリンクし、会議全体を管理するネットワーク要素となるようにすることを可能にすることが含まれることが可能である。また、この間接方法は、ＩＶＲソリューションにおいて使用されることも可能である。ＩＶＲサービスが、提供されているケースにおける、この間接方法の可能な１つの欠点は（そのようなシナリオでは、一般に、ＭＳポートは、コールがクリアされると、解放されることが可能であるものと、推測して差し支えない）、ＭＳポートが解放されることが可能であることを判定するのに、より大きい遅延が生じる可能性があることである。しかし、この間接方法は、リソースがどのように割り当てられるかを、ＡＳがより大幅にコントロールすることを可能にし、ＭＳＲＢにかかる負担を減らし、以上の利点は、いずれの欠点も上回る可能性がある。
【００３６】
ＡＳとＭＳＲＢの間の対話は、基本的に、データベース要求およびデータベース応答と見なされることが可能であり、ＭＳＲＢが、データベースである。以上の説明は、ＳＩＰを使用する、ＣＣＥを介したＡＳとＭＳＲＢの間の通信に関する詳細を提供したが、代替の実施形態では、ＡＳとＭＳＲＢは、直接に通信することができる。或る実施形態では、ＡＳとＭＳＲＢは、ＳＩＰの代わりにＨＴＴＰを使用して通信することができる。例えば、ＡＳは、ＨＴＴＰ  ＧＥＴメッセージを使用して、ＭＳリソースを要求し、ＨＴＴＰ  ＰＯＳＴメッセージを使用して、ＭＳＲＢに、それらのリソースをアイドル  プールに戻させることができる。理解することができるように、ＡＳとＭＳＲＢの間の直接通信のために、他の任意の適切なプロトコルも、使用されることが可能である。
【００３７】
図４および図５を参照すると、着信コールを扱う方法の代替の実施形態が、示されている。工程５０４乃至工程５２０は、基本的に、図３における工程３０５乃至工程３２０と同一である。工程５２４で、ＡＳ１４０は、そのコールのためのＭＳリソースを求める要求であるとともに、ＭＳへの、そのコールを確立する要求でもあるＩＮＶＩＴＥをＣＣＥ１３０に送信する。工程５３０で、ＣＣＥ１３０は、ＭＳリソースおよびコール確立を求める要求をＭＳＲＢ１４０に転送し、ＭＳＲＢ１４０は、ＭＳ１６０が、その要求、および既知の／計画された利用に鑑みて、適切なＭＳであると判定する。工程５３４で、ＭＳＲＢ１４０は、コール  レグをセットアップするよう、ＭＳ１６０にＩＮＶＩＴＥメッセージを送信する。工程５４０で、ＭＳ１６０は、ＭＳＲＢ１４０に応答して、着信コール要求を受け付ける。工程５４４で、ＭＳＲＢは、パス４６０を介してＡＳ１２０に応答メッセージを送信して、情報が、ＣＣＥ１３０を通るようにする。工程５６０で、ＡＳ１２０は、ＣＣＥ１３０を介して、コール  セットアップ応答メッセージをＢＥ４１５に送信する。工程５６４で、ＢＥ４１５は、コール  セットアップ応答メッセージを電話機２１０に提供する。工程５７０で、ＭＳ１６０は、ＡＳ１２０からスクリプトを取得する。工程５７４で、ＭＳ１６０は、リンク２８０を介して電話機２１０にオーディオを送信して、対話型サービスを開始するようにする。工程５８０で、コールは、終了し、ＭＳＲＢ１４０は、ＳＩＰクリア信号通知から、ＭＳリソースは、アイドル  プールに戻されることが可能であるものと推測する。
【００３８】
理解することができるように、ＭＳＲＢ１４０は、ＡＳ１２０からＭＳ１６０へのコール確立要求を中継する。このため、ＩＶＲなどのサービスに関して、図４〜図５に示される、この「中継」方法の実施形態は、図２〜図３に示される間接方法の実施形態とは異なる、ＭＳＲＢとの対話をもたらす。この中継方法は、ＭＳリソースが、アイドルに戻されることが可能であることが、コールのクリアを観察することから推測されることが可能である場合に、ＭＳＲＢがそのことをより迅速に判定することを可能にし、間接方法と比べて、ＡＳとＭＳＲＢの間で、より少ない工程が関与する。しかし、この中継方法は、前述したとおり、ＡＳが行使することができるコントロールの大きさに関して、間接方法と比べてより限定的であることが可能である。
【００３９】
図６および図７は、間接方法および中継方法のさらなる図をそれぞれ提供する。理解することができるように、両方の方法は、いくつかの利点を有する。
【００４０】
最初に図６を見ると、工程６１０で、ＡＳがＭＳリソースを要求する。或る実施形態では、要求は、Ｘ個のポートを含む会議コールを開始することであることが可能である。工程６１５で、ＣＣＥが、その要求をＭＳＲＢ（前述したとおり、単一の論理データベースを共有する１つまたは複数の物理サーバであることが可能な）に転送する。工程６２０で、ＭＳＲＢが、ＭＳロケーションを決定する。この決定には、伝送遅延を最小限に抑えるように、地理的構成要素が含まれることが可能である。工程６２５で、ＭＳＲＢが、ＣＣＥを介してＡＳに、ＭＳのアドレスとともに２００  ＯＫ信号を送信する。
【００４１】
工程６３０で、ＣＣＥが、ＡＳの要求で、ＭＳと様々な電話機との間のコール  レグをセットアップする。工程６３５で、ＡＳとＭＳの間に制御レグがセットアップされる。制御レグは、ＡＳが話者のレグ音声入力を除いてすべてをミュートすること、またはすべての会議レグに告知を再生すること、または補助的な会議を作成すること、またはＮ個の最大音量のレグからの入力をミキシングすることなどの命令を、ＭＳに与えることを可能にする。さらに、予約されたすべてのポートが使用されている場合、ＡＳは、さらなるポートを要求することができる。これは、通常は問題ではない。というのは、要求はしばしば安全ファクタをもたらすように、いくつかの追加のポートを含むことが可能であるからである。ポートが足りなくなるのをさらに防止するのに、要求されたポート数の或るパーセンテージが、コール期間にわたって暫定的に割り当てられることが可能であり、それらのポートが必要とされていないとＡＳが判定すると、それらのポートが、他の使用のために解放されることが可能である。コールへの、予期されるより高い参加レベルに対する緩衝として作用する余分なポートが、提供される場合、それらのポートは、複数のコールで共有されることが可能であることに留意されたい。
【００４２】
工程６４０で、コールは、終了する。これは、最終コール  レグの終了によって決定されることが可能である。工程６４０でコールが終了すると、工程６４５で、リソースが割り当て解除されることが可能であることを、ＡＳが、ＭＳＲＢに信号通知する。或る実施形態では、信号は、ＢＹＥメッセージであることが可能である。工程６５０で、前に割り当てられたＭＳリソースが、アイドル  プールに戻される。
【００４３】
次に、図７を参照すると、やはり、会議コール  シナリオを想定する、中継方法の高レベルの図が示されている。工程７０５で、会議に関する第１のコール  レグが、ネットワークに入ってくると、ＡＳは、ＡＳが、ＭＳに、そのコール  レグが確立されることを要求するのと同一のメッセージの中で、ＭＳリソースを要求する。要求は、必要とされるＭＳリソースのタイプ、および必要とされるポートの数を含まなければならない。また、要求は、発呼者の地理的区域、および、分かっている場合、コールの見込まれる時間についての情報も含むことが可能である。図示される実施形態では、要求は、ＣＣＥに送信されるＩＮＶＩＴＥメッセージの形態になっている。工程７１０で、ＣＣＥが、同一の要求情報を有するＩＮＶＩＴＥメッセージをＭＳＲＢに送信する。工程７１５で、ＭＳＲＢが、適切なＭＳのロケーションを特定し、ＭＳの割り当てが、最新に保たれるように、ＭＳＲＢデータベースの中で割り当てを追跡する。
【００４４】
次に、工程７２０で、ＭＳＲＢが、コール  レグを作成するよう、ＭＳにＩＮＶＩＴＥメッセージを送信する。理解することができるように、ＭＳには、より少ない情報が与えられることが可能である。というのは、ＭＳは、他のＭＳと比べた、そのＭＳの利用可能性を判定する必要がないからである。工程７２５で、ＭＳが、コールの受け付けを示す、コール  セットアップ要求への応答メッセージ（例えば、２００  ＯＫ）を送信することにより、ＭＳＲＢに応答する。工程７３０で、ＭＳＲＢは、その情報をＣＣＥに提供して、発呼者が、ＭＳに接続されることが可能であるようにする。信号通知パスは、ＣＣＥに向かう途中でＡＳを通り、このため、電話機からＭＳに至る信号通知パスは、ＢＥからＣＣＥを通り、ＡＳを通り、ＣＣＥを通り、ＭＳＲＢを通り、ＭＳに至ることに留意されたい。
【００４５】
工程７４０で、ＭＳが、スクリプト、および必要とされるファイルをＡＳから取得する。スクリプトは、ＶＸＭＬフォーマットになっていることが可能であり、取得は、ＨＴＴＰ、または他の何らかの適切なプロトコルを介して達せられることが可能である。工程７４５で、発呼者とＭＳが対話する。ＭＳと電話機の間のリンク２８０（図４）上で行われるメディア対話は、既知の仕方でオーディオ  ストリームを伝送するための、ＲＴＰなどの任意の適切なプロトコルを使用することが可能である。
【００４６】
対話が完了すると、工程７５０で、ＡＳが、ＭＳおよび発呼者に向けてのコールをクリアする。工程７５５で、ＭＳＲＢが、コールのクリアを観察し、ＭＳリソースをアイドル  プールに戻す。理解することができるように、ＭＳＲＢは、コールをクリアするための信号通知パスにあるため、ポートが、もはや使用されていないことが、コール  レグのクリアから推測されることが可能である場合、そのことの迅速な通知を受信する。しかし、大規模な会議コールの場合、ＭＳＲＢが、各コール  レグの信号通知パスにあるという事実は、ＭＳＲＢの作業負荷を増大させるきらいがある可能性がある。
【００４７】
したがって、間接方法は、ポートが、どのように使用されているかを、ＡＳが、より大幅にコントロールすることを可能にし、例えば、大規模な会議コールを扱うために、好ましい可能性がある。しかし、中継方法は、各コール  レグのステータスに関する、より迅速な更新をもたらすことができ、ＩＶＲタイプのコールを扱うために、好ましい可能性がある。しかし、いずれの方法も、特定のタイプのコールには限定されないことに留意されたい。
【００４８】
本発明を、本発明の好ましい実施形態、および例示的な実施形態に関連して説明してきた。添付の特許請求の範囲および趣旨に含まれる、他の多数の実施形態、変形形態、および変更形態が、本開示を精読することで、当業者には想起されよう。
【図面の簡単な説明】
【００４９】
【図１】本発明の或る態様によるＶｏＩＰを配信する際に使用するためのシステムの実施形態を示す概略図である。
【図２】本発明の或る態様による間接方法を使用してＶｏＩＰを配信する際に使用するためのシステムの実施形態を示す概略図である。
【図３】本発明の或る態様による図２に示されるシステムを使用する方法の実施形態を示す図である。
【図４】本発明の或る態様による中継方法を使用してＶｏＩＰを配信する際に使用するためのシステムの実施形態を示す概略図である。
【図５】本発明の或る態様による図４に示されるシステムを使用する方法の実施形態を示す図である。
【図６】本発明の或る態様による間接方法の実施形態を示す図である。
【図７】本発明の或る態様による中継方法の実施形態を示す図である。
【図８】本発明の或る態様による分散されたメディア・サーバ・セットの概略の実施形態を示す図である。
【図１】
2008537413.tif 000002
【図２】
2008537413.tif 000003
【図３】
2008537413.tif 000004
【図４】
2008537413.tif 000005
【図５】
2008537413.tif 000006
【図６】
2008537413.tif 000007
【図７】
2008537413.tif 000008
【図８】
2008537413.tif 000009
【国際調査報告】
2008537413.tif 000010
2008537413.tif 000011
2008537413.tif 000012