JP4328595B2

JP4328595B2 - ネットワーク、構内交換機及びそれに用いるマルチプロトコル通信端末制御方法

Info

Publication number: JP4328595B2
Application number: JP2003360133A
Authority: JP
Inventors: 義夫板垣; 忍木俣
Original assignee: NEC Communication Systems Ltd; NEC Infrontia Corp
Current assignee: NEC Platforms Ltd; NEC Communication Systems Ltd
Priority date: 2003-10-21
Filing date: 2003-10-21
Publication date: 2009-09-09
Anticipated expiration: 2023-10-21
Also published as: GB2408410A; US20050083916A1; GB2408410B; CA2485624A1; AU2004222781B2; GB0423445D0; CA2485624C; HK1074554A1; JP2005129982A; AU2004222781A1; US7660293B2

Description

本発明はネットワーク、構内交換機及びそれに用いるマルチプロトコル通信端末制御方法に関し、特に構内交換機（ＩＰ−ＰＢＸ：ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ−ＰｒｉｖａｔｅＢｒａｎｃｈｅＸｃｈａｎｇｅ）を含むネットワークに接続される端末に関する。

従来、この種のネットワークにおいては、構内交換機に固定電話端末やＰＨＳ（ＰｅｒｓｏｎａｌＨａｎｄｙ−ｐｈｏｎｅＳｙｓｔｅｍ）等の無線端末、及びＶｏＩＰ（ＶｏｉｃｅｏｖｅｒＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）端末等をＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）で接続して構成されている。

ＶｏＩＰ端末としては、ＩＰ電話端末やインタネット電話端末のほかに、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）端末がある。ＳＩＰはＩＰ網の環境において、ＩＰパケットという形式のデータを用いて、音声通話（固定電話、携帯電話等）をはじめ、テレビ電話等のビデオ通信やチャット（文字による会話）等のマルチメディア通信を開始したり、終了したりするために使用する通信プロトコルである。

ＩＰ網では、一般に、電子メールのように、相手との接続を確認せずに通信を行うコネクションレス型通信であるのに対し、固定電話では、一般に、相手との接続を確認して通信を行うコネクション型通信である。ＳＩＰは上記のＩＰ網においてコネクション型通信を実現するものである。

ＳＩＰは、基本的に、ＩＮＶＩＴＥ（ユーザ間のセッション確立）、ＡＣＫ（確認応答）、ＣＡＮＣＥＬ（セッション確立中のＩＮＶＩＴＥを終了させる）、ＢＹＥ（セッションの終了）等のメソッド（Ｍｅｔｈｏｄ、動作）で構成され、それぞれのメソッドをクライアントとサーバとの間で、リクエストとそれに対するレスポンスとしてやりとりすることで、セッションを確立したり、終了したりしている。

また、ＳＩＰは、アプリケーションを比較的簡単に作ることができるという特徴を持つ。例えば、ＩＰ電話に用いられるＩＴＵ−ＴのＨ．３２３に新サービスを追加する場合には、Ｈ．３２３付加サービスを規定するＨ．４５０．ｘプロトコルを追加し、ネットワーク上の全てのＨ．３２３エンド・ポイント及びゲートキーパのソフトウェアをアップデートする必要がある。しかしながら、ＳＩＰの場合には、新サービスを提供するＳＩＰアプリケーション・サーバを追加し、このサービスを利用するクライアントにのみ、対応するアプリケーションを追加すれば、新サービスが利用可能となる。

特開平０１−０６２９３４号公報特開平０３−０３４７４３号公報 "ＳＩＰ：ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ"［ＲＦＣ（ＲｅｑｕｅｓｔＦｏｒＣｏｍｍｅｎｔｓ）３２６１，Ｊｕｎｅ２００２，８〜３４ページ］

しかしながら、ＳＩＰ端末間の通信においては、ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ）で定義されているサービス（例えば、転送サービス、三者通話サービス、コール・ウェイティングサービス等）しか提供することができないという問題がある。

つまり、ＳＩＰ端末間の通信では、それらのＳＩＰ端末が上記のネットワークに接続されていたとしても、構内交換機が提供する豊富なサービス（例えば、コールバックサービス、内線割込みサービス、サードパーティコントロールサービス等）を受けることができないという問題がある。

また、ＳＩＰ端末間の通信では、新たなサービスが追加された場合に、ＳＩＰ端末（上記のクライアント）自身のソフトウェアをバージョンアップすることで、サービスを追加する必要があるという問題がある。

そこで、本発明の目的は上記の問題点を解消し、ＳＩＰ端末自身のソフトウェアをバージョンアップすることなく、構内交換機が提供する豊富なサービスを受けることができるネットワーク、構内交換機及びそれに用いるマルチプロトコル通信端末制御方法を提供することにある。

本発明によるネットワークは、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）網において相手先との接続を確認して通信を行うコネクション型通信を実現するＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）によって通信を行うＳＩＰ端末と、端末間の呼接続処理を行う構内交換機とを少なくとも含むネットワークであって、
前記構内交換機のコンポーネント群の一つとして組込まれかつ前記ＳＩＰの処理を代理のユーザ・エージェントとして動作するＢ２ＢＵＡ（ＢａｃｋＴｏＢａｃｋＵｓｅｒＡｇｅｎｔ）の仕組みを用いてモジュール化したＳＩＰ系プロトコル制御モジュールを備え、
端末間におけるＤＴＭＦ（ＤｉａｌＴｏｎｅＭｕｌｔｉＦｒｅｑｕｅｎｃｙ）信号送受信能力の交換を前記構内交換機を介在させて実現している。

