JP2020088595A - 通信装置、通信方法及びプログラム - Google Patents

Abstract

【課題】ＤＴＭＦ信号の存在を容易に確認可能とする通信装置を提供する。【解決手段】通信装置は、ＲＴＰ送受信部と分析制御部を備える。ＲＴＰ送受信部は、ＲＴＰパケットを送受信する。分析制御部は、ＲＴＰパケットを伝送する通信網に品質劣化が生じているか否かを判定する。さらに、分析制御部は、通信網に品質劣化が生じていると判定した場合に、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う。【選択図】図１

Description

本発明は、通信装置、通信方法及びプログラムに関する。

ＶｏＩＰ（Voice over Internet Protocol）技術における音声通話サービスでは、非特許文献１に示されるＲＴＰ（Real time Transport Protocol）プロトコルを用いた通信が多く利用されている。その際、ＲＴＰパケットが流れる通信（ネットワーク）では、異種網間又は事業者間通信網等の通信網の境界にてゲートウェイ装置を設置し、パケット通信を実現することが多い。

ここで、通話サービスにおいて、ユーザ端末の各プッシュボタンにＤＴＭＦ（Dual-Tone Multi-Frequency）信号（非特許文献２参照）を割り当て、コールセンタ等のサービスに利用していることがある。なお、ＤＴＭＦ信号は、４種類の低群周波数（６９７Ｈｚ、７７０Ｈｚ、８５２Ｈｚ、９４１Ｈｚ）と４種類の高群周波数（１２０９Ｈｚ、１３３６Ｈｚ、１４７７Ｈｚ、１６３３Ｈｚ）から各々１つずつ周波数を選択し、加算することで生成される信号である。

コールセンタを初めとした各種サービスにおいて、ＤＴＭＦ信号は「みなし音声」として扱われる。つまり、ＤＴＭＦ信号はＲＴＰプロトコルに準拠したＲＴＰパケットとしてネットワーク上で送受信される（みなし音声ＲＴＰパケットによる通信）。

あるいは、ＤＴＭＦ信号は、ＲＦＣ（Request for Comments）４７３３（非特許文献３参照）に記載されているＤＴＭＦ信号に関わる情報（ｄｉｇｉｔ番号、信号レベル等）を所定のフィールドに格納したＲＴＰパケットの１種として送受信される場合もある。

なお、「みなし音声ＲＴＰパケットによる通信」であってもＲＦＣ４７３３による形式であっても、ＤＴＭＦ信号の信号長はＲＴＰパケットを連続して送信するパケット数に相当する。なお、「みなし音声ＲＴＰパケットによる通信」において、１つのＲＴＰパケットに、利用する音声符号化方式で符号化済の音声フレーム、あるいはＤＴＭＦ信号情報を複数同梱するような場合もある。このような場合には、ＲＴＰパケット数ではなく符号化済の音声フレームの数がＤＴＭＦ信号長に相当する。

非特許文献４には、ＲＴＰの統計情報や通信品質に関するＲＴＣＰ−ＸＲ（Real-time Transport Control Protocol - extended report）が開示されている。また、特許文献１には、ＲＴＰパケットにＤＴＭＦ信号が含まれているか否かを判定するための周波数解析手法が開示されている。

特開２０００−３２４５１９号公報

H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC3550, July 2003, ［平成３０年１０月２５日検索］、インターネット<URL：http://www.ietf.org/rfc/rfc3550.txt> ITU-T "MULTIFREQUENCY PUSH-BUTTON SIGNAL RECEPTION", Q.24, ［平成３０年１０月２５日検索］、インターネット<URL：https://www.itu.int/rec/T-REC-Q.24/en> H. Schulzrinne and T.Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC4733, December 2006,［平成３０年１０月２５日検索］、インターネット<URL：http://www.ietf.org/rfc/rfc4733.txt> T. Friedman, R. Caceres, A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC3611, November 2003, ［平成３０年１０月２５日検索］、インターネット<URL：http://www.ietf.org/rfc/rfc3611.txt>

なお、上記先行技術文献の各開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明者らによってなされたものである。

上述のように、ＲＴＰパケットにＤＴＭＦ信号が格納されることがある。その際、十分に長い信号長（ＤＴＭＦ信号長）でＤＴＭＦ信号を送信すれば、送信先装置では当該信号の存在を認識しやすい。

一方、ＤＴＭＦ信号が送受信される通信では、音声通話も行われるため、特別な理由がない限り過度に長い信号長でのＤＴＭＦ信号の送信は好ましくない。また、ＤＴＭＦ信号に関する仕様として非特許文献２に開示されたＩＴＵ−Ｔ Ｑ．２４等があり、ＤＴＭＦ信号長の下限定義値に近接した信号長で送信するような、ＤＴＭＦ信号を検出する装置側にとっては厳しい動作仕様をもつ送信装置も存在する。

しかし、ＲＴＰパケットが経由するＩＰ（Internet Protocol）通信網での輻輳・障害等によるゆらぎやパケットロス等の発生影響により、送信先装置にて所定のＤＴＭＦ信号の検出・認識が困難な状況も発生する可能性がある。

例えば、図２に示すネットワークシステム（通信システム）を考える。図２に示すネットワークには、配下にモバイル端末等に代表されるユーザ端末１０２と通信する通信網を備え、他のＩＰ通信網との接続境界に配置されるようなゲートウェイ装置１０１ａ、１０１ｂが含まれる。

図２に示すＲＴＰパケットの宛先となる送信先ゲートウェイ装置（あるいは、その先の通信装置）において、ＩＰ通信網におけるネットワークの輻輳や障害等により発生するパケットのロスや遅着等により、ＤＴＭＦ信号の検出及び認識が困難となる場合がある。そこで、ＲＴＰパケットの送信元となるゲートウェイ装置１０１ａ（あるいは、ＶｏＩＰ通信の基点となるユーザ端末１０２）において、送信制御を実行することが考えられる。つまり、ネットワークの影響による送信先装置（例えば、送信先となるゲートウェイ装置１０１ｂ）でのＤＴＭＦ信号の未検出や誤認識を軽減することを目標とした送信制御の実行が考えられる。

しかし、送信元装置からは、送信先装置又はその先のＩＰ通信網の品質や、送信先装置におけるＤＴＭＦ信号の検出状況が認識できない場合も想定され、当該送信元装置等が送信制御を行うために必要な状況を把握するのが難しいことがある。

本発明は、ＤＴＭＦ信号の存在を容易に確認可能とすることに寄与する、通信装置、通信方法及びプログラムを提供することを主たる目的とする。

本発明乃至開示の第１の視点によれば、ＲＴＰ（Real time Transport Protocol）パケットを送受信する、ＲＴＰ送受信部と、ＲＴＰパケットを伝送する通信網に品質劣化が生じているか否かを判定する、分析制御部と、を備え、前記分析制御部は、前記通信網に品質劣化が生じていると判定した場合に、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ（Dual-Tone Multi-Frequency）信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う、通信装置が提供される。

本発明乃至開示の第２の視点によれば、通信装置において、ＲＴＰ（Real time Transport Protocol）パケットを送受信するステップと、ＲＴＰパケットを伝送する通信網に品質劣化が生じているか否かを判定するステップと、前記通信網に品質劣化が生じていると判定した場合に、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ（Dual-Tone Multi-Frequency）信号の信号長が長くなるようにＲＴＰパケットに関する制御を行うステップと、を含む通信方法が提供される。

本発明乃至開示の第３の視点によれば、通信装置に搭載されたコンピュータに、ＲＴＰ（Real time Transport Protocol）パケットを送受信する処理と、ＲＴＰパケットを伝送する通信網に品質劣化が生じているか否かを判定する処理と、前記通信網に品質劣化が生じていると判定した場合に、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ（Dual-Tone Multi-Frequency）信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う処理と、を実行させるプログラムが提供される。
なお、このプログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。

本発明乃至開示の各視点によれば、ＤＴＭＦ信号の存在を容易に確認可能とすることに寄与する、通信装置、通信方法及びプログラムが、提供される。

一実施形態の概要を説明するための図である。 第１の実施形態に係る通信システムの概略構成の一例を示す図である。 第１の実施形態に係るゲートウェイ装置の処理構成の一例を示す図である。 Ｕ−Ｐｌａｎｅデータ処理部の変換動作を説明するための図である。 ＲＴＣＰパケットのＡＰＰ種別の定義を説明するための図である。 Ｕ−Ｐｌａｎｅ統計情報蓄積部に格納された情報の一例を示す図である。 第１の実施形態に係るゲートウェイ装置の動作の一例を示すフローチャートである。 第２の実施形態に係るユーザ端末の処理構成の一例を示す図である。 ゲートウェイ装置のハードウェア構成の一例を示す図である。

初めに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。さらに、本願開示に示す回路図、ブロック図、内部構成図、接続図などにおいて、明示は省略するが、入力ポート及び出力ポートが各接続線の入力端及び出力端のそれぞれに存在する。入出力インターフェイスも同様である。

一実施形態に係る通信装置１０は、ＲＴＰ（Real time Transport Protocol）送受信部１１と分析制御部１２を備える（図１参照）。ＲＴＰ送受信部１１は、ＲＴＰパケットを送受信する。分析制御部１２は、ＲＴＰパケットを伝送する通信網に品質劣化が生じているか否かを判定する。さらに、分析制御部１２は、通信網に品質劣化が生じていると判定した場合に、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ（Dual-Tone Multi-Frequency）信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う。

