JP2001086161A - 呼制御サーバおよび音声データ通信方法 - Google Patents

Abstract

(57)【要約】 【課題】 パケット網においてクライアント端末装置か
ら要求されたＱｏＳを保証できる音声データ通信方法お
よび呼制御サーバを提供する。 【解決手段】 音声データ通信端末６−１から送信され
たＱｏＳ情報を含む通話要求コマンド７０に応答して、
発側呼制御サーバ３−１が、通話相手となる着側端末７
−２を管轄する着側呼制御サーバ３−２に対して呼接続
コマンド７１を送信し、着側呼制御サーバからの呼接続
ＡＣＫコマンド７２に応答して、上記発側の音声データ
通信端末を収容している発側ルータ５−１に対して、上
記通話要求コマンドで指定されたＱｏＳ情報を含むＱｏ
Ｓ設定コマンド７３を送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、マルチメディア通
信システムに関し、更に詳しくは、インターネットにお
いてリアルタイム情報を中継するための呼制御サーバお
よびデータ通信方法に関する。

【０００２】

【従来の技術】近年、ＴＣＰ／ＩＰ（Transmission Con
trol Protocol／Internet Protocol）をベースとするイ
ンターネットが急速に普及している。特に、音声端末を
インターネットを介して接続し、音声データをリアルタ
イムに送受信することによって、従来の電話網と同様の
通話を提供するインターネット電話サービスが開始さ
れ、音声系データをインターネット上に統合しようとい
う動きが活発になってきている。インターネット電話で
は、例えば、一般の電話機からインターネット内の第１
アクセスポイントにアクセスし、このアクセスポイント
から通話相手の電話機に近い第２アクセスポイント迄の
区間にインターネットを利用し、第２アクセスポイント
から相手電話機迄の区間は公衆電話網を利用するタイプ
の通信形態が注目されている。

【０００３】インターネット電話を実現する場合、例え
ば、音声入出力処理用のハードウェアと制御用ソフトウ
ェアを搭載したインターネット電話機能をもつパーソナ
ル・コンピュータ（以下、ＰＣと言う）間で通話するタ
イプと、既存の電話機とインターネット電話機能を備え
たクライアントＰＣとの間でゲートウェイ装置を介して
通話するタイプと、一般の電話機間の通話をゲートウェ
イ装置で中継するタイプの３つに分けられる。一般の電
話機との間の通話をインターネットで中継する場合、呼
制御手順の変換処理と、音声データ形式の変換処理とが
必要となる。

【０００４】標準化団体ＩＴＵ−Ｔでは、マルチメディ
ア通信端末の構成として、上記２つの変換処理モジュー
ルをそれぞれプロトコルとしてまとめたＨ.３２３勧告
を規定している。Ｈ.３２３に準拠したインターネット
電話システムでは、従来、上記呼制御手順の変換処理と
音声データの変換処理とを一つのクライアントＰＣ、あ
るいはゲートウェイ装置に同居させるのが一般的であっ
た。しかしながら、Ｈ.３２３で規定されている呼制御
手順の変換プロトコルは複雑であり、クライアントＰＣ
やＩＰ電話機（外観は通常の電話機と類似しているが、
音声データの変換処理、音声データのＩＰパケット化、
ＩＰ網へのパケット転送処理機能を備えた端末）に上記
機能を装備させるには処理負荷が大き過ぎるという意見
が出されたため、１９９８年末から、インターネットの
標準化策定団体であるＩＥＴＦにおいて、呼制御手順の
変換処理と音声データの変換処理とを別々の装置で行う
シンプル化されたプロトコルが検討され始めている（me
gaco-BOFにおいて議論"draft-huitema-MGCP-v0r1-01.tx
t（expire：99/5）"）。

【０００５】また、マルチメディアデータ転送の増加に
伴って、インターネットの網側の機能として、予め各通
信に必要な帯域を確保したり、優先制御を行うためのＱ
ｏＳ(Quality of Service)保証プロトコルの標準化作業
が、例えば、ＲＳＶＰ(Resource Reservation Protoco
l)や、ｄｉｆｆｓｅｒｖ（differenciated services）
等で進められており、これらを利用することにより、リ
アルタイム系のメディア通信の品質保証が可能となって
きている。上記標準化作業に関しては、ＩＥＴＦのRFC2
205 “Resource Reservation Protocol(RSVP)Version 1
Functional Specification”や、ｆｉｆｆｓｅｒｖ−
ＷＧにおける議論“draft-ietf-diffserv-arch-02.txt
(expire：99/4)”、ｒａｐ−ＷＧにおける議論“draft-
ietf-rap-cops-rsvp-02.txt（expire：99/6）”等に記
載されている。また、インターネットにおける音声通信
に関しては、例えば、雑誌、日経コミュニケーション、
１９９９年２月１日号に、“ＶｏＩＰゲートウェイ 音
声をネットで中継”と題する報告がある。

【０００６】

【発明が解決しようとする課題】然るに、呼制御変換処
理とデータ変換処理とを別装置で行うインターネット電
話システムでは、ＱｏＳ保証機能を持ったインターネッ
ト上で音声通話の中継を行う場合、網へのＱｏＳ要求は
呼制御変換装置（以下、呼制御サーバと言う）で行わ
れ、実際のデータ転送処理はルータ等のデータ変換装置
（以下、メディア通信装置と言う）で行われるため、Ｑ
ｏＳ要求に従ってリソースが確保された経路と、実際に
データが転送される経路とが必ずしも一致せず、特に、
呼制御サーバ装置とメディア通信装置とが互いに別の網
セグメントに位置している場合、ＱｏＳの保証が完全で
はない。

【０００７】本発明の目的は、呼制御変換処理とデータ
変換処理とを別装置で行った場合にＱｏＳを保証できる
パケット網を提供することにある。本発明の他の目的
は、パケット網においてクライアント端末装置から要求
されたＱｏＳを保証した音声データ通信方法を提供する
ことにある。本発明の更に他の目的は、パケット網にお
いてクライアント端末装置から要求されたＱｏＳを保証
した音声データ通信を可能とする呼制御サーバを提供す
ることにある。

【０００８】

【課題を解決するための手段】上記課題を解決するため
に、本発明では、クライアント端末から通話要求を受信
した呼制御サーバが、着側端末を管轄する着側呼制御サ
ーバとの間で呼設定手順を実行すると共に、発側端末を
収容している発側ルータと着側端末を収容している着側
ルータとの間に、上記通話要求で指定されたＱｏＳのリ
ソース確保を指令することを特徴とする。更に詳述する
と、本発明の呼制御サーバは、音声データ通信端末から
送信されたＱｏＳ情報を含む通話要求コマンドの受信に
応答して、通話相手となる着側端末を管轄する着側呼制
御サーバに対して呼接続コマンドを送信するための第１
手段と、上記着側呼制御サーバからの呼接続ＡＣＫコマ
ンドの受信に応答して、上記発側の音声データ通信端末
を収容している発側ルータに対して、上記通話要求コマ
ンドで指定されたＱｏＳ情報を含むＱｏＳ設定コマンド
を送信するための第２手段とを備えたことを特徴とす
る。

