(57)【要約】      （修正有）【課題】セッション制御において、アプリケーション・サーバで不必要な信号転送処理が行われないようにして処理負荷を軽減し、かつネットワークのスループット向上を図る。【解決手段】Ｓ−ＣＳＣＦ（２−Ｂ）の加入者情報記憶部に、アプリケーション・サーバＡＳＶ１，ＡＳＶ２に対する接続条件を予め記憶しておく。そして、Ｓ−ＣＳＣＦ（２−Ｂ）が加入者端末ＵＥ−Ａ，ＵＥ−Ｂ間のセッションを制御する際に、Ｓ−ＣＳＣＦ（２−Ｂ）の加入者情報記憶部に格納されている加入者に対応する情報をもとに、アプリケーション・サーバＡＳＶ１，ＡＳＶ２に対するセッション制御信号の送受信の要否を判定し、この判定の結果送受信が必要と判定された場合にのみアプリケーション・サーバＡＳＶ１，ＡＳＶ２との間でセッション制御信号を送受信する。【選択図】図１
2011041192.tif 000002
【特許請求の範囲】
【請求項１】
ＩＭＳ（IP Multimedia Subsystem）を用いたネットワークに設けられ、加入者端末間でアプリケーション・サーバを介してセッション制御を行うセッション制御装置において、
サービスごとに前記アプリケーション・サーバに対するセッション制御信号の送受信条件を表す拡張情報を含むフィルタ情報を記憶するフィルタ情報記憶手段と、
前記加入者端末間のセッション制御時に、当該加入者端末が利用するサービスに対応する前記記憶されたフィルタ情報に含まれる拡張情報をもとに、前記アプリケーション・サーバに対するセッション制御信号の送受信の要否を判定する判定手段と、
前記判定の結果に基づいて、前記アプリケーション・サーバとの間のセッション制御信号の送受信を制御する送受信制御手段と
を具備することを特徴とするセッション制御装置。
【請求項２】
発信元の加入者端末から送信されるセッション確立要求に応じてセッション制御経路を表すルート情報を構築する際に、前記アプリケーション・サーバの識別情報を前記ルート情報に記録しないように制御する手段を、さらに具備することを特徴とする請求項１記載のセッション制御装置。
【請求項３】
前記フィルタ情報記憶手段は、前記フィルタ情報の拡張情報として、「常時」、「セッション確立前」、「セッション確立後」のいずれかを指定する情報を記憶し、
前記送受信制御手段は、前記記憶されたフィルタ情報に含まれる拡張情報に基づく判定結果に応じ、当該拡張情報が「常時」の場合にはアプリケーション・サーバとの間のセッション制御信号の送受信を常時行い、前記拡張情報が「セッション確立前」及び「セッション確立後」の場合にはそれぞれセッション確立前及びセッション確立後の期間のみアプリケーション・サーバとの間でセッション制御信号を送受信する
ことを特徴とする請求項１又は２記載のセッション制御装置。
【請求項４】
ＩＭＳ（IP Multimedia Subsystem）を用いたネットワークに設けられるセッション制御装置において、加入者端末間でアプリケーション・サーバを介してセッション制御を行うセッション制御方法であって、
サービスごとに前記アプリケーション・サーバに対するセッション制御信号の送受信条件を表す拡張情報を含むフィルタ情報を記憶媒体に記憶する過程と、
前記加入者端末間のセッションを制御する際に、当該加入者端末が利用するサービスに対応するフィルタ情報を前記記憶媒体から読み出して、この読み出されたフィルタ情報に含まれる拡張情報をもとに、前記アプリケーション・サーバに対するセッション制御信号の送受信の要否を判定し、この判定の結果に基づいて前記アプリケーション・サーバとの間のセッション制御信号の送受信を制御する過程と
を具備することを特徴とするセッション制御方法。
【請求項５】
発信元の加入者端末から送信されるセッション確立要求に応じてセッション制御経路を表すルート情報を構築する際に、前記アプリケーション・サーバの識別情報を前記ルート情報に記録しないように制御する過程を、さらに具備することを特徴とする請求項４記載のセッション制御方法。
【請求項６】
前記フィルタ情報を記憶する過程は、前記フィルタ情報の拡張情報として、「常時」、「セッション確立前」、「セッション確立後」のいずれかを指定する情報を記憶し、
前記制御する過程は、前記記憶されたフィルタ情報に含まれる拡張情報に基づく判定結果に応じ、当該拡張情報が「常時」の場合にはアプリケーション・サーバとの間のセッション制御信号の送受信を常時行い、前記拡張情報が「セッション確立前」及び「セッション確立後」の場合にはそれぞれセッション確立前及びセッション確立後の期間のみアプリケーション・サーバとの間でセッション制御信号を送受信する
ことを特徴とする請求項４又は５記載のセッション制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＩＭＳ（IP Multimedia Subsystem）において端末間のセッション制御を行うセッション制御装置及び方法に関する。
【背景技術】
【０００２】
ITU-T等で議論している次世代ネットワーク（ＮＧＮ：Next Generation Network）は、サービスがＩＰ（Internet Protocol）ネットワークを経て提供されるネットワークアーキテクチャを想定している。ＮＧＮでは第三世代の移動通信ネットワークの標準化団体である3GPP（3rd Generation Partnership Project）で策定されたＩＭＳの採用を決めており、このＩＭＳを用いたネットワークサービスが提供されている。ＩＭＳはプロトコルとしてSIP （Session Initiation Protocol）を用いることで、サービスの実行制御、端末間のセッション制御、登録処理及び課金処理等を行うサブシステムである。ＩＭＳでは、SIP を用いたアプリケーション・サーバ（ＡＳ：Application Server）を利用することで様々なアプリケーションを実行することが可能となる。アプリケーション・サーバを利用することで、ＩＭＳは単なる二者間でのマルチメディア・セッションの確立だけでなく、拡張したサービスを実現することができる。アプリケーション・サーバを利用することで実現されるサービスとしては、ＣＡＴ（Customized Alerting Tone）サービスや保留サービス等が知られている（例えば、非特許文献１及び非特許文献２を参照。）。
【０００３】
ところで、発信側の端末と着信側の端末との間にアプリケーション・サーバを介してセッションを確立する場合、セッション制御サーバ（Ｓ−ＣＳＣＦ：Call Session Control Function）は、例えば図１０に示すようにアプリケーション・サーバＡＳＶ１，ＡＳＶ２を起点として、発信元の端末ＵＥ−Ａとの間と、着信先の端末ＵＥ−Ｂとの間に２つのフローを形成することでセッションを確立する。
【０００４】
図１１は、上記セッションの確立過程で構築されるルート情報、つまりRoute Set の一例を示すものである。発信元の端末ＵＥ−Ａから着信先の端末ＵＥ−Ｂとの間にセッションを確立する場合、当該端末ＵＥ−Ａ，ＵＥ−Ｂ間に介在する、各ノードの識別情報Ａ，Ｂ，Ｃ，１，Ｃ，Ｄが順に記録されることでRoute Set が生成される。このRoute Set は着信先の端末ＵＥ−Ｂから発信元の端末ＵＥ−Ａへ応答信号により通知され、以後発信元の端末ＵＥ−Ａと着信先の端末ＵＥ−Ｂとの間で転送されるセッション制御信号は、上記Route Set に従い転送される（例えば、非特許文献３乃至非特許文献６を参照。）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】3GPP TS 24.182 V8.2.0 (2009-06); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia Subsystem (IMS) Customized Alerting Tones (CAT); Protocol specification (Release 8); 4章等, Jun.2009
【非特許文献２】3GPP TS 24.610 V8.3.0 (2009 03); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Communication HOLD (HOLD) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification (Release 8); 4章等, Mar.2009
【非特許文献３】3GPP TS 23.228, V8.9.0 (2009-06); 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 8); 4.2.4章, 24頁, Jun.2009
【非特許文献４】3GPP TS 24.229, V8.8.0 (2009-06); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 8); 5.4.3.2章, 66頁, Jun.2009
【非特許文献５】3GPP TS 23.218, V8.4.0 (2008-12); 3rd Generation Partnership Project; Technical Specification Group 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) session handling; IM call model; Stage 2 (Release 8); 5.2.1〜5.2.3章, 12〜13頁, Dec.2008
【非特許文献６】3GPP TS 29.228, V8.5.0 (2009-03); 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents (Release 8); Annex B (informative): 2.2章，2.3章, 52〜54頁 Mar.2009
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところが、上記した従来のセッション制御方法では、セッション制御処理の開始から終了までの全期間にわたり、アプリケーション・サーバが常時介在する状態でセッション制御信号の転送制御が行われる。このため、実際のサービスの実行中にアプリケーション・サーバを介在させる必要がなくなっても、例えば図１２に示すようにセッション制御信号は常にアプリケーション・サーバＡＳＶ１を経由することになる。この結果、アプリケーション・サーバＡＳＶ１にとっては、不必要なセッション制御信号の送受信処理のために無駄な負荷がかかるという問題があった。
【０００７】
さらに、例えば図１３に示すように転送経路に介在するアプリケーション・サーバＡＳＶ１，ＡＳＶ２，ＡＳＶ３，…の数が多くなると、Route set の情報量増加によるセッション制御信号のデータサイズの大型化と、SIP のホップ数の増加により、ネットワークのスループットの低下を招く心配もあった。
【０００８】
この発明は上記事情に着目してなされたもので、その目的とするところは、セッション制御時において、アプリケーション・サーバで不必要な信号転送処理が行われないようにしてアプリケーション・サーバの処理負荷を軽減とネットワークにおけるスループットの向上を可能にしたセッション制御装置及び方法を提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するためにこの発明の一つの観点は、ＩＭＳ（IP Multimedia Subsystem）を用いたネットワークに設けられ、加入者端末間でアプリケーション・サーバを介してセッション制御を行うセッション制御装置にあって、サービスごとに上記アプリケーション・サーバに対するセッション制御信号の送受信条件を表す拡張情報を含むフィルタ情報をフィルタ情報記憶手段に記憶しておく。そして、上記加入者端末間のセッション制御時に、当該加入者端末が利用するサービスに対応する上記記憶されたフィルタ情報に含まれる拡張情報をもとに、上記アプリケーション・サーバに対するセッション制御信号の送受信の要否を判定し、この判定の結果に基づいてアプリケーション・サーバとの間のセッション制御信号の送受信を制御するようにしたものである。
【００１０】
したがって、アプリケーション・サーバに対するセッション制御信号の送受信条件を表す拡張情報をフィルタ情報に含めて予め記憶しておくことで、加入者端末間のセッション制御時に、上記記憶されたフィルタ情報に含まれる拡張情報をもとにアプリケーション・サーバに対するセッション制御信号の送受信の要否が判定され、この判定の結果に基づいてアプリケーション・サーバとの間のセッション制御信号の送受信が行われる。このため、アプリケーション・サーバとの間では、予め設定した条件を満たすときのみセッション制御信号の送受信が行われることになる。したがって、アプリケーション・サーバでは無駄なセッション制御信号の送受信が行われなくなり、これによりアプリケーション・サーバの処理負荷は軽減される。
【００１１】
また、この発明の一観点は以下のような具体的な態様を備えることも特徴とする。  
第１の態様は、発信元の加入者端末から送信されるセッション確立要求に応じてセッション制御経路を表すルート情報を構築する際に、アプリケーション・サーバの識別情報を上記ルート情報に記録しないように制御するものである。  
このようにすると、セッション確立要求時において構築されるルート情報にはアプリケーション・サーバの識別情報が記録されない。このため、セッション制御経路上にアプリケーション・サーバが存在することを加入者端末に対し隠蔽することが可能となる。また、アプリケーション・サーバの識別情報を記録しないようにすることでルート情報の情報サイズを小さくすることができ、これにより加入者端末が多数のアプリケーション・サーバのサービスを利用する場合でも、セッション制御信号のデータサイズを小型化することが可能となる。
【００１２】
第２の態様は、フィルタ情報の拡張情報として、「常時」、「セッション確立前」、「セッション確立後」のいずれかを指定する情報を記憶させる。そして、セッション制御を行う際に、上記記憶されたフィルタ情報に含まれる拡張情報に応じ、当該拡張情報が「常時」の場合にはアプリケーション・サーバとの間のセッション制御信号の送受信を常時行い、上記拡張情報が「セッション確立前」及び「セッション確立後」の場合にはそれぞれセッション確立前及びセッション確立後の期間のみアプリケーション・サーバとの間でセッション制御信号の送受信を行うように制御するものである。  
このようにすると、セッション制御信号の送受信条件として、「常時」、「セッション確立前」、「セッション確立後」の３種類の送受信許可期間を指定することができ、これにより簡単な条件によりアプリケーション・サーバとの間のセッション制御信号の送受信を制御することができる。
【発明の効果】
【００１３】
すなわち、この発明の一つの観点によれば、セッション制御時において、アプリケーション・サーバで不必要な信号転送処理が行われないようにしてアプリケーション・サーバの処理負荷を軽減とネットワークにおけるスループットの向上を可能にしたセッション制御装置及び方法を提供することができる。
【図面の簡単な説明】
【００１４】
【図１】この発明の一実施形態に係わるセッション制御機能（Ｓ−ＣＳＣＦ）を備えたＩＭＳネットワークシステムの概略構成図。
【図２】この発明の一実施形態に係わるセッション制御機能（Ｓ−ＣＳＣＦ）の構成を示すブロック図。
【図３】図２に示したセッション制御機能（Ｓ−ＣＳＣＦ）が加入者情報として保存するinitial Filter Criteriaの構成の一例を示す図。
【図４】図１に示したシステムにおけるＩＭＳ  ＣＡＴ発信時のシーケンスを示す図。
【図５】ＩＭＳ  ＣＡＴ発信時のシーケンスの従来例を示す図。
【図６】図１に示したシステムにおける保留サービス実行時のシーケンスを示す図。
【図７】保留サービス実行時のシーケンスの従来例を示す図。
【図８】図１に示したシステムにおいて生成されるセッションを構成するフローを示す図。
【図９】図１に示したシステムにおけるRoute setの構築動作を示す図。
【図１０】従来システムにおいて生成されるセッションを構成するフローを示す図。
【図１１】従来システムにおけるRoute setの構築動作を示す図。
【図１２】従来システムの課題を説明するための図。
【図１３】従来システムの課題を説明するための図。
【発明を実施するための形態】
【００１５】
以下、図面を参照してこの発明に係わる実施形態を説明する。  
図１は、この発明の一実施形態に係わるセッション制御機能を備えたネットワークシステムの概略構成図である。このネットワークシステムは、通信事業者が管理するＩＭＳ（IP Multimedia Subsystem）に基づくネットワークからなり、通信プロトコルとしてＳＩＰ（Session Initiation Protocol）を使用する。
【００１６】
ＩＭＳのネットワークＮＷは、複数のSIP サーバＳＳＶ−Ａ，ＳＳＶ−Ｂと、複数のアプリケーション・サーバ（ＡＳ）ＡＳＶ１，ＡＳＶ２と、加入者情報データベース（ＨＳＳ：Home Subscriber Server）ＤＢを備えている。
このうちSIP サーバＳＳＶ−Ａ，ＳＳＶ−Ｂはそれぞれ、Ｐ−ＣＳＣＦ（Proxy−Call Session Control Function）１−Ａ，１−Ｂと、Ｓ−ＣＳＣＦ（Serving−Call Session Control Function）２−Ａ，２−Ｂと、図示しないＩ−ＣＳＣＦ（Interrogating−Call Session Control Function）を有している。Ｐ−ＣＳＣＦ１−Ａ，１−Ｂは、プロキシサーバとして機能するもので、このＰ−ＣＳＣＦ１−Ａ，１−Ｂには携帯電話機やＰＤＡ（Personal Digital Assistant）、パーソナル・コンピュータ等の加入者端末ＵＥ−Ａ，ＵＥ−Ｂが接続される。
【００１７】
Ｓ−ＣＳＣＦ２−Ａ，２−Ｂは、セッション制御サーバとして機能するもので、加入者情報データベースＤＢに記憶された加入者情報に基づいて、加入者端末ＵＥ−Ａ，ＵＥ−Ｂ及びアプリケーション・サーバＡＳＶ１，ＡＳＶ２に対するSIPによるセッション確立や開放等のセッション制御処理を行う。
【００１８】
アプリケーション・サーバＡＳＶ１，ＡＳＶ２は、加入者に対し種々のサービスを提供するもので、上記Ｓ−ＣＳＣＦ２−Ａ，２−Ｂに対し接続される。付加サービスとしては、例えば発信元の加入者端末に対しＲＢＴ（Ring Back Tone）に代わり音楽データ等の特別な呼出音を提供するＣＡＴ（Customized Alerting Tone）サービスや、保留操作を行った加入者端末に対し保留音を提供する保留サービス、加入者端末から送信される通話音声データを記録する留守番電話サービス等がある。
【００１９】
ところで、上記Ｓ−ＣＳＣＦ２−Ａ，２−Ｂは以下のように構成される。図２はその機能構成を示すブロック図である。  
すなわち、Ｓ−ＣＳＣＦ２−Ａ，２−Ｂは、制御ユニット２１と、記憶ユニット２２と、SIP 送受信部２３を備えている。このうち先ずSIP 送受信部２３は、制御ユニット２１の制御の下で、Ｐ−ＣＳＣＦ１−Ａ，１−Ｂ、アプリケーション・サーバＡＳＶ１，ＡＳＶ２及び加入者情報データベースＤＢとの間でSIP 信号の送受信を行う。
【００２０】
記憶ユニット２２には、加入者情報記憶部２２１が設けられている。加入者情報記憶部２２１には、加入者情報の一つとしてinitial Filter Criteria４０が保存される。このinitial Filter Criteria４０は、加入者登録時に加入者情報データベース（ＨＳＳ）ＤＢからダウンロードされる。
【００２１】
initial Filter Criteria４０は、例えば図３に示すようにTrigger Point４１と、Application Server管理情報４２とを備える。Trigger Point４１は、複数のService Point Trigger４１１〜４４ｎを有している。各Service Point Trigger４１１〜４４ｎは、受信したセッション制御信号のヘッダ等に挿入された条件がいずれのサービス条件と一致するかを判定するもので、それぞれRequest-URI５１と、SIP Method５２と、SIP Header５３と、Session Case５４と、Session Description５５とを含んでいる。Request-URI５１は、SIP 信号の宛先を表す。SIP Method５２は、INVITE、OPTIONS、SUBSCRIBE等の対象となるSIP methodを表す。SIP Header５３は、検索対象となるSIP Headerの有無或いは部分／完全一致となる条件の有無を判定するために用いる。Session Case５４は、セッションの向き等の条件を表す。この条件としては、発信者宛の信号（在圏／圏外）、着信者宛の信号（在圏／圏外）、転送サービス後の発信者等の５つのパターンがある。Session Description５５は、セッション制御信号の本文（ｂｏｄｙ部）に記述されている内容との部分／完全一致となる条件の判定に用いる。
【００２２】
また、各Service Point Trigger４１１〜４１ｎには、この発明を実現するために必要な制御情報としてAS handling case within session５６が新たに記憶されている。AS handling case within session５６は、アプリケーション・サーバＡＳＶ１，ＡＳＶ２に対する接続条件を指定するもので、接続条件として「常時」と、「セッション確立前のみ」と、「セッション確立後のみ」の３種類の送受信許可期間のいずれかを指定する。
【００２３】
一方、Application Server管理情報４２は、アプリケーション・サーバＡＳＶ１，ＡＳＶ２に対し接続するために必要な情報を記憶したもので、上記各Service Point Trigger４１１〜４１ｎの中から受信セッション制御信号の条件と一致する条件を含むService Point Triggerが見つかった場合に読み出される。Application Server管理情報４２には、SIP URI６１と、Default handling６２と、Service Information６３が記憶されている。SIP URI６１は、接続先対象のアプリケーション・サーバの宛先を表す。Default handling６２は、アプリケーション・サーバに対しセッション制御信号が到達不能となった場合にどういう動作を実行するかを規定する。Service Information６３は、アプリケーション・サーバからセッション制御サーバＳＳＶ１に対して通知される内容の通知欄を表す。
【００２４】
また、Application Server管理情報４２にも、上記Service Point Trigger４１と同様にAS handling case within session６４が新たに記憶されている。このAS handling case within session６４は、上記Service Point Trigger４１に記憶されたAS handling case within session５６と同一の内容を有するもので、AS handling case within session５６の予備として使用される。  
なお、上記initial Filter Criteria４０の基本構成とその機能については、非特許文献４のAnnex B.2.2章、2.3章に詳しく述べられている。
【００２５】
制御ユニット１０は、この発明に係わる制御機能として、ルート情報構築部２１１と、ＡＳ送受信要否判定部２１２と、信号送受信制御部２１３とを備えている。これらの制御機能はいずれも、制御プログラムをＣＰＵ（Central Processing Unit）に実行させることにより実現される。
【００２６】
ルート情報構築部２１１は、発信元の加入者端末から送信されたセッション確立要求が受信された場合に、発信元の加入者端末から着信先の加入者端末までの信号転送経路を表すルート情報（Route set）に、アプリケーション・サーバＡＳＶ１，ＡＳＶ２の識別情報を記録せず、自己のセッション制御サーバＳＳＶ１の識別情報のみを記録する。すなわち、ルート情報からアプリケーション・サーバＡＳＶ１，ＡＳＶ２を隠蔽する処理を行う。
【００２７】
ＡＳ送受信要否判定部２１２は、加入者端末から送信されたセッション制御信号が受信された場合に、上記記憶ユニット２２の加入者情報記憶部２２１に保存されたinitial Filter Criteria４０を参照して、現在のセッション制御過程がAS handling case within session５６に記述された接続条件に該当するか否かを判定し、その判定結果をもとにアプリケーション・サーバＡＳＶ１，ＡＳＶ２に対するセッション制御信号の送受信の要否を判断する。
【００２８】
信号送受信制御部２１３は、上記ＡＳ送受信要否判定部２１２によるセッション制御信号の送受信の要否の判定結果に基づいて、送受信が必要と判断された場合にのみアプリケーション・サーバＡＳＶ１，ＡＳＶ２との間に形成されるフローを使用して、アプリケーション・サーバＡＳＶ１との間でセッション制御信号を送受信する。上記アプリケーション・サーバＡＳＶ１，ＡＳＶ２との間に形成されるフローは、発信元の加入者端末及び着信先の加入者端末との間にそれぞれ形成されるフローとは独立したフローである。
【００２９】
次に、以上のように構成されたセッション制御サーバ（Ｓ−ＣＳＣＦ）２−Ａ，２−Ｂの動作を、２種類のサービスを例にとって説明する。  
（１）ＩＭＳ  ＣＡＴサービスの提供を受ける場合  
ここでは、加入者端末ＵＥ−Ａを発信元、加入者端末ＵＥ−Ｂを着信先とし、発信元の加入者端末ＵＥ−ＡがＣＡＴサービスを利用する場合を例にとって説明する。ＣＡＴサービスは、アプリケーション・サーバＡＳＶ１が提供する。図４はその制御シーケンスを示す図である。
【００３０】
先ず、発信元の加入者端末ＵＥ−Ａがセッション確立要求INVITE(Offer A1)を送信すると、このINVITE(Offer A1)は上記加入者端末ＵＥ−Ａを収容するＰ−ＣＳＣＦ１−Ａで受信されたのちＳ−ＣＳＣＦ２−Ａに転送され、このＳ−ＣＳＣＦ２−Ａから着信先の加入者端末ＵＥ−Ｂを収容するＳ−ＣＳＣＦ２−Ｂに転送される。
【００３１】
さて、上記セッション確立要求INVITE(Offer A1)を受信すると着信側のＳ−ＣＳＣＦ２−Ｂは、ＡＳ送受信要否判定部２１２により、アプリケーション・サーバに対するセッション制御信号の送受信の要否を以下のように判定する。すなわち、先ず上記受信したINVITE(Offer A1)をもとに、加入者情報記憶部２２１に保存されたinitial Filter Criteria４０の中から、発信元の加入者に対応する条件が記憶されたService Point Triggerを検索する。次に、この検索されたService Point Trigger のAS handling case within session５６に記載された接続条件に、現在のセッション制御過程が該当するか否かを判定する。そして、この判定の結果、現在のセッション制御過程が上記接続条件に該当すると、アプリケーション・サーバに対するセッション制御信号の送受信が必要と判断する。
【００３２】
例えば、いまAS handling case within session５６に接続条件として「セッション確立前のみ」が記載されていれば、現在のセッション制御過程はセッション確立前の状態であるため上記接続条件に該当する。このため、ＡＳ送受信要否判定部２１２は、アプリケーション・サーバＡＳＶ１に対するセッション制御信号の送受信が必要と判断する。
【００３３】
ＡＳ送受信要否判定部２１２により送受信が必要と判断されると、信号送受信制御部２１３によりApplication Server管理情報４２が読み出され、この管理情報４２に記載された情報に基づいて、アプリケーション・サーバＡＳＶ１との間でセッション確立要求INVITE(Offer A1)の送受信が行われる。なお、このときアプリケーション・サーバＡＳＶ１との間のINVITE(Offer A1)の送受信は、図８に示すように発信元の加入者端末及び着信先の加入者端末との間にそれぞれ形成されるフローとは独立したフローにより行われる。
【００３４】
上記INVITE(Offer A1)を受信するとアプリケーション・サーバＡＳＶ１は、音源としてのＭＲＦに対しINVITE(Offer A1)を与える。ＭＲＦは上記INVITE(Offer A1)に応じてＣＡＴ用リソースを確保し、アプリケーション・サーバＡＳＶ１に対し200OK(CAT-answer)を返送する。
【００３５】
また、アプリケーション・サーバＡＳＶ１からINVITE(Offer A1)が返送されるとＳ−ＣＳＣＦ２−Ｂは、着信先の加入者端末ＵＥ−Ｂに向けINVITE(Offer A1)を送信する。このINVITE(Offer A1)はＰ−ＣＳＣＦ１−Ｂを経て着信先の加入者端末ＵＥ−Ｂに転送される。上記INVITE(Offer A1)を受信すると着信先の加入者端末ＵＥ−Ｂは、183(Answer B1)を返送する。183(Answer B1)が返送されるとＳ−ＣＳＣＦ２−Ｂは、この183(Answer B1)を、上記着信先の加入者端末ＵＥ−Ｂとの間に形成されるフローとは異なるフローによりアプリケーション・サーバＡＳＶ１へ転送する。そして、アプリケーション・サーバＡＳＶ１からPRACKが返送されると、このPRACKを着信先の加入者端末ＵＥ−Ｂへ転送する。これに対し着信先の加入者端末ＵＥ−Ｂから応答信号200OK(PRA)が返送されると、Ｓ−ＣＳＣＦ２−Ｂは当該200OK(PRA)をアプリケーション・サーバＡＳＶ１へ転送する。アプリケーション・サーバＡＳＶ１が上記応答信号200OK(PRA)を受信すると、ＭＲＦはＣＡＴ用の圧縮音楽データを記憶媒体から読み出して復号し、この復号された音楽データの送信を開始する。
【００３６】
一方、上記発信元の加入者端末ＵＥ−ＡからINVITE(Offer A1)を受信すると、アプリケーション・サーバＡＳＶ１は183(session: CAT-answer)を返送する。この183(session: CAT-answer)は、発信側のＳ−ＣＳＣＦ２−Ａ及びＰ−ＣＳＣＦ１−Ａを介して発信元の加入者端末ＵＥ−Ａに転送される。上記183(session: CAT-answer)を受信すると発信元の加入者端末ＵＥ−Ａは、PRACKを返送する。このPRACKは、発信側のＰ−ＣＳＣＦ１−Ａ及びＳ−ＣＳＣＦ２−Ａを介して着信側のＳ−ＣＳＣＦ２−Ｂに転送され、さらにアプリケーション・サーバＡＳＶ１へ転送される。これに対し、アプリケーション・サーバＡＳＶ１が応答信号200OK(PRA)を返送すると、この200OK(PRA)は着信側のＳ−ＣＳＣＦ２−Ｂから発信元の加入者端末ＵＥ−Ａへ転送される。  
かくして、ＭＲＦから送信されたＣＡＴ用の音楽データは発信元の加入者端末ＵＥ−Ａに転送され、この発信元の加入者端末ＵＥ−ＡにおいてＲＢＴの代わりに出力される。したがって、発信元のユーザは呼出中であることを音楽により確認できる。
【００３７】
この状態で、着信先の加入者端末ＵＥ−Ｂにおいてユーザが着信応答すると、着信先の加入者端末ＵＥ−Ｂから200OK(INV)(no SDP)が送信される。Ｓ−ＣＳＣＦ２−Ｂは、上記200OK(INV)(no SDP)を受信するとこの200OK(INV)(no SDP)をアプリケーション・サーバＡＳＶ１へ転送する。この200OK(INV)(no SDP)を受信するとアプリケーション・サーバＡＳＶ１は、ＭＲＦに対し終了信号BYEを送信する。この終了信号BYEを受信するとＭＲＦは、ＣＡＴ用の音声データの送信を停止し、その応答信号200OK(BYE)をアプリケーション・サーバＡＳＶ１へ返送する。
【００３８】
また、上記200OK(INV)(no SDP)を受信するとアプリケーション・サーバＡＳＶ１は、UPDATE(Offer B1)を発信元の加入者端末ＵＥ−Ａへ送信する。これに対し発信元の加入者端末ＵＥ−Ａは200OK(UDP)(Answer A2)を返送する。この200OK(UDP)(Answer A2)は、発信側のＰ−ＣＳＣＦ１−Ａ及びＳ−ＣＳＣＦ２−Ａを介して着信側のＳ−ＣＳＣＦ２−Ｂに転送され、さらにアプリケーション・サーバＡＳＶ１へ転送される。これに対し、アプリケーション・サーバＡＳＶ１が応答信号200OK(INV)(no SDP)を返送すると、この200OK(INV)(no SDP)は着信側のＳ−ＣＳＣＦ２−Ｂから発信元の加入者端末ＵＥ−Ａへ転送される。  
かくして、発信元の加入者端末ＵＥ−Ａと着信先の加入者端末ＵＥ−Ｂとの間にはセッションが確立され、以後両端末間では図４の６ａに示すように通話のためのメディアデータ転送状態となる。
【００３９】
上記メディアデータの転送状態となると、発信元の加入者端末ＵＥ−Ａは上記200OK(INV)(no SDP)に対し先ずACKを返送する。このACKは発信側のＰ−ＣＳＣＦ１−Ａ及びＳ−ＣＳＣＦ２−Ａを介して着信側のＳ−ＣＳＣＦ２−Ｂに転送される。ACKを受信すると着信側のＳ−ＣＳＣＦ２−Ｂは、ＡＳ送受信要否判定部２１２により、加入者情報記憶部２２１に保存されたinitial Filter Criteria４０の中から発信元の加入者に対応する条件が記憶されたService Point Triggerを検索し、この検索されたService Point Trigger のAS handling case within session５６に記載された接続条件に、現在のセッション制御過程が該当するか否かを判定する。
【００４０】
例えば、現在のセッション制御過程はセッション確立後であり、かつAS handling case within session５６に記載された接続条件は「セッション確立前」である。このためＡＳ送受信要否判定部２１２は、現在のセッション制御過程は接続条件に該当しないと判定し、アプリケーション・サーバＡＳＶ１に対するセッション制御信号の送受信は不要と判断する。  
ＡＳ送受信要否判定部２１２により送受信が不要と判断されると、信号送受信制御部２１３はアプリケーション・サーバＡＳＶ１への上記ACK の送信を省略し、当該ACKを着信先の加入者端末ＵＥ−Ｂへ向け転送する。
【００４１】
以後同様に、加入者端末ＵＥ−Ａ，ＵＥ−Ｂからセッション制御信号が送信されるごとに、着信側のＳ−ＣＳＣＦ２−ＢではＡＳ送受信要否判定部２１２により現在のセッション制御過程がAS handling case within session５６に記載された接続条件に該当するか否かが判定される。そして、現在のセッション制御過程はセッション確立後であり、AS handling case within session５６に記載された接続条件（セッション確立前）に該当しないため、信号送受信制御部２１３はアプリケーション・サーバＡＳＶ１との間の上記セッション制御信号の送受信を省略する。  
したがって、加入者端末ＵＥ−Ａ，ＵＥ−Ｂ間にセッションが確立された後は、Ｓ−ＣＳＣＦ２−Ｂとアプリケーション・サーバＡＳＶ１との間では不必要なセッション制御信号の送受信が行われないようになり、これによりアプリケーション・サーバＡＳＶ１の処理負担は軽減される。
【００４２】
図５は、以上述べた本実施形態のＡＳ送受信要否の判定を行わない場合のシーケンスを示したものである。同図の８ａに示すように、加入者端末ＵＥ−Ａ，ＵＥ−Ｂ間にセッションが確立された後にも、Ｓ−ＣＳＣＦ２−Ｂとアプリケーション・サーバＡＳＶ１との間ではセッション制御信号ACKが無条件に送受信される。このため、アプリケーション・サーバＡＳＶ１では実質的な不必要なセッション制御信号の送受信処理を強いられることになり、その分処理負担が大きくなる。
【００４３】
（２）保留サービスの提供を受ける場合  
ここでは、加入者端末ＵＥ−Ａ，ＵＥ−Ｂ間でセッションが確立された状態で、着信先の加入者端末ＵＥ−Ｂの操作に応じて保留サービスが実行される場合を例にとって説明する。保留サービスは、アプリケーション・サーバＡＳＶ２が提供する。図６はその制御シーケンスを示す図である。
【００４４】
先ず、発信元の加入者端末ＵＥ−Ａがセッション確立要求INVITE(Offer A1)を送信すると、このINVITE(Offer A1)は上記加入者端末ＵＥ−Ａを収容するＰ−ＣＳＣＦ１−Ａで受信されたのちＳ−ＣＳＣＦ２−Ａに転送され、このＳ−ＣＳＣＦ２−Ａから着信先の加入者端末ＵＥ−Ｂを収容するＳ−ＣＳＣＦ２−Ｂに転送される。
【００４５】
さて、上記セッション確立要求INVITE(Offer A1)を受信すると着信側のＳ−ＣＳＣＦ２−Ｂは、ＡＳ送受信要否判定部２１２により、アプリケーション・サーバに対するセッション制御信号の送受信の要否を以下のように判定する。すなわち、先ず上記受信したINVITE(Offer A1)をもとに、加入者情報記憶部２２１に保存されたinitial Filter Criteria４０の中から、発信元の加入者に対応する条件が記憶されたService Point Triggerを検索する。次に、この検索されたService Point Trigger のAS handling case within session５６に記載された接続条件に、現在のセッション制御過程が該当するか否かを判定する。そして、この判定の結果、現在のセッション制御過程が上記接続条件に該当しなければ、アプリケーション・サーバに対するセッション制御信号の送受信は不要と判断する。
【００４６】
例えば、いまAS handling case within session５６に接続条件として「セッション確立後のみ」が記載されていれば、現在のセッション制御過程はセッション確立前の状態（図６中の７ａ）であるため上記接続条件に該当しない。このため、ＡＳ送受信要否判定部２１２は、アプリケーション・サーバＡＳＶ２への上記INVITE(Offer A1)の送信は不必要と判断する。
【００４７】
ＡＳ送受信要否判定部２１２により送受信が不必要と判断されると、信号送受信制御部２１３はアプリケーション・サーバＡＳＶ２への上記セッション確立要求INVITE(Offer A1)の送信を省略し、当該INVITE(Offer A1)を着信先の加入者端末ＵＥ−Ｂへ向け送信する。このINVITE(Offer A1)は着信側のＰ−ＣＳＣＦ１−Ｂを経て着信先の加入者端末ＵＥ−Ｂに転送される。INVITE(Offer A1)を受信すると着信先の加入者端末ＵＥ−Ｂは、応答信号183(Answer B1)を返送する。
【００４８】
上記応答信号183(Answer B1)を受信した場合にも、Ｓ−ＣＳＣＦ２−ＢはＡＳ送受信要否判定部２１２により、アプリケーション・サーバＡＳＶ２に対するセッション制御信号の送受信の要否を判定する。そして、この場合も現在のセッション制御過程はセッション確立前の状態（図６中の７ａ）であるため、AS handling case within session５６に記述された接続条件、つまり「セッション確立後のみ」に該当しない。このため、ＡＳ送受信要否判定部２１２は、アプリケーション・サーバＡＳＶ２への上記応答信号183(Answer B1)の送信は不必要と判断する。
【００４９】
ＡＳ送受信要否判定部２１２により送受信が不必要と判断されると、信号送受信制御部２１３はアプリケーション・サーバＡＳＶ２への上記応答信号183(Answer B1)の送信を省略し、当該183(Answer B1)を発信元の加入者端末ＵＥ−Ａへ向け送信する。この上記183(Answer B1)は発信側のＳ−ＣＳＣＦ２−Ａ及びＰ−ＣＳＣＦ１−Ａを経て発信元の加入者端末ＵＥ−Ａに転送される。
【００５０】
以後同様に、加入者端末ＵＥ−Ａ，ＵＥ−ＢからPRACK、200OK(PRA)、200OK(INV)、ACK等のセッション制御信号が送信されるごとに、着信側のＳ−ＣＳＣＦ２−ＢではＡＳ送受信要否判定部２１２により現在のセッション制御過程がAS handling case within session５６に記載された接続条件に該当するか否かが判定される。そして、現在のセッション制御過程はセッション確立前であり、AS handling case within session５６に記載された接続条件（セッション確立後）に該当しないため、信号送受信制御部２１３はアプリケーション・サーバＡＳＶ２との間の上記セッション制御信号の送受信を省略する。  
したがって、加入者端末ＵＥ−Ａ，ＵＥ−Ｂ間にセッションが確立される前の状態では、Ｓ−ＣＳＣＦ２−Ｂとアプリケーション・サーバＡＳＶ２との間では不必要なセッション制御信号の送受信が行われないようになり、これによりアプリケーション・サーバＡＳＶ２の処理負担は軽減される。
【００５１】
一方、加入者端末ＵＥ−Ａ，ＵＥ−Ｂ間にセッションが確立された後の状態では、以下のようにＡＳ送受信要否判定処理とその判定結果に基づくセッション制御信号の送受信処理が行われる。  
すなわち、加入者端末ＵＥ−Ｂにおいて保留操作が行われると、加入者端末ＵＥ−ＢからINVITE(sendonly)が送信される。このINVITE(sendonly)を受信すると着信側のＳ−ＣＳＣＦ２−Ｂは、ＡＳ送受信要否判定部２１２により、アプリケーション・サーバＡＳＶ２に対するセッション制御信号の送受信の要否を判定する。
【００５２】
すなわち、先ず上記受信したINVITE(sendonly)をもとに、加入者情報記憶部２２１に保存されたinitial Filter Criteria４０の中から、発信元の加入者に対応する条件が記憶されたService Point Triggerを検索する。次に、この検索されたService Point Trigger のAS handling case within session５６に記載された接続条件に、現在のセッション制御過程が該当するか否かを判定する。そして、この判定の結果、現在のセッション制御過程が上記接続条件に該当すると、アプリケーション・サーバに対するセッション制御信号の送受信が必要と判断する。
【００５３】
例えば、いまAS handling case within session５６には接続条件として「セッション確立後」が記載されているので、現在のセッション制御過程はセッション確立後の状態であるため上記接続条件に該当する。このため、ＡＳ送受信要否判定部２１２は、アプリケーション・サーバＡＳＶ２に対するセッション制御信号の送受信は必要と判断する。
【００５４】
ＡＳ送受信要否判定部２１２により送受信が必要と判断されると、信号送受信制御部２１３によりApplication Server管理情報４２が読み出され、この管理情報４２に記載された情報に基づいて、アプリケーション・サーバＡＳＶ２との間で上記INVITE(sendonly)の送受信が行われる。なお、このときアプリケーション・サーバＡＳＶ２との間のINVITE(sendonly)の送受信は、図８に示すように加入者端末ＵＥ−Ａ及び加入者端末ＵＥ−Ｂとの間にそれぞれ形成されるフローとは独立したフローにより行われる。
【００５５】
上記INVITE(sendonly)を受信するとアプリケーション・サーバＡＳＶ２は、当該INVITE(sendonly)を加入者端末ＵＥ−Ａへ送信する。このINVITE(sendonly)は、Ｓ−ＣＳＣＦ２−Ａ及びＰ−ＣＳＣＦ１−Ａを介して加入者端末ＵＥ−Ａに転送される。INVITE(sendonly)を受信すると加入者端末ＵＥ−Ａは応答信号200OK(recvonly)を返送する。この応答信号200OK(recvonly)はＰ−ＣＳＣＦ１−Ａ及びＳ−ＣＳＣＦ２−Ａを経てＳ−ＣＳＣＦ２−Ｂに転送される。
【００５６】
この200OK(recvonly)を受信するとＳ−ＣＳＣＦ２−Ｂは、ＡＳ送受信要否判定部２１２により、アプリケーション・サーバＡＳＶ２に対する上記200OK(recvonly)の送受信の要否を判定する。この判定の結果、いまはセッション確立後であり、かつAS handling case within session５６には接続条件として「セッション確立後」が記載されているので、アプリケーション・サーバＡＳＶ２に対する上記200OK(recvonly)の送受信は必要と判断する。送受信が必要と判断されると、信号送受信制御部２１３によりアプリケーション・サーバＡＳＶ２へ上記200OK(recvonly)が送信される。
【００５７】
アプリケーション・サーバＡＳＶ２は、上記200OK(recvonly)を受信すると保留用の音源であるＭＲＦに対し保留音の送信を指示する。この結果、ＭＲＦは記憶媒体から圧縮保留音データを読み出して復号し、この復号された保留音データを送信する。この保留音データはアプリケーション・サーバＡＳＶ２から、Ｓ−ＣＳＣＦ２−Ｂ、Ｓ−ＣＳＣＦ２−Ａ及びＰ−ＣＳＣＦ１−Ａを経て加入者端末ＵＥ−Ａに転送される。かくして、加入者端末ＵＥ−Ａのユーザは保留中であることを確認できる。  
なお、上記ＭＲＦに対する保留音の送信指示を終了すると、アプリケーション・サーバＡＳＶ２は上記200OK(recvonly)をＳ−ＣＳＣＦ２−Ｂへ返送する。Ｓ−ＣＳＣＦ２−Ｂは、上記200OK(recvonly)を保留操作した加入者端末ＵＥ−Ｂへ送信する。
【００５８】
図７は、以上述べた保留サービスの提供を受ける場合に、ＡＳ送受信要否の判定を行わない場合のシーケンスを示したものである。同図の９ａに示すように、加入者端末ＵＥ−Ａ，ＵＥ−Ｂ間にセッションが確立される前の状態において、Ｓ−ＣＳＣＦ２−Ｂとアプリケーション・サーバＡＳＶ２との間ではセッション制御信号が無条件に送受信される。このため、アプリケーション・サーバＡＳＶ１では実質的な不必要なセッション制御信号の送受信処理を強いられることになり、その分処理負担が大きくなる。
【００５９】
（３）ルート情報の構築処理
上記（１）及び（２）において述べたセッション確立要求の転送過程において、Ｓ−ＣＳＣＦ２−Ｂでは以下のようにルート情報の構築処理が行われる。図９は、発信元の加入者端末ＵＥ−Ａから着信先の加入者端末ＵＥ−Ｂまでのセッション制御経路におけるルート情報構築処理を示す図である。
【００６０】
発信元の加入者端末ＵＥ−Ａがセッション確立要求INVITE(Offer A1)を送信すると、その転送経路上に位置する各ノードは順次ルート情報に自ノードの識別情報を記録する。例えば、Ｐ−ＣＳＣＦ１−Ａは自身の識別情報（Ａ）をルート情報（Route set）に記録し、続いてＳ−ＣＳＣＦ２−Ａは自身の識別情報（Ｂ）を上記ルート情報に追加記録する。
【００６１】
一方、Ｓ−ＣＳＣＦ２−Ｂは、上記セッション確立要求INVITE(Offer A1)を受信すると、ルート情報構築部２１１の制御の下で、セッション制御経路にアプリケーション・サーバＡＳＶ１，ＡＳＶ２が含まれる場合であっても、当該アプリケーション・サーバＡＳＶ１，ＡＳＶ２の識別情報（１），（２）を上記ルート情報に記録せず、自身の識別情報（Ｃ）のみをルート情報に追加記録する。そして、このルート情報をINVITE(Offer A1)と共にＰ−ＣＳＣＦ１−Ｂへ転送する。Ｐ−ＣＳＣＦ１−Ｂは、上記INVITE(Offer A1)を受信すると、自身の識別情報（Ｄ）をルート情報に追加記録した後、着信先の加入者端末ＵＥ−Ｂへ転送する。着信先の加入者端末ＵＥ−Ｂは、上記INVITE(Offer A1)と共にルート情報を受信すると、このルート情報を構築済みのルート情報として記憶すると共に、応答信号により発信元の加入者端末ＵＥ−Ａへ返送する。発信元の加入者端末ＵＥ−Ａは、上記応答信号と共に受信した構築済みのルート情報を記憶し、以後このルート情報を用いてセッション制御信号を送信する。  
かくして、アプリケーション・サーバＡＳＶ１，ＡＳＶ２の識別情報はルート情報から隠蔽される。
【００６２】
以上説明したようにこの実施形態では、加入者情報の一つであるinitial Filter Criteria４０にAS handling case within session５６の記憶領域を設け、このAS handling case within session５６にアプリケーション・サーバＡＳＶ１，ＡＳＶ２に対する接続条件を記憶している。そして、Ｓ−ＣＳＣＦ２−Ｂが上記加入者端末ＵＥ−Ａ，ＵＥ−Ｂ間のセッションを制御する際に、加入者に対応するinitial Filter Criteria４０のAS handling case within session５６をもとに、上記アプリケーション・サーバＡＳＶ１，ＡＳＶ２に対するセッション制御信号の送受信の要否を判定し、この判定の結果送受信が必要と判定された場合にのみアプリケーション・サーバＡＳＶ１，ＡＳＶ２との間でセッション制御信号を送受信するようにしている。
【００６３】
したがって、Ｓ−ＣＳＣＦ２−Ｂとアプリケーション・サーバＡＳＶ１，ＡＳＶ２との間では、AS handling case within session５６として予め設定した接続条件を満たすときのみセッション制御信号の送受信が行われることになる。したがって、アプリケーション・サーバＡＳＶ１，ＡＳＶ２では無駄なセッション制御信号の送受信処理が行われなくなり、これによりアプリケーション・サーバＡＳＶ１，ＡＳＶ２の処理負荷を軽減することができる。
【００６４】
また、接続条件としてセッション制御の期間、例えば「常時」、「セッション確立前」、「セッション確立後」を選択的に記憶し、現在のセッション制御過程がこれらの期間に該当する場合にのみアプリケーション・サーバＡＳＶ１，ＡＳＶ２との間でセッション制御信号の送受信を行うようにしている。このため、接続条件を「常時」、「セッション確立前」、「セッション確立後」の３種類の送受信許可期間により指定することができ、これにより簡単な条件によりアプリケーション・サーバとの間のセッション制御信号の送受信を制御することができる。
【００６５】
さらに、発信元の加入者端末ＵＥ−Ａから送信されるセッション確立要求に応じてセッション制御経路を表すルート情報（Route set）を構築する際に、Ｓ−ＣＳＣＦ２−Ｂはアプリケーション・サーバＡＳＶ１，ＡＳＶ２の識別情報を上記ルート情報に記録しないようにしている。このため、アプリケーション・サーバＡＳＶ１，ＡＳＶ２の識別情報をルート情報から隠蔽することができる。したがって、ルート情報の情報サイズを小さくすることができ、これにより加入者端末が多数のアプリケーション・サーバのサービスを利用する場合でも、セッション制御信号のデータサイズを小型化することが可能となる。
【００６６】
なお、この発明は上記実施形態に限定されるものではない。例えば、前記実施形態ではAS handling case within session５６として設定する接続条件として、「常時」、「セッション確立前」、「セッション確立後」の３種類の送受信許可期間を設定するようにしたが、他に「セッション解放期間」を加えてもよく、さらにはセッション制御信号単位で接続条件を設定するようにしてもよい。
【００６７】
また、前記実施形態では、アプリケーション・サーバＡＳＶ１，ＡＳＶ２が提供するサービスとして、ＣＡＴサービスと保留サービスを提供する場合を例にとって説明したが、留守番録音サービス等のその他のサービスを提供する場合にも、この発明は同様に適用可能である。
【００６８】
その他、アプリケーション・サーバとの接続条件を表す拡張情報の構成やその記憶手段の構成、ＡＳ送受信要否判定処理及びその判定結果に基づくセッション制御信号の送受信制御処理の手順等についても、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。
【００６９】
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００７０】
ＮＷ…SIP ベースのＩＭＳネットワーク、ＳＳＶ−Ａ，ＳＳＶ−Ｂ…SIP サーバ、１−Ａ，１−Ｂ…Ｐ−ＣＳＣＦ、２−Ａ，２−Ｂ…Ｓ−ＣＳＣＦ、ＡＳＶ１，ＡＳＶ２…アプリケーション・サーバ、ＵＥ−Ａ，ＵＥ−Ｂ…加入者端末、ＤＢ…加入者情報データベース（ＨＳＳ）、２１…制御ユニット、２２…記憶ユニット、２３…SIP 送受信部、２１１…ルート情報構築部、２１２…ＡＳ送受信要否判定部、２１３…信号送受信制御部、２２１…加入者情報記憶部、４０…Initial Filter Criteria、４１…Trigger Point、４１１〜４１ｎ…Service Point Trigger、４２…Application Server管理情報。
【図１】
2011041192.tif 000003
【図２】
2011041192.tif 000004
【図３】
2011041192.tif 000005
【図４】
2011041192.tif 000006
【図５】
2011041192.tif 000007
【図６】
2011041192.tif 000008
【図７】
2011041192.tif 000009
【図８】
2011041192.tif 000010
【図９】
2011041192.tif 000011
【図１０】
2011041192.tif 000012
【図１１】
2011041192.tif 000013
【図１２】
2011041192.tif 000014
【図１３】
2011041192.tif 000015