JP2011097469A - 電話システムとその交換装置 - Google Patents

Abstract

【課題】メディアサーバのリソースコストを抑えつつＩＰ電話機に十分なサービスを提供できるようにすること。
【解決手段】メディアサーバおよびＩＰ交換機をそれぞれ備える複数のノードを通信網としての専用線ネットワーク１００を介して相互接続した電話システムにおいて、交換装置に、自ノードにおけるメディアサーバのリソースの残量を把握する把握手段を備える。そして、専用線ネットワーク１００を介してノード間に呼が生じた場合に、呼の着信先ノードにおけるメディアサーバのリソースの残量があれば、着信先ノードにおけるメディアサーバのリソースから発信元の電話端末に対してトーン信号を送信するように制御するようにした。
【選択図】 図３

Description

この発明は、メディアサーバを備える電話システムと、その交換装置に関する。

ＩＰ（Internet Protocol）ネットワークを利用する近年の電話システムには、メディアサーバを使用して音声通信に係わる種々サービスを提供するものがある。メディアサーバは電話システムの交換装置などに接続され、交換装置に対する補助的な機能を提供する。例えば回線のスイッチングといった交換接続に係わる基本的な処理機能は交換装置により実施され、ビジートーン等の発信元などへ送信される音声やトーン信号は、メディアサーバにより発生され、送信される。

現実のシステムでは、ＩＰ電話機、ＩＰ交換機およびメディアサーバをそれぞれ備える複数のＬＡＮ（Local Area Network）を、ＩＰ専用線によるネットワークシステムを介して相互接続する形態が一般的である。ＩＰ電話機により生成された呼や種々の処理要求に対し、メディアサーバのリソース（音声やトーン信号を発生させるための回路、あるいはポートなど）を使用することで多種多様なサービスを提供することができる。しかしながらメディアサーバに多くのリソース（例えば十分な数の通信ポート）を用意しておかなくてはならず、リソースコストの上昇を招きやすい。

関連する技術が特許文献１に開示される。この文献には、プレゼンス情報及び呼制御設定条件情報に応じて呼制御サーバを制御することで、発信元のユーザ及び着信側のユーザを煩わせることなくユーザの状況に応じた呼制御を実現しようとする技術が開示される。

特開２００８−２８７７０号公報

以上述べたようにメディアサーバを備える既存の電話システムでは、メディアサーバに多くのリソースを用意しておかなくてはならず、リソースコストが上昇する。仮にメディアサーバのリソースが枯渇すればＩＰ電話機へのサービスを継続して提供することができなくなるので何らかの対処が望まれる。

この発明は上記事情によりなされたもので、その目的は、メディアサーバのリソースコストを抑えつつＩＰ電話機に十分なサービスを提供することの可能な電話システムとその交換装置を提供することにある。

上記目的を達成するためにこの発明の一態様によれば、電話端末と、交換装置と、トーン信号を発生するメディアサーバとが接続される複数のノードを通信網を介して相互接続して形成される電話システムにおいて、前記交換装置は、自ノードにおける前記メディアサーバのリソースの残量を把握する把握手段を備え、前記通信網を介してノード間に呼が生じた場合に、前記呼の着信先ノードにおけるメディアサーバのリソースの残量があれば、当該着信先ノードにおけるメディアサーバのリソースから発信元の電話端末に対してトーン信号を送信するように制御することを特徴とする電話システムが提供される。

このような手段を講じることにより、メディアサーバのリソースを使用してサービスを提供するにあたり、メディアサーバリソースの使用状態に応じてＩＰ交換機間の呼制御メッセージが適応的に切り替えられる。従って、着信先ノードあるいは発呼元ノードのいずれのメディアサーバに接続した場合でも、電話端末に対して常に同等のサービスを提供することが可能になる。

この発明によれば、メディアサーバのリソースコストを抑えつつＩＰ電話機に十分なサービスを提供することの可能な電話システムとその交換装置を提供することができる。

本発明の第１の実施の形態に係わる電話システムの実施の形態を示すシステム図。 本発明の第１の実施の形態に係わるメディアサーバのリソースを要求する際に、着側ノードのリソースに余裕のある状態での処理手順を示すシーケンス図。 本発明の第２の実施の形態に係わるメディアサーバのリソースを要求する際に、着側ノードのリソース残量が少ない状態での処理手順を示すシーケンス図。 端末情報管理テーブルに登録される内容の一例を示す図。 着側ノードのリソース残量の少ない状態で発側ＩＰ電話機がトーン信号の送出機能を備える場合の処理手順の一例を示すシーケンス図。 着側ノードのリソース残量の少ない状態で発側ＩＰ電話機がトーン信号の送出機能を備える場合の処理手順の他の例を示すシーケンス図。