本発明による構内交換機は、端末間の呼接続処理を行う構内交換機であって、
ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）網において相手先との接続を確認して通信を行うコネクション型通信を実現するＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）の処理を代理のユーザ・エージェントとして動作するＢ２ＢＵＡ（ＢａｃｋＴｏＢａｃｋＵｓｅｒＡｇｅｎｔ）の仕組みを用いてモジュール化したＳＩＰ系プロトコル制御モジュールをコンポーネント群の一つとして組込み、
端末間におけるＤＴＭＦ（ＤｉａｌＴｏｎｅＭｕｌｔｉＦｒｅｑｕｅｎｃｙ）信号送受信能力の交換を実現させている。

本発明によるマルチプロトコル通信端末制御方法は、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）網において相手先との接続を確認して通信を行うコネクション型通信を実現するＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）によって通信を行うＳＩＰ端末と、端末間の呼接続処理を行う構内交換機とを少なくとも含むネットワークのマルチプロトコル通信端末制御方法であって、
代理のユーザ・エージェントとして動作するＢ２ＢＵＡ（ＢａｃｋＴｏＢａｃｋＵｓｅｒＡｇｅｎｔ）の仕組みを用いてモジュール化されかつ前記構内交換機のコンポーネント群の一つとして組込まれたＳＩＰ系プロトコル制御モジュールに前記ＳＩＰの処理を行わせ、
端末間におけるＤＴＭＦ（ＤｉａｌＴｏｎｅＭｕｌｔｉＦｒｅｑｕｅｎｃｙ）信号送受信能力の交換を前記構内交換機を介在させて実現している。

すなわち、本発明の構内交換機（ＩＰ−ＰＢＸ：ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ−ＰｒｉｖａｔｅＢｒａｎｃｈｅＸｃｈａｎｇｅ）は、ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）の処理をＢ２ＢＵＡ（ＢａｃｋＴｏＢａｃｋＵｓｅｒＡｇｅｎｔ）の仕組みを用いてモジュール化し、構内交換機のコンポーネント群の一つとして組込む。構内交換機はモジュール化された各プロトコル群に対し、相互接続を提供し、また付加サービスを提供する。

これによって、標準のＳＩＰ端末と標準のＳＩＰプロキシサーバという組合わせのシステムでは、実現のための工数を多く必要とした多彩な既存プロトコルとの接続を柔軟に実現し、同時に、現行の構内交換機が持つ豊富な付加サービスを利用することも可能となる。

また、ＳＩＰを拡張した拡張ＳＩＰプロトコルａや拡張ＳＩＰプロトコルｂ等のプロトコルも、上記と同様に、Ｂ２ＢＵＡの仕組みを用いてモジュール化し、構内交換機に組込むことによって、標準ＳＩＰプロトコルの範囲では実現が難しい付加サービス等も柔軟に実現することが可能になるとともに、それらの端末に対しても標準ＳＩＰプロトコル端末はもちろん、既存プロトコル端末との相互接続を提供することが可能となる。

さらに、本発明の構内交換機では、ＤＴＭＦ（ＤｉａｌＴｏｎｅＭｕｌｔｉＦｒｅｑｕｅｎｃｙ）信号送受信能力の交換も、構内交換機が介在することで実現する。つまり、ＤＴＭＦ信号送受信能力の問合せに応答できない端末については、構内交換機が適切な応答を行い、両端の端末については、ネゴシエーションで確認された手段でＤＴＭＦの送受信を行う。実際のＤＴＭＦ信号送信においては、構内交換機がその送信を代行する場合がある。

本発明の構内交換機では、上述した一連の処理によって、異なるプロトコル端末間でも、ＤＴＭＦ信号の送受信を実現することが可能となる。

本発明は、以下に述べるような構成及び動作とすることで、ＳＩＰ端末自身のソフトウェアをバージョンアップすることなく、構内交換機が提供する豊富なサービスを受けることができるという効果が得られる。

次に、本発明の実施例について図面を参照して説明する。図１は本発明の一実施例によるネットワークの構成を示すブロック図である。図１において、本発明の一実施例によるネットワークはＩＰ−ＰＢＸ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ−ＰｒｉｖａｔｅＢｒａｎｃｈｅＸｃｈａｎｇｅ：ＩＰ対応構内交換機）１と、プロトコルＡ対応端末２と、プロトコルＢ対応端末３と、プロトコルＸ対応端末４と、標準ＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）プロトコル対応端末５と、拡張ＳＩＰプロトコルａ対応端末６と、拡張ＳＩＰプロトコルｂ対応端末７と、メディアゲートウェイ８とを相互にＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）１００で接続して構成され、メディアゲートウェイ８を介してインタネット２００に接続されている。

図２は図１のＩＰ−ＰＢＸ１の構成を示すブロック図である。図２において、ＩＰ−ＰＢＸ１はＰＢＸ付加サービス提供モジュール１１と、ＰＢＸ基本接続処理提供モジュール１２と、既存プロトコルＡ制御モジュール１３と、既存プロトコルＢ制御モジュール１４と、既存プロトコルＸ制御モジュール１５と、標準ＳＩＰプロトコル制御モジュール１６と、拡張ＳＩＰプロトコルａ制御モジュール１７と、拡張ＳＩＰプロトコルｂ制御モジュール１８と、テーブル１９とから構成されている。

