JP4060846B2 - コールパークサービスシステム、呼制御サーバおよびコールパークサービス方法 - Google Patents

Description

本発明は、本願発明は、ＩＰネットワークを介した音声通話におけるコールパークサービスを提供するコールパークサービスシステム、呼制御サーバおよびコールパークサービス方法に関するものである。

現在、ＩＰ(Internet Protocol)網を用いた音声通話（以下、ＶｏＩＰ（Voice over IP）という）サービス・製品としてＳＩＰ(Session Initiation Protocol)プロトコルを用いたＳＩＰサービスプロバイダ（企業向けにＳＩＰベースのＶｏＩＰサービスを提供しているキャリア）が多く存在している。ＳＩＰサービスプロバイダでは、呼処理系付加サービスにＳＩＰプロトコルを採用した製品を開発しＶｏＩＰサービスを推進しており、ＶｏＩＰサービスとして新音声サービス（既存付加サービス）の提供が検討されている（例えば特許文献１，２参照）。

上記新音声サービスの１つとして、コールパークサービスの提供が検討されている。このコールパークサービスとは、例えば、予めグルーピングされた複数の端末のうち何れかの端末（端末Ａ）が通信中の相手端末Ｂを、ピックアップが可能となる保留状態を意味するコールパーク保留したときに、当該グループに属する端末Ｃをピックアップすると、端末Ｃが端末Ｂと通話ができるサービスである。
なお、ピックアップとは、予め決められた操作により同一コールパークグループに属する他のユーザの呼を自分の端末に切り替える操作のことを意味する。

なお、出願人は、本明細書に記載した先行技術文献情報で特定される先行技術文献以外には、本発明に関連する先行技術文献を出願時までに発見するには至らなかった。
特開２００１−２２３７４７号公報 特表２００３−５１７７６４

しかしながら、従来のコールパークサービスは、ユーザ側にＰＢＸ(Private automatic Branch eXchange)が存在しないと実現することができなかった。また、従来のコールパークサービスは、ユーザ側のＰＢＸによって実現されているため、端末とＰＢＸ間の制御にＰＢＸ独自のプロトコルが用いられており、コールパークサービス相互の接続性が低かった。
そこで、本願発明は、上述したような課題を解決するためになされたものであり、使い勝手のよいＶｏＩＰによるコールパークサービスシステム、呼制御サーバおよびコールパークサービス方法を提供することを目的とする。

上述したような課題を解決するために、本発明に係るコールパークサービスシステムは、ＩＰネットワークに接続されＩＰネットワークを介して通信を行う複数の端末と、ＩＰネットワークに接続され端末間の呼を制御する呼制御サーバとを備え、呼制御サーバは、第１の端末と第２の端末との間の呼を確立する第１の手段と、第１の端末の保留動作を検出すると呼を保留する第２の手段と、第３の端末からの保留解除動作を検出すると、第２の端末と第３の端末との間の呼を確立する第３の手段とを備えたことを特徴とする。

上記コールパークサービスシステムにおいて、端末のグループを管理するデータベースを備え、第３の手段は、第３の端末からの保留解除動作を検出すると、データベースを参照して第１の端末と第３の端末とが同一のグループに属するか否かを判断し、両者が同一のグループに属するときに第２の端末と第３の端末との間の呼を確立するようにしてもよい。

上記コールパークサービスシステムにおいて、呼制御サーバは、さらに各端末に端末の呼の状態に応じて状態表示信号を送信する第４の手段を備え、端末は、状態表示信号を受信する受信手段と、受信した状態表示信号に応じた表示を行う表示手段とを有するようにしてもよい。

上記コールパークサービスシステムにおいて、呼制御サーバは、さらにデータベースを参照し、同一のグループに属する各端末に端末の呼の状態に応じて状態表示信号を送信する第４の手段を備え、端末は、状態表示信号を受信する受信手段と、受信した状態表示信号に応じた表示を行う表示手段とを有するようにしてもよい。

上記コールパークサービスシステムにおいて、状態表示信号は、通話中、保留中、終話信号のうち少なくとも１つを表す信号を含むようにしてもよい。

上記コールパークサービスシステムにおいて、第４の手段は、第１の端末と第２の端末との間で呼が確立されると、第１の端末が属するグループと第２の端末が属するグループの端末それぞれに通話中を表す信号を送信するようにしてもよい。

上記コールパークサービスシステムにおいて、第４の手段は、通話中の第１の端末からの保留動作により呼が保留されると、第１の端末が属するグループの端末に保留中を表す信号を送信するようにしてもよい。

上記コールパークサービスシステムにおいて、第４の手段は、通話中の第１または第３の端末と第２の端末とのいずれかからの終話動作が検出されると、第１の端末が属するグループの端末に終話信号を送信するようにしてもよい。

また、本発明に係る呼制御サーバは、ＩＰネットワークに接続され、ＩＰネットワークを介して通信を行う端末間の呼を制御する呼制御サーバであって、第１の端末と第２の端末との間の呼を確立する第１の手段と、第１の端末の保留動作を検出すると呼を保留する第２の手段と、第３の端末からの保留解除動作を検出すると、第２の端末と第３の端末との間の呼を確立する第３の手段と端末のグループを管理するデータベースとを備え、第３の手段は、第３の端末からの保留解除動作を検出すると、データベースを参照して第１の端末と第３の端末とが同一のグループに属するか否かを判断し、両者が同一のグループに属するときに第２の端末と第３の端末との間の呼を確立することを特徴とする。

上記呼制御サーバにおいて、データベースを参照し、同一のグループに属する各端末に端末の呼の状態に応じて状態表示信号を送信する第４の手段をさらに備えるようにしてもよい。

上記呼制御サーバにおいて、状態表示信号は、通話中、保留中、終話信号のうち少なくとも１つを表す信号を含むようにしてもよい。

上記呼制御サーバにおいて、第４の手段は、第１の端末と第２の端末との間で呼が確立されると、第１の端末が属するグループと第２の端末が属するグループの端末それぞれに通話中を表す信号を送信するようにしてもよい。

上記呼制御サーバにおいて、第４の手段は、通話中の第１の端末からの保留動作により呼が保留されると、第１の端末が属するグループの端末に保留中を表す信号を送信するようにしてもよい。

上記呼制御サーバにおいて、第４の手段は、通話中の第１または第３の端末と第２の端末とのいずれかからの終話動作が検出されると、第１の端末が属するグループの端末に終話信号を送信するようにしてもよい。

また、本発明に係るコールパークサービス方法は、ＩＰネットワークに接続されＩＰネットワークを介して通信を行う複数の端末と、ＩＰネットワークに接続され端末間の呼を制御する呼制御サーバと、端末のグループを管理するデータベースとを備えた通信システムのコールパークサービス方法であって、第１の端末と第２の端末との間の呼を確立する第１のステップと、第１の端末の保留動作を検出すると呼を保留する第２のステップと、第３の端末からの保留解除動作を検出すると、第２の端末と第３の端末との間の呼を確立する第３のステップとを備え、上記第３のステップは、第３の端末からの保留解除動作を検出すると、データベースを参照して第１の端末と第３の端末とが同一のグループに属するか否かを判断し、両者が同一のグループに属するときに第２の端末と第３の端末との間の呼を確立することを特徴とする。

上記コールパークサービス方法において、データベースを参照し、同一のグループに属する各端末に端末の呼の状態に応じて状態表示信号を送信する第４のステップをさらに有するようにしてもよい。

上記コールパークサービス方法において、状態表示信号は、通話中、保留中、終話信号のうち少なくとも１つを表す信号を含むようにしてもよい。

上記コールパークサービス方法において、上記第４のステップは、第１の端末と第２の端末との間で呼が確立されると、第１の端末が属するグループと第２の端末が属するグループの端末それぞれに通話中を表す信号を送信するようにしてもよい。

上記コールパークサービスシステムにおいて、上記第４のステップは、通話中の第１の端末からの保留動作により呼が保留されると、第１の端末が属するグループの端末に保留中を表す信号を送信するようにしてもよい。

上記コールパークサービスシステムにおいて、上記第４のステップは、通話中の第１または第３の端末と第２の端末とのいずれかからの終話動作が検出されると、第１の端末が属するグループの端末に終話信号を送信するようにしてもよい。

本発明によれば、第１の端末と第２の端末との間で呼が確立され、第１の端末の保留動作を検出すると確立された呼が保留にされ、第３の端末から保留解除動作を検出すると第２の端末と第３の端末との間の呼が確立される。このため、コールパークサービスを提供するのにＰＢＸが必要ではなく、ＰＢＸ独自のプロトコルを使わなくてよいので、使い勝手のよいＶｏＩＰによるコールパークサービスの提供が可能となる。

以下、図面を参照して、本発明の実施の形態について詳細に説明する。図１は、本実施の形態に係るコールパークサービスシステムの構成を示す図である。
本実施の形態に係るコールパークサービスシステムは、ＶＰＮ１に接続された複数の電話端末１０と、ＩＰ網に含まれるＶＰＮ(Virtual Private Network)１に接続されたＣＡ(Call Agent)２０とを有する。ここで、ＩＰ網には、任意の条件ごとにグルーピングされた複数のＶＰＮが含まれるようにしてもよい。

電話端末１０は、ＶＰＮ１に直接に接続されたＩＰ電話端末、ＧＷ(Gate Way)を介してＶＰＮ１に接続された公衆回線網に接続された電話端末、ＬＡＮ(Local Area Network)２等を介してＶＰＮ２に接続されたＩＰ電話端末等から構成される。ここで、任意のＬＡＮ２に接続された電話端末２０は、任意のパークグループを構成し、このグループ内でコールパークサービスが実現される。

このような電話端末１０は、ＶＰＮ１等から各種データを送受信するための送受信部と、受信したデータを表示する表示部とを少なくとも備える。表示部は、ランプ、スピーカ、液晶や蛍光表示管等の表示画面等から構成され、色、音、画像等により、各種表示を行う。

図２は、ＣＡ２０の構成を示すブロック図である。
ＣＡ２０は、データ通信部２１と、制御部２２と、記憶部２３と、保留部２４とを少なくとも備える。

データ通信部２１は、電話端末２０と各種データの送受信を行う。
制御部２２は、ＣＡ２０各部を制御し、電話端末１０の呼制御を行う。

記憶部２３は、制御部２２の制御およびコールパーク部２４が用いる各種データを記憶する。この記憶部２３には、図３に示すテーブルも記憶されている。図３は、記憶部２３に記憶されるテーブルの図である。

図３（ａ）に示すＶＰＮ内線番号変換テーブルは、パークグループ内の電話端末１０の電話番号を示す「ユーザ番号」、パークグループ内の内線番号を示す「内線番号」、ＶＰＮの識別番号を示す「ＶＰＮグループ」、例えば地域など端末が設けられた物理的な位置等の識別番号を示す「拠点番号」、端末番号の桁数を示す「端末番号桁数」、パークグループの識別番号を示す「パークグループ」等のフィールドを有し、任意のＶＰＮに含まれる全てのユーザ番号のレコードが記録される。ここで、「内線番号」とは、「拠点番号」と「端末番号」とを組み合わせたものに相当し、このような「内線番号」を電話番号を示す数列の末尾に組み合わせたものが「ユーザ番号」となる。

図３（ｂ）に示すパークグループ管理テーブルには、ＶＰＮの識別番号を示す「ＶＰＮグループ」、パークグループの識別番号を示す「パークグループ」、パークグループの識別ＩＤを示す「識別ＩＤ」、パークグループ内の電話端末１０の電話番号を示す「ユーザ番号」等のフィールドを有し、パークグループに含まれる全てのユーザ番号のレコードが記録される。

