JP4218456B2 - 通話装置、通話方法及び通話システム - Google Patents

Description

本発明は、例えばＶｏＩＰ（Voice over Internet Protocol）を使用したいわゆるインターネット電話等を行う通話装置、通話方法及び通話システムに関し、特に高音質の音声及び音響からなる実時間音響データをやり取りするために好適な通話装置、通話方法及び通話システムに関する。

音声をＩＰパケットにしてカプセル化することでＩＰ網を介した音声通話を可能とする技術として、ＶｏＩＰがある。ＶｏＩＰによる通話を行うためには、通話したい相手の情報の取得、通話したい相手の呼び出し、応答といった一連の情報交換をする必要があり、これらの目的のために、ＳＩＰ（Session Initiation Protocol）等の呼制御プロトコルが使用される。

このようなＶｏＩＰを含め、インターネット等の通信回線網を利用し、実時間動画像データや音声データ等の実時間音響データ等の実時間データを送信するシステムが増えている。インターネット等の公衆回線網においては、複数の利用者がネットワークの帯域を供給しているため、輻輳制御手法、すなわち輻輳の回避及び輻輳発生時の鎮静化手法は大きな課題となっている。従って、実時間性を重要とする通信形態が増えるという変化に伴い、実時間データの通信における輻輳制御手法が重要になってきている（下記特許文献１参照）。

ところで、従来、ＶｏＩＰを使用した実時間音声コミュニケーションにおいては、人の音声の主たる情報が含まれているのは、４〜５KHz付近の周波数帯域であったため、チャンネル数は１、標本化周波数を８KHz〜１６KHzに設定するのが常道であったが、このような狭い帯域では背景雑音や雰囲気等を伝達するのは困難である。

チャンネル数を２以上に設定し、標本化周波数をＣＤＤＡ（Compact Disk Digital Audio）並の４４．１KHzまで引き上げると背景雑音や雰囲気等も伝送でき、また加えて、音声コミュニケーションに、既存の楽曲コンテンツを流用した高音質なＢＧＭ機能等を付加することなども可能になる。

ここで、チャンネル数を２以上に設定し、標本化周波数をＣＤＤＡ並の４４．１KHzまで引き上げて、無圧縮の１６bits LinearＰＣＭ（Phase Code Modulation：パルス符号変調）のデータを伝送する場合、ネットワーク上の伝送ビットレートは１４１１．２Kbps以上になってしまい、実インターネット環境で利用するのは難しい。したがって、現状では高能率符号化方式を用いる必要があるが、近時のＣＰＵの性能の向上により、実時間音声コミュニケーションにおいても高能率符号化方式を採用することが可能になってきている。

なお、高能率符号化方式にはいくつかの方式があるが、先ず周波数分解を行い、信号を複数のサブバンドに分割したうえ、それぞれのブロックを、聴覚心理特性を利用して符号化精度を適応的に変化させて、必要最低限のビット数で所定の周波数成分をエントロピー符号するものが殆どである。この高能率符号化により、符号化する周波数成分に応じてビットレートは可変になる。

このような高品質な実時間音響データの送受信をインターネットを介して行う場合、受信するデータパケットに、エラー又はロストパケット等の欠落パケットがあると、品質を維持できない。したがって、このような欠落したパケットは、通常受信側から送信側へパケットの再送要求を送り、再び送信してもらう処理をする。その際、往復伝播遅延ＲＴＴ（Round Trip Time）を計測しておき、このＲＴＴに基づき、受信側が再送要求したパケットが、受信側において再生処理される予定時刻までに受信できるか否かが判断される（下記特許文献２）。

ところで、通常、実時間音声コミュニケーションにおいては、ネットワーク揺らぎは、ＲＦＣ（Request for Comments：インターネット技術標準文書）１８８９に記述された下記計算式から、２つのパケットＰ（ｉ）、Ｐ（ｊ）の送信時及び受信時における到着間隔の差Ｄを求め、これによりジッタＪを算出することができる。
Ｄ（ｉ，ｊ）＝（Ｒｊ−Ｒｉ）−（Ｓｊ−Ｓｉ）＝（Ｒｊ−Ｓｊ）−（Ｒｉ−Ｓｉ）
Ｊ＝Ｊ＋（｜Ｄ（ｉ−１，ｉ）｜−Ｊ）／１６
これにより、ミリ秒・マイクロ秒単位で算出し、揺らぎ吸収バッファの容量を自動調整することで、伝送の揺らぎが多少変化しても吸収できるようになされている。

特開２００１−３２０４４０号公報 特開２００３−１６９０４０号公報

しかしながら、このような方式で自動調整されるバッファの容量では、特定の周期で大幅にパケットが欠落したり、到着間隔が唐突に大きく揺らぐ場合など、音が寸断されてしまう可能性が否めない。特に、音声データとＢＧＭ等の付加データとを合成した高音質な実時間音響データをやり取りする実時間音声コミュニケーションを行う場合は、上述したように、欠落パケットがあると音質が低下してしまうが、再送要求できる時間に限りがあり、品質を維持できない場合がある。

これに対し、例えば音声のみの実時間音響データをやりとりするような場合には、情報量が小さく、必ずしも再送要求する必要がないので、揺らぎ吸収バッファの容量は比較的小さくしてもよい。このように、従来は、低遅延を望むユーザと高音質を臨むユーザとを同時に満足させることが困難であった。

本発明は、このような従来の実情に鑑みて提案されたものであり、インターネットを介して通話をする際、必要に応じて応答性又は音質のいずれにも対応することができる通話装置、通話方法及び通話システムを提供することを目的とする。

上述した目的を達成するために、本発明に係る通話装置は、インターネットを介して実時間音響データの送受信を行う通話装置において、音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、上記データパケット及び上記制御パケットを上記インターネットを介して１以上の他の通話装置に送信する送信手段と、上記１以上の他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、上記受信したデータパケットをバッファリングする揺らぎ吸収バッファと、上記受信したデータパケットに格納された圧縮符号化データを復号伸張する復号伸張手段と、上記復号伸張したデータをバッファリングするバッファと、上記バッファの容量をユーザの指示に基づき制御する制御手段とを有し、上記揺らぎ吸収バッファの容量は、受信するデータパケットの伝送レートに基づき自動調整される。

本発明においては、復号伸張したデータをバッファリングするバッファの容量をユーザが決定することができ、伝送情報量が多く高音質なデータの送受信の際には音質を維持するためにバッファ容量を大きくし、音声のみの通話を行うような通常の通話においては、低遅延を目的としてバッファを小さくする等、ユーザのニーズに合わせたデータ受信を行うことができる。

また、上記制御手段は、少なくとも上記バッファの容量を示すバッファ情報を上記制御パケットに格納させることができ、通話相手となる他の通話装置に対し、通話装置を使用しているユーザが決定したバッファのサイズを通知することができる。

更に、上記制御手段は、上記他の通話装置からの制御パケットに格納されたバッファ情報に基づき上記データパケットの伝送レートを制御することができ、通話相手となる他の通話装置のバッファ容量に合わせて伝送する実時間音響データの圧縮符号化率等を変更し、伝送レートを可変とすることができる。

更にまた、上記受信したデータパケットをバッファリングする揺らぎ吸収バッファを有し、該揺らぎ吸収バッファの容量は、受信するデータパケットの伝送レートに基づき自動調整されるものとすることができ、ユーザ操作で容量が可変なバッファに対し、伝送レートに応じて最低限度の容量のバッファを確保することができ、例えば応答性を重視するような通話の場合にはユーザ操作が可能なバッファの容量をゼロにしてもよい。

また、上記制御手段は、上記他の通話装置からのデータパケットの伝送レートを計測し、上記ユーザに通知してもよく、ユーザは、音質を上げるためにバッファ容量を大きくするか否か等をこの伝送レートに基づき決定してもよい。

更に、上記制御手段は、上記バッファの容量に応じて生成された欠落データパケットの再送要求を指示する再送要求指示情報を生成し、上記制御パケットに格納させることができ、例えばユーザ操作により容量が可変な上記バッファを大きくしておけば、再送要求する時間を長くとることができ、高品質なデータを維持することができる。

