JP2006287697A - Ｉｐセントレックスシステム - Google Patents

Abstract

【課題】
ＳＩＰを搭載したＩＰセントレックス網内に、複数のＳＩＰサーバの接続を中継するセンタサーバを設けた際に、ＳＩＰサーバ上で発生する折り返し呼の接続を正常に行い、センタサーバで呼制御を集中的に管理し、課金、トラヒック制御等をセンタサーバのみで行なう。
【解決手段】 自サーバがターゲットに送信したメッセージが、同一セッションで、かつ別トランザクションでターゲットから送信される折り返し呼が発生した場合に、ＳＩＰサーバで１個のセッションを２個のセッション（呼）として扱うことで、各々別のリモートターゲットを確定し、折り返し接続を行うことと、同一Ｒｅｑｕｅｓｔ−ＵＲＩによるメッセージの送信先を、前段の装置と、企業とで、別方向にルーチングする。これによって、ＳＩＰを搭載したＩＰセントレックス網内に設置された複数のＳＩＰサーバの接続を中継するセンタサーバを実現する。
【選択図】 図１０

Description

本発明は、ＩＰセントレックスシステムに関し、特に、ＩＰセントレックス網に設置されたプロキシサーバにおける呼接続のためのルーチングシステムの制御方法に関する。

ＩＰ（Internet Protocol）セントレックスシステムは、各企業に、ＰＢＸの代わりに、ＳＩＰ（Session Initiation Protocol）プロキシサーバ（以下、「ＳＩＰサーバ」という）を設置して通話を制御するシステムである。このＩＰセントレックスシステムでは、企業の規模により、１つの企業で１台から数台のＳＩＰサーバを使用したり、１台で複数の企業を収容し、互いのＳＩＰサーバを連携させて呼の接続を行う。

ＳＩＰサーバは、企業の規模や形態により、企業に設置する場合や、ＩＰセントレックス網側に設置する場合もある。以下に、ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ（Request for Comment）３２６１に述べられている仕様に基づいた呼の接続方式の一例について、図１を参照しながら説明する。

図１は、ＲＦＣ３２６１に基づいた制御によってＳＩＰサーバの呼接続時の処理を表したシーケンスの一例を示し、発信端末１からＳＩＰサーバ２を経由して着信端末３に接続し、着側の呼び出しに成功した場合のシーケンスの一例を示す。

ＳＩＰは、ＲＦＣ３２６１に基づくリクエスト・レスポンスの送受信で構成されるプロトコルであり、ＳＩＰのセッションは、ダイアログ（Ｄｉａｌｏｇｓ）を使用して管理する。ダイアログは、ＳＩＰメッセージヘッダのＣａｌｌ−ＩＤ値、ローカルタグ（local-tag）、リモートタグ（remote-tag）から識別し、ＳＩＰメッセージのヘッダのＴｏタグ、Ｆｒｏｍタグ、及びＣａｌｌ−ＩＤを使用する。

呼接続のため、発信端末１からＩＮＶＩＴＥリクエスト４を受信したＳＩＰサーバ２は、ＩＮＶＩＴＥリクエスト４のヘッダを使用して、ダイアログが一致する呼を特定する。呼が特定されない場合には、新規呼として新たなダイアログの生成のための情報を、呼識別のための情報として保存する（ステップＳ１）。

ＳＩＰサーバ２では、ＲＦＣ３２６１に準拠した制御にて、受信したリクエストのＳＩＰヘッダから、リクエストメッセージの有効性のチェックを行い（ステップＳ２）、ルーチングの前処理としてＲｅｑｕｅｓｔ−ＵＲＩをチェックする（ステップＳ３）。

その後、Ｒｅｑｕｅｓｔ−ＵＲＩから、次接続先である装置を判定するため、リクエストのターゲットを確定する処理を行い（ステップＳ４）、ターゲットにリクエストをフォワードするため、ＳＩＰメッセージ編集（Ｖｉａヘッダや、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの付与等）を行い（ステップＳ５）、メッセージ５を送信する。尚、リクエストのターゲットの特定には、Ｒｅｑｕｅｓｔ−ＵＲＩを使用する。