【０００９】本発明の１実施例によれば、上記呼制御サ
ーバは、各通信端末と、該通信端末を管轄する呼制御サ
ーバのアドレスと、デフォルトルータアドレスとの関係
を記憶するロケーション管理テーブルと、コネクション
毎に、少なくとも発側、着側の端末アドレスと、ＱｏＳ
情報とを記憶するコネクション管理テーブルとを有し、
前記第１手段が、前記通話要求コマンドの受信に応答し
て、上記コネクション管理テーブルに新たなエントリを
追加し、上記ロケーション管理テーブルを参照して、前
記通話要求コマンドで指定された着側端末と対応する着
側呼制御サーバのアドレスを求め、前記第２手段が、前
記呼接続ＡＣＫコマンドの受信に応答して、上記コネク
ション管理テーブルを参照し、前記ＱｏＳ情報を含むＱ
ｏＳ設定コマンドを生成することを特徴とする。

【００１０】本発明の音声データの通信方法は、複数の
ルータと複数の呼制御サーバとを有するＩＰパケット網
において、（ａ）音声データの送信に先だって、上記Ｉ
Ｐパケット網に接続された発側の通信端末から該端末を
管轄する発側の呼制御サーバに、着側端末とＱｏＳ情報
を特定した通話要求コマンドを送信するステップと、
（ｂ）上記通話要求コマンドの受信に応答して、上記発
側の呼制御サーバから上記着側端末を管轄する着側の呼
制御サーバに、着側端末とＱｏＳ情報を特定した呼接続
コマンドを送信するステップと、（ｃ）上記着側呼制御
サーバから上記発側呼制御サーバに、呼接続ＡＣＫコマ
ンドを送信ステップと、（ｄ）上記呼接続ＡＣＫコマン
ドの受信に応答して、上記発側呼制御サーバから上記発
側端末を収容している発側ルータに、上記通話要求コマ
ンドで指定されたＱｏＳ情報を含むＱｏＳ設定コマンド
を送信するステップと、（ｅ）上記発側ルータから上記
着側端末を収容している着側ルータに至る経路上の各ル
ータで指定ＱｏＳの設定可否を示すリターン情報を付加
しながら、上記ＱｏＳ設定コマンドを上記着側呼制御サ
ーバに転送するステップと、（ｆ）上記着側呼制御サー
バが、上記ＱｏＳ設定コマンドのリターン情報から上記
発側ルータと着側ルータ間に所望のＱｏＳが確保された
ことを確認して、上記着側端末に通話要求コマンドを送
信するステップとを有することを特徴とする。

【００１１】本発明の１実施例によれば、上記ＱｏＳ設
定コマンドのリターン情報から、発側ルータと着側ルー
タ間に所望のＱｏＳを確保できなかったことが判明した
時、上記着側呼制御サーバから発側サーバに、呼接続を
拒絶するコマンドが送信される。また、この時、上記着
側呼制御サーバから着側ルータを経由して発側ルータ
に、上記ＱｏＳ設定を解除するためのコマンドが送信さ
れる。

【００１２】

【発明の実施の形態】以下、本発明の実施形態につい
て、図面を参照して説明する。図１は、本発明の音声デ
ータ通信方法が適用される通信ネットワークの構成の１
例を示す。図１において、１はパケット網、２は公衆電
話網であり、パケット網１は、複数のルータ５ｎ（ｎ＝
１、２、…）からなり、これらのサーバには、呼制御サ
ーバ装置３（３−１、３−２）、ＩＰ電話クライアント
端末６（６−１、６−２）、ＩＰ電話機７（７−１、７
−２）、および、パケット網に接続された端末アドレス
情報を管理するためのＤＮＳ（Domain Name System）サ
ーバ９が接続されている。また、一般の電話機８を収容
した公衆電話網２は、ゲートウエイ（Gate Way:ＧＷ）
装置４を介して上記パケット網１に接続されている。

【００１３】図２は、クライアント端末６の構成を示
す。クライアント端末６は、ＣＰＵ１０と、上記ＣＰＵ
１０で実行する通信プログラム等が格納されたメモリ１
１と、各種のテーブルデータを記憶するための蓄積装置
１２と、パケット網１に接続するための通信網インタフ
ェース１３と、音声入力用の第１入力装置（マイク）１
４Ａと、データ入力用の第２の入力装置（キーボード、
マウス、ペン等）１４Ｂと、音声出力用の第1の出力装
置（スピーカ）１５Ａと、データ出力用の第2の出力装
置（ディスプレイ等）１５Ｂと、送信データ処理回路１
００Ｔと、受信パケット処理回路１００Ｒと、これらの
要素を相互接続する内部バスとからなる。

【００１４】送信データ処理回路１００Ｔは、第１入力
装置１４Ａから入力されたアナログ音声信号をディジタ
ル信号に変換するためのＡ／Ｄ変換器１５と、ディジタ
ル化された音声信号を圧縮、符号化するための符号化回
路（Coder）１６と、上記Coder１６から出力された符号
化音声データにシーケンス番号等の制御情報を付加し
て、図２３で後述する所定フォーマットのデータブロッ
クを生成するためのデータパケット化回路１７と、上記
音声データパケットおよび後述する呼制御用のコマンド
パケットにＴＣＰ／ＵＤＰヘッダとＩＰヘッダを付加
し、ＩＰパケットとして通信網インタフェース１３に出
力するネットワークパケット化回路１８とからなる。

【００１５】受信パケット処理回路１００Ｒは、通信網
インタフェース１３から受信されたＩＰパケットからヘ
ッダ情報を除去し、データフィールドの内容を出力する
ネットワークパケット分解回路２２と、上記データフィ
ールドの内容を識別し、コマンドパケットと音声データ
パケットとに振り分けるデータ／コマンド振分け回路２
３と、音声データパケットをバッファリングするための
データキュー２４と、上記データキュー２４から音声デ
ータパケットを読み出し、各音声データパケットの制御
情報をチェックしながら符号化音声データを出力する符
号化音声データ抽出回路２５と、上記符号化音声データ
を復号化する復号化回路（Decoder）２６と、復号化さ
れたディジタル音声データをアナログ音声信号に変換す
るためのＤ／Ａ変換回路２７とからなる。

