JP2009049817A

JP2009049817A - Ｉｐ電話システム

Info

Publication number: JP2009049817A
Application number: JP2007215338A
Authority: JP
Inventors: Norio Kodera; 教雄小寺; Atsushi Fujimoto; 淳富士本; Masayuki Nonaka; 誠之野中
Original assignee: Aruze Corp
Current assignee: Universal Entertainment Corp
Priority date: 2007-08-21
Filing date: 2007-08-21
Publication date: 2009-03-05

Abstract

【課題】通話装置の低消費電力化を図って長時間の連続使用を可能としたＩＰ電話システムを提供する。
【解決手段】ネットワーク(ＩＰ網)を介して相互に通話することが可能な複数の通話装置T1,T2と、通話装置間で通話する際の接続開始処理を実行すると共に、通話装置間での通話に際し、通話装置との間で送受信される音声データを制御するサーバＳｖとを有するＩＰ電話システムであって、接続開始処理が実行されて、通話装置間の通話接続が確立した状態において、通話装置とサーバとの間で、音声データの送受信が行われる標準通話モードと、所定レベル以下の音声データの送受信を停止させ且つ所定レベル以上の音声データの送受信を継続させる省電力通話モードとを、所定コマンドが入力されることにより、相互に切り替える制御を行う送受信データ制御手段を備える。
【選択図】図１

Description

本発明は、ＩＰ(Internet Protocol)ネットワークを用いた通信技術において通話装置の低消費電力化が図られたＩＰ電話システムに関する。

従来、インターネットやイントラネットなどのＩＰネットワーク(ＩＰ網)を用いて、例えばＢＧＭ(Back Ground Music)などの音楽や、人の話し声といった各種の音声データを通信する技術(例えば、特許文献１)が知られている。そして、かかる音声通信技術は、例えばＶｏＩＰ(Voice over Internet Protocol)を用いた通話装置(いわゆるＩＰ電話)などとして実用化されている。

実用化の一例として、ＩＰ電話(通話装置)相互で通話を行う場合、送信元において、アナログの音声データをデジタル変換すると共に、そのデジタルデータにフレーム化処理を施して小さな単位に分割し、その分割データ毎に送信先のヘッダ情報を付加することで、当該音声データは、例えばＲＴＰ(Real-time Transport Protocol)パケットと呼ばれる小さな単位に分割された状態で順次ＩＰ網を介して送信先へ送信(無線通信)される。そして、送信先において、受信した各パケットを元の音声データに復元し再生することにより、送信元と送信先との間で通話が行われる。

また、ＩＰ電話(通話装置)を用いた音声通信技術では、当該ＩＰ電話が無線ＬＡＮ接続されたＩＰ網の特性上、送信元と送信先との間の距離や通信時間に影響されること無く、比較的低コストで音声通信を行うことが可能である。また、ＩＰ電話と共に例えばSkypeなどのソフトフォンや他の固定電話とを組み合わせることで、当該音声通信技術をコラボレーションツールとして利用することも可能である。
特開２００５−４５７３７号公報

しかしながら、現状のＩＰ電話(通話装置)には、長時間に亘って連続して使用することができないといった問題がある。これは、ＩＰ電話の通信(通話)に際し、電力消費の多い処理が行われるため、バッテリー(電池)の容量が早期に消費されてしまうことが要因となっている。ここで、ＩＰ電話の電力消費について考察すると、(１)音声データのデジタル化、(２)パケットからの音声データの復元及び再生、(３)ＩＰ網へのパケットの無線通信などの各処理に際し、バッテリー(電池)の電力消費量が多くなっている。

そこで、本発明の目的は、通話装置の低消費電力化を図って長時間の連続使用を可能としたＩＰ電話システムを提供することにある。

このような目的を達成するために、第１の発明は、ネットワークを介して相互に通話することが可能な複数の通話装置と、前記通話装置間で通話する際の接続開始処理を実行すると共に、前記通話装置間での通話に際し、当該通話装置との間で送受信される音声データを制御するサーバとを有するＩＰ電話システムであって、前記接続開始処理が実行されて、前記通話装置間の通話接続が確立した状態において、前記通話装置と前記サーバとの間で、前記音声データの送受信が行われる標準通話モードと、所定レベル以下の前記音声データの送受信を停止させ且つ所定レベル以上の前記音声データの送受信を継続させる省電力通話モードとを、所定コマンドが入力されることにより、相互に切り替える制御を行う送受信データ制御手段を備えている。

第１の発明によれば、所定コマンドの入力によって標準通話モードと省電力通話モードとの切替制御が行われることで、例えば電力消費の多い処理を低減し、これにより、通話装置のバッテリー(電池)の電力消費量を少なくすることができる。この結果、通話装置を長期に亘って連続して使用することができる。

