JP6464397B2 - 音声通信装置 - Google Patents

Description

本発明は、音声通信装置に関し、例えば、ＩＰプロトコルに従って音声データを受信し、受信した音声を再生する音声通信装置に関する。

近年、音声データをパケット化し、ＲＴＰ（Real-time Transport Protocol）を利用して、音声通話を行うＶｏＩＰ（Voice over Internet Protocol）通話装置が利用されている。このＶｏＩＰ通話装置では、インターネット網等の通信品質が必ずしも十分に確保されていない公衆ネットワークを利用して音声データを送受信する。そのため、ＶｏＩＰ通話装置では、通信経路の遅延、データ消失等の問題に起因して、通話品質が劣化することがある。そのため、ＶｏＩＰ通話装置では、通話品質の確保のために、パケットデータの送受信状況をモニタすることが行われる。そこで、パケットデータの送受信状況をモニタする技術が特許文献１〜５に開示されている。

特許文献１では、計測装置と中央局とにより構成されるネットワーク制御システムが開示されている。この計測装置は、時刻情報配信装置から配信された時刻情報を受信し、その時刻情報に基づいて計測装置間の時刻を同期させる。また、中央局は、トラフィック観測データを収集して解析する観測データ収集装置と、リンクに対するトラフィック量、パケットロス量、特定のフローに対するネットワーク遅延量、または遅延ジッタ量を含むネットワーク品質の解析結果およびフロー毎の経路情報を基に、フロー毎に最適経路を探索し、該当するネットワークノード装置１０に対して経路設定を行うネットワークノード制御装置と、を備える。

特許文献２では、一般仕様のトラフィックストリームの要求を特定するステップと、特定されたトラフィック要求を、要求と伝送媒体のオーバーヘッド及び状態を考慮して別の形態に変形するステップと、伝送媒体の状態に最適にモニタされたフィードバックステータスに従って仕様を調整するステップと、媒体確保の間に被るオーバヘッドと同様に、仕様を維持し処理に必要なリソースを減らすため、多重トラフィックストリーム仕様を単一仕様に統合するステップと、仕様に従って媒体確保スケジュールを生成するステップと、伝送のコーディネート用に媒体確保を実行するステップと、を含むリアルタイムデータの提供方法が開示されている。

特許文献３では、インターネット網から受信されるパケットに対し、その遅延、ジッタ、データロス率の少なくとも一つを測定する測定手段、前記測定手段からの測定結果をもとに通信パケットのエラー率を監視する手段と、この監視手段からの出力に応じた出力を行なうモニター手段、を備えたことを特徴とするトラフィックモニターが開示されている。

特許文献４では、ネットワークサービス使用活動の分類に基づいて、ネットワークサービス使用活動をネットワークサービス使用制御ポリシーに関連付け、ネットワークサービス使用活動分類リストに基づいて、ネットワークサービス使用活動を様々な形で制御するシステムが開示されている。

特許文献５では、経路特性を繰り返し決定することによって複数の並列データ経路の各々を特徴付け、複数の並列データ経路が送信側ノードと受信側ノードの単一の仮想接続を定め、目的関数を達成するために複数の並列データ経路のデータ送信のスケジューリングを経路特性に基づいて決定するデータ通信方法が開示されている。

特開２０１１−８２８５８号公報 特開２００４−２６６７９５号公報 特開２００２−２３２４７５号公報 特表２０１３−５３４０８１号公報 特表２００７−５２７１７０号公報

ＶｏＩＰ装置ではインターネット網を介して音声データが受信される毎に、受信データをバッファ回路に格納する。そのため、このバッファ回路内の音声データの蓄積量をモニタすることで、ネットワーク網の品質を監視できるように考えられる。しかし、バッファ回路内の音声データの管理は、バッファ回路に音声データが新たに蓄積されるタイミングと、１つの音声データのデコードが完了したタイミング等の所定の処理に合わせて行われる。そのため、音声データの受信が途切れた場合、或いは、バッファ回路内のデータがアンダーフロー状態になった場合等には、バッファ回路等に蓄積された音声データ量のモニタが正しく行われない問題がある。

