JP2010130396A

JP2010130396A - 管理装置

Info

Publication number: JP2010130396A
Application number: JP2008303428A
Authority: JP
Inventors: 正 ▲高▼橋; Tadashi Takahashi; Hiroaki Miyata; 裕章宮田; Hiroshi Nishii; 浩士西井
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2008-11-28
Filing date: 2008-11-28
Publication date: 2010-06-10
Also published as: CN101902452A; US20100146096A1

Abstract

【課題】
加入者収容装置からＩＰ網へＰＳＴＮを介さずに直接接続される場合、従来ＰＳＴＮ網内の交換機で振分けていた着信番号により、接続先が音声またはデータを判別できない。また、加入者網までＩＰ網とした場合、アナログ回線およびＩＳＤＮ回線を利用している各ユーザは、音声通話やデータ通信が利用できない。
【解決手段】
ＩＳＤＮ回線かアナログ回線か、メディアゲートウェイ（管理装置）の時分割スイッチ（ＴＳＷ、Time Division Switch）のどのＨＷ（High Way）のＴＳ（TimeSlot）を利用して接続をするか等の情報、加入者が契約しているサービスの情報等の加入者情報を登録・管理するテーブルを用い、テーブルの情報にしたがって加入者端末のIP回線などのインタフェースへの接続を制御する。
【選択図】図１

Description

本発明は、従来のISDN（Integrated Services Digital Network）回線を使用して音声通話およびデータ通信を利用しているユーザをIP網へ接続させる手段を提供するメディアゲートウェイに関する。

近年、次世代ネットワーク（（NGN）Next Generation Network）への移行もますます進んでおり、ネットワークのオールIP（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）化が進んでいる。オールIP（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）化への流れは、アナログ回線およびＩＳＤＮ（Integrated Services Digital Network）回線が収容される公衆交換電話網（ＰＳＴＮ：ＰｕｂｌｉｃＳｗｉｔｃｈｅｄＴｅｌｅｐｈｏｎｅＮｅｔｗｏｒｋ）も例外ではなくなってきている。さらには、上記の動きに併せて、公衆交換電話網（ＰＳＴＮ：ＰｕｂｌｉｃＳｗｉｔｃｈｅｄＴｅｌｅｐｈｏｎｅＮｅｔｗｏｒｋ）において、中継交換機を含む中継網をＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）網への移行が進んでいる。その大きな理由が、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）網で使用されるルータやスイッチは、公衆交換電話網（ＰＳＴＮ：ＰｕｂｌｉｃＳｗｉｔｃｈｅｄＴｅｌｅｐｈｏｎｅＮｅｔｗｏｒｋ）を形成している交換機よりもはるかにコストがかからず、維持費を抑えられるからである。

音声通話に関しては、音声をＩＰパケットで送信するVoIP（Voice over Internet Protocol）技術を利用することにより、中継網にてＩＰ網への以降が進んでいる。
同様に通信接続用のセッション制御プロトコルとしては、ＳＩＰ（Session Initiation Protocol）がＲＦＣ３２６１にて標準化されているため、ＩＰ網上にＳＩＰサーバを配備することで、各ゲートウェイ（ＧＷ）および各端末間でのＶｏＩＰによる音声通話が行われている。

データ通信に関しては、接続先のインターネット接続業者（ＩＳＰ：Internet services provider）に対して着信番号を指定することにより、ＰＳＴＮ網を介して接続先のＲＡＳ(ＲｅｍｏｔｏＡｃｃｅｓｓＳｅｒｖｅｒ)にアクセスすることにより行われている。また、最近では、共通の着信番号にて接続し、各ＩＳＰへの振分けは接続先のＲＡＳ(ＲｅｍｏｔｏＡｃｃｅｓｓＳｅｒｖｅｒ)にて接続識別子(ドメイン名)等によるＩＳＰの振分けも実施されている。

今後も、中継網だけではなく加入者網に対してもＰＳＴＮからＩＰ網への移行が加速するものと考えれる。

また、別のアプローチとして、高速インターネット接続として、光およびＡＤＳＬ接続等のブロードバンドアクセスへの移行も進んでおり、加入者側までＩＰ網としてしまうことで、データ通信およびＶｏＩＰ通信を行うサービスも行われている。

但し、全ての加入者が光およびＡＤＳＬ等のブロードアクセス回線に移行せずに、アナログ回線およびＩＳＤＮ回線を継続して使用する加入者と共存したネットワークとなる。

例えば、特許文献１には、ＰＳＴＮ網における加入者交換機を経由してメディアゲートウェイ（ＭＧ）に接続し、さらにＩＰ網を介することでユーザ端末とインターネット網間のデータ通信が行われることが記載されている。

また、例えば、特許文献２には、ＭＧに収容されている端末から接続要求があり、着信番号の端末が同じＭＧに収容されている場合、ＶｏＩＰに変換せずにそのままＭＧ内にて接続することが記載されている。

特開２００３−３４８２３０特開２００１−３２６７２４

今後、加入者網に対してＩＰ網への移行の加速が予想されるが、アナログ回線およびＩＳＤＮ回線等加入者インタフェースがなくならない限り、アクセスラインとして存在するため、ＩＰ網への移行は加入者収容装置までとなる。そのため、加入者収容装置からＩＰ網へＰＳＴＮを介さずに直接接続される場合、加入者収容装置では、着信番号から通信相手が音声端末なのかデータ通信端末なのか識別が出来ない。そのため、従来ＰＳＴＮ網内の交換機で振分けていた着信番号により、接続先が音声またはデータを判別できなくなってしまうという課題がある。また、加入者網までＩＰ網とした場合、アナログ回線およびＩＳＤＮ回線を利用している各ユーザは、音声通話やデータ通信が利用できなくなってしまうという課題がある。

また、ＰＳＴＮ網における加入者交換機を経由してメディアゲートウェイ（ＭＧ）に接続し、さらにＩＰ網を介することでユーザ端末とインターネット網間のデータ通信が行われる場合、インターネット網に接続するインタフェースＵＮＩにて、データをＩＰ網からＰＳＴＮ網に戻すために、ＰＳＴＮ網を残さなくてはならないという課題がある。

アナログ回線およびISDN回線を利用した複数の電話やＰＣ、データ端末を収容する加入者収容装置をメディアゲートウェイとし、ＩＰ網のエッジに配備し、さらに、ＩＰ網内にはルータやサーバ（例えばＳＩＰサーバ）を配備したネットワーク構成を構築する。アナログおよびＩＳＤＮユーザからの呼設定要求を受けたメディアゲートウェイは、例えばＳＩＰプロトコルとしてのメッセージへの載せ換えを行い、ＳＩＰサーバに対してセッション接続要求を実施することで、加入者交換機および中継交換機等の従来のＰＳＴＮ網への接続を行わずにＩＰ網への接続制御を行う。上記、接続要求を受信したＳＩＰサーバは、接続先の電話番号から自装置内で管理している加入者情報管理テーブルを参照し、接続先のＩＰアドレスおよび接続形態を抽出する。抽出した情報に接続形態がない場合は、ＳＩＰサーバは音声通話と認識し、接続先にセッション接続要求をする。上記セッション接続がを完了した時点で、ＶｏＩＰによる音声通話が可能となる。一方で、抽出した情報に接続形態が登録されていた場合は、ＳＩＰサーバはデータ通信であると判別し、抽出した接続形態を、セッション接続要求メッセージＩＮＶＩＴＥの応答となる200 ＯＫパケットに情報を付加して、メディアゲートウェイに情報を通知する。上記メッセージのなかには、接続先のＩＰアドレスが付加されることもある。

ＳＩＰサーバからのセッション接続要求に対する応答パケットである200 ＯＫを受信したメディアゲートウェイは、応答パケットである200 ＯＫパケットから、接続先のＩＰアドレスおよび接続形態を抽出し、抽出した情報にあわせた動作を実施する。抽出した接続形態情報がＰＰＰoEであった場合には、メディアゲートウェイは、ＰＰＰoEのクライアントとして動作を行い、ＢＡＳとの間でＰＰＰoEのセッション接続を行う。また、抽出した情報が、Ｌ２ＴＰであった場合には、メディアゲートウェイはＬＡＣとして動作をし、ＩＳＰに配備されているＬＮＳとＬ２ＴＰ接続を行う。

上記動作により、データ通信が可能となる。ここでは、ＳＩＰサーバから接続先の接続形態を通知することで、接続先の電話番号から、音声通話かデータ通信かを判別することを可能とし、複数の動作に対応することができる。

本発明では一例として、ＩＳＤＮの利用者かアナログ回線か、メディアゲートウェイ（管理装置）の時分割スイッチ（ＴＳＷ、Time Division Switch）のどのＨＷ（High Way）のＴＳ（TimeSlot）を利用して接続をするかの情報、加入者が契約しているサービスの情報等の加入者情報を登録・管理するテーブルを用い、上記テーブルの情報にしたがって加入者（端末）をIP回線などのインタフェースにて接続先に接続する。また、端末を使用するユーザーである加入者について、セッションを接続している接続先の情報と加入者の情報を管理するテーブルを具備し、上記テーブルの情報に基づいて接続先との接続形態を管理し、データ通信か音声通信かを判別する。また、サーバ（例えばSIPサーバ）において、加入者や接続先の情報を管理する加入者情報管理テーブルを所有し、上記管理テーブルに、音声通信かデータ通信かを識別するための接続形態の情報を管理してもよい。上記SIPサーバは、セション接続要求を受信した際に、接続先の電話番号から、上記管理テーブルにて接続先が音声かデータかを判別し、データであることを判別したら、発信元に対して接続形態を付加して応答メッセージを返信してもよい。

