JP2012156629A - 信号処理装置及びプログラム - Google Patents

Abstract

【課題】 転送するＳＩＰメッセージを処理する際に、ＳＩＰメッセージを転送先で処理可能な形式に変換することができる信号処理装置を提供する。
【解決手段】 本発明は、ＳＩＰメッセージを受信して処理し送信先の通信装置へ向けて送出する信号処理装置に関する。そして、信号処理装置は、当該信号処理装置がＳＩＰメッセージを処理して、送信先の通信装置へ向けて送出する際の最初の転送先の対象となり得る通信装置のそれぞれについて、対応するＳＩＰメッセージの記述形式に係る情報を保持する手段と、受信したＳＩＰメッセージを、保持している情報に基づいて、最初の転送先の通信装置が処理可能な形式に変換する手段と、変換したＳＩＰメッセージを、当該ＳＩＰメッセージに係る最初の転送先の通信装置に送信する手段とを有することを特徴とする。
【選択図】 図１

Description

この発明は、信号処理装置及びプログラムに関し、例えば、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に対応したネットワークに配置するＳＩＰ−ＡＬＧ（ＳＩＰ Ａｐｐｌｉｃａｔｉｏｎ Ｌｅｖｅｌ Ｇａｔｅｗａｙ）装置に適用することができる。

従来、ＳＩＰ（非特許文献１、２）に対応した複数のネットワークの間を、接続をさせるＳＩＰ−ＡＬＧにおいて、ＳＩＰメッセージの送信先に合わせて、そのＳＩＰメッセージに含まれるＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）のスキームを変更する技術としては、特許文献１に記載の技術がある。

特許文献１の記載技術では、ＳＩＰメッセージを変換する際に、ＳＩＰのリクエストメッセージを受信したときに特殊なパラメータがメッセージ内に付与されているかどうか判断し、条件に一致した場合にスキームを変換するような構成であった。

特表２００９−５１３０５２号公報

ＩＥＴＦ ＲＦＣ２５４３ ＩＥＴＦ ＲＦＣ３２６１

特許文献１では、自網内の端末へ着信させる場合におけるＵＮＩ（Ｕｓｅｒ−Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）接続構成におけるスキーム変換機能について記載されているが、ＮＮＩ（Ｎｅｔｗｏｒｋ−Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）構成は対象としていない。さらに、特許文献１に記載されたスキーム変換機能は、対象がＲｅｑｕｅｓｔ−ｌｉｎｅヘッダに限定されているため、その他のＵＲＩを含むヘッダ（Ｔｏヘッダ、Ｆｒｏｍヘッダ、Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙヘッダ、Ｐ−Ｐｒｅｆｆｅｒｅｄ−Ｉｄｅｎｔｉｔｙヘッダ等）のスキームに関しては考慮されていない。

ＳＩＰ−ＡＬＧ装置をＮＮＩ接続構成とした場合の役割は、別のネットワーク（ＳＩＰ−ＡＬＧ装置は自身のネットワークに配置されているものとする）とのＳＩＰの差分を吸収し、各ネットワークのルールに従い適切にＳＩＰメッセージを生成し転送することである。例えば、Ｒｅｑｕｅｓｔ−ＬｉｎｅヘッダのＵＲＩのスキーム（メッセージ内でのＵＲＩ等の書式）がＴＥＬ−ＵＲＩ（Ｔｅｌｅｐｈｏｎｅ−Ｓｕｂｓｃｒｉｂｅｒ）形式で扱うネットワークなのか、ＳＩＰ−ＵＲＩ形式で扱うネットワークなのかでＳＩＰリクエストの送信先を決定する方式に差異が発生するケースがある。

Ｒｅｑｕｅｓｔ−ＬｉｎｅヘッダのＵＲＩがＴＥＬ−ＵＲＩ形式の場合は、その対地番号（電話番号）で送信先を決定する方式が一般的であり、Ｒｅｑｕｅｓｔ−ＬｉｎｅヘッダのＵＲＩがＳＩＰ−ＵＲＩ形式の場合は、そこに含まれるドメイン名やホスト名で送信先を決定する方式が適用されることもある。このためＳＩＰ−ＡＬＧ装置は対向装置へＳＩＰリクエストを送信する際、どちらかに対応したＳＩＰメッセージを生成して転送する必要がある。さらに、ＳＩＰメッセージを扱う接続先サーバによっては、Ｒｅｑｕｅｓｔ−Ｌｉｎｅヘッダ以外にもＴｏヘッダやＦｒｏｍヘッダがＳＩＰ−ＵＲＩ形式あるいはＴＥＬ−ＵＲＩ形式のメッセージしか読み取れない場合もあり、ネットワーク間をまたぐＳＩＰ−ＡＬＧ装置においては、ＳＩＰ−ＵＲＩとＴＥＬ−ＵＲＩ変換の方式を実装させることが重要である。

上述のような問題に鑑みて、転送するＳＩＰメッセージを処理する際に、ＳＩＰメッセージを転送先で処理可能な形式に変換することができる信号処理装置（例えば、ＳＩＰ−ＡＬＧ装置等）、及び信号処理プログラムが望まれている。

第１の本発明は、送信元の通信装置から送信先の通信装置へ向けて送出されたＳＩＰメッセージを受信して処理し、送信先の通信装置へ向けて送出する信号処理装置において、（１）当該信号処理装置がＳＩＰメッセージを処理して、送信先の通信装置へ向けて送出する際の最初の転送先の対象となり得る通信装置のそれぞれについて、対応するＳＩＰメッセージの記述形式に係る情報を保持する通信装置情報保持手段と、（２）上記通信装置情報保持手段が保持している情報に従って、受信したＳＩＰメッセージを、当該ＳＩＰメッセージに係る最初の転送先の通信装置が処理可能な形式に変換するメッセージ変換手段と、（３）上記メッセージ変換手段が変換したＳＩＰメッセージを、当該ＳＩＰメッセージに係る最初の転送先の通信装置に送信する送信手段とを有することを特徴とする。

