JP2006203311A - 呼制御システム、呼制御方法、および呼制御プログラム - Google Patents

Abstract

【課題】 各種資源の利用効率と利便性を高める。
【解決手段】 呼制御システムにおいて、呼制御を規定する呼制御プロトコル上で定義される呼状態のほうが、所定の呼処理言語上で定義される呼状態よりも詳細である場合、当該呼処理言語上でも呼制御プロトコル上の詳細さに適合する呼状態を定義したうえで、呼処理言語で記述した呼転送シナリオ情報を、前記端末情報の一部として、端末情報蓄積装置に蓄積しておき、いずれかのエンド端末に他のエンド端末から呼制御メッセージが届けられるときには、呼制御支援装置は、呼制御メッセージが届けられるエンド端末に該当する端末情報のなかから呼転送シナリオ情報を抽出し、呼転送シナリオ情報にしたがって呼転送を実行する。
【選択図】 図１

Description

本発明は呼制御システム、呼制御方法、および呼制御プログラムに関し、例えば、ＣＰＬ（Call Processing Language）で記述された呼転送シナリオにしたがって呼転送を行う場合などに適用して好適なものである。

ＩＰ電話のユーザが、ＩＰ電話サービスの内容を変更するための技術として、下記の非特許文献１に記載されたＣＰＬがある。

ＣＰＬは、実際に用いられる呼制御プロトコル上で、ある呼状態が発生したとき、ＩＰ電話交換システムがどのように動作すべきかを指定するための簡易プログラミング言語である。

ただし、ＩＰ電話交換システムの全動作をＣＰＬで指定できるようにすると、ＣＰＬで記述される内容によってはＩＰ電話交換システムが停止してしまう等の不都合が生じる可能性もあるため、ＣＰＬで記述できるのは、呼処理に限定されている。
IETF draft-ietf-iptel-cpl-09"CPL:Alanguage for User Control of Internet Telephony Services",Jonathan Lennox,Xiaotao Wu,Henning Schulzrinne,April 2004

ところが上述したＣＰＬでは、定義されている呼状態の数が呼制御プロトコルの実行によって起こり得る実際の呼状態に比べて少ないため、様々な不都合が起きる可能性があり、各種資源の利用効率と利便性が低い。

例えば、ＣＰＬでは、ある着信先ＩＮ１が話中（ビジー）であるとき、着信先ＩＮ１への呼を別な着信先ＩＮ２へ転送するように記述することができるが、呼制御プロトコルや着信先の機能によっては、着信先ＩＮ１だけでなくＩＮ２も話中であることが分かることがある（例えば、ＳＩＰ（Session Initiation Protocol）の応答コード「６００」に対応するＢｕｓｙ Ｅｖｅｒｙｗｈｅｒｅ（どの場所もビジー）が返ってきた場合など）。ＣＰＬにしたがった動作をする限り、ＩＰ電話交換システムは、この場合でも、すでに話中であることが分かっている着信先ＩＮ２へ呼を転送してしまうことになる。そしてこのような呼転送により、ＩＰ電話交換システムおよび着信先の端末の資源（例えば、処理能力など）が無駄に消費されるほか、ネットワークの帯域なども無駄に消費されてしまう。

また、このように無駄な呼転送の繰り返しが起こり得るということは、発呼側のユーザの立場からすると、かなり長時間待たなければ、呼を設定できる着信先端末があるか否かの見極めが付かないことを意味し、利便性が低下する可能性が高い。

かかる課題を解決するために、第１の本発明では、呼制御メッセージを処理してエンド端末を始点または終点とする経路上で行われる呼制御を支援する呼制御支援装置と、前記呼制御メッセージの送信元または宛先となるエンド端末に関する情報である端末情報を各エンド端末に対応付けて蓄積する端末情報蓄積装置とを備えた呼制御システムにおいて、前記呼制御を規定する呼制御プロトコル上で定義される呼状態のほうが、所定の呼処理言語上で定義される呼状態よりも詳細である場合、当該呼処理言語上でも呼制御プロトコル上の詳細さに適合する呼状態を定義したうえで、当該呼処理言語で記述した呼転送シナリオ情報を、前記端末情報の一部として、前記端末情報蓄積装置に蓄積しておき、いずれかのエンド端末に他のエンド端末から呼制御メッセージが届けられるときには、前記呼制御支援装置は、当該呼制御メッセージが届けられるエンド端末に該当する端末情報のなかから呼転送シナリオ情報を抽出し、当該呼転送シナリオ情報にしたがって呼転送を実行することを特徴とする。