図３（ｃ）に示すランプ番号管理テーブルは、ＶＰＮの識別番号を示す「ＶＰＮグループ」、パークグループの識別番号を示す「パークグループ」、このパークグループが有するランプの使用状況を示す「ランプ番号」等のフィールドを有し、任意のＶＰＮに含まれる全てのパークグループに対応するレコードが形成される。
ここで、「ランプ番号」のフィールドは、例えば５０などＣＡ２０が管理可能な数量設けられており、該当するランプが使用中の場合は「１」、該当するランプが空いている場合は「０」が記録される。

図３（ｄ）に示す番号状態テーブルは、ＶＰＮの識別番号を示す「ＶＰＮグループ」、パークグループの識別番号を示す「パークグループ」、ランプの識別番号を示す「管理ランプ番号」、呼情報を示す「呼情報」、ランプの状態を示す「ランプ状態」等のフィールドを有し、任意のパークグループに含まされる全てのランプに対応するレコードが形成される。
ここで、「ランプ状態」のフィールドには、対応する電話端末１０が通話中（ＢＵＳＹ）の場合には「１」が、対応する電話端末１０が保留中（ＨＯＬＤ）の場合には「２」が記録される。

保留部２４は、記憶部２３に記憶された各テーブルを参照してコールパークサービスを提供する電話端末１０のパークグループの識別動作、ＮＯＴＩＦＹ信号等のコールパークサービスに関する各種信号の送受信動作などのコールパークサービスに関する各種制御を行う。

このようなＣＡ２０を構成するデータ通信部２１、制御部２２、記憶部２３および保留部２４は、それぞれＣＰＵ等の演算装置、メモリ、HDD等の記憶装置、ＶＰＮ１に接続された電話端末１０と各種情報の送受を行うＩ/Ｆ装置、キーボード、マウス等の入力装置、CRT(Cathode Ray Tube)、LCD(Liquid Crystal Display)、FED(Field Emission Display)または有機EL(Electro Luminescence)等の表示装置などを備えたコンピュータと、このコンピュータにインストールされたプログラムとから構成されており、上記ハードウェア装置がプログラムによって制御されることによって、すなわちハードウェア資源とソフトウェアが協働することによって、各機能を実現する。
なお、プログラムは、ＣＤ(Compact Disc)、ＤＶＤ(Digital Versatile Disk)やフレキシブルディスクなどの記録媒体に記録し、この記録媒体によってコンピュータにインストールするようにしてもよい。また、ＣＡ２０が接続されたＶＰＮ１を介して受信したプログラムをコンピュータにインストールするようにしてもよい。

次に、図４を参照して、本実施の形態に係るコールパークサービスシステムの動作について説明する。図４は、コールパークサービスシステムの動作を示すシーケンス図である。
図４において、電話端末１０からなる端末Ａ０および端末Ａ１とが同じコールグループ（コールグループ＃１）に属し、電話端末１０からなる端末Ｂ０および端末Ｂ１とが同じコールグループ（コールグループ＃２）に属する場合を例に説明する。また、図４では、後述する「通話中状態表示あり」に設定された場合について説明する。
なお、以下において、便宜上、電話端末１０のことを端末という。

なお、本実施の形態で用いるＳＩＰでは、メソッドを指定することでコマンドを実行する。標準では次のメソッドが定義されている。
「ＩＮＶＩＴＥ」は、ユーザをコールに招待することを意味する。
「ＡＣＫ」は、「ＩＮＶＩＴＥ」に対する応答を受け取ったことを知らせることを意味する。
「ＢＹＥ」は、コールを終了することを意味する。
「ＣＡＮＣＥＬ」は、未応答の「ＩＮＶＩＴＥ」リクエストをキャンセルすることを意味する。
「ＯＰＴＩＯＮＳ」は、サーバの能力情報を問い合わせることを意味する。
「ＲＥＧＩＳＴＥＲ」は、ユーザの現在位置を登録することを意味する。
「ＩＮＦＯ」は、ＤＴＭＦディジットや画像等のセッションに関係する情報を伝えることを意味する。

また、ＳＩＰでは、ＨＴＴＰ／１．１の応答コードの一部を拡張して利用する。応答コードには次のようなものが含まれる。
１００番台の応答コードは、暫定応答を意味し、リクエストを受信し、処理中であることを示す。例えば、「１００Ｔｒｙｉｎｇ」や「１８０Ｒｉｎｇｉｎｇ」などが挙げられる。
２００番台の応答コードは、成功応答を意味し、リクエストが理解され、受け入れられたことを示す。例えば、「２００ＯＫ」や「２０２Ａｃｃｅｐｔｅｄ」などが挙げられる。
３００番台の応答コードは、リダイレクト応答を意味し、リクエストを完了するために、更なる処理が必要であることを示す。例えば、「３００Ｍｕｌｔｉｐｌｅ Ｃｈｏｉｃｅｓ」や「３０１Ｍｏｖｅｄ Ｐｅｒｍａｎｅｎｔｌｙ」などが挙げられる。

４００番台の応答コードは、リクエストエラー応答を意味し、リクエストの書式が間違っていたか、このサーバでは処理できないことを示す。例えば、「４００Ｂａｄ Ｒｅｑｕｅｓｔ」や「４０１Ｕｎａｕｔｈｏｒｉｚｅｄ」などが挙げられる。
５００番台の応答コードは、サーバエラー応答を意味し、サーバでのリクエスト処理に失敗したことを示す。例えば、「５００Ｉｎｔｅｒｎａｌ Ｓｅｒｖｅｒ Ｅｒｒｏｒ」や「５０１Ｎｏｔ Ｉｍｐｌｅｍｅｎｔｅｄ」などが挙げられる。
６００番台の応答コードは、グローバルサーバエラー応答を意味し、リクエストをどのサーバでも処理できないことを意味する。例えば、「６００Ｂｕｓｙ Ｅｖｅｒｙｗｈｅｒｅ」や「６０３Ｄｅｃｌｉｎｅ」などが挙げられる。

まず、端末Ａ１と端末Ｂ０とが通話を開始する動作を説明する（ステップＳ４０１〜４１５）。
発端末である端末Ａ１は、着端末である端末Ｂ０を指定するアドレスに関する情報を含むＩＮＶＩＴＥリクエストを、ＣＡ２０に送出する（ステップＳ４０１）。ＩＮＶＩＴＥリクエストを受信したＣＡ２０は、リクエストに対するレスポンスとして正常にＩＮＶＩＴＥリクエストを受信し、相手側端末である端末Ｂ０にＩＮＶＩＴＥをルートすることを試みていることを通知する１００Ｔｒｙｉｎｇレスポンスを、端末Ａ１に返送する（ステップＳ４０２）。また、ＣＡ２０は、ＩＮＶＩＴＥリクエストを端末Ｂ０に転送する（ステップＳ４０３）。

ＩＮＶＩＴＥリクエストを受信した端末Ｂ０は、１００ＴｒｙｉｎｇレスポンスをＣＡ２０に返送して呼び出しを開始し（ステップＳ４０４）、１８０ＲｉｎｇｉｎｇレスポンスメッセージをＣＡ２０を介して端末Ａ１に向かって送信する（ステップＳ４０５）。
１８０Ｒｉｎｇｉｎｇレスポンスメッセージを受信したＣＡ２０は、１８０Ｒｉｎｇｉｎｇレスポンスメッセージを、端末Ａ１に転送する（ステップＳ４０６）。
１８０Ｒｉｎｇｉｎｇレスポンスメッセージを受信した端末Ａ１は、呼び出し音または画面表示でユーザに通知する。

端末Ｂ０のユーザが受話器を取ると、端末Ｂ０は応答したことを示すため２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４０７）。
２００ＯＫレスポンスメッセージを受信したＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ａ１に転送する（ステップＳ４０８）。

２００ＯＫレスポンスメッセージを受信した端末Ａ１は、２００ＯＫレスポンスメッセージの受信を確認するため、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ４０９）。
端末Ａ１から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１が属するコールグループの全ての端末に対して、呼状態（ＢＵＳＹ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４１０）。このＣＡ２０から送信されるＮＯＴＩＦＹ信号には、端末のランプ制御に関する情報が含まれており、受信したＮＯＴＩＦＹ信号に基づいて、コールグループ＃１の端末は、自身のランプの点灯制御を行う。
コールグループ＃１の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４１２）。なお、端末から送信されるＮＯＴＩＦＹ信号に対する２００ＯＫ信号は、コールパークサービスの動作に関わらず、コールパークサービスの動作とは非同期でＣＡ２０に送信される。

また、端末Ａ１からＡＣＫメッセージを受信したＣＡ２０は、コールグループ＃２に属する端末に対して、呼状態（ＢＵＳＹ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４１３）。このＮＯＴＩＦＹ信号にも、端末のランプ制御に関する情報が含まれており、コールグループ＃２の端末は、受信したＮＯＴＩＦＹ信号に基づいて、自身のランプの点灯制御を行う。
コールグループ＃２の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４１４）。

これにより、端末Ａ１と端末Ｂ０とは通話中となる（ステップＳ４１５）。

次に、端末Ｂ０が端末Ａ１をコールパーク保留にし、端末Ｂ０と同じコールグループ＃２の端末Ｂ１が端末Ａ１と通話を行う動作について説明する（ステップＳ４２１〜Ｓ４４０）。

コールパーク保留を行う端末Ｂ０は、通話中である端末Ａ１を保留（ＨＯＬＤ）にする情報を含むＩＮＶＩＴＥリクエストを、ＣＡ２０に送出する（ステップＳ４２１）。ＩＮＶＩＴＥリクエストを受信したＣＡ２０は、ＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ４２２）。

ＩＮＶＩＴＥリクエストを受信した端末Ａ１は、応答したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ４２３）。２００ＯＫレスポンスメッセージを受信したＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ０に転送する（ステップＳ４２４）。２００ＯＫレスポンスメッセージを受信した端末Ｂ０は、２００ＯＫレスポンスメッセージの受信を確認するため、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ４２５）。

端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ｂ０が属するコールグループ＃２の全ての端末に対して、呼状態（ＨＯＬＤ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４２６）。このＮＯＴＩＦＹ信号には、端末のランプ制御に関する情報が含まれており、受信したＮＯＴＩＦＹ信号に基づいて、コールグループ＃２の端末は、自身のランプを点灯制御を行う。
コールグループ＃２の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４２７）。

また、ＣＡ２０は、端末Ａ１を保留にすることを示すＮＯＴＩＦＹ信号をコールグループ＃２の端末に送信すると、ＡＣＫメッセージを端末Ａ１に送信する（ステップＳ４２８）。
これにより、端末Ａ１と端末Ｂ０とは、コールパーク保留状態となる（ステップＳ４２９）。

ここで、端末Ｂ１は、コールパーク保留にされた端末Ａ１をピックアップするために、コールパーク保留中である端末Ａ１を保留解除（ＵＮＨＯＬＤ）する情報を含むＩＮＶＩＴＥリクエストを、ＣＡ２０に送出する（ステップＳ４３０）。ＩＮＶＩＴＥリクエストを受信したＣＡ２０は、ＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ４３１）。

ＩＮＶＩＴＥリクエストを受信した端末Ａ１は、応答したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ４３２）。２００ＯＫレスポンスメッセージを受信したＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ１に転送する（ステップＳ４３３）。２００ＯＫレスポンスメッセージを受信した端末Ｂ１は、２００ＯＫレスポンスメッセージの受信を確認するため、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ４３４）。

