(57)【要約】【課題】使い勝手のよいＶｏＩＰによるコールパークサービスシステム、呼制御サーバおよびコールパークサービス方法を提供することを目的とする。【解決手段】本発明によれば、２つの電話端末１０間で呼が確立され、一方の電話端末１０の保留動作を検出すると確立された呼が保留にされ、保留にした電話端末１０と同じパークグループに属する第３者の電話端末１０が保留解除動作を行うと、保留にされた電話端末１０と保留解除を行った電話端末１０との間の呼が確立される。このため、コールパークサービスを提供するのにＰＢＸが必要ではなく、ＰＢＸ独自のプロトコルを使わなくてよいので、使い勝手のよいＶｏＩＰによるコールパークサービスの提供が可能となる。【選択図】  図１
2006174112.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワークに接続され前記ＩＰネットワークを介して通信を行う複数の端末と、前記ＩＰネットワークに接続され前記端末間の呼を制御する呼制御サーバとを備え、
前記呼制御サーバは、
第１の端末と第２の端末との間の呼を確立する第１の手段と、
前記第１の端末の保留動作を検出すると前記呼を保留する第２の手段と、
第３の端末からの保留解除動作を検出すると、前記第２の端末と前記第３の端末との間の呼を確立する第３の手段と
を備えたことを特徴とするコールパークサービスシステム。
【請求項２】
請求項１記載のコールパークサービスシステムにおいて、
前記端末のグループを管理するデータベースを備え、
前記第３の手段は、
前記第３の端末からの保留解除動作を検出すると、前記データベースを参照して前記第１の端末と前記第３の端末とが同一のグループに属するか否かを判断し、両者が同一のグループに属するときに前記第２の端末と前記第３の端末との間の呼を確立する
ことを特徴とするコールパークサービスシステム。
【請求項３】
請求項１または２に記載されたコールパークサービスシステムにおいて、
前記呼制御サーバは、さらに
各端末に前記端末の呼の状態に応じて状態表示信号を送信する第４の手段を備え、
前記端末は、
前記状態表示信号を受信する受信手段と、
受信した状態表示信号に応じた表示を行う表示手段と
を有することを特徴とするコールパークサービスシステム。
【請求項４】
請求項２に記載されたコールパークサービスシステムにおいて、
前記呼制御サーバは、さらに
前記データベースを参照し、同一のグループに属する各端末に前記端末の呼の状態に応じて状態表示信号を送信する第４の手段を備え、
前記端末は、
前記状態表示信号を受信する受信手段と、
受信した状態表示信号に応じた表示を行う表示手段と
を有することを特徴とするコールパークサービスシステム。
【請求項５】
請求項３または４に記載されたコールパークサービスシステムにおいて、
前記状態表示信号は、通話中、保留中、終話信号のうち少なくとも１つを表す信号を含む
ことを特徴とするコールパークサービスシステム。
【請求項６】
請求項５に記載されたコールパークサービスシステムにおいて、
前記第４の手段は、
前記第１の端末と前記第２の端末との間で呼が確立されると、前記第１の端末が属するグループと前記第２の端末が属するグループの端末それぞれに前記通話中を表す信号を送信する
ことを特徴とするコールパークサービスシステム。
【請求項７】
請求項５または６に記載されたコールパークサービスシステムにおいて、
前記第４の手段は、
通話中の前記第１の端末からの保留動作により前記呼が保留されると、前記第１の端末が属するグループの端末に保留中を表す信号を送信する
ことを特徴とするコールパークサービスシステム。
【請求項８】
請求項５乃至７のいずれかに記載されたコールパークサービスシステムにおいて、
前記第４の手段は、
通話中の前記第１または第３の端末と前記第２の端末とのいずれかからの終話動作が検出されると、前記第１の端末が属するグループの端末に終話信号を送信する
ことを特徴とするコールパークサービスシステム。
【請求項９】
ＩＰネットワークに接続され、前記ＩＰネットワークを介して通信を行う端末間の呼を制御する呼制御サーバであって、
第１の端末と第２の端末との間の呼を確立する第１の手段と、
前記第１の端末の保留動作を検出すると前記呼を保留する第２の手段と、
第３の端末からの保留解除動作を検出すると、前記第２の端末と前記第３の端末との間の呼を確立する第３の手段と
前記端末のグループを管理するデータベースと
を備え、
前記第３の手段は、
前記第３の端末からの保留解除動作を検出すると、前記データベースを参照して前記第１の端末と前記第３の端末とが同一のグループに属するか否かを判断し、両者が同一のグループに属するときに前記第２の端末と前記第３の端末との間の呼を確立する
ことを特徴とする呼制御サーバ。
【請求項１０】
請求項９に記載された呼制御サーバにおいて、
前記データベースを参照し、同一のグループに属する各端末に前記端末の呼の状態に応じて状態表示信号を送信する第４の手段をさらに備える
ことを特徴とする呼制御サーバ。
【請求項１１】
請求項１０に記載された呼制御サーバにおいて、
前記状態表示信号は、通話中、保留中、終話信号のうち少なくとも１つを表す信号を含む
ことを特徴とする呼制御サーバ。
【請求項１２】
請求項１１に記載された呼制御サーバにおいて、
前記第４の手段は、
前記第１の端末と前記第２の端末との間で呼が確立されると、前記第１の端末が属するグループと前記第２の端末が属するグループの端末それぞれに前記通話中を表す信号を送信する
ことを特徴とする呼制御サーバ。
【請求項１３】
請求項１１または１２に記載された呼制御サーバにおいて、
前記第４の手段は、
通話中の前記第１の端末からの保留動作により前記呼が保留されると、前記第１の端末が属するグループの端末に保留中を表す信号を送信する
ことを特徴とする呼制御サーバ。
【請求項１４】
請求項１１乃至１３のいずれか１項に記載された呼制御サーバにおいて、
前記第４の手段は、
通話中の前記第１または第３の端末と前記第２の端末とのいずれかからの終話動作が検出されると、前記第１の端末が属するグループの端末に終話信号を送信する
ことを特徴とする呼制御サーバ。
【請求項１５】
ＩＰネットワークに接続され前記ＩＰネットワークを介して通信を行う複数の端末と、前記ＩＰネットワークに接続され前記端末間の呼を制御する呼制御サーバと、前記端末のグループを管理するデータベースとを備えた通信システムのコールパークサービス方法であって、
第１の端末と第２の端末との間の呼を確立する第１のステップと、
前記第１の端末の保留動作を検出すると前記呼を保留する第２のステップと、
第３の端末からの保留解除動作を検出すると、前記第２の端末と前記第３の端末との間の呼を確立する第３のステップと
を備え、
前記第３のステップは、
前記第３の端末からの保留解除動作を検出すると、前記データベースを参照して前記第１の端末と前記第３の端末とが同一のグループに属するか否かを判断し、両者が同一のグループに属するときに前記第２の端末と前記第３の端末との間の呼を確立する
ことを特徴とするコールパークサービス方法。
【請求項１６】
請求項１５に記載されたコールパークサービス方法において、
前記データベースを参照し、同一のグループに属する各端末に前記端末の呼の状態に応じて状態表示信号を送信する第４のステップ
をさらに有することを特徴とするコールパークサービス方法。
【請求項１７】
請求項１６に記載されたコールパークサービス方法において、
前記状態表示信号は、通話中、保留中、終話信号のうち少なくとも１つを表す信号を含む
ことを特徴とするコールパークサービス方法。
【請求項１８】
請求項１７に記載されたコールパークサービス方法において、
前記第４のステップは、
前記第１の端末と前記第２の端末との間で呼が確立されると、前記第１の端末が属するグループと前記第２の端末が属するグループの端末それぞれに前記通話中を表す信号を送信する
ことを特徴とするコールパークサービス方法。
【請求項１９】
請求項１７または１８に記載されたコールパークサービス方法において、
前記第４のステップは、
通話中の前記第１の端末からの保留動作により前記呼が保留されると、前記第１の端末が属するグループの端末に保留中を表す信号を送信する
ことを特徴とするコールパークサービス方法。
【請求項２０】
請求項１７乃至１９のいずれか１項に記載されたコールパークサービス方法において、
前記第４のステップは、
通話中の前記第１または第３の端末と前記第２の端末とのいずれかからの終話動作が検出されると、前記第１の端末が属するグループの端末に終話信号を送信する
ことを特徴とするコールパークサービス方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、本願発明は、ＩＰネットワークを介した音声通話におけるコールパークサービスを提供するコールパークサービスシステム、呼制御サーバおよびコールパークサービス方法に関するものである。
【背景技術】
【０００２】
現在、ＩＰ(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)やフレキシブルディスクなどの記録媒体に記録し、この記録媒体によってコンピュータにインストールするようにしてもよい。また、ＣＡ２０が接続されたＶＰＮ１を介して受信したプログラムをコンピュータにインストールするようにしてもよい。
【００３９】
次に、図４を参照して、本実施の形態に係るコールパークサービスシステムの動作について説明する。図４は、コールパークサービスシステムの動作を示すシーケンス図である。
図４において、電話端末１０からなる端末Ａ０および端末Ａ１とが同じコールグループ（コールグループ＃１）に属し、電話端末１０からなる端末Ｂ０および端末Ｂ１とが同じコールグループ（コールグループ＃２）に属する場合を例に説明する。また、図４では、後述する「通話中状態表示あり」に設定された場合について説明する。
なお、以下において、便宜上、電話端末１０のことを端末という。
【００４０】
なお、本実施の形態で用いるＳＩＰでは、メソッドを指定することでコマンドを実行する。標準では次のメソッドが定義されている。
「ＩＮＶＩＴＥ」は、ユーザをコールに招待することを意味する。
「ＡＣＫ」は、「ＩＮＶＩＴＥ」に対する応答を受け取ったことを知らせることを意味する。
「ＢＹＥ」は、コールを終了することを意味する。
「ＣＡＮＣＥＬ」は、未応答の「ＩＮＶＩＴＥ」リクエストをキャンセルすることを意味する。
「ＯＰＴＩＯＮＳ」は、サーバの能力情報を問い合わせることを意味する。
「ＲＥＧＩＳＴＥＲ」は、ユーザの現在位置を登録することを意味する。
「ＩＮＦＯ」は、ＤＴＭＦディジットや画像等のセッションに関係する情報を伝えることを意味する。
【００４１】
また、ＳＩＰでは、ＨＴＴＰ／１．１の応答コードの一部を拡張して利用する。応答コードには次のようなものが含まれる。
１００番台の応答コードは、暫定応答を意味し、リクエストを受信し、処理中であることを示す。例えば、「１００Ｔｒｙｉｎｇ」や「１８０Ｒｉｎｇｉｎｇ」などが挙げられる。
２００番台の応答コードは、成功応答を意味し、リクエストが理解され、受け入れられたことを示す。例えば、「２００ＯＫ」や「２０２Ａｃｃｅｐｔｅｄ」などが挙げられる。
３００番台の応答コードは、リダイレクト応答を意味し、リクエストを完了するために、更なる処理が必要であることを示す。例えば、「３００Ｍｕｌｔｉｐｌｅ  Ｃｈｏｉｃｅｓ」や「３０１Ｍｏｖｅｄ  Ｐｅｒｍａｎｅｎｔｌｙ」などが挙げられる。
【００４２】
４００番台の応答コードは、リクエストエラー応答を意味し、リクエストの書式が間違っていたか、このサーバでは処理できないことを示す。例えば、「４００Ｂａｄ  Ｒｅｑｕｅｓｔ」や「４０１Ｕｎａｕｔｈｏｒｉｚｅｄ」などが挙げられる。
５００番台の応答コードは、サーバエラー応答を意味し、サーバでのリクエスト処理に失敗したことを示す。例えば、「５００Ｉｎｔｅｒｎａｌ  Ｓｅｒｖｅｒ  Ｅｒｒｏｒ」や「５０１Ｎｏｔ  Ｉｍｐｌｅｍｅｎｔｅｄ」などが挙げられる。
６００番台の応答コードは、グローバルサーバエラー応答を意味し、リクエストをどのサーバでも処理できないことを意味する。例えば、「６００Ｂｕｓｙ  Ｅｖｅｒｙｗｈｅｒｅ」や「６０３Ｄｅｃｌｉｎｅ」などが挙げられる。
【００４３】
まず、端末Ａ１と端末Ｂ０とが通話を開始する動作を説明する（ステップＳ４０１〜４１５）。
発端末である端末Ａ１は、着端末である端末Ｂ０を指定するアドレスに関する情報を含むＩＮＶＩＴＥリクエストを、ＣＡ２０に送出する（ステップＳ４０１）。ＩＮＶＩＴＥリクエストを受信したＣＡ２０は、リクエストに対するレスポンスとして正常にＩＮＶＩＴＥリクエストを受信し、相手側端末である端末Ｂ０にＩＮＶＩＴＥをルートすることを試みていることを通知する１００Ｔｒｙｉｎｇレスポンスを、端末Ａ１に返送する（ステップＳ４０２）。また、ＣＡ２０は、ＩＮＶＩＴＥリクエストを端末Ｂ０に転送する（ステップＳ４０３）。
【００４４】
ＩＮＶＩＴＥリクエストを受信した端末Ｂ０は、１００ＴｒｙｉｎｇレスポンスをＣＡ２０に返送して呼び出しを開始し（ステップＳ４０４）、１８０ＲｉｎｇｉｎｇレスポンスメッセージをＣＡ２０を介して端末Ａ１に向かって送信する（ステップＳ４０５）。
１８０Ｒｉｎｇｉｎｇレスポンスメッセージを受信したＣＡ２０は、１８０Ｒｉｎｇｉｎｇレスポンスメッセージを、端末Ａ１に転送する（ステップＳ４０６）。
１８０Ｒｉｎｇｉｎｇレスポンスメッセージを受信した端末Ａ１は、呼び出し音または画面表示でユーザに通知する。
【００４５】
端末Ｂ０のユーザが受話器を取ると、端末Ｂ０は応答したことを示すため２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４０７）。
２００ＯＫレスポンスメッセージを受信したＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ａ１に転送する（ステップＳ４０８）。
【００４６】
２００ＯＫレスポンスメッセージを受信した端末Ａ１は、２００ＯＫレスポンスメッセージの受信を確認するため、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ４０９）。
端末Ａ１から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１が属するコールグループの全ての端末に対して、呼状態（ＢＵＳＹ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４１０）。このＣＡ２０から送信されるＮＯＴＩＦＹ信号には、端末のランプ制御に関する情報が含まれており、受信したＮＯＴＩＦＹ信号に基づいて、コールグループ＃１の端末は、自身のランプの点灯制御を行う。
コールグループ＃１の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４１２）。なお、端末から送信されるＮＯＴＩＦＹ信号に対する２００ＯＫ信号は、コールパークサービスの動作に関わらず、コールパークサービスの動作とは非同期でＣＡ２０に送信される。
【００４７】
また、端末Ａ１からＡＣＫメッセージを受信したＣＡ２０は、コールグループ＃２に属する端末に対して、呼状態（ＢＵＳＹ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４１３）。このＮＯＴＩＦＹ信号にも、端末のランプ制御に関する情報が含まれており、コールグループ＃２の端末は、受信したＮＯＴＩＦＹ信号に基づいて、自身のランプの点灯制御を行う。
コールグループ＃２の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４１４）。
【００４８】
これにより、端末Ａ１と端末Ｂ０とは通話中となる（ステップＳ４１５）。
【００４９】
次に、端末Ｂ０が端末Ａ１をコールパーク保留にし、端末Ｂ０と同じコールグループ＃２の端末Ｂ１が端末Ａ１と通話を行う動作について説明する（ステップＳ４２１〜Ｓ４４０）。
【００５０】
コールパーク保留を行う端末Ｂ０は、通話中である端末Ａ１を保留（ＨＯＬＤ）にする情報を含むＩＮＶＩＴＥリクエストを、ＣＡ２０に送出する（ステップＳ４２１）。ＩＮＶＩＴＥリクエストを受信したＣＡ２０は、ＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ４２２）。
【００５１】
ＩＮＶＩＴＥリクエストを受信した端末Ａ１は、応答したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ４２３）。２００ＯＫレスポンスメッセージを受信したＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ０に転送する（ステップＳ４２４）。２００ＯＫレスポンスメッセージを受信した端末Ｂ０は、２００ＯＫレスポンスメッセージの受信を確認するため、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ４２５）。
【００５２】
端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ｂ０が属するコールグループ＃２の全ての端末に対して、呼状態（ＨＯＬＤ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４２６）。このＮＯＴＩＦＹ信号には、端末のランプ制御に関する情報が含まれており、受信したＮＯＴＩＦＹ信号に基づいて、コールグループ＃２の端末は、自身のランプを点灯制御を行う。
コールグループ＃２の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４２７）。
【００５３】
また、ＣＡ２０は、端末Ａ１を保留にすることを示すＮＯＴＩＦＹ信号をコールグループ＃２の端末に送信すると、ＡＣＫメッセージを端末Ａ１に送信する（ステップＳ４２８）。
これにより、端末Ａ１と端末Ｂ０とは、コールパーク保留状態となる（ステップＳ４２９）。
【００５４】
ここで、端末Ｂ１は、コールパーク保留にされた端末Ａ１をピックアップするために、コールパーク保留中である端末Ａ１を保留解除（ＵＮＨＯＬＤ）する情報を含むＩＮＶＩＴＥリクエストを、ＣＡ２０に送出する（ステップＳ４３０）。ＩＮＶＩＴＥリクエストを受信したＣＡ２０は、ＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ４３１）。
【００５５】
ＩＮＶＩＴＥリクエストを受信した端末Ａ１は、応答したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ４３２）。２００ＯＫレスポンスメッセージを受信したＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ１に転送する（ステップＳ４３３）。２００ＯＫレスポンスメッセージを受信した端末Ｂ１は、２００ＯＫレスポンスメッセージの受信を確認するため、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ４３４）。
【００５６】
端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ｂ０が属するコールグループ＃２の全ての端末に対して、呼状態（ＢＵＳＹ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４３５）。このＮＯＴＩＦＹ信号には、端末のランプ制御に関する情報が含まれており、受信したＮＯＴＩＦＹ信号に基づいて、コールグループ＃２の端末は、自身のランプを点灯制御を行う。
コールグループ＃２の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４３６）。
【００５７】
また、ＣＡ２０は、端末Ａ１を保留解除することを示すＮＯＴＩＦＹ信号をコールグループ＃２の端末に送信すると、ＡＣＫメッセージを端末Ａ１に送信する（ステップＳ４３７）。
また、ＣＡ２０は、通信を切断することを意味するＢＹＥメッセージを、端末Ａ１をコールパーク保留にした端末Ｂ０に、送信する（ステップＳ４３８）。ＢＹＥメッセージを受信すると、端末Ｂ０は、ＢＹＥメッセージを受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ４３９）。
【００５８】
これにより、端末Ａ１のコールパーク保留が解除され、端末Ａ１と端末Ｂ１との通話が実現される（ステップＳ４４０）。
【００５９】
なお、上述したように端末Ａ１と端末Ｂ０とが通話中のときに、端末Ｂ０が端末Ａ１をコールパーク保留をする場合（着保留）について図４の左側を参照して説明したが、端末Ａ１が端末Ｂ０をコールパーク保留をする場合（発保留）については、その動作を図４の右側に示す。この発保留において、着保留と同様の処理については、同じステップの番号を付して、適宜説明を省略する。
【００６０】
次に、端末Ｂ１が端末Ａ１との通話を切断する動作を説明する（ステップＳ４５１〜Ｓ４５８）。
端末Ｂ１は、端末Ａ１との通信を切断することを意味するＢＹＥメッセージを、ＣＡ２０に送信する（ステップＳ４５１）
ＢＹＥメッセージを受信すると、ＣＡ２０は、端末Ｂ１が属するコールグループ＃２の全ての端末に対して、呼状態（ＢＹＥ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知する（ステップＳ４５２）。このＮＯＴＩＦＹ信号には、端末のランプ制御に関する情報が含まれており、受信したＮＯＴＩＦＹ信号に基づいて、コールグループ＃２の端末は、自身のランプを点灯制御を行う。
コールグループ＃２の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４５３）。
【００６１】
また、ＣＡ２０は、端末Ａ１が属するコールグループ＃１の全ての端末に対して、呼状態（ＢＹＥ）、呼情報、呼に対応するランプ番号をＮＯＴＩＦＹ信号で通知し（ステップＳ４５４）、端末Ａ１と端末Ｂ１との通信を切断することを意味するＢＹＥメッセージを、端末Ａ１に転送する（ステップＳ４５５）。
【００６２】
コールグループ＃１の端末は、ＣＡ２０からＮＯＴＩＦＹ信号を受信すると、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ４５６）。また、端末Ａ１は、ＣＡ２０からＢＹＥメッセージを受信すると、このＢＹＥ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ４５７）。
【００６３】
２００ＯＫレスポンスメッセージを端末Ａ１から受信すると、ＣＡ２０は、受信した２００ＯＫレスポンスメッセージを端末Ｂ１に転送する（ステップＳ４５８）。
これにより、端末Ａ１と端末Ｂ１との通信は切断される。
【００６４】
なお、上述したように端末Ａ１と端末Ｂ１とが通話中のときに、端末Ｂ１が端末Ａ１との通信を切断にする場合（着切断）について図４の左側を参照して説明したが、端末Ａ１が端末Ｂ１との通信を切断する場合（発切断）については、その動作を図４の右側に示す。この発切断において、着切断と同様の処理については、同じステップの番号を付して、適宜説明を省略する。
【００６５】
このように、本実施の形態によれば、ＳＩＰプロトコルを用い、ＰＢＸ等のユーザ装置を不要とすることにより、相互接続性を高めることが可能となる。結果として、使い勝手のよいコールパークサービスの提供が可能となる。
また、本実施の形態によれば、ユーザ設備に制御装置が不要となるので、ＩＰ電話端末のみでコールパークサービスを提供することが可能となる。
【００６６】
次に、本実施の形態に係るコールパークサービスシステムで提供されるコールパークサービスについて説明する。コールパークサービスは、通話中状態通知機能とランプ番号通知機能の２種類の通知機能を有する。それぞれについて、以下に説明する。
【００６７】
［通話中状態通知機能］
コールパークサービスでは、同一コールパークグループ内の端末に対して、各端末の呼状態を付属するランプを用いてユーザに通知することができる。ユーザに対して通知することができる状態は、通話中（ＢＵＳＹ）、保留中（ＨＯＬＤ）、回線空き（ＢＹＥ）の３状態である。ユーザは、契約時に通話中状態通知機能を使用するか否かを選択することができ、ＣＡ２０は、契約状態に応じて「通話中状態通知機能あり」または「通話中状態通知機能なし」の何れか一方の動作を行う。それぞれの動作は次の通りである。
なお、コールパークグループとは、グルーピングされたＩＰ−ＶＰＮユーザ番号の集合を意味する。
【００６８】
「通話中状態通知機能なし」の場合は、通話中呼に対してコールパーク保留を起動した端末である保留端末と、通話中呼に対してコールパーク保留を起動された端末である被保留端末との間にコールパーク保留が成功したときに、保留端末の属するコールパークグループに対してＮＯＴＩＦＹ信号で呼状態（ＨＯＬＤ）、呼情報、呼に対応するランプ番号を通知する。
また、コールパークグループ内に存在する保留状態呼に対して保留解除を起動した端末である代理応答端末によってピックアップが成功したときに、代理応答端末の属するコールパークグループ（保留端末と同一のコールパークグループ）に対してＮＯＴＩＦＹ信号にて呼状態（ＢＵＳＹ）、呼情報、呼に対するランプ番号を通知する。
また、呼切断時に、発側コールパークグループ、着側コールパークグループそれぞれに対してＮＯＴＩＦＹ信号で呼状態（ＢＹＥ）、呼情報、呼に対するランプ番号を通知する。
【００６９】
「通話中状態通知機能あり」の場合は、発端末と着端末との呼が確立したときに、発側コールパークグループ、着側コールパークグループそれぞれに対して呼状態（ＢＵＳＹ）、呼情報、呼に対応するランプ番号を通知する。保留時、保留解除時、呼切断時のＮＯＴＩＦＹ信号の送信動作については、通話中状態通知なしの場合と同様である。
【００７０】
［ランプ番号通知機能］
「通話中推移時」、「保留起動時」、「保留解除時」に、電話端末からランプ番号を示す独自ヘッダ（Ｐ−Ｎ−ＬｏｃａｔｅＩｎｆｏ）が付与される場合、ＣＡ２０でそのヘッダ情報をＮＯＴＩＦＹ信号に付加し、コールパークグループに対してランプ番号を通知する機能を有する。
「通話中状態通知機能なし」と「通話中状態通知機能あり」それぞれの場合の動作について、以下に説明する。
【００７１】
まず、「通話中状態通知機能なし」の場合について説明する。
「通話中推移時」は、発端末からのｉｎｉｔｉａｌ  ＩＮＶＩＴＥに付与することができるランプ番号を通知する独自ヘッダの有無、付与されているランプ番号によらず、発側コールパークグループに対してＮＯＴＩＦＹ信号は送信されない。また、着側端末からのｉｎｉｔｉａｌ  ＩＮＶＩＴＥに対する２００ＯＫのランプ番号を通知する独自ヘッダの有無、付与されているランプ番号によらず、着側コールパークグループに対してＮＯＴＩＦＹ信号は送信されない。
【００７２】
「保留起動時」は、保留端末からのＩＮＶＩＴＥ（ＨＯＬＤ）リクエストにランプ番号を通知する独自ヘッダが付与された場合、保留端末と同一コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループで既に使用中の場合、ＣＡ２０は、ＩＮＶＩＴＥ（ＨＯＬＤ）リクエストに対してエラーレスポンス（４０３）を送信する。
【００７３】
「保留解除時」は、代理応答端末からのＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストにランプ番号を通知する独自ヘッダが付与された場合、代理応答端末と同一コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループの保留起動時に決定されたランプ番号以外の場合、ＣＡ２０はＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストに対してエラーレスポンス（４０３）を送信する。
【００７４】
次に、「通話中状態通知機能あり」の場合について説明する。
「通話中推移時」は、発端末からのｉｎｉｔｉａｌ  ＩＮＶＩＴＥにランプ番号を通知する独自ヘッダが付与された場合、発側コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。着端末からのｉｎｉｔｉａｌ  ＩＮＶＩＴＥに対する２００ＯＫにランプ番号を通知する独自ヘッダが付与された場合、着側コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループで既に使用中の場合、ＣＡ２０で空いているランプ番号を通知する。
【００７５】
「保留起動時」は、保留端末からのＩＮＶＩＴＥ（ＨＯＬＤ）にランプ番号を通知する独自ヘッダが付与された場合、保留端末と同一コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループの通話中推移時に決定されたランプ番号以外の場合、ＣＡ２０は、ＩＮＶＩＴＥ（ＨＯＬＤ）リクエストに対してエラーレスポンス（４０３）を送信する。
【００７６】
「保留解除時」は、代理応答端末からのＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストにランプ番号を通知する独自ヘッダが付与された場合、代理応答端末と同一コールパークグループに対するＮＯＴＩＦＹ信号で独自ヘッダに示されたランプ番号を通知する。もし、独自ヘッダに示されたランプ番号が同一コールパークグループの保留起動時に決定されたランプ番号以外の場合、ＣＡ２０は、ＩＮＶＩＴＥ（ＵＮＨＯＬＤ）に対してエラーレスポンス（４０３）を送信する。
【００７７】
ここで、ＣＡ２０は、端末間の通信にランプを割り当て、このランプ単位で通信制御を行っており、コールパークグループ単位でランプ番号の使用状態を保持している。
ランプ番号を空き状態から使用中に変更するのは、端末から最初に独自ヘッダを受信し、かつ、そのランプ番号がＣＡ２０で空き状態となっている場合であり、使用中から空き状態に変更されるのは、通話中状態通知ありの場合はＮＯＴＩＦＹ（ＢＹＥ）信号を送信したとき、通話中状態通知なしの場合は保留解除ＮＯＴＩＦＹ（ＢＵＳＹ）信号送信時である。ＣＡ２０は、１つのコールパークグループ当たり最大５０個までランプ番号を保持することができる。通話中状態通知ありで、ｉｎｉｔｉａｌ  ＩＮＶＩＴＥまたは２００ＯＫ受信時に端末にて独自ヘッダが付与されないか、５０個全てのランプ番号が使用中であるか、ＣＡ２０にて管理できるランプ番号以外の値が設定された場合は、端末に対して送信するランプ番号はＮＵＬＬとなる。
【００７８】
上述した通話中状態通知機能およびランプ番号通知機能のＣＡ２０における動作について、図５〜８を参照して説明する。
まず、図５を参照して、「通話中状態通知あり」の設定で、同一のパークグループ内に発着行う場合の状態通知の動作について説明する。図５は、「通話中状態通知あり」の設定で、同一のパークグループ内に発着行う場合の状態通知の動作を説明する図である。
【００７９】
何れのランプも使用していない状態のときに（ステップＳ５０１）、ＩＮＶＩＴＥリクエストを受信すると、ＣＡ２０は、１番のランプを通知する独自ヘッダが付与されている場合は１番のランプを保持し（ステップＳ５０２）、１番のランプを通知する独自ヘッダが付与されたが１番のランプが使用中の場合は未使用のランプ（２番のランプ）を保持し（ステップＳ５０３）、独自ヘッダが付与されていない場合はランプを未使用状態とする（ステップＳ５０４）。
【００８０】
１番のランプを保持した後、２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ランプ番号に関わらず１番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５０５）。ここで、１番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。
２番のランプを保持した後、２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ランプ番号に関わらず２番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５０６）。ここで、２番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。
【００８１】
ランプ未使用状態において、２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、１番のランプを通知する独自ヘッダが付与された場合はステップＳ５０５の処理に進み、１番のランプを通知する独自ヘッダが付与されたが１番のランプが使用中の場合はステップＳ５０６の処理に進み、独自ヘッダが付与されていない場合はランプ番号をＮＵＬＬとするＮＯＴＩＦＹ信号を同一のコールパークグループの端末に送信する（ステップＳ５０７）。このステップＳ５０７において、ＮＵＬＬ以外のランプに関する通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。
【００８２】
１番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を送信後、保留端末からＩＮＶＩＴＥ（ＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、１番のランプを通知する独自ヘッダが付与されている場合は、１番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５０８）。ここで、１番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させず、その通知の送信元に対して４０３信号を送信する。
【００８３】
２番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を送信後、保留端末からＩＮＶＩＴＥ（ＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、２番のランプを通知する独自ヘッダが付与されている場合は、２番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５０９）。ここで、２番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させず、その通知の送信元に対して４０３信号を送信する。
【００８４】
ランプ番号をＮＵＬＬとするＮＯＴＩＦＹ信号を送信後、保留端末から１番のランプを通知する独自ヘッダが付与されたＩＮＶＩＴＥ（ＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、ステップＳ５０９の処理に進む。
【００８５】
１番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を送信後、代理応答端末からＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、１番のランプを通知する独自ヘッダが付与されている場合は、１番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５１０）。ここで、１番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させず、その通知の送信元に対して４０３信号を送信する。
【００８６】
２番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を送信後、代理応答端末からＩＮＶＩＴＥ（ＵＮＨＯＬＤ）リクエストを受信すると、ＣＡ２０は、２番のランプを通知する独自ヘッダが付与されている場合は、２番のランプをＨＯＬＤ状態とするＮＯＴＩＦＹ信号を、同一のコールパークグループの端末に送信する（ステップＳ５１１）。ここで、２番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させず、その通知の送信元に対して４０３信号を送信する。
【００８７】
呼切断するＢＹＥ信号を受信すると、ＣＡ２０は、同一のコールパークグループの端末に対してＮＯＴＩＦＹ信号で呼状態（ＢＹＥ）、呼情報、呼に対するランプ番号を通知する（ステップＳ５１２）。
【００８８】
次に、図６を参照して、「通話中状態通知あり」の設定で、発着が別のパークグループにおいて発側パークグループ内への状態通知の動作について説明する。図６は、「通話中状態通知あり」の設定で、発着が別のパークグループにおいて発側パークグループ内への状態通知の動作について説明する図である。
なお、図６において、ステップＳ６０４とＳ６０７以外のステップは、対応する図５のステップとそれぞれ同等である。したがって、図５に示すステップと同等のステップには、下二桁のステップ番号に同じ番号を付して、適宜説明を省略する。
【００８９】
ステップＳ６０４の状態、すなわちランプ未使用状態において、独自ヘッダが付与されていない２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ランプ番号をＮＵＬＬとするＮＯＴＩＦＹ信号を発側のコールパークグループに送信する（ステップＳ６０７）。このステップＳ６０７において、ＮＵＬＬ以外のランプに関する通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。
【００９０】
次に、図７を参照して、「通話中状態通知あり」の設定で、発着が別のパークグループにおいて着側パークグループ内への状態通知の動作について説明する。図７は、「通話中状態通知あり」の設定で、発着が別のパークグループにおいて着側パークグループ内への状態通知の動作について説明する図である。
なお、図７において、ステップＳ７０８〜Ｓ７１２は、対応する図５のステップＳ５０８〜５１２とそれぞれ同等である。したがって、図５に示すステップと同等のステップには、下二桁のステップ番号に同じ番号を付して、適宜説明を省略する。
【００９１】
何れのランプも使用していない状態のときに（ステップＳ７０１）、ＩＮＶＩＴＥリクエストを受信すると、ＣＡ２０は、独自ヘッダの有無や通知されたランプの番号に関わらず１番のランプを保持する（ステップＳ７０２）。
【００９２】
１番のランプを保持した状態において、２００ＯＫレスポンスメッセージを受信し、１番のランプを通知する独自ヘッダが付与された場合、ＣＡ２０は、１番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、着側のコールパークグループに送信する（ステップＳ７０５）。ここで、１番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。
【００９３】
また、１番のランプを保持した状態において、２００ＯＫレスポンスメッセージを受信し、１番のランプを通知する独自ヘッダが付与されたが１番のランプが使用中の場合、ＣＡ２０は、２番のランプをＢＵＳＹ状態とするＮＯＴＩＦＹ信号を、着側のコールパークグループに送信する（ステップＳ７０６）。ここで、２番のランプ以外の通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。
【００９４】
また、１番のランプを保持した状態において、２００ＯＫレスポンスメッセージを受信し、独自ヘッダが付与されていない場合、ＣＡ２０は、ランプ番号をＮＵＬＬとするＮＯＴＩＦＹ信号を、着側のコールパークグループに送信する（ステップＳ７０７）。このステップＳ７０７において、ＮＵＬＬ以外のランプに関する通知を受信しても、ＣＡ２０は、ランプ状態を変化させない。
【００９５】
次に、図８を参照して、「通話中状態通知なし」の設定で、保留端末と同一のパークグループ内への状態通知の動作について説明する。図８は、「通話中状態通知なし」の設定で、保留端末と同一のパークグループ内への状態通知の動作を説明する図である。
なお、図８において、ステップＳ８０８，Ｓ８１０，Ｓ８１２は、対応する図５のステップとそれぞれ同等である。したがって、図５に示すステップと同等のステップには、下二桁のステップ番号に同じ番号を付して、適宜説明を省略する。
【００９６】
何れのランプも使用していない状態のときに（ステップＳ８０１）、ＩＮＶＩＴＥリクエストを受信すると、ＣＡ２０は、独自ヘッダの有無や通知されたランプの番号に関わらず、ランプを未使用の状態にする（ステップＳ８０２）。
【００９７】
ランプ未使用の状態において、２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、通知されたランプ番号に関わらず、ランプを未使用の状態にする（ステップＳ８０５）。
【００９８】
次に、図９〜４１を参照して、本実施の形態に係るコールパークサービスシステムの各動作について説明する。
前述した図４および図９，１０に示す処理は正常処理を、図１１〜３４は準正常処理を、図３５〜４１は異常処理を示す。ここで、準正常処理とは、正常処理の中で予想される異常状態が発生したときの対処法を意味する。
【００９９】
なお、図９〜４１では、電話端末１０からなる端末Ａ０および端末Ａ１とが同じコールグループ（コールグループ＃１）に属し、電話端末１０からなる端末Ｂ０および端末Ｂ１とが同じコールグループ（コールグループ＃２）に属するシステムを例に説明する。ここで、端末Ａ０，Ａ１側を発信者の端末が属する発側、端末Ｂ０，Ｂ１側を着信者の端末が属する着側とする。
また、発信者とは、ある呼を生成したユーザのことを意味する。ＳＩＰ信号上ではｉｎｉｔｉａｌ  ＩＮＶＩＴＥを生成した端末を使用しているユーザのことを意味する。
また、着信者とは、ある呼に対して始めに応答したユーザのことを意味する。ＳＩＰ信号上ではｉｎｉｔｉａｌ  ＩＮＶＩＴＥに対して２００ＯＫレスポンスを送信した端末を使用しているユーザのことを意味する。
【０１００】
まず、図９を参照して、通話中状態通知なしの場合の本実施の形態に係るコールパークサービスシステムの動作について説明する。図９は、通話中状態通知なしの場合の動作を示すシーケンス図である。
なお、図９において、保留動作と切断動作は、図４に示す動作（ステップＳ４２１〜Ｓ４５８）と同等である。したがって、保留動作と切断動作については適宜説明を省略する。
【０１０１】
図９に示す通話中状態通知なしの場合は、通話中状態が表示されない、すなわち、図４で示したステップＳ４１０，４１１〜４１４のＮＯＴＩＦＹ（ＢＵＳＹ）信号に対応する処理が行われない。これにより、本実施の形態において、通話中状態通知なしに設定された場合は、通話中の状態が通知されない。
【０１０２】
次に、図１０を参照して、ＲＥＧＩＳＴＥＲ端末への状態通知について説明する。図１０は、ＲＥＧＩＳＴＥＲ端末への状態通知を示すシーケンス図である。
端末Ａ０と端末Ｂ０とが通話中（ｄｉａｌｏｇ１／ラン  ＃１）であり（ステップＳ１００１）、端末Ａ１と端末Ｂ１とが保留中（ｄｉａｌｏｇ２／ラン  ＃２）である場合に、端末Ｂ２（ＲＥＧＩＳＴＥＲ端末）が端末登録をする旨のＲＥＧＩＳＴＥＲ信号をＣＡ２０に送信する（ステップＳ１００３）。
例えば、端末Ｂ２が端末登録が認可されていない等のリクエストエラー応答として４０１Ｕｎａｕｔｈｏｒｉｚｅｄ信号がＣＡ２０から返信されると（ステップＳ１００４）、端末Ｂ２は、再度ＲＥＧＩＳＴＥＲ信号をＣＡ２０に送信する（ステップＳ１００５）。
【０１０３】
ＲＥＧＩＳＴＥＲ信号を受信し、端末Ｂ２の端末登録を認可すると、ＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ２に送信する（ステップＳ１００６）。
また、ＣＡ２０は、端末Ｂ２と同一のコールパークグループに属する端末Ｂ０および端末Ｂ１の状態を通知するＮＯＴＩＦＹ信号を、端末Ｂ２に送信する（ステップＳ１００７，Ｓ１００８）。
ＮＯＴＩＦＹ信号を受信すると、端末Ｂ２は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１００９）。
【０１０４】
このように、本実施の形態では、位置登録をした端末に対して同一コールパークグループ内に属する他の端末の状態が通知される。
【０１０５】
次に、図１１を参照して、保留前保留ＩＮＶＩＴＥのすれ違い動作（発側保留勝ち）について説明する。図１１は、保留前保留ＩＮＶＩＴＥのすれ違い動作（発側保留勝ち）のシーケンス図である。
端末Ａ１と端末Ｂ０とが通話中のときに（ステップＳ１１０１）、端末Ａ１が端末Ｂ０を保留にするＩＮＶＩＴＥリクエストをＣＡ２０に送信した後に（ステップＳ１１０２）、端末Ｂ０が端末Ａ１を保留にするＩＮＶＩＴＥリクエストがＣＡ２０に送信されると（ステップＳ１１０３）、ＣＡ２０は、端末Ｂ０のＩＮＶＩＴＥリクエストに対して、５００  Ｓｅｒｖｅｒ  Ｉｎｔｅｒｎａｌ  Ｅｒｒｏｒ信号（以下、５００信号という）を端末Ｂ０に送信する（ステップＳ１１０４）。
【０１０６】
５００信号を受信すると、端末Ｂ０は、５００信号の受信を確認したことを示すＡＣＫメッセージをＣＡ２０に送信し（ステップＳ１１０５）、ＩＮＶＩＴＥリクエストをエラーしたことを示す４９１信号を、ＣＡ２０に送信する（ステップＳ１１０６）。
【０１０７】
４９１信号を受信したＣＡ２０は、４９１信号を端末Ａ１に転送し（ステップＳ１１０７）、４９１信号を受信したことを示すＡＣＫメッセージを端末Ｂ０に送信する（ステップＳ１１０８）。
【０１０８】
４９１信号を受信した端末Ａ１は、４９１信号を受信したことを示すＡＣＫメッセージをＣＡ２０に送信し（ステップＳ１１０９）、再度、ＩＮＶＩＴＥリクエストをＣＡ２０に送信する（ステップＳ１１０８）。
すると、図４で示した発保留側のステップＳ４２２〜Ｓ４２９の処理と同等の処理が行われ（ステップＳ１１１２〜Ｓ１１１９）、端末Ａ１と端末Ｂ０とはコールパーク保留状態となる。
【０１０９】
このように、本実施の形態によれば、ＩＮＶＩＴＥリクエストがすれ違った場合は、最初にＣＡ２０に到達したＩＮＶＩＴＥリクエストが優先される。
【０１１０】
次に、図１２を参照して、保留前保留ＩＮＶＩＴＥのすれ違い動作（着側保留勝ち）について説明する。図１２は、保留前保留ＩＮＶＩＴＥのすれ違い動作（着側保留勝ち）のシーケンス図である。
端末Ａ１と端末Ｂ０とが通話中のときに（ステップＳ１２０１）、端末Ｂ０が端末Ａ１に、また端末Ａ１が端末Ｂ０に、それぞれＩＮＶＩＴＥリクエストをＣＡ２０に送信したが（ステップＳ１２０２、１２０３）、端末Ｂ０のＩＮＶＩＴＥリクエストが先にＣＡ２０に到達すると、ＣＡ２０は、端末Ｂ０のＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ１２０４）。
【０１１１】
ＩＮＶＩＴＥリクエストを送信後にＣＡ２０から端末Ｂ０からのＩＮＶＩＴＥリクエストが転送された端末Ａ１は、ＩＮＶＩＴＥリクエストをエラーしたことを示す４９１信号を、ＣＡ２０に送信する（ステップＳ１２０５）。
【０１１２】
４９１信号を受信したＣＡ２０は、４９１信号を端末Ｂ０に転送し（ステップＳ１２０６）、４９１信号を受信したことを示すＡＣＫメッセージを端末Ａ１に送信する（ステップＳ１２０７）。
【０１１３】
４９１信号を受信した端末Ｂ０は、４９１信号を受信したことを示すＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１２０８）。
ＡＣＫメッセージを受信したＣＡ２０は、５００信号を端末Ａ１に送信する（ステップＳ１２０９）。
５００信号を受信した端末Ａ１は、４９１信号を受信したことを示すＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１２１０）。
【０１１４】
ＡＣＫメッセージを送信後、端末Ｂ０は、再度、ＩＮＶＩＴＥリクエストをＣＡ２０に送信する（ステップＳ１２１１）。
すると、図４で示した着保留側のステップＳ４２２〜Ｓ４２９の処理と同等の処理が行われ（ステップＳ１２１２〜Ｓ１２１９）、端末Ａ１と端末Ｂ０とはコールパーク保留状態となる。
【０１１５】
このように、本実施の形態によれば、ＩＮＶＩＴＥリクエストがすれ違った場合は、最初にＣＡ２０に到達したＩＮＶＩＴＥリクエストが優先される。
【０１１６】
次に、図１３を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作について説明する。図１３は、代理応答端末からの保留解除ＩＮＶＩＴＥと保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１３０１）、代理応答端末となる端末Ｂ１から保留解除（ＵＮＨＯＬＤ）を意味するＩＮＶＩＴＥリクエストを受信すると（ステップＳ１３０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ１３０３）。
【０１１７】
ＩＮＶＩＴＥリクエストの転送後、保留端末である端末Ｂ０から生存確認を示すｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１３０４）、ＣＡ２０は、既に端末Ｂ１から保留解除のＩＮＶＩＴＥリクエストを受信しているので、５００信号を端末Ｂ０に送信する（ステップＳ１３０５）。
５００信号を受信した端末Ｂ０は、ＡＣＫメッセージをＣＡ２０に返信する（ステップＳ１３０６）。
【０１１８】
ＡＣＫメッセージの受信後は、図４で示した着保留側のステップＳ４３２〜Ｓ４４０の処理と同等の処理が行われ（ステップＳ１３０７〜Ｓ１３１５）、端末Ａ１と端末Ｂ１との通話が行われる。
【０１１９】
端末Ｂ１は、保留解除後、すぐにｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストをＣＡ２０に送信する（ステップＳ１３１６）。
ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると、ＣＡ２０は、そのリクエストを端末Ａ１に転送する（ステップＳ１３１７）。
ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると、端末Ａ１は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１３１８）。
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、そのメッセージを端末Ｂ１に送信する（ステップＳ１３１９）。
２００ＯＫレスポンスメッセージを受信すると、端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１３２０）。
ＡＣＫメッセージを受信すると、ＣＡ２０は、そのＡＣＫメッセージを端末Ａ１に転送する（ステップＳ１３２１）。
【０１２０】
このように本実施の形態では、代理応答処理は、保留端末からの生存確認よりも優先される。
【０１２１】
次に、図１４を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと保留端末からのＢＹＥとのすれ違い動作について説明する。図１４は、代理応答端末からの保留解除ＩＮＶＩＴＥと保留端末からのＢＹＥとのすれ違い動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１４０１）、代理応答端末となる端末Ｂ１から保留解除を意味するＩＮＶＩＴＥリクエストを受信すると（ステップＳ１４０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ１４０３）。
【０１２２】
しかしながら、ＩＮＶＩＴＥリクエストの転送後、保留端末である端末Ｂ０から呼切断要求を示すＢＹＥメッセージを受信すると（ステップＳ１４０４）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ１４０５、Ｓ１４０７）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ１４０６，Ｓ１４０８）。
【０１２３】
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１にＢＹＥメッセージを転送し（ステップＳ１４０９）、ＩＮＶＩＴＥリクエストを送信してきた端末Ｂ１に５００信号を送信する（ステップＳ１４１０）。
【０１２４】
ＢＹＥメッセージを受信すると、端末Ａ１は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１４１１）。
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、その２００ＯＫレスポンスメッセージを端末Ｂ０に転送する（ステップＳ１４１２）。
５００信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１４１３）。
【０１２５】
このように、本実施の形態によれば、端末からの呼切断要求は、他の処理よりも優先される。
【０１２６】
次に、図１５を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い（保留解除勝ち／リフレッシュ更新時間外）の動作について説明する。図１５は、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い（保留解除勝ち／リフレッシュ更新時間外）の動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１５０１）、代理応答端末となる端末Ｂ１から保留解除を意味するＩＮＶＩＴＥリクエストを受信すると（ステップＳ１５０２）、ＣＡ２０は、リフレッシュ時間の数秒前は、ＵＮＨＯＬＤの再送を促すために、４９１信号を端末Ｂ１に送信する（ステップＳ１５０３）。
【０１２７】
ここで、保留端末である端末Ａ１から生存確認を示すｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１５０４）、ＣＡ２０は、そのリクエストを端末Ｂ０に転送する（ステップＳ１５０５）。
【０１２８】
４９１信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信し（ステップＳ１５０６）、ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信した端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１５０７）。
【０１２９】
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、そのメッセージを端末Ａ１に転送する（ステップＳ１５０８）。
２００ＯＫレスポンスメッセージを受信した端末Ａ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１５０９）。
ＡＣＫメッセージを受信したＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ１５１０）。
【０１３０】
ＡＣＫメッセージの転送後は、図４で示した着保留側のステップＳ４３０〜Ｓ４４０の処理と同等の処理が行われ（ステップＳ１５１１〜Ｓ１５２１）、端末Ａ１と端末Ｂ１との通話が行われる。
【０１３１】
このように、本実施の形態によれば、保留元以外の端末からの生存確認は、代理応答要求よりも優先される。
【０１３２】
次に、図１６を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い（保留解除勝ち／リフレッシュ更新時間外）動作について説明する。図１６は、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い（保留解除勝ち／リフレッシュ更新時間外）動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１６０１）、代理応答端末となる端末Ｂ１から保留解除を意味するＩＮＶＩＴＥリクエストを受信すると（ステップＳ１６０２）、ＣＡ２０は、そのリクエストを端末Ａ１に転送する（ステップＳ１６０３）。
【０１３３】
ここで、保留端末である端末Ａ１から生存確認を示すｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１６０４）、ＣＡ２０は、端末Ｂ１からのＩＮＶＩＴＥリクエストを透過して、ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストに対して、５００信号を端末Ａ１に送信する（ステップＳ１６０５）。
【０１３４】
５００信号を受信した端末Ａ１は、ＡＣＫメッセージをＣＡ２０に送信し（ステップＳ１６０６）、ＵＮＨＯＬＤのＩＮＶＩＴＥリクエストに対する４９１信号をＣＡ２０に送信する（ステップＳ１６０７）。
【０１３５】
４９１信号を受信したＣＡ２０は、その４９１信号を端末Ｂ１に転送し（ステップＳ１６０８）、ＡＣＫメッセージを端末Ａ１に送信する（ステップＳ１６０９）。
４９１信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１６１０）。
すると、端末Ａ１と端末Ｂ０とがコールパーク保留が維持される（ステップＳ１６１１）。
【０１３６】
このように、本実施の形態によれば、保留元以外の端末からの生存確認は、代理応答要求よりも優先される。
【０１３７】
次に、図１７を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅ  ＩＮＶＩＴＥとのすれ違い（ｋｅｅｐａｌｉｖｅ勝ち）動作について説明する。図１７は、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのｋｅｅｐａｌｉｖｅ  ＩＮＶＩＴＥとのすれ違い（ｋｅｅｐａｌｉｖｅ勝ち）動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１７０１）、保留端末である端末Ａ１からｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１７０２）、ＣＡ２０は、そのリクエストを端末Ｂ０に転送する（ステップＳ１７０４）。このｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストの転送とすれ違って、端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ１７０３）、ＣＡ２０は、ＵＮＨＯＬＤの再送を促すため４９１信号を端末Ｂ１に送信する（ステップＳ１７０５）。
【０１３８】
一方、ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信した端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１７０６）。
２００ＯＫレスポンスメッセージを受信したＣＡ２０は、そのメッセージを端末Ａ１に転送する（ステップＳ１７０７）。
【０１３９】
４９１信号を受信すると、端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１７０８）。
２００ＯＫレスポンスメッセージを受信すると、端末Ａ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１７０９）。
ＡＣＫメッセージを受信すると、ＣＡ２０は、そのメッセージを端末Ｂ０に転送する（ステップＳ１７０６）。
【０１４０】
ＡＣＫメッセージの転送後は、図４で示した着保留側のステップＳ４３０〜Ｓ４４０の処理と同等の処理が行われ（ステップＳ１７１１〜Ｓ１７２１）、端末Ａ１と端末Ｂ１との通話が行われる。
【０１４１】
このように、本実施の形態によれば、保留元以外の端末からの生存確認は、代理応答要求よりも優先される。
【０１４２】
次に、図１８を参照して、被保留端末からのＡＣＫ（ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ）前の代理応答端末からの保留解除ＩＮＶＩＴＥ送信動作について説明する。図１８は、被保留端末からのＡＣＫ（ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ）前の代理応答端末からの保留解除ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１８０１）、保留端末である端末Ａ１からｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ１８０２）、ＣＡ２０は、そのリクエストを端末Ｂ０に転送する（ステップＳ１８０３）。
【０１４３】
ｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信した端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ１８０４）。
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、そのメッセージを端末Ａ１に転送する（ステップＳ１８０５）。
【０１４４】
ここで、端末Ａ１からのＡＣＫメッセージの受信前に、端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ１８０６）、ＣＡ２０は、端末Ａ１からのＡＣＫメッセージの受信後に（ステップＳ１８０７）、ＵＮＨＯＬＤの再送を促すための４９１信号を端末Ｂ１に送信する（ステップＳ１８０８）。また、ＣＡ２０は、端末Ａ１から受信したＡＣＫメッセージを、端末Ｂ０に転送する（ステップＳ１８０９）。
４９１信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ１８１０）。
【０１４５】
ＡＣＫメッセージの転送後は、図４で示した着保留側のステップＳ４３０〜Ｓ４４０の処理と同等の処理が行われ（ステップＳ１８１１〜Ｓ１８２１）、端末Ａ１と端末Ｂ１との通話が行われる。
【０１４６】
このように、本実施の形態によれば、保留元以外の端末からの生存確認は、代理応答要求よりも優先される。
【０１４７】
次に、図１９を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥに対する被保留端末からのエラーレスポンス動作について説明する。図１９は、代理応答端末からの保留解除ＩＮＶＩＴＥに対する被保留端末からのエラーレスポンスを示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ１９０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ１９０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ１９０３）。
【０１４８】
ここで、端末Ａ１が受信したＩＮＶＩＴＥリクエストに対して、４００ＢａｄＲｅｑｕｅｓｔ信号（以下、４００信号という）をＣＡ２０に送信すると（ステップＳ１９０４）、ＣＡ２０は、４００信号を端末Ｂ１に転送し（ステップＳ１９０５）、ＡＣＫメッセージを端末Ａ１に送信する（ステップＳ１９０６）。
端末Ｂ１からＡＣＫメッセージを受信すると（ステップＳ１９０７）、ＣＡ２０は，端末Ａ１と端末Ｂ０とのコールパーク保留を継続する（ステップＳ１９０８）。
【０１４９】
このように、本実施の形態によれば、端末からのエラーレスポンスは、ＣＡ２０を透過して処理される。
【０１５０】
次に、図２０を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのＢＹＥとのすれ違い動作について説明する。図２０は、代理応答端末からの保留解除ＩＮＶＩＴＥと被保留端末からのＢＹＥとのすれ違い動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２００１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２００２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２００３）。
【０１５１】
このＩＮＶＩＴＥリクエストの転送とすれ違って、端末Ａ１からＢＹＥメッセージを受信すると（ステップＳ２００４）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２００５、Ｓ２００７）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２００６，２００８）。
【０１５２】
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ＩＮＶＩＴＥリクエストを送信してきた端末Ｂ１に５００信号を送信し（ステップＳ２００９）、端末Ｂ０にＢＹＥメッセージを転送する（ステップＳ２０１０）。
【０１５３】
ＢＹＥメッセージを受信すると、端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ２０１１）。
２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、その２００ＯＫレスポンスメッセージを端末Ａ１に転送する（ステップＳ２０１２）。
５００信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ２０１３）。
【０１５４】
このように、本実施の形態によれば、端末からの呼切断要求は、他の処理よりも優先される。
【０１５５】
次に、図２１を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥ送信後に代理応答端末からのＣＡＮＣＥＬ送信動作について説明する。図２１は、代理応答端末からの保留解除ＩＮＶＩＴＥ送信後に代理応答端末からのＣＡＮＣＥＬ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２１０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２１０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２１０３）。
【０１５６】
ここで、端末Ｂ１からＣＡＮＣＥＬ信号を受信すると（ステップＳ２１０４）、ＣＡ２０は、端末Ｂ１が属するコールグループ＃２に含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知し（ステップＳ２１０５）、ＣＡＮＣＥＬ信号に対する２００ＯＫレスポンスメッセージを端末Ｂ１に送信する（ステップＳ２１０６）。また、ＣＡ２０は、コールグループ＃１に含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２１０８）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２１０７，２１０９）。
【０１５７】
コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１と端末Ｂ０にＢＹＥメッセージを送信する（ステップＳ２１１０，２１１１）。
端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２１１２）、ＣＡ２０は、４８７信号を端末Ｂ１に送信する（ステップＳ２１１３）。
【０１５８】
ＢＹＥメッセージを受信すると、端末Ｂ０は、２００ＯＫレスポンスメッセージをＣＡ２０に送信する（ステップＳ２１１４）。
４８７信号を受信すると、端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ２１１５）。
【０１５９】
このように、本実施の形態によれば、端末からの呼切断要求は、他の処理よりも優先される。
【０１６０】
次に、図２２を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥ送信後に代理応答端末からのＢＹＥ送信動作について説明する。図２２は、代理応答端末からの保留解除ＩＮＶＩＴＥ送信後に代理応答端末からのＢＹＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２２０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２２０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２２０３）。
【０１６１】
ここで、端末Ｂ１からＣＡＮＣＥＬ信号を受信すると（ステップＳ２２０４）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２２０５、Ｓ２２０７）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２２０６，Ｓ２２０８）。
【０１６２】
コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１と端末Ｂ０にＢＹＥメッセージを送信する（ステップＳ２２０９，Ｓ２２１０）。
端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２２１１）、ＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ１に送信する（ステップＳ２２１２）。
また、ＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ０から受信する（ステップＳ２１１３）。
【０１６３】
このように、本実施の形態によれば、端末からの呼切断要求は、他の処理よりも優先される。
【０１６４】
次に、図２３を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥ送信中の強制呼解放動作について説明する。図２３は、代理応答端末からの保留解除ＩＮＶＩＴＥ送信中の強制呼解放動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２３０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２３０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２３０３）。
【０１６５】
ここで、呼解放が強制的に要求される（ＦＳＴ）と（ステップＳ２３０４）、ＣＡ２０は、コールグループ＃１に含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２３０５）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したコールグループ＃１の端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２３０６）。また、ＣＡ２０は、ＢＹＥメッセージを端末Ａ１に送信し（ステップＳ２３０７）、２００ＯＫレスポンスメッセージを端末Ａ１から受信する（ステップＳ２３０９）。
【０１６６】
また、ＣＡ２０は、コールグループ＃２に含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２３０８）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したコールグループ＃２の端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２３１０）。
また、ＣＡ２０は、ＢＹＥメッセージを端末Ｂ０に送信し（ステップＳ２３１１）、５００信号を端末Ｂ１に送信する（ステップＳ２３０９）。すると、ＣＡ２０は、端末Ｂ０から２００ＯＫレスポンスメッセージを受信し（ステップＳ２３１３）、端末Ｂ１からＡＣＫメッセージを受信する（ステップＳ２３１４）。
【０１６７】
これにより、本実施の形態では、保守者等による呼解放要求は、他の処理よりも優先して処理される。
【０１６８】
次に、図２４を参照して、代理応答端末からの保留解除ＩＮＶＩＴＥ送信中の系切替動作について説明する。図２４は、代理応答端末からの保留解除ＩＮＶＩＴＥ送信中の系切替動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２４０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２４０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２４０３）。
【０１６９】
ここで、系の切替が要求されると（ステップＳ２４０４）、ＣＡ２０は、端末Ａ１と端末Ｂ０とのコールパーク保留を継続する（ステップＳ２４０５）。
【０１７０】
これにより、本実施の形態では、安定呼に対するシステム系の切替に対しては、その呼状態が保持される。
【０１７１】
次に、図２５を参照して、代理応答端末からのＡＣＫ（保留解除前ＩＮＶＩＴＥ）前の保留端末からのＢＹＥ送信動作について説明する。図２５は、代理応答端末からのＡＣＫ（保留解除前ＩＮＶＩＴＥ）前の保留端末からのＢＹＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２５０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２５０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２５０３）。
【０１７２】
端末Ａ１は、応答したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２５０４）。２００ＯＫレスポンスメッセージを受信したＣＡ２０は、２００ＯＫレスポンスメッセージを端末Ｂ１に転送する（ステップＳ２５０５）。
ここで、端末Ｂ０からＢＹＥメッセージを受信すると（ステップＳ２５０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２５０７、Ｓ２５０９）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２５０８，Ｓ２５１０）。
【０１７３】
コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１と端末Ｂ１にＢＹＥメッセージを送信する（ステップＳ２５１１，Ｓ２５１２）。
ＢＹＥメッセージ対して２００ＯＫレスポンスメッセージを端末Ａ１から受信すると（ステップＳ２５１３）、ＣＡ２０は、そのメッセージを端末Ｂ０に転送する（ステップＳ２５１４）。また、ＣＡ２０は、端末Ｂ１から２００ＯＫレスポンスメッセージを受信する（ステップＳ２５１５）。
【０１７４】
これにより、本実施の形態では、端末からの呼切断要求が他の処理よりも優先されることとなる。
【０１７５】
次に、図２６を参照して、代理応答端末からのＡＣＫ（保留解除信号ＩＮＶＩＴＥ）前の保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ送信動作について説明する。図２６は、代理応答端末からのＡＣＫ（保留解除信号ＩＮＶＩＴＥ）前の保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２６０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２６０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２６０３）。
【０１７６】
ＩＮＶＩＴＥリクエストの転送後、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２６０４）、ＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ２６０５）。
ここで、端末Ｂ０からｋｅｅｐａｌｉｖｅＩＮＶＩＴＥリクエストを受信すると（ステップＳ２６０６）、ＣＡ２０は、既に端末Ｂ１から保留解除のＩＮＶＩＴＥリクエストを受信しているので、５００信号を端末Ｂ０に送信する（ステップＳ２６０７）。
５００信号を受信した端末Ｂ０は、ＡＣＫメッセージをＣＡ２０に返信する（ステップＳ２６０８）。
【０１７７】
２００ＯＫレスポンスメッセージに対するＡＣＫメッセージを端末Ｂ１から受信すると（ステップＳ２６０９）、ＣＡ２０は、端末Ｂ１が属するコールグループ＃２の端末に対して、呼状態（ＢＵＳＹ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２６１０）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したコールグループ＃２の端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２６１１）。
【０１７８】
ＣＡ２０は、２００ＯＫレスポンスメッセージに対するＡＣＫメッセージを端末Ａ１に送信し（ステップＳ２６１２）、ＢＹＥメッセージを端末Ｂ０に送信し（ステップＳ２６１３）、端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２６１４）、保留を解除して端末Ａ１と端末Ｂ１との間の通話を確立する（ステップＳ２６１５）。
保留の解除後は、図１３で示したステップＳ１３１６〜Ｓ１３２１の処理と同等の処理が行われる（ステップＳ２６１６〜Ｓ２６２１）。
【０１７９】
これにより、本実施の形態では、代理応答処理は、保留元端末からの生存確認よりも優先される。
【０１８０】
次に、図２７を参照して、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の被保留端末からのＢＹＥ送信動作について説明する。図２７は、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の被保留端末からのＢＹＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２７０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２７０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２７０３）。
【０１８１】
ＩＮＶＩＴＥリクエストの転送後、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２７０４）、ＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ２７０５）。
ここで、端末Ａ１からＢＹＥメッセージを受信すると（ステップＳ２７０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２７０７、Ｓ２７０９）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２７０８，Ｓ２７１０）。
【０１８２】
コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ｂ０と端末Ｂ１にＢＹＥメッセージを送信する（ステップＳ２７１１，Ｓ２７１２）。
端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２７１３）、ＣＡ２０は、そのメッセージを端末Ａ１に転送する（ステップＳ２７１４）。また、ＣＡ２０は、端末Ｂ１から２００ＯＫレスポンスメッセージを受信する（ステップＳ２７１５）。
【０１８３】
これにより、本実施の形態では、端末からの呼切断要求は、他の処理よりも優先されることとなる。
【０１８４】
次に、図２８を参照して、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の代理応答端末からのＣＡＮＣＥＬ動作について説明する。図２８は、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の代理応答端末からのＣＡＮＣＥＬ動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ２８０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ２８０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ２８０３）。
【０１８５】
ＩＮＶＩＴＥリクエストの転送後、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２８０４）、ＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ２８０５）。
ここで、２００ＯＫレスポンスメッセージとすれ違いで端末Ｂ１からＣＡＮＣＥＬメッセージを受信すると（ステップＳ２８０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２８０７、Ｓ２８０９）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ２８０８，Ｓ２８１０）。
【０１８６】
コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、端末Ａ１，Ｂ０，Ｂ１にＢＹＥメッセージを送信し（ステップＳ２８１１〜Ｓ２８１３）し、それぞれの端末から２００ＯＫレスポンスメッセージを受信する（ステップＳ２８１４〜Ｓ２８１６）。
【０１８７】
これにより、本実施の形態では、端末からの呼切断要求は、他の処理よりも優先されることとなる。
【０１８８】
次に、図２９を参照して、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の代理応答端末からのＢＹＥ送信動作について説明する。図２９は、代理応答端末からのＡＣＫ（保留解除ＩＮＶＩＴＥ）前の代理応答端末からのＢＹＥ送信動作を示すシーケンス図である。
なお、図２９において、ステップＳ２９０５とＳ２９１４以外の処理は、対応する図２８で示したステップと同等であるので、対応するステップにはステップ番号の下２桁に同じ番号を付して、適宜説明を省略する。
【０１８９】
２００ＯＫレスポンスメッセージとすれ違いで端末Ｂ１からＢＹＥメッセージを受信すると（ステップＳ２９０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ２９０７、Ｓ２９０９）。それぞれの端末から２００ＯＫレスポンスメッセージを受信すると（ステップＳ２９０８、Ｓ２９１０）、端末Ａ１，Ｂ０にＢＹＥメッセージを送信し（ステップＳ２９１１，Ｓ２９１２）、それぞれから２００ＯＫレスポンスメッセージを受信し（ステップＳ２９１３，２９１５）、受信したＢＹＥメッセージに対して２００ＯＫレスポンスメッセージを端末Ｂ１に送信する（ステップＳ２９１４）。
【０１９０】
これにより、本実施の形態では、端末からの呼切断要求は、他の処理よりも優先されることとなる。
【０１９１】
次に、図３０を参照して、ＣＡからの保留端末へのＢＹＥと保留端末からのＢＹＥとのすれ違い動作について説明する。図３０は、ＣＡからの保留端末へのＢＹＥと保留端末からのＢＹＥとのすれ違い動作を示すシーケンス図である。
なお、図３０において、ステップＳ３００１〜３００９の処理は、図４の着保留側に示したステップＳ４２９〜Ｓ４３７と同等であるので、適宜説明を省略する。
【０１９２】
端末Ａ１へＡＣＫメッセージを送信後に、端末Ｂ０がＢＹＥメッセージをＣＡ２０に送信し（ステップＳ３０１０）、ＣＡ２０がＢＹＥメッセージを端末Ｂ０に送信して（ステップＳ３０１１）、ＢＹＥメッセージがすれ違ったとする。この場合、相互に２００ＯＫレスポンスメッセージを送信することにより（ステップＳ３０１２，Ｓ３０１３）、端末Ｂ０の呼が切断され、端末Ａ１と端末Ｂ１との通話が行われる（ステップＳ３０１４）。
【０１９３】
このように、本実施の形態では、保留元端末に対するＣＡからの呼解放要求は、他の処理よりも優先される。
【０１９４】
次に、図３１を参照して、ＣＡからの保留端末へのＢＹＥと保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作について説明する。図３１は、ＣＡからの保留端末へのＢＹＥと保留端末からのｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
なお、図３１において、ステップＳ３１０１〜３１０９の処理は、図４の着保留側に示したステップＳ４２９〜Ｓ４３７と同等であるので、適宜説明を省略する。
【０１９５】
端末Ａ１へＡＣＫメッセージを送信後に、端末Ｂ０がｋｅｅｐａｌｉｖｅＩＮＶＩＴＥメッセージをＣＡ２０に送信し（ステップＳ３１１０）、ＣＡ２０がＢＹＥメッセージを端末Ｂ０に送信して（ステップＳ３１１１）、２つのメッセージがすれ違ったとする。この場合、ＣＡ２０は、端末Ｂ０に４００信号を送信する（ステップＳ３１１２）。
【０１９６】
４００信号を受信すると、端末Ｂ０は、４００信号に対するＡＣＫメッセージと、ＢＹＥメッセージに対する２００ＯＫレスポンスメッセージとを、ＣＡ２０に送信する（ステップＳ３１１３，３１１４）。これにより、ＣＡ２０は、保留を解除して端末Ａ１と端末Ｂ１との間の通話を確立する（ステップＳ３１１５）。
【０１９７】
保留の解除後は、図１３で示したステップＳ１３１６〜Ｓ１３２１の処理と同等の処理が行われる（ステップＳ３１１６〜Ｓ３１２１）。
【０１９８】
このように、本実施の形態では、保留元端末に対するＣＡからの呼解放要求は、他の処理よりも優先される。
【０１９９】
次に、図３２を参照して、被保留端末への保留解除ＩＮＶＩＴＥのタイムアウト動作について説明する。図３２は、被保留端末への保留解除ＩＮＶＩＴＥのタイムアウト動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３２０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３２０２）、ＣＡ２０は、端末Ａ１へＩＮＶＩＴＥリクエストの転送を繰り返す（ステップＳ３２０３〜Ｓ３２０５）。
【０２００】
ＩＮＶＩＴＥリクエストに対して端末Ａ１から２００ＯＫレスポンスメッセージが受信されず、所定時間経過する、すなわちタイムアウト（Ｔ．Ｏ．）となると（ステップＳ３２０６）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ３２０７、Ｓ３２０９）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ３２０８，Ｓ３２１０）。
【０２０１】
コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、４８１信号を端末Ｂ１に送信し（ステップＳ３２１１）、ＢＹＥメッセージを端末Ｂ０に送信する（ステップＳ３２１２）。
端末Ｂ０から２００ＯＫレスポンスメッセージを受信し（ステップＳ３２１３）、端末Ｂ１からＡＣＫメッセージを受信すると（ステップＳ３２１４）、ＣＡ２０は、端末Ａ１と端末Ｂ０の呼の解放動作を行う。
なお、端末Ａ１の呼の解放動作については説明を省略する。
【０２０２】
このように、本実施の形態では、信号がタイムアウトになると、呼解放を行う。
【０２０３】
次に、図３３を参照して、代理応答端末への２００（保留解除ＩＮＶＩＴＥ）レスポンスタイムアウト動作について説明する。図３３は、代理応答端末への２００（保留解除ＩＮＶＩＴＥ）レスポンスタイムアウト動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３３０１）、代理応答端末となる端末Ｂ１からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３３０２）、ＣＡ２０は、端末Ａ１にＩＮＶＩＴＥリクエストを転送する（ステップＳ３３０３）。
【０２０４】
ＩＮＶＩＴＥリクエストの転送後、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ３３０４）、ＣＡ２０は、そのメッセージの端末Ｂ１への転送を繰り返す（ステップＳ３３０５〜Ｓ３３０７）。
【０２０５】
転送された２００ＯＫレスポンスメッセージに対して端末Ｂ１からＡＣＫメッセージが受信されず、タイムアウトとなると（ステップＳ３３０８）、ＣＡ２０は、端末Ａ１と端末Ｂ０が属するコールグループ＃１，＃２それぞれに含まれる端末に対して、呼状態（ＢＹＥ）をＮＯＴＩＦＹ信号で通知する（ステップＳ３３０９、Ｓ３３１１）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ３３１０，Ｓ３３１２）。
【０２０６】
コールグループ＃１，２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ＢＹＥメッセージを端末Ａ１，Ｂ０に送信する（ステップＳ３３１３、Ｓ３３１４）。
端末Ａ１，Ｂ０から２００ＯＫレスポンスメッセージを受信すると（ステップＳ３３１５，Ｓ３３１６）、ＣＡ２０は、端末Ａ１と端末Ｂ０の呼を解放する。
【０２０７】
このように、本実施の形態では、信号がタイムアウトになると、呼解放を行う。
【０２０８】
次に、図３４を参照して、複数端末からの保留解除操作の動作について説明する。図３４は、複数端末からの保留解除操作の動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３４０１）、端末Ｂ１と端末Ｂ０からＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３４０２、Ｓ３４０３）、ＣＡ２０は、最初に到達したＩＮＶＩＴＥリクエストを優先し、４０３信号を端末Ｂ０に送信する（ステップＳ３４０４）。
【０２０９】
端末Ｂ０からＡＣＫメッセージを受信すると（ステップＳ３４０５）、ＣＡ２０は、端末Ｂ１からのＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ３４０６）。
端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ３４０７）、ＣＡ２０は、そのメッセージを端末Ｂ１に転送する（ステップＳ３４０８）。
端末Ｂ１からＡＣＫメッセージを受信すると（ステップＳ３４０９）、ＣＡ２０は、端末Ｂ１が属するコールグループ＃２の端末に対して、呼状態（ＢＵＳＹ）をＮＯＴＩＦＹ信号で通知する（ステップＳ３４１０）。
ＣＡ２０からＮＯＴＩＦＹ信号を受信したそれぞれの端末は、ＮＯＴＩＦＹ信号を受信したことを示す２００ＯＫレスポンスメッセージを、ＣＡ２０に送信する（ステップＳ３４１１）。
【０２１０】
コールグループ＃２から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、ＡＣＫメッセージを端末Ａ１に送信し（ステップＳ３４１２）、ＢＹＥメッセージを端末Ｂ０に送信する（ステップＳ３４１３）。
端末Ｂ０から２００ＯＫレスポンスメッセージを受信すると、ＣＡ２０は、保留を解除し、端末Ａ１と端末Ｂ１との通話を確立する（ステップＳ３４１５）。
【０２１１】
このように、本実施の形態によれば、最初にＣＡに到達した保留解除信号が優先される。
【０２１２】
なお、上述したように端末Ａ１と端末Ｂ０とが通話中のときに、端末Ｂ０が端末Ａ１をコールパーク保留をする場合（着保留）について図３４の左側を参照して説明したが、端末Ａ１が端末Ｂ０をコールパーク保留をする場合（発保留）については、その動作を図３４の右側に示す。この発保留において、着保留と同様の処理については、同じステップの番号を付して、適宜説明を省略する。
【０２１３】
次に、図３５を参照して、保留ＩＮＶＩＴＥ送信中の保留元による早切り動作について説明する。図３５は、保留ＩＮＶＩＴＥ送信中の保留元による早切り動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とが通話中のときに（ステップＳ３５０１）、端末Ｂ０からＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３５０２）、ＣＡ２０は、そのリクエストを端末Ａ１に転送する（ステップＳ３５０３）。
【０２１４】
ＣＡ２０が端末Ａ１から２００ＯＫレスポンスメッセージを受信する前に、端末Ｂ０からＣＡＮＣＥＬ信号を受信すると（ステップＳ３５０４）、ＣＡ２０は、そのＣＡＮＣＥＬ信号を破棄する。したがって、端末Ａ１から２００ＯＫレスポンスメッセージを受信すると（ステップＳ３５０５）、ＣＡ２０は、そのメッセージを端末Ｂ０に転送する（ステップＳ３５０６）。
【０２１５】
２００ＯＫレスポンスメッセージの転送後は、図４で示したステップＳ４２５〜Ｓ４２９と同等の処理が行われる（ステップＳ３５０７〜Ｓ３５１１）。
【０２１６】
このように、本実施の形態では、保留処理に対するＣＡＮＣＥＬ信号を受信しても、保留処理が継続される。
【０２１７】
次に、図３６を参照して、保留中の保留端末による保留ＩＮＶＩＴＥ送信動作について説明する。図３６は、保留中の保留端末による保留ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３６０１）、保留中の保留端末である端末Ｂ０からＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３６０２）、ＣＡ２０は、そのリクエストはエラーであるとして４０３信号を端末Ｂ０に送信する（ステップＳ３６０３）。４０３信号を受信した端末Ｂ０は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ３６０４）。
【０２１８】
このように、本実施の形態によれば、保留中呼と同一ダイアログに対する保留信号に対しては、エラーとして処理する。
【０２１９】
次に、図３７を参照して、保留中の代理応答端末により保留ＩＮＶＩＴＥ送信動作について説明する。図３７は、保留中の代理応答端末により保留ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ３７０１）、代理応答端末となる端末Ｂ１からＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ３７０２）、ＣＡ２０は、端末Ｂ１のリクエストは端末Ａ１と端末Ｂ０の呼とは別の呼であると判断し、１００Ｔｒｙｉｎｇレスポンスを端末Ｂ１に送信し（ステップＳ３７０３）、ＩＮＶＩＴＥリクエストを端末Ａ１に転送する（ステップＳ３７０４）。
【０２２０】
ＩＮＶＩＴＥリクエスト転送後の処理は、図４で示したステップＳ４０４〜Ｓ４０９およびＳ４１１と同等の処理が行われる（ステップＳ３７０５〜Ｓ３７１１）。
【０２２１】
このように、本実施の形態によれば、保留中呼と異なるダイアログに対する保留信号に対しては、新規の呼として処理する。
【０２２２】
次に、図３８を参照して、独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作について説明する。図３８は、独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作を示すシーケンス図である。
「Ｐ−Ｎ−ＳｒｖＩｎｆｏ：ｃａｌｌｐａｒｋ」という独自ヘッダを有するＩＮＶＩＴＥリクエストを端末Ａ１から受信すると（ステップＳ３８０１）、ＣＡ２０は、そのヘッダを透過し、１００Ｔｒｙｉｎｇレスポンスを端末Ａ１に送信し（ステップＳ３８０２）、ＩＮＶＩＴＥリクエストを端末Ｂ０に転送する（ステップＳ３８０３）。
【０２２３】
ＩＮＶＩＴＥリクエスト転送後の処理は、図４で示したステップＳ４０４〜Ｓ４０９およびＳ４１１と同等の処理が行われる（ステップＳ３８０４〜Ｓ３８１０）。
【０２２４】
このように、本実施の形態によれば、新規呼接続要求（ｉｎｉ−ＩＮＶＩＴＥ）に不要なヘッダが付与されていてもそのヘッダを透過し、新規呼として処理を継続する。
【０２２５】
次に、図３９を参照して、他の独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作について説明する。図３９は、他の独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作を示すシーケンス図である。
図３８で示した独自ヘッダとは異なる独自ヘッダ「Ｐ−Ｎ−ＳｒｖＩｎｆｏ：ｔｒａｎｓｆｅｒ」を有するＩＮＶＩＴＥリクエストを端末Ａ１から受信すると（ステップＳ３９０１）、ＣＡ２０は、そのヘッダを透過し、１００Ｔｒｙｉｎｇレスポンスを端末Ａ１に送信し（ステップＳ３９０２）、ＩＮＶＩＴＥリクエストを端末Ｂ０に転送する（ステップＳ３９０３）。
【０２２６】
ＩＮＶＩＴＥリクエスト転送後の処理は、図４で示したステップＳ４０４〜Ｓ４０９およびＳ４１１と同等の処理が行われる（ステップＳ３９０４〜Ｓ３９１０）。
【０２２７】
このように、本実施の形態によれば、図３８の場合とは異なる新規呼接続要求（ｉｎｉ−ＩＮＶＩＴＥ）に不要なヘッダが付与されていてもそのヘッダを透過し、新規呼として処理を継続する。
【０２２８】
次に、図４０を参照して、保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信（ｒｅｐｌａｃｅｓ内容誤り）動作について説明する。図４０は、保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信（ｒｅｐｌａｃｅｓ内容誤り）動作を示すシーケンス図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ４００１）、代理応答端末となる端末Ｂ１からｒｅｐｌａｃｅｓ内容が誤ったＵＮＨＯＬＤのＩＮＶＩＴＥリクエストを受信すると（ステップＳ４００２）、ＣＡ２０は、端末Ｂ１に４０３信号を送信する（ステップＳ４００３）。４０３信号を受信した端末Ｂ１は、ＡＣＫメッセージをＣＡ２０に送信する（ステップＳ４００４）。
【０２２９】
このように、本実施の形態によれば、保留解除信号にコールパークサービス処理を継続するための情報が足りない場合は、エラーとして処理する。
【０２３０】
次に、図４１を参照して、保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信（ｒｅｐｌａｃｅｓなし）動作について説明する。図４１は、保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信（ｒｅｐｌａｃｅｓなし）動作を示す図である。
端末Ａ１と端末Ｂ０とがコールパーク保留中のときに（ステップＳ４１０１）、代理応答端末となる端末Ｂ１から「ｒｅｐｌａｃｅｓ」が含まれていない独自ヘッダを有するＩＮＶＩＴＥリクエストを端末Ａ１から受信すると（ステップＳ４１０２）、ＣＡ２０は、そのヘッダを透過し、１００Ｔｒｙｉｎｇレスポンスを端末Ａ１に送信し（ステップＳ４１０３）、ＩＮＶＩＴＥリクエストを端末Ｂ０に転送する（ステップＳ４１０４）。
【０２３１】
ＩＮＶＩＴＥリクエスト転送後の処理は、図４で示したステップＳ４０４〜Ｓ４０９およびＳ４１１と同等の処理が行われる（ステップＳ４１０５〜Ｓ４１１１）。
【０２３２】
このように、本実施の形態によれば、保留中呼として異なるダイアログに対する保留解除信号に対しては、新規呼として処理する。
【図面の簡単な説明】
【０２３３】
【図１】本発明のコールパークサービスシステムの構成を示す図である。
【図２】ＣＡ２０の構成を示すブロック図である。
【図３】（ａ）ＶＰＮ内線番号変換テーブル、（ｂ）パークグループ管理テーブル、（ｃ）ランプ番号管理テーブル、（ｄ）番号状態テーブルを示す図である。
【図４】コールパークサービスシステムの動作を示すシーケンス図である。
【図５】「通話中状態通知あり」、同一パークグループ内発着の状態通知の動作を説明する図である。
【図６】「通話中状態通知あり」、別パークグループ発着の発側パークグループ内の状態通知の動作を説明する図である。
【図７】「通話中状態通知あり」、別パークグループ発着の着側パークグループ内の状態通知の動作を説明する図である。
【図８】「通話中状態通知なし」、保留端末と同一パークグループ内への状態通知の動作を説明する図である。
【図９】通話中状態通知なしの場合の動作を示すシーケンス図である。
【図１０】ＲＥＧＩＳＴＥＲ端末への状態通知を示すシーケンス図である。
【図１１】保留前保留ＩＮＶＩＴＥのすれ違い動作のシーケンス図である。
【図１２】保留前保留ＩＮＶＩＴＥのすれ違い動作のシーケンス図である。
【図１３】保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
【図１４】保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
【図１５】保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
【図１６】保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
【図１７】保留解除ＩＮＶＩＴＥとｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
【図１８】ＡＣＫ前の保留解除ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
【図１９】保留解除ＩＮＶＩＴＥに対するエラーレスポンスを示すシーケンス図である。
【図２０】保留解除ＩＮＶＩＴＥとＢＹＥとのすれ違い動作を示すシーケンス図である。
【図２１】保留解除ＩＮＶＩＴＥ送信後のＣＡＮＣＥＬ送信動作を示すシーケンス図である。
【図２２】保留解除ＩＮＶＩＴＥ送信後のＢＹＥ送信動作を示すシーケンス図である。
【図２３】保留解除ＩＮＶＩＴＥ送信中の強制呼解放動作を示すシーケンス図である。
【図２４】保留解除ＩＮＶＩＴＥ送信中の系切替動作を示すシーケンス図である。
【図２５】ＡＣＫ前のＢＹＥ送信動作を示すシーケンス図である。
【図２６】ＡＣＫ前のｋｅｅｐａｌｉｖｅＩＮＶＩＴＥ送信動作を示すシーケンス図である。
【図２７】ＡＣＫ前のＢＹＥ送信動作を示すシーケンス図である。
【図２８】ＡＣＫ前のＣＡＮＣＥＬ動作を示すシーケンス図である。
【図２９】ＡＣＫ前のＢＹＥ送信動作を示すシーケンス図である。
【図３０】ＣＡのＢＹＥと保留端末のＢＹＥのすれ違い動作を示すシーケンス図である。
【図３１】ＣＡのＢＹＥと保留端末のｋｅｅｐａｌｉｖｅＩＮＶＩＴＥとのすれ違い動作を示すシーケンス図である。
【図３２】保留解除ＩＮＶＩＴＥのタイムアウト動作を示すシーケンス図である。
【図３３】２００レスポンスタイムアウト動作を示すシーケンス図である。
【図３４】複数端末からの保留解除操作の動作を示すシーケンス図である。
【図３５】保留元による早切り動作を示すシーケンス図である。
【図３６】保留端末による保留ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
【図３７】代理応答端末による保留ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
【図３８】独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作を示すシーケンス図である。
【図３９】独自ヘッダ付き新規ＩＮＶＩＴＥの送信動作を示すシーケンス図である。
【図４０】保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信動作を示すシーケンス図である。
【図４１】保留中の代理応答端末による保留解除ＩＮＶＩＴＥ送信動作を示す図である。
【符号の説明】
【０２３４】
１…ＶＰＮ、２…ＬＡＮ、１０…電話端末、２０…ＣＡ、２１…データ通信部、２２…制御部、２３…記憶部、２４…保留部。
【図１】
2006174112.tif 000003
【図２】
2006174112.tif 000004
【図３】
2006174112.tif 000005
【図４】
2006174112.tif 000006
【図５】
2006174112.tif 000007
【図６】
2006174112.tif 000008
【図７】
2006174112.tif 000009
【図８】
2006174112.tif 000010
【図９】
2006174112.tif 000011
【図１０】
2006174112.tif 000012
【図１１】
2006174112.tif 000013
【図１２】
2006174112.tif 000014
【図１３】
2006174112.tif 000015
【図１４】
2006174112.tif 000016
【図１５】
2006174112.tif 000017
【図１６】
2006174112.tif 000018
【図１７】
2006174112.tif 000019
【図１８】
2006174112.tif 000020
【図１９】
2006174112.tif 000021
【図２０】
2006174112.tif 000022
【図２１】
2006174112.tif 000023
【図２２】
2006174112.tif 000024
【図２３】
2006174112.tif 000025
【図２４】
2006174112.tif 000026
【図２５】
2006174112.tif 000027
【図２６】
2006174112.tif 000028
【図２７】
2006174112.tif 000029
【図２８】
2006174112.tif 000030
【図２９】
2006174112.tif 000031
【図３０】
2006174112.tif 000032
【図３１】
2006174112.tif 000033
【図３２】
2006174112.tif 000034
【図３３】
2006174112.tif 000035
【図３４】
2006174112.tif 000036
【図３５】
2006174112.tif 000037
【図３６】
2006174112.tif 000038
【図３７】
2006174112.tif 000039
【図３８】
2006174112.tif 000040
【図３９】
2006174112.tif 000041
【図４０】
2006174112.tif 000042
【図４１】
2006174112.tif 000043