また、第２の本発明では、呼制御メッセージを処理してエンド端末を始点または終点とする経路上で行われる呼制御を支援する呼制御支援装置と、前記呼制御メッセージの送信元または宛先となるエンド端末に関する情報である端末情報を各エンド端末に対応付けて蓄積する端末情報蓄積装置とを用いる呼制御方法において、前記呼制御を規定する呼制御プロトコル上で定義される呼状態のほうが、所定の呼処理言語上で定義される呼状態よりも詳細である場合、当該呼処理言語上でも呼制御プロトコル上の詳細さに適合する呼状態を定義したうえで、当該呼処理言語で記述した呼転送シナリオ情報を、前記端末情報の一部として、前記端末情報蓄積装置に蓄積しておき、いずれかのエンド端末に他のエンド端末から呼制御メッセージが届けられるときには、前記呼制御支援装置は、当該呼制御メッセージが届けられるエンド端末に該当する端末情報のなかから呼転送シナリオ情報を抽出し、当該呼転送シナリオ情報にしたがって呼転送を実行することを特徴とする。

さらに、第３の本発明は、呼制御メッセージを処理してエンド端末を始点または終点とする経路上で行われる呼制御を支援する呼制御支援機能と、前記呼制御メッセージの送信元または宛先となるエンド端末に関する情報である端末情報を各エンド端末に対応付けて蓄積する端末情報蓄積機能とを用いる呼制御プログラムにおいて、コンピュータに、前記呼制御を規定する呼制御プロトコル上で定義される呼状態のほうが、所定の呼処理言語上で定義される呼状態よりも詳細である場合、当該呼処理言語上でも呼制御プロトコル上の詳細さに適合する呼状態を定義したうえで、当該呼処理言語で記述した呼転送シナリオ情報を、前記端末情報の一部として蓄積する前記端末情報蓄積機能を実現させ、いずれかのエンド端末に他のエンド端末から呼制御メッセージが届けられるときには、前記呼制御支援機能は、当該呼制御メッセージが届けられるエンド端末に該当する端末情報のなかから呼転送シナリオ情報を抽出し、当該呼転送シナリオ情報にしたがって呼転送を実行することを特徴とする。

本発明によれば、各種資源の利用効率と利便性を高めることができる。

（Ａ）実施形態
以下、本発明にかかる呼制御システム、呼制御方法、および呼制御プログラムを、呼制御プロトコルとしてＳＩＰを用いるＶｏＩＰ通信システムに適用した場合を例に、実施形態について説明する。

（Ａ−１）第１の実施形態の構成
本実施形態にかかるＶｏＩＰ通信システム１０の全体構成例を図１に示す。なお、当該ＶｏＩＰ通信システム１０中に、図示しないサーバ類（例えば、ＤＨＣＰサーバやＤＮＳサーバなど）が存在していてもよいことは当然である。

図１において、当該ＶｏＩＰ通信システム１０は、加入者情報データベース１と、ＩＰ電話交換システム２と、ＩＰネットワーク３と、ＩＰ電話端末４，５を備えている。

このうちＩＰネットワーク３は、ＯＳＩ参照モデルのネットワーク層でＩＰプロトコルを用いるネットワークである。

ＩＰ電話交換システム２は、ＩＰ電話機が送信元または宛先となる呼制御メッセージの中継などの処理を実行するシステムで、ＳＩＰサーバに該当し得る。本実施形態で注目する呼の転送も、当該ＩＰ電話交換システム２が実行する。

加入者情報データベース１は、ＩＰ電話端末のユーザ（加入者）に関する情報（加入者情報）を蓄積するためのデータベースで、具体的には、ロケーションサーバが当該加入者情報データベース１に該当し得る。前記ＳＩＰサーバに含まれるプロキシは、呼制御メッセージを処理するとき、当該加入者情報データベース１の登録内容を参照してアドレス解決を行う。

加入者情報データベース１に登録される加入者情報には様々な情報が含まれる。例えば、各ＩＰ電話端末の位置情報（ＩＰアドレス）やＳＩＰ−ＵＲＩなどもそのような情報の一部である。ＩＰアドレスは、ＩＰネットワーク上（ＩＰプロトコル上）で宛先や送信元を識別するための識別情報である。また、ＳＩＰ−ＵＲＩは「ユーザ名＠ドメイン名」の形式で記述される識別情報で、ＳＩＰプロトコル上で宛先や送信元を識別する場合などに利用される。

