JP5465080B2 - 通信装置、通信システムおよび着信制御方法 - Google Patents

Description

本発明は、呼制御を必要としないネットワークと、呼制御を行う呼制御ネットワークと、を備える通信システムにおいて着信制御を行う通信装置に関する。

次世代ネットワーク（ＮＧＮ：Next Generation Network）における通信では、接続先を電話番号で特定し、ＳＩＰ（Session Initiation Protocol）によりセッション制御を行うことを前提としている。すなわち、ＮＧＮに接続する端末装置は、ＳＩＰによるセッション制御機能を有している必要がある。

一方、従来の端末装置（ＳＩＰセッション制御機能を有さない端末装置）からＮＧＮへの接続を実現することを目的とした、ＳＩＰによるセッション制御を代行するゲートウエイ装置を備えたシステムが提案されている（たとえば、下記特許文献１参照）。

ＮＧＮではＳＩＰによるセッション制御時に、必要とする帯域を申告することで帯域を確保するサービスが提供される。このような帯域確保型の通信サービスは、通信時間に応じた従量課金で提供されるのが一般的であり、課金対象となる時間はＳＩＰセッション確立時点からＳＩＰセッション切断時点までの時間とするのが一般的である。

帯域確保型の通信サービスを利用する端末の代表例として電話端末がある。通話時の着信側ではアナログ電話端末が実際に接続されていれば着信時に呼び出し音を鳴らし、オフフックされたことに連動してＳＩＰセッションが確立し、音声データの通信と課金が始まる。また、オフフックされなければＳＩＰセッションは確立されないため課金が開始されることはない。

一方、ＩＰネットワークで接続されているＩＰ端末からのデータ通信を上記特許文献１に記載の方法によってＮＧＮに接続している場合、着信側のエンド端末が実際に接続できるかできないかに関わらず、ＳＩＰセッションは常に確立されてしまう。したがって、実際にはエンドツーエンドのデータ通信は出来ない状況にもかかわらず、課金が開始されてしまうという課題があった。

したがって、エンド端末が接続できない場合に課金が発生しないように、エンド端末が接続可能か否かに基づいて、ＳＩＰセッションを確立することが望ましい。下記特許文献２には、エンド端末が実際に接続できるか否かを反映してサーバとの接続処理を行うシステムが開示されている。下記特許文献２に記載のシステムでは、クライアント・サーバ間の通信を中継する装置が、クライアントからの接続要求を受けた際にサーバに対して接続を試行し、サーバと接続が確立できる場合にのみ、クライアントからの接続要求を受け付ける。

国際公開第２００６／０５１５９４号 特開２００４−０５６３０６号公報

上述のように、上記特許文献１に記載の方法では、着信側のエンド端末が実際に接続できるかできないかに関わらず、ＳＩＰセッションは常に確立されてしまう。そのため、実際にはエンドエンド間のデータ通信ができない状況にもかかわらず、課金が開始されてしまう、という問題がある。

また、上記特許文献２に記載のシステムでは、クライアントからの接続要求を受けた際にサーバに対して接続を試行し、サーバと接続が確立できる場合にのみ、クライアントからの接続要求を受け付ける。しかし、このシステムでは、接続要求としてＴＣＰ（Transmission Control Protocol）セッション確立要求であり、ＴＣＰ等によるデータ通信に先立ってＳＩＰ等によるセッションの確立が必要な場合には、サーバとの接続性を確認できる前にＳＩＰセッションが確立され課金が開始されてしまい、上述の課題は解決できない。

本発明は、上記に鑑みてなされたものであって、エンドエンド間のデータ通信が正常に行えない場合に、ＳＩＰ等によるセッション制御におけるセッションを確立しないことにより不要な課金を回避することができる通信装置、通信システムおよび着信制御方法を得ることを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、呼制御を前提としない複数の第１のネットワークと、前記複数の第１のネットワーク間にあり呼制御を実施する第２のネットワークと、前記第１のネットワークのうちの１つと前記第２のネットワークとを接続し、自装置が接続する前記第１のネットワークに属する端末を着信側の端末とする呼の呼制御処理を行う通信装置と、を備え、前記通信装置は、前記第１のネットワークと接続するポートと、前記第２のネットワークから呼接続要求を受信すると、前記呼制御要求に基づいて、前記呼制御要求により接続を要求された着信端末が自装置の呼制御処理対象の端末である場合に、前記着信端末と自装置との接続可否の判定を実施するよう指示する呼制御部と、前記ポートごとに、該ポートに接続する前記第１のネットワークに属する自装置の呼制御処理対象の端末と、前記ポートのリンク状態と、をリンク状態情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記リンク状態情報に基づいて前記着信端末と自装置との接続可否を判定する端末接続判定部と、を備え、前記呼制御部は、前記端末接続判定部が判定した判定結果が接続可であった場合に着信可能応答を返答し、前記端末接続判定部が判定した判定結果が接続不可であった場合に着信拒否応答を返答する、ことを特徴とする。