本発明にかかる音声通信装置の一態様は、公衆ネットワークを介して他の装置でパケット化された音声データを受信し、前記音声データをバッファ回路に順次蓄積する受信処理部と、前記バッファ回路に蓄積された順に音声をデコードしてアナログ音声出力信号を出力する音声デコード部と、前記バッファ回路の前記音声データの蓄積量を所定の周期で取得して所定の期間内のバッファ回路の前記音声データの蓄積状態を示すモニタ状態値を生成するバッファ量モニタ部と、前記モニタ状態値に基づき状況表示部の表示状態を切り替える受信状況モニタ部と、を有し、前記バッファ量モニタ部は、自装置内で決められた時刻情報に基づき決定されるモニタ周期で前記バッファ回路の前記音声データの蓄積量を取得する。

本発明によれば、音声データを含む様々なデータの包括的な通信状態、或いは、音声データを含む様々なデータの包括的な処理状況によらず、定常的に音声データのみの通信状態及び処理状態をモニタすることができる。

実施の形態１にかかる音声通信装置のブロック図である。 実施の形態１にかかる音声通信装置の受信状況モニタ部の結果表示の例を示す表である。 実施の形態１にかかる音声通信装置の音声再生系の処理のフローチャートである。 実施の形態１にかかる音声通信装置のリアルタイムモニタ系のリアルタイムモードでの処理のフローチャートである。 図３のフローチャートに対応したバッファ状態値の計算タイミングを説明する図である。 実施の形態１にかかる音声通信装置のリアルタイムモニタ系のアベレージモードでの処理のフローチャートである。 図６のフローチャートに対応したバッファ状態値の計算タイミングを説明する図である。

実施の形態１
以下では、図面を参照して本発明の実施の形態について説明する。まず、以下で説明する音声通信装置は、ＲＴＰ（Real-time Transport Protocol）により、インターネット網等の公衆ネットワークを介して音声データを送受信するＶｏＩＰ通話装置である。そのため、以下で説明する各種通信は、ＲＴＰの規則に従って行われる。

図１に実施の形態１にかかる音声通信装置１、２のブロック図を示す。図１に示すブロック図では、音声通信装置１、２が公衆ネットワーク（以下、ＶｏＩＰネットワークと称す）を介して互いに通信を行う状態を示した。しかし、実施の形態１にかかる音声通信装置１、２は、いずれか一方の装置が以下で説明する受信処理部ＲＸを有していれば本発明の効果を奏する。

図１に示すように、音声通信装置１、２は、それぞれが送信処理部ＴＸ及び受信処理部ＲＸを有する。図１に示す例では、音声通信装置１、２として同じ音声通信装置を利用するため、以下では音声通信装置１について説明する。

図１に示すように、送信処理部ＴＸは、音声エンコード部１１、ＤＭＡ制御部１２、演算処理部１３を有する。演算処理部１３は例えばＣＰＵ（Central Processing Unit）等の演算装置である。そして、演算処理部１３には、音声メモリ１４、ＲＴＰ送信カプセリング処理部１５が含まれる。

音声エンコード部１１は、外部から入力されるアナログ音声入力信号をデジタル値で表される音声データにエンコードする。ＤＭＡ制御部１２は、音声エンコード部１１でエンコードされた音声データを演算処理部１３にＤＭＡ（Direct Memory Access）転送する。音声メモリ１４は、ＤＭＡ制御部１２から転送された音声データを一時的に記憶する。ＲＴＰ送信カプセリング処理部１５は、音声メモリ１４に格納されている音声データをＲＴＰの規則に従ってパケット化する。そして、ＲＴＰ送信カプセリング処理部１５は、音声データを含むパケットをＲＴＰの規則に従ってＶｏＩＰネットワークを介して他の装置（例えば、音声通信装置２）に送信する。

受信処理部ＲＸは、ＲＴＰ受信デカプセリング処理部２１、音声ジッタバッファ２２、ＤＭＡ制御部２３、音声デコード部２４、音声制御部２５、バッファ量モニタ部２６、受信状況モニタ部２７、状況表示部２８を有する。

