JP4389560B2 - リアルタイム通信システムおよびメディアエンド端末 - Google Patents

Description

本発明はリアルタイム通信システムに関し、例えば、ＶｏＩＰ技術を利用した音声通信を行う場合などに適用して好適なものである。

また、本発明は、かかるリアルタイム通信システムの構成要素としてのメディアエンド端末に関するものである。

ＭＩＤＩ（Musical Instrument Digital Interface）規格に対応した電子楽器などでは、ＭＩＤＩデータを出力することができる。ＭＩＤＩデータは、音の波形そのものではなく、音の高さ、長さ、音色などを数値データに変換して得られるものなので、波形そのものを符号化する場合などに比べ、はるかに小さなサイズで電子楽器の演奏内容を記述することが可能である。

ＭＩＤＩ規格を活用すれば、ある生徒が電子楽器を演奏することによって得られたＭＩＤＩデータを記憶媒体に記憶した上でその記憶媒体を郵送すること等により、遠隔地にいる講師に演奏の内容を伝え、当該講師が演奏の指導を行うというレッスン形態を取ることも可能である。

また、通常の公衆網（ＰＳＴＮ）で提供されるアナログ電話サービスを活用して音や音声を伝えることは可能であるので、アナログ電話サービスで、カラオケや声楽のレッスンを行ったり、楽器の演奏のレッスンを行ったりすることも、必ずしも不可能ではなかった。

しかしながら、アナログ電話サービスで伝えることのできる音声帯域は狭い帯域幅（３００−３４００Ｈｚ）に制限されているため、通常の通話は、ほぼ支障無く行うことができても、声楽、カラオケ、楽器のレッスンなどに用いるには通信の品質が低すぎるために問題が多い。

声楽、カラオケなどで発声される音声や、楽器の演奏によって発せられる音は、３００Ｈｚ未満の低域、および３４００Ｈｚより高い高域が、重要な成分となることが少なくないにもかかわらず、アナログ電話サービスではこれらの成分がカットされ、伝送不能となるからである。

その一方で、前記ＭＩＤＩデータを記憶した記憶媒体を郵送する場合には、帯域幅の点で問題はないものの、リアルタイム性に欠けるため、生徒と講師がリアルタイムで意思の疎通を取ることが難しく、効果的なレッスンを行うことは困難であった。

かかる課題を解決するために、第１の本発明のリアルタイム通信システムは、所定の通信プロトコルを用いたネットワーク上で、当該通信プロトコルに対応するパケットに第１の可聴周波信号に対応する可聴周波メディア情報を収容して、ユーザの使用する所定のメディアエンド端末からパケットを送信または受信するリアルタイム通信システムにおいて、メディアエンド端末は、（１）リアルタイム通信のため、近端側から受け取った音声信号に相当する第１の可聴周波信号をもとに音声コーデックにより符号化して広帯域幅の音声データに相当する可聴周波メディア情報の生成または可聴周波メディア情報から元の第１の可聴周波信号の復元を行う可聴周波メディア情報変換部と、（２）近端側から受け取った演奏音信号に相当する第２の可聴周波信号をもとに音声コーデックよりも高いサンプリング周波数を用いるオーディオコーデックでサンプリングした上で符号化して所定データ形式の広帯域幅の演奏波形データ又はＭＩＤＩデータに相当する演奏データへの変換または、演奏データから元の第２の可聴周波信号の復元を行う演奏データインタフェース部と、（３）ネットワークを通じて対向端末との間の呼設定を行うと共に、可聴周波メディア情報変換部及び演奏データインタフェース部と前記ネットワークとの間のパケット中継を行う通信制御手段とを備え、（４）可聴周波メディア情報を収容した第１のパケットと共に、前記演奏データを収容した第１のパケットとは異なる第２のパケットを、前記ネットワーク経由で伝送して、第１の可聴周波信号と第２の可聴周波信号を用いたユーザ間の意思疎通を行うことを特徴とする。

また、第２の本発明のメディアエンド端末は、所定の通信プロトコルを用いたネットワーク上で、当該通信プロトコルに対応するパケットに第１の可聴周波信号に対応する可聴周波メディア情報を収容してリアルタイム通信を行うリアルタイム通信システムの構成要素としてのメディアエンド端末において、（１）リアルタイム通信のため、近端側から受け取った音声信号に相当する第１の可聴周波信号をもとに音声コーデックにより符号化して広帯域幅の音声データに相当する可聴周波メディア情報の生成または可聴周波メディア情報から元の第１の可聴周波信号の復元を行う可聴周波メディア情報変換部と、（２）近端側から受け取った演奏音信号に相当する第２の可聴周波信号をもとに音声コーデックよりも高いサンプリング周波数を用いるオーディオコーデックでサンプリングした上で符号化して所定データ形式の広帯域幅の演奏波形データ又はＭＩＤＩデータに相当する演奏データへの変換または、演奏データから元の第２の可聴周波信号の復元を行う演奏データインタフェース部と、（３）ネットワークを通じて対向端末との間の呼設定を行うと共に、可聴周波メディア情報変換部及び前記演奏データインタフェース部とネットワークとの間のパケット中継を行う通信制御手段とを備え、（４）可聴周波メディア情報を収容した第１のパケットと共に、前記演奏データを収容した第１のパケットとは異なる第２のパケットを、ネットワーク経由で伝送して、第１の可聴周波信号と第２の可聴周波信号を用いたユーザ間の意思疎通を行うことを特徴とする。

本発明によれば、通信の品質を高め、複数種類の情報によりリアルタイムな意思の疎通を行うことが可能となる。