本発明に係る通話方法は、インターネットを介して実時間音響データの送受信を行う通話方法において、音声を含む実時間音響データを圧縮符号化する圧縮符号化工程と、上記圧縮符号化工程にて圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成工程と、少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成工程と、上記データパケット及び上記制御パケットを上記インターネットを介して１以上の他の通話装置に送信する送信工程と、上記１以上の他の通話装置からのデータパケット及び制御パケットを受信する受信工程と、上記受信したデータパケットを揺らぎ吸収バッファにバッファリングするバッファリング工程と、上記受信したデータパケットに格納された圧縮符号化データを復号伸張する復号伸張工程と、上記復号伸張したデータをバッファリングするバッファの容量をユーザの指示に基づき制御する制御工程とを有し、上記揺らぎ吸収バッファの容量は、受信するデータパケットの伝送レートに基づき自動調整される。

本発明に係る通話システムは、２以上の通話装置がインターネットを介して実時間音響データの送受信を行う通話システムにおいて、各上記通話装置は、音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、上記データパケット及び上記制御パケットを上記インターネットを介して１以上の他の通話装置に送信する送信手段と、上記１以上の他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、上記受信したデータパケットをバッファリングする揺らぎ吸収バッファと、上記受信したデータパケットに格納された圧縮符号化データを復号伸張する復号伸張手段と、上記復号伸張したデータをバッファリングするバッファと、上記バッファの容量をユーザの指示に基づき制御する制御手段とを有し、上記揺らぎ吸収バッファの容量は、受信するデータパケットの伝送レートに基づき自動調整され、少なくとも２つの通話装置のうち一方の上記通信装置の上記制御手段は、少なくとも上記バッファの容量を示すバッファ情報を上記制御パケットに格納させ、他方の通話装置の上記制御手段は、上記一方の通話装置からの制御パケットに格納されたバッファ情報に基づき当該一方の通話装置に送信するデータパケットの伝送レートを制御する。

本発明においては、復号伸張した無圧縮のデータをバッファリングするバッファの容量をユーザ操作に応じて決定することができ、更に、ユーザが決定したバッファ容量は、制御パケットにて通信相手となる通話装置へ伝えられ、これを受けた通話装置は、通話相手のバッファに応じた処理、例えば圧縮符号化方式を変更して伝送レートを可変に設定する等の処理を実行することができる。

本発明に係る通話装置によれば、インターネットを介して実時間音響データの送受信を行う通話装置において、音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、上記データパケット及び上記制御パケットを上記インターネットを介して１以上の他の通話装置に送信する送信手段と、上記１以上の他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、上記受信したデータパケットに格納された圧縮符号化データを復号伸張する復号伸張手段と、上記復号伸張したデータをバッファリングするバッファと、上記バッファの容量をユーザの指示に基づき制御する制御手段とを有するので、例えばバッファを大きくすると欠落パケットの再送要求可能な時間を長くして伝送情報量が多いような高音質なデータの品質を維持することができ、一方、音声のみで低遅延で応答性を重視するような通話を行うような通常の通話においては、バッファを小さくする等、ユーザのニーズに合わせたデータ受信を行うことができる。

また、本発明に係る通信システムにおいては、各通話装置のユーザがバッファの容量を所望の容量として、ユーザニーズにあわせたデータ受信を行うことができると共に、データの送信側においては、通話相手のバッファ容量を制御パケットにより知ることができ、通話相手のニーズに合わせたデータ送信を行うことができる。

以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。本発明を、２以上の通話装置がインターネットを介してＶｏＩＰにより通話を行う通話装置としてのＶｏＩＰクライアント及びこれを備えた通話システムとしてのＶｏＩＰシステムに適用したものである。本実施の形態におけるＶｏＩＰクライアントは、ＢＧＭが付加されるような高音質な音声データであって音質を重視する場合と、通常の通話のように低遅延を重視する場合とをユーザ自身が選択することができるものである。

先ず、本実施の形態におけるＶｏＩＰを使用したネットワークコミュニケーションをオ行うＶｏＩＰシステムの概略について説明する。図１は、本実施の形態におけるＶｏＩＰシステムの一例を示す模式図である。本実施の形態におけるＶｏＩＰシステムでは、例えば２チャンネル以上で、且つユーザ間で、通話のみではなく様々な効果音及びＢＧＭ等も共有することができる高音質の音声コミュニケーションを実現するものである。なお、本実施の形態におけるＶｏＩＰシステムは、２つの通話装置（以下、ＶｏＩＰクライアントという。）間で行なわれるものとするが、ＶｏＩＰシステムを構成するＶｏＩＰクライアントは２つに限らず、従ってＶｏＩＰクライアントを介してネットワークコミュニケーションに参加可能な参加者は２以上であることは勿論である。

図１に示すように、ＶｏＩＰシステム１００は、例えばＰＣ（Personal Computer）等のＶｏＩＰクライアント１１１と、これとインターネット１３０を介して接続されたＶｏＩＰクライアント１２１とを有する。

このＶｏＩＰシステム１００においては、ＶｏＩＰクライアント１１１のユーザ１１０と、ＶｏＩＰクライアント１２１のユーザ１２０とは、自身のＶｏＩＰクライアント１１１、１２１に搭載される後述するＶｏＩＰ用のアプリケーション（ソフト・フォン）等と、例えばマイクロフォンとヘッドフォンとからなるヘッドセット又はマイクロフォンと受話器とからなるハンドセットとを使用し、インターネット１３０を介して通信相手とコミュニケーションを行う。

インターネット１３０は、一般公衆回線等の通信回線や、情報通信ネットワークを複数接続することによって世界中に拡がったネットワーク環境である。現在、広帯域、高速な通信回線の普及によってブロードバンド伝送（Broadband Transmission）を可能としている。光ファイバー、非対称ディジタル加入者線、無線等を用い、５００ｋｂｐｓ以上の通信回線でネットワークを構成している。

このインターネット１３０には、ＶｏＩＰ通信を制御するＶｏＩＰサーバ１３１、及び音源データ１３２及びダウンロードユーザインフォメーション１３３等のデータを管理するウェブサーバ１３４等が接続されている。また、各ＶｏＩＰクライアント１１１、１２１には、各ＶｏＩＰクライアント１１１、１２１が有するウェブブラウザ１１２、１２２等によりウェブサーバ１３４からダウンロードするか、又は自身で購入若しくは編集した音源データ１１３、１２３が記憶されている。

ウェブサーバ１３４のデータベースに格納されている音源データ１３２、及びユーザがダウンロード等して所持している音源データ１１３、１２３は、例えばＢＧＭ（Back Ground Music）等に使用される音楽や、波の音・拍手の音・雷鳴・ベルの音等の各種効果音であり、これらの音源データは、ユーザ間のネットワークコミュニケーションにて使用することができる。

次に、このＶｏＩＰクライアントについて説明する。図２は、ＶｏＩＰシステムを構成するＶｏＩＰクライアントの機能を示すブロック図である。図２に示すように、このようなインターネットコミュニケーションを行うためのＶｏＩＰクライアント２０は、コミュニケーションに参加している参加者、即ち通話相手へデータを送信する送信手段２１と、通話相手からのデータを受け取る受信手段４１とを有する。

送信手段２１は、マイクが接続され、外部（ユーザ）の音声をキャッチするマイクキャプチャ（MIC capture）２２と、例えばＭＰ３（ＭＰＥＧ（Moving Picture Experts Group）１オーディオLayer３）、又はＭＰＥＧ４等に圧縮された各種効果音（Sound Effect：ＳＥ）の音源ファイルが記憶された効果音ファイル記憶部２３と、同じく圧縮された各種ＢＧＭの音源ファイルが記憶されたＢＧＭファイル記憶部２４と、効果音ファイル及びＢＧＭファイルを読み出しデコードする夫々デコーダ２５及び２６と、マイクによりキャプチャした音、効果音、及びＢＧＭのゲインを制御して音量調整するゲイン調整部２７〜２９と、これらの３つの音を合成する合成部３０と、合成した音を圧縮符号化するエンコーダ３１と、圧縮符号化されたデータをデータパケットとしてのＲＴＰ（Real-Time Transport Protocol）パケットに格納するデータパケット生成手段としてのパケット化部（packetize）３２ａと、後述するデコーダ４６にてデコードされたデータをバッファリングするＰＣＭバッファ（図示せず）の容量を制御すると共に、ＲＴＣＰ（Real-Time Control Protocol）パケットに格納する各種制御情報及びＲＴＰパケットをコントロールする管理情報等を管理する制御部３４と、制御情報及び管理情報等をＲＴＣＰパケットに格納する制御パケット生成手段としてのＲＴＣＰパケット化部３２ｂと、ＲＴＰパケット及びＲＴＣＰパケット等を送信する送信部３３とを有する。送信部３３から送られたＲＴＰパケットがインターネット１３０を介して通信対象となる他のＶｏＩＰクライアントに送信される。

