JP2008211452A

JP2008211452A - Ｓｉｐサーバ

Info

Publication number: JP2008211452A
Application number: JP2007045419A
Authority: JP
Inventors: Junji Tagane; 淳司田金; Ryuji Oda; 龍二小田
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2007-02-26
Filing date: 2007-02-26
Publication date: 2008-09-11
Anticipated expiration: 2027-02-26
Also published as: US8189764B2; JP4738363B2; US20080205607A1

Abstract

【課題】セッション毎にサーバ内に保持するルートセット情報を含んだメモリ量を削減し、サーバの輻輳を抑制するＳＩＰサーバを提供する。
【解決手段】ＳＩＰサーバ１００は、セッション毎にＳＩＰ信号で特定されるルートセット情報のうちレコードルートヘッダのアドレス情報を論理番号に対応付け、共通するレコードルートヘッダのアドレス情報について単一の論理番号を設定するルート管理テーブルを保持する第１のメモリ部２０と、レコードルートヘッダのアドレス情報を除くセッション情報、セッション制御に使用するインスタンス管理情報及び論理番号を保持する第２のメモリ部３０と、を備え、第２のメモリ部３０に保持する論理番号に基づき、第１のメモリ部２０に保持するレコードルートヘッダのアドレス情報を読み出す。
【選択図】図１

Description

この発明は、ＩＰネットワーク経由で行われる電話通信を管理及び制御するＩＰテレフォニーサーバであって、ＩＰネットワーク上でマルチメディアセッションを開始／変更／終了するためのプロトコルとして、セッション開始プロトコル（Session Initiation Protocol：以下、ＳＩＰと称す）を使用するＳＩＰサーバに関する。

ＳＩＰは、ＩＥＴＦ（Internet Engineering Task Force）のＳＩＰワーキンググループで提案され、ＲＦＣ３２６１で標準化されている。ＳＩＰを利用したネットワークでは、加入者の端末（User Agent：以下、ＵＡと称す）のうち、発呼側の端末（User Agent Client：以下、ＵＡＣと称す）と着呼側の端末（User Agent Server：以下、ＵＡＳと称す）との間の通信は、複数のプロキシサーバを経由して行なわれる。

図６は、ＲＦＣ３２６１に準拠した経路制御（Route Set：以下、ルートセットと称す）情報を説明するためのメッセージシーケンスの一例を示すシーケンス図である。なお、図６において、発端末（ＵＡＣ）と着端末（ＵＡＳ）との間の通信は、サーバＢ、サーバＭ及びサーバＹを経由して行なわれるものとする。また、ＳＩＰヘッダ名である、Request-URIはRURI、Record-RouteはRR、ContactはC、RouteはRとして、それぞれ省略して表している。

ここで、ＳＩＰにおいては、初期信号であるＩＮＶＩＴＥが通過したサーバを記録するRecord-Routeヘッダ（以下、レコードルートヘッダと称す）が存在する。このレコードルートヘッダ及び末端となる加入者の端末（ＵＡ）のアドレス情報を示すContactヘッダ（以下、コンタクトヘッダと称す）から、Routeヘッダ（以下、ルートヘッダと称す）を構築する。そして、以降のリクエストの転送には、ルートヘッダに従ってリクエスト転送を行なうルールをＲＦＣが採用している。このうち、レコードルートヘッダは初期信号であるＩＮＶＩＴＥで確立した経路情報を後の信号で変更してはならず、ルートセット（レコードルートヘッダ及びコンタクトヘッダ）情報は加入者の端末（ＵＡ）が保持するルールとなっている。

このように、発端末（ＵＡＣ）は、ＳＩＰメッセージで発信したセッション確立要求をＳＩＰサーバにてプロキシし、着端末（ＵＡＳ）に着信させる。そして、着端末（ＵＡＳ）により応答すると、ＳＩＰサーバを介して発端末（ＵＡＣ）に通知する。これにより、ＩＰテレフォニーにおけるセッションの通話を確立させる。

しかしながら、ＲＦＣ３２６１によると、プロキシ動作を行なうＳＩＰサーバはルートセット情報を管理する必要は無いのであるが、ＳＩＰサーバからセッションを切断したいという要求も実際には存在する。特に、ＳＩＰサーバの構成としてＰｒｏｘｙ方式とＢ２ＢＵＡ（Back-To-Back User Agent）方式があり、Ｂ２ＢＵＡ方式の場合には、ＳＩＰサーバは加入者の端末（ＵＡ）として動作するためにルートセット情報を管理しなければならない。また、Ｐｒｏｘｙ方式の場合には、本来はルートセット情報を管理する必要は無いのであるが、ＳＩＰサーバからの切断などにより必要に応じてルートセット情報を管理する必要がある。このように、従来のＳＩＰサーバにおいては、Ｐｒｏｘｙ方式やＢ２ＢＵＡ方式に関わらず、セッション毎にルートセット情報を管理する必要があり、セッション毎にルートセット情報を保持するメモリ領域を確保し、ＳＩＰサーバ内にルートセット情報を保持している。

例えば、従来のＳＩＰサーバは、ＩＮＶＩＴＥ要求を受信し、ヘッダに含まれる標準的なルーティング情報と本体に含まれる付加的な発呼者情報に応じて、被呼側エンドポイントのアドレスを判定し、セッションを判定されたアドレスにルーティングする（例えば、特許文献１参照）。