第２の本発明の信号処理プログラムは、（１）送信元の通信装置から送信先の通信装置へ向けて送出されたＳＩＰメッセージを受信して処理し、送信先の通信装置へ向けて送出する信号処理装置に搭載されたコンピュータを、（２）当該信号処理装置がＳＩＰメッセージを処理して、送信先の通信装置へ向けて送出する際の最初の転送先の対象となり得る通信装置のそれぞれについて、対応するＳＩＰメッセージの記述形式に係る情報を保持する通信装置情報保持手段と、（３）上記通信装置情報保持手段が保持している情報に従って、受信したＳＩＰメッセージを、当該ＳＩＰメッセージに係る最初の転送先の通信装置が処理可能な形式に変換するメッセージ変換手段と、（４）上記メッセージ変換手段が変換したＳＩＰメッセージを、当該ＳＩＰメッセージに係る最初の転送先の通信装置に送信する送信手段として機能させることを特徴とする。

本発明によれば、転送するＳＩＰメッセージを処理する際に、ＳＩＰメッセージを転送先で処理可能な形式に変換可能することができる信号処理装置を提供することができる。

実施形態に係るＳＩＰ−ＡＬＧ装置（信号処理装置）を備えるネットワークシステムの全体構成について示したブロック図である。 実施形態に係るＳＩＰ−ＡＬＧ装置（信号処理装置）の機能的構成について示したブロック図である。 実施形態に係るスキーム変換対応テーブルの内容例について示した説明図である。 実施形態に係るＳＩＰ−ＡＬＧ装置（信号処理装置）の動作について示したフローチャートである。 実施形態に係るＳＩＰ−ＡＬＧ装置（信号処理装置）が処理するＳＩＰメッセージ（ＩＮＶＩＴＥメッセージ）の具体例（一部ヘッダのみ表記）について示した説明図である。

（Ａ）主たる実施形態
以下、本発明による信号処理装置及びプログラムの一実施形態を、図面を参照しながら詳述する。なお、この実施形態では、本発明の信号処理装置をＳＩＰ−ＡＬＧ装置に適用した場合の例について説明している。

（Ａ−１）実施形態の構成
図２は、この実施形態のＳＩＰ−ＡＬＧ装置１０が配置されたネットワークシステム１の全体構成を示すブロック図である。

ネットワークシステム１には、３つのネットワークＮＡ、ＮＢ、ＮＣが配置されているものとする。そして、図２では、ネットワークＮＡには、ＳＩＰサーバ２０−１が配置されており、ネットワークＮＢには、ＳＩＰサーバ２０−２が配置されており、ＮＣには、ＳＩＰサーバ２０−３が配置されている。なお、ネットワークシステム１に配置されるネットワークの数やネットワーク構成、ＳＩＰサーバの数は限定されないものである。

そして、ネットワークＮＡ、ＮＢ、ＮＣの間にＳＩＰ−ＡＬＧ装置１０が配置されており、ＳＩＰ−ＡＬＧとして機能しているものとする。ＳＩＰ−ＡＬＧ装置１０によりこれらのネットワークは終端され、ネットワーク間の通信についてＳＩＰメッセージ等の中継が行われる。また、ＳＩＰ−ＡＬＧ装置１０は、ＳＩＰメッセージ中継の際に、中継するＳＩＰメッセージと、転送先のＳＩＰサーバとで、ＳＩＰメッセージを構成するＵＲＩのスキームが異なる場合等には、転送先のＳＩＰサーバ２０で処理可能な形式に変換して、送出する処理を行う。

また、各ＳＩＰサーバ２０は、例えば、図示しない配下のＳＩＰ端末や、同一ネットワーク内の他のＳＩＰサーバから受信したＳＩＰメッセージ（ＩＮＶＩＴＥメッセージ等）を処理して、他のネットワークのＳＩＰサーバ２０に転送する必要がある場合に、ＳＩＰ−ＡＬＧ装置１０を介して当該ＳＩＰメッセージを転送する場合もあるものとする。また、各ＳＩＰサーバ２０は、ＳＩＰ−ＡＬＧ装置１０から転送されてきたＳＩＰメッセージを処理して、図示しない配下のＳＩＰ端末や他のＳＩＰサーバに転送する場合もあるものとする。なお、各ＳＩＰサーバ２０としては、既存のものを適用することができるので、詳しい説明を省略する。

さらに、ネットワークＮＡ、ＮＢでは、ＳＩＰメッセージを構成するＵＲＩのスキームとしてＳＩＰ−ＵＲＩ形式が採用されているものとする。また、ネットワークＮＣでは、ＳＩＰメッセージを構成するＵＲＩのスキームとしてＴＥＬ−ＵＲＩが採用されているものとする。すなわち、ＳＩＰ−ＡＬＧ装置１０は、いずれかのネットワークのＳＩＰサーバ２０から受信したＳＩＰメッセージについて、次の転送先のＳＩＰサーバ２０で採用される形式に変換する処理（少なくとも転送先で採用されるスキームに合わせて変換する処理を含む）を行い、さらに、転送先のＳＩＰサーバ２０へ向けて送出する処理を行う。

図１は、ＳＩＰ−ＡＬＧ装置１０の機能的構成について示したブロック図である。

ＳＩＰ−ＡＬＧ装置１０は、制御部１１、スキーム変換対応テーブル１２、及びメッセージ処理部１３を有している。図１では、図示を省略しているが、ＳＩＰ−ＡＬＧ装置１０は、ネットワークに接続するためのインタフェース等、既存のＳＩＰ−ＡＬＧ装置１０と同様のその他の構成も備えているものとする。

ＳＩＰ−ＡＬＧ装置１０は、プロセッサ及びネットワークへ接続するためのインタフェースを有する情報処理装置（１台に限定されず、複数台を分散処理し得るようにしたものであっても良い。）上に、実施形態の信号処理プログラムをインストールすることにより、構築するようにしても良いが、その場合でも機能的には図１のように表すことができる。

制御部１１は、ＳＩＰ−ＡＬＧ装置１０の装置全体を制御する機能を担っている。

