JP4635095B2

JP4635095B2 - 通信システムとそのサーバ装置

Info

Publication number: JP4635095B2
Application number: JP2009155999A
Authority: JP
Inventors: 秀人村上
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2009-06-30
Filing date: 2009-06-30
Publication date: 2011-02-16
Anticipated expiration: 2029-06-30
Also published as: US20100329271A1; US20120002674A1; JP2011015065A

Description

この発明は、ＩＰ（Internet Protocol）ネットワークを介して端末間でメディアデータを授受することの可能な通信システムと、このシステムにおいて用いられるサーバ装置に関する。

ＩＰ化された近年の通信システムにおいて、端末間にエンド・ツウ・エンドのセッションを形成するのにＳＩＰ（Session Initiation Protocol）、Ｈ．３２３、Ｍｅｇａｃｏ（Media gateway control）などのプロトコルが知られている。近年ではＳＩＰを用いるのが主流になってきている。

ＳＩＰの基本仕様は、ＩＥＴＦ（Internet Engineering Task Force）において策定されたＲＦＣ３２６１に記述される。このほかＳＩＰの拡張版や他の関連する種々の仕様が策定されており、例えばＲＦＣ２６６３にはアドレス変換プロトコルであるＮＡＰＴ（Network Address Port Translation）の仕様が記述されている。

ＳＩＰを用いて様々な通信サービスを実現するには、ネットワークに参加するＳＩＰ端末をＳＩＰサーバに登録する手順が必要である。その手順においてＳＩＰ端末は、ＳＩＰサーバに登録要求メッセージ（ＲＥＧＩＳＴＥＲ）を送信する。ＳＩＰサーバは、受信したＲＥＧＩＳＴＥＲメッセージに含まれる登録対象のＳＩＰ−ＵＲＩ（SIP - Uniform Resource Identifier）と、Ｃｏｎｔａｃｔヘッダで通知される要求元のＳＩＰ端末のアドレスとをバインディングし、データベースに記録する。ここで、登録対象のＳＩＰ−ＵＲＩはＡｏＲ（Address of Record）と呼ばれる論理的なアドレスであり、ＳＩＰ端末の実際のアドレスはコンタクトアドレスと称される。

この処理が終わると、ＡｏＲ宛に送信されたＳＩＰメッセージはＳＩＰサーバからこのバインディングされたコンタクトアドレスに転送されるようになる。このような理由から、ＡｏＲを使用している端末を識別するには、通常、コンタクトアドレスを使用することになる。

ところで、ＡｏＲを使用している端末をコンタクトアドレスで識別するケースでは、先に触れたＮＡＰＴ、あるいはＮＡＴ（Network Address Translation）を備えるネットワークで問題が生じる。すなわちＮＡＴ機能を持つ通信装置（例えばＮＡＴルータとする）をＳＩＰメッセージが通過する際、そのメッセージに記されるコンタクトアドレスがＮＡＴルータのグローバルアドレスに置き換えられてしまう。つまりＮＡＴルータの配下のプライベートネットワークに属するＳＩＰ端末のコンタクトアドレスは全て同じＩＰアドレスになってしまうので、ＲＥＧＩＳＴＥＲ発行元の端末そのものを区別することができなくなる。

このことは次のような不具合も生む。例えばＳＩＰサービスを有料で提供するケースではユーザを認証するためにパスワードによる認証を行うが、そもそもシステムが個々の端末を識別できないという脆弱性があるので、悪意あるユーザがパスワードを漏洩すれば本来許されないユーザもサービスを受けることができてしまう。

不正なユーザの利用を防止するために特許文献１の技術が知られている。特許文献１ではユーザを特定する情報をＲＥＧＩＳＴＥＲメッセージに追加することで、個々のＳＩＰ端末のユーザを特定可能としているのでＳＩＰ端末に独自の改変を加える必要がある。特に、ＨＵＢから取得した位置情報を用いてユーザを識別するようにしているので利用できるＳＩＰ端末が制限され、汎用性に欠ける。基本仕様であるＲＦＣ３２６１の規定内で上記不具合を解決可能な手法が求められる。

特開２００８−７８７６６号公報

以上述べたように既存の技術では、ＮＡＴデバイスの配下のプライベートネットワークに属するＳＩＰ端末をＳＩＰサーバが識別できない。このため課金上の不具合などが生じ、何らかの対策が求められる。
この発明は上記事情によりなされたもので、その目的は、プライベートネットワークに属する複数の端末を個々に識別できるようにした通信システムとそのサーバ装置を提供することにある。

