(57)【特許請求の範囲】
【請求項１】
呼制御及びＲＴＰ（Real−time Transport Protocol）制御を行う中継装置において、
前記ＲＴＰ制御による通信中に、予め定められた時間以上、ＲＴＰパケットを受信できていない状態か否かを検出する受信状況検出手段と、
前記受信状況検出手段が前記ＲＴＰパケットを前記予め定められた時間以上受信できていない状態であることを検出すると、相手装置との通信切断処理を実行する通信切断処理手段と、
相手装置と通信を行う際の前記呼制御のプロトコルによるメッセージを調べて、前記ＲＴＰ制御による通信が無音圧縮処理を施されたものであるか否かを検出する無音圧縮処理検出手段と、を備え、
前記通信切断処理手段は、前記受信状況検出手段により、前記ＲＴＰパケットを前記予め定められた時間以上受信できていない状態であることが検出されても、前記無音圧縮処理検出手段にて無音圧縮処理が施されたものであると検出した際には、前記相手装置との通信切断処理を実行しない、
ことを特徴とする中継装置。
【請求項２】
請求項１に記載の中継装置が組み込まれている、ことを特徴とする電話機。
【請求項３】
呼制御及びＲＴＰ（Real−time Transport Protocol）制御を行う中継装置の制御プログラムにおいて、
相手装置と通信を行う際の前記呼制御のプロトコルによるメッセージを調べて、前記ＲＴＰ制御による通信が無音圧縮処理を施されたものであるか否かを検出する無音圧縮処理検出ステップと、
前記ＲＴＰ制御による通信中に、予め定められた時間以上、ＲＴＰパケットを受信できていない状態か否かを検出する受信状況検出ステップと、
前記受信状況検出ステップで前記ＲＴＰパケットを前記予め定められた時間以上受信できていない状態であることを検出した場合であって、前記無音圧縮処理検出ステップにて前記ＲＴＰ制御による通信が無音圧縮処理を施されたものでないと検出した際に、通信切断処理を実行する通信切断処理ステップと、
を演算処理装置に実行させることを特徴とする中継装置の制御プログラム。
【請求項４】
呼制御及びＲＴＰ（Real−time Transport Protocol）制御を行う通信方法において、
相手装置と通信を行う際の前記呼制御のプロトコルによるメッセージを調べて、前記ＲＴＰ制御による通信が無音圧縮処理を施されたものであるか否かを検出する無音圧縮処理検出ステップと、
前記ＲＴＰ制御による通信中に、予め定められた時間以上、ＲＴＰパケットを受信できていない状態か否かを検出する受信状況検出ステップと、
前記受信状況検出ステップで前記ＲＴＰパケットを前記予め定められた時間以上受信できていない状態であることを検出した場合であって、前記無音圧縮処理検出ステップにて前記ＲＴＰ制御による通信が無音圧縮処理を施されたものでないと検出した際に、通信切断処理を実行する通信切断処理ステップと、
を有することを特徴とする通信方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、呼制御及びＲＴＰ（Real−time  Transport  Protocol）制御を行う中継装置、その制御プログラム、通信方法に関する。
【０００２】
【従来の技術】
ＴＴＣ標準のＨ．３２３規格に準拠した中継装置では、図４に示すように、ＲＴＰ通信中に、この中継装置に接続されている電話機からオンフック信号を受信すると、通信先の中継装置に対してリリースコンプリート・メッセージを送信する。この通信先の中継装置は、このリリースコンプリート・メッセージを受信すると、これに接続されている電話機等にビジートーン信号を出力する。
【０００３】
【発明が解決しようとする課題】
しかしながら、従来技術では、呼接続中に、通信先側の中継装置やネットワーク機器等が電源オフ等の障害が発生した場合、前述したように、通話者操作によるオンフックにて切断しない限り、無通信となり、呼の持ち切り状態が続いてしまうという問題点がある。
【０００４】
本発明は、このような従来の問題点に着目し、呼接続中に、通信先側の中継装置やネットワーク機器等が電源オフ等の障害が発生した場合でも、呼の持ち切りを回避することができる中継装置、その制御プログラム、通信方法を提供することを目的とする。
【０００５】
【課題を解決するための手段】
前記目的を達成するための中継装置は、
呼制御及びＲＴＰ（Real−time Transport Protocol）制御を行う中継装置において、
前記ＲＴＰ制御による通信中に、予め定められた時間以上、ＲＴＰパケットを受信できていない状態か否かを検出する受信状況検出手段と、
前記受信状況検出手段が前記ＲＴＰパケットを前記予め定められた時間以上受信できていない状態であることを検出すると、相手装置との通信切断処理を実行する通信切断処理手段と、
相手装置と通信を行う際の前記呼制御のプロトコルによるメッセージを調べて、前記ＲＴＰ制御による通信が無音圧縮処理を施されたものであるか否かを検出する無音圧縮処理検出手段と、を備え、
前記通信切断処理手段は、前記受信状況検出手段により、前記ＲＴＰパケットを前記予め定められた時間以上受信できていない状態であることが検出されても、前記無音圧縮処理検出手段にて無音圧縮処理が施されたものであると検出した際には、前記相手装置との通信切断処理を実行しない、ことを特徴とするものである。
【０００６】
ここで、前記中継装置による前記通信切断処理では、通信元側にビジートーン信号を出力してもよいし、通信先側に対して、リリースコンプリート・メッセージを出力してもよい。
【０００７】
また、前記前記予め定められた時間は、前記ＲＴＰパケットの最大多重処理時間を超える時間にしてもよい。また、前記ＲＴＰ制御による通信開始時に該通信における前記ＲＴＰパケットの多重処理時間を認識する多重処理時間認識手段と、該多重処理時間認識手段で認識された多重処理時間に応じて、前記予め定められた時間を定める判断時間設定手段を設けてもよい。
【０００９】
ここで、以上の各中継装置を電話機に組み込んでもよい。
【００１０】
また、前記目的を達成するための中継装置の制御プログラムは、
呼制御及びＲＴＰ（Real−time Transport Protocol）制御を行う中継装置の制御プログラムにおいて、
相手装置と通信を行う際の前記呼制御のプロトコルによるメッセージを調べて、前記ＲＴＰ制御による通信が無音圧縮処理を施されたものであるか否かを検出する無音圧縮処理検出ステップと、
前記ＲＴＰ制御による通信中に、予め定められた時間以上、ＲＴＰパケットを受信できていない状態か否かを検出する受信状況検出ステップと、
前記受信状況検出ステップで前記ＲＴＰパケットを前記予め定められた時間以上受信できていない状態であることを検出した場合であって、前記無音圧縮処理検出ステップにて前記ＲＴＰ制御による通信が無音圧縮処理を施されたものでないと検出した際に、通信切断処理を実行する通信切断処理ステップと、
を演算処理装置に実行させることを特徴とするものである。
【００１１】
また、前記目的を達成するための通信方法は、
呼制御及びＲＴＰ（Real−time Transport Protocol）制御を行う通信方法において、
相手装置と通信を行う際の前記呼制御のプロトコルによるメッセージを調べて、前記ＲＴＰ制御による通信が無音圧縮処理を施されたものであるか否かを検出する無音圧縮処理検出ステップと、
前記ＲＴＰ制御による通信中に、予め定められた時間以上、ＲＴＰパケットを受信できていない状態か否かを検出する受信状況検出ステップと、
前記受信状況検出ステップで前記ＲＴＰパケットを前記予め定められた時間以上受信できていない状態であることを検出した場合であって、前記無音圧縮処理検出ステップにて前記ＲＴＰ制御による通信が無音圧縮処理を施されたものでないと検出した際に、通信切断処理を実行する通信切断処理ステップと、
を有することを特徴とするものである。
【００１２】
【発明の実施の形態】
以下、本発明に係る通信システムの一実施形態について、図面を用いて説明する。
【００１３】
本実施形態における通信システムは、図１及び図２に示すように、ＬＡＮ回線２に接続されている中継装置１０と、この中継装置１０に接続されている電話機１と、を備えている。
【００１４】
中継装置１０は、ＦＸＳインタフェース１２とイーサネット（米国ゼロックス社の登録商標）インタフェース１１とを有している。ＦＸＳインタフェース１２には、ＶｏＩＰ（Voice  over  Internet  Protocol）ゲートウェイが搭載され、ここに電話機１が接続されている。また、イーサネットインタフェース１１には、前述したＬＡＮ回線２が接続されている。このＬＡＮ回線２の先には、ネットワーク機器等を介して、通信先側の中継装置１０及び電話機１が接続されている。ネットワーク機器は、基本的にルータで、その先にＷＡＮ（wide  Area  Network）を接続してもよいが、この実施形態では、説明の簡略化のために、ＨＵＢ３が接続されているものとする。
【００１５】
この中継装置１０は、図２に示すように、通信先側であるＬＡＮ回線２と接続される前述のイーサネットインタフェース１１と、通信元側である電話機１と接続される前述のＦＸＳインタフェース１２と、イーサネットインタフェース１１に入力した受信データを一時的に溜めておく受信バッファ１３と、各種制御プログラムや各種データ等を記憶しておくデータメモリ１４と、データメモリ１４に記憶されているプログラムに従って動作するＣＰＵ１５と、受信データのデコード処理等のディジタル信号処理を行うＤＳＰ（Digital  Signal  Processor）１６と、を備えている。なお、図２では、太い実線矢印で受信データの流れを示している。
【００１６】
データメモリ１４に記憶されている制御プログラム１４ａとしては、ＴＴＣ標準のＨ．３２３規格に準拠した、呼制御プロトコルであるＨ．２５５Ｑ９３１と、能力情報交換プロトコルであるＨ．２４５と、ＲＴＰと、本発明の特徴部分である自立切断プログラム等が搭載されている。この他、ゲートキーパと端末との制御プログラムであるＨ．２２５ＲＡＳを搭載し、ゲートキーパを設けてもよい。また、ＤＳＰ１６には、音声コーデックとしてＧ．７２９が搭載されている。
【００１７】
また、データメモリ１４に記憶されている構成情報設定データ１４ｂとしては、ＬＡＮ回線のＩＰアドレス、サブネットマスク、後述する無通信タイムアウト時間（判断時間）等がある。
【００１８】
なお、本実施形態において、受信状況検出手段は、無通信タイムアウト時間及び制御プログラムが記憶されているデータメモリ１４、及び制御プログラムを実行するＣＰＵ１５を有して構成される。また、通信切断処理手段、データメモリ１４、ＣＰＵ１５、さらに、ＣＰＵ１５からの指示でビジートーン信号を出力するＤＳＰ１６を有して構成される。
【００１９】
次に、呼制御プロトコルであるＨ．２５５Ｑ９３１による発信接続時のシーケンスについて、図３を用いて説明する。なお、同図中、向かって左側が発信側を示し、向かって右側が着信側を示している。
【００２０】
発信側の電話機から発信側の中継装置がダイヤルを受信すると、このダイヤルに対応したＩＰアドレスを調べて、このＩＰアドレスが設定されている着信側の中継装置へセットアップ・メッセージを送信する。
【００２１】
着信側の中継装置は、セットアップ・メッセージを受信すると、着信側の電話機に呼び出し信号を出力すると共に、発信側の中継装置へアラート・メッセージを送信する。発信側の中継装置は、アラート・メッセージを受信すると、発信側の電話機に呼待ち信号を出力する。その後、着信側の中継装置が、着信側の電話機からオフフック信号を受信すると、発信側の中継装置へコネクト・メッセージを送信する。この結果、メディアチャンネルがオープンされ、中継装置相互間のＲＴＰ通信が確立し、電話機相互間での通話が可能になる。なお、ここでは、メディアチャンネルのオープンをコネクト・メッセージの受信で行っているが、アラート・メッセージの受信で行うようにしてもよい。また、着信側の中継装置は、セットアップ・メッセージを受信すると、アラート・メッセージを送信する前に、コールプロシーディング・メッセージを送信するようにしてもよい。
【００２２】
次に、Ｈ．２５５Ｑ９３１による切断時のシーケンスについて、図４を用いて説明する。
【００２３】
従来技術で説明したように、ＲＴＰ通信中に、例えば、発信側の中継装置が電話機からオンフック信号を受信すると、着信側の中継装置に対してリリースコンプリート・メッセージを送信する。着信側の中継装置は、このリリースコンプリート・メッセージを受信すると、これに接続されている電話機にビジートーン信号を出力する。その後、着信側の電話機からオンフック信号を受信すると、発信側の中継装置へリリースコンプリート・メッセージを返す。
【００２４】
次に、図２を用いて、呼接続完了後の音声データの受信処理について説明する。
【００２５】
イーサネットインタフェース１１が音声データを受信すると、これを受信バッファ１３の受信パケットデータバッファ１３ａに順次溜める。この音声データは、レイヤ２のデータとしてイーサネットのフレームとして読み込まれたデータであるが、制御プログラムを実行するＣＰＵにより、ＩＰ（Internet  Protocol），ＵＤＰ（User  Datagram  Protocol），ＲＴＰパケットのレイヤまで解析される。なお、ここでは、音声データにＵＤＰを用い、その上でＲＴＰにより音声通信を実現している。ＣＰＵ１５は、音声データからＲＴＰパケットを解析すると、このＲＴＰパケットを揺らぎ吸収バッファ１３ｂに溜める。この揺らぎ吸収バッファ１３ｂは、指定量のＲＴＰパケットを一時的に溜めて再生するＦＩＦＯバッファであり、ネットワークからの揺らぎを吸収するためのものである。この揺らぎ吸収バッファ１３ｂに一時的に溜められたＲＰＴパケットは、一定周期（１０ｍｓ）毎にＤＳＰ１６に取り込まれ、ここで、Ｇ．７２９コーデックのデコード処理が施され、ＦＸＳインタフェース１２を通じてアナログ音声に再生されて、電話機１で音声を聞き取れるようになる。
【００２６】
次に、図５に示すフローチャートに従って、自立切断プログラムによるＣＰＵ１５の動作について説明する。
【００２７】
ＣＰＵ１５は、まず、能力情報等が含まれているセットアップ・メッセージ中に、音声圧縮処理の有情報が含まれているか否かを調べ、無音声圧縮処理の有情報が含まれていれば、無音声圧縮処理の有無フラグを１にする（ステップ１）。次に、ＲＴＰ通信が開始されたことを確認すると（ステップ２）、無通信タイマを０にリセットしてから時間計測を開始し（ステップ３）、ＲＴＰパケットを受信したか否かを調べる（ステップ４）。ＲＴＰパケットを受信していれば再び無通信タイマをリセットし（ステップ５）、前述した制御プログラムによるＲＴＰパケットの受信処理を実行させ（ステップ６）、ステップ４に戻る。
【００２８】
ステップ４で、ＲＴＰパケットを受信していないことが分かると、無通信タイマで計測した時間がデータメモリ１４に記憶されている無通信タイムアウト時間（判断時間）以上になっているか否かを判断し（ステップ７）、無通信タイムアウト時間以上になっていれば、無音声圧縮処理の有無をフラグで調べて（ステップ８）、このフラグが０、つまり、受信データに対して無音声圧縮処理が施されていないと判断すると、ネットワーク機器等に障害が生じたものとして、切断処理を実行し、電話機１に対してＤＳＰ１６からビジートーン信号を出力させる（ステップ９）。通話者は、電話機１からビジートーンを聞くと、通信が切断されたことを認識し、受話器をオンフック状態にする。中継装置１０は、図４を用いて前述したように、電話機１からオンフック信号を受信すると、通信相手側の中継装置１０にリリースコンプリート・メッセージを送信する。なお、この切断処理では、電話機１に対するビジートーン信号を出力と共に、電話機からのオンフック信号を待たずに通信相手側の中継装置にリースコンプリート・メッセージを送信するようにしてもよい。
【００２９】
ステップ８で、無音声圧縮処理の有無フラグが１、つまり、音声データに対して音声圧縮処理が施されていると判断すると、この無通信は無音声状態が続き、この無音声に対して圧縮処理を行っている結果で、ネットワーク機器等の障害によるものではないとして、切断処理を行わなず、ステップ１０に進む。
【００３０】
ステップ７で、無通信タイマで計測した時間が無通信タイムアウト時間以上になっていないと判断した場合、及び、ステップ８で、無音声圧縮処理の有無フラグが１であると判断した場合、呼接続中が否かを判断し（ステップ１０）、呼接続中であればステップ４に戻り、呼接続中でなければ終了する。
【００３１】
以上のように、本実施形態では、通信先側の中継装置１０やネットワーク機器等が電源オフ等の障害が発生した場合でも、呼接続中、ＲＴＰパケットの受信状況を監視し、一定時間以上、ＲＴＰパケットを受信できない場合には、自立的に切断を実行しているので、呼の持ち切りを回避することができる。
【００３２】
ところで、本実施形態では、無通信タイムアウト時間をＲＴＰパケットの受信間隔の最大時間に基づいて定めている。この最大時間は、ＩＰパケット中にＲＴＰパケットをいくつ多重化するかに関係する。ＲＴＰパケットは、１０ｍｓの音声データで、Ｇ．７２９コーデックでＲＴＰパケットをＩＰパケットに多重化する場合、図６に示すように、多重数に１０ｍｓを掛けた時間が多重処理時間となる。現状で、最大多重数は２０であることから、最大多重時間は２００ｍｓとなる。
【００３３】
本実施形態では、この最大多重時間２００ｍｓと、ネットワーク内の揺らぎとを考慮して、無通信タイムアウト時間を５ｓ、またはそれ以上に設定している。
【００３４】
なお、ここでは、無通信タイムアウト時間は固定値であるが、ＲＴＰパケットの多重処理時間に応じて定めるようにしてもよい。この場合、ＲＴＰパケットのヘッダを見て、このヘッダから多重数又は多重処理時間を認識し、この多重処理時間に対して予め定められたルールに従って、無通信タイムアウト時間を定めるようにするとよい。この無通信タイムアウト時間を定めるルールとしては、例えば、多重処理時間が１００ｍｓ以下の場合には、無通信タイムアウト時間を４ｓに、多重処理時間が１００ｍｓを超える場合には、無通信タイムアウト時間を６ｓに設定する等が考えられる。
【００３５】
また、以上の実施形態では、中継装置１０に電話機１を直接接続した例であるが、ＰＢＸ（Private  Branch  Exchange：構内交換機）や、公衆網等を介して、電話機１を接続してもよい。これらの場合、前述したステップ９の切断処理では、単に、ＰＢＸや公衆網との間の切断処理を行うのみで、中継装置から電話機にビジートーン信号を出力しない。これは、ＰＢＸや公衆網との間の切断処理が行われると、ＰＢＸや公衆網側が電話機に対してビジートーン信号を出力するからである。
【００３６】
また、以上の実施形態では、電話機１と中継装置１０とは別体であるが、ＲＴＰ通信が可能な電話機として、電話機内に以上の中継装置を組み込むようにしてもよい。
【００３７】
【発明の効果】
本発明によれば、通信先側の中継装置やネットワーク機器等が電源オフ等の障害が発生した場合でも、呼接続中、ＲＴＰパケットの受信状況を監視し、一定時間以上、ＲＴＰパケットを受信できない場合には、自立的に切断処理を実行しているので、呼の持ち切りを回避することができる。
【図面の簡単な説明】
【図１】本発明に係る一実施形態における通信システムの構成を示す説明図である。
【図２】本発明に係る一実施形態における中継装置の回路ブロック図である。
【図３】呼制御プロトコルであるＨ．２５５Ｑ９３１による発信接続時のシーケンスを示す説明図である。
【図４】呼制御プロトコルであるＨ．２５５Ｑ９３１による切断時のシーケンスを示す説明図である。
【図５】本発明に係る一実施形態における自立切断プログラムによるＣＰＵの動作を示すフローチャートである。
【図６】ＲＴＰパケットの多重数と多重処理時間との関係を示す説明図である。
【符号の説明】
１…電話機、２…ＬＡＮ回線、３…ＨＵＢ、１０…中継装置、１１…イーサネットインタフェース、１２…ＦＸＳインタフェース、１３…受信バッファ、１４…データメモリ、１５…ＣＰＵ、１６…ＤＳＰ。
【図１】
0003874641.tif 000002
【図２】
0003874641.tif 000003
【図３】
0003874641.tif 000004
【図４】
0003874641.tif 000005
【図５】
0003874641.tif 000006
【図６】
0003874641.tif 000007