JP5379167B2 - Ｓｉｐ−ｈｔｔｐアプリケーション相関器 - Google Patents

Description

本発明は、一般に電気通信システムと、電気通信システムにおける改善サービスに関する。

技術レベルが向上するにつれて、通信の選択肢は多種多様なものとなった。例えば、ここ３０年間の電気通信産業において、個人通信は、一家に一台のダイヤル式電話機から、一家に複数の、音声にもデータにも対応した電話線、ケーブル線、および／または光ファイバ線へと発展した。また、通信においては、セルラ式電話やＷｉ−Ｆｉにより移動体（mobile element）が追加された。同様に、娯楽産業においては、３０年前はテレビジョン用フォーマットが１つしかなく、家庭に設置されたアンテナによって、このフォーマットが無線で送受信されていた。これについても、標準画質ＴＶ（SDTV：standard definition TV）、拡張画質ＴＶ（EDTV：enhanced definition TV）、高画質ＴＶ（HDTV：high definition TV）など様々な画質の規格に発展し、またこれらの様々なテレビジョン表示フォーマットを配信するため、ケーブルや衛星などの多くのシステムに発展した。また、この２つの産業間にまたがってサービスが成長した。このようなシステムが双方の産業において発展し続けると、サービス提供の併合も続き、消費者にとっては新たなサービスも期待されよう。また、このようなサービスは、例えばテレビジョンで観る番組の画質の向上に見られるように、より多くの情報を処理して出力する技術能力に基づくものとなる。したがって、サービス配信における必要条件については、エンドユーザへの「最後の１マイル（last mile）」まで含んだネットワーク全体でより多くの帯域幅が使用可能となることに依存し続けるであろう。

通信産業および娯楽産業の双方に影響を与える関連技術にはインターネットもある。１９９０年代始めからインターネットで使用されていたプロトコルの１つがハイパーテキスト転送プロトコル（HTTP：Hyper Text Transfer Protocol）である。このプロトコルは、まずはハイパーテキストマークアップ言語（HTML：Hyper Text Markup Language）ページにアクセスするためのものとして初期設計されたトランザクションベースのプロトコルであり、必ずしも、増加したデータフローを処理するように発展したインターネットの物理構造や関連する通信ストリームを処理するように設計されたものではない。例えば、サーバには以前よりも多くのメモリがあり、通信リンクには過去よりも高い帯域幅を有するものが存在し、プロセッサはより速く、より有能なものとなり、これらの要素の利用するプロトコルが存在する。消費者のインターネット利用が拡大するにつれて、サービス会社は、従来のサービスを提供する機構としてインターネット（および他のインターネットプロトコル（IP：Internet Protocol）ネットワーク）に専心した。例えばＨＴＴＰ１．１などのＨＴＴＰの発展により、上記に関連したＨＴＴＰの能力が改善され、様々なハードウェア販売業者がその機器にＨＴＴＰを統合することに精通している。今や、以前の改善点を利用した新たなサービスが存在しており、その例としては、ＩＰテレビジョン（IPTV。ＩＰデータパケットを用い、ネットワークによってテレビジョン番組を配信するシステムやサービスを指す。）ビデオオンデマンド（VOD：video on demand）、ボイスオーバＩＰ（VoIP：voice over IP）、単一あるいはまとめて受信される他のウェブ関連サービスなどが挙げられる。

ＩＰネットワークを用いて様々なサービスを提供する様々な新しい方法に対応するため、新たなネットワークアーキテクチャが開発され、規格化されている。ＩＰマルチメディアサブシステム（IMS：IP Multimedia Subsystem）は、ＩＰマルチメディアサービスをエンドユーザまで配信するために使用されるアーキテクチャフレームワークである。例えばセッション開始プロトコル（SIP：Session Initiation Protocol）などのＩＰプロトコルを用いて異種システムに収束機構を提供するサービス独立トポロジーへと、ＩＭＳアーキテクチャは発展した。これについては、アクセスネットワークをサービスレイヤから分離させる水平制御レイヤの提供によって達成される。とりわけ、ＩＭＳアーキテクチャは、ＩＰＴＶシステムやＩＰＴＶサービスの展開に有用なプラットフォームを提供することができる。

したがって、以下で説明する実施形態例は、異なる信号伝達プロトコルを使用する装置間の通信を容易にするネットワークエンティティおよび方法の必要性に取り組んだものである。

本発明に係るシステムおよび方法は、異なる信号伝達プロトコルを使用する装置間の通信を容易にするネットワークエンティティおよび方法の必要性に取り組んだものである。

実施形態例によれば、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワークと非ＩＭＳノードとの間でアプリケーション情報を動的に相関させる方法が、ゲートウェイにおいて、第１の信号伝達プロトコルを使用する上記ＩＭＳネットワークから第１のメッセージを受信するステップと、上記第１のメッセージから情報を読み出すステップと、以前に記憶された情報と上記情報を相関させて、上記非ＩＭＳノードで動作する複数のアプリケーションのうちのいずれが上記第１のメッセージに関連しているかを判定するステップと、上記非ＩＭＳノードで動作する複数のアプリケーションのうちの、上記第１のメッセージに関連している１つに関連する情報を含む、上記第１の信号伝達プロトコルとは異なる第２の信号伝達プロトコルを使用する第２のメッセージを、上記非ＩＭＳノードへ送信するステップとを含む。

別の実施形態例によれば、ゲートウェイ装置が、メッセージを送受信する通信インタフェースであって、第１の信号伝達プロトコルを使用する第１の受信メッセージが、アプリケーションに関連する情報を含む、通信インタフェースと、アプリケーションＩＤと、ユニフォームリソースロケータ（ＵＲＬ）と、デフォルト情報と、ＩＭＳ通信サービス識別子（ＩＣＳＩ）とを含む情報を記憶する記憶部と、上記第１の信号伝達プロトコルを使用する上記第１の受信メッセージと、記憶された上記情報とを相関させ、上記第１の信号伝達プロトコルとは異なる第２の信号伝達プロトコルを使用する第２のメッセージのルーティング先のアプリケーションを識別する処理部であって、上記第２の信号伝達プロトコルを使用する上記第２のメッセージは、上記アプリケーションに関連する情報を含む、処理部とを備える。

添付図面は実施形態例を示している。

図１は、実施形態例に係る、インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワークとインターネットプロトコルテレビジョン端末機能（ITF：Internet Protocol Television Terminal Function）との間の信号伝達を示す。 図２は、実施形態例に係る、ＩＭＳゲートウェイと通信中の複数のアプリケーションを実行しているＩＴＦを示す。 図３は、実施形態例に係るＩＭＳゲートウェイを示す。 図４は、実施形態例に係る、異なる種類のメッセージをＩＴＦへ送信するＩＭＳゲートウェイを示す。 図５ａは、実施形態例に係る、情報を記憶するアプリケーション識別テーブルを示す。 図５ｂは、実施形態例に係るトラフィックテーブルを示す。 図６ａは、実施形態例に係る、アプリケーションにアクセスするＩＭＳゲートウェイにおけるＳＩＰ信号伝達を示す信号伝達図である。 図６ｂは、実施形態例に係る、アプリケーションにアクセスするＩＭＳゲートウェイにおけるＳＩＰ信号伝達を示す信号伝達図である。 図７は、実施形態例に係る、アプリケーションにアクセスするＩＭＳゲートウェイにおけるＳＩＰ信号伝達を示す信号伝達図である。 図８ａは、実施形態例に係る、アプリケーションにアクセスするＩＭＳゲートウェイにおけるＳＩＰ信号伝達を示す信号伝達図である。 図８ａは、実施形態例に係る、アプリケーションにアクセスするＩＭＳゲートウェイにおけるＳＩＰ信号伝達を示す信号伝達図である。 図９は、実施形態例に係る、アプリケーションにアクセスするＩＭＳゲートウェイにおけるＳＩＰ信号伝達を示す信号伝達図である。 図１０は、実施形態例に係る通信ノードを示す。 図１１は、実施形態例に係る、ＩＭＳネットワークと非ＩＭＳとの間でノードアプリケーション情報を相関させる方法フローチャートを示す。

以下の実施形態例の詳細な説明では添付図面を参照する。異なる図面における同一参照番号は同一または同様のものを指している。また、以下の詳細な説明は本発明を限定するものではない。その代わりに、本発明の範囲は添付の特許請求の範囲によって限定される。

