JP2011009961A - 通信端末および呼制御装置および通信プログラム - Google Patents

Abstract

【課題】
情報が取得できない原因を特定することでユーザに適切な対応を促し、再操作における利便性を向上させることを可能にした通信端末および呼制御装置および通信プログラムを提供する。
【解決手段】
４０４ＮｏｔＦｏｕｎｄ通知を受けた通信端末では、通信要求を行なった際の通信情報である通信履歴や通信先を指定した指定方法等の情報に基づいて、４０４ＮｏｔＦｏｕｎｄ通知を受けた原因を特定する。また、その４０４ＮｏｔＦｏｕｎｄ通知に指定された情報に基づいて原因を特定するほか、その指定された情報を元に以後の処理を実行する。
【選択図】 図１

Description

本発明は、通信端末および呼制御装置および通信プログラムに関する。

ＨＴＴＰ（Hypertext Transfer Protocol）などの通信プロトコルを用いて行なわれるインターネット通信の際に、コンテンツ提供サイトが存在しない場合等にはサーバを見つけられなかったことが通知される。すなわち、エラーステータスにあることが通知される。

この場合、操作者は指定アドレスのスペルを確認するほか、他のコンテンツ提供サイトへアクセスを行なう。

特許文献１に開示された従来技術では、エラー発生頻度の高い宛先を設定してファクシミリ通信を行おうと試みた場合であっても、ファクシミリ通信が不成功のまま放置されてしまう事態を回避できるようにした技術が公開されている。

この特許文献１では、ファクシミリ通信における宛先に対する通信履歴を記録しておき、その通信履歴を元に宛先に係るエラー発生頻度を判定し、その結果を表示画面上に表示させている。

特開２００９−００５２９５号公報

本発明は、情報が取得できない原因を特定することでユーザに適切な対応を促し、再操作における利便性を向上させることを可能にした通信端末および呼制御装置および通信プログラムを提供することを目的とする。

上記目的を達成するため、請求項１の発明は、着呼側通信端末との呼接続に際し、該呼接続における呼制御を行う呼制御装置に対して通信要求を行う通信要求手段と、前記通信要求手段による通信要求に基づく前記着呼側通信端末の通信状態を前記呼制御装置から受信する受信手段と、前記受信手段により受信した通信状態が前記着呼側通信端末と通信できない場合、前記通信要求に係る通信情報に基づいて当該着呼側通信端末と通信できない原因を特定する特定手段とを具備する。

また、請求項２の発明は、請求項１の発明において、前記特定手段は、他の通信端末との間における通信履歴から前記着呼側通信端末との通信履歴を検出し、該通信履歴に基づいて前記原因を特定する。

また、請求項３の発明は、請求項２の発明において、前記特定手段は、前記着呼側通信端末との前記通信履歴を検出できた場合であって該通信履歴により通信実績があるときには前記原因を前記着呼側通信端末における通信接続障害と特定し、前記通信履歴を検出できた場合であって該通信履歴により通信実績がないときには前記原因を前記着呼側通信端末の非存在と特定する。

また、請求項４の発明は、請求項２の発明において、前記特定手段は、前記着呼側通信端末との通信履歴が検出できた場合であって該通信履歴における通信実績が一定期間内のものであるときには前記原因を前記着呼側通信端末における通信接続障害と特定する。

また、請求項５の発明は、請求項１の発明において、前記通信要求手段は、呼接続先一覧にある通信端末に基づき前記呼接続を行う前記着呼側通信端末を指定して前記通信要求を行い、前記特定手段は、前記呼接続先一覧から指定した前記着呼側通信端末と通信できない場合には前記原因を該着呼側通信端末における通信接続障害と特定する。

また、請求項６の発明は、請求項１の発明において、前記着呼側通信端末は、前記呼制御装置に登録された登録状態を保留とする保留時間を当該呼制御装置に通知する通知手段を具備し、前記呼制御装置は、前記通知手段によって前記着呼側通信端末から前記保留時間が通知されることにより登録期間の満了以後、該保留時間の経過まで前記着呼側通信端末を保留状態として管理する状態管理手段を具備し、前記受信手段は、前記通信要求手段によって通信要求した前記着呼側通信端末との通信状態が保留状態であることを前記呼制御装置から受信し、前記特定手段は、前記受信手段によって保留状態であると受信することにより前記原因を前記着呼側通信端末における通信接続障害と特定する。

また、請求項７の発明は、請求項３乃至６のいずれかの発明において、前記通信要求手段は、前記特定手段によって前記原因が前記着呼側通信端末における通信接続障害であると特定された場合に、再度、着呼側通信端末との呼接続に際して前記呼制御装置に対して通信要求を行う。

また、請求項８の発明は、請求項１の発明において、前記受信手段は、前記着呼側通信端末との通信状態とともに動作指示情報を受信する。

また、請求項９の発明は、請求項８の発明において、前記受信手段によって受信した動作指示情報に係る前記原因を提示する宛先情報に基づいて接続する接続手段を更に具備し、前記特定手段は、前記接続手段によって接続した宛先情報に基づく宛先に提示された前記原因で特定する。

また、請求項１０の発明は、請求項８の発明において、前記通信要求手段は、前記受信手段によって受信した動作指示情報に係る指定時刻通信要求に基づいて指定時刻に再度、通信要求を行う。

また、請求項１１の発明は、請求項１または８の発明において、前記呼制御装置は、前記着呼側通信端末から登録要求を受け付けることにより前記着呼側通信端末へ前記着呼側通信端末の通信状態を通知する通知手段を具備し、前記通信要求手段は、前記通知手段によって通信状態が通知されることにより前記着呼側通信端末との呼接続における通信要求を前記呼接続装置に行う。

また、請求項１２の発明は、通信端末間の呼制御に際し、発呼側通信端末からの呼接続によって着呼側通信端末に通信要求を行う通信要求手段と、前記通信要求手段による通信要求に対して前記着呼側通信端末との通信状態を検出する状態検出手段と、前記状態検出手段によって検出した通信状態が前記着呼側通信端末が検知できない状態である場合に、前記通信要求に係る通信情報に基づいて当該着呼側通信端末と通信できない原因を特定する特定手段とを具備する。

また、請求項１３の発明は、請求項１２の発明において、前記特定手段は、通信端末間における通信履歴から前記呼出 先通信端末が検知できない状態にある前記着呼側通信端末との通信履歴を検出し、該通信履歴に基づいて前記原因を特定する。

また、請求項１４の発明は、コンピュータを、着呼側通信端末との呼接続に際し、該呼接続における呼制御を行う呼制御装置に通信要求を行う通信要求手段、前記通信要求手段による通信要求に基づく前記着呼側通信端末の通信状態を前記呼制御装置から受信する受信手段、前記受信手段により受信した通信状態が前記着呼側通信端末と通信できない場合、前記通信要求に係る通信情報に基づいて当該着呼側通信端末と通信できない原因を特定する。

本発明の請求項１によれば、情報が取得できない原因を特定することでユーザに適切な対応を促し、再操作における利便性を向上させることが可能になるという効果を奏する。

また、請求項２によれば、通信履歴に基づいて情報が取得できない原因を特定することが可能になるという効果を奏する。

また、請求項３によれば、通信履歴に基づいて詳細な原因を特定することが可能になるという効果を奏する。

また、請求項４によれば、通信履歴の状態に基づいて情報が取得できない原因を特定することが可能になるという効果を奏する。

