(57)【要約】【課題】  多者間通話サービスにおける揺らぎや遅延の影響を最小限にした複数音声ストリームのリアルタイム同期方法及び同期システムを提供する。【解決手段】同時刻に発生された複数音声ストリームの最初の音声パケットの受信時刻とタイムスタンプをメモリに格納し、この格納された受信時刻、タイムスタンプと、２番目以降の同期処理されるべき音声パケットのタイムスタンプとから、演算により、現在時刻で同期処理されるべき音声パケットであるか否かを判別する。【選択図】        図９ 
2005159570.tif 000002
【特許請求の範囲】
【請求項１】
複数音声ストリームの音声パケットの時刻同期処理をリアルタイムで行う同期方法であって、
受信した音声ストリームの最初の音声パケットが有するタイムスタンプ及び前記最初の音声パケットの受信時刻をサーバ内の記憶装置に記憶するステップと、
前記記憶装置に格納された前記最初の音声パケットのタイムスタンプ及び前記最初の音声パケットの受信時刻と、コンピュータに内蔵された内部時計から得られる現在時刻と、前記最初の音声パケットに続く２番目以降の音声パケットのタイムスタンプとから、前記２番目以降の音声パケットが前記現在時刻において処理可能か否かをリアルタイムで判定するステップと
からなる複数音声ストリームのリアルタイム同期方法。
【請求項２】
前記音声パケットが現在時刻において処理可能かどうかを判定するステップは、最初に受信した音声パケットのタイムスタンプをＴＳ０、前記最初の音声パケットに続く音声パケットであって、現在処理しようとする音声パケットのタイムスタンプをＴＳｎ、最初に受信した音声パケットの受信時刻をＴ０、連続するＲＴＰパケットのタイムスタンプ増加量をＴＳＩ、１つのＲＴＰパケットにおける録音時間をＳＴ、任意設定の待機時間閾値をＪＴとしたとき、現在時刻Timeが次式（１）及び（２）
Time≧T0+{(TSn-TS0)/TSI}×ST        （１）
Time−［T0+{(TSn-TS0)/TSI}×ST］≦JT    （２）
を満足するとき、タイムスタンプＴＳｎが付された音声パケットを現在時刻において処理可能であると判定することを特徴とする請求項１に記載の複数音声ストリームのリアルタイム同期方法。
【請求項３】
前記任意設定の待機時間閾値ＪＴは、揺らぎを吸収するための揺らぎ吸収バッファサイズに設定することを特徴とする請求項２に記載の複数音声ストリームのリアルタイム同期方法。
【請求項４】
受信した複数音声ストリームの音声パケット時刻同期処理をリアルタイムで行う同期システムであって、
前記受信した音声ストリームの最初の音声パケットのタイムスタンプを取得するタイムスタンプ取得手段と、
前記受信した音声ストリームの最初の音声パケットの受信時刻を取得する受信時刻取得手段と、
前記最初の音声パケットのタイムスタンプ及び受信時刻を記憶装置に格納する記憶手段と、
前記受信した複数音声ストリームの２番目以降に受信した音声パケットのタイムスタンプと前記最初に受信した音声パケットのタイムスタンプを減算する減算手段と、
前記減算したタイムスタンプの差分を１個のタイムスタンプが有する情報量で除算し、該除算結果に一個の音声パケットの記憶時間を乗算して、最初の音声パケットの到来から現在処理している音声パケットの到来までの時間を計測する時間計測手段と、
前記時間計測手段の出力に最初の音声パケットの受信時刻を加算して、受信した音声パケットの処理すべき時刻を算出する時刻算出手段と、
前記時刻算出手段で算出した時刻と、前記受信時刻取得手段で取得した時刻とを比較する比較手段と、
前記比較手段の出力に基づいて、現在時刻の時点で前記音声パケットを処理するか否かを判断する判定手段とからなる
複数音声ストリームのリアルタイム同期システム。
【請求項５】
前記音声パケットを処理するか否かを判断する判定手段は、最初に受信した音声パケットのＲＴＰのタイムスタンプをＴＳ０、現在処理しようとする音声パケットのタイムスタンプＴＳｎ、最初に受信した音声パケットの受信時刻をＴ０、連続するＲＴＰパケットのタイムスタンプ増加量をＴＳＩ、１つのＲＴＰパケットにおける録音時間をＳＴ、任意に設定される待機時間閾値をＪＴとしたとき、現在時刻Timeが次式（１）（２）
Time≧T0+{(TSn-TS0)/TSI}×ST        （１）
Time−［T0+{(TSn-TS0)/TSI}×ST］≦JT    （２）
を満足するとき、処理可能であると判定することを特徴とする請求項４に記載の複数音声ストリームのリアルタイム同期システム。
【請求項６】
前記任意に設定される待機時間閾値ＪＴは、揺らぎ吸収バッファサイズに等しく設定することを特徴とする請求項５に記載の複数音声ストリームのリアルタイム同期システム。
【請求項７】
受信した複数音声ストリームの音声パケットからタイムスタンプを取得するタイムスタンプ取得手段と、
前記受信した複数音声ストリームの音声パケットの揺らぎを吸収する揺らぎ吸収バッファと、
前記揺らぎ吸収バッファから得られる複数音声ストリームを構成する各音声ストリームの音声パケットを、時刻同期させて処理する手段と、
前記時刻同期処理された複数音声パケットの各音声パケットをミキシング処理する手段と、
前記ミキシング処理した複数音声ストリームを構成する音声パケットを送信する手段とからなることを特徴とする複数音声ストリームによる多者間通話システム。
【請求項８】
前記時刻同期させて処理する手段は、前記受信した音声ストリームの最初の音声パケットのタイムスタンプを取得するタイムスタンプ取得手段と、
前記受信した音声ストリームの最初の音声パケットの受信時刻を取得する受信時刻取得手段と、
前記最初の音声パケットのタイムスタンプ及び受信時刻を記憶装置に格納する記憶手段と、
前記受信した複数音声ストリームの２番目以降に受信した音声パケットのタイムスタンプと前記最初に受信した音声パケットのタイムスタンプを減算する減算手段と、
前記減算したタイムスタンプの差分を１個のタイムスタンプが有する情報量で除算し、該除算結果に一個の音声パケットの記憶時間を乗算して、最初の音声パケットの到来から現在処理している音声パケットの到来までの時間を計測する時間計測手段と、
前記時間計測手段の出力に最初の音声パケットの受信時刻を加算して、受信した音声パケットの処理すべき時刻を算出する時刻算出手段と、
前記時刻算出手段で算出した時刻と、前記受信時刻取得手段で取得した時刻とを比較する比較手段と、
前記比較手段の出力に基づいて、現在時刻の時点で前記音声パケットを処理するか否かを判断する判定手段とからなる
ことを特徴とする請求項７に記載の複数音声ストリームによる多者間通話システム。
【請求項９】
前記音声パケットを処理するか否かを判断する判定手段は、最初に受信した音声パケットのＲＴＰのタイムスタンプをＴＳ０、現在処理しようとする音声パケットのタイムスタンプＴＳｎ、最初に受信した音声パケットの受信時刻をＴ０、連続するＲＴＰパケットのタイムスタンプ増加量をＴＳＩ、１つのＲＴＰパケットにおける録音時間をＳＴ、任意に設定される待機時間閾値をＪＴとしたとき、現在時刻Timeが次式（１）（２）
Time≧T0+{(TSn-TS0)/TSI}×ST        （１）
Time−［T0+{(TSn-TS0)/TSI}×ST］≦JT    （２）
を満足するとき、処理可能であると判定することを特徴とする請求項８に記載の複数音声ストリームによる多者間通話システム。
【請求項１０】
前記任意に設定される待機時間閾値ＪＴは、揺らぎ吸収バッファサイズに等しく設定することを特徴とする請求項９に記載の複数音声ストリームによる多者間通話システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット交換網を用いて多人数で音声通話を行う場合の多者間通話システムに関し、特に、話者に対応する複数パケットストリームの揺らぎと遅延問題を解決した複数ストリームのリアルタイム同期方法及び同期システム並びにそれを用いた多者間通話システムに関する。  
【背景技術】
【０００２】
大容量回線の低価格化や通信業界の規制緩和などにより、安価に電話を行うことのできるIP 電話サービスの利用者は増加傾向にある。従来の電話は回線交換網を利用しているため、1対1通話が基本の音声通信であり、大手通信会社の提供するサービスとしての位置付けであった。
【０００３】
IP 電話方式は、IP（Internet Protocol）を利用したパケット交換網を利用して電話通信を行うサービスである。このIP 電話方式では、音声データはWeb等のデータと同列に扱うことが可能である。このことは、従来の電話では実現が難しかった応用サービスの提供を容易にする可能性を有している。さらに、インターネットを利用するIP 電話方式では、一般利用者が容易に応用サービスを提供することも可能になる。
【０００４】
しかし、利用する回線の特性が異なるため、従来の電話では起こらない次のような問題が発生する。すなわち、IP 電話方式で利用されるパケット交換網は回線交換網と違い、通信経路を占有することが無いため、データの伝送経路上のトラフィック状況によって遅延が生じ、特にデータの到着時間に一貫性が無い「揺らぎ」が生じる。電話はリアルタイム性が重要になるため、揺らぎを吸収する制御はきわめて重要である。この揺らぎを吸収するためには、「揺らぎ吸収バッファ」が必要であり、この揺らぎや遅延を吸収する制御用のプロトコルとしては、一般にRTP(Real-time Transport Protocol)が使用される。
【０００５】
また、IP 電話方式では、送話者から受話者へデータが到着するまでに、送話者側では音声サンプリング、エンコード、パケット化に伴った遅延時間が生じ、送話者から受話者までの伝送経路中では、伝送距離に応じた伝播遅延、経路にあるルータにおけるパケットのキューイング遅延等が生じ、受話者側ではパケットの処理、揺らぎの吸収、受信データのチェック、音声のデコード時間が生じる。
【０００６】
したがって、IP 電話方式においては、上記「揺らぎ」や伝送中の様々な遅延に対処するため、複数人の話す音声を同時刻化することと、複数の音声ストリームを効果的にミキシングすることが重要である。この複数人の話す音声の同時刻化に際して、パケット交換網において、「揺らぎ」を生じる複数の時間的に独立した音声ストリームのパケットをある程度貯めておき、同期処理すればパケット交換網でのパケット伝送で生じた遅延・揺らぎを緩和しつつ複数の音声ストリームを同期することは可能である。
【０００７】
従来の多者間通話システムにおける時刻同期としては、図１５に示すようなものが知られている（非特許文献１）。図１５に示す同期方法は、多者間通話システムに参加する３人の参加者Ａ、Ｂ、Ｃの音声データを符号化器２００ａ〜２００ｃで符号化し、タイムスタンプが押されたリニアストリームとしてバッファメモリ２０１ａ〜２０１ｃに蓄積する。このバッファメモリ２０１ａ〜２０１ｃに蓄積された音声データはＡ、Ｂ、Ｃの順番にバッファメモリ２０２に順次蓄積され、ミキシングされる。そして、このミキシングされた音声データＸ＝Ａ＋Ｂ＋Ｃから自分（送信者自身）が発した音声データが減算されて復号化器２０３a〜２０３ｃに供給される。すなわち、ユーザAが保有する複合化器２０３ａには、ミキシングされたデータＸからユーザAが発した音声データＡが減算されたデータＢ＋Ｃが送られ、複合化されてユーザＡに送信される。送り先がＢあるいはＣの場合も同様な操作で他の二者の音声データが送信される。ここで、各送信者からの音声データは、通常20ms単位で送られてくるので、このデータを二つまとめて40msの音声データとして送信される。
【０００８】
図１６は、上述の送信中に揺らぎが発生した場合の、従来のミキシングの問題点を説明するための図である。第１の音声ストリーム（Ａ）の音声パケット１ａ〜４ａと第２の音声ストリーム（Ｂ）の音声パケット１ｂ〜４ｂは、図示のようにそれぞれ送信タイミングを同じくしている。しかし、伝送経路等における揺らぎが発生すると、受信タイミングは図示のごとく３ａ、３ｂ以降にずれが生じ、送信タイミングとことなったタイミングでミキシングされてしまう。したがって、第１の音声ストリーム（Ａ）の音声パケット３ａと４ａの部分が、第２の音声ストリーム（Ｂ）の音声パケット３ｂと４ｂよりワンテンポ送れて聞こえるため、会話が聞きづらくなるという問題が生じる。さらに、このような揺らぎによる遅れは蓄積されるので、多者間通話において、相手の声が適切なタイミングで聞こえてこないという問題が生じるのである。
【０００９】
図１７に示すように、複数の音声ストリームは、時間的に独立しており、データの送信時間が同じ場合でも宛先での受信時間は異なったものになる。このため、音声データをミキシングする必要性のあるシステムでは、揺らぎによる到着時間や到着順のずれを緩和する必要がある。すなわち、ミキシングシステムにおいてこの揺らぎによる影響を考慮しない場合は「音声がブチブチ切れる。」あるいは「間延びが起こる」といった現象が生じてしまう。双方とも、正常な音声コミュニケーションの妨げになることは言うまでもないが、特に、間延びの影響としては、通常5秒で再生する部分に、仮に７秒かかったとして2秒の遅れが生じ、かつこの遅れが累積してくるので、会話をしていて極めて聞きづらいという問題が生じることになる。
【非特許文献１】Internet Telephony Workshop 2001「Centralized Conferencing using SIP」（２００１．４．２発行）
【発明の開示】
【発明が解決しようとする課題】
【００１０】
この揺らぎと遅延の問題を解決するため、例えば、いったん「揺らぎ吸収バッファ」にかなり膨大な数のデータを貯めてから、読み出す方法が考えられる。例えば、「揺らぎ吸収バッファ」に２秒間（１パケットを20msとして100データ）のデータを貯めると、２秒までの揺らぎの影響が無視できることになる。
【００１１】
しかし、この方法では、高品質な音声品質を保つ場合の1つの基準である「総合150ms以内の遅延時間に抑える」という基準が満たされないことになる。したがって、揺らぎ吸収バッファに貯めるというアプローチでは、高品質な音声品質を保つことはできない。すなわち、IP 電話方式における時刻同期処理は、音声品質を保ちつつ処理速度を向上させる必要があり、したがって、音声ストリームの微細時間に同期処理を完了する必要がある。そのため、ミキシングを行う際に問題にならない程度のパケット数をバッファに蓄積し、処理を行う必要がある。
【００１２】
また、上述した複数ストリームの時間同期では、パケット交換網上で発生する遅延、揺らぎの影響が同期結果に反映されるため、処理すべきデータを処理すべきタイミングに処理できるとは限らない。つまり、リアルタイムに近い状態で同期処理をして多者間で会話を行うことは難しいという問題が生じる。
【００１３】
また、データが遅延した場合は、本来処理すべきタイミングの次のタイミングで処理されることになるため、ストリーム間に再生時期の“ずれ”が発生するばかりでなく、以降の同期処理において“ずれ”は累積する。
【００１４】
本発明は、上記のような問題点を踏まえ、バッファに貯めるデータ量を可能な限り少なくし、かつ揺らぎによる悪影響を緩和するとともに、リアルタイム性を確保しつつ複数ストリームの時刻同期を実現することを目的とする。  
【課題を解決するための手段】
【００１５】
上記課題を解決し、本発明の目的を達成するため、本発明の請求項１に記載された発明は、複数音声ストリームの時刻同期をリアルタイムで行う同期方法であって、受信した音声ストリームの最初の音声パケットが有するタイムスタンプ及び最初の音声パケットの受信時刻をサーバ内の記憶装置に記憶するステップと、この記憶装置に格納された最初の音声パケットのタイムスタンプ及び最初の音声パケットの受信時刻と、コンピュータに内蔵された内部時計から得られる現在時刻と、最初の音声パケットに続く２番目以降の音声パケットのタイムスタンプとから、この２番目以降の音声パケットが現在時刻において処理可能か否かをリアルタイムで判定するステップとからなることを特徴とする。
ここで、音声とは、人間が発声器官を通じて発する言語音のみならず、テレビやラジオの音及び音楽、並びにそれらと類似の機械から発する音や音楽も含むものとする。また、最初の音声パケットの受信時刻は、コンピュータに内蔵した内部時計によって測定されるものである。
【００１６】
また、請求項２に記載された発明は、請求項１に記載された発明において、音声パケットが現在時刻において処理可能かどうかを判定するステップは、最初に受信した音声パケットのタイムスタンプをＴＳ０、最初の音声パケットに続く２番目以降の音声パケットであって、現在処理しようとする音声パケットのタイムスタンプをＴＳｎ、最初に受信した音声パケットの受信時刻をＴ０、連続する音声パケットのタイムスタンプ増加量をＴＳＩ、１つの音声パケットにおける録音時間をＳＴ、任意設定の待機時間閾値をＪＴとしたとき、現在時刻Timeが次式（１）及び（２）
Time≧T0+{(TSn-TS0)/TSI}×ST        （１）
Time−［T0+{(TSn-TS0)/TSI}×ST］≦JT    （２）
を満足するとき、タイムスタンプＴＳｎが付された音声パケットを現在時刻において処理可能であると判定することを特徴とするものである。
なお、請求項３に記載された発明は、請求項２に記載の発明において、任意設定の待機時間閾値ＪＴを、揺らぎを吸収するための揺らぎ吸収バッファサイズに設定するようにしたものである。
【００１７】
また、請求項４に記載された発明は、受信した複数音声ストリームの音声パケット時刻同期処理をリアルタイムで行う同期システムであって、受信した音声ストリームの最初の音声パケットのタイムスタンプを取得するタイムスタンプ取得手段と、受信した音声ストリームの最初の音声パケットの受信時刻を取得する受信時刻取得手段と、最初の音声パケットのタイムスタンプ及び受信時刻を記憶装置に格納する記憶手段と、受信した複数音声ストリームの２番目以降に受信した音声パケットのタイムスタンプと最初に受信した音声パケットのタイムスタンプを減算する減算手段と、この減算したタイムスタンプの差分を１個のタイムスタンプが有する情報量で除算し、該除算結果に一個の音声パケットの記憶時間を乗算して、最初の音声パケットの到来から現在処理している音声パケットの到来までの時間を計測する時間計測手段と、時間計測手段の出力に最初の音声パケットの受信時刻を加算して、受信した音声パケットの処理すべき時刻を算出する時刻算出手段と、この時刻算出手段で算出した時刻と、受信時刻取得手段で取得した時刻とを比較する比較手段と、この比較手段の出力に基づいて、現在時刻の時点で当該音声パケットを処理するか否かを判断する判定手段とからなることを特徴とするものである。
【００１８】
また、請求項５に記載された発明は、請求項４に記載の発明において、音声パケットを処理するか否かを判断する判定手段は、最初に受信した音声パケットのタイムスタンプをＴＳ０、現在処理しようとする音声パケットのタイムスタンプＴＳｎ、最初に受信した音声パケットの受信時刻をＴ０、連続する音声パケットのタイムスタンプ増加量をＴＳＩ、１つの音声パケットにおける録音時間をＳＴ、任意に設定される待機時間閾値をＪＴとしたとき、現在時刻Timeが次式（１）（２）
Time≧T0+{(TSn-TS0)/TSI}×ST        （１）
Time−［T0+{(TSn-TS0)/TSI}×ST］≦JT    （２）
を満足するとき、処理可能であると判定することを特徴とするものである。
なお、請求項６に記載の発明は、請求項５に記載の発明において、任意に設定される待機時間閾値ＪＴを揺らぎ吸収バッファサイズに等しく設定するようにしたものである。
【００１９】
また、請求項７に記載された発明は、ＩＰ電話網を通して複数音声ストリームのやり取りを行う多者間通話システムの発明であって、受信した複数音声ストリームの音声パケットからタイムスタンプを取得するタイムスタンプ取得手段と、受信した複数音声ストリームの音声パケットの揺らぎを吸収する揺らぎ吸収バッファと、この揺らぎ吸収バッファから得られる複数音声ストリームを構成する各音声ストリームの音声パケットを、時刻同期させて処理する手段と、時刻同期処理された複数音声パケットの各音声パケットをミキシング処理する手段と、このミキシング処理した複数音声ストリームを構成する音声パケットを送信する手段とからなることを特徴とするものである。
【００２０】
また、請求項８に記載された発明は、請求項７に記載の発明における時刻同期させて処理する手段を限定したものであり、この処理手段は、受信した音声ストリームの最初の音声パケットのタイムスタンプを取得するタイムスタンプ取得手段と、受信した音声ストリームの最初の音声パケットの受信時刻を取得する受信時刻取得手段と、最初の音声パケットのタイムスタンプ及び受信時刻を記憶装置に格納する記憶手段と、受信した複数音声ストリームの２番目以降に受信した音声パケットのタイムスタンプと最初に受信した音声パケットのタイムスタンプを減算する減算手段と、減算したタイムスタンプの差分を１個のタイムスタンプが有する情報量で除算し、該除算結果に一個の音声パケットの記憶時間を乗算して、最初の音声パケットの到来から現在処理している音声パケットの到来までの時間を計測する時間計測手段と、この時間計測手段の出力に最初の音声パケットの受信時刻を加算して、受信した音声パケットの処理すべき時刻を算出する時刻算出手段と、この時刻算出手段で算出した時刻と、受信時刻取得手段で取得した時刻とを比較する比較手段と、この比較手段の出力に基づいて、現在時刻の時点で当該音声パケットを処理するか否かを判断する判定手段とからなることを特徴としている。
【００２１】
また、請求項９に記載された発明は、請求項８に記載される発明において、音声パケットを処理するか否かを判断する判定手段は、最初に受信した音声パケットのタイムスタンプをＴＳ０、現在処理しようとする音声パケットのタイムスタンプＴＳｎ、最初に受信した音声パケットの受信時刻をＴ０、連続する音声パケットのタイムスタンプ増加量をＴＳＩ、１つの音声パケットにおける録音時間をＳＴ、任意に設定される待機時間閾値をＪＴとしたとき、現在時刻Timeが次式（１）（２）
Time≧T0+{(TSn-TS0)/TSI}×ST        （１）
Time−［T0+{(TSn-TS0)/TSI}×ST］≦JT    （２）
を満足するとき、処理可能であると判定することを特徴とするものである。
なお、請求項１０に記載の発明は、請求項９に記載の発明において、任意に設定される待機時間閾値ＪＴを揺らぎ吸収バッファサイズに等しく設定するようにしたものである。
【００２２】
本発明のリアルタイム同期方法及び同期システム、並びにこれを利用した多者間通話システムにおいては、その前提として、揺らぎを生じる各音声ストリームは時間的に独立しており、データの送信時刻が同じ場合でも、宛先の受信時刻が異なってくるということが考慮されている。このため、音声データをミキシングする必要があるシステムにおいては、揺らぎによる到着時刻や到着順のずれを緩和する必要がある。
【００２３】
本発明によれば、受信した音声ストリームの最初の音声パケットが有するタイムスタンプ及び最初の音声パケットの受信時刻をサーバ内の記憶装置に記憶し、記憶された最初の音声パケットのタイムスタンプ及び最初の音声パケットの受信時刻と、コンピュータ内部時計から得られる現在時刻と、最初の音声パケットに続く２番目以降の音声パケットのタイムスタンプとから、この２番目以降の音声パケットが現在時刻において処理可能か否かをリアルタイムで判定するようにしているので、任意に設定できる待機時間閾値ＪＴ、例えば、揺らぎ吸収のためのバッファサイズとして膨大な数（例えば１００サンプル分の容量、１サンプル20msとして２秒分の容量）を必要としないですむようにしている。
【発明の効果】
【００２４】
本発明のリアルタイム時刻同期方法及び時刻同期システム並びにこれを利用した多者間通話システムによれば、上述のように、膨大な数の揺らぎ吸収バッファを必要とせずに、バッファの中に貯めるデータ量を可能な限り少なくして、揺らぎを緩和することが可能である。
【００２５】
また、ある話者が音声を入力しない場合のストリームには無音圧縮という現象が生じるが、この無音時には、データは送信しないけれども、音声のタイミングを制御するタイムスタンプを増加させておき、次にマイクから音声が入力された場合に、更に必要量だけタイムスタンプを増加させてデータを送るようにしている。このため、無音圧縮が伝送データに発生していても問題なく時間同期を行うことができる。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の実施の形態の例を図面に基づいて説明する。
【００２７】
図１は、一般的な多者間の通話システムの概要図を示すものであり、多者間通話サーバ１と複数のユーザ端末（IP電話器）２がネットワーク３に接続されている。
この多者間の通話サービスにおいては、各ユーザが持っているユーザ端末の機能に差があることから、端末が必ず備えている最低限の機能でサービスを提供することが必要となる。すなわち、電話には、対象に対して電話をかける「シグナリング」機能と、シグナリングにより相手と通話できることが確定した後に音声を送信する「全2重音声伝送」機能が必要となる。ここで全2重とは、自身の音声と相手の音声を同時に扱う事を意味している。
【００２８】
ネットワーク3は、IP電話トラフィックのみ伝送する専用網と、インターネットのように電話以外のトラフィックが伝送されている共有回線も含んでおり、シグナリング機能と全2重音声伝送に関するユーザ端末の前提条件から、サーバでは次の流れで処理を行っている。
【００２９】
まず、シグナリング機能面では、サーバ１が、多者間通話を行うグループに対してユニークなIDを割り当て、ユーザＡはそのIDに対して電話をかける。ここで、ユーザＡは、多者間通話サーバ１と1対1セッションを張っているだけであるが、サーバ１は他のユーザＢ、Ｃ、Ｄともセッションを張っているため、見かけ上、ユーザA、B、C、Ｄはサーバ１を介して仮想的にマルチセッションを張っているといえる。
【００３０】
次に、電話に必要な全2重音声伝送機能面であるが、各ユーザから送信された音声を適切にミキシングし、複数の音声ストリームを一つのストリームに圧縮し、送出することが必要とされる。この全2重音声伝送機能を用いて複数の音声ストリームのやり取りが可能になる。
【００３１】
図２は、多者間通話サーバ１の機能ブロックを説明するための概略図である。１１は電話をかける際の制御を司るシグナリングモジュール、１２は音声データを受信する場合の制御を司るデータ受信モジュール、１３は参加者情報データベース管理操作モジュール、１４は参加者情報管理データベース、１５は正当性のあるパケットとして判別されたデータを格納する受信データキューである。
また、１６は受信データキュー１５に保持されている同一グループのキューの時刻同期制御モジュール、１７は時刻同期制御モジュール１６で同期されたパケットをミキシングするミキシングモジュール、１８はミキシング済みのパケットをストリーム制御プロトコルに合わせた形式になるよう処理し、送信する送信モジュールである。
なお、１９はシグナリングパケット、２０はサーバが受信する音声パケット、２１はミキシング済みでサーバが送信する音声パケットである。
【００３２】
シグナリングモジュール１１は、ユーザからのシグナリングデータを処理するためのモジュールであって、シグナリングデータを内包するパケット１９を受信し、シグナリングデータの内容から多者間通話サービスを提供するために必要となる情報を取得するためのものである。そして、シグナリングモジュール１１は、この取得した情報から、多者間通話サーバ1が多者間通話サービスを提供可能であるか否かを判別し応答する。また、シグナリングモジュール１１はすでに開始済みのサービスを停止するためのシグナリングの処理も行っている。
【００３３】
データ受信モジュール１２は、ユーザからの音声パケットを受信するためのモジュールであり、このモジュールにおいて受信したデータの正当性がチェックされる。例えば、IP電話では音声の送受信に関してストリーム制御プロトコル(RTP)を用い、パケットのロスや遅延を検出している。この正当性チェックは、パケットがロスしたり、遅れすぎたパケットを検出したりした場合にその制御や破棄を行うものである。
【００３４】
参加者情報管理データベース操作モジュール１３は、シグナリングモジュール１１で処理された内容を参加者情報管理データベース１４に反映させるためのモジュールであり、シグナリングモジュール１１からの命令で動作し、参加者情報管理データベース１４に対し、参加の場合は新規にエントリを追加し、脱退の場合は参加者情報管理データベース１４に存在するエントリを探して削除する。参加者情報管理データベース１４には、参加者のネットワーク的な位置情報(IPアドレス等)や、参加しているグループのID、送信状況等が格納されている。
【００３５】
データ受信モジュール１２において正当性のあるパケットとして判別されたデータを格納する受信データキュー１５は、新しいパケットをキュー１５の最後尾に格納し、キュー１５から取り出す場合は先頭から取り出していく。一人のユーザにつき独立した1つのキューを割り当てており、この点で受信データキュー１５は複数のキューの集合体であるといえる。
【００３６】
時刻同期制御モジュール１６は、受信データキュー１５に保持されている、同一グループのキューの時刻同期制御を行うものであり、この時刻同期制御モジュール１６における同期制御は、パケット交換網で発生する、データの到着時間に一貫性の無い「揺らぎ」という現象を回避するために必要とされる。この同期制御が行われないと、揺らぎの影響により、参加者全員の音声は同時に到着することが無く、データの到着順が異なってしまう。このため、ミキシング対象のデータが実時間的に同時に送出された音声であるかを判別し、時間を合わせる時刻同期が必要となる。同期を行わないで各送話者からの音声データの到着時刻がずれると、ミキシングを行うべきでないもの同士をミキシングすることになり、ノイズが発生して音声品質が悪くなる。また、同時に発生された音声パケットのうちの一方の到着が遅れた場合は、その一方の音声データの処理が、先に到着した他方の音声パケットの次に処理すべき他方のデータと一緒に処理されるため、処理後のミキシング音声に間延びが現れることになり、音声品質に悪影響を及ぼすことになる。
【００３７】
送信モジュール１８は、ミキシング済みのパケットをストリーム制御プロトコルに合わせた形式になるように処理し、送信するモジュールであり、ここでの送信状況は参加者情報管理データベース１４で一括管理しているため、参加者情報管理データベース１４から送信状況に関する情報を取得し、その情報を元にパケットを整形し、整形されたパケット２１がユーザに送信される。
【００３８】
図３は、図２の２０、２１で送受信されるＲＴＰをストリーム制御プロトコルとするパケットフォーマットを示したものである。３１は、ＲＴＰで定義された音声ストリームの何番目のパケットであるかを示すシーケンス番号であり、パケットが一つ送信されるたびに１ずつ増加する。そのため、最後に受信した音声パケットのシーケンス番号との差が１にならない場合は、パケットロスが発生したと判断される。
【００３９】
３２はＲＴＰで定義されているタイムスタンプである。タイムスタンプ３２は時間情報ではなく、送信されたデータのデータサイズで表現されている。このタイムスタンプは主として再生タイミングの制御に用いられる。３３は、ＲＴＰで定義されているストリームの識別子であり、同一ストリームではこの識別子は常に同じになる。３４は、ユーザ端末で音声をデジタル化したペイロード（音声データ）である。
【００４０】
図４は、参加者情報管理データベース１４における時刻同期に関係するデータ構造を示すものである。
４１には、多者間通話の１グループの通話に、任意の時間に参加している参加者数が保持される。４２には、参加者情報を保持する配列のアドレスが格納される。この参加者情報を保持する配列のアドレス４２の内部構造は、参加者情報保持テーブル４３に示されている。このように、参加者情報保持テーブル４３には、ＩＤキーとそれに対応する指定されたアドレスとが保持されている。このＩＤ番号と対応する情報のアドレスの詳細はユーザ固有の情報テーブル４４に示されている。すなわち、テーブル４４には、ユーザのＩＤ番号４５に対応して、ユーザ固有の受信データキューの先頭アドレス４６と、ユーザ固有の受信データキューの最後尾アドレス４７と、最初に受信した音声パケットの受信時刻４８と、最初に受信した音声パケットのタイムスタンプ４９とが格納されている。
【００４１】
同時刻処理は、ユーザ固有の受信データキューの先頭アドレス４６で指定されているユーザに対して行われる。また、ユーザ固有の受信データキューの最後尾アドレス４７には、図２で説明したメディアデータを処理するブロックであるデータ受信モジュール１２で処理された音声パケットのアドレスが格納される。また、最初に受信した音声パケットの受信時刻４８は、多者間通話サーバ１におけるコンピュータ内部時計の時間を格納するものであり、この時間をミリ秒以下の制度で保持している。最初に受信した音声パケットのタイムスタンプ４９は、最初に受信した音声パケットの受信時刻４８とともに、時刻同時処理に用いられる。
【００４２】
次に、図５に基づいて、音声パケットの受信からミキシングして送信するまでの音声パケットの流れにそって、本発明の全体像を説明する。ここでは多者間通話に参加する3人のユーザＡ、Ｂ、Ｃからの音声データのミキシング処理について説明する。
図５に示すように、音声パケットの受信から音声パケットの送信までの全体システムは、複数参加者Ａ、Ｂ、Ｃからの音声パケットデータを受信して、時刻の刻印を行うタイムスタンパ５２と、揺らぎの吸収処理を行うバッファ５３と、時刻同期処理部５４と、データミキシング処理部５５と、データ送信処理部５６と、これら全体の時間のタイミングを制御するコンピュータ内部時計５７とから構成される。コンピュータ内部時計５７は、タイムスタンパ５２と、時刻同期処理部５４において主として利用される。カウンタ５８は固定周期、すなわち、音声パケットの１つの時間、例えば20msをカウントしてリセットするカウンタである。
【００４３】
次に、図５の全体システムの動作を説明する。ユーザＡ、Ｂ、Ｃからの音声パケット５１ａ、５１ｂ、５１ｃは、タイムスタンパ部５２に供給される。ここで、ユーザＡ、Ｂ、Ｃから送られてくる音声パケットには、その発生時には同時刻であっても、５１ａ〜５１ｃに図示するように、到達時間にばらつきが生じている。これは、上述したように、送話者側では音声サンプリング、エンコード、パケット化に伴った遅延時間が生じ、あるいは伝送経路中の伝送距離に応じた伝播遅延や経路にあるルータにおけるパケットのキューイング遅延等が生じるからである。
【００４４】
図６はタイムスタンパ部５２の処理と動作を説明するための図である。ユーザA、B、Cから発せられる音声パケットのヘッダには、図３の３２に示されるように、タイムスタンプが刻印されている。タイムスタンパ部５２は、それぞれのユーザから受信した音声パケットのストリームにおける最初の音声パケットの受信時刻Ｔ０とタイムスタンプＴＳ０を取得し、受信時刻Ｔ０を図４の４８に、タイムスタンプＴＳ０を同じく図４の４９にそれぞれ格納する。そして、受信した音声パケットを受信データキューの先頭アドレス４６（図４）に、受信データキューの最後尾アドレスを４７（図４）に格納する。
【００４５】
ユーザAから最初に発せられた音声パケットの受信時刻Ｔａ０、ユーザBから最初に発せられた音声パケットの受信時刻Ｔｂ０、ユーザCから最初に発せられた音声パケットの受信時刻Ｔｃ０とされ、この受信時刻とそれぞれの最初の音声パケットのタイムスタンプＴＳa0、ＴＳｂ０、ＴＳｃ０とにより、それ以降の音声パケットの処理時刻が算出される。また、各ユーザから発せられたｎ番目の音声パケットのタイムスタンプＴＳｎは、受信したデータサイズの累計で表現されるので、例えば、音声パケットのデータサイズが100バイトであれば、ｎ番目のパケットのタイムスタンプＴＳｎは100ｎバイトとなる。そして、そのタイムスタンプＴＳｎの音声パケットを処理すべき時刻は、後述する数式（１）の右辺で表現される時刻となるのである。
このことは、各ユーザから発せられた音声パケットは、他のユーザの音声パケットとはかかわりなく、自己の音声ストリームの最初に到着した音声パケットの到着時刻Ｔ０と、同音声パケットのタイムスタンプＴＳ０のみから、それ以降の音声パケットの処理時間が決定されるということを意味している。
【００４６】
図7は、上述のタイムスタンパ部５２の動作を説明するためのフローチャートである。ＩＰ電話網とのコネクションが行われ、回線が接続されると、最初に音声パケットの受信が行われる（ステップＳ６１）。次に、受信したパケットが回線接続後に最初に受信した音声パケットか否かが判断される（ステップＳ６２）。
受信した音声パケットが最初の音声パケットである場合には、計算機内部時計５７が与えるそのときの受信時刻を図４に示されるユーザ固有の情報テーブル４４の「最初に受信した音声パケットの受信時刻（Ｔ０）」の欄４８に格納する。また、続いて、その音声パケットのタイムスタンプＴＳ０をヘッダ部から読み出し、同じくユーザ固有情報テーブル４４の「最初に受信した音声パケットのタイムスタンプ（ＴＳ０）」の欄４９に格納する（ステップＳ６３）。
【００４７】
判断ステップＳ６２で受信した音声パケットが、その音声ストリームにおける最初の音声パケットではないと判断された場合は、ステップＳ６３を飛ばして、この音声パケットのアドレスを図４に示すユーザ固有の情報テーブル４４の「受信データキューの最後尾アドレス」の欄４７に格納する（ステップＳ６４）。
【００４８】
次に、各ユーザの電話器がＩＰ電話網に接続されているか否かのコネクションの状態を判断する（ステップＳ６５）。コネクションが接続状態であれば、ステップＳ６１に戻り、次の音声パケットの受信を待つことになる。また、判断ステップＳ６５において、コネクションが切断されたと判断された場合には、音声パケットのタイムスタンプの処理を終了させる。
【００４９】
図５に示すように、タイムスタンパ部５２でタイムスタンプが付与されたユーザＡ、Ｂ、Ｃからの音声パケットデータは、揺らぎ吸収バッファ５３に送られる。この揺らぎ吸収バッファ５３は、図２で示した受信データキュー１５において実現されるものであり、受信データキュー１５に保持されている音声パケットの録音時間の累計時間と同じ揺らぎを吸収することが可能である。1つの音声パケットあたりの録音時間が20msであるから、受信データキュー１５に2つの音声パケットを保持するようにすれば40msまでの揺らぎを吸収することができる。
【００５０】
揺らぎ吸収処理が行われた各音声データは、時刻同期処理部５４に送られる。時刻同期処理部５４は、20ms周期で動作するカウンタ５８によってその処理が開始される。この同期処理は、サーバ内で動作するコンピュータの内部時計５７で取得した現在時刻Timeが、数式（１）を満たすかどうかを判別することによって行われる。すなわち、比較すべき音声パケットのタイムスタンプＴＳｎが、図４の４８に格納されている最初に受信した音声パケットの受信時刻Ｔ０、同じく図４の４９に格納されている最初に受信した音声パケットのタイムスタンプＴＳ０、連続する音声パケットのタイムスタンプの増加量ＴＳＩ（例えば100バイト）、音声パケットの送信周期でありかつ1つの音声パケットにおける録音時間ＳＴ（例えば20ms）を固定値とした場合に、サーバの動作するコンピュータの内部時計５７で取得した現在時刻（Time）が数式（１）を満たすか否かの判断によって、処理可能な音声パケットかどうかが判断される。
Time≧T0＋{( TSn−TS0)/TSI}×ST        （１）
【００５１】
ここで、 (TSn−TS0)は、受信した音声パケットの増加バイト数であり、TSIはタイムスタンプのバイト数を表すから、{(TSn−TS0)/TSI}は、増加した音声パケット数を表し、この値に１つの音声パケットにおける録音時間ＳＴ（例えば20ms）を掛け、最初の受信時刻を足した右辺の値は、タイムスタンプＴＳｎが付された音声パケットが到着する時間を示している。  
したがって、数式（１）で示す不等式を満たす場合は、処理されるべき音声パケットの到着時間が実際の時間より小さいこと、すなわち現在時刻より前の時刻（前に処理されるべき時刻）を意味するから、この音声パケットは処理されなければならないものである。
【００５２】
ここで、数式（１）に示す不等式が成立しなくなったとき、すなわち、数式（１）の右辺（タイムスタンプTSｎが付された音声パケットの処理時間）が左辺の現在時刻(Time)よりも大きいときは、タイムスタンプTSｎが付された音声パケットを処理する時間がまだ来ていないことを意味している。この場合には、処理すべきパケットは次の処理時間がくるまで、待ち行列の先頭に戻って処理時間が来るのを待つことになる。
【００５３】
また、数式（１）に示す不等式を満たすだけでは、かなり遅れて到着した音声パケットを処理可能として判断することになる。例えば、現在時刻(Time)よりも1秒以上遅れて到着した音声パケットを処理してしまうことになって、処理後の音声が極めて聞き苦しいものとなる。そこで、任意設定の待機時間閾値（JT）（例えば、パケット2個分の遅延時間40msを有する「揺らぎ吸収バッファサイズ」とする。）を設け、数式（３）を満たす場合、すなわち、現在時刻(Time)とタイムスタンプTSｎが付された音声パケットの処理時刻との差が、揺らぎ吸収バッファサイズJTより大きい場合は、無視できない遅延が発生したと判断して、その音声パケットを処理しないようする。つまり、数式（１）に示す不等式を満たしても、数式（２）の条件を満たすような音声パケットは破棄することにしている。
Time−(T0＋{( TSn−TS0)/TSI}×ST)＞JT        （３）
【００５４】
時刻同期処理部５４で処理され同期されていると判断された時刻同期処理済み音声パケットは、データミキシング処理部５５に送られ、ここで複数参加者からの音声パケットデータのミキシングが行われて、データ送信処理部５６を介して、自分以外の他の参加に送信される。
【００５５】
図８は、時刻同期処理部５４の機能ブロック構成図である。時刻同期処理部５４は、キューの先頭データを取得する先頭データ取得ブロック７２と、サーバの時刻とデータの処理されるべき時間を比較する時間比較ブロック７３と、時間比較ブロック７３の出力を得て処理すべき時間が到来しているか否かを判断する判別ブロック７４と、この判断結果の特別な場合に処理を行わないように制御する処理ブロック７５から構成される。
【００５６】
以下、図８の機能ブロック図の動作を説明すると、同期処理対象データの格納キュー７１に格納されている音声パケット７１ａ〜７１ｃが先頭データ取得ブロック７２に供給される。先頭データ取得ブロック７２で取得されたデータは、そのデータの処理されるべき時間とサーバの時刻とを比較する処理時間比較ブロック７３に送られる。そして、この比較ブロック７３の出力が判別ブロック７４に供給され、ここで、受け取ったデータがまだ処理すべきでないと判定された場合に、このデータの処理を行わないで、処理対象データ格納キュー７１の先頭に戻すようにする。そして、判別ブロック７４で処理すべきと判断された音声データは処理ブロック７５に供給されるが、ここで、既に処理時間来ていると判断された音声データであっても、現在時刻との時間差が所定基準より大きいと判断された場合は、この音声データの処理を行わないで破棄し、同期処理対象データ格納キュー内の次のデータを参照するようにする。判別ブロック７４で処理時間が既に来ていると判定され、かつ処理ブロック７５において現在時刻との当該データの処理時間との時間差が所定基準内にあると判定された音声データのみが処理されて、図５に示すデータミキシング部５５に時刻同期データ７６として出力される。
【００５７】
次に、図８の先頭データ取得ブロック７２と処理時間比較ブロック７３について、図９の詳細ブロック図を参照して詳しく説明する。
先頭データ取得ブロック７２は、先頭データ取得部７２ａと、受信時刻取得部７２ｂと、計算機内部時計７２ｃとから構成される。また、処理時間比較ブロック７３は、音声パケットキューの先頭データのタイムスタンプＴＳｎと、最初に受信した音声パケットのタイムスタンプＴＳ０の差(TSn−TS0)を計算するタイムスタンプ差取得部７３ａと、このタイムスタンプ差(TSn−TS0)、タイムスタンプの増加量（TSI）、１サンプルの録音時間ST（例えば20ms）とから、最初に受信した音声パケットから同期処理対象データ格納キューの先頭データを受け取るまでの経過時間を求める経過時間取得部７３ｂと、この経過時間と最初の音声データを受信した時刻Ｔ０を加算する処理時刻算出部７３ｃと、処理されるべき時刻と現在の時刻(Time)とを比較する処理時刻・現在時刻比較部７３ｄと、最初に受信した音声データの受信時刻Ｔ０とそのデータ内のタイムスタンプＴＳ０を保存するバッファ７３ｅとから構成される。
【００５８】
図９の動作を説明する。同期処理対象データ格納キュー７１に格納された音声データ７１ａ〜７１ｃは、先頭データ取得部７２ａにおいて、計算機内部時計７２ｃからの受信時刻が与えられる。この受信時刻は受信した音声データが最初のパケットである場合に、その受信時刻Ｔ０がバッファ７３ｅに格納される。また、そのときのタイムスタンプＴＳ０が同じく保持バッファ７３ｅに格納される。このバッファ７３ｅは、図４に示したユーザ固有の情報テーブル４４の「最初に受信した音声パケットの受信時刻（Ｔ０）」の欄４８と、その音声パケットのタイムスタンプＴＳ０を格納する同じくユーザ固有情報テーブル４４の「最初に受信した音声パケットのタイムスタンプ（ＴＳ０）」の欄４９に相当するものである。
【００５９】
次に、タイムスタンプ差取得部７３ａにおいて、同期処理対象データ格納キュー７１から読み出される先頭データに付されたタイムスタンプＴＳｎと最初に受信した音声パケットのタイムスタンプＴＳ０との差(TSn−TS0)が算出され、経過時間算出部７３ｂにおいて、このタイムスタンプ差、タイムスタンプの増加量（TSI）、１サンプルの録音時間ST（例えば20ms）とから、最初に受信した音声パケットから同期処理対象データ格納キューの先頭データを受け取るまでの経過時間｛(TSn−TS0)/TSI｝*STが計算される。
【００６０】
次に、処理時刻算出部７３ｃにおいて、経過時間算出部７３ｂで求められた経過時間と保持バッファ７３ｅに記憶されている最初に受信した音声パケットの受信時刻T0が加算され、タイムスタンプTSｎが付与された音声パケットの処理時刻[To+｛(TSn−TS0)/TSI｝*ST]が求められる。そして、時刻比較部７３ｄにおいて、時刻算出部７３ｃで計算された上記処理されるべき時刻と現在時刻（Time）とが比較され、比較結果が判別ブロック７４に送られる。以下、図８の動作説明で説明したとおりである。
【００６１】
図１０は、図５及び図８に示す時刻同期処理部５４の動作を経時的に順を追って説明するためのフローチャートである。上述したように、この時刻同期処理部５４は、パケット交換網で発生するデータの到着性に一貫性がない「揺らぎ」現象を回避するために必要なものである。まず、回線が接続されてから、音声パケットの１つに録音されている固定の時間、例えば20msだけ音声パケットの受信を待機させる（ステップＳ１０１）。
【００６２】
次に、図５のカウンタ５８のカウント値“ｉ”を“０”に初期化する（ステップＳ１０２）。ここで、初期化した“０”の値は、図４に示す参加者情報保持テーブル４３におけるグループ参加者の最初のＩＤ番号“０”に相当し、カウンタ５８は、このＩＤ番号“０”からカウントを開始し、グループの参加人数Ｎとすると、Ｎ−１で終了するように動作する。なお、本例では、カウンタ５８としてアップカウンタを用いており、参加者毎に＋１インクリメントしているが、カウンタ５８としてダウンカウンタを用いることもできる。この場合には、カウント値“ｉ”を“Ｎ−１”に初期化し、一人の参加者のストリームを処理するたびに−１デクリメントをする。そして、カウント値が“０”になったとき、処理を終了するように動作させる。
【００６３】
次に、参加者情報の保持テーブル４３において、カウンタ５８の値“ｉ”と同じＩＤを持つユーザを選定し、図４に示すユーザ固有の情報テーブル４４から、図２の受信データキュー１５の先頭アドレス４６に格納されている音声パケットを参照する（ステップＳ１０３）。そして、ステップＳ１０３で参照した先頭アドレス４６に格納されている音声パケットのタイムスタンプを調べ、不図示のメモリ装置にタイムスタンプを変数TSnとして格納する（ステップＳ１０４）。
【００６４】
続いて、多者間通話サーバ１における現在時刻Timeをサーバ内の計算機内部時計５７から取得し、これを同じく不図示のメモリ装置に格納する（ステップＳ１０５）。現在の処理対象となっている音声パケットが処理可能であるかどうかの判断は、上述した数式（１）の右辺で示すタイムスタンプ等から計算した値とこの現在時刻Timeと比較することで行われる。
【００６５】
すなわち、既に説明したように、図７のステップＳ６３で取得した、最初に受信した音声パケットの受信時刻(T0)４８及び最初に受信した音声パケットのタイムスタンプ(TS0)４９と、連続する音声パケットのタイムスタンプの増加量(TSI)、音声パケットの送信周期でありかつ1つの音声パケットにおける録音時間(ST)を固定値として用い、ステップＳ１０４で取得した音声パケットのタイムスタンプ(TSn)を、ステップＳ１０５取得したサーバの動作するコンピュータの内部時計５７で取得した現在時刻(Time)と、比較することで行われる。
【００６６】
ここでは、各変数を用いた不等式（１）、（２）
Time≧T0＋{( TSn−TS0)/TSI}×ST           （１）
Time−Ｔ0＋{( TSn−TS0)/TSI}×ST≦JT      （２）
とが、ともに成立するか否かが判断される（ステップＳ１０６）。
【００６７】
既に説明したように、判断ステップＳ１０６で数式（１）が成立している場合は、タイムスタンプTSｎが付された音声パケットが処理すべき時間内にあることを意味し、数式（２）を満たす場合とは、タイムスタンプTSｎが付された音声パケットが、任意設定の待機時間閾値以下、例えば、揺らぎバッファサイズ以下の遅延を持つことを意味する、すなわち、既に説明した数式（３）とは逆に、無視できないほどの遅延が発生していないことを意味している。
【００６８】
この数式（１）と数式（２）の条件をともに満たす場合のみ、その音声パケットが処理すべき音声パケットとして判断される（ステップＳ１０７）。そして、数式（１）を満たさない音声パケットは、現在時刻(Time)において、まだ処理する時間が来ていないとして、待ち行列の先頭に戻され、数式（１）を満足していても、数式（２）を満足しない場合、すなわち、数式（３）を満たす場合には、無視できない遅延が発生しているとして、その音声パケットは処理されずに破棄される。
【００６９】
次に、カウンタ５８のカウント値“ｉ”が“Ｎ−１”（グループの参加人数Ｎ）に達したか否かが判断される（ステップＳ１０８）。判断ステップＳ１０８において、カウンタ５８のカウント値“ｉ”が“Ｎ−１”に達しない場合は、カウンタ５８の値“ｉ”を“ｉ＋１”にインクリメントし（ステップＳ１０９）、別のＩＤ番号（図４参照）の音声ストリームの処理に移行する。判断ステップＳ１０８で、カウンタ５８のカウント値“ｉ”が“Ｎ−１”に達したと判断された場合は、カウンタ５８が終了条件を満たしたと判断され、ステップＳ１０７までで処理可能と判別された音声パケットの集合のミキシング処理を行う（ステップＳ１１０）。
【００７０】
続いて、各参加者の電話器とＩＰ電話網とのコネクションが接続中であるかが判別される（ステップＳ１１１）。コネクションが接続中であればステップＳ１０１からの処理を継続し、切断されていれば時刻同期処理を終了する。
【００７１】
次に、図５のデータミキシング処理部５５の構成及び動作について、図１１及び図１２に基づいて説明する。図１１はミキシング処理の機能ブロック図であり、図１２はその説明のための波形図である。
図１１は、ミキシング処理する音声パケットデータが2つの場合を示している。ミキシング対象データ８１ａと８１ｂは比較処理を行うサンプルの組を取得するサンプル取得ブロック８２に供給される。次に、サンプル取得ブロック８２で取得されたサンプルの先頭のサンプルが絶対値計算ブロック８３に供給され、ここで取得されたサンプルの振幅値の絶対値が計算される。絶対値計算ブロック８３でサンプルの振幅値は、大小比較ブロック８４に供給され、ここで絶対値の大小が比較される。
【００７２】
続いて、大小比較ブロック８４で比較されたサンプルの振幅の絶対値のうち大きいほうの絶対値のサンプルがサンプル選択ブロック８５で選択され、サンプル数管理ブロック８６に供給される。サンプル数管理ブロック８６は、何個ごとのサンプルについて選択処理を行うかを予め設定して管理するブロックであり、例えば、各音声パケットの連続するK個（例えば4個）のサンプルのうち最初のサンプルのみを、大小比較ブロック８４に供給し、続く（K−１）個のサンプルについては、最初のサンプルの比較で大きいと判断された側の音声データのサンプルの振幅絶対値をミキシングデータ出力ブロック８７に送るためのものである。この場合、続く（K−１）個のサンプルについては、振幅値の絶対値計算ブロック８３において絶対値計算がなされるだけで大小比較はおこなわれない。ここで、K＝１であれば、全てのサンプルについて、絶対値計算と絶対値の大小比較をおこなうことになることは言うまでもない。
データ出力ブロック８７は、ミキシング済みデータ８８を図5のデータ送信処理部５６に供給するためのものである。
【００７３】
上述した音声ミキシング処理は、ＰＣＭ(Pulse Code Modulation)化された音声信号について行われ、ミキシング対象となる音声パケットのサンプル（例えば、サンプリング周波数を8kHzとする。参加者数によっては16kHzや32kHzとすることもできる。）を比較し、比較条件を満たした方を選択することでミキシングが行われる。例えば、８kHzのサンプリングでは、２つの音声ストリームをミキシングする場合、1秒間に8000回の処理を必要とする。また、この処理の回数は参加人数が多くなると、それに比例して大きくなる。
【００７４】
図１２は、ユーザから送られる図１１に示すミキシング対象データ８１ａ（図１２の９１）と８１ｂ（図１２の９２）の全てのサンプルについて、大小比較を行う例を示した波形図である。PCM音声は、ビットレートや圧縮方式によりデータ形式が異なるため、詳細な比較条件は違ったものとならざるを得ない。ただ、基本的な概念は、音声データを波形表示した際に、振幅の絶対値９０を求め、大きい方のサンプルを選択することである。
【００７５】
図１２に示すように、ユーザから送られた音声パケット９１と音声パケット９２のそれぞれは、サンプルごとに大きいほうが選択され、ミキシングデータ９３として出力される。すなわち、音声パケット９１の最初のサンプル９１ａと音声パケット９２の最初のサンプル９２ａとを比較すると、その絶対値はサンプル９１ａの方が大きいので、サンプル９１ａがミキシングデータとして選択される。この選択は、見かけ上荒い制御ではあるが、実際に扱っている１サンプル当たりの録音時間は8000分の1秒（8kHzサンプリングの場合）とミクロなレベルの制御となる。
【００７６】
図１３は、入力されるミキシング対象データが４つの場合の例であり、その他の処理機能ブロックは図１１と同じであるので、同一符号を付し、説明は省略する。本例ではミキシング対象データが４つの例を示しているが、ミキシング対象データの数をいくらにするかは、多者間通話の参加者数によって決まるものであり、通話が可能であれば４以上であってもよいことは言うまでもない。
【００７７】
次に、図１４のフローチャートに基づいて、本発明のミキシング方法の手順について説明する。最初に、ミキシングを行うための音声パケットデータの入力が行われる（ステップＳ１２１）。続いて、図１１（図１３も同じである）のサンプル数管理ブロック８６における処理中のサンプルの順番を表す番号“ｉ”を“１”に初期化する（ステップＳ１２２）。次に、図１１のサンプル取得ブロック８２において、各入力データの“ｉ”番目のサンプルからＫ個のサンプルの組を取得する(ステップＳ１２３)。ここで、Ｋは、同時に処理するサンプル数であり、固定値である。
【００７８】
次に、図１１に示す絶対値計算ブロック８３において、各サンプルの組から“ｉ”番目のサンプルの振幅値の絶対値が計算され（ステップＳ１２４）、計算された各々の絶対値は大小比較ブロック８４においてその大小関係が比較され、最大の絶対値を持つものが選択される（ステップＳ１２５）。続いて、図１１のサンプル選択ブロック８５において、振幅値が最大となったサンプルの組の“ｉ”番目から“（ｉ＋Ｋ）−１”番目までのＫ個の出力データが出力サンプルとして選択される（ステップＳ１２６）。
【００７９】
次に、サンプル数管理ブロック８６において、“ｉ”を“ｉ＋Ｋ”に更新する。例えば“ｉ”が“１”で“Ｋ”が“４”であれば、次に最大値を比較するサンプルは“４＋１”番目、つまり“５”番目のサンプルになる。ここで、全てのサンプルについて大小関係を判断する場合では、“Ｋ”が“１”となることはいうまでもない。
サンプル処理の順番管理用の番号“ｉ”が更新されると、続いて“ｉ”が入力データの最後に達したか否かが判断される（ステップＳ１２８）。ここで、入力データがまだあるとき、すなわち最後まで処理されていないときは、ステップＳ１２３に戻り、各入力データから再び更新された“ｉ”番目のデータからＫ個のサンプルを取得する。判断ステップＳ１２８で“ｉ”が入力データの最後に達したと判断されると、結果を出力して処理を終了する（ステップＳ１２９）。  
【００８０】
以上、図１１〜図１４に基づいて、複数ストリームの音声パケットのミキシング処理について説明した。この音声ミキシング処理によれば、1回の処理にかかる処理時間は、データに四則演算を行う波形の重ねあわせよりも少ないため、処理時間の低減が可能である。また、ここで用いられる比較ミキシングによれば、複数（特に、３つ以上）のストリームを同時にミキシングする場合には、さらに処理時間の低減を行うことが可能である。
すなわち、波形の重ねあわせで３つのデータをミキシングする場合、まず２つのデータをミキシングし、その結果を残りのデータとミキシングする必要がある。したがって、ミキシングテータ数を8000バイト、ミキシング対象データを“Ｎ”とすると、必要計算数は8000＊”Ｎ−1”となる。
【００８１】
また、上記ミキシング処理によれば、例えば、３つのミキシング対象データＡ、Ｂ、Ｃをミキシングする場合、Ａ、Ｂ、Ｃ全てのデータに対して、同時に比較演算を行って絶対値最大のものを選択するので、必要計算数はミキシング対象データの数にかかわらず常に8000回/秒になる。
【００８２】
また、音声データの比較でミキシングすることで、さらに高速化を図ることができる。PCM音声には、Differential PCMと呼ばれる圧縮方式がある。これは、連続するサンプル間の差が小さいことを利用し、連続する2つのサンプルの差を取ることで圧縮する手法である。この概念を応用することにより、大小比較を行うミキシングでは、大小比較を行ったサンプルの次のサンプルへも、高確率で結果を適用することができる。
【００８３】
仮に3つ先のサンプルまで比較結果を適用した場合、まず1サンプル目を比較し、大きな方を選択する。次の2・3・4サンプル目は、1サンプル目で選択したデータのサンプルを選択するようにする。次に5サンプル目のデータを比較処理し、6・7・8サンプル目のデータは5サンプル目の比較処理で選択したデータのサンプルを選択する。Nサンプル目を比較した場合、N+1・N+2・N+3サンプル目はNサンプル目で選択した側の音声データのサンプルを比較することなく選択する。これを繰り返すことにより、必要となる計算数は2000回/秒となり、計算量が４分の１に低減される。
【００８４】
この方法は、一見荒い制御に見えるが、実際はかなりミクロな時間軸での制御であること、かつ会話では全員が同時に発声することは稀であるので、ほとんど問題にならないで話者の声を識別することが可能である。音楽、男声、女声でミキシングを行った場合、全ての音声を容易に聴覚レベルで認識する事が可能であり、高品質な音声ミキシングを実現できる。
【００８５】
本発明の複数ストリームの音声パケットの時刻同期処理方法及び同期システムによれば、任意設定の待機時間閾値、例えば揺らぎ吸収バッファサイズと同じ遅延時間を余計に費やすだけで、多者間通話システムにおける揺らぎや遅延の問題が解決され、複数の音声ストリームのリアルタイムの同期が実現される。また、特定の話者から音声データが送信されない無音時であっても、その音声ストリームのタイムスタンプを増加させることによって、問題なく時間同期を行うことができる。
【００８６】
以上、本発明の実施の形態について説明したが、本発明はここで説明した実施の形態に限らず、本発明の要旨を逸脱することなく、その他の種々の構成を採りうるものであることは言うまでもない。
【図面の簡単な説明】
【００８７】
【図１】本発明の実施の形態によるネットワークを基盤とする多者間通話システムの概略図である。
【図２】図1における多者間通話サーバ１の機能ブロックを説明するための概略図である。
【図３】ＲＴＰをストリーム制御プロトコルとするパケットフォーマットである。
【図４】図２における参加者情報管理データベース１４における時刻同期に関係するデータ構造を示す図である。
【図５】音声パケットの受信からミキシングして送信するまでの音声パケットの流れを示すシステム構成図である。
【図６】複数音声ストリームの最初の音声パケットの受信時刻とタイムスタンプを示す図である。
【図７】複数音声ストリームの最初の音声パケットの受信時刻とタイムスタンプの処理を説明するためのフローチャートである。
【図８】図５の時刻同期処理部５４の概略構成を示す機能ブロック図である。
【図９】図５の時刻同期処理部５４の内部構成をさらに詳細に示す機能ブロック図である。
【図１０】図５の時刻同期処理部５４の動作を説明するためのフローチャートである。
【図１１】ミキシング対象データが２つの場合の、図５のミキシング処理部５５の細部構成を示す機能ブロック図である。
【図１２】ミキシング処理を説明するための波形図である。
【図１３】ミキシング対象データが４つの場合の、図５のミキシング処理部５５の細部構成を示すブロック図である。
【図１４】ミキシング処理を説明するためのフローチャートである。
【図１５】従来の同期処理システムを説明するための図である。
【図１６】揺らぎの発生による従来の同期処理システムの問題点を説明するための図である。
【符号の説明】
【００８８】
１・・・多者間通話サーバ、２・・・IP電話機 、３・・・ネットワーク(インターネット、IP網等)、１１・・・シグナリングモジュール、１２・・・データ受信モジュール、１３・・・参加者情報管理データベース操作モジュール、１４・・・参加者情報管理データベース、１５・・・受信データキュー、１６・・・時刻同期制御モジュール、１７・・・ 音声ミキシングモジュール、１８・・・データ送信モジュール、１９・・・シグナリングパケット、２０・・・音声パケット(サーバが受信)、２１・・・音声パケット(ミキシング済みでサーバが送信)、５２・・・タイムスタンパ部、５３・・・揺らぎ吸収バッファ、５４・・・時刻同期処理部、５５・・・データミキシング処理部、５６・・・データ送信処理部、７２・・・先頭データ取得ブロック、７３・・・時間比較ブロック、７４・・・判別ブロック、７５・・・処理ブロック、７２ｂ・・・現在時刻取得部、７３ａ・・・タイムスタンプ差取得部、７３ｂ・・・経過時間取得部、７３ｃ・・・処理時刻算出部、９２・・・サンプル取得ブロック、９３・・・絶対値計算ブロック、９４・・・大小比較ブロック、９５・・・サンプル選択ブロック、９６・・・サンプル数管理ブロック、９７・・・データ出力ブロック、９８・・・ミキシング済みデータ
【図１】
2005159570.tif 000003
【図２】
2005159570.tif 000004
【図３】
2005159570.tif 000005
【図４】
2005159570.tif 000006
【図５】
2005159570.tif 000007
【図６】
2005159570.tif 000008
【図７】
2005159570.tif 000009
【図８】
2005159570.tif 000010
【図９】
2005159570.tif 000011
【図１０】
2005159570.tif 000012
【図１１】
2005159570.tif 000013
【図１２】
2005159570.tif 000014
【図１３】
2005159570.tif 000015
【図１４】
2005159570.tif 000016
【図１５】
2005159570.tif 000017
【図１６】
2005159570.tif 000018