【００１６】第２入力装置１４Ｂからの入力データは、
メモリ１１に格納されたプログラムの一部を構成するイ
ベント解析ルーチン１９によって解析され、上記入力デ
ータが呼設定に関するイベントの場合、コマンドパケッ
ト化ルーチン２０によって所定フォーマットのコマンド
パケットが生成され、ネットワークパケット化回路１８
に供給される。上記コマンドパケットの生成に必要な各
種制御情報や呼制御の状態遷移は、発信呼制御処理ルー
チン２１によって管理されている。一方、データ／コマ
ンド振り分け回路２３で識別されたコマンドパケット
は、メモリ１１に格納されたプログラムの一部を構成す
るコマンド解析処理２９によって受信コマンドの種別が
解析される。受信コマンドがユーザに通知すべきコマン
ドの場合、受信コマンドに対応した出力メッセージまた
は出力信号が出力データ生成ルーチン３０によって生成
され、第２出力装置１５Ｂに出力される。音声パケット
の受信状態や呼制御状態遷移は、受信呼制御処理ルーチ
ン３１によって管理される。

【００１７】ここでは、音声データのパケット化とネッ
トワークパケット化、受信パケットの分解、データ／コ
マンド振り分け、符号化音声データの抽出をハードウエ
ア回路によって行っているが、これらの処理は、メモリ
１１に格納されたプログラムルーチンによって、ソフト
ウェア的に実現してもよい。

【００１８】蓄積装置１２には、図３に示すアドレス管
理テーブル１１０と、図４に示す固定値テーブル１２０
が形成されている。アドレス管理テーブル１１０は、通
信端末名１１１とＩＰアドレス１１２との関係を示す複
数のエントリを有し、ＤＮＳサーバ９が保持するアドレ
ス管理テーブルに対するキャッシュメモリとなってい
る。

【００１９】固定値テーブル１２０は、各ＩＰ電話クラ
イアント端末６に固有の制御情報を記憶するためのもの
であり、例えば、そのＩＰ電話クライアント端末に与え
られた通信端末名１２１およびＩＰアドレス１２２と、
該ＩＰ電話クライアント端末からの発呼を受け付ける呼
制御サーバ（発側呼制御サーバ）のアドレス１２３と、
該ＩＰ電話クライアント端末を収容しているルータ、す
なわち、デフォルト（第１ホップ目）のルータ（発側デ
フォルトルータ）のアドレス１２４と、ＱｏＳ（Qualit
y of Service）情報として、帯域１２５、最大許容遅延
時間１２６および許容パケットロス率１２７と、符号化
方式特定情報１２８を記憶している。

【００２０】本発明の音声データ通信方法をＩＰ電話機
７に適用する場合は、各ＩＰ電話機７に上記図２に示し
たＩＰ電話クライアント端末６と同様のパケット処理機
能を装備すればよい。ＧＷ装置４は、公衆網２から受信
した音声信号と呼制御信号をそれぞれＩＰパケットに変
換してルータ５―３に転送し、逆に、ルータ５―３から
の受信ＩＰパケットを音声信号または呼制御信号に変換
して公衆網２に転送する。従って、公衆網との入出力イ
ンタフェースを入力装置１４Ａ、１４Ｂ、出力装置１５
Ａ、１５Ｂに対応付ければ明らかなように、ＧＷ装置４
に上記図２と同様の機能をもたせることによって、一般
電話機８に対しても本発明の音声データ通信方法を適用
できる。

【００２１】呼制御サーバ３は、パケット網１に接続さ
れたＧＷ装置４をＩＰ電話クライアント端末６やＩＰ電
話機７と同等に扱う。以下の説明で、呼制御装置３が端
末として扱うこれらの装置を総括して、メディア（音声
データ）通信端末と言う。呼制御サーバ装置３は、本発
明の音声データ通信方法を実現するために、例えば、図
５に示すロケーション管理テーブル２００と、図６に示
すコネクション管理テーブル２１０を備えている。

【００２２】ロケーション管理テーブル２００は、その
呼制御サーバが過去に通話中継したメディア通信端末の
名称２０１と、該メディア通信端末を管轄する呼制御サ
ーバのアドレス２０２と、該メディア通信端末のデフォ
ルト（第１ホップ目）のルータのアドレス２０３との関
係を示す複数のエントリ２００―１〜２００―ｍからな
っている。コネクション管理テーブル２１０は、現在通
話中の呼と対応した複数のエントリ２１０―１〜２１０
―ｋからなり、各エントリは、呼に割り当てられた論理
回線番号２１１と、発側（または送信元）通信端末のア
ドレス２１２と、発側通信端末が接続された発側（また
は送信元）デフォルトルータのアドレス２１３と、着側
（宛先）通信端末のアドレス２１４と、着側通信端末が
接続された着側（または宛先）デフォルトルータのアド
レス２１５と、着側通信端末を管轄する着側（または宛
先）呼制御サーバのアドレス２１６と、上記呼における
ＱｏＳ情報（帯域幅２１７、最大許容遅延時間２１８、
許容パケットロス率２１９）と、上記呼で使用される音
声符号化方式を特定するための定義情報２２０とを含
む。

【００２３】図７は、図１の通信ネットワークに適用し
た本発明による音声データ通信方法の全体的な通信手順
を示す。ここでは、ルータ５―１に収容されたＩＰ電話
クライアント端末６―１を発側端末、ルータ５―７に収
容されたＩＰ電話機７―２を着側端末とし、サーバ３―
１を発側呼制御サーバ、３―２を着側呼制御サーバと
し、発側端末６−１からの通話要求によって呼が設定さ
れ、通話終了後、着側端末７―２から切断要求によって
呼が切断される迄の各装置の動作を説明する。発側端末
６−１の第２入力装置１４Ｂから、着側端末７−２の通
信端末名入力を含むユーザ操作によって通話要求イベン
トが発生した場合、発側端末６−１において通話要求処
理４４が実行され、これによって通話要求コマンド７０
を含む図２６に示すＩＰパケットが生成され、発側呼制
御サーバ３−１に送信される。

【００２４】上記ＩＰパケットは、図２６に示すよう
に、ＩＰヘッダ７１０とＩＰデータフィールド７２０と
からなり、ＩＰヘッダ７１０の送信元アドレス（ＳＡ）
７１１には固定値テーブル１２０から求めた発側端末６
―１のＩＰアドレス１２２が設定され、宛先アドレス
（ＤＡ）７１２にはアドレス管理テーブル１１０から求
めた着側端末のＩＰアドレスが設定される。また、ＩＰ
データフィールド７２０は、ＴＣＰ／ＵＤＰのヘッダフ
ィールド７２１とデータフィールド７２２とからなり、
上記データフィールド７２２に、コマンド種類７３０、
コマンドＩＤ７３１、発側端末アドレス７３２、発側端
末名７３３、着側端末アドレス７３４、着側端末名７３
５、符号化方式特定情報７３６、帯域７３７、最大許容
遅延時間７３８、許容パケットロス率７３９からなる通
話要求コマンド７０が設定される。