端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ｂ０が属するコールグループ＃２の全ての端末に対して、呼状態（ＢＵＳＹ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４３５）。このＮＯＴＩＦＹ信号には、端末のランプ制御に関する情報が含まれており、受信したＮＯＴＩＦＹ信号に基づいて、コールグループ＃２の端末は、自身のランプを点灯制御を行う。
コールグループ＃２の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４３６）。

また、ＣＡ２０は、端末Ａ１を保留解除することを示すＮＯＴＩＦＹ信号をコールグループ＃２の端末に送信すると、ＡＣＫメッセージを端末Ａ１に送信する（ステップＳ４３７）。
また、ＣＡ２０は、通信を切断することを意味するＢＹＥメッセージを、端末Ａ１をコールパーク保留にした端末Ｂ０に、送信する（ステップＳ４３８）。ＢＹＥメッセージを受信すると、端末Ｂ０は、ＢＹＥメッセージを受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ４３９）。

これにより、端末Ａ１のコールパーク保留が解除され、端末Ａ１と端末Ｂ１との通話が実現される（ステップＳ４４０）。

なお、上述したように端末Ａ１と端末Ｂ０とが通話中のときに、端末Ｂ０が端末Ａ１をコールパーク保留をする場合（着保留）について図４の左側を参照して説明したが、端末Ａ１が端末Ｂ０をコールパーク保留をする場合（発保留）については、その動作を図４の右側に示す。この発保留において、着保留と同様の処理については、同じステップの番号を付して、適宜説明を省略する。

次に、端末Ｂ１が端末Ａ１との通話を切断する動作を説明する（ステップＳ４５１〜Ｓ４５８）。
端末Ｂ１は、端末Ａ１との通信を切断することを意味するＢＹＥメッセージを、ＣＡ２０に送信する（ステップＳ４５１）
ＢＹＥメッセージを受信すると、ＣＡ２０は、端末Ｂ１が属するコールグループ＃２の全ての端末に対して、呼状態（ＢＹＥ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４５２）。このＮＯＴＩＦＹ信号には、端末のランプ制御に関する情報が含まれており、受信したＮＯＴＩＦＹ信号に基づいて、コールグループ＃２の端末は、自身のランプを点灯制御を行う。
コールグループ＃２の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４５３）。

また、ＣＡ２０は、端末Ａ１が属するコールグループ＃１の全ての端末に対して、呼状態（ＢＹＥ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知し（ステップＳ４５４）、端末Ａ１と端末Ｂ１との通信を切断することを意味するＢＹＥメッセージを、端末Ａ１に転送する（ステップＳ４５５）。

コールグループ＃１の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４５６）。また、端末Ａ１は、ＣＡ２０からＢＹＥメッセージを受信すると、このＢＹＥ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ４５７）。

２００ＯＫレスポンスメッセージを端末Ａ１から受信すると、ＣＡ２０は、受信した２００ＯＫレスポンスメッセージを端末Ｂ１に転送する（ステップＳ４５８）。
これにより、端末Ａ１と端末Ｂ１との通信は切断される。

なお、上述したように端末Ａ１と端末Ｂ１とが通話中のときに、端末Ｂ１が端末Ａ１との通信を切断にする場合（着切断）について図４の左側を参照して説明したが、端末Ａ１が端末Ｂ１との通信を切断する場合（発切断）については、その動作を図４の右側に示す。この発切断において、着切断と同様の処理については、同じステップの番号を付して、適宜説明を省略する。

このように、本実施の形態によれば、ＳＩＰプロトコルを用い、ＰＢＸ等のユーザ装置を不要とすることにより、相互接続性を高めることが可能となる。結果として、使い勝手のよいコールパークサービスの提供が可能となる。
また、本実施の形態によれば、ユーザ設備に制御装置が不要となるので、ＩＰ電話端末のみでコールパークサービスを提供することが可能となる。

次に、本実施の形態に係るコールパークサービスシステムで提供されるコールパークサービスについて説明する。コールパークサービスは、通話中状態通知機能とランプ番号通知機能の２種類の通知機能を有する。それぞれについて、以下に説明する。

［通話中状態通知機能］
コールパークサービスでは、同一コールパークグループ内の端末に対して、各端末の呼状態を付属するランプを用いてユーザに通知することができる。ユーザに対して通知することができる状態は、通話中（ＢＵＳＹ）、保留中（ＨＯＬＤ）、回線空き（ＢＹＥ）の３状態である。ユーザは、契約時に通話中状態通知機能を使用するか否かを選択することができ、ＣＡ２０は、契約状態に応じて「通話中状態通知機能あり」または「通話中状態通知機能なし」の何れか一方の動作を行う。それぞれの動作は次の通りである。
なお、コールパークグループとは、グルーピングされたＩＰ−ＶＰＮユーザ番号の集合を意味する。

「通話中状態通知機能なし」の場合は、通話中呼に対してコールパーク保留を起動した端末である保留端末と、通話中呼に対してコールパーク保留を起動された端末である被保留端末との間にコールパーク保留が成功したときに、保留端末の属するコールパークグループに対してＮＯＴＩＦＹ信号で呼状態（ＨＯＬＤ）、呼情報、呼に対応するランプ番号を通知する。
また、コールパークグループ内に存在する保留状態呼に対して保留解除を起動した端末である代理応答端末によってピックアップが成功したときに、代理応答端末の属するコールパークグループ（保留端末と同一のコールパークグループ）に対してＮＯＴＩＦＹ信号にて呼状態（ＢＵＳＹ）、呼情報、呼に対するランプ番号を通知する。
また、呼切断時に、発側コールパークグループ、着側コールパークグループそれぞれに対してＮＯＴＩＦＹ信号で呼状態（ＢＹＥ）、呼情報、呼に対するランプ番号を通知する。

「通話中状態通知機能あり」の場合は、発端末と着端末との呼が確立したときに、発側コールパークグループ、着側コールパークグループそれぞれに対して呼状態（ＢＵＳＹ）、呼情報、呼に対応するランプ番号を通知する。保留時、保留解除時、呼切断時のＮＯＴＩＦＹ信号の送信動作については、通話中状態通知なしの場合と同様である。

［ランプ番号通知機能］
「通話中推移時」、「保留起動時」、「保留解除時」に、電話端末からランプ番号を示す独自ヘッダ（Ｐ−Ｎ−ＬｏｃａｔｅＩｎｆｏ）が付与される場合、ＣＡ２０でそのヘッダ情報をＮＯＴＩＦＹ信号に付加し、コールパークグループに対してランプ番号を通知する機能を有する。
「通話中状態通知機能なし」と「通話中状態通知機能あり」それぞれの場合の動作について、以下に説明する。

まず、「通話中状態通知機能なし」の場合について説明する。
「通話中推移時」は、発端末からのｉｎｉｔｉａｌ ＩＮＶＩＴＥに付与することができるランプ番号を通知する独自ヘッダの有無、付与されているランプ番号によらず、発側コールパークグループに対してＮＯＴＩＦＹ信号は送信されない。また、着側端末からのｉｎｉｔｉａｌ ＩＮＶＩＴＥに対する２００ＯＫのランプ番号を通知する独自ヘッダの有無、付与されているランプ番号によらず、着側コールパークグループに対してＮＯＴＩＦＹ信号は送信されない。

「保留起動時」は、保留端末からのＩＮＶＩＴＥ（ＨＯＬＤ）リクエストにランプ番号を通知する独自ヘッダが付与された場合、保留端末と同一コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループで既に使用中の場合、ＣＡ２０は、ＩＮＶＩＴＥ（ＨＯＬＤ）リクエストに対してエラーレスポンス（４０３）を送信する。

「保留解除時」は、代理応答端末からのＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストにランプ番号を通知する独自ヘッダが付与された場合、代理応答端末と同一コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループの保留起動時に決定されたランプ番号以外の場合、ＣＡ２０はＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストに対してエラーレスポンス（４０３）を送信する。

次に、「通話中状態通知機能あり」の場合について説明する。
「通話中推移時」は、発端末からのｉｎｉｔｉａｌ ＩＮＶＩＴＥにランプ番号を通知する独自ヘッダが付与された場合、発側コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。着端末からのｉｎｉｔｉａｌ ＩＮＶＩＴＥに対する２００ＯＫにランプ番号を通知する独自ヘッダが付与された場合、着側コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループで既に使用中の場合、ＣＡ２０で空いているランプ番号を通知する。

「保留起動時」は、保留端末からのＩＮＶＩＴＥ（ＨＯＬＤ）にランプ番号を通知する独自ヘッダが付与された場合、保留端末と同一コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループの通話中推移時に決定されたランプ番号以外の場合、ＣＡ２０は、ＩＮＶＩＴＥ（ＨＯＬＤ）リクエストに対してエラーレスポンス（４０３）を送信する。

「保留解除時」は、代理応答端末からのＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストにランプ番号を通知する独自ヘッダが付与された場合、代理応答端末と同一コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループの保留起動時に決定されたランプ番号以外の場合、ＣＡ２０は、ＩＮＶＩＴＥ（ＵＮＨＯＬＤ）に対してエラーレスポンス（４０３）を送信する。

ここで、ＣＡ２０は、端末間の通信にランプを割り当て、このランプ単位で通信制御を行っており、コールパークグループ単位でランプ番号の使用状態を保持している。
ランプ番号を空き状態から使用中に変更するのは、端末から最初に独自ヘッダを受信し、かつ、そのランプ番号がＣＡ２０で空き状態となっている場合であり、使用中から空き状態に変更されるのは、通話中状態通知ありの場合はＮＯＴＩＦＹ（ＢＹＥ）信号を送信したとき、通話中状態通知なしの場合は保留解除ＮＯＴＩＦＹ（ＢＵＳＹ）信号送信時である。ＣＡ２０は、１つのコールパークグループ当たり最大５０個までランプ番号を保持することができる。通話中状態通知ありで、ｉｎｉｔｉａｌ ＩＮＶＩＴＥまたは２００ＯＫ受信時に端末にて独自ヘッダが付与されないか、５０個全てのランプ番号が使用中であるか、ＣＡ２０にて管理できるランプ番号以外の値が設定された場合は、端末に対して送信するランプ番号はＮＵＬＬとなる。

上述した通話中状態通知機能およびランプ番号通知機能のＣＡ２０における動作について、図５〜８を参照して説明する。
まず、図５を参照して、「通話中状態通知あり」の設定で、同一のパークグループ内に発着行う場合の状態通知の動作について説明する。図５は、「通話中状態通知あり」の設定で、同一のパークグループ内に発着行う場合の状態通知の動作を説明する図である。

何れのランプも使用していない状態のときに（ステップＳ５０１）、ＩＮＶＩＴＥリクエストを受信すると、ＣＡ２０は、１番のランプを通知する独自ヘッダが付与されている場合は１番のランプを保持し（ステップＳ５０２）、１番のランプを通知する独自ヘッダが付与されたが１番のランプが使用中の場合は未使用のランプ（２番のランプ）を保持し（ステップＳ５０３）、独自ヘッダが付与されていない場合はランプを未使用状態とする（ステップＳ５０４）。

１番のランプを保持した後、２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ランプ番号に関わらず１番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５０５）。ここで、１番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。
２番のランプを保持した後、２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ランプ番号に関わらず２番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５０６）。ここで、２番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。