また、前記ＣＰＬで記述された呼転送シナリオも当該加入者情報に含まれる。ここでは、ある加入者情報に含まれている呼転送シナリオＣＹ１に注目する。ただし本実施形態のＣＰＬは、上述した通常のＣＰＬに比べると拡張されており、通常のＣＰＬでは記述することのできない呼状態を記述することが可能である。

ＩＰ電話端末４，５は、ＶｏＩＰ機能を搭載したＩＰ電話機または、ＶｏＩＰゲートウエイと一般電話機（ＶｏＩＰ非対応の電話機）を組み合わせた構成要素にあたる。

ＩＰ電話端末５には、ＩＰ電話端末５Ａと５Ｂが含まれている。これらのＩＰ電話端末５Ａ、５Ｂは、論理的には別個のＩＰ電話端末であるが、物理的には同じＩＰ電話端末であってよい。このような構成は、同一のＩＰ電話端末に複数（ここでは、２つ）のＳＩＰ−ＵＲＩを設定することによって実現可能である。ＳＩＰプロトコル上、設定されているＳＩＰ−ＵＲＩごとに、別個のＩＰ電話端末が存在するものとみなされるからである。

以下、上記のような構成を有する本実施形態の動作について、図２および図３を用いて説明する。

図２は、ＸＭＬ（eXtensible Markup Language）形式で記述した前述の呼転送シナリオＣＹ１の一例を示したものである。

従来の呼転送シナリオと異なる点は、図２には、ｄｒａｆｔ−ｉｅｔｆ−ｉｐｔｅｌ−ｃｐｌ−０９で定義されていない拡張されたタグによる記述ＥＴ１が含まれている点である。

タグ（ｔａｇ）は“＜”と“＞”で囲まれた要素を持つ記述である。Ｘを任意の要素とすると、“＜Ｘ＞”や、“＜Ｘ＞”と“＜／Ｘ＞”の組をＸタグと呼ぶ。ＸＭＬ形式で記述された呼転送シナリオのなかにおいて、１つのタグは基本的に１つの呼状態に対応する。

周知のように、ＸＭＬの記述は入れ子構造になっているが、この入れ子構造では、外側の記述（外側のタグ）ほど木構造の上位の節に対応付けることができ、上位の節（上位のタグ）から順番に処理が行われる。

図２中、＜ｃｐｌ＞ と＜／ｃｐｌ＞ で囲まれた部分がＣＰＬによる呼転送シナリオＣＹ１の本体を示している。また、＜ｉｎｃｏｍｉｎｇ＞と＜／ｉｎｃｏｍｉｎｇ＞で囲まれた部分は着信時の動作（呼処理動作）を示し、＜ｌｏｃａｔｉｏｎ Ｙ＞と＜／ｌｏｃａｔｉｏｎ＞で囲まれた部分はロケーション（転送先）の設定動作を示している。ここで、Ｙとしては任意のロケーションを記述できるが、図２の例では、ロケーションとして、「user1@xxx.jp」または「user2@xxx.jp」のいずれかが記述される。

また、＜ｐｒｏｘｙ＞と＜／ｐｒｏｘｙ＞は、前記ロケーションの設定動作で設定されたロケーションへの転送動作を示している。＜ｐｒｏｘｙ＞と＜／ｐｒｏｘｙ＞で囲まれたところに何も記述されていない「＜ｐｒｏｘｙ＞＜／ｐｒｏｘｙ＞」は、そこで呼転送シナリオが終了し、当該呼に対する呼処理動作が終わることを示している。図２中の「＜ｐｒｏｘｙ／＞」は、「＜ｐｒｏｘｙ＞＜／ｐｒｏｘｙ＞」の省略形である。

さらに、＜ｂｕｓｙ＞と＜／ｂｕｓｙ＞で囲まれた部分は、前記ロケーションの設定動作で設定されたロケーションへの転送動作の結果、転送先が話中（ビジー）である旨の応答を返送してきた場合に実行される動作を示している。

また、＜ｆａｉｌｕｒｅ Ｚ＞と＜／ｆａｉｌｕｒｅ＞で囲まれた部分は、所定の応答コード（ステータスコード）が返送されてきたときに実行される動作を示している。ここで、Ｚには任意の応答コードが記述され得るが、図２の例では、「ｒｅｓｐｏｎｓｅ＝”Ａ１”」が記述されている。この「Ａ１」が任意の応答コードに対応する。ここでは、当該「Ａ１」として「６００」が記述されているものとする。「６００」は、「Ｂｕｓｙ Ｅｖｅｒｙｗｈｅｒｅ」（どの場所もビジー）を示す応答コードで、転送先のＩＰ電話端末（例えば、５Ａ）が他のＩＰ電話端末（例えば、５Ｂ）もビジーであることを検出する機能（他ビジー検出機能）を持っていることを前提に、自身も含め他のＩＰ電話端末もすべてビジーであることを検出しているときに返送される応答コードである。当該「６００」と置換可能な類似の応答コードとしては、「６０３」＝「Ｄｅｃｌｉｎｅ」（辞退）などがある。転送先のＩＰ電話端末は、前記他ビジー検出機能を持たない場合や、他ビジー検出機能を持っているが、自身以外のいずれかの他のＩＰ電話端末がビジーでないことを検出している場合には、応答コードとして「４８６」＝「Ｂｕｓｙ Ｈｅｒｅ」（ここはビジー）を返す。