一方、インターネット１３０を介して通信相手の送信手段２１から送られるデータを受信する受信手段４１は、ＲＴＰパケット及びＲＴＣＰパケット等を受信する受信部４２と、受信したＲＴＰパケットをデパケッタイズするＲＴＰデパケット化部（depacketize）４３ａと、ＲＴＣＰパケットをデパケッタイズするＲＴＣＰデパケット化部（depacketize）４３ｂと、ＲＴＰパケットの到着時間を補正するデジッタ部（de-jitter）４４と、送られたＲＴＰパケットのエラーが生じた部分又は伝送中に損失した部分等の欠落部分を補償するパケット補償部（packet loss compensator）４５と、パケット補償部４５からのデータを復号伸張するデコーダ４６と、例えばＭＰ３、ＭＰＥＧ４等に圧縮された着信音の音源ファイルが記憶された着信音ファイル（Ring Tone File）記憶部４７と、着信音ファイルを読み出しデコードするデコーダ４８と、デコーダ４６及び４８のゲイン調整をする夫々ゲイン調整部４９及び５０と、上述した送信手段２１における合成部３０にて合成された送信用のＰＣＭデータ、即ち送信者側自身の音源のゲイン調整するゲイン調整部５２と、ゲイン調整された送信用のデータ、通信相手から送信されてきたデータ、及び着信音データを合成する合成部５３と、合成部５３にて合成されたデータをヘッドフォン（ＨＰ）５４へ出力する出力部と、合成部５３へ出力される着信音とは別に着信音のゲインを調整するゲイン調整部５１と、ゲイン調整された着信音を外部へ出力するスピーカ（ＳＰ）５５とを有する。

次に、このＶｏＩＰクライアントのデータの送受信方法について説明する。先ず、送信側において、マイクキャプチャ２２は、マイクにより入力されたユーザの音声をキャッチしてゲイン調整部２７へ送る。ゲイン調整部２７は、音声データに対し、ユーザの指示によるか又は自動的に、ゲイン係数ｋ１を乗算し、所望の大きさにゲイン調整する。

効果音ファイル記憶部２３及びＢＧＭファイル記憶部２４は、例えばＭＰ３、ＭＰＥＧ４等の圧縮技術により予め圧縮された音源ファイルが記憶された、例えばハードディスクドライブ（ＨＤＤ）、ＲＯＭ（read only memory）又は光磁気ディスクからなり、デコーダ２５及び２６は、これらの圧縮符号化データを読み出し、読み出した圧縮符号化データをＰＣＭデータに変換する。更に、デコーダ２５、２６は、変換したＰＣＭデータを夫々ゲイン調整部２８、２９へ送り、ゲイン調整部２８、２９は、送られてきたデータに対し、ユーザの指示によるか又は自動的に、夫々ゲイン係数ｋ２及びｋ３を乗算して、所望の大きさにゲイン調整する。

ゲイン調整部２７〜２９にてゲイン調整された音声、ＢＧＭ及び効果音は、合成部３０に供給され、合成部３０はゲイン調整部２７〜２９の出力を飽和処理しつつ加算し、この加算結果をエンコーダ３１に出力する。エンコーダ３１は、この加算結果をネットワークにて送信するために、例えばＭＰＥＧ４等にエンコードする。エンコードされたデータは、リアルタイム・トランスポート・プロトコル（Real-time Transport Protocol：ＲＴＰ）に従ってデータをパケット化するＲＴＰパケット化（packetize）部３２ａに供給される。

ＲＴＰパケット化部３２ａは、エンコードデータをＲＴＰパケットにパケット化し、パケット化データは、送信部３３からインターネット１３０を介して通信相手のＶｏＩＰクライアントへ送信される。

また、制御部３４は、ユーザ操作に基づきデコーダ４６の後段に設けられたＰＣＭバッファの容量を制御するものである。そして、ユーザ操作によって変更されたＰＣＭバッファの容量に応じて、伝送途中でエラーが生じたり又は失われたような欠落パケットの再送要求等の制御情報を生成する。また、このバッファ容量をＲＴＣＰパケットの拡張部分に格納させる。更に、本実施の形態におけるＶｏＩＰクライアントが送受信するＲＴＣＰパケットの拡張部分には、受信部４２にて受信したパケットのジッタを相殺するための揺らぎ吸収バッファの容量等も記述することができる。なお、制御部３４は、ＲＴＣＰパケットのレポートブロック等に格納される各種管理情報を管理すると共に、ＲＴＣＰパケットの拡張部分に格納される他の制御情報も生成することができる。他の制御情報としては、再生する前の無圧縮のＰＣＭデータを格納しておくＰＣＭバッファの容量通信相手となる他のＶｏＩＰクライアントが送信してくるＲＴＰパケットに格納される実時間音響データの圧縮率を指定する例えばエンコード帯域及びサブバンド分割数等の情報等がある。

そして、ＲＴＣＰパケット化部３２ｂは、この制御情報及び管理情報をＲＴＣＰパケットにパケット化し、このパケット化データも送信部３３からインターネット１３０を介して通信相手のＶｏＩＰクライアントへ送信される。

また、ＶｏＩＰによる通話では、ＲＴＰパケットを送信する前に、制御部３４がＳＩＰ等の呼制御プロトコルにより、送信部３３を介して、通信対象となる他のＶｏＩＰクライアントに対し呼シグナリングを行う。そして、他のＶｏＩＰクライアントの間でＲＴＰ／ＲＴＣＰセッションが確立された後、送信部３３がＲＴＰパケット及びＲＴＣＰパケットを送信することができる。ＲＴＰ／ＲＴＣＰパケットの詳細は後述する。

一方、受信側においては、受信部４２がインターネット１３０を介して送られてくるＲＴＰパケット及びＲＴＣＰパケット等を受信する。そして、ＲＴＣＰデパケット化部４３ｂは、受信したＲＴＣＰパケットを分解し、制御部３４は、ＲＴＣＰパケットの拡張部分に格納された上述のＰＣＭバッファ情報を取り出し、これに応じて伝送レートを変更指せる等の処理をする。

また、受信部４２が受信したＲＴＰパケットをＲＴＰデパケット化部４３ａが逆パケット化した後、デジッタ部４４が例えばネットワークの状態等により受信が遅れる等して到着時刻が不均等になっているデータを補正し、等間隔化する。この補正は、逆パケット化されＩＰ、ＵＤＰ（User Datagram Protocol）から分解されたＲＴＰのタイムスタンプ、シーケンシャルナンバーを基に行なわれる。その後、パケット補償部４５がネットワークの送受信において欠落又は受信不能等となったパケットを保障する処理、具体的には、欠落したパケットの代わりにその前又は後のパケットと同じパケットを使用するようにしたり、欠落したパケットの再送要求をして改めて欠落パケットを受信するようにする等したりしてパケットの損失を補償する。こうして得られたＭＰＥＧ４等の圧縮データはデコーダ４６にてデコードされ、これをゲイン調整部４９がユーザ指示又は自動的に、ゲイン係数ｋ５を乗算してゲイン調整する。

デコーダ４８は、他のＶｏＩＰクライアントから呼シグナリングされたとき、即ち電話がかかってきたときにユーザに通知するための呼び出し用の呼び出し音又は呼び出し用に使用する音楽等からなる着信音の音源ファイルを着信音ファイル記憶部４７から読み出す。着信音ファイル記憶部４７からの着信音データは、ユーザの所望によって予め選択されており、着信のタイミングに従って図示しないＲＡＭに読み出されながらデコーダ４８にてデコードされる。着信音の音源ファイルも、ＢＧＭ等の音源ファイル等と同様にＭＰ３、ＭＰＥＧ４等に圧縮されたものとなっており、ファイル単位の着信音データとして着信音ファイル記憶部４７に複数ファイル分記憶されている。そして、デコーダ４８は、読み出した音源ファイルをデコードし、デコードされた音源データをゲイン調整部５０、５１がユーザ指示又は自動的に、夫々ゲイン係数ｋ６、ｋ７を乗算することでゲイン調整する。