第２の発明において、前記通話装置には、前記送受信データ制御手段として、前記通話モード切替用のコマンドが入力されることにより、前記サーバに対する所定レベル以下の前記音声データの送信を停止させ且つ所定レベル以上の前記音声データの送信を継続させる送受信データ制御部が設けられており、前記サーバには、前記送受信データ制御手段として、前記通話装置の前記通話モード切替を行う旨の通知コマンドが入力されることにより、前記通話装置に対する所定レベル以下の音声データの送信を停止させ且つ所定レベル以上の音声データの送信を継続させる送受信データ制御機能が付加されている。

第２の発明によれば、通話装置からサーバへ音声データを送信する際の送信処理だけで無く、サーバから通話装置へ送信された音声データの受信処理を低減することができるため、通話装置の低消費電力化を更に図ることができる。

第３の発明において、前記音声データは、ＲＴＰに基づいて前記通話装置と前記サーバとの間で送受信されており、前記通知コマンドは、ＲＴＣＰの拡張イベントとして前記通話装置から前記サーバへ送信されている。

第３の発明によれば、通常のデータストリーム(即ち、音声データの処理シーケンス)に影響されること無く、簡単に通話モードの切替を実行することができる。

本発明によれば、通話装置の低消費電力化を図って長時間の連続使用を可能としたＩＰ電話システムを実現することができる。

以下、本発明の一実施の形態に係るＩＰ電話システムについて説明する。
本実施の形態に係るＩＰ電話システムは、インターネットの通信技術を利用した通話装置や、所定の通信規約(プロトコル)に従って通話装置同士を交信(無線通信)させる機能を有するサーバを、ＩＰ網を介して相互に接続させた通信システムとして構築されている。なお、ＩＰ網とは、インターネット或いはインターネットと同じ仕組みのネットワークの総称であり、通話装置は、当該ＩＰ網に敷設された無線ＬＡＮ(Local Area Network)、或いは有線ＬＡＮに接続させることができる。

また、サーバは、例えばＳＩＰ(Session Initiation Protocol)やＰ２Ｐ(Peer to Peer)などの通信形態に準拠して、通話装置の呼設定を実現する機能を有している。この場合、通話装置としては、例えばＩＰ電話、並びにＩＰ電話として機能するインカム、或いは所定のアプリケーションソフトがインストールされ、ソフトフォンとして機能するパソコン(デスクトップ型やノート型など)Ｈ(図１(ａ)参照)、ＰＤＡ(Personal Digital Assistants)などを適用することができる。

図１(ａ),(ｂ)には、上述したようなＩＰ電話システムの構成例が示されており、かかるＩＰ電話システムにおいては、複数(図面では２名)のユーザP1,P2が携帯している通話装置(例えば、無線ＩＰ電話端末)T1,T2と、各通話装置T1,T2と無線通信を行って当該通話装置T1,T2をＩＰ網(図示しない)に接続させると共に、各通話装置T1,T2との通話に際し、当該通話装置T1,T2とサーバＳｖとの間で送受信されるデータを中継する複数(図面では一例として、２つ)の中継装置(例えば、アクセスポイント)1AP,2APと、ＩＰ網を介して各中継装置1AP,2APに接続されたサーバＳｖとを備えて構成されている。

なお、中継装置1AP,2APは、各通話装置T1,T2との通話に際し、ＩＰ網のトラフィック状況に応じて当該データを中継する機能を有しており、これにより、前記通話時におけるサーバＳｖやＩＰ網へのトラフィックの集中を防止するとともに、サーバＳｖやＩＰ網に対する負荷の分散を図ることができる。その際、このようなデータ中継機能を中継装置1AP,2APに持たせるのではなく、図示しないデータ中継サーバ(負荷分散サーバ)を別途設けて同様のデータ中継を行わせる構成としてもよいし、サーバＳｖにデータ中継機能を持たせてもよい。

ここで、通話装置T1,T2は、そのモバイル性を確保するために、一定時間毎(例えば、数秒に１回、１分に１回)に各中継装置1AP,2APとの間で無線通信を行って、自端末の位置登録を繰り返すように設定されている。なお、各通話装置T1,T2と各中継装置1AP,2APとの無線通信では、例えばIEEE802.11a、IEEE802.11b、IEEE802.11gなどの規格に従って各種信号の送受信が行われる。このとき、各中継装置1AP,2APは、各通話装置T1,T2からの無線信号を受信すると、各中継装置1AP,2AP毎に電波強度を測定し、その測定結果を各中継装置1AP,2APを介してサーバＳｖに通知する。

図２には、このような通話装置T1,T2の内部構成の一例が示されており、当該通話装置T1,T2は、音声を電気信号に変換するマイク８と、電気信号を音声に変換するスピーカ１０と、マイク８から出力されたアナログ信号をデジタル信号に変換すると共に、デジタル信号をアナログ信号に変換し、当該アナログ信号によりスピーカ１０を駆動する音声処理回路１２と、ＳＩＰリクエストを生成・送信し、応答を受信するユーザ・エージェント・クライアント部１４と、ＳＩＰリクエストを受信・処理し、応答を生成するユーザ・エージェント・サーバ部１６と、各中継装置1AP,2APとの間で無線通信し、各種データの送受信を行う無線ＬＡＮインターフェイス１８と、ＲＦ-ＩＤを有する無線チップ１９とを備えている。

