JP4823306B2

JP4823306B2 - ＶｏＩＰネットワークにおけるメディアサーバリソースの管理

Info

Publication number: JP4823306B2
Application number: JP2008506832A
Authority: JP
Inventors: バンナー，バーバラ，レスリー; ディトリッヒ，トーマス，ジェー．; ドビン，ジェイ; へフェイル，クリストファー; イベヅィム，ジェームス，エー．; ムンソン，ガリー，エー．; マーフィー，ジェームス，ウィリアム; リッチアーディ，ドミニック，エム．; ストッキー，ロバート，ジュニヤ
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 2005-04-22
Filing date: 2006-04-17
Publication date: 2011-11-24
Anticipated expiration: 2026-04-17
Also published as: EP1872560A1; CA2599407A1; JP2008537413A; KR100950872B1; KR20070112475A; WO2006115976A1

Description

本発明は、ＶｏＩＰで使用するために構成されたネットワークにおけるメディアサーバリソースの管理の分野に関する。

本国際出願は、２００５年４月２２に出願した仮出願第６０／６７４，２４４号の利益を主張し、２００５年１２月２９日に出願した米国特許出願第１１／３２１，７６０号の優先権を主張し、２００５年１２月２９日に出願した米国特許出願第１１／３２１，７３４号の優先権をさらに主張する。

ＶｏＩＰの使用は既知である。基本的に、ＶｏＩＰは、個人の可聴の会話（アナログである）を符号化して、データパケット（デジタルである）にして、デジタルパケットが、ＩＰ（インターネットプロトコル）ネットワークを介して送信されることが可能であるようにする、μ−ｌａｗを使用するＧ．７１１などの、ただし、それには限定されないコーデックを使用することにかかわる。周知のとおり、ＩＰネットワークは、音声の他にも、データサービス（ファイル転送、電子メール、インスタントメッセージングなど）に加えて、ビデオまたはファックスなどの、他の種類のトラフィックを伝送することができる。そのような収斂した、または統合されたネットワークは、ネットワークプロバイダおよびユーザへの経済的利点、および運用上の利点がある。

ＶｏＩＰサービスには、ネットワーク内の装置との、通常、メディアサーバとのメディアベースの発呼者対話がかかわることが可能である。そのような対話は、例えば、ただし、限定なしに、二重トーンマルチ周波数（ｄｕａｌｔｏｎｅｍｕｌｔｉ−ｆｒｅｑｕｅｎｃｙ：ＤＴＭＦ）ルーチンまたは音声プロンプト−コレクトルーチン（例えば、フリーダイヤルサービスのため、またはボイスメールを取り出すために使用されることが可能）のため、告知を聞くため、あるいは電話会議コールに参加するためであることが可能である。この概念は、例えば、限定なしに、ファックスストアアンドフォワードまたはテレビ会議を含むことが可能なＳｏＩＰ（ＳｅｒｖｉｃｅｓｏｖｅｒＩＰ）として、より一般的に知られる、ＶｏＩＰ以外のサービスにまで一般化される。
「ＣｏｍｍｏｎＶｏＩＰＡｒｃｈｉｔｅｃｔｕｒｅ」（ＡＴ＆ＴＰｏｉｎｔＯｆＶｉｅｗ／ＶｏＩＰ、２００３年１２月２２日）

メディアサーバが特定のサービスをどのように提供するかを操縦するロジックが、アプリケーションサーバによって提供されることが可能である。メディアサーバに対してアプリケーションサーバを使用するための基本的なアーキテクチャは、周知である。しかし、より多数のメディアサーバを扱う多数のアプリケーションサーバが、存在することが可能である。したがって、様々なアプリケーションサーバに関してメディアサーバの利用を管理するのに、何かが必要とされている。

本発明の諸態様は、ＶｏＩＰコールに、より一般的には、ＳｏＩＰコールに割り当てられたメディアサーバリソースを管理するための方法に関する。或る実施形態では、アプリケーションサーバは、ＶｏＩＰ電話機、または他の顧客装置などのＩＰノードを発信元とするサービス要求を受信する。これに応答して、アプリケーションサーバは、要求されたサービスを提供するメディアサーバリソースを要求する。メディアサーバリソース要求は、メディアサーバリソースブローカに送られることが可能である。メディアサーバリソースブローカは、要求されたサービスを提供する適切なメディアサーバを決定し、その情報をアプリケーションサーバに提供する。すると、アプリケーションサーバは、メディアサーバとＩＰノードが接続されるようにすることができ、アプリケーションサーバは、メディアサーバが、必要に応じて、ＩＰノードと対話することを可能にするロジックを提供する。

別の実施形態では、アプリケーションサーバは、ＶｏＩＰ電話機、または他の顧客装置などのＩＰノードを発信元とするサービス要求を受信する。これに応答して、アプリケーションサーバは、要求されたサービスを提供するメディアサーバリソースを要求する。メディアサーバリソース要求は、メディアサーバリソースブローカに送られることが可能である。メディアサーバリソースブローカは、要求されたサービスを提供する適切なメディアサーバを決定し、そのメディアサーバに問い合わせて、ＩＰアドレスを特定する。すると、メディアサーバリソースブローカは、メディアサーバが、ＩＰノードに接続されるようにすることができる。次に、アプリケーションサーバが、メディアサーバが、ＩＰノードとのコールを管理することを可能にするロジックを提供することができる。

本発明は、同様の符号が同様の要素を示す添付の図において、例として示されているが、それには限定されない。

前述したとおり、ＶｏＩＰを提供するためのアーキテクチャは、周知であり、一例が、「ＣｏｍｍｏｎＶｏＩＰＡｒｃｈｉｔｅｃｔｕｒｅ」という名称の白書、ＡＴ＆ＴＰｏｉｎｔＯｆＶｉｅｗ／ＶｏＩＰ、２００３年１２月２２日において開示されており、この白書は、参照により全体が本明細書に組み込まれている。しかし、共有することの利点に動機付けられて、ＭＳ（メディアサーバ）の共有プールを扱う様々なサービスをサポートする多数のＡＳ（アプリケーションサーバ）が、存在することが可能である。

ＭＳの共有プールの使用により、ＶｏＩＰを提供するのに使用されるリソースのより効率的な使用が可能になる。例えば、ＭＳリソースが、地域レベルで管理される場合、より高い効率が可能である。管理されるＭＳの数が増加し、ＭＳのロケーションがより分散されるにつれ、得られることが可能な効率は、さらにより顕著になる。

図１を参照すると、システムの高レベルの概略図が、開示されている。システム内に示される要素のそれぞれは、一緒にリンクされた１つまたは複数の物理的要素または論理的要素を含むモジュールであることが可能であることに留意されたい。ＡＳ１２０が、ＣＣＥ（コール制御要素）１３０に接続されているのが示されている。一般に、ＡＳは、電話システムのユーザに、ボイスメールなどのサービスを提供することができ、それらのサービスは、ＬＤＡＰ（ライトウェイトディレクトリアクセスプロトコル）ルックアップなどのネットワークリソースを含むことが可能である。また、ＡＳは、複数のパーティをマルチキャスト会議に接続するロジックを背景で扱うこともでき、可聴のプロンプトの提供、およびそれらのプロンプトへの応答の収集を介してユーザと対話するためのスクリプトを提供することができる。したがって、ＡＳは、所望されるサービスを発呼者に提供するのに必要なロジックを提供することができ、他のデバイスと通信する際の特定のプロトコルの使用に限定されない。通常、ＡＳは、特定の機能のためにプログラミングされる。このため、或る実施形態では、ＡＳは、１つまたは複数の記録されたメッセージを生成する命令を提供することにより、コールセンタへのコールを扱うのに必要とされるロジックを提供し、ユーザ入力に構造化された応答を提供し、ＩＶＲ（対話型音声応答）インタフェースにおいて一般的であるように、受け取られた数字を処理するようにプログラミングされることが可能である。