合成部５３は、着信音及び通信相手から送信されゲイン調整部４９にてゲイン調整された、通話相手から受け取った受信データと、ゲイン調整部５２から出力される自身の送信データとを加算処理する。ゲイン調整部５２は、送信される送信データを通話相手と共有するため、送信データにユーザが設定するループバック音量レベルであるゲイン係数ｋ４を乗算するものである。

そして、合成部５３にて合成されたデータは、ヘッドフォン５４を介して出力されユーザに伝えられる。また、着信音ファイル記憶部４７から読み出された着信音データは、ヘッドフォン５４とは別にスピーカ５５からも出力されるよう構成されている。

このようなＶｏＩＰクライアントにおいては、ユーザ操作に応じてＰＣＭバッファの容量を可変に設定することができるので、ユーザニーズに応じて、ＢＧＭ等を付加した高音質な実時間音響データをやり取りする際には、ＰＣＭバッファの容量を大きくして欠落パケット再送要求可能な時間を長く高音質を維持するようにし、音声のみの実時間音響データをやり取りする際には、例えばＰＣＭバッファの容量をゼロにして応答性を重視するようにすることができる。

更に、一般の電話に比してダイナミックレンジを広くすることで、ステレオ等の高音質の音声とＢＧＭ及び効果音等からなる音響とが合成された合成音を送受信することができ、従ってＢＧＭ等を付加しても会話（音声）をマスキングすることがない。また、効果音及びＢＧＭ等の音源ファイルから読み出した音と、通信者自身が話した音声、即ちマイク音とを別々にゲイン調整することができるため、効果音及びＢＧＭの音量を所望のレベルに調整することができ、ユーザは、通信相手へ例えば自身の気分を伝えたりすることができる。

また、着信音をヘッドフォン５４とスピーカ５５とで別々に出力することにより、例えばユーザがヘッドフォン５４を使用してＶｏＩＰによる通信中に一時的にＶｏＩＰクライアント２０から離れたり、通話が終了した後もヘッドフォン５４をセットしたままにしておいたりした場合であっても、着信音がスピーカ５５から外部に出力されるようにすることができる。

次に、このＶｏＩＰクライアントに使用されるソフトウェアについて説明する。図３は、一般的なＰＣ向けＶｏＩＰクライアントアプリケーションを含むソフトウェアモジュールを示す図である。ＶｏＩＰクライアントは、この図３に示す開放型システム間相互接続（Open System Interconnection：ＯＳＩ）のアーキテクチャに基づく各階層のプロトコルに応じたソフトウェアモジュール１を実行することにより上述の図２に示した機能を達成する。

図３において下位層から上位層に向かって各階層を説明する。先ず、物理層２としての機能にはユニバーサル・シリアル・バス（Universal Serial Bus：ＵＳＢ）カメラドライバ２ａ、ＵＳＢオーディオドライバ２ｂ及び各種ドライバ２ｃがある。カメラドライバ２ａからのビデオデータやオーディオドライバ２ｂからのオーディオデータの伝送条件の物理的条件を合わせるレイヤである。

次に、データリンク層としての機能には、オペレーティングシステム（Operating System：ＯＳ）３がある。隣接ノード間の誤りのないデータ伝送を実行するためのものである。

そして、ネットワーク層としての機能には、インターネットプロトコル（Internet Protocol：ＩＰ）制御部４がある。ネットワーク層は、データ送受信に使用する通信経路を選択し、フロー制御・品質制御などの通信制御を行うところである。信頼性を追求しないコネクションレス（Conectionless)パケット伝送プロトコルであるＩＰは、信頼性保証機能、フロー制御機能、エラー回復機能を上位階層（トランスポート層とアプリケーション層）に任せている。

トランスポート層としての機能には、トランスポート・コントロール・プロトコル（Transport Control Protocol：ＴＣＰ）／ユーザ・データグラム・プロトコル（User Datagram Protocol：ＵＤＰ）制御部５がある。

トランスポート層では、ＩＰアドレスを使用してエンド・ツー・エンドの伝送を行う。ネットワークの種類に依存せず、要求される品質クラスに従ってフロー制御や順序制御を行う。ＴＣＰは信頼性保証機能を持ち、伝送したデータの各バイトにシーケンス番号を付け、受信側から受け取り通知（Acknowledgment：ＡＣＫ（確認応答））が送られてこなければデータを再送する。ＵＤＰは、アプリケーション間のデータグラムの送信機能を提供する。ＩＰネットワークを用いて、音声・動画像をストリーミング再生する場合、一般にエラー時に再送を行うＴＣＰのようなトランスポート・プロトコルは使用できない。また、ＴＣＰは、１対１通信用のプロトコルであり、複数の相手に情報を送信することができない。そこで、このような用途には、ＵＤＰが用いられる。即ち、例えば再送制御を必要とする等、信頼性が高い通信を行う際にはＴＣＰ通信としてＴＣＰパケットを生成し、音声及び映像データ、並びに後述するＳＩＰを伝送する等、リアルタイム性が高い通信を行う際にはＵＤＰ通信としＵＤパケットを生成する。

ＵＤＰは、アプリケーションのプロセスがリモートマシン上の他のアプリケーションのプロセスへデータを伝送することを、最小のオーバーヘッドで行えるように設計されている。そのため、ＵＤＰのヘッダに入る情報は、送信元ポート番号、宛先ポート番号、データ長、チェックサムのみであり、ＴＣＰにあるパケットの順序を表す番号を入れるフィールドがないので、ネットワーク上で異なる経路を介して伝送されるなどによりパケットの順序が入れ替わってしまった場合に、その順序を正しい状態に戻す処理を行うことができない。また、送信時のタイムスタンプ等の時間情報を入れるフィールドは、ＴＣＰにもＵＤＰにもない。

セッション層６としての機能には、セッション・イニシエーション・プロトコル（Session Initiation Protocol：ＳＩＰ）制御部１１、ＲＴＰ／ＲＴＣＰ制御部１２、コーデック（codec）１３、通話音とＢＧＭ及び／又は効果音の合成処理ソフトウェアを構成する保留音制御部１４、ＢＧＭ合成部１５、及び着信音制御部１６がある。セッション層６は、情報の伝送制御を行う。アプリケーション間における対話モードを管理して会話単位の制御を行う。

ＳＩＰ制御部１１は、ＩＰネットワーク上でマルチメディアセッションを確立・変更・終了するための、アプリケーション層６のシグナリングプロトコル（ＲＦＣ３２６１で標準化）により呼制御を行う。

また、ＲＴＰ／ＲＴＣＰ制御部１２のうち、ＲＴＰは、音声データにＢＧＭ及び効果音等が合成され圧縮符号化された送信データを送信するためのプロトコルであり、送信データに時間情報及び順序情報を付与してネットワークを通じて音声データ送受信する機能を有する。また、ＲＴＣＰは、ＲＴＰを制御する制御プロトコルであり、ＲＴＰのフロー制御、クロック同期及びデータの再生時刻の認識、情報源の認識等を行う機能を有する。

コーデック１３は、送信音（伝送データ）を後述する高能率音響圧縮及び復号する機能を有する。

ＴＣＰ／ＵＤＰ制御部１０は、例えば再送制御を必要とする等、信頼性が高い通信を行う際にはＴＣＰ通信としてＴＣＰパケットを生成し、音声及び映像データ、並びに後述するＳＩＰを伝送する等、リアルタイム性が高い通信を行う際にはＵＤＰ通信としＵＤパケットを生成し、ＩＰ制御部１１は、ＴＣＰパケット又はＵＤＰパケットをＩＰパケット化する機能を有する。

また、プレゼンテーション層としての機能には、ＶｏＩＰ通話制御７がある。プレゼンテーション層では、アプリケーションで送受信する情報の表現形式を管理して、データの変換や暗号化を行う。ＶｏＩＰ通話制御部７は、ＶｏＩＰ通話機能の全体をコントロールする制御部である。

最上層のアプリケーション層としての機能には、コンピュータを視覚的に操作するためのグラフィカルユーザインターフェース（Graphical User Interface：ＧＵＩ）８がある。アプリケーション層は、ユーザプログラムで使用する通信機能の外部仕様を管理して、それに基づく情報のやり取りを行う層であり、ＧＵＩ８は、ユーザ操作用のインターフェイスを提供し、ユーザの手入力情報をハンドリングする。