［第１の実施形態］
図１は、この発明に係わる電話システムの第１の実施の形態を示すシステム図である。このシステムは、メディアサーバおよびＩＰ交換機をそれぞれ備える複数のローカルネットワーク（ＬＡＮ：Local Area Network）Ｌ１〜Ｌｎを通信網としての専用線ネットワーク１００を介して相互接続したものである。ネットワークＬ１〜Ｌｎを、それぞれノード（Node）と称する。
ＩＰ交換機はＬＡＮごとに設けられ、複数のＩＰ電話機を収容する。また、ＩＰ電話機に対する保留音や各種サービストーンを供給するメディアサーバがＩＰ交換機ごとに接続される。

例えばＬＡＮ Ｌ１においては、ＩＰ交換機１とメディアサーバ１−１とが接続される。ＩＰ交換機１にはＩＰ電話機１−２が収容されている。もちろん図示した数に限らず多数のＩＰ電話機がＩＰ交換機に収容されることが可能である。他のＬＡＮ Ｌ２〜Ｌｎにおいても同様の構成となっている。

ところで、ＩＰ交換機１は、ＩＰ電話制御部１−３、呼制御部１−４、ＩＰ専用線制御部１−５、メディアサーバ管理部１−６、番号分析部１−７、番号分析テーブル１−８、番号蓄積テーブル１−９、および端末情報管理テーブル１−１０を備える。
ＩＰ電話制御部１−３はＩＰ電話機に接続され、ＩＰ電話機との間での呼制御メッセージの授受に係わる制御を行う。番号分析部１−７は、ＩＰ電話制御部１−３からの発信要求に含まれる入力番号を、番号分析テーブル１−８を参照して分析する。分析の結果はＩＰ電話制御部１−３に通知される。分析の結果、他のＬＡＮに属するＩＰ電話機への発信要求であれば、呼制御部１−４は、ＩＰ交換機内部での呼制御に係わる制御を実施する。ＩＰ専用線制御部１−５は、着信先のＩＰ電話機を収容するノード（ＬＡＮ）との間で、各種の呼制御メッセージを授受する。メディアサーバ管理部１−６は、メディアサーバのリソース使用状態を管理し、特に残リソースの有無を把握する。

番号分析部１−７は、ＩＰ電話機からの入力ダイヤルを番号分析テーブル１−８を参照して分析する。番号分析テーブル１−８は、ダイヤル番号と要求される機能との対応関係を登録したテーブルである。番号蓄積テーブル１−９は、ＩＰ電話機ごとに、入力されたダイヤル番号を一時的に格納する。つまり番号蓄積テーブル１−９は、入力された最新のダイヤル番号をＩＰ電話機ごとに記憶する。

端末情報管理テーブル１−１０は、端末ＩＤ（ＩＰアドレスまたはＭＡＣ（Media access control）アドレスなど）とその内線番号、トーン送出機能の有無、あるいは送出できるダイヤル信号の種類などをＩＰ電話機ごとに登録したテーブルである。

図１においては、呼がＩＰ専用線ネットワークを経由して異なるＬＡＮ間で接続される場合がある。このようなケースにおいてメディアサーバのリソースを使用する際、発側ＩＰ端末と同じＬＡＮに属するメディアサーバ（発側ノード側）を使用するか、着側ＩＰ端末と同じＬＡＮに属するメディアサーバ（着側ノード側）を使用するかを決める必要がある。この実施形態では、着側ノードのメディアサーバのリソースに余裕のある限り、着側ノードのメディアサーバを使用することとする。

図２は、メディアサーバのリソースを要求する際に、着側ノードのリソースに余裕のある状態での処理手順を示すシーケンス図である。ＩＰ交換機間で用いられる呼接続プロトコルには、ＳＩＰ（Session Initiation Protocol）あるいはＱＳＩＧなどを用いることができるが、以下ではＳＩＰを用いる場合につき説明する。

なおＳＩＰを用いるシステムでは、ログインと称する手順により各ＩＰ電話機がシステムに登録される。登録にあたってはＩＰ電話機の端末ＩＤと内線番号、およびユーザ名などが対応付けられ、データベース（端末情報管理テーブル１−１０）に登録される。

図２ではＬＡＮ Ｌ１のＩＰ交換機１を発側ノード（ノード番号（１０））とし、ＬＡＮ Ｌ２のＩＰ交換機２を着側ノード（ノード番号（２０））とする。着側ノード（ＩＰ交換機２）は図１のＩＰ交換機１と同様の機能ブロックであるＩＰ電話制御部２−３、呼制御部２−４、ＩＰ専用線制御部２−５、メディアサーバ管理部２−６、番号分析部２−７、番号分析テーブル２−８、および番号蓄積テーブル２−９を備える。

ＩＰ電話機１−２はネットワークに接続されると、ＩＰ交換機１にログイン要求を送出する。ＩＰ交換機１のＩＰ電話制御部１−３は、受信したログイン要求に含まれるＩＰ電話機１−２の端末情報（内線番号、ＩＰアドレスなどのログイン元ＩＰ電話機に関する情報）を、端末情報管理テーブル１−１０に登録する。

