JP4813881B2 - Ｓｉｐサーバ - Google Patents

Description

本発明は、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を実装したＳＩＰサーバに関し、特にＳＩＰサーバのアドレス解決としての、ＳＩＰリクエストメッセージ中のＲｅｑｕｅｓｔ−ＵＲＩより宛先を決定するＳＩＰサーバに関する。

従来、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）の標準であるＲＦＣ３２６１によるとＳＩＰサーバ（ＲＦＣ３２６１中ではＰｒｏｘｙ）が、ＳＩＰサーバ側の登録内容から宛先を決定しアドレス解決する場合には、Ｒｅｑｕｅｓｔ−ＵＲＩを索引として検索することが推奨されている（ＲＦＣ３２６１の１０．３章、１６章）ものの、プロトコルとして明確な拠点番号でのアドレス解決方法は何ら規定されていなかった。

また、従来ＳＩＰサーバへＳＩＰゲートウェイを登録してＳＩＰゲートウェイ配下のＰＢＸ内線や複数の内線電話器を使用する際には、予めこれら全ての内線電話機の番号をＳＩＰサーバへ登録しておくか、あるいは、拠点番号を着番号の接頭番号として、ＳＩＰプロトコルでの登録方法（ＳＩＰ端末やＳＩＰゲートウェイから行なうＲＥＧＩＳＴＥＲ）とは別に、ＳＩＰサーバ側で予めＳＩＰ−ＵＲＩのユーザ部分とその拠点番号を関連付けすることで、Ｒｅｑｕｅｓｔ−ＵＲＩより宛先を決定するアドレス解決の為の設定を行なっていた。これは一般的にＵＲＩのユーザの部分は個人を示す管理情報であること、また、ＲＦＣ３２６１にて２つのＵＲＩの比較一致条件としてユーザ、ホスト（ポート）が一致しなければならないこと（１９．１．４章）が明記されており、着番号の比較として適用されていることが起因している。

また、ＲＦＣ２３９６において、ＳＩＰ−ＵＲＩ中にも適用されているＵＲＩの構文に関しては、階層を示す場合は「／」等を区切りとして用いることが明記されているが、電話番号の発信時の入力方法としては、このような区切り文字の入力が煩わしく、また、これまでの用途に無かったことから馴染まない為、実際には用いられていなかった。

ＲＦＣ３２６１「Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」 ＲＦＣ２３９６「Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ （ＵＲＩ）： Ｇｅｎｅｒｉｃ Ｓｙｎｔａｘ」

前記背景技術で説明した既存のＳＩＰサーバにおいては、ＳＩＰサーバにＳＩＰゲートウェイを登録し、このＳＩＰゲートウェイ配下のＰＢＸ内線や複数の内線電話器を使用する際には、全ての内線電話機に割り当てられた全桁数の番号をＳＩＰサーバに事前に全て登録しておくか、事前に各内線電話器に対応したＵＲＩのユーザ部分と、内線電話器を収容する拠点の拠点番号を関連付けして設定しておく必要があり、内線電話器の数が多い場合には、その設定登録作業に多くの時間を費やしてしまっていた。

本発明は上記課題に鑑みてなされたものであり、電話器やＳＩＰ端末などに割り当てられた番号登録の簡略化を図るため、拠点に収容する電話器やＳＩＰ端末などのユーザ登録を個々に行わずに、例えば、拠点などを新設してもこれらの配下に有する複数の端末の通信設定を拠点番号を利用して簡単に行うことが可能なＳＩＰサーバを提供することを目的とする。

請求項１に係るＳＩＰサーバは、ＳＩＰ端末からの発信要求に応じてＳＩＰプロトコルで呼制御を行う呼制御手段と、ＳＩＰ端末からのＳＩＰメッセージを受信する受信手段と、ＳＩＰメッセージを作成しＳＩＰ端末へ送信する送信手段と、ＳＩＰ端末から受信したリクエストメッセージのＲｅｑｕｅｓｔ−ＵＲＩから宛先を決定するアドレス解決手段とを有するＳＩＰサーバにおいて、
ＳＩＰ端末の電話番号の先頭の一部分と当該ＳＩＰ端末のアドレスとを対応付けて記憶する記憶手段を有し、
前記アドレス解決手段は、リクエストメッセージのＲｅｑｕｅｓｔ−ＵＲＩのユーザ部分に含まれる、着信側ＳＩＰ端末の電話番号の先頭の一部分が、前記記憶手段に記憶されている電話番号の先頭の一部分と一致する場合、当該電話番号の先頭の一部分に対応して記憶されているアドレスを着信側ＳＩＰ端末のアドレスとして取得することを特徴とする。

請求項２に係るＳＩＰサーバは、請求項１記載のＳＩＰサーバにおいて、前記受信手段は、ＴｏヘッダもしくはＣｏｎｔａｃｔヘッダの少なくともいずれかのユーザ部分に着信側ＳＩＰ端末の電話番号の先頭の一部分が設定されたＲＥＧＩＳＴＥＲメッセージを着信側ＳＩＰ端末から受信し、前記記憶手段は、ＲＥＧＩＳＴＥＲメッセージに含まれる電話番号の先頭の一部分を、着信側ＳＩＰ端末のアドレスと対応付けて記憶することを特徴とする。

請求項３に係るＳＩＰサーバは、請求項１記載のＳＩＰサーバにおいて、前記アドレス解決手段は、Ｒｅｑｕｅｓｔ−ＵＲＩのユーザ部分に含まれる電話番号の先頭の一部分が、前記記憶手段に複数記憶されている場合、当該複数の中で最も桁数の多い電話番号の先頭の一部分を選択し、当該選択した電話番号の先頭の一部分に対応して記憶されているアドレスを取得することを特徴とする。