通常、ＡＳ１２０は、エンドユーザ自体とメディア対話を実行しないが、代わりに、ＭＳ１６０に命令を与えることができる。或る実施形態では、ＭＳ１６０は、音声認識エンジンと、会議ブリッジと、ＴＴＳ（テキストツー音声）エンジンとを含むことが可能であり、あるいは記録されたメッセージを再生し、発呼者によって入力された数字を収集して、個人が、ＡＳ１２０によって提供されるロジックと対話することができるようにすることが可能である。

ＡＳ１２０は、潜在的に、ＳＩＰ（セッション開始プロトコル）を使用して提供されることが可能な、着信コールから受け取られた信号と直接に対話することもできる。しかし、ＡＳ１２０は、好ましくは、ＡＳ１２０のためのプロキシの役割をするようにＣＣＥ（コール制御要素）を使用することができる。したがって、着信コールは、ＣＣＥによってルーティングされることが可能であり、コールレグは、所望に応じて、ＡＳにおけるサービスロジックの誘導の下で、ＣＣＥによって追加される、変更される、または削除されることが可能である。このため、図１に示されるとおり、ＣＣＥ１３０は、どのようにコールが、ネットワークにアクセスするか、またはネットワークから出て行くかについての詳細を、ＡＳ１２０が無視することを可能にし、したがって、ＡＳ１２０は、代わりに、どのようにコールが扱われるかについての論理に集中することができる。

ＡＳ１２０は、着信コールを直接に扱わないように構成されることが可能であるが、着信コールからの或る量の情報が、所望されるサービスを提供するのに役立つ可能性がある。このため、ＡＳ１２０は、ＣＣＥ１３０と通信するように構成されることが可能である。ＡＳとＣＣＥ１３０の間で通信する一方法は、ＳＩＰの使用である。さらに、ＡＳ１２０は、ＭＳ１６０と通信して、発呼者とのメディア対話に関してどのようにするかについて、ＭＳ１６０に命令するように構成されることが可能である。そのような通信には、例えば、限定なしに、ＭＳＭＬ（メディアセッションマークアップ言語）およびＭＯＭＬ（メディアオブジェクトマークアップ言語）、またはＶＸＭＬ（音声拡張マークアップ言語）がかかわることが可能である。

ＡＳ１２０、ＣＣＥ１３０、およびＭＳ１６０は、命令、およびコールを処理することの詳細を扱う。しかし、図８に示されるとおり、ＡＳ１２０ａは、ＭＳモジュール１６１〜１６６と対話することができ、各ＭＳモジュールは、異なる地域に位置している。本明細書で使用される、各ＭＳモジュールは、１つまたは複数の物理サーバから成ることが可能であり、地域は、物理的場所、市、郡、州、または国から成ることが可能である。このため、地域レベルにおける管理は、２つ以上の地域を管理する。異なる地域においてＭＳを提供することは、広大な距離をまたぐ必要なしに、それらの地域近く、またはそれらの地域内に位置する個人にサービスを提供することができるという利点を有することに留意されたい。しかし、様々なＭＳの効率的な利用は、或る特定の地域において何が起きているかを単に認識していることにより、すべての地域における全体の利用可能なＭＳリソースが効率的に利用されていることは確実にならないため、より複雑となる。

また、ＡＳ１２０ｂのような追加のＡＳが、ＭＳ１６１〜１６６を使用することも可能である（より明瞭にするため、図８内のＡＳ１２０ｂとＭＳの間の接続は、示されていない）。しかし、ＡＳ１０２ａとＡＳ１２０ｂは、独立に動作していることが可能であり、異なるサービスをサポートすることが可能であり、異なるサービスプロバイダによって提供されることが可能であるので、ＡＳ１２０ａも、ＡＳ１２０ｂも、ＭＳ１６１も、他のＭＳと比べてＭＳ１６１にかかる負荷を認識しているものと見込むことはできない。

したがって、リソース利用を向上させるのを助けるのに、ＭＳＲＢ（メディアサーバリソースブローカ）１４０が、利用されることが可能である。ＭＳＲＢ１４０は、ＭＳサービスを求める要求を受信し、その要求、およびＭＳの現在の利用に応じて、要求されたサービスを提供する適切なＭＳを決定する。ＭＳＲＢ１４０は、コールの地理的発信元、様々なＭＳに対するコールの発信元の近さ、ＭＳの能力、サポートされる必要があるコールレグの数、必要とされるリソースのタイプ（例えば、音声認識エンジンまたは数字収集が要求されるかどうか）、コールレグが活性である時間の長さ、将来の予約（例えば、所与のサービス、または来るべき、スケジュールされた会議コールのための最小容量）、およびＭＳの利用に影響を与える可能性があり、したがって、所望されるサービスのデリバリに影響を与える可能性がある他の任意のパラメータなどの、ただし、以上には限定されない、利用可能な帯域幅の使用の単なるパーセンテージ以外の、利用と関係するさらなるパラメータも考慮することができる。ＭＳリソースを選択するためにＭＳＲＢ１４０が使用する情報の一部は、ポートに関して必要とされるコーデックのタイプ、ポート使用の見込まれる時間、地理的選好、必要とされるポートの数、制御プロトコル（ＶＸＭＬ、またはＭＳＣＭＬ（メディアサーバ制御マークアップ言語）、またはＭＲＣＰ（メディアリソース制御プロトコル）などの）に関する選好、会議識別番号（スケジュールされた会議コールに関する）、要求が行われている顧客サービス、あるいはＤＴＭＦ収集が必要とされているか、または或るタイプの音声認識が必要とされているかなどの、ただし、以上には限定されない、ＡＳ１２０からの要求の属性として入手されることが可能である。

例えば、図１に戻ると、ＭＳＲＢＳＩＰコントローラ１４５は、音声認識能力を有するＭＳを求める要求を受信することが可能である。その要求は、２時間という期間にわたって１００のポートを求めるデマンドを含むことが可能である。本明細書で使用される、ポートという用語は、物理ポートに限定されず、代わりに、論理ポートを指すことに留意されたい。このため、ポートは、各着信コールに関して、所望されるサービスを提供するために十分な帯域幅、および処理能力、および諸能力の単位であると考えられることが可能である。したがって、１００の論理ポートの必要性は、１００以上のコールを同時に扱うのに十分な能力を有する単一の物理ポートの一部分を使用して満たされることが可能である。さらに、ＭＳＲＢが、個々のポートの割り当てを識別し、追跡しているのではなく、所望されるタイプのポートにアクセスすることがでるＭＳアドレスを識別し、そのレベルにおけるリソース割り当てを追跡するだけで十分である。

サーバであることが可能なＭＳＲＢＳＩＰコントローラ１４５は、ＭＳＲＢデータベース１５０に問い合わせて、ネットワークにおけるすべての利用可能なＭＳの現在の利用、計画された利用、および容量を特定することができる。前述の例を続けると、ＭＳ１６０が、２時間にわたって１００のポートを提供する十分な容量を有することを特定した後、ＭＳ１６０のアドレスが、ＣＣＥ１３０を介してＡＳ１２０に提供されることが可能である。或る実施形態では、ＡＳおよびＣＣＥは、次に、接続１２２および１６４を介してＭＳ１６０を直接に相手にして、ＭＳＲＢ１４０のさらなる関与なしに、ＭＳ１６０に至るコールレグをセットアップする。代替の実施形態では、信号は、ＣＣＥ１３０を通ってＭＳＲＢ１４０に流れた後、ＭＳ１６０まで流れる。以上２つの方法を、以下により詳細に説明する。