ハイパーテキスト転送プロトコル（ＨＴＴＰ）およびセッション開始プロトコル（ＳＩＰ）は、１または複数のネットワークによるサービス配信の支援に使用するプロトコルである。場合によっては、例えばインターネットプロトコルテレビジョン（ＩＰＴＶ）端末機能（ＩＴＦ）などの製造業者のようなハードウェア販売業者がその製品でＨＴＴＰを使用するところ、インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）ネットワークアーキテクチャをサービスの配信に使用するサービスプロバイダがその製品にセッション開始プロトコル（ＳＩＰ）を使用するということもあり得る。ＨＴＴＰはトランザクションベースのプロトコルであるところ、ＳＩＰは、ＳＩＰエンドポイントを有する装置間の通信を可能とするセッションベースのプロトコルである。ＨＴＴＰを使用するシステムは、例えばＩＰＴＶ信号を伝送するＨＴＴＰ信号伝達を用いて、サービスに関連したＩＭＳを受信可能であるが、典型的には、上述のＩＭＳネットワークアーキテクチャで使用されるＳＩＰなど、新たなアーキテクチャで使用されるプロトコルは使用可能ではない。ＳＩＰ信号伝達を用いる装置およびＨＴＴＰ信号伝達を用いる装置は、あるプロトコルから、さらなる伝送のための他のプロトコルへ情報を転換するために、例えばＩＭＳゲートウェイなどのインタフェースが必要であろう。この発想については、図１に示す構成要素例に関する上段に見られる。

図１は、ＩＴＦ２と、ＩＭＳゲートウェイ４と、ＩＭＳネットワーク１０とを含んでいる。www.openiptvforum.orgで見られるようなオープンＩＴＦ（OITF：Open ITF）必要条件にしたがうＩＴＦであればいかなるものであってもよいＩＴＦ２と、ＩＭＳゲートウェイ４は、例えば家庭などの同一の一般的な場所に設置され、ＨＴＴＰ信号伝達を用いて互いに通信する。ＩＭＳゲートウェイ４は、ＳＩＰ信号伝達を用いてＩＭＳネットワーク１０と通信する。この実施形態例では、認証およびセッション管理を行うコールセッション制御機能（CSCF：call session control function）６と、例えばメッセージング用ピアツーピア（P2P：peer-to-peer）通信イネーブラ１４および一意のユニフォームリソースロケータ（URL：uniform resource locator）に関連したネットワークサーバ８の２つのアプリケーションサーバとを有するものとして、ＩＭＳネットワーク１０を示している。ＩＭＳゲートウェイ４は、ＨＴＴＰ信号伝達およびＳＩＰ信号伝達の双方を用いる能力と、いずれかの側からの信号伝達要求を相関させる能力とを有する。より具体的には、ＩＭＳゲートウェイ４はＳＩＰメッセージを受信し、例えばＨＴＴＰ信号伝達などの非ＳＩＰ信号伝達を用いて、本発明によって以下で説明するようなＩＴＦ２で動作している正しいアプリケーションへ情報を送信する。ＨＴＴＰ信号伝達に関するさらなる情報については、１９９９年６月付のRequest for Comments（RFC：リクエストフォーコメント）2２６１６で見られる。ＩＭＳネットワーク１０は、単純化して、以下で説明する実施形態例における信号伝達処理を説明するために示したノードしか有していないように示してあるが、ＩＭＳネットワーク１０では典型的により多くのノードが見られるものであり、一般的にＩＭＳアーキテクチャおよびＳＩＰ信号伝達の詳細については、それぞれ、２００７年３月付のThird Generation Partnership Project（3GPP：第３世代パートナーシッププロジェクト）Technical Specification（TS：技術仕様書）23.228 Version（バージョン）8および２００２年６月付のＲＦＣ３２６１で見られる。

実施形態例によれば、図２に示すように、ＩＴＦ２は、例えばブラウザベースのアプリケーション１ ２０２、ブラウザベースのアプリケーション２ ２０４、ネイティブベースのアプリケーション１ ２１０などの複数のアプリケーションと、例えばブラウザベースのアプリケーション３のインスタンス１ ２０６、ブラウザベースのアプリケーション３のインスタンス２ ２０８などの同一アプリケーションの複数のインスタンスとを実行しているものとすることができる。ブラウザベースのアプリケーションは分散型アプリケーション環境（DAE：distributed application environment）で動作することが可能であり、例えばプレゼンスおよびチャット／メッセージングのようなアプリケーションが挙げられる。ネイティブベースのアプリケーションは、登録およびプロファイル管理のようなＩＴＦ埋込アプリケーションで動作することができる。しかしながら、ここでブラウザベースのもの、ネイティブベースのものに関するこれらのアプリケーション例は、純粋に例示的なものであり、当業者であれば、アプリケーションは、ブラウザベースとして開発されたものであるか、ネイティブベースとして開発されたものであるかによって限定されることはないということが理解されよう。また、図２に示すように、ＩＭＳゲートウェイ４は、恐らくはＩＴＦ２で動作するアプリケーションのうちの１つに関する情報を含むＳＩＰメッセージを受信する。ＩＭＳゲートウェイ４はこの情報を通知２１２としてＩＴＦ２へ送信し、ＩＴＦ２では、以下で説明するように所望のアプリケーションにこの通知が到達する。

ＩＭＳゲートウェイ例４について、図３を参照しながら説明する。ＩＭＳゲートウェイ４は、ＩＭＳネットワーク１０からの着信ＳＩＰメッセージ２１４を、ＩＴＦ２で動作するアプリケーションと整合させる。ＩＭＳゲートウェイ４は、ＩＴＦ２宛ての着信ＳＩＰメッセージ２１４がＩＴＦ２における適切なアプリケーションへ送信されたものであることを保証する責任がある通知ルータ３０２を備える。この機能の支援のもと、この実施形態例によって、通知ルータ３０２は認証／セッション管理機能３０６とＩＭＳゲートウェイ（ＩＧ）−ＩＴＦサーバ３０４とレジスタ３０８とを備える。認証／セッション管理機能３０６は、それ自体とその関連アプリケーションを有するＩＴＦ２とに対するＩＭＳネットワーク１０による許可およびセッション管理のために使用される。ＩＧ−ＩＴＦサーバ３０４はＩＴＦ２へメッセージを送信する。レジスタ３０８は、ＩＴＦ２で支援されたアプリケーションに関する情報と、ＳＩＰセッション情報と、ユニフォームリソースロケータ（ＵＲＬ）情報とを有し、その他にも、例えばオペレータネットワークによって事前設定された識別情報なども有する。このような情報を用いて、ＩＴＦ２で動作するアプリケーションを一意に識別し、着信ＳＩＰメッセージ２１４とその対応するＩＴＦアプリケーションとの正しい整合を行う。メッセージを送信するためにＳＩＰメッセージ／ＩＴＦアプリケーションの関係を判定するときには、認証／セッション管理機能３０６もＩＧ−ＩＴＦサーバ３０４もレジスタ３０８と通信する。また、これらの機能を用いて、必要に応じてレジスタ３０８に情報を加えることができる。この実施形態例に係るＩＭＳゲートウェイ４は、ＩＴＦ２で動作しているアプリケーションの知識と関連ＳＩＰダイアログ情報とを必要に応じて維持するステートフル（stateful）装置である。また、ＩＭＳゲートウェイ４は、ＩＴＦ２に電源が入っている限り、このような状態をその記憶部（図３には示していないが、以下で説明する図１０には示してある）に維持する。以下、アプリケーションについて、ＩＴＦ２およびＩＭＳゲートウェイ４の両視点から、より詳細に説明する。

実施形態例によれば、複数のアプリケーションが同時にＩＴＦ２で動作することが可能である。上述のように、これらのアプリケーションは、例えばＤＡＥベースのアプリケーションおよびＩＴＦ埋込アプリケーションのような、ＩＴＦ２でサービスロジックを実行するアプリケーションの２つの一般的なカテゴリに分類することができる。ＩＭＳゲートウェイ４の視点からは（ＩＭＳゲートウェイ４はＳＩＰを用いてＩＭＳネットワーク１０とのインタフェースを行う）、これらのアプリケーションは、例えばＳＩＰダイアログおよび状態情報の有無（または必要性）に応じて、この実施形態に係る３つの異なる方法で、ＳＩＰ通信とのインタフェースが行われる。

