SIP−HTTPアプリケーション相関器
本発明に係るシステムおよび方法は、異なる信号伝達プロトコルを使用する装置間の通信を容易にする。ゲートウェイが、SIPなどの第1のプロトコルの着信メッセージを解析し、メッセージのルーティング先とすべきアプリケーションインスタンスを識別することができる。そして、メッセージは別のプロトコルへ変換され、識別されたアプリケーションへ送信される。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般に電気通信システムと、電気通信システムにおける改善サービスに関する。
【背景技術】
【0002】
技術レベルが向上するにつれて、通信の選択肢は多種多様なものとなった。例えば、ここ30年間の電気通信産業において、個人通信は、一家に一台のダイヤル式電話機から、一家に複数の、音声にもデータにも対応した電話線、ケーブル線、および/または光ファイバ線へと発展した。また、通信においては、セルラ式電話やWi−Fiにより移動体(mobile element)が追加された。同様に、娯楽産業においては、30年前はテレビジョン用フォーマットが1つしかなく、家庭に設置されたアンテナによって、このフォーマットが無線で送受信されていた。これについても、標準画質TV(SDTV:standard definition TV)、拡張画質TV(EDTV:enhanced definition TV)、高画質TV(HDTV:high definition TV)など様々な画質の規格に発展し、またこれらの様々なテレビジョン表示フォーマットを配信するため、ケーブルや衛星などの多くのシステムに発展した。また、この2つの産業間にまたがってサービスが成長した。このようなシステムが双方の産業において発展し続けると、サービス提供の併合も続き、消費者にとっては新たなサービスも期待されよう。また、このようなサービスは、例えばテレビジョンで観る番組の画質の向上に見られるように、より多くの情報を処理して出力する技術能力に基づくものとなる。したがって、サービス配信における必要条件については、エンドユーザへの「最後の1マイル(last mile)」まで含んだネットワーク全体でより多くの帯域幅が使用可能となることに依存し続けるであろう。
【0003】
通信産業および娯楽産業の双方に影響を与える関連技術にはインターネットもある。1990年代始めからインターネットで使用されていたプロトコルの1つがハイパーテキスト転送プロトコル(HTTP:Hyper Text Transfer Protocol)である。このプロトコルは、まずはハイパーテキストマークアップ言語(HTML:Hyper Text Markup Language)ページにアクセスするためのものとして初期設計されたトランザクションベースのプロトコルであり、必ずしも、増加したデータフローを処理するように発展したインターネットの物理構造や関連する通信ストリームを処理するように設計されたものではない。例えば、サーバには以前よりも多くのメモリがあり、通信リンクには過去よりも高い帯域幅を有するものが存在し、プロセッサはより速く、より有能なものとなり、これらの要素の利用するプロトコルが存在する。消費者のインターネット利用が拡大するにつれて、サービス会社は、従来のサービスを提供する機構としてインターネット(および他のインターネットプロトコル(IP:Internet Protocol)ネットワーク)に専心した。例えばHTTP1.1などのHTTPの発展により、上記に関連したHTTPの能力が改善され、様々なハードウェア販売業者がその機器にHTTPを統合することに精通している。今や、以前の改善点を利用した新たなサービスが存在しており、その例としては、IPテレビジョン(IPTV。IPデータパケットを用い、ネットワークによってテレビジョン番組を配信するシステムやサービスを指す。)ビデオオンデマンド(VOD:video on demand)、ボイスオーバIP(VoIP:voice over IP)、単一あるいはまとめて受信される他のウェブ関連サービスなどが挙げられる。
【0004】
IPネットワークを用いて様々なサービスを提供する様々な新しい方法に対応するため、新たなネットワークアーキテクチャが開発され、規格化されている。IPマルチメディアサブシステム(IMS:IP Multimedia Subsystem)は、IPマルチメディアサービスをエンドユーザまで配信するために使用されるアーキテクチャフレームワークである。例えばセッション開始プロトコル(SIP:Session Initiation Protocol)などのIPプロトコルを用いて異種システムに収束機構を提供するサービス独立トポロジーへと、IMSアーキテクチャは発展した。これについては、アクセスネットワークをサービスレイヤから分離させる水平制御レイヤの提供によって達成される。とりわけ、IMSアーキテクチャは、IPTVシステムやIPTVサービスの展開に有用なプラットフォームを提供することができる。
【0005】
したがって、以下で説明する実施形態例は、異なる信号伝達プロトコルを使用する装置間の通信を容易にするネットワークエンティティおよび方法の必要性に取り組んだものである。
【発明の概要】
【発明が解決しようとする課題】
【0006】
本発明に係るシステムおよび方法は、異なる信号伝達プロトコルを使用する装置間の通信を容易にするネットワークエンティティおよび方法の必要性に取り組んだものである。
【課題を解決するための手段】
【0007】
実施形態例によれば、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ネットワークと非IMSノードとの間でアプリケーション情報を動的に相関させる方法が、ゲートウェイにおいて、第1の信号伝達プロトコルを使用する上記IMSネットワークから第1のメッセージを受信するステップと、上記第1のメッセージから情報を読み出すステップと、以前に記憶された情報と上記情報を相関させて、上記非IMSノードで動作する複数のアプリケーションのうちのいずれが上記第1のメッセージに関連しているかを判定するステップと、上記非IMSノードで動作する複数のアプリケーションのうちの、上記第1のメッセージに関連している1つに関連する情報を含む、上記第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用する第2のメッセージを、上記非IMSノードへ送信するステップとを含む。
【0008】
別の実施形態例によれば、ゲートウェイ装置が、メッセージを送受信する通信インタフェースであって、第1の信号伝達プロトコルを使用する第1の受信メッセージが、アプリケーションに関連する情報を含む、通信インタフェースと、アプリケーションIDと、ユニフォームリソースロケータ(URL)と、デフォルト情報と、IMS通信サービス識別子(ICSI)とを含む情報を記憶する記憶部と、上記第1の信号伝達プロトコルを使用する上記第1の受信メッセージと、記憶された上記情報とを相関させ、上記第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用する第2のメッセージのルーティング先のアプリケーションを識別する処理部であって、上記第2の信号伝達プロトコルを使用する上記第2のメッセージは、上記アプリケーションに関連する情報を含む、処理部とを備える。
【図面の簡単な説明】
【0009】
添付図面は実施形態例を示している。
【0010】
【図1】図1は、実施形態例に係る、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ネットワークとインターネットプロトコルテレビジョン端末機能(ITF:Internet Protocol Television Terminal Function)との間の信号伝達を示す。
【図2】図2は、実施形態例に係る、IMSゲートウェイと通信中の複数のアプリケーションを実行しているITFを示す。
【図3】図3は、実施形態例に係るIMSゲートウェイを示す。
【図4】図4は、実施形態例に係る、異なる種類のメッセージをITFへ送信するIMSゲートウェイを示す。
【図5a】図5aは、実施形態例に係る、情報を記憶するアプリケーション識別テーブルを示す。
【図5b】図5bは、実施形態例に係るトラフィックテーブルを示す。
【図6a】図6aは、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図6b】図6bは、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図7】図7は、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図8a】図8aは、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図8b】図8aは、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図9】図9は、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図10】図10は、実施形態例に係る通信ノードを示す。
【図11】図11は、実施形態例に係る、IMSネットワークと非IMSとの間でノードアプリケーション情報を相関させる方法フローチャートを示す。
【発明を実施するための形態】
【0011】
以下の実施形態例の詳細な説明では添付図面を参照する。異なる図面における同一参照番号は同一または同様のものを指している。また、以下の詳細な説明は本発明を限定するものではない。その代わりに、本発明の範囲は添付の特許請求の範囲によって限定される。
【0012】
ハイパーテキスト転送プロトコル(HTTP)およびセッション開始プロトコル(SIP)は、1または複数のネットワークによるサービス配信の支援に使用するプロトコルである。場合によっては、例えばインターネットプロトコルテレビジョン(IPTV)端末機能(ITF)などの製造業者のようなハードウェア販売業者がその製品でHTTPを使用するところ、インターネットプロトコルマルチメディアサブシステム(IMS)ネットワークアーキテクチャをサービスの配信に使用するサービスプロバイダがその製品にセッション開始プロトコル(SIP)を使用するということもあり得る。HTTPはトランザクションベースのプロトコルであるところ、SIPは、SIPエンドポイントを有する装置間の通信を可能とするセッションベースのプロトコルである。HTTPを使用するシステムは、例えばIPTV信号を伝送するHTTP信号伝達を用いて、サービスに関連したIMSを受信可能であるが、典型的には、上述のIMSネットワークアーキテクチャで使用されるSIPなど、新たなアーキテクチャで使用されるプロトコルは使用可能ではない。SIP信号伝達を用いる装置およびHTTP信号伝達を用いる装置は、あるプロトコルから、さらなる伝送のための他のプロトコルへ情報を転換するために、例えばIMSゲートウェイなどのインタフェースが必要であろう。この発想については、図1に示す構成要素例に関する上段に見られる。
【0013】
図1は、ITF2と、IMSゲートウェイ4と、IMSネットワーク10とを含んでいる。www.openiptvforum.orgで見られるようなオープンITF(OITF:Open ITF)必要条件にしたがうITFであればいかなるものであってもよいITF2と、IMSゲートウェイ4は、例えば家庭などの同一の一般的な場所に設置され、HTTP信号伝達を用いて互いに通信する。IMSゲートウェイ4は、SIP信号伝達を用いてIMSネットワーク10と通信する。この実施形態例では、認証およびセッション管理を行うコールセッション制御機能(CSCF:call session control function)6と、例えばメッセージング用ピアツーピア(P2P:peer-to-peer)通信イネーブラ14および一意のユニフォームリソースロケータ(URL:uniform resource locator)に関連したネットワークサーバ8の2つのアプリケーションサーバとを有するものとして、IMSネットワーク10を示している。IMSゲートウェイ4は、HTTP信号伝達およびSIP信号伝達の双方を用いる能力と、いずれかの側からの信号伝達要求を相関させる能力とを有する。より具体的には、IMSゲートウェイ4はSIPメッセージを受信し、例えばHTTP信号伝達などの非SIP信号伝達を用いて、本発明によって以下で説明するようなITF2で動作している正しいアプリケーションへ情報を送信する。HTTP信号伝達に関するさらなる情報については、1999年6月付のRequest for Comments(RFC:リクエストフォーコメント)22616で見られる。IMSネットワーク10は、単純化して、以下で説明する実施形態例における信号伝達処理を説明するために示したノードしか有していないように示してあるが、IMSネットワーク10では典型的により多くのノードが見られるものであり、一般的にIMSアーキテクチャおよびSIP信号伝達の詳細については、それぞれ、2007年3月付のThird Generation Partnership Project(3GPP:第3世代パートナーシッププロジェクト)Technical Specification(TS:技術仕様書)23.228 Version(バージョン)8および2002年6月付のRFC3261で見られる。
【0014】
実施形態例によれば、図2に示すように、ITF2は、例えばブラウザベースのアプリケーション1 202、ブラウザベースのアプリケーション2 204、ネイティブベースのアプリケーション1 210などの複数のアプリケーションと、例えばブラウザベースのアプリケーション3のインスタンス1 206、ブラウザベースのアプリケーション3のインスタンス2 208などの同一アプリケーションの複数のインスタンスとを実行しているものとすることができる。ブラウザベースのアプリケーションは分散型アプリケーション環境(DAE:distributed application environment)で動作することが可能であり、例えばプレゼンスおよびチャット/メッセージングのようなアプリケーションが挙げられる。ネイティブベースのアプリケーションは、登録およびプロファイル管理のようなITF埋込アプリケーションで動作することができる。しかしながら、ここでブラウザベースのもの、ネイティブベースのものに関するこれらのアプリケーション例は、純粋に例示的なものであり、当業者であれば、アプリケーションは、ブラウザベースとして開発されたものであるか、ネイティブベースとして開発されたものであるかによって限定されることはないということが理解されよう。また、図2に示すように、IMSゲートウェイ4は、恐らくはITF2で動作するアプリケーションのうちの1つに関する情報を含むSIPメッセージを受信する。IMSゲートウェイ4はこの情報を通知212としてITF2へ送信し、ITF2では、以下で説明するように所望のアプリケーションにこの通知が到達する。
【0015】
IMSゲートウェイ例4について、図3を参照しながら説明する。IMSゲートウェイ4は、IMSネットワーク10からの着信SIPメッセージ214を、ITF2で動作するアプリケーションと整合させる。IMSゲートウェイ4は、ITF2宛ての着信SIPメッセージ214がITF2における適切なアプリケーションへ送信されたものであることを保証する責任がある通知ルータ302を備える。この機能の支援のもと、この実施形態例によって、通知ルータ302は認証/セッション管理機能306とIMSゲートウェイ(IG)−ITFサーバ304とレジスタ308とを備える。認証/セッション管理機能306は、それ自体とその関連アプリケーションを有するITF2とに対するIMSネットワーク10による許可およびセッション管理のために使用される。IG−ITFサーバ304はITF2へメッセージを送信する。レジスタ308は、ITF2で支援されたアプリケーションに関する情報と、SIPセッション情報と、ユニフォームリソースロケータ(URL)情報とを有し、その他にも、例えばオペレータネットワークによって事前設定された識別情報なども有する。このような情報を用いて、ITF2で動作するアプリケーションを一意に識別し、着信SIPメッセージ214とその対応するITFアプリケーションとの正しい整合を行う。メッセージを送信するためにSIPメッセージ/ITFアプリケーションの関係を判定するときには、認証/セッション管理機能306もIG−ITFサーバ304もレジスタ308と通信する。また、これらの機能を用いて、必要に応じてレジスタ308に情報を加えることができる。この実施形態例に係るIMSゲートウェイ4は、ITF2で動作しているアプリケーションの知識と関連SIPダイアログ情報とを必要に応じて維持するステートフル(stateful)装置である。また、IMSゲートウェイ4は、ITF2に電源が入っている限り、このような状態をその記憶部(図3には示していないが、以下で説明する図10には示してある)に維持する。以下、アプリケーションについて、ITF2およびIMSゲートウェイ4の両視点から、より詳細に説明する。
【0016】
実施形態例によれば、複数のアプリケーションが同時にITF2で動作することが可能である。上述のように、これらのアプリケーションは、例えばDAEベースのアプリケーションおよびITF埋込アプリケーションのような、ITF2でサービスロジックを実行するアプリケーションの2つの一般的なカテゴリに分類することができる。IMSゲートウェイ4の視点からは(IMSゲートウェイ4はSIPを用いてIMSネットワーク10とのインタフェースを行う)、これらのアプリケーションは、例えばSIPダイアログおよび状態情報の有無(または必要性)に応じて、この実施形態に係る3つの異なる方法で、SIP通信とのインタフェースが行われる。
【0017】
このような実施形態に係るSIP通信とアプリケーションとのインタフェースを行う第1の方法は、例えばプレゼンスやセッションセットアップなどのSIPダイアログが必要なアプリケーションに関する。例えばIMSゲートウェイ4およびIMSノードなど、SIPエンドポイントを有する2つのエンティティが、SIPを用いた通信を行うと、SIPダイアログが発生する。他のアプリケーションではSIPダイアログを必要としない。かかる他のアプリケーションは、まずは、スタンドアローントランザクション型のアプリケーション(インスタントメッセージまたは登録)であり、SIPダイアログが必要ではない。IMSゲートウェイ4への着信SIPメッセージは、実施形態例に係るイベントを処理するための、例えば新たなメッセージ、既存のSIPダイアログに対するメッセージ、またはITF2のアプリケーションからの要求に対するメッセージ応答のような3つの種類のメッセージのうちの1つと見なすことが可能である。新たなメッセージは、例えば、既存のSIPダイアログがないSIP MESSAGEとすることができる。既存のメッセージは、例えば、既存のSIPダイアログに属するSIP NOTIFYとすることができる。メッセージ応答は、例えば、ITF2由来でIMSゲートウェイ4が正しく修正/送信したサービス要求メッセージなどのIMSゲートウェイ4による要求に応じたSIP 200 OKとすることができる。異なる処理が行われるこれら3つの通知イベントについて、以下でさらに詳細に説明する。
【0018】
実施形態例によれば、図4に示すように、IMSゲートウェイ4はITF2と通信し、通知イベントの種類に基づく異なる種類の通知を適切なアプリケーションへ配信する。まず、IMSゲートウェイ4は着信SIPメッセージ214を受信する。どの種類のイベントが受信されたのかを通知ルータ302が判定する。そして、通信ルータ302は、セッション中通知414または第三者通知416のいずれかを作成し、ITF2へ送信する。セッション中通知は、典型的には、ITF2のアクティブアプリケーションとIMSゲートウェイ4との間に進行中の通信がある場合に使用する。第三者通知は、典型的には、ITF2の非アクティブアプリケーションとの通信を開始する新たなメッセージに対して使用する。通知がセッション中通知414であった場合、この通知は、例えばDAE App1 408やDAE App2 412など、ITF2のブラウザ部404で目下動作中の適切なDAEアプリケーションへ送信される。通知が第三者通知416であった場合、この通知は、ITF2においてルータ機能と同様に機能する第三者通知処理部420へ送信される。
【0019】
そして、第三者通知処理部420は、受信した通知がDAEブラウザベースのアプリケーション402へ向かう必要があるのか、ITF埋込アプリケーション406へ向かう必要があるのか判定する。通知がDAEブラウザベースのアプリケーション402へ向かうものであった場合、ブラウザ404がDAEブラウザベースのアプリケーション402に対してアクセス可能なユニフォームリソースロケータ(URL)が送信される。受信した通知がITF埋込アプリケーション406へ向かうものであった場合、この通知は、アプリケーションプログラミングインタフェース(API:application programming interface)を通じて、使用を所望するITF埋込アプリケーション406へ送信される。また、図4には示していないが、初期サービス要求などのメッセージをITF2からIMSゲートウェイ4へ送信して、IMSネットワーク10へ送信することも可能である。
【0020】
上述のように、ITF2は、HTTP信号伝達を用いて、アクティブアプリケーションからの要求をIMSゲートウェイ4へ送信することができる。実施形態例によれば、特にIMSゲートウェイ4で受信するSIPメッセージの調整について、アプリケーションの正しい追跡を容易にするため、アプリケーションごとに一意のアプリケーションID(identification)を、ITF2からIMSゲートウェイ4へのHTTP要求メッセージへ挿入する。この要求は、ITF2で動作するDAEアプリケーション408、412、およびITF埋込アプリケーション406の両方に対して発生させることが可能である。DAEアプリケーション408、412、およびITF埋込アプリケーション406については、欧州電子計算機工業会(ECMA:European Computer Manufacturers Association)スクリプトを用いて、HTTP要求メッセージのヘッダまたはヘッダ拡張子へ一意のアプリケーションIDを挿入することができる。かかるアプリケーションIDについては、規格化されていることも、規格化されていないこともあるが、メッセージの適切なルーティングを容易にするためには一意であるべきである。一意性を保証する方法の1つとしては、一意性を表すプロパティを有するサービスユニフォームリソースネーム(URN:uniform resource name)でアプリケーションIDを表すことが挙げられる。URNについてのさらなる情報に関心がある読者は、1997年5月付のRFC2141を参照のこと。また、上述のように、この一意のアプリケーションIDをもつHTTP要求メッセージに新たなフィールドを追加することも可能である。
【0021】
実施形態例によれば、ITF2からのHTTP要求がIMSゲートウェイ4で受信されると、一意のアプリケーションIDは、対応するSIPダイアログとともに、また適用可能であれば記憶された状態とともに、IMSゲートウェイ4に維持される。また、HTTP要求が受信され、SIPダイアログが作成されると、IMSゲートウェイ4は、SIPダイアログについて、進行中のイベントの報告に使用する通知の種類に関する動的な情報を維持する。
【0022】
上述のように、IMSゲートウェイ4は、ITF2で動作するアプリケーションに関する情報とSIPダイアログ情報とを記憶する。実施形態例によれば、識別情報がレジスタ308に記憶されており、着信SIPメッセージ214からの情報を、ITF2で動作する正しいアプリケーションへ送信することが可能である。レジスタ308に識別情報を記憶するテーブル例500および520を、それぞれ図5(a)および5(b)に示す。レジスタ308のアプリケーション識別テーブル例500は、例えば、IMSゲートウェイ4が第三者通知の処理に用いることができる。より具体的に、この例では、アプリケーションテーブル500は、典型的にはサービスプロバイダ(SP:service provider)によって遠隔的に事前設定されたものであり、サービスプロバイダが提供するDAEアプリケーションに対するアプリケーションIDと、対応するDAEアプリケーションに使用されるURLとを有する。ITF埋込アプリケーションは、URLの使用を必要とせず、ホームネットワークインタフェース−IMSゲートウェイインタフェース(HNI-IGI:home network interface-IMS gateway interface)(図示せず)においてスタートアップの間にIMSゲートウェイ4に登録する。ITF2配置は、表示する能力と、ユーザとやり取りを行う能力とを有する。
【0023】
この実施形態によれば、着信SIPメッセージ214をアプリケーションに整合させるアシストに、およびIMS要求に対する順守についての発信SIPメッセージのチェックに、IMSゲートウェイ4が使用するものとして、IMS通信サービス識別子(ICSI:IMS communication service identifier)をアプリケーションごとに定めることができる。場合によっては、同一のアプリケーションの複数のインスタンスを同時にITF2で動作させることも可能である。この支援のもと、トラフィックテーブル例520は、IMSゲートウェイ4がアプリケーションのインスタントの異なるものどうしを区別できる情報を記憶する。テーブル500および520に記憶されたこれらの種々の識別情報を何度も用いて、IMSゲートウェイ4は、どの通知またはメッセージがITF2におけるどのアプリケーション(またはアプリケーションインスタンス)へルーティングすべきかを識別することができる。アプリケーション識別テーブル例500およびトラフィックテーブル例520について、以下でさらに詳細に説明する。また、アプリケーション識別テーブル500およびトラフィックテーブル520は、2つの別々のテーブルとして示してあるが、単一のテーブルに記憶することも可能であり、あるいは、情報を結びつけたままで2よりも多くのテーブルにさらに分散させることも可能である。
【0024】
図5(a)に示すように、アプリケーション識別テーブル500は、行502を読み取ると示されるように、必要に応じて、アプリケーションID504と、DAEアプリケーションに対して第三者通知で使用されるURL508と、ICSI506との間に結びつきを維持する。また、デフォルトURLを使用するデフォルトDAEアプリケーションも示してあるが、これについては、着信SIPメッセージがICSIまたはアプリケーションIDを有していない場合(アプリケーション識別テーブル500では「設定なし」という項目で示している)に使用可能である。アプリケーション識別テーブル500は、着信SIPメッセージがICSIと、アプリケーションIDとを含む場合、ICSIおよびアプリケーションIDの両方を含む場合、ICSIもアプリケーションIDも含まない場合にイベントの処理に使用する情報を通知ルータ308に提供する。この情報を他の情報とともに使用して、IMSゲートウェイ4はイベントを処理する。
【0025】
実施形態例によれば、図5(b)に示すように、トラフィックテーブル520はSIPダイアログ、または着信SIPメッセージ214の特定SIPヘッダにおけるアプリケーション識別情報と、アプリケーションインスタンスとの間の結びつきを維持する。各結びつきは、テーブル520において各項目522、524、526で示すように表されており、項目1 522はアプリケーションの第1インスタンスに結びつけられたSIPダイアログ(またはアプリケーション識別情報)を表し、項目2 524は同一アプリケーションの第2インスタンス、または異なるアプリケーションの第1インスタンスを表し、項目3 526は同一アプリケーションの第3インスタンス、またはITF2で目下動作中の異なるアプリケーションの第1インスタンスを表すものとすることができる。着信SIPメッセージ214を処理するために項目522、524、526が選択されると、項目522、524、526は、関連アプリケーションインスタンスへ向かう着信トラフィックに使用するTCPをIMSゲートウェイ4が一意に識別できるほど十分な状態情報を有するであろう。また、このようにTCPを使用することで、IMSゲートウェイ4は、例えばTCPが適切に終了することなどから、アプリケーションインスタンスがいつ終了したかを認識することが可能であり、例えば複数のTCPリンクが同時に手荒にシャットダウンされるなど、同一アプリケーションの異なるインスタンスの複数のTCPリンクが不適切に終了した場合のエラーリカバリも可能である。また、実施形態例によれば、トラフィックテーブル520に必要であれば、項目522、524、526に追加状態情報を記憶することも可能である。
【0026】
実施形態例によれば、様々なトラフィックシナリオによって、項目522、524、526を作成してトラフィックテーブル520に記憶することが必要となり得る。第1のシナリオでは、例えばメッセージおよび/または信号伝達などのトラフィックがITF2のアプリケーションから発信され、IMSゲートウェイ4へ送信される。IMSゲートウェイ4はSIPダイアログの維持を要求する。IMSゲートウェイ4は、IMSゲートウェイ4はIMSネットワーク10にセッション確立の要求を送信し、SIPダイアログが作成され、維持される。そして、項目522、524、526が作成され、トラフィックテーブル520に記憶される。トラフィックテーブル520は、アプリケーションインスタンスをSIPダイアログと結びつけて、例えばTCP情報などの他の必要な状態情報を記憶する。
【0027】
実施形態によれば、第2のシナリオでは、ITF2のアプリケーションからトラフィックが発信され、IMSゲートウェイ4へ送信されるが、SIPダイアログを作成して維持する必要はない。このシナリオでは、項目522、524、526をトラフィックテーブル520に作成する必要がない。その代わり、ITF2の発信アプリケーションに応じて、例えば発信アプリケーションが登録アプリケーション(など)である場合には、SIP状態を作成してIMSゲートウェイ4に記憶し、あるいは、例えば発信アプリケーションがインスタントメッセージングアプリケーション、スタンドアローントランザクションアプリケーション(など)である場合には、IMSネットワーク10とのやり取りが完了できたら、状態を維持しない。
【0028】
別の実施形態例によれば、第3のシナリオでは、SIPメッセージ214がIMSゲートウェイ4によってIMSネットワーク10から受信されるが、トラフィックテーブルに項目はない。この場合、IMSゲートウェイ4はアプリケーション識別テーブル500を用いて適切なアプリケーションを識別し、以下でさらに詳細に説明するように、ITF2の適切なアプリケーションへ要求を送信する。識別されたアプリケーションに応じて、トラフィックテーブル520に項目522、524、526を作成することができる。例えば、識別されたアプリケーションがSIPダイアログの維持を必要とする場合、IMSゲートウェイによってITF2からの成功応答を受信すると、続いて項目522、524、526を作成する。別の例では、識別されたアプリケーションがSIPダイアログの維持を必要としない場合、トラフィックテーブル520への項目522、524、526の作成および記憶は行わない。その代わり、トランザクションは完了され、全トランザクションが完了できるまで、IMSゲートウェイ4はステートフルのままである。さらに別の例では、識別されたアプリケーションがSIPダイアログを必要としてはいないが、着信メッセージに対してアクティブのままでいようとする場合、そのTCP接続を維持することによってこのことを示すことが可能であり、トラフィックテーブル520に項目522、524、526が作成され、維持される。
【0029】
したがって、実施形態によれば、IMSゲートウェイ4は、IMSネットワーク10からの様々な着信SIPメッセージを処理する。この様々な着信SIPメッセージは、IMSゲートウェイ4に利用可能な情報に応じて様々にITF2へ送信される通知を必要とする。第1の実施形態例では、IMSゲートウェイ4は、トラフィックテーブル520を調べることによって、着信SIPメッセージに関するSIPダイアログが以前に存在しているものであるか判定する。着信SIPメッセージに関するSIPダイアログが以前に存在しているものであれば、IMSゲートウェイ4によって、TCPリンクを通じて適切なアプリケーションインスタンスにセッション中通知が送信される。送信される通知には、受信SIPメッセージのペイロード部分(またはカプセル化バージョン)が含まれており、ペイロード部分は関連SIPヘッダを有している。
【0030】
SIP通信とのアプリケーションのインタフェースを行う第2の方法は、例えば登録など、SIPダイアログは必要ないが状態はIMSゲートウェイ4に維持されるアプリケーションに関する。別の実施形態例では、IMSゲートウェイ4は、既存のSIPダイアログがないSIPメッセージをIMSネットワーク10から受信する。しかしながら、この場合、意図するアプリケーションインスタンスをIMSゲートウェイが識別し、セッション中通知を使用して、適切なTCPリンクを通じてITF2の正しいアプリケーションインスタンスへ送信することができる状態情報が、そのためにトラフィックテーブル520に記憶されている。送信される通知には、受信SIPメッセージのペイロード部分(またはカプセル化バージョン)が含まれており、ペイロード部分は関連SIPヘッダを有している。
【0031】
SIP通知とのアプリケーションのインタフェースを行うこの第3の方法は、IMSゲートウェイ4の視点からは、例えばメッセージングおよび発呼者識別など、SIPダイアログも状態も必要としないアプリケーションに関する。別の実施形態例では、IMSゲートウェイ4は、対応するSIPダイアログも、トラフィックテーブル520に存在する目下維持されている状態情報もないSIPメッセージをIMSネットワーク10から受信する。この場合、アプリケーションIDの識別は、テーブル500を調べることが必要となり、また着信メッセージのコンテンツ、特にアクセプト−コンタクト(Accept-Contact:受入−連絡)SIPヘッダのコンテンツに依存する。実施形態例によれば、SIPヘッダのAアクセプト−コンタクトフィールドは、IMSゲートウェイ4がSIPメッセージをITF2で動作するアプリケーションと整合させることができる情報を含んだものとすることができる。SIPメッセージのアクセプト−コンタクトフィールドについてのさらなる情報に関心のある読者は、2004年付のRFC3841を参照のこと。この情報を用いて、IMSゲートウェイ4は、SIPメッセージをITF2のアプリケーションにリンクさせて、そのために第三者通知を使用して通知を送信する。送信される通知には、テーブル500における整合した項目から選択される情報に加えて、受信SIPメッセージのペイロード部分(カプセル化バージョン)が含まれており、ペイロード部分は関連SIPヘッダを有している。
【0032】
さらに別の実施形態例によれば、IMSゲートウェイ4は、ICSIのみを明示的に含むSIPメッセージをIMSネットワーク10から受信し、IMSゲートウェイ4はデフォルトアプリケーションIDを推測して使用する。アプリケーション識別テーブル500は、典型的には、必要であればICSIに使用するデフォルトアプリケーションIDを有する。例えば、図5(a)の行514および516に示すように、ICSI1およびICSI2はデフォルトアプリケーションIDに結び付けられている。このデフォルトアプリケーションIDを使用して、IMSゲートウェイ4は、受信した通知をITF2のデフォルトアプリケーションIDへ送信する。また、着信SIPメッセージがICSIもアプリケーションIDも含んでいない場合には、デフォルトURLを使用する。
【0033】
別の実施形態例によれば、IMSゲートウェイ4は、ICSIもアプリケーションIDも明示的に含むSIPメッセージをIMSネットワーク10から受信し、ルータ機能302は、アプリケーション識別テーブル500を調べることによって、受信した通知を、ITF2で動作するアプリケーションにリンクさせることができる。この場合、IMSゲートウェイ4は、例えば第三者通知など、識別したアプリケーションへの送信用の通知情報を含むメッセージをITF2へ送信する。送信される通知には、テーブル500における整合した項目から選択される情報に加えて、受信SIPメッセージのペイロード部分(カプセル化バージョン)が含まれており、ペイロード部分は関連SIPヘッダを有している。
【0034】
IMSゲートウェイ4がSIPメッセージを受信し、セッション中通知なのか第三者通知なのか判定した後、IMSゲートウェイ4は通知を適切に送信する。例えば、SIPメッセージがセッション中通知である場合は、典型的には状態情報によって判定されるのだが、IMSゲートウェイ4は、HTTP信号伝達または他の信号伝達方式を使用して、ITF2で動作する適切なアプリケーションへ通知情報を送信する。通知が第三者通知であると判定されると、通知情報はITF2の第三者通知処理部420へ送信され、第三者通知処理部420は、例えばITF埋込アプリケーション406やDAEブラウザアプリケーション402などの正しいアプリケーションへ通知情報を送信する。第三者通知処理部420は、この判定を、第三者通知メッセージ416で受信した情報に基づいて行う。まず、第三者通知処理部420は、第三者通知メッセージ416においてアプリケーションIDを探す。アプリケーションIDがあっても、第三者通知処理部420が認識しなければ、含まれているURLを使用して、ネットワークアプリケーションDAEに要求を処理させる。第三者通知処理部420がアプリケーションIDを認識する場合は、第三者通知処理部420は、必要なアプリケーションがITF埋込アプリケーション406であると考え、それに応じて、適切なAPIを使用して通知を送信する。
【0035】
他の実施形態例によれば、ITF2から要求を発生させて、IMSゲートウェイ4からIMSネットワーク10へ発信トラフィックを送信することも可能である。続いて受信した着信SIPメッセージを必要なアプリケーションに整合させることなど、様々な方法を用いて、発信アプリケーションを一意に識別することができる。例えば、DAEアプリケーション408、412、またはITF埋込アプリケーション406がメッセージを発信すると、新たなHTTPヘッダにアプリケーションIDを埋め込むことが可能であり、アプリケーションIDは、IMSゲートウェイ4によって抽出される。あるいは、DAEアプリケーション408、412、およびITF埋込アプリケーション406は、新たなHTTPヘッダにICSIを含めることが可能であり、ICSIは、SIPヘッダにおける追加情報とともに、IMSゲートウェイ4がアプリケーション識別テーブル500に関連して使用して、アプリケーションIDの位置を突き止めることができる。
【0036】
ここで図6〜9を参照しながら、上述のシステム例および方法例に基づいた信号伝達図例について説明する。図6(a)は、ITF2において目下アクティブなメッセージングアプリケーションがなく、SIPメッセージ受信して、メッセージングアプリケーションを開始する信号伝達図例を示している。まず、「appid=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE602がP2P通信イネーブラ12からCSCF6へ送信され、CSCF6は、SIP MESSAGE602をIMSゲートウェイ4内の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、トラフィックテーブル520を調べ、着信SIPメッセージに整合する項目がないことを確認する。そして、IMSゲートウェイは、アプリケーション識別テーブル500を調べ、例えば「appid=MESSAGING」などの受信したアクセプト−コンタクトヘッダ情報に、および必要に応じてテーブル500の情報に基づいて、アプリケーションIDの位置を突き止める。そして、認証/セッション管理機能306が、メッセージ604を送信して、IG−ITFサーバ304へ第三者通知を呼び出す。そして、IG−ITFサーバ304は、メッセージ606を送信して、アプリケーションID(「appid」)とURL(アプリケーション識別テーブル500から取得)とを含む第三者通知をITF2へ呼び出す。
【0037】
この例では、ITF2の第三者通知処理部420は、受信したappidを認識せず、その代わりにITF2が、メッセージ614に示すように、受信したURLを使用してアプリケーションを取得する。ネットワークサーバ8がHTTP Get URLメッセージ614を受信したら、メッセージ616に示すように、ECMAスクリプトを用いたジェネリックDAEアプリケーションハンドラを含む200 OKメッセージがITF2へ返信される。ほぼ同時に、IG−ITFサーバ304は認証/セッション管理機能306にオペレーション結果608を返信する。オペレーション結果608に基づいて、認証/セッション管理機能306は、202 ACCEPTEDメッセージをCSCF6へ送信し、CSCF6は202 ACCEPTEDメッセージをP2P通信イネーブラ12へ送信する。メッセージングアプリケーションがアクティブのままでいることを望めば、TCP接続を維持する。そして、IMSゲートウェイ4はトラフィックテーブル520に項目を作成して、追加SIPとアプリケーション関連状態情報とを維持する。これにより、着信SIPメッセージがメッセージアプリケーション宛てである場合、この場合に第三者通知を使用するのとは対照的に、セッション中通知を使用して、メッセージングアプリケーションを後に呼び出すことができる。
【0038】
実施形態例によれば、図6(b)は、ITF2においてメッセージングDAEが目下アクティブに動作しており、IG−ITFサーバ304との永久的TCP接続を有している場合に、メッセージングアプリケーションに関するSIPメッセージを受信する信号伝達図例を示している。まず、情報「appid=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE618がP2P通信イネーブラ12からCSCF6へ送信され、CSCF6は、SIP MESSAGE618をIMSゲートウェイ4内の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、トラフィックテーブル520を調べ、SIP MESSAGE618のアクセプト−コンタクトヘッダに基づいて着信SIPメッセージを処理可能な項目の位置を突き止める。また、そのステートフル能力に基づいて、IMSゲートウェイ4は、DAEメッセージアプリケーションがITF2で目下動作中であり、そのためセッション中通知を使用すべきであることがわかる。そして、認証/セッション管理機能306が、メッセージ620を送信して、IG−ITFサーバ304へ第三者通知を呼び出す。そして、IG−ITFサーバ304は、拡張可能マークアップ言語(XML:extensible markup language)を使用可能なITF2へのセッション中通知を呼び出すためのメッセージ622を送信する。そして、IG−ITFサーバ304から認証/セッション管理機能306にオペレーション結果メッセージ624が送信される。そして、認証/セッション管理機能306は202 Acceptedメッセージ626をCSCF6へ送信し、CSCF6は202 Acceptedメッセージ628をP2P通信イネーブラ12へ送信する。
【0039】
実施形態によれば、図7は、ITF2がプレゼンスアプリケーションで動作している場合の信号伝達例を示している。まず、事前に取得されているもので、プレゼンス通知のためにIG−ITFサーバ304とのTCP接続を確立するプレゼンスアプリケーションを、ユーザが開始する。これにより、トラフィックテーブル520に項目が作成され、IMSゲートウェイ4はこの項目を使用して、同一ダイアログに関連する着信SIPプレゼンス通知メッセージを整合させることができる。さらにこれにより、IMSゲートウェイ4はセッション中通知を使用して、着信プレゼンス通知メッセージをITF2のプレゼンスアプリケーションに送信することが可能となる。プレゼンス情報を含むSIP NOTIFYメッセージ702をP2P通信イネーブラ12からCSCF6を介して受信すると、IMSゲートウェイ4は、トラフィックテーブル520の適切なSIPダイアログとメッセージ702を整合させ、適切なアプリケーションインスタンスを選択する。また、IMSゲートウェイ4は、この場合にはセッション中通知を使用すべきであることがわかる。そして、認証/セッション管理機能306は、メッセージ704を送信して、IG−ITFサーバ304へセッション中通知を呼び出す。そして、IG−ITFサーバ304は、XMLとすることが可能な着信NOTIFYを含むセッション中通知を呼び出すためのITF2へのメッセージ706を送信する。そして、IG−ITFサーバ304から認証/セッション管理機能306にオペレーション結果メッセージ708が送信される。そして、認証/セッション管理機能306は200 OKメッセージ710をCSCF6へ送信し、CSCF6は200 OKメッセージ710をP2P通信イネーブラ12へ送信する。
【0040】
実施形態例によれば、図8(a)は、ITF埋込アプリケーションを使用したメッセージングの場合の信号伝達例を示している。まず、P2P通信イネーブラ12が、「ICSI=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE802をCSCF6へ送信し、CSCF6は、SIP MESSAGE802をIMSゲートウェイ4の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、アクセプト−コンタクトにおける情報を取り、トラフィックテーブル520を調べ、着信SIPメッセージに整合する項目がないことを確認する。そして、IMSゲートウェイは、アプリケーション識別テーブル500を調べ、例えばテーブル500の同一行511に見られるようなアプリケーションIDに結び付けられているテーブル500に記憶されたICSIに、受信したICSIを整合させる。認証/セッション管理機能306は、ITF2へのアプリケーションIDを含む第三者通知をITF2が呼び出すための情報を有するメッセージ804をIG−ITFサーバ304へ送信する。ITF2の第三者通知処理部420は、メッセージ806を受信してアプリケーションIDを認識し、ITF2は埋込メッセージングアプリケーションを起動する。例えば、メッセージング用のDAEブラウザベースのアプリケーション402の代わりに、メッセージング用のITF埋込アプリケーション406が起動される。そして、IG−ITFサーバ304から認証/セッション管理機能306へオペレーション結果が送信される。そして、認証/セッション管理機能306は202 Acceptedメッセージ810をCSCF6へ送信し、CSCF6は202 Acceptedメッセージ812をP2P通信イネーブラ12へ送信する。ITF埋込アプリケーション406はアクティブのままでTCP接続を維持することを選択可能であり、その場合は、セッション中通知を使用して、このアプリケーション宛の後続の着信メッセージを配信できる項目を、IMSゲートウェイ4がトラフィックテーブル520に作成する。
【0041】
実施形態例によれば、図8(b)は、IG−ITFサーバ304とのTCP接続を有するITF2おいてアクティブな埋込メッセージアプリケーションが目下動作している場合に、メッセージングアプリケーションに関するSIPメッセージを受信する信号伝達例を示している。まず、情報「ICSI=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE814がP2P通信イネーブラ12からCSCF6へ送信され、CSCF6は、SIP MESSAGE814をIMSゲートウェイ4内の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、トラフィックテーブル520を調べ、SIP MESSAGE814のアクセプト−コンタクトヘッダの情報に基づいて着信メッセージを処理可能な項目の位置を突き止める。そのステートフル能力に基づいて、IMSゲートウェイ4は、セッション中通知を使用すべきであることがわかる。そして、認証/セッション管理機能306が、メッセージ816を送信して、IG−ITFサーバ304へ第三者通知を呼び出す。そして、IG−ITFサーバ304は、メッセージ622をITF2へ送信し、XMLとすることができる情報を含むセッション中通知を呼び出す。そして、IG−ITFサーバ304から認証/セッション管理機能306にオペレーション結果メッセージ820が送信される。そして、認証/セッション管理機能306は202 Acceptedメッセージ822をCSCF6へ送信し、CSCF6は202 Acceptedメッセージ824をP2P通信イネーブラ12へ送信する。
【0042】
実施形態によれば、図9は、IMSゲートウェイ4においてアプリケーションIDまたはICSIを含まないSIPメッセージを受信する信号伝達例を示している。まず、P2P通信イネーブラ12がSIP PUBLISHメッセージ902をCSCF6へ送信し、CSCF6はSIP PUBLISHメッセージ902をIMSゲートウェイ4の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、受信したSIP PUBLISHメッセージ902のアクセプト−コンタクトヘッダにアプリケーションIDもICSIも欠如していることに気づき、そのためトラフィックテーブル520を調べずに、むしろアプリケーション識別テーブル500を調べて、デフォルトURLを有するアプリケーションをテーブル500から取る。認証/セッション管理機能306はメッセージ904を送信し、IG−ITFサーバ304への第三者通知を呼び出す。そして、IG−ITFサーバ304はメッセージ906を送信し、テーブル500から得られるデフォルトURLを含む第三者通知を呼び出す。ITF2はメッセージ906を受信し、第三者通知処理部420はアプリケーションIDを確認せず、その代わり、供給されたURLを使用して、DAEアプリケーションを取得して、ネットワークサーバ8へ送信されるHTTP Get URLメッセージ908に示すように、この要求を処理する。ネットワークサーバ8は、ITF2に対して、DAEデフォルトアプリケーションハンドラ(典型的にはいくつかの拡張可能ハイパーテキストマークアップ言語(XHTML:extensible hyper text markup language)命令とEcmaスクリプト命令とを含む)を含む200 OKメッセージ910で応答する。そして、IG−ITFサーバ304から認証/セッション管理機能306にオペレーション結果メッセージ912が送信される。そして、認証/セッション管理機能306は200 OKメッセージ914をCSCF6へ送信し、CSCF6は200 OKメッセージ916をP2P通信イネーブラ12へ送信する。
【0043】
上述のシステムおよび方法を使用する実施形態例によれば、IMSゲートウェイ4は、ITF2との複数のTCPリンクの損失のような様々なエラーに対してエラーリカバリを行う能力を有するものとすることができる。この場合、複数のアプリケーションインスタンスがITF2において目下アクティブであり、各アプリケーションインスタンスは、IMSゲートウェイ4との通信に対して、異なるTCPリンクをアップさせるであろう。TCPリンクは、アプリケーションインスタンスがアップし、動作している限り、アップしているであろう。TCPリンクがダウンすると、IMSゲートウェイ4はTCPリンクの損失を検出し、設定可能タイマに基づいて、IMSゲートウェイ4がトラフィックテーブル520において適当な項目522、524、526を更新できる新たなリンクをアプリケーションインスタンスが再確立するまで、例えば約40〜60秒間、待機する。
【0044】
実施形態によれば、TCPリンクの再確立に関するタイマが満了すると、IMSゲートウェイ4は、アプリケーションインスタンスが終了したと想定し、対応するネットワーク側通信の終了およびトラフィックテーブル520からの項目522、524、または526の削除に進行する。アプリケーションインスタンスが終了していなければ、IMSゲートウェイ4は、典型的に、TCPリンク再確立の一部としてSIP UPDATEと等しいものをIMSゲートウェイ4のピアへ送信する。これにより、SIP状態情報は変更されず、IMSゲートウェイ4が、リンク不具合が複数ある場合のエラーリカバリを処理できる。同一アプリケーションの複数のインスタンスに複数のリンク不具合があるこの場合では、IMSゲートウェイ4は、トラフィックテーブル520に記憶された状態情報と関連してSIP UPDATEメッセージの情報を使用して、意図されたアプリケーションインスタンスを一意に識別して、エラーリカバリを成功させることができる。
【0045】
上述の実施形態例は、人対人の通信に関するメッセージおよびプロトコルを与える。IMSゲートウェイ4の機能を行うことが可能な通信ノード例1000について、図10を参照しながら説明する。通信ノード1000は、処理部1002(または複数の処理コア)と、記憶部1004と、1または2以上の2次格納装置1006と、インタフェース1008とを有するものとして、通信ノード1000と他のネットワークおよび装置との間の通信を容易にすることができる。記憶部1004および/または2次格納装置1006を使用して、状態情報とテーブル500および520とを記憶することができる。ロジックおよびプロトコルも、通信ノード1000内に記憶し、処理部1002が通知の種類を決定するために、またIMSゲートウェイ4がその他すべての上述した機能例を行うために使用することが可能である。
【0046】
実施形態例に係る上述のシステム例を使用して、異なるプロトコルを使用する装置間の通信を容易にする方法を、図11のフローチャートに示す。まず、インターネットマルチメディアサブシステム(IMS)ネットワークと非IMSノードとの間でアプリケーション情報を相関させる方法が、ゲートウェイにおいて、ステップ1102において第1の信号伝達プロトコルを使用して、IMSネットワークから第1のメッセージを受信すること;ステップ1104において第1のメッセージから情報を読み出すこと;ステップ1106において、この情報を、以前に記憶された情報と相関させて、非IMSノードで動作する複数のアプリケーションのうちのいずれが第1のメッセージに関連しているかを判定すること;ステップ118において、第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用して、非IMSノードで動作する複数のアプリケーションのうちの、第1のメッセージに関連しているものに関する情報を含む第2のメッセージを、非IMSノードへ送信すること;を含む。
【0047】
当業者によって了解されるように、図11に示すような方法は、ソフトウェアで全体的または部分的に実施することが可能である。したがって、本発明の実施形態例にしたがってデータを処理するシステムおよび方法は、記憶装置に含まれた命令のシーケンスを実行する1または2以上の処理部によって実行することが可能である。このような命令は、固定媒体、リムーバブル媒体、またはリモート媒体(ネットワーク格納部)とすることができる2次データ格納装置1006などの他のコンピュータ読出可能媒体から記憶装置1004へ読み出すものとすることも可能である。記憶装置に含まれた命令のシーケンスの実行は、例えば上述のように処理部に動作させる。代替の実施形態では、有線回路を、ソフトウェア命令の代わりに、またはソフトウェアと組み合わせて、実施形態例を実施することが可能である。
【0048】
上述の実施形態例は、本発明の全ての点において例示的なものとしたつもりであり、限定的なものとするつもりはない。かかる変更点や修正点はすべて、特許請求の範囲に記載の本発明の範囲および意図の内であると考えられるものである。例えば、1つの家庭で複数のITF2がIMSゲートウェイ4と通信しているものとすることも可能であり、この場合でも、IMSゲートウェイ4は、例えばテーブル500および520に追加情報を記憶しておいてITFで動作しているアプリケーションを参照することなどによって、通信中のITF2におけるアプリケーションを一意に識別可能である。加えて、上述のサービス例は純粋に例示的なものであり、他のIMSサービスは上述のシステムおよび方法によって支援可能である。本願明細書において使用した構成、動作、または命令は、明示的な記載がない限り、本発明に対して決定的または本質的なものとして解釈すべきものではない。また、ここで使用した冠詞「a」は1または2以上の項目を含むものと意図している。
【技術分野】
【0001】
本発明は、一般に電気通信システムと、電気通信システムにおける改善サービスに関する。
【背景技術】
【0002】
技術レベルが向上するにつれて、通信の選択肢は多種多様なものとなった。例えば、ここ30年間の電気通信産業において、個人通信は、一家に一台のダイヤル式電話機から、一家に複数の、音声にもデータにも対応した電話線、ケーブル線、および/または光ファイバ線へと発展した。また、通信においては、セルラ式電話やWi−Fiにより移動体(mobile element)が追加された。同様に、娯楽産業においては、30年前はテレビジョン用フォーマットが1つしかなく、家庭に設置されたアンテナによって、このフォーマットが無線で送受信されていた。これについても、標準画質TV(SDTV:standard definition TV)、拡張画質TV(EDTV:enhanced definition TV)、高画質TV(HDTV:high definition TV)など様々な画質の規格に発展し、またこれらの様々なテレビジョン表示フォーマットを配信するため、ケーブルや衛星などの多くのシステムに発展した。また、この2つの産業間にまたがってサービスが成長した。このようなシステムが双方の産業において発展し続けると、サービス提供の併合も続き、消費者にとっては新たなサービスも期待されよう。また、このようなサービスは、例えばテレビジョンで観る番組の画質の向上に見られるように、より多くの情報を処理して出力する技術能力に基づくものとなる。したがって、サービス配信における必要条件については、エンドユーザへの「最後の1マイル(last mile)」まで含んだネットワーク全体でより多くの帯域幅が使用可能となることに依存し続けるであろう。
【0003】
通信産業および娯楽産業の双方に影響を与える関連技術にはインターネットもある。1990年代始めからインターネットで使用されていたプロトコルの1つがハイパーテキスト転送プロトコル(HTTP:Hyper Text Transfer Protocol)である。このプロトコルは、まずはハイパーテキストマークアップ言語(HTML:Hyper Text Markup Language)ページにアクセスするためのものとして初期設計されたトランザクションベースのプロトコルであり、必ずしも、増加したデータフローを処理するように発展したインターネットの物理構造や関連する通信ストリームを処理するように設計されたものではない。例えば、サーバには以前よりも多くのメモリがあり、通信リンクには過去よりも高い帯域幅を有するものが存在し、プロセッサはより速く、より有能なものとなり、これらの要素の利用するプロトコルが存在する。消費者のインターネット利用が拡大するにつれて、サービス会社は、従来のサービスを提供する機構としてインターネット(および他のインターネットプロトコル(IP:Internet Protocol)ネットワーク)に専心した。例えばHTTP1.1などのHTTPの発展により、上記に関連したHTTPの能力が改善され、様々なハードウェア販売業者がその機器にHTTPを統合することに精通している。今や、以前の改善点を利用した新たなサービスが存在しており、その例としては、IPテレビジョン(IPTV。IPデータパケットを用い、ネットワークによってテレビジョン番組を配信するシステムやサービスを指す。)ビデオオンデマンド(VOD:video on demand)、ボイスオーバIP(VoIP:voice over IP)、単一あるいはまとめて受信される他のウェブ関連サービスなどが挙げられる。
【0004】
IPネットワークを用いて様々なサービスを提供する様々な新しい方法に対応するため、新たなネットワークアーキテクチャが開発され、規格化されている。IPマルチメディアサブシステム(IMS:IP Multimedia Subsystem)は、IPマルチメディアサービスをエンドユーザまで配信するために使用されるアーキテクチャフレームワークである。例えばセッション開始プロトコル(SIP:Session Initiation Protocol)などのIPプロトコルを用いて異種システムに収束機構を提供するサービス独立トポロジーへと、IMSアーキテクチャは発展した。これについては、アクセスネットワークをサービスレイヤから分離させる水平制御レイヤの提供によって達成される。とりわけ、IMSアーキテクチャは、IPTVシステムやIPTVサービスの展開に有用なプラットフォームを提供することができる。
【0005】
したがって、以下で説明する実施形態例は、異なる信号伝達プロトコルを使用する装置間の通信を容易にするネットワークエンティティおよび方法の必要性に取り組んだものである。
【発明の概要】
【発明が解決しようとする課題】
【0006】
本発明に係るシステムおよび方法は、異なる信号伝達プロトコルを使用する装置間の通信を容易にするネットワークエンティティおよび方法の必要性に取り組んだものである。
【課題を解決するための手段】
【0007】
実施形態例によれば、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ネットワークと非IMSノードとの間でアプリケーション情報を動的に相関させる方法が、ゲートウェイにおいて、第1の信号伝達プロトコルを使用する上記IMSネットワークから第1のメッセージを受信するステップと、上記第1のメッセージから情報を読み出すステップと、以前に記憶された情報と上記情報を相関させて、上記非IMSノードで動作する複数のアプリケーションのうちのいずれが上記第1のメッセージに関連しているかを判定するステップと、上記非IMSノードで動作する複数のアプリケーションのうちの、上記第1のメッセージに関連している1つに関連する情報を含む、上記第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用する第2のメッセージを、上記非IMSノードへ送信するステップとを含む。
【0008】
別の実施形態例によれば、ゲートウェイ装置が、メッセージを送受信する通信インタフェースであって、第1の信号伝達プロトコルを使用する第1の受信メッセージが、アプリケーションに関連する情報を含む、通信インタフェースと、アプリケーションIDと、ユニフォームリソースロケータ(URL)と、デフォルト情報と、IMS通信サービス識別子(ICSI)とを含む情報を記憶する記憶部と、上記第1の信号伝達プロトコルを使用する上記第1の受信メッセージと、記憶された上記情報とを相関させ、上記第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用する第2のメッセージのルーティング先のアプリケーションを識別する処理部であって、上記第2の信号伝達プロトコルを使用する上記第2のメッセージは、上記アプリケーションに関連する情報を含む、処理部とを備える。
【図面の簡単な説明】
【0009】
添付図面は実施形態例を示している。
【0010】
【図1】図1は、実施形態例に係る、インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ネットワークとインターネットプロトコルテレビジョン端末機能(ITF:Internet Protocol Television Terminal Function)との間の信号伝達を示す。
【図2】図2は、実施形態例に係る、IMSゲートウェイと通信中の複数のアプリケーションを実行しているITFを示す。
【図3】図3は、実施形態例に係るIMSゲートウェイを示す。
【図4】図4は、実施形態例に係る、異なる種類のメッセージをITFへ送信するIMSゲートウェイを示す。
【図5a】図5aは、実施形態例に係る、情報を記憶するアプリケーション識別テーブルを示す。
【図5b】図5bは、実施形態例に係るトラフィックテーブルを示す。
【図6a】図6aは、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図6b】図6bは、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図7】図7は、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図8a】図8aは、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図8b】図8aは、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図9】図9は、実施形態例に係る、アプリケーションにアクセスするIMSゲートウェイにおけるSIP信号伝達を示す信号伝達図である。
【図10】図10は、実施形態例に係る通信ノードを示す。
【図11】図11は、実施形態例に係る、IMSネットワークと非IMSとの間でノードアプリケーション情報を相関させる方法フローチャートを示す。
【発明を実施するための形態】
【0011】
以下の実施形態例の詳細な説明では添付図面を参照する。異なる図面における同一参照番号は同一または同様のものを指している。また、以下の詳細な説明は本発明を限定するものではない。その代わりに、本発明の範囲は添付の特許請求の範囲によって限定される。
【0012】
ハイパーテキスト転送プロトコル(HTTP)およびセッション開始プロトコル(SIP)は、1または複数のネットワークによるサービス配信の支援に使用するプロトコルである。場合によっては、例えばインターネットプロトコルテレビジョン(IPTV)端末機能(ITF)などの製造業者のようなハードウェア販売業者がその製品でHTTPを使用するところ、インターネットプロトコルマルチメディアサブシステム(IMS)ネットワークアーキテクチャをサービスの配信に使用するサービスプロバイダがその製品にセッション開始プロトコル(SIP)を使用するということもあり得る。HTTPはトランザクションベースのプロトコルであるところ、SIPは、SIPエンドポイントを有する装置間の通信を可能とするセッションベースのプロトコルである。HTTPを使用するシステムは、例えばIPTV信号を伝送するHTTP信号伝達を用いて、サービスに関連したIMSを受信可能であるが、典型的には、上述のIMSネットワークアーキテクチャで使用されるSIPなど、新たなアーキテクチャで使用されるプロトコルは使用可能ではない。SIP信号伝達を用いる装置およびHTTP信号伝達を用いる装置は、あるプロトコルから、さらなる伝送のための他のプロトコルへ情報を転換するために、例えばIMSゲートウェイなどのインタフェースが必要であろう。この発想については、図1に示す構成要素例に関する上段に見られる。
【0013】
図1は、ITF2と、IMSゲートウェイ4と、IMSネットワーク10とを含んでいる。www.openiptvforum.orgで見られるようなオープンITF(OITF:Open ITF)必要条件にしたがうITFであればいかなるものであってもよいITF2と、IMSゲートウェイ4は、例えば家庭などの同一の一般的な場所に設置され、HTTP信号伝達を用いて互いに通信する。IMSゲートウェイ4は、SIP信号伝達を用いてIMSネットワーク10と通信する。この実施形態例では、認証およびセッション管理を行うコールセッション制御機能(CSCF:call session control function)6と、例えばメッセージング用ピアツーピア(P2P:peer-to-peer)通信イネーブラ14および一意のユニフォームリソースロケータ(URL:uniform resource locator)に関連したネットワークサーバ8の2つのアプリケーションサーバとを有するものとして、IMSネットワーク10を示している。IMSゲートウェイ4は、HTTP信号伝達およびSIP信号伝達の双方を用いる能力と、いずれかの側からの信号伝達要求を相関させる能力とを有する。より具体的には、IMSゲートウェイ4はSIPメッセージを受信し、例えばHTTP信号伝達などの非SIP信号伝達を用いて、本発明によって以下で説明するようなITF2で動作している正しいアプリケーションへ情報を送信する。HTTP信号伝達に関するさらなる情報については、1999年6月付のRequest for Comments(RFC:リクエストフォーコメント)22616で見られる。IMSネットワーク10は、単純化して、以下で説明する実施形態例における信号伝達処理を説明するために示したノードしか有していないように示してあるが、IMSネットワーク10では典型的により多くのノードが見られるものであり、一般的にIMSアーキテクチャおよびSIP信号伝達の詳細については、それぞれ、2007年3月付のThird Generation Partnership Project(3GPP:第3世代パートナーシッププロジェクト)Technical Specification(TS:技術仕様書)23.228 Version(バージョン)8および2002年6月付のRFC3261で見られる。
【0014】
実施形態例によれば、図2に示すように、ITF2は、例えばブラウザベースのアプリケーション1 202、ブラウザベースのアプリケーション2 204、ネイティブベースのアプリケーション1 210などの複数のアプリケーションと、例えばブラウザベースのアプリケーション3のインスタンス1 206、ブラウザベースのアプリケーション3のインスタンス2 208などの同一アプリケーションの複数のインスタンスとを実行しているものとすることができる。ブラウザベースのアプリケーションは分散型アプリケーション環境(DAE:distributed application environment)で動作することが可能であり、例えばプレゼンスおよびチャット/メッセージングのようなアプリケーションが挙げられる。ネイティブベースのアプリケーションは、登録およびプロファイル管理のようなITF埋込アプリケーションで動作することができる。しかしながら、ここでブラウザベースのもの、ネイティブベースのものに関するこれらのアプリケーション例は、純粋に例示的なものであり、当業者であれば、アプリケーションは、ブラウザベースとして開発されたものであるか、ネイティブベースとして開発されたものであるかによって限定されることはないということが理解されよう。また、図2に示すように、IMSゲートウェイ4は、恐らくはITF2で動作するアプリケーションのうちの1つに関する情報を含むSIPメッセージを受信する。IMSゲートウェイ4はこの情報を通知212としてITF2へ送信し、ITF2では、以下で説明するように所望のアプリケーションにこの通知が到達する。
【0015】
IMSゲートウェイ例4について、図3を参照しながら説明する。IMSゲートウェイ4は、IMSネットワーク10からの着信SIPメッセージ214を、ITF2で動作するアプリケーションと整合させる。IMSゲートウェイ4は、ITF2宛ての着信SIPメッセージ214がITF2における適切なアプリケーションへ送信されたものであることを保証する責任がある通知ルータ302を備える。この機能の支援のもと、この実施形態例によって、通知ルータ302は認証/セッション管理機能306とIMSゲートウェイ(IG)−ITFサーバ304とレジスタ308とを備える。認証/セッション管理機能306は、それ自体とその関連アプリケーションを有するITF2とに対するIMSネットワーク10による許可およびセッション管理のために使用される。IG−ITFサーバ304はITF2へメッセージを送信する。レジスタ308は、ITF2で支援されたアプリケーションに関する情報と、SIPセッション情報と、ユニフォームリソースロケータ(URL)情報とを有し、その他にも、例えばオペレータネットワークによって事前設定された識別情報なども有する。このような情報を用いて、ITF2で動作するアプリケーションを一意に識別し、着信SIPメッセージ214とその対応するITFアプリケーションとの正しい整合を行う。メッセージを送信するためにSIPメッセージ/ITFアプリケーションの関係を判定するときには、認証/セッション管理機能306もIG−ITFサーバ304もレジスタ308と通信する。また、これらの機能を用いて、必要に応じてレジスタ308に情報を加えることができる。この実施形態例に係るIMSゲートウェイ4は、ITF2で動作しているアプリケーションの知識と関連SIPダイアログ情報とを必要に応じて維持するステートフル(stateful)装置である。また、IMSゲートウェイ4は、ITF2に電源が入っている限り、このような状態をその記憶部(図3には示していないが、以下で説明する図10には示してある)に維持する。以下、アプリケーションについて、ITF2およびIMSゲートウェイ4の両視点から、より詳細に説明する。
【0016】
実施形態例によれば、複数のアプリケーションが同時にITF2で動作することが可能である。上述のように、これらのアプリケーションは、例えばDAEベースのアプリケーションおよびITF埋込アプリケーションのような、ITF2でサービスロジックを実行するアプリケーションの2つの一般的なカテゴリに分類することができる。IMSゲートウェイ4の視点からは(IMSゲートウェイ4はSIPを用いてIMSネットワーク10とのインタフェースを行う)、これらのアプリケーションは、例えばSIPダイアログおよび状態情報の有無(または必要性)に応じて、この実施形態に係る3つの異なる方法で、SIP通信とのインタフェースが行われる。
【0017】
このような実施形態に係るSIP通信とアプリケーションとのインタフェースを行う第1の方法は、例えばプレゼンスやセッションセットアップなどのSIPダイアログが必要なアプリケーションに関する。例えばIMSゲートウェイ4およびIMSノードなど、SIPエンドポイントを有する2つのエンティティが、SIPを用いた通信を行うと、SIPダイアログが発生する。他のアプリケーションではSIPダイアログを必要としない。かかる他のアプリケーションは、まずは、スタンドアローントランザクション型のアプリケーション(インスタントメッセージまたは登録)であり、SIPダイアログが必要ではない。IMSゲートウェイ4への着信SIPメッセージは、実施形態例に係るイベントを処理するための、例えば新たなメッセージ、既存のSIPダイアログに対するメッセージ、またはITF2のアプリケーションからの要求に対するメッセージ応答のような3つの種類のメッセージのうちの1つと見なすことが可能である。新たなメッセージは、例えば、既存のSIPダイアログがないSIP MESSAGEとすることができる。既存のメッセージは、例えば、既存のSIPダイアログに属するSIP NOTIFYとすることができる。メッセージ応答は、例えば、ITF2由来でIMSゲートウェイ4が正しく修正/送信したサービス要求メッセージなどのIMSゲートウェイ4による要求に応じたSIP 200 OKとすることができる。異なる処理が行われるこれら3つの通知イベントについて、以下でさらに詳細に説明する。
【0018】
実施形態例によれば、図4に示すように、IMSゲートウェイ4はITF2と通信し、通知イベントの種類に基づく異なる種類の通知を適切なアプリケーションへ配信する。まず、IMSゲートウェイ4は着信SIPメッセージ214を受信する。どの種類のイベントが受信されたのかを通知ルータ302が判定する。そして、通信ルータ302は、セッション中通知414または第三者通知416のいずれかを作成し、ITF2へ送信する。セッション中通知は、典型的には、ITF2のアクティブアプリケーションとIMSゲートウェイ4との間に進行中の通信がある場合に使用する。第三者通知は、典型的には、ITF2の非アクティブアプリケーションとの通信を開始する新たなメッセージに対して使用する。通知がセッション中通知414であった場合、この通知は、例えばDAE App1 408やDAE App2 412など、ITF2のブラウザ部404で目下動作中の適切なDAEアプリケーションへ送信される。通知が第三者通知416であった場合、この通知は、ITF2においてルータ機能と同様に機能する第三者通知処理部420へ送信される。
【0019】
そして、第三者通知処理部420は、受信した通知がDAEブラウザベースのアプリケーション402へ向かう必要があるのか、ITF埋込アプリケーション406へ向かう必要があるのか判定する。通知がDAEブラウザベースのアプリケーション402へ向かうものであった場合、ブラウザ404がDAEブラウザベースのアプリケーション402に対してアクセス可能なユニフォームリソースロケータ(URL)が送信される。受信した通知がITF埋込アプリケーション406へ向かうものであった場合、この通知は、アプリケーションプログラミングインタフェース(API:application programming interface)を通じて、使用を所望するITF埋込アプリケーション406へ送信される。また、図4には示していないが、初期サービス要求などのメッセージをITF2からIMSゲートウェイ4へ送信して、IMSネットワーク10へ送信することも可能である。
【0020】
上述のように、ITF2は、HTTP信号伝達を用いて、アクティブアプリケーションからの要求をIMSゲートウェイ4へ送信することができる。実施形態例によれば、特にIMSゲートウェイ4で受信するSIPメッセージの調整について、アプリケーションの正しい追跡を容易にするため、アプリケーションごとに一意のアプリケーションID(identification)を、ITF2からIMSゲートウェイ4へのHTTP要求メッセージへ挿入する。この要求は、ITF2で動作するDAEアプリケーション408、412、およびITF埋込アプリケーション406の両方に対して発生させることが可能である。DAEアプリケーション408、412、およびITF埋込アプリケーション406については、欧州電子計算機工業会(ECMA:European Computer Manufacturers Association)スクリプトを用いて、HTTP要求メッセージのヘッダまたはヘッダ拡張子へ一意のアプリケーションIDを挿入することができる。かかるアプリケーションIDについては、規格化されていることも、規格化されていないこともあるが、メッセージの適切なルーティングを容易にするためには一意であるべきである。一意性を保証する方法の1つとしては、一意性を表すプロパティを有するサービスユニフォームリソースネーム(URN:uniform resource name)でアプリケーションIDを表すことが挙げられる。URNについてのさらなる情報に関心がある読者は、1997年5月付のRFC2141を参照のこと。また、上述のように、この一意のアプリケーションIDをもつHTTP要求メッセージに新たなフィールドを追加することも可能である。
【0021】
実施形態例によれば、ITF2からのHTTP要求がIMSゲートウェイ4で受信されると、一意のアプリケーションIDは、対応するSIPダイアログとともに、また適用可能であれば記憶された状態とともに、IMSゲートウェイ4に維持される。また、HTTP要求が受信され、SIPダイアログが作成されると、IMSゲートウェイ4は、SIPダイアログについて、進行中のイベントの報告に使用する通知の種類に関する動的な情報を維持する。
【0022】
上述のように、IMSゲートウェイ4は、ITF2で動作するアプリケーションに関する情報とSIPダイアログ情報とを記憶する。実施形態例によれば、識別情報がレジスタ308に記憶されており、着信SIPメッセージ214からの情報を、ITF2で動作する正しいアプリケーションへ送信することが可能である。レジスタ308に識別情報を記憶するテーブル例500および520を、それぞれ図5(a)および5(b)に示す。レジスタ308のアプリケーション識別テーブル例500は、例えば、IMSゲートウェイ4が第三者通知の処理に用いることができる。より具体的に、この例では、アプリケーションテーブル500は、典型的にはサービスプロバイダ(SP:service provider)によって遠隔的に事前設定されたものであり、サービスプロバイダが提供するDAEアプリケーションに対するアプリケーションIDと、対応するDAEアプリケーションに使用されるURLとを有する。ITF埋込アプリケーションは、URLの使用を必要とせず、ホームネットワークインタフェース−IMSゲートウェイインタフェース(HNI-IGI:home network interface-IMS gateway interface)(図示せず)においてスタートアップの間にIMSゲートウェイ4に登録する。ITF2配置は、表示する能力と、ユーザとやり取りを行う能力とを有する。
【0023】
この実施形態によれば、着信SIPメッセージ214をアプリケーションに整合させるアシストに、およびIMS要求に対する順守についての発信SIPメッセージのチェックに、IMSゲートウェイ4が使用するものとして、IMS通信サービス識別子(ICSI:IMS communication service identifier)をアプリケーションごとに定めることができる。場合によっては、同一のアプリケーションの複数のインスタンスを同時にITF2で動作させることも可能である。この支援のもと、トラフィックテーブル例520は、IMSゲートウェイ4がアプリケーションのインスタントの異なるものどうしを区別できる情報を記憶する。テーブル500および520に記憶されたこれらの種々の識別情報を何度も用いて、IMSゲートウェイ4は、どの通知またはメッセージがITF2におけるどのアプリケーション(またはアプリケーションインスタンス)へルーティングすべきかを識別することができる。アプリケーション識別テーブル例500およびトラフィックテーブル例520について、以下でさらに詳細に説明する。また、アプリケーション識別テーブル500およびトラフィックテーブル520は、2つの別々のテーブルとして示してあるが、単一のテーブルに記憶することも可能であり、あるいは、情報を結びつけたままで2よりも多くのテーブルにさらに分散させることも可能である。
【0024】
図5(a)に示すように、アプリケーション識別テーブル500は、行502を読み取ると示されるように、必要に応じて、アプリケーションID504と、DAEアプリケーションに対して第三者通知で使用されるURL508と、ICSI506との間に結びつきを維持する。また、デフォルトURLを使用するデフォルトDAEアプリケーションも示してあるが、これについては、着信SIPメッセージがICSIまたはアプリケーションIDを有していない場合(アプリケーション識別テーブル500では「設定なし」という項目で示している)に使用可能である。アプリケーション識別テーブル500は、着信SIPメッセージがICSIと、アプリケーションIDとを含む場合、ICSIおよびアプリケーションIDの両方を含む場合、ICSIもアプリケーションIDも含まない場合にイベントの処理に使用する情報を通知ルータ308に提供する。この情報を他の情報とともに使用して、IMSゲートウェイ4はイベントを処理する。
【0025】
実施形態例によれば、図5(b)に示すように、トラフィックテーブル520はSIPダイアログ、または着信SIPメッセージ214の特定SIPヘッダにおけるアプリケーション識別情報と、アプリケーションインスタンスとの間の結びつきを維持する。各結びつきは、テーブル520において各項目522、524、526で示すように表されており、項目1 522はアプリケーションの第1インスタンスに結びつけられたSIPダイアログ(またはアプリケーション識別情報)を表し、項目2 524は同一アプリケーションの第2インスタンス、または異なるアプリケーションの第1インスタンスを表し、項目3 526は同一アプリケーションの第3インスタンス、またはITF2で目下動作中の異なるアプリケーションの第1インスタンスを表すものとすることができる。着信SIPメッセージ214を処理するために項目522、524、526が選択されると、項目522、524、526は、関連アプリケーションインスタンスへ向かう着信トラフィックに使用するTCPをIMSゲートウェイ4が一意に識別できるほど十分な状態情報を有するであろう。また、このようにTCPを使用することで、IMSゲートウェイ4は、例えばTCPが適切に終了することなどから、アプリケーションインスタンスがいつ終了したかを認識することが可能であり、例えば複数のTCPリンクが同時に手荒にシャットダウンされるなど、同一アプリケーションの異なるインスタンスの複数のTCPリンクが不適切に終了した場合のエラーリカバリも可能である。また、実施形態例によれば、トラフィックテーブル520に必要であれば、項目522、524、526に追加状態情報を記憶することも可能である。
【0026】
実施形態例によれば、様々なトラフィックシナリオによって、項目522、524、526を作成してトラフィックテーブル520に記憶することが必要となり得る。第1のシナリオでは、例えばメッセージおよび/または信号伝達などのトラフィックがITF2のアプリケーションから発信され、IMSゲートウェイ4へ送信される。IMSゲートウェイ4はSIPダイアログの維持を要求する。IMSゲートウェイ4は、IMSゲートウェイ4はIMSネットワーク10にセッション確立の要求を送信し、SIPダイアログが作成され、維持される。そして、項目522、524、526が作成され、トラフィックテーブル520に記憶される。トラフィックテーブル520は、アプリケーションインスタンスをSIPダイアログと結びつけて、例えばTCP情報などの他の必要な状態情報を記憶する。
【0027】
実施形態によれば、第2のシナリオでは、ITF2のアプリケーションからトラフィックが発信され、IMSゲートウェイ4へ送信されるが、SIPダイアログを作成して維持する必要はない。このシナリオでは、項目522、524、526をトラフィックテーブル520に作成する必要がない。その代わり、ITF2の発信アプリケーションに応じて、例えば発信アプリケーションが登録アプリケーション(など)である場合には、SIP状態を作成してIMSゲートウェイ4に記憶し、あるいは、例えば発信アプリケーションがインスタントメッセージングアプリケーション、スタンドアローントランザクションアプリケーション(など)である場合には、IMSネットワーク10とのやり取りが完了できたら、状態を維持しない。
【0028】
別の実施形態例によれば、第3のシナリオでは、SIPメッセージ214がIMSゲートウェイ4によってIMSネットワーク10から受信されるが、トラフィックテーブルに項目はない。この場合、IMSゲートウェイ4はアプリケーション識別テーブル500を用いて適切なアプリケーションを識別し、以下でさらに詳細に説明するように、ITF2の適切なアプリケーションへ要求を送信する。識別されたアプリケーションに応じて、トラフィックテーブル520に項目522、524、526を作成することができる。例えば、識別されたアプリケーションがSIPダイアログの維持を必要とする場合、IMSゲートウェイによってITF2からの成功応答を受信すると、続いて項目522、524、526を作成する。別の例では、識別されたアプリケーションがSIPダイアログの維持を必要としない場合、トラフィックテーブル520への項目522、524、526の作成および記憶は行わない。その代わり、トランザクションは完了され、全トランザクションが完了できるまで、IMSゲートウェイ4はステートフルのままである。さらに別の例では、識別されたアプリケーションがSIPダイアログを必要としてはいないが、着信メッセージに対してアクティブのままでいようとする場合、そのTCP接続を維持することによってこのことを示すことが可能であり、トラフィックテーブル520に項目522、524、526が作成され、維持される。
【0029】
したがって、実施形態によれば、IMSゲートウェイ4は、IMSネットワーク10からの様々な着信SIPメッセージを処理する。この様々な着信SIPメッセージは、IMSゲートウェイ4に利用可能な情報に応じて様々にITF2へ送信される通知を必要とする。第1の実施形態例では、IMSゲートウェイ4は、トラフィックテーブル520を調べることによって、着信SIPメッセージに関するSIPダイアログが以前に存在しているものであるか判定する。着信SIPメッセージに関するSIPダイアログが以前に存在しているものであれば、IMSゲートウェイ4によって、TCPリンクを通じて適切なアプリケーションインスタンスにセッション中通知が送信される。送信される通知には、受信SIPメッセージのペイロード部分(またはカプセル化バージョン)が含まれており、ペイロード部分は関連SIPヘッダを有している。
【0030】
SIP通信とのアプリケーションのインタフェースを行う第2の方法は、例えば登録など、SIPダイアログは必要ないが状態はIMSゲートウェイ4に維持されるアプリケーションに関する。別の実施形態例では、IMSゲートウェイ4は、既存のSIPダイアログがないSIPメッセージをIMSネットワーク10から受信する。しかしながら、この場合、意図するアプリケーションインスタンスをIMSゲートウェイが識別し、セッション中通知を使用して、適切なTCPリンクを通じてITF2の正しいアプリケーションインスタンスへ送信することができる状態情報が、そのためにトラフィックテーブル520に記憶されている。送信される通知には、受信SIPメッセージのペイロード部分(またはカプセル化バージョン)が含まれており、ペイロード部分は関連SIPヘッダを有している。
【0031】
SIP通知とのアプリケーションのインタフェースを行うこの第3の方法は、IMSゲートウェイ4の視点からは、例えばメッセージングおよび発呼者識別など、SIPダイアログも状態も必要としないアプリケーションに関する。別の実施形態例では、IMSゲートウェイ4は、対応するSIPダイアログも、トラフィックテーブル520に存在する目下維持されている状態情報もないSIPメッセージをIMSネットワーク10から受信する。この場合、アプリケーションIDの識別は、テーブル500を調べることが必要となり、また着信メッセージのコンテンツ、特にアクセプト−コンタクト(Accept-Contact:受入−連絡)SIPヘッダのコンテンツに依存する。実施形態例によれば、SIPヘッダのAアクセプト−コンタクトフィールドは、IMSゲートウェイ4がSIPメッセージをITF2で動作するアプリケーションと整合させることができる情報を含んだものとすることができる。SIPメッセージのアクセプト−コンタクトフィールドについてのさらなる情報に関心のある読者は、2004年付のRFC3841を参照のこと。この情報を用いて、IMSゲートウェイ4は、SIPメッセージをITF2のアプリケーションにリンクさせて、そのために第三者通知を使用して通知を送信する。送信される通知には、テーブル500における整合した項目から選択される情報に加えて、受信SIPメッセージのペイロード部分(カプセル化バージョン)が含まれており、ペイロード部分は関連SIPヘッダを有している。
【0032】
さらに別の実施形態例によれば、IMSゲートウェイ4は、ICSIのみを明示的に含むSIPメッセージをIMSネットワーク10から受信し、IMSゲートウェイ4はデフォルトアプリケーションIDを推測して使用する。アプリケーション識別テーブル500は、典型的には、必要であればICSIに使用するデフォルトアプリケーションIDを有する。例えば、図5(a)の行514および516に示すように、ICSI1およびICSI2はデフォルトアプリケーションIDに結び付けられている。このデフォルトアプリケーションIDを使用して、IMSゲートウェイ4は、受信した通知をITF2のデフォルトアプリケーションIDへ送信する。また、着信SIPメッセージがICSIもアプリケーションIDも含んでいない場合には、デフォルトURLを使用する。
【0033】
別の実施形態例によれば、IMSゲートウェイ4は、ICSIもアプリケーションIDも明示的に含むSIPメッセージをIMSネットワーク10から受信し、ルータ機能302は、アプリケーション識別テーブル500を調べることによって、受信した通知を、ITF2で動作するアプリケーションにリンクさせることができる。この場合、IMSゲートウェイ4は、例えば第三者通知など、識別したアプリケーションへの送信用の通知情報を含むメッセージをITF2へ送信する。送信される通知には、テーブル500における整合した項目から選択される情報に加えて、受信SIPメッセージのペイロード部分(カプセル化バージョン)が含まれており、ペイロード部分は関連SIPヘッダを有している。
【0034】
IMSゲートウェイ4がSIPメッセージを受信し、セッション中通知なのか第三者通知なのか判定した後、IMSゲートウェイ4は通知を適切に送信する。例えば、SIPメッセージがセッション中通知である場合は、典型的には状態情報によって判定されるのだが、IMSゲートウェイ4は、HTTP信号伝達または他の信号伝達方式を使用して、ITF2で動作する適切なアプリケーションへ通知情報を送信する。通知が第三者通知であると判定されると、通知情報はITF2の第三者通知処理部420へ送信され、第三者通知処理部420は、例えばITF埋込アプリケーション406やDAEブラウザアプリケーション402などの正しいアプリケーションへ通知情報を送信する。第三者通知処理部420は、この判定を、第三者通知メッセージ416で受信した情報に基づいて行う。まず、第三者通知処理部420は、第三者通知メッセージ416においてアプリケーションIDを探す。アプリケーションIDがあっても、第三者通知処理部420が認識しなければ、含まれているURLを使用して、ネットワークアプリケーションDAEに要求を処理させる。第三者通知処理部420がアプリケーションIDを認識する場合は、第三者通知処理部420は、必要なアプリケーションがITF埋込アプリケーション406であると考え、それに応じて、適切なAPIを使用して通知を送信する。
【0035】
他の実施形態例によれば、ITF2から要求を発生させて、IMSゲートウェイ4からIMSネットワーク10へ発信トラフィックを送信することも可能である。続いて受信した着信SIPメッセージを必要なアプリケーションに整合させることなど、様々な方法を用いて、発信アプリケーションを一意に識別することができる。例えば、DAEアプリケーション408、412、またはITF埋込アプリケーション406がメッセージを発信すると、新たなHTTPヘッダにアプリケーションIDを埋め込むことが可能であり、アプリケーションIDは、IMSゲートウェイ4によって抽出される。あるいは、DAEアプリケーション408、412、およびITF埋込アプリケーション406は、新たなHTTPヘッダにICSIを含めることが可能であり、ICSIは、SIPヘッダにおける追加情報とともに、IMSゲートウェイ4がアプリケーション識別テーブル500に関連して使用して、アプリケーションIDの位置を突き止めることができる。
【0036】
ここで図6〜9を参照しながら、上述のシステム例および方法例に基づいた信号伝達図例について説明する。図6(a)は、ITF2において目下アクティブなメッセージングアプリケーションがなく、SIPメッセージ受信して、メッセージングアプリケーションを開始する信号伝達図例を示している。まず、「appid=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE602がP2P通信イネーブラ12からCSCF6へ送信され、CSCF6は、SIP MESSAGE602をIMSゲートウェイ4内の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、トラフィックテーブル520を調べ、着信SIPメッセージに整合する項目がないことを確認する。そして、IMSゲートウェイは、アプリケーション識別テーブル500を調べ、例えば「appid=MESSAGING」などの受信したアクセプト−コンタクトヘッダ情報に、および必要に応じてテーブル500の情報に基づいて、アプリケーションIDの位置を突き止める。そして、認証/セッション管理機能306が、メッセージ604を送信して、IG−ITFサーバ304へ第三者通知を呼び出す。そして、IG−ITFサーバ304は、メッセージ606を送信して、アプリケーションID(「appid」)とURL(アプリケーション識別テーブル500から取得)とを含む第三者通知をITF2へ呼び出す。
【0037】
この例では、ITF2の第三者通知処理部420は、受信したappidを認識せず、その代わりにITF2が、メッセージ614に示すように、受信したURLを使用してアプリケーションを取得する。ネットワークサーバ8がHTTP Get URLメッセージ614を受信したら、メッセージ616に示すように、ECMAスクリプトを用いたジェネリックDAEアプリケーションハンドラを含む200 OKメッセージがITF2へ返信される。ほぼ同時に、IG−ITFサーバ304は認証/セッション管理機能306にオペレーション結果608を返信する。オペレーション結果608に基づいて、認証/セッション管理機能306は、202 ACCEPTEDメッセージをCSCF6へ送信し、CSCF6は202 ACCEPTEDメッセージをP2P通信イネーブラ12へ送信する。メッセージングアプリケーションがアクティブのままでいることを望めば、TCP接続を維持する。そして、IMSゲートウェイ4はトラフィックテーブル520に項目を作成して、追加SIPとアプリケーション関連状態情報とを維持する。これにより、着信SIPメッセージがメッセージアプリケーション宛てである場合、この場合に第三者通知を使用するのとは対照的に、セッション中通知を使用して、メッセージングアプリケーションを後に呼び出すことができる。
【0038】
実施形態例によれば、図6(b)は、ITF2においてメッセージングDAEが目下アクティブに動作しており、IG−ITFサーバ304との永久的TCP接続を有している場合に、メッセージングアプリケーションに関するSIPメッセージを受信する信号伝達図例を示している。まず、情報「appid=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE618がP2P通信イネーブラ12からCSCF6へ送信され、CSCF6は、SIP MESSAGE618をIMSゲートウェイ4内の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、トラフィックテーブル520を調べ、SIP MESSAGE618のアクセプト−コンタクトヘッダに基づいて着信SIPメッセージを処理可能な項目の位置を突き止める。また、そのステートフル能力に基づいて、IMSゲートウェイ4は、DAEメッセージアプリケーションがITF2で目下動作中であり、そのためセッション中通知を使用すべきであることがわかる。そして、認証/セッション管理機能306が、メッセージ620を送信して、IG−ITFサーバ304へ第三者通知を呼び出す。そして、IG−ITFサーバ304は、拡張可能マークアップ言語(XML:extensible markup language)を使用可能なITF2へのセッション中通知を呼び出すためのメッセージ622を送信する。そして、IG−ITFサーバ304から認証/セッション管理機能306にオペレーション結果メッセージ624が送信される。そして、認証/セッション管理機能306は202 Acceptedメッセージ626をCSCF6へ送信し、CSCF6は202 Acceptedメッセージ628をP2P通信イネーブラ12へ送信する。
【0039】
実施形態によれば、図7は、ITF2がプレゼンスアプリケーションで動作している場合の信号伝達例を示している。まず、事前に取得されているもので、プレゼンス通知のためにIG−ITFサーバ304とのTCP接続を確立するプレゼンスアプリケーションを、ユーザが開始する。これにより、トラフィックテーブル520に項目が作成され、IMSゲートウェイ4はこの項目を使用して、同一ダイアログに関連する着信SIPプレゼンス通知メッセージを整合させることができる。さらにこれにより、IMSゲートウェイ4はセッション中通知を使用して、着信プレゼンス通知メッセージをITF2のプレゼンスアプリケーションに送信することが可能となる。プレゼンス情報を含むSIP NOTIFYメッセージ702をP2P通信イネーブラ12からCSCF6を介して受信すると、IMSゲートウェイ4は、トラフィックテーブル520の適切なSIPダイアログとメッセージ702を整合させ、適切なアプリケーションインスタンスを選択する。また、IMSゲートウェイ4は、この場合にはセッション中通知を使用すべきであることがわかる。そして、認証/セッション管理機能306は、メッセージ704を送信して、IG−ITFサーバ304へセッション中通知を呼び出す。そして、IG−ITFサーバ304は、XMLとすることが可能な着信NOTIFYを含むセッション中通知を呼び出すためのITF2へのメッセージ706を送信する。そして、IG−ITFサーバ304から認証/セッション管理機能306にオペレーション結果メッセージ708が送信される。そして、認証/セッション管理機能306は200 OKメッセージ710をCSCF6へ送信し、CSCF6は200 OKメッセージ710をP2P通信イネーブラ12へ送信する。
【0040】
実施形態例によれば、図8(a)は、ITF埋込アプリケーションを使用したメッセージングの場合の信号伝達例を示している。まず、P2P通信イネーブラ12が、「ICSI=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE802をCSCF6へ送信し、CSCF6は、SIP MESSAGE802をIMSゲートウェイ4の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、アクセプト−コンタクトにおける情報を取り、トラフィックテーブル520を調べ、着信SIPメッセージに整合する項目がないことを確認する。そして、IMSゲートウェイは、アプリケーション識別テーブル500を調べ、例えばテーブル500の同一行511に見られるようなアプリケーションIDに結び付けられているテーブル500に記憶されたICSIに、受信したICSIを整合させる。認証/セッション管理機能306は、ITF2へのアプリケーションIDを含む第三者通知をITF2が呼び出すための情報を有するメッセージ804をIG−ITFサーバ304へ送信する。ITF2の第三者通知処理部420は、メッセージ806を受信してアプリケーションIDを認識し、ITF2は埋込メッセージングアプリケーションを起動する。例えば、メッセージング用のDAEブラウザベースのアプリケーション402の代わりに、メッセージング用のITF埋込アプリケーション406が起動される。そして、IG−ITFサーバ304から認証/セッション管理機能306へオペレーション結果が送信される。そして、認証/セッション管理機能306は202 Acceptedメッセージ810をCSCF6へ送信し、CSCF6は202 Acceptedメッセージ812をP2P通信イネーブラ12へ送信する。ITF埋込アプリケーション406はアクティブのままでTCP接続を維持することを選択可能であり、その場合は、セッション中通知を使用して、このアプリケーション宛の後続の着信メッセージを配信できる項目を、IMSゲートウェイ4がトラフィックテーブル520に作成する。
【0041】
実施形態例によれば、図8(b)は、IG−ITFサーバ304とのTCP接続を有するITF2おいてアクティブな埋込メッセージアプリケーションが目下動作している場合に、メッセージングアプリケーションに関するSIPメッセージを受信する信号伝達例を示している。まず、情報「ICSI=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE814がP2P通信イネーブラ12からCSCF6へ送信され、CSCF6は、SIP MESSAGE814をIMSゲートウェイ4内の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、トラフィックテーブル520を調べ、SIP MESSAGE814のアクセプト−コンタクトヘッダの情報に基づいて着信メッセージを処理可能な項目の位置を突き止める。そのステートフル能力に基づいて、IMSゲートウェイ4は、セッション中通知を使用すべきであることがわかる。そして、認証/セッション管理機能306が、メッセージ816を送信して、IG−ITFサーバ304へ第三者通知を呼び出す。そして、IG−ITFサーバ304は、メッセージ622をITF2へ送信し、XMLとすることができる情報を含むセッション中通知を呼び出す。そして、IG−ITFサーバ304から認証/セッション管理機能306にオペレーション結果メッセージ820が送信される。そして、認証/セッション管理機能306は202 Acceptedメッセージ822をCSCF6へ送信し、CSCF6は202 Acceptedメッセージ824をP2P通信イネーブラ12へ送信する。
【0042】
実施形態によれば、図9は、IMSゲートウェイ4においてアプリケーションIDまたはICSIを含まないSIPメッセージを受信する信号伝達例を示している。まず、P2P通信イネーブラ12がSIP PUBLISHメッセージ902をCSCF6へ送信し、CSCF6はSIP PUBLISHメッセージ902をIMSゲートウェイ4の認証/セッション管理機能306へ送信する。IMSゲートウェイ4は、受信したSIP PUBLISHメッセージ902のアクセプト−コンタクトヘッダにアプリケーションIDもICSIも欠如していることに気づき、そのためトラフィックテーブル520を調べずに、むしろアプリケーション識別テーブル500を調べて、デフォルトURLを有するアプリケーションをテーブル500から取る。認証/セッション管理機能306はメッセージ904を送信し、IG−ITFサーバ304への第三者通知を呼び出す。そして、IG−ITFサーバ304はメッセージ906を送信し、テーブル500から得られるデフォルトURLを含む第三者通知を呼び出す。ITF2はメッセージ906を受信し、第三者通知処理部420はアプリケーションIDを確認せず、その代わり、供給されたURLを使用して、DAEアプリケーションを取得して、ネットワークサーバ8へ送信されるHTTP Get URLメッセージ908に示すように、この要求を処理する。ネットワークサーバ8は、ITF2に対して、DAEデフォルトアプリケーションハンドラ(典型的にはいくつかの拡張可能ハイパーテキストマークアップ言語(XHTML:extensible hyper text markup language)命令とEcmaスクリプト命令とを含む)を含む200 OKメッセージ910で応答する。そして、IG−ITFサーバ304から認証/セッション管理機能306にオペレーション結果メッセージ912が送信される。そして、認証/セッション管理機能306は200 OKメッセージ914をCSCF6へ送信し、CSCF6は200 OKメッセージ916をP2P通信イネーブラ12へ送信する。
【0043】
上述のシステムおよび方法を使用する実施形態例によれば、IMSゲートウェイ4は、ITF2との複数のTCPリンクの損失のような様々なエラーに対してエラーリカバリを行う能力を有するものとすることができる。この場合、複数のアプリケーションインスタンスがITF2において目下アクティブであり、各アプリケーションインスタンスは、IMSゲートウェイ4との通信に対して、異なるTCPリンクをアップさせるであろう。TCPリンクは、アプリケーションインスタンスがアップし、動作している限り、アップしているであろう。TCPリンクがダウンすると、IMSゲートウェイ4はTCPリンクの損失を検出し、設定可能タイマに基づいて、IMSゲートウェイ4がトラフィックテーブル520において適当な項目522、524、526を更新できる新たなリンクをアプリケーションインスタンスが再確立するまで、例えば約40〜60秒間、待機する。
【0044】
実施形態によれば、TCPリンクの再確立に関するタイマが満了すると、IMSゲートウェイ4は、アプリケーションインスタンスが終了したと想定し、対応するネットワーク側通信の終了およびトラフィックテーブル520からの項目522、524、または526の削除に進行する。アプリケーションインスタンスが終了していなければ、IMSゲートウェイ4は、典型的に、TCPリンク再確立の一部としてSIP UPDATEと等しいものをIMSゲートウェイ4のピアへ送信する。これにより、SIP状態情報は変更されず、IMSゲートウェイ4が、リンク不具合が複数ある場合のエラーリカバリを処理できる。同一アプリケーションの複数のインスタンスに複数のリンク不具合があるこの場合では、IMSゲートウェイ4は、トラフィックテーブル520に記憶された状態情報と関連してSIP UPDATEメッセージの情報を使用して、意図されたアプリケーションインスタンスを一意に識別して、エラーリカバリを成功させることができる。
【0045】
上述の実施形態例は、人対人の通信に関するメッセージおよびプロトコルを与える。IMSゲートウェイ4の機能を行うことが可能な通信ノード例1000について、図10を参照しながら説明する。通信ノード1000は、処理部1002(または複数の処理コア)と、記憶部1004と、1または2以上の2次格納装置1006と、インタフェース1008とを有するものとして、通信ノード1000と他のネットワークおよび装置との間の通信を容易にすることができる。記憶部1004および/または2次格納装置1006を使用して、状態情報とテーブル500および520とを記憶することができる。ロジックおよびプロトコルも、通信ノード1000内に記憶し、処理部1002が通知の種類を決定するために、またIMSゲートウェイ4がその他すべての上述した機能例を行うために使用することが可能である。
【0046】
実施形態例に係る上述のシステム例を使用して、異なるプロトコルを使用する装置間の通信を容易にする方法を、図11のフローチャートに示す。まず、インターネットマルチメディアサブシステム(IMS)ネットワークと非IMSノードとの間でアプリケーション情報を相関させる方法が、ゲートウェイにおいて、ステップ1102において第1の信号伝達プロトコルを使用して、IMSネットワークから第1のメッセージを受信すること;ステップ1104において第1のメッセージから情報を読み出すこと;ステップ1106において、この情報を、以前に記憶された情報と相関させて、非IMSノードで動作する複数のアプリケーションのうちのいずれが第1のメッセージに関連しているかを判定すること;ステップ118において、第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用して、非IMSノードで動作する複数のアプリケーションのうちの、第1のメッセージに関連しているものに関する情報を含む第2のメッセージを、非IMSノードへ送信すること;を含む。
【0047】
当業者によって了解されるように、図11に示すような方法は、ソフトウェアで全体的または部分的に実施することが可能である。したがって、本発明の実施形態例にしたがってデータを処理するシステムおよび方法は、記憶装置に含まれた命令のシーケンスを実行する1または2以上の処理部によって実行することが可能である。このような命令は、固定媒体、リムーバブル媒体、またはリモート媒体(ネットワーク格納部)とすることができる2次データ格納装置1006などの他のコンピュータ読出可能媒体から記憶装置1004へ読み出すものとすることも可能である。記憶装置に含まれた命令のシーケンスの実行は、例えば上述のように処理部に動作させる。代替の実施形態では、有線回路を、ソフトウェア命令の代わりに、またはソフトウェアと組み合わせて、実施形態例を実施することが可能である。
【0048】
上述の実施形態例は、本発明の全ての点において例示的なものとしたつもりであり、限定的なものとするつもりはない。かかる変更点や修正点はすべて、特許請求の範囲に記載の本発明の範囲および意図の内であると考えられるものである。例えば、1つの家庭で複数のITF2がIMSゲートウェイ4と通信しているものとすることも可能であり、この場合でも、IMSゲートウェイ4は、例えばテーブル500および520に追加情報を記憶しておいてITFで動作しているアプリケーションを参照することなどによって、通信中のITF2におけるアプリケーションを一意に識別可能である。加えて、上述のサービス例は純粋に例示的なものであり、他のIMSサービスは上述のシステムおよび方法によって支援可能である。本願明細書において使用した構成、動作、または命令は、明示的な記載がない限り、本発明に対して決定的または本質的なものとして解釈すべきものではない。また、ここで使用した冠詞「a」は1または2以上の項目を含むものと意図している。
【特許請求の範囲】
【請求項1】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ネットワークと非IMSノードとの間でアプリケーション情報を相関させる方法であって、
ゲートウェイにおいて、第1の信号伝達プロトコルを使用する前記IMSネットワークから第1のメッセージを受信するステップと、
前記第1のメッセージから情報を読み出すステップと、
以前に記憶された情報と前記情報を相関させて、前記非IMSノードで動作する複数のアプリケーションのうちのいずれが前記第1のメッセージに関連しているかを判定するステップと、
前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに関連する情報を含む、前記第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用する第2のメッセージを、前記非IMSノードへ送信するステップと
を含む方法。
【請求項2】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに、SIPダイアログを使用する、請求項1に記載の方法。
【請求項3】
前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対する後続メッセージを受信するステップと、
前記非IMSノードにセッション中通知メッセージを送信するステップと
をさらに含む、請求項2に記載の方法。
【請求項4】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対して、記憶部に維持された状態を有する、請求項1に記載の方法。
【請求項5】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対してステートレスである、請求項1に記載の方法。
【請求項6】
前記第1のメッセージは、前記情報をコンタクト−アクセプトヘッダに含むセッション開始プロトコル(SIP)メッセージである、請求項1に記載の方法。
【請求項7】
前記情報は、ユニフォームリソースロケータ(URL)とIMS通信サービス識別子(ICSI)とのうちの少なくとも1つである、請求項6に記載の方法。
【請求項8】
前記第2の信号伝達プロトコルはハイパーテキスト転送プロトコル(HTTP)である、請求項1に記載の方法。
【請求項9】
前記第2の信号伝達プロトコルを使用して、アプリケーションIDを含む第2のメッセージを前記非IMSノードから受信するステップであって、前記第2のメッセージはHTTP要求メッセージであるステップをさらに含む、請求項1に記載の方法。
【請求項10】
前記以前に記憶された情報は、記憶されたURLと、ICSIと、アプリケーションIDとを含む、請求項1に記載の方法。
【請求項11】
前記複数のアプリケーションのうちの1つの各インスタンスは一意に識別される、請求項1に記載の方法。
【請求項12】
前記一意の識別は、トランスミッションコントロールプロトコル(TCP)のハッシングとのアプリケーションIDの連結から作成される、請求項11に記載の方法。
【請求項13】
SIPダイアログが維持されることを要求する第1のアプリケーションから発信されたメッセージを受信することと、SIPダイアログが維持されることを要求する第2のアプリケーションに関連するSIPメッセージを受信することとのうちの少なくとも1つによって、前記テーブルに項目が作成される、請求項11に記載の方法。
【請求項14】
前記第1のメッセージを受信した後にSIPダイアログを確立するステップと、
前記SIPダイアログと前記アプリケーションとをリンクさせる追加情報を記憶するステップと、
前記アプリケーションに関連する、前記IMSネットワークからの後続受信メッセージに対して、記憶された前記追加情報に基づいてセッション中通知を使用するステップと
をさらに含む、請求項1に記載の方法。
【請求項15】
前記アプリケーションの開始後に前記非IMSノードとのトランスミッションコントロールプロトコル(TCP)接続を確立するステップと、
前記アプリケーションが終了された後に前記非IMSノードとの前記TCP接続を終了するステップと
をさらに含む、請求項1に記載の方法。
【請求項16】
前記非IMSノードはインターネットプロトコルテレビジョン端末機能(ITF)である、請求項1に記載の方法。
【請求項17】
前記アプリケーションは、分散型アプリケーション環境(DAE)アプリケーションと埋込ITFアプリケーションとのうちの少なくとも1つである、請求項1に記載の方法。
【請求項18】
メッセージを送受信する通信インタフェースであって、第1の信号伝達プロトコルを使用する第1の受信メッセージが、アプリケーションに関連する情報を含む、通信インタフェースと、
アプリケーションIDと、ユニフォームリソースロケータ(URL)と、デフォルト情報と、IMS通信サービス識別子(ICSI)とを含む情報を記憶する記憶部と、
前記第1の信号伝達プロトコルを使用する前記第1の受信メッセージと、記憶された前記情報とを相関させ、前記第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用する第2のメッセージのルーティング先のアプリケーションを識別する処理部であって、前記第2の信号伝達プロトコルを使用する前記第2のメッセージは、前記アプリケーションに関連する情報を含む、処理部と
を備えるゲートウェイ装置。
【請求項19】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに、SIPダイアログを使用する、請求項18に記載のゲートウェイ装置。
【請求項20】
前記通信インタフェースにおいて、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対する後続メッセージを受信し、前記非IMSノードにセッション中通知メッセージを送信することをさらに含む、請求項19に記載のゲートウェイ装置。
【請求項21】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対して、記憶部に維持された状態を有する、請求項18に記載のゲートウェイ装置。
【請求項22】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対してステートレスである、請求項18に記載のゲートウェイ装置。
【請求項23】
前記第1のメッセージは、前記情報をコンタクト−アクセプトヘッダに含むセッション開始プロトコル(SIP)メッセージである、請求項18に記載のゲートウェイ装置。
【請求項24】
前記情報は、ユニフォームリソースロケータ(URL)とICSIとのうちの少なくとも1つである、請求項18に記載のゲートウェイ装置。
【請求項25】
前記第2の信号伝達プロトコルはハイパーテキスト転送プロトコル(HTTP)である、請求項18に記載のゲートウェイ装置。
【請求項26】
前記通信インタフェースにおいて、アプリケーションIDを含む、前記第2の信号伝達プロトコルを使用する第2のメッセージを、前記非IMSノードから受信することをさらに含み、前記第2のメッセージはHTTP要求メッセージである、請求項18に記載のゲートウェイ装置。
【請求項27】
URLと、ICSIと、アプリケーションIDとを含む前記以前に記憶された情報を記憶する、事前設定テーブルをさらに備える、請求項18に記載のゲートウェイ装置。
【請求項28】
前記アプリケーションの各インスタンスは、前記記憶部において一意に識別される、請求項18に記載のゲートウェイ装置。
【請求項29】
前記一意の識別は、トランスミッションコントロールプロトコル(TCP)のハッシングとのアプリケーションIDの連結から作成される、請求項28に記載のゲートウェイ装置。
【請求項30】
SIPダイアログが維持されることを要求する第1のアプリケーションから発信されたメッセージを受信することと、SIPダイアログが維持されることを要求する第2のアプリケーションに関連するSIPメッセージを受信することとのうちの少なくとも1つによって、前記テーブルに項目が作成される、請求項28に記載のゲートウェイ装置。
【請求項31】
前記第1のメッセージを受信した後にSIPダイアログを確立する前記ゲートウェイと、
前記SIPダイアログと前記アプリケーションとをリンクさせる追加情報を記憶する前記記憶部とを備え、
前記ゲートウェイは、前記アプリケーションに関連する、前記IMSネットワークからの後続受信メッセージに対して、記憶された前記追加情報に基づいてセッション中通知を使用する、請求項18に記載のゲートウェイ装置。
【請求項32】
前記ゲートウェイは、前記アプリケーションの開始後に前記非IMSノードとのトランスミッションコントロールプロトコル(TCP)接続を確立し、前記アプリケーションが終了された後に前記非IMSノードとの前記TCP接続を終了する、請求項18に記載のゲートウェイ装置。
【請求項33】
前記非IMSノードはインターネットプロトコルテレビジョン端末機能(ITF)である、請求項18に記載のゲートウェイ装置。
【請求項34】
前記アプリケーションは、分散型アプリケーション環境(DAE)アプリケーションと埋込ITFアプリケーションとのうちの少なくとも1つである、請求項18に記載のゲートウェイ装置。
【請求項1】
インターネットプロトコル(IP)マルチメディアサブシステム(IMS)ネットワークと非IMSノードとの間でアプリケーション情報を相関させる方法であって、
ゲートウェイにおいて、第1の信号伝達プロトコルを使用する前記IMSネットワークから第1のメッセージを受信するステップと、
前記第1のメッセージから情報を読み出すステップと、
以前に記憶された情報と前記情報を相関させて、前記非IMSノードで動作する複数のアプリケーションのうちのいずれが前記第1のメッセージに関連しているかを判定するステップと、
前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに関連する情報を含む、前記第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用する第2のメッセージを、前記非IMSノードへ送信するステップと
を含む方法。
【請求項2】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに、SIPダイアログを使用する、請求項1に記載の方法。
【請求項3】
前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対する後続メッセージを受信するステップと、
前記非IMSノードにセッション中通知メッセージを送信するステップと
をさらに含む、請求項2に記載の方法。
【請求項4】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対して、記憶部に維持された状態を有する、請求項1に記載の方法。
【請求項5】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対してステートレスである、請求項1に記載の方法。
【請求項6】
前記第1のメッセージは、前記情報をコンタクト−アクセプトヘッダに含むセッション開始プロトコル(SIP)メッセージである、請求項1に記載の方法。
【請求項7】
前記情報は、ユニフォームリソースロケータ(URL)とIMS通信サービス識別子(ICSI)とのうちの少なくとも1つである、請求項6に記載の方法。
【請求項8】
前記第2の信号伝達プロトコルはハイパーテキスト転送プロトコル(HTTP)である、請求項1に記載の方法。
【請求項9】
前記第2の信号伝達プロトコルを使用して、アプリケーションIDを含む第2のメッセージを前記非IMSノードから受信するステップであって、前記第2のメッセージはHTTP要求メッセージであるステップをさらに含む、請求項1に記載の方法。
【請求項10】
前記以前に記憶された情報は、記憶されたURLと、ICSIと、アプリケーションIDとを含む、請求項1に記載の方法。
【請求項11】
前記複数のアプリケーションのうちの1つの各インスタンスは一意に識別される、請求項1に記載の方法。
【請求項12】
前記一意の識別は、トランスミッションコントロールプロトコル(TCP)のハッシングとのアプリケーションIDの連結から作成される、請求項11に記載の方法。
【請求項13】
SIPダイアログが維持されることを要求する第1のアプリケーションから発信されたメッセージを受信することと、SIPダイアログが維持されることを要求する第2のアプリケーションに関連するSIPメッセージを受信することとのうちの少なくとも1つによって、前記テーブルに項目が作成される、請求項11に記載の方法。
【請求項14】
前記第1のメッセージを受信した後にSIPダイアログを確立するステップと、
前記SIPダイアログと前記アプリケーションとをリンクさせる追加情報を記憶するステップと、
前記アプリケーションに関連する、前記IMSネットワークからの後続受信メッセージに対して、記憶された前記追加情報に基づいてセッション中通知を使用するステップと
をさらに含む、請求項1に記載の方法。
【請求項15】
前記アプリケーションの開始後に前記非IMSノードとのトランスミッションコントロールプロトコル(TCP)接続を確立するステップと、
前記アプリケーションが終了された後に前記非IMSノードとの前記TCP接続を終了するステップと
をさらに含む、請求項1に記載の方法。
【請求項16】
前記非IMSノードはインターネットプロトコルテレビジョン端末機能(ITF)である、請求項1に記載の方法。
【請求項17】
前記アプリケーションは、分散型アプリケーション環境(DAE)アプリケーションと埋込ITFアプリケーションとのうちの少なくとも1つである、請求項1に記載の方法。
【請求項18】
メッセージを送受信する通信インタフェースであって、第1の信号伝達プロトコルを使用する第1の受信メッセージが、アプリケーションに関連する情報を含む、通信インタフェースと、
アプリケーションIDと、ユニフォームリソースロケータ(URL)と、デフォルト情報と、IMS通信サービス識別子(ICSI)とを含む情報を記憶する記憶部と、
前記第1の信号伝達プロトコルを使用する前記第1の受信メッセージと、記憶された前記情報とを相関させ、前記第1の信号伝達プロトコルとは異なる第2の信号伝達プロトコルを使用する第2のメッセージのルーティング先のアプリケーションを識別する処理部であって、前記第2の信号伝達プロトコルを使用する前記第2のメッセージは、前記アプリケーションに関連する情報を含む、処理部と
を備えるゲートウェイ装置。
【請求項19】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに、SIPダイアログを使用する、請求項18に記載のゲートウェイ装置。
【請求項20】
前記通信インタフェースにおいて、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対する後続メッセージを受信し、前記非IMSノードにセッション中通知メッセージを送信することをさらに含む、請求項19に記載のゲートウェイ装置。
【請求項21】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対して、記憶部に維持された状態を有する、請求項18に記載のゲートウェイ装置。
【請求項22】
前記ゲートウェイは、前記非IMSノードで動作する複数のアプリケーションのうちの、前記第1のメッセージに関連している1つに対してステートレスである、請求項18に記載のゲートウェイ装置。
【請求項23】
前記第1のメッセージは、前記情報をコンタクト−アクセプトヘッダに含むセッション開始プロトコル(SIP)メッセージである、請求項18に記載のゲートウェイ装置。
【請求項24】
前記情報は、ユニフォームリソースロケータ(URL)とICSIとのうちの少なくとも1つである、請求項18に記載のゲートウェイ装置。
【請求項25】
前記第2の信号伝達プロトコルはハイパーテキスト転送プロトコル(HTTP)である、請求項18に記載のゲートウェイ装置。
【請求項26】
前記通信インタフェースにおいて、アプリケーションIDを含む、前記第2の信号伝達プロトコルを使用する第2のメッセージを、前記非IMSノードから受信することをさらに含み、前記第2のメッセージはHTTP要求メッセージである、請求項18に記載のゲートウェイ装置。
【請求項27】
URLと、ICSIと、アプリケーションIDとを含む前記以前に記憶された情報を記憶する、事前設定テーブルをさらに備える、請求項18に記載のゲートウェイ装置。
【請求項28】
前記アプリケーションの各インスタンスは、前記記憶部において一意に識別される、請求項18に記載のゲートウェイ装置。
【請求項29】
前記一意の識別は、トランスミッションコントロールプロトコル(TCP)のハッシングとのアプリケーションIDの連結から作成される、請求項28に記載のゲートウェイ装置。
【請求項30】
SIPダイアログが維持されることを要求する第1のアプリケーションから発信されたメッセージを受信することと、SIPダイアログが維持されることを要求する第2のアプリケーションに関連するSIPメッセージを受信することとのうちの少なくとも1つによって、前記テーブルに項目が作成される、請求項28に記載のゲートウェイ装置。
【請求項31】
前記第1のメッセージを受信した後にSIPダイアログを確立する前記ゲートウェイと、
前記SIPダイアログと前記アプリケーションとをリンクさせる追加情報を記憶する前記記憶部とを備え、
前記ゲートウェイは、前記アプリケーションに関連する、前記IMSネットワークからの後続受信メッセージに対して、記憶された前記追加情報に基づいてセッション中通知を使用する、請求項18に記載のゲートウェイ装置。
【請求項32】
前記ゲートウェイは、前記アプリケーションの開始後に前記非IMSノードとのトランスミッションコントロールプロトコル(TCP)接続を確立し、前記アプリケーションが終了された後に前記非IMSノードとの前記TCP接続を終了する、請求項18に記載のゲートウェイ装置。
【請求項33】
前記非IMSノードはインターネットプロトコルテレビジョン端末機能(ITF)である、請求項18に記載のゲートウェイ装置。
【請求項34】
前記アプリケーションは、分散型アプリケーション環境(DAE)アプリケーションと埋込ITFアプリケーションとのうちの少なくとも1つである、請求項18に記載のゲートウェイ装置。
【図1】
【図2】
【図3】
【図4】
【図5a】
【図5b】
【図6a】
【図6b】
【図7】
【図8a】
【図8b】
【図9】
【図10】
【図11】
【図2】
【図3】
【図4】
【図5a】
【図5b】
【図6a】
【図6b】
【図7】
【図8a】
【図8b】
【図9】
【図10】
【図11】
【公表番号】特表2011−524095(P2011−524095A)
【公表日】平成23年8月25日(2011.8.25)
【国際特許分類】
【出願番号】特願2010−549230(P2010−549230)
【出願日】平成21年3月2日(2009.3.2)
【国際出願番号】PCT/IB2009/050836
【国際公開番号】WO2009/109901
【国際公開日】平成21年9月11日(2009.9.11)
【出願人】(598036300)テレフオンアクチーボラゲット エル エム エリクソン(パブル) (2,266)
【Fターム(参考)】
【公表日】平成23年8月25日(2011.8.25)
【国際特許分類】
【出願日】平成21年3月2日(2009.3.2)
【国際出願番号】PCT/IB2009/050836
【国際公開番号】WO2009/109901
【国際公開日】平成21年9月11日(2009.9.11)
【出願人】(598036300)テレフオンアクチーボラゲット エル エム エリクソン(パブル) (2,266)
【Fターム(参考)】
[ Back to top ]