メッセージ処理部１３は、ＳＩＰ−ＡＬＧ装置１０に与えられたＳＩＰメッセージ（ＩＮＶＩＴＥメッセージ等）について変換処理等の処理を行い、転送先に向けて送出する。メッセージ処理部１３では、ＳＩＰメッセージを受信すると、例えば、既存のＳＩＰサーバと同様の処理により、受信したＳＩＰメッセージの次の転送先（最初の転送先）を決定し、処理したＳＩＰメッセージを転送先へ向けて送出する。

また、メッセージ処理部１３は、変換処理部１４を有している。メッセージ処理部１３では、受信したＳＩＰメッセージの内容について、送信先に応じて必要な場合変換処理部１４を用いて変換する処理を行う。なお、メッセージ処理部１３によるＳＩＰメッセージの処理は、変換処理部１４による変換処理以外については、既存のＳＩＰ−ＡＬＧ装置と同様の処理を適用することができる。

変換処理部１４は、メッセージ処理部１３に供給されたＳＩＰメッセージを、送信先に応じて、スキーム変換対応テーブル１２の内容に従い変換処理する。

次に、各ＳＩＰサーバ２０で送信されるＳＩＰメッセージを構成するＵＲＩの記述形式の例について説明する。

ＳＩＰ−ＵＲＩに対応するＳＩＰサーバ２０が対応するＳＩＰメッセージを構成するＵＲＩは、例えば、「sip:05022222222@domain.com」のような形式で記述されるものとする。「sip:」は当該ＵＲＩの対応するスキームがＳＩＰ−ＵＲＩであることを示している。また、「sip:」に続く「05022222222」は、電話番号を示しており、当該ＵＲＩにおけるユーザ識別子（ユーザＩＤ）に相当する。なお、ここでは、ＳＩＰ−ＵＲＩのスキームに対応したＵＲＩの例では、電話番号をそのままユーザ識別子として用いている場合を示しているが、電話番号以外の任意の文字列をユーザ識別子として用いるようにしても良い。そして、電話番号に続く「@」で仕切られた後の「domain.com」は、当該ＵＲＩに係るドメイン名を示している。

また、ＳＩＰ−ＴＥＬに対応するＳＩＰサーバが送信するＳＩＰメッセージを構成するＵＲＩは、例えば、「tel:05022222222」のような形式で記述されるものとする。「tel:」は当該ＵＲＩの対応するスキームがＴＥＬ−ＵＲＩであることを示している。また、「tel:」に続く「05022222222」は、電話番号を示しており、当該ＵＲＩにおけるユーザ識別子（ユーザＩＤ）に相当する。なお、ＴＥＬ−ＵＲＩでは、通常ＳＩＰ−ＵＲＩのようにＵＲＩに「@ドメイン名」の記述は含まれない。

ＳＩＰサーバで送信されるＳＩＰメッセージを構成するＵＲＩは、以上のような記述形式となっており、変換処理部１４は、転送先のＳＩＰサーバに合わせた記述形式にあわせた変換を行う。

スキーム変換対応テーブル１２は、変換処理部１４によりＳＩＰメッセージ変換処理が行われる際に参照されるテーブルであり、各ＳＩＰサーバ２０が対応するＳＩＰメッセージを構成するＵＲＩの記述形式に関する情報が登録されている。

図３は、スキーム変換対応テーブル１２に登録される情報の例について示した説明図である。

図３に示すように、スキーム変換対応テーブル１２には、ＳＩＰメッセージの転送先の対象となり得るＳＩＰサーバ２０ごとに、ＵＲＩの記述形式に係る情報として、送信先ＳＩＰサーバ名、スキーム、ドメイン名、番号フォーマットの項目の情報が登録されている。図３では、１行で、一つのＳＩＰサーバに関する情報が記述されている。

「送信先ＳＩＰサーバ名」の項目は、当該ＳＩＰサーバ２０の識別子を示す情報である。送信先ＳＩＰサーバ名の形式は、ＳＩＰサーバ２０を識別することができる形式であれば限定されないものであるが、例えば、ＳＩＰ−ＡＬＧ装置１０から当該ＳＩＰサーバ２０へアクセスするためのＩＰアドレスやホスト名等を適用するようにしても良い。

なお、図３及び以下では、説明を簡易にするために、ＳＩＰサーバ２０−１のホスト名（識別子）を「ＳＩＰサーバ１」、ＳＩＰサーバ２０−２のホスト名を「ＳＩＰサーバ２」、ＳＩＰサーバ２０−３のホスト名を「ＳＩＰサーバ３」と表わすものとする。

「スキーム」の項目は、当該ＳＩＰサーバ２０が対応するＵＲＩのスキームを示す情報である。ここでは、スキームの項目には、ＳＩＰ−ＵＲＩを示す「ＳＩＰ」、又は、ＴＥＬ−ＵＲＩを示す「ＴＥＬ」のいずれかが登録されるものとする。

ここでは、図３に示すように、ＳＩＰサーバ１（ＳＩＰサーバ２０−１）及びＳＩＰサーバ２（ＳＩＰサーバ２０−２）のスキームは「ＳＩＰ」、ＳＩＰサーバ３（ＳＩＰサーバ２０−３）のスキームは「ＴＥＬ」と登録されている。

「ドメイン名」の項目は、当該ＳＩＰサーバ２０が対応するＵＲＩの記述に用いるドメイン名を示す情報である。

ここでは、図３に示すように、ＳＩＰサーバ１（ＳＩＰサーバ２０−１）のドメイン名は「domain.com」、ＳＩＰサーバ２（ＳＩＰサーバ２０−２）のドメイン名は「domain.net」と登録されているものとする。

なお、ここでは、スキームが「ＴＥＬ」の場合には、仕様上ＵＲＩの記述にドメイン名が不要であるため、空欄を示す「−」が登録されるものとする。ＳＩＰサーバ３（ＳＩＰサーバ２０−３）はスキームがＴＥＬであるため、図３に示すように、ドメイン名の項目には空欄を示す「−」が登録されている。

「番号フォーマット」の項目は、当該ＳＩＰサーバ２０が対応するＵＲＩの記述で用いる電話番号（ユーザ識別子）のフォーマット（記述形式）について示している。

次に、ネットワークシステム１において用いられる電話番号のフォーマットについて説明する。