この場合、各通話装置T1,T2は、交信可能範囲(交信エリア)E1,E2(図１(ａ))内にある中継装置1AP,2APを経由して、ＳＩＰサーバとしての機能を有するサーバＳｖを介して互いに交信(無線通信)可能であると共に、内線電話の端末として各ユーザP1,P2相互で通話することが可能である。また、通話装置T1,T2にＳＩＰフォンの機能を持たせることで、１対多の通話(例えば、マネージャから全ユーザへの一斉通報)、多対多の通話(例えば、全ユーザ参加の多地点会議)などを実行することも可能である。更に、ＳＩＰサーバとしての機能を有するサーバＳｖを他のエリア(同一建物内の別フロアや遠隔地にある支店など)のサーバ(図示しない)と接続することにより、複数の交信エリアに割り当てられた通話装置相互間で交信することも可能である。

図３には、各中継装置1AP,2APの内部構成の一例が示されており、当該中継装置1AP,2APは、上述したような無線ＬＡＮ端末(無線ＩＰ電話端末)である通話装置T1,T2をサーバＳｖに接続するための電波を中継する機能を有する。これにより、各中継装置1AP,2APの交信可能範囲(交信エリア)E1,E2内にある全ての通話装置T1,T2同士、及び当該通話装置T1,T2とサーバＳｖとは、本実施の形態の通信システム(ネットワーク)を経由して相互に接続可能となる。

図３に示すように、中継装置1AP,2APは、各通話装置T1,T2に設けられたＲＦ-ＩＤを有する無線チップ１９から受信した電波の強度を自動的に測定し、その測定結果を当該通話装置T1,T2の状態を示す情報に対応した電波強度測定データとして取得し且つ記憶すると共に、記憶した電波強度測定データをサーバＳｖに送信する電波強度測定部２０と、各通話装置T1,T2との間で無線通信を行うための無線通信部２２と、無線通信部２２に接続された演算部２４と、演算部２４に接続されたネットワーク通信制御部２６とを備えている。
ここで、無線通信部２２は、各通話装置T1,T2に対してデータの送受信(無線通信)を行うための変調・復調機能、並びに、所定の通信規約(プロトコル)に従ってデータの送受信(無線通信)を行う機能を有する例えばＲＦ(Radio Frequency)ユニットとして構成されている。

また、演算部２４は、ＣＰＵ２８がＲＡＭ３０を作業領域としてＲＯＭ３２に記憶されたプログラムに従って所定の処理を実行する機能を有する。ここで、ＲＯＭ３２には、例えば２つのバンクＢ１,Ｂ２が設けられており、少なくとも一方のバンク(例えば、Ｂ１)には、中継装置1AP,2APとして機能させるためのプログラムが記憶されるようになっている。また、プログラムデータは、バス３４を介してＣＰＵ２８とＲＡＭ３０とＲＯＭ３２との間でやり取りされるようになっており、バス３４は、ネットワーク通信制御部２６を介してサーバＳｖに接続されている。この場合、ＲＯＭ３２のバンクＢ１に記憶されたプログラムがＲＡＭ３０を作業領域としてＣＰＵ２８によって実行されることにより、中継装置1AP,2APが実現される。また、例えばバンクＢ１に不都合が発生した場合やプログラムを更新した場合に、通信を停止させないようにするために、ＣＰＵ２８は、予備用のバンクＢ２に切り換えて運用されるようにしても良い。

また、サーバＳｖは、ＳＩＰサーバとしての機能(ＳＩＰリクエストを処理する機能)を有するＳＩＰエンティティであって、ユーザ・エージェントとして動作する通話装置T1,T2からのＳＩＰリクエストの次の転送先を解決し、そのリクエストを転送するプロキシサーバ、ＳＩＰリクエストの次の転送先を解決し、そのリクエストを応答で送信するリダイレクトサーバ、REGISTERリクエストを受信し、ユーザ・エージェントである通話装置T1,T2のコンタクトアドレスを登録するサーバを含むユーザ・エージェント・サーバとして機能するだけで無く、ユーザ・エージェント・クライアントとしても機能する。

図４には、このようなサーバＳｖの内部構成の一例が示されており、当該サーバＳｖは、通話装置位置特定部３６と、通話装置位置記憶部３８と、通話対象特定部４１と、特定通話装置通報部４３とを備えている。かかるサーバＳｖは、例えばコンピュータ、ワークステーションなどの情報処理装置として構成されており、その内部メモリであるＲＯＭ４４に以下に説明する各種機能を実行させるためのプログラムを記憶し、これをＲＡＭ４６を作業領域としてＣＰＵ４８によって実行する。この場合、プログラムは、必ずしもＲＯＭ４４に記憶させる必要は無く、例えばＡＳＰ(Application Service Provider)などの外部装置から提供されるようにしても良い。