ＲＴＰ受信デカプセリング処理部２１は、ＶｏＩＰネットワークを介して、他の装置（例えば、音声通信装置２）でパケット化された音声データを受信する。そして、ＲＴＰ受信デカプセリング処理部２１は、受信したパケットから音声データを抽出する。また、ＲＴＰ受信デカプセリング処理部２１は、抽出した音声データをバッファ回路（例えば、音声ジッタバッファ２２）に順次蓄積する。また、ＲＴＰ受信デカプセリング処理部２１は、音声データを音声ジッタバッファ２２に蓄積したことに応じて、音声ジッタバッファ２２への音声データの蓄積が完了したことを音声制御部２５に通知する。

音声ジッタバッファ２２は、例えば、ＦＩＦＯ（First Input First Output）等の複数のバッファを含むメモリである。つまり、音声ジッタバッファ２２は、複数のバッファに音声データを蓄積し、蓄積された音声データのうち最も古い音声データから順に出力する。

ＤＭＡ制御部２３は、音声ジッタバッファ２２に蓄積された音声データのうち最も古い音声データから順に取り出し、音声デコード部２４に転送する。音声デコード部２４は、ＤＭＡ制御部２３から転送された音声データをデコードしてアナログ音声出力信号を生成する。また、音声デコード部２４は、デコード処理が完了したことを音声制御部２５に通知する。

音声制御部２５は、ＲＴＰ受信デカプセリング処理部２１におけるパケットの受信状況及び音声ジッタバッファ２２の音声データの蓄積状況に応じて音声デコード部２４のデコード速度を調節する。また、音声制御部２５は、ＲＴＰ受信デカプセリング処理部２１のパケット受信状況及び音声デコード部２４のデコード処理の進行状況に応じて、音声ジッタバッファ２２に蓄積されている音声データの管理を行う。具体的には、音声制御部２５は、音声ジッタバッファ２２に蓄積された音声データを参照し、音声データが送信された順序に応じて並べ替える。また、音声制御部２５は、音声ジッタバッファ２２に蓄積された音声データに遅延が大きな音声データ（例えば、既にデコードが完了してしまった音声データの間に位置すべき音声データ）があった場合、当該音声データを消去する。

バッファ量モニタ部２６は、音声ジッタバッファ２２の音声データの蓄積量を所定の周期（以下、取得周期と称す）で取得して所定の期間（以下平均値取得期間と称す）内のバッファ回路の音声データの蓄積状態を示すモニタ状態値ＢＣを生成する。また、実施の形態１にかかるバッファ量モニタ部２６は、モニタ状態値ＢＣをリアルタイムモードとアベレージモードの演算モードで算出する。リアルタイムモードの演算とアベレージモードの演算は、利用者の指示に基づき切り替えられても良く、並列して行われても良い。このモニタ状態値ＢＣは、内蔵されるメモリにログ情報として蓄積される。また、バッファ量モニタ部２６は、取得した蓄積量の履歴情報であるバッファ履歴情報を内蔵されるメモリに生成する。

また、バッファ量モニタ部２６は、ＲＴＰ受信デカプセリング処理部２１によるパケットの受信タイミングとは独立したタイミングで音声ジッタバッファ２２の音声データの蓄積量情報の取得を行う。より具体的には、ＲＴＰ受信デカプセリング処理部２１は、ＶｏＩＰネットワークからのパケット受信間隔に従って音声ジッタバッファ２２に音声ジッタバッファ２２に音声データを蓄積する。このパケット受信間隔は、パケットを送信する送信処理部ＴＸが決定するものである。一方、バッファ量モニタ部２６は、自装置内で決められた時刻情報に基づき決定されるモニタ周期で音声ジッタバッファ２２路の前記音声データの蓄積量を取得する。

