(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-09-13
(45)【発行日】2023-09-22
(54)【発明の名称】プログラム、装置およびシステム
(51)【国際特許分類】
G10L 19/00 20130101AFI20230914BHJP
G10L 19/005 20130101ALI20230914BHJP
H04M 1/00 20060101ALI20230914BHJP
【ＦＩ】
G10L19/00 320
G10L19/005
H04M1/00 H
【請求項の数】
18
(21)【出願番号】P 2019101349
(22)【出願日】2019-05-30
(65)【公開番号】P2019211776
(43)【公開日】2019-12-12
【審査請求日】2022-05-23
(31)【優先権主張番号】10-2018-0065026
(32)【優先日】2018-06-05
(33)【優先権主張国・地域又は機関】KR
(73)【特許権者】
【識別番号】516014409
【氏名又は名称】ライン プラス コーポレーション
【氏名又は名称原語表記】ＬＩＮＥ Ｐｌｕｓ Ｃｏｒｐｏｒａｔｉｏｎ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100091214
【弁理士】
【氏名又は名称】大貫 進介
(72)【発明者】
【氏名】クァック ジョンナム
【審査官】大野 弘
(56)【参考文献】
【文献】特開平０２－０８１５３８（ＪＰ，Ａ）
【文献】特開２００４－２８９５７９（ＪＰ，Ａ）
【文献】特開２００９－１８２６４８（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ１０Ｌ １９／００
Ｇ１０Ｌ １９／００５
Ｈ０４Ｍ １／００
(57)【特許請求の範囲】
【請求項1】
コンピュータに、音声通話の相手の電子機器から、ストリームの情報に連続する音声区間に関する情報が含まれた音声ストリームをパケット単位で受信して再生する再生ステップと、
前記音声ストリームの再生過程中に音切れが発生した場合、前記連続する音声区間に関する情報を利用して前記音切れの原因を分析する分析ステップと、を実行させ、
前記音声ストリームの情報内に、前記連続する音声区間を識別するための識別子が追加されており、前記分析ステップにおいて、前記音切れ以後のパケットと以前のパケットの識別子を比べて前記音切れの原因を分析する、プログラム。
【請求項2】
前記音声ストリームは、ペイロードコーデック方式によって圧縮されている請求項１に記載のプログラム。
【請求項3】
前記再生ステップは、前記音声通話の相手の電子機器からＤＴＸ（ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｔｒａｎｓｍｉｓｓｉｏｎ）のストリーミング方式によって前記音声ストリームを受信して再生する請求項１に記載のプログラム。
【請求項4】
前記再生ステップは、前記音声通話の相手の電子機器から受信した各パケットのタイムスタンプを参照して該当の区間の音声を再生する請求項１に記載のプログラム。
【請求項5】
前記分析ステップは、前記音切れ以後のパケットと以前のパケットの識別子を比べ、識別子が異なる場合は無音区間による音切れと判断する請求項１に記載のプログラム。
【請求項6】
前記分析ステップは、前記音切れ以後のパケットと以前のパケットの識別子を比べ、識別子が同じ場合はネットワークスパイクによる音切れと判断する請求項１に記載のプログラム。
【請求項7】
前記コンピュータに、前記音切れの原因分析結果による通話品質レポートをサーバまたはユーザに提供するステップを実行させる請求項１に記載のプログラム。
【請求項8】
前記コンピュータに、前記音切れの原因分析結果を通知形態によってユーザに提供するステップを実行させる請求項１に記載のプログラム。
【請求項9】
前記コンピュータに、前記音切れの原因分析結果がネットワークスパイクによる途切れである場合、音声再生のバッファリング時間を調節するステップを実行させる請求項１に記載のプログラム。
【請求項10】
音声通話の相手の電子機器から、ストリームの情報に連続する音声区間に関する情報が含まれた音声ストリームをパケット単位で受信して再生する手段と、前記音声ストリームの再生過程中に音切れが発生した場合、前記連続する音声区間に関する情報を利用して前記音切れの原因を分析する手段を含み、
前記音声ストリームの情報内に、前記連続する音声区間を識別するための識別子が追加されており、前記分析する手段は、前記音切れ以後のパケットと以前のパケットの識別子を比べて前記音切れの原因を分析する、装置。
【請求項11】
電子機器が実現する音声通話品質モニタリングシステムであって、音声通話の相手の電子機器から、ストリームの情報に連続する音声区間に関する情報が含まれた音声ストリームをパケット単位で受信して再生する音声再生手段、および
前記音声ストリームの再生過程中に音切れが発生した場合、前記連続する音声区間に関する情報を利用して前記音切れの原因を分析することによって通話品質モニタリングを実行する品質モニタリング手段
を備え、前記音声ストリームの情報内に、前記連続する音声区間を識別するための識別子が追加されており、前記品質モニタリング手段は、前記音切れ以後のパケットと以前のパケットの識別子を比べて前記音切れの原因を分析する、音声通話品質モニタリングシステム。
【請求項12】
前記音声ストリームは、ペイロードコーデック方式によって圧縮されている、請求項１１に記載の音声通話品質モニタリングシステム。
【請求項13】
前記音声再生手段は、ＤＴＸ（ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｔｒａｎｓｍｉｓｓｉｏｎ）のストリーミング方式によって前記音声ストリームを受信して再生し、
前記音声通話の相手の電子機器から受信した各パケットのタイムスタンプを参照して該当の区間の音声を再生する、
請求項１１に記載の音声通話品質モニタリングシステム。
【請求項14】
前記品質モニタリング手段は、前記音切れ以後のパケットと以前のパケットの識別子を比べ、識別子が異なる場合は無音区間による音切れと判断する、
請求項１１に記載の音声通話品質モニタリングシステム。
【請求項15】
前記品質モニタリング手段は、前記音切れ以後のパケットと以前のパケットの識別子を比べ、識別子が同じ場合はネットワークスパイクによる音切れと判断する、
請求項１１に記載の音声通話品質モニタリングシステム。
【請求項16】
前記品質モニタリング手段は、前記音切れの原因分析結果による通話品質レポートをサーバまたはユーザに提供する、
請求項１１に記載の音声通話品質モニタリングシステム。
【請求項17】
前記品質モニタリング手段は、前記音切れの原因分析結果を通知形態によってユーザに提供する、
請求項１１に記載の音声通話品質モニタリングシステム。
【請求項18】
前記品質モニタリング手段は、前記音切れの原因分析結果がネットワークスパイクによる途切れである場合、音声再生のバッファリング時間を調節する、
請求項１１に記載の音声通話品質モニタリングシステム。
【発明の詳細な説明】
【技術分野】
【0001】
以下の説明は、音声通話の品質を管理する技術に関する。
【背景技術】
【0002】
ＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ、インターネット電話）の使用は、今や周知のこととなった。ＶｏＩＰは、基本的にユーザの音声をデジタルデータパケットにエンコードし、デジタルデータパケットをＩＰ（インターネットプロトコル）ネットワークを介して送信する。
【0003】
例えば、特許文献１（登録日２０１１年０９月２６日）には、ＩＰ基盤でＶｏＩＰインターネット電話サービスを提供する技術が開示されている。
【先行技術文献】
【特許文献】
【0004】
【文献】韓国登録特許第１０－１０６９１１６号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
音声ストリームの受信処理時にネットワークスパイクと無音区間を区別できるようにする。
【課題を解決するための手段】
【0006】
電子機器が実行する音声通話品質モニタリング方法であって、前記電子機器は、メモリに含まれるコンピュータ読み取り可能な命令を実行するように構成された少なくとも１つのプロセッサを含み、前記音声通話品質モニタリング方法は、前記少なくとも１つのプロセッサにより、音声通話の相手の電子機器から、ストリームの情報に連続する音声区間に関する情報が含まれた音声ストリームをパケット単位で受信して再生する段階、および前記少なくとも１つのプロセッサにより、前記音声ストリームの再生過程中に音切れが発生した場合、前記連続する音声区間に関する情報を利用して前記音切れの原因を分析する段階を含む、音声通話品質モニタリング方法を提供する。
【0007】
一側面によると、ペイロードコーデック方式によって圧縮された音声ストリームの情報内に、連続する音声区間を識別するための識別子を追加してよい。
【0008】
他の側面によると、前記再生する段階は、前記音声通話の相手の電子機器から間欠送信（ＤＴＸ：ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｔｒａｎｓｍｉｓｓｉｏｎ）のストリーミング方式によって前記音声ストリームを受信して再生してよい。
【0009】
また他の側面によると、前記再生する段階は、前記音声通話の相手の電子機器から受信した各パケットのタイムスタンプを参照して該当の区間の音声を再生してよい。
【0010】
また他の側面によると、前記分析する段階は、前記音切れ以後のパケットと以前のパケットの識別子を比べて前記音切れの原因を分析してよい。
【0011】
また他の側面によると、前記分析する段階は、前記音切れ以後のパケットと以前のパケットの識別子を比べた結果、識別子が異なる場合は無音区間による途切れであると判断し、識別子が同じ場合はネットワークスパイクによる途切れであると判断してよい。
【0012】
また他の側面によると、前記音声通話品質モニタリング方法は、前記少なくとも１つのプロセッサにより、前記音切れの原因分析結果による通話品質レポートをサーバまたはユーザに提供する段階をさらに含んでよい。
【0013】
また他の側面によると、前記音声通話品質モニタリング方法は、前記少なくとも１つのプロセッサにより、前記音切れの原因分析結果を通知形態によってユーザに提供する段階をさらに含んでよい。
【0014】
さらに他の側面によると、前記音声通話品質モニタリング方法は、前記少なくとも１つのプロセッサにより、前記音切れの原因分析結果がネットワークスパイクによる途切れである場合、音声再生のバッファリング時間を調節する段階をさらに含んでよい。
【0015】
また他の側面によると、前記音声通話品質モニタリング方法をコンピュータに実行させるコンピュータプログラム、および非一時的なコンピュータ読み取り可能な記録媒体が提供される。
【0016】
電子機器で実現される音声通話品質モニタリングシステムであって、メモリ、および前記メモリに通信可能に接続され、前記メモリに含まれるコンピュータ読み取り可能な命令を実行するように構成された少なくとも１つのプロセッサを含み、前記少なくとも１つのプロセッサは、音声通話の相手の電子機器から、ストリームの情報に連続する音声区間に関する情報が含まれた音声ストリームをパケット単位で受信して再生する音声再生部、および前記音声ストリームの再生過程中に音切れが発生した場合、前記連続する音声区間に関する情報を利用して前記音切れの原因を分析することによって通話品質モニタリングを実行する品質モニタリング部を備える、音声通話品質モニタリングシステムを提供する。
【発明の効果】
【0017】
本発明の実施形態によると、音声ストリームの受信処理時に発生した音切れの原因がネットワークスパイクによるものか無音区間によるものかを判断することにより、音声通話の品質を効果的にモニタリングおよび管理することができる。
【図面の簡単な説明】
【0018】
【図1】本発明の一実施形態における、ネットワーク環境の例を示した図である。
【図2】本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。
【図3】本発明の一実施形態における、無音区間による音切れを説明するための例示図である。
【図4】本発明の一実施形態における、スパイクによる音切れを説明するための例示図である。
【図5】本発明の一実施形態における、電子機器のプロセッサが含むことのできる構成要素の例を示した図である。
【図6】本発明の一実施形態における、電子機器が実行することのできる方法の例を示したフローチャートである。
【図7】本発明の一実施形態における、連続する音声区間に識別子を付与する過程を説明するための例示図である。
【図8】本発明の一実施形態における、音切れの原因を分析する過程を説明するための例示図である。
【発明を実施するための形態】
【0019】
以下、本発明の実施形態について、添付の図面を参照しながら詳細に説明する。
【0020】
本発明の実施形態は、音声通話の品質を管理する技術に関し、より詳細には、音声ストリームの受信処理時にネットワークスパイクと無音区間を区別する方法、システム、コンピュータプログラム、および非一時的なコンピュータ読み取り可能な記録媒体に関する。
【0021】
本明細書で具体的に開示される事項などを含む実施形態は、音声ストリームの受信処理時にネットワークスパイクと無音区間を区別することができ、これによってサービスの品質管理、効率性、利便性などの側面において相当な長所を達成することができる。
【0022】
図１は、本発明の一実施形態における、ネットワーク環境の例を示した図である。図１のネットワーク環境は、複数の電子機器１１０、１２０、１３０、１４０、複数のサーバ１５０、１６０、およびネットワーク１７０を含む例を示している。このような図１は、発明の説明のための一例に過ぎず、電子機器の数やサーバの数が図１のように限定されることはない。
【0023】
複数の電子機器１１０、１２０、１３０、１４０は、コンピュータ装置によって実現される固定端末や移動端末であってよい。複数の電子機器１１０、１２０、１３０、１４０の例としては、スマートフォン、携帯電話、ナビゲーション、ＰＣ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ）、ノート型ＰＣ、デジタル放送用端末、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、ＰＭＰ（Ｐｏｒｔａｂｌｅ Ｍｕｌｔｉｍｅｄｉａ Ｐｌａｙｅｒ）、タブレット、ゲームコンソール、ウェアラブルデバイス、ＩｏＴ（ｉｎｔｅｒｎｅｔ ｏｆ ｔｈｉｎｇｓ）デバイス、ＶＲ（ｖｉｒｔｕａｌ ｒｅａｌｉｔｙ）デバイス、ＡＲ（ａｕｇｍｅｎｔｅｄ ｒｅａｌｉｔｙ）デバイスなどがある。一例として、図１では、電子機器１（１１０）の例としてスマートフォンを示しているが、本発明の実施形態において、電子機器１（１１０）は、実質的に無線または有線通信方式を利用し、ネットワーク１７０を介して他の電子機器１２０、１３０、１４０および／またはサーバ１５０、１６０と通信することのできる多様な物理的なコンピュータ装置のうちの１つを意味してよい。
【0024】
通信方式が限定されることはなく、ネットワーク１７０が含むことのできる通信網（一例として、移動通信網、有線インターネット、無線インターネット、放送網、衛星網など）を利用する通信方式だけではなく、機器間の近距離無線通信が含まれてよい。例えば、ネットワーク１７０は、ＰＡＮ（ｐｅｒｓｏｎａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＬＡＮ（ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、ＣＡＮ（ｃａｍｐｕｓ ａｒｅａ ｎｅｔｗｏｒｋ）、ＭＡＮ（ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔｗｏｒｋ）、ＷＡＮ（ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、ＢＢＮ（ｂｒｏａｄｂａｎｄ ｎｅｔｗｏｒｋ）、インターネットなどのネットワークのうちの１つ以上の任意のネットワークを含んでよい。さらに、ネットワーク１７０は、バスネットワーク、スターネットワーク、リングネットワーク、メッシュネットワーク、スター－バスネットワーク、ツリーまたは階層的ネットワークなどを含むネットワークトポロジのうちの任意の１つ以上を含んでもよいが、これらに限定されることはない。
【0025】
サーバ１５０、１６０それぞれは、複数の電子機器１１０、１２０、１３０、１４０とネットワーク１７０を介して通信して命令、コード、ファイル、コンテンツ、サービスなどを提供する１つ以上のコンピュータ装置によって実現されてよい。例えば、サーバ１５０は、ネットワーク１７０を介して接続した複数の電子機器１１０、１２０、１３０、１４０に第１サービスを提供するシステムであってよく、サーバ１６０も、ネットワーク１７０を介して接続した複数の電子機器１１０、１２０、１３０、１４０に第２サービスを提供するシステムであってよい。より具体的な例として、サーバ１５０は、複数の電子機器１１０、１２０、１３０、１４０においてインストールされて実行されるコンピュータプログラムであるアプリケーションを通じ、該当のアプリケーションが目的とするサービス（一例として、ＶｏＩＰサービスなど）を第１サービスとして複数の電子機器１１０、１２０、１３０、１４０に提供してよい。他の例として、サーバ１６０は、上述したアプリケーションのインストールおよび実行のためのファイルを複数の電子機器１１０、１２０、１３０、１４０に配布するサービスを第２サービスとして提供してよい。
【0026】
図２は、本発明の一実施形態における、電子機器およびサーバの内部構成を説明するためのブロック図である。図２では、電子機器に対する例として電子機器１（１１０）の内部構成およびサーバ１５０の内部構成について説明する。また、他の電子機器１２０、１３０、１４０やサーバ１６０も、上述した電子機器１（１１１０）またはサーバ１５０と同一または類似の内部構成を有してよい。
【0027】
電子機器１（１１０）およびサーバ１５０は、メモリ２１１、２２１、プロセッサ２１２、２２２、通信モジュール２１３、２２３、および入力／出力インタフェース２１４、２２４を含んでよい。メモリ２１１、２２１は、非一時的なコンピュータ読み取り可能な記録媒体であって、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ディスクドライブ、ＳＳＤ（ｓｏｌｉｄ ｓｔａｔｅ ｄｒｉｖｅ）、フラッシュメモリ（ｆｌａｓｈ ｍｅｍｏｒｙ）などのような永続的大容量記録装置を含んでよい。ここで、ＲＯＭ、ＳＳＤ、フラッシュメモリ、ディスクドライブのような永続的大容量記録装置は、メモリ２１１、２２１とは区分される別の永続的記録装置として電子機器１（１１０）やサーバ１５０に含まれてもよい。また、メモリ２１１、２２１には、オペレーティングシステムと、少なくとも１つのプログラムコード（一例として、電子機器１（１１０）においてインストールされて実行されるブラウザや特定のサービスの提供のために電子機器１（１１０）にインストールされるアプリケーションなどのためのコード）が記録されてよい。このようなソフトウェア構成要素は、メモリ２１１、２２１とは別のコンピュータ読み取り可能な記録媒体からロードされてよい。このような別のコンピュータ読み取り可能な記録媒体は、フロッピー（登録商標）ドライブ、ディスク、テープ、ＤＶＤ／ＣＤ－ＲＯＭドライブ、メモリカードなどのコンピュータ読み取り可能な記録媒体を含んでよい。他の実施形態において、ソフトウェア構成要素は、コンピュータ読み取り可能な記録媒体ではない通信モジュール２１３、２２３を通じてメモリ２１１、２２１にロードされてもよい。例えば、少なくとも１つのプログラムは、開発者またはアプリケーションのインストールファイルを配布するファイル配布システム（一例として、上述したサーバ１６０）がネットワーク１７０を介して提供するファイルによってインストールされるコンピュータプログラム（一例として、上述したアプリケーション）に基づいてメモリ２１１、２２１にロードされてよい。
【0028】
プロセッサ２１２、２２２は、基本的な算術、ロジック、および入出力演算を実行することにより、コンピュータプログラムの命令を処理するように構成されてよい。命令は、メモリ２１１、２２１または通信モジュール２１３、２２３によって、プロセッサ２１２、２２２に提供されてよい。例えば、プロセッサ２１２、２２２は、メモリ２１１、２２１のような記録装置に記録されたプログラムコードにしたがって受信される命令を実行するように構成されてよい。
【0029】
通信モジュール２１３、２２３は、ネットワーク１７０を介して電子機器１（１１０）とサーバ１５０とが互いに通信するための機能を提供してもよいし、電子機器１（１１０）および／またはサーバ１５０が他の電子機器（一例として、電子機器２（１２０））または他のサーバ（一例として、サーバ１６０）と通信するための機能を提供してもよい。一例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１のような記録装置に記録されたプログラムコードにしたがって生成した要求が、通信モジュール２１３の制御にしたがってネットワーク１７０を介してサーバ１５０に伝達されてよい。これとは逆に、サーバ１５０のプロセッサ２２２の制御にしたがって提供される制御信号や命令、コンテンツ、ファイルなどが、通信モジュール２２３とネットワーク１７０を経て電子機器１（１１０）の通信モジュール２１３を通じて電子機器１（１１０）に受信されてよい。例えば、通信モジュール２１３を通じて受信されたサーバ１５０の制御信号や命令、コンテンツ、ファイルなどは、プロセッサ２１２やメモリ２１１に伝達されてよく、コンテンツやファイルなどは、電子機器１（１１０）がさらに含むことのできる記録媒体（上述した永続的記録装置）に記録されてよい。
【0030】
入力／出力インタフェース２１４は、入力／出力装置２１５とのインタフェースのための手段であってよい。例えば、入力装置は、キーボード、マウス、マイクロフォン、カメラなどの装置を、出力装置は、ディスプレイ、スピーカ、触覚フィードバックデバイスなどのような装置を含んでよい。他の例として、入力／出力インタフェース２１４は、タッチスクリーンのように入力と出力のための機能が１つに統合された装置とのインタフェースのための手段であってもよい。入力／出力装置２１５は、電子機器１（１１０）と１つの装置で構成されてもよい。また、サーバ１５０の入力／出力インタフェース２２４は、サーバ１５０に接続するかサーバ１５０が含むことのできる入力または出力のための装置（図示せず）とのインタフェースのための手段であってよい。より具体的な例として、電子機器１（１１０）のプロセッサ２１２がメモリ２１１にロードされたコンピュータプログラムの命令を処理するにあたり、サーバ１５０や電子機器２（１２０）が提供するデータを利用して構成されるサービス画面やコンテンツが、入力／出力インタフェース２１４を通じてディスプレイに表示されてよい。
【0031】
また、他の実施形態において、電子機器１（１１０）およびサーバ１５０は、図２の構成要素よりも多くの構成要素を含んでもよい。しかし、大部分の従来技術的構成要素を明確に図に示す必要はない。例えば、電子機器１（１１０）は、上述した入力／出力装置２１５のうちの少なくとも一部を含むように実現されてもよいし、トランシーバ、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）モジュール、カメラ、各種センサ、データベースなどのような他の構成要素をさらに含んでもよい。より具体的な例として、電子機器１（１１０）がスマートフォンである場合、一般的にスマートフォンが含んでいる加速度センサやジャイロセンサ、カメラモジュール、物理的な各種ボタン、タッチパネルを利用したボタン、入力／出力ポート、振動のための振動器などのような多様な構成要素が、電子機器１（１１０）にさらに含まれるように実現されてよい。
【0032】
音声通話のための音声ストリーミングでは、ネットワークの負荷が通話品質を決めるための重要な要素となる。２人以上のユーザが通話をするとき、パケットのサイズを減らすためにコーデックを使用するようになる。すなわち、コーデックは、音声信号によるネットワーク負荷を減らすために音声を圧縮する役割を行うのである。
【0033】
エンコーダによる圧縮によって小さくなったビットストリームは、ＲＴＰ（ｒｅａｌ－ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）のような応用レイヤのトランスポートプロトコルを利用して相手に送信されるようになる。これを受信した受信端では、ビットストリームをデコードした後、デコードされた原音を再生してユーザに聞かせるようになる。
【0034】
一方、パケットを小さくするためには、エンコーダの圧縮率が重要となる。圧縮率が高いほど小さなパケットを生成することができ、ネットワークの負荷を効果的に減らすことができる。
【0035】
圧縮の効果を極大化するためのストリーミング送信技術の一例として、ＤＴＸ（ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｔｒａｎｓｍｉｓｓｉｏｎ）を挙げることができる。ＤＴＸとは、実際の音声区間だけをエンコードして送信し、無音区間のデータは送信しないストリーミング方式である。
【0036】
受信端では、送信端のシーケンス（ｓｅｑｕｅｎｃｅ）番号を利用してパケットの遺失状況を判断し、送信端のタイムスタンプを参照して再生しなければならない時間を認知する。ＤＴＸを利用する場合、受信端は、音声区間だけでパケットを受信して再生するようになり、無音区間では受信するパケットがないため再生することができない。
【0037】
例えば、表１のようなヘッダのパケットに対し、トランスポートレイヤがＲＴＰであれば、ＤＴＸではない場合、実際の音声区間はもちろん、無音区間のパケットもすべて送信される。
【0038】
【表1】
【0039】
表１のパケットをＤＴＸで送信すれば、表２のように無音区間のパケットを除いて送信するようになる。
【0040】
【表2】
【0041】
受信端では音声ストリームを受信して適した時間に再生しなければならないが、ネットワーク状況によってはパケットの受信間隔が均一でないこともある。
【0042】
このようなネットワーク問題によってパケット間にディレイが発生するようになるが、受信端では一定量のディレイを念頭においてバッファリングを実施する。しかし、瞬間的に特定のパケットがバッファリングよりも大きなディレイ（以下、「スパイク」とする）を被るようになると、再生過程中に音切れ現象が発生するようになる。
【0043】
【0044】
図３を参照すると、無音区間（Ｓ）が含まれた音声信号３００に対し、ＤＴＸの場合は、送信端ＴＸから音声区間（１）、（２）、（３）、（４）だけが送信されて無音区間（Ｓ）は送信されない。受信端ＲＸでは各パケットのタイムスタンプ０、１００、２００、４００を参照して音声を再生するようになるが、このとき、音声区間（３）と（４）の間に、無音区間（Ｓ）による正常な音切れ現象が発生するようになる。
【0045】
図４を参照すると、連続する音声区間（１）、（２）、（３）、（４）、（５）で構成された音声信号４００に対し、送信端ＴＸから音声区間（１）、（２）、（３）、（４）、（５）が送信され、受信端ＲＸでは各パケットのタイムスタンプ０、１００、２００、３００、４００を参照して音声を再生する。しかし、音声区間（４）の送受信時に、ネットワーク問題によって受信端ＲＸでバッファリングよりも大きなディレイを被るようになれば、スパイクによる非正常な音切れ現象が発生するようになる。
【0046】
要するに、受信端ＲＸでは、正常な無音区間によって再生が途切れる場合と、ネットワークの一時的なディレイによって再生が途切れる場合が発生するようになるが、音声通話の品質を管理するためには、このような２つの音切れを区別する必要がある。受信端ＲＸで音の再生が中断された場合、この原因がスパイクによるものであるかを判断することは、音質の損傷を見分ける重要な鍵となる。
【0047】
以下では、ＤＴＸ基盤の音声ストリームを受信して再生するときにスパイクと無音区間を区別することができる方法およびシステムの具体的な実施形態について説明する。
【0048】
図５は、本発明の一実施形態における、電子機器のプロセッサが含むことのできる構成要素の例を示したブロック図であり、図６は、本発明の一実施形態における、電子機器が実行することのできる方法の例を示したフローチャートである。
【0049】
本実施形態に係る電子機器１（１１０）には、コンピュータによって実現される音声通話品質モニタリングシステムが構成されてよい。音声通話品質モニタリングシステムは、ＰＣ基盤のプログラムまたはモバイル端末専用のアプリケーションで構成されてよい。本実施形態における音声通話品質モニタリングシステムは、独立的に動作するプログラム形態で実現されても、あるいは特定のアプリケーション（例えば、メッセンジャーなど）のイン－アプリ（ｉｎ－ａｐｐ）形態で構成されて前記特定のアプリケーション上で動作するように実現されてもよい。音声通話品質モニタリングシステムは、電子機器１（１１０）上にインストールされるアプリケーション形態で実現され、サーバ１５０との連動によるインターネット電話（ＶｏＩＰ）技術に基づく音声ストリームの受信処理時の音切れの原因を把握することができる。
【0050】
例えば、電子機器１（１１０）にインストールされたアプリケーションが提供する命令に基づき、電子機器１（１１０）に実現された音声通話品質モニタリングシステムは、音声通話品質モニタリング方法を実行してよい。図６に示した音声通話品質モニタリング方法を実行するために、電子機器１（１１０）のプロセッサ２１２は、構成要素として、図５に示すように、音声送信部５１０、音声再生部５２０、および品質モニタリング部５３０を備えてよい。実施形態によっては、プロセッサ２１２の構成要素は、選択的にプロセッサ２１２に含まれても除外されてもよい。また、実施形態によっては、プロセッサ２１２の構成要素は、プロセッサ２１２の機能の表現のために分離されても併合されてもよい。
【0051】
このようなプロセッサ２１２およびプロセッサ２１２の構成要素は、図６の音声通話品質モニタリング方法が含む段階６１０～６４０を実行するように電子機器１（１１０）を制御してよい。例えば、プロセッサ２１２およびプロセッサ２１２の構成要素は、メモリ２１１が含むオペレーティングシステムのコードと少なくとも１つのプログラムのコードによる命令（ｉｎｓｔｒｕｃｔｉｏｎ）とを実行するように実現されてよい。
【0052】
ここで、プロセッサ２１２の構成要素は、電子機器１（１１０）に記録されたプログラムコードが提供する命令（一例として、電子機器１（１１０）で実行されたアプリケーションが提供する命令）にしたがってプロセッサ２１２によって実行される、プロセッサ２１２の互いに異なる機能（ｄｉｆｆｅｒｅｎｔ ｆｕｎｃｔｉｏｎｓ）の表現であってよい。例えば、電子機器１（１１０）が音声ストリームを相手の電子機器（一例として、電子機器２（１２０））に送信するように上述した命令にしたがって電子機器１（１１０）を制御するプロセッサ２１２の機能的表現として、音声送信部５１０が利用されてよい。
【0053】
段階６１０で、プロセッサ２１２は、電子機器１（１１０）の制御と関連する命令がロードされたメモリ２１１から必要な命令を読み取ってよい。この場合、前記読み取った命令は、以下で説明する段階６２０～６４０をプロセッサ２１２が実行するように制御するための命令を含んでよい。
【0054】
段階６２０で、音声送信部５１０は、電子機器１（１１０）の音声インタフェースに入力された音声信号を圧縮し、圧縮された音声ストリームをパケット単位で相手の電子機器（一例として、電子機器２（１２０））に送信するが、該当の音声ストリームの情報内で連続する音声区間に関する情報を追加で送信してよい。音声送信部５１０は、実際に音声信号が連続する区間に対し、該当の音声区間を識別するための識別子を付与してよい。ペイロードコーデック方式により、圧縮ストリームの情報内で連続する音声区間に対する識別子としてチャンクＩＤ（ｃｈｕｎｋ ｉｄ）を追加してよい。一例として、受信端で認識することのできるペイロードヘッダを定義する必要があり、例えば、ペイロード内の固定位置のＮビットをチャンクＩＤとして使用してよい。他の例として、ヘッダ定義を表示せず、ペイロードクエリの形態でヘッダをデータで伝達すればチャンクＩＤがリターンされてくるＡＰＩを提供することも可能である。
【0055】
図７に示した音声信号７００の場合、連続する音声区間に、該当の区間を識別するためのチャンクＩＤを付与してよい。連続する音声区間は、一定サイズ以上の無音区間（Ｓ）によって区別されてよく、連続する音声区間のパケットには同じ識別子を付与してよい。図７では、連続する音声区間として、パケット（１）、（２）、（３）にはチャンクＩＤとしてａが、パケット（４）、（５）にはチャンクＩＤとしてｂが、パケット（６）にはチャンクＩＤとしてｃが付与されている。すなわち、チャンクＩＤによって隣接する音声区間のパケットの連続状態が分かるようになる。
【0056】
再び図６において、段階６３０で、音声再生部５２０は、相手の電子機器から音声ストリームをパケット単位で受信してデコードした後、原音を再生してよい。音声再生部５２０は、受信端ＲＸにおいて、送信端ＴＸから受信した各パケットのタイムスタンプを参照して音声区間を再生するようになる。
【0057】
段階６４０で、品質モニタリング部５３０は、再生過程中に一定時間以上の音切れが発生した場合、該当の音声ストリームの情報内に含まれた情報として連続する音声区間に関する情報を利用して音切れの原因を分析することによって音声通話品質モニタリングを実行してよい。品質モニタリング部５３０は、受信端ＲＸでの音声再生のためのパケット受信にバッファリング時間よりも大きなディレイが発生した場合を音切れと判断し、ディレイされたパケットが受信されて再生された場合、以前パケットのチャンクＩＤと比べて音切れの原因を分析してよい。
【0058】
例えば、送信端ＴＸからＤＴＸを利用して送信された音声ストリームに対し、受信端ＲＸでのパケット受信時間が表３のようになる場合、パケット（４）以前に無音区間が存在し、これによって再生するパケットがなくて音切れが発生するようになる。
【0059】
【表3】
【0060】
しかし、本発明の一実施形態では、送信端ＴＸで連続する音声区間にチャンクＩＤを付与して音声ストリームを送信するようになるため、パケット間のチャンクＩＤを比べることにより、音声自体が途切れたものなのか、あるいはスパイクによるものなのかを区別できるようになる。
【0061】
送信端ＴＸで、図７の音声信号に対する圧縮ストリームをＤＴＸで送信した場合、表４に示すように、該当のストリームの情報内にチャンクＩＤが含まれて送信される。
【0062】
【表4】
【0063】
送信端ＴＸから送信されたパケットの受信端ＲＸでの受信時間が表５のようであるとき、パケット（４）、（５）、（６）以前に音切れが発生したと言える。
【0064】
【0065】
図８を参照すると、パケット（４）以前に無音区間が存在し、再生するパケットの不存在により音切れが発生する。品質モニタリング部５３０は、パケット（４）が受信されて該当のパケットの音声が再生されている間にパケット（４）と以前パケット（３）のチャンクＩＤを比べる。パケット（３）とパケット（４）のチャンクＩＤが異なるため（ａ≠ｂ）、パケット（４）の再生前に発生した音切れ現象は無音区間による途切れであると判断することができる。
【0066】
一方、パケット（５）の受信時にもディレイが発生して音切れが発生している。品質モニタリング部５３０は、パケット（５）以前に発生した音切れに対し、パケット（５）が受信されて再生されるときに、以前パケット（４）のチャンクＩＤと現在パケット（５）のチャンクＩＤとが比較される。パケット（４）とパケット（５）のチャンクＩＤは同じなので（ｂ＝ｂ）、パケット（５）の再生前に発生した音切れは、無音区間による正常な途切れではなく、ネットワークスパイクによる途切れであると非正常な判断することができる。
【0067】
言い換えれば、品質モニタリング部５３０は、再生過程中に音切れが発生した場合、以前パケットおよび現在パケットのチャンクＩＤを比較し、チャンクＩＤが異なる場合は無音区間による正常な途切れであり、チャンクＩＤが同じ場合はネットワークスパイクによる途切れであると区別するのである。
【0068】
品質モニタリング部５３０は、再生過程中に発生する音切れの原因を具体的に分析することができ、その分析結果を音声通話の品質管理に活用することができる。一例として、品質モニタリング部５３０は、音声通話が終わった後、該当の通話中に発生した音切れの原因分析結果による通話品質レポートをサーバ１５０または電子機器１（１１０）のユーザに提供してよい。他の例として、品質モニタリング部５３０は、音声通話中に音切れが発生した場合、該当の音切れの原因分析結果を通知形態によって電子機器１（１１０）のユーザに提供してもよい。また他の例として、品質モニタリング部５３０は、音声通話中に発生した音切れがネットワークスパイクによる途切れであると判断された場合、対策として例えば、音声再生のためのバッファリング時間を増加させる調節方式により、音切れの原因によってバッファリング時間を制御することも可能である。
【0069】
このように、本発明の実施形態によると、音声ストリームの受信処理時にネットワークスパイクと無音区間を正確に区別することにより、音声通話の品質を効果的にモニタリングおよび管理することができる。
【0070】
上述した装置は、ハードウェア構成要素、ソフトウェア構成要素、および／またはハードウェア構成要素とソフトウェア構成要素との組み合わせによって実現されてよい。例えば、実施形態で説明された装置および構成要素は、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ、マイクロコンピュータ、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサ、または命令を実行して応答することができる様々な装置のように、１つ以上の汎用コンピュータまたは特殊目的コンピュータを利用して実現されてよい。処理装置は、オペレーティングシステム（ＯＳ）およびＯＳ上で実行される１つ以上のソフトウェアアプリケーションを実行してよい。また、処理装置は、ソフトウェアの実行に応答し、データにアクセスし、データを記録、操作、処理、および生成してもよい。理解の便宜のために、１つの処理装置が使用されるとして説明される場合もあるが、当業者は、処理装置が複数個の処理要素および／または複数種類の処理要素を含んでもよいことが理解できるであろう。例えば、処理装置は、複数個のプロセッサまたは１つのプロセッサおよび１つのコントローラを含んでよい。また、並列プロセッサのような、他の処理構成も可能である。
【0071】
ソフトウェアは、コンピュータプログラム、コード、命令、またはこれらのうちの１つ以上の組み合わせを含んでもよく、思うままに動作するように処理装置を構成したり、独立的または集合的に処理装置に命令したりしてよい。ソフトウェアおよび／またはデータは、処理装置に基づいて解釈されたり、処理装置に命令またはデータを提供したりするために、いかなる種類の機械、コンポーネント、物理装置、コンピュータ記録媒体または装置に具現化されてよい。ソフトウェアは、ネットワークによって接続されたコンピュータシステム上に分散され、分散された状態で記録されても実行されてもよい。ソフトウェアおよびデータは、１つ以上のコンピュータ読み取り可能な記録媒体に記録されてよい。
【0072】
実施形態に係る方法は、多様なコンピュータ手段によって実行可能なプログラム命令の形態で実現されてコンピュータ読み取り可能な媒体に記録されてよい。ここで、媒体は、コンピュータ実行可能なプログラムを継続して記録するものであっても、実行またはダウンロードのために一時記録するものであってもよい。また、媒体は、単一または複数のハードウェアが結合した形態の多様な記録手段または格納手段であってよく、あるコンピュータシステムに直接接続する媒体に限定されることはなく、ネットワーク上に分散して存在するものであってもよい。媒体の例は、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープのような磁気媒体、ＣＤ－ＲＯＭおよびＤＶＤのような光媒体、フロプティカルディスク（ｆｌｏｐｔｉｃａｌ ｄｉｓｋ）のような光磁気媒体、およびＲＯＭ、ＲＡＭ、フラッシュメモリなどを含み、プログラム命令が記録されるように構成されたものであってよい。また、媒体の他の例として、アプリケーションを配布するアプリケーションストアやその他の多様なソフトウェアを供給または配布するサイト、サーバなどで管理する記録媒体または格納媒体が挙げられる。
【0073】
以上のように、実施形態を、限定された実施形態および図面に基づいて説明したが、当業者であれば、上述した記載から多様な修正および変形が可能であろう。例えば、説明された技術が、説明された方法とは異なる順序で実行されたり、かつ／あるいは、説明されたシステム、構造、装置、回路などの構成要素が、説明された方法とは異なる形態で結合されたりまたは組み合わされたり、他の構成要素または均等物によって対置されたり置換されたとしても、適切な結果を達成することができる。
【0074】
したがって、異なる実施形態であっても、特許請求の範囲と均等なものであれば、添付される特許請求の範囲に属する。
【符号の説明】
【0075】
２１２：プロセッサ
５１０：音声送信部
５２０：音声再生部
５３０：品質モニタリング部
５１０：音声送信部
５２０：音声再生部
５３０：品質モニタリング部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】