(57)【要約】【課題】特定の通信方式に対応していない端末にサービスを提供でき、かつ、サービスに係るネットワークリソースを減らすことができるＳＩＰアプリケーションサーバ、ＳＩＰサービス処理方法及びプログラムを提供する。【解決手段】ネットワークに接続された端末間の呼接続に関するサービスを提供するアプリケーションサーバ１は、外部アプリケーションサーバ２からサービスの開始要求を受け付けるＡＮＩ受付部１１と、通信方式毎に優先度を記憶する方式選択情報記憶部１５と、方式選択情報記憶部１５を参照し、優先度に応じて通信方式を選択し、当該通信方式で前記サービスを試行して、試行に成功したか否かに応じて当該通信方式を選択する方式選択機能部１２と、方式選択機能部１２により選択された通信方式を用いて端末にサービスを提供する方式別呼処理部１３と、を備える。【選択図】図２
2010056632.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された端末間の呼接続に関するサービスを提供するＳＩＰアプリケーションサーバであって、
外部アプリケーションサーバから前記サービスの開始要求を受け付ける受付部と、
通信方式毎に優先度を記憶する方式選択情報記憶部と、
前記方式選択情報記憶部を参照し、優先度に応じて通信方式を選択し、当該通信方式で前記サービスを試行して、試行に成功したか否かに応じて当該通信方式を選択する方式選択機能部と、
前記方式選択機能部により選択された通信方式を用いて前記端末に前記サービスを提供する方式別呼処理部と、
を備えることを特徴とするＳＩＰアプリケーションサーバ。
【請求項２】
前記方式選択情報記憶部は、相互に移行可能な通信方式のグループ及びグループ内の試行順序を更に記憶し、
前記方式選択機能部は、
優先度の最も高い通信方式が属するグループを選択し、
当該グループ内で最も試行順序が早い通信方式で前記サービスを試行し、
前記サービスの試行に成功すると、当該グループ内でより優先度の高い通信方式がなくなるまで、次に試行順序が早い通信方式に移行して前記サービスを試行し、
前記サービスの試行に失敗すると、次に優先度が高い通信方式が属するグループを選択する
ことを特徴とする請求項１に記載のＳＩＰアプリケーションサーバ。
【請求項３】
端末毎に過去に接続可能であった通信方式を記憶する端末能力記憶部を備え、
前記方式選択機能部は、前記端末能力記憶部を参照し、前記端末に接続可能であった通信方式が記憶されている場合には、当該通信方式を選択し、前記端末に通信可能であった通信方式が記憶されていない場合には、前記サービスの試行が成功した通信方式を前記端末の接続可能であった通信方式として前記端末能力記憶部に記憶させる
ことを特徴とする請求項１または２に記載のＳＩＰアプリケーションサーバ。
【請求項４】
ネットワークに接続された端末間の呼接続に関するサービスを提供するＳＩＰアプリケーションサーバが、外部アプリケーションサーバから前記サービスの開始要求を受け付けるステップと、
前記ＳＩＰアプリケーションサーバが、予め記憶された優先度に応じて通信方式を選択し、当該通信方式で前記サービスを試行して、試行に成功したか否かに応じて当該通信方式を選択するステップと、
前記ＳＩＰアプリケーションサーバが、前記選択された通信方式を用いて前記端末に前記サービスを提供するステップと、
を有することを特徴とするＳＩＰサービス処理方法。
【請求項５】
ネットワークに接続された端末間の呼接続に関するサービスを提供するコンピュータに、
外部アプリケーションサーバから前記サービスの開始要求を受け付けるステップと、
予め記憶された優先度に応じて通信方式を選択し、当該通信方式で前記サービスを試行して、試行に成功したか否かに応じて当該通信方式を選択するステップと、
前記選択された通信方式を用いて前記端末に前記サービスを提供するステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＩＰアプリケーションサーバ、ＳＩＰサービス処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来から、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）網を介してＩＭＳ（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）やＮＧＮ（Ｎｅｘｔ  Ｇｅｎｅｒａｔｉｏｎ  Ｎｅｔｗｏｒｋ）などのサービスを提供するＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）アプリケーションサーバが知られている。このようなアプリケーションサーバのうち、サービスを利用するための外部ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）であるＡＮＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ−Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ）を提供しているものがある。このとき、アプリケーションサーバは、ＡＮＩに対応するサービスを特定の通信方式で固定的に提供していた。
そのため、その通信方式に対応していない端末からはそのサービスを利用できない、という問題があった。
【０００３】
その問題に対し、特許文献１に記載の技術では、アプリケーションサーバが、サービス要求を受信すると、サービスを利用する端末から端末環境情報を取得する。そして、アプリケーションサーバは、端末環境情報に基づいて、サービスを行うプログラムを実行してサービス結果を端末に送信するか、端末にサービスを行うプログラムを送信してそのプログラムを実行させるかを決定する。サービスを行うプログラムは、端末上で実行することで、端末をサービスの通信方式に対応させることができる。このため、サービスの通信方式に対応していない端末からもサービスを利用することができる。
【０００４】
また、特許文献２に記載の技術では、端末と当該端末に対応するアプリケーションサーバを予めドメイン名サーバに登録している。そして、アプリケーションサーバは、端末に対応するアプリケーションサーバをドメイン名サーバに問い合わせて、端末へ応答すべきアプリケーションサーバを決定している。このため、例えば、ドメイン名サーバに端末の通信方式に対応するアプリケーションサーバを登録しておくことで、サービスを提供できる端末を増やすことができる。
【特許文献１】特開２００４−１３９５０４号公報
【特許文献２】特開２００４−２４０８６３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１に記載の技術では、サービス要求毎に端末から端末環境情報を取得しなければならないため、サービス要求回数が多い場合、或いは端末環境情報のサイズが大きい場合には、通信量が増大してしまうという問題がある。また、通信方式が固定されているため、簡易な通信方式で十分な端末に対しても複雑な手順で接続する場合があった。
また、特許文献２に記載の技術では、予め端末とアプリケーションサーバの対応関係をドメイン名サーバに登録する必要があるため、登録されていない端末には対応できない、という問題がある。また、事前に対応関係を登録する手間がかかるという問題がある。
【０００６】
本発明は上記の点に鑑みてなされたものであり、その目的は、特定の通信方式に対応していない端末にサービスを提供でき、かつ、サービスに係るネットワークリソースを減らすことができるＳＩＰアプリケーションサーバ、ＳＩＰサービス処理方法及びプログラムを提供することにある。
【課題を解決するための手段】
【０００７】
本発明は上記の課題を解決するためになされたものであり、本発明の一態様は、ネットワークに接続された端末間の呼接続に関するサービスを提供するＳＩＰアプリケーションサーバであって、外部アプリケーションサーバから前記サービスの開始要求を受け付ける受付部と、通信方式毎に優先度を記憶する方式選択情報記憶部と、前記方式選択情報記憶部を参照し、優先度に応じて通信方式を選択し、当該通信方式で前記サービスを試行して、試行に成功したか否かに応じて当該通信方式を選択する方式選択機能部と、前記方式選択機能部により選択された通信方式を用いて前記端末に前記サービスを提供する方式別呼処理部と、を備えることを特徴とするＳＩＰアプリケーションサーバある。
【０００８】
この発明によれば、優先度に応じて通信方式を選択し、選択した通信方式でサービスを試行して、試行に成功したか否かに応じて当該通信方式でサービスを提供するか否かを決定する。これにより、各端末が対応した通信方式でサービスを提供することができる。このため、特定の通信方式に対応していない端末にサービスを提供することができる。また、優先度をネットワークリソース量に基づいて決定することにより、端末が対応する通信方式の中でよりネットワークリソースの消費が少ない通信方式を選択することができる。これにより、サービスに係るネットワークリソースを減らすことができる。
【０００９】
また、本発明の一態様は、上記のＳＩＰアプリケーションサーバにおいて、前記方式選択情報記憶部は、相互に移行可能な通信方式のグループ及びグループ内の試行順序を更に記憶し、前記方式選択機能部は、優先度の最も高い通信方式が属するグループを選択し、当該グループ内で最も試行順序が早い通信方式で前記サービスを試行し、前記サービスの試行に成功すると、当該グループ内でより優先度の高い通信方式がなくなるまで、次に試行順序が早い通信方式に移行して前記サービスを試行し、前記サービスの試行に失敗すると、次に優先度が高い通信方式が属するグループを選択することを特徴とする。
【００１０】
この発明の目的は、端末へサービスを開始するまでの時間を短縮することにある。この発明によれば、移行可能なグループ内では試行順序が早い通信方式から順に試行する。これにより、例えば、より多くの端末が対応できる通信方式の試行順序を早くすることにより、端末へサービスを開始するまでの時間を短縮することができる。
【００１１】
また、本発明の一態様は、上記のＳＩＰアプリケーションサーバにおいて、端末毎に過去に接続可能であった通信方式を記憶する端末能力記憶部を備え、前記方式選択機能部は、前記端末能力記憶部を参照し、前記端末に接続可能であった通信方式が記憶されている場合には、当該通信方式を選択し、前記端末に通信可能であった通信方式が記憶されていない場合には、前記サービスの試行が成功した通信方式を前記端末の接続可能であった通信方式として前記端末能力記憶部に記憶させることを特徴とする。
【００１２】
この発明によれば、過去に接続可能であった通信方式を記憶するので、１度通信を行った端末に対してサービスを試行する必要がない。このため、サービスに係る通信量を減らすことができる。
【００１３】
また、本発明の一態様は、ネットワークに接続された端末間の呼接続に関するサービスを提供するＳＩＰアプリケーションサーバが、外部アプリケーションサーバから前記サービスの開始要求を受け付けるステップと、前記ＳＩＰアプリケーションサーバが、予め記憶された優先度に応じて通信方式を選択し、当該通信方式で前記サービスを試行して、試行に成功したか否かに応じて当該通信方式を選択するステップと、前記ＳＩＰアプリケーションサーバが、前記選択された通信方式を用いて前記端末に前記サービスを提供するステップと、を有することを特徴とするＳＩＰサービス処理方法である。
【００１４】
また、本発明の一態様は、ネットワークに接続された端末間の呼接続に関するサービスを提供するコンピュータに、外部アプリケーションサーバから前記サービスの開始要求を受け付けるステップと、予め記憶された優先度に応じて通信方式を選択し、当該通信方式で前記サービスを試行して、試行に成功したか否かに応じて当該通信方式を選択するステップと、前記選択された通信方式を用いて前記端末に前記サービスを提供するステップと、を実行させるためのプログラムである。
【発明の効果】
【００１５】
本発明によれば、優先度に応じて通信方式を選択し、選択した通信方式でサービスを試行して、試行に成功したか否かに応じて当該通信方式でサービスを提供するか否かを決定する。これにより、特定の通信方式に対応していない端末にサービスを提供することができる。また、優先度をネットワークリソース量に基づいて決定することにより、端末が対応する通信方式の中でよりネットワークリソースの消費が少ない通信方式を選択することができる。これにより、サービスに係るネットワークリソースを減らすことができる。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照しながら本発明の実施形態について詳しく説明する。
［第１の実施形態］
図１は、本発明の実施形態によるアプリケーションサーバ１（ＳＩＰアプリケーションサーバ）が提供するサービスの一例を示す概略図である。
アプリケーションサーバ１は、ＩＰ網上でＩＭＳやＮＧＮなどのサービスを提供するサーバ装置である。本実施形態では、アプリケーションサーバ１は、ＳＩＰによる呼接続に関するサービスを端末に提供する。また、アプリケーションサーバ１は、サービスを利用するためのＡＮＩを提供している。ＡＮＩとは、通信サービス向けのＡＰＩである。外部アプリケーションサーバ２は、アプリケーションサーバ１とは別の事業者が提供するアプリケーションサーバである。外部アプリケーションサーバ２は、アプリケーションサーバ１が提供しているＡＮＩを利用することにより、アプリケーションサーバ１と連携してサービスを提供する。
【００１７】
発端末３は、ＣＳＣＦ（Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）５を介して発呼する端末である。着端末４は、ＣＳＣＦ６を介して着信する端末である。ＣＳＣＦ５及び６は、ＳＩＰによる呼制御のセッション制御、管理、認証、ルーティング等を行う装置である。
アプリケーションサーバ１と外部アプリケーション２はインターネットを介して接続されている。また、アプリケーションサーバ１とＣＳＣＦ５，６はＩＭＳ網を介して接続されている。また、アプリケーションサーバ１は、発端末３及び着端末４に通話サービスに係る制御パケットを送信して発端末３と着端末４の通話を制御する。また、発端末３と着端末４は、音声パケットを送受信して通話を行う。
【００１８】
図２は、本実施形態におけるアプリケーションサーバ１の構成を示すブロック図である。
アプリケーションサーバ１は、ＡＮＩ受付部１１と、方式選択機能部１２と、方式別呼処理部１３と、ＳＩＰ−ＩＦ部１４と、方式選択情報記憶部１５と、を含んで構成される。
ＡＮＩ受付部１１は、外部アプリケーションサーバ２からサービスの開始要求を受け付ける。具体的には、ＡＮＩ受付部１１は、サービスを利用するためのＡＮＩに基づいたメッセージのデータを受信する。外部アプリケーションサーバ２とＡＮＩ受付部１１間のインタフェースはＡＮＩである。
方式選択機能部１２は、方式選択情報記憶部１５を参照して、複数の通信方式からサービスを利用する端末に適した通信方式を選択する。方式選択機能部１２の処理の詳細は後述する。
方式別呼処理部１３は、方式選択機能部１２で選択された通信方式を用いて端末にサービスを提供する。方式別呼処理部１３は、複数の通信方式を実行可能であり、方式Ａ機能部１３Ａと、方式Ｂ機能部１３Ｂと、方式Ｃ機能部１３Ｃと、を含んで構成される。方式Ａ機能部１３Ａは、通信方式Ａで通信処理する。方式Ｂ機能部１３Ｂは、通信方式Ｂで通信処理する。方式Ｃ機能部１３Ｃは、通信方式Ｃで通信処理する。本実施形態では、通信方式ＡはＵＮＩ−ＲＥＦＥＲ方式、通信方式Ｂは３ＰＣＣ方式、通信方式Ｃはメディアブリッジ方式である。なお、本実施形態では、方式別呼処理部１３が実行可能な通信方式数は３であるが、上述のものに限られることはなく、２以上の通信方式が実行可能であればよい。
方式選択情報記憶部１５は、方式別呼処理部１３が実行可能な通信方式の優先度、非対応端末、方式グループ及び方式グループ内の試行順序を記憶している。また、方式選択情報記憶部１５は、メディアサーバの端末番号を設定情報として予め記憶している。ここで、メディアサーバとは、映像・音声などのメディアを接続した端末に対して提供するサーバ装置である。また、端末番号とは、端末を一意に識別するための番号である。
ＳＩＰ−ＩＦ部１４は、ＣＳＣＦ５，６とデータのやり取りを行う。ＳＩＰ−ＩＦ部１４とＣＳＣＦ５，６間のインタフェースはＳＩＰである。
【００１９】
図３は、本実施形態における各通信方式を説明するための概略図である。
ＵＮＩ−ＲＥＦＥＲ方式は他の通信方式に比べてネットワークリソースの消費が小さい通信方式である。ネットワークリソースとは、例えばサーバリソース（セッション数）及び転送帯域消費（ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）数）である。ＵＮＩ−ＲＥＦＥＲ方式におけるセッション数は１セッション、ＲＴＰ数は１本である。また、ＵＮＩ−ＲＥＦＥＲ方式では、各端末が自律的に接続先に接続する。このため、ＵＮＩ−ＲＥＦＥＲ方式で通信を行う場合には、アプリケーションサーバ１は、接続先を切り替えるサービスを提供することができない。また、ＵＮＩ−ＲＥＦＥＲ方式に対応可能な端末は、接続先切り替えを指示するＲＥＦＥＲメッセージに対応した端末である。
３ＰＣＣ方式はＵＮＩ−ＲＥＦＥＲ方式の次にネットワークリソースの消費が小さい通信方式である。３ＰＣＣ方式におけるセッション数は２セッション、ＲＴＰ数は１本である。また、３ＰＣＣ方式に対応可能な端末は、接続先の更新を指示するＵＰＤＡＴＥ又はｒｅ−ＩＮＶＩＴＥメッセージに対応した端末である。
メディアブリッジ方式は、アプリケーションサーバ１で音声パケットを中継する通信方式である。そのためメディアブリッジ方式は他の通信方式に比べてネットワークリソースの消費が大きい通信方式である。メディアブリッジ方式におけるセッション数は２セッション、ＲＴＰ数は２本である。また、メディアブリッジ方式に対応している端末は、ＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）に対応可能な端末である。このため、３ＰＣＣ方式で接続可能な端末はメディアブリッジ方式で接続可能である。。
なお、３ＰＣＣ方式とメディアブリッジ方式は互いに移行可能である。つまり、アプリケーションサーバ１は、呼の途中で３ＰＣＣ方式からメディアブリッジ方式に切り替えて通信することが可能である。同様に、アプリケーションサーバ１は、呼の途中でメディアブリッジ方式から３ＰＣＣ方式に切り替えて通信することが可能である。
【００２０】
各通信方式には優先度が設定されている。本実施形態では、ネットワークリソース消費の小さい方式ほど優先度が高い。このため、ＵＮＩ−ＲＥＦＥＲ方式、３ＰＣＣ方式、メディアブリッジ方式の順に優先度が高い。また、相互に移行可能な通信方式は１つの方式グループに属する。このため、３ＰＣＣ方式とメディアブリッジ方式が１つの方式グループに属する。また、方式グループ内では試行順序が予め定まっている。本実施形態では、対応端末が多い方式ほど試行順序が早い。メディアブリッジ方式で接続可能な端末は３ＰＣＣ方式で接続可能である。よって、メディアブリッジ方式の方が３ＰＣＣ方式に比べて対応端末が多い。このため、メディアブリッジ方式の試行順序が３ＰＣＣ方式より先である。
【００２１】
図４は、本実施形態における方式選択情報記憶部１５が記憶するテーブルのデータ構造及びデータ例を示す概略図である。
図示するように、このテーブルは、行と列からなる２次元の表形式のデータであり、通信方式と、優先度と、方式グループと、試行順序と、非対応端末と、の各項目の列を有している。このテーブルの各行は通信方式毎に存在する。優先度は、通信方式のネットワークリソースに関する優先度を表わす。ここで、番号が小さいほど優先度が高い。方式グループは、通信方式が属する方式グループの識別番号である。試行順序は、方式グループ内での試行順序を表わす。ここで、番号が小さいほど試行順序が早い。非対応端末は、通信方式が対応していない端末を表わす。
【００２２】
図に示す例では、ＵＮＩ−ＲＥＦＥＲ方式の優先度は「１」、方式グループは「１」、試行順序は「１」、非対応端末は「メディアサーバ」である。ここで、発端末３又は着端末４がメディアサーバである場合には、通話途中で各端末の接続先が切り替わる場合がある。ＵＮＩ−ＲＥＦＥＲ方式は、端末の接続先を容易に切り替えることができない通信方式である。このため、メディアサーバを非対応端末に設定する。また、３ＰＣＣ方式の優先度は「２」、方式グループは「２」、試行順序は「２」、非対応端末はなしである。また、メディアブリッジ方式の優先度は「３」、方式グループは「２」、試行順序は「１」、非対応端末はなしである。
【００２３】
方式選択機能部１２は、方式選択情報記憶部１５が記憶するテーブルを参照して通信方式を選択する。その具体的な手順を以下に示す。選択候補は方式選択情報記憶部１５に記憶されている全ての通信方式である。また、以下の処理は、ＡＮＩ受付部１１から方式選択機能部１２に発端末３及び着端末４の端末番号が入力されるとスタートする。
（１）方式選択情報記憶部１５を参照し、発端末３と着端末４のいずれか一方が非対応端末である通信方式を選択候補から除外する。
（２）方式選択情報記憶部１５を参照し、選択候補の中で優先度が最も高い通信方式が属する方式グループを選択する。
（３）選択した方式グループ内で試行順序が最も早い通信方式でサービスを試行する。そして、発端末３及び着端末４から成功を示すメッセージが返信された場合に、試行に成功したと判定する。一方、発端末３と着端末４のいずれかからエラーを示すメッセージが返信された場合には、試行に失敗したと判定する。
（４）試行に成功すると、試行に成功した通信方式の方式グループ以外の選択候補を除外する。
（５）残っている選択候補の中に、試行に成功した通信方式より優先度の高い通信方式がなければ、試行に成功した通信方式を選択する。
（６）残っている選択候補の中に、試行に成功した通信方式より優先度の高い通信方式があれば、（２）に戻る。
（７）試行が失敗すると、試行した通信方式を選択候補から除外して（２）に戻る。
（８）全ての通信方式が選択候補から除外された場合は、通信サービスの提供を中止する。
【００２４】
つまり、方式選択機能部１２は、方式選択情報記憶部１５を参照し、優先度に応じて通信方式を選択し、当該通信方式で前記サービスを試行して、試行に成功したか否かに応じて当該通信方式を選択する。また、方式選択機能部１２は、優先度の最も高い通信方式が属するグループを選択し、当該グループ内で最も試行順序が早い通信方式で前記サービスを試行し、サービスの試行に成功すると、当該グループ内でより優先度の高い通信方式がなくなるまで、次に試行順序が早い通信方式に移行して前記サービスを試行し、サービスの試行に失敗すると、次に優先度が高い通信方式が属するグループを選択する。
【００２５】
次に、図５を参照して、図４に示すデータ例に基づいて上述した手順を行った場合について説明する。図５は、本実施形態における方式選択機能部１２の処理の手順を示すフローチャートである。
まず、ステップＳ１では、方式選択機能部１２は、発端末３又は着端末４がメディアサーバか否かを判定する。発端末３又は着端末４がメディアサーバである場合には、ステップＳ４へ進む。つまり、非対応端末がメディアサーバであるＵＮＩ−ＲＥＦＥＲ方式を選択候補から除外する。一方、発端末３と着端末４のいずれもがメディアサーバでない場合には、ステップＳ２へ進む。
【００２６】
ステップＳ２では、方式選択機能部１２は、ＵＮＩ−ＲＥＦＥＲ方式でサービスを試行する。これは、ＵＮＩ−ＲＥＦＥＲ方式が最も優先度が高いためである。ここで、ＲＥＦＥＲメッセージに対応した端末のみＵＮＩ−ＲＥＦＥＲ方式に対応可能である。そのため、方式選択機能部１２は、ＲＥＦＥＲメッセージを発端末３に送信して、成功を示すメッセージが端末から返信された場合にＵＮＩ−ＲＥＦＥＲ方式でサービスの試行が成功したと判定する。一方、方式選択機能部１２は、それ以外の場合はＵＮＩ−ＲＥＦＥＲ方式でサービスの試行が失敗したと判定する。ＵＮＩ−ＲＥＦＥＲ方式でサービスの試行が成功した場合は、ステップＳ３へ進む。一方、ＵＮＩ−ＲＥＦＥＲ方式でサービスの試行が失敗した場合には、ステップＳ４に進む。
ステップＳ３では、方式選択機能部１２は、ＵＮＩ−ＲＥＦＥＲ方式でサービスを提供することを決定する。
【００２７】
一方、ステップＳ４では、方式選択機能部１２は、メディアブリッジ方式でサービスを試行する。これは、メディアブリッジ方式がＵＮＩ−ＲＥＦＥＲ方式の次に優先度の高い３ＰＣＣ方式が属する方式グループ内で最も試行順序が高いためである。なお、このとき、方式選択機能部１２は、音声パケットを中継するメディアブリッジを予約するが、それに失敗した場合にはサービス提供の処理を中止する。
【００２８】
次に、ステップＳ５では、方式選択機能部１２は、３ＰＣＣ方式に移行してサービスを試行する。ここで、ＵＰＤＡＴＥ又はｒｅ−ＩＮＶＩＴＥメッセージに対応した端末のみ３ＰＣＣ方式で接続可能である。そのため、方式選択機能部１２は、発端末３及び着端末４にＵＰＤＡＴＥメッセージを送信して、成功を示すメッセージが発端末３及び着端末４から返信された場合に３ＰＣＣ方式でサービスの試行が成功したと判定する。一方、方式選択機能部１２は、それ以外の場合は３ＰＣＣ方式でサービスの試行に失敗したと判定する。３ＰＣＣ方式でサービスの試行に成功した場合には、ステップＳ６へ進む。一方、３ＰＣＣ方式でサービスの試行に失敗した場合には、ステップＳ７へ進む。
【００２９】
ステップＳ６では、方式選択機能部１２は、メディアブリッジ方式から３ＰＣＣ方式に移行してサービスを提供することを決定する。
ステップＳ７では、方式選択機能部１２は、メディアブリッジ方式のままサービスを提供することを決定する。
【００３０】
次に、図６から図９を参照して、上述した本実施形態のアプリケーションサーバ１の動作を説明する。図６及び図７は、本実施形態におけるアプリケーションサーバ１が外部アプリケーションサーバ２からｍａｋｅＣａｌｌＳｅｓｓｉｏｎを含むメッセージ（ｍａｋｅＣａｌｌＳｅｓｓｉｏｎメッセージ）を受信した際の手順を示すシーケンス図である。ｍａｋｅＣａｌｌＳｅｓｓｉｏｎは、通信サービス向けＡＰＩ（ＡＮＩ）共通仕様であるＰａｒｌａｙ−Ｘで定義されているＡＮＩの１つである。ｍａｋｅＣａｌｌＳｅｓｓｉｏｎメッセージには、サービスの呼を確立する発端末３と着端末４が指定されている。
【００３１】
まず、外部アプリケーションサーバ２がｍａｋｅＣａｌｌＳｅｓｓｉｏｎメッセージをアプリケーションサーバ１に対して送信する（ステップＳ１０１）。アプリケーションサーバ１は、当該ｍａｋｅＣａｌｌＳｅｓｓｉｏｎメッセージに対応するサービスの識別番号を外部アプリケーションサーバ２に対して返信する（ステップＳ１０２）。
そして、アプリケーションサーバ１は、ＵＮＩ−ＲＥＦＥＲ方式でサービスを試行する。つまり、アプリケーションサーバ１は、ＲＥＦＥＲメッセージを発端末３に対して送信する（ステップＳ１０３）。本例では、発端末３はＲＥＦＥＲメッセージに対応していない。このため、発端末３は、エラーを示すメッセージをアプリケーションサーバ１に対して返信する（ステップＳ１０４）。
【００３２】
アプリケーションサーバ１は、エラーメッセージを受信すると、ＵＮＩ−ＲＥＦＥＲ方式でサービスの試行が失敗したと判定して、メディアブリッジ方式でサービスを試行する。具体的には、まず、アプリケーションサーバ１は通話を開始するためのＩＮＶＩＴＥメッセージを発端末３に対して送信する（ステップＳ１０５）。すると、発端末３は、呼び出し中であることを示す１８０応答メッセージをアプリケーションサーバ１に対して返信し（ステップＳ１０６）、続いて成功したことを示す２００応答メッセージをアプリケーションサーバ１に対して返信する（ステップＳ１０７）。アプリケーションサーバ１は、２００応答メッセージを受信すると、受信確認であるＡＣＫメッセージを発端末３に対して返信する（ステップＳ１０８）。
【００３３】
次に、アプリケーションサーバ１は、着端末４に対してＩＮＶＩＴＥメッセージを送信する（ステップＳ１０９）。すると、着端末４は、１８０応答メッセージ及び２００応答メッセージをアプリケーションサーバ１に対して返信する（ステップＳ１２０，Ｓ１２１）。アプリケーションサーバ１は、２００応答メッセージを受信すると、ＡＣＫメッセージを着端末４に対して返信する（ステップＳ１２２）。これにより、メディアブリッジ方式で発端末３と着端末４が通話を開始する。
【００３４】
次に、アプリケーションサーバ１は、通信方式を３ＰＣＣ方式に切り替えるために、ＵＰＤＡＴＥメッセージを発端末３に対して送信する（ステップＳ１２３）。本例では、発端末３はＵＰＤＡＴＥメッセージに対応していない。このため、発端末３は、エラーを示すメッセージをアプリケーションサーバ１に対して返信する（ステップＳ１２４）。アプリケーションサーバ１は、エラーメッセージを受信すると、３ＰＣＣ方式に移行不可であると判定してメディアブリッジ方式のまま発端末３と着端末４の通話を継続する。
【００３５】
図８及び図９は、本実施形態におけるアプリケーションサーバ１が外部アプリケーションサーバ２にｈａｎｄｌｅＣａｌｌｅｄＮｕｍｂｅｒを含むメッセージ（ｈａｎｄｌｅＣａｌｌｅｄＮｕｍｂｅｒメッセージ）を送信する際の手順を示すシーケンス図である。ｈａｎｄｌｅＣａｌｌｅｄＮｕｍｂｅｒは、Ｐａｒｌａｙ−Ｘで定義されているＡＮＩの１つである。
【００３６】
まず、外部アプリケーションサーバ２が、アプリケーションサーバ１に対してｓｔａｒｔＣａｌｌＤｉｒｅｃｔｉｏｎＮｏｔｉｆｉｃａｔｉｏｎメッセージを送信して、サービスに使用する番号Ｘを通知する（ステップＳ２０１）。アプリケーションサーバ１は空のメッセージを外部アプリケーションサーバ２に対して返信する（ステップＳ２０２）。これにより、アプリケーションサーバ１は、番号Ｘ宛に通話開始の要求が到着した場合に、外部アプリケーションサーバ２に番号Ｘに対して通話要求が到着したことを通知することができる。
【００３７】
発端末３は、着端末４と通話を開始する際、アプリケーションサーバ１に対してＩＮＶＩＴＥメッセージを送信する（ステップＳ２０３）。このとき、発端末３は、ＩＮＶＩＴＥメッセージに通話先の番号Ｘを含める。アプリケーションサーバ１は、ｈａｎｄｌｅＣａｌｌｅｄＮｕｍｂｅｒメッセージを利用して外部アプリケーソンサーバ２に対して番号Ａから番号Ｘに通話要求がきたことを通知する（ステップＳ２０４）。すると、外部アプリケーションサーバ２は、転送先である着端末４の番号Ｂをアプリケーションサーバ１に対して返信する（ステップＳ２０５）。
次に、アプリケーションサーバ１は、受信したＩＮＶＩＴＥメッセージの返信として２００応答メッセージを発端末３に対して送信する（ステップＳ２０６）。発端末３は、ＡＣＫメッセージをアプリケーションサーバ１に対して返信する（ステップＳ２０７）。
【００３８】
次に、アプリケーションサーバ１は、ＵＮＩ−ＲＥＦＥＲ方式でサービスを試行する。つまり、アプリケーションサーバ１は、ＲＥＦＥＲメッセージを発端末３に対して送信する（ステップＳ２０８）。本例では、発端末３はＲＥＦＥＲメッセージに対応していない。このため、発端末３は、エラーを示すメッセージをアプリケーションサーバ１に対して送信する（ステップＳ２０９）。
【００３９】
アプリケーションサーバ１は、エラーメッセージを受信すると、ＵＮＩ−ＲＥＦＥＲ方式でサービスの試行が失敗したと判定して、メディアブリッジ方式でサービスを試行する。具体的には、まず、アプリケーションサーバ１はＩＮＶＩＴＥメッセージを着端末４に送信する（ステップＳ２１０）。すると、着端末４は、アプリケーションサーバ１に対して１８０応答メッセージを送信する（ステップＳ２１１）。アプリケーションサーバは、その１８０応答メッセージを発端末３に転送する（ステップＳ２１２）。着端末４は、通話可能になると、２００応答メッセージをアプリケーションサーバ１に対して送信する（ステップＳ２１３）。アプリケーションサーバ１は、その２００応答メッセージを発端末３に転送する（ステップＳ２１４）。すると、発端末３は、ＡＣＫメッセージをアプリケーションサーバ１に対して送信する（ステップＳ２１５）。アプリケーションサーバは、着端末４にそのＡＣＫメッセージを転送する（ステップＳ２１６）。
これにより、メディアブリッジ方式で発端末３と着端末４が通話を開始する。
【００４０】
次に、アプリケーションサーバ１は、通信方式を３ＰＣＣ方式に切り替えるために、ＵＰＤＡＴＥメッセージを発端末３に対して送信する（ステップＳ２１７）。本例では、発端末３はＵＰＤＡＴＥメッセージに対応していない。このため、発端末３は、エラーを示すメッセージをアプリケーションサーバ１に対して返信する（ステップ２１７）。アプリケーションサーバ１は、エラーメッセージを受信すると、３ＰＣＣ方式に移行不可であると判定してメディアブリッジ方式のまま発端末３と着端末４の通話を継続する。
【００４１】
このように、本実施形態によれば、優先度の高い通信方式から順にサービスを試行して、試行に成功した通信方式でサービスを提供する。これにより、各端末が対応した通信方式でサービスを提供することができる。このため、特定の通信方式に対応していない端末にサービスを提供することができる。また、ネットワークリソース量に関する優先度の高い通信方式から順にサービスを試行するので、端末が対応する通信方式の中でよりネットワークリソースの消費が少ない通信方式を選択することができる。これにより、サービスに係るネットワークリソースを減らすことができる。
また、ネットワークリソースを効率的に利用できるため、アプリケーションサーバ１を運用する事業者は、ネットワークに配置すべきリソースを少なくすることができる。
また、アプリケーションサーバ１が提供するＡＮＩの利用者（本実施形態では外部アプリケーションサーバ２）は、接続方式を意識せずにＡＮＩを利用することができる。
【００４２】
［第２の実施形態］
次に、この発明の第２の実施形態によるアプリケーションサーバについて説明する。
図１０は、本実施形態におけるアプリケーションサーバ８の構成を示すブロック図である。本実施形態におけるアプリケーションサーバ８は、図２に示す構成に対して端末能力記憶部８６を新たに設けている。端末能力記憶部８６は、端末毎に過去に接続可能であった通信方式を記憶する。
本実施形態における方式選択機能部８２は、端末能力記憶部８６を参照し、端末に接続可能であった通信方式を選択する。また、方式選択機能部８２は、端末能力記憶部８６に端末の情報がない場合には、上述した図５に示す処理を行い、サービスの試行が成功した通信方式を当該端末に接続可能であった通信方式として端末能力記憶部８６に記憶する。
他の構成は第１の実施形態と同様なので、説明を省略する。
【００４３】
図１１は、本実施形態における端末能力記憶部８６に記憶されたテーブルのデータ構造及びデータ例を示す概略図である。
図示するように、このテーブルは、行と列からなる２次元の表形式のデータであり、端末番号と、ＵＮＩ−ＲＥＦＥＲと、３ＰＣＣの各項目の列を有している。このテーブルの各行は端末番号毎に存在する。端末番号は、各端末を識別する識別情報である。ＵＮＩ−ＲＥＦＥＲは、端末がＵＮＩ−ＲＥＦＥＲ方式で接続可能であったか否かを示す。図に示す例では、「○」は接続可能を表わし、「×」は接続不可を表わす。３ＰＣＣは、端末が３ＰＣＣ方式で接続可能であったか否かを示す。図に示す例では、「○」は接続可能を表わし、「×」は接続不可を表わす。
図に示す例では、端末Ａは、ＵＮＩ−ＲＥＦＥＲ方式及び３ＰＣＣ方式いずれも接続可能である。端末Ｂは、ＵＮＩ−ＲＥＦＥＲ方式は接続可能であるが、３ＰＣＣ方式は接続不可である。また、端末Ｃは、ＵＮＩ−ＲＥＦＥＲ方式及び３ＰＣＣ方式いずれも接続不可である。
【００４４】
このように、本実施形態によれば、過去に接続可能であった通信方式を記憶している。このため、１度通信を行った端末に対応している通信方式で試行する必要がなくなる。これにより、より少ない通信量で最適な通信方式を選択することができる。
【００４５】
また、図２に示すアプリケーションサーバ１又は図１０に示すアプリケーションサーバ８の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、通信方式を選択する処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００４６】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。
また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【００４７】
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
例えば、本実施形態では、ＵＮＩ−ＲＥＦＥＲ方式、３ＰＣＣ方式及びメディアブリッジ方式から通信方式を選択したが、他の通信方式から選択してもよい。
【図面の簡単な説明】
【００４８】
【図１】第１の実施形態によるアプリケーションサーバが提供するサービスの一例を示す概略図である。
【図２】本実施形態におけるアプリケーションサーバの構成を示すブロック図である。
【図３】本実施形態における各通信方式を説明するための概略図である。
【図４】本実施形態における方式選択情報記憶部に記憶されたテーブルのデータ構造及びデータ例を示す概略図である。
【図５】本実施形態における方式選択機能部の処理の手順を示すフローチャートである。
【図６】本実施形態におけるアプリケーションサーバの手順を示すシーケンス図である。
【図７】本実施形態におけるアプリケーションサーバの手順を示すシーケンス図である。
【図８】本実施形態におけるアプリケーションサーバの手順を示すシーケンス図である。
【図９】本実施形態におけるアプリケーションサーバの手順を示すシーケンス図である。
【図１０】第２の実施形態におけるアプリケーションサーバの構成を示すブロック図である。
【図１１】本実施形態における端末能力記憶部に記憶されたテーブルのデータ構造及びデータ例を示す概略図である。
【符号の説明】
【００４９】
１，８…アプリケーションサーバ  ２…外部アプリケーションサーバ  ３…発端末  ４…着端末  ５，６…ＣＳＣＦ  １１，８１…ＡＮＩ受付部  １２，８２…方式選択機能部  １３，８３…方式別呼処理部  １３ａ，８３ａ…通信機能部  １３Ａ，８３Ａ…方式Ａ機能部  １３Ｂ，８３Ｂ…方式Ｂ機能部  １３Ｃ，８３Ｃ…方式Ｃ機能部  １４，８４…ＳＩＰ−ＩＦ部  １５，８５…方式選択情報記憶部  ８６…端末能力記憶部
【図１】
2010056632.tif 000003
【図２】
2010056632.tif 000004
【図３】
2010056632.tif 000005
【図４】
2010056632.tif 000006
【図５】
2010056632.tif 000007
【図６】
2010056632.tif 000008
【図７】
2010056632.tif 000009
【図８】
2010056632.tif 000010
【図９】
2010056632.tif 000011
【図１０】
2010056632.tif 000012
【図１１】
2010056632.tif 000013