受信状況モニタ部２７は、バッファ量モニタ部２６が算出したモニタ状態値ＢＣに基づき状況表示部２８の表示状態を切り替える。例えば、状況表示部２８は、ＬＥＤ等のインジケータである。そして、受信状況モニタ部２７は、点滅制御信号ＡＬ、ＡＨ、ＬＯによりインジケータの点滅速度を切り替える。そこで、実施の形態１にかかる音声通信装置の受信状況モニタ部の結果表示の例を示す表を図２に示す。

図２に示すように、実施の形態１では、バッファ状態値ＢＣの大きさに応じてインジケータの点滅速度を切り替える。具体的には、受信状況モニタ部２７は、バッファ状態値ＢＣが上限値Ｈｔｈ以上となった場合に点滅制御信号ＡＨをハイレベルとして、インジケータの点滅速度を高速（例えば、１秒当たり４回の点滅）にする。受信状況モニタ部２７は、バッファ状態値ＢＣが上限値Ｈｔｈと下限値Ｌｔｈとの間であった場合に点滅制御信号ＡＬをハイレベルとして、インジケータの点滅速度を低速（例えば、１秒当たり１回の点滅）にする。受信状況モニタ部２７は、バッファ状態値ＢＣが下限値Ｌｔｈ以下となった場合に点滅制御信号ＬＯをハイレベルとして、インジケータを消灯する。なお、上限値Ｈｔｈと下限値Ｌｔｈは、音声ジッタバッファ２２のバッファ数、音声通信装置１が置かれたネットワークの環境に応じて適宜決定されるものである。

実施の形態１にかかる音声通信装置１では、受信処理部ＲＸの動作に特徴の１つを有する。そこで、以下では、受信処理部ＲＸの動作について詳細に説明する。受信処理部ＲＸの動作は、ＲＴＰ受信デカプセリング処理部２１、音声ジッタバッファ２２、ＤＭＡ制御部２３、音声デコード部２４、音声制御部２５により音声を再生する音声再生系の動作と、バッファ量モニタ部２６、受信状況モニタ部２７、状況表示部２８によりネットワークの状態をモニタするリアルタイムモニタ系の動作に分けて考えることができる。実施の形態１にかかる受信処理部ＲＸでは、音声再生系とリアルタイムモニタ系とを独立したタイミングで動作させるためである。そこで、以下では、受信処理部ＲＸの動作を、音声再生系の動作と、に分けて説明する。

図３に実施の形態１にかかる音声通信装置の音声再生系の処理のフローチャートを示す。図３に示すように、受信処理部ＲＸでは、ＲＴＰ受信デカプセリング処理部２１が音声データを含む音声パケットを受信したことに応じて、音声ジッタバッファ２２に音声データが格納される（ステップＳ１、Ｓ２）。

続いて、ＲＴＰ受信デカプセリング処理部２１は、音声ジッタバッファ２２に音声データの格納処理が完了したことを音声制御部２５に通知したことに応じて、音声制御部２５がジッタバッファ管理処理を実行する（ステップＳ３）。このジッタバッファ管理処理では、音声データの順序の並べ替えが行われる。音声データの並べ替え処理では、音声データの送信順序に基づく並べ替えと、到達遅延が大きな音声データの廃棄が行われる。次いで、音声制御部２５は、ワンダ制御を行う（ステップＳ４）。このワンダ制御は、音声ジッタバッファ２２内の音声データ数管理であり、音声制御部２５は、音声ジッタバッファ２２の音声データの多少に基づく音声デコード部２４のデコード速度を調整する。

続いて、音声デコード部２４が音声データのデコード処理を実行し、デコード処理が完了したことに応じて、デコード処理の完了を音声制御部２５に通知する（ステップＳ５、Ｓ６）。そして、音声制御部２５は、デコード処理の完了通知を受信したことに応じて、再度ジッタバッファ管理を行う（ステップＳ７）。このステップＳ７の処理は、ステップＳ３の処理と同じである。そして、ステップＳ７の完了後、受信処理部ＲＸは、再度音声パケットの受信を待機する（ステップＳ１）。