また、請求項５によれば、呼接続先一覧を用いて着呼側通信端末を指定したか否かによって、情報が取得できない原因を特定することが可能になるという効果を奏する。

また、請求項６によれば、着呼側通信端末が登録された状態にあっても保留状態となっている場合には通信接続障害によって情報が取得できない原因であると特定することが可能になるという効果を奏する。

また、請求項７によれば、通信接続障害から復帰している場合に、再度通信要求の操作をユーザが行なうことなく、情報を取得することが可能になるという効果を奏する。

また、請求項８によれば、特定の通信状態にある場合においても動作指示情報に示す情報に基づいて最適な対応を促すことが可能になるという効果を奏する。

また、請求項９によれば、動作指示情報で示された宛先情報によって示された宛先にある情報に基づいて最適な対応を促すことが可能になるという効果を奏する。

また、請求項１０によれば、指定時刻に、再度通信要求の操作をユーザが行なうことなく通信要求を行なうことによって情報を取得することが可能になるという効果を奏する。

また、請求項１１によれば、通信予約された着呼側通信端末から登録要求を受け付けることにより、再度通信要求の操作をユーザが行なうことなく通信要求を行なうことによって情報を取得することが可能になるという効果を奏する。

また、請求項１２によれば、情報が取得できない原因を特定することでユーザに適切な対応を促し、再操作における利便性を向上させることが可能になるという効果を奏する。

また、請求項１３によれば、通信履歴に基づいて情報が取得できない原因を特定することが可能になるという効果を奏する。

また、請求項１４によれば、情報が取得できない原因を特定することでユーザに適切な対応を促し、再操作における利便性を向上させることが可能になるという効果を奏する。

本発明の実施の形態における通信端末および呼制御装置および通信プログラムを適用して構成した通信システムの構成図の一例。 呼接続の処理遷移を示す図。 呼接続の処理遷移を示す図。 本発明の実施の形態におけるＩＰ通信端末の詳細な構成を示す図。 本発明の実施の形態における呼制御サーバの詳細な構成を示す図。 本発明の実施の形態におけるＩＰ通信端末によって行なわれる詳細な処理の流れを示すフローチャート。 着呼側ＩＰ通信端末との通信に関する情報として、宛先の指定方法を判断条件として判断する処理の流れを示すフローチャート。 着呼側ＩＰ通信端末との通信に関する情報として、通信履歴情報を用いて判断する処理の流れを示すフローチャート。 本発明の実施の形態における呼制御サーバによって行なわれる詳細な処理の流れを示すフローチャート。 ＩＰ通信端末から保留情報を受信する場合における処理シーケンスを示す図。 参照先情報が呼制御サーバに設定された場合における処理シーケンスを示す図。 時刻指定がされている場合における処理シーケンスを示す図。 自動再要求機能を用いた処理シーケンスを示す図。

以下、本発明に係わる通信端末および呼制御装置および通信プログラムの一実施例を添付図面を参照して詳細に説明する。

図１は、本発明の実施の形態における通信端末および呼制御装置および通信プログラムを適用して構成した通信システムの構成図の一例である。

この図１には、ネットワークＡとネットワークＢの２つの通信ネットワークが通信回線によって接続された通信ネットワークが示されており、ネットワークＡは、音声や映像などのマルチメディア情報の情報通信を行なう通信端末であるＩＰ通信端末Ａ−１（１００Ａ−１）、ＩＰ通信端末（１００Ａ−２）と、ＩＰ通信端末同士の情報通信における通信セッション（セション）の確立のための呼制御を行なう呼制御サーバ２００を具備して構成される。

また、ネットワークＢは、音声や映像などのマルチメディア情報の情報通信を行なう通信端末であるＩＰ通信端末Ｂ−１（１００Ｂ−１）、ＩＰ通信端末（１００Ｂ−２）を具備して構成される。

なお、図１では、呼制御サーバ２００をネットワークＡにのみ設置し、ネットワークＡとネットワークＢのドメインが同一である場合のネットワーク構成を示しているが、これに限定されることなく、ネットワークＡおよびネットワークＢそれぞれに呼制御サーバを設置し、ネットワークＡとネットワークＢとが異なるドメインを構成するような構成であってもよい。

呼制御サーバ２００は、ＩＰ通信端末からＤＨＣＰ（Dynamic Host Configuration Protocol）などを用いたＩＰアドレスの設定要求を受信すること等によりＩＰアドレスとＩＰ通信端末間の情報通信におけるセッションの確立に使用するＵＲＩ（Uniform Resource Identifier）とを対応付けて、レジストラサーバがロケーションサーバ内に登録する。これにより、ロケーションサーバ内には、呼制御サーバ２００の同一ドメイン内のユーザエージェントであるＩＰ通信端末のロケーション情報（位置情報）（「バインディング情報」ともいう）としてＩＰアドレスとＵＲＩとの対応関係、バインディング情報の有効期間の情報が蓄積された状態となる。

このバインディング情報は、ＩＰ通信端末から有効期間が経過する前に再度、更新処理が行なわれることによって延長されるほか、ＩＰ通信端末からの保留要求によってもその有効期間が延長される。

このようにして、ロケーションサーバによってＩＰアドレスとＵＲＩとの対応関係が登録された状態において、ＩＰ通信端末からＵＲＩによって通信先のＩＰ通信端末を指定した通信リクエストを受信すると、リダイレクトサーバがそのＵＲＩに対応するＩＰアドレスをロケーションサーバ内を検索し、該当するＩＰアドレスを要求元のＩＰ通信端末へ応答する。

この呼制御サーバ２００におけるプロトコルとして、例えばＨ．３２３プロトコルやＳＩＰ（Session Initiation Protocol）があり、このうちＳＩＰを用いた呼制御サーバを特に「ＳＩＰサーバ」と称呼する。

もちろん、呼制御サーバ２００にロケーションサーバを設けてバインディング情報を管理するのではなく、他の外部ネットワーク装置によってこのバインディング情報を管理するような構成であってもよい。この場合、呼制御サーバ２００のリダイレクトサーバがバインディング情報を管理する外部ネットワーク装置にバンディング情報の検索要求を行ない、その検索要求に該当するバインディング情報を取得する。

また、このロケーションサーバが蓄積するバインディング情報には、ＵＲＩとＩＰアドレスの対応関係のほかそのＩＰ通信端末に関する通信情報をも対応付けて管理することも可能である。

図２および図３は、ＩＰ通信端末からの通信要求に基づいて呼制御サーバ２００が呼制御を行なうことにより発呼側のＩＰ通信端末（以下、「発呼側ＩＰ通信端末」という）と着呼側のＩＰ通信端末（以下、「着呼側ＩＰ通信端末」という）が行なう呼接続の処理遷移を示している。

図２は、発呼側ＩＰ通信端末と着呼側ＩＰ通信端末との呼接続により通信セッションが確立した場合における処理遷移を示し、図３は、発呼側ＩＰ通信端末と着呼側ＩＰ通信端末との呼接続により通信セッションが確立できなかった場合における処理遷移を示している。

図２において、着呼側ＩＰ通信端末が着呼側ＩＰ通信端末をＵＲＩで指定した通信要求（ＩＮＶＩＴＥリクエスト）を呼制御サーバに行ない、呼制御サーバは通信要求で指定されたＵＲＩの着呼側ＩＰ通信端末に対して通信要求を転送する。このとき、呼制御サーバは着呼側ＩＰ通信端末に対して呼び出し中であるステータス情報（Ｔｒｙｉｎｇ）を通知する。