既存の電話番号の形式としては、例えば、ＩＴＵ−Ｔ Ｅ．１６４で定義された形式がある。Ｅ．１６４は、ＩＴＵ−Ｔによる公衆交換電話網などの電話網の電話番号計画に関する勧告であり、頭に「＋」及び国番号が表記された形式が採用されている。日本に対しては、国番号として８１が付与されており、Ｅ．１６４の形式で日本の公衆電話網における電話番号を表記する場合には、電話番号が「＋８１」から始まる番号となる。一方、日本国内の公衆電話網では、Ｅ．１６４の形式ではなく「０」から始まる番号となっている。

ここでは、各ＳＩＰサーバ２０では、対応する電話番号のフォーマットとして、上述のＥ．１６４又は、日本国内の形式（「０」から始まる番号）のいずれかが採用されているものとする。なお、ＳＩＰサーバ２０で採用する電話番号のフォーマットの種類や数については上述のものに限定されないものである。

そして、スキーム変換対応テーブル１２において「番号フォーマット」の項目には、Ｅ．１６４のフォーマットに対応していることを示す「Ｅ．１６４」又は、日本国内のフォーマットに対応していることを示す「国内」のいずれかが登録されるものとする。

そして、ここでは、図３に示すように、ＳＩＰサーバ１（ＳＩＰサーバ２０−１）及びＳＩＰサーバ２（ＳＩＰサーバ２０−２）の番号フォーマットは「国内」、ＳＩＰサーバ３（ＳＩＰサーバ２０−３）の番号フォーマットは「Ｅ．１６４」と登録されているものとする。

（Ａ−２）実施形態の動作
次に、以上のような構成を有するこの実施形態のネットワークシステム１におけるＳＩＰ−ＡＬＧ装置１０の動作を説明する。

ここでは、まず、ＳＩＰ−ＡＬＧ装置１０のメッセージ処理部１３（変換処理部１４）の動作の概要について説明した後、ＳＩＰメッセージ処理の具体例について説明する。なお、以下では、ＳＩＰ−ＡＬＧ装置１０がＩＮＶＩＴＥメッセージについて処理する場合を例として説明するが、他のＵＲＩの記述を含むＳＩＰメッセージについても同様の処理であるため説明を省略する。

図４は、ＳＩＰ−ＡＬＧ装置１０が、ＳＩＰメッセージ（ＩＮＶＩＴＥメッセージ）を受信した場合の動作について示したフローチャートである。

ここでは、まず、ＳＩＰ−ＡＬＧ装置１０のメッセージ処理部１３に、ＳＩＰサーバ２０−１からのＩＮＶＩＴＥメッセージが与えられたものとする（Ｓ１０１）。

そして、メッセージ処理部１３では、そのＩＮＶＩＴＥメッセージの内容等から、次の転送先（最初の転送先）のＳＩＰサーバを決定する（Ｓ１０２）。メッセージ処理部１３による次の転送先の決定方法は、上述の通り、既存の決定方法を用いるようにしても良い。具体的には、例えば、Ｔｏヘッダに記載されたＵＲＩに基づいて決定するようにしても良い。ここでは、メッセージ処理部１３により、次の転送先のＳＩＰサーバが決定され、そのＳＩＰサーバを識別する情報としてホスト名が得られたものとして以降の説明を行う。

次に、メッセージ処理部１３の変換処理部１４により、次の転送先のＳＩＰサーバの情報（スキーム、ドメイン名、及び番号フォーマットの各項目の情報）が、スキーム変換対応テーブル１２から取得される（Ｓ１０３、Ｓ１０４）。ここでは、変換処理部１４は、ホスト名をキーとして、次の転送先のＳＩＰサーバの情報を、スキーム変換対応テーブル１２から検出するものとする。

次に、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩのスキームと、次の転送先のＳＩＰサーバが対応するＵＲＩのスキームを把握する（Ｓ１０５）。

ここでは、各ＳＩＰサーバが対応するＵＲＩのスキームは、ＴＥＬ−ＵＲＩ又はＳＩＰ−ＵＲＩのいずれかである。したがって、ステップＳ１０５で、変換処理部１４が把握する変換内容は、変換対象のＩＮＶＩＴＥメッセージのスキームがＴＥＬ−ＵＲＩで転送先のスキームがＳＩＰ−ＵＲＩの場合、変換対象のＩＮＶＩＴＥメッセージのスキームがＴＥＬ−ＵＲＩで転送先のスキームがＴＥＬ−ＵＲＩの場合、変換対象のＩＮＶＩＴＥメッセージのスキームがＳＩＰ−ＵＲＩで転送先がＴＥＬ−ＵＲＩの場合、又は、変換対象のＩＮＶＩＴＥメッセージのスキームがＳＩＰ−ＵＲＩで転送先のスキームがＳＩＰ−ＵＲＩの場合のいずれかとなる。そして、変換処理部１４は、上述のステップＳ１０５の判定結果に従って、以降のステップの処理でＩＮＶＩＴＥメッセージの変換を行う。

なお、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩのスキームについて、変換対象のＩＮＶＩＴＥメッセージの内容を解析して判定するようにしても良いし、転送元のＳＩＰサーバ２０のホスト名を把握して、スキーム変換対応テーブル１２から読み込んで把握するようにしても良い。変換処理部１４が、変換対象のＩＮＶＩＴＥメッセージの内容を解析して、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩのスキームを判定する場合には、例えば、各ヘッダに含まれるＵＲＩが、「sip:」で始まる場合にはＳＩＰ−ＵＲＩと判定し、「tel:」で始まる場合にはＴＥＬ−ＵＲＩと判定するようにしても良い。

上述のステップＳ１０５において、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩのスキームがＴＥＬ−ＵＲＩ、次の転送先のＳＩＰサーバ２０が対応するスキームがＳＩＰ−ＵＲＩと判定された場合、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージについて各ヘッダのＵＲＩに係るスキームを変換する処理を行う（Ｓ１０６）。

上述の通り、ＴＥＬ−ＵＲＩのスキームに対応したＵＲＩは「tel:」で始まり、ＳＩＰ−ＵＲＩのスキームに対応したＵＲＩは「sip:」で始まる。したがって、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージの各ヘッダのＵＲＩについて、「tel:」を「sip:」に変換することによりスキームを変換する。