本発明による通信システムは一例として、複数の端末と、前記端末と接続される管理装置と、前記管理装置と接続されるネットワークと、前記ネットワークと接続されるサーバと、前記ネットワークでの接続状態の情報を格納する第1テーブルとを備える通信システムであって、前記管理装置は、前記端末に関する情報を格納する第２テーブルと、前記ネットワークを介するセッションに関する情報を格納する第３テーブルと、前記ネットワークを介するサービスプロバイダの情報を格納する第４テーブルと、前記第2テーブル、前記第3テーブル、及び前記第4テーブルから読み出す情報に基づいて、前記端末と前記ネットワークとの接続を制御するインターフェースとを有し、前記サーバは、前記管理装置からセッション接続要求を受信するときに、前記第1テーブルから読み出す情報に基づいて、応答メッセージを送信する。

ＰＳＴＮ網をＩＰ網に移行する際に、ＩＳＤＮ回線を利用して、音声通話およびデータ通信、さらには、パケット交換サービスを利用しているユーザが収容できる。また、ＳＩＰサーバと連携することで着信番号情報のみで、音声通話かデータ通信かの判別を可能とし、データ通信に対しても複数の接続方法に対応してデータ通信を行うことができる。

以下、図面を用いて実施例について詳細に説明する。

図1は、IPネットワークを示す1実施構成の例の図である。

ネットワークでは、ISDN回線を利用した複数の電話（10-1〜10-ｎ、12-1〜12-m、14-1〜14-ｋ）、複数のPC（11-1〜11-n、13-1〜13-m、15-1〜15-ｋ）、アナログ回線を利用した複数の電話（16-1〜16-n、17-1〜17-m）およびISDNのサービスであるパケット交換サービスを行うデータ端末（140）があり、各々がメディアゲートウェイ（管理装置、MG）（30-1〜30-3）を介してIP網（1）に接続されMG（30-1〜30-3）がインターネットサービスプロバイダであるISP A（80-1）およびISP B（80-2）が各々所有するLNS1（70-1）、LNS2（70-2）と接続され、さらに、パケット交換サービスに対応するパケット網（100）は、MG（30-1）と接続されたネットワーク構成である。

さらに詳しくは、ISDN回線を利用した複数の電話（10-1〜10-ｎ、12-1〜12-m、14-1〜14-ｋ）、複数のPC（11-1〜11-n、13-1〜13-m、15-1〜15-ｋ）は、ISDNのディジタル回線から信号を受け取り、TAなどのISDN対応機器が扱えるように信号を変換する機能を持ったDSU（Digital Service Unit）やさまざまな通信機器をISDNのディジタル回線で使用するために、通信機器の信号をディジタル化するTA（Terminal Adapter）を介して、MG（30-1〜30-3）に接続される。

IP網（1）内には、各種パケットをルーティングするRouter（40）やブロードバンドアクセスサーバであるBAS（60）が配備され、さらにRouter（40）は、VoIP（Voice over Internet Protocol）によるIP電話のセッション接続や切断等のセッション制御を行うSIPサーバ（50）および各種情報の問い合わせに利用されるRADIUSサーバ3（90-3）が接続されている。

インターネットサービスプロバイダであるISP A（80-1）およびISP B（80-2）内には、各々WEBサーバ（１１０−１）およびＷＥＢサーバ（110-2）が配備され、さらには、認証等の処理を行うためのRADIUSサーバ1（90-1）およびRADIUSサーバ2（90-2）が接続されている。さらに、パケット交換サービスを実施するパケット網（100）の先には、データベース（130）が接続されている。

図2は、図1のネットワーク構成の概略図である。

図2に示す丸文字１で囲まれた（111）は、電話1（10-1）と電話2（14-2）が音声通信（VoIP（Voice over Internet Protocol））を実施する際の通信ルートを示し、丸文字２で囲まれた（112）は、PC2（11-2）とISP A（80-1）内のWEBサーバ（110-1）とデータ通信を行う際の通信ルート（112）を示し、丸文字３（113）で囲まれた（113）は、PC1（13-2）とISP B（80-2）内のWEBサーバ（110-2）とデータ通信を行う際通信ルート（113）を示し、丸文字４で囲まれた（114）は、パケット交換サービス利用者が通信を行う際の通信ルートを示している。詳細については後述する。

図2において、電話1（10-1）、PC2（11-2）、PC1（13-2）、ISP A（80-1）およびISP B（80-2）に付随する文字列「xxx-xxx-xxxx」はそれぞれ電話番号を示し、MG（30-1〜30-3）、LNS1（70-1）およびLNS2（70-2）に付随する文字列「xxx.xxx.x.x」は、各端末および装置に割り当てられたIPアドレスを示している。

図3はメディアゲートウェイ（MG）（30）の主要部を示すブロック構成図である。

MG（30）は、装置動作を制御するプロセッサ（38）と、図1および図2に示すISDN回線を利用した複数の電話（10-1〜10-ｎ、12-1〜12-m、14-1〜14-ｋ、16-1〜16-ｎ、17-1〜17-m）、複数のPC（11-1〜11-n、13-1〜13-m、15-1〜15-ｋ）およびデータ端末（140）との接続やデータのやり取りを実施するための複数の加入者回線インタフェース（31-1〜31-n）と、加入者回線インタフェースからのデータを時分割スイッチ（以下、ＴＳＷ）（33）と接続される複数の加入者ＨＷ（High Way、TSWとプロトコル処理部を接続する時分割のバス）（32-1〜32-ｎ）と、加入者HW（32-1〜32-ｎ）を終端するTSW（33）と、プロトコル処理部（35）と接続される複数のIP網側HW（TS1〜TS512、ここでTSはTime Slot）（34-1〜34-m）と、IP網に接続するための複数のIP回線インタフェース（36-1〜36-n）と、メモリ（39）とからなる。

プロセッサ（38）は、制御端末（310）が接続されており、保守者が制御端末（310）を用いて装置の各種制御および情報の登録・削除を行うことができる。

メモリ（39）には、ソフトウェアとして、制御処理（391）があり、開通処理（F3910）、閉塞処理（F3911）、SETUP受信処理（F3912）、発呼処理（F3913）、200 OK受信処理（F3914）、INVITE受信処理（F3915）、CALLPROC受信処理（F3916）、接続振り分け処理（F3917）、認証要求受信処理（F3918）、BYE受信処理（F3919）およびREL COMP受信処理（F3920）の複数の制御処理を備え、加入者情報管理テーブル（392）、セッション接続管理テーブル（393）、データ管理テーブル（394）、ドメイン管理テーブル（395）を備えている。

制御部（37）のメモリ（39）内にある制御処理（391）の詳細な処理は後述する。
加入者管理テーブル（392）には、加入者等の情報（加入者がユーザーである端末が接続する回線の種別情報、その端末が接続するMG管理装置の時分割スイッチの設定情報、及び端末のユーザーに関するサービス情報など）であって、図7で示すように、加入者の電話番号（3921）、ISDN回線の利用かアナログ回線の利用かを示すI/A（3922）、加入者がどのパケットを利用するのかを示す情報であるB1/B2/D/A、加入者に固定的に振り分けたHWおよびTSの各種情報（3923）、MG（30）が利用するIP address（3924）およびポート番号（3925）、加入者回線が利用できるか（開通・閉塞状態）を示すREG STATUS（3926）、SIPを利用する際の識別情報であるSIP URI（3927）および加入者がパケット交換サービスを利用しているか等の契約サービス（3928）の各種情報を登録・更新して管理される。詳細な加入者管理テーブル（392）の利用方法については、後に詳述する。

図7に示す加入者管理テーブル（392、3929.39210）に示すように、加入者の契約サービス（3928）が、Bch-P（3929）およびDch-P（39210）となっている。この情報は、パケット交換サービスを示しており、ISDN回線、アナログ回線とは別のサービスとなっている。パケット交換サービスを利用しているかの識別を行い、MG（30-1）は、パケット網に対してデータを送付する。実施例では特に説明はしないが、図7に示す加入者管理テーブル（392、3929.39210）の契約サービス（3928）の確認を行うことで、MG（30-1）は、パケット網（100）にデータを送信する。

セッション接続管理テーブル（393）には、セッション接続に関する情報を格納するものであって、図8に示すように送信元の電話番号（3931）、SIPを用いた通信時の識別情報となるSIP URI（3932）、IP address(3934)および利用しているポート番号（3935）の情報、接続先の電話番号（3936）、SIPを用いた通信時の識別情報となるSIP URI（3932）、IP address(3938)、利用しているポート番号（3938）、接続先がPPPoEやL2TPにより接続している等の接続形態（39310）の情報、さらには、SIPを用いた通信時にセッション接続メッセージを識別するためのコマンド・シーケンスであるCseq（39310）さらにStutus（39311）が登録・更新され管理される。詳細なセッション接続管理テーブル（393）の利用方法については、後に詳述する。

データ管理テーブルは（394）は、PPPoEのセッションを確立した際のセッション情報を格納するものであって、図9に示すようにPPPoEのセッションを確立した際のSession ID(3941)、L2TPのトンネリングを形成した際のMG（30）のTunnel ID(3942)、Session ID(3943)およびL2TPのトンネリングを形成している接続装置のTunnel ID（3944）およびSession ID（3945）を登録・更新して管理している。詳細なデータ管理テーブル（394）の利用方法については、後に詳述する。