そして、着呼側ＩＰ通信端末に通信要求が行なわれると、この着呼側ＩＰ通信端末では通信要求で指定された処理機能が応答することで呼制御サーバに対して通信応答（２００ ＯＫ）を通知する。呼制御サーバでは、通信要求で指定されたＵＲＩに対するＩＰアドレスをリダイレクトサーバがロケーションサーバ内から検索し、ＩＰアドレスを含む通信応答を生成して要求元ＩＰ通信端末へ転送する。

これにより、発呼側ＩＰ通信端末は着呼側ＩＰ通信端末のＩＰアドレスを取得し、そのＩＰアドレスにより示される着呼側ＩＰ通信端末へＡＣＫ情報を送信することでセッションを確立する。

以後、発呼側ＩＰ通信端末と着呼側ＩＰ通信端末は、上位プロトコルによるデータ通信を行なう。

続いて、図３において、図２と同様、発呼側ＩＰ通信端末が着呼側ＩＰ通信端末をＵＲＩで指定した通信要求（ＩＮＶＩＴＥリクエスト）を呼制御サーバに行な行なう。

このとき、呼制御サーバは発呼側ＩＰ通信端末に対して呼び出し中であるステータス情報（Ｔｒｙｉｎｇ）を通知する。

呼制御サーバは、通信要求で指定されたＵＲＩの着呼側ＩＰ通信端末に対して通信要求を転送する。このとき、図３（ａ）に示すように指定間違いで等によりＵＲＩが見つからない場合には、通信要求を転送できず発呼側ＩＰ通信端末に対して「４０４ＮｏｔＦｏｕｎｄ通知」を行なう。

また、図３（ｂ）に示すように、通信要求を転送後、呼制御サーバでは、着呼側ＩＰ通信端末からの通信応答の待ち状態となるが、一定時間を経過しても通信応答を受信しない場合には、着呼側ＩＰ通信端末に対して「４０４ＮｏｔＦｏｕｎｄ通知」を行なう。

この「４０４ＮｏｔＦｏｕｎｄ通知」は、発呼側ＩＰ通信端末からの通信要求に対応する着呼側ＩＰ通信端末が通信遮断した状態や未起動の状態などによって存在しない場合のほか、ＵＲＩがＳＩＰサーバで見つからなかったことを示す通知である。

図４は、本発明の実施の形態におけるＩＰ通信端末の詳細な構成を示す図である。

図４において、ＩＰ通信端末１００は、受信部１０１、解析部１０２、情報制御部１０３、履歴検索部１０４、宛先指定方法判断部１０５、履歴記憶部１０６、原因特定部１０７、呼接続処理部１０８、処理情報作成部１０９、送信部１１０、ユーザインターフェース１１１を具備して構成される。

発呼側のＩＰ通信端末における呼接続処理部１０８は、着呼側ＩＰ通信端末との呼接続に際して着呼側ＩＰ通信端末のＵＲＩが指定された通信要求（ＩＮＶＩＴＥリクエスト）を作成し、その通信要求を送信部１１０を介して呼制御サーバへ送信する。

着呼側のＩＰ通信端末は、呼制御サーバより通信要求を受信部１０１で受信し、通信要求を解析部１０２へと通知する。解析部１０２では、受信した情報が通信要求であることを解析すると、呼制御処理部１０８へと通知する。

このとき、呼制御処理部１０８では、通信要求された機能の状態などを確認した後に通信応答を作成して送信部１１０へと通知する。送信部１１０では呼制御処理部１０８で作成された通信応答を呼制御サーバへと送信する。

このようにして、呼制御サーバを介して発呼側ＩＰ通信端末と着呼側ＩＰ通信端末との間でセッションが確立される。以後、発呼側ＩＰ通信端末と着呼側ＩＰ通信端末が上位プロトコルを用いて、ダイレクトに通信を行なう。

また、呼接続処理部１０８では、呼制御サーバのロケーションサーバに登録されたバインディング情報を登録するために、一定期間の経過後に有効期間の更新要求を呼制御サーバに行なう。

さらに、この呼接続処理部１０８では、ロケーションサーバに登録されたバインディング情報を保留状態へ移行するために、処理情報作成部１０９で作成した処理情報を付与した保留要求を行なうことができる。この場合、呼制御サーバは保留要求を受信すると、レジストラサーバが処理情報に基づいてバインディング情報を保留する。

この保留要求によってＩＰ通信端末の状態を保留状態とする場合、ＩＰ通信端末から呼制御サーバに対して「REGISTER sip:reg.example.com SIP/2.0」という保留要求とともに処理情報として「Expires:86400,Contact:<sip:xxx@xx.xx.xx.xx>:expires=0>」という情報を送信する。

これによって、呼制御サーバでは「xxx@xx.xx.xx.xx」というＩＰ通信端末を「86400秒」間（24時間）、保留状態（ペンディング状態）とする。

また、発呼側のＩＰ通信端末における呼接続処理部１０８から送信部１１０を介して呼制御サーバへ送信した通信要求を、呼制御サーバが着呼側のＩＰ通信端末へと送信した場合に、その着呼側ＩＰ通信端末からその通信要求に対する応答が一定時間以上、行われない場合若しくは指定間違いで等でＵＲＩが見つからないことにより通信要求を受けることができない場合、発呼側のＩＰ通信端末は、呼制御サーバから４０４ＮｏｔＦｏｕｎｄ通知を受信部１０１を介して受信する。

呼制御サーバでは、４０４ＮｏｔＦｏｕｎｄ通知に着呼側ＩＰ通信端末との通信ができない原因となる情報を付加することができる。

例えば、通信要求で指定された着呼側ＩＰ通信端末に関する情報が呼制御サーバのロケーションサーバに登録されていない場合には４０４ＮｏｔＦｏｕｎｄ通知のヘッダー情報に付加する付加情報として「warn-code」の項目に「Warning 390 SIP サーバ名 "Not Recorded"」を指定することで着呼側ＩＰ通信端末がネットワーク上に存在しないことを通知することができる。

また、ロケーションサーバに着呼側ＩＰ通信端末の通信状態として通信保留や通信拒絶、通信障害などの情報が登録されている場合には４０４ＮｏｔＦｏｕｎｄ通知のヘッダー情報に付加する付加情報として「warn-code」の項目に「Warning 390 SIP サーバ名 "Not Ready"」を指定することで着呼側ＩＰ通信端末に通信障害が発生していることを通知することができる。

このとき、受信部１０１は、この４０４ＮｏｔＦｏｕｎｄ通知を解析部１０２へと通知し、解析部１０２は、受信した情報が４０４ＮｏｔＦｏｕｎｄ通知であると解析すると、情報制御部１０３へとその４０４ＮｏｔＦｏｕｎｄ通知を転送する。

情報制御部１０３では、４０４ＮｏｔＦｏｕｎｄ通知の通信情報に基づいて着呼側ＩＰ通信端末とセッションの確立ができない原因と関連する情報の制御処理を行なう。この情報制御部１０３では、履歴検索部１０４、宛先指定方法判断部１０５を具備し、４０４ＮｏｔＦｏｕｎｄ通知のヘッダー情報に「warn-code」の項目等による付加情報が付加されていない場合に、これらの履歴検索部１０４、宛先指定方法判断部１０５に基づいて情報の制御処理を行なう。

履歴検索部１０４は、４０４ＮｏｔＦｏｕｎｄ通知の通信情報に対してこの４０４ＮｏｔＦｏｕｎｄ通知の通知元である着呼側ＩＰ通信端末との通信履歴を検索する。