ＳＩＰサーバ２は、Ｒｅｑｕｅｓｔ−ＵＲＩを翻訳し、メッセージの送信先である接続先の装置、端末等を求める。リクエストのターゲットの特定には、Ｒｅｑｕｅｓｔ−ＵＲＩヘッダを使用する。

ＳＩＰサーバ２は、Ｒｅｑｕｅｓｔ−ＵＲＩを翻訳し、翻訳した結果からメッセージの送信先である接続先装置、端末等を求める。そのため、ＳＩＰサーバ２には、Ｒｅｑｕｅｓｔ−ＵＲＩの内容から接続先の装置、端末等を一意に求めることができる情報を予め設定しておく。

図２は、Ｒｅｑｕｅｓｔ−ＵＲＩから接続先装置を求めるための情報を設定するためのテーブルの一例を示し、図３は、Ｒｅｑｕｅｓｔ−ＵＲＩから接続先を求めるための処理フローの一例を示す。

図１に戻り、次に、リクエストに対するレスポンス６を受信すると、受信したＳＩＰメッセージから呼を特定し（ステップＳ６）、先頭のＶｉａヘッダを削除する（ステップＳ７）。その後、レスポンスのフォワード確認を行い（ステップＳ８）、フォワード可能であれば、必要に応じてメッセージを編集し、レスポンス７を透過する。上記処理によってリクエストとレスポンスの透過を行う。

次に、従来のＩＰセントレックス網の構成について、図４を参照しながら説明する。

従来のＩＰセントレックス網１２は、ＰＳＴＮ（Public Switched Telephone Networks）網１１に接続され、各ＳＩＰサーバ１〜ｎをメッシュに接続した構成である。メッシュ型で接続した場合、各ＳＩＰサーバ１〜ｎには、ＩＰセントレックス網１２内で接続するすべての装置情報が必要となる。

図２は、各ＳＩＰサーバ１〜ｎに設定されるルーチング情報の一例を示し、１台のＳＩＰサーバには、ＩＰセントレックス網１２内に設置された他のＳＩＰサーバに接続するための情報をすべてを備える必要がある。このような接続形態では、ＩＰセントレックスシステムの規模が大きくなり、ＳＩＰサーバの設置台数が増加するに従って各ＳＩＰサーバに必要なルーチング情報量も比例して増加する。

また、構成を変更した場合、例えば、図４のＩＰセントレックス網１２に企業Ｘが追加され、ＳＩＰサーバＸを新たに設置すると、ＳＩＰサーバ１〜ｎには、ＳＩＰサーバＸに対してのルーチング情報を各々追加する必要がある。

前述のとおり、従来方式では、ＩＰセントレックスシステムに新規企業を追加する場合や、構成を変更する場合には、既に設置されているＳＩＰサーバのルーチング情報を変更する必要がある。この問題を解決するためには、ＩＰセントレックス網内のＳＩＰサーバの接続形態を、現状の接続形式から、ＩＰセントレックス網の中核に、中継交換機相当のＳＩＰサーバ（以下、「センタサーバ」と表示する）を設置し、他企業網に対する接続の場合には、センタサーバを中継するような接続形態に変更することが考えられる。

図５は、センタサーバ２３を設置したＩＰセントレックス網２２の接続形態の一例を示す。ＩＰセントレックス網２２は、ＰＳＴＮ網２１に接続され、ＳＩＰサーバ１〜ｎは、企業規模により設置台数も異なり、複数企業で１台のＳＩＰサーバを使用している場合もある。

例えば、企業網２から企業網３に接続する場合には、ＳＩＰメッセージは、企業網２→ＳＩＰサーバ２→センタサーバ２３→ＳＩＰサーバ２→企業網３とＳＩＰメッセージを透過しなければならず、ＳＩＰサーバ２では、自サーバがターゲットに送信したメッセージが、同一セッションで、かつ別トランザクションで、ターゲットから送信されてくるという現象が発生する。ここで、本現象を「折り返し」と表現し、以下、折り返しが発生する接続を、「折り返し接続」と表現する。

従来の方式では、リクエストのターゲットである接続先の情報は、Ｒｅｑｕｅｓｔ−ＵＲＩから一意に決定する仕組みであったため、図６に示すように、ＳＩＰサーバ２では、センタサーバ２３から折り返しが発生した場合、再度同一のＲｅｑｕｅｓｔ−ＵＲＩを翻訳し、再度センタサーバ２３にリクエストを送信するという現象が発生してしまう。

