JP4410907B2

JP4410907B2 - 音声呼管理制御方法およびそのためのゲートウェイ装置

Info

Publication number: JP4410907B2
Application number: JP2000099665A
Authority: JP
Inventors: 雄二 ▲高▼橋
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2000-03-31
Filing date: 2000-03-31
Publication date: 2010-02-10
Anticipated expiration: 2020-03-31
Also published as: US20010036190A1; JP2001285342A; US6950425B2

Description

【０００１】
【発明の属する技術分野】
本発明は、音声呼管理制御方法およびその方法に用いるゲートウェイ装置に関する。
従来の音声系ネットワークにおける通信においては、特定の回線交換経路を介して音声情報のやりとりが行われている。いわゆる電話交換網がその代表例である。
【０００２】
このような通信は、音声のようにリアルタイム性が必要とされる用途には最適な方法であると共に、通話品質ということが重要視される場合に有効な方法である。
一方、上記電話交換網のような音声系ネットワークとは別の形態のネットワークとして、インターネットやイントラネット等に代表されるデータ系ネットワークがある。このデータ系ネットワークにおける通信は、上記音声系ネットワークとは反対に、いかに多量のデータを伝送するかということと、いかに伝送ルートの最適化ならびに効率化を図るかということを重要視する場合に有効な方法である。この方法に基づくネットワークとして最も広く利用されているのがＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ（ＩＰ）ネットワークである。
【０００３】
これまで、上記音声系ネットワークとデータ系ネットワークとはそれぞれ独立の通信方式のもとで運用されてきたが、近年これらの通信方式を融合させる技術が次々と確立し始めてきている。例えば、ＶｏｉｃｅｏｖｅｒＦＲ（ＶｏＦＲ）、ＶｏｉｃｅｏｖｅｒＡＴＭ（ＶｏＡＴＭ）、ＶｏｉｃｅｏｖｅｒＩＰ（ＶｏＩＰ）等が、その融合技術としてよく知られている。そしてこの中でもとりわけＶｏＩＰ技術が注目を浴びている。
【０００４】
その理由は、第１に、パソコン（ＰＣ）とアプリケーションソフトウェアが広く普及してきたことと、そのＰＣとアプリケーションソフトウェアを使ったインターネットが普及したことに起因してＩＰネットワークの環境が充実してきたこと、第２に、そのＩＰネットワークによるデータと音声の統合効果により、通信コストが大幅に低減したこと、を挙げることができる。
【０００５】
かくして、ＶｏＩＰ技術を基盤としたいわゆる統合ネットワークの構築が一層加速しているのが現状である。本発明はかかる状況のもとで、ＩＰネットワークに応用して特に有効な、音声呼管理制御方法について述べる。
【０００６】
【従来の技術】
図１４の（ａ）は一般的な音声系ネットワークのシステム構成を、（ｂ）は一般的なデータ系ネットワークのシステム構成をそれぞれ示す図である。
本図の、一般的な音声系ネットワーク（ａ）では、配下に電話機１（＃１）を有するＰＢＸ２（＃１）と、同じく配下に電話機１（＃２）を有するＰＢＸ２（＃２）とが、公衆網３または専用線網４を介して、接続し、電話機１（＃１）と電話機１（＃２）との間で音声通話を行う。
【０００７】
一方、本図の、一般的なデータ系ネットワーク（ｂ）では、配下にパソコン（ＰＣ）５を有する伝送装置６（＃１）と、配下にホスト８を有する伝送装置６（＃２）とが、専用線網７を介して、接続し、パソコン（ＰＣ）５とホスト８との間でデータ通信を行う。
このように、従来は、音声系ネットワーク（電話交換網）と、データ系ネットワーク（ＩＰネットワーク）とが２分化して別々に存在していた。
【０００８】
ところが既述したＶｏＩＰ技術の進展に伴って、音声情報をＩＰパケットに乗せて伝送する技術が発展し、ここに、２分化された上記の音声系およびデータ系のネットワークは、一つに統合され、広く統合ネットワークが構築されるに至った。
図１５はＶｏＩＰ技術を基盤とした、一般的なＩＰネットワークの一構成例を示す図である。なお全図を通じて、同様の構成要素には同一の参照番号または記号を付して示す。
【０００９】
本図において、１１＃１は一方の幹線系（例えば東京地区本社）、１１＃２は他方の幹線系（例えば大阪地区本社）であり、これらの幹線系１１＃１および１１＃２はそれぞれのゲートウェイ装置（ＧＷ）１２＃１および１２＃２を介して、大容量の専用線１４によって結ばれる。
一方の幹線系１１＃１とその配下の各支線系１６（＃１，＃２…）とは、それぞれのゲートウェイ装置（ＧＷ）１２＃１および１７を介して、専用線１５＃１によって結ばれる。
【００１０】
同様に、他方の幹線系１１＃２とその配下の各支線系１６（…＃９，＃１０）とは、それぞれのゲートウェイ装置（ＧＷ）１２＃２および１７を介して、専用線１５＃２によって結ばれる。
幹線系１１＃１内は、前述した、電話機１＃１を有するＰＢＸ２＃１と、ＰＣ５＃１と、ゲートウェイ装置（ＧＷ）１２＃１とが、ＬＡＮ１３＃１によって結ばれている。
【００１１】
幹線系１１＃２内も同様に、前述した、電話機１＃２を有するＰＢＸ２＃２と、ＰＣ５＃２と、ゲートウェイ装置（ＧＷ）１２＃２とが、ＬＡＮ１３＃２によって結ばれている。
このような幹線系１１＃１，＃２の構成は、基本的に各支線系１６（＃１，＃２…＃９，＃１０）についても同様であり、各ゲートウェイ装置（ＧＷ）１７と、ＰＢＸ１８と、ＰＣ１９とが、ＬＡＮ（点線で示す）によって結ばれる。
【００１２】
図１５に一構成例を示す、音声系とデータ系とをＶｏＩＰ技術により統合したＩＰネットワークにおいて、本発明に係る音声呼管理制御方法と密接な関連を有するのは、幹線系１１のゲートウェイ装置（ＧＷ）１２であり、また、支線系１６のゲートウェイ装置（ＧＷ）１７である。なお、以下の説明は、幹線系のゲートウェイ装置に主として着目して行うが、支線系のゲートウェイ装置も同様に考えることができる。
【００１３】
図１６は一般的なゲートウェイ装置の一構成例を示す図である。
従来の一般的なゲートウェイ装置２０は、ＬＡＮ（１３）を制御するためのＬＡＮ制御部２１と、相手方のゲートウェイ装置との間で専用線１４によるサービスを受けるための回線制御を行うＷＡＮ制御部２３と、プログラムを含む所要の各種データを格納するメモリ部２４と、種々のサービスメニューを提示したり各種障害情報を表示するディスプレイ／ＬＥＤ部２５と、ゲートウェイ装置２０に対する各種パラメータ（局データ等）が、例えばＲＳ２３２Ｃのポートを介して外部ＰＣより設定される外部Ｉ／Ｆ（インタフェース）部２６と、共通バス２７を介して装置２０全体の制御を司る、ＣＰＵを含む制御部２２とからなる。
【００１４】
【発明が解決しようとする課題】
上記ゲートウェイ装置２０の制御のもとで、専用線１４および相手方ゲートウェイ装置を介して、例えば、電話機１＃１および電話機１＃２の間で通話を行っている場合、音声呼パケットの遅延やパケットロスに起因して、音声が遅れて到達したり、会話が途切れ途切れになったりして、既述したリアルタイム性や一定の通話品質が保てなくなり、正常な会話状態が成立しない、という問題が生じている。
【００１５】
通常、統合ネットワークにおいては、伝送路をいかに効率的に使用するかを主眼において技術革新がなされてきており、一例としてはＲＳＶＰ（ＩｎｔＳｅｒｖ）、ＤｉｆｆＳｅｒｖなる帯域確保技術により、ＩＰネットワークにおける通信状態の確保を行っている。
ところが一方、実際にはネットワーク環境によっては、上記の帯域確保技術が使えない場合も数多く存在する。これは、ＩＰネットワーク内にある全ての、ルータ等を含むゲートウェイ装置間でその帯域確保機能を持っていなくてはならず、インターネット等の場合においては、どこでどのように音声パケットがルーティングされて行くかわからないため、結局は、上記の問題が発生してしまう。
【００１６】
また、上記のＶｏＩＰ技術をもとにした通信においては、呼の管理を行うためのＧａｔｅＫｅｅｐｅｒ（図１５のＧＫ参照）を経由して通信を行う場合があるが、音声呼のみの管理という観点からは、ＩＰネットワーク状態を監視することができるが、データ呼の管理まで管理しているものはあまりないし、また例えあったとしても、上記Ｇａｔｅｋｅｅｐｅｒを用いて通信を行うことが標準規格上必須とはなっていないため、結局は、上記に示す問題が発生することになる。
【００１７】
したがって本発明は上記問題点に鑑み、通話のリアルタイム性と一定の通話品質とを常に保つことができるようにした音声呼管理制御方法と、その方法を実施するためのゲートウェイ装置とを提供することを目的とするものである。
【００１８】
【課題を解決するための手段】
ＶｏＩＰ技術を基盤とする音声系とデータ系の統合ネットワークにおいて、しばしば音声呼パケットの遅延やパケットロスに起因して、通話のリアルタイム性や一定の通話品質が保てなくなる場合がしばしば発生し、その原因について分析したところ次のような現象が明らかになった。
【００１９】
統合ネットワーク内のあるゲートウェイ装置１２＃１から他の対向ゲートウェイ装置１２＃２に音声呼パケットを伝送する場合、連続する２つの手順を必要とする。第１の手順はシグナリング情報をなす音声呼パケットを送信する手順であり、通信確立のための手順である。これにより伝送パスが張られると、次に第２の手順が開始する。この手順は、その伝送パスを介して、本来の音声情報をなす音声呼パケットを送信する手順であり、ここに会話状態が開始する。
【００２０】
上記の第１および第２の手順は、上記伝送パスが有する空き通信帯域に比べて上記音声呼パケットの所要帯域が少ない場合には、共に成立し、問題なく上記会話状態に達しその会話状態を正常に維持できる。
逆に、上記の第１および第２の手順は、上記の空き通信帯域に比べて上記の音声呼パケットの所要帯域が多い場合には、共に成立せず、上記伝送パスは張れず、上記会話状態にも到達し得ない。
【００２１】
問題は、上記第１の手順は成立しても、上記第２の手順は成立しない場合がある、ということである。この原因は、上記シグナリング情報をなす音声呼パケットの所要帯域と上記音声情報をなす音声呼パケットとの間のアンバランスにある。すなわち、音声情報のパケット伝送に要する所要帯域に比べてシグナリング情報のパケット伝送に要する所要帯域は少ない。経験的には、これらの所要帯域の比は、１．５〜２対１である。
【００２２】
そうすると、これらの所要帯域の差により、上記第１の手順は成立しても上記第２の手順は不成立ということが起こり得る。このような場合、通信確立手順を通じて、相手先にシグナリング情報が届き、その後の接続ネゴシエーションさえ完了してしまえば、通信は確立し、通話状態にまで達する。
この場合は、空き通信帯域に余裕はないとは言え、所要帯域の少ないシグナリング情報によって通信状態にまでは達し得ただけであり、その後の、所要帯域の多い音声情報にとっては最早通信帯域は不十分であり、結局、正常な会話状態は維持できないことになる。この結果、上記のリアルタイム性や一定の通話品質が失なわれてしまうことになる。本発明は上述した分析結果に着眼してなされたものである。
【００２３】
図１は本発明に係る方法の基本ステップを示す図である。
音声系とデータ系の統合ネットワークにおける、本発明に基づく音声呼管理制御方法は、図１に示す第１、第２および第３ステップ（Ｓ１１，Ｓ１２，Ｓ１３）からなる。
第１ステップＳ１１：前記統合ネットワーク内の第１ゲートウェイ装置１２＃１に入力されるパケットが音声呼パケットか否かを識別する。
【００２４】
第２ステップＳ１２：第１ステップＳ１１において、音声呼パケットであると識別されたとき、対向する第２ゲートウェイ装置１２＃２との間の伝送パスが有する空き通信帯域と当該音声呼パケットの所要帯域とに基づき、当該音声呼パケットがその伝送パスを通過可能か否かの判定を行う。
第３ステップＳ１３：通過可能と判定されたときのみ、当該音声呼パケットを前記第２ゲートウェイ装置に転送する。
【００２５】
図２は本発明に係るゲートウェイ装置の基本構成図である。上述した図１のステップＳ１１〜Ｓ１３は、図２のゲートウェイ装置３０によって、実施可能である。
図２を参照すると、音声系のデータ系の統合ネットワーク内の、本発明に係るゲートウェイ装置３０は、少なくとも、図示する識別手段３１と判定手段３２とを有している。好ましくは、さらにメモリ手段３３を有してなる。なお、図２のゲートウェイ装置３０は、図１６のゲートウェイ装置２０に対応するが、図２では、本発明に特徴的な手段（３１，３２，３３）のみを明示する。これら識別手段３１および判定手段３２は、図１６の制御部２２内にソフトウェアにより形成することができる。また、メモリ手段３３は、図１６のメモリ部２４として形成することができる。
【００２６】
具体的には、識別手段３１は、ゲートウェイ装置１２＃１に入力されるパケットが音声呼パケットか否かを識別する。
また、判定手段３２は、識別手段３１において音声呼パケットであると識別されたとき、対向する他のゲートウェイ装置１２＃２との間の伝送パスが有する通信帯域と当該音声呼パケットの所要帯域とに基づき、当該音声呼パケットが該伝送パスを通過可能か否かの判定を行う。
【００２７】
さらにまた上記のメモリ手段３３は、識別手段３１による識別または判定手段３２による判定を行うために参照される所定のパラメータを保持する。
したがって再び上記図１を参照すると、第１ゲートウェイ装置１２＃１内のメモリ手段３３に保持された上記所定のパラメータを参照して、第１または第２ステップ（Ｓ１，Ｓ１２）を実行することになる。
【００２８】
【発明の実施の形態】
図３は本発明が適用される統合ネットワークの一構成例を示す図である。ただし図１５に示したＩＰネットワークの構成とほぼ同じである。図１５と相違するのは、第１ゲートウェイ装置（ＧＷ）１２＃１と第２ゲートウェイ装置（ＧＷ）１２＃２との間の専用線１４の部分を、図解的に描き改めたことである。
【００２９】
すなわち、専用線１４上で形成される伝送パスを参照番号１０としてパイプ（通信帯域）で表し、このパイプを占有しているデータの部分（音声系とデータ系の双方を含む）をハッチングを付して表す。本図の例では、最大許容通信帯域を全て使い切っておらず、空き通信帯域ＡＢ（ＡｖａｉｌａｂｌｅＢａｎｄ）が存在している。
【００３０】
新たに音声呼パケットが幹線系１１＃１（あるいは該幹線系１１＃１の配下にある支線系１６）内において発生したとすると、ゲートウェイ装置（ＧＷ）１１＃１は、まず、その入力されたパケットが音声呼パケットであるか否か識別する。この場合該パケットは音声呼パケットであるから、これを識別する。
この識別後、ゲートウェイ装置（ＧＷ）１１＃１は、最初に入力されてくるシグナリング情報（図中の〈１〉）が、伝送パス１０の空き通信帯域ＡＢを通過できるか否か判定する。この判定により、通過可能と分かると、次に入力されてくる音声情報が同様にその空き通信帯域ＡＢを通過できるか否か判定する。この判定により通過可能と分かると、両ゲートウェイ装置（１１＃１，１１＃２）間に通話パスが確立され、会話状態に入る。
【００３１】
図４はゲートウェイ装置３０の具体的構成例を示す図である。
本図に示すとおり、その基本ブロック構成は、図１６に示した構成と変わらないが、主として制御部２２については、その内部構成が変更されている。すなわち、識別部４１および解析部４２が、既述の識別手段３１として、形成され、伝送パス帯域管理部４３が、既述の判定手段３２として、形成される。また、メモリ部２４にはさらにパラメータ情報ならびにルーティング情報が保持されて、既述のメモリ手段３３となる。
【００３２】
図５は本発明のゲートウェイ装置により実行される主要なステップとこれに関連するステップとを示すフローチャートである。
本図において、ステップＳ１１，Ｓ１２およびＳ１３は、図１に示したＳ１１，Ｓ１２およびＳ１３に対応する。
ステップＳ２１：ユーザが幹線系内（あるいは支線系内）の電話機１より、相手先の電話番号をダイヤルしたものとする。
【００３３】
ステップＳ２２：そのダイヤル情報は、対応するＰＢＸ２（もしくはゲートウェイ装置３０の入力段）においてＩＰパケット化される。
ステップＳ２３：他のユーザがパソコン（ＰＣ）５より、ホスト８に向けてデータを転送しているものとする。このデータもＩＰパケット化されている。
上記ステップにより、ゲートウェイ装置３０に入力されたＩＰパケットは、まず、ステップＳ２４に入る。
【００３４】
ステップＳ２４：図４の識別部４１において、その入力されたＩＰパケットが音声呼パケットか否か判定する。
このステップＳ２４においては、メモリ部２４内に保持されたパラメータ情報を参照する。この“パラメータ”は、入力されたパケットのヘッダ部分に記述される情報要素であり、当該パケットの属性等を示す。最も大事なのは、当該パケットが音声呼パケットか否かを示す情報要素である。
【００３５】
具体的には、上記パラメータは、ゲートウェイ装置３０に入力されるパケットの、ＩＰソースアドレス、ＴＣＰ／ＩＰ、ＲＴＰ、ＵＤＰの各ポート番号、およびＴＯＳ値の少なくとも１つである。このパラメータに基づき、ステップＳ２４を実行する。メモリ部２４は、好ましくは、これら全てのパラメータを保持する。ここに、ＴＣＰ／ＩＰは、ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ／ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ、
ＲＴＰは、Ｒｅａｌ−ｔｉｍｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ、
ＵＤＰは、ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ、
ＴＯＳは、ＴｉｍｅＯｆＳｅｒｖｉｃｅであり、いずれも周知である。
【００３６】
メモリ部２４内のパラメータ情報としては、音声呼パケットであることを表示する特定のＩＰソースアドレスやＴＣＰ／ＩＰ、ＲＴＰ等が記述されており、これらのパラメータのいずれかに一致する入力パケットがあれば、これは音声呼パケットであると識別される。図５において、
ステップＳ２５：ステップＳ２４により識別された、シグナリング情報をなす音声呼パケットの所要帯域に基づき、このシグナリング情報が伝送パス１０を通過可能か否かの判定を行う。
【００３７】
ステップＳ２６：通過可能と判定されると、音声情報をなす音声呼パケットの所要帯域に基づき、この音声情報が伝送パス１０を通過可能か否かの判定を行う。
ステップＳ２７：上記ステップＳ２５とＳ２６の結果が共にＹｅｓであると、通話状態となり、このときは、リアルタイム性と一定の通話品質とを保った会話が行える。
【００３８】
再び上記ステップＳ２４（識別）についてもう少し詳しく考察すると、その識別を実行する際の上述のパラメータを、メモリ部２４内に保持するために事前入力するが、この入力は外部インタフェース部２６から行うことができる。
しかしながら、入力される音声呼パケットの全てが、そのメモリ部２４内のパラメータのいずれかと必ず一致するとは限らない。すなわち、メモリ部２４に未登録のパラメータもあり得る。このような未登録のパラメータを有する音声呼パケットは、その次に来るステップＳ２５およびＳ２６による判定が受けられず、本発明による効果を得ることができない。
【００３９】
そこで、メモリ部２４に未登録のパラメータを有するパケットが出現したときは、これは解析部４２にて解析し、音声呼パケットを表すものであることが判明したらメモリ部２４にそのパラメータを登録し、パラメータ情報を増やす。すなわち、識別手段３１をなすその解析部４２は、上記の識別を実行する際のパラメータを、音声呼パケットがゲートウェイ装置３０を通過するときにその音声呼パケットの情報要素を解析することにより割り出し、これをメモリ手段をなすメモリ部２４内に蓄積して保持する。
【００４０】
これにより当該音声呼パケットが次回ゲートウェイ装置３０に入力されるときには、ステップＳ２４による識別で音声呼パケットであるものと認定され、引き続く、ステップＳ２５およびＳ２６による判定を受けることができる。
解析部４２により解析される上記の情報要素としては、例えば、当該音声呼パケットの「パケット長」があり、所定のパケット長であることを検出して、メモリ部２４に蓄積されるパラメータとしてさらに加える。
【００４１】
また上記ステップＳ２６について考察すると、音声情報が伝送パスを通過可能か否かの判定に用いるパラメータとして、例えば、当該音声呼パケットの通信スループット情報を用いることができ、このパラメータに基づき該ステップＳ２６を実行することができる。
図６は図５のステップＳ２６の変形態様を示す図である。
【００４２】
本図に示すとおり、ステップＳ２６での判定は、
ステップＳ３１：音声呼パケットの伝送パス１０への通過を許可するか、
ステップＳ３２：その通過を制限するか、または、
ステップＳ３３：その通過許可の待ち受けとするか、のいずれかの判定である。
【００４３】
上記ステップＳ３１とＳ３２はそれぞれ、図５のステップＳ２７とＳ２８に相当するので、ステップＳ３３が新たなステップである。このステップＳ３３を利用して新たなサービスをユーザに提供することができる。これを図７に示す。
図７は図６のステップＳ３３の応用例を示す図である。
図７によれば、通信予約のステップＳ４１をさらに含み、ステップＳ２６での判定が、伝送パス１０への通過許可の待ち受けとする判定であるとき（ステップＳ３３）、その通信予約を行い、該通過許可の発行（ステップＳ２６とＹｅｓ）と同時に当該音声呼パケットの送信を行う（ステップＳ４２）。
【００４４】
ユーザはトラヒックの輻輳が終了したら即座に発呼したい場合がある。このような要求に応えるために通信予約を可能とし、この予約があったときは、ステップＳ２６で通過許可が出次第、待ちとなっていた音声呼パケットを送信開始することができる。なおこの予約は、ユーザからの操作によりゲートウェイ装置３０に対して行うことができる。予約の有無は、メモリ部２４に一時的に記録しておけばよい。
【００４５】
以上、本発明に係る音声呼管理制御方法とゲートウェイ装置について述べてきたが、最後に、上述の説明に関連する詳細例について述べておく。
図８はシグナリング情報についてその詳細例を示す図である。
すなわちシグナリング情報伝送時のＩＰパケット（音声呼パケット）のフィールドを一例として示す図である。
【００４６】
図中のＩＰは最下位のレイヤ、ＴＣＰはその上のレイヤ、ＵＤＰはさらにその上のレイヤにそれぞれ対応する。これをさらに詳しく図９〜１１において示す。
図９はＩＰヘッダフィールドの詳細例を示す図であり、
図１０はＴＣＰヘッダフィールドの詳細例を示す図であり、
図１１はＵＤＰヘッダフィールドの詳細例を示す図である。
【００４７】
これら図９〜１１において、左下がりハッチングの部分は、既述のパラメータのうち、識別部４１（図４）による識別（図５のステップＳ２４参照）のために特に有用な情報要素であり、これを見ることにより入力されたパケットが音声呼パケットか否かを識別できる。
一方、右下がりハッチングの部分は、既述のパラメータのうち、解析部４２（図４）による解析に用いることのできるパラメータであり、そのパケット長（“トータル長”）を見て、音声呼パケットであると解析できる。そして当該音声呼パケットのヘッダから得た情報要素、ＩＰソースアドレス、ＴＣＰ／ＩＰ…等をメモリ部２４に登録することができる。このトータル長は例えば音声呼パケットの場合８０byteである。
【００４８】
図１２は図４内でのパケットの動きと処理を図解的に表す図である。
本図において、（１）〜（５）は処理の流れを示す。また簡単のため３つのパケットＡ，Ｂ，Ｃのみを示す。
先ずは、ＬＡＮ制御部２１へ入力されＩＰパケットのＩＰソースアドレス／ポート番号／ＴＯＳ値等を識別部４１で見て、音声呼パケットかどうか識別を行う。
【００４９】
例えば、メモリ部２４からそれらのパラメータを参照し、その比較を行い、音声呼パケットと判断する。このとき、既にメモリ部２４にパラメータが登録済の場合は何も処理しないが、新規の音声呼パケットであれば解析部４２により、既述のパケット長を調べて、そのＩＰソースアドレス／ポート番号／ＴＯＳ値をメモリ部２４に登録し、累積する。
【００５０】
図１２の伝送パス帯域管理部４３について見ると、メモリ部２４に対しては事前にＩＰアドレス等と送付先との関係等を示すルーティング情報を格納しておく必要がある（図４の“ルーティング情報”）。
また、音声呼パケットのフィールド帯域は予め、圧縮方式等から一義的にその容量が決まっているので、このことを利用して、予めルーティングテーブルを作るとき、音声呼という観点から所要帯域はこれだけ必要になるという情報も入れておくことにより、１つの音声呼の所要帯域は決まってくる。音声呼の通信であれば、そのパケット個数により伝送パス使用帯域は決定できる。また、データ呼の場合は、通信中のスループットを測定することにより、伝送パス使用帯域は分かる。
【００５１】
以上の構成のもとで、図３に示す統合ネットワーク内で実現される通信シーケンスは図１３のようになる。
図１３は図３において実現される通信シーケンスを表す図である。
本図では、上半分に「通信可」の場合のシーケンスを、下半分に「通信不可」の場合のシーケンスをそれぞれ示す。
【００５２】
支線系１６よりＰＢＸ＃ａ１を通してシグナリング（発呼）が発生すると、ＧＷ＃１内で、音声呼パケットの識別や伝送パスを通過可能か否かの判定が行われ、その判定の結果、通過可能ということであれば（帯域ＯＫ）、その旨のシグナリングをＰＢＸ＃ａ１（応答）に返す。これと共に、相手方ＰＢＸ＃ｂ１０へシグナリング（発呼）を送り込む。相手方が着呼すると、その旨のシグナリング（応答）を、ＲＢＴ（ＲｉｎｇＢａｃｋＴｏｎｅ）として、ＰＢＸ＃ａ１に返す。ここで音声通話が開始する。このときの会話においては、リアルタイム性と一定の通話品質が確保される。
【００５３】
本図の後半では、伝送パスを通過することが可能でないとの判定が出され、シグナリング（応答）として、帯域ＮＧを伝えるＢＴ（ＢｕｓｙＴｏｎｅ）が当該ユーザに与えられる。ユーザはトラヒックの輻輳が回避された後、再発呼する。
【００５４】
【発明の効果】
以上説明したように本発明によれば、トラヒックの輻輳時において、通話を開始するときから、リアルタイム性や一定の通話品質を失うような劣悪な通話状態に陥ってしまうようなことが未燃に防止され、ＩＰネットワークのエンドユーザに快適な通話サービスを提供することができる。また必要であれば、そのような劣悪な通話状態から脱したことをゲートウェイ装置で検出して、保留していた発呼動作を自動的に再スタートさせることもできる。
【図面の簡単な説明】
【図１】本発明に係る方法の基本ステップを示す図である。
【図２】本発明に係るゲートウェイ装置の基本構成図である。
【図３】本発明が適用される統合ネットワークの一構成例を示す図である。
【図４】ゲートウェイ装置３０の具体的構成例を示す図である。
【図５】本発明のゲートウェイ装置により実行される主要なステップとこれに関連するステップとを示すフローチャートである。
【図６】図５のステップＳ２６の変形態様を示す図である。
【図７】図６のステップＳ３３の応用例を示す図である。
【図８】シグナリング情報についてその詳細例を示す図である。
【図９】ＩＰヘッダフィールドの詳細例を示す図である。
【図１０】ＴＣＰヘッダフィールドの詳細例を示す図である。
【図１１】ＵＤＰヘッダフィールドの詳細例を示す図である。
【図１２】図４内でのパケットの動きと処理を図解的に表す図である。
【図１３】図３において実現される通信シーケンスを表す図である。
【図１４】（ａ）は一般的な音声系ネットワークのシステム構成を、（ｂ）は一般的なデータ系ネットワークのシステム構成をそれぞれ示す図である。
【図１５】ＶｏＩＰ技術を基盤とした、一般的なＩＰネットワークの一構成例を示す図である。
【図１６】一般的なゲートウェイ装置の一構成例を示す図である。
【符号の説明】
１…電話機
５…パソコン（ＰＣ）
６…伝送装置
７…専用線網
８…ホスト
１０…伝送パス
１１…幹線系
１２…ゲートウェイ装置（ＧＷ）
１３…ＬＡＮ
１４…専用線
１５…専用線
１６…支線系（＃１，＃２，＃９，＃１０）
１７…ゲートウェイ装置（ＧＷ）
１８…ＰＢＸ
１９…ＰＣ
２０…ゲートウェイ装置
２１…ＬＡＮ制御部
２２…制御部
２３…ＷＡＮ制御部
２４…メモリ部
２６…外部インタフェース部
３０…ゲートウェイ装置
３１…識別手段
３２…判定手段
３３…メモリ手段
４１…識別部
４２…解析部
４３…伝送パス帯域管理部
ＡＢ…空き通信帯域