ＭＳＲＢ１４０が、要求されたサービスを提供することができるＭＳのＩＤをＡＳに提供する際、ＭＳＲＢ１４０は、そのＭＳの使用をＭＳＲＢデータベース１５０の中に格納する。このため、前述の例を続けると、ＭＳサービスを求める将来の要求は、ＭＳ１６０が、２時間の期間にわたって割り当てられた１００のポートを有するという事実を考慮に入れる。ＭＳＲＢ１４０は、ネットワーク上のＭＳのセットを使用するすべてのＡＳに関する要求を受信し、ＭＳＲＢ１４０は、現在の要求、および予約に基づく、ネットワーク上のすべてのＭＳの割り当てを把握しているので、ＭＳＲＢ１４０は、各ＡＳによって必要とされるサービスが提供されることを確実にしながら、様々なＭＳのより高い利用をもたらすことができる。

前述の例では、２時間という期間にわたって１００のポートが要求されたが、１時間後、ほとんどすべてのポートが空いていることが可能である。例えば、ＭＳ１６０が、インフォマーシャルなどの広告に応答して発呼した顧客にＩＶＲを提供していた場合、インフォマーシャルの終了により、着信コールの数が、大幅に減ることが生じることが可能である。ＡＳ１２０は、コール信号通知パスにあるため、任意の時点で、いくつのコールレグが、ＭＳ１６０に接続されているかを認識している。１時間後、インフォマーシャルに関するコールを扱うＡＳ１２０は、着信コール量が、最後の１時間にわたって４０のポートしか必要とされないようなものである判定することが可能であり、したがって、ＡＳ１２０は、その時点で、ポートのうち６０個が、ＭＳアイドルプールに戻されることが可能であることをＭＳＲＢ１４０に通知することにより、それだけの数のポートを解放することができる。このアプローチは、ＭＳＲＢが、ネットワークリソースをより効率的に管理することを可能にすることができ、その他の潜在的な利点をもたらすこともできる。図示されるとおり、ＭＳＲＢ１４０と、ＡＳのセットとが、信号通知エラーまたはＡＳ障害などの事態により、同期しなくなることに対する対策として、ＭＳＲＢが、実際のＭＳ利用を把握しているように、１つまたは複数のＯＳＳ（オペレーションサポートシステム）１７０とＭＳＲＢ１４０との間で通信パス１７５が提供される。ＯＳＳは、サービスごとの予約、会議ごとの予約、ＭＳの計画されたダウン時間、ＭＳの計画外のダウン時間、ＭＳ装置追加、およびＭＳ装置削除などのファクタを含む利用更新を提供することが可能である。或る実施形態では、ＭＳ利用情報は、パス１８０を使用して、ＯＳＳ１７０経由でＭＳ１６０からＭＳＲＢ１４０に来ることが可能である。代替の実施形態では、利用情報は、パス１６２を使用して、直接に提供されてもよい。

或る実施形態では、割り当てられたポートの数を減らす代わりに、ＡＳ１２０は、例えば、観察されるコール量が、予期されていたよりも多い場合、ＭＳＲＢ１４０から、追加のポートを代わりに要求することができる。

しかし、すべての要求が、完全に満たされるわけではない可能性があることに留意されたい。例えば、第１のＡＳに関してＸ個のポートを求める要求が、第２のＡＳからの、Ｙ個のポートを求める要求、および第３のＡＳからの、Ｚ個のポートを求める要求と一緒に受信される可能性があり、ＸとＹとＺの合計が、ＭＳ上で利用可能なＮ個のポートという容量を超える可能性がある。理解することができるように、異なるＭＳには、異なる数のポートが利用可能であり、したがって、異なる利用レベルを有することが可能である。第１のＡＳからのＸ個のポートを求める要求が会議コールと関係しており、その他の要求がＩＶＲと関係している場合、可能な１つの応答は、Ｘ個のポートを求める要求をそのＡＳに許可し、Ｙ個のポートを求める要求、およびＺ個のポートを求める要求の一部を、第２のＡＳおよび第３のＡＳに許可することである。すると、第２のＡＳおよび第３のＡＳは、その部分的な提供を受け入れるかどうかを決定することができる。第２のＡＳと第３のＡＳがともにその部分的な提供を受け入れるものと想定すると、ＭＳＲＢは、各ＡＳ要求に関して割り当てられたポートの数を記録に留める。

さらに、会議コールをサポートするようにＸ個のポートを求める要求が、接続する発呼者の数を過大評価（または過小評価）する可能性があり、コールが接続される時間も過大評価（または過小評価）する可能性がある。さらに、ＡＳは、いくつのポートをＡＳが所望するか、またはＡＳが所望するポートのタイプに関して、ＭＳＲＢに対するＡＳの要求を変更することができる。また、ＭＳＲＢは、他のＡＳによる、提供されたポートの利用についても認識している。このため、ポートが利用可能になると、それらのポートは、適宜、別のＡＳをサポートするように移されることが可能である。

図１に示されるとおり、ＯＳＳ（オペレーションサポートシステム）１７０が、ＭＳＲＢ１４０に接続される。或る実施形態では、ＯＳＳ１７０は、将来のサービスを求める要求に応答して、リソースの将来の利用をスケジュールするよう、ＭＳＲＢに要求することができる。例えば、２０００のコールレグを有する大規模な会議コールを行うことを計画している個人は、前もって、その会議コールをスケジュールして、その会議コールに参加することを計画している２０００名すべての人々が、その会議コールに実際に加わることができることを確実にしたいと所望する可能性がある。ＭＳＲＢは、前にスケジュールされた任意の利用に基づき、その会議コールを扱う好ましいＭＳを決定することもできる。また、ＭＳＲＢは、ＭＳのスケジュールされた使用を調整して、各ＭＳのより一貫した利用レベルがもたらされるようにすることもできることに留意されたい。このため、第１のＭＳ、および第２のＭＳを伴う或る実施形態では、ＭＳＲＢは、第１のＭＳの前にスケジュールされた利用を第２のＭＳに移し、新規の要求を扱うよう、第１のＭＳをスケジュールすることができる。また、様々な優先順位（例えば、或る会議コールへのポートの割り当てが、ＩＶＲへのポートの割り当てよりも高い優先順位を有することが可能である）に応じて、変更が行われることも可能である。ＭＳが失われたことなどの技術問題に応答して、さらなる変更が行われてもよい。このため、ＭＳＲＢは、ネットワーク上でＭＳを利用する堅牢で、効率的な手段を提供する。

ＶｏＩＰ技術の使用において周知のとおり、ＢＥ、ＣＣＥ、ＭＳ、およびＡＳのネットワーク要素の間、およびＢＥとＳＩＰ電話機との間の基礎をなす信号通知は、複数のプロトコル、例えば、限定なしに、ＳＩＰ、Ｈ．３２３、またはＭＧＣＰ（メディアゲートウェイ制御プロトコル）の何らかの組み合わせである。前述の要素の任意の２つの間で使用されることが可能なＳＩＰを使用する或る実施形態では、一連の要求メッセージ（例えば、ＩＮＶＩＴＥ、ＢＹＥ、ＡＣＫ）および応答メッセージ（例えば、１８０Ａｌｅｒｔｉｎｇ、２００ＯＫ）を使用して、メディアセッションが確立されること、およびクリアされることが可能である。ＳＩＰメッセージは、例えば、ＳＩＰＵＲＩの形態で、ＳＩＰ信号通知エンティティを識別するアドレス情報を伝送する。また、ＳＩＰメッセージは、ＳＤＰ（セッション記述プロトコル）を使用して、メディア情報を含め、様々なタイプのペイロード情報を伝送することもでき、その場合、ＳＤＰコンテンツは、メディア受信ＩＰアドレス、およびメディアエンドポイントのポート番号、およびメディアの特性（例えば、Ｇ．７２６符号化されたオーディオ）のような事物を示す。メディアアドレスの交換により、メディア接続が確立される。メディア自体は、ＲＴＰ（リアルタイムトランスポートプロトコル）のようなプロトコルを使用して転送される。