このような状態で、以下では、発側ノードに接続されるＩＰ電話機１−２から、着側ノードに収容されるＩＰ電話機（番号：２０００）への発呼が生じたケースを想定する。ユーザがＩＰ電話機１−２において相手先番号“２０００”の入力を伴う発信操作を行うと（ステップＳ１）、番号“２０００”をセットされた発信要求がＩＰ電話制御部１−３に送信される（ステップＳ２）。これを受けたＩＰ電話制御部１−３は、相手先番号“２０００”を含む分析要求を番号分析部１−７に対して通知する（ステップＳ３）。

番号分析部１−７は相手先番号“２０００”をキーとして番号分析テーブル１−８を参照し、相手先番号種別および相手ノード番号を取得する（ステップＳ４）。ここでは相手先番号種別として（専用線接続）が取得され、相手ノード番号として（２０）が取得される（ステップＳ５）。この結果はＩＰ電話制御部１−３に通知される（ステップＳ６）。さらに、相手先番号“２０００”は番号蓄積テーブル１−９に登録される（ステップＳ７）。

ＩＰ電話制御部１−３は、番号分析部１−７の処理結果に基づいて、相手ノード番号（２０）および入力ダイヤル“２０００”を合わせたパラメータ“２０２０００”を着信先ＵＲＩ（Uniform Resource Indicator）としてセットした専用線接続要求を、呼制御部１−４に対して送信する（ステップＳ８）。これを受けた呼制御部１−４は、ＩＰ専用線制御部１−５に対して着信要求を送信する（ステップＳ９）。そうするとＩＰ専用線制御部１−５は、着側ノード（２０）に対しＩＮＶＩＴＥメッセージを送信する（ステップＳ１０）。

着側ノード（２０）のＩＰ専用線制御部２−５は、ＩＮＶＩＴＥメッセージを受信すると、当該ＩＮＶＩＴメッセージにセットされたパラメータ“２０２０００”を番号分析部２−７に通知する（ステップＳ１１）。番号分析部２−７は、“２０２０００”をキーとして番号分析テーブル２−８を参照し（ステップＳ１２）、相手先番号種別（内線接続）とその着信先番号“２０００”とを取得する（ステップＳ１３）。これらの情報は番号分析部２−７からＩＰ専用線制御部２−５に通知される（ステップＳ１４）。そして、ＩＰ専用線制御部２−５は、発側ノード（１０）に向けて、１００ Ｔｒｙｉｎｇを返信する（ステップＳ１５）。

更に、ＩＰ電話制御部２−５は、番号分析部２−７から通知された情報をもとに、呼制御部２−４に対して着信先ダイヤル（２０００）をパラメータとしてセットした内線接続要求を送信する（ステップＳ１６）。このとき、着信端末２０００が、他端末と通話中等の理由で空き状態でない場合には、呼制御部２−４はＩＰ専用線制御部２−５に対して接続拒否を返送する（ステップＳ１７）。

この状態では、発信元に着側ｂｕｓｙを示す話中音（Busy Tone：ＢＴ）を供給する必要があるので、以下、メディアサーバのリソースを利用するための処理が開始される。すなわちＩＰ電話制御部２−５は、発側ノードのＩＰ電話機１−２に対してビジートーンＢＴを供給するために、メディアサーバ管理部２−６にリソース接続要求を送信する（ステップＳ１８）。このリソース接続要求には、（トーン種別：ＢＴ、ＤＴＭＦ（Dual Tone Multi Frequency）受信：要）なるパラメータがセットされる。

ここで、メディアサーバのリソースとは主に、ＩＰ電話機との間にセッションを形成するために必要となる論理通信ポートを意味し、その数には限りがある。このほか、ＣＰＵ（Central Processing Unit）の処理能力、メモリ容量などの概念も含んでよい。

そうするとメディアサーバ管理部２−６は、ビジートーン発生とＤＴＭＦ信号受信に必要な空きリソースをハントしたのち、着側ノード（２０）のメディアサーバ２−１に対してリソース接続指示（トーン種別：ＢＴ、ＤＴＭＦ受信：要）を送信する（ステップＳ１９）。この指示を受けたメディアサーバ２−１は、確保されたリソースを用いてビジートーンＢＴを供給するとともにＤＴＭＦの受信待ちとなる（ステップＳ２０）。

またメディアサーバ管理部２−６は、メディアサーバ２−１のリソース情報（ＩＰアドレス、ポート番号）を設定したリソース接続受付をＩＰ専用線制御部２−５に通知する（ステップＳ２１）。この通知を受けたＩＰ専用線制御部２−５は、発側ノード（１０）に対して１８３ Ｓｅｓｓｉｏｎ Ｐｒｏｇｒｅｓｓ ＳＤＰ（ＭＳ）を送信する（ステップＳ２２）。