また、従来のＳＩＰサーバは、アドレス変換情報を呼毎にＶｏＩＰ用アドレス変換装置に通知し、アドレス変換装置は、プライベートＩＰ網側からのＳＩＰメッセージをグローバルＩＰ網側のＩＰアドレスに変換し、グローバルＩＰ網側からのＳＩＰメッセージをプライベートＩＰ網側のＩＰアドレスに変換し、同一のプライベートＩＰ網に接続されたＩＰ電話端末同士で通信する場合には、単一のアドレス変換装置を介して端末同士で直接通信するように設定し、複数のプライベートＩＰ網に跨って接続された端末同士で通信する場合には、単一のアドレス変換装置を介して端末同士で直接通信するようにするか、複数のアドレス変換装置を連携させ、グローバル網を介して端末同士で通信する（例えば、特許文献２参照）。

本来、加入者の端末（ＵＡ）は、自端末で使用するセッション数（通常の通話であれば１つであるが、複数のセッションに使用しても問題は無い）分のルートセット情報を管理すればよいのであるが、ＳＩＰサーバのメモリ内にセッション毎のルートセット情報を管理する構成とすれば、ＳＩＰサーバ側は最大同時接続数分のルートセット情報を保持する必要がある。

例えば、図７（ａ）に示すように、ＳＩＰサーバ１００を中心（自サーバ）として、プロキシサーバである、第１のプロキシサーバ１０１（Ｐｒｏｘｙ＃１（ＩＰアドレス”192.168.10.11”））、第２のプロキシサーバ１０２（Ｐｒｏｘｙ＃２（ＩＰアドレス”192.168.10.12”））、第３のプロキシサーバ１０３（Ｐｒｏｘｙ＃３（ＩＰアドレス”192.168.10.13”））、第４のプロキシサーバ１０４（Ｐｒｏｘｙ＃４（ＩＰアドレス”192.168.10.14”））又は第５のプロキシサーバ１０５（Ｐｒｏｘｙ＃５（ＩＰアドレス”192.168.10.15”））を経由して、加入者の端末（ＵＡ）である、第１の加入者端末２０１（ＵＡ＃１（ＩＰアドレス”192.168.1.100”））、第２の加入者端末２０２（ＵＡ＃２（ＩＰアドレス”192.168.1.101”））又は第３の加入者端末２０３（ＵＡ＃３（ＩＰアドレス”192.168.1.102”））間の電話通信を行なう場合を考える。

図７（ａ）はＳＩＰサーバ内に経路情報を保持する場合を説明するための説明図、図７（ｂ）は図７（ａ）に示す自サーバ内に保持される経路情報の一例を示した説明図である。なお、実線はセッション＃１の経路、破線はセッション＃２の経路、一点鎖線はセッション＃３の経路をそれぞれ示している。

自サーバで３つのセッションが通信中である場合には、図７（ｂ）に示すように、セッション＃１、セッション＃２及びセッション＃３における各ルートセット情報のアドレス情報の文字列をＳＩＰサーバ１００のメモリ上に管理することとなる。なお、図７では、ＩＰアドレス形式を一例として示しているが、ＤＮＳ（Domain Name System）によってアドレス解決が可能なＦＱＤＮ（Fully Qualified Domain Name）のアドレス形式の場合も同様に考えられる。

さらに具体例を示すと、１０万セッションの同時接続を許容するＳＩＰサーバにおいて、１セッションに４つのレコードルートヘッダを使用し、１アドレスのサイズが一般的な２５６ｂｙｔｅであると仮定する。この場合には、ＳＩＰサーバ全体でルートセット情報の管理に必要となるメモリ量は、（コンタクトヘッダ×２＋レコードルートヘッダ×４）×最大同時接続数であり、計算値は、（２５６ｂｙｔｅ×２＋２５６ｂｙｔｅ×４）×１００，０００セッション≒１５４Ｍｂｙｔｅの計１５４Ｍｂｙｔｅのメモリが必要となる。１セッション分で考えると、１．５４ｋｂｙｔｅのメモリの確保が必要である。さらに、このメモリ量は、レコードルートヘッダの数が増加すれば、それに比例して必要なメモリ量は増加することとなる。なお、通信中においても呼救済を行なう必要があるために、このメモリは、ヒープ（heap）領域では無く、共有メモリ領域に確保する必要がある。

特に、ＡＣＴ（運用）系のＳＩＰサーバ（以下、ＡＣＴ系ＳＩＰサーバと称す）とＳＴＡＮＤＢＹ（待機）系のＳＩＰサーバ（以下、ＳＢＹ系ＳＩＰサーバと称す）とを備えた冗長構成サーバ（ＡＣＴ／ＳＢＹ）を用いる場合には、ＡＣＴ系ＳＩＰサーバからＳＢＹ系ＳＩＰサーバに切り替えている間のセッション救済のために、ＡＣＴ系ＳＩＰサーバに故障が発生する前に系間でルートセット情報をＳＢＹ系ＳＩＰサーバに転送しておく必要がある。
特開２００２−３３５２６７号公報特開２００５−７２８１７号公報

従来のＳＩＰサーバにおいては、ＳＩＰサーバ内に大容量（前述した具体例では、ルートセット情報を記録するメモリ領域のみで１５６Ｍｂｙｔｅ）のメモリを備える必要があるいう問題点があった。