これにより、例えば、効果的な遠隔音楽レッスンを実現することができる。

（Ａ）実施形態
以下、本発明にかかるリアルタイム通信システムおよびメディアエンド端末をＶｏＩＰシステムに適用した場合を例に、実施形態について説明する。

（Ａ−１）第１の実施形態の構成
本実施形態にかかるＶｏＩＰシステム１０の全体構成例を図１に示す。

図１において、当該ＶｏＩＰシステム１０は、ＩＰ網１１と、モデム装置１２，１７と、ＣＰＥ（Customer Premises Equipment）装置１３，１８と、マイク１４と、ヘッドセット１５，１９と、楽器１６と、アクセス回線ＡＣ１，ＡＣ２とを備えている。

このうちＩＰ網１１は特定の通信事業者もしくはＩＳＰ（インターネット・サービス・プロバイダ）が管理、運営するネットワークであり、ＯＳＩ参照モデルのネットワーク層ではＩＰプロトコルを用いているため、当該ＩＰ網１１では、ＶｏＩＰ技術によるＩＰ電話サービスが提供されている。ＩＰ網１１には、図示しないルータ、Ｌ２スイッチなどの各種ネットワーク機器が含まれている。

ＩＰ網１１には必要に応じてインターネット（図示せず）が接続されていてもかまわない。

図１上、ユーザＵ１とＵ２はＶｏＩＰによる音声通信とＭＩＤＩデータのやり取りによって意思の疎通をはかる。このような意思の疎通は様々な用途で実行され得るが、ここでは音楽レッスンを例に取る。ユーザＵ１が音楽レッスンの生徒であり、ユーザＵ２が講師であるものとする。

基本的に、生徒であるユーザＵ１側の構成要素と、講師であるユーザＵ２側の構成要素は対応している。すなわち、回線終端装置１２は回線終端装置１７に対応し、ＣＰＥ装置１３は前記ＣＰＥ装置１８に対応し、ヘッドセット１５は前記ヘッドセット１９に対応しているので、以下では、主として、ユーザＵ１側の構成要素に着目して説明を進める。

前記アクセス回線ＡＣ１、ＡＣ２として、近年では、ＡＤＳＬなどのブロードバンドサービスが利用されることが多いが、前記回線終端装置１２は、そのアクセス回線ＡＣ１を終端する部分である。したがって、アクセス回線ＡＣ１としてＡＤＳＬを用いる場合にはＡＤＳＬモデムなどが、当該回線終端装置２１に該当する。また、アクセス回線ＡＣ１として光を用いる場合には、メディアコンバータ（光終端装置）などが、当該回線終端装置２１に該当する。アクセス回線ＡＣ２が当該アクセス回線ＡＣ１と同種のアクセス回線である必要がないことは当然である。

図１上は別個の構成要素として図示しているが、当該回線終端装置１２は、前記ＣＰＥ装置１３に内蔵されるものであってもよいことは当然である。また、必要に応じて、回線終端装置１２にルータの機能が内蔵されていてもかまわない。

ＣＰＥ装置１３はユーザＵ１が管理するネットワーク機器で、後述するＶｏＩＰゲートウエイの機能などを搭載している。当該ＣＰＥ装置１３は、無料または低価格で、ユーザＵ１に配布され得る。

当該ＣＰＥ装置１３を介して回線終端装置１２に接続されているヘッドセット１５とマイク１４は、ユーザＵ１に対するユーザインタフェースを構成する。

音楽レッスンに際し、ユーザＵ１は頭部に装着したヘッドセット１５を用いてユーザＵ１と通話しながら、自身が演奏する楽器１６の音（演奏音）ＡＵをユーザＵ２に聴取させる。ユーザＵ１が発話した音声はヘッドセット１５内のマイク１５Ａによって集音され、ＣＰＥ装置１３内で音声コーデックにより音声データに符号化された上、ＩＰパケットＰＫ１１に収容されてＩＰ網１１経由で回線終端装置１７まで届けられる。

同様に、ユーザＵ１が演奏する楽器１６の演奏音ＡＵは、前記マイク１４で集音されてＣＰＥ装置１３内で、音声コーデックよりも高いサンプリング周波数を用いるオーディオコーデックでサンプリングされ符号化された上、ＩＰパケットＰＫ２１に収容されてＩＰ網１１経由で回線終端装置１７まで届けられる。なお、楽器１６が電子楽器であってアナログ出力端子を備えている場合には、マイク１４の替わりに、当該アナログ出力端子とＣＰＥ装置１３を接続するためのアナログ入力端子を、ＣＰＥ装置１３側に配置するようにしてもよい。

このような構成であるから、楽器１６はＭＩＤＩ対応の楽器である必要はなく、任意の楽器を使用することができる。したがってキーボードやピアノなどの一般的な楽器や電子楽器などのほか、胡弓などの楽器を、当該楽器１６として使用することもユーザＵ１の自由である。

前記ＣＰＥ装置１３の内部構成は例えば図２に示すものであってよい。ＣＰＥ装置１８の構成も基本的にはこれと同じであってよい。

（Ａ−１−１）ＣＰＥ装置の内部構成例
図２において、当該ＣＰＥ装置１３は、通信制御部２１と、ＶｏＩＰ部２２と、オーディオコーデック部２３とを備えている。