図６は、図５に示した企業網２から企業網３に接続する際、従来のリクエストターゲットの確定方式で接続先を決定した場合に発生する現象を示したシーケンス図である。以下、図６のシーケンスについて説明する。

図５の企業網３の配下の端末を示すＵＲＩはｘｘｘであり、ＳＩＰサーバ２には、Ｒｅｑｕｓｔ−ＵＲＩ：ｘｘｘのターゲットして、センタサーバ２３を指定したデータを設定してあり、センタサーバ２３には、Ｒｅｑｕｅｓｔ−ＵＲＩ：ｘｘｘのターゲットとしてＳＩＰサーバ２を指定したデータが設定されている。

企業網２から企業網３に接続する場合には、企業網２からＳＩＰサーバ２に対し、Ｒｅｑｕｅｓｔ−ＵＲＩ：ｘｘｘが設定されたＩｎｉｔｉａｌ−ＩＮＶＩＴＥメッセージ３１が送信される。

ＳＩＰサーバ２では、Ｒｅｑｕｅｓｔ−ＵＲＩ：ｘｘｘからターゲットであるセンタサーバ２３を求め、メッセージを編集した後、センタサーバ２３に対してＩｎｉｔｉａｌ−ＩＮＶＩＴＥ３２を送信する。

次に、センタサーバ２３は、ＳＩＰサーバ２と同様に、受信したＩｎｉｔｉａｌ−ＩＮＶＩＴＥ３２のＲｅｑｕｅｓｔ−ＵＲＩを使用してターゲットを決定する。受信したＩｎｉｔｉａｌ−ＩＮＶＩＴＥ３２のＲｅｑｕｅｓｔ−ＵＲＩは、Ｒｅｑｕｅｓｔ−ＵＲＩ：ｘｘｘであるため、ターゲットとしてＳＩＰサーバ２が求められる。そこで、センタサーバ２３は、メッセージを編集し、ＳＩＰサーバ２にＩｎｉｔｉａｌ−ＩＮＶＩＴＥ３３を送信する。

ＳＩＰサーバ２は、受信したＩｎｉｔｉａｌ−ＩＮＶＩＴＥ３３のＲｅｑｕｅｓｔ−ＵＲＩ：ｘｘｘからターゲットを求めるが、先程と同じＲｅｑｕｅｓｔ−ＵＲＩであるため、ターゲットとして、再度センタサーバ２３を求め、センタサーバ２３にＩｎｉｔｉａｌ−ＩＮＶＩＴＥ３４を送信することになる。

この後、ＳＩＰサーバ２と、センタサーバ２３との間で、Ｉｎｉｔｉａｌ−ＩＮＶＩＴＥを透過し続け、図６に示したとおり、ＳＩＰサーバとセンタサーバ２３との間でループ６０が発生し、呼接続を行うことができない。上記ループ現象が発生するため、ＩＰセントレックスシステムでは、センタサーバ設置の接続形態をとることができなかった。

そこで、本発明は、ＩＰセントレックス網にてセンタサーバを設置する接続方法を採用した場合に発生する折り返し接続を正常に行うことを可能とし、ＩＰセントレックスシステムに新規企業を追加する場合や、構成を変更する場合に、既に設置されているＳＩＰサーバのルーチング情報を変更する必要のないＩＰセントレックスシステムを提供することを目的とする。

上記目的を達成するため、本発明は、ＩＰセントレックスシステムであって、複数のＳＩＰサーバの接続を中継するセンタサーバを備えることを特徴とする。

また、本発明は、センタサーバであって、複数のＳＩＰサーバの接続を中継することを特徴とする。

センタサーバを設置することにより、すべての呼をセンタサーバを経由させるシステムを構成することができ、センタサーバで呼制御を集中的に管理することが可能になる。これにより、課金や、トラヒック制御をセンタサーバのみで行なうことができる。

また、センタサーバを設置することにより、各ＳＩＰサーバではＩＰセントレックス網の他装置へのルーチング情報を設定する必要がなくなり、センタサーバへのルーチング情報のみ設定するだけで、他のＳＩＰサーバとの接続が可能になり、装置に設定する情報量を削減することができる。

