JP5004901B2

JP5004901B2 - セッション制御イベント通知ａｐｉ提供装置、セッション制御イベント通知ａｐｉ提供方法及びセッション制御イベント通知ａｐｉ提供プログラム

Info

Publication number: JP5004901B2
Application number: JP2008208891A
Authority: JP
Inventors: 道生入江; 雅志金子
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2008-08-14
Filing date: 2008-08-14
Publication date: 2012-08-22
Anticipated expiration: 2028-08-14
Also published as: JP2010045651A

Description

本発明は、通信ネットワークにおけるアプリケーションを開発するためにサービス提供者が利用するＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍＩｎｔｅｒｆａｃｅ）のうち、セッション制御に関するイベント通知を行うＡＰＩに関する。

電話等のサービスを提供する通信事業者の通信ネットワークに対し、通信ネットワークにおけるセッション制御を外部のアプリケーションから制御可能とするＡＰＩの検討が進められている。また、このようなＡＰＩが、一部の通信ネットワークにおいて利用されはじめている。このようなＡＰＩは通信事業者内のサービス提供者や、通信事業者外のサービス提供者によって利用されることが想定されている。これらのサービス提供者は、提供するサービスごとにアプリケーションを開発し、このアプリケーションから前述のＡＰＩを呼び出すことによって、通信ネットワークに対するセッション制御を実現している。

通信ネットワークにおけるセッション制御を外部のアプリケーションから制御可能とする従来技術によるＡＰＩとして、ＰａｒｌａｙＸが挙げられる（非特許文献１および非特許文献２参照）。このＰａｒｌａｙＸとは、電話などの端末を制御する仕組みを知らない開発者でも、容易に端末を操作するアプリケーションを開発できることを目的に規定されたＡＰＩの規格である。このＰａｒｌａｙＸにおいては、その制御する機能種別に応じて、幾つかのパートに分かれている。たとえば、ＰａｒｌａｙＸのパートとして、Ｐａｒｔ２：ＴｈｉｒｄＰａｒｔｙＣａｌｌ（非特許文献１参照）、および、Ｐａｒｔ３：ＣａｌｌＮｏｔｉｆｉｃａｔｉｏｎ（非特許文献２参照）が、知られている。

このＰａｒｌａｙＸにおけるセッション制御ＡＰＩであるＴｈｉｒｄＰａｒｔｙＣａｌｌは、電話機やテレビ電話機等の通信端末間でのセッション接続や、セッションの状態や、セッションに接続している各通信端末の状態を取得する命令を提供する。その特徴として、単純な２通信端末間のセッション接続のみならず、セッションに対する通信端末の追加や削除、また、あるセッションから別のセッションへと通信端末を移動するといった命令を提供する等、１端末単位での操作を可能としている点が挙げられる。なお、通信端末の状態とは、たとえば、通信端末の通信における状態、すなわち、通信状態のことである。

また、ＰａｒｌａｙＸにおけるセッション制御イベント通知ＡＰＩであるＣａｌｌＮｏｔｉｆｉｃａｔｉｏｎは、セッション制御におけるイベントを契機に、アプリケーションに対してイベントを通知し、またイベントに対してどのような処理を行うかアプリケーションからの指示が必要な場合には、この指示を要求する命令を提供する。ここでいうイベントとしては、ある通信端末が別の通信端末に対してセッション接続を開始したこと、着信側の通信端末が応答しなかったこと、着信側の端末が通話中のため呼び出しに応じられないこと、または、着信側端末が呼び出しに応じてセッションが確立したこと、等が挙げられる。また、イベントに対する指示要求を受けたアプリケーションからは、そのままの処理の継続や、セッションの切断、更に別の通信端末へのセッションの転送等の指示が可能である。

これらの通知や指示要求は、通信端末からの発呼を契機として呼び出されるものであり、ＴｈｉｒｄＰａｒｔｙＣａｌｌの命令によってセッションに新たに通信端末を追加するといった、アプリケーションからの操作を契機とした場合には呼び出されない。アプリケーションからの操作を契機としたセッションや通信端末の状態変化の取得や、状態変化に対する操作については、ＴｈｉｒｄＰａｒｔｙＣａｌｌで提供されている状態取得命令や１端末単位での操作命令を利用する形となっている。