このうちＶｏＩＰ部２２は、いわゆるＶｏＩＰゲートウエイなどに相当する機能を持つ部分である。したがって、ユーザＵ１が発話した音声はヘッドセット１５のマイク１５Ａで集音されたあと、このＶｏＩＰ部２２内で符号化されて音声データとなり、音声データは前記ＩＰパケットＰＫ１１に収容されて通信制御部２１や、前記回線終端装置１２などを介してＩＰ網１１へ送出される。ユーザＵ２が発話した音声をユーザＵ１が聴取するときにはこれと反対の手順となる。

すなわち、ユーザＵ２側のヘッドセット１９のマイク１９Ａで集音された音声の符号化結果としての音声データを収容したＩＰパケットＲＫ１１が、前記ＣＰＥ装置１８から送出されると、回線終端装置１７やＩＰ網１１などを経由してＣＰＥ装置１３内の当該ＶｏＩＰ部２２まで届けられ、ＶｏＩＰ部２２内で当該ＩＰパケットＲＫ１１から取り出した音声データを復号した上、復号結果が、前記ヘッドセット１５のスピーカ１５Ｂから出力され、ユーザＵ１に聴取される。

ここで当該符号化を行う符号化器や復号を行う復号器が、上述した音声コーデックであり、ＶｏＩＰ部２２内に配置されている。

オーディオコーデック部２３は、前記マイク１４から集音した演奏音ＡＵを上述したように当該音声コーデックよりも高いサンプリング周波数でサンプリングした上で符号化し、符号化結果である演奏データ（演奏音ＡＵの波形を示すデータ）をＩＰパケットＰＫ２１に収容して送信する。本実施形態の構成上、ユーザＵ１がユーザＵ２が演奏する演奏音を聴取することはないため、当該オーディオコーデック部２３は復号を行う必要はなく、符号化のみを行えばよいが、必要ならば、オーディオコーデック部２３に復号器としての機能を搭載してもよい。これは、講師であるユーザＵ２が演奏して手本を示す場合などに有効である。

通信制御部２１は中継機能と同期機能を持つ部分である。

このうち中継機能は、前記ＩＰパケットＰＫ１１をＶｏＩＰ部２２から回線終端装置１２へ中継する場合およびＩＰパケットＰＫ２１をオーディオコーデック部２３から回線終端装置１２へ中継する場合、ならびに、ＩＰパケットＲＫ１１を回線終端装置１２からＶｏＩＰ部２２に中継する場合に機能する。

同期機能のほうは、ＩＰパケットＰＫ１１とＰＫ２１を同期させるための機能である。音声データを伝えるＩＰパケットＰＫ１１は、ＩＴＵ−Ｔ勧告Ｈ．３２３やＳＩＰ（セッション開始プロトコル）などの呼制御の手順で呼設定が行われたあとで送出されることになるため、演奏データを伝えるＩＰパケットＰＫ２１も、このＩＰパケットＰＫ１１に合わせて送信するようにするとよい。

通信制御部２１は、呼制御の過程でＣＰＥ装置１８側における鳴動に応えてユーザＵ２がオフフックしたあと、ＩＰパケットＰＫ１１の送信を許し、それにつづいてＩＰパケットＰＫ２１の送信を許すように制御するものであってよい。なお、講師であるユーザＵ２側から生徒であるユーザＵ１へ電話をかける（発信する）ようにしてもよいことは当然である。

また、ここでは、ＶｏＩＰ部２２で音声データを伝送し、オーディオコーデック部２３で演奏データを伝送するようにしたが、ＶｏＩＰ部２２を用いて音声データの一部として演奏データを伝送できる可能性もある。

ＶｏＩＰ部２２の仕様を例えば、前記アナログ電話サービスなどの帯域幅（３００−３４００Ｈｚ）よりもはるかに広い帯域幅（５０−７０００Ｈｚ）に対応できるものとして、広帯域通信（例えば、ＩＴＵ−Ｔ勧告Ｇ．７２２に対応する通信など）を行う場合などには、３００Ｈｚ未満の低域や３４００Ｈｚより高い高域の可聴周波信号を伝えることができるため、ユーザＵ１の発話する音声と同じ機構を利用してユーザＵ１の演奏音ＡＵを伝えることが可能である。

その場合、通信制御部２１は、前記同期機能を搭載する必要はない。

広帯域通信の効果としてはまた、通話の品質が高まることも上げられる。日本語などに比べて外国語（例えば、英語）の発声では、３４００Ｈｚより高い高域を伝えることができないと正常な通話を行うことが難しくなる現象もみられるが、広帯域通信によってこのような現象の影響を著しく改善することが可能である。ユーザＵ１、Ｕ２のいずれか、または双方が英語を話す場合などには特に有効である。

また、ＶｏＩＰの広帯域通信によって音声データの一部として演奏音ＡＵの内容を伝えるか、演奏データの形で、音声データと別個に演奏音ＡＵの内容を伝えるかを、ユーザＵ１が動的に選択できるようにしてもよい。

なお、図１上は省略しているが、前記呼制御の手順を実行するため、ＩＰ網１１上に、ＳＩＰサーバやＨ．３２３ゲートキーパなどが存在してよいことは当然である。

以下、上記のような構成を有する本実施形態の動作について説明する。ここでは、生徒であるユーザＵ１から講師であるユーザＵ２へ発信するものとする。

（Ａ−２）第１の実施形態の動作
ユーザＵ１は楽器１６を前記マイク１４の近傍に配置して準備を行い、頭部にヘッドセット１５を装着したあと、講師であるユーザＵ２の電話番号を指定してユーザＵ２へ電話をかける。電話番号の指定にはそのためのユーザインタフェースを用意しておく必要がある。当該ユーザインタフェースとしては、例えば、電話機を用いてもよいし、ディスプレイ装置に表示されるＷｅｂページを用いるようにしてもよい。