上記ステップＳ１からステップＳ７の処理は、音声パケットの受信タイミングに基づき繰り返し実行される。そのため、音声パケットの到達遅延がない通常状態では、ステップＳ１からステップＳ７の処理は、一定の周期（例えば、１０ｍｓｅｃ程度の周期）で行われる。しかし、音声パケットの到達遅延が一定でない場合、繰り返し処理の実行周期が不安定になる。また、音声ジッタバッファ２２に蓄積されている音声データが枯渇するアンダーフロー状態となるとステップＳ５のデコード処理が滞り、ステップＳ７の処理が実行できない状態が発生する。なお、このようなアンダーフローが発生しても、音声パケットが受信されれば、アンダーフロー状態は解消される。

続いて、実施の形態１にかかる音声通信装置１のリアルタイムモニタ系の動作について説明する。実施の形態１にかかる音声通信装置１では、バッファ状態値の算出方法の違いに応じてリアルタイムモードとアベレージモードの２つの動作モードを有する。そこで以下では、リアルタイムモードとアベレージモードとの２つの動作を分けてリアルタイムモニタ系の動作について説明する。

図４に実施の形態１にかかる音声通信装置１のリアルタイムモニタ系のリアルタイムモードでの処理のフローチャートを示す。図４に示すように、リアルタイムモニタモードでは、リアルタイムモニタ系に属するバッファ量モニタ部２６が、音声ジッタバッファ２２の音声データの蓄積量を示すジッタバッファ管理情報を取得する際にローカルタイムＴｒｘ１、Ｔｒｘ２の２つの時間を利用する。このローカルタイムＴｒｘ１、Ｔｒｘ２は、自装置（例えば、音声通信装置１）内のクロック信号に基づきカウントアップされる時間である。また、バッファ量モニタ部２６では、モニタ周期の１周期の長さを規定する取得間隔ＴＡと、バッファ状態値ＢＣを算出する期間の長さを規定する平均値取得期間ＴＢと、を有する。この取得間隔ＴＡの設定値及び平均値取得期間ＴＢの設定値は、音声通信装置１の管理者が任意に設定できる値であり、音声通信装置１が設置されたネットワークの状況に応じて設定できるものである。例えば、取得間隔ＴＡは、音声パケットの通常状態における到達間隔と同じ設定値し、平均値取得間隔ＴＢは、取得間隔ＴＡの整数倍の設定値とすることが好ましい。

図４に示すように、リアルタイムモニタ系では、バッファ量モニタ部２６が取得間隔ＴＡでジッタバッファ管理情報を取得して、取得した音声ジッタバッファ２２の音声データの蓄積量をバッファ履歴情報として蓄積する（ステップＳ１１〜Ｓ１３）。また、バッファ量モニタ部２６は、平均値取得間隔ＴＢが経過するまで、ステップＳ１１〜Ｓ１３のジッタバッファ管理情報の取得を継続する（ステップＳ１４）。

そして、リアルタイムモニタ系では、ローカルタイムＴｒｘ２が平均値取得間隔ＴＢに達すると、ローカルタイムＴｒｘ２をリセットし（ステップＳ１５）、バッファ量モニタ部２６がリアルタイムモニタ統計処理を実施する（ステップＳ１６）。このステップＳ１６のリアルタイムモニタ統計処理では、平均値取得間隔ＴＢの期間中に取得された音声データの蓄積量の平均値を算出し、当該平均値をバッファ状態値ＢＣとして出力する。なお、バッファ状態値ＢＣは、ログ情報として蓄積されていても良い。

そして、リアルタイムモニタ系では、受信状況モニタ部２７がステップＳ１６で算出されたバッファ状態値ＢＣを参照してリアルタイムモニタ結果表示処理を行う（ステップＳ１７）。このステップＳ１７のリアルタイムモニタ結果表示処理では、図２の表に従った表示の切り替えが行われる。

ここで、図４に示したフローチャートに従って算出されるバッファ状態値の計算タイミングを説明する図を図５に示す。図５に示すように、図４に示したリアルタイムモードでは、取得間隔ＴＡ毎に音声ジッタバッファ２２の音声データの蓄積量が取得され、平均値取得期間ＴＢ毎に平均値取得期間ＴＢ期間中に取得された蓄積量の平均値がバッファ状態値ＢＣとして算出される。

