JP4609365B2

JP4609365B2 - プロキシサーバ及びｉｐネットワークの特定信号転送方法

Info

Publication number: JP4609365B2
Application number: JP2006095137A
Authority: JP
Inventors: 稔和小林
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2006-03-30
Filing date: 2006-03-30
Publication date: 2011-01-12
Anticipated expiration: 2026-03-30
Also published as: JP2007274160A

Description

本発明はプロキシサーバ及びＩＰネットワークの特定信号転送方法に関し、例えば、トランザクションステートフルなＳＩＰプロキシサーバや、そのＳＩＰプロキシサーバを用いたＩＰネットワークにおけるセッション監視信号（セッションタイマ信号）のインタワーク方式に適用し得るのである。

ＩＰ電話サービスでは、装置間の信号授受を、ＩＰ電話ネットワーク上を通過していくパケットベースで行うため、従来の電話交換サービスと異なり、ネットワークの間欠障害や端末障害等によるパケットロストで、各装置間（端末、ＩＰ電話交換機（サーバ）等）の状態が不一致になる可能性が大きい。そのため、定期的に各装置間（端末−サーバ間、端末−端末間等）でセッションタイマ機能（ヘルスチェック機能）を動作させることにより、各装置間の状態のアンマッチを防ぐことが行われるのが一般的である。信号制御プロトコルとしてＳＩＰを用いたＩＰ電話ネットワークでは、ＩＥＴＦＲＦＣ４０２８等でセッションタイマ機能の実現方法が規定されている。さらに、ＩＰ電話が普及するに従い、国内標準（ＴＴＣ標準）が整備され、ＳＩＰベースでのセッションタイマ動作等の詳細な信号規定がＴＴＣ標準として規定されてきている（非特許文献１〜非特許文献３参照）。
ＪＪ−９０．２４事業者ＳＩＰ網に接続するＳＩＰ端末基本接続インタフェース技術仕様ＪＪ−９０．２５管理された事業者ＳＩＰ網間における相互接続インタフェース技術仕様ＪＪ−９０．２２事業者ＳＩＰ網における網付与ユーザＩＤ情報転送に関する技術仕様

しかし、上述したＴＴＣ標準では、ＳＩＰプロキシサーバを用いたＩＰネットワークにて、ＩＰ電話サービスを実現する場合において、ＳＩＰプロキシサーバが「トランザクションステートフルなＳＩＰプロキシサーバ」の場合には、セッションタイマ機能に対応できないという課題がある。

図２のシーケンス図を参照しながら、上記課題が発生することを具体的に説明する。

発信者番号が非通知のケースにおいて、発側ＩＰ電話端末（ＵＡＣ）１００から、ＩＰ電話交換機能を有するＳＩＰプロキシサーバ（ＳＩＰＰｒｏｘｙ）２００へのＩｎｉｔｉａｌ−ＩＮＶＩＴＥリクエストには、その端末に係る発番号情報がＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙ上に設定されている（Ｓ１）。ＳＩＰプロキシサーバ２００は、発信者のなりすましを防止するため、発信者番号の正常性の検証し、着側ＩＰ電話端末（ＵＡＳ；他の装置であっても良い）３００へ信号を転送する（Ｓ２）。

発側ＩＰ電話端末（ＵＡＣ）１００は、セッションの状態をチェックするため、定期的にセッションタイマ信号（Ｒｅ−ＩＮＶＩＴＥ信号）を送出する（Ｓ３）。このセッションタイマ信号（Ｒｅ−ＩＮＶＩＴＥ）には、ＴＴＣ標準上、Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙは設定されない。トランザクションステートフルなＳＩＰプロキシサーバ２００では、Ｉｎｉｔｉａｌ−ＩＮＶＩＴＥもＲｅ−ＩＮＶＩＴＥも別々のトランザクションとして扱うため、Ｒｅ−ＩＮＶＩＴＥ信号でも発信者番号の正常性検証を実施しようとするが、発信者番号相当の信号が設定されていないため、Ｒｅ−ＩＮＶＩＴＥ信号を送出した端末１００に対してＮＧ応答することになり、これにより、最終的には、端末１００がセッション監視ＮＧと判断し、端末サイドから信号切断がなされることになる（Ｓ４）。

因みに、コールステートフルなＳＩＰプロキシサーバの場合はダイアログ（発信〜切断までの呼の状態）を管理しているので問題ないが、トランザクションステートフルなＳＩＰプロキシサーバ１０では、ＴＴＣ標準に対応した端末（ＵＡ）を対してサービスできないことになる。

そのため、発信者番号を含まない特定信号にも適切に転送処理できるプロキシサーバや、特定信号転送方法が望まれている。