特に、ＩＰテレフォニーサーバの高信頼性を確保するために、ＳＩＰサーバの冗長化（ＡＣＴ／ＳＢＹなど）を構成する場合には、セッション救済に必要なメモリ領域を、ＡＣＴ系ＳＩＰサーバからＳＢＹ系ＳＩＰサーバに系間で引継ぐ必要があり、セッション制御時に系間でのメモリ転送処理が動作する。このため、ルートセット情報を管理するデータエリアが大きくなるほど転送量は増え、さらに高負荷状態になるとＳＩＰサーバの輻輳を早期に招き、ＩＰテレフォニーサーバの性能が劣化するという問題点があった。

また、ＡＣＴ系ＳＩＰサーバ及びＳＢＹ系ＳＩＰサーバ間を一度に転送できる転送量を超過すれば、セッション救済に必要なメモリ領域を分割して転送する必要が生じ、ＩＰテレフォニーサーバの性能に悪影響を与えるという問題点があった。

この発明は、上述のような課題を解決するためになされたもので、第１の目的は、セッション毎にサーバ内に保持するルートセット情報を含んだメモリ量を削減し、サーバの輻輳を抑制するＳＩＰサーバを提供するものである。

また、第２の目的は、冗長構成サーバにおけるＡＣＴ系ＳＩＰサーバ及びＳＢＹ系ＳＩＰサーバ間の系間のメモリ転送量を削減し、輻輳を抑制するＳＩＰサーバを提供するものである。

この発明に係るＳＩＰサーバにおいては、所定のプロキシサーバのアドレス情報を論理番号に対応付け、共通するプロキシサーバのアドレス情報について単一の論理番号を設定するルート管理テーブルを保持する第１のメモリ部と、所定のプロキシサーバのアドレス情報を除くセッション情報、セッション制御に使用するインスタンス管理情報及び論理番号を保持する第２のメモリ部と、を備え、第２のメモリ部に保持する論理番号に基づき、第１のメモリ部に保持する所定のプロキシサーバのアドレス情報を読み出すものである。

この発明は、所定のプロキシサーバのアドレス情報を論理番号に対応付け、共通するプロキシサーバのアドレス情報について単一の論理番号を設定するルート管理テーブルを保持する第１のメモリ部と、所定のプロキシサーバのアドレス情報を除くセッション情報、セッション制御に使用するインスタンス管理情報及び論理番号を保持する第２のメモリ部と、を備え、第２のメモリ部に保持する論理番号に基づき、第１のメモリ部に保持する所定のプロキシサーバのアドレス情報を読み出すことにより、従来のＳＩＰサーバと比較して、セッション毎にＳＩＰサーバ内に保持するルートセット情報のメモリ量を削減することができる。

（本発明の第１の実施形態）
図１はこの発明を実施するための第１の実施形態におけるＳＩＰサーバのシステム構成を示すブロック図、図２（ａ）は図１に示すＳＩＰサーバの第１のメモリに保持されるルート管理テーブルの一例を示す説明図、図２（ｂ）は図１に示すＳＩＰサーバの第２のメモリ部に保持される経路情報の一例を示した説明図、図３（ａ）は図１に示すＳＩＰサーバによるルートセット情報の保持手順を説明するためのブロック図、図３（ｂ）は図１に示すＳＩＰサーバによるルートセット情報の復元手順を説明するためのブロック図である。

図１において、呼処理機能部１０は、自サーバ（ＳＩＰサーバ１００）に接続されているサーバ（以下、対向サーバと称す）との間でＳＩＰ信号の送受信を制御するＳＩＰ送受信部１１と、ＳＩＰ信号を受けて宛先の決定及びセッション状態の管理を行なうセッション制御部１２とからなる。

第１のメモリ部２０は、セッション毎にＳＩＰ信号で特定されるルートセット情報のうちレコードルートヘッダのアドレス情報を論理番号に対応付け、共通するレコードルートヘッダのアドレス情報について単一の論理番号を設定するルート管理テーブルを保持する。このルート管理テーブルは、例えば、図２（ａ）に示すように、論理番号とＩＰアドレスとを１対１で対応させたものである。また、論理番号は全部で１ｂｙｔｅ（０〜２５５値）程度の数値であり、発端末（ＵＡＣ）及び着端末（ＵＡＳ）間を経由するプロキシサーバのＩＰアドレス数以上の個数を有すればよい。なお、一般的には、最大３２個の論理番号があれば、発端末（ＵＡＣ）及び着端末（ＵＡＳ）間を経由するプロキシサーバのＩＰアドレス数に対応できるものである。

ここで、図７（ａ）に示すように、ＳＩＰサーバ１００を中心（自サーバ）として、プロキシサーバである、第１のプロキシサーバ１０１（Ｐｒｏｘｙ＃１（ＩＰアドレス”192.168.10.11”））、第２のプロキシサーバ１０２（Ｐｒｏｘｙ＃２（ＩＰアドレス”192.168.10.12”））、第３のプロキシサーバ１０３（Ｐｒｏｘｙ＃３（ＩＰアドレス”192.168.10.13”））、第４のプロキシサーバ１０４（Ｐｒｏｘｙ＃４（ＩＰアドレス”192.168.10.14”））又は第５のプロキシサーバ１０５（Ｐｒｏｘｙ＃５（ＩＰアドレス”192.168.10.15”））を経由して、加入者の端末（ＵＡ）である、第１の加入者端末２０１（ＵＡ＃１（ＩＰアドレス”192.168.1.100”））、第２の加入者端末２０２（ＵＡ＃２（ＩＰアドレス”192.168.1.101”））又は第３の加入者端末２０３（ＵＡ＃３（ＩＰアドレス”192.168.1.102”））間の電話通信を行なう場合を考える。