このリアルタイムモードは、ＶｏＩＰネットワークの状態が不安定である場合に有効である。平均値取得期間ＴＢ毎にバッファ状態値ＢＣを算出することで、ＶｏＩＰネットワークの過渡状態への応答を高められるためである。

続いて、図６に実施の形態１にかかる音声通信装置のリアルタイムモニタ系のアベレージモードでの処理のフローチャートを示す。図６に示すように、アベレージモードでは、リアルタイムモニタ系に属するバッファ量モニタ部２６が、音声ジッタバッファ２２の音声データの蓄積量を示すジッタバッファ管理情報を取得する際にローカルタイムＴｒｘを利用する。このローカルタイムＴｒｘは、自装置（例えば、音声通信装置１）内のクロック信号に基づきカウントアップされる時間である。また、アベレージモードにおいても、バッファ量モニタ部２６では、モニタ周期の１周期の長さを規定する取得間隔ＴＡを有する。しかし、アベレージモードの動作では、平均値取得期間ＴＢのリアルタイムモニタ統計処理でりようされるため、図６のフローチャート中には表現されていない。

図６に示すように、アベレージモードでは、バッファ量モニタ部２６は、取得間隔ＴＡでジッタバッファ管理情報を取得してバッファ履歴情報として蓄積し、リアルタイムモニタ統計処理を行う（ステップＳ２１、Ｓ２２、Ｓ２４、Ｓ２５）。また、受信状況モニタ部２７は、取得間隔ＴＡでリアルタイムモニタ結果表示処理を行う（ステップＳ２３〜Ｓ２５）。ステップＳ２３のリアルタイムモニタ結果表示処理は、リアルタイムモードのステップＳ７（図４）の処理と同じ処理である。

一方、アベレージモードでは、ステップＳ２２のリアルタイムモニタ統計処理におけるバッファ状態値ＢＣの計算方法が異なる。そこで、アベレージモードにおけるリアルタイムモニタ統計処理について、図６のフローチャートに対応したバッファ状態値の計算タイミングを説明する図を図７に示し、図７を参照して説明する。

図７に示すように、アベレージモードでは、取得間隔ＴＡで音声ジッタバッファ２２の蓄積量の情報を取得する毎にバッファ状態値ＢＣを算出する。このとき、バッファ量モニタ部２６は、最新の蓄積量から平均値取得期間ＴＢの最古の蓄積量までの平均値をバッファ状態値ＢＣとして算出する。そして、バッファ量モニタ部２６は、新たに蓄積量を取得した場合には、タイミングｎ−１（ｎは演算タイミングを示す番号）で算出された蓄積量の積算値に最新の蓄積量を加算すると共に最古の蓄積量を減算してタイミングｎにおける蓄積量の積算値を算出する。そして、バッファ量モニタ部２６は、当該積算値を加算されている蓄積量の数で割ることでバッファ状態値ＢＣ（ｎ）を得る。なお、算出されたバッファ状態ＢＣは、ログとして記録することが好ましい。

このリアルタイムモードは、ＶｏＩＰネットワークが安定している場合、或いは、音声の途切れが一時的で利用者に音切れが認識されにくい状態を無視したい場合、に有効である。一時的な音声パケットの途切れは、時間平均値を算出した場合、演算結果に表れにくいためである。リアルタイムモードでは、取得間隔ＴＡ毎にバッファ状態値ＢＣが算出されるため、ＶｏＩＰネットワークの詳細な解析に向く。

上記説明より、実施の形態１にかかる音声通信装置１、２では、バッファ量モニタ部２６、受信状況モニタ部２７、状況表示部２８により構成されるリアルタイムモニタ系の構成を有する。これにより、実施の形態１にかかる音声通信装置１では、音声パケットの受信或いは音声データのデコード状況とは独立して音声パケットの受信状況を定常的にモニタすることができる。つまり、実施の形態１にかかる音声通信装置１、２では音声データを含む様々なデータの包括的な通信状態、或いは、音声データを含む様々なデータの包括的な処理状況によらず、定常的に音声データのみの通信状態および処理状態をモニタすることができる。