さらに、ＩＰセントレックス網に新規ＳＩＰサーバを設置する場合や、構成を変更する場合にも、他のＳＩＰサーバのルーチング情報を変更する必要がなくなり、ＩＰセントレックス網内の構成変更も容易になるという効果もある。

前記センタサーバは、発信側装置を特定するためのデータベースと、該データベースを用いてＲｅｑｕｅｔ−ＵＲＩを翻訳する手段と、該Ｒｅｑｕｅｔ−ＵＲＩの翻訳を行うためのデータベースと、該Ｒｅｑｕｅｔ−ＵＲＩの翻訳結果により、ＳＩＰメッセージをルーチングさせる手段と、該ルーチングを行うためのデータベースとを備えるようにすることができる。これによって、同一Ｒｅｑｕｅｔ−ＵＲＩであっても、別方向にＳＩＰメッセージを透過させることができ、折り返し接続時には、ＳＩＰサーバで１個のダイアログを２個の別のセッションとして扱うことが可能となる。その結果、上記ＳＩＰを搭載したＩＰセントレックス網内に設置された複数のＳＩＰサーバの接続を中継するセンタサーバを実現することができる。

また、前記センタサーバの前記Ｒｅｑｕｅｔ−ＵＲＩの翻訳を行うためのデータベースは、前記発信側装置毎又は／及び企業毎に設定可能であるとともに、前記ルーチングを行うためのデータベースは、企業毎に設定可能とすることができる。これによって、発信側装置又は／及び企業により、リクエストのターゲットを別対地にすることができる。

さらに、本発明は、ＳＩＰサーバであって、発信側装置を特定するためのデータベースと、該データベースを用いてＲｅｑｕｅｔ−ＵＲＩを翻訳する手段と、該Ｒｅｑｕｅｔ−ＵＲＩの翻訳を行うためのデータベースと、該Ｒｅｑｕｅｔ−ＵＲＩの翻訳結果により、ＳＩＰメッセージをルーチングさせる手段と、該ルーチングを行うためのデータベースとを備えることを特徴とする。これによって、同一Ｒｅｑｕｅｔ−ＵＲＩであっても、別方向にＳＩＰメッセージを透過させることができ、折り返し接続時には、ＳＩＰサーバで１個のダイアログを２個の別のセッションとして扱うことが可能となる。その結果、上記ＳＩＰを搭載したＩＰセントレックス網内に設置された複数のＳＩＰサーバの接続を中継するセンタサーバを実現することができる。

前記ＳＩＰサーバの前記Ｒｅｑｕｅｔ−ＵＲＩの翻訳を行うためのデータベースは、前記発信側装置毎又は／及び企業毎に設定可能とするとともに、前記ルーチングを行うためのデータベースは、企業毎に設定可能とすることができる。これによって、発信側装置又は／及び企業により、リクエストのターゲットを別対地にすることができる。

以上のように、本発明によれば、ＩＰセントレックス網にてセンタサーバを設置する接続方法を採用した場合に発生する折り返し接続を正常に行うことが可能となり、ＩＰセントレックスシステムに新規企業を追加する場合や、構成を変更する場合に、既に設置されているＳＩＰサーバのルーチング情報を変更することなどが不要となる。

図５は、本発明の一実施の形態としてのセンタサーバを設置したＩＰセントレックスシステムの構成を示す。センタサーバ２３は、ＩＰセントレックス網２２を介して、ＧＷ２４、ＳＩＰサーバ１〜ｎ等と接続される。ＩＰセントレックス網２２は、ＧＷ２４を介してＰＳＴＮ網２１に接続されている。

ＳＩＰサーバは、企業規模により１〜ｎ個の企業網を収容する。また、企業規模によっては、複数のＳＩＰサーバで１つの企業網を収容することもある。ＳＩＰサーバ１〜ｎは、収容する企業網１〜ｎ、及びセンタサーバ２３に、ＩＰセントレックス網２２を介して接続される。

次に、上記ＳＩＰサーバ１〜ｎの構成について、図７乃至図９を参照しながら説明する。