このような実施形態に係るＳＩＰ通信とアプリケーションとのインタフェースを行う第１の方法は、例えばプレゼンスやセッションセットアップなどのＳＩＰダイアログが必要なアプリケーションに関する。例えばＩＭＳゲートウェイ４およびＩＭＳノードなど、ＳＩＰエンドポイントを有する２つのエンティティが、ＳＩＰを用いた通信を行うと、ＳＩＰダイアログが発生する。他のアプリケーションではＳＩＰダイアログを必要としない。かかる他のアプリケーションは、まずは、スタンドアローントランザクション型のアプリケーション（インスタントメッセージまたは登録）であり、ＳＩＰダイアログが必要ではない。ＩＭＳゲートウェイ４への着信ＳＩＰメッセージは、実施形態例に係るイベントを処理するための、例えば新たなメッセージ、既存のＳＩＰダイアログに対するメッセージ、またはＩＴＦ２のアプリケーションからの要求に対するメッセージ応答のような３つの種類のメッセージのうちの１つと見なすことが可能である。新たなメッセージは、例えば、既存のＳＩＰダイアログがないＳＩＰ ＭＥＳＳＡＧＥとすることができる。既存のメッセージは、例えば、既存のＳＩＰダイアログに属するＳＩＰ ＮＯＴＩＦＹとすることができる。メッセージ応答は、例えば、ＩＴＦ２由来でＩＭＳゲートウェイ４が正しく修正／送信したサービス要求メッセージなどのＩＭＳゲートウェイ４による要求に応じたＳＩＰ ２００ ＯＫとすることができる。異なる処理が行われるこれら３つの通知イベントについて、以下でさらに詳細に説明する。

実施形態例によれば、図４に示すように、ＩＭＳゲートウェイ４はＩＴＦ２と通信し、通知イベントの種類に基づく異なる種類の通知を適切なアプリケーションへ配信する。まず、ＩＭＳゲートウェイ４は着信ＳＩＰメッセージ２１４を受信する。どの種類のイベントが受信されたのかを通知ルータ３０２が判定する。そして、通信ルータ３０２は、セッション中通知４１４または第三者通知４１６のいずれかを作成し、ＩＴＦ２へ送信する。セッション中通知は、典型的には、ＩＴＦ２のアクティブアプリケーションとＩＭＳゲートウェイ４との間に進行中の通信がある場合に使用する。第三者通知は、典型的には、ＩＴＦ２の非アクティブアプリケーションとの通信を開始する新たなメッセージに対して使用する。通知がセッション中通知４１４であった場合、この通知は、例えばＤＡＥ Ａｐｐ１ ４０８やＤＡＥ Ａｐｐ２ ４１２など、ＩＴＦ２のブラウザ部４０４で目下動作中の適切なＤＡＥアプリケーションへ送信される。通知が第三者通知４１６であった場合、この通知は、ＩＴＦ２においてルータ機能と同様に機能する第三者通知処理部４２０へ送信される。

そして、第三者通知処理部４２０は、受信した通知がＤＡＥブラウザベースのアプリケーション４０２へ向かう必要があるのか、ＩＴＦ埋込アプリケーション４０６へ向かう必要があるのか判定する。通知がＤＡＥブラウザベースのアプリケーション４０２へ向かうものであった場合、ブラウザ４０４がＤＡＥブラウザベースのアプリケーション４０２に対してアクセス可能なユニフォームリソースロケータ（ＵＲＬ）が送信される。受信した通知がＩＴＦ埋込アプリケーション４０６へ向かうものであった場合、この通知は、アプリケーションプログラミングインタフェース（API：application programming interface）を通じて、使用を所望するＩＴＦ埋込アプリケーション４０６へ送信される。また、図４には示していないが、初期サービス要求などのメッセージをＩＴＦ２からＩＭＳゲートウェイ４へ送信して、ＩＭＳネットワーク１０へ送信することも可能である。

上述のように、ＩＴＦ２は、ＨＴＴＰ信号伝達を用いて、アクティブアプリケーションからの要求をＩＭＳゲートウェイ４へ送信することができる。実施形態例によれば、特にＩＭＳゲートウェイ４で受信するＳＩＰメッセージの調整について、アプリケーションの正しい追跡を容易にするため、アプリケーションごとに一意のアプリケーションＩＤ（identification）を、ＩＴＦ２からＩＭＳゲートウェイ４へのＨＴＴＰ要求メッセージへ挿入する。この要求は、ＩＴＦ２で動作するＤＡＥアプリケーション４０８、４１２、およびＩＴＦ埋込アプリケーション４０６の両方に対して発生させることが可能である。ＤＡＥアプリケーション４０８、４１２、およびＩＴＦ埋込アプリケーション４０６については、欧州電子計算機工業会（ECMA：European Computer Manufacturers Association）スクリプトを用いて、ＨＴＴＰ要求メッセージのヘッダまたはヘッダ拡張子へ一意のアプリケーションＩＤを挿入することができる。かかるアプリケーションＩＤについては、規格化されていることも、規格化されていないこともあるが、メッセージの適切なルーティングを容易にするためには一意であるべきである。一意性を保証する方法の１つとしては、一意性を表すプロパティを有するサービスユニフォームリソースネーム（URN：uniform resource name）でアプリケーションＩＤを表すことが挙げられる。ＵＲＮについてのさらなる情報に関心がある読者は、１９９７年５月付のＲＦＣ２１４１を参照のこと。また、上述のように、この一意のアプリケーションＩＤをもつＨＴＴＰ要求メッセージに新たなフィールドを追加することも可能である。

実施形態例によれば、ＩＴＦ２からのＨＴＴＰ要求がＩＭＳゲートウェイ４で受信されると、一意のアプリケーションＩＤは、対応するＳＩＰダイアログとともに、また適用可能であれば記憶された状態とともに、ＩＭＳゲートウェイ４に維持される。また、ＨＴＴＰ要求が受信され、ＳＩＰダイアログが作成されると、ＩＭＳゲートウェイ４は、ＳＩＰダイアログについて、進行中のイベントの報告に使用する通知の種類に関する動的な情報を維持する。

上述のように、ＩＭＳゲートウェイ４は、ＩＴＦ２で動作するアプリケーションに関する情報とＳＩＰダイアログ情報とを記憶する。実施形態例によれば、識別情報がレジスタ３０８に記憶されており、着信ＳＩＰメッセージ２１４からの情報を、ＩＴＦ２で動作する正しいアプリケーションへ送信することが可能である。レジスタ３０８に識別情報を記憶するテーブル例５００および５２０を、それぞれ図５（ａ）および５（ｂ）に示す。レジスタ３０８のアプリケーション識別テーブル例５００は、例えば、ＩＭＳゲートウェイ４が第三者通知の処理に用いることができる。より具体的に、この例では、アプリケーションテーブル５００は、典型的にはサービスプロバイダ（SP：service provider）によって遠隔的に事前設定されたものであり、サービスプロバイダが提供するＤＡＥアプリケーションに対するアプリケーションＩＤと、対応するＤＡＥアプリケーションに使用されるＵＲＬとを有する。ＩＴＦ埋込アプリケーションは、ＵＲＬの使用を必要とせず、ホームネットワークインタフェース−ＩＭＳゲートウェイインタフェース（HNI-IGI：home network interface-IMS gateway interface）（図示せず）においてスタートアップの間にＩＭＳゲートウェイ４に登録する。ＩＴＦ２配置は、表示する能力と、ユーザとやり取りを行う能力とを有する。

この実施形態によれば、着信ＳＩＰメッセージ２１４をアプリケーションに整合させるアシストに、およびＩＭＳ要求に対する順守についての発信ＳＩＰメッセージのチェックに、ＩＭＳゲートウェイ４が使用するものとして、ＩＭＳ通信サービス識別子（ICSI：IMS communication service identifier）をアプリケーションごとに定めることができる。場合によっては、同一のアプリケーションの複数のインスタンスを同時にＩＴＦ２で動作させることも可能である。この支援のもと、トラフィックテーブル例５２０は、ＩＭＳゲートウェイ４がアプリケーションのインスタントの異なるものどうしを区別できる情報を記憶する。テーブル５００および５２０に記憶されたこれらの種々の識別情報を何度も用いて、ＩＭＳゲートウェイ４は、どの通知またはメッセージがＩＴＦ２におけるどのアプリケーション（またはアプリケーションインスタンス）へルーティングすべきかを識別することができる。アプリケーション識別テーブル例５００およびトラフィックテーブル例５２０について、以下でさらに詳細に説明する。また、アプリケーション識別テーブル５００およびトラフィックテーブル５２０は、２つの別々のテーブルとして示してあるが、単一のテーブルに記憶することも可能であり、あるいは、情報を結びつけたままで２よりも多くのテーブルにさらに分散させることも可能である。