これを受けた発側ノード（１０）のＩＰ専用線制御部１−５は、着側ノード（２０）のメディアサーバ２−１との双方向接続を要求する呼出通知を呼制御部１−４に与える（ステップＳ２３）。この通知は呼制御部１−４からＩＰ電話制御部１−３を経てＩＰ電話機１−２に達する（ステップＳ２４，Ｓ２５）。そうすると発側ノード（１０）のＩＰ電話機１−２と着側ノード（２０）の着側ノード（２０）のメディアサーバ２−１との間でセッションが確立され、ＩＰ電話機１−２のユーザはメディアサーバ２−１からのビジートーンＢＴを聴取する（ステップＳ２６）。このビシートーンを聴取することで、ユーザは着信先が話中であることを認識する。

なお、ＩＰ交換機により提供される規定のサービスとして、話中呼出、通話割込、メッセージウェイティングなどがある。ＩＰ電話機１−２のユーザは、話中呼出、通話割込、メッセージウェイティングなどの規定サービスを希望する場合は、ビジートーンＢＴを聴取している状態で、所望のサービスに対応したサービス起動特番をＩＰ電話機１−２から入力する。

そうすると、ＩＰ電話機１−２では入力されたサービス特番に対応したＤＴＭＦ信号を発生し、前記確立したセッションを介して、着側のメディアサーバ２−１に送信する。メディアサーバ２−１は専用線ネットワーク１００経由でＤＴＭＦ信号を受信すると、着側ノード（２０）の番号分析部２−７にその内容の分析を依頼する。その結果に応じて、ＩＰ交換機２は、着側ノード（２０）により提供されるサービス（話中呼出、通話割込など）が起動されることとなる（ステップＳ２７）。

以上のシーケンスでは、着側ノード（２０）におけるメディアサーバ２−１のリソースに余裕があるので、着信側のメディアサーバ２−１のリソースが消費される。ここで、本実施の形態では、着信側端末がビジーの場合、着信側のメディアサーバのリソースを使用して、トーン信号を発生するようにしている。ここで、着信側のメディアサーバを使うことにより、よって専用線ネットワーク１００を跨ぐセッションを継続して接続しておくことが可能になる。

このため、例えば着信側の話中が解消した場合、メディアサーバから発信元に呼出音（Ring Back Tone）を送出できるため、発信元のユーザが話中が解消されたことを認識できる。

［第２の実施形態］
前記第１の実施形態では以上の手順を実施するには、システムにおけるトラフィックを考慮して、全てのメディアサーバに対して充分なリソースを確保する必要がある。つまりシステムを構成するノード数、あるいは各ＩＰ交換機に接続されるＩＰ電話機の台数を考慮したうえでメディアサーバに多数のリソースを予め用意する必要があり、リソースコストが上昇する虞がある。例えば着側ノード（２０）のメディアサーバ２−１の通信ポートが全て消費されているなどの状態では使用可能なリソースが枯渇した状態となり、メディアサーバ２−１からのサービスを受けることができなくなる。このような状態では発側ＩＰ電話機１−２には何らのトーンも送出されなくなり、ユーザにとっては不便であるばかりか呼が切断される可能性も有る。以下ではこのような事態に対処可能な実施形態につき説明する。

この実施形態では、着側ノードのリソース残量の少ない状態での処理手順につき説明する。
図３は、メディアサーバのリソースを要求する際に、着側ノードのリソース残量の少ない状態での処理手順を示すシーケンス図である。図３の手順は、着ノード側メディアリソースが枯渇している状態での対応を示すものである。図３において図２と同じ処理には共通のステップ番号を付して示し、以下では異なる手順についてのみ説明する。なおシーケンス初期の番号分析部１−７，２−７による処理（ステップＳ３〜Ｓ７、ステップＳＳ１１〜Ｓ１４）は図２と同様であり、繁雑を避けるため図示と説明を省略する。

ステップＳ１８において、着側ノード（２０）のＩＰ専用線制御部２−５からメディアサーバ管理部２−６に対してリソース接続要求が送信されると、空きリソースの無いことを反映して、メディアサーバ管理部２−６からＩＰ専用線制御部２−５に対してリソース接続拒否が返送される（ステップＳ３０）。これを受けてＩＰ専用線制御部２−５は、発側ノード（１０）に対して４８６ Ｂｕｓｙ Ｈｅｒｅを送信する（ステップＳ３１）。この４８６ Ｂｕｓｙ Ｈｅｒｅを受信した発側ノード（１０）のＩＰ専用線制御部１−５は、着信拒否メッセージを呼制御部１−４を経てＩＰ電話制御部１−３に送信する（ステップＳ３２，Ｓ３３）。これにより発側ノード（１０）および着側ノード（２０）の間にはセッションが確立されない。

４８６ Ｂｕｓｙ Ｈｅｒｅメッセージは、ＩＮＶＩＴＥメッセージに対するエラーレスポンスである。これを受信した発側ノード（１０）は着側端末が話中状態と認識し、ＩＰ電話機１−２に着信先ｂｕｓｙを示すビジートーン（ＢＴ）を供給するための処理を開始する。