標準ＳＩＰプロトコル制御モジュール１６、拡張ＳＩＰプロトコルａ制御モジュール１７、拡張ＳＩＰプロトコルｂ制御モジュール１８はそれぞれＳＩＰ系プロトコルを終端し、ＳＩＰの処理をＢ２ＢＵＡ（ＢａｃｋＴｏＢａｃｋＵｓｅｒＡｇｅｎｔ）の仕組みを用いてモジュール化してＩＰ−ＰＢＸ１のコンポーネント群の一つとして組込まれるものであり、ハードウェアでも、またソフトウェアでも実現可能である。ＩＰ−ＰＢＸ１は上記のモジュール化された各プロトコル群に対し、相互接続を提供し、また付加サービスを提供する。

ここで、Ｂ２ＢＵＡは、発信元のＳＩＰ端末からＳＩＰリクエスト（ＳＩＰメッセージ）を受取った時に、ユーザ・エージェント・サーバとしてそのリクエスト（メッセージ）を処理する論理的なエンティティ（機能）である。また、Ｂ２ＢＵＡでは、発信元のＳＩＰ端末からのリクエストに対してどのように答えるべきかを決定するために、発信先のＳＩＰ端末に対してユーザ・エージェント・クライアントとして動作し、発信先のＳＩＰ端末へのリクエストを生成する。

つまり、Ｂ２ＢＵＡは、プライベートなユーザ・エージェントとパブリックなユーザ・エージェントとが結合されたもので、それぞれのネットワーク（端末）に対して代理のユーザ・エージェントとして動作する。

ＰＢＸ付加サービス提供モジュール１１はプロトコルＡ対応端末２、プロトコルＢ対応端末３、プロトコルＸ対応端末４、標準ＳＩＰプロトコル対応端末５、拡張ＳＩＰプロトコルａ対応端末６、拡張ＳＩＰプロトコルｂ対応端末７に対して付加サービス（例えば、コールバックサービス、内線割込みサービス、サードパーティコントロールサービス等）を提供する。

ＰＢＸ基本接続処理提供モジュール１２はプロトコルＡ対応端末２、プロトコルＢ対応端末３、プロトコルＸ対応端末４、標準ＳＩＰプロトコル対応端末５、拡張ＳＩＰプロトコルａ対応端末６、拡張ＳＩＰプロトコルｂ対応端末７に対して基本接続処理を提供するとともに、それらの相互接続を提供する。

既存プロトコルＡ制御モジュール１３はプロトコルＡ対応端末２に対応して設けられ、プロトコルＡ対応端末２からの信号をＩＰ−ＰＢＸ１内部のプロトコル（以下、ＰＢＸ内部プロトコルとする）の信号に変換してＰＢＸ基本接続処理提供モジュール１２に送信するとともに、ＰＢＸ基本接続処理提供モジュール１２からの信号をプロトコルＡの信号に変換してプロトコルＡ対応端末２に送信する。

既存プロトコルＢ制御モジュール１４はプロトコルＢ対応端末３に対応して設けられ、プロトコルＢ対応端末３からの信号をＰＢＸ内部プロトコルの信号に変換してＰＢＸ基本接続処理提供モジュール１２に送信するとともに、ＰＢＸ基本接続処理提供モジュール１２からの信号をプロトコルＢの信号に変換してプロトコルＢ対応端末３に送信する。

既存プロトコルＸ制御モジュール１５はプロトコルＸ対応端末４に対応して設けられ、プロトコルＸ対応端末４からの信号をＰＢＸ内部プロトコルの信号に変換してＰＢＸ基本接続処理提供モジュール１２に送信するとともに、ＰＢＸ基本接続処理提供モジュール１２からの信号をプロトコルＸの信号に変換してプロトコルＸ対応端末４に送信する。

標準ＳＩＰプロトコル制御モジュール１６は標準ＳＩＰプロトコル対応端末５に対応して設けられ、標準ＳＩＰプロトコル対応端末５からの信号（リクエスト）をＰＢＸ内部プロトコルの信号に変換してＰＢＸ基本接続処理提供モジュール１２に送信するとともに、ＰＢＸ基本接続処理提供モジュール１２からの信号（上記のリクエストに対する応答、または標準ＳＩＰプロトコル対応端末５へのリクエスト）を標準ＳＩＰプロトコルの信号に変換して標準ＳＩＰプロトコル対応端末５に送信する。

拡張ＳＩＰプロトコルａ制御モジュール１７は拡張ＳＩＰプロトコルａ対応端末６に対応して設けられ、拡張ＳＩＰプロトコルａ対応端末６からの信号（リクエスト）をＰＢＸ内部プロトコルの信号に変換してＰＢＸ基本接続処理提供モジュール１２に送信するとともに、ＰＢＸ基本接続処理提供モジュール１２からの信号（上記のリクエストに対する応答、または拡張ＳＩＰプロトコルａ対応端末６へのリクエスト）を拡張ＳＩＰプロトコルａの信号に変換して拡張ＳＩＰプロトコルａ対応端末６に送信する。

拡張ＳＩＰプロトコルｂ制御モジュール１８は、拡張ＳＩＰプロトコルｂ対応端末７に対応して設けられ、拡張ＳＩＰプロトコルｂ対応端末７からの信号（リクエスト）をＰＢＸ内部プロトコルの信号に変換してＰＢＸ基本接続処理提供モジュール１２に送信するとともに、ＰＢＸ基本接続処理提供モジュール１２からの信号（上記のリクエストに対する応答、または拡張ＳＩＰプロトコルｂ対応端末７へのリクエスト）を拡張ＳＩＰプロトコルｂの信号に変換して拡張ＳＩＰプロトコルｂ対応端末７に送信する。