上記通信装置１０は、例えば、ＩＰ通信網を介して、ＤＴＭＦ信号を「みなし音声」又は「ＲＦＣ４７３３形式」のＲＴＰパケットを送受信するＶｏＩＰ通信環境に配置される。通信装置１０は、他の通信装置（例えば、下流の通信装置）におけるＤＴＭＦ信号の認識情報やネットワーク品質（例えば、パケットロス率）の分析を行い、当該品質が劣化していると判断した場合、ＲＴＰパケットに関する送信制御を行う。例えば、通信装置１０は、ＲＴＰパケットの送信元装置（上流の通信装置）に対してＲＴＰパケットを送信する際のＤＴＭＦ信号の時間長を増やすような送信制御の実施を指示する。具体的には、通信装置１０は、送信元装置に対して、ＤＴＭＦ信号が格納され、連続して送信されるＲＴＰパケットの数を増やすように指示する。あるいは、通信装置１０は、自装置の内部モジュールにおいて、ＤＴＭＦ信号の時間長を増やすような変換動作を行いＲＴＰパケットに関する送信制御を実施する。

このように、通信装置１０は、ネットワーク品質を示す統計情報や他の装置におけるＤＴＭＦ信号の認証情報に基づき、送信元装置に対して情報のフィードバックを行いＲＴＰパケットに関する適切な送信制御の実施を促す。その結果、送信元装置が出力するＤＴＭＦ信号が格納されたＲＴＰパケットを下流の通信装置に確実に伝達することができるようになる。

以下に具体的な実施の形態について、図面を参照してさらに詳しく説明する。なお、各実施形態において同一構成要素には同一の符号を付し、その説明を省略する。

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

図２は、第１の実施形態に係る通信システムの概略構成の一例を示す図である。図２を参照すると、通信システムには、２台のゲートウェイ装置１０１ａ、１０１ｂと、ユーザ端末１０２が含まれる。なお、図２は例示であってシステムの構成を限定する趣旨ではないことは勿論である。

また、図２に示す２台のゲートウェイ装置１０１ａ、１０１ｂはそれぞれ同じ機能を備え、これらを区別する特段の理由がない場合には単に「ゲートウェイ装置１０１」と表記する。

図３は、第１の実施形態に係るゲートウェイ装置１０１の処理構成の一例を示す図である。図３を参照すると、ゲートウェイ装置１０１は、呼制御部２０１と、複数のＵ−Ｐｌａｎｅ（Ｕｓｅｒ−Ｐｌａｎｅ）処理部２０２ａ〜２０２ｎと、Ｕ−Ｐｌａｎｅ統計情報記憶部２１０と、Ｕ−Ｐｌａｎｅ分析・制御部２１１と、を含んで構成される。なお、以降の説明において、Ｕ−Ｐｌａｎｅ処理部２０２ａ〜２０２ｎを区別する特段の理由がない場合には、単に「Ｕ−Ｐｌａｎｅ処理部２０２」と表記する。

Ｕ−Ｐｌａｎｅ処理部２０２は、第１のＲＴＰ送受信部２０３と、第１のＲＴＣＰ（Real-time Transport Control Protocol）送受信部２０４と、Ｕ−Ｐｌａｎｅデータ処理部２０５と、統計情報記憶部２０６と、分析・制御部２０７と、第２のＲＴＰ送受信部２０８と、第２のＲＴＣＰ送受信部２０９と、を含む。

Ｕ−Ｐｌａｎｅ処理部２０２ａ〜２０２ｎのそれぞれは、上記各部を備える。

呼制御部２０１は、上位の呼制御装置、又は、対向の通信装置との呼制御を終端する。呼制御部２０１は、当該呼制御の内容に従い、配下のＵ−Ｐｌａｎｅ処理部２０２に対し、該当する呼の通信が可能となるよう呼接続に関わる設定、制御、及びリソース管理等を行う。なお、図３は、Ｕ−Ｐｌａｎｅ処理部２０２の個数（ａ〜ｎ）分、複数の通信セッションが実施できることを想定した構成例である。

Ｕ−Ｐｌａｎｅ処理部２０２は、呼制御部２０１からの指示に従い各機能部（各処理モジュール）に対し、Ｕ−Ｐｌａｎｅ通信を行うための設定、制御を行い対象となる通信の呼のＵ−Ｐｌａｎｅ通信を実現する。

第１のＲＴＰ送受信部２０３は、ＲＴＰパケットを送受信する。具体的には、第１のＲＴＰ送受信部２０３は、ＩＰ回線網から届く対象呼のＲＴＰパケットの送受信を行う。第１のＲＴＰ送受信部２０３は、受信ＲＴＰパケットに含まれるＵ−Ｐｌａｎｅデータ（ユーザデータ）をＵ−Ｐｌａｎｅデータ処理部２０５へ出力する。

逆方向に関し、第１のＲＴＰ送受信部２０３は、Ｕ−Ｐｌａｎｅデータ処理部２０５から取得するパケットデータ情報を基にＲＴＰパケットを構成し、当該構成したＲＴＰパケットをＩＰ回線の先の通信装置に向けて送信する。

第１のＲＴＰ送受信部２０３は、受信したＲＴＰパケットから通信網（ＩＰ回線網）の品質を示す統計情報を算出する。例えば、第１のＲＴＰ送受信部２０３は、上記統計情報として、パケットロス率やジッタ値等を算出する。第１のＲＴＰ送受信部２０３は、当該算出した統計情報をＵ−Ｐｌａｎｅ統計情報記憶部２１０に格納する。

さらに、第１のＲＴＰ送受信部２０３は、第１のＲＴＣＰ送受信部２０４からの要求に応じて統計情報を算出する。算出された統計情報は、第１のＲＴＣＰ送受信部２０４に出力される（第１のＲＴＰ送受信部２０３は要求に応答する）。

また、第１のＲＴＰ送受信部２０３は、第１のＲＴＣＰ送受信部２０４から取得する情報であって、対向装置から送信されてくるＲＴＣＰパケット内に含まれるＲＴＰ統計情報（パケットロス率やジッタ値等）を使用してＲＴＰ送受信制御（自装置のＲＴＰ送受信制御）を行う。

第１のＲＴＣＰ送受信部２０４は、対象通信呼のＲＴＣＰパケットの送受信を行う。第１のＲＴＣＰ送受信部２０４は、受信ＲＴＣＰパケットに含まれる各種統計情報を第１のＲＴＰ送受信部２０３に引き渡す。第１のＲＴＣＰ送受信部２０４は、受信ＲＴＣＰパケットに含まれる制御情報を分析・制御部２０７へ出力する。

第１のＲＴＣＰ送受信部２０４は、定期的に第１のＲＴＰ送受信部２０３からＲＴＰに関する統計情報を取得し、当該情報に基づきＲＴＣＰパケットを構築して送信する。第１のＲＴＣＰ送受信部２０４は、第１のＲＴＰ送受信部２０３、又は、分析・制御部２０７からの情報又は指示を契機にしてＲＴＣＰパケットを構築し、ＩＰ回線網にＲＴＣＰパケットを送信することもある。

Ｕ−Ｐｌａｎｅデータ処理部２０５は、受信したＲＴＰパケットに含まれるＵ−Ｐｌａｎｅデータに対して所定の変換処理を行う。具体的には、Ｕ−Ｐｌａｎｅデータ処理部２０５は、Ｕ−Ｐｌａｎｅデータに対して、呼制御部２０１からの設定・制御内容、又は、分析・制御部２０７からの指示内容にＵ−Ｐｌａｎｅデータを変換する。変換されたデータは、第２のＲＴＰ送受信部２０８に出力される。

また、Ｕ−Ｐｌａｎｅデータ処理部２０５は、取得したＵ−Ｐｌａｎｅデータを解析する。具体的には、Ｕ−Ｐｌａｎｅデータ処理部２０５は、Ｕ−ＰｌａｎｅデータがＤＴＭＦ信号か否かの分析を行う。つまり、Ｕ−Ｐｌａｎｅデータ処理部２０５は、受信したＲＴＰパケットにＤＴＭＦ信号が格納されていたか否かの判定、分析を行う。

さらに、Ｕ−Ｐｌａｎｅデータ処理部２０５は、Ｕ−ＰｌａｎｅデータがＤＴＭＦ信号と判定した際には、当該情報（Ｕ−ＰｌａｎｅデータはＤＴＭＦ信号）を統計情報記憶部２０６に格納する。つまり、Ｕ−Ｐｌａｎｅデータ処理部２０５は、ＤＴＭＦ信号を検出した事実（ＤＴＭＦ信号の検出履歴）を統計情報記憶部２０６に格納する。

Ｕ−Ｐｌａｎｅデータ処理部２０５は、第２のＲＴＰ送受信部２０８から取得するＵ−Ｐｌａｎｅデータに対しても同様に、呼制御部２０１、又は、分析・制御部２０７からの指示内容に従いＵ−Ｐｌａｎｅデータに所定の変換処理を行う。その後、Ｕ−Ｐｌａｎｅデータ処理部２０５は、第１のＲＴＰ送受信部２０３へＵ−Ｐｌａｎｅデータを出力したり、該当方向のＵ−ＰｌａｎｅデータについてＤＴＭＦ信号か否かの分析、ＤＴＭＦ信号と判定した際の情報格納処理を行う。