請求項４に係るＳＩＰサーバは、請求項１または２記載のＳＩＰサーバにおいて、前記送信手段は、前記アドレス解決手段が複数のアドレスを取得した場合、ＲＦＣ３２６１によるシーケンシャルサーチまたはパラレルサーチにより、前記複数のアドレスにリクエストメッセージを送出することを特徴とする。

請求項５に係るＳＩＰサーバは、請求項４記載のＳＩＰサーバにおいて、ＲＥＧＩＳＴＥＲメッセージに含まれるＣｏｎｔａｃｔヘッダのｑ値指定に基づき、シーケンシャルサーチまたはパラレルサーチを行なうことを特徴とする。

本発明に係るＳＩＰサーバによれば、電話器やＳＩＰ端末などに割り当てられた番号登録の簡略化を図り、拠点に収容する電話器やＳＩＰ端末などのユーザ登録を個々に行わずに、これら電話器などの番号登録の簡略化を可能とし、例えば、拠点などを新設してもこれらの配下に有する複数の端末の通信設定を簡単に行うことができる。また、アドレス解決の際に所定桁数において前方一致する番号が複数存在した場合でも、より長い桁数で一致した番号を採用するため、登録する番号桁数を揃える必要がなくなり、先頭の値の一致する拠点番号が複数あった場合でも、番号登録の簡略化が可能である。例えば、ある拠点は接頭番号２１〜２９にて着信させ、他方の拠点は接頭番号２０で着信させたい場合に、前者拠点のＳＩＰ端末は番号２で登録し、他方の拠点のＳＩＰ端末は番号２０と登録すれば良い。また、新設拠点であるＳＩＰ端末の登録において、ＳＩＰサーバ側を設定変更することなく、ＳＩＰ端末側のみの設定で容易に行うことが可能である。更に、ＳＩＰサーバにて同一番号の登録を許容するため、同一拠点番号にて複数のＳＩＰ端末の登録が可能となり、ＳＩＰサーバは同一番号にて複数宛先（複数のＳＩＰ端末）が存在する場合は、シーケンシャルサーチ又はパラレルサーチを実施することで、複数ＳＩＰ端末の回線を有効に利用することが可能となる。更に、ＲＥＧＩＳＴＥＲのＣｏｎｔａｃｔヘッダのｑ値に基づき、シーケンシャルサーチ又はパラレルサーチを行えるので、ＳＩＰサーバへの設定は不要となり、ＳＩＰ端末のみの設定でサービスの運用を行うことが可能となる。

以下、本発明を実施するための最良の形態としての実施例を図１から図１６を参照して説明する。もちろん、本発明は、その発明の趣旨に反さない範囲で、実施例において説明した以外のものに対しても容易に適用可能なことは説明を要するまでもない。

本実施例のＳＩＰネットワークシステムについて以下に説明する。ＳＩＰネットワークシステム１には、ＳＩＰサービスを提供するＳＩＰサーバ１１が構成されており、このＳＩＰサーバ１１と後述する各拠点などに配置された電話器とは、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）網１６を介して接続されている。なお、後述するＳＩＰゲートウェイやＳＩＰ電話器等のＳＩＰプロトコルを実装した端末をＳＩＰ端末と定義して説明する。

ＳＩＰサーバ１１は、ＲＦＣ３２６１のＰｒｏｘｙサーバ、およびＲＥＧＩＳＴＥＲサーバとしても機能するものであり。これらが一体化したものとして説明するが、ＲＦＣ３２６１に示されているように物理的には２つのサーバ、またはロケーションサービスによる実装を行なっても良いことは言うまでもない。

図１に示すようにＳＩＰサーバ１１は、ＩＰ−ＶＰＮ網１６や各拠点に配置されたＳＩＰゲートウェイを介してＳＩＰゲートウェイ１２１，１２２１，１２２２，１２２３，１２３，１２４やＳＩＰ電話器１５１，１５２が接続されている。なお、こうしたＳＩＰ端末としてのＳＩＰゲートウェイやＳＩＰ電話器１５１，１５２は、従来から用いられている一般的なＳＩＰ端末とほぼ同じであり、本実施例におけるＳＩＰ端末とは、ＲＥＧＩＳＴＥＲメッセージによって電話番号の登録、および発信時にＩＮＶＩＴＥメッセージにより着番号（発信時の相手番号）を、Ｒｅｑｕｅｓｔ−ＵＲＩのユーザを特定するためのユーザ部分を用いて行なう端末を示すものであり、ＲＥＧＩＳＴＥＲメッセージとＩＮＶＩＴＥメッセージの詳細については後述する。

第１の拠点１０内に配置されたＳＩＰゲートウェイ１２１は、音声側にＦＸＳ（Ｆｏｒｅｉｇｎ Ｅｘｃｈａｎｇｅ Ｓｔａｔｉｏｎ）インタフェースを持つゲートウェイ装置であり、ＦＸＳインタフェースを介して電話器１３１１，１３１２が接続されおり、拠点番号を「１０」として割り当て、ＳＩＰサーバ１１へは拠点番号の「１０」と対応してユーザを「１０」として登録する。

第２の拠点２０内に配置されたＳＩＰゲートウェイ１２２１，１２２２，１２２３は、音声側にＯＤインタフェースを持つゲートウェイ装置であり、ＯＤインタフェースを介してＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ）１４が接続されおり、拠点番号を「２０」として割り当て、ＳＩＰサーバ１１へは拠点番号の「２０」と対応してユーザを「２０」として登録する。なお、ＰＢＸ１４には電話器１３２１，１３２２，１３２３が接続されている。

