JP4275265B2 - 呼制御サーバおよび音声データ通信方法 - Google Patents
呼制御サーバおよび音声データ通信方法 Download PDFInfo
- Publication number
- JP4275265B2 JP4275265B2 JP26137299A JP26137299A JP4275265B2 JP 4275265 B2 JP4275265 B2 JP 4275265B2 JP 26137299 A JP26137299 A JP 26137299A JP 26137299 A JP26137299 A JP 26137299A JP 4275265 B2 JP4275265 B2 JP 4275265B2
- Authority
- JP
- Japan
- Prior art keywords
- call
- router
- command
- control server
- call control
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Telephonic Communication Services (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、マルチメディア通信システムに関し、更に詳しくは、インターネットにおいてリアルタイム情報を中継するための呼制御サーバおよびデータ通信方法に関する。
【０００２】
【従来の技術】
近年、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）をベースとするインターネットが急速に普及している。特に、音声端末をインターネットを介して接続し、音声データをリアルタイムに送受信することによって、従来の電話網と同様の通話を提供するインターネット電話サービスが開始され、音声系データをインターネット上に統合しようという動きが活発になってきている。インターネット電話では、例えば、一般の電話機からインターネット内の第１アクセスポイントにアクセスし、このアクセスポイントから通話相手の電話機に近い第２アクセスポイント迄の区間にインターネットを利用し、第２アクセスポイントから相手電話機迄の区間は公衆電話網を利用するタイプの通信形態が注目されている。
【０００３】
インターネット電話を実現する場合、例えば、音声入出力処理用のハードウェアと制御用ソフトウェアを搭載したインターネット電話機能をもつパーソナル・コンピュータ（以下、ＰＣと言う）間で通話するタイプと、既存の電話機とインターネット電話機能を備えたクライアントＰＣとの間でゲートウェイ装置を介して通話するタイプと、一般の電話機間の通話をゲートウェイ装置で中継するタイプの３つに分けられる。一般の電話機との間の通話をインターネットで中継する場合、呼制御手順の変換処理と、音声データ形式の変換処理とが必要となる。
【０００４】
標準化団体ＩＴＵ−Ｔでは、マルチメディア通信端末の構成として、上記２つの変換処理モジュールをそれぞれプロトコルとしてまとめたＨ.３２３勧告を規定している。Ｈ.３２３に準拠したインターネット電話システムでは、従来、上記呼制御手順の変換処理と音声データの変換処理とを一つのクライアントＰＣ、あるいはゲートウェイ装置に同居させるのが一般的であった。
しかしながら、Ｈ.３２３で規定されている呼制御手順の変換プロトコルは複雑であり、クライアントＰＣやＩＰ電話機（外観は通常の電話機と類似しているが、音声データの変換処理、音声データのＩＰパケット化、ＩＰ網へのパケット転送処理機能を備えた端末）に上記機能を装備させるには処理負荷が大き過ぎるという意見が出されたため、１９９８年末から、インターネットの標準化策定団体であるＩＥＴＦにおいて、呼制御手順の変換処理と音声データの変換処理とを別々の装置で行うシンプル化されたプロトコルが検討され始めている（megaco-BOFにおいて議論"draft-huitema-MGCP-v0r1-01.txt（expire：99/5）"）。
【０００５】
また、マルチメディアデータ転送の増加に伴い、インターネットの網側の機能として、予め各通信に必要な帯域を確保したり、優先制御を行うためのＱｏＳ(Quality of Service)保証プロトコルの標準化作業が、例えば、ＲＳＶＰ(Resource Reservation Protocol)や、ｄｉｆｆｓｅｒｖ（differenciated services）等で進められており、これらを利用することにより、リアルタイム系のメディア通信の品質保証が可能となってきている。
上記標準化作業に関しては、ＩＥＴＦのRFC2205 “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）”等に記載されている。また、インターネットにおける音声通信に関しては、例えば、雑誌、日経コミュニケーション、１９９９年２月１日号に、“VoIPゲートウェイ 音声をネットで中継”と題する報告がある。
【０００６】
【発明が解決しようとする課題】
然るに、呼制御変換処理とデータ変換処理とを別装置で行うインターネット電話システムでは、ＱｏＳ保証機能を持ったインターネット上で音声通話の中継を行う場合、網へのＱｏＳ要求は呼制御変換装置（以下、呼制御サーバと言う）で行われ、実際のデータ転送処理はルータ等のデータ変換装置（以下、メディア通信装置と言う）で行われるため、ＱｏＳ要求に従ってリソースが確保された経路と、実際にデータが転送される経路とが必ずしも一致せず、特に、呼制御サーバ装置とメディア通信装置とが互いに別の網セグメントに位置している場合、ＱｏＳの保証が完全ではない。
【０００７】
本発明の目的は、呼制御変換処理とデータ変換処理とを別装置で行った場合にＱｏＳを保証できるパケット網を提供することにある。
本発明の他の目的は、パケット網においてクライアント端末装置から要求されたＱｏＳを保証した音声データ通信方法を提供することにある。
本発明の更に他の目的は、パケット網においてクライアント端末装置から要求されたＱｏＳを保証した音声データ通信を可能とする呼制御サーバを提供することにある。
【０００８】
【課題を解決するための手段】
上記課題を解決するために、本発明では、クライアント端末から通話要求を受信した呼制御サーバが、着側端末を管轄する着側呼制御サーバとの間で呼設定手順を実行すると共に、発側端末を収容している発側ルータと着側端末を収容している着側ルータとの間に、上記通話要求で指定されたＱｏＳのリソース確保を指令することを特徴とする。
更に詳述すると、本発明の呼制御サーバは、音声データ通信端末から送信されたＱｏＳ情報を含む通話要求コマンドの受信に応答して、通話相手となる着側端末を管轄する着側呼制御サーバに対して呼接続コマンドを送信するための第１手段と、上記着側呼制御サーバからの呼接続ＡＣＫコマンドの受信に応答して、上記発側の音声データ通信端末を収容している発側ルータに対して、上記通話要求コマンドで指定されたＱｏＳ情報を含むＱｏＳ設定コマンドを送信するための第２手段とを備えたことを特徴とする。
【０００９】
本発明の１実施例によれば、上記呼制御サーバは、各通信端末と、該通信端末を管轄する呼制御サーバのアドレスと、デフォルトルータアドレスとの関係を記憶するロケーション管理テーブルと、コネクション毎に、少なくとも発側、着側の端末アドレスと、ＱｏＳ情報とを記憶するコネクション管理テーブルとを有し、前記第１手段が、前記通話要求コマンドの受信に応答して、上記コネクション管理テーブルに新たなエントリを追加し、上記ロケーション管理テーブルを参照して、前記通話要求コマンドで指定された着側端末と対応する着側呼制御サーバのアドレスを求め、前記第２手段が、前記呼接続ＡＣＫコマンドの受信に応答して、上記コネクション管理テーブルを参照し、前記ＱｏＳ情報を含むＱｏＳ設定コマンドを生成することを特徴とする。
【００１０】
本発明の音声データの通信方法は、複数のルータと複数の呼制御サーバとを有するＩＰパケット網において、（ａ）音声データの送信に先だって、上記ＩＰパケット網に接続された発側の通信端末から該端末を管轄する発側の呼制御サーバに、着側端末とＱｏＳ情報を特定した通話要求コマンドを送信するステップと、（ｂ）上記通話要求コマンドの受信に応答して、上記発側の呼制御サーバから上記着側端末を管轄する着側の呼制御サーバに、着側端末とＱｏＳ情報を特定した呼接続コマンドを送信するステップと、（ｃ）上記着側呼制御サーバから上記発側呼制御サーバに、呼接続ＡＣＫコマンドを送信ステップと、（ｄ）上記呼接続ＡＣＫコマンドの受信に応答して、上記発側呼制御サーバから上記発側端末を収容している発側ルータに、上記通話要求コマンドで指定されたＱｏＳ情報を含むＱｏＳ設定コマンドを送信するステップと、（ｅ）上記発側ルータから上記着側端末を収容している着側ルータに至る経路上の各ルータで指定ＱｏＳの設定可否を示すリターン情報を付加しながら、上記ＱｏＳ設定コマンドを上記着側呼制御サーバに転送するステップと、（ｆ）上記着側呼制御サーバが、上記ＱｏＳ設定コマンドのリターン情報から上記発側ルータと着側ルータ間に所望のＱｏＳが確保されたことを確認して、上記着側端末に通話要求コマンドを送信するステップとを有することを特徴とする。
【００１１】
本発明の１実施例によれば、上記ＱｏＳ設定コマンドのリターン情報から、発側ルータと着側ルータ間に所望のＱｏＳを確保できなかったことが判明した時、上記着側呼制御サーバから発側サーバに、呼接続を拒絶するコマンドが送信される。また、この時、上記着側呼制御サーバから着側ルータを経由して発側ルータに、上記ＱｏＳ設定を解除するためのコマンドが送信される。
【００１２】
【発明の実施の形態】
以下、本発明の実施形態について、図面を参照して説明する。
図１は、本発明の音声データ通信方法が適用される通信ネットワークの構成の１例を示す。
図１において、１はパケット網、２は公衆電話網であり、パケット網１は、複数のルータ５ｎ（ｎ＝１、２、…）からなり、これらのサーバには、呼制御サーバ装置３（３−１、３−２）、ＩＰ電話クライアント端末６（６−１、６−２）、ＩＰ電話機７（７−１、７−２）、および、パケット網に接続された端末アドレス情報を管理するためのＤＮＳ（Domain Name System）サーバ９が接続されている。また、一般の電話機８を収容した公衆電話網２は、ゲートウエイ（Gate Way:ＧＷ）装置４を介して上記パケット網１に接続されている。
【００１３】
図２は、クライアント端末６の構成を示す。
クライアント端末６は、ＣＰＵ１０と、上記ＣＰＵ１０で実行する通信プログラム等が格納されたメモリ１１と、各種のテーブルデータを記憶するための蓄積装置１２と、パケット網１に接続するための通信網インタフェース１３と、音声入力用の第１入力装置（マイク）１４Ａと、データ入力用の第２の入力装置（キーボード、マウス、ペン等）１４Ｂと、音声出力用の第1の出力装置（スピーカ）１５Ａと、データ出力用の第2の出力装置（ディスプレイ等）１５Ｂと、送信データ処理回路１００Ｔと、受信パケット処理回路１００Ｒと、これらの要素を相互接続する内部バスとからなる。
【００１４】
送信データ処理回路１００Ｔは、第１入力装置１４Ａから入力されたアナログ音声信号をディジタル信号に変換するためのＡ／Ｄ変換器１５と、ディジタル化された音声信号を圧縮、符号化するための符号化回路（Coder）１６と、上記Coder１６から出力された符号化音声データにシーケンス番号等の制御情報を付加して、図２３で後述する所定フォーマットのデータブロックを生成するためのデータパケット化回路１７と、上記音声データパケットおよび後述する呼制御用のコマンドパケットにＴＣＰ／ＵＤＰヘッダとＩＰヘッダを付加し、ＩＰパケットとして通信網インタフェース１３に出力するネットワークパケット化回路１８とからなる。
【００１５】
受信パケット処理回路１００Ｒは、通信網インタフェース１３から受信されたＩＰパケットからヘッダ情報を除去し、データフィールドの内容を出力するネットワークパケット分解回路２２と、上記データフィールドの内容を識別し、コマンドパケットと音声データパケットとに振り分けるデータ／コマンド振分け回路２３と、音声データパケットをバッファリングするためのデータキュー２４と、上記データキュー２４から音声データパケットを読み出し、各音声データパケットの制御情報をチェックしながら符号化音声データを出力する符号化音声データ抽出回路２５と、上記符号化音声データを復号化する復号化回路（Decoder）２６と、復号化されたディジタル音声データをアナログ音声信号に変換するためのＤ／Ａ変換回路２７とからなる。
【００１６】
第２入力装置１４Ｂからの入力データは、メモリ１１に格納されたプログラムの一部を構成するイベント解析ルーチン１９によって解析され、上記入力データが呼設定に関するイベントの場合、コマンドパケット化ルーチン２０によって所定フォーマットのコマンドパケットが生成され、ネットワークパケット化回路１８に供給される。上記コマンドパケットの生成に必要な各種制御情報や呼制御の状態遷移は、発信呼制御処理ルーチン２１によって管理されている。一方、データ／コマンド振り分け回路２３で識別されたコマンドパケットは、メモリ１１に格納されたプログラムの一部を構成するコマンド解析処理２９によって受信コマンドの種別が解析される。受信コマンドがユーザに通知すべきコマンドの場合、受信コマンドに対応した出力メッセージまたは出力信号が出力データ生成ルーチン３０によって生成され、第２出力装置１５Ｂに出力される。音声パケットの受信状態や呼制御状態遷移は、受信呼制御処理ルーチン３１によって管理される。
【００１７】
ここでは、音声データのパケット化とネットワークパケット化、受信パケットの分解、データ／コマンド振り分け、符号化音声データの抽出をハードウエア回路によって行っているが、これらの処理は、メモリ１１に格納されたプログラムルーチンによって、ソフトウェア的に実現してもよい。
【００１８】
蓄積装置１２には、図３に示すアドレス管理テーブル１１０と、図４に示す固定値テーブル１２０が形成されている。
アドレス管理テーブル１１０は、通信端末名１１１とＩＰアドレス１１２との関係を示す複数のエントリを有し、ＤＮＳサーバ９が保持するアドレス管理テーブルに対するキャッシュメモリとなっている。
【００１９】
固定値テーブル１２０は、各ＩＰ電話クライアント端末６に固有の制御情報を記憶するためのものであり、例えば、そのＩＰ電話クライアント端末に与えられた通信端末名１２１およびＩＰアドレス１２２と、該ＩＰ電話クライアント端末からの発呼を受け付ける呼制御サーバ（発側呼制御サーバ）のアドレス１２３と、該ＩＰ電話クライアント端末を収容しているルータ、すなわち、デフォルト（第１ホップ目）のルータ（発側デフォルトルータ）のアドレス１２４と、ＱｏＳ（Quality of Service）情報として、帯域１２５、最大許容遅延時間１２６および許容パケットロス率１２７と、符号化方式特定情報１２８を記憶している。
【００２０】
本発明の音声データ通信方法をＩＰ電話機７に適用する場合は、各ＩＰ電話機７に上記図２に示したＩＰ電話クライアント端末６と同様のパケット処理機能を装備すればよい。ＧＷ装置４は、公衆網２から受信した音声信号と呼制御信号をそれぞれＩＰパケットに変換してルータ５―３に転送し、逆に、ルータ５―３からの受信ＩＰパケットを音声信号または呼制御信号に変換して公衆網２に転送する。従って、公衆網との入出力インタフェースを入力装置１４Ａ、１４Ｂ、出力装置１５Ａ、１５Ｂに対応付ければ明らかなように、ＧＷ装置４に上記図２と同様の機能をもたせることによって、一般電話機８に対しても本発明の音声データ通信方法を適用できる。
【００２１】
呼制御サーバ３は、パケット網１に接続されたＧＷ装置４をＩＰ電話クライアント端末６やＩＰ電話機７と同等に扱う。以下の説明で、呼制御装置３が端末として扱うこれらの装置を総括して、メディア（音声データ）通信端末と言う。
呼制御サーバ装置３は、本発明の音声データ通信方法を実現するために、例えば、図５に示すロケーション管理テーブル２００と、図６に示すコネクション管理テーブル２１０を備えている。
【００２２】
ロケーション管理テーブル２００は、その呼制御サーバが過去に通話中継したメディア通信端末の名称２０１と、該メディア通信端末を管轄する呼制御サーバのアドレス２０２と、該メディア通信端末のデフォルト（第１ホップ目）のルータのアドレス２０３との関係を示す複数のエントリ２００―１〜２００―ｍからなっている。
コネクション管理テーブル２１０は、現在通話中の呼と対応した複数のエントリ２１０―１〜２１０―ｋからなり、各エントリは、呼に割り当てられた論理回線番号２１１と、発側（または送信元）通信端末のアドレス２１２と、発側通信端末が接続された発側（または送信元）デフォルトルータのアドレス２１３と、着側（宛先）通信端末のアドレス２１４と、着側通信端末が接続された着側（または宛先）デフォルトルータのアドレス２１５と、着側通信端末を管轄する着側（または宛先）呼制御サーバのアドレス２１６と、上記呼におけるＱｏＳ情報（帯域幅２１７、最大許容遅延時間２１８、許容パケットロス率２１９）と、上記呼で使用される音声符号化方式を特定するための定義情報２２０とを含む。
【００２３】
図７は、図１の通信ネットワークに適用した本発明による音声データ通信方法の全体的な通信手順を示す。
ここでは、ルータ５―１に収容されたＩＰ電話クライアント端末６―１を発側端末、ルータ５―７に収容されたＩＰ電話機７―２を着側端末とし、サーバ３―１を発側呼制御サーバ、３―２を着側呼制御サーバとし、発側端末６−１からの通話要求によって呼が設定され、通話終了後、着側端末７―２から切断要求によって呼が切断される迄の各装置の動作を説明する。
発側端末６−１の第２入力装置１４Ｂから、着側端末７−２の通信端末名入力を含むユーザ操作によって通話要求イベントが発生した場合、発側端末６−１において通話要求処理４４が実行され、これによって通話要求コマンド７０を含む図２６に示すＩＰパケットが生成され、発側呼制御サーバ３−１に送信される。
【００２４】
上記ＩＰパケットは、図２６に示すように、ＩＰヘッダ７１０とＩＰデータフィールド７２０とからなり、ＩＰヘッダ７１０の送信元アドレス（ＳＡ）７１１には固定値テーブル１２０から求めた発側端末６―１のＩＰアドレス１２２が設定され、宛先アドレス（ＤＡ）７１２にはアドレス管理テーブル１１０から求めた着側端末のＩＰアドレスが設定される。また、ＩＰデータフィールド７２０は、ＴＣＰ／ＵＤＰのヘッダフィールド７２１とデータフィールド７２２とからなり、上記データフィールド７２２に、コマンド種類７３０、コマンドＩＤ７３１、発側端末アドレス７３２、発側端末名７３３、着側端末アドレス７３４、着側端末名７３５、符号化方式特定情報７３６、帯域７３７、最大許容遅延時間７３８、許容パケットロス率７３９からなる通話要求コマンド７０が設定される。
【００２５】
上記通話要求処理４４では、図８に示すように、ユーザ入力イベントから宛先端末７−２の通信端末名を取得し（ステップ４４０）、該通信端末名を持つエントリがアドレス管理テーブル１１０に既に登録済みか否かをチェックする（４４１）。もし、目的エントリがアドレス管理テーブルに未登録の場合は、ＤＮＳサーバに上記宛先端末のＩＰアドレスを問合わせ（４４２）、上記宛先端末の名称１１１とＩＰアドレス１１２との関係を示す新たなエントリをアドレス管理テーブル１１０に登録（４４３）した後、通話要求コマンド７０を生成し（４４４）、上記通話要求コマンド７０を含むＩＰパケットを発側呼制御サーバに送信する（４４５）。この時、通話要求コマンド７０に含まれる発側端末アドレス７３２、発側端末名７３３、符号化方式特定情報７３６およびＱｏＳ情報７３７〜７３９は固定値テーブル１２０から得られ、着側端末アドレス７３４と着側端末名７３５は、上述したアドレス管理テーブル１１０の目的エントリの内容と対応している。また、ＩＰパケットヘッダの送信元アドレス７１１と宛先アドレス７１２には、固定値テーブル１２０から得た発側端末６−１のＩＰアドレス１２２と発側呼制御サーバアドレス１２３とがそれぞれ設定される。
【００２６】
上記通話要求コマンド７０の受信に応答して、発側呼制御サーバ装置３−１は、呼接続処理４５を行い、図２７に示す呼接続コマンド７１を含むＩＰパケットを生成して、着側呼制御サーバ装置３−２に送信する。上記呼接続コマンド７１は、受信した通話要求コマンド７０に含まれる項目７３０〜７３９に、更に、発側デフォルトルータアドレス７４０を追加した内容となっている。
上記呼接続処理４５では、図９に示すように、受信した通話要求コマンド７０から抽出した発側端末名７３３と着側端末名７３５に基づいて、ロケーション管理テーブル２００を参照し、上記発側端末名７３３と対応するデフォルトルータアドレス（発側ルータアドレス）と、上記着側端末名７３５と対応する呼制御サーバアドレス（着側呼制御サーバアドレス）を求め（４５０）、これらのアドレスと、上記通話要求コマンド７０から抽出された発側端末アドレス７３２、着側端末アドレス７３４、符号化方式定義情報７３６、ＱｏＳ情報７３７−７３９を含む新たなエントリをコネクション管理テーブル２１０に追加する（４５１）。次に、上記通話要求コマンド７０の内容と上記発側デフォルトルータアドレスとに基づいて、図２７に示すフォーマットの呼接続コマンド７１を含むＩＰパケットを生成し（４５２）、これを着側呼制御サーバ３−２に送信する（４５３）。
【００２７】
着側呼制御サーバ装置３−２は、上記呼接続コマンド７１の受信に応答して呼接続受信処理４６を行う。呼接続受信処理４６では、図１０に示すように、受信した呼接続コマンド７１から抽出した発側端末名７３５に基づいて、ロケーション管理テーブル２００を参照し、上記着側端末名と対応する着側デフォルトルータアドレスを検索し（４６０）、上記着側デフォルトルータアドレスと、上記呼接続コマンド７１から抽出したその他の項目とに基づいて新たなテーブルエントリを生成し、これをコネクション管理テーブル２１０に登録する（４６１）。
【００２８】
この場合、着側呼制御サーバ３−２のコネクション管理テーブル２１０では、管轄下にある端末７−２を発側、通信相手となる端末６−１を着側として上記テーブルエントリが生成され、上記呼接続コマンド７１のＩＰヘッダに送信元アドレスとして設定された発側呼制御サーバ３−１のアドレスが着側呼制御サーバアドレス２１６として記憶される。着側呼制御サーバ装置３−２は、次に、呼設定ＡＣＫコマンド７２を生成し（４６２）、この呼設定ＡＣＫコマンド７２を含むＩＰパケットを発側の呼制御サーバ３−１に送信する（４６３）。上記呼設定ＡＣＫコマンド７２には、発側、着側の端末アドレスの他に、ステップ４６０で検索した着側デフォルトルータアドレスが含まれている。
【００２９】
発側呼制御サーバ３−１は、上記呼接続ＡＣＫコマンド７２を受信すると、ＱｏＳ設定処理４７を実行する。上記ＱｏＳ設定処理４７では、図１１に示すように、受信した呼接続ＡＣＫコマンド７２から着側デフォルトルータアドレスを抽出し、これを上記呼接続ＡＣＫコマンド７２の発側、着側端末アドレスで特定されるコネクション管理テーブル２１０の該当エントリのフィールド２１５に追加する（ステップ４７９）。次に、上記テーブルエントリの内容に基づいて、図２８に示すＱｏＳ設定コマンド７３を生成し（ステップ４７１）、上記ＱｏＳ設定コマンド７３を含むＩＰパケットをカプセル化して、発側デフォルトルータ５−１に送信する（ステップ４７２）。尚、この実施例では、着側デフォルトルータアドレスを呼接続ＡＣＫコマンド７２の受信時にコネクション管理テーブル２１０に設定しているが、この着側デフォルトルータアドレスの設定は、前述の呼接続処理４５で行ってもよい。
【００３０】
上記ＱｏＳ設定コマンド７３は、図２８に示すように、コマンド種別７３０、コマンドＩＤ７３１、発側端末アドレス７３２、着側端末アドレス７３４、符号化方式情報７３６、ＱｏＳ情報７３７〜７３９の他に、発側デフォルトルータアドレス７４０、着側呼制御サーバアドレス７４１、着側デフォルトルータアドレス７４２と、リターン値設定フィールド７４３を含み、ＩＰヘッダの送信元アドレス（ＳＡ）と宛先アドレス（ＤＡ）には、発側呼制御サーバ３−１と着側呼制御サーバ３−２のアドレスがそれぞれ設定される。また、上記ＩＰヘッダの前に付されるカプセル化ヘッダには、送信元アドレス（ＳＡ）として発側呼制御サーバ３−１のアドレス、宛先アドレス（ＤＡ）として発側デフォルトルータ５−１のアドレスがそれぞれ設定され、プロトコルタイプ（プロトコル番号）として、このＩＰパケットがＱｏＳ設定コマンドであることを示す特定の番号（以下、“ｘｘ”で示す）を含む。
【００３１】
発側ルータ５−１は、上記ＱｏＳ設定コマンド７３を含むカプセル化ＩＰパケットを受信すると、プロトコル番号が“ｘｘ”であることから、受信パケットをＱｏＳ設定コマンド７３と解釈し、ＱｏＳ設定コマンド７３の発側デフォルトルータアドレス７４０と着側デフォルトルータアドレス７４２をチェックする。この場合、発側デフォルトルータアドレス７４０が自分のアドレスに一致しているため、発側ルータ５−１は、カプセル化ＩＰパケットの送信元アドレス（ＳＡ）を自分のアドレス、宛先アドレス（ＤＡ）を着側デフォルトルータアドレス７４２にそれぞれ書き換えて、ネットワークに送出する。
着側ルータ５−７が、上記ＱｏＳ設定コマンド７３を含むカプセル化ＩＰパケットを受信すると、プロトコル番号が“ｘｘ”であることから、受信パケットをＱｏＳ設定コマンド７３と解釈し、発側ルータ５−１と同様に、ＱｏＳ設定コマンド７３の発側デフォルトルータアドレス７４０と着側デフォルトルータアドレス７４２をチェックする。この場合、着側デフォルトルータアドレス７４２が自分のアドレスに一致しているため、着側ルータ５−１は、カプセル化を解除し、発側呼制御サーバ３−１が発行した元のＩＰパケットに戻して、ネットワークに送出する。
【００３２】
上記中継動作によって、 ＱｏＳ設定コマンド７３は着側呼制御サーバ３−２に転送される。上述したＱｏＳ設定コマンド７３の中継過程において、各ルータは、受信したＱｏＳ設定コマンド７３で指定されたＱｏＳ情報７３７〜７３９を満足するリソースが確保できるか否かを判定し、それぞれの判定結果に従って、フィールド７４３にＱｏＳ設定可否を示すリターン値を設定する。何れかの中継ルータがＱｏＳ設定不可を示した場合は、エラーリターンとなり、呼設定は不成功に終わる。但し、上記ＱｏＳ設定が可能なルータを検索しながら経路を設定する場合はこの限りではない。
着側呼制御サーバ３−２は、ルータ５−７から上記ＱｏＳ設定コマンドを含むＩＰパケットを受信すると、リターン値設定フィールド７４３をチェックし、もし、リターン値がＱｏＳ設定可を示す場合は、通話要求中継処理４８を実行し、リターン値がＱｏＳ設定不可を示していた場合、すなわちエラーリターンとなっていた場合は、後述する呼接続拒絶処理５１を実行する。
【００３３】
上記通話要求中継処理４８では、図１２に示すように、ＱｏＳ設定コマンド７３から発側端末アドレス７３２と着側端末アドレス７３４を抽出し、コネクション管理テーブル２１０の上記発側端末アドレスと対応するテーブルエントリから、符号化方式の定義情報を取得する（ステップ４８０）。次に、上記符号化方式定義情報と着側端末アドレスを含む通話要求コマンド７４を生成し（４８１）、該通話要求コマンド７４を含むＩＰパケットを着側端末７−２に送信する（ステップ４８２）。
着側端末７−２は、呼制御サーバ３−２から上記通話要求コマンド７４を受信すると、端末ユーザに通話の着信を通知し、ユーザからの応答イベントを処理するための通話要求受信処理４９を実行する。もし、ユーザから通話拒絶イベント７６を受けた場合は、呼制御サーバ３−２に通話拒絶コマンド７７を応答するための通話拒絶処理５０を実行し、通話許諾イベント８２を受けた場合は、通話許諾コマンド８３を応答するための通話許諾処理５４を実行する。
【００３４】
上記通話要求受信処理４９では、図１３に示すように、通話要求コマンド７４から発側端末アドレスと、符号化方式の定義情報を抽出し（ステップ４９０）、これらの情報を図示しない通話管理テーブルに登録する（４９１）。次に、図２に示した符号化回路（Coder）１６と復号化回路（Decoder）２６に、上記定義情報に従った符号化方式のパラメータを設定し（４９２）、着信通知メッセージを第２出力装置１５Ｂに出力する（４９３）。上記着信通知メッセージに対するユーザからの応答待ち時間を制限するためのタイマを起動し（４９４）、ユーザから応答を判定する。ユーザから通話受諾応答があった場合（４９５）、発側、着側の端末アドレスを含む通話受諾コマンド８２を生成し、該通話受諾コマンドを含むＩＰパケットを着側呼制御サーバ装置３−２に送信する（通話受諾処理５４）。この後、図７に示す発側端末の音声データ送受信処理５７と同様の音声データ送受信処理４９８を開始する。ユーザから通話拒絶応答があった場合（４９６）、または、タイマがタイムアウトとなった場合（４９７）は、通話拒絶処理５０を実行する。
【００３５】
上記通話拒絶処理５０では、図１４に示すように、発側、着側の端末アドレスを含む通話拒絶コマンド７７を生成し（ステップ５００）、上記通話拒絶コマンド７７を含むＩＰパケットを呼制御サーバ装置３−２に送信（５０１）した後、符号化回路１６と復号化回路２６を初期化する（５０２）。
エラーリターンを含むＱｏＳ設定コマンド７３（ＱｏＳ設定エラー通知７８）を受信した場合、あるいは着側端末７−２から通話拒絶コマンド７７を受信した場合は、着側呼制御サーバ３−２は、呼接続拒絶処理５１を実行する。
【００３６】
上記呼接続拒絶処理５１では、図１５に示すように、受信した通話接続拒絶コマンド７７、またはＱｏＳ設定エラー通知７８に含まれる着側、発側の端末アドレスに基づいて、コネクション管理テーブル２１０を参照し、着側呼制御サーバアドレス２１６として記憶されて発側の呼制御サーバ３−１のアドレスを取得する（ステップ５１０）。次に、呼接続拒絶原因と、発側端末６−１および着側端末７−２のアドレスとを含む呼接続拒絶コマンド８０を生成し（５１１）、該コマンドを上記ステップ５１０で取得した発側呼制御サーバ３−１宛に送信する（５１２）。今回の呼接続拒絶がＱｏＳ設定エラー通知７８に起因していた場合（５１３）は、コネクション管理テーブル２１０から該当エントリを削除して（５１７）、このルーチンを終了する。
【００３７】
呼接続拒絶が端末ユーザからの通話拒絶コマンド７６に起因していた場合は、コネクション管理テーブル２１０から発側、着側のデフォルトルータアドレス２１３、２１５を取得し（５１４）、これらのアドレス情報を含むＱｏＳリリースコマンド７９を生成し（５１５）、これをＩＰパケットとして着側ルータ５−７に送信（５１６）した後、コネクション管理テーブル２１０から該当エントリを削除する（５１７）。上記ＱｏＳリリースコマンド７９は、ＱｏＳ設定コマンド４７の経路を逆方向に辿ってデフォルトルータ５−１まで中継される。経路上の各ルータは、上記ＱｏＳリリースコマンド７９の受信に応答して、ＱｏＳ設定コマンド４７受信時に確保していた通信リソースを順次に解放していく。
【００３８】
呼接続拒絶コマンド８０を受信した発側呼制御サーバ装置３−１は、通話拒絶中継処理５２を実行する。上記通話拒絶中継処理５２では、図１６に示すように、通話拒絶原因を含む通話拒絶コマンド８１を生成し（ステップ５２０）、上記通話拒絶コマンド８１を含むＩＰパケットを発側端末６−１へ送信（５２１）した後、上記呼接続拒絶コマンド８０の発側、着側の端末アドレスに基づいて、コネクション管理テーブル２１０から該当エントリを削除する（５２２）。
【００３９】
通話拒絶コマンド８１を受信した発側端末６−１は、通話拒絶受信処理５３を実行する。上記通話拒絶受信処理５３では、図１７に示すように、通話拒絶コマンド８１が示す通話拒絶原因に応じて、ユーザに通知すべきメッセージを生成し、これを第２出力装置１５Ｂに出力する（ステップ５３０）。この後、符号化回路１６、復号化回路２６を初期化し（５３１）、発側呼制御サーバ装置３−１とのコネクションを切断する（５３２）。
【００４０】
着側の呼制御サーバ装置３−２は、着側端末７−２から通話受諾コマンド８３を受信すると、呼確立処理５５を実行する。上記呼確立処理５５では、図１８に示すように、受信した通話受諾コマンド８３に含まれる発側、着側の端末アドレスに基づいて、コネクション管理テーブル２１０から発側呼制御サーバアドレスを取得する（ステップ５５０）。次に、発側、着側端末のアドレスを含み、呼が確立されたことを示す呼確立コマンド８４を生成し（５５１）、該呼確立コマンドを含むＩＰパケットを発側呼制御サーバ３−１に対して送信する（５５２）。
【００４１】
上記呼確立コマンド８４を受信した発側呼制御サーバ３−１は、通話要求受諾中継処理５６を実行する。上記通話受諾中継処理５６では、図１９に示すように、通話受諾コマンド８５を生成し（ステップ５６０）、受信した前記呼確立コマンドが示す発側端末アドレスに基づいて、上記通話受諾コマンド８５を発側端末６−１に送信する（５６１）。
【００４２】
発側端末６−１は、上記通話受諾コマンド８５を受信すると、音声データ送受信処理５７を開始する。これによって発側端末６−１と着側端末７−２との間で通話音声データの送受信が可能となる。
上記音声データ送受信処理５７が開始されると、符号化回路１６で圧縮された符号化音声データがデータパケット化回路１７によって次々と音声パケットに変換される。各音声パケットは、図２９に示すように、コマンド種別７３０と、符号化方式定義情報７５０と、シーケンス番号７５１と、タイムスタンプ（時刻情報）７５２と、符号化音声データ７５３とからなる。各音声パケットは、ネットワークパケット化回路１８によってＩＰヘッダが付加された後、通信網インタフェース１３を介してパケット網１に送出される。一方、パケット網１から受信されたＩＰパケットは、ネットワークパケット分解回路２２とデータ／コマンド振り分け回路２３で処理され、各受信パケットに含まれる符号化音声データが符号化音声データ抽出回路２５で抽出され、復号化回路２６に供給される。
【００４３】
発側端末６−１と着側端末７−２との間での通話が終了し、例えば、着側端末７−２のユーザが通話切断８６の操作を行った場合、着側端末７−２では、通話切断処理５８が実行される。上記通話切断処理５８では、図２０に示すように、通話切断コマンド８７を生成し（ステップ５８０）、該通話切断コマンド８７を含むＩＰパケットを着側呼制御サーバ３−２に送信（５８１）した後、符号化回路１６を含む送信データ処理回路１００Ｔと、復号化回路２６を含む受信パケット処理回路１００Ｒを初期化する（５８２）。
【００４４】
上記通話切断コマンド８７を受信した着側呼制御サーバ３−２は、呼切断処理５９を実行する。上記呼切断処理５９では、図２１に示すように、着側端末７−２と発側端末６−１のアドレスを含む呼切断コマンド８８を生成し（ステップ５９０）、コネクション管理テーブル２１０から求めた呼制御サーバアドレス２１６に従って、上記呼切断コマンドを含むＩＰパケットを発側呼制御サーバアドレス３−１に送信する（５９１）。次に、ＱｏＳリソースを開放するためのＱｏＳリリースコマンド８９を生成し（５９２）、該コマンドを含むＩＰパケットを着側デフォルトルータ５−７経由で発側デフォルトルータ５−１に送信（５９３）した後、コネクション管理テーブル２１０から該当コネクションのエントリを削除する（５９４）。
【００４５】
発側呼制御サーバ装置３−１は、上記呼切断コマンド８８を受信すると、通話切断中継処理６０を実行する。上記通話切断中継処理６０では、図２２に示すように、通話切断コマンド９０を生成し（ステップ６００）、上記呼切断コマンド８８が示す発側端末アドレスに従って、上記通話切断コマンド９０を含むＩＰパケットを発側端末６−１に送信（６０１）した後、コネクション管理テーブル２１０から該当エントリを削除する（６０２）。
【００４６】
発側端末６−１は、上記通話切断コマンド９０を受信すると、通話切断受信処理６１を実行する。上記通話切断受信処理６１では、図２３に示すように、ユーザにコネクションの切断を通知するための切断メッセージを生成し、第２出力装置１５Ｂに出力する（ステップ６１０）。この後、送信データ処理回路１００Ｔと受信パケット処理回路１００Ｒを初期化し（６１１）、呼制御サーバ装置３−２とのコネクションを切断する（６１２）。
【００４７】
図２４は、発側、着側の各端末装置６−１、７−２で実行される通話制御プログラムのフローチャートを示す。
通話制御プログラムが起動されると（ステップ２００）、第２入力装置１４Ｂからのイベント入力の有無を検知する（２０１）。もし、イベント入力があった場合、入力イベントの種類を判定し、入力イベントに応じた処理を実行する。入力イベントが通話要求であれば（２０２）通話要求処理４４、切断要求であれば（２０３）通話切断処理５８、通話拒絶であれば（２０４）通話拒絶処理５０、通話許諾であれば（２０５）通話受諾処理５４をそれぞれ実行する。入力イベントが上記の何れにも該当しなかった場合、あるいは、上記所定の処理を終えた場合、通話制御プログラムの終了指示かあったか否かを判定し（２２０）、終了指示があった場合は、本ルーチンを終了し、そうでなければ、ステップ２０１に戻る。
【００４８】
ステップ２０１で、ユーザからのイベント入力がなかった場合、パケット網１からのパケットの着信の有無を判定する（２１０）。パケットが着信していなければ、ステップ２２０に進む。パケットが着信していた場合、受信パケットが呼制御用のコマンドか否かを判定し（２１１）、呼制御コマンドでなければ、音声データの受信処理５７Ｒを行う。受信パケットが呼制御コマンドの場合、受信コマンドの種類に応じた処理を事項する。受信コマンドが通話要求コマンド７０であれば（２１２）通話要求受信処理４９、通話切断コマンド８７であれば（２１３）通話切断受信処理６１を実行する。また、受信コマンドが通話受諾コマンド８３であれば（２１４）、音声データ送受信処理５７を開始し、通話拒絶コマンド７７であれば（２１５）、通話拒絶受信処理５３を実行する。受信コマンドがこれらの何れにも該当しなかった場合、あるいは、上記所定の処理を終了した場合、ステップ２２０に進む。
【００４９】
図２５は、呼制御サーバ装置３−１、３−２で実行される呼制御プログラムのフローチャートを示す。このプログラムが起動されると（ステップ３００）、パケット網１からのパケットの着信の有無を検出し（３０１）し、パケットが着信していた場合、上記受信パケットに含まれる受信コマンドが、クライアント端末から発行された呼接続制御コマンドか否か判定する（３０２）。
受信コマンドがクライアント端末から発行されたコマンドの場合、受信コマンドの種類に応じた処理を実行する。受信コマンドが通話要求コマンド７０であれば（３０３）呼接続処理４５、通話切断コマンド８７であれば（３０４）呼切断処理５９、通話受諾コマンド８３であれば（３０５）呼確立処理５５、通話拒絶コマンド７７であれば（３０６）呼接続拒絶処理５１をそれぞれ実行する。受信コマンドが上記何れにも該当しなかった場合、または、上記所定の処理を終えた場合、呼制御プログラムの終了指示の有無を判定し（３３０）、終了指示があった場合は、本ルーチンを終了し、そうでない場合は、ステップ３０１に戻る。
【００５０】
ステップ３０２で、受信コマンドがクライアント端末からのものではなかった場合、該コマンドが他の呼制御サーバ装置から発行された呼制御コマンドか否かを判定する（３１０）。もし、そうであれば、受信コマンドの種類に応じた処理を実行する。受信コマンドが呼接続コマンド７１であれば（３１１）呼接続受信処理４６、呼接続ＡＣＫコマンド７２であれば（３１２）ＱｏＳ設定処理４７、呼接続拒絶コマンド８０であれば（３１３）通話拒絶中継処理５２、呼確立コマンド８４であれば（３１４）通話受諾中継処理５６、呼切断コマンド８７であれば（３１５）通話絶断中継処理６０をそれぞれ実行する。
【００５１】
ステップ３１０において、受信コマンドが他の呼制御サーバ装置から発行された呼制御コマンドではなかった場合、該コマンドがＱｏＳ設定コマンドか否かを判定し（ステップ３２０）、ＱｏＳコマンドでなければステップ３０１に戻る。受信コマンドがＱｏＳコマンドの場合、該ＱｏＳコマンドのリターン値がＱｏＳ設定可能な状態を示しているか否かを判定し（３２１）、もし、ＱｏＳ設定が可能であれば、通話要求中継処理５８を実行し、ＱｏＳ設定が不能であれば、呼接続拒絶処理５１を実行して、ステップ３３０に進む。
【００５２】
【発明の効果】
以上の実施形態から明らかなように、本発明によれば、音声データ通信端末のコネクション設定を呼制御サーバで行い、且つ、各音声データ通信端末を収容しているデフォルトルータを経由して通話に必要なＱｏＳ設定を行うようにしているため、実際にメディアデータが通るパス上でのＱｏＳ制御が可能となる。また、本発明によれば、音声データ通信端末のコネクション設定を呼制御サーバで代行することによって、各音声データ通信端末の処理負荷を軽減できる。
【図面の簡単な説明】
【図１】本発明の音声データ通信方法が適用される通信ネットワークの構成の１例を示す図。
【図２】図１におけるクライアント端末６の構成図。
【図３】通信端末６が備えるアドレス管理テーブル１１０の構成図。
【図４】通信端末６が備える固定値テーブル１２０の構成図。
【図５】図１における呼制御サーバ３が備える通信端末ロケーション管理テーブル２００の構成図。
【図６】呼制御サーバ装置３が備えるコネクション管理テーブル２１０の構成図。
【図７】図１の通信ネットワークにおける本発明による音声データ通信方法の全体的な通信手順を示す図。
【図８】図７における通話要求処理４４の詳細を示すフローチャート。
【図９】図７における呼接続処理４５の詳細を示すフローチャート。
【図１０】図７における呼接続受信処理４６の詳細を示すフローチャート。
【図１１】図７におけるＱｏＳ設定処理４７の詳細を示すフローチャート。
【図１２】図７における通話要求中継処理４８の詳細を示すフローチャート。
【図１３】図７における通話要求受信処理４９の詳細を示すフローチャート。
【図１４】図７における通話拒絶処理５０の詳細を示すフローチャート。
【図１５】図７における呼接続拒絶処理５１の詳細を示すフローチャート。
【図１６】図７における通話拒絶中継処理５２の詳細を示すフローチャート。
【図１７】図７における通話拒絶受信処理５３の詳細を示すフローチャート。
【図１８】図７における呼確立処理５５の詳細を示すフローチャート。
【図１９】図７における通話受諾中継処理５６の詳細を示すフローチャート。
【図２０】図７における通話切断処理５８の詳細を示すフローチャート。
【図２１】図７における呼切断処理５９の詳細を示すフローチャート。
【図２２】図７における通話切断中継処理６０の詳細を示すフローチャート。
【図２３】図７における通話切断受信処理６１の詳細を示すフローチャート。
【図２４】通信端末６で実行される通話制御プログラムのフローチャート。
【図２５】呼制御サーバ３で実行される呼制御プログラムのフローチャート。
【図２６】ＩＰパケットと通話要求コマンド７０のフォーマットの１例を示す図。
【図２７】呼接続コマンド７１のフォーマットの１例を示す図。
【図２８】ＱｏＳ設定コマンド７３のフォーマットの１例を示す図。
【図２９】音声パケットのフォーマットの１例を示す図。
【符号の説明】
１：パケット網、２：公衆電話網、３：呼制御サーバ、４：音声データ中継装置（ゲートウェイ）、５：ルータ、６、７：音声データ通信端末
【発明の属する技術分野】
本発明は、マルチメディア通信システムに関し、更に詳しくは、インターネットにおいてリアルタイム情報を中継するための呼制御サーバおよびデータ通信方法に関する。
【０００２】
【従来の技術】
近年、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）をベースとするインターネットが急速に普及している。特に、音声端末をインターネットを介して接続し、音声データをリアルタイムに送受信することによって、従来の電話網と同様の通話を提供するインターネット電話サービスが開始され、音声系データをインターネット上に統合しようという動きが活発になってきている。インターネット電話では、例えば、一般の電話機からインターネット内の第１アクセスポイントにアクセスし、このアクセスポイントから通話相手の電話機に近い第２アクセスポイント迄の区間にインターネットを利用し、第２アクセスポイントから相手電話機迄の区間は公衆電話網を利用するタイプの通信形態が注目されている。
【０００３】
インターネット電話を実現する場合、例えば、音声入出力処理用のハードウェアと制御用ソフトウェアを搭載したインターネット電話機能をもつパーソナル・コンピュータ（以下、ＰＣと言う）間で通話するタイプと、既存の電話機とインターネット電話機能を備えたクライアントＰＣとの間でゲートウェイ装置を介して通話するタイプと、一般の電話機間の通話をゲートウェイ装置で中継するタイプの３つに分けられる。一般の電話機との間の通話をインターネットで中継する場合、呼制御手順の変換処理と、音声データ形式の変換処理とが必要となる。
【０００４】
標準化団体ＩＴＵ−Ｔでは、マルチメディア通信端末の構成として、上記２つの変換処理モジュールをそれぞれプロトコルとしてまとめたＨ.３２３勧告を規定している。Ｈ.３２３に準拠したインターネット電話システムでは、従来、上記呼制御手順の変換処理と音声データの変換処理とを一つのクライアントＰＣ、あるいはゲートウェイ装置に同居させるのが一般的であった。
しかしながら、Ｈ.３２３で規定されている呼制御手順の変換プロトコルは複雑であり、クライアントＰＣやＩＰ電話機（外観は通常の電話機と類似しているが、音声データの変換処理、音声データのＩＰパケット化、ＩＰ網へのパケット転送処理機能を備えた端末）に上記機能を装備させるには処理負荷が大き過ぎるという意見が出されたため、１９９８年末から、インターネットの標準化策定団体であるＩＥＴＦにおいて、呼制御手順の変換処理と音声データの変換処理とを別々の装置で行うシンプル化されたプロトコルが検討され始めている（megaco-BOFにおいて議論"draft-huitema-MGCP-v0r1-01.txt（expire：99/5）"）。
【０００５】
また、マルチメディアデータ転送の増加に伴い、インターネットの網側の機能として、予め各通信に必要な帯域を確保したり、優先制御を行うためのＱｏＳ(Quality of Service)保証プロトコルの標準化作業が、例えば、ＲＳＶＰ(Resource Reservation Protocol)や、ｄｉｆｆｓｅｒｖ（differenciated services）等で進められており、これらを利用することにより、リアルタイム系のメディア通信の品質保証が可能となってきている。
上記標準化作業に関しては、ＩＥＴＦのRFC2205 “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）”等に記載されている。また、インターネットにおける音声通信に関しては、例えば、雑誌、日経コミュニケーション、１９９９年２月１日号に、“VoIPゲートウェイ 音声をネットで中継”と題する報告がある。
【０００６】
【発明が解決しようとする課題】
然るに、呼制御変換処理とデータ変換処理とを別装置で行うインターネット電話システムでは、ＱｏＳ保証機能を持ったインターネット上で音声通話の中継を行う場合、網へのＱｏＳ要求は呼制御変換装置（以下、呼制御サーバと言う）で行われ、実際のデータ転送処理はルータ等のデータ変換装置（以下、メディア通信装置と言う）で行われるため、ＱｏＳ要求に従ってリソースが確保された経路と、実際にデータが転送される経路とが必ずしも一致せず、特に、呼制御サーバ装置とメディア通信装置とが互いに別の網セグメントに位置している場合、ＱｏＳの保証が完全ではない。
【０００７】
本発明の目的は、呼制御変換処理とデータ変換処理とを別装置で行った場合にＱｏＳを保証できるパケット網を提供することにある。
本発明の他の目的は、パケット網においてクライアント端末装置から要求されたＱｏＳを保証した音声データ通信方法を提供することにある。
本発明の更に他の目的は、パケット網においてクライアント端末装置から要求されたＱｏＳを保証した音声データ通信を可能とする呼制御サーバを提供することにある。
【０００８】
【課題を解決するための手段】
上記課題を解決するために、本発明では、クライアント端末から通話要求を受信した呼制御サーバが、着側端末を管轄する着側呼制御サーバとの間で呼設定手順を実行すると共に、発側端末を収容している発側ルータと着側端末を収容している着側ルータとの間に、上記通話要求で指定されたＱｏＳのリソース確保を指令することを特徴とする。
更に詳述すると、本発明の呼制御サーバは、音声データ通信端末から送信されたＱｏＳ情報を含む通話要求コマンドの受信に応答して、通話相手となる着側端末を管轄する着側呼制御サーバに対して呼接続コマンドを送信するための第１手段と、上記着側呼制御サーバからの呼接続ＡＣＫコマンドの受信に応答して、上記発側の音声データ通信端末を収容している発側ルータに対して、上記通話要求コマンドで指定されたＱｏＳ情報を含むＱｏＳ設定コマンドを送信するための第２手段とを備えたことを特徴とする。
【０００９】
本発明の１実施例によれば、上記呼制御サーバは、各通信端末と、該通信端末を管轄する呼制御サーバのアドレスと、デフォルトルータアドレスとの関係を記憶するロケーション管理テーブルと、コネクション毎に、少なくとも発側、着側の端末アドレスと、ＱｏＳ情報とを記憶するコネクション管理テーブルとを有し、前記第１手段が、前記通話要求コマンドの受信に応答して、上記コネクション管理テーブルに新たなエントリを追加し、上記ロケーション管理テーブルを参照して、前記通話要求コマンドで指定された着側端末と対応する着側呼制御サーバのアドレスを求め、前記第２手段が、前記呼接続ＡＣＫコマンドの受信に応答して、上記コネクション管理テーブルを参照し、前記ＱｏＳ情報を含むＱｏＳ設定コマンドを生成することを特徴とする。
【００１０】
本発明の音声データの通信方法は、複数のルータと複数の呼制御サーバとを有するＩＰパケット網において、（ａ）音声データの送信に先だって、上記ＩＰパケット網に接続された発側の通信端末から該端末を管轄する発側の呼制御サーバに、着側端末とＱｏＳ情報を特定した通話要求コマンドを送信するステップと、（ｂ）上記通話要求コマンドの受信に応答して、上記発側の呼制御サーバから上記着側端末を管轄する着側の呼制御サーバに、着側端末とＱｏＳ情報を特定した呼接続コマンドを送信するステップと、（ｃ）上記着側呼制御サーバから上記発側呼制御サーバに、呼接続ＡＣＫコマンドを送信ステップと、（ｄ）上記呼接続ＡＣＫコマンドの受信に応答して、上記発側呼制御サーバから上記発側端末を収容している発側ルータに、上記通話要求コマンドで指定されたＱｏＳ情報を含むＱｏＳ設定コマンドを送信するステップと、（ｅ）上記発側ルータから上記着側端末を収容している着側ルータに至る経路上の各ルータで指定ＱｏＳの設定可否を示すリターン情報を付加しながら、上記ＱｏＳ設定コマンドを上記着側呼制御サーバに転送するステップと、（ｆ）上記着側呼制御サーバが、上記ＱｏＳ設定コマンドのリターン情報から上記発側ルータと着側ルータ間に所望のＱｏＳが確保されたことを確認して、上記着側端末に通話要求コマンドを送信するステップとを有することを特徴とする。
【００１１】
本発明の１実施例によれば、上記ＱｏＳ設定コマンドのリターン情報から、発側ルータと着側ルータ間に所望のＱｏＳを確保できなかったことが判明した時、上記着側呼制御サーバから発側サーバに、呼接続を拒絶するコマンドが送信される。また、この時、上記着側呼制御サーバから着側ルータを経由して発側ルータに、上記ＱｏＳ設定を解除するためのコマンドが送信される。
【００１２】
【発明の実施の形態】
以下、本発明の実施形態について、図面を参照して説明する。
図１は、本発明の音声データ通信方法が適用される通信ネットワークの構成の１例を示す。
図１において、１はパケット網、２は公衆電話網であり、パケット網１は、複数のルータ５ｎ（ｎ＝１、２、…）からなり、これらのサーバには、呼制御サーバ装置３（３−１、３−２）、ＩＰ電話クライアント端末６（６−１、６−２）、ＩＰ電話機７（７−１、７−２）、および、パケット網に接続された端末アドレス情報を管理するためのＤＮＳ（Domain Name System）サーバ９が接続されている。また、一般の電話機８を収容した公衆電話網２は、ゲートウエイ（Gate Way:ＧＷ）装置４を介して上記パケット網１に接続されている。
【００１３】
図２は、クライアント端末６の構成を示す。
クライアント端末６は、ＣＰＵ１０と、上記ＣＰＵ１０で実行する通信プログラム等が格納されたメモリ１１と、各種のテーブルデータを記憶するための蓄積装置１２と、パケット網１に接続するための通信網インタフェース１３と、音声入力用の第１入力装置（マイク）１４Ａと、データ入力用の第２の入力装置（キーボード、マウス、ペン等）１４Ｂと、音声出力用の第1の出力装置（スピーカ）１５Ａと、データ出力用の第2の出力装置（ディスプレイ等）１５Ｂと、送信データ処理回路１００Ｔと、受信パケット処理回路１００Ｒと、これらの要素を相互接続する内部バスとからなる。
【００１４】
送信データ処理回路１００Ｔは、第１入力装置１４Ａから入力されたアナログ音声信号をディジタル信号に変換するためのＡ／Ｄ変換器１５と、ディジタル化された音声信号を圧縮、符号化するための符号化回路（Coder）１６と、上記Coder１６から出力された符号化音声データにシーケンス番号等の制御情報を付加して、図２３で後述する所定フォーマットのデータブロックを生成するためのデータパケット化回路１７と、上記音声データパケットおよび後述する呼制御用のコマンドパケットにＴＣＰ／ＵＤＰヘッダとＩＰヘッダを付加し、ＩＰパケットとして通信網インタフェース１３に出力するネットワークパケット化回路１８とからなる。
【００１５】
受信パケット処理回路１００Ｒは、通信網インタフェース１３から受信されたＩＰパケットからヘッダ情報を除去し、データフィールドの内容を出力するネットワークパケット分解回路２２と、上記データフィールドの内容を識別し、コマンドパケットと音声データパケットとに振り分けるデータ／コマンド振分け回路２３と、音声データパケットをバッファリングするためのデータキュー２４と、上記データキュー２４から音声データパケットを読み出し、各音声データパケットの制御情報をチェックしながら符号化音声データを出力する符号化音声データ抽出回路２５と、上記符号化音声データを復号化する復号化回路（Decoder）２６と、復号化されたディジタル音声データをアナログ音声信号に変換するためのＤ／Ａ変換回路２７とからなる。
【００１６】
第２入力装置１４Ｂからの入力データは、メモリ１１に格納されたプログラムの一部を構成するイベント解析ルーチン１９によって解析され、上記入力データが呼設定に関するイベントの場合、コマンドパケット化ルーチン２０によって所定フォーマットのコマンドパケットが生成され、ネットワークパケット化回路１８に供給される。上記コマンドパケットの生成に必要な各種制御情報や呼制御の状態遷移は、発信呼制御処理ルーチン２１によって管理されている。一方、データ／コマンド振り分け回路２３で識別されたコマンドパケットは、メモリ１１に格納されたプログラムの一部を構成するコマンド解析処理２９によって受信コマンドの種別が解析される。受信コマンドがユーザに通知すべきコマンドの場合、受信コマンドに対応した出力メッセージまたは出力信号が出力データ生成ルーチン３０によって生成され、第２出力装置１５Ｂに出力される。音声パケットの受信状態や呼制御状態遷移は、受信呼制御処理ルーチン３１によって管理される。
【００１７】
ここでは、音声データのパケット化とネットワークパケット化、受信パケットの分解、データ／コマンド振り分け、符号化音声データの抽出をハードウエア回路によって行っているが、これらの処理は、メモリ１１に格納されたプログラムルーチンによって、ソフトウェア的に実現してもよい。
【００１８】
蓄積装置１２には、図３に示すアドレス管理テーブル１１０と、図４に示す固定値テーブル１２０が形成されている。
アドレス管理テーブル１１０は、通信端末名１１１とＩＰアドレス１１２との関係を示す複数のエントリを有し、ＤＮＳサーバ９が保持するアドレス管理テーブルに対するキャッシュメモリとなっている。
【００１９】
固定値テーブル１２０は、各ＩＰ電話クライアント端末６に固有の制御情報を記憶するためのものであり、例えば、そのＩＰ電話クライアント端末に与えられた通信端末名１２１およびＩＰアドレス１２２と、該ＩＰ電話クライアント端末からの発呼を受け付ける呼制御サーバ（発側呼制御サーバ）のアドレス１２３と、該ＩＰ電話クライアント端末を収容しているルータ、すなわち、デフォルト（第１ホップ目）のルータ（発側デフォルトルータ）のアドレス１２４と、ＱｏＳ（Quality of Service）情報として、帯域１２５、最大許容遅延時間１２６および許容パケットロス率１２７と、符号化方式特定情報１２８を記憶している。
【００２０】
本発明の音声データ通信方法をＩＰ電話機７に適用する場合は、各ＩＰ電話機７に上記図２に示したＩＰ電話クライアント端末６と同様のパケット処理機能を装備すればよい。ＧＷ装置４は、公衆網２から受信した音声信号と呼制御信号をそれぞれＩＰパケットに変換してルータ５―３に転送し、逆に、ルータ５―３からの受信ＩＰパケットを音声信号または呼制御信号に変換して公衆網２に転送する。従って、公衆網との入出力インタフェースを入力装置１４Ａ、１４Ｂ、出力装置１５Ａ、１５Ｂに対応付ければ明らかなように、ＧＷ装置４に上記図２と同様の機能をもたせることによって、一般電話機８に対しても本発明の音声データ通信方法を適用できる。
【００２１】
呼制御サーバ３は、パケット網１に接続されたＧＷ装置４をＩＰ電話クライアント端末６やＩＰ電話機７と同等に扱う。以下の説明で、呼制御装置３が端末として扱うこれらの装置を総括して、メディア（音声データ）通信端末と言う。
呼制御サーバ装置３は、本発明の音声データ通信方法を実現するために、例えば、図５に示すロケーション管理テーブル２００と、図６に示すコネクション管理テーブル２１０を備えている。
【００２２】
ロケーション管理テーブル２００は、その呼制御サーバが過去に通話中継したメディア通信端末の名称２０１と、該メディア通信端末を管轄する呼制御サーバのアドレス２０２と、該メディア通信端末のデフォルト（第１ホップ目）のルータのアドレス２０３との関係を示す複数のエントリ２００―１〜２００―ｍからなっている。
コネクション管理テーブル２１０は、現在通話中の呼と対応した複数のエントリ２１０―１〜２１０―ｋからなり、各エントリは、呼に割り当てられた論理回線番号２１１と、発側（または送信元）通信端末のアドレス２１２と、発側通信端末が接続された発側（または送信元）デフォルトルータのアドレス２１３と、着側（宛先）通信端末のアドレス２１４と、着側通信端末が接続された着側（または宛先）デフォルトルータのアドレス２１５と、着側通信端末を管轄する着側（または宛先）呼制御サーバのアドレス２１６と、上記呼におけるＱｏＳ情報（帯域幅２１７、最大許容遅延時間２１８、許容パケットロス率２１９）と、上記呼で使用される音声符号化方式を特定するための定義情報２２０とを含む。
【００２３】
図７は、図１の通信ネットワークに適用した本発明による音声データ通信方法の全体的な通信手順を示す。
ここでは、ルータ５―１に収容されたＩＰ電話クライアント端末６―１を発側端末、ルータ５―７に収容されたＩＰ電話機７―２を着側端末とし、サーバ３―１を発側呼制御サーバ、３―２を着側呼制御サーバとし、発側端末６−１からの通話要求によって呼が設定され、通話終了後、着側端末７―２から切断要求によって呼が切断される迄の各装置の動作を説明する。
発側端末６−１の第２入力装置１４Ｂから、着側端末７−２の通信端末名入力を含むユーザ操作によって通話要求イベントが発生した場合、発側端末６−１において通話要求処理４４が実行され、これによって通話要求コマンド７０を含む図２６に示すＩＰパケットが生成され、発側呼制御サーバ３−１に送信される。
【００２４】
上記ＩＰパケットは、図２６に示すように、ＩＰヘッダ７１０とＩＰデータフィールド７２０とからなり、ＩＰヘッダ７１０の送信元アドレス（ＳＡ）７１１には固定値テーブル１２０から求めた発側端末６―１のＩＰアドレス１２２が設定され、宛先アドレス（ＤＡ）７１２にはアドレス管理テーブル１１０から求めた着側端末のＩＰアドレスが設定される。また、ＩＰデータフィールド７２０は、ＴＣＰ／ＵＤＰのヘッダフィールド７２１とデータフィールド７２２とからなり、上記データフィールド７２２に、コマンド種類７３０、コマンドＩＤ７３１、発側端末アドレス７３２、発側端末名７３３、着側端末アドレス７３４、着側端末名７３５、符号化方式特定情報７３６、帯域７３７、最大許容遅延時間７３８、許容パケットロス率７３９からなる通話要求コマンド７０が設定される。
【００２５】
上記通話要求処理４４では、図８に示すように、ユーザ入力イベントから宛先端末７−２の通信端末名を取得し（ステップ４４０）、該通信端末名を持つエントリがアドレス管理テーブル１１０に既に登録済みか否かをチェックする（４４１）。もし、目的エントリがアドレス管理テーブルに未登録の場合は、ＤＮＳサーバに上記宛先端末のＩＰアドレスを問合わせ（４４２）、上記宛先端末の名称１１１とＩＰアドレス１１２との関係を示す新たなエントリをアドレス管理テーブル１１０に登録（４４３）した後、通話要求コマンド７０を生成し（４４４）、上記通話要求コマンド７０を含むＩＰパケットを発側呼制御サーバに送信する（４４５）。この時、通話要求コマンド７０に含まれる発側端末アドレス７３２、発側端末名７３３、符号化方式特定情報７３６およびＱｏＳ情報７３７〜７３９は固定値テーブル１２０から得られ、着側端末アドレス７３４と着側端末名７３５は、上述したアドレス管理テーブル１１０の目的エントリの内容と対応している。また、ＩＰパケットヘッダの送信元アドレス７１１と宛先アドレス７１２には、固定値テーブル１２０から得た発側端末６−１のＩＰアドレス１２２と発側呼制御サーバアドレス１２３とがそれぞれ設定される。
【００２６】
上記通話要求コマンド７０の受信に応答して、発側呼制御サーバ装置３−１は、呼接続処理４５を行い、図２７に示す呼接続コマンド７１を含むＩＰパケットを生成して、着側呼制御サーバ装置３−２に送信する。上記呼接続コマンド７１は、受信した通話要求コマンド７０に含まれる項目７３０〜７３９に、更に、発側デフォルトルータアドレス７４０を追加した内容となっている。
上記呼接続処理４５では、図９に示すように、受信した通話要求コマンド７０から抽出した発側端末名７３３と着側端末名７３５に基づいて、ロケーション管理テーブル２００を参照し、上記発側端末名７３３と対応するデフォルトルータアドレス（発側ルータアドレス）と、上記着側端末名７３５と対応する呼制御サーバアドレス（着側呼制御サーバアドレス）を求め（４５０）、これらのアドレスと、上記通話要求コマンド７０から抽出された発側端末アドレス７３２、着側端末アドレス７３４、符号化方式定義情報７３６、ＱｏＳ情報７３７−７３９を含む新たなエントリをコネクション管理テーブル２１０に追加する（４５１）。次に、上記通話要求コマンド７０の内容と上記発側デフォルトルータアドレスとに基づいて、図２７に示すフォーマットの呼接続コマンド７１を含むＩＰパケットを生成し（４５２）、これを着側呼制御サーバ３−２に送信する（４５３）。
【００２７】
着側呼制御サーバ装置３−２は、上記呼接続コマンド７１の受信に応答して呼接続受信処理４６を行う。呼接続受信処理４６では、図１０に示すように、受信した呼接続コマンド７１から抽出した発側端末名７３５に基づいて、ロケーション管理テーブル２００を参照し、上記着側端末名と対応する着側デフォルトルータアドレスを検索し（４６０）、上記着側デフォルトルータアドレスと、上記呼接続コマンド７１から抽出したその他の項目とに基づいて新たなテーブルエントリを生成し、これをコネクション管理テーブル２１０に登録する（４６１）。
【００２８】
この場合、着側呼制御サーバ３−２のコネクション管理テーブル２１０では、管轄下にある端末７−２を発側、通信相手となる端末６−１を着側として上記テーブルエントリが生成され、上記呼接続コマンド７１のＩＰヘッダに送信元アドレスとして設定された発側呼制御サーバ３−１のアドレスが着側呼制御サーバアドレス２１６として記憶される。着側呼制御サーバ装置３−２は、次に、呼設定ＡＣＫコマンド７２を生成し（４６２）、この呼設定ＡＣＫコマンド７２を含むＩＰパケットを発側の呼制御サーバ３−１に送信する（４６３）。上記呼設定ＡＣＫコマンド７２には、発側、着側の端末アドレスの他に、ステップ４６０で検索した着側デフォルトルータアドレスが含まれている。
【００２９】
発側呼制御サーバ３−１は、上記呼接続ＡＣＫコマンド７２を受信すると、ＱｏＳ設定処理４７を実行する。上記ＱｏＳ設定処理４７では、図１１に示すように、受信した呼接続ＡＣＫコマンド７２から着側デフォルトルータアドレスを抽出し、これを上記呼接続ＡＣＫコマンド７２の発側、着側端末アドレスで特定されるコネクション管理テーブル２１０の該当エントリのフィールド２１５に追加する（ステップ４７９）。次に、上記テーブルエントリの内容に基づいて、図２８に示すＱｏＳ設定コマンド７３を生成し（ステップ４７１）、上記ＱｏＳ設定コマンド７３を含むＩＰパケットをカプセル化して、発側デフォルトルータ５−１に送信する（ステップ４７２）。尚、この実施例では、着側デフォルトルータアドレスを呼接続ＡＣＫコマンド７２の受信時にコネクション管理テーブル２１０に設定しているが、この着側デフォルトルータアドレスの設定は、前述の呼接続処理４５で行ってもよい。
【００３０】
上記ＱｏＳ設定コマンド７３は、図２８に示すように、コマンド種別７３０、コマンドＩＤ７３１、発側端末アドレス７３２、着側端末アドレス７３４、符号化方式情報７３６、ＱｏＳ情報７３７〜７３９の他に、発側デフォルトルータアドレス７４０、着側呼制御サーバアドレス７４１、着側デフォルトルータアドレス７４２と、リターン値設定フィールド７４３を含み、ＩＰヘッダの送信元アドレス（ＳＡ）と宛先アドレス（ＤＡ）には、発側呼制御サーバ３−１と着側呼制御サーバ３−２のアドレスがそれぞれ設定される。また、上記ＩＰヘッダの前に付されるカプセル化ヘッダには、送信元アドレス（ＳＡ）として発側呼制御サーバ３−１のアドレス、宛先アドレス（ＤＡ）として発側デフォルトルータ５−１のアドレスがそれぞれ設定され、プロトコルタイプ（プロトコル番号）として、このＩＰパケットがＱｏＳ設定コマンドであることを示す特定の番号（以下、“ｘｘ”で示す）を含む。
【００３１】
発側ルータ５−１は、上記ＱｏＳ設定コマンド７３を含むカプセル化ＩＰパケットを受信すると、プロトコル番号が“ｘｘ”であることから、受信パケットをＱｏＳ設定コマンド７３と解釈し、ＱｏＳ設定コマンド７３の発側デフォルトルータアドレス７４０と着側デフォルトルータアドレス７４２をチェックする。この場合、発側デフォルトルータアドレス７４０が自分のアドレスに一致しているため、発側ルータ５−１は、カプセル化ＩＰパケットの送信元アドレス（ＳＡ）を自分のアドレス、宛先アドレス（ＤＡ）を着側デフォルトルータアドレス７４２にそれぞれ書き換えて、ネットワークに送出する。
着側ルータ５−７が、上記ＱｏＳ設定コマンド７３を含むカプセル化ＩＰパケットを受信すると、プロトコル番号が“ｘｘ”であることから、受信パケットをＱｏＳ設定コマンド７３と解釈し、発側ルータ５−１と同様に、ＱｏＳ設定コマンド７３の発側デフォルトルータアドレス７４０と着側デフォルトルータアドレス７４２をチェックする。この場合、着側デフォルトルータアドレス７４２が自分のアドレスに一致しているため、着側ルータ５−１は、カプセル化を解除し、発側呼制御サーバ３−１が発行した元のＩＰパケットに戻して、ネットワークに送出する。
【００３２】
上記中継動作によって、 ＱｏＳ設定コマンド７３は着側呼制御サーバ３−２に転送される。上述したＱｏＳ設定コマンド７３の中継過程において、各ルータは、受信したＱｏＳ設定コマンド７３で指定されたＱｏＳ情報７３７〜７３９を満足するリソースが確保できるか否かを判定し、それぞれの判定結果に従って、フィールド７４３にＱｏＳ設定可否を示すリターン値を設定する。何れかの中継ルータがＱｏＳ設定不可を示した場合は、エラーリターンとなり、呼設定は不成功に終わる。但し、上記ＱｏＳ設定が可能なルータを検索しながら経路を設定する場合はこの限りではない。
着側呼制御サーバ３−２は、ルータ５−７から上記ＱｏＳ設定コマンドを含むＩＰパケットを受信すると、リターン値設定フィールド７４３をチェックし、もし、リターン値がＱｏＳ設定可を示す場合は、通話要求中継処理４８を実行し、リターン値がＱｏＳ設定不可を示していた場合、すなわちエラーリターンとなっていた場合は、後述する呼接続拒絶処理５１を実行する。
【００３３】
上記通話要求中継処理４８では、図１２に示すように、ＱｏＳ設定コマンド７３から発側端末アドレス７３２と着側端末アドレス７３４を抽出し、コネクション管理テーブル２１０の上記発側端末アドレスと対応するテーブルエントリから、符号化方式の定義情報を取得する（ステップ４８０）。次に、上記符号化方式定義情報と着側端末アドレスを含む通話要求コマンド７４を生成し（４８１）、該通話要求コマンド７４を含むＩＰパケットを着側端末７−２に送信する（ステップ４８２）。
着側端末７−２は、呼制御サーバ３−２から上記通話要求コマンド７４を受信すると、端末ユーザに通話の着信を通知し、ユーザからの応答イベントを処理するための通話要求受信処理４９を実行する。もし、ユーザから通話拒絶イベント７６を受けた場合は、呼制御サーバ３−２に通話拒絶コマンド７７を応答するための通話拒絶処理５０を実行し、通話許諾イベント８２を受けた場合は、通話許諾コマンド８３を応答するための通話許諾処理５４を実行する。
【００３４】
上記通話要求受信処理４９では、図１３に示すように、通話要求コマンド７４から発側端末アドレスと、符号化方式の定義情報を抽出し（ステップ４９０）、これらの情報を図示しない通話管理テーブルに登録する（４９１）。次に、図２に示した符号化回路（Coder）１６と復号化回路（Decoder）２６に、上記定義情報に従った符号化方式のパラメータを設定し（４９２）、着信通知メッセージを第２出力装置１５Ｂに出力する（４９３）。上記着信通知メッセージに対するユーザからの応答待ち時間を制限するためのタイマを起動し（４９４）、ユーザから応答を判定する。ユーザから通話受諾応答があった場合（４９５）、発側、着側の端末アドレスを含む通話受諾コマンド８２を生成し、該通話受諾コマンドを含むＩＰパケットを着側呼制御サーバ装置３−２に送信する（通話受諾処理５４）。この後、図７に示す発側端末の音声データ送受信処理５７と同様の音声データ送受信処理４９８を開始する。ユーザから通話拒絶応答があった場合（４９６）、または、タイマがタイムアウトとなった場合（４９７）は、通話拒絶処理５０を実行する。
【００３５】
上記通話拒絶処理５０では、図１４に示すように、発側、着側の端末アドレスを含む通話拒絶コマンド７７を生成し（ステップ５００）、上記通話拒絶コマンド７７を含むＩＰパケットを呼制御サーバ装置３−２に送信（５０１）した後、符号化回路１６と復号化回路２６を初期化する（５０２）。
エラーリターンを含むＱｏＳ設定コマンド７３（ＱｏＳ設定エラー通知７８）を受信した場合、あるいは着側端末７−２から通話拒絶コマンド７７を受信した場合は、着側呼制御サーバ３−２は、呼接続拒絶処理５１を実行する。
【００３６】
上記呼接続拒絶処理５１では、図１５に示すように、受信した通話接続拒絶コマンド７７、またはＱｏＳ設定エラー通知７８に含まれる着側、発側の端末アドレスに基づいて、コネクション管理テーブル２１０を参照し、着側呼制御サーバアドレス２１６として記憶されて発側の呼制御サーバ３−１のアドレスを取得する（ステップ５１０）。次に、呼接続拒絶原因と、発側端末６−１および着側端末７−２のアドレスとを含む呼接続拒絶コマンド８０を生成し（５１１）、該コマンドを上記ステップ５１０で取得した発側呼制御サーバ３−１宛に送信する（５１２）。今回の呼接続拒絶がＱｏＳ設定エラー通知７８に起因していた場合（５１３）は、コネクション管理テーブル２１０から該当エントリを削除して（５１７）、このルーチンを終了する。
【００３７】
呼接続拒絶が端末ユーザからの通話拒絶コマンド７６に起因していた場合は、コネクション管理テーブル２１０から発側、着側のデフォルトルータアドレス２１３、２１５を取得し（５１４）、これらのアドレス情報を含むＱｏＳリリースコマンド７９を生成し（５１５）、これをＩＰパケットとして着側ルータ５−７に送信（５１６）した後、コネクション管理テーブル２１０から該当エントリを削除する（５１７）。上記ＱｏＳリリースコマンド７９は、ＱｏＳ設定コマンド４７の経路を逆方向に辿ってデフォルトルータ５−１まで中継される。経路上の各ルータは、上記ＱｏＳリリースコマンド７９の受信に応答して、ＱｏＳ設定コマンド４７受信時に確保していた通信リソースを順次に解放していく。
【００３８】
呼接続拒絶コマンド８０を受信した発側呼制御サーバ装置３−１は、通話拒絶中継処理５２を実行する。上記通話拒絶中継処理５２では、図１６に示すように、通話拒絶原因を含む通話拒絶コマンド８１を生成し（ステップ５２０）、上記通話拒絶コマンド８１を含むＩＰパケットを発側端末６−１へ送信（５２１）した後、上記呼接続拒絶コマンド８０の発側、着側の端末アドレスに基づいて、コネクション管理テーブル２１０から該当エントリを削除する（５２２）。
【００３９】
通話拒絶コマンド８１を受信した発側端末６−１は、通話拒絶受信処理５３を実行する。上記通話拒絶受信処理５３では、図１７に示すように、通話拒絶コマンド８１が示す通話拒絶原因に応じて、ユーザに通知すべきメッセージを生成し、これを第２出力装置１５Ｂに出力する（ステップ５３０）。この後、符号化回路１６、復号化回路２６を初期化し（５３１）、発側呼制御サーバ装置３−１とのコネクションを切断する（５３２）。
【００４０】
着側の呼制御サーバ装置３−２は、着側端末７−２から通話受諾コマンド８３を受信すると、呼確立処理５５を実行する。上記呼確立処理５５では、図１８に示すように、受信した通話受諾コマンド８３に含まれる発側、着側の端末アドレスに基づいて、コネクション管理テーブル２１０から発側呼制御サーバアドレスを取得する（ステップ５５０）。次に、発側、着側端末のアドレスを含み、呼が確立されたことを示す呼確立コマンド８４を生成し（５５１）、該呼確立コマンドを含むＩＰパケットを発側呼制御サーバ３−１に対して送信する（５５２）。
【００４１】
上記呼確立コマンド８４を受信した発側呼制御サーバ３−１は、通話要求受諾中継処理５６を実行する。上記通話受諾中継処理５６では、図１９に示すように、通話受諾コマンド８５を生成し（ステップ５６０）、受信した前記呼確立コマンドが示す発側端末アドレスに基づいて、上記通話受諾コマンド８５を発側端末６−１に送信する（５６１）。
【００４２】
発側端末６−１は、上記通話受諾コマンド８５を受信すると、音声データ送受信処理５７を開始する。これによって発側端末６−１と着側端末７−２との間で通話音声データの送受信が可能となる。
上記音声データ送受信処理５７が開始されると、符号化回路１６で圧縮された符号化音声データがデータパケット化回路１７によって次々と音声パケットに変換される。各音声パケットは、図２９に示すように、コマンド種別７３０と、符号化方式定義情報７５０と、シーケンス番号７５１と、タイムスタンプ（時刻情報）７５２と、符号化音声データ７５３とからなる。各音声パケットは、ネットワークパケット化回路１８によってＩＰヘッダが付加された後、通信網インタフェース１３を介してパケット網１に送出される。一方、パケット網１から受信されたＩＰパケットは、ネットワークパケット分解回路２２とデータ／コマンド振り分け回路２３で処理され、各受信パケットに含まれる符号化音声データが符号化音声データ抽出回路２５で抽出され、復号化回路２６に供給される。
【００４３】
発側端末６−１と着側端末７−２との間での通話が終了し、例えば、着側端末７−２のユーザが通話切断８６の操作を行った場合、着側端末７−２では、通話切断処理５８が実行される。上記通話切断処理５８では、図２０に示すように、通話切断コマンド８７を生成し（ステップ５８０）、該通話切断コマンド８７を含むＩＰパケットを着側呼制御サーバ３−２に送信（５８１）した後、符号化回路１６を含む送信データ処理回路１００Ｔと、復号化回路２６を含む受信パケット処理回路１００Ｒを初期化する（５８２）。
【００４４】
上記通話切断コマンド８７を受信した着側呼制御サーバ３−２は、呼切断処理５９を実行する。上記呼切断処理５９では、図２１に示すように、着側端末７−２と発側端末６−１のアドレスを含む呼切断コマンド８８を生成し（ステップ５９０）、コネクション管理テーブル２１０から求めた呼制御サーバアドレス２１６に従って、上記呼切断コマンドを含むＩＰパケットを発側呼制御サーバアドレス３−１に送信する（５９１）。次に、ＱｏＳリソースを開放するためのＱｏＳリリースコマンド８９を生成し（５９２）、該コマンドを含むＩＰパケットを着側デフォルトルータ５−７経由で発側デフォルトルータ５−１に送信（５９３）した後、コネクション管理テーブル２１０から該当コネクションのエントリを削除する（５９４）。
【００４５】
発側呼制御サーバ装置３−１は、上記呼切断コマンド８８を受信すると、通話切断中継処理６０を実行する。上記通話切断中継処理６０では、図２２に示すように、通話切断コマンド９０を生成し（ステップ６００）、上記呼切断コマンド８８が示す発側端末アドレスに従って、上記通話切断コマンド９０を含むＩＰパケットを発側端末６−１に送信（６０１）した後、コネクション管理テーブル２１０から該当エントリを削除する（６０２）。
【００４６】
発側端末６−１は、上記通話切断コマンド９０を受信すると、通話切断受信処理６１を実行する。上記通話切断受信処理６１では、図２３に示すように、ユーザにコネクションの切断を通知するための切断メッセージを生成し、第２出力装置１５Ｂに出力する（ステップ６１０）。この後、送信データ処理回路１００Ｔと受信パケット処理回路１００Ｒを初期化し（６１１）、呼制御サーバ装置３−２とのコネクションを切断する（６１２）。
【００４７】
図２４は、発側、着側の各端末装置６−１、７−２で実行される通話制御プログラムのフローチャートを示す。
通話制御プログラムが起動されると（ステップ２００）、第２入力装置１４Ｂからのイベント入力の有無を検知する（２０１）。もし、イベント入力があった場合、入力イベントの種類を判定し、入力イベントに応じた処理を実行する。入力イベントが通話要求であれば（２０２）通話要求処理４４、切断要求であれば（２０３）通話切断処理５８、通話拒絶であれば（２０４）通話拒絶処理５０、通話許諾であれば（２０５）通話受諾処理５４をそれぞれ実行する。入力イベントが上記の何れにも該当しなかった場合、あるいは、上記所定の処理を終えた場合、通話制御プログラムの終了指示かあったか否かを判定し（２２０）、終了指示があった場合は、本ルーチンを終了し、そうでなければ、ステップ２０１に戻る。
【００４８】
ステップ２０１で、ユーザからのイベント入力がなかった場合、パケット網１からのパケットの着信の有無を判定する（２１０）。パケットが着信していなければ、ステップ２２０に進む。パケットが着信していた場合、受信パケットが呼制御用のコマンドか否かを判定し（２１１）、呼制御コマンドでなければ、音声データの受信処理５７Ｒを行う。受信パケットが呼制御コマンドの場合、受信コマンドの種類に応じた処理を事項する。受信コマンドが通話要求コマンド７０であれば（２１２）通話要求受信処理４９、通話切断コマンド８７であれば（２１３）通話切断受信処理６１を実行する。また、受信コマンドが通話受諾コマンド８３であれば（２１４）、音声データ送受信処理５７を開始し、通話拒絶コマンド７７であれば（２１５）、通話拒絶受信処理５３を実行する。受信コマンドがこれらの何れにも該当しなかった場合、あるいは、上記所定の処理を終了した場合、ステップ２２０に進む。
【００４９】
図２５は、呼制御サーバ装置３−１、３−２で実行される呼制御プログラムのフローチャートを示す。このプログラムが起動されると（ステップ３００）、パケット網１からのパケットの着信の有無を検出し（３０１）し、パケットが着信していた場合、上記受信パケットに含まれる受信コマンドが、クライアント端末から発行された呼接続制御コマンドか否か判定する（３０２）。
受信コマンドがクライアント端末から発行されたコマンドの場合、受信コマンドの種類に応じた処理を実行する。受信コマンドが通話要求コマンド７０であれば（３０３）呼接続処理４５、通話切断コマンド８７であれば（３０４）呼切断処理５９、通話受諾コマンド８３であれば（３０５）呼確立処理５５、通話拒絶コマンド７７であれば（３０６）呼接続拒絶処理５１をそれぞれ実行する。受信コマンドが上記何れにも該当しなかった場合、または、上記所定の処理を終えた場合、呼制御プログラムの終了指示の有無を判定し（３３０）、終了指示があった場合は、本ルーチンを終了し、そうでない場合は、ステップ３０１に戻る。
【００５０】
ステップ３０２で、受信コマンドがクライアント端末からのものではなかった場合、該コマンドが他の呼制御サーバ装置から発行された呼制御コマンドか否かを判定する（３１０）。もし、そうであれば、受信コマンドの種類に応じた処理を実行する。受信コマンドが呼接続コマンド７１であれば（３１１）呼接続受信処理４６、呼接続ＡＣＫコマンド７２であれば（３１２）ＱｏＳ設定処理４７、呼接続拒絶コマンド８０であれば（３１３）通話拒絶中継処理５２、呼確立コマンド８４であれば（３１４）通話受諾中継処理５６、呼切断コマンド８７であれば（３１５）通話絶断中継処理６０をそれぞれ実行する。
【００５１】
ステップ３１０において、受信コマンドが他の呼制御サーバ装置から発行された呼制御コマンドではなかった場合、該コマンドがＱｏＳ設定コマンドか否かを判定し（ステップ３２０）、ＱｏＳコマンドでなければステップ３０１に戻る。受信コマンドがＱｏＳコマンドの場合、該ＱｏＳコマンドのリターン値がＱｏＳ設定可能な状態を示しているか否かを判定し（３２１）、もし、ＱｏＳ設定が可能であれば、通話要求中継処理５８を実行し、ＱｏＳ設定が不能であれば、呼接続拒絶処理５１を実行して、ステップ３３０に進む。
【００５２】
【発明の効果】
以上の実施形態から明らかなように、本発明によれば、音声データ通信端末のコネクション設定を呼制御サーバで行い、且つ、各音声データ通信端末を収容しているデフォルトルータを経由して通話に必要なＱｏＳ設定を行うようにしているため、実際にメディアデータが通るパス上でのＱｏＳ制御が可能となる。また、本発明によれば、音声データ通信端末のコネクション設定を呼制御サーバで代行することによって、各音声データ通信端末の処理負荷を軽減できる。
【図面の簡単な説明】
【図１】本発明の音声データ通信方法が適用される通信ネットワークの構成の１例を示す図。
【図２】図１におけるクライアント端末６の構成図。
【図３】通信端末６が備えるアドレス管理テーブル１１０の構成図。
【図４】通信端末６が備える固定値テーブル１２０の構成図。
【図５】図１における呼制御サーバ３が備える通信端末ロケーション管理テーブル２００の構成図。
【図６】呼制御サーバ装置３が備えるコネクション管理テーブル２１０の構成図。
【図７】図１の通信ネットワークにおける本発明による音声データ通信方法の全体的な通信手順を示す図。
【図８】図７における通話要求処理４４の詳細を示すフローチャート。
【図９】図７における呼接続処理４５の詳細を示すフローチャート。
【図１０】図７における呼接続受信処理４６の詳細を示すフローチャート。
【図１１】図７におけるＱｏＳ設定処理４７の詳細を示すフローチャート。
【図１２】図７における通話要求中継処理４８の詳細を示すフローチャート。
【図１３】図７における通話要求受信処理４９の詳細を示すフローチャート。
【図１４】図７における通話拒絶処理５０の詳細を示すフローチャート。
【図１５】図７における呼接続拒絶処理５１の詳細を示すフローチャート。
【図１６】図７における通話拒絶中継処理５２の詳細を示すフローチャート。
【図１７】図７における通話拒絶受信処理５３の詳細を示すフローチャート。
【図１８】図７における呼確立処理５５の詳細を示すフローチャート。
【図１９】図７における通話受諾中継処理５６の詳細を示すフローチャート。
【図２０】図７における通話切断処理５８の詳細を示すフローチャート。
【図２１】図７における呼切断処理５９の詳細を示すフローチャート。
【図２２】図７における通話切断中継処理６０の詳細を示すフローチャート。
【図２３】図７における通話切断受信処理６１の詳細を示すフローチャート。
【図２４】通信端末６で実行される通話制御プログラムのフローチャート。
【図２５】呼制御サーバ３で実行される呼制御プログラムのフローチャート。
【図２６】ＩＰパケットと通話要求コマンド７０のフォーマットの１例を示す図。
【図２７】呼接続コマンド７１のフォーマットの１例を示す図。
【図２８】ＱｏＳ設定コマンド７３のフォーマットの１例を示す図。
【図２９】音声パケットのフォーマットの１例を示す図。
【符号の説明】
１：パケット網、２：公衆電話網、３：呼制御サーバ、４：音声データ中継装置（ゲートウェイ）、５：ルータ、６、７：音声データ通信端末
Claims (5)
- 複数のルータを有するＩＰパケット網に接続された呼制御サーバであって、
発側の音声データ通信端末から送信されたＱｏＳ情報を含む通話要求コマンドの受信に応答して、通話相手となる着側端末を管轄する着側呼制御サーバに対して呼接続コマンドを含むＩＰパケットを送信する第１手段と、
上記着側呼制御サーバから上記着側端末を収容している着側ルータのデフォルトルータアドレスを含む呼接続ＡＣＫコマンドを含むＩＰパケットを受信したとき、上記発側の音声データ端末を収容している発側ルータのデフォルトルータアドレスと、上記着側ルータのデフォルトルータアドレスと、上記通話要求コマンドで指定されたＱｏＳ情報とを示すＱｏＳ設定コマンドを含み、上記着側呼制御サーバを宛先とするＩＰパケットを生成し、該ＩＰパケットを上記発側ルータのデフォルトルータアドレスを宛先アドレスとするカプセル化ヘッダでカプセル化して、上記発側ルータに送信する第２手段とを備え、
上記発側ルータが、上記カプセル化ヘッダの宛先アドレスを上記着側ルータのデフォルトルータアドレスに書き換えて、上記ＱｏＳ設定コマンドを含むＩＰパケットを上記ＩＰパケット網に送信するようにしたことを特徴とする呼制御サーバ。 - 請求項１に記載の呼制御サーバにおいて、
各通信端末と、該通信端末を管轄する呼制御サーバのアドレスと、デフォルトルータアドレスとの関係を記憶するロケーション管理テーブルと、
コネクション毎に、少なくとも発側、着側の端末アドレスと、発側のデフォルトルータアドレスと、ＱｏＳ情報とを記憶するためのコネクション管理テーブルとを有し、
前記第１手段が、前記通話要求コマンドの受信に応答して、上記コネクション管理テーブルに新たなエントリを追加し、上記ロケーション管理テーブルから、前記通話要求コマンドで指定された着側端末と対応する着側呼制御サーバのアドレスを求め、該アドレスを宛先として前記呼接続コマンドを送信し、
前記第２手段が、前記呼接続ＡＣＫコマンドを受信したとき、該呼接続ＡＣＫコマンドから抽出した前記着側ルータのデフォルトルータアドレスと、上記コネクション管理テーブルが示す前記発側ルータのデフォルトルータアドレスおよび前記ＱｏＳ情報を含むＱｏＳ設定コマンドを生成することを特徴とする呼制御サーバ。 - 複数のルータと複数の呼制御サーバとを有するＩＰパケット網における音声データの通信方法において、
音声データの送信に先立って、上記ＩＰパケット網に接続された発側の通信端末から該端末を管轄する発側の呼制御サーバに、着側端末とＱｏＳ情報を特定した通話要求コマンドを送信するステップと、
上記通話要求コマンドの受信に応答して、上記発側の呼制御サーバから上記着側端末を管轄する着側の呼制御サーバに、上記発側の通信端末を収容している発側ルータのデフォルトルータアドレスと、着側端末と、ＱｏＳ情報を特定した呼接続コマンドを送信するステップと、
上記着側呼制御サーバから上記発側呼制御サーバに、上記着側端末を収容している着側ルータのデフォルトルータアドレスを含む呼接続ＡＣＫコマンドを送信するステップと、
上記呼接続ＡＣＫコマンドの受信に応答して、上記発側呼制御サーバが、上記発側の音声データ端末を収容している発側ルータのデフォルトルータアドレスと、上記着側ルータのデフォルトルータアドレスと、上記通話要求コマンドで指定されたＱｏＳ情報とを示すＱｏＳ設定コマンドを含み、上記着側呼制御サーバを宛先とするＩＰパケットを生成し、上記発側端末を収容している発側ルータに対して、上記ＩＰパケットを上記発側ルータのデフォルトルータアドレスを宛先アドレスとするカプセル化ヘッダでカプセル化して送信するステップと、
上記発側ルータから上記デフォルトルータアドレスが示す着側ルータに至る経路上の各ルータで指定ＱｏＳの設定可否を示すリターン情報を付加しながら、上記ＱｏＳ設定コマンドを含むＩＰパケットを上記着側呼制御サーバに転送するステップと、
上記着側呼制御サーバが、上記ＱｏＳ設定コマンドのリターン情報から上記発側ルータと着側ルータ間に所望のＱｏＳが確保されたことを確認して、上記着側端末に通話要求コマンドを送信するステップを有することを特徴とする音声データの通信方法。 - 前記ＱｏＳ設定コマンドのリターン情報から前記発側ルータと着側ルータ間に所望のＱｏＳを確保できなかったことが判明した時、前記着側呼制御サーバから前記発側呼制御サーバに、呼接続を拒絶するコマンドを送信することを特徴とする請求項３に記載の音声データの通信方法。
- 前記ＱｏＳ設定コマンドのリターン情報から前記発側ルータと着側ルータ間に所望のＱｏＳを確保できなかったことが判明した時、前記着側呼制御サーバから前記着側ルータを経由して前記発側ルータに、前記ＱｏＳ設定を解除するためのコマンドを送信することを特徴とする請求項３または請求項４に記載の音声データの通信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP26137299A JP4275265B2 (ja) | 1999-09-16 | 1999-09-16 | 呼制御サーバおよび音声データ通信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP26137299A JP4275265B2 (ja) | 1999-09-16 | 1999-09-16 | 呼制御サーバおよび音声データ通信方法 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006237804A Division JP2006333524A (ja) | 2006-09-01 | 2006-09-01 | 呼制御サーバおよび音声データ通信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001086161A JP2001086161A (ja) | 2001-03-30 |
| JP4275265B2 true JP4275265B2 (ja) | 2009-06-10 |
Family
ID=17360936
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP26137299A Expired - Lifetime JP4275265B2 (ja) | 1999-09-16 | 1999-09-16 | 呼制御サーバおよび音声データ通信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4275265B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4849365B2 (ja) * | 2001-04-17 | 2012-01-11 | 尹 在一 | ＶｏＩＰ電話交換制御ネットワークシステム |
| US7142532B2 (en) * | 2001-07-23 | 2006-11-28 | Acme Packet, Inc. | System and method for improving communication between a switched network and a packet network |
| US7362707B2 (en) | 2001-07-23 | 2008-04-22 | Acme Packet, Inc. | System and method for determining flow quality statistics for real-time transport protocol data flows |
| DE10230248A1 (de) * | 2001-11-16 | 2003-06-12 | Nec Europe Ltd | Verfahren zum Übertragen von zeitsynchronen Daten |
| JP3855909B2 (ja) | 2002-10-23 | 2006-12-13 | 株式会社日立製作所 | ポリシ設定可能なピアツーピア通信システム |
-
1999
- 1999-09-16 JP JP26137299A patent/JP4275265B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001086161A (ja) | 2001-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100551859B1 (ko) | 패킷 처리 장치 | |
| US8605620B2 (en) | System for transmitting high quality speech signals on a voice over internet protocol network | |
| CN103430524B (zh) | 一种用于使得使用sip的企业网络能够存活的备用sip服务器 | |
| US9350784B2 (en) | Method and communication system for selecting a transmission mode for transmitting payload data | |
| EP2074790B1 (en) | Media terminal adapter with session initiation protocol (sip) proxy | |
| EP1724983A1 (en) | Method of providing a real-time communication connection | |
| US7230945B2 (en) | Method for sending dual-tone multi-frequency signal using voice over internet protocol | |
| US20070064677A1 (en) | Packet media gateway with a secondary PSTN connection and method for time slot switching | |
| US20020085569A1 (en) | Communication control apparatus and method, and communication system using the communication control apparatus | |
| US20060072469A1 (en) | Communication terminal, communication system, and communication method | |
| JP4275265B2 (ja) | 呼制御サーバおよび音声データ通信方法 | |
| JP4161185B2 (ja) | 時刻同期データの伝送方法 | |
| JP4449137B2 (ja) | 音声中継サーバ | |
| KR20000072520A (ko) | 큐오에스 메커니즘을 이용한 음성 데이터 우선 전송 방법 | |
| JP3663893B2 (ja) | データ中継システム | |
| US6975636B2 (en) | Voice over internet protocol gateway system and method therefor | |
| JP2006100905A (ja) | Ｉｐ電話交換方法及び装置 | |
| US20050135346A1 (en) | Transmitting apparatus | |
| JP2006333524A (ja) | 呼制御サーバおよび音声データ通信方法 | |
| JP4080937B2 (ja) | ネットワーク間のパケット中継方法及びシステム | |
| JP4623325B2 (ja) | 時刻同期データの伝送方法 | |
| JP4212380B2 (ja) | データパケット送信装置 | |
| JPWO2004049657A1 (ja) | 伝送装置 | |
| US20070223447A1 (en) | Gateway device and control method thereof | |
| US8588212B2 (en) | IP telephone system, network device, communication method in disaster situations used therefor and IP telephone terminal |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060901 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20060901 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080522 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080527 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080728 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090210 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090304 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120313 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120313 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130313 Year of fee payment: 4 |