このＷｅｂページ（発信用Ｗｅｂページ）は、ユーザＵ１が前記音楽レッスンの受講のために発信する際に利用するページで、音楽レッスンの講師（例えば、Ｕ２）の名前または電話番号などの着信先を示す情報の表示（着信先指定表示）を含む。またＣＰＥ装置１３には、当該発信用Ｗｅｂページを表示するためのソフトウエアであるＷｅｂポータルを搭載しておく。ＷｅｂポータルはＷｅｂブラウザの一種であるが、ソフトウエアによるダイヤル発信機能を備えている点が通常のＷｅｂブラウザと相違する。

Ｗｅｂポータルを用いる場合、ＣＰＥ装置１３には前記ディスプレイ装置やマウスなどのポインティングデバイスを接続する必要があり、ＩＰ網１１上には、前記発信用Ｗｅｂページを提供するＷｅｂサーバ機能が配置されることになるが、ユーザＵ１は前記着信先指定表示をクリックする等の簡単な操作だけで、着信先を指定してユーザＵ２へ発信することができる。

ユーザＵ１が電話番号（着信先）を指定することにより前記呼制御の手順が開始されると、呼び出しにこたえてユーザＵ２によりＣＰＥ装置１８側でオフフックの操作が行われ、ユーザＵ２がヘッドセット１９を自身の頭部に装着する。これにより、ユーザＵ１とＵ２のＶｏＩＰ通信によるリアルタイムの通話が可能となる。この通話は、ＩＰ網１１経由で、前記ＩＰパケットＰＫ１１とＲＫ１１がやり取りされることによって成立する。

通話の進行に応じて、ユーザＵ１が楽器１６を演奏すると、その演奏音ＡＵはマイク１４で集音され、演奏音ＡＵに対応する演奏データを収容したＩＰパケットＰＫ２１がＩＰ網１１経由で伝送されるようになる。

音声データのほうは当然、再送制御なしのリアルタイム通信によって伝送されるが、このように演奏データを音声データと別個のパケットで伝送する場合、演奏データを収容したＩＰパケットＰＫ２１の伝送は再送制御を伴う非リアルタイム通信とすることも可能である。ＩＰ網１１上でパケット損失が発生した場合でも、ユーザＵ２側で、音の途切れなどのない完全な演奏音ＡＵを再現できる点では再送制御を行うほうが有利であるが、ユーザＵ１とＵ２のあいだの意思疎通は演奏データの伝送と音声データの伝送が密接に結びついて進行するため、リアルタイム性を重視する場合には、ＩＰパケットＰＫ２１の伝送も再送制御を伴わないリアルタイム通信とするほうが有利である。

また、ＩＰパケットＰＫ２１の伝送をリアルタイム通信で行うか、非リアルタイム通信で行うかを、ユーザＵ１またはＵ２側から動的に選択できるようにしてもよい。このようにしておけば、パケット損失などの発生状況に応じて、いずれを用いるかを決めることができる。

再送制御を行う場合、パケット損失が発生すると、パケット損失によって失われたものと同じＩＰパケットＰＫ２１が送信元であるＣＰＥ装置１３から再び送信され、宛先であるＣＰＥ装置１８では、その再送されたＩＰパケットＰＫ２１の到着を待って演奏音ＡＵの再生出力を行うことになるため、厳密なリアルタイム性を確保することはできないが、上述したように、ＭＩＤＩデータを記憶した記憶媒体を郵送などで送る場合に比べるとはるかにリアルタイム性が高いため、ほぼリアルタイムであるといえる。

いずれにしても、生徒であるユーザＵ１は講師であるユーザＵ２からの指示にしたがって微妙に演奏の仕方を変えて楽器１６の演奏を繰り返し、遠隔の音楽レッスンを実行することが可能である。ユーザＵ２側でも、微妙な演奏音の変化を聞き取った上で、適切な指示を伝えることが十分に可能である。

この方法の場合、ユーザＵ１とＵ２の位置が物理的に大きく離れていても、長時間の移動を行うことなく、対面によるレッスンに近い音楽レッスンを実現することができる。例えば、ユーザＵ１が国内にいて、ユーザＵ２が外国にいる場合などにも有効である。ユーザＵ１とＵ２の母国語が異なる場合には、ＣＰＥ装置１３または１８に機械翻訳機能を搭載して、リアルタイムで機械翻訳を伴う通話を行うようにしてもよい。

移動の必要がないことから、受講料を低価格に設定することや、短時間のうちに世界中の多くの講師の指示を受けること等も容易である。また本実施形態は、生徒や講師が老人など、移動が容易でない状態の人である場合にも効果的である。

（Ａ−３）第１の実施形態の効果
本実施形態によれば、通信の品質を高め、複数種類の情報（ここでは、音声データと演奏データ）によりリアルタイムな意思の疎通を行うことが可能となる。

これにより、例えば、効果的な遠隔音楽レッスンを実現することができる。

（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。

本実施形態は、前記楽器１６の演奏音の波形を示す前記演奏データの替わりに、ＭＩＤＩデータを用いる点が相違するだけである。

（Ｂ−１）第２の実施形態の構成および動作
本実施形態のＶｏＩＰシステム３０の全体構成例を図５に示す。

図５において、図１と同じ符号を付与した構成要素の機能は第１の実施形態と同じなので、その詳しい説明は省略する。また、ＣＰＥ装置１３Ａは前記ＣＰＥ装置１３に相当し、ＣＰＥ装置１８Ａは前記ＣＰＥ装置１８に相当し、楽器１６Ａは前記楽器１６に相当する。