【００２５】上記通話要求処理４４では、図８に示すよ
うに、ユーザ入力イベントから宛先端末７−２の通信端
末名を取得し（ステップ４４０）、該通信端末名を持つ
エントリがアドレス管理テーブル１１０に既に登録済み
か否かをチェックする（４４１）。もし、目的エントリ
がアドレス管理テーブルに未登録の場合は、ＤＮＳサー
バに上記宛先端末のＩＰアドレスを問合わせ（４４
２）、上記宛先端末の名称１１１とＩＰアドレス１１２
との関係を示す新たなエントリをアドレス管理テーブル
１１０に登録（４４３）した後、通話要求コマンド７０
を生成し（４４４）、上記通話要求コマンド７０を含む
ＩＰパケットを発側呼制御サーバに送信する（４４
５）。この時、通話要求コマンド７０に含まれる発側端
末アドレス７３２、発側端末名７３３、符号化方式特定
情報７３６およびＱｏＳ情報７３７〜７３９は固定値テ
ーブル１２０から得られ、着側端末アドレス７３４と着
側端末名７３５は、上述したアドレス管理テーブル１１
０の目的エントリの内容と対応している。また、ＩＰパ
ケットヘッダの送信元アドレス７１１と宛先アドレス７
１２には、固定値テーブル１２０から得た発側端末６−
１のＩＰアドレス１２２と発側呼制御サーバアドレス１
２３とがそれぞれ設定される。

【００２６】上記通話要求コマンド７０の受信に応答し
て、発側呼制御サーバ装置３−１は、呼接続処理４５を
行い、図２７に示す呼接続コマンド７１を含むＩＰパケ
ットを生成して、着側呼制御サーバ装置３−２に送信す
る。上記呼接続コマンド７１は、受信した通話要求コマ
ンド７０に含まれる項目７３０〜７３９に、更に、発側
デフォルトルータアドレス７４０を追加した内容となっ
ている。上記呼接続処理４５では、図９に示すように、
受信した通話要求コマンド７０から抽出した発側端末名
７３３と着側端末名７３５に基づいて、ロケーション管
理テーブル２００を参照し、上記発側端末名７３３と対
応するデフォルトルータアドレス（発側ルータアドレ
ス）と、上記着側端末名７３５と対応する呼制御サーバ
アドレス（着側呼制御サーバアドレス）を求め（４５
０）、これらのアドレスと、上記通話要求コマンド７０
から抽出された発側端末アドレス７３２、着側端末アド
レス７３４、符号化方式定義情報７３６、ＱｏＳ情報７
３７−７３９を含む新たなエントリをコネクション管理
テーブル２１０に追加する（４５１）。次に、上記通話
要求コマンド７０の内容と上記発側デフォルトルータア
ドレスとに基づいて、図２７に示すフォーマットの呼接
続コマンド７１を含むＩＰパケットを生成し（４５
２）、これを着側呼制御サーバ３−２に送信する（４５
３）。

【００２７】着側呼制御サーバ装置３−２は、上記呼接
続コマンド７１の受信に応答して呼接続受信処理４６を
行う。呼接続受信処理４６では、図１０に示すように、
受信した呼接続コマンド７１から抽出した発側端末名７
３５に基づいて、ロケーション管理テーブル２００を参
照し、上記着側端末名と対応する着側デフォルトルータ
アドレスを検索し（４６０）、上記着側デフォルトルー
タアドレスと、上記呼接続コマンド７１から抽出したそ
の他の項目とに基づいて新たなテーブルエントリを生成
し、これをコネクション管理テーブル２１０に登録する
（４６１）。

【００２８】この場合、着側呼制御サーバ３−２のコネ
クション管理テーブル２１０では、管轄下にある端末７
−２を発側、通信相手となる端末６−１を着側として上
記テーブルエントリが生成され、上記呼接続コマンド７
１のＩＰヘッダに送信元アドレスとして設定された発側
呼制御サーバ３−１のアドレスが着側呼制御サーバアド
レス２１６として記憶される。着側呼制御サーバ装置３
−２は、次に、呼設定ＡＣＫコマンド７２を生成し（４
６２）、この呼設定ＡＣＫコマンド７２を含むＩＰパケ
ットを発側の呼制御サーバ３−１に送信する（４６
３）。上記呼設定ＡＣＫコマンド７２には、発側、着側
の端末アドレスの他に、ステップ４６０で検索した着側
デフォルトルータアドレスが含まれている。

【００２９】発側呼制御サーバ３−１は、上記呼接続Ａ
ＣＫコマンド７２を受信すると、ＱｏＳ設定処理４７を
実行する。上記ＱｏＳ設定処理４７では、図１１に示す
ように、受信した呼接続ＡＣＫコマンド７２から着側デ
フォルトルータアドレスを抽出し、これを上記呼接続Ａ
ＣＫコマンド７２の発側、着側端末アドレスで特定され
るコネクション管理テーブル２１０の該当エントリのフ
ィールド２１５に追加する（ステップ４７９）。次に、
上記テーブルエントリの内容に基づいて、図２８に示す
ＱｏＳ設定コマンド７３を生成し（ステップ４７１）、
上記ＱｏＳ設定コマンド７３を含むＩＰパケットをカプ
セル化して、発側デフォルトルータ５−１に送信する
（ステップ４７２）。尚、この実施例では、着側デフォ
ルトルータアドレスを呼接続ＡＣＫコマンド７２の受信
時にコネクション管理テーブル２１０に設定している
が、この着側デフォルトルータアドレスの設定は、前述
の呼接続処理４５で行ってもよい。

【００３０】上記ＱｏＳ設定コマンド７３は、図２８に
示すように、コマンド種別７３０、コマンドＩＤ７３
１、発側端末アドレス７３２、着側端末アドレス７３
４、符号化方式情報７３６、ＱｏＳ情報７３７〜７３９
の他に、発側デフォルトルータアドレス７４０、着側呼
制御サーバアドレス７４１、着側デフォルトルータアド
レス７４２と、リターン値設定フィールド７４３を含
み、ＩＰヘッダの送信元アドレス（ＳＡ）と宛先アドレ
ス（ＤＡ）には、発側呼制御サーバ３−１と着側呼制御
サーバ３−２のアドレスがそれぞれ設定される。また、
上記ＩＰヘッダの前に付されるカプセル化ヘッダには、
送信元アドレス（ＳＡ）として発側呼制御サーバ３−１
のアドレス、宛先アドレス（ＤＡ）として発側デフォル
トルータ５−１のアドレスがそれぞれ設定され、プロト
コルタイプ（プロトコル番号）として、このＩＰパケッ
トがＱｏＳ設定コマンドであることを示す特定の番号
（以下、“ｘｘ”で示す）を含む。