ＳＩＰサーバは、図７に示すように、呼の生起を検出して呼の接続、呼の解放を行う呼処理制御部４５と、接続先として指定されたＲｅｑｕｅｓｔ−ＵＲＩを分析して対地を求めるＲｅｑｕｅｓｔ−ＵＲＩ翻訳制御部４６と、対地より接続先を決定するルーチング制御部４４と、発信装置を判定するための図示しない装置管理制御部から構成される。さらに、Ｒｅｑｕｅｓｔ−ＵＲＩ翻訳テーブル４３と、ルーチングテーブル４１と、装置テーブル４２とを備えている。

装置テーブル４２には、図８に示すように、対向する装置の情報として、ＩＰアドレスとポートとを設定するように構成される。この表に示すように、ＩＰアドレスとポートとで装置を特定することができる。

図９は、ＳＩＰサーバが備えるＲｅｑｕｅｓｔ−ＵＲＩ翻訳テーブル４３の一例を示す。このＲｅｑｕｅｓｔ−ＵＲＩ翻訳テーブル４３には、Ｒｅｑｕｅｓｔ−ＵＲＩから接続先の対地を求める情報を設定する。対地は、装置毎、企業毎に設定することが可能であり、また、企業、装置に関わらず設定することもできるため、同一のＲｅｑｕｅｓｔ−ＵＲＩであっても、装置、企業により、リクエストのターゲットを別対地にすることができる。

図７のルーチングテーブル４１には、Ｒｅｑｕｅｓｔ−ＵＲＩ翻訳テーブル４３で求めた対地毎と企業毎に、接続先装置のＩＰアドレスとポートの情報を設定する。接続先装置のＩＰアドレスとポートとは、前述した装置テーブル４２の情報を使用してもよい。

次に、センタサーバ２３の構成について説明する。センタサーバ２３は、ＲＦＣ３２６１に準拠したプロキシサーバである必要がある。センタサーバ２３は、接続が集中するため、分散処理が可能なシステム構成とすることが望ましい。また、センタサーバ２３は、１個のＲｅｑｕｅｓｔ−ＵＲＩからは１個のターゲットを確定することができ、ＲＦＣ３２６１に準拠した制御でＳＩＰメッセージを透過することができる必要がある。

次に、センタサーバ２３を設置したＩＰセントレックス網で発生する折り返し呼の接続動作時の動作について、図１０を参照しながら説明する。尚、同図は、図５の企業網２から企業網３に通話を行う場合の接続図である。

企業網２及び企業網３には、各々ＳＩＰが搭載された端末１、端末２、端末３、端末４が設置されている。

端末１から端末３に接続する場合には、ＳＩＰメッセージは、端末１、ＳＩＰサーバ２、センタサーバ２３、ＳＩＰサーバ２、端末３の順に透過する。

ここで、呼接続時の制御について説明する。折り返し接続が発生した場合には、ＳＩＰサーバ２では、ＲＦＣ３２６１で定義された１つのダイアログを、２個の呼（呼１、呼２）として制御する。

企業網２の端末１から呼接続のためのＩＮＶＩＴＥ５０を受信すると、図５のＳＩＰサーバ２は、ＲＦＣ３２６１に準拠した制御で受信したメッセージがＩｎｉｔｉａｌ−ＩＮＶＩＴＥであることを特定する。

次に、ＳＩＰサーバ２で、リクエストのターゲットを確定するための制御について、図１１を参照しながら説明する。

ＳＩＰサーバ２は、受信したＩＮＶＩＴＥ５０のＶｉａヘッダを使用し、図８の装置テーブル４２の検索を行う。装置テーブル４２に該当データが存在した場合には、装置の情報を記憶させておく。受信したＩＮＶＩＴＥ５０のＲｅｑｕｅｓｔ−ＵＲＩと、記憶した装置で、図９のＲｅｑｕｅｓｔ−ＵＲＩ翻訳テーブル４３を検索し、リクエストの送信先となるターゲットの対地を検索する。図１１の場合、ターゲットはセンタサーバ２３となる。

ＳＩＰサーバ２は、企業網２のセンタサーバ２３のルーチングテーブルから、接続先のセンタサーバ２３のＩＰアドレスとポートを取得し、取得したＩＰアドレスとポートに対してＩＮＶＩＴＥ５１を送信する。尚、送信時にはＲＦＣ３２６１に準拠したターゲットへのリクエストの送信のための処理を行う。