ランプ未使用状態において、２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、１番のランプを通知する独自ヘッダが付与された場合はステップＳ５０５の処理に進み、１番のランプを通知する独自ヘッダが付与されたが１番のランプが使用中の場合はステップＳ５０６の処理に進み、独自ヘッダが付与されていない場合はランプ番号をＮＵＬＬとするＮＯＴＩＦＹ信号を同一のコールパークグループの端末に送信する（ステップＳ５０７）。このステップＳ５０７において、ＮＵＬＬ以外のランプに関する通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。

１番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を送信後、保留端末からＩＮＶＩＴＥ（ＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、１番のランプを通知する独自ヘッダが付与されている場合は、１番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５０８）。ここで、１番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させず、その通知の送信元に対して４０３信号を送信する。

２番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を送信後、保留端末からＩＮＶＩＴＥ（ＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、２番のランプを通知する独自ヘッダが付与されている場合は、２番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５０９）。ここで、２番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させず、その通知の送信元に対して４０３信号を送信する。

ランプ番号をＮＵＬＬとするＮＯＴＩＦＹ信号を送信後、保留端末から１番のランプを通知する独自ヘッダが付与されたＩＮＶＩＴＥ（ＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、ステップＳ５０９の処理に進む。

１番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を送信後、代理応答端末からＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、１番のランプを通知する独自ヘッダが付与されている場合は、１番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５１０）。ここで、１番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させず、その通知の送信元に対して４０３信号を送信する。

２番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を送信後、代理応答端末からＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、２番のランプを通知する独自ヘッダが付与されている場合は、２番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５１１）。ここで、２番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させず、その通知の送信元に対して４０３信号を送信する。

呼切断するＢＹＥ信号を受信すると、ＣＡ２０は、同一のコールパークグループの端末に対してＮＯＴＩＦＹ信号で呼状態（ＢＹＥ）、呼情報、呼に対するランプ番号を通知する（ステップＳ５１２）。

次に、図６を参照して、「通話中状態通知あり」の設定で、発着が別のパークグループにおいて発側パークグループ内への状態通知の動作について説明する。図６は、「通話中状態通知あり」の設定で、発着が別のパークグループにおいて発側パークグループ内への状態通知の動作について説明する図である。
なお、図６において、ステップＳ６０４とＳ６０７以外のステップは、対応する図５のステップとそれぞれ同等である。したがって、図５に示すステップと同等のステップには、下二桁のステップ番号に同じ番号を付して、適宜説明を省略する。

ステップＳ６０４の状態、すなわちランプ未使用状態において、独自ヘッダが付与されていない２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ランプ番号をＮＵＬＬとするＮＯＴＩＦＹ信号を発側のコールパークグループに送信する（ステップＳ６０７）。このステップＳ６０７において、ＮＵＬＬ以外のランプに関する通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。

次に、図７を参照して、「通話中状態通知あり」の設定で、発着が別のパークグループにおいて着側パークグループ内への状態通知の動作について説明する。図７は、「通話中状態通知あり」の設定で、発着が別のパークグループにおいて着側パークグループ内への状態通知の動作について説明する図である。
なお、図７において、ステップＳ７０８〜Ｓ７１２は、対応する図５のステップＳ５０８〜５１２とそれぞれ同等である。したがって、図５に示すステップと同等のステップには、下二桁のステップ番号に同じ番号を付して、適宜説明を省略する。

何れのランプも使用していない状態のときに（ステップＳ７０１）、ＩＮＶＩＴＥリクエストを受信すると、ＣＡ２０は、独自ヘッダの有無や通知されたランプの番号に関わらず１番のランプを保持する（ステップＳ７０２）。

１番のランプを保持した状態において、２００ＯＫレスポンスメッセージを受信し、１番のランプを通知する独自ヘッダが付与された場合、ＣＡ２０は、１番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、着側のコールパークグループに送信する（ステップＳ７０５）。ここで、１番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。

また、１番のランプを保持した状態において、２００ＯＫレスポンスメッセージを受信し、１番のランプを通知する独自ヘッダが付与されたが１番のランプが使用中の場合、ＣＡ２０は、２番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、着側のコールパークグループに送信する（ステップＳ７０６）。ここで、２番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。

また、１番のランプを保持した状態において、２００ＯＫレスポンスメッセージを受信し、独自ヘッダが付与されていない場合、ＣＡ２０は、ランプ番号をＮＵＬＬとするＮＯＴＩＦＹ信号を、着側のコールパークグループに送信する（ステップＳ７０７）。このステップＳ７０７において、ＮＵＬＬ以外のランプに関する通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。

次に、図８を参照して、「通話中状態通知なし」の設定で、保留端末と同一のパークグループ内への状態通知の動作について説明する。図８は、「通話中状態通知なし」の設定で、保留端末と同一のパークグループ内への状態通知の動作を説明する図である。
なお、図８において、ステップＳ８０８，Ｓ８１０，Ｓ８１２は、対応する図５のステップとそれぞれ同等である。したがって、図５に示すステップと同等のステップには、下二桁のステップ番号に同じ番号を付して、適宜説明を省略する。

何れのランプも使用していない状態のときに（ステップＳ８０１）、ＩＮＶＩＴＥリクエストを受信すると、ＣＡ２０は、独自ヘッダの有無や通知されたランプの番号に関わらず、ランプを未使用の状態にする（ステップＳ８０２）。

ランプ未使用の状態において、２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、通知されたランプ番号に関わらず、ランプを未使用の状態にする（ステップＳ８０５）。

次に、図９〜４１を参照して、本実施の形態に係るコールパークサービスシステムの各動作について説明する。
前述した図４および図９，１０に示す処理は正常処理を、図１１〜３４は準正常処理を、図３５〜４１は異常処理を示す。ここで、準正常処理とは、正常処理の中で予想される異常状態が発生したときの対処法を意味する。

なお、図９〜４１では、電話端末１０からなる端末Ａ０および端末Ａ１とが同じコールグループ（コールグループ＃１）に属し、電話端末１０からなる端末Ｂ０および端末Ｂ１とが同じコールグループ（コールグループ＃２）に属するシステムを例に説明する。ここで、端末Ａ０，Ａ１側を発信者の端末が属する発側、端末Ｂ０，Ｂ１側を着信者の端末が属する着側とする。
また、発信者とは、ある呼を生成したユーザのことを意味する。ＳＩＰ信号上ではｉｎｉｔｉａｌ ＩＮＶＩＴＥを生成した端末を使用しているユーザのことを意味する。
また、着信者とは、ある呼に対して始めに応答したユーザのことを意味する。ＳＩＰ信号上ではｉｎｉｔｉａｌ ＩＮＶＩＴＥに対して２００ＯＫレスポンスを送信した端末を使用しているユーザのことを意味する。

まず、図９を参照して、通話中状態通知なしの場合の本実施の形態に係るコールパークサービスシステムの動作について説明する。図９は、通話中状態通知なしの場合の動作を示すシーケンス図である。
なお、図９において、保留動作と切断動作は、図４に示す動作（ステップＳ４２１〜Ｓ４５８）と同等である。したがって、保留動作と切断動作については適宜説明を省略する。

図９に示す通話中状態通知なしの場合は、通話中状態が表示されない、すなわち、図４で示したステップＳ４１０，４１１〜４１４のＮＯＴＩＦＹ（ＢＵＳＹ）信号に対応する処理が行われない。これにより、本実施の形態において、通話中状態通知なしに設定された場合は、通話中の状態が通知されない。

次に、図１０を参照して、ＲＥＧＩＳＴＥＲ端末への状態通知について説明する。図１０は、ＲＥＧＩＳＴＥＲ端末への状態通知を示すシーケンス図である。
端末Ａ０と端末Ｂ０とが通話中（ｄｉａｌｏｇ１／ラン ＃１）であり（ステップＳ１００１）、端末Ａ１と端末Ｂ１とが保留中（ｄｉａｌｏｇ２／ラン ＃２）である場合に、端末Ｂ２（ＲＥＧＩＳＴＥＲ端末）が端末登録をする旨のＲＥＧＩＳＴＥＲ信号をＣＡ２０に送信する（ステップＳ１００３）。
例えば、端末Ｂ２が端末登録が認可されていない等のリクエストエラー応答として４０１Ｕｎａｕｔｈｏｒｉｚｅｄ信号がＣＡ２０から返信されると（ステップＳ１００４）、端末Ｂ２は、再度ＲＥＧＩＳＴＥＲ信号をＣＡ２０に送信する（ステップＳ１００５）。

ＲＥＧＩＳＴＥＲ信号を受信し、端末Ｂ２の端末登録を認可すると、ＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ２に送信する（ステップＳ１００６）。
また、ＣＡ２０は、端末Ｂ２と同一のコールパークグループに属する端末Ｂ０および端末Ｂ１の状態を通知するＮＯＴＩＦＹ信号を、端末Ｂ２に送信する（ステップＳ１００７，Ｓ１００８）。
ＮＯＴＩＦＹ信号を受信すると、端末Ｂ２は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１００９）。

このように、本実施の形態では、位置登録をした端末に対して同一コールパークグループ内に属する他の端末の状態が通知される。

次に、図１１を参照して、保留前保留ＩＮＶＩＴＥのすれ違い動作（発側保留勝ち）について説明する。図１１は、保留前保留ＩＮＶＩＴＥのすれ違い動作（発側保留勝ち）のシーケンス図である。
端末Ａ１と端末Ｂ０とが通話中のときに（ステップＳ１１０１）、端末Ａ１が端末Ｂ０を保留にするＩＮＶＩＴＥリクエストをＣＡ２０に送信した後に（ステップＳ１１０２）、端末Ｂ０が端末Ａ１を保留にするＩＮＶＩＴＥリクエストがＣＡ２０に送信されると（ステップＳ１１０３）、ＣＡ２０は、端末Ｂ０のＩＮＶＩＴＥリクエストに対して、５００ Ｓｅｒｖｅｒ Ｉｎｔｅｒｎａｌ Ｅｒｒｏｒ信号（以下、５００信号という）を端末Ｂ０に送信する（ステップＳ１１０４）。

５００信号を受信すると、端末Ｂ０は、５００信号の受信を確認したことを示すＡＣＫメッセージをＣＡ２０に送信し（ステップＳ１１０５）、ＩＮＶＩＴＥリクエストをエラーしたことを示す４９１信号を、ＣＡ２０に送信する（ステップＳ１１０６）。

４９１信号を受信したＣＡ２０は、４９１信号を端末Ａ１に転送し（ステップＳ１１０７）、４９１信号を受信したことを示すＡＣＫメッセージを端末Ｂ０に送信する（ステップＳ１１０８）。

４９１信号を受信した端末Ａ１は、４９１信号を受信したことを示すＡＣＫメッセージをＣＡ２０に送信し（ステップＳ１１０９）、再度、ＩＮＶＩＴＥリクエストをＣＡ２０に送信する（ステップＳ１１０８）。
すると、図４で示した発保留側のステップＳ４２２〜Ｓ４２９の処理と同等の処理が行われ（ステップＳ１１１２〜Ｓ１１１９）、端末Ａ１と端末Ｂ０とはコールパーク保留状態となる。

このように、本実施の形態によれば、ＩＮＶＩＴＥリクエストがすれ違った場合は、最初にＣＡ２０に到達したＩＮＶＩＴＥリクエストが優先される。

