JP2009049819A

JP2009049819A - Ｉｐ電話システム

Info

Publication number: JP2009049819A
Application number: JP2007215340A
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との間の通話モードを保留モードから保留解除モード(通話状態)に切り替える。

以下、上述したＩＰ電話システムの通話モード切替の動作例について、図１(ｂ)を参照して説明する。なお、当該動作説明では、通話装置T1,T2間で通話接続が確立した状態(ＲＴＰ／ＲＴＣＰセッションが確立した状態)において、例えば一方の通話装置Ｔ２に第三者から外線が入ったことで、他方の通話装置Ｔ１とサーバＳｖとの間で通話モードの切替制御が行われる場合を想定する。

セッション確立状態において、通話装置T1,T2間では、音声データを付加(格納)した複数のＲＴＰパケットがサーバＳｖ及び中継装置1AP,2APを介して通話相手へ送信され復元されることにより、通話状態が継続している(Ｅ１)。この場合、音声データには、日常の通話時に交わされる所定レベル以上の音声データ(以下、有音データという)の他、所定レベル以下の音声データ、例えば会話の合間に生じる無声データやユーザの周囲で生じている雑音データなど(以下、これらを無音データという)も含まれている。

かかる通話状態において、一方の通話装置Ｔ２に第三者から外線が入ったとき、他方の通話装置Ｔ１は、一方の通話装置Ｔ２との通話(通信)状態が解除され、且つ、サーバＳｖとの間でのみ通信可能な状態となる。このとき、通話装置Ｔ１のユーザＰ１は、通話相手との通話(会話)を行うことは無いが、当該通話装置Ｔ１のマイク８(図２)には、例えばユーザＰ１以外の者が発声する種々雑多な有音データや、その他の無音データが混在した無用な音声データが収音され続ける。そして、通話装置Ｔ１では、収音した無用な音声データ(有音データ、無音データ)を音声処理回路１２(図２)でデジタル化し、これをＲＴＰパケットに付加してサーバＳｖに向けてパケット送信する処理が継続する。しかしながら、このような送信処理は、通話装置Ｔ１のバッテリー(電池)を無駄に消費させる結果を招くこととなる。

そこで、本実施の形態のＩＰ電話システムでは、上述したような状態が生じた際、通話装置Ｔ１が無用な音声データ(有音データ、無音データ)のパケット送信を中断すること、すなわち、通話装置Ｔ１を通話状態から保留モードへ切り替えることにより、バッテリー(電池)の電力消費量を抑え、当該通話装置Ｔ１の省電力化を図っている。なお、通話装置Ｔ１では、マイク８から収音されたすべての音声データのレベル(デシベル値、音量、周波数などの出力レベル)がセッション制御部２９によって常時監視されており、そのレベルが予め設定した基準レベルを下回ったとき、その旨を示す信号が通信モードを切り替えるためのコマンドとしてセッション制御部２９に入力される。このとき、セッション制御部２９では、通話モードを通話状態から保留モードに切り替えるモード切替要請を示す通知コマンドが生成される。

ここで、基準レベルは、ＩＰ電話システムの使用目的や使用環境に応じて任意に設定されるため特に限定しないが、例えばマイク８から収音された無用な音声データの出力レベルの状態(例えば、レベルの高低、出力時間など)を判定する際の閾値として、当該基準レベルを設定しても良い。この場合、セッション制御部２９は、例えば、マイク８から収音された音声データの出力レベルが当該閾値(基準レベル)を下回って、そのまま所定時間経過したとき、収音された音声データが無用なものと自動的に判定し、その判定結果に基づいて、モード切替要請を示す通知コマンドを自動生成する。なお、基準レベルは、例えばマイク８で収音可能な音声データに基づいて予め固定的に設定しても良いし、通話時間やその時点でのバッテリー(電池)残量などに応じて任意に(段階的に)設定しても良い。

また、通知コマンドの生成は、マイク８から収音された音声データのレベルをセッション制御部２９が常時監視して自動的に行う構成の他、これに代えて、或いはこれに加えてユーザＰ１によって行われる明示的な動作(例えば、モード切替ボタンを押す動作やキーワード(意味のあるワード)の発声動作など)に基づいて、セッション制御部２９が受動的に行うようにしてもよい。これにより、ユーザＰ１のニーズに応じて、通話モードを通話状態から保留モードに切り替えるモード切替要請を示す通知コマンドを生成することができる。この場合、ユーザＰ１は、例えば通話装置Ｔ１のモニタ(特に符号は付さない)に表示されるバッテリー(電池)残量のインジケータを確認し、当該残量が低下している場合のみならず、十分な残量がある場合であっても予め通話時間を見越して上記通知コマンドを生成させることができる。

