呼制御方法、および呼制御システム
【課題】呼セッション制御サーバとアプリケーションサーバ間の呼確立要求信号の流通インタフェースにおいて、サービス状態情報の記憶領域を削減する。
【解決手段】呼制御システムであって、呼制御サーバ１は、サービス状態情報を含む第１の呼確立要求信号を生成する生成手段１４と、第１の呼確立要求信号を送信してアプリケーションサーバに接続する接続手段１３と、アプリケーションサーバから受信した第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定手段１５とを有し、アプリケーションサーバは、呼制御サーバ１から受信した第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成する生成手段と、第２の呼確立要求信号を送信して前記呼制御サーバに接続する接続手段とを有する。
【解決手段】呼制御システムであって、呼制御サーバ１は、サービス状態情報を含む第１の呼確立要求信号を生成する生成手段１４と、第１の呼確立要求信号を送信してアプリケーションサーバに接続する接続手段１３と、アプリケーションサーバから受信した第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定手段１５とを有し、アプリケーションサーバは、呼制御サーバ１から受信した第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成する生成手段と、第２の呼確立要求信号を送信して前記呼制御サーバに接続する接続手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、3GPP（Third Generation Partnership Project）、3GPP2（Third Generation Partnership Project2）にて標準化されているIMS（IP Multimedia ）において、呼確立要求信号を受信した呼セッション制御機能部（以下「CSCF」：Call Session Control Functionと称する）と、サービスを提供するアプリケーションサーバ（以下、「AS」：Application Serverと称する）との間の呼確立要求信号の流通インタフェース（以下、IMSのインタフェース呼称に従い「ISCインタフェース」：IP multimedia Service Controlインタフェースと称する）に関する。
【背景技術】
【０００２】
ISCインタフェースにおいては、CSCFが、ASに呼確立要求信号を送信後、ASから当該呼に対応した呼確立要求信号を受信した場合に、先にCSCFからASに送信した呼確立要求信号に対応するサービス状態の情報を識別可能である必要がある。呼確立要求信号は、SIP（Session Initiation Protocol）における、INVITEメソッド（Initial-INVITE）、MESSAGEメソッドなどを指す。
【０００３】
ここでいうサービス状態の情報（以下、「サービス状態情報」と称する）は、CSCFからASへ呼確立要求信号を送信する処理（以下、「AS接続処理」と称する）を行う時点でサービス対象ユーザとして認識しているユーザの識別子など、サービス提供を正常に継続するためにCSCFが必要とする情報である。
【０００４】
ISCインタフェースの実装技術については、例えば非特許文献１、非特許文献２に記載されている。また、SIPについては、例えば非特許文献３に記載されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】“3GPP TS 23．218 V9.2.0”、3rd Generation Partnership Project (3GPP)、2010年6月、［online］、［2010年12月9日検索］、インターネット＜http://www.3gpp.org/ftp/Specs/archive/23_series/23.218/23218-920.zip＞
【非特許文献２】“3GPP TS 24．229 V10.1.0”、3rd Generation Partnership Project (3GPP)、2010年9月、［online］、［2010年12月9日検索］、インターネット＜http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-a10.zip＞
【非特許文献３】J. Rosenberg, et. al.、“SIP : Session Initiation Protocol RFC 3261”、IETF、2002年6月、［2010年12月13日検索］、インターネット＜http://datatracker.ietf.org/doc/rfc3261/?include_text=1＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
非特許文献１、非特許文献２に記載のISCインタフェースの実装技術では、以下の手順を行うことでCSCFにサービス状態情報の識別を可能にする。
【０００７】
１）CSCFがAS接続処理を行う際に、当該呼のサービス状態情報をそのサービス状態情報と一意に対応付けが可能な識別子（以下、「ODI」：Original Dialog Identifierと称する）とともにCSCFが保持し、ODIを呼確立要求信号に含めてASに送信する。
【０００８】
２）ASが上記１）の呼に対応した呼確立要求信号をCSCFに送信する処理（以下、「CSCF接続処理」と称する）を行う際に、AS接続処理時にASが受信した呼確立要求信号に含まれたODIを含めて送信する。
【０００９】
３）上記２）のCSCF接続処理の呼確立要求信号を受信したCSCFは、呼確立要求信号中に含まれるODIを基に、受信呼確立要求信号に対応するサービス状態情報を識別・取得し、呼処理を継続する。
【００１０】
図５は、従来のISCインタフェース実装技術における、CSCFとAS間でODIを含む呼確立要求信号が流通し、それによりCSCFおよびASが正常にサービス提供する動作を説明するための図である。図示するシステムは、CSCF-Cと、AS#6 3fと、AS#7 3gと、端末装置4aと、端末装置4bとを有し、AS#6 3fおよびAS#7 3gはCSCF-Cに接続され、端末装置4aおよび端末装置4bもCSCF-Cに接続されている。
【００１１】
CSCF-Cは、加入者系のセッション制御機能を有するユーザ収容ノードである。
【００１２】
AS#6 3fおよびAS#7 3gは、CSCF-Cから接続されることによりサービスを提供するアプリケーションサーバである。
【００１３】
端末装置4aおよび端末装置4bは、通信サービスを利用するユーザが操作する端末装置であり、図５の例では端末装置4aを呼の発信側とし、端末装置4bを呼の着信側としている。
【００１４】
CSCF-Cには、AS接続処理を行う呼が発生した場合、CSCF-Cにて生成するODI毎にサービス状態情報を記憶する記憶領域31が確保されている。
【００１５】
呼確立要求信号21〜26は、端末装置4aから送信された呼確立要求信号21を契機に発生する一連の呼確立要求信号を示している。
【００１６】
端末装置4aが呼確立要求信号21を送信すると、CSCF-Cが受信し、AS接続処理が必要か否かを判定する。AS接続処理の要否判定は、非特許文献１、非特許文献２に記載される接続条件(以下、「iFC」: initial Filter Criteriaと称する)と呼確立要求信号の内容とを比較し、条件に該当する場合にAS接続処理を行う。図５の例では、iFCに呼確立要求信号が合致し、AS#6 3fへのAS接続処理が必要であると判定されるものとする。
【００１７】
CSCF-CがAS#6 3fへAS接続処理を行う際、CSCF-Cは、ODIを一意に識別可能となるように生成し、生成したODIを端末装置4aから受信した呼確立要求信号およびCSCFの保持する加入者データを分析した結果得られるサービス状態情報と対応付けて記憶領域31に記憶する。さらに、AS#6 3fへの呼確立要求信号22に生成したODIを含めて送信する。
【００１８】
呼確立要求信号22を受信したAS#6 3fは、自身のサービス論理に従って呼確立要求信号22を加工し、CSCF接続処理として呼確立要求信号23をCSCF-Cに送信する。この際、呼確立要求信号23には、呼確立要求信号22でAS#6 3fが受信したODIと同一の値のODIが含まれる。呼確立要求信号23は、呼確立要求信号22と比べた場合、着信者を示すRequest-URI、Toヘッダフィールド等の値が変更されている可能性があり、また発信者を示すFromヘッダフィールド、P-Asserted-Identityヘッダフィールド等の値が変更されている可能性もある。その他、AS#6 3fのサービス論理の条件により呼確立要求信号に含まれるその他の情報が追加、変更、削除されている可能性がある。
【００１９】
CSCF-Cは、呼確立要求信号23を受信すると、当該呼確立要求信号23に含まれるODIを抽出し、当該ODIに対応するサービス状態情報を記憶領域31から取得する。これは、CSCF-Cは引き続きAS接続処理要否判定を行うが、その判定には端末装置4aから呼確立要求信号21を受信した時点のサービス状態情報が必要であることによる。つまり、呼確立要求信号23はAS#6 3fによりODI以外の情報を変更されている可能性があるため、呼確立要求信号23からは「どのユーザをサービス対象ユーザと認識するか（どのユーザのiFCを用いてAS接続処理要否判定を実施するか）」、「当該一連の呼についてサービス対象ユーザのiFCをどこまで処理したかの進捗状況」といったサービス状態情報に相当する情報が確実に抽出できるとは限らないからである。
【００２０】
CSCF-Cが、記憶領域31から取得したサービス状態情報を用いて、引き続きAS接続処理要否判定を行った結果、今度はAS#7 3gにAS接続処理が必要になったとする。CSCF-Cは、呼確立要求信号23で受信したODIに対応するサービス状態情報のiFC処理の進捗状況を更新して、記憶領域31に記憶する。さらに、CSCF-Cは、AS#7 3gへ呼確立要求信号24を送信する。
【００２１】
AS#7 3gが呼確立要求信号24を受信した際の処理は、先に述べたAS#6 3fが呼確立要求信号22を受信した際の処理と同様である。
【００２２】
CSCF-Cは、呼確立要求信号25を受信すると、呼確立要求信号25に含まれるODIを抽出し、当該ODIに対応するサービス状態情報を記憶領域31から取得する。
【００２３】
CSCF-Cが、記憶領域31から取得したサービス状態情報を用いて、引き続きAS接続処理要否判定を行った結果、今度はAS接続処理が不要と判定されたとする。CSCF-Cは、呼確立要求信号25で受信したODIに対応するサービス状態情報のiFC処理の進捗状況を更新して、記憶領域31に記憶する。さらに、CSCF-Cは、端末装置4bへ呼確立要求信号26を送信する。
【００２４】
以降はIMSとして標準的なSIPの呼確立処理を行い、呼が確立する。
【００２５】
上記のような従来技術では、ASのサービス論理による呼確立要求信号内容の追加、変更、削除の影響を受けずに正常に呼処理を継続するためには、CSCFが記憶領域にサービス状態情報を保持しておくことが必要である。サービス状態情報の保持期間は、図５に示す呼確立処理では、呼確立要求信号21についてCSCFがサービス状態情報を保持してから呼確立要求信号21〜26に対応する呼が解放されるまでとなる。
【００２６】
サービス状態情報は、CSCFがODIを生成する毎に1レコード必要であり、その分CSCFでは記憶領域の確保が必要となる。このことは、1つのCSCFで多数の呼がAS連携処理を行うような場合ほど、大量の記憶領域が必要となることを意味する。また、1つのCSCFで多数のユーザを収容可能であるほど、大量の記憶領域が必要となる。すなわち、ODI毎にサービス状態情報をCSCFが保持する必要があり、多数の呼についてAS接続処理を行う場合はそれに見合ったCSCFの記憶領域を確保する必要があり、CSCFシステムのコスト増加の要因となる。
【００２７】
さらに、CSCFの演算性能に対して、記憶領域からの読み出し速度、あるいは記憶領域への書き込み速度が不十分の場合は、読み出しあるいは書き込みの待ち合わせ時間が長くなり、CSCFの呼処理性能のボトルネックとなるという問題もある。
【００２８】
本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、呼セッション制御サーバとアプリケーションサーバ間の呼確立要求信号の流通インタフェースにおいて、サービス状態情報の記憶領域を削減可能な呼制御方法、および呼制御システムを提供することにある。
【課題を解決するための手段】
【００２９】
上記目的を達成するため、本発明は、呼制御サーバとアプリケーションサーバ間の呼確立要求信号の流通インタフェースにおける呼制御方法であって、前記呼制御サーバは、 サービス状態情報を含む第１の呼確立要求信号を生成し、当該第１の呼確立要求信号を送信して前記アプリケーションサーバに接続する第１の接続ステップを行い、前記アプリケーションサーバは、前記呼制御サーバから受信した前記第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成し、当該第２の呼確立要求信号を送信して前記呼制御サーバに接続する第２の接続ステップを行い、前記呼制御サーバは、前記アプリケーションサーバから受信した前記第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定ステップと、を行う。
【００３０】
また、本発明は、呼制御サーバと、アプリケーションサーバとを有する呼制御システムであって、前記呼制御サーバは、サービス状態情報を含む第１の呼確立要求信号を生成する生成手段と、前記第１の呼確立要求信号を送信して前記アプリケーションサーバに接続する接続手段と、前記アプリケーションサーバから受信した第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定手段と、を有し、前記アプリケーションサーバは、前記呼制御サーバから受信した前記第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成する生成手段と、前記第２の呼確立要求信号を送信して前記呼制御サーバに接続する接続手段と、を有する。
【発明の効果】
【００３１】
本発明によれば、呼セッション制御サーバとアプリケーションサーバ間の呼確立要求信号の流通インタフェースにおいて、サービス状態情報の記憶領域を削減可能な呼制御方法、および呼制御システムを提供することができる。
【図面の簡単な説明】
【００３２】
【図１】本発明の実施形態に係るシステムの全体構成図である。
【図２】本実施形態のCSCFの構成例を示す図である。
【図３】CSCFの処理を説明するためのシーケンス図（その１）である。
【図４】CSCFの処理を説明するためのシーケンス図（その２）である。
【図５】従来のCSCFの処理を説明するための説明図である。
【発明を実施するための形態】
【００３３】
以下、本発明の実施の形態について、図面を参照して説明する。
【００３４】
まず、本実施形態に係るシステムについて説明する。
【００３５】
［システムの構成］
図１は、本実施形態のシステムの構成例を示す構成図である。図示する本システムは、CSCF−A1（呼制御サーバ）と、複数のAS （AS#1 3a、AS#2 3b、AS#3 3c、AS#4 3d、およびAS#5 3e）と、端末装置4とを有する。なお、どのASであるかを特定しない場合は、「AS3」と記載する。AS#1 3a〜AS#5 3eの各々は、CSCF−A1に接続され、端末装置4もCSCF−A1に接続される。
【００３６】
CSCF−A1は、iFC処理を実装した加入者系のセッション制御機能を含むユーザ収容ノード（例えば、SIPサーバなど）である。詳細については後述する。
【００３７】
AS#1 3a〜AS#5 3eは、CSCF−A1から接続されて、各種のサービスを提供するアプリケーションサーバである。図１では、５つのAS3を示しているが、AS3の数はこれに限定されるものではない。
【００３８】
端末装置4は、通信サービスを利用するユーザが操作する端末装置である。なお、図１では、CSCF−A1に接続される端末装置4は1つであるが、端末装置４は複数存在してもよい。
【００３９】
次に、本システムの機能について説明する。
【００４０】
［システムの機能］
本システムでは、CSCF−A1は、端末装置4あるいは他のCSCF−A（不図示）から送信されてきた呼確立要求信号を受信すると、呼確立要求信号の内容と、当該CSCF−A1に設定されたiFC（接続条件）とを比較し、条件に合致するか否かによりAS接続処理の要否を判定（AS接続処理要否判定）する。AS接続処理要と判定された場合、CSCF−A1は、AS接続処理として、ODI記述部分にサービス状態情報を記述した呼確立要求信号を生成し、AS3に送信する。
【００４１】
なお、ODI記述部分は、非特許文献１および非特許文献２に規定されているように、SIPリクエスト信号のRouteヘッダフィールドに記載されるname-addr部のuserinfo部を指す。SIPリクエスト信号規定については非特許文献３に記載されている。
【００４２】
AS3は、受信した呼確立要求信号を当該AS3自身のサービス論理に従って加工することにより新たな呼確立要求信号を生成し、CSCF接続処理としてCSCF-A1に送信する。なお、新たな呼確立要求信号のODI記述部分には、AS3がCSCF−A1から受信した呼確立要求信号のODI記述部分と同一の値を透過的に設定する。
【００４３】
CSCF-A1は、CSCF接続処理によりAS3から送信された呼確立要求信号を受信すると、当該呼確立要求信号のODI記述部分に含まれるサービス状態情報を抽出し、抽出したサービス状態情報に基づいて引き続きAS接続処理要否判定を行う。
【００４４】
なお、サービス状態情報は、CSCF-A1がAS3からCSCF接続処理による呼確立要求信号を受信した後、正常に引き続きAS接続処理要否判定を実施するために必要となる情報である。本実施形態では、サービス状態情報として、「サービス対象ユーザの識別子」、「サービス対象ユーザのREGISTER状態」、「サービス対象ユーザのAS接続処理要否判定の進捗状況」、「サービス対象ユーザのAS接続処理要否判定の発着種別」を用いるが、本発明はこれらに限定されるものではない。例えば、これら以外の他の情報を用いたり、あるいは、これらの情報の一部を用いることとしてもよい。
【００４５】
「サービス対象ユーザの識別子」は、サービス対象ユーザを一意に識別可な識別子である。
【００４６】
「サービス対象ユーザのREGISTER状態」は、サービス対象ユーザのREGISTER状態がREGISTER未登録状態か、REGISTER登録済み状態かの種別である。AS接続処理後のAS3のサービス条件が、サービス対象ユーザがREGISTER未登録状態か、REGISTER登録済み状態かにより異なる場合があるため、本実施形態では、サービス状態情報の1つとする。
【００４７】
「サービス対象ユーザのAS接続処理要否判定の進捗状況」は、サービス対象ユーザのAS接続処理要否判定の進捗状況を示すものであり、本実施形態では判定済みiFCの識別子を用いる。AS3によるCSCF接続処理後、引き続きAS接続処理要否判定を行う際に、判定済みiFCの次優先度のiFCから判定を継続するために使用する。なお、次優先度のiFCから判定を継続可能であれば、判定済みiFCの識別子以外の情報を用いることとしてもよい。
【００４８】
「サービス対象ユーザのAS接続処理要否判定の発着種別」は、発CSCFにおいてAS接続処理要否判定を行っているのか、着CSCFにおいてAS接続処理要否判定を行っているのかの種別である。ASのサービス条件として、発CSCFにおけるAS接続処理の場合と、着CSCFにおけるAS接続処理の場合とは、サービス提供条件が異なる場合が有るため、本実施形態ではサービス状態情報の1つとする。
【００４９】
次に、本実施形態のCSCF−A1について説明する。
【００５０】
［CSCF−A1の構成］
図２は、図１に示すシステムにおけるCSCF−A1の構成例を示す図である。同図は、CSCF−A1の機能のうち、本発明に関係する部分のみを概念的に示している。
【００５１】
CSCF-A1は、サービス契約情報蓄積部11と、iFC蓄積部12と、SIP信号制御部13（接続手段）と、セッション制御部14（生成手段）と、AS接続処理要否判定部15（判定手段）と、ODI管理部16とを有する。
【００５２】
サービス契約情報蓄積部11は、ユーザ毎にユーザが契約したサービス契約情報を蓄積する。サービス契約情報蓄積部11には、iFC蓄積部12が蓄積する各iFCについて、各ユーザがどのサービスに契約しているか、すなわちユーザ毎にどのiFCを設定可能かの情報、および、各ユーザと当該ユーザに実際に設定されたiFCとの対応情報が、記憶されている。
【００５３】
iFC蓄積部12は、ユーザ毎に優先度が設定された、各サービスのiFC（接続条件）を蓄積する。
【００５４】
SIP信号制御部13は、呼確立要求信号（SIP信号のINVITE、MESSAGE等）や呼確立要求信号に対する応答信号（200 OK信号等）を受信し、これらの信号をセッション制御部14に送出するとともに、セッション制御部14から送出されるこれらの信号の処理結果にもとづき呼確立要求信号およびその応答信号を送信する。
【００５５】
セッション制御部 14は、SIP信号制御部 13から送出される信号を解析した結果と、必要に応じて当該セッション制御部 14が生成した情報あるいはODI管理部 16から取得した情報とに基づいて、サービス対象ユーザの識別子、発信元アドレス、着信先アドレス、サービス要求内容、サービス状態情報等をAS接続処理要否判定部 15に送出する。
【００５６】
また、セッション制御部 14は、AS接続処理要否判定部 15から送出される判定終了後の着信先アドレス、発信元アドレス、サービス要求内容、サービス状態情報等を受け取り、着信先アドレス、発信元アドレスおよびサービス要求内容等をSIP信号制御部 13に送出し、またODI管理部 16からODIを取得する。そして、セッション制御部 14は、ODIと、サービス状態情報とを1つにまとめ、ODI記述部分の値としてSIP信号制御部 13に送出する。サービス状態情報は、セッション制御部14が把握しているサービス対象ユーザの識別子と、セッション制御部14が把握しているサービス対象ユーザのREGISTER登録状態と、セッション制御部14が把握しているサービス対象ユーザのAS接続処理要否判定の発着種別と、AS接続処理要否判定部 15から受け取ったサービス対象ユーザのAS接続処理要否判定の進捗状況である。
【００５７】
セッション制御部 14の動作条件は、SIP信号制御部 13から送出される呼確立要求信号のODI記述部分に情報が存在するか否かで異なる。詳細については後述する。
【００５８】
AS接続処理要否判定部 15は、セッション制御部14から送出されるサービス対象ユーザの識別子によりサービス契約情報蓄積部11からサービス対象ユーザのサービス契約情報を取得する。また、iFC蓄積部12からサービス対象ユーザに対応する、優先度が設定されたiFCを全て取得し、取得した各iFCにサービス契約情報を反映させる。そして、これらの各iFCと、呼確立要求信号に含まれる着信先アドレス、発信元アドレスあるいはサービス要求内容等とを比較し、合致するか否かを判定する。合致する場合は、接続先AS3情報をセッション制御部14に送出する。
【００５９】
また、AS接続処理要否判定部 15は、セッション制御部14から、AS3が提供するサービスに則った呼確立要求信号に含まれる着信先アドレス、発信元アドレスあるいはサービス要求内容等を受け取り、優先度の最も高いiFCから順番に比較し、合致するか否かを判定する。いずれのiFCも合致することなく、全てのiFCについて判定が終了すると、判定結果に従った着信先アドレス、発信元アドレスおよびサービス要求内容等をセッション制御部14に送出する。
【００６０】
ODI管理部 16は、セッション制御部14からの要求に応じて、ODIの生成、払い出し、払い出し済みODIの管理を行う。ODIは一意に識別可能である必要があるため、ODI管理部16により、払い出し済みのODIを重複して払い出すことのないように管理する必要がある。ただし、代替手段として、時刻情報等の一意に識別可能と想定される値を使用してODIを生成する場合は、ODI管理部16は、払い出し済みODIの管理を行なわず、ODIの生成、払い出しのみを行うこととしてもよい。
【００６１】
また、本実施形態の各AS3は、CSCF−A1から受信した呼確立要求信号に含まれるサービス状態情報を設定した呼確立要求信号を生成する生成部（不図示）と、呼確立要求信号を送信して前記呼制御サーバに接続する接続部（不図示）と、を有する。
【００６２】
なお、CSCF−A1およびAS3は、例えば、ＣＰＵと、メモリと、ＨＤＤ等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、CSCF−A1およびAS3の各機能は、CSCF−A1用のプログラムの場合はCSCF−A1のＣＰＵが、そして、AS3用のプログラムの場合はAS3のＣＰＵがそれぞれ実行することにより実現される。
【００６３】
また、CSCF−A1用のプログラムおよびAS3用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
【００６４】
次に、CSCF−A1の処理について説明する。
【００６５】
［CSCF−A1の処理］
図３および図４は、図２に示したCSCF−Aの処理を説明するためのシーケンス図である。
【００６６】
まず、CSCF−A1が、端末装置4から呼確立要求信号を受信した場合の処理について説明する。ここでは、図３および図４に記載した処理順番を示す番号に「1-」を付加して以下に記述する。
【００６７】
1-1 SIP信号制御部13およびセッション制御部14は、端末装置4、他のCSCF−A1またはAS3から送信されてきた呼確立要求信号を受信する。
【００６８】
1-2 セッション制御部14は、受信した呼確立要求信号（以下、「信号A」と称する）のODI記述部分の存在有無を判定する。ここではODI記述部分が存在しないものとする。なお、呼確立要求信号にODI記述部分が存在するのは、AS3からのCSCF接続処理による呼確立要求信号である。
【００６９】
1-3 セッション制御部14は、信号AのODI記述部分の有無に応じてサービス状態情報を生成する。ここでは、1-2で信号AにはODI記述部分が無いと判定されているため、サービス状態情報は、信号Aの内容およびセッション制御部14が保持しているサービス対象ユーザの状態に基づいて生成される。
【００７０】
具体的には、サービス対象ユーザのAS接続処理要否判定の発着種別は、信号Aが端末装置4からの呼確立要求信号であることから「発」となる。サービス対象ユーザの識別子は、発着種別が「発」となることから、信号Aの発信元アドレスで示されるユーザの識別子となる。サービス対象ユーザのREGISTER状態は、セッション制御部14が保持しているサービス対象ユーザの状態から取得される。サービス対象ユーザのAS接続処理要否判定の進捗状況は、1-2で信号AにODI記述部分が存在しないと判定していることから、初期状態となる。
【００７１】
1-4 セッション制御部14は、AS接続処理要否判定部 15に対して、信号Aに記述されている発信元アドレス、着信先アドレス、サービス要求内容の他に、1-3で生成したサービス状態情報を送出し、AS接続処理判定を要求する。
【００７２】
1-5 AS接続処理判定要求を受けたAS接続処理要否判定部15は、サービス状態情報に含まれるサービス対象ユーザの識別子を用いて、サービス契約情報蓄積部11に対してサービス対象ユーザのサービス契約情報を要求する。
【００７３】
1-6 AS接続処理要否判定部15は、要求したサービス契約情報を取得する。
【００７４】
1-7 AS接続処理要否判定部15は、iFC蓄積部12に対して、1-6で取得したサービス契約情報を用いて、サービス対象ユーザについて判定対象となる全てのiFCを要求する。
【００７５】
1-8 AS接続処理要否判定部15は、要求したiFCを取得する。さらにAS接続処理要否判定部15は、取得した全iFCに設定されている優先度、および発着種別を確認する。
【００７６】
1-9 AS接続処理要否判定部15は、1-4で受け取ったサービス状態情報に含まれるサービス対象ユーザのAS接続処理要否判定の発着種別、およびサービス対象ユーザのAS接続処理要否判定の進捗状況と、1-8で取得した各iFCの優先度とから、次判定対象iFCを選択する。この場合、1-4でAS接続処理要否判定部15に渡されたサービス対象ユーザのAS接続処理要否判定の進捗状況は「初期状態」で、サービス対象ユーザのAS接続処理要否判定の発着種別が「発」となっている。このため、次判定対象iFCは、サービス対象ユーザが契約しているサービスに対応する、1-8で取得した全iFCのうち、最も優先度の高い発サービス用iFCが選択される。
【００７７】
1-10 AS接続処理要否判定部15は、iFC判定処理を行う。すなわち、1-9で選択した次判定対象iFCが、1-4で受信した発信元アドレス、着信先アドレス、サービス要求内容に合致するかを判定する。合致する場合は、1-2で信号AにはODI記述部分は存在しないと判定しているので、図４の1-11の処理に進む。合致しない場合は1-9に戻って当該判定済iFCの次の優先度のiFCを次判定対象iFCとして選択し、1-10でiFC判定処理を行う処理を繰り返す。全発サービス用iFCが合致せず、iFC判定処理が完了した場合は、図４の1-20の処理に進む。
【００７８】
＜1-10のiFC判定処理でいずれかのiFCが合致した場合＞
1-11 AS接続処理要否判定部15は、1-10で合致したiFCに記載された接続先AS情報を、セッション制御部14に送出する。
【００７９】
1-12 セッション制御部14は、1-2で信号AのODI記述部分は存在しないと判定しているため、後述の1-21で呼確立要求信号のODI記述部分を設定するために、ODI管理部 16に対してODIの払い出し要求を行う。
【００８０】
1-13 ODI管理部16は、ODIを一意に識別可能な値として生成し、生成したODIを払い出し済みODIとして記憶し、次回以降に重複した値のODIを生成しないようにする。
【００８１】
1-14 ODI管理部16は、生成されたODIをセッション制御部14に送出する。
【００８２】
1-15 セッション制御部14は、1-14で取得したODIとサービス状態情報とを、ODI記述部分に記載したAS接続処理用の呼確立要求信号を生成する。そして、呼確立要求信号と接続先AS情報とをSIP信号制御部13に送出する。
【００８３】
1-16 SIP信号制御部13は、接続先AS情報に従い、AS接続処理を実施する。
【００８４】
＜1-10のiFC判定処理で全iFCが合致しない場合＞
1-20 1-10で全iFCが合致せずにiFC判定処理が完了した場合、セッション制御部14は、AS接続処理要否判定部15から判定完了後の発信元アドレス、着信先アドレス、サービス要求内容等を受け取り、それらに従った呼確立要求信号を生成する。
【００８５】
1-21 SIP信号制御部13は、1-20で生成した呼確立要求信号に従い、呼接続処理を実施する。
【００８６】
以上の処理が、端末装置4から呼確立要求信号を受信した場合の処理である。
【００８７】
次に、図４の1-16で実施したAS3へのAS接続処理の後、AS3からCSCF接続処理として送信された呼確立要求信号をCSCF-A1が受信した場合の処理について、図３および図４を用いて説明する。ここでは、図３および図４に記載した処理順番を示す番号に「2-」を付加して以下に記述する。
【００８８】
2-1 SIP信号制御部13およびセッション制御部14は、AS3から送信されてきた呼確立要求信号を受信する。
【００８９】
2-2 セッション制御部14は、受信した呼確立要求信号（以下、「信号A」と称する）のODI記述部分の存在有無を判定する。ここではODI記述部分が存在するものとする。なお、AS3のCSCF接続処理により受信する呼確立要求信号には、ODI記述部分が存在する。
【００９０】
2-3 セッション制御部14は、信号AのODI記述部分の有無に応じてサービス状態情報を生成する。ここでは、2-2で信号AにはODI記述部分が有ると判定されているため、サービス状態情報は、信号Aの内容を用いて生成される。
【００９１】
具体的には、サービス状態情報のサービス対象ユーザの識別子、サービス対象ユーザのREGISTER状態、サービス対象ユーザのAS接続処理要否判定の発着種別、サービス対象ユーザのAS接続処理要否判定の進捗状況は、信号AのODI記述部分にサービス状態情報として含まれる値となる。この場合、サービス対象ユーザのAS接続処理要否判定の発着種別は「発」となる。
【００９２】
2-4 セッション制御部14は、AS接続処理要否判定部15に対して、信号Aに記述されている発信元アドレス、着信先アドレス、サービス要求内容の他に、2-3で生成したサービス状態情報を送出し、AS接続処理判定を要求する。
【００９３】
2-5 2-4でAS接続処理判定要求を受けたAS接続処理要否判定部15は、サービス状態情報に含まれるサービス対象ユーザの識別子を用いて、サービス契約情報蓄積部11に対してサービス対象ユーザのサービス契約情報を要求する。
【００９４】
2-6 AS接続処理要否判定部15は、要求したサービス契約情報を取得する。
【００９５】
2-7 AS接続処理要否判定部15は、iFC蓄積部12に対して、2-6で取得したサービ契約情報を用いて、サービス対象ユーザについて判定対象となる全てのiFCを要求する。
【００９６】
2-8 AS接続処理要否判定部15は、要求したiFCを取得する。さらにAS接続処理要否判定部15は、取得した全iFCに設定されている優先度、および発着種別を確認する。
【００９７】
2-9 AS接続処理要否判定部15は、2-4で受け取ったサービス状態情報に含まれるサービス対象ユーザのAS接続処理要否判定の発着種別、およびサービス対象ユーザのAS接続処理要否判定の進捗状況と、2-8で取得した各iFCの優先度とから、次判定対象iFCを選択する。この場合、2-4でAS接続処理要否判定部15に送出されたサービス対象ユーザのAS接続処理要否判定の進捗状況とAS接続処理要否判定の発着種別とは信号Aから取得した値が渡されている。このため、次判定対象iFCは、サービス対象ユーザが契約しているサービスに対応する2-8で取得した全iFCのうち、上記発着種別に対応したiFCであって、上記進捗状況に記載されたiFCの優先度の次に最も高い優先度の発サービス用iFCが選択される。
【００９８】
2-10 AS接続処理要否判定部15は、iFC判定処理を行う。すなわち、2-9で選択した次判定対象iFCが、2-4で受信した発信元アドレス、着信先アドレス、サービス要求内容に合致するかを判定する。合致する場合は、2-2で信号AにはODI記述部分があると判定しているので図４の2-17の処理に進む。合致しない場合は2-9に戻って当該判定済みiFCの次の優先度のiFCを次判定対象iFCとして選択し、2-10でiFC判定処理を行う処理を繰り返す。全iFCが合致せず、iFC判定処理が完了した場合には、図４の2-20の処理に進む。
【００９９】
＜2-10のiFC判定処理でいずれかのiFCが合致した場合＞
2-17 AS接続処理要否判定部15は、2-10で合致したiFCに記載された接続先AS情報を、セッション制御部14に送出する。
【０１００】
2-18 セッション制御部14は、2-2で信号AのODI記述部分はあると判定しているため、信号Aに記載されているODI記述部分を、そのままODI記述部分に記載したAS接続処理用の呼確立要求信号を生成する。そして、呼確立要求信号と接続先AS情報とをSIP信号制御部13に送出する。
【０１０１】
2-19 SIP信号制御部13は、接続先AS情報に従い、AS接続処理を実施する。
【０１０２】
＜2-10のiFC判定処理で全iFCが合致しない場合＞
2-20 2-10で全iFCが合致せずにiFC判定処理が完了した場合、セッション制御部14は、AS接続処理要否判定部15から判定完了後の発信元アドレス、着信先アドレス、サービス要求内容等を受け取り、それらに従った呼確立要求信号を生成する。
【０１０３】
2-21 SIP信号制御部13は、2-20で生成した呼確立要求信号に従い、呼接続処理を実施する。
【０１０４】
以上の処理が、AS3からCSCF接続処理として呼確立要求信号を受信し、サービス対象ユーザのAS接続処理要否判定の発着種別が「発」の場合の処理である。
【０１０５】
次に、上記2-21で実施した呼接続処理の結果、着信ユーザを収容した他のCSCF-A1が呼確立要求信号を受信した場合の処理を図３および図４を用いて説明する。ここでは、図３および図４に記載した処理順番を示す番号に「3-」を付加して以下に記述する。
【０１０６】
3-1 着側CSCF-A1のSIP信号制御部13およびセッション制御部14は、発側CSCF-A1から送信されてきた呼確立要求信号を受信する。
【０１０７】
3-2 セッション制御部14は、受信した呼確立要求信号（以下、「信号A」と称する）のODI記述部分の存在有無を判定する。ここではODI記述部分が存在しないものとする。なお、呼確立要求信号にODI記述部分が存在するのは、AS3からのCSCF接続処理で受信する呼確立要求信号であり、発側CSCF-A1から送信されてくる呼確立要求信号にはODI記述部分は存在しない。
【０１０８】
3-3 セッション制御部14は、信号AのODI記述部分の有無に応じてサービス状態情報を生成する。ここでは、3-2で信号AにはODI記述部分が無いと判定されているため、サービス状態情報は、信号Aの内容、およびセッション制御部14が保持しているサービス対象ユーザの状態により生成される。
【０１０９】
具体的には、サービス状態情報のサービス対象ユーザのAS接続処理要否判定の発着種別は、信号Aが発側CSFC-A1からの呼確立要求信号であることから「着」となる。サービス対象ユーザの識別子は、発着種別が「着」となることから、信号Aの着信先アドレスで示されるユーザの識別子となる。サービス対象ユーザのREGISTER状態は、セッション制御部14が保持しているサービス対象ユーザの状態より取得される。サービス対象ユーザのAS接続処理要否判定の進捗状況は、3-2にて信号AにODI記述部分が存在しないと判定していることから、「初期状態」となる。
【０１１０】
3-4 セッション制御部14は、AS接続処理要否判定部 15に対して、信号Aに記述されている発信元アドレス、着信先アドレス、サービス要求内容の他に、3-3で生成したサービス状態情報を送出し、AS接続処理判定を要求する。
【０１１１】
3-5 3-4でAS接続処理判定要求を受け取ったAS接続処理要否判定部15は、サービス状態情報に含まれるサービス対象ユーザの識別子を用いて、サービス契約情報蓄積部11に対してサービス対象ユーザのサービス契約情報を要求する。
【０１１２】
3-6 AS接続処理要否判定部15は、要求したサービス契約情報を取得する。
【０１１３】
3-7 AS接続処理要否判定部15は、iFC蓄積部12に対して3-6で取得したサービス契約情報を用いて、サービス対象ユーザについて判定対象となる全てのiFCを要求する。
【０１１４】
3-8 AS接続処理要否判定部15は、要求したiFCを取得する。さらに、AS接続処理要否判定部15は、取得した全iFCに設定されている優先度、および発着種別を確認する。
【０１１５】
3-9 AS接続処理要否判定部15は、3-4で受け取ったサービス状態情報に含まれるサービス対象ユーザのAS接続処理要否判定の発着種別、およびサービス対象ユーザのAS接続処理要否判定の進捗状況と、3-8で取得した各iFCの優先度とから、次判定対象iFCを選択する。この場合、3-4でAS接続処理要否判定部15に渡されたサービス対象ユーザのAS接続処理要否判定の進捗状況は「初期状態」で、サービス対象ユーザのAS接続処理要否判定の発着種別が「着」となっている。このため、次判定対象iFCは、サービス対象ユーザが契約しているサービスに対応する、3-8で取得した全iFCのうち、最も優先度の高い着サービス用iFCが選択される。
【０１１６】
3-10 AS接続処理要否判定部15は、iFC判定処理を行う。すなわち、3-9で選択した次判定対象iFCが、3-4で受信した発信元アドレス、着信先アドレス、サービス要求内容に合致するかを判定する。合致する場合は、3-2で信号AにはODI記述部分は存在しないと判定しているので、図４の3-11の処理に進む。合致しない場合は3-9に戻って当該判定済iFCの次の優先度のiFCを次判定対象iFCとして選択し、3-10でiFC判定処理を行う処理を繰り返す。全着サービス用iFCが合致せず、iFC判定処理が完了した場合には、図４の3-20の処理に進む。
【０１１７】
＜3-10のiFC判定処理でいずれかのiFCが合致した場合＞
3-11 3-10で合致したiFCに記載された接続先AS情報を、AS接続処理要否判定部15からセッション制御部14に送出する。
【０１１８】
3-12 セッション制御部14は、3-2で信号AのODI記述部分は存在しないと判定しているため、後述の3-21で呼確立要求信号のODI記述部分を設定するために、ODI管理部 16に対してODIの払い出し要求を行う。
【０１１９】
3-13 ODI管理部16は、ODIを一意に識別可能な値として生成し、生成したODIを払い出し済みODIとして記憶し、次回以降に重複した値のODIを生成しないようにする。
【０１２０】
3-14 ODI管理部16は、生成したODIをセッション制御部14に送出する。
【０１２１】
3-15 セッション制御部14は、3-14で取得したODIとサービス状態情報とを、ODI記述部分に記載したAS接続処理用の呼確立要求信号を生成する。そして、呼確立要求信号と接続先AS情報とをSIP信号制御部13に送出する。
【０１２２】
3-16 SIP信号制御部13は、接続先AS情報に従い、AS接続処理を実施する。
【０１２３】
＜3-10のiFC判定処理で全iFCが合致しない場合＞
3-20 3-10で全iFCが合致せずにiFC判定処理が完了した場合、セッション制御部14は、AS接続処理要否判定部15から判定完了後の発信元アドレス、着信先アドレス、サービス要求内容等を受け取り、それらに従った呼確立要求信号を生成する。
【０１２４】
3-21 SIP信号制御部13は、3-20で生成した呼確立要求信号に従い、呼接続処理を実施する。
【０１２５】
以上の処理が、発CSCF-A1から呼確立要求信号を受信した場合の処理である。
【０１２６】
次に、図４の上記3-16で実施した着サービス用iFCのAS3へのAS接続処理の後、AS3からCSCF接続処理として送信された呼確立要求信号を着側CSCF-A1が受信した場合の処理について、図３および図４を用いて説明する。ここでは、図３および図４に記載した処理順番を示す番号の先頭に「4-」を付加して以下に記述する。
【０１２７】
4-1 着側CSCF-A1のSIP信号制御部13およびセッション制御部14は、AS3から送信されてきた呼確立要求信号を受信する。
【０１２８】
4-2 セッション制御部14は、受信した呼確立要求信号（以下、「信号A」と称する）のODI記述部分の存在有無を判定する。ここでは、ODI記述部分が存在するものとする。なお、AS3からCSCF接続処理で受信する呼確立要求信号には、ODI記述部分が存在する。
【０１２９】
4-3 セッション制御部14は、信号AのODI記述部分有無に応じてサービス状態情報を生成する。この場合、4-2で信号AにはODI記述部分があると判定されているため、サービス状態情報は信号Aの内容により生成される。
【０１３０】
具体的には、サービス状態情報のサービス対象ユーザの識別子、サービス対象ユーザのREGISTER状態、サービス対象ユーザのAS接続処理要否判定の発着種別、サービス対象ユーザのAS接続処理要否判定の進捗状況は、信号AのODI記述部分にサービス状態情報として含まれる値となる。この場合、サービス対象ユーザのAS接続処理要否判定の発着種別は「着」となる。
【０１３１】
4-4 セッション制御部14は、AS接続処理要否判定部 15に対して、信号Aに記述されている発信元アドレス、着信先アドレス、サービス要求内容の他に、4-3で生成したサービス状態情報を送出し、AS接続処理判定を要求する。
【０１３２】
4-5 4-4でAS接続処理判定要求を受けたAS接続処理要否判定部15は、サービス状態情報に含まれるサービス対象ユーザの識別子を用いて、サービス契約情報蓄積部11に対してサービス対象ユーザのサービス契約情報を要求する。
【０１３３】
4-6 AS接続処理要否判定部15は、要求したサービス契約情報を取得する。
【０１３４】
4-7 AS接続処理要否判定部15は、iFC蓄積部12に対して4-6で取得したサービス契約情報を用いて、サービス対象ユーザについて判定対象となる全てのiFCを要求する。
【０１３５】
4-8 AS接続処理要否判定部15は、要求したiFCを取得する。さらにAS接続処理要否判定部15は、取得した全iFCに設定されている優先度、および発着種別を確認する。
【０１３６】
4-9 AS接続処理要否判定部15は、4-4で取得したサービス状態情報に含まれるサービス対象ユーザのAS接続処理要否判定の発着種別、およびサービス対象ユーザのAS接続処理要否判定の進捗状況と、4-8で取得した各iFCの優先度とから、次判定対象iFCを選択する。この場合、4-4でAS接続処理要否判定部15に送出されたサービス対象ユーザのAS接続処理要否判定の進捗状況とAS接続処理要否判定の発着種別とは信号Aから取得した値が渡されている。このため、次判定対象iFCは、サービス対象ユーザが契約しているサービスに対応する4-8で取得した全iFCのうち、上記発着種別に対応したiFCであって、上記進捗状況に記載されたiFCの優先度の次に最も優先度の高い着サービス用iFCが選択される。
【０１３７】
4-10 AS接続処理要否判定部15は、iFC判定処理を行う。すなわち、4-9で選択した次判定対象iFCに、4-4で受信した発信元アドレス、着信先アドレス、サービス要求内容に合致するかを判定する。合致する場合は、4-2で信号AにはODI記述部分があると判定しているので図４の4-17の処理に進む。合致しない場合は4-9に戻って判定済みiFCの次の優先度のiFCを次判定対象iFCとして選択し、4-10でiFC判定処理を行う処理を繰り返す。全iFCが合致せず、iFC判定処理が完了した場合には、図４の4-20の処理に進む。
【０１３８】
＜4-10のiFC判定処理でいずれかのiFCが合致した場合＞
4-17 AS接続処理要否判定部15は、4-10で合致したiFCに記載された接続先AS情報を、セッション制御部14に送出する。
【０１３９】
4-18 セッション制御部14は、4-2で信号AのODI記述部分はあると判定しているため、信号Aに記載されていたODI記述部分を、そのままODI記述部分に記載したAS接続処理要の呼確立要求信号を生成する。そして、呼確立要求信号と接続先AS情報とをSIP信号制御部13に送出する。
【０１４０】
4-19 SIP信号制御部13は、接続先AS情報に従い、AS接続処理を実施する。
【０１４１】
＜4-10のiFC判定処理で全iFCが合致しない場合＞
4-20 4-10で全iFCが合致せずにiFC判定処理が完了した場合、セッション制御部14は、AS接続処理要否判定部15から判定完了後の発信元アドレス、着信先アドレス、サービス要求内容等を受け取り、それらに従った呼確立要求信号を生成する。
【０１４２】
4-21 SIP信号制御部13は、4-20で生成した呼確立要求信号に従い、呼接続処理を実施する。
【０１４３】
以上説明した本実施形態では、CSCFはAS接続処理を行う際に、呼確立要求信号にサービス状態情報を含めてASに送信し、ASは受信した呼確立要求信号に含まれるサービス状態情報をCSCF接続処理を行う際の呼確立要求信号に透過的に設定してCSCFに送信し、CSCFはASから受信した呼確立要求信号に含まれるサービス状態情報を抽出し解析することにより当該呼のサービス状態情報を取得できるようにする。
【０１４４】
これにより、CSCF接続処理によりASから呼確立要求信号を受信したCSCFが、正常に処理を継続するのに必要なサービス状態情報は、受信した呼確立要求信号に含まれているため、サービス状態情報を記録する記憶領域を削減することができる。すなわち、従来技術でサービス状態情報を記録するために必要とされていた、CSCFの記憶領域を削減することができる。これにより、ODIが同時に多数払いだされるような利用形態のCSCFであっても、より少ない記憶容量（ハードウェア）で、CSCFとAS間の呼確立要求信号のISCインタフェースを実現することができる。また、サービス状態情報用の記憶容量が削減されることから、削減された分をユーザ収容データ用の記憶領域として用いることができる。
【０１４５】
また、本実施形態では、サービス状態情報は呼確立要求信号に含まれて送受信されるため、サービス状態情報の取得のために記憶領域へアクセスする回数を削減することができる。すなわち、サービス状態情報の取得処理がCSCFの性能ボトルネックとなる事態を回避することができる。
【０１４６】
また、本実施形態では、ASからCSCFが受信した呼確立要求信号の内容とCSCFが保持するサービス状態情報の突合処理が不要となる。
【０１４７】
なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【０１４８】
例えば、上記実施形態では、呼確立要求信号中にサービス状態情報が含まれる箇所は、呼確立要求信号のODI記述部分であるものとして説明したが、呼確立要求信号中の他の部分にサービス状態情報を含めることとしてもよい。
【０１４９】
また、上記実施形態では、サービス状態情報の全部を、呼確立要求信号中に含めて送信することとしたが、サービス状態情報の一部を呼確立要求信号中に含めて送信することとしてもよい。この場合、呼確立要求信号中に含めないサービス状態情報については従来技術と同様にCSCFの記憶領域へ記録を行い、呼確立要求信号中に含めたサービス状態情報については記憶領域への記録を行わないことで、サービス状態情報の記録に必要な記憶領域を低減することができる。
【０１５０】
また、本発明は、以下に示す変形例の1つあるいは複数を適用することとしてもよい。
【０１５１】
(1)図４の15あるいは18において、呼確立要求信号のODI記述部分を生成する際、ODIとサービス状態情報とを用いてODI記述部分を生成するのではなく、サービス状態情報のみを用いてODI記述部分を生成することとしてもよい。
【０１５２】
(2)上記(1)に併せて、ODI管理部 16を使用せず、図４の12〜14のODIの払い出し処理・取得を行わないこととしてもよい。
【０１５３】
(3)図４の15あるいは18において、呼確立要求信号のODI記述部分にサービス状態情報を含める際、サービス状態情報そのものではなく、予め定めたサービス状態情報相当の符号を含めることとしてもよい。符号は、図３の3でサービス状態情報をして復元される。
【符号の説明】
【０１５４】
１ ：ＣＳＣＦ−Ａ
１１：サービス契約情報蓄積部
１２：iFC蓄積部
１３：SIP信号制御部
１４：セッション制御部
１５：AS接続処理要否判定部
１６：ODI管理部
３ ：AS
４ ：端末装置
【技術分野】
【０００１】
本発明は、3GPP（Third Generation Partnership Project）、3GPP2（Third Generation Partnership Project2）にて標準化されているIMS（IP Multimedia ）において、呼確立要求信号を受信した呼セッション制御機能部（以下「CSCF」：Call Session Control Functionと称する）と、サービスを提供するアプリケーションサーバ（以下、「AS」：Application Serverと称する）との間の呼確立要求信号の流通インタフェース（以下、IMSのインタフェース呼称に従い「ISCインタフェース」：IP multimedia Service Controlインタフェースと称する）に関する。
【背景技術】
【０００２】
ISCインタフェースにおいては、CSCFが、ASに呼確立要求信号を送信後、ASから当該呼に対応した呼確立要求信号を受信した場合に、先にCSCFからASに送信した呼確立要求信号に対応するサービス状態の情報を識別可能である必要がある。呼確立要求信号は、SIP（Session Initiation Protocol）における、INVITEメソッド（Initial-INVITE）、MESSAGEメソッドなどを指す。
【０００３】
ここでいうサービス状態の情報（以下、「サービス状態情報」と称する）は、CSCFからASへ呼確立要求信号を送信する処理（以下、「AS接続処理」と称する）を行う時点でサービス対象ユーザとして認識しているユーザの識別子など、サービス提供を正常に継続するためにCSCFが必要とする情報である。
【０００４】
ISCインタフェースの実装技術については、例えば非特許文献１、非特許文献２に記載されている。また、SIPについては、例えば非特許文献３に記載されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】“3GPP TS 23．218 V9.2.0”、3rd Generation Partnership Project (3GPP)、2010年6月、［online］、［2010年12月9日検索］、インターネット＜http://www.3gpp.org/ftp/Specs/archive/23_series/23.218/23218-920.zip＞
【非特許文献２】“3GPP TS 24．229 V10.1.0”、3rd Generation Partnership Project (3GPP)、2010年9月、［online］、［2010年12月9日検索］、インターネット＜http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-a10.zip＞
【非特許文献３】J. Rosenberg, et. al.、“SIP : Session Initiation Protocol RFC 3261”、IETF、2002年6月、［2010年12月13日検索］、インターネット＜http://datatracker.ietf.org/doc/rfc3261/?include_text=1＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
非特許文献１、非特許文献２に記載のISCインタフェースの実装技術では、以下の手順を行うことでCSCFにサービス状態情報の識別を可能にする。
【０００７】
１）CSCFがAS接続処理を行う際に、当該呼のサービス状態情報をそのサービス状態情報と一意に対応付けが可能な識別子（以下、「ODI」：Original Dialog Identifierと称する）とともにCSCFが保持し、ODIを呼確立要求信号に含めてASに送信する。
【０００８】
２）ASが上記１）の呼に対応した呼確立要求信号をCSCFに送信する処理（以下、「CSCF接続処理」と称する）を行う際に、AS接続処理時にASが受信した呼確立要求信号に含まれたODIを含めて送信する。
【０００９】
３）上記２）のCSCF接続処理の呼確立要求信号を受信したCSCFは、呼確立要求信号中に含まれるODIを基に、受信呼確立要求信号に対応するサービス状態情報を識別・取得し、呼処理を継続する。
【００１０】
図５は、従来のISCインタフェース実装技術における、CSCFとAS間でODIを含む呼確立要求信号が流通し、それによりCSCFおよびASが正常にサービス提供する動作を説明するための図である。図示するシステムは、CSCF-Cと、AS#6 3fと、AS#7 3gと、端末装置4aと、端末装置4bとを有し、AS#6 3fおよびAS#7 3gはCSCF-Cに接続され、端末装置4aおよび端末装置4bもCSCF-Cに接続されている。
【００１１】
CSCF-Cは、加入者系のセッション制御機能を有するユーザ収容ノードである。
【００１２】
AS#6 3fおよびAS#7 3gは、CSCF-Cから接続されることによりサービスを提供するアプリケーションサーバである。
【００１３】
端末装置4aおよび端末装置4bは、通信サービスを利用するユーザが操作する端末装置であり、図５の例では端末装置4aを呼の発信側とし、端末装置4bを呼の着信側としている。
【００１４】
CSCF-Cには、AS接続処理を行う呼が発生した場合、CSCF-Cにて生成するODI毎にサービス状態情報を記憶する記憶領域31が確保されている。
【００１５】
呼確立要求信号21〜26は、端末装置4aから送信された呼確立要求信号21を契機に発生する一連の呼確立要求信号を示している。
【００１６】
端末装置4aが呼確立要求信号21を送信すると、CSCF-Cが受信し、AS接続処理が必要か否かを判定する。AS接続処理の要否判定は、非特許文献１、非特許文献２に記載される接続条件(以下、「iFC」: initial Filter Criteriaと称する)と呼確立要求信号の内容とを比較し、条件に該当する場合にAS接続処理を行う。図５の例では、iFCに呼確立要求信号が合致し、AS#6 3fへのAS接続処理が必要であると判定されるものとする。
【００１７】
CSCF-CがAS#6 3fへAS接続処理を行う際、CSCF-Cは、ODIを一意に識別可能となるように生成し、生成したODIを端末装置4aから受信した呼確立要求信号およびCSCFの保持する加入者データを分析した結果得られるサービス状態情報と対応付けて記憶領域31に記憶する。さらに、AS#6 3fへの呼確立要求信号22に生成したODIを含めて送信する。
【００１８】
呼確立要求信号22を受信したAS#6 3fは、自身のサービス論理に従って呼確立要求信号22を加工し、CSCF接続処理として呼確立要求信号23をCSCF-Cに送信する。この際、呼確立要求信号23には、呼確立要求信号22でAS#6 3fが受信したODIと同一の値のODIが含まれる。呼確立要求信号23は、呼確立要求信号22と比べた場合、着信者を示すRequest-URI、Toヘッダフィールド等の値が変更されている可能性があり、また発信者を示すFromヘッダフィールド、P-Asserted-Identityヘッダフィールド等の値が変更されている可能性もある。その他、AS#6 3fのサービス論理の条件により呼確立要求信号に含まれるその他の情報が追加、変更、削除されている可能性がある。
【００１９】
CSCF-Cは、呼確立要求信号23を受信すると、当該呼確立要求信号23に含まれるODIを抽出し、当該ODIに対応するサービス状態情報を記憶領域31から取得する。これは、CSCF-Cは引き続きAS接続処理要否判定を行うが、その判定には端末装置4aから呼確立要求信号21を受信した時点のサービス状態情報が必要であることによる。つまり、呼確立要求信号23はAS#6 3fによりODI以外の情報を変更されている可能性があるため、呼確立要求信号23からは「どのユーザをサービス対象ユーザと認識するか（どのユーザのiFCを用いてAS接続処理要否判定を実施するか）」、「当該一連の呼についてサービス対象ユーザのiFCをどこまで処理したかの進捗状況」といったサービス状態情報に相当する情報が確実に抽出できるとは限らないからである。
【００２０】
CSCF-Cが、記憶領域31から取得したサービス状態情報を用いて、引き続きAS接続処理要否判定を行った結果、今度はAS#7 3gにAS接続処理が必要になったとする。CSCF-Cは、呼確立要求信号23で受信したODIに対応するサービス状態情報のiFC処理の進捗状況を更新して、記憶領域31に記憶する。さらに、CSCF-Cは、AS#7 3gへ呼確立要求信号24を送信する。
【００２１】
AS#7 3gが呼確立要求信号24を受信した際の処理は、先に述べたAS#6 3fが呼確立要求信号22を受信した際の処理と同様である。
【００２２】
CSCF-Cは、呼確立要求信号25を受信すると、呼確立要求信号25に含まれるODIを抽出し、当該ODIに対応するサービス状態情報を記憶領域31から取得する。
【００２３】
CSCF-Cが、記憶領域31から取得したサービス状態情報を用いて、引き続きAS接続処理要否判定を行った結果、今度はAS接続処理が不要と判定されたとする。CSCF-Cは、呼確立要求信号25で受信したODIに対応するサービス状態情報のiFC処理の進捗状況を更新して、記憶領域31に記憶する。さらに、CSCF-Cは、端末装置4bへ呼確立要求信号26を送信する。
【００２４】
以降はIMSとして標準的なSIPの呼確立処理を行い、呼が確立する。
【００２５】
上記のような従来技術では、ASのサービス論理による呼確立要求信号内容の追加、変更、削除の影響を受けずに正常に呼処理を継続するためには、CSCFが記憶領域にサービス状態情報を保持しておくことが必要である。サービス状態情報の保持期間は、図５に示す呼確立処理では、呼確立要求信号21についてCSCFがサービス状態情報を保持してから呼確立要求信号21〜26に対応する呼が解放されるまでとなる。
【００２６】
サービス状態情報は、CSCFがODIを生成する毎に1レコード必要であり、その分CSCFでは記憶領域の確保が必要となる。このことは、1つのCSCFで多数の呼がAS連携処理を行うような場合ほど、大量の記憶領域が必要となることを意味する。また、1つのCSCFで多数のユーザを収容可能であるほど、大量の記憶領域が必要となる。すなわち、ODI毎にサービス状態情報をCSCFが保持する必要があり、多数の呼についてAS接続処理を行う場合はそれに見合ったCSCFの記憶領域を確保する必要があり、CSCFシステムのコスト増加の要因となる。
【００２７】
さらに、CSCFの演算性能に対して、記憶領域からの読み出し速度、あるいは記憶領域への書き込み速度が不十分の場合は、読み出しあるいは書き込みの待ち合わせ時間が長くなり、CSCFの呼処理性能のボトルネックとなるという問題もある。
【００２８】
本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、呼セッション制御サーバとアプリケーションサーバ間の呼確立要求信号の流通インタフェースにおいて、サービス状態情報の記憶領域を削減可能な呼制御方法、および呼制御システムを提供することにある。
【課題を解決するための手段】
【００２９】
上記目的を達成するため、本発明は、呼制御サーバとアプリケーションサーバ間の呼確立要求信号の流通インタフェースにおける呼制御方法であって、前記呼制御サーバは、 サービス状態情報を含む第１の呼確立要求信号を生成し、当該第１の呼確立要求信号を送信して前記アプリケーションサーバに接続する第１の接続ステップを行い、前記アプリケーションサーバは、前記呼制御サーバから受信した前記第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成し、当該第２の呼確立要求信号を送信して前記呼制御サーバに接続する第２の接続ステップを行い、前記呼制御サーバは、前記アプリケーションサーバから受信した前記第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定ステップと、を行う。
【００３０】
また、本発明は、呼制御サーバと、アプリケーションサーバとを有する呼制御システムであって、前記呼制御サーバは、サービス状態情報を含む第１の呼確立要求信号を生成する生成手段と、前記第１の呼確立要求信号を送信して前記アプリケーションサーバに接続する接続手段と、前記アプリケーションサーバから受信した第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定手段と、を有し、前記アプリケーションサーバは、前記呼制御サーバから受信した前記第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成する生成手段と、前記第２の呼確立要求信号を送信して前記呼制御サーバに接続する接続手段と、を有する。
【発明の効果】
【００３１】
本発明によれば、呼セッション制御サーバとアプリケーションサーバ間の呼確立要求信号の流通インタフェースにおいて、サービス状態情報の記憶領域を削減可能な呼制御方法、および呼制御システムを提供することができる。
【図面の簡単な説明】
【００３２】
【図１】本発明の実施形態に係るシステムの全体構成図である。
【図２】本実施形態のCSCFの構成例を示す図である。
【図３】CSCFの処理を説明するためのシーケンス図（その１）である。
【図４】CSCFの処理を説明するためのシーケンス図（その２）である。
【図５】従来のCSCFの処理を説明するための説明図である。
【発明を実施するための形態】
【００３３】
以下、本発明の実施の形態について、図面を参照して説明する。
【００３４】
まず、本実施形態に係るシステムについて説明する。
【００３５】
［システムの構成］
図１は、本実施形態のシステムの構成例を示す構成図である。図示する本システムは、CSCF−A1（呼制御サーバ）と、複数のAS （AS#1 3a、AS#2 3b、AS#3 3c、AS#4 3d、およびAS#5 3e）と、端末装置4とを有する。なお、どのASであるかを特定しない場合は、「AS3」と記載する。AS#1 3a〜AS#5 3eの各々は、CSCF−A1に接続され、端末装置4もCSCF−A1に接続される。
【００３６】
CSCF−A1は、iFC処理を実装した加入者系のセッション制御機能を含むユーザ収容ノード（例えば、SIPサーバなど）である。詳細については後述する。
【００３７】
AS#1 3a〜AS#5 3eは、CSCF−A1から接続されて、各種のサービスを提供するアプリケーションサーバである。図１では、５つのAS3を示しているが、AS3の数はこれに限定されるものではない。
【００３８】
端末装置4は、通信サービスを利用するユーザが操作する端末装置である。なお、図１では、CSCF−A1に接続される端末装置4は1つであるが、端末装置４は複数存在してもよい。
【００３９】
次に、本システムの機能について説明する。
【００４０】
［システムの機能］
本システムでは、CSCF−A1は、端末装置4あるいは他のCSCF−A（不図示）から送信されてきた呼確立要求信号を受信すると、呼確立要求信号の内容と、当該CSCF−A1に設定されたiFC（接続条件）とを比較し、条件に合致するか否かによりAS接続処理の要否を判定（AS接続処理要否判定）する。AS接続処理要と判定された場合、CSCF−A1は、AS接続処理として、ODI記述部分にサービス状態情報を記述した呼確立要求信号を生成し、AS3に送信する。
【００４１】
なお、ODI記述部分は、非特許文献１および非特許文献２に規定されているように、SIPリクエスト信号のRouteヘッダフィールドに記載されるname-addr部のuserinfo部を指す。SIPリクエスト信号規定については非特許文献３に記載されている。
【００４２】
AS3は、受信した呼確立要求信号を当該AS3自身のサービス論理に従って加工することにより新たな呼確立要求信号を生成し、CSCF接続処理としてCSCF-A1に送信する。なお、新たな呼確立要求信号のODI記述部分には、AS3がCSCF−A1から受信した呼確立要求信号のODI記述部分と同一の値を透過的に設定する。
【００４３】
CSCF-A1は、CSCF接続処理によりAS3から送信された呼確立要求信号を受信すると、当該呼確立要求信号のODI記述部分に含まれるサービス状態情報を抽出し、抽出したサービス状態情報に基づいて引き続きAS接続処理要否判定を行う。
【００４４】
なお、サービス状態情報は、CSCF-A1がAS3からCSCF接続処理による呼確立要求信号を受信した後、正常に引き続きAS接続処理要否判定を実施するために必要となる情報である。本実施形態では、サービス状態情報として、「サービス対象ユーザの識別子」、「サービス対象ユーザのREGISTER状態」、「サービス対象ユーザのAS接続処理要否判定の進捗状況」、「サービス対象ユーザのAS接続処理要否判定の発着種別」を用いるが、本発明はこれらに限定されるものではない。例えば、これら以外の他の情報を用いたり、あるいは、これらの情報の一部を用いることとしてもよい。
【００４５】
「サービス対象ユーザの識別子」は、サービス対象ユーザを一意に識別可な識別子である。
【００４６】
「サービス対象ユーザのREGISTER状態」は、サービス対象ユーザのREGISTER状態がREGISTER未登録状態か、REGISTER登録済み状態かの種別である。AS接続処理後のAS3のサービス条件が、サービス対象ユーザがREGISTER未登録状態か、REGISTER登録済み状態かにより異なる場合があるため、本実施形態では、サービス状態情報の1つとする。
【００４７】
「サービス対象ユーザのAS接続処理要否判定の進捗状況」は、サービス対象ユーザのAS接続処理要否判定の進捗状況を示すものであり、本実施形態では判定済みiFCの識別子を用いる。AS3によるCSCF接続処理後、引き続きAS接続処理要否判定を行う際に、判定済みiFCの次優先度のiFCから判定を継続するために使用する。なお、次優先度のiFCから判定を継続可能であれば、判定済みiFCの識別子以外の情報を用いることとしてもよい。
【００４８】
「サービス対象ユーザのAS接続処理要否判定の発着種別」は、発CSCFにおいてAS接続処理要否判定を行っているのか、着CSCFにおいてAS接続処理要否判定を行っているのかの種別である。ASのサービス条件として、発CSCFにおけるAS接続処理の場合と、着CSCFにおけるAS接続処理の場合とは、サービス提供条件が異なる場合が有るため、本実施形態ではサービス状態情報の1つとする。
【００４９】
次に、本実施形態のCSCF−A1について説明する。
【００５０】
［CSCF−A1の構成］
図２は、図１に示すシステムにおけるCSCF−A1の構成例を示す図である。同図は、CSCF−A1の機能のうち、本発明に関係する部分のみを概念的に示している。
【００５１】
CSCF-A1は、サービス契約情報蓄積部11と、iFC蓄積部12と、SIP信号制御部13（接続手段）と、セッション制御部14（生成手段）と、AS接続処理要否判定部15（判定手段）と、ODI管理部16とを有する。
【００５２】
サービス契約情報蓄積部11は、ユーザ毎にユーザが契約したサービス契約情報を蓄積する。サービス契約情報蓄積部11には、iFC蓄積部12が蓄積する各iFCについて、各ユーザがどのサービスに契約しているか、すなわちユーザ毎にどのiFCを設定可能かの情報、および、各ユーザと当該ユーザに実際に設定されたiFCとの対応情報が、記憶されている。
【００５３】
iFC蓄積部12は、ユーザ毎に優先度が設定された、各サービスのiFC（接続条件）を蓄積する。
【００５４】
SIP信号制御部13は、呼確立要求信号（SIP信号のINVITE、MESSAGE等）や呼確立要求信号に対する応答信号（200 OK信号等）を受信し、これらの信号をセッション制御部14に送出するとともに、セッション制御部14から送出されるこれらの信号の処理結果にもとづき呼確立要求信号およびその応答信号を送信する。
【００５５】
セッション制御部 14は、SIP信号制御部 13から送出される信号を解析した結果と、必要に応じて当該セッション制御部 14が生成した情報あるいはODI管理部 16から取得した情報とに基づいて、サービス対象ユーザの識別子、発信元アドレス、着信先アドレス、サービス要求内容、サービス状態情報等をAS接続処理要否判定部 15に送出する。
【００５６】
また、セッション制御部 14は、AS接続処理要否判定部 15から送出される判定終了後の着信先アドレス、発信元アドレス、サービス要求内容、サービス状態情報等を受け取り、着信先アドレス、発信元アドレスおよびサービス要求内容等をSIP信号制御部 13に送出し、またODI管理部 16からODIを取得する。そして、セッション制御部 14は、ODIと、サービス状態情報とを1つにまとめ、ODI記述部分の値としてSIP信号制御部 13に送出する。サービス状態情報は、セッション制御部14が把握しているサービス対象ユーザの識別子と、セッション制御部14が把握しているサービス対象ユーザのREGISTER登録状態と、セッション制御部14が把握しているサービス対象ユーザのAS接続処理要否判定の発着種別と、AS接続処理要否判定部 15から受け取ったサービス対象ユーザのAS接続処理要否判定の進捗状況である。
【００５７】
セッション制御部 14の動作条件は、SIP信号制御部 13から送出される呼確立要求信号のODI記述部分に情報が存在するか否かで異なる。詳細については後述する。
【００５８】
AS接続処理要否判定部 15は、セッション制御部14から送出されるサービス対象ユーザの識別子によりサービス契約情報蓄積部11からサービス対象ユーザのサービス契約情報を取得する。また、iFC蓄積部12からサービス対象ユーザに対応する、優先度が設定されたiFCを全て取得し、取得した各iFCにサービス契約情報を反映させる。そして、これらの各iFCと、呼確立要求信号に含まれる着信先アドレス、発信元アドレスあるいはサービス要求内容等とを比較し、合致するか否かを判定する。合致する場合は、接続先AS3情報をセッション制御部14に送出する。
【００５９】
また、AS接続処理要否判定部 15は、セッション制御部14から、AS3が提供するサービスに則った呼確立要求信号に含まれる着信先アドレス、発信元アドレスあるいはサービス要求内容等を受け取り、優先度の最も高いiFCから順番に比較し、合致するか否かを判定する。いずれのiFCも合致することなく、全てのiFCについて判定が終了すると、判定結果に従った着信先アドレス、発信元アドレスおよびサービス要求内容等をセッション制御部14に送出する。
【００６０】
ODI管理部 16は、セッション制御部14からの要求に応じて、ODIの生成、払い出し、払い出し済みODIの管理を行う。ODIは一意に識別可能である必要があるため、ODI管理部16により、払い出し済みのODIを重複して払い出すことのないように管理する必要がある。ただし、代替手段として、時刻情報等の一意に識別可能と想定される値を使用してODIを生成する場合は、ODI管理部16は、払い出し済みODIの管理を行なわず、ODIの生成、払い出しのみを行うこととしてもよい。
【００６１】
また、本実施形態の各AS3は、CSCF−A1から受信した呼確立要求信号に含まれるサービス状態情報を設定した呼確立要求信号を生成する生成部（不図示）と、呼確立要求信号を送信して前記呼制御サーバに接続する接続部（不図示）と、を有する。
【００６２】
なお、CSCF−A1およびAS3は、例えば、ＣＰＵと、メモリと、ＨＤＤ等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされた所定のプログラムを実行することにより、各装置の各機能が実現される。例えば、CSCF−A1およびAS3の各機能は、CSCF−A1用のプログラムの場合はCSCF−A1のＣＰＵが、そして、AS3用のプログラムの場合はAS3のＣＰＵがそれぞれ実行することにより実現される。
【００６３】
また、CSCF−A1用のプログラムおよびAS3用のプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ−ＲＯＭなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
【００６４】
次に、CSCF−A1の処理について説明する。
【００６５】
［CSCF−A1の処理］
図３および図４は、図２に示したCSCF−Aの処理を説明するためのシーケンス図である。
【００６６】
まず、CSCF−A1が、端末装置4から呼確立要求信号を受信した場合の処理について説明する。ここでは、図３および図４に記載した処理順番を示す番号に「1-」を付加して以下に記述する。
【００６７】
1-1 SIP信号制御部13およびセッション制御部14は、端末装置4、他のCSCF−A1またはAS3から送信されてきた呼確立要求信号を受信する。
【００６８】
1-2 セッション制御部14は、受信した呼確立要求信号（以下、「信号A」と称する）のODI記述部分の存在有無を判定する。ここではODI記述部分が存在しないものとする。なお、呼確立要求信号にODI記述部分が存在するのは、AS3からのCSCF接続処理による呼確立要求信号である。
【００６９】
1-3 セッション制御部14は、信号AのODI記述部分の有無に応じてサービス状態情報を生成する。ここでは、1-2で信号AにはODI記述部分が無いと判定されているため、サービス状態情報は、信号Aの内容およびセッション制御部14が保持しているサービス対象ユーザの状態に基づいて生成される。
【００７０】
具体的には、サービス対象ユーザのAS接続処理要否判定の発着種別は、信号Aが端末装置4からの呼確立要求信号であることから「発」となる。サービス対象ユーザの識別子は、発着種別が「発」となることから、信号Aの発信元アドレスで示されるユーザの識別子となる。サービス対象ユーザのREGISTER状態は、セッション制御部14が保持しているサービス対象ユーザの状態から取得される。サービス対象ユーザのAS接続処理要否判定の進捗状況は、1-2で信号AにODI記述部分が存在しないと判定していることから、初期状態となる。
【００７１】
1-4 セッション制御部14は、AS接続処理要否判定部 15に対して、信号Aに記述されている発信元アドレス、着信先アドレス、サービス要求内容の他に、1-3で生成したサービス状態情報を送出し、AS接続処理判定を要求する。
【００７２】
1-5 AS接続処理判定要求を受けたAS接続処理要否判定部15は、サービス状態情報に含まれるサービス対象ユーザの識別子を用いて、サービス契約情報蓄積部11に対してサービス対象ユーザのサービス契約情報を要求する。
【００７３】
1-6 AS接続処理要否判定部15は、要求したサービス契約情報を取得する。
【００７４】
1-7 AS接続処理要否判定部15は、iFC蓄積部12に対して、1-6で取得したサービス契約情報を用いて、サービス対象ユーザについて判定対象となる全てのiFCを要求する。
【００７５】
1-8 AS接続処理要否判定部15は、要求したiFCを取得する。さらにAS接続処理要否判定部15は、取得した全iFCに設定されている優先度、および発着種別を確認する。
【００７６】
1-9 AS接続処理要否判定部15は、1-4で受け取ったサービス状態情報に含まれるサービス対象ユーザのAS接続処理要否判定の発着種別、およびサービス対象ユーザのAS接続処理要否判定の進捗状況と、1-8で取得した各iFCの優先度とから、次判定対象iFCを選択する。この場合、1-4でAS接続処理要否判定部15に渡されたサービス対象ユーザのAS接続処理要否判定の進捗状況は「初期状態」で、サービス対象ユーザのAS接続処理要否判定の発着種別が「発」となっている。このため、次判定対象iFCは、サービス対象ユーザが契約しているサービスに対応する、1-8で取得した全iFCのうち、最も優先度の高い発サービス用iFCが選択される。
【００７７】
1-10 AS接続処理要否判定部15は、iFC判定処理を行う。すなわち、1-9で選択した次判定対象iFCが、1-4で受信した発信元アドレス、着信先アドレス、サービス要求内容に合致するかを判定する。合致する場合は、1-2で信号AにはODI記述部分は存在しないと判定しているので、図４の1-11の処理に進む。合致しない場合は1-9に戻って当該判定済iFCの次の優先度のiFCを次判定対象iFCとして選択し、1-10でiFC判定処理を行う処理を繰り返す。全発サービス用iFCが合致せず、iFC判定処理が完了した場合は、図４の1-20の処理に進む。
【００７８】
＜1-10のiFC判定処理でいずれかのiFCが合致した場合＞
1-11 AS接続処理要否判定部15は、1-10で合致したiFCに記載された接続先AS情報を、セッション制御部14に送出する。
【００７９】
1-12 セッション制御部14は、1-2で信号AのODI記述部分は存在しないと判定しているため、後述の1-21で呼確立要求信号のODI記述部分を設定するために、ODI管理部 16に対してODIの払い出し要求を行う。
【００８０】
1-13 ODI管理部16は、ODIを一意に識別可能な値として生成し、生成したODIを払い出し済みODIとして記憶し、次回以降に重複した値のODIを生成しないようにする。
【００８１】
1-14 ODI管理部16は、生成されたODIをセッション制御部14に送出する。
【００８２】
1-15 セッション制御部14は、1-14で取得したODIとサービス状態情報とを、ODI記述部分に記載したAS接続処理用の呼確立要求信号を生成する。そして、呼確立要求信号と接続先AS情報とをSIP信号制御部13に送出する。
【００８３】
1-16 SIP信号制御部13は、接続先AS情報に従い、AS接続処理を実施する。
【００８４】
＜1-10のiFC判定処理で全iFCが合致しない場合＞
1-20 1-10で全iFCが合致せずにiFC判定処理が完了した場合、セッション制御部14は、AS接続処理要否判定部15から判定完了後の発信元アドレス、着信先アドレス、サービス要求内容等を受け取り、それらに従った呼確立要求信号を生成する。
【００８５】
1-21 SIP信号制御部13は、1-20で生成した呼確立要求信号に従い、呼接続処理を実施する。
【００８６】
以上の処理が、端末装置4から呼確立要求信号を受信した場合の処理である。
【００８７】
次に、図４の1-16で実施したAS3へのAS接続処理の後、AS3からCSCF接続処理として送信された呼確立要求信号をCSCF-A1が受信した場合の処理について、図３および図４を用いて説明する。ここでは、図３および図４に記載した処理順番を示す番号に「2-」を付加して以下に記述する。
【００８８】
2-1 SIP信号制御部13およびセッション制御部14は、AS3から送信されてきた呼確立要求信号を受信する。
【００８９】
2-2 セッション制御部14は、受信した呼確立要求信号（以下、「信号A」と称する）のODI記述部分の存在有無を判定する。ここではODI記述部分が存在するものとする。なお、AS3のCSCF接続処理により受信する呼確立要求信号には、ODI記述部分が存在する。
【００９０】
2-3 セッション制御部14は、信号AのODI記述部分の有無に応じてサービス状態情報を生成する。ここでは、2-2で信号AにはODI記述部分が有ると判定されているため、サービス状態情報は、信号Aの内容を用いて生成される。
【００９１】
具体的には、サービス状態情報のサービス対象ユーザの識別子、サービス対象ユーザのREGISTER状態、サービス対象ユーザのAS接続処理要否判定の発着種別、サービス対象ユーザのAS接続処理要否判定の進捗状況は、信号AのODI記述部分にサービス状態情報として含まれる値となる。この場合、サービス対象ユーザのAS接続処理要否判定の発着種別は「発」となる。
【００９２】
2-4 セッション制御部14は、AS接続処理要否判定部15に対して、信号Aに記述されている発信元アドレス、着信先アドレス、サービス要求内容の他に、2-3で生成したサービス状態情報を送出し、AS接続処理判定を要求する。
【００９３】
2-5 2-4でAS接続処理判定要求を受けたAS接続処理要否判定部15は、サービス状態情報に含まれるサービス対象ユーザの識別子を用いて、サービス契約情報蓄積部11に対してサービス対象ユーザのサービス契約情報を要求する。
【００９４】
2-6 AS接続処理要否判定部15は、要求したサービス契約情報を取得する。
【００９５】
2-7 AS接続処理要否判定部15は、iFC蓄積部12に対して、2-6で取得したサービ契約情報を用いて、サービス対象ユーザについて判定対象となる全てのiFCを要求する。
【００９６】
2-8 AS接続処理要否判定部15は、要求したiFCを取得する。さらにAS接続処理要否判定部15は、取得した全iFCに設定されている優先度、および発着種別を確認する。
【００９７】
2-9 AS接続処理要否判定部15は、2-4で受け取ったサービス状態情報に含まれるサービス対象ユーザのAS接続処理要否判定の発着種別、およびサービス対象ユーザのAS接続処理要否判定の進捗状況と、2-8で取得した各iFCの優先度とから、次判定対象iFCを選択する。この場合、2-4でAS接続処理要否判定部15に送出されたサービス対象ユーザのAS接続処理要否判定の進捗状況とAS接続処理要否判定の発着種別とは信号Aから取得した値が渡されている。このため、次判定対象iFCは、サービス対象ユーザが契約しているサービスに対応する2-8で取得した全iFCのうち、上記発着種別に対応したiFCであって、上記進捗状況に記載されたiFCの優先度の次に最も高い優先度の発サービス用iFCが選択される。
【００９８】
2-10 AS接続処理要否判定部15は、iFC判定処理を行う。すなわち、2-9で選択した次判定対象iFCが、2-4で受信した発信元アドレス、着信先アドレス、サービス要求内容に合致するかを判定する。合致する場合は、2-2で信号AにはODI記述部分があると判定しているので図４の2-17の処理に進む。合致しない場合は2-9に戻って当該判定済みiFCの次の優先度のiFCを次判定対象iFCとして選択し、2-10でiFC判定処理を行う処理を繰り返す。全iFCが合致せず、iFC判定処理が完了した場合には、図４の2-20の処理に進む。
【００９９】
＜2-10のiFC判定処理でいずれかのiFCが合致した場合＞
2-17 AS接続処理要否判定部15は、2-10で合致したiFCに記載された接続先AS情報を、セッション制御部14に送出する。
【０１００】
2-18 セッション制御部14は、2-2で信号AのODI記述部分はあると判定しているため、信号Aに記載されているODI記述部分を、そのままODI記述部分に記載したAS接続処理用の呼確立要求信号を生成する。そして、呼確立要求信号と接続先AS情報とをSIP信号制御部13に送出する。
【０１０１】
2-19 SIP信号制御部13は、接続先AS情報に従い、AS接続処理を実施する。
【０１０２】
＜2-10のiFC判定処理で全iFCが合致しない場合＞
2-20 2-10で全iFCが合致せずにiFC判定処理が完了した場合、セッション制御部14は、AS接続処理要否判定部15から判定完了後の発信元アドレス、着信先アドレス、サービス要求内容等を受け取り、それらに従った呼確立要求信号を生成する。
【０１０３】
2-21 SIP信号制御部13は、2-20で生成した呼確立要求信号に従い、呼接続処理を実施する。
【０１０４】
以上の処理が、AS3からCSCF接続処理として呼確立要求信号を受信し、サービス対象ユーザのAS接続処理要否判定の発着種別が「発」の場合の処理である。
【０１０５】
次に、上記2-21で実施した呼接続処理の結果、着信ユーザを収容した他のCSCF-A1が呼確立要求信号を受信した場合の処理を図３および図４を用いて説明する。ここでは、図３および図４に記載した処理順番を示す番号に「3-」を付加して以下に記述する。
【０１０６】
3-1 着側CSCF-A1のSIP信号制御部13およびセッション制御部14は、発側CSCF-A1から送信されてきた呼確立要求信号を受信する。
【０１０７】
3-2 セッション制御部14は、受信した呼確立要求信号（以下、「信号A」と称する）のODI記述部分の存在有無を判定する。ここではODI記述部分が存在しないものとする。なお、呼確立要求信号にODI記述部分が存在するのは、AS3からのCSCF接続処理で受信する呼確立要求信号であり、発側CSCF-A1から送信されてくる呼確立要求信号にはODI記述部分は存在しない。
【０１０８】
3-3 セッション制御部14は、信号AのODI記述部分の有無に応じてサービス状態情報を生成する。ここでは、3-2で信号AにはODI記述部分が無いと判定されているため、サービス状態情報は、信号Aの内容、およびセッション制御部14が保持しているサービス対象ユーザの状態により生成される。
【０１０９】
具体的には、サービス状態情報のサービス対象ユーザのAS接続処理要否判定の発着種別は、信号Aが発側CSFC-A1からの呼確立要求信号であることから「着」となる。サービス対象ユーザの識別子は、発着種別が「着」となることから、信号Aの着信先アドレスで示されるユーザの識別子となる。サービス対象ユーザのREGISTER状態は、セッション制御部14が保持しているサービス対象ユーザの状態より取得される。サービス対象ユーザのAS接続処理要否判定の進捗状況は、3-2にて信号AにODI記述部分が存在しないと判定していることから、「初期状態」となる。
【０１１０】
3-4 セッション制御部14は、AS接続処理要否判定部 15に対して、信号Aに記述されている発信元アドレス、着信先アドレス、サービス要求内容の他に、3-3で生成したサービス状態情報を送出し、AS接続処理判定を要求する。
【０１１１】
3-5 3-4でAS接続処理判定要求を受け取ったAS接続処理要否判定部15は、サービス状態情報に含まれるサービス対象ユーザの識別子を用いて、サービス契約情報蓄積部11に対してサービス対象ユーザのサービス契約情報を要求する。
【０１１２】
3-6 AS接続処理要否判定部15は、要求したサービス契約情報を取得する。
【０１１３】
3-7 AS接続処理要否判定部15は、iFC蓄積部12に対して3-6で取得したサービス契約情報を用いて、サービス対象ユーザについて判定対象となる全てのiFCを要求する。
【０１１４】
3-8 AS接続処理要否判定部15は、要求したiFCを取得する。さらに、AS接続処理要否判定部15は、取得した全iFCに設定されている優先度、および発着種別を確認する。
【０１１５】
3-9 AS接続処理要否判定部15は、3-4で受け取ったサービス状態情報に含まれるサービス対象ユーザのAS接続処理要否判定の発着種別、およびサービス対象ユーザのAS接続処理要否判定の進捗状況と、3-8で取得した各iFCの優先度とから、次判定対象iFCを選択する。この場合、3-4でAS接続処理要否判定部15に渡されたサービス対象ユーザのAS接続処理要否判定の進捗状況は「初期状態」で、サービス対象ユーザのAS接続処理要否判定の発着種別が「着」となっている。このため、次判定対象iFCは、サービス対象ユーザが契約しているサービスに対応する、3-8で取得した全iFCのうち、最も優先度の高い着サービス用iFCが選択される。
【０１１６】
3-10 AS接続処理要否判定部15は、iFC判定処理を行う。すなわち、3-9で選択した次判定対象iFCが、3-4で受信した発信元アドレス、着信先アドレス、サービス要求内容に合致するかを判定する。合致する場合は、3-2で信号AにはODI記述部分は存在しないと判定しているので、図４の3-11の処理に進む。合致しない場合は3-9に戻って当該判定済iFCの次の優先度のiFCを次判定対象iFCとして選択し、3-10でiFC判定処理を行う処理を繰り返す。全着サービス用iFCが合致せず、iFC判定処理が完了した場合には、図４の3-20の処理に進む。
【０１１７】
＜3-10のiFC判定処理でいずれかのiFCが合致した場合＞
3-11 3-10で合致したiFCに記載された接続先AS情報を、AS接続処理要否判定部15からセッション制御部14に送出する。
【０１１８】
3-12 セッション制御部14は、3-2で信号AのODI記述部分は存在しないと判定しているため、後述の3-21で呼確立要求信号のODI記述部分を設定するために、ODI管理部 16に対してODIの払い出し要求を行う。
【０１１９】
3-13 ODI管理部16は、ODIを一意に識別可能な値として生成し、生成したODIを払い出し済みODIとして記憶し、次回以降に重複した値のODIを生成しないようにする。
【０１２０】
3-14 ODI管理部16は、生成したODIをセッション制御部14に送出する。
【０１２１】
3-15 セッション制御部14は、3-14で取得したODIとサービス状態情報とを、ODI記述部分に記載したAS接続処理用の呼確立要求信号を生成する。そして、呼確立要求信号と接続先AS情報とをSIP信号制御部13に送出する。
【０１２２】
3-16 SIP信号制御部13は、接続先AS情報に従い、AS接続処理を実施する。
【０１２３】
＜3-10のiFC判定処理で全iFCが合致しない場合＞
3-20 3-10で全iFCが合致せずにiFC判定処理が完了した場合、セッション制御部14は、AS接続処理要否判定部15から判定完了後の発信元アドレス、着信先アドレス、サービス要求内容等を受け取り、それらに従った呼確立要求信号を生成する。
【０１２４】
3-21 SIP信号制御部13は、3-20で生成した呼確立要求信号に従い、呼接続処理を実施する。
【０１２５】
以上の処理が、発CSCF-A1から呼確立要求信号を受信した場合の処理である。
【０１２６】
次に、図４の上記3-16で実施した着サービス用iFCのAS3へのAS接続処理の後、AS3からCSCF接続処理として送信された呼確立要求信号を着側CSCF-A1が受信した場合の処理について、図３および図４を用いて説明する。ここでは、図３および図４に記載した処理順番を示す番号の先頭に「4-」を付加して以下に記述する。
【０１２７】
4-1 着側CSCF-A1のSIP信号制御部13およびセッション制御部14は、AS3から送信されてきた呼確立要求信号を受信する。
【０１２８】
4-2 セッション制御部14は、受信した呼確立要求信号（以下、「信号A」と称する）のODI記述部分の存在有無を判定する。ここでは、ODI記述部分が存在するものとする。なお、AS3からCSCF接続処理で受信する呼確立要求信号には、ODI記述部分が存在する。
【０１２９】
4-3 セッション制御部14は、信号AのODI記述部分有無に応じてサービス状態情報を生成する。この場合、4-2で信号AにはODI記述部分があると判定されているため、サービス状態情報は信号Aの内容により生成される。
【０１３０】
具体的には、サービス状態情報のサービス対象ユーザの識別子、サービス対象ユーザのREGISTER状態、サービス対象ユーザのAS接続処理要否判定の発着種別、サービス対象ユーザのAS接続処理要否判定の進捗状況は、信号AのODI記述部分にサービス状態情報として含まれる値となる。この場合、サービス対象ユーザのAS接続処理要否判定の発着種別は「着」となる。
【０１３１】
4-4 セッション制御部14は、AS接続処理要否判定部 15に対して、信号Aに記述されている発信元アドレス、着信先アドレス、サービス要求内容の他に、4-3で生成したサービス状態情報を送出し、AS接続処理判定を要求する。
【０１３２】
4-5 4-4でAS接続処理判定要求を受けたAS接続処理要否判定部15は、サービス状態情報に含まれるサービス対象ユーザの識別子を用いて、サービス契約情報蓄積部11に対してサービス対象ユーザのサービス契約情報を要求する。
【０１３３】
4-6 AS接続処理要否判定部15は、要求したサービス契約情報を取得する。
【０１３４】
4-7 AS接続処理要否判定部15は、iFC蓄積部12に対して4-6で取得したサービス契約情報を用いて、サービス対象ユーザについて判定対象となる全てのiFCを要求する。
【０１３５】
4-8 AS接続処理要否判定部15は、要求したiFCを取得する。さらにAS接続処理要否判定部15は、取得した全iFCに設定されている優先度、および発着種別を確認する。
【０１３６】
4-9 AS接続処理要否判定部15は、4-4で取得したサービス状態情報に含まれるサービス対象ユーザのAS接続処理要否判定の発着種別、およびサービス対象ユーザのAS接続処理要否判定の進捗状況と、4-8で取得した各iFCの優先度とから、次判定対象iFCを選択する。この場合、4-4でAS接続処理要否判定部15に送出されたサービス対象ユーザのAS接続処理要否判定の進捗状況とAS接続処理要否判定の発着種別とは信号Aから取得した値が渡されている。このため、次判定対象iFCは、サービス対象ユーザが契約しているサービスに対応する4-8で取得した全iFCのうち、上記発着種別に対応したiFCであって、上記進捗状況に記載されたiFCの優先度の次に最も優先度の高い着サービス用iFCが選択される。
【０１３７】
4-10 AS接続処理要否判定部15は、iFC判定処理を行う。すなわち、4-9で選択した次判定対象iFCに、4-4で受信した発信元アドレス、着信先アドレス、サービス要求内容に合致するかを判定する。合致する場合は、4-2で信号AにはODI記述部分があると判定しているので図４の4-17の処理に進む。合致しない場合は4-9に戻って判定済みiFCの次の優先度のiFCを次判定対象iFCとして選択し、4-10でiFC判定処理を行う処理を繰り返す。全iFCが合致せず、iFC判定処理が完了した場合には、図４の4-20の処理に進む。
【０１３８】
＜4-10のiFC判定処理でいずれかのiFCが合致した場合＞
4-17 AS接続処理要否判定部15は、4-10で合致したiFCに記載された接続先AS情報を、セッション制御部14に送出する。
【０１３９】
4-18 セッション制御部14は、4-2で信号AのODI記述部分はあると判定しているため、信号Aに記載されていたODI記述部分を、そのままODI記述部分に記載したAS接続処理要の呼確立要求信号を生成する。そして、呼確立要求信号と接続先AS情報とをSIP信号制御部13に送出する。
【０１４０】
4-19 SIP信号制御部13は、接続先AS情報に従い、AS接続処理を実施する。
【０１４１】
＜4-10のiFC判定処理で全iFCが合致しない場合＞
4-20 4-10で全iFCが合致せずにiFC判定処理が完了した場合、セッション制御部14は、AS接続処理要否判定部15から判定完了後の発信元アドレス、着信先アドレス、サービス要求内容等を受け取り、それらに従った呼確立要求信号を生成する。
【０１４２】
4-21 SIP信号制御部13は、4-20で生成した呼確立要求信号に従い、呼接続処理を実施する。
【０１４３】
以上説明した本実施形態では、CSCFはAS接続処理を行う際に、呼確立要求信号にサービス状態情報を含めてASに送信し、ASは受信した呼確立要求信号に含まれるサービス状態情報をCSCF接続処理を行う際の呼確立要求信号に透過的に設定してCSCFに送信し、CSCFはASから受信した呼確立要求信号に含まれるサービス状態情報を抽出し解析することにより当該呼のサービス状態情報を取得できるようにする。
【０１４４】
これにより、CSCF接続処理によりASから呼確立要求信号を受信したCSCFが、正常に処理を継続するのに必要なサービス状態情報は、受信した呼確立要求信号に含まれているため、サービス状態情報を記録する記憶領域を削減することができる。すなわち、従来技術でサービス状態情報を記録するために必要とされていた、CSCFの記憶領域を削減することができる。これにより、ODIが同時に多数払いだされるような利用形態のCSCFであっても、より少ない記憶容量（ハードウェア）で、CSCFとAS間の呼確立要求信号のISCインタフェースを実現することができる。また、サービス状態情報用の記憶容量が削減されることから、削減された分をユーザ収容データ用の記憶領域として用いることができる。
【０１４５】
また、本実施形態では、サービス状態情報は呼確立要求信号に含まれて送受信されるため、サービス状態情報の取得のために記憶領域へアクセスする回数を削減することができる。すなわち、サービス状態情報の取得処理がCSCFの性能ボトルネックとなる事態を回避することができる。
【０１４６】
また、本実施形態では、ASからCSCFが受信した呼確立要求信号の内容とCSCFが保持するサービス状態情報の突合処理が不要となる。
【０１４７】
なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【０１４８】
例えば、上記実施形態では、呼確立要求信号中にサービス状態情報が含まれる箇所は、呼確立要求信号のODI記述部分であるものとして説明したが、呼確立要求信号中の他の部分にサービス状態情報を含めることとしてもよい。
【０１４９】
また、上記実施形態では、サービス状態情報の全部を、呼確立要求信号中に含めて送信することとしたが、サービス状態情報の一部を呼確立要求信号中に含めて送信することとしてもよい。この場合、呼確立要求信号中に含めないサービス状態情報については従来技術と同様にCSCFの記憶領域へ記録を行い、呼確立要求信号中に含めたサービス状態情報については記憶領域への記録を行わないことで、サービス状態情報の記録に必要な記憶領域を低減することができる。
【０１５０】
また、本発明は、以下に示す変形例の1つあるいは複数を適用することとしてもよい。
【０１５１】
(1)図４の15あるいは18において、呼確立要求信号のODI記述部分を生成する際、ODIとサービス状態情報とを用いてODI記述部分を生成するのではなく、サービス状態情報のみを用いてODI記述部分を生成することとしてもよい。
【０１５２】
(2)上記(1)に併せて、ODI管理部 16を使用せず、図４の12〜14のODIの払い出し処理・取得を行わないこととしてもよい。
【０１５３】
(3)図４の15あるいは18において、呼確立要求信号のODI記述部分にサービス状態情報を含める際、サービス状態情報そのものではなく、予め定めたサービス状態情報相当の符号を含めることとしてもよい。符号は、図３の3でサービス状態情報をして復元される。
【符号の説明】
【０１５４】
１ ：ＣＳＣＦ−Ａ
１１：サービス契約情報蓄積部
１２：iFC蓄積部
１３：SIP信号制御部
１４：セッション制御部
１５：AS接続処理要否判定部
１６：ODI管理部
３ ：AS
４ ：端末装置
【特許請求の範囲】
【請求項１】
呼制御サーバとアプリケーションサーバ間の呼確立要求信号の流通インタフェースにおける呼制御方法であって、
前記呼制御サーバは、
サービス状態情報を含む第１の呼確立要求信号を生成し、当該第１の呼確立要求信号を送信して前記アプリケーションサーバに接続する第１の接続ステップを行い、
前記アプリケーションサーバは、
前記呼制御サーバから受信した前記第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成し、当該第２の呼確立要求信号を送信して前記呼制御サーバに接続する第２の接続ステップを行い、
前記呼制御サーバは、
前記アプリケーションサーバから受信した前記第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定ステップと、を行うこと
を特徴とする呼制御方法。
【請求項２】
呼制御サーバと、アプリケーションサーバとを有する呼制御システムであって、
前記呼制御サーバは、
サービス状態情報を含む第１の呼確立要求信号を生成する生成手段と、
前記第１の呼確立要求信号を送信して前記アプリケーションサーバに接続する接続手段と、
前記アプリケーションサーバから受信した第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定手段と、を有し、
前記アプリケーションサーバは、
前記呼制御サーバから受信した前記第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成する生成手段と、
前記第２の呼確立要求信号を送信して前記呼制御サーバに接続する接続手段と、を有すること
を特徴とする呼制御システム。
【請求項１】
呼制御サーバとアプリケーションサーバ間の呼確立要求信号の流通インタフェースにおける呼制御方法であって、
前記呼制御サーバは、
サービス状態情報を含む第１の呼確立要求信号を生成し、当該第１の呼確立要求信号を送信して前記アプリケーションサーバに接続する第１の接続ステップを行い、
前記アプリケーションサーバは、
前記呼制御サーバから受信した前記第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成し、当該第２の呼確立要求信号を送信して前記呼制御サーバに接続する第２の接続ステップを行い、
前記呼制御サーバは、
前記アプリケーションサーバから受信した前記第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定ステップと、を行うこと
を特徴とする呼制御方法。
【請求項２】
呼制御サーバと、アプリケーションサーバとを有する呼制御システムであって、
前記呼制御サーバは、
サービス状態情報を含む第１の呼確立要求信号を生成する生成手段と、
前記第１の呼確立要求信号を送信して前記アプリケーションサーバに接続する接続手段と、
前記アプリケーションサーバから受信した第２の呼確立要求信号に含まれるサービス状態情報を抽出し、当該サービス状態情報を用いてアプリケーションサーバへの接続要否を判定する判定手段と、を有し、
前記アプリケーションサーバは、
前記呼制御サーバから受信した前記第１の呼確立要求信号に含まれるサービス状態情報を設定した第２の呼確立要求信号を生成する生成手段と、
前記第２の呼確立要求信号を送信して前記呼制御サーバに接続する接続手段と、を有すること
を特徴とする呼制御システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１２−１７５３５５（Ｐ２０１２−１７５３５５Ａ）
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願番号】特願２０１１−３４７８１（Ｐ２０１１−３４７８１）
【出願日】平成２３年２月２１日（２０１１．２．２１）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年９月１０日（２０１２．９．１０）
【国際特許分類】
【出願日】平成２３年２月２１日（２０１１．２．２１）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]