ここで、既存プロトコルＡ制御モジュール１３、既存プロトコルＢ制御モジュール１４、既存プロトコルＸ制御モジュール１５、標準ＳＩＰプロトコル制御モジュール１６、拡張ＳＩＰプロトコルａ制御モジュール１７、拡張ＳＩＰプロトコルｂ制御モジュール１８にはそれぞれポート番号（ポート＃１〜＃６）またはＩＰアドレス（ローカルＩＰアドレスまたはグローバルＩＰアドレス）が割り当てられている。テーブル１９はそれら割り当てられたポート番号またはＩＰアドレス毎に対応する端末のプロトコルが保持されており、ＰＢＸ基本接続処理提供モジュール１２はテーブル１９を参照してポート番号またはＩＰアドレスからプロトコルを判定する。

図３及び図４は図１のＩＰ−ＰＢＸ１の処理動作を示すシーケンスチャートである。これら図１〜図４を参照してＩＰ−ＰＢＸ１の処理動作について説明する。これらの処理はハードウェアでも、ソフトウェア（プログラム）でも実現可能である。

まず、既存プロトコル対応端末（図１のプロトコルＡ対応端末２、プロトコルＢ対応端末３、プロトコルＸ対応端末４）からＳＩＰ系プロトコル対応端末（図１の標準ＳＩＰプロトコル対応端末５、拡張ＳＩＰプロトコルａ対応端末６、拡張ＳＩＰプロトコルｂ対応端末７）に接続が要求された場合の処理について説明する。

既存プロトコル対応端末からＩＰ−ＰＢＸ１にＳＩＰ系プロトコル対応端末への接続要求が送信されると、ＩＰ−ＰＢＸ１の既存プロトコル制御モジュール（図２の既存プロトコルＡ制御モジュール１３、既存プロトコルＢ制御モジュール１４、既存プロトコルＸ制御モジュール１５）は既存プロトコルの通信制御にて既存プロトコル対応端末からの接続要求を受付け（図３のａ１）、その既存プロトコルの接続要求をＰＢＸ内部プロトコルの信号に変換し、その信号をＰＢＸ基本接続処理提供モジュール１２に送る（ＰＢＸプロトコルで処理）（図３のａ２）。

ＰＢＸ基本接続処理提供モジュール１２は既存プロトコル対応端末からの接続要求を処理してＳＩＰ系プロトコル制御モジュール（図２の標準ＳＩＰプロトコル制御モジュール１６、拡張ＳＩＰプロトコルａ制御モジュール１７、拡張ＳＩＰプロトコルｂ制御モジュール１８）に渡す（ＰＢＸプロトコルで処理）（図３のａ３）。

ＳＩＰ系プロトコル制御モジュールはＰＢＸ基本接続処理提供モジュール１２からの信号をＳＩＰ系プロトコルの接続要求に変換し、その接続要求をＳＩＰ系プロトコルの通信制御にてＳＩＰ系プロトコル対応端末に送信する（図３のａ４）。

以上の処理によって既存プロトコル対応端末とＳＩＰ系プロトコル対応端末との間のセッションが確立すると、既存プロトコル対応端末とＳＩＰ系プロトコル対応端末との間のメディアパケットはＰｅｅｒ−ｔｏ−Ｐｅｅｒで通信される（図３のａ５）。但し、上記のように、一方がＩＰ端末でない場合にはメディアパケットの通信をＩＰ−ＰＢＸ１が代行する。

尚、既存プロトコル対応端末とＳＩＰ系プロトコル対応端末との間の通信において、ＩＰ−ＰＢＸ１の付加サービスを利用する場合にはその要求がＰＢＸ基本接続処理提供モジュール１２からＰＢＸ付加サービス提供モジュール１１へと渡されて処理される。

次に、標準ＳＩＰプロトコル対応端末５から拡張ＳＩＰプロトコルａ対応端末６に接続が要求された場合の処理について説明する。

標準ＳＩＰプロトコル対応端末５からＩＰ−ＰＢＸ１に拡張ＳＩＰプロトコルａ対応端末６への接続要求が送信されると、ＩＰ−ＰＢＸ１の標準ＳＩＰプロトコル制御モジュール１６は標準ＳＩＰプロトコルの通信制御にて標準ＳＩＰプロトコル対応端末５からの接続要求を受付け（図４のｂ１）、その標準ＳＩＰプロトコルの接続要求をＰＢＸ内部プロトコルの信号に変換し、その信号をＰＢＸ基本接続処理提供モジュール１２に送る（ＰＢＸプロトコルで処理）（図４のｂ２）。

ＰＢＸ基本接続処理提供モジュール１２は標準ＳＩＰプロトコル対応端末５からの接続要求を処理して拡張ＳＩＰプロトコルａ制御モジュール１７に渡す（ＰＢＸプロトコルで処理）（図４のｂ３）。

拡張ＳＩＰプロトコルａ制御モジュール１７はＰＢＸ基本接続処理提供モジュール１２からの信号を拡張ＳＩＰプロトコルａの接続要求に変換し、その接続要求を拡張ＳＩＰプロトコルａの通信制御にて拡張ＳＩＰプロトコルａ対応端末６に送信する（図４のｂ４）。