次に、図１２を参照して、保留前保留ＩＮＶＩＴＥのすれ違い動作（着側保留勝ち）について説明する。図１２は、保留前保留ＩＮＶＩＴＥのすれ違い動作（着側保留勝ち）のシーケンス図である。
端末Ａ１と端末Ｂ０とが通話中のときに（ステップＳ１２０１）、端末Ｂ０が端末Ａ１に、また端末Ａ１が端末Ｂ０に、それぞれＩＮＶＩＴＥリクエストをＣＡ２０に送信したが（ステップＳ１２０２、１２０３）、端末Ｂ０のＩＮＶＩＴＥリクエストが先にＣＡ２０に到達すると、ＣＡ２０は、端末Ｂ０のＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ１２０４）。

ＩＮＶＩＴＥリクエストを送信後にＣＡ２０から端末Ｂ０からのＩＮＶＩＴＥリクエストが転送された端末Ａ１は、ＩＮＶＩＴＥリクエストをエラーしたことを示す４９１信号を、ＣＡ２０に送信する（ステップＳ１２０５）。

４９１信号を受信したＣＡ２０は、４９１信号を端末Ｂ０に転送し（ステップＳ１２０６）、４９１信号を受信したことを示すＡＣＫメッセージを端末Ａ１に送信する（ステップＳ１２０７）。

４９１信号を受信した端末Ｂ０は、４９１信号を受信したことを示すＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１２０８）。
ＡＣＫメッセージを受信したＣＡ２０は、５００信号を端末Ａ１に送信する（ステップＳ１２０９）。
５００信号を受信した端末Ａ１は、４９１信号を受信したことを示すＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１２１０）。

ＡＣＫメッセージを送信後、端末Ｂ０は、再度、ＩＮＶＩＴＥリクエストをＣＡ２０に送信する（ステップＳ１２１１）。
すると、図４で示した着保留側のステップＳ４２２〜Ｓ４２９の処理と同等の処理が行われ（ステップＳ１２１２〜Ｓ１２１９）、端末Ａ１と端末Ｂ０とはコールパーク保留状態となる。

このように、本実施の形態によれば、ＩＮＶＩＴＥリクエストがすれ違った場合は、最初にＣＡ２０に到達したＩＮＶＩＴＥリクエストが優先される。

次に、図１３を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作について説明する。図１３は、代理応答端末からの保留解除ＩＮＶＩＴＥと保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１３０１）、代理応答端末となる端末Ｂ１から保留解除（ＵＮＨＯＬＤ）を意味するＩＮＶＩＴＥリクエストを受信すると（ステップＳ１３０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ１３０３）。

ＩＮＶＩＴＥリクエストの転送後、保留端末である端末Ｂ０から生存確認を示すｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１３０４）、ＣＡ２０は、既に端末Ｂ１から保留解除のＩＮＶＩＴＥリクエストを受信しているので、５００信号を端末Ｂ０に送信する（ステップＳ１３０５）。
５００信号を受信した端末Ｂ０は、ＡＣＫメッセージをＣＡ２０に返信する（ステップＳ１３０６）。

ＡＣＫメッセージの受信後は、図４で示した着保留側のステップＳ４３２〜Ｓ４４０の処理と同等の処理が行われ（ステップＳ１３０７〜Ｓ１３１５）、端末Ａ１と端末Ｂ１との通話が行われる。

端末Ｂ１は、保留解除後、すぐにｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストをＣＡ２０に送信する（ステップＳ１３１６）。
ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると、ＣＡ２０は、そのリクエストを端末Ａ１に転送する（ステップＳ１３１７）。
ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると、端末Ａ１は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１３１８）。
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、そのメッセージを端末Ｂ１に送信する（ステップＳ１３１９）。
２００ＯＫレスポンスメッセージを受信すると、端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１３２０）。
ＡＣＫメッセージを受信すると、ＣＡ２０は、そのＡＣＫメッセージを端末Ａ１に転送する（ステップＳ１３２１）。

このように本実施の形態では、代理応答処理は、保留端末からの生存確認よりも優先される。

次に、図１４を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと保留端末からのＢＹＥとのすれ違い動作について説明する。図１４は、代理応答端末からの保留解除ＩＮＶＩＴＥと保留端末からのＢＹＥとのすれ違い動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１４０１）、代理応答端末となる端末Ｂ１から保留解除を意味するＩＮＶＩＴＥリクエストを受信すると（ステップＳ１４０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ１４０３）。

しかしながら、ＩＮＶＩＴＥリクエストの転送後、保留端末である端末Ｂ０から呼切断要求を示すＢＹＥメッセージを受信すると（ステップＳ１４０４）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ１４０５、Ｓ１４０７）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ１４０６，Ｓ１４０８）。

２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１にＢＹＥメッセージを転送し（ステップＳ１４０９）、ＩＮＶＩＴＥリクエストを送信してきた端末Ｂ１に５００信号を送信する（ステップＳ１４１０）。

ＢＹＥメッセージを受信すると、端末Ａ１は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１４１１）。
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、その２００ＯＫレスポンスメッセージを端末Ｂ０に転送する（ステップＳ１４１２）。
５００信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１４１３）。

このように、本実施の形態によれば、端末からの呼切断要求は、他の処理よりも優先される。

次に、図１５を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い（保留解除勝ち／リフレッシュ更新時間外）の動作について説明する。図１５は、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い（保留解除勝ち／リフレッシュ更新時間外）の動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１５０１）、代理応答端末となる端末Ｂ１から保留解除を意味するＩＮＶＩＴＥリクエストを受信すると（ステップＳ１５０２）、ＣＡ２０は、リフレッシュ時間の数秒前は、ＵＮＨＯＬＤの再送を促すために、４９１信号を端末Ｂ１に送信する（ステップＳ１５０３）。

ここで、保留端末である端末Ａ１から生存確認を示すｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１５０４）、ＣＡ２０は、そのリクエストを端末Ｂ０に転送する（ステップＳ１５０５）。

４９１信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信し（ステップＳ１５０６）、ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信した端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１５０７）。

２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、そのメッセージを端末Ａ１に転送する（ステップＳ１５０８）。
２００ＯＫレスポンスメッセージを受信した端末Ａ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１５０９）。
ＡＣＫメッセージを受信したＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ１５１０）。

ＡＣＫメッセージの転送後は、図４で示した着保留側のステップＳ４３０〜Ｓ４４０の処理と同等の処理が行われ（ステップＳ１５１１〜Ｓ１５２１）、端末Ａ１と端末Ｂ１との通話が行われる。

このように、本実施の形態によれば、保留元以外の端末からの生存確認は、代理応答要求よりも優先される。

次に、図１６を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い（保留解除勝ち／リフレッシュ更新時間外）動作について説明する。図１６は、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い（保留解除勝ち／リフレッシュ更新時間外）動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１６０１）、代理応答端末となる端末Ｂ１から保留解除を意味するＩＮＶＩＴＥリクエストを受信すると（ステップＳ１６０２）、ＣＡ２０は、そのリクエストを端末Ａ１に転送する（ステップＳ１６０３）。

ここで、保留端末である端末Ａ１から生存確認を示すｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１６０４）、ＣＡ２０は、端末Ｂ１からのＩＮＶＩＴＥリクエストを透過して、ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストに対して、５００信号を端末Ａ１に送信する（ステップＳ１６０５）。

５００信号を受信した端末Ａ１は、ＡＣＫメッセージをＣＡ２０に送信し（ステップＳ１６０６）、ＵＮＨＯＬＤのＩＮＶＩＴＥリクエストに対する４９１信号をＣＡ２０に送信する（ステップＳ１６０７）。

４９１信号を受信したＣＡ２０は、その４９１信号を端末Ｂ１に転送し（ステップＳ１６０８）、ＡＣＫメッセージを端末Ａ１に送信する（ステップＳ１６０９）。
４９１信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１６１０）。
すると、端末Ａ１と端末Ｂ０とがコールパーク保留が維持される（ステップＳ１６１１）。

このように、本実施の形態によれば、保留元以外の端末からの生存確認は、代理応答要求よりも優先される。

次に、図１７を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅ ＩＮＶＩＴＥとのすれ違い（ｋｅｅｐａｌｉｖｅ勝ち）動作について説明する。図１７は、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅ ＩＮＶＩＴＥとのすれ違い（ｋｅｅｐａｌｉｖｅ勝ち）動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１７０１）、保留端末である端末Ａ１からｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１７０２）、ＣＡ２０は、そのリクエストを端末Ｂ０に転送する（ステップＳ１７０４）。このｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストの転送とすれ違って、端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ１７０３）、ＣＡ２０は、ＵＮＨＯＬＤの再送を促すため４９１信号を端末Ｂ１に送信する（ステップＳ１７０５）。

一方、ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信した端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１７０６）。
２００ＯＫレスポンスメッセージを受信したＣＡ２０は、そのメッセージを端末Ａ１に転送する（ステップＳ１７０７）。

４９１信号を受信すると、端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１７０８）。
２００ＯＫレスポンスメッセージを受信すると、端末Ａ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１７０９）。
ＡＣＫメッセージを受信すると、ＣＡ２０は、そのメッセージを端末Ｂ０に転送する（ステップＳ１７０６）。

ＡＣＫメッセージの転送後は、図４で示した着保留側のステップＳ４３０〜Ｓ４４０の処理と同等の処理が行われ（ステップＳ１７１１〜Ｓ１７２１）、端末Ａ１と端末Ｂ１との通話が行われる。

このように、本実施の形態によれば、保留元以外の端末からの生存確認は、代理応答要求よりも優先される。

次に、図１８を参照して、被保留端末からのＡＣＫ（ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ）前の代理応答端末からの保留解除ＩＮＶＩＴＥ送信動作について説明する。図１８は、被保留端末からのＡＣＫ（ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ）前の代理応答端末からの保留解除ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１８０１）、保留端末である端末Ａ１からｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１８０２）、ＣＡ２０は、そのリクエストを端末Ｂ０に転送する（ステップＳ１８０３）。

ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信した端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１８０４）。
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、そのメッセージを端末Ａ１に転送する（ステップＳ１８０５）。

ここで、端末Ａ１からのＡＣＫメッセージの受信前に、端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ１８０６）、ＣＡ２０は、端末Ａ１からのＡＣＫメッセージの受信後に（ステップＳ１８０７）、ＵＮＨＯＬＤの再送を促すための４９１信号を端末Ｂ１に送信する（ステップＳ１８０８）。また、ＣＡ２０は、端末Ａ１から受信したＡＣＫメッセージを、端末Ｂ０に転送する（ステップＳ１８０９）。
４９１信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１８１０）。

ＡＣＫメッセージの転送後は、図４で示した着保留側のステップＳ４３０〜Ｓ４４０の処理と同等の処理が行われ（ステップＳ１８１１〜Ｓ１８２１）、端末Ａ１と端末Ｂ１との通話が行われる。

このように、本実施の形態によれば、保留元以外の端末からの生存確認は、代理応答要求よりも優先される。

次に、図１９を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥに対する被保留端末からのエラーレスポンス動作について説明する。図１９は、代理応答端末からの保留解除ＩＮＶＩＴＥに対する被保留端末からのエラーレスポンスを示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１９０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ１９０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ１９０３）。

ここで、端末Ａ１が受信したＩＮＶＩＴＥリクエストに対して、４００ＢａｄＲｅｑｕｅｓｔ信号（以下、４００信号という）をＣＡ２０に送信すると（ステップＳ１９０４）、ＣＡ２０は、４００信号を端末Ｂ１に転送し（ステップＳ１９０５）、ＡＣＫメッセージを端末Ａ１に送信する（ステップＳ１９０６）。
端末Ｂ１からＡＣＫメッセージを受信すると（ステップＳ１９０７）、ＣＡ２０は，端末Ａ１と端末Ｂ０とのコールパーク保留を継続する（ステップＳ１９０８）。

このように、本実施の形態によれば、端末からのエラーレスポンスは、ＣＡ２０を透過して処理される。