図２から明らかなように、ｆａｉｌｕｒｅタグのほうがｂｕｓｙタグよりも上位の節にあたるため、先に処理される。
図３は呼転送の様子を示す動作シーケンスで、Ｓ１０〜Ｓ１７の各ステップを備えている。図３の動作シーケンスは図２の呼転送シナリオＣＹ１に対応した動作を示している。

（Ａ−２）第１の実施形態の動作
ここで、前記ＩＰ電話端末５ＡはＳＩＰ−ＵＲＩである「user1@xxx.jp」に対応し、ＩＰ電話端末５ＢはＳＩＰ−ＵＲＩである「user2@xxx.jp」に対応するものとする。そして、いずれかのＩＰ電話端末（ここでは、４とする）からＩＰ電話端末５Ａすなわちロケーション「user1@xxx.jp」に着信したものとする。

この着信は、当該ＩＰ電話端末４がオフフックされて呼設定を要求する呼制御メッセージ（ＳＩＰメッセージの１つであるＩＮＶＩＴＥメッセージ）がＩＰネットワーク３経由でＩＰ電話交換システム２まで届けられ、さらにＩＰ電話交換システム２による呼処理を経て、ＩＰネットワーク３経由でＩＰ電話端末５Ａに届けられることによって実現される。ＩＰネットワーク３上を伝送される以上、すべての呼制御メッセージはＩＰパケットに収容されて送受されることは当然である。

ＩＰ電話交換システム２における呼処理では、前記ＩＮＶＩＴＥメッセージがＩＰ電話交換システム２まで到達した時点で当該ＩＮＶＩＴＥメッセージの宛先（Ｔｏフィールドの記述）である前記ＳＩＰ−ＵＲＩ「user1@xxx.jp」を抽出し、当該ＳＩＰ−ＵＲＩをもとに前記加入者情報データベース１を検索する。加入者情報データベース１内では、当該ＳＩＰ−ＵＲＩ「user1@xxx.jp」に対応付けられた加入者情報の一部として前記呼転送シナリオＣＹ１が登録されているため、この検索では、検索結果として当該呼転送シナリオＣＹ１が得られる。このあと、ＩＰ電話交換システム２は、当該呼転送シナリオＣＹ１にしたがって呼転送を行う。ここまでの処理は図３のステップＳ１０に対応するものである。

検索結果として得られた呼転送シナリオＣＹ１の内容が図２に示す通りであるものとすると、前記ＩＮＶＩＴＥメッセージがＩＰ電話交換システム２まで届いた時点で着信とみなして、ＩＰ電話交換システム２が、ｉｎｃｏｍｉｎｇタグを処理しはじめる。

つづいてステップＳ１１では、ｌｏｃａｔｉｏｎタグが処理されて、図２の記述にしたがい、ロケーションの設定が行われる。図２では最初に処理されるｌｏｃａｔｉｏｎタグにロケーション「user1@xxx.jp」が記述されているため、ＩＰ電話交換システム２による呼の転送先としては、最初、当該ロケーション「user1@xxx.jp」が設定される。このｌｏｃａｔｉｏｎタグに別なロケーションを記述しておけば、その記述にしたがい「user1@xxx.jp」以外の転送先へ呼を転送することができることは当然である。

上述したように、当該「user1@xxx.jp」はＩＰ電話端末５Ａに対応するため、このＩＮＶＩＴＥメッセージはＩＰ電話端末５Ａに転送される。

当該ＩＮＶＩＴＥメッセージを受信したＩＰ電話端末５Ａがどのような応答メッセージを返送してくるかは、その時点のＩＰ電話端末５Ａの機能や状態に応じて変わる。

