(57)【要約】【課題】アプリケーション開発者に端末間でのメディア種別を意識させることなく、より高度で利便性が高いサービス開発を実現する。【解決手段】ゲートウェイ２００が情報ネットワーク３００と通信事業者ネットワーク１００との間に設けられている。ゲートウェイ２００には、プリケーション４１０から呼び出すことができる制御ＡＰＩ２１０として、接続ＡＰＩ、切断ＡＰＩ、切り替えＡＰＩ、分割ＡＰＩ、結合ＡＰＩが設定される。ゲートウェイ２００は、アプリケーション４１０からのＡＰＩ呼び出し、または端末からの発信を契機に、メディアネゴシエーションをベースとしてセッションを確立する。【選択図】図１
2009223533.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションサーバからの指令を受け、通信事業者のネットワークに接続された通信ノード間のセッションを制御するセッション制御装置において、
前記アプリケーションサーバからの指令に応じて前記通信ノード間のセッションを確立するセッション確立手段と、
前記通信ノード間において確立されたセッションを示すセッション識別子を前記アプリケーションサーバへ送信するセッション識別子通知手段と、
前記通信ノード間に確立されたセッションを前記アプリケーションサーバからの指令に応じて制御するセッション制御手段と、
前記通信ノードとのセッション確立時に前記通信ノード間でメディアネゴシエーションを行う管理手段と、
を具備することを特徴とするセッション制御装置。
【請求項２】
前記前記管理手段は、通信ノード毎のメディアネゴシエーション結果を保持する保持手段を有し、前記通信ノード毎のメディアネゴシエーション結果に基づいて、メディアタイプの変更に伴うコーデック変更を判定することを特徴とする請求項１記載のセッション制御装置。
【請求項３】
前記セッション制御手段は、前記アプリケーションサーバからの指令に基づき、確立中のセッションの第１、第２の通信ノードの一方の接続先を第３の通信ノードに切り替える切り替え手段を有することを特徴とする請求項１記載のセッション制御装置。
【請求項４】
前記セッション制御手段は、前記アプリケーションサーバからの指令に基づき、確立中のセッションの第１、第２の通信ノードの接続先を、それぞれ第３、第４の通信ノードに切り替える分割手段を有することを特徴とする請求項１記載のセッション制御装置。
【請求項５】
前記セッション制御手段は、前記アプリケーションサーバからの指令に基づき、確立中の第１のセッションの一方の通信ノードと、確立中の第２のセッションの一方の通信ノードとを、セッションを確立したまま再結合する再結合手段を有することを特徴とする請求項１記載のセッション制御装置。
【請求項６】
前記セッション制御手段は、前記アプリケーションサーバからの指令に基づき、確立中のセッションを切断する切断手段を有することを特徴とする請求項１記載のセッション制御装置。
【請求項７】
前記セッション制御手段は、通信ノード間でセッションが確立された場合に、確立された当該セッションを特定するセッション識別子を前記アプリケーションサーバに通知することを特徴とする請求項１乃至６のいずれかに記載のセッション制御装置。
【請求項８】
アプリケーションサーバからの指令を受け、通信事業者のネットワークに接続された通信ノード間のセッションを制御するセッション制御方法において、
前記アプリケーションサーバからの指令に応じて前記通信ノード間のセッションを確立するステップと、
前記通信ノード間において確立されたセッションを示すセッション識別子を前記アプリケーションサーバへ送信するステップと、
前記通信ノード間に確立されたセッションを前記アプリケーションサーバからの指令に応じて制御するステップと、
前記通信ノードとのセッション確立時に前記通信ノード間でメディアネゴシエーションを行うステップと、
を有することを特徴とするセッション制御方法。
【請求項９】
アプリケーションサーバからの指令を受け、通信事業者のネットワークに接続された通信ノード間のセッションを制御するコンピュータに、
前記アプリケーションサーバからの指令に応じて前記通信ノード間のセッションを確立するステップと、
前記通信ノード間において確立されたセッションを示すセッション識別子を前記アプリケーションサーバへ送信するステップと、
前記通信ノード間に確立されたセッションを前記アプリケーションサーバからの指令に応じて制御するステップと、
前記通信ノードとのセッション確立時に前記通信ノード間でメディアネゴシエーションを行うステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションからの要求により通信ネットワーク上の端末間（サーバ〜端末間、サーバ〜サーバ間も含む）のセッション制御を行うセッション制御装置、セッション制御方法およびプログラムに関する。
【背景技術】
【０００２】
ＩＰ電話や通信ネットワーク上の端末間のセッション制御を、ＡＰＩ（Application Program Interface）等の提供により第三者のアプリケーションから制御可能とする技術（サードパーティコールコントロール）が一部標準化されている（例えば、非特許文献１参照）。しかしながら、非特許文献１のような従来技術では、接続・切断手段しか提供されないなど、制御の種類が少ないため、アプリケーションによって制御可能なことが限定されていた。
【０００３】
そこで、端末間のセッションにおいて多様なメディア種別を利用可能なＩＰベースの通信ネットワーク上において、セッション制御信号として広く使われているＳＩＰ（Session Initiation Protocol）では、ＳＤＰ（Session Description Protocol）交換によって、セッション確立する端末同士のネゴシエーションで、端末の能力に応じたメディア種別（音声通信・映像通信・データ通信等）を選択する方法が標準化されている（例えば、非特許文献２参照）。
【非特許文献１】「Best Current Practices for Third Party Call Control(3pcc)in the Session Initiation Protocol(SIP)」、2004年
【非特許文献２】「実践ＳＩＰ詳解テキスト」リックテレコム、２００５年、ｐ．２３４−２６７
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述した従来技術（非特許文献２）では、標準化によって示されている方法は、あくまで端末間のセッション制御方法に留まっている。また、サードパーティコールコントロールにおけるＳＤＰ交換方式について規定しているＲＦＣ３７２５においても、非特許文献１のようなセッション制御を追加した場合に、どのような方法でＳＤＰ交換を行えばよいかは明確にされていない。
【０００５】
そこで、制御の種類を増やし（セッションの切り替え、分割、結合）、特定電話番号に対する着信などの呼制御イベントをアプリケーションに通知する手段などを提供し、アプリケーション開発者がより多くのサービスの開発を可能とすることが望まれる。
【０００６】
しかしながら、端末間のセッション接続時に用いられるメディア種別について、常にアプリケーションから指定するのでは、アプリケーション開発者がセッション制御を実行するたびに、接続させる端末間でのメディア種別を意識しなければならない。
【０００７】
このように、柔軟なセッション制御ＡＰＩを利用したアプリケーション開発において、制御のたびにセッションのメディア種別をアプリケーションから指定しなければならないのは不便である。また、柔軟なサードパーティコールコントロールにおいても、メディア種別の指定は、あくまで端末間のメディアネゴシエーションに任せることができるような仕組みが必要である。
【０００８】
本発明は、このような事情を考慮してなされたものであり、その目的は、アプリケーション開発者に端末間でのメディア種別を意識させることなく、より高度で利便性が高いサービス開発を実現することができるセッション制御装置、セッション制御方法およびプログラムを提供することにある。
【課題を解決するための手段】
【０００９】
上述した課題を解決するために、本発明は、アプリケーションサーバからの指令を受け、通信事業者のネットワークに接続された通信ノード間のセッションを制御するセッション制御装置において、前記アプリケーションサーバからの指令に応じて前記通信ノード間のセッションを確立するセッション確立手段と、前記通信ノード間において確立されたセッションを示すセッション識別子を前記アプリケーションサーバへ送信するセッション識別子通知手段と、前記通信ノード間に確立されたセッションを前記アプリケーションサーバからの指令に応じて制御するセッション制御手段と、前記通信ノードとのセッション確立時に前記通信ノード間でメディアネゴシエーションを行う管理手段と、を具備することを特徴とするセッション制御装置である。
【００１０】
本発明は、上記の発明において、前記前記管理手段は、通信ノード毎のメディアネゴシエーション結果を保持する保持手段を有し、前記通信ノード毎のメディアネゴシエーション結果に基づいて、メディアタイプの変更に伴うコーデック変更を判定することを特徴とする。
【００１１】
本発明は、上記の発明において、前記セッション制御手段は、前記アプリケーションサーバからの指令に基づき、確立中のセッションの第１、第２の通信ノードの一方の接続先を第３の通信ノードに切り替える切り替え手段を有することを特徴とする。
【００１２】
本発明は、上記の発明において、前記セッション制御手段は、前記アプリケーションサーバからの指令に基づき、確立中のセッションの第１、第２の通信ノードの接続先を、それぞれ第３、第４の通信ノードに切り替える分割手段を有することを特徴とする。
【００１３】
本発明は、上記の発明において、前記セッション制御手段は、前記アプリケーションサーバからの指令に基づき、確立中の第１のセッションの一方の通信ノードと、確立中の第２のセッションの一方の通信ノードとを、セッションを確立したまま再結合する再結合手段を有する。
【００１４】
本発明は、上記の発明において、前記セッション制御手段は、前記アプリケーションサーバからの指令に基づき、確立中のセッションを切断する切断手段を有する。
【００１５】
本発明は、上記の発明において、前記セッション制御手段は、通信ノード間でセッションが確立された場合に、確立された当該セッションを特定するセッション識別子を前記アプリケーションサーバに通知することを特徴とする。
【００１６】
また、上述した課題を解決するために、本発明は、アプリケーションサーバからの指令を受け、通信事業者のネットワークに接続された通信ノード間のセッションを制御するセッション制御方法において、前記アプリケーションサーバからの指令に応じて前記通信ノード間のセッションを確立するステップと、前記通信ノード間において確立されたセッションを示すセッション識別子を前記アプリケーションサーバへ送信するステップと、前記通信ノード間に確立されたセッションを前記アプリケーションサーバからの指令に応じて制御するステップと、前記通信ノードとのセッション確立時に前記通信ノード間でメディアネゴシエーションを行うステップと、を有することを特徴とするセッション制御方法である。
【００１７】
また、上述した課題を解決するために、本発明は、アプリケーションサーバからの指令を受け、通信事業者のネットワークに接続された通信ノード間のセッションを制御するコンピュータに、前記アプリケーションサーバからの指令に応じて前記通信ノード間のセッションを確立するステップと、前記通信ノード間において確立されたセッションを示すセッション識別子を前記アプリケーションサーバへ送信するステップと、前記通信ノード間に確立されたセッションを前記アプリケーションサーバからの指令に応じて制御するステップと、前記通信ノードとのセッション確立時に前記通信ノード間でメディアネゴシエーションを行うステップと、を実行させるためのプログラムである。
【発明の効果】
【００１８】
この発明によれば、アプリケーションに対して自由度が高いセッション制御ＡＰＩが提供されることにより、アプリケーション開発者の利便性が向上し、より多くのアプリケーション開発者を通信ネットワーク上のサービス開発に参入させることができる。さらに、当該ＡＰＩは、セッション制御において端末間メディアネゴシエーションをベースとしているため、マルチメディア対応端末を利用したサービス開発も容易となり、より高度で利便性が高いサービス開発を実現することができる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の一実施形態を、図面を参照して説明する。
【００２０】
図１は、本発明の一実施の形態によるゲートウェイ（セッション制御装置）を用いた情報通信システムの構成を示すブロック図である。このシステムは、ネットワークの制御プロトコルとして、ＳＩＰ（Session Initiation Protocol）、ＡＰＩ（Application Program Interface）提供プロトコルとして、ＳＯＡＰ（Simple Object Access Protocol）を使用している。
【００２１】
図において、４００は通信事業者以外のサーバ提供者が管理するアプリケーションサーバ、４１０は、アプリケーションサーバ４００内に設定されたアプリケーション、３００は、アプリケーションサーバ４００が接続された情報ネットワーク、１００は、通信ノードとしての端末５００が接続された通信事業者ネットワーク、２００は、情報ネットワーク３００と通信事業者ネットワーク１００との間に接続されたゲートウェイ、２１０は、ゲートウェイ２００内に設置され、公開されるセッション制御ＡＰＩである。
【００２２】
ここで、端末５００は、ＳＩＰに対応したＶｏＩＰ端末であり、これらの端末５００がＳＩＰ信号により制御するセッションのうち、アプリケーション４１０と連携させるセッションは、必ずゲートウェイ２００を通るものとする。すなわち、アプリケーションサーバ４００上のアプリケーション４１０から送信されたセッション制御ＡＰＩ呼出要求がゲートウェイ装置２００に受信されると、通信事業者ネットワーク１００を介して端末５００との間で呼制御信号を送受信し、端末５００間のセッション制御を行う。
【００２３】
また、端末５００が発信するときに、直接相手の端末５００に送信するのではなく、ゲートウェイ２００を仲介させることにより、アプリケーション４１０に対して呼制御イベントの通知を行う。このとき、ゲートウェイ２００と端末５００との間のプロトコルがＳＩＰとなり、ゲートウェイ２００とアプリケーションサーバ４００との間のプロトコルがＳＯＡＰとなり、アプリケーションサーバ４００上で動作しているアプリケーション４１０からＳＯＡＰによってセッション制御ＡＰＩ２１０の呼出が可能となる。
【００２４】
図２は、本実施形態によるゲートウェイ２００の構成を示すブロック図である。アプリケーション４１０から呼び出すことができる制御ＡＰＩ２１０としては、図２に示すように、接続ＡＰＩ２１１、切断ＡＰＩ２１２、切り替えＡＰＩ２１３、分割ＡＰＩ２１４、結合ＡＰＩ２１５が設定される。また、呼制御イベント通知のためのイベント通知ＡＰＩ２１６も提供される。端末ＳＤＰ管理機能２１７は、後述する、端末間メディアネゴシエーションを実現するために、端末５００に送信したＳＤＰ情報を保存する機能である。メディア終端機能２１８は、後述する自動音声を端末５００へ送信したり、端末５００からの音声入力や、ダイアルトーン信号などのメディアを介した入力を受け付けたりする機能である。ゲートウェイ２００を実現する上で、メディア終端機能２１８は、必須ではなく、これを具備しないゲートウェイ２００であってもよい。
【００２５】
図３は、本実施形態による、端末発信時のメディア種別の決定方法として標準化されているＳＤＰ交換による端末間のセッション制御の一例を示すシーケンス図である。端末間のセッション制御においては、端末間の通信で用いるメディア種別の決定が必要である。図３では、ＩＮＶＩＴＥ要求時に、端末５００（Ａ）が自らのメディア処理能力（対応コーデック等）や、待ち受け状態情報（どのポートで待ち受けしているか）などをＳＤＰ形式で記述した情報をｏｆｆｅｒＡとして端末５００（Ｂ）に送信する（Ｓ３１）。これを受信した端末５００（Ｂ）は、ｏｆｆｅｒＡで指定された内容を解読した上で、自らのメディア処理能力から当該セッションで用いるコーデック等を決定し、待ち受け状態情報とともにＳＤＰ形式で記述して、応答信号に乗せてａｎｓｗｅｒＢとして送信する（Ｓ３２）。端末５００（Ａ）は、応答信号を受信すると、ＡＣＫを端末５００（Ｂ）に送信する（Ｓ３３）。
【００２６】
図４は、本実施形態による、端末発信時のメディア種別の決定方法として標準化されているＳＤＰ交換による端末間のセッション制御の他の例を示すシーケンス図である。図４に示すように、発信端末５００（Ａ）は、ＳＤＰを設定しないＩＮＶＩＴＥ（セッション接続信号）を送信し（Ｓ４１）、それを受信した着信端末５００（Ｂ）が自らのメディア処理能力からｏｆｆｅｒＢを設定して応答信号に乗せて送信し（Ｓ４２）、それを受けた端末５００（Ａ）がＡＣＫにａｎｓｗｅｒＡを乗せて送信する（Ｓ４３）。
【００２７】
上述した図３、図４に示す手順により、双方の端末５００（Ａ）、（Ｂ）の間でメディアネゴシエーションが行われ、端末５００（Ａ）、（Ｂ）の能力に応じたメディアが選択される。上述した例は、あくまで端末５００が発信する場合の手順であり、端末５００の間でセッション制御を行うゲートウェイ２００が端末５００間のセッション制御を行うセッション制御方法（サードパーティコールコントロール）に、そのまま適用することはできない。
【００２８】
ここで、図５乃至図７は、本実施形態による、ゲートウェイ２００のセッション制御ＡＰＩ２１０において制御されるセッションのメディア種別を決定する方法の例を示すシーケンス図である。図２に示すようなセッション制御ＡＰＩ２１０において制御されるセッションのメディア種別の決定については、図５に示すように、アプリケーション４１０から接続要求により制御ＡＰＩを呼び出す度に（Ｓ５１）、アプリケーション４１０が指定する方法や、図６に示すように、アプリケーション４１０からの接続要求では指定せず（Ｓ６１）、ゲートウェイ２００が設定ファイル等で静的に保持しているＳＤＰ情報を元にネゴシエーション（Ｓ６２、Ｓ６３）を行う方法や、図７に示すように、アプリケーション４１０からの接続要求では指定せず（Ｓ７１）、セッション制御信号のやりとり（Ｓ７２、Ｓ７３）の中で、端末間のネゴシエーションによって決定する方法が考えられる。
【００２９】
但し、図７に示した方法の実現方法については明らかにされていない。そこで、本発明では、ゲートウェイ２００における端末ＳＤＰ管理機能２１７と、呼制御ＡＰＩ２１１〜２１６とが、図８〜図１６に示すシーケンスに従って動作することにより、図７で示すようなセッション制御ＡＰＩを実現する。
【００３０】
［接続ＡＰＩ］
まず、接続ＡＰＩ２１１について説明する。
図８は、本実施形態による、接続ＡＰＩ２１１が呼び出された場合のシーケンス（ＲＦＣ３７２５（４．３．Ｐａｇｅ６）で示されているＦｌｏｗ３）図である。本シーケンスにおいて、アプリケーション４１０から端末５００（Ａ）、（Ｂ）間の接続要求がゲートウェイ２００に送信されると（Ｓ００１）、セッションを識別するセッションＩＤが返される（Ｓ００２）。アプリケーション４１０は、以降のセッション制御（切断等）を、当該セッションＩＤを用いて実施する。
【００３１】
ゲートウェイ２００では、接続要求受信後、通信ネットワーク１００を介して端末５００（Ａ）、（Ｂ）間の呼制御を行う（Ｓ００３〜Ｓ００５）。この呼制御が実施されると、端末５００（Ａ）が呼びだし〜通話状態となる。但し、この時点では、端末５００（Ｂ）のＳＤＰが不明であるため、端末５００（Ａ）には、ｂｈ−ＳＤＰを送信して無音状態としておく（Ｓ００５）。ｂｈ−ＳＤＰは、ＩＰアドレスに「０．０．０．０」が指定されたＳＤＰであり、このようなＳＤＰを受信した端末５００は、メディアの送信を停止する。その後、端末５００（Ａ）、（Ｂ）間のメディアネゴシエーションが行われ、通信が開始される（Ｓ００６〜Ｓ０１１）。
【００３２】
本方式の特徴としては、Ｓ００５で端末５００（Ａ）を無音状態で通話中にしておくことと、Ｓ００６でＳＤＰ無設定のＩＮＶＩＴＥを端末５００（Ｂ）に送信することにより、Ｓ００７にて応答信号で返ってきたＳＤＰ（ｏｆｆｅｒＢ）を、Ｓ００８にてｒｅ−ＩＮＶＩＴＥで端末５００（Ａ）に送信することにより、端末間でのメディアネゴシエーションを実現している点である。端末５００から送信されたＳＤＰを他方の端末に転送する場合（Ｓ００６〜Ｓ００７、Ｓ００９〜Ｓ０１０）に、ゲートウェイ２００でＳＤＰを書き換える場合もある。これは、ゲートウェイ２００を利用したセッション制御で故意にメディアの種別を変更する場合や、ゲートウェイ２００にてメディアの転送先を操作する場合（ゲートウェイ２００がメディア通信を仲介する場合など）等に行われる。当然、これらの変換処理が行われず、ＳＤＰをそのまま転送するシーケンスもあり得る。また、標準化での規定により、ｒｅ−ＩＮＶＩＴＥによるメディア更新には、以下のような制限事項がある。
【００３３】
［メディア更新時の制限事項］
（Ａ）ＳＤＰ更新する場合には、前回のＳＤＰと同数以上のｍ＝行（メディアタイプを指定する行）を含んでいる必要がある。
（Ｂ）ペイロードタイプ（メディアエンコード情報が指定されているａ行）を削除してはいけない。削除する場合には、ｍ行のポート番号を０で上書きしたＳＤＰでメディアネゴシエーション（ｒｅ−ＩＮＶＩＴＥ）することにより、端末からのメディア送信を停止［１］させ、その後、ｍ行を更新したＳＤＰで再度メディアネゴシエーション（ｒｅ−ＩＮＶＩＴＥ）を実施［２］する必要がある。
【００３４】
上記の制限事項により、接続中のある端末５００に対して接続先の変更・メディアタイプの変更を実施する時に、送信先のアドレス情報のみを更新する場合や、映像・音声を表すペイロードタイプの変更のみを追加する場合には、図９に示すように、アドレス情報を更新したＳＤＰをＩＮＶＩＴＥ／ｒｅ−ＩＮＶＩＴＥ処理の中で１回送信すればよい（Ｓ８４）。また、更新後に端末５００が利用するペイロードタイプを変更したい場合（ペイロードタイプを削除する場合）には、図１０に示すように、２回のｒｅ−ＩＮＶＩＴＥ送信（上記［１］と［２］）が必要になる場合がある（Ｓ９４、Ｓ９５）。本発明で示している各ＡＰＩシーケンスは、１回のｒｅ−ＩＮＶＩＴＥで完了した場合のみ示していたが、更新後のメディアタイプによっては、上述した図１０に示すような手順となることもある。このとき、ｒｅ−ＩＮＶＩＴＥ処理（Ｓ８４、Ｓ９４）によってコーデックが変更されるかどうかは、端末５００に送信したＳＤＰ情報（Ｓ８２、Ｓ９２）を保持していなければ判定できないため、本発明では、図２に示すように、端末毎のＳＤＰ情報を保持する端末ＳＤＰ管理機能２１７をゲートウェイ２００に設け、メディアネゴシエーションの結果を保持しておく。
【００３５】
また、図８に示すシーケンスをＩＰ電話網に適用した場合、Ｓ００４で端末５００（Ａ）の利用者が受話器を持ち上げてから、Ｓ０１１にて両者の通信が開始されるまで、端末５００（Ａ）の利用者は無音状態のまま待ち続けなければならないという問題がある。また、端末５００の中にｂｈ−ＳＤＰ非対応のものがあった場合、該シーケンスは適用できない。
【００３６】
図１１は、上記問題点を回避するための動作を説明するためのシーケンス図である。図１１において、基本的なシーケンスは、図８のシーケンスと変わらないが、Ｓ１０５にて暫定ＳＤＰを返し、端末５００（Ａ）には、メディア終端機能２１により自動音声を流しておくところが異なる。暫定ＳＤＰには、ゲートウェイ２００のアドレス等の任意のアドレスと任意メディア種別などが設定される。端末５００（Ａ）は、通常の端末とのセッション制御が行われると錯覚する。これにより、端末５００の中にｂｈ−ＳＤＰに非対応のものがあった場合でも、セッション制御が可能である。また、自動音声については、Ｓ１０４で指定された端末５００（Ａ）のＳＤＰ（ｏｆｆｅｒＡ）に対してメディア終端機能２１８を利用して自動音声を流す。自動音声としては、呼びだし音や、音声による案内の他、故意に無音を指定する場合もある。
【００３７】
［切断ＡＰＩ］
次に、切断ＡＰＩ２１２について説明する。
切断ＡＰＩ２１２については、ＲＦＣ３７２５（７．Ｐａｇｅ１０）の手順で実現可能である。これによれば、接続ＡＰＩ呼びだし時などに払い出されるセッションＩＤを指定された切断要求をゲートウェイ２００が受信すると、当該セッションに接続された、端末５００にＢＹＥを送信し、セッションを切断する。
【００３８】
［切り替えＡＰＩ］
次に、切り替えＡＰＩ２１３について説明する。
図１２は、本実施形態による、切り替えＡＰＩ２１３が呼び出された場合のシーケンス図である。まず、図１２のシーケンスでは、ゲートウェイ２００がアプリケーション４１０から切り替え要求を受信すると（Ｓ２０１）、アプリケーション４１０に応答を返し（Ｓ２０２）、その後、セッションＩＤ［１］で指定されたセッション［１］の端末５００（Ａ）の接続先を、端末５００（Ｂ）から端末５００（Ｃ）へ切り替える呼制御を実施する。
【００３９】
該呼制御では、まず、切り替え後に切断される端末５００（Ｂ）にＢＹＥを送信し、切断する（Ｓ２０３、Ｓ２０４）。次に、切り替え処理中に端末５００（Ａ）が無音状態となることを防ぐために、端末５００（Ａ）へのｒｅ−ＩＮＶＩＴＥ送信（Ｓ２０５〜Ｓ２０７）によって自動音声に接続させる。但し、該シーケンスにおいて、自動音声への接続（Ｓ２０５〜Ｓ２０７）は必須ではない。その後、端末５００（Ｃ）にＳＤＰ無設定のＩＮＶＩＴＥ送信し（Ｓ２０８）、応答して受け取ったｏｆｆｅｒＣを端末５００（Ａ）にｒｅ−ＩＮＶＩＴＥ送信することにより、端末５００（Ａ）、（Ｃ）間でのＳＤＰ交換が行われ（Ｓ２０８〜Ｓ２１３）、端末間でメディアネゴシエーションされたセッションが確立する。
【００４０】
但し、該シーケンスの制限事項として、端末５００（Ｃ）がＩＮＶＩＴＥ（Ｓ２０８）に対してビジー応答や、エラー応答などを返してきた場合、端末５００（Ａ）の接続先がなくなり、切断することになる。端末５００（Ｃ）がどのような応答を返してくるかは、ＩＮＶＩＴＥを送信してみなければ分からないため、切り替えを試行するが、端末５００（Ｃ）への接続に失敗した場合には、切り替え処理を実施しない、というＡＰＩ仕様を実現できない。
【００４１】
図１３は、図１２のシーケンスの制限事項である端末切り替え失敗時の処理を改善したシーケンス図である。該シーケンスでは、端末５００（Ｂ）の切断の前に端末５００（Ｃ）へのＩＮＶＩＴＥ送信を最初に実施する（Ｓ３０３）。そして、端末５００（Ｃ）から正常応答（２００  ＯＫ）が返ってくると（Ｓ３０４）、その後に端末５００（Ｂ）への切断処理を行い（Ｓ３０５、Ｓ３０６）、端末５００（Ａ）、（Ｃ）間のメディアネゴシエーションを行う（Ｓ３０７〜Ｓ３１０）。該シーケンスでは、端末５００（Ｃ）へのＩＮＶＩＴＥに対してビジー応答等のエラー応答が返ってきた場合に、以降の切り替え処理を中止することができる。
【００４２】
［分割ＡＰＩ］
次に、分割ＡＰＩ２１４について説明する。
図１４は、本実施形態による、分割ＡＰＩ２１４が呼び出された場合のシーケンス図である。図１４のシーケンスでは、ゲートウェイ２００がアプリケーション４１０からセッションＩＤ［１］に対する分割要求を受信すると（Ｓ４０１）、アプリケーション４１０に分割後に生成されるセッションＩＤ［２］を含む応答を返し（Ｓ４０２）、その後、セッションＩＤ［１］で指定されたセッション端末５００（Ａ）の接続先を端末５００（Ｂ）から端末５００（Ｃ）へ切り替え、端末５００（Ｂ）の接続先を端末５００（Ｄ）へ切り替え、セッションＩＤ［２］を確立する呼制御を実施する。
【００４３】
該呼制御では、まず、端末５００（Ｃ）にＳＤＰ無設定のＩＮＶＩＴＥを送信し（Ｓ４０３）、応答（２００  ＯＫ）を受信し（Ｓ４０４）、その後、端末５００（Ｂ）に分割処理中に自動音声を流すためのｒｅ−ＩＮＶＩＴＥを送信する（Ｓ４０５〜Ｓ４０７）。その後、端末５００（Ｃ）からの応答に乗っているＳＤＰ（ｏｆｆｅｒＣ）をｒｅ−ＩＮＶＩＴＥで端末５００（Ａ）に送信することにより、端末５００（Ａ）、（Ｃ）間のメディアネゴシエーションを実施しセッション［１］を確立させる（Ｓ４０８〜Ｓ４１１）。次に、端末５００（Ｄ）にＳＤＰ無設定のＩＮＶＩＴＥを送信し（Ｓ４１２）、応答（２００  ＯＫ）を受信し（Ｓ４１３）、その後、応答信号に乗っているＳＤＰ（ｏｆｆｅｒＤ’）を端末５００（Ｂ）に送信することにより、端末５００（Ｂ）、（Ｄ）間のメディアネゴシエーションを実施し、セッション［２］を確立させる（Ｓ４１４〜Ｓ４１７）。
【００４４】
［結合ＡＰＩ２１５］
次に、結合ＡＰＩ２１５について説明する。
図１５は、本実施形態による、結合ＡＰＩ２１５が呼び出された場合のシーケンス図である。図１５のシーケンスでは、ゲートウェイ２００がアプリケーション４１０から結合要求（Ｓ６０１）を受信すると、アプリケーション４１０に応答を返し（Ｓ６０２）、その後、アプリケーション４１０から指定されたセッション［１］の端末５００（Ａ）と、もう１つ指定されたセッション［２］の端末５００（Ｃ）を新たに接続させる呼制御を実施する。
【００４５】
該呼制御では、まず、結合対象でない端末５００（Ｂ）、端末（Ｄ）にＢＹＥを送信し、切断する（Ｓ６０３〜Ｓ６０６）。その後、端末５００（Ａ）、（Ｃ）間でメディアネゴシエーションを行う（Ｓ６０７〜Ｓ６１２）。端末５００（Ｃ）のｒｅ−ＩＮＶＩＴＥ送信時（Ｓ６０９）にＳＤＰとしてｏｆｆｅｒＡ’を設定しているが、これは、ｏｆｆｅｒＡと端末ＳＤＰ管理機能２１７で保持している値を利用して生成する。より詳細には、まず、端末５００（Ａ）のｒｅ−ＩＮＶＩＴＥ送信時（Ｓ６０７）にＳＤＰ無設定のｒｅ−ＩＮＶＩＴＥを送信し、応答として端末５００（Ａ）のｏｆｆｅｒＡを受信する。その後、端末５００（Ｃ）に対するｒｅ−ＩＮＶＩＴＥ生成時に、ｏｆｆｅｒＡと端末ＳＤＰ管理機能２１７で保持している端末５００（Ｃ）向けのＳＤＰの値を利用して、上記［メディア更新時の制限事項］に従ったメディア交換を実施する。このように、端末ＳＤＰ管理機能２１７を用いて、Ｓ６０７〜Ｓ６１２のメディアネゴシエーション処理を実施することにより、端末５００（Ａ）、（Ｃ）間のＳＤＰ交換によるセッション確立を実現できる。但し、該シーケンスの制限事項として、Ｓ６０７〜Ｓ６１２において、端末５００（Ａ）、（Ｃ）間のメディアネゴシエーションが失敗するなどのエラーが発生した場合、分割処理を実施しない、というＡＰＩ仕様を実現できない。
【００４６】
図１６は、図１５のシーケンスの制限事項である結合失敗時の処理を改善した動作を説明するためのシーケンス図である。該シーケンスでは、まず、端末５００（Ｂ）、（Ｄ）の切断の前に端末５００（Ａ）、（Ｃ）のメディアネゴシエーションを実施する（Ｓ７０３〜Ｓ７０６）。そして、メディアネゴシエーションが正常終了した後、端末５００（Ｂ）、（Ｄ）への切断処理を行う（Ｓ７０７〜Ｓ７１０）。該シーケンスでは、端末（Ａ）、（Ｃ）間のメディアネゴシエーションがエラー終了した場合であっても、以降の結合処理を中止することができる。
【００４７】
［呼制御イベント通知ＡＰＩ］
次に、呼制御イベント通知ＡＰＩ２１６について説明する。
図１７は、本実施形態による、呼制御イベント通知ＡＰＩ２１６が呼び出された場合のシーケンス図である。なお、図１７では、端末５００（Ａ）が端末５００（Ｂ’）に発信した場合のシーケンスを示している。ここで、端末５００（Ｂ’）の端末を識別するためのＵＲＩ（Uniform Resource Identifier）は、端末５００（Ｂ）と同一の場合もある。
【００４８】
端末５００（Ａ）が（Ｂ’）発信すると（Ｓ８０１）、直接、端末５００（Ｂ）にＩＮＶＩＴＥがルーチングされず、まず、ゲートウェイ２００がＩＮＶＩＴＥを受ける。端末発のＩＮＶＩＴＥを受けると、ゲート２００は、ＡからＢ’に着信したことを着信通知ＡＰＩとしてアプリケーション４１０に通知する（Ｓ８０２）。その際、セッションＩＤ［１］をアプリケーション４１０に通知することにより、アプリケーション４１０は、これ以降に呼制御ＡＰＩを用いたセッションの制御が可能となる。アプリケーション４１０は、イベント通知に対して応答を返す（Ｓ８０３）。応答には、セッションに対する制御情報（セッションを強制切断する、接続先を変更する等）を乗せることを可能とする。これにより、アプリケーション４１０による着信時のセッション制御動作指定を可能としている。
【００４９】
アプリケーション４１０から応答が返ってきた後、ゲートウェイ２００は、端末５００（Ｂ）にＩＮＶＩＴＥを転送し、セッション［１］の確立が行われる（Ｓ８０４〜Ｓ８０８）。その後、通信確立の通知をアプリケーション４１０に送信する（Ｓ８０９）。アプリケーション４１０は、受け取る通知（Ｓ８０２、Ｓ８０９）を、ゲートウェイ２００に対して事前に指定することを可能とする。但し、該シーケンスの問題点として、アプリケーション４１０の応答処理（Ｓ８０３）が遅れると、発信した端末５００（Ａ）への応答が遅くなり、無音状態が続いてしまうという問題が発生する可能性がある。
【００５０】
図１８は、上記問題を改善した動作を説明するためのシーケンス図である。図１８において、該シーケンスでは、Ｓ９０４でアプリケーション４１０へイベント（着信）を通知する前に、自動音声等に接続しておく（Ｓ９０１〜Ｓ９０３）。そして、アプリケーション４１０から応答が返った後（Ｓ９０５）、端末（Ａ）、（Ｂ）間のｒｅ−ＩＮＶＩＴＥ処理によりメディアネゴシエーションを行い、セッション［１］を確立する。これにより、アプリケーション４１０からの応答が遅れた場合でも、端末５００（Ａ）の無音時間を短縮することができる。
【００５１】
上述した実施形態によれば、以下の効果が得られる。
（１）アプリケーション４１０の開発者にとって利便性の高いセッション制御手段が提供され、通信ネットワーク１００上の端末５００間のセッション制御を利用した高度なサービスが開発可能となる。
（２）端末間メディアネゴシエーションをベースとしたセッション制御ＡＰＩが実現されることにより、音声・映像・データ等マルチメディア対応端末を対象としたサービス開発が容易に可能となる。
（３）着信イベント通知ＡＰＩの実現により、端末発信によって生成されたセッションの場合でも、セッション制御ＡＰＩとの組み合わせによる端末５００間のメディアネゴシエーションを利用したサービスアプリケーション開発が可能となる。
（４）端末５００に対しては、多くの端末でサポートされているセッション制御信号のみで構成されるセッション制御を行うため、多様なセッション制御を実現しつつも対応端末が制限されない。
【００５２】
なお、上述した端末５００、ゲートウェイ２００、及びアプリケーションサーバ４００などは、内部にコンピュータシステムを有していてもよい。そして、上述した端末５００、ゲートウェイ２００のセッション制御ＡＰＩ２１０、及びアプリケーションサーバ４００のアプリケーション４１０の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記録されており、この記録媒体に記録されたプログラムをコンピュータシステムが読み出して実行することにより、上記処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
【００５３】
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Dynamic Random Access Memory））のように、一定時間プログラムを保持しているものも含むものとする。また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【図面の簡単な説明】
【００５４】
【図１】本発明の一実施の形態によるゲートウェイ（セッション制御装置）を用いた情報通信システムの構成を示すブロック図である。
【図２】本実施形態によるゲートウェイ２００の構成を示すブロック図である。
【図３】本実施形態による、端末発信時のメディア種別の決定方法として標準化されているＳＤＰ交換による端末間のセッション制御の一例を示すシーケンス図である。
【図４】本実施形態による、端末発信時のメディア種別の決定方法として標準化されているＳＤＰ交換による端末間のセッション制御の他の例を示すシーケンス図である。
【図５】本実施形態による、ゲートウェイ２００のセッション制御ＡＰＩ２１０において制御されるセッションのメディア種別の決定する方法の例を示すシーケンス図である。
【図６】本実施形態による、ゲートウェイ２００のセッション制御ＡＰＩ２１０において制御されるセッションのメディア種別の決定する方法の例を示すシーケンス図である。
【図７】本実施形態による、ゲートウェイ２００のセッション制御ＡＰＩ２１０において制御されるセッションのメディア種別の決定する方法の例を示すシーケンス図である。
【図８】本実施形態による、接続ＡＰＩ２１１が呼び出された場合のシーケンス図である。
【図９】接続中のある端末５００に対して接続先の変更・メディアタイプの変更を実施する際のシーケンス図である。
【図１０】接続中のある端末５００ペイロードタイプの変更を実施する際のシーケンス図である。
【図１１】本実施形態による、接続ＡＰＩ２１１が呼び出された際の制限事項を回避するための動作を説明するためのシーケンス図である。
【図１２】本実施形態による、切り替えＡＰＩ２１３が呼び出された場合のシーケンス図である。
【図１３】本実施形態による、切り替えＡＰＩ２１３が呼び出された際の制限事項を回避するための動作を説明するためのシーケンス図である。
【図１４】本実施形態による、分割ＡＰＩ２１４が呼び出された場合のシーケンス図である。
【図１５】本実施形態による、結合ＡＰＩ２１５が呼び出された場合のシーケンス図である。
【図１６】本実施形態による、結合ＡＰＩ２１５が呼び出された際の制限事項を回避するための動作を説明するためのシーケンス図である。
【図１７】本実施形態による、呼制御イベント通知ＡＰＩ２１６が呼び出された場合のシーケンス図である。
【図１８】本実施形態による、呼制御イベント通知ＡＰＩ２１６が呼び出された際の問題を改善するための動作を説明するためのシーケンス図である。
【符号の説明】
【００５５】
１００  通信事業者ネットワーク
２００  ゲートウェイ
２１０  セッション制御ＡＰＩ
２１１  接続ＡＰＩ
２１２  切断ＡＰＩ
２１３  切り替えＡＰＩ
２１４  分割ＡＰＩ
２１５  結合ＡＰＩ
２１６  イベント通知ＡＰＩ
２１７  端末ＳＤＰ管理機能
２１８  メディア終端機能
３００  情報ネットワーク
４００  アプリケーションサーバ
４１０  アプリケーション
５００  端末
【図１】
2009223533.tif 000003
【図２】
2009223533.tif 000004
【図３】
2009223533.tif 000005
【図４】
2009223533.tif 000006
【図５】
2009223533.tif 000007
【図６】
2009223533.tif 000008
【図７】
2009223533.tif 000009
【図８】
2009223533.tif 000010
【図９】
2009223533.tif 000011
【図１０】
2009223533.tif 000012
【図１１】
2009223533.tif 000013
【図１２】
2009223533.tif 000014
【図１３】
2009223533.tif 000015
【図１４】
2009223533.tif 000016
【図１５】
2009223533.tif 000017
【図１６】
2009223533.tif 000018
【図１７】
2009223533.tif 000019
【図１８】
2009223533.tif 000020