ＰａｒｌａｙＸのＡＰＩを提供する各ＡＰＩ提供装置の接続を示す構成図を図１に示す。セッション制御ＡＰＩ提供装置３００、セッション制御イベント通知ＡＰＩ提供装置４００、メディア制御ＡＰＩ提供装置５００等は、それぞれ対応するＰａｒｌａｙＸのＡＰＩを提供するゲートウェイ装置である。これらのＡＰＩ提供装置で提供されるＡＰＩは、情報ネットワーク（情報ＮＷ）２００を介して、アプリケーションサーバ１００上のアプリケーション処理部１１０におけるアプリケーションから利用される。

このＡＰＩ呼び出しを受けて、各ＡＰＩ提供装置はセッション制御用ネットワーク６００に対してセッション制御を行い、ＡＰＩの機能に応じて通信端末７００、７１０間のセッション接続や音声ガイダンスの再生等の制御を行う。なお、ＡＰＩを提供するＡＰＩ提供装置としては、この図１のようにＡＰＩの種類毎に装置が分かれている場合もあれば、複数の種類のＡＰＩ提供装置を一体とした装置により提供している場合もある。

以降においては、セッション制御ＡＰＩ提供装置３００、セッション制御イベント通知ＡＰＩ提供装置４００、または、メディア制御ＡＰＩ提供装置５００を、ＡＰＩ提供装置と称して説明する。また、以降においては、このアプリケーションサーバ１００上のアプリケーション処理部１１０におけるアプリケーションを、アプリケーションと称して説明する。

ＰａｒｌａｙＸのセッション制御イベント通知ＡＰＩであるＣａｌｌＮｏｔｉｆｉｃａｔｉｏｎにおいて定義されている通知命令や指示要求命令は、ＰａｒｌａｙＸのその他のＡＰＩとは異なり、ＡＰＩ提供装置からアプリケーションを呼び出す形となっている。

まず、ＰａｒｌａｙＸにおける通常の形態であって、アプリケーションからＡＰＩ提供装置を呼び出す例として、ＴｈｉｒｄＰａｒｔｙＣａｌのｍａｋｅＣａｌｌＳｅｓｓｉｏｎ命令の動作シーケンス例を図６に示す。ここでは、アプリケーション処理部１１０がセッション制御ＡＰＩ提供装置３００に対し、ステップＳ００１でｍａｋｅＣａ１１Ｓｅｓｓｉｏｎ命令を呼び出すことで、通信端末７００と通信端末７１０の間で通話を実現している（図６のステップＳ００２〜ステップＳ０１３参照）。

この図６の動作シーケンスに対し、ＡＰＩ提供装置からアプリケーションを呼び出すＣａｌｌＮｏｔｉｆｉｃａｔｉｏｎの例として、通信端末が話中であった場合に、ＡＰＩ提供装置がアプリケーションを呼び出すｎｏｔｉｆｙＢｕｓｙ命令の動作シーケンス例を図７に示す。ここでは、通信端末７００から通信端末７１０に対してのステップＳ１０１でのＩＮＶＩＴＥ命令を、セッション制御イベント通知ＡＰＩ提供装置４００が通信端末７１０に転送し（ステップＳ１０２）、これに対して通信端末７１０から話中であるという応答が返ってきている（ステップＳ１０３）。これを受けて、セッション制御イベント通知ＡＰＩ提供装置４００は、アプリケーション処理部１１０に対してステップＳ１０４でｎｏｔｉｆｙＢｕｓｙ命令を通知し、アプリケーション処理部１１０に通信端末７１０が話中であったことを通知している（ステップＳ１０４）。

次に、セッション制御イベント通知ＡＰＩ提供装置４００の機能構成について図８に示す。通知命令部４１０は、各種イベントをアプリケーションに通知する命令であり、指示要求命令部４２０は各種イベントを通知し、このイベントに対してどのような処理を行うのかアプリケーションに対して指示を求める命令である。

通知命令部４１０で扱うイベントの種別は、セッション接続の開始（４１１）、接続先の通信端末が話中である（４１２）、対象の通信端末に接続できない（４１３）、接続先の通信端末が応答しない（４１４）、接続が確立した（４１５）場合の計５つである。
すなわち、通知命令部４１０は、イベントの種別に対応して、セッション接続の開始に対応する発呼部４１１と、接続先の通信端末が話中であることに対応する話中部４１２と、対象の通信端末に接続できないことに対応する非到達部４１３と、接続先の通信端末が応答しないことに対応する無応答部４１４と、接続が確立したことに対応する応答部４１５とを、有している。