ドメイン管理テーブル（395）は、インターネットサービスプロバイダの情報を格納するものであって、図10に示すようにインターネットサービスプロバイダ毎に決められているドメイン名（3951）およびインターネットサービスプロバイダが各々に所有しているLNS（70-1、70-2）のIP address（3952）が登録・管理されている。詳細なドメイン管理テーブル（395）の利用方法については、後に詳述する。

図4は、SIPサーバ（50）の主要部を示すブロック構成図である。

SIPサーバ（50）は、サーバを制御するプロセッサ（55）と、データの送受信を行う回線インタフェース（51-1、51-n）と、回線インタフェース（51-1、51-n）に接続されたプロトコル処理部（52）と、メモリ（54）と、内部バス（51）からなる。制御部（53）のメモリ（56）には、SIP処理部（561）、加入者情報管理テーブル（562）および接続管理テーブル（563）が備わっており、プロセッサ（58）は、加入者情報管理テーブル（562）および接続管理テーブル（563）を利用してSIP処理部（561）の処理を実行する。

プロセッサ（55）は、制御端末（57）が最終的に接続されており、保守者が制御端末（57）を用いて装置の各種制御および情報の登録・削除を行うことができる。

SIP処理部（561）には、登録・削除処理（F5611）、INVITE受信処理（F5612）、200 OK受信処理（F5613）およびBYE受信処理（F5614）の各種処理がある。詳細な各処理については後述する。

加入者情報管理テーブル（562）は、図11に示すように情報登録をリクエストしてきた加入者等の情報、具体的には加入者などの電話番号（5621）、端末識別情報であるSIP URI（5622）、接続先となる装置のIP address（5623）および登録されているユーザもしくはISPに接続する方法を示す接続形態（5624）の各種情報を登録・更新し管理している。詳細な加入者情報管理テーブル（562）の利用方法については、後に詳述する。

接続管理テーブル（563）では、図12に示すように、セッション接続している端末の情報として、送信元の電話番号（5631）、SIPを利用した通信における識別情報であるSIP URI（5632）、IP address（5633）およびポート番号（5634）の情報、送信先の電話番号（5635）、SIP URI（5636）、IP address（5637）およびポート番号（5638）の情報、さらには、SIPメッセージ内のメッセージ識別情報であるコマンド・シーケンスCSeq（5639）が登録・更新され管理される。詳細な接続管理テーブル（562）の利用方法については、後に詳述する。

図5は、図3に示す加入者HW（32-1〜32-ｎ）収容割当てを示す例である。図5（a）に示すようにISDN回線利用者は、2本のＢチャネル・パケットと1本のＤチャネル・パケットが収容され、加入者HW（32-1〜32-ｎ）からTSW（33）で終端され、また、図5（b）はアナログ回線利用者の収容割当てを示す。図3に示すTSW（33）で終端され、図7に示す加入者管理テーブル（392）のI/A（3922）にてISDN回線もしくはアナログ回線を利用しているかを判断する。

図6は、図3に示すMG（30）内のTSW（33）により振り分けられるHW（34-1〜34-m）のTS割当て規則例を示す。本実施例では、1加入者あたり固定的に4TSを割当てることにする。4ＴＳは、2本のＢチャネル・パケットと1本のＤチャネル・パケットおよびアナログ回線を割り当てる。32MHWの場合、1HWあたりTS1〜TS512まで割り振れるため、128ユーザの収容が可能となる。

図6（a）に示すように、ISDN回線利用者でB1およびB2チャネルしか利用しないユーザは、TS1およびTS2を利用することとなりTS3およびTS4は未使用状態となる。

図6（b）に示すように、ISDN回線利用者でDチャネルしか利用しないユーザは、TS3のみを利用し、TS1、TS2およぼTS4は未使用状態となる。

図6（ｃ）に示すようにアナログ回線利用者は、TS4のみを利用し、TS1〜TS3は未使用状態となる。

上記状態は、加入者情報管理テーブル（392）の情報に基づいて管理され、ユーザ毎にどのHWおよびTSを利用するかを決定している。

本発明では、固定的に決めているが、加入者情報管理テーブル（392）の情報にHWが空いているかを確認する方法等により空いているHWを有効に利用する仕組みとしても良い。

図13は、図3に示す制御端末（310）を通して、保守者が新規ユーザ情報や回線を開通させる指示などのコマンドが発行した際にMG（30）がSIPサーバ（50）に対して加入者情報の登録メッセージの送信を行い、ＳＩＰサーバ（50）のデータベースに加入者情報を登録するまでのシーケンスを示す。

図14は、図3に示す制御端末（310）を通して、保守者が退会したユーザの情報削除や一時的に回線を閉塞するユーザ情報など回線を閉塞するコマンドが発行した際にMG（30）がSIPサーバ（50）に対して加入者情報の削除メッセージを送信し、ＳＩＰサーバのデータベースから加入者情報の削除するまでのシーケンスを示す。

図15は、電話1（20-1）と電話2（14-2）がRTP（Real-time Transport Protocol）を用いたVoIP（Voice over Internet Protocol）通信（音声通話）を行うためのシーケンスおよびプロトコルスタックを示す。

図16は、電話1（20-1）と電話2（14-2）のVoIP通信（音声通話）の切断を行うためのシーケンスを示す。

以下、図13〜図16に示す通信シーケンスと、図21〜図35に示すフローチャートを参照して、実施例1のMG（30）、SIPサーバ（50）の各々の処理動作について説明する。

SIPサーバ（50）に加入者情報登録・削除が完了するまでについてMG（30-1）およびSIPサーバ（50）の処理動作について説明する。

新規加入者の情報の登録や各種設定処理は、図3に示す制御端末（310）を用いて、保守者がコマンド等を入力することで実施する。加入者情報の他に回線を接続できる状態にする開通指示やユーザの理由により一時的に回線を閉塞させるなどの閉塞指示なども保守者の作業に含まれる。

まず、回線を開通させるための開通支持コマンドが発行されたら（Ｆ100）、ＭＧ（30-1）は、図21に示す開通処理（Ｆ3910）フローにしたがって、図36（a）の加入者管理テーブル（392）に示すように、REG STATUS（3926）を開通処理中（Cseq=101 REGISTER）に更新する（F39101）。本発明では、2チャネルあるB1チャネルもしくはB2チャネルどちらを利用するかの選択の仕方については特に規定はしない。

更新処理が完了したら、加入者管理テーブル（392）に登録されている情報、すなわち、発信元となるユーザの電話番号（3921）、SIPを用いた通信の識別情報となるSIP URI（3927）、ＭＧ（30-1）が利用するIP address(3924)および使用するポート番号（3925）をSIPメッセージに付与し、さらには、REG STATUS（3926）に登録したSIPメッセージの識別情報となるコマンド・シーケンスCseq（Cseq = 101 REGISTER）を用いて、SIPサーバ（50）に対して加入者情報登録メッセージであるREGISTERパケット（SQ100）を送信する（F39102）。

REGISTERパケット（SQ100）を受信したSIPサーバ（50）は、図23に示す登録・削除処理（F5611）のフローにしたがって、発信元の電話番号、SIPを用いた通信における識別子であるSIP URIおよびIP address、さらには、SIPメッセージの識別情報であるコマンド・シーケンスCseqを抽出し（F56111）、発信元の電話番号、SIPを用いた通信における識別子であるSIP URIおよびIP addressにて図11(a)に示す加入者情報管理テーブル（562）を検索する（F56112）。

続いて、抽出した情報が登録されており一致するかを確認し（F56113）、一致するものがすでに登録されていた場合については、後に詳述する。一致するものがなければ、抽出した情報である電話番号、SIP URI、IP addressおよびCseqを図11（b）に示す加入者情報管理テーブルに登録する（F56115、562-1）。登録が完了したら、登録完了を示すSIPメッセージである200 OKパケットに抽出したCseqを設定して、200 OKパケット（SQ101）を発信元に送信する（F56116）。

登録完了通知である200 OKパケット（SQ101）を受信したMG（30-1）は、図24に示す200 OK受信処理（F3914）のフローにしたがって、受信した200 OKパケット（SQ101）から、発信元および接続先の電話番号、SIP処理における識別情報であるSIP URI、IP address、ポート番号、接続形態およびCseqを抽出し（F39141）、SIPメッセージの識別情報であるコマンド・シーケンスCseqにて図8に示すセッション管理テーブル（393）を検索する（F39142）。情報が登録されており一致するかを確認し（F39143）、一致した場合は、フロー F391412へ、一致しなかった場合は、さらにSIPメッセージの識別情報であるコマンド・シーケンスCseqにて、図7に示す加入者管理テーブルを検索し（F39144）、その結果が一致するかを確認する（F39145）。検索した結果が一致しない場合は、受信した200 OKパケット（SQ101）を廃棄し（F39146）、一致した場合は、SIPメッセージの識別情報であるコマンド・シーケンスCseqがREGISTERのものであるかを確認する（F39147）。REGISTERに対するものでなかった場合については、後に詳述する。REGISTERに対する200 OKパケット（SQ101）であった場合、SIPメッセージのCONTACTヘッダ内のexpiresを抽出し（F39148）、expiresの値が0かどうかを確認する（F39149）。0でなかった場合には、図36（ｂ）の加入者管理テーブル（392）に示すように、REG STATUS（3926）を開通に更新する（F391410）。0であった場合については後に詳述する。以上により、MG（30-1）がSIPサーバ（50）に対して実施する加入者情報登録処理が完了する。