第３の拠点３０内に配置されたＳＩＰ電話器１５１，１５２は、前述したようにＳＩＰプロトコルを実装したものであり、これら２台のＳＩＰ電話器１５１，１５２の両者には、拠点番号として「３０」を割り当てているが、ここではＳＩＰサーバ１１へは内線番号を含めた全桁番号、すなわち前者は「３０１０００１」、後者は「３０１０００２」としてユーザを登録する。

第１の領域４０内配置されたＳＩＰゲートウェイ１２３は、音声側にＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋｓ）電話網１７へ接続するために、Ｉインタフェース（ＩＳＤＮへの接続インタフェース）を持つゲートウェイ装置であり、ＳＩＰゲートウェイ１２３は、前述した内線電話器として機能する電話器１３１１，１３１２，１３２１，１３２２，１３２３，ＳＩＰ電話器１５１，１５２のそれぞれとＰＳＴＮ電話網１７との発着信を可能とするものである。なお、より詳細には、ＰＳＴＮ電話網１７に接続された電話器１３３１との通話等など、第１の領域４０内のＳＩＰゲートウェイ１２３は、ＰＳＴＮ電話網１７の電話番号（の市外局番）が「０」から始まることから、「０」を接頭番号とし、ＳＩＰサーバ１１へはユーザを「０」として登録する。

第２の領域５０内のＳＩＰゲートウェイ１２４は、音声側インタフェースは持たずＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）電話網１９へ接続する為のプロトコル変換装置であり、拠点１０，２０，３０のそれぞれに配置された各電話器１３１１，１３１２、１３２１，１３２２，１３２３、１５１，１５２とＩＰ電話網１９との発着信を可能にするものであり、より詳細には、ＩＰ電話網１９に接続されたＩＰ電話器１８１との通話など、第２の領域５０内のＳＩＰゲートウェイ１２４は、ＩＰ電話網１９の電話番号が「０５０」から始まるため、「０５０」を接頭番号とし、ＳＩＰサーバ１１へはユーザを「０５０」として登録する。

図２はＳＩＰサーバの概略構成を示すブロック図である。同図に示すように、ＳＩＰサーバ１１には、ＲＡＭやＨＤＤなどの記憶装置２２１を備え、この記憶装置２２１に各種データ情報２２１１〜２２１５が論理的に配置され、これらの情報に基づき中央処理装置２１が制御を行う。また、ＳＩＰサーバ１１とＳＩＰゲートウェイ１２１，１２２１〜１２２３，１２３，１２４やＳＩＰ電話器１５１，１５２との通信は、ネットワークインタフェース２３により、ＩＰ−ＶＰＮ網１６へ通じるイーサネット（登録商標）回線２４により接続され行なわれるようになっており、構成情報２２１１は、ＳＩＰサーバ１１を動作させる為に必要な装置の動作モード等の情報である。

２２１６は、ＳＩＰサーバ１１上でＳＩＰサービスを展開するためのＳＩＰサーバアプリケーションであるプログラムである。プログラム２２１６は、ＳＩＰサービスの呼制御を行う呼制御手段２２１６ａと、プログラム２２１６からＳＩＰ端末へＳＩＰメッセージを送信するための送信手段２２１６ｂと、ＳＩＰ端末等から送信されるＳＩＰメッセージを受信するための受信手段２２１６ｃと、受信したＳＩＰメッセージを解読する解読手段２２１６ｄから構成される。プログラム２２１６は、中央処理装置２１により記憶装置２２１が備える各情報を用いてＳＩＰサーバの動作制御を行う。送受信バッファ２５は、図示しない、ネットワークインタフェース用のＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。受信バッファ２５１は、ネットワークインタフェース２３を通じてＳＩＰ端末が発信したメッセージが格納され、受信手段２２１６ｃを通じてプログラム２２１６により処理が行われる。送信バッファ２５２には、プログラム２２１６により作成されたメッセージが送信手段２２１６ｂを通じて格納され、ネットワークインタフェース２３を通じてイーサネット（登録商標）回線２４に送出される。

以上の構成により、プログラム２２１６は、受信バッファ２５１内に格納されるＳＩＰ端末から受信した受信メッセージ２５１１を受信手段２１１６ｃにより読み取り、解読手段２１１６ｄにより受信メッセージ２５１１の解読を行い、解読した結果の応答や宛先へのメッセージの作成や転送等の必要に応じた呼制御を呼制御手段２２１６ａにより行い、呼制御手段２２１６ａにより作成又は転送指示されるメッセージを送信手段２２１６ｂにより送信メッセージ２５２１として送信バッファ２５２に格納し、ネットワークインタフェース２３及びイーサネット（登録商標）回線を通じて、送信先宛先となるＳＩＰ端末へ送信するという一連のＳＩＰサービスを展開することができる。

また、データ情報としてのＳＩＰトランザクション情報２２１２は、ＲＦＣ３２６１によるステートフルプロキシとしてＳＩＰメッセージの送受信を行なう為に必要な情報であり、ＳＩＰ呼情報２２１５はＳＩＰの呼管理情報（ＲＦＣ３２６１によるダイアログ情報）と呼開始時に確立されたルート情報とであり、呼開始であるＩＮＶＩＴＥから、ＢＹＥやエラー応答等による呼切断まで保持する。フォーキング情報２２１４は、ＳＩＰ端末たるＳＩＰゲートウェイ１２１、１２２１，１２２２，１２２３、１２３，１２４及びＳＩＰ電話器１５１，１５２からの発信要求時に該当する着信先（宛先）が複数検索された場合に、これら複数の着信先を一時的に保存する。

