(57)【要約】  高度に大きさの変更が可能で、信頼できるＩＰベースの通信を記録するソフトウェアのソリューションである。記録は、自動的に行われるか、そうする権利が与えられているユーザーからの要請によって引き起こされるように構成されている。要請による記録を開始するユーザーは、コールへの参加者である必要はない。ソリューションは、２つのサーバー構成要素、コールマネージャーおよびメディアサーバーに基づく。コールマネージャーは、メディアサーバーを介して２つのエンドポイント間のＩＰメディアの流れを再経路付けする責任がある。メディアサーバーは、記録として蓄積されているコピーを捕捉しながら、ＩＰメディアパケットを中継する。記録は、ネットワークシェアに蓄積されて標準ネットワークファイル安全機構を用いて守られる。再生記録にアクセスするには、管理者を介して構成されている権利が必要である。記録の再生は、電話、クライアントの申請またはウェブサービスを介して達成できる。
2009527200.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、そのネットワークは、複数のエンドユーザーおよびそれらエンドユーザーを接続するのに用いられる少なくとも１つのメディアサーバーを含み、前記少なくとも１つのメディアサーバーは、ソフトウェアアプリケーションを蓄積するメモリーを有し、前記少なくとも１つのメディアサーバーは、前記メモリーに蓄積されるプロトコルスタックを備え、前記方法は、
（ａ）エンドユーザー間のデータの流れを、前記少なくとも１つのメディアサーバーの中間実時間プロトコルドライバーインターフェースに仕向け、かつその実時間のデータの流れを、前記プロトコルスタックの上位レベルプロトコルアダプターに送り、
（ｂ）その実時間のデータの流れを、その上位レベルのプロトコルアダプターから少なくとも１つのメディアサーバーのメモリーに蓄積されるコールマネージャーソフトウェアプログラムに送り、
（ｃ）そのコールマネージャーソフトウェアプログラムを用いて、前記少なくとも１つのメディアサーバーのメモリーに前記（ｂ）のデータの流れを蓄積し、
（ｄ）そのコールマネージャーソフトウェアプログラムを用いて、データの流れを複製し、
（ｅ）そのデータの流れを、指定されたエンドポイントへと仕向け直すためのコールマネージャーソフトウェアプログラムを介して、ソースおよび行先ＩＰアドレスおよび前記データの流れのポートを、その中間実時間プロトコルドライバーインターフェースの宛先変更テーブルに書き換え、
（ｆ）前記ステップ（ｄ）で複製されたデータの流れを、前記ステップ（ｅ）の前記宛先変更テーブルのアドレスおよびポートへと送信する
ステップを備えている方法。
【請求項２】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、前記ＩＰパケットベースのデータネットワークは、複数のメディアサーバーを備え、前記方法はさらに、
（ｇ）前記１つのメディアサーバーが前記データの流れを取り扱うことができないときに、エンドユーザー間のデータの流れを、別のメディアサーバーの中間実時間プロトコルドライバーインターフェースに仕向ける
ステップをさらに備えている請求項１に記載の方法。
【請求項３】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、前記方法はさらに、
（ｇ）前記少なくとも１つのメディアサーバーがデータの流れを取り扱うことができないときに、エンドユーザー間のデータの流れを、異なるＩＰベースのパケットデータネットワークの前記メディアサーバーの中間実時間プロトコルドライバーインターフェースに仕向ける
ステップをさらに備えている請求項１に記載の方法。
【請求項４】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、前記ステップ（ａ）の前記データの流れは、エンドユーザーの双方向のメディアの流れであり、前記ステップ（ｃ）は、コールの双方のソースの単一の記録を提供する前記双方向のメディアの流れの２つの流れを加算するステップを備えている請求項１に記載の方法。
【請求項５】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、前記ステップ（ｃ）は、前記双方向のメディアの流れの情報をコール詳細記録への延長として蓄積するステップを備えており、
前記方法はさらに、コール詳細記録の属性によって前記双方向のメディアの流れの蓄えられた情報を検索するステップを備えている
請求項１に記載の方法。
【請求項６】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、コール詳細記録の属性を検索する前記ステップは、以下の属性、すなわち、コーラーＩＤ、自動番号ＩＤおよびダイヤルされた番号ＩＤサービスの少なくとも１つを検索するステップを備えている請求項５に記載の方法。
【請求項７】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、前記（ｅ）が、以下のパラメータ、すなわち、ＬｉｓｔｅｎＰｏｒｔ、ＳｅｎｄＰｏｒｔ、ＲｅｄｉｒｅｃｔＰｏｒｔおよびＲｅｄｉｒｅｃｔＩＰＡｄｄｒを有する宛先変更テーブルを用いて、ソースおよび行先ＩＰアドレスおよびポートを書き換えるステップを備えている請求項１に記載の方法。
【請求項８】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、前記（ｅ）が、さらにＲｅｄｉｒｅｃｔＭＡＣＡｄｄｒという追加のパラメータを有する宛先変更テーブルを用いて、ソースおよび行先ＩＰアドレスおよびポートを書き換えるステップを備えている請求項７に記載の方法。
【請求項９】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、前記データの流れが、少なくともオーディオパケットデータの流れおよびビデオパケットデータの流れのいずれか一方である請求項１に記載の方法。
【請求項１０】
ＩＰパケットベースのデータネットワークにおいてコールを記録する方法であって、前記実時間プロトコルドライバーインターフェースが、ＲＴＰブリッジデバイスドライバーを備えている請求項１に記載の方法。
【請求項１１】
ＩＰパケットベースのデータネットワークにおいて、そのネットワークには、複数のエンドユーザーと、データの流れの送信についてエンドユーザーを接続するのに用いられる少なくとも１つのメディアサーバーとが含まれており、前記少なくとも１つのメディアサーバーは、ソフトウェアのアプリケーションを蓄積するメモリーを有し、前記少なくとも１つのメディアサーバーは、前記メモリーに蓄積されるプロトコルのスタック手段を備えており、改善によって備えられる：
前記プロトコルのスタック手段は、エンドユーザー間のデータの流れが送られる第一の中間実時間プロトコルドライバーインターフェース手段と、第二の上位レベルプロトコルアダプター手段と、第三のマネージャーソフトウェアプログラム手段とを備えており、実時間のデータの流れを、前記中間実時間プロトコルドライバーインターフェース手段と前記上位レベルプロトコルアダプター手段とを介して前記第三のマネージャーソフトウェアプログラム手段に送り、
前記第三のマネージャーソフトウェアプログラム手段は、前記データの流れを前記少なくとも１つのメディアサーバーの前記メモリーに蓄積する蓄積手段を備えており、
前記第三のマネージャーソフトウェアプログラム手段はまた、データの流れを引き続いて再送する前記第一の中間実時間プロトコルドライバーインターフェース手段によって、そこに送られてくる前記データの流れを複製する複製手段を備えており、
前記第三のマネージャーソフトウェアプログラム手段はさらに、ソースおよび行先ＩＰアドレスと前記データの流れのポートとを書き換える書き換え手段と、前記書き換え手段から受け取られるソースおよび行先ＩＰアドレスと前記データの流れのポートとからなる宛先変更テーブルとを備えており、前記宛先変更テーブルは、データの流れを、それらの指定されたエンドポイントへと向け直す前記中間実時間プロトコルドライバーインターフェース手段にあり、
前記第一の中間実時間プロトコルドライバーインターフェース手段は、複製されたデータの流れを前記宛先変更テーブルのアドレスおよびポートに送信する
ＩＰパケットベースのネットワーク。
【請求項１２】
さらに、各々が前記第三のマネージャーソフトウェアプログラム手段を有する複数のメディアサーバーを備えていて、前記メディアサーバーの各々の前記第三のマネージャーソフトウェアプログラム手段の各々は、前記１つのメディアサーバーがデータの流れを取り扱うことができないとき、エンドユーザー間のデータの流れを、前記別のメディアサーバーの前記中間実時間プロトコルドライバーインターフェース手段に転送する転送手段を備えている請求項１１に記載のＩＰパケットベースのデータネットワーク。
【請求項１３】
前記第三のマネージャーソフトウェアプログラム手段が、エンドユーザー間のデータの流れを、前記少なくとも１つのメディアサーバーがデータの流れを取り扱うことができないときに、異なるＩＰベースのパケットデータネットワークの前記メディアサーバーの中間実時間プロトコルドライバーインターフェースに転送する転送手段を備えている請求項１１に記載のＩＰパケットベースのデータネットワーク。
【請求項１４】
前記データの流れが、エンドユーザーの双方向メディアの流れであり、前記第三のマネージャーソフトウェアプログラム手段が、前記蓄積手段によるコールの双方のソースを唯一記録する前記双方向メディアの流れの２つの流れを加算する加算手段を備えている請求項１１に記載のＩＰパケットベースのデータネットワーク。
【請求項１５】
前記蓄積手段は、前記双方向メディアの流れの情報を蓄積する手段をコール詳細記録への内線として蓄積する手段を備え、
前記第三のマネージャーソフトウェアプログラム手段はさらに、コール詳細記録の属性によって前記双方向メディアの流れの蓄積された情報を検索する検索手段を備えている
請求項１１に記載のＩＰパケットベースのデータネットワーク。
【請求項１６】
前記検索する手段は、前記双方向のメディアの流れの前記蓄積された情報を検索して、以下の属性、すなわち、コーラーＩＤ、自働番号識別およびダイヤルされた番号の識別サービスの少なくとも１つを求める請求項１５に記載のＩＰパケットベースのデータネットワーク。
【請求項１７】
前記宛先変更テーブルは、以下のパラメータ、すなわち、ＬｉｓｔｅｎＰｏｒｔ、ＳｅｎｄＰｏｒｔ、ＲｅｄｉｒｅｃｔＰｏｒｔおよびＲｅｄｉｒｅｃｔＩＰＡｄｄｒを備えている請求項１５に記載のＩＰパケットベースのデータネットワーク。
【請求項１８】
ＩＰパケットベースのデータネットワークの一部を構成するメディアサーバーにおいて、そのネットワークには複数のエンドユーザーが含まれており、そのメディアサーバーは、エンドユーザー間のデータの流れを接続するのに用いられており、前記少なくとも１つのメディアサーバーは、ソフトウェアのアプリケーションを蓄積するメモリーおよび前記メモリーに蓄積されるプロトコルスタック手段を有し、改善によって備えられる
前記プロトコルスタック手段は、エンドユーザー間のデータの流れが送られる第一の中間実時間プロトコルドライバーインターフェース手段と、第二の上位レベルプロトコルアダプター手段と、第三のマネージャーソフトウェアプログラム手段とを備えており、前記中間実時間プロトコルドライバーインターフェース手段および前記上位レベルプロトコルアダプター手段を介して、前記第三のマネージャーソフトウェアプログラム手段に実時間データの流れを送り、
前記第三のマネージャーソフトウェアプログラム手段は、前記データの流れを前記メモリーに蓄積する蓄積手段を備え、
前記第三のマネージャーソフトウェアプログラム手段はまた、データの流れを引き続いて再送する前記第一の中間実時間プロトコルドライバーインターフェース手段によって、そこに送られてくる前記データの流れを複製する複製手段を備えており、
前記第三のマネージャーソフトウェアプログラム手段はさらに、ソースおよび行先ＩＰアドレスと前記データの流れのポートとを書き換える書き換え手段と、前記書き換え手段から受け取られるソースおよび行先ＩＰアドレスと前記データの流れのポートとからなる宛先変更テーブルとを備えており、前記宛先変更テーブルは、データの流れをそれらの指定されたエンドポイントへと向け直す前記中間実時間プロトコルドライバーインターフェース手段にあり、
前記第一の中間実時間プロトコルドライバーインターフェース手段は、複製されたデータの流れを前記宛先変更テーブルのアドレスおよびポートに送信する
メディアサーバー。
【請求項１９】
前記データの流れは、エンドユーザーの双方向メディアの流れであり、前記第三のマネージャーソフトウェアプログラム手段は、前記蓄積手段によるコールの双方のソースの単一の記録を提供する前記双方向メディアの流れの２つの流れを加算する加算手段を備えており、前記蓄積手段は、前記双方向のメディアの流れの情報をコール詳細記録への内線として蓄積する手段を備えており、前記第三のマネージャーソフトウェアプログラム手段はさらに、コール詳細記録の属性によって前記双方向メディアの流れの蓄積された情報を検索する検索手段を備えている請求項１８に記載のメディアサーバー。
【請求項２０】
前記宛先変更テーブルは、以下のパラメータ、すなわち、ＬｉｓｔｅｎＰｏｒｔ、ＳｅｎｄＰｏｒｔ、ＲｅｄｉｒｅｃｔＰｏｒｔおよびＲｅｄｉｒｅｃｔＩＰＡｄｄｒを備えている請求項１８に記載のメディアサーバー。
【発明の詳細な説明】
【背景技術】
【０００１】
（発明の背景）
電話コールの記録は、従来、音声回路に導入されている少なくとも何らかのハードウェアデバイスを用いることによって達成されている。最新世代のパケット傍受コール記録製品でさえ、ポートミラーリングを行うことができるイーサネット（登録商標）スイッチという形の特定のハードウェアが必要である。電話コールを記録するハードウェアを組み入れている従来技術のシステムの例が、米国特許５，３９２，３２９号、５，９２３，７４６号、６，２４９，５７０号、６，６６５，３７６号および６，７２８，３４５号に開示されている。本発明は、電話コールを記録する、純粋にソフトウェアの方法およびシステムに向けられている。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
（発明の概要）
本発明は、ＩＰパケットベースのシステムにおける電話コールを記録する、純粋にソフトウェアのソリューションに向けられている。このソフトウェアのソリューションは、基本的なＰＣで作動し、それ専用の特別なハードウェアを有さない。さらには、発明の記録ソフトウェアは、ＩＰ通信システム全体について、サーバーが提供するコール制御で共同使用されている。発明のこの分散型ソフトウェアのソリューションの利点は、さらなる記録能力が要求されるにつれ、さらなる記録ノードがＩＰ通信システムのネットワークに加えられることである。また、ＰＣプラットフォームが性能を増やし続けるにつれ、記録能力もそれに対応して増大することである。
【課題を解決するための手段】
【０００３】
発明の分散型ソフトウェアアーキテクチャは、１からｎまでの処理要素またはノードの記録リソースからなる。この、記録ノードを分散する能力によって、記録リソースを記録すべき終点近くに位置づけることが可能となり、そうして必要とされるネットワークリソースを最小化する。
【０００４】
発明のソフトウェアアーキテクチャによって、どの要素が機能停止しても、その要素と関係する進行中のコールしか影響されないことが確実になる。そのネットワーク要素についての引き続いてのコールは、利用可能な能力を有するネットワークにおいて、他の要素へと経路が定められる。発明のソフトウェアアーキテクチャは、大きさの変更が可能であって、必要とされるだけ多くのさらなる記録リソースを可能とし、必要とされるだけのさらなる処理要素がネットワークに加えられる。発明のソフトウェアアーキテクチャは、それが用いられるパケットベースのシステムの性質のために非常に信頼性があり、一方、記録リソースは、システムにおける単一の端子に対し専用である必要はない。記録リソースは、１コールごとをベースとして割り当てられており、従って、一か所にためられているリソースを、記録されるべき多数の潜在的な端子の間でシェアすることが可能である。管理者たちは、自動記録をどう構成するかについていくつかのオプションを有する。管理者が、関係するコールだけを記録するシステムを構成できるようにすることで、ＣＰＵ処理、帯域幅およびディスクのスペースが節約される。
【０００５】
発明のソフトウェアのアーキテクチャは、簡単かつ直ちに構成可能であり、それによって、管理がＩＰ通信システムそのものに統合され、他の通信システムの構成すべてが管理される同じインターフェースを介して構成を記録することが可能となっている。アドレスを用いて自動記録が開始される。自動記録が可能とされているアドレスにダイヤルすることで、コールが記録され、ダイヤルされたアドレスに対してその記録にタグを付ける。自動記録が可能とされている一次的なアドレスからコールにダイヤルすることで、そのコールを記録して、その一次的なアドレスに対してその記録にタグを付ける。
【０００６】
本発明のソフトウェアによって提供される制御の粒状度またはパッケージングの例が、グループアドレスについてのコールの記録を管理することによって示されている。グループアドレスは、自動記録について１ステップで構成できる。より大きなアドレスグループの一員がコールに取り次ぐとき、その記録は、グループアドレスに対して蓄積され、局の一次アドレスに対して蓄積されない。これによってリソースが最適化されるのは、グループアドレスへのコールを記録することのみによるのであって、一次アドレスへのまたはそこからのコールによるものではない。発明のソフトウェアアーキテクチャによって提供される管理制御の別の例は、海外へのコールを記録する選択的な方法を提供することができるというものである。同じ局またはグループについて２つの外部サービスアドレスが作られ、そのうち１つは記録するように構成されるが、他方はそうではない。そしてユーザーは、記録するか否かの自分たちの必要性に合う外部サービスを選ぶという選択をしなければならず、それによっても、記録リソースのより良い管理が提供される。
【０００７】
需要に応じた記録もまた提供される。一旦コールが接続されれば、記録はいつでも開始できる。ユーザーは、「ストップ」または「スタート」の記録命令を発することによって、コールの需要に応じた記録を明白に停止または再開する。需要に応じた記録は、コール制御アプリケーションにメッセージを送ることによって実施される。これは、数多くの方法で達成できる。いくつか例をあげると、ＩＰ電話でボタンを押すこと、コンピュータ‐電話統合（ＣＴＩ）アプリケーションを用いること、またはウェブサービスを介するものである。管理者は、ＣＯＳ（サービスのクラス：Ｃｌａｓｓ  ｏｆ  Ｓｅｒｖｉｃｅ）プロフィールを介して需要に応じた記録に権利を割り当てることによって、この特権を管理することができる。
【０００８】
発明のソフトウェアアーキテクチャは、階層性の権利管理を提供する。記録の権利は、局とユーザーの双方のレベルで管理される。局は、ＩＰ電話のような音声端子に照会し、一方ユーザーは、通信するためのシステムにおいて端子を使用する人に照会する。ユーザーは、ユーザー名、パスワードまたはＰＩＮコードのような何らかの形の信用証明によって特定される。ユーザーは、典型的には、１つ以上の音声局または端子に対する権利が割り当てられる。そしてユーザーは、その端子において進行中のコールにつき記録を行うことができる。発明のコール管理アプリケーションソフトウェアは、メディアサーバーを通して記録されるべき音声端子間のＩＰメディアの流れを再経路付けする。
【実施例１】
【０００９】
（発明の詳細な説明）
ここで、より詳細に図面を参照するが、図１を参照すると、本発明が使用されているシステムアーキテクチャが示されている。システムアーキテクチャは、典型的には、パーソナルコンピュータまたはワークステーション１０’に結合される複数のＩＰ電話１０またはそれと等価のものからなる。ＰＣおよびＩＰ電話またはエンドユーザーは、ＩＰパケットベースのデータネットワークシステムの一部を構成する。各ユーザー１０は、典型的にはＩＰ電話であるが、それは、オーディオデータの流れが周知の方法でＩＰデータフォーマットに変換されているＰＯＴＳ型電話であってもよい。システムアーキテクチャは、システムの要件および規模に基づいて１つ以上のメディアサーバー１２を含む。各サーバーは、以下に詳細が記述され、本発明によりコールの記録を達成するべくそこに実装されているソフトウェアのアプリケーションを有しており、全てのコール管理とロギングが含まれている。これらのメディアサーバーは、エンドユーザーの橋渡しをし、それによって、全てのオーディオデータが各サーバーを通って流れ、または経路付けられ、そうして、発明のコール制御マネージャーがコールを記録し、以下に詳細が記述される他の機能を行う。続いて、メディアサーバー１２は、１からｎのメディアサーバーに記録され、蓄積されている記録ファイル全てが、蓄積され、専用のパーソナルコンピュータ１８で、そこにアクセスされるようにダウンロードされている中央ファイルサーバー１４に結合される。
【００１０】
１からｎのメディアサーバー１２のうち特定のエンドユーザーまたはワークステーションのコールを記録するのに用いられる特定のメディアサーバー１２は、ネットワークのリソースを最適化する以下のアルゴリズムを用いて決定される。
１．誘発エンドユーザーをホストしているコールマネージャーのメディアサーバー
２．誘発エンドユーザーと同じＬＡＮで最も負荷が低いメディアサーバー
３．コール許可制御が禁止されるとき別のＬＡＮで負荷が最も低いメディアサーバー
【００１１】
このアプローチは、地理的に複数の位置にまたがるシステムについてかなりの利点をもたらす。メディアの流れを管理するために最適なコールマネージャーを用いることによって、コール状態についてのコールマネージャーの知識を使ってさらなる最適化が可能となる。記録されているエンドポイントが延期されると、コールマネージャーは、ＭＯＨ（延期しているメッセージ）の流れを、記録メディアサーバーを通して経路付けせず、そうして、そのＭＯＨコールを記録するリソースを浪費しない。別の例は、転送と関係する。最適なメディアサーバーのコールマネージャーは、全てのコール状態を知っているので、記録されているエンドポイント１０の継続中のコールが転送されると、その記録は自動的に２つの記録ファイルに分割されるが、それは、コールマネージャーにそのコール転送状態が知らされるからである。これが特に有用である例は、以下の通りである。ＰＳＴＮコールがカスタマーサービス代理人のエンドユーザー１０に到着し、問題を解決できなくなって、そのサービス代理人がコールを別のエンドポイント１０のスーパーバイザーに転送する。その後、スーパーバイザーは、代理人とコールを見直したいと思うであろう。スーパーバイザーは、転送の後行われた顧客との話し合いを明らかにすることなく、カスタマーと代理人との間のコールの一区切りに簡単にアクセスするであろう。
【００１２】
各メディアサーバー１２は、簡単に再生できる共通のフォーマットでセッションを記録する。このフォーマットは、例えば、８ＫＨｚ、８ビットでサンプルされたｕ‐ｌａｗ  ｗａｖファイルである。記録は、最初は地方または最適な処理メディアサーバー１２で消費され、それらはそこに残るか、選択的に代わりの蓄積シェアまたはデータネットワークのファイルサーバー１４へと転送されるかし、このように柔軟に記録が蓄積される。ＩＰ電話またはエンドポイント１０が接続されるワークステーションまたはＰＣの場合には、デスクトップＣＴＩ（コンピュータ‐電話インターフェース）のアプリケーションの再生を用いて信用証明を得て、自分の記録ログにアクセスできる。選択された記録は、ＲＴＳＰ（実時間ストリーミングプロトコル）を介して流れに戻すか、局所的にダウンロードして再生することができる。
【００１３】
記録が、安全認証を用いてデータネットワークのファイルシェアに蓄積されているので、記録蓄積への権限の無いアクセスの防止が達成され、そうして、記録の再生の安全が保証されるが、記録へのアクセスにはある形の認証を必要とする。再生のための記録の選択について、記録ログが表示されているユーザーを識別するためのＰＩＮコードを用いる電話再生によってもまた、再生は達成される。代わりに、記録ログを得るためのユーザー名／パスワード証明を用いる安全ウェブサービスを介してのウェブサービスの再生もまた可能である。選択された記録は、ＲＴＳＰ（実時間ストリーミングプロトコル）を介して流れに戻されるか、局部的にダウンロードされて再生される。
【００１４】
ここで、図２および図３を参照すると、発明の主なソフトウェアアーキテクチャが各メディアサーバー１２に示されている。ＩＰ電話１０からのオーディオデータの流れ、またはそれらと等価のものが、通常は、ネットワークインターフェースカード（ＮＩＣ）２０を介してネットワークに接続されており、１つの電話がオーディオの流れ０を提供するソースであり、第二のものがオーディオの流れ１を提供する行先である。ネットワークインターフェースカード（ＮＩＣ）は、オーディオデータフレームが送信され、メディアサーバーで受信されるゲートウェイとして働く。ＮＩＣは、通常のネットワークドライバーインターフェースかミニポートアダプターかドライバー２２によって制御され、それらによって、１つ以上のＮＩＣドライバーがデータパケットを送受信して、１つ以上の、上位にあるプロトコルドライバーおよびオペレーティングシステムと通信する。ミニポートアダプター２２は、オーディオデータの流れを発明の中間レベルＲＴＰ（実時間トランスポートプロトコル）中間ブリッジドライバーソフトウェアカーネル２４に届ける。ＲＴＰレベルは、電話オーディオデータの流れのような実時間データをマルチキャストまたはユニキャストネットワークサービス上で送信するアプリケーションのための、端末同士のネットワークトランスポート機能を提供する。データトランスポートは、通常制御プロトコル（ＲＴＣＰ）によって拡大され、データ送付を、大きなマルチキャストネットワークに大きさの変更が可能な方法でモニタすることが可能となり、最小限の制御および識別機能を提供する。ＲＴＰおよびＲＴＣＰは、下位にあるトランスポートおよびネットワーク層から独立して設計されている。ＲＴＰプロトコルは、ＲＴＰレベルの翻訳プログラムとミキサーの使用をサポートする。このＲＴＰ中間プロトコルドライバーインターフェースは、古いプロトコルアダプターまたはドライバー２２と、ドライバーがユーザーへのサービスを提供するＴＤＩインターフェースまたは別のアプリケーション専用のインターフェースを実施する上位レベルのトランスポートプロトコルアダプターまたはドライバー２６との間にある。そのようなドライバーは、パケットを割り当て、データをパケットにコピーし、ＮＤＩＳをコールすることによって、パケットをより低いレベルのドライバーに送る。それはまた、より低いレベルにあるプロトコルインターフェースを提供して、次に低いレベルのドライバーまたはアダプター２４からパケットを受け取る。
【００１５】
中間の高機能ネットワークＲＴＰ橋渡しデバイスドライバー２４が、ネットワークスタックのネットワークインターフェースドライバー２２の真上に位置していて、受け取られる全てのネットワークパケットを処理する。この処理を構成しているステップは、ネットワークスタックにおける、次に高いＩＰプロトコルアダプタードライバー２６まで各々受け取られたオーディオデータパケットを送り、各パケットを検査して、行先ポートが、ＲＴＰレベルの宛先変更テーブル３０に列挙されているＲＴＰパケットであるかどうか判定し、その宛先変更テーブルは、詳細が以下に説明されるようなコールを、コールの行先に再び仕向けるためのコールマネージャープログラムによって設定されている。かかってくるコールは、その行先としてメディアサーバーを有しており、コールマネージャーは、そのコールを、その実際の意図された行先に再び仕向けなければならない。この後半の基準に合致するこれらのパケットは複製され、そして、ソースおよび行先ＩＰアドレスおよびポート‐これらの値は、行先ポートを含んだ同じ宛先変更テーブルエントリーから読み取られる‐について書き換えられる。そして、複製されたパケットは、送信されるべきネットワークドライバー２２へと送り戻される。受信から再送信までに導入される遅延は、１ｍＳ未満である。そして、ソースオーディオの流れ０（図２のブロック３２）およびＲＴＰ橋渡しドライバーから送られる行先オーディオの流れ１（図２のブロック３４）が、記録アプリケーション３４’に入力されて、その後、エンコーダー３６によって符号化され、望まれるか必要であるかするなら、引き続いてネットワーク蓄積デバイスまたはファイルサーバー１４に蓄積するために、各メディアサーバー１２の局部蓄積メディア３８に蓄積される。
【００１６】
注意すべきは、前述のパケット反射手順は、ＣＯＤＥＣ（符号器‐復号器）から独立している。アプリケーションレベルでは、記録されるべきパケットは、独立して復号され、それによって非対称の符号を用いる双方向メディアの流れ３２および３４がサポートされる。２つの流れ３２および３４は、コールにおいて双方のソースの記録を唯一とするために加算される。加算された流れは、８ＫＨｚ、８ビットでサンプルされたｕ‐ｌａｗ  ｗａｖファイルのような、蓄積および再生のための共通のフォーマットに変換される。流れの実時間反映がＩＰスタックの下で取り扱われるので、アプリケーション層は、復号、加算、記録および記録蓄積演算への送信を行う間、ＩＰスタックバッファを用いる。コール記録に関する情報は、ＣＤＲ（コール詳細記録）への内線として蓄積される。したがって、コーラーＩＤ（ＣＬＩＤ）や自動番号識別（ＡＮＩ）やダイヤルされた番号の識別サービス（ＤＮＩＳ）のような、全てのＣＤＲ属性によって、記録は検索可能である。ＣＤＲの通知によって、コールについて記録が利用可能であるということが指示できる。
【００１７】
ここで図４を参照すると、記録リソース選択論理が示されている。一旦コールが開始されると（ブロック４０）、記録アプリケーションソフトウェア３４は、そのコールが、地方のエンドユーザーかワークステーションもしくは管理者によって設定されるような記録（ブロック４２）を必要とするものかどうか判断する。記録されるべきコールでなければ、オーディオデータの流れが、通常通り設定され、コールは通常の方法で終了される（ブロック４４）。決定ブロック４２への答えが「イエス」であるなら、ソースと関係する各々の管理ホストメディアサーバー１２において、利用可能な記録リソースがあるかどうかをソフトウェアが判定する（決定ブロック４６）。「イエス」であるなら、それに続くオーディオの流れ３２および３４（図２）がこのメディアサーバー（ブロック４８）を介して再経路付けされ、コール設定が達成されて（ブロック５０）、オーディオデータの流れ３２および３４が、ホストメディアサーバーでの記録アプリケーションを介して記録される。決定ブロック４６への答えが「ノー」であるなら、発明のソフトウェアが、誘発するエンドユーザーのそれと同じＬＡＮで、他のメディアサーバー１２を探し、それらが利用可能な記録リソースを有するかどうかを見る（決定ブロック５０’）。「イエス」であるなら、オーディオの流れ３２および３４は、最も利用可能であるものに再経路付けされる（ブロック５２）。決定ブロック５０’への答えが「ノー」であるなら、システムソフトウェアは、誘発するエンドポイントと関係しない別のＬＡＮのメディアサーバーで、記録リソースの利用可能性のほうを見る（決定ブロック５２’）。「イエス」であるなら、オーディオの流れ３２および３４は、最も利用可能性を有するものに再経路付けされ（ブロック５４）、コール設定が終了する（ブロック５０）。決定ブロック５２’への答えが「ノー」であるなら、決定ブロック５６において、アプリケーションソフトウェアは、その記録無しにコールを完了することが許されるかべきかどうかを決定する。「イエス」であるなら、コール設定が完了する（ブロック４４）。「ノー」であるなら、「失敗」コール信号が、誘発するエンドユーザーまたはソースのエンドユーザーへと送り戻される（ブロック５８）。
【００１８】
図５を参照すると、図２および図３の中間ＲＴＰ橋渡しドライバー２４についてのフローチャートが示されている。ＲＴＰ橋渡しドライバーは、図２および図３のプロトコルアダプター２２からのオーディオパケットを待ち（ブロック６０）、それを受け取ると、パケットを図２および図３の上位レベルのＩＰプロトコルアダプター２６に送り（ブロック６２）、そこで、決定ブロック６４において、パケットがＲＴＰデータを含むかどうかを決定する。決定ブロック６４への答えが「ノー」であるなら、何も行われない。パケットがＲＴＰデータであるなら、決定ブロック６６は、行先ポートが図２の宛先変更テーブル３０に列挙されているかどうかを判定する。列挙されていなければ、何も行われないが、それは、コールが記録できないであろうからである。「イエス」であるなら、ソースＩＰアドレスと行先とポートＩＰアドレスが書き換えられ、新しいＩＰとイーサネット（登録商標）チェックサムが計算され（ブロック６８）、その結果、変更されたパケットが、図２および図３のミニポートアダプター２２へと送られる（ブロック７０）。
【００１９】
ここで図６を参照すると、記録アプリケーションソフトウェアについてのフローチャートが示されている。２つのエンドポイント間の対話を記録するために、双方のソース（流れ０および流れ１）からの音声が捕捉され、混合されなければならない。深さ８のパケット待ち行列が作られて、流れのパケットを加算するか、または混ぜ合わせる。名目のオーディオパケット化期間である２０ｍＳ毎に、発明のソフトウェアアプリケーションがＲＴＰパケットを読み取ろうとし、そしてそれを加算して、流れについての待ち行列の、次に利用可能な流れの要素とする。これは、２０ｍＳの割り込み毎に、流れ０および流れ１の各々について一回行われる。オーディオの流れ３２および３４（ブロック７１）からのＲＴＰパケットが読み取られる（ブロック７２）。決定ブロック７４は、読み取るべきオーディオデータがあるかどうかを決定する。ネットワークのジッターや起こり得るパケットの損失のために、処理されるべきデータが無いか、または利用できるデータのパケットが２つ以上あるかもしれない。「イエス」であるなら、ソフトウェアがデータを復号し（ブロック７６）、そして待ち行列においてデータの余地があるかどうかを判定する（決定ブロック７８）。ＲＴＰを送るのに、多くの符号を用いることができる。ＲＴＰは、混合される前に線形フォーマットへと復号される。決定ブロック７８への答えが「イエス」であるなら、加算の演算が行われ、データを、関連するそれぞれの流れ０および１について、次に利用可能な待ち行列要素へと配置する。各流れ０および１についてポインタを用いることで、加算プロセスは、ネットワークのジッターの影響を緩和することが可能となる（ブロック８８）。決定ブロック７８への答えが「ノー」であるなら、ソフトウェアは、全て加算されたサンプルを待ち行列からディスクへと流し込む（ブロック８２）。加算されたサンプルは、双方の流れ０および１からのデータをそこへと加算した待ち行列を参照する。これらの要素は一揃いになっていて、待ち行列から動かしてディスクに送り、さらに多くのパケットを加算するための空間を空けることができる。そしてソフトウェアは、決定ブロック８４において、ここに、待ち行列におけるデータのための余地があるかどうかを判定する。「イエス」であるなら、プログラムはブロック８８へと進んでデータを加算し、前述のように利用可能な流れのために次に利用可能な待ち行列要素とする。決定ブロック８４への答えが「ノー」であるなら、ソフトウェアは、データのための余地ができるまで、待ち行列から加算されていない十分なサンプルを流し出す（ブロック８６）。ネットワークにおける深刻なジッターまたはパケットの損失のために、流れ０および１の一方からのデータのみで待ち行列を使い尽くすことが可能であり、この場合、１つの流れのデータのみを含む要素が待ち行列から動かされて、蓄積用のディスクに送られる。そして、プログラムは前述の通りブロック８８へと進む。
【００２０】
ブロック７８から８８までのステップを用いて、バッファにおいてオーディオの流れ３２および３４（流れ０および１）の双方を加算し、一揃いの対話が記録され、前述のように対話が実際に行われるにつれ、コールの双方の端部が連続して記録される。決定ブロック７４への答えが「ノー」であるなら、もしくはブロック８８のデータ加算ステップが完了した後は、データの流れ０が処理されていたなら、データの流れ０からデータの流れ１までのブロック９０においてプログラムが増す。データの流れ１が処理されていたなら、ソフトウェアはオーディオデータの流れが１よりも大きいと判定し（決定ブロック９０への「イエス」）、ソフトウェアが元に戻って、流れ０についてのデータを再度待つということを意味する。決定ブロック９２への答えが「ノー」であるなら、ＲＴＰ橋渡しレベルからの流れ１について、オーディオデータの受け取りをプログラムが待つ。待ち行列は、各流れについて１つのポインタという、２つのポインタがあるバッファからなる（流れ０ポインタおよび流れ１ポインタ）。待ち行列は、サイレンスへと初期化され、ディスクに流し込まれた各サンプルはサイレンスと置き換えられる。各システムについてパケットが到着すると、それらは待ち行列において次に利用可能な場所へと加算され、その結果、流れ０および流れ１の加算か、または他方の流れがある時間利用不可能である（パケットの損失または過度のジッターによって利用可能でない流れデータもある）ならば、単一のシステムの流れからのデータかを含むいずれかのパケットを生じる。
【００２１】
図７を参照すると、メディアサーバー１２に蓄積される発明のコールマネージャープログラム３４によって管理される、記録設定コールフローが示されている。そのコールフローには、コールを管理し、記録するための、コールマネージャー、メディアサーバーおよび電話の間の信号が記述されている。コールマネージャーは、ＲＴＰ橋渡しドライバーレベル２４で、コールの設定および宛先変更テーブル３０を制御し（図２）、かつソースと行先ＩＰアドレスとポート‐これらの値は、行先ポートを含む同じ宛先変更テーブルエントリーから読み取られる‐に関して書き換えられたパケットを複製する。そして、複製されたパケットが、送信されるべきネットワークドライバー２２に戻される。図７において、最初の状態は、電話ＡおよびＢの間で確立された接続である。コールマネージャーは、それぞれのメディアサーバーを介してコールの記録を初期化し、そして、メディアの記述ＡおよびＢからなるメディア接続を作るが、それらには、エンドポイントがＲＴＰの流れを受け付けるであろうＩＰアドレスとポートとが含まれている。メディアサーバーは、「接続結果作成」でコールマネージャーに応答し、それにはＡおよびＢなるメディアサーバーの記述が含まれており、その各々には、ＲＴＰの流れを受け付けるためにメディアサーバーが使っているであろうＩＰアドレスとポートが含まれている。続いてコールマネージャーは、ＡおよびＢのメディア接続の記述を変更し、メディアサーバーを誘発して、ＲＴＰ橋渡しのためのＡおよびＢへの音声パケットのコピーを転送または複製するプロセスを開始させる。そしてメディアサーバーは、コールマネージャーに信号を送り、結果として、メディアの記述ＡおよびＢという変更された接続を得る。そしてコールマネージャーは、パケットを電話Ａに送るためのメディア接続結果を変更するが、それは、変更された接続パケットをコールマネージャーに送り返し、続いて、電話Ｂでの接続についても同じことを行う。
【００２２】
ＲＴＰ橋渡しドライバーレベル２４（図２）の宛先変更テーブル３０は、エントリー毎に５つのパラメータからなる。各エントリーは、一方向の流れ１つについて責任がある。電話コールの二方向を記録するために２つのエントリーが必要とされる。
エンドポイントＡ  --------->  メディアサーバー  --------->  エンドポイントＢ
エンドポイントＡ  <---------  メディアサーバー  <---------  エンドポイントＢ
テーブルエントリーのパラメータは、以下の通りである。
ＬｉｓｔｅｎＰｏｒｔ‐処理されるべく入ってくるＲＴＰの流れについてメディアサーバーが聞くＵＤＰ（ユーザーデータグラムプロトコル）ポート
ＳｅｎｄＰｏｒｔ‐コピーされたＲＴＰパケットを送信するためにメディアサーバーが用いるＵＤＰ（ユーザーデータグラムプロトコル）ポート
ＲｅｄｉｒｅｃｔＰｏｒｔ‐メディアサーバーがＲＴＰに送る行先エンドポイントのポート
ＲｅｄｉｒｅｃｔＩＰＡｄｄｒ‐メディアサーバーがＲＴＰを送る行先エンドポイントのＩＰアドレス
ＲｅｄｉｒｅｃｔＭＡＣＡｄｄｒ‐再び仕向けるべきＭＡＣ（メディアアクセス制御）アドレス（これは、別のサブネットに配置されるならばエンドポイントまたはゲートウェイであっても良い）
【００２３】
宛先変更テーブルのパラメータは、図６の記録アプリケーションによって得られ、以下のようにＲＴＰ橋渡しドライバーに送られる。ＲｅｄｉｒｅｃｔＰｏｒｔおよびＲｅｄｉｒｅｃｔＩＰＡｄｄｒは、コール設定の間に記録アプリケーションによって得られる（前述の図７の記録コールフロー図を参照）。記録アプリケーションは、ＡＲＰ（アドレス解像度プロトコル）を行って使用されるＭＡＣ（メディアアクセス制御）アドレスを得る。記録アプリケーションは、使用されるＬｉｓｔｅｎポートおよびＳｅｎｄポートを開く。記録アプリケーションは、これらのパラメータをＲＴＰ橋渡しドライバーに送って、宛先変更テーブルを築く。
【００２４】
ＲＴＰ橋渡しのアプリケーションは、オーディオＲＴＰの記録に限られない。本発明は、ビデオＲＴＰを記録するのに用いられる。それは記録を超えるアプリケーションについても使用される。たとえば、以下の図で示されるようなｎ者会議放送へのアプリケーションを構築するのにも用いられる。
エンドポイントＡ  --------->  メディアサーバー  --------->  エンドポイントＢ
エンドポイントＡ  --------->  メディアサーバー  --------->  エンドポイントＣ
エンドポイントＡ  --------->  メディアサーバー  --------->  エンドポイントＤ
エンドポイントＡ  --------->  メディアサーバー  --------->  エンドポイントｎ
【００２５】
本発明は、ＲＴＰトラフィックに限定されない。それは、実時間ＵＤＰトラフィックを効率的に中継する必要がある、いかなるアプリケーションについても用いられる。
【００２６】
発明の特定の実施例が示され、記述されているが、添付した特許請求の範囲に説明される発明の範囲および精神から逸脱することなく、数多くの変更および改良がなされても良いことを理解すべきである。
【図面の簡単な説明】
【００２７】
【図１】発明のシステムアーキテクチャのブロック図である。
【図２】発明のコール記録ソフトウェアを組み込み、かつそれを実施する発明のメディアサーバーアーキテクチャのブロック図である。
【図３】図２のメディアサーバーアーキテクチャのソフトウェア層またはカーネルの描写である。
【図４Ａ】発明のコール記録ソフトウェアの記録リソース選択論理のフローチャートである。
【図４Ｂ】発明のコール記録ソフトウェアの記録リソース選択論理のフローチャートである。
【図５】図４のＲＴＰブリッジ中間体のフローチャートである。
【図６】図４のソフトウェア記録アプリケーションのフローチャートである。
【図７】コール管理プログラムにより制御される記録設定フローを示すチャートである。
【図１】
2009527200.tif 000003
【図２】
2009527200.tif 000004
【図３】
2009527200.tif 000005
【図４】
2009527200.tif 000006
【図４Ａ】
2009527200.tif 000007
【図４Ｂ】
2009527200.tif 000008
【図５】
2009527200.tif 000009
【図６】
2009527200.tif 000010
【図７】
2009527200.tif 000011
【国際調査報告】
2009527200.tif 000012