自サーバで３つのセッションが通信中である場合には、図２に示すように、セッション＃１、セッション＃２及びセッション＃３の各ルートセット情報のアドレス情報に対応する論理番号（数値）を、ＳＩＰサーバ１００の第１のメモリ部２０上のルート管理テーブルにて管理することとなる。なお、図２においては、ＩＰアドレス形式を一例として示しているが、ＤＮＳによってアドレス解決が可能なＦＱＤＮのアドレス形式の場合も同様に適用できる。

第２のメモリ部３０は、レコードルートヘッダのアドレス情報を除くルートセット情報（コンタクトヘッダのアドレス情報）及びその他のセッション制御に必要な情報であるセッション情報、セッション制御に使用するインスタンス管理情報、並びにレコードルートヘッダのアドレス情報に対応する論理番号を保持する。

なお、ルートセット情報のうちコンタクトヘッダのアドレス情報は、加入者の端末（ＵＡ）のアドレス情報であり、セッション毎に個別に管理する必要があるために、全セッションにおいて共通的に管理することができず、論理番号に対応付けることなく、文字列として第２のメモリ３０に保持している。

共通ルート管理部４０は、前述したルート管理テーブルに対してレコードルートヘッダのアドレス情報の設定及び読出しを行ない、セッション制御部１２及び第１のメモリ２０間における、レコードルートヘッダのアドレス情報の受け渡しを行なう。

つぎに、ＳＩＰサーバ１００によるルートセット情報の保持手順について、図３（ａ）を用いて説明する。
通常の稼動中であるＳＩＰサーバ１００は、ＳＩＰ信号によるセッション確立制御を行なうための呼処理機能部１０を用いてセッションの確立及び切断を実施する。

まず、呼処理機能部１０は、最初のＳＩＰ信号（以下、ｉｎｉｔｉａｌ−ＩＮＶＩＴＥと称す）をＳＩＰ送受信部１１で受信する（ステップ１：図３（ａ）の矢印１)と、ＳＩＰ信号を受信したことをセッション制御部１２に通知する（ステップ２：図３（ａ）の矢印２）。

つぎに、セッション制御部１２は、ｉｎｉｔｉａｌ−ＩＮＶＩＴＥの受信時に、これから確立しようとするＳＩＰセッションの状態管理などのセッション制御を行なうためのインスタンスを生成し、このインスタンスにて宛先分析などのセッション制御を行なう。

そして、セッション制御部１２は、このインスタンスの管理情報、ルートセット情報などのセッション制御に必要な情報であるセッション情報を、第２のメモリ部３０上に書込み保持する（ステップ３：図３（ａ）の矢印３）。

なお、生成されたインスタンス管理情報は、Ｃａｌｌ−ＩＤに対応してＳＩＰ送受信部１１に登録され、ＳＩＰ送受信部１１は、該当セッションにおける以降のＳＩＰ信号の受信時に、Ｃａｌｌ−ＩＤをＫｅｙ情報として一意にセッション制御部１２のインスタンスを特定することが可能である。

セッション制御部１２は、対向サーバの宛先が決定した後に、ＳＩＰ送受信部１１に対してＳＩＰ信号の送信要求を行ない（ステップ４：図３（ａ）の矢印４）、対向サーバの宛先にｉｎｉｔｉａｌ−ＩＮＶＩＴＥを送信する（ステップ５：図３（ａ）の矢印５）。

そして、ｉｎｉｔｉａｌ−ＩＮＶＩＴＥに対するレスポンス（１８３ＳｅｓｓｉｏｎＰｒｏｇｒｅｓｓ、１８０Ｒｉｎｇｉｎｇ若しくは２００ＯＫなど）又はＡＣＫが、ＳＩＰ送受信部１１で受信される（ステップ６：図３（ａ）の矢印６）と、呼処理機能部１０はＳＩＰ信号を受信したことをセッション制御部１２に通知する（ステップ７：図３（ａ）の矢印７）。

なお、セッション制御部１２は、該当セッションを制御するためにｉｎｉｔｉａｌ−ＩＮＶＩＴＥの受信時に生成したインスタンスによって、継続してレスポンスやＡＣＫの制御を行なう。

セッション制御部１２は、ＳＩＰ信号上のルートセット情報であるレコードルートヘッダ及びコンタクトヘッダを読み出して、コンタクトヘッダのアドレス情報を第２のメモリ部３０に書込み格納する（ステップ８：図３（ａ）の矢印８）。

また、セッション制御部１２は、共通ルート管理部４０にレコードルートヘッダのアドレス情報の設定要求を行ない（ステップ９：図３（ａ）の矢印９）、共通ルート管理部４０によって第１のメモリ部２０にレコードルートヘッダのアドレス情報の設定を行なう（ステップ１０：図３（ａ）の矢印１０）。