図４は、ＧＵＩの一例を示す模式図である。ＧＵＩ８は、図４に示すように、ＶｏＩＰクライアントアプリケーション１の終了処理を行うアプリケーション制御部６１と、情報表示部６２と、ダイヤル部６３と、ヘッドセットボリューム部６４ａと、スピーカボリューム部６４ｂと、サウンドエフェクト選択表示部６５と、サウンドエフェクト制御部６６と、ＢＧＭ選択表示部６７と、ＢＧＭ制御部６８、ＰＣＭバッファ調整部６９とを有する。

情報表示部６２は、ユーザが通信対象となる相手先の番号をダイヤルした場合のダイヤル番号や、通信相手が話し中か否か等の相手状態等を表示する。ダイヤル部６３は、ＶｏＩＰ相手先をダイヤルするため等のテンキーからなる。また、ヘッドセットボリューム６４ａは、ヘッドセットから出力される音量を調節し、スピーカボリューム部６４ｂは、スピーカから出力される音量を調節する。サウンドエフェクト選択部６５は、ユーザが使用可能なサウンドエフェクト音源データファイルの表示するものであり、例えば銃声音、雷音、拍手の音、歓声音等を選択でき、サウンドエフェクト制御部６６により、効果音の再生及び停止、並びに音量調節を行う。これにより、効果音の各種効果音でユーザが通話相手への気持ち等を表現することができる。

また、ＢＧＭ選択表示部６７は、ユーザが使用可能な例えばタヒチの波の音等のＢＧＭ音源データファイルを表示するものであり、更にＢＧＭ制御部６８により、ＢＧＭの再生及び停止、並びにＢＧＭの音量調節を行うことで、サウンドエフェクトと同様、ユーザ自身が選択し、調節した音量により、ユーザの気分やその場の雰囲気を通信相手へ伝えること等ができる。

ＰＣＭバッファ調整部６９は、上述したように、デコード処理後であって、再生出力前のＰＣＭデータをバッファリングするＰＣＭバッファの容量をユーザが調節可能とするために設けられた操作部であって、例えば高音質実時間音響データをやり取りする際には、バッファ容量を大きくし、低遅延を目的とする実時間音響データをやり取りする場合には、バッファ容量は小さくする等の調整がなされる。

次に、ソフトウェアモジュール１を実行するＶｏＩＰクライアントのハードウェア構成について説明する。図５は、ＶｏＩＰクライアントのハードウェア構成を示すブロック図である。図５に示すように、ＶｏＩＰクライアント２０において、ＣＰＵ（Central Processing Unit）２２１は、ＲＯＭ（Read Only Memory）２２２に記憶されている上記ソフトウェアモジュールを構成する各種プログラム、又は記憶部２２８からＲＡＭ（Random Access Memory）２２３にロードされた上述のソフトウェアモジュール１を構成する各種プログラムに従って各種の処理を実行する。また図示せぬタイマが計時動作を行い、時刻情報をＣＰＵ２２１に供給する。ＲＡＭ２２３にはまた、ＣＰＵ２２１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ２２１、ＲＯＭ２２２及びＲＡＭ２２３は、バス２２４を介して相互に接続されている。このバス２２４にはまた、入出力インターフェイス２２５も接続されている。

入出力インターフェイス２２５には、キーボード、マウス等よりなる入力部２２６、ＣＲＴ、ＬＣＤ等よりなるディスプレイ、並びに、ヘッドフォンやスピーカ等よりなる出力部２２７、ハードディスク等より構成される記憶部２２８、モデム、ターミナルアダプタなどより構成される通信部２２９が接続されている。

通信部２２９は、図示せぬインターネットを介しての通信処理を行う。ＣＰＵ２２１から提供されたデータを送信する。また通信部２２９は通信相手から受信したデータをＣＰＵ２２１、ＲＡＭ２２３、記憶部２２８に出力する。記憶部２２８はＣＰＵ２２１との間でやり取りし、情報の保存・消去を行う。通信部２２９はまた、他のクライアントとの間で、アナログ信号またはディジタル信号の通信処理を行う。

入出力インターフェイス２２５にはまた、必要に応じてドライブ２３０が接続され、磁気ディスク２４１、光ディスク２４２、光磁気ディスク２４３、或いは半導体メモリ２４４等が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２２８にインストールされる。

次に、このようなハードウェア構成のＶｏＩＰクライアントが上述の図２に示すソフトウェアモジュール１を構成する各種プログラムを実行することによりＶｏＩＰ通話を実行する方法について説明する。

図６は、図３に示す一般的なＰＣ向けソフトウェアモジュールのうち、ＶｏＩＰ通話制御部７が制御するＲＴＰ／ＲＴＣＰパケットの送受信機能を説明する図である。図６に示すように、ＶｏＩＰ通話制御部７の制御は、スレッド１〜スレッド５に分けることができる。スレッド１は、送信者がＲＴＰパケットを送信するまでの処理、即ち送信者が発話した音声を含むデータを格納したデータパケットを送信する処理であり、スレッド２、３は、送信されたＲＴＰパケットを受信して再生するまでの処理、即ち上記送信者が通信対象となっている相手の音声を含むデータを聞くまでの処理である。

また、スレッド４は、オペレーティングシステム（ＯＳ）３に付随するスレッドライブラリにより自動生成される。スレッドライブラリは、プライオリティに応じてスレッド１、スレッド２及びスレッド３のメインプロセッサ（図５に示すＣＰＵ２２１）上での計算資源配分、即ちスケジューリングを行う。

また、スレッド５は、アプリケーションであるＧＵＩ８のメインスレッドであり、スレッド１、スレッド２及びスレッド３を生成したり破棄したりすると共に、プログラミングされたアルゴリズム或いはユーザ操作に応じてスレッド１、スレッド２及びスレッド３の制御を行う。

ＲＴＰ／ＲＴＣＰパケットの送信処理であるスレッド１においては、マイクからユーザの音声をキャプチャしてＰＣＭデータを受け取り（Capture）、必要に応じて、ＢＧＭ合成部５等により、キャプチャサンプル・フレーム毎に、効果音及びＢＧＭと音声とを合成し（Effect or Mixing）、コーデック１３は、そのデータを圧縮符号化する（encode）。そして、ＲＴＰ／ＲＴＣＰ制御部１２が圧縮符号化したデータをＲＴＰパケット化し（packet）、送信する（send）。

また、ＲＴＰパケットの送信処理とは別に、通信対象の通話装置におけるコーデックの圧縮符号化方式を制御するための制御情報を格納したＲＴＣＰパケットの送信処理が行われる。

一方、ＲＴＰパケットの受信処理においては、ＶｏＩＰクライアントの受信側に設けられたデコード処理前後の揺らぎ吸収バッファ、即ち、エンコードされたバイトストリームＰＣＭを格納する揺らぎ吸収バッファ（Forward Jitter buffer）ＢＦ１と、デコード処理後に設けられ、デコードされ無圧縮のlinearＰＣＭとされたデータを格納する揺らぎ吸収バッファ（Backward Jitter buffer）（以下、ＰＣＭバッファという。）ＢＦ２とを使用する。

ここで、揺らぎ吸収バッファＢＦ１は、後述するように、通話相手との間のＲＴＰパケットの受信状態に応じて、伝送の揺らぎを吸収するために必要な容量に自動調整されるものであり、無圧縮のデータを格納するためのＰＣＭバッファＢＦ２の容量は、ユーザが手入力できるようになされており、ＢＧＭ等が付加されるような高音質なデータのやり取りの際には、ユーザがこれを操作し、ＰＣＭバッファＢＦ２の容量を大きく設定しておくことができる。一方、通常の音声のみの通話を行う際等、低遅延で応答性を重視するような場合には、このＰＣＭバッファＢＦ２の容量を例えばゼロに設定することも可能である。

先ず、そして、ＲＴＰ／ＲＴＣＰパケットの受信機能のうち、スレッド２では、ＲＴＰ／ＲＴＣＰ制御部１２がＲＴＰパケットを受信し（Receive）、ネットワーク上で発生したデータ損失及び転送パケットのデータエラー等の欠落パケットを補う処理、例えばパケットの再送要求等を行い（parse）、デコード処理前に設けられた揺らぎ吸収バッファＢＦ１に格納する（push＆pop）する。これをコーデック１３が復号伸張し（decode）、デコード処理後に設けられるＰＣＭバッファＢＦ２に、無圧縮のデータとして格納する（push）。