一方、指示要求命令部４２０は、セッション接続の開始（４２１）、接続先の通信端末が話中である（４２２）、対象の通信端末に接続できない（４２３）、接続先の通信端末が応答しない（４２４）場合の４つを対象のイベント種別としている。
すなわち、指示要求命令部４２０は、イベント種別に対応して、セッション接続の開始に対応する発呼部４２１と、接続先の通信端末が話中であることに対応する話中部４２２と、対象の通信端末に接続できないことに対応する非到達部４２３と、接続先の通信端末が応答しないことに対応する無応答部４２４とを、有している。

また、指示要求命令部４２０の指示部４２５では、これらのイベントに対するアプリケーションからの指示の種類として、処理の継続（４２６）、セッションの切断（４２７）、セッションの接続先を別の通信端末に転送（４２８）の３種類を定義している。
すなわち、指示部４２５は、これらのイベントに対するアプリケーションからの指示の種類に対応して、処理の継続に対応する継続部４２６、セッションの切断に対応する切断部４２７と、セッションの接続先を別の通信端末に転送に対応する転送部４２８とを、有している。
Parlay Group,"Open Service Access (OSA); Parlay X Web Services; Part 2: Third Party Call (Parlay X 3),"ETSI ES 202 504-2 v0.0.5, Jun.2007. Parlay Group,"Open Service Access (OSA); Parlay X Web Services; Part 3: Call Notification (Parlay X 3),"ETSI ES 202 504-3 v0.0.3, Jun.2007.

しかしながら、従来技術のセッション制御イベント通知ＡＰＩでは、端末からのセッション接続時における各種イベントのみを契機とするイベント通知及び指示要求を行う仕組みは提供されているが、端末の切断（例：受話器を置く）によるセッション切断を契機としたアプリケーションへのイベント通知及び指示要求を行う仕組みは提供されていないという問題がある。

この従来技術を利用するアプリケーションで、このような切断イベントを契機として処理を行うには、セッション接続時から通信端末の切断が発生するまでの間、アプリケーションから通信端末の状態取得命令を繰り返し呼び続ける必要がある。しかしながら、この連続的な命令呼び出し（ポーリング）は、アプリケーション側にとっても、アプリケーションからの命令を受け取るＡＰＩ提供装置にとっても負荷の高い処理であり、回避したいという要望がある。

また、従来技術のセッション制御ＡＰＩでは、１通信端末単位での操作が可能であるにもかかわらず、端末からの発呼時には最初に必ず２通信端末を含むセッション状態を生成する必要がある。そのため、２通信端末での通話を行う前に、１通信端末だけに対して録音音声を流すといった処理を実現することができないという問題がある。

このような処理を実現するためには、通信端末からの発呼時は原則として１通信端末のみを含む状態でセッションを生成するか、あるいは、何らかのイベントを契機にアプリケーションから２通信端末の代わりに１通信端末のみを含むセッションを生成する仕組みが必要となる。

更に、上記２つの問題の組み合わせとして、２通信端末を含むセッションから１通信端末が切断する際に、残ったもう１通信端末も切断してしまう代わりに、１通信端末だけを含むセッション状態として通信状態を継続させ、この通信状態を継続させた通信端末に対して録音音声を流す等の各種操作を実現する仕組みが存在していないという問題もある。

また、従来技術では定義されていないが、２通信端末を含むセッションにおける１通信端末の切断に対し、残されたもう一方の通信端末を自動的に切断するのか、それとも残されたものはそのままに１通信端末を含むセッションとして継続するのかといった、ＡＰＩの動作の解釈における問題がある。
後者の動作が行われると解釈する場合、２通信端末間で通話を開始するだけの単純なアプリケーションにおいても、一方の通信端末の切断を受けてもう一方の通信端末を切断するために、アプリケーションは切断イベントの通知を待ち続ける必要がある。前者の場合は切断に対して自動的にもう一方の通信端末を切断するため、このような問題は起こらないが、自動的に切断を行いたくない場合にアプリケーションから自動的な切断を行わずに１通信端末のみを含むセッション状態を生成する仕組みが必要となる。

本発明は、このような事情に鑑みてなされたもので、その目的は、通話の開始時や終了時に１通信端末単位での様々なセッション制御やメディア制御を行うサービスを、ポーリングを行わない低負荷な仕組みで実現することが可能となるセッション制御イベント通知ＡＰＩ提供装置、セッション制御イベント通知方法及びセッション制御イベント通知ＡＰＩ提供プログラムを提供する。