上記目的を達成するためにこの発明の一態様によれば、プライベートアドレスを用いるプライベートネットワークとグローバルアドレスを用いるグローバルネットワークとを相互に接続するルータと、前記プライベートネットワークに属する端末と、前記グローバルネットワークに設けられ、前記端末から前記ルータを経由して送出されるＳＩＰ（Session Initiation Protocol）メッセージに基づく処理を行うサーバ装置とを具備する通信システムにおいて、前記サーバ装置は、前記端末から前記ルータを含む経路を介して受信したＲＥＧＩＳＴＥＲメッセージの、当該経路におけるデバイスにより順次追記されるＶｉａヘッダの全てに記載されるＩＰ（Internet Protocol）アドレスから、当該ＲＥＧＩＳＴＥＲメッセージの送出元端末に対応付けられる識別情報を生成する識別情報生成手段と、前記プライベートネットワークに属する端末ごとに、前記識別情報、および当該端末が使用可能なＵＲＩ（Uniform Resource Identifier）数を含む所定の登録条件とを対応付けた管理テーブルと、この管理テーブルにおいて管理される識別情報と前記登録条件とを照合して、その結果に基づいて前記ＲＥＧＩＳＴＥＲメッセージによる登録要求元の端末の登録の可否を判定する登録判定手段とを備えることを特徴とする通信システムが提供される。

このような手段を講じることにより、ＲＥＧＩＳＴＥＲメッセージがサーバ装置に到達すると、全てのＶｉａヘッダに記載されるＩＰアドレスに基づいて識別情報が生成される。Ｖｉａヘッダにおける識別情報はＲＥＧＩＳＴＥＲメッセージの伝送ルートを一意に反映するものであるので、上記識別情報を用いれば各伝送ルート、ひいてはＲＥＧＩＳＴＥＲメッセージの送出元ＳＩＰ端末を一意に識別することが可能になる。

この発明によれば、プライベートネットワークに属する複数の端末を個々に識別できるようにした通信システムとそのサーバ装置を提供することができる。

この発明に係わる通信システムの実施の形態を示すシステム図。図１のＳＩＰサーバ２００の一実施の形態を示す機能ブロック図。図２のＳＩＰサーバ２００に備わるソフトウェア間の関係を示すブロック図。ＲＥＧＩＳＴＥＲメッセージの一例を示す図。図２、図３に示すロケーションテーブル２４ａの一例を示す図。登録判定部２３ｂにより実施される、登録の可否を判定するための処理手順を示すフローチャート。第２の実施形態における識別情報の生成手順につき説明するための図。ロケーションサーバを設けたケースにおけるソフトウェア構成を示す図。

図１は、この発明に係わる通信システムの実施の形態を示すシステム図である。この通信システムは、基幹ネットワーク１００としてのＩＰネットワークと、この基幹ネットワークに接続されるＳＩＰサーバ２００とを中核として形成される。ＳＩＰサーバ２００は、ＳＩＰメッセージの中継を行うプロキシサーバとしての機能と、ＳＩＰ端末のロケーション情報を管理するレジストラサーバとしての機能とを備える。

基幹ネットワーク１００にはルータ３００、４００が接続される。ルータ３００はプライベートネットワークであるネットワークＡを、基幹ネットワーク１００に接続する。ルータ４００はプライベートネットワークであるネットワークＢを、基幹ネットワーク１００に接続する。

基幹ネットワーク１００はグローバルアドレスを用いるネットワークであり、例えば公衆網として利用されるＩＰネットワークである。プライベートネットワークＡ，Ｂはプライベートアドレスを用いるネットワークであり、基幹ネットワーク１００とは異なる管理体系で割り当てられるＩＰアドレスを使用するネットワークである。

そこで、ルータ３００、４００のいずれも、ＮＡＴ機能と、このＮＡＴ機能の元でのＳＩＰメッセージの伝送を保証するＮＡＴ解決機能とを備える。ＮＡＴ機能は、プライベートネットワーク内で使用されるプライベートアドレスと各ルータのグローバルアドレスとを相互に変換する機能であり、現状のＩＰｖ４におけるアドレス不足を解消するために必要な機能である。ルータにＮＡＴ機能を設けることで、グローバルネットワークとプライベートネットワークにおけるＩＰアドレスの管理体系の差異を吸収し、アドレス重複などの不具合無くシステムを運用することが可能になる。しかしＮＡＴ機能は基本的にＩＰパケットのヘッダにおけるＩＰアドレスを変換するものであるので、ＳＩＰメッセージに埋め込まれたＩＰアドレスを変換することはできない。そこで、ＳＩＰを用いるシステムではＮＡＴ解決機能が必要になる。