すなわち、発側ノード（１０）のＩＰ電話制御部１−３は、メディアサーバ管理部１−６にリソース接続要求（トーン種別：ＢＴ、ＤＴＭＦ受信：要）を送信する（ステップＳ３４）。つまりリソース接続要求は専用線ネットワーク１００に送出されることなく、発側ノード（１０）内のローカルで処理される。この要求を受けたメディアサーバ管理部１−６は、空きリソースをハントしたのち発側のメディアサーバ１−１に対してリソース接続指示（トーン種別：ＢＴ、ＤＴＭＦ受信：要）を送信する（ステップＳ３５）。この指示を受けたメディアサーバ１−１は、確保されたリソースを用いてビジートーンＢＴを供給するとともにＤＴＭＦの受信待ちとなる（ステップＳ３６）。

またメディアサーバ管理部１−６は、メディアサーバ１−１のリソース情報（ＩＰアドレス、ポート番号）を設定したリソース接続受付をＩＰ電話制御部１−３に通知する（ステップＳ３７）。これを受けたＩＰ電話制御部１−３は、メディアサーバ１−１との双方向接続を要求する呼出通知をＩＰ電話機１−２に与える（ステップＳ３８）。これによりＩＰ電話機１−２とメディアサーバ１−１との間にセッションが確立される。このため、ＩＰ電話機１−２のユーザは、発側ノードメディアサーバ１−１で発生させたビジートーンＢＴを聴取する状態になる（ステップＳ３９）。すなわちＩＰ電話機１−２は、発側ノード（１０）に繋がれたメディアサーバ１−１からのビジートーンＢＴを受信する状態となる。このビシートーンを聴取することで、ユーザは着信先が話中であることを認識する。

なお、ＩＰ交換機により提供される規定のサービスとして、話中呼出、通話割込、メッセージウェイティングなどがある。ＩＰ電話機１−２のユーザは、話中呼出、通話割込、メッセージウェイティングなどの規定サービスを希望する場合は、ビジートーンＢＴを聴取している状態で所望のサービスに対応したサービス起動特番をＩＰ電話機１−２から入力する。そうするとメディアサーバ１−１はＤＴＭＦをローカルで受信し、その旨を発側ノード（１０）のＩＰ電話制御部１−３に通知する（ステップＳ４０）。ＩＰ電話制御部１−３は番号分析部１−７にＤＴＭＦの内容の分析を依頼する（ステップＳ４１）。

番号分析部１−７は、番号蓄積テーブル１−９に登録されている相手先番号“２０００”を取得するとともに（ステップＳ４２）、入力されたサービス起動特番をキーとして番号分析テーブル１−８を参照し（ステップＳ４３）、要求されたサービスが特定される（ステップＳ４４）。これを受けて番号分析部１−７は、特定されたサービス種別および相手先ノード番号（２０）をＩＰ電話制御部１−３に通知する（ステップＳ４５）。

そうするとＩＰ電話制御部１−３は、番号分析部１−７の処理結果に基づいて、相手ノード番号（２０）および入力ダイヤル“２０００”を合わせたパラメータ“２０２０００”と、サービス種別とをセットした専用線接続要求を、呼制御部１−４に送信する（ステップＳ４６）。これを受けて呼制御部１−４は、ＩＰ専用線制御部１−５に対して着信要求を送信する（ステップＳ４７）。ＩＰ専用線制御部１−５は、着側ノード（２０）に対しＩＮＶＩＴＥメッセージを送信する（ステップＳ４８）。このメッセージにはパラメータ“２０２０００”と、付加ダイヤル“ｘｘｘｘ”とがセットされる。付加ダイヤルとは入力されたサービス起動特番である。

着側ノード（２０）のＩＰ専用線制御部２−５は、発側ノード（１０）に向け１００ Ｔｒｙｉｎｇを返信し（ステップＳ４９）、ＩＮＶＩＴＥメッセージにセットされたパラメータ“２０２０００”と付加ダイヤル“ｘｘｘｘ”を番号分析部２−７に通知し（ステップＳ５０）、その処理結果としてサービス種別を取得する（ステップＳ５１）。ＩＰ専用線制御部２−５は、取得したサービス種別をパラメータに設定して、呼制御２−４に該当サービスの起動を要求し（ステップＳ５２）、ＩＰ交換機２が提供するサービス（話中呼出、通話割込、メッセージウェイティングなど）が起動される（ステップＳ５３）。

以上説明したように第２の実施形態では、メディアサーバのリソースを使用してサービスを提供する電話システムにおいて、ＩＰ交換機で授受される呼制御メッセージをメディアサーバリソースの残量に応じて切り替えるようにし、サービス提供に係わるメディアサーバを呼毎に切り替えるようにする。さらに、発信元ＩＰ電話機と発側ノードのメディアサーバに接続されたケースにおいて、発信元ＩＰ電話機の入力ダイヤルを分析し、その結果に応じて着側ノードに対するサービス起動用の呼制御メッセージを送信するようにしている。これにより発信元ノード、着信先ノードのいずれのメディアサーバのリソースを使用する場合でも、発信元のＩＰ電話機に常に同等のサービスを提供することが可能になる。

