JP5129989B2 - 会議レイアウト制御及び制御プロトコル - Google Patents

Description

関連出願の表示：本願は、Richard E. Huber、Arun Punj及びPeter D. Hillによる米国仮特許出願第６０/８１４,４７７号「インテリジェントオーディオ制限方法(Intelligent Audio Limit Method)」(代理人管理番号：Fore-119)、Arun Punj、Richard E. Huber及びGregory H. Smithによる米国仮特許出願第６０/８１４,４９１号「独立したマルチメディアソースの会議コールへの結び付け(Associating Independent Multimedia Sources Into a Conference Call)」(代理人管理番号：Fore-121)という、同時に出願された２つの米国仮特許出願に関係しており、これらの仮特許出願は、引用を以て本件明細書の一部となる。

本発明は、電話会議(teleconference)のビデオディスプレイに関する。より詳細には、本発明は、電話会議のビデオディスプレイの制御に関しており、電話会議のノードの少なくとも１つが、各ノードに固有であり得る特定のフォーマットで、会議の各ノードのディスプレイレイアウトを少なくとも部分的に個々に制御する。

本発明は、ノード間における電話会議に関しており、各ノードは、会議の変化が起こると、その他のノードに会議の変化のみを知らせる。より詳細には、本発明は、ノード間における電話会議に関しており、各ノードは、会議の変化が起こると、変化により影響を受けるノードのみに会議の変化のみを知らせる。

ディスプレイレイアウトに関して、標準的なＭＣＵベースの会議コールでは、ＭＣＵは、各参加者のビデオストリームのレイアウトを制御する。実際に、ＭＣＵは、全ての参加者に同じ画像を送る。例えば、１０人の参加者がいる会議コールでは、ＭＣＵは、Ｂ、Ｃ、Ｄ及びＥと呼ぶことにする任意の４人を選択して、Ｂ、Ｃ、Ｄ及びＥの合成画像を(多分ハリウッドスクエアのように)作成し、それを全ての参加者に送る。

ＶｉＰｒにおいて、このモデルは、各参加者が独立して、個々にレイアウトを選択できるように拡張されている。故に、Ａは、大きなビデオで２人(Ｂ及びＣ)を、小さなビデオで他の７人を見ることができた。Ｂは、大きなビデオの１人と、小さなビデオの３人と、１つのＴＶチャンネルを、そのディスプレイで選択できた。

プロトコルに関して、１０人の参加者がいる会議コールを考える。従来のシグナリングプロトコルでは、会議の状態に変化があると、例えば、Ｐ１がそのビデオを無効にすると、メッセージが使用されて、そのメッセージは、Ｐ１乃至Ｐ１０の全ての参加者に情報と共に送られる。これは、深刻なスケーラビリティの問題を引き起こす。本発明は、効率的な方法で、非常に大規模な会議コール(数百人の参加者)を制御する技術を与える。その技術によれば、送信される必要があるのは差異だけとなり、例えば、上記の例では、小さいＮＯＴＩＦＹイベントが、Ｐ１がその送信器を切ったという情報と共に送られる。

本発明は、電話会議システムに関する。システムはネットワークを備える。システムは、互いに通信して電話会議を構成する複数のノードを備えており、各ノードのライブシーンで電話会議が構成されるのが好ましい。各ノードは、ディスプレイレイアウトを有するビデオディスプレイを有しており、少なくとも１つのノードは、各ノードに固有であり得る特定のフォーマットで、会議の各ノードのディスプレイレイアウトを少なくとも部分的に個々に制御する。

本発明は、電話会議を提供する方法に関する。この方法は、ネットワークを通じて互いに通信する複数のノードで会議を構成するステップを含んでおり、各ノードのライブシーンで会議が構成されるのが好ましい。各ノードは、ディスプレイレイアウトを有するビデオディスプレイを有している。少なくとも１つのノードを用いて、各ノードに固有であり得る特定のフォーマットで、会議の各ノードのディスプレイレイアウトを少なくとも部分的に個々に制御するステップがある。

本発明は、ネットワーク用の電話会議用ノードに関しており、ネットワークは、その他のノードを伴っている。電話会議用ノードは、ネットワークを通じて互いに通信して会議を構成する複数のノードと通信するネットワークインターフェイスを備えており、各ノードのライブシーンで電話会議が構成されるのが好ましい。電話会議用ノードは、各ノードに固有であり得る特定のフォーマットで、会議の各ノードのディスプレイレイアウトを少なくとも部分的に個々に制御するコントローラを備えている。

本発明は、電話会議システムに関する。システムは、ネットワークを備えている。システムは、ネットワークを通じて互いに通信して会議を構成する複数のノードを備えており、各ノードのライブシーンで会議が構成されるのが好ましい。各ノードは、変化が起こると、その他のノードに変化のみを伝える。

本発明は、少なくとも３つのノード、例えばパーティの間で、電気通信会議を開催する方法に関する。その方法は、ノード間の会議を確立するステップを含んでおり、各ノードのライブシーンで会議が確立されるのが好ましい。会議に変化を起こすステップがある。変化のみをノードに送信するステップがあり、各ノードのライブシーンの変化を伝えるのが好ましい。

本発明は、ネットワーク用の電話会議用ノードに関しており、ネットワークは、その他のノードを伴っている。電話会議用ノードは、互いに通信して会議を構成する複数のノードと通信するネットワークインターフェイスを備えており、各ノードのライブシーンで会議が構成されるのが好ましい。電話会議用ノードは、変化が起こるとその変化のみをその他のノードに送信するコントローラを備えている。

多数の会議参加者を効率的に制御する機能は、非常に望ましいものである。これは、特に、低帯域幅のリンクについて正しい。さらに、これは、交換される必要があるメッセージが非常に小さいので、中間ノードの処理を低減する。

添付の図面を参照すると、幾つかの図面を通して、同じ参照符号が類似又は同様な部分を指している。特に図２０及び図２１を参照すると、電話会議システム(10)が示されている。システム(10)は、ネットワーク(40)を備えている。システム(10)は、互いに通信して、会議を構成する複数のノードを備えており、各ノードのライブシーンで電話会議が構成されるのが好ましい。各ノードは、ディスプレイレイアウトを有するビデオディスプレイ(54)を有しており、少なくとも１つのノードは、各ノードに固有であり得る特定のフォーマットで、会議の各ノードのディスプレイレイアウトを少なくとも部分的に個々に制御する。

各ノードは、特定のフォーマットでビデオを強制的に表示させられるのが好ましい。各ノードは、特定のフォーマットに固定されるのが好ましい。各ノードは、ディスプレイの特定の場所にて、会議のその他のノードから送られた幾つかのビデオストリームを強制的に表示させられるのが好ましい。各ノードは、複数のノードの１つによって制御されないスクリ−ンの任意の部分で表示されるものを制御するのが好ましい。複数のノードの１つは、各ノードのディスプレイレイアウトを完全に制御するのが好ましい。

本発明は、電話会議を提供する方法に関する。この方法は、ネットワーク(40)を通じて互いに通信する複数のノードで会議を構成するステップを含んでおり、各ノードのライブシーンで会議が構成されるのが好ましい。各ノードは、ディスプレイレイアウトを有するビデオディスプレイ(54)を有している。少なくとも１つのノードを用いて、各ノードに固有であり得る特定のフォーマットで、会議の各ノードのディスプレイレイアウトを少なくとも部分的に個々に制御するステップがある。

本発明は、ネットワーク(40)用の電話会議用ノードに関しており、ネットワーク(40)は、その他のノードを伴っている。電話会議用ノードは、複数のノードと通信して、ライブ会議を構成するネットワークインターフェイス(42)を備えており、各ノードのライブシーンでライブ会議が構成されるのが好ましい。電話会議用ノードは、各ノードに固有であり得る特定のフォーマットで、会議の各ノードのディスプレイレイアウトを少なくとも部分的に個々に制御するコントローラ(19)を備えている。

本発明の動作において、本発明は、会議参加者の１人から送られる会議参加者個別の画面のレイアウトを制御する技術を与える。例えば、Ｐ１からＰ１０までの会議コールの参加者がいて、それら参加者の１人がモデレータ(moderator)となり、Ｐ２に対して、各参加者の参加者の夫々のライブシーンを、Ｐ１及びＰ５を大きいビデオで、残りを小さいビデオで強制的に見させることができるだろう。各パーティのディスプレイは、このような方法で個別に制御されるだろう。

このレイアウト制御は、スクリーン全体ではなく個々のウインドウに実行されて、スクリーン上の管理外の(non-managed)ウインドウにも個別に制御が提供されてもよい。

遠隔のパーティが、各会議参加者のスクリーンレイアウトを制御できる。通常は、モデレータが、全てのパーティに対してモデレータと同じレイアウトを使用するように強制するだろう。しかしながら、細かい(fine grain)制御によって、会議参加者のサブセッションに渡ってサブモデレータの制御が認められるケースもあり得るだろう。

レイアウト制御機構は、会議参加者の所望のスクリーンレイアウトを含むレイアウトメッセージを生成する。レイアウトメッセージはまた、このメッセージを受信すべき参加者のリストを含む。そして、このレイアウトメッセージは、ＳＩＰ ＮＯＴＩＦＹイベントを介して、会議フォーカス又はホストに送られる。会議フォーカスは、このメッセージを、このリストに含まれる各パーティの出力メッセージキューに加える。会議フォーカスは、各パーティについてキューに入れられたイベントの全てを処理する際に、このメッセージを送る。メッセージが特定のパーティに送られて受信されると、そのパーティは、メッセージに含まれるリクエストに合うように、自己のスクリーンレイアウトを変更する。スクリーンレイアウトの変更が、新しいメディアストリームへのパーティの接続又は接続解除を要求する場合、パーティは、適当なイベントを発行して、リクエストされた変更を行うだろう。

本発明では、ユーザ又は１組のユーザ(１又は複数のモデレータ)に、会議の各ＶｉＰｒビデオフォンのディスプレイレイアウトを個々に制御することが可能な機能が与えられている。この制御は、部分的又は全体的であってよい。全体的な制御のディスプレイレイアウトフォーマットでは、会議の各参加者は、特定のフォーマットで画像を表示するように強制される。それは、ＭＣＵに幾らか似ているが、各参加者を夫々異なるフォーマットに固定できる点で異なっている。しかし、参加者が、あるフォーマットに一旦固定されると、それは、会議コールのディスプレイレイアウトを制御することはできない。例えば、Ａは、Ｃ、Ｄ及びＥから送られたライブシーンを３つの大きなビデオで表示し、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ及びＫを６つの小さなビデオで表示するように固定され得る。

部分的な制御のディスプレイフォーマットでは、各参加者は、特定の場所に幾つかのストリームを表示するように指示される。しかし、それは、スクリーンの残りに表示されるものを制御する。例えば、Ａは、左の大きなビデオでＢを表示するように指示され得る。しかしながら、それは、１つ、２つ、又は３つの大きなビデオを表示することを選択可能である。同様に、このスキームは、音声又は小さいビデオに使用できるだろう。

Ｌａｙｏｕｔ Ｃｏｎｔｒｏｌメッセージは、ＳＩＰ/ＮＯＴＩＦＹメッセージとして送られるが、それらは、その他のＳＩＰ又はＨＴＴＰ手段を介して送られてもよい。

「典型的な」ＶｉＰｒ会議コールでは、各端末に、会議コールにおけるその他の参加者の各々から送られる利用可能なオーディオ及びビデオスストリームの全てが与えられる。各端末の各ユーザは、通常、自己のローカルな端末に、スクリーンに自動的に各ビデオを順番に配置させるだろう。そして、ユーザは、どのパーティのビデオが、大きなビデオウインドウとして、又は小さなビデオウインドウとしてスクリーン上に示されるかを手動で選択できるだろう。

コールの参加者が、コールを管理すること(moderate)を希望する場合、彼らは、「Ｌａｙｏｕｔ Ｃｏｎｔｒｏｌ」の特徴を用いて、その他の端末の幾つか又は全てを制限する。これらの制限は、どの参加者が、大きなビデオウインドウとして表示されるかを含むことができる。それらはまた、小さなビデオウインドウのどれが、特定の参加者に固定されるかを制御できる。制限を、強制的に又は任意にすることができ、その結果、参加者は、モデレータの選択を無効にできるか否かを指定できる。また、レイアウト制御は、スクリーン上の２次的な画像の配置を制御するのに使用され得る。また、レイアウト制御は、スクリーン上の任意の２次的な画像の大きさを制御できる。さらに、レイアウト制御は、遠隔のパーティが、発言することを認められてアンミュートされる(unmuted)ことを希望する場合に、遠隔のパーティのオーディオミュートを制御し、遠隔のパーティが発言を要求する機能を制御できる。

ＳＩＰ/ＮＯＴＩＦＹメッセージは、レイアウト制御オプションを含んでおり、会議ホストに送られる。会議ホストは、このメッセージを、その他のパーティの全て配信する。

コールのモデレータは、標準的なＳＩＰ/ＳＤＰ「ａ＝Ｒｘ−Ｌｉｓｔ: Ａ Ｂ Ｃ」機構を使用して、コールのモデレータが表示しているパーティを特定する。ここで、「Ａ Ｂ Ｃ」は、見られている遠隔パーティのパーティ識別子である。コール管理モードで動作する場合、「Ａｍ Ｂｍ Ｃｍ」のように「ｍ」がパーティに添付されない限り、これらは全て「選択的な」レイアウト位置として取り扱われる。「ｍ」は、強制フラグであって、遠隔のユーザインターフェイスに、どのパーティがスクリーン上にて位置を固定されなくてはならないのかを教える。なお、選択的なパーティは、ユーザインターフェイスが希望するならば、遠隔の各端末で独立に変更できる。ユーザインターフェイスは、会議に「全強制」モードを強制することができ、該モードでは、管理されたコールで動作する場合に、全てのパーティが強制されるものとして取り扱われる。

「モデレータ−レイアウト」と称されるイベントが使用されて、スクリーンのその他の特性を制御するレイアウト制御メッセージが特定される。「ｃｈａｎ＿ｓｉｚｅ」は、２次的なビデオの大きさを、「ｃｏｌ＿ｓｉｚｅ」は、２次的な画像の大きさを制御するのに使用される選択的な文字列のキーワードである。「ｆｌｏｏｒ−ｒｅｑｕｅｓｔ」及び「ｆｌｏｏｒ−ｗｉｔｈｄｒａｗｎ」と名付けられたイベントが使用されて、パーティが発言権を欲していること、又は、リクエストを取り下げることを希望していることを、モデレータに教える。「ｆｌｏｏｒ−ｇｒａｎｔｅｄ」と名付けられたイベントが、モデレータによってパーティに送られて、それらがアンミュートされて、現在話すことができる旨が伝えられる。端末のユーザインターフェイスは、これらのイベントの各々を順守して、コールのモデレータによって指示されたようにスクリーンを制御する。

次の出願は全て、引用を以て本件明細書の一部となる。米国特許出願第１０/１１４,４０２号「ビデオフォン及びビデオコール方法(VIDEOPHONE AND METHOD FOR A VIDEO CALL)」。米国特許出願第１０/８７１,８５２号「オーディオミキサ及びその方法(AUDIO MIXER AND METHOD)」。米国特許出願第１１/０７８,１９３号「ストリームを伴う会議の方法及び装置(METHOD AND APPARATUS FOR CONFERENCING WITH STREAM)」。

ノードには、メンバー、パーティ、端末、又は会議の参加者が含まれる。会議は、通常、少なくとも３つのノードを含んでおり、１０や２０、５０、１００、１５０、又はより多数のノードでさえあり得る。

添付の図面を参照すると、幾つかの図面を通して、同じ参照符号が類似又は同様な部分を指している。特に図２２を参照すると、電話会議システム(10)が示されている。システム(10)は、ネットワーク(40)を備えている。システム(10)は、ネットワーク(40)を介して互いに通信して、会議を構成する複数のノードを備えており、各ノードのライブシーンで会議が構成されるのが好ましい。各ノードは、変化が起こった場合に、その変化のみをその他のノードに送信する。

各ノードは、変化によって影響を受けるパーティのみに、その変化のみを伝える。

本発明は、少なくとも３つのノード、例えばパーティ間で電気通信会議を開催する方法に関する。その方法は、ノード間のライブ会議を確立するステップを含んでおり、各ノードのライブシーンで会議が確立されるのが好ましい。会議に変化を起こすステップがある。その変化のみをノードに送信するステップがある。

送信するステップは、変化によって影響を受けるノードのみに、その変化のみを伝えるステップを含むのが好ましい。変化を起こすステップは、ノードのステータスの１つに変化を起こすステップを含むのが好ましい。変化を起こすステップは、会議の状態の１つに変化を起こすステップを含むのが好ましい。ノードの１つから、全部ではない幾つかのノードのみに、指定のメッセージ(directed message)を送るステップがあるのが好ましい。確立するステップは、ＳＩＰ ＮＯＴＩＦＹ/ＯＫ技術に基づいて会議を確立するステップを含むのが好ましい。

会議の変化は、ノードのステータスの１つの変化を含むのが好ましい。会議の変化は、会議の状態の変化を含むのが好ましい。複数のノードの１つは、全部ではない幾つかのノードのみに、指定のメッセージを送る。複数のノードは、ＳＩＰ ＮＯＴＩＦＹ/ＯＫ技術に基づいて会議を確立するのが好ましい。各ノードは、コントローラ(19)と、コントローラ(19)及びネットワーク(40)と通信するネットワークインターフェイス(42)とを有するのが好ましい。コントローラ(19)は、そのノードに任意の変化をもたらし、その変化をネットワークインターフェイス(42)、さらにはネットワーク(40)を通じて、会議のその他のノードに送る。

本発明は、ネットワーク(40)用の電話会議用ノードに関しており、ネットワーク(40)は、その他のノードを伴っている。電話会議用ノードは、その他のノードと通信して、ライブ会議を構成するためのネットワークインターフェイス(42)を備えており、各ノードのライブシーンでライブ会議が構成されるのが好ましい。電話会議用ノードは、変化が起こった場合に、その変化のみをその他のノードに送信するコントローラ(19)を備えている。

好ましい実施例の動作では、大規模会議用の制御機構は、会議制御メッセージを用いて、コール上の全てのパーティを管理する。参加者は、会議制御メッセージを生成し、この会議制御メッセージは、送信されるストリームの特徴と、会議のその他の参加者から受信するストリームの所望のリストとを両方含む。この会議制御メッセージは、ＳＩＰ ＮＯＴＩＦＹイベントを介して、会議フォーカス又はホストに送られる。その後、会議フォーカスは、このメッセージを、このメッセージによって影響を受ける各パーティの出力キューに加える。会議フォーカスは、各パーティについてキューに入れられたイベントの全てを処理する際に、これらメッセージを送信する。メッセージが送られて、特定のパーティで受信されると、そのパーティは、出力するストリームのリストにリクエスト中のパーティを加える。また、会議制御メッセージは、ビデオストリームをオン若しくはオフにする、又は音声のみの制御のために「保留」にする要望を示すために送信され得る。

大規模会議のシグナリングの発明
従来、ＶｉＰｒ会議は、オファー/アンサーモデルに基づいていた。このモデルでは、会議の全体的な状態が、会議参加者の間で交換される各メッセージで運ばれていた。例えば、Ｐ１乃至Ｐ５からなる５人の参加者間の会議を考える。この場合、これら５人のパーティは、ホストを呼ばれる中央ポイントを介して会議に接続されるだろう。ホストは、会議の全体的な状態を含むテーブルを作成するだろう。パーティＰ１乃至Ｐ３が、映像/音声を送信又は受信し、パーティＰ２及びＰ３が、音声のみを送信又は受信する場合、このテーブルのみが、全体的な状態を示すであろう。任意の変化が会議に起こる時はいつでも、ホストは、テーブルを再計算し、その情報を各人に送るだろう。例えば、Ｐ３がビデオの送信を停止する場合、以下のテーブル１がテーブル２に変更されて、その完全なテーブルが各人に送られる。