通話装置位置特定部３６は、各通話装置T1,T2から各中継装置1AP,2APを経由して受信した電波強度測定データに基づいて、当該通話装置T1,T2の位置を特定する。このとき、各通話装置T1,T2の位置は、それを携帯するユーザP1,P2(図１)の移動に従って変化するため、通話装置位置特定部３６は、電波強度測定データを受信する毎に当該通話装置T1,T2の位置を最新のものに更新する。

なお、通話装置T1,T2の位置は、必ずしも座標のように１点に定める必要は無く、例えば各中継装置1AP,2APの交信可能範囲(交信エリア)E1,E2を複数の小エリアに分割し、当該小エリア毎に該当する通話装置T1,T2の位置を特定しても良い。また、通信トラフィックを考慮して、各中継装置1AP,2APが測定した電波強度測定データに変更があった場合のみ、当該中継装置1AP,2APから当該測定データをサーバＳｖへ送信し、当該送信タイミングでサーバＳｖが通話装置T1,T2の位置の特定及び更新を行う構成としてもよい。

通話装置位置記憶部３８は、通話装置位置特定部３６が特定した各通話装置T1,T2の位置を記憶すると共に、電波強度測定データを受信する毎に最新のものに更新した当該通話装置T1,T2の位置を記憶する。

通話対象特定部４１は、発呼側のユーザ(例えば、ユーザＰ１)が携帯する通話装置Ｔ１を操作し、着呼側のユーザ(例えば、ユーザＰ２)が携帯する通話装置Ｔ２を呼び出すための呼出信号が通話装置Ｔ１から送信されたとき、当該呼出信号に対応する通話装置Ｔ２(呼出通話装置)情報を抽出し、通話装置位置記憶部３８に記憶されている当該通話装置Ｔ２の位置を特定する。

特定通話装置通報部４３は、通話対象特定部４１が特定した通話装置(呼出通話装置Ｔ２)の位置情報に基づいて当該通話装置Ｔ２に向けて発呼する。これにより、発呼側の通話装置Ｔ１と着呼側の通話装置Ｔ２との通話接続を試みる接続開始処理が実行される。
一例として、特定通話装置通報部４３にＳＩＰフォン(ＩＰ電話)の発呼側端末(ユーザ・エージェント・クライアント)としての機能を持たせて、当該特定通話装置通報部４３と各通話装置T1,T2との間でセッション管理を行う場合を想定する。この場合、特定通話装置通報部４３には、各通話装置T1,T2の宛先情報(例えば、ＵＲＩ(Uniform Resource Identifier)、電話番号)を予め記録しておくことにより、該当する宛先情報に基づいてセッション(ＲＴＰ(Real-time Transport Protocol)／ＲＴＣＰ(Real-time Transport Control Protocol)セッション)の確立処理が実行される。

接続開始処理では、所定の通信規約(プロトコル)に従ったＳＩＰリクエストの送受信処理(シグナリング処理)がサーバＳｖを経由して実行される。具体的には、ＳＩＰメッセージの手順に従って、まず、発呼側(通話装置Ｔ１)から着呼側(通話装置Ｔ２)に「INVITE(招待)」が送信され、続いて、着呼側(通話装置Ｔ２)から「100 Trying(暫定応答)」「180 Ringing(呼び出し中)」「200 ok(成功応答)」を受信したとき、発呼側(通話装置Ｔ１)から着呼側(通話装置Ｔ２)に「ACK(確認応答)」が送信される。これにより、発呼側(通話装置Ｔ１)と着呼側(通話装置Ｔ２)との通話接続が確立(セッション確立)する。

セッションが確立すると、発呼側の通話装置Ｔ１は、着呼側の通話装置Ｔ２に向けて通話を開始可能な状態に制御され、それ以降、所定の通話操作(例えば、通話ボタンの操作など)を行うことにより、発呼側から着呼側へ通話を行うことができる。通話装置T1,T2間での通話に際しては、音声データをＲＴＰ／ＲＴＣＰに基づいてパケット化した音声パケット(ＲＴＰパケット)が送受信されるとともに、必要に応じて当該音声パケット(ＲＴＰパケット)の送受信を制御するための制御パケット(ＲＴＣＰパケット)の送受信が行われる。

なお、ＲＴＰは、音声データ(或いは、動画像データ)そのものを送受信するためのプロトコルであるのに対し、ＲＴＣＰは、周期的に、パケットロス、遅延ジッタ、ラウンドトリップ等の回線品質を評価し、その帯域に見合ったリアルタイム通信を実現するため情報を送受信するためのプロトコルである。したがって、ＲＴＣＰパケットを送受信させることで、通信相手から返信される情報により、例えばネットワークの状態や通話装置T1,T2の状態などを推測し、当該通話装置T1,T2間の通信状態の変更(通信回数の低減等)などの動的な処理を行うことができる。

ここで、接続開始処理が実行され、ＲＴＰ／ＲＴＣＰのセッションが確立された後に通話装置T1,T2間で送受信されるＲＴＰ／ＲＴＣＰパケットについて説明する。
ＲＴＰパケットは、ＩＰヘッダ、ＵＤＰ(User Datagram Protocol)ヘッダ、ＲＴＰヘッダ及びＲＴＰデータから構成されている。この場合、ＲＴＰヘッダには、先頭から、バージョン情報格納部(Ｖ：version、例えばＶ＝２)、パディング格納部(Ｐ：padding)、拡張ビット格納部(Ｘ：extension)、ＣＳＲＣ(contributing source)カウント格納部(ＣＣ)、マーカ情報(Ｍ：marker)格納部、マーカ・ビット格納部(Ｍ：maker)、ペイロード種別情報格納部(ＰＴ：payload type)、シーケンス番号情報格納部(sequence number)、タイムスタンプ格納部(time stamp)、ＳＳＲＣ識別子格納部(synchronization source identifier)、ＣＳＲＣ識別子格納部が設けられている。そして、ＣＳＲＣ識別子格納部の後ろ(拡張ヘッダ使用時(拡張ビット格納部に１がセットされた場合)は、当該拡張ヘッダ部の後ろ)に、通話装置T1,T2間、具体的にはユーザP1,P2間で実際にやり取りされる音声データが付加されている。

これに対し、ＲＴＣＰパケットは、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＣＰヘッダ及びＲＴＣＰデータから構成されている。この場合、拡張可能なＲＴＣＰパケットであるＲＴＣＰＡＰＰパケットのヘッダには、先頭から、バージョン情報格納部(Ｖ：version、例えばＶ＝２)、パディング有無格納部(Ｐ：padding)、subtype格納部(いわゆるアイテムカウント格納部(ＩＣ：Item Count))、パケットタイプ(ＰＴ：packet type)格納部、レポート長格納部(length)、ＳＳＲＣ／ＣＳＲＣ識別子格納部、アスキー(ＡＳＣＩＩ：American Standard Code for Information、情報交換用アメリカ標準コード)で記述されるＮａｍｅ格納部が設けられている。そして、Ｎａｍｅ格納部の後ろに、アプリケーション独自のデータが格納されるデータ格納部(Application-Dependent Data)が付加されている。

パケットタイプＰＴ格納部には、ＲＴＣＰパケットの種別が記録されており、本実施の形態においては、一例として、このパケットタイプ(ＰＴ)に２０４(パケットタイプ値)が設定されている。パケットタイプ値の２０４は、かかるＲＴＣＰパケットがＡＰＰ(Application-defined：アプリケーション固有情報)であること、すなわち、ＲＴＣＰ規定外のアプリケーション固有の制御情報を通知するためのパケットであることを示す。

なお、ＲＴＣＰパケットには、上述したようなＡＰＰパケット(パケットタイプ値２０４)の他にも、ＲＴＰデータの送信者から送られるタイプのＲＴＣＰＳＲ(Sender Report)パケット(パケットタイプ値２００)や、ＲＴＰデータの受信者から送られるタイプのＲＴＣＰパケットＲＴＣＰＲＲ(Receiver Report)パケット(パケットタイプ値２０１)などがある。

ＳＲパケットは、ストリームを送出している通話装置から他の通話装置に対して送出されるもので、自装置が送出したストリームに関する情報である送信情報(sender info)と、受信したストリーム各々についてストリームの受信状態(パケット破棄率、ジッタ等)を送信側の通話装置へ報告するためのレポートブロック(reception report block)とを含んでいる。これに対し、ＲＲパケットは、他の通話装置から受信したスリームに関する情報を通知するためのもので、同じく受信したストリーム各々についてストリームの受信状態を送信側の通話装置へ報告するためのレポートブロックを含んでいる。

このレポートブロックには、パケットの送信者の同期送信元(ＳＳＲＣ：Synchronization Source)識別子、ＲＴＰ損失率、損失ＲＴＰパケット数、受信シーケンス番号、到着時間間隔のジッタの平均値、最後に受信したＳＲの送信時刻(ＬＳＲ：Last SR timestamp)、最後にＳＲを受信した時刻からこのＲＲを送るまでの時間(ＤＬＳＲ：Delay since Last SR)が設定される。

したがって、送信側の通話装置(例えば、通話装置Ｔ１)においては、ＲＴＰデータの送信の際に、送信ＲＴＰパケット数及び送信ＲＴＰバイト数を管理しておき、また、受信側の通話装置(例えば、通話装置Ｔ２)においては、ＲＴＰデータの受信の際に、受信ＲＴＰパケット数、損失ＲＴＰパケット数及び到着時間のジッタ等の管理情報を管理する。これにより、通話装置T1,T2において、相互に通信状況を把握することができる。