この履歴検索部１０４は、履歴記憶部１０６で記憶する通信履歴に着呼側ＩＰ通信端末との通信履歴が含まれるかを検索する。履歴記憶部１０６では着呼側ＩＰ通信端末を識別する通信端末ＩＤ、ＵＲＩ、ＩＰアドレスに対応付けて通信日時、通信時間、通信状態等の通信履歴情報を記憶している。なお、この履歴記憶部１０６はＩＰ通信端末が記憶するのではなく、ネットワーク上のデータベース（図示せず）上に記憶するほか、呼制御サーバが個々のＩＰ通信端末ごとに管理して記憶するような構成とすることが可能である。この場合、着呼側ＩＰ通信端末が記憶元に通信履歴情報を問い合わせ、その問い合わせに対して応答される通信履歴情報から検索する。

履歴検索部１０４では、着呼側ＩＰ通信端末のＵＲＩに基づいて通信履歴情報を検索するほか、呼制御サーバから通信履歴情報に対する４０４ＮｏｔＦｏｕｎｄ通知として着呼側ＩＰ通信端末のＩＰアドレスが応答された場合にはそのＩＰアドレスに基づいて通信履歴情報を検索してもよい。

さらに、この履歴検索部１０４には、通信履歴情報の検索条件を設定することができ、その検索条件に合致する着呼側ＩＰ通信端末との通信履歴を検索する。この検索条件の一例として、検索する通信履歴情報の期間によって指定され、履歴検索部１０４は、その検索期間内に通信履歴情報が存在するかを検索する。この場合、着呼側ＩＰ通信端末との間における通信履歴情報が存在した場合であってもこの検索条件で定める検索期間内の通信履歴情報が存在しない場合には通信履歴情報が存在しないものとする。

また、情報制御部１０３を構成する宛先指定方法判断部１０５は、呼接続処理部１０８で呼接続に際して着呼側のＩＰ通信端末を指定する際に用いた宛先指定情報および宛先情報を保持しており、この宛先指定情報を元に宛先の指定方法を判断する。

呼接続処理部１０８における着呼側のＩＰ通信端末を指定する方法として、着呼側のＩＰ通信端末を直接入力により指定する方法のほかアドレス帳などの呼接続先一覧を用いて指定する方法がある。宛先指定情報は、着呼側のＩＰ通信端末の指定方法が、直接入力であるか若しくは呼接続先一覧を用いた方法であるかの情報である。

そして、情報制御部１０３は、履歴検索部１０４によって着呼側ＩＰ通信端末との通信履歴が存在することおよび宛先指定方法判断部１０５によって宛先の指定方法が呼接続先一覧を用いた方法と判断された場合に、その旨を原因特定部１０７へと通知する。

このとき、原因特定部１０７は、４０４ＮｏｔＦｏｕｎｄ通知が行なわれた着呼側ＩＰ通信端末との間における通信エラーは、着呼側ＩＰ通信端末に通信接続障害が発生していることが原因であると特定する。

また、情報制御部１０３は、履歴検索部１０４によって着呼側ＩＰ通信端末との通信履歴が存在しないことおよび宛先指定方法判断部１０５によって宛先の指定方法が直接入力を用いた方法と判断された場合に、その旨を原因特定部１０７へと通知する。

このとき、原因特定部１０７は、４０４ＮｏｔＦｏｕｎｄ通知が行なわれた着呼側ＩＰ通信端末との間における通信エラーは、着呼側ＩＰ通信端末がネットワーク上に存在しないことが原因であると特定する。

これに対して、呼制御サーバから受信した４０４ＮｏｔＦｏｕｎｄ通知のヘッダー情報に付加情報が付加されている場合に情報制御部１０３は、情報制御部１０３が具備する履歴検索部１０４、宛先指定方法判断部１０５による情報を用いることなく、付加情報を原因特定部１０７へと通知する。

これにより、原因特定部１０７は、その付加情報を元に４０４ＮｏｔＦｏｕｎｄ通知となった原因を特定する。

すなわち、付加情報が「Warning 390 SIP サーバ名 "Not Recorded"」である場合には、着呼側ＩＰ通信端末がネットワーク上に存在しないことが原因と特定し、付加情報が「Warning 390 SIP サーバ名 "Not Ready"」である場合には、着呼側ＩＰ通信端末に通信障害が発生していることが原因であると特定する。

この原因特定部１０７では、４０４ＮｏｔＦｏｕｎｄ通知の原因となる情報をユーザインターフェース１１１を構成する表示ディスプレイに表示する。例えば、通信障害が発生していることが原因であると特定された場合には「通信先デバイスの状態を確認した後に、再操作してください。」というメッセージを表示する。また、ネットワーク上に存在しないことが原因であると特定された場合には「通信先が見つかりません。あて先を確認し、正しいあて先を入力してください。」というメッセージを表示する。

なお、４０４ＮｏｔＦｏｕｎｄ通知のヘッダー情報に「Error-Info」ヘッダーが付与され、エラー詳細表示情報が付与されている場合にユーザインターフェース１１１の表示ディスプレイには、その「Error-Info」ヘッダーによって示される情報若しくはその情報によって示される参照先にある情報を表示する。例えば、「土、日曜日は受信できません。月曜日の午前８時以降に送信願いします。」とか、「ただいいまメンテナンス中です。番号[xx-xxxx-xxxx]へ送信願います。」と表示する。

さらに、４０４ＮｏｔＦｏｕｎｄ通知のヘッダー情報に「Retry-after」ヘッダーと指定時刻が付与され（例えば、「Retry-after:1800」）、指定時刻再要求情報が付与されている場合にはユーザインターフェース１１１の表示ディスプレイに、その時刻指定がされていることおよび指定時刻を表示する。

また、原因特定部１０７は、特定した原因が「着呼側ＩＰ通信端末に通信障害が発生していること」である場合、呼接続処理部１０８に対して再度、その着呼側ＩＰ通信端末に通信要求を行なうように指示する。このとき呼接続処理部１０８では、直前の通信要求（ＩＮＶＩＴＥリクエスト）の送信から一定時間（保留状態にある場合には保留時間の経過後の一定時間）の経過後（例えば、３０分経過後）再度、着呼側ＩＰ通信端末に通信要求を行なう。このときの宛先として宛先指定方法判断部１０５が保持する宛先情報を用いることで再通信要求（リダイアル処理）を行なう。

さらに、呼接続処理部１０８は、受信部１０１で４０４ＮｏｔＦｏｕｎｄ通知を受信し、解析部１０２で４０４ＮｏｔＦｏｕｎｄ通知であってそのヘッダー情報に許可イベントの情報が示されていることを解析部１０２から通知されることによって、呼制御サーバに対して自動再要求の予約通知を行なう。

例えば、ヘッダー情報に「Allow-Events:dialog,・・・」が設定されていることにより許可イベントの情報が示されていると解析部１０２では解析し、この場合、呼制御サーバに対して「SUBSCRIBE EVENT:dialog」と自動再要求の予約通知を行なう。

このとき、呼制御サーバでは、４０４ＮｏｔＦｏｕｎｄ通知を行なうこととなった着呼側ＩＰ通信端末から登録要求を受けた場合に、その旨を予約通知することを設定する。

そして、着呼側ＩＰ通信端末から登録要求を受けて呼制御サーバが発呼側ＩＰ通信端末に登録要求を受けたことを通知すると、呼接続処理部１０８では、自動再要求を行なう。

