JP5194056B2 - 呼セッション制御方法、および呼セッション制御サーバ - Google Patents

呼セッション制御方法、および呼セッション制御サーバ Download PDF

Info

Publication number
JP5194056B2
JP5194056B2 JP2010128765A JP2010128765A JP5194056B2 JP 5194056 B2 JP5194056 B2 JP 5194056B2 JP 2010128765 A JP2010128765 A JP 2010128765A JP 2010128765 A JP2010128765 A JP 2010128765A JP 5194056 B2 JP5194056 B2 JP 5194056B2
Authority
JP
Japan
Prior art keywords
call
session control
loop
establishment request
request signal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010128765A
Other languages
English (en)
Other versions
JP2011254423A (ja
Inventor
伸之 千綿
裕一 石原
健一郎 松本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2010128765A priority Critical patent/JP5194056B2/ja
Publication of JP2011254423A publication Critical patent/JP2011254423A/ja
Application granted granted Critical
Publication of JP5194056B2 publication Critical patent/JP5194056B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

本発明は、3GPP(Third Generation Partnership Project)、3GPP2(Third Generation Partnership Project2)にて標準化されているIMS(IP Multimedia )において、呼確立要求信号を受信した呼セッション制御機能部(以下CSCF:Call Session Control Functionと称する)が、受信した呼確立要求信号の内容と予め設定している接続条件(以下、iFC:initial Filter Criteriaと称する)とを比較し、合致するか否かを判定し、合致した場合は、該当するサービスを提供するアプリケーションサーバ(以下、「AS」:Application Serverと称する)に接続する処理を行う呼セッション制御技術に関する。
従来のiFC処理の実装技術としては、次のような技術がある。すなわち、CSCFが呼確立要求信号(SIP:Session Initiation Protocolにおける、INVITEメソッド、MESSAGEメソッドなどを指す)を受信すると、呼確立要求信号の内容と予め設定しているiFCとを、予めiFC毎に設定された優先度の高い順番に合致するか否かを判定する。合致した場合は、該当するASに呼確立要求信号を送信して接続する処理(以下、「AS接続処理」と称する)を行う。呼確立要求信号を受信したASは、サービスを提供し、提供したサービスにもとづく呼確立要求信号をCSCFへ送信して接続する処理(以下、「CSCF接続処理」と称する)を行う。CSCFがASから送信された呼確立要求信号を受信すると、先に合致したiFCより低い優先度を持った未判定のiFCから判定を継続する(例えば、非特許文献1参照)。
"3GPP TS 23.218""、[online]、[平成22年3月30日検索]、インターネット<http://www.3gpp.org/ftp/Specs/archive/23_series/23.218/23218-900.zip>
しかしながら、上記の技術では、CSCFにとっては優先度の高いiFCから順番に判定していくことができるが、CSCF側の優先度のつけ方とAS側のサービスの提供の仕方とが整合していない場合には、不具合が発生する場合がある。具体的には、呼確立要求信号の着信先アドレスを例にすると、CSCFが受信した呼確立要求信号の着信先アドレスがiFCに合致したことによりAS接続処理を行い、接続されたASのCSCF接続処理によりCSCFが受信した呼確立要求信号の着信先アドレスが、(1)論理アドレスなどのルーチングすることができないアドレスであって、(2)前記着信先アドレスが既に判定の対象となった判定済みのiFCに合致するアドレスであり、さらに(3)前記着信先アドレスの条件に合致する未判定iFCが存在しない場合に不具合が発生する。
前記(1)、(2)および(3)の条件を全て満たす場合、CSCF接続処理によりCSCFが受信した呼確立要求信号は、判定済みiFCとの合致判定は行われず、また、未判定iFCにも合致しないことから、着信先アドレスは論理アドレスの状態のままでiFC処理を終了することになる。このため、CSCF接続処理によりCSCFがASから受信する呼確立要求信号の着信先アドレスを用いて接続先へルーチングすることができず、呼損等となり、ASがサービスを提供できなくなる。
図8は、着信先アドレスがiFCに合致したことによりAS接続処理を行い、接続されたASのCSCF接続処理によりCSCFが受信した呼確立要求信号の着信先アドレスを基に着信先へルーチングできない場合を説明するための図である。図示するシステムは、CSCF−B2と、AS#6 3fと、端末装置4とを有し、AS#6 3fおよび端末装置4は、CSCF−B2に接続されている。
CSCF−B2は、加入者系のセッション制御機能を含むユーザ収容ノードである。AS#6 3fは、CSCF−B2から接続されることにより、所定のサービスを提供するアプリケーションサーバ(AS)である。端末装置4は、通信サービスを利用するユーザが操作する端末装置である。
CSCF−B2には、予めiFC11およびiFC12の2つの接続条件が設定されている。iFC11は、CSCFが受信した呼確立要求信号の着信先アドレスが0800の論理番号(図示する例では0800−123456)である場合に、AS#6 3fに接続する処理を行うという条件および動作を、優先度「1」として定義したものである。
iFC12は、着信先アドレスが0120の論理番号(図示する例では0120−234567)である場合に、AS#6 3fに接続する処理を行うという条件および動作を、優先度「2」として定義したものである(iFCには、その他に記載する条件として条件合致時の接続先ASのアドレス等があるが、ここでは省略するものとする。)。
また、AS#6 3fのサービスの提供の仕様としては、0120番号(図示する例では0120−234567)が送られてきた場合は0800番号(図示する例では0800−123456)に変換し、また、0800番号(図示する例は0800−123456)が送られてきた場合は0AB〜Jの物理番号に変換する処理を行うものとする。
端末装置4が、着信先アドレスが0120番号(0120−234567)である呼確立要求信号を送信すると、CSCF−B2が当該信号を受信する。そして、CSCF−B2は、呼確立要求信号の0120番号(0120−234567)と、優先度が最も高いiFC11との比較を行うが、合致しないことからスキップし、優先度が次に高いiFC12との比較を行う。iFC12(着信先アドレス:0120−234567)と合致するため、CSCF−B2は、AS#6 3fにAS接続処理を行う。
AS#6 3fは、CSCF−B2から着信先アドレスが0120番号(0120−234567)である呼確立要求信号が送られてくると、着信先アドレスを0800番号(0800−123456)に変換するサービスを行い、着信先アドレスが0800番号(0120−234567)である呼確立要求信号をCSCF−B2に送信するCSCF接続処理を行う。
CSCF−B2は、着信先アドレスが0800番号(0800−123456)である呼確立要求信号を受信し、CSCF接続処理の呼確立要求信号と、iFCとの比較を行う。ここで比較を行う対象は、iFCは未判定のiFCのみである。iFC11およびiFC12については、既に判定済みのiFCであるため、判定対象外となる。そのため、着信先アドレスが0800番号(0800−123456)については、既に判定済みでスキップしたiFC11で定義されてはいるが、判定されることはない。
図8に示す例では、iFC11およびiFC12以外のiFCが存在しないため、未判定iFC なしとなり、iFC判定処理は終了する。iFC判定処理終了後、CSCF-B2は、着信先アドレスを基にルーチング処理を試行するが、呼確立要求信号の着信先アドレスが論理アドレスであることからルーチング先を解決できず、エラー応答により呼損とするなどのルーチング不可能時の動作をすることになる。
また、図8において、方路なし(NG)となることを回避するために、iFC11とiFC12の優先度の順番を入れ替えるということが考えられる。しかしその場合、iFCの優先度設定において、iFCを設定するユーザ(システム管理者など)は、各ASの提供するサービスの内容毎に、関連するiFCの優先度の高低の条件を考慮し、条件に従った設定を確実に行う必要がある。その結果、iFCの設定が難しくなり、iFCを設定するユーザの負荷が大きくなる。また、ユーザが行ったiFCの設定誤りにより、呼損となる可能性が排除できない。
以上説明したように、CSCF側の優先度の設定とAS側のサービス提供の仕様とが整合していない場合は、呼損となってしまうという問題がある。
本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、CSCF側の優先度の設定とAS側のサービス提供の仕様とが整合していない場合であっても呼損とすることがない、呼セッション制御方法、および呼セッション制御サーバを提供することにある。
上記目的を達成するため、本発明は、呼セッション制御方法であって、呼セッション制御サーバは、複数のサービスの各々の接続条件が優先度とともに記憶された記憶部を、有し、端末またはアプリケーションサーバから送信される呼確立要求信号を受信し、当該呼確立要求信号の信号情報と、前記記憶部に記憶された各接続条件とを、既に合致した接続条件の優先度に関わらず優先度の最も高い接続条件から順番に前記信号情報と接続条件とが合致するまで比較する判定ステップと、前記判定ステップにおいて、いずれかの接続条件と合致した場合、前記信号情報と合致した接続条件に設定されたアプリケーションサーバへ接続するサーバ接続ステップと、を行う。
本発明は、呼セッション制御サーバであって、複数のサービスの各々の接続条件が優先度とともに記憶された記憶手段と、端末またはアプリケーションサーバから送信される呼確立要求信号を受信し、当該呼確立要求信号の信号情報と、前記記憶手段に記憶された各接続条件とを、既に合致した接続条件の優先度に関わらず優先度の最も高い接続条件から順番に前記信号情報と接続条件とが合致するまで比較する判定手段と、前記信号情報といずれかの接続条件とが合致した場合、ループ事象が発生しているか否かを判定するループ判定手段と、ループ事象が発生していないと判定された場合、前記信号情報と合致した接続条件に設定されたアプリケーションサーバへ接続するサーバ接続手段と、ループ事象が発生したと判定された場合、所定のガイダンスを送出する、または、呼を切断するループ検出後処理手段と、を有する。
本発明によれば、CSCF側の優先度の設定とAS側のサービス提供の仕様とが整合していない場合であっても呼損とすることがない、呼セッション制御方法、および呼セッション制御サーバを提供することができる。
本発明の実施形態に係るシステムの全体構成図である。 本実施形態のCSCFの構成例を示す図である。 CSCFの判定部の処理概要を説明するための図である。 CSCFの判定部の処理例(ループなし)を説明するための図である。 CSCFの判定部の処理例(ループあり)を説明するための図である。 CSCFの動作の一例を示すフローチャートである。 システムの動作の一例を示すシーケンスチャートである。 CSCFが受信した呼確立要求信号の着信先アドレスを用いて着信先へルーチングできない場合を説明するための図である。
以下、本発明の実施の形態について、図面を参照して説明する。
まず、本発明の実施形態に係るシステムについて説明する。
[システムの構成]
図1は、本実施形態のシステムの構成例を示す構成図である。図示する本システムは、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#2 3b、AS#3 3c、AS#4 3dおよびAS#5 3eは、それぞれCSCF−A1に接続され、端末装置4もCSCF−A1に接続される。
CSCF−A1は、iFC処理を実装した加入者系のセッション制御機能を含むユーザ収容ノード(例えば、SIPサーバなど)である。詳細についてはこの後説明する。
AS#1 3a〜AS#5 3eは、CSCF−A1から接続されて、各種のサービスを提供するアプリケーションサーバである。
端末装置4は、通信サービスを利用するユーザが操作する端末装置である。なお、図1では、CSCF−A1に接続される端末装置4は1つであるが、端末装置4は複数存在してもよい。
次に、本システムの機能について説明する。
[システムの機能]
本システムでは、CSCF−A1は、端末装置4あるいは他のCSCF−A(不図示)から送信されてきた呼確立要求信号を受信すると、呼確立要求信号の内容と、当該CSCF−A1に設定された各iFC(接続条件)とを比較し、条件に合致するか否かを判定する。条件に合致した場合は、ループ事象が発生しているか否かを判別し、ループ事象が発生していない場合は、AS接続処理を行う。
接続されたASは、CSCF接続処理を行い、呼確立要求信号をCSCF-A1に送信する。CSCF-A1は、ASから送信された呼確立要求信号を受信すると、先に合致したiFCの優先度の高低に関わらず、ASから送信された呼確立要求信号の内容とiFCとを、優先度の最も高いiFCから順番に比較し、条件に合致するか否かを判定する処理を行う。そして、CSCF-A1は、条件に合致するまで、未判定の全てのiFCについての判定処理が終了すると、判定結果に従った呼確立要求信号を着信先となる端末装置4あるいは他のCSCF−A(不図示)に送信する。
次に、本実施形態のCSCF−A1について説明する。
[CSCF−A1の構成]
図2は、図1に示すシステムにおけるCSCF−A1の構成例を示す図である。同図は、CSCF−A1の機能のうち、本発明に関係する部分のみを概念的に示している。
CSCF−A1は、サービス契約情報蓄積部11と、iFC蓄積部12と、SIP信号制御部13と、セッション制御部14と、判定部15とを有している。
サービス契約情報蓄積部11は、ユーザ毎にユーザが契約したサービス契約情報を蓄積する機能を有する。サービス契約情報には、iFC蓄積部12が蓄積する各iFCについて、各ユーザがどのサービスに契約しているかが記憶されている。すなわち、各ユーザと、当該ユーザが契約している少なくとも1つのサービスとが、対応付けて記憶されている。
iFC蓄積部12は、各サービスのiFC(接続条件)を蓄積する機能を有する。すなわち、各サービスと、当該サービスのiFCとが対応付けて記憶されている。なお、各iFCには、iFC蓄積部12に蓄積された全てのiFC内での優先度が設定されている。
SIP信号制御部13は、呼確立要求信号(SIP信号のINVITE、MESSAGE等)や呼確立要求信号に対する応答信号(200 OK信号等)を受信し、これらの信号をセッション制御部14に送出するとともに、セッション制御部14から送出される、これらの信号の処理結果にもとづいて呼確立要求信号およびその応答信号を送信する機能を有する。
セッション制御部14は、SIP信号制御部13から送出される信号を解析し、発信元アドレス、着信先アドレスおよびサービス要求内容等の信号情報を判定部15に送出するとともに、判定部15から送出される接続先AS3情報をSIP信号制御部13に送出する機能を有する。また、セッション制御部14は、SIP信号制御部13から送出される、AS3が提供するサービスに則った呼確立要求信号を解析し、発信元アドレス、着信先アドレスおよびサービス要求内容等の信号情報を判定部15に送出する機能を有する。また、セッション制御部14は、判定部15から送出される判定終了後の着信先アドレス、発信元アドレスおよびサービス要求内容等の信号情報をSIP信号制御部13に送出する機能を有する。
また、セッション制御部14は、判定部15からループ発生情報が送出された場合は、ループ検出後処理を行う機能を有する。
判定部15は、セッション制御部14から送出される発信元アドレスを用いて、サービス契約情報蓄積部11から該当する発信ユーザが契約している全てのサービスを取得する。そして、取得した各サービスに対応するiFCを、iFC蓄積部12からそれぞれ抽出し、当該発信ユーザのiFCとする。なお、iFC蓄積部12から抽出した各iFCには、iFC蓄積部12内でユニークな(重複しない)優先度が設定されている。このため、iFC蓄積部12から抽出した発信ユーサの各iFCの優先度が、重複することはない。
そして、判定部15は、これらの各iFCと、呼確立要求信号に含まれる着信先アドレス、発信元アドレスあるいはサービス要求内容等とを比較し、合致するか否かを判定する。そして、いずれかの各iFCと合致した場合、判定部15は、ループ事象が発生していないことを確認し、接続先AS3情報をセッション制御部14に送出する。
また、判定部15は、セッション制御部14から送出された、AS3が提供するサービスに則った呼確立要求信号に含まれる着信先アドレス、発信元アドレスあるいはサービス要求内容等を受け取り、先に合致したiFCの優先度の高低に関わらず、優先度の最も高いiFCから順番に比較し、合致するか否かを判定する処理を行う。そして、判定部15は、合致するまで全ての未判定のiFCについて判定を行い、判定が終了すると、判定結果に従った着信先アドレス、発信元アドレスおよびサービス要求内容等をセッション制御部14に送出する機能を有する。
また、判定部15は、ループ事象が発生していると判断した場合は、セッション制御部14にループ発生情報を送出する機能を有する。
なお、CSCF−A1は、例えば、CPUと、メモリと、HDD等の外部記憶装置と、入力装置と、出力装置とを備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPUがメモリ上にロードされたCSCF−A1用のプログラムを実行することにより、CSCF−A1の各機能が実現される。また、CSCF−A1用のプログラムは、ハードディスク、フレキシブルディスク、CD−ROM、MO、DVD−ROMなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
次に、CSCF−A1の判定部15の処理について詳しく説明する。
[CSCF−Aの判定部の処理]
まずCSCF−Aの処理の概要について説明する。
図3は、判定部15の処理概要を説明するための図である。判定部15の処理は、iFC判定処理151と、ループ判定処理152とを有する。
SIP信号制御部13およびセッション制御部14は、端末装置4から送信されてきた呼確立要求信号を受信する。これにより、判定部15は、呼確立要求信号に含まれる着信先アドレス、発信元アドレス、サービス要求内容等(S1)を用いて、iFC判定処理151を行う。
iFC判定処理151では、優先度が最も高いiFCを比較対象として設定し(1511)、当該iFCと呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等の信号情報とを比較し(1512)、合致するか否かを判定する。合致しない場合であって、未判定iFCが存在する場合は(1513)、次に優先度が高いiFCを比較対照として設定し(1514)、当該iFCと比較し(1512)、未判定のiFCがなくなるまで以降の処理を繰り返す。
一方、いずれかのiFCと合致した場合は(1512:合致あり)、ループ判定処理152を行う。ループ判定処理152は、例えばAS3への接続処理回数(ASアクセス回数)を取得し(1521)、接続処理回数が所定の回数(規定数)より少ない場合(1521:規定数未満)は、ループ事象が発生していないと判定し、接続先AS情報(S2)をセッション制御部14に送出する。この場合、セッション制御部14およびSIP信号制御部13は、接続先AS情報(S2)を用いて対応するAS3にAS3接続処理を行う。なお、接続先AS情報は、合致した場合に接続するASのアドレス情報であって、各iFCに設定されている。
そして、SIP信号制御部13およびセッション制御部14は、接続されたAS3のCSCF接続処理により、当該AS3の提供サービスに則った呼確立要求信号を受信する。これにより、判定部15は、当該呼確立要求信号に含まれる着信先アドレス、発信元アドレス、サービス要求内容等(S1A)を用いて、iFC判定処理151を行う。その際、iFC判定処理151では、先に合致したiFCの優先度の高低に関わらず、優先度が最も高いiFCから順に比較しなおす。
いずれかのiFCと合致することなく、全てのiFCについて判定が終了すると(1513:未判定iFCなし)、判定結果に従った着信先アドレス、発信元アドレス、サービス要求内容等(S3)をセッション制御部14に送出し、セッション制御部14およびSIP信号制御部13は、端末装置4あるいは他CSCF−A(不図示)に呼確立要求信号を送信する。なお、判定結果に従った着信先アドレス、発信元アドレス、サービス要求内容等(S3)は、接続されたAS3のCSCF接続処理により、当該AS3の提供サービスに則った呼確立要求信号に含まれるものである。
また、ループ判定処理152において、AS接続処理回数を取得し(1521)、AS接続処理回数が規定数以上の場合(1522:規定数以上)、判定部15は、ループ事象が発生していると判定し、ループが発生していることを通知するためのループ発生情報(S4)をセッション制御部14に送出する。これにより、セッション制御部14は、ループ検出後処理を行う。ループ検出後処理としては、例えば呼切断処理、または、ループが発生したことを通知し、ASの設定について確認するよう促すためのガイダンスを、システム管理者の端末装置に送出をすることなどが考えられる。
ここで、ループ判定処理152を設けている理由は、AS3から送信された当該AS3の提供サービスに則った呼確立要求信号を受信すると、本実施形態では呼確立要求信号の信号情報とiFCとを優先度が最も高いから順に比較しなおすため、AS3の提供サービスによっては、ループが発生する可能性があるためである。具体例については、図5を用いて後述する。
ループの検出方法としては、図3に示すように、AS接続処理を行う呼確立要求信号の中にAS接続処理回数が判別可能な情報を含めるようにし、AS接続処理回数が規定数以上になった時点でループ事象が発生したとみなす方法がある。
この方法の場合、実際にループとなる呼か否かに関わらず、AS接続処理の回数を制限することになる。そのため、ASサービスの実現に必要なAS接続処理回数と、ループ事象発生時にシステムに与える処理負荷の影響とを考慮して、AS接続処理回数の最大値(規定数)を決定する必要がある。
AS接続処理回数の最大値を決定する際の自由度を確保するため、AS接続処理を行う呼確立要求信号の中に含めるAS接続処理回数の情報は、AS接続処理回数を判別する目的のために使用する値を信号のヘッダ、あるいはパラメタに含める方法が好ましい。この場合、ループ判定処理152において、AS接続処理回数が規定数未満の場合(1522:規定数未満)、判定部15は、AS接続処理回数に「1」加算(または「1」減算)するなどして、AS接続処理回数を更新する。そして、更新後のAS接続処理回数は、接続先AS情報(S2)とともにSIP信号制御部13およびセッション制御部14に送信され、AS接続処理の呼確立要求信号に含まれてASに送信される。そして、更新後のAS接続処理回数は、接続されたAS3のCSCF接続処理による呼確立要求信号に含まれて送信され、判定部15は、当該呼確立要求信号に含まれるAS接続処理回数を取得する(1521)。
また、システムの処理負荷耐性に余裕があり、かつASがProxyとして処理を行うタイプのASである場合は、例えば、RFC3261(SIP)に規定のMax-Forwardヘッダ値の減算機構(デフォルト値70から始まり、ノードを通過するたびに1ずつ減算されていき、0になった時点で呼確立要求信号が破棄される)を、AS接続処理回数の情報として用いることも可能である。
また、他のループ検出方法として、AS接続処理を行う一連の呼を識別する識別子を呼確立要求信号に含め、CSCFの判定部15が当該識別子を監視し、同一識別子の通過回数(出現回数)が規定数以上になった時点でループ事象が発生したとみなす方法が考えられる。
AS接続処理を行う一連の呼を識別する識別子は、セッション制御部14などが設定する3GPP TS23.218に規定のODI(Original Dialog Identifier)を用いる方法を用いてもよいし、独自の信号拡張による識別子を用いてもよい。
さらに、他のループ検出方法として、AS接続処理を行う度に、当該AS接続処理の呼確立要求信号に含まれる、AS接続処理を行う一連の呼を識別する識別子と、着信先アドレスと、発信元アドレスとを1組(1レコード)としてCSCF−A1の識別子記憶部(不図示)に記憶し、当該識別子記憶部に記憶されたいずれかの組(レコード)の識別子、着信先アドレスおよび発信元アドレスと一致する呼確立要求信号が通過(検出)する場合に、ループが発生したとみなす方法がある。この方法で用いる識別子は、前述のODIを用いる方法でもよいし、独自の信号拡張を行う方法でもよい。
ループ検出後処理の方法としては、図3に示したように、AS3の設定について確認するよう促すガイダンスを送出するものがある。また、他のループ検出後処理方法としては、呼を切断するものがある。
なお、ループ検出処理およびループ検出後処理は、AS接続処理によりCSCFからASへ呼接続要求信号を送信する前に実施するか、あるいはCSCF接続処理によりASからCSCFが呼接続要求信号を受信した後に実施してもよい。
図4は、CSCF−A1の判定部15の具体的な処理例(ループなし)を説明するための図である。ここでは、iFC蓄積部12に蓄積された各iFCは次のとおりとする。またループ判定処理は、ASアクセス回数が規定数以上になったことでループが発生したとみなすものとする。
優先度1:iFC 01(接続先AS#1 3a)着信先アドレスが0800番号(0800−123456)である場合にAS#1 3aに接続する処理を行う。AS#1 3a の提供サービスは0800番号を0AB〜Jに変換するものである。
優先度2:iFC 02(接続先AS#2 3b)着信先アドレスが0120番号(0120−234567)である場合にAS#2 3bに接続する処理を行う。AS#2 3bの提供サービスは0120番号を0800番号に変換するものである。
優先度3:iFC 03(接続先AS#3 3c)発信元アドレスおよびサービス要求内容等が合致した場合にAS#3 3cに接続する処理を行う。
優先度4:iFC 04(接続先AS#4 3d)発信元アドレスおよびサービス要求内容等が合致した場合にAS#4 3dに接続する処理を行う。
優先度5:iFC 05(接続先AS#5 3e)発信元アドレスおよびサービス要求内容等が合致した場合にAS#5 3eに接続する処理を行う。
図4に示す判定部15の処理は、端末装置4から送信された呼確立要求信号の着信先アドレス(ここでは0120−234567とする)、発信元アドレスおよびサービス要求内容をもとに行われる。ただし、ここでは着信先アドレスと合致するiFCは存在するが、発信元アドレスおよびサービス要求内容等と合致するiFCは存在しないものとして説明する。
まず、判定部15は、セッション制御部14から、端末装置4から送信された呼確立要求信号の着信先アドレス(0120−234567)、発信元アドレス、サービス要求内容等を含む信号情報(S1)を受け付け、これらの信号情報と優先度1のiFC 01とを比較し、合致しないのでスキップする。そして、判定部15は、優先度2のiFC 02と信号情報と比較し、着信先アドレス(0120−234567)が合致するため、ループ処理判定152を行う。ループ処理判定152において、ASアクセス回数が規定数に達しないため(すなわち、ループなしと判定され)、AS#2 3bへの接続先AS情報(S2)をセッション制御部14に送出する(以上の処理は、図4の(1)で示す矢印の流れである。)。
そして、判定部15は、セッション制御部14から、AS#2 3bから送信された呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報(S1A)を受け付ける。この着信先アドレスは、AS#2 3bの提供するサービスにより、0120−234567から0800−123456に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス(0800−123456)と、優先度が最も高いiFC01とを比較し、今度は合致する。そして、ASアクセス回数が規定数に達しないので(すなわち、ループなしと判定され)、AS#1 3aへの接続先AS情報をセッション制御部14に送出する(以上の処理は、図4の(2)で示す矢印の流れである。)。
そして、判定部15は、セッション制御部14から、AS#1 3aから送信された呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報(S1A)を受け付ける。この着信先アドレスは、AS#1 3aの提供するサービスにより、0800−123456から0AB〜J(物理アドレス)に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス(0AB〜J)と優先度が最も高いiFC01とを比較し、今度は合致しないのでスキップし、次に優先度2のiFC 02とを比較し、合致しないのでスキップし、次に優先度3のiFC 03とを比較し、合致しないのでスキップし、次に優先度4のiFC 04と比較し、合致しないのでスキップし、次に優先度5のiFC 05と比較し、合致しないのでスキップする。全てのiFCについて判定が終了すると、判定部15は、判定結果に従った判定後の着信先アドレス(0AB〜J)、発信元アドレスおよびサービス要求内容等(S3)を、セッション制御部14に送出する。なお、この着信先アドレス(0AB〜J)、発信元アドレスおよびサービス要求内容等は、AS#1 3aから送信された呼確立要求信号の信号情報と同じものである(以上の処理は、図4の(3)で示す矢印の流れである。)。
図5は、CSCF−A1の判定部15の具体的な処理例(ループあり)を説明するための図である。ここでは、iFC蓄積部12に蓄積された各iFCは次のとおりとする。またループ判定処理は、ASアクセス回数が規定数以上になったことでループ事象が発生したとみなすものとする。
優先度1:iFC 01(接続先AS#1 3a)着信先アドレスが0800番号(0800−123456)である場合にAS#1 3aに接続する処理を行う。ここでのAS#1 3a の提供サービスは0800番号を0120番号(0120−234567)に変換するものである。
優先度2:iFC 02(接続先AS#2 3b)着信先アドレスが0120番号(0120−234567)である場合にAS#2 3bに接続する処理を行う。AS#2 3bの提供サービスは0120番号を0800番号(0800−123456)に変換するものである。
優先度3:iFC 03(接続先AS#3 3c)発信元アドレスおよびサービス要求内容等が合致した場合にAS#3 3cに接続する処理を行う。
優先度4:iFC 04(接続先AS#4 3d)発信元アドレスおよびサービス要求内容等が合致した場合にAS#4 3dに接続する処理を行う。
優先度5:iFC 05(接続先AS#5 3e)発信元アドレスおよびサービス要求内容等が合致した場合にAS#5 3eに接続する処理を行う。
図5に示す判定部15の処理は、端末装置4から送信された呼確立要求信号の着信先アドレス(ここでは0120−234567とする)、発信元アドレスおよびサービス要求内容をもとに行われる。ただし、ここでは着信先アドレスと合致するiFCは存在するが、発信元アドレスおよびサービス要求内容等と合致するiFCは存在しないものとして説明する。
まず、判定部15は、セッション制御部14から、端末装置4から送信された呼確立要求信号の着信先アドレス(0120−234567)、発信元アドレス、サービス要求内容等を含む信号情報(S1)を受け付け、これらの信号情報と優先度1のiFC 01とを比較し、合致しないのでスキップする。そして、判定部15は、信号情報と優先度2のiFC 02と比較し、着信先アドレス(0120−234567)が合致するため、ループ処理判定152を行う。ループ処理判定152において、ASアクセス回数が規定数に達しないため(すなわち、ループなしと判定され)、AS#2 3bへの接続先AS情報をセッション制御部14に送出する(以上の処理は、図5の(1)で示す矢印の流れである。)。
そして、判定部15は、セッション制御部14から、AS#2 3bから送信された呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報(S1A)を受け付ける。この着信先アドレスは、AS#2 3bの提供するサービスにより、0120−234567から0800−123456に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス(0800−123456)と優先度が最も高いiFC01とを比較し、今度は合致する。そして、ASアクセス回数が規定数に達しないためループなしと判定され、AS#1 3aへの接続先AS情報をセッション制御部14に送出する(以上の処理は、図4で(2)で示す矢印の流れである。)。
そして、判定部15は、セッション制御部14から、AS#1 3aから送信された呼確立要求信号の着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報(S1A)を受け付ける。この着信先アドレスは、AS#1 3aの提供するサービスにより、0800−123456から0120−234567に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス(0120−234567)と優先度が最も高いiFC01とを比較し、今度は合致しないのでスキップする。次に変更後の着信先アドレス(0120−234567)と優先度2のiFC 02とを比較し、今度も合致するためループ処理判定152を行い、ASアクセス回数が規定数に達しないためループなしと判定され、AS#2 3bへの接続先AS情報をセッション制御部14に送出する(以上の処理は、図5の(3)で示す矢印の流れであるが、前述の(1)の流れと同様である。)。
そして、判定部15は、セッション制御部14から、AS#2 3bから送信された呼確立要求信号の着信先アドレス、発信元アドレスおよびサービス要求内容等を含む信号情報(S1A)を受け付ける。この着信先アドレスは、AS#2 3bの提供するサービスにより、0120−234567から0800−123456に変更された変更後の着信先アドレスである。判定部15は、変更後の着信先アドレス(0800−123456)と優先度が最も高いiFC01とを比較し、今度は合致する。そして、ASアクセス回数が規定数に達しないためループなしと判定され、AS#1 3aへの接続先AS情報をセッション制御部14に送出する(以上の処理は、図4で(4)で示す矢印の流れであるが、前述の(2)の流れと同様である。)。
そして、判定部15は、セッション制御部14から、AS#1 3aの提供するサービスにより変更された変更後の着信先アドレス(0120−234567)、発信元アドレスおよびサービス要求内容を含む信号情報(S1A)を受け付ける。
以上の流れにより、同じ動作を何度も繰り返すループ事象が発生し、ASアクセス回数が規定数に達する。これにより、判定部15は、ループ判定処理152においてループありと判定し、ループ発生情報(S4)をセッション制御部14に送出し、セッション制御部14がループ検出後処理を行う。
次に、CSCF−A1の動作について説明する。
[CSCF−A1の動作]
図6は、CSCF−A1の動作の一例を示すフローチャートである。図2の構成において、図3の処理を基本とした図4および図5の処理の流れを説明するものである。なお図6では、図3のiFC判定処理151およびループ判定処理152は簡略化した表現にしている。
CSCF−A1のSIP信号制御部13が、端末装置4から送信される呼確立要求信号を受信し、セッション制御部14に送出する(ステップA1)。セッション制御部14は、呼確立要求信号を解析し、当該信号に含まれる着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報(S1)を判定部15に送出する(ステップA2)。判定部15は、送出された信号情報の発信元アドレスを用いて、サービス契約情報蓄積部11から該当するユーザのサービス契約情報を読み出し(ステップA3)、iFC蓄積部12から該当するユーザが契約する各サービスのiFCを読み出し、該当するユーザのサービス契約情報に対応したiFCを決定する(ステップA4)(以上の処理は、図6で(1)で示す矢印の流れである。)。
そして、判定部15は、ステップA4で決定した各iFCと、ステップA2で送出された信号情報(着信先アドレス、発信元アドレスおよびサービス要求内容等)とを比較し、合致するか否かを判定する(ステップA5)(以上の処理は、図6で(2)で示す矢印の流れである。)。
そして、判定部15は、いずれかのiFCと合致すると判定した場合(ステップA5:YES)、ループが発生していないか否かを判定し(ステップA6)、ループが発生していないと判定した場合は(ステップA6:NO)は、当該iFCで指定されたAS3に接続するための接続先AS情報(S2)をセッション制御部14に送出する。セッション制御部14は、当該AS3に接続するための呼確立要求信号を構成し(組み立て)、SIP信号制御部13に送出する(ステップA7)。SIP信号制御部13は、当該呼確立要求信号をAS3に送信する(ステップA8)(以上の処理は、図6で(3)で示す矢印の流れである。)。
そして、SIP信号制御部13は、AS3から送信される、AS3が提供するサービスに則った呼確立要求信号を受信し、セッション制御部14に送出する(ステップA1)。セッション制御部14は、送出された呼確立要求信号を解析し、当該信号に含まれる着信先アドレス、発信元アドレス、サービス要求内容等を含む信号情報(S1A)を判定部15に送出する(ステップA2)(以上の処理は、図6で(4)で示す矢印の流れである。)。
判定部15は、ステップA4で決定した各iFCと、ステップA2で送出された信号情報とを比較し、合致するか否かを判定する(ステップA5)。そして、合致しないと判定した場合(ステップA5:NO)、判定部15は、未判定のiFC が存在するか否かを判定し(ステップA9)、未判定のiFCについて合致するか否かを判定する(ステップA5)。全ての未判定のiFCについて合致するか否かの判定処理を終了すると(ステップA9:NO)、判定終了後の着信先アドレス、発信元アドレス、サービス要求内容等(S3)を、セッション制御部14に送出する。セッション制御部14は、端末装置4あるいは他CSCF−A(不図示)に接続するための呼確立要求信号を構成し(組み立て)、SIP信号制御部13に送出する(ステップA7)。SIP信号制御部13は、端末装置4あるいは他CSCF−A(不図示)に呼確立要求信号送信する(ステップA8)(以上の処理は、図6で(5)で示す矢印の流れである。)。
また、ステップA6においてループが発生していると判定した場合(ステップA6:YES)、判定部15は、ループ発生情報(S4)をセッション制御部14に送出する。これにより、セッション制御部14は、例えば、所定のガイダンスを端末装置4に送信するための呼確立要求信号号を構成し(組み立て)、SIP信号制御部13に送出する(ステップA7)。SIP信号制御部13は、所定のガイダンスを送出するための呼確立要求信号を送信する(ステップA8)。(以上の処理は、図6で(6)で示す矢印の流れである。)
次に、本実施形態のシステムの動作について説明する。
[システムの動作]
図7は、図1におけるシステムの動作の一例を示すシーケンスチャートである。同図は、端末装置4、CSCF−A1およびAS3の間のシーケンスを示している。
端末装置4が、呼確立要求信号を送信し(ステップB1)、CSCF−A1のSIP信号制御部13が当該呼確立要求信号を受信する(ステップB2)。そして、判定部15が、着信先アドレス、発信元アドレス、サービス要求内容等と、各iFCとを比較し、合致するか否かを判定する(ステップB3)。合致するiFCが存在する場合(ステップB3:YES)、判定部15は、ループが発生しているか否かを判定する(ステップB4)。
ループが発生していない場合(ステップB4:NO)、SIP信号制御部13は、AS3に呼確立要求信号を送信する(ステップB5)。AS3は、呼確立要求信号を受信し、所定のサービスを提供(実行)し、提供したサービスに則った呼確立要求信号をCSCF−A1に送信する(ステップB6)。SIP信号制御部13は、AS3が送信した呼確立要求信号を受信し(ステップB7)、判定部15は、AS3が提供したサービスに則った着信先アドレス、発信元アドレス、サービス要求内容等と、各iFCとを比較する(ステップB3)。このステップB3の比較は、未判定のiFCが存在する場合(ステップB8:YES)、繰り返し行われる。合致するiFCが存在することなく、全てのiFCについてステップB3の比較が終了すると(ステップB8:NO)、判定終了後の着信先アドレス、発信元アドレス、サービス要求内容等を含む呼確立要求信号をSIP信号制御部13が端末装置4あるいは他CSCF−A(不図示)に送信する(ステップB9)。
また、ステップB4において、ループが発生していると判断された場合(ステップB4:YES)、SIP信号制御部13は端末装置4に所定のガイダンスを送出するための呼確立要求信号を送信する(ステップB10)。
なお、図7の中では呼確立要求信号の例としてINVITEメソッドを記載しているが、呼確立要求信号はMESSAGEメソッド等を含むSIP信号である。
以上説明した本実施形態のCSCF−A1では、呼確立要求信号の信号情報(着信先アドレス、発信元アドレス、サービス要求内容等)と各iFC (接続条件)とを、優先度の高い順番に条件に合致するか否かを判定し、合致した場合は、ループ事象が発生していないことを確認してAS接続処理を行い、ASのCSCF接続処理によりAS3から送信された呼確立要求信号を受信すると、先に合致したiFCの優先度の高低に関わらず、呼確立要求信号の信号情報とiFCとを優先度の最も高いiFCから順番に比較し、合致するか否かを判定する。
すなわち、ASのCSCF接続処理によりASからCSCFが受信した呼接続要求信号については、判定済みiFCについてもiFC判定対象に含め、先に合致したiFCの優先度の高低に関わらず、ASから送信された呼確立要求信号の内容とiFCとを優先度の最も高いiFCから順番に比較し、合致するか否かを判定する。
これにより、本実施形態では、CSCF側の優先度の設定方法と、AS側のサービス提供の仕方(仕様)とが整合していない場合であっても、呼損となることを回避することができる。そのため、CSCF側とAS側とでは、それぞれ独自に優先度や提供の仕方を決定することができる。すなわち、CSCF側では、着信先アドレス、発信元アドレスおよびサービス要求内容を考慮することなく、iFC蓄積部12に蓄積される各iFCの優先度を自由に設定することができ、設定した優先度に従って判定処理を行うことができる。
また、判定済みiFCについてもiFC判定対象に含めることにより、ASのサービス提供内容によっては、ループ事象が発生する場合が考えられることため、ループ事象の検出処理、およびループを防止するループ検出後処理を行う。これにより、ループ事象の発生を確実に防止することができる。
なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。例えば、上記実施形態のCSCF−A1では、判定部15は、呼確立要求信号の内容とiFCとを優先度の最も高いiFCから順番に比較し、いずれかのiFCと合致する場合、ループ判定処理を行うこととした(図3:ループ判定処理152)。しかしながら、本発明はこれに限定されることなく、例えば、AS側でループするような呼確立要求信号をCSCFに送信しない仕様とすることなどにより、ループ判定処理を行うことなく、AS接続処理を行うこととしてもよい。
1 :CSCF−A
11:サービス契約情報蓄積部
12:iFC蓄積部
13:SIP信号制御部
14:セッション制御部
15:判定部
3 :AS
4 :端末装置

Claims (7)

  1. 呼セッション制御方法であって、
    呼セッション制御サーバは、
    複数のサービスの各々の接続条件が優先度とともに記憶された記憶部を、有し、
    端末またはアプリケーションサーバから送信される呼確立要求信号を受信し、当該呼確立要求信号の信号情報と、前記記憶部に記憶された各接続条件とを、既に合致した接続条件の優先度に関わらず優先度の最も高い接続条件から順番に前記信号情報と接続条件とが合致するまで比較する判定ステップと、
    前記判定ステップにおいて、いずれかの接続条件と合致した場合、前記信号情報と合致した接続条件に設定されたアプリケーションサーバへ接続するサーバ接続ステップと、を行うこと
    を特徴とする呼セッション制御方法。
  2. 請求項1記載の呼セッション制御方法であって、
    前記判定ステップにおいて、いずれかの接続条件と合致した場合、ループ事象が発生しているか否かを判定するループ判定ステップを、さらに行うこと
    を特徴とする呼セッション制御方法。
  3. 請求項2記載の呼セッション制御方法であって、
    前記呼確立要求信号には、前記サーバ接続ステップを行った回数が判別可能な接続回数が含まれ、
    前記ループ判定ステップは、前記呼確立要求信号に含まれる接続回数を取得し、当該接続回数が所定の値以上の場合に、ループ事象が発生したと判別すること
    を特徴とする呼セッション制御方法。
  4. 請求項2記載の呼セッション制御方法であって、
    前記呼確立要求信号には、呼を識別する呼識別子が含まれ、
    前記ループ判定ステップは、前記判定ステップで受信する前記呼確立要求信号の呼識別子を監視し、同一の呼識別子が所定の回数以上出現した場合に、ループ事象が発生したと判別すること
    を特徴とする呼セッション制御方法。
  5. 請求項2記載の呼セッション制御方法であって、
    前記呼確立要求信号には、呼を識別する呼識別子が含まれ、
    前記ループ判定ステップは、サーバ接続ステップで前記アプリケーションサーバに接続するために生成された呼確立要求信号に含まれる識別子、着信先アドレス、および発信元アドレスを対応付けて識別子記憶部に記憶し、前記判定ステップで受信した前記呼確立要求信号の識別子、着信先アドレス、および発信元アドレスが、前記識別子記憶部に記憶された識別子、着信先アドレス、および発信元アドレスと一致する場合、ループ事象が発生したと判別すること
    を特徴とする呼セッション制御方法。
  6. 請求項2から請求項4のいずれか1項に記載の呼セッション制御方法であって、
    ループ事象が発生したと判定された場合、所定のガイダンスを送出する、または、呼を切断するループ検出後処理ステップを行うこと
    を特徴とする呼セッション制御方法。
  7. 呼セッション制御サーバであって、
    複数のサービスの各々の接続条件が優先度とともに記憶された記憶手段と、
    端末またはアプリケーションサーバから送信される呼確立要求信号を受信し、当該呼確立要求信号の信号情報と、前記記憶手段に記憶された各接続条件とを、既に合致した接続条件の優先度に関わらず優先度の最も高い接続条件から順番に前記信号情報と接続条件とが合致するまで比較する判定手段と、
    前記信号情報といずれかの接続条件とが合致した場合、ループ事象が発生しているか否かを判定するループ判定手段と、
    ループ事象が発生していないと判定された場合、前記信号情報と合致した接続条件に設定されたアプリケーションサーバへ接続するサーバ接続手段と、
    ループ事象が発生したと判定された場合、所定のガイダンスを送出する、または、呼を切断するループ検出後処理手段と、を有すること
    を特徴とする呼セッション制御サーバ。
JP2010128765A 2010-06-04 2010-06-04 呼セッション制御方法、および呼セッション制御サーバ Active JP5194056B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010128765A JP5194056B2 (ja) 2010-06-04 2010-06-04 呼セッション制御方法、および呼セッション制御サーバ

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010128765A JP5194056B2 (ja) 2010-06-04 2010-06-04 呼セッション制御方法、および呼セッション制御サーバ

Publications (2)

Publication Number Publication Date
JP2011254423A JP2011254423A (ja) 2011-12-15
JP5194056B2 true JP5194056B2 (ja) 2013-05-08

Family

ID=45417949

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010128765A Active JP5194056B2 (ja) 2010-06-04 2010-06-04 呼セッション制御方法、および呼セッション制御サーバ

Country Status (1)

Country Link
JP (1) JP5194056B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5961519B2 (ja) * 2012-10-10 2016-08-02 株式会社Nttドコモ 呼制御装置、呼制御方法、呼制御プログラム
JP6423327B2 (ja) * 2015-08-13 2018-11-14 日本電信電話株式会社 呼処理サーバおよび呼処理方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1886456B1 (en) * 2005-05-27 2008-10-22 Telefonaktiebolaget LM Ericsson (publ) Call forwarding in an ip multimedia subsystem (ims)
US7877487B2 (en) * 2006-12-29 2011-01-25 Alcatel-Lucent Usa Inc. Dynamic service triggers in communication networks
JP4593579B2 (ja) * 2007-02-28 2010-12-08 日本電信電話株式会社 サービス連携装置、サービス連携システム、サービス連携方法、およびそのコンピュータプログラム
JP2009111732A (ja) * 2007-10-30 2009-05-21 Nippon Telegr & Teleph Corp <Ntt> アプリケーションサーバ連携システム、アプリケーションサーバ連携方法、及びアプリケーションサーバ連携プログラム

Also Published As

Publication number Publication date
JP2011254423A (ja) 2011-12-15

Similar Documents

Publication Publication Date Title
EP2087435B1 (en) Application service invocation
EP2112798B1 (en) Service controlling in a service provisioning system
US8296447B2 (en) Method for copying session information, call control server for executing the same, and computer product
JP5765745B2 (ja) カンバセーション(conversation)中の複数の通信のモダリティ(modalities)の伝送
US8364827B2 (en) Communication system
JP5716795B2 (ja) サービス制御装置、サービス制御システム及び方法
JP2008104112A (ja) 送信経路設定装置、送信経路設定方法および送信経路設定プログラム
WO2007068209A1 (fr) Procede, systeme et dispositif d&#39;envoi de messages instantanes ims
US7899058B2 (en) Using a hash value as a pointer to an application class in a communications device
JP5194056B2 (ja) 呼セッション制御方法、および呼セッション制御サーバ
EP1763205A1 (en) Communication system, transfer control method, telephone device used for same, communication device, and program
US8903990B2 (en) IMS performance monitoring
US20190020693A1 (en) Data processing
JP5367477B2 (ja) サービス提供システムおよびサービス提供方法
KR101813276B1 (ko) 범용 플러그앤플레이 텔레포니 서비스에서 파일 전송을 위한 시스템 및 방법
KR101763854B1 (ko) 범용 플러그 앤 플레이 텔레포니 서비스에서 세션 정보를 저장하는 방법 및 시스템
US20180375901A1 (en) Method of communication between a calling terminal and a plurality of called terminals
JP5272027B2 (ja) 呼制御方法、および呼制御システム
JP6340972B2 (ja) 通信課金システムおよび通信課金方法
US20150350452A1 (en) Method and system for managing dropped call operations
US20140143314A1 (en) Communication system
JP2017147489A (ja) 通信制御システム、通信制御方法、通信制御プログラム、および、通信制御装置
JP2013172409A (ja) 呼制御システム及び呼制御方法
JP2012034044A (ja) 通信制御方法及びアプリケーションサーバ及び通信制御プログラム

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120524

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120529

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120726

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130129

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130204

R150 Certificate of patent or registration of utility model

Ref document number: 5194056

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160208

Year of fee payment: 3

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350