ＮＡＴ解決機能としては例えばＡＬＧ（Application Level Gateway）がある。ＡＬＧとはＮＡＴ／ＮＡＰＴルータにおいて通過するＳＩＰメッセージの中身を解読し、ＳＩＰメッセージ内に埋め込まれたプライベートアドレスをＮＡＴ／ＮＡＰＴルータのグローバルアドレスに置き換える方法である。ＳＩＰメッセージ内のＩＰアドレスがルータにおいて置換されるので、ＳＩＰ端末側にはＡＬＧ向けの機能を実装する必要が無い。

すなわちルータ３００，４００のいずれも、ＮＡＴルータの機能とＡＬＧサーバの機能とを兼ね備える。ルータ３００のグローバルアドレスは “172.16.38.20” であり、ルータ４００のグローバルアドレスは “172.16.38.30” である。

なおＮＡＴ解決機能にはＡＬＧのほか、ＳＴＵＮ（Simple Traversal of UDP through NAT）、あるいはＴＵＲＮ（Traversal Using Relay NAT）と称する機能もある。ＳＴＵＮはＲＦＣ３４８９に規定され次のような手順を踏むプロトコルである。すなわちＳＩＰ端末は自らのＩＰアドレス、ポート番号を含むパケットをグローバルネットワークに置かれたＳＴＵＮサーバに送信する。ＳＴＵＮサーバはこれを受けてパケットのヘッダの情報とデータ部の情報とを比較し、ＮＡＴ処理の前後におけるＳＩＰ端末のＩＰアドレスとポート番号とを知る。これらの情報はＳＴＵＮサーバから送信元のＳＩＰ端末に通知され、ＳＩＰ端末はグローバルネットワーク側のアドレス情報を知ることが可能になる。これをもとにＳＩＰ端末はＳＩＰメッセージに、グローバルネットワーク使用されるグローバルアドレスを記載することが可能になり、ＮＡＴ解決を実現できる。

ＴＵＲＮでは、メディアを中継（リレー）するための装置（ＴＵＲＮサーバ）をグローバルネットワーク側に配置する。そして、プライベートネットワークとグローバルネットワークとの間で授受されるパケットを一旦ＴＵＲＮサーバを経由させることで、ＮＡＴルータを経由するパケットの送受信を可能とするプロトコルである。

プライベートネットワークＡにはＳＩＰ端末１０，２０が属し、プライベートネットワークＢにはＳＩＰ端末３０が属する。いずれのＳＩＰ端末も固体毎に設定されたＵＲＩを備え、基本的にはこのＵＲＩ（プライマリＵＲＩと称する）を用いてＳＩＰサービスが行われる。例えばプライベートネットワークＡにおけるＳＩＰ端末１０のＩＰアドレスは “192.168.1.10” であり、ＳＩＰ端末２０のＩＰアドレスは “192.168.1.20” である。これらのＩＰアドレスに基づき各端末のＵＲＩが設定される。プライベートネットワークＢにおけるＳＩＰ端末３０のＩＰアドレスは “192.168.1.10” であり、ＳＩＰ端末１０のＩＰアドレスと同じであるが、これはルータ４００のＮＡＴ機能により隠蔽される。なおＡｏＲに関しては、原則として一つのＡｏＲを複数のＳＩＰ端末が同時に使用することは無いものとする。

１台のＳＩＰ端末で複数のＵＲＩを使用する場合に、プライマリＵＲＩ以外のＵＲＩはセカンダリＵＲＩと称され、プライマリＵＲＩに関連付けて管理される。なお、プライマリＵＲＩ、セカンダリＵＲＩは以下の説明において本願発明の特徴を理解しやすくするための概念である。

図１においてＳＩＰサーバ２００は、ＳＩＰ端末１０，２０，３０にとってはレジストラサーバおよびプロキシサーバとして機能する。よってＳＩＰ端末１０はサービスの開始にあたりＲＥＧＩＳＴＥＲメッセージをＳＩＰサーバ２００に送信し、登録を要求する。

図２は、図１のＳＩＰサーバ２００の一実施の形態を示す機能ブロック図である。ＳＩＰサーバ２００はインタフェース部２１、入出力部２２、主制御部２３、およびデータベース部２４を備える。インタフェース部２１は基幹ネットワーク１００に接続され、ＩＰパケットの授受に係わるインタフェース処理を行う。入出力部２２は種々の設定データおよび運用情報の入力などに用いられる。