このように、セッション制御部２９で生成された通知コマンドは、当該通話装置Ｔ１からＲＴＣＰパケットによって、無線ＬＡＮインターフェイス１８を介してサーバＳｖへ向けて送信される(Ｅ２)。その際、セッション制御部２９は、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に上記通知コマンドを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。

このとき、上記通知コマンドを受信したサーバＳｖは、セッション制御機能により、モード切替要請を受け入れた旨を通知するためのＲＴＣＰパケットを通話装置Ｔ１へ向けて送信する(Ｅ３)。その際、サーバＳｖは、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に上記通知コマンドを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。この場合、サーバＳｖ(図４)において、ＲＴＣＰパケット(ＡＰＰパケット)を生成する処理手順は、例えば当該処理手順を実行するためのプログラムをＲＯＭ４４に記憶し、その記憶したプログラムがＲＡＭ４６を作業領域としてＣＰＵ４８によって実行される。なお、サーバＳｖに対するプログラムのインストールに代えて、例えば同様の処理手順を実行するための回路系を新たにサーバＳｖに増設しても良い。

続いて、サーバＳｖは、自身のセッション制御機能により、前記確立したセッションを制御するための処理(ＳＩＰシーケンス処理)を実行し、当該通話装置T1,T2との間の通話モードを通話状態から保留モードに切り替える。この場合、ＳＩＰシーケンス処理は、サーバＳｖから通話装置Ｔ１に保留操作が行われる(Ｅ４)。すなわち、サーバＳｖから通話装置Ｔ１に「INVITE(保留)」が送信され、続いて、通話装置Ｔ１から「200
ok(成功応答)」を受信したとき、サーバＳｖから通話装置Ｔ１に「ACK(確認応答)」が送信される。これにより、サーバＳｖの通話装置Ｔ１に対する保留操作が完了し、これ以降、通話装置Ｔ１は、保留状態に維持される。

これにより、通話装置Ｔ１は、基準レベルを下回った無用な音声データをサーバＳｖに送信する送信処理だけで無く、サーバＳｖから送信された音声データの受信処理を無くすることができる。これにより、その分だけ、通話装置Ｔ１のバッテリー(電池)の電力消費量を低減させることができ、当該通話装置Ｔ１の低消費電力化を図ることができる。この結果、通話装置Ｔ１を長期に亘って連続して使用することが可能となる。

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

ここで、本実施の形態においては、通話装置Ｔ１の通話モードを通話状態から保留モードに切り替えた後、例えば当該通話装置Ｔ１のユーザＰ１のニーズに応じて、保留モードから保留解除モードに切り替えることにより、当該通話モードを通話装置T1,T2間での通話が可能な通話状態に復帰させることができる。ここで、通話状態に復帰させる方法としては、例えば、ユーザＰ１が通話装置Ｔ１のマイク８(図２)に向けて発した第一声(音声データ)のレベル(デシベル値、音量、周波数などの出力レベル)が、上述した基準レベル(閾値)に対して上回っているか、下回っているかの判定処理が実行される。かかる判定処理は、セッション制御部２９によって実行され、上回っていると判定された場合には、収音された音声データは有用なもの(意味のある通話・会話)と判定され、その判定結果に基づいて、通話モードを保留モードから保留解除モードに切り替えるモード切替要請を示す通知コマンドが自動生成される。

なお、下回っていると判定された場合には、収音された音声データは無用なものと判定され、通話装置Ｔ１は、保留状態に維持される。また、通話状態に復帰させる方法としては、上述したようにセッション制御部２９が自動的に通知コマンドを生成する構成の他、これに代えて、或いはこれに加えてユーザＰ１によって行われる明示的な動作(例えば、モード切替ボタンを押す動作やキーワード(意味のあるワード)の発声動作など)に基づいて、セッション制御部２９が受動的に通知コマンドを生成するようにしてもよい。

このように、セッション制御部２９によって生成された通知コマンド(通話状態に復帰させるモード切替要請コマンド)は、通話装置Ｔ１からＲＴＣＰパケットによって、無線ＬＡＮインターフェイス１８を介してサーバＳｖへ向けて送信される(Ｅ５)。その際、セッション制御部２９は、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に上記通知コマンドを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。

このとき、上記通知コマンドを受信したサーバＳｖは、セッション制御機能により、モード切替要請を受け入れた旨を通知するためのＲＴＣＰパケットを通話装置Ｔ１へ向けて送信する(Ｅ６)。その際、サーバＳｖは、ＲＴＣＰの拡張イベントとして、パケットタイプ値を２０４に設定するとともに、当該パケットのデータ格納部に上記通知コマンドを格納したＲＴＣＰパケット(ＡＰＰパケット)を生成する。この場合、サーバＳｖ(図４)において、ＲＴＣＰパケット(ＡＰＰパケット)を生成する処理手順は、例えば当該処理手順を実行するためのプログラムをＲＯＭ４４に記憶し、その記憶したプログラムがＲＡＭ４６を作業領域としてＣＰＵ４８によって実行される。なお、サーバＳｖに対するプログラムのインストールに代えて、例えば同様の処理手順を実行するための回路系を新たにサーバＳｖに増設しても良い。