【００３１】発側ルータ５−１は、上記ＱｏＳ設定コマ
ンド７３を含むカプセル化ＩＰパケットを受信すると、
プロトコル番号が“ｘｘ”であることから、受信パケッ
トをＱｏＳ設定コマンド７３と解釈し、ＱｏＳ設定コマ
ンド７３の発側デフォルトルータアドレス７４０と着側
デフォルトルータアドレス７４２をチェックする。この
場合、発側デフォルトルータアドレス７４０が自分のア
ドレスに一致しているため、発側ルータ５−１は、カプ
セル化ＩＰパケットの送信元アドレス（ＳＡ）を自分の
アドレス、宛先アドレス（ＤＡ）を着側デフォルトルー
タアドレス７４２にそれぞれ書き換えて、ネットワーク
に送出する。着側ルータ５−７が、上記ＱｏＳ設定コマ
ンド７３を含むカプセル化ＩＰパケットを受信すると、
プロトコル番号が“ｘｘ”であることから、受信パケッ
トをＱｏＳ設定コマンド７３と解釈し、発側ルータ５−
１と同様に、ＱｏＳ設定コマンド７３の発側デフォルト
ルータアドレス７４０と着側デフォルトルータアドレス
７４２をチェックする。この場合、着側デフォルトルー
タアドレス７４２が自分のアドレスに一致しているた
め、着側ルータ５−１は、カプセル化を解除し、発側呼
制御サーバ３−１が発行した元のＩＰパケットに戻し
て、ネットワークに送出する。

【００３２】上記中継動作によって、 ＱｏＳ設定コマ
ンド７３は着側呼制御サーバ３−２に転送される。上述
したＱｏＳ設定コマンド７３の中継過程において、各ル
ータは、受信したＱｏＳ設定コマンド７３で指定された
ＱｏＳ情報７３７〜７３９を満足するリソースが確保で
きるか否かを判定し、それぞれの判定結果に従って、フ
ィールド７４３にＱｏＳ設定可否を示すリターン値を設
定する。何れかの中継ルータがＱｏＳ設定不可を示した
場合は、エラーリターンとなり、呼設定は不成功に終わ
る。但し、上記ＱｏＳ設定が可能なルータを検索しなが
ら経路を設定する場合はこの限りではない。着側呼制御
サーバ３−２は、ルータ５−７から上記ＱｏＳ設定コマ
ンドを含むＩＰパケットを受信すると、リターン値設定
フィールド７４３をチェックし、もし、リターン値がＱ
ｏＳ設定可を示す場合は、通話要求中継処理４８を実行
し、リターン値がＱｏＳ設定不可を示していた場合、す
なわちエラーリターンとなっていた場合は、後述する呼
接続拒絶処理５１を実行する。

【００３３】上記通話要求中継処理４８では、図１２に
示すように、ＱｏＳ設定コマンド７３から発側端末アド
レス７３２と着側端末アドレス７３４を抽出し、コネク
ション管理テーブル２１０の上記発側端末アドレスと対
応するテーブルエントリから、符号化方式の定義情報を
取得する（ステップ４８０）。次に、上記符号化方式定
義情報と着側端末アドレスを含む通話要求コマンド７４
を生成し（４８１）、該通話要求コマンド７４を含むＩ
Ｐパケットを着側端末７−２に送信する（ステップ４８
２）。着側端末７−２は、呼制御サーバ３−２から上記
通話要求コマンド７４を受信すると、端末ユーザに通話
の着信を通知し、ユーザからの応答イベントを処理する
ための通話要求受信処理４９を実行する。もし、ユーザ
から通話拒絶イベント７６を受けた場合は、呼制御サー
バ３−２に通話拒絶コマンド７７を応答するための通話
拒絶処理５０を実行し、通話許諾イベント８２を受けた
場合は、通話許諾コマンド８３を応答するための通話許
諾処理５４を実行する。

【００３４】上記通話要求受信処理４９では、図１３に
示すように、通話要求コマンド７４から発側端末アドレ
スと、符号化方式の定義情報を抽出し（ステップ４９
０）、これらの情報を図示しない通話管理テーブルに登
録する（４９１）。次に、図２に示した符号化回路（Co
der）１６と復号化回路（Decoder）２６に、上記定義情
報に従った符号化方式のパラメータを設定し（４９
２）、着信通知メッセージを第２出力装置１５Ｂに出力
する（４９３）。上記着信通知メッセージに対するユー
ザからの応答待ち時間を制限するためのタイマを起動し
（４９４）、ユーザから応答を判定する。ユーザから通
話受諾応答があった場合（４９５）、発側、着側の端末
アドレスを含む通話受諾コマンド８２を生成し、該通話
受諾コマンドを含むＩＰパケットを着側呼制御サーバ装
置３−２に送信する（通話受諾処理５４）。この後、図
７に示す発側端末の音声データ送受信処理５７と同様の
音声データ送受信処理４９８を開始する。ユーザから通
話拒絶応答があった場合（４９６）、または、タイマが
タイムアウトとなった場合（４９７）は、通話拒絶処理
５０を実行する。

【００３５】上記通話拒絶処理５０では、図１４に示す
ように、発側、着側の端末アドレスを含む通話拒絶コマ
ンド７７を生成し（ステップ５００）、上記通話拒絶コ
マンド７７を含むＩＰパケットを呼制御サーバ装置３−
２に送信（５０１）した後、符号化回路１６と復号化回
路２６を初期化する（５０２）。エラーリターンを含む
ＱｏＳ設定コマンド７３（ＱｏＳ設定エラー通知７８）
を受信した場合、あるいは着側端末７−２から通話拒絶
コマンド７７を受信した場合は、着側呼制御サーバ３−
２は、呼接続拒絶処理５１を実行する。

【００３６】上記呼接続拒絶処理５１では、図１５に示
すように、受信した通話接続拒絶コマンド７７、または
ＱｏＳ設定エラー通知７８に含まれる着側、発側の端末
アドレスに基づいて、コネクション管理テーブル２１０
を参照し、着側呼制御サーバアドレス２１６として記憶
されて発側の呼制御サーバ３−１のアドレスを取得する
（ステップ５１０）。次に、呼接続拒絶原因と、発側端
末６−１および着側端末７−２のアドレスとを含む呼接
続拒絶コマンド８０を生成し（５１１）、該コマンドを
上記ステップ５１０で取得した発側呼制御サーバ３−１
宛に送信する（５１２）。今回の呼接続拒絶がＱｏＳ設
定エラー通知７８に起因していた場合（５１３）は、コ
ネクション管理テーブル２１０から該当エントリを削除
して（５１７）、このルーチンを終了する。