主制御部２３は、この実施形態に係わる処理機能としてＳＩＰ制御部２３ａ、登録判定部２３ｂ、識別情報生成部２３ｃを備える。ＳＩＰ制御部２３ａは、各ＳＩＰ端末からルータ３００，４００を介して受信したＳＩＰメッセージを解読し、その記載内容に沿って呼接続処理などの制御を行う。登録判定部２３ｂは、ＲＥＧＩＳＴＥＲメッセージにより登録を要求した端末の登録の可否を、データベース部２４に記憶されるロケーションテーブル２４ａを参照して判定する。識別情報生成部２３ｃは、各ＳＩＰ端末からルータ３００，４００を介して受信したＲＥＧＩＳＴＥＲメッセージの全てのＶｉａヘッダに記載されるＩＰアドレスから、各ＳＩＰ端末を識別するための識別情報を生成する。さらに、データベース部２４は使用可能ＵＲＩ数管理テーブル２４ｂを記憶する。このテーブルはＵＲＩのエンティティ、および、１台のＳＩＰ端末において使用可能なＵＲＩの数を設定したテーブルである。

図３は、図２のＳＩＰサーバに備わるソフトウェア間の関係を示すブロック図である。ＲＥＧＩＳＴＥＲメッセージによる登録要求を受信すると、ＳＩＰ制御部２３ａは登録判定部２３ｂにその登録の可否の判定を要求する。登録判定部２３ｂはロケーションテーブル２４ａを参照し、登録の可否を判定する。登録判定部２３ｂは識別情報生成部２３ｃに、各ＳＩＰ端末を識別するための識別情報の生成を要求する。識別情報生成部２３ｃはこの要求に応じ、受信したＲＥＧＩＳＴＥＲメッセージの全てのＶｉａヘッダに記載されるＩＰアドレスから、このＲＥＧＩＳＴＥＲメッセージの送出元端末に対応付けられる識別情報を生成する。

図３において、ＳＩＰサーバ２００に達したＳＩＰメッセージはまずＳＩＰ制御部２３ａで処理される。このＳＩＰメッセージがＲＥＧＩＳＴＥＲメッセージであれば、登録判定部２３ｂにメッセージが通知される。登録判定部２３ｂはこのＲＥＧＩＳＴＥＲメッセージの送出元のＳＩＰ端末の登録の可否の判定を判定する。登録が許可されれば、登録判定部２３ｂはこのＲＥＧＩＳＴＥＲメッセージで通知されたＡｏＲとコンタクトアドレスとの関連付け（バインディング）を行う。

登録判定部２３ｂは、ＲＥＧＩＳＴＥＲメッセージの送信元端末を識別するための情報を生成するため、識別情報生成部２３ｃに識別情報生成要求を送信する。この識別情報生成要求には受信したＲＥＧＩＳＴＥＲメッセージに含まれる全てのＶｉａヘッダがセットされる。

識別情報生成部２３ｃは、識別情報生成要求で通知されたＶｉａヘッダからＩＰアドレスのみを抽出する。全てのＶｉａヘッダから取り出したＩＰアドレスは連結され１行の文字列とし、この文字列から識別情報を生成する。生成した識別情報は識別情報生成結果として要求元の登録判定部２３ｂに返送される。生成された識別情報はロケーションテーブル２４ａに登録される。また、ロケーションテーブル２４ａには、ＡｏＲとコンタクトアドレスの関連も併せて管理される。

図４は、ＲＥＧＩＳＴＥＲメッセージの一例を示す図である。このメッセージはＲＦＣ３２６１に規定される基本的なフォーマットを持つ。ＳＩＰの規定によれば、ＲＥＧＩＳＴＥＲメッセージ内のＣｏｎｔａｃｔヘッダ、およびＶｉａヘッダに、登録要求元であるＳＩＰ端末１０のＩＰアドレス “192.168.1.10” がセットされる。このＲＥＧＩＳＴＥＲメッセージがＳＩＰ端末１０から送出されたのちルータ３００を経由する際、ルータ３００のこれはルータ３００のＡＬＧとしての機能によりその記載の一部が修正される。すなわちＲＥＧＩＳＴＥＲメッセージ内のＣｏｎｔａｃｔヘッダのコンタクトアドレスは “172.16.38.20” に書き換えられる。