これによりＩＰネットワークシステムを構成するすべてのＩＰ交換機に接続されたメディアサーバリソースのコストを抑えた上で、同一ネットワーク上の任意のＩＰ電話機に対して常に同等のＩＰ交換機サービスを提供することが可能になる。従って、メディアサーバのリソースコストを抑えつつＩＰ電話機に十分なサービスを提供することの可能な電話システムとその交換装置を提供することが可能となる。

なお、この発明は上記実施の形態に限定されるものではない。例えばメディアサーバから供給されるトーン信号はビジートーンＢＴに限るものではなく、リオーダートーン（Re-order Tone）あるいはファストビジートーン（fast-busy tone）などであっても良い。

ここで、リオーダートーンとは、発側端末の誤ダイヤルによる着信先不存在、または着信先の障害発生などにより、呼出し後のサービス起動不可の場合に送出される。ファストビジートーンとは、着信拒否状態の端末を呼び出した場合に送出される。

また、上記実施形態では着信先メディアサーバのリソースが枯渇した状態への対応につき説明したが、これに限らず、リソース残量が規定の閾値以下であればリソース接続拒否を送出するようにしても良い（図３のステップＳ３０）。つまり、ある程度のリソースが残っていたとしてもその残量が閾値を下回れば、空きリソース無しと判定するようにしてもよい。

［第３の実施形態］
次に、第３の実施形態について、説明する。本実施の形態では、ＩＰ電話機がビジートーン等のトーン信号を送出する機能を備える場合につき説明する。着呼先のＩＰ電話機がこの種の機能を備えていれば、発側のメディアサーバのリソースを使用しなくても、発呼元ＩＰ電話機にビジートーン等を聴取させることができる。

ここでは、発側ＩＰ電話機のトーン送出機能の有無に着目し、さらに着側ノードのメディアサーバリソースが枯渇しているケースを想定する。 本実施の形態では、ＩＰ電話機のログイン時に登録の際に、端末情報としてトーン送出機能の有無をサーバに対して、通知する。サーバには、ＩＰ電話機ごとの端末情報を登録するための端末情報管理テーブル（追加図面に図示）の中に、トーン発生回路の有無を記憶させる。

図４は、端末情報管理テーブル１−１０に登録される内容の一例を示す図である。このテーブルは例えばＩＰ交換機ごとに記憶され、ログイン手順にて与えられた端末ＩＤおよび内線番号に対応付けて、トーン送出機能の有無と、ダイヤル送出機能の詳細についてＩＰ電話機ごとに予め登録される。トーン送出機能が“有り”のＩＰ電話機は、自らがトーン信号を相手先に送出する機能を持つ。ダイヤル送出機能としては“制御信号”と“ＤＴＭＦ信号”との区別があり、ＤＴＭＦ信号または制御信号のいずれかにより相手先への指示を与えるものである。

図５は、発側ＩＰ電話機がトーン信号の送出機能を備える場合で、ダイヤル送出機能がＤＴＭＦの場合の処理手順の一例を示すシーケンス図である。図５において図６と同じ処理には共通のステップ番号を付して示し、以下では異なる手順についてのみ説明する。ここでは、発側ＩＰ電話機のトーン送出機能の有無に着目し、さらに着側ノードのメディアサーバリソースが枯渇しているケースを想定する。なお着側ＩＰ電話機がトーン出力機能を備えていても、ビジーであれば現在通話中のセッションの方にトーン出力のリソースが割りあてられる。

図５のステップＳ３３で接続拒否を受信した発側ノード（１０）のＩＰ電話制御部１−３は、端末情報管理テーブル１−１０を参照する。ここで、発側ＩＰ電話機のトーン送出機能が“有り”で、ダイヤル送出機能が「ＤＴＭＦ」であれば、ＩＰ電話制御部１−３はメディアサーバ管理部１−６に対してリソース接続要求（トーン：なし、ＤＴＭＦ受信：要）を送信する（ステップＳ６０）。この要求を受けたメディアサーバ管理部１−６は、空きリソースをハントしたのち発側のメディアサーバ１−１に対してリソース接続指示（トーン種別：なし、ＤＴＭＦ受信：要）を送信する（ステップＳ６１）。この指示を受けたメディアサーバ１−１は、確保されたリソースを用いてＤＴＭＦの受信待ちとなる（ステップＳ６２）。