本実施形態では、演奏データの替わりにＭＩＤＩデータを使用するので、ＣＰＥ装置１３Ａ側でＭＩＤＩデータを生成する必要がある。

ここでは、楽器１６Ａが、ユーザＵ１による楽器１６Ａの演奏の内容を記述するＭＩＤＩデータを出力する機能を持つＭＩＤＩ楽器であるものとする。

当該ＭＩＤＩデータを受け取るＣＰＥ装置１３Ａは、図３に示す内部構成を備えている。図３中、図２と同じ符号を付与したＶｏＩＰ部２２の機能は基本的に第１の実施形態と同じであるので、ＣＰＥ装置１３ＡはＭＩＤＩインタフェース部３１を有する点が図２に示した前記ＣＰＥ装置１３と異なる。

なお、本実施形態では、演奏音を示す情報はＭＩＤＩデータとして伝送されるため、第１の実施形態のように当該ＶｏＩＰ部２２で３００Ｈｚ未満の低域や３４００Ｈｚより高い高域の可聴周波信号を伝えるための広帯域通信を行う必要性は低い。

本実施形態のＣＰＥ装置１３Ａ内に設けられたＭＩＤＩインタフェース部３１は、当該ＭＩＤＩデータをＩＰパケットＰＫ２１に収容して送信する機能を持つ部分である。

通信制御部２１Ａの機能は、基本的に前記通信制御部２１と同じであってよいが、ＭＩＤＩデータは前記演奏データのように演奏音ＡＵの波形を示すデータではなく数値データであり、宛先であるＣＰＥ装置１８Ａ側で正常な演奏音の再生出力を行うためには、１ビットの誤りの混入や脱落の発生も許されないと考えられるため、ＩＰパケットの再送制御を行うことが望ましい。

同じサイズのデータで比較した場合、数値データのほうがはるかに長い期間の音声（または音）を記述できるため、ＩＰパケットＰＫ２１で再送による遅延が発生したとしても、その遅延が直接、ユーザＵ２側における音声出力と演奏音の再生出力のタイミングのずれとして、ユーザＵ２に認識される可能性を軽減することができる。

音声データを収容したＩＰパケットＰＫ１１とともに、ＭＩＤＩデータを収容したＩＰパケットＰＫ２１を受信するＣＰＥ装置１８Ａの内部構成は例えば図４に示す通りである。

図４において、当該ＣＰＥ装置１８Ａは、通信制御部２１Ａと、ＶｏＩＰ部２２と、ＭＩＤＩインタフェース部３２と、音源モジュール部３３と、ミキサ部３４とを備えている。

このうち符号２１Ａ、２２を付与した各構成要素の機能は同じ符号を付与した既述の構成要素と同じである。

ＭＩＤＩインタフェース部３２Ａは、ＩＰ網１１経由でＣＰＥ装置１８Ａが受信したＩＰパケットＰＫ２１から、前記ＭＩＤＩデータを取り出して音源モジュール部３３へ供給する部分である。

音源モジュール部３３は、いわゆるＭＩＤＩ音源モジュールであり、供給を受けたＭＩＤＩデータに応じて、演奏音の再生出力を行う。音源モジュール部３３内には、ＲＯＭ（リードオンリーメモリ）等に音色などの情報が格納されており、ＭＩＤＩデータにしたがってそれらの情報を読み出すこと等により、演奏音の再生出力を行うものである。

ミキサ部３４は、ＶｏＩＰ部２２から供給されるユーザＵ１の発話した音声を示す復号結果と、音源モジュール部３３から供給される演奏音を示す再生出力とをミキシングし、ミキシング結果をユーザＵ２に聴取させるために機能する部分である。

もちろん、本実施形態でも第１の実施形態と同様に、ユーザＵ２が発話した音声も、ＶｏＩＰ部２２で生成されたＩＰパケットＲＫ１１で、ＣＰＥ装置１３Ａ側へ伝送される。

（Ｂ−２）第２の実施形態の効果
本実施形態によれば、第１の実施形態の効果とほぼ同等な効果を得ることができる。

加えて、本実施形態では、ＭＩＤＩデータを収容したＩＰパケット（ＲＫ２１）を再送制御することにより、講師であるユーザ（Ｕ２）が聴取する演奏音の品質を、より高いものとすることが可能である。

（Ｃ）第３の実施形態
以下では、本実施形態が第１、第２の実施形態と相違する点についてのみ説明する。

本実施形態では、講師であるユーザＵ２側から生徒であるユーザＵ１側へも手本となる楽器の演奏音を伝送できる点、および聴覚的な情報だけでなく視覚的な情報を用いた意思疎通をはかることができる点で、第１、第２の実施形態と相違する。

ＭＩＤＩデータを収容したＩＰパケットの伝送を行う点で、本実施形態は、第１の実施形態よりも第２の実施形態に近いとみることができる。

（Ｃ−１）第３の実施形態の構成および動作
本実施形態のＶｏＩＰシステム４０の全体構成例を図６に示す。

図６において、図５と同じ符号１１，１２，１７，１５，１９，１６Ａを付与した構成要素の機能は基本的に第２の実施形態と同じであるので、その詳しい説明は省略する。

本実施形態では、ユーザＵ１による楽器１６Ａの演奏の様子を視覚的に伝えるためのカメラ４２がユーザＵ１側に配置されている。

ここでは、楽器１６Ａはキーボードであるため、当該カメラ４２は主としてユーザＵ１の指の動きを撮影するように設定されている。