この発明は上述した課題を解決するためになされたもので、請求項１に記載の発明は、アプリケーションサーバと連携して通信端末との間のセッション接続を制御するセッション制御イベント通知ＡＰＩ提供装置であって、２台の通信端末間のセッションが接続されている場合に、前記２台の通信端末のうちのいずれか一方の通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、前記受信した切断要求イベントを前記アプリケーションサーバへ通知するとともに、当該切断要求イベントに対する処理内容を前記アプリケーションサーバへ問い合わせる切断通知部と、前記２台の通信端末のうちの他方の通信端末のみとの間のセッションを生成する指示情報を前記アプリケーションサーバから前記問い合わせに対して受信し、当該指示情報を受信したことに応じて、前記他方の通信端末のみとの間のセッションを生成する単一端末指示要求命令部と、を有することを特徴とするセッション制御イベント通知ＡＰＩ提供装置である。

請求項２に記載の発明は、アプリケーションサーバと連携して通信端末との間のセッション接続を制御するセッション制御イベント通知ＡＰＩ提供装置において用いられるセッション制御イベント通知方法であって、２台の通信端末間のセッションが接続されている場合に、前記２台の通信端末のうちのいずれか一方の通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、前記受信した切断要求イベントを前記アプリケーションサーバへ通知するとともに、当該切断要求イベントに対する処理内容を前記アプリケーションサーバへ問い合わせる切断通知手順と、前記２台の通信端末のうちの他方の通信端末のみとの間のセッションを生成する指示情報を前記アプリケーションサーバから前記問い合わせに対して受信し、当該指示情報を受信したことに応じて、前記他方の通信端末のみとの間のセッションを生成する単一端末指示要求命令手順と、を有することを特徴とするセッション制御イベント通知ＡＰＩ提供方法である。

請求項３に記載の発明は、アプリケーションサーバと連携して通信端末との間のセッション接続を制御するセッション制御イベント通知ＡＰＩ提供装置としてのコンピュータに、２台の通信端末間のセッションが接続されている場合に、前記２台の通信端末のうちのいずれか一方の通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、前記受信した切断要求イベントを前記アプリケーションサーバへ通知するとともに、当該切断要求イベントに対する処理内容を前記アプリケーションサーバへ問い合わせる切断通知手順と、前記２台の通信端末のうちの他方の通信端末のみとの間のセッションを生成する指示情報を前記アプリケーションサーバから前記問い合わせに対して受信し、当該指示情報を受信したことに応じて、前記他方の通信端末のみとの間のセッションを生成する単一端末指示要求命令手順と、を実行させるためのセッション制御イベント通知ＡＰＩ提供プログラムである。

この発明によれば、セッション制御イベント通知ＡＰＩ提供装置が、セッションが接続されている通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、この受信した切断要求イベントをアプリケーションサーバへ通知する。
これにより、アプリケーションサーバ上のアプリケーションは、通信端末の状態取得命令を繰り返し呼び続けるというポーリングを行うこと無しに、通信端末の状態を取得することが可能となる。

そのため、通話の開始時や終了時に１通信端末単位での様々なセッション制御やメディア制御を行うサービスを、ポーリングを行わない低負荷な仕組みで実現することが可能となり、ＡＰＩによるサービス開発の自由度を高め、通信ネットワークにおけるセッション制御機能を利用したサービスの多様化が促進される。

以下、図面を参照して、本発明の実施の形態について説明する。図１は、従来技術と同様に、この発明の一実施形態によるＰａｒｌａｙＸのＡＰＩを提供する各ＡＰＩ提供装置の接続を示す構成図である。なお、同図において、従来技術の構成に対応する構成には同一の符号を付け、その説明を省略する。なお、本実施形態によるセッション制御イベント通知ＡＰＩ提供装置を、セッション制御イベント通知ＡＰＩ提供装置４００Ｂとして説明する。このセッション制御イベント通知ＡＰＩ提供装置４００Ｂは、アプリケーションサーバ１００と連携して通信端末７００または７１０との間のセッション接続を制御する。

ここでは、図１における情報ネットワーク２００としてインターネット等を想定し、セッション制御用ネットワーク６００としてＮＧＮ（ＮｅｘｔＧｅｎｅｒａｌｉｏｎＮｅｔｗｏｒｋ）やＩＭＳ（ＩＰＭｕｌｔｉｍｅｄｉａＳｕｂｓｙｓｔｅｍｓ）等のＳＩＰ（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ）によってセッション接続を行う通信ネットワークを想定する。