図５（ａ）に示すように、アプリケーション識別テーブル５００は、行５０２を読み取ると示されるように、必要に応じて、アプリケーションＩＤ５０４と、ＤＡＥアプリケーションに対して第三者通知で使用されるＵＲＬ５０８と、ＩＣＳＩ５０６との間に結びつきを維持する。また、デフォルトＵＲＬを使用するデフォルトＤＡＥアプリケーションも示してあるが、これについては、着信ＳＩＰメッセージがＩＣＳＩまたはアプリケーションＩＤを有していない場合（アプリケーション識別テーブル５００では「設定なし」という項目で示している）に使用可能である。アプリケーション識別テーブル５００は、着信ＳＩＰメッセージがＩＣＳＩと、アプリケーションＩＤとを含む場合、ＩＣＳＩおよびアプリケーションＩＤの両方を含む場合、ＩＣＳＩもアプリケーションＩＤも含まない場合にイベントの処理に使用する情報を通知ルータ３０８に提供する。この情報を他の情報とともに使用して、ＩＭＳゲートウェイ４はイベントを処理する。

実施形態例によれば、図５（ｂ）に示すように、トラフィックテーブル５２０はＳＩＰダイアログ、または着信ＳＩＰメッセージ２１４の特定ＳＩＰヘッダにおけるアプリケーション識別情報と、アプリケーションインスタンスとの間の結びつきを維持する。各結びつきは、テーブル５２０において各項目５２２、５２４、５２６で示すように表されており、項目１ ５２２はアプリケーションの第１インスタンスに結びつけられたＳＩＰダイアログ（またはアプリケーション識別情報）を表し、項目２ ５２４は同一アプリケーションの第２インスタンス、または異なるアプリケーションの第１インスタンスを表し、項目３ ５２６は同一アプリケーションの第３インスタンス、またはＩＴＦ２で目下動作中の異なるアプリケーションの第１インスタンスを表すものとすることができる。着信ＳＩＰメッセージ２１４を処理するために項目５２２、５２４、５２６が選択されると、項目５２２、５２４、５２６は、関連アプリケーションインスタンスへ向かう着信トラフィックに使用するＴＣＰをＩＭＳゲートウェイ４が一意に識別できるほど十分な状態情報を有するであろう。また、このようにＴＣＰを使用することで、ＩＭＳゲートウェイ４は、例えばＴＣＰが適切に終了することなどから、アプリケーションインスタンスがいつ終了したかを認識することが可能であり、例えば複数のＴＣＰリンクが同時に手荒にシャットダウンされるなど、同一アプリケーションの異なるインスタンスの複数のＴＣＰリンクが不適切に終了した場合のエラーリカバリも可能である。また、実施形態例によれば、トラフィックテーブル５２０に必要であれば、項目５２２、５２４、５２６に追加状態情報を記憶することも可能である。

実施形態例によれば、様々なトラフィックシナリオによって、項目５２２、５２４、５２６を作成してトラフィックテーブル５２０に記憶することが必要となり得る。第１のシナリオでは、例えばメッセージおよび／または信号伝達などのトラフィックがＩＴＦ２のアプリケーションから発信され、ＩＭＳゲートウェイ４へ送信される。ＩＭＳゲートウェイ４はＳＩＰダイアログの維持を要求する。ＩＭＳゲートウェイ４は、ＩＭＳゲートウェイ４はＩＭＳネットワーク１０にセッション確立の要求を送信し、ＳＩＰダイアログが作成され、維持される。そして、項目５２２、５２４、５２６が作成され、トラフィックテーブル５２０に記憶される。トラフィックテーブル５２０は、アプリケーションインスタンスをＳＩＰダイアログと結びつけて、例えばＴＣＰ情報などの他の必要な状態情報を記憶する。

実施形態によれば、第２のシナリオでは、ＩＴＦ２のアプリケーションからトラフィックが発信され、ＩＭＳゲートウェイ４へ送信されるが、ＳＩＰダイアログを作成して維持する必要はない。このシナリオでは、項目５２２、５２４、５２６をトラフィックテーブル５２０に作成する必要がない。その代わり、ＩＴＦ２の発信アプリケーションに応じて、例えば発信アプリケーションが登録アプリケーション（など）である場合には、ＳＩＰ状態を作成してＩＭＳゲートウェイ４に記憶し、あるいは、例えば発信アプリケーションがインスタントメッセージングアプリケーション、スタンドアローントランザクションアプリケーション（など）である場合には、ＩＭＳネットワーク１０とのやり取りが完了できたら、状態を維持しない。

別の実施形態例によれば、第３のシナリオでは、ＳＩＰメッセージ２１４がＩＭＳゲートウェイ４によってＩＭＳネットワーク１０から受信されるが、トラフィックテーブルに項目はない。この場合、ＩＭＳゲートウェイ４はアプリケーション識別テーブル５００を用いて適切なアプリケーションを識別し、以下でさらに詳細に説明するように、ＩＴＦ２の適切なアプリケーションへ要求を送信する。識別されたアプリケーションに応じて、トラフィックテーブル５２０に項目５２２、５２４、５２６を作成することができる。例えば、識別されたアプリケーションがＳＩＰダイアログの維持を必要とする場合、ＩＭＳゲートウェイによってＩＴＦ２からの成功応答を受信すると、続いて項目５２２、５２４、５２６を作成する。別の例では、識別されたアプリケーションがＳＩＰダイアログの維持を必要としない場合、トラフィックテーブル５２０への項目５２２、５２４、５２６の作成および記憶は行わない。その代わり、トランザクションは完了され、全トランザクションが完了できるまで、ＩＭＳゲートウェイ４はステートフルのままである。さらに別の例では、識別されたアプリケーションがＳＩＰダイアログを必要としてはいないが、着信メッセージに対してアクティブのままでいようとする場合、そのＴＣＰ接続を維持することによってこのことを示すことが可能であり、トラフィックテーブル５２０に項目５２２、５２４、５２６が作成され、維持される。

したがって、実施形態によれば、ＩＭＳゲートウェイ４は、ＩＭＳネットワーク１０からの様々な着信ＳＩＰメッセージを処理する。この様々な着信ＳＩＰメッセージは、ＩＭＳゲートウェイ４に利用可能な情報に応じて様々にＩＴＦ２へ送信される通知を必要とする。第１の実施形態例では、ＩＭＳゲートウェイ４は、トラフィックテーブル５２０を調べることによって、着信ＳＩＰメッセージに関するＳＩＰダイアログが以前に存在しているものであるか判定する。着信ＳＩＰメッセージに関するＳＩＰダイアログが以前に存在しているものであれば、ＩＭＳゲートウェイ４によって、ＴＣＰリンクを通じて適切なアプリケーションインスタンスにセッション中通知が送信される。送信される通知には、受信ＳＩＰメッセージのペイロード部分（またはカプセル化バージョン）が含まれており、ペイロード部分は関連ＳＩＰヘッダを有している。

ＳＩＰ通信とのアプリケーションのインタフェースを行う第２の方法は、例えば登録など、ＳＩＰダイアログは必要ないが状態はＩＭＳゲートウェイ４に維持されるアプリケーションに関する。別の実施形態例では、ＩＭＳゲートウェイ４は、既存のＳＩＰダイアログがないＳＩＰメッセージをＩＭＳネットワーク１０から受信する。しかしながら、この場合、意図するアプリケーションインスタンスをＩＭＳゲートウェイが識別し、セッション中通知を使用して、適切なＴＣＰリンクを通じてＩＴＦ２の正しいアプリケーションインスタンスへ送信することができる状態情報が、そのためにトラフィックテーブル５２０に記憶されている。送信される通知には、受信ＳＩＰメッセージのペイロード部分（またはカプセル化バージョン）が含まれており、ペイロード部分は関連ＳＩＰヘッダを有している。