そして、スレッド３においては、ＵＳＢカメラドライバ２ａ、ＵＳＢオーディオドライバ２ｂ及び各種ドライバ２ｃが、ＰＣＭバッファＢＦ２から無圧縮のデータを読み出し（pop）、この読み出したデータを再生する（sound device）。ここで、このＰＣＭバッファＢＦ２が大きければ、ＰＣＭバッファＢＦ２にデータがバッファリングされてから読み出されるまでの時間が長くなる。即ち、受信したパケットの再生予定時刻にゆとりができ、欠落パケットの再送要求をし、これを再生予定時刻までに受信することができる時間的な幅が広がる。

また、スレッド１にて行うエフェクト効果及びＢＧＭと音声との合成（Effect or Mixing）は、スレッド３において、ＰＣＭバッファＢＦ２からデータを読み出した後であって、再生する前に行ってもよい。

ここで、デコード処理前に設けられた揺らぎ吸収バッファＢＦ１の容量（バッファサイズ）は、以下のようにして求めることができる。図７は、ＲＴＰパケット送信者（ＲＴＰSender）としてのＶｏＩＰクライアントＵＡＳと、ＲＴＰパケット受信者（ＲＴＰReceiver）としてのＶｏＩＰクライアントＵＡＲとの間のＲＴＰパケットのやり取りを示す図であって、ＲＴＣＰを利用したRound Trip Timeの計算方法を示すシーケンス図である。

図７において、Ｓｉ、Ｓｊは、時刻ｉ、ｊに送信側ＶｏＩＰクライアントＵＡＳから送られるＲＴＰパケットＰ（ｉ）、Ｐ（ｊ）の送信時刻（Ｓｉ＝10 Nov 1995 11:33:25.125、Ｓｊ＝10 Nov 1995 11:33:25:145）を示し、Ｒｉ、Ｒｊは、時刻ｉ、ｊに受信側のＶｏＩＰクライアントＵＡＲが受け取るＲＴＰパケットＰ（ｉ）、Ｐ（ｊ）の到着時刻（Ｒｉ＝10 Nov 1995 11:37:23.235、Ｒｊ＝10 Nov 1995 11:37:24.002）を示す。

そして、ＶｏＩＰ通話制御部７は、ＲＴＰパケットのタイムスタンプを使用し、ＲＦＣ１８８９に記述された下記計算式から、２つのパケットＰ（ｉ）、Ｐ（ｊ）の送信時及び受信時における到着間隔の差Ｄを求め、これによりジッタＪを算出することができる。
Ｄ（ｉ，ｊ）＝（Ｒｊ−Ｒｉ）−（Ｓｊ−Ｓｉ）＝（Ｒｊ−Ｓｊ）−（Ｒｉ−Ｓｉ）
Ｊ＝Ｊ＋（｜Ｄ（ｉ−１，ｉ）｜−Ｊ）／１６
これにより、ミリ秒・マイクロ秒単位で、図６に示す、エンコードされた状態の受信データをバッファリングする揺らぎ吸収バッファＢＦ１の容量を算出することができる。

そして、必要に応じて、揺らぎ吸収バッファＢＦ１の容量を自動調整し、自動調整した揺らぎ吸収バッファＢＦ１に対して、ＲＴＰパケットを、挿入及び取り出しの順で処理を実行する（スレッド２のpush＆pop）。

そして、上述したように、揺らぎ吸収バッファＢＦ１から取り出したバイトストリームをデコードし、必要ならばサウンドデバイスに書き込み再生を行う。ここで、必要に応じてサウンドデバイスに書き込む前に、デコードしたデータをＰＣＭバッファＢＦ２に挿入する。

次に、本実施の形態におけるＶｏＩＰシステムにおけるＲＴＰ／ＲＴＣＰパケットについて更に具体的に説明する。

図３に示すＳＩＰ制御部１１の呼制御により、ＲＴＰ／ＲＴＣＰパケットは、ＲＴＰ／ＲＴＣＰのセッションを確立した後、送受信が開始される。図８（ａ）及び（ｂ）は、ＲＴＰパケットの夫々構成及びヘッダのフォーマットを示す図であり、図９（ａ）乃至（ｃ）は、アプリケーションによって拡張可能なＲＴＣＰ ＡＰＰパケットの構成、そのヘッダ（RTCP APP Application-defined Header）、及び送信レポートのフォーマット例を示す図である。

ＲＴＰは、インターネット等のＩＰネットワークにおいて、リアルタイムに音声や動画を送信／受信するトランスポート・プロトコルであり、ＲＦＣ１８８９で勧告されている。ＲＴＰは、トランスポート層に位置し、一般にＵＤＰ上でＲＴＣＰと共に用いられる。

そして、図８（ａ）に示すように、ＲＴＰパケットは、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダ及びＲＴＰデータからなる。そして、ＲＴＰヘッダには、図８（ｂ）に示すように、先頭から、バージョン情報格納部（Ｖ：version、例えばＶ＝２）Ｆ１、パディング格納部（Ｐ：padding）Ｆ２、拡張ビット格納部（Ｘ：extension）Ｆ３、ＣＳＲＣ（contributing source）カウント格納部（ＣＣ）Ｆ４、マーカ情報（Ｍ：marker）格納部Ｆ４、マーカ・ビット格納部（Ｍ：maker）Ｆ５、ペイロード種別情報格納部（ＰＴ：payload type）Ｆ６、シーケンス番号情報格納部（sequence number）Ｆ７、タイムスタンプ格納部（time stamp）Ｆ８、ＳＳＲＣ識別子格納部（synchronization source identifier）Ｆ９、ＣＳＲＣ識別子格納部Ｆ１０が設けられ、ＣＳＲＣ識別子格納部Ｆ１０の後ろに実時間音響データが付加される。

バージョン情報格納部Ｆ１には、ＲＴＰのバージョンを示す情報が格納され、例えばＲＴＰ２を示すときには、その旨のバージョン情報が格納される。

カウント格納部Ｆ４は、ヘッダ中に示されるＣＳＲＣ（寄与送信元識別子）の数を示す。

ペイロード種別情報格納部Ｆ６には、実時間音響データの種類を示す情報が格納され、例えば映像や音声を示す旨の情報等が格納される。

シーケンス番号情報格納部Ｆ７には、ＲＴＰセッションにおいて、ＲＴＰパケットを送受信する度にカウントアップされ、送受信するＲＴＰパケットの順番を認識するためのシーケンス番号が格納される。

タイムスタンプ格納部Ｆ８には、実時間音響データを作成、更新した日時に関するタイムスタンプ情報が格納される。

ＳＳＲＣ識別子格納部Ｆ９及びＣＳＲＣ識別子格納部Ｆ１０には、ＲＴＰセッションにおいて、データ送信側のソースを識別するための情報が格納される。ＳＳＲＣ識別子は、同期送信元識別子であり、同一ユーザが組み合わせて扱うべき複数のストリームが同じ値を共有するように割り当てた識別子であり、ＣＳＲＣ識別子は、寄与送信元識別子であり、ストリーム源を示す。複数のストリームがミキシング処理され１つのストリームデータとして提供される場合等に使用される。

図３に示すＲＴＰ／ＲＴＣＰ制御部８は、ＲＴＰに従って実時間音響データを送信するに際して、上記各格納部に各種情報を格納すると共に、各格納部に格納された各種情報を認識して実時間音響データを抽出する処理をする。

上述のＲＴＰが音声・動画像データそのものを送信／受信するプロトコルであるのに対し、ＲＴＣＰは、周期的に、パケットロス、遅延ジッタ、ラウンドトリップ等の回線品質を評価し、その帯域に見合ったリアルタイム通信を実現するため情報を送信／受信するプロトコルである。

このＲＴＣＰを用いることにより、相手からフィードバックされてくる情報により、ネットワークの状態などを推測して送信レートを変更するなどの動的な処理を行うことができる。また、今誰がデータを送信していて、誰が受信しているかを示す情報もＲＴＣＰパケットで同時に送っているので、今現在の参加者の情報を知ることもできる。