さらに、本発明では、ＳＩＰサーバ２がＩＮＶＩＴＥを透過する際、ＩＮＶＩＴＥメッセージのトランザクションデータとは別に、Ｖｉａヘッダ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダを図５の呼１の情報として保存する。

図１２は、ＳＩＰサーバ２が保持する呼の情報を示したブロック図である。センタサーバ２３では、ＳＩＰサーバ２から受信したメッセージについて、ＲＦＣ３２６１に準拠したルーチングを行い、ＳＩＰサーバ２に対して送信する。ＳＩＰサーバ２は、センタサーバ２３から受信したＩＮＶＩＴＥ５２のダイアログから呼を特定する。

本発明では、ここで、ＲＦＣ３２６１のダイアログ識別ロジックに加え、ＳＩＰサーバ２がＩＮＶＩＴＥを送信する際にセーブしたＶｉａヘッダ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダの比較処理を行う。

受信したＩＮＶＩＴＥのＦｒｏｍヘッダと、呼１で保存したＦｒｏｍヘッダとを比較し、同一であれば、メッセージの送信元は同一、すなわち、呼が折り返してきたと判断する。折り返しの判断をした場合には、受信したＩＮＶＩＴＥの前段装置の比較を行うため、呼１のＶｉａ情報と、受信したＩＮＶＩＴＥのＶｉａ情報とを比較し、前段装置が同一か否かを判断する。受信したＩＮＶＩＴＥのＶｉａ情報が一致すれば、一致した呼に割り振る。

図１０の場合には、受信したＩＮＶＩＴＥのＶｉａからはセンタサーバ２３の情報、呼１の情報からは端末１の情報が得られるため、両者は一致しない。従って、新規呼と判断し、新たに呼２を生成する。これにより、上記制御で、折り返しで発生した同一ダイアログを２個の呼に分割することが可能になる。呼を分割することにより、ＳＩＰサーバ２では、２個の新規呼として扱うことができ、各々別のセッションとして扱うことが可能になる。

呼２では、呼１と同様に、受信したＩＮＶＩＴＥより送信元の装置を特定する。受信したＩＮＶＩＴＥメッセージには、センタサーバ２３の透過時に、センタサーバ２３のＶｉａヘッダが付与されているため、装置テーブル４２を検索すると、メッセージ送信元装置がセンタサーバ２３であることが判る。

メッセージ送信元がセンタサーバ２３であるため、Ｒｅｑｕｅｓｔ−ＵＲＩ翻訳テーブルを検索する。呼１の時とは検索条件が異なるため、対地をＳＩＰサーバ２が収容する企業網３を選択することができる。そして、Ｒｅｑｕｅｓｔ−ＵＲＩの翻訳結果より、ＳＩＰサーバ２は、端末向けのルーチング制御を行い、自収容の企業３の端末３にメッセージを送信する。

ＳＩＰサーバ２は、ＩＮＶＩＴＥメッセージ透過時、ＩＮＶＩＴＥメッセージのＶｉａヘッダ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダを図５の呼２の情報として保存する。この時の、Ｖｉａヘッダ、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダは、呼１で保存した情報とは異なる。

次に、図１０におけるＩｎｉｔａｉｌ−ＩＮＶＩＴＥに対するレスポンス５１の受信時の制御を説明する。リンギング（１８０Ｒｉｇｉｎｇ）、及び応答（２００ＯＫ）等のレスポンスの場合も、ダイアログの識別により呼を特定し、呼１、呼２を検索する。その後、リクエスト送信時に保存したＶｉａヘッダが一致する呼を特定する。図１０の場合には、端末３からのレスポンスを受信したＳＩＰサーバ２で呼２が特定される。

その後、ＳＩＰサーバ２では、ＲＦＣ３２６１に準拠した制御を行い、レスポンスをセンタサーバ２３に送信する。センタサーバ２３でも、同様に、ダイアログで呼を検索し、ＳＩＰサーバ２に対してレスポンスを送信する。ＳＩＰサーバ２では、センタサーバ２３からのレスポンスを受け、端末３からの受信時と同様の制御を行う。ここでは、呼１を検索することができ、端末１へレスポンスを送信する。