また、ユーザ登録情報２２１３としては、アドレス解決に必要な各ＳＩＰ端末の電話番号と宛先等が格納されており、図１に示す一例では、全てのＳＩＰ端末、すなわちＳＩＰゲートウェイ１２１、１２２１，１２２２，１２２３、１２３，１２４及びＳＩＰ電話器１５１，１５２の「ユーザ」や「宛先」などが登録されている。

図３はＳＩＰサーバのユーザ情報を示す説明図である。同図に示す各ＳＩＰ端末（ＳＩＰゲートウェイ１２１、１２２１，１２２２，１２２３、１２３，１２４及びＳＩＰ電話器１５１，１５２）の「ユーザ」は、追加拠点番号または拠点番号を含む内線番号である。

「宛先」は、ＳＩＰ端末の宛先アドレスを示す。本実施例としては、ＳＩＰ端末のＩＰアドレスを格納するものとするが、ＤＮＳによるアドレス解決を行なう場合は、ＤＮＳ解決可能な各ＳＩＰ端末のホスト名であってもよい。

「ポート」はＳＩＰ端末の宛先ポート番号であるが省略も可能であり、省略時はＳＩＰ標準ポートの５０６０が適用される。「優先」は、登録したＳＩＰ端末に同一拠点番号が複数ある場合に、シーケンシャルサーチ（ＲＦＣ３２６１による順次着信）を行なう場合に、接続を試みる優先度を示す。

「発信方法」は同一番号が複数ある場合に、シーケンシャルサーチを行なうかパラレルサーチ（ＲＦＣ３２６１による一斉着信）を行なうかの選択である。発信方法が「構成情報による」はテーブルのデフォルト設定であり、この場合は、ＳＩＰサーバに設定される構成情報２２１１の設定内容に従う。なお、構成情報２２１１は、前述したようにＳＩＰサーバ１１を動作させる為に必要な装置の動作モード等の情報であり、運用によって設定変更が可能であり、設定は管理者等がｔｅｌｎｅｔ接続やＷＥＢ接続等で、外部接続のＰＣ１３等からＳＩＰサーバ１１にログインして行なう。

図４は、図２に示したＳＩＰサーバの構成情報を示す説明図であり、この構成情報２２１１の設定項目の「アドレス」は、ＳＩＰサーバ１１のＩＰアドレスであり、「ＳＩＰポート番号」はＳＩＰサーバ１１でのＳＩＰプロトコルの送受信ポート番号の設定内容を示している。

「ユーザ登録方法」は、ユーザ登録情報２２１３の設定方法として、「手動入力」するか「ＲＥＧＩＳＴＥＲ」を選択する。一方の「手動入力」を選択した場合には、管理者等がｔｅｌｎｅｔ接続やＷＥＢ接続等で、外部接続のＰＣ１３等からユーザ登録情報２２１３の各設定を手動入力する。他方の「ＲＥＧＩＳＴＥＲ」を選択した場合には、ＳＩＰ端末から申告されるＲＥＧＩＳＴＥＲメッセージの内容より、ユーザ登録情報２２１３を自動設定または自動更新する。なお、管理者は保守管理の面とセキュリティーの面を考え、適宜、どちらの運用とするか選択可能となっている。

「発信方法」は、登録したＳＩＰ端末に同一拠点番号が複数ある場合に、「シーケンシャルサーチ」を行なうか「パラレルサーチ」を行なうかのデフォルト値である。実際の動作は、図３に示したユーザ登録情報２２１３の「発信方法」の内容に従う。

「ＲＥＧＩＳＴＥＲのユーザ取得」については後述とする。「ＲＥＧＩＳＴＥＲ認証」項目、「ＩＮＶＩＴＥ認証」は、ＳＩＰサーバ１１がＲＥＧＩＳＥＴＲメッセージやＩＮＶＩＴＥメッセージにＳＩＰ端末を認証するか否かの設定であり、「認証パスワード」はその際のパスワードを示している。認証実施時は、ＳＩＰサーバ１１の設定と各ＳＩＰ端末のパスワード設定を合致させる必要があるが、本実施例ではＲＥＧＩＳＴＥＲ認証項目、ＩＮＶＩＴＥ認証項目はなしにて設定しているものとして説明する。

図５はＳＩＰ端末とＳＩＰサーバの発信、呼出し、応答、切断までの一連の呼制御を示すシーケンスであり、図６はＳＩＰ端末から送出したＩＮＶＩＴＥメッセージの一例を示す説明図であり、それぞれＲＦＣ３２６１に準拠している。図５に示すシーケンスにおいて、ＳＩＰサーバ１１がＩＮＶＩＴＥ受信してアドレス解決の方法、及び決定した宛先にＩＮＶＩＴＥ送信する部分について以下に説明する。

既に登録情報が図３に示す内容の通り登録されているものとして、ＩＮＶＩＴＥ受信、アドレス解決、ＩＮＶＩＴＥ送信するまでの処理を図７〜図９のフローチャートにより説明する。まずＳＩＰサーバ１１は呼接続の最初メッセージであるＩＮＶＩＴＥを受信すると、ＳＩＰメッセージ受信処理（Ｓ９１）が実行される。次に、事前チェック処理（Ｓ９２）にて、プロトコル上の各種チェックを行なう。ここで、チェック結果（Ｓ９３）がＮＧの場合は、エラー応答処理（Ｓ９４）へ移り、エラー応答をＳＩＰサーバ１１からリクエストを受信したＳＩＰ端末へ返信する。また、チェック結果（Ｓ９３）がＯＫの場合は、各メッソッドに対応した処理を行なう。このメソッドが呼接続の最初のＩＮＶＩＴＥ以外（Ｓ９５）の場合は、各メソッドに対応した処理（Ｓ９６）へ移行する。メソッドが呼接続の最初のＩＮＶＩＴＥの場合、着信先を決定する為にアドレス解決処理（Ｓ９８／Ｓ１０１）へ移行する。