次に、図２０を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのＢＹＥとのすれ違い動作について説明する。図２０は、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのＢＹＥとのすれ違い動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２００１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２００２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２００３）。

このＩＮＶＩＴＥリクエストの転送とすれ違って、端末Ａ１からＢＹＥメッセージを受信すると（ステップＳ２００４）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２００５、Ｓ２００７）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２００６，２００８）。

２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ＩＮＶＩＴＥリクエストを送信してきた端末Ｂ１に５００信号を送信し（ステップＳ２００９）、端末Ｂ０にＢＹＥメッセージを転送する（ステップＳ２０１０）。

ＢＹＥメッセージを受信すると、端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ２０１１）。
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、その２００ＯＫレスポンスメッセージを端末Ａ１に転送する（ステップＳ２０１２）。
５００信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ２０１３）。

このように、本実施の形態によれば、端末からの呼切断要求は、他の処理よりも優先される。

次に、図２１を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥ送信後に代理応答端末からのＣＡＮＣＥＬ送信動作について説明する。図２１は、代理応答端末からの保留解除ＩＮＶＩＴＥ送信後に代理応答端末からのＣＡＮＣＥＬ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２１０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２１０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２１０３）。

ここで、端末Ｂ１からＣＡＮＣＥＬ信号を受信すると（ステップＳ２１０４）、ＣＡ２０は、端末Ｂ１が属するコールグループ＃２に含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知し（ステップＳ２１０５）、ＣＡＮＣＥＬ信号に対する２００ＯＫレスポンスメッセージを端末Ｂ１に送信する（ステップＳ２１０６）。また、ＣＡ２０は、コールグループ＃１に含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２１０８）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２１０７，２１０９）。

コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１と端末Ｂ０にＢＹＥメッセージを送信する（ステップＳ２１１０，２１１１）。
端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２１１２）、ＣＡ２０は、４８７信号を端末Ｂ１に送信する（ステップＳ２１１３）。

ＢＹＥメッセージを受信すると、端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ２１１４）。
４８７信号を受信すると、端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ２１１５）。

このように、本実施の形態によれば、端末からの呼切断要求は、他の処理よりも優先される。

次に、図２２を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥ送信後に代理応答端末からのＢＹＥ送信動作について説明する。図２２は、代理応答端末からの保留解除ＩＮＶＩＴＥ送信後に代理応答端末からのＢＹＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２２０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２２０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２２０３）。

ここで、端末Ｂ１からＣＡＮＣＥＬ信号を受信すると（ステップＳ２２０４）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２２０５、Ｓ２２０７）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２２０６，Ｓ２２０８）。

コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１と端末Ｂ０にＢＹＥメッセージを送信する（ステップＳ２２０９，Ｓ２２１０）。
端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２２１１）、ＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ１に送信する（ステップＳ２２１２）。
また、ＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ０から受信する（ステップＳ２１１３）。

このように、本実施の形態によれば、端末からの呼切断要求は、他の処理よりも優先される。

次に、図２３を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥ送信中の強制呼解放動作について説明する。図２３は、代理応答端末からの保留解除ＩＮＶＩＴＥ送信中の強制呼解放動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２３０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２３０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２３０３）。

ここで、呼解放が強制的に要求される（ＦＳＴ）と（ステップＳ２３０４）、ＣＡ２０は、コールグループ＃１に含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２３０５）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したコールグループ＃１の端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２３０６）。また、ＣＡ２０は、ＢＹＥメッセージを端末Ａ１に送信し（ステップＳ２３０７）、２００ＯＫレスポンスメッセージを端末Ａ１から受信する（ステップＳ２３０９）。

また、ＣＡ２０は、コールグループ＃２に含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２３０８）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したコールグループ＃２の端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２３１０）。
また、ＣＡ２０は、ＢＹＥメッセージを端末Ｂ０に送信し（ステップＳ２３１１）、５００信号を端末Ｂ１に送信する（ステップＳ２３０９）。すると、ＣＡ２０は、端末Ｂ０から２００ＯＫレスポンスメッセージを受信し（ステップＳ２３１３）、端末Ｂ１からＡＣＫメッセージを受信する（ステップＳ２３１４）。

これにより、本実施の形態では、保守者等による呼解放要求は、他の処理よりも優先して処理される。

次に、図２４を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥ送信中の系切替動作について説明する。図２４は、代理応答端末からの保留解除ＩＮＶＩＴＥ送信中の系切替動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２４０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２４０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２４０３）。

ここで、系の切替が要求されると（ステップＳ２４０４）、ＣＡ２０は、端末Ａ１と端末Ｂ０とのコールパーク保留を継続する（ステップＳ２４０５）。

これにより、本実施の形態では、安定呼に対するシステム系の切替に対しては、その呼状態が保持される。

次に、図２５を参照して、代理応答端末からのＡＣＫ（保留解除前ＩＮＶＩＴＥ）前の保留端末からのＢＹＥ送信動作について説明する。図２５は、代理応答端末からのＡＣＫ（保留解除前ＩＮＶＩＴＥ）前の保留端末からのＢＹＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２５０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２５０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２５０３）。

端末Ａ１は、応答したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２５０４）。２００ＯＫレスポンスメッセージを受信したＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ１に転送する（ステップＳ２５０５）。
ここで、端末Ｂ０からＢＹＥメッセージを受信すると（ステップＳ２５０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２５０７、Ｓ２５０９）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２５０８，Ｓ２５１０）。

コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１と端末Ｂ１にＢＹＥメッセージを送信する（ステップＳ２５１１，Ｓ２５１２）。
ＢＹＥメッセージ対して２００ＯＫレスポンスメッセージを端末Ａ１から受信すると（ステップＳ２５１３）、ＣＡ２０は、そのメッセージを端末Ｂ０に転送する（ステップＳ２５１４）。また、ＣＡ２０は、端末Ｂ１から２００ＯＫレスポンスメッセージを受信する（ステップＳ２５１５）。

これにより、本実施の形態では、端末からの呼切断要求が他の処理よりも優先されることとなる。

次に、図２６を参照して、代理応答端末からのＡＣＫ（保留解除信号ＩＮＶＩＴＥ）前の保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ送信動作について説明する。図２６は、代理応答端末からのＡＣＫ（保留解除信号ＩＮＶＩＴＥ）前の保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２６０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２６０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２６０３）。

ＩＮＶＩＴＥリクエストの転送後、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２６０４）、ＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ２６０５）。
ここで、端末Ｂ０からｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ２６０６）、ＣＡ２０は、既に端末Ｂ１から保留解除のＩＮＶＩＴＥリクエストを受信しているので、５００信号を端末Ｂ０に送信する（ステップＳ２６０７）。
５００信号を受信した端末Ｂ０は、ＡＣＫメッセージをＣＡ２０に返信する（ステップＳ２６０８）。

２００ＯＫレスポンスメッセージに対するＡＣＫメッセージを端末Ｂ１から受信すると（ステップＳ２６０９）、ＣＡ２０は、端末Ｂ１が属するコールグループ＃２の端末に対して、呼状態（ＢＵＳＹ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２６１０）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したコールグループ＃２の端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２６１１）。

ＣＡ２０は、２００ＯＫレスポンスメッセージに対するＡＣＫメッセージを端末Ａ１に送信し（ステップＳ２６１２）、ＢＹＥメッセージを端末Ｂ０に送信し（ステップＳ２６１３）、端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２６１４）、保留を解除して端末Ａ１と端末Ｂ１との間の通話を確立する（ステップＳ２６１５）。
保留の解除後は、図１３で示したステップＳ１３１６〜Ｓ１３２１の処理と同等の処理が行われる（ステップＳ２６１６〜Ｓ２６２１）。

これにより、本実施の形態では、代理応答処理は、保留元端末からの生存確認よりも優先される。

次に、図２７を参照して、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の被保留端末からのＢＹＥ送信動作について説明する。図２７は、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の被保留端末からのＢＹＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２７０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２７０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２７０３）。

ＩＮＶＩＴＥリクエストの転送後、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２７０４）、ＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ２７０５）。
ここで、端末Ａ１からＢＹＥメッセージを受信すると（ステップＳ２７０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２７０７、Ｓ２７０９）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２７０８，Ｓ２７１０）。

コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ｂ０と端末Ｂ１にＢＹＥメッセージを送信する（ステップＳ２７１１，Ｓ２７１２）。
端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２７１３）、ＣＡ２０は、そのメッセージを端末Ａ１に転送する（ステップＳ２７１４）。また、ＣＡ２０は、端末Ｂ１から２００ＯＫレスポンスメッセージを受信する（ステップＳ２７１５）。

これにより、本実施の形態では、端末からの呼切断要求は、他の処理よりも優先されることとなる。

次に、図２８を参照して、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の代理応答端末からのＣＡＮＣＥＬ動作について説明する。図２８は、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の代理応答端末からのＣＡＮＣＥＬ動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２８０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２８０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２８０３）。

ＩＮＶＩＴＥリクエストの転送後、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２８０４）、ＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ２８０５）。
ここで、２００ＯＫレスポンスメッセージとすれ違いで端末Ｂ１からＣＡＮＣＥＬメッセージを受信すると（ステップＳ２８０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２８０７、Ｓ２８０９）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２８０８，Ｓ２８１０）。

コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１，Ｂ０，Ｂ１にＢＹＥメッセージを送信し（ステップＳ２８１１〜Ｓ２８１３）し、それぞれの端末から２００ＯＫレスポンスメッセージを受信する（ステップＳ２８１４〜Ｓ２８１６）。

これにより、本実施の形態では、端末からの呼切断要求は、他の処理よりも優先されることとなる。

次に、図２９を参照して、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の代理応答端末からのＢＹＥ送信動作について説明する。図２９は、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の代理応答端末からのＢＹＥ送信動作を示すシーケンス図である。
なお、図２９において、ステップＳ２９０５とＳ２９１４以外の処理は、対応する図２８で示したステップと同等であるので、対応するステップにはステップ番号の下２桁に同じ番号を付して、適宜説明を省略する。

２００ＯＫレスポンスメッセージとすれ違いで端末Ｂ１からＢＹＥメッセージを受信すると（ステップＳ２９０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２９０７、Ｓ２９０９）。それぞれの端末から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２９０８、Ｓ２９１０）、端末Ａ１，Ｂ０にＢＹＥメッセージを送信し（ステップＳ２９１１，Ｓ２９１２）、それぞれから２００ＯＫレスポンスメッセージを受信し（ステップＳ２９１３，２９１５）、受信したＢＹＥメッセージに対して２００ＯＫレスポンスメッセージを端末Ｂ１に送信する（ステップＳ２９１４）。

これにより、本実施の形態では、端末からの呼切断要求は、他の処理よりも優先されることとなる。

次に、図３０を参照して、ＣＡからの保留端末へのＢＹＥと保留端末からのＢＹＥとのすれ違い動作について説明する。図３０は、ＣＡからの保留端末へのＢＹＥと保留端末からのＢＹＥとのすれ違い動作を示すシーケンス図である。
なお、図３０において、ステップＳ３００１〜３００９の処理は、図４の着保留側に示したステップＳ４２９〜Ｓ４３７と同等であるので、適宜説明を省略する。

端末Ａ１へＡＣＫメッセージを送信後に、端末Ｂ０がＢＹＥメッセージをＣＡ２０に送信し（ステップＳ３０１０）、ＣＡ２０がＢＹＥメッセージを端末Ｂ０に送信して（ステップＳ３０１１）、ＢＹＥメッセージがすれ違ったとする。この場合、相互に２００ＯＫレスポンスメッセージを送信することにより（ステップＳ３０１２，Ｓ３０１３）、端末Ｂ０の呼が切断され、端末Ａ１と端末Ｂ１との通話が行われる（ステップＳ３０１４）。

