(57)【要約】      （修正有）【課題】所望のビデオ、オーディオストリームを選択的に選べ、ストリーム帯域幅を制御できること。【解決手段】会議を開催する電気通信システムはネットワークを含んでいる。システムはネットワークを通じて互いに通信するＮ個のノードを具えている。Ｎ個のノードの各ノードは、帯域幅を有する独自のビデオストリームと、それに対応しており、帯域幅を有する独自のオーディオストリームとを生成可能であって、それらストリームを、Ｎ個のノードのその他のノードにネットワークを通じて送信する。各ノードの各ストリームの帯域幅は、所定のレベルに動的に制御及び設定される。電気通信システムにて会議を開催する方法。帯域幅マネージャ。電気通信ネットワークにて帯域幅を制御する方法。会議を開催するための電気通信システム。各ノードは、その他のノードの何れかから送られる任意のストリームを選択的に受信できる。ビデオフォン。ビデオコールをする方法。【選択図】図２２
2005318535.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークと、
ネットワークを通じて互いに通信するＮ個のノードとを具えており、
Ｎは、３より大きい、又は３と等しい整数であり、
各ノードは、帯域幅を有しており、それに対応する独自の少なくとも１つのビデオストリームと、帯域幅を有しており、それに対応する独自のオーディオストリームとを生成可能であり、それらストリームは、ネットワークを通じてＮ個のノードのその他のノードに送信され、
各ノードから送られる各ストリームの帯域幅は、所定のレベルに動的に制御及び設定される、会議を開催するための電気通信システム。
【請求項２】
ネットワークを通じてＮ個のノードと通信して、各ノードから送られる各ストリームの帯域幅を制御する帯域幅マネージャを含む、請求項１に記載のシステム。
【請求項３】
Ｎ個のノードには、ネットワークを通じて互いに通信する第１ノードと、第２ノードと、少なくとも１つの第３ノードとがあり、
第１ノードは、第１ノードのシーンの第１ビデオストリームと、第１ノードのシーンの第２ビデオストリームと、第１ノードのシーンのオーディオストリームとを第２及び第３ノードに送り、
第２及び第３ノードは、そのオーディオストリームと、第１ビデオストリーム又は第２ビデオストリームの何れかとを再生する、請求項２に記載のシステム。
【請求項４】
第１ビデオストリームのフレームレートは、１秒間に２５フレームよりも大きく又はそれと等しく、第２ビデオストリームのフレームレートは、１秒間に２５フレームよりも小さい、請求項３に記載のシステム。
【請求項５】
第２及び第３ノードは、ディスプレイスクリーンを有しており、
第２又は第３ノードが第１ビデオストリームを表示する場合、スクリーンの２０％よりも大きい又はそれに等しい領域に亘って、第１ビデオストリームを大きい画像として表示し、第２又は第３ノードが第２ビデオストリームを表示する場合、スクリーンの２０％よりも小さい領域に亘って、第２ビデオストリームを小さい画像として表示する、請求項４に記載のシステム。
【請求項６】
ネットワークを通じて、第１、第２及び第３ノードと通信する第４ノードを含んでおり、
第４ノードは、第１、第２及び第３ノードに、テレビジョンチャンネルのテレビジョンビデオストリームを送り、
第１、第２及び第３ノードは、スクリーン上にて第１ビデオストリームの横にそのテレビジョンストリームを表示できる、請求項５に記載のシステム。
【請求項７】
第２ノードは、第２ノードのシーンの第１ビデオストリームと、第２ノードのシーンの第２ビデオストリームと、第２ノードのシーンのオーディオストリームとを第３ノードに送り、
第３ノードは、ディスプレイコントローラを具えており、
ディスプレイコントローラは、スクリーン上に現れる画像を制御し、各ノードから送られた第１ビデオストリームの各々を、第３ノードのスクリーン上に互いに並べて再生する、請求項６に記載のシステム。
【請求項８】
ネットワークは、イーサネット又はＡＴＭネットワークである、請求項７に記載のシステム。
【請求項９】
ビデオ会議コール用の会議ブリッジ又はＭＣＵを用いることなく、ビデオ会議コール用として、第１及び第２ノードの第１及び第２ビデオストリームと、それらのオーディオストリームとが、ネットワークに送られる、請求項８に記載のシステム。
【請求項１０】
各ノードは、ビデオ会議コールに、ＡＴＭポイントツーマルチポイントストリームを用いる、請求項９に記載のシステム。
【請求項１１】
第３ノードは、第１又は第２ノードから送られる第１又は第２ビデオストリームのどれが表示されるかを予め定める、請求項１０に記載のシステム。
【請求項１２】
第１若しくは第２ノードの夫々のシーンにおけるユーザが話している場合、又は、第１若しくは第２ノードの第１ビデオストリームを表示するように第３ノードが予め定められている場合、第３ノードは、第１又は第２ノードから送られる第１のビデオストリームの表示を選択する、請求項１１に記載のシステム。
【請求項１３】
第１及び第２ノードの第１ビデオストリームは、ネットワークに亘って送られる際にＭＰＥＧ-２フォーマットにされている、請求項１２に記載のシステム。
【請求項１４】
第１及び第２ノードは、コンティニュアスＰを用いて、第１及び第２ノードの第１ビデオストリームをＭＰＥＧ-２フォーマットにする、請求項１３に記載のシステム。
【請求項１５】
第１及び第２ノードは、各々のシーンの第１ビデオストリームをクリップする、請求項１４に記載のシステム。
【請求項１６】
第１及び第２ノードは、各々のシーンの第１ビデオストリームを、各々のシーンにおけるユーザがいない場所について第１ビデオストリームの部分を削除して、クリップする、請求項１５に記載のシステム。
【請求項１７】
第１及び第２ノードは、各々のシーンにて所定の閾値を超えたノイズがある場合にのみ、各々のシーンのオーディストリームを送る、請求項１６に記載のシステム。
【請求項１８】
第１ノードは、自動プレゼンスセンサを具えており、
自動プレゼンスセンサは、ユーザが第１ノードのシーンに存在するか否かを判断して、ユーザが第１ノードに存在するか否かを示すプレゼンスインジケータを生成し、
第１ノードは、第２及び第３ノードにプレゼンスインジケータを送る手段を具えている、請求項１７に記載のシステム。
【請求項１９】
第１ノードは、第１ノードのシーンの全てのユーザに、プレゼンスインジケータが所定の時間内に作成されようとしている旨を警告する警告信号を生成する、請求項１８に記載のシステム。
【請求項２０】
第１ノードは、第１シーンのビデオ画像を取得して第１ビデオストリームを生成する撮像手段を具えている、請求項１９に記載のシステム。
【請求項２１】
撮像手段と通信して、フレームバッファリングを行うことなく、第１ビデオストリームを圧縮して、所望のフォーマットにエンコードするエンコーダを具える、請求項２０に記載のシステム。
【請求項２２】
第１ノードは、エンコーダと通信するフィールドプログラマブルゲートアレイを含んでおり、
フィールドプログラマブルゲートアレイは、第１ビデオストリームをパケット化し、撮像手段から第１ビデオストリームを受け取り、第１ノードの第２ビデオストリームを生成し、それをパケット化する、請求項２１に記載のシステム。
【請求項２３】
第１ノードは、フィールドプログラマブルゲートアレイ及びネットワークと通信するネットワークインターフェイスを含んでおり、
ネットワークインターフェイスは、第１ノードのビデオストリームをネットワークに転送し、第２ノードから第１ビデオストリームを受信し、それをフィールドプログラマブルゲートアレイに送る、請求項２２に記載のシステム。
【請求項２４】
第１ノードは、第１シーンの音声を受け取り、第１ノードのオーディオストリームを生成するマイクロホン手段を含む、請求項２３に記載のシステム。
【請求項２５】
第１ノードは、スピーカ手段を具えており、
スピーカ手段は、ネットワークインターフェイスと通信して、第２ノードから送られるオーディオストリームを再生する、請求項２４に記載のシステム。
【請求項２６】
第１ノードは、ＤＳＰを含んでおり、
ＤＳＰは、第１ノードのオーディオストリームをパケット化して、フィールドプログラマブルゲートアレイにオーディオストリームを供給し、
フィールドプログラマブルゲートアレイは、第１ノードのオーディオストリームをネットワークインターフェイスに転送し、
ネットワークインターフェイスは、第１ノードのオーディオストリームをネットワークに転送し、
ＤＳＰは、フィールドプログラマブルゲートアレイから、第２ノードのオーディオストリームを受け取る、請求項２５に記載のシステム。
【請求項２７】
第１ノードは、オーディオインターフェイスを含んでおり、
オーディオインターフェイスは、マイクロホン手段から第１ノードのオーディオストリームを受け取って、それをデジタル化してＤＳＰに供給し、ＤＳＰから受け取った第２ノードから送られたオーディオストリームを、スピーカ手段が再生するアナログ形式に変換する、請求項２６に記載のシステム。
【請求項２８】
ネットワークインターフェイスは、第１ノードのオーディオストリーム及びビデオストリームのパケットがネットワークに送られる前に、それらにタイムスタンプを付し、第１ノードが受け取る第２ノードのオーディオストリーム及びビデオストリームのパケットを、タイムスタンプを用いて整列し、第２ノードのオーディオストリーム及びビデオストリームのパケットが第１ノードで再生されると、第２ノードのシーンの画像に関する音声が再生される、請求項２７に記載のシステム。
【請求項２９】
第１ノードは、第２ノードから送られる第１ビデオストリームを受け取って格納する受信メモリと、ネットワークインターフェイス、エンコーダ、フィールドプログラマブルゲートアレイ及びＤＳＰに接続されて、それらを制御するメインコントローラとを具えており、
メインコントローラは、ネットワークインターフェイスに指示して、第２ノードの第１ビデオストリームを選択して、それを受信メモリに送り、受信メモリに格納された第２ノードの第１ビデオストリームをデコード及び伸張して、それをディスプレイコントローラに送る、請求項２８に記載のシステム。
【請求項３０】
第１ノードは、ディスプレイコントローラに接続されたＬＣＤコントローラを含んでおり、
ディスプレイスクリーンは、ＬＣＤコントローラに接続されたパネルディスプレイを含んでおり、
ＬＣＤコントローラは、ディスプレイコントローラから第２ノードの第１ビデオストリームを受け取り、第２ノードの第１ビデオストリームをパネルに表示する準備をする、請求項２９に記載のシステム。
【請求項３１】
機能に関するボタンがタッチスクリーンに見えており、
タッチスクリーンコントローラは、タッチスクリーン及びメインコントローラに接続されており、ユーザがタッチスクリーン上でタッチしたボタンに関する情報を、メインコントローラに転送する、請求項３０に記載のシステム。
【請求項３２】
第１ノードは、デコーダを含んでおり、
デコーダは、撮像手段から送られる第１ノードのシーンの第１ビデオストリームをデジタル形式に変換して、それをエンコーダ及びフィールドプログラマブルゲートアレイに供給し、
デコーダは、フィールドプログラマブルゲートアレイ及びエンコーダに接続されており、
さらに、デコーダは、テレビジョンビデオストリームと、その他のアナログ形式のビデオストリームを受け取って、それらをデジタル形式に変換する、請求項３１に記載のシステム。
【請求項３３】
撮像手段は、デコーダと通信するアナログビデオカメラを、エンコーダ及びフィールドプログラマブルゲートアレイと通信するデジタルビデオカメラを、又は、フィールドプログラマブルゲートアレイと通信するファイヤラインカメラであって、フィールドプログラマブルゲートアレイは、ファイヤラインカメラから受け取ったビデオストリームをエンコードするファイヤラインカメラを具えている、請求項３２に記載のシステム。
【請求項３４】
ＤＳＰは、第１ノードのシーンのオーディオストリームのステレオエコーキャンセルを行い、
エンコーダは、第１ノードの第１ビデオストリームに少なくとも７２０×６４０ピクセルの解像度を与え、
マイクロホン手段及びスピーカ手段は全二重である、請求項３３に記載のシステム。
【請求項３５】
ＤＳＰは、スピーカ手段で生成されるノイズについてマイクロホン手段をモニタし、スピーカ手段を調整して所望のノイズレベルを維持する、請求項３４に記載のシステム。
【請求項３６】
メインコントローラは、ユーザによるコマンドを認識して、ビデオ会議の別のユーザに自動的にコールし、そのコマンドを用いて、その他のユーザに、彼らがビデオ会議を求められている旨をアナウンスする、請求項３５に記載のシステム。
【請求項３７】
第１ノードがビデオコールを受け入れられない場合、第１ノードにビデオメールがもたらされる、請求項３６に記載のシステム。
【請求項３８】
ネットワーク及び第１ノードと通信するサーバを具えており、
サーバは、第１ノードがビデオコールを受信しない場合に、第１ノードへのビデオコールを受信し、第１ノードが受信しないビデオコールに関するビデオメッセージを格納し、第１ノードで見られることを待っているビデオコールがある旨のビデオコール待ちメッセージを第１ノードに送る、請求項３７に記載のシステム。
【請求項３９】
第１ノードは、ディスプレイコントローラに接続された複数のディスプレイパネルを有しており、
個々のノードから送られる第１ビデオストリームの画像は、複数のパネルが１つの連続的なパネルであるかのように、並べてパネル上に表示される、請求項３８に記載のシステム。
【請求項４０】
第１ノードは、第２撮像手段を具えており、
第２撮像手段は、第１ノードのシーンのビューが撮像手段と異なっている第１ノードの第１ビデオストリームを生成する、請求項３９に記載のシステム。
【請求項４１】
メインコントローラは、フィールドプログラマブルゲートアレイから送られた第１ノードの第２ビデオストリームを、ディスプレイコントローラに送り、
第２ビデオストリームがディスプレイパネル上に表示されて、第１ノードのユーザは、ディスプレイパネル上にて第１ノードのシーンを見る、請求項４０に記載のシステム。
【請求項４２】
Ｎは、３より大きい、又は３と等しい整数であって、ネットワークを通じて互いに通信するＮ個のノードの各々にて、帯域幅を有しており、それに対応する独自の少なくとも１つのビデオストリームと、帯域幅を有しており、それに対応する独自のオーディオストリームとを生成して、それらストリームを、ネットワークを通じてＮ個のノードのその他のノードに送信する工程と、
各ノードから送られる各ストリームの帯域幅を、所定にレベルに動的に制御及び設定する工程とを含む、電気通信システムにて会議を開催する方法。
【請求項４３】
Ｎは、３より大きい、又は３と等しい整数であり、Ｎ個のノードを有するネットワークと通信する手段であって、Ｎ個のノードの各々は、帯域幅を有しており、それに対応する独自の少なくとも１つのビデオストリームと、帯域幅を有しており、それに対応する独自のオーディオストリームとを生成可能であり、それらストリームは、ネットワークを通じてＮ個のノードのその他のノードに送信される手段と、
各ノードから送られる各ストリームの帯域幅を、所定のレベルに動的に制御及び設定する手段とを含む帯域幅マネージャ。
【請求項４４】
Ｎは、３より大きい、又は３と等しい整数であり、Ｎ個のノードを有するネットワークと帯域幅マネージャとが通信する工程であって、Ｎ個のノードの各々は、帯域幅を有しており、それに対応する独自の少なくとも１つのビデオストリームと、帯域幅を有しており、それに対応する独自のオーディオストリームとを生成可能であり、それらストリームは、ネットワークを通じてＮ個のノードのその他のノードに送信される工程と、
帯域幅マネージャを用いて、各ノードから送られる各ストリームの帯域幅を、所定のレベルに動的に制御及び設定する工程とを含む、電気通信ネットワークにて帯域幅を制御する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオ及びオーディオ会議に関する。より詳細には、本発明は、ビデオ及びオーディオ会議に関しており、ネットワークの各ノードは、自らが所望するビデオ又はオーディオストリームを選択的に選  ぶことが可能であって、ストリームの帯域幅は、所定のレベルに動的に制御及び設定される。
【背景技術】
【０００２】
ネットワークに亘って高品質の会議コールを得るためには、以下のタイプの制約がある：
−  制限された帯域幅
−  [アクセス、プライオリティー、モデレーター、ポリシー]のような管理上の制約
【０００３】
このような制約に対応できる能力が存在する必要がある。本発明は、会議コールの品質を調整して、現在におけるネットワーク状態及び構成に合わせる。また、本発明は、ネットワーク構成及び制約の変化にも対処可能である。
【０００４】
加えて、参加者が多い会議コールでは、各参加者は、その他の参加者から送られるオーディオ及びビデオストリームに苦しめられるだろう。参加者は、どのストリームが見られ、又は聴かれるかを選択する能力を有することで、起こり得るデータのオーバーロードを規制できるべきである。本発明は、会議の各参加者に、会議のその他の参加者から送られた任意のストリームを選択する能力を与える。
【発明の開示】
【０００５】
本発明は、会議を開催するための電気通信システムに関する。システムは、ネットワークを具えている。システムは、ネットワークを通じて相互に通信するＮ個のノードを具えており、ここで、Ｎは、３より大きい又は３と等しい整数である。Ｎ個のノードの各ノードは、それに対応しており、帯域幅を有する独自のビデオストリームと、それに対応しており、帯域幅を有する独自のオーディオストリームとを生成可能であって、それらストリームを、Ｎ個のノードのその他のノードにネットワークを介して送信する。各ノードの各ストリームの帯域幅は、所定のレベルに動的に制御及び設定される。システムは、ネットワークを通じてＮ個のノードと通信する帯域幅マネージャを含んでおり、該帯域幅マネージャは、各ノードから送られる各ストリームの帯域幅を制御するのが好ましい。
【０００６】
本発明は、電気通信システムにおいて会議を開催する方法に関する。その方法は、ネットワークを通じて相互に通信するＮ個のノードの各々で、それに対応しており、帯域幅を有する独自のビデオストリームと、それに対応しており、帯域幅を有する独自のオーディオストリームとを生成して、Ｎ個のノードのその他のノードにネットワークを介して送信する工程を含んでいる。ここで、Ｎは、３より大きい又は３と等しい整数である。各ノードから送られる各ストリームの帯域幅を、所定のレベルに動的に制御及び設定する工程がある。
【０００７】
本発明は、帯域幅マネージャに関する。マネージャは、Ｎ個のノードがあるネットワークと通信する手段を具えている。ここで、Ｎは、３より大きい又は３と等しい整数である。Ｎ個のノードの各ノードは、それに対応しており、帯域幅を有する独自のビデオストリームと、それに対応しており、帯域幅を有する独自のオーディオストリームとを生成可能であって、それらストリームを、Ｎ個のノードのその他のノードにネットワークを介して送信する。マネージャは、各ノードから送られる各ストリームの帯域幅を、所定のレベルに動的に制御及び設定する手段がある。
【０００８】
本発明は、電気通信ネットワークにおいて帯域幅を制御する方法に関する。その方法は、帯域幅マネージャと、Ｎ個のノードを有するネットワークとが通信する工程を具えており、ここで、Ｎは、３より大きい又は３と等しい整数である。Ｎ個のノードの各ノードは、それに対応しており、帯域幅を有する独自のビデオストリームと、それに対応しており、帯域幅を有する独自のオーディオストリームとを生成可能であって、それらストリームを、Ｎ個のノードのその他のノードにネットワークを介して送信する。帯域幅マネージャを用いて、各ノードから送られる各ストリームの帯域幅を、所定のレベルに動的に制御及び設定する工程がある。
【０００９】
本発明は、会議を開催する電気通信システムに関する。システムは、ネットワークを具えている。システムは、ネットワークを通じて相互に通信するＮ個のノードを具えている。ここで、Ｎは、３より大きい又は３と等しい整数である。各ノードは、それに対応する独自の少なくとも１つのビデオストリームと、それに対応する独自のオーディオストリームとを生成可能であって、それらストリームを、Ｎ個のノードのその他のノードにネットワークを介して送信する。各ノードの各ストリームの帯域幅は、所定のレベルに動的に制御及び設定される。各ノードは、その他の任意のノードから任意のストリームを選択的に受信できる。
【００１０】
本発明は、電気通信システムにおいて会議を開催する方法に関する。その方法は、ネットワークを通じて相互に通信するＮ個のノードの各々で、それに対応する独自の少なくとも１つのビデオストリームと、それに対応する独自のオーディオストリームとを生成して、Ｎ個のノードのその他のノードにネットワークを介して送信する工程を含んでいる。ここで、Ｎは、３より大きい又は３と等しい整数である。各ノードで、その他の任意のノードから送られた任意のストリームを選択的に受信する工程がある。
【００１１】
本発明は、ビデオフォンに関する。ビデオフォンは、シーンが夫々異なる複数のビデオストリーム及びオーディオストリームの中の任意のストリームを、ネットワークから選択的に受信する手段を具えている。ビデオフォンは、選択したオーディオストリームを表示し、選択したオーディオストリームを聴く手段を具えている。
【００１２】
本発明は、ビデオコールをする方法に関する。その方法は、シーンが夫々異なる複数のビデオストリーム及びオーディオストリームの中の任意のストリームを、ビデオフォンにて、ネットワークから選択的に受信する工程がある。選択したオーディオストリームを表示し、選択したオーディオストリームを聴く工程がある。
【発明を実施するための最良の形態】
【００１３】
図面を参照すると、幾つかの図を通じて類似又は同様の部分には同じ符号が付されている。特に、図２２を参照すると、会議開催用の電気通信システムが示されている。システムは、ネットワーク(40)を具えている。システムは、ネットワーク(40)を通じて相互に通信するＮ個のノードを具えている。ここで、Ｎは、３より大きい又は３と等しい整数である。Ｎ個のノードの各ノードは、それに対応しており、帯域幅を有する独自のビデオストリームと、それに対応しており、帯域幅を有する独自のオーディオストリームとを生成可能であって、それらストリームを、Ｎ個のノードのその他のノードにネットワーク(40)を介して送信する。各ノードの各ストリームの帯域幅は、所定のレベルに動的に制御及び設定される。システムは、ネットワーク(40)を通じてＮ個のノードと通信する帯域幅マネージャ(16)を含んでおり、該帯域幅マネージャ(16)は、各ノードから送られる各ストリームの帯域幅を制御するのが好ましい。
【００１４】
本発明は、電気通信システムにおいて会議を開催する方法に関する。その方法は、ネットワーク(40)を通じて相互に通信するＮ個のノードの各々で、それに対応しており、帯域幅を有する独自のビデオストリームと、それに対応しており、帯域幅を有する独自のオーディオストリームとを生成して、Ｎ個のノードのその他のノードにネットワーク(40)を介して送信する工程を含んでいる。ここで、Ｎは、３より大きい又は３と等しい整数である。各ノードから送られる各ストリームの帯域幅を、所定のレベルに動的に制御及び設定する工程がある。
【００１５】
本発明は、帯域幅マネージャ(16)に関する。マネージャは、Ｎ個のノードがあるネットワーク(40)と通信する手段を具えている。ここで、Ｎは、３より大きい又は３と等しい整数である。Ｎ個のノードの各ノードは、それに対応しており、帯域幅を有する独自のビデオストリームと、それに対応しており、帯域幅を有する独自のオーディオストリームとを生成可能であって、それらストリームを、Ｎ個のノードのその他のノードにネットワーク(40)を介して送信する。マネージャには、各ノードから送られる各ストリームの帯域幅を、所定のレベルに動的に制御及び設定する手段がある。
【００１６】
本発明は、電気通信ネットワーク(40)において帯域幅を制御する方法に関する。その方法は、帯域幅マネージャ(16)と、Ｎ個のノードを有するネットワーク(40)とが通信する工程を具えており、ここで、Ｎは、３より大きい又は３と等しい整数である。Ｎ個のノードの各ノードは、それに対応しており、帯域幅を有する独自のビデオストリームと、それに対応しており、帯域幅を有する独自のオーディオストリームとを生成可能であって、それらストリームを、Ｎ個のノードのその他のノードにネットワーク(40)を介して送信する。帯域幅マネージャ(16)を用いて、各ノードから送られる各ストリームの帯域幅を、所定のレベルに動的に制御及び設定する工程がある。
【００１７】
図２２に示すように、本発明は、会議を開催する電気通信システムに関する。帯域幅マネージャ(16)は、この実施例に必須ではない。システムは、ネットワーク(40)を具えている。システムは、ネットワーク(40)を通じて相互に通信するＮ個のノードを具えている。ここで、Ｎは、３より大きい又は３と等しい整数である。各ノードは、それに対応する独自の少なくとも１つのビデオストリームと、それに対応する独自のオーディオストリームとを生成可能であって、それらストリームを、Ｎ個のノードのその他のノードにネットワーク(40)を介して送信する。各ノードの各ストリームの帯域幅は、所定のレベルに動的に制御及び設定される。各ノードは、その他の任意のノードから任意のストリームを選択的に受信できる。
【００１８】
本発明は、電気通信システムにおいて会議を開催する方法に関する。その方法は、ネットワーク(40)を通じて相互に通信するＮ個のノードの各々で、それに対応する独自の少なくとも１つのビデオストリームと、それに対応する独自のオーディオストリームとを生成して、Ｎ個のノードのその他のノードにネットワーク(40)を介して送信する工程を含んでいる。ここで、Ｎは、３より大きい又は３と等しい整数である。各ノードで、その他の任意のノードから送られた任意のストリームを選択的に受信する工程がある。
【００１９】
図２３に示すように、本発明は、ビデオフォン(15)に関する。ビデオフォン(15)は、シーンが夫々異なった複数のビデオストリーム及びオーディオストリームの中の任意のストリームを、ネットワーク(40)から選択的に受信する手段を具えている。ビデオフォン(15)は、選択したオーディオストリームを表示し、選択したオーディオストリームを聴く手段を具えている。
【００２０】
本発明は、ビデオコールをする方法に関する。その方法は、シーンが夫々異なる複数のビデオストリーム及びオーディオストリームの中の任意のストリームを、ビデオフォン(15)にて、ネットワーク(40)から選択的に受信する工程がある。選択したオーディオストリームを表示し、選択したオーディオストリームを聴く工程がある。
【００２１】
システム(10)は、第１ノード(80)と、第２ノード(82)と、少なくとも第３ノード(84)とを具えており、それらは、ネットワーク(40)を通じて相互に通信するＮ個のノードに含まれている。第１ノード(80)は、該第１ノード(80)でのシーンの第１ビデオストリームと、該第１ノード(80)でのシーンの第２ビデオストリームと、該第１ノード(80)でのシーンのオーディオストリームとを、第２及び第３ノード(82)(84)に送る。第２及び第３ノード(82)(84)は、オーディオストリームと、第１ビデオストリーム又は第２ビデオストリームの何れか一方とを再生する。
【００２２】
第１ビデオストリームのフレームレートは、１秒当たり２５フレームよりも大きく、第２ビデオストリームのフレームレートは、１秒当たり２５フレームよりも小さいのが好ましい。第１ビデオストリームのビットレートは、１秒当たり１.５Ｍｂｉｔｓよりも大きく又はそれに等しく、第２ビデオストリームのフレームレートは、１秒当たり１.５Ｍｂｉｔｓよりも小さいのが好ましい。第２及び第３ノード(82)(84)は、ディスプレイスクリーンを有しているのが好ましく、第２又は第３ノード(82)(84)が第１ビデオストリームを表示する場合、それらは、スクリーンの２０％より大きい又はそれに等しい領域に亘る大きな画像として、第１ビデオストリームを表示し、第２及び第３ノード(82)(84)が第２ビデオストリームを表示する場合、それらは、スクリーンの２０％より小さい領域に亘る小さな画像として、第２ビデオストリームを表示する。システム(10)は、ネットワーク(40)を通じて、第１、第２及び第３ノード(80)(82)(84)と通信する第４ノードを含むのが好ましく、該第４ノードは、第１、第２及び第３ノード(84)に、テレビジョンチャンネルのテレビジョンビデオストリームを送信する。第１、第２及び第３ノード(80)(82)(84)は、第１ビデオストリームと並べてテレビジョンビデオストリームをスクリーンに表示できる。
【００２３】
第２ノード(82)は、該第２ノード(82)のシーンの第１ビデオストリームと、該第２ノード(82)のシーンの第２ビデオストリームと、シーンのオーディオストリームとを、第３ノード(84)に送る。第３ノード(84)は、ディスプレイコントローラ(52)を有しており、該ディスプレイコントローラ(52)は、スクリーンに表れる画像を制御して、各ノードから送られる第１ビデオストリームの各々を、第３ノード(84)のスクリーンに並べて再生する。ネットワーク(40)は、イーサネット又はＡＴＭネットワーク(40)であるのが好ましい。第１及び第２ノード(80)(82)の第１ビデオストリーム、第２ビデオストリーム及びオーディオストリームは、ビデオ会議コール用の会議ブリッジやＭＣＵを用いることなく、ビデオ会議コール用にネットワーク(40)に送られるのが好ましい。各ノードは、ビデオ会議コール用に、ＡＴＭポイントツーマルチポイントストリームを用いるのが好ましい。
【００２４】
第３ノード(84)は、第１若しくは第２ノード(80)(82)から送られる第１又は第２ビデオストリームのどれを表示するかを予め決定するのが好ましい。第１若しくは第２ノード(80)(82)における各々のシーンでユーザが話している場合、又は、第３ノード(84)が第１若しくは第２ノード(80)(82)から送られる第１ビデオストリームを表示することを予め決定していた場合、第３ノード(84)は、第１又は第２ノード(80)(82)から送られる第１ビデオストリームを表示することを選択する。第１及び第２ノード(82)から送られる第１ビデオストリームは、ネットワーク(40)で送られる場合に、ＭＰＥＧ−２フォーマットのような所望のフォーマットであるのが好ましい。第１及び第２ノード(82)は、コンティニュアスＰ(continuous P)を用いて、第１及び第２ノード(82)の第１ビデオストリームを、ＭＰＥＧ−２フォーマットにするのが好ましい。第１及び第２ノード(82)は、第１及び第２ノード(80)(82)のシーンの第１ビデオストリームを夫々クリップするのが好ましい。
【００２５】
第１及び第２ノード(80)(82)は、各々のシーンにて、ユーザがいない場所に関する部分を第１ビデオストリームから除去することで、各々のシーンの第１ビデオストリームをクリップするのが好ましい。各々のシーンにてノイズが閾値を超える場合にのみ、第１及び第２ノード(80)(82)は、第１及び第２ノード(80)(82)のシーンのオーディオストリームを夫々送るのが好ましい。第１ノード(80)は、自動的なプレゼンスセンサを有しており、該センサは、第１ノード(80)のシーンにユーザがいるか否かを判断して、ユーザが第１ノード(80)にいるか否かを示すプレゼンスインジケータを生成するのが好ましい。第１ノード(80)は、第２及び第３ノード(82)(84)にプレゼンスインジケータを送るのが好ましい。第１ノード(80)は、警告信号を生成して、第１ノード(80)のシーンのあらゆるユーザに、プレゼンスインジケータが所定の時間内に作られようとしていることを警告するのが好ましい。
【００２６】
第１ノード(80)は、第１シーンのビデオ画像を得て、ビデオストリームを生成する撮像手段を含むのが好ましい。システム(10)は、撮像手段と通信するエンコーダ(36)を含んでおり、該エンコーダ(36)は、フレームバッファリングを行うことなく、第１ビデオストリームをＭＰＥＧ−２フォーマットに圧縮及びエンコードするのが好ましい。第１ノード(80)は、エンコーダ(36)と通信するフィールドプログラマブルゲートアレイ(38)を含み、該フィールドプログラマブルゲートアレイ(38)は、第１ビデオストリームをパケット化するのが好ましい。また、フィールドプログラマブルゲートアレイ(38)は、撮像手段から第１ビデオストリームを受信し、第１ノード(80)の第２ビデオストリームを生成し、その第２ビデオストリームをパケット化するのが好ましい。第１ノード(80)は、フィールドプログラマブルゲートアレイ(38)及びネットワーク(40)と通信するネットワークインターフェイス(42)を含んでおり、第１ノード(80)の第１ビデオストリームをネットワーク(40)に転送し、第２ノード(82)から第１ビデオストリームを受信し、それをフィールドプログラマブルゲートアレイ(38)に送るのが好ましい。
【００２７】
第１ノード(80)は、第１シーンの音声を受け取って、第１ノード(80)のオーディオストリームを生成するマイクロホン手段を具えているのが好ましい。第１ノード(80)は、ネットワークインターフェイス(42)と通信して、第２ノード(82)から送られるオーディオストリームを再生するスピーカ手段を具えるのが好ましい。第１ノード(80)は、ＤＳＰ(62)を含んでおり、該ＤＳＰ(62)は、第１ノード(80)のオーディオストリームをパケット化し、そのオーディオストリームをフィールドプログラマブルゲートアレイ(38)に与えるのが好ましい。フィールドプログラマブルゲートアレイ(38)は、第１ノード(80)のオーディオストリームをネットワークインターフェイス(42)に転送し、該ネットワークインターフェイス(42)は、第１ノード(80)のオーディオストリームをネットワーク(40)に転送する。また、ＤＳＰ(62)は、第２ノード(82)のオーディオストリームをフィールドプログラマブルゲートアレイ(38)から受信する。第１ノード(80)は、オーディオインターフェイス(60)を含んでおり、該オーディオインターフェイス(60)は、マイクロホン手段から第１ノード(80)のオーディオストリームを受信して、それをデジタル化してＤＳＰ(62)に与えるのが好ましい。オーディオインターフェイス(60)は、ＤＳＰ(62)から受信した第２ノード(82)のオーディオストリームを、スピーカ手段が再生できるようにアナログ形式に変換するのが好ましい。
【００２８】
ネットワークインターフェイス(42)は、第１ノード(80)のオーディオストリーム及びビデオストリームのパケットに、それらがネットワーク(40)に送られる前にタイムスタンプを付すのが好ましい。また、ネットワークインターフェイス(42)は、タイムスタンプを用いて、第１ノード(80)が受信した第２ノード(82)のビデオストリーム及びオーディオストリームのパケットを並べるのが好ましい。これによって、第２ノード(82)のビデオストリーム及びオーディオストリームが、第１ノード(80)で再生される場合に、第２ノード(82)のシーンの画像に関連した音声が再生される。システム(10)は受信メモリを含むのが好ましく、第２ノード(82)から送られる第１ビデオストリームは、受信メモリに受信及び格納される。また、システム(10)は、ネットワークインターフェイス(42)と、エンコーダ(36)と、フィールドプログラマブルゲートアレイ(38)と、ＤＳＰ(62)とに接続されて、それらを制御するメインコントローラ(50)を含むのが好ましく、メインコントローラ(50)がネットワークインターフェイス(42)に指示すると、第２ノード(82)の第１ビデオストリームが選択されて、それが受信メモリに送られる。メインコントローラ(50)は、受信メモリに格納された第２ノードの第１ビデオストリームをデコード及び伸張して、それをディスプレイコントローラ(52)に送る。
【００２９】
第１ノード(80)は、ディスプレイコントローラ(52)に接続されたＬＣＤコントローラを含んでおり、ディスプレイスクリーンは、ＬＣＤコントローラに接続されたパネルディスプレイを含んでいるのが好ましい。ＬＣＤコントローラは、ディスプレイコントローラ(52)から第２ノード(82)の第１ビデオストリームを受信し、第２ノード(82)の第１ビデオストリームをパネルに表示する準備をする。システム(10)は、タッチスクリーンを含んでいるのが好ましく、該スクリーン上には機能に関連したボタンがあり、タッチスクリーン及びメインコントローラ(50)に接続されたタッチスクリーンコントローラは、ユーザによってタッチスクリーン上でタッチされたボタンに関する情報をメインコントローラ(50)に転送する。第１ノード(80)は、デコーダ(34)を含むのが好ましく、該デコーダ(34)は、撮像手段から送られた第１ノード(80)のシーンの第１ビデオストリームを、デジタル形式に変換して、それをエンコーダ(36)及びフィールドプログラマブルゲートアレイ(38)に与える。デコーダ(34)は、フィールドプログラマブルゲートアレイ(38)及びエンコーダ(36)に接続されており、テレビジョンビデオストリーム及びその他のアナログ形式のストリームも受信して、それらをデジタル形式に変換するのが好ましい。
【００３０】
カメラ手段は、デコーダ(34)と通信するアナログビデオカメラを、エンコーダ(36)及びフィールドプログラマブルゲートアレイ(38)と通信するデジタルビデオカメラを、又は、フィールドプログラマブルゲートアレイ(38)と通信するファイヤライン(fire wire)カメラを具えているのが好ましい。フィールドプログラマブルゲートアレイ(38)は、ファイヤラインカメラから受信した任意のビデオストリームをエンコーダ(36)に送る。ＤＳＰ(62)は、第１ノード(80)のシーンのオーディオストリームにステレオエコーキャンセルを行うのが好ましい。エンコーダ(36)は、第１ノード(80)の第１ビデオストリームの解像度を少なくとも７２０×６４０ピクセルとするのが好ましく、マイクロホン手段及びスピーカ手段は全二重であるのが好ましい。ＤＳＰ(62)は、スピーカ手段で生成されたノイズのレベルについてマイクロホン手段をモニタして、所望のノイズレベルを維持するようにスピーカ手段を調整するのが好ましい。メインコントローラ(50)は、ユーザのコマンドを認識して、ビデオ会議のために別のユーザに自動的にコールをし、そのコマンドを用いて、その他のユーザに、彼らがビデオ会議にリクエストされている旨をアナウンスするのが好ましい。
【００３１】
第１ノード(80)がビデオコールを受け入れられない場合に、第１ノード(80)にビデオメールが有るのが好ましい。システム(10)はサーバ(66)を含んでおり、該サーバ(66)は、ネットワーク(40)及び第１ノード(80)と通信し、第１ノード(80)がビデオコールを受信しない場合に、第１ノード(80)のためにビデオコールを受信するのが好ましい。そして、サーバ(66)は、第１ノード(80)が受信しないビデオコールに関連したビデオメッセージを格納して、第１ノード(80)で見られることを待っているビデオメッセージがある旨のビデオコール待ちメッセージを、第１ノード(80)に送る。第１ノード(80)には、ディスプレイコントローラ(52)に接続された複数のディスプレイパネルがあるのが好ましく、異なるノードから送られた第１ビデオストリームの画像は、それら複数のパネルが１つの連続的なパネルであるかのように、並べてパネルに表示されるのが好ましい。第１ノード(80)は、第２撮像手段を含んでおり、該手段は、第１ノード(80)のシーンの眺めが第１撮像手段と異なっている第１ノード(80)の第１ビデオストリームを生成するのが好ましい。メインコントローラ(50)は、フィールドプログラマブルゲートアレイ(38)から送られる第１ノード(80)の第２ビデオストリームをディスプレイコントローラ(52)に送り、該ストリームは、第１ノード(80)のユーザがディスプレイパネル上で第１ノード(80)のシーンが見られるように、パネルに表示されるのが好ましい。第１ノード(80)、第２ノード(82)及び第３ノード(84)は、ビデオフォン(15)を含むのが好ましい。第１ノード(80)、第２ノード(82)及び第３ノード(84)は、ビデオフォン(15)と通信するＰＣ(68)を含むことができる。
【００３２】
本発明の動作について説明する。
【００３３】
概要
[範囲]
帯域幅マネージャ(16)は、ＶｉＰｒ２サーバシステムの一部であって、物理的及び論理的ネットワークの境界及びタイプに亘ってＲＴＰ/ＡＶＰメディアフローを制御することで、ＳＩＰ[引用をもって本明細書の一部となる"J. Rosenberg, H. Schulzrinne, et. al., RFC3261: Session Initiation Protocol, 2002"を参照のこと]ユーザエージェント(例えば、ＶｉＰｒ端末)による帯域幅の使用を制限するように設計されている。帯域幅マネージャ(16)は、エンドポイント間のメディアフローのパスに直接存在するのではなく、セッション開始プロトコル(ＳＩＰ)シグナリングコールセットアップパスに含まれる。ソース及びデスティネーションネットワークは、ＳＩＰリクエストから決定される一方で、帯域幅の使用は、ＳＩＰリクエストに含まれるセッション記述プロトコル(ＳＤＰ[引用をもって本明細書の一部となる"M. Handley, V. Jacobson, RFC2327:, 1998"を参照のこと])から決定される。
【００３４】
[アーキテクチャ]
帯域幅マネージャ(16)の実施について考慮される２つの主要なオプションがある。即ち、それが、ＳＩＰプロキシーの一部として実施されるか否かと、バックツーバックＳＩＰユーザエージェント(Ｂ２ＢＵＡ)の一部として実施されるか否かということである。Ｂ２ＢＵＡオプションがより有利であるという判断がなされたが、この判断に至る２つのオプションに関する種々の利点及び不都合は、以下にて説明される。プロキシーとＢ２ＢＵＡとの間の大きな差は、Ｂ２ＢＵＡは、新しいコールを確立するのに対して、プロキシーは、ＩＮＶＩＴＥのトランザクションを単にフォワードすることである。本事例の帯域幅マネージャ(16)は、Ｂ２ＢＵＡアーキテクチャを用いている。
【００３５】
[Ｂ２ＢＵＡの実施]
ＲＦＣ３２６１[引用をもって本明細書の一部となる"J. Rosenberg, H. Schulzrinne, et. al., RFC3261: Session Initiation Protocol, 2002"を参照のこと]は、以下のようにＢ２ＢＵＡを規定する。
【００３６】
バックツーバックユーザエージェント：バックツーバックユーザエージェント(Ｂ２ＢＵＡ)は、リクエストを受信して、ユーザエージェントサーバ(ＵＡＳ)としてそれを処理する論理エンティティである。そのリクエストにどのようにレスポンスすべきかを決定するために、それは、ユーザエージェントクライアント(ＵＡＣ)として機能し、リクエストを生成する。プロキシーサーバとは異なって、それは、ダイアログステートを維持しており、それが確立したダイアログに送られる全てのリクエストに関与する必要がある。それはＵＡＣ及びＵＡＳの連結であるから、その作用について、説明的な定義は必要とされない。
【００３７】
典型的な２つのＵＡであるクライアント側(ＵＡＣ)及びサーバ側(ＵＡＳ)によるＢ２ＢＵＡのインタラクションは、次のように要約される(アンダーラインを引いた太字のＢ２ＢＵＡ)：
ＵＡＣ−−−＞ＵＡＳ(ｂ２ｂ)＝＝＝[アプリケーションロジック]＝＝＝ＵＡＣ(ｂ２ｂ)−−−＞ＵＡＳ
【００３８】
Ｂ２ＢＵＡが、ＵＡＳ及びＵＡＣのＲＦＣ３２６１要求の全てを満足する限りにおいて、Ｂ２ＢＵＡの「アプリケーションロジック」は、創意によってのみ制限される。
【００３９】
Ｂ２ＢＵＡは、コールステートフルであるので、プロキシーよりも容易に、コールを再ネゴシエーション/ドロップできる。基本的に、Ｂ２ＢＵＡは、新しいコールを確立し、オリジナルのリクエストから情報の大半をコピーする(例えば、Ｒｅｑｕｅｓｔ−ＵＲＩ、Ｆｒｏｍ  ＵＲＩ、Ｔｏ  ＵＲＩ)。
【００４０】
帯域幅マネージャ(16)とインタラクトする全てのＳＩＰエンティティは、以下の規格に完全に準拠していると仮定される。
・  ＲＦＣ３２６１−セッション開始プロトコル
・  ＲＦＣ２３２７−セッション記述プロトコル
【００４１】
帯域幅マネージャ(16)とインタラクトするＳＩＰエンティティには、ＳＩＰプロシキサーバと、ＳＩＰユーザエージェントとがある。
【００４２】
これらの規格から逸脱することは、帯域幅マネージャ(16)に負の影響を与えるだろう。ロバストな実施のためにあらゆる試みがされる一方で、不適当なＳＩＰ若しくはＳＤＰを用いた、又は不適当な働きをするエンティティによって、例えば以下のような、かなり多数のエラー状態が起こるだろう。
・  コールセットアップの失敗
・  帯域幅の不適切な検出
【００４３】
外的ブレークダウン
図３は、帯域幅マネージャ(16)の規則定義の基礎を示す。２又は３以上のネットワークがＩＰ及びポートレンジで規定されている。これらのネットワークは、デスティネーションについてＲｅｑｕｅｓｔ−ＵＲＩのホスト/ポートに合わせることで、そして、ソースネットワークについて、ＶｉａヘッダのＩＰ/ポートに合わせることで、ＳＩＰリクエストに合致されている。リンクは、ネットワーク間で定義されている。ソース及びデスティネーションネットワークがＳＩＰリクエストに合致されており、リンクがネットワーク間で定義されている場合に、帯域幅マネージャが実行される。
【００４４】
リンクは、帯域幅の制約と共に定義される。これらのリンクに亘るコールがそれらの制約を満たすことを保証することが、帯域幅マネージャ(16)の仕事である。図４は、リンクについて定義された制約の一例を示す。ポリシーは、新しいコールに許される帯域幅を制限して、あるリンク使用閾値にてコールを再ネゴシエーションすることにある。タイプが異なるストリームについて、別個のポリシーがあって良く、ビデオ、オーディオ及びデータ、又はその他のタイプのストリームについて、異なるポリシーが定められてもよい(例えば、ビデオが無くて高帯域幅のオーディオよりも、低帯域幅のビデオと、低帯域幅のオーディオとが、コールで利用されることがより望ましいだろう)。帯域幅マネージャ(16)のこのリリースでは、リンクのポリシーは双方向であって、故に、帯域幅の使用は、リンクに沿った２つの方向について別個にアカウント及び規制されるが(例えば、会議コールにて、リンクの一方の側の参加者を、他方の側よりも多くできる)、リンクに沿った異なる方向について、別個のポリシーは定められない。リンクの帯域幅は、対称的である必要はない。また、非対称的なポリシーを定めることが、設計上可能である。
【００４５】
新しいコールは、以下の２つの方法で、オファーのＳＤＰを変更することで、(現在のリンク使用に基づいて)コール当たりの最大帯域幅に合うように調節される。
・  ＶｉＰｒのビデオストリームについて、ｂ＝帯域幅識別子の値を減らす。
・  より帯域幅の高いオーディオコーデックを削除する。
【００４６】
制約に収まるようにオファーのＳＤＰを変更できない場合(例えば、ある使用閾値を超えて、制約が０の帯域幅を指定する場合)、コールは拒否される。
【００４７】
[Ｂ２ＢＵＡ ＳＩＰメッセージ転送]
帯域幅マネージャ(16)は、「オファー」のＳＤＰだけを変化させて、その帯域幅のアカウンティングプロセスの一部として、アンサーのＳＤＰのみを見る。図６は、帯域幅マネージャ(16)がコールに関与する場合に、ＳＩＰ世界で起こっていることをまとめており、オファー又はアンサーは、新しいコールについてリンクの制限を超えている。
【００４８】
「４８８ Ｎｏｔ Ａｃｃｅｐｔａｂｌｅ」ＳＩＰレスポンスのメッセージは、ワーニングヘッダフィールドを含んでおり、次のように(ＲＦＣ３２６１により)設定できる：
【００４９】
３７０ Ｉｎｓｕｆｆｉｃｉｅｎｔ bａｎｄｗｉｄｔｈ:  セッション記述で指定された又はメディアで定義された帯域幅が、利用可能であると知られている帯域幅を超えている。
【００５０】
ＳＩＰエラーレスポンスコードを受信すると、このワーニングヘッダフィールドが表示されるか否かは、ＳＩＰユーザエージェント次第である。仮に、ＶｉＰｒ端末がＳＩＰエラーレスポンスコードを受信して、(ＳＩＰエラーレスポンスコード及びオプションのワーニングヘッダに基づいて)拡張されたエラー情報を(多分、オプションとして、追加のボタンが押されることで)表示すると、ユーザの知識が増加するであろう。帯域幅マネージャ(16)がＢ２ＢＵＡコールのセットアップをする間、幾つかのリクエストのヘッダフィールドがＵＡＳからＵＡＣに「伝搬されて」、新しいコールが開始される必要がある。これらのヘッダフィールドは、以下を含んでいる。
・  Ｆｒｏｍ
・  Ｔｏ
・  Ｒｅｑｕｅｓｔ−ＵＲＩ
・  Ｅｘｐｉｒｅｓ
・  Ｒｅｑｕｉｒｅ
・これをトランスペアレントに通過させることは簡単ではないので、実際には、Ｂ２ＢＵＡは、(ＵＡＳ仕様に従う必要があるから、とにかくＲＦＣ３２６１で決められるように)Ｒｅｑｕｉｒｅ内の要求に従う必要がある。
・(Ｂ２ＢＵＡをＲｅｑｕｉｒｅが通過することに関して)ＳＩＰメーリングリストに見られるさらなる「エビデンス」：否。できるだけ強調すると：否。これは全くの間違いであり、それは、増加している危険な誤解に見える。Ｂ２ＢＵＡは、Ｒｅｑｕｉｒｅをトランスペアレントに通過させることはできない。それは、指示されたエクステンションを理解して呼び出す必要がある。
・ジョナサン ローゼンベルグ：私のｂ２ｂｕａは、あらゆる面でプロキシーであると仮定するが、ＳＤＰをいじくってファイヤーウォールを超えることが起こり得る。確かに、それはＲｅｑｕｉｒｅを無視できるが、正しいのか？  間違いである。私は、エクステンションフー(foo)を定義する。それは、「このＳＤＰのコンテントは、見掛けと異なる。メディアの本当のポート/アドレスを見つける代わりに、このヘッダを見よ」を意味する。このエクステンションは、(ＵＡはおよそボディを見るから)Ｒｅｑｕｉｒｅを必要とするが、プロキシーが行わないことから、Ｐｒｏｘｙ-Ｒｅｑｕｉｒｅを必要としない。従って、あなたの一種のプロキシーは、無視すべきでなかった時にＲｅｑｕｉｒｅを無視したので、奇妙な方法で機能しなくなるだろう。
・  (ＢＷ制約による)ＳＤＰ
帯域幅マネージャ(16)によって、ＳＤＰは、「オファー」方向について変えられてもよい。変化は、ｂ＝ラインの値を低減し、受信パーティリストを変更し、より帯域幅が高いコーデックタイプをオファーから削除することを含む。これらのヘッダは、Ｃｏｎｔｅｎｔ−Ｔｙｐｅ、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ、Ｃｏｎｔｅｎｔ−Ｄｉｓｐｏｓｉｔｉｏｎ、Ｃｏｎｔｅｎｔ−Ｌａｎｇｕａｇｅ及びＣｏｎｔｅｎｔ−Ｅｎｃｏｄｉｎｇを含む。
・  ＭａｘＦｏｒｗａｒｄｓ−−プロキシーに関する「コピー及び減少」ロジックと類似しており、帯域幅マネージャ(16)を介したループを防止する。ＵＡＳ側に到着したリクエストは、Ｍａｘ-Ｆｏｒｗａｒｄｓヘッダを有しておらず、ＵＡＣ側の新しいＩＮＶＩＴＥが、７０をデフォルト値として、Ｍａｘ-Ｆｏｒｗａｒｄｓヘッダで生成される。Ｍａｘ-Ｆｏｒｗａｒｄｓヘッダが存在せず、値がゼロである場合、コールセットアップは、４８３ Ｔｏｏ Ｍａｎｙ Ｈｏｐｓレスポンスで拒絶されて、さもなれば、その値は、コピー及び減少されて、ＵＡＣ側の新しいＩＮＶＩＴＥにて用いられる。
【００５１】
伝搬されない幾つかのフィールドも存在する、これらのフィールドは、以下を含む。
・  Ｃｏｎｔａｃｔ
このヘッダは、エンドポイントのアドレスを指定しており、Ｂ２ＢＵＡでは、ＵＡＣ及びＵＡＳ側が達してよいアドレスを反映すべきである。即ち、ＵＡＣ側上の新たなＩＮＶＩＴＥのＣｏｎｔａｃｔヘッダは、ＵＡＣが達してよいアドレスを反映し、ＵＡＳ側上の最初のファイナルレスポンスのＣｏｎｔａｃｔヘッダは、ＵＡＳが達してよいアドレスを反映する。これらの２つのアドレスは、だぶん同じであろう。これが行われることで、ダイアログコンテキスト内のさらなるリクエスト(例えば、ＲＥＦＥＲ、ＢＹＥ等)が、帯域幅マネージャ(16)を介して正しくルーティングされることを保証される。
・  Ｃａｌｌ-ＩＤ及びＴｏ/Ｆｒｏｍタグ
これらは、ＵＡＣ側の新しいコールで生成されて、ＵＡＳ側のコールにて対応するヘッダには関係しない。
・  Ｖｉａリスト
・  Ｒｅｃｏｒｄ-Ｒｏｕｔｅ
・  Ｒｏｕｔｅ
ルーズルーティングのためには、ＵＡＳ側のオリジナルのＩＮＶＩＴＥにあるＲｏｕｔｅヘッダを調べるのが望ましく、ＵＡＳ側の新しいＩＮＶＩＴＥのために、ルートセットを構築するのに用いられてよい。
・  Ｃｓｅｑ
【００５２】
幾つかの独自仕様のフィールドが存在してよい。それらは重要なエンドツーエンドであって、全てのヘッダフィールドがオリジナルメッセージからコピーされて、(リクエスト及びレスポンスの)新しいメッセージが送信される前に、置換が必要であることが知られたヘッダのみが除かれて置き換えられる方法で、Ｂ２ＢＵＡが実施されることが非常に望ましい。
【００５３】
データ記述
[コーデックルックアップテーブル]
帯域幅使用は、各メディアブロックにおけるオプションのｂ＝識別子から判断される。この識別子が存在しない場合、帯域幅マネージャ(16)は、特定された各コーデックタイプに基づいて帯域幅使用を見積もる必要がある。これを助けるために、公知の多数のコーデックタイプについてルックアップテーブルが定義される。各コーデックタイプは、使用する帯域幅がｋｐｓで特定されており、さらに、オプションのアディティブ(additive)及びマルチプリカティブ(mulitiplicative)変更子を有しており、オーバーヘッドが考慮されえいる(例えば、ＵＤＰ/ＩＰ、ＡＴＭ、ＲＴＰ/ＡＶＰ等)。
【００５４】
セッション記述プロトコル[]引用を以て本明細書の一部となる"M. Handley, V. Jacobson, RFC2327:, 1998"]
セッション記述プロトコル(ＳＤＰ)は、設定されるメディアストリームのプロパティを記述するために、ＳＩＰで使用される。プロパティは、送信パラメータ(例えば、ＩＰアドレス及びポート)と、各メディアタイプ(ビデオ及びオーディオメディアタイプのみが、帯域幅マネージャ(16)にて扱われる)についてのコーデックオプション(例えば、ＧＳＭ、ＰＣＭＵ、ＭＰＥＧ等)と、各メディアタイプについての帯域幅の指定とを含んでいる。
【００５５】
図７は、注記付きのＳＤＰのサンプルであって、帯域幅マネージャについて重要な部分が、強調表示されている。「M. Handley, V. Jacobson, RFC2327:, 1998」には以下の事が記載されている。
【００５６】
アナウンスメントは、セッション−レベルセクションと、その後にあるゼロ又は１以上のメディア−レベルセクションとで構成される。セッション−レベル部分は、「ｖ＝」ラインで始まって、その後に、最初のメディア−レベルセクションがある。メディアの記述は「ｍ＝」ラインで始まって、次のメディアの記述、又は全セッションの記述のエンドに続く。一般に、セッション−レベルの値は、同等なメディア−レベルの値で上書きされない限り、全てのメディアについてデフォルトの値になっている。
【００５７】
各メディアの記述は、メディアタイプで開始されて、本明細書では、「オーディオ」及び「ビデオ」メディアタイプのみが考慮される。次のサブフィールドは、メディアストリームが供給されるべき送信ポートである。このポートは、その値が０に設定されると、その特別なメディアストリームがセッションの継続期間に中止される場合を除いて、帯域幅マネージャにとっては重要でない。
【００５８】
「ｃ＝」ラインは、「ｃ＝＜ネットワークタイプ＞＜アドレスタイプ＞＜コネクションアドレス＞」の形式の接続情報を含んでいる。マルチキャストコネクションアドレスは、例えば、２２４.２.１.１/１２７のように、アドレスの後にＴＴＬ値を含む必要があるが、/ＴＴＬシンタックスは、ユニキャストアドレスについて不正である。
【００５９】
オプションの「ｂ＝」ライン(ｂ＝＜変更子＞:＜帯域幅−値＞)は、セッション又はメディアで使用される帯域幅案を指定する。＜帯域幅−値＞は、キロビット/秒で特定される。＜変更子＞は、英数字の１つのワードであって、帯域幅の形態を意味しており、ＣＴ(conference total)若しくはＡＳ(application specific)として設定され、又は、「Ｘ−」で開始する変更子を用いる独自の方式に拡張される。引用を以て本明細書の一部となる[M. Handley, V. Jacobson, RFC2327:, 1998]によると、以下の通りである：
【００６０】
ＣＴは、全てのサイトでの全てのメディアについてトータルの帯域幅の数量を与える。ＡＳは、１つのサイトでの１つのメディアについて帯域幅の数量を与えるが、同時に送信する多くのサイトがあってもよい。
【００６１】
ゼロの値は許されるが、推奨されない。それは、送られるべきメディアがないことを示す。ＲＴＰの場合、全てのＲＴＣＰは無効にされるだろう。
【００６２】
ＳＤＰのセッションレベルには、様々な必須フィールドがあるが、それらは、帯域幅管理ついては重要であると認識されないだろう。それらのフィールドは「ｖ＝」(プロトコルバージョン)、「ｏ＝」(オーナー/クリエーター及び識別子)、「ｓ＝」(セッション名)及び「ｔ＝」(セッションタイム、オファー/アンサーのＲＦＣ３２６４［引用を以て本明細書の一部となる"J. Rosenberg, H. Schulzrinne, RFC3264: An Offer/Answer Model with the Session Description Protocol (SDP), 2002"は、ＳＩＰに含まれるＳＤＰについて、「ｔ＝」は「０ ０」と設定されるべきと記している。)
【００６３】
「ａ＝」属性ラインは、プロパティ属性(ａ＝＜フラグ＞)又は値属性(ａ＝＜属性＞：＜値＞)の何れかを示す。関連する重要なプロパティフラグは、ｒｅｃｖｏｎｌｙ、ｓｅｎｄｒｅｃｖ、ｓｅｎｄｏｎｌｙ及びｉｎａｃｒｉｖｅであって、これらはメディアフローの方向を示す。
【００６４】
引用を以て本明細書の一部となる[M. Handley, V. Jacobson, RFC2327:, 1998]にて定められており、ＡＢＮＦに従った＜属性＞に許されるキャラクタは、数字０−９と、大文字及び小文字のアルファベットであるが、その仕様のさらに後では、「属性の名称は、ＩＳＯ−１０６４６/ＵＴＦ−８のＵＳ−ＡＳＣＩＩのサブセットでなければならない」と記載されている。ユーザ定義された＜属性＞名は、「Ｘ−」で開始されなければならないが、ＶｉＰｒも、「Ｘ＿」をユーザ定義属性名に使用している。この議論に用いられる所定の値の属性の１つは、「ａ＝タイプ：＜会議タイプ＞」であって、通常、会議コールのセッションレベルでは「ａ＝タイプ：ｍｅｅｔｉｎｇ」が、設定される。
【００６５】
オファー/アンサーのＲＦＣ［引用を以て本明細書の一部となる"J. Rosenberg, H. Schulzrinne, RFC3264: An Offer/Answer Model with the Session Description Protocol (SDP), 2002"]は、特に、それがＳＩＰでの利用に適用される際に、ＳＤＰに関連するさらなる情報を含む。ＳＩＰセッションは、２つのパーティの間におけるＩＮＶＩＴＥ/ＯＫ/ＡＣＫの交換で開始される。ＳＩＰに含まれるＳＤＰには、２つのオファー/アンサーモデルがある。
−  ＩＮＶＩＴＥはオファーＳＤＰを含み、ＯＫはアンサーＳＤＰを含む。
−  ＩＮＶＩＴＥはＳＤＰを含まず、ＯＫはアンサーＳＤＰを含み、ＡＣＫは、アンサーＳＤＰを含む。
引用を以て本明細書の一部となる"J. Rosenberg, H. Schulzrinne, RFC3264: An Offer/Answer Model with the Session Description Protocol (SDP), 2002"によると、以下の通りである：
【００６６】
オファー内の各「ｍ＝」ラインについて、対応する「ｍ＝」ラインが、アンサー内に存在する必要がある。アンサーは、厳密にオファーと全く同じ数の「ｍ＝」ラインを含む。これによって、ストリームは、それらオーダーに基づいて組み合わされる。これは、オファーが含む「ｍ＝」ラインがゼロである場合、アンサーが含む「ｍ＝」ラインはゼロであることを意味する。
【００６７】
オファーされたストリームは、何らかの理由でアンサーにて拒否されてもよい。ストリームが拒否される場合、オファー側とアンサー側は、そのストリームについてメディア(又はＲＴＣＰパケット)を生成してはならない。オファーされたストリームを拒否するためには、アンサーにおける対応するストリームのポート番号は、ゼロに設定される必要がある。
【００６８】
リストされた如何なるメディアフォーマットも無視される。少なくとも１つは、ＳＤＰで特定されたように、存在している必要がある。
【００６９】
同じタイプの複数のメディアがオファーにある場合、それは、オファー側が、そのタイプの複数のストリームを同時に送る(及び/又は受信する)ことを希望していることを意味する。特定のメディアタイプについてユーザが１つのソースを有している場合、唯一のポリシーのみが意味をなす：ソースは、同じタイプの各ストリームに送られて、同じタイプの複数のストリームを受信する意図は、単に１つを選択するよりも、それらは全て並行に存在すべきというものである。
【００７０】
オファー/アンサーのＲＦＣでは、ユニキャスト及びマルチキャストについて幾つかの差異がある：
【００７１】
１．ユニキャスト
ストリームがｓｅｎｄｏｎｌｙとしてオファーされる場合、対応するストリームは、アンサーにてｒｅｃｖｏｎｌｙ又はｉｎａｃｔｉｖｅとして記される必要がある。メディアストリームがオファーにてｒｅｃｖｏｎｌｙとしてリストされる場合、ストリームは、アンサーにてｒｅｃｖｏｎｌｙ又はｉｎａｃｔｉｖｅとして記される必要がある。オファーされたメディアストリームがｓｅｎｄｒｅｃｖとしてリストされる場合(又は、メディア又はセッションレベルで向きの属性がない場合。このケースでは、ストリームはデフォルトとしてｓｅｎｄｒｅｃｖとなる)、アンサーでの対応するストリームは、ｓｅｎｄｏｎｌｙ、ｒｅｃｖｏｎｌｙ、ｓｅｎｄｒｅｃｖ又はｉｎａｃｔｉｖｅとして記される。オファーされたメディアストリームがｉｎａｃｔｉｖｅとしてリストされる場合、それは、アンサーにてｉｎａｃｔｉｖｅとして記される必要がある。
【００７２】
コールを「ホールド」にすることは、全てのｓｅｎｄｒｅｃｖストリームをｓｅｎｄｏｎｌｙにして、全てのｒｅｃｖｏｎｌｙストリームをｉｎａｃｔｉｖｅに設定することで達成される。古い２５３４ ＳＩＰ ＲＦＣは、０.０.０.０のＩＰコネクション値を用いることを指定していたが、これは、オファー/アンサーのＲＦＣでは推奨されない。
【００７３】
２．マルチキャスト
セッションの記述が、受信(送信)のみとしてリストされたマルチキャストストリームを含む場合、それは、オファー側及びアンサー側を含む参加者は、そのストリームの受信(送信)のみを行える。これはユニキャストの考えと異なっている。ここで、方向性は、オファー側とアンサー側の間におけるメディアの流れを意味する。
【００７４】
ストリームについて２つの視点があるユニキャストとは異なって、マルチキャストストリームでは、ストリームについて単一の視点しかない。そのようなものとして、マルチキャストのオファーに対してアンサーを生成することには、一般的に、ストリームの特性における限定されたセットを変更することが含まれる。
【００７５】
マルチキャストストリームが受け入れられる場合、アンサーにおけるアドレス及びポート情報は、オファーにおける情報と合致する必要がある。同様に、アンサーにおける方向性の情報(ｓｅｎｄｏｎｌｙ、ｒｅｃｖｏｎｌｙ又はｓｅｎｄｒｅｃｖ)は、オファーにおける情報と合致する必要がある。
【００７６】
ロジック記述
[ＵＡＳ及びＵＡＣコールステータス]
各ダイアログ上にて、イベントに基づいて対応するアクションをすることで、Ｂ２ＢＵＡは、ＵＡＳ及びＵＡＣ側のコールステータスの同期を維持することを試みる。例えば、ＵＡＳがＩＮＶＩＴＥを受信すると、ＵＡＣはＩＮＶＩＴＥを生成するだろう。そして、ＵＡＳがレスポンスを受信すると、通常、同様なレスポンスがＵＡＳに送られるであろう。この概要は、図８に示されている。これには、幾つかの例外が存在する：
・  ＵＡＳがＩＮＶＩＴＥを受信すると直ちに、１００ＴＲＹＩＮＧが、ＵＡＳによって送られて、ＲＦＣ３２６１のＵＡＳ仕様が満たされる必要がある。ＵＡＣ側で受信された１００ＴＲＹＩＮＧメッセージは、ＵＡＳ側に再送信されない。
・  幾つかのオペレーション(例えば、存在しているコールのドロップ)は、帯域幅マネージャ(16)で開始される。
【００７７】
[最初のＳＩＰのＩＮＶＩＴＥに基づくネットワークマッチング]
最初のＳＩＰのＩＮＶＩＴＥメッセージは、ＳＩＰプロキシーのロケーションルックアップで調べられる必要があって、帯域幅管理がそのコールに対して発動される必要があるか否かが決定される。帯域幅管理の規則は、本質的にネットワークの定義を含んでおり、ＳＩＰのＩＮＶＩＴＥのソース及びデスティネーションに適合される必要がある。２つのネットワークが、ＳＩＰのＩＮＶＩＴＥのソース及びデスティネーションに合っており、それらネットワーク間でリンクが定義される場合、帯域幅管理が発動される(即ち、ＩＮＶＩＴＥは、Ｂ２ＢＵＡを通じてルートされる)。
【００７８】
[デスティネーションネットワークマッチ]
Ｒｅｑｕｅｓｔ−ＵＲＩは、全てのネットワーク定義に対して合わされて、マッチが行い得るか否かが見られる。Ｒｅｑｕｅｓｔ−ＵＲＩがホストネームである場合、ＤＮＳのルックアップが行われて、(場合によって、単純なローカルメモリキャッシングＤＮＳルックアップ機能が実行されて)ＩＰアドレスが決定される。この弱点は、ＲＦＣ３２６１は、Ｒｅｑｕｅｓｔ−ＵＲＩをそのＤＮＳＩＰアドレスで置き換えてはならないことを指令しており、ＳＩＰスタックは、その後、メッセージを送る直前に、別のＤＮＳのルックアップを行うことである。
【００７９】
[ソースネットワークマッチ]
ＳＩＰのＩＮＶＩＴＥのＶｉａヘッダは、ＳＩＰメッセージが得たパッチのトレースを与えており、ＳＩＰのＩＮＶＩＴＥからソースネットワークを定める幾つかのオプションがある：
１．  トップのＶｉａのみを使用。
最上のＶｉａは、前のホップを示す。
２．底にあるＶｉａのみを使用。
底にあるＶｉａは、ＳＩＰのＩＮＶＩＴＥのオリジネーター(originator)を示すべきである。
３．全てのＶｉａを使用。
このオプションの結果、複数のマッチが行われて、その後、どのネットワークマッチが優先するかという問いが生じる。
１．「最近の」ネットワーク？  即ち、ネットワークは、トップに最も近いＶｉａに合致する。
２．「最初の」ネットワーク？  即ち、ネットワークは、底に最も近いＶｉａに合致する。
【００８０】
「最初の」を伴うオプション３は、帯域幅マネージャ(16)で使用される。オリジネーターを示す底のＶｉａは、プロキシーサーバの「陰になった」ＩＰアドレスであって、現在のプロキシーサーバの規則で処理される時刻まで無意味であるかも知れない。
【００８１】
[Ｒｅ−ＩＮＶＩＴＥ処理]
ＳＩＰは、コールの間、セッションパラメータ(例えば、メディアストリーム)を、ＲｅＩＮＶＩＴＥを用いて変化させる。これらは、ダイアログコンテクストの範囲内のＩＮＶＩＴＥメッセージであって(例えば、Ｔｏ：及びＦｒｏｍ：のヘッダタグの両方が存在する)、ｒｅＩＮＶＩＴＥの失敗は、コール状態を変化させてはならない。それ故に、ｒｅＩＮＶＩＴＥを処理する際には、ｍａｋｅ−ｂｅｆｏｒｅ−ｂｒｅａｋアプローチが、帯域幅マネージャ(16)で利用されるだろう。
【００８２】
[帯域幅管理ロジック]
このセクションは、ポイントツーポイント及び会議コールについて、帯域幅マネージャ(16)で利用されるロジックを記載する。幾つかのハイレベルの入力は、決定を行うプロセスに必要とされて、これらの入力は、その後、新しいコールと共に行う事項を決定する際に要求される更なる情報へのアクセスをもたらす。
【００８３】
これらの入力は、以下の通りである：
１．  コールが起こるリンク。
ａ．  両方の方向における現在のリンクの使用。
ｂ．  このリンクに適用するポリシー。
２．  リンク上のコールの方向、及び用いられるＳＤＰのオファー/アンサーモデル(Ｉｎｖｉｔｅオファー−ＯＫアンサー、又はＯＫオファー−ＡＣＫアンサー)。
ａ．  ＳＤＰオファーが起こるリンクの方向。
ｂ．  ＳＤＰアンサーが予期されるリンクの方向。
３．  ＳＤＰオファー
ａ．  コールレッグのタイプ：ポイントツーポイント、小/中/大会議
１．帯域幅マネージャ(16)を経由するこの会議のその他の会議コールレッグ。
２．ストリーム当たりのオファーされた帯域幅(参加者当たりのオーディオ/ビデオ)。
【００８４】
この情報に基づいて、帯域幅マネージャ(16)は、以下の決定をして、各コールタイプを処理する：
【００８５】
[ポイントツーポイントコール]
これらのコールは、管理が最も簡単である。ＳＤＰに付託されるＲＴＰ/ＡＶＰストリームは、リンク上でユニークであって、各コールは、その他全てのコールから独立している。帯域幅マネージャ(16)は、ポリシー(図４参照)を調べて、オファー方向における全リンク使用に基づいて、オファー内のオーディオ及びビデオストリームについて、最大帯域幅を決定する。これらの上限が、各ストリームにおけるオファーされた帯域幅よりも小さい場合、それに応じて、ストリームの「ｂ＝」パラメータが修正される。特別な「ｂ＝」パラメータが０に設定されると、そのメディアブロックのポートパラメータもゼロに設定されて、そのストリームは無効にされる。オファーされたストリームの帯域幅が現在の使用に加えられて、全体がリンクの容量を超えそうな場合、ビデオストリームの帯域幅は、次に低いステップに下げられて(有効なオプションは：４０００,２０００,１０００,５００,０)、新しいコールが試みられて提供される。上記の全ての後、オファーがなお受け入れ可能である場合、アンサーがオファーと同じ帯域幅を有しているという仮定がされて、アンサー方向における使用が調べられる。必要ならば、オファーの帯域幅は、これに基づいてさらに低減される。オファーが、そのストリームの１つにおいて、ゼロの帯域幅よりも今なお大きい場合、Ｂ２ＢＵＡの第２側のコールが、変更されたＳＤＰで確立され、さもなければ、コールが完全に拒絶される。
【００８６】
コールが確立されると、そのコールについて、ストリーム当たりの帯域幅がリンク上でカウントされる。オファーの属性ライン(ｓｅｎｄｏｎｌｙ、ｒｅｃｖｏｎｌｙ又はｓｅｎｄｒｅｃｖ)が「ｓｅｎｄ」を含んでおり、対応するアンサーも「ｒｅｃｖ」を含んでいる場合にのみ、各ストリームの帯域幅もカウントされる。オファーが「ｒｅｃｖ」を含んでおり、アンサーが「ｓｅｎｄ」を含む場合にのみ、反対の方向の帯域幅もカウントされる。これらのチェックは、コールのホールドと、ビデオ又はオーディオのミュートを達成するために必要とされる。後の段階では、マルチレベルのプライオリティとプレエンプション(preemption)も実施されて、新しいコールに不充分な帯域幅がある場合、帯域幅マネージャ(16)は、新しいコールに利用される容量を作るためにドロップできる、よりプライオリティが低いコールがあるか否かを調べる。
【００８７】
後の段階では、既存コールの再ネゴシエーションが行われるだろう。ポリシーに基づいて、使用がある閾値に到達すると、ある帯域幅を超えて使用をしている既存のコールが落とされるように再ネゴシエーションされて、新しいコールに使用される更なる容量が生じる。
【００８８】
[小会議モデル(参加者が３又は４人)]
このタイプの会議コールでは、各参加者は、各メディアストリーム(ビデオ及びオーディオ)について、マルチキャスト(又は、ＡＴＭのポイントツーマルチポイント)データを送信し、その他全ての参加者は、彼らが興味のあるメディアストリームを視聴できる。会議ホストのＳＩＰＵＡは、(即ち、誰かとのコールの最中に、第３の参加者を勧誘することで、)会議を開始したＶｉＰｒ上で動作し、ＳＩＰコールのレッグ(ダイアログ)は、各参加者と、会議ホストとの間に存在する。それ故に、関係する全てのパーティの間に複数のコールレッグは存在しない。これがハブアンドスポークモデルである。
【００８９】
会議の個々の「スポーク」の全ては、明らかに、帯域幅マネージャ(16)を経由する必要はない。
【００９０】
[シナリオ例]
ローカルＬＡＮ上の会議に３つのＶｉＰｒがあり、帯域幅マネージャ(16)で定義されており、容量が制限されたリンクに亘って、４番目のＶｉＰｒが勧誘される。この場合、４番目のコールレッグのみが帯域幅マネージャ(16)を経由して、その他のコールレッグは、会議ホストとＶｉＰｒ端末との間で、直接的に確立されるであろう。図１０は、このシナリオ例で確立された結果である５つのＳＩＰコールレッグを示す。マルチキャストメディアストリームは示されていないが、ネットワークルーティング要素は、必要なＩＧＭＰマルチキャストパケット転送を行って、ＶｉＰｒ１、２及び３のストリームがＶｉＰｒ４に到達し、ＶｉＰｒ４のストリームがＶｉＰｒ１、２及び３に到達することが保証される。
【００９１】
このシナリオをさらに説明すると、図１１は、ＶｉＰｒ４が勧誘された場合における、帯域幅マネージャ(16)に到達するオファーのＳＤＰの関連部分を示している。会議コールの識別子(ａ＝ｘ＿ＧＵＩＤラインに見られる)、ポート番号及びマルチキャストグループＩＰの組合せが、リンク上にユニークに仮定されて、帯域幅マネージャ(16)を経由する同じ会議コールのその他のレッグは、同じストリームに言及する。リンクに亘ってこれらストリームについて使用される帯域幅は、たとえ複数のコールのレッグがそれらに言及するとしても、それは、マルチキャストで起こることを正確に反映するので、一旦カウントされなくてはならない。
【００９２】
このケースの帯域幅マネージャ(16)は、リンク上のこれらストリームの存在を今のところ知っておらず、それら全てを、このリンクに亘って最初にオファーされている新しいストリームと仮定する。ポリシーと、その方向における現在のリンクの使用とを調べて、帯域幅マネージャ(16)は、例えば、ビデオについてストリーム当たりの新しい最大の帯域幅は２０００ｋｂｐｓであって、オファーは、ビデオストリーム当たり３０００ｋｂｐｓを求めていたことを知る。オファーが変更されると、オファーされたＳＤＰについて新しい帯域幅の全体は、(６０００＋１９２)ｋｂｐｓとなる。これがリンクキャパシティに到達する場合、ストリーム当たりのビデオ帯域幅は、さらに、新たなオファーが受け入れ可能な限界を満たすまで、次のより低い有効値(４０００、２０００、１０００又は５００)に低減される。アンサー方向において使用可能な帯域幅も調べられて、ストリーム当たりの可能な最大レートが、プレースホルダーのＶＨｏｓｔストリームに挿入される。ＶｉＰｒ４はこれらの値を見て、それが、自己のデフォルトの伝送レートを調節する必要があるか否かを決定する。帯域幅マネージャ(16)からＶｉＰｒ４への「新しい」コールにおけるオファーＳＤＰは、図１２に示されている。オファー方向において使用可能なビデオの帯域幅がない場合、ＶＨｏｓｔのプレースホルダーがｂ＝０に設定されて、ＶｉＰｒ４に対して、それはビデオに関与できないというシグナリングが行われる。この場合、ＢＷＭは、最終的に会議ホストにアンサーを戻す場合に、ｂ＝ビデオラインを修正しないことを「思い出す」必要がある。
【００９３】
ＶｉＰｒ４がこのＳＤＰを受信する場合、それは、ＶｉＰｒ１、２及び３から２０００ｋｂｐｓのビデオストリームを想定することを知っており、それは、(プレースホルダーのＶＨｏｓｔストリームから)２０００ｋｂｐｓでビデオを送信できることを知っている。幾つかのケースが、ＶｉＰｒ４がＳＤＰにおいて応答することに応じて生じる。
【００９４】
ケース１：ＶｉＰｒ４は、オーディオ及びビデオコールにレスポンスする。
ＶｉＰｒ４は、ＶＨｏｓｔセクションにおけるオーディオ及びビデオの上限値を受け入れて、図１３のようにＳＤＰでレスポンスする。ＶＨｏｓｔのメディアセクションにおける変更されたｂ＝ラインは、帯域幅マネージャ(16)によってこのように維持されて、帯域幅マネージャ(16)が関係していたことが、会議ホストに示される。
【００９５】
ＶｉＰｒ４は、会議コールについて、オーディオのみに関与することを希望する。ビデオストリームは、ポート番号０と、ｂ＝０ラインとで無効にされる。帯域幅マネージャ(16)は、この結果として、ビデオは、ＶｉＰｒ４に送信されもしないこと(即ち、ＶｉＰｒ４は、その他のＶｉＰｒのマルチキャストビデオストリームに加わらないこと)を認識する必要があり、その結果：
１．  リンクのオファー方向について予定された/割り当てられたこれらストリームについて、結果として生じる任意のビデオの帯域幅は、フリーにされる必要がある。
２．  ＶｉＰｒ１、２及び３について変更されたｂ＝ラインは、それらの元の値に戻されて、会議ホストが、全てのＶｉＰｒについて不必要なｒｅＩＮＶＩＴＥをトリガーすることを防止する必要がある。
【００９６】
これは、実現可能である最高のオーディオ/ビデオ体験を与え且つ維持するＶｉＰｒのポリシーに従っている。ＶｉＰｒ１、２及び３からのビデオは、容量が制限されたリンクに亘る必要はないから、ＶｉＰｒ１、２及び３は、高品質のビデオを互いに送受信できる。
【００９７】
図１４は、ＶｉＰｒ４から帯域幅マネージャ(16)へ送られるＳＤＰのアンサーと、帯域幅マネージャ(16)から会議ホストへ送られるＳＤＰのアンサーとを示す。
【００９８】
[中会議モデル(５から１２の参加者)]
中会議モデルと小会議モデルとの大きな差は、各参加者が、さらにサムネイルサイズのビデオストリーム(３５０ｋｂ/ｓ？？？)をマルチキャストし、各参加者は、その他の３つの「大きな」ビデオストリームを視聴し、その結果、何人かの参加者は、彼らの大きなビデオを見ることに誰も関心がない場合、大きなビデオをマルチキャストする必要は全くない(このようにしないと、この会議モデルは、無駄な大量の帯域幅によって、直ちに非現実的でなくなる)。
【００９９】
独自仕様の追加のフィールドが、ＳＤＰのメディアブロックに含められており、会議ホストによって、どのパーティにどのストリームが属するかを特定されて、各パーティの大きなビデオの選択が調べられる。パーティ識別子フィールドは、会議ホストによって、各パーティについてオーディオメディアブロックに加えられて、形式ａ＝Ｘ−Ｐａｒｔｙ＿ＩＤ：＜識別子＞を有している。各ビデオメディアブロックは属性ラインを有しており、パーティが見ることに関心がある３つの大きなビデオストリームが表される。これらは、先に説明したパーティの識別子で言及されており、属性ラインは、次のフォーマット：ａ＝ｘ−ｐａｒｔｙ＿ｌｉｓｔ[＜ｉｄ１＞，＜ｉｄ２＞，＜ｉｄ３＞]を有している。また、各参加者は、ｍ＝ＬＲ−Ｖｉｄｅｏで特定されるサムネイルビデオストリーム(低ビットレートビデオ)を有している。オーディオ及びＬＲ−Ｖｉｄｅｏメディアブロックは、通常、ｘｐａｒｔｙ＿ｌｉｓｔ属性を含んでおらず、「それら」端末が、その他全てのオーディオ及びＬＲ−Ｖｉｄｅｏストリームを受信したい旨が示されている。
【０１００】
会議ホストが新たな参加者を勧誘する(会議ホストにＲＥＦＥＲを送信することで、会議における任意の端末は、新たな参加者を勧誘できる)場合、ＶＨｏｓｔのメディアブロックは、新しい参加者に利用されるイニシャルのビデオストリームを含んだｘ−ｐａｒｔｙ＿ｌｉｓｔ属性を含む。図１６は、会議ホストから帯域幅マネージャ(16)に達するＩＮＶＩＴＥにおけるＳＤＰボディのサンプルの関連部分を示す。ＶｉＰｒ５は、容量が制限されたリンクに亘って中会議に加えられる。
【０１０１】
会議リストは、各参加者について個別のコールレッグを有しているから、パーティリスト属性において、参加者は、ＳＤＰにおける配置に従って順序付けられておらず、順序付けは完全に異なり得る。これから収集される情報の例として、ＶｉＰｒ１のメディアストリームは、以下を示す：
・  それは、このケースではＶｉＰｒ２、３及び４に対応するパーティ２、３及び４から送られる「大きな」ビデオを受信することに関心がある。
・  それは、会議コールにおける全てのパーティから、オーディオストリーム及びｌｒ−ビデオストリームを受信することに関心がある。
【０１０２】
帯域幅マネージャ(16)は、新しいコールのオファーにおいてこのＳＤＰを受信すると、リンク使用に基づいて適切な場合には、ストリームの帯域幅を変更する必要がある。さらに、それは、最初のｉｎｖｉｔｅについて、誰かの大きなビデオの選択に、ＶｉＰｒ５を最初に入れることはできず、アンサー方向について、最初に帯域幅は必要とされないことを知っている。その後、帯域幅マネージャ(16)はこのロジックを引き続き行う：
・  オーディオストリームはＬＲストリームよりもプライオリティが高く、ＬＲストリームは、大きなビデオストリームよりもプライオリティが高い。
・  ＶｉＰｒ１、２及び３から送られる大きなビデオは、最初にＶｉＰｒ５で受信される(帯域幅の許可)。
・  この例では、ストリーム当たりの最大帯域幅は、２０００ｋｂｐｓに設定される。
・  帯域幅マネージャ(16)は、これら３つのみの大きなビデオのストリームの帯域幅を変更でき、このコールレッグに必要とされる帯域幅を低減する効果が得られる。
【０１０３】
以下の表は、このコールレッグについて各方向に必要とされる帯域幅をまとめている。
【０１０４】
【表１】
2005318535.tif 000003
【０１０５】
図１７は、ＶｉＰｒ５に送られる前に帯域幅マネージャ(16)で変更されたＳＤＰを示す。小会議モデルのケースのように、ＶｉＰｒ５は、ビデオを返さず、そのＬＲビデオに割り当て/確保された帯域幅が解放されて、最初の３つのパーティについて変更されたストリームは、それらの元の値に戻されるだろう。しかしながら、恐らく、ＶｉＰｒ５は、オーディオ及びビデオと共にコールを受け入れて、図１８に示すＳＤＰと共にＳＩＰのＯＫを送るであろう。
【０１０６】
帯域幅マネージャ(16)は、(ＶｉＰｒ５は、それがビデオに加わっていると示したので、最初の３つのパーティについて変更された帯域幅で)このＯＫを会議ホストに転送するだろう。会議ホストは、通常のようにその他のパーティの全てにｒｅＩＮＶＩＴＥを送って、それらに新しい参加者を知らせるだろう。最初の３つのパーティは、それらのマルチキャスト送信レートを適切に調整するだろう。帯域幅マネージャ(16)のロジックに関した幾つかのケースが、以下に記載されている。これらのケースは、参加者が、彼らの大きなビデオを表示選択を変更することを含んでいる。
【０１０７】
ケース１−ＶｉＰｒ５は、ＶｉＰｒ３の代わりにＶｉＰｒ４を見ることを決定する。
これを示すために、図１９に示すように、ＶｉＰｒ５は、帯域幅マネージャ(16)を通じて、パーティリスト属性が変更されたｒｅＩＮＶＩＴＥを送る。
【０１０８】
帯域幅マネージャ(16)は、このメッセージを受信すると、ＶｉＰｒ５は、ＶｉＰｒ３の大きなビデオを見ることにもはや関心がないことを知る。リンク(ネットワーク２)のこのサイドに、ＶｉＰｒ３のビデオに関心のある参加者がいない場合、帯域幅マネージャ(16)は、ネットワーク１からネットワーク２への方向のリンクに関する帯域幅を解放できる。また、帯域幅マネージャ(16)は、ＶｉＰｒ５がＶｉＰｒ４を見ることを希望していることを知る。使用可能なリンク(ネットワーク１からネットワーク２)の帯域幅と、ＶｉＰｒ４が大きなビデオを送信している現在のビットレートとを考慮して、帯域幅マネージャ(16)は、以下の決定の中から１つを選ぶ：
・  ケース１ａ：ＢＷＭは、ＶｉＰｒ４が送信しているビットレートをサポートする。
・  ケース１ｂ：ＢＷＭは、現在のＶｉＰｒ４のビットレートをサポートできないが、より低いビットレートをサポートできる。
・  ケース１ｃ：この会議コールにてＮ１からＮ２へ送られるその他の大きなビデオのストリーム、例えばＶｉＰｒ１及びＶｉＰｒ２のストリームのビットレートを下げることなく、ＶｉＰｒ４からの大きなビデオを、低いビットレートでさえサポートできない。
・  ケース１ｄ：ＢＷＭは、ＶｉＰｒ４から送られるビデオを全くサポートできない。
【０１０９】
[ケース１ａ]
この場合、帯域幅マネージャ(16)は、ＳＤＰを変更する必要はなくて、単にそれを会議ホストに送る。
【０１１０】
[ケース１ｂ及び１ｃ]
ケース１ｂ及び１ｃは、プロトコルの働きとメッセージフローとに関して同じであって、唯一の相違は、帯域幅マネージャ(16)の決定/許可プロセスにある。第１段階の帯域幅マネージャ(16)については、ケース１ｂのみが考慮される。即ち、ＢＷＭは、大きなビデオの新たなリクエストに合わせるために、大きなビデオの接続に関する帯域幅を変更しない。このことは、それが将来変化する場合、中スケールのプロトコル機構に影響を及ぼすべきではないだろう。ケース１ｃは、若干さらに複雑であって、それは、この例について用いられる。ＢＷＭは、ＶｉＰｒ１及びＶｉＰｒ２の大きなビデオの伝送帯域幅を下げる決定をして、このリンクに亘ってＶｉＰｒ４からの送信がサポートされる。それがＶｉＰｒ１、２及び４について選択する帯域幅は、１０００ｋｂｐｓである。ＢＷＭから会議ホストへ送られる変更されたＳＤＰは、図２０に見られる。会議ホストはｒｅＩＮＶＩＴＥを受信して、関連する全てのパーティに情報を送る。この場合、ＶｉＰｒ１、２及び４は、それらの大きなビデオの送信レートを調整して、ＶｉＰｒ３は、そのリスナーのリストからＶｉＰｒ５を除去し、ＶｉＰｒ４は、そのリスナーのリストにＶｉＰｒ５を加える。会議ホストは、ＢＷＭにＯＫを送り返して、ＢＷＭは、それをＶｉＰｒ５に送る。
【０１１１】
[ケース１ｄ]
このケースでは、ＢＷＭは、ＶｉＰｒ４からＶｉＰｒ５への大きなビデオを、全くサポートできないことを決定する。ＢＷＭはＳＤＰを修正して、ＶｉＰｒ５は、ＶｉＰｒ４の大きなビデオを求めたが、帯域幅がないために、この要求は拒絶された旨を会議ホストに示す。これが示される方法は、パーティリストにおける適切なエントリを負の値に設定することである。ｘｐａｒｔｙ＿ｌｉｓｔは、[１，２，４]から[１，２，-４]に変化する。不必要であることから、帯域幅フィールドは変更されない。変更されたＳＤＰは、図２１に示されている。会議ホストは、ＶｉＰｒ４から送られる大きなビデオをＶｉＰｒ５が求めているが、ＢＷＭで拒絶されていることを認識する。会議ホストは、ＯＫにおいて、同じＳＤＰでＢＷＭに応答して、その後、ＢＷＭは、それをＶｉＰｒ５に転送し返す。ＶｉＰｒ５は、ＶｉＰｒ４を加える試みが失敗したことを認識し、さらに、動作は、端末に至る。例えば、それは、その後自動的に再試行し、ユーザに警告し、又はＶｉＰｒ３のビデオを戻すことを試みることなどを行える。
【０１１２】
この明細書では、参加者が４人までの会議が、小会議[ＳＣｏｎｆ]として言及されている。参加者が４乃至１２人の会議が、中会議[ＭＣｏｎｆ]と称されており、参加者が１２人を超える会議が、大会議[ＬＣｏｎｆ]として称されている。
【０１１３】
ＶｉＰｒ会議モデルは、ハブアンドスポーク会議モデルである。会議のハブはＶＨｏｓｔである。このコールの各参加者は、スポークである。ハブスポークモデルは、中及び大会議コールについて使われ続ける。
【０１１４】
[小会議]
ＶｉＰｒ会議は、ハブアンドスポークモデルに従う。会議コールの各パーティは、会議ホスト[ｈｕｂ]を用いてＳＩＰコール[ｓｐｏｋｅ]を確立する。また、会議ホストは、ＶＨｏｓｔと呼ばれる。通常、会議ホストは、ＶｉＰｒ上で動作して、会議を開始させる。
【０１１５】
参加者がＰ１[ＶｉＰｒ Ｖ１上]、Ｐ２[Ｖ２上]、Ｐ３[Ｖ３上]である会議コールは、３つのＳＩＰコールから構成されている。
−  ＶＨｏｓｔとＶ１の間のＳＩＰコール。
−  ＶＨｏｓｔとＶ２の間のＳＩＰコール。
−  ＶＨｏｓｔとＶ３の間のＳＩＰコール。
【０１１６】
ＶＨｏｓｔの役割は、各参加者からその他の全ての参加者への会議ストリーミング情報を配信することである。
【０１１７】
小会議では、各パーティは、２つのメディアストリーム−オーディオ、ビデオを送信できる。
−  会議コールがホールドである場合、オーディオ及びビデオストリームの両方は送信されない。
−  カメラが停止されている場合、ビデオストリームは送信されない。
【０１１８】
さらに、以下の制約が全ての参加者に設定される。ＶｉＰｒがカメラを停止した場合、それは、また、ビデオを受信しないようにされる。ＶｉＰｒがホールド状態にある場合、それは、オーディオ/ビデオを受信しないようにされる。
【０１１９】
さらに、黙示のポリシーの通り、タイプＸのストリーム[オーディオ又はビデオの何れか]を送信している全てのＶｉＰｒは、そのタイプのストリームを視聴することに関心があるように、自動的に解釈される。即ち、参加者がオーディオ送信可能となった場合、その他の全てのパーティは、このパーティがオーディオを受信する関心があることのサインとして、それを解釈する。これは、「送信可能は受信希望を意味する」規則として言い換えることができる。
【０１２０】
例えば、パーティＰ１、Ｐ２、Ｐ３及びＰ４による会議を考える：
【０１２１】
テーブル１は、各パーティのストリーム情報を示す。Ｖｉｄｅｏ Ｔｘ＝Ｏｎは、そのパーティがビデオについて送信可能であることを意味する。それは、そのパーティが実際にビデオを送信していることを意味してはいない。パーティは、別のパーティがＶｉｄｅｏ Ｔｘ＝Ｏｎであることを見る場合にのみ、送信を開始する。
【０１２２】
【表２】
2005318535.tif 000004
【０１２３】
このテーブルを構築するために、各パーティは、その送信情報をＶＨｏｓｔに送る。そして、ＶＨｏｓｔは、その他のパーティに、この情報を伝える。よって、各パーティは、その他のパーティの送信状態を知る。
【０１２４】
次に、Ｐ１、Ｐ２、Ｐ３及びＰ４が、それを、このテーブルを如何に解釈するかを見る。
【０１２５】
Ｐ１にて
Ｐ１は、Ｐ２がオーディオについて送信可能/オンであることを知る。このことは、Ｐ２もＰ１から受信することを望んでいることの表示として、Ｐ１によって解釈される。故に、送信状態は、黙示的に受信状態とリンクされる。同様にして、Ｐ１も、Ｐ２がビデオに関心があるとして解釈する。故に、Ｐ１は、オーディオ/ビデオストリームのリスナーとしてＰ２を加える。
【０１２６】
Ｐ１は、Ｐ３がオーディオのみに関心があることを知る。それに応じて、それは、単に、オーディオのリスナー/レシーバーとしてＰ３を加える。
【０１２７】
Ｐ４は、オーディオ又はビデオの何れかについても、リスナーとして加えられない。
【０１２８】
同様に、Ｐ２、Ｐ３及びＰ４は、それらの個々のストリームの送信状態を見て、それらからオーディオ/ビデオを受信することに関心のあるパーティを認識する。
【０１２９】
[ＳＩＰの詳細]
各パーティの送信状態を記録するテーブル１は、ＳＤＰとしてエンコードされて、ＶＨｏｓｔによって又は通じて、各パーティに送られる。あるパーティがそのストリーム送信状態を変化させる場合は何時でも、それは、テーブルをアップデートして、それをＶＨｏｓｔに送る。それ故に、ＶＨｏｓｔは、現在のテーブルステート情報の管理者及び反射体として機能する。
【０１３０】
如何にして、このテーブルが埋められて、ＳＤＰに示されるか？
【０１３１】
これを理解するために、参加者がＰ１、Ｐ２、Ｐ３及びＰ４である同じ会議を考える。Ｐ１は、会議を開始する。それは、ＩＮＶＩＴＥをＶＨｏｓｔに送る。そのストリーム情報は、ＳＤＰに含められて、ＳＤＰに付けられる。ＳＤＰは、この時点では、テーブル１の単に１つのラインを示している[テーブル２]。これは、実際のＳＤＰフォーマット/構文ではなく、ＳＤＰの内容の論理的表現である。属性ラインによって、このテーブルが実施にエンコードされる模様を理解するためには、テーブル４を参照のこと。
【０１３２】
【表３】
2005318535.tif 000005
【０１３３】
この時点にて、Ｐ１は、オーディオとビデオの何れかを送信してはいない。単に、それは、送信可能であることを示しているのみである。先述のように、Ｐ１は、別のパーティが、それに対応するストリームについて送信可能であることを知るまで、そのストリームの送信を始めない。
【０１３４】
また、「送信可能は受信希望を意味する」規則によって、それは、その他のパーティからオーディオ/ビデオを受信することに、自らが関心があることを示す。
【０１３５】
次のステップでは、ＳＩＰのＲＥＦＥＲをＶＨｏｓｔに送ることで、Ｐ１は、Ｐ２を会議に勧誘する。ＶＨｏｓｔは、Ｐ２について、Ｐ１からＲＥＦＥＲを受信すると、テーブル２のＳＤＰを伴ったＩＮＶＩＴＥをＰ２に送る。Ｐ２は、自己のストリームをテーブル２に加えることで、これを承認する。アップデートされたストリーム情報は、テーブル３で表現される。
【０１３６】
【表４】
2005318535.tif 000006
【０１３７】
ＶＨｏｓｔは、このアップデートをＰ１に戻す。そして、Ｐ１の存在及びストリーミング情報を知るに至る。
【０１３８】
Ｐ１は、同様な方法で会議コールをＰ３及びＰ４に加える。
【０１３９】
[ＳＤＰにおけるテーブルの表現]
各パーティは、ＳＤＰにパーティブロック情報を加える。パーティブロック情報は、３つのメディアブロックの情報から構成される。オーディオ、ビデオ及びサムネイルビデオの各々について１つのブロックが設けられる。
【０１４０】
オーディオメディアブロックは、以下の様に示される：
【０１４１】
【表５】
2005318535.tif 000007
【０１４２】
ビデオ及びＬＲビデオは、同様な方法で表現される。それ故に、各パーティは、[テーブル４のように]ＳＤＰで示されるブロックのセットを有する。
【０１４３】
[ＵＡＣ/ＵＡＳにおける実施の詳細]
このシナリオでのＵＡＣ及びＵＡＳは、ＶｉＰｒ端末クラスのデバイスである。これらのデバイス上のソフトウエアは、概念的に以下のサブモジュールに分けられる：
【０１４４】
Ｓｉｐ ＵＡ:このモジュールは、Ｓｉｐ機能を実現する。それは、帯域幅マネージャ(16)とのインタラクションに関与しており、メディアストリームについて要求される帯域幅を要求及び割り当てる。
【０１４５】
オーディオ/ビデオ/データサブシステム：サブシステムは、ネットワークに亘って、会議におけるその他のネットワークノード部分に送信される、オーディオ、ビデオ及びデータストリームの生成に関与する。また、このサブシステムは、その他のノードから受信したオーディオ、ビデオ及びデータストリームを再生する。
【０１４６】
ネットワークモジュール：このモジュールは、ネットワークソケットをプログラムして、会議ピアとメディアパケットを送受信する。
【０１４７】
[中会議モデル]
中会議は、ディスプレイ上でのサイズとレイアウトにおいて、小会議と異なっている。中スケール会議は、１〜１２のパーティ間の会議である。その結果、大きなビデオの３人の参加者と、１２のサムネイル参加者が、ディスプレイ上に配置される。
【０１４８】
参加者が４人の小会議は、５番目のパーティが加えられる場合、自動的に中会議に変換される。
【０１４９】
また、会議は、中会議として開始することもできる。全ての中会議は、ＵＲＩでユニークに特定される。
【０１５０】
中スケール会議は、以下の点において、小会議と異なっている。
１．中スケール会議の参加者は、３つのストリームまで送信できる。
ａ．  オーディオストリーム
ｂ．  大きなビデオストリーム
ｃ．  小さなサムネイルストリーム
参加者がカメラをオンにすると、そのトランスミッタは、大きなビデオとサムネイルビデオの両方を送信可能となる。
２．中スケール会議では、参加者が、ビデオ及びサムネイルビデオのトランスミッタをオンになっていることを示す場合、その他のパーティから大きなビデオとサムネイルビデオを受信することを望む旨を、暗に伝える必要はない。これは、小会議に用いられるモデル「送信可能は受信希望を意味する」は、もはや正しくないことを意味する。
【０１５１】
これにより、若干の問題が生じる。小スケールの会議とは異なり、各パーティは、その他の機構を用いて、それが受信することに関心があるストリームを示す必要がある。
【０１５２】
問題：では、各パーティが受信することに関心があるストリームのセットを、どのように示すのか？
【０１５３】
Ｐ１乃至Ｐ５がパーティである中スケール会議を考える。全てのパーティは、ビデオ/オーディオが送信可能である。
【０１５４】
各パーティは、以下の能力がある。
−  ３つの大きなビデオを表示する。
−  １２のサムネイルビデオ。
−  １２のオーディオストリーム。
【０１５５】
それ故に、各パーティは、３つの大きなビデオで表示される３つのパーティを、４つのパーティから選択する必要がある。Ｐ１は、大きいビデオとしてＰ３、Ｐ４及びＰ５を見ることを望んでいるとする。
【０１５６】
故に、Ｐ１は、Ｐ３、Ｐ４及びＰ５の大きなビデオに関心があることを示す必要がある。それが行われる１つの方法は、ｒｅｃｅｉｖｅ＿ｐａｒｔｙ＿ｌｉｓｔフィールドを明示的に有するように、ＳＤＰ/メディア属性のテーブルをアップデートすることだろう。つまり、テーブル１は、以下のように変更されるであろう[テーブル５]：
【０１５７】
テーブル５は、また、その他のパーティの選択を示している。
【０１５８】
【表６】
2005318535.tif 000008
【０１５９】
このテーブルから、ストリーム情報を運ぶプロトコル機構が、各参加者が視聴したいパーティのリストに関する情報を運ぶように変化する必要があることは、明らかである。
【０１６０】
これを行う方法の１つは、小会議の機構を再利用して、ＳＤＰにて現在のストリーム情報の完全なテーブルをエンコードすることである。基本的に、このＳＤＰは、その他全てのパーティに関する送受信情報を運ぶ。
【０１６１】
例えば、Ｐ１は、以下のようなＳＤＰの部分をエンコードできるだろう：
【０１６２】
【表７】
2005318535.tif 000009
【０１６３】
さらに、以前とほとんど同じ方法で、会議が開始して、各パーティが１つずつ加えられる。
【０１６４】
最初のパスについて、これが、我々が話しているアプローチである。各パーティは、ＳＤＰに新しいラインを加えることで、自己が視聴することに関心があるパーティをＳＤＰに示すだろう。
【０１６５】
[実施の詳細]
中会議のコールを実施するソフトウエアは、以下のサブモジュールに分けられる：
【０１６６】
Ｓｉｐ ＵＡ:このモジュールは、Ｓｉｐ機能を実現する。それは、帯域幅マネージャ(16)とのインタラクションに関与しており、メディアストリームについて要求される帯域幅を要求及び割り当てる。
【０１６７】
オーディオ/ビデオ/データサブシステム：サブシステムは、ネットワークに亘って、会議におけるその他のネットワークノード部分に送信されるオーディオ、ビデオ及びデータストリームの生成に関与する。また、このサブシステムは、その他のノードから受信したオーディオ、ビデオ及びデータストリームを再生する。
【０１６８】
ネットワークモジュール：このモジュールは、ネットワークソケットをプログラムして、会議ピアとメディアパケットを送受信する。
【０１６９】
如何にして、小会議が中会議に変換されるのか？  如何にして、中会議が開始されるのか？
【０１７０】
先に説明したように、５番目のパーティが加えられる場合、パーティが４つである小会議は、中会議コールに変換される。
【０１７１】
[アプローチ１]
このアプローチでは、プロトコル機構が関係する限りにおいて、小会議と中会議間に基本的な差異がない。
【０１７２】
このアプローチでは、各パーティは、その他の全てのパーティに、オーディオ/ビデオ及びＬＲビデオについて、自己の送信情報を送る。しかしながら、どのパーティも、その他のあるパーティがそのストリームを見ることを開始したことの指示を受信するまで、ＬＲビデオストリームを送信しない。この方法では、小会議から中会議へのレイアウトの変化の決定は、完全に個々のパーティ次第である。
【０１７３】
以下の例を用いて、この試みがどのように機能するかを理解する。この例では、Ｐ２、Ｐ３、Ｐ３及びＰ５を会議コールに加えることで、Ｐ１は、会議コールを開始する。
１．  Ｐ１は、Ｈｏｓｔを会議に勧誘することで、会議を開始する。それは、テーブル６ａに示す情報と共に、ＩＮＶＩＴＥをＨｏｓｔに送る。
【０１７４】
【表８】
2005318535.tif 000010
【０１７５】
２．  Ｐ１は、ＨｏｓｔにＰ２及びＰ３を照会して(refer)、それらを会議に加える。
３．  Ｈｏｓｔは、Ｐ１のストリーム情報を含むＳＤＰを伴うＩＮＶＩＴＥを、Ｐ２に送る。
４．  Ｐ２は、Ｐ１がコール上にある唯一のパーティであることを知る。それは、パーティの数が４より小さいことを知って、Ｐ１からビデオ/オーディオを受信することを要求する。しかし、それは、Ｐ１のＬＲビデオストリームを受信するリクエストは送らない。
【０１７６】
この時点にて、ＳＤＰのテーブルは、テーブル６ｂのようになる。
【０１７７】
【表９】
2005318535.tif 000011
【０１７８】
５．  Ｈｏｓｔは、ＳＤＰとしてのテーブル６ｂと共に、Ｐ３にＩＮＶＩＴＥを送る。
６．  Ｐ３は、[自らを含む]３つのパーティが会議にあることを知る。故に、それは、Ｐ１及びＰ２からのＬＲビデオストリームを受信しないことを決定する。それは、Ｐ１及びＰ２からのオーディオ及びビデオストリームをのみを要求する。また、それは、ＳＤＰにその送信情報を含める。
【０１７９】
この時点にて、ＳＤＰのテーブルは、テーブル６ｃのようになる。
【０１８０】
【表１０】
2005318535.tif 000012
【０１８１】
７．  Ｈｏｓｔは、テーブル６ｃをＰ１及びＰ２に送る。Ｐ１は、Ｐ２及びＰ３がコールに参加したことを知る。そして、それは、テーブル６ｃをテーブル６ｄにアップデートして、それをＨｏｓｔに送る。テーブル６ｄは、Ｐ１が、Ｐ２及びＰ３からオーディオ/ビデオを受信し、ＬＲビデオを受信しないことを希望している旨を示す。また、Ｐ２は、それがコールに参加したので、Ｐ３がコールに参加したことを知る。そして、Ｐ２は、テーブル６ｃを６ｅにアップデートして、それをＨｏｓｔに送る。
【０１８２】
【表１１】
2005318535.tif 000013
【０１８３】
【表１２】
2005318535.tif 000014
【０１８４】
８．  Ｈｏｓｔは、テーブル６ｄと６ｅをマージして、テーブル６ｆを作成する。そして、テーブル６ｆが全てのパーティに送られる。
【０１８５】
【表１３】
2005318535.tif 000015
【０１８６】
９．  同様にして、Ｐ４が加えられると、テーブルは、テーブル６ｇのようになる。
【０１８７】
【表１４】
2005318535.tif 000016
【０１８８】
１０．  この会議にＰ５が加えられる場合、Ｈｏｓｔは、Ｐ５にテーブル６ｇを送る。そして、それは、コールに５つのパーティがあることを知り、それは、中スケールの会議モードに移行できる。それは、それを行う。そして、それは、パーティＰ１乃至Ｐ４に、それらのサムネイルビデオとオーディオストリームを受信することを希望している旨を示す。さらに、それは、パーティＰ１乃至Ｐ３に、それらの大きなビデオを受信することも希望している旨を示す。それは、テーブル６ｇを６ｈに変更することで、これを行う。Ｐ５の決定は、Ｐ１乃至Ｐ４の決定と独立していることに留意すべきである。実際には、Ｐ５は、Ｐ１乃至Ｐ４からサムネイルを受信しないことを選択し、その代わりに、パーティＰ１乃至Ｐ４の全てから大きなビデオを受信する要求ができるであろう。
【０１８９】
【表１５】
2005318535.tif 000017
【０１９０】
１１．  Ｈｏｓｔは、テーブル６ｈを全てのパーティに送る。
【０１９１】
【表１６】
2005318535.tif 000018
【０１９２】
１２．  Ｐ１乃至Ｐ４がアップデートされたテーブルを得ると、それらは、Ｐ５がコールに参加して、パーティの数が、現在５以上になったことを知る。そして、それらは、中会議モデルに移行をする決定をする。例えば、Ｐ１は、大きなウィンドウで、Ｐ２、Ｐ３及びＰ４を見ることを決定する。Ｐ２は、大きなウィンドウで、Ｐ１、Ｐ２及びＰ４を見ることを決定する。そして、Ｐ３は、大きなビデオで、Ｐ１、Ｐ２及びＰ４を見ることを決定する。そして、Ｐ４は、大きなパーティとしてＰ１、Ｐ２及びＰ３を見ることを決定する。故に、結果のストリーム情報テーブルは、テーブル６ｉのようになる。
【０１９３】
【表１７】
2005318535.tif 000019
【０１９４】
注意１．テーブル６ｉから、オーディオ/ＬＲビデオストリームの受信パーティ情報も同様であることが容易に理解される。
【０１９５】
注意２．とは言え、各パーティが小会議から中会議に変更する決定を個々に行えることに留意すべきである。全てのパーティが、同時にこの決定をすることは重要である。これは、現在において、複数のビデオフォーマットの送信がサポートできていないからである。小会議及び中会議のビデオフォーマットは異なっている。
【０１９６】
[アプローチ２]
このアプローチでは、小から大/中に会議を変化する決定は、Ｈｏｓｔによって指示される。アプローチ１の例を考える。ステップ９までのステップは、基本的に同じである。しかしながら、Ｐ５が加えられる場合、Ｈｏｓｔは、現在、会議にて、コール上に５人の参加者があることを知る。故に、それは、[ストリーム情報の]テーブルにフィールドを挿入して、会議が中会議であることを示す。この属性は、個々のパーティで用いられて、それらが中会議フォーマットで会議を表示すべきである旨が暗示される。
【０１９７】
[アプローチ３]
アプローチ３は、１と２のコンビネーションである。故に、パーティは、そのビューフォーマットを小から中に変化させる決定を個々に行えるだろう。又は、それは、ホストによって指示されるとそのように行うだろう。加えて、会議コールが開始されていると、パーティは、[ストリーム情報の]テーブルにこの属性を含めることを、ホストに要求するだろう。
【０１９８】
この決定は、アプローチ３をサポート及び実施する。
【０１９９】
帯域幅マネージャ(16)は、それによって管理されるリンクに亘る任意のストリームで用いられるＴｘ帯域幅を制御する。帯域幅マネージャ(16)(ＢＷＭ)の機能は、ソフトウエアとして、ＳＧＰ又はＶＨｏｓｔに含められる。
【０２００】
ＢＷＭは、スローなリンクに亘ってＩＮＶＩＴＥをリレーする場合、それは、コールされたＶｉＰｒに、それが、その種々のストリームについて確保した帯域幅を示すことが可能である。また、それは、その他のユーザが発したその他のストリームが送信されている帯域幅を示す。帯域幅におけるゼロの値は、帯域幅マネージャ(16)が、その特定のストリームが「その」リンクに亘ることを許可していないこと意味する。
【０２０１】
以下のセクションでは、帯域幅マネージャ(16)を通過する、ｐ２ｐコール及び会議コールのメッセージの流れについて議論する。
【０２０２】
[Ｐ２Ｐコール]
ネットＮ１におけるＶｉＰｒＡ[Ｎ１Ａ]が、ネットＮ２におけるＶｉＰｒＢ[Ｎ１Ｂ]にコールする場合を考える。ここで、ＶｉＰｒ Ｎ２は、リンクＮ１−Ｎ２に亘って、帯域幅マネージャ(16)で管理される。
【０２０３】
Ａは、ＩＮＶＩＴＥ[ＳＤＰ]において、オファーとして以下の事項を含んでいる。
【０２０４】
注意１：この記載では、ｍブロック内の関連する属性ラインが示されている。
【０２０５】
注意２：この記載で示される属性ラインはロジカルであって、ＳＤＰシンタックスを定義しておらず、又はそれに従っていない。
【０２０６】
【表１８】
2005318535.tif 000020
【０２０７】
ＢＷＭは、Ｎ１ＡからＮ２Ｂへの向きについて、３.５Ｍｂｐｓを利用可能にし、Ｎ２ＢからＮ１Ａへの向きについて、３.０Ｍｂｐｓのみを利用可能にしたことを気付くであろう。そして、それ故に、それは、テーブル１のＳＤＰに示すように、ビデオのｂラインを３０００に変更する。修正されたＳＤＰは、テーブル２のようになる。ｂ＝３０００ラインは、Ｎ２Ｂがそのオーディオストリームを送信できる最大値を示す。
【０２０８】
【表１９】
2005318535.tif 000021
【０２０９】
Ｎ２Ｂは、このメッセージを得ると、それを以下のように解釈する：
−  Ｎ２Ａは、６４Ｋｂｐｓでオーディオを、３０００ｋｂｐｓでビデオを送信することを許可されている。
−  Ｎ２Ｂは、Ｔｘオーディオについて、≦６４Ｋｂｐｓである値を、Ｔｘビデオについて、≦３０００ｋｂｐｓである値を選択するように制限されている。
【０２１０】
注意：Ａは、Ｂが選択するどのような値でもストリームを送信する。
【０２１１】
[小会議]
ＢＷＭは、ネットワークＮ１及びＮ２をリンクする。ＶｉＰｒのＮ１Ａ、Ｎ１Ｂ及びＮ１Ｃ[全てネット１にある]が、会議に参加している。Ｎ１Ｃは、Ｎ２Ｐを会議に照会する。ＶＨｏｓｔは、ＩＮＶＩＴＥをＮ２Ｐに送り、それは、ＢＷＭにルーティングされる。ＩＮＶＩＴＥの中身は、以下のようになる:
【０２１２】
[注意１：小会議のｌｒビデオは無視されるので、それは示されていない]
【０２１３】
【表２０】
2005318535.tif 000022
【０２１４】
ここで、ｂ＝３０００は、対応するトランスミッタが３０００ｋｂｐｓでストリームを生成するように設定されている旨を意味する。Ｘ−ＧＵＩＤラインは、会議コールを一意に特定する。
【０２１５】
ＢＷＭはＩＮＶＩＴＥを得ると、それが、会議の一部ではないことを知る。それは、Ｎ２Ｐが勧誘されており、リンクＮ１−Ｎ２に亘っていることを知る。それは、Ｎ１Ａ、Ｎ１Ｂ及びＮ１Ｃのオーディオの帯域幅をサポートできる＊ある決定を用いるプロセス＊を計算するが、それがＮ１からＮ２についてサポートできるビデオＴｘの最大帯域幅は６Ｍｂｐｓであり、[例えば]、それは、Ｎ１Ａ、Ｎ１Ｂ及びＮ１Ｃの各々について、これを２Ｍｂｐｓに分割する。また、それは、Ｎ２Ｐのオーディオ及びビデオトランスミッタの最大帯域幅を決定及び確保できる。[Ｎ２からＮ１の方向については]、Ｎ２Ｐは、ＢＷＭで確保される最大帯域幅までの適当な帯域幅を選択できる。
【０２１６】
そして、ＢＷＭからＮ２Ｐに転送されるＩＮＶＩＴＥは、以下のようになる：
【０２１７】
【表２１】
2005318535.tif 000023
【０２１８】
ＶＨｏｓｔメディアストリームにおけるｂラインは、プレースホルダーとして用いられて、与えられたストリームに利用可能な帯域幅がＮ２Ｐに示される。これらのプレースホルダーは、ストリームがアクティブである毎に有効である。即ち、パーティがカメラを停止させて、それを再度オンにする場合、ＩＮＶＩＴＥをＶＨｏｓｔに送ることで、それは、それが送信することを許された帯域幅を引き出すために、ＶＨｏｓｔのｂのストリームに受け取られた値を見るのを待つ必要がある。即ち、各帯域幅のネゴシエーションが完了するためには、ＩＮＶＩＴＥ−ＯＫのペアのメッセージを必要とする。
【０２１９】
Ｎ２Ｐがこのメッセージを得ると、それは、Ａ、Ｂ及びＣが送信する帯域幅を知り、それが送信することを許される最大の帯域幅の指示を得る。
【０２２０】
最後に、Ｎ２Ｐがレスポンスすると、以下のケースが起こり得る：
【０２２１】
[ケース１]
Ｎ２Ｐは、オーディオ/ビデオの参加者である。Ｎ２Ｐは、オーディオについて６４Ｋの値を、ビデオについて２０００ｋｂｐｓの値を選択する。Ｎ２Ｐは、以下のＯＫをＢＷＭに送る。
【０２２２】
【表２２】
2005318535.tif 000024
【０２２３】
ＢＷＭがこのメッセージを得ると、それは、このストリームに４０００ｋｂｐｓを確保していたが、Ｎ２Ｐはビデオを２０００ｋｂｐｓで行うことを知る。それは、ビデオに許可された余分な１０００の帯域幅を解放する。
【０２２４】
そして、それは、以下のＯＫをＶＨｏｓｔに送る。ＢＷＭは、Ｎ２Ｐから受信したＯＫの全てのメディアラインを、ＶＨｏｓｔに送られるＯＫにコピーする必要がある。
【０２２５】
【表２３】
2005318535.tif 000025
【０２２６】
ＶＨｏｓｔは、このメッセージを全てのパーティにリレーする。送信帯域幅が変更されたそれらパーティは、それらのビデオビットレートを変更するだろう。また、全てのパーティは、ＶＨｏｓｔからメッセージを得る際に要求されている通常の中会議の動作の全てを行う。
【０２２７】
[ケース２]
Ｎ２Ｐは、オーディオのみを行う。そのケースでは、リンクに亘る全てのビデオ帯域幅が[両方向について]解放される。故に、Ｎ１からＮ２方向について[Ｎ１Ａ、Ｎ１Ｂ及びＮ１Ｃから送られる]ビデオに確保された６Ｍｂｐｓが解放される。このケースにおいてＮ２ＰによってＢＷＭに送られるＯＫは、以下のようになる。
【０２２８】
【表２４】
2005318535.tif 000026
【０２２９】
このケースでは、ＢＷＭがこのメッセージを得ると、それは、Ｎ２Ｐはビデオを受信する必要がないので、Ｎ１Ａ、Ｎ１Ｂ及びＮ１Ｃの送信帯域幅を下げる必要がないことを知る。これは、最も良いビデオ/オーディオの聴取を与えて維持するＶｉＰｒのポリシーに従うことに留意のこと。
【０２３０】
従って、ＶＨｏｓｔは、以下のＯＫをＶＨｏｓｔに送る。
【０２３１】
【表２５】
2005318535.tif 000027
【０２３２】
ＶＨｏｓｔは、このメッセージを全てのパーティにリレーする。それらパーティは、帯域幅を変化させて、それらのビデオビットレートを変化させるであろう。また、全てのパーティは、ＶＨｏｓｔからメッセージを得ることに要求される通常の中会議アクションの全てを行う。
【０２３３】
[中会議]
ネットＮ１及びＮ２は、ＢＷＭが管理するリンクで互いに繋がれる。Ｎ１Ａ、Ｎ１Ｂ、Ｎ１Ｃ、Ｎ１Ｄ、Ｎ１Ｅは、ネットワークＮ１におけるＶｉＰｒである。Ｎ２Ｐは、ネットワークＮ２におけるＶｉＰｒである。また、Ｎ１Ａ、Ｎ１Ｂ、Ｎ１Ｃ、Ｎ１Ｄ及びＮ１Ｅは、既に、中会議コールに含まれている。それらパーティの１つが、Ｎ２Ｐをコールに参加させる。
【０２３４】
ＶＨｏｓｔは、ルートされる以下のＩＮＶＩＴＥをＢＷＭに送る。
【０２３５】
【表２６】
2005318535.tif 000028
【表２７】
2005318535.tif 000029
【０２３６】
この勧誘では、各パーティのｍ＝オーディオラインに関するＰａｒｔｙＩＤは、ＶＨｏｓｔによって許可されたパーティＩＤであって、この会議内における各パーティを一意に特定する。あるパーティは、その他全てのパーティによって、そのパーティＩＤを用いて特定される。
【０２３７】
ストリームに関係したａ＝ｘ−ｐａｒｔｙ＿ｌｉｓｔラインは、パーティのリストを示しており、「この」パーティは、そのリストのパーティから対応するストリームを受信することに関心がある。リストが明示されていない場合、「この」パーティは、その他全てのパーティから対応するストリームを受信することに関心がある。
【０２３８】
また、ＶＨｏｓｔの大きなビデオのメディアラインに関連してｘ−ｐａｒｔｙ＿ｌｉｓｔラインがあることに留意のこと。これは、Ｎ２Ｐが会議コールを受け入れる場合、これらのパーティは大きく表示されなくてはならないという指示として、ＢＷＭとターゲットのＶｉＰｒ[Ｎ２Ｐ]に送られる。
【０２３９】
例えば、Ａのメディアストリームは以下を示す：
−  それは、パーティ２[Ｎ１Ｂ]、３[Ｎ１Ｃ]及び４[Ｎ１Ｄ]から大きなビデオを受信することに関心がある。
−  それは、全てのパーティからオーディオ/ｌｒビデオを受信することに関心がある。
【０２４０】
ＢＷＭはこの勧誘を得て、リンクに亘る帯域幅のように、各ストリームの帯域幅を変更する。また、それは、誰かの大きなビデオにて、Ｎ２Ｐがまず最初にあるように選択され得ないことを知る。
【０２４１】
従って、以下の事項が、ＢＷＭの決定プロセスで行われる。
−  オーディオストリームは、ＬＲビデオよりもプライオリティを高くされ、さらに、ＬＲビデオは、大きなビデオよりもプライオリティを高くされる。
−  Ｎ１Ａ、Ｎ１Ｂ及びＮ１Ｃから送信された大きなビデオは、Ｎ２Ｐにて受信される。
−  全てのオーディオ/ｌｒビデオ[１０ ｉｎ ｎｕ]ストリームは、Ｎ２Ｐで受信される。
【０２４２】
以下のテーブルは、上流及び下流方向の帯域幅要求を与える。
【０２４３】
【表２８】
2005318535.tif 000030
【０２４４】
それは、Ｎ１からＮ２に行く各ストリームのｔｘ帯域幅を変更する間、これらを考慮する。
【０２４５】
また、それは、Ｎ２Ｐが、Ｎ１Ａ、Ｎ１Ｂ及びＮ１Ｃを見るように制約されていることを知っているので、必要に応じて、それらのＴｘ帯域幅を変更できる。また、それは、Ｎ２Ｐのオーディオ及びビデオトランスミッタの帯域幅を確保できる。この時点において、誰も大きなビデオに合わせられないからである。
【０２４６】
その後、ＢＷＭは、以下のＩＮＶＩＴＥをＮ２Ｐに転送するだろう。
【０２４７】
【表２９】
2005318535.tif 000031
【表３０】
2005318535.tif 000032
【０２４８】
小会議のＮ２Ｐは、その大きなビデオの送信ストリームに許される帯域幅はないこと、そして、６４及び３５０ｋｂｉｔｓが、オーディオ/ｌｒビデオに確保されていることを知らされる。
【０２４９】
さらに、小会議のＮ２Ｐは、そのｌｒビデオに許可された帯域幅が解放されるケースでは、ビデオを戻さないであろう。最初の３つのパーティ[Ｎ１Ａ、Ｎ１Ｂ、Ｎ１Ｃ]の帯域幅は、そのオリジナルの値に戻される。しかしながら、さらにあり得るケースでは、Ｎ２Ｐは、コール[オーディオ/ビデオ]を受け入れて、ＢＷＭに以下のＯＫを送るだろう。
【０２５０】
【表３１】
2005318535.tif 000033
【表３２】
2005318535.tif 000034
【０２５１】
そして、ＢＷＭは、[Ａ、Ｂ及びＣの大きなビデオについての変更された帯域幅を伴った]このＯＫをＶＨｏｓｔに転送するであろう。ＶＨｏｓｔは、このメッセージを得ると、このメッセージを全てのパーティに転送するであろう。全てのパーティは、それらの送信帯域幅が変更されたことを知って、それらのビデオビットレートを再設定するであろう。さらに、全てのパーティは、必要な通常の会議アクションの全てを行うであろう。
【０２５２】
次の幾つかのセクションでは、パーティが、それらの大きなウィンドウの参加者を変更することを試みるケースを扱う。
【０２５３】
[ケース１]
パーティＮ２Ｐは、Ｎ１Ｃの代わりにＮ１Ｄを見ることを決定する。これを示すために、パーティＮ２Ｐは、以下の内容で、[ｒｅ]ＩＮＶＩＴＥをＢＷＭに送る。
【０２５４】
【表３３】
2005318535.tif 000035
【表３４】
2005318535.tif 000036
【０２５５】
ＢＷＭはこのメッセージを得て、Ｎ２ＰがＣの大きなビデオを見ることに関心がないことを知る。ＢＷＭは、ネットＮ２上にあってＣの大きなビデオを見ている、会議の別の参加者があるか否かを確認する。そして、それは、そのような参加者がない場合、Ｎ１からＮ２の方向におけるＣの大きなビデオに関する帯域幅を解放する。
【０２５６】
また、ＢＷＭは、Ｎ２ＰがＮ１Ｄを見ることを望んでいることを知る。利用可能なリンク[Ｎ１−Ｎ２]の帯域幅と、Ｎ１Ｄが大きなビデオを送信している現在のビットレートと、さらにその他のファクターとを調べた後、ＢＷＭは以下の決定の何れかを行うことができる。
【０２５７】
ケースａ：ＢＷＭは、Ｎ１Ｄが大きなビデオを送信しているビットレートをサポートできる。
【０２５８】
ケースｂ：ＢＷＭは、Ｎ１Ｄが大きなビデオを送信しているビットレートをサポートできないが、より低い値をサポートできる。
【０２５９】
ケースｃ：ＢＷＭは、この会議について、例えば、Ｎ１Ａ及びＮ１Ｂにおいて、Ｎ１からＮ２に行くその他の大きなビデオのビットレートを下げることなく、より低いビットレートでさえもＮ１Ｄからの大きいビデオをサポートできない。
【０２６０】
ケースｄ：ＢＷＭは、Ｎ１Ｄから送られるビデオをサポートできない。
【０２６１】
注意
１．  ＢＷＭ決定プロセスという点では、ケースｂ及びｃは異なっている。しかし、これらは、実際にはポリシーの決定であって、プロトコルの働き[メッセージの流れ]は、両方のケースで同じになるだろう。
中会議の最初の解放について、ケース「ｂ」のみが、ＢＷＭによって考慮されるだろう。つまり、新たな大きなビデオのリクエストを受け入れるために、現存する大きなビデオコネクションの帯域幅は、変更されない。しかしながら、これはポリシーの決定であって、中スケールのプロトコル機構[ＢＷＭとのインタラクションを含む]は、その結果として変化すべきではない。
２．  ケースａでは、単に、ＢＷＭは、Ｎ２Ｐから受信したｒｅ[ＩＮＶＩＴＥ]をＶＨｏｓｔにパスする。故に、そのケースを議論しない。
【０２６２】
ケースｃ及びｄは、以下に説明される：
【０２６３】
ケース１ｃ
このケースでは、帯域幅マネージャ(16)は、Ｎ１Ａ及びＮ１Ｂの大きなビデオストリームのＴｘ帯域幅を下げて、Ｎ２ＤからのＴｘをサポートしなければならないことを決定する。それは、Ｎ１Ａ、Ｎ１Ｂ及びＮ１Ｃについて、Ｔｘ帯域幅の値を、夫々(１５００、１５００、１５００ｋｂｐｓ)と選択する。
【０２６４】
その結果、それは、以下のようにＩＮＶＩＴＥを変更する：
【０２６５】
【表３５】
2005318535.tif 000037
【表３６】
2005318535.tif 000038
【０２６６】
ＶＨｏｓｔは、このｒｅ−ＩＮＶＩＴＥを得て、ＩＮＶＩＴＥの情報を全てのパーティに送る。その他の全てのパーティは、ｒｅ−ｉｎｖｉｔｅを得ると、適切な行動を行う。このケースでは、Ｎ１Ａ、Ｎ１Ｂ及びＮ１Ｄは、それらの大きなビデオのビットレートを変更する。Ｎ１Ｃは、リスナーリストからＮ２Ｐを除去する。そして、Ｎ１Ｄは、受信者のリストにＮ２Ｐに加える。
【０２６７】
また、ＶＨｏｓｔは、ＯＫをＢＷＭに送り返し、それはＮ２Ｐにリレーされる。ＢＷＭは、ＶＨｏｓｔから受信したＯＫからＮ２Ｐに送信するＯＫに、全てのメディアストリームをコピーなければならない。
【０２６８】
ケース１ｄ
このケースでは、帯域幅マネージャ(16)は、Ｎ１ＤからＮ２Ｐへの大きなビデオをサポートできないと決定する。このケースでは、ＢＷＭは、ＩＮＶＩＴＥを変更することで、Ｎ２ＰがＮ１Ｄのビデオを求めているが、帯域幅の不足によりこのリクエストが拒否されていることを、ＶＨｏｓｔに示す。それは、パーティリストにて、−ｖｅのようにＤをマークすることで、そのように行う。故に、大きなビデオについてＮ２Ｐによって送信されたｘ−ｐａｒｔｙ−ｌｉｓｔは、｛１、２、４｝から｛１、２、−４｝に変更される。Ｎ１Ｄの大きなビデオに関する帯域幅フィールドは、そのままにされる。ｒｅ[ＩＮＶＩＴＥ]は、次のようになる：
【０２６９】
【表３７】
2005318535.tif 000039
【表３８】
2005318535.tif 000040
【０２７０】
そして、ＶＨｏｓｔは、Ｎ２ＰがＮ１Ｄのビデオを求めており、ＢＷＭで拒絶されていることを知る。ＶＨｏｓｔは、テーブル１４の情報を、Ｎ２Ｐに戻されるＯＫに反映させる。このＯＫは、ＢＷＭによってＮ２Ｐにリレーされる。Ｎ２Ｐは、ＶＨｏｓｔからＮ２Ｐに送られたＯＫにある全てのメディアストリーム情報をコピーする必要がある。
【０２７１】
Ｎ２Ｐは、このＳＤＰを見て、そのリクエストが失敗したことを認める。後で試みることが必要な場合、それは可能である。
【０２７２】
さらなる注意として、以下の何れかの条件下で、ＶＨｏｓｔは、帯域幅を最大値に戻す。
−  新しいパーティが加えられる。
−  パーティが削除される。
【０２７３】
また、パーティがそのストリーム状態を変化させる、即ち、ｉｎａｃｔｉｖｅからａｃｔｉｖｅに、又はａｃｔｉｖｅからｉｎａｃｔｉｖｅに移行する場合は何時でも、その帯域幅を最大に戻す。これにより、ホールドを終えるストリームが、できるだけ最大値に戻される。
【０２７４】
１．  各参加者に、入手可能なストリームのセットから、自分が希望する任意のストリームを受信することを選択可能とする能力。
会議に、Ｐ１乃至Ｐ５の５人の参加者がいるとする。また、これらの参加者の各々は、Ｔｙｐｅ−１からＴｙｐｅ−ｎまでのタイプが異なるＮ個のストリームを生成する能力があるとする。Ｎは、１より大きい任意の数であろう。Ｐ１は、Ｐ２及びＰ３からのみ、ｔｙｐｅ−１のストリームを受信することを望む場合、その後、このことを示すように、ａ＝Ｘ−ｒｘｐａｒｔｙ−ｌｉｓｔの値を設定できるだろう。
【０２７５】
２．  各参加者にて、受信者をコントロールする能力。
会議コールに、Ｐ１乃至Ｐ５の５人の参加者がいるとする。また、これらの参加者の各々は、Ｔｙｐｅ−１からＴｙｐｅ−ｎまでのタイプが異なるＮ個のストリームを生成する能力があるとする。Ｎは、１より大きい任意の数であろう。さらに、Ｐ１は、Ｐ２及びＰ３から、ｔｙｐｅ−１のストリームを受信することを希望するとする。また、ある理由で[帯域幅の不足に対する安全策として様々な理由で]、Ｐ１は、このストリームを受信することを許可されないとする。
この場合、ａ＝ｘ−ｒｘｐａｒｔｙ−ｌｉｓｔの値は、Ｐ１がＰ２からストリームを受信することを許可されていないことを示すために再び使用される。
【０２７６】
３．  特別なストリーム属性を示す能力。
会議の一部である各ストリームに、任意の特別な処理を示す付加属性を付すことが可能であろう。特に、ｒｘ−ｐａｒｔｙ−ｌｉｓｔは、ストリームが、
ａ．  管理者推奨(Moderator recommended)
−    管理者強制(Moderator recommended)
であるか否かを示すことに使用できる。
ストリームが、管理者強制にされる場合、各参加者は、そのストリームを受信することを要求される。
これら属性は、ネットワークのＶＨｏｓｔ、帯域幅マネージャ(16)、又はＳＩＰプロキシーの何れかで加えられる。
【０２７７】
４．  各参加者が所定のストリームのどれかを送信するために使用できる帯域幅を制御する能力。
プロトコルによって、各参加者は、自分がストリームを送信することを希望するかも知れない帯域幅が何であるかを示して、帯域幅管理プロトコル機能は、その後、ポリシーに基づいて、どれだけの帯域幅が、各参加者に[実際には、参加者からの各ストリームに]許可されるかを決定する。
【０２７８】
５．  顕著な変化が会議に起こる場合には何時でも帯域幅マネージャと再ネゴシエーションすることで、会議コールの品質を増加させる能力。
変化が顕著な任意のイベントが起こる場合、帯域幅プロトコル機能は、各ストリームで使用される帯域幅を最大にしようとする。変化が顕著なイベントは、以下のようなタイプであり得る：
−  ストリームが加えられ、又は削除される。
−  ストリームが可能又は不可能になる。
−  パーティが加えられ、又は削除される。
−  管理ポリシーに基づくイベント。
【０２７９】
[帯域幅マネージャ(16)のポリシースキーム]
この説明は完全ではなく、帯域幅マネージャ(16)は、様々な方法で構成され得る。帯域幅マネージャ(16)のポリシーアルゴリズムは、かなり柔軟である。そして、エンドユーザによって合わせられて、いろいろなポリシーが効率的に構成される。それは、デフォルトとして、以下のポリシーモデルをサポートする。
【０２８０】
１．  オーディオのみ。  帯域幅マネージャ(16)によって管理されるリンク(11)に亘って、ネットワーク(ｎｅｔ−１)からネットワーク(ｎｅｔ−２)にコールがされる場合、その後、各参加者がビデオをサポート又は要求できるか否かに拘わらず、コールは、常にオーディオのみにドロップされる。
【０２８１】
２．  低帯域幅モデル。  帯域幅マネージャ(16)によって管理されるリンク(11)に亘って、ネットワーク(ｎｅｔ−１)からネットワーク(ｎｅｔ−２)にコールがされる場合、コールにおける全てのビデオストリームの帯域幅は、１Ｍｂｐｓにドロップされる。この値は、設定可能である。
【０２８２】
３．  中帯域幅モデル。  帯域幅マネージャ(16)によって管理されるリンク(11)に亘って、ネットワーク(ｎｅｔ−１)からネットワーク(ｎｅｔ−２)にコールがされる場合、コールにおける全てのビデオストリームの帯域幅は、２Ｍｂｐｓにドロップされる。このモデルは２に似ている。
【０２８３】
４.  ステップ帯域幅モデル。  このモデルでは、帯域幅マネージャ(16)によって管理されるリンク(11)に亘ってコールがされる場合、以下の制限が制約される一方で、各ストリームにどれだけの帯域幅を許可すべきかが決定される。
ａ．  現在使用可能な帯域幅。リンクの帯域幅の５０％を超える分が使用可能である場合、各ストリームにはそれらが要求したのと同じ帯域幅が与えられる。
ｂ．  現在使用可能な帯域幅が、５０％より小さいが２５％を超える場合、各ストリームには、それらが要求する値の５０％が与えられる。
ｃ．  現在使用可能な帯域幅が、２５％より小さいが５％を超える場合、各参加者には、それらが要求した値の１/４のみが与えられる。
ｄ．  現在使用可能な帯域幅が、５％より小さい場合、オーディオストリームのみが許可される。
【０２８４】
５.  プライオリティに基づくステップモデル。  このモデルでは、各ユーザに関するプライオリティがある。故に、プライオリティがより高いユーザは、ストリームの送受信において、より大きい帯域幅を与えられてよい。
【０２８５】
背景/用語：
ＶＸ：  ユーザ「Ｘ」がログインするＶｉＰｒ。所定のＶｉＰｒには、同時に１人のユーザのみがログインできる。ＶｉＰｒ会議は、２つのタイプに分けられる：  タイプＡ：通常モード。各参加者は、２つのストリーム[オーディオ、ビデオ]を、会議におけるその他全ての参加者に送信する。各参加者は、その他全てのパーティからオーディオ及びビデオを受信する。タイプＢ：エンハンスドモード。各参加者は、その他全ての参加者に、３つのストリーム[オーディオ、ビデオ及びサムネイルビデオ]を送信できる。このモードでは、全ての参加者が、その他全ての参加者から[オーディオ、サムネイル]を受信する。各参加者は、会議コールの参加者の一部からビデオを受信することを選択できる。
【０２８６】
クレームポイント：
エンハンスド会議モードに関して
１.  プロトコルエクステンションが生成されて、会議にて利用されている全てのストリームの中から、任意の一部のストリームを選択的に受信可能となる。例えば、Ｖａ、Ｖｂ、Ｖｃ、Ｖｄ及びＶｅが会議にある場合、参加者Ｖａは以下のようにストリームを受信することを選択できるだろう：
Ｖｂから：ビデオのみ
Ｖｃから：オーディオのみ
Ｖｄから：サムネイルビデオのみ
Ｖｅから：ビデオ、オーディオ及びサムネイル
【０２８７】
帯域幅管理モードに関して
２.  プロトコルエクステンションは、以下の帯域幅制御の特徴を与える：
＊ＶｉＰｒで送信されている任意のストリームの帯域幅の送信帯域幅を制御する。
＊ネットワークで利用可能な帯域幅がないので、ＶｉＰｒに対して、それがコールにおけるある参加者からストリームを受信できない旨を示す。
【０２８８】
この制御は、エンハンスド会議に加えて、通常会議でも利用可能である。ｐ２ｐコールの帯域幅制御は、現在の標準でカバーされる。
【０２８９】
例えば、参加者Ｖａ、Ｖｂ、Ｖｃ、Ｖｄ、Ｖｅが会議にいるとする。Ｖａ乃至Ｖｄが同じＬＡＮ Ａ上にあって、Ｖｅは、ＷＡＮを介して、帯域幅が制限されたＬＡＮ Ｂにある。その後、以下の何れかが、帯域幅管理コントロールを用いて達成される。
−  Ｖａ、Ｖｂ、Ｖｃ、Ｖｄの任意若しくは全ての参加者、又はそれら参加者の任意の組合せが、それらのビデオの帯域幅を下げるように求められて、Ｖａ＋Ｖｂ＋Ｖｃ＋Ｖｄの和が、ＷＡＮを通じて、ＬＡＮ Ａ及びＬＡＮ Ｂの間で利用可能である帯域幅内にされる。
−  Ｖｅは、それは遅いリンクに亘っているから、ビデオを送受信できないことを知らされる。
−  Ｖｅは、全ての参加者ではなく２人の参加者のみからビデオを受信できる旨を知らされる。
【０２９０】
また、プロトコルは、会議コールが継続している間、帯域幅を動的に変化させることができる。
【０２９１】
４.  参加者Ｖａ、Ｖｂ、Ｖｃ、Ｖｄ及びＶｅがいるエンハンスド会議では、Ｖａからのビデオストリームを見ることに関心のある参加者がいない場合、Ｖａは、そのビデオストリームを送信しない。これは、誰もがビデオストリームを送受信する通常モードと対照的である。これによって、帯域幅の顕著な節約がもたらされる。
【０２９２】
図８、図９及び図１０を参照すると、Ｓビデオを伴うソニー製の一般的なアナログカメラ(32)のような撮像装置(30)は、該撮像装置(30)で得られるシーンの画像を電気信号に変換する。その電気信号は、配線を通って、フィリップス製ＳＡＡ７１４４ ＮＴＳＣ/ＰＡＬ/デコーダのようなビデオデコーダ(34)に送られる。ビデオデコーダ(34)は、電気信号をデジタル信号に変換して、ＢＴ６５６フォーマットのような、シーンの画素のストリームとしてそれらを送る。画素のストリームは、ビデオデコーダ(34)から送り出されて、第１ストリームと、第１ストリームと同じである第２ストリームとに分けられる。エンコーダ(36)は、ＩＢＭ ｅＮＶ ４２０エンコーダであるのが好ましく、画素の第１ストリームを受信し、それを処理してＭＰＥＧ-２フォーマットのデータストリームを生成する。ビデオエンコーダ(36)で生成されたデータストリームは、カメラで生成された際と比較して約５０分の１のサイズに圧縮される。ＭＰＥＧ-２ストリームは、エンコードされたデジタルストリームであって、後にパケット化される以前にフレームバッファリングされないので、遅延が最小化されている。エンコードされたＭＰＥＧ-２デジタルストリームは、フィールドプログラマブルゲートアレイ(ＦＰＧＡ)(38)と、ＭＰＥＧ-２ストリームを生成するソフトウエアとを用いて、ＲＴＰを用いてパケット化される。そして、ＰＬＸ ９０５４ ＰＣＩインターフェイス(44)を通じて、ネットワークインターフェイス(42)を用いて、イーサネット８０２.Ｐ、又は毎秒１５５メガビットのＡＴＭのようなネットワーク(40)に送信される。必要ならば、ＣＮＮや映画のようなＶＣＲやテレビジョンショーに関するビデオストリームがデコーダ(34)で受信され、ディスプレイコントローラ(52)に直接供給されて表示される。デコーダコントローラ(46)は、ＦＰＧＡ(38)に配置されてデコーダ(34)に接続されており、デコーダ(34)の動作を制御する。
【０２９３】
また、デジタルカメラ(47)を用いる場合、カメラで生成されたストリームは、既にデジタルフォーマットであって、デコーダ(34)に供給される必要はない。デジタルカメラ(47)から送られるデジタルストリームは、ＢＴ ６５６フォーマットであって、カメラから直接に第１及び第２ストリームに分けて送り出されて、ビデオデコーダ(34)を通ることはない。
【０２９４】
さらに、１３９４ インターフェイスファイヤラインカメラ(48)のようなファイヤラインカメラ(48)を用いると、デジタル信号を直接ＦＰＧＡ(38)に供給できる。ファイヤラインカメラ(48)を用いると、ＦＰＧＡ(38)から非常に短い距離を超えてデータストリームの生成が行われる場合に、デジタル信号が、例えばケーブルによって、ファイヤラインカメラ(48)から長い距離でサポートされる利点がある。ＦＰＧＡ(38)は、ファイヤラインカメラ(48)から送られるデジタル信号をエンコーダ(36)に供給して、上述の処理が行われる。そして、ＦＰＧＡ(38)は、以下に説明するように、低フレームレートのストリームを生成する。
【０２９５】
第２ストリームはＦＰＧＡ(38)に供給されて、ＦＰＧＡ(38)及びソフトウエアは、モーションＪＰＥＧストリームのような低フレームレートのストリームを生成する。第２ストリームは、第１ストリームよりも低い帯域幅を必要とする。ＦＰＧＡ(38)及びメインコントローラ(50)は、ソフトウエアによるエンコードを用いて、この低フレームレートのストリームを圧縮及びパケット化し、それをＰＣＩインターフェイス(44)に供給する。続いて、ＰＣＩインターフェイス(44)は、ネットワークインターフェイスカード(56)を通じてネットワークインターフェイス(42)にそれを転送する。ネットワークインターフェイス(42)は、それをネットワーク(40)に送信する。エンコードされたＭＰＥＧ-２デジタルストリーム及び低フレームレートストリームは、基本的に同じであるが独立した２つのデータストリームである。しかしながら、低フレームレートストリームは、ＭＰＥＧ-２データストリームと比較して縮小されており、ＭＰＥＧ-２ストリームと比較して、同一シーンの表示が小さく、ネットワーク(40)のリソースが少なくてすむ。
【０２９６】
ネットワーク(40)上で、各デジタルストリームは、所望の受信ビデオフォン(15)に運ばれる。会議のパーティが２を超える場合には、各デジタルストリームは、複数の受信ビデオフォン(15)に運ばれる。データは、ＳＩＰを用いてルーティングされる。受信ビデオフォン(15)のネットワークインターフェイスカード(56)は、第１及び第２データストリームのパケットを受信し、パケットのデータと、メインコントローラで選択されたビデオストリーム(第１又は第２)とを受信メモリに送る。受信ビデオフォン(15)のメインコントローラ(50)は、ソフトウエアを用いて、選択された受信データストリームをデコード及び伸張し、それをディスプレイコントローラ(52)に転送する。ディスプレイコントローラ(52)は、一般的なスケーリングハードウエアを用いて、ＶＧＡデジタルフラットパネルディスプレイに再生画像を表示する。受信ビデオフォン(15)のユーザは、タッチスクリーン(74)を用いて、２つのデータストリームのうちどちらが表示されるかを選択する。必要に応じて、ユーザは両方を選択し、シーンの大きい画像と小さい画像とが表示される。しかしながら、送信ビデオフォン(15)から送られる両方のストリームが表示されることは、通常起こらないだろう。表示用のプロトコルの説明は、以下で行われる。シーンの大きい画像又はシーンの小さい画像の何れかを選択するオプションを有することで、ユーザは、システム(10)のリソースを割り当てて、見る者にとってその時により重要である者が、大きく鮮明な画像で見られるように選択できる。一方で、ユーザがまだ見たいと思うがその時に重要ではない者も、まだ見られ得る。
【０２９７】
２以上のビデオストリームがある場合(会議コールが行われている場合)、ディスプレイコントローラ(52)は、個々のビデオストリームをディスプレイ(54)に並べて表示する。ディスプレイ(54)に並べて形成された画像はクリップされており、縮小されていない。シーンにおける物の大きさは変化しておらず、単に、各データストリームのシーンにおける夫々の側の外領域が削除される。必要ならば、シーンの小さい画像に関するストリームの画像は、ディスプレイ(54)のスクリーンにて、右下隅に並べて表示される。図９に示すように、ディスプレイコントローラ(52)は、一般的なデジタルビデオをＬＣＤコントローラ(72)に供給する。ディスプレイコントローラ(52)は、ＡＴＩ又はＮｖｉｄｉａ製であり、一般的なＶＧＡコントローラである。ＬＣＤコントローラ(72)は、ディスプレイコントローラ(52)から送られる一般的なデジタルビデオを得て、フィリップスや富士通のパネルのような、使用する特定のパネルに適した画像を作成する。
【０２９８】
画像のクリップをさらに向上させるため、単に、画像の部分的削除を外側端部から中央に向けて行う代わりに、関係ある情報を示さない部分を画像からクリップする。画像の左側又右側にて人物が話している場合、外端部の各々からクリップする代わりに、人物が画像の右側にいる場合、画像の左側からクリップするのが望ましく、人物が画像の左側にいる場合、画像の右側からクリップするのが望ましい。外端部の各々からクリップすると、人物の部分が失われることが起こり得る。ビデオトラッキングを用いることで、形成される画像を見て、画像内で変化が起こっている場所を解析して、画像内で人物がいる場所を特定する。人物は、画像のその他の領域に対して相対的に動いており、この相対移動を特定することで、画像における人物の位置が決定され得る。このビデオトラッキングによって、変化が最も少なくなる端部又は複数の端部にて、クリップを起こすことが可能となる。代わりに、又はビデオトラッキングと併せて、オーディオトラッキングを用いて、画像のクリップを行うことを補助できる。ビデオフォン(15)はマイクロホンアレイを有しており、マイクロホンアレイの数々の要素に所定の音が達する異なる瞬間にて、一般的な三角測量(triangulation)を行うことで、マイクロホンアレイに対して人物が何処に配置されているかを決定できる。画像になっているシーンに対するマイクロホンの位置は知られているので、画像における人物の位置も分かる。
【０２９９】
ビデオフォン(15)の機能は、モニタ上のタッチスクリーン(74)で制御される。タッチスクリーン(74)は、一般的なガラスのタッチスクリーンであって、タッチスクリーンコントローラ(76)に生信号を供給する。公知のように、生信号は、ユーザが所定の場所でガラスに触ると生じる超音波で感知される。そして、タッチスクリーンコントローラ(76)は生信号を得ると、それらをディスプレイ上のＸ及びＹ位置に関する有意義な情報に変換して、この情報をメインコントローラ(50)に送る。
【０３００】
テレビジョン又はＶＣＲ接続が利用される場合、テレビジョン又は映画はデコーダ(34)に供給されて、その供給は、ビデオフォン(15)で受信されるその他の信号と同様に制御される。テレビジョン又は映画は、ディスプレイ(54)上にて、別のビデオフォン(15)に関係したビデオのシーンの横に表示される。
【０３０１】
シーンのオーディオストリームは、基本的に、オーディオビデオストリームと平行な同様の経路を通るが、オーディオストリームは、マイクロホン、サウンドカード、ヘッドセット又はハンドセットのようなオーディオレシーバ(58)から、コーデックのようなＣＳクリスタル４２０１オーディオインターフェイス(60)に供給される。オーディオインターフェイス(60)は、ボリューム及びミキシングの制御に加えて、信号のアナログデジタル変換及びデジタルアナログ変換を行う。オーディオインターフェイス(60)は、オーディオ信号をデジタル化して、ＴＣＩ ３２０Ｃ６７１１ 又は ６２０５ ＤＳＰ(62)に送る。その後、ＤＳＰ(62)は、デジタル化されたオーディオストリームをパケット化し、そのデジタル化されたオーディオストリームをＦＰＧＡ(38)に転送する。続いて、ＦＰＧＡ(38)は、それをＰＣＩインターフェイス(44)に与える。オーディオストリームは、その後、ネットワークインターフェイスカード(56)を通ってネットワーク(40)に送信される。オーディオストリームは受信ビデオフォン(15)で受信されて、ＦＰＧＡ(38)を通ってＤＳＰ(62)に、さらにはオーディオインターフェイス(60)に送られる。デジタル信号は、オーディオインターフェイス(60)にてアナログ信号に変換されて、スピーカ(64)で再生される。
【０３０２】
ネットワークインターフェイスカード(56)は、ネットワーク(40)に送信されるオーディオパケット及びビデオパケットの各々にタイムスタンプを付す。ビデオフォン(15)が受信したオーディオ及びビデオパケットが処理される速度は、充分に速いので、人間の目及び耳は、シーンのビデオに合わせられるオーディオのずれを、視聴の際に識別できない。２０〜３０ミリ秒未満という制約が、シーンのオーディオ及びビデオ情報の処理になされて、シーンのビデオ及びオーディオの関係が維持される。受信ビデオフォン(15)にて受信される際に、シーンのオーディオ及びビデオの同期を保証するために、各パケットのタイムスタンプが参照されて、対応するオーディオベースのパケットとビデオベースのパケットが受信ビデオフォン(15)にて並べられて、対応するように基本的に同時に再生される。これによって、受信ビデオフォン(15)のユーザに識別されるようなシーンのビデオ及びオーディオのずれは存在しなくなる。
【０３０３】
ＥＮＣ−ＤＳＰボードは、ＩＢＭ ｅＮＶ ＭＰＥＧ−２エンコーダ及びサポート回路と、オーディオエンコード及びデコードをするＤＳＰ(62)と、ＰＣＩインターフェイス(44)とを含んでいる。それは、高性能ＰＣ(68)プラットホーム及びディスプレイ(54)システム(10)に与えられる完全なビデオフォン(15)端末機能に必要なハードウエアを含んでいる。それは、フルサイズのＰＣＩ２.２に準拠したデザインである。カメラ、１又は複数のマイクロホン、及びスピーカ(64)は、このボードにインターフェイスする。ＤＳＰ(62)は、オーディオエンコード、デコード、ミキシング、ステレオ配置(stereo placement)、レベルコントロール、ギャップフィリング(gap filling)、パケット化、及びその他のオーディオ機能、例えば、ステレオＡＥＣ、ビームステアリング、ノイズキャンセル、キーボードクリックキャンセルやデリバーバレイション(de-reverberation)を行う。ＦＰＧＡ(38)は、セロクシア(Celoxia)(ヘンデル−Ｃ(Handel-C))ツールを用いて開発され、再構成可能である。レイアウトは、１〜３百万ゲートレンジで部品をサポートする。
【０３０４】
このボードは、デジタルカメラ(47)のチップインターフェイス、ハードウエア又は「ビデオＤＳＰ」ベースのマルチチャンネルビデオデコーダ(34)のインターフェイス、ＤＶＩ入出力コネクタを用いたビデオオーバーレイを含んでおり、ビデオオーバーレイと共に、フルダンプなフレームバッファを可能としている。
【０３０５】
ＮＴＳＣ又はＰＡＬビデオ信号を用いて、エンコーダ(36)は、６４０×４８０である、好ましくは７２０×４８０又はより高解像度である高品質なビデオストリームを生成する。ビットレートは、フレーム当たりの最大ビットが制限されるように制御されて、ネットワーク(40)に亘って伝送遅延が抑制される。デコーダ(34)は、データの第１マクロブロックを受信すると、一枚のデコードを開始する。ある種のバッファリングが行われてもよく、軽微なジッタが調整されて、画像が向上する。
【０３０６】
ＭＰＥＧ-２は、広く使用及び実施されており、ＤＶＤ及びＶＣＤのエンコード、デジタルＶＣＲ、及びＴｉＶｏのようなビデオ録画装置に加えて、ＤＳＳやその他のデジタルＴＶ放送の基礎となっている。通常、４から５０Ｍｂｉｔ/ｓｅｃのビデオ伝送が選択されると考えられる。ＭＰＥＧ-２は、広く使用されているので、比較的低コストであり、デコードについての、つい最近ではさらにエンコードについての高集積化されたソリューションが、現在商業的に入手可能である。
【０３０７】
ＭＰＥＧ-２は、一般的な圧縮方法と考えられるよりは、むしろエンコードされたビデオのシンタックス(syntax)であると考えられる。仕様がシンタックス及びエンコード方法を定める一方で、定められたシンタックスに従う限り、その方法の使用について非常に広い自由度がある。この理由から、ＭＰＥＧ-２に関する一般化は、しばしば誤り又は不正確である。特定の用途へのＭＰＥＧ-２のパフォーマンスを評価するためには、特定のエンコード方法と目的とする応用について、より低いレベルの詳細まで達する必要がある。
【０３０８】
ネットワーク(40)に関連した問題と共に、低遅延のエンコード及びデコードの問題は、ビデオフォン(15)のプロジェクトにとって興味深い。ＭＰＥＧ-２のアルゴリズムにおける３つの主要な問題があり、これらはネットワーク(40)に亘って高い品質のビデオを得るために理解される必要がある。
【０３０９】
・  ＧＯＰ(Group Of Pictures)構造及びその遅延における効果。
・  遅延及びネットワーク(40)の要求に関するビットレートの効果、エンコードされたフレームサイズ変化、ＶＢＶバッファ。
・  パケット損失の質に関するＧＯＰ構造の効果。
【０３１０】
ＧＯＰ構造及び遅延：
ＭＰＥＧ-２は、３種類のエンコードフレーム：Ｉ，Ｐ及びＢを定義している。最も普通に使用されるＧＯＰ構造は、１６フレーム長のＩＰＢＢＰＢＢＰＢＢＰＢＢＰＢＢである。この構造の問題は、Ｂフレームは前後のフレームから推測される動きであるので、連続するＢフレームの各々には、そのＢフレームのエンコードが開始できる前に、次のフレームがキャプチャされる必要があることである。各フレームは３３ｍｓｅｃであるので、これは、Ｂフレームがない構造を超えて、このＧＯＰ構造に最小で６６ｍｓｅｃの遅延を加える。結果として、このことによって、Ｉ及び/又はＰフレームのみを含んでおり、ＭＰＥＧ-２の仕様で、ＳＰ＠ＭＬ(シンプルプロファイル)エンコードとして定められた、低遅延のＧＯＰ構造が導かれる。
【０３１１】
ビットレート、エンコードフレームサイズ、及びＶＢＶ：
Ｂフレームが除かれてエンコード遅延が最小化されると、ＧＯＰ構造は、Ｉフレームと、Ｉフレームに対するＰフレームとで構成される。Ｉフレームは、完全にフレーム内符号化されているので、これを行うために多くのビットが必要とされて、次のＰフレームのビットは少なくなる。
【０３１２】
ＩフレームはＰフレームの８倍大きく、そのビットレートは公称(nominal)の５倍である可能性があることに留意すべきである。このことは、ネットワーク(40)上の要求と遅延とに直接的な影響を与える。帯域幅に制限がある場合、Ｉフレームはネットワーク(40)のリストリクションにてバッファリングされて、結果として、限定されたセグメントに亘って、複数のフレームの時間遅延が加わるであろう。再生レートがネットワーク(40)の帯域幅ではなく、ビデオに合わせられるので、このバッファはレシーバに適合する必要がある。上記データで用いられるサンプルは、低動作オフィスシーンであった。シーンが変化する高動作のコンテントでは、フレームには、コンテントに応じたビットが割り当てられて、シーンが変化する際には幾つかの大きなＰフレームが生じるであろう。
【０３１３】
この振る舞いを制御するために、ＭＰＥＧ-２は、ＶＢＶバッファ(ビデオバッファリングベリファ)を使用する。ＶＢＶバッファは、最大エンコードフレームサイズと公称のビットレートとの間の比率をある程度制御する。公称ビットレートで示されたサイズの２倍より小さくＩフレームが制限されるように、ＶＢＶを確実に制限することで、加えられるバッファリング遅延を１フレーム時間に制限できる。ＶＢＶのサイズを制限することによって、画質が犠牲となる。Ｉフレームが大きい理由は、次のＰフレームの良いベースを与えるためであり、Ｉフレームのサイズが制限される場合、質は、より低いビットレート(＜４Ｍビット)へと顕著に低下する。２Ｍビットでは、平均フレームサイズは８Ｋバイトであり、このサイズの２倍でさえも、Ｉフレームと同様にＤＣＴ圧縮される３２０×２４０のＪＰＥＧ画像を、良質でエンコードするのには不十分である。
【０３１４】
Ｉフレームのみのエンコードによって、エンコードフレームサイズは、より一致するが、質がより低下する。低ビットレートのＩフレームのみをエンコードすることは、ＭＰＥＧ-２のアルゴリズムの圧縮能力の大部分を活用していない。
【０３１５】
ＭＰＥＧ-２の仕様は、ＣＢＲ(Constant Bit Rate)及びＶＢＲ(Variable Bit Rate)モードを定めており、ストリーム内にて可変なＧＯＰ構造を可能とする。ＣＢＲモードは、必要に応じてパッディング(padding)を行って、各ＧＯＰについて一定数のビットを生成するように定められている。ＶＢＲは、エンコード帯域幅を可変にすることで、一定の質を得ることを意図としており、より簡単なセクションにおけるより低いビットレートでこのことが補償されている限り、ストリームにて、困難なエンコード領域により多くのビットを割り当てることが可能となる。ＶＢＲは、２(two)パス又はシングルパステクニックを用いて実現できる。可変ＧＯＰ構造によって、例えば、シーンが遷移する境界におけるＩフレームの配置にて、目で見える圧縮アーチファクトが除去される。低遅延が求められており、ＶＢＲ又は可変ＧＯＰを実施するためにビットを小さくする必要があるので、これらのモードは、ビデオフォン(15)の用途には、ほとんど関連がない。
【０３１６】
典型的なＧＯＰ構造におけるＰ及びＢフレームは、Ｉフレームと、以前のＰ及びＢフレームとに依存しているので、データの損失は、次のＩフレームまでの全てのフレームに影響を与えて、エラーが生じる。このことは、また、スタートアップの待ち時間に影響を与えて、例えば、ＤＳＳシステム(10)でチャンネルをオンにする場合、デコーダ(34)は、画像の表示を開始する前にＩフレームを待つ。このために、ＧＯＰ長、構造及びビットレートは、用途及び配信システム(10)に対して調整される必要がある。ＩＰを用いたリアルタイムコラボレーションの場合、信頼性のあるプロトコルを用いてハンドシェイク及び再送するのに要する遅延を受け入れる余裕はないので、遅れたパケットは失われたとして取り扱う必要があり、ＲＴＰやＵＤＰのような信頼性がない転送プロトコルが用いられる。パケット損失がビデオの質に与える効果について、様々な解析がなされており、典型的なＩＰＢ ＧＯＰ構造では、１％のパケット損失が３０％のフレーム損失を生じる事が示されている。より短いＧＯＰ構造、究極的にはＩフレームのみのストリーム(質の損失がある)は、これを幾分抑える。また、ＦＥＣ(Forward Error Correction)テクニックは、損失が生じると、これを幾分抑えることができる。しかし、ＭＰＥＧ-２の問題の一つは、明らかに、データ損失をあまり許容できないことである。
【０３１７】
連続的Ｐフレームエンコードと呼ばれるＧＯＰ構造は、上記の問題に対処して、比較的低ビットレートで、優れたビデオの質をビデオフォン(15)に与える。連続的Ｐエンコードは、Ｐフレーム内にて、フレームのマクロブロックをフレーム内エンコードする能力を用いる。各フレームにて、１６×１６ピクセルのマクロブロックの擬似乱数セットをエンコードし、その他をモーションコーディング(motion-coding)して、Ｉフレームのビットの同等物を各フレームに分布させる。擬似乱数を用いてマクロブロックの選択をすると、頻出する時間スケールで全てのブロックが更新されるので、スタートアップとシーンの変化は、妥当な方法で処理される。
【０３１８】
ＩＢＭは、このアルゴリズムをＳ４２０エンコーダで実施しており、フルフレームＤＣＴアップデートレートを８フレーム(３.７５回/秒)に設定している。典型的なオフィス及び会議のコンテントでは、その結果は、非常に優れたものとなる。エンコードによる遅延、エンコードされたフレームのサイズの変化、パケット損失は、ビデオフォン(15)にとって非常に理想的な振る舞いとなっている。エンコードされたサンプルを見ると、シーン変化と非常に動的なコンテントについてはエンコーダ(36)のアーチファクトが現れるが、コラボレーションで典型的である話し手の顔のコンテントについては、質は非常に良い。
【０３１９】
高質のオーディオは、効果的なコミュニケーションにおいて欠かすことができない。高質とは、全二重であり、帯域幅が７ｋＨｚであり(電話は３.２ｋＨｚ)、信号対雑音比が３０ｄＢより大きく、知覚できるエコー、クリッピング又はゆがみがないことである。設定は非常に容易で、可能な限りケーブルは少ない。オンボードの診断は、問題及びその解決方法とを示す。スピーカ(64)の音には、音のレベルの高低に関係なく、大きなはじけ音やうなり音が無い。
【０３２０】
失われた又は遅れたパケットのオーディオ信号は、先のオーディオ信号に基づいて「満たす」ことができる。オーディオバッファは、ネットワーク(40)のジッタとオーディオに加わる遅延との間のバランスとして約５０ｍｓとすべきである。３２０サンプル又は２０ｍｓの現在のパケットサイズを減らすならば、エンコード及びデコード遅延が減るであろう。しかしながら、２０ｍｓは、ＲＴＰパケットの一般的なデータ長である。
【０３２１】
以下に説明するプロセスの幾つかは、市販の製品で利用可能である。しかしながら、コスト低減と集積化を図るために、それらはＤＳＰ(62)として実施されるであろう。別の実施例では、１つのＤＳＰ(62)が上記のプロセスに加えて音響エコーキャンセルをも行うのではなく、第２ＤＳＰ(62)が、音響エコーキャンセルを行い得る。
【０３２２】
オーディオシステム(10)は、送信及び受信セクションを有している。送信セクションは、以下の要素で構成される。
【０３２３】
マイクロホン：
スピーカフォンに対する主要な不満の一つに、離れた所で聞く音がこもってしまうことがある。このこもった音は、部屋の反響によって生じるものであり、直接音のパワーに対する反射(反響)音のパワーの比、として考えるのが良い。現在、ピックアップを改善する最も良い方法は、マイクロホンを話し手に近づけて配置して、直接音のパワーを増加させることである。オフィス環境では、マイクロホンは、ＰＣ(68)のモニタに、ビデオフォン(15)端末に、ホワイトボードに配置できる。
【０３２４】
自動ゲイン制御：
各マイクロホンのプリアンプのゲインは自動的に調節されて、ＡＤＣレンジが十分に使用される。プリアンプゲインは、ＡＥＣ及びノイズリダクションのようなその他のオーディオプロセスに送られる。
【０３２５】
ＣＯＤＥＣ：
簡単な形式では、これはＡＤＣデバイスとなる。しかしながら、テキサスインスツルメント及びアナログデバイスインコーポレイテッドのような幾つかの企業は、アナログアンプとアナログマルチプレクサを具えるＣＯＤＥＣを有している。また、同様に制御されるＤＡＣがチップ上にある。先に説明した自動ゲイン制御は、ＣＯＤＥＣ内で実施されて、ＤＳＰ(62)で制御される。
【０３２６】
ノイズリダクション：
２つの方法のノイズリダクションを用いることで、ＳＮＲを改善できる。第１の方法は、ノイズゲーティング(noise gating)と一般に呼ばれており、現在の信号レベルに応じてチャンネルをオン・オフする。第２の方法は、適応ノイズキャンセル(ＡＮＣ)であり、マイクロホンの信号から不要なノイズを取り去る。オフィス環境では、ＡＮＣを用いて、ＰＡアナウンス、ファンノイズ、ある場合にはキーボードのクリック音でさえ除去できるであろう。
【０３２７】
ノイズリダクション又はゲーティングのアルゴリズムは、クールエディトやゴールドウェーブのような市販のオーディオ編集パッケージで利用できる。このようパッケージは、特別な効果を加えて、記録からスクラッチ及びポップノイズを除去し、テープ記録からヒスノイズも除去できる。
【０３２８】
音響エコーキャンセル：
エコーが聞こえるのは、話し手の声が５０ｍｓを超えた後に話し手に戻る場合である。エコーは、非常に気を散らせるので、除去される必要がある。エコーの２つのソースとして、ラインエコーと音響エコーがある。ラインエコーは、２本線の電話システム(10)の特性による。ＰＳＴＮは、ラインエコーキャンセラ(ＬＥＣ)を用いて、このエコーを除去する。スピーカフォンシステム(10)を用いる場合、アコーステックエコーは、電話のスピーカとマイクロホン間で起こる。離れたスピーカからの音は、離れたマイクロホンで拾われて話し手に戻る。音響エコーキャンセル(ＡＥＣ)は、ＬＥＣよりも難しい。部屋の音響は、モデルよりも複雑で、人の動きで急に変化するからである。ＡＳＰＩ ＥＦ１２１０のようなスタンドアロンデバイスから、ＤＳＰ(62)のプラットフォームで動くように最適化されたシグナルワークスのオブジェクトモジュールに亘る、多くのＡＥＣプロダクトがある。
【０３２９】
オートミキシング：
オートミキシングは、互いにミキシングされるマイクロホン信号を選択し、ミキサのモノラル出力をエンコーダ(36)に送る。選択基準は、最も音が大きいソースの近くのマイクロホンを用いること、又は閾値レベルを超えた音を受けているマイクロホンを用いることを基本にしている。オートミキサは、様々なベンダーから商業的に入手でき、電話会議及び電話教育システムで使用されている。
【０３３０】
エンコーディング：
データ伝送の帯域幅を低減するため、典型的な信号特性と我々のスピーチの理解力を利用して、オーディオ信号はより低いビットレートに圧縮される。現在、Ｇ.７２２コーデックが、適度なビットレートである６４ｋビット/秒にて、最も良いオーディオ品質(７ｋＨｚ帯域幅＠１４ビット)を提供する。
【０３３１】
ＲＴＰ伝送：
エンコードされたオーディオデータは、２０ｍｓｅｃのセグメントに分割されて、リアルタイムプロトコル(ＲＴＰ)パケットとして送られる。ＲＴＰは、ＶｏＩＰ及び電話会議の用途に必要なリアルタイムデータ交換用に特別に設計された。
【０３３２】
受信セクションは、以下の要素で構成される。
【０３３３】
ＲＴＰ受信：
ＲＴＰパケットは、１又は２以上の離れた場所から送られるオーディオストリームを含んでおり、各々のバッファに置かれる。失われた又は遅れたパケットが検出されると、その情報はギャップハンドラー(Gap Handler)に送られる。順序が正しくないパケットは、遅れたパケットの特殊な例であって、同じように遅れたパケットは、多分廃棄される。代わりに、少なくとも１つのパケット長についてオーディオ信号の再生を遅らせるバッファを用いてもよい。バッファのサイズは、両端間の遅延が１００ｍｓより長くないように制限される必要があるだろう。
【０３３４】
デコーディング：
Ｇ.７２２オーディオストリームは、ＣＯＤＥＣ用のＰＣＭサンプルにデコードされる。
【０３３５】
ギャップハンドリング：
ネットワークに亘ってＲＴＰパケットは失われ、又は破損するであろう。それ故に、ギャップハンドラーは、過去のパケットのスペクトル及び統計に基づいて、失われたデータを「満たす」。最小の場合として、ゼロがデータストリームに加えられてデータが作成されるが、スペクトル内挿又は外挿アルゴリズムを用いてデータを満たすことができる。
【０３３６】
バッファリング：
ネットワークジッタは、連続的なオーディオ再生を可能とするために、バッファリングを必要とするだろう。恐らく、このバッファは、短期のジッタ統計と待ち時間の効果との間の妥協に基づいて、そのサイズ(故に待ち時間も)調整するであろう。
【０３３７】
レート制御：
ビデオフォン(15)端末の公称のサンプルレートは、１６ｋＨｚである。しかしながら、わずかな差異が存在しているならば処理される必要があるだろう。例えば、北のビデオフォン(15)が現在１６,００１Ｈｚでサンプリングする一方で、南のビデオフォン(15)は１５,９９９Ｈｚでサンプリングする。よって、南の端末は、スピーカに出力するよりも１秒当たりに１だけ多いサンプルを積み重ねており、北の端末では、同じだけの量が不足するだろう。受信バッファの長期の統計によって、サンプリングレートの差異を決定して、(北のビデオフォン(15)のための)適切な内挿、又は(南のビデオフォン(15)のための)デシメーションのファクタを計算できる。
【０３３８】
ボリューム制御：
スピーカ(64)から来る音のボリュームを調整することは、通常、離れた聴取者によって行われる。より良い方法は、部屋のマイクロホンで聞こえる大きさに基づいて、スピーカ(64)からの音を自動的に調整することであろう。バックグラウンドノイズ及び聴取者自身の嗜好のようなその他の因子を考慮することもできる。
【０３３９】
ステレオ配置：
場所が異なる離れた話し手を、聴野(auditory field)に置くことができる。だから、場所Ａの人物は常に左から、場所Ｂの人物は真ん中から、場所Ｃの人物は右から聞こえるということになるだろう。この配置によって、話をしている者に追従することが容易になる。
【０３４０】
スピーカ：
音の質は、スピーカ(64)及びその筺体の質で、ある程度決定される。如何なる場合でも、自己増幅型スピーカ(64)がビデオフォン(15)端末に使用される。
【０３４１】
差別化(Differentiation)：
ポリコムサウンドステーションのような現在の会議システムは、充分ではあるが帯域が制限された全二重のオーディオ品質をもたらす。しかしながら、帯域幅は、３５００Ｈｚまで制限されており、その結果、音質は、耳に負担を掛けるものとなり、際立った摩擦音の場合には顕著である。
【０３４２】
ビデオフォン(15)は、帯域幅を７ｋＨｚに広げ、複数のマイクロホンを自動ミキシングして、部屋の反響音を最小にする。３人又はそれより多い人物が話している場合、離れた参加者の各々は、ステレオ音場において独自の場所に配置されるだろう。高質のオーディオピックアップと増加した帯域幅とを組み合わせることで、ネットワーク(40)に渡る会議は、そこに居る者に素早くアプローチするだろう。
【０３４３】
オーディオシステム(10)は、複数のマイクロホンを用いて音をよく拾い、ワイドバンドエンコーダ(Ｇ.７２２)を用いて、トールグレード(tollgrade)システムで現在提供されているよりも良い忠実度を得ている。加えて、複数パーティの会議では、離れた話し手のステレオ配置が行われて、音響エコーキャンセルシステム(10)によるハンズフリー動作が可能となる。部屋のボリューム調整は、エンドユーザの単一管理で自動的に制御されて、全体的な音のレベルが調整される。
【０３４４】
ビデオフォン(15)ネットワーク(40)では、ゲートウェイ(70)は、ＳＩＰではない物をＳＩＰ環境に接続する。普通、プロトコルの差異に加えて電気的な差異がある。ゲートウェイ(70)の大半は、他の電話又はビデオ会議デバイスを、ビデオフォン(15)システム(10)に接続する。
【０３４５】
ゲートウェイ(70)は、インターフェイスで区別される。一方の側はネットワーク(40)であり、ビデオフォン(15)では、これはイーサネット又はＡＴＭである。外側は、アナログ電話線又はＲＳ−２３２ポートであろう。ポートのタイプ、番号及び特徴は、あるゲートウェイ(70)を他と区別する。ネットワーク(40)の側には、ＲＴＰ又はＡＬＬ２のような転送プロトコルと、ＳＩＰ、メガコ(Megaco)又はＭＧＣＰのようなシグナリングプロトコルとがある。
【０３４６】
外側では、与えられたインターフェイスに応じた多種多様なプロトコルがあってよい。例えば、ＩＳＤＮ(Ｑ.９３１)又はＰＯＴＳシグナリングがあろう。ＰＳＴＮゲートウェイ(70)は、ＰＳＴＮラインをビデオフォン(15)システム(10)にその場で接続する。ＰＢＸゲートウェイ(70)によって、ビデオフォン(15)システム(10)は、メーカー独自仕様の電話をエミュレートして、その場にあるＰＢＸへの互換性を与える。ＰＯＴＳゲートウェイ(70)は、みすぼらしいアナログフォンをビデオフォン(15)システム(10)に接続する。Ｈ.３２３ゲートウェイ(70)は、Ｈ.３２３システム(10)を、ＳＩＰベースのビデオフォン(15)システム(10)に接続する。これは、シグナリングのみのゲートウェイ(70)であり、メディアサーバ(66)は、Ｈ.２６１からＭＰＥＧへの変換を行う。
【０３４７】
ビデオフォン(15)で実行可能な３つの技術として、セッション開始プロトコル(ＳＩＰ)、セッション記述プロトコル(ＳＤＰ)、リアルタイム転送プロトコル(ＲＴＰ)があり、これらは全て、引用をもって本明細書の一部となる。
【０３４８】
ＳＩＰは、パケットネットワークに亘る音声及びビデオセッションを初期化し、管理し、終了するシグナリングプロトコルである。
【０３４９】
ＳＤＰは、マルチメディアセッションの初期化におけるセッション告知、セッション案内、及びその他のフォームを目的とするマルチメディアセッションを記述する。ＳＩＰは、ＳＤＰを用いてメディアセッションを記述する。
【０３５０】
ＲＴＰは、マルチキャスト又はユニキャストのネットワーク(40)でのサービスに亘って、オーディオ、ビデオ又はシミュレーションデータのようなリアルタイムデータを転送する用途に適しているエンドツーエンドのネットワーク(40)転送機能を与える。ＳＩＰは、ＲＴＰを用いてメディアセッション伝送を行う。
【０３５１】
ビデオフォン(15)は、如何なる会議ブリッジ又はＭＣＵも用いることなく、３又は４以上のパーティで会議を行える。これは、ＳＩＰで定められるようにＡＴＭポイントツーマルチポイントストリームを用いて達成される。さらに詳細に述べると、ＭＰＥＧ-２ストリーム及び低フレームレートストリームがパケット化されてネットワーク(40)に転送される場合、各パケットのヘッダ情報は、周知のように、会議の受信ビデオフォン(15)の全てのアドレスを特定する。この情報から、パケットがネットワーク(40)に転送される場合に、ＳＩＰは、異なるパケットについて必要な接続を確立して、所望のビデオフォン(15)である送り先にそれらが達することができる。
【０３５２】
如何なる会議ブリッジも使用しない会議の例として、１０個のビデオフォン(15)があって、それらは、会議のパーティがいる別々の場所に配置されているとする。各ビデオフォン(15)は、オーディオベースのストリームと、ＭＰＥＧ-２ベースのストリームと、低フレームレートベースのストリームとを生成する。しかしながら、各ビデオフォンは、これらストリームの何れも自分に送り戻さないので、１０のパーティがあるビデオフォン(15)の会議では、各々は、その他９個のビデオフォン(15)と効率的に通信可能となる。一方で、ビデオフォン(15)がそれ自身と通信する場合には、帯域幅を最大限に使用するために、どのビデオフォン(15)で生成されたビデオも、必要ならばビデオフォン(15)で生成されたオーディオも、基本的にそれが他のビデオフォン(15)であるかのように見られ、又は聞かれ得る。しかし、以下で説明するように内部チャンネルを通ると、ネットワーク(40)のどの帯域幅の使用も必要とされない。
【０３５３】
会議では、各ビデオフォン(15)は、９つのオーディオベースのデータストリームを受信する。３つのＭＰＥＧ-２ベースのデータストリームと、６つの低フレームレートベースのデータストリームとがある。必要ならば、レシーバは、低フレームレートの９つのストリームを選択して、ディスプレイ(54)が、各ビデオフォン(15)の小さい画像のみを表示し、又は、ＭＰＥＧ-２ベースの４つのストリームを選択して、ディスプレイ(54)が、会議の４つのビデオフォン(15)からの画像で満たされる。４つのＭＰＥＧ-２ベースのデータストリームが表示されるならば、ディスプレイ(54)に表示用の領域はないので、低フレームレートベースのストリームの画像は表示されない。３つのＭＰＥＧ-２ベースのデータストリームが表示される場合、これにより、６つの低フレームレートベースのストリームが表示できる。各ストリームは、いろいろなビデオフォン(15)にて、上述したように作成及び受信される。
【０３５４】
大きな画像を４つより多く会議で表示することが求められるならば、これを達成する方法は、追加のビデオフォン(15)が互いに接続されて、図７に示すように、個々のビデオフォン(15)のディスプレイは、一列に並べられる。あるビデオフォン(15)をマスターとすることができ、追加のビデオフォンが加えられると、それはマスタービデオフォン(15)のスレーブとなる。マスタービデオフォン(15)は、異なっているビデオフォン(15)に亘って、大きい及び小さい画像の表示を制御する。
【０３５５】
会議のビデオフォン(15)のディスプレイに、誰が大きい画像として、誰が小さい画像として表示されるかを決定するプロトコルについて、１つの好ましい実施例は、最近の３人の話し手を大きく表示し、その他のパーティを小さく表示するというものである。即ち、現在話をしているパーティと、それ以前の２人の話し手とが大きく表示される。会議の各ビデオフォン(15)は、会議のオーディオベースのストリームの全てを受信するので、各ビデオフォン(15)は、そのメインコントローラ(50)を用いて、所定の瞬間にて話が起こっている場所を割り出し、さらに、ネットワークインターフェイスカード(56)が、話が生じているビデオフォン(15)のＭＰＥＧ-２ストリームを受け取るが、低フレームレートストリームを受け取らないようにする。別のプロトコルでは、あるビデオフォン(15)は、リード又はモデレータービデオフォン(15)として設定され、リードビデオフォン(15)は、大きい及び小さい画像について、他の全てのビデオフォン(15)が見ているものを調べる。さらに別のプロトコルでは、誰を大きくし、誰を小さくするかという画像の選択は固定されて、会議を通じて同一に維持される。プロトコルは、各ビデオフォン(15)が、受信する画像をそれらがどのように表示するのを欲しているかを調べるというようにできる。ＭＰＥＧ-２ベースのストリーム及び低フレームレートストリームの両方が、ネットワーク(40)上にて、会議の受信ビデオフォンに転送される。その結果、両方のビデオストリームは、各受信ビデオフォン(15)にて利用でき、選択されているディスプレイ(54)のプロトコルに応じて表示される。
【０３５６】
各ビデオフォン(15)で送信されるオーディオベースのストリームについては、帯域幅をさらに効果的に使用するために、そして、如何なる送信ビデオフォン(15)又は受信ビデオフォン(15)にてなされる処理要求もを減らして、オーディオ処理を補助するために、オーディオストリームは、送信ビデオフォン(15)にて所定のデジベルの閾値を超えたオーディオがある場合にのみ、ビデオフォン(15)で送信される。十分大きな音のオーディオストリームを送信することのみによって、話が生じている場合に達するように又は超えるように閾値が較正されているとの仮定の下、基本的に帯域幅を使う以外に何も貢献しない外部からのバックグラウンドノイズが送受されることが防がれるだけでなく、話のオーディオストリームのみが受信されているので、話に関するＭＰＥＧ-２ストリームを選択することが助けられる。
【０３５７】
上述のように、特定のビデオフォン(15)が、他のビデオフォン(15)に送られている自分の画像を見たい場合には、ＦＰＧＡ(38)で作成された低フレームレートストリームがビデオフォン(15)のローカルメモリに送られる。しかしながら、低フレームレートストリームが、パケット化されて、ビデオフォン(15)からネットワーク(40)に送られる場合に起こり得るような圧縮は行われない。このローカルメモリから、メインプロセッサは、ソフトウエアを用いてそれを処理して、ディスプレイ(54)に小さい画像として表示させる。
【０３５８】
さらに、ビデオフォン(15)は、ネットワーク(40)から受信したどのオーディオ又はビデオストリームが聴かれるか又は見られるかを制御する。ビデオフォン(15)のユーザが見たい又は聴きたいよりも多くのパーティが会議にある状況において、ビデオフォン(15)のユーザは、会議全体を構成するオーディオ又はビデオストリームの一部のみを見る又は聴くように選択できる。例えば、パーティが１００ある会議では、ユーザは、見ることができる１００の画像から全２３の画像について、３つのビデオストリームをスクリーン上の大きな画像として、２０のビデオストリームをスクリーン上の小さな画像として見ることを選択する。ビデオフォン(15)のユーザは、声の大きな３人の話し手を大きな画像として表示し、また、会議のパーティのタッチスクリーン(20)を介して、小さな画像として表示する２０のパーティを選択する。これらパーティは、タッチスクリーンのページにリストアップされている。他のプロトコルを選択できて、小さな画像として表示される２０の画像を、会議が始まって各パーティが紹介をした時刻からの、会議における最新の２０人の話し手になるようにできる。表示されるビデオストリームの数を制御することで、組織が会議に適合し、ビデオフォン(15)のリソースの使用がより良く割り振られる。
【０３５９】
スクリーンで表示される個々の画像について、各画像に関連した選択が可能である。例えば、１つの画像を会議コールのモデレーターで選択し、２つの画像を、会議の現時点で、最後の/最も声が大きい話し手とし、その他の画像を、その他の会議の参加者全てからユーザが選択した人物とすることができる。このように、会議のあらゆる参加者又はユーザは、会議の参加者の全数から画像の様々な選択ができるであろう。そして、必要とされる最大帯域幅は、会議の参加者の数に拘わらず、１つのビデオストリームをネットワークに送るためのものとなり、４つのビデオストリームをネットワークから受け取るためのものとなる。
【０３６０】
オーディオストリームに関して、最も声の大きい３人の話し手の各々の画像がスクリーンに表示される間は、それらの話し手のオーディオストリームのみが選択されて聴かれる制限をビデオフォン(15)に課すことができる。ＤＳＰ(62)は、受信したオーディオストリームを解析して、声が最も大きい話し手の３つのオーディオストリームのみを再生させて、同時に、声が最も大きい話し手の３つのオーディオストリームに関係した、大きな画像の第１ビデオストリームのみを受信するようにネットワークインターフェイス(42)に指示する。一般的には、大勢の人々が同時に話すと、混乱が増加して、理解が妨げられる。故に、ユーザによる制御がオーディオストリームに行われることで、組織のある程度にそれらを認識させることが可能となる。
【０３６１】
オーディオストリームの制御の一環として、上述のように、各ビデオフォン(15)は、そのビデオフォン(15)のノイズが閾値を超えた場合にのみ、オーディオストリームを送る。好ましくは、閾値は動的であって、所定の時刻における、声の大きな３人の話し手に関連した音の大きな３つのオーディオストリームのノイズレベルに基づいている。このため、そのオーディオストリームが声の大きな３人の話し手のオーディオストリームの一つとして認められているので、その他のオーディオストリームのノイズレベルは、モニタされて、特定される必要がある。ＤＳＰ(62)は、ネットワーク(40)を介してネットワークインターフェイス(42)から送られるオーディオストリームを受信する。そして、ＤＳＰ(62)は、オーディオストリームを調べて、最も大きなノイズを有する３つのストリームを特定し、最も声の大きい３人の話し手のものとして特定されている受信した３つのオーディオストリームのノイズレベルを、ビデオフォン(15)のシーンのノイズレベルと比較する。ビデオフォン(15)のシーンのノイズレベルが、受信したどのオーディオストリームよりも大きい場合、ビデオフォン(15)は、そのオーディオストリームをネットワーク(40)に送る。ＤＳＰ(62)によるこのような解析が、会議の各ビデオフォンで独立に行われて、会議に亘って分散した解析が行われる。各ビデオフォンは、その他の全てのビデオフォンと独立して、受信したオーディオストリームに関する解析を自ら行う。明らかに、所定の時間にて声の大きい３人の話し手の１人のものであると十分に保証できるほどシーンのノイズが大きいと、個々のビデオフォン(15)が判別した後にのみ、オーディオストリームは、そのビデオフォン(15)によって送られる。各ビデオフォン(15)は  その結果、受信したオーディオストリームの情報を得て、それを自己のノイズレベルとの比較の基礎として用いる。そして、各ビデオフォン(15)は、独自に閾値の決定を行っている。
【０３６２】
分散した解析を行う別の方法では、各ビデオフォンが、ＤＳＰ(62)にて用いられるべき閾値となるものを決定した後、会議の他の全てのビデオフォンにこの閾値が送られる。これにより、全てのビデオフォンは、他の全てのビデオフォンが閾値としたものを検討でき、例えば、それらの閾値を平均して、そのビデオフォンのシーンに適用される閾値を特定する。
【０３６３】
声が最も大きい３人の話し手のビデオストリームを選択する技術を用いることで、パーティが大きな声で一度に話し始めて、混乱と不理解が生じる瞬間があるかも知れない。しかしながら、そのようにすることで、それはノイズを閾値のレベルに上げて、非常に短い間に、他と同程度の大きさのノイズを生成していないオーディオストリームは除去されて、声の最も大きな３人の話し手のオーディオストリームのみが再度選択されて聞こえるであろう。また、その他のオーディオストリームは選択されておらず、これらオーディオストリームが寄与しているかも知れないノイズのある程度が取り除かれる。このことは、時に、３つを超えるオーディオストリームがビデオフォン(15)で受信されることを意味している。３個を超えるビデオフォンで、ある瞬間にノイズが閾値を超えて、このようなビデオフォンの各々がその時にオーディオストリームを生成してネットワーク(40)に送り得るからである。しかしながら、今し方説明したように、一旦閾値が変更されると、事態は終わるだろう。オーディオストリームに関したこの分散した解析は、ここで説明したビデオフォン(15)に限定されることはなく、ビデオストリームの有無に拘わらず、如何なるタイプの音声を用いた会議でも利用可能である。
【０３６４】
使用する帯域幅の節約を重要視しており、必要なもののみを送って帯域幅を節約することから、画像のクリップは、受信ビデオフォン(15)ではなくエンコーダ(36)にて行われる。送信ビデオフォン(15)が、それの画像が受信ビデオフォン(15)にてどのように現れるかを知っている場合、エンコーダ(36)は、シーンの大きな画像を、それが送信される前にクリップする。そして、画像のそれほど大きくない部分が送信されて、帯域幅を使用する。クリップが受信ビデオフォン(15)で起こる場合、ソフトウエアを伴ったメインプロセッサは、受信した画像がディスプレイコントローラ(52)に供給される前に、それを処理するであろう。
【０３６５】
第２カメラをビデオフォン(15)に接続すると、シーンの別の眺めが得られる。例えば、部屋では、第１カメラ、即ち主カメラが、視聴者又は話し手の顔に焦点を合わせて配置される。しかしながら、部屋にはさらに人がいて、部屋にてビデオフォン(15)を制御する人は、受信ビデオフォン(15)の他の視聴者に彼らを見せたいと欲する。例えば、第２カメラは、部屋の上隅に配置されて、主カメラよりも基本的に部屋のかなり広い領域を見る。第２カメラの出力はデコーダ(34)に与えられる。デコーダ(34)は、ビデオ出力を受け取る幾つかのポートを有している。または、第２カメラから送られるストリームが既にデジタル化されている場合、それは、主カメラと同様なチャンネルを通じて、ビデオフォン(15)の処理要素に与えられる。各ビデオフォン(15)は、その外に送られるものは何でも制御し、送信するカメラ出力の選択は、ビデオフォン(15)を制御する視聴者によってなされるのが好ましい。一方で、あるビデオフォン(15)のカメラから送信されるストリームを制御及び選択する能力を、離れた受信ビデオフォン(15)に与えることができる。制御ビデオフォン(15)からの制御信号は、ネットワーク(40)を通じて送信されて、送信用に選択されたストリームを与える個々のビデオフォン(15)にて受信される。第２カメラに加えて、ＤＶＤ、ＶＣＲ又はホワイトボードカメラのビデオ出力のような、その他のタイプの如何なるビデオ出力も、ビデオフォン(15)を通じて供給されてよい。
【０３６６】
好ましい実施例では、ビデオフォン(15)はピークモードで動作する。ピークモードでは、ビデオフォン(15)のカメラは、前方のシーンのスチル画像を取得して、この画像を受信すると予め決めている他のビデオフォン(15)に送信する。例えば、スピードダイアルメニュに、そのようなビデオフォン(15)のリストがある。または、ピークモードでは、得られたスチル画像がビデオフォン(15)で保持されて、要求に応じて、そのビデオフォン(15)にコールしたいと思っている者に供給される。理想的には、ビデオフォン(15)の好ましい使用形態に合致するように、ビデオフォン(15)のユーザは、ビデオフォン(15)の外へ送られるものを全て制御して、単に、ピークモードをオフにすることを選択し、又はどの画像が送られるかを制御する。アクティブコールが起こると、ピークモードはオフになって、ピークモードと、連続的な画像ストリームがカメラで得られるアクティブコールとの間で矛盾が生じない。ピークモードでは、所定の時間間隔で、例えば、１分、５分、３０分間隔等で、シーンのスチル画像が得られる。ピークモードでは、スチル画像が得られる前の所定の時間にて、例えば、画像が得られる５又は１０秒前にて、オーディオキューが示されて、まさに画像が撮られようとしており、見苦しくないようにすべき旨の警告が、カメラの前にいる者に与えられる。オーディオキューは、ビープ音、ピング(ping)音、若しくはその他の録音されたノイズ、又はメッセージとすることができる。このように、ピークモードが用いられる場合には、ビデオフォン(15)のカメラの前におけるシーンのピークが他のビデオフォン(15)で利用可能となり、その他のビデオフォン(15)に、カメラに関わる人物の存在が示される。
【０３６７】
プレセンスセンサの別の実施例では、カメラの前の領域に対するカメラの自動レンズの位置を、プレゼンスセンサとして働かせる。カメラの前に人がいない場合、カメラの自動レンズは、その領域内の物体又は壁に焦点を当てる。人物がカメラの前にいる場合、自動レンズはその人物に焦点を当てる。これによって、人物がレンズの前にいない場合と異なる位置にレンズが配置される。レンズの焦点を示すカメラの信号は、カメラからＦＰＧＡ(38)に送られる。ＦＰＧＡ(38)は、その後、例えば、送信ビデオフォン(15)のスピードダイヤルリストにあるビデオフォン(15)の受信側のような、所定のリストにあるビデオフォン(15)の受信側に焦点の情報を送る。これによって、視聴者がビデオフォン(15)の前にいるか否かが受信ビデオフォン(15)に知らされて、誰がいることが示される。
【０３６８】
ビデオフォンと、ビデオフォンを用いたシステムと、ビデオコールの方法とに関する詳細な説明は、引用を以て本明細書の一部となる米国特許出願第１０/１１４,４０２号に記載されている。さらに、ゲートウェイ及びその方法に関する米国仮特許出願第６０/４８３,２１７号と、オーディオミキサ及びその方法に関する米国仮特許出願第６０/４８３,１３７号とは、双方ともに引用を以て本明細書の一部となる。
【０３６９】
説明を目的として、上記の実施例について詳細に記載したが、当該技術分野における通常の知識を有する者には、このような詳細は単に説明を目的としており、添付の特許請求の範囲に定められた本発明の精神と範囲から逸脱することなく、変更がなされてよいことが明らかであろう。
【図面の簡単な説明】
【０３７０】
添付の図面では、本発明の好ましい実施例と、本発明を実施する好ましい方法とが説明されている。
【図１】ＳＩＰプロキシーで実施される帯域幅マネージャを示す。
【図２】バックツーバックユーザエージェントとして実現された帯域幅マネージャを示す。
【図３】帯域幅マネージャネットワーク及びリンクの定義を示す。
【図４】帯域幅を制限するルールを示す。
【図５】帯域幅マネージャの好ましいデザインを示す。
【図６】オファー/アンサーモデルの両方で新しいコールを制限している模様を示す。
【図７】ＶｉＰｒ端末から送られる注記付きＳＤＰオファーのサンプルを示す。
【図８】Ｂ２ＢＵＡリクエスト/レスポンス処理を示す。
【図９】ＳＩＰ ＩＮＶＩＴＥのサンプルを示す。
【図１０】ハブアンドスポーク方式の会議を示す。
【図１１】シナリオ例において、帯域幅マネージャに到達するオファーＳＤＰを示す。
【図１２】シナリオ例において、帯域幅マネージャからＶｉＰｒ４に送られるオファーＳＤＰを示す。
【図１３】ケース１におけるＶｉＰｒ４のレスポンスを示す。
【図１４】ケース２におけるＶｉＰｒ４及び帯域幅マネージャから送られるＳＤＰである。
【図１５】中間の会議シナリオのサンプルである。
【図１６】帯域幅マネージャに関連する部分を示すＳＤＰのサンプルである。
【図１７】帯域幅マネージャからＶｉＰｒ５に送られる、修正されたオファーＳＤＰのサンプルである。
【図１８】ＶｉＰｒ５から送られるアンサーＳＤＰのサンプルである。
【図１９】ＶｉＰｒ５が大きなビデオを見るプライオリティを換える模様を示す(ケース１)。
【図２０】ＢＷＭが、参加者(1)(2)(4)の帯域幅を変更する模様を示す(ケース１ｃ)。
【図２１】ＢＷＭが、ＶｉＰｒ５のリクエストから４を取り除く模様を示す(ケース１ｄ)。
【図２２】本発明の電気通信システムの説明図である。
【図２３】本発明のビデオフォンのブロック図である。
【図２４ａ】ビデオフォンのブロック図である。
【図２４ｂ】ビデオフォンのブロック図である。
【図２４ｃ】ビデオフォンのブロック図である。
【図２５】ビデオフォンのアーキテクチャのブロック図である。
【図２６】システムの概要図である。
【図１】
2005318535.tif 000041
【図２】
2005318535.tif 000042
【図３】
2005318535.tif 000043
【図４】
2005318535.tif 000044
【図５】
2005318535.tif 000045
【図６】
2005318535.tif 000046
【図７】
2005318535.tif 000047
【図８】
2005318535.tif 000048
【図９】
2005318535.tif 000049
【図１０】
2005318535.tif 000050
【図１１】
2005318535.tif 000051
【図１２】
2005318535.tif 000052
【図１３】
2005318535.tif 000053
【図１４】
2005318535.tif 000054
【図１５】
2005318535.tif 000055
【図１６】
2005318535.tif 000056
【図１７】
2005318535.tif 000057
【図１８】
2005318535.tif 000058
【図１９】
2005318535.tif 000059
【図２０】
2005318535.tif 000060
【図２１】
2005318535.tif 000061
【図２２】
2005318535.tif 000062
【図２３】
2005318535.tif 000063
【図２４ａ】
2005318535.tif 000064
【図２４ｂ】
2005318535.tif 000065
【図２４ｃ】
2005318535.tif 000066
【図２５】
2005318535.tif 000067
【図２６】
2005318535.tif 000068
【外国語明細書】
2005318535000001.pdf