続いて、図８に示すアドレス解決処理（Ｓ１０１）では、まず着番号としてｒｅｑｕｅｓｔ−ＵＲＩのユーザの部分を着番号ａとしてコピーする（Ｓ１０２）。次に、図３に示したユーザ登録情報のＮｏ．のインデックスに相当するカウンタｃ、および拠点番号２０着信時のＳＩＰサーバのフォーキング情報（図１０）のＮｏ．のインデクスに相当するカウンタｄ、および最大一致桁数を示すｍａｘ＿ｂ、およびフォーキング情報（図１０）の全レコード内容の初期化を行う（Ｓ１０３）。カウンタｃはユーザ登録情報（図３）を順次検索する為のインデックスであり１ずつ加算（Ｓ１０４）し、ユーザ登録情報（図３）のＮｏ＝ｃに該当するレコードのユーザを拠点番号ｂとして、取得する（Ｓ１０５）。このとき拠点番号ｂが空でなく有効であり、ｃがユーザ登録情報（図３）の最大件数Ｍａｘを超えていない場合（Ｓ１０６）は、着番号ａの桁数が拠点番号ｂの桁数以上かチェックし（Ｓ１０９）、着番号ａの桁数が満たない場合は桁数不足の際はＳ１０４へ戻り、次のユーザ登録情報のレコードからユーザより拠点番号ｂとして取得（Ｓ１０５）する。次に着番号ａの先頭から、拠点番号ｂが一致するかチェックする（Ｓ１０１０）。例えば、ＳＩＰゲートウェイ１２１より電話器１３２１へ「２０１００１」でダイヤル発信した場合、着番号ａ＝２０１００１、拠点番号ｂ＝２０の場合は先頭（接頭）一致につき一致と判断する。一致の場合は、拠点番号ｂの桁数と最大一致桁数ｍａｘ＿ｂを比較（Ｓ１０１１）により、最大一致桁数ｍａｘ＿ｂの更新（Ｓ１０１２）及び、カウンタｄの初期化（Ｓ１０１３）を行なう。拠点番号ｂの桁数が最大一致桁数ｍａｘ＿ｂよりも小さい場合（Ｓ１０１４）は、Ｓ１０４の処理へ戻るが、そうでなければ、カウンタｄを加算し（Ｓ１０１５）、フォーキング情報（図１０）の「Ｎｏ．」がカウンタｄの該当レコードを、ユーザ登録情報（図３）の「Ｎｏ．」がカウンタｃよりコピー（Ｓ１０１６）しＳ１０４へ戻る。なお、前記Ｓ１０１１〜Ｓ１０１６では、先頭一致の番号として、より長い拠点番号を採用すると共に、複数の同一拠点番号があればそれらを複数宛先として取得する為のものである。

また、Ｓ１０６にて拠点番号ｂが空であったり、ｃがユーザ登録情報（図３）の最大数Ｍａｘを超えた場合は検索終了と判断し、カウンタｄが０かチェック（Ｓ１０７）し、０ならば該当する着番号がＳＩＰサーバ１１の登録情報になかったと判断し、エラー応答処理（Ｓ１０８）へ移り、「４０４ ＮｏｔＦｏｕｎｄ」などのエラー応答をＳＩＰサーバ１１がリクエストを受信したＳＩＰ端末へ返信する。また、Ｓ１０１７で検索終了し、フォーキング情報（図１０）に宛先が１つ以上存在する場合に遷移し、ここでフォーキング情報（図１０）の有効レコードまでを優先高→優先低の順に並び替えを行なう。これは後述のシーケンシャルサーチを行なう場合に、ＩＮＶＩＴＥを送出する順番を優先順に行なう為である。例えば、ＳＩＰゲートウェイ１２１より電話器１３２１へ「２０１００１」でダイヤル発信した場合、前述の処理によりフォーキング情報へ３件採取され、優先順にソートされた結果、フォーキング情報は図１０に示す内容の通りとなる。そして、並び替えられた後、ＩＮＶＩＴＥ送信処理（Ｓ１０１８／Ｓ１１１）へ遷移する。