ＳＩＰ通知とのアプリケーションのインタフェースを行うこの第３の方法は、ＩＭＳゲートウェイ４の視点からは、例えばメッセージングおよび発呼者識別など、ＳＩＰダイアログも状態も必要としないアプリケーションに関する。別の実施形態例では、ＩＭＳゲートウェイ４は、対応するＳＩＰダイアログも、トラフィックテーブル５２０に存在する目下維持されている状態情報もないＳＩＰメッセージをＩＭＳネットワーク１０から受信する。この場合、アプリケーションＩＤの識別は、テーブル５００を調べることが必要となり、また着信メッセージのコンテンツ、特にアクセプト−コンタクト（Accept-Contact：受入−連絡）ＳＩＰヘッダのコンテンツに依存する。実施形態例によれば、ＳＩＰヘッダのAアクセプト−コンタクトフィールドは、ＩＭＳゲートウェイ４がＳＩＰメッセージをＩＴＦ２で動作するアプリケーションと整合させることができる情報を含んだものとすることができる。ＳＩＰメッセージのアクセプト−コンタクトフィールドについてのさらなる情報に関心のある読者は、２００４年付のＲＦＣ３８４１を参照のこと。この情報を用いて、ＩＭＳゲートウェイ４は、ＳＩＰメッセージをＩＴＦ２のアプリケーションにリンクさせて、そのために第三者通知を使用して通知を送信する。送信される通知には、テーブル５００における整合した項目から選択される情報に加えて、受信ＳＩＰメッセージのペイロード部分（カプセル化バージョン）が含まれており、ペイロード部分は関連ＳＩＰヘッダを有している。

さらに別の実施形態例によれば、ＩＭＳゲートウェイ４は、ＩＣＳＩのみを明示的に含むＳＩＰメッセージをＩＭＳネットワーク１０から受信し、ＩＭＳゲートウェイ４はデフォルトアプリケーションＩＤを推測して使用する。アプリケーション識別テーブル５００は、典型的には、必要であればＩＣＳＩに使用するデフォルトアプリケーションＩＤを有する。例えば、図５（ａ）の行５１４および５１６に示すように、ＩＣＳＩ１およびＩＣＳＩ２はデフォルトアプリケーションＩＤに結び付けられている。このデフォルトアプリケーションＩＤを使用して、ＩＭＳゲートウェイ４は、受信した通知をＩＴＦ２のデフォルトアプリケーションＩＤへ送信する。また、着信ＳＩＰメッセージがＩＣＳＩもアプリケーションＩＤも含んでいない場合には、デフォルトＵＲＬを使用する。

別の実施形態例によれば、ＩＭＳゲートウェイ４は、ＩＣＳＩもアプリケーションＩＤも明示的に含むＳＩＰメッセージをＩＭＳネットワーク１０から受信し、ルータ機能３０２は、アプリケーション識別テーブル５００を調べることによって、受信した通知を、ＩＴＦ２で動作するアプリケーションにリンクさせることができる。この場合、ＩＭＳゲートウェイ４は、例えば第三者通知など、識別したアプリケーションへの送信用の通知情報を含むメッセージをＩＴＦ２へ送信する。送信される通知には、テーブル５００における整合した項目から選択される情報に加えて、受信ＳＩＰメッセージのペイロード部分（カプセル化バージョン）が含まれており、ペイロード部分は関連ＳＩＰヘッダを有している。

ＩＭＳゲートウェイ４がＳＩＰメッセージを受信し、セッション中通知なのか第三者通知なのか判定した後、ＩＭＳゲートウェイ４は通知を適切に送信する。例えば、ＳＩＰメッセージがセッション中通知である場合は、典型的には状態情報によって判定されるのだが、ＩＭＳゲートウェイ４は、ＨＴＴＰ信号伝達または他の信号伝達方式を使用して、ＩＴＦ２で動作する適切なアプリケーションへ通知情報を送信する。通知が第三者通知であると判定されると、通知情報はＩＴＦ２の第三者通知処理部４２０へ送信され、第三者通知処理部４２０は、例えばＩＴＦ埋込アプリケーション４０６やＤＡＥブラウザアプリケーション４０２などの正しいアプリケーションへ通知情報を送信する。第三者通知処理部４２０は、この判定を、第三者通知メッセージ４１６で受信した情報に基づいて行う。まず、第三者通知処理部４２０は、第三者通知メッセージ４１６においてアプリケーションＩＤを探す。アプリケーションＩＤがあっても、第三者通知処理部４２０が認識しなければ、含まれているＵＲＬを使用して、ネットワークアプリケーションＤＡＥに要求を処理させる。第三者通知処理部４２０がアプリケーションＩＤを認識する場合は、第三者通知処理部４２０は、必要なアプリケーションがＩＴＦ埋込アプリケーション４０６であると考え、それに応じて、適切なＡＰＩを使用して通知を送信する。

他の実施形態例によれば、ＩＴＦ２から要求を発生させて、ＩＭＳゲートウェイ４からＩＭＳネットワーク１０へ発信トラフィックを送信することも可能である。続いて受信した着信ＳＩＰメッセージを必要なアプリケーションに整合させることなど、様々な方法を用いて、発信アプリケーションを一意に識別することができる。例えば、ＤＡＥアプリケーション４０８、４１２、またはＩＴＦ埋込アプリケーション４０６がメッセージを発信すると、新たなＨＴＴＰヘッダにアプリケーションＩＤを埋め込むことが可能であり、アプリケーションＩＤは、ＩＭＳゲートウェイ４によって抽出される。あるいは、ＤＡＥアプリケーション４０８、４１２、およびＩＴＦ埋込アプリケーション４０６は、新たなＨＴＴＰヘッダにＩＣＳＩを含めることが可能であり、ＩＣＳＩは、ＳＩＰヘッダにおける追加情報とともに、ＩＭＳゲートウェイ４がアプリケーション識別テーブル５００に関連して使用して、アプリケーションＩＤの位置を突き止めることができる。

ここで図６〜９を参照しながら、上述のシステム例および方法例に基づいた信号伝達図例について説明する。図６（ａ）は、ＩＴＦ２において目下アクティブなメッセージングアプリケーションがなく、ＳＩＰメッセージ受信して、メッセージングアプリケーションを開始する信号伝達図例を示している。まず、「appid=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE６０２がＰ２Ｐ通信イネーブラ１２からＣＳＣＦ６へ送信され、ＣＳＣＦ６は、SIP MESSAGE６０２をＩＭＳゲートウェイ４内の認証／セッション管理機能３０６へ送信する。ＩＭＳゲートウェイ４は、トラフィックテーブル５２０を調べ、着信ＳＩＰメッセージに整合する項目がないことを確認する。そして、ＩＭＳゲートウェイは、アプリケーション識別テーブル５００を調べ、例えば「appid=MESSAGING」などの受信したアクセプト−コンタクトヘッダ情報に、および必要に応じてテーブル５００の情報に基づいて、アプリケーションＩＤの位置を突き止める。そして、認証／セッション管理機能３０６が、メッセージ６０４を送信して、ＩＧ−ＩＴＦサーバ３０４へ第三者通知を呼び出す。そして、ＩＧ−ＩＴＦサーバ３０４は、メッセージ６０６を送信して、アプリケーションＩＤ（「appid」）とＵＲＬ（アプリケーション識別テーブル５００から取得）とを含む第三者通知をＩＴＦ２へ呼び出す。

この例では、ＩＴＦ２の第三者通知処理部４２０は、受信したappidを認識せず、その代わりにＩＴＦ２が、メッセージ６１４に示すように、受信したＵＲＬを使用してアプリケーションを取得する。ネットワークサーバ８がHTTP Get URLメッセージ６１４を受信したら、メッセージ６１６に示すように、ＥＣＭＡスクリプトを用いたジェネリックＤＡＥアプリケーションハンドラを含む200 OKメッセージがＩＴＦ２へ返信される。ほぼ同時に、ＩＧ−ＩＴＦサーバ３０４は認証／セッション管理機能３０６にオペレーション結果６０８を返信する。オペレーション結果６０８に基づいて、認証／セッション管理機能３０６は、202 ACCEPTEDメッセージをＣＳＣＦ６へ送信し、ＣＳＣＦ６は202 ACCEPTEDメッセージをＰ２Ｐ通信イネーブラ１２へ送信する。メッセージングアプリケーションがアクティブのままでいることを望めば、ＴＣＰ接続を維持する。そして、ＩＭＳゲートウェイ４はトラフィックテーブル５２０に項目を作成して、追加ＳＩＰとアプリケーション関連状態情報とを維持する。これにより、着信ＳＩＰメッセージがメッセージアプリケーション宛てである場合、この場合に第三者通知を使用するのとは対照的に、セッション中通知を使用して、メッセージングアプリケーションを後に呼び出すことができる。

