JP3883452B2 - 通信システム - Google Patents
通信システム Download PDFInfo
- Publication number
- JP3883452B2 JP3883452B2 JP2002057169A JP2002057169A JP3883452B2 JP 3883452 B2 JP3883452 B2 JP 3883452B2 JP 2002057169 A JP2002057169 A JP 2002057169A JP 2002057169 A JP2002057169 A JP 2002057169A JP 3883452 B2 JP3883452 B2 JP 3883452B2
- Authority
- JP
- Japan
- Prior art keywords
- server device
- address information
- client
- backup
- communication
- 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 - Fee Related
Links
- 238000004891 communication Methods 0.000 title claims description 145
- 230000005540 biological transmission Effects 0.000 claims description 31
- 238000000034 method Methods 0.000 description 41
- 238000010586 diagram Methods 0.000 description 30
- 238000012545 processing Methods 0.000 description 24
- 230000011664 signaling Effects 0.000 description 7
- 238000001514 detection method Methods 0.000 description 6
- 230000006866 deterioration Effects 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1106—Call signalling protocols; H.323 and related
Description
【０００１】
【発明の属する技術分野】
本発明は通信システムに関し、特にＶｏＩＰ（voice over Internet Protocol）の通信を行う通信システムに関する。
【０００２】
【従来の技術】
近年、インターネットの台頭により、急速にネットワークやアプリケーションのＩＰ化が進展し、データのみならず、音声についてもＩＰ化して、ＩＰネットワークに統合しようという動きが強まっている。ＩＰネットワーク上に音声（voice）を通すための技術は、ＶｏＩＰと呼ばれる。
【０００３】
ＶｏＩＰシステムを導入する際には、従来の電話網相当の品質や信頼性（可用性）などが要求される。このようなニーズを解決するために、ＶｏＩＰシステムを実現するための基本部分や付加サービスなどに関して、ＩＴＵ−Ｔ（International Telecommunication Union−Telecommunication Standardization Sector）のＨ．３２３やＩＥＴＦ（Internet Engineering Task Force）のＳＩＰ（Session Initiation Protocol）において、標準化へ向けての検討が行われている。
【０００４】
図１６はＶｏＩＰシステムの構成を示す図である。図は、Ｈ．３２３システムで、バックアップ用ＶｏＩＰサーバが存在する場合の構成を示している。ＶｏＩＰシステム１００は、ＩＰネットワーク１００ａ上で（社内であればＬＡＮ）、サーバ機能を有するprimary GK（Gatekeeper）１０１及びalternate GK１０２と、クライアント機能を有するＥＰ（EndPoint）１０３−１〜１０３−ｎとから構成される。なお、primary GK１０１は、現行系のＶｏＩＰサーバであり、alternate GK１０２は、バックアップ用のＶｏＩＰサーバである。
【０００５】
ＶｏＩＰシステム１００で、例えば、ＥＰ１０３−１を持つユーザＡが、ＥＰ１０３−２を持つユーザＢに電話をする場合、まずＥＰ１０３−１は、ＥＰ１０３−２の電話番号をprimary GK１０１へ送信する。
【０００６】
すると、ＥＰ１０３−１〜１０３−ｎの電話番号を一元管理しているprimary GK１０１では、アドレス解決処理を行って、受信した電話番号に対応するＥＰ１０３−２のＩＰアドレスを求め、このＩＰアドレスをＥＰ１０３−１へ送信する。
【０００７】
これにより、ＥＰ１０３−１は、相手先をＥＰ１０３−２と認識し、ＥＰ１０３−１、１０３−２間での音声通信が実行される（ＥＰ間の音声通信実行時には、ＶｏＩＰサーバは介さない）。また、primary GK１０１に障害が発生すると、上述のようなアドレス解決処理ができなくなるので、通常はバックアップ用のalternate GK１０２が配置される。
【０００８】
このようなＶｏＩＰシステム１００に対して、ＥＰ１０３−１〜１０３−ｎが、primary GK１０１に自アドレス情報を登録する場合、登録手順（Ｈ．２２５．０のＲＡＳ（Registration Admission and Status）に規定されている）の中で、primary GK１０１からＥＰ１０３−１〜１０３−ｎへ、バックアップ用のalternate GK１０２が存在することが通知される。
【０００９】
具体的には、primary GK１０１は、自アドレス情報を登録してきたＥＰ１０３−１〜１０３−ｎにalternate GKのリストを“AlternateGK”として通知する。
ＥＰ１０３−１〜１０３−ｎは、primary GK１０１から受信した“AlternateGK”を解釈することによって、alternate GK１０２の存在（alternate GKが複数ある場合には、その優先順位も含まれる）を知ることができる。
【００１０】
【発明が解決しようとする課題】
しかし、上記のような従来のＶｏＩＰシステム１００に対し、ＥＰ１０３−１〜１０３−ｎがバックアップ用のalternate GK１０２へ接続する場合、primary GK１０１への登録が失敗したとき、または登録は成功したがその後の応答がなくなったときに（primary GK１０１の故障も含め）、ＥＰ１０３−１〜１０３−ｎは、初めてalternate GK１０２に対して登録することが規定されている。
【００１１】
図１７は従来のalternate GK１０２への登録の様子を示す図である。ＶｏＩＰシステム１００で、primary GK１０１とＥＰ１０３−１〜１０３−ｎとの通信が不可能になったときに、ＥＰ１０３−１〜１０３−ｎは、alternate GK１０２に対して登録する。
【００１２】
この規定に従うと、primary GK１０１からalternate GK１０２への切り替えの際、通話発信元のＥＰがalternate GK１０２への登録を先に終了し、着信先のＥＰがalternate GK１０２への登録を終了していないといった状態が発生する可能性があり、この場合には、音声通信を実行することができない。
【００１３】
すなわち、従来のalternate GKへの登録規定では、現行系のprimary GKからバックアップ用のalternate GKに切り替わる際に、通信不可能な時間帯が発生する場合があり、通信品質の悪化を引き起こすといった問題があった。
【００１４】
このような問題点に対して、解決案として、primary GKが保持しているアドレス情報をalternate GKに転送するという方法があるが、現在の勧告ではＧＫ間でアドレス情報を転送する手段については規定されていない。したがって、この方法では独自の方式となるために、異なるベンダ間での相互接続性を確保できなくなる。
【００１５】
さらに、alternate GKが最新のアドレス情報を持つためには、定期的な更新が必要となる。特にprimary GKとalternate GKが地理的に離れており、ＷＡＮ（Wide Area Network）を介しての接続となる場合には、定期更新のためのあらたな帯域を持たなければならない。
【００１６】
本発明はこのような点に鑑みてなされたものであり、現行系のＶｏＩＰサーバからバックアップ用のＶｏＩＰサーバへ切り替わる際のブランクをなくし、通信品質の向上を図った通信システムを提供することを目的とする。
【００１７】
【課題を解決するための手段】
本発明では上記課題を解決するために、図１に示すような、ＶｏＩＰの通信を行う通信システム１において、クライアントアドレス情報の一元管理を行うサーバ装置１０と、サーバ装置１０のバックアップを行うバックアップサーバ装置２０と、現行系のサーバ装置１０及びバックアップサーバ装置２０へ、クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部３２と、サーバ装置１０から、またはサーバ装置１０との通信が不可能になったときはバックアップサーバ装置２０から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部３３と、から構成されるクライアント装置３０と、を有することを特徴とする通信システム１が提供される。
【００１８】
ここで、サーバ装置１０は、クライアントアドレス情報の一元管理を行う。バックアップサーバ装置２０は、サーバ装置１０のバックアップを行う。クライアントアドレス情報登録通知部３２は、現行系のサーバ装置１０及びバックアップサーバ装置２０へ、クライアントアドレス情報を同時に登録通知する。通信制御部３３は、サーバ装置１０から、またはサーバ装置１０との通信が不可能になったときはバックアップサーバ装置２０から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う。また、クライアントアドレス情報登録通知部３２は、バックアップサーバ装置２０が複数台ある場合、クライアント装置３０とサーバ装置１０との通信が不可能になったとき、またはクライアント装置３０とクライアントアドレス情報を登録したバックアップサーバ装置２０との通信が不可能になったときに、クライアントアドレス情報が登録済みでないバックアップサーバ装置２０に対して、１台毎にクライアントアドレス情報を登録通知する。
【００１９】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。図１は通信システムの原理図である。通信システム１は、サーバ装置１０、バックアップサーバ装置２０、エンドポイントであるクライアント装置（以下、ＥＰ）３０−１〜３０−ｎを有して冗長系構成（サーバ装置１０及びバックアップサーバ装置２０の複数サーバを持つ）をとり、ネットワーク４（ＩＰネットワークやＬＡＮ等）上でＶｏＩＰ通信を行う。
【００２０】
現行系ゲートキーパであるサーバ装置（以下、primary GK）１０は、ＥＰ３０−１〜３０−ｎのクライアントアドレス情報の一元管理を行い、通常時には、ＥＰ３０−１〜３０−ｎとクライアント・サーバ通信を行う。
【００２１】
バックアップゲートキーパであるバックアップサーバ装置（以下、alternate GK）２０は、primary GK１０のバックアップを行う。alternate GK２０は、primary GK１０とＥＰ３０−１〜３０−ｎ間で通信が不可能になったときに、primary GK１０の代わりにクライアントアドレス情報を管理して、ＥＰ３０−１〜３０−ｎ間で通信を行うサーバである。なお、primary GK１０とalternate GK２０を総称する場合には、以降では単にＧＫと呼ぶ。
【００２２】
ＥＰ３０−１〜３０−ｎ（総称する場合はＥＰ３０）は、ネットワーク４との接続機能及び電話機能（または電話との接続機能）を有する、Ｈ．３２３システムにおけるクライアント機能を提供する端末装置に該当し、バックアップサーバ検出部３１、クライアントアドレス情報登録通知部３２、通信制御部３３から構成される。
【００２３】
バックアップサーバ検出部３１は、primary GK１０から送信されたalternate GK２０の存在を示す存在情報を受信して、alternate GK２０の検出を行う。
クライアントアドレス情報登録通知部３２は、primary GK１０と、検出したalternate GK２０へ、クライアントアドレス情報を同時に（例えば、システム起動時に）登録通知する。クライアントアドレス情報とは、ＥＰ３０に関する、電話番号、ＩＰアドレス、ユーザ名等のアドレス情報のことである。
【００２４】
通信制御部３３は、通常時はprimary GK１０から、またprimary GK１０との通信が不可能になったときはalternate GK２０から送信された、ＥＰ間で音声通信を行う際の着信先のＩＰアドレスを受信する。さらに、primary GK１０またはalternate GK２０から設定された伝送帯域の確保を行う。
【００２５】
ここで、従来では、primary GK１０とＥＰ３０との通信が不可能になったときに初めて、ＥＰ３０は、alternate GK２０に対してクライアントアドレス情報を登録していたが、本構成では、クライアントアドレス情報をprimary GK１０とalternate GK２０へ同時に登録通知することにした。これにより、ＥＰ３０とprimary GK１０との通信が不可能になった場合に、即時にalternate GK２０との通信を開始できるので、ＥＰ間の音声通信を瞬断なく継続実行することが可能になる。
【００２６】
次にprimary GK１０とalternate GK２０の構成について説明する。図２はprimary GK１０の構成を示す図である。primary GK１０は、存在情報通知部１１、現行系クライアントアドレス情報登録部１２、現行系通信設定部１３、現行系登録保持設定部１４から構成される。
【００２７】
存在情報通知部１１は、ＥＰ３０へ、alternate GK２０の存在を示す存在情報の通知を行う。また、alternate GK２０が複数台ある場合には、ＥＰ３０との通信が不可能になったときに、alternate GK２０に対する負荷を分散させるために、存在情報の内容をＥＰ３０によって変更して通知する（図９、１０で後述）。
【００２８】
現行系クライアントアドレス情報登録部１２は、ＥＰ３０から送信されたクライアントアドレス情報を登録する。現行系通信設定部１３は、クライアントアドレス情報のアドレス解決処理を行って、通話着信先のＥＰのＩＰアドレスを求め、発信元のＥＰ３０へ送信する。また、発信元のＥＰ３０に対して伝送帯域を設定する。
【００２９】
現行系登録保持設定部１４は、クライアントアドレス情報の登録を保持するための登録保持メッセージをＥＰ３０へ送信する。なお、登録保持メッセージに関する処理については図５〜図７で後述する。
【００３０】
図３はalternate GK２０の構成を示す図である。alternate GK２０は、バックアップ用クライアントアドレス情報登録部２２、バックアップ用通信設定部２３、バックアップ用登録保持設定部２４から構成される。
【００３１】
バックアップ用クライアントアドレス情報登録部２２は、ＥＰ３０から送信されたクライアントアドレス情報を登録する。バックアップ用通信設定部２３は、バックアップを行う場合、クライアントアドレス情報のアドレス解決処理を行って、通話着信先のＥＰのＩＰアドレスを求め、発信元のＥＰ３０へ送信する。また、ＥＰ３０に対して伝送帯域を設定する。
【００３２】
バックアップ用登録保持設定部２４は、バックアップを開始しない場合には、クライアントアドレス情報の登録を保持するための登録保持メッセージの送信間隔を、primary GK１０での登録保持メッセージの送信間隔よりも長く設定してＥＰ３０へ送信する。また、バックアップを開始した場合には、この送信間隔を短く設定して送信する。図５〜図７で後述する。
【００３３】
次に通信システム１の動作について詳しく説明する（第１の実施の形態とする）。図４はＲＡＳシグナリングを示すシーケンス図である。ＲＡＳは、ＥＰ３０が、ＧＫにクライアントアドレス情報を登録する際のシグナリング手順である。
【００３４】
図中のGK discoveryとは、ＥＰ３０がＧＫを動的に発見するための手順（オプション）である。通常、ＥＰ３０からはマルチキャストでＧＫを検出するためのメッセージが送信される。そして、そのメッセージに対して、同一ゾーン（ＧＫが管理対象とするＥＰの範囲）内のＧＫが応答する。ＥＰ３０は、この応答メッセージにてalternate GK（及び primary GK ）の存在を知ることができる。
【００３５】
EP registration処理とは、ＥＰ３０のエイリアスアドレス（電話番号やユーザ名等）やＩＰアドレスがマッピングされたクライアントアドレス情報を登録するための手順である。
【００３６】
なお、ＧＫ側では、この手順で得た管理対象のＥＰ３０のクライアントアドレス情報を内部テーブルに保持する。そして、Admission/bandwidth controlによるアドレス解決要求を受け付けた際に、エイリアスアドレスをキーとしたＩＰアドレスの解決を行う。Admission/bandwidth control処理とは、アドレス解決によりＩＰアドレスを求め、音声伝送に必要な帯域の割当てを行うための手順である。
〔Ｓ１〕ＥＰ３０のバックアップサーバ検出部３１は、GRQ（Gatekeeper Request）メッセージをマルチキャスト等によって送信する。GRQメッセージには、ＥＰ３０がalternate GK２０をサポートすることを意味する“supportsAltGK”を含んでおく（なお、本構成は、ＥＰ３０のみが意識して動作すればよいため、ＧＫに対して本構成の機能の存在を通知する必要はない）。
【００３７】
そして、ゾーン内のprimary GK１０の存在情報通知部１１は、GCF（Gatekeeper Confirm）メッセージで応答する。GCFメッセージには、alternate GK２０が存在する場合、そのalternate GK２０のトランスポートアドレス（ＩＰアドレス、ポート番号）が“AlternateGK”に含まれる。これにより、バックアップサーバ検出部３１は、alternate GK２０の存在を知ることができる。
【００３８】
なお、ＧＫ自身がprimaryなのか、alternateなのかは、事前にＧＫに設定しておくか、ＧＫ間で独自に情報（ＩＰアドレス、ＭＡＣアドレス等）を交換し、その値の大小によって自分がprimaryなのかalternateかを判断するように設定する。また、ステップＳ１の手順は、ＥＰ３０にとってオプションであり、ＥＰ３０に静的にＧＫのアドレス情報を設定しておけば、この手順を省略することができる。
〔Ｓ２ａ〕ＥＰ３０のクライアントアドレス情報登録通知部３２は、primary GK１０にRRQ（Registration Request）メッセージを送信して、自身のクライアントアドレス情報をprimary GK１０に通知する。このメッセージをprimary GK１０の現行系クライアントアドレス情報登録部１２が受け入れた場合は、RCF（Registration Confirm）メッセージで応答する。
〔Ｓ２ｂ〕クライアントアドレス情報登録通知部３２は、primary GK１０への登録動作と同様にして、Admission/bandwidth controlに移行する前に、alternate GK２０に対しても、RRQメッセージを送信する。そして、alternate GK２０に受け入れられた場合には、RCFメッセージによる応答を受ける。なお、この処理は、primary GK１０のゾーン内の全ＥＰが実行する。
〔Ｓ３〕ＥＰ３０の通信制御部３３は、ARQ（Address Request）メッセージをprimary GK１０へ送信する。primary GK１０の現行系通信設定部１３は、ARQメッセージを受信すると、内部テーブルにもとづき、アドレス解決を行って着信先ＥＰのＩＰアドレスを求め、かつ音声伝送に必要な帯域の設定を行う。
【００３９】
そして、現行系通信設定部１３は、ＩＰアドレスと帯域設定情報をACF（Address Confirm）メッセージに含めてＥＰ３０へ送信する。ＥＰ３０の通信制御部３３は、受信したACFメッセージにより、着信先のＩＰアドレスを認識し、かつ伝送帯域を確保する。
【００４０】
以上説明したような、ステップＳ１〜ステップＳ３による処理を行うことで、primary GK１０とalternate GK２０は同じクライアントアドレス情報を保持することができ、ＥＰ３０がprimary GK１０との通信が不可能になった場合には、即時にalternate GK２０との通信を開始して、ＥＰ間の音声通信を継続することができる。
【００４１】
なお、上記のシーケンス処理の中で拒絶される場合のメッセージは、GCFの代わりにGRJ（Gatekeeper Reject）、RCFの代わりにRRJ（Registration Reject）、ACFの代わりにARJ（Address Reject）となる。
【００４２】
ここで、primary GK１０が復旧したときの自動復帰については、通信不可能となったprimary GK１０に対して、ＥＰ３０のクライアントアドレス情報登録通知部３２は、RRQメッセージを定期的に送信し続け（ただし、トラフィック量や負荷を抑えるために、RRQメッセージの送信間隔は長く設定する）、RCFメッセージを受信した時点で復旧したと判断する。その後、alternate GK２０から、復旧したprimary GK１０へ接続が切り替わり、ＥＰ３０とprimary GK１０との通信が再開する。
【００４３】
次にＧＫで管理されるクライアントアドレス情報テーブル及び登録保持メッセージについて説明する。primary GK１０とalternate GK２０は、ＥＰ３０から送信されたクライアントアドレス情報をもとに、クライアントアドレス情報テーブルを作成する。
【００４４】
また、primary GK１０の現行系登録保持設定部１４及びalternate GK２０のバックアップ用登録保持設定部２４では、ＥＰ３０による登録を保持するために（ＥＰ３０が正常に動作しているか否かを判断するために）、ＥＰ３０に対して登録保持メッセージ（以下、KeepAlive）を送信する。
【００４５】
このとき、primary GK１０がＥＰ３０に通知するKeepAliveの送信間隔（以下timeToLive）よりも、alternate GK２０が通知するKeepAliveのtimeToLiveの方を長く設定する。
【００４６】
図５はprimary GK１０が管理するクライアントアドレス情報テーブルを示す図である。クライアントアドレス情報テーブルＴ１は、ＥＰ３０のＩＤを示すＥＰ##ＩＤ、そのＩＤに対応するＥＰのトランスポートアドレス（図ではＩＰアドレスが記されている）、エイリアスアドレス（図では電話番号が記されている）及び時刻情報の項目から構成される。
【００４７】
時刻情報とは、KeepAliveを送信する時刻（内部クロックにもとづく）のことであり、内部時刻＋timeToLiveで管理される。内部時刻とは、１つ前に送信したKeepAliveの送信済み時刻のことである。時刻情報の例として、内部時刻＋timeToLive＝10:48:29＋60sとは、１つ前に送信したKeepAliveの送信時刻は10:48:29であり、次のKeepAliveの送信時刻は10:49:29（＝10:48:29＋60s）ということである。
【００４８】
図６はalternate GK２０が管理するクライアントアドレス情報テーブルを示す図である。クライアントアドレス情報テーブルＴ２の各項目は、図５の場合と同様である。ただし、時刻情報のtimeToLiveが60sから3600sと長く設定されている。
【００４９】
このように、バックアップ用登録保持設定部２４が送信するKeepAliveのtimeToLiveは、現行系登録保持設定部１４が送信するKeepAliveのtimeToLiveよりも長く設定しておくことで、トラフィック量や負荷の増大を抑制することができる。
【００５０】
図７はalternate GK２０がバックアップを開始した際のクライアントアドレス情報テーブルを示す図である。ＥＰ３０とprimary GK１０との通信が不可能になり、alternate GK２０がバックアップを開始した場合には、バックアップ用登録保持設定部２４は、長く設定していたtimeToLiveを短く設定する。
【００５１】
クライアントアドレス情報テーブルＴ２ａは、上述した項目の他に、あらたに呼受付状態の項目が追加される。alternate GK２０がバックアップ開始後に、該当のＥＰからARQメッセージを受信した場合には、呼受付状態はActiveとなり、ARQメッセージを受信しない場合は、Passiveとなる。
【００５２】
そして、呼受付状態がActiveのＥＰに対しては、そのＥＰに対してバックアップ動作を開始したことになるので、KeepAliveのtimeToLiveを短く設定する。また、呼受付状態がPassiveのＥＰに対しては、そのＥＰに対してはバックアップ動作はまだ開始していないので、KeepAliveのtimeToLiveは変更せずに、図６で設定した値にしておく。
【００５３】
図では、ＥＰ＿ＩＤ＝０００１、０００３のＥＰは、Activeであるから、時刻情報をそれぞれ10:48:29＋3600s→10:48:29＋60s、11:03:53＋3600s→11:03:53＋60sに切り替え、ＥＰ＿ＩＤ＝０００２はPassiveであるから、10:55:32＋3600sのままとする。
【００５４】
次に第２の実施の形態について説明する。第１の実施の形態では、alternate GKが１台の場合であるが、より強固なシステムを構築するためにalternate GKを２台以上設置することも考えられる。
【００５５】
この場合、ＥＰ３０がすべてのalternate GKに対して、ＲＡＳチャネル（ＥＰとＧＫ間でＲＡＳ手順を実行するためのチャネル）を設定してしまうと、ＥＰが保持するＲＡＳチャネル数が増えてしまい、トラフィックの増加及びＥＰ３０に対する負荷が過大になってしまう。
【００５６】
したがって、第２の実施の形態では alternate GKが２台以上存在する場合、ＥＰ３０とprimary GK１０との通信が不可能になったとき、または、ＥＰ３０とバックアップを開始したalternate GKとの通信が不可能になったときに、クライアントアドレス情報が登録済みでないalternate GKに対して、１台毎にクライアントアドレス情報を登録通知するものである。図８を用いてこの様子を説明する。
【００５７】
図８は第２の実施の形態のＲＡＳシグナリングを示すシーケンス図である。Alternate GK２０−１、２０−２の２台の場合における処理を示す。
〔Ｓ１１〕ＥＰ３０とprimary GK１０間で、GK discovery処理としてGRQ／GCFメッセージの通信を行う。
〔Ｓ１２〕ＥＰ３０とprimary GK１０間で、EP registration処理としてRRQ／RCFメッセージの通信を行う。
〔Ｓ１３〕ＥＰ３０とalternate GK２０−１間で、EP registration処理としてRRQ／RCFメッセージの通信を行う。
〔Ｓ１４〕ＥＰ３０とprimary GK１０間で、Admission/bandwidth control処理としてARQ／ACFメッセージの通信を行う。
〔Ｓ１５〕ＥＰ３０とprimary GK１０との通信が不可能になったとする。
〔Ｓ１６〕ＥＰ３０とalternate GK２０−２間で、EP registration処理としてRRQ／RCFメッセージの通信を行う。
〔Ｓ１７〕ＥＰ３０とalternate GK２０−１間で、Admission/bandwidth control処理としてARQ／ACFメッセージの通信を行う。
【００５８】
すなわち、複数台のalternate GKを第１〜第ｎのalternate GKとすると、ＥＰ３０とprimary GK１０との通信が不可能になった時点で、第２のalternate GKにクライアントアドレス情報を登録通知し、第１のalternate GKとの通信が不可能になった時点で、第３のalternate GKにクライアントアドレス情報を登録通知する、というように常に２本のＲＡＳチャネルを保持するようにする。
【００５９】
なお、この場合、ＥＰ３０は、ＲＣＦメッセージに含まれる“AlternateGK”によって、alternate GKの存在だけでなくプライオリティも知ることができるので、優先度の高い順に２つのＲＡＳチャネルを保持するようにしてもよい。
【００６０】
次に第３の実施の形態について説明する。第３の実施の形態では、alternate GKが複数台ある場合、alternate GKの存在を示す“AlternateGK”の内容を、ＥＰ３０によって変更して通知し、alternate GKに対する負荷を分散させるものである。
【００６１】
図９は複数のalternate GKが配置されたシステムの構成を示す図である。ＶｏＩＰシステム１ａに対し、センター拠点（本社）５は、primary GK５１、ＥＰ５２−１〜５２−３、ルータ５３を有し、バス配線によってそれぞれ接続する。リモート拠点（支店）６は、alternate GK６１、ＥＰ６２−１〜６２−３、ルータ６３を有し、バス配線によってそれぞれ接続する。リモート拠点（支店）７は、alternate GK７１、ＥＰ７２−１〜７２−３、ルータ７３を有し、バス配線によってそれぞれ接続する。
【００６２】
また、ルータ５３は、アクセス回線Ｃ１（３Ｍｂｐｓ）でＩＰ−ＶＰＮ（Virtual Private Network）４ａと接続し、ルータ６３は、アクセス回線Ｃ２（１．５Ｍｂｐｓ）でＩＰ−ＶＰＮ４ａと接続し、ルータ７３は、アクセス回線Ｃ３（１．５Ｍｂｐｓ）でＩＰ−ＶＰＮ４ａと接続する。
【００６３】
このような構成のＶｏＩＰシステム１ａに対し、通常時では、図中の点線枠で示すゾーン内で、primary GK５１をサーバとしたＶｏＩＰ通信が行われる。ところが、センター拠点（本社）５に設置されたprimary GK５１が故障した場合、例えば、alternate GK６１のみがバックアップを開始したとすると、アクセス回線の速度が遅いリモート拠点（支店）６のalternate GK６１に対して、すべてのＥＰがアクセスを実行するため、レスポンスが悪くなるといった問題が発生する。
【００６４】
図１０は複数のalternate GKによりバックアップを行う際の様子を示す図である。ＶｏＩＰシステム１ａに対し、primary GK５１が故障した場合、第３の実施の形態では、alternate GK６１、７１の両方でバックアップを開始する。図では、alternate GK６１は、ゾーンｚ１として、ＥＰ５２−２、５２−３、ＥＰ６２−１〜ＥＰ６２−３をカバーし、alternate GK７１はゾーンｚ２として、ＥＰ５２−１、ＥＰ７２−１〜ＥＰ７２−３をカバーする。
【００６５】
すなわち、システム起動時に、primary GK５１は、ＥＰ５２−２、５２−３、ＥＰ６２−１〜ＥＰ６２−３に対してはバックアップ用サーバとしてalternate GK６１の存在を通知し、ＥＰ５２−１、ＥＰ７２−１〜ＥＰ７２−３に対してはバックアップ用サーバとしてalternate GK７１の存在を通知しておく。
【００６６】
これにより、primary GK５１との通信が不可能になった場合に、alternate GK６１はＥＰ５２−２、５２−３、ＥＰ６２−１〜ＥＰ６２−３をバックアップし、alternate GK７１はＥＰ５２−１、ＥＰ７２−１〜ＥＰ７２−３をバックアップするので、負荷が分散され、レスポンス悪化を抑制することが可能になる。
【００６７】
ここで、上述したＶｏＩＰシステム１ａのように、企業などにおいてalternate GKを設置する場合、自然災害などの影響を考慮して地理的に離れている拠点にalternate GKを設置することが考えられる。
【００６８】
企業の通信形態として、ホストコンピュータを設置しているセンター拠点にprimary GKを設置し、そのホストコンピュータにアクセスする端末が設置されているリモート拠点にalternate GKを設置する場合が多い。ところが、このようなシステムでは、primary GKからalternate GKに切り替わるとレスポンスが悪くなる可能性が高い。
【００６９】
したがって、第３の実施の形態では、primary GKがＥＰに通知する “AlternateGK”の内容をＥＰによって変更する（すなわち、alternate GKの規模やその拠点のアクセス回線速度によって、ゾーンの範囲を変更する）ことによって、primary GKのバックアップを複数のalternate GKで実現する。
【００７０】
これにより、alternate GKが管理するゾーンの範囲を小さくできるので、アクセス回線速度がボトルネックになって生じるレスポンスの悪化を抑制することが可能になる。または逆に、primary GKを複数で運用し、１台のalternate GKでバックアップすることも可能である。
【００７１】
次に第４の実施の形態について説明する。第１〜第３の実施の形態は、alternate GKを設置することを前提としているが、第４の実施の形態では、alternate GKを設置せずに、primary GKに登録された最新のアドレス情報をＥＰが保持することによって、primary GKとの通信が不可能になった場合に、ＥＰ内部でアドレス解決を行ない、ＥＰ間の通信を実現するものである。
【００７２】
図１１は第４の実施の形態の通信システムの構成を示す図である。通信システム１ｂは、ＥＰ３０ｂとprimary GK１０ｂから構成される。
ＥＰ３０ｂに対し、クライアントアドレス情報取得部３０ｂ−１は、クライアントアドレス情報または差分情報（ＥＰが追加または削除した際の変更情報）を取得する。通信部３０ｂ−２は、クライアントアドレス情報のアドレス解決処理を行い、現行系サーバとの通信が不可能になったときに、クライアント同士で通信を行う。
【００７３】
primary GK１０ｂに対し、クライアントアドレス情報通知部１０ｂ−１は、登録要求のあったＥＰに、登録されているクライアントアドレス情報を一括して通知する。差分情報通知部１０ｂ−２は、あらたにクライアントアドレス情報が登録された場合は、クライアントアドレス情報の差分情報のみを登録済みのＥＰへ通知する。
【００７４】
図１２は第４の実施の形態におけるクライアントアドレス情報の通知手順を示すシーケンス図である。
〔Ｓ２１〕ＥＰ３０ｂ−ａとprimary GK１０ｂ間で、RRQ／RCFメッセージの通信を行う。
〔Ｓ２２〕primary GK１０ｂのクライアントアドレス情報通知部１０ｂ−１は、システム起動時から一定時間（図では３６００秒）経過後に、登録済みのクライアントアドレス情報をＥＰ３０ｂ−ａへ一括して送信する。ＥＰ３０ｂ−ａのクライアントアドレス情報取得部３０ｂ−ａは、クライアントアドレス情報を一括して取得する。
〔Ｓ２３〕ＥＰ３０ｂ−ｂとprimary GK１０ｂ間で、RRQ／RCFメッセージの通信を行う（あらたにＥＰ３０ｂ−ｂが登録要求をしてきた状態）。
〔Ｓ２４ａ〕primary GK１０ｂの差分情報通知部１０ｂ−２は、あらたにクライアントアドレス情報が登録されたので、このクライアントアドレス情報（差分情報）のみを、すでに登録済みのＥＰ３０ｂ−ａへ通知する。
〔Ｓ２４ｂ〕primary GK１０ｂのクライアントアドレス情報通知部１０ｂ−１は、クライアントアドレス情報を一括してＥＰ３０ｂ−ｂへ通知する。
〔Ｓ２５〕ＥＰ３０ｂ−ｂとprimary GK１０ｂ間で、RRQ／RCFメッセージの通信を行う（あらたにＥＰ３０ｂ−ｃが登録要求をしてきた状態）。
〔Ｓ２６ａ〕primary GK１０ｂの差分情報通知部１０ｂ−２は、あらたにクライアントアドレス情報が登録されたので、このクライアントアドレス情報（差分情報）のみを、登録済みのＥＰ３０ｂ−ａ、３０ｂ−ｂへ通知する。
〔Ｓ２６ｂ〕primary GK１０ｂのクライアントアドレス情報通知部１０ｂ−１は、クライアントアドレス情報を一括してＥＰ３０ｂ−ｃへ通知する。
【００７５】
このように、第４の実施の形態では、primary GKに登録された最新のアドレス情報をＥＰが保持するために、ＥＰとprimary GK間で定期的に通信を行う。ただし、頻繁に大量のクライアントアドレス情報をやりとりするのは負荷増大に繋がるため、必要最小限に抑える必要がある。
【００７６】
このためには、例えば、primary GKに電源が投入されて一定時間経過した後に、その時点でprimary GKが保持しているクライアントアドレス情報を登録された全てのＥＰに一括送信する。その後、primary GKが保持しているクライアントアドレス情報が変更された時点でＥＰにその変更分だけを通知すればよい。
【００７７】
なお、クライアントアドレス情報の通知は、独自の手順で行なっても良いし、標準で定義されているＲＡＳメッセージの拡張（例えば、RCFメッセージにprimary GKが保有するクライアントアドレス情報を含ませて、ＥＰに通知する）によって実現することもできる。
【００７８】
次にＥＰの登録によりＧＫでアドレス解決が行われるまでの流れについてフローチャートを用いて説明する。図１３、図１４はＥＰの登録によりＧＫでアドレス解決が行われるまでの処理手順を示すフローチャートである。
〔Ｓ３１〕ＥＰは、登録時に、primary GKから送信されたRCFメッセージを受信し、RCFメッセージ内にalternate GKの存在を示す“AlternateGK”があるか否かを判断する。なければステップＳ３２へ、あればステップＳ３７へ行く。
〔Ｓ３２〕ＥＰは、一定時間経過後に、クライアントアドレス情報をprimary GKから一括して受信する。
〔Ｓ３３〕システムに対して、ＥＰの追加／削除があった場合は、ステップＳ３４へ行き、なければこの判断処理を繰り返す。
〔Ｓ３４〕すでに登録済みのＥＰは差分情報を受信し、あらたに登録したＥＰはクライアントアドレス情報を一括して受信する。
〔Ｓ３５〕ＥＰとprimary GKとの通信が不可能になった場合は、ステップＳ３６へ、そうでなければステップＳ３３へ戻る。
〔Ｓ３６〕ＥＰ内部でアドレス解決処理を行う。
〔Ｓ３７〕ＥＰは、第１のalternate GKに登録を行う。
〔Ｓ３８〕ＥＰとprimary GKとの通信が不可能になった場合は、ステップＳ３９へ、そうでなければこの判断処理を繰り返す。
〔Ｓ３９〕ＥＰは、第２のalternate GKに登録を行う。
〔Ｓ４０〕ＥＰは、通信不可能となったＧＫにRRQメッセージを定期的に送信する。
〔Ｓ４１〕RRCメッセージを返信したＧＫによってアドレス解決処理が行われる。
【００７９】
次にＥＰ３０の機能ブロックについて説明する。図１５はＥＰ３０の機能ブロックを示す図である。画像コーデック(Ｈ．２６１，Ｈ．２６３)３ａは、画像信号の符号化／復号化を行う。音声コーデック(Ｇ７００シリーズ，特にＧ．７１０−７２９)３ｂは、音声信号の符号化／復号化を行う。
【００８０】
システムコントロールユニット３ｃは、メディア制御部（Ｈ．２４５）３ｃ−１は、呼制御部（Ｈ．２２５．０）３ｃ−２、ＲＡＳ制御部（Ｈ．２２５．０）３ｃ−３から構成される。
【００８１】
メディア制御部（Ｈ．２４５）３ｃ−１は、ＥＰ間の主従関係、使用するコーデックなどの能力交換機能を提供するとともに、音声、画像及びデータを送受信するための論理チャネル（Logical Channel）ＣＨ１をＵＤＰ（User Datagram Protocol）上に設定する。論理チャネルＣＨ１を設定するためのＥＰ間でのやりとりは、ＴＣＰ（Transport Control Protocol）上のＨ．２４５コントロールチャネル（Control Channel）ＣＨ２を使って行う。
【００８２】
呼制御部（Ｈ．２２５．０）３ｃ−２は、ＥＰ間で通話を開始するために必要な情報（電話番号等）の交換を行う。この情報は、ＥＰ間に設定されたＴＣＰ上の呼シグナリングチャネル（Call Signaling Channel）ＣＨ３で送受信する。
【００８３】
ＲＡＳ制御部（Ｈ．２２５．０）３ｃ−３は、ＥＰがＧＫに対して、電話番号等のアドレス情報の登録、アドレス解決などを行う機能を提供する。これらのやりとりは、ＥＰとＧＫ間で、ＵＤＰ上のＲＡＳチャネル（RAS Channel）ＣＨ４を使って行う。また、ＥＰ３０の機能ブロックは、ＲＡＳ制御部３ｃ−３に含まれる。
【００８４】
ＲＴＰ（Real-Time Transport Control Protocol）／ＲＴＣＰ制御部３ｄは、符号化された音声や画像を送受信するために、ＩＰパケットにカプセリングする機能やそのＩＰパケットを制御（モニタ等）する機能を提供する。
【００８５】
ネットワークインタフェースカード（ＮＩＣ）３ｅは、ＬＡＮなどのネットワークに接続するためのデータリンクレイヤ及び物理レイヤ機能を提供する。
以上説明したように、 alternate GK２０への切り替えを瞬時に行うことができるため、エンドユーザにとっては、ＧＫの障害を意識することなく、高い可用性のもとで音声通信を行うことが可能になる。
【００８６】
なお、ＶｏＩＰ製品は、現在ではＨ．３２３対応製品が多く出荷されているために、上記の説明では、Ｈ．３２３をベースにして行ったが、これから製品化が始まる予定であるＳＩＰのクライアント・サーバシステムにも本発明を適用可能である。
【００８７】
（付記１） ＶｏＩＰの通信を行う通信システムにおいて、
クライアントアドレス情報の一元管理を行うサーバ装置と、
前記サーバ装置のバックアップを行うバックアップサーバ装置と、
現行系の前記サーバ装置及び前記バックアップサーバ装置へ、前記クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部と、前記サーバ装置から、または前記サーバ装置との通信が不可能になったときは前記バックアップサーバ装置から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部と、から構成されるクライアント装置と、
を有することを特徴とする通信システム。
【００８８】
（付記２） 前記クライアント装置は、前記バックアップサーバ装置の存在を示す存在情報を前記サーバ装置から受信して、前記バックアップサーバ装置の検出を行うバックアップサーバ検出部をさらに有することを特徴とする付記１記載の通信システム。
【００８９】
（付記３） 前記クライアントアドレス情報登録通知部は、前記バックアップサーバ装置が複数台ある場合、前記クライアント装置と前記サーバ装置との通信が不可能になったとき、または前記クライアント装置と前記クライアントアドレス情報を登録したバックアップサーバ装置との通信が不可能になったときに、前記クライアントアドレス情報が登録済みでないバックアップサーバ装置に対して、１台毎に前記クライアントアドレス情報を登録通知することを特徴とする付記１記載の通信システム。
【００９０】
（付記４） 前記クライアントアドレス情報登録通知部は、通信が不可能になったサーバ装置へ、前記クライアントアドレス情報を定期的に送信し、登録許可を受信したときには復旧したとみなし、前記クライアント装置は、復旧した前記サーバ装置へ接続を切り替えることを特徴とする付記１記載の通信システム。
【００９１】
（付記５） 前記サーバ装置は、前記バックアップサーバ装置が複数台ある場合、前記クライアント装置と前記サーバ装置との通信が不可能になったときに、前記バックアップサーバ装置に対するバックアップ時の負荷を分散させるために、前記バックアップサーバ装置の存在を示す存在情報の内容を前記クライアント装置によって変更して通知することを特徴とする付記１記載の通信システム。
【００９２】
（付記６） 前記バックアップサーバ装置は、前記クライアントアドレス情報の登録を保持するための登録保持メッセージの送信間隔を、前記サーバ装置での登録保持メッセージの送信間隔よりも長く設定することを特徴とする付記１記載の通信システム。
【００９３】
（付記７） 前記バックアップサーバ装置は、バックアップを開始した場合、前記サーバ装置よりも長く設定していた前記登録保持メッセージの前記送信間隔を短く設定することを特徴とする付記６記載の通信システム。
【００９４】
（付記８） クライアント側のＶｏＩＰの通信を行うクライアント装置において、
現行系のサーバ装置及びバックアップサーバ装置へ、クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部と、
前記サーバ装置から、または前記サーバ装置との通信が不可能になったときは前記バックアップサーバ装置から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部と、
を有することを特徴とするクライアント装置。
【００９５】
（付記９） 前記バックアップサーバ装置の存在を示す存在情報をサーバ装置から受信して前記バックアップサーバ装置の検出を行うバックアップサーバ検出部をさらに有することを特徴とする付記８記載のクライアント装置。
【００９６】
（付記１０） 前記クライアントアドレス情報登録通知部は、前記バックアップサーバ装置が複数台ある場合、前記クライアント装置と前記サーバ装置との通信が不可能になったとき、または前記クライアント装置と前記クライアントアドレス情報を登録したバックアップサーバ装置との通信が不可能になったときに、前記クライアントアドレス情報が登録済みでないバックアップサーバ装置に対して、１台毎に前記クライアントアドレス情報を登録通知することを特徴とする付記８記載のクライアント装置。
【００９７】
（付記１１） 前記クライアントアドレス情報登録通知部は、通信が不可能になったサーバ装置へ、前記クライアントアドレス情報を定期的に送信し、登録許可を受信したときには復旧したとみなし、復旧した前記サーバ装置へ接続が切り替わることを特徴とする付記８記載のクライアント装置。
【００９８】
（付記１２） 現行系サーバ側のＶｏＩＰの通信を行うサーバ装置において、クライアント装置へ、バックアップサーバ装置の存在を示す存在情報の通知を行い、前記バックアップサーバ装置が複数台ある場合には、前記クライアント装置と前記サーバ装置との通信が不可能になったときに、前記バックアップサーバ装置に対するバックアップ時の負荷を分散させるために、前記存在情報の内容を前記クライアント装置によって変更して通知する存在情報通知部と、
送信されたクライアントアドレス情報を登録する現行系クライアントアドレス情報登録部と、
前記クライアントアドレス情報のアドレス解決処理を行って求めた、着信先のＩＰアドレスを前記クライアント装置へ送信し、伝送帯域を設定する現行系通信設定部と、
前記クライアントアドレス情報の登録を保持するための登録保持メッセージを送信する現行系登録保持設定部と、
を有することを特徴とするサーバ装置。
【００９９】
（付記１３） バックアップサーバ側のＶｏＩＰの通信を行うバックアップサーバ装置において、
送信されたクライアントアドレス情報を登録するバックアップ用クライアントアドレス情報登録部と、
前記クライアントアドレス情報のアドレス解決処理を行って求めた、着信先のＩＰアドレスをクライアント装置へ送信し、伝送帯域を設定するバックアップ用通信設定部と、
前記クライアントアドレス情報の登録を保持するための登録保持メッセージの送信間隔を、サーバ装置での登録保持メッセージの送信間隔よりも長く設定して送信し、バックアップ開始時には、前記送信間隔を短く設定して送信するバックアップ用登録保持設定部と、
を有することを特徴とするバックアップサーバ装置。
【０１００】
（付記１４） ＶｏＩＰの通信を行う通信システムにおいて、
クライアントアドレス情報または差分情報を取得するクライアントアドレス情報取得部と、前記クライアントアドレス情報のアドレス解決処理を行い、現行系サーバとの通信が不可能になったときに、クライアント同士で通信を行う通信部と、から構成されるクライアント装置と、
登録要求のあったクライアント装置に、登録されているクライアントアドレス情報を一括して通知するクライアントアドレス情報通知部と、あらたにクライアントアドレス情報が登録された場合は、クライアントアドレス情報の前記差分情報のみを登録済みのクライアント装置へ通知する差分情報通知部と、から構成される現行系のサーバ装置と、
を有することを特徴とする通信システム。
【０１０１】
（付記１５） クライアント側のＶｏＩＰの通信を行うクライアント装置において、
クライアントアドレス情報または差分情報を取得するクライアントアドレス情報取得部と、
前記クライアントアドレス情報のアドレス解決処理を行い、現行系サーバとの通信が不可能になったときに、クライアント同士で通信を行う通信部と、
を有することを特徴とするクライアント装置。
【０１０２】
（付記１６） 現行系サーバ側のＶｏＩＰの通信を行うサーバ装置において、
登録要求のあったクライアント装置に、登録されているクライアントアドレス情報を一括して通知するクライアントアドレス情報通知部と、
あらたにクライアントアドレス情報が登録された場合は、クライアントアドレス情報の差分情報のみを登録済みのクライアント装置へ通知する差分情報通知部と、
を有することを特徴とするサーバ装置。
【０１０３】
（付記１７） ＶｏＩＰの通信を行うＶｏＩＰ通信方法において、
クライアント機能を持つエンドポイントと、サーバ機能を持つ現行系ゲートキーパとの間で、前記現行系ゲートキーパのバックアップ用のバックアップゲートキーパを見つけるためのGK discovery処理を行い、
前記エンドポイントが、前記現行系ゲートキーパ及び前記バックアップゲートキーパへ、クライアントアドレス情報を同時に登録通知するＥＰ registration処理を行い、
前記エンドポイントと前記現行系ゲートキーパとの間で、または前記現行系ゲートキーパとの通信が不可能になったときは、前記エンドポイントと前記バックアップ用ゲートキーパとの間で、ＩＰアドレスの解決及び帯域割り当てを行うためのAdmission/bandwidth control処理を行い、
通常時には、前記エンドポイントと前記現行系ゲートキーパとの間で通信を行い、前記現行系ゲートキーパとの通信が不可能になった場合には、前記エンドポイントと、瞬断なく接続が切り替わった前記バックアップ用ゲートキーパとの間で通信を行うことを特徴とするＶｏＩＰ通信方法。
【０１０４】
（付記１８） 前記バックアップゲートキーパが複数台ある場合、前記エンドポイントと前記現行系ゲートキーパとの通信が不可能になったとき、または前記エンドポイントと前記クライアントアドレス情報を登録したバックアップゲートキーパとの通信が不可能になったときに、前記クライアントアドレス情報が登録済みでないバックアップゲートキーパに対して、１台毎に前記クライアントアドレス情報を登録通知することを特徴とする付記１７記載のＶｏＩＰ通信方法。
【０１０５】
（付記１９） 通信が不可能になった現行系ゲートキーパへ、前記クライアントアドレス情報を定期的に送信し、登録許可を受信したときには復旧したとみなし、前記バックアップゲートキーパから、復旧した前記現行系ゲートキーパへ接続を切り替えることを特徴とする付記１７記載のＶｏＩＰ通信方法。
【０１０６】
（付記２０） 前記バックアップゲートキーパが複数台ある場合、前記エンドポイントと前記現行系ゲートキーパとの通信が不可能になったときに、前記バックアップゲートキーパに対する負荷を分散させるために、前記バックアップゲートキーパの存在を知らせるための情報の内容を前記エンドポイントによって変更して通知することを特徴とする付記１７記載のＶｏＩＰ通信方法。
【０１０７】
（付記２１） 前記バックアップゲートキーパでのKeepAliveのTimeToLiveを、前記現行系ゲートキーパでのKeepAliveのTimeToLiveよりも長く設定することを特徴とする付記１７記載のＶｏＩＰ通信方法。
【０１０８】
（付記２２） 前記バックアップゲートキーパがバックアップを開始した場合、前記現行系ゲートキーパよりも長く設定していた前記KeepAliveの前記TimeToLiveを短く設定することを特徴とする付記２１記載のＶｏＩＰ通信方法。
【０１０９】
（付記２３） ＶｏＩＰの通信を行うＶｏＩＰ通信方法において、
サーバ側では、登録要求のあったクライアントに、登録されているクライアントアドレス情報を一括して通知し、あらたにクライアントアドレス情報が登録された場合には、クライアントアドレス情報の差分情報のみを登録済みのクライアントへ通知し、
クライアント側では、クライアントアドレス情報または差分情報を取得し、前記クライアントアドレス情報のアドレス解決処理を行って、現行系サーバとの通信が不可能になったときに、クライアント同士で通信を行うことを特徴とするＶｏＩＰ通信方法。
【０１１０】
【発明の効果】
以上説明したように、本発明の通信システムは、クライアント装置から、現行系のサーバ装置及びバックアップサーバ装置へ、クライアントアドレス情報を同時に登録通知し、サーバ装置から、またはサーバ装置との通信が不可能になったときはバックアップサーバ装置から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う構成とした。これにより、現行系からバックアップ用のサーバへ切り替わる際のブランクをなくすことができるので、通信品質の向上を図ることが可能になる。
【図面の簡単な説明】
【図１】 通信システムの原理図である。
【図２】 primary GKの構成を示す図である。
【図３】 alternate GKの構成を示す図である。
【図４】ＲＡＳシグナリングを示すシーケンス図である。
【図５】 primary GKが管理するクライアントアドレス情報テーブルを示す図である。
【図６】 alternate GKが管理するクライアントアドレス情報テーブルを示す図である。
【図７】 alternate GKがバックアップを開始した際のクライアントアドレス情報テーブルを示す図である。
【図８】第２の実施の形態のＲＡＳシグナリングを示すシーケンス図である。
【図９】複数のalternate GKが配置されたシステムの構成を示す図である。
【図１０】複数のalternate GKによりバックアップを行う際の様子を示す図である。
【図１１】第４の実施の形態の通信システムの構成を示す図である。
【図１２】第４の実施の形態におけるクライアントアドレス情報の通知手順を示すシーケンス図である。
【図１３】ＥＰの登録によりＧＫでアドレス解決が行われるまでの処理手順を示すフローチャートである。
【図１４】ＥＰの登録によりＧＫでアドレス解決が行われるまでの処理手順を示すフローチャートである。
【図１５】ＥＰの機能ブロックを示す図である。
【図１６】ＶｏＩＰシステムの構成を示す図である。
【図１７】従来のalternate GKへの登録の様子を示す図である。
【符号の説明】
１ 通信システム
１０ サーバ装置
２０ バックアップサーバ装置
３０−１〜３０−ｎ クライアント装置
３１ バックアップサーバ検出部
３２ クライアントアドレス情報登録通知部
３３ 通信制御部
【発明の属する技術分野】
本発明は通信システムに関し、特にＶｏＩＰ（voice over Internet Protocol）の通信を行う通信システムに関する。
【０００２】
【従来の技術】
近年、インターネットの台頭により、急速にネットワークやアプリケーションのＩＰ化が進展し、データのみならず、音声についてもＩＰ化して、ＩＰネットワークに統合しようという動きが強まっている。ＩＰネットワーク上に音声（voice）を通すための技術は、ＶｏＩＰと呼ばれる。
【０００３】
ＶｏＩＰシステムを導入する際には、従来の電話網相当の品質や信頼性（可用性）などが要求される。このようなニーズを解決するために、ＶｏＩＰシステムを実現するための基本部分や付加サービスなどに関して、ＩＴＵ−Ｔ（International Telecommunication Union−Telecommunication Standardization Sector）のＨ．３２３やＩＥＴＦ（Internet Engineering Task Force）のＳＩＰ（Session Initiation Protocol）において、標準化へ向けての検討が行われている。
【０００４】
図１６はＶｏＩＰシステムの構成を示す図である。図は、Ｈ．３２３システムで、バックアップ用ＶｏＩＰサーバが存在する場合の構成を示している。ＶｏＩＰシステム１００は、ＩＰネットワーク１００ａ上で（社内であればＬＡＮ）、サーバ機能を有するprimary GK（Gatekeeper）１０１及びalternate GK１０２と、クライアント機能を有するＥＰ（EndPoint）１０３−１〜１０３−ｎとから構成される。なお、primary GK１０１は、現行系のＶｏＩＰサーバであり、alternate GK１０２は、バックアップ用のＶｏＩＰサーバである。
【０００５】
ＶｏＩＰシステム１００で、例えば、ＥＰ１０３−１を持つユーザＡが、ＥＰ１０３−２を持つユーザＢに電話をする場合、まずＥＰ１０３−１は、ＥＰ１０３−２の電話番号をprimary GK１０１へ送信する。
【０００６】
すると、ＥＰ１０３−１〜１０３−ｎの電話番号を一元管理しているprimary GK１０１では、アドレス解決処理を行って、受信した電話番号に対応するＥＰ１０３−２のＩＰアドレスを求め、このＩＰアドレスをＥＰ１０３−１へ送信する。
【０００７】
これにより、ＥＰ１０３−１は、相手先をＥＰ１０３−２と認識し、ＥＰ１０３−１、１０３−２間での音声通信が実行される（ＥＰ間の音声通信実行時には、ＶｏＩＰサーバは介さない）。また、primary GK１０１に障害が発生すると、上述のようなアドレス解決処理ができなくなるので、通常はバックアップ用のalternate GK１０２が配置される。
【０００８】
このようなＶｏＩＰシステム１００に対して、ＥＰ１０３−１〜１０３−ｎが、primary GK１０１に自アドレス情報を登録する場合、登録手順（Ｈ．２２５．０のＲＡＳ（Registration Admission and Status）に規定されている）の中で、primary GK１０１からＥＰ１０３−１〜１０３−ｎへ、バックアップ用のalternate GK１０２が存在することが通知される。
【０００９】
具体的には、primary GK１０１は、自アドレス情報を登録してきたＥＰ１０３−１〜１０３−ｎにalternate GKのリストを“AlternateGK”として通知する。
ＥＰ１０３−１〜１０３−ｎは、primary GK１０１から受信した“AlternateGK”を解釈することによって、alternate GK１０２の存在（alternate GKが複数ある場合には、その優先順位も含まれる）を知ることができる。
【００１０】
【発明が解決しようとする課題】
しかし、上記のような従来のＶｏＩＰシステム１００に対し、ＥＰ１０３−１〜１０３−ｎがバックアップ用のalternate GK１０２へ接続する場合、primary GK１０１への登録が失敗したとき、または登録は成功したがその後の応答がなくなったときに（primary GK１０１の故障も含め）、ＥＰ１０３−１〜１０３−ｎは、初めてalternate GK１０２に対して登録することが規定されている。
【００１１】
図１７は従来のalternate GK１０２への登録の様子を示す図である。ＶｏＩＰシステム１００で、primary GK１０１とＥＰ１０３−１〜１０３−ｎとの通信が不可能になったときに、ＥＰ１０３−１〜１０３−ｎは、alternate GK１０２に対して登録する。
【００１２】
この規定に従うと、primary GK１０１からalternate GK１０２への切り替えの際、通話発信元のＥＰがalternate GK１０２への登録を先に終了し、着信先のＥＰがalternate GK１０２への登録を終了していないといった状態が発生する可能性があり、この場合には、音声通信を実行することができない。
【００１３】
すなわち、従来のalternate GKへの登録規定では、現行系のprimary GKからバックアップ用のalternate GKに切り替わる際に、通信不可能な時間帯が発生する場合があり、通信品質の悪化を引き起こすといった問題があった。
【００１４】
このような問題点に対して、解決案として、primary GKが保持しているアドレス情報をalternate GKに転送するという方法があるが、現在の勧告ではＧＫ間でアドレス情報を転送する手段については規定されていない。したがって、この方法では独自の方式となるために、異なるベンダ間での相互接続性を確保できなくなる。
【００１５】
さらに、alternate GKが最新のアドレス情報を持つためには、定期的な更新が必要となる。特にprimary GKとalternate GKが地理的に離れており、ＷＡＮ（Wide Area Network）を介しての接続となる場合には、定期更新のためのあらたな帯域を持たなければならない。
【００１６】
本発明はこのような点に鑑みてなされたものであり、現行系のＶｏＩＰサーバからバックアップ用のＶｏＩＰサーバへ切り替わる際のブランクをなくし、通信品質の向上を図った通信システムを提供することを目的とする。
【００１７】
【課題を解決するための手段】
本発明では上記課題を解決するために、図１に示すような、ＶｏＩＰの通信を行う通信システム１において、クライアントアドレス情報の一元管理を行うサーバ装置１０と、サーバ装置１０のバックアップを行うバックアップサーバ装置２０と、現行系のサーバ装置１０及びバックアップサーバ装置２０へ、クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部３２と、サーバ装置１０から、またはサーバ装置１０との通信が不可能になったときはバックアップサーバ装置２０から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部３３と、から構成されるクライアント装置３０と、を有することを特徴とする通信システム１が提供される。
【００１８】
ここで、サーバ装置１０は、クライアントアドレス情報の一元管理を行う。バックアップサーバ装置２０は、サーバ装置１０のバックアップを行う。クライアントアドレス情報登録通知部３２は、現行系のサーバ装置１０及びバックアップサーバ装置２０へ、クライアントアドレス情報を同時に登録通知する。通信制御部３３は、サーバ装置１０から、またはサーバ装置１０との通信が不可能になったときはバックアップサーバ装置２０から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う。また、クライアントアドレス情報登録通知部３２は、バックアップサーバ装置２０が複数台ある場合、クライアント装置３０とサーバ装置１０との通信が不可能になったとき、またはクライアント装置３０とクライアントアドレス情報を登録したバックアップサーバ装置２０との通信が不可能になったときに、クライアントアドレス情報が登録済みでないバックアップサーバ装置２０に対して、１台毎にクライアントアドレス情報を登録通知する。
【００１９】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して説明する。図１は通信システムの原理図である。通信システム１は、サーバ装置１０、バックアップサーバ装置２０、エンドポイントであるクライアント装置（以下、ＥＰ）３０−１〜３０−ｎを有して冗長系構成（サーバ装置１０及びバックアップサーバ装置２０の複数サーバを持つ）をとり、ネットワーク４（ＩＰネットワークやＬＡＮ等）上でＶｏＩＰ通信を行う。
【００２０】
現行系ゲートキーパであるサーバ装置（以下、primary GK）１０は、ＥＰ３０−１〜３０−ｎのクライアントアドレス情報の一元管理を行い、通常時には、ＥＰ３０−１〜３０−ｎとクライアント・サーバ通信を行う。
【００２１】
バックアップゲートキーパであるバックアップサーバ装置（以下、alternate GK）２０は、primary GK１０のバックアップを行う。alternate GK２０は、primary GK１０とＥＰ３０−１〜３０−ｎ間で通信が不可能になったときに、primary GK１０の代わりにクライアントアドレス情報を管理して、ＥＰ３０−１〜３０−ｎ間で通信を行うサーバである。なお、primary GK１０とalternate GK２０を総称する場合には、以降では単にＧＫと呼ぶ。
【００２２】
ＥＰ３０−１〜３０−ｎ（総称する場合はＥＰ３０）は、ネットワーク４との接続機能及び電話機能（または電話との接続機能）を有する、Ｈ．３２３システムにおけるクライアント機能を提供する端末装置に該当し、バックアップサーバ検出部３１、クライアントアドレス情報登録通知部３２、通信制御部３３から構成される。
【００２３】
バックアップサーバ検出部３１は、primary GK１０から送信されたalternate GK２０の存在を示す存在情報を受信して、alternate GK２０の検出を行う。
クライアントアドレス情報登録通知部３２は、primary GK１０と、検出したalternate GK２０へ、クライアントアドレス情報を同時に（例えば、システム起動時に）登録通知する。クライアントアドレス情報とは、ＥＰ３０に関する、電話番号、ＩＰアドレス、ユーザ名等のアドレス情報のことである。
【００２４】
通信制御部３３は、通常時はprimary GK１０から、またprimary GK１０との通信が不可能になったときはalternate GK２０から送信された、ＥＰ間で音声通信を行う際の着信先のＩＰアドレスを受信する。さらに、primary GK１０またはalternate GK２０から設定された伝送帯域の確保を行う。
【００２５】
ここで、従来では、primary GK１０とＥＰ３０との通信が不可能になったときに初めて、ＥＰ３０は、alternate GK２０に対してクライアントアドレス情報を登録していたが、本構成では、クライアントアドレス情報をprimary GK１０とalternate GK２０へ同時に登録通知することにした。これにより、ＥＰ３０とprimary GK１０との通信が不可能になった場合に、即時にalternate GK２０との通信を開始できるので、ＥＰ間の音声通信を瞬断なく継続実行することが可能になる。
【００２６】
次にprimary GK１０とalternate GK２０の構成について説明する。図２はprimary GK１０の構成を示す図である。primary GK１０は、存在情報通知部１１、現行系クライアントアドレス情報登録部１２、現行系通信設定部１３、現行系登録保持設定部１４から構成される。
【００２７】
存在情報通知部１１は、ＥＰ３０へ、alternate GK２０の存在を示す存在情報の通知を行う。また、alternate GK２０が複数台ある場合には、ＥＰ３０との通信が不可能になったときに、alternate GK２０に対する負荷を分散させるために、存在情報の内容をＥＰ３０によって変更して通知する（図９、１０で後述）。
【００２８】
現行系クライアントアドレス情報登録部１２は、ＥＰ３０から送信されたクライアントアドレス情報を登録する。現行系通信設定部１３は、クライアントアドレス情報のアドレス解決処理を行って、通話着信先のＥＰのＩＰアドレスを求め、発信元のＥＰ３０へ送信する。また、発信元のＥＰ３０に対して伝送帯域を設定する。
【００２９】
現行系登録保持設定部１４は、クライアントアドレス情報の登録を保持するための登録保持メッセージをＥＰ３０へ送信する。なお、登録保持メッセージに関する処理については図５〜図７で後述する。
【００３０】
図３はalternate GK２０の構成を示す図である。alternate GK２０は、バックアップ用クライアントアドレス情報登録部２２、バックアップ用通信設定部２３、バックアップ用登録保持設定部２４から構成される。
【００３１】
バックアップ用クライアントアドレス情報登録部２２は、ＥＰ３０から送信されたクライアントアドレス情報を登録する。バックアップ用通信設定部２３は、バックアップを行う場合、クライアントアドレス情報のアドレス解決処理を行って、通話着信先のＥＰのＩＰアドレスを求め、発信元のＥＰ３０へ送信する。また、ＥＰ３０に対して伝送帯域を設定する。
【００３２】
バックアップ用登録保持設定部２４は、バックアップを開始しない場合には、クライアントアドレス情報の登録を保持するための登録保持メッセージの送信間隔を、primary GK１０での登録保持メッセージの送信間隔よりも長く設定してＥＰ３０へ送信する。また、バックアップを開始した場合には、この送信間隔を短く設定して送信する。図５〜図７で後述する。
【００３３】
次に通信システム１の動作について詳しく説明する（第１の実施の形態とする）。図４はＲＡＳシグナリングを示すシーケンス図である。ＲＡＳは、ＥＰ３０が、ＧＫにクライアントアドレス情報を登録する際のシグナリング手順である。
【００３４】
図中のGK discoveryとは、ＥＰ３０がＧＫを動的に発見するための手順（オプション）である。通常、ＥＰ３０からはマルチキャストでＧＫを検出するためのメッセージが送信される。そして、そのメッセージに対して、同一ゾーン（ＧＫが管理対象とするＥＰの範囲）内のＧＫが応答する。ＥＰ３０は、この応答メッセージにてalternate GK（及び primary GK ）の存在を知ることができる。
【００３５】
EP registration処理とは、ＥＰ３０のエイリアスアドレス（電話番号やユーザ名等）やＩＰアドレスがマッピングされたクライアントアドレス情報を登録するための手順である。
【００３６】
なお、ＧＫ側では、この手順で得た管理対象のＥＰ３０のクライアントアドレス情報を内部テーブルに保持する。そして、Admission/bandwidth controlによるアドレス解決要求を受け付けた際に、エイリアスアドレスをキーとしたＩＰアドレスの解決を行う。Admission/bandwidth control処理とは、アドレス解決によりＩＰアドレスを求め、音声伝送に必要な帯域の割当てを行うための手順である。
〔Ｓ１〕ＥＰ３０のバックアップサーバ検出部３１は、GRQ（Gatekeeper Request）メッセージをマルチキャスト等によって送信する。GRQメッセージには、ＥＰ３０がalternate GK２０をサポートすることを意味する“supportsAltGK”を含んでおく（なお、本構成は、ＥＰ３０のみが意識して動作すればよいため、ＧＫに対して本構成の機能の存在を通知する必要はない）。
【００３７】
そして、ゾーン内のprimary GK１０の存在情報通知部１１は、GCF（Gatekeeper Confirm）メッセージで応答する。GCFメッセージには、alternate GK２０が存在する場合、そのalternate GK２０のトランスポートアドレス（ＩＰアドレス、ポート番号）が“AlternateGK”に含まれる。これにより、バックアップサーバ検出部３１は、alternate GK２０の存在を知ることができる。
【００３８】
なお、ＧＫ自身がprimaryなのか、alternateなのかは、事前にＧＫに設定しておくか、ＧＫ間で独自に情報（ＩＰアドレス、ＭＡＣアドレス等）を交換し、その値の大小によって自分がprimaryなのかalternateかを判断するように設定する。また、ステップＳ１の手順は、ＥＰ３０にとってオプションであり、ＥＰ３０に静的にＧＫのアドレス情報を設定しておけば、この手順を省略することができる。
〔Ｓ２ａ〕ＥＰ３０のクライアントアドレス情報登録通知部３２は、primary GK１０にRRQ（Registration Request）メッセージを送信して、自身のクライアントアドレス情報をprimary GK１０に通知する。このメッセージをprimary GK１０の現行系クライアントアドレス情報登録部１２が受け入れた場合は、RCF（Registration Confirm）メッセージで応答する。
〔Ｓ２ｂ〕クライアントアドレス情報登録通知部３２は、primary GK１０への登録動作と同様にして、Admission/bandwidth controlに移行する前に、alternate GK２０に対しても、RRQメッセージを送信する。そして、alternate GK２０に受け入れられた場合には、RCFメッセージによる応答を受ける。なお、この処理は、primary GK１０のゾーン内の全ＥＰが実行する。
〔Ｓ３〕ＥＰ３０の通信制御部３３は、ARQ（Address Request）メッセージをprimary GK１０へ送信する。primary GK１０の現行系通信設定部１３は、ARQメッセージを受信すると、内部テーブルにもとづき、アドレス解決を行って着信先ＥＰのＩＰアドレスを求め、かつ音声伝送に必要な帯域の設定を行う。
【００３９】
そして、現行系通信設定部１３は、ＩＰアドレスと帯域設定情報をACF（Address Confirm）メッセージに含めてＥＰ３０へ送信する。ＥＰ３０の通信制御部３３は、受信したACFメッセージにより、着信先のＩＰアドレスを認識し、かつ伝送帯域を確保する。
【００４０】
以上説明したような、ステップＳ１〜ステップＳ３による処理を行うことで、primary GK１０とalternate GK２０は同じクライアントアドレス情報を保持することができ、ＥＰ３０がprimary GK１０との通信が不可能になった場合には、即時にalternate GK２０との通信を開始して、ＥＰ間の音声通信を継続することができる。
【００４１】
なお、上記のシーケンス処理の中で拒絶される場合のメッセージは、GCFの代わりにGRJ（Gatekeeper Reject）、RCFの代わりにRRJ（Registration Reject）、ACFの代わりにARJ（Address Reject）となる。
【００４２】
ここで、primary GK１０が復旧したときの自動復帰については、通信不可能となったprimary GK１０に対して、ＥＰ３０のクライアントアドレス情報登録通知部３２は、RRQメッセージを定期的に送信し続け（ただし、トラフィック量や負荷を抑えるために、RRQメッセージの送信間隔は長く設定する）、RCFメッセージを受信した時点で復旧したと判断する。その後、alternate GK２０から、復旧したprimary GK１０へ接続が切り替わり、ＥＰ３０とprimary GK１０との通信が再開する。
【００４３】
次にＧＫで管理されるクライアントアドレス情報テーブル及び登録保持メッセージについて説明する。primary GK１０とalternate GK２０は、ＥＰ３０から送信されたクライアントアドレス情報をもとに、クライアントアドレス情報テーブルを作成する。
【００４４】
また、primary GK１０の現行系登録保持設定部１４及びalternate GK２０のバックアップ用登録保持設定部２４では、ＥＰ３０による登録を保持するために（ＥＰ３０が正常に動作しているか否かを判断するために）、ＥＰ３０に対して登録保持メッセージ（以下、KeepAlive）を送信する。
【００４５】
このとき、primary GK１０がＥＰ３０に通知するKeepAliveの送信間隔（以下timeToLive）よりも、alternate GK２０が通知するKeepAliveのtimeToLiveの方を長く設定する。
【００４６】
図５はprimary GK１０が管理するクライアントアドレス情報テーブルを示す図である。クライアントアドレス情報テーブルＴ１は、ＥＰ３０のＩＤを示すＥＰ##ＩＤ、そのＩＤに対応するＥＰのトランスポートアドレス（図ではＩＰアドレスが記されている）、エイリアスアドレス（図では電話番号が記されている）及び時刻情報の項目から構成される。
【００４７】
時刻情報とは、KeepAliveを送信する時刻（内部クロックにもとづく）のことであり、内部時刻＋timeToLiveで管理される。内部時刻とは、１つ前に送信したKeepAliveの送信済み時刻のことである。時刻情報の例として、内部時刻＋timeToLive＝10:48:29＋60sとは、１つ前に送信したKeepAliveの送信時刻は10:48:29であり、次のKeepAliveの送信時刻は10:49:29（＝10:48:29＋60s）ということである。
【００４８】
図６はalternate GK２０が管理するクライアントアドレス情報テーブルを示す図である。クライアントアドレス情報テーブルＴ２の各項目は、図５の場合と同様である。ただし、時刻情報のtimeToLiveが60sから3600sと長く設定されている。
【００４９】
このように、バックアップ用登録保持設定部２４が送信するKeepAliveのtimeToLiveは、現行系登録保持設定部１４が送信するKeepAliveのtimeToLiveよりも長く設定しておくことで、トラフィック量や負荷の増大を抑制することができる。
【００５０】
図７はalternate GK２０がバックアップを開始した際のクライアントアドレス情報テーブルを示す図である。ＥＰ３０とprimary GK１０との通信が不可能になり、alternate GK２０がバックアップを開始した場合には、バックアップ用登録保持設定部２４は、長く設定していたtimeToLiveを短く設定する。
【００５１】
クライアントアドレス情報テーブルＴ２ａは、上述した項目の他に、あらたに呼受付状態の項目が追加される。alternate GK２０がバックアップ開始後に、該当のＥＰからARQメッセージを受信した場合には、呼受付状態はActiveとなり、ARQメッセージを受信しない場合は、Passiveとなる。
【００５２】
そして、呼受付状態がActiveのＥＰに対しては、そのＥＰに対してバックアップ動作を開始したことになるので、KeepAliveのtimeToLiveを短く設定する。また、呼受付状態がPassiveのＥＰに対しては、そのＥＰに対してはバックアップ動作はまだ開始していないので、KeepAliveのtimeToLiveは変更せずに、図６で設定した値にしておく。
【００５３】
図では、ＥＰ＿ＩＤ＝０００１、０００３のＥＰは、Activeであるから、時刻情報をそれぞれ10:48:29＋3600s→10:48:29＋60s、11:03:53＋3600s→11:03:53＋60sに切り替え、ＥＰ＿ＩＤ＝０００２はPassiveであるから、10:55:32＋3600sのままとする。
【００５４】
次に第２の実施の形態について説明する。第１の実施の形態では、alternate GKが１台の場合であるが、より強固なシステムを構築するためにalternate GKを２台以上設置することも考えられる。
【００５５】
この場合、ＥＰ３０がすべてのalternate GKに対して、ＲＡＳチャネル（ＥＰとＧＫ間でＲＡＳ手順を実行するためのチャネル）を設定してしまうと、ＥＰが保持するＲＡＳチャネル数が増えてしまい、トラフィックの増加及びＥＰ３０に対する負荷が過大になってしまう。
【００５６】
したがって、第２の実施の形態では alternate GKが２台以上存在する場合、ＥＰ３０とprimary GK１０との通信が不可能になったとき、または、ＥＰ３０とバックアップを開始したalternate GKとの通信が不可能になったときに、クライアントアドレス情報が登録済みでないalternate GKに対して、１台毎にクライアントアドレス情報を登録通知するものである。図８を用いてこの様子を説明する。
【００５７】
図８は第２の実施の形態のＲＡＳシグナリングを示すシーケンス図である。Alternate GK２０−１、２０−２の２台の場合における処理を示す。
〔Ｓ１１〕ＥＰ３０とprimary GK１０間で、GK discovery処理としてGRQ／GCFメッセージの通信を行う。
〔Ｓ１２〕ＥＰ３０とprimary GK１０間で、EP registration処理としてRRQ／RCFメッセージの通信を行う。
〔Ｓ１３〕ＥＰ３０とalternate GK２０−１間で、EP registration処理としてRRQ／RCFメッセージの通信を行う。
〔Ｓ１４〕ＥＰ３０とprimary GK１０間で、Admission/bandwidth control処理としてARQ／ACFメッセージの通信を行う。
〔Ｓ１５〕ＥＰ３０とprimary GK１０との通信が不可能になったとする。
〔Ｓ１６〕ＥＰ３０とalternate GK２０−２間で、EP registration処理としてRRQ／RCFメッセージの通信を行う。
〔Ｓ１７〕ＥＰ３０とalternate GK２０−１間で、Admission/bandwidth control処理としてARQ／ACFメッセージの通信を行う。
【００５８】
すなわち、複数台のalternate GKを第１〜第ｎのalternate GKとすると、ＥＰ３０とprimary GK１０との通信が不可能になった時点で、第２のalternate GKにクライアントアドレス情報を登録通知し、第１のalternate GKとの通信が不可能になった時点で、第３のalternate GKにクライアントアドレス情報を登録通知する、というように常に２本のＲＡＳチャネルを保持するようにする。
【００５９】
なお、この場合、ＥＰ３０は、ＲＣＦメッセージに含まれる“AlternateGK”によって、alternate GKの存在だけでなくプライオリティも知ることができるので、優先度の高い順に２つのＲＡＳチャネルを保持するようにしてもよい。
【００６０】
次に第３の実施の形態について説明する。第３の実施の形態では、alternate GKが複数台ある場合、alternate GKの存在を示す“AlternateGK”の内容を、ＥＰ３０によって変更して通知し、alternate GKに対する負荷を分散させるものである。
【００６１】
図９は複数のalternate GKが配置されたシステムの構成を示す図である。ＶｏＩＰシステム１ａに対し、センター拠点（本社）５は、primary GK５１、ＥＰ５２−１〜５２−３、ルータ５３を有し、バス配線によってそれぞれ接続する。リモート拠点（支店）６は、alternate GK６１、ＥＰ６２−１〜６２−３、ルータ６３を有し、バス配線によってそれぞれ接続する。リモート拠点（支店）７は、alternate GK７１、ＥＰ７２−１〜７２−３、ルータ７３を有し、バス配線によってそれぞれ接続する。
【００６２】
また、ルータ５３は、アクセス回線Ｃ１（３Ｍｂｐｓ）でＩＰ−ＶＰＮ（Virtual Private Network）４ａと接続し、ルータ６３は、アクセス回線Ｃ２（１．５Ｍｂｐｓ）でＩＰ−ＶＰＮ４ａと接続し、ルータ７３は、アクセス回線Ｃ３（１．５Ｍｂｐｓ）でＩＰ−ＶＰＮ４ａと接続する。
【００６３】
このような構成のＶｏＩＰシステム１ａに対し、通常時では、図中の点線枠で示すゾーン内で、primary GK５１をサーバとしたＶｏＩＰ通信が行われる。ところが、センター拠点（本社）５に設置されたprimary GK５１が故障した場合、例えば、alternate GK６１のみがバックアップを開始したとすると、アクセス回線の速度が遅いリモート拠点（支店）６のalternate GK６１に対して、すべてのＥＰがアクセスを実行するため、レスポンスが悪くなるといった問題が発生する。
【００６４】
図１０は複数のalternate GKによりバックアップを行う際の様子を示す図である。ＶｏＩＰシステム１ａに対し、primary GK５１が故障した場合、第３の実施の形態では、alternate GK６１、７１の両方でバックアップを開始する。図では、alternate GK６１は、ゾーンｚ１として、ＥＰ５２−２、５２−３、ＥＰ６２−１〜ＥＰ６２−３をカバーし、alternate GK７１はゾーンｚ２として、ＥＰ５２−１、ＥＰ７２−１〜ＥＰ７２−３をカバーする。
【００６５】
すなわち、システム起動時に、primary GK５１は、ＥＰ５２−２、５２−３、ＥＰ６２−１〜ＥＰ６２−３に対してはバックアップ用サーバとしてalternate GK６１の存在を通知し、ＥＰ５２−１、ＥＰ７２−１〜ＥＰ７２−３に対してはバックアップ用サーバとしてalternate GK７１の存在を通知しておく。
【００６６】
これにより、primary GK５１との通信が不可能になった場合に、alternate GK６１はＥＰ５２−２、５２−３、ＥＰ６２−１〜ＥＰ６２−３をバックアップし、alternate GK７１はＥＰ５２−１、ＥＰ７２−１〜ＥＰ７２−３をバックアップするので、負荷が分散され、レスポンス悪化を抑制することが可能になる。
【００６７】
ここで、上述したＶｏＩＰシステム１ａのように、企業などにおいてalternate GKを設置する場合、自然災害などの影響を考慮して地理的に離れている拠点にalternate GKを設置することが考えられる。
【００６８】
企業の通信形態として、ホストコンピュータを設置しているセンター拠点にprimary GKを設置し、そのホストコンピュータにアクセスする端末が設置されているリモート拠点にalternate GKを設置する場合が多い。ところが、このようなシステムでは、primary GKからalternate GKに切り替わるとレスポンスが悪くなる可能性が高い。
【００６９】
したがって、第３の実施の形態では、primary GKがＥＰに通知する “AlternateGK”の内容をＥＰによって変更する（すなわち、alternate GKの規模やその拠点のアクセス回線速度によって、ゾーンの範囲を変更する）ことによって、primary GKのバックアップを複数のalternate GKで実現する。
【００７０】
これにより、alternate GKが管理するゾーンの範囲を小さくできるので、アクセス回線速度がボトルネックになって生じるレスポンスの悪化を抑制することが可能になる。または逆に、primary GKを複数で運用し、１台のalternate GKでバックアップすることも可能である。
【００７１】
次に第４の実施の形態について説明する。第１〜第３の実施の形態は、alternate GKを設置することを前提としているが、第４の実施の形態では、alternate GKを設置せずに、primary GKに登録された最新のアドレス情報をＥＰが保持することによって、primary GKとの通信が不可能になった場合に、ＥＰ内部でアドレス解決を行ない、ＥＰ間の通信を実現するものである。
【００７２】
図１１は第４の実施の形態の通信システムの構成を示す図である。通信システム１ｂは、ＥＰ３０ｂとprimary GK１０ｂから構成される。
ＥＰ３０ｂに対し、クライアントアドレス情報取得部３０ｂ−１は、クライアントアドレス情報または差分情報（ＥＰが追加または削除した際の変更情報）を取得する。通信部３０ｂ−２は、クライアントアドレス情報のアドレス解決処理を行い、現行系サーバとの通信が不可能になったときに、クライアント同士で通信を行う。
【００７３】
primary GK１０ｂに対し、クライアントアドレス情報通知部１０ｂ−１は、登録要求のあったＥＰに、登録されているクライアントアドレス情報を一括して通知する。差分情報通知部１０ｂ−２は、あらたにクライアントアドレス情報が登録された場合は、クライアントアドレス情報の差分情報のみを登録済みのＥＰへ通知する。
【００７４】
図１２は第４の実施の形態におけるクライアントアドレス情報の通知手順を示すシーケンス図である。
〔Ｓ２１〕ＥＰ３０ｂ−ａとprimary GK１０ｂ間で、RRQ／RCFメッセージの通信を行う。
〔Ｓ２２〕primary GK１０ｂのクライアントアドレス情報通知部１０ｂ−１は、システム起動時から一定時間（図では３６００秒）経過後に、登録済みのクライアントアドレス情報をＥＰ３０ｂ−ａへ一括して送信する。ＥＰ３０ｂ−ａのクライアントアドレス情報取得部３０ｂ−ａは、クライアントアドレス情報を一括して取得する。
〔Ｓ２３〕ＥＰ３０ｂ−ｂとprimary GK１０ｂ間で、RRQ／RCFメッセージの通信を行う（あらたにＥＰ３０ｂ−ｂが登録要求をしてきた状態）。
〔Ｓ２４ａ〕primary GK１０ｂの差分情報通知部１０ｂ−２は、あらたにクライアントアドレス情報が登録されたので、このクライアントアドレス情報（差分情報）のみを、すでに登録済みのＥＰ３０ｂ−ａへ通知する。
〔Ｓ２４ｂ〕primary GK１０ｂのクライアントアドレス情報通知部１０ｂ−１は、クライアントアドレス情報を一括してＥＰ３０ｂ−ｂへ通知する。
〔Ｓ２５〕ＥＰ３０ｂ−ｂとprimary GK１０ｂ間で、RRQ／RCFメッセージの通信を行う（あらたにＥＰ３０ｂ−ｃが登録要求をしてきた状態）。
〔Ｓ２６ａ〕primary GK１０ｂの差分情報通知部１０ｂ−２は、あらたにクライアントアドレス情報が登録されたので、このクライアントアドレス情報（差分情報）のみを、登録済みのＥＰ３０ｂ−ａ、３０ｂ−ｂへ通知する。
〔Ｓ２６ｂ〕primary GK１０ｂのクライアントアドレス情報通知部１０ｂ−１は、クライアントアドレス情報を一括してＥＰ３０ｂ−ｃへ通知する。
【００７５】
このように、第４の実施の形態では、primary GKに登録された最新のアドレス情報をＥＰが保持するために、ＥＰとprimary GK間で定期的に通信を行う。ただし、頻繁に大量のクライアントアドレス情報をやりとりするのは負荷増大に繋がるため、必要最小限に抑える必要がある。
【００７６】
このためには、例えば、primary GKに電源が投入されて一定時間経過した後に、その時点でprimary GKが保持しているクライアントアドレス情報を登録された全てのＥＰに一括送信する。その後、primary GKが保持しているクライアントアドレス情報が変更された時点でＥＰにその変更分だけを通知すればよい。
【００７７】
なお、クライアントアドレス情報の通知は、独自の手順で行なっても良いし、標準で定義されているＲＡＳメッセージの拡張（例えば、RCFメッセージにprimary GKが保有するクライアントアドレス情報を含ませて、ＥＰに通知する）によって実現することもできる。
【００７８】
次にＥＰの登録によりＧＫでアドレス解決が行われるまでの流れについてフローチャートを用いて説明する。図１３、図１４はＥＰの登録によりＧＫでアドレス解決が行われるまでの処理手順を示すフローチャートである。
〔Ｓ３１〕ＥＰは、登録時に、primary GKから送信されたRCFメッセージを受信し、RCFメッセージ内にalternate GKの存在を示す“AlternateGK”があるか否かを判断する。なければステップＳ３２へ、あればステップＳ３７へ行く。
〔Ｓ３２〕ＥＰは、一定時間経過後に、クライアントアドレス情報をprimary GKから一括して受信する。
〔Ｓ３３〕システムに対して、ＥＰの追加／削除があった場合は、ステップＳ３４へ行き、なければこの判断処理を繰り返す。
〔Ｓ３４〕すでに登録済みのＥＰは差分情報を受信し、あらたに登録したＥＰはクライアントアドレス情報を一括して受信する。
〔Ｓ３５〕ＥＰとprimary GKとの通信が不可能になった場合は、ステップＳ３６へ、そうでなければステップＳ３３へ戻る。
〔Ｓ３６〕ＥＰ内部でアドレス解決処理を行う。
〔Ｓ３７〕ＥＰは、第１のalternate GKに登録を行う。
〔Ｓ３８〕ＥＰとprimary GKとの通信が不可能になった場合は、ステップＳ３９へ、そうでなければこの判断処理を繰り返す。
〔Ｓ３９〕ＥＰは、第２のalternate GKに登録を行う。
〔Ｓ４０〕ＥＰは、通信不可能となったＧＫにRRQメッセージを定期的に送信する。
〔Ｓ４１〕RRCメッセージを返信したＧＫによってアドレス解決処理が行われる。
【００７９】
次にＥＰ３０の機能ブロックについて説明する。図１５はＥＰ３０の機能ブロックを示す図である。画像コーデック(Ｈ．２６１，Ｈ．２６３)３ａは、画像信号の符号化／復号化を行う。音声コーデック(Ｇ７００シリーズ，特にＧ．７１０−７２９)３ｂは、音声信号の符号化／復号化を行う。
【００８０】
システムコントロールユニット３ｃは、メディア制御部（Ｈ．２４５）３ｃ−１は、呼制御部（Ｈ．２２５．０）３ｃ−２、ＲＡＳ制御部（Ｈ．２２５．０）３ｃ−３から構成される。
【００８１】
メディア制御部（Ｈ．２４５）３ｃ−１は、ＥＰ間の主従関係、使用するコーデックなどの能力交換機能を提供するとともに、音声、画像及びデータを送受信するための論理チャネル（Logical Channel）ＣＨ１をＵＤＰ（User Datagram Protocol）上に設定する。論理チャネルＣＨ１を設定するためのＥＰ間でのやりとりは、ＴＣＰ（Transport Control Protocol）上のＨ．２４５コントロールチャネル（Control Channel）ＣＨ２を使って行う。
【００８２】
呼制御部（Ｈ．２２５．０）３ｃ−２は、ＥＰ間で通話を開始するために必要な情報（電話番号等）の交換を行う。この情報は、ＥＰ間に設定されたＴＣＰ上の呼シグナリングチャネル（Call Signaling Channel）ＣＨ３で送受信する。
【００８３】
ＲＡＳ制御部（Ｈ．２２５．０）３ｃ−３は、ＥＰがＧＫに対して、電話番号等のアドレス情報の登録、アドレス解決などを行う機能を提供する。これらのやりとりは、ＥＰとＧＫ間で、ＵＤＰ上のＲＡＳチャネル（RAS Channel）ＣＨ４を使って行う。また、ＥＰ３０の機能ブロックは、ＲＡＳ制御部３ｃ−３に含まれる。
【００８４】
ＲＴＰ（Real-Time Transport Control Protocol）／ＲＴＣＰ制御部３ｄは、符号化された音声や画像を送受信するために、ＩＰパケットにカプセリングする機能やそのＩＰパケットを制御（モニタ等）する機能を提供する。
【００８５】
ネットワークインタフェースカード（ＮＩＣ）３ｅは、ＬＡＮなどのネットワークに接続するためのデータリンクレイヤ及び物理レイヤ機能を提供する。
以上説明したように、 alternate GK２０への切り替えを瞬時に行うことができるため、エンドユーザにとっては、ＧＫの障害を意識することなく、高い可用性のもとで音声通信を行うことが可能になる。
【００８６】
なお、ＶｏＩＰ製品は、現在ではＨ．３２３対応製品が多く出荷されているために、上記の説明では、Ｈ．３２３をベースにして行ったが、これから製品化が始まる予定であるＳＩＰのクライアント・サーバシステムにも本発明を適用可能である。
【００８７】
（付記１） ＶｏＩＰの通信を行う通信システムにおいて、
クライアントアドレス情報の一元管理を行うサーバ装置と、
前記サーバ装置のバックアップを行うバックアップサーバ装置と、
現行系の前記サーバ装置及び前記バックアップサーバ装置へ、前記クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部と、前記サーバ装置から、または前記サーバ装置との通信が不可能になったときは前記バックアップサーバ装置から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部と、から構成されるクライアント装置と、
を有することを特徴とする通信システム。
【００８８】
（付記２） 前記クライアント装置は、前記バックアップサーバ装置の存在を示す存在情報を前記サーバ装置から受信して、前記バックアップサーバ装置の検出を行うバックアップサーバ検出部をさらに有することを特徴とする付記１記載の通信システム。
【００８９】
（付記３） 前記クライアントアドレス情報登録通知部は、前記バックアップサーバ装置が複数台ある場合、前記クライアント装置と前記サーバ装置との通信が不可能になったとき、または前記クライアント装置と前記クライアントアドレス情報を登録したバックアップサーバ装置との通信が不可能になったときに、前記クライアントアドレス情報が登録済みでないバックアップサーバ装置に対して、１台毎に前記クライアントアドレス情報を登録通知することを特徴とする付記１記載の通信システム。
【００９０】
（付記４） 前記クライアントアドレス情報登録通知部は、通信が不可能になったサーバ装置へ、前記クライアントアドレス情報を定期的に送信し、登録許可を受信したときには復旧したとみなし、前記クライアント装置は、復旧した前記サーバ装置へ接続を切り替えることを特徴とする付記１記載の通信システム。
【００９１】
（付記５） 前記サーバ装置は、前記バックアップサーバ装置が複数台ある場合、前記クライアント装置と前記サーバ装置との通信が不可能になったときに、前記バックアップサーバ装置に対するバックアップ時の負荷を分散させるために、前記バックアップサーバ装置の存在を示す存在情報の内容を前記クライアント装置によって変更して通知することを特徴とする付記１記載の通信システム。
【００９２】
（付記６） 前記バックアップサーバ装置は、前記クライアントアドレス情報の登録を保持するための登録保持メッセージの送信間隔を、前記サーバ装置での登録保持メッセージの送信間隔よりも長く設定することを特徴とする付記１記載の通信システム。
【００９３】
（付記７） 前記バックアップサーバ装置は、バックアップを開始した場合、前記サーバ装置よりも長く設定していた前記登録保持メッセージの前記送信間隔を短く設定することを特徴とする付記６記載の通信システム。
【００９４】
（付記８） クライアント側のＶｏＩＰの通信を行うクライアント装置において、
現行系のサーバ装置及びバックアップサーバ装置へ、クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部と、
前記サーバ装置から、または前記サーバ装置との通信が不可能になったときは前記バックアップサーバ装置から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部と、
を有することを特徴とするクライアント装置。
【００９５】
（付記９） 前記バックアップサーバ装置の存在を示す存在情報をサーバ装置から受信して前記バックアップサーバ装置の検出を行うバックアップサーバ検出部をさらに有することを特徴とする付記８記載のクライアント装置。
【００９６】
（付記１０） 前記クライアントアドレス情報登録通知部は、前記バックアップサーバ装置が複数台ある場合、前記クライアント装置と前記サーバ装置との通信が不可能になったとき、または前記クライアント装置と前記クライアントアドレス情報を登録したバックアップサーバ装置との通信が不可能になったときに、前記クライアントアドレス情報が登録済みでないバックアップサーバ装置に対して、１台毎に前記クライアントアドレス情報を登録通知することを特徴とする付記８記載のクライアント装置。
【００９７】
（付記１１） 前記クライアントアドレス情報登録通知部は、通信が不可能になったサーバ装置へ、前記クライアントアドレス情報を定期的に送信し、登録許可を受信したときには復旧したとみなし、復旧した前記サーバ装置へ接続が切り替わることを特徴とする付記８記載のクライアント装置。
【００９８】
（付記１２） 現行系サーバ側のＶｏＩＰの通信を行うサーバ装置において、クライアント装置へ、バックアップサーバ装置の存在を示す存在情報の通知を行い、前記バックアップサーバ装置が複数台ある場合には、前記クライアント装置と前記サーバ装置との通信が不可能になったときに、前記バックアップサーバ装置に対するバックアップ時の負荷を分散させるために、前記存在情報の内容を前記クライアント装置によって変更して通知する存在情報通知部と、
送信されたクライアントアドレス情報を登録する現行系クライアントアドレス情報登録部と、
前記クライアントアドレス情報のアドレス解決処理を行って求めた、着信先のＩＰアドレスを前記クライアント装置へ送信し、伝送帯域を設定する現行系通信設定部と、
前記クライアントアドレス情報の登録を保持するための登録保持メッセージを送信する現行系登録保持設定部と、
を有することを特徴とするサーバ装置。
【００９９】
（付記１３） バックアップサーバ側のＶｏＩＰの通信を行うバックアップサーバ装置において、
送信されたクライアントアドレス情報を登録するバックアップ用クライアントアドレス情報登録部と、
前記クライアントアドレス情報のアドレス解決処理を行って求めた、着信先のＩＰアドレスをクライアント装置へ送信し、伝送帯域を設定するバックアップ用通信設定部と、
前記クライアントアドレス情報の登録を保持するための登録保持メッセージの送信間隔を、サーバ装置での登録保持メッセージの送信間隔よりも長く設定して送信し、バックアップ開始時には、前記送信間隔を短く設定して送信するバックアップ用登録保持設定部と、
を有することを特徴とするバックアップサーバ装置。
【０１００】
（付記１４） ＶｏＩＰの通信を行う通信システムにおいて、
クライアントアドレス情報または差分情報を取得するクライアントアドレス情報取得部と、前記クライアントアドレス情報のアドレス解決処理を行い、現行系サーバとの通信が不可能になったときに、クライアント同士で通信を行う通信部と、から構成されるクライアント装置と、
登録要求のあったクライアント装置に、登録されているクライアントアドレス情報を一括して通知するクライアントアドレス情報通知部と、あらたにクライアントアドレス情報が登録された場合は、クライアントアドレス情報の前記差分情報のみを登録済みのクライアント装置へ通知する差分情報通知部と、から構成される現行系のサーバ装置と、
を有することを特徴とする通信システム。
【０１０１】
（付記１５） クライアント側のＶｏＩＰの通信を行うクライアント装置において、
クライアントアドレス情報または差分情報を取得するクライアントアドレス情報取得部と、
前記クライアントアドレス情報のアドレス解決処理を行い、現行系サーバとの通信が不可能になったときに、クライアント同士で通信を行う通信部と、
を有することを特徴とするクライアント装置。
【０１０２】
（付記１６） 現行系サーバ側のＶｏＩＰの通信を行うサーバ装置において、
登録要求のあったクライアント装置に、登録されているクライアントアドレス情報を一括して通知するクライアントアドレス情報通知部と、
あらたにクライアントアドレス情報が登録された場合は、クライアントアドレス情報の差分情報のみを登録済みのクライアント装置へ通知する差分情報通知部と、
を有することを特徴とするサーバ装置。
【０１０３】
（付記１７） ＶｏＩＰの通信を行うＶｏＩＰ通信方法において、
クライアント機能を持つエンドポイントと、サーバ機能を持つ現行系ゲートキーパとの間で、前記現行系ゲートキーパのバックアップ用のバックアップゲートキーパを見つけるためのGK discovery処理を行い、
前記エンドポイントが、前記現行系ゲートキーパ及び前記バックアップゲートキーパへ、クライアントアドレス情報を同時に登録通知するＥＰ registration処理を行い、
前記エンドポイントと前記現行系ゲートキーパとの間で、または前記現行系ゲートキーパとの通信が不可能になったときは、前記エンドポイントと前記バックアップ用ゲートキーパとの間で、ＩＰアドレスの解決及び帯域割り当てを行うためのAdmission/bandwidth control処理を行い、
通常時には、前記エンドポイントと前記現行系ゲートキーパとの間で通信を行い、前記現行系ゲートキーパとの通信が不可能になった場合には、前記エンドポイントと、瞬断なく接続が切り替わった前記バックアップ用ゲートキーパとの間で通信を行うことを特徴とするＶｏＩＰ通信方法。
【０１０４】
（付記１８） 前記バックアップゲートキーパが複数台ある場合、前記エンドポイントと前記現行系ゲートキーパとの通信が不可能になったとき、または前記エンドポイントと前記クライアントアドレス情報を登録したバックアップゲートキーパとの通信が不可能になったときに、前記クライアントアドレス情報が登録済みでないバックアップゲートキーパに対して、１台毎に前記クライアントアドレス情報を登録通知することを特徴とする付記１７記載のＶｏＩＰ通信方法。
【０１０５】
（付記１９） 通信が不可能になった現行系ゲートキーパへ、前記クライアントアドレス情報を定期的に送信し、登録許可を受信したときには復旧したとみなし、前記バックアップゲートキーパから、復旧した前記現行系ゲートキーパへ接続を切り替えることを特徴とする付記１７記載のＶｏＩＰ通信方法。
【０１０６】
（付記２０） 前記バックアップゲートキーパが複数台ある場合、前記エンドポイントと前記現行系ゲートキーパとの通信が不可能になったときに、前記バックアップゲートキーパに対する負荷を分散させるために、前記バックアップゲートキーパの存在を知らせるための情報の内容を前記エンドポイントによって変更して通知することを特徴とする付記１７記載のＶｏＩＰ通信方法。
【０１０７】
（付記２１） 前記バックアップゲートキーパでのKeepAliveのTimeToLiveを、前記現行系ゲートキーパでのKeepAliveのTimeToLiveよりも長く設定することを特徴とする付記１７記載のＶｏＩＰ通信方法。
【０１０８】
（付記２２） 前記バックアップゲートキーパがバックアップを開始した場合、前記現行系ゲートキーパよりも長く設定していた前記KeepAliveの前記TimeToLiveを短く設定することを特徴とする付記２１記載のＶｏＩＰ通信方法。
【０１０９】
（付記２３） ＶｏＩＰの通信を行うＶｏＩＰ通信方法において、
サーバ側では、登録要求のあったクライアントに、登録されているクライアントアドレス情報を一括して通知し、あらたにクライアントアドレス情報が登録された場合には、クライアントアドレス情報の差分情報のみを登録済みのクライアントへ通知し、
クライアント側では、クライアントアドレス情報または差分情報を取得し、前記クライアントアドレス情報のアドレス解決処理を行って、現行系サーバとの通信が不可能になったときに、クライアント同士で通信を行うことを特徴とするＶｏＩＰ通信方法。
【０１１０】
【発明の効果】
以上説明したように、本発明の通信システムは、クライアント装置から、現行系のサーバ装置及びバックアップサーバ装置へ、クライアントアドレス情報を同時に登録通知し、サーバ装置から、またはサーバ装置との通信が不可能になったときはバックアップサーバ装置から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う構成とした。これにより、現行系からバックアップ用のサーバへ切り替わる際のブランクをなくすことができるので、通信品質の向上を図ることが可能になる。
【図面の簡単な説明】
【図１】 通信システムの原理図である。
【図２】 primary GKの構成を示す図である。
【図３】 alternate GKの構成を示す図である。
【図４】ＲＡＳシグナリングを示すシーケンス図である。
【図５】 primary GKが管理するクライアントアドレス情報テーブルを示す図である。
【図６】 alternate GKが管理するクライアントアドレス情報テーブルを示す図である。
【図７】 alternate GKがバックアップを開始した際のクライアントアドレス情報テーブルを示す図である。
【図８】第２の実施の形態のＲＡＳシグナリングを示すシーケンス図である。
【図９】複数のalternate GKが配置されたシステムの構成を示す図である。
【図１０】複数のalternate GKによりバックアップを行う際の様子を示す図である。
【図１１】第４の実施の形態の通信システムの構成を示す図である。
【図１２】第４の実施の形態におけるクライアントアドレス情報の通知手順を示すシーケンス図である。
【図１３】ＥＰの登録によりＧＫでアドレス解決が行われるまでの処理手順を示すフローチャートである。
【図１４】ＥＰの登録によりＧＫでアドレス解決が行われるまでの処理手順を示すフローチャートである。
【図１５】ＥＰの機能ブロックを示す図である。
【図１６】ＶｏＩＰシステムの構成を示す図である。
【図１７】従来のalternate GKへの登録の様子を示す図である。
【符号の説明】
１ 通信システム
１０ サーバ装置
２０ バックアップサーバ装置
３０−１〜３０−ｎ クライアント装置
３１ バックアップサーバ検出部
３２ クライアントアドレス情報登録通知部
３３ 通信制御部
Claims (4)
- ＶｏＩＰの通信を行う通信システムにおいて、
クライアントアドレス情報の一元管理を行うサーバ装置と、
前記サーバ装置のバックアップを行うバックアップサーバ装置と、
現行系の前記サーバ装置及び前記バックアップサーバ装置へ、前記クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部と、前記サーバ装置から、または前記サーバ装置との通信が不可能になったときは前記バックアップサーバ装置から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部と、
から構成されるクライアント装置と、
を有し、
前記クライアントアドレス情報登録通知部は、前記バックアップサーバ装置が複数台ある場合、前記クライアント装置と前記サーバ装置との通信が不可能になったとき、または前記クライアント装置と前記クライアントアドレス情報を登録したバックアップサーバ装置との通信が不可能になったときに、前記クライアントアドレス情報が登録済みでないバックアップサーバ装置に対して、１台毎に前記クライアントアドレス情報を登録通知する、
ことを特徴とする通信システム。 - ＶｏＩＰの通信を行う通信システムにおいて、
クライアントアドレス情報の一元管理を行うサーバ装置と、
前記サーバ装置のバックアップを行うバックアップサーバ装置と、
現行系の前記サーバ装置及び前記バックアップサーバ装置へ、前記クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部と、前記サーバ装置から、または前記サーバ装置との通信が不可能になったときは前記バックアップサーバ装置から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部と、
から構成されるクライアント装置と、
を有し、
前記クライアントアドレス情報登録通知部は、通信が不可能になったサーバ装置へ、前記クライアントアドレス情報を定期的に送信し、登録許可を受信したときには復旧したとみなし、前記クライアント装置は、復旧した前記サーバ装置へ接続を切り替える、
ことを特徴とする通信システム。 - ＶｏＩＰの通信を行う通信システムにおいて、
クライアントアドレス情報の一元管理を行うサーバ装置と、
前記サーバ装置のバックアップを行うバックアップサーバ装置と、
現行系の前記サーバ装置及び前記バックアップサーバ装置へ、前記クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部と、前記サーバ装置から、または前記サーバ装置との通信が不可能になったときは前記バックアップサーバ装置から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部と、
から構成されるクライアント装置と、
を有し、
前記サーバ装置は、前記バックアップサーバ装置が複数台ある場合、前記クライアント装置と前記サーバ装置との通信が不可能になったときに、前記バックアップサーバ装置に対するバックアップ時の負荷を分散させるために、前記バックアップサーバ装置の存在を示す存在情報の内容を前記クライアント装置によって変更して通知する、
ことを特徴とする通信システム。 - ＶｏＩＰの通信を行う通信システムにおいて、
クライアントアドレス情報の一元管理を行うサーバ装置と、
前記サーバ装置のバックアップを行うバックアップサーバ装置と、
現行系の前記サーバ装置及び前記バックアップサーバ装置へ、前記クライアントアドレス情報を同時に登録通知するクライアントアドレス情報登録通知部と、前記サーバ装置から、または前記サーバ装置との通信が不可能になったときは前記バックアップサーバ装置 から、着信先のＩＰアドレスを受信し、設定された伝送帯域の確保を行う通信制御部と、
から構成されるクライアント装置と、
を有し、
前記バックアップサーバ装置は、前記クライアントアドレス情報の登録を保持するための登録保持メッセージの送信間隔を、前記サーバ装置での登録保持メッセージの送信間隔よりも長く設定する、
ことを特徴とする通信システム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002057169A JP3883452B2 (ja) | 2002-03-04 | 2002-03-04 | 通信システム |
| US10/339,205 US20030167343A1 (en) | 2002-03-04 | 2003-01-09 | Communications system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002057169A JP3883452B2 (ja) | 2002-03-04 | 2002-03-04 | 通信システム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003258837A JP2003258837A (ja) | 2003-09-12 |
| JP2003258837A5 JP2003258837A5 (ja) | 2004-10-14 |
| JP3883452B2 true JP3883452B2 (ja) | 2007-02-21 |
Family
ID=27800110
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002057169A Expired - Fee Related JP3883452B2 (ja) | 2002-03-04 | 2002-03-04 | 通信システム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20030167343A1 (ja) |
| JP (1) | JP3883452B2 (ja) |
Families Citing this family (47)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7711847B2 (en) | 2002-04-26 | 2010-05-04 | Sony Computer Entertainment America Inc. | Managing users in a multi-user network game environment |
| US20030217135A1 (en) | 2002-05-17 | 2003-11-20 | Masayuki Chatani | Dynamic player management |
| US8131802B2 (en) | 2007-10-05 | 2012-03-06 | Sony Computer Entertainment America Llc | Systems and methods for seamless host migration |
| US8560707B2 (en) | 2007-10-05 | 2013-10-15 | Sony Computer Entertainment America Llc | Seamless host migration based on NAT type |
| KR100475186B1 (ko) | 2002-12-02 | 2005-03-10 | 삼성전자주식회사 | 접속 설정 프로토콜을 이용한 단말 장치의 등록 방법 |
| DE10314559A1 (de) * | 2003-03-31 | 2004-10-28 | Siemens Ag | Verfahren und Steuerungsprogramm zum Betrieb eines Kommunikationsendgeräts für paketorientierte Datenübermittlung |
| EP1487186B8 (de) * | 2003-06-11 | 2017-05-17 | Unify GmbH & Co. KG | Verfahren und Kommunikationsanordnung zum wechselweisen Betrieb eines Endgerätes an zumindest zwei Kommunikationsknoten |
| GB2405769B (en) * | 2003-09-08 | 2006-06-07 | Siemens Ag | A method of communicating between a user and a network |
| US7747672B1 (en) * | 2003-09-12 | 2010-06-29 | Avaya Inc. | Method and apparatus using lightweight RRQ for efficient recovery of a call signaling channel in gatekeeper-routed call signaling |
| US8050199B2 (en) * | 2003-09-30 | 2011-11-01 | Avaya Inc. | Endpoint registration with local back-off in a call processing system |
| JP4713492B2 (ja) * | 2003-11-21 | 2011-06-29 | アバイア カナダ コーポレーション | ネットワーク装置のバックアップ |
| US8170912B2 (en) * | 2003-11-25 | 2012-05-01 | Carhamm Ltd., Llc | Database structure and front end |
| TW200605574A (en) * | 2004-02-17 | 2006-02-01 | Ginganet Corp | Address resolution apparatus, address resolution method and telecommunication system thereof |
| US8838771B2 (en) * | 2004-09-27 | 2014-09-16 | Alcatel Lucent | Enabling VoIP calls to be initiated when a call server is unavailable |
| US20060182130A1 (en) * | 2005-01-24 | 2006-08-17 | Polycom, Inc. | Method and system for establishing an audio/video communication session across zones |
| US8223926B2 (en) * | 2005-02-11 | 2012-07-17 | Cisco Technology, Inc. | Resilient registration with a call manager |
| US8572431B2 (en) * | 2005-02-23 | 2013-10-29 | Barclays Capital Inc. | Disaster recovery framework |
| JP2006237950A (ja) * | 2005-02-24 | 2006-09-07 | Saxa Inc | Ｉｐ電話端末およびプログラム |
| US8594128B2 (en) * | 2005-04-19 | 2013-11-26 | At&T Intellectual Property Ii, L.P. | Method and apparatus for enabling dynamic protocol interworking resolution with diverse endpoints |
| US7668100B2 (en) | 2005-06-28 | 2010-02-23 | Avaya Inc. | Efficient load balancing and heartbeat mechanism for telecommunication endpoints |
| JP4491403B2 (ja) * | 2005-10-28 | 2010-06-30 | 富士通株式会社 | システム復旧方法 |
| US7899456B2 (en) * | 2005-12-16 | 2011-03-01 | International Business Machines Corporation | Method for faster mobility handoff of a mobile node |
| US8121028B1 (en) * | 2006-01-03 | 2012-02-21 | Sprint Communications Company L.P. | Quality of service provisioning for packet service sessions in communication networks |
| US9178742B2 (en) * | 2006-03-21 | 2015-11-03 | Cisco Technology, Inc. | System and method for maintaining a provisioned configuration for an endpoint in a communications network |
| US8630163B1 (en) * | 2006-09-28 | 2014-01-14 | Cisco Technology, Inc. | Server driven endpoint re-homing |
| JP4470934B2 (ja) * | 2006-10-20 | 2010-06-02 | 日本電気株式会社 | プロキシ・サーバ、通信システム、通信方法及びプログラム |
| GB2443859B (en) * | 2006-11-17 | 2011-11-09 | Al Innovations Ltd | Voice over internet protocol systems |
| CN100440792C (zh) * | 2006-12-14 | 2008-12-03 | 北京中星微电子有限公司 | 多点语音通讯方法及终端 |
| US8576833B2 (en) * | 2006-12-15 | 2013-11-05 | At&T Intellectual Property I, L.P. | Fault tolerant voice over Internet protocol (VoIP) systems and methods to operate the same |
| JP5227616B2 (ja) * | 2008-03-07 | 2013-07-03 | 株式会社日立製作所 | Ｉｐ電話システム、および複数の拠点間における呼の中継方法 |
| US8018848B2 (en) * | 2008-03-26 | 2011-09-13 | Avaya Inc. | Survivable phone behavior using SIP signaling in a SIP network configuration |
| US8107361B2 (en) * | 2008-03-26 | 2012-01-31 | Avaya Inc. | Simultaneous active registration in a SIP survivable network configuration |
| US7995466B2 (en) * | 2008-03-26 | 2011-08-09 | Avaya Inc. | Failover/failback trigger using SIP messages in a SIP survivable configuration |
| US8527656B2 (en) * | 2008-03-26 | 2013-09-03 | Avaya Inc. | Registering an endpoint with a sliding window of controllers in a list of controllers of a survivable network |
| US9438636B2 (en) | 2009-05-01 | 2016-09-06 | Avaya Inc. | Method to block split phone and gateway registration |
| US20120124431A1 (en) * | 2010-11-17 | 2012-05-17 | Alcatel-Lucent Usa Inc. | Method and system for client recovery strategy in a redundant server configuration |
| US8345840B2 (en) | 2010-11-23 | 2013-01-01 | Mitel Networks Corporation | Fast detection and reliable recovery on link and server failures in a dual link telephony server architecture |
| US8451828B2 (en) * | 2010-11-23 | 2013-05-28 | Mitel Network Corporation | Registering an internet protocol phone in a dual-link architecture |
| US9007972B2 (en) | 2011-07-01 | 2015-04-14 | Intel Corporation | Communication state transitioning control |
| US9526091B2 (en) | 2012-03-16 | 2016-12-20 | Intel Corporation | Method and apparatus for coordination of self-optimization functions in a wireless network |
| US9288140B2 (en) * | 2012-07-09 | 2016-03-15 | Coriant Operations, Inc. | Multichassis failover and recovery for MLPPP wireless backhaul |
| CN104104556B (zh) * | 2013-04-12 | 2018-09-28 | 腾讯科技（北京）有限公司 | 进行推荐信息展现的方法及系统 |
| CN103236947A (zh) * | 2013-04-23 | 2013-08-07 | 厦门亿联网络技术股份有限公司 | 一种用于voip话机的主备服务器切换方法 |
| CN104158735A (zh) * | 2014-08-21 | 2014-11-19 | 网神信息技术（北京）股份有限公司 | 网络数据包的分配方法和装置 |
| US10765952B2 (en) | 2018-09-21 | 2020-09-08 | Sony Interactive Entertainment LLC | System-level multiplayer matchmaking |
| US10695671B2 (en) | 2018-09-28 | 2020-06-30 | Sony Interactive Entertainment LLC | Establishing and managing multiplayer sessions |
| JP2024047727A (ja) * | 2022-09-27 | 2024-04-08 | 株式会社Ｊｖｃケンウッド | 端末装置、通信方法およびプログラム |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5828847A (en) * | 1996-04-19 | 1998-10-27 | Storage Technology Corporation | Dynamic server switching for maximum server availability and load balancing |
| US6016512A (en) * | 1997-11-20 | 2000-01-18 | Telcordia Technologies, Inc. | Enhanced domain name service using a most frequently used domain names table and a validity code table |
| US6519249B1 (en) * | 1998-12-23 | 2003-02-11 | Nortel Networks Ltd | Scalable gatekeepers in an internet telephony system and a method of operation |
| US6693874B1 (en) * | 1999-05-26 | 2004-02-17 | Siemens Information & Communication Networks, Inc. | System and method for enabling fault tolerant H.323 systems |
| US7023987B1 (en) * | 2000-05-04 | 2006-04-04 | Televoce, Inc. | Method and apparatus for adapting a phone for use in network voice operations |
| US20020065922A1 (en) * | 2000-11-30 | 2002-05-30 | Vijnan Shastri | Method and apparatus for selection and redirection of an existing client-server connection to an alternate data server hosted on a data packet network (DPN) based on performance comparisons |
| JP2002344497A (ja) * | 2001-05-18 | 2002-11-29 | Fujitsu Ltd | メディアゲートウェイ装置間の接続ルート切替え制御方法及びコールエージェント装置 |
-
2002
- 2002-03-04 JP JP2002057169A patent/JP3883452B2/ja not_active Expired - Fee Related
-
2003
- 2003-01-09 US US10/339,205 patent/US20030167343A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003258837A (ja) | 2003-09-12 |
| US20030167343A1 (en) | 2003-09-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3883452B2 (ja) | 通信システム | |
| EP1047241B1 (en) | System and method for restarting of signaling entities in H.323-based realtime communication networks | |
| EP1234410B1 (en) | Apparatus for a voice over ip (voip) telephony gateway and methods for use therein | |
| CN103430524B (zh) | 一种用于使得使用sip的企业网络能够存活的备用sip服务器 | |
| US7809846B2 (en) | Resilient application layer overlay framework for converged communication over Internet protocol networks | |
| JP2001203726A (ja) | 通信システム、通信方法および通信装置 | |
| US20070223446A1 (en) | System and method for maintaining a provisioned configuration for an endpoint in a communications network | |
| JP2009527200A (ja) | Ｉｐベースの通信システムにおけるコールを記録するシステムおよび方法 | |
| CA2478361C (en) | Method and apparatus for migrating to an alternate call controller | |
| WO2008052427A1 (fr) | Procédé et système de communication réseau pour rediriger un port de communication réseau | |
| US20100027528A1 (en) | Notification of Impending Media Gateway Resource Exhaustion | |
| US20060002371A1 (en) | Roaming communication system over Internet with remote hosts and related method | |
| US8331258B2 (en) | Method and device for responding to termination service state change indication | |
| KR100418397B1 (ko) | 이종 프로토콜간의 인터페이스를 수행하는 소프트 스위치 | |
| JP3933904B2 (ja) | 情報管理方法および情報管理装置 | |
| JP5427853B2 (ja) | データ同期方法 | |
| CA2442554A1 (en) | Internet telephony call agent |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050224 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060817 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060822 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061019 |
|
| 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: 20061114 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061114 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |