(57)【要約】【課題】通話装置の低消費電力化を図って長時間の連続使用を可能としたＩＰ電話システムを提供する。【解決手段】ネットワークを介して相互に通信することが可能な複数の通信端末T1,T2と、通信端末間で通信する際の接続開始処理を実行すると共に、通信端末間での通信に際し、通信端末との間でＲＴＰに基づいて送受信される通信データを制御するサーバＳｖとを有するＩＰ電話システムであって、接続開始処理が実行されて、通信端末間の通信接続が確立し、通信端末とサーバとの間でＲＴＰパケット化された通信データが送受信されている状態において、所定コマンドが入力されることにより、通信データの送信を中断する送信中断モードと、通信データの送信を再開する送信再開モードとに相互に切り替える制御を行う送受信データ制御手段を備える。【選択図】図１
2009049818.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して相互に通信することが可能な複数の通信端末と、
前記通信端末間で通信する際の接続開始処理を実行すると共に、前記通信端末間での通信に際し、当該通信端末との間でＲＴＰに基づいて送受信される通信データを制御するサーバとを有するＩＰ電話システムであって、
前記接続開始処理が実行されて、前記通信端末間の通信接続が確立し、前記通信端末と前記サーバとの間でＲＴＰパケット化された前記通信データが送受信されている状態において、
所定コマンドが入力されることにより、前記通信データの送信を中断する送信中断モードと、前記通信データの送信を再開する送信再開モードとに相互に切り替える制御を行う送受信データ制御手段を備えていることを特徴とするＩＰ電話システム。
【請求項２】
前記通信端末には、前記送受信データ制御手段として、前記モードを切り替えるためのコマンドが入力されることにより、前記通信データの前記送信中断モードと前記送信再開モードとを相互に切り替える制御を前記サーバに対して行う送受信データ制御部が設けられており、
前記サーバには、前記送受信データ制御手段として、前記通信端末の前記モード切替が行われた旨の通知コマンドが入力されることにより、前記通信端末に対して前記通信データの前記送信中断モードと前記送信再開モードとを相互に切り替える制御を行う送受信データ制御機能が付加されていることを特徴とする請求項１に記載のＩＰ電話システム。
【請求項３】
前記通知コマンドは、ＲＴＣＰの拡張イベントとして前記通信端末から前記サーバへ送信されていることを特徴とする請求項２に記載のＩＰ電話システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ(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間で通話接続が確立した状態(ＲＴＰ／ＲＴＣＰセッションが確立した状態)にあり、この状態において、通話装置Ｔ１とサーバＳｖとの間で音声データ送信モード切替のための制御が行われる場合を想定する。
【００４５】
接続開始処理の実行後、通話装置Ｔ１は、ＲＴＰパケットに音声データを付加(格納)し、当該パケットをサーバＳｖを介して相手側(着呼側)の通話装置Ｔ２に対して送信している(Ｅ１)。この場合の音声データには、日常の通話時に交わされる所定レベル以上の音声データ(以下、有音データという)の他、所定レベル以下の音声データ、例えば会話の合間に生じる無声データやユーザP1,P2の周囲で生じている雑音データなど(以下、これらを無音データという)も含まれている。
【００４６】
これにより、通話装置T1,T2間、すなわちユーザP1,P2の間で通話(会話)を行うことができる。通常は、かかる通話(会話)が終了するまで、サーバＳｖを介して当該通話装置T1,T2間で音声データの送受信が行われる。その一方で、ユーザP1,P2間(通話装置T1,T2間)での通話中、通話以外の別の事象(例えば来客、食事及びトイレなど)が生じ、当該通話をそのまま継続させることができず、一旦中断させなければならない状況となる場合もある。
このような場合、例えばユーザＰ１が通話装置Ｔ１を標準通話状態のまま上述したような別の事象に対処すると、その間も無音データは音声処理回路１２においてデジタル化され、ＲＴＰパケットに付加されてサーバＳｖへパケット送信され続けることとなり、通話装置Ｔ１のバッテリー(電池)を無駄に消費させる結果を招くこととなる。
【００４７】
そこで、本実施の形態においては、上述したような一旦開始された通話を中断させる必要が生じた場合、通話装置Ｔ１がすべての音声データ(有音データ及び無音データ)のパケット送信を中断すること、すなわち、通話装置Ｔ１を標準通話状態から送信中断モードへ切り替えることで、バッテリー(電池)の電力消費量を抑え、当該通話装置Ｔ１の低消費電力化を図っている。この場合、通話装置Ｔ１では、送受信データ制御部２７がマイク８から収音されて出力される音声信号のレベル(デシベル値、音量及び周波数など)を常時監視し、当該レベルが一定レベル(以下、基準レベルという)以下に低下した場合、音声データ送信モードを標準通話状態から送信中断モードへ切り替えるためのコマンド(モード切替コマンド)を自動生成し、当該モード切替コマンドを実行することで、サーバＳｖに対する音声データ(有音データ及び無音データ)のパケット送信を中断している。
【００４８】
なお、基準レベルは、ＩＰ電話システムの使用目的や使用環境などに応じて任意に設定すればよいため特に限定しないが、例えばマイク８から収音された無用な音声データ(無音データ)の出力レベルの状態(レベルの高低や出力時間など)を判定する際の閾値として設定すればよい。この場合、基準レベルは、予め固定的に設定してもよいし、通話時間やその時点でのバッテリー(電池)残量などに応じて任意に(段階的に)変動させて設定してもよい。
【００４９】
また、モード切替コマンドの生成及び実行は、上述したように送受信データ制御部２７がマイク８から収音されて出力される音声信号のレベル(デシベル値、音量及び周波数など)を常時監視し、当該音声信号の出力レベルが閾値(基準レベル)を下回って、そのまま所定時間経過したか否かを判定することにより自動的に行う構成の他、これに代えて、或いはこれに加えてユーザＰ１によって行われる明示的な動作(例えば、モード切替ボタンを押す動作やキーワード(意味のあるワード)の発声動作など)に基づいて、送受信データ制御部２７が受動的に(手動的に)行う構成であってもよい。
【００５０】
このような構成によれば、ユーザＰ１は、そのニーズに応じて、音声データ送信モードを標準通話状態から送信中断モードへ切り替えることができる。これにより、ユーザＰ１は、通話装置Ｔ１のモニタ(特に符号は付さない)に表示されるバッテリー(電池)残量のインジケータを確認し、当該残量が低下している場合のみならず、十分な残量がある場合であっても予め通話時間を見越してモード切替コマンドを生成実行させ、音声データ送信モードを標準通話状態から送信中断モードへ切り替えることで、バッテリー(電池)の消耗をより効果的に抑制することができる。
【００５１】
このように、通話装置Ｔ１において音声データ送信モードが標準通話状態から送信中断モードへ切り替えられた場合、当該通話装置Ｔ１は、音声データ送信モードの切替を行った旨を通知するためのＲＴＣＰパケットを無線ＬＡＮインターフェイス１８を介してサーバＳｖへ向けて送信する(Ｅ２)。その際、送受信データ制御部２７は、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に標準通話状態から送信中断モードへの切替を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。
【００５２】
これに対し、音声データ送信モード切替を通知するＲＴＣＰパケットを通話装置Ｔ１から受信したサーバＳｖは、通話装置Ｔ１における送信中断モードへの切り替えが行われたこと(すなわち音声データ送信の中断)を認識した場合、例えば通話装置Ｔ１からの音声データの送信が所定時間、途切れたことを検知した場合など、かかる中断を受け入れた旨を通知するためのＲＴＣＰパケットを通話装置Ｔ１へ向けて送信する(Ｅ３)。
【００５３】
その際、サーバＳｖは、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に標準通話状態から送信中断モードへの切替の受入を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。この場合、サーバＳｖ(図４)において、ＲＴＣＰパケット(ＡＰＰパケット)を生成する処理手順は、例えば当該処理手順を実行するためのプログラムをＲＯＭ４４に記憶し、その記憶したプログラムがＲＡＭ４６を作業領域としてＣＰＵ４８によって実行される。なお、サーバＳｖに対するプログラムのインストールに代えて、例えば同様の処理手順を実行するための回路系を新たにサーバＳｖに増設しても良い。
【００５４】
一方、音声データ送信の中断を認識できなかった場合、サーバＳｖは、通話装置Ｔ１から受信した音声データが付加(格納)されたＲＴＰパケットのシーケンス番号を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成し、当該パケットを通話装置Ｔ１に対して送信する。かかるパケットを受信した通話装置Ｔ１は、ＲＴＰパケットを一部欠落させた状態で通話を再開して継続させる。この場合には、一例として、通話装置Ｔ１が送信中断モードへの切替を再度行い、その旨を通知するＲＴＣＰパケット(ＡＰＰパケット)を生成してサーバＳｖに対して再送信する構成とすれば、確実に送信中断モードへの切替を行うことができる。その際、送信中断モードへの切替のリトライ制御(リトライする回数や間隔など)は、送受信データ制御部２７が行う構成とすればよい。
【００５５】
音声データ送信モード切替の受入を通知するＲＴＣＰパケットをサーバＳｖから受信した通話装置Ｔ１は、送受信データ制御部２７がすべての音声データ(有音データ及び無音データ)のＲＴＰパケット化を停止することで、当該パケットの送信を中断する。
これに対し、音声データ送信モード切替の受入を通知するＲＴＣＰパケットを通話装置Ｔ１に対して送信したサーバＳｖは、当該通話装置Ｔ１へ送信する音声データを所定レベル以上の音声データ(有音データ)に限定し、所定レベル以下の音声データ(無音データ)の送信を中断する音声データ送信モード(以下、サーバＳｖにおける当該モードも送信中断モードという)へ切り替え、有音データのみをＲＴＰパケット化して通話装置Ｔ１に対して送信する。
【００５６】
これにより、通話装置Ｔ１からサーバＳｖへのすべての音声データ(有音データ及び無音データ)の送信が中断され、当該音声データを送信する際の送信処理だけで無く、サーバＳｖから通話装置Ｔ１への音声データ(無音データ)の送信が中断され、当該音声データ送信された音声データを受信する際の受信処理を低減することができる。このため、通話装置Ｔ１のバッテリー(電池)の電力消費量を非常に効果的に低減させることができ、当該通話装置Ｔ１の低消費電力化を有効に図ることができる。この結果、通話装置Ｔ１を長期に亘って連続して使用することが可能となる。
なお、かかる低消費電力化の効果は、発呼側の通話装置Ｔ１のみに限定されるものではなく、着呼側の通話装置Ｔ２においても、通話装置Ｔ１からの音声データ(有音データ及び無音データ)の送信が中断されるため、その低消費電力化を図ることができる。
【００５７】
また、上述した構成においてサーバＳｖは、通話装置Ｔ１における送信中断モードへの切替が行われた旨を認識した場合、所定レベル以下の音声データ(無音データ)の送信のみを中断させているが、サーバＳｖ側での送信中断モードの設定時に送信を停止させるか否かの音声データのレベルは、ＩＰ電話システムの使用目的や使用環境などに応じて、例えば何らかの意味のある音声が入力されたか否か、或いは日常会話程度の音声のレベル(音声信号のデシベル値、音量及び周波数など)を有するか否かなどの基準に基づいて任意に設定すればよいため、ここでは特に限定しない。また、送信中断モードにおいては、サーバＳｖ側でも通話装置Ｔ１と同様に、すべての音声データ(有音データ及び無音データ)の送信を中断する構成であってもよい。
【００５８】
このように、本実施の形態によれば、音声データ送信モードの切替をＲＴＣＰパケット(ＡＰＰパケット)を送受信することによる通知によって行っているため、通常のデータストリーム(即ち、音声データの処理シーケンス)に影響されること無く、簡単に音声データ送信モードの切替を実行することができる。加えて、当該通知を受けた受信側(サーバＳｖ)で音声データ送信モード切替の要否を判定する構成、例えば判定の結果、通話装置Ｔ１における音声データ送信モードの切替を認めない(行わせない)構成などとすることも可能となる。さらに、音声データが付加(格納)されたＲＴＰパケットのシーケンス番号の連続性を確保することができるとともに、その確認を容易に行うことができる。
【００５９】
ここで、本実施の形態においては、標準通話状態から送信中断モードへの切替を行った後、必要に応じて送信中断モードから標準通話状態へ切り替える(復帰させる)ことができる。なお、送信中断モードからの切替後の標準通話状態を送信再開モードという。
通話装置Ｔ１において送信中断モードから送信再開モードへの切替(復帰)が行われた場合、当該通話装置Ｔ１は、音声データ送信モードの切替(復帰)を行った旨を通知するためのＲＴＣＰパケットを無線ＬＡＮインターフェイス１８を介してサーバＳｖへ向けて送信する(Ｅ５)。その際、送受信データ制御部２７は、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に送信中断モードから送信再開モードへの切替(復帰)を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。
この結果、通話装置Ｔ１は、サーバＳｖへのすべての音声データ(有音データ及び無音データ)の送信を再開させる。
【００６０】
なお、モード切替(復帰)コマンドの生成及び実行は、送受信データ制御部２７がマイク８から収音されて出力される音声信号のレベル(デシベル値、音量及び周波数など)を常時監視し、当該音声信号の出力レベルが閾値(基準レベル)を上回って、そのまま所定時間経過したか否かを判定することにより自動的に行えばよい。また、これに代えて、或いはこれに加えてユーザＰ１によって行われる明示的な動作(例えば、モード切替ボタンを押す動作やキーワード(意味のあるワード)の発声動作など)に基づいて、送受信データ制御部２７が受動的に(手動的に)行ってもよい。
【００６１】
これに対し、音声データ送信モード切替を通知するＲＴＣＰパケットを通話装置Ｔ１から受信したサーバＳｖは、通話装置Ｔ１における送信再開モードへの切り替えが行われたこと(すなわち音声データ送信の再開)を認識した場合、例えば所定時間内に通話装置Ｔ１からの音声データの送信を検知した場合など、かかる再開を受け入れた旨を通知するためのＲＴＣＰパケットを通話装置Ｔ１へ向けて送信する。
【００６２】
その際、サーバＳｖは、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に送信中断モードから送信再開モードへの切替の受入を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。この場合、サーバＳｖ(図４)において、ＲＴＣＰパケット(ＡＰＰパケット)を生成する処理手順は、例えば当該処理手順を実行するためのプログラムをＲＯＭ４４に記憶し、その記憶したプログラムがＲＡＭ４６を作業領域としてＣＰＵ４８によって実行される。なお、サーバＳｖに対するプログラムのインストールに代えて、例えば同様の処理手順を実行するための回路系を新たにサーバＳｖに増設しても良い。
そして、音声データ送信モード切替の受入を通知するＲＴＣＰパケットを通話装置Ｔ１に対して送信したサーバＳｖは、所定レベル以上の音声データ(有音データ)のみならず、所定レベル以下の音声データ(無音データ)もＲＴＰパケット化し、通話装置Ｔ１へのすべての音声データ(有音データ及び無音データ)の送信を再開させる。
【００６３】
なお、上述した標準通話状態から送信中断モードへの切替、並びに送信中断モードから送信再開モードへの切替は、通話装置Ｔ１からだけでなく、サーバＳｖから制御することもできる。この場合、サーバＳｖは、音声データ送信モードの切替を行う旨を通知するためのＲＴＣＰパケットを通話装置Ｔ１へ向けて送信する(Ｅ４，Ｅ６，Ｅ７)。
具体的には、標準通話状態から送信中断モードへの切替を行う場合、サーバＳｖは、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に標準通話状態から送信中断モードへの切替を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成し、通話装置Ｔ１へ送信する(Ｅ４，Ｅ７)。これに対し、送信中断モードから送信再開モードへの切替を行う場合、サーバＳｖは、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に送信中断モードから送信再開モードへの切替を通知するデータを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成し、通話装置Ｔ１へ送信する(Ｅ６)。
【００６４】
すなわち、サーバＳｖは、自ら主体的に標準通話状態から送信中断モードへの切替を行って、その旨を通話装置Ｔ１に通知することができ(Ｅ６)、さらにその後、所定レベル以上の音声データ(有音データ)を送信する必要が生じた場合(緊急時における一斉通報を行う場合など)には、送信中断モードから送信再開モードへの切替(復帰)を行い、その旨を通知することができる(Ｅ７)。これにより、通話装置Ｔ１とサーバＳｖとの間で必要に応じて標準通話状態(送信再開モード)と送信中断モードとの切替を相互に自由に行うことができる。
【００６５】
なお、上述した実施の形態では、所定レベル以上の音声データを有音データとし、所定レベル以下の音声データを無音データとして規定したが、これに限定されることは無く、他の基準に基づいて音声データのレベルを設定しても良い。例えば、音声データに有音データが所定量含まれている場合、これを所定レベル以上の音声データとし、一方、音声データに無音データが所定量含まれている場合、これを所定レベル以下の音声データとして規定しても良い。
【００６６】
この場合、サーバＳｖにおいて、かかる基準を満たすか否かの判定処理を行う必要があるが、例えば上述した送受信データ制御機能に更に判定機能を付加し、当該判定機能によって判定処理を実行し、その判定結果に基づいて、音声データ送信モードを切り替えるようにしても良いし、或いは、判定部(図示しない)を別途構築し、当該判定部によって判定処理を実行し、その判定結果に基づいて、音声データ送信モードを切り替えるようにしても良い。
【００６７】
また、音声データ送信モードの切替基準として、各中継装置1AP,2APの電波強度測定部２０によって取得された電波強度測定データや、当該データに基づいて特定される各通話装置T1,T2の位置などを加味し、これに基づいて、通話装置T1,T2とサーバＳｖとの間の音声データ送信モードを切り替えるようにしても良い。
【００６８】
このような切替基準により、標準通話状態(送信再開モード)と送信中断モードとの切替を相互に自由に行えることで、標準通話状態(送信再開モード)或いは送信中断モードを任意に選択することができ、通話装置Ｔ１の低消費電力化を図ることができるだけでなく、通話環境に応じて通話品質を自由に変更させることができる。例えば、周囲の雑音が多い場所などでは送信中断モードとしてバッテリー(電池)の消耗を防止しつつ、静粛な場所へ移動し、移動後には標準通話状態(送信再開モード)に切り替えることで、通話品質をより高めた状態で通話を継続させることが可能となる。
【図面の簡単な説明】
【００６９】
【図１】本発明の一実施の形態に係るＩＰ電話システムの構成を示す図であって、(ａ)は、通話装置間で通話が行われている状態を示すシステム全体概要図、(ｂ)は、音声データ送信モードの切替が行われる際のシーケンス図。
【図２】通話装置の内部構成を示す図。
【図３】中継装置の内部構成を示す図。
【図４】サーバの内部構成を示す図。
【符号の説明】
【００７０】
T1,T2  通話装置
６  サーバ
【図１】
2009049818.tif 000003
【図２】
2009049818.tif 000004
【図３】
2009049818.tif 000005
【図４】
2009049818.tif 000006