このスキームは、良く機能した。なぜならば、それは、現存するＳＩＰ基準に合致しており、基本的なＳＩＰプロトコルの拡張を可能とし、ＶｉＰｒスタイルの会議開催を可能にした。

会議の参加者の数が、１５人未満又はその程度の場合、このスキームは、良く機能した。それを超えると、全てのパーティを含むテーブルは、効率的に回されるには非常に大きくなる。さらに、会議の状態の如何なる変化についても、全てのパーティが影響を受ける訳ではない。処理する必要がないというメッセージで会議を溢れさせる必要はない。このモデルのもう１つの問題は、２つのＳＩＰピア間で、アプリケーションレベルで、メディアに関係することなくメッセージを送る機能ができないことである。

上述の問題を是正するために、我々は、この新しいスキームを発明した。この新しいスキームでは、以下に述べる重大な変化がなされている。

＄ 会議の状態は、２つの点で変化し得る。参加者の何れか１人が、その状態の変化(パーティローカル)をリクエストしていたか、パーティの１人が、会議全体の変化(グローバルな変化)をリクエストしていた。このような如何なる変化がなされるといつでも、変化するパーティ又はグローバル会議状態を特定する情報のみが、会議の参加者の間でやり取りされる。テーブル２の例を使用すると、完全なテーブルではなく、Ｐ３に対応する情報のみが送出される。[つまり、Ｐ３に関する行のみが、その他の参加者に再送される。] Ｇｌｏｂａｌ Ｅｖｅｎｔの例は、以下の通りである。
−−＞ Conference Name Change (会議の名前の変化)
−−＞ Conference Moderator Status Change (会議のモデレータの状態の変化)
−−＞ Floor Request Status Change (発言権リクエストの状態の変化)
−−＞ Conference Type Change (会議のタイプの変化)
−−＞ Conference Status Messages (パーティが会議の参加を拒絶されている等)
Ｐａｒｔｙ Ｅｖｅｎｔの例は以下の通りである。
−−＞ Party Toggling camera (カメラを切り替えるパーティ)
−−＞ Party Toggling Hold status (ホールド状態を切り替えるパーティ)
−−＞ Party Delete (パーティの削除)
−−＞ Party Add (パーティの追加)
−−＞ Party Status Change (モデレータになる/モデレータの放棄)
−−＞ Party requesting a change in Receive Media Stream (受信メディアストリー ムの変化を要求するパーティ)

＄ 変化によって影響を受けるパーティのみが、変更された情報を受信する。

＄ あるパーティＰ１から任意の数のパーティに、指定されたメッセージを送ることができる。例えば、Ｐ１は、メッセージをＰ２、Ｐ３及びＰ４に中継することを、ホストにリクエストできる。しかし、Ｐ５にはできない。これの最後の機能は重要であり、会議の開催において、グループベースでシグナリングを可能とする。

この新しい設計は、ＳＩＰ ＮＯＴＩＦＹ/ＯＫ手法に基づいており、新しいイベントパッケージを規定する。ＲＦＣ３２６１及びＲＦＣ３２６４基準は、ＳＩＰの基本仕様を規定している。ＲＦＣ３２６５は、イベントを使用するためのフレームワークを規定する。それらは、引用を以て本明細書の一部となる。

例えば、ホストは、常に、ＶｉＰｒ会議に必要とされる。実際に、会議のパーティは、お互いに直接シグナリングしているとは限らない。例えば、Ａ、Ｂ、Ｃの間の会議コールがあるとする。３つのＳＩＰ Ｃａｌｌ Ｌｅｇがある。
−− Ｈｏｓｔ ｔｏ Ａ
−− Ｈｏｓｔ ｔｏ Ｂ
−− Ｈｏｓｔ ｔｏ Ｃ
メディアは、Ａ、Ｂ、Ｃの間で直接的に流れる。

本発明において、Ｂは、現在、Ａからビデオを受信しており、Ｃからもビデオを受信することを希望している。この変化は、以下の２つの方法の何れかで送信できるだろう。

− Ｂは、ＮＯＴＩＦＹをホストに送る。ＮＯＴＩＦＹには、フィールド[called dest-party-list:Ｃ]があって、このメッセージがＣのみに送られて良いことが示されている。
− 代わりに、Ｂは、このような如何なるフィールドにも明示的に置かれていないが、ホストは、このメッセージがＣのみに影響することを検知でき、そのメッセージをＣにのみに送信してもよい。

ビデオフォン
図８、図９、図１０及び図１１を参照すると、Ｓビデオを伴うソニー製の一般的なアナログビデオカメラ(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)に並べて形成された画像はクリップされており(clipped)、縮小されていない。シーンにおける物の大きさは変化しておらず、単に、各データストリームのシーンにおける夫々の側の外領域が削除される。必要ならば、シーンの小さい画像に関するストリームの画像は、ディスプレイ(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)で生成されたオーディオも、基本的にそれが他のビデオフォン(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)のユーザは、声の大きな３人の話し手を大きな画像として表示し、また、会議のパーティのタッチスクリーン(74)を介して、小さな画像として表示する２０のパーティを選択する。これらパーティは、タッチスクリーンのページにリストアップされている。他のプロトコルを選択できて、小さな画像として表示される２０の画像を、会議が始まって各パーティが紹介をした時刻からの、会議における最新の話し手になるようにできる。表示されるビデオストリームの数を制御することで、組織が会議に適合し、ビデオフォン(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)に知らされて、誰がいることが示される。

また、ビデオフォン(15)はビデオメールを提供する。あるビデオコール(15)から別のビデオフォン(15)へのビデオコールが試みられて、所定時間後に、例えば４回ベルが鳴った後に、受信ビデオフォン(15)がビデオコールに応答しない場合、受信ビデオフォン(15)に関連したビデオサーバ(66)がビデオコールに応答する。ビデオサーバ(66)は、送信ビデオフォン(15)から送られるビデオコールに応答し、送信ビデオフォン(15)に、記録されたオーディオメッセージを、又は、記録されたビデオ画像を伴ったオーディオメッセージを送る。これらメッセージは、応答しない受信ビデオフォン(15)から送られて、前もってビデオサーバ(66)に記録されている。ビデオサーバ(66)は、メッセージを再生して、電話をかける人に、オーディオ、又はオーディオ及びビデオキューを与えて、ビープ音のような所定の表示の後にメッセージを残す。所定の表示が起こると、電話をかける人は、その人のビデオ画像に加えて発言を含んだメッセージを残す。ビデオ及びオーディオメッセージは、ビデオサーバ(66)にてメモリに格納される。メッセージは、必要なだけ長くでき、又は、定められた所定の時間間隔に限定できる。所定の時間間隔が経過した後、又は、電話をかける人がコールを済ませて終了した後、ビデオサーバ(66)は、ビデオメッセージを保存して、最初のコールに応答しなかった受信ビデオフォン(15)に信号を送る。受信ビデオフォン(15)の視聴者は、ビデオメッセージを待っている。このメッセージはテキスト若しくは、受信ビデオフォン(15)のディスプレイ(54)に表示されるビデオ画像とすることができ、または、単に、メッセージライトとすることもできる。メッセージライトが点灯すると、受信ビデオフォン(15)の視聴者に、視聴者へのビデオメールがある旨が知らされる。

視聴者がビデオメールを見ることを希望する場合、視聴者は、単にタッチスクリーン(74)の領域を選択するだけで、ビデオメールを起動できる。ユーザには、ビデオメールの読み出しを含めた、メールに関する一連の操作オプションが示される。メールの読み出しでは、信号がビデオサーバ(66)に送られて、ビデオフォン(15)のディスプレイ(54)にて視聴者用にビデオメールが再生される。画像のストリームがビデオサーバ(66)から送られて、ビデオベースのストリーム用の上述の経路を通じて受信ビデオフォン(15)に向かい、それを介して表示される。ビデオフォン(15)の視聴者が、ビデオサーバ(66)にメッセージを記録して、視聴者がビデオコールに答えない場合にビデオコールに応答するためには、視聴者はタッチスクリーン(74)の領域にタッチして、ビデオサーバ(66)を動作させる。視聴者は、所定の時間に、オーディオ又はオーディオ及びビデオのメッセージを記録するように促される。視聴者がこれを行うと、メッセージが作成される。

ビデオフォン(15)は、ユーザがボリューム調整することなく、所定のレベルでスピーカを動作させる。ビデオフォン(15)のスピーカ(64)は、マイクロホンでキャリブレーションできるので、マイクロフォンが非常に大きいノイズを拾う場合には、メインコントローラ(50)及びＤＳＰ(62)は、スピーカ(64)のオーディオ出力のレベルを下げて、ノイズレベルを低減する。所定且つ所望のレベルを設定することで、ビデオフォン(15)は、視聴者が何かを行うことなく、自動的にボリュームの大きさを制御する。

ビデオフォン(15)は、特定の人物に話しかける問合せを認識すると、受信ビデオフォン(15)でのトーン又は信号のような、認識に用いられる所定のスピーチパターンを用いて、受信ビデオフォン(15)にコールが要求されている旨を、受信ビデオフォン(15)の視聴者に知らせるようにプログラムできる。例えば、言葉「ヘイ、クレイグ(Hey Craig)」がビデオフォン(15)で用いられて、コールがクレイグに向けて開始されるべきものであることが送信ビデオフォン(15)で認識される。視聴者が「ヘイ、クレイグ」を言うことで、送信ビデオフォンが自動的にクレイグへのコールを開始し、言葉「ヘイ、クレイグ」がクレイグの受信ビデオフォン(15)に送られる。クレイグの受信ビデオフォン(15)が鳴って、コールがクレイグに要求されていることを示す代わりに、言葉「ヘイ、クレイグ」が、直ちにクレイグのビデオフォン(15)にアナウンスされる。これは、クレイグの注意を喚起するために通常起こされるベルに置き換わる。この動作を行う機能は、メインコントローラ(50)及びＤＳＰ(62)で実現されるであろう。発言「ヘイ、クレイグ」は、視聴者によってアナウンスされて、上述のようにサーバ(66)に送信される。サーバ(66)は、発言を解析して、命令として言葉を認識し、命令に記されたパーティにコールを開始する。その後、サーバ(66)は、クレイグのビデオフォン(15)のアドレス情報を用いて、クレイグのビデオフォン(15)とコールを開始し、クレイグのビデオフォン(15)で「ヘイ、クレイグ」になる信号又は音色を発生させる。

当該技術分野で周知のように、エンコーダ(36)は、各フレームの最初及び最後を特定できる。エンコーダ(36)がデータを受信すると、それはフレームのデータをエンコードして、フレームが完全になるまで格納する。エンコーダ(36)が使用するアルゴリズムによって、格納されたフレームは、次のフレームを形成するための基礎として用いられる。格納されたフレームは、次のフレームをエンコードするためのリファレンスフレームとして働く。これは、基本的に、最初からのフレーム全部ではなく、あるフレームから次のフレームへのフレームの変化がエンコードの中心だからである。その後、エンコードされたフレームは、上述のように、直ちに送り出されて、パケット化される。フレームは、パケット化を除いてバッファリングされることはないので、遅延は最小限に抑えられる。なお、エンコーダ(36)がフレームのデータをエンコードする際に、データの送信速度をさらに速くするために、フレーム全体がエンコードされることを待たないで、エンコードされたデータをパケット化のために順序付けしてもよい。また、先に説明した理由から、エンコードされたデータは、フレームを形成するために格納されるので、リファレンスフレームがフレームで利用可能となる。しかしながら、別個に、データは、エンコードされる際にパケット化のために送られて、パケット化の準備中にフレームを形成する。しかし、パケットが送信可能となって、フレームの一部分のみがパケットを部分的に構成する場合であっても、フレームの残りの部分が別個のパケットとして送信されて、フレーム情報を伴う両方のパケットが受信ビデオフォン(15)で受信されるまで、フレームは形成されない。

図１を参照すると、ビデオフォン(15)がネットワーク(40)に接続されている。ビデオフォン(15)は、銅又はマルチモードファイバーの何れかの上にて、１０/１００イーサネット接続と、オプションとしてＡＴＭ１５５Ｍｂｐｓ接続とをサポートしている。各ビデオフォン(15)端末は、通常、ユーザのＰＣ(68)に取り付けられている。ビデオフォン(15)の役割は、(会議)コールのオーディオ及びビデオ特性を与えることである。ＰＣ(68)は、その他の機能に用いられる。ビデオフォン(15)を用いてコールを確立することで、ＰＣ(68)間のマイクロソフトネットミーティングセッションが確立される。これによって、ユーザは、ウインドウズベースのプログラム、例えば、パワーポイントプレゼンテーションやスプレッドシートと協動すること、電子ホワイトボードと画像を交換すること、ファイルを転送すること、テキストベースのチャットプログラムを使用すること等が行える。ビデオフォン(15)端末がどのように接続されているかに拘わりなく、ＰＣ(68)は、イーサネットに接続できる。ＰＣ(68)は、当然に、ＡＴＭ ＬＡＮにも接続できる。ＰＣ(68)と、関連する送信ビデオフォン(15)とは、ネットワーク(40)を通じて相互に通信する。ＰＣ(68)と、関連する送信ビデオフォン(15)とが相互に通信することで、ＰＣ(68)は、送信ビデオフォン(15)が話している相手を知る。その後、ＰＣ(68)は、送信ビデオフォン(15)が話している相手である受信ビデオフォン(15)のＰＣ(68)と通信可能となる。また、ＰＣ(68)は、ビデオフォン(15)にコールすることも可能である。

システム(10)の機能の大半は、サーバーベースであって、ビデオフォン(15)のプロキシサーバで動作するソフトウエアで実現されている。プロキシサーバは、ＳＩＰプロキシサーバであるのが好ましい。基本機能をもたらすために第１サーバが必要とされ、第２サーバは、弾力的な動作に、言い換えると、第１サーバが失敗したイベントを保全するサービスに必要とされる。このような場合、サーバとビデオフォン(15)のソフトウエアは、バックアップサーバ(66)に自動的にスワップする。この構成を用いて、ネットワーク(40)上の他のビデオフォン(15)に、さらに、好ましくはＳＩＰフォンであるネットワークに登録された電話に、ビデオフォン(15)はコールをすることが可能となり、また、これらからのコールを受け取ることが可能となる。

メディアサーバは、一連のメディアストリーム上のユーザに一連のサービスを提供する。メディアサーバ(66)は、主サーバ(feature server)で(好ましくは主サーバで)制御される。それは、ユーザインボキャブル(user-invocable)な種々の機能の一部として、メディアストリームの送信側と受信側を与えるために用いられる。メディアサーバで与えられるサービスは、会議ブリッジ、記録及び再生、トランスコーディング、音色及びアナウンスメントである。

メディアサーバ(66)は、ＬＡＮ又はＷＡＮ上にあるボックスである。通常、それは、その他の接続を有していない。それは、ＳＩＰデバイスであるのが好ましい。主サーバは、ビデオフォン(15)端末から発する信号経路内にある。しかしながら、メディアの経路は、メディアサーバ(66)から装置に直通するだろう。

動作中、ユーザは、ビデオメール等の機能を要求してよい。主サーバ(66)は、ユーザインターフェイス及びシグナリング機能を与え、メディアサーバ(66)は、(使用されるならば)マルチメディアプロンプト(multimedia prompt)機能と、メッセージの記録再生機能を与えるだろう。

ビデオフォン(15)端末が、(ＳＩＰビデオフォンのような)プロトコル外又は基準外の(ビデオ)フォンにコールをし、又はそれらのコールを受け入れることを可能にするために、ＳＩＰゲートウェイのようなゲートウェイ(70)が加えられる。４本のアナログラインを有するゲートウェイ(70)が、ＰＳＴＮに直接接続されるか、ローカルＰＢＸのアナログラインに接続される。出力ラインを供給する通常の規則が適用される。一般的な１本の中継ラインが６人のユーザの全てに供給される。つまり、どのユーザも自分のフォンを用いて、勤務時間外の１０分間、外部接続にダイヤルすると仮定する。ビデオフォン(15)端末が現在のＰＢＸの拡張として働く場合、着信コールに関する限り、１本のアナログラインが各ビデオフォン(15)に必要となる。

ＣＮＮのようなＴＶソースが、ビデオフォン(15)のユーザに利用され得る。ビデオフォン(15)のビデオサーバ(66)によって、このサービスが可能となる。サーバ(66)は、１つのビデオチャンネルとの接続をサポートし、そのチャンネルは、ネットワーク(40)上のどのビデオフォン(15)のユーザでも利用される。ビデオチャンネルは、通常の２つの会議セッションと同等である。チューナは、利用可能なチャンネルをセットする。新たなビデオフォン(15)のビデオサーバ(66)が、ユーザが同時利用を願う異なるチャンネルの各々について設定に加えられる。

また、ビデオフォン(15)のサーバ(66)(好ましくはＳＩＰ)は、ユーザデータのデータベースを持っており、ユーザコンタクト情報のローカルキャッシュを含んでいる。このデータべースは、ユーザに関するメインコンタクトデータべースと同期化できる。同期化は、例えば、アウトルック/エクスチェンジのユーザによって、ロータスノーツのユーザのために行われる。別個のプログラムが、ＮＴベースの如何なるサーバ(66)プラットホームでも動作して、同期化を行う。扱うサイトの数に拘わらず、１つのサーバのみが必要とされる。

図２に示すように、通常、ビデオフォン(15)端末は、幾つかのサイトに渡って分散しており、ワイドエリアネットワーク(40)と協力する。あるサーバ(66)は、１つのキャンパスにて、最大で１００個以上のビデオフォン(15)を十分に扱える。サイト上のビデオフォン(15)の数が増加すると、ある段階でさらにサーバをインストールする必要が生じる。

ビデオフォン(15)が幾つかのサイトを渡って分散すると、中央サーバに基づいてそれらを動作可能となるが、ＷＡＮで使用される帯域幅と、ＷＡＮへの依存とを考慮すると、これは勧められる構成ではない。好ましくは、各サイトは少なくとも１つのサーバ(66)を有しており、該サーバ(66)は、ＳＩＰが用いられる場合、ＳＩＰサーバ(66)であるのが好ましい。さらに忠告すると、最も簡単で容易な構成は各サイトが、好ましくはＳＩＰである二重のサーバを有することである。しかしながら、遠隔のサイトサーバの代わりとして、中央サーバを用いることも可能である。

ビデオフォン(15)は、ネットワーク(40)の何処においても、１つの中央ゲートウェイ(70)からＰＳＴＮ又はＰＢＸベースの送信コールが可能である。しかしながら、ビデオフォン(15)が、受信コールを受け入れるためにローカルＰＢＸの延長でもなければならない場合には、ＰＳＴＮゲートウェイ(70)は、各場所に与えられることが必要である。そのサイトの全てのビデオフォン(15)について、ゲートウェイ(70)のポートが必要となる。

中央ＣＮＮサーバ(66)は、ネットワーク(40)上のどのビデオフォン(15)にも、ＴＶチャンネルを配信する。それにも拘わらず、ＷＡＮに渡ってその帯域幅を得るよりは、サイト特有のサーバを含むことが好ましいであろう。

ビデオフォン(15)は、(ファイバーと銅のオプションを用いて)１０/１００イーサネットネットワーク(40)又は１５５Ｍｂｉｔｓ/sec のＡＴＭネットワーク(40)の何れか一方に接続できる。ＡＴＭに接続されたビデオフォン(15)は、ＩＰコントロールプレーンを用いて、コールのエンドポイントのＡＴＭアドレスを定めて、そして、ＡＴＭ信号を発して、エンドポイント間で搬送チャンネル(bearer channel)を確立する。搬送チャンネルは、スイッチドバーチャル回路(ＳＶＣ)で確立され、完全なＱｏＳの要求が特定される。