さらに、図１は、ＶｏＩＰネットワークの図である。ＢＥ、ＣＣＥ、ＡＳ、およびＭＳなどの要素は、ＶｏＩＰネットワークにおいて見られる機能の、いくつかの典型的なグループ化を具体化する。したがって、それらの要素は、開示される諸実施形態に限定されるべきではなく、むしろ、説明される諸機能を実行する諸要素を対象とする。例えば、或る実施形態では、ＢＥは、セッション境界コントローラであることが可能であり、ネットワーク内部アドレスとネットワーク外部アドレスとの間の変換を含むことが可能な、ネットワーク外部エンティティに関する様々なセキュリティ機能、ポリシー機能、ならびにプロトコルインタワーキング−トランスコーディング機能を実行することが可能である。或る実施形態では、ＣＣＥは、コールエージェントまたはソフトスイッチであることが可能であり、ルーティング、またはＡＳ呼び出しおよびＡＳ対話などの、基本的なコール処理機能を実行することが可能である。理解することができるように、以上の要素は、そのように限定されず、様々な要素の他の既知の変種が、適宜、使用されてもよい。

図２および図３を参照すると、着信コールを扱う方法の実施形態が示されている。最初に、工程３０５で、ＩＰノードの例である電話機２１０が、ＳＩＰにおいて使用されるフォーマットであるＩＮＶＩＴＥメッセージをＢＥ２１５に送信する。このメッセージは、他の任意の既知のプロトコルで提供されることも可能であり、このメッセージは、サービス要求の例である。ＩＮＶＩＴＥメッセージは、宛先アドレス、および／または所望されるサービスのタイプの何らかの指示を含むことが可能である。次に、ＢＥ２１５が、ローカルポリシー（例えば、着信信号通知が、許されたＩＰアドレスからであるかどうか、または要求されたコール帯域幅が、許されるパラメータの範囲内にあるかどうか）に基づき、そのコールを受け付けるかどうかを決定する。ＳＩＰ電話機（ＬｉｎｋｓｙｓＲＴ４１Ｐ２のような、ただし、これに限定されない）は、コール発信デバイスの一例であり、コール発信デバイスは、ネットワークに直接に接続されても、中間ネットワークを介して接続されてもよい。

次に、コールを受け付けた後、ＢＥ２１５は、工程３１０で、ＣＣＥ１３０にＩＮＶＩＴＥメッセージを送信する。そのメッセージを受信すると、ＣＣＥ１３０は、ＳＢ（サービスブローカ）に問い合わせて、ＩＮＶＩＴＥの中のＴＮ（電話番号）または他の情報に関連するサービスフィーチャが存在するかどうかを確認する。ＳＢは、適切なＡＳのアドレスで応答することができる。次に、工程３１５で、ＣＣＥ１３０が、ＩＮＶＩＴＥの中に含まれるＴＮまたは他の情報に関連するＡＳである、ＡＳ１２０にＩＮＶＩＴＥメッセージを送信する。

工程３２０で、ＡＳ１２０は、ＮＳ（ネットワークサーバ）２２０から、さらなる情報を要求する。ディレクトリ要求であることが可能な、この要求は、ＳＯＡＰ、ＬＤＡＰ、ＳＭＴＰ、または他の何らかのプロトコルによって提供されることが可能であり、ＭＳＲＢによってサポートされるネットワーク内のサーバに向けられることが可能であり、またはネットワークの外部（例えば、インターネット上のどこか）であることが可能である。

工程３２５で、ＡＳ１２０が、ＭＳリソース、および所望されるＭＳ属性を要求するＩＮＶＩＴＥメッセージをＣＣＥ１３０に送信する。工程３４０で、ＣＣＥ１３０が、その要求をＭＳＲＢ１４０に転送する。ＭＳＲＢ１４０は、複数のサーバから成ることが可能であり、ＣＣＥ１２０は、ラウンドロビンのやり方で、異なるサーバにメッセージを送信することが可能であるが、ＭＳＲＢ１４０が、すべてのＭＳリソースの活動を把握しておくことができるように、ＭＳＲＢ１４０に関連する、すべてのＭＳに関する活動の単一の論理データベースが、要求されることに留意されたい。つまり、異なるＭＳＲＢが、同一のＭＳリソースを使用することができてはならない。

工程３４５で、ＭＳＲＢ１４０が、要求、および現在の／計画された利用レベルに鑑みて、適切なＭＳを決定する。会議コールの場合、所与の会議に関するすべてのコールレグを扱うのに、単一のＭＳを使用することが好ましい可能性がある。しかし、ＩＶＲタイプのコールの場合、複数のＭＳが、効率的に使用されることが可能であり、したがって、ＭＳＲＢ１４０は、様々なＭＳが、それらの様々なＭＳの既存の利用に応じて、純粋な分割で、または重み付き割り当てで、要求されたポートの一部を提供することができると判定することが可能である。

工程３５０で、ＭＳＲＢ１４０が、ＣＣＥ１３０を介して、ＡＳ１２０にＭＳアドレス、および他の任意の適切な情報を提供する。ＡＳ要求が、表明されるとおりに許可されることが可能でない場合、ＭＳＲＢは、代替で応答することが可能である（例えば、要求が、米国東部において１００のポートを求めていたのに対して、５０のポートが、米国西部におけるＭＳにおいて提供されることが可能である）。工程３５５で、ＡＳ１２０は、ＭＳ１６０に対するコールレグをセットアップするよう、ＣＣＥ１３０に命令する。工程３６０で、ＣＣＥ１３０は、コールに参加するよう、ＭＳ１６０に要求するＩＮＶＩＴＥメッセージをＭＳ１６０に送信する。工程３６５で、ＭＳ１６０は、コールを受け付ける応答をＣＣＥ１３０に送信する。工程３７０で、ＣＣＥ１３０は、応答をＢＥ２１５に中継する。工程３７５で、ＢＥは、応答を電話機２１０に送信して、電話機２１０とＭＳ１６０が、メディアリンクを確立するようにする。工程３８０で、ＡＳ１２０が、２１０からの電話コールを扱うための命令をＭＳ１６０に与える。ＭＳリソースの一部またはすべてが、もはや必要とされていない、例えば、コールまたは会議が終了した、またはより少ないポートが必要とされているとＡＳ１２０が判定した場合、ＡＳ１２０は、ＭＳＲＢ１４０と通信して、全部の数の、またはいくつかの数のポートをＭＳアイドルリソースプールに戻させることができる。或る実施形態では、ＡＳは、ポートの現在の必要性が、ポートの数、タイプ、またはタイプの取り合わせを求める初期の要求と一致しないと判定することが可能である。さらに、現在の割り当てられたポートが、追加の期間にわたって必要とされる可能性がある。例えば、ＡＳが、最初、Ｇ．７１１コーディングを使用するいくつかのポートを要求し、その後の何らかの時点で、３／４のＧ．７１１ポートと１／４のＧ．７２６ポートの取り合わせが、要求されると判定することが可能である。ＡＳは、その新たな取り合わせを要求する新規の要求をＭＳＲＢに送信することができる。どのようなＭＳリソースが利用可能であるか、および会議に現在、割り当てられているＭＳリソースが、Ｇ．７２６もサポートすることができるかどうかに依存して、ＭＳＲＢは、同一のＭＳリソースからの、または異なるＭＳリソースからの、要求されたＧ．７２６ポートでＡＳに応答することができる。

実際のメディアストリームは、リンク２８０を介して（ＢＥ２１５を介して）、電話機２１０とＭＳ１６０の間で伝送され、このため、前段の説明は、ＲＴＰ（リアルタイムトランスポートプロトコル）で提供されることが可能な実際のメディアストリームのルーティングではなく、サービスを求める要求、およびサービスを提供することと関係する信号のルーティングに関することに留意されたい。