この実施形態ではメッセージの上から３行目、４行目に記載されるＶｉａヘッダに着目する。周知のようにＶｉａヘッダはＳＩＰメッセージの通過した経路（ルート）を示す情報で、その通過ルートにおけるデバイス（ＳＩＰ−Ｐｒｏｘｙ）のＩＰアドレスが順次追加して記録されるフィールドである。図４においては、４行目のＶｉａヘッダにＩＰアドレス”192.168.1.10”が記載され、３行目のＶｉａヘッダにＩＰアドレス“172.16.38.20”が記載されている。これは、このＲＥＧＩＳＴＥＲメッセージがＳＩＰ端末１０から送出され、ルータ３００を介してＳＩＰサーバ２００に達したことを示す。

識別情報生成部２３ｃは、これらのＩＰアドレスを組み合わせてＳＩＰ端末を識別するための識別情報を生成する。識別情報を生成するには先に述べたように単純加算によるチェックサム、あるいはＭＤ５／ＳＨＡのようなハッシュ関数を利用できる。例えばチェックサムを利用する例では、各ＩＰアドレスの数字を連結して” 172.16.38.20192.168.1.10 ”という文字列を生成し、これを単純加算することでチェックサムを用いた識別情報を作成することができる。具体的には、連結した文字列“ 172.16.38.20192.168.1.10 ”を０ｘ３１＋０ｘ３７＋０ｘ３２＋…０ｘ３１＋０ｘ３０のように単純加算することで、識別情報＝０Ｘ４ＡＦが生成される。

すなわち文字列はアスキー（ASCII）コードで表現され、例えばＳＩＰメッセージで通知されるＩＰアドレス” 172.16.38.20 ”をバイナリコードで表現すると“０ｘ３１，０ｘ３７，０ｘ３２，０ｘ２Ｅ，０ｘ３１，０ｘ３６，０ｘ２Ｅ，０ｘ３３，０ｘ３８，０ｘ２Ｅ，０ｘ３２，０ｘ３０”となる。このバイナリデータをそのまま加算することで高速にチェックサムを生成することができる。また、文字コードを変換するといった処理も不要であり、その分、処理を高速化することができる。

図５は、図２、図３に示すロケーションテーブル２４ａの一例を示す図である。ロケーションテーブル２４ａには登録対象となるＳＩＰ端末ＡｏＲをキー情報として、ＲＥＧＩＳＴＥＲ送出元のＳＩＰ端末へのコンタクトアドレス、ｑ値、保持期間といった、ＲＦＣ３２６１で定義されるバインディングのために必要となる情報が登録される。これに加えてこの実施形態では、ＳＩＰ端末のプライマリＵＲＩ、および、上記生成された識別情報が登録される。次に、上記構成における作用を説明する。

図６は、登録判定部２３ｂにより実施される、登録の可否を判定するための処理手順を示すフローチャートである。登録判定部２３ｂは、システムへの登録を要求するＳＩＰ端末からのＲＥＧＩＳＴＥＲを受信すると、このメッセージに記載されるＡｏＲが使用可能であるか否かをチェックし（ブロックＢ１）、使用不可能であれば登録を拒否する（ブロックＢ２）。

次に登録判定部２３ｂは、上記記載されるＡｏＲがロケーションテーブル２４ａに登録されているものか否かをチェックする（ブロックＢ３）。ロケーションテーブル２４ａに、判定対象のＡｏＲが存在していれば、登録判定部２３ｂはＲＥＧＩＳＴＥＲメッセージの受信を受けて識別情報生成部２３ｃにより生成された識別情報と、ロケーションテーブル内の識別情報とが同じであるか否かを判定する（ブロックＢ４）。二つの識別情報が一致すればバインディングのリフレッシュと判断し（ブロックＢ５）、登録判定部２３ｂはロケーションテーブル２４ａの該当レコード中の保持期間を更新するとともに、処理が正常終了したことをＳＩＰ制御部２３ａに通知する。二つの識別情報が一致しなければ登録判定部２３ｂは不正な登録要求と判断し、登録を拒否する。

ブロックＢ３でＮｏ、すなわち通知されたＡｏＲが未登録であれば初回登録としての処理が開始される。すなわち登録判定部２３ｂは受信したＲＥＧＩＳＴＥＲメッセージ中のＡｏＲがプライマリＵＲＩであるか否かを、使用可能ＵＲＩ数管理テーブル２４ｂを参照して判定する（ブロックＢ６）。プライマリＵＲＩであれば、ロケーションテーブル２４ａに同じ識別情報を持つレコードが存在するか否かを確認する（ブロックＢ１０）。同じ識別情報を持つレコードが存在していれば、登録判定部２３ｂは登録を拒否する（ブロックＢ１１）。この手順により、１台の端末で使用できるプライマリＵＲＩを一つだけに限定して動作させることができる。なおシステム要求によっては複数のプライマリＵＲＩを使用する事も想定される。