つづいて、加入者情報削除処理について説明する。閉塞指示（F101）を受けたMG（30-1）は、図22に示す閉塞処理（F3911）のフローにしたがって、図36（c）の加入者管理テーブル（392）に示すように、REG STATUS（3926）を閉塞処理中（Cseq=102 REGISTER）に更新する（F39111）。更新が完了したら、加入者管理テーブル（392）に登録されている情報、すなわち、発信元の電話番号（3921）、SIPを用いた通信の識別情報となるSIP URI（3927）、IP address(3924)および使用するポート番号（3925）、REG STATUS（3926）に登録したSIPメッセージの識別情報であるコマンド・シーケンスCseq（102 REGISTER）付与し、さらに、expiresに0を設定して、SIPサーバ（50）に対して加入者情報削除メッセージであるREGISTERパケット（SQ102）を送信する（F39112）。

REGISTERパケット（SQ102）を受信したSIPサーバ（50）は、図23に示す登録・削除処理（F5611）のフローにしたがって、処理を実施する。加入者情報を登録する際に説明した所は省略し、フローF56113において登録情報と一致した場合から説明する。

フローF56113にて検索した結果が一致した場合は、SIPメッセージ内のexpiresを抽出し（F56117）、抽出した値が0であるかを確認する（F56118）。確認した結果が、0でない場合はREGISTERメッセージ（SQ102）を廃棄し（F56114）、0であった場合には、図11（c）に示す加入者情報テーブル（562、562-2）のように、抽出したSIP URI、IP addressおよび電話番号を削除する（F56119）。削除が完了したら、削除完了を示すSIPメッセージである200 OKパケットに抽出したCseqを設定して、200 OKパケット（SQ103）を発信元の送信する（F56116）。

削除完了を示す200 OKパケット（SQ103）を受信したMG（30-1）は、図24に示す200 OK受信処理（F3914）フローにしたがって処理を実施する。登録処理時について説明した部分は省略し、フローF39148から説明する。抽出したSIPメッセージのCONTACTヘッダ内のexpiresが0であった場合には、図36（ｄ）の加入者管理テーブル（392）が示すように、REG STATUS（3926）を閉塞に更新する（F391411）。

以上により、MG（30-1）がSIPサーバ（50）に対して実施する加入者情報削除処理が完了する。

次に電話1（10-1）と電話2（14-2）がRTP（Real-time Transport Protocol）（VoIP（Voice over Internet Protocol）通信）を開始するまでのMG（30-1）、SIPサーバ（50）の処理動作について、図15に示す通信シーケンスにしたがって説明する。

電話1（10-1）は、電話2（14-1）に対して電話を開始するために、呼設定要求メッセージであるSETUPメッセージ（SQ104）を送信する。

呼設定要求メッセージSETUP（SQ104）を受信したMG（30-1）は、図25に示すSETUP受信処理（F3912）フローにしたがって、回線網からのメッセージをSIPプロトコルに乗せ換える処理を実施する。まず、加入者回線IF No（受信した回線IF No）および接続先の電話番号を抽出し（F39121）、加入者回線IF No（受信した回線IF No）により、図7に示す加入者管理テーブル（392）を検索する（F39122）。つづいて、図7に示す加入者管理テーブル（392）のREG STATUS（3926）が開通となっているかを確認する（F39123）。図36（a）(c)(d)の加入者管理テーブル（392）が示すように、開通となっていない場合は、SETUPメッセージ（SQ104）を廃棄し（F39124）、図36（b）の加入者管理テーブル（392）のREG STATUS（3926）が示すように、開通となっている場合は、発信元（加入者）の電話番号、SIP URI、IP addressおよびポート番号を図7に示す加入者管理テーブル（392）から抽出し、図8（a）に示すセッション管理テーブル（393）に登録する（F39125）。さらに、SETUPメッセージ（SQ104）から抽出した接続先の電話番号を図8（b）に示すセッション管理テーブル（393）のように登録し（F39125）、発信元（加入者）に対して呼設定受付を示すCALLPROC（SQ105）を送信する（F39126）。送信が完了したら、図25に示す発呼処理（F3913）フローにしたがって、図8（c）に示すセッション接続管理テーブル（393）のCseq（3931）のように、SIPメッセージの識別情報となるCseqを「103 INVITE」と登録し（F39131）、図8（C）に示すセッション接続管理テーブル（393）から、接続先の電話番号、発信元（加入者）の電話番号、SIP URIおよびIP addressを抽出し（F39132）、抽出した情報および登録したSIPメッセージの識別情報であるCseq（103 INVITE）にて、電話1（10-1）からSETUPメッセージ（SQ104）をSIPプロトコルで用いるセッション接続要求となるINVITEパケット（SQ106）に載せ換えを行い、SIPサーバ（50）に対して送信する（F39133）。

セッション接続要求であるINVITEパケット（SQ106）を受信したSIPサーバ（50）は、図27に示すINVITE受信処理（F5612）フローにしたがって、接続先の電話番号およびSIPメッセージの識別情報であるコマンド・シーケンスCseqを抽出し（F56121）、接続先の電話番号にて、図11に示す加入者情報管理テーブル（562）を検索する。SIPサーバ（50）に接続先の情報が登録されていない場合は、SIPサーバ（50）はセッション接続要求を行うことができないため、発信元に対してNG応答、相手に接続できないことを伝えるメッセージを送信する（F56124）。図10（a）に示す加入者情報管理テーブル（562、5625）に示すように、接続先の情報が登録されていた場合には、図10（a）に示す加入者情報管理テーブル（562、5625）から、接続先の電話番号、SIP URIおよびIP addressを抽出し、図12（a）に示す接続管理テーブル（563、56310）に登録する（F56125）。さらに、図10（a）に示す加入者情報管理テーブル（562）に接続形態（5624）が登録されているか確認し（F56126）、図10（a）に示す加入者情報管理テーブル（562、5625）に示すように登録されていなければ、データ通信ではなく音声通信であると認識して処理を行う。受信したINVITEパケット（SQ106）から、発信元のSIPを用いた通信の識別情報であるSIP URI、IP address、ポート番号およびSIPメッセージの識別情報であるコマンド・シーケンスであるCseqを抽出し、図11（b）に示す接続管理テーブル（563、56311）のように抽出した情報を登録する（F56127）。接続形態が登録されていた場合については実施例2にて詳述する。

登録が完了（F56127）したら、接続先に対して、同一のSIPメッセージの識別情報であるコマンド・シーケンスであるCseq（103 INVITE）にてセッション接続要求メッセージであるINVITEパケット（SQ107）を送信する（F56128）。

ここで、管理する接続形態とは、音声なのかデータなのかを判別するための情報であり、さらには接続先がどういった接続、例えば、音声なのかPPPoEやL2TPによるデータ通信なのかを示す情報であってネットワークでの通信条件情報となる。この接続形態の情報は、あらかじめSIPサーバ（50）に登録される情報とする仕組みとし、接続形態が登録されていない場合もしくはRTPと登録されいる場合に関しては、通常のSIPサーバと同じように、接続相手までセッション接続要求であるINVITEメッセージを送信する。接続形態が登録されていた場合のSIPサーバ（50）の動作については、実施例2にて詳述する。

ここでは、接続形態の情報はSIPサーバ（50）に持たす仕組みとしたが、その他のシステムにおけるデータベースやMG（30）自身が管理しても良い。

セッション接続要求メッセージであるINVITEパケット（SQ107）を受信したMG（30-3）は、図28に示すINVITE受信処理（F3915）にしたがって、受信したINVITEパケット（SQ107）から接続先の電話番号および発信元の電話番号、SIP URI、IP address、ポート番号を抽出し（F39151）、接続先の電話番号にて図7に示す加入者管理テーブル（392）を検索する（F39152）。検索した結果が一致するかを確認し（F39153）、一致しない場合は、MG（30-3）が収容しているユーザではないため、INVITEパケット（SQ107）を廃棄し（F39154）、一致した場合は、MG（30-3）が収容しているユーザであるので、さらに、図7に示す加入者管理テーブル（392）のREG STATUS（3926）が開通かを確認する（F39155）。開通となっていない場合は、接続できない都度を示すメッセージを含むNG応答メッセージを発信元に送信し（F39156）、開通となっている場合は、接続が可能な状態であるため、図8に示すセッション管理テーブル（392）に抽出した情報を登録し（F39157）、SIPメッセージであるセッション接続要求INVITEメッセージ（SQ107）を回線網で使用するメッセージに載せ換えて、接続先に呼設定要求メッセージであるSETUPメッセージ（SQ108）を送信する（F39158）。

呼設定メッセージSETUP（SQ108）に対する応答であるCALLPROC（SQ109）を受信したMG（30-3）は、図29に示すCALLPROC受信処理（F3916）フローにしたがって、発信元の電話番号を抽出し（F39161）、図8に示すセッション管理テーブル（393）を検索する（F39162）。検索した結果が、一致しなかった場合は、CALLPROCを廃棄し（F39164）、一致した場合は、セッション管理テーブルからSIPメッセージの識別情報であるコマンド・シーケンスCseqを抽出する（F39205）。抽出したCseqがINVITEに対するものかを確認し（F39166）、INVITEでなければ、CALLPROCを廃棄（F39164）し、INVITEであれば、抽出したCseq（103 INVITE）にて200 OK（SQ110）を送信する（F39168）。