以上の処理によって標準ＳＩＰプロトコル対応端末５と拡張ＳＩＰプロトコルａ対応端末６との間のセッションが確立すると、標準ＳＩＰプロトコル対応端末５と拡張ＳＩＰプロトコルａ対応端末６との間のメディアパケットはＰｅｅｒ−ｔｏ−Ｐｅｅｒで通信される（図４のｂ５）。

図５〜図７は図１のＩＰ−ＰＢＸ１を介した呼接続処理を示すシーケンスチャートである。これら図１と図２と図５〜図７とを参照してＩＰ−ＰＢＸ１を介した呼接続処理について説明する。

拡張ＳＩＰプロトコルａ対応端末６がＩＰ−ＰＢＸ１を介して標準ＳＩＰプロトコル対応端末５に呼接続処理を行う場合、ＩＰ−ＰＢＸ１では標準ＳＩＰプロトコル制御モジュール１６が拡張ＳＩＰプロトコルａ対応端末６に対してユーザ・エージェント・サーバとして動作し（図５のｃ２，ｃ３，ｃ７，ｃ８，ｃ１０，ｃ１５，ｃ１８，ｃ２０）、拡張ＳＩＰプロトコルａ制御モジュール１７に対してユーザ・エージェント・クライアントとして動作する。

拡張ＳＩＰプロトコルａ制御モジュール１７は標準ＳＩＰプロトコル制御モジュール１６に対してユーザ・エージェント・サーバとして動作し、標準ＳＩＰプロトコル対応端末５にに対してユーザ・エージェント・クライアントとして動作する（図５のｃ５，ｃ１１，ｃ１６）。

つまり、拡張ＳＩＰプロトコルａ対応端末６がＩＰ−ＰＢＸ１に「ＩＮＶＩＴＥ」を送ると（図５のｃ１）、ＩＰ−ＰＢＸ１は拡張ＳＩＰプロトコルａ対応端末６に「１００ＴＲＹＩＮＧ」、「ＩＮＦＯ（ＤｉａｌＴｏｎｅ）」を返す（図５のｃ２，ｃ３）。その後、拡張ＳＩＰプロトコルａ対応端末６からＩＰ−ＰＢＸ１に「ＩＮＦＯ（ＤＩＧＩＴ）」が送られてくると（図５のｃ４）、ＩＰ−ＰＢＸ１は標準ＳＩＰプロトコル対応端末５に「ＩＮＶＩＴＥ」を送る（図５のｃ５）。

ＩＰ−ＰＢＸ１は標準ＳＩＰプロトコル対応端末５から「１８０ＲＩＮＧＩＮＧ」が送られてくると（図５のｃ６）、拡張ＳＩＰプロトコルａ対応端末６に「ＩＮＦＯ（ＲｉｎｇＢａｃｋＴｏｎｅ）」、「１８０ＲＩＮＧＩＮＧ」を送る（図５のｃ７，ｃ８）。この後、ＩＰ−ＰＢＸ１は標準ＳＩＰプロトコル対応端末５から「２００ＯＫ」が送られてくると（図５のｃ９）、拡張ＳＩＰプロトコルａ対応端末６に「２００ＯＫ」を送る（図５のｃ１０）。

ＩＰ−ＰＢＸ１は標準ＳＩＰプロトコル対応端末５に「ＡＣＫ」を送り（図５のｃ１１）、拡張ＳＩＰプロトコルａ対応端末６から「ＡＣＫ」を受取る（図５のｃ１２）。これによって、拡張ＳＩＰプロトコルａ対応端末６と標準ＳＩＰプロトコル対応端末５との間は「通話（ＲＴＰ；ＲｅａｌｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）」状態となる（図５のｃ１３）。

ＩＰ−ＰＢＸ１は標準ＳＩＰプロトコル対応端末５から「ＢＹＥ」が送られてくると（図５のｃ１４）、「ｒｅＩＮＶＩＴＥ（ＲＴＰ切）」を拡張ＳＩＰプロトコルａ対応端末６に送り（図５のｃ１５）、「２００ＯＫ」を標準ＳＩＰプロトコル対応端末５に返す（図５のｃ１６）。

ＩＰ−ＰＢＸ１は拡張ＳＩＰプロトコルａ対応端末６から「２００ＯＫ」が返ってくると（図５のｃ１７）、「ＩＮＦＯ（ＢｕｓｙＴｏｎｅ）」を拡張ＳＩＰプロトコルａ対応端末６に送り（図５のｃ１８）、拡張ＳＩＰプロトコルａ対応端末６から呼の切断による「ＢＹＥ」が送られてくると（図５のｃ１９）、「２００ＯＫ」を拡張ＳＩＰプロトコルａ対応端末６に返す（図５のｃ２０）。

ここで、「ＩＮＶＩＴＥ」は参加者間でセッションを確立するために使用されるメソッド、「１００ＴＲＹＩＮＧ」は試行中を示し、「ＩＮＦＯ」は情報を通知する時に使用するメソッド、「１８０ＲＩＮＧＩＮＧ」は呼出中を示し、「２００ＯＫ」は成功応答を示し、「ＡＣＫ」はセッションの確立許可に使用されるメソッド、「ＢＹＥ」はセッションを終了するために使用するメソッドである。

一方、ＩＳＤＮ（ＩｎｔｅｇｒａｔｅｄＳｅｒｖｉｃｅｓＤｉｇｉｔａｌＮｅｔｗｏｒｋ）端末（図示せず）がＩＰ−ＰＢＸ１を介して標準ＳＩＰプロトコル対応端末５に呼接続処理を行う場合、ＩＰ−ＰＢＸ１はＩＳＤＮ端末が発信して「ＳＥＴＵＰ」を送ってくると（図６のｄ１）、標準ＳＩＰプロトコル対応端末５に「ＩＮＶＩＴＥ」を送り（図６のｄ２）、ＩＳＤＮ端末に「ＣＡＬＬＰＲＯＣ」を送る（図６のｄ３）。