図５は、本発明の実施の形態における呼制御サーバの詳細な構成を示す図である。

図５において、呼制御サーバ２００は、受信部２０１、呼制御部２０２、記憶部２０３、更新処理部２０４、期限管理部２０５、ＩＰ通信端末情報記憶部２０６、情報作成部２０７、送信部２０８、更新登録部２０９、情報検索部２１０を具備して構成する。

ＩＰ通信端末情報記憶部２０６は、独自ドメイン内のＩＰ通信端末に関するバインディング情報を記憶している。この端末情報として、ＩＰ通信端末のＵＲＩとＩＰアドレスを対応付けて記憶するほか、ＩＰ通信端末の通信状態が付加されて記憶されている。

なお、このＩＰ通信端末情報記憶部２０６では、各ＩＰ通信端末との通信履歴を記憶することができ、図４に示すＩＰ通信端末の履歴記憶部１０６で記憶する通信履歴と同一のものを記憶する。

期限管理部２０５は、ＩＰ通信端末情報記憶部２０６で記憶するＩＰ通信端末のバインディング情報の有効期限に基づいてバインディング情報を削除するほか、無効とする期限管理を行なう。バインディング情報が保留状態にある場合にはその保留状態の経過後に期限管理を行なう。

受信部２０１では、ＩＰ通信端末よりバインディング情報の更新要求や登録要求、保留状態への移行要求を受信し、呼制御部２０２へと通知する。

呼制御部２０２では、受信部２０１がこれらの情報を受信したと判断する場合には情報処理部２０４に処理要求を行なう。情報処理部２０４の更新登録部２０９は、ＩＰ通信端末情報記憶部２０６で記憶するＩＰ通信端末の情報を更新し、登録し、そのＩＰ通信端末の通信状態を保留状態へ移行する。

ＩＰ通信端末からＩＰ通信端末の登録要求を受けた場合には、情報処理部２０４の更新登録部２０９は、ＩＰ通信端末のＩＰアドレスとＵＲＩとを対応付けて管理するとともに有効期間を設定してＩＰ通信端末情報記憶部２０６に登録する。また、更新要求を受けた場合には有効期間を延長する。

さらに、ＩＰ通信端末から処理情報として、「Expires:86400,Contact:<sip:xxx@xx.xx.xx.xx>:expires=0>」という情報を受信した場合、情報処理部２０４は、ＵＲＩが「xxx@xx.xx.xx.xx」であるＩＰ通信端末の通信状態を「86400秒」間（24時間）、保留状態（ペンディング状態）とする。

この保留状態とする情報を受信したときおよび保留状態にある着呼側ＩＰ通信端末への通信要求に対する応答の処理シーケンスを図１０に示し、以下で説明する。

さらに、情報処理部２０４は、バインディング情報保留期間を設定することができ、この保留期間が設定されている場合であって、期限管理部２０５により管理された有効期限を経過すると、ＩＰ通信端末の通信状態を一定期間、保留状態とする。

そして、発呼側ＩＰ通信端末から通信要求（ＩＮＶＩＴＥリクエスト）を受信部２０１で受信すると、受信部２０１は、その通信要求を呼制御部２０２へと通知する。呼制御部２０２では、通信要求で指定された着呼側ＩＰ通信端末が独自ドメイン（「責任ドメイン」ともいう）に所属するものであるかをドメインテーブルを用いて判断し、属さない場合には送信部２０８に通知し、プロキシサーバによってドメインテーブルに関する情報の交換を行なう他の呼制御サーバへと送信する。

また、通信要求で指定された着呼側ＩＰ通信端末が独自ドメインに属する場合には、情報処理部２０４へと情報処理要求を行なう。この情報処理部２０４は、更新登録部２０９、情報検索部２１０を具備し、情報検索部２１０は、呼制御部２０２からの情報処理要求に基づいてＩＰ通信端末情報記憶部２０６で記憶する着呼側ＩＰ通信端末の情報を検索する。

ＩＰ通信端末情報記憶部２０６は、独自ドメイン内のＩＰ通信端末に関するバインディング情報を記憶している。この端末情報として、ＩＰ通信端末のＵＲＩとＩＰアドレスを対応付けて記憶するほか、ＩＰ通信端末の通信状態が付加されて記憶されている。

なお、このＩＰ通信端末情報記憶部２０６では、各ＩＰ通信端末との通信履歴を記憶することができ、図４に示すＩＰ通信端末の履歴記憶部１０６で記憶する通信履歴と同一のものを記憶する。

もちろん、ＩＰ通信端末の履歴記憶部１０６で通信履歴を記憶するのではなく、呼制御サーバ２００のＩＰ通信端末情報記憶部２０６のみで通信履歴を記憶し、ＩＰ通信端末から通信履歴の検索要求を受信することで呼制御サーバ２００の情報処理部２０４の情報検索部２１０がＩＰ通信端末情報記憶部２０６で記憶する通信履歴情報を検索し、該当する情報がある場合に応答するような構成としてもよい。

そして、情報検索部２１０によって着呼側ＩＰ通信端末の情報が検索されると、情報処理部２０４は、通信要求に含まれるＵＲＩに対するＩＰアドレスの情報を呼制御部２０２に通知し、情報検索部２１０は、情報作成部２０７に着呼側ＩＰ通信端末の情報が検索されたことを通知する。情報作成部２０７は、その情報に付加された通信状態に基づいて付加情報を作成できる場合には作成し、呼制御部２０２へと通知する。情報作成部２０７は、着呼側のＩＰ通信端末の通信状態が保留状態にある場合にはそのＩＰ通信端末が保留状態にある旨を示す情報を作成して呼制御部２０２へと通知する。

呼制御部２０２では、情報処理部２０４から通知されたＵＲＩに対するＩＰアドレスの情報に情報作成部２０７で作成された付加情報を付加して、通信要求を行なった発呼側のＩＰ通信端末に送信部２０８を介して送信する。

また、情報検索部２１０によって着呼側ＩＰ通信端末の情報（バインディング情報および通信履歴情報）が検索できない場合、情報処理部２０４はその旨を呼制御部２０２へと通知する。このとき、呼制御部２０２では、「４０４ＮｏｔＦｏｕｎｄ通知」の作成を情報作成部２０７に要求し、情報作成部２０７が４０４ＮｏｔＦｏｕｎｄ通知を作成して呼制御部２０２に応答する。

呼制御部２０２では、送信部２０８を介して着呼側ＩＰ通信端末に４０４ＮｏｔＦｏｕｎｄ通知を送信する。

図６は、本発明の実施の形態におけるＩＰ通信端末によって行なわれる詳細な処理の流れを示すフローチャートである。

図６において、ＩＰ通信端末は、呼制御サーバに対して通信要求（ＩＮＶＩＴＥリクエスト）を行ない（６０１）、それに対して呼制御サーバより応答の受信まちとなる。応答を受信したかを判断し（６０２）、応答を受信していない場合（６０２でＮＯ）には受信するまで待つ。応答を受信した場合（６０２でＹＥＳ）には、その応答が４０４ＮｏｔＦｏｕｎｄ通知であるかを判断し（６０３）、４０４ＮｏｔＦｏｕｎｄ通知でない場合（６０３でＮＯ）には処理を終了する。

また、４０４ＮｏｔＦｏｕｎｄ通知を受信した場合（６０３でＹＥＳ）には、その通知に付加情報があるかを判断する（６０４）。