ブロックＢ１０で同じ識別情報を持つレコードが存在しなければ、登録判定部２３ｂはプライマリＵＲＩの初回登録と判断し、通知された情報や識別情報をロケーションテーブル２４ａに登録し、ＡｏＲとコンタクトアドレスとのバインディングを行う（ブロックＢ１２）。通知されたＡｏＲがセカンダリＵＲＩであれば、登録判定部２３ｂは使用可能ＵＲＩ数テーブルＢ１３を更新し、セカンダリＵＲＩとしての登録処理を行う（ブロックＢ１３）。以上の手順により、ＵＲＩを使用するＳＩＰ端末を物理的に識別して特定することが可能になる。

以上説明したようにこの実施形態では、ＮＡＴ機能を持つルータ経由でＲＥＧＩＳＴＥＲメッセージがＳＩＰサーバ２００に達すると、ＳＩＰサーバ２００の識別情報生成部２３ｃは、受信したＲＥＧＩＳＴＥＲメッセージの全てのＶｉａヘッダから、それぞれＩＰアドレスを抽出する。識別情報生成部２３ｃはこれらのＩＰアドレスの文字列を連結し、得られた数字列を単純加算して生成したチェックサムを識別情報としてロケーションテーブル２４ａに登録する。識別情報は、抽出したＩＰアドレスを連結したままのデータを用いても良いし、あるいは各ＩＰアドレスからハッシュ関数を用いて生成したハッシュ値を用いても良い。また、各ＩＰアドレスを単純に連結した文字列情報を識別情報としても良い。さらには、ＩＰアドレスを含めてＶｉａヘッダを部分的に切り出した情報を用いても良い。要するに全てのＶｉａヘッダのＩＰアドレスから、一意に識別可能な情報を生成できれば良い。

登録可否判定部２３ｂは、生成された識別情報と既に登録済みＵＲＩの情報とが蓄積されているロケーションテーブル２４ａ、および、各ＳＩＰ端末が使用できるＵＲＩ数が設定されている使用可能ＵＲＩ数管理テーブル２４ｂとを参照して、ＲＥＧＩＳＴＥＲ送出元のＳＩＰ端末の登録の可否を判定する。

Ｖｉａヘッダに記載されるＩＰアドレスはＲＥＧＩＳＴＥＲメッセージの経由したルートを一意に示すものであるので、全てのＩＰアドレスから生成した識別情報により、ＳＩＰ端末のそれぞれを物理的に識別することが可能になる。従ってこの識別情報と各ＳＩＰ端末とを一意に対応付けることができ、当該識別情報に基づいて、プライベートネットワークに属する複数のＳＩＰ端末を個々に識別することが可能になる。

従って、一つのＵＲＩを１台のＳＩＰ端末と確実に関連付け、関連付けの無いＳＩＰ端末では当該ＵＲＩを同時に使用できないようにすることができる。これによりＵＲＩを単位として課金されるシステムにおいて、ＵＲＩの不正利用を防止することができる。さらには、同じＳＩＰ端末からの一定数以上のＲＥＧＩＳＴＥＲを制限して、ＳＩＰサーバ２００の過負荷対策を促すことなどが可能となる。

また上記の手順によればＳＩＰ端末に独自の機能を追加する必要が無いのに加え、少ない比較処理で１台のＳＩＰ端末で使用できるＵＲＩ数、あるいは一つのＵＲＩを同時に使用できるＳＩＰ端末数を確実に制御することが可能になる。

またこの実施形態では、ＳＩＰ−Ｐｒｏｘｙを中継する度に付加されるＶｉａヘッダの全てを参照するようにしている。これによりＮＡＴ超えを要するプライベートネットワークが複数存在するケースにも対処することが可能である。つまり図１のＳＩＰ端末１０，３０のように、複数のＳＩＰ端末が重複するプライベートアドレスを持つケースがある。そこで、全てのＶｉａヘッダのＩＰアドレスを参照することでプライベートネットワークの区別も含めて、個々のＳＩＰ端末を物理的に識別することが可能になる。

さらに、多段のＳＩＰ−Ｐｒｏｘｙを経由するとその都度Ｖｉａヘッダが付加されるので、識別情報生成のためのデータ量も増大する。この実施形態では連結したＩＰアドレスから生成したチェックサムを識別情報として用いるようにしているので、データ量を削減でき、処理メモリに要する容量を削減して、ひいてはシステムのコストアップを防止することも可能になる。このほか、ハッシュ関数によるハッシュ値を用いても同様の効果を得られる。