本発明によれば、エンドエンド間のデータ通信が正常に行えない場合に、ＳＩＰ等によるセッション制御におけるセッションを確立しないことにより不要な課金を回避することができる、という効果を奏する。

図１は、本発明にかかる通信システムの構成例を示す図である。 図２は、エンド端末からエンド端末へＴＣＰデータ通信を行う際の通信フローを示すチャート図である。 図３は、エンド端末がＴＣＰ接続を受け付けられない状況での通信フローの一例を示すチャート図である。 図４は、通信装置の機能構成例を示す図である。 図５は、ＳＤＰ・端末対応管理テーブルの構成例を示す図である。 図６は、エンド端末ＬＡＮポート対応テーブルの構成例を示す図である。 図７は、ポート状態管理テーブルの構成例を示す図である。 図８は、着信制御手順の一例を示すフローチャートである。 図９は、着信制御手順の一例を示すフローチャートである。 図１０は、着信制御手順の一例を示すフローチャートである。 図１１は、リンク状態を基に判断した接続可否と、エンド端末のＩＰアドレスと、の対応を管理する管理テーブルの構成例を示す図である。 図１２は、着信側エンド端末の接続可否の確認に用いることができる確認手段の例を示す図である。

以下に、本発明にかかる通信装置、通信システムおよび着信制御方法の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。

実施の形態．
図１は、本発明にかかる通信システムの実施の形態の構成例を示す図である。図１に示すように、本実施の形態の通信システムは、呼制御が不要な第１のネットワーク４−１，４−２と、呼制御を必要とする第２のネットワーク５と、第１のネットワーク４−１と第２のネットワーク５とを接続する通信装置２と、第１のネットワーク４−２と第２のネットワーク５とを接続し、着信制御機能を備えた通信装置３と、で構成される。また、エンド端末１−１は、第１のネットワーク４−１に属する端末であり、エンド端末１−２は、第１のネットワーク４−２に属する端末である。

通信装置２，通信装置３は、それぞれ第１のネットワーク４−１，第１のネットワーク４−２内のエンド端末のＳＩＰセッション制御を代行する。例えば第１のネットワーク４−１内のエンド端末１−１を発信側端末とし、第１のネットワーク４−２のエンド端末１−２を着信側端末とする、第２のネットワーク５経由の通信を行う場合、通信装置２がエンド端末１−１の代わりに発信側の呼制御処理を実施し、通信装置３がエンド端末１−２の代わりに着信側の呼制御処理を実施する。また、第２のネットワーク５では採用しており、従量課金対象区間６は端末１−１と端末１−２が通信を行う際の課金対象の区間を示している。また、端末１−１と端末１−２の通信の際には、通信装置２と通信装置３の間でその通信用のＳＩＰセッション７を確立する。一般には、当該ＳＩＰセッションが確立している間に課金されることになる。

図２は、図１示した通信システムにおいて、エンド端末１−１からエンド端末１−２へＴＣＰデータ通信を行う際の通信フローを示すチャート図である。まず、端末１−１は、ＴＣＰ接続を要求するＴＣＰ ＳＹＮを送信する（ステップＳ１）。

通信装置２は、エンド端末１−１から送出されたＴＣＰ ＳＹＮを検出すると、通信装置３との間でＳＩＰによる呼制御を確立する。具体的には、通信装置２は、第２のネットワーク５内のＳＩＰサーバ（図示せず）に、通信装置３との間でＳＩＰセッション確立を要求するＳＩＰ ＩＮＶＩＴＥを送信する（ステップＳ２）。そして、ＳＩＰサーバは、通信装置３へＳＩＰ ＩＮＶＩＴＥを送信し（ステップＳ３）、通信装置２へＳＩＰ ＩＮＶＩＴＥを実行中であることを示す暫定応答である１００（Ｔｒｉｎｇ）を送信する（ステップＳ４）。

通信装置３は、ＳＩＰサーバからＳＩＰ ＩＮＶＩＴＥを受信すると、呼び出し中であることを示す１８０（Ｒｉｎｇｉｎｇ）をＳＩＰサーバに送信し（ステップＳ５）、セッション確立の準備が完了すると２００（ＯＫ）をＳＩＰサーバへ送信する（ステップＳ６）。ＳＩＰサーバは、通信装置２へ２００（ＯＫ）を転送し（ステップＳ７）、通信装置２は２００（ＯＫ）を受信すると、ＡＣＫをＳＩＰサーバへ返送する（ステップＳ８）。そして、ＳＩＰサーバがＡＣＫを通信装置３へ転送する（ステップＳ９）。以上の手順によりＳＩＰセッションが確立する。