付加情報が付加されている場合（６０４でＹＥＳ）には、通信できない原因の情報であるかを判断する（６０５）。通信できない原因の情報が付加されている場合（６０５でＹＥＳ）には、その原因の情報を表示ディスプレイ等に表示するなどの報知を行なう（６０６）。

そして、その原因が通信接続障害であるかを判断し（６０７）、原因が通信接続障害でない場合（６０７でＮＯ）であって着呼側のＩＰ通信端末が存在しない場合には処理を終了する。また、原因が通信接続障害である場合（６０７でＹＥＳ）には、一定時間を計時し（６０８）、一定時間が経過したかを判断する（６０９）。

一定時間を経過するまではその一定時間を計時し、一定時間を経過した場合（６０９でＹＥＳ）には、再度、呼制御サーバに対して通信要求を行ない（６０１）、上記の処理を繰り返して行なう。

これに対して、４０４ＮｏｔＦｏｕｎｄ通知に付加情報が付加されており、その付加情報が着呼側ＩＰ通信端末と通信できない原因を示す情報であるかの判断によって、通信ができない原因を示す情報でない場合（６０５でＮＯ）には、続いて、原因を示す情報を参照する参照先情報（リンク情報）であるかを判断する（６１４）。

参照先情報である場合（６１４でＹＥＳ）には、その参照先情報に基づいて原因を示す情報へアクセスする（６１５）。そして、その原因を示す情報を取得して（６１６）、４０４ＮｏｔＦｏｕｎｄ通知がされた原因を特定する（６１７）。そして、この特定した原因が通信接続障害であるかを判断し（６０７）、原因が通信接続障害でない場合（６０７でＮＯ）であって着呼側のＩＰ通信端末が存在しない場合には処理を終了する。

また、原因が通信接続障害である場合（６０７でＹＥＳ）には、一定時間を計時し（６０８）、一定時間が経過したかを判断する（６０９）。上記同様、一定時間を経過するまではその一定時間を計時し、一定時間を経過した場合（６０９でＹＥＳ）には、再度、呼制御サーバに対して通信要求を行ない（６０１）、上記の処理を繰り返して行なう。

そして、付加情報が参照先情報でない場合（６１４でＮＯ）には、続いて、指定時刻情報が付加情報として付加されているかを判断する（６１８）。指定時刻情報が設定されている場合（６１８でＹＥＳ）には、その指定された時刻を計時し（６１９）、指定された時刻となることにより再度、呼制御サーバに対して通信要求を行なう（６０１）。

指定時刻情報が付加情報として付加されていない場合（６１８でＮＯ）には、処理を終了する。

続いて、呼制御サーバより４０４ＮｏｔＦｏｕｎｄ通知が行なわれ、付加情報が付加されているかの判断処理によって、付加情報が付加されていない場合（６０４でＮＯ）について説明する。

この場合、着呼側ＩＰ通信端末との通信に関する情報に基づく判断処理を行なう（６１０）。この判断処理の詳細な流れを図７および図８に示す。

図７は、着呼側ＩＰ通信端末との通信に関する情報として、宛先の指定方法を判断条件として判断する処理の流れを示すフローチャートである。

図７において、着呼側ＩＰ通信端末との通信に関する情報として、着呼側のＩＰ通信端末を発呼側ＩＰ通信端末で指定した方法が、直接入力でなく、呼接続先一覧を用いた方法であるかを判断条件として判断する（７０１）。呼接続先一覧（アドレス帳）を用いて指定した場合（７０１でＹＥＳ）には、判断条件を満たすとして、判断条件に合致すると設定する（７０２）。

また、この判断条件を満たさない場合（７０１でＮＯ）には、通信履歴情報を用いて判断する処理（図８）を実行する。（７０３）。

図８は、着呼側ＩＰ通信端末との通信に関する情報として、通信履歴情報を用いて判断する処理の流れを示すフローチャートである。

図８において、着呼側ＩＰ通信端末との間の通信履歴情報を検索する（８０１）。この通信履歴情報は、上記に示すように、ＩＰ通信端末がそれぞれで記憶するほか、呼制御サーバが記憶する構成とすることができることから呼制御サーバが記憶している場合には、ＩＰ通信端末が呼制御サーバに通信履歴情報の検索要求を行ない、呼制御サーバが記憶している通信履歴を検索することによりその結果を応答するとともに合致する通信履歴がある場合にはその通信履歴情報を応答する。

この検索処理によって、着呼側ＩＰ通信端末の通信履歴が検索されたかを判断し（８０２）、通信履歴が検索された場合（８０２でＹＥＳ）には、続いて、一定期間内の通信履歴が存在するかを判断する（８０３）。一定期間内の通信履歴が存在する場合（８０３でＹＥＳ）には、通信履歴情報を判断条件とする条件に合致すると設定する（８０４）。

それに対して、検索処理によって通信履歴情報が検索されない場合（８０２でＮＯ）、および、通信履歴情報が検索された場合であっても一定期間内の通信履歴が存在しない場合（８０３でＮＯ）には、判断条件に合致しないと設定する（８０５）。

このようにして、図７および図８に示すような処理によって着呼側ＩＰ通信端末との通信に関する情報に基づく判断処理が行なわれると、続いて、判断条件に合致したか否かを判断する（６１１）。

図７および図８に示す判断処理によって判断条件を満たすと判断され、判断条件に合致することが設定されている場合（６１１でＹＥＳ）には、４０４ＮｏｔＦｏｕｎｄ通知がされた原因を、着呼側ＩＰ通信端末の通信接続障害が発生しているためであると特定する（６１２）。

それに対して、判断処理によって判断条件を満たすと判断され、判断条件に合致することが設定されていない場合（６１１でＮＯ）には、４０４ＮｏｔＦｏｕｎｄ通知がされた原因を、着呼側ＩＰ通信端末が存在していないためであると特定する（６１３）。

図９は、本発明の実施の形態における呼制御サーバによって行なわれる詳細な処理の流れを示すフローチャートである。

図９において、ＩＰ通信端末より通信要求（ＩＮＶＩＴＥリクエスト）を受信する（９０１）と、続いて、その通信要求を行なったＩＰ通信端末のＵＲＩにより示されるドメインが独自ドメインであるかを判断する（９０２）。独自ドメインであって呼制御サーバがＵＲＩに対するＩＰアドレスを記憶している場合（９０２でＹＥＳ）には、登録されているバインディング情報を検索する（９０３）。

それに対して、独自ドメインでない場合（９０２でＮＯ）には、ＩＰ通信端末より受信した通信要求を予め指定された他の呼制御サーバに転送する（９１６）。

そして、バンディング情報を検索した結果、バインディング情報が検索されたかを判断し（９０４）、バインディング情報が検索された場合（９０４でＹＥＳ）には、続いて、通信要求された着呼側ＩＰ通信端末が通信可能な状態にあるかを判断して（９１７）、通信可能な状態にある場合には通信要求で指定されたＵＲＩに対するＩＰアドレスを指定した通信応答を作成して、通信要求を行なったＩＰ通信端末に送信する（９１８）。

また、通信要求された着呼側ＩＰ通信端末が通信可能な状態にあると判断されない場合（９１７でＮＯ）には、そのバインディング情報が検索されたＩＰ通信端末が保留状態にあるかを判断する（９０５）。保留状態にある場合（９０５でＹＥＳ）には、着呼側ＩＰ通信端末が保留状態にあることを示す情報を付加した４０４ＮｏｔＦｏｕｎｄ通知を作成する（９０６）。