各ビデオストリームは、セッティングと帯域幅のネゴシエーションによって定められるように、２Ｍｂｐｓと６Ｍｂｐｓの間で双方向に送信可能である。ディスプレイ手段が２以上のビデオストリームを表示できるので、各ビデオフォンを全接続するのに要求される帯域幅は、コールのパーティ数と共に増加する。送信端のクリップによって、要求される最大の帯域幅は、単一のビデオストリームで使用される帯域幅の約２.５倍となる。サイトに幾つかのビデオフォン(15)がある場合、ユーザとトランク(trunk)間の通常のテレフォンレシオ(telephone ratio)が、ビデオフォン(15)のセッションに加わる。言い換えると、ビデオフォン(15)のユーザは、各コールにて平均して２人の他人と、つまり２つのストリームで会話すると予想され、ユーザは、その時に平均して１０分間ビデオフォン(15)を用いる。平均エンコードレートが３Ｍｂｐｓである場合、このことより、６ＭｂｐｓのＷＡＮの帯域幅が必要となり、この帯域幅では、最大６人までのユーザをサポートすることが期待される。

図３に示すように、ビデオフォン(15)は、ビデオフォン(15)端末の密度が低い場合に、「ｐ」で動作可能な('p' enabled)イーサネットネットワーク(40)で動作する。ビデオフォン(15)のシステム(10)は、２個のビデオフォン(15)を互いにリンクするネットワーク(40)のＡＴＭ部分に渡ってＳＶＣを確立すると共に、「ｐ」で動作可能なイーサネットを用いることで、十分なクオリティオブサービスが接続のイーサネット部分に渡って与えられることを保証する。

ビデオフォン(15)のシステム(10)の基本的な構成要素が、図４に示されている。それらは共にマルチメディア協動ツールを生成して、それらツールは、地理的に分散したチームが交流する能力を増進させる。このようなチームは、ほとんど全ての大企業で存在しており、次第に増加している。さらに、彼らが効果的及び効率的に働くことを助けるツールは、１０年前からほとんど変わっておらず、多くの面で不満足なものである。ビデオフォン(15)は、包括的な方法を用いて現存するシステムの多くの問題に対処し、遠隔地間の共同作業に断続的な(discontinuous)改善をもたらす。それは、新たに利用可能な技術を用いて可能となり、クオリティオブサービスと正しいミキシング機能で差別化され、優れたユーザインターフェイスの開発によって使用可能となり、標準ベースのアーキテクチャを用いることで、拡張可能なように設計される。

オーディオ及びビデオストリームは、上述のように、例えば、周知のＳＩＰ技術を用いて、ネットワーク上の始端ビデオフォン(15)から終端ビデオフォン(15)に送信される。ＳＩＰメッセージは、異種のネットワークに渡ってＩＰルーティング技術を用いてルーティングされてよい。異種のネットワークのメディアストリームには、より直接的な経路が要求される。好ましくは、図１５に示すように、会議の始端ビデオフォン(15)がイーサネットに接続されて、会議の終端ビデオフォン(15)がＡＴＭネットワークに接続されている場合、始端及び終端ビデオフォン間のネットワークを渡るパケットについて、以下に述べるアドレッシングが起こる。始端ビデオフォン(15)は、パケットをイーサネットに送って、始端ビデオフォンのＩＰアドレスを用いて通信が行われる。パケットは、イーサネットをＡＴＭネットワークにリンクする始端ゲートウェイ(80)に到達する。始端ゲートウェイ(80)では、始端ビデオフォン(15)のＩＰアドレスが、パケットから保存される。始端ゲートウェイ(80)は、始端ゲートウェイ(80)のＡＴＭアドレスをパケットに加えて、終端ビデオフォン(15)にパケットを送る。終端ビデオフォン(15)がパケットを受信すると、それは、始端ゲートウェイ(80)のＡＴＭアドレスをパケットより格納して、始端ゲートウェイ(80)にリターンパケットを送り返す。リターンパケットは、終端ビデオフォン(15)がパケットを受信したことを示しており、終端ビデオフォン(15)のＡＴＭアドレスを伴っている。始端ゲートウェイ(80)は、リターンパケットを受信すると、終端ビデオフォン(15)のＡＴＭアドレスを保存し、始端ゲートウェイ(80)のＩＰアドレスをリターンパケットに加える。リターンパケットは、その後、始端ゲートウェイ(80)から始端ビデオフォン(15)に送り返される。

このように、始端ビデオフォン(15)と終端ビデオフォン(15)間の経路全体に渡るクリティカルなノード、始端ビデオフォン(15)及び終端ビデオフォン(15)の具体的アドレスが、経路のクリティカルなノードの各々で知られる。最低でも、経路の各ノードは、経路の次のノードのアドレスを知る。必要ならば、個々のパケットが経路に沿って動くにつれて、追加されたアドレスがそれらに保存されて、経路の各ノードは、パケットが向かう次のノードよりも、クリティカルなノードのアドレスについてより多くを知る。これは、パケットがノードからノードへ移動すると、具体的な例としては、始端ビデオフォン(15)から始端ゲートウェイ(80)に、それから終端ビデオフォン(15)に、そして、終端ビデオフォン(15)から始端ゲートウェイ(80)に、それから始端ビデオフォン(15)に戻るように、パケットが移動すると、各ノードは、受け取った個々のパケットを送った前のノードのクリティカルなアドレスを保存し、次のノードが含まれるネットワークのタイプに関した自己のアドレスを持ち込むことによる。その結果として、各ノードが次のノードにパケットを送るのに必要なクリティカルなアドレスは、経路を通じて配布される。

イーサネット上の始端ビデオフォン(15)からＡＴＭネットワーク上の終端ビデオフォン(15)にパケットを転送するこの例は、逆の場合、つまり、始端端末つまり始端ビデオフォン(15)がＡＴＭネットワークと通信し、終端ビデオフォン(15)がイーサネットと通信する場合にも適用できる。

同様にして、経路は、イーサネットと通信する始端ビデオフォン(15)と、イーサネットと通信する終端ビデオフォン(15)とを含み、図１６に示すように、パケットが行き来するＡＴＭネットワークが中間にあるように構成され得る。このような場合、各端に配置された２つのゲートウェイがあって、それらは、イーサネットとＡＴＭネットワークのインターフェイスとなる。先述のように、処理では、追加ノードが単純に経路に加えられる。始端ゲートウェイ(80)は、自己のＡＴＭアドレスをパケットに取り込んで、それを終端ゲートウェイ(82)に送る。終端ゲートウェイ(82)は、始端ゲートウェイのＡＴＭアドレスを保存し、終端ゲートウェイのＩＰアドレスをパケットに加えて、イーサネット上で終端ビデオフォン(15)に送る。リターンパケットについて、同じ事が逆に起こる。各ゲートウェイは、先のゲートウェイ又は終端ビデオフォン(15)から得た個々のアドレス情報を保存して、自己のアドレスをリターンパケットに加える。リターンパケットは、最終的に始端ビデオフォン(15)に送られる。始端ゲートウェイ(80)及び始端ビデオフォン(15)は、終端ゲートウェイ(82)又は始端ゲートウェイ(80)のＡＴＭアドレスを夫々保存し、経路に渡る各リンクにおける個々のアドレスが、より効率的に格納されて、接続のパケットは、迅速に順次転送される。

例えば、ＳＩＰルーティング情報(または、標準的なルーティング情報であれば何でも用いられる)をパケットに収納するという、当業者に周知の技術と同様な技術を用いて、ビデオフォン(15)のメインコントローラ(50)及びネットワークインターフェイス(42)は、ビデオフォン(15)のアドレスを、それがネットワーク(40)に送る各パケットに加える。また、ネットワークインターフェイス(42)は、ネットワーク上のノードから送られるパケットから受け取ったアドレス情報を、ローカルメモリに格納する。同じように、ネットワーク(40)のゲートウェイについて同様な構成が適用される。周知のように、ゲートウェイは、パケットをその最終的な送り先に移動させる制御手段及びデータ処理手段を有している。ゲートウェイの制御機構のネットワークインターフェイス(42)及びメインコントローラ(50)は、ＳＩＰルーティング情報に関した周知の技術で動作し、パケットから受け取ったアドレス情報を格納し、パケットを送ろうとしているネットワーク(40)につ関する自己のアドレス情報をパケットに収納する。例えば、ゲートウェイ又はビデオフォン(15)のアドレス情報は、パケットのヘッダー部のフィールドに配置される。実施例では、終端及び始端ソースとしてビデオフォン(15)が使用されているが、パケットを生成及び受信するデバイスであればどのようなタイプも、このスキーム全体にて使用されることに留意すべきである。

バーチャルプレゼンスビデオ−フォン(ビデオフォン)(15)は、デスクトップのネットワーク(40)装置であり、個人用の通信端末である。それは、ユーザの机のフォンに置き換わって、現在のＰＢＸ端末の全ての機能を提供するものであり、ビデオフォン(15)の大きなタッチスクリーン(74)によって、ユーザインターフェイスが簡単になり、使用が容易になっている

ビデオフォン(15)は、全ての個人間通信にビデオの特徴を加えて、見聞をバーチャルなものに変化させる。従来では、ビデオ会議システムのビデオの質は、トランスペアレントであるのに技術的に不十分であった。ビデオフォン(15)は、十分に高い質のビデオをもたらして、見聞を正確に生成する最初の個人用ビデオフォンである。効果面では、リアルタイムビデオ通信が放送されるＴＶの質に近い画像の質を有しているだけでなく、待ち時間が非常に短く維持されなくてはならない。会話が自然に流れるためには、リップシンク(Lip Sync)もまた重要である。これらのような問題の全ては、ビデオフォン(15)のビデオサブシステムのデザインにて対処されている。ビデオフォン(15)は、この用途に特別に構成された最新のエンコーダ(36)及びデコーダ(34)技術を用いている。言い換えると、ビデオフォン(15)は、「そこにある」ように可能な限り近づいている。

また、ビデオフォン(15)は、ハイファイの、ＣＤに近い音質のオーディオチャンネルを使用することで、従来のスピーカフォンの性能を改善し、透明で明瞭な音声を提供する。ステレオのオーディオチャンネルは、各参加者のオーディオの空間的な差異を与える。進歩したステレオエコーキャンセルは、ユニットスピーカ(64)の音をキャンセルするだけでなく、騒々しい部屋でさえも、通常の会議のレベルにて、話し手に会議を続けることを可能にする。

ビデオフォン(15)は、最大で４つの離れたパーティによる(即ち５方向の)ビデオ会議コールを、及び/又は、最大で１０つのパーティによるオーディオ会議コールを確立して、直接的にサポートする。各ユーザは、彼/彼女のワークグループにおける他のメンバー全てについて、利用状況を見ることができる。ビデオフォン(15)は、マルチストリームのマルチメディアセッションを確立し、修正し、クリアする手段として、セッション開始プロトコル(ＳＩＰ)を用いるのが好ましい。ビデオフォン(15)は、ゲートウェイ(70)を通じて、その他のＳＩＰフォン又はその他のフォンへのオーディオコールを確立できる。

ビデオフォン(15)は、それが取り付けられるネットワーク(40)に高度な要求をする。ビデオフォン(15)のビデオフォンコールは、連続的な高帯域幅を提供して、帯域幅、待ち時間及びジッタを保証するようにネットワーク(40)に要求する。マルコーニ株式会社は、高度なクオリティオブサービス用途をサポートするネットワークを提供することを専門に行っている。ビデオフォン(15)の会議部屋バージョンも利用可能である。

ビデオフォン(15)は、通信端末(プラットホーム)であり、ユーザのＰＣ(68)を用いて、コンピューティングプラットホームを完全に統合する能力を有している。ＰＣ(68)用のビデオフォン(15)のアプリケーションは、ＰＣ(68)と、これに関係するビデオフォン(15)端末との間で多くのインテグレーションサービスを提供する。これには、ビデオフォン(15)の会議コールのパーティ間でネットミーティングセッションを自動的に確立することが含まれ、もし可能であるならば、ホワイトボードやプレゼンテーション等のアプリケーションが共有される。また、ＰＣ(68)上の番号にビデオフォン(15)で「ドラッグアンドドロップ」ダイヤルをすることを含むその他の機能も含まれる。

一連のサーバは、好ましくは各々がＳＩＰサーバであって、これらを用いて、ネットワーク(40)装置のコールの制御及び機能が実現される。これらは、通常のコンピューティングプラットホーム上で動作するソウトウェアサーバであって、リダンダンシ(redundancy)の能力がある。また、これらのサーバは、ユーザコンタクト情報データベースとユーザ選択データベースのローカルコピーを管理する。これらサーバで利用できるアプリケーションによって、企業の、又はその他のＬＤＡＰアクセス可能なディレクトリへのアクセスがもたらされる。

同期サーバ(66)は、ユーザメインコンタクトデータベースと、サーバ(66)(好ましくはＳＩＰ)上のローカルコピーとの間の同期を維持する。アウトルックエクスチェンジ又はロータスノーツの同期化がサポートされる。一連のメディアゲートウェイ(70)は、アナログ又はデジタルＰＳＴＮネットワーク(40)に使用される。一連のメディアゲートウェイ(70)は、最も一般的なＰＡＢＸ装置とインターフェイスして、それらＰＡＢＸに関係するボイスメールシステムを含んでいる。

メディアサーバ(66)は、ビデオフォン(15)端末に多数のサービスを提供する。それは、必要に応じて、４つのパーティに渡るビデオ会議の会議ブリッジ(Bridging-Conference server)(66)として働く。また、それによって、ビデオフォン(15)の規格と、Ｈ３２０/Ｈ３２３のような、その他の一般的なオーディオ又はビデオフォーマットとの間でトランスコーディングが可能となる。それによって、録音再生機能が提供されて、セッションが録音再生可能となる。それによって、トーン及びアナウンスメントのソースがもたらされる。

ＳＩＰファイヤーウォールのような、使用されている規格に従うファイヤーウォールが、(ＳＩＰプロキシソフトウェアのような)一般的なプロキシソフトウェアの制御下において、動的に生成されたＲＴＰストリームを安全に通過させるのに必要とされる。ＴＶサーバ(66)がソース又はＴＶ配給元として機能して、ビデオフォン(15)のユーザは、例えばＣＮＮのような、サポートされている任意のチャンネルを選択できる。

ビデオフォン(15)は、イーサネット及びＡＴＭデスクトップ用である。ビデオフォン(15)端末はエンドツーエンドのＡＴＭ ＳＶＣをサポートし、それらを用いて、必要なレベルのクオリティオブサービスで接続を確立する。また、ビデオフォン(15)は、ＬＡＮＥサービスを用いてＩＰ接続をサポートする。これを行って要求されるＱｏＳを保証するために、ＬＡＮＥ２が必要とされる。ビデオフォン(15)は、ＡＴＭに接続されたデスクトップＰＣ(68)へのＡＴＭパススルーを与え、又は、ＡＴＭからイーサネットへのパススルーを与えるので、イーサネットを介してＰＣ(68)に接続可能となる。

ビデオフォン(15)には、エンドツーエンドＱｏＳをサポートすることが必要とされる。イーサネットに接続されたビデオフォン(15)について、ユーザ接続は、８０２.１ｐ、ディフサーブ(DiffServ)及び/又はイントサーブ(IntServ)、或いはそれ以上をサポートする必要がある。送り先がＡＴＭネットワーク(40)を用いて到達可能である場合、イーサネットからＡＴＭへのゲートウェイ(70)が与えられる。ＳＩＰプロキシサーバ(66)及びＳＩＰシグナリングは、ターゲットのビデオフォン(15)端末に最も近いＡＴＭのエンドポイントを、即ち、それがＡＴＭ接続されていればそのＡＴＭアドレスを、又は、最も近いＡＴＭゲートウェイ(70)を確立する。シグナリングは、適切なＱｏＳで、ネットワーク(40)のＡＴＭ部分に渡ってＳＶＣを確立する。このＳＶＣは、離れた端部にて適切な優先度表示を生成する特定のイーサネットフローにリンクされる。

ビデオフォン(15)の製品ラインは、幾つかの端末(装置)と、これら装置に構築されない特徴を与える一連のサーバと、現存する設備及び外部のＰＳＴＮサービスに製品を接続する一連のゲートウェイ(70)とで構成される。システム(10)で与えられる基本的な機能は以下の通りである。

≡ 「オンネット(on-net)」の全てのコールでビデオが利用でき、オーディオとビデオの品質が非常に高いテレフォニーサービス。
≡ オーディオ及びビデオに関しており、臨機応変に又は予め計画されており、完全にセルフサービスであって、テレフォニーサービスに完全に組み込まれたマルチパーティ会議サービス。
≡ コラボレーションの可能性を決定する種々のツールを伴うプレゼンスサービス。
≡ 共有サーフェスサービス−電子ホワイトボード、アプリケーションの共有、ドキュメントの共有、プレゼンテーションの配信。
≡ その他の価値が、放送されるビデオ(大勢へのマイクメッセージ)のＴＶ配信のようなその他の価値が加えられたサービス。オンラインのインタラクティブトレーニング等である。必要ならば、セッションを記録するサービスも利用される。

ビデオフォン(15)は、劇的に新しい機能を有する電話であって、電話がすることをコンピュータが行おうとしているのではない。これによって、コンピュータが得意である事柄に、コンピュータを完全に同時利用する一方で、通信について、柔軟な、しかし用途が特定された装置を提供できる。ユーザインターフェイス及び物理的なデザインは、この用途に合わせられて、瞬時にオンになり、ＰＣ(68)のようではなく現在の電話のような、高い信頼性のあるデバイスがもたらされる。また、このアプローチは、デバイスの動作環境の制御をもたらして、ＰＣ(68)のハードウェア及びソフトウエアの構成上の問題に関するサポートの問題が無くなる。

人的要因の研究は、オーディオの質が、効果的でトランスペアレントな通信にとって、最も重要な唯一の因子であることを、幾度となく明らかにしてきた。ハンドセットは重要であるが、質が優れたハンズフリーオーディオによって、新たなレベルの効果的な遠隔共同作業がもたらされる。ハンズフリーオーディオは、音響エコーキャンセル(ＡＥＣ)と、オートゲインコントロール(ＡＧＣ)と、ワイドバンドなオーディオ能力(Ｇ.７２２ ８ｋＨｚ帯域幅又はそれより大きい)と、ステレオ出力と、ＰＣ(68)の音声出力の統合とを含んている。高質のマイクロフォンアレイもあり、空き缶(tin-can)効果を制限するように設定及び処理される。

ビジュアル出力と、ボタン/選択入力とについて、簡単で、クリーンで、直感的理解が容易であり、柔軟性が充分にあるプラットフォームが用いられる。これは、第１のビデオフォンモデルでは、高質のＴＦＴフルカラースクリーンであり、１７インチのダイアゴナルな(diagonal)１６×９のスクリーンで、解像度は、１２６０×７６８又はそれより大きく、中間解像度(medium resolution)の長寿命タッチパネルで覆われている。明るく(＞２００ｎｉｔ)、視角が広い(＞＋−６０°)アクティブマトリックスパネルが用いられて、フルモーションビデオを表示し、オフィス環境にて満足に鑑賞される。より大きく、より明るく、より早く、コントラストがより高く、視角がより広いスクリーンを使用してよい。

ビデオフォン(15)は、ＴＦＴカラーＬＣＤを用いており、インテルセレロン/４４０ＭＭＸ及びＬｙｎｘＶＧＡコントローラに基づいたＶＧＡタイプのディスプレイ(54)インターフェイスを伴うアーキテクチャのような、ＰＣ(68)を有している。

高質のデジタル４８０ラインのプログレッシブスキャンカメラが用いられて、少なくとも６４０×４８０ビデオで、１秒当たり３０フレームが得られる。ビデオフォン(15)は、ＭＰＥＧ２エンコードを用いており、セットトップボックスに関するビデオエンコーダ(36)技術を利用している。様々な異なるビットレートを生じることができ、ビデオの質は、１対１のコールに利用されるリソースと、１又多対多のコールの最高質の参加者とに適したものになる。統合された高質のカメラモジュールがスクリーン近くに配置され、外部ビデオ入力(ファイヤライン)が設けられて、追加のカメラ、ＶＣＲ又はその他のビデオソースが使用可能となる。