ところで、本実施の形態のＩＰ電話システムにおいては、通話装置T1,T2間での通話に際し、当該各通話装置T1,T2とサーバＳｖとの間では、２つの通話モード(標準通話モードと省電力通話モード)を任意に切り替えて音声データの送受信が行われている。
すなわち、本実施の形態のＩＰ電話システムには、接続開始処理が実行されて、通話装置T1,T2間の通話接続が確立した状態において、通話装置T1,T2とサーバＳｖとの間で、すべての音声データの送受信が行われる標準通話モードと、所定レベル以下の音声データの送受信を停止させ且つ所定レベル以上の音声データの送受信を継続させる省電力通話モードとを、所定コマンドが入力されることにより、相互に切り替える制御を行う送受信データ制御手段が備えられている。

この場合、図２に示すように通話装置T1,T2には、送受信データ制御手段として送受信データ制御部２７が設けられており、当該データ制御部２７は、前記通話モード切替用のコマンド、具体的には、標準通話モードから省電力通話モードへの切替用のコマンドが入力されることにより、サーバＳｖに対する所定レベル以下の音声データの送信を停止させ、且つ所定レベル以上の音声データの送信を継続させる。その一方で、データ制御部２７は、省電力通話モードから標準通話モードへの切替用のコマンドが入力されることにより、サーバＳｖに対する所定レベル以下の音声データの送信を再開させ、且つ所定レベル以上の音声データと併せて送信させる。

これに対し、サーバＳｖには、送受信データ制御手段として、通話装置T1,T2から前記通話モード切替を行う旨の通知コマンド、具体的には、標準通話モードから省電力通話モードへの切替を行う旨の通知コマンドが入力されることにより、通話装置T1,T2に対して所定レベル以下の音声データの送信を停止させ、且つ所定レベル以上の音声データの送信を継続させる送受信データ制御機能が付加されている。その一方で、サーバＳｖの送受信データ制御機能は、省電力通話モードから標準通話モードへの切替を行う旨の通知コマンドが入力されることにより、通話装置T1,T2に対する所定レベル以下の音声データの送信を再開させ、所定レベル以上の音声データと併せて送信させている。

なお、通話装置T1,T2及びサーバＳｖにおいて、省電力通話モードの設定時に送信を停止させるか否かの音声データのレベルは、ＩＰ電話システムの使用条件や使用目的などに応じて、例えば何らかの意味のある音声が入力されたか否か、或いは日常会話程度の音の強さ(デシベル値)、音量、周波数などを有するか否か、又はこれらの諸条件を満たすか否かなどの基準に基づいて任意に設定すればよいため、ここでは特に限定しない。

以下、本実施の形態のＩＰ電話システムの通話モード切替の動作例について、図１(ｂ)を参照して説明する。なお、当該動作説明に際し、通話装置T1,T2間では、すでに通話装置Ｔ１を発呼側、通話装置Ｔ２を着呼側として接続開始処理が実行され、当該通話装置T1,T2間で通話接続が確立した状態(ＲＴＰ／ＲＴＣＰセッションが確立した状態)にあり、この状態において、通話装置Ｔ１とサーバＳｖとの間で通話モード切替のための制御が行われる場合を想定する。

接続開始処理の実行後、通話装置Ｔ１は、ＲＴＰパケットに音声データを付加(格納)し、サーバＳｖを介して相手側(着呼側)の通話装置Ｔ２に対して送信している(Ｅ１)。この場合の音声データには、日常の通話時に交わされる所定レベル以上の音声データ(以下、有音データという)の他、所定レベル以下の音声データ、例えば会話の合間に生じる無声データやユーザの周囲で生じている雑音データなど(以下、これらを無音データという)も含まれている。

かかる無音データは、本来的に相手側(通話装置Ｔ２)へ送信されなくとも、当事者同士(Ｐ１とＰ２)の通話(会話)に特段影響を与えることはなく、当該通話をそのまま継続させることができる。その一方で、かかる無音データを音声処理回路１２においてデジタル化させ、ＲＴＰパケットに付加してサーバＳｖへパケット送信させた場合、通話装置Ｔ１のバッテリー(電池)を無駄に消費させる結果を招く。

そこで、本実施の形態においては、通話装置Ｔ１が上述したような無音データのパケット送信を停止すること、すなわち、通話装置Ｔ１を標準通話モードから省電力通話モードへ切り替えることで、バッテリー(電池)の電力消費量を抑え、当該通話装置Ｔ１の低消費電力化を図っている。この場合、通話装置Ｔ１は、送受信データ制御部２７がバッテリー(電池)の残量を常時監視し、当該残量が一定レベル以下に低下した場合、通話モードを標準通話モードから省電力通話モードへ切り替えるためのコマンド(モード切替コマンド)を自動生成し、当該モード切替コマンドを実行することで、サーバＳｖに対する無音データのパケット送信を停止している。

