JP2010183480A - リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラム - Google Patents
リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラム Download PDFInfo
- Publication number
- JP2010183480A JP2010183480A JP2009027087A JP2009027087A JP2010183480A JP 2010183480 A JP2010183480 A JP 2010183480A JP 2009027087 A JP2009027087 A JP 2009027087A JP 2009027087 A JP2009027087 A JP 2009027087A JP 2010183480 A JP2010183480 A JP 2010183480A
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- request
- receiving
- cscf
- unit
- 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.)
- Pending
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】着信側のホーム網に属するSIPサーバの障害によって着信側IMS端末が切断されている状態でも、発信側IMS端末から着信側IMS端末宛の接続要求があると、強制的に着信側IMS端末を再登録し、切断することなくセッションを確立することができる、リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラムを提供することを目的とする。
【解決手段】IP網内のノード132において、発信側端末111から着信側端末112宛のリクエストを処理する方法であって、発信側端末111から着信側端末112宛のリクエストを受信する受信ステップと、着信側端末111側に接続された下流ノード123が障害状況にあるか否かを判定する判定ステップと、判定ステップにおいて障害状況であると判定された場合、発信側端末111に対し、リクエストに対応するための暫定レスポンスを返信する返信ステップとを備える。
【選択図】図1
【解決手段】IP網内のノード132において、発信側端末111から着信側端末112宛のリクエストを処理する方法であって、発信側端末111から着信側端末112宛のリクエストを受信する受信ステップと、着信側端末111側に接続された下流ノード123が障害状況にあるか否かを判定する判定ステップと、判定ステップにおいて障害状況であると判定された場合、発信側端末111に対し、リクエストに対応するための暫定レスポンスを返信する返信ステップとを備える。
【選択図】図1
Description
本発明は、リクエストの送信を制御するリクエスト送信制御装置及びリクエスト送信制御方法、リクエスト送信制御装置を含むシステム、及びリクエスト送信制御装置用のプログラムに関する。
IMS(IP Multimedia Subsystem)には様々なエンティティがある。その中で中核を担う機能がセッション管理機能(CSCF(Call Session Control Function))である。端末から発信されたSIP(Session Initiation Protocol)メッセージは、端末が存在するネットワークにあるP−CSCF(Proxy CSCF)から、ホーム網のS−CSCF(Serving CSCF)に送られ、ホーム網のS−CSCFでメッセージの分析を行う。その結果、S−CSCFは着信側のS−CSCFにSIPメッセージを送信し、通信サービスを提供する。また、S−CSCFはユーザ登録時に加入者プロファイルをHSSからダウンロードすることにより柔軟な呼制御を可能とする。
しかし、着信側のP−CSCFに障害が発生した場合、同じく着信側のS−CSCFは、発信側IMS端末から着信側IMS端末宛のSIPメッセージを受信しても、当該SIPメッセージを着信側P−CSCFに送信することができないため、発信側IMS端末からのリクエストはエラーとなる。同様に、着信側のS−CSCFに障害が発生した場合にも、発信側のS−CSCFは、発信側IMS端末から着信側IMS端末宛のSIPメッセージを受信しても、当該SIPメッセージを着信側S−CSCFに送信することができないため、発信側IMS端末のリクエストはエラーとなる。
上記のように、IMSにおける発信側IMS端末は、着信側のホーム網に属するSIPサーバに障害が生じると、着信側IMS端末への接続要求を切断されてしまうため、再度、接続要求をやり直さなければならないという問題がある。その場合、発信側IMS端末のユーザは、再度、IMSネットワークに着信側IMS端末が登録されるのを待たなければならないことになるが、着信側IMS端末が再登録されたことを発信側IMS端末に知らしめる方法がないという問題がある。
本発明は、このような事情に鑑みてなされたものであって、着信側のホーム網に属するSIPサーバの障害によって着信側IMS端末が切断されている状態でも、発信側IMS端末から着信側IMS端末宛の接続要求があると、強制的に着信側IMS端末を再登録し、切断することなくセッションを確立することができる、リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラムを提供することを目的とする。
上記課題を解決するための本発明に係るリクエスト送信制御装置は、IP網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置であって、前記発信側端末から前記着信側端末宛のリクエストを受信する受信部と、前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部と、前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部とを備える。
上記課題を解決するための本発明に係るリクエスト送信制御方法は、IP網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御方法であって、前記発信側端末から前記着信側端末宛のリクエストを受信する受信ステップと、前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定ステップと、前記判定ステップにおいて前記下流ノードが障害状況であると判定された場合、前記受信ステップにおいて受信された前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信ステップとを備える。
上記課題を解決するための本発明に係るシステムは、IP網においてリクエストを発信する発信側端末と、前記発信側端末からのリクエストを着信する着信側端末と、前記IP網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置とを備えるシステムであって、前記リクエスト送信制御装置は、前記発信側端末から前記着信側端末宛のリクエストを受信する受信部と、前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部と、前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部とを有する。
上記課題を解決するための本発明に係るプログラムは、IP網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置用のプログラムであって、前記リクエスト送信制御装置を、前記発信側端末から前記着信側端末宛のリクエストを受信する受信部、前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部、前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部として機能させる。
本発明によれば、着信側のホーム網に属するSIPサーバの障害によって着信側IMS端末が切断されている状態でも、発信側IMS端末から着信側IMS端末宛の接続要求があると、強制的に着信側IMS端末を再登録し、切断することなくセッションを確立することができる。
以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
図1は、一実施形態に係るリクエスト送信システム100の利用環境の一例を示す。リクエスト送信システム100は、例えば、IMSをベースとする。本実施形態のリクエスト送信システム100は、IMS端末111、112と、P−CSCF121〜123と、S−CSCF131、132と、HSS141とを備える。IMS端末111、112は、IMS端末111を発信側のIMS端末とし、IMS端末112を発信側IMS端末111から着信を受ける着信側IMS端末とする。
P−CSCF121〜123は、発信側のホーム網に属する発信側P−CSCF121と、着信側のホーム網に属する着信側P−CSCF122、123とに分類される。同様に、S−CSCF131、132は、発信側のホーム網に属する発信側S−CSCF131と、着信側のホーム網に属する着信側S−CSCF132とに分類される。HSS141は、IMSで用いるユーザIDの管理、各ユーザの加入しているサービスのプロファイル管理、認証用情報の管理、各IMSサービス利用可否の管理、ユーザ移動管理のためのデータベースである。
発信側IMS端末111は、アクセス・ネットワークを介して発信側P−CSCF121と接続される。発信側P−CSCF121は、同じ発信側のホーム網に属する発信側S−CSCF131と接続される。発信側S−CSCF131は、着信側のホーム網に属する着信側S−CSCF132と接続される。着信側S−CSCF132は、同じ着信側のホーム網に属する着信側P−CSCF122、123と接続される。着信側P−CSCF122、123は、共にアクセス・ネットワークを介して着信側IMS端末112と接続することができる。なお、本実施形態では、着信側IMS端末112は、元々、着信側P−CSCF123と接続されていたが、着信側P−CSCF123の障害発生により、当該着信側P−CSCF123との接続が途絶えている状況を想定する。
図2は、本発明に係るリクエスト送信制御装置を示す機能ブロック図である。リクエスト送信制御装置300は、受信部310と、判定部320と、返信部330と、再登録要求部340と、送信部350とを備える。受信部310は、上流ノードから発信側IMS端末111から着信側IMS端末112宛のリクエストを受信する。判定部320は、着信側IMS端末112側に接続された下流ノードが障害状況にあるか否かを判定する。返信部330は、判定部320が下流ノードを障害状況であると判定した場合、受信部310が受信したリクエストに対応するための暫定レスポンスを、発信側IMS端末111に返信する。
再登録要求部340は、判定部320が障害状態の下流ノード以外の正常状態の下流ノードを確認した場合、当該正常状態の下流ノードを経由して、着信側IMS端末112へIP網への再登録を要求する。送信部350は、着信側IMS端末112がIP網に再登録された場合、受信部310が受信したリクエストを、正常状態の下流ノードを介して着信側IMS端末宛112に送信する。
また、返信部330は、再登録要求部340が着信側端末112へIP網への再登録を要求してから、所定時間内にセッションが確立されない場合、発信側端末111に対し、サーバ・タイムアウト・レスポンスを返信する。なお、本実施形態では、着信側S−CSCF132が本発明に係るリクエスト送信制御装置として機能する。
図3は、図1の実施形態におけるリクエスト処理手順を示すフローチャートである。以下、図3を参照して、本実施形態のIP網内のノードにおけるリクエスト処理手順について説明する。着信側S−CSCF132は、着信側IMS端末方向に接続された着信側P−CSCF122、123に対し、周期的にSIPのOPTIONSリクエストを用いたヘルスチェック信号を送信し、これに対する応答の有無を基に着信側P−CSCF122、123の障害の有無を判定する(S101)。
より詳細には、着信側S−CSCF132は、着信側P−CSCFからの応答があった場合には、そのステータスコードの内容により当該応答のあった着信側P−CSCFの障害の有無を判定する。また、着信側S−CSCF132は、着信側P−CSCFから応答がない場合には、OPTIONSリクエストの再送タイムアウトを以て着信側P−CSCFを障害状態とみなす。
なお、本実施形態の場合、着信側S−CSCF132は、着信側P−CSCF122を正常状態と判定し、着信側P−CSCF123を障害状態と判定したものとする。即ち、着信側IMS端末112は、この時点でIMSから切断されているものとする。そして、着信側S−CSCF132は、このように障害状態の有無を判定した着信側P−CSCF122、123の当該状態の内容について情報登録を行う(S102)。
発信側IMS端末111のユーザが、上記のように、着信側IMS端末112がIMSから切断されていることを知らずに、当該発信側IMS端末111を使用して着信側IMS112端末宛に発信要求を行ったとする。着信側S−CSCF132は、発信側IMS端末111から発信された発信要求を、発信側P−CSCF121、及び発信側S−CSCF131を順に経由して受信する(S103)。
着信側S−CSCF132は、本来この発信要求を着信側P−CSCF123を経由して着信側IMS端末112へ送信しなければならない。しかし、着信側S−CSCF132は、着信側P−CSCF123に障害が発生していると判定しているので、発信側IMS端末111から着信側IMS端末112宛の発信要求を送信せずに、一旦保持する(S104)。この時、着信側S−CSCF132は、発信側IMS端末111がタイムアウトになってしまうのを防止するために、例えば、100 Trying等の暫定応答を返信する。
次に、着信側S−CSCF132は、例えば、優先順位選択方式、ラウンドロビン分散方式、比率分散方式等の方法によって、正常状態の着信側P−CSCFを選択し、当該正常状態の着信側P−CSCFを経由して、強制的に着信側IMS端末112の再登録要求を行う(S105)。本実施形態の場合、着信側S−CSCF132は、着信側P−CSCF122を正常状態の着信側P−CSCFとして選択するものとする。
着信側P−CSCF122は、着信側S−CSCF132から再登録要求を受信すると、HSS141から着信側IMS端末112の加入者プロファイルをダウンロードする。そして、着信側P−CSCF122は、ダウンロードした着信側IMS端末112の加入者プロファイルに登録されているIPアドレスかSIP−URIを用いて、着信側IMS端末112に対し、1st−REGISTER実施命令を行う(S106)。着信側IMS端末112は、着信側P−CSCF122からの1st−REGISTER実施命令を受けて、着信側P−CSCF122経由で1st−REGISTERを実施し、再登録される(S107)。
着信側S−CSCF132は、着信側IMS端末112が再登録されると、保持していた発信側IMS端末111から着信側IMS端末112宛の発信要求を、着信側P−CSCF122経由で着信側IMS端末112へ送信し、セッションを確立する(S108)。また、着信側S−CSCF132は、正常状態の着信側P−CSCFが存在しない等の理由があり、再登録要求を行ってから所定時間経過してもセッションが確立できない場合には、発信側IMS端末111に対し、サーバ・タイムアウト・レスポンスを返信する。
このように、着信側S−CSCF132が、従来の方法にないCSCF機能を発揮することによって、発信側IMS端末111、及び着信側IMS端末112に何ら影響を与えることなくセッションを確立することができる。
図4は、別の実施形態に係るリクエスト送信システム100の利用環境の一例を示す。リクエスト送信システム200は、上記実施形態と同様にIMSをベースとする。また、本実施形態における各CSCFの構成は、上記実施形態の図2を参照して説明したものと同様の構成であるので、詳細な説明を省略する。
本実施形態のIMSは、IMS端末211、212と、P−CSCF221、222と、S−CSCF231〜233と、HSS241とを備える。IMS端末211、212は、IMS端末211を発信側のIMS端末とし、IMS端末212を発信側IMS端末211から着信を受ける着信側IMS端末とする。
P−CSCF221、222は、発信側のホーム網に属する発信側P−CSCF221と、着信側のホーム網に属する着信側P−CSCF222とに分類される。同様に、S−CSCF231〜233は、発信側のホーム網に属する発信側S−CSCF231と、着信側のホーム網に属する着信側S−CSCF232、233とに分類される。HSS241は、IMSで用いるユーザIDの管理、各ユーザの加入しているサービスのプロファイル管理、認証用情報の管理、各IMSサービス利用可否の管理、ユーザ移動管理のためのデータベースである。
発信側IMS端末211は、アクセス・ネットワークを介して発信側P−CSCF221と接続される。発信側P−CSCF221は、同じ発信側のホーム網に属する発信側S−CSCF231と接続される。発信側S−CSCF231は、着信側のホーム網に属する着信側S−CSCF232又は着信側S−CSCF233と接続することができる。本実施形態は、発信側S−CSCF231は、元々、着信側S−CSCF232と接続されていたが、着信側S−CSCF232の障害発生により、当該着信側P−CSCF223との接続が途絶えてしまっているといった状況を想定したものである。着信側S−CSCF232、233は、共に同じ着信側のホーム網に属する着信側P−CSCF222と接続することができる。
本実施形態では、発信側S−CSCF231が本発明に係るリクエスト送信制御装置として機能する場合について説明する。また、着信側S−CSCF232と着信側P−CSCF222との接続が、着信側S−CSCF232の障害発生により途絶えている状況を想定する。着信側P−CSCF222は、アクセス・ネットワークを介して着信側IMS端末212と接続される。
図5は、本発明の第2の実施形態におけるリクエスト処理手順を示すフローチャートである。以下、図5を参照して、本実施形態のIP網内のノードにおけるリクエスト処理手順について説明する。発信側S−CSCF231は、着信側IMS端末方向に接続された着信側S−CSCF232、233に対し、周期的にSIPのOPTIONSリクエストを用いたヘルスチェック信号を送信し、これに対する応答の有無を基に着信側S−CSCF232、233の障害の有無を判定する(S201)。
より詳細には、発信側S−CSCF231は、着信側S−CSCFからの応答があった場合には、そのステータスコードの内容により当該応答のあった着信側S−CSCFの障害の有無を判定する。また、発信側S−CSCF231は、着信側S−CSCFから応答がない場合には、OPTIONSリクエストの再送タイムアウトを以て着信側S−CSCFを障害状態とみなす。
なお、本実施形態の場合、発信側S−CSCF231は、着信側S−CSCF232を障害状態と判定し、着信側S−CSCF233を正常状態と判定したものとする。即ち、発信側IMS端末211から着信側IMS端末212宛の正常なルートは、着信側S−CSCF232の障害により途絶えてしまっているものとする。そして、発信側S−CSCF231は、このように障害状態の有無を判定した着信側P−CSCF232、233の当該状態の内容について情報登録を行う(S202)。
発信側IMS端末211のユーザが、上記のように、着信側IMS端末212宛の正常なルートが切断されていることを知らずに、当該発信側IMS端末211を使用して着信側IMS212端末宛に発信要求を行ったとする。発信側S−CSCF231は、発信側IMS端末211から発信された発信要求を、発信側P−CSCF221を経由して受信する(S203)。
発信側S−CSCF231は、本来この発信要求を着信側S−CSCF232を経由して着信側IMS端末212へ送信しなければならない。しかし、発信側S−CSCF231は、着信側S−CSCF232に障害が発生していると判定しているので、発信側IMS端末211から着信側IMS端末212宛の発信要求を送信せずに、一旦保持する(S204)。この時、発信側S−CSCF231は、発信側IMS端末211がタイムアウトになってしまうのを防止するために、例えば、100 Trying等の暫定応答を返信する。
次に、発信側S−CSCF231は、優先順位選択方式、ラウンドロビン分散方式、又は比率分散方式等の方法によって、正常状態の着信側S−CSCFを選択し、当該正常状態の着信側S−CSCFを経由して、強制的に着信側IMS端末212の再登録要求を行う(S205)。本実施形態の場合、発信側S−CSCF231は、着信側S−CSCF233を正常状態の着信側S−CSCFとして選択するものとする。
着信側S−CSCF233は、着信側S−CSCF232から再登録要求を受信すると、HSS241から着信側IMS端末212の加入者プロファイルをダウンロードする。そして、着信側S−CSCF233は、ダウンロードした着信側IMS端末212の加入者プロファイルに登録されているIPアドレスかSIP−URIを用いて、着信側IMS端末212に対し、1st−REGISTER実施命令を行う(S206)。着信側IMS端末212は、着信側S−CSCF233からの1st−REGISTER実施命令を受けて、着信側P−CSCF222経由で1st−REGISTERを実施し、再登録される(S207)。
発信側S−CSCF231は、着信側IMS端末212が再登録されると、保持していた発信側IMS端末211から着信側IMS端末212宛の発信要求を、着信側S−CSCF233経由で着信側IMS端末212へ送信し、セッションを確立する(S208)。しかし、発信側S−CSCF231は、正常状態の着信側P−CSCFが存在しない等の理由があり、再登録要求を行ってから所定時間経過してもセッションが確立できない場合には、発信側IMS端末211に対し、サーバ・タイムアウト・レスポンスを返信する。
このように、本実施形態においても、発信側S−CSCF231が、従来の方法にないCSCF機能を発揮することによって、発信側IMS端末211、及び着信側IMS端末212に何ら影響を与えることなくセッションを確立することができる。
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。その様な変更または改良を加えた形態も本発明の技術的範囲に含まれることが、特許請求の範囲の記載から明らかである。
例えば、上記の各CSCFは、内部にコンピュータシステムを有している。そして、上記の各CSCFにおける処理の過程は、プログラムの形式でコンピュータ読み取り可能な電子媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な電子媒体とは、磁気テープ、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリ等をいう。また、このプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしてもよい。
100 リクエスト送信システム
111 発信側IMS端末
112 着信側IMS端末
121 発信側P−CSCF
122 着信側P−CSCF
123 着信側P−CSCF
131 発信側S−CSCF
132 着信側S−CSCF
141 HSS
200 リクエスト送信システム
211 発信側IMS端末
212 着信側IMS端末
221 発信側P−CSCF
222 着信側P−CSCF
231 発信側S−CSCF
232 着信側S−CSCF
233 着信側S−CSCF
241 HSS
111 発信側IMS端末
112 着信側IMS端末
121 発信側P−CSCF
122 着信側P−CSCF
123 着信側P−CSCF
131 発信側S−CSCF
132 着信側S−CSCF
141 HSS
200 リクエスト送信システム
211 発信側IMS端末
212 着信側IMS端末
221 発信側P−CSCF
222 着信側P−CSCF
231 発信側S−CSCF
232 着信側S−CSCF
233 着信側S−CSCF
241 HSS
Claims (7)
- IP網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置であって、
前記発信側端末から前記着信側端末宛のリクエストを受信する受信部と、
前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部と、
前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部と
を備えるリクエスト送信制御装置。 - 前記判定部が前記障害状態の下流ノード以外の正常状態の下流ノードを確認した場合、
当該正常状態の下流ノードを経由して、前記着信側端末へIP網への再登録を要求する再登録要求部
をさらに備える請求項1に記載のリクエスト送信制御装置。 - 前記着信側端末がIP網に再登録された場合、
前記受信部が受信した前記リクエストを、前記正常状態の下流ノードを介して前記着信側端末宛に送信する送信部
をさらに備える請求項2に記載のIP網内のノードにおけるリクエスト送信制御装置。 - 前記再登録要求部が前記着信側端末へIP網への再登録を要求してから、所定時間内にセッションが確立されない場合、
前記返信部は、前記発信側端末に対し、サーバ・タイムアウト・レスポンスを返信する
請求項3に記載のIP網内のノードにおけるリクエスト送信制御装置。 - IP網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御方法であって、
前記発信側端末から前記着信側端末宛のリクエストを受信する受信ステップと、
前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定ステップと、
前記判定ステップにおいて前記下流ノードが障害状況であると判定された場合、前記受信ステップにおいて受信された前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信ステップと
を備えるリクエスト送信制御方法。 - IP網においてリクエストを発信する発信側端末と、
前記発信側端末からのリクエストを着信する着信側端末と、
前記IP網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置と
を備えるシステムであって、
前記リクエスト送信制御装置は、
前記発信側端末から前記着信側端末宛のリクエストを受信する受信部と、
前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部と、
前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部と
を有するシステム。 - IP網において発信側端末から着信側端末宛のリクエストを処理するリクエスト送信制御装置用のプログラムであって、前記リクエスト送信制御装置を、
前記発信側端末から前記着信側端末宛のリクエストを受信する受信部、
前記着信側端末側に接続された下流ノードが障害状況にあるか否かを判定する判定部、
前記判定部が前記下流ノードを障害状況であると判定した場合、前記受信部が受信した前記リクエストに対応するための暫定レスポンスを、前記発信側端末に返信する返信部
として機能させるプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009027087A JP2010183480A (ja) | 2009-02-09 | 2009-02-09 | リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009027087A JP2010183480A (ja) | 2009-02-09 | 2009-02-09 | リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2010183480A true JP2010183480A (ja) | 2010-08-19 |
Family
ID=42764630
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009027087A Pending JP2010183480A (ja) | 2009-02-09 | 2009-02-09 | リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2010183480A (ja) |
-
2009
- 2009-02-09 JP JP2009027087A patent/JP2010183480A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8553680B2 (en) | Service controlling in a service provisioning system | |
JP5173607B2 (ja) | 通信システム | |
CA2605475C (en) | Session initiation from application servers in an ip multimedia subsystem | |
EP2104305A1 (en) | Call service handling in an IMS-based system | |
JP2010541348A (ja) | Ipマルチメディア・サブシステム・ネットワークにおける障害回復 | |
US9021300B2 (en) | Method of changing over from a primary HSS to a backup HSS in an IP network | |
JP2009542106A (ja) | ローミング・ネットワークにおけるクライアントの登録をネットワーク・アプリケーションに通知する方法 | |
JP2008153782A (ja) | 呼管理方法、呼管理システム、およびメッセージ処理サーバシステム | |
JP2009219058A (ja) | 呼制御装置、呼制御システム、呼制御方法、及びコンピュータプログラム | |
US20160241601A1 (en) | Technique for restoring a service in a network | |
US11418635B2 (en) | Method of dynamic selection, by a caller, from a plurality of terminals of a callee | |
US20080186956A1 (en) | Method and system for processing call change request in an internet protocol multimedia subsystem | |
EP2200254B1 (en) | Mobile network system and guidance message providing method | |
US8117311B2 (en) | Communication method, server and medium on notification of session status | |
JP2011049687A (ja) | 通信ネットワークシステムとそのsip信号中継方法及びsipアプリケーション・サーバ | |
US8346269B2 (en) | Mobile network system and guidance message providing method | |
US11540209B2 (en) | Method for determining a set of encoding formats in order to establish a communication | |
JP2010525623A (ja) | 通信ネットワークにおいて使用する方法、および、装置 | |
JP2010183480A (ja) | リクエスト送信制御装置、リクエスト送信制御方法、システム、及びプログラム | |
US20180375901A1 (en) | Method of communication between a calling terminal and a plurality of called terminals | |
KR102286082B1 (ko) | 음성호 서비스 전환 시스템, 게이트웨이장치 및 서비스전환장치 그리고 그 장치의 동작 방법 | |
RU2417544C2 (ru) | Способы и устройства для передачи информации о состоянии сигнального соединения, относящейся к сигнальному соединению между терминалом и модулем посреднической функции управления сеансом/вызовом (p-cscf) в мультимедийной подсистеме интернет-протокола (ims) | |
CN102957680A (zh) | 一种实现ims核心网消息转发的系统及方法 | |
KR20070104829A (ko) | Csⅰ서비스를 위해 필요한 정보의 교환 방법 | |
KR20150041991A (ko) | 착신망의 호 처리 기능 장애 처리를 위한 장치, 이를 위한 방법 및 이 방법이 기록된 컴퓨터 판독 가능한 기록매체 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20100716 |