(57)【要約】【課題】信号経路からのＳＩＰアプリケーションサーバの離脱を可能とする。【解決手段】ＳＩＰアプリケーションサーバ１００ｃは、信号経路からの離脱を表明する離脱予定表明ＰＢ１を行なう。離脱表明予定ＰＢ１では、信号経路の端点のＳＩＰアプリケーションサーバ１００ｄ及びＳＩＰアプリケーションサーバ１００ａに離脱表明信号が送信される（ステップＢ１ａ、Ｂ２ａ及びＢ３ａ）。この離脱表明信号に対して、ＳＩＰアプリケーションサーバ１００ａ又は１００ｄからエラー応答が返信されると（ステップＢ３ｃ及びＢ２ｃ）、ＳＩＰアプリケーションサーバ１００ｃは、信号経路からの離脱を中断する（ＰＢ１ａ）。ＳＩＰアプリケーションサーバ１００ｄ及び１００ａから成功応答が返信されると（ステップＢ１ｂ、Ｂ２ｂ及びＢ３ｂ）、信号経路からの離脱処理ＰＣが行われる。【選択図】      図２
2011049682.tif 000002
【特許請求の範囲】
【請求項１】
ＳＩＰ（Session Initiation Protocol）信号経路を構成し、当該信号経路を介して所定のサービスを提供するＳＩＰアプリケーションサーバであって、
前記信号経路からの離脱を表明する離脱表明信号を、前記信号経路の端点である他のＳＩＰアプリケーションサーバに送信する離脱表明手段と、
前記離脱表明信号に対する前記端点のＳＩＰアプリケーションサーバからの応答を受信する応答受信手段と、
前記応答受信手段がエラー応答を受信した場合は前記信号経路からの離脱を中断し、前記応答受信手段が成功応答を受信した場合は前記信号経路からの離脱を行なう離脱制御手段と、
を具備するＳＩＰアプリケーションサーバ。
【請求項２】
前記離脱表明手段は、前記ＳＩＰアプリケーションサーバと同じサービスを提供する他のＳＩＰアプリケーションサーバに、前記信号経路からの離脱を表明する離脱表明信号を送信し、
前記離脱制御手段は、前記応答受信手段が当該他のＳＩＰアプリケーションサーバからエラー応答を受信した場合は、前記信号経路からの離脱を中断し、前記応答受信手段が当該他のＳＩＰアプリケーションサーバから成功応答を受信した場合は、前記信号経路からの離脱を行なう、請求項１に記載のＳＩＰアプリケーションサーバ。
【請求項３】
前記離脱制御手段は、前記ＳＩＰアプリケーションサーバ及び隣接する第１のＳＩＰエンティティとの間に確立されたダイアログを、前記ＳＩＰアプリケーションサーバに隣接する第２のＳＩＰエンティティに継承させるダイアログ継承制御手段を更に具備する、請求項１に記載のＳＩＰアプリケーションサーバ。
【請求項４】
ＳＩＰ（Session Initiation Protocol）信号経路を介して所定のサービスを提供する第１のＳＩＰアプリケーションサーバと、当該ＳＩＰアプリケーションサーバと共に当該信号経路を構成する少なくとも１つのＳＩＰエンティティとからなるＳＩＰ通信システムであって、
前記第１のＳＩＰアプリケーションサーバは、
前記信号経路からの離脱を表明する離脱表明信号を、前記信号経路の端点である第２のＳＩＰアプリケーションサーバに送信する離脱表明手段と、
前記離脱表明信号に対する前記第２のＳＩＰアプリケーションサーバからの応答を受信する応答受信手段と、
前記応答受信手段がエラー応答を受信した場合は前記信号経路からの離脱を中断し、前記応答受信手段が成功応答を受信した場合は前記信号経路からの離脱を行なう離脱制御手段を具備し、
前記離脱表明信号を受信したＳＩＰエンティティは、
前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を許可しない場合は、前記エラー応答を前記第１のＳＩＰアプリケーションサーバに送信し、
前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を許可する場合は、前記成功応答を前記第１のＳＩＰアプリケーションサーバに送信するＳＩＰ通信システム。
【請求項５】
前記離脱制御手段は、前記第１のＳＩＰアプリケーションサーバ及び隣接する第１のＳＩＰエンティティとの間に確立されたダイアログを、前記第１のＳＩＰアプリケーションサーバに隣接する第２のＳＩＰエンティティに継承させるダイアログ継承制御手段を更に具備する、請求項４に記載のＳＩＰ通信システム。
【請求項６】
前記ダイアログ継承制御手段は、前記第１のＳＩＰエンティティを継承対象として指定する継承要求を前記第２のＳＩＰエンティティに送信し、
前記第２のＳＩＰエンティティは、前記第１のＳＩＰエンティティにコールを招待して新たなダイアログを確立する、請求項５に記載のＳＩＰ通信システム。
【請求項７】
ＳＩＰ（Session Initiation Protocol）信号経路を介して所定のサービスを提供する第１のＳＩＰアプリケーションサーバと、当該第１のＳＩＰアプリケーションサーバと共に当該信号経路を構成する少なくとも１つのＳＩＰエンティティとからなるＳＩＰ通信システムにおいて用いられる、前記第１のＳＩＰアプリケーションサーバの信号経路からの離脱方法であって、
前記信号経路からの離脱を表明する離脱表明信号を、前記第１のＳＩＰアプリケーションサーバから前記信号経路の端点である第２のＳＩＰアプリケーションサーバに送信する離脱表明ステップと、
前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を許可しない場合は、前記第２のＳＩＰアプリケーションサーバからエラー応答を前記第１のＳＩＰアプリケーションサーバに送信し、前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を許可する場合は、前記第２のＳＩＰアプリケーションサーバから成功応答を前記第１のＳＩＰアプリケーションサーバに送信する応答送信ステップと、
前記離脱表明信号に対する前記第２のＳＩＰアプリケーションサーバからの応答を前記第１のＳＩＰアプリケーションサーバが受信する応答受信ステップと、
前記エラー応答が受信された場合は、前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を中断し、前記成功応答が受信されたた場合は前記信号経路からの離脱を行なう離脱制御ステップと、
を具備する信号経路からの離脱方法。
【請求項８】
前記離脱制御ステップは、前記第１のＳＩＰアプリケーションサーバ及び隣接する第１のＳＩＰエンティティとの間に確立されたダイアログを、前記ＳＩＰアプリケーションサーバに隣接する第２のＳＩＰエンティティに継承させるダイアログ継承制御ステップを更に具備する、請求項７に記載の信号経路からの離脱方法。
【請求項９】
前記ダイアログ継承制御ステップは、前記第１のＳＩＰエンティティを継承対象として指定する継承要求を前記第１のＳＩＰアプリケーションサーバから前記第２のＳＩＰエンティティに送信するステップと、
前記第２のＳＩＰエンティティから前記第１のＳＩＰエンティティにコールを招待して新たなダイアログを確立するステップを更に具備する、請求項８に記載の信号経路からの離脱方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＩＰ信号経路からのＳＩＰアプリケーションサーバの離脱を可能とするＳＩＰアプリケーションサーバ、ＳＩＰ通信システム、及び信号経路からの離脱方法に関する。
【背景技術】
【０００２】
ＩＭＳ(IP Multimedia Subsystem)ネットワークは、ＩＰネットワーク上で電話の発着信を制御するためのプロトコルであるＳＩＰ（session initiation protocol）をベースとしている。ＩＭＳを利用するサービスでは、加入者のサービス加入条件は、登録サーバ上で保持及び管理されている。加入者からの発信時、又は加入者への着信時には、当該加入条件に従って、新規ダイアログ確立リクエストがＳＩＰサーバからＳＩＰアプリケーションサーバ（ＳＩＰ−ＡＳ）へルーチングされる。ＳＩＰアプリケーションサーバは以降、当該ＳＩＰダイアログ中のＳＩＰ信号経路に介在し、様々なマルチメディア通信サービスを提供する。
【０００３】
例えば非特許文献１に記載されたＳＩＰアプリケーションサーバは、受信したＳＩＰリクエスト中のRecord-Routeヘッダに自らのＵＲＩ(Uniform Resource Identifier)を挿入して中継し、以降のＳＩＰ信号経路に自らを配置する。このＳＩＰアプリケーションサーバによって、経路の両端のエンドポイントに対するＳＩＰ信号、音声・映像メディアの送信などが制御され、エンドポイントに対してマルチメディアサービスが提供される。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】3GPP TS 24.237 V8.2.0 (2009-06) 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) Service continuity; Stage 3 (Release 8)
【発明の概要】
【発明が解決しようとする課題】
【０００５】
例えばサービスの提供を受けていたエンドポイントが当該サービスの利用を中止する場合等に、当該サービスを提供していたＳＩＰアプリケーションサーバは以降、単にＳＩＰ信号の中継点としてのみ機能する。
非特許文献１記載の技術では、ＳＩＰアプリケーションサーバはいったんＳＩＰ信号経路に組み込まれると、エンド間のＳＩＰ信号通信を維持したまま信号経路から離脱することができない。すなわち、ＳＩＰアプリケーションサーバは、一度組み込まれた信号経路上には切断終了まで介在し続ける必要がある。このため、ＳＩＰアプリケーションサーバの処理負荷の増大、ＳＩＰ信号の遅延の増大、ＳＩＰ信号数増加によるネットワークリソースの浪費が生じる。
【０００６】
また、ＳＩＰアプリケーションサーバが信号経路から離脱する場合に、同一経路上で同種類のＳＩＰアプリケーションサーバの離脱が同時に生じると、これらのアプリケーションサーバが提供していたサービスが、予期せずに提供できなくなることがある。
本発明は、上記の事情を鑑みてなされたもので、当該ＳＩＰダイアログ内のＳＩＰ信号経路からＳＩＰアプリケーションサーバを離脱可能とするＳＩＰアプリケーションサーバ、ＳＩＰ通信システム及びＳＩＰ信号経路からの離脱方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係るＳＩＰアプリケーションサーバは以下のような態様の構成とする。  
（１）ＳＩＰ（Session Initiation Protocol）信号経路を構成し、当該信号経路を介して所定のサービスを提供するＳＩＰアプリケーションサーバであって、前記信号経路からの離脱を表明する離脱表明信号を、前記信号経路の端点である他のＳＩＰアプリケーションサーバに送信する離脱表明手段と、前記離脱表明信号に対する前記端点のＳＩＰアプリケーションサーバからの応答を受信する応答受信手段と、前記応答受信手段がエラー応答を受信した場合は前記信号経路からの離脱を中断し、前記応答受信手段が成功応答を受信した場合は前記信号経路からの離脱を行なう離脱制御手段を具備する態様とする。  
この態様によれば、信号経路上で離脱を表明し、離脱に問題がないことが確認されてから信号経路からの離脱が行なわれる。このため、複数のサーバの同時離脱による予期せぬ通信の切断を防止することが可能となる。
【０００８】
（２）（１）の構成において、前記離脱表明手段は、前記ＳＩＰアプリケーションサーバと同じサービスを提供する他のＳＩＰアプリケーションサーバに、前記信号経路からの離脱を表明する離脱表明信号を送信し、前記離脱制御手段は、前記応答受信手段が当該他のＳＩＰアプリケーションサーバからエラー応答を受信した場合は、前記信号経路からの離脱を中断し、前記応答受信手段が当該他のＳＩＰアプリケーションサーバから成功応答を受信した場合は、前記信号経路からの離脱を行なう態様とする。  
この態様によれば、同じサービスを提供するＳＩＰアプリケーションサーバに離脱を表明し、サービスの提供に影響を与えないと判断されて当該同じサービスを提供するＳＩＰアプリケーションサーバからの成功応答を受信した場合に、信号経路から離脱することができる。
【０００９】
（３）（１）の態様において、前記離脱制御手段は、前記ＳＩＰアプリケーションサーバ及び隣接する第１のＳＩＰエンティティとの間に確立されたダイアログを、前記ＳＩＰアプリケーションサーバに隣接する第２のＳＩＰエンティティに継承させるダイアログ継承制御手段を更に具備する態様とする。  
この態様によれば、信号経路からの離脱に際してダイアログを他のエンティティに継承することができる。
【００１０】
また、本発明に係るＳＩＰ通信システムは以下のような態様の構成とする。  
（４）ＳＩＰ（Session Initiation Protocol）信号経路を介して所定のサービスを提供する第１のＳＩＰアプリケーションサーバと、当該第１のＳＩＰアプリケーションサーバと共に当該信号経路を構成する少なくとも１つのＳＩＰエンティティとからなるＳＩＰ通信システムであって、前記第１のＳＩＰアプリケーションサーバは、前記信号経路からの離脱を表明する離脱表明信号を、前記信号経路の端点である第２のＳＩＰアプリケーションサーバに送信する離脱表明手段と、前記離脱表明信号に対する前記第２のＳＩＰアプリケーションサーバからの応答を受信する応答受信手段と、前記応答受信手段がエラー応答を受信した場合は前記信号経路からの離脱を中断し、前記応答受信手段が成功応答を受信した場合は前記信号経路からの離脱を行なう離脱制御手段を具備し、前記離脱表明信号を受信したＳＩＰエンティティは、前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を許可しない場合は、前記エラー応答を前記第１のＳＩＰアプリケーションサーバに送信し、前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を許可する場合は、前記成功応答を前記第１のＳＩＰアプリケーションサーバに送信する態様とする。  
この態様によれば、信号経路上で離脱を表明し、離脱に問題がないことが確認されてから信号経路からの離脱が行なわれる。このため、複数のサーバの同時離脱による予期せぬ通信の切断を防止することが可能となる。
【００１１】
（５）（４）の構成において、前記離脱制御手段は、前記第１のＳＩＰアプリケーションサーバ及び隣接する第１のＳＩＰエンティティとの間に確立されたダイアログを、前記第１のＳＩＰアプリケーションサーバに隣接する第２のＳＩＰエンティティに継承させるダイアログ継承制御手段を更に具備する態様とする。  
この態様によれば、信号経路からの離脱に際してダイアログを他のエンティティに継承することができる。
【００１２】
（６）（５）の構成において、前記ダイアログ継承制御手段は、前記第１のＳＩＰエンティティを継承対象として指定する継承要求を前記第２のＳＩＰエンティティに送信し、前記第２のＳＩＰエンティティは、前記第１のＳＩＰエンティティにコールを招待して新たなダイアログを確立する態様とする。  
この態様によれば、ＳＩＰアプリケーションサーバから指定される継承対象のダイアログを継承する新たなダイアログを確立することができる。
【００１３】
また、本発明に係る信号経路からの離脱方法は以下のような態様の構成とする。  
（７）ＳＩＰ（Session Initiation Protocol）信号経路を介して所定のサービスを提供する第１のＳＩＰアプリケーションサーバと、当該第１のＳＩＰアプリケーションサーバと共に当該信号経路を構成する少なくとも１つのＳＩＰエンティティとからなるＳＩＰ通信システムにおいて用いられる、前記第１のＳＩＰアプリケーションサーバの信号経路からの離脱方法であって、前記信号経路からの離脱を表明する離脱表明信号を、前記第１のＳＩＰアプリケーションサーバから前記信号経路の端点である第２のＳＩＰアプリケーションサーバに送信する離脱表明ステップと、前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を許可しない場合は、前記第２のＳＩＰアプリケーションサーバからエラー応答を前記第１のＳＩＰアプリケーションサーバに送信し、前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を許可する場合は、前記第２のＳＩＰアプリケーションサーバから成功応答を前記第１のＳＩＰアプリケーションサーバに送信する応答送信ステップと、前記離脱表明信号に対する前記第２のＳＩＰアプリケーションサーバからの応答を前記第１のＳＩＰアプリケーションサーバが受信する応答受信ステップと、前記エラー応答が受信された場合は、前記第１のＳＩＰアプリケーションサーバの前記信号経路からの離脱を中断し、前記成功応答が受信されたた場合は前記信号経路からの離脱を行なう離脱制御ステップを具備する態様とする。  
この態様によれば、信号経路上で離脱を表明し、離脱に問題がないことが確認されてから信号経路からの離脱が行なわれる。このため、複数のサーバの同時離脱による予期せぬ通信の切断を防止することが可能となる。
【００１４】
（８）前記離脱制御ステップは、前記第１のＳＩＰアプリケーションサーバ及び隣接する第１のＳＩＰエンティティとの間に確立されたダイアログを、前記ＳＩＰアプリケーションサーバに隣接する第２のＳＩＰエンティティに継承させるダイアログ継承制御ステップを更に具備する態様とする。  
この態様によれば、信号経路からの離脱に際してダイアログを他のエンティティに継承することができる。
【００１５】
（９）前記ダイアログ継承制御ステップは、前記第１のＳＩＰエンティティを継承対象として指定する継承要求を前記第１のＳＩＰアプリケーションサーバから前記第２のＳＩＰエンティティに送信するステップと、前記第２のＳＩＰエンティティから前記第１のＳＩＰエンティティにコールを招待して新たなダイアログを確立するステップを更に具備する態様とする。  
この態様によれば、ＳＩＰアプリケーションサーバから指定される継承対象のダイアログを継承する新たなダイアログを確立することができる。
【発明の効果】
【００１６】
本発明によれば、信号経路からＳＩＰアプリケーションサーバを離脱可能とするＳＩＰアプリケーションサーバ、ＳＩＰ通信システム及びＳＩＰ信号経路からの離脱方法を提供することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本発明の一実施形態に係るＳＩＰアプリケーションサーバの機能構成を示す機能ブロック図。
【図２】ＳＩＰアプリケーションサーバが信号経路から離脱する場合に行われる、離脱予定表明手順を示すシークエンス図。
【図３】信号経路からの離脱を表明するリクエストメッセージの一例を示す図。
【図４】ＳＩＰアプリケーションサーバが、他のサーバにＳＩＰダイアログを継承してＳＩＰ信号経路から離脱する場合に用いられるダイアログ継承手順及び離脱手順を示すシークエンス図。
【図５】ダイアログ継承を要求するリクエストメッセージの一例を示す図。
【図６】ダイアログを継承するためのリクエストメッセージの一例を示す図。
【図７】ＳＩＰアプリケーションサーバが離脱したことを通知するメッセージの一例を示す図。
【図８】離脱決定がなされたＳＩＰアプリケーションサーバが、信号経路上の他のＳＩＰエンティティに対して離脱予定を表明する際に行われる処理を示すフローチャート。
【図９】ＳＩＰアプリケーションサーバが信号経路上の他のサーバから離脱予定表明メッセージを受信した場合に行われる処理を示すフローチャート。
【図１０】離脱予定表明を行なったＳＩＰアプリケーションサーバが、信号経路上の他のＳＩＰエンティティに対してダイアログの継承を要求する際に行われる処理を示すフローチャート。
【図１１】ダイアログの継承要求リクエストの送信先エンティティが複数検出された場合に行われる処理を示すフローチャート。
【図１２】ＳＩＰアプリケーションサーバが信号経路上の他のサーバから継承要求メッセージを受信した場合に行われる処理を示すフローチャート。
【図１３】ダイアログ継承要求リクエストを受信したＳＩＰアプリケーションサーバが、当該リクエストで指定されているダイアログを継承する際に行われる処理を示すフローチャート。
【図１４】信号経路から離脱した他のサーバからダイアログを継承したＳＩＰアプリケーションサーバが、他のＳＩＰエンティティに対して当該サーバの離脱を通知する際に行われる処理を示すフローチャート。
【発明を実施するための形態】
【００１８】
以下、図面を参照して本発明の実施の形態を詳細に説明する。
図１は、本発明の一実施形態に係るＳＩＰアプリケーションサーバ１００の機能構成を示す機能ブロック図である。
ＳＩＰアプリケーションサーバ１００は、アプリケーションサービスロジック格納部１０１、アプリケーションサービスロジック管理部１０２、離脱判定基準データ格納部１０３、離脱判定基準データ管理部１０４、ＳＩＰ呼制御部１０５、セッション管理用データ格納部１０６、離脱判定部１０７、ＳＩＰヘッダ制御部１０８、ＳＩＰメッセージボディ制御部１０９、ＳＩＰ通信制御部１１０、ＳＩＰセッションタイマ制御部１１１、及びソケット部１２０を有する。
【００１９】
ソケット部１２０には、ＳＩＰアプリケーションサーバ１００に接続される種々の機器の接続端子が挿入される。例えば、ＳＩＰアプリケーションサーバ１００がＳＩＰ通信ネットワークＳＮに接続するための接続ケーブルの接続端子は、ソケット部１２０に接続される。また、保守ネットワークＭＮへの接続ケーブルの接続端子も、ソケット部１２０に接続される。ＳＩＰアプリケーションサーバ１００に接続される機器には、図示は省略するが、入力装置や、表示装置等の出力装置等も含まれ得る。
【００２０】
ＳＩＰ通信ネットワークＳＮは、例えばＩＭＳネットワーク等のＳＩＰに基づくＩＰ通信ネットワークである。ＳＩＰ通信ネットワークＳＮは、ＳＩＰサーバ及びＳＩＰアプリケーションサーバ（ＡＳ）同士の接続によって構成される。これらのサーバは、ＩＰ電話等のＩＰ端末間でセッションを確立させる機能を有する。
【００２１】
保守ネットワークＭＮには、ＳＩＰアプリケーションサーバ１００が保持するデータを更新するための端末が接続されている。例えばＳＩＰアプリケーションサーバ１００のサービスロジックに変更が必要となると、ＳＩＰアプリケーションサーバ１００の設置者は、当該端末から保守ネットワークＭＮを介して更新ロジックを送信する。
【００２２】
アプリケーションサービスロジック格納部１０１は、ＳＩＰアプリケーションサーバ１００が提供するサービスアプリケーションのロジックを格納している。このロジックは、ＳＩＰアプリケーションサーバ１００のＣＰＵ（図示せず）が実行可能なプログラムとして格納されていてもよい。アプリケーションサービスロジック管理部１０２は、保守ネットワークＭＮから送信される情報に基づいて、アプリケーションサービスロジック格納部１０１に格納されているサービスロジックを管理する。保守ネットワークＭＮから更新ロジックが送信されたら、アプリケーションサービスロジック管理部１０２は、アプリケーションサービスロジック格納部１０１に格納されているロジックを更新する。
【００２３】
離脱判定基準データ格納部１０３は、ＳＩＰ信号経路からの離脱判定基準データ、及び離脱実行状態データを格納する。離脱判定基準データは、ＳＩＰアプリケーションサーバ１００が、どのような場合にダイアログから離脱できるのかの判定基準を示す。例えば信号経路上にＳＩＰアプリケーションサーバ１００と同じサービスを提供する他のサーバ存在し、当該ＳＩＰアプリケーションサーバ１００は信号の中継点としてのみ機能している場合に、当該ＳＩＰアプリケーションサーバ１００はダイアログから離脱できる。また、離脱実行状態データは、ＳＩＰアプリケーションサーバ１００が現在離脱実行中であるか、あるいは離脱予定であるか等の離脱処理の実行状態を示す。
【００２４】
離脱判定基準データ管理部１０４は、離脱判定基準格納部１０３に格納されている離脱判定基準データを、保守ネットワークＭＮを介して送信される情報に基づいて更新する。すなわち、ＳＩＰアプリケーションサーバ１００がどのような場合にダイアログから離脱できるかは、外部端末からでも保守ネットワークＭＮを介して更新できる。
【００２５】
ＳＩＰ呼制御部１０５は、ＳＩＰアプリケーションサーバ１００の各部を制御して、ＳＩＰに基づく呼(コール)制御（シグナリング）を行なう。呼制御（シグナリング）は、発信者と着信者の間のネットワーク上で、通信路の確保や切断等の処理を行うことを指す。ＳＩＰ呼制御部１０５は、ＳＩＰ通信ネットワークＳＮ上でのダイアログやセッションの確立や切断を制御する。セッション管理用データ格納部１０６は、ＳＩＰ呼制御部１０５がＳＩＰセッションを確立するために必要とするＳＩＰセッション管理データを格納する。ＳＩＰセッション管理データには、ＳＩＰアプリケーションサーバ１００のＳＩＰ−ＵＲＩやＩＰアドレスといった情報が含まれる。
【００２６】
離脱判定部１０７は、離脱判定基準データ格納部１０３に格納された離脱判定基準データ及びセッション管理用データ格納部１０６に格納されたセッション管理用データに基づいて、ＳＩＰ信号経路からの離脱可否、あるいは他のＳＩＰアプリケーションサーバの離脱可否（他のＳＩＰアプリケーションサーバの離脱表明に対する許可又は不許可）を、ＳＩＰ呼制御部１０５による制御に応じて判定する。判定結果はＳＩＰ呼制御部１０５に送信される。
【００２７】
ＳＩＰヘッダ制御部１０８は、ＳＩＰ呼制御部１０５による制御に応じて、ＳＩＰメッセージのヘッダ部を生成する。ＳＩＰメッセージのヘッダ部には、当該ＳＩＰアプリケーションサーバ１００のＳＩＰ−ＵＲＩ、ＳＩＰアプリケーションサーバ１００のサーバとしての種別（提供するサービスの種別）を表すＩＤ、ＳＩＰメッセージの宛て先等が記述される。
【００２８】
ＳＩＰメッセージボディ制御部１０９は、ＳＩＰ呼制御部１０５による制御に応じて、ＳＩＰメッセージのボディ部を生成する。ＳＩＰメッセージのボディ部には、使用できるメディアやパラメータ等、ＳＩＰメッセージの本文が記述される。
ＳＩＰ通信制御部１１０は、ＳＩＰ呼制御部１０５の制御によってＳＩＰヘッダ生成部１０８及びＳＩＰメッセージボディ生成部１０９が生成したＳＩＰメッセージをソケット部１２０に転送する。当該ＳＩＰメッセージは、ソケット部１２０を介してＳＩＰ通信ネットワークＳＮに出力され、ＳＩＰ通信ネットワークＳＮを介して宛て先のアドレスへ送信される。また、ＳＩＰ通信制御部１１０は、ＳＩＰ通信ネットワークＳＮを介して他のサーバからのＳＩＰメッセージを受信し、ＳＩＰ呼制御部１０５に転送する。ＳＩＰ通信制御部１１０が、受信したメッセージの解析を行ってもよい。ＳＩＰアプリケーションサーバ１００からのリクエストに対して、他のサーバからＲｅｔｒｙ−Ａｆｔｅｒヘッダをもつレスポンスが送られた場合、ＳＩＰ通信制御部１１０は、当該ヘッダで指定された待機時間の後にリクエスト送信を再試行する。
【００２９】
ＳＩＰセッションタイマ制御部１１１は、計時動作を行なうタイマを有する。ＳＩＰセッションタイマ制御部１１１は、確立されたＳＩＰセッションの起動時間や、他のサーバからのエラー応答を受けてからの待機時間等を計時し、計時結果をＳＩＰ呼制御部１０５に通知する。
【００３０】
次に、以上のように構成されたＳＩＰアプリケーションサーバが、確立済みのＳＩＰ信号経路から離脱する動作について説明する。
離脱予定表明手順  
図２は、ＳＩＰアプリケーションサーバが信号経路から離脱する場合に行われる、離脱予定表明手順を示すシークエンス図である。図２に示す離脱予定表明手順では、ＳＩＰ信号経路から離脱するＳＩＰアプリケーションサーバは、信号経路上の他のサーバに離脱予定があることを表明し、当該離脱予定表明に対して成功応答が返信された場合に、離脱処理を実行する。
【００３１】
図２では、４つのＳＩＰアプリケーションサーバ１００ａ、１００ｂ、１００ｃ及び１００ｄが図示されている。ＳＩＰアプリケーションサーバ１００ａ、１００ｂ、１００ｃ及び１００ｄの間では、マルチメディアセッションが確立されており、サーバ間ではマルチメディアデータのやり取りが行なわれている。
【００３２】
図２に示すように、ＳＩＰアプリケーションサーバ１００ａと１００ｂの間にはＳＩＰダイアログＤ１が、ＳＩＰアプリケーション１００ｂと１００ｃの間にはＳＩＰダイアログＤ２が、またＳＩＰアプリケーションサーバ１００ｃと１００ｄの間にはＳＩＰダイアログＤ３が確立している。なお、ダイアログとは、２つのＳＩＰエンティティ間で一定期間継続するピア・ツー・ピアのＳＩＰ関係である。なお、ダイアログを表すＤ３は、ローカルタグ、リモートタグ、Ｃａｌｌ−ＩＤのセットとして記述される。信号経路Ｄ１−Ｄ２−Ｄ３の端点（エンド）は、ＳＩＰアプリケーションサーバ１００ａ及び１００ｄである。
【００３３】
以下では、ＳＩＰアプリケーションサーバ１００ｃがこの信号経路からの離脱を表明する例について説明する。ＳＩＰアプリケーションサーバ１００ｃは、図１に示すＳＩＰアプリケーションサーバと同様の構成を有する。他のサーバも同様に、図１に示すような構成を有する。図２では、ＳＩＰアプリケーションサーバ１００ａ及び１００ｃが同様のサービスを提供しており、同じサービスＩＤ「００１」が割り当てられている。
【００３４】
例えばＳＩＰアプリケーションサーバ１００ｃが提供していたサービスの利用が終了する等して、離脱判定基準データ格納部１０３に格納されている離脱判定基準が満足されると、ＳＩＰアプリケーションサーバ１００ｃのＳＩＰ呼制御部１０５は、ＳＩＰ信号経路Ｄ１−Ｄ２−Ｄ３からの離脱を決定する（ＰＡ）。そして、ＳＩＰアプリケーションサーバ１００ｃは、信号経路Ｄ１−Ｄ２−Ｄ３を構成する各サーバに対して、離脱予定表明ＰＢ１を行なう。
【００３５】
離脱予定表明ＰＢ１において、ＳＩＰアプリケーションサーバ１００ｃは、信号経路の端点のＳＩＰアプリケーションサーバ１００ｄに、図３に示すようなＵＰＤＡＴＥリクエスト２００を送信する（ステップＢ１ａ）。ＵＰＤＡＴＥリクエスト２００は、ＳＩＰ呼制御部１０５の制御に基づいて生成され、リクエスト行２１０、ヘッダ部２２０及びボディ部２３０を含む。リクエスト行２１０には、メソッドとしてＵＰＤＡＴＥ（更新）が記載されている。ヘッダ部２２０はＳＩＰヘッダ制御部１０８によって生成され、図３に示すようなヘッダフィールド「Ｘ−Ｈｅａｄｅｒ：＜ＡＳ−１００ｃ；ＩＤ００１；ｗｉｔｈｄｒｏｗ＞」が含まれる。このヘッダフィールドに含まれる識別子「ｗｉｔｈｄｒａｗ」が、当該ＳＩＰアプリケーションサーバ１００ｃが離脱予定であることを表す。また、「Ｘ−ｈｅａｄｅｒ」は、ユーザによる指定が可能な、非標準のヘッダフィールドである。ボディ部２３０はＳＩＰメッセージボディ制御部１０９によって生成されるメッセージ本文であり、空であってもよい。
【００３６】
ＵＰＤＡＴＥリクエストメッセージ２００を受信したＳＩＰアプリケーションサーバ１００ｄの離脱判定部１０７がＳＩＰアプリケーションサーバ１００ｃの離脱を許可すると判定したら、当該ＳＩＰアプリケーションサーバ１００ｄの呼制御部１０５の制御に応じて成功応答コード「２００  ＯＫ」が生成され、ＳＩＰアプリケーションサーバ１００ｃに返信される（ステップＢ１ｂ）。
【００３７】
ＳＩＰアプリケーションサーバ１００ｃはまた、信号経路の他方の端点であるＳＩＰアプリケーションサーバ１００ａ宛のＵＰＤＡＴＥリクエスト２００を、ＳＩＰアプリケーションサーバ１００ｂへ送信する（ステップＢ２ａ）。ＳＩＰアプリケーションサーバ１００ｂは、当該リクエストをＳＩＰアプリケーションサーバ１００ａに中継転送する（ステップＢ３ａ）。
【００３８】
離脱予定を表明するためのＵＰＤＡＴＥリクエストメッセージは、信号経路上に存在するサーバの中でＳＩＰアプリケーションサーバ１００ｃから最も遠いサーバに対して、当該信号経路を構成するＳＩＰダイアログ内のリクエストとして送信される。ＳＩＰアプリケーションサーバ１００ｃが経路の端点でない場合は、経路の両端に向けてそれぞれ送信されるものとする。
【００３９】
信号経路の端点であり、ＳＩＰアプリケーションサーバ１００ｃと同じサービスを提供する（同じサービスＩＤ００１が割り当てられている）ＳＩＰアプリケーションサーバ１００ａが離脱処理ＰＣ´を行なっている場合、ＳＩＰアプリケーションサーバ１００ａの離脱判定基準データ格納部１０３には、ＳＩＰアプリケーションサーバ１００ａが離脱実行中であることを示す離脱実行状態データが格納されている。このため、ＳＩＰアプリケーションサーバ１００ａの離脱判定部１０７は、ＳＩＰアプリケーションサーバ１００ｃの離脱を許可しない。この判定結果に基づいて、ＳＩＰアプリケーションサーバ１００ａのＳＩＰ通信制御部１１０からは、リクエストエラー応答コード「４８０  Temporarily Unavailable」が、ＳＩＰアプリケーションサーバ１００ｂに送信される（ステップＢ３ｃ）。このリクエストエラー応答コードのヘッダ部には、後述するようにＲｅｔｒｙ−Ａｆｔｅｒヘッダが記述され、所定の待機時間が指定されてもよい。ＳＩＰアプリケーションサーバ１００ｂは、当該応答コードをＳＩＰアプリケーションサーバ１００ｃに中継転送する（ステップＢ２ｃ）。
【００４０】
いずれかのサーバからのリクエストエラー応答コードを受信すると、ＳＩＰアプリケーションサーバ１００ｃは、処理を中断する（ＰＢ１ａ）。例えばエラー応答コードにＲｅｔｒｙ−Ａｆｔｅｒヘッダが記述されている場合、ＳＩＰアプリケーションサーバ１００ｃは、当該ヘッダにおいて指定されている待機時間の間、処理を中断する。当該待機時間の後、ＳＩＰ通信制御部１１０によってＵＰＤＡＴＥメッセージ２００が再送信されてもよい。
【００４１】
ＳＩＰアプリケーションサーバ１００ａによる離脱処理ＰＣ´が終了すると、ＳＩＰアプリケーションサーバ１００ａは、成功応答コード「２００  ＯＫ」をＳＩＰアプリケーションサーバ１００ｂに送信する（ステップＢ３ｂ）。ＳＩＰアプリケーションサーバ１００ｂは、当該応答コードをＳＩＰアプリケーションサーバ１００ｃに中継転送する（ステップＢ２ｂ）。
【００４２】
ＳＩＰアプリケーションサーバ１００ｃは、両端のＳＩＰアプリケーションサーバからの成功応答コードを受け取ると、後述する離脱処理ＰＣを実行することができる。  
このように、図２に示す離脱予定表明手順によれば、ＳＩＰアプリケーションサーバが信号経路からの離脱を決定した場合に、当該信号経路に対して離脱予定を示す識別子（ｗｉｔｈｄｒａｗ）を含むメッセージ（ＵＰＤＡＴＥ）を送信する。このメッセージに対して、成功応答コードが返信されて離脱に問題がないことが確認されたら、信号経路からの離脱が行なわれる。このため、複数のサーバの同時離脱による予期せぬエンド−エンド間通信の切断を防止することができる。
【００４３】
なお、図２の離脱予定表明ＰＢ１では、離脱予定の通知のためにＵＰＤＡＴＥメッセージが用いられたが、その他のメソッドパラメータが用いられてもよい。また、離脱予定を示す識別子として「ｗｉｔｈｄｒａｗ」が用いられたが、離脱予定を示す識別子はこれに限定されない。また、他のサーバ（ＳＩＰアプリケーションサーバ１００ａ）が離脱処理ＰＣ´中である場合に限らず、他のサーバの離脱予定がすでに表明されている場合にも、当該他のサーバからエラー応答が返信され、離脱が中断される（ＰＢ１ａ）。
【００４４】
また、離脱予定を表すＵＰＤＡＴＥメッセージを受信したサーバは、当該メッセージの送信元のＳＩＰアプリケーションサーバが、自身と異なるＳＩＰアプリケーションサーバ種別であるか、あるいは同じ種別ではあるが当該送信元のＳＩＰアプリケーションサーバの離脱がサービスの提供に影響を与えないと判断した場合に、ＵＰＤＡＴＥメッセージをそのまま信号経路上の次のサーバに中継する（図２ではＳＩＰアプリケーションサーバ１００ｂ）。ただし、自身が端点である場合には成功応答コードを返信する（図２ではＳＩＰアプリケーションサーバ１００ｄ）。
【００４５】
離脱予定を表すＵＰＤＡＴＥメッセージを受信したサーバは、当該メッセージの送信元のＳＩＰアプリケーションサーバが、自身と同じ種別のＳＩＰアプリケーションサーバ種別であり、且つ自身が離脱中又は離脱表明中であって、送信元のＳＩＰアプリケーションサーバの離脱がサービスの提供に影響を与える判断した場合に、エラー応答コードを返信して、離脱表明を中継しない（図２ではＳＩＰアプリケーションサーバ１００ａ）。
【００４６】
ダイアログ継承手順及び離脱手順  
次に、サーバ間でダイアログを継承しつつ、信号経路から離脱する手順について説明する。図４は、ＳＩＰアプリケーションサーバが、他のサーバにＳＩＰダイアログを継承してＳＩＰ信号経路から離脱する場合に用いられるダイアログ継承手順及び離脱手順を示すシークエンス図である。図４に示す手順では、ＳＩＰ信号経路から離脱するＳＩＰアプリケーションサーバが信号経路上の他のサーバに離脱予定があることを表明し、両側のサーバがダイアログを継承した後、離脱処理が実行される。
【００４７】
図４では、４つのＳＩＰアプリケーションサーバ１００ａ、１００ｂ、１００ｃ及び１００ｄが図示されている。ＳＩＰアプリケーションサーバ１００ａ、１００ｂ、１００ｃ及び１００ｄの間では、マルチメディアセッションが確立されており、サーバ間ではマルチメディアデータのやり取りが行なわれている。
【００４８】
図４に示すように、ＳＩＰアプリケーションサーバ１００ａと１００ｂの間にはＳＩＰダイアログＤ１が、ＳＩＰアプリケーション１００ｂと１００ｃの間にはＳＩＰダイアログＤ２が、またＳＩＰアプリケーションサーバ１００ｃと１００ｄの間にはＳＩＰダイアログＤ３が確立し、ＳＩＰ信号経路が形成されている。
【００４９】
以下では、ＳＩＰアプリケーションサーバ１００ｃがこの信号経路から離脱する例について説明する。ＳＩＰアプリケーションサーバ１００ｃは、図１に示すＳＩＰアプリケーションサーバと同様の構成を有する。他のサーバも同様に、図１に示すような構成を有する。図４では、ＳＩＰアプリケーションサーバ１００ａ及び１００ｃが同様のサービスを提供しており、同じサービスＩＤ「００１」が割り当てられている。
【００５０】
例えばＳＩＰアプリケーションサーバ１００ｃが提供していたサービスの利用が終了すると、ＳＩＰアプリケーションサーバ１００ｃのＳＩＰ呼制御部１０５は、ＳＩＰ信号経路Ｄ１−Ｄ２−Ｄ３からの離脱を決定する（ＰＡ）。そして、ＳＩＰアプリケーションサーバ１００ｃは、信号経路を構成する各サーバに対して、離脱予定表明ＰＢ１を行なう。離脱決定ＰＡ及び離脱予定表明ＰＢ１の手順は、図２に示す離脱決定ＰＡ及び離脱予定表明ＰＢ１と同様なので、説明を省略する。
【００５１】
ＳＩＰアプリケーションサーバ１００ｃは、離脱予定表明ＰＢ１において、両端のＳＩＰアプリケーションサーバから成功応答コードを受け取ると（ステップＢ１ｂ及びＢ２ｃ）、ダイアログ継承処理ＰＢ２を行なう。  
ダイアログ継承ＰＢ２において、ＳＩＰアプリケーションサーバ１００ｃは、ＳＩＰアプリケーションサーバ１００ｂに、図５に示すようなＲＥＦＥＲリクエスト３００を送信し（ステップＣ２ａ）、ダイアログの継承を要求する。ＲＥＦＥＲリクエスト３００は、ＳＩＰ呼制御部１０５の制御に基づいて生成され、リクエスト行３１０、ヘッダ部３２０及びボディ部３３０を含む。リクエスト行３１０には、メソッドとしてＲＥＦＥＲ（参照）が記載されている。ヘッダ部３２０はＳＩＰヘッダ制御部１０８によって生成され、図５に示すようなヘッダフィールド「Ｒｅｆｅｒ−Ｔｏ：＜ＡＳ−１００ｄ；Ｒｅｐｌａｃｅｓ＝Ｄ３＞」が含まれる。Ｒｅｆｅｒ−Ｔｏヘッダは、指定されたエンティティへの参照を求めるリクエストメッセージであり、「ＡＳ−１００ｄ」は参照先としてＳＩＰアプリケーションサーバ１００ｄを指定する。ここで、「ＡＳ−１００ｄ」はアプリケーションサーバ１００ｄのＵＲＩ（例えばＳＩＰ−ＵＲＩやＳＩＰＳ−ＵＲＩ）を示す。また、パラメータ「Ｒｅｐｌａｃｅｓ」はダイアログの継承要求を意味し、「Ｄ３」が継承対象のダイアログを表す。
【００５２】
ＳＩＰアプリケーションサーバ１００ｂは、ＲＥＦＥＲリクエストにおいてＲｅｆｅｒ−Ｔｏヘッダで指定されたＳＩＰアプリケーションサーバ１００ｄに対して、図６に示すようなＩＮＶＩＴＥリクエスト４００を送信する（ステップＣ１ｂ）。ＩＮＶＩＴＥリクエスト４００は、ＳＩＰ呼制御部１０５の制御に基づいて生成され、リクエスト行４１０、ヘッダ部４２０及びボディ部４３０を含む。リクエスト行４１０には、メソッドとしてＩＮＶＩＴＥ（招待）が記載されている。ヘッダ部４２０はＳＩＰヘッダ制御部１０８によって生成され、図６に示すようなヘッダフィールド「Ｒｅｐｌａｃｅｓ：Ｄ３」が含まれる。このＲｅｐｌａｃｅｓヘッダは、上述のＲＥＦＥＲリクエスト内のＲｅｐｌａｃｅｓパラメータをコピーして設定される。
【００５３】
ＩＮＶＩＴＥリクエストは、宛て先のサーバにコールを招待するメッセージである。ＩＮＶＩＴＥリクエスト４００が宛て先のＳＩＰアプリケーションサーバ１００ｄに届くと、ＳＩＰアプリケーションサーバ１００ｄからＳＩＰアプリケーションサーバ１００ｂには、成功応答コード「２００  ＯＫ」が送信され（ステップＣ１ｃ）、ダイアログの継承が設定される。
【００５４】
ＳＩＰアプリケーションサーバ１００ｂは、成功応答コードを受信したら、応答を受け取ったことを知らせるＡＣＫメッセージをＳＩＰアプリケーションサーバ１００ｄに送信する（ステップＣ１ｄ）。またＳＩＰアプリケーションサーバ１００ｂは、ＳＩＰアプリケーションサーバ１００ｃに成功応答コード「２００  ＯＫ」を送信し（ステップＣ２ｅ）、ダイアログの継承が成されたことを通知する。
【００５５】
ダイアログ継承ＰＢ２が行なわれたら、ＳＩＰアプリケーションサーバ１００ｃの離脱処理ＰＣが行われる。  
離脱処理ＰＣでは、ＩＮＶＩＴＥリクエスト４００を受信したＳＩＰアプリケーションサーバ１００ｄからＳＩＰアプリケーションサーバ１００ｃへ、ダイアログを終了するためのＢＹＥメッセージが送信される（ステップＢ１ｄ）。ＳＩＰアプリケーションサーバ１００ｃから成功応答コード「２００  ＯＫ」が返信されると（ステップＢ１ｅ）、ＳＩＰアプリケーションサーバ１００ｃと１００ｄの間のダイアログＤ３が終了する。また、ＳＩＰアプリケーションサーバ１００ｃは、ＢＹＥメッセージをＳＩＰアプリケーションサーバ１００ｂに送信する（ステップＢ２ｄ）。ＳＩＰアプリケーションサーバ１００ｂから成功応答コード「２００  ＯＫ」が返信されると（ステップＢ２ｅ）、ＳＩＰアプリケーションサーバ１００ｃと１００ｂの間のダイアログＤ２が終了する。
【００５６】
以上のようにＳＩＰアプリケーションサーバ１００ｃが信号経路から離脱しても、ダイアログ継承ＰＢ２によって、ＳＩＰアプリケーションサーバ１００ｂと１００ｄの間にはダイアログＤ４が設定されている。ダイアログＤ１とＤ４は改めて対応付けられ、エンド−エンド間のＳＩＰ信号通信が維持される。
【００５７】
ＳＩＰアプリケーションサーバ１００ｃが信号経路から離脱したら、その旨をアプリケーションサーバ情報更新処理ＰＤによって信号経路上のサーバに通知することができる。  
アプリケーションサーバ情報更新ＰＤにおいて、ＳＩＰアプリケーションサーバ１００ｃのダイアログを継承したＳＩＰアプリケーションサーバ１００ｂは、ＳＩＰアプリケーションサーバ１００ａに、図７に示すようなＵＰＤＡＴＥリクエスト５００を送信する（ステップＣ３ｈ）。ＵＰＤＡＴＥリクエスト５００は、ＳＩＰ呼制御部１０５の制御に基づいて生成され、リクエスト行５１０、ヘッダ部５２０及びボディ部５３０を含む。ヘッダ部５２０はＳＩＰヘッダ制御部１０８によって生成され、図７に示すようなヘッダフィールド「Ｘ−Ｈｅａｄｅｒ：＜ＡＳ−１００ｃ；ＩＤ００１；ｄｒｏｐｐｅｄ＞」が含まれる。このヘッダフィールドに含まれる識別子「ｄｒｏｐｐｅｄ」が、ＳＩＰアプリケーションサーバ１００ｃが離脱したことを表す。
【００５８】
ＵＰＤＡＴＥリクエストメッセージ２００を受信したら、ＳＩＰアプリケーションサーバ１００ａは成功応答コード「２００  ＯＫ」ＳＩＰアプリケーションサーバ１００ｂに返信する（ステップＣ３ｉ）。
ＳＩＰアプリケーションサーバ１００ｂは、ＳＩＰアプリケーションサーバ１００ｄにも同様のＵＰＤＡＴＥリクエスト５００を送信する（ステップＣ２ｈ）。ＳＩＰアプリケーションサーバ１００ｄが成功応答コード「２００  ＯＫ」をＳＩＰアプリケーションサーバ１００ｂに返信すると（ステップＣ２ｉ）、現在信号経路上に存在するＳＩＰアプリケーションサーバの情報が更新される。
【００５９】
このように、図４に示すダイアログ継承及び離脱手順によれば、離脱予定表明ＰＢ１によって離脱に問題がないことが確認された後、ダイアログ継承ＰＢ２が行なわれる。
ダイアログ継承ＰＢ２では、ＳＩＰアプリケーションサーバ１００ｃが、隣接するＳＩＰアプリケーションサーバ１００ｂに、他方のＳＩＰアプリケーションサーバ１００ｄとの間に確立したダイアログ（Ｄ３）の継承を要求するためのリクエストを既存のダイアログ内のリクエストとして送信する（ステップＣ２ａ）。当該リクエストを受信したＳＩＰアプリケーションサーバ１００ｂは、リクエスト中のＲｅｆｅｒ−Ｔｏヘッダによって指定されるサーバ１００ｄに対してＩＮＶＩＴＥリクエストを送信してダイアログを継承する。また、ＩＮＶＩＴＥリクエストを受信したサーバ１００ｄが、ＢＹＥを送信することで継承の済んだダイアログを切断し、アプリケーションサーバ１００ｃが信号経路から離脱する。
【００６０】
従って、信号経路からの離脱に問題がないかどうかを事前に確認するができ、意図せぬエンド−エンド間通信の切断が防止される。また、離脱に問題が無いことが確認された上で、ＳＩＰダイアログの継承を要求するリクエストが送信され、当該リクエストを受信したサーバがダイアログを継承する。ダイアログが継承されたら、不要となったダイアログが切断され、ＳＩＰアプリケーションサーバはダイアログ中の信号経路から離脱できる。
【００６１】
なお、図２及び図４に示す手順では、ＳＩＰアプリケーションサーバが、ＳＩＰアプリケーションサーバ同士による信号経路から離脱する例について説明したが、サーバに限らず、他のＳＩＰエンティティとの間に成立したＳＩＰ信号経路からの離脱についても、同様の離脱手順を取ることができる。
【００６２】
次に、以上の離脱手順において、個々のアプリケーションサーバが実行する処理の詳細について図８〜１４を参照して説明する。
図８は、離脱決定ＰＡがなされたＳＩＰアプリケーションサーバが、信号経路上の他のＳＩＰエンティティに対して離脱予定を表明する際に行われる処理を示すフローチャートである。
【００６３】
まず、当該ＳＩＰアプリケーションサーバのＳＩＰ呼制御部１０５の制御によって、離脱予定表明メッセージ（例えば図３に示すＵＰＤＡＴＥメッセージ２００）が生成され、他のエンティティに対して送信される（ステップＳ４１１）。
次に、ＳＩＰアプリケーションサーバがこのメッセージに対する応答を受け取ったか否かが判断される（ステップＳ４１２）。離脱予定表明メッセージに対して成功応答コード「２００  ＯＫ」を受信したら（ステップＳ４１２でＹｅｓ）、図２及び図４に示すような離脱処理ＰＣが実行される。
【００６４】
一方、離脱予定表明メッセージに対する成功応答が受信されない場合（ステップＳ４１２でＮｏ）、エラー応答コードを受信したか否かが判断される（ステップＳ４１３）。
エラー応答コードを受信していない場合は（ステップＳ４１３でＮｏ）、予め定められた待機時間を待機して（ステップＳ４１４）、離脱予定表明メッセージを再送信する（ステップＳ４１１）。
【００６５】
例えば図２に示すエラー応答コード「４８０  Temporarily Unavailable」を受信した場合は（ステップＳ４１３でＹｅｓ）、当該エラー応答コードのヘッダ部に、「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されているか否かを判断する（ステップＳ４１５）。
【００６６】
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されている場合（ステップＳ４１５でＹｅｓ）、当該ヘッダにおいて指定された待機時間だけ待機して（ステップＳ４１６）、ＳＩＰ通信制御部１１０が離脱予定表明メッセージを再送信する（ステップＳ４１１）。
【００６７】
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されていない場合（ステップＳ４１５でＮｏ）、当該エラー応答コードが、離脱予定表明メッセージの再送信が無効であることを示すか否かが判断される（ステップＳ４１７）。例えば受信したエラーコードが６００番台のグローバルエラー応答コードであった場合には、離脱予定表明メッセージを再送信しても、どのエンティティでもリクエストが処理できない。また受信したエラーコードが５００番台のサーバエラー応答コードであった場合は、送信先のエンティティではリクエストが処理できない。このような場合に、離脱予定表明メッセージの再送信が無効であると判断され（ステップＳ４１７でＹｅｓ）、ダイアログからの離脱を中止する（ステップＳ４１８）。
【００６８】
一方、エラー応答コードが、離脱予定表明メッセージの再送信が有効であることを示す場合には（ステップＳ４１７でＮｏ）、予め定められた待機時間を待機して（ステップＳ４１４）、離脱予定表明メッセージを再送信する（ステップＳ４１１）。
図９は、ＳＩＰアプリケーションサーバが信号経路上の他のサーバから離脱予定表明メッセージを受信した場合に行われる処理を示すフローチャートである。
【００６９】
例えばＳＩＰアプリケーションサーバが、図３に示すようなＵＰＤＡＴＥメッセージ２００を受け取ったら（ステップＳ５１１）、離脱予定表明メッセージの送信元が、当該ＳＩＰアプリケーションサーバと同じ種別のＳＩＰアプリケーションサーバであるか否かが判断される（ステップＳ５１２）。ここで、当該ＳＩＰアプリケーションサーバは、離脱予定表明メッセージのヘッダ部に含まれるサービスＩＤと自身に割り当てられたサービスＩＤとが同一であるか否かを判断して、離脱予定表明メッセージの送信元と自身が同じ種別であるか（同じサービスを提供しているか）を判断する。
【００７０】
同じ種別のサーバからの離脱予定表明メッセージを受信したら（ステップＳ５１２でＹｅｓ）、ＳＩＰアプリケーションサーバの離脱判定部１０７は、離脱判定基準データ格納部１０３に格納されている離脱実行状態データに基づいて、自身が離脱予定表明中または離脱処理実行中であるかを判断する（ステップＳ５１３）。
【００７１】
離脱判定部１０７は、自身が離脱予定表明中、あるいは離脱処理実行中であれば（ステップＳ５１３でＹｅｓ；図２の離脱処理ＰＣ´）、例えば図２に示すリクエストエラー応答コード「４８０  Temporarily Unavailable」を離脱予定表明メッセージ送信元のサーバに送信する（ステップＳ５１４；図２のステップＢ３ｃ）。
【００７２】
自身が離脱予定表明中でも離脱処理実行中でもない場合（ステップＳ５１３でＮｏ）、離脱判定部１０７は、ＳＩＰアプリケーションサーバに信号経路からの離脱予定があるか否かを、離脱判定基準データ格納部１０３に格納されている離脱実行状態データに基づいて判断する（ステップＳ５１５）。離脱予定が無い場合には（ステップＳ５１５でＮｏ）、当該ＳＩＰアプリケーションサーバが信号経路上の端点であるか否かが判断される（ステップＳ５１７）。一方、離脱予定があると判断された場合（ステップＳ５１５でＹｅｓ）、離脱を中止し離脱予定表明ＰＢ１を行なわず（ステップＳ５１６）、ステップＳ５１７に処理を進める。
【００７３】
当該ＳＩＰアプリケーションが信号経路の端点であれば（ステップＳ５１７でＹｅｓ）、離脱予定表明メッセージの送信元に対して成功応答コード「２００  ＯＫ」が送信される（ステップＳ５１８；図２のステップＢ１ｂ及びＢ３ｂ）。
一方、当該ＳＩＰアプリケーションが信号経路の端点でなければ（ステップＳ５１８でＮｏ）、次のＳＩＰエンティティに離脱予定表明メッセージを中継送信する（ステップＳ５１９；図２のステップＢ３ａ）。
【００７４】
図１０は、離脱予定表明ＰＢ１を行なったＳＩＰアプリケーションサーバが、信号経路上の他のＳＩＰエンティティに対してダイアログの継承を要求する際に行われる処理を示すフローチャートである。
例えば図５に示すＲＥＦＥＲメッセージ３００のようなダイアログの継承要求メッセージの送信が決定されると（ステップＳ６１１）、ＳＩＰアプリケーションサーバのＳＩＰ通信制御部１１０によって当該要求メッセージの送信先候補が検出され、ＳＩＰ呼制御部１０５は、送信先候補が２つ以上検出されたか否かを判断する（ステップＳ６１２）。２つ以上の送信先候補が検出された場合には（ステップＳ６１２でＹｅｓ）、図１１に示す複数対象への継承要求送信が行なわれる（ステップＳ６１３）。
【００７５】
一方、１つの送信先候補が検出された場合（ステップＳ６１２でＮｏ）、ＳＩＰ呼制御部１０５の制御のもとで、ＳＩＰヘッダ制御部１０８及びＳＩＰメッセージボディ制御部１０９によってＲＥＦＥＲメッセージ３００のような継承要求メッセージが生成され、送信先候補のエンティティに送信される（ステップＳ６１４；図４のステップＣ２ａ）。
【００７６】
次に、この継承要求メッセージに対する応答を当該エンティティから受け取ったか否かが判断される（ステップＳ６１５）。当該送信先エンティティから成功応答コード「２００  ＯＫ」を受信したら（ステップＳ６１５でＹｅｓ；図４のステップＣ２ｅ）、当該送信先エンティティにダイアログ切断のためのＢＹＥメッセージが送信される（ステップＳ６１６；図４のステップＢ２ｄ）。
【００７７】
一方、継承要求メッセージに対する成功応答が受信されない場合（ステップＳ６１５でＮｏ）、エラー応答コードを受信したか否かが判断される（ステップＳ６１７）。
エラー応答コードを受信していない場合は（ステップＳ６１７でＮｏ）、予め定められた待機時間を待機して（ステップＳ６１８）、継承要求メッセージを再送信する（ステップＳ６１４）。
【００７８】
継承要求メッセージに対して、エラー応答コードを受信した場合は、（ステップＳ６１７でＹｅｓ）、当該エラー応答コードのヘッダ部に、「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されているか否かが判断される（ステップＳ６１９）。
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されている場合（ステップＳ６１９でＹｅｓ）、当該ヘッダにおいて指定された待機時間だけ待機して（ステップＳ６２０）、継承要求メッセージが再送信される（ステップＳ６１４）。
【００７９】
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されていない場合（ステップＳ６１９でＮｏ）、当該エラー応答コードが、継承要求メッセージの再送信が無効であることを示すか否かが判断される（ステップＳ６２１）。継承要求メッセージの再送信が無効であると判断された場合（ステップＳ６２１でＹｅｓ）、ダイアログからの離脱を中止する（ステップＳ６２２）。
【００８０】
一方、エラー応答コードが、継承要求メッセージの再送信が有効であることを示す場合には（ステップＳ６２１でＮｏ）、予め定められた待機時間を待機して（ステップＳ６１８）、継承要求メッセージを再送信する（ステップＳ６１４）。
図１１は、ダイアログの継承要求リクエストの送信先エンティティが複数検出された場合に行われる処理を示すフローチャートである。
【００８１】
図１０のステップＳ６１２において、継承要求リクエストの送信先候補が２つ以上の送検出された場合には（ステップＳ６１２でＹｅｓ）、図１１の処理に進み、複数の送信先候補から一つのエンティティが選択され、送信先として決定される（ステップＳ７１１）。選択の順序はデフォルトで決定されていてもよい。あるいは、信号経路上での距離が最も近いＳＩＰエンティティが選択されてもよい。
【００８２】
送信先エンティティが決定されたら、ＳＩＰ呼制御部１０５の制御のもとで、ＳＩＰヘッダ制御部１０８及びＳＩＰメッセージボディ制御部１０９によってＲＥＦＥＲメッセージ３００のような継承要求メッセージが生成され、送信先候補のエンティティに送信される（ステップＳ７１２）。
【００８３】
次に、この継承要求メッセージに対する応答を当該エンティティから受け取ったか否かを判断する（ステップＳ７１３）。継承要求メッセージに対する成功応答が受信されない場合（ステップＳ７１３でＮｏ）、エラー応答コードを受信したか否かが判断される（ステップＳ７１４）。
【００８４】
エラー応答コードを受信していない場合は（ステップＳ７１４でＮｏ）、予め定められた待機時間を待機して（ステップＳ７１５）、継承要求メッセージを再送信する（ステップＳ７１２）。
継承要求メッセージに対して、エラー応答コードを受信した場合は、（ステップＳ７１４でＹｅｓ）、当該エラー応答コードのヘッダ部に、「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されているか否かを判断する（ステップＳ７１６）。
【００８５】
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されている場合（ステップＳ７１６でＹｅｓ）、当該ヘッダにおいて指定された待機時間だけ待機して（ステップＳ７１７）、継承要求メッセージを再送信する（ステップＳ７１２）。
【００８６】
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されていない場合（ステップＳ７１６でＮｏ）、当該エラー応答コードが、継承要求メッセージの再送信が無効であることを示すか否かを判断する（ステップＳ７１８）。継承要求メッセージの再送信が無効であると判断された場合（ステップＳ７１８でＹｅｓ）、ダイアログを継承できないので、ダイアログからの離脱を中止する（ステップＳ７１９）。
【００８７】
一方、エラー応答コードが、継承要求メッセージの再送信が有効であることを示す場合には（ステップＳ７１８でＮｏ）、予め定められた待機時間を待機して（ステップＳ７１５）、継承要求メッセージを再送信する（ステップＳ７１２）。
一方、当該送信先エンティティから成功応答コード「２００  ＯＫ」を受信したら（ステップＳ７１３でＹｅｓ）、まだ継承要求メッセージを送信していない送信先候補が残っているか否かを判断する（ステップＳ７２０）。
【００８８】
全ての送信先候補に継承要求メッセージを送信し、全ての送信先から成功応答コードを受信していたら（ステップＳ７２０でＮｏ）、これら全ての送信先にダイアログ切断のためのＢＹＥメッセージが送信される（ステップＳ７２１）。
継承要求メッセージを送信していない送信先候補が残っている場合は（ステップＳ７２０でＹｅｓ）、ステップＳ７１２での送信先エンティティとの間に確立されていたダイアログを新たに継承対象のダイアログとして設定する（ステップＳ７２２）。その後、当該継承対象のダイアログを継承させる送信先エンティティを選択して次の送信先として決定し（ステップＳ７２３）、当該送信先エンティティに継承要求メッセージを送信する（ステップＳ７１２）。その後、ステップＳ７１３以降の処理を繰り返す。
【００８９】
図１２は、ＳＩＰアプリケーションサーバが信号経路上の他のサーバから継承要求メッセージを受信した場合に行われる処理を示すフローチャートである。
ＳＩＰアプリケーションサーバが、例えば図５に示すようなＲＥＦＥＲメッセージ３００を受け取ったら（ステップＳ８１１）、当該ＳＩＰアプリケーションサーバの離脱判定部１０７は、離脱判定基準データ格納部１０３に格納されている離脱実行状態データに基づいて、当該ＳＩＰアプリケーションサーバが離脱処理実行中であるか否かを判断する（ステップＳ８１２）。
【００９０】
離脱判定部１０７は、ＳＩＰアプリケーションが離脱処理実行中であれば（ステップＳ８１２でＹｅｓ）、例えば４８０番のリクエストエラー応答コード「４８０  Temporarily Unavailable」を継承要求メッセージ送信元のサーバに送信する（ステップＳ８１３）。エラー応答コードのヘッダ部には、Ｒｅｔｒｙ−Ａｆｔｅｒヘッダが記述されてもよい。このＲｅｔｒｙ−Ａｆｔｅｒヘッダによって、メッセージ送信元のサーバが継承要求メッセージを再送信する時間を指定することができる。
【００９１】
一方、ＳＩＰアプリケーションサーバが離脱処理実行中でない場合（ステップＳ８１２でＮｏ）、離脱判定部１０７は、ＳＩＰアプリケーションサーバが別のサーバから受信した継承要求メッセージを処理中であるか否かを判断する（ステップＳ８１４）。他の継承要求メッセージの処理中ではない場合には（ステップＳ８１４でＮｏ）、図１３に示すダイアログの継承が行なわれる（ステップＳ８１５）。
【００９２】
一方、当該ＳＩＰアプリケーションが他の継承要求メッセージの処理中である場合には（ステップＳ８１４でＹｅｓ）、エラー応答コードを継承要求メッセージ送信元のサーバに送信する（ステップＳ８１３）。
図１３は、ダイアログ継承要求リクエストを受信したＳＩＰアプリケーションサーバが、当該リクエストで指定されているダイアログを継承する際に行われる処理を示すフローチャートである。
【００９３】
ダイアログの継承の際には、ＳＩＰアプリケーションサーバのＳＩＰ呼制御部１０５の制御のもとでＳＩＰヘッダ制御部１０８及びＳＩＰメッセージボディ制御部１０９によって図６に示すＩＮＶＩＴＥメッセージ４００のような継承メッセージが生成され、継承要求メッセージで指定されたエンティティに送信される（ステップＳ９１１；図４のステップＣ１ｂ）。
【００９４】
次に、ＳＩＰアプリケーションサーバが継承メッセージに対する成功応答を当該エンティティから受け取ったか否かが判断される（ステップＳ９１２）。送信先エンティティから成功応答コード「２００  ＯＫ」を受信したら（ステップＳ９１２でＹｅｓ；図４のステップＣ１ｃ）、当該送信先エンティティに、応答を受け取ったことを知らせるＡＣＫメッセージが送信される（ステップＳ９１９；図４のステップＣ１ｄ）。続いて、図４に示すようにアプリケーションサーバ情報更新ＰＤが行なわれる。
【００９５】
一方、継承メッセージに対する成功応答が受信されない場合（ステップＳ９１２でＮｏ）、エラー応答コードを受信したか否かが判断される（ステップＳ９１３）。  
エラー応答コードを受信していない場合は（ステップＳ９１３でＮｏ）、予め定められた待機時間を待機して（ステップＳ９１４）、継承メッセージを再送信する（ステップＳ９１１）。
【００９６】
継承メッセージに対して、エラー応答コードを受信した場合は、（ステップＳ９１３でＹｅｓ）、当該エラー応答コードのヘッダ部に、「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されているか否かを判断する（ステップＳ９１５）。
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されている場合（ステップＳ９１５でＹｅｓ）、当該ヘッダにおいて指定された待機時間だけ待機して（ステップＳ９１６）、継承メッセージを再送信する（ステップＳ９１１）。
【００９７】
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されていない場合（ステップＳ９１５でＮｏ）、当該エラー応答コードが、継承メッセージの再送信が無効であることを示すか否かを判断する（ステップＳ９１６）。継承メッセージの再送信が無効であると判断された場合（ステップＳ９１６でＹｅｓ）、送信先のエンティティとのダイアログが確立できないのでダイアログ継承を中止し（ステップＳ９１７）、継承要求メッセージの送信元のサーバにエラー応答コードを送信する（ステップＳ９１８）。
【００９８】
一方、エラー応答コードが、継承メッセージの再送信が有効であることを示す場合には（ステップＳ９１６でＮｏ）、予め定められた待機時間を待機して（ステップＳ９１４）、継承メッセージを再送信する（ステップＳ９１１）。
図１４は、信号経路から離脱したサーバからダイアログを継承したＳＩＰアプリケーションサーバが、他のＳＩＰエンティティに対して当該サーバの離脱を通知する際に行われる処理を示すフローチャートである。
【００９９】
ダイアログを継承したＳＩＰアプリケーションサーバのＳＩＰ呼制御部１０５の制御によって、更新メッセージ（例えば図７に示すＵＰＤＡＴＥメッセージ５００）が生成され、他のエンティティに対して送信される（ステップＳ１０１１；図４のステップＣ２ｈ及びＳ３ｈ）。
【０１００】
次に、ＳＩＰアプリケーションサーバがこのメッセージに対する成功応答を受け取ったか否かが判断される（ステップＳ１０１２）。更新メッセージに対して成功応答コード「２００  ＯＫ」を受信したら（ステップＳ１０１２でＹｅｓ；図４のステップＣ２ｉ及びＣ３ｉ）、処理は終了する。
【０１０１】
一方、更新メッセージに対する成功応答が受信されない場合（ステップＳ１０１２でＮｏ）、エラー応答コードを受信したか否かが判断される（ステップＳ１０１４）。
エラー応答コードを受信していない場合は（ステップＳ１０１４でＮｏ）、予め定められた待機時間を待機して（ステップＳ１０１５）、更新メッセージを再送信する（ステップＳ１０１１）。
【０１０２】
エラー応答コードを受信した場合は（ステップＳ１０１４でＹｅｓ）、当該エラー応答コードのヘッダ部に、「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されているか否かを判断する（ステップＳ１０１６）。
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されている場合（ステップＳ１０１６でＹｅｓ）、当該ヘッダにおいて指定された待機時間だけ待機して（ステップＳ１０１７）、ＳＩＰ通信制御部１１０が更新メッセージを再送信する（ステップＳ１０１１）。
【０１０３】
エラー応答コードのヘッダ部に「Ｒｅｔｒｙ−Ａｆｔｅｒ」ヘッダが設定されていない場合（ステップＳ１０１６でＮｏ）、当該エラー応答コードが、更新メッセージの再送信が無効であることを示すか否かが判断される（ステップＳ１０１８）。更新メッセージの再送信が無効である場合（ステップＳ１０１８でＹｅｓ）、更新処理は中止される（ステップＳ１０１９）。
【０１０４】
一方、エラー応答コードが、更新メッセージの再送信が有効であることを示す場合には（ステップＳ１０１８でＮｏ）、予め定められた待機時間を待機して（ステップＳ１０１５）、更新メッセージを再送信する（ステップＳ１０１１）。
以上説明したように、本実施形態によれば、ＳＩＰアプリケーションサーバが信号経路からの離脱を決定した場合に、当該信号経路に対して離脱予定を示す識別子を含む離脱予定表明メッセージを送信する。この離脱予定表明メッセージに対して、成功応答コードが返信されて離脱に問題がないことが確認されたら、信号経路からの離脱が行なわれる。このため、複数のサーバの同時離脱による予期せぬエンド−エンド間通信の切断を防止することができる。
【０１０５】
また、離脱に問題がないことが確認されたら、ＳＩＰアプリケーションサーバ間でダイアログの継承を行なうこともできる。ダイアログ継承では、ＳＩＰアプリケーションサーバが、隣接するＳＩＰアプリケーションサーバに、他のＳＩＰアプリケーションサーバとの間に確立したダイアログの継承を要求するための継承要求リクエストを既存のダイアログ内のリクエストとして送信する。当該リクエストを受信したＳＩＰアプリケーションサーバは、当該他のＳＩＰアップリケーションに対して継承メッセージを送信してダイアログを継承する。また、継承メッセージ受信したサーバがＢＹＥを送信することで継承の済んだダイアログ切断し、ＳＩＰアプリケーションサーバの信号経路からの離脱が行なわれる。
【０１０６】
更に、ＳＩＰアプリケーションサーバが信号経路から離脱したら、その旨をアプリケーションサーバ情報更新処理によって信号経路上のサーバに通知することができる。
尚、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成を削除してもよい。さらに、異なる実施形態例に亘る構成要素を適宜組み合わせてもよい。
【０１０７】
また、本発明は、コンピュータに所定の手段を実行させるため、コンピュータを所定の手段として機能させるため、コンピュータに所定の機能を実現させるため、あるいはプログラムを記録したコンピュータ読取り可能な記録媒体としても実施することもできる。
【符号の説明】
【０１０８】
１００…ＳＩＰアプリケーションサーバ、１０１…アプリケーションサービスロジック格納部、１０２…アプリケーションサービスロジック管理部、１０３…離脱判定基準データ格納部、１０４…離脱判定基準データ管理部、１０５…ＳＩＰ呼制御部、１０６…セッション管理用データ格納部、１０７…離脱判定部、１０８…ＳＩＰヘッダ制御部、１０９…ＳＩＰメッセージボディ制御部、１１０…ＳＩＰ通信制御部、１１１…ＳＩＰセッションタイマ制御部、１２０…ソケット部。
【図１】
2011049682.tif 000003
【図２】
2011049682.tif 000004
【図３】
2011049682.tif 000005
【図４】
2011049682.tif 000006
【図５】
2011049682.tif 000007
【図６】
2011049682.tif 000008
【図７】
2011049682.tif 000009
【図８】
2011049682.tif 000010
【図９】
2011049682.tif 000011
【図１０】
2011049682.tif 000012
【図１１】
2011049682.tif 000013
【図１２】
2011049682.tif 000014
【図１３】
2011049682.tif 000015
【図１４】
2011049682.tif 000016