さらに、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージにおける、各ヘッダのＵＲＩにドメイン名（次の転送先のＳＩＰサーバで用いられるもの）を付与する処理を行う（Ｓ１０７）。

上述の通り、ＴＥＬ−ＵＲＩのスキームに対応したＵＲＩは、「tel:05022222222」等「tel:」＋「電話番号」という構成をとることが一般的である。これに対して、ＳＩＰ−ＵＲＩのスキームに対応したＵＲＩは、例えば、「sip:05022222222@domain.net」等、「sip:」＋「ユーザ識別子」＋「@ドメイン名」という構成をとることが一般的である。すなわち、ＴＥＬ−ＵＲＩのスキームに対応したＵＲＩでは、「@ドメイン名」の部分が記述されていない。そこで、上述のステップＳ１０７の処理により、変換対象の各ヘッダのＵＲＩに「@」及び次の転送先のＳＩＰサーバで用いられるドメイン名の記述を追加する処理を行う。

上述のステップＳ１０５において、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩのスキームがＳＩＰ−ＵＲＩ、次の転送先のＳＩＰサーバ２０が対応するスキームがＴＥＬ−ＵＲＩと判定された場合、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージについて各ヘッダのＵＲＩに係るスキームを変換する処理を行う（Ｓ１０８）。

具体的には、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージの各ヘッダのＵＲＩについて、「sip:」を「tel:」に変換することによりスキームを変換する。

さらに、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージにおける、各ヘッダのＵＲＩからドメイン名の記述を削除する処理を行う（Ｓ１０９）。

上述の通り、ＴＥＬ−ＵＲＩのスキームに対応したＵＲＩでは、「@ドメイン名」の部分が記述されないため、上述のステップＳ１０９の処理により、変換対象の各ヘッダのＵＲＩから、「@ドメイン名」の記述を削除する処理を行う。

上述のステップＳ１０５において、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩのスキームがＳＩＰ−ＵＲＩ、次の転送先のＳＩＰサーバ２０が対応するスキームもＳＩＰ−ＵＲＩと判定された場合、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージについて、各ヘッダのＵＲＩに記述されたドメイン名を、次の転送先で用いられるドメイン名に変換する処理を行う（Ｓ１１０）。

ＳＩＰメッセージのＵＲＩで用いられるドメイン名は、通常ネットワークごとに異なるものが用いられるため、同じＳＩＰ−ＵＲＩのスキームに対応したＳＩＰサーバ２０間でもドメイン名が異なる場合、正常なメッセージ処理が行われないことがある。そのため、変換処理部１４では、変換対象のＩＮＶＩＴＥメッセージのＵＲＩで用いられるドメイン名が、転送先のＳＩＰサーバで通用するものに変換する処理を行う。なお、ＵＲＩで用いられるドメイン名が各ネットワークで全て同じ場合や、ドメイン名が異なっていても転送先のＳＩＰサーバ２０で正常にメッセージ処理が可能な場合は、上述のステップＳ１１０の処理は省略するようにしても良い。

上述のステップＳ１０５において、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩのスキームがＴＥＬ−ＵＲＩ、次の転送先のＳＩＰサーバ２０が対応するスキームもＴＥＬ−ＵＲＩと判定された場合、又は、上述のステップＳ１０７、Ｓ１０９、Ｓ１１０のいずれかの処理が完了した場合、次に、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩの電話番号のフォーマット、及び、次の転送先のＳＩＰサーバが対応する電話番号のフォーマットを判定する処理を行う（Ｓ１１１）。

ここでは、各ＳＩＰサーバが対応する番号フォーマットは、上述の通り、国内又はＥ．１６４のいずれかである。したがって、ステップＳ１１１で、変換処理部１４が把握する内容は、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットが「国内」で転送先における番号フォーマットがＥ．１６４の場合、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットが国内で転送先における番号フォーマットが国内の場合、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットがＥ．１６４で転送先における番号フォーマットが国内の場合、又は、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットがＥ．１６４で転送先における番号フォーマットがＥ．１６４の場合のいずれかとなる。そして、変換処理部１４は、上述のステップＳ１１１の判定結果に従って、以降のステップの処理で、受信したＩＮＶＩＴＥメッセージの変換を行う。

なお、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットについては、変換対象のＩＮＶＩＴＥメッセージの内容を解析して判定するようにしても良いし、転送元のＳＩＰサーバのホスト名を把握して、スキーム変換対応テーブル１２から読み込んで把握するようにしても良い。変換処理部１４が、変換対象のＩＮＶＩＴＥメッセージの内容を解析して、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットを判定する場合には、例えば、各ヘッダに含まれるＵＲＩの、「sip:」又は「tel:」に続く電話番号の部分が「+」（又は「+81」）で始まる場合にはＥ．１６４と判定し、「0」で始まる場合には国内と判定するようにしても良い。

上述のステップＳ１１１において、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットが国内で、次の転送先のＳＩＰサーバが対応する番号フォーマットがＥ．１６４と判定された場合、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージについて各ヘッダのＵＲＩに係る番号フォーマットを変換する処理を行う（Ｓ１１２）。

上述の通り、番号フォーマットが国内に対応する場合には、ＵＲＩにおける電話番号は、例えば「05022222222」と先頭が「0」で始まる。また、番号フォーマットがＥ．１６４に対応する場合には、ＵＲＩにおける電話番号は、例えば、「+815022222222」と先頭が「+81」で始まる点で国内と異なる。したがって、この場合、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージの各ヘッダのＵＲＩについて、電話番号の部分のうち先頭を「0」から「+81」に変換することにより、番号フォーマットの変換を行う。

なお、ここでは、転送先のＳＩＰサーバ２０における番号フォーマットがＥ．１６４の場合には、変換処理部１４は、電話番号を構成する国番号を全て日本のもの（81）として処理しているが、スキーム変換対応テーブル１２にＳＩＰサーバ２０ごとの国番号を登録しておいて、転送先のＳＩＰサーバ２０に合わせた国番号として処理するようにしても良い。