統計情報記憶部２０６は、各処理部（第１のＲＴＰ送受信部２０３、第１のＲＴＣＰ送受信部２０４、Ｕ−Ｐｌａｎｅデータ処理部２０５、第２のＲＴＰ送受信部２０８、第２のＲＴＣＰ送受信部２０９）から入力される情報（統計情報、ＤＴＭＦ信号に関する情報；ＤＴＭＦ検出履歴）を蓄積する。統計情報記憶部２０６は、分析・制御部２０７からの要求に応じて、当該情報を出力する。

分析・制御部２０７は、各種情報を分析し、Ｕ−Ｐｌａｎｅ処理部２０２の各部を制御する。具体的には、分析・制御部２０７は、ＲＴＰパケットを伝送する通信網に品質劣化が生じているか否かを判定する。さらに、分析・制御部２０７は、通信網に品質劣化が生じていると判定した場合に、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う。

分析・制御部２０７は、統計情報記憶部２０６から取り出した統計情報やＤＴＭＦ信号に関する情報を基に分析を行う。分析・制御部２０７は、当該分析結果に基づいて、ＲＴＰパケットの送信元へ情報の通知（情報のフィードバック）が必要か否かを判断する。

分析の結果、送信元へのフィードバックが必要と判断した場合には、分析・制御部２０７は、第１のＲＴＣＰ送受信部２０４、又は、第２のＲＴＣＰ送受信部２０９に制御情報を出力する。具体的には、分析・制御部２０７は、ＤＴＭＦ信号が所定の周波数の組み合わせによる「みなし音声」として格納されている場合、他の通信装置（送信元装置）に対して、ＲＴＰパケットに格納されるＤＴＭＦ信号の信号長が長くなるように指示する。

あるいは、分析の結果、自装置でＤＴＭＦ信号に関するＵ−Ｐｌａｎｅデータの変換が必要と判断した場合には、分析・制御部２０７は、Ｕ−Ｐｌａｎｅデータ処理部２０５へ変換指示を出力する。具体的には、分析・制御部は、ＤＴＭＦ信号がＲＦＣ４７３３の形式によりＲＴＰパケットに格納されている場合、Ｕ−Ｐｌａｎｅデータ処理部２０５に対してＤＴＭＦ信号の信号長が長くなるようにＵ−Ｐｌａｎｅデータを変換するように指示する。

第２のＲＴＰ送受信部２０８及び第２のＲＴＣＰ送受信部２０９のそれぞれは、第１のＲＴＰ送受信部２０３及び第１のＲＴＣＰ送受信部２０４と同様の機能を備える。第２のＲＴＰ送受信部２０８及び第２のＲＴＣＰ送受信部２０９の説明に関し、第１のＲＴＰ送受信部２０３を第２のＲＴＰ送受信部２０８に、第１のＲＴＣＰ送受信部２０４を第２のＲＴＣＰ送受信部２０９に、ＩＰ回線網を他方のＩＰ回線網にそれぞれ読み替えれば良い。

Ｕ−Ｐｌａｎｅ統計情報記憶部２１０は、呼制御部２０１から取得する呼情報（ＩＰアドレスやＵＤＰ（User Datagram Protocol）ポート番号など）、Ｕ−Ｐｌａｎｅ処理部２０２ａ〜２０２ｎそれぞれからのＲＴＰ統計情報、ＤＴＭＦ信号の検出・認識履歴等を蓄積する。Ｕ−Ｐｌａｎｅ統計情報記憶部２１０は、Ｕ−Ｐｌａｎｅ分析・制御部２１１からの要求に応じて、上記蓄積されている情報を出力する。

Ｕ−Ｐｌａｎｅ分析・制御部２１１は、Ｕ−Ｐｌａｎｅ統計情報記憶部２１０から取り出した情報を基に分析を行う。具体的には、Ｕ−Ｐｌａｎｅ分析・制御部２１１は、送信元へ情報の通知（情報のフィードバック）が必要と判断した場合には、Ｕ−Ｐｌａｎｅ処理部２０２ａ〜２０２ｎのうち少なくとも１つに制御指示を出力する。

［動作の説明］
続いて、図３を参照しつつ第１の実施形態に係るゲートウェイ装置の動作を説明する。なお、図２のゲートウェイ装置１０１ａをＲＴＰパケットの送信元、ゲートウェイ装置１０１ｂを送信先として説明する。

［送信先装置（ＲＴＰパケットの受信装置）としての動作］
ゲートウェイ装置１０１ｂの呼制御部２０１は、上位の呼制御装置、又は、対向する通信装置とのやりとりによって決定した呼情報（ＩＰアドレス、ＵＤＰポート番号、使用する音声符号化方式やＲＴＰペイロードタイプ値等）によるＲＴＰ通信が可能となるようにＵ−Ｐｌａｎｅ処理部２０２に呼設定・指示を行う。

Ｕ−Ｐｌａｎｅ処理部２０２は、呼制御部２０１からの呼設定・指示により、内包する各機能部（第１のＲＴＰ送受信部２０３等）を制御することで所望のＲＴＰ通信を実現する。ＲＴＰ通信について、一方のＩＰ通信網から届くＲＴＰパケットは、第１のＲＴＰ送受信部２０３で受信される。

第１のＲＴＰ送受信部２０３は、受信ＲＴＰパケット内のＵ−Ｐｌａｎｅデータを抽出し、ＲＴＰヘッダ情報（例えば、非特許文献１に記載のＲＴＰのシーケンス番号やタイムスタンプ等）を付随情報として、Ｕ−Ｐｌａｎｅデータと共にＵ−Ｐｌａｎｅデータ処理部２０５に引き渡す。

Ｕ−Ｐｌａｎｅデータ処理部２０５は、呼設定内容に従いＵ−Ｐｌａｎｅデータと付随情報に対して所定の処理を行い、その結果を第２のＲＴＰ送受信部２０８へ出力する。第２のＲＴＰ送受信部２０８は、再び、Ｕ−ＰｌａｎｅデータをＲＴＰパケット化して他方の通信網へ出力する。

なお、上述のＵ−Ｐｌａｎｅデータ処理部２０５による所定の処理とは、例えば、入出力が同一の音声符号化方式の場合にはＵ−Ｐｌａｎｅデータを加工せず転送する透過転送が該当する。あるいは、入出力が異なる音声符号化方式の場合にはＵ−Ｐｌａｎｅデータを復号して別の音声符号化方式で符号化するような変換処理が、上記所定の処理に該当する。

また、ＲＦＣ４７３３形式のＲＴＰパケットを受信した際には、Ｕ−Ｐｌａｎｅデータ処理部２０５は、受信側ＩＰ通信網と送信側ＩＰ通信網でＲＴＰヘッダ情報（例えばペイロードタイプ値、シーケンス番号、タイムスタンプ値等）を付け替える等、付随情報の書き換えを行ったりもする。

上記説明した一連の流れに従い、一方のＩＰ通信網から届くＲＴＰパケット内のＵ−Ｐｌａｎｅデータは他方のＩＰ通信網に出力される。その際、（送信先装置の立場の観点として）第１のＲＴＰ送受信部２０３、Ｕ−Ｐｌａｎｅデータ処理部２０５、第２のＲＴＰ送受信２０８、第２のＲＴＣＰ送受信部２０９の各部はそれぞれ以下の動作も行う。

＜第１のＲＴＰ送受信部２０３＞
第１のＲＴＰ送受信部２０３は、受信ＲＴＰパケットに関する統計情報（例えば、ジッタ値、パケットロス率等）を算出する。また、第１のＲＴＰ送受信部２０３は、第１のＲＴＣＰ送受信部２０４からの要求に対し、上記算出した統計情報を応答する。その際、第１のＲＴＰ送受信部２０３は、当該統計情報を統計情報記憶部２０６、Ｕ−Ｐｌａｎｅ統計情報記憶部２１０に格納する。

＜Ｕ−Ｐｌａｎｅデータ処理部２０５＞
Ｕ−Ｐｌａｎｅデータ処理部２０５は、受信ＲＴＰパケットのＲＴＰヘッダ情報と、Ｕ−Ｐｌａｎｅデータを解析し、当該Ｕ−ＰｌａｎｅデータにＤＴＭＦ信号が含まれているか否かを判定する。

例えば、Ｕ−Ｐｌａｎｅデータ処理部２０５は、ＲＴＰヘッダ情報のペイロードタイプを確認し、対応するＲＴＰパケットがみなし音声パケットかＲＦＣ４７３３形式のＲＴＰパケットかを判定する。

ＲＴＰパケットが音声パケットであると判定された場合、Ｕ−Ｐｌａｎｅデータ処理部２０５は、当該パケットがＤＴＭＦ信号を含む「みなし音声ＲＴＰパケット」か否かを判定する。具体的には、Ｕ−Ｐｌａｎｅデータ処理部２０５は、Ｕ−Ｐｌａｎｅデータを所定の（対応する）音声符号化方式で復号した後に周波数成分解析を行うことで、上記ＤＴＭＦ信号が受信ＲＴＰパケットに含まれるか否かを判定する。周波数成分解析の手法としては、例えば、高速フーリエ変換や特許文献１等にも記載されているＧｏｅｒｔｚｅｌアルゴリズムを利用した方法を採用できる。但し、上記解析方法はこれらに限定されない。

ＤＴＭＦ信号が含まれると判定した際には、Ｕ−Ｐｌａｎｅデータ処理部２０５は、ＤＴＭＦ信号の情報（例えば、検出したｄｉｇｉｔ番号、信号長、信号レベルや雑音レベル、検出時刻等）を統計情報記憶部２０６に格納する。