理解することができるように、前述の方法は、ＭＳＲＢが、Ｘ個までのレグに関する会議コールのための適切なＭＳの初期決定を行い、その情報をＡＳに提供することを可能にする。その時点以降、その会議コールに加わろうと試みるさらなるコールレグは、その会議を扱うＭＳリソースの既知のＭＳアドレスに、ＡＳによって単に送信されることが可能である。ＡＳは、個別の各コールに関して、ＭＳＲＢに要求を行わなくてもよい。ＡＳが、ＭＳリソースをＭＳＲＢに要求し、ＭＳへのコールレグをセットアップする工程、またはＭＳからのコールレグをクリアする工程からの別々の工程において、ＭＳリソースが、もはや使用されなくなると、ＭＳＲＢに通知する、ＭＳＲＢを利用する、この「間接」方法は、他の方法に優るいくつかの利点を有する。可能な利点のいくつかには、（１）割り当てられたＭＳリソースが、もはや必要とされていない場合、そのことを判定するのが、コールクリアメッセージから、そのことを推測するＭＳＲＢではなく、ＡＳであることを可能にすること、これは、例えば、会議の状況において役立つ可能性がある、（２）或るコール、またはコールの集合に関して、より多い、またはより少ないリソース、あるいは異なるリソースを求めて、ＡＳが、要求を変更することを可能にすること、（３）ＡＳとＭＳＲＢの間のリソースネゴシエーションを可能にすること、（４）会議コールが、複数のＭＳ物理ユニットにまたがり、ＡＳが、それらのユニットをリンクし、会議全体を管理するネットワーク要素となるようにすることを可能にすることが含まれることが可能である。また、この間接方法は、ＩＶＲソリューションにおいて使用されることも可能である。ＩＶＲサービスが、提供されているケースにおける、この間接方法の可能な１つの欠点は（そのようなシナリオでは、一般に、ＭＳポートは、コールがクリアされると、解放されることが可能であるものと、推測して差し支えない）、ＭＳポートが解放されることが可能であることを判定するのに、より大きい遅延が生じる可能性があることである。しかし、この間接方法は、リソースがどのように割り当てられるかを、ＡＳがより大幅にコントロールすることを可能にし、ＭＳＲＢにかかる負担を減らし、以上の利点は、いずれの欠点も上回る可能性がある。

ＡＳとＭＳＲＢの間の対話は、基本的に、データベース要求およびデータベース応答と見なされることが可能であり、ＭＳＲＢが、データベースである。以上の説明は、ＳＩＰを使用する、ＣＣＥを介したＡＳとＭＳＲＢの間の通信に関する詳細を提供したが、代替の実施形態では、ＡＳとＭＳＲＢは、直接に通信することができる。或る実施形態では、ＡＳとＭＳＲＢは、ＳＩＰの代わりにＨＴＴＰを使用して通信することができる。例えば、ＡＳは、ＨＴＴＰＧＥＴメッセージを使用して、ＭＳリソースを要求し、ＨＴＴＰＰＯＳＴメッセージを使用して、ＭＳＲＢに、それらのリソースをアイドルプールに戻させることができる。理解することができるように、ＡＳとＭＳＲＢの間の直接通信のために、他の任意の適切なプロトコルも、使用されることが可能である。

図４および図５を参照すると、着信コールを扱う方法の代替の実施形態が、示されている。工程５０４乃至工程５２０は、基本的に、図３における工程３０５乃至工程３２０と同一である。工程５２４で、ＡＳ１４０は、そのコールのためのＭＳリソースを求める要求であるとともに、ＭＳへの、そのコールを確立する要求でもあるＩＮＶＩＴＥをＣＣＥ１３０に送信する。工程５３０で、ＣＣＥ１３０は、ＭＳリソースおよびコール確立を求める要求をＭＳＲＢ１４０に転送し、ＭＳＲＢ１４０は、ＭＳ１６０が、その要求、および既知の／計画された利用に鑑みて、適切なＭＳであると判定する。工程５３４で、ＭＳＲＢ１４０は、コールレグをセットアップするよう、ＭＳ１６０にＩＮＶＩＴＥメッセージを送信する。工程５４０で、ＭＳ１６０は、ＭＳＲＢ１４０に応答して、着信コール要求を受け付ける。工程５４４で、ＭＳＲＢは、パス４６０を介してＡＳ１２０に応答メッセージを送信して、情報が、ＣＣＥ１３０を通るようにする。工程５６０で、ＡＳ１２０は、ＣＣＥ１３０を介して、コールセットアップ応答メッセージをＢＥ４１５に送信する。工程５６４で、ＢＥ４１５は、コールセットアップ応答メッセージを電話機２１０に提供する。工程５７０で、ＭＳ１６０は、ＡＳ１２０からスクリプトを取得する。工程５７４で、ＭＳ１６０は、リンク２８０を介して電話機２１０にオーディオを送信して、対話型サービスを開始するようにする。工程５８０で、コールは、終了し、ＭＳＲＢ１４０は、ＳＩＰクリア信号通知から、ＭＳリソースは、アイドルプールに戻されることが可能であるものと推測する。

理解することができるように、ＭＳＲＢ１４０は、ＡＳ１２０からＭＳ１６０へのコール確立要求を中継する。このため、ＩＶＲなどのサービスに関して、図４〜図５に示される、この「中継」方法の実施形態は、図２〜図３に示される間接方法の実施形態とは異なる、ＭＳＲＢとの対話をもたらす。この中継方法は、ＭＳリソースが、アイドルに戻されることが可能であることが、コールのクリアを観察することから推測されることが可能である場合に、ＭＳＲＢがそのことをより迅速に判定することを可能にし、間接方法と比べて、ＡＳとＭＳＲＢの間で、より少ない工程が関与する。しかし、この中継方法は、前述したとおり、ＡＳが行使することができるコントロールの大きさに関して、間接方法と比べてより限定的であることが可能である。

図６および図７は、間接方法および中継方法のさらなる図をそれぞれ提供する。理解することができるように、両方の方法は、いくつかの利点を有する。

最初に図６を見ると、工程６１０で、ＡＳがＭＳリソースを要求する。或る実施形態では、要求は、Ｘ個のポートを含む会議コールを開始することであることが可能である。工程６１５で、ＣＣＥが、その要求をＭＳＲＢ（前述したとおり、単一の論理データベースを共有する１つまたは複数の物理サーバであることが可能な）に転送する。工程６２０で、ＭＳＲＢが、ＭＳロケーションを決定する。この決定には、伝送遅延を最小限に抑えるように、地理的構成要素が含まれることが可能である。工程６２５で、ＭＳＲＢが、ＣＣＥを介してＡＳに、ＭＳのアドレスとともに２００ＯＫ信号を送信する。

工程６３０で、ＣＣＥが、ＡＳの要求で、ＭＳと様々な電話機との間のコールレグをセットアップする。工程６３５で、ＡＳとＭＳの間に制御レグがセットアップされる。制御レグは、ＡＳが話者のレグ音声入力を除いてすべてをミュートすること、またはすべての会議レグに告知を再生すること、または補助的な会議を作成すること、またはＮ個の最大音量のレグからの入力をミキシングすることなどの命令を、ＭＳに与えることを可能にする。さらに、予約されたすべてのポートが使用されている場合、ＡＳは、さらなるポートを要求することができる。これは、通常は問題ではない。というのは、要求はしばしば安全ファクタをもたらすように、いくつかの追加のポートを含むことが可能であるからである。ポートが足りなくなるのをさらに防止するのに、要求されたポート数の或るパーセンテージが、コール期間にわたって暫定的に割り当てられることが可能であり、それらのポートが必要とされていないとＡＳが判定すると、それらのポートが、他の使用のために解放されることが可能である。コールへの、予期されるより高い参加レベルに対する緩衝として作用する余分なポートが、提供される場合、それらのポートは、複数のコールで共有されることが可能であることに留意されたい。

工程６４０で、コールは、終了する。これは、最終コールレグの終了によって決定されることが可能である。工程６４０でコールが終了すると、工程６４５で、リソースが割り当て解除されることが可能であることを、ＡＳが、ＭＳＲＢに信号通知する。或る実施形態では、信号は、ＢＹＥメッセージであることが可能である。工程６５０で、前に割り当てられたＭＳリソースが、アイドルプールに戻される。