一方、上述のステップＳ１１１において、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットがＥ．１６４で、次の転送先のＳＩＰサーバ２０が対応する番号フォーマットが国内と判定された場合、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージについて各ヘッダのＵＲＩに係る番号フォーマットを変換する処理を行う（Ｓ１１３）。この場合、変換処理部１４は、変換対象のＩＮＶＩＴＥメッセージの各ヘッダのＵＲＩについて、上述のステップＳ１１２と逆の処理、すなわち、電話番号の部分のうち先頭の「+国番号」の部分「+81」を「0」に変換することにより、番号フォーマットの変換を行う。

なお、上述のステップＳ１１１で、変換処理部１４により、変換対象のＩＮＶＩＴＥメッセージ及び次の転送先のＳＩＰサーバ２０の対応する番号フォーマットが同一の場合、又は、上述のステップＳ１１２、Ｓ１１３の処理のいずれかが完了すると、変換処理部１４によるＩＮＶＩＴＥメッセージの変換処理は終了する。そして、変換後のＩＮＶＩＴＥメッセージが、メッセージ処理部１３により次の転送先のＳＩＰサーバ２０へ送信される（Ｓ１１４）。

なお、上記の説明では、各ＳＩＰサーバが対応する番号フォーマットは、国内又はＥ．１６４のいずれかであるとしたが、既存のＳＩＰサーバが対応するＳＩＰ−ＵＲＩのスキームでは、ＵＲＩに含まれるユーザ識別子が番号のみで構成されている電話番号形式ではなく、任意の文字により構成された文字列の形式（以下、「アカウント形式」という）の場合もある。仮に、上述のステップＳ１１１で、変換処理部１４により、変換対象のＩＮＶＩＴＥメッセージを構成するＵＲＩに含まれるユーザ識別子が、アカウント形式であると判定された場合には、番号フォーマットの変換等は行わずに、上述のステップＳ１１４の処理に移行するようにしても良い。変換処理部１４が、ＳＩＰ−ＵＲＩ形式のＵＲＩの内容を解析して、ユーザ識別子の記述形式を認識する方法としては、例えば、「sip:」と「@」との間で、数字以外の記号が含まれる場合（ただし、先頭に「+」が配置されている場合は無視）には、アカウント形式と認識し、数字だけで構成されている場合には電話番号形式と認識するようにしても良い。

次に、上述の図４のフローチャートに従って、変換処理部１４が動作し、ＩＮＶＩＴＥメッセージを変換する場合の具体的な例について説明する。

図５は、ＳＩＰ−ＡＬＧ装置１０において処理されるＩＮＶＩＴＥメッセージの内容例について示した説明図である。なお、図５に示す各ＩＮＶＩＴＥメッセージでは、説明を簡易にするため、変換処理部１４で変換対象となるヘッダ情報（すなわち、ＵＲＩの記述を含むヘッダ情報）以外の部分については省略して図示している。

そして、ここでは、図５（ａ）に示す内容のＩＮＶＩＴＥメッセージが、変換処理部１４の変換対象となっているものとして説明する。

そして、まず最初に、図５（ａ）のＩＮＶＩＴＥメッセージに係る次の転送先のＳＩＰサーバ２０が、上述のステップＳ１０２の処理により、ＳＩＰサーバ２０−２と決定した場合の変換処理部１４による変換処理について説明する。

この場合、変換処理部１４では、上述のステップＳ１０３、Ｓ１０４の処理で、スキーム変換対応テーブル１２から、ＳＩＰサーバ２０−２の情報（スキーム：ＳＩＰ、ドメイン名：domain.net、番号フォーマット：国内）が取得される。

なお、ＳＩＰサーバ２０−１については、スキーム変換対応テーブル１２の内容、又は、図５（ａ）に示すＩＮＶＩＴＥメッセージに含まれるＵＲＩの構成から、「スキーム：ＳＩＰ、ドメイン名：domain.com、番号フォーマット：国内」と把握できる。例えば、図５（ａ）のＩＮＶＩＴＥメッセージのＩＮＶＩＴＥヘッダに記載されたＵＲＩでは「sip:05022222222@domain.com」となっている。このＵＲＩは「sip:」から始まるためＵＲＩのスキームはＳＩＰ−ＵＲＩと把握できる。また、このＵＲＩの「sip:」に続く電話番号は「0」から始まっているので、番号フォーマットは国内と把握できる。また、電話番号に続いて「@domain.com」となっているため、ドメイン名は「domain.com」と把握できる。

そして、次に、上述のステップＳ１０５の判定が行われるが、この場合は、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩのスキームがＳＩＰ−ＵＲＩで、次の転送先のＵＲＩのスキームもＳＩＰ−ＵＲＩであるので、上述のステップＳ１１０の処理に移行することになる。

ステップＳ１１０では、上述の通り、ＩＮＶＩＴＥメッセージの各ヘッダのＵＲＩに記述されたドメイン名が、次の転送先で用いられるドメイン名に変換される。この場合、各ＵＲＩの「domain.com」が「domain.net」に変換されることになる。

図５（ｂ）は、上述の図５（ａ）のＩＮＶＩＴＥメッセージが、上述のステップＳ１１０の処理に従って変換された後の内容について示している。

図５（ｂ）に示すように、変換前の「sip:05022222222@domain.com」というＵＲＩの記述が「sip:05022222222@domain.net」という記述に変換されている。また、図５（ｂ）では、変換前の「sip:05011111111@domain.com」というＵＲＩの記述が「sip:05011111111@domain.net」という記述に変換されている。

そして、次に、上述のステップＳ１１１の判定が行われるが、この場合は、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットが国内で、次の転送先のＵＲＩの番号フォーマットも国内であるので、番号フォーマットに関する変換は行われず、上述のステップＳ１１４の処理に移行し、変換処理部１４による変換処理は終了することになる。

次に、図５（ａ）のＩＮＶＩＴＥメッセージに係る次の転送先のＳＩＰサーバが、上述のステップＳ１０２の処理により、ＳＩＰサーバ２０−３と決定した場合の変換処理部１４による変換処理について説明する。