＜第２のＲＴＣＰ送受信部２０９＞
第２のＲＴＣＰ送受信部２０９は、他方のＩＰ通信網から届くＲＴＣＰパケットに含まれるＲＴＰ統計情報（ジッタ値、パケットロス数）を抽出し、当該ＲＴＰ統計情報をＵ−Ｐｌａｎｅ統計情報記憶部２１０に格納する。

＜統計情報記憶部２０６＞
統計情報記憶部２０６は、呼単位に各種統計情報を蓄積する。例えば、統計情報記憶部２０６は、各処理部から収集した下記のような統計情報を蓄積する。
・第１のＲＴＰ送受信部２０３から入力されるＲＴＰ統計情報（例えば、ジッタ値、パケットロス率）。
・Ｕ−Ｐｌａｎｅデータ処理部２０５から入力されるＤＴＭＦ信号情報（例えば、検出したｄｉｇｉｔ番号、信号長、信号レベルや雑音レベル、検出時刻等）。
・第２のＲＴＣＰ送受信部２０９から入力される（ゲートウェイ装置１０１ｂから見た場合の）ＲＴＰパケットの送信先から受信したＲＴＣＰパケットに含まれるＲＴＰ統計情報（例えば、ジッタ値、パケットロス率）。

＜分析・制御部２０７＞
分析・制御部２０７は、統計情報記憶部２０６から取り出した各種統計情報を基に、（送信先装置の立場として）以下の少なくとも１つの分析／指示／動作を行う。

動作ａ１：
分析・制御部２０７は、下記のケース１〜３のうち少なくとも１つが該当した場合に、下記に示す（ａ１−１）又は（ａ１−２）の指示を行う。より具体的には、分析・制御部２０７は、ＲＴＰパケットを受信した際に算出されたＲＴＰ統計情報、あるいは、自装置を基準として送信先である他方のＩＰ通信網から届くＲＴＣＰパケットに含まれるＲＴＰ統計情報を分析した結果、下記のケース１〜３のいずれかに該当するか確認する。

ケース１：
ジッタ値、又は、パケットロス率が予め設定した指標（閾値）に比べて高い場合。分析・制御部２０７は、通信品質が悪化した場合に下記の指示（ａ１−１）又は（ａ１−２）を行う。つまり、分析・制御部２０７は、自装置又は他の通信装置により算出された統計情報に基づいて通信網の品質劣化を判定し、下記の２つの指示のうちいずれかを行う。

ケース２：
自装置で検出・認識した直近Ｎ（Ｎは正の整数、以下同じ）回のＤＴＭＦ信号の検出履歴と、自装置を基準として送信先である他方のＩＰ通信網から届くＲＴＣＰパケットに含まれるＤＴＭＦ信号の検出履歴（送信先が後述の動作ａ２をした場合）と、を比較し両者の差分が予め設定した不一致数（閾値）を超過した場合。分析・制御部２０７は、自装置で検出したＤＴＭＦ信号の検出回数と、送信先が検出したＤＴＭＦ信号の検出回数と、の差が予め定めた回数を超えている場合、下記の指示（ａ１−１）又は（ａ１−２）を行う。このように、分析・制御部２０７は、自装置で検出したＤＴＭＦ信号の検出履歴と他の通信装置が検出したＤＴＭＦ信号の検出履歴に基づき、通信網の品質劣化を判定する。分析・制御部２０７は、判定の結果に基づき、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う。

ケース３：
自装置で検出・認識した際のＤＴＭＦ信号長の信号長が、非特許文献２に記載の基準値に非常に近接した信号として観測された場合。つまり、分析・制御部２０７は、自装置で検出したＤＴＭＦ信号とＤＴＭＦ信号に関する規格値（非特許文献２に記載の基準値）に基づき、通信網の品質劣化を判定する。分析・制御部２０７は、分析結果に基づき、下記の２つの指示のうちいずれかを行う。

分析・制御部２０７は、分析結果が上記ケース１〜３のいずれかに該当する場合、下記の指示（ａ１−１）又は（ａ１−２）を行う。

指示ａ１−１：
ＤＴＭＦ信号が「みなし音声」としてＲＴＰパケットに格納されている場合、分析・制御部２０７は、第１のＲＴＣＰ送受信部２０４に指示をする。具体的には、分析・制御部２０７は、ＤＴＭＦ信号長を長くしたい旨の要求、又は、具体的に長くしたい信号長情報が送信元装置（例えば、ゲートウェイ装置１０１ａ）に伝わるように第１のＲＴＣＰ送受信部２０４に指示をする。

指示を受けた第１のＲＴＣＰ送受信部２０４は、ＲＴＣＰパケットのＡＰＰ形式に上記情報（ＤＴＭＦ信号長を長くする旨の要求、具体的なＤＴＭＦ信号長）を格納して送信元装置に向けてＲＴＣＰパケットを送信する。なお、上記要求又は具体的なＤＴＭＦ信号長の情報に加え、当該要求の有効時間もＲＴＣＰパケットで送信されてもよい。

使用するＲＴＣＰパケットのパケット形式は、例えば、アプリケーション側で定義可能なＡＰＰ種別（非特許文献１参照）を利用してＲＴＣＰパケットを送信することが想定される。但し、当該形式に限定されず、例えば、検出したＤＴＭＦ信号に関わる情報についてＲＴＣＰ−ＸＲ（非特許文献４参照）の１種別として新規定義し送信元に伝達されてもよい。

指示ａ１−２：
分析・制御部２０７は、ＤＴＭＦ信号がＲＦＣ４７３３形式のＲＴＰパケットで送受信されている場合、ＤＴＭＦ信号長が長くなるようにＵ−Ｐｌａｎｅデータを変換するようにＵ−Ｐｌａｎｅデータ処理部２０５に指示する。

指示を受けたＵ−Ｐｌａｎｅデータ処理部２０５は、ＲＦＣ４７３３形式のＲＴＰパケットから抽出されたＵ−Ｐｌａｎｅデータと付随情報を扱う際、上記指示に従った動作を行う。具体的には、Ｕ−Ｐｌａｎｅデータ処理部２０５は、ＤＴＭＦ信号長が長くなるように、連続して受信するＲＦＣ４７３３形式のＲＴＰパケットから抽出したＵ−Ｐｌａｎｅデータと付随情報を付け替える変換処理を行う。

変換されたＵ−Ｐｌａｎｅデータと付随情報は、第２のＲＴＰ送受信部２０８に出力される。第２のＲＴＰ送受信部２０８は、取得したＵ−Ｐｌａｎｅデータと付随情報に従ってＵ−ＰｌａｎｅデータをＲＴＰパケット化し他方のＩＰ通信網に送信する。なお、上記変換処理は通信品質の悪化が解消した時点で停止してもよいし、呼切断されるまで継続してもよい。

なお、上記の指示（ａ１−１）、（ａ１−２）の選択について、上位の呼制御装置、又は対向の通信装置とのやりとりによって決定した呼情報に沿って選択してもよく、あるいは、送信先装置の設定ファイル等による設定としてもよい。例えば、ＤＴＭＦ信号がＲＦＣ４７３３の形式によりＲＴＰパケットに格納されている場合であっても、分析・制御部２０７は、送信元装置にＤＴＭＦ信号の信号長を長くように指示してもよい。

動作ａ２：
分析・制御部２０７は、直近Ｎ回のＤＴＭＦ信号の検出履歴を送信元装置（例えば、ゲートウェイ装置１０１ａ）にＲＴＣＰパケットで伝達するよう、第１のＲＴＣＰ送受信部２０４に検出履歴を提供しつつ、当該指示を行う。指示を受けた第１のＲＴＣＰ送受信部２０４は、上記指示（ａ１−１）と同様に、ＲＴＣＰパケットのＡＰＰ形式に上記情報（ＤＴＭＦ信号の検出履歴）を格納し、送信元装置に向けてＲＴＣＰパケットを送信する。

続いて、指示（ａ１−２）の変換処理について、図面を参照しつつ説明する。

図４は、Ｕ−Ｐｌａｎｅデータ処理部２０５の変換動作を説明するための図である。図４（ａ）は、ゲートウェイ装置から出力する通常時（無変換動作時）のＲＴＰパケットの一例を示す図である。図４（ｂ）は、ゲートウェイ装置から出力する変換動作時のＲＴＰパケットの一例を示す図である。

図４では、ＲＴＰヘッダ情報やＲＦＣ４７３３の情報を示す。なお、図４において、ＲＴＰヘッダのシーケンス番号（図ではＳＮ（Sequence Number）と表記）やタイムスタンプ値（図ではＴＳ（Time Stamp）と表記）は時系列に従って変動する情報であるが、説明の便宜上、具体的な数値を使って表記している。ジッタ値等、これらの値を図４の開示に限定する趣旨ではないことは勿論である。

図４の各列が１つのＲＴＰパケットに含まれる情報を示し、各列に記載の値は、使用音声符号化方式について、サンプリング周期は８ＫＨｚ、ＲＴＰパケット化周期は２０ｍｓと仮定した表記例である。

図４（ａ）では、列＃１〜＃２、列＃１０〜＃１２が音声ＲＴＰパケットである（ペイロードタイプが１００）。列＃３〜＃９はＲＦＣ４７３３形式のＲＴＰパケット、即ち、ＤＴＭＦ信号部分に相当するＲＴＰパケットである（ペイロードタイプが１０１）。

また、ＤＴＭＦ信号長は列＃３〜＃７の４つ分（４つ分＝２０ｍｓ×４＝８０ｍｓ相当で、列＃８、＃９は非特許文献３による再送パケットとして表記している；エンドビットが１）となる。