ＩＰ−ＰＢＸ１は標準ＳＩＰプロトコル対応端末５から「１８０ＲＩＮＧＩＮＧ」が送られてくると（図６のｄ４）、ＩＳＤＮ端末に「ＡＬＥＲＴ」を送り（図６のｄ５）、標準ＳＩＰプロトコル対応端末５が応答して「２００ＯＫ」を送ってくると（図６のｄ６）、ＩＳＤＮ端末に「ＣＯＮＮ」を送る（図６のｄ７）。これによって、ＩＳＤＮ端末と標準ＳＩＰプロトコル対応端末５との間は「インバウンド」、「通話（ＲＴＰ）」の状態となる（図６のｄ８，ｄ９）。

ＩＰ−ＰＢＸ１はＩＳＤＮ端末から「ＤＩＳＣ」が送られてくると（図６のｄ１０）、標準ＳＩＰプロトコル対応端末５に「ＢＹＥ」を送り（図６のｄ１１）、ＩＳＤＮ端末に「ＲＥＬ」を送る（図６のｄ１２）。この後、ＩＰ−ＰＢＸ１は標準ＳＩＰプロトコル対応端末５から「２００ＯＫ」が、ＩＳＤＮ端末から「ＲＥＬＣＯＭ」がそれぞれ送られてくると（図６のｄ１３，ｄ１４）、処理を終了する。

また、アナログ端末（図示せず）がＩＰ−ＰＢＸ１を介して標準ＳＩＰプロトコル対応端末５に呼接続処理を行う場合、ＩＰ−ＰＢＸ１はアナログ端末が「発信」を送ってくると（図７のｅ１）、標準ＳＩＰプロトコル対応端末５に「ＩＮＶＩＴＥ」を送る（図７のｅ２）。

これによって、標準ＳＩＰプロトコル対応端末５からＩＰ−ＰＢＸ１に対して「１８０ＲＩＮＧＩＮＧ」、「２００ＯＫ」が送られてくると（図７のｅ３，ｅ４）、アナログ端末と標準ＳＩＰプロトコル対応端末５との間は「インバウンド」、「通話（ＲＴＰ；ＲｅａｌｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）」の状態となる（図７のｅ５，ｅ６）。

ＩＰ−ＰＢＸ１はアナログ端末から「切断」が送られてくると（図７のｅ７）、標準ＳＩＰプロトコル対応端末５に「ＢＹＥ」を送る（図７のｅ８）。この後、ＩＰ−ＰＢＸ１は標準ＳＩＰプロトコル対応端末５から「２００ＯＫ」が送られてくると（図７のｅ９）、処理を終了する。

これによって、本実施例では、標準のＳＩＰ端末及び標準のＳＩＰプロキシサーバという組合せのシステムにおいて、その実現のための工数を多く必要とした多彩な既存プロトコルとの接続を柔軟に実現することができ、同時に、現行のＩＰ−ＰＢＸ１が持つ豊富な付加サービスを利用することができる。

また、本実施例では、ＳＩＰプロトコルを拡張した拡張ＳＩＰプロトコルａや拡張ＳＩＰプロトコルｂ等のプロトコルも、上記と同様に、Ｂ２ＢＵＡの仕組みを用いてモジュール化し、ＩＰ−ＰＢＸ１に組込むことによって、標準ＳＩＰプロトコルの範囲では実現が難しい付加サービス等も柔軟に実現することができるとともに、それらの端末に対しても標準ＳＩＰプロトコル端末５はもちろん、既存プロトコル端末との相互接続を提供することができる。

図８は図１のＩＰ−ＰＢＸ１が介在するＤＴＭＦ（ＤｉａｌＴｏｎｅＭｕｌｔｉＦｒｅｑｕｅｎｃｙ）信号送受信能力の交換処理を示すシーケンスチャートである。この図８を参照してＩＰ−ＰＢＸ１が介在するＤＴＭＦ信号送受信能力の交換処理について説明する。

本実施例では、ＤＴＭＦ信号送受信能力の交換処理もＩＰ−ＰＢＸ１が介在して実現する。能力問合せに応答することができない端末については、ＩＰ−ＰＢＸ１が適切な応答を行う。両端の端末はネゴシエーションで確認された手段でＤＴＭＦの送受信を行う。実際のＤＴＭＦ信号送信においては、ＩＰ−ＰＢＸが送信を代行する場合がある。

つまり、端末＃１と端末＃２との間において、メディアパケットがＰｅｅｒ−ｔｏ−Ｐｅｅｒで通信中に（図８のｆ１）、端末＃１からＤＴＭＦ能力問合せが送られてくると（図８のｆ２）、ＩＰ−ＰＢＸ１は端末＃２にＤＴＭＦ能力問合せを送る（図８のｆ３）。

ＩＰ−ＰＢＸ１は端末＃２からＤＴＭＦ能力応答が返ってくると（図８のｆ４）、端末＃１にＤＴＭＦ能力応答を返す（図８のｆ５）。この後、ＤＴＭＦ情報の送受信はネゴシエーション結果に応じて、Ｐｅｅｒ−ｔｏ−ＰｅｅｒまたはＩＰ−ＰＢＸ１経由で行われる（図８のｆ６）。