またメディアサーバ管理部１−６は、メディアサーバ１−１のリソース情報（ＩＰアドレス、ポート番号）を設定したリソース接続受付をＩＰ電話制御部１−３に通知する（ステップＳ３７）。
これを受けたＩＰ電話制御部１−３は、ＩＰ電話機１−２に対しメディアサーバ１−１との双方向接続を要求する呼出通知とトーン接続指示（トーン：ＢＴ）を送信する（ステップＳ６３）。これを受けたＩＰ電話機１−２はビジートーンＢＴを発生出力する。これによりＩＰ電話機１−２は、端末内のトーン発生回路によりビジートーンを発生させ、ＩＰ電話機１−２のユーザは、ビジートーンＢＴを聴取する状態になる（ステップＳ６４）。このビシートーンを聴取することで、ユーザは着信先が話中であることを認識する。

また、ＩＰ電話機１−２とメディアサーバ１−１との間にセッションが確立されている。このため、ＩＰ電話機１−２のユーザは、話中呼出、通話割込、メッセージウェイティングなどの規定サービスを希望する場合は、ビジートーンＢＴを聴取している状態で所望のサービスに対応したサービス起動特番をＩＰ電話機１−２から入力する。そうするとメディアサーバ１−１はＤＴＭＦをローカルで受信し、その旨を発側ノード（１０）のＩＰ電話制御部１−３に通知し（ステップＳ４０）、以後同様の動作を行う。

以上の手順により、ＤＴＭＦ信号を受信するためのリソースは必要となるが、メディアサーバにおいてトーン信号を発生させるためのリソースが必要なくなる。よってメディアサーバのリソースの消費を抑えることができる。

一方、図６は、発側ＩＰ電話機がトーン信号の送出機能を備える場合で、ダイヤル送信機能が制御信号の場合の処理手順の他の例を示すシーケンス図である。図６のステップＳ３３で接続拒否を受信した発側のＩＰ電話制御部１−３は、端末情報管理テーブル１−１０を参照する。ここで、発側ＩＰ電話機のトーン送出機能が“有り”で、ダイヤル送出機能が「制御信号」であれば、ＩＰ電話制御部１−３はただちにＩＰ電話機１−２に対しトーン接続指示（トーン：ＢＴ）を送信する（ステップＳ６１）。これを受けたＩＰ電話機１−２はビジートーンＢＴを発生出力する（ステップＳ６２）。

更に、ダイヤル送出機能として、制御信号の出力が可能であるため、ＩＰ電話機１−２のユーザか、特定サービス起動のために特番を入力すると、ＩＰ電話機１−２は、トーン信号ではなく、特番起動の制御信号に変換してＩＰ電話制御部１−３に入力される。このため、メディアサーバのリソースを使用しなくても、ＩＰ電話制御部１−３が要求されたサービスの内容を認識できる。

このように、発信元のＩＰ電話機がトーン発生機能を備え、ダイヤル送出機能として制御信号が送出可能であれば、発側ＩＰ電話機１−２からトーン信号を発生させ、更に特定サービスを起動する場合も制御信号で入力することができるので、メディアサーバのリソースを消費することがない。

［第４の実施形態］
このほか、ＩＰ電話機ごとに優先度を予め設定し、着側メディアサーバのリソースを捕捉するか否かを発信元ＩＰ電話機の優先度に応じて判定する実施形態も実現可能である。なお、優先度に関しては、例えば企業内における役職者の優先度を高くしたり、オフィス内の部課単位で優先度の高低を決めたり、あるいは特定部門のＩＰ電話機の優先度を全て高くしたりなどといった運用が可能である。

つまり、本来であれば着側メディアサーバのリソースを使用したいが、上記したようにリソース残量には限りがある。そこで、着側メディアサーバのリソースを優先的に使用できるＩＰ電話機と、そうでないＩＰ電話機（優先度の低いＩＰ電話機）とを、端末のログインの時に端末情報として、端末情報管理テーブル１−１０に登録しておく。そして、実際に発信が行われたときに、シーケンスの初期に優先度判定を行って、優先度の高いＩＰ電話機については着側メディアサーバのリソースを使用し、優先度の低いＩＰ電話機については発側メディアサーバのリソースを使用するようにしてもよい。

なお、この発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

Ｌ１〜Ｌｎ…ＬＡＮ、１００…専用線ネットワーク、１，２，３，ｎ…ＩＰ交換機、１−１，２−１，３−１，ｎ−１…メディアサーバ、１−２…ＩＰ電話機、１−３…ＩＰ電話制御部、１−４…呼制御部、１−５…ＩＰ専用線制御部、１−６…メディアサーバ管理部、１−７…番号分析部、１−８…番号分析テーブル、１−９…番号蓄積テーブル、１−１０…端末情報管理テーブル、２−３…ＩＰ電話制御部、２−４…呼制御部、２−５…ＩＰ専用線制御部、２−６…メディアサーバ管理部、２−７…番号分析部、２−８…番号分析テーブル

Claims (10)