ここで、共通ルート管理部４０は、セッション制御部１２から送信されたレコードルートヘッダのアドレス情報が、第１のメモリ部２０に設定されているか否かを判断する。そして、第１のメモリ部２０に未設定のレコードルートヘッダのアドレス情報である場合には、共通ルート管理部４０は、第１のメモリ部２０の空きエリアにレコードルートヘッダのアドレス情報を格納し、該当エリアのＩｎｄｅｘ値を論理番号としてセッション制御部１２に返却する（ステップ１１ａ：図３（ａ）の矢印１１）。また、既に設定済みの
レコードルートヘッダのアドレスである場合には、共通ルート管理部４０は、該当エリアに格納されている対応するＩｎｄｅｘ値を論理番号としてセッション制御部１２に返却する（ステップ１１ｂ：図３（ａ）の矢印１１）。
セッション制御部１２は、返却された論理番号をルートセット情報として第２のメモリ部３０に書込み保持する（ステップ１２：図３（ａ）の矢印１２）。

なお、該当セッションを制御するインスタンスなどのメモリ情報は、該当セッションの通信状態が切断されるまでの間は、第２のメモリ部３０上に保持される。
また、第１のメモリ部２０は、セッション毎の初期化は行なわず、蓄積されたレコードルートヘッダのアドレス情報をＩＰテレフォニーの運用中は使用し続ける。ただし、システム障害時の波及度に応じた再開フェーズを適用してもＩＰテレフォニーを復旧できない場合には、ＳＩＰサーバ１００を再開する初期設定時に共通ルート管理部４０によって第１のメモリ部２０の初期化を行なう。

また、この第１の実施形態においては、レコードルートヘッダのアドレス情報に対応する論理番号を割り当てる場合に、共通ルート管理部４０がセッション制御部１２からレコードルートヘッダのアドレス情報の設定要求を受ける度に、共通ルート管理部４０が論理番号を順次割り当てているのだが、レコードルートヘッダの対象となる加入者端末間を経由するプロキシサーバのアドレス情報を予め特定できるのであれば、第１のメモリ部２０に特定した所定のプロキシサーバのアドレス情報と論理番号とを対応付けたルート管理テーブルを予め格納しておいてもよい。

この場合には、前述したステップ９を、セッション制御部１２は、共通ルート管理部４０に、レコードルートヘッダのアドレス情報に対応する論理番号の読出し要求を行なうステップに変更することとなる。また、前述したステップ１０を、共通ルート管理部４０によって第１のメモリ部２０にレコードルートヘッダのアドレス情報に対応する論理番号の読出しを行なうステップに変更することとなる。

また、この第１の実施形態においては、全セッションにおける全てのレコードルートヘッダのアドレス情報を論理番号に対応させ、レコードルートヘッダのアドレス情報及び論理番号を第１のメモリ部２０及び第２のメモリ部３０にそれぞれ保持していたが、第２のメモリ部２０で許容できるメモリ量（経由するサーバ台数）に達するまでは、第２のメモリ部２０にレコードルートヘッダのアドレス情報を文字列で保持して従来のＳＩＰサーバと同様にＳＩＰサーバ１００を稼動させておき、第２のメモリ部２０で許容できるメモリ量（経由するサーバ台数）を超えたときに、共通ルート管理部４０を稼動させ、レコードルートヘッダのアドレス情報及び論理番号を第１のメモリ部２０及び第２のメモリ部３０にそれぞれ保持して前述したＳＩＰサーバ１００と同様に稼動するように、セッション制御部１２で制御してもよい。

つぎに、ＳＩＰサーバ１００によるルートセット情報の復元手順について、図３（ｂ）を用いて説明する。
まず、セッション制御部１２は、第２のメモリ部３０に保持している該当セッションにおけるルートセット情報の論理番号を参照する（ステップ１０１：図３（ｂ）の矢印１）、
そして、セッション制御部１２は、参照した論理番号に基づき、論理番号に対応するレコードルートヘッダのアドレス情報の読出し要求を共通ルート管理部４０に対して行なう（ステップ１０２：図３（ｂ）の矢印２）。

つぎに、共通ルート管理部４０は、参照した論理番号をＩｎｄｅｘとして、第１のメモリ部２０の該当エリアに格納されているレコードルートヘッダのアドレス情報を読出し（ステップ１０３：図３（ｂ）の矢印３）、このレコードルートヘッダのアドレス情報をセッション制御部１２に返却する（ステップ１０４：図３（ｂ）の矢印４）。

そして、セッション制御部１２は、返却されたレコードルートヘッダのアドレス情報及び第２のメモリ３０に保持させるメモリ情報を使用して、該当セッションの通信を切断するなどのそれぞれの処理に対するＳＩＰ信号を作成する。

つぎに、セッション制御部１２は、ＳＩＰ送受信部１１に対してＳＩＰ信号の送信要求を行ない（ステップ１０５：図３（ｂ）の矢印５）、対向サーバの宛先にＳＩＰ信号を送信する（ステップ１０６：図３（ｂ）の矢印６）ことで、該当セッションのそれぞれの処理を行なうことができる。