デスクトップへの現存するイーサネット接続は、１０/１００ＢａｓｅＴであり、ＬＡＮ、ＷＡＮ、ＰＣ(68)デスクトップや、種々のサーバ、プロキシ及びゲートウェイ(70)への接続に必要な唯一の接続である。オーディオ及びビデオのタイムクリティカルなＲＴＰストリームには、８０２.１ｐを用いて優先順位が付与されて、ＱｏＳのために、ＬＡＮのイーサネットドメイン内に機構が提供される。また、ディフサーブもサポートされ、ＲＳＶＰはオプションとしてサポートされる。デスクトップへの配線をさらに設ける必要がないように、ビデオフォン(15)は、小さな１０/１００イーサネットスイッチを含んでおり、現存するデスクトップのポートがフォンとＰＣ(68)の両方で使用できる。

また、ビデオフォン(15)は、ＡＴＭインターフェイスをサポートする。インターフェイスは、ＨＥ１５５Ｍｂiｔｓ/ｓｅｃカードの使用をベースとしており、ファイバー又は銅のインターフェイスを伴っている。ビデオフォン(15)には、ＡＴＭパススルーポートが設けられており、ＡＴＭ接続されたデスクトップに接続され、又は、イーサネット接続されたＰＣ(68)が、ＡＴＭ接続されたビデオフォン(15)に接続される。

会議部屋環境についてのコスト及び性能のトレードオフは、デスクトップについてのトレードオフと明らかに異なっている。ビデオプロジェクションと、遠隔でパン/チルト/ズームが可能な複数のカメラと、複数のマイクロホンと、リアプロジェクション型ホワイトボードと、会議部屋環境に適したその他の製品とが、会議ルームのビデオフォン(15)に統合される。会議部屋環境とデスクトップの相互作用は、シームレスでトランスペアレントである。この環境は、ＯＥＭ装置を大いに使用するであろう。ＯＥＭ装置は、デスクトップ用に所定の位置に配置されて、同じ設備及び標準器に接続されている。ハードウェアのデザインは、基本的に同様であって、複数のマイクロホンについてさらにオーディオをサポートし、複数のカメラ及びディスプレイについてさらにビデオをサポートする。その代わりに、低コストのＳＩＰフォンにリンクするＰＣ(68)のアプリケーションが使用されてもよい。アプリケーションは、ＰＣ(68)がタッチスクリーン(74)を有している場合、マウス又はタッチスクリーン(74)の何れか一方で駆動される。それらのデスクトップとその他の配置が、上述のコラボレーション機能を必要としない場合、システム(10)と共に動作する典型的なフォンが使用できて、配線又はＰＢＸを追加する必要はない。

ＳＩＰ(セッション開始プロトコル)標準を用いて、端末装置は１又は２以上のサーバでサポートされており、これらサーバは、登録、ロケーション、ユーザプロファイル、プレゼンス、及び種々のプロキシサービスを行う。これらサーバは、廉価なリナックス又はＢＳＤマシンであって、ＬＡＮに接続されている。

ビデオフォン(15)は、ＰＢＸ機能のキーセットが設けられたフォンであって、キーセットには、トランスファー、フォワード、３(及び４、５、・・・)パーティ会議、呼び手(caller)ＩＤ＋、コール履歴等が含まれる。これら機能の幾つかは、「ＣＰＬ」と称されるＳＩＰ拡張機構のトップに構築されてよい。拡張機構は、実際には言語であって、安全で拡張可能な方法で、コールの処理が行われる。

ビデオフォン(15)は、アクティブプレゼンス及びインスタントメッセージングを提供する。分散したグループによる共同作業は日々増加しており、プレゼンスは、このような作業に対して最も革新的なツールであって、それによって、人々は、誰がいるのか、彼らは何をしているのかを知ることができる。それは、オーバーヘッドが非常に小さい発呼のベースとなり、テレフォンタグ及び従来の番号のダイヤリングが無くなり、グループに働きかけて、現在一般的であるバラバラの１対１のフォン会議を通じてよりも、よりグループとして通信可能となる。インスタントメッセージング(リアルタイムｅメール)の統合は、おそらくＰＣ(68)のキーボードを入力に使用して、短いテキストのメッセージを遅延なく交換する方法を与える。

ビデオフォン(15)は、分散/冗長(redundant)アーキテクチャを提供する。これは、フォンシステム(10)であって、信頼性が必要とされる。また、それは、ローカルエクステンションを用いて中央管理され、分散したサーバは、全てのユーザに「瞬時に」応答する。ＳＩＰプロキシの種々の機能の各々は、例えば、ＳＩＰが用いられている場合、ネットワーク(40)内に配置された冗長バージョンを用いて、それらが一連の物理的サーバ内にて任意に結合できるように展開される。

マイクロソフトネットミーティングは、共有サーフェス及び共有アプリケーション機能に用いられる。ＰＣ(68)及びＰＤＡ用のコンピュータ/テレフォニーインターフェイス(ＣＴＩ)を用いることができ、これは、統合されたコンタクトリスト、選択されたフォンの番号又は名前へのオートダイヤリング、コール履歴のカレンダーロギング、コンタクトの自動エントリ等の機能を含んでいる。

ＲＴＰフローが動的に割り付けられるＵＤＰポートを用いるので、ＳＩＰには、ファイヤーウォールに関する問題があり、アドレス/ポート情報がＳＩＰメッセージに載せられる。これは、ファイヤーウォールが、ＳＩＰメッセージをトラックして、適切なアドレス/ポートの組合せについてファイヤーウォールに「ピンホール」を開ける必要があることを意味する。さらに、ＮＡＴが使用される場合、適切に変更されたアドレス/ポートを有するように、メッセージが変更される必要がある。このような仕事を達成する２つの方法がある。一つの方法は、ファイヤーウォール内にその能力を構築することである。トップ３のファイヤーウォールベンダー(チェックポイント、ネットワークアソシエーツ及びＡｘｘｃｅｎｔ)は、これを提供している。一方の方法は、メインのファイヤーウォールと並行動作して、単にＳＩＰを扱う特殊用途のファイヤーウォールを設けることである。このようなファイヤーウォールの市販バージョンには、マイクロアプリアンスのものがある。ＳＩＰ又はネットミーティングは好ましい実施例であって、必要とされるそれらの機能が個々に実行されることに留意すべきである。必要な機能が与えられる場合には、それらの代替物が使用されてよい。

図５は、ビデオフォン(15)端末の主たる物理的構成要素を示している。スタンドは、メインディスプレイ(54)パネルの高さを容易に調整し、その高さにパネルを保持する手段を与える。高さ調整の範囲は、少なくとも６インチの行程であって、異なる高さのユーザに対処できる。スタンドは机の上に置かれており、デスクトップの高さは画一化されていると仮定する。スタンドとメインユニット間のリンクは、ユーザの好みに合うように、限定された角度で垂直方向にチルトして、その角度で容易にロックされる。チルトの量は、垂直方向について−０＋１５Ｅ必要とされる。メインユニットは、オプションとしてのスタンドアセンブリを必要とすることなく、壁に直接掛けることができる。

メインユニットのケースは、ビデオフォン(15)の設計におけるその他の構成要素全てのハウジングであって、図５に示した全てのものと内部の電子装置の全てとを含んでいる。ケースには、左側又は右側の何れか一方にハンドセットが装着される。右利きの人は左手でハンドセットを手に取る傾向があり(彼らは、右手でタッチスクリーン(74)を駆動し、書き物をする)、左利きの人はその反対である。左側の位置が通常であるが、ハンドセットを右側に配置することも可能である。スピーカジャックがケースに設けられており、スピーカ(64)をビデオフォン(15)から離れて備え付けることができる。入力は、関係したＰＣ(68)のスピーカ出力を処理するために設けられており、ビデオフォン(15)は、ＰＣ(68)及びビデオフォン(15)のオーディオを制御できる。スピーカ(64)への(ブルートゥース又はソニー規格による)ワイヤレス接続が使用できる。

ハンドセットはユニットとして設けられており、ＲＪ９コイルケーブル及びコネクタジャックを用いて接続する。置かれている場合には、ハンドセットは容易に手に取られて、さらに、邪魔にならないようにすべきである。ハンドセットオプションは、ハンドセット標準のキーパッドを提供する。ワイヤレスのハンドセットは、端末のユーザの機動性を向上させるために用いられる。

ジャックは、ステレオハンドセット＋マイクロホンの接続用に設けられる。通常の電話の会話用のハンドセットの使用が増加している。ユーザは、ハンドセット＋ブーム(boom)が装着されたマイクロホン、又はヘッドセットのみの使用を選択でき、入力デバイスとしてマイクロフォンアレイが用いられる。端末のユーザの機動性を改善するワイヤレスヘッドセット用のオプションがある。

ＩＲポートが設けられて、ＰＤＡ及びその他のＩＲデバイスにインターフェイスする。ＩＲポートは、容易にアクセス可能なようにメインケース上に配置される。差し当たって、フォン及びＰＤＡのＩＲインターフェイスは、最も一般的なものであり、それ故、同様な理由から、ＩＲインターフェイスと同様に、ブルートゥースインターフェイスもそのように要求される。

アレイマイクロホンは、ケーシングに埋め込まれる。アレイは、端末の通常動作の結果として、外部ノイズを生成してはならない。特に、タッチパネル上でユーザの動作を検出可能にすべきではない。アレイマイクロホンによって、ユニットのフロント回りの(例えば６フィートの)円弧及び水平面の１１０Ｅ内にて、所定のデジベルのバックグラウンドノイズが存在する状態にて、ユーザは、通常の会話レベルで話すことができる。ユニットは、マイクロホンが動作/非動作である旨の明確な表示を、即ち「オンフック」又は「オフフック」と同等である表示をする必要がある。ビデオフォン(15)のユーザは、知らない間に聞かれていないという安心を求めるであろう。これは、カメラの機械的なシャッタと同等なオーディオとなる。

メインのビデオフォン(15)ユニットは、スマートカードリーダオプションを具えており、個人的な特徴を用いた端末への安全なアクセスがもたらされる。ビデオフォン(15)へのアクセスは、スクリーン上の簡単なパスワードログオンからセキュリティフォブ(fob)までの、数々のアクセスコントロール特徴を必要とするだろう。スマートカードリーダは、これらアクセス方法の一つを提供する。

チルト及びパンがスクリーンから制御可能である場合、好ましくは、パン及びチルトが電子的機構のみを用いており、機械的機構を必要としない場合、明らかに利点がある。カメラのマウントは、可能な限りメインスクリーンの上部に近いように装着されて、アイコンタクトが改善されるべきである。

カメラには、４８０ｐの出力を生成する能力があるデジタルカメラを用いるべきである。カメラの出力は、ＭＰＥＧ−２エンコーダ(36)に送られる。カメラを動的に設定可能として、カメラの出力が最適化されて、エンコーダ(36)の選択された出力データレートでエンコーダ(36)に送られるようにすべきである。顔は、カメラが受信する入力の大部分を形成する。それ故に、肌のトーンについて広い範囲のライティング状態下で行われる正確なキャプチャが、基本的な特性となる。

カメラは、３ｌｕｘに至るまでの、肌のトーンについて広い範囲のライティング状態下で動作すべきである。カメラは、自動ホワイトバランスを行えるべきである。ホワイトバランスの変化は緩やかであり、キャプチャされた画像の移行(transient)が画像の摂動(perturbation)を起こさないようにすべきである。最後の５秒に渡る変化のみが、ホワイトバランスを変化させるべきである。カメラは、１８インチから１０フィートまでで焦点が合うべきであり、即ち、大きな被写界深度を有している。カメラは、２０フィートまでで焦点が合うのが好ましい。ホワイトボードに何か情報がある場合、ユーザとその情報の両方に対してピントが合う必要がある。オートフォーカスは、ユーザの動作中にカメラが最適な焦点を絶えず探すものであり、受信機側にて乱れた画像を生じるので避ける必要がある。

カメラは、１人のユーザがちょうどカメラの前にいる設定から、数人のユーザが同時に１つのビデオフォン(15)上にある設定まで、有限のズーム能力(limited zoom capability)を可能としている。その代わりとして、異なったレンズが設けられてもよい。レンズの視野について述べると、これは、例えば３０Ｅの視野から７５Ｅの視野として定められ得る。

カメラは、例えば１２８０×９６０の画像のような、送信に要されるよりも大きな画像を入力できるべきである。これは、有限のズームと、水平及び垂直のパンとを電気的に可能とし、カメラに関するエレクトロメカニカルな制御の必要性を無くす。「オンスクリーン」の装着が、単にカメラのサイズで出来なくなることがないように、カメラは物理的に小さくすべきである。

中間解像度の長寿命タッチパネルは、ビデオフォン(15)と通信する主要な方法を構成し、メインディスプレイ(54)の前部を構成する。何度も指が接触することから、パネルは、汚れを落とす掃除の繰り返しと、ディスプレイ(54)の質に影響を与えるであろう指紋とに耐えなくてはならない。タッチパネルの較正が、即ち、タッチパネル上で触られる領域とディスプレイ(54)の下部の間のアライメントが「フォールスタッチ(false touch)」の要求を保証することが容易であるべきである。