この場合、変換処理部１４では、上述のステップＳ１０３、Ｓ１０４の処理で、スキーム変換対応テーブル１２から、ＳＩＰサーバ２０−３の情報（スキーム：ＴＥＬ、ドメイン名：「−」（空欄）、番号フォーマット：Ｅ．１６４）が取得される。

そして、次に、上述のステップＳ１０５の判定が行われるが、この場合は、変換対象のＩＮＶＩＴＥメッセージにおけるＵＲＩのスキームがＳＩＰ−ＵＲＩで、次の転送先のＵＲＩのスキームがＴＥＬ−ＵＲＩであるので、上述のステップＳ１０８の処理に移行することになる。

そして、ステップＳ１０８の処理では、上述の通り、ＩＮＶＩＴＥメッセージの各ヘッダのＵＲＩについて、スキームを変換（ＳＩＰ−ＵＲＩからＴＥＬ−ＵＲＩへ変換）する処理が行われる。この場合、各ＵＲＩの先頭の「sip:」が全て「tel:」に変換されることになる。

そして続くステップＳ１０９では、上述の通り、ＩＮＶＩＴＥメッセージの各ヘッダのＵＲＩに記述されたドメイン名が削除される。この場合、各ＵＲＩの「@domain.com」の部分の記述が削除されることになる。

図５（ｃ）は、上述の図５（ａ）のＩＮＶＩＴＥメッセージが、上述のステップＳ１０８及びステップＳ１０９の処理に従って変換された後の内容例について示している。

図５（ｃ）に示すように、変換前の「sip:05022222222@domain.com」というＵＲＩの記述が「tel:05022222222」という記述に変換されている。また、図５（ｂ）では、変換前の「sip:05011111111@domain.com」というＵＲＩの記述が「tel:05011111111」という記述に変換されている。

そして、次に、上述のステップＳ１１１の判定が行われるが、この場合は、変換対象のＩＮＶＩＴＥメッセージにおける番号フォーマットが国内で、次の転送先のＵＲＩの番号フォーマットがＥ．１６４であるので、上述のステップＳ１１２の処理に移行することになる。

そして、ステップＳ１１２の処理では、上述の通り、ＩＮＶＩＴＥメッセージの各ヘッダのＵＲＩについて、番号フォーマットを変換する処理（国内からＥ．１６４へ変換）する処理が行われる。この場合、各ＵＲＩの電話番号（ユーザＩＤ）の部分のうち先頭が、「+81」から「0」に変換されることになる。

図５（ｄ）は、上述の図５（ｃ）のＩＮＶＩＴＥメッセージが、上述のステップＳ１１２の処理に従って変換された後の内容例について示している。

図５（ｄ）に示すように、変換前の「tel:05022222222」というＵＲＩの記述が「tel:+815022222222」という記述に変換されている。また、図５（ｂ）では、変換前の「tel:05011111111」というＵＲＩの記述が「tel:+815011111111」という記述に変換されている。

（Ａ−３）実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。

ＳＩＰ−ＡＬＧ装置１０では、スキーム変換対応テーブル１２を用いたＳＩＰメッセージを構成するＵＲＩのスキーム変換等の処理を実現している。これにより、ＳＩＰ−ＡＬＧ装置１０を介した各ネットワークのＳＩＰサーバ２０において、対応するＵＲＩのスキーム等が異なっていても、転送先のＳＩＰサーバ２０が対応するルールに則ったＳＩＰメッセージを生成、転送することができ、ネットワーク間の接続親和性を高めることができる。

（Ｂ）他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

（Ｂ−１）上記の実施形態において、ネットワークシステム１を構成する各ネットワーク（ネットワークＮＡ、ＮＢ、ＮＣ）が対応するプロトコルは、ＩＰｖ４としても良いしＩＰｖ６としても良い。また、各ネットワークが対応するプロトコルは全て同一（例えば、全てＩＰｖ６に対応）としても良いし、複数のプロトコルが混在（例えば、一部のネットワークはＩＰｖ４に対応し、その他のネットワークはＩＰｖ６に対応）するような構成としても良い。

また、上記の実施形態では、ＳＩＰ−ＡＬＧ装置１０は、ネットワーク間のＳＩＰメッセージを処理するものとして説明したが、同一ネットワーク内のＳＩＰサーバ間のＳＩＰメッセージ処理を行う構成としても良い。

さらに、上記の実施形態では、ＳＩＰ−ＡＬＧ装置１０が、ＳＩＰメッセージを行うことについて説明したが、ＳＩＰメッセージ以外のデータ（ＩＰパケット）の転送も行うゲートウェイ（信号処理装置）として構築するようにしても良い。

（Ｂ−２）上記の実施形態において、スキーム変換対応テーブル１２については、図３に示すように、ＳＩＰサーバ単位でＵＲＩの記述形式の情報を登録する例について示しているが、情報を登録する単位はこれに限定されないものである。例えば、同一のネットワーク内のＳＩＰサーバに関する情報が同じ場合には、スキーム変換対応テーブル１２に転送先のネットワークごとに情報を登録し、変換処理部１４が、変換対象のＳＩＰメッセージの次の転送先のＳＩＰサーバが属するネットワークの情報を、当該ＳＩＰサーバの情報として取得するようにしても良い。

（Ｂ−３）上記の実施形態において、全てのネットワークで対応する番号フォーマットが同じ場合には、ＳＩＰ−ＡＬＧ装置１０において番号フォーマットの変換処理を省略するようにしても良い。また、その場合、スキーム変換対応テーブル１２から番号フォーマットに係る項目を省略するようにしても良い。