ＩＰ電話端末５Ａ自身がビジーでない場合、例えば、呼び出しに応えてＩＰ電話端末５Ａのユーザがオフフックすると、ＩＰ電話端末５Ａから２００ＯＫメッセージが返送され、呼設定が行われることになる。これは、ステップＳ１４に対応するケースである。ここで、「２００」はリクエスト（この場合、呼設定の要求）が成功したことを示す応答コードである。

ＩＰ電話端末５Ａが前記他ビジー検出機能を持たない場合や、他ビジー検出機能を持っていて他のいずれかのＩＰ電話端末（ここでは、５Ｂ）がビジーでないことを検出しており、なおかつ、ＩＰ電話端末５Ａ自身がビジーである場合には、前記「４８６」＝「Ｂｕｓｙ Ｈｅｒｅ」（ここはビジー）を返す。

ＩＰ電話端末５Ａから４８６ＢｕｓｙＨｅｒｅメッセージを受け取ったＩＰ電話交換システム２は、前記ｆａｉｌｕｒｅタグを検査してｆａｉｌｕｒｅタグが「６００」以外の応答コードと無関係なことを検出すると、次のｂｕｓｙタグを検査する。

予め応答コード「４８６」がｂｕｓｙタグに対応するものであることをＩＰ電話交換システム２に登録しておけば、ＩＰ電話交換システム２は、この検査で、当該応答コード「４８６」に対し、ｂｕｓｙタグの部分の記述にしたがった処理を実行すべきであることを認識できる。図２の例では、この部分にｌｏｃａｔｉｏｎタグが配置されているため、再び、ロケーションの設定動作が行われることになる（Ｓ１５）。

今回の設定では、図２の記述にしたがい、転送先として、ＩＰ電話端末５Ｂに対応するロケーション「user2@xxx.jp」が選ばれ、ＩＰ電話端末５ＢにＩＮＶＩＴＥメッセージが送信される（Ｓ１６）。

ＩＰ電話端末５Ｂがビジーでない場合、呼び出しに応えてＩＰ電話端末５Ｂのユーザがオフフックすると、ＩＰ電話端末５Ｂから２００ＯＫメッセージが返送され、呼設定が行われることになる。ただし、実際にはＩＰ電話端末５Ｂがビジーであるのに、ＩＰ電話端末５Ａが他ビジー検出機能を持たないために検出できなかった場合などには、ＩＰ電話端末５Ｂから２００ＯＫメッセージが返送されず、呼設定も行われない。呼設定が行えたとしても、行えなかったとしても、図２の呼転送シナリオＣＹ１では、２つ目の転送先にＩＮＶＩＴＥメッセージを転送したあとの処理は記述されていないため、当該呼に関し、ＩＰ電話交換システム２がさらなる転送処理を実行することはなく、呼の転送処理はここで終了する（Ｓ１７）。

一方、ＩＰ電話端末５Ａが前記他ビジー検出機能を持っていて、当該他ビジー検出機能の検出対象となる他のすべてのＩＰ電話端末（ここでは、５Ｂ）がビジーであることを検出しており、なおかつ、ＩＰ電話端末５Ａ自身もビジーである場合、前記ステップＳ１２の転送で届いたＩＮＶＩＴＥメッセージに応えて上述した応答コード「６００」（＝Ａ１）を含む６００ＢｕｓｙＥｖｅｒｙｗｈｅｒｅメッセージを返送することになる。

返送を受けた当該６００ＢｕｓｙＥｖｅｒｙｗｈｅｒｅメッセージに対する処理は、当該呼に関してＩＰ電話交換システム２内で実行される処理としては、図２中のｌｏｃａｔｉｏｎタグのなかで最も上位のｌｏｃａｔｉｏｎタグにしたがって設定されたロケーション「user1@xxx.jp」への転送につづいて実行されるものである。図２上、ｆａｉｌｕｒｅタグとｂｕｓｙタグはともに、ｐｒｏｘｙタグの１つ下位の階層に属する節にあたるが、同じ階層のなかでは図２上における記述の順番に処理を進めるものとすると、ｂｕｓｙタグより先にｆａｉｌｕｒｅタグが処理される。そして、ＩＰ電話交換システム２は、前記ｆａｉｌｕｒｅタグを検査するとき、６００ＢｕｓｙＥｖｅｒｙｗｈｅｒｅメッセージ中の応答コードとｆａｉｌｕｒｅタグに記述された応答コードが一致することが判定できるから、ｂｕｓｙタグを検査、処理する必要はなくなる。

