添付の図面を参照すると、幾つかの図面を通して、同じ参照符号が類似又は同様な部分を指している。特に図20を参照すると、電話会議システム(10)が示されている。システム(10)は、ネットワーク(40)を備えている。システム(10)は、端末又はビデオフォンのような複数のノードを備えており、それらノードは、ネットワーク(40)を通じて互いに通信する。端末は、ライブトークのオーディオストリームを互いに送信して、会議が構成される。各端末は、オーバーロード状態を検出できる。オーバーロード状態では、端末によって送信されて同時に存在するライブトークのオーディオストリームが、所定数を超えている。各端末は、その他の端末と共に、同時に送信されているオーディオストリームの数を制御して、オーバーロード状態を終わらせる。
好ましくは、各端末は、自己が送信するオーディオストリームとその他の端末が送信するオーディオストリームとに基づいてオーバーロード状態が検知されると、自己のオーディオストリームの送信を停止すべきか否かを決定する。各端末は、ネットワーク(40)からの同期メッセージを全く用いることなく、オーバーロード状態について、その他の端末から独立に同じ決定に達する。
本発明は、電話会議をする方法に関する。その方法は、複数の端末が、ネットワーク(40)を介して互いに通信するステップを含む。端末は、ライブトークのオーディオストリームを互いに送信し、会議が構成される。各端末でオーバーロード状態を検出するステップがある。オーバーロード状態では、端末によって送信されて同時に存在するライブトークのオーディオストリームが、所定数を超えている。同時に送信されているオーディオストリームの数を制御して、オーバーロード状態を終わらせるステップがある。
制御ステップは、各端末で、同時に送信されているオーディオストリームの数と、オーバーロード状態とを制御するステップを含むのが好ましい。制御ステップは、各端末が、自己が送信するオーディオストリームとその他の端末が送信するオーディオストリームとに基づいてオーバーロード状態が検知されると、自己のオーディオストリームの送信を停止すべきか否かを決定するステップを含むのが好ましい。制御ステップは、各端末が、ネットワーク(40)からの同期メッセージを全く用いることなく、オーバーロード状態について、その他の端末から独立に同じ決定に達するステップを含むのが好ましい。
本発明の方法は、ライブトークの最も新しいオーディオストリームを送信するノードが、それらのオーディオストリームの送信を継続することを許可するステップを含むのが好ましい。好ましくは、許可ステップは、各ノードのスコアを得るステップを含み、最も高いスコアを有するノードが送信を継続する。スコアを得るステップは、各パーティに関する過去の60秒内のオーディオパケットの数を用いて、スコアを決定するステップを含むのが好ましい。
本発明は、その他のノードを伴うネットワーク(40)用の電話会議ノード(12)に関する。ノードは、ネットワーク(40)インターフェイスを備えており、そのインターフェイスは、その他のノードと通信して、ライブトークの会議が構成される。ノードは、オーバーロード状態を検出するコントローラ(10)を備えている。オーバーロード状態では、ノードによって送信されて同時に存在するライブトークのオーディオストリームが、所定数を超えている。ノードは、その他のノードと共に、同時に送信されているオーディオストリームの数を制御して、オーバーロード状態を終わらせる。好ましくは、ノードは、ライブトークを受信するオーディオレシーバ(58)と、ノードにおけるライブ画像をキャプチャする撮像デバイスと、その他のノードから受信したオーディオストリームを再生するスピーカ(64)とを含んでいる。
好ましい実施例の動作において、大規模のライブ会議の参加者の最大数は、15パーティの会議にはないオーディオ処理問題をもたらす。100パーティの会議における議論は管理されているが、全ての遠隔地は、アンミュートされており、いつでも音声を送信できると仮定する。メインの話し手は、各人が応答するコメントして、100−300msの非常に短い時間に、各エンドポイントはオーディオデータを送り始め、「オーディオパケットストーム」が起こる。このようなストームの会議への影響は、受信ノイズレベルの増加であり、全ての条件が同じとして、音声出力が20dBジャンプするであろう。エンドポイントは、1秒当たり、5000個のオーディオRTPパケットを処理している。エンドポイントを会議のその他のエンドポイントに接続する低帯域幅のリンクは、8Mbpsのオーディオデータストリームに耐えなければならないだろう。(注:8Mbpsなる数は、各ViPr端末がオーディオデータを64kbpsで送信し、RTPオーバーヘッドが4.8kbpsで、IPオーバーヘッドが約4kbpsであるとして得られる。)
検出では、受信するオーディオパケットのレートが閾値と比較される。各エンドポイントは、ストームが存在しているか否かと、オーディオデータの送信又はセルフミュートを継続すべきか否かとを、独立に決定する。エンドポイントは共通スレッドを共有しており、各エンドポイントは互いのオーディオデータを受信することから、他のエンドポイントのトークのアクティビティ統計を推定できる。
シミュレーションにより、送信されているオーディオチャンネルの数が、通常は300ms未満である短い時間に限界に達することを予想できる。この理由は、ネットワーク(40)には遅延があり、任意のエンドポイントがストームを検出できる時間に影響を与えるからである。遅延が50msである場合、エンドポイントがストームを検出し終える前に、3つまでのパケットがルートにあり得る。また、各エンドポイントは、セルフミュートすべきか否かを決定しなければならない。各エンドポイントがストームを検出して、それを如何に軽減するかを決定する時点の違いによる典型的な統計変動があると、ミュートされるエンドポイントは予想よりも増減するであろう。不十分な数のエンドポイントがストームを抑制するためにミュートすると、幾つかのエンドポイントは、少し遅れてミュートするだろう。このプロセスでは、チャンネルのランダムネス(randomness)又はジッタに加えて、エンドポイントがストーム検出と軽減プロセスを開始する時点の違いにより誘起されるランダムネスがある。
所定の時間間隔内に受信したオーディオパケットの数が検出閾値を超えると、ストームが検出される(又は、宣言される)。
オーディオストーム検出及びその軽減
自己保護モード:オーディオプロセスが最も優先されることから、目的は、オーディオストームがViPr端末を渋滞させるのを防止することにある。オーディオクオリティ保護モードがアクティブではなく、超過した数のオーディオパケットが送られる場合にのみ呼び出される。このモードはまた、サービス拒絶攻撃(denial of service attacks)を防止する。
着信パケットは、比較的短い時間周期(100−200ms)に渡ってカウントされ、閾値が超えられると、さらなる受信パケットは全て、その時間周期の間に廃棄される。
オーディオクオリティ保護モード:目的は、オーディオパケットの送信を制限して、ネットワーク(40)のオーバーロードを防止し、リモート端末の各々におけるノイズと音声音量の超過を防止する。
1.全ての端末は、そこの端末を含む全てのオーディオストリームの統計を集める。
2.全ての端末は、実際にデータを送っている着信チャンネルの数を検知して、オーディオストームの開始(onsets)を独立して検出する。
3.各端末は、それらのローカルなオーディオ送信とリモート端末からのオーディオ送信のスコアに基づいて、オーディオストリームの送信を停止するか否かを独立に決定する。
ViPrのオーディオストームの検出及び軽減に関する新規で主要な特徴
各端末は、オーディオデータの送信をするか否かの決定において、他の端末から完全に自立している。
全ての端末が、各チャンネルについて同じ統計を近似的に計算することで、全ての端末の決定プロセスが互いに繋げられる。
以下では、基本的に、「オーディオストーム検出・回復」デバイスを以下に構築するかについて説明する。
会議コールの各パーティは、ライブトークのオーディオパケットを、コールのその他のパーティの全てに、決まった間隔で送る。ネットワーク(40)とプロセッサの負荷を制限する第1の方法は、各パーティが、無言(silence)の期間中にこれらのオーディオパケットを送ることを停止することである。典型的なコールでは、数パーティのみが一度に話し、他のパーティの全ては、「無言」モードにあるだろう。故に、各パーティは、それら数パーティからパケットを実際に受信しているだけであろう。新しいパーティが問い掛けに応答すると、音声アクティビティ検出ロジックは、そのエンドポイントからのオーディオパケットの送信を可能とする。同様に、パーティが話すのを止めると、音声アクティビティ検出ロジックは、もう一度「無言」モードになって、パケットのフローを停止させる。
大規模な同時の音声応答を生じる状況が起こるといつでも、各パーティは、「無言モード」を出て、パケット送信を開始するだろう。多くのオーディオストリームが、同時にアクティブになると、各エンドポイントでなされるオーディオミキシング機能は、プロセッサの集中を増すだろう。また、ネットワーク(40)の負荷が顕著に増加する。これは、「オーディオストーム」と呼ばれる状態であって、以下の説明で、オーディオストームを検出及び停止するデザインについて詳細を述べる。
各パーティは、着信したオーディオパケットをリアルタイムで処理しており、オーディオストームの間、ネットワーク(40)のトラヒックは、既に大きく増加している。故に、各パーティ間で信号をやり取りして、オーディオストーム情報を交換する第2のネットワーク(40)を用いるための容易な方法はない。これは、各エンドポイントに、独立してオーディオストームを検出することを要求する。これはまた、コールの各エンドポイントが、自己を含むコールの各パーティについて、短期のオーディオパケット履歴を自分で保持することを要求する。
オーディオストームの最初の検知は、比較的容易である。パーティが、少なくとも「nStormThreshold」の数のパーティからオーディオデータを実際に受信する時はいつでも、オーディオストームが単に宣言される。厄介なのは、このストームを如何に制御するかを決定することである。理想的な状況では、ストームの前に話していた1又は複数の同じパーティが、そのまま聴かれるべきである。さらに、各パーティは、さらなる多数のパーティを聴くことがそのまま可能であって、彼らの反応も同じように聴けるべきである。
各パーティから入ってきた過去のオーディオパケットの履歴が用いられて、「スコア」が生成される。その後、スコアは、どのパーティが最も新しい話し手であったかを決定する。リストの先頭部の「nSimultaneousTalkers」の数のパーティが、その後使用されて、オーディオストームが検出された後に送信を継続する選ばれた僅かのパーティを決定する。エンドポイントの全てが、オーディオパケットに関する正確に同じ履歴を保持しているから、それらは、常に、正確に同じスコアリストを有しているはずである。特定のエンドポイントがリストの先頭部内にあると、それは、送信を継続しなければならない。さもなければ、それは、直ちに送信を停止しなければならない。そのほか、このリストは、音声再生のためにどのパーティがデコード及びミックスされるかを制限するのに使用される。オーディオストームの影響は弱くなり、リストの先頭部の僅かのパーティのみが、送信を継続し、引き続き聴取される。
残ってる最後の事項は、オーディオストームが終わって、通常の会議動作が再開されるまで待つことである。正確に「nSimultaneousTalkers」の数のパーティが最初に送信するだろうから、オーディオストームが終わったと宣言される前に、パーティの数が「nSimultaneousTalkers」よりも少なくなるまで待つ必要がある。
典型的なスコアリングアルゴリズムは、各パーティについて、過去60秒内のオーディオパケットのカウントを用いることである。そして、このカウントは、従前の500ミリ秒の間隔毎に、100でインクリメントされる。この間隔では、少なくとも1つのパケットがこのパーティから受信されている。これは、最初の500ミリ秒の間隔に如何なるパケットも含まれないまで、60秒の履歴の各パーティについて継続する。このスコアリング方法は、最も新しい話し手を最初に指向し、それから、過去60秒内に何かを言ったパーティを指向する。
さらに複雑なその他のスコアリング手法が使用できる。例えば、「キープレゼンター」のようなあるパーティを手動で特定することで、リストの先頭部にあり、それ故に常に発言しているパーティが常時スコアされる。
オーディオストームに提案されるソリューションは、端末が独立に働いて、オーディオストームを検出及び軽減しなればならないことを仮定する。検出では、受信したオーディオパケットのレートが閾値と比較される。各端末は、ストームが存在しているか否かと、オーディオデータの送信又はセルフミュートを継続すべきか否かとを、独立に決定する。ViPr端末は共通スレッドを共有しており、各端末は互いのオーディオデータを受信するので、その他の端末のトークのアクティビティ統計を推定できる。
シミュレーションによって、送信されているオーディオチャンネルの数が、通常は300ms未満である短い時間に限界に達することを予想できる。この理由は、ネットワーク(40)には遅延があり、任意の端末がストームを検出できる時間に影響を与えるからである。遅延が50msである場合、端末がストームを検出し終える前に、3つまでのパケットがルートにあり得る。また、各端末は、セルフミュートすべきか否かを決定しなければならない。各端末がストームを検出して、それを如何に軽減するかを決定する時点の違いによる典型的な統計変動があると、ミュートされる端末は予想よりも増減するであろう。ストームを抑制するために不十分な数の端末がミュートすると、幾つかの端末は、少し遅れてミュートするだろう。このプロセスでは、チャンネルのランダムネス又はジッタに加えて、端末がストーム検出を開始する時点の違いにより誘起されるランダムネスがある。
オーディオパケットストームのクロノロジ(chronology)
50の参加者がいる大規模な会議が進行しているとする。1又は2以上の参加者が実際に話しており、残りの参加者は聴いている。おもしろい発言があって、突然、50+の参加者が笑い始める。各ViPr端末では、VADアルゴリズムは、マイク音声レベルの増加を検知し始め、60msの間これが続くと、4又は5のパケットのバーストが送られる。パケットは、20msのインターバルで送られる。バーストを受信した端末は、それを使用して、ジッタバッファをプレロードし、受信音声を再生し始める。笑っている者が落ち着くと、VADが無言を検知して、パケットを止める前に2秒の計測を開始する。
リモートミュートが使用されて議論が管理された(moderated)会議は、モデレータ(moderator)が参加者に発言権を与える点で負担が少ない。発言権を与えられたそれらの参加者のみが、オーディオパケットを送ることができる。
パケット送信アルゴリズム
以下の条件が真である場合、パケットが送信される。
VADアルゴリズムがスピーチを検出している。
及び
管理された会議で、モデレータがこの参加者をアンミュートした。
又は
管理されてない(unmoderated)会議で、以下が真である。
オーディオパケットストームが検出されない。
又は
オーディオストームが検出され、
参加者が重要な話し手である。
又は
送信された時間が最後のオーディオデータに基づく参加者のランキングが 、その他の参加者の各々から受信した最後のオーディオデータと比較され た。
オーディオパケットストーム検出
所定の時間間隔内に受信したオーディオパケットの数が検出閾値を超えると、ストームが検出(又は宣言)される。アルゴリズムは以下の通り。
パケットが受信されるごとに、グローバル変数g_nPktsRcvdがインクリメントされる。
100ms毎に、
オーディオストームが検出されていない場合、
g_nPktsRcvd > m_nPktsStormDeclaredならば、bStorm Detectedが真にセットされる。
オーディオストームが検出されている場合、
g_nPktsRcvd < m_nPktsStormOverならば、bStorm Detectedが疑にセットされる。
g_nPktsRcvdが0に設定される。
話し手のアクティビティ測定
話しのアクティビティは、2つの方法の一方で測定される。第1の方法は、通常は1分の間隔に渡って、話しに費やされる時間の割合を計算する。これは、ローカルな話し手のみについて計算され、以下のアルゴリズムを用いる。
循環バッファ(circular buffer)TT_localを全てゼロに初期化して、インデックスindxTTをゼロに初期化する。
2秒毎に、そしてオーディオパケットストームが検出されていないと、
ローカルな参加者が話している場合に、TT_local[indxTT]に1を設定し、その他の場合には0を設定する。indxTTをインクリメントする。
アレイサイズで割られたTT_localアレイの1の数が、話し時間の割合である。2秒のサンプリング間隔は、VADが2秒の最小オンタイムを有することに基づいている。TT_localアレイは、最後の瞬間もサンプリングするようにサイズが決められている。話が、最後の瞬間の25%について検出された場合、ローカルな話し手は、重要として分類される。
話しのアクティビティを測定する第2の方法は、パケットが受信又は送信された最後の時間を用いる。パケットストームの発生を考えると、最後のパケットの到着時間を単に用いることは、有益な結果を与えないであろう。より関心があるのは、現在のオーディオパケットストームが始まる前に、オーディオパケットが送られた最後の時間である。以下のアルゴリズムは、パケット到着時間を追跡記録する(track)。
PktRcvTime > PktRcvTimeLast+1秒である場合、
最後のパケットが現在のオーディオパケットストームの前に受信され、PktRc vTimeLastがPktRcvTimeLast1にコピーされる。
PktRcvTimeLast=PktRcvTime
同じアルゴリズムがオーディオパケットの送信に使用されるが、PktXmtTimeがPktRcvTimeに置き換わる。
実装
AudioManでは、EncoderRdy()が、AudioMan.cppのencoder_decorder_loop()に真を返すと、アクセス関数SetTalkTimeLast()が呼び出される。EncoderRdyのリターンステートは、VADで制御される。SetXmtTimeLast()は、AudioStrom.cppにある。
2秒ごとに、UpdateTalkerActivity()は、AudioMan.cppのencoder_decorder_loopで呼び出される。UpdateTalkerActivity()は、VADの話し状態eVADstateを調べて、アクセス関数IsTalking()を用いて、ローカルな参加者が話し中であるか否かを判断する。話しが検出されると、「1」が循環バッファ、TT_localへロードされる。
パケットが受信される毎に、関数SetRecTimeLast(iChannel)が呼び出される。関数SetRecTimeLast(iChannel)を用いて、そのチャンネルについて、最後に受信したパケットの時間が記録され、オーディオパケットストームを検出するための受信パケットの数、nPktsRcvStormがインクリメントされる。
100msごとに、StormDetect()は、nPktRcvStormを用いて、パケットストームが進行中であるか否かを検出する。StormDetect()は、encoder_decorder_loop()のwhile(1)ループの先頭に配置される。ストームが検出されると、ローカルな参加者が重要な話し手又は非常に高ランクでない限り、StormDetect()は、VADアクセス関数SetStormMute(true)を呼び出す。
パケットデコーディングアルゴリズム
AudioManはリアルタイムカーネルで実行され、着信した40を超えるG.722ストリームで一杯になると、CPUタイムが100%になるだろう。着信オーディオパケットの数が40より下に落ちるまで、タッチパネルは応答しない。(40という値は、おおまかな近似である。) 誰かが、冗談のような、参加者の大半が反応する何かを言う場合、大規模な会議において、これらの数は起こり得る。AudioManは、特定の時間周期に渡って、受信パケットの数をカウントする。パケットのカウントが所定の閾値を超えると、周期の前に到着したオーディオパケットは、単に廃棄される。廃棄されたパケットの数は、g_nPacketsPolicedで追跡記録されて、ゼロより大きい値がヘルプに表示されると、ステータススクリーンが示される。
AudioManと何もかも同じように、サーバセッティングは、
Audio_MaxReceivedPackets=70
Audio_MaxReceivedPacketsPeriod=40
この例では、40ms周期中で最初に受信した70のオーディオパケットがデコードされる。40msの周期が経過して、プロセスが再度開始するまで、70番目の後に受信されたパケットは廃棄される。
オーディオストーム処理について鍵となる「独特な」事項の1つは、各端末が、特別な同期メッセージを全く用いることなく、「正確に」同じ決定に独立に達することである。それら全てが同じオーディオストリームを受信し、同じスコアリングルールを用いることから、これが可能となる。
次の出願は全て、引用を以て本件明細書の一部となる。米国特許出願第10/114,402号「ビデオフォン及びビデオコール方法(VIDEOPHONE AND METHOD FOR A VIDEO CALL)」。米国特許出願第10/871,852号「オーディオミキサ及びその方法(AUDIO MIXER AND METHOD)」。米国特許出願第11/078,193号「ストリームを用いた会議の方法及び装置(METHOD AND APPARATUS FOR CONFERENCING WITH STREAM)」。
ノードには、メンバー、パーティ、端末、又は会議の参加者が含まれる。会議は、通常、少なくとも3つのノードを含んでおり、10や20、50、100、150、又はより多数のノードも含み得る。
全オーディオ帯域は、決して1000Kbpsを超えることはなく、ビデオに障害があってもよい。オーディオストーム帯域幅制御方法は、最大の話し手の数を10人に制限して、オーディオ及びビデオの劣化を防止する。
ビデオフォン
図8、図9、図10及び図11を参照すると、Sビデオを伴うソニー製の一般的なアナログビデオカメラ(32)のような撮像装置(30)が、該撮像装置(30)で得られるシーンの画像を電気信号に変換する。その電気信号は、配線を通って、フィリップス製SAA7144 NTSC/PAL/デコーダのようなビデオデコーダ(34)に送られる。ビデオデコーダ(34)は、電気信号をデジタル信号に変換して、BT656フォーマットのようなシーンの画素のストリームとしてそれらを送る。画素のストリームは、ビデオデコーダ(34)から送り出されて、第1ストリームと、第1ストリームと同じである第2ストリームとに分けられる。エンコーダ(36)は、IBM eNV 420エンコーダであるのが好ましく、画素の第1ストリームを受信し、それを処理してMPEG-2フォーマットのデータストリームを生成する。ビデオエンコーダ(36)で生成されたデータストリームは、カメラで生成された際と比較して約50分の1のサイズに圧縮される。MPEG-2ストリームは、エンコードされたデジタルストリームであって、引き続いてパケット化される前にフレームバッファリングされないので、遅延が最小化されている。エンコードされたMPEG-2デジタルストリームは、フィールドプログラマブルゲートアレイ(FPGA)(38)と、MPEG-2ストリームが与えられるソフトウエアとを用いて、RTPによってパケット化される。そして、PLX 9054 PCIインターフェイス(44)を通じて、ネットワークインターフェイス(42)を用いて、イーサネット(登録商標)802.P、又は毎秒155メガビットのATMのようなネットワーク(40)に送信される。必要ならば、CNNや映画のようなVCRやテレビジョンショーに関するビデオストリームがデコーダ(34)で受信され、ディスプレイコントローラ(52)に直接供給されて表示される。デコーダコントローラ(46)は、FPGA(38)に配置されてデコーダ(34)に接続されており、デコーダ(34)の動作を制御する。
また、デジタルカメラ(47)を用いる場合、カメラで生成された結果のストリームは、既にデジタルフォーマットであって、デコーダ(34)に供給される必要はない。デジタルカメラ(47)から送られるデジタルストリームは、BT 656フォーマットであって、カメラから直接に第1及び第2ストリームに分けて送り出されて、ビデオデコーダ(34)を通ることはない。
さらに、1394 インターフェイスファイヤラインカメラ(48)のようなファイヤラインカメラ(48)を用いると、デジタル信号を直接FPGA(38)に供給できる。ファイヤラインカメラ(48)を用いると、FPGA(38)から非常に短い距離を超えてデータストリームの生成が行われる場合に、デジタル信号が、例えばケーブルによって、ファイヤラインカメラ(48)から長い距離でサポートされる利点がある。FPGA(38)は、ファイヤラインカメラ(48)から送られるデジタル信号をエンコーダ(36)に供給して、上述の処理が行われる。そして、FPGA(38)は、以下に説明するように、低フレームレートのストリームを生成する。
第2ストリームはFPGA(38)に供給されて、FPGA(38)及びソフトウエアは、モーションJPEGストリームのような低フレームレートのストリームを生成する。第2ストリームは、第1ストリームよりも低い帯域幅を必要とする。FPGA(38)及びメインコントローラ(50)は、ソフトウェアによるエンコードを用いて、この低フレームレートのストリームを圧縮及びパケット化し、それをPCIインターフェイス(44)に供給する。続いて、PCIインターフェイス(44)は、ネットワークインターフェイスカード(56)を通じてネットワークインターフェイス(42)にそれを転送する。ネットワークインターフェイス(42)は、それをネットワーク(40)に送信する。エンコードされたMPEG-2デジタルストリーム及び低フレームレートストリームは、基本的に同じであるが独立した2つのデータストリームである。しかしながら、低フレームレートストリームは、MPEG-2データストリームと比較して縮小されており、MPEG-2ストリームと比較して、同一シーンの表示が小さく、ネットワーク(40)のリソースが少なくてすむ。
ネットワーク(40)上では、各デジタルストリームは、所望の受信ビデオフォン(15)に運ばれる。会議のパーティの数が2を超える場合には、各デジタルストリームは、複数の受信ビデオフォン(15)に運ばれる。データは、SIPを用いてルーティングされる。受信ビデオフォン(15)のネットワークインターフェイスカード(56)は、第1及び第2データストリームのパケットを受信し、パケットのデータと、メインコントローラで選択されたビデオストリーム(第1又は第2)とを受信メモリに送る。受信ビデオフォン(15)のメインコントローラ(50)は、ソフトウエアを用いて、選択された受信データストリームをデコード及び伸張し、それをディスプレイコントローラ(52)に転送する。ディスプレイコントローラ(52)は、一般的なスケーリングハードウエアを用いて、VGAデジタルフラットパネルディスプレイに再生画像を表示する。受信ビデオフォン(15)のユーザは、タッチスクリーン(74)を用いて、2つのデータストリームのうちどちらが表示されるかを選択する。必要に応じて、ユーザは両方を選択し、シーンの大きい画像と小さい画像とが表示される。しかしながら、送信ビデオフォン(15)から送られる両方のストリームが表示されることは、通常起こらないだろう。表示用のプロトコルの説明は、以下で行われる。シーンの大きい画像又はシーンの小さい画像の何れかを選択するオプションを有することで、ユーザは、システム(10)のリソースを割り当てて、見る者にとってその時により重要である者が、大きく鮮明な画像で見られるように選択できる。一方で、ユーザがまだ見たいと思うがその時に重要ではない者も、引き続き見られ得る。
2以上のビデオストリームがある場合(会議コールが起こっている場合)、ディスプレイコントローラ(52)は、個々のビデオストリームをディスプレイ(54)に並べて表示する。ディスプレイ(54)に並べて形成された画像はクリップされており(clipped)、縮小されていない。シーンにおける物の大きさは変化しておらず、単に、各データストリームのシーンにおける夫々の側の外領域が削除される。必要ならば、シーンの小さい画像に関するストリームの画像は、ディスプレイ(54)のスクリーンにて、右下隅に並べて表示される。図9に示すように、ディスプレイコントローラ(52)は、一般的なデジタルビデオをLCDコントローラ(72)に供給する。ディスプレイコントローラ(52)は、ATI又はNvidia製であり、一般的なVGAコントローラである。LCDコントローラ(72)は、ディスプレイコントローラ(52)から送られる一般的なデジタルビデオを得て、フィリップスや富士通のパネルのような、使用する特定のパネルに適した画像を作成する。
画像のクリップをさらに向上させるため、単に、画像の部分的削除を外側端部から中央に向けて行う代わりに、関係ある情報を示さない部分を画像からクリップする。画像の左側又右側にて人物が話している場合、外端部の各々からクリップする代わりに、人物が画像の右側にいる場合、画像の左側からクリップするのが望ましく、人物が画像の左側にいる場合、画像の右側からクリップするのが望ましい。外端部の各々からクリップすると、人物の部分が失われることが起こり得る。ビデオトラッキングを用いることで、形成される画像を見て、画像内で変化が起こっている場所を解析して、画像内で人物がいる場所を特定する。人物は、画像のその他の領域に対して相対的に動いており、この相対移動を特定することで、画像における人物の位置が決定され得る。このビデオトラッキングによって、クリップを、変化が最も少なくなる端部又は複数の端部にて起こすことが可能となる。代わりに、又はビデオトラッキングと併せて、オーディオトラッキングを用いて、画像のクリップを行うことを補助できる。ビデオフォン(15)はマイクロホンアレイを有しており、マイクロホンアレイの数々の要素に音が達する異なる瞬間にて、一般的な三角測量(triangulation)を行うことで、マイクロホンアレイに対して人物が何処に配置されているかを決定できる。画像になっているシーンに対するマイクロホンの位置は知られているので、画像における人物の位置も分かる。
ビデオフォン(15)の機能は、モニタ上のタッチスクリーン(74)で制御される。タッチスクリーン(74)は、一般的なガラスのタッチスクリーンであって、タッチスクリーンコントローラ(76)に生信号を供給する。公知のように、生信号は、ユーザが所定の場所でガラスに触ると生じる超音波で感知される。そして、タッチスクリーンコントローラ(76)は生信号を得ると、それらをスクリーン上のX及びY位置に関する有意義な情報に変換して、この情報をメインコントローラ(50)に送る。
テレビジョン又はVCR接続が利用される場合、テレビジョン又は映画はデコーダ(34)に供給されて、その供給は、ビデオフォン(15)で受信されるその他のビデオ信号と同様に制御される。テレビジョン又は映画は、ディスプレイ(54)上にて、別のビデオフォン(15)に関係したビデオのシーンの横に表示される。
シーンのオーディオストリームは、基本的に、オーディオビデオストリームと並行な同様の経路を通るが、オーディオストリームは、マイクロホン、サウンドカード、ヘッドセット又はハンドセットのようなオーディオレシーバ(58)から、CSクリスタル4201オーディオインターフェイス(60)又はコーデック製の同様なインターフェイスに供給される。オーディオインターフェイス(60)は、ボリューム及びミキシングの制御に加えて、信号のアナログデジタル変換及びデジタルアナログ変換を行う。オーディオインターフェイス(60)は、オーディオ信号をデジタル化して、TCI 320C6711 又は 6205 DSP(62)に送る。その後、DSP(62)は、デジタル化されたオーディオストリームをパケット化し、そのデジタル化されたオーディオストリームをFPGA(38)に転送する。続いて、FPGA(38)は、それをPCIインターフェイス(44)に与える。オーディオストリームは、その後、ネットワークインターフェイスカード(56)を通ってネットワーク(40)に送信される。オーディオストリームは受信ビデオフォン(15)で受信されて、FPGA(38)を通ってDSP(62)に、さらにはオーディオインターフェイス(60)に送られる。デジタル信号は、オーディオインターフェイス(60)にてアナログ信号に変換されて、スピーカ(64)で再生される。
ネットワークインターフェイスカード(56)は、ネットワーク(40)に送信されるオーディオパケット及びビデオパケットの各々にタイムスタンプを付す。ビデオフォン(15)が受信したオーディオ及びビデオパケットが処理される速度は、充分に速いので、人間の目及び耳は、シーンのビデオに合わせられるオーディオのずれを、視聴の際に識別できない。20〜30ミリ秒未満という制限が、シーンのオーディオ及びビデオ情報の処理でなされて、シーンのビデオ及びオーディオの関係が維持される。シーンのオーディオ及びビデオの同期を受信ビデオフォン(15)にて受信される際に保証するために、各パケットのタイムスタンプが参照されて、対応するオーディオベースのパケットとビデオベースのパケットが受信ビデオフォン(15)にて並べられて、対応するように基本的に同時に再生される。これによって、受信ビデオフォン(15)のユーザに識別されるようなシーンのビデオ及びオーディオのずれは存在しなくなる。
ENC−DSPボードは、IBM eNV 420 MPEG−2エンコーダ及びサポート回路と、オーディオエンコード及びデコードをするDSP(62)と、PCIインターフェイス(44)とを含んでいる。それは、高性能PC(68)プラットホーム及びディスプレイ(54)システム(10)に与えられる完全なビデオフォン(15)端末機能に必要なハードウエアを含んでいる。それは、フルサイズのPCI2.2に準拠したデザインである。カメラ、1又は複数のマイクロホン、及びスピーカ(64)は、このボードにインターフェイスする。DSP(62)は、オーディオエンコード、デコード、ミキシング、ステレオ配置(stereo placement)、レベルコントロール、ギャップフィリング(gap filling)、パケット化、及びその他のオーディオ機能、例えば、ステレオAEC、ビームステアリング、ノイズキャンセル、キーボードクリックキャンセルやデリバーバレイション(de-reverberation)を行う。FPGA(38)は、セロクシア(Celoxia)(ヘンデル−C(Handel-C))ツールを用いて開発され、再構成可能である。レイアウトは、1〜3百万ゲートレンジで部品をサポートする。
このボードは、デジタルカメラ(47)チップインターフェイス、ハードウエア又は「ビデオDSP」ベースのマルチチャンネルビデオデコーダ(34)インターフェイス、DVI入出力コネクタを用いたビデオオーバーレイを含んでおり、ビデオオーバーレイと共に、フルダンプなフレームバッファを可能としている。
NTSC又はPALビデオ信号を用いて、エンコーダ(36)は、640×480である、好ましくは720×480又はより高解像度である高品質なビデオストリームを生成する。ビットレートは、フレーム当たりの最大ビットが制限されるように制御されて、ネットワーク(40)に渡って伝送遅延が抑制される。デコーダ(34)は、第1マクロブロックのデータを受信すると、一枚のデコードを開始する。ある種のバッファリングが行われてもよく、軽微なジッタが調整されて、画像が向上する。
MPEG-2は、広く使用及び実施されており、DVD及びVCDのエンコード、デジタルVCR、及びTiVoのようなビデオ録画装置に加えて、DSSやその他のデジタルTV放送の基礎となっている。通常、4から50Mbit/secのビデオ伝送が選択されると考えられる。MPEG-2は、広く使用されているので、比較的低コストであり、デコードについての、つい最近ではさらにエンコードについての高集積化されたソリューションが、現在商業的に入手可能である。
MPEG-2は、一般的な圧縮方法と考えられるよりは、むしろエンコードされたビデオのシンタックス(syntax)であると考えられる。仕様がシンタックス及びエンコード方法を定める一方で、定められたシンタックスに従う限り、その方法の使用について非常に広い自由度がある。この理由から、MPEG-2に関する一般化は、しばしば誤り又は不正確である。特定の用途へのMPEG-2のパフォーマンスを評価するためには、特定のエンコード方法と意図した応用について、より低いレベルの詳細まで達する必要がある。
ネットワーク(40)に関連した問題と共に、低遅延のエンコード及びデコードの問題は、ビデオフォン(15)プロジェクトにとって興味深い。MPEG-2のアルゴリズムにおける3つの主要な問題があり、これらはネットワーク(40)に渡って低遅延で高い品質のビデオを得るために理解される必要がある。
≡ GOP(Group Of Pictures)構造及びその遅延に与える効果。
≡ 遅延及びネットワーク(40)の要求に与えるビットレート、エンコードされたフレームサイズ変化、VBVバッファの効果。
≡ パケット損失による、質に与えるGOP構造の効果。
GOP構造及び遅延:
MPEG-2は、3種類のエンコードフレーム:I,P及びBを定義している。最も普通に使用されるGOP構造は、16フレーム長のIPBBPBBPBBPBBPBBである。この構造の問題は、Bフレームは前後のフレームから推測される動きであるので、連続するBフレームの各々について、Bフレームのエンコードが開始できる前に、次のフレームがキャプチャされる必要があることである。各フレームは33msecであるので、これは、Bフレームがない構造を超えて、このGOP構造に最小で66msecの遅延を加える。このことによって、I及び/又はPフレームのみを含んでおり、MPEG-2の仕様で、SP@ML(シンプルプロファイル)エンコードとして定められた、低遅延のGOP構造が導かれる。
ビットレート、エンコードフレームサイズ、及びVBV:
Bフレームが除かれてエンコード遅延が最小化されると、GOP構造は、Iフレームと、Iフレームに対するPフレームとで構成される。Iフレームは、完全にフレーム内符号化されているので、これを行うために多くのビットが必要とされて、次のPフレームのビットは少なくなる。
IフレームはPフレームの8倍大きく、そのビットレートは公称(nominal)の5倍である可能性があることに留意すべきである。このことは、ネットワーク(40)の要求と遅延とに直接的な影響を与える。帯域幅に制限がある場合、Iフレームはネットワーク(40)のリストリクションにてバッファリングされて、結果として限定されたセグメントに渡って、複数のフレームの時間の遅延が加わるであろう。再生レートがネットワーク(40)の帯域幅ではなく、ビデオに合わせられるので、このバッファはレシーバに適合する必要がある。上記データで用いられるサンプルは、低動作オフィスシーンであった。シーンが変化する高動作のコンテントでは、フレームには、コンテントに応じたビットが割り当てられて、シーンが変化する際には幾つかの大きなPフレームが生じるであろう。
この振る舞いを制御するために、MPEG-2は、VBVバッファ(ビデオバッファリングベリファ)を使用する。VBVバッファは、最大エンコードフレームサイズと公称のビットレートとの間の比率をある程度制御する。公称ビットレートで示されたサイズの2倍より小さくIフレームが制限されるように、VBVを確実に制限することで、加えられるバッファリング遅延を1フレーム時間に制限できる。VBVのサイズを制限することによって、画質が犠牲となる。Iフレームが大きい理由は、次のPフレームの良いベースを与えるためであり、Iフレームのサイズが制限される場合、質は、より低いビットレート(<4Mビット)へと顕著に低下する。2Mビットでは、平均フレームサイズは8Kバイトであり、このサイズの2倍でさえも、Iフレームと同様にDCT圧縮される320×240のJPEG画像を、良質でエンコードするのには不十分である。
Iフレームのみのエンコードによって、エンコードフレームサイズは、より一致するが、質がより低下する。低ビットレートのIフレームのみをエンコードすることは、MPEG-2のアルゴリズムの圧縮能力の大部分を活用していない。
MPEG-2の仕様は、CBR(Constant Bit Rate)及びVBR(Variable Bit Rate)モードを定めており、ストリーム内にて可変なGOP構造を可能とする。CBRモードは、必要に応じてパッディング(padding)を行って、各GOPについて一定数のビットを生成するように定められている。VBRは、エンコード帯域幅を可変にすることで、一定の質を得ることを意図としており、より簡単なセクションにおけるより低いビットレートでこのことが補償されている限り、ストリームにて、困難なエンコード領域により多くのビットを割り当てることが可能となる。VBRは、2(two)パス又はシングルパステクニックを用いて実現できる。可変GOP構造によって、例えば、シーンが遷移する境界におけるIフレームの配置にて、目で見える圧縮アーチファクトが除去される。低遅延が求められており、VBR又は可変GOPを実施するためにビットを小さくする必要があるので、これらのモードは、ビデオフォン(15)の用途には、ほとんど関連がない。
典型的なGOP構造におけるP及びBフレームは、Iフレームと、以前のP及びBフレームとに依存しているので、データの損失は、次のIフレームまでの全てのフレームに影響を与えて、エラーが生じる。このことは、また、スタートアップの待ち時間に影響を与えて、例えば、DSSシステム(10)でチャンネルをオンにする場合、デコーダ(34)は、画像の表示を開始する前にIフレームを待つ。このために、GOP長、構造及びビットレートは、用途及び配信システム(10)に対して調整される必要がある。IPを用いたリアルタイムコラボレーションの場合、信頼性のあるプロトコルを用いてハンドシェイク及び再送するのに要する遅延を受け入れる余裕はないので、遅れたパケットは失われたとして取り扱う必要があり、RTPやUDPのような信頼性がない転送プロトコルが用いられる。パケット損失がビデオの質に与える効果について、様々な解析がなされており、典型的なIPB GOP構造では、1%のパケット損失が30%のフレーム損失を生じる事が示されている。より短いGOP構造、究極的にはIフレームのみのストリーム(質の損失がある)は、これを幾分抑える。また、FEC(Forward Error Correction)テクニックは、損失が生じると、これを幾分抑えることができる。しかし、MPEG-2の問題の一つは、明らかに、データ損失をあまり許容できないことである。
連続的Pフレームエンコードと呼ばれるGOP構造は、上記の問題の全てに対処して、比較的低ビットレートで、優れたビデオの質をビデオフォン(15)に与える。連続的Pエンコードは、Pフレーム内にて、フレームのマクロブロックをフレーム内エンコードする機能を用いる。各フレームにて、16×16ピクセルのマクロブロックの擬似乱数セットをエンコードし、その他をモーションコーディング(motion-coding)して、Iフレームのビットの同等物を各フレームに分布させる。擬似乱数を用いてマクロブロックの選択をすると、頻出する時間スケールで全てのブロックが更新されるので、スタートアップとシーンの変化は、妥当な方法で処理される。
IBMは、このアルゴリズムをS420エンコーダで実施しており、フルフレームDCTアップデートレートを8フレーム(3.75回/秒)に設定している。典型的なオフィス及び会議のコンテントでは、その結果は、非常に優れたものとなる。エンコードによる遅延、エンコードされたフレームのサイズの変化、パケット損失は、ビデオフォン(15)にとって非常に理想的な振る舞いとなっている。エンコードされたサンプルを見ると、シーン変化と非常に動的なコンテントについてはエンコーダ(36)アーチファクトが現れるが、コラボレーションで典型的である話し手の顔のコンテントについては、質は非常に良い。
高質のオーディオは、効果的なコミュニケーションにおいて欠かすことができない。高質とは、全二重であり、帯域幅が7kHzであり(電話は3.2kHz)、信号対雑音比が30dBより大きく、知覚できるエコー、クリッピング又はゆがみがないことである。設定は非常に容易で、可能な限りケーブルは少ない。オンボードの診断は、問題及びその解決方法とを示す。スピーカ(64)からの音には、音のレベルの高低に関係なく、大きなはじけ音やうなり音が無い。
失われた又は遅れたパケットのオーディオ信号は、先のオーディオ信号に基づいて「満たす」ことができる。オーディオバッファは、ネットワーク(40)のジッタとオーディオに加わる遅延との間のバランスとして約50msとすべきである。320サンプル又は20msの現在のパケットサイズを減らすならば、エンコード及びデコード遅延が減るであろう。しかしながら、20msは、RTPパケットの一般的なデータ長である。
以下に説明するプロセスの幾つかは、市販の製品で利用されている。しかしながら、コスト低減と集積化を図るために、それらはDSP(62)として実施されるであろう。別の実施例では、1つのDSP(62)が上記のプロセスに加えて音響エコーキャンセルをも行うのではなく、第2DSP(62)が、音響エコーキャンセルを行い得る。
オーディオシステム(10)は、送信及び受信セクションを有している。送信セクションは、以下の要素で構成される。
マイクロフォン:
スピーカフォンに対する主要な不満の一つに、離れた所で聞く音がこもってしまうことがある。このこもった音は、部屋の反響によって生じるものであり、直接音のパワーに対する反射(反響)音のパワーの比、として考えるのが良い。現在、ピックアップを改善する最も良い方法は、マイクロフォンを話し手に近づけて配置して、直接音のパワーを増加させることである。オフィス環境では、マイクロフォンは、PC(68)のモニタに、ビデオフォン(15)端末に、ホワイトボードに配置できる。
自動ゲイン制御:
各マイクロフォンのプリアンプのゲインは自動的に調節されて、ADCレンジが十分に使用される。プリアンプゲインは、AEC及びノイズリダクションのようなその他のオーディオプロセスに送られる。
CODEC:
簡単な形式では、これはADCデバイスとなる。しかしながら、テキサスインスツルメント及びアナログデバイスインコーポレイテッドのような幾つかの企業は、アナログアンプとアナログマルチプレクサを具えるCODECを有している。また、同様に制御されるDACがチップ上にある。先に説明した自動ゲイン制御は、CODECで実施されて、DSP(62)で制御される。
ノイズリダクション:
2つの方法のノイズリダクションを用いることで、SNRを改善できる。第1の方法は、一般にノイズゲーティング(noise gating)と呼ばれており、現在の信号レベルに応じてチャンネルをオン・オフする。第2の方法は、適応ノイズキャンセル(ANC)であり、マイクロフォンの信号から不要なノイズを取り去る。オフィス環境では、ANCを用いて、PAアナウンス、ファンノイズ、ある場合にはキーボードのクリック音でさえ除去できるであろう。
ノイズリダクション又はゲーティングのアルゴリズムは、クールエディトやゴールドウェーブのような市販のオーディオ編集パッケージで利用できる。このようパッケージは、特別な効果を加えて、記録からスクラッチ及びポップノイズを除去し、テープ記録からヒスノイズも除去できる。
音響エコーキャンセル:
エコーが聞こえるのは、話し手の声が50msを超えた後に話し手に戻る場合である。エコーは、非常に気を散らせるので、除去される必要がある。エコーの2つのソースとして、ラインエコーと音響エコーがある。ラインエコーは、2本線の電話システム(10)の特性による。PSTNは、ラインエコーキャンセラ(LEC)を用いて、このエコーを除去する。スピーカフォンシステム(10)を用いる場合、音響エコーは、電話のスピーカとマイクロホン間で起こる。離れたスピーカからの音は、離れたマイクロホンで拾われて話し手に戻る。音響エコーキャンセル(AEC)は、LECよりも難しい。部屋の音響は、モデルよりも複雑で、人の動きで急に変化するからである。ASPI EF1210のようなスタンドアロンデバイスから、DSP(62)のプラットフォームで動くように最適化されたシグナルワークスのオブジェクトモジュールに亘る、多くのAECプロダクトがある。
オートミキシング:
オートミキシングは、互いにミキシングされるマイクロホン信号を選択し、ミキサのモノラル出力をエンコーダ(36)に送る。選択基準は、最も音が大きいソースの近くのマイクロホンを用いること、又は閾値レベルを超えた音を受けているマイクロホンを用いることを基本にしている。オートミキサは、様々なベンダーから商業的に入手でき、電話会議及び電話教育システムで使用されている。
エンコーディング:
データ伝送の帯域幅を低減するため、典型的な信号特性と我々のスピーチの理解力を利用して、オーディオ信号はより低いビットレートに圧縮される。現在、G.722コーデックが、適度なビットレートである64kビット/秒にて、最も良いオーディオ品質(7kHz帯域幅@14ビット)を提供する。
RTP伝送:
エンコードオーディオデータは、20msecのセグメントに分割されて、リアルタイムプロトコル(RTP)パケットとして送られる。RTPは、VoIP及び電話会議の用途に必要なリアルタイムデータ交換用に特別に設計された。
受信セクションは、以下の要素で構成される。
RTP受信:
RTPパケットは、1又は2以上の離れた場所から送られるオーディオストリームを含んでおり、各々のバッファに置かれる。失われた又は遅れたパケットが検出されると、その情報がギャップハンドラー(Gap Handler)に送られる。順序が正しくないパケットは、遅れたパケットの特殊な例であって、遅れたパケットと同じように、多分廃棄される。代わりに、少なくとも1つのパケット長についてオーディオ信号の再生を遅らせるバッファを用いてもよい。バッファのサイズは、両端間の遅延が100msより長くないように制限される必要があるだろう。
デコーディング:
G.722オーディオストリームは、CODEC用のPCMサンプルにデコードされる。
ギャップハンドリング:
ネットワークに渡ってRTPパケットは失われ、又は破損するであろう。それ故に、ギャップハンドラーは、過去のパケットのスペクトル及び統計に基づいて、失われたデータを「満たす」。最小の場合として、ゼロがデータストリームに加えられてデータが作成されるが、スペクトル内挿又は外挿アルゴリズムを用いてデータを満たすことができる。
バッファリング:
ネットワークジッタは、連続的なオーディオ再生を可能とするために、バッファリングを必要とするだろう。恐らく、このバッファは、短期のジッタ統計と待ち時間の効果との間の妥協に基づいて、そのサイズ(故に待ち時間も)調整するであろう。
レート制御:
ビデオフォン(15)端末の公称のサンプルレートは、16kHzである。しかしながら、わずかな差異が存在しているならば処理される必要があるだろう。例えば、北のビデオフォン(15)が現在16,001Hzでサンプリングする一方で、南のビデオフォン(15)は15,999Hzでサンプリングする。よって、南の端末は、スピーカに出力するよりも1秒当たりに1だけ多いサンプルを積み重ねており、北の端末では、同じだけけの量が不足するだろう。受信バッファの長期の統計によって、サンプリングレートの差異を決定して、(北のビデオフォン(15)のための)適切な内挿、又は(南のビデオフォン(15)のための)デシメーションのファクタを計算できる。
ボリューム制御:
スピーカ(64)から来る音のボリュームを調整することは、通常、離れた聴取者によって行われる。より良い方法は、部屋のマイクロホンで聞こえる大きさに基づいて、スピーカ(64)からの音を自動的に調整することであろう。バックグラウンドノイズ及び聴取者自身の嗜好のようなその他の因子を考慮することもできる。
ステレオ配置:
場所が異なる離れた話し手を、聴野(auditory field)に置くことができる。だから、場所Aの人物は常に左から、場所Bの人物は真ん中から、場所Cの人物は右から聞こえるということになるだろう。この配置によって、話をしている者に追従することが容易になる。
スピーカ:
音の質は、スピーカ(64)及びその筺体の質である程度決定される。如何なる場合でも、自己増幅型スピーカ(64)がビデオフォン(15)端末に使用される。
差別化(Differentiation):
ポリコムサウンドステーションのような現在の会議システムは、充分ではあるが帯域が制限された全二重のオーディオ品質をもたらす。しかしながら、帯域幅は、3500Hzに制限されており、その結果、音質は、耳に負担を掛けるものとなり、際立った摩擦音の場合には顕著である。
ビデオフォン(15)は、帯域幅を7kHzに広げ、複数のマイクロホンを自動ミキシングして、部屋の反響音を小さくする。3人又はそれより多い人物が話している場合、離れた参加者の各々は、ステレオ音場において独自の場所に配置されるだろう。高質のオーディオピックアップと増加した帯域幅とを組み合わせることで、ネットワーク(40)に渡る会議は、そこに居る者に素早くアプローチするだろう。
オーディオシステム(10)は、複数のマイクロホンを用いているので音をよく拾い、ワイドバンドエンコーダ(G.722)を用いて、トールグレード(tollgrade)で現在提供されているよりも良い忠実度を得ている。加えて、複数パーティの会議では、離れた話し手のステレオ配置が行われて、音響エコーキャンセルシステム(10)によるハンズフリー動作が可能となる。部屋のボリューム調整は、エンドユーザの単一管理で自動的に制御されて、全体的な音のレベルが調整される。
ビデオフォン(15)ネットワーク(40)では、ゲートウェイ(70)は、SIPではない物をSIP環境に接続する。普通、プロトコルの差異に加えて電気的な差異がある。ゲートウェイ(70)の大半は、他の電話又はビデオ会議デバイスを、ビデオフォン(15)のシステム(10)に接続する。
ゲートウェイ(70)は、インターフェイスで区別される。一方の側はネットワーク(40)であり、ビデオフォン(15)では、これはイーサネット又はATMである。外側は、アナログ電話線又はRS−232ポートであろう。ポートのタイプ、番号及び特徴は、あるゲートウェイ(70)を他と区別する。ネットワーク(40)の側には、RTP又はALL2のような転送プロトコルと、SIP、メガコ(Megaco)又はMGCPのような信号伝達プロトコルとがある。
外側では、与えられたインターフェイスに応じた多種多様なプロトコルがあってよい。例えば、ISDN(Q.931)又はPOTSシグナリングがあろう。PSTNゲートウェイ(70)は、PSTNラインをビデオフォン(15)システム(10)にその場で接続する。PBXゲートウェイ(70)によって、ビデオフォン(15)システム(10)は、メーカー独自仕様の電話をエミュレートして、その場にあるPBXへの互換性を与える。POTSゲートウェイ(70)は、みすぼらしいアナログフォンをビデオフォン(15)システム(10)に接続する。H.323ゲートウェイ(70)は、H.323システム(10)を、SIPベースのビデオフォン(15)システム(10)に接続する。これは、信号伝達のみのゲートウェイ(70)であり、メディアサーバ(66)は、H.261からMPEGへの変換を行う。
ビデオフォン(15)で実行可能な3つの技術として、セッション開始プロトコル(SIP)、セッション記述プロトコル(SDP)、リアルタイム転送プロトコル(RTP)があり、これらは全て、引用をもって本明細書の一部となる。
SIPは、パケットネットワークに渡る音声及びビデオセッションを初期化し、管理し、終了する信号伝達プロトコルである。
SDPは、マルチメディアセッションの初期化におけるセッション告知、セッション案内、及びその他のフォームを目的とするマルチメディアセッションを記述する。SIPは、SDPを用いてメディアセッションを記述する。
RTPは、マルチキャスト又はユニキャストのネットワーク(40)でのサービスに渡って、オーディオ、ビデオ又はシミュレーションデータのようなリアルタイムデータを転送する用途に適しているエンドツーエンドのネットワーク(40)転送機能を与える。SIPは、RTPを用いてメディアセッション伝送を行う。
ビデオフォン(15)は、如何なる会議ブリッジ又はMCUも用いることなく、3又は4以上のパーティで会議を行える。これは、SIPで定められるようにATMポイントツーマルチポイントストリームを用いて達成される。さらに詳細に述べると、MPEG-2ストリーム及び低フレームレートストリームがパケット化されてネットワーク(40)に転送される場合、各パケットのヘッダ情報は、周知のように、会議の受信ビデオフォン(15)の全てのアドレスを特定する。この情報から、パケットがネットワーク(40)に転送される場合に、SIPは、異なるパケットについて必要な接続を確立して、所望のビデオフォン(15)の送り先にそれらが達することができる。
如何なる会議ブリッジも使用しない会議の例として、10個のビデオフォン(15)があって、それらは、会議のパーティがいる別々の場所に配置されているとする。各ビデオフォン(15)は、オーディオベースのストリームと、MPEG-2ベースのストリームと、低フレームレートベースのストリームとを生成する。しかしながら、各ビデオフォン(15)は、これらストリームの何れも自分に送り戻さないので、10のパーティがあるビデオフォン(15)の会議では、各々は、その他9個のビデオフォン(15)と効率的に通信可能となる。一方で、ビデオフォン(15)がそれ自身と通信する場合には、帯域幅を最大限に使用するために、どのビデオフォン(15)で生成されたビデオも、必要ならばビデオフォン(15)で生成されたオーディオも、基本的にそれが他のビデオフォン(15)であるかのように見られ、又は聞かれ得る。しかし、以下で説明するように内部チャンネルを通ると、ネットワーク(40)のどの帯域幅の使用も必要とされない。
会議では、各ビデオフォン(15)は、9つのオーディオベースのデータストリームを受信する。3つのMPEG-2ベースのデータストリームと、6つの低フレームレートベースのデータストリームとがある。必要ならば、レシーバは、低フレームレートの9つのストリームを選択して、ディスプレイ(54)は各ビデオフォン(15)の小さい画像を表示し、又は、MPEG-2ベースの4つのストリームを選択して、ディスプレイ(54)は会議の4つのビデオフォン(15)からの画像で満たされる。4つのMPEG-2ベースのデータストリームが表示されるならば、ディスプレイ(54)に表示用の領域はないので、低フレームレートベースのストリームの画像は表示されない。3つのMPEG-2ベースのデータストリームが表示される場合、6つの低フレームレートベースのストリームを表示できる。各ストリームは、いろいろなビデオフォン(15)にて、上述したように作成及び受信される。
大きな画像を4つより多く会議で表示することが求められるならば、これを達成する方法では、追加のビデオフォン(15)が互いに接続されて、図7に示すように、個々のビデオフォン(15)のディスプレイは、一列に並べられる。あるビデオフォン(15)をマスターとすることができ、追加のビデオフォンが加えられると、それはマスタービデオフォン(15)のスレーブとなる。マスタービデオフォン(15)は、異なっているビデオフォン(15)に渡って、大きい及び小さい画像の表示を制御する。
会議のビデオフォン(15)のディスプレイに、誰が大きい画像として、誰が小さい画像として表示されるかを決定するプロトコルについて、1つの好ましい実施例は、最近の3人の話し手を大きく表示し、その他のパーティを小さく表示するというものである。即ち、現在話をしているパーティと、それ以前の2人の話し手とが大きく表示される。会議の各ビデオフォン(15)は、会議のオーディオベースのストリームの全てを受信するので、各ビデオフォン(15)は、そのメインコントローラ(50)を用いて、所定の瞬間にて話が起こっている場所を割り出し、さらに、ネットワークインターフェイスカード(56)が、話が生じているビデオフォン(15)のMPEG-2ストリームを受け取るが、低フレームレートストリームを受け取らないようにする。別のプロトコルでは、あるビデオフォン(15)は、リード又はモデレータビデオフォン(15)として設定され、リードビデオフォン(15)は、大きい及び小さい画像について、他の全てのビデオフォン(15)が見ているものを選別する。さらに別のプロトコルでは、誰を大きくし、誰を小さくするかという画像の選択は固定されて、会議を通じて同一に維持される。プロトコルは、各ビデオフォン(15)が、受信する画像をそれらがどのように表示するのを欲しているかを調べるというようにできる。MPEG-2ベースのストリーム及び低フレームレートストリームの両方が、ネットワーク(40)上にて、会議の受信ビデオフォンに転送される。その結果、両方のビデオストリームは、各受信ビデオフォン(15)にて利用でき、選択されているディスプレイ(54)のプロトコルに応じて表示される。
各ビデオフォン(15)で転送されるオーディオベースのストリームについては、帯域幅をさらに効果的に使用するために、そして、如何なる送信ビデオフォン(15)又は受信ビデオフォン(15)にてなされる処理要求を減らして、オーディオ処理を補助するために、オーディオベースのストリームは、送信ビデオフォン(15)にて所定のデジベルの閾値を超えたオーディオがある場合にのみ、ビデオフォン(15)で送信される。十分大きな音のオーディオベースのストリームを送信することのみによって、話が生じている場合に達するように又は超えるように閾値が較正されているとの仮定の下、基本的に帯域幅を使う以外に何も貢献しない外部からのバックグラウンドノイズが送受されることが防がれるだけでなく、話のオーディオストリームのみが受信されているので、話に関するMPEG-2ストリームを選択することが助けられる。
上述のように、特定のビデオフォン(15)が、他のビデオフォン(15)に送られている自分の画像を見たい場合には、FPGA(38)で作成された低フレームレートストリームがビデオフォン(15)のローカルメモリに送られる。しかしながら、低フレームレートストリームが、パケット化されて、ビデオフォン(15)からネットワーク(40)に送られる場合に起こり得るような圧縮は行われない。このローカルメモリから、メインプロセッサは、ソフトウェアを用いてそれを処理して、それをディスプレイ(54)に小さい画像として表示させる。
さらに、ビデオフォン(15)は、ネットワーク(40)から受信したどのオーディオ又はビデオストリームが聞かれるか又は見られるかを制御する。ビデオフォン(15)のユーザが見たい又は聞きたいよりも多くのパーティが会議にある状況において、ビデオフォン(15)のユーザは、会議全体を構成するオーディオ又はビデオストリームの一部のみを見る又は聞くように選択できる。例えば、パーティが100ある会議では、ユーザは、見ることができる100の画像から全23の画像について、3つのビデオストリームをスクリーン上の大きな画像として、20のビデオストリームをスクリーン上の小さな画像として見ることを選択する。ビデオフォン(15)のユーザは、声の大きな3人の話し手を大きな画像として表示し、また、会議のパーティのタッチスクリーン(74)を介して、小さな画像として表示する20のパーティを選択する。これらパーティは、タッチスクリーンのページにリストアップされている。他のプロトコルを選択できて、小さな画像として表示される20の画像を、会議が始まって各パーティが紹介をした時刻からの、会議における最新の話し手になるようにできる。表示されるビデオストリームの数を制御することで、組織が会議に適合し、ビデオフォン(15)のリソースの使用がより良く割り振られる。
スクリーンで表示される個々の画像について、各画像に関連した選択が可能である。例えば、1つの画像を会議コールのモデレータで選択し、2つの画像を、会議の現時点で最後の/最も声が大きい話し手とし、その他の画像を、その他の会議の参加者全てからユーザが選択した人物とすることができる。このように、会議のあらゆる参加者又はユーザは、会議の参加者の全数から画像の様々な選択ができるであろう。そして、必要とされる最大帯域幅は、会議の参加者の数に拘わらず、1つのビデオストリームをネットワークに送るためのものとなり、4つのビデオストリームをネットワークから受け取るためのものとなる。
オーディオストリームに関して、最も声の大きい3人の話し手の各々の画像がスクリーンに表示される間は、それらの話し手のオーディオストリームのみが選択されて聞かれる制限をビデオフォン(15)に課すことができる。DSP(62)は、受信したオーディオストリームを解析して、声が最も大きい話し手の3つのオーディオストリームのみを再生させて、同時に、声が最も大きい話し手の3つのオーディオストリームに関係した、大きな画像の第1ビデオストリームのみを受信するようにネットワークインターフェイス(42)に指示する。一般的には、大勢の人々が同時に話すと、混乱が増加して、理解が妨げられる。故に、ユーザによる制御がオーディオストリームに行われることで、組織のある程度にそれらを認識させることが可能となる。
オーディオストリームの制御の一環として、上述のように、各ビデオフォン(15)は、そのビデオフォン(15)のノイズが閾値を超えた場合にのみ、オーディオストリームを送る。好ましくは、閾値は動的であって、所定の時刻における、声の大きな3人の話し手に関連した音の大きな3つのオーディオストリームのノイズレベルに基づいている。このため、オーディオストリームが声の大きな3人の話し手のオーディオストリームの一つとして認められるので、その他のオーディオストリームのノイズレベルは、モニタされて、特定される必要がある。DSP(62)は、ネットワーク(40)を介してネットワークインターフェイス(42)から送られるオーディオストリームを受信する。そして、DSP(62)は、オーディオストリームを調べて、最も大きなノイズを有する3つのストリームを特定し、最も声の大きい3人の話し手のものとして特定されている受信した3つのオーディオストリームのノイズレベルを、ビデオフォン(15)のシーンのノイズレベルと比較する。ビデオフォン(15)のシーンのノイズレベルが、受信したどのオーディオストリームよりも大きい場合、ビデオフォン(15)は、そのオーディオストリームをネットワーク(40)に送る。DSP(62)によるこのような解析が、会議の各ビデオフォンで独立に行われて、会議に渡って分散した解析が行われる。各ビデオフォンは、その他の全てのビデオフォンと独立して、受信したオーディオストリームに関する解析を自ら行う。明らかに、これらオーディオストリームは、所定の時間にて声の大きい3人の話し手の1人のものであると十分に保証できるほどシーンのノイズが大きいと、個々のビデオフォン(15)が判別した後にのみ、各ビデオフォン(15)によって送られる。各ビデオフォン(15)は その結果、受信したオーディオストリームの情報を得て、それを自己のノイズレベルとの比較の基礎として用いる。そして、各ビデオフォン(15)は、独自に閾値の決定を行っている。
分散した解析を行う別の方法では、各ビデオフォンが、DSP(62)にて用いられるべき閾値となるものを決定した後、会議の他の全てのビデオフォンにこの閾値が送られる。これにより、全てのビデオフォンは、他の全てのビデオフォンが閾値としたものを検討でき、例えば、それらの閾値を平均して、そのビデオフォンのシーンに適用される閾値を特定する。
声が最も大きい3人の話し手のビデオストリームを選択する技術を用いることで、パーティが大きな声で一度に話し始めて、混乱と不理解が生じる瞬間があるかも知れない。しかしながら、そのようにすることで、それはノイズを閾値のレベルに上げて、非常に短い間に、他と同程度の大きさのノイズを生成していないオーディオストリームは除去されて、声の最も大きな3人の話し手のオーディオストリームのみが再度選択されて聞こえるであろう。また、その他のオーディオストリームは選択されておらず、これらオーディオストリームが寄与しているかも知れないノイズのある程度が取り除かれる。このことは、時に、3つを超えるオーディオストリームがビデオフォン(15)で受信されることを意味している。3個を超えるビデオフォンで、ある瞬間にノイズが閾値を超えて、このようなビデオフォンの各々が、その時にオーディオストリームを生成してネットワーク(40)に送り得るからである。しかしながら、今し方説明したように、一旦閾値が変更されると、事態は終わるだろう。オーディオストリームに関したこの分散した解析は、ここで説明したビデオフォン(15)に限定されることはなく、ビデオストリームの有無に拘わらず、如何なるタイプの音声を用いた会議でも利用可能である。
使用する帯域幅の節約を重要視しており、必要なもののみを送って帯域幅を節約することから、画像のクリップは、受信ビデオフォン(15)ではなくエンコーダ(36)にて行われる。送信ビデオフォン(15)が、それの画像が受信ビデオフォン(15)にてどのように現れるかを知っている場合、エンコーダ(36)は、シーンの大きな画像を、それが送信される前にクリップする。そして、画像のそれほど大きくない部分が送信されて、帯域幅を使用する。クリップが受信ビデオフォン(15)で起こる場合、ソフトウエアを伴ったメインプロセッサは、受信した画像がディスプレイコントローラ(52)に供給される前に、それを処理するであろう。
第2カメラをビデオフォン(15)に接続すると、シーンの別の眺めが得られる。例えば、部屋では、第1カメラ、即ち主カメラが、視聴者又は話し手の顔に焦点を合わせて配置される。しかしながら、部屋にはさらに人がいて、ビデオフォン(15)を制御する人は、受信ビデオフォン(15)の他の視聴者を見たいと欲する。例えば、第2カメラは、部屋の上隅に配置されて、主カメラよりも基本的に部屋のかなり広い領域を見る。第2カメラの出力はデコーダ(34)に与えられる。デコーダ(34)は、ビデオ出力を受け取る幾つかのポートを有している。または、第2カメラから送られるストリームが既にデジタル化されている場合、それは、主カメラと同様なチャンネルを通じて、ビデオフォン(15)の処理要素に与えられる。各ビデオフォン(15)は、その外に送られるものは何でも制御し、送信するカメラ出力の選択は、ビデオフォン(15)を制御する視聴者によってなされるのが好ましい。一方で、あるビデオフォン(15)のカメラから送信されるストリームを制御及び選択する能力を、離れた受信ビデオフォン(15)に与えることができる。制御ビデオフォン(15)からの制御信号は、ネットワーク(40)を通じて送信されて、送信用に選択されたストリームを与える個々のビデオフォン(15)にて受信される。第2カメラに加えて、DVD、VCR又はホワイトボードカメラのビデオ出力のような、その他のタイプの如何なるビデオ出力も、ビデオフォン(15)を通じて供給されてよい。
好ましい実施例では、ビデオフォン(15)はピークモードで動作する。ピークモードでは、ビデオフォン(15)のカメラは、前方のシーンのスチル画像を取得して、この画像を受信すると予め決めている他のビデオフォン(15)に送信する。例えば、スピードダイアルメニュに、このようなビデオフォン(15)のリストがある。または、ピークモードでは、得られたスチル画像がビデオフォン(15)で保持されて、要求に応じて、そのビデオフォン(15)にコールしたいと思っている者に供給される。理想的には、ビデオフォン(15)の好ましい使用形態に合致するように、ビデオフォン(15)のユーザは、ビデオフォン(15)の外へ送られるものを全て制御して、単に、ピークモードをオフにすることを選択し、又はどの画像が送られるかを制御する。アクティブコールが起こると、ピークモードはオフになって、ピークモードと、連続的な画像ストリームがカメラで得られるアクティブコールとの間で矛盾が生じない。ピークモードでは、所定の時間間隔で、例えば、1分、5分、30分間隔等で、シーンのスチル画像が得られる。ピークモードでは、スチル画像が得られる前の所定の時間にて、例えば、画像が得られる5又は10秒前にて、オーディオキューが示されて、まさに画像が撮られようとしており、見苦しくないようにすべき旨の警告が、カメラの前にいる者に与えられる。オーディオキューは、ビープ音、ピング(ping)音、若しくはその他の録音されたノイズ、又はメッセージとすることができる。このように、ピークモードが用いられる場合には、ビデオフォン(15)のカメラの前におけるシーンのピークが他のビデオフォン(15)で利用可能となり、その他のビデオフォン(15)に、カメラに関わる人物の存在が示される。
プレセンスセンサの別の実施例では、カメラの前の領域に対するカメラの自動レンズの位置を、プレゼンスセンサとして働かせる。カメラの前に人がいない場合、カメラの自動レンズは、その領域内の物体又は壁に焦点を当てる。人物がカメラの前にいる場合、自動レンズはその人物に焦点を当てる。人物によって、人物がレンズの前にいない場合と異なる位置にレンズが配置される。レンズの焦点を表示するカメラの信号は、カメラからFPGA(38)に送られる。FPGA(38)は、その後、例えば、送信ビデオフォン(15)のスピードダイヤルリストにあるビデオフォン(15)の受信側のような、所定のリストにあるビデオフォン(15)の受信側に焦点の情報を送る。これによって、視聴者がビデオフォン(15)の前にいるか否かが受信ビデオフォン(15)に知らされて、誰がいることが示される。
また、ビデオフォン(15)はビデオメールを提供する。あるビデオコール(15)から別のビデオフォン(15)へのビデオコールが試みられて、所定時間後に、例えば4回ベルが鳴った後に、受信ビデオフォン(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)及びDSP(62)は、スピーカ(64)のオーディオ出力のレベルを下げて、ノイズレベルを低減する。所定且つ所望のレベルを設定することで、ビデオフォン(15)は、視聴者が何かを行うことなく、自動的にボリュームの大きさを制御する。
ビデオフォン(15)は、特定の人物に話しかける問合せを認識すると、受信ビデオフォン(15)でのトーン又は信号のような、認識に用いられる所定のスピーチパターンを用いて、受信ビデオフォン(15)にコールが要求されている旨を、受信ビデオフォン(15)の視聴者に知らせるようにプログラムできる。例えば、言葉「ヘイ、クレイグ(Hey Craig)」がビデオフォン(15)で用いられて、コールがクレイグに向けて開始されるべきものであることが送信ビデオフォン(15)で認識される。視聴者が「ヘイ、クレイグ」を言うことで、送信ビデオフォンが自動的にクレイグへのコールを開始し、言葉「ヘイ、クレイグ」がクレイグの受信ビデオフォン(15)に送られる。クレイグの受信ビデオフォン(15)が鳴って、コールがクレイグに要求されていることを示す代わりに、言葉「ヘイ、クレイグ」が、直ちにクレイグのビデオフォン(15)にアナウンスされる。これは、クレイグの注意を喚起するために通常起こされるベルに置き換わる。この動作を行う機能は、メインコントローラ(50)及びDSP(62)で実現されるであろう。発言「ヘイ、クレイグ」は、視聴者によってアナウンスされて、上述のようにサーバ(66)に送信される。サーバ(66)は、発言を解析して、命令として言葉を認識し、命令に記されたパーティにコールを開始する。その後、サーバ(66)は、クレイグのビデオフォン(15)のアドレス情報を用いて、クレイグのビデオフォン(15)とコールを開始し、クレイグのビデオフォン(15)で「ヘイ、クレイグ」になる信号又は音色を発生させる。
当該技術分野で周知のように、エンコーダ(36)は、各フレームの最初及び最後を特定できる。エンコーダ(36)がデータを受信すると、それはフレームのデータをエンコードして、フレームが完全になるまで格納する。エンコーダ(36)が使用するアルゴリズムによって、格納されたフレームは、次のフレームを形成するための基礎として用いられる。格納されたフレームは、次のフレームをエンコードするためのリファレンスフレームとして働く。これは、基本的に、最初からのフレーム全部ではなく、あるフレームから次のフレームへのフレームの変化がエンコードの中心だからである。その後、エンコードされたフレームは、上述のように、直ちに送り出されて、パケット化される。フレームは、パケット化を除いてバッファリングされることはないので、遅延は最小限に抑えられる。なお、エンコーダ(36)がフレームのデータをエンコードする際に、データの送信速度をさらに速くするために、フレーム全体がエンコードされることを待たないで、エンコードされたデータをパケット化のために順序付けしてもよい。また、先に説明した理由から、エンコードされたデータは、フレームを形成するために格納されるので、リファレンスフレームがフレームで利用可能となる。しかしながら、別個に、データは、エンコードされる際にパケット化のために送られて、パケット化の準備中にフレームを形成する。しかし、パケットが送信可能となって、フレームの一部分のみがパケットを部分的に構成する場合であっても、フレームの残りの部分が別個のパケットとして送信されて、フレーム情報を伴う両方のパケットが受信ビデオフォン(15)で受信されるまで、フレームは形成されない。
図1を参照すると、ビデオフォン(15)がネットワーク(40)に接続されている。ビデオフォン(15)は、銅又はマルチモードファイバーの何れかの上にて、10/100イーサネット接続と、オプションとしてATM155Mbps接続とをサポートしている。各ビデオフォン(15)端末は、通常、ユーザのPC(68)に取り付けられている。ビデオフォン(15)の役割は、(会議)コールのオーディオ及びビデオ特性を与えることである。PC(68)は、その他の機能に用いられる。ビデオフォン(15)を用いてコールを確立することで、PC(68)間のマイクロソフトネットミーティングセッションが確立される。これによって、ユーザは、ウインドウズベースのプログラム、例えば、パワーポイントプレゼンテーションやスプレッドシートと協動すること、電子ホワイトボードと画像を交換すること、ファイルを転送すること、テキストベースのチャットプログラムを使用すること等が行える。ビデオフォン(15)端末がどのように接続されているかに拘わりなく、PC(68)は、イーサネットに接続できる。PC(68)は、当然に、ATM LANにも接続できる。PC(68)と、関連する送信ビデオフォン(15)とは、ネットワーク(40)を通じて相互に通信する。PC(68)と、関連する送信ビデオフォン(15)とが相互に通信することで、PC(68)は、送信ビデオフォン(15)が話している相手を知る。その後、PC(68)は、送信ビデオフォン(15)が話している相手である受信ビデオフォン(15)のPC(68)と通信可能となる。また、PC(68)は、ビデオフォン(15)にコールすることも可能である。
システム(10)の機能の大半は、サーバーベースであって、ビデオフォン(15)のプロキシサーバで動作するソフトウエアで実現されている。プロキシサーバは、SIPプロキシサーバであるのが好ましい。基本機能をもたらすために第1サーバが必要とされ、第2サーバは、弾力的な動作に、言い換えると、第1サーバが失敗したイベントを保全するサービスに必要とされる。このような場合、サーバとビデオフォン(15)のソフトウエアは、バックアップサーバ(66)に自動的にスワップする。この構成を用いて、ネットワーク(40)上の他のビデオフォン(15)に、さらに、好ましくはSIPフォンであるネットワークに登録された電話に、ビデオフォン(15)はコールをすることが可能となり、また、これらからのコールを受け取ることが可能となる。
メディアサーバは、一連のメディアストリーム上のユーザに一連のサービスを提供する。メディアサーバ(66)は、主サーバ(feature server)で(好ましくは主サーバで)制御される。それは、ユーザインボキャブル(user-invocable)な種々の機能の一部として、メディアストリームの送信側と受信側を与えるために用いられる。メディアサーバで与えられるサービスは、会議ブリッジ、記録及び再生、トランスコーディング、音色及びアナウンスメントである。
メディアサーバ(66)は、LAN又はWAN上にあるボックスである。通常、それは、その他の接続を有していない。それは、SIPデバイスであるのが好ましい。主サーバは、ビデオフォン(15)端末から発する信号経路内にある。しかしながら、メディアの経路は、メディアサーバ(66)から装置に直通するだろう。
動作中、ユーザは、ビデオメール等の機能を要求してよい。主サーバ(66)は、ユーザインターフェイス及びシグナリング機能を与え、メディアサーバ(66)は、(使用されるならば)マルチメディアプロンプト(multimedia prompt)機能と、メッセージの記録再生機能を与えるだろう。
ビデオフォン(15)端末が、(SIPビデオフォンのような)プロトコル外又は基準外の(ビデオ)フォンにコールをし、又はそれらのコールを受け入れることを可能にするために、SIPゲートウェイのようなゲートウェイ(70)が加えられる。4本のアナログラインを有するゲートウェイ(70)が、PSTNに直接接続されるか、ローカルPBXのアナログラインに接続される。出力ラインを供給する通常の規則が適用される。一般的な1本の中継ラインが6人のユーザの全てに供給される。つまり、どのユーザも自分のフォンを用いて、勤務時間外の10分間、外部接続にダイヤルすると仮定する。ビデオフォン(15)端末が現在のPBXの拡張として働く場合、着信コールに関する限り、1本のアナログラインが各ビデオフォン(15)に必要となる。
CNNのようなTVソースが、ビデオフォン(15)のユーザに利用され得る。ビデオフォン(15)のビデオサーバ(66)によって、このサービスが可能となる。サーバ(66)は、1つのビデオチャンネルとの接続をサポートし、そのチャンネルは、ネットワーク(40)上のどのビデオフォン(15)のユーザでも利用される。ビデオチャンネルは、通常の2つの会議セッションと同等である。チューナは、利用可能なチャンネルをセットする。新たなビデオフォン(15)のビデオサーバ(66)が、ユーザが同時利用を願う異なるチャンネルの各々について設定に加えられる。
また、ビデオフォン(15)のサーバ(66)(好ましくはSIP)は、ユーザデータのデータベースを持っており、ユーザコンタクト情報のローカルキャッシュを含んでいる。このデータべースは、ユーザに関するメインコンタクトデータべースと同期化できる。同期化は、例えば、アウトルック/エクスチェンジのユーザによって、ロータスノーツのユーザのために行われる。別個のプログラムが、NTベースの如何なるサーバ(66)プラットホームでも動作して、同期化を行う。扱うサイトの数に拘わらず、1つのサーバのみが必要とされる。
図2に示すように、通常、ビデオフォン(15)端末は、幾つかのサイトに渡って分散しており、ワイドエリアネットワーク(40)と協力する。あるサーバ(66)は、1つのキャンパスにて、最大で100個以上のビデオフォン(15)を十分に扱える。サイト上のビデオフォン(15)の数が増加すると、ある段階でさらにサーバをインストールする必要が生じる。
ビデオフォン(15)が幾つかのサイトを渡って分散すると、中央サーバに基づいてそれらを動作可能となるが、WANで使用される帯域幅と、WANへの依存とを考慮すると、これは勧められる構成ではない。好ましくは、各サイトは少なくとも1つのサーバ(66)を有しており、該サーバ(66)は、SIPが用いられる場合、SIPサーバ(66)であるのが好ましい。さらに忠告すると、最も簡単で容易な構成は各サイトが、好ましくはSIPである二重のサーバを有することである。しかしながら、遠隔のサイトサーバの代わりとして、中央サーバを用いることも可能である。
ビデオフォン(15)は、ネットワーク(40)の何処においても、1つの中央ゲートウェイ(70)からPSTN又はPBXベースの送信コールが可能である。しかしながら、ビデオフォン(15)が、受信コールを受け入れるためにローカルPBXの延長でもなければならない場合には、PSTNゲートウェイ(70)は、各場所に与えられることが必要である。そのサイトの全てのビデオフォン(15)について、ゲートウェイ(70)のポートが必要となる。
中央CNNサーバ(66)は、ネットワーク(40)上のどのビデオフォン(15)にも、TVチャンネルを配信する。それにも拘わらず、WANに渡ってその帯域幅を得るよりは、サイト特有のサーバを含むことが好ましいであろう。
ビデオフォン(15)は、(ファイバーと銅のオプションを用いて)10/100イーサネットネットワーク(40)又は155Mbits/sec のATMネットワーク(40)の何れか一方に接続できる。ATMに接続されたビデオフォン(15)は、IPコントロールプレーンを用いて、コールのエンドポイントのATMアドレスを定めて、そして、ATM信号を発して、エンドポイント間で搬送チャンネル(bearer channel)を確立する。搬送チャンネルは、スイッチドバーチャル回路(SVC)で確立され、完全なQoSの要求が特定される。
各ビデオストリームは、セッティングと帯域幅のネゴシエーションによって定められるように、2Mbpsと6Mbpsの間で双方向に送信可能である。ディスプレイ手段が2以上のビデオストリームを表示できるので、各ビデオフォンを全接続するのに要求される帯域幅は、コールのパーティ数と共に増加する。送信端のクリップによって、要求される最大の帯域幅は、単一のビデオストリームで使用される帯域幅の約2.5倍となる。サイトに幾つかのビデオフォン(15)がある場合、ユーザとトランク(trunk)間の通常のテレフォンレシオ(telephone ratio)が、ビデオフォン(15)のセッションに加わる。言い換えると、ビデオフォン(15)のユーザは、各コールにて平均して2人の他人と、つまり2つのストリームで会話すると予想され、ユーザは、その時に平均して10分間ビデオフォン(15)を用いる。平均エンコードレートが3Mbpsである場合、このことより、6MbpsのWANの帯域幅が必要となり、この帯域幅では、最大6人までのユーザをサポートすることが期待される。
図3に示すように、ビデオフォン(15)は、ビデオフォン(15)端末の密度が低い場合に、「p」で動作可能な('p' enabled)イーサネットネットワーク(40)で動作する。ビデオフォン(15)のシステム(10)は、2個のビデオフォン(15)を互いにリンクするネットワーク(40)のATM部分に渡ってSVCを確立すると共に、「p」で動作可能なイーサネットを用いることで、十分なクオリティオブサービスが接続のイーサネット部分に渡って与えられることを保証する。
ビデオフォン(15)のシステム(10)の基本的な構成要素が、図4に示されている。それらは共にマルチメディア協動ツールを生成して、それらツールは、地理的に分散したチームが交流する能力を増進させる。このようなチームは、ほとんど全ての大企業で存在しており、次第に増加している。さらに、彼らが効果的及び効率的に働くことを助けるツールは、10年前からほとんど変わっておらず、多くの面で不満足なものである。ビデオフォン(15)は、包括的な方法を用いて現存するシステムの多くの問題に対処し、遠隔地間の共同作業に断続的な(discontinuous)改善をもたらす。それは、新たに利用可能な技術を用いて可能となり、クオリティオブサービスと正しいミキシング機能で差別化され、優れたユーザインターフェイスの開発によって使用可能となり、標準ベースのアーキテクチャを用いることで、拡張可能なように設計される。
オーディオ及びビデオストリームは、上述のように、例えば、周知のSIP技術を用いて、ネットワーク上の始端ビデオフォン(15)から終端ビデオフォン(15)に送信される。SIPメッセージは、異種のネットワークに渡ってIPルーティング技術を用いてルーティングされてよい。異種のネットワークのメディアストリームには、より直接的な経路が要求される。好ましくは、図15に示すように、会議の始端ビデオフォン(15)がイーサネットに接続されて、会議の終端ビデオフォン(15)がATMネットワークに接続されている場合、始端及び終端ビデオフォン間のネットワークを渡るパケットについて、以下に述べるアドレッシングが起こる。始端ビデオフォン(15)は、パケットをイーサネットに送って、始端ビデオフォンのIPアドレスを用いて通信が行われる。パケットは、イーサネットをATMネットワークにリンクする始端ゲートウェイ(80)に到達する。始端ゲートウェイ(80)では、始端ビデオフォン(15)のIPアドレスが、パケットから保存される。始端ゲートウェイ(80)は、始端ゲートウェイ(80)のATMアドレスをパケットに加えて、終端ビデオフォン(15)にパケットを送る。終端ビデオフォン(15)がパケットを受信すると、それは、始端ゲートウェイ(80)のATMアドレスをパケットより格納して、始端ゲートウェイ(80)にリターンパケットを送り返す。リターンパケットは、終端ビデオフォン(15)がパケットを受信したことを示しており、終端ビデオフォン(15)のATMアドレスを伴っている。始端ゲートウェイ(80)は、リターンパケットを受信すると、終端ビデオフォン(15)のATMアドレスを保存し、始端ゲートウェイ(80)のIPアドレスをリターンパケットに加える。リターンパケットは、その後、始端ゲートウェイ(80)から始端ビデオフォン(15)に送り返される。
このように、始端ビデオフォン(15)と終端ビデオフォン(15)間の経路全体に渡るクリティカルなノード、始端ビデオフォン(15)及び終端ビデオフォン(15)の具体的アドレスが、経路のクリティカルなノードの各々で知られる。最低でも、経路の各ノードは、経路の次のノードのアドレスを知る。必要ならば、個々のパケットが経路に沿って動くにつれて、追加されたアドレスがそれらに保存されて、経路の各ノードは、パケットが向かう次のノードよりも、クリティカルなノードのアドレスについてより多くを知る。これは、パケットがノードからノードへ移動すると、具体的な例としては、始端ビデオフォン(15)から始端ゲートウェイ(80)に、それから終端ビデオフォン(15)に、そして、終端ビデオフォン(15)から始端ゲートウェイ(80)に、それから始端ビデオフォン(15)に戻るように、パケットが移動すると、各ノードは、受け取った個々のパケットを送った前のノードのクリティカルなアドレスを保存し、次のノードが含まれるネットワークのタイプに関した自己のアドレスを持ち込むことによる。その結果として、各ノードが次のノードにパケットを送るのに必要なクリティカルなアドレスは、経路を通じて配布される。
イーサネット上の始端ビデオフォン(15)からATMネットワーク上の終端ビデオフォン(15)にパケットを転送するこの例は、逆の場合、つまり、始端端末つまり始端ビデオフォン(15)がATMネットワークと通信し、終端ビデオフォン(15)がイーサネットと通信する場合にも適用できる。
同様にして、経路は、イーサネットと通信する始端ビデオフォン(15)と、イーサネットと通信する終端ビデオフォン(15)とを含み、図16に示すように、パケットが行き来するATMネットワークが中間にあるように構成され得る。このような場合、各端に配置された2つのゲートウェイがあって、それらは、イーサネットとATMネットワークのインターフェイスとなる。先述のように、処理では、追加ノードが単純に経路に加えられる。始端ゲートウェイ(80)は、自己のATMアドレスをパケットに取り込んで、それを終端ゲートウェイ(82)に送る。終端ゲートウェイ(82)は、始端ゲートウェイのATMアドレスを保存し、終端ゲートウェイのIPアドレスをパケットに加えて、イーサネット上で終端ビデオフォン(15)に送る。リターンパケットについて、同じ事が逆に起こる。各ゲートウェイは、先のゲートウェイ又は終端ビデオフォン(15)から得た個々のアドレス情報を保存して、自己のアドレスをリターンパケットに加える。リターンパケットは、最終的に始端ビデオフォン(15)に送られる。始端ゲートウェイ(80)及び始端ビデオフォン(15)は、終端ゲートウェイ(82)又は始端ゲートウェイ(80)のATMアドレスを夫々保存し、経路に渡る各リンクにおける個々のアドレスが、より効率的に格納されて、接続のパケットは、迅速に順次転送される。
例えば、SIPルーティング情報(または、標準的なルーティング情報であれば何でも用いられる)をパケットに収納するという、当業者に周知の技術と同様な技術を用いて、ビデオフォン(15)のメインコントローラ(50)及びネットワークインターフェイス(42)は、ビデオフォン(15)のアドレスを、それがネットワーク(40)に送る各パケットに加える。また、ネットワークインターフェイス(42)は、ネットワーク上のノードから送られるパケットから受け取ったアドレス情報を、ローカルメモリに格納する。同じように、ネットワーク(40)のゲートウェイについて同様な構成が適用される。周知のように、ゲートウェイは、パケットをその最終的な送り先に移動させる制御手段及びデータ処理手段を有している。ゲートウェイの制御機構のネットワークインターフェイス(42)及びメインコントローラ(50)は、SIPルーティング情報に関した周知の技術で動作し、パケットから受け取ったアドレス情報を格納し、パケットを送ろうとしているネットワーク(40)につ関する自己のアドレス情報をパケットに収納する。例えば、ゲートウェイ又はビデオフォン(15)のアドレス情報は、パケットのヘッダー部のフィールドに配置される。実施例では、終端及び始端ソースとしてビデオフォン(15)が使用されているが、パケットを生成及び受信するデバイスであればどのようなタイプも、このスキーム全体にて使用されることに留意すべきである。
バーチャルプレゼンスビデオ−フォン(ビデオフォン)(15)は、デスクトップのネットワーク(40)装置であり、個人用の通信端末である。それは、ユーザの机のフォンに置き換わって、現在のPBX端末の全ての機能を提供するものであり、ビデオフォン(15)の大きなタッチスクリーン(74)によって、ユーザインターフェイスが簡単になり、使用が容易になっている
ビデオフォン(15)は、全ての個人間通信にビデオの特徴を加えて、見聞をバーチャルなものに変化させる。従来では、ビデオ会議システムのビデオの質は、トランスペアレントであるのに技術的に不十分であった。ビデオフォン(15)は、十分に高い質のビデオをもたらして、見聞を正確に生成する最初の個人用ビデオフォンである。効果面では、リアルタイムビデオ通信が放送されるTVの質に近い画像の質を有しているだけでなく、待ち時間が非常に短く維持されなくてはならない。会話が自然に流れるためには、リップシンク(Lip Sync)もまた重要である。これらのような問題の全ては、ビデオフォン(15)のビデオサブシステムのデザインにて対処されている。ビデオフォン(15)は、この用途に特別に構成された最新のエンコーダ(36)及びデコーダ(34)技術を用いている。言い換えると、ビデオフォン(15)は、「そこにある」ように可能な限り近づいている。
また、ビデオフォン(15)は、ハイファイの、CDに近い音質のオーディオチャンネルを使用することで、従来のスピーカフォンの性能を改善し、透明で明瞭な音声を提供する。ステレオのオーディオチャンネルは、各参加者のオーディオの空間的な差異を与える。進歩したステレオエコーキャンセルは、ユニットスピーカ(64)の音をキャンセルするだけでなく、騒々しい部屋でさえも、通常の会議のレベルにて、話し手に会議を続けることを可能にする。
ビデオフォン(15)は、最大で4つの離れたパーティによる(即ち5方向の)ビデオ会議コールを、及び/又は、最大で10つのパーティによるオーディオ会議コールを確立して、直接的にサポートする。各ユーザは、彼/彼女のワークグループにおける他のメンバー全てについて、利用状況を見ることができる。ビデオフォン(15)は、マルチストリームのマルチメディアセッションを確立し、修正し、クリアする手段として、セッション開始プロトコル(SIP)を用いるのが好ましい。ビデオフォン(15)は、ゲートウェイ(70)を通じて、その他のSIPフォン又はその他のフォンへのオーディオコールを確立できる。
ビデオフォン(15)は、それが取り付けられるネットワーク(40)に高度な要求をする。ビデオフォン(15)のビデオフォンコールは、連続的な高帯域幅を提供して、帯域幅、待ち時間及びジッタを保証するようにネットワーク(40)に要求する。マルコーニ株式会社は、高度なクオリティオブサービス用途をサポートするネットワークを提供することを専門に行っている。ビデオフォン(15)の会議部屋バージョンも利用可能である。
ビデオフォン(15)は、通信端末(プラットホーム)であり、ユーザのPC(68)を用いて、コンピューティングプラットホームを完全に統合する能力を有している。PC(68)用のビデオフォン(15)のアプリケーションは、PC(68)と、これに関係するビデオフォン(15)端末との間で多くのインテグレーションサービスを提供する。これには、ビデオフォン(15)の会議コールのパーティ間でネットミーティングセッションを自動的に確立することが含まれ、もし可能であるならば、ホワイトボードやプレゼンテーション等のアプリケーションが共有される。また、PC(68)上の番号にビデオフォン(15)で「ドラッグアンドドロップ」ダイヤルをすることを含むその他の機能も含まれる。
一連のサーバは、好ましくは各々がSIPサーバであって、これらを用いて、ネットワーク(40)装置のコールの制御及び機能が実現される。これらは、通常のコンピューティングプラットホーム上で動作するソウトウェアサーバであって、リダンダンシ(redundancy)の能力がある。また、これらのサーバは、ユーザコンタクト情報データベースとユーザ選択データベースのローカルコピーを管理する。これらサーバで利用できるアプリケーションによって、企業の、又はその他のLDAPアクセス可能なディレクトリへのアクセスがもたらされる。
同期サーバ(66)は、ユーザメインコンタクトデータベースと、サーバ(66)(好ましくはSIP)上のローカルコピーとの間の同期を維持する。アウトルックエクスチェンジ又はロータスノーツの同期化がサポートされる。一連のメディアゲートウェイ(70)は、アナログ又はデジタルPSTNネットワーク(40)に使用される。一連のメディアゲートウェイ(70)は、最も一般的なPABX装置とインターフェイスして、それらPABXに関係するボイスメールシステムを含んでいる。
メディアサーバ(66)は、ビデオフォン(15)端末に多数のサービスを提供する。それは、必要に応じて、4つのパーティに渡るビデオ会議の会議ブリッジ(Bridging-Conference server)(66)として働く。また、それによって、ビデオフォン(15)の規格と、H320/H323のような、その他の一般的なオーディオ又はビデオフォーマットとの間でトランスコーディングが可能となる。それによって、録音再生機能が提供されて、セッションが録音再生可能となる。それによって、トーン及びアナウンスメントのソースがもたらされる。
SIPファイヤーウォールのような、使用されている規格に従うファイヤーウォールが、(SIPプロキシソフトウェアのような)一般的なプロキシソフトウェアの制御下において、動的に生成されたRTPストリームを安全に通過させるのに必要とされる。TVサーバ(66)がソース又はTV配給元として機能して、ビデオフォン(15)のユーザは、例えばCNNのような、サポートされている任意のチャンネルを選択できる。
ビデオフォン(15)は、イーサネット及びATMデスクトップ用である。ビデオフォン(15)端末はエンドツーエンドのATM SVCをサポートし、それらを用いて、必要なレベルのクオリティオブサービスで接続を確立する。また、ビデオフォン(15)は、LANEサービスを用いてIP接続をサポートする。これを行って要求されるQoSを保証するために、LANE2が必要とされる。ビデオフォン(15)は、ATMに接続されたデスクトップPC(68)へのATMパススルーを与え、又は、ATMからイーサネットへのパススルーを与えるので、イーサネットを介してPC(68)に接続可能となる。
ビデオフォン(15)には、エンドツーエンドQoSをサポートすることが必要とされる。イーサネットに接続されたビデオフォン(15)について、ユーザ接続は、802.1p、ディフサーブ(DiffServ)及び/又はイントサーブ(IntServ)、或いはそれ以上をサポートする必要がある。送り先がATMネットワーク(40)を用いて到達可能である場合、イーサネットからATMへのゲートウェイ(70)が与えられる。SIPプロキシサーバ(66)及びSIPシグナリングは、ターゲットのビデオフォン(15)端末に最も近いATMのエンドポイントを、即ち、それがATM接続されていればそのATMアドレスを、又は、最も近いATMゲートウェイ(70)を確立する。シグナリングは、適切なQoSで、ネットワーク(40)のATM部分に渡ってSVCを確立する。このSVCは、離れた端部にて適切な優先度表示を生成する特定のイーサネットフローにリンクされる。
ビデオフォン(15)の製品ラインは、幾つかの端末(装置)と、これら装置に構築されない特徴を与える一連のサーバと、現存する設備及び外部のPSTNサービスに製品を接続する一連のゲートウェイ(70)とで構成される。システム(10)で与えられる基本的な機能は以下の通りである。
≡ 「オンネット(on-net)」の全てのコールでビデオが利用でき、オーディオとビデオの品質が非常に高いテレフォニーサービス。
≡ オーディオ及びビデオに関しており、臨機応変に又は予め計画されており、完全にセルフサービスであって、テレフォニーサービスに完全に組み込まれたマルチパーティ会議サービス。
≡ コラボレーションの可能性を決定する種々のツールを伴うプレゼンスサービス。
≡ 共有サーフェスサービス−電子ホワイトボード、アプリケーションの共有、ドキュメントの共有、プレゼンテーションの配信。
≡ その他の価値が、放送されるビデオ(大勢へのマイクメッセージ)のTV配信のようなその他の価値が加えられたサービス。オンラインのインタラクティブトレーニング等である。必要ならば、セッションを記録するサービスも利用される。
ビデオフォン(15)は、劇的に新しい機能を有する電話であって、電話がすることをコンピュータが行おうとしているのではない。これによって、コンピュータが得意である事柄に、コンピュータを完全に同時利用する一方で、通信について、柔軟な、しかし用途が特定された装置を提供できる。ユーザインターフェイス及び物理的なデザインは、この用途に合わせられて、瞬時にオンになり、PC(68)のようではなく現在の電話のような、高い信頼性のあるデバイスがもたらされる。また、このアプローチは、デバイスの動作環境の制御をもたらして、PC(68)のハードウェア及びソフトウエアの構成上の問題に関するサポートの問題が無くなる。
人的要因の研究は、オーディオの質が、効果的でトランスペアレントな通信にとって、最も重要な唯一の因子であることを、幾度となく明らかにしてきた。ハンドセットは重要であるが、質が優れたハンズフリーオーディオによって、新たなレベルの効果的な遠隔共同作業がもたらされる。ハンズフリーオーディオは、音響エコーキャンセル(AEC)と、オートゲインコントロール(AGC)と、ワイドバンドなオーディオ能力(G.722 8kHz帯域幅又はそれより大きい)と、ステレオ出力と、PC(68)の音声出力の統合とを含んている。高質のマイクロフォンアレイもあり、空き缶(tin-can)効果を制限するように設定及び処理される。
ビジュアル出力と、ボタン/選択入力とについて、簡単で、クリーンで、直感的理解が容易であり、柔軟性が充分にあるプラットフォームが用いられる。これは、第1のビデオフォンモデルでは、高質のTFTフルカラースクリーンであり、17インチのダイアゴナルな(diagonal)16×9のスクリーンで、解像度は、1260×768又はそれより大きく、中間解像度(medium resolution)の長寿命タッチパネルで覆われている。明るく(>200nit)、視角が広い(>+−60°)アクティブマトリックスパネルが用いられて、フルモーションビデオを表示し、オフィス環境にて満足に鑑賞される。より大きく、より明るく、より早く、コントラストがより高く、視角がより広いスクリーンを使用してよい。
ビデオフォン(15)は、TFTカラーLCDを用いており、インテルセレロン/440MMX及びLynxVGAコントローラに基づいたVGAタイプのディスプレイ(54)インターフェイスを伴うアーキテクチャのような、PC(68)を有している。
高質のデジタル480ラインのプログレッシブスキャンカメラが用いられて、少なくとも640×480ビデオで、1秒当たり30フレームが得られる。ビデオフォン(15)は、MPEG2エンコードを用いており、セットトップボックスに関するビデオエンコーダ(36)技術を利用している。様々な異なるビットレートを生じることができ、ビデオの質は、1対1のコールに利用されるリソースと、1又多対多のコールの最高質の参加者とに適したものになる。統合された高質のカメラモジュールがスクリーン近くに配置され、外部ビデオ入力(ファイヤライン)が設けられて、追加のカメラ、VCR又はその他のビデオソースが使用可能となる。
デスクトップへの現存するイーサネット接続は、10/100BaseTであり、LAN、WAN、PC(68)デスクトップや、種々のサーバ、プロキシ及びゲートウェイ(70)への接続に必要な唯一の接続である。オーディオ及びビデオのタイムクリティカルなRTPストリームには、802.1pを用いて優先順位が付与されて、QoSのために、LANのイーサネットドメイン内に機構が提供される。また、ディフサーブもサポートされ、RSVPはオプションとしてサポートされる。デスクトップへの配線をさらに設ける必要がないように、ビデオフォン(15)は、小さな10/100イーサネットスイッチを含んでおり、現存するデスクトップのポートがフォンとPC(68)の両方で使用できる。
また、ビデオフォン(15)は、ATMインターフェイスをサポートする。インターフェイスは、HE155Mbits/secカードの使用をベースとしており、ファイバー又は銅のインターフェイスを伴っている。ビデオフォン(15)には、ATMパススルーポートが設けられており、ATM接続されたデスクトップに接続され、又は、イーサネット接続されたPC(68)が、ATM接続されたビデオフォン(15)に接続される。
会議部屋環境についてのコスト及び性能のトレードオフは、デスクトップについてのトレードオフと明らかに異なっている。ビデオプロジェクションと、遠隔でパン/チルト/ズームが可能な複数のカメラと、複数のマイクロホンと、リアプロジェクション型ホワイトボードと、会議部屋環境に適したその他の製品とが、会議ルームのビデオフォン(15)に統合される。会議部屋環境とデスクトップの相互作用は、シームレスでトランスペアレントである。この環境は、OEM装置を大いに使用するであろう。OEM装置は、デスクトップ用に所定の位置に配置されて、同じ設備及び標準器に接続されている。ハードウェアのデザインは、基本的に同様であって、複数のマイクロホンについてさらにオーディオをサポートし、複数のカメラ及びディスプレイについてさらにビデオをサポートする。その代わりに、低コストのSIPフォンにリンクするPC(68)のアプリケーションが使用されてもよい。アプリケーションは、PC(68)がタッチスクリーン(74)を有している場合、マウス又はタッチスクリーン(74)の何れか一方で駆動される。それらのデスクトップとその他の配置が、上述のコラボレーション機能を必要としない場合、システム(10)と共に動作する典型的なフォンが使用できて、配線又はPBXを追加する必要はない。
SIP(セッション開始プロトコル)標準を用いて、端末装置は1又は2以上のサーバでサポートされており、これらサーバは、登録、ロケーション、ユーザプロファイル、プレゼンス、及び種々のプロキシサービスを行う。これらサーバは、廉価なリナックス又はBSDマシンであって、LANに接続されている。
ビデオフォン(15)は、PBX機能のキーセットが設けられたフォンであって、キーセットには、トランスファー、フォワード、3(及び4、5、・・・)パーティ会議、呼び手(caller)ID+、コール履歴等が含まれる。これら機能の幾つかは、「CPL」と称されるSIP拡張機構のトップに構築されてよい。拡張機構は、実際には言語であって、安全で拡張可能な方法で、コールの処理が行われる。
ビデオフォン(15)は、アクティブプレゼンス及びインスタントメッセージングを提供する。分散したグループによる共同作業は日々増加しており、プレゼンスは、このような作業に対して最も革新的なツールであって、それによって、人々は、誰がいるのか、彼らは何をしているのかを知ることができる。それは、オーバーヘッドが非常に小さい発呼のベースとなり、テレフォンタグ及び従来の番号のダイヤリングが無くなり、グループに働きかけて、現在一般的であるバラバラの1対1のフォン会議を通じてよりも、よりグループとして通信可能となる。インスタントメッセージング(リアルタイムeメール)の統合は、おそらくPC(68)のキーボードを入力に使用して、短いテキストのメッセージを遅延なく交換する方法を与える。
ビデオフォン(15)は、分散/冗長(redundant)アーキテクチャを提供する。これは、フォンシステム(10)であって、信頼性が必要とされる。また、それは、ローカルエクステンションを用いて中央管理され、分散したサーバは、全てのユーザに「瞬時に」応答する。SIPプロキシの種々の機能の各々は、例えば、SIPが用いられている場合、ネットワーク(40)内に配置された冗長バージョンを用いて、それらが一連の物理的サーバ内にて任意に結合できるように展開される。
マイクロソフトネットミーティングは、共有サーフェス及び共有アプリケーション機能に用いられる。PC(68)及びPDA用のコンピュータ/テレフォニーインターフェイス(CTI)を用いることができ、これは、統合されたコンタクトリスト、選択されたフォンの番号又は名前へのオートダイヤリング、コール履歴のカレンダーロギング、コンタクトの自動エントリ等の機能を含んでいる。
RTPフローが動的に割り付けられるUDPポートを用いるので、SIPには、ファイヤーウォールに関する問題があり、アドレス/ポート情報がSIPメッセージに載せられる。これは、ファイヤーウォールが、SIPメッセージをトラックして、適切なアドレス/ポートの組合せについてファイヤーウォールに「ピンホール」を開ける必要があることを意味する。さらに、NATが使用される場合、適切に変更されたアドレス/ポートを有するように、メッセージが変更される必要がある。このような仕事を達成する2つの方法がある。一つの方法は、ファイヤーウォール内にその能力を構築することである。トップ3のファイヤーウォールベンダー(チェックポイント、ネットワークアソシエーツ及びAxxcent)は、これを提供している。一方の方法は、メインのファイヤーウォールと並行動作して、単にSIPを扱う特殊用途のファイヤーウォールを設けることである。このようなファイヤーウォールの市販バージョンには、マイクロアプリアンスのものがある。SIP又はネットミーティングは好ましい実施例であって、必要とされるそれらの機能が個々に実行されることに留意すべきである。必要な機能が与えられる場合には、それらの代替物が使用されてよい。
図5は、ビデオフォン(15)端末の主たる物理的構成要素を示している。スタンドは、メインディスプレイ(54)パネルの高さを容易に調整し、その高さにパネルを保持する手段を与える。高さ調整の範囲は、少なくとも6インチの行程であって、異なる高さのユーザに対処できる。スタンドは机の上に置かれており、デスクトップの高さは画一化されていると仮定する。スタンドとメインユニット間のリンクは、ユーザの好みに合うように、限定された角度で垂直方向にチルトして、その角度で容易にロックされる。チルトの量は、垂直方向について−0+15E必要とされる。メインユニットは、オプションとしてのスタンドアセンブリを必要とすることなく、壁に直接掛けることができる。
メインユニットのケースは、ビデオフォン(15)の設計におけるその他の構成要素全てのハウジングであって、図5に示した全てのものと内部の電子装置の全てとを含んでいる。ケースには、左側又は右側の何れか一方にハンドセットが装着される。右利きの人は左手でハンドセットを手に取る傾向があり(彼らは、右手でタッチスクリーン(74)を駆動し、書き物をする)、左利きの人はその反対である。左側の位置が通常であるが、ハンドセットを右側に配置することも可能である。スピーカジャックがケースに設けられており、スピーカ(64)をビデオフォン(15)から離れて備え付けることができる。入力は、関係したPC(68)のスピーカ出力を処理するために設けられており、ビデオフォン(15)は、PC(68)及びビデオフォン(15)のオーディオを制御できる。スピーカ(64)への(ブルートゥース又はソニー規格による)ワイヤレス接続が使用できる。
ハンドセットはユニットとして設けられており、RJ9コイルケーブル及びコネクタジャックを用いて接続する。置かれている場合には、ハンドセットは容易に手に取られて、さらに、邪魔にならないようにすべきである。ハンドセットオプションは、ハンドセット標準のキーパッドを提供する。ワイヤレスのハンドセットは、端末のユーザの機動性を向上させるために用いられる。
ジャックは、ステレオハンドセット+マイクロホンの接続用に設けられる。通常の電話の会話用のハンドセットの使用が増加している。ユーザは、ハンドセット+ブーム(boom)が装着されたマイクロホン、又はヘッドセットのみの使用を選択でき、入力デバイスとしてマイクロフォンアレイが用いられる。端末のユーザの機動性を改善するワイヤレスヘッドセット用のオプションがある。
IRポートが設けられて、PDA及びその他のIRデバイスにインターフェイスする。IRポートは、容易にアクセス可能なようにメインケース上に配置される。差し当たって、フォン及びPDAのIRインターフェイスは、最も一般的なものであり、それ故、同様な理由から、IRインターフェイスと同様に、ブルートゥースインターフェイスもそのように要求される。
アレイマイクロホンは、ケーシングに埋め込まれる。アレイは、端末の通常動作の結果として、外部ノイズを生成してはならない。特に、タッチパネル上でユーザの動作を検出可能にすべきではない。アレイマイクロホンによって、ユニットのフロント回りの(例えば6フィートの)円弧及び水平面の110E内にて、所定のデジベルのバックグラウンドノイズが存在する状態にて、ユーザは、通常の会話レベルで話すことができる。ユニットは、マイクロホンが動作/非動作である旨の明確な表示を、即ち「オンフック」又は「オフフック」と同等である表示をする必要がある。ビデオフォン(15)のユーザは、知らない間に聞かれていないという安心を求めるであろう。これは、カメラの機械的なシャッタと同等なオーディオとなる。
メインのビデオフォン(15)ユニットは、スマートカードリーダオプションを具えており、個人的な特徴を用いた端末への安全なアクセスがもたらされる。ビデオフォン(15)へのアクセスは、スクリーン上の簡単なパスワードログオンからセキュリティフォブ(fob)までの、数々のアクセスコントロール特徴を必要とするだろう。スマートカードリーダは、これらアクセス方法の一つを提供する。
チルト及びパンがスクリーンから制御可能である場合、好ましくは、パン及びチルトが電子的機構のみを用いており、機械的機構を必要としない場合、明らかに利点がある。カメラのマウントは、可能な限りメインスクリーンの上部に近いように装着されて、アイコンタクトが改善されるべきである。
カメラには、480pの出力を生成する能力があるデジタルカメラを用いるべきである。カメラの出力は、MPEG−2エンコーダ(36)に送られる。カメラを動的に設定可能として、カメラの出力が最適化されて、エンコーダ(36)の選択された出力データレートでエンコーダ(36)に送られるようにすべきである。顔は、カメラが受信する入力の大部分を形成する。それ故に、肌のトーンについて広い範囲のライティング状態下で行われる正確なキャプチャが、基本的な特性となる。
カメラは、3luxに至るまでの、肌のトーンについて広い範囲のライティング状態下で動作すべきである。カメラは、自動ホワイトバランスを行えるべきである。ホワイトバランスの変化は緩やかであり、キャプチャされた画像の移行(transient)が画像の摂動(perturbation)を起こさないようにすべきである。最後の5秒に渡る変化のみが、ホワイトバランスを変化させるべきである。カメラは、18インチから10フィートまでで焦点が合うべきであり、即ち、大きな被写界深度を有している。カメラは、20フィートまでで焦点が合うのが好ましい。ホワイトボードに何か情報がある場合、ユーザとその情報の両方に対してピントが合う必要がある。オートフォーカスは、ユーザの動作中にカメラが最適な焦点を絶えず探すものであり、受信機側にて乱れた画像を生じるので避ける必要がある。
カメラは、1人のユーザがちょうどカメラの前にいる設定から、数人のユーザが同時に1つのビデオフォン(15)上にある設定まで、有限のズーム能力(limited zoom capability)を可能としている。その代わりとして、異なったレンズが設けられてもよい。レンズの視野について述べると、これは、例えば30Eの視野から75Eの視野として定められ得る。
カメラは、例えば1280×960の画像のような、送信に要されるよりも大きな画像を入力できるべきである。これは、有限のズームと、水平及び垂直のパンとを電気的に可能とし、カメラに関するエレクトロメカニカルな制御の必要性を無くす。「オンスクリーン」の装着が、単にカメラのサイズで出来なくなることがないように、カメラは物理的に小さくすべきである。
中間解像度の長寿命タッチパネルは、ビデオフォン(15)と通信する主要な方法を構成し、メインディスプレイ(54)の前部を構成する。何度も指が接触することから、パネルは、汚れを落とす掃除の繰り返しと、ディスプレイ(54)の質に影響を与えるであろう指紋とに耐えなくてはならない。タッチパネルの較正が、即ち、タッチパネル上で触られる領域とディスプレイ(54)の下部の間のアライメントが「フォールスタッチ(false touch)」の要求を保証することが容易であるべきである。
タッチスクリーン(74)の表面は、表面の反射を可能な限り少なくして、窓に向いている場合でもディスプレイ(54)が鮮明であるようにすべきである。「フォールスタッチ」がまれにしか起きないということが必要とされる。タッチパネルの解像度の要求は、それ故に、タッチが区別しようとしている最も小さいディスプレイ(54)の領域に非常に依存している。解像度と視差の誤差とは相まって、平均的な訓練を受けたユーザが、これらの因子によって「フォールスタッチ」をする可能性が5%未満になるようにすべきである(20回の選択に1回のフォールスタッチがある)。このフォールスタッチ率は2%未満であるのが好ましい。即ち、50回の選択に1回のフォールスタッチがある。
必要に応じて、成功したタッチの音響及び/又は視覚フィードバックがユーザに与えられなければならない。これらのトーンは、その時点にてタッチスクリーン(74)のディスプレイ(54)上にあるものに応じて変化してよい。例えば、キーボードを用いている場合、キーボード音に似た音が適切であり、ダイヤルパッドを用いている場合、個々に異なる音が適切であり、その他も同様である。音響フィードバックは、全ての状況にて必要ではなく、タッチの成功を示すある音響又は視覚的な表示がユーザの助けとなってもよい。ユーザは、トーンのオン/オフが可能であり、ある設定画面にて、タッチに関係したトーン、トーンの持続時間及びボリュームレベルの設定が可能とすべきである。デフォルト値が与えられるべきである。また、タッチスクリーン(74)には、指に加えてペンが使用できる。
ディスプレイ(54)パネルは、少なくとも17インチダイアゴナルフラットパネル(又はより良いもの)であって、フルカラーディスプレイ技術を用いており、アスペクト比は16×9であるのが好ましいが、16×10でもよい。
スクリーンの解像度は、少なくとも1280×768とすべきである。視認可能な角度は、垂直平面及び水平平面の双方について、少なくとも6E外の軸とすべきである。スクリーンのコントラスト比は、一般的な300:1よりも良くすべきである。色解像度は、1色当たり少なくとも6ビットとすべきであり、即ち、プロトタイプユニットで適切な、1色当たり6ビットで262Kの色を表示できるようにすべきである。その他の条件が同じとして、製品ユニットでは、1色当たり8ビットが好ましい。ディスプレイ(54)パネルは、充分に高輝度であって、充分に明るく又は自然に明るくされた部屋でさえも、楽に見られるようにすべきである。輝度は、少なくとも300cd/cm2とすべきである。ディスプレイ(54)及びデコードのエレクトロニクスは、720Pの高解像度の画像を表示可能とすべきである。このような画像は、ネットワーク(40)上の適当なソースから送られる。
バックライトは、最小寿命にて、少なくとも25,000時間で最大輝度の50%に至るものとすべきであろう。ビデオフォン(15)端末が休止しており、バックライトが切れている場合、着信コールがある場合やユーザがタッチスクリーンの何処かに触れた場合、バックライトは自動的にオンになるべきである。タッチスクリーンがオフになった後の休止期間は、ユーザによって設定可能であって、この設定は、「オフしない」ことまで含むべきである。
ビデオフォン(15)の接続領域に必要な接続が、図6に示されている。各コネクタの要件は、以下の段落にて簡潔に説明されている。
2つのRJ45 10/100イーサネットコネクタは、ネットワーク(40)への接続、及び関係するPC(68)からの接続に用いられる。
ATMパーソナリティモジュールにオプションのプラグが設けられて、光学及び銅のインターフェスの両方について、ビデオフォン(15)が、容易に155Mbits/secのインターフェイスをサポート可能にすべきである。
USBポートが設けられて、例えば、キーボード、マウス、廉価なカメラ等のオプションである種々の周辺機器が容易に接続可能にすべきである。
1394(ファイヤライン)インターフェイスが設けられて、外部の(ファイヤライン)カメラ又はその他のビデオソースに接続可能とすべきである。そのインターフェイスによって、ファイヤラインインターフェイスの完全なインバンドカメラ制御が可能となる。必要な外部コンバータが用いられて、Sビデオからファイヤライン入力への変換をすべきである。会議へのビデオフォンの出力において、このソースをメインカメラソースの代わりに使用可能とすべきである。ノーマル又は「CNN」モードを、即ち、このビデオソース上でクリップ可能(clippable)又はクリップ不可能であるかを特定可能とすべきである。XVGAビデオ出力が設けられて、ビデオフォン(15)が外部プロジェクタを駆動可能とすべきである。その画像は、メインディスプレイ(54)に表示されたものを反映する。
オーディオ入力は、PCオーディオ出力に供給されるべきである。PC(68)のオーディオとビデオフォン(15)とのオーディオの統合を確保するために、1組のスピーカ(64)のみが配置されるであろう。PC(68)の音は、ビデオフォン(15)のオーディオチャンネルを通るであろう。1つ又は1対のジャックが設けられて、ヘッドセットと、ブームが取り付けられたマイクロホンとが接続される。ヘッドセットのみの動作も、内蔵マイクロホンアレイを用いて可能とする必要がある。ヘッドセットジャックが比較的アクセスし難い場合、ヘッドセットを接続されたままにして、ユーザの制御によって、オーディオがヘッドセット上であるか否かを選択可能にすべきである。外部の左側及び右側スピーカ(64)が接続される。図7に示すように、1、2又は3つのビデオフォン(15)ユニットを、それらが、単一の機能のユニットであるかのように使用可能である。
2以上のビデオフォンが配置される場合、1つのユニットのみがメイン制御パネルとして動作し、その他のユニットはビデオと、表示されているそのビデオに直接関係した制御手段とを表示する。これらの如何なる配置についても1組のスピーカ(64)のみが必要とされるのみであろう。
マイクロホン入力及びオーディオストリームに関して、多数のオプションが設けられて、一般的な1つのマイクロホン入力を用いることから、各マイクロホンアレイからビデオフォン(15)のビデオソースにオーディオを送ることまで、可能とされるべきである。
ビデオ入力について、多数のオプションが設けられるべきである。デフォルトでは、「制御パネル」ビデオフォン(15)のビューが送信されるべきである。帯域幅がさらに利用可能である場合、各ユーザは、ユーザが表示されるスクリーンからビデオを得られ、さらに自然な経験が得られる。複数のビデオフォン(15)端末の調整は、LAN接続を用いて得られ、つまり、特殊な如何なる連絡ケーブルも必要とされない。
ビデオフォン(15)は、多数の主な機能を提供する。
−それは、オフィスフォンとなる。
−それは、ユーザのフォンとなる。
−それは、ビデオフォンとなる。
−それは、会議フォンとなる。
−それは、ビデオ会議フォンとなる。
−それは、コンタクトの詳細への容易なアクセスと、それらの管理とを行う。
−それは、ボイス/ビデオメールへのアクセスと、それらの管理とを行う。
ユニットの機能は、2つのカテゴリ、つまりユーザ機能及びシステム機能に分類される。
ユーザ機能は、ユーザが利用できる全ての機能である。
システム(10)の機能は、I.T.が要求する機能であって、モニタを設定し、ビデオフォン(15)端末を維持するものである。それらは、通常のユーザには見えない。実際に、デザイン全体の重要な目的は、ユーザに非常にシンプルなインターフェイスが与えられて、ほとんど訓練することなくビデオフォン(15)が使えることを確実にすることである。
以下に示される基本的な機能の組は、利用可能とすべき機能の最小の組である。
ビデオフォン(15)は、ユーザが端末にログオンしていない場合、通常の電話として動作する。その機能は、関連するPC(68)があることに全く依存してはならない。
以下に示されるビデオフォン(15)の機能は、オフィスにおける一般的なフォンのものである。
端末は、サイトに奉仕するPABX上の一般的な内線番号を得ることが可能である。
端末は、PABX上の、ビデオフォン(15)のネットワーク(40)上の、又は外部のフォンの区別なく、どんなフォンから送られた着信コールをも受け取ることが可能である。
ビデオフォン(15)は、互換性のあるその他のSIPフォンから送られるコールを受け入れ可能である。
着信コールは、設定されたように(以下の設定スクリーンの要件を参照のこと)ベルのトーンを生成する。特に、ビデオを含むビデオフォン(15)コールのベルトーンには、コールがビデオフォン(15)の端末から送られるか否かに拘わらず、オーディオのみのコールと区別するベルトーンが選択できる。
着信コールは、ディスプレイ(54)のステータス領域に、着信コールの表示を生成する。この表示は、着信コールで得られる情報と同じ程度の発呼側ID情報を与えるか、誰も応答できないことを示さなくてはならない。
a)着信コールのステータス表示上にあるコールアクセプトボタンを押すことで、着信コールを受け入れできる。
b)ハンドセットを持ち上げることで、着信コールを受け入れできる。これは、提供されるオプションの全てを、即ちビデオ及びオーディオを常に受け入れる。
ユーザは、コール中に、ハンドセットと、ハンズフリー(スピーカフォン)動作との間で切り替え可能である。コール中にハンドセットを持ち上げると、スピーカフォンモードからハンドセットに自動的に切り替わる。スピーカフォンモードを再選択することなしにハンドセットを戻すと、コールが切断される。
スクリーン上の表示は、モードで、即ち、ハンドセット又はハンズフリーで定められるべきである。
コールステータスバーは、コールの継続時間を表示できる。
メインディスプレイ(54)上での簡単な制御により、着信コールのボリュームを調整可能である。ヘッドセット及びスピーカのボリュームは独立して調節可能とすべきである。
スピーカフォンモードである場合、コールを切断することなくハンドセットをハンドセットスタンドに戻すことが可能である。
$ユーザが、コールステータス表示上のクリアボタンを押すと、コールが終了する。
$ハンドセットモードであって、ハンズフリーが選択されていない場合に、ユーザがハンドセットを戻すと、コールが終了する。
$コールがビデオフォン(15)に確実に示されている場合に、離れたパーティがコールを切ると、コールが終了する。
ホールド−コールをホールドし、さらにコールのホールドを再度オフにすることを可能とすべきである。ホールド状態は、ホールドされたコールに出るボタンを用いて、ステータス表示に表示されるべきである。
コール待ち−さらに送られる着信コールは、ディスプレイ(54)のステータス領域に着信コール表示を生成する。それは、設定メニュで使用可能とされない場合、コールのトーンを生成しない。
現在の動作モード、即ちハンドセット又はハンズフリーモードにて、ステータスディスプレイ(54)上のコールアクセプトボタンを用いて、新たな着信コールを受け入れできる。
別の着信コールを受け入れると、現在のコールは自動的にホールドになる。
任意のコール上で「ホールド中止」ボタンを押すと、その他のコールは自動的にホールドに移行する。
同時に存在する処理可能な着信コールの数は、ステータスディスプレイ(54)のスペースを利用して設定される。それは、2つのコール未満にはされない。
現在のコールの数が処理可能な数を超える場合、その他の着信コールは、
a)ビジートーンを発生させ、又は、
b)ボイスメールに直ちにフォワードされ、
c)設定された転送番号に直ちにフォワードされ、
d)記録メッセージを送られる。
「コールフォワードビジー」設定が、ユーザによって定められる。
着信コールが受け入れ限界内であって、(設定自在な)時間間隔内で応答されない場合、コールは、
a)ボイスメールにフォワードされる。
b)以前に設定された転送番号にフォワードされる。
c)記録メッセージを送られる。
「コールフォワードノーアンサー」設定が、ユーザによって定められる。
コール転送−ユーザは、どんなコールもその他の番号に容易に転送できる。転送機能は、コールをホールドして、新しい番号にダイヤル可能である。鳴り響くトーンが聞こえると、ユーザに、転送を完了するオプションが与えられる。また、ユーザは、新たな番号と通話して、その後、転送を開始すること、又は、会議コールの全て(3つの)パーティを初めて合わせることの何れか一方を行う。後者の場合、その会議コールを抜け出す機能が、ユーザに提供される。コールした端末から、応答が、又は直ちにボイスメールが送られない場合には、ユーザに、元のコールに戻るオプションが与えられる。
コールフォワード−予め設定された番号に着信コールを自動的にフォワードするようにフォンを設定できる必要がある。コールフォワードは、
a)無条件であり(unconditional)、
b)ビジーの場合にフォワードし、
c)応答がない場合にフォワードする。
会議コール−ボイスコールが最初であるか否かに拘わらず、オーディオのみの会議で会議コールが可能である。少なくとも3つのコールで、即ち4方向の会話で、会議を開催可能である。常に1つの会議をサポートすることのみが要求されるが、やはり、コール待ちについて先に説明したように、もう1つの着信コールを受け入れ可能であることも要求される。プロトタイプでは、特定の会議への1つの着信コールを受け入れることのみ可能であって、即ち、ビデオフォンではないコールに外部ブリッジが必要であってよい。
着信コールステータス表示のオプションによって、ユーザは、会議接続にコールを加え、又はそれから除去できる。
着信又は発信コールであるか否かに拘わらず、コールを会議に加えることが可能である。
遠隔の会議ユーザがコールを切った場合、そのコールの行程は自動的にクリアされる。
コールは、ハンズフリーにされるか、ハンドセットを用いて行われる。ハンドセットを持ち上げることで、コール中でないならばダイヤルパッドが使用可能となり、オーディオがハンドセットに繋げられる。オンスクリーントーンのダイヤルパッド(即ち、数字「1」から「0」と「★」及び「#」)が必要とされる。さらに、ポーズボタンが設けられて、(PABXと通じるために(但し、ゲートウェイ(70)がこの要求を排除するようにプログラムできる場合を除く))ダイヤルされる文字列にポーズを挿入可能となる。+キーが加えられて、+記号は、そのロケーションについてインターナショナルなアクセス文字列に自動的に変換されるように配慮すべきである。
入力エラーを修正するキー(例えば[バック]キー)及び入力をクリアするクリアキーも必要とされる。[バック]キーを短押しすると、最後に入力された番号が除去されて、長押しすると、番号の除去が継続されて、終わると番号のレジスタがクリアされる。
番号表示は、自動的にローカルな番号フォーマットに変換される。[これには、国ごとにスタイルが異なるので、ユーザが動作する国を選択する必要がある。また、インターナショナルコードが入力される場合には、そのコードは、番号の残りの部分をフォーマットする基礎として用いられる。]
トーン番号パッドを用いて機能を選択するサービスに接続される場合、オンスクリーンのキーパッド、又はハンドセットのキーが用いられる際に、正しいトーンが、そのサービスの指示にて生成される。ダイヤルパッドは、コールが如何様に開始されるかに拘わらず、この機能を与える。
リダイヤル−適当に特定されるファンクションを一度タッチすると、最後にダイヤルした番号をリダイヤルできる。
オートリダイヤル−例えば、[リダイヤル]ボタンを一定時間そのままにしておくと、オートリダイヤル機構が動作を開始する。先の試みが、試みた回数ビジー信号を返す場合、リターンオートリダイヤルは、自動的にコールを繰り返す。
キャンプオンビジー(CAMP ON BUSY)−それをサポートするデバイスにコールをする場合、「キャンプオンビジー」機能が利用される。コールされたパーティがコールに出れるようになると、キャンプオンビジーは、ユーザにコールバックする。コールされた番号がキャンプオンビジーをサポートできない場合、メッセージが生成されて、「このサービスは利用できない」旨が述べられる。
ユーザがビデオフォン(15)にログオンしていない場合、適当なログオン画面を表示可能である。
頻出する失敗着信・送信コールのログは、統合されたダイヤル画面にて適当なビューで表示される。「リダイヤルした最後の番号」の設備にアクセスする1又は2回のタッチが、常にダイヤルスクリーン上で行える。さらに、これらのログの記述が以下にされている。
ビデオフォン(15)端末で利用できる機能のフルセットにアクセスするためには、ユーザは、端末にログインしなくてはならない。ログイン画面が出されてユーザは名前とパスワードを入力する。これは、ネットワーク(40)への通常のアクセスで名前とパスワードを入れるのと同様に行える。ビデオフォン(15)端末は、それ故に、サイトのユーザ認証サービスを利用するであろう。ビデオフォン(15)がこれらの認証サービスを利用できるように、IT作業者が設定可能とするのに必要な画面が出される。ユーザを同定する別の方法は、例えば、スマートカード又はIDフォブを用いることである。ユーザには、ビデオフォン(15)端末にログインする前に、PC(68)に既にログオンしている必要はない。
複数のユーザが、1つのビデオフォン(15)にログオンでき、鳴り響く着信トーンは、各ユーザについて異なるようにできる。また、着信コールの表示は、コールしているパーティの名前に加えて、コールされたパーティの名前を特定する。複数のユーザが1つのビデオフォン(15)にログオンする場合、コールをフォワードする機能の全ては、コールの届け先であるユーザに特定されている。
ユーザが既に自分のPC(68)にログインしている場合、ビデオフォン(15)へのログオン行為により、ユーザがログオンしたPC(68)と、このことをPC(68)から確認するビデオフォン(15)端末との間で連関が生じる。ユーザは、複数のビデオフォン(15)端末に同時にログオンできる。動作中のビデオフォン(15)は、そのユーザへのコールが最初に応答されるものである。
ホームページ画面は、(フルスクリーンモードを除いて)全ての画面が見られるステータス領域を含んでいる。ステータスは、ログオンしたユーザの名前、又は「ログオンしているユーザがない」旨を含んでいる。また、ユーザの「プレゼンス」状態、ビデオ及びオーディオ送信用のアイコン、ボイスメール「メッセージ」表示、及び日付がある。
ユーザのボイスメールシステム(10)に聞かれていないボイスメールがある場合、「メッセージ」表示は、明るくされて、点滅する。表示器を押すと、ボイスメール操作画面が立ち上がる。
日付領域をタッチすると、カレンダー機能にアクセスできる。
ホームページにはコントロールバー領域が設けられて、この領域は全ての画面に渡って視認される(フルスクリーンモードを除く)。
コントロールバーは、最も頻繁に使用されたコントロール機能への直接的なアクセスを可能とし、その他全ての機能へのアクセスも可能とする。アイコンはボタン上で使用されて、また、テキストは、機能の目的を強調するために用いられる。
また、制御パネルは、マイクロホン、カメラ及びスピーカ(64)の統括的な制御をする。制御では、それらの動作状態が、例えばオン又はオフが、そして使用可能なアイコンの場所が明確に示される。
自己の画像が利用でき、カメラで撮影された画像と、アクティブコールの終端で視認できるその部分の両方とが示される。自己の画像をオン・オフすること、そして、常時オンであるか、アクティブコールが確立すると一度だけオンになるかを決定できる。
スクリーンのメインビデオ領域にて、常時、即ち、コール中の場合又はコール中でない場合等にて、カメラの画像を表示可能である。その画像は、1つのビデオコールに対応するものであって、その他のビデオ表示上にオーバーレイする。ビデオのフルスクリーンバージョンを表示可能である。これは、デジタルミラーと考えることができ、カメラが表示する又はしている画像に彼/彼女が満足していることをユーザに確認可能とする。
診断目的では、エンコード及びデコード後にユーザが画像を見られることが望ましく、これによって、ユーザは、離れた所で見られることになる画像の質を把握できる。このモードがサポートされると、カメラの画像と、エンコード、デコードされた画像とが並べて表示される。コンタクト情報に関する画像として用いるために、ユーザは、自己の画像をキャプチャできる。
ホーム画面の大部分は、統合されたダイヤル機能に割り当てられる。4つの主たる補助機能は、スピードダイヤル表示、ディレクトリアクセス表示、ダイヤルパッド、及びコールログへのアクセスである。ダイヤルパッドと、コールログへのアクセスとは、使い易さと両立した最小限度の表示領域を占めており、スピードダイヤル/コンタクトページに利用される領域が最大にされる。スピードダイヤル領域が優先して詳細にわたっており、主な補助機能の全てについて共通した要求は、スピードダイヤルの下のみで詳細にされており、その他の3つの機能には黙示的に含まれる。ダイヤル領域の機能は、コールがなされる相手であるユーザを選択する。
スピードダイヤル領域は、ダイヤルスクリーンのその他の要求に合わせて、可能な限り大きくできる。20を超えるスピードダイヤルのロケーションが適切である。各ロケーションは充分に大きく、そのロケーションに格納される人物の詳細な情報が、通常の動作におけるスクリーンからの距離、例えば3フィートにて非常に読み易いようにされる。
スピードダイヤルロケーションに格納されたユーザの情報は、人物名を、知られているならば「プレゼンスステータス」を、そのスピードダイヤルが選択されている場合はコールされる番号を、ユーザがビデオコールをサポートしているか否かを示すアイコンとを含んでいる。また、詳細情報には、ビデオの種類が、例えば、ビデオフォン(15)、互換性のあるMPEG2、H261等が含まれる。
その領域には、クリア領域が設けられており、このクリア領域は、コールを開始する際にタッチされる。使用されるならば、親指の爪の絵が含まれる。長い名前(即ち、スピードダイヤルボタンに割り当てられたスペースに納まらない名前)を処理する方法が提供される。
標準的なインターナショナルフォーマット、即ち「+国コードエリアコード番号」における通常の電話番号は、この番号にコールするのに必要な外部アクセスとインターナショナルアクセスコードとに自動的に変換される。
スピードダイヤルページ上にて、人物に関するコンタクトの完全な詳細が利用できる。コンタクトの詳細では、ユーザがコールできる全ての番号が示されて、スピードダイヤルページで用いられるデフォルト番号として、これらの番号から1つの番号を選択する手段がもたらされる。そのコンタクトページへのこのリンクを用いて、そのユーザの別の番号を選択してダイヤルできる。
ユーザ情報は、その人物に関するつい最近のコール履歴を含んでおり、例えば、コール履歴は、失敗着信コール、送信コールの何れか一方である最後の10コールである。「ラストコール」情報のみを提供することは、受け入れ可能な最小の機能であろう。
スピードダイヤルエントリに関してコンタクトの詳細を編集し、及び/又は、スピードダイヤルページに新たなコンタクトエントリを作成することが可能である。コンタクト画面、ディレクトリ画面、又はコールログ画面からスピードダイヤルページにエントリをコピーできる。スピードダイヤルページからコンタクト画面又はディレクトリ画面にエントリをコピーできる。スピードダイヤルエントリを削除すること、又はそのエントリを別のコンタクトページに移動することが可能である(即ち、コピーとオリジナルの削除)。
スピードダイヤルページ上にてユーザの掲載を制御可能である。また、ある方法(カラーコーディング)で、スピードダイヤルユーザの様々なクラスを、即ち、ビジネス、家族、仲間、ベンダー、顧客を区別することが可能である。スピードダイヤルページは、コンタクト情報におけるその他の複数のカテゴリからの名称をかなり含んでいてもよい。自動認証のある種のフォーム、例えば、姓・名・会社や姓・名・会社の後にクラス等のフォームが用いられる。
ユーザのグループを、1つのスピードダイヤルエントリとして定義できる。それは、グループのサイズが最大会議コールのサイズに限定される場合に受け入れられる。スピードダイヤルページからディレクトリビューを選択可能である。ディレクトリビューは、スピードダイヤルページと同じ画面領域を占める。ビデオフォン(15)がアクセスするオンラインのディレクトリの範囲から選択が可能である。デフォルトは、アウトルック及び/又はロータスノーツのディレクトリであって、それらは、ユーザの主なコンタクトの詳細を含んでいる。選択されたディレクトリの名前は表示される。
アウトルック又はノーツのコンタクトリストにおいてユーザによって確立されたカテゴリーは、選択時に利用できる。カテゴリの数が表示領域に合っていない場合、ボタンが設けられて、リストを、スクロールアップ又はスクロールダウンする。リストは、アルファベット順に整理される。
スピードダイヤルカテゴリは、スピードダイヤルページに配置されるカテゴリである。スピードダイヤルページが一杯になって、もはやこのコンタクトカテゴリにさらに名称を加えることができなく、それらが既存のエントリに取って変わらない場合、何らかの表示がされる。最近のコール順にスピードダイヤルエントリを順序付ける機能があり、即ち、最後に用いられたスピードダイヤルエントリは下側に配置されるであろう。これは、どのエントリが削除される最適の候補であるかを見るために用いられて、より使われる番号を入力可能とする。
最小限のユーザ入力で、選択されたカテゴリからエントリを容易に見つけて選択できる。エントリ選択機構は、比較的短いリストと、非常に長いリスト(10000の名前)とについて働く必要がある。その機構は、検索されるテキスト文字列を入力できる必要がある。提示されたデータのソート順を、性、名又は組織で選択できる必要がある。入力エラーを修正して、全検索を迅速に再開する手段がある。
検索キーの順番は重要であって、ユーザが変更できることが好ましい。言い換えると、例えば、最も左の検索キーを押し続けることにより、ユーザは、姓、名又は会社(又は、属性の拡張リスト。これは、例えば、特定の部署又は特定の場所にいる者、例えば”韓国にいる者”を見つけるために使用される)による検索をすることを選択できる。第2キーは、その後、第1キーの検索の限定を行い、以下同様となる。よって、複数のキーが、会社、姓、名と設定される。例えばマルコーニの場合、姓についてマルコーニをアルファベット順に検索するユーザ検索が行われる。各ソートカテゴリが選択された場合、そのカテゴリフィールドの同じ値を用いて、エントリの下位の順序付けが黙示的になされるのは明らかである。姓が選択される場合、黙示的な下位の順序は、名そして会社であり、会社が選択される場合、黙示的な下位の順序は、姓そして名であり、名が選択される場合、黙示的な下位の順序は、姓そして会社である。
コールログ画面は、送信、着信及び失敗というコールの3つのカテゴリの最近のエントリを表示する。選択されたカテゴリは明瞭に示される。加えて、「頻出する」カテゴリがあって、該カテゴリは、任意のタイプの最近のコール(200未満)について、頻繁に用いられる番号をリストアップする。コールダイヤル画面からダイヤルパッドにアクセス可能である。かなりの量のコールログデータの処理をもたらす値の解析は保留される。
最低の場合でも、「メッセージ」がタッチされて、ユーザへのボイスメールシステム(10)への接続がなされると、このユーザのボイスメールが入力され、ダイヤルパッドが表示されて、フォンのキーが通常押されるようにボイスメールが制御される。「ボイスメール」画面の大部分にはボタンがあって、メールシステム(10)の各機能にアクセス可能である。アクセスされる機能には、例えば、次メッセージ、先メッセージ、メッセージ再生、メッセージ転送、メッセージ応答、コール送信等がある。各ファンクション内のキー押しと等価な全てのものにもアクセス可能であって、記録開始、記録停止、記録レビュー、記録削除等がある。全てのファンクションはボタン上にあり、各々のDMFトーンに変換される。
「フォワード」番号又はどのボイスメールコマンドも、ユーザの番号リストが入力される必要があり、スピードダイヤル又はディレクトリ画面ビューから選択できる。その選択によって、ユーザの番号の適当な部分が自動的に挿入される。これは、ボイスメッセージをグループにフォワードするのに特に有用であろう。ユーザは、ビデオフォン(15)上にて日時を設定可能である。適当なネットワーク(40)サービスによって、日時を自動的に設定できるのが好ましい。
カレンダ機能が利用できて、ユーザのアウトルック/パーム/ノーツスケジュール/カレンダアプリケーションと統合される。単に、日、週又は月単位で、(アウトルック又はパームのスクリーンで)任意の日付の予定が見られて、アウトルック又はパームデータベースを介してのみ可能な変更と新たなエントリとが見られることが最小限要求されるであろう。
かなり多くのユーザが自分のカレンダを保持しておらず、実際には自分の机にPC(68)がないであろうが、情報を見る必要がある事態は起こり得る。画面のステータス部にあるユーザステータス領域にタッチして、ユーザは自己のステータスを設定する。ユーザには、選択可能な一連のステータスオプションがあり、i)空き、ii)ビジー−コール中であり、別のコールが受け取れない、iii)接触禁止−コール中ではないが、中断可能ではない、iv)5分内に戻る、v)オフィス外、vi)休日を含んでいる。
ビデオフォン(15)端末に1つのコールがある場合、1つの着信ストリームから、会議における最大数のストリームまでがサポートされる。ビデオ会議では、端末は、1つの会議コールの部分として、他のパーティへの少なくとも4つの接続をサポートする。最大サイズのビデオ会議コールがある場合さえも、少なくとも2つの独立したオーディオのみのコールを受け入れ可能であり、オーディオコールは会議(consultation)ホールド転送され得る。ビデオフォン(15)は、少なくとも3つの「コール状態(instance)」を同時に、つまり、独立したコールを最大で3つまでサポートできる。1つのコールのみがアクティブにできる。つまり、コール制御は、1度に、1つのコールのみに行われる。1を超えるコールが受け入れ可能である。つまり、ユーザのオーディオ及びビデオは、アクティブであるか否かに拘わらず、受け入れられた各コールに送信されている。オーディオ及びビデオがホールド中のユーザに送信されず、そのユーザから送られるオーディオ及びビデオも止められている場合、進行中のコールはホールドされてよい。
着信コールのステータスは、コントロール表示領域に示される。コール自体と、インコール制御とがディスプレイ(54)のメインセクションに示される。
コールステータスは、以下の通りである。
i) 着信コール。
ii) 受入及びアクティブ−ユーザのオーディオ(ビデオコールの場合はビデオも)は、種々のミュート制御を受けて、このコールに接続され、コール制御がこのコールに適用される。
iii) 受入及び非アクティブ−上記と同様であるが、コール制御はこのコールに適用されない。
iv) 受入及びホールド−ユーザのオーディオ(ビデオコールの場合はビデオも)は、このコールへ送信されていない。
v) 受入及び転送。
コールステータスは、各コールについて示される。受け入れられた1つのコールのみがアクティブとなる。受け入れられたコールは、そのコールに関連したコール表示の領域を又は制御パネルのコールステータスを、タッチすることでアクティブにされる。先のアクティブコールは何れも、アクティブに設定されない。2度目のタッチは、アクティブ状態をオフにする。着信コールの表示は、コールがビデオ接続を申し出ているか否かを示す。表示がないことは、オーディオのみのコールを意味する。着信コールの表示は、その着信コールに関するパーティの名称を示す。これは、直ちに、ユーザが1対1でコールされているか、又は会議への参加を勧誘されているかを示す。
ユーザは、以下のオプションを用いて着信コールを処理する。
i) 音声のみのコールとしてコールを受け入れる。
ii) ビデオコール(音声を含む)としてコールを受け入れる。
iii) ボイスメールを送る。
ビデオフォン(15)端末を設定して、サポートされるコールの最大数まで、着信コールに自動応答できる。申し出があると、自動応答は、オーディオ及びビデオ接続を生成する。 コールが一旦起こると、ユーザステータスは、自動的に「インコール」に変化する。アクティブなコールがないと、ユーザステータスは、前の状態(一般的には「空き(available)状態」)に戻る。
ユーザは、コールユーザデータも配布されるか否かを設定可能である。ユーザが、既に1又は2以上のコールを受け入れている場合、及び、全てのコールがホールドである又はアクティブでない場合、このコールは、受け入れられると新しいコール状態を生成する。受け入れられたがアクティブでないコールは全て、この新しいコールをユーザが扱う最中に、ユーザの見聞きを継続して行う。受け入れられたコールの1つが受け入れられてアクティブとなる場合、新しいコールがそのコールに加えられる。コールが受け入れられると、そのコールの全てのパーティは、新しい呼出し側にとって、会議の参加者となる。
ある時間(10秒より大きい)の後、ユーザがコールに出ない場合、コールは、「フォワードオンノーサンサー(Forward on No Answer)」設定で定められたように、自動的にフォワードされるであろう。上述のように、フォワードは、コールの宛先であるユーザに特定される。ユーザステータスに「ドゥノットディスターブ(Do not disturb)」若しくは「ビジー(busy)」が付される場合、又は、最大数のコールが処理されている状態で「ビジー」状態が設定された場合、コールは、「フォワードオンビジー」及び「フォワードオンドゥノットディスターブ」設定で定められたように「直ちに」転送される。実施されるならば、「ショウフォワーデットコール(show forwarded calls)」設定で修正される。
「ショウフォワーデットコール」設定を用いて、着信コールが転送される前に、ユーザがある時間(5秒より大きい)の間、着信コール表示を見ることを選択できる。(これは、コールを受け取ることを望まない場合に、ユーザに対して、コールへの積極的な動作が要求されるのではなく、動作が必要とされないことを意味する。)これは、ビデオフォン(15)が既に最大数のコールを処理していることによってビジー状態が生じている場合には、これは機能しない。
コールと共に送られる(非常に短い)テキストメッセージを作成する能力は、コールの重要性及びそれがどの程度の長さであるかについて、さらに情報を運ぶ有用な方法である。メッセージを作成して送信コールに加える要件は、以下に説明される。存在する場合、着信コールテキストメッセージは、着信コールに関連して表示される。ディスプレイ(54)は、複数の着信コールが同時にある場合に、テキストメッセージの表示に対処する。また、テキストメッセージは、着信又は失敗コールログに格納される。
コールパラメータネゴシエーションは、ネットワーク(40)のポリシーパラメータと現在のネットワーク(40)利用内にてコールを確立するのに要するものに制限される。設定により、ユーザは、その他のビデオフォン(15)端末に対してコールの選択を明示できて、例えば、常時ビデオを提供すること、決してビデオを提供しなこと、ビデオを提供することを希望しているか否かを各コールに尋ねることが可能になる。
キャンプオンアベイラブル(Camp on Available)は、他のビデオフォン(15)のユーザへのコールについてサポートされる。これは、ユーザの状態が「空き状態」に変化すると、ユーザにコールを開始する。コールされたユーザがグループである場合、グループの全てのメンバーが「空き状態」である場合にのみ、コールが開始される。
会議コールでは、スピードダイヤル又はディレクトリリストのある場所が人物のグループを示している場合、その各々がコールの参加者となる。この機能を実施するための推奨される処理は、各コールを順番に行い、直ちにそのコールが会議に加えられるべき旨の動作要求確認をするものである。これによって、コールがボイスメールに直行する場合、エスケープルートが与えられる。最初の呼出し側の動作が完了すると、つまり、コール中であるかコールが拒否されると、次の番号が処理される。
半二重である送信コールを、言い換えると、コールされたパーティからオーディオ及び/又はビデオを要求する送信コールを生成できるが、あるタイプのコールではどちらも送信しない。それは、プルモードである。同様に、プッシュモードを生成可能である。プッシュモードでは、送信コールは、オーディオ及び/又はビデオを送るが、如何なるオーディオ又はビデオをも要求できない。このモードは、無人端末に、又は会議にて消極的な役割のみをするユーザの端末に、選択的にコンテンツを配信するために使用されてよい。
スピーカ(64)、ハンドセット及びヘッドセットのボリュームは、全て個別に調節される。スピーカは、オン・オフされる。スピーカをオフにするとマイクロホンがオフにされる。ステータス表示は、スピーカ及びマイクロホンの状態を示す。
マイクロホンは、オフにでき、オンに戻すこともできる。ステータス表示は、マイクロホンのミュートの状態を示す。
カメラは、オフにでき、オンに戻すこともできる。ステータス表示は、カメラのミュートの状態を示す。
インコール制御は、アクティブなコールのみに働く。受け入れられたコールは、アクティブでない場合に、進行中のコールのステータス表示を制御パネルにてタッチするか、特定のインコール制御ファンクション領域を除くコール表示領域の何処かをタッチすることで、アクティブにされる。現在アクティブであるその他のコールは、非アクティブにされる。アクティブなコールは、同じ領域を続いて押すことで非アクティブにされる。制御によって、アクティブなコールは切られる。会議コールでは、それによって、コール状態の全ての要素がクリアされる。
コールは、会議コントロールに受け入れられて、アクティブとされて機能する。会議コントロールをタッチすると、現在のアクティブコール状態を、アクティブにされる次のコールに加える。会議コントロールは、再度押されて非アクティブにされるまで、又は別のコールがアクティブにされるまでの何れかの場合にて、コールがアクティブであることを示す。現在アクティブである全てのコールが会議コール状態に加えられた後、コールは1つの会議コールになり、会議コントロールのアクティブ表示は消える。再度述べると、会議は、他のコールが加えられるコールを選択し、その後、そのコールに加えられるコールを選択する。
会議コールに繋がれたあるパーティを終了する方法は、そのパーティがコールを切ることである。様々な理由から、ユーザは、コール状態の各部分を独立に制御したいと希望するだろう。これは、脱会議(de-conference)能力によって実現できる。例えば、3秒より長くコール状態をタッチすることで、サブメニューが表示される。サブメニューでは、コール状態の個々のメンバーを特定でき、脱会議について選択され得る。このコールは、その後会議から除去されて、別個のコール状態として確立される。それには、通常の全ての制御が適用されて、特にクリア可能である。
転送ファンクションはアクティブコールを転送する。転送コントロールがタッチされると、統合されたダイヤル画面が表示されて、アクティブコールがホールドされる。しかしながら、それはインコール動作に関わっていることが表示されている。転送コントロールは、再度押されて、転送がキャンセルされるまで、又は、ユーザがコールの転送を希望する番号のダイヤルが選択及び押されるまで、コールがアクティブであることを示す。
送信コールが一旦開始されると、転送コントロールは状態の変化を表示し、コントロールがタッチされると、「ブラインド」転送が起こって、コール状態が画面から除かれる。その代わりに、コール先の番号が応答するまで、ユーザは待ってもよく、コール先の番号が応答する時点で、新しいコール状態が生成されて、ユーザはコール先のパーティと会話ができ、転送ファンクションは状態を再度変化させる。そして、それを再度押すことで、両方のコールの転送及び終了が完了する旨が表示される。別の方法では、転送されている呼出側との会話に戻って、転送処理が再スタートされ、又はコールが終了する。転送は主要な機構であり、それによって、「アドミン(admin)」はコールをセットアップし、それを「ボス(boss)」に転送する。この場合、転送されたコールをアドミンが「聞き」続けることが不可能であるのは重要である。これは、安全な環境には特に重要である。
ホールドコントロールをタッチすると、アクティブコールはホールドされる。ホールドでは、送信ビデオ及びオーディオストリームは中断されて、ホールドされている旨の表示が離れた端に与えられる。着信オーディオ及びビデオストリームはもはや表示されない。ホールド状態は、コントロールバー上でコール状態表示上に示される。何らかのコールがホールドされている場合、ホールドコントロールはホールドがアクティブである旨を表示する。アクティブコールがホールドである場合にホールドを再度押すと、ホールドが解除されて、コールは表示された状態に戻る。
メイン制御パネルを制御することで、ホーム画面を立ち上げて、その他の全ての非コールファンクションにアクセス可能となる。メインが選択された表示がされる。メインが再度押されると、現在のコールの表示が再度行われて、メインが選択から外される。受け入れられて表示されたコール内のパーティの各々について、及び表示された各コールについて、分離コントロールが適用される。個々のユーザの各々から送られるオーディオのボリュームを調整することが必要とされる。画面に表示されたオーディオ及び/又はビデオを独立してミュートすることが可能である。ステータスインジケータがあって、オーディオ又はビデオミュートがオンであるか否かを示す。
2以上のコール状態が常に表示できる場合、例えば、2人の他人の会議コールに加えて1人の他人への新たなコールがある場合、完全なコール状態についてオーディオ及び/又はビデオをミュートすることが可能である。例えば、第2コールで話している間に、オーディオについて2つのパーティの会議をミュート可能である。
ビデオをサポート可能なオーディオのみの接続上で、ビデオをリクエストすることが可能である。ビデオリクエストの受け入れ又は拒絶も可能である。接続が合意されるとビデオ接続が確立される、設定ページアイテムによって、ユーザは、ビデオリクエストを常時受け入れ、又は常時拒絶可能である。
各接続について、搬送(bearer)チャンネルパラメータを、つまり、ビデオの着信及び送信エンコードレートを、オーディオもあるならばそのレートを表示できる。コール中では、制御はアクティブコールのみに働く。受け入れられたコールは、アクティブでない場合、アクティブにされる。
どのユーザも「搬送チャンネルクオリティモニタ」を利用可能である。このモニタは、携帯電話の信号強度メータのようなビットであって、例えば、オーディオ及びビデオチャンネル上でエラー又は損失パケットがない場合には、100%のグリーンバーとなり、損失レート又は待ち時間が所定のレートに達すると黄色のバーとなり、より高いレートに至ると赤いバーとなる。このタイムフレームにおけるエラーがユーザのビデオに影響するので、時間積分は短く、例えば50ミリ秒とされる。従って、例えば、受信側でビデオのアーチファクトが見られて、同時にモニタバーが黄色又は赤に移動する場合、受信側は、ネットワーク(40)の混雑が生じていることを知る。
コール内で、ビデオエンコードパラメータを変更する、つまりエンコードレート増加又は減少することをリクエストできる。このリクエストを受け入れ又は拒否することが可能であり、送信ビデオレートを変更する方法が与えられる。ビデオフォン(15)は、全ての参加者に対して1つの送信エンコードレートを生じる。それは、受信ストリームの全てにて異なる受信レートを受け入れ可能である。
サイドバーへのリクエストが可能であり、そのリクエストを受け入れ又は拒否することも可能である。受け入れられる場合、サイドバーは両方の参加者から他の全ての者へのオーディオストリームを切る。これによって、彼らはプライベートな会議ができ、その一方で、彼らは、全ての議論を聞き、さらに、全ての参加者を見続け、それらに見られ続ける。ビデオ及びサイドバーリクエストの両方の方法で短いメッセージを送ることができる。
コールが着信コールであるか送信コールであるかに拘わらず、ビデオビューへのスクリーン移行はスムースでなくてはならない。オーディオは、ビデオを予想してよい。この移行がされ得るまで、ビデオは表示されるべきではない。(即ち、ビデオへの移行において、ジャンピ(jumpy)な画像、半分しか形成されていないフレーム等があるべきではない。) ユーザのディスプレイ(54)のビデオ画面への移行は、コールが「進行中」である後にのみ開始し、コールを開始する時点では行われない。ユーザから送られるビデオの表示は、ユーザのディスプレイ(54)に割り当てられた表示領域を最大限利用する。インディスプレイコントロールは、この1つのコール状態の1人のユーザの表示を、フルスクリーン表示に変換する。「フルスクリーン」表示の内の何処かをタッチすると、標準表示に戻る。既に言及したインコールコントロールに加えて、ユーザ名が表示される。ディスプレイ(54)及びコントロールパネルのコール状態は、コールがアクティブか否かを、即ち、インコールの一般的な制御が動作するか否かを示す。あるコール状態が起きていると、そのコール状態を押すことで、又はインコールの特定のコントロール領域から離れたメインディスプレイ(54)上の何処かを押すことで、アクティブがインアクティブとなる。
1つのコール状態であって2つのパーティのコールからの移行はスムースであって、第2コールが「進行中」になると開始される。ディスプレイ(54)は、ユーザのディスプレイ(54)に割り付けられた表示領域を最大限に使用する。必要ならば、ビデオは変倍よりも各縁部をクリップされて、使用領域に合わせられる。フルスクリーン表示を2又は3以上にする要求はない。既に述べたインコントロールに加えて、ユーザ名が各パーティに表示される。両方のパーティが単一のコール状態の部分であることが示される。ディスプレイ(54)及びコントロールパネルのコール状態は、コールがアクティブか否かを示す。パーティがさらにビデオコールに加わるにつれて、着信ビデオは使用領域に合うように、その都度クリップされる。
共に単一パーティコールである2つのコール状態では、これらユーザ各々への2つの別個のコールがあって、双方が表示される。オンスクリーン表示及びコールコントロール表示は、独立した別個の2つのコールがあること、さらに、どれかがアクティブであるか否かとを明確に示す。コールの何れか一方がホールドにされる場合、そのコールはもはや表示されず、ディスプレイ(54)は、単一コール状態の単一コールの表示に戻る。
ユーザ領域には、上記に記載されたものに加えて、以下の組合せの何れかが表示される。
各々が単一パーティのコールである、4つのコール状態。
あるコールが2つのパーティであって、その他が単一パーティのコールである3つのコール状態。
1つのコールが最大で3つのパーティのコールであるか、2つのコールが2つのパーティのコールである、2つのコール状態。
「CNN」スタイル表示要求は、上記した単一コール状態の単一コールの要求であって、フルスクリーン表示が可能である。また、画面の半分に「CNN」スタイルコールを表示し、残りの半分を1又は2つのユーザ表示領域として使用可能である。後者は、2つの独立したコール状態、又は、パーティが2つである単一のコール状態である。
様々なレベルで音声及びデータの暗号化をすることが可能である。診断、テスト、測定及び管理機構にアクセスすると、SMF(simple management framework)が用いられる。言い換えると、アクセスは、3つの方法、SNMP、ウェブ及びクラフト(craft)インターフェイスを通じて、全ての機能を可能にする。ビデオフォン(15)端末は、遠隔管理可能であり、オンサイトのIT専門家が日々の動作を見ることや、ソフトウェアをアップグレートしてバグを修正することは不要である。障害診断も遠隔で可能であって、問題が、ユニットハードウェア、ユニット設定、ユニットソフトウェア、ネットワーク(40)又はネットワーク(40)サービスに関連しているか否かを判断できる。管理では、IP接続が仮定され得るが、ビデオフォン(15)への比較的低帯域幅での接続である必要がある。
通常動作下では、電源が入れられると、ビデオフォン(15)は、ハードウェアシステム(10)テストを短縮バージョンで行う。これが不合格であると、ビデオフォン(15)は、メインスクリーンにブート失敗メッセージを表示する。端末は、より長いハードウェア診断モードに強制的にされ得る。これは、キーボードをUSPポートに取り付けることで、又は、ユニットの電源を入れてタッチスクリーンの右上隅を押すことでなされる。このモードによって、基本的なオペレーティングシステムとさらに強力な診断にアクセスして、ハードウェアが不合格であるか否かを判断可能となる。
一連の単純なテストを含めることができ、これによって、ビデオフォン(15)がブートアップテストをパスするが正しい機能をユーザに提供していない場合に、ユーザは活動可能である。端末には、ローカルキーボード(及びマウス)について技術的インターフェイスが設けられており、診断ユニット又システム(10)の問題を支援する。これによって、オーディオ及びビデオ等の様々な診断にアクセス可能となる。
遠隔制御下で、ビデオフォン(15)端末のソフトウェアの新たなバージョンを安全にダウンロード可能である。安全については、ダウンロードされたバージョンに不備が起こる場合は、ローカルな介入(即ち、誰かがCDを挿入すること)を行うことなく、先のバージョンに戻すことが可能である。特定のビデオフォン(15)端末上のソフトウェアのバージョン番号と、ユニットのハードウェアのシリアル番号と、アセンブリ修正番号と、キーサブアセンブリのシリアル番号及びアセンブリ修正番号とを、管理インターフェイスを通じて読み出しできる。システム(10)がクラッシュした場合、ビデオフォン(15)は、そのクラッシュの診断を支援する情報を格納し、又は情報の格納を完了している。ビデオフォン(15)がリブートされると、この情報は解析のためにリモートサイトからオンラインで回収できる。
ビデオフォン(15)は、電源入力からの全ての動作、イベント及び状態の変化のランニングログを保持する。ログは、記録装置がこの機能に割り当てできる限りにおいて保持される。少なくとも1月分の動作量について格納可能であるべきである。このデータには、多数のカテゴリが含まれており、例えば、安全カテゴリは、ユーザがコールした番号等のユーザデータを含んでおり、ユーザによってのみ公開可能である。コール数、コール状態(即ち、コール状態及び状態当たりのエンドポイントの数)、エンコーダ(36)及びデコーダ(34)の特性、搬送チャンネルエラーレポート等のような一般的なデータは、あまり慎重を期するデータではない。システム(10)レベルの問題を診断し、一連のイベントを生成することを助ける一手段として、キーが押されたことを毎回記録することが可能である。
ビデオフォン(15)は、IPレベル及びSIPレベルの両方で、コントロールプレーンレベルでエクスチェンジを、離れた遠隔端末(ビデオフォン(15)端末に遠隔接続されたラインモニタを有する同等物)にコピーする。端末の管理は、多数のパラメータ、例えばネットワーク(40)のクオリティを、モニタする。閾値を設定して、これらの閾値に到達した場合に警告を発することが可能である。ATMインターフェイス及びイーサネットインターフェイスの両方は、(例えばrmonと同等な)一般的な測定をする。測定は、ビデオフォン(15)で利用される。ビデオフォン(15)は、1又は2以上のネットワークマネージメントシステムに警告を送ることが可能である。
オーディオミキサ
オーディオミキサに関して、第1ノード(80)は、オーディオストリーム及びビデオストリームを作成可能であり、クオリティオブサービス機能を有するATMネットワークの一部である。第1ノード(80)は、第2ノード(82)とポイントツーポイントコールを構成することを望む。第2ノード(82)は、オーディオ機能のみを有しており、例えば、PSTNフォンである。第2ノード(82)は、ATMネットワークの一部ではない。
ATMネットワークの一部であるSIPサーバにシグナリング情報を送って、第1ノード(80)は、第2ノード(82)へのコールの構成を開始する。該情報によって、第2ノード(82)が第1ノード(80)が始めているコールの着信先であることが、サーバに確認される。サーバは、第2ノード(82)に関するアドレス情報を有しており、第1ノード(80)から受信したシグナリング情報にアドレス情報を加えて、該シグナリング情報を、第2ノード(82)のアドレス情報と共に、ATMネットワークの一部であるオーディオミキサ(20)に送る。
第1ノード(80)を出所とするシグナリング情報を受信すると、ミキサ(20)は、この情報から、第1ノード(80)が接続を構成することを望んでいるのは第2ノード(82)であると判断する。そして、ミキサ(20)は、第2ノード(82)に案内(invitation)を送る。ミキサ(20)は、何らかの形で、例えば、T1ライン又はイーサネットのようなATMネットワークではない方法で、第2ノード(82)と通信して、その特徴と、データがそれに与えられて該データを理解するために必要な様式とに関して明らかにする。これに応じて、第2ノード(82)は、データが入力されて第2ノード(82)で理解されるのに必要な特定の様式を、ミキサ(20)に明らかにする。また、第2ノード(82)は、それにデータを送ることが可能であり、接続が構成し得ることをミキサ(20)に明らかにする。
その後、ミキサ(20)は、接続を構成する準備ができていることを示す信号を第1ノード(80)に送る。ATMネットワークの一部であるミキサ(20)は、第1ノード(80)に対して第2ノード(82)を代理し(represent)、第2ノード(82)がATMネットワークの一部であり、第1ノード(80)と類似しているというインプレッションを、第1ノード(80)に与える。ミキサ(20)は、そのネットワークの一部又は第2ノード(82)が属する接続の一部であって、第2ノード(82)に対して第1ノード(80)を代理している。ミキサ(20)は、第1ノード(80)が同じネットワークの一部又は第2ノード(82)が属する接続の一部であって、第2ノード(82)と類似しているというインプレッションを、第1ノード(80)に与える。
その後、第1ノード(80)は、データのストリーミングを開始する。該データは、オーディオデータを含んでいる。そして、第1ノード(80)は、当該技術分野で周知のように、そのデータのパケットをミキサ(20)にユニキャストする。ミキサ(20)は、パケットを受信すると、当該技術分野で周知のように、パケットのデータをバッファに格納し、第1ノード(80)から送られたパケットに関する接続を効率的にターミネートする。該パケットの送り先は、第2ノード(82)である。ミキサ(20)は、第2ノード(82)に送られた案内を通じて、データが入力されるために必要な様式を以前に知らされているので、第2ノード(82)は、そのデータを理解できる。ミキサ(20)は、バッファに格納されたデータを必要なフォーマットにして、その後、適当な時間制限下で、適切に再フォーマットされたデータを、ミキサ(20)から第1ノード(80)への新しい且つ別個の接続に効率的に送る。この方法では、実際には2つの別個の接続が含まれるが、ポイントツーポイントコールが構成される。第1ノード(80)又は第2ノード(82)の何れも、第1ノード(80)と第2ノード(82)間で所望のポイントツーポイントコールを生成するために、2つの接続が用いられていることを認識しない。同様にして、第2ノード(82)から第1ノード(80)にデータが送られると、処理は繰り返される。しかし、この場合、第2ノード(82)から送られたデータがミキサ(20)で受信された後、ミキサ(20)は、第1ノード(80)が理解可能な様式にデータを再フォーマットする。そして、ミキサ(20)は、該ミキサ(20)にてバッファに格納された、第2ノード(82)から送られたデータを、第1ノード(80)にユニキャストする。ATMではなくIPが用いられる場合、ミキサ(20)は、当該技術分野で周知のように、ユニキャストなIPパケットを第1ノード(80)に送る。
次に、別名ポイントツーマルチポイント接続として知られている、会議開催を含むシナリオが、本発明を用いて説明される。ポイントツーポイント接続を含む上述の話の続きとして、第1ノード(80)は、会議を構成する接続に、第3ノード(84)を加えることを希望する。第3ノード(84)は、ATMネットワークの一部であり、本質的に第1ノード(80)と同じ特徴を有している。第1ノード(80)は、シグナリングの案内を、会議をホストするホストノード(22)に送る。ホストノード(22)は、第1ノード(80)にすることができ、又は、別のノードにすることもできる。第1ノード(80)は、サーバを通じてホストノード(22)と通信して会議を構成し、第3ノード(84)を会議に加える。ホストノード(22)は案内を行って、ミキサ(20)にシグナリングを発するために接続を構成すると共に、第1ノード(80)とミキサ(20)間で最初のシグナリング接続を生成する。なお、該接続は、ターミネートされる。また、ホストノード(22)は案内を行って、第3ノード(84)への接続をも構成する。これは、第3ノード(84)を接続に加える第1ノード(80)からの要求に応じて行われる。ATMネットワークの一部であるノードが会議に接続されることになる各ケースでは、シグナリングはサーバを通じて進んで、当該技術分野で周知のように、適切にルーティングされる。ホストノード(22)は、ATMネットワーク内での会議接続用の典型的なホストノードとして働く。ミキサ(20)は、ATMネットワークの一部ではないが、会議接続全体の一部となるあらゆるノードを代表している。
ATMネットワーク上の任意のノードについて、接続の一部であるがATMネットワークの一部ではない如何なるノードも、ミキサ(20)は、あたかもATMネットワーク上の他のノードであるように現れるようにする。シグナリング接続は、ホストとミキサ(20)間、ミキサ(20)と(ミキサ(20)で代表される)第2ノード(82)間で構成される。それらシグナリング接続を通じて、接続における全てのノードから送られる必須情報は各ノードに送られる。これによって、それらノードは、接続における他の全てのノードを理解して通信することが可能となる。実際には、ホストノード(22)は、他の全てのノードに、これらノードの特徴に関する情報を与えるだけでなく、それらがホストノード(22)に最初に与えた情報をノードに戻す。これにより、各ノードは、基本的に自己の情報を返される。この情報が配布されると、典型的な任意の会議状態における通常のケースのように、ストリーミング情報が出される。ATMネットワークのシナリオでは、第1ノード(80)及び第3ノード(84)は、PMPツリーを用いて、パケットの情報を、互いに及びミキサ(20)にATMマルチキャストするであろう。IP環境では、第1ノード(80)及び第3ノード(84)は、ネットワーク上の全てのノードにパケットをIPマルチキャストし(ミキサ(20)は、このためにノードとなる)、接続の一部であるノードのみ、接続の一部である特定のパケット情報を理解及び使用するであろう。
ミキサ(20)は、上述のように、第1ノード(80)及び第3ノード(84)からパケットを受信して、それらをバッファに格納する。種々のノードから送られるパケットは、ミキサ(20)で受信されると再フォーマットされて、当業者に周知である一般的なアルゴリズムに従ってミキシングされ、言い換えると互いに足し合わされる。その後、所定時間にて、ミキサ(20)で再フォーマットされたデータは、当該技術分野で周知なように、第2ノード(82)に送られる。逆の場合、同様な方法で、第2ノード(82)から送られるデータは、ミキサ(20)で受信されてバッファに格納される。その後、それは、再フォーマット様式で、第1ノード(80)及び第3ノード(84)にマルチキャスト出力される。
第4ノードは、オーディオ機能のみを有しており、第2ノード(82)と類似している。そして、これは、ATMネットワークの一部ではない。第4ノードが会議に加えられる場合、ホストノード(22)は、ミキサ(20)と第2シグナリング接続を構成する。次に、ミキサ(20)は、第4ノードと別個の接続を構成し、該接続は、ミキサ(20)が第2ノード(82)と構成した接続とは異なる。ミキサ(20)は、それがサポートしているセッションのリストを保持している。対象となっている会議を含むセッションにおいて、それは、ミキサ(20)を介した2つの相互接続(cross connects)を特定する。第1相互接続は、ホストノード(22)から第2ノード(82)へのシグナリング接続を通じたものであり、第2相互接続は、ホストノード(22)から第4ノードへのシグナリング接続を通じたものである。この方法では、ホストノード(22)と同様にして、第1及び第3ノード(80)(84)は、第2ノード(82)及び第4ノードを代理する2つの別個のノードがあり、それらと通信していると信じている。実際には、ミキサ(20)は、第2ノード(82)及び第4ノードの両方を代理し、それらの各々から送られたデータを別々にマルチキャストし、この錯覚に加えて、第2ノード(82)及び第4ノードが第1ノード(80)及び第3ノード(84)と似ているという錯覚が、第1ノード(80)及び第3ノード(84)にて維持される。
ViPrシステムは、高度に発達したビデオ会議システムであり、「バーチャルプレゼンス」会議開催特性を与えるものであって、今日市販されている従来の如何なるビデオ会議システムの能力をも遙かに超えている。ViPrシステムは、ポイントツーマルチポイントなSVC(PMP−SVC)及びIPマルチキャストに依拠しており、会議の参加者間でポイントツーマルチポイントなオーディオ/ビデオメディアストリームを確立する。ViPr会議に参加しているユーザが、オーディオ及びビデオの質が今までにない会議を楽しむ間に、ViPrを用いていない他のユーザをViPr会議に加える必要がある。システム(10)は、ユニキャストな音声のみのテレフォンコール(即ち、PSTN、モバイルフォン及びSIPフォン)を、複数参加者のViPr会議に加えることを可能にする。
現在のViPrシステムは、SIPベースのアナログ及びデジタル電話ゲートウェイを通じて、電話システムをサポートする。この機能により、ViPrのユーザは、電話ユーザにポイントツーポイントコールを行うことができ、電話のユーザからポイントツーポイントコールを受信できる。しかしながら、それらによって、ViPrのユーザがテレフォンコールをViPr会議に加えることは可能とはならない。これは、テレフォンコールのユニキャスト特性と、電話ゲートウェイが、テレフォンコールをPMP/マルチキャストなストリームに変換できないことによる。ViPrのユーザが、ユニキャストなテレフォンコールをViPr会議に加えることを可能とすることで、ViPr UAMは、ViPrシステムによる電話のサポートを促進する。
この機能をサポートするために、ViPr UAMは、ViPr端末と電話ユーザ(即ち、PSTN、モバイルフォン及びSIPフォン)間でシームレスな会議機能を与える。これは、アップストリームのユニキャストなテレフォンオーディオストリームを、ポイントツーマルチポイントのオーディオストリーム(即ち、PMP−SVC又はIPマルチキャスト)に変換すること、ダウンストリームのPMP/マルチキャストなViPrオーディオストリームをユニキャストなテレフォンオーディオストリームにミキシング又は変換することに加えて、ワイドバンドの16ビット/16KHzPCMエンコーディングからG.711又はG.722に、ViPrオーディオについて、ダウンストリームのオーディオのトランスコーディングをすることによって行われる。
UAMで与えられるさらなる機能は、インターメディアゲートウェイの機能である。インターメディアゲートウェイは、IP/UDPオーディオストリームをATM SVCオーディオストリームに変換し、また、その逆の変換も行う。この機能によって、ATM環境に配置されたViPrシステムと、イーサネットネットワーク上のSIPベースのボイスオーバーIP(VoIP)電話ゲートウェイとの間で相互運用が可能となる。
UAMは、1又は2以上のViPrフォンが1又は2以上の電話ゲートウェイと共に動作することを可能にする。
UAMは、下記の構成に示すように、ユニキャストなオーディオデバイスを伴ったViPr会議コールをサポートする。
・タイプ1:1つの会議コールをサポートする。1つのオーディオユニキャストデバイスが参加者である。
・タイプ2:複数の会議コールをサポートする。各会議コールでは、複数のオーディオユニキャストデバイスが参加者であり得る。
・タイプ3:複数の会議コールをサポートする。各会議コールでは、厳密に1つのオーディオユニキャストデバイスが参加者である。
1つのユニキャストマネージャアプリケーションで、20の参加者(ユニキャストデバイスに加えてViPrフォン)がサービスされるのが好ましい。
ユニキャストデバイスは、図1に示す構成にて使用される。
図1に示すように、ユニキャストデバイスとViPrでやり取りされる全てのコールは、必ずUAMに送られる。UAMは、B2B SIP UAを行ってユニキャストデバイスをViPrに接続する。
例: POST1のユーザAは、ViPr V1のユーザBにコールする。以下の一連のイベントが起こる。
1. UD1(メディアトリックス又はあらゆる種類のユニキャストデバイス)は、User_Bへの接続のリクエストを、User_Aから受信する。
2. UD1は、INVITE(案内)をUAMに送る。INVITE内のTo field又はDisplay Nameは、コールがUser_Bへのものであることを特定している。
3. UAMは、着信コールC1でINVITEを受信する。
4. UAMは、C1のINVITEからUser_Bのsipアドレスを取り出すと共に、INVITEをV1に送出して、このユーザへのコールC2を開始する。
5. また、UAMは、C1をC2に相互接続する。
6. V1は、UAMから受信するINVITEを参照する。それは、SDPによって、ViPrクラスのデバイスであると確認される。つまり、V1のソフトウェアは、ピア(peer)ソフトウェアに、Replaces/Refers等を含むViPrデバイスに求められる全ての機能をサポートする能力があることを知る。
7. 例えば、V1のUser_Bが、OK(了承)と共にINVITEを返信する。
8. UAMは、接続C2がアップされたとマークする。そして、C1にOKを送る。
この例におけるメディアストリームについて説明する。V1とUD1間のメディアストリームは、以下の方法の何れかで送られる。
1. メディアは、V1からUD1に直接送られる。これは、UAMが正しいSDPを書き込んで行われる。つまり、INVITEをV1に送る上に、それは、受信用にUD1のIPアドレス,ポートを加える。そして、OKをUD1に送る上に、それは、V1のIPアドレス,ポートを受信アドレスとして加える。
2. メディアは、UAMで中継される。このケースでは、UAMは、V1からUD1へのデータを中継し、その逆も行う。UAMとViPrがATMクラウドを介して通信接続されているならば、その後、V1とUAM間のSVCが設定され得ることは容易に理解される。つまり、メディアトラフィックについて、UAMは、イーサネットゲートウェイに対してATMとして働く。
例1をさらに続けると、User_Aは、V2のUser_Bを会議に加えることを決定する。そして、以下のイベントが生じる。
1. UAMとV1間のSip接続は、会議コールC3で置き換えられて、V1、V2及びUAMが参加者となる。つまり、B2B UAは、会議コール(C3)をユニキャストコール(C1)と相互接続する。
2. UAMは、C3とC4間でトラフィックを常に中継する。上述のオプション11。それは、V1及びV2から送られるトラフィックをミキシングし、それをUD1に中継する。また、それは、UD1から送られるトラフィックを、V1及びV2にマルチキャストする。
UAMによって行われる機能は、以下の要素に分けられる。
・ SIP B2B UAユニット[SBU]。このユニットは、B2B SIP UAを実施するために必要なsipシグナリングを生成する。
・ メディア相互接続(Media Cross Connect)及びミキサ [MCMU]。
UAM機能は、3つの処理、即ち、図2に示す、SBU、ユニキャストミキサマネージャ及びSipスタックで決められる。
Sipサーバ(SipServer)プロセスは、Sip機能を実施して、SBUに、アブストラクテッドシグナリング(abstracted signaling)API(インターフェイスIa)を与え得る。また、インターフェイスIaは変化しない。
B2B UAを実施するために、SBUは、コール制御及びグルーロジック(glue logic)を実施する。このユニットは、Callmanager/Vupperコードに基づいている。SBUは、正しいミキサのストリームを設定することも担当する。このために、SBUは、RPCを通じてUMMプロセスとインターフェイスする。
UMMは、メディアストリームを相互接続する機能を実施することに加えて、オーディオミキシング機能を実施する。
B2B UAを実施するために、SBUは、コール制御及びグルーロジックを実施する。SBUは、正しいミキサのストリームを設定することも担当する。このために、SBUは、RPCを通じてUMMプロセスとインターフェイスする。
SBUユニットは、内部的に以下のように構成される。
図3から理解されるように、SBUのデザインは、CallManagerから与えられるSIP/メディアストリームインターフェイスを再利用及び拡張しているので、UAMについてシグナリングコール制御ロジックが実施される。
以下の記載にて、User_AがUser_Bへのコールを開始する場合の制御フローを示す。
以下では、Sipサーバは、UAMのSipサーバを参照しており、SBUは、UAMのSBUに言及し、UMMは、UAMのUMMを参照している。
例をさらに明確にするために、以下の事項が仮定される。
− ネットワーク全体は、イーサネットネットワークである。
− V1のIPアドレスは、172.19.64.101である。
− V2のIPアドレスは、172.19.64.101である。
− V1/V2クラウドに接続されるUAMのインターフェイスのIPアドレスは、172.19.64.51であり、UD1クラウドに接続されるUAMのIPインターフェイスは、169.144.50.100である。
− UD1のIPアドレスは、169.144.50.48である。
− アドレスは、<IPアドレス,ポート>の組として表される。
− 例における全てのアドレス及びポートは説明用であり、それらは、固定される必要はなく、むしろOSによって、割り当てられる。
− 以下の例では、(UAMの)SBUで受信される全てのSIPイベントは、実際にSipサーバで受信されて、その後SBUに移動させられる。しかしながら、Sipサーバがイベントを受信して、それをSBUに移動することは、簡単化のために示されない。
上記の表は、コールの経路で起こる事を説明している。次に、このコールが会議コールに変換される場合における制御フローを示す。この場合、例えば、User_Bは、V2のUser_Cをコールに加えて会議をする。
さらに、下記の事項が仮定される。
− V2のIPアドレスは、171.19.64.102である。
別のViPrのユーザを会議に加えるために、ステップ12から18が繰り返される。別のユニキャストデバイスのユーザ、即ちPOTS2のUser_Dに必要なステップを説明する。
以下の事項を仮定する。
− ViPr V2のUser_Cは、POTS2上のUser_Dを会議に加えることを決断する。
UMMは、メディアストリームを相互接続する機能に加えて、オーディオミキシング機能を実施する。
展開シナリオ 1:
図4を参照すると、このシナリオは、2つのケースをカバーしている。
複数参加者のViPrオーディオ/ビデオ会議におけるViPrユーザは、ユニキャストなオーディオのみの電話ユーザを会議に加える。
このケースでは、複数参加者のViPr会議におけるViPrユーザは、ユニキャストな電話ユーザを会議に加える決定をする。その結果、参加者の1人が、着信先の電話番号にコールを開始する。ViPr SIPサーバは、そのコールの着信先をViPr UAMに変更する。ViPr UAMは、ViPrのオーディオのみのコールをターミネートし、電話ゲートウェイを通じて、着信先の電話へのバックツーバックコールを確立する。
コールが確立されると、ViPr UAMは、電話から受信したG.711/G.722オーディオストリームを、PMP/マルチキャストストリームに変換し、トランスコーディングすることなく、それをViPr端末に転送する。他方で、ViPr UAMは、種々のViPr端末から受信したワイドバンドの16bit/16KHzPCM ViPr オーディオストリームを、G.711又はG.722である1つのユニキャストなオーディオストリームにトランスコーディング及びミキシングして、それを電話の着信先に転送する。
電話ユーザを含んでおり、ポイントツーポイントなオーディオのみの会議において、ViPrユーザは、別のViPrユーザを会議に加える。
このケースでは、電話ユーザ(T)を含むポイントツーポイントなオーディオのみのコールにおけるViPrユーザ(V1)は、別のViPrユーザ(V2)を会議に加えることを決定する。その結果、ViPrユーザV1は、着信先のViPrユーザV2にオーディオ/ビデオコールを開始する。ViPrシステムは、V1及びViPr UAMで確立されたポイントツーポイントコールを切って、V1、V2及びViPr UAM間のPMP/マルチキャストコールを再確立する。
ViPr UAMは、新たなViPrオーディオ/ビデオコールをターミネートし、それを、すでに確立されたバックツーバックテレフォンコールにブリッジする。このプロセスを通じて、テレフォンコールはアクティブなままであって、スイッチングは、電話ユーザに認識されない。
コールが確立されると、ViPr UAMは、電話から受信したユニキャストなG.711/G.722オーディオストリームを、PMP/マルチキャストストリームに変換し、トランスコーディングすることなく、それをViPr端末に転送する。他方で、ViPr UAMは、種々のViPr端末から受信したワイドバンドの16bit/16KHzPCM ViPrオーディオストリームを、G.711又はG.722である1つのユニキャストなオーディオストリームにトランスコーディング及びミキシングし、それを電話の着信先に転送する。
ViPrは、マルチストリームのマルチメディアセッションを確立し、修正し消去する手段として、セッション開始プロトコル(SIP)を用いる。UAMは、ViPr端末及び電話ユーザ(即ち、PSTN、モバイルフォン及びSIPフォン)間の会議能力を与える。これは、アップストリームのユニキャストな音声のみのテレフォンストリームを、ポイントツーマルチポイントストリーム(即ち、PMP−SVC又はIPマルチキャスト)に変換すること、ダウンストリームのViPrのマルチキャスト/PMPオーディオストリームを、ユニキャストな音声のみのテレフォンストリームに変換することに加えて、ワイドバンドの16bit/16KHzPCMエンコーディングからG.711又はG.722に、ViPrオーディオについて、ダウンストリームのオーディオのトランスコーディングをすることによって行われる。
展開シナリオ 2:
図5を参照すると、このシナリオは、2つのケースをカバーしている。
電話ユーザは、ViPrユーザにコールする。
このケースでは、電話ユーザは、ViPrユーザに向けてコール(オーディオのみ)を開始する。電話ゲートウェイは、そのコールの着信先をViPr UAMに変更する。ViPr UAMは、テレフォンコールをターミネートし、着信先のViPr端末へのバックツーバックなViPrのオーディオのみのコールを確立する。
コールが確立されると、ViPr UAMは、電話から受信したG.711/G.722オーディオストリームを、トランスコーディングすることなくViPr端末に転送する。他方で、ViPr UAMは、ワイドバンドの16bit/16KHzPCMからG.711又はG.722に、ViPrのオーディオストリームのトランスコーディングを行い、それを電話の着信先に転送する。
ViPrユーザは、電話ユーザにコールする。
この場合、ViPrユーザは、電話ユーザにコールを開始する。ViPr SIPサーバは、そのコールの着信先をViPr UAMに変更する。ViPr UAMは、ViPrのオーディオのみのコールをターミネートし、電話ゲートウェイを用いて、着信先の電話へのバックツーバックなPSTNコールを確立する。前の段落と同様な方法で、トランスコーディングが行われる。
図6は、UAMの典型的な使用状況を示す。UAMで与えられる特徴を、以下に示す。
(特徴1)
例えば、ViPr V1及びV2は、ポイントツーポイントコールに含まれており、それらは、ユニキャストデバイスUD1を、会議コールに加えることを希望する。言い換えると、目的は、UD1、V1及びV2が会議にいる会議コールを構成することである。例えば、V1のユーザは、UD1のユーザが、他の参加者としてV1及びV2を含む会議コールに加えられるようにリクエストする。このリクエストは、SIPサーバの1つによって、UAMに転送される。
その後、UAMは、以下の動作を行う。
− UD1を代理して、会議コールに加わる。この会議コールC1をコールする。
− また、ユニキャストデバイスを含むポイントツーポイントコールを作成する。この会議コールC2をコールする。
− C2で受信したオーディオデータをC1に中継する。
− コールC2の参加者V1及びV2からオーディオデータを受け取って、このデータをミキシングしてUDに転送する。
(特徴2)
上述の図のviprネットがATMであり、UDネットがIPネットワークであるケースを考える。また、可能な範囲内で、ATMネットワークに亘って、オーディオについて、LANE/CLIPではなく、SVCのみが使用されることが望ましいと仮定される。これにより、セキュリティ上の問題又はパフォーマンス上の問題に対処可能となる。
このケースでは、viprネット上のViPr V1が、音声会話にユニキャストデバイス(UD1)を加えることを希望する場合、UAMが用いられて、ATMネットワークにてSVCを、IPネットワークにてIPを使用する機能が与えられる。
これを行うためには、V1からUD1への全てのコールは、V1からUAMDへのコールと、UAMDからV2へのコールとに分けられる。
UAMでサポートされる特徴に要求される設定は、以下のカテゴリに分けられる。
− ViPrからUDへのコールの設定
− UDからViPrへのコールの設定
− 一般的な設定
(一般的な設定)
B2BUA SIP UAは、所望の任意のポート(5060以外)で動くようにされる。これは、以下のパラメータを含むように、vipr.iniファイルを修正することで行われる。
SIP_Port = 7070 [任意の有効なポート番号]
(ViPrからUDへのコールの設定)
典型的なViPrコールでは、ユーザが「番号」をダイヤルすると、その「コールリクエスト」は、SIPサーバに送られる。SIPサーバは、それを適切な着信先に転送する。しかしながら、このケースは異なっている。このケースでは、ユーザが、自分がユニキャストデバイス(UD1)と話をしたいと希望していると言うと、SIPサーバはUAMにそのリクエストを転送する。さらに、それは、このコールがUD1に転送されるべき旨を特定する情報を、そのリクエストに加える。つまり、SIPサーバは、UAMデバイスでサービスされるSIP−URIに作られたコールを、適切なUAMDサーバにルーティングするようにプログラムされる。
また、UAMで受信された全てのコールを転送するために、デフォルトのユニキャストデバイスのSIPアドレスを指定することが可能である。このデフォルトアドレスは、vipr.iniファイルに、以下の行を加えることで指定される。
UD_SERVER_ADDRESS = 169.144.50.48
X_FORWARD_AVAILABLE = 0
ユニキャストデバイスからViPrにコールがなされる場合、そのコールは、UAMに送られなければならないことに留意すべきである。これを行うために、適切な設定がユニキャストデバイスで行われる。これに関しては、ユニキャストデバイスの使用書を参照のこと。
(UDからViPrへのコールの設定)
ViPrへのコールは、UDで開始されて、UAMにルーティングされる。これを達成する一つの方法は、UDをプログラムして、全てのコールをUAMに導くこと又は転送することである。最終的なコールの着信先(例えば、V1)は、UAMへのコールリクエスト内で指定される。通常、このアドレスは、SIPメッセージ内のTo fieldであろう。これらの設定は、UD又はSIPサーバで行われる。
さらに、UAMがUDからコールリクエストを受信する場合、UAMは、それを、コールされた参加者の健全さをチェックするゲートウェイマーシャル(Marshall)サーバに転送する。このゲートウェイアドレスは、以下のように、vipr.iniファイルで指定できる。
GatewayMarshallServer = sip.eng.fore.com:5065
略語のリスト
ATM (Asynchronous Transfer Mode) 非同期転送ノード
ISDN (Integrated Services Digital Network) 総合サービスデジタルネットワーク
IP (Internet Protocol) インターネットプロトコル
LAN (Local Area Network) ローカルエリアネットワーク
MC (Mulicast) マルチキャスト(IP)
MCMU (Media Cross Connect and Mixer) メディア相互接続及びミキサ
MCU (Media Conferencing Unit) メディア会議ユニット
PBX (Private Branch Exchange) プライベートブランチエクスチェンジ(構内電話交換機)
PCM (Pulse-Code Modulation) パルス符号変調
PMP (Point-to-Multipoint) ポイントツーマルチポイント(ATM)
POTS ("Plain Old Telephone") 「一般的な電話システム」
PRI (Primary Rate Interface) 1次群インターフェース
PSTN (Public Switched Telephone Network) 公衆交換電話網
SBU (SIP back-to-back user agent) SIPバックツーバックユーザエージェント
SIP (Session Initiation Protocol) セクション開始プロトコル
SVC (Switched Virtual Circuit) 交換接続型仮想回路
UAM (Unicast Audio Mixer) ユニキャストオーディオミキサ
ViPrTM (Virtual Presence System) バーチャルプレゼンスシステム
WAN (Wide Area Network) 広域通信網
例示を目的として、上述の実施例について、本発明が詳細に説明されたが、このような詳細は、単に説明を目的としており、当該技術分野における通常の知識を有する者であれば、特許請求の範囲に記載される場合を除き、発明の精神と範囲から逸脱することなく、変形ができることは理解できるであろう。