また、実施の形態１にかかる音声通信装置１、２では、リアルタイムモニタ系で算出されるバッファ状態値ＢＣに基づきインジケータの点滅速度を切り替える。これにより、実施の形態１にかかる音声通信装置１、２では、ログ情報を参照することなく、管理者が音声パケットの受信状況をリアルタイムに把握することができる。一般的に、公衆ネットワークを介した通信の状況を確認する場合、ルーター装置等のインジケータの点滅を確認するが、この確認方法では、音声パケット以外の他のパケットの受信状態に対しても反応してしまうため、音声パケットのみを対象とした確認ができない問題がある。また、ログ等の確認により音声パケットの受信状況を確認する場合は、ログの取得及びその検証に時間がかかる問題がある。

また、実施の形態１にかかる音声通信装置１では、リアルタイムモードとアベレージモードの２つの演算モードでバッファ状態値ＢＣを算出する。これにより、実施の形態１にかかる音声通信装置１では、ＶｏＩＰネットワークの状況に応じて参照するバッファ状態値を参照し、ネットワークの状況に応じた解析を行うことが可能になる。また、実施の形態１にかかる音声通信装置１は、リアタイムモードで算出されるバッファ状態値と、アベレージモードで算出されるバッファ状態値と、をログに保存することで、ネットワーク状況のより詳細な解析が可能になる。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

１、２ 音声通信装置
１１ 音声エンコード部
１２ ＤＭＡ制御部
１３ 演算処理部
１４ 音声メモリ
１５ ＲＴＰ送信カプセリング処理部
２１ ＲＴＰ受信デカプセリング処理部
２２ 音声ジッタバッファ
２３ ＤＭＡ制御部
２４ 音声デコード部
２５ 音声制御部
２６ バッファ量モニタ部
２７ 受信状況モニタ部
２８ 状況表示部
ＴＸ 送信処理部
ＲＸ 受信処理部

Claims (3)

1. 公衆ネットワークを介して他の装置でパケット化された音声データを受信し、前記音声データをバッファ回路に順次蓄積する受信処理部と、
   前記バッファ回路に蓄積された順に音声をデコードしてアナログ音声出力信号を出力する音声デコード部と、
   前記バッファ回路の前記音声データの蓄積量を所定の周期で取得して所定の期間内のバッファ回路の前記音声データの蓄積状態を示すバッファ状態値を生成するバッファ量モニタ部と、
   前記バッファ状態値に基づき状況表示部の表示状態を切り替える受信状況モニタ部と、を有し、
   前記バッファ量モニタ部は、
   自装置内で決められた時刻情報に基づき決定されるモニタ周期で前記バッファ回路の前記音声データの蓄積量を取得し、
   前記所定の期間内の間、前記モニタ周期で前記蓄積量を取得し、前記所定の期間毎に前記所定の期間内に取得された前記蓄積量の平均値を算出して前記バッファ状態値を出力するリアルタイムモードと、
   前記モニタ周期で前記蓄積量を取得し、前記蓄積量を取得する毎に最新の前記蓄積量から前記所定の期間の最古の前記蓄積量までの平均値を算出して前記バッファ状態値を出力するアベレージモードと、を外部から与えられる指示に基づき切り替え、
   前記受信状況モニタ部は、前記バッファ状態値が上限値以上となった場合に前記状況表示部のインジケータの点滅速度を高速にし、前記バッファ状態値が前記上限値と下限値との間であった場合に前記インジケータの点滅速度を低速にし、前記バッファ状態値が前記下限値以下となった場合に前記インジケータを消灯する、音声通信装置。
2. 前記受信処理部における受信状況及び前記バッファ回路の音声データの蓄積状況に応じて前記音声デコード部のデコード速度を調節する音声制御部をさらに有する請求項１に記載の音声通信装置。
3. アナログ音声入力信号から前記音声データを生成し、生成した前記音声データを前記他の装置に送信する送信処理部をさらに有する請求項１又は２記載の音声通信装置。

Images