実施形態例によれば、図６（ｂ）は、ＩＴＦ２においてメッセージングＤＡＥが目下アクティブに動作しており、ＩＧ−ＩＴＦサーバ３０４との永久的ＴＣＰ接続を有している場合に、メッセージングアプリケーションに関するＳＩＰメッセージを受信する信号伝達図例を示している。まず、情報「appid=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE６１８がＰ２Ｐ通信イネーブラ１２からＣＳＣＦ６へ送信され、ＣＳＣＦ６は、SIP MESSAGE６１８をＩＭＳゲートウェイ４内の認証／セッション管理機能３０６へ送信する。ＩＭＳゲートウェイ４は、トラフィックテーブル５２０を調べ、SIP MESSAGE６１８のアクセプト−コンタクトヘッダに基づいて着信ＳＩＰメッセージを処理可能な項目の位置を突き止める。また、そのステートフル能力に基づいて、ＩＭＳゲートウェイ４は、ＤＡＥメッセージアプリケーションがＩＴＦ２で目下動作中であり、そのためセッション中通知を使用すべきであることがわかる。そして、認証／セッション管理機能３０６が、メッセージ６２０を送信して、ＩＧ−ＩＴＦサーバ３０４へ第三者通知を呼び出す。そして、ＩＧ−ＩＴＦサーバ３０４は、拡張可能マークアップ言語（XML：extensible markup language）を使用可能なＩＴＦ２へのセッション中通知を呼び出すためのメッセージ６２２を送信する。そして、ＩＧ−ＩＴＦサーバ３０４から認証／セッション管理機能３０６にオペレーション結果メッセージ６２４が送信される。そして、認証／セッション管理機能３０６は202 Acceptedメッセージ６２６をＣＳＣＦ６へ送信し、ＣＳＣＦ６は202 Acceptedメッセージ６２８をＰ２Ｐ通信イネーブラ１２へ送信する。

実施形態によれば、図７は、ＩＴＦ２がプレゼンスアプリケーションで動作している場合の信号伝達例を示している。まず、事前に取得されているもので、プレゼンス通知のためにＩＧ−ＩＴＦサーバ３０４とのＴＣＰ接続を確立するプレゼンスアプリケーションを、ユーザが開始する。これにより、トラフィックテーブル５２０に項目が作成され、ＩＭＳゲートウェイ４はこの項目を使用して、同一ダイアログに関連する着信ＳＩＰプレゼンス通知メッセージを整合させることができる。さらにこれにより、ＩＭＳゲートウェイ４はセッション中通知を使用して、着信プレゼンス通知メッセージをＩＴＦ２のプレゼンスアプリケーションに送信することが可能となる。プレゼンス情報を含むSIP NOTIFYメッセージ７０２をＰ２Ｐ通信イネーブラ１２からＣＳＣＦ６を介して受信すると、ＩＭＳゲートウェイ４は、トラフィックテーブル５２０の適切なＳＩＰダイアログとメッセージ７０２を整合させ、適切なアプリケーションインスタンスを選択する。また、ＩＭＳゲートウェイ４は、この場合にはセッション中通知を使用すべきであることがわかる。そして、認証／セッション管理機能３０６は、メッセージ７０４を送信して、ＩＧ−ＩＴＦサーバ３０４へセッション中通知を呼び出す。そして、ＩＧ−ＩＴＦサーバ３０４は、ＸＭＬとすることが可能な着信NOTIFYを含むセッション中通知を呼び出すためのＩＴＦ２へのメッセージ７０６を送信する。そして、ＩＧ−ＩＴＦサーバ３０４から認証／セッション管理機能３０６にオペレーション結果メッセージ７０８が送信される。そして、認証／セッション管理機能３０６は200 OKメッセージ７１０をＣＳＣＦ６へ送信し、ＣＳＣＦ６は200 OKメッセージ７１０をＰ２Ｐ通信イネーブラ１２へ送信する。

実施形態例によれば、図８（ａ）は、ＩＴＦ埋込アプリケーションを使用したメッセージングの場合の信号伝達例を示している。まず、Ｐ２Ｐ通信イネーブラ１２が、「ICSI=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE８０２をＣＳＣＦ６へ送信し、ＣＳＣＦ６は、SIP MESSAGE８０２をＩＭＳゲートウェイ４の認証／セッション管理機能３０６へ送信する。ＩＭＳゲートウェイ４は、アクセプト−コンタクトにおける情報を取り、トラフィックテーブル５２０を調べ、着信ＳＩＰメッセージに整合する項目がないことを確認する。そして、ＩＭＳゲートウェイは、アプリケーション識別テーブル５００を調べ、例えばテーブル５００の同一行５１１に見られるようなアプリケーションＩＤに結び付けられているテーブル５００に記憶されたＩＣＳＩに、受信したＩＣＳＩを整合させる。認証／セッション管理機能３０６は、ＩＴＦ２へのアプリケーションＩＤを含む第三者通知をＩＴＦ２が呼び出すための情報を有するメッセージ８０４をＩＧ−ＩＴＦサーバ３０４へ送信する。ＩＴＦ２の第三者通知処理部４２０は、メッセージ８０６を受信してアプリケーションＩＤを認識し、ＩＴＦ２は埋込メッセージングアプリケーションを起動する。例えば、メッセージング用のＤＡＥブラウザベースのアプリケーション４０２の代わりに、メッセージング用のＩＴＦ埋込アプリケーション４０６が起動される。そして、ＩＧ−ＩＴＦサーバ３０４から認証／セッション管理機能３０６へオペレーション結果が送信される。そして、認証／セッション管理機能３０６は202 Acceptedメッセージ８１０をＣＳＣＦ６へ送信し、ＣＳＣＦ６は202 Acceptedメッセージ８１２をＰ２Ｐ通信イネーブラ１２へ送信する。ＩＴＦ埋込アプリケーション４０６はアクティブのままでＴＣＰ接続を維持することを選択可能であり、その場合は、セッション中通知を使用して、このアプリケーション宛の後続の着信メッセージを配信できる項目を、ＩＭＳゲートウェイ４がトラフィックテーブル５２０に作成する。

実施形態例によれば、図８（ｂ）は、ＩＧ−ＩＴＦサーバ３０４とのＴＣＰ接続を有するＩＴＦ２おいてアクティブな埋込メッセージアプリケーションが目下動作している場合に、メッセージングアプリケーションに関するＳＩＰメッセージを受信する信号伝達例を示している。まず、情報「ICSI=MESSAGING」をアクセプト−コンタクトヘッダに含むSIP MESSAGE８１４がＰ２Ｐ通信イネーブラ１２からＣＳＣＦ６へ送信され、ＣＳＣＦ６は、SIP MESSAGE８１４をＩＭＳゲートウェイ４内の認証／セッション管理機能３０６へ送信する。ＩＭＳゲートウェイ４は、トラフィックテーブル５２０を調べ、SIP MESSAGE８１４のアクセプト−コンタクトヘッダの情報に基づいて着信メッセージを処理可能な項目の位置を突き止める。そのステートフル能力に基づいて、ＩＭＳゲートウェイ４は、セッション中通知を使用すべきであることがわかる。そして、認証／セッション管理機能３０６が、メッセージ８１６を送信して、ＩＧ−ＩＴＦサーバ３０４へ第三者通知を呼び出す。そして、ＩＧ−ＩＴＦサーバ３０４は、メッセージ６２２をＩＴＦ２へ送信し、ＸＭＬとすることができる情報を含むセッション中通知を呼び出す。そして、ＩＧ−ＩＴＦサーバ３０４から認証／セッション管理機能３０６にオペレーション結果メッセージ８２０が送信される。そして、認証／セッション管理機能３０６は202 Acceptedメッセージ８２２をＣＳＣＦ６へ送信し、ＣＳＣＦ６は202 Acceptedメッセージ８２４をＰ２Ｐ通信イネーブラ１２へ送信する。