この判定のあと、ＩＰ電話交換システム２は、当該呼に関する転送処理を終了することができる（Ｓ１３）。前記記述ＥＴ１で、＜ｆａｉｌｕｒｅ Ｚ＞と＜／ｆａｉｌｕｒｅ＞で囲まれた部分に何も記述されていないからである。ここで呼転送処理を終了するということは、２つ目の転送先である前記ＩＰ電話端末５Ｂへの呼の転送が行われないことを意味する。このため、すでにビジーであることが分かっている転送先へ呼を転送することによって生じるＩＰネットワーク３の帯域の消費、ＩＰ電話交換システム２自体の処理能力の消費、呼の転送先のＩＰ電話端末５Ｂの処理能力の消費などを抑制して資源を節約することができる。

他ビジー検出機能を持つＩＰ電話端末（ここでは、５Ａ）が存在する状況で、拡張されたタグによる記述ＥＴ１を含む呼転送シナリオＣＹ１に応じた呼転送処理を行えば、同一条件下では、本実施形態のほうが従来に比べて呼転送が繰り返される回数が減少するため、発呼側のユーザは、呼を設定できるＩＰ電話端末があるか否かの見極めを従来よりも短時間で付けることが可能となり、利便性が向上する。図示の例では、呼の転送先となり得るＩＰ電話端末は５Ａと５Ｂの２つだけであるが、呼転送シナリオの内容などによっては、３つ以上の転送先へ、逐次、呼の転送が繰り返される可能性もあるから、従来は、発呼側のユーザにとって呼を設定できるＩＰ電話端末があるか否かの見極めを付けるために長時間を要する可能性があった。

もしも記述ＥＴ１が存在しなければ、図２による呼転送シナリオでは、前記ロケーションの設定動作で設定されたロケーション（user1@xxx.jp）への転送動作のあと、転送先が話中（ビジー）である旨の応答を返送してきた場合、２つ目のロケーション（user2@xxx.jp）へ呼を転送することになる。この点は、ＩＰ電話端末５Ａが４８６ＢｕｓｙＨｅｒｅメッセージを返送してきてビジーを示した場合でも、６００ＢｕｓｙＥｖｅｒｙｗｈｅｒｅメッセージを返送してきてビジーを示した場合でも同じである。従来のＣＰＬに基づく呼転送処理では、そのためのタグが存在せず、応答コード「４８６」と「６００」等とを区別して異なる処理を行うことができなかったからである。

（Ａ−３）第１の実施形態の効果
本実施形態によれば、各種資源の利用効率と利便性を高めることができる。

（Ｂ）第２の実施形態
以下では、本実施形態が第１の実施形態と相違する点についてのみ説明する。

本実施形態は、音声などによる案内情報を伝えることのできるガイダンスサーバを設け、呼の転送先として当該ガイダンスサーバを含むことのできる構成とした点が第１の実施形態と相違する。

（Ｂ−１）第２の実施形態の構成および動作
本実施形態にかかるＶｏＩＰ通信システム２０の全体構成例を図４に示す。

図４において、当該ＶｏＩＰ通信システム２０は、加入者情報データベース１と、ＩＰ電話交換システム２と、ＩＰネットワーク３と、ＩＰ電話端末４，２１と、ガイダンスサーバ２２とを備えている
このうち図１と同じ符号１〜４を付与した構成要素の機能は基本的に第１の実施形態と同じであるので、その詳しい説明は省略する。

また、ＩＰ電話端末２１は、前記ＩＰ電話端末４または５と同じものであってよい。

ガイダンスサーバ２２は、呼の転送を受け、呼が設定されたときには、発呼元のＩＰ電話端末（例えば、４）に宛てて、音声などによる案内情報を伝えることのできるサーバである。図４の例では、ガイダンスサーバ２２は１台であるが、複数台のガイダンスサーバが設けられていてもよいことは当然である。また、物理的には１台のサーバであっても、論理的に複数のガイダンスサーバとして用いることが可能である。いずれにしても、複数のガイダンスサーバが存在する場合、ガイダンスサーバごとに、案内情報の内容が相違する構成とすることが可能である。

本実施形態で用いる呼転送シナリオＣＹ２の内容は図５に示す通りである。

図５中の各タグの意味は第１の実施形態と同じである。

図５において、記述ＥＴ２が拡張されたタグに対応する。

本実施形態におけるＩＰ電話交換システム２の動作を図６に示す。図６は呼転送の様子を示す動作シーケンスで、Ｓ２０〜Ｓ２９の各ステップを備えている。図６の動作シーケンスは図５の呼転送シナリオＣＹ２に対応した動作を示している。