図２に本実施形態によるセッション制御イベント通知ＡＰＩ提供装置４００Ｂの機能構成を示す。このセッション制御イベント通知ＡＰＩ提供装置４００Ｂと、図８を用いて説明した従来技術におけるセッション制御イベント通知ＡＰＩ提供装置４００Ａとの違いは、通知命令部４１０に対象とするイベント種別として切断部４１６（切断通知命令部）が追加された点と、指示要求命令部４２０に対象とするイベント種別として切断部４３０（切断指示要求命令部）が追加された点と、指示要求命令部４２０の指示部４２５に１通信端末状態の生成に対応する１端末部４２９（単一端末指示要求命令部）が追加された点とである。

切断部４１６は、セッションに接続されている通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、受信した切断要求イベントをアプリケーションサーバ１００へ通知する。

切断部４３０は、セッションに接続されている通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、受信した切断要求イベントをアプリケーションサーバ１００へ通知するともに、当該切断要求イベントに対する処理内容をアプリケーションサーバ１００へ問い合わせる。

１端末部４２９は、通信端末との間のセッションを生成する指示情報をアプリケーションサーバ１００から受信したことに応じて、他方の通信端末のみとの間のセッションを生成する。

また、２台の通信端末間のセッションが接続されている場合に、この２台の通信端末のうちのいずれか一方の通信端末からの当該セッションに対する切断要求イベントをセッション制御イベント通知ＡＰＩ提供装置４００Ｂが受信したことに応じて、切断部４３０と、１端末部４２９とは、たとえば、次のように動作する。

切断部４３０は、２台の通信端末間のセッションが接続されている場合に、この２台の通信端末のうちのいずれか一方の通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、受信した切断要求イベントをアプリケーションサーバ１００へ通知するともに、当該切断要求イベントに対する処理内容をアプリケーションサーバ１００へ問い合わせる。

１端末部４２９は、２台の通信端末のうちの他方の通信端末のみとの間のセッションを生成する指示情報をアプリケーションサーバ１００から切断部４３０の問い合わせに対して受信し、当該指示情報を受信したことに応じて他方の通信端末のみとの間のセッションを生成する。

なお、上述した切断部４１６と切断部４３０とは、たとえば、セッション制御イベント通知ＡＰＩ提供装置４００Ｂが内蔵する設定情報記憶部に予め設定されている設定情報に基づいて、切断部４１６と切断部４３０との内、いずれか一方のみが機能するようにされている。なお、この設定情報記憶部に記憶させている設定情報は、たとえば、アプリケーションサーバ１００が、セッション制御イベント通知ＡＰＩ提供装置４００Ｂとの通信を介して、変更する。

次に図３から図５を用いて、本実施形態によるセッション制御イベント通知ＡＰＩ提供装置４００Ｂの動作、および、このセッション制御イベント通知ＡＰＩ提供装置４００Ｂと、アプリケーションサーバ１００と、通信端末７００と、通信端末７１０とを有する通信システムの動作について説明する。

まず、図３に通知命令部４１０における切断部４１６の通知の動作シーケンス例を示す。ここでは、例えば図６に示すようなセッション制御ＡＰＩや、通信端末からの発呼によってＡＰＩ提供装置と通信端末との間でセッションが既に確立され、通信端末間での通話が開始されているものとし、セッション接続時のシーケンスについては省略する（図３のステップＳ２０１、ステップＳ２０２、および、ステップＳ２０３参照）。また、ここでは、切断部４１６と切断部４３０とのうち、切断部４１６が動作するものとして説明する。

通話中に通信端末７１０からの切断要求がセッション制御イベント通知ＡＰＩ提供装置４００に届くと（ステップＳ２０４）、これを契機としてセッション制御イベント通知ＡＰＩ提供装置４００からアプリケーション処理部１１０へと切断通知命令が呼び出される（ステップＳ２０５）。

すなわち、セッション制御イベント通知ＡＰＩ提供装置４００の切断部４１６は、セッションに接続されている通信端末（通信端末７１０）からの当該セッションに対する切断要求イベント（切断要求）を受信したことに応じて、受信した切断要求イベントをアプリケーションサーバ１００へ通知する（ステップＳ２０４、ステップＳ２０５参照）。

この切断通知命令ではアプリケーションへの通知のみを行い、セッション制御については通知を行わない場合と同等の動作を行うため、両通信端末７１０と７００とのセッションを順次切断し（ステップＳ２０７、ステップＳ２１０）、通話を終了する（ステップＳ２１１）。