次に、応答確認（ＡＣＫ）の制御について説明する。図１０の端末１からのＡＣＫを受信したＳＩＰサーバ２では、ダイアログの識別より呼１、呼２を特定する。複数の呼を特定した場合には、呼に保存されているリクエストと受信リクエストのＦｒｏｍタグの比較を行う。

Ｆｒｏｍタグが存在しない場合には、Ｆｒｏｍヘッダの比較を行う。これらが同一であれば、Ｖｉａの比較を行う。ここでは、端末１からのメッセージであるため、呼１を特定することができる。その後は、ＩＮＶＩＴＥ時と同等ＲＦＣ３２６１に準拠した方式でリクエストを送信する。

センタサーバ２３でも同様に、ダイアログから呼を特定し、リクエストを送信する。ＳＩＰサーバ２では、センタサーバ２３から受信したメッセージを、端末から受信した時と同様に制御する。Ｆｒｏｍの比較、Ｖｉａの比較を行うと、ここでは、呼２を特定することができる。呼２を特定した後、リクエストを端末３に送信する。上記手順により、センタサーバ２３を経由した折り返し呼の接続が完了する。

次に、着側からの切断について説明する。ＳＩＰ端末３からのＢＹＥメッセージを受信した場合には、ＳＩＰサーバ２は、ダイアログにより呼１、呼２を特定することができ、ここで、呼毎に保存されているＦｒｏｍヘッダと、受信リクエストのＦｒｏｍヘッダとを比較すると、呼１、呼２どちらも一致しない。

一致しない場合には、次に、呼毎にセーブしてあるＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダと、受信メッセージのＲｏｕｔｅヘッダとの比較を行う。Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダは、メッセージ透過の際に経由した装置経路を示すヘッダであり、Ｒｏｕｔｅヘッダは、Ｒｅｃｏｒｄ−Ｒｏｕｔｅヘッダから生成した経由すべき装置を示したヘッダである。

呼１で保存されたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダには、ＳＩＰサーバ２の情報が残り、呼２で保存されたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダには、ＳＩＰサーバ２、センタサーバ２３、ＳＩＰサーバ２の情報が残る。

ＳＩＰサーバ２で端末３より受信したＢＹＥヘッダのＲｏｕｔｅヘッダには、ＳＩＰサーバ２、センタサーバ２３、ＳＩＰサーバ２の情報が設定されている。経路を比較すると、ＢＹＥの残りの経路は、呼２で保存したＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダと一致する。従って、受信したＢＹＥは呼２に割り振ることができる。その後、ＲＦＣ３２６１に準拠した制御で、センタサーバ２３にメッセージを送信する。センタサーバ２３は、呼を特定した後、ＳＩＰサーバ２にメッセージを送信する。

次に、ＳＩＰサーバ２でＢＹＥを受信した場合、ＢＹＥのＲｏｕｔｅヘッダからはＳＩＰサーバ２の情報だけが残る。呼１、呼２に保存されたＲｅｃｏｒｄ−Ｒｏｕｔｅヘッダと経路を比較すると、呼１が一致するため、呼１に割り振り、その後端末１に送信する。ＢＹＥを受信した端末１では、切断可能であると判断したならば、切断応答のレスポンス（２００ＯＫ）を返信する。レスポンスは、ダイアログで呼を特定した後、Ｖｉａが一致する呼に割り振る。

ＳＩＰサーバ２では、端末１からの２００ＯＫを受信した場合には、呼１を特定し、センタサーバ２３から受信した場合には、呼２を特定する。呼に割り振った後は、ＲＦＣ３２６１に基づきレスポンスを透過する。上記制御により折り返し接続時の切断が完了する。

上記に示した以外のリクエスト、レスポンスの制御、例えば、保留時のＩＮＶＩＴＥ、転送時のＲＥＦＥＲ等もこれらと同様の手順で行うことができる。