続いて図９に示すＩＮＶＩＴＥ送信処理（Ｓ１１１）では、まずフォーキング情報（図１０）より有効な宛先件数分の、即ち前述のカウンタｄ分のＩＮＶＩＴＥメッセージを作成する（Ｓ１１２）。これはまず、発信端末より受信したＩＮＶＩＴＥメッセージをそれぞれその宛先毎にコピーする。次にコピーしたメッセージの必要なヘッダをそれぞれ書き換える。具体的にはＭａｘＦｏｒｄの減算、Ｒｅｃｏｒｄ−Ｒｏｕｔｅの挿入、Ｖｉａヘッダの更新等をＲＦＣ３２６１に従い行なう。これらのヘッダは宛先毎に変わることはないが、Ｒｅｑｕｅｓｔ−ＵＲＩはフォーキング情報（図１０）の宛先毎にホスト名部分を更新する。例えば、ＳＩＰゲートウェイ１２１より電話器１３２１へ「２０１００１」でダイヤル発信した場合、以下の様にＳＩＰサーバ１１に受信されたＲｅｑｕｅｓｔ−ＵＲＩは、前述のフォーキング情報（図１０）より送信時は送出先毎に次の様に更新する。
ＳＩＰサーバ受信時： ＩＮＶＩＴＥ ｓｉｐ：２０１００１＠Ｓｅｒｖｅｒ ＳＩＰ／２．０
↓
ＳＩＰゲートウェイ（１２２１）へ送出時： ＩＮＶＩＴＥ ｓｉｐ：２０１００１＠ＳＩＰＧＷ１２２１ ＳＩＰ／２．０
ＳＩＰゲートウェイ（１２２２）へ送出時： ＩＮＶＩＴＥ ｓｉｐ：２０１００１＠ＳＩＰＧＷ１２２２ ＳＩＰ／２．０
ＳＩＰゲートウェイ（１２２３）へ送出時： ＩＮＶＩＴＥ ｓｉｐ：２０１００１＠ＳＩＰＧＷ１２２３ ＳＩＰ／２．０

次にフォーキング情報（図１０）の「発信方法」（Ｓ１１３）をチェックし、シーケンシャルサーチの場合は、シーケンシャルサーチによる発信処理（Ｓ１１４）を実行する。

図１１はＳＩＰサーバ１１からシーケンシャルサーチによって発信したシーケンスの一例を示し、このシーケンスでは、ＳＩＰゲートウェイ１２２１へ発信を試みるがＳＩＰゲートウェイ１２２１とＰＢＸ間の音声チャネルに空きがない為、次の優先にスライドし、ＳＩＰゲートウェイ１２２２へ再度発信して通話可能となること示している。この発信により同一拠点に複数のチャネルがあり複数のＳＩＰゲートウェイが設置されている場合には、空きチャネルのあるＳＩＰゲートウェイ回線を捕捉可能である。

次に図１において、ＩＰ電話網１９へ発信する一例を以下に説明する。例えば、第１の拠点内のＳＩＰゲートウェイ１２１から第２の領域内のＩＰ電話器１８１へ発信する場合は、ＩＮＶＩＴＥメッセージにてＲｅｑｕｅｓｔ−ＵＲＩは以下の様に送出され、これをＳＩＰサーバ１１は受信する。
ＳＩＰサーバ受信時： ＩＮＶＩＴＥ ｓｉｐ：０５０１２３４５６７８＠Ｓｅｒｖｅｒ ＳＩＰ／２．０

ユーザ登録情報としては、図３に示すように、０と０５０が「ユーザ」として登録されており、何れにおいても先頭が０にて両者一致するが、図８に示したアドレス解決処理のフローチャートのＳ１０１４での最大桁数のチェック処理より、最終的に一致桁数が、より長い拠点番号０５０の割り当てられた第２の領域のＳＩＰゲートウェイ１２４が、フォーキング情報テーブルの宛先として記録され、前述した図９の処理を経て、ＳＩＰゲートウェイ１２４へ着信する。つまり、ユーザ登録情報にて異なる複数の番号が一致する場合は、より多くの一致桁数を有する宛先へ着信し、短い方のユーザへは着信しない。

次に図１において、第３の拠点内の拠点番号３０のＳＩＰ電話器１５１の着信する一例について説明する。この一例ではユーザ登録情報は、図３の内線番号を含めた電話番号を「ユーザ」としている。すなわち、第２の拠点２０内の拠点番号２０のＳＩＰゲートウェイ１２２１〜１２２３においては、拠点番号２０のみを登録してもよいが、この場合シーケンシャルサーチによりＳＩＰ電話器１５１とＳＩＰ電話器１５２とのどちらにも着信する可能性がある為、全桁数の電話番号を予め登録している。これによって、該当する所望の電話番号のＳＩＰ電話器１５１へ着信可能である。なお、パラレルサーチにて発信した場合は、どちらも一斉に着信させる運用も可能であり、これについては後述とする。

次に、ユーザ登録情報（図３）への登録方法について説明する。本実施例においては、この方法としては２つあり、その一方は、運用管理者等が、事前にこれらの設定項目をＳＩＰサーバへ設定するものであり、他方は、ＳＩＰプロトコルのＲＥＧＩＳＴＥＲに従う登録方法であり、どちらによるかは前述の構成情報（図４）のユーザ登録方法に従う。次に、デフォルト設定である後者のＲＥＧＩＳＴＥＲ登録について以下に説明する。

図１２はＳＩＰサーバへＳＩＰ端末からメッセージにより登録した場合の登録シーケンスであり、図１３はＲＥＧＩＳＴＥＲメッセージの一例を示す説明図であり、何れもＲＦＣ３２６１に準拠している。ＳＩＰ端末から本ＳＩＰサーバ１１のユーザ登録情報２２１３へ登録する場合は、その拠点番号となる先頭（接頭）番号（または拠点番号を含めた内線番号）をＲＥＧＩＳＴＥＲメッセージの登録する「ユーザ」としてＲＥＧＩＳＴＥＲ送出する。具体的には、図１３に示すＲＥＧＩＳＴＥＲメッセージのＴｏ、Ｃｏｎｔａｃｔヘッダのユーザ部分を拠点番号とするようにＳＩＰ端末を設定する。そして、例えばＳＩＰ電話器１５１の拠点番号を３０とし登録し、着信させたい場合は、以下の様にＲＥＧＩＳＴＥＲを送出すればよい。
Ｔｏ： ＜ｓｉｐ：３０＠Ｓｅｒｖｅｒ＞
Ｃｏｎｔａｃｔ： ＜ｓｉｐ：３０＠ ＳＩＰＴＥＬ１．５．１：５０６０＞；ｑ＝１．０