そして、ＳＩＰセッション確立後、通信装置２は、エンド端末１−１からステップＳ１で受信したＴＣＰ ＳＹＮを通信装置３経由でエンド端末１−２へ転送する（ステップＳ１０）。以降ＴＣＰの３ＷａｙハンドシェークによりＴＣＰコネクションの確立がされる。具体的には、エンド端末１−２が、ＴＣＰ ＳＹＮ／ＡＣＫを通信装置３および通信装置２経由でエンド端末１−１へ返送し（ステップＳ１１）、エンド端末１−１が、通信装置２および通信装置３経由でエンド端末１−２へＴＣＰ ＡＣＫを返送する（ステップＳ１２）。この３ＷａｙハンドシェークによるＴＣＰコネクションの確立後、ＴＣＰデータ通信が行われる（ステップＳ１３）。

本実施の形態では第２のネットワークが従量課金制を採用している。一般に、ＳＩＰセッションが確立された時点から、第２のネットワーク５での従量課金が開始される。このＳＩＰセッション確立の時点は、着信側である通信装置３からの２００（ＯＫ）を第２のネットワーク５内のＳＩＰサーバが中継した時点（ステップＳ６）か、送信側である通信装置２からの２００ ＯＫに対するＡＣＫを網内のＳＩＰサーバが中継した時点（ステップＳ８）、とするのが一般的である。

従来は、以上のＳＩＰセッション確立が、エンド端末１−２が、ネットワークから切り離されている、または故障等によりＴＣＰ接続ができない場合でも実施される。図３は、エンド端末１−２が、ＴＣＰ接続を受け付けられない状況での通信フローの一例を示すチャート図である。図１の場合と同様にステップＳ１〜ステップＳ１０が実施される。しかし、ステップＳ１０では、エンド端末１−２がＴＣＰ接続を受け付けられない状況であるため、エンド端末１−２からＴＣＰ ＳＹＮに対する応答であるＡＣＰ ＳＹＮ／ＡＣＫが送信されない。したがって、エンド端末１−１は、ＴＣＰ ＳＹＮを送信してから所定の時間が経過するごとにＴＣＰ ＳＹＮを再送する（ステップＳ１４，ステップＳ１５）。そして、最終的にＳＩＰセッションのタイムアウトとなり、ＳＩＰによるセッションが切断する（ステップＳ１６）。

なお、ここでは、無通信時間を監視するなどの手法により、確立されたＳＩＰセッションを用いた通信が所定の時間以上行われない場合には、タイムアウトとしてＳＩＰセッションが自動的に切断されるとしている。しかし、ＳＩＰセッションの無通信時間を監視せずＴＣＰコネクションの切断のみを契機にＳＩＰセッションを切断するような動作である場合、ステップＳ１５は実施されずに課金対象時間が継続してしまう。

本実施の形態では、エンド端末１−２がＴＣＰ接続できない場合に生じる不要な課金を防ぐために、通信装置３は、エンド端末１−２がＴＣＰ接続できない場合にＳＩＰセッションを確立しないよう制御する着信制御機能を備える。

図４は、本実施の形態の通信装置３の機能構成例を示す図である。本実施の形態の通信装置３は、第２のネットワーク５と接続するＷＡＮ（Wide Area Network）ポート３１と、第１のネットワーク４−１と接続されるＬＡＮ（Local Area Network）ポート３６−１〜３６−４と、ＷＡＮポート３１とＬＡＮポート３６−１〜３６−４との間でルーティング処理とアドレス／ポート番号変換を行うＮＡＰＴ（Network Address Port Translation）／ルーティング部３２と、ＷＡＮポート３１から受信したＳＩＰメッセージを終端処理するＳＩＰセッション制御部（呼制御部）３３と、ＳＩＰメッセージに格納されているＳＤＰ（Session Description Protocol）情報と着信させるべき端末の対応を管理するＳＤＰ・端末対応管理部３４と、各ＬＡＮポート３６−１〜３６−４と接続されているエンド端末のＩＰアドレスとの対応と、各ＬＡＮポート３６−１〜３６−４のリンク状態と、を管理するＬＡＮポート状態・端末対応管理部３５と、で構成される。なお、ここでは、ＬＡＮポートを４つとしているが、ＬＡＮポートの数はこれに限らずいくつでもよい。

図５は、ＳＤＰ・端末対応管理部３４が管理する（保持する）ＳＤＰ・端末対応管理テーブルの構成例を示す図である。ＳＤＰ・端末対応管理テーブルの各エントリは、エントリ番号、宛先電話番号、ＳＤＰフォーマット、着信端末ＩＰアドレスおよび着信端末ポート番号で構成される。ＳＤＰ・端末対応管理テーブルの情報は、予め設定しておくこととする。