タッチスクリーン(74)の表面は、表面の反射を可能な限り少なくして、窓に向いている場合でもディスプレイ(54)が鮮明であるようにすべきである。「フォールスタッチ」がまれにしか起きないということが必要とされる。タッチパネルの解像度の要求は、それ故に、タッチが区別しようとしている最も小さいディスプレイ(54)の領域に非常に依存している。解像度と視差の誤差とは相まって、平均的な訓練を受けたユーザが、これらの因子によって「フォールスタッチ」をする可能性が５％未満になるようにすべきである(２０回の選択に１回のフォールスタッチがある）。このフォールスタッチ率は２％未満であるのが好ましい。即ち、５０回の選択に１回のフォールスタッチがある。

必要に応じて、成功したタッチの音響及び/又は視覚フィードバックがユーザに与えられなければならない。これらのトーンは、その時点にてタッチスクリーン(74)のディスプレイ(54)上にあるものに応じて変化してよい。例えば、キーボードを用いている場合、キーボード音に似た音が適切であり、ダイヤルパッドを用いている場合、個々に異なる音が適切であり、その他も同様である。音響フィードバックは、全ての状況にて必要ではなく、タッチの成功を示すある音響又は視覚的な表示がユーザの助けとなってもよい。ユーザは、トーンのオン/オフが可能であり、ある設定画面にて、タッチに関係したトーン、トーンの持続時間及びボリュームレベルの設定が可能とすべきである。デフォルト値が与えられるべきである。また、タッチスクリーン(74)には、指に加えてペンが使用できる。

ディスプレイ(54)パネルは、少なくとも１７インチダイアゴナルフラットパネル(又はより良いもの)であって、フルカラーディスプレイ技術を用いており、アスペクト比は１６×９であるのが好ましいが、１６×１０でもよい。

スクリーンの解像度は、少なくとも１２８０×７６８とすべきである。視認可能な角度は、垂直平面及び水平平面の双方について、少なくとも６Ｅ外の軸とすべきである。スクリーンのコントラスト比は、一般的な３００：１よりも良くすべきである。色解像度は、１色当たり少なくとも６ビットとすべきであり、即ち、プロトタイプユニットで適切な、１色当たり６ビットで２６２Ｋの色を表示できるようにすべきである。その他の条件が同じとして、製品ユニットでは、１色当たり８ビットが好ましい。ディスプレイ(54)パネルは、充分に高輝度であって、充分に明るく又は自然に明るくされた部屋でさえも、楽に見られるようにすべきである。輝度は、少なくとも３００ｃｄ/ｃｍ²とすべきである。ディスプレイ(54)及びデコードのエレクトロニクスは、７２０Ｐの高解像度の画像を表示可能とすべきである。このような画像は、ネットワーク(40)上の適当なソースから送られる。

バックライトは、最小寿命にて、少なくとも２５,０００時間で最大輝度の５０％に至るものとすべきであろう。ビデオフォン(15)端末が休止しており、バックライトが切れている場合、着信コールがある場合やユーザがタッチスクリーンの何処かに触れた場合、バックライトは自動的にオンになるべきである。タッチスクリーンがオフになった後の休止期間は、ユーザによって設定可能であって、この設定は、「オフしない」ことまで含むべきである。

ビデオフォン(15)の接続領域に必要な接続が、図６に示されている。各コネクタの要件は、以下の段落にて簡潔に説明されている。

２つのＲＪ４５ １０/１００イーサネットコネクタは、ネットワーク(40)への接続、及び関係するＰＣ(68)からの接続に用いられる。

ＡＴＭパーソナリティモジュールにオプションのプラグが設けられて、光学及び銅のインターフェスの両方について、ビデオフォン(15)が、容易に１５５Ｍｂｉｔｓ/secのインターフェイスをサポート可能にすべきである。

ＵＳＢポートが設けられて、例えば、キーボード、マウス、廉価なカメラ等のオプションである種々の周辺機器が容易に接続可能にすべきである。

１３９４(ファイヤライン)インターフェイスが設けられて、外部の(ファイヤライン)カメラ又はその他のビデオソースに接続可能とすべきである。そのインターフェイスによって、ファイヤラインインターフェイスの完全なインバンドカメラ制御が可能となる。必要な外部コンバータが用いられて、Ｓビデオからファイヤライン入力への変換をすべきである。会議へのビデオフォンの出力において、このソースをメインカメラソースの代わりに使用可能とすべきである。ノーマル又は「ＣＮＮ」モードを、即ち、このビデオソース上でクリップ可能(clippable)又はクリップ不可能であるかを特定可能とすべきである。ＸＶＧＡビデオ出力が設けられて、ビデオフォン(15)が外部プロジェクタを駆動可能とすべきである。その画像は、メインディスプレイ(54)に表示されたものを反映する。

オーディオ入力は、ＰＣオーディオ出力に供給されるべきである。ＰＣ(68)のオーディオとビデオフォン(15)とのオーディオの統合を確保するために、１組のスピーカ(64)のみが配置されるであろう。ＰＣ(68)の音は、ビデオフォン(15)のオーディオチャンネルを通るであろう。１つ又は１対のジャックが設けられて、ヘッドセットと、ブームが取り付けられたマイクロホンとが接続される。ヘッドセットのみの動作も、内蔵マイクロホンアレイを用いて可能とする必要がある。ヘッドセットジャックが比較的アクセスし難い場合、ヘッドセットを接続されたままにして、ユーザの制御によって、オーディオがヘッドセット上であるか否かを選択可能にすべきである。外部の左側及び右側スピーカ(64)が接続される。図７に示すように、１、２又は３つのビデオフォン(15)ユニットを、それらが、単一の機能のユニットであるかのように使用可能である。

２以上のビデオフォンが配置される場合、１つのユニットのみがメイン制御パネルとして動作し、その他のユニットはビデオと、表示されているそのビデオに直接関係した制御手段とを表示する。これらの如何なる配置についても１組のスピーカ(64)のみが必要とされるのみであろう。

マイクロホン入力及びオーディオストリームに関して、多数のオプションが設けられて、一般的な１つのマイクロホン入力を用いることから、各マイクロホンアレイからビデオフォン(15)のビデオソースにオーディオを送ることまで、可能とされるべきである。

ビデオ入力について、多数のオプションが設けられるべきである。デフォルトでは、「制御パネル」ビデオフォン(15)のビューが送信されるべきである。帯域幅がさらに利用可能である場合、各ユーザは、ユーザが表示されるスクリーンからビデオを得られ、さらに自然な経験が得られる。複数のビデオフォン(15)端末の調整は、ＬＡＮ接続を用いて得られ、つまり、特殊な如何なる連絡ケーブルも必要とされない。

ビデオフォン(15)は、多数の主な機能を提供する。
−それは、オフィスフォンとなる。
−それは、ユーザのフォンとなる。
−それは、ビデオフォンとなる。
−それは、会議フォンとなる。
−それは、ビデオ会議フォンとなる。
−それは、コンタクトの詳細への容易なアクセスと、それらの管理とを行う。
−それは、ボイス/ビデオメールへのアクセスと、それらの管理とを行う。

ユニットの機能は、２つのカテゴリ、つまりユーザ機能及びシステム機能に分類される。

ユーザ機能は、ユーザが利用できる全ての機能である。

システム(10)の機能は、Ｉ.Ｔ.が要求する機能であって、モニタを設定し、ビデオフォン(15)端末を維持するものである。それらは、通常のユーザには見えない。実際に、デザイン全体の重要な目的は、ユーザに非常にシンプルなインターフェイスが与えられて、ほとんど訓練することなくビデオフォン(15)が使えることを確実にすることである。

以下に示される基本的な機能の組は、利用可能とすべき機能の最小の組である。

ビデオフォン(15)は、ユーザが端末にログオンしていない場合、通常の電話として動作する。その機能は、関連するＰＣ(68)があることに全く依存してはならない。

以下に示されるビデオフォン(15)の機能は、オフィスにおける一般的なフォンのものである。

端末は、サイトに奉仕するＰＡＢＸ上の一般的な内線番号を得ることが可能である。

端末は、ＰＡＢＸ上の、ビデオフォン(15)のネットワーク(40)上の、又は外部のフォンの区別なく、どんなフォンから送られた着信コールをも受け取ることが可能である。

ビデオフォン(15)は、互換性のあるその他のＳＩＰフォンから送られるコールを受け入れ可能である。

着信コールは、設定されたように(以下の設定スクリーンの要件を参照のこと)ベルのトーンを生成する。特に、ビデオを含むビデオフォン(15)コールのベルトーンには、コールがビデオフォン(15)の端末から送られるか否かに拘わらず、オーディオのみのコールと区別するベルトーンが選択できる。

着信コールは、ディスプレイ(54)のステータス領域に、着信コールの表示を生成する。この表示は、着信コールで得られる情報と同じ程度の発呼側ＩＤ情報を与えるか、誰も応答できないことを示さなくてはならない。

ａ）着信コールのステータス表示上にあるコールアクセプトボタンを押すことで、着信コールを受け入れできる。
ｂ）ハンドセットを持ち上げることで、着信コールを受け入れできる。これは、提供されるオプションの全てを、即ちビデオ及びオーディオを常に受け入れる。

ユーザは、コール中に、ハンドセットと、ハンズフリー(スピーカフォン)動作との間で切り替え可能である。コール中にハンドセットを持ち上げると、スピーカフォンモードからハンドセットに自動的に切り替わる。スピーカフォンモードを再選択することなしにハンドセットを戻すと、コールが切断される。

スクリーン上の表示は、モードで、即ち、ハンドセット又はハンズフリーで定められるべきである。

コールステータスバーは、コールの継続時間を表示できる。

メインディスプレイ(54)上での簡単な制御により、着信コールのボリュームを調整可能である。ヘッドセット及びスピーカのボリュームは独立して調節可能とすべきである。

スピーカフォンモードである場合、コールを切断することなくハンドセットをハンドセットスタンドに戻すことが可能である。

＄ユーザが、コールステータス表示上のクリアボタンを押すと、コールが終了する。
＄ハンドセットモードであって、ハンズフリーが選択されていない場合に、ユーザがハンドセットを戻すと、コールが終了する。
＄コールがビデオフォン(15)に確実に示されている場合に、離れたパーティがコールを切ると、コールが終了する。

ホールド−コールをホールドし、さらにコールのホールドを再度オフにすることを可能とすべきである。ホールド状態は、ホールドされたコールに出るボタンを用いて、ステータス表示に表示されるべきである。

コール待ち−さらに送られる着信コールは、ディスプレイ(54)のステータス領域に着信コール表示を生成する。それは、設定メニュで使用可能とされない場合、コールのトーンを生成しない。

現在の動作モード、即ちハンドセット又はハンズフリーモードにて、ステータスディスプレイ(54)上のコールアクセプトボタンを用いて、新たな着信コールを受け入れできる。

別の着信コールを受け入れると、現在のコールは自動的にホールドになる。

任意のコール上で「ホールド中止」ボタンを押すと、その他のコールは自動的にホールドに移行する。

同時に存在する処理可能な着信コールの数は、ステータスディスプレイ(54)のスペースを利用して設定される。それは、２つのコール未満にはされない。

現在のコールの数が処理可能な数を超える場合、その他の着信コールは、
ａ）ビジートーンを発生させ、又は、
ｂ）ボイスメールに直ちにフォワードされ、
ｃ）設定された転送番号に直ちにフォワードされ、
ｄ）記録メッセージを送られる。

「コールフォワードビジー」設定が、ユーザによって定められる。

着信コールが受け入れ限界内であって、(設定自在な)時間間隔内で応答されない場合、コールは、
ａ）ボイスメールにフォワードされる。
ｂ）以前に設定された転送番号にフォワードされる。
ｃ）記録メッセージを送られる。

「コールフォワードノーアンサー」設定が、ユーザによって定められる。

コール転送−ユーザは、どんなコールもその他の番号に容易に転送できる。転送機能は、コールをホールドして、新しい番号にダイヤル可能である。鳴り響くトーンが聞こえると、ユーザに、転送を完了するオプションが与えられる。また、ユーザは、新たな番号と通話して、その後、転送を開始すること、又は、会議コールの全て(３つの)パーティを初めて合わせることの何れか一方を行う。後者の場合、その会議コールを抜け出す機能が、ユーザに提供される。コールした端末から、応答が、又は直ちにボイスメールが送られない場合には、ユーザに、元のコールに戻るオプションが与えられる。

コールフォワード−予め設定された番号に着信コールを自動的にフォワードするようにフォンを設定できる必要がある。コールフォワードは、
ａ）無条件であり(unconditional)、
ｂ）ビジーの場合にフォワードし、
ｃ）応答がない場合にフォワードする。

会議コール−ボイスコールが最初であるか否かに拘わらず、オーディオのみの会議で会議コールが可能である。少なくとも３つのコールで、即ち４方向の会話で、会議を開催可能である。常に１つの会議をサポートすることのみが要求されるが、やはり、コール待ちについて先に説明したように、もう１つの着信コールを受け入れ可能であることも要求される。プロトタイプでは、特定の会議への１つの着信コールを受け入れることのみ可能であって、即ち、ビデオフォンではないコールに外部ブリッジが必要であってよい。

着信コールステータス表示のオプションによって、ユーザは、会議接続にコールを加え、又はそれから除去できる。

着信又は発信コールであるか否かに拘わらず、コールを会議に加えることが可能である。

遠隔の会議ユーザがコールを切った場合、そのコールの行程は自動的にクリアされる。

コールは、ハンズフリーにされるか、ハンドセットを用いて行われる。ハンドセットを持ち上げることで、コール中でないならばダイヤルパッドが使用可能となり、オーディオがハンドセットに繋げられる。オンスクリーントーンのダイヤルパッド(即ち、数字「１」から「０」と「^★」及び「＃」)が必要とされる。さらに、ポーズボタンが設けられて、(ＰＡＢＸと通じるために(但し、ゲートウェイ(70)がこの要求を排除するようにプログラムできる場合を除く))ダイヤルされる文字列にポーズを挿入可能となる。＋キーが加えられて、＋記号は、そのロケーションについてインターナショナルなアクセス文字列に自動的に変換されるように配慮すべきである。

入力エラーを修正するキー(例えば[バック]キー)及び入力をクリアするクリアキーも必要とされる。[バック]キーを短押しすると、最後に入力された番号が除去されて、長押しすると、番号の除去が継続されて、終わると番号のレジスタがクリアされる。

番号表示は、自動的にローカルな番号フォーマットに変換される。[これには、国ごとにスタイルが異なるので、ユーザが動作する国を選択する必要がある。また、インターナショナルコードが入力される場合には、そのコードは、番号の残りの部分をフォーマットする基礎として用いられる。]

トーン番号パッドを用いて機能を選択するサービスに接続される場合、オンスクリーンのキーパッド、又はハンドセットのキーが用いられる際に、正しいトーンが、そのサービスの指示にて生成される。ダイヤルパッドは、コールが如何様に開始されるかに拘わらず、この機能を与える。

リダイヤル−適当に特定されるファンクションを一度タッチすると、最後にダイヤルした番号をリダイヤルできる。

オートリダイヤル−例えば、[リダイヤル]ボタンを一定時間そのままにしておくと、オートリダイヤル機構が動作を開始する。先の試みが、試みた回数ビジー信号を返す場合、リターンオートリダイヤルは、自動的にコールを繰り返す。

キャンプオンビジー(CAMP ON BUSY)−それをサポートするデバイスにコールをする場合、「キャンプオンビジー」機能が利用される。コールされたパーティがコールに出れるようになると、キャンプオンビジーは、ユーザにコールバックする。コールされた番号がキャンプオンビジーをサポートできない場合、メッセージが生成されて、「このサービスは利用できない」旨が述べられる。

ユーザがビデオフォン(15)にログオンしていない場合、適当なログオン画面を表示可能である。

頻出する失敗着信・送信コールのログは、統合されたダイヤル画面にて適当なビューで表示される。「リダイヤルした最後の番号」の設備にアクセスする１又は２回のタッチが、常にダイヤルスクリーン上で行える。さらに、これらのログの記述が以下にされている。

ビデオフォン(15)端末で利用できる機能のフルセットにアクセスするためには、ユーザは、端末にログインしなくてはならない。ログイン画面が出されてユーザは名前とパスワードを入力する。これは、ネットワーク(40)への通常のアクセスで名前とパスワードを入れるのと同様に行える。ビデオフォン(15)端末は、それ故に、サイトのユーザ認証サービスを利用するであろう。ビデオフォン(15)がこれらの認証サービスを利用できるように、ＩＴ作業者が設定可能とするのに必要な画面が出される。ユーザを同定する別の方法は、例えば、スマートカード又はＩＤフォブを用いることである。ユーザには、ビデオフォン(15)端末にログインする前に、ＰＣ(68)に既にログオンしている必要はない。

複数のユーザが、１つのビデオフォン(15)にログオンでき、鳴り響く着信トーンは、各ユーザについて異なるようにできる。また、着信コールの表示は、コールしているパーティの名前に加えて、コールされたパーティの名前を特定する。複数のユーザが１つのビデオフォン(15)にログオンする場合、コールをフォワードする機能の全ては、コールの届け先であるユーザに特定されている。

ユーザが既に自分のＰＣ(68)にログインしている場合、ビデオフォン(15)へのログオン行為により、ユーザがログオンしたＰＣ(68)と、このことをＰＣ(68)から確認するビデオフォン(15)端末との間で連関が生じる。ユーザは、複数のビデオフォン(15)端末に同時にログオンできる。動作中のビデオフォン(15)は、そのユーザへのコールが最初に応答されるものである。

ホームページ画面は、(フルスクリーンモードを除いて)全ての画面が見られるステータス領域を含んでいる。ステータスは、ログオンしたユーザの名前、又は「ログオンしているユーザがない」旨を含んでいる。また、ユーザの「プレゼンス」状態、ビデオ及びオーディオ送信用のアイコン、ボイスメール「メッセージ」表示、及び日付がある。

ユーザのボイスメールシステム(10)に聞かれていないボイスメールがある場合、「メッセージ」表示は、明るくされて、点滅する。表示器を押すと、ボイスメール操作画面が立ち上がる。

日付領域をタッチすると、カレンダー機能にアクセスできる。

ホームページにはコントロールバー領域が設けられて、この領域は全ての画面に渡って視認される(フルスクリーンモードを除く)。

コントロールバーは、最も頻繁に使用されたコントロール機能への直接的なアクセスを可能とし、その他全ての機能へのアクセスも可能とする。アイコンはボタン上で使用されて、また、テキストは、機能の目的を強調するために用いられる。

また、制御パネルは、マイクロホン、カメラ及びスピーカ(64)の統括的な制御をする。制御では、それらの動作状態が、例えばオン又はオフが、そして使用可能なアイコンの場所が明確に示される。

自己の画像が利用でき、カメラで撮影された画像と、アクティブコールの終端で視認できるその部分の両方とが示される。自己の画像をオン・オフすること、そして、常時オンであるか、アクティブコールが確立すると一度だけオンになるかを決定できる。

スクリーンのメインビデオ領域にて、常時、即ち、コール中の場合又はコール中でない場合等にて、カメラの画像を表示可能である。その画像は、１つのビデオコールに対応するものであって、その他のビデオ表示上にオーバーレイする。ビデオのフルスクリーンバージョンを表示可能である。これは、デジタルミラーと考えることができ、カメラが表示する又はしている画像に彼/彼女が満足していることをユーザに確認可能とする。

診断目的では、エンコード及びデコード後にユーザが画像を見られることが望ましく、これによって、ユーザは、離れた所で見られることになる画像の質を把握できる。このモードがサポートされると、カメラの画像と、エンコード、デコードされた画像とが並べて表示される。コンタクト情報に関する画像として用いるために、ユーザは、自己の画像をキャプチャできる。

ホーム画面の大部分は、統合されたダイヤル機能に割り当てられる。４つの主たる補助機能は、スピードダイヤル表示、ディレクトリアクセス表示、ダイヤルパッド、及びコールログへのアクセスである。ダイヤルパッドと、コールログへのアクセスとは、使い易さと両立した最小限度の表示領域を占めており、スピードダイヤル/コンタクトページに利用される領域が最大にされる。スピードダイヤル領域が優先して詳細にわたっており、主な補助機能の全てについて共通した要求は、スピードダイヤルの下のみで詳細にされており、その他の３つの機能には黙示的に含まれる。ダイヤル領域の機能は、コールがなされる相手であるユーザを選択する。

スピードダイヤル領域は、ダイヤルスクリーンのその他の要求に合わせて、可能な限り大きくできる。２０を超えるスピードダイヤルのロケーションが適切である。各ロケーションは充分に大きく、そのロケーションに格納される人物の詳細な情報が、通常の動作におけるスクリーンからの距離、例えば３フィートにて非常に読み易いようにされる。

スピードダイヤルロケーションに格納されたユーザの情報は、人物名を、知られているならば「プレゼンスステータス」を、そのスピードダイヤルが選択されている場合はコールされる番号を、ユーザがビデオコールをサポートしているか否かを示すアイコンとを含んでいる。また、詳細情報には、ビデオの種類が、例えば、ビデオフォン(15)、互換性のあるＭＰＥＧ２、Ｈ２６１等が含まれる。

その領域には、クリア領域が設けられており、このクリア領域は、コールを開始する際にタッチされる。使用されるならば、親指の爪の絵が含まれる。長い名前(即ち、スピードダイヤルボタンに割り当てられたスペースに納まらない名前)を処理する方法が提供される。

標準的なインターナショナルフォーマット、即ち「＋国コードエリアコード番号」における通常の電話番号は、この番号にコールするのに必要な外部アクセスとインターナショナルアクセスコードとに自動的に変換される。

スピードダイヤルページ上にて、人物に関するコンタクトの完全な詳細が利用できる。コンタクトの詳細では、ユーザがコールできる全ての番号が示されて、スピードダイヤルページで用いられるデフォルト番号として、これらの番号から１つの番号を選択する手段がもたらされる。そのコンタクトページへのこのリンクを用いて、そのユーザの別の番号を選択してダイヤルできる。

ユーザ情報は、その人物に関するつい最近のコール履歴を含んでおり、例えば、コール履歴は、失敗着信コール、送信コールの何れか一方である最後の１０コールである。「ラストコール」情報のみを提供することは、受け入れ可能な最小の機能であろう。

スピードダイヤルエントリに関してコンタクトの詳細を編集し、及び/又は、スピードダイヤルページに新たなコンタクトエントリを作成することが可能である。コンタクト画面、ディレクトリ画面、又はコールログ画面からスピードダイヤルページにエントリをコピーできる。スピードダイヤルページからコンタクト画面又はディレクトリ画面にエントリをコピーできる。スピードダイヤルエントリを削除すること、又はそのエントリを別のコンタクトページに移動することが可能である(即ち、コピーとオリジナルの削除)。

スピードダイヤルページ上にてユーザの掲載を制御可能である。また、ある方法(カラーコーディング)で、スピードダイヤルユーザの様々なクラスを、即ち、ビジネス、家族、仲間、ベンダー、顧客を区別することが可能である。スピードダイヤルページは、コンタクト情報におけるその他の複数のカテゴリからの名称をかなり含んでいてもよい。自動認証のある種のフォーム、例えば、姓・名・会社や姓・名・会社の後にクラス等のフォームが用いられる。

ユーザのグループを、１つのスピードダイヤルエントリとして定義できる。それは、グループのサイズが最大会議コールのサイズに限定される場合に受け入れられる。スピードダイヤルページからディレクトリビューを選択可能である。ディレクトリビューは、スピードダイヤルページと同じ画面領域を占める。ビデオフォン(15)がアクセスするオンラインのディレクトリの範囲から選択が可能である。デフォルトは、アウトルック及び/又はロータスノーツのディレクトリであって、それらは、ユーザの主なコンタクトの詳細を含んでいる。選択されたディレクトリの名前は表示される。

アウトルック又はノーツのコンタクトリストにおいてユーザによって確立されたカテゴリーは、選択時に利用できる。カテゴリの数が表示領域に合っていない場合、ボタンが設けられて、リストを、スクロールアップ又はスクロールダウンする。リストは、アルファベット順に整理される。

スピードダイヤルカテゴリは、スピードダイヤルページに配置されるカテゴリである。スピードダイヤルページが一杯になって、もはやこのコンタクトカテゴリにさらに名称を加えることができなく、それらが既存のエントリに取って変わらない場合、何らかの表示がされる。最近のコール順にスピードダイヤルエントリを順序付ける機能があり、即ち、最後に用いられたスピードダイヤルエントリは下側に配置されるであろう。これは、どのエントリが削除される最適の候補であるかを見るために用いられて、より使われる番号を入力可能とする。

最小限のユーザ入力で、選択されたカテゴリからエントリを容易に見つけて選択できる。エントリ選択機構は、比較的短いリストと、非常に長いリスト(１００００の名前)とについて働く必要がある。その機構は、検索されるテキスト文字列を入力できる必要がある。提示されたデータのソート順を、性、名又は組織で選択できる必要がある。入力エラーを修正して、全検索を迅速に再開する手段がある。

検索キーの順番は重要であって、ユーザが変更できることが好ましい。言い換えると、例えば、最も左の検索キーを押し続けることにより、ユーザは、姓、名又は会社(又は、属性の拡張リスト。これは、例えば、特定の部署又は特定の場所にいる者、例えば”韓国にいる者”を見つけるために使用される)による検索をすることを選択できる。第２キーは、その後、第１キーの検索の限定を行い、以下同様となる。よって、複数のキーが、会社、姓、名と設定される。例えばマルコーニの場合、姓についてマルコーニをアルファベット順に検索するユーザ検索が行われる。各ソートカテゴリが選択された場合、そのカテゴリフィールドの同じ値を用いて、エントリの下位の順序付けが黙示的になされるのは明らかである。姓が選択される場合、黙示的な下位の順序は、名そして会社であり、会社が選択される場合、黙示的な下位の順序は、姓そして名であり、名が選択される場合、黙示的な下位の順序は、姓そして会社である。

コールログ画面は、送信、着信及び失敗というコールの３つのカテゴリの最近のエントリを表示する。選択されたカテゴリは明瞭に示される。加えて、「頻出する」カテゴリがあって、該カテゴリは、任意のタイプの最近のコール(２００未満)について、頻繁に用いられる番号をリストアップする。コールダイヤル画面からダイヤルパッドにアクセス可能である。かなりの量のコールログデータの処理をもたらす値の解析は保留される。

最低の場合でも、「メッセージ」がタッチされて、ユーザへのボイスメールシステム(10)への接続がなされると、このユーザのボイスメールが入力され、ダイヤルパッドが表示されて、フォンのキーが通常押されるようにボイスメールが制御される。「ボイスメール」画面の大部分にはボタンがあって、メールシステム(10)の各機能にアクセス可能である。アクセスされる機能には、例えば、次メッセージ、先メッセージ、メッセージ再生、メッセージ転送、メッセージ応答、コール送信等がある。各ファンクション内のキー押しと等価な全てのものにもアクセス可能であって、記録開始、記録停止、記録レビュー、記録削除等がある。全てのファンクションはボタン上にあり、各々のＤＭＦトーンに変換される。

「フォワード」番号又はどのボイスメールコマンドも、ユーザの番号リストが入力される必要があり、スピードダイヤル又はディレクトリ画面ビューから選択できる。その選択によって、ユーザの番号の適当な部分が自動的に挿入される。これは、ボイスメッセージをグループにフォワードするのに特に有用であろう。ユーザは、ビデオフォン(15)上にて日時を設定可能である。適当なネットワーク(40)サービスによって、日時を自動的に設定できるのが好ましい。

カレンダ機能が利用できて、ユーザのアウトルック/パーム/ノーツスケジュール/カレンダアプリケーションと統合される。単に、日、週又は月単位で、(アウトルック又はパームのスクリーンで)任意の日付の予定が見られて、アウトルック又はパームデータベースを介してのみ可能な変更と新たなエントリとが見られることが最小限要求されるであろう。

かなり多くのユーザが自分のカレンダを保持しておらず、実際には自分の机にＰＣ(68)がないであろうが、情報を見る必要がある事態は起こり得る。画面のステータス部にあるユーザステータス領域にタッチして、ユーザは自己のステータスを設定する。ユーザには、選択可能な一連のステータスオプションがあり、i)空き、ii)ビジー−コール中であり、別のコールが受け取れない、iii)接触禁止−コール中ではないが、中断可能ではない、iv)５分内に戻る、v)オフィス外、vi)休日を含んでいる。