ＳＩＰサーバ１１はデフォルトではＲＥＧＩＳＴＥＲのＣｏｎｔａｃｔヘッダより、ユーザ登録情報（図３）の各項目を設定する。具体的には、以下の対応関係により各項目を設定する。優先はＣｏｎｔａｃｔヘッダのｑ値より決定する。尚、図での優先は便宜上、優先順位で示しているが、ｑ値は一般的には０〜１．０の範囲で記述される。
Ｃｏｎｔａｃｔ： ＜ｓｉｐ：３０＠ ＳＩＰＴＥＬ１．５．１：５０６０＞；ｑ＝０．０
（Ｃｏｎｔａｃｔ： ＜ｓｉｐ：ユーザ＠宛先 ：ポート＞；ｑ＝優先に変換／発信方法設定）

ＲＥＧＩＳＴＥＲメッセージ、および上記Ｃｏｎｔａｃｔの各パラメータはＳＩＰサーバ１１でチェックし、問題なく既に登録されているユーザ登録情報（図３）と比較しそれが新規であれば空きレコードに新規に設定登録し、図３に示す「ユーザ」及び「宛先」にて同一の端末であるとＳＩＰサーバが認識した場合は、ユーザ登録情報（図３）の内容を更新する。

ＲＥＧＩＳＴＥＲ登録方法はＲＦＣ３２６１に準じており各処理の詳細については、ここでは省略するが、本実施例におけるＳＩＰサーバ１１の独自仕様により動作する点について説明する。ユーザ登録情報（図３）の「ユーザ」は、構成情報（図４）の「ＲＥＧＩＳＴＥＲのユーザ取得」設定よりＴｏヘッダからの取得が可能であり、構成情報「ＲＥＧＩＳＴＥＲのユーザ取得」設定が「Ｔｏヘッダ」と選択した場合は、Ｔｏヘッダよりユーザ登録情報（図３）の「ユーザ」を設定する。ＲＦＣ３２６１によると、Ｔｏヘッダから設定するべきであるが、前述の動作は説明の便宜上Ｃｏｎｔａｃｔをデフォルトとしている。また、発信方法は、ＲＦＣ３２６１においてＲＥＧＩＳＴＥＲメッセージでの規定はない為、本ＳＩＰサーバ１１では次のルールを適用する。
ｑ値パラメータ無し ：ＳＩＰサーバ側のデフォルト（構成情報図４の発信方法による）
ｑ値が以下範囲外 ：エラー応答（登録無効）
１．０≧ｑ＞０．０ の範囲：シーケンシャルサーチ （ｑ値より優先設定）
ｑ＝０．０ ：パラレルサーチ

ＳＩＰサーバ１１は複数の同一ユーザの登録を可能とするが、同一ユーザの登録がフォーキング情報テーブル（図１０）の最大レコード件数ｍａｘ（３２件）を超えた場合、ＲＥＧＩＳＴＥＲの応答としてエラー応答「４０３ Ｆｏｒｂｉｄｄｅｎ」を返し、ユーザ登録情報を更新しない。なお、これらＲＥＧＩＳＴＥＲ登録動作はＲＦＣ３２６１に外れるものではないため、ＳＩＰ端末側で番号をＲＥＧＩＳＴＥＲ登録可能とすれば、ＳＩＰサーバ１１により拠点番号を登録利用することが可能となる。

また、図３の一例では、拠点番号３０のＳＩＰ電話器１５１，１５２は内線番号を含めた番号（３０１００１，３０１００２）を登録し、発信方法はシーケンシャルサーチにより内線指定による着信を行なっていたが、前述したＳＩＰ電話器１５１の登録同様に、ＳＩＰ電話器１５２よりＲＥＧＩＳＴＥＲ登録することで、ＳＩＰサーバ側で図１４のようにユーザ登録情報が変更可能である。図１４は拠点番号が３０に変更になった他、前述のＲＥＧＩＳＴＥＲ登録にてｑ値０．０にて登録した結果、発信方法がパラレルサーチに変更された事を示している。この結果、ＳＩＰゲートウェイ１２１より３０１００１へダイヤル発信した場合、ＳＩＰサーバにて、図７、図８のフローチャートの処理が実行され、ユーザ登録情報（図１４）のユーザ「３０」のＳＩＰ電話器２台がフォーキング情報として格納され、その結果、フォーキング情報テーブルは図１５に示したものとなる。次いで図９のフォローチャート処理にて、発信方法のチェック（Ｓ１１３）にてパラレルサーチにて、パラレルサーチによる発信（Ｓ１１５）が適用される。

本ＳＩＰサーバからパラレルサーチサーチによって、発信したシーケンスの一例を図１６に示す。この一例では、ＳＩＰサーバよりＳＩＰ電話器１５１，１５２へ、一斉にＩＮＶＩＴＥ発信するが、先に応答したＳＩＰ電話器１５２と通話確立させ、ＳＩＰ電話器１５１は途中放棄としている。これにより拠点番号３０（ユーザ「３０」）への着信は、３０以降を任意番号とした一斉着信が可能となる。