このように、本実施の形態では、保留元端末に対するＣＡからの呼解放要求は、他の処理よりも優先される。

次に、図３１を参照して、ＣＡからの保留端末へのＢＹＥと保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作について説明する。図３１は、ＣＡからの保留端末へのＢＹＥと保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
なお、図３１において、ステップＳ３１０１〜３１０９の処理は、図４の着保留側に示したステップＳ４２９〜Ｓ４３７と同等であるので、適宜説明を省略する。

端末Ａ１へＡＣＫメッセージを送信後に、端末Ｂ０がｋｅｅｐａｌｉｖｅＩＮＶＩＴＥメッセージをＣＡ２０に送信し（ステップＳ３１１０）、ＣＡ２０がＢＹＥメッセージを端末Ｂ０に送信して（ステップＳ３１１１）、２つのメッセージがすれ違ったとする。この場合、ＣＡ２０は、端末Ｂ０に４００信号を送信する（ステップＳ３１１２）。

４００信号を受信すると、端末Ｂ０は、４００信号に対するＡＣＫメッセージと、ＢＹＥメッセージに対する２００ＯＫレスポンスメッセージとを、ＣＡ２０に送信する（ステップＳ３１１３，３１１４）。これにより、ＣＡ２０は、保留を解除して端末Ａ１と端末Ｂ１との間の通話を確立する（ステップＳ３１１５）。

保留の解除後は、図１３で示したステップＳ１３１６〜Ｓ１３２１の処理と同等の処理が行われる（ステップＳ３１１６〜Ｓ３１２１）。

このように、本実施の形態では、保留元端末に対するＣＡからの呼解放要求は、他の処理よりも優先される。

次に、図３２を参照して、被保留端末への保留解除ＩＮＶＩＴＥのタイムアウト動作について説明する。図３２は、被保留端末への保留解除ＩＮＶＩＴＥのタイムアウト動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３２０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３２０２）、ＣＡ２０は、端末Ａ１へＩＮＶＩＴＥリクエストの転送を繰り返す（ステップＳ３２０３〜Ｓ３２０５）。

ＩＮＶＩＴＥリクエストに対して端末Ａ１から２００ＯＫレスポンスメッセージが受信されず、所定時間経過する、すなわちタイムアウト（Ｔ．Ｏ．）となると（ステップＳ３２０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ３２０７、Ｓ３２０９）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ３２０８，Ｓ３２１０）。

コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、４８１信号を端末Ｂ１に送信し（ステップＳ３２１１）、ＢＹＥメッセージを端末Ｂ０に送信する（ステップＳ３２１２）。
端末Ｂ０から２００ＯＫレスポンスメッセージを受信し（ステップＳ３２１３）、端末Ｂ１からＡＣＫメッセージを受信すると（ステップＳ３２１４）、ＣＡ２０は、端末Ａ１と端末Ｂ０の呼の解放動作を行う。
なお、端末Ａ１の呼の解放動作については説明を省略する。

このように、本実施の形態では、信号がタイムアウトになると、呼解放を行う。

次に、図３３を参照して、代理応答端末への２００（保留解除ＩＮＶＩＴＥ）レスポンスタイムアウト動作について説明する。図３３は、代理応答端末への２００（保留解除ＩＮＶＩＴＥ）レスポンスタイムアウト動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３３０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３３０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ３３０３）。

ＩＮＶＩＴＥリクエストの転送後、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ３３０４）、ＣＡ２０は、そのメッセージの端末Ｂ１への転送を繰り返す（ステップＳ３３０５〜Ｓ３３０７）。

転送された２００ＯＫレスポンスメッセージに対して端末Ｂ１からＡＣＫメッセージが受信されず、タイムアウトとなると（ステップＳ３３０８）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ３３０９、Ｓ３３１１）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ３３１０，Ｓ３３１２）。

コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ＢＹＥメッセージを端末Ａ１，Ｂ０に送信する（ステップＳ３３１３、Ｓ３３１４）。
端末Ａ１，Ｂ０から２００ＯＫレスポンスメッセージを受信すると（ステップＳ３３１５，Ｓ３３１６）、ＣＡ２０は、端末Ａ１と端末Ｂ０の呼を解放する。

このように、本実施の形態では、信号がタイムアウトになると、呼解放を行う。

次に、図３４を参照して、複数端末からの保留解除操作の動作について説明する。図３４は、複数端末からの保留解除操作の動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３４０１）、端末Ｂ１と端末Ｂ０からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３４０２、Ｓ３４０３）、ＣＡ２０は、最初に到達したＩＮＶＩＴＥリクエストを優先し、４０３信号を端末Ｂ０に送信する（ステップＳ３４０４）。

端末Ｂ０からＡＣＫメッセージを受信すると（ステップＳ３４０５）、ＣＡ２０は、端末Ｂ１からのＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ３４０６）。
端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ３４０７）、ＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ３４０８）。
端末Ｂ１からＡＣＫメッセージを受信すると（ステップＳ３４０９）、ＣＡ２０は、端末Ｂ１が属するコールグループ＃２の端末に対して、呼状態（ＢＵＳＹ）をＮＯＴＩＦＹ信号で通知する（ステップＳ３４１０）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ３４１１）。

コールグループ＃２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ＡＣＫメッセージを端末Ａ１に送信し（ステップＳ３４１２）、ＢＹＥメッセージを端末Ｂ０に送信する（ステップＳ３４１３）。
端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、保留を解除し、端末Ａ１と端末Ｂ１との通話を確立する（ステップＳ３４１５）。

このように、本実施の形態によれば、最初にＣＡに到達した保留解除信号が優先される。

なお、上述したように端末Ａ１と端末Ｂ０とが通話中のときに、端末Ｂ０が端末Ａ１をコールパーク保留をする場合（着保留）について図３４の左側を参照して説明したが、端末Ａ１が端末Ｂ０をコールパーク保留をする場合（発保留）については、その動作を図３４の右側に示す。この発保留において、着保留と同様の処理については、同じステップの番号を付して、適宜説明を省略する。

次に、図３５を参照して、保留ＩＮＶＩＴＥ送信中の保留元による早切り動作について説明する。図３５は、保留ＩＮＶＩＴＥ送信中の保留元による早切り動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とが通話中のときに（ステップＳ３５０１）、端末Ｂ０からＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３５０２）、ＣＡ２０は、そのリクエストを端末Ａ１に転送する（ステップＳ３５０３）。

ＣＡ２０が端末Ａ１から２００ＯＫレスポンスメッセージを受信する前に、端末Ｂ０からＣＡＮＣＥＬ信号を受信すると（ステップＳ３５０４）、ＣＡ２０は、そのＣＡＮＣＥＬ信号を破棄する。したがって、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ３５０５）、ＣＡ２０は、そのメッセージを端末Ｂ０に転送する（ステップＳ３５０６）。

２００ＯＫレスポンスメッセージの転送後は、図４で示したステップＳ４２５〜Ｓ４２９と同等の処理が行われる（ステップＳ３５０７〜Ｓ３５１１）。

このように、本実施の形態では、保留処理に対するＣＡＮＣＥＬ信号を受信しても、保留処理が継続される。

次に、図３６を参照して、保留中の保留端末による保留ＩＮＶＩＴＥ送信動作について説明する。図３６は、保留中の保留端末による保留ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３６０１）、保留中の保留端末である端末Ｂ０からＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３６０２）、ＣＡ２０は、そのリクエストはエラーであるとして４０３信号を端末Ｂ０に送信する（ステップＳ３６０３）。４０３信号を受信した端末Ｂ０は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ３６０４）。

このように、本実施の形態によれば、保留中呼と同一ダイアログに対する保留信号に対しては、エラーとして処理する。

次に、図３７を参照して、保留中の代理応答端末により保留ＩＮＶＩＴＥ送信動作について説明する。図３７は、保留中の代理応答端末により保留ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３７０１）、代理応答端末となる端末Ｂ１からＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３７０２）、ＣＡ２０は、端末Ｂ１のリクエストは端末Ａ１と端末Ｂ０の呼とは別の呼であると判断し、１００Ｔｒｙｉｎｇレスポンスを端末Ｂ１に送信し（ステップＳ３７０３）、ＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ３７０４）。

ＩＮＶＩＴＥリクエスト転送後の処理は、図４で示したステップＳ４０４〜Ｓ４０９およびＳ４１１と同等の処理が行われる（ステップＳ３７０５〜Ｓ３７１１）。

このように、本実施の形態によれば、保留中呼と異なるダイアログに対する保留信号に対しては、新規の呼として処理する。

次に、図３８を参照して、独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作について説明する。図３８は、独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作を示すシーケンス図である。
「Ｐ−Ｎ−ＳｒｖＩｎｆｏ：ｃａｌｌｐａｒｋ」という独自ヘッダを有するＩＮＶＩＴＥリクエストを端末Ａ１から受信すると（ステップＳ３８０１）、ＣＡ２０は、そのヘッダを透過し、１００Ｔｒｙｉｎｇレスポンスを端末Ａ１に送信し（ステップＳ３８０２）、ＩＮＶＩＴＥリクエストを端末Ｂ０に転送する（ステップＳ３８０３）。

ＩＮＶＩＴＥリクエスト転送後の処理は、図４で示したステップＳ４０４〜Ｓ４０９およびＳ４１１と同等の処理が行われる（ステップＳ３８０４〜Ｓ３８１０）。

このように、本実施の形態によれば、新規呼接続要求（ｉｎｉ−ＩＮＶＩＴＥ）に不要なヘッダが付与されていてもそのヘッダを透過し、新規呼として処理を継続する。

次に、図３９を参照して、他の独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作について説明する。図３９は、他の独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作を示すシーケンス図である。
図３８で示した独自ヘッダとは異なる独自ヘッダ「Ｐ−Ｎ−ＳｒｖＩｎｆｏ：ｔｒａｎｓｆｅｒ」を有するＩＮＶＩＴＥリクエストを端末Ａ１から受信すると（ステップＳ３９０１）、ＣＡ２０は、そのヘッダを透過し、１００Ｔｒｙｉｎｇレスポンスを端末Ａ１に送信し（ステップＳ３９０２）、ＩＮＶＩＴＥリクエストを端末Ｂ０に転送する（ステップＳ３９０３）。

ＩＮＶＩＴＥリクエスト転送後の処理は、図４で示したステップＳ４０４〜Ｓ４０９およびＳ４１１と同等の処理が行われる（ステップＳ３９０４〜Ｓ３９１０）。

このように、本実施の形態によれば、図３８の場合とは異なる新規呼接続要求（ｉｎｉ−ＩＮＶＩＴＥ）に不要なヘッダが付与されていてもそのヘッダを透過し、新規呼として処理を継続する。

次に、図４０を参照して、保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信（ｒｅｐｌａｃｅｓ内容誤り）動作について説明する。図４０は、保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信（ｒｅｐｌａｃｅｓ内容誤り）動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ４００１）、代理応答端末となる端末Ｂ１からｒｅｐｌａｃｅｓ内容が誤ったＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ４００２）、ＣＡ２０は、端末Ｂ１に４０３信号を送信する（ステップＳ４００３）。４０３信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ４００４）。

このように、本実施の形態によれば、保留解除信号にコールパークサービス処理を継続するための情報が足りない場合は、エラーとして処理する。