接続先からのセッション接続要求であるINVITEパケット（SQ106、SQ107）に対する応答メッセージである200 OKパケット（SQ110）を受信したSIPサーバ（50）は、図30に示す200 OK受信処理（F5613）フローにしたがって、発信元、接続相手の電話番号、SIP通信における識別情報であるSIP URI、IP address、ポート番号およびSIPメッセージの識別情報であるコマンド・シーケンスCseqを抽出し（F56131）、抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseqにて、図12(b)に示す接続管理テーブル（563、5631）を検索する（F56132）。検索した結果が一致するかどうかを確認し（F56133）、一致しない場合は、応答メッセージである200 OKパケットを廃棄する（F56134）。一致した場合は、SIPメッセージの識別情報であるコマンド・シーケンスであるCseqがセッション接続要求であるINVITEに対するものであるかを確認し（F56135）、INVITEに対するものでなければ、BYEに対するものかを確認するフローF561310へ移行する。フローF561310以降については、後で詳述する。

図12(b)に示す接続管理テーブル（563、5631）のように、セッション接続要求であるINVITEに対する応答である200 OKパケット（SQ110）であった場合は、接続先の電話番号、SIP URI、IP addressおよびポート番号にて、図12（b）に示す接続管理テーブル（563）を検索し（F56136）、一致するか（登録されているか）を確認する（F56137）。一致しない（登録されていない）場合は、200 OKパケット（SQ110）を廃棄（F56139）し、一致する場合（登録されている場合）は、図12（ｃ）に示す接続管理テーブル（563、56312）に示すように、発信元のSIP URI、ポート番号を登録する（F56138）。登録完了したら、抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseq（103 INVITE）にて200 OKパケット（SQ111）を接続先に送信する（F561314）。

セッション接続要求であるINVITEパケット（SQ106）に対する応答パケットである200 OKパケット（SQ111）を受信したMG（30-1）は、図24に示す200 OK受信処理（F3914）フローにしたがって処理を実施する。すでに説明済みのフローの説明は省略し、フローF391412から説明をする。

抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseq（F39144）がINVITEパケット（SQ106、SQ107）に対するものであるか確認し（F39147）、図8（C）に示すセッション管理テーブル（393、3931）に示すように、INVITEに対する応答メッセージである200 OKパケット（SQ111）であった場合には、抽出した接続先の電話番号、SIP URI、IP address、ポート番号および接続形態にて、図8（ｃ）に示すセッション接続管理テーブル（393）を検索し（F391413）、検索した結果が一致するかどうかを確認する（F391414）。一致しない場合は、200 OKパケット（SQ111）を廃棄し（F391417）、図8（C）に示すセッション管理テーブル（393、39312）に示すように、一致した場合は、発信元のSIP URI、IP address、ポート番号および接続形態、さらには、Cseq（39310）を図8（ｄ）に示すセッション管理接続テーブル（393、39313）に登録し（F391415）、発信元に対して、ACKを送信する（F391421）。ACKの送信が完了したら、図31に示す接続振り分け処理（F3917）を実施する。

セッション接続要求であるSIPメッセージINVITE（SQ106、SQ107）に対する応答パケットである200 OK(SQ111)を受信し、図24に示す200 OK受信処理（F3914）フローを完了したMG（30-1）は、図31に示す接続振り分け処理（F3917）フローにしたがって、図8（ｄ）に示すセッション接続管理テーブル（393）から接続形態を抽出し（F39171）、接続形態が登録されているかを確認する（F39172）。図8（ｄ）のセッション管理テーブル（393、39313）に示すように、登録がない場合は、接続先である電話2（14-2）が電話にでるまで、すなわち、CONNECTが完了するのを待つ（F39176）。図8（ｄ）に示すセッション接続管理テーブル（393）に接続形態が登録されている場合については、後述する。

CONNECTが完了するのは、着側である電話2（14-2）からのCONNECTメッセージ（SQ113）および200 OK（SQ114〜SQ115）をMG（30-1）が受信し、電話1（10-1）に対してCONNECT（SQ116）を送信し、応答メッセージACK（SQ117）を発信元に送信する。

以上でCONNECT処理が完了する。CONNECTが完了したら、MG（30-1）は、RTP（Real-time Transport Protocol）によるVoIP（Voice over Internet Protocol）通信（音声）処理（F39159）を実施する。

以上で、電話1（10-1）と電話2（14-1）がRTP（Real-time Transport Protocol）によるVoIP（Voice over Internet Protocol）通信を開始するまでのMG（30-1）、SIPサーバ（50）の処理動作が完了し、電話1（10-1）と電話2（14-1）との間で音声通話（SQ118〜SQ120）ができる。

つづいて、電話1（10-1）と電話2（14-1）との間で音声通話（SQ118〜SQ120）を切断する際のMG（30）およびSIPサーバ（50）の処理動作について説明する。

切断要求メッセージであるDISC（SQ121）を受信したMG（30-1）は、発信元の電話番号を抽出し、図8（d）に示すセッション接続管理テーブル（393、3931）に登録があるか確認する。登録がない場合には、DISC（SQ121）を廃棄し、登録があった場合には、図8（e）のセッション管理テーブル（393、39314）に示すように、SIPメッセージの識別情報であるコマンド・シーケンスCseq（104 BYE）を登録し、受信した回線網側の切断メッセージであるDISC（SQ121）をSIPメッセージのセッション切断要求メッセージBYEパケット（SQ122）に変換して接続先に送信する（SQ122）。

セッション切断要求メッセージであるBYEパケット（SQ122）を受信したSIPサーバ（50）は、図33に示すBYE受信処理（F5614）フローにしたがって、発信元および接続先の電話番号、SIP通信における識別情報であるSIP URI、IP addressおよびポート番号を抽出し（F56141）、抽出した情報にて、図12（ｃ）に示す接続管理テーブルを検索する（F56142）。登録されている情報が一致するかを確認し（F56143）、一致しなければ、BYEパケット（SQ121）を廃棄し（F56144）、一致した場合は、SIPメッセージの識別情報であるコマンド・シーケンスCseqを抽出し（F56145）、図12（ｄ）に示す接続管理テーブル（563、56313）ように、SIPメッセージの識別情報であるコマンド・シーケンスCseq（104 BYE）を更新する（F56146）。登録が完了したら、登録したSIPメッセージの識別情報であるコマンド・シーケンスCseq（104 BYE）にて接続先にセッション切断要求であるBYEパケット（SQ123）を送信する（F56147）。

セッション切断要求であるBYEパケット（SQ123）を受信したMG（30-3）は、図34に示すBYE受信処理（F3919）にしたがって、発信元および接続先の電話番号、SIP URI、IP address、ポート番号を抽出し（F39191）、抽出した情報にて図8に示すセッション接続管理テーブル（393）を検索する（F39192）。検索した結果が一致するかを確認し（F39193）、一致しない場合は、セッション切断要求であるBYEパケット（SQ122）を廃棄し（F39194）、一致した場合は、SIPメッセージの識別情報であるコマンド・シーケンスCseq（104 BYE）を抽出し（F39195）、図8に示す接続管理テーブル（563）に登録する（F39196）。登録が完了したら、SIPメッセージで受信した切断要求メッセージBYEパケット（SQ124）を回線網側での切断要求メッセージであるDISC（SQ123）に変換して送信し（F39197）、さらに開放メッセージであるREL（SQ125）を送信する（F39198）。

電話2（14-1）は、開放が完了すると開放完了メッセージであるREL COMP（SQ125）が送信されてくる。開放完了メッセージであるREL COMP（SQ126）を受信したMG（30-3）は、図35に示すREL COMP受信処理（F3920）フローにしたがって、発信元の電話番号を抽出し（F39201）、図8に示すセッション管理テーブル（363）を検索する（F39202）。検索した結果、一致しない場合は、REL COMPを廃棄（F39204）し、一致した場合は、図8に示すセッション管理テーブル（393）からSIPメッセージの識別情報であるコマンド・シーケンスCseqを抽出し（F39205）、BYEに対するものである場合は、抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseqにて200 OKパケット（SQ127）を送信する。BYEに対するものでなかった場合については後述する。

セッション切断要求であるBYEパケット（SQ122）に対する応答メッセージである200 OKパケット（SQ126）を受信したSIPサーバ（50）は、図30に示す200 OK受信処理（F5613）フローにしたがって処理を実施する。すでに説明済みのフローの説明は省略し、フローF561310から説明を開始する。

受信した200 OKパケット（SQ126）から抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseqがBYEに対するものであるかを確認し（F561310）、BYEに対するものでなければ、200 OKパケットを廃棄（F56134）する。図12（ｄ）に示す接続管理テーブル（563,56313）に示すように、BYEに対するものであった場合には、発信元および接続先の電話番号、SIP通信における識別情報であるSIP URI、IP addressおよびポート番号にて、図12（d）に示す接続管理テーブル（ｄ）を検索（F561311）し、登録情報と一致するかを確認する（F561312）。一致しなければ、200 OKパケット（SQ127）を廃棄し（F56134）、一致した場合は、発信元および接続先の登録情報を図12（e）が示すように削除する（F561313）。削除が完了したら、抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseq（104 BYE）にて200 OKパケット（SQ128）を送信する（F561314）。

切断要求パケットであるBYEパケット（SQ121）に対する応答メッセージである200 OKパケット（SQ127）を受信したMG（30-1）は、図24に示す200 OK受信処理（F3914）フローにしたがって処理を実施する。

すでに説明済みの処理に関しては説明を省略し、フローF391416から説明する。MG（30-1）は、受信した200 OKパケット（SQ126）から抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseqがBYEかどうかを確認する（F391416）。BYEに対するものでなかった場合は、200 OKパケットを廃棄（F391417）し、図8（e）が示すセッション管理テーブル（393,39314）のように、切断要求メッセージであるBYEに対する200 OKであった場合には、発信元および接続先の電話番号、SIP URI、IP address、ポート番号および接続形態にて図8（e）に示すセッション接続管理テーブル（393）を検索する（F391418）。検索した結果が一致するかを確認し（F391419）、一致しない場合は、200 OKパケットを廃棄し（F391417）、一致した場合には、図8（ｆ）のセッション接続管理テーブル（393、39315）が示すように発信元の情報およびSIPメッセージの識別情報であるコマンド・シーケンスCseqを削除する（F391420）。削除が完了したら、応答メッセージであるACK（SQ129）を送信（F391421）し、さらに、接続先に呼解放メッセージであるREL（SQ130）を送信する。

呼解放メッセージであるREL（SQ130）に対する呼解放完了メッセージREL COMP（SQ131）を受信したMG（30-1）は、図35に示すREL COMP受信処理（F3920）フローにしたがって処理を行う。説明済みのフローは省略し、フローF39207から説明する。セッション管理テーブルから抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseqがBYEに対するものであるかを確認し（F391207）、BYEに対するものでなかった場合には、図8（g）に示すセッション接続管理テーブル（393）のように発信元の情報を削除する（F39208）。

以上により、音声通話が切断される。

上記により、電話1（10-1）と電話2（14-2）の音声通話開始および切断におけるMG（30）およびSIPサーバ（50）の処理動作の説明が完了する。

次に実施例2について説明する。図17は、PC2（11-2）がISP A（80-1）内のWEBサーバ（110-1）とデータ通信丸文字１を行う際の通信シーケンスおよびプロトコルスタックを示す。
図18は、PC2（11-2）がISP A（80-1）内のWEBサーバ（110-1）とデータ通信丸文字１を切断する際の通信シーケンスを示す。

以下、図17〜図18に示す通信シーケンスと、図21〜図35に示すフローチャートを参照して、実施例2でPC2（11-2）がISP A（80-1）内のWEBサーバ（110-1）とデータ通信丸文字１を実施するまでのMG（30-1、30-2）、SIPサーバ（50）の各々の処理動作について説明する。

まず、データ通信丸文字１を行うまでの処理について説明する。図1８に示すSQ104〜SQ106、図25に示すSETUP受信処理（F3912）、図26に示す発呼処理（F3913）の処理に関しては実施例1と同様のため説明は省略する。

セッション接続要求であるINVITEパケット（SQ106）を受信したSIPサーバ（50）は、図27に示すINVITE受信処理（F5612）フローにしたがって処理を実行する。実施例1と同様の処理に関しては説明を省略し、フローF56126から説明をする。

接続先の電話番号にて図11（a）に示す加入者情報管理テーブル（562）を検索し、接続形態が登録されているかを確認する（F56126）。図11（a）に示す加入者情報管理テーブル（392、5626）に示されるように、登録されている場合は、接続形態（5624）および接続先のIP address（5623）を抽出する（F56129）。図11（a）の接続形態（5624）が示すように、本実施例2では接続形態がPPPoEでデータ通信であることが判明する。

接続形態およびIP addressを抽出したら（F56129）、SIPメッセージの識別情報であるCseq（105 INVITE）を設定し、さらにSIPメッセージ内に接続形態およびIP addressを付加した200 OKパケット（SQ300）を発信元に送信する（F561210）。このときの200 OKパケット（SQ130）の例を図37に示す。ここで、上記で抽出する接続先のIP addressは登録されていないこともある。登録されていない場合は、MG（30）は接続先が分からない状態となるが、接続形態のみを200 OKパケットに付与するのみで問題はない。接続形態のみが登録されている場合に関しては、後に詳述する。

ここでは、図37に示す200 OK パケット例に示すように、例えばヘッダフィールド内にCONNECTION：PPPoE(M100)などと追加して接続形態をMG（30-1）に知らせる方法とした。しかし、SIPメッセージはテキストベースであるため、接続形態の付加の仕方は特に指定することはない。

また、接続形態がRTP（Real-time Transport Protocol）やVoIP（Voice over Internet Protocol）と登録されている場合は、上記に説明した処理ではなく、実施例1で説明した処理、すなわち接続先にセッション接続要求メッセージINVITEを送信する処理となる。

上記に示したように、実施例2では、SIPサーバ（50）は、接続形態の情報を元に、発信元に200 OKを返すか、または、接続先にINVITEを送信するかを判断する。すなわち、接続先の情報を元に、音声通信を行うのか、データ通信を行うのかを判別し、データ通信である場合は、MG（30）にSIPメッセージの200 OKを利用して知らせる仕組みとしている。上記、動作により、MG（30）は、音声かデータかの区別が可能となり、さらに、接続形態にあわせた動作を行うことが可能となる。本実施例では、MG（30）がPPPoEのクライアントとして動作することとなる。

200 OKパケット（SQ300）を受信したMG（30-1）は、図24に示す200 OK受信処理（F3914）にしたがって処理を実行する。すでに実施例1で説明済みの所は省略し、フローF391412から説明を開始する。抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseqがINVITEのものであるかを確認し（F391412）、図8（ｃ）に示すセッション管理テーブル（393、39316）のように、INVITEのものである場合は、接続先の電話番号、SIP URI、IP address、ポート番号および接続形態にて、図8（C）が示すセッション接続管理テーブル（393、39316）を検索し（F391413）、一致するかを確認する。一致しない場合は、200 OKパケットを廃棄（F391317）し、一致した場合は、図8（ｄ）が示すセッション管理テーブル（393、39317）のように、発信元のSIP URI、IP address、ポート番号および接続形態を登録し、さらにSIPメッセージの識別情報であるコマンド・シーケンスCseqを削除する（F391415）。本実施例では、実施例1との相違点は、接続形態がある点となる。

上記により200 OK処理（F3915）が完了したら、図31に示す接続振り分け処理（F3917）フローにしたがって、図8（ｄ）に示すセッション接続管理テーブル（393、39317）から接続形態および接続先のIP addressを抽出し（F39171）、接続形態が登録されているかを確認する（F39172）。接続形態がPPPoEであるかを確認し（F39173）、確認した結果が、図8（d）に示すセッション管理テーブル（393、39317）のように、PPPoEである場合は、MG（30-1）はPC2（11-1）に対してCONNECT（SQ322）を送信し（F39174）、送信が完了したら、PPPoEクライアントとして動作を行い、BAS（60）との間でPPPoE接続処理（F39175）を実施する。また、BAS（60）-LNS1（70-1）間は、L2TPにより接続される。PPPoEでなかった場合については、実施例3にて説明する。

MG（30）は、BAS（60）との間でPPPoEのセッションを接続することで、接続先のIP address等の情報は不要となる。接続先までは、BAS（60）が繋いでくれることとなる。

PPPoE接続処理およびL2TP接続処理（SQ131〜SQ154）に関しては、既知の技術であるため、詳細な説明は省略する。

PPPoEのセッション接続シーケンス（PPPoEディスカバリーステージ）（SQ302〜SQ305）、PPPセッション接続シーケンス（SQ306〜SQ309）を経て、認証要求メッセージ（SQ310）を受信したMG（30-1）は、図32に示す認証要求受信処理（F3918）にしたがって、発信元のIP addressおよび接続識別子（接続識別子：利用するISP毎に割り当てられるユーザID）を抽出し（F39181）、発信元のIP addressにて、図8（ｄ）に示すセッション管理テーブル（393、39317）を検索する（F39182）。検索した結果、登録されているかを確認し（F39183）、登録されていない場合は、認証要求メッセージ（SQ310）を削除し、登録されている場合は、STATUS（39311）が認証要求待ちとなっているか確認する（F39185）。本実施例では、図8（ｄ）に示すセッション管理テーブル（393、39317）に示すように、登録されていないので、認証要求をBAS（60）に送信する（F39186）。その後、BAS（60）とLNS1（70-1）間では、L2TP接続処理が実施され（SQ312）、L2TPのトンネルが形成される（SQ313）。トンネルが形成された後、RADIUSサーバ（90-1）による認証が行われ、認証結果が通知される（SQ314〜SQ316）。認証確立後、IPCPの処理が実行され（SQ317）、データ通信が可能となる。

PPPoE接続処理（F39175）において、付与されるSESSION IDの情報は、図9（a）に示すデータ管理テーブル（394）にて管理される。その際、図8（c）が示すセッション管理テーブル（393、39317）の接続形態「PPPoE #3」の「#3」がデータ管理テーブルの3番目に登録されていることを示し、実施例2では、図9（a）のデータ管理テーブル（394、3946）が示すように、SESSION IDは「55」となる。SESSION IDの登録・管理の方法は、ここに示す方法でなくても問題はない。

上記により、PC2（11-2）がISP A（80-1）内のWEBサーバ（110-1）とデータ通信丸文字１（SQ157〜SQ160）が可能となる。

PC2（11-2）がISP A（80-1）内のWEBサーバ（110-1）とデータ通信丸文字１を切断するの処理について説明する。

まず、PPPセッション開放要求であるLCP Terminate Reqパケット（SQ323）、さらにはPPPセッション開放の応答であるLCP Terminate Aｃｋパケット（SQ324）のやり取りがPC1（11-1）-LNS1（70-1）間で完了することでPPPセッションが開放される。PPPセッションが開放されたら、図8（e）に示すセッション接続管理テーブル（393、39318）に示すように接続先の各種情報を削除する。

PPPセッションが開放された後、PADT送信処理（F102）にしたがって、MG（30-1）は、PPPoEのセッション開放を通知するため、BAS（60）に対してPADTパケット（SQ163）を送信する。その際、図9（ｂ）に示すデータ管理テーブル（394）が示すように、PPPoEのセッションIDを削除してから、PADTパケット（SQ325）を送信する。

PADTパケット（SQ325）を受信したBAS（60）は、L2TP切断処理（SQ326〜SQ330）を実施する。L2TP切断処理（SQ326〜SQ330）は既知の技術であるため説明は省略する。

つづいて、呼切断メッセージであるDISC（SQ331）を受信したMG（30-1）は、発信元の電話番号を抽出し、図8（e）に示すセッション接続管理テーブル（393）に登録があるか確認する。登録がない場合には、DISC（SQ331）を廃棄し、登録があった場合には、図8（e）に示すセッション管理テーブルに、接続先の情報が登録されているか確認する。登録されている場合は、DISC（SQ331）を削除し、登録されていない場合には、発信元に解放を通知するREL（SQ332）を送信する。解放に対して、解放完了を示すREL COMP（SQ333）を受信したMG（30-1）は、図35に示すREL COMP受信処理（F3920）フローにしたがって、発信元の電話番号を抽出し（F39201）、発信元の電話番号にて図8（e）に示すセッション接続管理テーブル（393）を検索する（F39202）。検索結果が一致しない場合は、REL COMPを廃棄し（F39204）、一致した場合は、セッション管理テーブルのSIPメッセージの識別情報であるコマンド・シーケンスCseqを抽出し（F39205）、BYEに対するものかを確認する（F39207）。本実施例では、BYEに対するものではないので、図8(ｆ)が示すセッション接続管理テーブルのように、発信元の情報を削除する（F39208）。

以上により、データ通信丸文字１の切断が完了する。

次に実施例3について説明する。図19は、PC2（13-2）がISP B（80-2）内のWEBサーバ（110-2）とデータ通信丸文字２を行う際の通信シーケンスおよびプロトコルスタックを示す。

図20は、PC2（13-2）がISP B（80-2）内のWEBサーバ（110-2）とデータ通信丸文字２を切断する際の通信シーケンスを示す。

以下、図19〜図20に示す通信シーケンスと、図21〜図35に示すフローチャートを参照して、本発明における実施例2のMG（30）、SIPサーバ（50）の各々の処理動作について説明する。

まず、PC2（13-2）がISP B（80-2）内のWEBサーバ（110-2）とデータ通信丸文字２を開始するまでの処理について説明する。

図19に示すSQ104〜SQ106、図25に示すSETUP受信処理（F3912）、図26に示す発呼処理（F3913）の処理に関しては実施例1と同様のため説明は省略する。

接続先の電話番号にて図11（a）に示す加入者情報管理テーブル（562）を検索し、接続形態が登録されているかを確認する（F56126）。図11（a）に示す加入者情報管理テーブル（562、5627、5628）に示されるように、登録されている場合は、接続形態（5624）および接続先のIP address（5623）を抽出する（F56129）。図11（a）の接続形態（5624）が示すように、本実施例2では接続形態がL2TPを用いたでデータ通信であることが判明する。

本実施例3では、図11（a）に示す加入者情報管理テーブル（562、5627、5628）に示されるように、接続形態および接続先のIP addressが登録されている（5627）および接続形態のみが登録されている（5628）の二通りのパターンがある。実施例2では、PPPoE接続、すなわちレイヤ2ネットワークでのやりとりであるため、接続先のIP addressが分からなくても、BASに対してPADI（SQ302）をブロードキャストで送信し、応答があったBAS（60）との間でPPPoEのセッションを確立できた。しかし、本実施例3では、接続先のIP addressが必要となる。以後、上記必要に応じてIP addressがないパターンについても説明する。

接続形態およびIP addressを抽出したら（F56129）、SIPメッセージの識別情報であるCseq（106 INVITE）を設定し、さらにSIPメッセージ内に接続形態およびIP addressを付加した200 OKパケット（SQ402）を発信元に送信する（F561210）。このときの200 OKパケット（SQ402）の例を図38に示す。

ここでは、図38に示す200 OK パケット例に示すように、例えばヘッダフィールド内にCONNECTION：L2TP/100.0.100.1(M101)などと追加して接続形態をMG（30-1）に知らせる方法とした。後半に示すＩＰａｄｄｒｅｓｓは、接続形態の他にＩＰ addressがある場合に付与する。しかし、SIPメッセージはテキストベースであるため、接続形態の付加の仕方は特に指定することはない。

接続形態がRTP（Real-time Transport Protocol）やVoIP（Voice over Internet Protocol）と登録されている場合は、上記に説明した処理ではなく、実施例1で説明した処理、すなわち接続先にセッション接続要求メッセージINVITEを送信する処理となる。

上記に示したように、実施例2では、SIPサーバ（50）は、接続形態の情報を元に、発信元に200 OKを返すか、または、接続先にINVITEを送信するかを判断する。すなわち、接続先の情報を元に、音声通信を行うのか、データ通信を行うのかを判別し、データ通信である場合は、MG（30）にSIPメッセージの200 OKを利用して知らせる仕組みとしている。上記、動作により、MG（30）は、音声かデータかの区別が可能となり、さらに、接続形態にあわせた動作を行うことが可能となる。本実施例では、MG（30）がLACとして動作することとなる。

200 OKパケット（SQ402）を受信したMG（30-1）は、図24に示す200 OK受信処理（F3914）にしたがって処理を実行する。すでに実施例1で説明済みの所は省略し、フローF39132から説明を開始する。抽出したSIPメッセージの識別情報であるコマンド・シーケンスCseqがINVITEのものであるかを確認し（F391412）、INVITEのものである場合は、接続先の電話番号、SIP URI、IP address、ポート番号および接続形態にて、図8（C）が示すセッション接続管理テーブル（393、39319）を検索し（F391413）、一致するかを確認する。一致する場合は、200 OKパケットを廃棄（F391317）し、一致した場合は、図8（ｄ）が示すセッション管理テーブル（393、39320）のように、発信元のSIP URI、IP address、ポート番号および接続形態を登録し、さらにSIPメッセージの識別情報であるコマンド・シーケンスCseqを削除する（F391415）。本実施例では、実施例1とは違い、接続形態がある点となる。

上記により200 OK処理（F3915）が完了したら、図31に示す接続振り分け処理（F3917）フローにしたがって、図8（ｄ）に示すセッション接続管理テーブル（393、39320）から接続形態および接続先のIP addressを抽出し（F39171）、接続形態が登録されているかを確認する（F39172）。接続形態がPPPoEであるかを確認し（F39173）、PPPoEでなかった場合は、接続形態がL2TPかを確認する（F39175）。L2TPであった場合は、接続先のIP addressが登録されているか確認し（F39178）、図8（ｄ）に示すセッション接続管理テーブル（393、39320）のように登録がある場合は、PC2（13-2）に対して接続要求を示すCONNECT（SQ400）を送信し、接続先IP addressの装置とL2TP接続処理を開始する（F39179）。図8（ｄ）に示すセッション接続管理テーブル（393、39321）が示すように、接続先のIP addressが登録されていない場合は、PC2（13-2）に対して接続要求を示すCONNECT（SQ400）を送信し（F391711）、図8（e）に示すセッション接続管理テーブル（393、39322）のように認証要求待ちを登録する（F391712）。

上記において、接続先のIP addressが登録されていた場合には、接続先装置との間でL2TP接続処理が開始できるが、接続先のIP addressが登録されていない場合には、接続が開始できない。そのため、次に説明する処理において問題を解決する。

続いて、認証要求（SQ406）を受信したMG（30-1）は、図32に示す認証要求受信処理（F3918）にしたがって、発信元のIP addressおよび接続識別子（接続識別子：利用するISP毎に割り当てられるユーザID）を抽出し（F39181）、発信元のIP addressにて、図8（e）に示すセッション管理テーブル（393、39322）を検索する（F39182）。検索した結果、登録されているかを確認し（F39183）、登録されていない場合は、認証要求メッセージ（SQ310）を削除し、登録されている場合は、STATUS（39311）が認証要求待ちとなっているか確認する（F39185）。本実施例では、図8（e）に示すセッション管理テーブル（393、39317）に示すように、登録されているので、抽出した接続識別子にて、図10に示すドメイン管理テーブル（395、3953）を検索し（F39187）、登録されているか確認する（F39171）。登録されていれば、接続先のIP addressを抽出し、図8（f）に示すセッション管理テーブル（393、39323）のようにIP addressを登録する（F391810）。登録が完了したら、接続先の装置とL2TPの接続処理を実施する（F391811）。

図10に示すドメイン管理テーブル（395）に登録がなかった場合は、登録がないことを示すメッセージなどのNG応答を返信する（F391812）。