かかる課題を解決するため、第１の本発明は、ユーザエージェント間の信号の中継機能を有する、アドレス解決を行うプロキシサーバにおいて、（１）転送を許可したい特定信号、又は、その特定信号と他の一部の信号とでしか信号内に存在しない項目について、予め設定されている転送可否条件を記憶する転送可否条件記憶手段と、（２）発信者番号非通知若しくは発信者番号非挿入の受信信号か否かを判断する第１の判断手段と、（３）発信者番号非通知若しくは発信者番号非挿入の受信信号である場合に、予め設定されている上記転送可否条件に従って、転送可否を判断する第２の判断手段とを有することを特徴とする。

また、第２の本発明は、ユーザエージェント間の特定信号の中継を、アドレス解決を行うプロキシサーバが行うＩＰネットワークの特定信号転送方法において、上記プロキシサーバは、転送を許可したい特定信号、又は、その特定信号と他の一部の信号とでしか信号内に存在しない項目について、予め設定されている転送可否条件を記憶しており、受信信号があったときに、発信者番号非通知若しくは発信者番号非挿入の受信信号か否かを判断し、発信者番号非通知若しくは発信者番号非挿入の受信信号である場合に、予め設定されている上記転送可否条件に従って、転送可否を判断することを特徴とする。

本発明によれば、発信者番号を含まない特定信号にも適切に転送処理できるプロキシサーバ及び特定信号転送方法を実現することができる。

（Ａ）実施形態
以下、本発明によるプロキシサーバ及びＩＰネットワークの特定信号転送方法の一実施形態を、図面を参照しながら説明する。なお、この実施形態のプロキシサーバはＳＩＰプロキシサーバであり、特定信号はセッションタイマ信号である。

（Ａ−１）実施形態の構成
図３は、この実施形態のＳＩＰプロキシサーバを含む電話通信システムの構成を示すブロック図である。

図３において、トランザクションステートフルなＳＩＰプロキシサーバ２はＩＰネットワーク１に配備されている。ＳＩＰプロキシサーバ２は、ユーザ情報管理部３、ルーチング情報管理部４、呼情報管理部１０及び信号処理部５を有する。

ユーザ情報管理部３は、契約加入者に関する情報を管理するものである。ルーチング情報管理部４は、接続先アドレス（ＰＳＴＮ等のルーチング先情報）等の情報を管理するものである。呼情報管理部１０は、トランザクション（信号）のログ等を管理するものである。

信号処理部５は、信号の送受信処理、受信した信号内容を分析し、送信信号の編集処理、各種条件に従ったルーチング処理、端末−サーバ間の状態確認処理等を司るものである。この実施形態の信号処理部５は、信号の一連の受信処理の中に、発信者番号を含まない信号の転送可否の判断処理を含んでいる。また、この実施形態の場合、ＳＩＰプロキシサーバ２には、当該サーバの設置者や保守者によって、後述する図４に示すような信号転送判定条件５Ａが設定される。信号処理部５は、設定されている信号転送判定条件５Ａに従って、信号の転送可否を判断する。

ユーザ端末６及び７はそれぞれ、当該ＳＩＰプロキシサーバ２に収容されている端末を表している。ユーザ端末９は、ＰＳＴＮ網８の電話事業者が管理する端末である。例えば、ユーザ端末６は、ＳＩＰサーバ２を介して、ユーザ端末７やユーザ端末９と通話を実現する。なお、ユーザ端末９と通信する場合には、ＩＰ電話交換機（ＰＳＴＮゲートウェイ）１１を経由して通信することになる。

ＳＩＰプロキシサーバ２から見て、ユーザ端末６、ユーザ端末７、ＩＰ電話交換機（ＰＳＴＮゲートウェイ）１１がユーザエージェント（ＵｓｅｒＡｇｅｎｔ：ＵＡ）であり、当該電話通信システムでのセッションタイマは各ＵＡ間でＳＩＰサーバ１２を介して実現している。

（Ａ−２）実施形態の動作
次に、この実施形態の電話通信システムにおけるセッションタイマ機能に係る動作を、図１のフローチャートを参照しながら、説明する。

ＳＩＰプロキシサーバ２は、信号を受信すると（Ｆ１０１）、受信信号と当該ＳＩＰプロキシサーバ２で管理している加入者情報とに基づいて、送信元のユーザを認証（検証）する（Ｆ１０２）。

ユーザ認証がＮＧの場合には、ＳＩＰプロキシサーバ２は、発側のユーザエージェント（端末等）に対して、エラー応答をする（Ｆ１０３）。これに対して、ユーザ認証がＯＫであれば、ＳＩＰプロキシサーバ２は、受信信号が発信者番号通知の信号であるか否かの判定を行う（Ｆ１０４）。