図６はＬＡＮポート状態・端末対応管理部３５が管理する（保持する）エンド端末のＩＰアドレスとエンド端末が接続するＬＡＮポート番号との対応を格納したエンド端末ＬＡＮポート対応テーブルの構成例を示す図である。エンド端末ＬＡＮポート対応テーブルの各エントリは、ＬＡＮポート番号と、各ＬＡＮポートに接続されているエンド端末のＩＰアドレスと、から成る。エンド端末ＬＡＮポート対応テーブルを用いて、エンド端末のＩＰアドレスをキーとして、このエンド端末が接続されているＬＡＮポートの番号を検索することができる。なお、ここでは、ＬＡＮポート３６−ｉ（ｉ＝１，２，３，４）のＬＡＮポート番号をＬＡＮポート番号＃ｉとする。エンド端末ＬＡＮポート対応テーブルは、例えばエンド端末が、第１のネットワーク４−１に接続した時点で把握することができる。

図７はＬＡＮポート状態・端末対応管理部３５が、管理する（保持する）各ＬＡＮポート３６−１〜３６−４のリンク状態を示すポート状態管理テーブルの構成例を示す図である。ポート状態管理テーブルには、各ＬＡＮポート番号とそれぞれのリンク状態（ＵＰ（接続可能な状態）またはＤＯＷＮ（接続不可の状態））とが格納されている。ポート状態管理テーブルは、例えば、定期的に各ＬＡＮポート３６−１〜３６−４のリンク状態を確認して、その確認結果を反映することにより生成および更新するようにすればよい。

なお、ここでは、図６に例示したエンド端末ＬＡＮポート対応テーブルと、図７にポート状態管理テーブルと、の２つのテーブルに分けて管理することとしたが、ＬＡＮポートごとに、そのＬＡＮポートに接続するエンド端末とリンク状態と、の対応が管理できればよく、これらを１つのリンク状態情報テーブルとして管理してもよい。

つぎに、本実施の形態の通信装置３の着信制御動作を説明する。図８〜図１０は、本実施の形態の通信装置３の着信制御手順の一例を示すフローチャートである。図８は、ＳＩＰセッション制御部３３が実施する処理を示し、図９は、ＳＤＰ・端末対応管理部３４が実施する処理を示し、図１０は、ＬＡＮポート状態・端末対応管理部３５が実施する処理を示している。以下、図８〜図１０を用いて通信装置３の着信制御動作を説明する。

通信装置３では、ＮＡＰＴ／ルーティング部３２が、ＷＡＮポート３１を介して第２のネットワーク５からＳＩＰ接続メッセージ（ＳＩＰ ＩＮＶＩＴＥ）を受信すると、受信したＳＩＰ接続メッセージをＳＩＰセッション制御部３３に転送し、ＳＩＰセッション制御部３３の処理が開始される（ステップＳ２１）。ＳＩＰセッション制御部３３は、ＮＡＰＴ／ルーティング部３２経由でＳＩＰ接続メッセージを受信すると（ステップＳ２２）、受信したメッセージ内の各パラメータに基づいて、着信可能かどうかの判断を行う（ステップＳ２３）。着信可能かどうかは、例えば受信したメッセージ内の宛先電話番号が自身の管理する宛先番号であるか否か（すなわち、自身がＳＩＰセッション制御処理を行うべきエンド端末であるか）等に基づいて判断する。

そして、ＳＩＰセッション制御部３３は、ステップＳ２３の判断結果が着信可であるか否かを判定し（ステップＳ２４）、着信可であった場合（ステップＳ２４ Ｙｅｓ）、受信したＳＩＰ接続メッセージから、宛先電話番号と、ＳＤＰ情報として格納されているＳＤＰフォーマット情報と、を抽出することにより着信端末を特定し、抽出した宛先電話番号とＳＤＰフォーマット情報とをＳＤＰ・端末対応管理部３４へ通知し、ＳＤＰ・端末対応管理部３４に対して処理（着信可否判定処理）を行なうよう指示する（ステップＳ２５）。

ＳＤＰ・端末対応管理部３４は、図９に示すように、ＳＩＰセッション制御部３３からの指示により処理（着信可否判定処理）を開始し（ステップＳ３１）、通知された宛先電話番号とＳＤＰフォーマット情報とをキーとして、自身が管理しているＳＤＰ・端末対応管理テーブルを参照して、通知された宛先電話番号とＳＤＰフォーマット情報とに対応する着信端末のＩＰアドレスおよびポート番号情報を検索する（ステップＳ３２）。