1. 電話端末と、交換装置と、トーン信号を発生するメディアサーバとが接続される複数のノードを通信網を介して相互接続して形成される電話システムにおいて、
   前記交換装置は、
   自ノードにおける前記メディアサーバのリソースの残量を把握する把握手段を備え、
   前記通信網を介してノード間に呼が生じた場合に、前記呼の着信先ノードにおけるメディアサーバのリソースの残量があれば、当該着信先ノードにおけるメディアサーバのリソースから発信元の電話端末に対してトーン信号を送信するように制御することを特徴とする電話システム。
2. 前記交換装置は、
   自ノードの電話端末からの他ノード宛の発信要求を前記通信網を介して当該他ノードに送信する送信手段と、
   自ノード宛に他ノードから送信された発信要求を受信する受信手段と、
   前記受信した発信要求に対し前記メディアサーバのリソースが必要となる場合に、前記把握されたリソースの残量が規定の閾値以下であれば、発信元ノードのメディアサーバのリソースを要求する旨を示すリソース要求信号を前記発信元ノードに返信する返信手段と、
   前記メッセージを受信した場合に、自ノードにおける発信元電話端末と自ノードにおけるメディアサーバとの間にセッションを形成して当該発信元電話端末に対し当該メディアサーバからのトーン信号を供給するセッション形成手段とを具備することを特徴とする請求項１記載の電話システム。
3. 前記交換装置は、さらに、
   自ノードの前記発信元電話端末において入力されたダイヤル番号を記憶する記憶手段と、
   当該発信元電話端末から特定のサービスを要求する特番が入力されたことを検出すると、前記記憶手段に記憶されたダイヤル番号に、前記入力された特番を付加して、対応するノード宛に前記特定サービスを要求する特定サービス要求手段を具備することを特徴とする請求項２記載の電話システム。
4. 前記交換装置は、さらに、
   前記電話端末ごとに電話端末の機能を登録するための端末情報管理テーブルを備え、
   前記セッション形成手段は、呼の発生に際して発信元電話端末における前記トーン送出機能の有無を確認し、その結果、前記発信元電話端末に前記トーン送出機能がある場合に、当該発信元電話端末に対し、トーン発生要求信号を送信することを特徴とする請求項３記載の電話システム。
5. 前記電話端末はそれぞれ優先度を個別に設定され、
   前記交換装置は、発側の電話端末に対してトーン信号を送信するに際して、着信先ノードにおけるメディアサーバのリソースを使用するか、または、発信元ノードにおけるメディアサーバのリソースを使用するかを前記優先度に基づいて決定することを特徴とする請求項１記載の電話システム。
6. 電話端末と、交換装置と、トーン信号を発生するメディアサーバとが接続される複数のノードを通信網を介して相互接続して形成される電話システムに用いられる前記交換装置において、
   自ノードにおける前記メディアサーバのリソースの残量を把握する把握手段を備え、
   前記通信網を介してノード間に呼が生じた場合に、前記呼の着信先ノードにおけるメディアサーバのリソースの残量があれば、当該着信先ノードにおけるメディアサーバのリソースから発信元の電話端末に対してトーン信号を送信するように制御することを特徴とする交換装置。
7. さらに、自ノードの電話端末からの他ノード宛の発信要求を前記通信網を介して当該他ノードに送信する送信手段と、
   自ノード宛に他ノードから送信された発信要求を受信する受信手段と、
   前記受信した発信要求に対し前記メディアサーバのリソースが必要となる場合に、前記把握されたリソースの残量が規定の閾値以下であれば、発信元ノードのメディアサーバのリソースを要求する旨を示すリソース要求信号を前記発信元ノードに返信する返信手段と、
   前記メッセージを受信した場合に、自ノードにおける発信元電話端末と自ノードにおけるメディアサーバとの間にセッションを形成して当該発信元電話端末に対し当該メディアサーバからのトーン信号を供給するセッション形成手段とを具備することを特徴とする請求項６記載の交換装置。
8. さらに、
   自ノードの前記発信元電話端末において入力されたダイヤル番号を記憶する記憶手段と、
   当該発信元電話端末から特定のサービスを要求する特番が入力されたことを検出すると、前記記憶手段に記憶されたダイヤル番号に、前記入力された特番を付加して、対応するノード宛に前記特定サービスを要求する特定サービス要求手段を具備することを特徴とする請求項６記載の交換装置。
9. さらに、
   前記電話端末ごとに電話端末の機能を登録するための端末情報管理テーブルを備え、
   前記セッション形成手段は、呼の発生に際して発信元電話端末における前記トーン送出機能の有無を確認し、その結果、前記発信元電話端末に前記トーン送出機能がある場合に、当該発信元電話端末に対し、トーン発生要求信号を送信することを特徴とする請求項８記載の交換装置。
10. 前記電話端末はそれぞれ優先度を個別に設定され、
    前記交換装置は、発側の電話端末に対してトーン信号を送信するに際して、着信先ノードにおけるメディアサーバのリソースを使用するか、または、発信元ノードにおけるメディアサーバのリソースを使用するかを前記優先度に基づいて決定することを特徴とする請求項６記載の交換装置。

Images