【００３７】呼接続拒絶が端末ユーザからの通話拒絶コ
マンド７６に起因していた場合は、コネクション管理テ
ーブル２１０から発側、着側のデフォルトルータアドレ
ス２１３、２１５を取得し（５１４）、これらのアドレ
ス情報を含むＱｏＳリリースコマンド７９を生成し（５
１５）、これをＩＰパケットとして着側ルータ５−７に
送信（５１６）した後、コネクション管理テーブル２１
０から該当エントリを削除する（５１７）。上記ＱｏＳ
リリースコマンド７９は、ＱｏＳ設定コマンド４７の経
路を逆方向に辿ってデフォルトルータ５−１まで中継さ
れる。経路上の各ルータは、上記ＱｏＳリリースコマン
ド７９の受信に応答して、ＱｏＳ設定コマンド４７受信
時に確保していた通信リソースを順次に解放していく。

【００３８】呼接続拒絶コマンド８０を受信した発側呼
制御サーバ装置３−１は、通話拒絶中継処理５２を実行
する。上記通話拒絶中継処理５２では、図１６に示すよ
うに、通話拒絶原因を含む通話拒絶コマンド８１を生成
し（ステップ５２０）、上記通話拒絶コマンド８１を含
むＩＰパケットを発側端末６−１へ送信（５２１）した
後、上記呼接続拒絶コマンド８０の発側、着側の端末ア
ドレスに基づいて、コネクション管理テーブル２１０か
ら該当エントリを削除する（５２２）。

【００３９】通話拒絶コマンド８１を受信した発側端末
６−１は、通話拒絶受信処理５３を実行する。上記通話
拒絶受信処理５３では、図１７に示すように、通話拒絶
コマンド８１が示す通話拒絶原因に応じて、ユーザに通
知すべきメッセージを生成し、これを第２出力装置１５
Ｂに出力する（ステップ５３０）。この後、符号化回路
１６、復号化回路２６を初期化し（５３１）、発側呼制
御サーバ装置３−１とのコネクションを切断する（５３
２）。

【００４０】着側の呼制御サーバ装置３−２は、着側端
末７−２から通話受諾コマンド８３を受信すると、呼確
立処理５５を実行する。上記呼確立処理５５では、図１
８に示すように、受信した通話受諾コマンド８３に含ま
れる発側、着側の端末アドレスに基づいて、コネクショ
ン管理テーブル２１０から発側呼制御サーバアドレスを
取得する（ステップ５５０）。次に、発側、着側端末の
アドレスを含み、呼が確立されたことを示す呼確立コマ
ンド８４を生成し（５５１）、該呼確立コマンドを含む
ＩＰパケットを発側呼制御サーバ３−１に対して送信す
る（５５２）。

【００４１】上記呼確立コマンド８４を受信した発側呼
制御サーバ３−１は、通話要求受諾中継処理５６を実行
する。上記通話受諾中継処理５６では、図１９に示すよ
うに、通話受諾コマンド８５を生成し（ステップ５６
０）、受信した前記呼確立コマンドが示す発側端末アド
レスに基づいて、上記通話受諾コマンド８５を発側端末
６−１に送信する（５６１）。

【００４２】発側端末６−１は、上記通話受諾コマンド
８５を受信すると、音声データ送受信処理５７を開始す
る。これによって発側端末６−１と着側端末７−２との
間で通話音声データの送受信が可能となる。上記音声デ
ータ送受信処理５７が開始されると、符号化回路１６で
圧縮された符号化音声データがデータパケット化回路１
７によって次々と音声パケットに変換される。各音声パ
ケットは、図２９に示すように、コマンド種別７３０
と、符号化方式定義情報７５０と、シーケンス番号７５
１と、タイムスタンプ（時刻情報）７５２と、符号化音
声データ７５３とからなる。各音声パケットは、ネット
ワークパケット化回路１８によってＩＰヘッダが付加さ
れた後、通信網インタフェース１３を介してパケット網
１に送出される。一方、パケット網１から受信されたＩ
Ｐパケットは、ネットワークパケット分解回路２２とデ
ータ／コマンド振り分け回路２３で処理され、各受信パ
ケットに含まれる符号化音声データが符号化音声データ
抽出回路２５で抽出され、復号化回路２６に供給され
る。

【００４３】発側端末６−１と着側端末７−２との間で
の通話が終了し、例えば、着側端末７−２のユーザが通
話切断８６の操作を行った場合、着側端末７−２では、
通話切断処理５８が実行される。上記通話切断処理５８
では、図２０に示すように、通話切断コマンド８７を生
成し（ステップ５８０）、該通話切断コマンド８７を含
むＩＰパケットを着側呼制御サーバ３−２に送信（５８
１）した後、符号化回路１６を含む送信データ処理回路
１００Ｔと、復号化回路２６を含む受信パケット処理回
路１００Ｒを初期化する（５８２）。

【００４４】上記通話切断コマンド８７を受信した着側
呼制御サーバ３−２は、呼切断処理５９を実行する。上
記呼切断処理５９では、図２１に示すように、着側端末
７−２と発側端末６−１のアドレスを含む呼切断コマン
ド８８を生成し（ステップ５９０）、コネクション管理
テーブル２１０から求めた呼制御サーバアドレス２１６
に従って、上記呼切断コマンドを含むＩＰパケットを発
側呼制御サーバアドレス３−１に送信する（５９１）。
次に、ＱｏＳリソースを開放するためのＱｏＳリリース
コマンド８９を生成し（５９２）、該コマンドを含むＩ
Ｐパケットを着側デフォルトルータ５−７経由で発側デ
フォルトルータ５−１に送信（５９３）した後、コネク
ション管理テーブル２１０から該当コネクションのエン
トリを削除する（５９４）。

【００４５】発側呼制御サーバ装置３−１は、上記呼切
断コマンド８８を受信すると、通話切断中継処理６０を
実行する。上記通話切断中継処理６０では、図２２に示
すように、通話切断コマンド９０を生成し（ステップ６
００）、上記呼切断コマンド８８が示す発側端末アドレ
スに従って、上記通話切断コマンド９０を含むＩＰパケ
ットを発側端末６−１に送信（６０１）した後、コネク
ション管理テーブル２１０から該当エントリを削除する
（６０２）。