次に、図４１を参照して、保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信（ｒｅｐｌａｃｅｓなし）動作について説明する。図４１は、保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信（ｒｅｐｌａｃｅｓなし）動作を示す図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ４１０１）、代理応答端末となる端末Ｂ１から「ｒｅｐｌａｃｅｓ」が含まれていない独自ヘッダを有するＩＮＶＩＴＥリクエストを端末Ａ１から受信すると（ステップＳ４１０２）、ＣＡ２０は、そのヘッダを透過し、１００Ｔｒｙｉｎｇレスポンスを端末Ａ１に送信し（ステップＳ４１０３）、ＩＮＶＩＴＥリクエストを端末Ｂ０に転送する（ステップＳ４１０４）。

ＩＮＶＩＴＥリクエスト転送後の処理は、図４で示したステップＳ４０４〜Ｓ４０９およびＳ４１１と同等の処理が行われる（ステップＳ４１０５〜Ｓ４１１１）。

このように、本実施の形態によれば、保留中呼として異なるダイアログに対する保留解除信号に対しては、新規呼として処理する。

本発明のコールパークサービスシステムの構成を示す図である。 ＣＡ２０の構成を示すブロック図である。 （ａ）ＶＰＮ内線番号変換テーブル、（ｂ）パークグループ管理テーブル、（ｃ）ランプ番号管理テーブル、（ｄ）番号状態テーブルを示す図である。 コールパークサービスシステムの動作を示すシーケンス図である。 「通話中状態通知あり」、同一パークグループ内発着の状態通知の動作を説明する図である。 「通話中状態通知あり」、別パークグループ発着の発側パークグループ内の状態通知の動作を説明する図である。 「通話中状態通知あり」、別パークグループ発着の着側パークグループ内の状態通知の動作を説明する図である。 「通話中状態通知なし」、保留端末と同一パークグループ内への状態通知の動作を説明する図である。 通話中状態通知なしの場合の動作を示すシーケンス図である。 ＲＥＧＩＳＴＥＲ端末への状態通知を示すシーケンス図である。 保留前保留ＩＮＶＩＴＥのすれ違い動作のシーケンス図である。 保留前保留ＩＮＶＩＴＥのすれ違い動作のシーケンス図である。 保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。 ＡＣＫ前の保留解除ＩＮＶＩＴＥ送信動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥに対するエラーレスポンスを示すシーケンス図である。 保留解除ＩＮＶＩＴＥとＢＹＥとのすれ違い動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥ送信後のＣＡＮＣＥＬ送信動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥ送信後のＢＹＥ送信動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥ送信中の強制呼解放動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥ送信中の系切替動作を示すシーケンス図である。 ＡＣＫ前のＢＹＥ送信動作を示すシーケンス図である。 ＡＣＫ前のｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ送信動作を示すシーケンス図である。 ＡＣＫ前のＢＹＥ送信動作を示すシーケンス図である。 ＡＣＫ前のＣＡＮＣＥＬ動作を示すシーケンス図である。 ＡＣＫ前のＢＹＥ送信動作を示すシーケンス図である。 ＣＡのＢＹＥと保留端末のＢＹＥのすれ違い動作を示すシーケンス図である。 ＣＡのＢＹＥと保留端末のｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。 保留解除ＩＮＶＩＴＥのタイムアウト動作を示すシーケンス図である。 ２００レスポンスタイムアウト動作を示すシーケンス図である。 複数端末からの保留解除操作の動作を示すシーケンス図である。 保留元による早切り動作を示すシーケンス図である。 保留端末による保留ＩＮＶＩＴＥ送信動作を示すシーケンス図である。 代理応答端末による保留ＩＮＶＩＴＥ送信動作を示すシーケンス図である。 独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作を示すシーケンス図である。 独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作を示すシーケンス図である。 保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信動作を示すシーケンス図である。 保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信動作を示す図である。

符号の説明

１…ＶＰＮ、２…ＬＡＮ、１０…電話端末、２０…ＣＡ、２１…データ通信部、２２…制御部、２３…記憶部、２４…保留部。

Claims (20)

1. ＩＰネットワークに接続され前記ＩＰネットワークを介して通信を行う複数の端末と、前記ＩＰネットワークに接続され前記端末間の呼を制御する呼制御サーバとを備え、
   前記呼制御サーバは、
   前記端末のグループを管理するデータベースと、
   第１の端末と第２の端末との間の呼を確立する第１の手段と、
   前記第１の端末の保留動作を検出すると前記呼を保留する第２の手段と、
   前記第１の端末と同一のグループに属する第３の端末からの保留解除動作を検出すると、前記第２の端末と前記第３の端末との間の呼を確立する第３の手段と
   を備えたことを特徴とするコールパークサービスシステム。
2. 請求項１記載のコールパークサービスシステムにおいて、
   前記第３の手段は、
   前記第３の端末からの保留解除動作を検出すると、前記データベースを参照して前記第１の端末と前記第３の端末とが同一のグループに属するか否かを判断し、両者が同一のグループに属するときに前記第２の端末と前記第３の端末との間の呼を確立する
   ことを特徴とするコールパークサービスシステム。
   
3. 請求項１または２に記載されたコールパークサービスシステムにおいて、
   前記呼制御サーバは、さらに
   各端末に前記端末の呼の状態に応じて状態表示信号を送信する第４の手段を備え、
   前記端末は、
   前記状態表示信号を受信する受信手段と、
   受信した状態表示信号に応じた表示を行う表示手段と
   を有することを特徴とするコールパークサービスシステム。
4. 請求項２に記載されたコールパークサービスシステムにおいて、
   前記呼制御サーバは、さらに
   前記データベースを参照し、同一のグループに属する各端末に前記端末の呼の状態に応じて状態表示信号を送信する第４の手段を備え、
   前記端末は、
   前記状態表示信号を受信する受信手段と、
   受信した状態表示信号に応じた表示を行う表示手段と
   を有することを特徴とするコールパークサービスシステム。
5. 請求項３または４に記載されたコールパークサービスシステムにおいて、
   前記状態表示信号は、通話中、保留中、終話信号のうち少なくとも１つを表す信号を含む
   ことを特徴とするコールパークサービスシステム。
6. 請求項５に記載されたコールパークサービスシステムにおいて、
   前記第４の手段は、
   前記第１の端末と前記第２の端末との間で呼が確立されると、前記第１の端末が属するグループと前記第２の端末が属するグループの端末それぞれに前記通話中を表す信号を送信する
   ことを特徴とするコールパークサービスシステム。
7. 請求項５または６に記載されたコールパークサービスシステムにおいて、
   前記第４の手段は、
   通話中の前記第１の端末からの保留動作により前記呼が保留されると、前記第１の端末が属するグループの端末に保留中を表す信号を送信する
   ことを特徴とするコールパークサービスシステム。
8. 請求項５乃至７のいずれかに記載されたコールパークサービスシステムにおいて、
   前記第４の手段は、
   通話中の前記第１または第３の端末と前記第２の端末とのいずれかからの終話動作が検出されると、前記第１の端末が属するグループの端末に終話信号を送信する
   ことを特徴とするコールパークサービスシステム。
9. ＩＰネットワークに接続され、前記ＩＰネットワークを介して通信を行う端末間の呼を制御する呼制御サーバであって、
   第１の端末と第２の端末との間の呼を確立する第１の手段と、
   前記第１の端末の保留動作を検出すると前記呼を保留する第２の手段と、
   第３の端末からの保留解除動作を検出すると、前記第２の端末と前記第３の端末との間の呼を確立する第３の手段と
   前記端末のグループを管理するデータベースと
   を備え、
   前記第３の手段は、
   前記第３の端末からの保留解除動作を検出すると、前記データベースを参照して前記第１の端末と前記第３の端末とが同一のグループに属するか否かを判断し、両者が同一のグループに属するときに前記第２の端末と前記第３の端末との間の呼を確立する
   ことを特徴とする呼制御サーバ。
10. 請求項９に記載された呼制御サーバにおいて、
    前記データベースを参照し、同一のグループに属する各端末に前記端末の呼の状態に応じて状態表示信号を送信する第４の手段をさらに備える
    ことを特徴とする呼制御サーバ。
11. 請求項１０に記載された呼制御サーバにおいて、
    前記状態表示信号は、通話中、保留中、終話信号のうち少なくとも１つを表す信号を含む
    ことを特徴とする呼制御サーバ。
12. 請求項１１に記載された呼制御サーバにおいて、
    前記第４の手段は、
    前記第１の端末と前記第２の端末との間で呼が確立されると、前記第１の端末が属するグループと前記第２の端末が属するグループの端末それぞれに前記通話中を表す信号を送信する
    ことを特徴とする呼制御サーバ。
13. 請求項１１または１２に記載された呼制御サーバにおいて、
    前記第４の手段は、
    通話中の前記第１の端末からの保留動作により前記呼が保留されると、前記第１の端末が属するグループの端末に保留中を表す信号を送信する
    ことを特徴とする呼制御サーバ。
14. 請求項１１乃至１３のいずれか１項に記載された呼制御サーバにおいて、
    前記第４の手段は、
    通話中の前記第１または第３の端末と前記第２の端末とのいずれかからの終話動作が検出されると、前記第１の端末が属するグループの端末に終話信号を送信する
    ことを特徴とする呼制御サーバ。
15. ＩＰネットワークに接続され前記ＩＰネットワークを介して通信を行う複数の端末と、前記ＩＰネットワークに接続され前記端末間の呼を制御する呼制御サーバと、前記端末のグループを管理するデータベースとを備えた通信システムのコールパークサービス方法であって、
    第１の端末と第２の端末との間の呼を確立する第１のステップと、
    前記第１の端末の保留動作を検出すると前記呼を保留する第２のステップと、
    第３の端末からの保留解除動作を検出すると、前記第２の端末と前記第３の端末との間の呼を確立する第３のステップと
    を備え、
    前記第３のステップは、
    前記第３の端末からの保留解除動作を検出すると、前記データベースを参照して前記第１の端末と前記第３の端末とが同一のグループに属するか否かを判断し、両者が同一のグループに属するときに前記第２の端末と前記第３の端末との間の呼を確立する
    ことを特徴とするコールパークサービス方法。
16. 請求項１５に記載されたコールパークサービス方法において、
    前記データベースを参照し、同一のグループに属する各端末に前記端末の呼の状態に応じて状態表示信号を送信する第４のステップ
    をさらに有することを特徴とするコールパークサービス方法。
17. 請求項１６に記載されたコールパークサービス方法において、
    前記状態表示信号は、通話中、保留中、終話信号のうち少なくとも１つを表す信号を含む
    ことを特徴とするコールパークサービス方法。
18. 請求項１７に記載されたコールパークサービス方法において、
    前記第４のステップは、
    前記第１の端末と前記第２の端末との間で呼が確立されると、前記第１の端末が属するグループと前記第２の端末が属するグループの端末それぞれに前記通話中を表す信号を送信する
    ことを特徴とするコールパークサービス方法。
19. 請求項１７または１８に記載されたコールパークサービス方法において、
    前記第４のステップは、
    通話中の前記第１の端末からの保留動作により前記呼が保留されると、前記第１の端末が属するグループの端末に保留中を表す信号を送信する
    ことを特徴とするコールパークサービス方法。
20. 請求項１７乃至１９のいずれか１項に記載されたコールパークサービス方法において、
    前記第４のステップは、
    通話中の前記第１または第３の端末と前記第２の端末とのいずれかからの終話動作が検出されると、前記第１の端末が属するグループの端末に終話信号を送信する
    ことを特徴とするコールパークサービス方法。
    
    

Images