ビデオフォン(15)端末に１つのコールがある場合、１つの着信ストリームから、会議における最大数のストリームまでがサポートされる。ビデオ会議では、端末は、１つの会議コールの部分として、他のパーティへの少なくとも４つの接続をサポートする。最大サイズのビデオ会議コールがある場合さえも、少なくとも２つの独立したオーディオのみのコールを受け入れ可能であり、オーディオコールは会議(consultation)ホールド転送され得る。ビデオフォン(15)は、少なくとも３つの「コール状態(instance)」を同時に、つまり、独立したコールを最大で３つまでサポートできる。１つのコールのみがアクティブにできる。つまり、コール制御は、１度に、１つのコールのみに行われる。１を超えるコールが受け入れ可能である。つまり、ユーザのオーディオ及びビデオは、アクティブであるか否かに拘わらず、受け入れられた各コールに送信されている。オーディオ及びビデオがホールド中のユーザに送信されず、そのユーザから送られるオーディオ及びビデオも止められている場合、進行中のコールはホールドされてよい。

着信コールのステータスは、コントロール表示領域に示される。コール自体と、インコール制御とがディスプレイ(54)のメインセクションに示される。

コールステータスは、以下の通りである。
i) 着信コール。
ii) 受入及びアクティブ−ユーザのオーディオ(ビデオコールの場合はビデオも)は、種々のミュート制御を受けて、このコールに接続され、コール制御がこのコールに適用される。
iii) 受入及び非アクティブ−上記と同様であるが、コール制御はこのコールに適用されない。
iv) 受入及びホールド−ユーザのオーディオ(ビデオコールの場合はビデオも)は、このコールへ送信されていない。
v) 受入及び転送。

コールステータスは、各コールについて示される。受け入れられた１つのコールのみがアクティブとなる。受け入れられたコールは、そのコールに関連したコール表示の領域を又は制御パネルのコールステータスを、タッチすることでアクティブにされる。先のアクティブコールは何れも、アクティブに設定されない。２度目のタッチは、アクティブ状態をオフにする。着信コールの表示は、コールがビデオ接続を申し出ているか否かを示す。表示がないことは、オーディオのみのコールを意味する。着信コールの表示は、その着信コールに関するパーティの名称を示す。これは、直ちに、ユーザが１対１でコールされているか、又は会議への参加を勧誘されているかを示す。

ユーザは、以下のオプションを用いて着信コールを処理する。
i) 音声のみのコールとしてコールを受け入れる。
ii) ビデオコール(音声を含む)としてコールを受け入れる。
iii) ボイスメールを送る。

ビデオフォン(15)端末を設定して、サポートされるコールの最大数まで、着信コールに自動応答できる。申し出があると、自動応答は、オーディオ及びビデオ接続を生成する。 コールが一旦起こると、ユーザステータスは、自動的に「インコール」に変化する。アクティブなコールがないと、ユーザステータスは、前の状態(一般的には「空き(available)状態」)に戻る。

ユーザは、コールユーザデータも配布されるか否かを設定可能である。ユーザが、既に１又は２以上のコールを受け入れている場合、及び、全てのコールがホールドである又はアクティブでない場合、このコールは、受け入れられると新しいコール状態を生成する。受け入れられたがアクティブでないコールは全て、この新しいコールをユーザが扱う最中に、ユーザの見聞きを継続して行う。受け入れられたコールの１つが受け入れられてアクティブとなる場合、新しいコールがそのコールに加えられる。コールが受け入れられると、そのコールの全てのパーティは、新しい呼出し側にとって、会議の参加者となる。

ある時間(１０秒より大きい)の後、ユーザがコールに出ない場合、コールは、「フォワードオンノーサンサー(Forward on No Answer)」設定で定められたように、自動的にフォワードされるであろう。上述のように、フォワードは、コールの宛先であるユーザに特定される。ユーザステータスに「ドゥノットディスターブ(Do not disturb)」若しくは「ビジー(busy)」が付される場合、又は、最大数のコールが処理されている状態で「ビジー」状態が設定された場合、コールは、「フォワードオンビジー」及び「フォワードオンドゥノットディスターブ」設定で定められたように「直ちに」転送される。実施されるならば、「ショウフォワーデットコール(show forwarded calls)」設定で修正される。

「ショウフォワーデットコール」設定を用いて、着信コールが転送される前に、ユーザがある時間(５秒より大きい)の間、着信コール表示を見ることを選択できる。（これは、コールを受け取ることを望まない場合に、ユーザに対して、コールへの積極的な動作が要求されるのではなく、動作が必要とされないことを意味する。）これは、ビデオフォン(15)が既に最大数のコールを処理していることによってビジー状態が生じている場合には、これは機能しない。

コールと共に送られる(非常に短い)テキストメッセージを作成する能力は、コールの重要性及びそれがどの程度の長さであるかについて、さらに情報を運ぶ有用な方法である。メッセージを作成して送信コールに加える要件は、以下に説明される。存在する場合、着信コールテキストメッセージは、着信コールに関連して表示される。ディスプレイ(54)は、複数の着信コールが同時にある場合に、テキストメッセージの表示に対処する。また、テキストメッセージは、着信又は失敗コールログに格納される。

コールパラメータネゴシエーションは、ネットワーク(40)のポリシーパラメータと現在のネットワーク(40)利用内にてコールを確立するのに要するものに制限される。設定により、ユーザは、その他のビデオフォン(15)端末に対してコールの選択を明示できて、例えば、常時ビデオを提供すること、決してビデオを提供しなこと、ビデオを提供することを希望しているか否かを各コールに尋ねることが可能になる。

キャンプオンアベイラブル(Camp on Available)は、他のビデオフォン(15)のユーザへのコールについてサポートされる。これは、ユーザの状態が「空き状態」に変化すると、ユーザにコールを開始する。コールされたユーザがグループである場合、グループの全てのメンバーが「空き状態」である場合にのみ、コールが開始される。

会議コールでは、スピードダイヤル又はディレクトリリストのある場所が人物のグループを示している場合、その各々がコールの参加者となる。この機能を実施するための推奨される処理は、各コールを順番に行い、直ちにそのコールが会議に加えられるべき旨の動作要求確認をするものである。これによって、コールがボイスメールに直行する場合、エスケープルートが与えられる。最初の呼出し側の動作が完了すると、つまり、コール中であるかコールが拒否されると、次の番号が処理される。

半二重である送信コールを、言い換えると、コールされたパーティからオーディオ及び/又はビデオを要求する送信コールを生成できるが、あるタイプのコールではどちらも送信しない。それは、プルモードである。同様に、プッシュモードを生成可能である。プッシュモードでは、送信コールは、オーディオ及び/又はビデオを送るが、如何なるオーディオ又はビデオをも要求できない。このモードは、無人端末に、又は会議にて消極的な役割のみをするユーザの端末に、選択的にコンテンツを配信するために使用されてよい。

スピーカ(64)、ハンドセット及びヘッドセットのボリュームは、全て個別に調節される。スピーカは、オン・オフされる。スピーカをオフにするとマイクロホンがオフにされる。ステータス表示は、スピーカ及びマイクロホンの状態を示す。

マイクロホンは、オフにでき、オンに戻すこともできる。ステータス表示は、マイクロホンのミュートの状態を示す。

カメラは、オフにでき、オンに戻すこともできる。ステータス表示は、カメラのミュートの状態を示す。

インコール制御は、アクティブなコールのみに働く。受け入れられたコールは、アクティブでない場合に、進行中のコールのステータス表示を制御パネルにてタッチするか、特定のインコール制御ファンクション領域を除くコール表示領域の何処かをタッチすることで、アクティブにされる。現在アクティブであるその他のコールは、非アクティブにされる。アクティブなコールは、同じ領域を続いて押すことで非アクティブにされる。制御によって、アクティブなコールは切られる。会議コールでは、それによって、コール状態の全ての要素がクリアされる。

コールは、会議コントロールに受け入れられて、アクティブとされて機能する。会議コントロールをタッチすると、現在のアクティブコール状態を、アクティブにされる次のコールに加える。会議コントロールは、再度押されて非アクティブにされるまで、又は別のコールがアクティブにされるまでの何れかの場合にて、コールがアクティブであることを示す。現在アクティブである全てのコールが会議コール状態に加えられた後、コールは１つの会議コールになり、会議コントロールのアクティブ表示は消える。再度述べると、会議は、他のコールが加えられるコールを選択し、その後、そのコールに加えられるコールを選択する。

会議コールに繋がれたあるパーティを終了する方法は、そのパーティがコールを切ることである。様々な理由から、ユーザは、コール状態の各部分を独立に制御したいと希望するだろう。これは、脱会議(de-conference)能力によって実現できる。例えば、３秒より長くコール状態をタッチすることで、サブメニューが表示される。サブメニューでは、コール状態の個々のメンバーを特定でき、脱会議について選択され得る。このコールは、その後会議から除去されて、別個のコール状態として確立される。それには、通常の全ての制御が適用されて、特にクリア可能である。

転送ファンクションはアクティブコールを転送する。転送コントロールがタッチされると、統合されたダイヤル画面が表示されて、アクティブコールがホールドされる。しかしながら、それはインコール動作に関わっていることが表示されている。転送コントロールは、再度押されて、転送がキャンセルされるまで、又は、ユーザがコールの転送を希望する番号のダイヤルが選択及び押されるまで、コールがアクティブであることを示す。

送信コールが一旦開始されると、転送コントロールは状態の変化を表示し、コントロールがタッチされると、「ブラインド」転送が起こって、コール状態が画面から除かれる。その代わりに、コール先の番号が応答するまで、ユーザは待ってもよく、コール先の番号が応答する時点で、新しいコール状態が生成されて、ユーザはコール先のパーティと会話ができ、転送ファンクションは状態を再度変化させる。そして、それを再度押すことで、両方のコールの転送及び終了が完了する旨が表示される。別の方法では、転送されている呼出側との会話に戻って、転送処理が再スタートされ、又はコールが終了する。転送は主要な機構であり、それによって、「アドミン(admin)」はコールをセットアップし、それを「ボス(boss)」に転送する。この場合、転送されたコールをアドミンが「聞き」続けることが不可能であるのは重要である。これは、安全な環境には特に重要である。

ホールドコントロールをタッチすると、アクティブコールはホールドされる。ホールドでは、送信ビデオ及びオーディオストリームは中断されて、ホールドされている旨の表示が離れた端に与えられる。着信オーディオ及びビデオストリームはもはや表示されない。ホールド状態は、コントロールバー上でコール状態表示上に示される。何らかのコールがホールドされている場合、ホールドコントロールはホールドがアクティブである旨を表示する。アクティブコールがホールドである場合にホールドを再度押すと、ホールドが解除されて、コールは表示された状態に戻る。

メイン制御パネルを制御することで、ホーム画面を立ち上げて、その他の全ての非コールファンクションにアクセス可能となる。メインが選択された表示がされる。メインが再度押されると、現在のコールの表示が再度行われて、メインが選択から外される。受け入れられて表示されたコール内のパーティの各々について、及び表示された各コールについて、分離コントロールが適用される。個々のユーザの各々から送られるオーディオのボリュームを調整することが必要とされる。画面に表示されたオーディオ及び/又はビデオを独立してミュートすることが可能である。ステータスインジケータがあって、オーディオ又はビデオミュートがオンであるか否かを示す。

２以上のコール状態が常に表示できる場合、例えば、２人の他人の会議コールに加えて１人の他人への新たなコールがある場合、完全なコール状態についてオーディオ及び/又はビデオをミュートすることが可能である。例えば、第２コールで話している間に、オーディオについて２つのパーティの会議をミュート可能である。

ビデオをサポート可能なオーディオのみの接続上で、ビデオをリクエストすることが可能である。ビデオリクエストの受け入れ又は拒絶も可能である。接続が合意されるとビデオ接続が確立される、設定ページアイテムによって、ユーザは、ビデオリクエストを常時受け入れ、又は常時拒絶可能である。

各接続について、搬送(bearer)チャンネルパラメータを、つまり、ビデオの着信及び送信エンコードレートを、オーディオもあるならばそのレートを表示できる。コール中では、制御はアクティブコールのみに働く。受け入れられたコールは、アクティブでない場合、アクティブにされる。

どのユーザも「搬送チャンネルクオリティモニタ」を利用可能である。このモニタは、携帯電話の信号強度メータのようなビットであって、例えば、オーディオ及びビデオチャンネル上でエラー又は損失パケットがない場合には、１００％のグリーンバーとなり、損失レート又は待ち時間が所定のレートに達すると黄色のバーとなり、より高いレートに至ると赤いバーとなる。このタイムフレームにおけるエラーがユーザのビデオに影響するので、時間積分は短く、例えば５０ミリ秒とされる。従って、例えば、受信側でビデオのアーチファクトが見られて、同時にモニタバーが黄色又は赤に移動する場合、受信側は、ネットワーク(40)の混雑が生じていることを知る。

コール内で、ビデオエンコードパラメータを変更する、つまりエンコードレート増加又は減少することをリクエストできる。このリクエストを受け入れ又は拒否することが可能であり、送信ビデオレートを変更する方法が与えられる。ビデオフォン(15)は、全ての参加者に対して１つの送信エンコードレートを生じる。それは、受信ストリームの全てにて異なる受信レートを受け入れ可能である。

サイドバーへのリクエストが可能であり、そのリクエストを受け入れ又は拒否することも可能である。受け入れられる場合、サイドバーは両方の参加者から他の全ての者へのオーディオストリームを切る。これによって、彼らはプライベートな会議ができ、その一方で、彼らは、全ての議論を聞き、さらに、全ての参加者を見続け、それらに見られ続ける。ビデオ及びサイドバーリクエストの両方の方法で短いメッセージを送ることができる。

コールが着信コールであるか送信コールであるかに拘わらず、ビデオビューへのスクリーン移行はスムースでなくてはならない。オーディオは、ビデオを予想してよい。この移行がされ得るまで、ビデオは表示されるべきではない。(即ち、ビデオへの移行において、ジャンピ(jumpy)な画像、半分しか形成されていないフレーム等があるべきではない。) ユーザのディスプレイ(54)のビデオ画面への移行は、コールが「進行中」である後にのみ開始し、コールを開始する時点では行われない。ユーザから送られるビデオの表示は、ユーザのディスプレイ(54)に割り当てられた表示領域を最大限利用する。インディスプレイコントロールは、この１つのコール状態の１人のユーザの表示を、フルスクリーン表示に変換する。「フルスクリーン」表示の内の何処かをタッチすると、標準表示に戻る。既に言及したインコールコントロールに加えて、ユーザ名が表示される。ディスプレイ(54)及びコントロールパネルのコール状態は、コールがアクティブか否かを、即ち、インコールの一般的な制御が動作するか否かを示す。あるコール状態が起きていると、そのコール状態を押すことで、又はインコールの特定のコントロール領域から離れたメインディスプレイ(54)上の何処かを押すことで、アクティブがインアクティブとなる。

１つのコール状態であって２つのパーティのコールからの移行はスムースであって、第２コールが「進行中」になると開始される。ディスプレイ(54)は、ユーザのディスプレイ(54)に割り付けられた表示領域を最大限に使用する。必要ならば、ビデオは変倍よりも各縁部をクリップされて、使用領域に合わせられる。フルスクリーン表示を２又は３以上にする要求はない。既に述べたインコントロールに加えて、ユーザ名が各パーティに表示される。両方のパーティが単一のコール状態の部分であることが示される。ディスプレイ(54)及びコントロールパネルのコール状態は、コールがアクティブか否かを示す。パーティがさらにビデオコールに加わるにつれて、着信ビデオは使用領域に合うように、その都度クリップされる。

共に単一パーティコールである２つのコール状態では、これらユーザ各々への２つの別個のコールがあって、双方が表示される。オンスクリーン表示及びコールコントロール表示は、独立した別個の２つのコールがあること、さらに、どれかがアクティブであるか否かとを明確に示す。コールの何れか一方がホールドにされる場合、そのコールはもはや表示されず、ディスプレイ(54)は、単一コール状態の単一コールの表示に戻る。

ユーザ領域には、上記に記載されたものに加えて、以下の組合せの何れかが表示される。
各々が単一パーティのコールである、４つのコール状態。
あるコールが２つのパーティであって、その他が単一パーティのコールである３つのコール状態。
１つのコールが最大で３つのパーティのコールであるか、２つのコールが２つのパーティのコールである、２つのコール状態。

「ＣＮＮ」スタイル表示要求は、上記した単一コール状態の単一コールの要求であって、フルスクリーン表示が可能である。また、画面の半分に「ＣＮＮ」スタイルコールを表示し、残りの半分を１又は２つのユーザ表示領域として使用可能である。後者は、２つの独立したコール状態、又は、パーティが２つである単一のコール状態である。

様々なレベルで音声及びデータの暗号化をすることが可能である。診断、テスト、測定及び管理機構にアクセスすると、ＳＭＦ(simple management framework)が用いられる。言い換えると、アクセスは、３つの方法、ＳＮＭＰ、ウェブ及びクラフト(craft)インターフェイスを通じて、全ての機能を可能にする。ビデオフォン(15)端末は、遠隔管理可能であり、オンサイトのＩＴ専門家が日々の動作を見ることや、ソフトウェアをアップグレートしてバグを修正することは不要である。障害診断も遠隔で可能であって、問題が、ユニットハードウェア、ユニット設定、ユニットソフトウェア、ネットワーク(40)又はネットワーク(40)サービスに関連しているか否かを判断できる。管理では、ＩＰ接続が仮定され得るが、ビデオフォン(15)への比較的低帯域幅での接続である必要がある。

通常動作下では、電源が入れられると、ビデオフォン(15)は、ハードウェアシステム(10)テストを短縮バージョンで行う。これが不合格であると、ビデオフォン(15)は、メインスクリーンにブート失敗メッセージを表示する。端末は、より長いハードウェア診断モードに強制的にされ得る。これは、キーボードをＵＳＰポートに取り付けることで、又は、ユニットの電源を入れてタッチスクリーンの右上隅を押すことでなされる。このモードによって、基本的なオペレーティングシステムとさらに強力な診断にアクセスして、ハードウェアが不合格であるか否かを判断可能となる。

