米国特許情報 | 欧州特許情報 | 国際公開(PCT)情報 | Google の米国特許検索
 
     特許分類
A 農業
B 衣類
C 家具
D 医学
E スポ−ツ;娯楽
F 加工処理操作
G 机上付属具
H 装飾
I 車両
J 包装;運搬
L 化学;冶金
M 繊維;紙;印刷
N 固定構造物
O 機械工学
P 武器
Q 照明
R 測定; 光学
S 写真;映画
T 計算機;電気通信
U 核技術
V 電気素子
W 発電
X 楽器;音響


  ホーム -> 計算機;電気通信 -> キヤノン株式会社

発明の名称 データ伝送装置及びその制御方法、並びに制御プログラム
発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2007−5894(P2007−5894A)
公開日 平成19年1月11日(2007.1.11)
出願番号 特願2005−180628(P2005−180628)
出願日 平成17年6月21日(2005.6.21)
代理人 【識別番号】100125254
【弁理士】
【氏名又は名称】別役 重尚
発明者 田尻 勝敏
要約 課題
ネットワーク上でのメッセージ転送に遅延が生じても、アンダーフローを防止してリアルタイム性に優れたデータ伝送を行うことができるデータ伝送装置を提供する。

解決手段
メッセージ処理部104が送信バッファ103を常に監視し、所定の閾値まで音声データが蓄積されたタイミングで、音声データを送信バッファ103から取得し、HTTPリクエストの中に埋め込んでサーバ装置へ送信する。このとき、転送時間計測部105により時間計測を開始し、サーバ装置からレスポンスを受信するまでの時間を計測する。送信データ量決定部106は、この計測時間の統計処理を実施し、HTTPメッセージの送受信にかかる時間の恒常的な変動傾向(一時的でない)を判断して、送信バッファ103の前記閾値を変更する。
特許請求の範囲
【請求項1】
ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置において、
入力装置から入力されたデータを一時的に記憶するバッファリング手段と、
前記バッファリング手段に記憶したデータを含むリクエストメッセージを作成するリクエストメッセージ作成手段と、
前記作成されたリクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信手段と、
前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測手段と、
前記転送時間計測手段で計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定手段とを備えたことを特徴とするデータ伝送装置。
【請求項2】
前記データ量決定手段は、
前記転送時間計測手段によって該メッセージ転送時間が増加していると判断された場合は前記リクエストメッセージの1つに含まれるデータ量を増加し、該メッセージ転送時間が減少傾向にあると判断された場合には前記データ量を減少させることを特徴とする請求項1に記載のデータ伝送装置。
【請求項3】
前記メッセージ転送時間の増減が一時的、または増減の幅が小さい場合は、前記データ量を変更しないことを特徴とする請求項2に記載のデータ伝送装置。
【請求項4】
前記データ量決定手段によって指定されたデータ量のデータが前記バッファリング手段に記憶された場合に次のリクエストメッセージの送信処理を行うことを特徴とする請求項1乃至3のいずれかに記載のデータ伝送装置。
【請求項5】
ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置の制御方法において、
入力された連続データを一時的にバッファリング手段に記憶する工程と、
前記バッファリング手段に記憶したデータを含むリクエストメッセージを作成するリクエストメッセージ作成工程と、
前記リクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信工程と、
前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測工程と、
前記転送時間計測工程で計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定工程とを実行することを特徴とするデータ伝送装置の制御方法。
【請求項6】
ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置の制御方法を実行するための、コンピュータで読み取り可能な制御プログラムであって、
入力された連続データを一時的にバッファリング手段に記憶するステップと、
前記バッファリング手段に記憶した連続データを含むリクエストメッセージを作成するリクエストメッセージ作成ステップと、
前記リクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信ステップと、
前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測ステップと、
前記転送時間計測ステップで計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定ステップとを有することを特徴とする制御プログラム。
発明の詳細な説明
【技術分野】
【0001】
本発明は、インターネット等のネットワークを介して音声などの連続データを伝送するデータ伝送装置及びその制御方法、並びに前記制御方法を実現するための制御プログラムに関する。
【背景技術】
【0002】
近年、IP(Internet Protocol)ネットワークを利用したライブ配信システムやビデオ会議システム等、リアルタイム性が要求されるデータの配信システムが提案されている(例えば、特許文献1参照)。
【0003】
一般に、リアルタイム(実時間)の音声通信を行う場合に、送信側は、音声通信による遅延量を小さくするため音声データを小さく区切って送信する。さらに、小さく区切った音声データを一定間隔で送信する必要がある。これは、受信側で後述するようなアンダーフローを起こさないようにするためである。受信側でアンダーフローが発生すると、再生時に音途切れやエコーなどが発生し、ユーザに不快感を与えることになる。
【0004】
HTTP(HyperText Transfer Protocol)を用いて、クライアント装置からサーバ装置へリアルタイム性の高い音声通信を実施することを考える。まず、クライアント装置は、HTTPリクエストに音声データを含めたHTTPメッセージをサーバ装置へ送信し、サーバ装置からレスポンスを受信する。このHTTPメッセージの送受信を繰り返すことにより、クライアント装置からサーバ装置へ連続した音声通信が可能になる。但し、上述したように、リアルタイム性の高い音声通信を行うためには、クライアント装置は、上記HTTPメッセージの送受信処理をなるべく小さい単位で、且つ一定間隔で実施する必要がある。
【特許文献1】特開2002−330489号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
しかしながら、上記HTTPメッセージの送受信処理において、実際のネットワーク環境では、装置もしくはネットワーク上の様々な遅延要因により、HTTPメッセージの送受信単位を小さい単位で、且つ一定間隔で実施することは困難である。
【0006】
具体的には、クライアント装置とサーバ装置間のネットワーク経路において、プロキシサーバ装置を経由する場合には、HTTPメッセージを一時蓄積することで転送処理が数百ミリ秒程度遅れたり、HTTPヘッダを書き換えてHTTPレスポンスの転送後にHTTPセッションを切断させたりすることがある。また、クライアント装置上でアンチウイルスソフトウェアが動作していると、プロキシサーバ装置使用時と同様の現象を引き起こす場合がある。その他、ネットワーク上でのパケット落ちなど、様々な原因により、HTTPメッセージの送受信処理が滞る場合がある。
【0007】
このような要因から、HTTPメッセージの送受信処理が滞り、音声を再生する側のサーバ装置ではアンダーフローが起こって再生時の音途切れやエコーが発生し、ユーザに不快感を与えるという問題があった。
【0008】
本発明は上記従来の問題点に鑑み、ネットワーク上でのメッセージ転送に遅延が生じても、アンダーフローを防止してリアルタイム性に優れたデータ伝送を行うことができるデータ伝送装置及びその制御方法、並びに制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【0009】
本発明は上記目的を達成するため、ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置において、入力装置から入力されたデータを一時的に記憶するバッファリング手段と、前記バッファリング手段に記憶したデータを含むリクエストメッセージを作成するリクエストメッセージ作成手段と、前記作成されたリクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信手段と、前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測手段と、前記転送時間計測手段で計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定手段とを備えたことを特徴とする。
【0010】
また、本発明は、ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置の制御方法において、入力された連続データを一時的にバッファリング手段に記憶する工程と、前記バッファリング手段に記憶したデータを含むリクエストメッセージを作成するリクエストメッセージ作成工程と、前記リクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信工程と、前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測工程と、前記転送時間計測工程で計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定工程とを実行することを特徴とする。
【0011】
また、本発明は、ネットワークを介して外部装置にデータをリアルタイムに伝送するデータ伝送装置の制御方法を実行するための、コンピュータで読み取り可能な制御プログラムであって、入力された連続データを一時的にバッファリング手段に記憶するステップと、前記バッファリング手段に記憶した連続データを含むリクエストメッセージを作成するリクエストメッセージ作成ステップと、前記リクエストメッセージを前記外部装置へ送信し、該外部装置から前記リクエストメッセージに対するレスポンスメッセージを受信するメッセージ送受信ステップと、前記リクエストメッセージの送信から前記レスポンスメッセージを受信するまでのメッセージ転送時間を計測する転送時間計測ステップと、前記転送時間計測ステップで計測した前記メッセージ転送時間に基づいて、前記リクエストメッセージに含まれるデータのデータ量を決定するデータ量決定ステップとを有することを特徴とする。
【発明の効果】
【0012】
本発明によれば、ネットワーク上でのメッセージ転送に遅延が生じても、リクエストメッセージおよびレスポンスメッセージの送受信時間を利用することにより、アンダーフローを防止することができ、リアルタイム性に優れた品質の良いデータ伝送を行うことが可能になる。
【発明を実施するための最良の形態】
【0013】
本発明のデータ伝送装置及びその制御方法、並びに制御プログラムの実施の形態について、図面を参照しながら説明する。
【0014】
<装置の構成>
図1は、本発明のデータ伝送装置である音声通信装置を備えた音声伝送システムの要部機能を示すブロック図である。
【0015】
この音声伝送システムは、音声入力装置100から入力された音声データをクライアント装置101からネットワーク108を介してサーバ装置200へリアルタイムに伝送するシステムである。クライアント装置101は、音声データ処理部102、送信バッファ103、メッセージ処理部104、転送時間計測部105、送信データ量決定部106、及びネットワーク処理部107等から構成されている。なお、図1に示す音声伝送システムは、通信端末装置として、クライアント装置101およびサーバ装置200からなるが、クライアント装置どうしの構成でもサーバ装置どうしの構成でもよい。
【0016】
音声データ処理部102は、音声入力装置100から音声信号を受けてA/D変換処理と音声圧縮処理を行い、送信バッファ103は、圧縮された音声データを一時的格納する。メッセージ処理部104は、送信バッファ103に蓄積された音声データを含んだHTTPリクエストメッセージを作成する。
【0017】
転送時間計測部105は、作成したHTTPリクエストを送信したときから、サーバ装置200より返信されるHTTPレスポンスを受信するまでの時間(メッセージ転送時間)を計測し、送信データ量決定部106は、前記メッセージ転送時間の統計を取って、HTTPリクエストに含める音声データ量を決定する。ネットワーク処理部107は、HTTPリクエストやHTTPレスポンスを送受信する。
【0018】
なお、音声入力装置100はクライアント装置101内に存在する場合もあるが、音声伝送システムを構成する機能ブロックとして大きな違いはないため、本実施の形態では別装置として説明する。
【0019】
一方、サーバ装置200は、ネットワーク処理部201、受信バッファ202、メッセージ処理部203、及び音声データ処理部204を有している。ネットワーク処理部201は、HTTPレスポンスやHTTPリクエストを送受信する。受信バッファ202は、
受信した音声データを蓄積し、メッセージ処理部203は、HTTPレスポンスを作成する。音声データ処理部204は、音声データを順次伸長しつつD/A変換する。
【0020】
図2は、図1に示したクライアント装置101のハード構成の一例を示すブロック図である。
【0021】
このクライアント装置101は、図1に示した音声データ処理部102及び送信バッファ103と、CPU901と、ROM902と、RAM903と、入力装置コントローラ(KBC)905と、CRTコントローラ(CRTC)906と、ディスクコントローラ(DKC)907と、ネットワークインターフェースコントローラ908とが、システムバス904を介して互いに通信可能に接続された構成となっている。
【0022】
CPU901は、ROM902或いはHD911に記憶されたソフトウェアを実行することで、システムバス904に接続された各構成部を総括的に制御する。即ち、CPU901は、所定の処理シーケンスに従った処理プログラムを、ROM902或いはHD911から読み出して実行することで、図1に示したメッセージ処理部104、転送時間計測部105、及び送信データ量決定部106に相当する各機能を実現すると共に、本実施の形態に係る動作(図3参照)を実現するための制御を行う。RAM903は、CPU901の主メモリ或いはワークエリア等として機能する。
【0023】
入力装置コントローラ(KBC)905は、入力装置であるマウス909a及びキーボード909bからの指示入力を制御し、CRTコントローラ(CRTC)906は、CRTディスプレイ(CRT)910の表示を制御する。ディスクコントローラ(DKC)907は、ハードディスク(HD)911に対するアクセス動作を制御し、ネットワークインターフェースコントローラ(NIC、図1中のネットワーク処理部107に相当)908は、ネットワーク108との接続処理を行う。
【0024】
<本実施の形態に係る動作>
次に、本実施の形態に係る動作について図3を参照して説明する。図3は、本実施の形態のクライアント装置101の動作を示すフローチャートである。
【0025】
クライアント装置101よりサーバ装置200への音声通信を開始する場合、まず、音声データ処理部102では、音声入力装置100からリアルタイムに入力された音声信号をA/D変換し、さらに音声圧縮を施してから送信バッファ103に蓄積する(ステップS11)。音声信号は連続して入力されてくるので、数ミリから数十ミリ秒程度の短期間で送信バッファ103に次々と蓄積される。
【0026】
メッセージ処理部104は、送信バッファ103を常に監視し、送信バッファ103に所定の閾値(後述する)まで音声データが蓄積されると(ステップS12)、その音声データを送信バッファ103から取得し(ステップS13)、HTTPリクエストの中に埋め込む(ステップS14)。そして、メッセージ処理部104は、転送時間計測部105を通して、ネットワーク処理部107に対して、前記音声データが埋め込まれたHTTPリクエストの送信を指示する。このとき、転送時間計測部105は、タイマーによる時間計測を開始する(ステップS15)。ネットワーク処理部107は、メッセージ処理部104から指示されたHTTPリクエストをネットワーク108を介して、サーバ装置200へ送信する。
【0027】
サーバ装置200側では、HTTPリクエストを受信すると、音声データを受信バッファ202に蓄積し、HTTPレスポンスを作成する。そして、ネットワーク108を介して、クライアント装置101に返信する。その後、受信バッファ202に蓄積された音声データは、順次伸長がなされ、さらにD/A変換が行われて音声出力装置205へ出力され、音声が再生される。
【0028】
クライアント装置101では、ネットワーク処理部107がHTTPレスポンスを受信し、転送時間計測部105を通して、メッセージ処理部104に届ける。転送時間計測部105は、HTTPレスポンスを確認すると、動作中のタイマーを停止し(ステップS16)、HTTPリクエストの送信からHTTPレスポンスの受信までにかかった時間(メッセージ転送時間)を算出して送信データ量決定部106に通知する(ステップS17)。
【0029】
送信データ量決定部106は、過去から現在までに計測されたメッセージ転送時間の統計処理を実施する。そして、今回計測したメッセージ転送時間と過去の計測時間を比較することによりHTTPリクエストの1つに含まれる送信データ量を決定する(ステップS18)。具体的には、今回計測したメッセージ転送時間が過去の計測時間より長くなっていると判断すると、メッセージ処理部104に対して、監視している送信バッファ103に蓄積する送信データの容量の閾値を大きくし、一度に転送する送信データ量を増加させる指示を出す。また、今回計測したメッセージの転送時間が過去の計測時間より短くなっていると判断すると、メッセージ処理部104に対して監視している送信バッファ103に蓄積する送信データの容量の閾値を小さくし、一度に転送する送信データ容量を減少させる指示を出す。(ステップS20)。
【0030】
送信データ量決定部106が、メッセージ転送時間が過去の計測時間より長くなっている、または短くなっていると判断する方法としては、例えば、直近の10秒間の平均計測時間がその前の10秒間の平均計測時間の2倍になっている、或いは半分になっているといったように、恒常的な変動傾向を観察する方法がある。この場合、ネットワークの一時的な遅延検出によって、短時間の間に何度も閾値を変更しないようにする。短時間に何度も閾値を変更すると、サーバ装置200で再生時の平均通信時間が揺らぎ、音途切れが発生しやすくなる。
【0031】
また、送信データ量決定部106によって決定される送信バッファ103の最初の閾値(初期値)は、実際のネットワーク構成上の遅延要因を考慮して決定することが好ましい。例えば、HTTPリクエストはプロキシサーバ装置を経由してサーバ装置200へ送るのか、またはクライアント装置101上でアンチウイルスソフトを使用しているか、などのネットワーク構成上の遅延要因を調べ、これらを使用している場合は送信バッファ103の閾値を大きく、使用していない場合は送信バッファ103の閾値を小さく設定する。この時、実際の環境により、複数の閾値を使い分けると効果的である。
【0032】
このようにして、通信するネットワーク構成に最適な初期値を送信バッファ103の閾値として使用することができる。さらに、過去からの計測時間の統計を取ることで動的に一度に音声データを送信データとして転送するデータ量を変更できるので、メッセージの送受信間隔が想定以上に時間がかかるネットワーク環境でも、最適な閾値でネットワーク通信することができる。また、音声通信を一旦終了しても、送信バッファ103の閾値を、通信対象のサーバ装置毎に保持しておき、次回の音声通信時の初期値として再利用することで、次回以降、最初から安定した音声通信が可能となる。
【0033】
クライアント装置101側でHTTPレスポンスを受信した後、メッセージ処理部104は、送信バッファ103に蓄積されている音声データが再度閾値を超えたときに、次のHTTPリクエストのために送信バッファ103から音声データを取得し、この音声データを埋め込んだHTTPデータを作成して前記した手順でサーバ装置200へ送信する。このとき、音声データが閾値を超えてもHTTPレスポンスを受信できていない場合、次のHTTPリクエストの送信処理は、HTTPレスポンスの受信まで待ち合わせることになる。
【0034】
<受信バッファのバッファ蓄積量の推移>
次に、図4(a),(b),(c)を参照して、サーバ装置200における受信バッファ202のバッファ蓄積量の推移について説明する。図4(a),(b),(c)は、サーバ装置200における受信バッファのバッファ蓄積量の推移を説明するための波形図である。
【0035】
(A)理想的な状態でのバッファ蓄積量の推移
HTTPリクエストを送信してからHTTPレスポンスを受信するまでの時間であるメッセージ転送時間が、音声データが送信バッファ103の閾値を越えるまでに必要な時間より短い場合は、サーバ装置200内における受信バッファ202のバッファ蓄積量は図4(a)に示すように推移していく。
【0036】
図4(a)の例では、音声データを含んだHTTPリクエストを受信した時刻t200において、残存しているバッファ蓄積量b200がHTTPリクエストに含まれる音声データを取得することによりバッファ蓄積量b201まで一時的に増加する。その後、次のHTTPリクエストを受信する時刻t201まで音声再生していくことで徐々にバッファ蓄積量が減少していくことを表している。なお、本実施の形態では、前提として、HTTPリクエストの受信の完了に応じてHTTPレスポンスをクライアント装置101に返信する処理が行われるものとする。そして、また次のHTTPリクエストを時刻t202で受信し、受信バッファ202に蓄積し再生する、という処理を繰り返す。
【0037】
図4(a)の例では、理想的な状態で通信していると仮定している。具体的には、サーバ装置200が、HTTPリクエストの受信の完了に応じてHTTPレスポンスをクライアント装置101に返信するため、クライアント装置101は遅滞なくHTTPレスポンスを受信することができる。このため、バッファ蓄積量の平均も一定であり、受信バッファ202に音声データがなくなるというアンダーフローを起こすことはない。
【0038】
(B)本実施の形態を適用しない場合おけるバッファ蓄積量の推移
次に、本実施の形態を適用しない場合の、サーバ装置200における受信バッファ202のバッファ蓄積量の推移について説明する。
【0039】
ネットワーク経路上にプロキシサーバ装置を使用している、或いは特定のアンチウイルスソフトを使用している場合など、ネットワーク上の遅延要因により、クライアント装置101がHTTPリクエストを一定間隔で送信できない場合における、サーバ装置200の受信バッファ202のバッファ蓄積量の推移を図4(b)に示す。
【0040】
サーバ装置200は、時刻t300の時点でHTTPレスポンスを返している。しかしながら、クライアント装置101は、ネットワーク上の遅延により時刻t301になってもHTTPレスポンスを受信することができない。このため、クライアント装置101は、当然次のHTTPリクエストを送信することはできない。
【0041】
クライアント装置101は、理想的なHTTPリクエスト受信タイミングである時刻t301においてHTTPリクエストを受信できていないため、サーバ装置200の受信バッファ202の蓄積されていた音声データ量は時刻t302の時点でゼロとなる。つまりアンダーフローが起きて、音声出力装置205では音途切れが発生してしまう。
【0042】
その後、クライアント装置101はHTTPレスポンスの受信に応じて次のHTTPリクエストを送信するが、サーバ装置200では時刻t303にHTTPリクエストを受信することになる。この時、一時的にバッファ蓄積量が回復し音声再生が開始されるが、結局次のHTTPリクエストの到着にも時間がかかってしまうので、再度バッファアンダーフローが発生し、音声出力装置205からは連続した音として聞こえない状態となる。
【0043】
(C)本実施の形態を適用した場合におけるバッファ蓄積量の推移
次に、図4(b)の例と同じ条件の下で、本実施の形態を適用した場合のサーバ装置200におけるバッファ蓄積量の推移を図4(c)に示す。
【0044】
遅延要因として、ネットワーク経路上にプロキシサーバ装置を使用している、或いは特定のアンチウイルスソフトを使用している場合で、且つクライアント装置101側において接続時の情報として前記遅延要因を知っている場合に、クライアント装置101は1つのHTTPリクエストに含める音声データ量を例えば図4(b)の2倍に設定する。
【0045】
その結果、サーバ装置200の受信バッファ202は、時刻t400において2倍の音声データが増えてバッファ蓄積量b401まで増加する。そのため、その後2倍のメッセージ間隔で次のHTTPリクエストを受信したとしても、バッファ蓄積量b400までしか減らないので、バッファアンダーフローの発生を防止することができる。
【0046】
本実施の形態では、このように予め分かっているネットワーク構成への対応だけでなく、例えばHTTPメッセージが通過するネットワーク経路が途中で変更されたり、ネットワーク負荷が急に高くなったりする場合など、恒常的なネットワーク遅延が発生する場合でも、的確に対応することができる。即ち、前述したようにメッセージ転送時間を計測し統計を取ることで、そのネットワーク遅延を検出し、HTTPメッセージと一緒に送信される音声データを大きくすることで、サーバ装置200におけるバッファアンダーフローを防止することができる。
【0047】
<本実施の形態の利点>
リアルタイム性が高い音声通信を行うために理想的には、クライアント装置101は、HTTPメッセージの送受信処理をなるべく小さい単位で、且つ一定間隔で実施することが重要である。しかしながら、クライアント装置101とサーバ装置200間のネットワーク経路において、HTTPメッセージの送受信処理が滞ることがある。その要因としては、例えばプロキシサーバ装置を経由したり、クライアント装置101上でアンチウイルスソフトが動作していたりするなど、ネットワーク構成上の遅延によるものが、まず挙げられる。その他にも、HTTPメッセージが通過するネットワーク経路が途中で変更された場合や、ネットワーク上でのパケット落ちやネットワーク負荷が急に高くなるなど、一時的なネットワーク環境による遅延が複雑に絡まりあってクライアント装置からは恒常的にネットワーク遅延が発生しているように見える場合もある。
【0048】
このような場合では、クライアント装置101とサーバ装置200間におけるHTTPメッセージの送受信(HTTPリクエストに音声データを含めたHTTPメッセージをサーバ装置へ送信しサーバ装置からレスポンスを受信する)に悪影響が生ずる。即ち、前記HTTPメッセージの送信からレスポンスを受信するまでの時間が送信データの間隔(1リクエストに含まれる音声データ量)よりも大きくなってくる。
【0049】
このような傾向においては、本実施の形態では、一度に送るデータ量を増やして送信間隔を長くするように調整する。即ち、HTTPリクエストに含める音声データ量を、その時点でのネットワーク構成/環境における恒常的なメッセージ送受信時間分以上のデータ量にする。具体的には、メッセージ処理部104が送信バッファ103を常に監視し、所定の閾値まで音声データが蓄積されたタイミングで、音声データを送信バッファ103から取得し、HTTPリクエストの中に埋め込んでサーバ装置へ送信する。このとき、転送時間計測部105により時間計測を開始し、サーバ装置からレスポンスを受信するまでの時間を計測する。送信データ量決定部106は、この計測時間の統計処理を実施し、HTTPメッセージの送受信にかかる時間の恒常的な変動傾向(一時的でない)を判断して、送信バッファ103の前記閾値を変更する。
【0050】
このような本実施の形態の構成において、例えば、HTTPリクエストをプロキシサーバ装置経由して送る、またはクライアント装置101上でアンチウイルスソフトを使用するなど、実際のネットワーク構成の遅延要因が予め分かっている場合には、前記送信バッファ103の閾値を、これらの遅延要因を考慮して決定する。これによって、通信するネットワーク構成に最適な初期値を閾値として使用することができる。さらに、予め分かっているネットワーク構成への対応だけでなく、上述したような恒常的なネットワーク遅延が発生しているようなネットワーク環境でも、過去からの計測時間の統計を取ることで動的に最適な閾値に変更することができる。
【0051】
これにより、HTTPリクエストに含める音声データ量を、使用するネットワーク環境に最適な単位に設定し、且つHTTPリクエストの送信間隔を一定にすることができるので、サーバ装置200側でバッファアンダーフローが発生することを防ぐことができ、音途切れや不快なエコーを回避することが可能になる。
【0052】
なお、本発明の目的は、実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)が記憶媒体に格納されたプログラムコードを読み出して実行することによっても達成される。
【0053】
この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施の形態の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。
【0054】
また、プログラムコードを供給するための記憶媒体としては、例えば、フロッピー(登録商標)ディスク、ハードディスク、光磁気ディスク、CD−ROM、CD−R、CD−RW、DVD−ROM、DVD−RAM、DVD−RW、DVD+RW、磁気テープ、不揮発性のメモリカード、ROM等を用いることができる。または、プログラムコードをネットワークを介してダウンロードしてもよい。
【0055】
また、コンピュータが読み出したプログラムコードを実行することにより、上記実施の形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているOS(オペレーティングシステム)等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【0056】
更に、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。
【0057】
この場合、上記プログラムは、該プログラムを記憶した記憶媒体から直接、またはインターネット、商用ネットワーク、もしくはローカルエリアネットワーク等に接続された不図示の他のコンピュータやデータベース等からダウンロードすることにより供給される。
【図面の簡単な説明】
【0058】
【図1】音声伝送システムの要部機能を示すブロック図である。
【図2】クライアント装置のハード構成の一例を示すブロック図である。
【図3】実施の形態の動作を示すフローチャートである。
【図4】受信バッファのバッファ蓄積量の推移を示す波形図である。
【符号の説明】
【0059】
100 音声入力装置
101 クライアント装置
102 音声データ処理部
103 送信バッファ
104 メッセージ処理部
105 転送時間計測部
106 送信データ量決定部
107 ネットワーク処理部
108 ネットワーク
201 サーバ装置
202 受信バッファ
205 音声出力装置
901 CPU
902 ROM




 

 


     NEWS
会社検索順位 特許の出願数の順位が発表

URL変更
平成6年
平成7年
平成8年
平成9年
平成10年
平成11年
平成12年
平成13年


 
   お問い合わせ info@patentjp.com patentjp.com   Copyright 2007-2013