JP5355297B2 - 通信サービス提供方法および通信サービス提供システム - Google Patents
通信サービス提供方法および通信サービス提供システム Download PDFInfo
- Publication number
- JP5355297B2 JP5355297B2 JP2009189465A JP2009189465A JP5355297B2 JP 5355297 B2 JP5355297 B2 JP 5355297B2 JP 2009189465 A JP2009189465 A JP 2009189465A JP 2009189465 A JP2009189465 A JP 2009189465A JP 5355297 B2 JP5355297 B2 JP 5355297B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- component
- terminal
- unit
- service logic
- 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
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Description
例えば、2者間のセッション制御を行う場合、発信者側の端末と着信者側の端末とを接続するセッション制御や、通話中の端末同士の接続を切断するセッション制御のような基本的な制御は、異なる通信サービスにおいても実施される頻度が高い。このため、通信サービス毎にサービスロジックを用意すると、複数のサービスロジック間で基本的な制御が重複して記載される可能性も高い。よって、サービスの数の増大することに伴い、サービスロジックの記載量が増加するため、その中の重複部分も多くなる可能性もより高くなり、効率が悪くなるという問題がある。
図1は、本実施形態に係るサービス提供システムの一例について示す概略図である。
図1に示す通り、通信サービス提供システムは、通信サービス提供サーバ100と、この通信サービス提供サーバ100とネットワークNWを介して接続されている複数の端末200(例えば、201、202、203、・・・、20n)と、メディアサーバ300とを備える。
メディアサーバ300は、音声データ、画像データあるいは動画データ等を記憶しており、通信サービス提供サーバ100を介して接続された端末装置200に対して、記憶しているデータを再生する。
具体的に説明すると、UA機能部120は、UA管理制御部121を備え、複数のUA、例えば、発UA122、着UA123、発用MS−UA124、および着用MS−UA125として機能する。また、UA機能部120は、内部に記憶部126を備える。
また、UA機能部120は、部品機能部130からメッセージを受け取ると、このメッセージに応じたUAのインスタンスを生成する。
また、UA管理制御部121は、複数のUA(発UA122、着UA123、発用MS−UA124、および着用MS−UA125)のそれぞれを識別する固有のUA識別番号と、部品機能部130によって生成される部品のそれぞれを識別するための固有の部品番号とを対応付けて記憶する記憶部126を有している。このUA管理制御部121は、この記憶部126を参照して、複数のUAと複数の部品との間のイベントバスとして、メッセージの送受信を制御する。例えば、UA管理制御部121は、発UA122からメッセージを受信した場合、記憶部126を参照して、発UA122から受信したメッセージを、部品が生成されていないならば、部品管理制御部131に送信する。なお、部品が生成されているか否かが判断され、部品が生成されている場合、UA管理制御部121は、生成されている部品に対してメッセージを送信する。
さらに、UA管理制御部121は、生成されたUAが通信プロトコルスタック110から受けたイベント通知に応じた処理を終了した場合、当該UAのインスタンスを削除する。
このようにして、部品機能部130は、サービスに依存していないメッセージテーブルデータを参照して動作することにより、サービスに依存しないSIP信号レベルでの2者間のセッション制御を行っている。
例えば、特定のサービスにのみ特化しているサービスロジックを利用して、1つの通信サービスに対して、それぞれ、1つの通信サービスを実行するソフトフェアのブロックを必要とする場合、これらのソフトウェアのブロックは、サービスに依存していることとなる。一方、異なる通信サービスに対して、共通して利用可能なソフトウェアのブロックを通信サービスに応じて呼出し、通信サービスを実行する場合、これらのソフトウェアのブロックは、サービスに依存していないこととなる。
部品の種類とは、後述する接続部品P、切断部品Q、ガイダンス再生部品R、発呼部品S、メディア変更部品Tを表わす。また、部品の属性情報とは、例えば、接続部品に関しては接続方法を表わす情報であり、発信側のダイアログを確立することを要する方法( confirmed dialog )であること、あるいは、発信側のダイアログの確立を必要とせずにアーリー状態のままで接続する方法( early dialog )であることを表わす。
また、部品管理制御部131は、生成された部品132とサービスロジック部140との間のイベントバスであって、部品132とサービスロジック部140との間のメッセージの送受信を行う。
さらに、部品管理制御部131は、部品132から処理を終了することを表すメッセージを受け付けた場合、サービスロジック部140へイベント通知を行い、サービスロジック部140のAPI呼出しに応じて当該部品のインスタンスを削除する。
この部品132は、部品毎に予め決められているメッセージテーブルデータを参照して、SIP信号レベルでの2者間のセッション制御を行う。このメッセージテーブルデータは、部品132の制御内容を表わす部品制御情報であって、受信したメッセージに応じて、部品132が送信するメッセージが対応付けられている。
また、部品132は、部品管理制御部131によって生成された際に、制御復帰タイミングが予め決められている場合、この制御復帰タイミングに合わせて、サービスロジック部140に対して制御の復帰を行う。つまり、部品132は、制御復帰タイミングとなると、サービスロジック部140に対してイベント通知を行う。
さらに、部品132は、部品管理制御部131によって生成された際に決められているメッセージ送信先に対してメッセージを送信する。なお、このメッセージ送信先は、部品132の生成を指示するAPI呼出しを部品管理制御部131に行うサービスロジック部140によって決定されるものであり、部品132は、サービスロジック部140によって決定されたメッセージ送信先にメッセージを送信することができる。
つまり、サービスロジック部140は、サービス情報記憶部150を参照して、サービスパターンのプログラムを実行することにより、サービスに依存する通信サービス制御を実現するとともに、サービスに依存せずに通信サービス制御を実行する部品132に対して制御を指示するためのAPI呼出しを行う。
具体的に説明すると、サービスロジック部140は、サービス情報記憶部150を参照して、部品管理制御部131からのイベント通知に基づき、サービスパターンを決定する。また、サービスロジック部140は、決定されたサービスパターンのプログラムを実行する。
ここで、サービスロジックとは、サービスロジック部140によって実行されるサービスパターンのプログラムである。
さらに、サービスロジック部140は、部品132からの制御の復帰待ち状態において、部品管理制御部131を介して部品132からイベント通知を受けると、サービスに依存しているサービスパターンの制御を継続する。これにより、サービスに依存せずに通信サービス制御を実行する部品132から、サービスに依存する通信サービス制御を実行するサービスロジック部140の制御へと切り替わり、制御が復帰される。
さらに、サービスロジック部140は、サービス情報記憶部150に記憶されている情報を参照して、課金サービスやデータ変換等を行う。例えば、発信側の端末201の番号または着信側の端末202の番号に基づき、加入者に応じた課金情報が予め対応付けられている加入者データを参照することで、端末201または端末202に課金される通話代を求めることができる。また、発信側の端末201がダイヤルした番号が論理番号である場合、サービス情報記憶部150を参照して、この論理番号に対応付けられている物理番号を得て、論理番号を物理番号に変換する。
図2に示す通り、部品管理制御部131は、サービスロジック部140から部品生成を表わすAPI呼出しを受けると、このAPI呼出しに応じた部品132を生成する(ステップST1)。言い換えると、部品管理制御部131は、API呼出しに含まれる部品生成に関する情報(例えば、部品の種類、部品の属性、発信側の端末の番号、受信側の端末の番号、制御復帰ポイント等を表わす情報)に応じた部品132のプログラムを起動し、実行する。なお、部品132は、上記部品生成に関する情報を一時的に部品機能部130内の記憶部133に記憶しておく。
これにより、ステップST1で生成された部品132は、サービスロジック部140の部品生成より以前に端末から通信サービス提供サーバ100が受信していたメッセージ(例えば、通信を要求するメッセージ)に対応するメッセージをUA機能部120に送信する。一方、UA機能部120からメッセージを受信した場合、部品132は、このメッセージに対応するメッセージをUA機能部120に送信する。すなわち、部品132は、UA機能部120に対してメッセージの送受信を行う(ステップST2)。
そして、ステップST2において、部品132の生成時にサービスロジック部140から指定された制御復帰ポイントに表わされているメッセージを、UA機能部120から受信した場合、部品132は、復帰タイミングであると判断し(ステップST3−YES)、UA機能部120から受信したメッセージに対応するメッセージをサービスロジック部140にイベント通知する(ステップST4)。そして、部品132は、以降の処理を中断する(ステップST5)。
また、ステップST6において、サービスロジック部140から部品削除の指示を表わすAPI呼出しがあった場合(ステップST6−削除)、部品管理制御部131は、部品132を削除する(ステップST9)。
図3に示す通り、サービスロジック部140は、部品管理制御部131からイベント通知を受けると(ステップST11−YES)、このイベント通知に基づき、サービス情報記憶部150を参照して、サービスパターンを決定する(ステップST12)。
つまり、サービスロジック部140は、このサービスパターンのプログラムに従って、部品132の生成を表わすAPI呼出しを部品管理制御部131に対して行う(ステップST16)。なお、この時、サービスロジック部140は、サービスパターンのプログラムに従い、部品生成に関する情報(例えば、部品の種類、部品の属性、発信側の端末の番号、受信側の端末の番号、制御復帰ポイント等を表わす情報)を作成してAPI呼出しとともに部品管理制御部131に送信する。
そして、部品を継続する場合、部品132の制御処理の継続指示を表わすAPI呼出しを行う(ステップST19)。その後、部品132の終了を表わすイベント通知を受けたか否かを判断し(ステップST20)、受けていない場合、さらにサービスロジック部140への制御復帰が行われるか否かをステップST17に戻って判断する。
そして、サービスパターンのプログラムに従って、サービスロジック部140は、さらに部品の生成があるか否かを判断し(ステップST23)、さらに部品を生成する場合、ステップST16に戻る。
はじめに、図4〜8を用いて、発信者により端末201を介して呼び出された番号を変換するとともに、発信者の端末201と着信者の端末202との2者間のセッションを確立するための基本接続パターンについて説明する。
図4は、この基本接続パターンのメッセージ送受信を表わすイメージ図である。図5は、基本接続パターンにおける状態遷移の一例を示す概略図である。
図4に示す通り、例えば発信者によって番号「0120−aaa−bbb」がダイヤルされると、端末201は、通信サービス提供サーバ100に対して通話(接続)を要求するメッセージを送信する。すると、このメッセージは、通信サービス提供サーバ100の通信プロトコルスタック110によって変換され、発UA122に送信される。そして、発UA122は、通信プロトコルスタック110から送信されたメッセージに基づくイベント通知をUA管理制御部121に行い、次いで、部品管理制御部131がこのイベント通知に対応するイベント通知をサービスロジック部140に行う。
そして、サービスロジック部140は、このイベント通知に基づき、サービス情報記憶部150に記憶されている加入者データを参照して、着信者の端末202の論理番号に対応する物理番号へ番号変換するとともに、サービスパターンを決定する。
物理番号とは、複数の端末の中から当該端末を識別する固有の端末識別情報である。
論理番号とは、物理番号が表わす契約者が特定の通信サービスを受けるため予め決められている番号であって、当該サービスの契約をしている端末を識別する端末識別情報である。ここでは、論理番号は、発信側の端末によってダイヤルされる電話番号であって、メッセージに関連付けられて、発信側の端末から通信サービス提供サーバ100に送信される。
音声ファイルは、サービスパターンにおいて音声データを提供することが含まれている場合、この提供される音声データを表わす情報であって、当該サービスパターンと対応付けられている。なお、この音声ファイルの音声データは、ネットワークを介して接続され、通信サービス提供サーバ100の外部にあるメディアサーバ300に記憶されている。
また、加入者データは、発信者側の端末の電話番号(契約者番号あるいは物理番号)とサービスパターンが対応付けられ、発信者側の端末の電話番号に応じて、サービスパターンが決定されものであってもよい。
例えば、サービスロジック部140は、発信側の端末から自端末を識別するための端末識別情報(例えば、電話番号)が関連付けられた通信サービスの提供を要求するメッセージ(例えば、通話要求)を受信した場合、このメッセージに基づき、この発信側の端末が利用可能な通信サービスのサービスロジックと、当該発信側の端末の端末識別情報とを対応付けた加入者データを記憶するサービス情報記憶部150を参照して、端末識別情報と対応付けられているサービスロジックに従って、通信サービスの提供を開始するものであってもよい。
これにより、サービスロジック部140は、この「基本接続」のプログラムに従って、接続部品Pの部品生成と、切断部品Qの部品生成を行う。なお、この「基本接続」のプログラムには、接続部品Pの部品の生成および削除処理が終了した後、切断部品Qの部品の生成および削除処理を実行することが予め決められている。また、この「基本接続」のプログラムには、接続部品Pの属性情報として、発信側のダイアログを確立することを要する方法( confirmed dialog )が、サービスロジック部140によって決められている。また、接続部品Pの制御復帰ポイントとしては「180メッセージ受信、200_INVITEメッセージ受信、ACKメッセージ受信」が、切断部品Qの制御復帰ポイントとしては、「200_BYEメッセージ受信」が、サービスロジック部140によって決められている。
そして、部品管理制御部131によって接続部品Pが生成され、接続部品Pによって接続処理が実行されると、端末201と端末202とが接続中という状態になる。これにより、接続部品Pの機能が達成されたため、部品管理制御部131は、サービスロジック部140に対して、部品終了のイベント通知を行う(ステップST103)。ここで、接続処理が終了する。続けて、サービスロジック部140は、部品管理制御部131に対して、接続部品Pの削除を表わすAPI呼出しを行う(ステップST104)。これにより、端末201と端末202とが通話状態となる。
この部品管理制御部131によって切断部品Qが生成され、切断部品Qによって切断処理が実行されると、端末201と端末202とが切断中の状態となる。これにより、切断部品Qの機能が達成されたため、部品管理制御部131は、サービスロジック部140に対して、部品終了を表わすイベント通知を行う(ステップST107)。ここで、切断処理が終了する。そして、サービスロジック部140は、部品管理制御部131に対して、切断部品Qの削除を表わすAPI呼出しを行う(ステップST108)。これにより、端末201と端末202の通話に関する状態が全てなくなり、空き状態となる。
図7に示す通り、発信者Aから番号「0120−aaa−bbb」への通話が要求されると、端末201は、INVITE(SDP−A)メッセージを、ネットワークNWを介して通信サービス提供サーバ100に送信する(ステップST110)。すると、INVITE(SDP−A)メッセージを受信した通信サービス提供サーバ100の通信プロトコルスタック110が、このINVITE(SDP−A)メッセージをINVITEメッセージに変換して、部品管理制御部131に送信する(ステップST111)。そして、部品管理制御部131は、着信通知を表わすイベント通知をサービスロジック部140に通知する(ステップST112)。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「接続部品P」、属性情報の接続方法「confired」、制御復帰ポイント「180メッセージ受信、200_INVITEメッセージ受信、ACKメッセージ受信」であるとする。そこで、サービスロジック部140は、この部品の種類と、属性情報と、制御復帰ポイントと、発信側の端末201の番号を発信側番号Aと、着信側の端末202の番号を着信側番号Bとを含む「部品生成に関する情報」を生成し、部品管理制御部131に対して、この部品生成に関する情報を付与したAPI呼出しをする。
これにより、UA機能部120は着UA123に対してAPI呼出しを行い、着UA123は、端末202に対してINVITE(SDP−A)メッセージを送信する(ステップST115)。そして、端末202は、着UA123に100メッセージを送信し(ステップST116)、その後、180メッセージも送信する(ステップST117)。
そして、着UA123は、200_PRACKメッセージを接続部品Pに送信する(ステップST128)。ここで、200_PRACKメッセージの受信も、接続部品Pの制御復帰ポイントとなっていないため、接続部品Pは、200_PRACKメッセージを発UA122に送信する(ステップST129)。この発UA122は、200_PRACKメッセージを端末201に送信する(ステップST130)。
端末202から200_INVITE(SDP−B)メッセージが着UA123に送信されると(ステップST131)、着UA123は、200_INVITEメッセージを接続部品Pに送信する(ステップST132)。
そして、接続部品Pは、端末201から端末202の呼び出しが確立されたことを表わす呼確立通知(B)をサービスロジック部140に送信し(ステップST133)、サービスロジック部140に制御を復帰させる。
また、接続部品Pは、200_INVITEメッセージを発UA122に送信する(ステップST137)。この発UA122は、200_INVITE(SDP−B)メッセージを端末201に送信し(ステップST138)、端末202からACKメッセージを受信する(ステップST139)。次いで、発UA122は、ACKメッセージを接続部品Pに送信する(ステップST140)。
これにより、接続部品Pは、部品終了通知をサービスロジック部140に通知する(ステップST141)。そして、サービスロジック部140は、「基本接続」のプログラムに従い、接続部品Pの削除を決定し、部品削除メッセージを部品管理制御部131に送信する(ステップST142)。これを受けて、部品管理制御部131は、接続部品Pを削除する。
以上によって、端末201と端末202の接続が完了する。
図8に示す通り、端末201と端末202は、通話中となっている。この状態において、端末201が、発UA122に対してBYEメッセージを送信する(ステップST150)。すると、この発UA122が、BYEメッセージを部品管理制御部131に送信するとともに(ステップST151)、端末201に200_BYEメッセージを送信する(ステップST152)。
このBYEメッセージを受信した部品管理制御部131は、切断通知(A)を表わすメッセージをサービスロジック部140に送信する(ステップST153)。なお、このメッセージには、切断を通知した側の端末として端末201を特定する情報(例えば、端末201の番号)が関連付けられている。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「切断部品Q」、制御復帰ポイント「200_BYEメッセージ受信」であるとする。そこで、サービスロジック部140は、サービス情報記憶部150に一次的に記憶されていた「端末201と端末202とが通話状態である」ことを表わす情報を読み出し、ステップST153で受信したメッセージに関連付けられている端末201と特定する情報に基づき、別の端末202を特定する情報を切断する側の端末であることを検出する。
そして、サービスロジック部140は、この部品の種類と、制御復帰ポイントと、切断する側の端末202の番号とを含む「部品生成に関する情報」を生成し、部品管理制御部131に対して、この部品生成に関する情報を付与したAPI呼出しをする。
これにより、UA機能部120は着UA123に対してAPI呼出しを行い、着UA123は、端末202に対してBYEメッセージを送信する(ステップST156)。そして、端末202は、着UA123に200BYEメッセージを送信する(ステップST157)。
そして、着UA123は、UA機能部120を介して200_BYEメッセージを切断部品Qに送信する(ステップST158)。この切断部品Qは、部品終了を表わす部品終了通知をサービスロジック部140に送信し、サービスロジック部140に制御を復帰させる(ステップST159)。
これにより、端末201と端末202とは通話が切断される。
次に、図9〜11を用いて、発信者Aにより端末201を介して呼び出された番号を変換するとともに、発信者Aの端末201と、ガイダンスを再生するメディアサーバ300との2者間のセッションを確立するためのガイダンス接続パターンについて説明する。
図9は、ガイダンス接続パターンにおける状態遷移の一例を示す概略図である。
そして、サービスロジック部140は、このイベント通知に基づき、サービス情報記憶部150に記憶されている加入者データα(図6参照)を参照して、番号を変換するとともに、サービスパターンを決定する。
これにより、サービスロジック部140は、この「ガイダンス接続」のプログラムに従って、接続部品Pの部品生成と、ガイダンス再生部品Rの部品生成と、切断部品Qの部品生成とを行う。なお、この「ガイダンス接続」のプログラムには、接続部品Pの部品の生成および削除処理が終了した後、ガイダンス再生部品Rの部品生成および削除処理を終了し、その後、切断部品Qの部品の生成および削除処理を実行することが予め決められている。また、この「ガイダンス接続」のプログラムには、接続部品Pの属性情報として、発信側のダイアログの確立を必要とせずにアーリー状態のままで接続する方法( early )が、サービスロジック部140によって決められている。また、接続部品Pの制御復帰ポイントとしては「180メッセージ受信、200_INVITEメッセージ受信、ACKメッセージ受信」が、ガイダンス再生部品Rの制御復帰ポイントとしては「200_INFOメッセージ受信」が、切断部品Qの制御復帰ポイントとしては「200_BYEメッセージ受信」が、それぞれ、サービスロジック部140によって決められている。
なお、この接続部品Pは、属性情報を除いて、上述した接続部品Pと同様であるため、詳細な説明は省略する。
そして、部品管理制御部131によって接続部品Pが生成され、接続部品Pによって接続処理が実行されると、端末201とメディアサーバ300とが接続中という状態になる。これにより、接続部品Pの機能が達成されたため、部品管理制御部131は、サービスロジック部140に対して、部品終了を表わすイベント通知を行う(ステップST203)。ここで、接続処理が終了する。
そして、サービスロジック部140は、部品管理制御部131に対して、接続部品Pの削除を表わすAPI呼出しを行うとともに、続けて、ガイダンス再生部品Rの部品生成を表わすAPI呼出しを部品管理制御部131に対して行う(ステップST204)。これにより、端末201とメディアサーバ300とが通話状態となり、メディアサーバ300の音声ファイル「天気予報」の音声を再生することで、端末201に天気予報のガイダンスが流れる。
その後、ガイダンスが終了すると、部品管理制御部131は、サービスロジック部140に対して、部品終了を表わすイベント通知を行う(ステップST205)。
この部品管理制御部131によって切断部品Qが生成され、切断部品Qによって切断処理が実行されると、端末201とメディアサーバ300とが切断中の状態となる。これにより、切断部品Qの機能が達成されたため、部品管理制御部131は、サービスロジック部140に対して、部品終了を表わすイベント通知を行う(ステップST208)。ここで、切断処理が終了する。そして、サービスロジック部140は、部品管理制御部131に対して、切断部品Qの削除を表わすAPI呼出しを行う(ステップST209)。これにより、端末201とメディアサーバ300の通話に関する状態が全てなくなり、空き状態となる。
発UA122は、PRACKメッセージをUA管理制御部121を介して接続部品Pに送信する(ステップST213)。接続部品Pは、PRACKメッセージが制御復帰ポイントではないため、UA管理制御部121を介して着用MS−UA125にPRACKメッセージを送信する(ステップST214)。そして、着用MS−UA125は、メディアサーバ300に対してPRACKメッセージを送信する(ステップST215)。
これにより、接続部品Pが自身の機能を達成したため、部品管理制御部131は、部品終了を表わす通知をサービスロジック部140に送信する(ステップST220)。そして、サービスロジック部140は、「ガイダンス接続」のプログラムに従い、接続部品Pの削除を決定し、部品削除メッセージを部品管理制御部131に送信する(ステップST221)。これを受けて、部品管理制御部131は、接続部品Pを削除する。
以上によって、端末201とメディアサーバ300の接続が完了し、通話中となる。
図11に示す通り、サービスロジック部140は、「ガイダンス接続」のプログラムに従って、ガイダンス再生部品Rを生成する指示をAPI呼出しする(ステップST251)。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「ガイダンス再生部品R」、制御復帰ポイント「200_INFOメッセージ受信」、音声ファイル「天気予報」であるとする。そこで、サービスロジック部140は、この部品の種類と、制御復帰ポイントと、ガイダンス再生側のメディアサーバ300の番号とを含む「部品生成に関する情報」を生成し、部品管理制御部131に対して、この部品生成に関する情報を付与したAPI呼出しをする。
これにより、着用MS−UA125は、メディアサーバ300に対してINFO(発ガイダンス再生指示)メッセージを送信する(ステップST253)。そしてメディアサーバ300は、200_INFOメッセージを着用MS−UA125を介してUA管理制御部121に送信する(ステップST254)。
そして、UA管理制御部121は、200_INFOメッセージをガイダンス再生部品Rに送信すると(ステップST255)、メディアサーバ300が音声ファイル「天気予報」を再生し、ガイダンスを端末201に流す。
以上によって、端末201に対してメディアサーバ300のガイダンス再生が終了する。
そして、この後、図8を用いて説明したように、切断部品Qを作成して削除する処理を行う。
次に、図12〜16を用いて、端末201に対してメディアサーバ300に記憶されているモーニングコールの音声データを再生するため、端末201とメディアサーバ300との2者間のセッションを確立するための網内発呼パターンについて説明する。
図12は、この網内発呼パターンのメッセージ送受信を表わすイメージ図である。
図13に示す通り、サービスロジック部140は、加入者データβに基づき、発呼日時「毎日7:00」に到達したか否かを判断する。そして、発呼日時に到達した場合(ステップST301)、サービスロジック部140は、この発呼日時と対応付けられているサービスパターン「網内発呼(モーニングコール)」をサービスパターンとして決定する。
これにより、サービスロジック部140は、この「網内発呼(モーニングコール)」のプログラムに従って、発呼部品Sの部品生成と、メディア変更部品Tの部品生成と、切断部品Qの部品生成を行う。
なお、この「網内発呼(モーニングコール)」のプログラムには、端末203を呼び出すための発呼部品Sの部品の生成および削除処理と、メディアサーバ300を呼び出すための発呼部品Sの部品の生成および削除処理とが終了した後、メディア変更部品Tの部品の生成および削除処理と、ガイダンス再生部品Rの部品の生成および削除処理とを行い、最後に、切断部品Qの部品の生成および削除処理を実行することが予め決められている。
そして、部品管理制御部131によって発呼部品Sが生成され、発呼部品Sによって呼び出し処理が実行されると、端末203が読み出され、端末203が発呼中となる。すなわち、端末203と通信サービス提供サーバ100とが接続状態となる。
これにより、発呼部品Sの機能が達成されたため、部品管理制御部131は、サービスロジック部140に対して、部品終了のイベント通知を行う(ステップST303)。ここで、呼び出し処理が終了する。
そして、部品管理制御部131によって発呼部品Sが生成され、発呼部品Sによって呼び出し処理が実行されると、メディアサーバ300が読み出され、メディアサーバ300が発呼中となる。すなわち、メディアサーバ300と通信サービス提供サーバ100とが接続状態となる。
これにより、発呼部品Sの機能が達成されたため、部品管理制御部131は、サービスロジック部140に対して、部品終了のイベント通知を行う(ステップST305)。ここで、呼び出し処理が終了する。
これにより、メディア変更部品Tの機能が達成されたため、部品管理制御部131は、サービスロジック部140に対して、メディア変更部品Tの削除を表わすAPI呼出しを行うとともに、続けて、ガイダンス再生部品Rの部品生成を表わすAPI呼出しを部品管理制御部131に対して行う(ステップST308)。これにより、端末203とメディアサーバ300とが通話状態となり、メディアサーバ300の音声ファイル「モーニングコール」の音声を再生することで、端末203にモーニングコールのガイダンスが流れる。
その後、ガイダンスが終了すると、部品管理制御部131は、サービスロジック部140に対して、部品終了を表わすイベント通知を行う(ステップST309)。
あるいは、メディアサーバ300による音声ファイル「モーニング」の音声データの再生時間が終了することによって、ガイダンス再生の終了を表すメッセージが、通信プロトコルスタック110、UA機能部120、および部品機能部130を介してサービスロジック部140に切断通知を表わすメッセージとしてイベント通知されるものであってもよい。
この部品管理制御部131によって切断部品Qが生成され、切断部品Qによって切断処理が実行されると、端末203とメディアサーバ300とが切断中の状態となる。これにより、切断部品Qの機能が達成されたため、部品管理制御部131は、サービスロジック部140に対して、部品終了を表わすイベント通知を行う(ステップST312)。ここで、切断処理が終了する。そして、サービスロジック部140は、部品管理制御部131に対して、切断部品Qの削除を表わすAPI呼出しを行う(ステップST313)。これにより、端末203とメディアサーバ300の通話に関する状態が全てなくなり、空き状態となる。
図15に示す通り、サービスロジック部140は、サービス情報記憶部150に記憶されている加入者データβを参照して、発呼日時に到達したか否かを判断し、発呼日時に到達した場合、サービスパターンとして、「網内発呼(モーニングコール)」を決定する。そして、サービスロジック部140は、この「網内発呼(モーニングコール)」のプログラムに従って、端末203を呼び出すための発呼部品Sの部品生成のAPI呼出しを、部品管理制御部131に対して行う(ステップST321)。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「発呼部品S」、制御復帰ポイント「200_INVITEメッセージ受信、ACKメッセージ受信」であるとする。そこで、サービスロジック部140は、この部品の種類と、制御復帰ポイントと、発信側の端末203の番号を発信側番号Aとを含む「部品生成に関する情報」を生成し、部品管理制御部131に対して、この部品生成に関する情報を付与したAPI呼出しをする。
これにより、UA機能部120は発UA122に対してAPI呼出しを行い、発UA122は、端末203に対してINVITE(SDP−A)メッセージを送信する(ステップST323)。そして、端末203は、発UA122に100メッセージを送信し(ステップST324)、その後、180メッセージも送信する(ステップST325)。
続けて、端末203は、発UA122に200_INVITE(SDP−A)メッセージを送信する(ステップST327)。この発UA122は、200_INVITE(SDP−A)メッセージを発呼部品Sに送信する(ステップST328)。
これにより、発呼部品Sは、部品管理制御部131を介してサービスロジック部140に呼確立通知(A)を行い(ステップST329)、サービスロジック部140に制御を復帰させる。
これにより、発呼部品Sは、部品終了通知をサービスロジック部140に通知する(ステップST333)。そして、サービスロジック部140は、「網内発呼(モーニングコール)」のプログラムに従い、発呼部品Sの削除を決定し、部品削除メッセージを部品管理制御部131に送信する(ステップST334)。これを受けて、部品管理制御部131は、発呼部品Sを削除する。
以上によって、端末203の呼び出しが完了する。
なお、メディアサーバ300を呼び出すための発呼部品Sの生成処理も同様であるため、詳細な説明は省略する。
図16に示す通り、サービスロジック部140は、「網内発呼(モーニングコール)」のプログラムに従って、メディア変更部品Tを生成する指示をAPI呼出しする(ステップST351)。
具体的に説明すると、ここでは、決定されたサービスパターンの部品生成に関する情報が、部品の種類「メディア変更部品T」、制御復帰ポイント「メディアサーバ300からの200_UPDATEメッセージ受信」であるとする。そこで、サービスロジック部140は、この部品の種類と、制御復帰ポイントと、発呼部品Sによって呼び出されている端末203とメディアサーバ300の番号とを含む「部品生成に関する情報」を生成し、部品管理制御部131に対して、この部品生成に関する情報を付与したAPI呼出しをする。
これにより、発UA122は、端末203に対してUPDATE(SDP−B)メッセージを送信する(ステップST353)。そして、端末203は、200_UPDATE(SDP−B)メッセージを発UA122を介してUA管理制御部121に送信する(ステップST354)。
これにより、着用MS−UA125は、メディアサーバ300に対してUPDATE(SDP−A)メッセージを送信する(ステップST357)。そして、メディアサーバ300は、200_UPDATE(SDP−A)メッセージを着用MS−UA125を介してUA管理制御部121に送信する(ステップST358)。
また、部品132は、サービスロジック部140へのイベント通知(部品中断やサービスロジックへの制御復帰)および、サービスロジック部140からのAPI呼出し受信(部品継続(中断していた部品の再開))等を行う。
サービスロジック部140は、このイベント通知を受けて、部品を継続するか、あるいは削除するかを判断する。このサービスロジック部140は、継続する場合、部品管理制御部131に部品継続を表わすAPI呼出しを行い、一方、部品を削除する場合、部品管理制御部131に部品削除を表わすAPI呼出しを行う。
また、部品132は、自身の機能を達成すると、部品終了を表わすイベント通知をサービスロジック部140に行うと、部品132による制御処理が終了中となる。これを受けたサービスロジック部140は、部品削除を表わすAPI呼出しを部品管理制御部131に行う。これにより、当該部品132は、部品管理制御部131によって削除される。
言い換えると、サービスロジック部140によってサービスパターンが決定されると、決定されたサービスパターンのプログラムが実行され、プログラムに従って少なくとも1つの部品が生成され、部品による処理が終了したら、当該部品を削除するようにした。
これにより、サービスロジック部140は、サービスパターンのプログラムを実行することによって、サービスに依存せず、他のサービスとも共通して利用することができる独立のモジュールである部品を実行させることができる。よって、通信サービスの違いに関わらず、共通して利用することができるため、異なる通信サービスにおいて共通する処理は、同じ種類の部品を利用することによって実現することができる。従って、部品に対応する処理をサービスロジック部140を制御するプログラムに全て記載する必要がなく、通信サービスを実行するためのサービスロジックの記載量を低減することができる。
なお、実施形態によらず、サービスロジック部140と部品機能部130とが切り離されていない場合、通信サービスに応じたサービスロジックを、通信サービス毎に作成しなければならない。よって、このサービスロジックには、サービスロジック部140と部品機能部130間で生じるイベント通知とAPI呼出しとを記述し、さらに、部品機能部130とUA管理制御部121との間に生じるイベント通知とAPI呼出しとを記述しなければならなかった。しかし、本実施形態では、サービスロジックには、前者のみを記述すればよく、後者は、部品132ごとのメッセージテーブルデータを用意すればよい。よって、サービス毎に作成されるサービスロジックにおいて、部品132ごとのメッセージテーブルデータに対応する制御の記述が不要となる。
例えば、部品132−1の復帰ポイントでその部品132−1を削除し、削除した後に他の部品132−2の制御処理を起動するようにサービスロジックを作成することによって、既存の部品132の制御処理を変更せずに、部品132の制御処理を部分的に利用することができる。
また、本実施形態によらない場合、SIPサーブレットコンテナ、HTTPサーブレットコンテナ等の従来のアプリケーションサーバ(AS)のソフトウェア構造は、サービス固有の処理(サービスロジック)を記述する部分に信号プロトコルの処理が混在していたため、サービスロジックの状態数が多く、構造の複雑化を招いていた。その結果、サービスロジックの記述量が大きく、それに伴い開発コストの増加/開発期間の長期化が問題であった。
また、Web Servicesから呼制御を行うためのAPIとしてParlay−Xが標準化されている。Parlay−Xと通信プロトコルのゲートウェイも従来のASと同様に、その結果、サービスロジックの記述量が大きく、それに伴い開発コストの増加/開発期間の長期化が問題であった。
また、「コンピュータシステム」は、WWWシステムを利用している場合であれば、ホームページ提供環境(あるいは表示環境)も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ROM、フラッシュメモリ等の書き込み可能な不揮発性メモリ、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
また、上記プログラムは、このプログラムを記憶装置等に記憶したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク(通信網)や電話回線等の通信回線(通信線)のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムに既に記録されているプログラムとの組み合せで実現できるもの、いわゆる差分ファイル(差分プログラム)であっても良い。
110 通信プロトコルスタック
120 UA機能部
121 UA管理制御部
122 発UA
123 着UA
124 発用MS UA
125 着用MS UA
130 部品機能部
131 部品管理制御部
132 部品(サービス非依存機能部)
140 サービスロジック部
150 サービス情報記憶部
Claims (6)
- 少なくとも1つの端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバにおける通信サービス提供方法であって、
前記通信サービス提供サーバのサービスロジック部が、
前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報とともに、前記サービス非依存機能部からの制御復帰のポイントを表わす制御復帰ポイント情報を送信するステップと、
前記通信サービス提供サーバの部品管理制御部が、
前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成させるステップと、
前記通信サービス提供サーバの前記サービス非依存機能部が、
前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行うステップと、
前記通信サービス提供サーバの前記サービス非依存機能部が、
前記部品制御情報に従って前記メッセージの送受信を行っている際に、前記制御復帰ポイント情報が表わす前記制御復帰ポイントとなった場合、前記サービスロジック部に対して制御の復帰を行うためのイベント通知を送信するとともに、前記端末との前記メッセージの送受信を中断するステップと、
前記通信サービス提供サーバのサービスロジック部が、
前記部品生成に関する情報を送信した後の制御の復帰待ち状態において、前記サービス非依存機能部から前記イベント通知を受信した場合、前記サービス非依存機能部による制御を継続するか否かを判断するステップと、
を備えることを特徴とする通信サービス提供方法。 - 前記通信サービス提供サーバのサービスロジック部は、
前記部品生成に関する情報を送信する場合、前記端末の論理番号および前記端末の物理番号のうちの少なくともいずれか一方に応じたサービスパターンを決定し、前記サービスロジックに依存せずに自身の機能を発揮する前記サービス非依存機能部のうち、決定した前記サービスパターンに応じて前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす前記部品生成に関する情報を送信することを特徴とする請求項1に記載の通信サービス提供方法。 - 前記通信サービス提供サーバのサービスロジック部が、
発信側の端末から自端末を識別するための第1の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第1の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第1の端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップと
を備えることを特徴とする請求項1から2のいずれか一項に記載の通信サービス提供方法。 - 前記通信サービス提供サーバのサービスロジック部が、
発信側の端末から、着信側の端末を識別するための第2の端末識別情報が関連付けられた前記通信サービスの提供を要求するメッセージを受信した場合、当該メッセージに基づき、前記第2の端末識別情報と前記発信側の端末が利用可能な通信サービスの前記サービスロジックとを対応付けたサービス利用情報を記憶するサービス情報記憶部を参照して、前記第2端末識別情報と対応付けられている前記サービスロジックに従って、通信サービスの提供を開始するステップと
を備えることを特徴とする請求項1から3のいずれか一項に記載の通信サービス提供方法。 - 前記通信サービス提供サーバのサービスロジック部が、
前記サービスロジックで複数の前記サービス非依存機能部による制御処理の実行が予め決められている場合、前記サービスロジックに従って、複数の前記サービス依存機能部を生成することを特徴とする請求項1から4のいずれか一項に記載の通信サービス提供方法。 - 少なくとも1つの端末と、この端末とネットワークを介して接続されており前記端末に通信サービスを提供する通信サービス提供サーバとを含む通信サービス提供システムであって、
前記通信サービスの制御内容を表わすサービスロジックに従って通信サービスの提供を開始する場合、各通信サービスロジックに依存せずに自身の機能を発揮するサービス非依存機能部のうち前記サービスロジックにおいて予め決められている前記サービス非依存機能部を表わす部品生成に関する情報とともに、前記サービス非依存機能部からの制御復帰のポイントを表わす制御復帰ポイント情報を送信するサービスロジック部と、
前記サービスロジック部から前記部品生成に関する情報を受信すると、当該部品生成に関する情報において表されている前記サービス非依存機能部を生成する部品管理制御部と、
前記部品管理制御部によって生成されると、自サービス非依存機能部の制御内容を表わす部品制御情報に従って、前記端末とメッセージの送受信を行い、前記部品制御情報に従って前記メッセージの送受信を行っている際に、前記制御復帰ポイント情報が表わす前記制御復帰ポイントとなった場合、前記サービスロジック部に対して制御の復帰を行うためのイベント通知を送信するとともに、前記端末との前記メッセージの送受信を中断する前記サービス非依存機能部と、
前記部品生成に関する情報を送信した後の制御の復帰待ち状態において、前記サービス非依存機能部から前記イベント通知を受信した場合、前記サービス非依存機能部による制御を継続するか否かを判断するサービスロジック部と、
を備えることを特徴とする通信サービス提供システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009189465A JP5355297B2 (ja) | 2009-08-18 | 2009-08-18 | 通信サービス提供方法および通信サービス提供システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009189465A JP5355297B2 (ja) | 2009-08-18 | 2009-08-18 | 通信サービス提供方法および通信サービス提供システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2011040000A JP2011040000A (ja) | 2011-02-24 |
JP5355297B2 true JP5355297B2 (ja) | 2013-11-27 |
Family
ID=43767668
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009189465A Active JP5355297B2 (ja) | 2009-08-18 | 2009-08-18 | 通信サービス提供方法および通信サービス提供システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5355297B2 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5519554B2 (ja) * | 2011-02-25 | 2014-06-11 | 日本電信電話株式会社 | 呼制御システムおよび呼制御に利用する情報の冗長化方法 |
JP5896509B2 (ja) * | 2011-07-13 | 2016-03-30 | 日本電信電話株式会社 | クラスタリング通信システム |
JP5715584B2 (ja) * | 2012-02-09 | 2015-05-07 | 日本電信電話株式会社 | Apl−gw−fe |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3058494B2 (ja) * | 1991-11-12 | 2000-07-04 | 富士通株式会社 | 通信網のサービス制御装置 |
JP2000156733A (ja) * | 1998-05-28 | 2000-06-06 | Alcatel Usa Sourcing Lp | Ain/inssp拡張製品 |
JP2001268229A (ja) * | 2000-03-17 | 2001-09-28 | Ntt Comware Corp | 電話サービス装置、電話サービス方法及びその記録媒体 |
-
2009
- 2009-08-18 JP JP2009189465A patent/JP5355297B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2011040000A (ja) | 2011-02-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR100932350B1 (ko) | 비디오 통신 방법, 비디오 통신 시스템, 및 통합 미디어자원 서버 | |
EP1982549B1 (en) | Personalization content sharing system and method | |
US9078239B2 (en) | Caller information provision | |
JP5048127B2 (ja) | マルチメディアカスタマイズされた呼出音およびマルチメディアカスタマイズされた着信音サービスを実装するための方法および装置 | |
JP2000083103A (ja) | 呼び出し信号を交換する通知方法、呼び出し信号を交換する方法およびインタ―ネットイネ―ブルド装置 | |
US20060203802A1 (en) | Method and system for dynamically specifying and instantly transmitting and representing/displaying call data | |
JP2008022584A (ja) | ワイヤレスマルチメディア通信システム及び方法 | |
JP5486055B2 (ja) | テレビ電話のための呼出方法およびシステム | |
KR20080102242A (ko) | 통화 연결음을 사용하여 존재 정보를 제공하는 방법 및 시스템 | |
JP5040171B2 (ja) | 情報処理装置及び接続制御方法並びにプログラム | |
JP2009540754A (ja) | 通信網内の発呼者へのカスタマイズされたマルチメディアグリーティングを配信するための方法 | |
JP3506231B2 (ja) | 着呼者呼び出し方法、通信機器、発呼者情報サーバおよび呼び出し制御装置 | |
JP5355297B2 (ja) | 通信サービス提供方法および通信サービス提供システム | |
CN101009735A (zh) | 通信方法和通信*** | |
JP4834759B2 (ja) | メディアサーバ、セッション復旧方法及びコンピュータプログラム | |
JP2003338871A (ja) | リングバックトーン代替情報提供方法及びシステム | |
WO2004049681A1 (en) | Mobile comunication method and device for playing an audio file at a remote communication device | |
WO2015014174A1 (zh) | 实现回铃播放的方法、装置和回铃业务*** | |
CN100486368C (zh) | 数据提供平台 | |
US7688763B2 (en) | Method for establishing a communication connection in a direct communication network | |
KR100704828B1 (ko) | 발신정보표시 방식의 멀티미디어 콘텐츠 제공 방법 | |
CN1893485B (zh) | 通信网络中多媒体回落方法 | |
KR101002463B1 (ko) | 휴대 단말기의 자체 링백톤 설정 방법 | |
CN100446461C (zh) | 通信终端 | |
KR20060089795A (ko) | 링백톤 방식의 멀티미디어 콘텐츠 제공 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20120919 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20121002 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20121203 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130226 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130430 |
|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20130430 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130529 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20130724 |
|
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: 20130820 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130827 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5355297 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
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 |