カメラ４２の撮影によって得られた画像データは、ＩＰパケットに収容され、ＩＰ網１１経由でユーザＵ２側へ伝送される。したがって、本実施形態のＣＰＥ装置１３Ａと１８Ｃは、第２の実施形態の機能に加えて、画像データを取り扱う機能を持つ必要があることは当然である。

画像データを収容したＩＰパケットの伝送は、再送制御を伴う非リアルタイム通信とすることも可能であるが、再送制御を行わないリアルタイム通信とすることも望ましい。

ユーザＵ２は、前記ＣＰＥ装置１８Ｃに接続されたディスプレイ装置４１で、前記画像データが示すユーザＵ１の鍵盤上における指の動きを目視することができる。

また、ユーザＵ２側の楽器１６Ｂは楽器１６Ａと同じＭＩＤＩ楽器である。講師であるユーザＵ２がこの楽器１６Ｂを演奏して手本を示すと、その演奏音がＭＩＤＩデータの形でユーザＵ１側へ伝えられ、ユーザＵ１に聴取される。

なお、ここでは、画像データの伝送方向は生徒（Ｕ１）から講師（Ｕ２）へ向かう方向のみであるが、演奏の手本を視覚的に伝えたい場合もあり得る考えられるので、カメラ４２と同様なカメラをユーザＵ２側に配置するとともに、ディスプレイ装置４１と同様なディスプレイ装置をユーザＵ１側にも配置して、双方向で画像データのやり取りを行うことができるようにしてもよいことは当然である。

（Ｃ−３）第３の実施形態の効果
本実施形態によれば、第２の実施形態の効果と同等な効果を得ることができる。

加えて、本実施形態では、視覚的な情報も伝えることにより、意思疎通のレベルを、対面による音楽レッスンにいっそう近づけることことが可能である。

（Ｄ）第４の実施形態
以下では、本実施形態が第１〜第３の実施形態と相違する点についてのみ説明する。

第１〜第３の実施形態では、一人の生徒と一人の講師による１対１の音楽レッスンを想定したが、本実施形態では、複数の生徒と一人の講師による多対１の音楽レッスンを可能にする。

本実施形態は、第１〜第３の実施形態のなかでは第３の実施形態に最も近いものとみることができる。

（Ｄ−１）第４の実施形態の構成および動作
本実施形態のＶｏＩＰシステム５０の全体構成例を図７に示す。

図７において、図６と同じ符号１１，１２，１７，１３Ａ、１８Ｃ、１５，１６Ａ、１６Ｂ、１９，４１，４２を付与した各構成要素の機能は基本的に第３の実施形態と同じであるので、その詳しい説明は省略する。

ユーザＵ３も、ユーザＵ１と同様に、講師であるユーザＵ２から音楽レッスンを受ける生徒である。したがって、ユーザＵ３側の構成要素はユーザＵ１側の構成要素とまったく同じものであってよい。

本実施形態でＩＰ網１１上に配置したＭＩＸサーバ（ミキシングサーバ）５１は、二人の生徒Ｕ１，Ｕ３による楽器１６Ａの演奏内容を示す情報をミキシングして、ミキシング結果をユーザＵ２に伝える。これにより、ユーザＵ１とＵ３が物理的に１つの楽器１６Ａを連弾した場合と同様な演奏音を、ユーザＵ２が聴取することができる。

ここでは、二人の生徒が演奏する楽器は同じもの（ここでは、同じ仕様のキーボード）であるが、異なっていてもよいことは当然である。また、三人以上の生徒の演奏音を同時にユーザＵ２が聴取する場合には、例えば、生徒の集団に交響曲を演奏させること等も可能である。必要に応じて、ＭＩＸサーバ５１のミキシング結果は、各生徒にも聴取できるようにするとよい。

また各生徒の音声を当該ＭＩＸサーバ５１上でミキシングすることにより、同じ音楽レッスンに参加している各生徒による同時通話も可能である。通話は、講師と各生徒のあいだで行えるほか、生徒相互間でも行うことができるようにしてもよい。

さらに、このＶｏＩＰシステム５０を利用して生徒間（例えば、Ｕ１とＵ３のあいだ）で個別練習を行うことも可能である。

また、必要に応じて、講師側の楽器１６Ｂを省略してもよいことは当然である。

（Ｄ−２）第４の実施形態の効果
本実施形態によれば、第３の実施形態の効果と同等な効果を得ることができる。

加えて、本実施形態では、１対１の音楽レッスンに限らず、多対１の音楽レッスンを行うことも可能である。

（Ｅ）他の実施形態
なお、本発明では、図１０に示す構成のＶｏＩＰシステムを用いることも可能である。図１０の構成は、図５のＩＰ網１１上にデータ変換サーバ７１を配置したものである。

当該データ変換サーバ７１は、ＣＰＥ装置１３Ａ側から送信されたＩＰパケットＰＫ２１に収容されているＭＩＤＩデータを、ＶｏＩＰ部２２の符号化によって生成されるものと同じ音声データ（演奏音の波形を示すデータ）に変換した上で、変換後の音声データを収容したＩＰパケットをＣＰＥ装置１８Ａ側へ送信するサーバである。

この構成の利点は、ユーザＵ２側のＣＰＥ装置１８ＡがＭＩＤＩに対応する必要がなく、前記ＭＩＤＩ音源モジュール（音源モジュール部３３）等の搭載の必要がない点である。