【００４６】発側端末６−１は、上記通話切断コマンド
９０を受信すると、通話切断受信処理６１を実行する。
上記通話切断受信処理６１では、図２３に示すように、
ユーザにコネクションの切断を通知するための切断メッ
セージを生成し、第２出力装置１５Ｂに出力する（ステ
ップ６１０）。この後、送信データ処理回路１００Ｔと
受信パケット処理回路１００Ｒを初期化し（６１１）、
呼制御サーバ装置３−２とのコネクションを切断する
（６１２）。

【００４７】図２４は、発側、着側の各端末装置６−
１、７−２で実行される通話制御プログラムのフローチ
ャートを示す。通話制御プログラムが起動されると（ス
テップ２００）、第２入力装置１４Ｂからのイベント入
力の有無を検知する（２０１）。もし、イベント入力が
あった場合、入力イベントの種類を判定し、入力イベン
トに応じた処理を実行する。入力イベントが通話要求で
あれば（２０２）通話要求処理４４、切断要求であれば
（２０３）通話切断処理５８、通話拒絶であれば（２０
４）通話拒絶処理５０、通話許諾であれば（２０５）通
話受諾処理５４をそれぞれ実行する。入力イベントが上
記の何れにも該当しなかった場合、あるいは、上記所定
の処理を終えた場合、通話制御プログラムの終了指示か
あったか否かを判定し（２２０）、終了指示があった場
合は、本ルーチンを終了し、そうでなければ、ステップ
２０１に戻る。

【００４８】ステップ２０１で、ユーザからのイベント
入力がなかった場合、パケット網１からのパケットの着
信の有無を判定する（２１０）。パケットが着信してい
なければ、ステップ２２０に進む。パケットが着信して
いた場合、受信パケットが呼制御用のコマンドか否かを
判定し（２１１）、呼制御コマンドでなければ、音声デ
ータの受信処理５７Ｒを行う。受信パケットが呼制御コ
マンドの場合、受信コマンドの種類に応じた処理を事項
する。受信コマンドが通話要求コマンド７０であれば
（２１２）通話要求受信処理４９、通話切断コマンド８
７であれば（２１３）通話切断受信処理６１を実行す
る。また、受信コマンドが通話受諾コマンド８３であれ
ば（２１４）、音声データ送受信処理５７を開始し、通
話拒絶コマンド７７であれば（２１５）、通話拒絶受信
処理５３を実行する。受信コマンドがこれらの何れにも
該当しなかった場合、あるいは、上記所定の処理を終了
した場合、ステップ２２０に進む。

【００４９】図２５は、呼制御サーバ装置３−１、３−
２で実行される呼制御プログラムのフローチャートを示
す。このプログラムが起動されると（ステップ３０
０）、パケット網１からのパケットの着信の有無を検出
し（３０１）し、パケットが着信していた場合、上記受
信パケットに含まれる受信コマンドが、クライアント端
末から発行された呼接続制御コマンドか否か判定する
（３０２）。受信コマンドがクライアント端末から発行
されたコマンドの場合、受信コマンドの種類に応じた処
理を実行する。受信コマンドが通話要求コマンド７０で
あれば（３０３）呼接続処理４５、通話切断コマンド８
７であれば（３０４）呼切断処理５９、通話受諾コマン
ド８３であれば（３０５）呼確立処理５５、通話拒絶コ
マンド７７であれば（３０６）呼接続拒絶処理５１をそ
れぞれ実行する。受信コマンドが上記何れにも該当しな
かった場合、または、上記所定の処理を終えた場合、呼
制御プログラムの終了指示の有無を判定し（３３０）、
終了指示があった場合は、本ルーチンを終了し、そうで
ない場合は、ステップ３０１に戻る。

【００５０】ステップ３０２で、受信コマンドがクライ
アント端末からのものではなかった場合、該コマンドが
他の呼制御サーバ装置から発行された呼制御コマンドか
否かを判定する（３１０）。もし、そうであれば、受信
コマンドの種類に応じた処理を実行する。受信コマンド
が呼接続コマンド７１であれば（３１１）呼接続受信処
理４６、呼接続ＡＣＫコマンド７２であれば（３１２）
ＱｏＳ設定処理４７、呼接続拒絶コマンド８０であれば
（３１３）通話拒絶中継処理５２、呼確立コマンド８４
であれば（３１４）通話受諾中継処理５６、呼切断コマ
ンド８７であれば（３１５）通話絶断中継処理６０をそ
れぞれ実行する。

【００５１】ステップ３１０において、受信コマンドが
他の呼制御サーバ装置から発行された呼制御コマンドで
はなかった場合、該コマンドがＱｏＳ設定コマンドか否
かを判定し（ステップ３２０）、ＱｏＳコマンドでなけ
ればステップ３０１に戻る。受信コマンドがＱｏＳコマ
ンドの場合、該ＱｏＳコマンドのリターン値がＱｏＳ設
定可能な状態を示しているか否かを判定し（３２１）、
もし、ＱｏＳ設定が可能であれば、通話要求中継処理５
８を実行し、ＱｏＳ設定が不能であれば、呼接続拒絶処
理５１を実行して、ステップ３３０に進む。

【００５２】

【発明の効果】以上の実施形態から明らかなように、本
発明によれば、音声データ通信端末のコネクション設定
を呼制御サーバで行い、且つ、各音声データ通信端末を
収容しているデフォルトルータを経由して通話に必要な
ＱｏＳ設定を行うようにしているため、実際にメディア
データが通るパス上でのＱｏＳ制御が可能となる。ま
た、本発明によれば、音声データ通信端末のコネクショ
ン設定を呼制御サーバで代行することによって、各音声
データ通信端末の処理負荷を軽減できる。

【図面の簡単な説明】

【図１】本発明の音声データ通信方法が適用される通信
ネットワークの構成の１例を示す図。

【図２】図１におけるクライアント端末６の構成図。

【図３】通信端末６が備えるアドレス管理テーブル１１
０の構成図。

【図４】通信端末６が備える固定値テーブル１２０の構
成図。

【図５】図１における呼制御サーバ３が備える通信端末
ロケーション管理テーブル２００の構成図。

【図６】呼制御サーバ装置３が備えるコネクション管理
テーブル２１０の構成図。

【図７】図１の通信ネットワークにおける本発明による
音声データ通信方法の全体的な通信手順を示す図。

【図８】図７における通話要求処理４４の詳細を示すフ
ローチャート。

【図９】図７における呼接続処理４５の詳細を示すフロ
ーチャート。

【図１０】図７における呼接続受信処理４６の詳細を示
すフローチャート。

【図１１】図７におけるＱｏＳ設定処理４７の詳細を示
すフローチャート。

【図１２】図７における通話要求中継処理４８の詳細を
示すフローチャート。

【図１３】図７における通話要求受信処理４９の詳細を
示すフローチャート。

