リソース集中管理方式のネットワーキングにおける音声パス制御とリソースの管理方法及びそのシステム
【課題】異なったシステムの端末間での通話開始までの時間を短縮する。
【解決手段】ネットワーク接続された２システム間で、ＲＴＰプロトコルによる音声通話を行う際の、パス制御及びリソース管理方法において、第１の通話用端末を収容する第１のシステム及び第２の通話用端末を収容する第２のシステムの各々に、端末を制御する実ＥＳＩＵ制御手段とＲＴＰパケットによる音声通話を制御する実ＶｏＩＰ制御手段とを実装し、マスターとなる第３のシステムがスレーブとなる第１及び第２のシステムの各実ＥＳＩＵ制御手段と各実ＶｏＩＰ制御手段とにそれぞれ対応する仮想ＥＳＩＵ制御手段と仮想ＶｏＩＰ制御手段とを実装し、これらの仮想制御手段を介して、第１及び第２のシステムのＶｏＩＰリソースを一元管理し、管理結果に基づいて、第１及び第２のシステムをコマンド制御し、通話パス形成及びＲＴＰ送出を行わせる。
【解決手段】ネットワーク接続された２システム間で、ＲＴＰプロトコルによる音声通話を行う際の、パス制御及びリソース管理方法において、第１の通話用端末を収容する第１のシステム及び第２の通話用端末を収容する第２のシステムの各々に、端末を制御する実ＥＳＩＵ制御手段とＲＴＰパケットによる音声通話を制御する実ＶｏＩＰ制御手段とを実装し、マスターとなる第３のシステムがスレーブとなる第１及び第２のシステムの各実ＥＳＩＵ制御手段と各実ＶｏＩＰ制御手段とにそれぞれ対応する仮想ＥＳＩＵ制御手段と仮想ＶｏＩＰ制御手段とを実装し、これらの仮想制御手段を介して、第１及び第２のシステムのＶｏＩＰリソースを一元管理し、管理結果に基づいて、第１及び第２のシステムをコマンド制御し、通話パス形成及びＲＴＰ送出を行わせる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、異なったシステムにある端末間の通話を開始させるためのリソース集中管理方式のネットワーキングにおける音声パス制御とリソースの管理方法及びそのシステムに関する。
【背景技術】
【０００２】
従来のシステム間の通話手順は、リソース管理を各システムで行う関係上、通話開始手順が煩雑であり、また、時間がかかり、通話開始までに時間がかかることがあった。そのため、出来るだけ簡略な手順で音声パス接続を行う手順が求められていた。
【特許文献１】特開２００５−１５０８６５号公報
【特許文献２】特開２００５−１９７８２６号公報
【特許文献１】特開２００６−０１９９６８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
２システム間で音声通話を行う場合、ＲＴＰというプロトコルに基づいて相互に音声パケットの送出を行う。
【０００４】
このとき、相互にＲＴＰ出力先のＩＰアドレスを知る必要があるが、これは、使用する通話チャネルによってそのつど変わるため、通話を行うたびに求めなければならない。
【０００５】
従来のシステム間での音声通話では、それぞれのシステムがＶｏＩＰの通話チャネルなどのリソース管理を行うため、通話を行うたびに相互にどの通話チャネルを使用するか通知し合わなくてはならず、手順が複雑となり、そのため、通話開始までに時間がかかることもあった。
【０００６】
そこで、本発明は、異なったシステムの端末間での通話開始までの時間を短縮することを目的とする。
【課題を解決するための手段】
【０００７】
本発明では、一台のマスター主装置となるシステムが通話チャネルなどのＶｏＩＰリソースを一元管理することにより、上記の問題を回避する。
【０００８】
すなわち、マスター主装置システムが、通話を行う両システムのＶｏＩＰチャネルをすべて管理、把握するため、通話パスを接続する際にも相互のシステムで使用する通話チャネルを通知しあう必要はない。
【発明の効果】
【０００９】
ＲＴＰを出力する際の手順が簡略化され、相互で通信を行わなくても即座にＲＴＰを出力し、通話を行うことが出来る。
【００１０】
また、従来の接続処理に比べて非常に簡単化された処理で音声通話を実現することが出来、また、通話成立後、即座にＲＴＰパケットの送出を指示できるため、通話開始までのオーバーヘッドが少ない。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照して本発明を実施するための実施例について詳細に説明する。
【実施例１】
【００１２】
まず、基本となる構成例について説明する。
【００１３】
本構成例のポイントは、ネットワーク上にあるリソースを自分のリソースのように扱う技術にある。
【００１４】
プログラム制御により動作する主装置では、ハードウェアのリソース管理、すなわち、端末、回線等の管理をパッケージ管理という形で行っている。
【００１５】
したがって、ネットワーク上のリソースを自分のリソースであるかのように扱うためにはネットワーク上のパッケージをあたかも自分のパッケージであるかのように扱うことができればよい。
【００１６】
図１にネットワーク間のパッケージ管理の概念図を示す。
【００１７】
主装置２にパッケージをインストールしたとき、パッケージの情報と、それに接続されている端末や回線等の情報はイーサネット（登録商標）経由で主装置１に伝達される。
【００１８】
一方、主装置２では、それらの情報は一切、パッケージ制御部や呼制御部に伝わらないため、主装置２としては、何も状況に変化があったようには見えない。
【００１９】
主装置１は、主装置２から上がってくるデータを下位のレイヤーで処理し、あたかも、自分のスロットから情報があがってきたかのように見せるため、主装置１としては、自分のスロットにパッケージが刺さったように見える。
【００２０】
また、パッケージに対する指示（下りデータ）に関しても、下位のレイヤーで処理し、仮想パッケージに対する指示は、ネットワーク上にある実パッケージに伝達する。
【００２１】
以上の仕組みを導入することにより、ネットワーク上のリソースをあたかも自分のリソースであるかのように扱うことが可能になる。
【００２２】
したがって、呼制御などの上位のレイヤーでは、ネットワーク上であることを意識することなく、リソースを自由に使用できる。
【００２３】
図２に、本構成例によるネットワーキングの構成図を示す。
【００２４】
ネットワーク上の全リソースを管理し、全ての呼制御を行う主装置をマスターと呼ぶ。
【００２５】
他方、マスターに接続し、パッケージ情報を提供し、マスターからの指示にしたがう主装置をスレーブと呼ぶ。
【００２６】
本構成例によるネットワーキングを行うためには、ネットワークを構成する複数の主装置の中で一台の主装置がマスターになる必要がある。スレーブは全てマスターに接続し、その指示に従い、自分では一切、呼制御等の処理を行わない。すなわち、スレーブが呼制御などを行うための機能部を持っていたとしても、これらは休止状態となる。
【００２７】
マスターは複数のスレーブを制御することができ、スレーブとして接続された主装置のリソースを全て自分のもののように扱うことができる。
【００２８】
以上によって、マスターと、スレーブにより構成されたネットワークがあたかも一つのシステムであるかのように振舞うことができる。
【００２９】
どの主装置がマスター、またはスレーブになるかといった情報、また、それぞれどのＩＰアドレスで接続されているかという情報はあらかじめ設定が必要である。
【００３０】
マスターとして設定された主装置は、スレーブの接続を待ち、スレーブは、あらかじめ設定されたマスターのＩＰアドレスに対し、接続を行う。
【００３１】
このようにして、マスターとスレーブの接続が確立されたあと、パッケージ情報の伝達等が行われ、ネットワークとして動作するようになる。
【００３２】
また、マスターが万が一、ダウンしたとき、これに接続する全ての主装置が利用不可能になってしまう。これを防ぐために、マスターがダウンしたときは、１又は複数のスレーブのうちの一つがマスターになり、マスターの役割を代行する(Redundancy)。
【００３３】
マスターがダウンしたとき、どのスレーブが代行するかという情報は、あらかじめ設定をしておく必要がある。
【００３４】
次に、ネットワーク上のリソースの集中管理を行うための具体的方法について説明する。
【００３５】
図３にネットワーキングにおけるシステム構成を示す。
【００３６】
ネットワーク上にマスターは唯一つ存在し、全てのスレーブを制御する。
【００３７】
ネットワーク上で各システムを識別するために、各システムはそれぞれシステムＩＤという重複しない値を持つ。
【００３８】
図４に、本構成例におけるスロット管理の概念図を示す。
【００３９】
ネットワークに接続する、システムＩＤを持つ各システムには、スロットに物理的にパッケージがインストールされているが、これらの情報は、仮想スロットデータベースとして、一元的にまとめられ、マスターシステムで管理される。
【００４０】
マスターは、この仮想スロットデータベースを参照してスロットを制御する。
【００４１】
他システムのスロットであれば、物理的なスロットは、ＩＰ網で接続された遠隔地に存在するが、マスターは、遠隔地にある物理スロットを意識することなく、あたかもそれが自分のスロットであるかのように扱うことができる。
【００４２】
したがって、そのスロットにインストールされたパッケージに接続された端末、回線も自システムに接続された端末、回線と同じように扱うことができる。
【００４３】
これを表した図を図５に示す。
【００４４】
システムＩＤ：１のシステムには、端末を接続するパッケージ、システムＩＤ：２のシステムには、公衆回線に接続する回線を収容するパッケージ、システム：３のシステムには、ＩＰネットワークに接続するＩＰ回線を収容するパッケージがそれぞれインストールされている。
【００４５】
これらの物理的なスロットは、仮想スロットとして管理されているので、スロットに接続するパッケージに収容された端末、回線等を自システム同様、自由に制御できる。
【００４６】
以上の方法によって、ネットワークに分散したシステムであっても制限なく主装置の機能を利用することができる。
【００４７】
図５で示した各システムは、図３にあらわされるように、一台のマスターがそれ以外のスレーブを制御するサーバー・クライアント型の構成となっており、マスターが、自システム含め、全ての主装置の呼処理、データベース管理を行う。また、仮想スロットの管理もマスターが行う。
【００４８】
各システムはＩＰで接続されており、各システムを識別するためにそれぞれ固有のシステムＩＤを持つ。
【００４９】
システム１には、端末を収容するパッケージ、システム２には、通常回線を収容するパッケージ、システム３には、ＩＰ回線を収容するパッケージがそれぞれ収容されている。
【００５０】
これらは、仮想スロットデータベースで情報が管理されている。このデータは、基本的にマスターで管理されるが、マスターが交代したときのために、各スレーブでも同一のデータを保持している。
【００５１】
図５で示した実施例について、データの流れの観点から説明を加える。
【００５２】
図６は、従来のパッケージ制御のデータの流れを示したものである。
【００５３】
図６のように、パッケージからの上りデータは、スロットＩ／Ｆモジュール１０１から、ＩＯＣＳ（入出力制御モジュール）１０３を介し、ＣＡＰＳ（呼制御モジュール）／ＯＰＭＳ（パッケージ、端末管理モジュール）１０５に送られる。
【００５４】
そして、ＣＡＰＳ／ＯＰＭＳ１０５でデータが処理され、ＩＯＣＳ１０３を介して、スロットＩ／Ｆモジュール１０１に下りの指示が行われる。たとえば、パッケージがインストールされたとき、上りデータとして、ＯＰＭＳ１０５にデータが送られ、パッケージがインストールされたことを認識し、パッケージに対し、立ち上げを許可するという、パッケージの起動制御や、スロットにインストールされたパッケージに接続された端末がオフフックした場合なども、上りデータとして、ＣＡＰＳ１０５にオフフックした旨を伝え、ＣＡＰＳ１０５はそれを受け、端末にダイヤルトーンを出すコマンドを、ＩＯＣＳ１０３経由で下りデータとして送出する、などである。
【００５５】
図６では、スロットＩ／Ｆ１０１からのデータを直接、入力データとして上位モジュールに上げているので、当然、自システムに接続されたスロットしか制御できない。
【００５６】
図７に、本実施例におけるデータの流れを示す。
【００５７】
図７の通り、スロットの入出力を制御するスロット制御モジュール１０７と、スロット情報を管理するスロット管理モジュール１０９を新たに追加することで、ネットワークを介したスロット管理を実現する。
【００５８】
スロットからの上りデータは、一旦、スロット制御モジュール１０７にスプールされ、自システムの属するマスターのスロット管理モジュール１０９に送られる。自身がマスターである場合は、自身のスロット管理モジュール１０９に送られる。スロット管理モジュール１０９に送られたデータは、上位モジュールであるＩＯＣＳ１０３に対し、データをある特定のスロットからデータが上がってきたかのように見せる。
【００５９】
ここで、図８を示し、スロット管理モジュール１０９の動作について、説明を加える。
【００６０】
スロット管理モジュール１０９は、ある特定のシステムの特定のスロットからデータを受け取ったとき、もし、それが、いままでに認識していないシステムのスロットであった場合、新たに仮想的なスロット番号をアサインし、以後、そのシステムのスロットを、アサインした仮想的なスロット番号のスロットとして扱う。
【００６１】
たとえば、システム１のスロット１より上りデータがあがってきた場合、それがいままでに認識していないスロットであった場合、仮想スロットとしてスロット１をアサインする。
【００６２】
このようにして、新たに仮想スロットをアサインしたとき、図８のような物理スロット／仮想スロット対照表１１１を作成していく。
【００６３】
以後、システム１のスロット１よりあがってきたデータは、ＩＯＣＳ、ＣＡＰＳ等の上位モジュールでは、自システムのスロット１であるかのように扱われ、ネットワークを意識する必要すらなくなる。
【００６４】
実際に、スロットに下りデータを送出し、ハードウェアに指示を出すときは、物理スロット／仮想スロット対照表１１１を参照して、適切なシステムのスロットに対して指示を出す。
【００６５】
その指示は、各システムのスロット制御モジュール１０７に届けられ、各システムの実際のパッケージに対してコマンドが送られる。
【００６６】
以上のように、ネットワーク上のスロットを制御、管理するモジュールを導入することで、主装置の処理の大部分では、ネットワークを意識する必要がなく、あたかも、自分のシステムを制御するかのようにハードウェアを制御することが可能となる。
【００６７】
なお、仮想スロットの個数については、物理スロットのようにハードウェア的な制限がなく、システムのメモリが許す限り、無限にアサインすることが可能である。
【００６８】
また、システムの内部的には、通常、仮想スロット番号で処理がされるが、システムデータの設定など、ユーザーの目に見える部分では、どのシステムのどのスロットなのか識別したい場合がある。
【００６９】
その場合には、物理スロット／仮想スロット対照表１１１を参照して、物理スロットで設定等を行うことができる。
【００７０】
以上、基本となる構成例についての説明を終える。
【００７１】
次に、本題となる発明の実施例について説明をする。
【００７２】
本発明は、基本となる構成における音声リソース管理とパス制御について効率よく行う方法を提供するものである。
【００７３】
本発明は、上記の基本となる構成に基づき、音声通話を実現する。
【００７４】
図９は、その発明により、パッケージを管理する方法を示している。
【００７５】
ここで、ＶｏＩＰと表記されているものは、音声をＲＴＰパケットに変換して相手のポートに送出する機能を有するハードウェアであり、
ＥＳＩＵはＤｔｅｒｍなどの端末を制御するハードウェアである。
【００７６】
（Ｐ）と表記されているものは、物理的にそのパッケージが実装されていることを意味し、（Ｖ）と表記されているものは、基本となる構成に基づき、仮想的にそのパッケージがインストールされていることを意味している。
【００７７】
この仮想スロットの情報は、ネットワーク上でのマスター主装置となるシステムで管理されるため、マスター主装置は、接続するすべてのスレーブ主装置となるシステムのパッケージ情報を、あたかも自分のもののように扱うことが出来る。
【００７８】
したがって、ＶｏＩＰのリソースのチャネル使用状態や、そのチャネルのタイムスロット、ＥＳＩＵに接続する端末のポートや、そのポートのタイムスロットなどもマスター主装置となるシステムがすべて知ることができ、他システムのものでありながら、あたかも自分のシステムであるかのようにリソース管理、パス制御を行うことが出来る。
【００７９】
図１０にスレーブ主装置間でのレガシー端末（Ｄｔｅｒｍ）同士の通話イメージを示す。
【００８０】
システム１は、マスター主装置として機能し、接続するスレーブ主装置システムであるシステム２、３のスロット情報を仮想スロットとしてすべて把握している。また、マスター主装置のＣＰＵ上で呼処理も動作しており、端末間が通話状態になったことを検出することが出来る。
【００８１】
ＩＰ網を用いて通話を行う場合、図のようにＶｏＩＰ←→ＥＳＩＵ間でのハイウェイ接続と、お互いのＶｏＩＰチャネルへのＲＴＰ接続を行う必要がある。
【００８２】
ハイウェイ接続を行うためには、使用するＶｏＩＰチャネルのタイムスロットと、端末の接続するＥＳＩＵのタイムスロットを求める必要があり、ＲＴＰを出力するには相手のＶｏＩＰチャネルのＩＰアドレス、ポート番号を求める必要がある。
【００８３】
相手のＶｏＩＰチャネルのＩＰアドレス、ポート番号は、相手の使用するＶｏＩＰチャネルから求めることが出来る。
【００８４】
以上を踏まえ、スレーブ主装置のレガシー端末間での通話処理を図の番号に従い説明していく。
【００８５】
［１］ ＶｏＩＰリソースの予約と、スレーブ主装置に対するＲＴＰ送出、ハイウェイ接続の指示（マスター主装置での処理）。
【００８６】
マスター主装置で端末間が通話状態になったことを認識。システム間の通話になるかどうか判定する。
【００８７】
システム間の通話であるので、ＶｏＩＰリソースを使用した通話になると判断する（ここで、マスター主装置内部の端末同士もしくは、スレーブ主装置内部の端末同士の通話であればＶｏＩＰは不要）。
【００８８】
ＶｏＩＰリソースを使う際、まず各システムで使用するＶｏＩＰリソースを予約する。
【００８９】
このとき、予約するＶｏＩＰリソースは、それを使用する端末の属するシステムのものである必要があるので、そうなるようマスター主装置は各システムのＶｏＩＰリソースを予約する。
【００９０】
ここで、マスター主装置は、スロット情報をすべて把握しているため、予約したＶｏＩＰチャネルから、ＶｏＩＰチャネルのタイムスロットを求め、端末の接続するＥＳＩＵのタイムスロットを求めることが出来る。
【００９１】
また、双方で使用するＶｏＩＰチャネルが分かるため、ＲＴＰ出力先のＩＰアドレス、ポート番号も求めることが出来る。
【００９２】
［２］、［２’］ スレーブ主装置システムに対するハイウェイ接続、ＲＴＰ出力の指示（マスター主装置での処理）。
【００９３】
［１］において求めたＶｏＩＰチャネルのタイムスロット、端末のタイムスロット、ＲＴＰ出力先ＩＰアドレス、ポート番号をスレーブ主装置システムに通知し、ハイウェイ接続、ＲＴＰ出力を各スレーブ主装置に指示する。
【００９４】
［３］、［３’］ ＲＴＰの出力（スレーブ主装置での処理）
各スレーブ主装置において、［２］でマスター主装置により通知されたＩＰアドレス、ポート番号をもとに相手システムのＶｏＩＰチャネルに対し、ＲＴＰを出力する。
【００９５】
［４］、［４’］ ハイウェイ接続（スレーブ主装置での処理）
各スレーブ主装置において、［２］でマスター主装置により通知されたタイムスロットをもとに、ＶｏＩＰチャネル←→端末間でハイウェイを接続する。
【００９６】
以上のように、基本的にマスター主装置がすべて処理を行い、スレーブ主装置にＲＴＰ送出、ハイウェイ接続の指示を行うことでシステム間での通話を実現する。
【００９７】
マスター主装置は、スレーブ主装置のパッケージ情報をすべて保持しており、すべての処理を自らのＣＰＵで行うため、以上見てきたように非常にシンプルな処理でシステム間の通話を実現することが出来る。
【００９８】
図２において、システム１、２、３は、それぞれＩＰ網で接続された主装置であり、システム１がマスター主装置システムとして機能、システム２、３は、スレーブ主装置システムとして機能している。
【００９９】
マスター主装置には、なにもパッケージがインストールされていないが、スレーブ主装置であるシステム２、３にはシステム間通話用にＶｏＩＰ、端末接続用にＥＳＩＵがインストールされている。
【０１００】
各ＥＳＩＵには、それぞれ一台ずつのレガシー端末が接続されている。
【０１０１】
上述したように、マスター主装置となる主装置は、通話を行う両システムのリソース情報を一元管理するため、双方のシステムのＲＴＰ出力先ＩＰアドレス、ポート番号が分かり、双方のシステムにＲＴＰ出力を指示することが出来る。スレーブ主装置となるシステムはマスター主装置の指示に従い、実際のＶｏＩＰのハードウェアに対し、そのコマンドを転送するだけでいい。
【０１０２】
同様に、ＶｏＩＰとＥＳＩＵ間の接続すべきタイムスロットも分かるため、双方のシステムにハイウェイ接続を指示し、スレーブ主装置もそのコマンドに従うだけでいい。
【０１０３】
これによって、両Ｄｔｅｒｍ間で通話パスが確立し、通話を行うことが出来る。
【図面の簡単な説明】
【０１０４】
【図１】本発明の実施例による、仮想パッケージを用いて、他の主装置の実パッケージを自主装置の実パッケージとして扱う様子を示す図である。
【図２】本発明の実施例によるマスター主装置とスレーブ主装置の接続例を示す図である。
【図３】本発明の実施例によるマスター主装置とスレーブ主装置の他の接続例を示す図である。
【図４】本発明の実施例による仮想スロットと物理スロットとの対応関係を示す図である。
【図５】本発明の実施例による仮想スロットと物理スロットとの対応関係及び各物理スロットの接続先の例を示す図である。
【図６】従来例によるＣＡＰＳ／ＯＰＭＳ、ＩＯＣＳ及びスロットインターフェースとの接続関係を示す図である。
【図７】本発明の実施例によるＣＡＰＳ／ＯＰＭＳ、ＩＯＣＳ、スロット管理モジュール、物理スロット／仮想スロット対照表、スロット制御モジュール及びスロットインターフェースとの接続関係を示す図である。
【図８】本発明の実施例による物理スロット／仮想スロット対照表の具体例を示す図である。
【図９】本発明の実施例によるマスター主装置とスレーブ主装置と端末との間の接続関係を示す図である。
【図１０】本発明の実施例による通話開始のための手順を説明するための図である。
【符号の説明】
【０１０５】
１０１ システムインターフェース
１０３ ＩＯＣＳ（入出力制御モジュール）
１０５ ＣＡＰＳ（呼制御モジュール）／ＯＰＭＳ（パッケージ、端末管理モジュール）
１０７ スロット制御モジュール
１０９ スロット管理モジュール
１１１ 物理スロット／管理スロット対照表
【技術分野】
【０００１】
本発明は、異なったシステムにある端末間の通話を開始させるためのリソース集中管理方式のネットワーキングにおける音声パス制御とリソースの管理方法及びそのシステムに関する。
【背景技術】
【０００２】
従来のシステム間の通話手順は、リソース管理を各システムで行う関係上、通話開始手順が煩雑であり、また、時間がかかり、通話開始までに時間がかかることがあった。そのため、出来るだけ簡略な手順で音声パス接続を行う手順が求められていた。
【特許文献１】特開２００５−１５０８６５号公報
【特許文献２】特開２００５−１９７８２６号公報
【特許文献１】特開２００６−０１９９６８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
２システム間で音声通話を行う場合、ＲＴＰというプロトコルに基づいて相互に音声パケットの送出を行う。
【０００４】
このとき、相互にＲＴＰ出力先のＩＰアドレスを知る必要があるが、これは、使用する通話チャネルによってそのつど変わるため、通話を行うたびに求めなければならない。
【０００５】
従来のシステム間での音声通話では、それぞれのシステムがＶｏＩＰの通話チャネルなどのリソース管理を行うため、通話を行うたびに相互にどの通話チャネルを使用するか通知し合わなくてはならず、手順が複雑となり、そのため、通話開始までに時間がかかることもあった。
【０００６】
そこで、本発明は、異なったシステムの端末間での通話開始までの時間を短縮することを目的とする。
【課題を解決するための手段】
【０００７】
本発明では、一台のマスター主装置となるシステムが通話チャネルなどのＶｏＩＰリソースを一元管理することにより、上記の問題を回避する。
【０００８】
すなわち、マスター主装置システムが、通話を行う両システムのＶｏＩＰチャネルをすべて管理、把握するため、通話パスを接続する際にも相互のシステムで使用する通話チャネルを通知しあう必要はない。
【発明の効果】
【０００９】
ＲＴＰを出力する際の手順が簡略化され、相互で通信を行わなくても即座にＲＴＰを出力し、通話を行うことが出来る。
【００１０】
また、従来の接続処理に比べて非常に簡単化された処理で音声通話を実現することが出来、また、通話成立後、即座にＲＴＰパケットの送出を指示できるため、通話開始までのオーバーヘッドが少ない。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照して本発明を実施するための実施例について詳細に説明する。
【実施例１】
【００１２】
まず、基本となる構成例について説明する。
【００１３】
本構成例のポイントは、ネットワーク上にあるリソースを自分のリソースのように扱う技術にある。
【００１４】
プログラム制御により動作する主装置では、ハードウェアのリソース管理、すなわち、端末、回線等の管理をパッケージ管理という形で行っている。
【００１５】
したがって、ネットワーク上のリソースを自分のリソースであるかのように扱うためにはネットワーク上のパッケージをあたかも自分のパッケージであるかのように扱うことができればよい。
【００１６】
図１にネットワーク間のパッケージ管理の概念図を示す。
【００１７】
主装置２にパッケージをインストールしたとき、パッケージの情報と、それに接続されている端末や回線等の情報はイーサネット（登録商標）経由で主装置１に伝達される。
【００１８】
一方、主装置２では、それらの情報は一切、パッケージ制御部や呼制御部に伝わらないため、主装置２としては、何も状況に変化があったようには見えない。
【００１９】
主装置１は、主装置２から上がってくるデータを下位のレイヤーで処理し、あたかも、自分のスロットから情報があがってきたかのように見せるため、主装置１としては、自分のスロットにパッケージが刺さったように見える。
【００２０】
また、パッケージに対する指示（下りデータ）に関しても、下位のレイヤーで処理し、仮想パッケージに対する指示は、ネットワーク上にある実パッケージに伝達する。
【００２１】
以上の仕組みを導入することにより、ネットワーク上のリソースをあたかも自分のリソースであるかのように扱うことが可能になる。
【００２２】
したがって、呼制御などの上位のレイヤーでは、ネットワーク上であることを意識することなく、リソースを自由に使用できる。
【００２３】
図２に、本構成例によるネットワーキングの構成図を示す。
【００２４】
ネットワーク上の全リソースを管理し、全ての呼制御を行う主装置をマスターと呼ぶ。
【００２５】
他方、マスターに接続し、パッケージ情報を提供し、マスターからの指示にしたがう主装置をスレーブと呼ぶ。
【００２６】
本構成例によるネットワーキングを行うためには、ネットワークを構成する複数の主装置の中で一台の主装置がマスターになる必要がある。スレーブは全てマスターに接続し、その指示に従い、自分では一切、呼制御等の処理を行わない。すなわち、スレーブが呼制御などを行うための機能部を持っていたとしても、これらは休止状態となる。
【００２７】
マスターは複数のスレーブを制御することができ、スレーブとして接続された主装置のリソースを全て自分のもののように扱うことができる。
【００２８】
以上によって、マスターと、スレーブにより構成されたネットワークがあたかも一つのシステムであるかのように振舞うことができる。
【００２９】
どの主装置がマスター、またはスレーブになるかといった情報、また、それぞれどのＩＰアドレスで接続されているかという情報はあらかじめ設定が必要である。
【００３０】
マスターとして設定された主装置は、スレーブの接続を待ち、スレーブは、あらかじめ設定されたマスターのＩＰアドレスに対し、接続を行う。
【００３１】
このようにして、マスターとスレーブの接続が確立されたあと、パッケージ情報の伝達等が行われ、ネットワークとして動作するようになる。
【００３２】
また、マスターが万が一、ダウンしたとき、これに接続する全ての主装置が利用不可能になってしまう。これを防ぐために、マスターがダウンしたときは、１又は複数のスレーブのうちの一つがマスターになり、マスターの役割を代行する(Redundancy)。
【００３３】
マスターがダウンしたとき、どのスレーブが代行するかという情報は、あらかじめ設定をしておく必要がある。
【００３４】
次に、ネットワーク上のリソースの集中管理を行うための具体的方法について説明する。
【００３５】
図３にネットワーキングにおけるシステム構成を示す。
【００３６】
ネットワーク上にマスターは唯一つ存在し、全てのスレーブを制御する。
【００３７】
ネットワーク上で各システムを識別するために、各システムはそれぞれシステムＩＤという重複しない値を持つ。
【００３８】
図４に、本構成例におけるスロット管理の概念図を示す。
【００３９】
ネットワークに接続する、システムＩＤを持つ各システムには、スロットに物理的にパッケージがインストールされているが、これらの情報は、仮想スロットデータベースとして、一元的にまとめられ、マスターシステムで管理される。
【００４０】
マスターは、この仮想スロットデータベースを参照してスロットを制御する。
【００４１】
他システムのスロットであれば、物理的なスロットは、ＩＰ網で接続された遠隔地に存在するが、マスターは、遠隔地にある物理スロットを意識することなく、あたかもそれが自分のスロットであるかのように扱うことができる。
【００４２】
したがって、そのスロットにインストールされたパッケージに接続された端末、回線も自システムに接続された端末、回線と同じように扱うことができる。
【００４３】
これを表した図を図５に示す。
【００４４】
システムＩＤ：１のシステムには、端末を接続するパッケージ、システムＩＤ：２のシステムには、公衆回線に接続する回線を収容するパッケージ、システム：３のシステムには、ＩＰネットワークに接続するＩＰ回線を収容するパッケージがそれぞれインストールされている。
【００４５】
これらの物理的なスロットは、仮想スロットとして管理されているので、スロットに接続するパッケージに収容された端末、回線等を自システム同様、自由に制御できる。
【００４６】
以上の方法によって、ネットワークに分散したシステムであっても制限なく主装置の機能を利用することができる。
【００４７】
図５で示した各システムは、図３にあらわされるように、一台のマスターがそれ以外のスレーブを制御するサーバー・クライアント型の構成となっており、マスターが、自システム含め、全ての主装置の呼処理、データベース管理を行う。また、仮想スロットの管理もマスターが行う。
【００４８】
各システムはＩＰで接続されており、各システムを識別するためにそれぞれ固有のシステムＩＤを持つ。
【００４９】
システム１には、端末を収容するパッケージ、システム２には、通常回線を収容するパッケージ、システム３には、ＩＰ回線を収容するパッケージがそれぞれ収容されている。
【００５０】
これらは、仮想スロットデータベースで情報が管理されている。このデータは、基本的にマスターで管理されるが、マスターが交代したときのために、各スレーブでも同一のデータを保持している。
【００５１】
図５で示した実施例について、データの流れの観点から説明を加える。
【００５２】
図６は、従来のパッケージ制御のデータの流れを示したものである。
【００５３】
図６のように、パッケージからの上りデータは、スロットＩ／Ｆモジュール１０１から、ＩＯＣＳ（入出力制御モジュール）１０３を介し、ＣＡＰＳ（呼制御モジュール）／ＯＰＭＳ（パッケージ、端末管理モジュール）１０５に送られる。
【００５４】
そして、ＣＡＰＳ／ＯＰＭＳ１０５でデータが処理され、ＩＯＣＳ１０３を介して、スロットＩ／Ｆモジュール１０１に下りの指示が行われる。たとえば、パッケージがインストールされたとき、上りデータとして、ＯＰＭＳ１０５にデータが送られ、パッケージがインストールされたことを認識し、パッケージに対し、立ち上げを許可するという、パッケージの起動制御や、スロットにインストールされたパッケージに接続された端末がオフフックした場合なども、上りデータとして、ＣＡＰＳ１０５にオフフックした旨を伝え、ＣＡＰＳ１０５はそれを受け、端末にダイヤルトーンを出すコマンドを、ＩＯＣＳ１０３経由で下りデータとして送出する、などである。
【００５５】
図６では、スロットＩ／Ｆ１０１からのデータを直接、入力データとして上位モジュールに上げているので、当然、自システムに接続されたスロットしか制御できない。
【００５６】
図７に、本実施例におけるデータの流れを示す。
【００５７】
図７の通り、スロットの入出力を制御するスロット制御モジュール１０７と、スロット情報を管理するスロット管理モジュール１０９を新たに追加することで、ネットワークを介したスロット管理を実現する。
【００５８】
スロットからの上りデータは、一旦、スロット制御モジュール１０７にスプールされ、自システムの属するマスターのスロット管理モジュール１０９に送られる。自身がマスターである場合は、自身のスロット管理モジュール１０９に送られる。スロット管理モジュール１０９に送られたデータは、上位モジュールであるＩＯＣＳ１０３に対し、データをある特定のスロットからデータが上がってきたかのように見せる。
【００５９】
ここで、図８を示し、スロット管理モジュール１０９の動作について、説明を加える。
【００６０】
スロット管理モジュール１０９は、ある特定のシステムの特定のスロットからデータを受け取ったとき、もし、それが、いままでに認識していないシステムのスロットであった場合、新たに仮想的なスロット番号をアサインし、以後、そのシステムのスロットを、アサインした仮想的なスロット番号のスロットとして扱う。
【００６１】
たとえば、システム１のスロット１より上りデータがあがってきた場合、それがいままでに認識していないスロットであった場合、仮想スロットとしてスロット１をアサインする。
【００６２】
このようにして、新たに仮想スロットをアサインしたとき、図８のような物理スロット／仮想スロット対照表１１１を作成していく。
【００６３】
以後、システム１のスロット１よりあがってきたデータは、ＩＯＣＳ、ＣＡＰＳ等の上位モジュールでは、自システムのスロット１であるかのように扱われ、ネットワークを意識する必要すらなくなる。
【００６４】
実際に、スロットに下りデータを送出し、ハードウェアに指示を出すときは、物理スロット／仮想スロット対照表１１１を参照して、適切なシステムのスロットに対して指示を出す。
【００６５】
その指示は、各システムのスロット制御モジュール１０７に届けられ、各システムの実際のパッケージに対してコマンドが送られる。
【００６６】
以上のように、ネットワーク上のスロットを制御、管理するモジュールを導入することで、主装置の処理の大部分では、ネットワークを意識する必要がなく、あたかも、自分のシステムを制御するかのようにハードウェアを制御することが可能となる。
【００６７】
なお、仮想スロットの個数については、物理スロットのようにハードウェア的な制限がなく、システムのメモリが許す限り、無限にアサインすることが可能である。
【００６８】
また、システムの内部的には、通常、仮想スロット番号で処理がされるが、システムデータの設定など、ユーザーの目に見える部分では、どのシステムのどのスロットなのか識別したい場合がある。
【００６９】
その場合には、物理スロット／仮想スロット対照表１１１を参照して、物理スロットで設定等を行うことができる。
【００７０】
以上、基本となる構成例についての説明を終える。
【００７１】
次に、本題となる発明の実施例について説明をする。
【００７２】
本発明は、基本となる構成における音声リソース管理とパス制御について効率よく行う方法を提供するものである。
【００７３】
本発明は、上記の基本となる構成に基づき、音声通話を実現する。
【００７４】
図９は、その発明により、パッケージを管理する方法を示している。
【００７５】
ここで、ＶｏＩＰと表記されているものは、音声をＲＴＰパケットに変換して相手のポートに送出する機能を有するハードウェアであり、
ＥＳＩＵはＤｔｅｒｍなどの端末を制御するハードウェアである。
【００７６】
（Ｐ）と表記されているものは、物理的にそのパッケージが実装されていることを意味し、（Ｖ）と表記されているものは、基本となる構成に基づき、仮想的にそのパッケージがインストールされていることを意味している。
【００７７】
この仮想スロットの情報は、ネットワーク上でのマスター主装置となるシステムで管理されるため、マスター主装置は、接続するすべてのスレーブ主装置となるシステムのパッケージ情報を、あたかも自分のもののように扱うことが出来る。
【００７８】
したがって、ＶｏＩＰのリソースのチャネル使用状態や、そのチャネルのタイムスロット、ＥＳＩＵに接続する端末のポートや、そのポートのタイムスロットなどもマスター主装置となるシステムがすべて知ることができ、他システムのものでありながら、あたかも自分のシステムであるかのようにリソース管理、パス制御を行うことが出来る。
【００７９】
図１０にスレーブ主装置間でのレガシー端末（Ｄｔｅｒｍ）同士の通話イメージを示す。
【００８０】
システム１は、マスター主装置として機能し、接続するスレーブ主装置システムであるシステム２、３のスロット情報を仮想スロットとしてすべて把握している。また、マスター主装置のＣＰＵ上で呼処理も動作しており、端末間が通話状態になったことを検出することが出来る。
【００８１】
ＩＰ網を用いて通話を行う場合、図のようにＶｏＩＰ←→ＥＳＩＵ間でのハイウェイ接続と、お互いのＶｏＩＰチャネルへのＲＴＰ接続を行う必要がある。
【００８２】
ハイウェイ接続を行うためには、使用するＶｏＩＰチャネルのタイムスロットと、端末の接続するＥＳＩＵのタイムスロットを求める必要があり、ＲＴＰを出力するには相手のＶｏＩＰチャネルのＩＰアドレス、ポート番号を求める必要がある。
【００８３】
相手のＶｏＩＰチャネルのＩＰアドレス、ポート番号は、相手の使用するＶｏＩＰチャネルから求めることが出来る。
【００８４】
以上を踏まえ、スレーブ主装置のレガシー端末間での通話処理を図の番号に従い説明していく。
【００８５】
［１］ ＶｏＩＰリソースの予約と、スレーブ主装置に対するＲＴＰ送出、ハイウェイ接続の指示（マスター主装置での処理）。
【００８６】
マスター主装置で端末間が通話状態になったことを認識。システム間の通話になるかどうか判定する。
【００８７】
システム間の通話であるので、ＶｏＩＰリソースを使用した通話になると判断する（ここで、マスター主装置内部の端末同士もしくは、スレーブ主装置内部の端末同士の通話であればＶｏＩＰは不要）。
【００８８】
ＶｏＩＰリソースを使う際、まず各システムで使用するＶｏＩＰリソースを予約する。
【００８９】
このとき、予約するＶｏＩＰリソースは、それを使用する端末の属するシステムのものである必要があるので、そうなるようマスター主装置は各システムのＶｏＩＰリソースを予約する。
【００９０】
ここで、マスター主装置は、スロット情報をすべて把握しているため、予約したＶｏＩＰチャネルから、ＶｏＩＰチャネルのタイムスロットを求め、端末の接続するＥＳＩＵのタイムスロットを求めることが出来る。
【００９１】
また、双方で使用するＶｏＩＰチャネルが分かるため、ＲＴＰ出力先のＩＰアドレス、ポート番号も求めることが出来る。
【００９２】
［２］、［２’］ スレーブ主装置システムに対するハイウェイ接続、ＲＴＰ出力の指示（マスター主装置での処理）。
【００９３】
［１］において求めたＶｏＩＰチャネルのタイムスロット、端末のタイムスロット、ＲＴＰ出力先ＩＰアドレス、ポート番号をスレーブ主装置システムに通知し、ハイウェイ接続、ＲＴＰ出力を各スレーブ主装置に指示する。
【００９４】
［３］、［３’］ ＲＴＰの出力（スレーブ主装置での処理）
各スレーブ主装置において、［２］でマスター主装置により通知されたＩＰアドレス、ポート番号をもとに相手システムのＶｏＩＰチャネルに対し、ＲＴＰを出力する。
【００９５】
［４］、［４’］ ハイウェイ接続（スレーブ主装置での処理）
各スレーブ主装置において、［２］でマスター主装置により通知されたタイムスロットをもとに、ＶｏＩＰチャネル←→端末間でハイウェイを接続する。
【００９６】
以上のように、基本的にマスター主装置がすべて処理を行い、スレーブ主装置にＲＴＰ送出、ハイウェイ接続の指示を行うことでシステム間での通話を実現する。
【００９７】
マスター主装置は、スレーブ主装置のパッケージ情報をすべて保持しており、すべての処理を自らのＣＰＵで行うため、以上見てきたように非常にシンプルな処理でシステム間の通話を実現することが出来る。
【００９８】
図２において、システム１、２、３は、それぞれＩＰ網で接続された主装置であり、システム１がマスター主装置システムとして機能、システム２、３は、スレーブ主装置システムとして機能している。
【００９９】
マスター主装置には、なにもパッケージがインストールされていないが、スレーブ主装置であるシステム２、３にはシステム間通話用にＶｏＩＰ、端末接続用にＥＳＩＵがインストールされている。
【０１００】
各ＥＳＩＵには、それぞれ一台ずつのレガシー端末が接続されている。
【０１０１】
上述したように、マスター主装置となる主装置は、通話を行う両システムのリソース情報を一元管理するため、双方のシステムのＲＴＰ出力先ＩＰアドレス、ポート番号が分かり、双方のシステムにＲＴＰ出力を指示することが出来る。スレーブ主装置となるシステムはマスター主装置の指示に従い、実際のＶｏＩＰのハードウェアに対し、そのコマンドを転送するだけでいい。
【０１０２】
同様に、ＶｏＩＰとＥＳＩＵ間の接続すべきタイムスロットも分かるため、双方のシステムにハイウェイ接続を指示し、スレーブ主装置もそのコマンドに従うだけでいい。
【０１０３】
これによって、両Ｄｔｅｒｍ間で通話パスが確立し、通話を行うことが出来る。
【図面の簡単な説明】
【０１０４】
【図１】本発明の実施例による、仮想パッケージを用いて、他の主装置の実パッケージを自主装置の実パッケージとして扱う様子を示す図である。
【図２】本発明の実施例によるマスター主装置とスレーブ主装置の接続例を示す図である。
【図３】本発明の実施例によるマスター主装置とスレーブ主装置の他の接続例を示す図である。
【図４】本発明の実施例による仮想スロットと物理スロットとの対応関係を示す図である。
【図５】本発明の実施例による仮想スロットと物理スロットとの対応関係及び各物理スロットの接続先の例を示す図である。
【図６】従来例によるＣＡＰＳ／ＯＰＭＳ、ＩＯＣＳ及びスロットインターフェースとの接続関係を示す図である。
【図７】本発明の実施例によるＣＡＰＳ／ＯＰＭＳ、ＩＯＣＳ、スロット管理モジュール、物理スロット／仮想スロット対照表、スロット制御モジュール及びスロットインターフェースとの接続関係を示す図である。
【図８】本発明の実施例による物理スロット／仮想スロット対照表の具体例を示す図である。
【図９】本発明の実施例によるマスター主装置とスレーブ主装置と端末との間の接続関係を示す図である。
【図１０】本発明の実施例による通話開始のための手順を説明するための図である。
【符号の説明】
【０１０５】
１０１ システムインターフェース
１０３ ＩＯＣＳ（入出力制御モジュール）
１０５ ＣＡＰＳ（呼制御モジュール）／ＯＰＭＳ（パッケージ、端末管理モジュール）
１０７ スロット制御モジュール
１０９ スロット管理モジュール
１１１ 物理スロット／管理スロット対照表
【特許請求の範囲】
【請求項１】
ネットワーク接続された２システム間で、ＲＴＰプロトコルによる音声通話を行う際の、パス制御及びリソース管理方法において、
第１の通話用端末を収容する第１のシステム及び第２の通話用端末を収容する第２のシステムの各々に、端末を制御する実ＥＳＩＵ制御手段とＲＴＰパケットによる音声通話を制御する実ＶｏＩＰ制御手段とを実装し、
マスターとなる第３のシステムがスレーブとなる第１及び第２のシステムの各実ＥＳＩＵ制御手段と各実ＶｏＩＰ制御手段とにそれぞれ対応する仮想ＥＳＩＵ制御手段と仮想ＶｏＩＰ制御手段とを実装し、
これらの仮想制御手段を介して、第１及び第２のシステムのＶｏＩＰリソースを一元管理し、
管理結果に基づいて、第１及び第２のシステムをコマンド制御し、通話パス形成及びＲＴＰ送出を行わせることを特徴とするパス制御及びリソース管理方法。
【請求項２】
ネットワーク接続された２システム間で、ＲＴＰプロトコルによる音声通話を行う際の、パス制御及びリソース管理方法において、
第１の通話用端末を収容する第１のシステム及び第２の通話用端末を収容する第２のシステムの各々に、端末を制御する実ＥＳＩＵ制御手段とＲＴＰパケットによる音声通話を制御する実ＶｏＩＰ制御手段とを実装し、
マスターとなる第３のシステムがスレーブとなる第１及び第２のシステムの各実ＥＳＩＵ制御手段と各実ＶｏＩＰ制御手段とにそれぞれ対応する仮想ＥＳＩＵ制御手段と仮想ＶｏＩＰ制御手段とを実装し、
これらの仮想制御手段を介して、第１及び第２のシステムのＶｏＩＰリソースを一元管理し、
管理結果に基づいて、第１及び第２のシステムをコマンド制御し、通話パス形成及びＲＴＰ送出を行わせることを特徴とするパス制御及びリソース管理システム。
【請求項１】
ネットワーク接続された２システム間で、ＲＴＰプロトコルによる音声通話を行う際の、パス制御及びリソース管理方法において、
第１の通話用端末を収容する第１のシステム及び第２の通話用端末を収容する第２のシステムの各々に、端末を制御する実ＥＳＩＵ制御手段とＲＴＰパケットによる音声通話を制御する実ＶｏＩＰ制御手段とを実装し、
マスターとなる第３のシステムがスレーブとなる第１及び第２のシステムの各実ＥＳＩＵ制御手段と各実ＶｏＩＰ制御手段とにそれぞれ対応する仮想ＥＳＩＵ制御手段と仮想ＶｏＩＰ制御手段とを実装し、
これらの仮想制御手段を介して、第１及び第２のシステムのＶｏＩＰリソースを一元管理し、
管理結果に基づいて、第１及び第２のシステムをコマンド制御し、通話パス形成及びＲＴＰ送出を行わせることを特徴とするパス制御及びリソース管理方法。
【請求項２】
ネットワーク接続された２システム間で、ＲＴＰプロトコルによる音声通話を行う際の、パス制御及びリソース管理方法において、
第１の通話用端末を収容する第１のシステム及び第２の通話用端末を収容する第２のシステムの各々に、端末を制御する実ＥＳＩＵ制御手段とＲＴＰパケットによる音声通話を制御する実ＶｏＩＰ制御手段とを実装し、
マスターとなる第３のシステムがスレーブとなる第１及び第２のシステムの各実ＥＳＩＵ制御手段と各実ＶｏＩＰ制御手段とにそれぞれ対応する仮想ＥＳＩＵ制御手段と仮想ＶｏＩＰ制御手段とを実装し、
これらの仮想制御手段を介して、第１及び第２のシステムのＶｏＩＰリソースを一元管理し、
管理結果に基づいて、第１及び第２のシステムをコマンド制御し、通話パス形成及びＲＴＰ送出を行わせることを特徴とするパス制御及びリソース管理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２００９−１０４８１（Ｐ２００９−１０４８１Ａ）
【公開日】平成２１年１月１５日（２００９．１．１５）
【国際特許分類】
【出願番号】特願２００７−１６７６４９（Ｐ２００７−１６７６４９）
【出願日】平成１９年６月２６日（２００７．６．２６）
【出願人】（０００２２７２０５）ＮＥＣインフロンティア株式会社 (1,047)
【Ｆターム（参考）】
【公開日】平成２１年１月１５日（２００９．１．１５）
【国際特許分類】
【出願日】平成１９年６月２６日（２００７．６．２６）
【出願人】（０００２２７２０５）ＮＥＣインフロンティア株式会社 (1,047)
【Ｆターム（参考）】
[ Back to top ]