図６において、ステップＳ２０は前記ステップＳ１０に対応し、ステップＳ２１は前記ステップＳ１１に対応し、ステップＳ２２は前記ステップＳ１２に対応し、ステップＳ２３は前記ステップＳ１４に対応し、ステップＳ２４は前記ステップＳ１５に対応し、ステップＳ２５は前記ステップＳ１６に対応し、ステップＳ２６は前記ステップＳ１７に対応するので、その詳しい説明は省略する。

ただし、ステップＳ２４は、応答コード「４８６」が返送されてきた場合、すなわち、着信先のＩＰ電話端末（例えば、２１）がビジーのときではなく、応答コード「Ｂ１」が返送されてきたときに実行される処理である。

また、ステップＳ２７は当該ステップＳ２４に対応するが、ステップＳ２４の場合とは異なる応答コード「Ｃ１」が返送されてきたときに処理される。

なお、図５上で、＜ｆａｉｌｕｒｅ ｒｅｓｐｏｎｓｅ＝”Ｂ１”＞と＜／ｆａｉｌｕｒｅ＞で囲まれた部分と、＜ｆａｉｌｕｒｅ ｒｅｓｐｏｎｓｅ＝”Ｃ１”＞と＜／ｆａｉｌｕｒｅ＞で囲まれた部分は、前記木構造で同じ階層に属するため、いずれが先に処理されてもかまわないが、ここでは、図５に記述された順番にしたがって、＜ｆａｉｌｕｒｅ ｒｅｓｐｏｎｓｅ＝”Ｂ１”＞と＜／ｆａｉｌｕｒｅ＞で囲まれた部分のほうが先に処理されるものとする。

すなわち、応答コードが「Ｂ１」であるか否かが先に検査され、「Ｂ１」である場合には、設定されるロケーション（server1@xxx.jp）へ転送されて（ステップＳ２４〜Ｓ２６に対応）、「Ｂ１」でない場合に、「Ｃ１」であるか否かが先に検査される。応答コードが「Ｃ１」である場合には、設定されるロケーション（server2@xxx.jp）へ転送される（ステップＳ２７〜Ｓ２９に対応）。

このうち、ロケーション（server1@xxx.jp）は１つのガイダンスサーバに対応し、ロケーション（server2@xxx.jp）は、もう１つのガイダンスサーバに対応するものであってよい。

これによれば、ＣＰＬで定義されたタグに束縛されることなく、着信先のＩＰ電話端末（例えば、２１）から返送されてきた応答コードに応じて、ＩＰ電話交換システム２が転送先のガイダンスサーバを変更し、発呼元のＩＰ電話端末（例えば、４）のユーザに異なる案内情報を届けることができる。

もちろん、転送先のロケーションの数はここにあげた２つに限定する必要はないので、必要に応じて、１つとしてもよく、３つ以上としてもよい。

また、呼転送シナリオＣＹ２のなかに、図２の記述ＥＴ１と同等な記述やｂｕｓｙタグを記述しておくこと等により、第１の実施形態と同様な動作を行うことも可能である。

（Ｂ−２）第２の実施形態の効果
本実施形態によれば、着信先のＩＰ電話端末（例えば、２１）から返送されてきた応答コードに応じて、発呼元のＩＰ電話端末（例えば、４）のユーザに対し、異なる案内情報を届けることができるため、柔軟で、利便性が高い。

また、本実施形態では、第１の実施形態の効果と同等な効果を得ることも可能である。

（Ｃ）他の実施形態
図２や図５に示した呼転送シナリオＣＹ１，ＣＹ２は一例であって、第１、第２の実施形態の趣旨に反しない限り、様々な変形が可能であることは当然である。

また、呼転送シナリオの記述言語は、図２や図５に示したＸＭＬに限定する必要はない。例えば、様々なプログラミング言語を用いて、同等な機能を持つ呼転送シナリオを記述することが可能である。

さらに、上記第１および第２の実施形態において、ＩＰ電話交換システム２と加入者情報データベース１は別の装置であったが、同一の装置上にこれらの機能を実装することも可能である。

なお、上記第２の実施形態でガイダンスサーバ２２が提供する案内情報は、音声とともに、または音声に替えて、画像などを含むものであってもよい。発呼元のＩＰ電話端末（例えば、４）が、テレビ電話などに対応した機能を持つ場合、画像による案内も効果的である。

また、本発明は、上記第１、第２の実施形態で用いた以外の通信プロトコルに適用することができる。

例えば、ネットワーク層の通信プロトコルとしてＩＰプロトコルの代わりにＩＰＸプロトコルなどを用いることができる可能性がある。さらに、呼制御プロトコルとしてＳＩＰ以外の通信プロトコルを用いることができる可能性もある。