上述のように、図４（ｂ）は、指示（ａ１−２）の変換処理を実施した場合のＲＴＰパケットの送信例を示す。図４（ｂ）では、列＃１〜＃２、＃１２が音声ＲＴＰパケットで、ＤＴＭＦ信号部分は列＃３〜＃１１である。図４（ｂ）において、ＤＴＭＦ信号長は列＃３〜＃９の６つとしている。

図４に示すように、列＃１０、＃１１の音声ＲＴＰパケットに代えて、ＲＦＣ４７３３形式のＲＴＰパケットを列＃１０、＃１１で送信することでＤＴＭＦ信号長が長くなる。なお、図４（ａ）に示す列＃１０、列＃１１の音声ＲＴＰパケットは、図４（ａ）から図４（ｂ）のような変換処理と、ＤＴＭＦ検出処理の分析結果あるいは変換処理以前に受信したＲＦ４７３３パケットに含まれるＤＴＭＦ信号のｄｉｇｉｔ番号や信号レベルの情報等を用いて、図４（ｂ）に示す列＃１０、列＃１１のＲＦＣ４７３３形式のＲＴＰパケットに差し替えられる。図４の例では、ＤＴＭＦ信号の伝送時間（Duration）が、８０ｍｓ（２０ｍ×４パケット）から１２０ｍｓ（２０×６パケット）に長くなっている。このように、Ｕ−Ｐｌａｎｅデータ処理部２０５は、ＤＴＭＦ信号の伝送時間が長くなるように、ＲＴＰパケットを差し替える。

Ｕ−Ｐｌａｎｅデータ処理部２０５は、変換対象のＤＴＭＦ信号を含むＲＴＰパケットに続く音声ＲＴＰパケットのペイロードタイプをＲＦＣ４７３３形式のペイロードタイプに書き換えて、ＤＴＭＦ信号長を長くする。なお、Ｕ−Ｐｌａｎｅデータ処理部２０５は、上記ペイロードタイプに加え、シーケンス番号、タイムスタンプ値、エンドビット等も書き換える。

続いて、ＲＴＣＰパケットのＡＰＰ種別の定義例について非特許文献１、４及び図５を参照しつつ説明する。図５には、複数の情報を１つのＲＴＣＰパケットのＡＰＰ種別に格納した例が示されている。

図５の範囲Ａの部分（非特許文献１のＡＰＰのデータ形式の“application−dependent data”の部分）に、載せる情報ごとに識別ＩＤ（Identification）を定義する。当該ＩＤに続く領域（ＤＡＴＡ_１、ＤＡＴＡ_２・・・）の部分に各種情報が格納される。

例えば、ＤＡＴＡ_１には要求情報又は送信元に要望する具体的なＤＴＭＦ信号長値が格納される。ＤＡＴＡ_２にはＤＡＴＡ_１の情報の有効期限が格納される。ＤＡＴＡ_３には前述の有効期限の起点となる時刻情報が格納される。ＤＡＴＡ_４には直近で検出したＤＴＭＦ信号の直近Ｎ回の検出履歴が格納される。

なお、図５は複数の情報を載せた例だが、フィールドのビット割当も含め、図５のフィールド定義に限定するわけではなく、別の定義であってもよい。

Ｕ−Ｐｌａｎｅ統計情報記憶部２１０は、呼制御部２０１からの呼情報や、複数のＵ−Ｐｌａｎｅ処理部２０２から出力される呼単位のＲＴＰ統計情報を、取り纏めて蓄積や更新する。

Ｕ−Ｐｌａｎｅ統計情報記憶部２１０による情報管理の一例を図６に示す。図６には、左から順に管理ＩＤ、対象ＩＰ通信網（２つのＩＰ通信網をＡ、Ｂと表記）、通信相手の情報、呼種別、統計値１、統計値２、自装置のＤＴＭＦ検出・認識履歴等を図示している。なお、第１の実施形態では、各ゲートウェイ装置１０１は入力と出力のＩＰ通信網と接続されているため、枝番で入力側を「０１」、出力側を「０２」として区別している。

図６では１行あたり、２つの統計値の列を設けている。統計値１には自装置で受信したＲＴＰ統計値としてパケットロス率を格納し、統計値２には（自装置から見て送信先となる）対向装置から届いたＲＴＣＰパケットに含まれるＲＴＰ統計情報としてパケットロス率を格納する想定である。

Ｕ−Ｐｌａｎｅ分析・制御部２１１は、通信呼に関してグループ分けを行い、グループごとに通信品質の分析を行う。さらに、Ｕ−Ｐｌａｎｅ分析・制御部２１１は、通信品質が劣化したと判定されたグループに属するＲＴＰパケットに格納されて送受信されるＤＴＭＦ信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う。即ち、Ｕ−Ｐｌａｎｅ分析・制御部２１１は、対向装置をグループ化し、グループ内で品質的問題が検出された場合、グループ内のセッションにおいて同様の品質的問題が発生したものと判定し、ＤＴＭＦ信号の検出が容易に検出可能となるように制御する。

Ｕ−Ｐｌａｎｅ分析・制御部２１１は、Ｕ−Ｐｌａｎｅ統計情報記憶部２１０から取り出した統計情報を基に、（送信先装置の立場として）以下の２つの動作のうち少なくとも１つの分析・判定動作を行う。

動作ｂ１：
Ｕ−Ｐｌａｎｅ分析・制御部２１１は、通信呼に関してグループ化し、グループ毎の品質状況の分析を行う。分析の結果に応じて、Ｕ−Ｐｌａｎｅ分析・制御部２１１は、下記の（ｂ１−１）又は（ｂ１−２）の動作を行う。

なお、上記グループ化は、例えば、ＩＰアドレスごとや呼種別ごと、提供サービスごと等のグループ化などが相当し、接続関係によって外部から与えられるものとする。

一例を説明する。Ｕ−Ｐｌａｎｅ分析・制御部２１１は、ＩＰ通信網内の呼接続に使用されている対向ＩＰアドレスについて、ネットワークアドレス毎にグループ分けする。図６の例では、ＩＰ通信網Ａ側について、管理ＩＤの２０２Ａ−０１、２０２Ｂ−１、２０２Ｄ−０１が同じグループに分類され、２０２Ｃ−０１と２０２Ｅ−０１が同じグループに分類される。

Ｕ−Ｐｌａｎｅ分析・制御部２１１は、グループ分けの後、個々のグループに属する通信呼のＲＴＰ統計情報について分析する。具体的には、Ｕ−Ｐｌａｎｅ分析・制御部２１１は、指標値に対して予め設定した基準を超える呼が規定数を上回った場合（閾値を超過した場合）、該当ネットワークアドレスグループに関して「品質悪化発生」と判定する。

分析の結果、「品質悪化発生」と判定されると、Ｕ−Ｐｌａｎｅ分析・制御部２１１は以下の２つの動作のいずれかを行う。

動作（ｂ１−１）：
Ｕ−Ｐｌａｎｅ分析・制御部２１１は、ＤＴＭＦ信号の信号長を長くしたい旨の要求、又は、具体的に長くしたい信号長値を送信元装置にＲＴＣＰパケットで伝達するよう、該当グループに属する呼の制御を行っているＵ−Ｐｌａｎｅ処理部２０２に対して指示を行う。指示を受けたＵ−Ｐｌａｎｅ処理部２０２は、該当グループに属する呼に対して、指示（ａ１−１）にて説明した第１のＲＴＣＰ送受信部２０４と同様の動作を行う。

動作（ｂ１−２）：
ＤＴＭＦ信号がＲＦＣ４７３３形式のＲＴＰで通信されている場合、Ｕ−Ｐｌａｎｅ分析・制御部２１１は、ＤＴＭＦ信号長が長くなるような変換を行うよう該当グループに属する呼の制御を行っているＵ−Ｐｌａｎｅ処理部２０２に対して指示を行う。指示を受けたＵ−Ｐｌａｎｅ処理部２０２は、該当グループに属する呼に対して、指示（ａ１−２）にて説明したＵ−Ｐｌａｎｅデータ処理部２０５及び第２のＲＴＰ送受信部２０８と同様の動作を行う。

送信先としてのゲートウェイ装置１０１の動作をまとめると図７に示すフローチャートのとおりとなる。

ゲートウェイ装置１０１は、ＲＴＰパケットにＤＴＭＦ信号が含まれるか否かを判定する（ステップＳ０１）。

ＲＴＰパケットにＤＴＭＦ信号が含まれない場合（ステップＳ０１、Ｎｏ分岐）には、ゲートウェイ装置１０１はステップＳ０１の処理を繰り返す。

ＲＴＰパケットにＤＴＭＦ信号が含まれる場合（ステップＳ０１、Ｙｅｓ分岐）には、ゲートウェイ装置１０１は、統計情報又はＤＴＭＦ検出履歴を分析し、ＩＰ通信網に品質劣化が生じているか否かを判定する（ステップＳ０２）。

品質劣化が生じていなければ（ステップＳ０２、Ｎｏ分岐）、ゲートウェイ装置１０１は、処理を終了する。

品質劣化が生じていれば（ステップＳ０２、Ｙｅｓ分岐）、ゲートウェイ装置１０１は、ＤＴＭＦ信号がＲＴＰパケットに格納されている形式（タイプ）を判定する（ステップＳ０３）。

格納タイプが「みなし音声」である場合には、ゲートウェイ装置１０１は、他の通信装置に対してＤＴＭＦ信号の信号長を長くするように指示する（ステップＳ０４）。