一方、端末＃２が問合せに応答できない端末の場合、ＩＰ−ＰＢＸ１が端末＃２のＤＴＭＦ能力を代理応答する。つまり、端末＃１からＤＴＭＦ能力問合せが送られてくると（図８のｆ２）、ＩＰ−ＰＢＸ１は端末＃２にＤＴＭＦ能力問合せを送らず、端末＃１にＤＴＭＦ能力応答を返す（図８のｆ５）。この後、ＤＴＭＦ情報の送受信はネゴシエーション結果に応じて、Ｐｅｅｒ−ｔｏ−ＰｅｅｒまたはＩＰ−ＰＢＸ１経由で行われる（図８のｆ６）。

これら一連の処理によって、本実施例では異なるプロトコル端末間でも、ＤＴＭＦ信号の送受信を実現することができる。

このように、本実施例では、ＩＰ−ＰＢＸ１のサービスにＳＩＰに準拠するクライアント端末を組入れることができ、ＳＩＰクライアント端末に対し、現行のＩＰ−ＰＢＸ１がサポートする多様なプロトコルに対応した端末への自由な相互接続を提供するとともに、現行のＩＰ−ＰＢＸ１の持つ豊富な付加サービスを提供することができる。

図９は本発明の他の実施例によるＩＰ−ＰＢＸの構成を示すブロック図である。図９において、本発明の他の実施例によるＩＰ−ＰＢＸ１ａは標準ＳＩＰプロトコル制御モジュール１６と拡張ＳＩＰプロトコルａ制御モジュール１７と拡張ＳＩＰプロトコルｂ制御モジュール１８とにおける共通処理をモジュール化したＳＩＰ系プロトコル共通処理モジュール２０，２１を設けた以外は図２に示す本発明の一実施例によるＩＰ−ＰＢＸ１と同様の構成となっており、同一構成要素には同一符号を付してある。

但し、標準ＳＩＰプロトコル制御モジュール１６、拡張ＳＩＰプロトコルａ制御モジュール１７、拡張ＳＩＰプロトコルｂ制御モジュール１８は共通処理を省いてモジュール化したものである。この共通処理としては、例えばコンタクトインフォメーションを登録するためのＳＩＰ系プロトコルレジストラモジュール２１ａがある。

尚、本実施例では、ＳＩＰ系プロトコル共通処理モジュール２０，２１を、標準ＳＩＰプロトコル制御モジュール１６、拡張ＳＩＰプロトコルａ制御モジュール１７、拡張ＳＩＰプロトコルｂ制御モジュール１８に対してＬＡＮ１００側とＰＢＸ基本接続処理提供モジュール１２側とにそれぞれ設けているが、これらを一つのモジュールで実現することも可能である。

また、上述した本発明の一実施例では標準ＳＩＰプロトコル制御モジュール１６、拡張ＳＩＰプロトコルａ制御モジュール１７、拡張ＳＩＰプロトコルｂ制御モジュール１８にそれぞれポート＃４〜＃６を割当てているが、本実施例ではＳＩＰ系プロトコル共通処理モジュール２０に共通のポート＃ｋを割当てている。

これら一連の処理によって、本実施例では異なるプロトコル端末間でも、ＤＴＭＦ信号の送受信を実現することができる。また、本実施例では、ＩＰ−ＰＢＸ１のサービスにＳＩＰに準拠するクライアント端末を組入れることができ、ＳＩＰクライアント端末に対し、現行のＩＰ−ＰＢＸ１がサポートする多様なプロトコルに対応した端末への自由な相互接続を提供するとともに、現行のＩＰ−ＰＢＸ１の持つ豊富な付加サービスを提供することができる。

本発明は、上記のように、ＬＡＮ等のネットワーク内でのＳＩＰ端末に対する構内交換機のサービスの提供のみならず、インタネット等の外部のＩＰ網を介した呼接続処理にも適用可能である。また、本発明は、ＩＰ網経由でＰＢＸ機能を提供するＩＰセントレックス（ｃｅｎｔｒｅｘ）にも適用可能である。

本発明の一実施例によるネットワークの構成を示すブロック図である。図１のＩＰ−ＰＢＸの構成を示すブロック図である。図１のＩＰ−ＰＢＸの処理動作を示すシーケンスチャートである。図１のＩＰ−ＰＢＸの処理動作を示すシーケンスチャートである。図１のＩＰ−ＰＢＸを介した呼接続処理を示すシーケンスチャートである。図１のＩＰ−ＰＢＸを介した呼接続処理を示すシーケンスチャートである。図１のＩＰ−ＰＢＸを介した呼接続処理を示すシーケンスチャートである。図１のＩＰ−ＰＢＸが介在するＤＴＭＦ信号送受信能力の交換処理を示すシーケンスチャートである。本発明の他の実施例によるＩＰ−ＰＢＸの構成を示すブロック図である。

符号の説明

１，１ａＩＰ−ＰＢＸ
２プロトコルＡ対応端末
３プロトコルＢ対応端末
４プロトコルＸ対応端末
５標準ＳＩＰプロトコル対応端末
６拡張ＳＩＰプロトコルａ対応端末
７拡張ＳＩＰプロトコルｂ対応端末
８メディアゲートウェイ
１１ＰＢＸ付加サービス提供モジュール
１２ＰＢＸ基本接続処理提供モジュール
１３既存プロトコルＡ制御モジュール
１４既存プロトコルＢ制御モジュール
１５既存プロトコルＸ制御モジュール
１６標準ＳＩＰプロトコル制御モジュール
１７拡張ＳＩＰプロトコルａ制御モジュール
１８拡張ＳＩＰプロトコルｂ制御モジュール
１９テーブル
２０，２１ＳＩＰ系プロトコル共通処理モジュール
２１ａＳＩＰ系プロトコルレジストラモジュール
１００ＬＡＮ