以上の説明でハードウエア的に実現した機能の大部分はソフトウエア的に実現することができ、ソフトウエア的に実現した機能のほとんど全てはハードウエア的に実現することが可能である。

第１の実施形態にかかるＶｏＩＰ通信システムの全体構成例を示す概略図である。 第１の実施形態で使用する呼転送シナリオの構成例を示す概略図である。 第１の実施形態の動作例を示すシーケンス図である。 第２の実施形態にかかるＶｏＩＰ通信システムの全体構成例を示す概略図である。 第２の実施形態で使用する呼転送シナリオの構成例を示す概略図である。 第２の実施形態の動作例を示すシーケンス図である。

符号の説明

１…加入者情報データベース、２…ＩＰ電話交換システム、３…ＩＰネットワーク、４，５，５Ａ、５Ｂ、２１…ＩＰ電話端末、ＣＹ１，ＣＹ２…呼転送シナリオ。

Claims (4)

1. 呼制御メッセージを処理してエンド端末を始点または終点とする経路上で行われる呼制御を支援する呼制御支援装置と、前記呼制御メッセージの送信元または宛先となるエンド端末に関する情報である端末情報を各エンド端末に対応付けて蓄積する端末情報蓄積装置とを備えた呼制御システムにおいて、
   前記呼制御を規定する呼制御プロトコル上で定義される呼状態のほうが、所定の呼処理言語上で定義される呼状態よりも詳細である場合、当該呼処理言語上でも呼制御プロトコル上の詳細さに適合する呼状態を定義したうえで、当該呼処理言語で記述した呼転送シナリオ情報を、前記端末情報の一部として、前記端末情報蓄積装置に蓄積しておき、
   いずれかのエンド端末に他のエンド端末から呼制御メッセージが届けられるときには、前記呼制御支援装置は、当該呼制御メッセージが届けられるエンド端末に該当する端末情報のなかから呼転送シナリオ情報を抽出し、当該呼転送シナリオ情報にしたがって呼転送を実行することを特徴とする呼制御システム。
2. 請求項１の呼制御システムにおいて、
   他のエンド端末とのあいだで呼が確立されると所定の案内コンテンツを他のエンド端末へ送信する案内コンテンツ提供端末を１または複数備え、
   前記呼転送シナリオ情報には、当該案内コンテンツ提供端末への呼転送を記述しておくことを特徴とする呼制御システム。
3. 呼制御メッセージを処理してエンド端末を始点または終点とする経路上で行われる呼制御を支援する呼制御支援装置と、前記呼制御メッセージの送信元または宛先となるエンド端末に関する情報である端末情報を各エンド端末に対応付けて蓄積する端末情報蓄積装置とを用いる呼制御方法において、
   前記呼制御を規定する呼制御プロトコル上で定義される呼状態のほうが、所定の呼処理言語上で定義される呼状態よりも詳細である場合、当該呼処理言語上でも呼制御プロトコル上の詳細さに適合する呼状態を定義したうえで、当該呼処理言語で記述した呼転送シナリオ情報を、前記端末情報の一部として、前記端末情報蓄積装置に蓄積しておき、
   いずれかのエンド端末に他のエンド端末から呼制御メッセージが届けられるときには、前記呼制御支援装置は、当該呼制御メッセージが届けられるエンド端末に該当する端末情報のなかから呼転送シナリオ情報を抽出し、当該呼転送シナリオ情報にしたがって呼転送を実行することを特徴とする呼制御方法。
4. 呼制御メッセージを処理してエンド端末を始点または終点とする経路上で行われる呼制御を支援する呼制御支援機能と、前記呼制御メッセージの送信元または宛先となるエンド端末に関する情報である端末情報を各エンド端末に対応付けて蓄積する端末情報蓄積機能とを用いる呼制御プログラムにおいて、コンピュータに、
   前記呼制御を規定する呼制御プロトコル上で定義される呼状態のほうが、所定の呼処理言語上で定義される呼状態よりも詳細である場合、当該呼処理言語上でも呼制御プロトコル上の詳細さに適合する呼状態を定義したうえで、当該呼処理言語で記述した呼転送シナリオ情報を、前記端末情報の一部として蓄積する前記端末情報蓄積機能を実現させ、
   いずれかのエンド端末に他のエンド端末から呼制御メッセージが届けられるときには、前記呼制御支援機能は、当該呼制御メッセージが届けられるエンド端末に該当する端末情報のなかから呼転送シナリオ情報を抽出し、当該呼転送シナリオ情報にしたがって呼転送を実行することを特徴とする呼制御プログラム。

Images