(57)【要約】【課題】  音声にＢＧＭ及び効果音等を合成した高音質な音声コミュニケーションをインターネットを介して行う際に、通話を遮断することなく、ネットワーク帯域に応じて符号化・伝送する音響周波数成分を動的に決定する。【解決手段】  ＶｏＩＰクライアントは、音声にＢＧＭや効果音を合成したデータを高能率圧縮符号化し、これをＲＴＰパケット化して通話相手となる他のＶｏＩＰクライアントと送受信することで通話を行う。このＶｏＩＰクライアントは、上記他のＶｏＩＰクライアントがエンコードすべき帯域を指定するエンコード帯域幅、該エンコード帯域幅を分割するサブバンド分割ブロック数等の制御情報を記述したＲＴＣＰ  ＡＰＰパケットを上記他のＶｏＩＰクライアントに送信する。このＲＴＣＰパケットを受信した他のＶｏＩＰクライアントは、この制御情報に基づきコーデックを変更してＲＴＰパケットを送信する。【選択図】  図１１
2005045739.tif 000002
【特許請求の範囲】
【請求項１】
インターネットを介して実時間音響データの送受信を行う通話装置において、
音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、
上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、
少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、
１以上の他の通話装置に対して、上記データパケット及び上記制御パケットを送信する送信手段と、
上記他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、
上記他の通話装置からのデータパケットの伝送レートを制御する制御情報を生成する制御手段とを有し、
上記制御パケット生成手段は、上記管理情報と共に上記制御情報を格納した上記制御パケットを生成する
ことを特徴とする通話装置。
【請求項２】
上記制御手段は、上記受信手段が受信する上記他の通話装置からのデータパケットの伝送レートを計測し、該計測結果に基づき上記制御情報を生成する
ことを特徴とする請求項１記載の通話装置。
【請求項３】
上記制御手段は、ユーザ操作に基づき上記制御情報を生成する
ことを特徴とする請求項１記載の通話装置。
【請求項４】
上記制御情報は、上記他の通話装置からのデータパケットに格納される実時間音響データの圧縮率を制御する情報を有する
ことを特徴とする請求項１記載の通話装置。
【請求項５】
上記圧縮率を制御する情報は、上記他の通話装置からのデータパケットに格納される実時間音響データの圧縮すべき周波数帯域を指定する情報を有する
ことを特徴とする請求項４記載の通話装置。
【請求項６】
上記圧縮率を制御する情報は、上記他の通話装置からのデータパケットに格納される実時間音響データのサブバンド分割数を指定する情報を有する
ことを特徴とする請求項４記載の通話装置。
【請求項７】
上記受信手段は、受信した上記データパケットをバッファリングする受信バッファを有し、
上記制御手段は、上記受信バッファのサイズに応じて欠落データパケットの再送要求を指示する再送要求指示情報を生成し、
上記制御パケット生成手段は、上記再送要求指示情報を格納した上記制御パケットを生成する
ことを特徴とする請求項１記載の通話装置。
【請求項８】
上記データパケットに格納された実時間音響データは、音声とバックグラウンドミュージック及び／又は効果音とが合成されたものである
ことを特徴とする請求項１記載の通話装置。
【請求項９】
上記圧縮符号化手段は、上記他の通話装置からの制御パケットに格納された上記伝送レートを制御する制御情報に基づき上記他の通話装置に送信する実時間音響データの圧縮率を変更する
ことを特徴とする請求項１記載の通話装置。
【請求項１０】
インターネットを介して実時間音響データの送受信を行う通話方法において、
音声を含む実時間音響データを圧縮符号化する圧縮符号化工程と、
上記圧縮符号化工程にて圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成工程と、
少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成工程と、
１以上の他の通話装置に対して、上記データパケット及び上記制御パケットを送信する送信工程と、
上記他の通話装置からのデータパケット及び制御パケットを受信する受信工程と、
上記他の通話装置からのデータパケットの伝送レートを制御する制御情報を生成する制御工程とを有し、
上記制御パケット生成工程では、上記管理情報と共に上記制御情報を格納した上記制御パケットを生成する
ことを特徴とする通話方法。
【請求項１１】
上記制御工程では、上記受信工程にて受信する上記他の通話装置からのデータパケットの伝送レートを計測し、該計測結果に基づき上記制御情報を生成する
ことを特徴とする請求項１０記載の通話方法。
【請求項１２】
上記制御工程では、ユーザ操作に基づき上記制御情報を生成する
ことを特徴とする請求項１０記載の通話方法。
【請求項１３】
上記制御情報は、上記他の通話装置からのデータパケットに格納される実時間音響データの圧縮率を制御する情報を有する
ことを特徴とする請求項１０記載の通話方法。
【請求項１４】
上記圧縮率を制御する情報は、上記他の通話装置からのデータパケットに格納される実時間音響データの圧縮すべき周波数帯域を指定する情報を有する
ことを特徴とする請求項１３記載の通話方法。
【請求項１５】
上記圧縮率を制御する情報は、上記他の通話装置からのデータパケットに格納される実時間音響データのサブバンド分割数を指定する情報を有する
ことを特徴とする請求項１３記載の通話方法。
【請求項１６】
上記制御工程では、受信した上記データパケットをバッファリングする受信バッファの容量に応じて欠落データパケットの再送要求を指示する再送要求指示情報を生成し、
上記制御パケット生成工程では、上記再送要求指示情報を格納した上記制御パケットを生成する
ことを特徴とする請求項１０記載の通話方法。
【請求項１７】
上記データパケットに格納された実時間音響データは、音声とバックグラウンドミュージック及び／又は効果音とが合成されたものである
ことを特徴とする請求項１０記載の通話方法。
【請求項１８】
上記圧縮符号化工程では、上記他の通話装置からの制御パケットに格納された上記伝送レートを制御する制御情報に基づき上記他の通話装置に送信する実時間音響データの圧縮率を変更する
ことを特徴とする請求項１０記載の通話方法。
【請求項１９】
２以上の通話装置がインターネットを介して実時間音響データの送受信を行う通話システムにおいて、
各通話装置は、
音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、
上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、
少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、
１以上の他の通話装置に対して、上記データパケット及び上記制御パケットを送信する送信手段と、
上記他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、
上記他の通話装置からのデータパケットの伝送レートを制御する制御情報を生成する制御手段とを有し、
少なくとも２つの通話装置の一方の上記制御パケット生成手段は、上記管理情報と共に他方の通話装置からのデータパケットの伝送レートを制御する上記制御情報を格納した上記制御パケットを生成し、
上記他方の通話装置の上記圧縮符号化手段は、上記一方の通話装置からの制御パケットに格納された上記制御情報に基づき該一方の通話装置に送信する実時間音響データの圧縮率を変更する
ことを特徴とする通話システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えばＶｏＩＰ（Voice over Internet Protocol）を使用したいわゆるインターネット電話等を行う通話装置、通話方法及び通話システムに関し、特に高音質の音声及び音響からなる実時間音響データをやり取りするために好適な通話装置、通話方法及び通話システムに関する。
【背景技術】
【０００２】
音声をＩＰパケットにしてカプセル化することでＩＰ網を介した音声通話を可能とする技術として、ＶｏＩＰがある。ＶｏＩＰによる通話を行うためには、通話したい相手の情報の取得、通話したい相手の呼び出し、応答といった一連の情報交換をする必要があり、これらの目的のために、ＳＩＰ（Session Initiation Protocol）等の呼制御プロトコルが使用される。
【０００３】
近年、このようなＶｏＩＰを含め、インターネット等の通信回線網を利用し、実時間動画像データや、音声データ等の実時間音響データ等の実時間データを送信するシステムが増えている。このようなインターネット等の公衆回線網においては、複数の利用者がネットワークの帯域を供給しているため、輻輳制御手法、すなわち輻輳の回避及び輻輳発生時の鎮静化手法が大きな課題となっている。従って、実時間性を重要とする通信形態が増えるという変化に伴い、実時間データの通信における輻輳制御手法が重要になってきている（下記特許文献１参照）。
【０００４】
ところで、従来、ＶｏＩＰを使用した実時間音声コミュニケーションにおいては、人の音声の主たる情報が含まれているのは、４〜５KHz付近の周波数帯域であったため、チャンネル数は１、標本化周波数を８KHz〜１６KHzに設定するのが常道であった。しかし、このような狭い帯域では背景雑音や雰囲気等を伝達するのは困難である。
【０００５】
そこで、チャンネル数を２以上に設定し、標本化周波数をＣＤＤＡ（Compact Disk Digital Audio）並の４４．１KHzまで引き上げると、背景雑音や雰囲気等も伝送でき、また加えて、音声コミュニケーションに、既存の楽曲コンテンツを流用した高音質なＢＧＭ機能等を付加することなども可能になる。
【０００６】
ところがチャンネル数を２以上に設定し、標本化周波数をＣＤＤＡ並の４４．１KHzまで引き上げて、無圧縮の１６bits LinearＰＣＭ（Phase Code Modulation：パルス符号変調）のデータを伝送する場合、ネットワーク上の伝送ビットレートは１４１１．２Kbps以上になってしまい、実インターネット環境で利用するのは難しい。したがって、現状では高能率符号化方式を用いる必要があるが、近時のＣＰＵの性能の向上により、実時間音声コミュニケーションにおいても高能率符号化方式を採用することが可能になってきている。
【０００７】
なお、高能率符号化方式にはいくつかの方式があるが、先ず周波数分解を行い、信号を複数のサブバンドに分割したうえ、それぞれのブロックを、聴覚心理特性を利用して符号化精度を適応的に変化させて、必要最低限のビット数で所定の周波数成分をエントロピー符号するものが殆どである。この高能率符号化により、符号化する周波数成分に応じてビットレートは可変になる。
【０００８】
即ち、従来の一般の電話のように、伝送ビットレートも音のクオリティも低い場合には、ネットワーク状況に応じて動的に圧縮方式のパラメータを変更して輻輳制御をする必要が生じなかったものの、ＢＧＭ機能等を付加したような高音質な実時間音響データをやり取りする実時間音声コミュニケーションを行う場合には、ネットワークのデータ伝送レートが高くなる。したがって、通話中に何らかの要因でネットワーク帯域が混雑しはじめた場合、通話が一時的に遮断されることを余儀なくされることが少なくなく、このようなＢＧＭ機能が付加されているような高音質音声の実時間コミュニケーションにおいては、上記特許文献１のように、動的に圧縮方式のパラメータを変更する必要が生じる。
【０００９】
【特許文献１】特開２００１−３２００４４０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、ＶｏＩＰによる実時間音声コミュニケーションにおいては、基本的にはＳＩＰ等の呼制御プロトコルを用いてシグナリングを行い、通話相手のＩＰアドレス・ポート番号・音声及び音響圧縮方式を知る。そして、自身とその目標アドレスとの間で双方向にＲＴＰ（Real-Time Transport Protocol）及びＲＴＣＰ（Real-Time Control Protocol）のストリームを送受信するのが基本的な仕組みである。通常、一度ＲＴＰのストリームが確立されると、音声圧縮方式は再呼制御を行わない限り変更できない。また、再呼制御を行うと通話が一時的に遮断される。
【００１１】
即ち、符号化する周波数成分に応じて別々の音声・音楽圧縮方式として分類してしまうと、再呼制御が必要となるため、ネットワーク帯域が何らかの理由で混雑する等した際、そのままの伝送ビットレートであっても、伝送ビットレートを下げるために必要となる再呼制御によっても、通話が一時的に遮断されてしまうという問題点がある。そこで、同一の音声・音楽圧縮方式がネットワーク帯域に応じて、通話を遮断することなく動的にサブバンド分割数及び符号化すべき周波数成分を決定する仕組みの一般化が望まれる。
【００１２】
本発明は、このような従来の実情に鑑みて提案されたものであり、音声にＢＧＭ及び効果音等を合成した高音質な音声コミュニケーションをインターネットを介して行う際に、通話を遮断することなく、ネットワーク帯域に応じて符号化・伝送する音響周波数成分を動的に決定することができる通話装置、通話方法及び通話システムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
上述した目的を達成するために、本発明に係る通話装置は、インターネットを介して実時間音響データの送受信を行う通話装置において、音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、１以上の他の通話装置に対して、上記データパケット及び上記制御パケットを送信する送信手段と、上記他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、上記他の通話装置からのデータパケットの伝送レートを制御する制御情報を生成する制御手段とを有し、上記制御パケット生成手段は、上記管理情報と共に上記制御情報を格納した上記制御パケットを生成することを特徴とする。
【００１４】
本発明においては、他の通話装置からのデータパケットの伝送レートを制御する制御情報生成し、これを上記管理情報と共に格納した上記制御パケットとして他の通話装置に送信することで、これを受信する他の通話装置に対し、制御パケットの制御情報に基づき他の通話装置が送信するデータパケットの伝送レートを設定させることができる。即ち、ネットワーク帯域が急激に混雑し始めた場合や受信側で聞き取りにくい等の状態が生じた場合に、データパケットの受信側でデータパケットの送信側の送信データの伝送レートの制御をすることができ、またこの制御情報を、呼制御の際のメッセージではなく、制御パケットと共に送信するため、データパケットの送受信を停止する必要がない。
【００１５】
また、上記制御手段は、上記受信手段が受信する上記他の通話装置からのデータパケットの伝送レートを計測し、該計測結果に基づき上記制御情報を生成するか、又はユーザ操作に基づき上記制御情報を生成することができ、この制御情報としては、上記他の通話装置からのデータパケットに格納される実時間音響データの圧縮率を制御する情報、例えば上記他の通話装置からのデータパケットに格納される実時間音響データの圧縮すべき周波数帯域及び／又はサブバンド分割数を指定する情報等とすることができ。これにより、他の通話装置が送信してくるデータパケットに格納する実時間音響データの圧縮符号化方式を変更させることができる。
【００１６】
更に、上記受信手段は、受信した上記データパケットをバッファリングする受信バッファを有し、上記制御手段は、上記受信バッファのサイズに応じて欠落データパケットの再送要求を指示する再送要求指示情報を生成し、上記制御パケット生成手段は、上記再送要求指示情報を格納した上記制御パケットを生成することができ、他の通話装置からの伝送レートを制御する制御情報と供に、受信されるまでにエラーが生じるか又は伝送途中で失われる等した欠落パケットの再送要求を行う再送要求指示情報を制御パケットにて送信することができる。
【００１７】
更にまた、上記データパケットに格納された実時間音響データは、音声とバックグラウンドミュージック及び／又は効果音とが合成されたものであり、音声のみではなくバックグラウンドミュージック等が付加されて情報量が大きい送信データであっても必要に応じて伝送レートを制御することにより通信が遮断されることがない。
【００１８】
また、上記圧縮符号化手段は、上記他の通話装置からの制御パケットに格納された上記伝送レートを制御する制御情報に基づき上記他の通話装置に送信する実時間音響データの圧縮率を変更することができ、通話相手となる他の通話装置からの要求に応じて送信するデータパケットに格納する実時間音響データの圧縮率を変更し、送信するデータパケットの伝送レートを可変とすることができる。
【００１９】
本発明に係る通話方法は、インターネットを介して実時間音響データの送受信を行う通話方法において、音声を含む実時間音響データを圧縮符号化する圧縮符号化工程と、上記圧縮符号化工程にて圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成工程と、少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成工程と、１以上の他の通話装置に対して、上記データパケット及び上記制御パケットを送信する送信工程と、上記他の通話装置からのデータパケット及び制御パケットを受信する受信工程と、上記他の通話装置からのデータパケットの伝送レートを制御する制御情報を生成する制御工程とを有し、上記制御パケット生成工程では、上記管理情報と共に上記制御情報を格納した上記制御パケットを生成することを特徴とする。
【００２０】
本発明に係る通話システムは、２以上の通話装置がインターネットを介して実時間音響データの送受信を行う通話システムにおいて、各通話装置は、音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、１以上の他の通話装置に対して、上記データパケット及び上記制御パケットを送信する送信手段と、上記他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、上記他の通話装置からのデータパケットの伝送レートを制御する制御情報を生成する制御手段とを有し、少なくとも２つの通話装置の一方の上記制御パケット生成手段は、上記管理情報と共に他方の通話装置からのデータパケットの伝送レートを制御する上記制御情報を格納した上記制御パケットを生成し、上記他方の通話装置の上記圧縮符号化手段は、上記一方の通話装置からの制御パケットに格納された上記制御情報に基づき該一方の通話装置に送信する実時間音響データの圧縮率を変更することを特徴とする。
【００２１】
本発明においては、一方の通話装置が、自身の通話対象となる他方の通話装置が送信するデータパケットの伝送レートを制御することができ、また、他方の通話装置からの要求に応じて該他方の通話装置に送信する実時間音響データの圧縮符号化方式を変更して当該他方の通話装置に伝送するデータパケットの伝送レートを制御することができる。
【発明の効果】
【００２２】
本発明に係る通話装置によれば、インターネットを介して実時間音響データの送受信を行う通話装置において、音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、１以上の他の通話装置に対して、上記データパケット及び上記制御パケットを送信する送信手段と、上記他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、上記他の通話装置からのデータパケットの伝送レートを制御する制御情報を生成する制御手段とを有し、上記制御パケット生成手段は、上記管理情報と共に上記制御情報を格納した上記制御パケットを生成するので、データパケットの受信側で、制御パケットにより、データパケットの送信側となっている他の通話装置の送信伝送レートの制御をすることができ、例えばネットワーク帯域が急激に混雑し始めた場合や受信側で聞き取りにくい等の状態が生じた場合には通話相手となる他の通話装置が送信する伝送レートを再呼制御することなく下げさせることがき、よって高音質で情報量が大きい実時間音響データを送受信するような場合であっても通話を継続することができる。
【００２３】
また、本発明に係る通話システムによれば、２以上の通話装置がインターネットを介して実時間音響データの送受信を行う通話システムにおいて、各通話装置は、音声を含む実時間音響データを圧縮符号化する圧縮符号化手段と、上記圧縮符号化手段により圧縮符号化されたデータを格納したデータパケットを生成するデータパケット生成手段と、少なくとも上記データパケットの送受信を管理する管理情報を格納した制御パケットを生成する制御パケット生成手段と、１以上の他の通話装置に対して、上記データパケット及び上記制御パケットを送信する送信手段と、上記他の通話装置からのデータパケット及び制御パケットを受信する受信手段と、上記他の通話装置からのデータパケットの伝送レートを制御する制御情報を生成する制御手段とを有し、少なくとも２つの通話装置の一方の上記制御パケット生成手段は、上記管理情報と共に他方の通話装置からのデータパケットの伝送レートを制御する上記制御情報を格納した上記制御パケットを生成し、上記他方の通話装置の上記圧縮符号化手段は、上記一方の通話装置からの制御パケットに格納された上記制御情報に基づき該一方の通話装置に送信する実時間音響データの圧縮率を変更するので、一方の通話装置が、自身の通話対象となる他方の通話装置からのデータパケットの伝送レートを制御することができ、また、他方の通話装置からの要求に応じて他方の通話装置に伝送するデータパケットに格納する実時間音響データの圧縮符号化方式を変更して伝送レートを制御することができ、情報量が多い、例えばＢＧＭや効果音等が付加された等高音質な実時間音響データをやり取りするような場合であっても伝送レートを動的に変化させることができるので、ネットワーク帯域が混雑した場合でも通話が遮断されることがない。
【発明を実施するための最良の形態】
【００２４】
以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。この実施の形態は、本発明を、２以上の通話装置がインターネットを介してＶｏＩＰにより通話を行う通話装置としてのＶｏＩＰクライアント及びこれを備えた通話システムとしてのＶｏＩＰシステムに適用したものである。本実施の形態におけるＶｏＩＰクライアントは、通話装置間での通話継続を可能とするため、ネットワーク帯域に応じて、音質を可変にする、即ち同一の音声・音楽圧縮方式におけるサブバンド分割数及び符号化すべき周波数成分を動的に決定するものである。
【００２５】
先ず、本実施の形態におけるＶｏＩＰを使用したネットワークコミュニケーションをオ行うＶｏＩＰシステムの概略について説明する。図１は、本実施の形態におけるＶｏＩＰシステムの一例を示す模式図である。本実施の形態におけるＶｏＩＰシステムでは、例えば２チャンネル以上で、且つユーザ間で、通話のみではなく様々な効果音及びＢＧＭ等も共有することができる高音質の音声コミュニケーションを実現するものである。なお、本実施の形態におけるＶｏＩＰシステムは、２つの通話装置（以下、ＶｏＩＰクライアントという。）間で行なわれるものとするが、ＶｏＩＰシステムを構成するＶｏＩＰクライアントは２つに限らず、従ってＶｏＩＰクライアントを介してネットワークコミュニケーションに参加可能な参加者は２以上であってもよい。
【００２６】
図１に示すように、ＶｏＩＰシステム１００は、例えばＰＣ（Personal Computer）等のＶｏＩＰクライアント１１１と、これとインターネット１３０を介して接続されたＶｏＩＰクライアント１２１とを有する。
【００２７】
このＶｏＩＰシステム１００においては、ＶｏＩＰクライアント１１１のユーザ１１０と、ＶｏＩＰクライアント１２１のユーザ１２０とは、自身のＶｏＩＰクライアント１１１、１２１に搭載される後述するＶｏＩＰ用のアプリケーション（ソフト・フォン）等と、例えばマイクロフォンとヘッドフォンとからなるヘッドセット又はマイクロフォンと受話器とからなるハンドセットとを使用し、インターネット１３０を介して通信相手とコミュニケーションを行う。
【００２８】
インターネット１３０は、一般公衆回線等の通信回線や、情報通信ネットワークを複数接続することによって世界中に拡がったネットワーク環境である。現在、広帯域、高速な通信回線の普及によってブロードバンド伝送（Broadband Transmission）を可能としている。光ファイバー、非対称ディジタル加入者線、無線等を用い、５００ｋｂｐｓ以上の通信回線でネットワークを構成している。
【００２９】
このインターネット１３０には、ＶｏＩＰ通信を制御するＶｏＩＰサーバ１３１、及び音源データ１３２及びダウンロードユーザインフォメーション１３３等のデータを管理するウェブサーバ１３４等が接続されている。また、各ＶｏＩＰクライアント１１１、１２１には、各ＶｏＩＰクライアント１１１、１２１が有するウェブブラウザ１１２、１２２等によりウェブサーバ１３４からダウンロードするか、又は自身で購入若しくは編集した音源データ１１３、１２３が記憶されている。
【００３０】
ウェブサーバ１３４のデータベースに格納されている音源データ１３２、及びユーザがダウンロード等して所持している音源データ１１３、１２３は、例えばＢＧＭ（Back Ground Music）等に使用される音楽や、波の音・拍手の音・雷鳴・ベルの音等の各種効果音であり、これらの音源データは、ユーザ間のネットワークコミュニケーションにて使用することができる。
【００３１】
次に、このＶｏＩＰクライアントについて説明する。図２は、ＶｏＩＰシステムを構成するＶｏＩＰクライアントの機能を示すブロック図である。図２に示すように、このようなインターネットコミュニケーションを行うためのＶｏＩＰクライアント２０は、コミュニケーションに参加している参加者、即ち通話相手へデータを送信する送信手段２１と、通話相手からのデータを受け取る受信手段４１とを有する。
【００３２】
送信手段２１は、マイクが接続され、外部（ユーザ）の音声をキャッチするマイクキャプチャ（MIC capture）２２と、例えばＭＰ３（ＭＰＥＧ（Moving Picture Experts Group）１オーディオLayer３）、又はＭＰＥＧ４等に圧縮された各種効果音（Sound Effect：ＳＥ）の音源ファイルが記憶された効果音ファイル記憶部２３と、同じく圧縮された各種ＢＧＭの音源ファイルが記憶されたＢＧＭファイル記憶部２４と、効果音ファイル及びＢＧＭファイルを読み出しデコードする夫々デコーダ２５及び２６と、マイクによりキャプチャした音声、効果音、及びＢＧＭのゲインを制御して音量調整するゲイン調整部２７〜２９と、これらの３つの音を合成する合成部３０と、合成した音を圧縮符号化するエンコーダ３１と、圧縮符号化されたデータをデータパケットとしてのＲＴＰパケットに格納するデータパケット生成手段としてのパケット化部（packetize）３２ａと、後述する制御情報を生成する制御部３４と、該制御情報及びＲＴＰパケットをコントロールする管理情報等をＲＴＣＰパケットに格納する制御パケット生成手段としてのＲＴＣＰパケット化部３２ｂと、ＲＴＰパケット及びＲＴＣＰパケット等を送信する送信部３３とを有する。送信部３３から送られたＲＴＰパケットがインターネット１３０を介して通信対象となる他のＶｏＩＰクライアントに送信される。
【００３３】
一方、インターネット１３０を介して通信相手の送信手段２１から送られるデータを受信する受信手段４１は、ＲＴＰパケット及びＲＴＣＰパケット等を受信する受信部４２と、受信したＲＴＰパケットをデパケッタイズするＲＴＰデパケット化部（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：ＩＰ）制御部４がある。ネットワーク層は、データ送受信に使用する通信経路を選択し、フロー制御・品質制御などの通信制御を行うところである。信頼性を追求しないコネクションレス（Connectionless)パケット伝送プロトコルであるＩＰは、信頼性保証機能、フロー制御機能、エラー回復機能を上位階層（トランスポート層とアプリケーション層）に任せている。
【００５３】
トランスポート層としての機能には、トランスポート・コントロール・プロトコル（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）は、スレッド３において、揺らぎ吸収バッファＢＦ２からデータを読み出した後であって、再生する前に行ってもよく、また無圧縮のデータを格納するＰＣＭバッファを用意せず、揺らぎ吸収バッファからデータを読み出し復号したデータを揺らぎ吸収バッファＢＦ２に格納することなく再生するようにしてもよい。
【００８０】
更にＲＴＰパケットの受信処理とは別に、ＶｏＩＰ通話制御部７がコーデック１３における圧縮符号化方式を制御するため、受信したＲＴＣＰパケットに含まれる制御情報を取り出す等のＲＴＣＰパケットの受信処理が行われる。
【００８１】
次に、ＲＴＰパケットに格納する実時間音響データのコーデックの変更制御方法について更に詳細に説明する。本実施の形態におけるＶｏＩＰシステムにおいては、ネットワークの輻湊状態に応じ、送信する音声データにＢＧＭ及び効果音等が合成された送信データの圧縮率、即ちデータの伝送レートを再呼制御することなく異ならせることにより、高音質で情報量が大きい送信データであっても、通信を継続可能にするものである。
【００８２】
具体的には、例えばネットワークが何らかの要因で混雑した場合においは、再呼制御を行なわずにそのコーデック（圧縮符号化方式）を変更してビットレートを下げること等が挙げられる。
【００８３】
このため、ＲＴＰ／ＲＴＣＰ制御部１２は、受信するＲＴＰパケットからネットワーク伝送レートを常時又は定期的に計測する。この伝送レートの計測結果に応じて、ＶｏＩＰ通話制御部７は、ＲＴＣＰパケットにて、欠落パケットの再送要求を行なわせると同時に、通信相手が圧縮すべき周波数成分を通知させる。
【００８４】
具体的には、例えば、ＲＴＰパケットの伝送遅延（時間的な遅れ）が大きくなる等して伝送レートが小さくなり、ＶｏＩＰ通話制御部７がネットワークが混雑していると判断した場合、ＲＴＰ／ＲＣＴＰ制御部１２が、送信音の圧縮すべき周波数として、例えば高周波成分を削除又はビット割当てを減らして圧縮する等するように通知するためのＲＴＣＰパケットを生成するよう制御する。
【００８５】
これにより、例えばビットレートを下げるような指示（制御情報）を有するＲＴＣＰパケットを受けとった他のＶｏＩＰクライアントでは、当該他のＶｏＩＰクライアントのＲＴＰ／ＲＣＴＰ制御部からＶｏＩＰ通話制御部を介してこの制御情報がコーデックに入力され、コーデックが圧縮符号化方式を変更する。こうして圧縮符号化方式がコーデックにより変更され送信レートが小さくされた送信データがＲＴＰ／ＲＣＴＰ制御部１２からＲＴＰパケットとされ、他のＶｏＩＰクライアントから送信される。こうして、ＶｏＩＰクライアントは、通話相手となる他のＶｏＩＰクライアントから送信されるＲＴＰパケットの伝送レートを制御する制御情報をＲＴＣＰパケットにより送信し、他のＶｏＩＰクライアントから送信されるＲＴＰパケットの伝送レートを制御することができる。
【００８６】
このように、受信側となるＶｏＩＰクライアントの要求により、送信側となる他のＶｏＩＰクライアントが圧縮符号化方式を変更することにより、高音質な音声とＢＧＭ及び効果音が合成された合成音源データ、即ち高いビットレートで送信する必要があるデータ通信中に、何らかの要因でネットワーク帯域が急激に混雑し始めた場合、たとえ音質が一時的に低下したとしても会話（通信）を遮断することなく、継続させることができる。即ち、ＳＩＰ等の呼制御のためのメッセージを使用することなく、ＲＴＣＰパケットを使用して圧縮符号化方式の変更を行うことができるので通話が遮断されることがない。
【００８７】
また、本実施の形態におけるＲＴＣＰパケットは、後述するように拡張可能なＲＴＣＰ  ＡＰＰパケットであり、ＲＴＣＰパケットを使用して、欠落パケットの再送要求を行うことができ、この欠落パケットの再送要求を行うと同時に、他のＶｏＩＰクライアントが圧縮すべき周波数成分を通知することができるため、処理が迅速になる。
【００８８】
次に、本実施の形態におけるＶｏＩＰシステムにおいて更に詳細に説明する。ＶｏＩＰクライアント間における上述したＲＴＣ／ＲＴＣＰパケットの送受信は、先ず、一方のＶｏＩＰクライアントが他方のＶｏＩＰクライアントに呼シグナリングを行い、両者が通話相手のＩＰアドレス、ポート番号、音声及び音響圧縮方式等を認識する必要がある。ここでは、図３に示すようなＶｏＩＰクライアントアプリケーション１を備えたＰＣ（Personal Computer）がＵＡ（User Agent）となり、このＵＡ同士でＶｏＩＰする際の呼制御方法について説明する。
【００８９】
図７は、図３に示すＶｏＩＰソフトウェア１を使用して通話を行う際に、やり取りされるメッセージ・データの流れを示す図である。
【００９０】
図７に示すＵＡ１、ＵＡ２は、ＳＩＰによってＶｏＩＰの呼制御を行うＳＩＰＵＡである。このようなＶｏＩＰ通信において、ＳＩＰを用いた開始側（発呼側）として動作している場合はＵＡＣ（UA Client）となり、通信の受け手側（着呼側）として動作している場合はＵＡＳ（UA Server）となり、両ＶｏＩＰクライアント１１１、１２１間でデータ（メッセージ）がやり取りされる。ＳＩＰのメッセージには、ＵＡＣからＵＡＳへ送られるメッセージであるリクエストと、ＵＡＳからＵＡＣへ返されるメッセージであるレスポンスとがあり、リクエストのメッセージ・ボディには、ＳＤＰ（Session Description Protocol）に基づいたセッション情報が収納される。また、ＯＫレスポンス等の所定のレスポンスには、通話に使用するコーデックを選択するためのＳＤＰメッセージを含む。
【００９１】
先ず、発呼側のＵＡ１から着呼側のＵＡ２へセッション参加要求としてＩＮＶＩＴＥ  ＳＤＰ１（Ｄ１）が送られる。着呼側のＵＡ１にこれが届くと、着呼側のＵＡ２からリクエストが受信され処理中であることを示す100Tryningレスポンス及び180 Ringingレスポンス（Ｄ２）が送られ、次いで、発呼側のＵＡ１からリクエストが受理されたことを示す200 OKＳＤＰレスポンス（Ｄ３）が送られる。この180 Ringingレスポンスは、着呼側のＵＡ２にて呼び出し音を鳴らしている状態を示し、着呼側のＵＡ２にて受話器を取り上げたときに、200 OKＳＤＰレスポンスが送られる。そして、発呼側のＵＡ１からＡＣＫ（Ｄ４）が送られることにより、通信のためのポートが開かれる。こうしてＲＴＰ／ＲＴＣＰのセッションを確立し、音声及び音響データを送受信し合う（Ｄ５）。
【００９２】
また、逆に着呼側であったＵＡ２が発呼側となり、ＵＡ１へセッション参加要求ＩＮＶＩＴＥ  ＳＤＰ２（Ｄ６）が送られた場合、着呼側となったＵＡ１から発呼側ＵＡ２（クライアント側）のエラーを伝える405 Not Acceptableレスポンス（Ｄ７）が送信された場合、これを受信した発呼側ＵＡ２は、ＡＣＫ（Ｄ８）を送信し、再び着呼側のＵＡ１へセッション参加要求ＩＮＶＩＴＥ  ＳＤＰ２（Ｄ９）を再送する。
【００９３】
着呼側ＵＡ１がこれを正常に受信できれば、これを知らせる200 OKレスポンス（Ｄ１０）が送られ、発呼側からＡＣＫ（Ｄ１１）が送られることにより、新しいＲＴＰ／ＲＴＣＰのセッションを確立し、音声及び音響データを送受信し合う（Ｄ１２）。
【００９４】
このように、先ず始めに呼制御を行ってからＲＴＰ／ＲＴＣＰのセッションを確立し、音声及び音響データを送受信し合う。
【００９５】
図８は、図７に示す呼制御の際に使用されるＳＤＰの記述例を示す図である。図８に示すように、ＳＤＰで示されるタグ（注釈記号）のうち、「ｖ」はバージョン番号を示し、「ｏ」はセッション生成者とセッション識別用の情報を示し、ｏ＝＜ユーザ名＞＜ＳＤＰメッセージ識別番号＞＜メッセージ識別サブ番号＞＜ネットワーク・タイプ＞＜アドレス・タイプ＞＜アドレス＞と記述される。また「ｓ」はセッションのタイトルを示し、「ｃ」はコネクションデータを示し、ｓ＝＜開始時刻＞＜終了時刻＞と記述される。
【００９６】
また、「ｍ」はメディア名とトランスポートアドレスを示し、ｍ＝＜メディア種別＞＜ポート番号＞＜トランスポート・プロトコル＞＜ペイロード・タイプ＞と記述され、「ａ」はメディア属性を示し、ｍ＝rtpmap：＜ペイロード・タイプ＞＜符号化則＞／＜クロック＞と記述される。
【００９７】
このように、ＳＩＰは、ＩＰアドレス・ポート番号・音声及び音響圧縮方式を記述することができ、呼制御の際にはこのＳＤＰを、お互いに送受信し合う。ＶｏＩＰシステムにおいては、このＳＩＰによりＲＴＰ／ＲＴＣＰのセッションを確立し、ＲＴＰ／ＲＴＣＰパケットの送受信を行うが、上述した如く、音声及び音響圧縮方式をこのＳＩＰの呼制御において確立してしまうと、ネットワーク帯域の混雑の度合いによって伝送ビットレートを可変とするために、再び再呼制御が必要となる。
【００９８】
そこで、本実施の形態においては、ＲＴＣＰパケットを拡張したＡＰＰパケットを使用して、受信側にてデータの到着状態、即ち送信側の伝送レートを常時又は定期的に計測し、この伝送レートに基づき、伝送レートを挙げるか、又は下げるかの判断を行い、これをＡＰＰパケットにより送信側に通知して送信するデータの伝送レートを制御するものである。
【００９９】
次に、ＲＴＰ／ＲＴＣＰのセッションを確立した後送受信されるＲＴＰ／ＲＴＣＰパケットについて説明する。図９（ａ）及び（ｂ）は、ＲＴＰパケットの夫々構成及びヘッダのフォーマットを示す図であり、図１０（ａ）乃至（ｃ）は、アプリケーションによって拡張可能なＲＴＣＰ  ＡＰＰパケットの構成、そのヘッダ（RTCP APP Application-defined Header）、及び送信レポートのフォーマット例を示す図である。
【０１００】
ＲＴＰは、インターネット等のＩＰネットワークにおいて、リアルタイムに音声や動画を送信／受信するトランスポート・プロトコルであり、ＲＦＣ１８８９で勧告されている。ＲＴＰは、トランスポート層に位置し、一般にＵＤＰ上でＲＴＣＰと共に用いられる。
【０１０１】
そして、図９（ａ）に示すように、ＲＴＰパケットは、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダ及びＲＴＰデータからなる。そして、ＲＴＰヘッダには、図９（ｂ）に示すように、先頭から、バージョン情報格納部（Ｖ：version、例えばＶ＝２）Ｆ１、パディング格納部（Ｐ：padding）Ｆ２、拡張ビット格納部（Ｘ：extension）Ｆ３、ＣＳＲＣ（contributing source）カウント格納部（ＣＣ）Ｆ４、マーカ情報（Ｍ：marker）格納部Ｆ４、マーカ・ビット格納部（Ｍ：maker）Ｆ５、ペイロード種別情報格納部（ＰＴ：payload type）Ｆ６、シーケンス番号情報格納部（sequence number）Ｆ７、タイムスタンプ格納部（time stamp）Ｆ８、ＳＳＲＣ識別子格納部（synchronization source identifier）Ｆ９、ＣＳＲＣ識別子格納部Ｆ１０が設けられ、ＣＳＲＣ識別子格納部Ｆ１０の後ろに実時間音響データが付加される。
【０１０２】
バージョン情報格納部Ｆ１には、ＲＴＰのバージョンを示す情報が格納され、例えばＲＴＰ２を示すときには、その旨のバージョン情報が格納される。
【０１０３】
カウント格納部Ｆ４は、ヘッダ中に示されるＣＳＲＣ（寄与送信元識別子）の数を示す。
【０１０４】
ペイロード種別情報格納部Ｆ６には、実時間音響データの種類を示す情報が格納され、例えば映像や音声を示す旨の情報等が格納される。
【０１０５】
シーケンス番号情報格納部Ｆ７には、ＲＴＰセッションにおいて、ＲＴＰパケットを送受信する度にカウントアップされ、送受信するＲＴＰパケットの順番を認識するためのシーケンス番号が格納される。
【０１０６】
タイムスタンプ格納部Ｆ８には、実時間音響データを作成、更新した日時に関するタイムスタンプ情報が格納される。
【０１０７】
ＳＳＲＣ識別子格納部Ｆ９及びＣＳＲＣ識別子格納部Ｆ１０には、ＲＴＰセッションにおいて、データ送信側のソースを識別するための情報が格納される。ＳＳＲＣ識別子は、同期送信元識別子であり、同一ユーザが組み合わせて扱うべき複数のストリームが同じ値を共有するように割り当てた識別子であり、ＣＳＲＣ識別子は、寄与送信元識別子であり、ストリーム源を示す。複数のストリームがミキシング処理され１つのストリームデータとして提供される場合等に使用される。
【０１０８】
図３に示すＲＴＰ／ＲＴＣＰ制御部８は、ＲＴＰに従って実時間音響データを送信するに際して、上記各格納部に各種情報を格納すると共に、各格納部に格納された各種情報を認識して実時間音響データを抽出する処理をする。
【０１０９】
上述のＲＴＰが音声・動画像データそのものを送信／受信するプロトコルであるのに対し、ＲＴＣＰは、周期的に、パケットロス、遅延ジッタ、ラウンドトリップ等の回線品質を評価し、その帯域に見合ったリアルタイム通信を実現するため情報を送信／受信するプロトコルである。
【０１１０】
このＲＴＣＰを用いることにより、相手からフィードバックされてくる情報により、ネットワークの状態などを推測して送信レートを変更するなどの動的な処理を行うことができる。また、今誰がデータを送信していて、誰が受信しているかを示す情報もＲＴＣＰパケットで同時に送っているので、今現在の参加者の情報を知ることもできる。
【０１１１】
図１０（ａ）に示すように、ＲＴＣＰパケットは、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＣＰヘッダ及びＲＴＣＰデータからなる。そして、拡張可能なＲＴＣＰパケットであるＲＴＣＰ  ＡＰＰパケットのヘッダには、図１０（ｂ）に示すように、先頭から、バージョン情報格納部（Ｖ：version、例えばＶ＝２）Ｆ１１、パディング格納部（Ｐ：padding）Ｆ１２、subtype格納部Ｆ１３、パケットタイプ（ＰＴ：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でもあるＵＡ１とＵＡ２との間でやり取りされるＳＲブロックを含むＲＴＣＰパケット及びＲＲブロックを含むＲＴＣＰパケットにおいては、図１１に示すように、拡張データとして、エンコード帯域幅（Encode Bandwidth）、サブバンド分割ブロック数（sub band Numbers）、デコード処理部前後の揺らぎ吸収バッファサイズ（時間に換算可能）（Forward and Backward Jitter Buffer size）、上記吸収バッファにキューイングされているデータサイズ（時間に換算可能）（Buffer queued size）、ＲＴＰパケットの再送リクエスト情報（Re-Request：sequence number）を記述することができる。ＲＴＰパケットの再送リクエストにはシーケンス番号を利用する。
【０１１９】
ＵＡ１は、ＵＡ１のユーザの音声にＢＧＭ・効果音等が合成された送信音源ストリームをＲＴＰパケットにて送信する。また、ＵＡ２も、ＵＡ２のユーザの音声にＢＧＭ・効果音等が合成された合成音をＲＴＰパケットにて送信する。
【０１２０】
そして、例えばＵＡ１は、ＲＴＣＰ  ＡＰＰパケットに、ストリーム受信装置としてのＵＡ１がストリーム送信装置としてのＵＡ２に対してそのストリーム受信状態を報告するレポートブロックに加え、ＵＡ２から送られるＲＴＰパケットの到着状態に応じて、制御情報としてのエンコード帯域幅及びサブバンド分割ブロック数を記述する。これを受けたＵＡ２は、そのエンコード帯域幅及びサブバンド分割ブロック数に基づき、ＵＡ１に送信する送信データのエンコード帯域及びサブバンド分割ブロック数を変更することで、伝送レートを変更する。
【０１２１】
また同様に、ＵＡ２からＵＡ１に対して、ＵＡ１から送られるＲＴＰパケットの到着状態に応じて伝送レートを制御するための制御情報としてエンコード帯域幅及びサブバンド分割ブロック数を通知することができ、同様に、これを受けたＵＡ１はエンコードすべき帯域及びサブバンド分割ブロック数を変更し、伝送レートを変更する。
【０１２２】
更に、ＵＡ１とＵＡ２との間にて、ＳＲ（Sender Report）ブロックを含むＲＴＣＰパケットを送信してからＳＲ（Receiver Report）ブロックを含むＲＴＣＰパケットを受信するまでの時間がＲＴＴ（Round Trip Time）として求められ、ＵＡ１は、このＲＴＴと、自身のデコード処理部前後の揺らぎ吸収バッファサイズとに応じてＵＡ２から再送してもらうことが可能な欠落パケットのシーケンス番号を通知する。即ち、ＲＴＴの計算結果に基づき、再送要求したパケットが送られてくるまでの時間情報が得られ、再送要求したパケットが到着する時刻よりそのパケットのデコードを開始予定時間又は再生予定時間が遅いときは再送要求を行うことができる。
【０１２３】
なお、このアプリケーション固有情報ＡＰＰとして、自身のデコード処理前後の揺らぎ吸収バッファサイズ、この揺らぎ吸収バッファを占有しているデータ量等の情報も記載することができ、これらの通知を受けた通話相手側のＶｏＩＰクライアントは、これらの値に基づき、送信するデータの伝送レートを変更する等してもよい。
【０１２４】
このように、ＵＡ１及びＵＡ２において、ＲＴＣＰ  ＡＰＰパケットに含まれるエンコード帯域幅及びサブバンド分割ブロック数により、通信相手から送られるＲＴＰパケットの圧縮すべき音の周波数成分を、通話相手に通知することができ、高音質な音声通話中に、何らかの要因でネットワーク帯域が急激に混雑しはじめた場合であっても、伝送レートを下げることにより、会話を遮断されることなく、継続させることができる。
【０１２５】
即ち、本実施の形態においては、例えばＵＡ１からの送信データが格納されたＲＴＰパケットを受信した受信側のＵＡ２は、その受信結果に基づきＵＡ１に伝送レートの変更を要求するＲＴＣＰ  ＡＰＰパケットを送信する。これを受け取ったＵＡ１が、受け取ったＡＰＰパケットに含まれる制御情報に基づき、ＵＡ２に対して欠落パケットを再送すると共に、圧縮する周波数成分の情報に基づき送信データの圧縮符号化方式を変更し、よって伝送するデータの伝送レートを可変とすることができる。このように、ＲＴＰパケットの受信側の要求により、ＲＴＰパケットを送信する送信側のＶｏＩＰクライアントがコーデックを適宜変更したデータを伝送することにより、コーデックの変更通知をするための再呼制御が不要になり、通信が途切れることがない。
【０１２６】
更に、本実施の形態においては、常時又は定期的に受信側において伝送レートを計測し、その伝送レートに応じて送信側のコーデックを自動的に制御するものとしたが、受信端末を使用しているユーザ操作に基づき同様に処理を行うことができる。
【０１２７】
即ち、図４に示すＧＵＩ８に示したように、例えば、伝送レートを上下するための音質制御部６９等の操作部を設けておき、音声のみの通話か又は音声にＢＧＭ等を付加した高音質のデータによる通話かに応じてユーザ自身が伝送レートを指示できるようにしたり、又はユーザが例えば音声及び音響が聞き取りにくいと感じた場合には、ユーザ自身がこの操作部を操作して伝送レートを変更することができる。また、伝送レートを下げる際に高周波成分をカットするか、音響データをカットするか等を選択できるような操作部を設け、ユーザ操作に基づきＶｏＩＰ通話制御部３がＲＴＣＰ  ＡＰＰパケットを使用して、送信者側の伝送レートを制御するようにしてもよい。また、逆に、ユーザの要望に応じて伝送レートを上げて音質を向上可能なようにしておいてもよい。
【０１２８】
次に、パケットを送信してからメッセージの往復に要する時間を示すＲＴＴの求め方について説明する。このＲＴＴは、上述したように、ＶｏＩＰ通話制御部３によち、欠落パケットの再送要求を行う際、ＲＴＰパケットを受信した際のジッタを吸収するために使用するＲＴＰパケット受信バッファのサイズと共に参照されるものである。
【０１２９】
図１２は、ＲＴＣＰを利用したＲＴＴの計算方法を示すシーケンス図である。図１２に示すように、ＲＴＰのSenderでもありReceiverでもあるＵＡ１とＵＡ２との間にて、先ず、ＵＡ１からＲＴＣＰ  ＳＲパケットが送られると、ＵＡ２からＲＴＣＰ  ＲＲパケットが送られる。ＲＴＣＰ  ＲＲパケットには、レポートブロックとしてＬＳＲ及びＤＬＳＲが記述されている。
【０１３０】
ＬＳＲは、最後に受信したＳＲパケットのＮＴＰ（Network Time Protocol）タイムスタンプであり、例えば図１２においては、ＵＡ１がＲＴＣＰ  ＳＲパケットを送信した時間（10 Nov 1995 11:33:25.125）である。ＲＲパケットを受信したＵＡ１は、ＲＴＣＰ  ＲＲパケットの到着時間Ａ（10 Nov 1995 11:33:36.5）と、ＲＲパケットのレポートブロックに記載されたＬＳＲとからＲＴＴ（＝ＬＳＲ−Ａ）を算出することができる。
【０１３１】
ＲＴＴには、最後にＳＲパケットを受信したとき、このレポートブロックを送信するまでの経過時間を１／６５５３６秒単位で表した値を示すＤＬＳＲ等が含まれる。これは、伝送レートやネットワークの混雑度合いによって変化するものである。
【０１３２】
こうしてＵＡ１は、算出したＲＴＴ及びパケット到着時刻等によりネットワーク負荷を推定し、欠落パケットの再送要求をしたり、ストリームの伝送レートを調整する。このＲＴＴは、ＲＴＣＰパケットを送受信する毎に算出してもよく、又は所定時間経過毎に算出したり、コーデックを変更した際に算出するようにしておよい。
【０１３３】
次に、聴覚心理特性を利用した高能率音響圧縮符号化及び復号伸張方法の一具体例について説明する。図１３及び図１４は、夫々高能率音響圧縮符号化部及び高能率音響復号伸張部を示すブロック図である。高能率音響圧縮符号化部７０は、図２に示すエンコーダ３１に対応するものであり、図１３に示すように、時間周波数分解部７１と、量子化部７２と、聴覚心理モデル部７３と、帯域割当て部７４と、マルチプレクス７５とを有する。
【０１３４】
時間周波数分解部７１は、時間軸の信号を所定時間単位でブロック化あるいはフレーム化してこのフレーム毎の時間軸の信号を周波数軸上の信号に変換（スペクトル変換）して複数の周波数帯域に分割する。
【０１３５】
聴覚心理モデル部７３は、一般に高域ほど帯域幅が広くなるような臨界帯域（クリティカルバンド）と呼ばれている帯域幅で、オーディオ信号を複数（例えば２５バント）の帯域に分割する等の処理を行い、帯域割当て部７４は、各帯域毎に所定のビット配分或いは、各帯域毎に適応的なビット割当て（ビットアロケーション）を行う。例えば、モディファイド離散コサイン変換（modified discrete cosine transform：ＭＤＣＴ）処理されて得られた係数データをビットアロケーションによって符号化する際には、各フレーム毎のＭＤＣＴ処理により得られる各帯域毎のＭＤＣＴ係数データに対して、適応的なビット数が割当てられる。
【０１３６】
ここで、上述したＲＴＣＰパケットに格納される制御情報に含まれるエンコード帯域及びサブバンド分割ブロック数は、例えば聴覚心理モデル部７３に供給され、エンコードすべきデータを指定されたエンコード帯域のデータのみとし、このエンコード帯域をサブバンド分割ブロック数に分割する等の処理を行う。
【０１３７】
量子化部７２は、帯域毎に割り当てられたビット数に基づき、量子化ステップ又は量子化サイズを決定して量子化する。
【０１３８】
マルチプレクス７５は、量子化されたデータを、帯域割当て部により割り当てられたビット数等の副情報と共に多重化して出力する。
【０１３９】
また、図１４に示すように、高能率音響復号伸張部８０は、デマルチプレクス８１と、逆量子化８２と、時間周波数再構成部８３とを有する。デマルチプレクス８１は、高能率符号化されたデータが入力され、これをデマルチプレクスする。逆量子化部８２は、出マルチプレクス８１より取り出された帯域情報等の副情報に基づき量子化データを逆量子化し、時間周波数再構成部８３は、時間軸上のデータを周波数軸上のデータに変換して出力する。
【０１４０】
このような高能率音響圧縮符号化によれば、音響情報チャンネルの全てのチャンネルを合わせた総ビットレ−トを可変とし、かつ一定の最大値を越えないようなビット配分を行なわせることができる。
【０１４１】
即ち、ＡＰＰパケットにて指定されたエンコード帯域により、圧縮すべき周波数成分を選択し、ＡＰＰパケットにて指定されたサブバンド分割ブロック数にエンコード帯域を分割するので、通信相手からのＡＰＰパケットに含まれるエンコード帯域及びサブバンド分割ブロック数に基づき、出力するデータのビット数を削減したり、又は増大させたりしてエンコードする実時間音響データの圧縮率を変更することで、伝送するビットレートを可変とすることができる。
【０１４２】
また、ここでは、ＡＰＰパケットにて圧縮すべき周波数成分を指定するものとしたが、例えば伝送ビットレートを指定するようにし、送信側の高能率圧縮符号化部７０が、その指定された伝送ビットレートになるよう圧縮符号化するようにしてもよい。更に、制御情報として各帯域に割り当てるビット数や、量子化部が量子化する量子化ステップ又はサイズ等の情報を指定してもよい。
【図面の簡単な説明】
【０１４３】
【図１】本発明の実施の形態におけるＶｏＩＰシステムの一例を示す模式図である。
【図２】本発明の実施の形態におけるＶｏＩＰシステムのうち、ＶｏＩＰクライアント１１１とインターネット１３０とからなる要部を示すブロック図である。
【図３】本発明の実施の形態におけるＶｏＩＰシステムが有するＶｏＩＰクライアントとして、一般的なＰＣを使用した場合におけるＶｏＩＰクライアントアプリケーションを示す図である。
【図４】上記ＶｏＩＰクライアントアプリケーションにおけるＧＵＩの一例を示す模式図である。
【図５】本発明の実施の形態におけるＶｏＩＰシステムにおけるＶｏＩＰクライアント（ＶｏＩＰクライアント）のハードウェア構成を示すブロック図である。
【図６】図３に示すＶｏＩＰクライアントアプリケーションのうち、ＲＴＰ／ＲＴＣＰパケットを送受信する処理を示す機能ブロック図である。
【図７】上記ＶｏＩＰクライアントアプリケーションを使用してＶｏＩＰを行う際の呼制御においてやり取りされるメッセージ・データの流れを示す図である。
【図８】呼制御の際に使用されるＳＤＰの記述例を示す図である。
【図９】（ａ）及び（ｂ）は、夫々ＲＴＰパケットの構成及びヘッダのフォーマットを示す図である。
【図１０】（ａ）乃至（ｃ）は、アプリケーションによって拡張可能なＲＴＣＰ  ＡＰＰパケットの構成、そのヘッダ（RTCP APP Application-defined Header）、及び送信レポートのフォーマット例を示す図である。
【図１１】本実施の形態におけるＶｏＩＰシステムにおいて、ＲＴＣＰ  ＡＰＰメッセージの交換時にやりとりされるメッセージを示す図である。
【図１２】ＲＴＣＰを利用したRound Trip Timeの計算方法を示すシーケンス図である。
【図１３】聴覚心理特性を利用した高能率音響圧縮符号化部を示すブロック図である。
【図１４】聴覚心理特性を利用した高能率音響復号伸張部を示すブロック図である。
【符号の説明】
【０１４４】
１  ＶｏＩＰクライアントアプリケーション、２１  送信手段、２２  マイクキャプチャ、２３  効果音ファイル読み込み部、２４  ＢＧＭファイル読み込み部、２５，２６，３１  デコーダ、２７，２８，２９  ゲイン調整部、３０  合成部、３１  エンコーダ、３２  パケット化部、３３  送信部、４１  受信手段、４２  受信部、４３  デパケッタイズ部、４４  デジッタ部、４５  パケット補償部、４６  デコーダ、４７  読み出し部、４８  復号部、４９，５０，５１，５２  ゲイン調整部、５３  合成部、５４  出力部、５５  スピーカ、１００  ＶｏＩＰ通信システム、１１１、１２１  ＶｏＩＰクライアント、１１０，１２０  ユーザ、１１２，１２２  ウェブブラウザ、１３４  ウェブサーバ、１１３、１２３  音源データ、１３０  インターネット
【図１】
2005045739.tif 000003
【図２】
2005045739.tif 000004
【図３】
2005045739.tif 000005
【図４】
2005045739.tif 000006
【図５】
2005045739.tif 000007
【図６】
2005045739.tif 000008
【図７】
2005045739.tif 000009
【図８】
2005045739.tif 000010
【図９】
2005045739.tif 000011
【図１０】
2005045739.tif 000012
【図１１】
2005045739.tif 000013
【図１２】
2005045739.tif 000014
【図１３】
2005045739.tif 000015
【図１４】
2005045739.tif 000016