［第２の実施形態］
第１の実施形態では、各ルータ３００，４００におけるＮＡＴ機能がＡＬＧにより解決されるケースを想定した。このケースではＲＥＧＩＳＴＥＲメッセージの要求元ラインにおけるＩＰアドレスがセグメント（プライベートネットワーク）ごとに異なるので、ＲＥＧＩＳＴＥＲメッセージ中のＶｉａヘッダのみを用いて、各ＳＩＰ端末を特定するための識別情報を生成することができる。これに対し先に触れたＳＴＵＮ、あるいはＴＵＲＮによりＮＡＴ解決がなされるケースではＶｉａヘッダの要求元ラインのＩＰアドレスが同じのセグメントの全てで同じになる。以下ではこのようなケースを想定した実施の形態につき説明する。

図７は、この実施形態における識別情報の生成手順につき説明するための図である。すなわちこの実施形態では、ＲＥＧＩＳＴＥＲメッセージ内のＶｉａヘッダに記されるＩＰアドレスに加えて、このＲＥＧＩＳＴＥＲメッセージを伝送したＩＰパケットに記されるＩＰヘッダ、およびＵＤＰ／ＴＣＰヘッダをも利用する。

図７に示されるように、ＳＩＰメッセージを伝送するＩＰパケットにはＩＰヘッダにその送信元および宛先のＩＰアドレスが記載される。ＴＣＰまたはＵＤＰヘッダには、送信元および宛先のポート番号が記載される。図７によればＳＩＰメッセージの３行目のＶｉａヘッダに、ＩＰアドレス“172.16.38.20”が記載され、４行目のＶｉａヘッダにＩＰアドレス”192.168.1.10”が記載されている。さらに、ＴＣＰ／ＵＤＰヘッダの送信元ポート番号には”1000”が記載され、ＩＰヘッダの送信元ＩＰアドレスには “172.16.38.20 ”が記載されている。

そこでこの実施形態では、これらのＩＰアドレスおよびポート番号を組み合わせ、“172.16.38.20192.168.1.10172.16.38.201000 ” という文字列を生成し、これを単純加算することでチェックサムを作成する。すなわち第２の実施形態では第１の実施形態で用いた手法を拡張し、ＶｉａヘッダのＩＰアドレスに加え、ＲＥＧＩＳＴＥＲメッセージを伝播したＩＰパケットのＩＰヘッダにおける送信元ＩＰアドレス、および、ＵＤＰ／ＴＣＰヘッダに含まれる送信元ポート番号も使用してチェックサムを生成するようにしている。このチェックサムを識別情報として用いることにより、ＡＬＧ以外の手法（例えばＳＴＵＮ、ＴＵＲＮ）でＮＡＴ問題が解決されるシステムにおいても、ＲＥＧＩＳＴＥＲ送出元のＳＩＰ端末を個別に識別することが可能となる。

なお、この発明は上記実施の形態に限定されるものではない。例えばＳＩＰ端末のロケーションを管理するためのロケーションサーバを用いても良い。
図８はロケーションサーバを設けたケースにおけるソフトウェア構成を示す図である。ロケーションサーバ５００はＳＩＰサーバ２００とは独立して設けられ、データベース２４を備えてロケーションテーブル２４ａと使用可能ＵＲＩ数テーブル２４ｂとを記憶する。このような構成にする事により、ＳＩＰサーバが複数存在する場合において、各ＳＩＰサーバが参照するロケーション情報の完全性を向上させることが可能になる。つまり複数のＳＩＰサーバにロケーションテーブルを記憶させると、それらの同期を取る必要がある。図８に示すようにデータベースを単一化することで、データベース間の同期処理の必要がなくなるので、登録判定部２３ｂが参照すべきデータを統一化することが可能になる。

さらに、この発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１００…基幹ネットワーク、２００…ＳＩＰサーバ、３００，４００…ルータ、Ａ，Ｂ…プライベートネットワーク、１０，２０，３０…ＳＩＰ端末、２１…インタフェース部、２２…入出力部、２３…主制御部、２３ａ…ＳＩＰ制御部、２３ｂ…登録判定部、２３ｃ…識別情報生成部、２４…データベース部、２４ａ…ロケーションテーブル、２４ｂ…使用可能ＵＲＩ数管理テーブル

Claims