Claims

ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）網において相手先との接続を確認して通信を行うコネクション型通信を実現するＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）によって通信を行うＳＩＰ端末と、端末間の呼接続処理を行う構内交換機とを少なくとも含むネットワークであって、
前記構内交換機のコンポーネント群の一つとして組込まれかつ前記ＳＩＰの処理を代理のユーザ・エージェントとして動作するＢ２ＢＵＡ（ＢａｃｋＴｏＢａｃｋＵｓｅｒＡｇｅｎｔ）の仕組みを用いてモジュール化したＳＩＰ系プロトコル制御モジュールを有し、
端末間におけるＤＴＭＦ（ＤｉａｌＴｏｎｅＭｕｌｔｉＦｒｅｑｕｅｎｃｙ）信号送受信能力の交換を前記構内交換機を介在させて実現することを特徴とするネットワーク。
前記ＳＩＰは、ＩＰパケットという形式のデータを用いてマルチメディア通信を開始したり、終了したりするために使用する通信プロトコルであることを特徴とする請求項１記載のネットワーク。
前記ＳＩＰ系プロトコル制御モジュールは、各々異なるプロトコルを持つ複数のＳＩＰ端末各々に対応して配設したことを特徴とする請求項１または請求項２記載のネットワーク。
前記構内交換機は、モジュール化された各プロトコル群に対して相互接続及び付加サービスのうちの少なくとも一方を提供することを特徴とする請求項１から請求項３のいずれか記載のネットワーク。
前記ＤＴＭＦ信号送受信能力の交換が不可の端末における前記ＤＴＭＦ信号の送信を前記構内交換機が代行することを特徴とする請求項１から請求項４のいずれか記載のネットワーク。
端末間の呼接続処理を行う構内交換機であって、
ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）網において相手先との接続を確認して通信を行うコネクション型通信を実現するＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）の処理を代理のユーザ・エージェントとして動作するＢ２ＢＵＡ（ＢａｃｋＴｏＢａｃｋＵｓｅｒＡｇｅｎｔ）の仕組みを用いてモジュール化したＳＩＰ系プロトコル制御モジュールをコンポーネント群の一つとして組込み、
端末間におけるＤＴＭＦ（ＤｉａｌＴｏｎｅＭｕｌｔｉＦｒｅｑｕｅｎｃｙ）信号送受信能力の交換を実現させることを特徴とする構内交換機。
前記ＳＩＰは、ＩＰパケットという形式のデータを用いてマルチメディア通信を開始したり、終了したりするために使用する通信プロトコルであることを特徴とする請求項６記載の構内交換機。
前記ＳＩＰ系プロトコル制御モジュールは、各々異なるプロトコルを持つ複数のＳＩＰ端末各々に対応して配設したことを特徴とする請求項６または請求項７記載の構内交換機。
モジュール化された各プロトコル群に対して相互接続及び付加サービスのうちの少なくとも一方を提供することを特徴とする請求項６から請求項８のいずれか記載の構内交換機。
前記ＤＴＭＦ信号送受信能力の交換が不可の端末における前記ＤＴＭＦ信号の送信を代行することを特徴とする請求項６から請求項９のいずれか記載の構内交換機。
ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）網において相手先との接続を確認して通信を行うコネクション型通信を実現するＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）によって通信を行うＳＩＰ端末と、端末間の呼接続処理を行う構内交換機とを少なくとも含むネットワークのマルチプロトコル通信端末制御方法であって、
代理のユーザ・エージェントとして動作するＢ２ＢＵＡ（ＢａｃｋＴｏＢａｃｋＵｓｅｒＡｇｅｎｔ）の仕組みを用いてモジュール化されかつ前記構内交換機のコンポーネント群の一つとして組込まれたＳＩＰ系プロトコル制御モジュールに前記ＳＩＰの処理を行わせ、
端末間におけるＤＴＭＦ（ＤｉａｌＴｏｎｅＭｕｌｔｉＦｒｅｑｕｅｎｃｙ）信号送受信能力の交換を前記構内交換機を介在させて実現することを特徴とするマルチプロトコル通信端末制御方法。
前記ＳＩＰは、ＩＰパケットという形式のデータを用いてマルチメディア通信を開始したり、終了したりするために使用する通信プロトコルであることを特徴とする請求項１１記載のマルチプロトコル通信端末制御方法。
前記ＳＩＰ系プロトコル制御モジュールを、各々異なるプロトコルを持つ複数のＳＩＰ端末各々に対応して配設したことを特徴とする請求項１１または請求項１２記載のマルチプロトコル通信端末制御方法。
前記構内交換機が、モジュール化された各プロトコル群に対して相互接続及び付加サービスのうちの少なくとも一方を提供することを特徴とする請求項１１から請求項１３のいずれか記載のマルチプロトコル通信端末制御方法。
前記構内交換機が、前記ＤＴＭＦ信号送受信能力の交換が不可の端末における前記ＤＴＭＦ信号の送信を代行することを特徴とする請求項１１から請求項１４のいずれか記載のマルチプロトコル通信端末制御方法。