続いて、サーバＳｖは、自身のセッション制御機能により、前記確立したセッションを制御するための処理(ＳＩＰシーケンス処理)を実行し、当該通話装置T1,T2との間の通話モードを保留モードから保留解除モードに切り替える。この場合、ＳＩＰシーケンス処理は、サーバＳｖから通話装置Ｔ１に保留解除操作が行われる(Ｅ７)。すなわち、サーバＳｖから通話装置Ｔ１に「INVITE(保留解除)」が送信され、続いて、通話装置Ｔ１から「200 ok(成功応答)」を受信したとき、サーバＳｖから通話装置Ｔ１に「ACK(確認応答)」が送信される。これにより、サーバＳｖの通話装置Ｔ１に対する保留解除操作が完了し、これ以降、通話装置Ｔ１は、通話状態(保留解除モード)に復帰・維持される。

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

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

また、通話モードの切替基準として、各中継装置1AP,2APの電波強度測定部２０によって取得された電波強度測定データや、当該データに基づいて特定される各通話装置T1,T2の状態などを加味し、これに基づいて、通話装置T1,T2とサーバＳｖとの間の通話モードを切り替えるようにしても良い。

このような切替基準により、保留モードと保留解除モードの切替を相互に自由に行えることで、ユーザＰ１のニーズに応じて保留モード或いは保留解除モードを任意に選択することができ、通話装置Ｔ１の低消費電力化を図ることができるだけでなく、通話環境に応じて通話品質を自由に変更させることができる。例えば、通話以外の別の事象(例えば、来客、食事及びトイレなど)が生じて、通話をそのまま継続させることができない場合、一時的に保留モードに切り替えることにより、通話装置Ｔ１のバッテリー(電池)の電力消費量を低減させることができ、当該通話装置Ｔ１の低消費電力化を図ることができる。この結果、通話装置Ｔ１を長期に亘って連続して使用することが可能となる。

更に、本実施の形態によれば、サーバＳｖ側から通話装置T1,T2の保留及び保留解除の操作を行うようにしたことにより、例えば交信可能範囲(エリア)外の通話装置T1,T2に対するセッションの制御不能を回避することができると共に、セッション制御部を持たない各種の通信端末に対する保留制御を実行することも可能となる。これにより、通信端末(通話装置)の種類を問わず、当該通信端末の低消費電力化を図ることができる。

(ａ)は、本発明の一実施の形態に係るＩＰ電話システムの構成例を示す図、(ｂ)は、保留モードと保留解除モードとの切替制御を行っている処理シーケンスを示す図。通話装置(通信端末)の構成を示す図。中継装置の構成を示す図。サーバの構成を示す図。

符号の説明

T1,T2 通信端末(通話装置)
Ｓｖサーバ

Claims

ネットワークを介して相互に通信することが可能な複数の通信端末と、
前記通信端末間で通信する際の接続開始処理を実行すると共に、前記通信端末間での通信に際し、当該通信端末との間でＲＴＰに基づいて送受信される通信データを制御するサーバとを有するＩＰ電話システムであって、
前記接続開始処理が実行されて、前記通信端末間で相互に通信を行うためのセッションが確立し、前記通信端末と前記サーバとの間でＲＴＰパケット化された前記通信データが送受信されている状態において、
所定コマンドが入力されることにより、前記サーバと前記通信端末との間で、前記確立したセッションを制御するための処理を実行し、当該セッションを一時的に中断させる保留モードと、前記保留モードを解除して前記中断させたセッションを再開させる保留解除モードとを相互に切り替えるセッション制御手段を備えていることを特徴とするＩＰ電話システム。
前記通信端末には、前記セッション制御手段として、前記モードを切り替えるためのコマンドが入力されることにより、前記保留モードと前記保留解除モードとを相互に切り替えるモード切替要請を前記サーバに対して行うセッション制御部が設けられており、
前記サーバには、前記セッション制御手段として、前記通信端末からの前記モード切替要請を示す通知コマンドが入力されることにより、前記確立したセッションを制御するための処理を実行し、前記保留モードと前記保留解除モードとを相互に切り替えるセッション制御機能が付加されていることを特徴とする請求項１に記載のＩＰ電話システム。
前記通知コマンドは、ＲＴＣＰの拡張イベントとして前記通信端末から前記サーバへ送信されていることを特徴とする請求項２に記載のＩＰ電話システム。