一連の単純なテストを含めることができ、これによって、ビデオフォン(15)がブートアップテストをパスするが正しい機能をユーザに提供していない場合に、ユーザは活動可能である。端末には、ローカルキーボード(及びマウス)について技術的インターフェイスが設けられており、診断ユニット又システム(10)の問題を支援する。これによって、オーディオ及びビデオ等の様々な診断にアクセス可能となる。

遠隔制御下で、ビデオフォン(15)端末のソフトウェアの新たなバージョンを安全にダウンロード可能である。安全については、ダウンロードされたバージョンに不備が起こる場合は、ローカルな介入(即ち、誰かがＣＤを挿入すること)を行うことなく、先のバージョンに戻すことが可能である。特定のビデオフォン(15)端末上のソフトウェアのバージョン番号と、ユニットのハードウェアのシリアル番号と、アセンブリ修正番号と、キーサブアセンブリのシリアル番号及びアセンブリ修正番号とを、管理インターフェイスを通じて読み出しできる。システム(10)がクラッシュした場合、ビデオフォン(15)は、そのクラッシュの診断を支援する情報を格納し、又は情報の格納を完了している。ビデオフォン(15)がリブートされると、この情報は解析のためにリモートサイトからオンラインで回収できる。

ビデオフォン(15)は、電源入力からの全ての動作、イベント及び状態の変化のランニングログを保持する。ログは、記録装置がこの機能に割り当てできる限りにおいて保持される。少なくとも１月分の動作量について格納可能であるべきである。このデータには、多数のカテゴリが含まれており、例えば、安全カテゴリは、ユーザがコールした番号等のユーザデータを含んでおり、ユーザによってのみ公開可能である。コール数、コール状態(即ち、コール状態及び状態当たりのエンドポイントの数)、エンコーダ(36)及びデコーダ(34)の特性、搬送チャンネルエラーレポート等のような一般的なデータは、あまり慎重を期するデータではない。システム(10)レベルの問題を診断し、一連のイベントを生成することを助ける一手段として、キーが押されたことを毎回記録することが可能である。

ビデオフォン(15)は、ＩＰレベル及びＳＩＰレベルの両方で、コントロールプレーンレベルでエクスチェンジを、離れた遠隔端末(ビデオフォン(15)端末に遠隔接続されたラインモニタを有する同等物)にコピーする。端末の管理は、多数のパラメータ、例えばネットワーク(40)のクオリティを、モニタする。閾値を設定して、これらの閾値に到達した場合に警告を発することが可能である。ＡＴＭインターフェイス及びイーサネットインターフェイスの両方は、(例えばｒｍｏｎと同等な)一般的な測定をする。測定は、ビデオフォン(15)で利用される。ビデオフォン(15)は、１又は２以上のネットワークマネージメントシステムに警告を送ることが可能である。

オーディオミキサ
オーディオミキサに関して、第１ノード(80)は、オーディオストリーム及びビデオストリームを作成可能であり、クオリティオブサービス機能を有するＡＴＭネットワークの一部である。第１ノード(80)は、第２ノード(82)とポイントツーポイントコールを構成することを望む。第２ノード(82)は、オーディオ機能のみを有しており、例えば、ＰＳＴＮフォンである。第２ノード(82)は、ＡＴＭネットワークの一部ではない。

ＡＴＭネットワークの一部であるＳＩＰサーバにシグナリング情報を送って、第１ノード(80)は、第２ノード(82)へのコールの構成を開始する。該情報によって、第２ノード(82)が第１ノード(80)が始めているコールの着信先であることが、サーバに確認される。サーバは、第２ノード(82)に関するアドレス情報を有しており、第１ノード(80)から受信したシグナリング情報にアドレス情報を加えて、該シグナリング情報を、第２ノード(82)のアドレス情報と共に、ＡＴＭネットワークの一部であるオーディオミキサ(20)に送る。

第１ノード(80)を出所とするシグナリング情報を受信すると、ミキサ(20)は、この情報から、第１ノード(80)が接続を構成することを望んでいるのは第２ノード(82)であると判断する。そして、ミキサ(20)は、第２ノード(82)に案内(invitation)を送る。ミキサ(20)は、何らかの形で、例えば、Ｔ１ライン又はイーサネットのようなＡＴＭネットワークではない方法で、第２ノード(82)と通信して、その特徴と、データがそれに与えられて該データを理解するために必要な様式とに関して明らかにする。これに応じて、第２ノード(82)は、データが入力されて第２ノード(82)で理解されるのに必要な特定の様式を、ミキサ(20)に明らかにする。また、第２ノード(82)は、それにデータを送ることが可能であり、接続が構成し得ることをミキサ(20)に明らかにする。

その後、ミキサ(20)は、接続を構成する準備ができていることを示す信号を第１ノード(80)に送る。ＡＴＭネットワークの一部であるミキサ(20)は、第１ノード(80)に対して第２ノード(82)を代理し(represent)、第２ノード(82)がＡＴＭネットワークの一部であり、第１ノード(80)と類似しているというインプレッションを、第１ノード(80)に与える。ミキサ(20)は、そのネットワークの一部又は第２ノード(82)が属する接続の一部であって、第２ノード(82)に対して第１ノード(80)を代理している。ミキサ(20)は、第１ノード(80)が同じネットワークの一部又は第２ノード(82)が属する接続の一部であって、第２ノード(82)と類似しているというインプレッションを、第１ノード(80)に与える。

その後、第１ノード(80)は、データのストリーミングを開始する。該データは、オーディオデータを含んでいる。そして、第１ノード(80)は、当該技術分野で周知のように、そのデータのパケットをミキサ(20)にユニキャストする。ミキサ(20)は、パケットを受信すると、当該技術分野で周知のように、パケットのデータをバッファに格納し、第１ノード(80)から送られたパケットに関する接続を効率的にターミネートする。該パケットの送り先は、第２ノード(82)である。ミキサ(20)は、第２ノード(82)に送られた案内を通じて、データが入力されるために必要な様式を以前に知らされているので、第２ノード(82)は、そのデータを理解できる。ミキサ(20)は、バッファに格納されたデータを必要なフォーマットにして、その後、適当な時間制限下で、適切に再フォーマットされたデータを、ミキサ(20)から第１ノード(80)への新しい且つ別個の接続に効率的に送る。この方法では、実際には２つの別個の接続が含まれるが、ポイントツーポイントコールが構成される。第１ノード(80)又は第２ノード(82)の何れも、第１ノード(80)と第２ノード(82)間で所望のポイントツーポイントコールを生成するために、２つの接続が用いられていることを認識しない。同様にして、第２ノード(82)から第１ノード(80)にデータが送られると、処理は繰り返される。しかし、この場合、第２ノード(82)から送られたデータがミキサ(20)で受信された後、ミキサ(20)は、第１ノード(80)が理解可能な様式にデータを再フォーマットする。そして、ミキサ(20)は、該ミキサ(20)にてバッファに格納された、第２ノード(82)から送られたデータを、第１ノード(80)にユニキャストする。ＡＴＭではなくＩＰが用いられる場合、ミキサ(20)は、当該技術分野で周知のように、ユニキャストなＩＰパケットを第１ノード(80)に送る。

次に、別名ポイントツーマルチポイント接続として知られている、会議開催を含むシナリオが、本発明を用いて説明される。ポイントツーポイント接続を含む上述の話の続きとして、第１ノード(80)は、会議を構成する接続に、第３ノード(84)を加えることを希望する。第３ノード(84)は、ＡＴＭネットワークの一部であり、本質的に第１ノード(80)と同じ特徴を有している。第１ノード(80)は、シグナリングの案内を、会議をホストするホストノード(22)に送る。ホストノード(22)は、第１ノード(80)にすることができ、又は、別のノードにすることもできる。第１ノード(80)は、サーバを通じてホストノード(22)と通信して会議を構成し、第３ノード(84)を会議に加える。ホストノード(22)は案内を行って、ミキサ(20)にシグナリングを発するために接続を構成すると共に、第１ノード(80)とミキサ(20)間で最初のシグナリング接続を生成する。なお、該接続は、ターミネートされる。また、ホストノード(22)は案内を行って、第３ノード(84)への接続をも構成する。これは、第３ノード(84)を接続に加える第１ノード(80)からの要求に応じて行われる。ＡＴＭネットワークの一部であるノードが会議に接続されることになる各ケースでは、シグナリングはサーバを通じて進んで、当該技術分野で周知のように、適切にルーティングされる。ホストノード(22)は、ＡＴＭネットワーク内での会議接続用の典型的なホストノードとして働く。ミキサ(20)は、ＡＴＭネットワークの一部ではないが、会議接続全体の一部となるあらゆるノードを代表している。

ＡＴＭネットワーク上の任意のノードについて、接続の一部であるがＡＴＭネットワークの一部ではない如何なるノードも、ミキサ(20)は、あたかもＡＴＭネットワーク上の他のノードであるように現れるようにする。シグナリング接続は、ホストとミキサ(20)間、ミキサ(20)と(ミキサ(20)で代表される)第２ノード(82)間で構成される。それらシグナリング接続を通じて、接続における全てのノードから送られる必須情報は各ノードに送られる。これによって、それらノードは、接続における他の全てのノードを理解して通信することが可能となる。実際には、ホストノード(22)は、他の全てのノードに、これらノードの特徴に関する情報を与えるだけでなく、それらがホストノード(22)に最初に与えた情報をノードに戻す。これにより、各ノードは、基本的に自己の情報を返される。この情報が配布されると、典型的な任意の会議状態における通常のケースのように、ストリーミング情報が出される。ＡＴＭネットワークのシナリオでは、第１ノード(80)及び第３ノード(84)は、ＰＭＰツリーを用いて、パケットの情報を、互いに及びミキサ(20)にＡＴＭマルチキャストするであろう。ＩＰ環境では、第１ノード(80)及び第３ノード(84)は、ネットワーク上の全てのノードにパケットをＩＰマルチキャストし(ミキサ(20)は、このためにノードとなる)、接続の一部であるノードのみ、接続の一部である特定のパケット情報を理解及び使用するであろう。

ミキサ(20)は、上述のように、第１ノード(80)及び第３ノード(84)からパケットを受信して、それらをバッファに格納する。種々のノードから送られるパケットは、ミキサ(20)で受信されると再フォーマットされて、当業者に周知である一般的なアルゴリズムに従ってミキシングされ、言い換えると互いに足し合わされる。その後、所定時間にて、ミキサ(20)で再フォーマットされたデータは、当該技術分野で周知なように、第２ノード(82)に送られる。逆の場合、同様な方法で、第２ノード(82)から送られるデータは、ミキサ(20)で受信されてバッファに格納される。その後、それは、再フォーマット様式で、第１ノード(80)及び第３ノード(84)にマルチキャスト出力される。

第４ノードは、オーディオ機能のみを有しており、第２ノード(82)と類似している。そして、これは、ＡＴＭネットワークの一部ではない。第４ノードが会議に加えられる場合、ホストノード(22)は、ミキサ(20)と第２シグナリング接続を構成する。次に、ミキサ(20)は、第４ノードと別個の接続を構成し、該接続は、ミキサ(20)が第２ノード(82)と構成した接続とは異なる。ミキサ(20)は、それがサポートしているセッションのリストを保持している。対象となっている会議を含むセッションにおいて、それは、ミキサ(20)を介した２つの相互接続(cross connects)を特定する。第１相互接続は、ホストノード(22)から第２ノード(82)へのシグナリング接続を通じたものであり、第２相互接続は、ホストノード(22)から第４ノードへのシグナリング接続を通じたものである。この方法では、ホストノード(22)と同様にして、第１及び第３ノード(80)(84)は、第２ノード(82)及び第４ノードを代理する２つの別個のノードがあり、それらと通信していると信じている。実際には、ミキサ(20)は、第２ノード(82)及び第４ノードの両方を代理し、それらの各々から送られたデータを別々にマルチキャストし、この錯覚に加えて、第２ノード(82)及び第４ノードが第１ノード(80)及び第３ノード(84)と似ているという錯覚が、第１ノード(80)及び第３ノード(84)にて維持される。

ＶｉＰｒシステムは、高度に発達したビデオ会議システムであり、「バーチャルプレゼンス」会議開催特性を与えるものであって、今日市販されている従来の如何なるビデオ会議システムの能力をも遙かに超えている。ＶｉＰｒシステムは、ポイントツーマルチポイントなＳＶＣ(ＰＭＰ−ＳＶＣ)及びＩＰマルチキャストに依拠しており、会議の参加者間でポイントツーマルチポイントなオーディオ/ビデオメディアストリームを確立する。ＶｉＰｒ会議に参加しているユーザが、オーディオ及びビデオの質が今までにない会議を楽しむ間に、ＶｉＰｒを用いていない他のユーザをＶｉＰｒ会議に加える必要がある。システム(10)は、ユニキャストな音声のみのテレフォンコール(即ち、ＰＳＴＮ、モバイルフォン及びＳＩＰフォン)を、複数参加者のＶｉＰｒ会議に加えることを可能にする。

現在のＶｉＰｒシステムは、ＳＩＰベースのアナログ及びデジタル電話ゲートウェイを通じて、電話システムをサポートする。この機能により、ＶｉＰｒのユーザは、電話ユーザにポイントツーポイントコールを行うことができ、電話のユーザからポイントツーポイントコールを受信できる。しかしながら、それらによって、ＶｉＰｒのユーザがテレフォンコールをＶｉＰｒ会議に加えることは可能とはならない。これは、テレフォンコールのユニキャスト特性と、電話ゲートウェイが、テレフォンコールをＰＭＰ/マルチキャストなストリームに変換できないことによる。ＶｉＰｒのユーザが、ユニキャストなテレフォンコールをＶｉＰｒ会議に加えることを可能とすることで、ＶｉＰｒ ＵＡＭは、ＶｉＰｒシステムによる電話のサポートを促進する。

この機能をサポートするために、ＶｉＰｒ ＵＡＭは、ＶｉＰｒ端末と電話ユーザ(即ち、ＰＳＴＮ、モバイルフォン及びＳＩＰフォン)間でシームレスな会議機能を与える。これは、アップストリームのユニキャストなテレフォンオーディオストリームを、ポイントツーマルチポイントのオーディオストリーム(即ち、ＰＭＰ−ＳＶＣ又はＩＰマルチキャスト)に変換すること、ダウンストリームのＰＭＰ/マルチキャストなＶｉＰｒオーディオストリームをユニキャストなテレフォンオーディオストリームにミキシング又は変換することに加えて、ワイドバンドの１６ビット/１６ＫＨｚＰＣＭエンコーディングからＧ.７１１又はＧ.７２２に、ＶｉＰｒオーディオについて、ダウンストリームのオーディオのトランスコーディングをすることによって行われる。

ＵＡＭで与えられるさらなる機能は、インターメディアゲートウェイの機能である。インターメディアゲートウェイは、ＩＰ/ＵＤＰオーディオストリームをＡＴＭ ＳＶＣオーディオストリームに変換し、また、その逆の変換も行う。この機能によって、ＡＴＭ環境に配置されたＶｉＰｒシステムと、イーサネットネットワーク上のＳＩＰベースのボイスオーバーＩＰ(ＶｏＩＰ)電話ゲートウェイとの間で相互運用が可能となる。

ＵＡＭは、１又は２以上のＶｉＰｒフォンが１又は２以上の電話ゲートウェイと共に動作することを可能にする。

ＵＡＭは、下記の構成に示すように、ユニキャストなオーディオデバイスを伴ったＶｉＰｒ会議コールをサポートする。
・タイプ１：１つの会議コールをサポートする。１つのオーディオユニキャストデバイスが参加者である。
・タイプ２：複数の会議コールをサポートする。各会議コールでは、複数のオーディオユニキャストデバイスが参加者であり得る。
・タイプ３：複数の会議コールをサポートする。各会議コールでは、厳密に１つのオーディオユニキャストデバイスが参加者である。

１つのユニキャストマネージャアプリケーションで、２０の参加者(ユニキャストデバイスに加えてＶｉＰｒフォン)がサービスされるのが好ましい。

ユニキャストデバイスは、図１に示す構成にて使用される。

図１に示すように、ユニキャストデバイスとＶｉＰｒでやり取りされる全てのコールは、必ずＵＡＭに送られる。ＵＡＭは、Ｂ２Ｂ ＳＩＰ ＵＡを行ってユニキャストデバイスをＶｉＰｒに接続する。

例： ＰＯＳＴ１のユーザＡは、ＶｉＰｒ Ｖ１のユーザＢにコールする。以下の一連のイベントが起こる。
１． ＵＤ１(メディアトリックス又はあらゆる種類のユニキャストデバイス)は、Ｕｓｅｒ＿Ｂへの接続のリクエストを、Ｕｓｅｒ＿Ａから受信する。
２． ＵＤ１は、ＩＮＶＩＴＥ(案内)をＵＡＭに送る。ＩＮＶＩＴＥ内のＴｏ ｆｉｅｌｄ又はＤｉｓｐｌａｙ Ｎａｍｅは、コールがＵｓｅｒ＿Ｂへのものであることを特定している。
３． ＵＡＭは、着信コールＣ１でＩＮＶＩＴＥを受信する。
４． ＵＡＭは、Ｃ１のＩＮＶＩＴＥからＵｓｅｒ＿Ｂのｓｉｐアドレスを取り出すと共に、ＩＮＶＩＴＥをＶ１に送出して、このユーザへのコールＣ２を開始する。
５． また、ＵＡＭは、Ｃ１をＣ２に相互接続する。
６． Ｖ１は、ＵＡＭから受信するＩＮＶＩＴＥを参照する。それは、ＳＤＰによって、ＶｉＰｒクラスのデバイスであると確認される。つまり、Ｖ１のソフトウェアは、ピア(peer)ソフトウェアに、Ｒｅｐｌａｃｅｓ/Ｒｅｆｅｒｓ等を含むＶｉＰｒデバイスに求められる全ての機能をサポートする能力があることを知る。
７． 例えば、Ｖ１のＵｓｅｒ＿Ｂが、ＯＫ(了承)と共にＩＮＶＩＴＥを返信する。
８． ＵＡＭは、接続Ｃ２がアップされたとマークする。そして、Ｃ１にＯＫを送る。

この例におけるメディアストリームについて説明する。Ｖ１とＵＤ１間のメディアストリームは、以下の方法の何れかで送られる。
１． メディアは、Ｖ１からＵＤ１に直接送られる。これは、ＵＡＭが正しいＳＤＰを書き込んで行われる。つまり、ＩＮＶＩＴＥをＶ１に送る上に、それは、受信用にＵＤ１のＩＰアドレス，ポートを加える。そして、ＯＫをＵＤ１に送る上に、それは、Ｖ１のＩＰアドレス，ポートを受信アドレスとして加える。
２． メディアは、ＵＡＭで中継される。このケースでは、ＵＡＭは、Ｖ１からＵＤ１へのデータを中継し、その逆も行う。ＵＡＭとＶｉＰｒがＡＴＭクラウドを介して通信接続されているならば、その後、Ｖ１とＵＡＭ間のＳＶＣが設定され得ることは容易に理解される。つまり、メディアトラフィックについて、ＵＡＭは、イーサネットゲートウェイに対してＡＴＭとして働く。

例１をさらに続けると、Ｕｓｅｒ＿Ａは、Ｖ２のＵｓｅｒ＿Ｂを会議に加えることを決定する。そして、以下のイベントが生じる。
１． ＵＡＭとＶ１間のＳｉｐ接続は、会議コールＣ３で置き換えられて、Ｖ１、Ｖ２及びＵＡＭが参加者となる。つまり、Ｂ２Ｂ ＵＡは、会議コール(Ｃ３)をユニキャストコール(Ｃ１)と相互接続する。
２． ＵＡＭは、Ｃ３とＣ４間でトラフィックを常に中継する。上述のオプション１１。それは、Ｖ１及びＶ２から送られるトラフィックをミキシングし、それをＵＤ１に中継する。また、それは、ＵＤ１から送られるトラフィックを、Ｖ１及びＶ２にマルチキャストする。