その４０４ＮｏｔＦｏｕｎｄ通知を通信要求を行なったＩＰ通信端末に送信する（９１０）。

また、バインディング情報を検索した結果、バインディング情報が検索できない場合（９０４でＮＯ）には、続いて、エラー情報の作成設定がされているかを判断する（９０７）。

設定されている場合（９０７でＹＥＳ）には、通信要求されたＩＰ通信端末のバインディング情報が記憶されていないというエラー情報を付加した４０４ＮｏｔＦｏｕｎｄ通知を作成する（９０８）。その４０４ＮｏｔＦｏｕｎｄ通知を通信要求を行なったＩＰ通信端末に送信する（９１０）。

それに対して、エラー情報の作成設定がされていない場合（９０７でＮＯ）には、付加情報等が付加されていない４０４ＮｏｔＦｏｕｎｄ通知の作成し（９０９）、その４０４ＮｏｔＦｏｕｎｄ通知を通信要求を行なったＩＰ通信端末に送信する（９１０）。

続いて、バインディング情報を記憶しており、ＩＰ通信端末が保留状態にないと判断された場合（９０５でＮＯ）には、以下のような処理を行なう。

着呼側のＩＰ通信端末と通信ができない原因となる情報への参照先情報（リンク情報）を作成することが設定されているかを判断し（９１１）、参照先情報を作成することが設定されている場合（９１１でＹＥＳ）には、参照先情報を作成し（９１４）、その参照先情報を付加情報として付加した４０４ＮｏｔＦｏｕｎｄ通知を作成する（９１５）。そして、その４０４ＮｏｔＦｏｕｎｄ通知を通信要求を行なったＩＰ通信端末に送信する（９１０）。

また、参照先情報を作成することが設定されていない場合（９１１でＮＯ）には、続いて、時刻指定を行なうことが設定されているかを判断する（９１２）。時刻指定を行なうことが設定されていない場合（９１２でＮＯ）には、呼制御サーバの処理能力を示す情報を付加した４０４ＮｏｔＦｏｕｎｄ通知を作成する（９０９）。

このときの呼制御サーバの処理能力を示す情報として、呼制御サーバがＡｕｔｏ−Ｒｅｔｒｙ機能（自動再要求機能）を有しているか否かを示す情報があって、呼制御サーバが自動再要求機能を有している場合にはこの４０４ＮｏｔＦｏｕｎｄ通知のヘッダーのAllow-Eventsにその旨を設定する。

そして、その４０４ＮｏｔＦｏｕｎｄ通知を通信要求を行なったＩＰ通信端末に送信する（９１０）。

また、時刻指定を行なうことが設定されているかの判断で時刻指定を行なうことが設定されている場合（９１２でＹＥＳ）には、保留時間の経過後の時刻をヘッダーのRetry-After項目に設定した４０４ＮｏｔＦｏｕｎｄ通知を作成する（９１３）。

例えば、「Retry-After:1800」と設定した場合には1800秒後の時刻を指定したこととなる。

そして、その４０４ＮｏｔＦｏｕｎｄ通知を通信要求を行なったＩＰ通信端末に送信する（９１０）。

図１０は、ＩＰ通信端末から保留情報を受信する場合における処理シーケンスを示す図である。

図１０において、ＩＰ通信端末は、呼制御サーバに対して「REGISTER sip:reg.example.com SIP/2.0」、「Expires:86400,Contact:<sip:xxx@xx.xx.xx.xx>:expires=0>」という情報を送信する。

これによって、呼制御サーバでは「xxx@xx.xx.xx.xx」というＩＰ通信端末を「86400秒」間（24時間）、保留状態に設定する。

これにより、８６４００秒の保留状態にあるＩＰ通信端末を着呼側ＩＰ通信端末として、通信要求を受信した呼制御サーバでは、「Waring:390 reg.example.com “Not Ready”」という情報を発行側のＩＰ通信端末へ送信する。

すなわち、通信接続障害が発生している状態であることを示す。

図１１は、参照先情報が呼制御サーバに設定された場合における処理シーケンスを示す図である。

図１１において、発呼側ＩＰ通信端末が呼制御サーバに通信要求を行なうと、呼制御サーバでは、通信要求で指定されたＵＲＩに対するＩＰアドレスの着呼側ＩＰ通信端末のバインディング情報の検索を行ない、検索されない場合には、ヘッダーのError-Infoの項目に参照先情報を付加して４０４ＮｏｔＦｏｕｎｄ通知を送信する。

これを受信した発呼側ＩＰ通信端末はＡＣＫ通知を呼制御サーバへ行なう。

そして、発呼側ＩＰ通信端末は付加された参照先情報に基づいて、情報の取得リクエストを行なう。図１１（ａ）に示す場合、その参照先情報が示す参照先が情報管理サーバであって、発呼側ＩＰ通信端末がその情報管理サーバからの情報の取得レスポンスを受けることで情報が取得できるようになる。

また、図１１（ｂ）に示す場合、参照先情報が示す参照先が呼制御サーバであって、発呼側ＩＰ通信端末がその呼制御サーバからの情報の取得レスポンスを受けることで情報が取得できるようになる。

図１２は、時刻指定がされている場合における処理シーケンスを示す図である。

図１２において、発呼側のＩＰ通信端末が通信要求を行ない、呼制御サーバから４０４ＮｏｔＦｏｕｎｄ通知を受信した場合において、この４０４ＮｏｔＦｏｕｎｄ通知のヘッダーに「Retry-After:1800」と指定されているときは、１８００秒後を指定時刻とする。

そして、１８００秒を経過すると、再度通信要求（ＩＮＶＩＴＥリクエスト）を行なう。

図１３は、自動再要求機能を用いた処理シーケンスを示す図である。

図１３において、発呼側ＩＰ通信端末が通信要求を呼制御サーバに対して行なうと、呼制御サーバが通信要求で指定されたＵＲＩに対するＩＰアドレスなどのバインディング情報を検索する。バインディング情報が検索できない等により呼制御サーバは、発呼側ＩＰ通信端末に対して４０４ＮｏｔＦｏｕｎｄ通知を送信する。

このときの４０４ＮｏｔＦｏｕｎｄ通知のヘッダー情報に「Allow-Events:dialog,・・・」を設定する。これにより、発呼側ＩＰ通信端末は、再度、通信要求を行なうことが可能であることを示す。

また、発呼側ＩＰ通信端末がこのヘッダー情報が付加された４０４ＮｏｔＦｏｕｎｄ通知を受信すると、呼制御サーバに対して自動再要求の予約通知として「SUBSCRIBE：EVENT:dialog」を通知する。これによって、呼制御サーバでは、この予約通知に対して通信予約を設定する。

そして、呼制御サーバでは、通信予約された着呼側通信端末からの登録要求（ＲＥＧＩＳＴＥＲリクエスト）を受信した場合にその着呼側通信端末からの登録要求がされたことを通知する通知先として発呼側ＩＰ通信端末を設定し、その発呼側ＩＰ通信端末に対して「２００ ＯＫ」を通知することで、発呼側ＩＰ通信端末がこの通知を受信する。

そして、呼制御サーバから「NOFITY（初期状態の通知）」を受信した発呼側ＩＰ通信端末では、初期状態をセットし、呼制御サーバに対して「２００ ＯＫ」を通知する。