格納タイプが「ＲＦＣ４７３３形式」である場合には、ゲートウェイ装置１０１は、自装置の内部モジュールにおいて、ＤＴＭＦ信号の信号長が長くなるようにＲＴＰパケットの変換を行う（ステップＳ０５）。

［送信元装置（ＲＴＰパケットの送信装置）としての動作］
続いて、上述の送信先装置の動作内容に対して異なる箇所に関し、送信元装置としての動作を説明する。

上述のように、送信元装置としてゲートウェイ装置１０１ａ、送信先装置としてゲートウェイ装置１０１ｂを考える。

送信元装置（ゲートウェイ装置１０１ａ）が、送信先装置（ゲートウェイ装置１０１ｂ）から、第２のＲＴＣＰ送受信部２０９においてＲＴＣＰパケットを受信したとする。この時、受信ＲＴＣＰパケットの中に、ＤＴＭＦ信号の信号長を長くしたい旨を示す要求情報、又は、具体的に長くしたい信号長値が含まれていた場合、第２のＲＴＣＰ送受信部２０９は、分析・制御部２０７にその情報を出力する。

分析・制御部２０７は、以下の２つの動作のうちいずれかの判断・指示を行う。なお、いずれの動作を選択するかは送信元装置の上位の呼制御装置、又は、対向の通信装置とのやりとりによって決定した呼情報に従って選択可能とする。但し、予め送信元についてＤＴＭＦ信号の伸長制御や送信制御の対応／非対応が判明している場合は、送信先装置の設定ファイル等で選択可能な仕組みとしてもよい。

動作ｃ１：
ＤＴＭＦ信号の生成点が自装置から見た送信元である場合（例えば、図２ではゲートウェイ装置１０１ａから見た送信元はユーザ端末）、又は、自装置ではＤＴＭＦ信号の信号長の変更が困難な場合、分析・制御部２０７は、上述の動作（ａ１−１）と同様の動作を行う。

動作ｃ２：
ＤＴＭＦ信号の生成点が自装置である場合、分析・制御部２０７は、上述の（ａ１−２）と同様にＤＴＭＦ信号の信号長が長くなるようにＲＴＰパケットが生成されるように指示を行う。具体的には、「みなし音声」としてＲＴＰパケットに格納するＤＴＦＭ信号の伝送時間が長くなるように音声データを生成し、ＲＴＰパケットに格納するようにＲＴＰパケット生成手段（例えば、後述する音声入力部５０２）に指示がなされる。

以上のように、第１の実施形態に係るゲートウェイ装置１０１は、ＩＰ通信網の輻輳、障害等に伴うパケットロス発生状況を観測・集計し、ＤＴＭＦ信号検出状況も考慮して分析を行う。その後、ゲートウェイ装置１０１は、送信元となる通信装置へＤＴＭＦ信号に関しての送信制御要望等をフィードバックする。送信元装置（あるいはＤＴＭＦ信号の発生点である更にその先の送信元装置）は、当該要望に基づき、ＤＴＭＦ時間長を伸長する等の送信制御を行う。その結果、ＤＴＭＦ信号情報をＲＴＰパケットで送受信する通信において、通信網の品質劣化（例えばジッタ値やパケットロス率の上昇）による送信先装置でのＤＴＭＦ信号の未検出、検出に伴うＤＴＭＦ信号によるサービス品質劣化の軽減（回避）が実現される。

また、第１の実施形態では、未だ通信品質に問題ない通信呼に対して、これから先、通信品質劣化が起こりえる可能性に備えてＤＴＭＦ信号の未検出を軽減、又は回避できる可能性も期待できる。第１の実施形態では、送信相手（自装置から見た送信元／送信先装置）をグループ毎（例えば、ＩＰネットワークアドレス毎にグループ化）に分析し、当該グループに属する複数の通信呼の品質悪有無も確認して制御するためである。第１の実施形態では、ある通信呼に関する通信品質の劣化を検出した時点で、同じＩＰネットワークアドレスに属する別の通信呼に対しても送信元に対してＤＴＭＦ信号の送信制御を促し、グループ全体に生じうるＤＴＭＦ信号に関する問題を事前に回避する。

［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。

本願開示は、ゲートウェイ装置間への適用だけでなく、例えば、図２において、送信元装置をユーザ端末１０２、送信先装置をゲートウェイ装置１０１ａとし、その間の制御方法に適用してもよい。第２の実施形態では、上記構成、動作を説明する。

送信先装置のゲートウェイ装置１０１の構成、動作等は第１の実施形態で説明した送信先装置と同様とする。

図８は、第２の実施形態に係るユーザ端末１０２の処理構成の一例を示す図である。図８を参照すると、ユーザ端末１０２は、第２の呼制御部５０１と、音声入力部５０２と、第２のＵ−Ｐｌａｎｅデータ処理部５０３と、第３のＲＴＰ送受信部５０４と、第３のＲＴＣＰ送受信部５０５と、音声出力部５０６と、画面制御部５０７と、制御部５０８と、を備える。

第２の呼制御部５０１は、対向の通信装置との呼制御を終端し、その呼制御内容に沿って、配下の各部（音声入力部５０２〜制御部５０８）に対して、通信可能となるよう呼情報の設定、制御を行う。

音声入力部５０２は、ユーザの音声を取得し、Ｕ−Ｐｌａｎｅデータとして第２のＵ−Ｐｌａｎｅデータ処理部５０３に出力する。

なお、通信中にユーザがプッシュボタンを押下した際、第２の呼制御部５０１の呼情報でＤＴＭＦ信号を「みなし音声」で伝えるような通信を採用することができる。この場合、音声入力部５０２は、予めプッシュボタン毎に割当てられたＤＴＭＦ信号を生成し、「みなし音声」として第２のＵ−Ｐｌａｎｅデータ処理部５０３にＵ−Ｐｌａｎｅデータを出力する。

第２の呼制御部５０１の指示でＤＴＭＦ信号をＲＦＣ４７３３形式で伝達するような通信の場合には、音声入力部５０２は、取得したＵ−Ｐｌａｎｅデータの他に、予めボタン毎に割当てられたＤＴＭＦ信号の情報も付随情報として併せて第２のＵ−Ｐｌａｎｅデータ処理部５０３に出力する。

なお、ＤＴＭＦ信号の情報とは、ｄｉｇｉｔ番号、信号レベル、時間長等、最終的に第３のＲＴＰ送受信部５０４でＲＦＣ４７３３のＲＴＰパケットを構築の基礎にできる情報である。なお、音声入力部５０２は、ＤＴＭＦ信号を送信した場合には、「ＤＴＭＦ信号送信履歴」としては制御部５０８に出力する。

また、音声入力部５０２は、制御部５０８からの指示があった場合は後述する動作を実施する。

第２のＵ−Ｐｌａｎｅデータ処理部５０３は、第２の呼制御部５０１から入力された呼情報に沿って、音声入力部５０２から入力されたＵ−Ｐｌａｎｅデータを所定の音声符号化方式で符号化する。符号化されたＵ−Ｐｌａｎｅデータは、第３のＲＴＰ送受信部５０４に出力される。また、Ｕ−Ｐｌａｎｅデータと併せて付随情報が存在する場合には、第２のＵ−Ｐｌａｎｅデータ処理部５０３は、当該付随情報も第３のＲＴＰ送受信部５０４へ出力する。

また、反対方向の動作として、第３のＲＴＰ送受信部５０４から入力される、符号化されたＵ−Ｐｌａｎｅデータに対して、第２のＵ−Ｐｌａｎｅデータ処理部５０３は、当該符号化されたＵ−Ｐｌａｎｅデータを復号し、得られるＵ−Ｐｌａｎｅデータを音声出力部５０６へ出力する。第３のＲＴＰ送受信部５０４からの入力に付随情報が存在する場合には、当該付随情報も音声出力部５０６へ出力される。

第３のＲＴＰ送受信部５０４は、第２のＵ−Ｐｌａｎｅデータ処理部５０３から入力される符号化されたＵ−ＰｌａｎｅデータをＲＴＰパケット化し、対向通信相手に向けて送信する。また、対向通信相手から受信するＲＴＰパケットに関し、ジッタバッファ制御やパケット解析の結果により得られるＵ−Ｐｌａｎｅデータは第２のＵ−Ｐｌａｎｅデータ処理部５０３へ出力される。

第３のＲＴＰ送受信部５０４は、ＲＴＰパケット送受信に関わる統計情報を算出し、第３のＲＴＣＰ送受信部５０５からの要求に対する応答として出力する。第３のＲＴＰ送受信部５０４は、第３のＲＴＣＰ送受信部５０５から入力される、対向の通信相手から届くＲＴＣＰパケット内に含まれるＲＴＰ統計情報（例えばパケットロス率やジッタ値等）を活用して、ＲＴＰ送受信制御を行う。

第３のＲＴＣＰ送受信部５０５は、ＩＰ通信網から届くＲＴＣＰパケットに含まれる各種統計情報を第３のＲＴＰ送受信部５０４に、制御情報を制御部５０８にそれぞれ出力する。第３のＲＴＣＰ送受信部５０５は、定期的にＲＴＣＰパケットを送信する他、制御部５０８からの情報・指示を起点にＲＴＣＰパケットを構成し、ＩＰ通信網にＲＴＣＰパケットを送信する。