プライベートアドレスを用いるプライベートネットワークとグローバルアドレスを用いるグローバルネットワークとを相互に接続するルータと、
前記プライベートネットワークに属する端末と、
前記グローバルネットワークに設けられ、前記端末から前記ルータを経由して送出されるＳＩＰ（Session Initiation Protocol）メッセージに基づく処理を行うサーバ装置とを具備する通信システムにおいて、
前記サーバ装置は、
前記端末から前記ルータを含む経路を介して受信したＲＥＧＩＳＴＥＲメッセージの、当該経路におけるデバイスにより順次追記されるＶｉａヘッダの全てに記載されるＩＰ（Internet Protocol）アドレスから、当該ＲＥＧＩＳＴＥＲメッセージの送出元端末に対応付けられる識別情報を生成する識別情報生成手段と、
前記プライベートネットワークに属する端末ごとに、前記識別情報、および当該端末が使用可能なＵＲＩ（Uniform Resource Identifier）数を含む所定の登録条件とを対応付けた管理テーブルと、
この管理テーブルにおいて管理される識別情報と前記登録条件とを照合して、その結果に基づいて前記ＲＥＧＩＳＴＥＲメッセージによる登録要求元の端末の登録の可否を判定する登録判定手段とを備えることを特徴とする通信システム。
前記識別情報生成手段は、前記ＲＥＧＩＳＴＥＲメッセージの全てのＶｉａヘッダに記載されるＩＰアドレスを連結した文字情報から生成したチェックサムを前記識別情報とすることを特徴とする請求項１に記載の通信システム。
前記識別情報生成手段は、前記ＲＥＧＩＳＴＥＲメッセージの全てのＶｉａヘッダに記載されるＩＰアドレスからハッシュ関数を用いて生成したハッシュ値を前記識別情報とすることを特徴とする請求項１に記載の通信システム。
前記識別情報生成手段は、さらに、前記受信したＲＥＧＩＳＴＥＲメッセージを伝送したＩＰパケットのＩＰヘッダに記載される送信元ＩＰアドレスと、当該ＩＰパケットのＴＣＰ／ＵＤＰヘッダに記載される送信元ポート番号とを、前記全てのＶｉａヘッダに記載されるＩＰアドレスに組み合わせて前記識別情報を生成することを特徴とする請求項１に記載の通信システム。
プライベートアドレスを用いるプライベートネットワークとグローバルアドレスを用いるグローバルネットワークとを相互に接続するルータと、前記プライベートネットワークに属する端末とを具備する通信システムの前記グローバルネットワークに設けられるサーバ装置において、
前記端末から前記ルータを経由して送出されるＳＩＰ（Session Initiation Protocol）メッセージに基づく処理を行うＳＩＰ制御手段と、
前記端末から前記ルータを含む経路を介して受信したＲＥＧＩＳＴＥＲメッセージの、当該経路におけるデバイスにより順次追記されるＶｉａヘッダの全てに記載されるＩＰ（Internet Protocol）アドレスから、当該ＲＥＧＩＳＴＥＲメッセージの送出元端末に対応付けられる識別情報を生成する識別情報生成手段と、
前記プライベートネットワークに属する端末ごとに、前記識別情報、および当該端末が使用可能なＵＲＩ（Uniform Resource Identifier）数を含む所定の登録条件とを対応付けた管理テーブルと、
この管理テーブルにおいて管理される識別情報と前記登録条件とを照合して、その結果に基づいて前記ＲＥＧＩＳＴＥＲメッセージによる登録要求元の端末の登録の可否を判定する登録判定手段とを備えることを特徴とするサーバ装置。
前記識別情報生成手段は、前記ＲＥＧＩＳＴＥＲメッセージの全てのＶｉａヘッダに記載されるＩＰアドレスを連結した文字情報から生成したチェックサムを前記識別情報とすることを特徴とする請求項５に記載のサーバ装置。
前記識別情報生成手段は、前記ＲＥＧＩＳＴＥＲメッセージの全てのＶｉａヘッダに記載されるＩＰアドレスからハッシュ関数を用いて生成したハッシュ値を前記識別情報とすることを特徴とする請求項５に記載のサーバ装置。
前記識別情報生成手段は、さらに、前記受信したＲＥＧＩＳＴＥＲメッセージを伝送したＩＰパケットのＩＰヘッダに記載される送信元ＩＰアドレスと、当該ＩＰパケットのＴＣＰ／ＵＤＰヘッダに記載される送信元ポート番号とを、前記全てのＶｉａヘッダに記載されるＩＰアドレスに組み合わせて前記識別情報を生成することを特徴とする請求項５に記載のサーバ装置。