【図１４】図７における通話拒絶処理５０の詳細を示す
フローチャート。

【図１５】図７における呼接続拒絶処理５１の詳細を示
すフローチャート。

【図１６】図７における通話拒絶中継処理５２の詳細を
示すフローチャート。

【図１７】図７における通話拒絶受信処理５３の詳細を
示すフローチャート。

【図１８】図７における呼確立処理５５の詳細を示すフ
ローチャート。

【図１９】図７における通話受諾中継処理５６の詳細を
示すフローチャート。

【図２０】図７における通話切断処理５８の詳細を示す
フローチャート。

【図２１】図７における呼切断処理５９の詳細を示すフ
ローチャート。

【図２２】図７における通話切断中継処理６０の詳細を
示すフローチャート。

【図２３】図７における通話切断受信処理６１の詳細を
示すフローチャート。

【図２４】通信端末６で実行される通話制御プログラム
のフローチャート。

【図２５】呼制御サーバ３で実行される呼制御プログラ
ムのフローチャート。

【図２６】ＩＰパケットと通話要求コマンド７０のフォ
ーマットの１例を示す図。

【図２７】呼接続コマンド７１のフォーマットの１例を
示す図。

【図２８】ＱｏＳ設定コマンド７３のフォーマットの１
例を示す図。

【図２９】音声パケットのフォーマットの１例を示す
図。

【符号の説明】

１：パケット網、２：公衆電話網、３：呼制御サーバ、
４：音声データ中継装置（ゲートウェイ）、５：ルー
タ、６、７：音声データ通信端末

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｍ 3/42 Ｈ０４Ｌ 11/20 Ｂ ９Ａ００１ 11/00 ３０３ (72)発明者 湯本 一磨 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 星 徹 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 Ｆターム(参考） 5K024 AA02 AA72 BB07 BB10 CC05 CC09 DD01 DD04 DD05 EE01 EE06 FF03 FF06 GG01 GG03 5K030 HA08 HB01 HD03 JT01 LA02 LB02 LC01 LC08 5K033 CB04 CB06 CC01 DB17 DB18 5K051 AA03 AA08 BB02 CC02 CC11 DD02 DD07 DD13 EE01 EE02 EE04 FF01 FF07 GG03 HH12 HH13 HH15 HH18 HH19 HH27 JJ04 JJ16 JJ17 KK01 5K101 KK05 LL02 MM04 MM06 MM07 NN03 NN07 NN14 NN15 NN23 NN25 NN34 PP03 RR12 SS08 TT02 UU19 UU20 9A001 BB04 CC06 DD10 EE05 FF03 JJ18 JJ27 KK56

Claims (5)

【特許請求の範囲】
1. 【請求項１】複数のルータを有するパケット網に接続さ
   れた呼制御サーバであって、 音声データ通信端末から送信されたＱｏＳ情報を含む通
   話要求コマンドの受信に応答して、通話相手となる着側
   端末を管轄する着側呼制御サーバに対して呼接続コマン
   ドを送信するための第１手段と、 上記着側呼制御サーバからの呼接続ＡＣＫコマンドの受
   信に応答して、上記発側の音声データ通信端末を収容し
   ている発側ルータに対して、上記通話要求コマンドで指
   定されたＱｏＳ情報を含むＱｏＳ設定コマンドを送信す
   るための第２手段とを備えたことを特徴とする呼制御サ
   ーバ。
2. 【請求項２】請求項１に記載の呼制御サーバにおいて、 各通信端末と、該通信端末を管轄する呼制御サーバのア
   ドレスと、デフォルトルータアドレスとの関係を記憶す
   るロケーション管理テーブルと、 コネクション毎に、少なくとも発側、着側の端末アドレ
   スと、ＱｏＳ情報とを記憶するコネクション管理テーブ
   ルとを有し、 前記第１手段が、前記通話要求コマンドの受信に応答し
   て、上記コネクション管理テーブルに新たなエントリを
   追加し、上記ロケーション管理テーブルを参照して、前
   記通話要求コマンドで指定された着側端末と対応する着
   側呼制御サーバのアドレスを求め、 前記第２手段が、前記呼接続ＡＣＫコマンドの受信に応
   答して、上記コネクション管理テーブルを参照し、前記
   ＱｏＳ情報を含むＱｏＳ設定コマンドを生成することを
   特徴とする呼制御サーバ。
3. 【請求項３】複数のルータと複数の呼制御サーバとを有
   するＩＰパケット網における音声データの通信方法にお
   いて、 音声データの送信に先だって、上記ＩＰパケット網に接
   続された発側の通信端末から該端末を管轄する発側の呼
   制御サーバに、着側端末とＱｏＳ情報を特定した通話要
   求コマンドを送信するステップと、 上記通話要求コマンドの受信に応答して、上記発側の呼
   制御サーバから上記着側端末を管轄する着側の呼制御サ
   ーバに、着側端末とＱｏＳ情報を特定した呼接続コマン
   ドを送信するステップと、 上記着側呼制御サーバから上記発側呼制御サーバに、呼
   接続ＡＣＫコマンドを送信ステップと、 上記呼接続ＡＣＫコマンドの受信に応答して、上記発側
   呼制御サーバから上記発側端末を収容している発側ルー
   タに、上記通話要求コマンドで指定されたＱｏＳ情報を
   含むＱｏＳ設定コマンドを送信するステップと、 上記発側ルータから上記着側端末を収容している着側ル
   ータに至る経路上の各ルータで指定ＱｏＳの設定可否を
   示すリターン情報を付加しながら、上記ＱｏＳ設定コマ
   ンドを上記着側呼制御サーバに転送するステップと、 上記着側呼制御サーバが、上記ＱｏＳ設定コマンドのリ
   ターン情報から上記発側ルータと着側ルータ間に所望の
   ＱｏＳが確保されたことを確認して、上記着側端末に通
   話要求コマンドを送信するステップとを有することを特
   徴とする音声データの通信方法。
4. 【請求項４】前記ＱｏＳ設定コマンドのリターン情報か
   ら前記発側ルータと着側ルータ間に所望のＱｏＳを確保
   できなかったことが判明した時、前記着側呼制御サーバ
   から前記発側サーバに、呼接続を拒絶するコマンドを送
   信することを特徴とする請求項３に記載の音声データの
   通信方法。
5. 【請求項５】前記ＱｏＳ設定コマンドのリターン情報か
   ら前記発側ルータと着側ルータ間に所望のＱｏＳを確保
   できなかったことが判明した時、前記着側呼制御サーバ
   から前記着側ルータを経由して前記発側ルータに、前記
   ＱｏＳ設定を解除するためのコマンドを送信することを
   特徴とする請求項３または請求項４に記載の音声データ
   の通信方法。