そして、ＳＤＰ・端末対応管理部３４はＳＤＰ・端末対応管理テーブル内に通知された宛先電話番号とＳＤＰフォーマット情報とに合致するエントリが存在するか（すなわち、着信端末が存在するか）否かを判断し（ステップＳ３３)、合致するエントリが存在する場合（ステップＳ３３ Ｙｅｓ）、検索して得られた着信端末のＩＰアドレスをＬＡＮポート状態・端末対応管理部３５に通知するとともに、ＬＡＮポート状態・端末対応管理部３５へ処理（着信可否判定処理）開始を指示する（ステップＳ３４）。また、ステップＳ３３で合致するエントリが存在しないと判断した場合（ステップＳ３３ Ｎｏ）、ＳＤＰ・端末対応管理部３４は、着信不可と判定し、この判定結果をＳＩＰセッション制御部３３へ通知する（ステップＳ３５）。

ＬＡＮポート状態・端末対応管理部３５は、図１０に示すように、ＳＤＰ・端末対応管理部３４から指示されると処理を開始し（ステップＳ４１）、通知された着信端末のＩＰアドレスをキーとして、エンド端末ＬＡＮポート対応テーブルを検索して対応するＬＡＮポート番号を検索する（ステップＳ４２）。そして、ＬＡＮポート状態・端末対応管理部３５は、対応するＬＡＮポート番号が存在するか否かを判断し（ステップＳ４３）、対応するＬＡＮポート番号情報が存在する場合には（ステップＳ４３ Ｙｅｓ）、検索して得られたＬＡＮポート番号をキーに、ポート状態管理テーブルを検索して、当該ＬＡＮポートのリンク状態を取得する（ステップＳ４４）。そして、取得したリンク状態情報がＵＰであるか否かを判断し（ステップＳ４５）、リンクがＵＰであった場合（ステップＳ４５ Ｙｅｓ）、着信可能と判定し、この判定結果をＳＩＰセッション制御部３３へ通知する（ステップＳ４６）。

一方、ステップＳ４３で、対応するＬＡＮポート番号情報が存在しないと判断した場合（ステップＳ４３ Ｎｏ）、着信不可と判定し、この判定結果をＳＤＰ・端末対応管理部３４経由でＳＩＰセッション制御部３３へ通知する（ステップＳ４７）。また、ステップＳ４５で、取得したリンク状態情報がＤＯＷＮであった場合（ステップＳ４５ Ｎｏ）、ステップＳ４７へ進む。

図８に戻り、ＳＩＰセッション制御部３３は、ＳＤＰ・端末対応管理部３４から通知された判定結果が着信可能であるか否かを判断する（ステップＳ２６）。判定結果が着信可能であった場合（ステップＳ２６ Ｙｅｓ）は、着信許可応答（２００（ＯＫ））を第２のネットワーク５へ送信し（ステップＳ２７）、ＳＩＰセッションを確立する。一方、判定結果が着信不可であった場合（ステップＳ２６ Ｎｏ）は、着信拒否応答（４０６（Not Acceptable等）を第２のネットワーク５へ送信する（ステップＳ２８）。

このように着信先のエンド端末が接続されているＬＡＮポート３６−１〜３６−４のリンク状態に応じてＳＩＰセッションの着信許可・拒否を制御する。このため、着信エンド端末が着信不能である場合にはＳＩＰセッションを確立せず、無駄な課金の発生を避けることができる。

また、図６に例示したエンド端末ＬＡＮポート対応テーブルと、図７に示したポート状態管理テーブルと、を１つにまとめて、リンク状態を基に判断した接続可否と、エンド端末のＩＰアドレスと、対応付けて管理するようにしてもよい。図１１は、リンク状態を基に判断した接続可否と、エンド端末のＩＰアドレスと、の対応を管理する管理テーブルの構成例を示す図である。ＬＡＮポート状態・端末対応管理部３５は、図１１に例示するような管理テーブルを用いて、接続可否を判定してもよい。

また、本実施の形態では、図７に示したポート状態管理テーブルを予め作成して管理するようにしたが、ポート状態管理テーブルを予め作成しておかずに、リンク状態の確認が必要となった時点（ＳＩＰセッション制御部３３から着信可否判定処理の開始を指示された時点、すなわち着信端末が特定された後）で、確認の対象となるＬＡＮポートのリンク状態を確認してもよい。またリンク状態の確認方法は、例えばリンク状態を確認するための所定のコマンドを送信することにより行なう。この場合、ポート状態管理テーブルを予め作成しておく場合には、例えば定期的にリンク状態を確認するための所定のコマンドを送信することにより、ポート状態管理テーブルの作成および更新を行い、リンク状態の確認が必要となった時点で確認を行なう場合には、リンク状態の確認が必要となった時点でリンク状態を確認するための所定のコマンドを送信する。