図３を用いて説明したように、本実施形態によれば、セッション制御イベント通知ＡＰＩ提供装置４００の切断部４１６が、セッションに接続されている通信端末（通信端末７１０）からの当該セッションに対する切断要求イベント（切断要求）を受信したことに応じて、受信した切断要求イベントをアプリケーションサーバ１００へ通知する（切断通知命令を呼び出す）。

これにより、アプリケーションサーバ１００上のアプリケーションは、通信端末の状態取得命令を繰り返し呼び続けるというポーリングを行うこと無しに、通信端末の状態を取得することが可能となる。そのため、アプリケーションサーバ１００上のアプリケーションは、通信端末の状態に応じて、様々なサービスを提供することができる。

次に、図４は、通信端末７００から通信端末７１０への発呼時に、話中だった場合に切断する代わりに、通信端末７００のみを含むセッション状態を生成する動作シーケンス例である。通信端末７００から通信端末７１０への接続要求（ステップＳ３０１）をセッション制御イベント通知ＡＰＩ提供装置４００が仲介し、通信端末７１０へと送信（ステップＳ３０２）する。

これに対し、通信端末７１０が話中であるという応答が、通信端末７１０からセッション制御イベント通知ＡＰＩ提供装置４００に返信される（ステップＳ３０３）。これを受けてセッション制御イベント通知ＡＰＩ提供装置４００が、アプリケーション処理部１１０に対して、語中の指示を要求する指示要求命令を呼び出す（ステップＳ３０４）。アプリケーション処理部１１０は、これに対し、通信端末７００のみを含むセッション状態の生成を指示する（ステップＳ３０５）。ここでは転送（Ｒｏｕｔｅ）先の端末を指定しない（ｎｕ１１）ことで、１端末状態の生成を指示するものとする。

ここで１端末状態の生成を指示しなかった場合は、図７のように全くセッションが生成されずに接続自体が失敗となるが、ここでは通信端末７００とセッション制御イベント通知ＡＰＩ提供装置４００との間でセッションが確立されている（ステップＳ３０９）。

すなわち、セッション制御イベント通知ＡＰＩ提供装置４００の１端末部４２９は、通信端末との間のセッションを生成する指示情報をアプリケーションサーバ１００から受信したことに応じて、他方の通信端末（通信端末７００）との間のセッションを生成する（ステップＳ３０９参照）。

図４を用いて説明したように、本実施形態によれば、端末からの発呼時に、最初に２通信端末を含むセッション状態を生成すること無しに、１通信端末のみを含むセッションを生成することが可能となる。そのため、たとえば、２通信端末での通話を行う前に、１通信端末だけに対して録音音声を流すといった処理を実現することができる。

なお、上述した図４のステップＳ３０５の説明においては、転送（Ｒｏｕｔｅ）先の端末を指定しない（ｎｕ１１）ことで、１端末状態の生成を指示するものとして説明したが、これに限られるものではなく、転送（Ｒｏｕｔｅ）ではなく１端末状態の生成を表す独自の指示名が与えられ、この独自の指示名により１端末状態の生成を指示するようにしてもよい。

次に、図５に通信端末からの切断イベントを受けて１通信端末のみを含むセッション状態を生成し、残されたもう一方の通信端末に対して音声ガイダンスを再生するサービスの動作シーケンス例を示す。このシーケンスは、相手が受話器を置いた場合に、通話時間を合成音声で読み上げるサービスを想定している。図３の場合と同様に、既に通信端末７００および通信端末７１０とセッション制御イベント通知ＡＰＩ提供装置４００との間でセッションが確立されており（ステップＳ４０１、ステップＳ４０２）、両通信端末間での通話が行われている（ステップＳ４０３）ものとする。また、ここでは、切断部４１６と切断部４３０とのうち、切断部４３０が動作するものとして説明する。

ここで、通信端末７１０の受話器が置かれ、切断メッセージがセッション制御イベント通知ＡＰＩ提供装置４００へと送られる（ステップＳ４０４）。これを受けて、セッション制御イベント通知ＡＰＩ提供装置４００は、アプリケーション処理部１１０に対し指示要求を行い（ステップＳ４０５）、アプリケーション処理部１１０は１端末状態の生成を、セッション制御イベント通知ＡＰＩ提供装置４００に指示する（ステップＳ４０６）。