図９（ａ）に示すように、ＲＴＣＰパケットは、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＣＰヘッダ及びＲＴＣＰデータからなる。そして、拡張可能なＲＴＣＰパケットであるＲＴＣＰ ＡＰＰパケットのヘッダには、図９（ｂ）に示すように、先頭から、バージョン情報格納部（Ｖ：version、例えばＶ＝２）Ｆ１１、パディング格納部（Ｐ：padding）Ｆ１２、subtype格納部Ｆ１３、マーカ情報（Ｍ：marker）格納部Ｆ１４、パケットタイプ（ＰＴ：packet type）格納部Ｆ１５、レポート長格納部（length）Ｆ１６、ＳＳＲＣ／ＣＳＲＣ識別子格納部Ｆ１７、アスキー（ＡＳＣＩＩ：American Standard Code for Information、情報交換用アメリカ標準コード）で記述されるＮａｍｅ格納部Ｆ１８が設けられ、この後に、アプリケーション独自のデータが格納されるデータ格納部（Application-Dependent Data）Ｆ１９が付加される。

パケットタイプＰＴ格納部Ｆ１５には、ＲＴＣＰパケットの種別が記録され、本実施の形態においては、このパケットタイプＰＴ＝ＡＰＰ（Application：アプリケーション固有情報）＝２０４（パケットタイプ値）と記述される。ＡＰＰは、ＲＴＣＰ規定外のアプリケーション固有の制御情報を通知するためのパケットであることを示す。

図３に示すＲＴＰ／ＲＴＣＰ制御部８は、ＲＴＣＰ ＡＰＰパケットとして、上述したように、欠落パケットの再送要求をＲＴＰパケットを受信した際のジッタを吸収するために使用するＲＴＰパケット受信のための揺らぎ吸収バッファの容量をデータ格納部Ｆ１９に記述して送信することができる。そして同時に、ＶｏＩＰ通話制御部３の指示により、通信相手が送信すべき送信データにおける圧縮する周波数成分の情報を記述して送信することができる。

ここで、ＲＴＣＰパケットには、ＲＴＰデータの送信者から送られるタイプのＲＴＣＰ ＳＲ（Sender Report、）パケットと、ＲＴＰデータの受信者から送られるタイプのＲＴＣＰパケットＲＴＣＰ ＲＲ（Receiver Report、）パケットとがある。

ＳＲパケットは、ストリームを送出している端末から他の端末に対して送出されるもので、自装置が送出したストリームに関する情報である送信情報（sender info）と、受信したストリーム各々についてストリームの受信状態（パケット破棄率、ジッタ等）を送信装置へ報告するためのレポートブロック（reception report block）とを含み、ＲＲパケットは、他の通話装置から受信したスリームに関する情報を通知するためのもので、同じく受信したストリーム各々についてストリームの受信状態を送信装置へ報告するためのレポートブロックを含むものである。

このレポートブロックは、図９（ｃ）に示すように、パケットの送信者の同期送信元(ＳＳＲＣ：Synchronization Source)識別子、ＲＴＰ損失率、損失ＲＴＰパケット数、受信シーケンス番号、到着時間間隔のジッタの平均値、最後に受信したＳＲの送信時刻（ＬＳＲ：Last SR timestamp）、最後にＳＲを受信した時刻からこのＲＲを送るまでの時間（ＤＬＳＲ：Delay since Last SR）を入れることになっている。

したがって、送信側においては、ＲＴＰデータの送信の際に、送信ＲＴＰパケット数及び送信ＲＴＰバイト数を管理しておき、また、受信側においては、ＲＴＰデータの受信の際に、受信ＲＴＰパケット数、損失ＲＴＰパケット数及び到着時間のジッタ等の管理情報を管理する。

図１０は、本実施の形態におけるＲＴＣＰ ＡＰＰメッセージの交換時にやりとりされるメッセージを示す図である。ＲＴＰのSenderでもありReceiverでもあるＵＡ１とＵＡ２との間でやり取りされるＳＲ（Sender Report）を含むＲＴＣＰ ＡＰＰパケット及びＲＲ（Receiver Report）を含むＲＴＣＰ ＡＰＰパケットにおいては、図１０に示すように、拡張データとして、エンコード帯域幅（Encode Bandwidth）、サブバンド分割ブロック数（sub band Numbers）、デコード処理部前後の揺らぎ吸収バッファ容量（Forward and Backward Jitter Buffer size）、上記吸収バッファにキューイングされているデータサイズ（Buffer queued size）、ＲＴＰパケットの再送リクエスト情報（Re-Request：sequence number）を記述することができる。ＲＴＰパケットの再送リクエストにはシーケンス番号を利用する。

なお、デコード処理前の揺らぎ吸収バッファＢＦ１の容量及びデコード処理後の揺らぎ吸収バッファであるＰＣＭバッファＢＦ２、並びにこれらバッファにキューイングされているデータサイズは、時間に換算可能である。

ここで、上述したように、本実施の形態におけるＶｏＩＰクライアントは、ＰＣＭバッファＢＦ２のバッファサイズ（バッファ容量）をユーザ操作に基づき変更することができる。ＰＣＭバッファＢＦ２のバッファ容量を変更する場合は、例えば、図４に示すＧＵＩ８のバッファ調整部６９を使用し、ユーザが必要に応じて適宜調整するようにすればよい。また、ＲＴＰパケットの受信側では、ＲＴＰパケットの受信ビットレートを常時又は定期的に計測（算出）することができ、算出した受信ビットレートに応じて、ユーザ自身がＰＣＭバッファＢＦ２の容量を調整するようにしてもよい。例えば、受信ビットレートをＶｏＩＰクライアントがユーザに通知し、ユーザはこの受信ビットレートを基にＰＣＭバッファＢＦ２の容量を変更してもよい。

そして、このＲＴＣＰ ＡＰＰパケットにより、調整したＰＣＭバッファＢＦ２のバッファ容量を通話相手となる他のＶｏＩＰクライアントへ通知することにより、他のＶｏＩＰクライアントがそのバッファ容量に応じて送信データの伝送レートを変更することができる。更に、吸収バッファにキューイングされているデータサイズ（揺らぎ吸収バッファＢＦ１やＰＣＭバッファＢＦ２にバッファリングされているデータ占有量）から、バッファの空容量を正確に認識することができ、これに基づき伝送レートを変更することができる。

また、ＶｏＩＰクライアントは、ＳＲ（Sender Report）ブロックを含むＲＴＣＰパケットを送信してからＲＲ（Receiver Report）ブロックを含むＲＴＣＰパケットを受信するまでの時間からＤＬＳＲ（Delay since Last Sender Report）を差し引いた結果算出するＲＴＴ（Round Trip Time）を測定し、これと自身の揺らぎ吸収バッファＢＦ１又はＰＣＭバッファＢＦ２の容量とに基づき、欠落パケットの再送要求を行うことで、特にＢＧＭ等の欠落パケットの影響を受けやすいデータを送受信する場合の品質を維持することができる。

即ち、ＲＴＴにより、再送要求したパケットが再送されてくるまでの時間情報が得られるため、再送要求したパケットが到着する時刻よりそのパケットのデコードを開始予定時間又はデコードしたデータを再生する再生予定時間が遅いときは、欠落パケットの再送要求を行うことができる。

従って、ＰＣＭバッファＢＦ２の容量をユーザ操作により可変とすることにより、パケットが届いてからそのパケットに格納されたデータが再生される再生予定時刻までの間、即ち再送要求できる期間を調整することができ、例えば、音声のみの通話を行うような場合、即ち多少の音質低下よりも遅延が少ないことが重要であるような、必ずしも再送要求する必要がない場合には、ＰＣＭバッファＢＦ２の容量を小さく又はゼロに設定しておけばよい。

一方、ＢＧＭ等の付加データを合成して送受信し合うような場合、即ち多少の遅延よりも高音質であることが重要であるような場合は、ＰＣＭバッファＢＦ２の容量を大きくしておけば、欠落パケットの再送要求ができ、ユーザはエラー及び損失がないデータを再生出力させることができる。

また、揺らぎ吸収バッファＢＦ２のバッファ容量の通知を受けた通信相手のＶｏＩＰクライアントは、このバッファＢＦ２の容量に応じて、即ち、ＰＣＭバッファＢＦ２の容量が大きいときは、伝送ビットレートを上げて高音質な送信データとし、ＰＣＭバッファＢＦ２の容量が小さい場合には、例えばＢＧＭを付加せず音声のみを送信することで伝送ビットレートを下げ低遅延を達成するように伝送レートを可変とすることができる。