以上のように、この発明の第１の実施形態におけるＳＩＰサーバ１００は、各セッションの経路情報を全セッションで共通的に管理する共通ルート管理部４０を配置し、各セッションにおいてｉｎｉｔｉａｌ-ＩＮＶＩＴＥのレスポンス受信時に経路（レコードルート及びコンタクト）が確定すると、共通ルート管理部４０に経路情報（レコードルートヘッダ）を通知し、共通ルート管理部４０は各レコードルートヘッダのアドレス情報に対し論理番号を付与して返却することにより、ＳＩＰサーバ１００側で保持するルートセット情報をセッション毎に第２のメモリ部３０に文字列で保持することなく、セッション毎に各レコードルートヘッダのアドレス情報に付与された論理番号（数値）を保持するだけでよく、セッション毎にルートセット管理用に使用するルートセット情報の保持メモリ量を削減できる。

特に、ルートセットはセッション毎に確立するものではあるが、同一のネットワーク内で各々のセッション設定のために通過する経路（レコードルートされるサーバ）は、同一の経路（ＳＩＰサーバ１００）を通ることが大半であると考えられ、各セッションの経路情報を全セッションで共通的に管理することは、複数のセッションにおいて同一のサーバが重複して経路に入る場合に、該当サーバのアドレス情報をＳＩＰサーバ１００内で１つ保持すればよく、メモリ量の削減に有効である。

（本発明の第２の実施形態）
図４はこの発明を実施するための第２の実施形態におけるＳＩＰサーバのシステム構成を示すブロック図、図５は図４に示すＳＩＰサーバによるルートセット情報の系間転送手順を説明するためのブロック図である。図４および図５において、図１〜図３と同じ符号は、同一または相当部分を示し、その説明を省略する。

ＳＩＰサーバ１００は、ＡＣＴ系ＳＩＰサーバ１００ａとＳＢＹ系ＳＩＰサーバ１００ｂとをＬＡＮ（local area network）６０を介して情報を送受信させる構成の冗長構成サーバ（ＡＣＴ／ＳＢＹ）である。

第３のメモリ部２０ｂは、第１のメモリ部２０ａに保持する前述したルート管理テーブルと同一のデータ構造からなるルート管理テーブルを保持する記憶手段である。

第４のメモリ部３０ｂは、第２のメモリ部３０ａに保持する前述したセッション情報、インスタンス管理情報及び論理番号と同一のデータ構造からなるセッション情報、インスタンス管理情報及び論理番号を保持する記憶手段である。

系間転送処理部５０は、セッション制御部１２からのメモリ転送要求に基づき、第１のメモリ２０ａに保持するルート管理テーブルを第３のメモリ部２０ｂに転送し書込み、第２のメモリ部３０ａに保持するセッション情報、インスタンス管理情報及び論理番号を第４のメモリ部３０ｂに転送し書込む転送処理手段である。

なお、この第２の実施形態におけるＳＩＰサーバにおいては、ＳＩＰサーバ１００が冗長構成サーバ（ＡＣＴ／ＳＢＹ）であるところのみが第１の実施形態と異なるところであり、後述する第３のメモリ部２０ｂ、第４のメモリ部３０ｂ及び系間転送処理部５０による作用効果以外は、第１の実施形態と同様の作用効果を奏する。

ＡＣＴ系ＳＩＰサーバ１００ａに故障が発生し、ＩＰテレフォニーを運用するＳＩＰサーバ１００が、ＡＣＴ系ＳＩＰサーバ１００ａからＳＢＹ系ＳＩＰサーバ１００ｂに切り替わった場合に、新たなＡＣＴ系ＳＩＰサーバとなるＳＢＹ系ＳＩＰサーバ１００ｂによってセッション救済を行なう必要がある。このため、系間転送処理部５０は、ＡＣＴ系ＳＩＰサーバ１００ａに故障が発生する前に、ＡＣＴ系ＳＩＰサーバ１００ａからＳＢＹ系ＳＩＰサーバ１００ｂに対してセッション救済に必要となるメモリ内容を転送する。

ここで、ＳＩＰサーバ１００によるルートセット情報の系間転送手順について、図５を用いて説明する。

まず、第１のメモリ部２０ａ及び第２のメモリ部３０ｂに前述した所定の情報をそれぞれ格納した状態において、セッション制御部１２は、第１のメモリ部２０ａに保持されたルート管理テーブルと、第２のメモリ部２０ｂに保持されたレコードルートヘッダのアドレス情報を除くルートセット情報及びその他のセッション制御に必要な情報であるセッション情報、セッション制御に使用するインスタンス管理情報、並びにレコードルートヘッダのアドレス情報に対応する論理番号とを、ＳＢＹ系ＳＩＰサーバ１００ｂに転送するために、系間転送処理部５０に対して転送指示を行なう（ステップ２０１：図５の矢印１）。

系間転送処理部５０は、第１のメモリ部２０ａからルート管理テーブルを参照（ステップ２０２：図５の矢印２）したうえで、ＳＢＹ系ＳＩＰサーバ１００ｂに転送し、第３のメモリ部２０ｂに書込む（ステップ２０３：図５の矢印３）。また、系間転送処理部５０は、第２のメモリ部２０ｂからレコードルートヘッダのアドレス情報を除くルートセット情報及びその他のセッション制御に必要な情報であるセッション情報、セッション制御に使用するインスタンス管理情報、並びにレコードルートヘッダのアドレス情報に対応する論理番号を参照（ステップ２０４：図５の矢印４）したうえで、ＳＢＹ系ＳＩＰサーバ１００ｂに転送し、第４のメモリ部３０ｂに書込む（ステップ２０５：図５の矢印５）。