以上のように本実施例によれば、拠点に収容する電話器やＳＩＰ端末などのユーザ登録を個々に行わずに、電話器やＳＩＰ端末などに割り当てられた番号登録の簡略化を図ることが可能となる。従って、拠点などを新たに設置した際、拠点の配下に有する複数の端末の通信設定を拠点番号を利用して簡単に行うことが可能となり、ＳＩＰサーバにより拠点番号を利用した発着信ができる。さらに、従来のように、ＳＩＰゲートウェイ配下に有する端末の全内線番号の登録が不要となり、ユーザ部分と拠点番号とを関連付けする必要も無く、拠点番号をＳＩＰゲートウェイ割り当て番号計画に利用できるので、運用管理者の番号計画の登録の設定工数を削減することができる。さらに、ＳＩＰサーバのユーザ登録のレコード数（テーブルサイズ）を削減でき、また、ＳＩＰ端末側はＳＩＰ端末側のプログラム変更をすることなく、ＳＩＰサーバによって拠点番号を利用した発着信ができる。

本実施例におけるＳＩＰサーバを用いたＳＩＰネットワークシステムの全体構成を示すブロック図である。 同上、ＳＩＰサーバの概略構成を示すブロック図である。 同上、ＳＩＰサーバのユーザ情報を示す説明図である。 同上、ＳＩＰサーバの構成情報を示す説明図である。 同上、呼制御を示すシーケンスである。 同上、ＩＮＶＩＴＥメッセージの一例を示す説明図である。 同上、ＳＩＰメッセージ（ＩＮＶＩＴＥ）受信処理を示すフローチャートである。 同上、アドレス解決処理のフローチャートである。 同上、（ＩＮＶＩＴＥ）送信処理を示すフローチャートである。 同上、拠点番号２０着信時のＳＩＰサーバのフォーキング情報を示す説明図である。 同上、シーケンシャルサーチでの発信時の呼制御シーケンスである。 同上、１２はＳＩＰサーバへＳＩＰ端末からメッセージにより登録した場合の登録シーケンスである。 同上、ＲＥＧＩＳＴＥＲメッセージの一例を示す説明図である。 同上、ＩＰ電話器からのＲＥＧＩＳＴＥＲ登録変更時におけるＳＩＰサーバのユーザ登録情報を示す説明図である。 同上、ＳＩＰ電話器からＲＥＧＩＳＴＥＲ登録変更後の着信時の内容のＳＩＰサーバのフォーキング情報である。 同上、パラレルサーチでの発信時の呼制御シーケンスである。

符号の説明

１１ ＳＩＰサーバ
１２１ ＳＩＰゲートウェイ（ＳＩＰ端末）
１２２１ ＳＩＰゲートウェイ（ＳＩＰ端末）
１２２２ ＳＩＰゲートウェイ（ＳＩＰ端末）
１２２３ ＳＩＰゲートウェイ（ＳＩＰ端末）
１２３ ＳＩＰゲートウェイ（ＳＩＰ端末）
１２４ ＳＩＰゲートウェイ（ＳＩＰ端末）
２２１６ プログラム
２２１６ａ 呼制御手段
２２１６ｂ 送信手段
２２１６ｃ 受信手段
２２１６ｄ 解読手段

Claims (5)

1. ＳＩＰ端末からの発信要求に応じてＳＩＰプロトコルで呼制御を行う呼制御手段と、ＳＩＰ端末からのＳＩＰメッセージを受信する受信手段と、ＳＩＰメッセージを作成しＳＩＰ端末へ送信する送信手段と、ＳＩＰ端末から受信したリクエストメッセージのＲｅｑｕｅｓｔ−ＵＲＩから宛先を決定するアドレス解決手段とを有するＳＩＰサーバにおいて、
   ＳＩＰ端末の電話番号の先頭の一部分と当該ＳＩＰ端末のアドレスとを対応付けて記憶する記憶手段を有し、
   前記アドレス解決手段は、リクエストメッセージのＲｅｑｕｅｓｔ−ＵＲＩのユーザ部分に含まれる、着信側ＳＩＰ端末の電話番号の先頭の一部分が、前記記憶手段に記憶されている電話番号の先頭の一部分と一致する場合、当該電話番号の先頭の一部分に対応して記憶されているアドレスを着信側ＳＩＰ端末のアドレスとして取得することを特徴とするＳＩＰサーバ。
2. 前記受信手段は、ＴｏヘッダもしくはＣｏｎｔａｃｔヘッダの少なくともいずれかのユーザ部分に着信側ＳＩＰ端末の電話番号の先頭の一部分が設定されたＲＥＧＩＳＴＥＲメッセージを着信側ＳＩＰ端末から受信し、
   前記記憶手段は、ＲＥＧＩＳＴＥＲメッセージに含まれる電話番号の先頭の一部分を、着信側ＳＩＰ端末のアドレスと対応付けて記憶することを特徴とする請求項１記載のＳＩＰサーバ。
3. 前記アドレス解決手段は、Ｒｅｑｕｅｓｔ−ＵＲＩのユーザ部分に含まれる電話番号の先頭の一部分が、前記記憶手段に複数記憶されている場合、当該複数の中で最も桁数の多い電話番号の先頭の一部分を選択し、当該選択した電話番号の先頭の一部分に対応して記憶されているアドレスを取得することを特徴とする請求項１記載のＳＩＰサーバ。
4. 前記送信手段は、前記アドレス解決手段が複数のアドレスを取得した場合、ＲＦＣ３２６１によるシーケンシャルサーチまたはパラレルサーチにより、前記複数のアドレスにリクエストメッセージを送出することを特徴とする請求項１または２記載のＳＩＰサーバ。
5. ＲＥＧＩＳＴＥＲメッセージに含まれるＣｏｎｔａｃｔヘッダのｑ値指定に基づき、シーケンシャルサーチまたはパラレルサーチを行なうことを特徴とする請求項４記載のＳＩＰサーバ。

Images