音声出力部５０６は、第２のＵ−Ｐｌａｎｅデータ処理部５０３から入力されるＵ−Ｐｌａｎｅデータを使用ユーザに音声として出力（再生）する。あるいは、音声出力部５０６は、付随情報が存在する場合、当該情報をＲＦＣ４７３３（ＤＴＭＦ信号）に関する情報として参照し、指定のＤＴＭＦ信号を生成・再生する。音声出力部５０６は、制御部５０８からの指示に沿って、所定の制御動作を行う。

画面制御部５０７は、第２の呼制御部５０１からの指示に従って、通信の開始／終了の表示、あるいは制御部５０８や音声入力部５０２からの指示に沿って、所定の画面表示を行う。

［動作の説明］
次に、第２の実施形態に係るシステムの動作について説明する。

送信先装置の動作は第１の実施形態の内容と同様であり、送信元装置の動作として説明する。ユーザ端末１０２について、第２の呼制御部５０１は、対向の通信装置とのやりとりによって決定した呼情報（ＩＰアドレスやＵＤＰポート番号、使用する音声符号化方式やＲＴＰペイロードタイプ値等）で、ＲＴＰ通信可能となるよう、内包する各処理モジュールに通信開始／終了のための設定、制御を行う。

呼接続完了後のＲＴＰ送信動作について、音声入力部５０２は、マイク等の集音部を介してユーザの音声を取得し、Ｕ−Ｐｌａｎｅデータとして第２のＵ−Ｐｌａｎｅデータ処理部５０３に出力する。

なお、ユーザがプッシュボタンを押下した際、第２の呼制御部５０１からの設定を参照し、ＤＴＭＦ信号を「みなし音声」で伝える呼の場合は、音声入力部５０２は、予めプッシュボタン毎に割当てられたＤＴＭＦ信号情報でＤＴＭＦ信号を作成し、Ｕ−ＰｌａｎｅデータとしてＤＴＭＦ信号情報と併せて第２のＵ−Ｐｌａｎｅデータ処理部５０３に出力する。

一方、ＤＴＭＦ信号をＲＦＣ４７３３形式で伝える呼の場合には、音声入力部５０２は、無音に相当するＵ−Ｐｌａｎｅデータと、ＤＴＭＦ信号情報を付随情報として、第２のＵ−Ｐｌａｎｅデータ処理部５０３に出力する。

なお、ＤＴＭＦ信号情報とは、押下したプッシュボタンに対応するｄｉｇｉｔ番号、信号レベル、信号時間長等の情報とし、最終的に第３のＲＴＰ送受信部５０４にてＲＦＣ４７３３形式のＲＴＰパケットの作成の際に利用できる情報とする。

ＤＴＭＦ信号を発信しない出力タイミングの際には、音声入力部５０２は、付属情報は例えば空とするなど、後続の処理部でＤＴＭＦ発信時／非発信時の区別ができるようにする。

第２のＵ−Ｐｌａｎｅデータ処理部５０３は、音声入力部５０２から入力されたＵ−Ｐｌａｎｅデータと付随情報に対して、Ｕ−Ｐｌａｎｅデータを所定の音声符号化方式に沿って符号化し、符号化されたＵ−Ｐｌａｎｅデータと付随情報を第３のＲＴＰ送受信部５０４に出力する。

第３のＲＴＰ送受信部５０４は、以下の２つの動作のうちいずれかを行いＩＰ通信網にＲＴＰパケットを出力する。

（１）付随情報が空の場合、第３のＲＴＰ送受信部５０４は、符号化されたＵ−ＰｌａｎｅデータをＲＴＰ化する。
（２）付随情報がある場合、第３のＲＴＰ送受信部５０４は、当該付随情報を基にＲＦＣ４７３３形式でＲＴＰパケット化する。

また、ＲＴＣＰパケットの送信動作について、第３のＲＴＣＰ送受信部５０５は、第３のＲＴＰ送受信部５０４から一定周期でＲＴＰ統計情報を取得し、当該情報を基にＲＴＣＰパケットを構築し、ＩＰ通信網に出力する。

呼接続完了後のＲＴＰ受信動作について、第３のＲＴＰ送受信部５０４で受信したＲＴＰパケットは、ジッタバッファ制御やパケット解析の結果、符号化されたＵ−Ｐｌａｎｅデータ、又は、ＲＦＣ４７３３に含まれたＤＴＭＦ信号情報を付随情報として、第２のＵ−Ｐｌａｎｅデータ処理部５０３へ出力される。

第２のＵ−Ｐｌａｎｅデータ処理部５０３では、第３のＲＴＰ送受信部５０４から入力されるデータが、符号化されたＵ−Ｐｌａｎｅデータであれば復号し、得られるＵ−Ｐｌａｎｅデータを音声出力部５０６へ出力する。その際、付随情報が含まれていれば、第２のＵ−Ｐｌａｎｅデータ処理部５０３は、当該情報も含めて音声出力部５０６に出力する。

音声出力部５０６は、第２のＵ−Ｐｌａｎｅデータ処理部５０３からのＵ−Ｐｌａｎｅデータを再生する、又は、付随情報が存在すれば、当該付随情報も参考にし、ＤＴＭＦ信号のＵ−Ｐｌａｎｅデータを生成し、再生する。

第３のＲＴＣＰ送受信部５０５で受信したＲＴＣＰパケットはパケット解析され、得られた統計情報・制御情報は第３のＲＴＰ送受信部５０４に出力される。当該これらの情報は、ＲＴＰパケットの送受信制御に活用される。

上記の説明は、通常のＲＴＰ／ＲＴＣＰパケットの通信の動作例だが、第２の実施形態の特徴部分について以下説明する。

第３のＲＴＣＰ送受信部５０５は、対向装置から受信するＲＴＣＰパケットを解析した際に、受信ＲＴＣＰパケットの中に、第１の実施形態で挙げた、ＤＴＭＦ信号の信号長を長くしたい旨を示す要求情報、又は、具体的に長くしたい信号長の値、あるいは、ＤＴＭＦ信号の検出履歴等が含まれていた場合、制御部５０８にその情報を出力する。

制御部５０８は、上記情報に応じて以下の２つの動作のうちいずれかの指示・動作を行う。

動作ｄ１：
ＤＴＭＦ信号長を長くしたい旨を示す情報が含まれていた場合、又は、具体的に長くしたい信号長の値が含まれていた場合、制御部５０８は、同じ趣旨の情報を音声入力部５０２に指示する。

指示を受けた音声入力部５０２は、上記要求に対応可能な場合、指示の受信以降、ユーザがプッシュボタンを押下した際に生成するＤＴＭＦ信号の信号長をあらかじめ定めた一定の割合に長くした値、又は、指示された値に従ってＤＴＭＦ信号を生成し、Ｕ−Ｐｌａｎｅデータとして、第２のＵ−Ｐｌａｎｅデータ処理部５０３に出力する。なお、有効期限や有効期限の起点となる時刻情報も含まれていた場合、制御部５０８はこれらの情報も併せて音声入力部５０２に情報を出力する。

動作ｄ２：
ＤＴＭＦ信号の検出履歴が含まれていた場合、制御部５０８は、蓄積した直近Ｎ回の送信履歴と照合する。なお、ユーザ端末１０２からＤＴＭＦ信号に該当する「みなし音声」、又は、ＲＦＣ４７３３形式のＲＴＰパケットを送信したばかりで送信先装置で検出していない可能性も考慮して、直前に送信したＤＴＭＦ信号の送信履歴は照合対象から除外してもよい。

照合の結果、双方の履歴に不一致箇所が予め定めた数以上確認された場合、制御部５０８は、音声入力部５０２にＤＴＭＦ信号の信号長を長くする指示をする。

指示を受けた音声入力部５０２は、以降、ユーザがプッシュボタンを押下した際に生成するＤＴＭＦ信号の信号長を予め定めた一定の割合に長くした値でＤＴＭＦ信号を生成し、Ｕ−Ｐｌａｎｅデータとして、第２のＵ−Ｐｌａｎｅデータ処理部５０３に出力する。

なお、有効期限や有効期限の起点となる時刻情報も含まれる場合、音声入力部５０２は、当該情報に従って一定時間経過後に通常時のＤＴＭＦ信号長で生成する処理に戻っても良いし、呼切断されるまで継続しても良い。

制御部５０８について、検出履歴と送信履歴の照合結果やＤＴＭＦ信号長を長くする一連の動作を行う際に、音声出力部５０６へ指示してアラーム音を再生させる、あるいは、画面制御部５０７へ指示し、対向装置の検出状況の進捗表示や安定した通信エリアへの移動を促すような表示をしても良い。

［ハードウェア構成］
続いて、システムに含まれる各装置のハードウェア構成について説明する。

図９は、ゲートウェイ装置１０１のハードウェア構成の一例を示す図である。ゲートウェイ装置１０１は、図９に例示する構成を備える。例えば、ゲートウェイ装置１０１は、内部バスにより相互に接続される、ＣＰＵ（Central Processing Unit）３０１、メモリ３０２、通信手段であるＮＩＣ（Network Interface Card）３０３等を備える。

但し、図９に示す構成は、ゲートウェイ装置１０１のハードウェア構成を限定する趣旨ではない。ゲートウェイ装置１０１は、図示しないハードウェアを含んでもよい。ゲートウェイ装置１０１に含まれるＣＰＵ等の数も図９の例示に限定する趣旨ではなく、例えば、複数のＣＰＵ３０１がゲートウェイ装置１０１に含まれていてもよい。

メモリ３０２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、補助記憶装置（ハードディスク等）等である。