この指示により、セッション制御イベント通知ＡＰＩ提供装置４００は、通信端末７１０との接続を終了し（ステップＳ４０８）、両通信端末間の通話を終了する（ステップＳ４０９）。その後、セッション制御イベント通知ＡＰＩ提供装置４００は、残された通信端末７００に対してセッション状態の更新を行い（ステップＳ４１０〜ステップＳ４１２）、１通信端末のみのセッション状態としてセッションを継続する（ステップＳ４１３）。

その後、アプリケーション処理部１１０は、ＰａｒｌａｙＸにおけるメディア制御ＡＰＩであるＡｕｄｉｏＣａｌｌ（下記の参考文献１参照）の音声再生命令ｐｌａｙＡｕｄｉｏＭｅｓｓａｇｅを、セッション制御イベント通知ＡＰＩ提供装置４００に対して出力する（ステップＳ４１４）ことで、通信端末７００に対して音声ガイダンスを再生する（ステップＳ４１５）。

（参考文献１） Parlay Group,“Open Service Access (OSA); Parlav X Web Services; Part 11: Audio Call (Parlay X 3),”ETSI ES 202 504-11 v0.0.3, Jun.2007.

すなわち、図５において、セッション制御イベント通知ＡＰＩ提供装置４００の切断部４３０は、２台の通信端末（通信端末７００と７１０）間のセッションが接続されている場合に、この２台の通信端末のうちのいずれか一方の通信端末（この場合、通信端末７１０）からの当該セッションに対する切断要求イベントを受信したことに応じて、受信した切断要求イベントをアプリケーションサーバ１００へ通知するとともに、当該切断要求イベントに対する処理内容を示す指示情報をアプリケーションサーバ１００へ問い合わせる（ステップＳ４０５参照）。

そして、セッション制御イベント通知ＡＰＩ提供装置４００の１端末部４２９は、２台の通信端末（通信端末７００と７１０）のうちの他方の通信端末（この場合、通信端末７００）のみとの間のセッションを生成する指示情報をアプリケーションサーバ１００から切断部４３０の問い合わせに対して受信し、当該指示情報を受信したことに応じて他方の通信端末（この場合、通信端末７００）のみとの間のセッションを生成する（ステップＳ４１３参照）。

図５を用いて説明したように、本実施形態によれば、２通信端末を含むセッションから１通信端末が切断する際に、残ったもう１通信端末も切断してしまう代わりに、１通信端末だけを含むセッション状態として通信状態を継続させることができる。そのため、たとえば、通信状態を継続させた１通信端末に対して、録音音声を流す等のサービスを提供することができる。

上記図１から図５を用いて説明した本実施形態により、通話の開始時や終了時に１通信端末単位での様々なセッション制御やメディア制御を行うサービスを、ポーリングを行わない低負荷な仕組みで実現することが可能となり、ＡＰＩによるサービス開発の自由度を高め、通信ネットワークにおけるセッション制御機能を利用したサービスの多様化が促進される。

なお、上述した本実施形態は、幾つかのパートに分かれているＰａｒｌａｙＸにおいて、Ｐａｒｔ２：ＴｈｉｒｄＰａｒｔｙＣａｌｌ（非特許文献１）と、Ｐａｒｔ３：ＣａｌｌＮｏｔｉｆｉｃａｔｉｏｎ（非特許文献２）の範囲に相当するものであり、Ｐａｒｔ３を拡張して新しいＡＰＩを追加するものである。

なお、上記の実施形態の説明においては、切断部４１６と切断部４３０とを異なる構成として説明したが、これに限られるものではなく、この切断部４１６と切断部４３０とを一体として切断通知部として構成してもよい。

たとえば、この切断通知部は、セッションに接続されている通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、受信した切断要求イベントをアプリケーションサーバ１００へ通知する。または、この切断通知部は、セッションに接続されている通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、受信した切断要求イベントをアプリケーションサーバ１００へ通知するともに、当該切断要求イベントに対する処理内容をアプリケーションサーバ１００へ問い合わせる。

切断通知部のこの２つの動作は、たとえば、セッション制御イベント通知ＡＰＩ提供装置４００Ｂが内蔵する設定情報記憶部に予め設定されている設定情報に基づいて、この２つの動作の内、いずれか一方のみが動作するようにされている。

なお、このセッション制御イベント通知ＡＰＩ提供装置４００Ｂは専用のハードウェアにより実現されるものであってもよく、また、このセッション制御イベント通知ＡＰＩ提供装置４００ＢはメモリおよびＣＰＵ（中央演算装置）により構成され、セッション制御イベント通知ＡＰＩ提供装置４００Ｂの機能を実現するためのプログラムをメモリにロードして実行することによりその機能を実現させるものであってもよい。