ＵＡＭによって行われる機能は、以下の要素に分けられる。
・ ＳＩＰ Ｂ２Ｂ ＵＡユニット[ＳＢＵ]。このユニットは、Ｂ２Ｂ ＳＩＰ ＵＡを実施するために必要なｓｉｐシグナリングを生成する。
・ メディア相互接続(Media Cross Connect)及びミキサ [ＭＣＭＵ]。

ＵＡＭ機能は、３つの処理、即ち、図２に示す、ＳＢＵ、ユニキャストミキサマネージャ及びＳｉｐスタックで決められる。

Ｓｉｐサーバ(SipServer)プロセスは、Ｓｉｐ機能を実施して、ＳＢＵに、アブストラクテッドシグナリング(abstracted signaling)ＡＰＩ(インターフェイスＩａ)を与え得る。また、インターフェイスＩａは変化しない。

Ｂ２Ｂ ＵＡを実施するために、ＳＢＵは、コール制御及びグルーロジック(glue logic)を実施する。このユニットは、Ｃａｌｌｍａｎａｇｅｒ/Ｖｕｐｐｅｒコードに基づいている。ＳＢＵは、正しいミキサのストリームを設定することも担当する。このために、ＳＢＵは、ＲＰＣを通じてＵＭＭプロセスとインターフェイスする。

ＵＭＭは、メディアストリームを相互接続する機能を実施することに加えて、オーディオミキシング機能を実施する。

Ｂ２Ｂ ＵＡを実施するために、ＳＢＵは、コール制御及びグルーロジックを実施する。ＳＢＵは、正しいミキサのストリームを設定することも担当する。このために、ＳＢＵは、ＲＰＣを通じてＵＭＭプロセスとインターフェイスする。

ＳＢＵユニットは、内部的に以下のように構成される。

図３から理解されるように、ＳＢＵのデザインは、ＣａｌｌＭａｎａｇｅｒから与えられるＳＩＰ/メディアストリームインターフェイスを再利用及び拡張しているので、ＵＡＭについてシグナリングコール制御ロジックが実施される。

以下の記載にて、Ｕｓｅｒ＿ＡがＵｓｅｒ＿Ｂへのコールを開始する場合の制御フローを示す。

以下では、Ｓｉｐサーバは、ＵＡＭのＳｉｐサーバを参照しており、ＳＢＵは、ＵＡＭのＳＢＵに言及し、ＵＭＭは、ＵＡＭのＵＭＭを参照している。

例をさらに明確にするために、以下の事項が仮定される。
− ネットワーク全体は、イーサネットネットワークである。
− Ｖ１のＩＰアドレスは、１７２.１９.６４.１０１である。
− Ｖ２のＩＰアドレスは、１７２.１９.６４.１０１である。
− Ｖ１/Ｖ２クラウドに接続されるＵＡＭのインターフェイスのＩＰアドレスは、１７２.１９.６４.５１であり、ＵＤ１クラウドに接続されるＵＡＭのＩＰインターフェイスは、１６９.１４４.５０.１００である。
− ＵＤ１のＩＰアドレスは、１６９.１４４.５０.４８である。
− アドレスは、＜ＩＰアドレス，ポート＞の組として表される。
− 例における全てのアドレス及びポートは説明用であり、それらは、固定される必要はなく、むしろＯＳによって、割り当てられる。
− 以下の例では、(ＵＡＭの)ＳＢＵで受信される全てのＳＩＰイベントは、実際にＳｉｐサーバで受信されて、その後ＳＢＵに移動させられる。しかしながら、Ｓｉｐサーバがイベントを受信して、それをＳＢＵに移動することは、簡単化のために示されない。

上記の表は、コールの経路で起こる事を説明している。次に、このコールが会議コールに変換される場合における制御フローを示す。この場合、例えば、Ｕｓｅｒ＿Ｂは、Ｖ２のＵｓｅｒ＿Ｃをコールに加えて会議をする。

さらに、下記の事項が仮定される。
− Ｖ２のＩＰアドレスは、１７１.１９.６４.１０２である。

別のＶｉＰｒのユーザを会議に加えるために、ステップ１２から１８が繰り返される。別のユニキャストデバイスのユーザ、即ちＰＯＴＳ２のＵｓｅｒ＿Ｄに必要なステップを説明する。

以下の事項を仮定する。
− ＶｉＰｒ Ｖ２のＵｓｅｒ＿Ｃは、ＰＯＴＳ２上のＵｓｅｒ＿Ｄを会議に加えることを決断する。

ＵＭＭは、メディアストリームを相互接続する機能に加えて、オーディオミキシング機能を実施する。

展開シナリオ １：
図４を参照すると、このシナリオは、２つのケースをカバーしている。

複数参加者のＶｉＰｒオーディオ/ビデオ会議におけるＶｉＰｒユーザは、ユニキャストなオーディオのみの電話ユーザを会議に加える。

このケースでは、複数参加者のＶｉＰｒ会議におけるＶｉＰｒユーザは、ユニキャストな電話ユーザを会議に加える決定をする。その結果、参加者の１人が、着信先の電話番号にコールを開始する。ＶｉＰｒ ＳＩＰサーバは、そのコールの着信先をＶｉＰｒ ＵＡＭに変更する。ＶｉＰｒ ＵＡＭは、ＶｉＰｒのオーディオのみのコールをターミネートし、電話ゲートウェイを通じて、着信先の電話へのバックツーバックコールを確立する。

コールが確立されると、ＶｉＰｒ ＵＡＭは、電話から受信したＧ.７１１/Ｇ.７２２オーディオストリームを、ＰＭＰ/マルチキャストストリームに変換し、トランスコーディングすることなく、それをＶｉＰｒ端末に転送する。他方で、ＶｉＰｒ ＵＡＭは、種々のＶｉＰｒ端末から受信したワイドバンドの１６ｂｉｔ/１６ＫＨｚＰＣＭ ＶｉＰｒ オーディオストリームを、Ｇ.７１１又はＧ.７２２である１つのユニキャストなオーディオストリームにトランスコーディング及びミキシングして、それを電話の着信先に転送する。

電話ユーザを含んでおり、ポイントツーポイントなオーディオのみの会議において、ＶｉＰｒユーザは、別のＶｉＰｒユーザを会議に加える。

このケースでは、電話ユーザ(Ｔ)を含むポイントツーポイントなオーディオのみのコールにおけるＶｉＰｒユーザ(Ｖ１)は、別のＶｉＰｒユーザ(Ｖ２)を会議に加えることを決定する。その結果、ＶｉＰｒユーザＶ１は、着信先のＶｉＰｒユーザＶ２にオーディオ/ビデオコールを開始する。ＶｉＰｒシステムは、Ｖ１及びＶｉＰｒ ＵＡＭで確立されたポイントツーポイントコールを切って、Ｖ１、Ｖ２及びＶｉＰｒ ＵＡＭ間のＰＭＰ/マルチキャストコールを再確立する。

ＶｉＰｒ ＵＡＭは、新たなＶｉＰｒオーディオ/ビデオコールをターミネートし、それを、すでに確立されたバックツーバックテレフォンコールにブリッジする。このプロセスを通じて、テレフォンコールはアクティブなままであって、スイッチングは、電話ユーザに認識されない。

コールが確立されると、ＶｉＰｒ ＵＡＭは、電話から受信したユニキャストなＧ.７１１/Ｇ.７２２オーディオストリームを、ＰＭＰ/マルチキャストストリームに変換し、トランスコーディングすることなく、それをＶｉＰｒ端末に転送する。他方で、ＶｉＰｒ ＵＡＭは、種々のＶｉＰｒ端末から受信したワイドバンドの１６ｂｉｔ/１６ＫＨｚＰＣＭ ＶｉＰｒオーディオストリームを、Ｇ.７１１又はＧ.７２２である１つのユニキャストなオーディオストリームにトランスコーディング及びミキシングし、それを電話の着信先に転送する。

ＶｉＰｒは、マルチストリームのマルチメディアセッションを確立し、修正し消去する手段として、セッション開始プロトコル(ＳＩＰ)を用いる。ＵＡＭは、ＶｉＰｒ端末及び電話ユーザ(即ち、ＰＳＴＮ、モバイルフォン及びＳＩＰフォン)間の会議能力を与える。これは、アップストリームのユニキャストな音声のみのテレフォンストリームを、ポイントツーマルチポイントストリーム(即ち、ＰＭＰ−ＳＶＣ又はＩＰマルチキャスト)に変換すること、ダウンストリームのＶｉＰｒのマルチキャスト/ＰＭＰオーディオストリームを、ユニキャストな音声のみのテレフォンストリームに変換することに加えて、ワイドバンドの１６ｂｉｔ/１６ＫＨｚＰＣＭエンコーディングからＧ.７１１又はＧ.７２２に、ＶｉＰｒオーディオについて、ダウンストリームのオーディオのトランスコーディングをすることによって行われる。

展開シナリオ ２：
図５を参照すると、このシナリオは、２つのケースをカバーしている。

電話ユーザは、ＶｉＰｒユーザにコールする。

このケースでは、電話ユーザは、ＶｉＰｒユーザに向けてコール(オーディオのみ)を開始する。電話ゲートウェイは、そのコールの着信先をＶｉＰｒ ＵＡＭに変更する。ＶｉＰｒ ＵＡＭは、テレフォンコールをターミネートし、着信先のＶｉＰｒ端末へのバックツーバックなＶｉＰｒのオーディオのみのコールを確立する。

コールが確立されると、ＶｉＰｒ ＵＡＭは、電話から受信したＧ.７１１/Ｇ.７２２オーディオストリームを、トランスコーディングすることなくＶｉＰｒ端末に転送する。他方で、ＶｉＰｒ ＵＡＭは、ワイドバンドの１６ｂｉｔ/１６ＫＨｚＰＣＭからＧ.７１１又はＧ.７２２に、ＶｉＰｒのオーディオストリームのトランスコーディングを行い、それを電話の着信先に転送する。

ＶｉＰｒユーザは、電話ユーザにコールする。

この場合、ＶｉＰｒユーザは、電話ユーザにコールを開始する。ＶｉＰｒ ＳＩＰサーバは、そのコールの着信先をＶｉＰｒ ＵＡＭに変更する。ＶｉＰｒ ＵＡＭは、ＶｉＰｒのオーディオのみのコールをターミネートし、電話ゲートウェイを用いて、着信先の電話へのバックツーバックなＰＳＴＮコールを確立する。前の段落と同様な方法で、トランスコーディングが行われる。

図６は、ＵＡＭの典型的な使用状況を示す。ＵＡＭで与えられる特徴を、以下に示す。

(特徴１)
例えば、ＶｉＰｒ Ｖ１及びＶ２は、ポイントツーポイントコールに含まれており、それらは、ユニキャストデバイスＵＤ１を、会議コールに加えることを希望する。言い換えると、目的は、ＵＤ１、Ｖ１及びＶ２が会議にいる会議コールを構成することである。例えば、Ｖ１のユーザは、ＵＤ１のユーザが、他の参加者としてＶ１及びＶ２を含む会議コールに加えられるようにリクエストする。このリクエストは、ＳＩＰサーバの１つによって、ＵＡＭに転送される。

その後、ＵＡＭは、以下の動作を行う。
− ＵＤ１を代理して、会議コールに加わる。この会議コールＣ１をコールする。
− また、ユニキャストデバイスを含むポイントツーポイントコールを作成する。この会議コールＣ２をコールする。
− Ｃ２で受信したオーディオデータをＣ１に中継する。
− コールＣ２の参加者Ｖ１及びＶ２からオーディオデータを受け取って、このデータをミキシングしてＵＤに転送する。

(特徴２)
上述の図のｖｉｐｒネットがＡＴＭであり、ＵＤネットがＩＰネットワークであるケースを考える。また、可能な範囲内で、ＡＴＭネットワークに亘って、オーディオについて、ＬＡＮＥ/ＣＬＩＰではなく、ＳＶＣのみが使用されることが望ましいと仮定される。これにより、セキュリティ上の問題又はパフォーマンス上の問題に対処可能となる。

このケースでは、ｖｉｐｒネット上のＶｉＰｒ Ｖ１が、音声会話にユニキャストデバイス(ＵＤ１)を加えることを希望する場合、ＵＡＭが用いられて、ＡＴＭネットワークにてＳＶＣを、ＩＰネットワークにてＩＰを使用する機能が与えられる。

これを行うためには、Ｖ１からＵＤ１への全てのコールは、Ｖ１からＵＡＭＤへのコールと、ＵＡＭＤからＶ２へのコールとに分けられる。

ＵＡＭでサポートされる特徴に要求される設定は、以下のカテゴリに分けられる。
− ＶｉＰｒからＵＤへのコールの設定
− ＵＤからＶｉＰｒへのコールの設定
− 一般的な設定

(一般的な設定)
Ｂ２ＢＵＡ ＳＩＰ ＵＡは、所望の任意のポート(５０６０以外)で動くようにされる。これは、以下のパラメータを含むように、ｖｉｐｒ．ｉｎｉファイルを修正することで行われる。
SIP_Port = 7070 [任意の有効なポート番号]

(ＶｉＰｒからＵＤへのコールの設定)
典型的なＶｉＰｒコールでは、ユーザが「番号」をダイヤルすると、その「コールリクエスト」は、ＳＩＰサーバに送られる。ＳＩＰサーバは、それを適切な着信先に転送する。しかしながら、このケースは異なっている。このケースでは、ユーザが、自分がユニキャストデバイス(ＵＤ１)と話をしたいと希望していると言うと、ＳＩＰサーバはＵＡＭにそのリクエストを転送する。さらに、それは、このコールがＵＤ１に転送されるべき旨を特定する情報を、そのリクエストに加える。つまり、ＳＩＰサーバは、ＵＡＭデバイスでサービスされるＳＩＰ−ＵＲＩに作られたコールを、適切なＵＡＭＤサーバにルーティングするようにプログラムされる。

また、ＵＡＭで受信された全てのコールを転送するために、デフォルトのユニキャストデバイスのＳＩＰアドレスを指定することが可能である。このデフォルトアドレスは、ｖｉｐｒ．ｉｎｉファイルに、以下の行を加えることで指定される。
UD_SERVER_ADDRESS = 169.144.50.48
X_FORWARD_AVAILABLE = 0

ユニキャストデバイスからＶｉＰｒにコールがなされる場合、そのコールは、ＵＡＭに送られなければならないことに留意すべきである。これを行うために、適切な設定がユニキャストデバイスで行われる。これに関しては、ユニキャストデバイスの使用書を参照のこと。

(ＵＤからＶｉＰｒへのコールの設定)
ＶｉＰｒへのコールは、ＵＤで開始されて、ＵＡＭにルーティングされる。これを達成する一つの方法は、ＵＤをプログラムして、全てのコールをＵＡＭに導くこと又は転送することである。最終的なコールの着信先(例えば、Ｖ１)は、ＵＡＭへのコールリクエスト内で指定される。通常、このアドレスは、ＳＩＰメッセージ内のＴｏ ｆｉｅｌｄであろう。これらの設定は、ＵＤ又はＳＩＰサーバで行われる。

さらに、ＵＡＭがＵＤからコールリクエストを受信する場合、ＵＡＭは、それを、コールされた参加者の健全さをチェックするゲートウェイマーシャル(Marshall)サーバに転送する。このゲートウェイアドレスは、以下のように、ｖｉｐｒ．ｉｎｉファイルで指定できる。
GatewayMarshallServer = sip.eng.fore.com:5065

略語のリスト
ＡＴＭ (Asynchronous Transfer Mode) 非同期転送ノード
ＩＳＤＮ (Integrated Services Digital Network) 総合サービスデジタルネットワーク
ＩＰ (Internet Protocol) インターネットプロトコル
ＬＡＮ (Local Area Network) ローカルエリアネットワーク
ＭＣ (Mulicast) マルチキャスト(ＩＰ)
ＭＣＭＵ (Media Cross Connect and Mixer) メディア相互接続及びミキサ
ＭＣＵ (Media Conferencing Unit) メディア会議ユニット
ＰＢＸ (Private Branch Exchange) プライベートブランチエクスチェンジ(構内電話交換機)
ＰＣＭ (Pulse-Code Modulation) パルス符号変調
ＰＭＰ (Point-to-Multipoint) ポイントツーマルチポイント(ＡＴＭ)
ＰＯＴＳ ("Plain Old Telephone") 「一般的な電話システム」
ＰＲＩ (Primary Rate Interface) １次群インターフェース
ＰＳＴＮ (Public Switched Telephone Network) 公衆交換電話網
ＳＢＵ (SIP back-to-back user agent) ＳＩＰバックツーバックユーザエージェント
ＳＩＰ (Session Initiation Protocol) セクション開始プロトコル
ＳＶＣ (Switched Virtual Circuit) 交換接続型仮想回路
ＵＡＭ (Unicast Audio Mixer) ユニキャストオーディオミキサ
ＶｉＰｒ^TM (Virtual Presence System) バーチャルプレゼンスシステム
ＷＡＮ (Wide Area Network) 広域通信網

例示を目的として、上述の実施例について、本発明が詳細に説明されたが、このような詳細は、単に説明を目的としており、当該技術分野における通常の知識を有する者であれば、特許請求の範囲に記載される場合を除き、発明の精神と範囲から逸脱することなく、変形ができることは理解できるであろう。

添付の図面では、本発明の好ましい実施例と、本発明を行う好ましい方法とが図示されている。
図１は、本発明のシステムの概要図である。 図２は、本発明のネットワークの概要図である。 図３は、ＰＣ及びネットワークに接続されたビデオフォンの概要図である。 図４は、本発明のシステムの概要図である。 図５ａ及び図５ｂは、夫々、ビデオフォンの正面及び側面の概要図である。 図６は、ビデオフォンの接続パネルの概要図である。 図７は、ビデオフォンのマルチスクリーン構成の概要図である。 図８ａは、ビデオフォンのブロック図である。 図８ｂは、ビデオフォンのブロック図である。 図８ｃは、ビデオフォンのブロック図である。 図９は、ビデオフォンアーキテクチャのブロック図である。 図１０は、システムの概要図である。 図１１は、システムの概要図である。 図１２は、本発明のシステムの概要図である。 図１３は、本発明のもう１つのシステムの概要図である。 図１４は、本発明のオーディオミキサの概要図である。 図１５は、ミキサのアーキテクチャのブロック図である。 図１６は、ＳＢＵのブロック図である。 図１７は、ビデオフォン会議におけるビデオフォンＵＡＭの概要図である。 図１８は、双方向の電話コールにおけるビデオフォンＵＡＭの概要図である。 図１９は、ミキサ用のネットワークの概要図である。 図２０は、本発明のブロック図である。 図２１は、幾つかのノードを示した本発明のブロック図である。 図２２は、本発明のブロック図である。

Claims (3)

1. ネットワークと、
   互いに通信して、各ノードのライブシーンの会議を構成する複数のノードとを備えており、
   各ノードは、ディスプレイレイアウトを有するビデオディスプレイを有しており、
   各ノードには、会議におけるその他のノードの各々から送られるビデオストリームが与えられ、
   複数のノードの少なくとも１つは、各ノードに固有であり得る特定のディスプレイレイアウトフォーマットで、会議の各ノードのディスプレイレイアウトを個々に、少なくとも部分的に制御し、
   各ノードは、複数のノードの少なくとも１つによって、前記特定のディスプレイレイアウトフォーマットに固定され、
   各ノードは、前記複数のノードの少なくとも１つによって、ディスプレイの特定の場所に、会議のその他のノードから送られる幾つかのビデオストリームを、前記特定のディスプレイレイアウトフォーマットで表示するように強制される電話会議システム。
2. 各ノードは、複数のノードの１つによって制御されないスクリーンの任意の部分に表示されるものを制御する、請求項１に記載のシステム。
3. 複数のノードの１つは、各ノードのディスプレイレイアウトを全体的に制御する、請求項２に記載のシステム。

Images