ゲートウェイ装置１０１の機能は、上述の処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ３０２に格納されたプログラムをＣＰＵ３０１が実行することで実現される。また、そのプログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。即ち、上記処理モジュールが行う機能は、何らかのハードウェア、或いはハードウェアを利用して実行されるソフトウェアにより実現できればよい。

なお、ユーザ端末１０２の基本的なハードウェア構成はゲートウェイ装置１０１と同一とすることができ、且つ、当業者にとって明らかであるため詳細な説明を省略する。

［変形例］
なお、上記実施形態にて説明した通信システムの構成、動作等は例示であってシステム等の構成、動作を限定する趣旨ではない。例えば、上記実施形態では、ＲＦＣ４７３３の形式のＲＴＰパケットのＤＴＭＦ信号の信号長を長くする際、音声ＲＴＰパケットをＤＴＭＦ信号が格納されたＲＴＰパケットに変換（差し替え）している。このような変換ではなく、ＤＴＭＦ信号の信号長が長くなるように新たなＲＦＣ４７３３形式のＲＴＰパケットが挿入（追加）されてもよい。例えば、図４を参照すると、図４（ａ）の列＃９と列１０の間に、図４（ｂ）の列＃１０、列＃１１のＲＦＣ４７３３形式のＲＴＰパケットが挿入されてもよい。なお、この場合であっても、ＤＴＭＦ信号の信号長を長くした結果の整合性を確保するための変換（例えば、図４（ａ）の列＃７〜＃９の変換）は必要となる。

また、上述の説明で用いたフローチャートでは、複数の工程（処理）が順番に記載されているが、各実施形態で実行される工程の実行順序は、その記載の順番に制限されない。各実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。また、上述の各実施形態は、内容が相反しない範囲で組み合わせることができる。

上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、ＤＴＭＦ信号をＲＴＰパケットで送信するようなモバイル端末、あるいは、主に他のＩＰ通信網との境界点に配置されるメディアゲートウェイ装置等に好適に適用可能である。

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
上述の第１の視点に係る通信装置のとおりである。
［付記２］
前記ＲＴＰ送受信部は、受信したＲＴＰパケットから前記通信網の品質を示す統計情報を算出し、
前記分析制御部は、前記統計情報に基づいて前記通信網の品質劣化を判定する、好ましくは付記１に記載の通信装置。
［付記３］
前記分析制御部は、自装置で検出したＤＴＭＦ信号の検出履歴と他の通信装置が検出したＤＴＭＦ信号の検出履歴に基づき、前記通信網の品質劣化を判定する、好ましくは付記１に記載の通信装置。
［付記４］
前記分析制御部は、自装置で検出したＤＴＭＦ信号とＤＴＭＦ信号に関する規格値に基づき、前記通信網の品質劣化を判定する、好ましくは付記１に記載の通信装置。
［付記５］
前記分析制御部は、他の通信装置に対して、ＲＴＰパケットに格納されるＤＴＭＦ信号の信号長が長くなるように指示する、好ましくは付記１乃至４のいずれか一に記載の通信装置。
［付記６］
受信したＲＴＰパケットに含まれるユーザデータに対して所定の変換処理を行う、データ処理部をさらに備え、
前記分析制御部は、ＤＴＭＦ信号がＲＦＣ４７３３形式によりＲＴＰパケットに格納されている場合には、前記データ処理部に対してＤＴＭＦ信号の信号長が長くなるように前記ユーザデータを変換するように指示する、好ましくは付記１乃至４のいずれか一に記載の通信装置。
［付記７］
前記データ処理部は、ＤＴＭＦ信号がみなし音声としてＲＴＰパケットに格納されているか、ＤＴＭＦ信号がＲＦＣ（Request for Comments）４７３３の形式によりＲＴＰパケットに格納されているか、を判定する、好ましくは付記６に記載の通信装置。
［付記８］
通信呼に関してグループ分けを行い、前記グループごとに通信品質の分析を行うと共に、通信品質が劣化したと判定されたグループに属するＲＴＰパケットに格納されて送受信されるＤＴＭＦ信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う、Ｕ−Ｐｌａｎｅ（ユーザプレーン）分析制御部をさらに備える、好ましくは付記１乃至７のいずれか一に記載の通信装置。
［付記９］
前記データ処理部は、ユーザデータを音声符号化方式で復号した後に周波数成分解析を行い、ＤＴＭＦ信号がＲＴＰパケットに含まれるか否かを判定する、好ましくは付記７又は８に記載の通信装置。
［付記１０］
前記統計情報は、少なくともパケットロス率及びジッタ値のいずれかである、好ましくは付記１乃至９のいずれか一に記載の通信装置。
［付記１１］
上述の第２の視点に係る通信方法のとおりである。
［付記１２］
上述の第３の視点に係るプログラムのとおりである。
なお、付記１１の形態及び付記１２の形態は、付記１の形態と同様に、付記２の形態〜付記１０の形態に展開することが可能である。

なお、引用した上記の特許文献等の各開示は、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態ないし実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択（部分的削除を含む）が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１０ 通信装置
１１ ＲＴＰ送受信部
１２ 分析制御部
１０１、１０１ａ、１０１ｂ ゲートウェイ装置
１０２ ユーザ端末
２０１ 呼制御部
２０２、２０２ａ〜２０２ｎ Ｕ−Ｐｌａｎｅ処理部
２０３ 第１のＲＴＰ送受信部
２０４ 第１のＲＴＣＰ送受信部
２０５ Ｕ−Ｐｌａｎｅデータ処理部
２０６ 統計情報記憶部
２０７ 分析・制御部
２０８ 第２のＲＴＰ送受信部
２０９ 第２のＲＴＣＰ送受信部
２１０ Ｕ−Ｐｌａｎｅ統計情報記憶部
２１１ Ｕ−Ｐｌａｎｅ分析・制御部
３０１ ＣＰＵ（Central Processing Unit）
３０２ メモリ
３０３ ＮＩＣ（Network Interface Card）
５０１ 第２の呼制御部
５０２ 音声入力部
５０３ 第２のＵ−Ｐｌａｎｅデータ処理部
５０４ 第３のＲＴＰ送受信部
５０５ 第３のＲＴＣＰ送受信部
５０６ 音声出力部
５０７ 画面制御部
５０８ 制御部

Claims (10)

1. ＲＴＰ（Real time Transport Protocol）パケットを送受信する、ＲＴＰ送受信部と、
   ＲＴＰパケットを伝送する通信網に品質劣化が生じているか否かを判定する、分析制御部と、
   を備え、
   前記分析制御部は、前記通信網に品質劣化が生じていると判定した場合に、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ（Dual-Tone Multi-Frequency）信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う、通信装置。
2. 前記ＲＴＰ送受信部は、受信したＲＴＰパケットから前記通信網の品質を示す統計情報を算出し、
   前記分析制御部は、前記統計情報に基づいて前記通信網の品質劣化を判定する、請求項１に記載の通信装置。
3. 前記分析制御部は、自装置で検出したＤＴＭＦ信号の検出履歴と他の通信装置が検出したＤＴＭＦ信号の検出履歴に基づき、前記通信網の品質劣化を判定する、請求項１に記載の通信装置。
4. 前記分析制御部は、自装置で検出したＤＴＭＦ信号とＤＴＭＦ信号に関する規格値に基づき、前記通信網の品質劣化を判定する、請求項１に記載の通信装置。
5. 前記分析制御部は、他の通信装置に対して、ＲＴＰパケットに格納されるＤＴＭＦ信号の信号長が長くなるように指示する、請求項１乃至４のいずれか一項に記載の通信装置。
6. 受信したＲＴＰパケットに含まれるユーザデータに対して所定の変換処理を行う、データ処理部をさらに備え、
   前記分析制御部は、ＤＴＭＦ信号がＲＦＣ４７３３形式によりＲＴＰパケットに格納されている場合には、前記データ処理部に対してＤＴＭＦ信号の信号長が長くなるように前記ユーザデータを変換するように指示する、請求項１乃至４のいずれか一項に記載の通信装置。
7. 前記データ処理部は、ＤＴＭＦ信号がみなし音声としてＲＴＰパケットに格納されているか、ＤＴＭＦ信号がＲＦＣ（Request for Comments）４７３３の形式によりＲＴＰパケットに格納されているか、を判定する、請求項６に記載の通信装置。
8. 通信呼に関してグループ分けを行い、前記グループごとに通信品質の分析を行うと共に、通信品質が劣化したと判定されたグループに属するＲＴＰパケットに格納されて送受信されるＤＴＭＦ信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う、ユーザプレーン分析制御部をさらに備える、請求項１乃至７のいずれか一項に記載の通信装置。
9. 通信装置において、
   ＲＴＰ（Real time Transport Protocol）パケットを送受信するステップと、
   ＲＴＰパケットを伝送する通信網に品質劣化が生じているか否かを判定するステップと、
   前記通信網に品質劣化が生じていると判定した場合に、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ（Dual-Tone Multi-Frequency）信号の信号長が長くなるようにＲＴＰパケットに関する制御を行うステップと、
   を含む通信方法。
10. 通信装置に搭載されたコンピュータに、
    ＲＴＰ（Real time Transport Protocol）パケットを送受信する処理と、
    ＲＴＰパケットを伝送する通信網に品質劣化が生じているか否かを判定する処理と、
    前記通信網に品質劣化が生じていると判定した場合に、ＲＴＰパケットに格納されて送受信されるＤＴＭＦ（Dual-Tone Multi-Frequency）信号の信号長が長くなるようにＲＴＰパケットに関する制御を行う処理と、
    を実行させるプログラム。

Images