また、アクセス回線ＡＣ１やＡＣ２が、例えばＡＤＳＬ等のように上り方向の帯域が狭く、下り方向の帯域が広い非対称速度のアクセス回線である場合には、ＩＰ網１１上のデータ変換サーバ７１でＭＩＤＩデータを音声データに変換してデータのサイズが増大することは、非対称速度アクセス回線との適合性が高く、効率的であるといえる。ＣＰＥ装置１３Ａから送信されアクセス回線ＡＣ１を上り方向に伝送されるときにはサイズが小さく、ＣＰＥ装置１８Ａに届けるためにアクセス回線ＡＣ２を下り方向に伝送されるときにはサイズが大きくなるからである。

当該データ変換サーバ７１や前記ＭＩＸサーバ５１を用いる場合、これらのサーバの位置によっては、ホップ数が増大して、リアルタイム通信の遅延の増加、通信品質の不安定化などの不利益を招く可能性があるため、サーバ７１，５１の位置には配慮する必要がある。

なお、上記第２の実施形態において、図５上、インタフェース機器であるＵＳＢ−ＭＩＤＩが楽器１６ＡとＣＰＥ装置１３Ａのあいだに介在しているが、当該ＵＳＢ−ＭＩＤＩの機能は、楽器１６Ａ内またはＣＰＥ装置１３Ａに内蔵されていてもよいことは当然である。また、ＵＳＢ（ユニバーサル・シリアル・バス）を用いることは必ずしも必須ではないことは当然である。

また、以上の説明において、ヘッドセット（例えば、１５）は、その他の手段に置換可能である。例えば、ハンズフリーフォンなどを活用することも可能である。

一方、図１，図５〜図７、図１０の構成にかかわらず、各ユーザのあいだには、１つのＩＰ網（１１）以外のネットワークが介在するようにしてもよい。一般的に遠隔の生徒と講師が音楽レッスンのために通信する場合は、むしろ、１つのＩＰ網とともに（、または１つのＩＰ網に替えて、）多数のネットワーク（ＩＳＰ網すなわち、ＡＳ）が介在する構成になるほうが普通である。

その場合、ＶｏＩＰシステムの全体構成は、例えば、図８に示すものとなる。

図８の例では、日本国内に位置するユーザＵ１は、日本のＩＳＰ網の１つであるＩＳＰ１と、ＩＰ網１１と、米国のＩＳＰ網の１つである米国ＩＳＰとを経由した通信により、ユーザＵ２による音楽レッスンを受ける。

ところが、図８の構成は図９に示す構成とすることによって、リアルタイム通信の品質がかなり高まり、安定した品質で通信できることが簡単な実験によって確認された。

図９の場合、日本国内に位置するユーザＵ１は、日本のＩＳＰ網の１つであるＩＳＰ１と、ティア１（１次プロバイダ）網６１と、専用線ＡＣ３とを経由した通信により、ユーザＵ２による音楽レッスンを受ける。

ここで、ティア１網６１は、ＩＳＰ網の一種であるが、超大手の米国ＩＳＰによって運営されている。周知のように、インターネットはＩＳＰ網の集合体であるが、各ＩＳＰ網のあいだには、ルーティング可能な経路情報の数に応じて階層構造が存在する。ティア１網は、その階層構造のなかで最上位に位置するＩＳＰ網で、インターネット上のどのＩＳＰ網に対しても（より厳密には、どのＡＳ（自律システム）に対しても）ルーティング可能な経路情報を保有している。

ティア１網以外のＩＳＰ網に収容されている場合、ＩＰパケットの宛先によっては該当する経路情報が分からず、経路情報を特定するために他のＩＳＰ網を経由しなければならないことが起こり得る。

図９のような構成とすることにより、生徒の側からは世界中の講師からリアルタイムの遠隔音楽レッスンを受けることができる利点があり、講師の側からは世界中の生徒にリアルタイムでレッスンを行うことができる利点がある。

なお、本発明は、楽器のレッスンだけでなく、声楽や、カラオケなどのレッスンを含め、遠隔教育システムに広く適用できる可能性がある。

また、上記実施形態にかかわらず、ＯＳＩ参照モデルのネットワーク層のプロトコルは必ずしもＩＰプロトコルである必要はない。一例として、ＩＰＸプロトコルなどを利用できる可能性もある。

さらに、以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。また、以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することが可能であり、ソフトウエア的に実現した機能のほとんどすべては、ハードウエア的に実現することが可能である。

第１の実施形態にかかるＶｏＩＰシステムの全体構成例を示す概略図である。 第１の実施形態で使用するＣＰＥ装置の主要部の構成例を示す概略図である。 第２の実施形態で使用するＣＰＥ装置の主要部の構成例を示す概略図である。 第２の実施形態で使用するもう１つのＣＰＥ装置の主要部の構成例を示す概略図である。 第２の実施形態にかかるＶｏＩＰシステムの全体構成例を示す概略図である。 第３の実施形態にかかるＶｏＩＰシステムの全体構成例を示す概略図である。 第４の実施形態にかかるＶｏＩＰシステムの全体構成例を示す概略図である。 他の実施形態にかかるＶｏＩＰシステムの全体構成例を示す概略図である。 他の実施形態にかかるＶｏＩＰシステムの全体構成例を示す概略図である。 他の実施形態にかかるＶｏＩＰシステムの全体構成例を示す概略図である。

符号の説明

１０…ＶｏＩＰシステム、１１…ＩＰ網、１２、１７…回線終端装置、１３，１８…ＣＰＥ装置、１４…マイク、１５，１９…ヘッドセット、１６…楽器、５１…ＭＩＸサーバ、７１…データ変換サーバ、ＡＵ…演奏音、ＰＫ１１，ＰＫ２１，ＲＫ１１…ＩＰパケット。

Claims (7)