上記方法により接続先のIP addressを知ることが可能となる。本発明では、MG（30）内にドメイン管理テーブルにて管理を実施したが、RADIUSサーバなどに問い合わせる方法でも問題はない。L2TP接続処理（SQ407）、認証処理（SQ406,SQ408〜SQ412）、IPCP処理（SQ416〜SQ418）の各処理を経て、データ通信が可能となる。上記各種処理は、既知ｎ技術であるため、詳細な説明は省略する。

L2TP接続処理（F39154）において、付与されるSESSION IDおよびTUNNEL IDの各情報は、図9（a）に示すデータ管理テーブル（394）にて管理される。その際、図8（c）が示すセッション管理テーブル（393）の接続形態「L2TP #1」の「#1」がデータ管理テーブルの3番目に登録されていることを示し、実施例2では、図9（a）のデータ管理テーブル（394、3947）が示すように、MG（30-1）のSESSION IDは「1」、TUNNEL IDは「1」、接続先のSESSION IDは「10」、TUNNEL IDは「10」となる。SESSION IDおよびTUNNEL IDの登録・管理の方法は、本発明に示す方法でなくても問題はない。

本実施例においても、実施例2と同様に、接続形態の情報により、音声かデータかの区別をSIPサーバが判別し、SIPメッセージを利用することで、MG（30）は、音声かデータかを区別し、さらには、接続方法が分かることにより、本実施例3では、LACとして動作することを可能とした。

つづいて、PC1（13-2）がISP B（80-2）内のWEBサーバ（110-2）とデータ通信丸文字２を切断するための処理について説明する。

まず、PPPセッション解放をするためにLCP Terminate Reqパケット（SQ197）、さらにはPPPセッション開放の応答であるLCP Terminate Aｃｋパケット（SQ198）によりPPPセッションの解放を行い、その後、L2TP切断処理（SQ419〜SQ434）により実施する。L2TPの処理は既知の技術であるため詳細な説明は省略する。

以上、PPPセッション解放とL2TP切断処理によりL2TPのトンネルが解放され（SQ434）、データ通信丸文字２が終了する。その際、図8（e）に示すセッション接続管理テーブル（393,39324）に示すように、接続先の各種情報を削除する。さらに図9（b）が示すように、MG（30-1）側のTUNNEL IDが「1」、SESSION IDは「1」、LNS2（70-2）側のTUNNEL IDが「10」、SESSION IDは「10」を削除する。

つづいて、呼切断メッセージであるDISC（SQ169）を受信したMG（30-1）は、発信元の電話番号を抽出し、図8（e）に示すセッション接続管理テーブル（393）に登録があるか確認する。登録がない場合には、DISC（SQ204）を廃棄し、登録があった場合には、図8（e）に示すセッション管理テーブルに、接続先の情報が登録されているか確認する。登録されている場合は、DISC（SQ435）を削除し、登録されていない場合には、発信元に解放を通知するREL（SQ436）を送信する。解放に対して、解放完了を示すREL COMP（SQ437）を受信したMG（30-1）は、図31に示すREL COMP受信処理（F3917）フローにしたがって、発信元の電話番号を抽出し（F39171）、発信元の電話番号にて図8（e）に示すセッション接続管理テーブル（393）を検索する（F39172）。検索結果が一致しない場合は、REL COMPを廃棄し（F39174）、一致した場合は、セッション管理テーブルのSIPメッセージの識別情報であるコマンド・シーケンスCseqを抽出し（F39175）、BYEに対するものかを確認する（F39177）。本実施例では、BYEに対するものではないので、図8(ｆ)が示すセッション接続管理テーブルのように、発信元の情報を削除する（F39178）。

以上により、呼切断まで完了し、データ通信丸文字２の切断が完了する。

ネットワーク構成ネットワーク構成概略図 MG（30）の構成図 SIPサーバ（50）の構成図 ISDN回線ユーザおよびアナログ回線ユーザの使用するパケット例を示す図 HWに対するTSの割当て規則例を示す図 MG（30）が管理する加入者管理テーブル MG（30）が管理するセッション接続管理テーブル MG（30）が管理するデータ管理テーブル MG（30）が管理するドメイン管理テーブル SIPサーバ（50）が管理する加入者情報管理テーブル SIPサーバ（50）が管理する接続管理テーブル MG（30）とSIP（50）の間で実施される加入者情報を登録するまでの通信シーケンス MG（30）とSIP（50）の間で実施される加入者情報を削除するまでの通信シーケンス音声通信を開始するまでの通信シーケンス音声通話を切断するまでの通信シーケンスデータ通信丸文字１を開始するまでの通信シーケンスデータ通信丸文字１を終了するまでの通信シーケンスデータ通信丸文字２を開始するまでの通信シーケンスデータ通信丸文字２を終了するまでの通信シーケンス MG（30）が実施する開通処理を示すフロー図 MG（30）が実施する閉塞処理を示すフロー図 SIPサーバ（50）が実施する登録・削除処理を示すフロー図 MG（30）が実施する200 OK受信処理を示すフロー図 MG（30）が実施するSETUP受信処理を示すフロー図 MG（30）が実施する発呼処理を示すフロー図 SIPサーバ（50）が実施するINVITE受信処理を示すフロー図 MG（30）が実施するINVITE受信処理を示すフロー図 MG（30）が実施するCALLPROC処理を示すフロー図 SIPサーバ（50）が実施する200 OK受信処理を示すフロー図 MG（30）が実施する接続振り分け処理を示すフロー図 MG（30）が実施する認証要求受信処理を示すフロー図 SIPサーバ（50）が実施するBYE受信処理を示すフロー図 MG（30）が実施するBYE受信処理を示すフロー図 MG（30）が実施するREL COMP受信処理を示すフロー図 MG（30）が管理する加入者管理テーブル SIPサーバ（50）が送信する200 OKパケット例を示す図 SIPサーバ（50）が送信する200 OKパケット例を示す図

Claims

複数の端末と、前記端末と接続される管理装置と、前記管理装置と接続されるネットワークと、前記ネットワークと接続されるサーバと、前記ネットワークでの接続状態の情報を格納する第1テーブルとを備える通信システムであって、
前記管理装置は、
前記端末に関する情報を格納する第２テーブルと、前記ネットワークを介するセッションに関する情報を格納する第３テーブルと、前記ネットワークを介するサービスプロバイダの情報を格納する第４テーブルと、
前記第2テーブル、前記第3テーブル、及び前記第4テーブルから読み出す情報に基づいて、前記端末と前記ネットワークとの接続を制御するインターフェースとを有し、
前記サーバは、
前記管理装置からセッション接続要求を受信するときに、前記第1テーブルから読み出す情報に基づいて前記管理装置へ応答メッセージを送信することを特徴とする通信システム。
前記管理装置は、前記第2テーブルから読み出す情報に基づいて、前記端末のユーザーが加入するサービス種別を判別し、前記インターフェースは、前記サービス種別に応じて前記ネットワークとの接続を制御することを特徴とする請求項１に記載の通信システム。
前記接続状態の情報は、前記ネットワークでの通信についてデータ通信、音声通信のいずれであるかを判定するための情報を含むことを特徴とする請求項１に記載の通信システム。
前記接続状態の情報は、前記ネットワークでの通信条件情報であって、前記サーバは前記第1テーブルから読み出す情報に基づいて前記ネットワークでの通信についてデータ通信、音声通信のいずれであるかを判定することを特徴とする請求項１に記載の通信システム。
前記サーバは、前記第１テーブルから読み出す情報に基づいて、SIPプロトコルに基づくセッション制御を行う処理部を有することを特徴とする請求項１に記載の通信システム。
前記第２テーブルは、前記端末が接続する回線の種別情報、前記端末が接続する管理装置の時分割スイッチの設定情報、及び前記端末のユーザーに関するサービス情報を格納することを特徴とする請求項１に記載の通信システム。
前記第２テーブルは、前記端末が接続する回線がISDNかアナログ回線かについての種別情報を格納し、前記ネットワークはインターネットプロトコルネットワークであることを特徴とする請求項１に記載の通信システム。
前記第1テーブルは前記サーバに格納されることを特徴とする請求項１に記載の通信システム。
前記第1テーブルは前記管理装置に格納されることを特徴とする請求項１に記載の通信システム。
前記サーバに接続され、前記第1テーブルに格納される情報を制御する制御端末をさらに有することを特徴とする請求項１に記載の通信システム。
前記管理装置は、PPPoEのセッション情報を格納する第５テーブルをさらに有することを特徴とする請求項１に記載のする通信システム。
前記接続状態の情報に関連する接続管理情報を格納する第6テーブルをさらに有することを特徴とする請求項１に記載のする通信システム。
前記第３テーブルは、前記ネットワークを介した接続先の端末の電話番号、発信元の端末の電話番号、及び前記ネットワークにおけるアドレスとを記憶し、前記管理装置は前記端末から受信するメッセージと前記第3テーブルから読み出す情報とに基づいて、前記サーバへメッセージを送信することを特徴とする請求項１に記載の通信システム。
前記サーバは、セッション切断要求メッセージを受信するときに、前記第1テーブルから読み出した情報に基づき前記第6テーブルから接続管理情報を検索することを特徴とする請求項１２に記載の通信システム。
前記サーバは、前記第1テーブルから読み出した情報に基づいて前記ネットワークでの通信についてデータ通信、音声通信のいずれであるかの判定をし、前記データ通信であるときに、接続情報を付加した応答メッセージを前記管理装置へ送信することを特徴とする請求項１に記載の通信システム。