なお、モード切替コマンドが生成されるタイミングは、例えば、フル充電時に対する残量の割合として予め固定的に設定してもよいし、通話時間やその時点でのバッテリー(電池)残量などに応じて任意に(段階的に)変動させて設定してもよい。
また、モード切替コマンドの生成及び実行は、上述したように送受信データ制御部２７がバッテリー(電池)残量を常時監視して自動的に行う構成の他、これに代えて、或いはこれに加えてユーザＰ１によって行われる明示的な動作(例えば、モード切替ボタンを押す動作やキーワード(意味のあるワード)の発声動作など)に基づいて、送受信データ制御部２７が受動的に行うようにしてもよい。このような構成によれば、ユーザＰ１は、通話装置Ｔ１のモニタ(特に符号は付さない)に表示されるバッテリー(電池)残量のインジケータを確認し、当該残量が低下している場合のみならず、十分な残量がある場合であっても予め通話時間を見越してモード切替コマンドを生成実行させ、通話モードを標準通話モードから省電力通話モードへ切り替えることができる。

このように通話装置Ｔ１において、通話モードが標準通話モードから省電力通話モードへの切替が行われる場合、通話装置Ｔ１は、かかるモード切替に先立って、送受信データ制御部２７が通話モードの切替を行う旨を通知するためのＲＴＣＰパケットを、無線ＬＡＮインターフェイス１８を介してサーバＳｖへ向けて送信する(Ｅ２)。その際、送受信データ制御部２７は、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に標準通話モードから省電力通話モードへの切替を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。

これに対し、通話モード切替を通知するＲＴＣＰパケットを通話装置Ｔ１から受信したサーバＳｖは、通話装置Ｔ１における省電力通話モードへの切り替えが行われた場合、当該サーバＳｖから当該通話装置Ｔ１へ送信する音声データを所定レベル以上の音声データ(有音データ)に限定し、所定レベル以下の音声データ(無音データ)の送信を停止する省電力通話モードへ切り替える旨を通知するためのＲＴＣＰパケットを通話装置Ｔ１へ向けて送信する(Ｅ３)。

その際、サーバＳｖは、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に標準通話モードから省電力通話モードへの切替を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。この場合、サーバＳｖ(図４)において、ＲＴＣＰパケット(ＡＰＰパケット)を生成する処理手順は、例えば当該処理手順を実行するためのプログラムをＲＯＭ４４に記憶し、その記憶したプログラムがＲＡＭ４６を作業領域としてＣＰＵ４８によって実行される。なお、サーバＳｖに対するプログラムのインストールに代えて、例えば同様の処理手順を実行するための回路系を新たにサーバＳｖに増設しても良い。

通話モード切替を通知するＲＴＣＰパケットをサーバＳｖから受信した通話装置Ｔ１は、上述したように送受信データ制御部２７がモード切替コマンドを生成し、当該モード切替コマンドを実行することで、標準通話モードから省電力通話モードへの切替を行う(Ｅ４)。
そして、通話装置Ｔ１は、送受信データ制御部２７が無音データのパケット送信を停止し、有音データのみをＲＴＰパケット化し、サーバＳｖに対して送信する(Ｅ５)。同様に、サーバＳｖも無音データのパケット送信を停止し、有音データのみをＲＴＰパケット化し、通話装置Ｔ１に対して送信する。

これにより、通話装置Ｔ１からサーバＳｖへ音声データを送信する際の送信処理だけで無く、サーバＳｖから通話装置Ｔ１へ送信された音声データの受信処理を低減することができるため、通話装置Ｔ１のバッテリー(電池)の電力消費量を非常に効果的に低減させることができ、当該通話装置Ｔ１の低消費電力化を有効に図ることができる。この結果、通話装置Ｔ１を長期に亘って連続して使用することが可能となる。
なお、かかる低消費電力化の効果は、発呼側の通話装置Ｔ１のみに限定されるものではなく、着呼側の通話装置Ｔ２においても、通話装置Ｔ１から送信される(受信する)音声データが有音データのみに限定されるため、その低消費電力化を図ることができる。

また、本実施の形態によれば、通話モードの切替をＲＴＣＰパケット(ＡＰＰパケット)を送受信することによる通知によって行っているため、通常のデータストリーム(即ち、音声データの処理シーケンス)に影響されること無く、簡単に通話モードの切替を実行することができる。加えて、ＲＴＣＰパケットの送受信単位で通話モードの切替を制御することができるため、実際の通話状態(通話環境)に即したより細やかな通話モードの切替制御を行うことができる。

ここで、本実施の形態においては、標準通話モードから省電力通話モードへの切替を行った後、必要に応じて省電力通話モードから標準通話モードへ切り替える(復帰させる)ことができる。
この場合、通話装置Ｔ１は、かかるモード切替(復帰)に先立って、送受信データ制御部２７がかかる通話モードの切替(復帰)を行う旨を通知するためのＲＴＣＰパケットを、無線ＬＡＮインターフェイス１８を介してサーバＳｖへ向けて送信する(Ｅ６)。その際、送受信データ制御部２７は、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に省電力通話モードから標準通話モードへの切替(復帰)を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。