なお、アプリケーション固有情報ＡＰＰとして、デコード処理前後の揺らぎ吸収バッファＢＦ１及びＢＦ２のバッファ容量、この揺らぎ吸収バッファＢＦ１及びＢＦ２を占有しているデータ量の情報、欠落パケットの再送要求等の制御情報に加え、受信側のＶｏＩＰクライアンが送信側のＶｏＩＰクライアントの送信データのエンコード帯域幅及びサブバンド分割ブロック数等を指定する情報を記載することにより、通信相手の圧縮符号化方式を指定することで自身が受信するストリームの伝送レートを制御することも可能である。

本実施の形態においては、圧縮された音声データを復号するデコード処理部の前に、ＲＴＰパケットのヘッダを用いて算出したジッタ値分の容量を自動的に確保可能な揺らぎ吸収バッファＢＦ１を用意し、デコード処理部の後に、ユーザが手入力した容量分のＰＣＭバッファである揺らぎ吸収バッファＢＦ２を用意することで、低遅延を望むユーザのニーズと高音質を臨むユーザのニーズとの両方満たすことができる。

即ち、低遅延を重視した自動調整バッファである揺らぎ吸収バッファＢＦ１に加えて、ユーザの手入力で調整できるＰＣＭバッファＢＦ２を用意することで、欠落パケットの再送要求が有効になる時間軸上の幅が広がり、高音質な状態で録音をしたい場合等において、音質を重視した受信が可能になり、低遅延か高音質かのトレードオフをユーザ操作にゆだねることができる。

こうしてＶｏＩＰクライアントが受信側となる場合には、低遅延か高音質かの受信状態を選択することができ、送信側となる場合には、通信相手の揺らぎ吸収バッファＢＦ１及びＰＣＭバッファＢＦ２のバッファ容量に応じて、通信相手のニーズに応じた伝送レートの送信データを送信することができる。

本発明の実施の形態におけるＶｏＩＰシステムの一例を示す模式図である。 本発明の実施の形態におけるＶｏＩＰシステムのうち、ＶｏＩＰクライアント１１１とインターネット１３０とからなる要部を示すブロック図である。 本発明の実施の形態におけるＶｏＩＰシステムが有するＶｏＩＰクライアントとして、一般的なＰＣを使用した場合におけるＶｏＩＰクライアントアプリケーションを示す図である。 上記ＶｏＩＰクライアントアプリケーションにおけるＧＵＩの一例を示す模式図である。 本発明の実施の形態におけるＶｏＩＰシステムにおけるＶｏＩＰクライアント（ＶｏＩＰクライアント）のハードウェア構成を示すブロック図である。 図３に示すＶｏＩＰクライアントアプリケーションのうち、ＲＴＰ／ＲＴＣＰパケットを送受信する処理を示す機能ブロック図である。 ＲＴＣＰを利用したRound Trip Timeの計算方法を示すシーケンス図である。 （ａ）及び（ｂ）は、夫々ＲＴＰパケットの構成及びヘッダのフォーマットを示す図である。 （ａ）乃至（ｃ）は、アプリケーションによって拡張可能なＲＴＣＰ ＡＰＰパケットの構成、そのヘッダ（RTCP APP Application-defined Header）、及び送信レポートのフォーマット例を示す図である。 本実施の形態におけるＶｏＩＰシステムにおいて、ＲＴＣＰ ＡＰＰメッセージの交換時にやりとりされるメッセージを示す図である。

符号の説明

１ ＶｏＩＰクライアントアプリケーション、２１ 送信手段、２２ マイクキャプチャ、２３ 効果音ファイル読み込み部、２４ ＢＧＭファイル読み込み部、２５，２６，３１ デコーダ、２７，２８，２９ ゲイン調整部、３０ 合成部、３１ エンコーダ、３２ パケット化部、３３ 送信部、４１ 受信手段、４２ 受信部、４３ デパケッタイズ部、４４ デジッタ部、４５ パケット補償部、４６ デコーダ、４７ 読み出し部、４８ 復号部、４９，５０，５１，５２ ゲイン調整部、５３ 合成部、５４ 出力部、５５ スピーカ、１００ ＶｏＩＰ通信システム、１１１、１２１ ＶｏＩＰクライアント、１１０，１２０ ユーザ、１１２，１２２ ウェブブラウザ、１３４ ウェブサーバ、１１３、１２３ 音源データ、１３０ インターネット

Claims (9)

1. インターネットを介して実時間音響データの送受信を行う通話装置において、
   音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、
   上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、
   少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、
   上記データパケット及び上記制御パケットを上記インターネットを介して１以上の他の通話装置に送信する送信手段と、
   上記１以上の他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、
   上記受信したデータパケットをバッファリングする揺らぎ吸収バッファと、
   上記受信したデータパケットに格納された圧縮符号化データを復号伸張する復号伸張手段と、
   上記復号伸張したデータをバッファリングするバッファと、
   上記バッファの容量をユーザの指示に基づき制御する制御手段とを有し、
   上記揺らぎ吸収バッファの容量は、受信するデータパケットの伝送レートに基づき自動調整される
   通話装置。
2. 上記制御手段は、上記バッファの容量に応じて欠落データパケットの再送要求を指示する再送要求指示情報を生成し、上記制御パケットに格納させる
   請求項１記載の通話装置。
3. 上記制御手段は、少なくとも上記バッファの容量を示すバッファ情報を上記制御パケットに格納させると共に、上記他の通話装置からの制御パケットに格納されたバッファ情報に基づき上記データパケットの伝送レートを制御する
   請求項１記載の通話装置。
4. 上記制御手段は、上記他の通話装置からのデータパケットの伝送レートを計測し、上記ユーザに通知する
   請求項１記載の通話装置。
5. インターネットを介して実時間音響データの送受信を行う通話方法において、
   音声を含む実時間音響データを圧縮符号化する圧縮符号化工程と、
   上記圧縮符号化工程にて圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成工程と、
   少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成工程と、
   上記データパケット及び上記制御パケットを上記インターネットを介して１以上の他の通話装置に送信する送信工程と、
   上記１以上の他の通話装置からのデータパケット及び制御パケットを受信する受信工程と、
   上記受信したデータパケットを揺らぎ吸収バッファにバッファリングするバッファリング工程と、
   上記受信したデータパケットに格納された圧縮符号化データを復号伸張する復号伸張工程と、
   上記復号伸張したデータをバッファリングするバッファの容量をユーザの指示に基づき制御する制御工程とを有し、
   上記揺らぎ吸収バッファの容量は、受信するデータパケットの伝送レートに基づき自動調整される
   通話方法。
6. 上記バッファの容量に応じて生成された欠落データパケットの再送要求を指示する再送要求指示情報を生成し、上記制御パケットに格納させる再送要求生成工程を有する
   請求項５記載の通話方法。
7. 少なくとも上記バッファの容量を示すバッファ情報を上記制御パケットに格納させるバッファ情報生成工程と、
   上記他の通話装置からの制御パケットに格納されたバッファ情報に基づき上記データパケットの伝送レートを制御する伝送レート制御工程とを有する
   請求項５記載の通話方法。
8. 上記他の通話装置からのデータパケットの伝送レートを計測し、上記ユーザに通知する工程を有する
   請求項５記載の通話方法。
9. ２以上の通話装置がインターネットを介して実時間音響データの送受信を行う通話システムにおいて、
   各上記通話装置は、
   音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、
   上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、
   少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、
   上記データパケット及び上記制御パケットを上記インターネットを介して１以上の他の通話装置に送信する送信手段と、
   上記１以上の他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、
   上記受信したデータパケットをバッファリングする揺らぎ吸収バッファと、
   上記受信したデータパケットに格納された圧縮符号化データを復号伸張する復号伸張手段と、
   上記復号伸張したデータをバッファリングするバッファと、
   上記バッファの容量をユーザの指示に基づき制御する制御手段とを有し、
   上記揺らぎ吸収バッファの容量は、受信するデータパケットの伝送レートに基づき自動調整され、
   少なくとも２つの通話装置のうち一方の上記通信装置の上記制御手段は、少なくとも上記バッファの容量を示すバッファ情報を上記制御パケットに格納させ、
   他方の通話装置の上記制御手段は、上記一方の通話装置からの制御パケットに格納されたバッファ情報に基づき当該一方の通話装置に送信するデータパケットの伝送レートを制御する
   通話システム。

Images