ＩＥＴＦのＲＦＣ３２６１に基づいた制御にてＳＩＰサーバの呼接続時の処理を表したシーケンス図である。 Ｒｅｑｕｅｓｔ−ＵＲＩから接続先装置を求めるための情報を設定するテーブルの一例を示す図である。 Ｒｅｑｕｅｓｔ−ＵＲＩから接続先を求める従来方式のシーケンス図である。 従来のＩＰセントレックス網の一例を示すブロック図である。 本発明にかかるセンタサーバを設置したＩＰセントレックス網の一実施形態を示すブロック図である。 センタサーバを設置したＩＰセントレックス網で、従来のリクエストターゲット確定方式を用いた場合に発生するシーケンス図である。 本発明にかかるＳＩＰサーバの一例を示すブロック図である。 本発明にかかる装置テーブルの一例を示す図である。 Ｒｅｑｕｅｓｔ−ＵＲＩ翻訳テーブルの一例を示す図である。 本発明にかかるＩＰセントレックスシステムでセンタサーバ折り返しの呼が発生した場合の接続の一例を示す図である。 本発明の折り返し時のリクエストターゲット確定方式を示したシーケンス図である。 本発明にかかるＳＩＰサーバで保持する呼情報の一例を示す図である。

符号の説明

１ 発信端末
２ ＳＩＰサーバ
３ 受信端末
４ ＩＮＶＩＴＥ
５ ＩＮＶＩＴＥ
６ １８０Ｒｉｎｇｉｎｇ
７ １８０Ｒｉｎｇｉｎｇ
１１ ＰＳＴＮ網
１２ ＩＰセントレックス網
１３ ＧＷ
２１ ＰＳＴＮ網
２２ ＩＰセントレックス網
２３ センタサーバ
２４ ＧＷ
３１ ＩＮＶＩＴＥリクエスト
３２ ＩＮＶＩＴＥリクエスト
３３ ＩＮＶＩＴＥリクエスト
３４ ＩＮＶＩＴＥリクエスト
４１ ルーチングテーブル
４２ 装置テーブル
４３ Ｒｅｑｕｅｓｔ−ＵＲＩ翻訳テーブル
４４ ルーチング制御部
４５ 呼処理制御部
４６ Ｒｅｑｕｅｓｔ−ＵＲＩ翻訳制御部
５０ ＩＮＶＩＴＥリクエスト
５１ ＩＮＶＩＴＥリクエスト
５２ ＩＮＶＩＴＥリクエスト
５５ ＩＮＶＩＴＥレスポンス
６０ ループ

Claims (6)

1. ＳＩＰ（Session Initiation Protocol）プロキシサーバの接続を中継するセンタサーバを備えることを特徴とするＩＰセントレックスシステム。
2. 複数のＳＩＰプロキシサーバの接続を中継することを特徴とするセンタサーバ。
3. 前記センタサーバは、
   発信側装置を特定するためのデータベースと、
   該データベースを用いてＲｅｑｕｅｔ−ＵＲＩを翻訳する手段と、
   該Ｒｅｑｕｅｔ−ＵＲＩの翻訳を行うためのデータベースと、
   該Ｒｅｑｕｅｔ−ＵＲＩの翻訳結果により、ＳＩＰメッセージをルーチングさせる手段と、
   該ルーチングを行うためのデータベースとを備えることを特徴とする請求項２に記載のセンタサーバ。
4. 前記Ｒｅｑｕｅｔ−ＵＲＩの翻訳を行うためのデータベースは、前記発信側装置毎又は／及び企業毎に設定可能であるとともに、前記ルーチングを行うためのデータベースは、企業毎に設定可能であることを特徴とする請求項３に記載のセンタサーバ。
5. ＳＩＰプロキシサーバであって、
   発信側装置を特定するためのデータベースと、
   該データベースを用いてＲｅｑｕｅｔ−ＵＲＩを翻訳する手段と、
   該Ｒｅｑｕｅｔ−ＵＲＩの翻訳を行うためのデータベースと、
   該Ｒｅｑｕｅｔ−ＵＲＩの翻訳結果により、ＳＩＰメッセージをルーチングさせる手段と、
   該ルーチングを行うためのデータベースとを備えることを特徴とするＳＩＰプロキシサーバ。
6. 前記Ｒｅｑｕｅｔ−ＵＲＩの翻訳を行うためのデータベースは、前記発信側装置毎又は／及び企業毎に設定可能であるとともに、前記ルーチングを行うためのデータベースは、企業毎に設定可能であることを特徴とする請求項５に記載のＳＩＰプロキシサーバ。

Images