これに対し、通話モード切替(復帰)を通知するＲＴＣＰパケットを受信したサーバＳｖは、通話装置Ｔ１における標準通話モードへの切り替え(復帰)が行われた場合、同様にかかる通話モードの切替(復帰)を行う旨を通知するためのＲＴＣＰパケットを通話装置Ｔ１へ向けて送信する(Ｅ７)。その際、サーバＳｖは、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に省電力通話モードから標準通話モードへの切替(復帰)を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。

これにより、通話装置Ｔ１は、サーバＳｖへの音声データの送信に際し、所定レベル以下の音声データ(無音データ)の送信を再開させ、所定レベル以上の音声データ(有音データ)と併せて送信を行う。同様に、サーバＳｖは、通話装置Ｔ１への音声データの送信に際し、無音データの送信を再開させ、有音データと併せて送信を行う。

なお、上述した実施の形態では、所定レベル以上の音声データを有音データとし、所定レベル以下の音声データを無音データとして規定したが、これに限定されることは無く、他の基準に基づいて音声データのレベルを設定しても良い。例えば、音声データに有音データが所定量含まれている場合、これを所定レベル以上の音声データとし、一方、音声データに無音データが所定量含まれている場合、これを所定レベル以下の音声データとして規定しても良い。

この場合、かかる基準を満たすか否かの判定処理を行う必要があるが、通話装置T1,T2では、例えば上述した送受信データ制御部２７によって判定処理を実行し、その判定結果に基づいて、通話モードを切り替えるようにしても良い。一方、サーバＳｖでは、例えば上述した送受信データ制御機能に更に判定機能を付加し、当該判定機能によって判定処理を実行し、その判定結果に基づいて、通話モードを切り替えるようにしても良いし、或いは、サーバＳｖに判定部(図示しない)を別途構築し、当該判定部によって判定処理を実行し、その判定結果に基づいて、通話モードを切り替えるようにしても良い。

また、通話モードの切り替えの基準として、各中継装置1AP,2APの電波強度測定部２０によって取得された電波強度測定データや、当該データに基づいて特定される各通話装置T1,T2の位置などを加味し、これに基づいて、通話装置T1,T2とサーバＳｖとの間の通話モードを切り替えるようにしても良い。例えば、電波強度測定データによって通話装置T1,T2の位置が中継装置1AP,2APの近くに所在することが特定されたとき、標準通話モードから省電力通話モードへ通信モードを切り替える。これに対して、電波強度測定データによって通話装置T1,T2の位置が中継装置1AP,2APから離れて所在することが特定されたとき、省電力通話モードから標準通話モードへ通信モードを切り替える。

このように、標準通話モードと省電力通話モードとの切替を相互に自由に行えることで、標準通話モード或いは省電力通話モードを任意に選択することができ、通話装置Ｔ１の低消費電力化を図ることができるだけでなく、通話環境に応じて通話品質を自由に変更させることができる。例えば、周囲の雑音が多い場所などでは省電力通話モードとしてバッテリー(電池)の消耗を防止し、静粛な場所に移動した際には標準通話モードに切り替えることで、通話品質をより高めた状態で通話を継続させることが可能となる。

本発明の一実施の形態に係るＩＰ電話システムの構成を示す図であって、(ａ)は、通話装置間で通話が行われている状態を示すシステム全体概要図、(ｂ)は、通話モードの切替が行われる際のシーケンス図。通話装置の内部構成を示す図。中継装置の内部構成を示す図。サーバの内部構成を示す図。

符号の説明

T1,T2 通話装置
６サーバ

Claims

ネットワークを介して相互に通話することが可能な複数の通話装置と、
前記通話装置間で通話する際の接続開始処理を実行すると共に、前記通話装置間での通話に際し、当該通話装置との間で送受信される音声データを制御するサーバとを有するＩＰ電話システムであって、
前記接続開始処理が実行されて、前記通話装置間の通話接続が確立した状態において、
前記通話装置と前記サーバとの間で、前記音声データの送受信が行われる標準通話モードと、所定レベル以下の前記音声データの送受信を停止させ且つ所定レベル以上の前記音声データの送受信を継続させる省電力通話モードとを、所定コマンドが入力されることにより、相互に切り替える制御を行う送受信データ制御手段を備えていることを特徴とするＩＰ電話システム。
前記通話装置には、前記送受信データ制御手段として、前記通話モード切替用のコマンドが入力されることにより、前記サーバに対する所定レベル以下の前記音声データの送信を停止させ且つ所定レベル以上の前記音声データの送信を継続させる送受信データ制御部が設けられており、
前記サーバには、前記送受信データ制御手段として、前記通話装置の前記通話モード切替を行う旨の通知コマンドが入力されることにより、前記通話装置に対する所定レベル以下の音声データの送信を停止させ且つ所定レベル以上の音声データの送信を継続させる送受信データ制御機能が付加されていることを特徴とする請求項１に記載のＩＰ電話システム。
前記音声データは、ＲＴＰに基づいて前記通話装置と前記サーバとの間で送受信されており、前記通知コマンドは、ＲＴＣＰの拡張イベントとして前記通話装置から前記サーバへ送信されていることを特徴とする請求項２に記載のＩＰ電話システム。