なお、系間転送処理部５０は、ＳＩＰサーバ１００で制御している全てのセッションにおいてメモリ転送指示を受け、指示されたメモリ領域をＳＢＹ系ＳＩＰサーバ１００ｂに転送し、ＳＢＹ系ＳＩＰサーバ１００ｂにおける対応する第１のメモリ部３０ａ又は第４のメモリ部３０ｂ上に書込む転送処理を行なう。

また、第１のメモリ部２０ａのルート管理テーブルに設定されていない、新規に設定されるレコードルートヘッダのアドレス情報が発生した場合（新規のアドレス情報に対応する論理番号が付与された場合）には、共通ルート管理部４０は、系間転送処理部５０にメモリ転送要求を行なう（ステップ２０６：図５の矢印６）。

そして、系間転送処理部５０は、第１のメモリ部２０ａから新規のアドレス情報及びそれに対応する新規の論理番号を参照（ステップ２０７：図５の矢印７）したうえで、ＳＢＹ系ＳＩＰサーバ１００ｂに転送し、第３のメモリ部２０ｂに書込む（ステップ２０８：図５の矢印８）。また、系間転送処理部５０は、新規の論理番号を参照（ステップ２０９：図５の矢印９）したうえで、ＳＢＹ系ＳＩＰサーバ１００ｂに転送し、第４のメモリ部３０ｂに書込む（ステップ２１０：図５の矢印１０）。
以上のように、本発明のＳＩＰサーバ１００の構成を冗長構成サーバに適用した場合であっても、冗長構成サーバの系間のメモリ転送量を削減でき、系間のメモリ転送を要因としたサーバの輻輳が生じることを抑制することができる。

つぎに、本発明のＳＩＰサーバ１００を導入したネットワークにおけるルートセット情報を保持するために必要なＳＩＰサーバ１００のメモリ量と、従来のＳＩＰサーバを導入したネットワークにおけるルートセット情報を保持するために必要な従来のＳＩＰサーバのメモリ量とを比較する。

まず、従来のＳＩＰサーバに必要なメモリ量であるが、前述した背景技術で示したように、計算値は、（２５６ｂｙｔｅ×２＋２５６ｂｙｔｅ×４）×１００，０００セッション≒１５４Ｍｂｙｔｅの計１５４Ｍｂｙｔｅのメモリが必要となる。

これに対して、本発明のＳＩＰサーバ１００においては、１０万セッションの同時接続を許容するＳＩＰサーバ１００において、１セッションに４つのレコードルートヘッダを使用し、１アドレスのサイズが一般的な２５６ｂｙｔｅであると仮定する。また、経路となるサーバがネットワーク内に最大で３２台存在し得ると仮定する。この場合には、ＳＩＰサーバ１００全体でルートセット情報の管理に必要となるメモリ量は、（コンタクトヘッダ×２＋レコードルートヘッダ（論理番号）×４）×最大同時接続数＋（共通ルート管理部４０で使用するサイズ（１台のサーバに使用するサイズ×サーバ台数））であり、計算値は、（２５６ｂｙｔｅ×２＋1ｂｙｔｅ×４）×１００，０００セッション＋（２５６ｂｙｔｅ×３２台）≒５２Ｍｂｙｔｅの計５２Ｍｂｙｔｅのメモリが必要となる。
したがって、従来のＳＩＰサーバと比較して、約１００Ｍｂｙｔｅのメモリの使用量を削減できることがわかる。

また、例えば、１００万ＢＨＣＡ（Busy Hour Call Attempts：電話網が最も混雑する時間帯（busy hour）におけるセッション呼び出し（call）の回数の総量）を実現するＳＩＰサーバ１００の場合には、１時間で１Ｇｂｙｔｅ分の系間転送量を削減することが可能となり、ＳＩＰサーバ１００内にルートセット情報を保持することによる性能劣化となる要因を軽減することが可能となる。

上記実施形態に関し、更に以下の付記を開示する。
（付記１）複数のプロキシサーバを経由するＩＰネットワーク上でマルチメディアセッションを開始／変更／終了するためのセッション開始プロトコルによってルートセット情報が特定され、共通するプロキシサーバのアドレス情報を含む複数のルートセット情報を保持するＳＩＰサーバにおいて、所定のプロキシサーバのアドレス情報を論理番号に対応付け、前記共通するプロキシサーバのアドレス情報について単一の論理番号を設定するルート管理テーブルを保持する第１のメモリ部と、前記所定のプロキシサーバのアドレス情報を除くセッション情報、セッション制御に使用するインスタンス管理情報及び前記論理番号を保持する第２のメモリ部と、を備え、前記第２のメモリ部に保持する前記論理番号に基づき、前記第１のメモリ部に保持する前記所定のプロキシサーバのアドレス情報を読み出すことを特徴とするＳＩＰサーバ。

（付記２）前記請求項１に記載のＳＩＰサーバにおいて、前記所定のプロキシサーバのアドレス情報は、セッション毎にＳＩＰ信号で特定されるルートセット情報のうちレコードルートヘッダのアドレス情報であることを特徴とするＳＩＰサーバ。

（付記３）前記請求項１又は２に記載のＳＩＰサーバにおいて、ＳＩＰ信号に基づき宛先の決定及びセッション状態の管理を行なうセッション制御部と、前記ルート管理テーブルに対して前記アドレス情報の設定及び読出しを行ない、前記セッション制御部及び第１のメモリ部間における、前記アドレス情報の受け渡しを行なう共通ルート管理部と、を備えていることを特徴とするＳＩＰサーバ。