また、本実施の形態では、通信装置３は、着信側エンド端末が接続を受け付けられないかどうか（自身と通信接続が可能であるか否か）の判断を、そのエンド端末が接続されているＬＡＮポートのリンク状態で判断するようにしたが、これに限らず、他の方法で着信側エンド端末が接続可否を判断するようにしてもよい。言い換えると、ＬＡＮポート状態・端末対応管理部３５は、自身とエンド端末との通信接続が可能か否かを判定する端末接続判定部の一種であり、端末接続判定部は、ＬＡＮポートのリンク状態以外の他の確認手段を用いてエンド端末が自身と接続（通信接続）が可能化否かを判定してもよい。

図１２は、着信側エンド端末の接続可否の確認に用いることができる確認手段の例を示す図である。図１２には、確認を行うレイヤと、確認手段と、着信拒否の判定基準と、ＳＩＰ接続要求を契機に実行される着信可否判断の中で、判断条件に用いる値の取得と判断を行うことができるか否かの情報（「着信時に実施」）と、予め着信側エンド端末ごとに接続可否を決めておくことができるか否かの情報（「予め実施」）と、を示している。

「着信時に実施」の項目が丸となっている場合は、着信拒否の判定基準と、ＳＩＰ接続要求を契機に実行される着信可否判断の中で、判断条件に用いる値の取得と判断を行うことができることを示している。また、「予め実施」の項目が丸となっている場合は、判断条件に用いる値の取得はＳＩＰ接続要求の受信とは独立に、予め実施しておくことができることを示している。

一番上の段の個別ＬＡＮポートリンク状態による確認を確認手段とする場合は、本実施の形態の着信制御動作として上述した。２段目のＡＲＰ（Address Resolution Protocol）リクエストへの応答を確認手段とする場合は、着信側エンド端末からＡＲＰ応答がない場合に着信側エンド端末が接続不可であるとし、着信不可と判定する。

３段目のＤＨＣＰ（Dynamic Host Configuration Protocol）リース状態／ＦＯＲＣＥＲＥＮＥＷを確認手段とする場合は、着信側エンド端末がＤＨＣＰリース無しの場合、または着信側エンド端末からＦＯＲＣＥＲＥＮＥＷへの応答無しの場合に、着信側エンド端末が接続不可であるとし、着信不可と判定する。

４段目のＥｔｈｅｒｎｅｔ（登録商標） ＯＡＭ（Operation Administration and Maintenance）のＣＣＭ（Continuity Check Messages）受信、着信側エンド端末からのＣＣＭの定期受信が無い（定期受信の周期を超える所定の時間以上受信がない）場合に、着信側エンド端末が接続不可であるとし、着信不可と判定する。Ｅｔｈｅｒｎｅｔ（登録商標） ＯＡＭのＬＢ（Loopback）応答（自装置から送信したＬＢパケットがエンド端末を経由して自装置へもどってくるか）を確認手段とする場合は、着信側エンド端末からＬＢ応答がない場合に、着信側エンド端末が接続不可であるとし、着信不可と判定する。

５段目のＬＬＤＰ（Link Layer Discovery Protocol）により定期的に送信される管理情報の受信を確認手段とする場合、着信側エンド端末からのＬＬＤＰによる管理情報の定期受信がない場合に、着信側エンド端末が接続不可であるとし、着信不可と判定する。

また、６段目のＰＩＮＧ応答を確認手段とする場合、着信側エンド端末からＰＩＮＧ応答が無い場合に、着信側エンド端末が接続不可であるとし、着信不可と判定する。７段目のＩＧＭＰ（Internet Group Management Protocol）／ＭＬＤ（Multicast Listener Discovery）により周期的に送信される定期送信パケットの受信の有無を確認手段とする場合、着信側エンド端末からのＩＧＭＰまたはＭＬＤによる定期送信パケットの受信がない場合に、着信側エンド端末が接続不可であるとし、着信不可と判定する。

８段目のＴＣＰ ＳＹＮへの応答、ＩＣＭＰ（Internet Control Message Protocol） Port Unreachable受信を確認手段とする場合、着信側エンド端末からＴＣＰ ＳＹＮに対するＳＹＮ ＡＣＫ応答が無い場合、または着信側エンド端末からＩＣＭＰ Port Unreachableを受信した場合に、着信側エンド端末が接続不可であるとし、着信不可と判定する。

９段目のＵＤＰに対するＩＣＭＰ Port Unreachable受信を確認手段とする場合、通信装置３からＵＤＰパケットを送信し着信側エンド端末からそのパケットに対するＩＣＭＰ Port Unreachableを受信した場合に、着信側エンド端末が接続不可であるとし、着信不可と判定する。また、着信側エンド端末の接続可否を判定できる確認手段であれば、これら図１０に示した以外の確認手段を用いてもよい。