また、図１または図２におけるセッション制御イベント通知ＡＰＩ提供装置４００Ｂの機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによりセッション制御イベント通知ＡＰＩ提供装置４００Ｂの処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

各ＡＰＩ提供装置の接続を示す一例としての構成図である。本実施形態によるセッション制御イベント通知ＡＰＩ提供装置の構成図である。本実施形態による切断イベントをアプリケーションへ通知する一例としてのシーケンスチャートである。本実施形態による指示要求に対しアプリケーションから１端末状態の生成を指示する一例としてのシーケンスチャートである。本実施形態による切断イベントに対しアプリケーションから１端末状態の生成を指示し、通信端末に対して音声ガイダンスを再生する一例としてのシーケンスチャートである。従来技術によるアプリケーションからＡＰＩ提供装置を呼び出す一例としてのシーケンスチャートである。従来技術によるＡＰＩ提供装置からアプリケーションへイベントを通知する一例としてのシーケンスチャートである。従来技術におけるセッション制御イベント通知ＡＰＩ提供装置の構成図である。

符号の説明

１００…アプリケーションサーバ、１１０…アプリケーション処理部、２００…情報ネットワーク、３００…セッション制御ＡＰＩ提供装置、４００、４００Ａ、４００Ｂ…セッション制御イベント通知ＡＰＩ提供装置、４１０…通知命令部、４１１、４２１…発呼部、４１２、４２２…話中部、４１３、４２３…非到達部、４１４、４２４…無応答部、４１５…応答部、４１６、４２７、４３０…切断部、４２９…１端末部、４２０…指示要求命令部、５００…メディア制御ＡＰＩ提供装置、６００…セッション制御用ネットワーク、７００、７１０…通信端末

Claims

アプリケーションサーバと連携して通信端末との間のセッション接続を制御するセッション制御イベント通知ＡＰＩ提供装置であって、
２台の通信端末間のセッションが接続されている場合に、
前記２台の通信端末のうちのいずれか一方の通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、前記受信した切断要求イベントを前記アプリケーションサーバへ通知するとともに、当該切断要求イベントに対する処理内容を前記アプリケーションサーバへ問い合わせる切断通知部と、
前記２台の通信端末のうちの他方の通信端末のみとの間のセッションを生成する指示情報を前記アプリケーションサーバから前記問い合わせに対して受信し、当該指示情報を受信したことに応じて、前記他方の通信端末のみとの間のセッションを生成する単一端末指示要求命令部と、
を有することを特徴とするセッション制御イベント通知ＡＰＩ提供装置。
アプリケーションサーバと連携して通信端末との間のセッション接続を制御するセッション制御イベント通知ＡＰＩ提供装置において用いられるセッション制御イベント通知方法であって、
２台の通信端末間のセッションが接続されている場合に、
前記２台の通信端末のうちのいずれか一方の通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、前記受信した切断要求イベントを前記アプリケーションサーバへ通知するとともに、当該切断要求イベントに対する処理内容を前記アプリケーションサーバへ問い合わせる切断通知手順と、
前記２台の通信端末のうちの他方の通信端末のみとの間のセッションを生成する指示情報を前記アプリケーションサーバから前記問い合わせに対して受信し、当該指示情報を受信したことに応じて、前記他方の通信端末のみとの間のセッションを生成する単一端末指示要求命令手順と、
を有することを特徴とするセッション制御イベント通知ＡＰＩ提供方法。
アプリケーションサーバと連携して通信端末との間のセッション接続を制御するセッション制御イベント通知ＡＰＩ提供装置としてのコンピュータに、
２台の通信端末間のセッションが接続されている場合に、
前記２台の通信端末のうちのいずれか一方の通信端末からの当該セッションに対する切断要求イベントを受信したことに応じて、前記受信した切断要求イベントを前記アプリケーションサーバへ通知するとともに、当該切断要求イベントに対する処理内容を前記アプリケーションサーバへ問い合わせる切断通知手順と、
前記２台の通信端末のうちの他方の通信端末のみとの間のセッションを生成する指示情報を前記アプリケーションサーバから前記問い合わせに対して受信し、当該指示情報を受信したことに応じて、前記他方の通信端末のみとの間のセッションを生成する単一端末指示要求命令手順と、
を実行させるためのセッション制御イベント通知ＡＰＩ提供プログラム。