次に、図７を参照すると、やはり、会議コールシナリオを想定する、中継方法の高レベルの図が示されている。工程７０５で、会議に関する第１のコールレグが、ネットワークに入ってくると、ＡＳは、ＡＳが、ＭＳに、そのコールレグが確立されることを要求するのと同一のメッセージの中で、ＭＳリソースを要求する。要求は、必要とされるＭＳリソースのタイプ、および必要とされるポートの数を含まなければならない。また、要求は、発呼者の地理的区域、および、分かっている場合、コールの見込まれる時間についての情報も含むことが可能である。図示される実施形態では、要求は、ＣＣＥに送信されるＩＮＶＩＴＥメッセージの形態になっている。工程７１０で、ＣＣＥが、同一の要求情報を有するＩＮＶＩＴＥメッセージをＭＳＲＢに送信する。工程７１５で、ＭＳＲＢが、適切なＭＳのロケーションを特定し、ＭＳの割り当てが、最新に保たれるように、ＭＳＲＢデータベースの中で割り当てを追跡する。

次に、工程７２０で、ＭＳＲＢが、コールレグを作成するよう、ＭＳにＩＮＶＩＴＥメッセージを送信する。理解することができるように、ＭＳには、より少ない情報が与えられることが可能である。というのは、ＭＳは、他のＭＳと比べた、そのＭＳの利用可能性を判定する必要がないからである。工程７２５で、ＭＳが、コールの受け付けを示す、コールセットアップ要求への応答メッセージ（例えば、２００ＯＫ）を送信することにより、ＭＳＲＢに応答する。工程７３０で、ＭＳＲＢは、その情報をＣＣＥに提供して、発呼者が、ＭＳに接続されることが可能であるようにする。信号通知パスは、ＣＣＥに向かう途中でＡＳを通り、このため、電話機からＭＳに至る信号通知パスは、ＢＥからＣＣＥを通り、ＡＳを通り、ＣＣＥを通り、ＭＳＲＢを通り、ＭＳに至ることに留意されたい。

工程７４０で、ＭＳが、スクリプト、および必要とされるファイルをＡＳから取得する。スクリプトは、ＶＸＭＬフォーマットになっていることが可能であり、取得は、ＨＴＴＰ、または他の何らかの適切なプロトコルを介して達せられることが可能である。工程７４５で、発呼者とＭＳが対話する。ＭＳと電話機の間のリンク２８０（図４）上で行われるメディア対話は、既知の仕方でオーディオストリームを伝送するための、ＲＴＰなどの任意の適切なプロトコルを使用することが可能である。

対話が完了すると、工程７５０で、ＡＳが、ＭＳおよび発呼者に向けてのコールをクリアする。工程７５５で、ＭＳＲＢが、コールのクリアを観察し、ＭＳリソースをアイドルプールに戻す。理解することができるように、ＭＳＲＢは、コールをクリアするための信号通知パスにあるため、ポートが、もはや使用されていないことが、コールレグのクリアから推測されることが可能である場合、そのことの迅速な通知を受信する。しかし、大規模な会議コールの場合、ＭＳＲＢが、各コールレグの信号通知パスにあるという事実は、ＭＳＲＢの作業負荷を増大させるきらいがある可能性がある。

したがって、間接方法は、ポートが、どのように使用されているかを、ＡＳが、より大幅にコントロールすることを可能にし、例えば、大規模な会議コールを扱うために、好ましい可能性がある。しかし、中継方法は、各コールレグのステータスに関する、より迅速な更新をもたらすことができ、ＩＶＲタイプのコールを扱うために、好ましい可能性がある。しかし、いずれの方法も、特定のタイプのコールには限定されないことに留意されたい。

本発明を、本発明の好ましい実施形態、および例示的な実施形態に関連して説明してきた。添付の特許請求の範囲および趣旨に含まれる、他の多数の実施形態、変形形態、および変更形態が、本開示を精読することで、当業者には想起されよう。

本発明の或る態様によるＶｏＩＰを配信する際に使用するためのシステムの実施形態を示す概略図である。本発明の或る態様による間接方法を使用してＶｏＩＰを配信する際に使用するためのシステムの実施形態を示す概略図である。本発明の或る態様による図２に示されるシステムを使用する方法の実施形態を示す図である。本発明の或る態様による中継方法を使用してＶｏＩＰを配信する際に使用するためのシステムの実施形態を示す概略図である。本発明の或る態様による図４に示されるシステムを使用する方法の実施形態を示す図である。本発明の或る態様による間接方法の実施形態を示す図である。本発明の或る態様による中継方法の実施形態を示す図である。本発明の或る態様による分散されたメディア・サーバ・セットの概略の実施形態を示す図である。

Claims