予め確認手段による実施を実施しておく場合は、通信装置３はＳＩＰセッション制御の対象となる各エンド端末について、エンド端末と接続した後にＡＲＰやＰＩＮＧ等を定期的に送信しその結果を保持しておき、保持している確認結果に基づいて着信端末の接続可否の判定を行なう。着信時に実施の場合は、着信端末の接続可否の判定を行なう際に、ＡＲＰやＰＩＮＧ等を送信して確認結果を取得し、取得した確認結果に基づいて着信端末の接続可否の判定を行なう。

このように、本実施の形態では、通信装置３がＳＩＰ接続メッセージを受信した場合に、ＳＩＰセッション制御部３３が、ＳＩＰ接続メッセージから宛先電話番号と、ＳＤＰ情報として格納されているＳＤＰフォーマット情報と、抽出してＳＤＰ・端末対応管理部３４へ通知し、ＳＤＰ・端末対応管理部３４がＳＤＰ・端末対応管理テーブルに基づいて、着信側端末のＩＰアドレスを求める。そして、ＬＡＮポート状態・端末対応管理部３５が着信側端末のＩＰアドレスとエンド端末ＬＡＮポート対応テーブルおよびポート状態管理テーブルに基づいて着信端末の接続可否を判定し、着信端末が接続不可である場合には、着信不可と判定しＳＩＰセッション制御部３３に通知し、ＳＩＰセッション制御部３３は着信不可の判定結果であった場合には着信拒否応答を返信するようにした。そのため、エンドエンド間のデータ通信が正常に行えない場合にＳＩＰ等によるセッション制御におけるセッションを確立しないことにより、不要な課金を回避することができる。

以上のように、本発明にかかる通信装置および着信制御方法は、ＩＰ（Internet Protocol：インターネットプロトコル）ネットワークと、このＩＰネットワーク上で呼制御を行う呼制御ネットワークと、を備える通信システムにおいて着信制御を行う通信装置に有用であり、特に、呼制御ネットワークで従量課金制のサービスを提供している場合に適している。

１−１，１−２ エンド端末
２，３ 通信装置
４−１，４−２ 第１のネットワーク
５ 第２のネットワーク
３１ ＷＡＮポート
３２ ＮＡＰＴ／ルーティング部
３３ ＳＩＰセッション制御部
３４ ＳＤＰ・端末対応管理部
３５ ＬＡＮポート状態・端末対応管理部
３６−１〜３６−４ ＬＡＮポート

Claims (21)

1. 呼制御を前提としない複数の第１のネットワークと、
   前記複数の第１のネットワーク間にあり呼制御を実施する第２のネットワークと、
   前記第１のネットワークのうちの１つと前記第２のネットワークとを接続し、自装置が接続する前記第１のネットワークに属する端末を着信側の端末とする呼の呼制御処理を行う通信装置と、
   を備え、
   前記通信装置は、
   前記第１のネットワークと接続するポートと、
   前記第２のネットワークから呼接続要求を受信すると、前記呼制御要求に基づいて、前記呼制御要求により接続を要求された着信端末が自装置の呼制御処理対象の端末である場合に、前記着信端末と自装置との接続可否の判定を実施するよう指示する呼制御部と、
   前記ポートごとに、該ポートに接続する前記第１のネットワークに属する自装置の呼制御処理対象の端末と、前記ポートのリンク状態と、をリンク状態情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記リンク状態情報に基づいて前記着信端末と自装置との接続可否を判定する端末接続判定部と、
   を備え、
   前記呼制御部は、前記端末接続判定部が判定した判定結果が接続可であった場合に着信可能応答を返答し、前記端末接続判定部が判定した判定結果が接続不可であった場合に着信拒否応答を返答する、
   ことを特徴とする通信システム。
2. 呼制御を前提としない第１のネットワークと、呼制御を実施する第２のネットワークと、を接続し、前記第１のネットワークに属する端末を着信側の端末とする呼の呼制御処理を行う通信装置であって、
   前記第２のネットワークから呼接続要求を受信すると、前記呼制御要求に基づいて、前記呼制御要求により接続を要求された着信端末が自装置の呼制御処理対象の端末である場合に、前記着信端末と自装置との接続可否の判定を実施するよう指示する呼制御部と、
   前記呼制御部からの指示に基づいて、前記着信端末と自装置との接続可否を判定する端末接続判定部と、
   を備え、
   前記呼制御部は、前記端末接続判定部が判定した判定結果が接続可であった場合に着信可能応答を返答し、前記端末接続判定部が判定した判定結果が接続不可であった場合に着信拒否応答を返答する、
   ことを特徴とする通信装置。
3. 前記第１のネットワークと接続するポート、
   をさらに備え、
   前記端末接続判定部は、前記ポートごとに、該ポートに接続する前記第１のネットワークに属する自装置の呼制御処理対象の端末と、前記ポートのリンク状態と、をリンク状態情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記リンク状態情報に基づいて前記着信端末と自装置との接続可否を判定する、
   ことを特徴とする請求項２に記載の通信装置。