（Ｂ−４）上記の実施形態において、変換処理部１４は、変換対象ＳＩＰメッセージを構成するユーザ識別子が電話番号の場合に、その電話番号の番号フォーマットについて、次の転送先のＳＩＰサーバが対応する番号フォーマットに変換する処理について説明した（上述の図４のステップＳ１１１〜１１３参照）。ここで、変換処理部１４によるユーザ識別子の変換を、番号フォーマットの変換ではなく、ユーザ識別子自体の変換を行うようにしても良い。例えば、一人のユーザに、ユーザ識別子として、「05011111111」という電話番号形式の識別子と、「abcdef」というアカウント形式の識別子が付与されている場合を想定する。また、スキーム変換対応テーブル１２に各ＳＩＰサーバ２０が対応するユーザ識別子の記述形式の項目（「電話番号形式」又は「アカウント形式」のいずれかで示される項目）を追加して登録しておくものとする。さらに、ＳＩＰ−ＡＬＧ装置１０は、ユーザごとのアカウント形式のユーザ識別子と、電話番号形式のユーザ識別子との対応テーブル（以下、「識別子対応テーブル」という）も備えているものとする。そして、変換処理部１４は、変換対象のＳＩＰメッセージにおけるユーザ識別子の記述形式と、次の転送先のＳＩＰサーバ２０が対応するユーザ識別子の記述形式を把握し、記述形式が異なる場合には、ＵＲＩを構成するユーザ識別子の部分について、上述の識別子対応テーブルを用いて、変換するようにしても良い。

なお、変換処理部１４が、変換対象のＳＩＰメッセージで対応するユーザ識別子の記述形式を認識する方法としては、例えば、スキーム変換対応テーブル１２の内容から認識するようにしいても良いし、当該ＳＩＰメッセージに含まれるＵＲＩの内容を解析して認識するようにしても良い。

ここで、例として、あるユーザに電話番号形式のユーザ識別子として「05011111111」、アカウント形式のユーザ識別子として「abcdef」が付与されている場合を想定する。そして、変換処理部１４で当該ユーザのＵＲＩが含まれるＳＩＰメッセージを変換する際に、変換対象のＳＩＰメッセージにおける記述形式が電話番号形式で、次の転送先のＳＩＰサーバが対応する記述形式がアカウント形式であったものとする。この場合、変換処理部１４は、上述の識別子対応テーブルを用いて、「05011111111」に対応するユーザ識別子として「abcdef」を検出し、さらに、当該ＳＩＰメッセージのＵＲＩに含まれる、「05011111111」というユーザ識別子を、「abcdef」というユーザ識別子に変換する処理を行う。例えば、変換前のＵＲＩが「sip:05011111111@domain.com」だった場合には、「sip:abcdef@domain.com」と変換されることになる。

１…ネットワークシステム、２０、２０−１〜２０−３…ＳＩＰサーバ、１０…ＳＩＰ−ＡＬＧ装置（信号処理装置）、１１…制御部、１２…スキーム変換対応テーブル、１３…メッセージ処理部、１４…変換処理部、ＮＡ、ＮＢ、ＮＣ…ネットワーク。

Claims (6)

1. 送信元の通信装置から送信先の通信装置へ向けて送出されたＳＩＰメッセージを受信して処理し、送信先の通信装置へ向けて送出する信号処理装置において、
   当該信号処理装置がＳＩＰメッセージを処理して、送信先の通信装置へ向けて送出する際の最初の転送先の対象となり得る通信装置のそれぞれについて、対応するＳＩＰメッセージの記述形式に係る情報を保持する通信装置情報保持手段と、
   上記通信装置情報保持手段が保持している情報に従って、受信したＳＩＰメッセージを、当該ＳＩＰメッセージに係る最初の転送先の通信装置が処理可能な形式に変換するメッセージ変換手段と、
   上記メッセージ変換手段が変換したＳＩＰメッセージを、当該ＳＩＰメッセージに係る最初の転送先の通信装置に送信する送信手段と
   を有することを特徴とする信号処理装置。
2. 上記通信装置情報保持手段が保持する情報には、上記転送先の対象となり得る通信装置のそれぞれが対応するＳＩＰメッセージのＵＲＩに係るスキームの種別の情報が含まれており、
   上記メッセージ変換手段は、受信したＳＩＰメッセージに含まれるＵＲＩを、当該ＳＩＰメッセージに係る最初の転送先の通信装置が対応するスキームに変換する
   ことを特徴とする請求項１に記載の信号処理装置。
3. 上記通信装置情報保持手段が保持する情報には、さらに、上記転送先の対象となり得る通信装置のそれぞれが対応するＳＩＰメッセージのＵＲＩを構成するドメイン名の情報が含まれており、
   上記メッセージ変換手段は、さらに、受信したＳＩＰメッセージに含まれるＵＲＩを構成するドメイン名の部分を、当該ＳＩＰメッセージに係る最初の転送先の通信装置が対応するドメイン名とする処理を行う
   ことを特徴とする請求項２に記載の信号処理装置。
4. 上記通信装置情報保持手段が保持する情報には、さらに、上記転送先の対象となり得る通信装置のそれぞれが対応するＳＩＰメッセージのＵＲＩを構成するユーザ識別子の記述形式に係る種別の情報が含まれており、
   上記メッセージ変換手段は、さらに、受信したＳＩＰメッセージに含まれるＵＲＩを構成するユーザ識別子の部分を、当該ＳＩＰメッセージに係る最初の転送先の通信装置が対応する記述形式に変換する処理を行う
   ことを特徴とする請求項２又は３に記載の信号処理装置。
5. 上記ユーザ識別子は、電話番号形式であることを特徴とする請求項４に記載の信号処理装置。
6. 送信元の通信装置から送信先の通信装置へ向けて送出されたＳＩＰメッセージを受信して処理し、送信先の通信装置へ向けて送出する信号処理装置に搭載されたコンピュータを、
   当該信号処理装置がＳＩＰメッセージを処理して、送信先の通信装置へ向けて送出する際の最初の転送先の対象となり得る通信装置のそれぞれについて、対応するＳＩＰメッセージの記述形式に係る情報を保持する通信装置情報保持手段と、
   上記通信装置情報保持手段が保持している情報に従って、受信したＳＩＰメッセージを、当該ＳＩＰメッセージに係る最初の転送先の通信装置が処理可能な形式に変換するメッセージ変換手段と、
   上記メッセージ変換手段が変換したＳＩＰメッセージを、当該ＳＩＰメッセージに係る最初の転送先の通信装置に送信する送信手段と
   して機能させることを特徴とする信号処理プログラム。

Images