ＩＰノード（２１０）にサービスを提供する方法であって、
（ａ）アプリケーションサーバ（１２０）において前記ＩＰノードからサービス要求を受信すること、
（ｂ）前記サービス要求に応答して、メディアサーバリソースを求める要求を、前記アプリケーションサーバ（１２０）からメディアサーバリソースを求める前記要求を受信したコール制御要素（１３０）からメディアサーバリソースブローカ（１４０）へ転送することを含み、前記メディアサーバリソースブローカ（１４０）は前記アプリケーションサーバ（１２０）の外部にあり、さらに、
（ｃ）前記メディアサーバリソースブローカを使用して、第１のメディアサーバ（１６０）の選択を前記アプリケーションサーバに提供し、前記メディアサーバリソースブローカは、メディアサーバセットからの前記第１のメディアサーバを、メディアサーバリソースを求める前記要求、および前記メディアサーバリソースブローカ（１４０）によって決定された前記メディアサーバセットの中のメディアサーバの各々の利用と関係する１つまたは複数のパラメータに応答して、選択すること、
（ｄ）前記ＩＰノードと前記第１のメディアサーバの間でコールを確立すること、ならびに
（ｅ）前記アプリケーションサーバから前記第１のメディアサーバに前記コールを管理するための命令を提供することを含む方法。
前記メディアサーバセットは、別々の地理的区域におけるメディアサーバを含む請求項１に記載の方法。
（ａ）における前記サービス要求は、セッション開始プロトコル、Ｈ．３２３、メディアゲートウェイ制御プロトコル、スキニークライアント制御プロトコル、ＭｉＮｅｔ、ＣｏｒＮｅｔ−ＩＰ、Ｉｎｔｅｒ−ＡｓｔｅｒｉｓｋｅＸｃｈａｎｇｅプロトコル、Ｓｋｙｐｅ、およびＪａｊａｈから成るリストから選択されるプロトコルで提供される請求項１に記載の方法。
（ｂ）における前記要求することは、ハイパーテキストトランスポートプロトコルを使用して、前記アプリケーションサーバから前記メディアサーバリソースブローカに直接に行われる請求項１に記載の方法。
（ｂ）における前記要求することは、
（ｉ）コール制御要素にＩＮＶＩＴＥメッセージを送信すること、および
（ｉｉ）前記コール制御要素から前記メディアサーバリソースブローカに第２のＩＮＶＩＴＥメッセージを送信することを含む請求項１に記載の方法。
（ｂ）における前記要求することは、メディアサーバ使用の性質、必要とされるポートの数、顧客が契約したサービスのタイプ、必要とされるポートの特性、ポート使用の時間、会議コール識別、メディアサーバのロケーションの地理的選好、および使用されるべき制御プロトコルの選好から成るリストから選択される１つまたは複数の属性を含む請求項１に記載の方法。
（ｃ）における前記１つまたは複数のパラメータの１つは、前記セットの中の各メディアサーバの能力、前記セットの中の各メディアサーバにおいて利用可能なポートの数、前記セットの中の各メディアサーバの地理的ロケーション、前記セットの中の各メディアサーバの現在の利用、前記セットの中の各メディアサーバのスケジュールされた利用から成るリストから選択される請求項１に記載の方法。
（ｅ）における前記コールを前記確立することは、リアルタイムトランスポートプロトコルを使用する請求項１に記載の方法。
前記第１のメディアサーバは、複数のメディアサーバを含む請求項１に記載の方法。
（ｅ）における命令を前記提供することは、
（ｉ）メディアセッションマークアップ言語、メディアオブジェクトマークアップ言語、メディアサーバ制御マークアップ言語、音声拡張マークアップ言語、コール制御拡張マークアップ言語、およびメディアリソース制御プロトコルから成るリストから選択される言語を使用して、コマンドを送信することを含む請求項１に記載の方法。
（ｃ）における前記選択することは、
（ｉ）前記第１のメディアサーバが、前記要求されたメディアサーバリソースを提供すべきことを、前記メディアサーバセットの中のメディアサーバのそれぞれにおいて、前記要求されたメディアサーバリソースを提供するのに適した利用可能なポートの数に基づいて、判定することを含む請求項１に記載の方法。
メディアサーバセットの利用を制御する方法であって、
（ａ）メディアサーバリソースを求める要求を、アプリケーションサーバ（１２０）から前記要求を受信したコール制御要素（１３０）からメディアサーバリソースブローカ（１４０）において受信することを含み、前記メディアサーバリソースブローカ（１４０）は前記アプリケーションサーバ（１２０）の外部にあり、さらに、
（ｂ）前記メディアサーバセットの中の各メディアサーバに関して、前記要求されたメディアサーバリソースの利用可能性を判定すること、
（ｃ）選択された第１のメディアサーバ（１６０）のアドレスを提供し、前記メディアサーバリソースブローカは、前記判定された利用可能性に基づき、前記メディアサーバセットから前記第１のメディアサーバを選択すること、および
（ｄ）前記メディアサーバリソースを求める前記要求に基づく、前記第１のメディアサーバの割り当てレベルの変化を追跡することを含む方法。
（ａ）における前記要求は、メディアサーバ使用の性質、必要とされるポートの数、顧客が契約したサービスのタイプ、必要とされるポートの特性、ポート使用の時間、会議コール識別、メディアサーバのロケーションの地理的選好、および使用されるべき制御プロトコルの選好から成るリストから選択される１つまたは複数の属性を含む請求項１２に記載の方法。
前記メディアサーバリソースブローカは、データベースモジュールに結合された少なくとも１つのサーバを含み、（ｄ）における前記追跡することは、
（ｉ）前記データベースモジュールの中に格納された前記第１のメディアサーバの前記割り当てレベルのレコードを更新することを含む請求項１２に記載の方法。
前記メディアサーバセットは、異なる地域に位置する複数のメディアサーバを含む請求項１２に記載の方法。
（ｂ）における利用可能性を前記判定することは、
（ｉ）要求されたポートの数およびタイプを、前記メディアサーバセットの中の各メディアサーバにおいて利用可能なポートの数およびタイプと比較すること、ならびに
（ｉｉ）前記要求された量およびタイプを満たす十分なポートを提供することができるメディアサーバに関して、前記要求された数のポートを提供した後に、最大レベルの予備のポートが利用可能であるメディアサーバとして、前記第１のメディアサーバを選択することを含む請求項１２に記載の方法。
（ｅ）前記メディアサーバの利用レベルに関する更新を受信し、前記更新は、メディアサーバ（１６）およびオペレーションサポートシステム（１７０）から成るリストから選択されるモジュールから来ることをさらに含む請求項１２に記載の方法。
前記利用レベルの前記更新は、計画されたダウン時間、計画外のダウン時間、装置追加、装置削除、サービスごとの予約、会議ごとの予約、およびメディアサーバ利用ステータスから成るリストから選択される少なくとも１つのファクタを含む請求項１７に記載の方法。
（ｅ）将来のメディアサーバリソースを求める要求を前記メディアサーバリソースブローカから受信すること、および
（ｆ）将来のメディアサーバリソースを求める前記要求に関連する計画された割り当てをデータベースモジュール（１５０）の中に格納することをさらに含み、（ｂ）における前記メディアサーバセットの中のメディアサーバの利用可能性を前記判定することは、前記計画された割り当てを含む請求項１２に記載の方法。
ネットワークを介してテレビ会議コールレグを処理する方法であって、
（ａ）第１のコール発信デバイス（２１０）に関連する境界要素（２１５）から受信された着信コール要求に基づき、アプリケーションサーバ（１２０）に、前記アプリケーションサーバによって制御される会議に接続されるべき第１の要求を提供すること、
（ｂ）前記第１の要求に応答して、メディアサーバリソースを求める第１のリソース要求を、前記アプリケーションサーバ（１２０）からメディアサーバリソースを求める前記第１のリソース要求を受信したコール制御要素（１３０）からメディアサーバリソースブローカ（１４０）へ転送することを含み、前記メディアサーバリソースブローカ（１４０）は前記アプリケーションサーバ（１２０）の外部にあり、さらに、
（ｃ）前記メディアサーバリソースブローカから、前記ネットワーク上の第１のメディアサーバ（１６０）のアドレスを受信すること、および
（ｄ）前記第１のコール発信デバイスと前記第１のメディアサーバの間で第１のコールレグを確立することを含む方法。
（ｃ）における前記受信することは、
（ｉ）前記メディアサーバリソースブローカを使用して、前記第１のメディアサーバが、前記要求を扱うのに利用可能であることを判定すること、および
（ｉｉ）前記第１のメディアサーバのアドレスを提供することを含む請求項２０に記載の方法。
（ｂ）における前記提供することは、
（ｉ）メディアサーバリソースを求める要求をアプリケーションサーバから受信すること、および
（ｉｉ）前記要求を前記メディアサーバリソースブローカに提供することを含み、前記要求は、要求されるポートの数、および地理的ロケーションの選好を含む請求項２０に記載の方法。
（ｅ）前記会議コールをサポートするのに必要とされるリソースのパラメータを変更する第２のリソース要求を前記メディアサーバリソースブローカに提供することをさらに含む請求項２０に記載の方法。
（ｅ）前記アプリケーションサーバにおいて、第２のコール発信デバイス（２１２）からの、前記会議コールに接続されるべき第２の要求を受信すること、および
（ｆ）前記第１のメディアサーバと前記第２のコール発信デバイスの間で、前記メディアサーバリソースブローカに問い合わせることなしに確立される第２のコールレグを確立することをさらに含む請求項２０に記載の方法。
ＩＰノード（２１０）にサービスを提供する方法であって、
（ａ）アプリケーションサーバ（１２０）において前記ＩＰノードからサービス要求を受信すること、
（ｂ）前記サービス要求に応答して、メディアサーバリソースを求める要求を、前記アプリケーションサーバ（１２０）からメディアサーバリソースを求める前記要求を受信したコール制御要素（１３０）からメディアサーバリソースブローカ（１４０）へ転送することを含み、前記メディアサーバリソースブローカ（１４０）は前記アプリケーションサーバ（１２０）の外部にあり、さらに、
（ｃ）前記メディアサービスリソースブローカを使用して、第１のメディアサーバ（１６０）が、前記サービス要求を満たすのに利用可能であると判定し、前記第１のメディアサーバは、メディアサーバセットから、メディアサーバリソースを求める前記要求、および前記メディアサーバセットの中のメディアサーバの利用と関係する１つまたは複数のパラメータに応答して選択されること、
（ｄ）前記メディアサーバリソースブローカを介して、前記第１のメディアサーバを前記ＩＰノードと接続し、前記接続は、前記第１のメディアサーバと前記ＩＰノードの間でコールを確立する際に使用するためのＩＰアドレスおよびポート番号を提供すること、
（ｅ）前記ＩＰノードと前記第１のメディアサーバの間でコールを確立すること、ならびに
（ｆ）前記アプリケーションサーバから前記第１のメディアサーバに前記コールを管理するための命令を提供することを含む方法。
前記メディアサーバセットは、別々の地理的区域に位置するメディアサーバを含む請求項２５に記載の方法。
（ａ）における前記サービス要求は、セッション開始プロトコル、Ｈ．３２３、メディアゲートウェイ制御プロトコル、スキニークライアント制御プロトコル、ＭｉＮｅｔ、ＣｏｒＮｅｔ−ＩＰ、Ｉｎｔｅｒ−ＡｓｔｅｒｉｓｋｅＸｃｈａｎｇｅプロトコル、Ｓｋｙｐｅ、およびＪａｊａｈから成るリストから選択されるプロトコルで提供される請求項２５に記載の方法。
（ｂ）における前記要求することは、ハイパーテキストトランスポートプロトコルを使用して、前記アプリケーションサーバから前記メディアサーバリソースブローカに直接に行われる請求項２５に記載の方法。
（ｂ）における前記要求することは、
（ｉ）コール制御要素（１３０）にＩＮＶＩＴＥメッセージを送信すること、および
（ｉｉ）前記コール制御要素から前記メディアサーバリソースブローカに第２のＩＮＶＩＴＥメッセージを送信することを含む請求項２５に記載の方法。
（ｂ）における前記要求することは、メディアサーバ使用の性質、必要とされるポートの数、顧客が契約したサービスのタイプ、必要とされるポートの特性、ポート使用の時間、会議コール識別、メディアサーバのロケーションの地理的選好、および使用されるべき制御プロトコルの選好から成るリストから選択される１つまたは複数の属性を含む請求項２５に記載の方法。
（ｃ）における前記１つまたは複数のパラメータの１つは、前記セットの中の各メディアサーバの能力、前記セットの中の各メディアサーバにおいて利用可能なポートの数、前記セットの中の各メディアサーバの地理的ロケーション、前記セットの中の各メディアサーバの現在の利用、前記セットの中の各メディアサーバのスケジュールされた利用から成るリストから選択される請求項２５に記載の方法。
（ｅ）における前記コールを前記確立することは、リアルタイムトランスポートプロトコルを使用する請求項２５に記載の方法。
前記第１のメディアサーバは、複数のメディアサーバを含む請求項２５に記載の方法。
（ｆ）における命令を前記提供することは、
（ｉ）メディアセッションマークアップ言語、メディアオブジェクトマークアップ言語、メディアサーバ制御マークアップ言語、音声拡張マークアップ言語、コール制御拡張マークアップ言語、およびメディアリソース制御プロトコルから成るリストから選択される言語を使用して、コマンドを送信することを含む請求項２５に記載の方法。
（ｃ）における前記判定することは、前記メディアサーバセットの中のメディアサーバのそれぞれにおいて、前記要求されたメディアサーバリソースを提供するのに適した利用可能なポートの数に基づく請求項２５に記載の方法。
メディアサーバセットの利用を制御する方法であって、
（ａ）メディアサーバリソースを求める要求を、アプリケーションサーバ（１２０）から前記要求を受信したコール制御要素（１３０）からメディアサーバリソースブローカ（１４０）において受信することを含み、前記メディアサーバリソースブローカ（１４０）は前記アプリケーションサーバ（１２０）の外部にあり、さらに、
（ｂ）前記メディアサーバセットの中の各メディアサーバ（１６０）に関して、前記要求されたメディアサーバリソースの利用可能性を判定すること、
（ｃ）前記第１のメディアサーバのＩＰアドレスおよびポート番号をＩＰノード（２１０）に提供すること、ならびに
（ｄ）前記メディアサーバリソースを求める前記要求に基づく、前記第１のメディアサーバの割り当てレベルの変化を追跡することを含む方法。
（ａ）における前記要求は、セッション開始プロトコルで提供される請求項３６に記載の方法。
（ａ）における前記要求は、メディアサーバ使用の性質、必要とされるポートの数、顧客が契約したサービスのタイプ、必要とされるポートの特性、ポート使用の時間、会議コール識別、メディアサーバのロケーションの地理的選好、および使用されるべき制御プロトコルの選好から成るリストから選択される１つまたは複数の属性を含む請求項３６に記載の方法。
前記メディアサーバリソースブローカは、データベースモジュールに結合された少なくとも１つのサーバを含み、（ｄ）における前記追跡することは、
（ｉ）前記データベースモジュールの中に格納された前記第１のメディアサーバの前記割り当てレベルのレコードを更新することを含む請求項３６に記載の方法。
前記メディアサーバセットは、異なる地域に位置する複数のメディアサーバを含む請求項３６に記載の方法。
（ｂ）における利用可能性を前記判定することは、
（ｉ）要求されたポートの数およびタイプを、前記メディアサーバセットの中の各メディアサーバにおいて利用可能なポートの数およびタイプと比較すること、ならびに
（ｉｉ）前記要求された量およびタイプを満たす十分なポートを提供することができるメディアサーバに関して、前記要求された数のポートを提供した後に、最大レベルの予備のポートが利用可能であるメディアサーバとして、前記第１のメディアサーバを選択することを含む請求項３６に記載の方法。
（ｅ）前記メディアサーバの利用レベルに関する更新を受信し、前記更新は、メディアサーバ（１６０）およびオペレーションサポートシステム（１７０）から成るリストから選択されるモジュールから来ることをさらに含む請求項３６に記載の方法。
前記利用レベルの前記更新は、計画されたダウン時間、計画外のダウン時間、装置追加、装置削除、サービスごとの予約、会議ごとの予約、およびメディアサーバ利用ステータスから成るリストから選択される少なくとも１つのファクタを含む請求項４２に記載の方法。
（ｅ）将来のメディアサーバリソースを求める要求を前記メディアサーバリソースブローカから受信すること、および
（ｆ）前記要求の計画された利用をデータベースモジュール（１５０）の中に格納することをさらに含み、（ｂ）における利用可能性を前記判定することは、前記計画された利用を含む請求項３６に記載の方法。
ＶｏＩＰネットワークを介して対話型音声応答コールを処理する方法であって、
（ａ）ＶｏＩＰ電話機（２１０）に関連する境界要素（２１５）から受信されるサービス要求をアプリケーションサーバ（１２０）に提供すること、
（ｂ）メディアサーバリソースを求める要求を、前記アプリケーションサーバ（１２０）からメディアサーバリソースを求める前記要求を受信したコール制御要素（１３０）からメディアサーバリソースブローカ（１４０）に転送することを含み、前記メディアサーバリソースブローカ（１４０）は前記アプリケーションサーバ（１２０）の外部にあり、さらに、
（ｃ）前記ＶｏＩＰネットワーク上の第１のメディアサーバ（１６０）のＩＰアドレスを特定すること、
（ｄ）前記メディアサーバリソースブローカを使用して、前記第１のメディアサーバに問い合わせて、ＩＰアドレスおよびポート番号を特定すること、
（ｅ）前記メディアサーバリソースブローカを介して前記第１のメディアサーバを前記境界要素に接続すること、ならびに
（ｆ）前記ＶｏＩＰ電話機と前記第１のメディアサーバの間でコールを確立することを含む方法。
（ｃ）における前記判定することは、および
（ｉ）メディアサーバリソースを求める前記要求をメディアサーバセットの利用可能性と比較すること、および
（ｉｉ）前記メディアサーバセットからの前記第１のメディアサーバを選択して、前記メディアサーバリソースを提供することを含む請求項４５に記載の方法。
（ｉｉ）における前記選択することは、
（１）前記第１のメディアサーバが、前記メディアサーバセットの中の、その他のメディアサーバよりも低い割り当てレベルを有すると判定することを含む請求項４６に記載の方法。
（ｆ）における前記コールを前記確立することは、リアルタイムトランスポートプロトコルを使用する請求項４５に記載の方法。