実施形態によれば、図９は、ＩＭＳゲートウェイ４においてアプリケーションＩＤまたはＩＣＳＩを含まないＳＩＰメッセージを受信する信号伝達例を示している。まず、Ｐ２Ｐ通信イネーブラ１２がSIP PUBLISHメッセージ９０２をＣＳＣＦ６へ送信し、ＣＳＣＦ６はSIP PUBLISHメッセージ９０２をＩＭＳゲートウェイ４の認証／セッション管理機能３０６へ送信する。ＩＭＳゲートウェイ４は、受信したSIP PUBLISHメッセージ９０２のアクセプト−コンタクトヘッダにアプリケーションＩＤもＩＣＳＩも欠如していることに気づき、そのためトラフィックテーブル５２０を調べずに、むしろアプリケーション識別テーブル５００を調べて、デフォルトＵＲＬを有するアプリケーションをテーブル５００から取る。認証／セッション管理機能３０６はメッセージ９０４を送信し、ＩＧ−ＩＴＦサーバ３０４への第三者通知を呼び出す。そして、ＩＧ−ＩＴＦサーバ３０４はメッセージ９０６を送信し、テーブル５００から得られるデフォルトＵＲＬを含む第三者通知を呼び出す。ＩＴＦ２はメッセージ９０６を受信し、第三者通知処理部４２０はアプリケーションＩＤを確認せず、その代わり、供給されたＵＲＬを使用して、ＤＡＥアプリケーションを取得して、ネットワークサーバ８へ送信されるHTTP Get URLメッセージ９０８に示すように、この要求を処理する。ネットワークサーバ８は、ＩＴＦ２に対して、ＤＡＥデフォルトアプリケーションハンドラ（典型的にはいくつかの拡張可能ハイパーテキストマークアップ言語（XHTML：extensible hyper text markup language）命令とEcmaスクリプト命令とを含む）を含む200 OKメッセージ９１０で応答する。そして、ＩＧ−ＩＴＦサーバ３０４から認証／セッション管理機能３０６にオペレーション結果メッセージ９１２が送信される。そして、認証／セッション管理機能３０６は200 OKメッセージ９１４をＣＳＣＦ６へ送信し、ＣＳＣＦ６は200 OKメッセージ９１６をＰ２Ｐ通信イネーブラ１２へ送信する。

上述のシステムおよび方法を使用する実施形態例によれば、ＩＭＳゲートウェイ４は、ＩＴＦ２との複数のＴＣＰリンクの損失のような様々なエラーに対してエラーリカバリを行う能力を有するものとすることができる。この場合、複数のアプリケーションインスタンスがＩＴＦ２において目下アクティブであり、各アプリケーションインスタンスは、ＩＭＳゲートウェイ４との通信に対して、異なるＴＣＰリンクをアップさせるであろう。ＴＣＰリンクは、アプリケーションインスタンスがアップし、動作している限り、アップしているであろう。ＴＣＰリンクがダウンすると、ＩＭＳゲートウェイ４はＴＣＰリンクの損失を検出し、設定可能タイマに基づいて、ＩＭＳゲートウェイ４がトラフィックテーブル５２０において適当な項目５２２、５２４、５２６を更新できる新たなリンクをアプリケーションインスタンスが再確立するまで、例えば約４０〜６０秒間、待機する。

実施形態によれば、ＴＣＰリンクの再確立に関するタイマが満了すると、ＩＭＳゲートウェイ４は、アプリケーションインスタンスが終了したと想定し、対応するネットワーク側通信の終了およびトラフィックテーブル５２０からの項目５２２、５２４、または５２６の削除に進行する。アプリケーションインスタンスが終了していなければ、ＩＭＳゲートウェイ４は、典型的に、ＴＣＰリンク再確立の一部としてSIP UPDATEと等しいものをＩＭＳゲートウェイ４のピアへ送信する。これにより、ＳＩＰ状態情報は変更されず、ＩＭＳゲートウェイ４が、リンク不具合が複数ある場合のエラーリカバリを処理できる。同一アプリケーションの複数のインスタンスに複数のリンク不具合があるこの場合では、ＩＭＳゲートウェイ４は、トラフィックテーブル５２０に記憶された状態情報と関連してSIP UPDATEメッセージの情報を使用して、意図されたアプリケーションインスタンスを一意に識別して、エラーリカバリを成功させることができる。

上述の実施形態例は、人対人の通信に関するメッセージおよびプロトコルを与える。ＩＭＳゲートウェイ４の機能を行うことが可能な通信ノード例１０００について、図１０を参照しながら説明する。通信ノード１０００は、処理部１００２（または複数の処理コア）と、記憶部１００４と、１または２以上の２次格納装置１００６と、インタフェース１００８とを有するものとして、通信ノード１０００と他のネットワークおよび装置との間の通信を容易にすることができる。記憶部１００４および／または２次格納装置１００６を使用して、状態情報とテーブル５００および５２０とを記憶することができる。ロジックおよびプロトコルも、通信ノード１０００内に記憶し、処理部１００２が通知の種類を決定するために、またＩＭＳゲートウェイ４がその他すべての上述した機能例を行うために使用することが可能である。

実施形態例に係る上述のシステム例を使用して、異なるプロトコルを使用する装置間の通信を容易にする方法を、図１１のフローチャートに示す。まず、インターネットマルチメディアサブシステム（ＩＭＳ）ネットワークと非ＩＭＳノードとの間でアプリケーション情報を相関させる方法が、ゲートウェイにおいて、ステップ１１０２において第１の信号伝達プロトコルを使用して、ＩＭＳネットワークから第１のメッセージを受信すること；ステップ１１０４において第１のメッセージから情報を読み出すこと；ステップ１１０６において、この情報を、以前に記憶された情報と相関させて、非ＩＭＳノードで動作する複数のアプリケーションのうちのいずれが第１のメッセージに関連しているかを判定すること；ステップ１１８において、第１の信号伝達プロトコルとは異なる第２の信号伝達プロトコルを使用して、非ＩＭＳノードで動作する複数のアプリケーションのうちの、第１のメッセージに関連しているものに関する情報を含む第２のメッセージを、非ＩＭＳノードへ送信すること；を含む。

当業者によって了解されるように、図１１に示すような方法は、ソフトウェアで全体的または部分的に実施することが可能である。したがって、本発明の実施形態例にしたがってデータを処理するシステムおよび方法は、記憶装置に含まれた命令のシーケンスを実行する１または２以上の処理部によって実行することが可能である。このような命令は、固定媒体、リムーバブル媒体、またはリモート媒体（ネットワーク格納部）とすることができる２次データ格納装置１００６などの他のコンピュータ読出可能媒体から記憶装置１００４へ読み出すものとすることも可能である。記憶装置に含まれた命令のシーケンスの実行は、例えば上述のように処理部に動作させる。代替の実施形態では、有線回路を、ソフトウェア命令の代わりに、またはソフトウェアと組み合わせて、実施形態例を実施することが可能である。

上述の実施形態例は、本発明の全ての点において例示的なものとしたつもりであり、限定的なものとするつもりはない。かかる変更点や修正点はすべて、特許請求の範囲に記載の本発明の範囲および意図の内であると考えられるものである。例えば、１つの家庭で複数のＩＴＦ２がＩＭＳゲートウェイ４と通信しているものとすることも可能であり、この場合でも、ＩＭＳゲートウェイ４は、例えばテーブル５００および５２０に追加情報を記憶しておいてＩＴＦで動作しているアプリケーションを参照することなどによって、通信中のＩＴＦ２におけるアプリケーションを一意に識別可能である。加えて、上述のサービス例は純粋に例示的なものであり、他のＩＭＳサービスは上述のシステムおよび方法によって支援可能である。本願明細書において使用した構成、動作、または命令は、明示的な記載がない限り、本発明に対して決定的または本質的なものとして解釈すべきものではない。また、ここで使用した冠詞「ａ」は１または２以上の項目を含むものと意図している。

Claims (33)

1. インターネットプロトコル（ＩＰ）マルチメディアサブシステム（ＩＭＳ）ネットワークと非ＩＭＳノードとの間でアプリケーション情報を相関させる方法であって、
   ゲートウェイにおいて、第１の信号伝達プロトコルを使用する前記ＩＭＳネットワークから第１のメッセージを受信するステップと、
   以前に記憶された情報であって、第１の信号伝達プロトコルを使用するメッセージを複数のアプリケーションの１つに関連させる情報を有する前記第１のメッセージから抽出された情報の相関に基づいて、前記非ＩＭＳノードで動作する複数のアプリケーションのうちの１つに、受信された前記第１のメッセージを関連させるステップと、
   前記非ＩＭＳノードで動作する複数のアプリケーションのうちの、前記第１のメッセージに関連している１つに関連する情報を含む、前記第１の信号伝達プロトコルとは異なる第２の信号伝達プロトコルを使用する第２のメッセージを、前記非ＩＭＳノードへ送信するステップと
   を含み、
   前記以前に記憶された情報は、記憶されたＵＲＬと、ＩＣＳＩと、アプリケーションＩＤとを含む、方法。
2. 前記ゲートウェイは、前記非ＩＭＳノードで動作する複数のアプリケーションのうちの、前記第１のメッセージに関連している１つに、ＳＩＰダイアログを使用する、請求項１に記載の方法。
3. 前記非ＩＭＳノードで動作する複数のアプリケーションのうちの、前記第１のメッセージに関連している１つに対する後続メッセージを受信するステップと、
   前記非ＩＭＳノードにセッション中通知メッセージを送信するステップと
   をさらに含む、請求項２に記載の方法。