（付記４）前記請求項１乃至３のいずれかに記載のＳＩＰサーバにおいて、前記第１のメモリ部に保持する前記ルート管理テーブルと同一のデータ構造からなるルート管理テーブルを保持する第３のメモリ部と、前記第２のメモリ部に保持する前記セッション情報、インスタンス管理情報及び論理番号と同一のデータ構造からなるセッション情報、インスタンス管理情報及び論理番号を保持する第４のメモリ部と、前記セッション制御部からのメモリ転送要求に基づき、前記第１のメモリ部に保持する前記ルート管理テーブルを第３のメモリ部に転送し書込み、前記第２のメモリ部に保持するセッション情報、インスタンス管理情報及び論理番号を前記第４のメモリ部に転送し書込む系間転送処理部と、を備えていることを特徴とするＳＩＰサーバ。

この発明を実施するための第１の実施形態におけるＳＩＰサーバのシステム構成を示すブロック図である。（ａ）は図１に示すＳＩＰサーバの第１のメモリに保持されるルート管理テーブルの一例を示す説明図、（ｂ）は図１に示すＳＩＰサーバの第２のメモリ部に保持される経路情報の一例を示した説明図である。（ａ）は図１に示すＳＩＰサーバによるルートセット情報の保持手順を説明するためのブロック図、（ｂ）は図１に示すＳＩＰサーバによるルートセット情報の復元手順を説明するためのブロック図である。この発明を実施するための第２の実施形態におけるＳＩＰサーバのシステム構成を示すブロック図である。図４に示すＳＩＰサーバによるルートセット情報の系間転送手順を説明するためのブロック図である。ＲＦＣ３２６１に準拠した経路制御情報を説明するためのメッセージシーケンスの一例を示すシーケンス図である。（ａ）はＳＩＰサーバ内に経路情報を保持する場合を説明するための説明図、（ｂ）は（ａ）に示す自サーバ内に保持される経路情報の一例を示した説明図である。

符号の説明

１０呼処理機能部
１１ＳＩＰ送受信部
１２セッション制御部
２０，２０ａ第１のメモリ部
２０ｂ第３のメモリ部
３０，３０ａ第２のメモリ部
３０ｂ第４のメモリ部
３０第２のメモリ部
４０共通ルート管理部
５０系間転送処理部
６０ＬＡＮ
１００ＳＩＰサーバ
１００ａＡＣＴ系ＳＩＰサーバ
１００ｂＳＢＹ系ＳＩＰサーバ
１０１第１のプロキシサーバ
１０２第２のプロキシサーバ
１０３第３のプロキシサーバ
１０４第４のプロキシサーバ
１０５第５のプロキシサーバ
２０１第１の加入者端末
２０２第２の加入者端末
２０３第３の加入者端末

Claims

複数のプロキシサーバを経由するＩＰネットワーク上でマルチメディアセッションを開始／変更／終了するためのセッション開始プロトコルによってルートセット情報が特定され、共通するプロキシサーバのアドレス情報を含む複数のルートセット情報を保持するＳＩＰサーバにおいて、
所定のプロキシサーバのアドレス情報を論理番号に対応付け、前記共通するプロキシサーバのアドレス情報について単一の論理番号を設定するルート管理テーブルを保持する第１のメモリ部と、
前記所定のプロキシサーバのアドレス情報を除くセッション情報、セッション制御に使用するインスタンス管理情報及び前記論理番号を保持する第２のメモリ部と、を備え、
前記第２のメモリ部に保持する前記論理番号に基づき、前記第１のメモリ部に保持する前記所定のプロキシサーバのアドレス情報を読み出すことを特徴とするＳＩＰサーバ。
前記請求項１に記載のＳＩＰサーバにおいて、
前記所定のプロキシサーバのアドレス情報は、セッション毎にＳＩＰ信号で特定されるルートセット情報のうちレコードルートヘッダのアドレス情報であることを特徴とするＳＩＰサーバ。
前記請求項１又は２に記載のＳＩＰサーバにおいて、
ＳＩＰ信号に基づき宛先の決定及びセッション状態の管理を行なうセッション制御部と、
前記ルート管理テーブルに対して前記アドレス情報の設定及び読出しを行ない、前記セッション制御部及び第１のメモリ部間における、前記アドレス情報の受け渡しを行なう共通ルート管理部と、
を備えていることを特徴とするＳＩＰサーバ
前記請求項１乃至３のいずれかに記載のＳＩＰサーバにおいて、
前記第１のメモリ部に保持する前記ルート管理テーブルと同一のデータ構造からなるルート管理テーブルを保持する第３のメモリ部と、
前記第２のメモリ部に保持する前記セッション情報、インスタンス管理情報及び論理番号と同一のデータ構造からなるセッション情報、インスタンス管理情報及び論理番号を保持する第４のメモリ部と、
前記セッション制御部からのメモリ転送要求に基づき、前記第１のメモリ部に保持する前記ルート管理テーブルを第３のメモリ部に転送し書込み、前記第２のメモリ部に保持するセッション情報、インスタンス管理情報及び論理番号を前記第４のメモリ部に転送し書込む系間転送処理部と、
を備えていることを特徴とするＳＩＰサーバ。