発信者番号通知の信号を受信した場合には、ＳＩＰプロキシサーバ２は、受信信号上のＦｒｏｍヘッダ等に設定されている発信者番号が、ユーザ情報管理部３で管理している加入者データのいずれかの発信者番号に合致しているか否かを検証する（Ｆ１０５）。信号上の発信者番号と合致する発信者番号の加入者データがユーザ情報管理部３に存在しなければ、ＳＩＰプロキシサーバ２は、発側のユーザエージェント（端末等）に対して、エラー応答を行う（Ｆ１０６）。これに対して、受信信号上の発信者番号に対する認証ができた場合には、ＳＩＰプロキシサーバ２は、着側のユーザエージェント（端末等）に対して信号を転送する（Ｆ１０７）。

受信信号が発信者番号非通知の信号の場合には、そのＳＩＰプロトコルに従う信号上にＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダが存在するか否かを確認する（Ｆ１０８）。この判定は、例えば、受信信号が、セッション確立時の初期のＩＮＶＩＴＥリクエストになっているか否かの判定に相当する。

Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダが存在すると、ＳＩＰプロキシサーバ２は、このヘッダと、ユーザ情報管理部３で管理している対応情報との照合により、送信元のユーザを認証（検証）する（Ｆ１０９）。

Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダに基づく、ユーザ認証がＮＧの場合には、ＳＩＰプロキシサーバ２は、発側のユーザエージェント（端末等）に対して、エラー応答を行う（Ｆ１１０）。これに対して、受信信号のＰ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダに基づいてユーザ認証ができた場合には、ＳＩＰプロキシサーバ２は、着側のユーザエージェント（端末等）に対して信号を転送する（Ｆ１１１）。

Ｐ−Ｐｒｅｆｅｒｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダが存在しない場合でも、この実施形態のＳＩＰプロキシサーバ２は、設定されている信号転送判定条件５Ａに従って、信号の転送可否を判断する（Ｆ１１２）。設定されている信号転送判定条件５Ａに従うと、転送が認められない場合であれば、ＳＩＰプロキシサーバ２は、発側のユーザエージェント（端末等）に対して、エラー応答を行う（Ｆ１１３）。これに対して、設定されている信号転送判定条件５Ａに従うと、転送が認められる場合であれば、ＳＩＰプロキシサーバ２は、着側のユーザエージェント（端末等）に対して信号を転送する（Ｆ１１４）。

この実施形態の場合、図４に示すように、受信信号に、Ｔｏタグ（Ｔｏヘッダのｔａｇパラメータ）があることを転送条件に設定することもでき、また、受信信号に、Ｒｏｕｔｅヘッダがあることを転送条件に設定することもできる。

従って、信号転送判定条件５Ａとして設定可能なパターンは、以下の４つのパターンＰＴ１〜ＰＴ４である。（１）第１のパターンＰＴ１は、Ｔｏタグがあれば、Ｒｏｕｔｅヘッダの存在を問わずに信号を転送させるパターンである。（２）第２のパターンＰＴ２は、Ｒｏｕｔｅヘッダがあれば、Ｔｏタグの存在を問わずに信号を転送させるパターンである。（３）第３のパターンＰＴ３は、Ｔｏタグがあり、かつ、Ｒｏｕｔｅヘッダがあれば信号を転送させるパターンである。（４）第４のパターンＰＴ４は、転送を認めないパターンである。

第１〜第３のパターンＰＴ１〜ＰＴ３のいずれかが設定されている際において、図３のステップＦ１１３に移行してきて、転送が認められる信号は、セッションタイマ信号に利用されているＲｅ−ＩＮＶＩＴＥ信号やＵＰＤＡＴＥ信号などに限定される。言い換えると、ＳＩＰプロキシサーバ２に、転送条件パターンとして第１〜第３のパターンＰＴ１〜ＰＴ３のいずれかを設定している状態では、セッションタイマ信号に利用されているＲｅ−ＩＮＶＩＴＥ信号は、ＳＩＰプロキシサーバ２でエラー処理されることなく、次の段（着側のユーザエージェント）に転送される。

図４に示すＴｏタグの有無判断や、Ｒｏｕｔｅヘッダの有無判断を転送条件に設定することは、ＴＴＣ標準に違反していない。

（Ａ−３）実施形態の効果
上記実施形態によれば、トランザクションステートレスなＳＩＰプロキシサーバに、特定信号の転送可否の判断機能を追加するようにしたので、ＴＴＣ標準に違反することなく、セッションタイマ信号を転送することを可能とすることができる。これにより、トランザクションステートレスなＳＩＰプロキシサーバの特徴を生かしたまま、ＴＴＣ標準準拠の端末−サーバ間でも問題なくサービスを実現することが可能となる。