4. 前記ゲートウェイは、前記非ＩＭＳノードで動作する複数のアプリケーションのうちの、前記第１のメッセージに関連している１つに対して、記憶部に維持された状態を有する、請求項１に記載の方法。
5. 前記ゲートウェイは、前記非ＩＭＳノードで動作する複数のアプリケーションのうちの、前記第１のメッセージに関連している１つに対してステートレスである、請求項１に記載の方法。
6. 前記第１のメッセージは、前記第１のメッセージから抽出される前記情報をコンタクト−アクセプトヘッダに含むセッション開始プロトコル（ＳＩＰ）メッセージである、請求項１に記載の方法。
7. 前記第１のメッセージから抽出される前記情報は、ユニフォームリソースロケータ（ＵＲＬ）とＩＭＳ通信サービス識別子（ＩＣＳＩ）とのうちの少なくとも１つである、請求項６に記載の方法。
8. 前記第２の信号伝達プロトコルはハイパーテキスト転送プロトコル（ＨＴＴＰ）である、請求項１に記載の方法。
9. 前記第２の信号伝達プロトコルを使用して、アプリケーションＩＤを含む第２のメッセージを前記非ＩＭＳノードから受信するステップであって、前記第２のメッセージはＨＴＴＰ要求メッセージであるステップをさらに含む、請求項１に記載の方法。
10. 前記複数のアプリケーションのうちの１つの各インスタンスは一意に識別される、請求項１に記載の方法。
11. 前記一意の識別は、トランスミッションコントロールプロトコル（ＴＣＰ）のハッシングとのアプリケーションＩＤの連結から作成される、請求項１０に記載の方法。
12. ＳＩＰダイアログが維持されることを要求する第１のアプリケーションから発信されたメッセージを受信することと、ＳＩＰダイアログが維持されることを要求する第２のアプリケーションに関連するＳＩＰメッセージを受信することとのうちの少なくとも１つによって、テーブルに項目が作成される、請求項１０に記載の方法。
13. 前記第１のメッセージを受信した後にＳＩＰダイアログを確立するステップと、
    前記ＳＩＰダイアログと前記アプリケーションとをリンクさせる追加情報を記憶するステップと、
    前記アプリケーションに関連する、前記ＩＭＳネットワークからの後続受信メッセージに対して、記憶された前記追加情報に基づいてセッション中通知を使用するステップと
    をさらに含む、請求項１に記載の方法。
14. 前記アプリケーションの開始後に前記非ＩＭＳノードとのトランスミッションコントロールプロトコル（ＴＣＰ）接続を確立するステップと、
    前記アプリケーションが終了された後に前記非ＩＭＳノードとの前記ＴＣＰ接続を終了するステップと
    をさらに含む、請求項１に記載の方法。
15. 前記非ＩＭＳノードはインターネットプロトコルテレビジョン端末機能（ＩＴＦ）である、請求項１に記載の方法。
16. 前記アプリケーションは、分散型アプリケーション環境（ＤＡＥ）アプリケーションと埋込ＩＴＦアプリケーションとのうちの少なくとも１つである、請求項１に記載の方法。
17. メッセージを送受信する通信インタフェースであって、第１の信号伝達プロトコルを使用する第１のメッセージが、アプリケーションに関連する情報を含む、通信インタフェースと、
    アプリケーションＩＤと、ユニフォームリソースロケータ（ＵＲＬ）と、デフォルト情報と、ＩＭＳ通信サービス識別子（ＩＣＳＩ）とを含む情報を記憶する記憶部と、
    前記第１の信号伝達プロトコルを使用する前記第１のメッセージと、前記記憶部に記憶されたアプリケーションＩＤと、ユニフォームリソースロケータ（ＵＲＬ）と、デフォルト情報と、ＩＭＳ通信サービス識別子（ＩＣＳＩ）とを含む前記情報とを相関させ、前記第１の信号伝達プロトコルとは異なる第２の信号伝達プロトコルを使用する第２のメッセージのルーティング先の複数のアプリケーションのうちの１つと前記メッセージを関連させる処理部であって、前記第２の信号伝達プロトコルを使用する前記第２のメッセージは、前記アプリケーションに関連する情報を含む、処理部と
    を備えるゲートウェイ装置。
18. 前記ゲートウェイは、非ＩＭＳノードで動作する複数のアプリケーションのうちの、前記第１のメッセージに関連している１つに、ＳＩＰダイアログを使用する、請求項１７に記載のゲートウェイ装置。
19. 前記通信インタフェースにおいて、前記非ＩＭＳノードで動作する複数のアプリケーションのうちの、前記第１のメッセージに関連している１つに対する後続メッセージを受信し、前記非ＩＭＳノードにセッション中通知メッセージを送信することをさらに含む、請求項１８に記載のゲートウェイ装置。
20. 前記ゲートウェイは、非ＩＭＳノードで動作する複数のアプリケーションのうちの、前記第１のメッセージに関連している１つに対して、記憶部に維持された状態を有する、請求項１７に記載のゲートウェイ装置。
21. 前記ゲートウェイは、非ＩＭＳノードで動作する複数のアプリケーションのうちの、前記第１のメッセージに関連している１つに対してステートレスである、請求項１７に記載のゲートウェイ装置。
22. 前記第１のメッセージは、前記アプリケーションに関連する情報をコンタクト−アクセプトヘッダに含むセッション開始プロトコル（ＳＩＰ）メッセージである、請求項１７に記載のゲートウェイ装置。
23. 前記アプリケーションに関連する情報は、ユニフォームリソースロケータ（ＵＲＬ）とＩＣＳＩとのうちの少なくとも１つである、請求項１７に記載のゲートウェイ装置。
24. 前記第２の信号伝達プロトコルはハイパーテキスト転送プロトコル（ＨＴＴＰ）である、請求項１７に記載のゲートウェイ装置。
25. 前記通信インタフェースにおいて、アプリケーションＩＤを含む、前記第２の信号伝達プロトコルを使用する第２のメッセージを、非ＩＭＳノードから受信することをさらに含み、前記第２のメッセージはＨＴＴＰ要求メッセージである、請求項１７に記載のゲートウェイ装置。
26. ＵＲＬと、ＩＣＳＩと、アプリケーションＩＤとを含む以前に前記記憶部に記憶された情報を記憶する、事前設定テーブルをさらに備える、請求項１７に記載のゲートウェイ装置。
27. 前記アプリケーションの各インスタンスは、前記記憶部において一意に識別される、請求項１７に記載のゲートウェイ装置。
28. 前記一意の識別は、トランスミッションコントロールプロトコル（ＴＣＰ）のハッシングとのアプリケーションＩＤの連結から作成される、請求項２７に記載のゲートウェイ装置。
29. ＳＩＰダイアログが維持されることを要求する第１のアプリケーションから発信されたメッセージを受信することと、ＳＩＰダイアログが維持されることを要求する第２のアプリケーションに関連するＳＩＰメッセージを受信することとのうちの少なくとも１つによって、テーブルに項目が作成される、請求項２７に記載のゲートウェイ装置。
30. 前記第１のメッセージを受信した後にＳＩＰダイアログを確立する前記ゲートウェイと、
    前記ＳＩＰダイアログと前記アプリケーションとをリンクさせる追加情報を記憶する前記記憶部とを備え、
    前記ゲートウェイは、前記アプリケーションに関連する、ＩＭＳネットワークからの後続受信メッセージに対して、記憶された前記追加情報に基づいてセッション中通知を使用する、請求項１７に記載のゲートウェイ装置。
31. 前記ゲートウェイは、前記アプリケーションの開始後に非ＩＭＳノードとのトランスミッションコントロールプロトコル（ＴＣＰ）接続を確立し、前記アプリケーションが終了された後に前記非ＩＭＳノードとの前記ＴＣＰ接続を終了する、請求項１７に記載のゲートウェイ装置。
32. 非ＩＭＳノードはインターネットプロトコルテレビジョン端末機能（ＩＴＦ）である、請求項１７に記載のゲートウェイ装置。
33. 前記アプリケーションは、分散型アプリケーション環境（ＤＡＥ）アプリケーションと埋込ＩＴＦアプリケーションとのうちの少なくとも１つである、請求項１７に記載のゲートウェイ装置。

Images