その後、呼制御サーバが、着呼側ＩＰ通信端末から登録要求（ＲＥＧＩＳＴＥＲリクエスト）を受信した呼制御サーバでは、発呼側ＩＰ通信端末に対して「NOTIFY(Ready状態の通知)」を行ない、ダイアログイベント通知の終了を通知する。

そして、発呼側ＩＰ通信端末では、この「NOTIFY(Ready状態の通知)」を受信すると、着呼側通信端末が登録されたことを検知し、発呼側ＩＰ通信端末は、呼制御サーバに対して「２００ ＯＫ」を通知する。

これにより、発呼側ＩＰ通信端末では、再度、通信要求（ＩＮＶＩＴＥリクエスト）を行なう。

以上に示す実施の形態は、本発明の実施の一形態であって、これらの実施例に限定することなく、その要旨を変更しない範囲内で適宜変形して実施できるものである。

なお、本発明は、通信機能を備えた通信システムで上述の動作を実行させ、あるいは上述の手段を構成させるためのプログラムを格納した記録媒体（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等）から該プログラムをコンピュータにインストールし、これを実行させることにより、上述の処理を実行する通信システムを構成することも可能である。通信システムを構成するコンピュータは、システムバスを介してＣＰＵ（Central Processor Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ハードディスクが接続されている。ＣＰＵは、ＲＯＭまたはハードディスクに記憶されているプログラムに従い、ＲＡＭを作業領域にして処理を行う。

また、プログラムを供給するための媒体は、通信媒体（通信回線、通信システムのように一時的または流動的にプログラムを保持する媒体）でもよい。例えば、通信ネットワークの電子掲示板（ＢＢＳ：Bulletin Board Service）に該プログラムを掲示し、これを通信回線を介して配信するようにしてもよい。

１００ ＩＰ通信端末
１０１ 受信部
１０２ 解析部
１０３ 情報制御部
１０４ 履歴検索部
１０５ 宛先指定方法判断部
１０６ 履歴記憶部
１０７ 原因特定部
１０８ 呼接続処理部
１０９ 処理情報作成部
１１０ 送信部
１１１ ユーザインターフェース
２００ 呼制御サーバ
２０１ 受信部
２０２ 呼制御部
２０３ 記憶部
２０４ 更新処理部
２０５ 期限管理部
２０６ ＩＰ通信端末情報記憶部
２０７ 情報作成部
２０８ 送信部
２０９ 更新登録部
２１０ 情報検索部

Claims (14)

1. 着呼側通信端末との呼接続に際し、該呼接続における呼制御を行う呼制御装置に対して通信要求を行う通信要求手段と、
   前記通信要求手段による通信要求に基づく前記着呼側通信端末の通信状態を前記呼制御装置から受信する受信手段と、
   前記受信手段により受信した通信状態が前記着呼側通信端末と通信できない場合、前記通信要求に係る通信情報に基づいて当該着呼側通信端末と通信できない原因を特定する特定手段と
   を具備する通信端末。
2. 前記特定手段は、
   他の通信端末との間における通信履歴から前記着呼側通信端末との通信履歴を検出し、該通信履歴に基づいて前記原因を特定する請求項１記載の通信端末。
3. 前記特定手段は、
   前記着呼側通信端末との前記通信履歴を検出できた場合であって該通信履歴により通信実績があるときには前記原因を前記着呼側通信端末における通信接続障害と特定し、前記通信履歴を検出できた場合であって該通信履歴により通信実績がないときには前記原因を前記着呼側通信端末の非存在と特定する請求項２記載の通信端末。
4. 前記特定手段は、
   前記着呼側通信端末との通信履歴が検出できた場合であって該通信履歴における通信実績が一定期間内のものであるときには前記原因を前記着呼側通信端末における通信接続障害と特定する請求項２記載の通信端末。
5. 前記通信要求手段は、
   呼接続先一覧にある通信端末に基づき前記呼接続を行う前記着呼側通信端末を指定して前記通信要求を行い、
   前記特定手段は、
   前記呼接続先一覧から指定した前記着呼側通信端末と通信できない場合には前記原因を該着呼側通信端末における通信接続障害と特定する請求項１記載の通信端末。
6. 前記着呼側通信端末は、
   前記呼制御装置に登録された登録状態を保留とする保留時間を当該呼制御装置に通知する通知手段
   を具備し、
   前記呼制御装置は、
   前記通知手段によって前記着呼側通信端末から前記保留時間が通知されることにより登録期間の満了以後、該保留時間の経過まで前記着呼側通信端末を保留状態として管理する状態管理手段
   を具備し、
   前記受信手段は、
   前記通信要求手段によって通信要求した前記着呼側通信端末との通信状態が保留状態であることを前記呼制御装置から受信し、
   前記特定手段は、
   前記受信手段によって保留状態であると受信することにより前記原因を前記着呼側通信端末における通信接続障害と特定する請求項１記載の通信端末。
7. 前記通信要求手段は、
   前記特定手段によって前記原因が前記着呼側通信端末における通信接続障害であると特定された場合に、再度、着呼側通信端末との呼接続に際して前記呼制御装置に対して通信要求を行う請求項３乃至６のいずれかに記載の通信端末。
8. 前記受信手段は、
   前記着呼側通信端末との通信状態とともに動作指示情報を受信する請求項１記載の通信端末。
9. 前記受信手段によって受信した動作指示情報に係る前記原因を提示する宛先情報に基づいて接続する接続手段
   を更に具備し、
   前記特定手段は、
   前記接続手段によって接続した宛先情報に基づく宛先に提示された前記原因で特定する請求項８記載の通信端末。
10. 前記通信要求手段は、
    前記受信手段によって受信した動作指示情報に係る指定時刻通信要求に基づいて指定時刻に再度、通信要求を行う請求項８記載の通信端末。
11. 前記着呼側通信端末と通信できない場合、該着呼側通信端末との通信予約を設定する予約設定手段
    を更に具備し、
    前記呼制御装置は、
    前記予約設定手段によって通信予約が設定された前記着呼側通信端末から登録要求を受け付けることにより予約元の通信端末に前記着呼側通信端末の通信状態を通知する通知手段
    を具備し、
    前記通信要求手段は、
    前記通知手段によって通信状態が通知されることにより前記着呼側通信端末との呼接続における通信要求を前記呼接続装置に行う請求項１または８に記載の通信端末。
12. 通信端末間の呼制御に際し、発呼側通信端末からの呼接続によって着呼側通信端末に通信要求を行う通信要求手段と、
    前記通信要求手段による通信要求に対して前記着呼側通信端末との通信状態を検出する状態検出手段と、
    前記状態検出手段によって検出した通信状態が前記着呼側通信端末が検知できない状態である場合に、前記通信要求に係る通信情報に基づいて当該着呼側通信端末と通信できない原因を特定する特定手段と
    を具備する呼制御装置。
13. 前記特定手段は、
    通信端末間における通信履歴から前記着呼側通信端末が検知できない状態にある前記着呼側通信端末との通信履歴を検出し、該通信履歴に基づいて前記原因を特定する請求項１２記載の呼制御装置。
14. コンピュータを、
    着呼側通信端末との呼接続に際し、該呼接続における呼制御を行う呼制御装置に通信要求を行う通信要求手段、
    前記通信要求手段による通信要求に基づく前記着呼側通信端末の通信状態を前記呼制御装置から受信する受信手段、
    前記受信手段により受信した通信状態が前記着呼側通信端末と通信できない場合、前記通信要求に係る通信情報に基づいて当該着呼側通信端末と通信できない原因を特定する特定手段
    として機能させる通信プログラム。

Images