また、上記実施形態の説明では、単独のＳＩＰプロキシサーバにて実現するイメージで説明したが、図５に示すように、前段にロードバランサを配し、ロードバランサの背後に複数のＳＩＰプロキシサーバ等をとる構成の場合だと、コールステートフルなＳＩＰプロキシサーバだと、サーバ故障等を考えると、各ＳＩＰプロキシサーバで生成されるダイアログの状態をサーバ間で同報させたりしないと、サーバ故障時に、セッションタイマ信号ＮＧになるが、ＳＩＰプロキシサーバが、上記の信号転送の判断機能を適用したトランザクションステートフルなＳＩＰプロキシサーバであれば、故障が発生しても継続的にセッションタイマ信号を転送することが可能である。

なお、ロードバランサの背後の複数のサーバがコールステートフルなＳＩＰプロキシサーバの場合でも、ダイアログ管理が完全でなくなることを許容するのであれば、上述した信号転送の判断機能を適用すれば、セッションタイマ信号を転送することは可能にできる。

（Ｂ）他の実施形態
上記実施形態では、信号転送を許可する条件を任意設定できるものを示したが、ＳＩＰプロキシサーバに固定的に設定されているものであっても良い。その固定設定は、上述した第１〜第３のパターンのいずれかであれば良い。
また、上記実施形態では、信号転送を許可する条件を任意設定できる項目が、図４に示すようなＴｏタグの有無判断や、Ｒｏｕｔｅヘッダの有無判断であるものを示したが、他の項目を条件項目とするようにしても良い。図６は、独自ヘッダ及び独自パラメータを条件の項目としたＳＩＰプロキシサーバの例を示しており、独自ヘッダや独自パラメータの項目を条件の１項目とした場合には、具体的な表記（−／ａａａ、−／ｂｂｂ）を指定することを要する。但し、独自規定の項目に関しては、ユーザエージェントとの整合が必要になる。

さらに、上記実施形態では、トランザクションステートフルなＳＩＰプロキシサーバにて実現するイメージで説明したが、本発明の信号転送の可否判断機能をコールステートフルなＳＩＰプロキシサーバに適用することも可能である。

さらにまた、図４に示した信号転送の可否判断項目は、セッションタイマ信号を意図して選定されたものであるが、特定の呼を通す手段（例えば、サーバ輻輳でも通話確立しているセッションタイマの信号のみ通す等）に対しても、図４に示した信号転送の可否判断項目について定まる条件を適用することも可能である。

上記実施形態では、プロキシサーバとユーザエージェントとの転送プロトコルがＳＩＰプロトコルの場合を示したが、他のピアツーピアのプロトコルを適用しているシステムに対しても本発明を適用することができる。

実施形態の信号転送の判断処理を示すフローチャートである。従来の課題を説明するためのシーケンス図である。実施形態の電話通信システムの構成要素を示すブロック図である。実施形態の転送可否判断条件の項目の説明図である。実施形態の効果を説明するための図面である。他の実施形態の転送可否判断条件の項目の説明図である。

符号の説明

１…ＩＰネットワーク、２…ＳＩＰプロキシサーバ、３…ユーザ情報管理部、４…ルーチング情報管理部、５…信号処理部、１０…呼情報管理部。

Claims

ユーザエージェント間の信号の中継機能を有する、アドレス解決を行うプロキシサーバにおいて、
転送を許可したい特定信号、又は、その特定信号と他の一部の信号とでしか信号内に存在しない項目について、予め設定されている転送可否条件を記憶する転送可否条件記憶手段と、
発信者番号非通知若しくは発信者番号非挿入の受信信号か否かを判断する第１の判断手段と、
発信者番号非通知若しくは発信者番号非挿入の受信信号である場合に、予め設定されている上記転送可否条件に従って、転送可否を判断する第２の判断手段と
を有することを特徴とするプロキシサーバ。
転送可否条件を既定する上記項目は、規格又は規格に準じた標準で規定されているものであることを特徴とする請求項１に記載のプロキシサーバ。
転送可否条件を既定する上記項目として複数が存在し、転送可否条件に利用する項目を外部からの入力により選択できる項目選択手段を有することを特徴とする請求項１又は２に記載のプロキシサーバ。
トランザクションステートフルなＳＩＰプロキシサーバであることを特徴とする請求項１〜３のいずれかに記載のプロキシサーバ。
ユーザエージェント間の特定信号の中継を、アドレス解決を行うプロキシサーバが行うＩＰネットワークの特定信号転送方法において、
上記プロキシサーバは、転送を許可したい特定信号、又は、その特定信号と他の一部の信号とでしか信号内に存在しない項目について、予め設定されている転送可否条件を記憶しており、
受信信号があったときに、発信者番号非通知若しくは発信者番号非挿入の受信信号か否かを判断し、
発信者番号非通知若しくは発信者番号非挿入の受信信号である場合に、予め設定されている上記転送可否条件に従って、転送可否を判断する
ことを特徴とするＩＰネットワークの特定信号転送方法。