Claims

音声系とデータ系の統合ネットワークにおける音声呼管理制御方法であって、
前記統合ネットワーク内の第１ゲートウェイ装置に入力されるパケットが音声呼パケットか否かを識別する第１ステップと、
前記第１ステップにおいて、音声呼パケットであると識別されたとき、対向する第２ゲートウェイ装置との間の伝送パスが有する空き通信帯域と当該音声呼パケットの所要帯域とに基づき、当該音声呼パケットが該伝送パスを通過可能か否かの判定を行う第２ステップと、
通過可能と判定されたときのみ、当該音声呼パケットを前記第２ゲートウェイ装置に転送する第３ステップとを有し、ここに
前記第１または第２ステップは、前記第１ゲートウェイ装置内に保持された所定のパラメータを参照して実行し、
前記第１ステップを実行する際の前記パラメータを、前記音声呼パケットが前記第１ゲートウェイ装置を通過するときにその音声呼パケットの情報要素を解析することにより割り出し、これを前記第１ゲートウェイ装置内に蓄積して保持することを特徴とする音声呼管理制御方法。
前記パラメータが、
前記第１ゲートウェイ装置に入力されるパケットの、ＩＰソースアドレス、ＴＣＰ／ＩＰ、ＲＴＰ、ＵＤＰの各ポート番号、およびＴＯＳ値の少なくとも１つであって、当該パラメータに基づき、前記第１ステップを実行する請求項１に記載の音声呼管理制御方法。
前記情報要素が、当該音声呼パケットのパケット長であり、所定のパケット長であることを検出して、蓄積される前記パラメータに加える請求項１に記載の音声呼管理制御方法。
音声系とデータ系の統合ネットワークにおける音声呼管理制御方法であって、
前記統合ネットワーク内の第１ゲートウェイ装置に入力されるパケットが音声呼パケットか否かを識別する第１ステップと、
前記第１ステップにおいて、音声呼パケットであると識別されたとき、対向する第２ゲートウェイ装置との間の伝送パスが有する空き通信帯域と当該音声呼パケットの所要帯域とに基づき、当該音声呼パケットが該伝送パスを通過可能か否かの判定を行う第２ステップと、
通過可能と判定されたときのみ、当該音声呼パケットを前記第２ゲートウェイ装置に転送する第３ステップとを有し、ここに
前記第２ステップは、前記第１ステップにより識別された、シグナリング情報をなす音声呼パケットの所要帯域に基づき、該シグナリング情報が前記伝送パスを通過可能か否かの判定をまず行うステップと、通過可能と判定されると、音声情報をなす該音声呼パケットの所要帯域に基づき、該音声情報が前記伝送パスを通過可能か否かの判定を引き続き行うステップとからなることを特徴とする音声呼管理制御方法。
音声系とデータ系の統合ネットワーク内のゲートウェイ装置において、
前記ゲートウェイ装置に入力されるパケットが音声呼パケットか否かを識別する識別手段と、
前記識別手段において音声呼パケットであると識別されたとき、対向する他のゲートウェイ装置との間の伝送パスが有する通信帯域と当該音声呼パケットの所要帯域とに基づき、当該音声呼パケットが該伝送パスを通過可能か否かの判定を行う判定手段とを有し、ここに
前記識別手段による識別または前記判定手段による判定を行うために参照される所定のパラメータを保持するメモリ手段をさらに有し、かつ前記識別手段は、前記識別を実行する際の前記パラメータを、前記音声呼パケットが該ゲートウェイ装置を通過するときにその音声呼パケットの情報要素を解析することにより割り出し、これを前記メモリ手段内に蓄積して保持する解析部を含むことを特徴とするゲートウェイ装置。