1. 所定の通信プロトコルを用いたネットワーク上で、当該通信プロトコルに対応するパケットに第１の可聴周波信号に対応する可聴周波メディア情報を収容して、ユーザの使用する所定のメディアエンド端末から前記パケットを送信または受信するリアルタイム通信システムにおいて、
   前記メディアエンド端末は、
   リアルタイム通信のため、近端側から受け取った音声信号に相当する前記第１の可聴周波信号をもとに音声コーデックにより符号化して広帯域幅の音声データに相当する可聴周波メディア情報の生成または可聴周波メディア情報から元の第１の可聴周波信号の復元を行う可聴周波メディア情報変換部と、
   近端側から受け取った演奏音信号に相当する第２の可聴周波信号をもとに音声コーデックよりも高いサンプリング周波数を用いるオーディオコーデックでサンプリングした上で符号化して所定データ形式の広帯域幅の演奏波形データ又はＭＩＤＩデータに相当する演奏データへの変換または、演奏データから元の第２の可聴周波信号の復元を行う演奏データインタフェース部と、
   前記ネットワークを通じて対向端末との間の呼設定を行うと共に、前記可聴周波メディア情報変換部及び前記演奏データインタフェース部と前記ネットワークとの間のパケット中継を行う通信制御手段とを備え、
   前記可聴周波メディア情報を収容した第１のパケットと共に、前記演奏データを収容した上記第１のパケットとは異なる第２のパケットを、前記ネットワーク経由で伝送して、第１の可聴周波信号と第２の可聴周波信号を用いたユーザ間の意思疎通を行うことを特徴とするリアルタイム通信システム。
2. 請求項１のリアルタイム通信システムにおいて、
   前記ネットワーク上にミキシングサーバを設置し、
   当該ミキシングサーバは、
   複数の前記メディアエンド端末から送信された上記第１のパケット及び上記第２のパケットを、所定の１つのメディアエンド端末に中継すると共に、その１つのメディアエンド端末から送信された上記第１のパケット及び上記第２のパケットを前記複数のメディアエンド端末へ中継する第１の中継処理部を有し、前記ユーザ間の多対１の意思疎通を行うことを特徴とするリアルタイム通信システム。
3. 請求項１のリアルタイム通信システムにおいて、
   前記メディアエンド端末のうち少なくともいずれか１つが、前記演奏データインタフェース部を持たない場合、前記ネットワーク上に変換サーバを設置し、
   当該変換サーバは、
   前記メディアエンド端末から送信された上記第２のパケットから取り出した演奏データを、前記可聴周波メディア情報に変換してパケットに収容した上で、前記演奏データインタフェース部を持たないメディアエンド端末へ中継する第２の中継処理部を備えたことを特徴とするリアルタイム通信システム。
4. 請求項１のリアルタイム通信システムにおいて、
   前記メディアエンド端末は、
   リアルタイム通信のため、近端側から受け取った画像信号をもとに画像メディア情報の生成または画像メディア情報から元の画像信号の復元を行う画像メディア情報変換部を備え、
   画像を利用した前記ユーザ間の意思疎通を行うことを特徴とするリアルタイム通信システム。
5. 請求項１のリアルタイム通信システムにおいて、
   前記メディアエンド端末は、
   前記可聴周波メディア情報から復元して得られた第１の可聴周波信号と、前記演奏データから変換して得られた第２の可聴周波信号とをミキシングするミキシング部を備えたことを特徴とするリアルタイム通信システム。
6. 請求項１のリアルタイム通信システムにおいて、
   前記ネットワークが、異なる組織によって管理された複数の要素ネットワークの集合体であり、なおかつ、要素ネットワーク間の経路制御のために保有する経路情報の範囲に応じて要素ネットワークのあいだに階層構造が存在する場合、相互に通信する前記メディアエンド端末のうち少なくともいずれか一方は、この階層構造の最上位に位置し自身で他の全ての要素ネットワークに関する経路情報を保有する第１階層要素ネットワークに収容されていることを特徴とするリアルタイム通信システム。
7. 所定の通信プロトコルを用いたネットワーク上で、当該通信プロトコルに対応するパケットに第１の可聴周波信号に対応する可聴周波メディア情報を収容してリアルタイム通信を行うリアルタイム通信システムの構成要素としてのメディアエンド端末において、
   前記リアルタイム通信のため、近端側から受け取った音声信号に相当する前記第１の可聴周波信号をもとに音声コーデックにより符号化して広帯域幅の音声データに相当する可聴周波メディア情報の生成または可聴周波メディア情報から元の第１の可聴周波信号の復元を行う可聴周波メディア情報変換部と、
   近端側から受け取った演奏音信号に相当する第２の可聴周波信号をもとに音声コーデックよりも高いサンプリング周波数を用いるオーディオコーデックでサンプリングした上で符号化して所定データ形式の広帯域幅の演奏波形データ又はＭＩＤＩデータに相当する演奏データへの変換または、演奏データから元の第２の可聴周波信号の復元を行う演奏データインタフェース部と、
   前記ネットワークを通じて対向端末との間の呼設定を行うと共に、前記可聴周波メディア情報変換部及び前記演奏データインタフェース部と前記ネットワークとの間のパケット中継を行う通信制御手段とを備え、
   前記可聴周波メディア情報を収容した第１のパケットと共に、前記演奏データを収容した上記第１のパケットとは異なる第２のパケットを、前記ネットワーク経由で伝送して、第１の可聴周波信号と第２の可聴周波信号を用いたユーザ間の意思疎通を行うことを特徴とするメディアエンド端末。

Images