4. 前記第１のネットワークと接続するポート、
   をさらに備え、
   前記端末接続判定部は、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示されると、前記着信端末が接続する前記ポートのリンク状態を取得し、取得した前記リンク状態に基づいて前記着信端末と自装置との接続可否を判定する、
   ことを特徴とする請求項２に記載の通信装置。
5. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＡＲＰリクエストに対する応答の有無をＡＲＰ応答情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記ＡＲＰ応答情報に基づいて前記着信端末と自装置との接続可否を判定する、
   ことを特徴とする請求項２に記載の通信装置。
6. 前記端末接続判定部は、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示されると、前記着信端末に対してＡＲＰリクエストを送信し、前記ＡＲＰリクエストに対する応答の有無に基づいて前記着信端末と自装置との接続可否を判定する、
   ことを特徴とする請求項２に記載の通信装置。
7. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＤＨＣＰリース状態の有無をＤＨＣＰリース情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記ＤＨＣＰリース情報に基づいて前記着信端末と自装置との接続可否を判定する、
   ことを特徴とする請求項２に記載の通信装置。
8. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＤＨＣＰ ＦＯＲＣＥＲＥＮＥＷに対する応答の有無をＤＨＣＰ情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記ＤＨＣＰ情報に基づいて前記着信端末と自装置との接続可否を判定する、
   ことを特徴とする請求項２に記載の通信装置。
9. 前記端末接続判定部は、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示されると、前記着信端末に対してＤＨＣＰ ＦＯＲＣＥＲＥＮＥＷを送信し、前記ＤＨＣＰ ＦＯＲＣＥＲＥＮＥＷに対する応答の有無に基づいて前記着信端末と自装置との接続可否を判定する、
   ことを特徴とする請求項２に記載の通信装置。
10. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＥｔｈｅｒｎｅｔ（登録商標） ＯＡＭのＣＣＭを定期的に受信しているか否かをＣＣＭ情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記ＣＣＭ情報に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
11. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＥｔｈｅｒｎｅｔ（登録商標） ＯＡＭのＬＢパケットに対する応答の有無をＬＢ情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記ＬＢ情報に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
12. 前記端末接続判定部は、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示されると、前記着信端末に対してＬＢパケットを送信し、前記ＬＢパケットに対する応答の有無に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
13. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＬＬＤＰにより定期的に送信される管理情報の定期的な受信の有無をＬＬＤＰ情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記ＬＬＤＰ情報に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
14. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＰＩＮＧコマンドに対する応答の有無をＰＩＮＧ情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記ＰＩＮＧ情報に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
15. 前記端末接続判定部は、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示されると、前記着信端末に対してＰＩＮＧコマンドを送信し、前記ＰＩＮＧコマンドに対する応答の有無に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
16. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＩＧＭＰまたはＭＬＤによる定期送信パケットの受信の有無を定期パケット受信情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記定期パケット受信情報に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
17. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＴＣＰ ＳＹＮに対する応答の有無をＴＣＰ情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記ＴＣＰ情報に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
18. 前記端末接続判定部は、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示されると、前記着信端末に対してＴＣＰ ＳＹＮを送信し、前記ＴＣＰ ＳＹＮに対する応答の有無に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
19. 前記端末接続判定部は、前記第１のネットワークに属する自装置の呼制御処理対象の端末ごとにＵＤＰパケットに対する応答の有無をＵＣＰ情報として保持し、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示された場合に、前記ＵＣＰ情報に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
20. 前記端末接続判定部は、前記呼制御部から前記着信端末と自装置との接続可否の判定の実施を指示されると、前記着信端末に対してＵＤＰパケットを送信し、前記ＵＤＰパケットに対する応答の有無に基づいて前記着信端末と自装置との接続可否を判定する、
    ことを特徴とする請求項２に記載の通信装置。
21. 呼制御を前提としない第１のネットワークと、呼制御を実施する第２のネットワークと、を接続し、前記第１のネットワークに属する端末を着信側の端末とする呼の呼制御処理を行う通信装置における着信制御方法であって、
    前記第２のネットワークから、呼接続要求を受信すると、前記呼制御要求に基づいて、前記呼制御要求により接続を要求された着信端末が自装置の呼制御処理対象の端末である場合に、前記着信端末と自装置との接続可否の判定を実施するよう指示する判定指示ステップと、
    前記判定指示ステップでの指示に基づいて、前記着信端末と自装置との接続可否を判定する端末接続判定ステップと、
    前記端末接続判定部が判定した判定結果が接続可であった場合に着信可能応答を返答し、前記端末接続判定部が判定した判定結果が接続不可であった場合に着信拒否応答を返答する着信応答ステップと、
    を含むことを特徴とする着信制御方法。

Images