JP2008236130A - 通信を確立してメッセージを中継する装置、通信を確立する方法およびプログラム - Google Patents

Abstract

【課題】メッセージ配送時の遅延を削減する中継装置を提供すること。
【解決手段】ＳＩＰ端末を識別する第１識別情報と、ＳＩＰ端末から送信されたメッセージの転送先として予測される他のＳＩＰ端末を識別する第２識別情報とを対応づけて記憶する記憶部１２０と、他のＳＩＰ端末に転送する転送メッセージの前に受信され、通信に関する処理要求と第１識別情報とを含む要求メッセージをＳＩＰ端末から受信する送受信部１０１と、受信した要求メッセージに含まれる第１識別情報に対応する第２識別情報を記憶部１２０から取得する取得部１０４と、取得した第２識別情報の他のＳＩＰ端末との間で通信を確立するコネクション確立部１０３とを備えた。
【選択図】 図２

Description

この発明は、通信を確立し、確立した通信によってメッセージを中継する装置、通信を確立する方法およびプログラムに関するものである。

近年、通信装置間に介在し通信を制御・中継するシグナリングプロトコルとしてＳＩＰ（Session Initiation Protocol）が広く知られている。ＳＩＰを用いた通信システム（ＳＩＰシステム）では、端末装置であるＳＩＰ端末間の通信仲介サーバ装置としてＳＩＰプロキシが用いられ、ＳＩＰ端末とＳＩＰプロキシ間を接続するトランスポートプロトコルとして、ＴＬＳ（Transport Layer Security）プロトコルを用いてセキュリティを確保する方法が一般的である。なお、ＳＩＰ端末およびＳＩＰプロキシを合わせてＳＩＰエンティティと呼ぶ。

ＴＬＳはコネクション指向のセキュアトランスポートプロトコルであり、ＴＬＳを用いてＳＩＰメッセージの配送を行なうためには、ＳＩＰエンティティ間で、ＴＬＳハンドシェイクを実行してコネクションを確立する必要がある。非特許文献１には、ＳＩＰメッセージのセキュアな配送のためのトランスポートプロトコルとして、ＴＬＳを利用することが示されている。

ここで、ＳＩＰプロキシＢが、ＳＩＰメッセージを送信するＳＩＰ端末ＡからＳＩＰメッセージを受信し、宛先であるＳＩＰ端末Ｃに対してＳＩＰメッセージを配送するまでの処理の概要を以下に説明する。

まず、ＳＩＰ端末Ａは、ＳＩＰプロキシＢとの間でＴＬＳのハンドシェイクプロトコルを実行する。これにより、ＳＩＰ端末ＡとＳＩＰプロキシＢとの間で、セキュアなコネクションが確立される。次に、ＳＩＰ端末Ａは、確立したセキュアコネクションを利用して、ＴＬＳにより暗号化されたＳＩＰメッセージをＳＩＰプロキシＢに送信する。

ＳＩＰプロキシＢはこれを受信し、ＴＬＳ復号化してＳＩＰメッセージを取り出す。ＳＩＰプロキシＢは、ＳＩＰヘッダに含まれるＲｅｑｕｅｓｔ-ＵＲＩを参照し、受信したＳＩＰメッセージの配送先を判断する。このために、例えばＳＩＰロケーションサーバに問い合わせることなどを行ってもよい。ＳＩＰプロキシＢは、ＳＩＰメッセージの配送先であるＳＩＰ端末Ｃとの間で、ＴＬＳのハンドシェイクプロトコルを実行する。これにより、ＳＩＰプロキシＢとＳＩＰ端末Ｃとの間で、セキュアなコネクションが確立される。

次に、ＳＩＰプロキシＢは、確立したセキュアコネクションを利用して、ＴＬＳにより暗号化したＳＩＰメッセージをＳＩＰ端末Ｃに送信する。ＳＩＰ端末Ｃは、ＳＩＰプロキシＢとの間で確立されたＴＬＳコネクションを利用して、ＳＩＰレスポンスメッセージを送信し、ＳＩＰプロキシＢは、ＳＩＰ端末Ａとの間で確立されたＴＬＳコネクションを利用して、受信したＳＩＰレスポンスメッセージを配送する。

このように、ＳＩＰプロキシＢがＳＩＰメッセージを配送するためには、各ＳＩＰ端末との間でハンドシェイクプロトコルを実行してコネクションを確立する必要がある。ハンドシェイクプロトコルでは複数のメッセージが相互に送受信されるため、ＴＬＳコネクション確立処理は一定の時間を要する処理となる。

また、一般にＳＩＰプロキシは、ＳＩＰメッセージを受信してそのＳＩＰヘッダ（一般にはＲｅｑｕｅｓｔ-ＵＲＩ）を参照するまで、そのＳＩＰメッセージを配送する先であるＳＩＰ端末を特定することができない。このため、ＳＩＰメッセージを受信して配送先を特定した後に、配送先ＳＩＰ端末に対してＴＬＳコネクションを確立してＳＩＰメッセージを配送する必要がある。

J. Rosenberg et al.、 "RFC 3261、 SIP: Session Initiation Protocol"、 [online]、June 2002、 retrieved from the Internet: <URL: http://www.ietf.org/rfc/rfc3261.txt>

しかしながら、非特許文献１などの従来の方法では、ＳＩＰメッセージを受信して配送先を特定した後に、ＴＬＳコネクションの確立処理を開始するため、ＳＩＰメッセージの配送完了までに要する時間遅延が増大するという問題があった。

なお、ＴＬＳコネクションは、ＳＩＰメッセージの送信の際に毎回行なう必要があるものではなく、確立済みのＴＬＳコネクションを維持してＳＩＰメッセージの配送に利用することも可能である。しかし、複数のＴＬＳコネクションを維持することは、ＳＩＰプロキシの記憶容量およびＣＰＵ（Central Processing Unit）負荷を圧迫するため望ましくない。したがって、通常は、ＳＩＰ ＩＮＶＩＴＥリクエストメッセージの送信に際して、ＳＩＰトランザクション毎に新しいＴＬＳコネクションを確立する場合が多い。

本発明は、上記に鑑みてなされたものであって、中継装置がメッセージ配送のため実行する通信確立処理により生じるメッセージ配送時の遅延を削減することができる装置、方法およびプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、端末装置との間で通信を確立し、前記端末装置間で送受信されるメッセージを、確立した通信によって中継する中継装置であって、前記端末装置を識別する第１識別情報と、前記端末装置から送信されたメッセージの転送先として予測される他の端末装置を識別する第２識別情報とを対応づけて記憶する記憶部と、前記他の端末装置に転送する転送メッセージの前に受信され、通信に関する処理要求と前記第１識別情報とを含む要求メッセージを前記端末装置から受信する受信部と、受信した前記要求メッセージに含まれる前記第１識別情報に対応する前記第２識別情報を前記記憶部から取得する取得部と、取得した前記第２識別情報の前記他の端末装置との間で通信を確立する確立部と、を備えたことを特徴とする。

また、本発明は、端末装置との間で通信を確立し、前記端末装置間で送受信されるメッセージを、確立した通信によって中継する中継装置における通信確立方法であって、受信部によって、他の端末装置に転送する転送メッセージの前に受信され、通信に関する処理要求と前記端末装置を識別する第１識別情報とを含む要求メッセージを前記端末装置から受信する受信ステップと、取得部によって、前記第１識別情報と、前記端末装置から送信されたメッセージの転送先として予測される前記他の端末装置を識別する第２識別情報とを対応づけて記憶する記憶部から、受信した前記要求メッセージに含まれる前記第１識別情報に対応する前記第２識別情報を取得する取得ステップと、確立部によって、取得した前記第２識別情報の前記他の端末装置との間で通信を確立する確立ステップと、を備えたことを特徴とする。

また、本発明は、上記方法を実行することができるプログラムである。

本発明によれば、中継装置がメッセージ配送のため実行する通信確立処理により生じるメッセージ配送時の遅延を削減することができるという効果を奏する。

以下に添付図面を参照して、この発明にかかるメッセージを中継する装置、通信を確立する方法およびプログラムの最良な実施の形態を詳細に説明する。

（第１の実施の形態）
第１の実施の形態にかかる中継装置は、ＴＬＳコネクションに関する情報と、配送先ＳＩＰエンティティとを対応づけて記憶し、ＴＬＳコネクションの確立要求を受付けたときに記憶した情報を参照して配送先ＳＩＰエンティティを予測し、当該ＳＩＰエンティティとの間のＴＬＳコネクションの確立を事前に実行するものである。

図１は、第１の実施の形態にかかる通信システムのネットワーク構成を示すブロック図である。図１に示すように、本実施の形態の通信システムは、ＳＩＰプロキシ１００と、複数のＳＩＰ端末２００ａ、２００ｂ、２００ｃとが、ルータ３００を介して接続された構成となっている。

ＳＩＰプロキシ１００は、ＳＩＰ端末２００間のＳＩＰメッセージを中継する中継装置である。ＳＩＰプロキシ１００は、ＴＬＳプロトコルによってＴＬＳコネクションを確立し、ＴＬＳコネクションによってＳＩＰメッセージを中継する。ＳＩＰプロキシ１００の構成の詳細については後述する。

ＳＩＰ端末２００ａ、２００ｂ、２００ｃは、シグナリングプロトコルとしてＳＩＰを使用し、ＳＩＰのＵＡ（User Agent）機能を備えた端末装置である。なお、ＳＩＰ端末２００ａ、２００ｂ、２００ｃは同様の構成を有するため、以下では、単にＳＩＰ端末２００という場合がある。なお、接続されるＳＩＰ端末２００の個数は３つに限られるものではない。ＳＩＰ端末２００の構成の詳細については後述する。

ルータ３００は、ＳＩＰ端末２００およびＳＩＰプロキシ１００との間でＩＰパケットを転送するものであり、ＩＰルータ／スイッチなどの従来から用いられている装置により構成することができる。

次に、ＳＩＰプロキシ１００の構成の詳細について説明する。図２は、第１の実施の形態にかかるＳＩＰプロキシ１００の構成を示すブロック図である。図２に示すように、ＳＩＰプロキシ１００は、記憶部１２０と、送受信部１０１と、メッセージ処理部１０２と、コネクション確立部１０３と、取得部１０４とを備えている。

記憶部１２０は、メッセージを中継する処理で用いる各種情報を記憶するものであり、コネクション管理テーブル１２１と、予測テーブル１２２とを格納している。

コネクション管理テーブル１２１は、後述するコネクション確立部１０３が確立したコネクションに関する情報を格納するテーブルである。図３は、コネクション管理テーブル１２１のデータ構造の詳細を示す説明図である。

図３に示すように、コネクション管理テーブル１２１は、コネクションを識別するＴＬＳコネクションＩＤと、受け付けＴＬＳコネクションアドレス／ポートと、ＴＬＳコネクションの接続元となるＳＩＰプロキシ１００のポートを表す接続元ポート、暗号アルゴリズムＩＤ、暗号パラメータとを対応づけて保持している。

受け付けＴＬＳコネクションアドレス／ポートには、ＴＬＳコネクションの確立要求の受け付け元であるＳＩＰ端末２００を識別する識別情報として、ＳＩＰ端末２００のＩＰアドレスおよびポート番号が設定される。なお、ポート番号は必須ではなく、識別情報としてＩＰアドレスのみを設定するように構成してもよい。

また、暗号アルゴリズムＩＤとは、送信データを暗号化する、または受信データを復号化するための暗号アルゴリズムを識別する情報を表す。また、暗号パラメータとは、確立したＴＬＳコネクションに関連する暗号化のためのパラメータを表す。

なお、記憶部１２０は、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。

図２に戻り、予測テーブル１２２は、転送するＳＩＰメッセージの転送先となるＳＩＰ端末２００を特定するための情報を格納するテーブルである。図４は、第１の実施の形態の予測テーブル１２２のデータ構造の詳細を示す説明図である。

図４に示すように、予測テーブル１２２は、受け付けＴＬＳコネクションアドレス／ポートと、予測ＳＩＰメッセージ転送先とを対応づけて格納している。予測ＳＩＰメッセージ転送先には、ＳＩＰメッセージの転送先として予測されるＳＩＰ端末２００を識別する識別情報（ＩＰアドレスとポート番号）が設定される。

予測テーブル１２２は、ＴＬＳコネクションの確立要求を受信したときに、要求元のＳＩＰ端末２００に対応するＳＩＰメッセージ転送先を予測するために、取得部１０４によって参照される。なお、予測テーブル１２２に格納する情報は、事前に求めた値を設定するように構成してもよいし、過去に転送したＳＩＰメッセージから統計的に推測するように構成してもよい。統計的に推測する場合は、例えば、過去に転送したＳＩＰメッセージの転送先として最も多いＳＩＰ端末２００を設定するように構成することができる。また、一つの受付ＴＬＳコネクションアドレス／ポートに対応して、複数の予測ＳＩＰメッセージ転送先とを対応付けて格納するように構成することもできる。

図２に戻り、送受信部１０１は、外部の装置との間でメッセージの送受信を行うものである。例えば、送受信部１０１は、ＳＩＰメッセージを送信するとき、メッセージ処理部１０２からＳＩＰメッセージデータを受信し、コネクション確立部１０３に対して、ＳＩＰメッセージの送信に利用するＴＬＳコネクションの確立を依頼する。既に利用可能なＴＬＳコネクションが存在し、コネクション確立部１０３で管理されている場合は、送受信部１０１は、そのコネクションに関する情報をコネクション確立部１０３から取得する。そして、送受信部１０１は、ＴＬＳコネクションに関連づけられた暗号パラメータによってＳＩＰメッセージを暗号化した後、ＳＩＰメッセージをネットワークへと送信する。

また、送受信部１０１は、ＳＩＰメッセージを受信したときは、コネクション確立部１０３を利用して、受信したＴＬＳコネクションに関連づけられた暗号パラメータを特定し、特定した暗号パラメータによって受信したＳＩＰメッセージを復号する。そして、送受信部１０１は、復号したＳＩＰメッセージデータをメッセージ処理部１０２へと転送する。

メッセージ処理部１０２は、非特許文献１などに示されるＳＩＰの基本仕様にしたがって、ＳＩＰプロキシ１００の基本的な機能であるＳＩＰメッセージの配送のための各種処理を行うものである。例えば、メッセージ処理部１０２は、ＳＩＰメッセージデータを送受信部１０１から受けとり、受信したＳＩＰメッセージの解釈および送信するＳＩＰメッセージの組み立てを行い、送信するＳＩＰメッセージデータを送受信部１０１に転送する。

メッセージ処理部１０２は、ＳＩＰメッセージデータの組み立てを行う際、必要に応じて、ＳＩＰプロキシ１００の内部またはネットワーク上に存在するＳＩＰロケーションサーバ（図示せず）などを参照して送信先を決定するように構成してもよい。

コネクション確立部１０３は、他の構成部からの要求に応じてＴＬＳコネクションを確立するものである。また、コネクション確立部１０３は、他の構成部からの要求に応じて確立済みのＴＬＳコネクションを破棄する処理を行う。

例えば、コネクション確立部１０３は、ＴＬＳハンドシェイクプロトコルを実行するとともに、ＴＬＳハンドシェイクで求められたＴＬＳの暗号化や復号化のための暗号パラメータをコネクション管理テーブル１２１に記憶する。また、コネクション確立部１０３は、ＴＬＳコネクションを破棄する場合は、コネクション管理テーブル１２１から該当するエントリを削除する。さらに、ＴＬＳコネクションの確立要求の受け付け元であるＳＩＰ端末２００のＩＰアドレスおよびポート番号を通知された場合は、コネクション確立部１０３は、コネクション管理テーブル１２１を参照して、対応する暗号アルゴリズムＩＤと暗号パラメータとを特定する。

取得部１０４は、送受信部１０１から、受信したメッセージに含まれる送信元のＳＩＰ端末２００のアドレス情報を受け取り、受け取ったアドレス情報に対応する予測ＳＩＰメッセージ転送先を予測テーブル１２２から取得するものである。このようにして、以降転送するＳＩＰメッセージの転送先として予測されるＳＩＰ端末２００のアドレスが取得できる。また、取得部１０４は、転送先として予測されたＳＩＰ端末２００に対するＴＬＳコネクションの確立要求を、コネクション確立部１０３に通知する。

次に、ＳＩＰ端末２００の構成の詳細について説明する。図５は、第１の実施の形態にかかるＳＩＰ端末２００の構成を示すブロック図である。図５に示すように、ＳＩＰ端末２００は、送受信部２０１と、メッセージ処理部２０２と、コネクション確立部２０３と、アプリケーション２０４とを備えている。

送受信部２０１は、外部の装置との間でメッセージの送受信を行うものである。例えば、送受信部２０１は、ＳＩＰメッセージを送信するとき、メッセージ処理部２０２からＳＩＰメッセージデータを受信し、後述するコネクション確立部２０３に対して、ＳＩＰメッセージの送信に利用するＴＬＳコネクションの確立を依頼する。既に利用可能なＴＬＳコネクションが存在し、コネクション確立部２０３で管理されている場合は、送受信部２０１は、そのコネクションに関する情報をコネクション確立部２０３から取得する。そして、送受信部２０１は、ＴＬＳコネクションに関連づけられた暗号パラメータによってＳＩＰメッセージを暗号化した後、ＳＩＰメッセージをネットワークへと送信する。

また、送受信部２０１は、ＳＩＰメッセージを受信したときは、コネクション確立部２０３を利用して受信したＴＬＳコネクションに関連づけられた暗号パラメータを特定し、特定した暗号パラメータによって受信したＳＩＰメッセージを復号する。そして、送受信部２０１は、復号したＳＩＰメッセージデータをメッセージ処理部２０２へと転送する。

メッセージ処理部２０２は、非特許文献１などに示されるＳＩＰ ＵＡ（User Agent）の基本仕様にしたがって、ＳＩＰメッセージを構成して送受信部２０１によって送信する。また、メッセージ処理部２０２は、送受信部２０１から受信したＳＩＰメッセージを解釈する。これらのＳＩＰメッセージの構成および解釈は、後述するアプリケーション２０４の要求に応じて実行される。

コネクション確立部２０３は、ＳＩＰプロキシ１００のコネクション確立部１０３と同様に、ＴＬＳコネクションの確立および破棄に関する処理を行うものである。例えば、コネクション確立部２０３は、ＴＬＳハンドシェイクプロトコルを実行するとともに、ＴＬＳの暗号化や復号化のための暗号パラメータの記憶部（図示せず）に記憶して管理する。なお、コネクション確立部２０３は、図３のコネクション管理テーブル１２１と同様のテーブルによって確立したコネクションに関する情報を管理するが、管理方法はコネクション確立部１０３と同様であるので図示および説明を省略する。

アプリケーション２０４は、ＳＩＰを利用してメッセージを送受信することにより動作する機能を含むアプリケーションである。例えば、ＳＩＰを利用したホットラインシステムの端末側のアプリケーション、インターホンとＴＶモニター付受話器とからなるＳＩＰを利用した通話システムのアプリケーションなどが該当する。なお、このようなアプリケーションであれば、通信相手が特定されるため、本実施の形態の手法により転送先を予測して事前にコネクションを確立しておくことによる配送遅延削減の効果が大きくなる。

次に、このように構成された第１の実施の形態にかかるＳＩＰプロキシ１００による中継処理について図６を用いて説明する。図６は、第１の実施の形態における中継処理の全体の流れを示すフローチャートである。なお、以下では、ＳＩＰ端末２００ａ上のユーザ１が、ＳＩＰ端末２００ｂ上のユーザ２に対してＳＩＰ ＩＮＶＩＴＥリクエストメッセージを送信する場合を例として説明する。

ここで、ＳＩＰプロキシ１００の記憶部の予測テーブルにおいて、端末２００ａのＩＰアドレスを、受け付けＴＬＳコネクションアドレス／ポートとした場合、端末２００ｂのＩＰアドレスおよびＳＩＰの通常ポートが、予測ＳＩＰメッセージ転送先として予測できるよう、情報が格納されているとする。

最初に、ＳＩＰ端末２００ａの送受信部２０１が、ＳＩＰプロキシ１００宛にＴＬＳコネクションの確立を要求するためのＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージを送信する（ステップＳ６０１）。

なお、この処理の前提として、送信先の決定処理およびメッセージ作成処理が以下のような手順で実行される。まず、ＳＩＰ端末２００ａ上のユーザ１がアプリケーション２０４を操作したこと等を契機として、アプリケーション２０４がメッセージ処理部２０２にＳＩＰ ＩＮＶＩＴＥリクエストメッセージの作成を依頼する。そして、メッセージ処理部２０２が、ＳＩＰ仕様にしたがって、ユーザ２に宛てたＳＩＰ ＩＮＶＩＴＥリクエストメッセージを作成し、このメッセージの送信先をＳＩＰプロキシ１００であると決定する。

作成されたメッセージは、送受信部１０１に転送される。送受信部１０１は、コネクション確立部２０３に、ＳＩＰプロキシ１００との間のＴＬＳコネクションの確立を依頼する。ＳＩＰ端末２００ａのコネクション確立部２０３は、ＳＩＰプロキシ１００との間でＴＬＳコネクションを確立するため、ＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージを作成し、送受信部１０１に転送する。

このようにして作成されたＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージが送受信部２０１によってＳＩＰプロキシ１００に送信され（ステップＳ６０１）、ＳＩＰプロキシ１００の送受信部１０１によって受信される。

送受信部１０１は、受信したＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージの送信元ＩＰアドレスおよびポート番号を、取得部１０４に対して通知する。取得部１０４は、予測テーブル１２２を参照し、通知された送信元ＩＰアドレスおよびポート番号に対応する予測ＳＩＰメッセージ転送先を取得する（ステップＳ６０２）。ここでは、ＳＩＰ端末２００ａから受信するＳＩＰメッセージの転送先がＳＩＰ端末２００ｂであると決定される。

このように転送先を予測した後、以下のステップＳ６０３〜ステップＳ６０５で、各ＳＩＰ端末２００との間のＴＬＳコネクションの確立処理が行われる。なお、ステップＳ６０３のＳＩＰプロキシ１００とＳＩＰ端末２００ａとの間のＴＬＳハンドシェイク、およびステップＳ６０４〜ステップＳ６０５のＳＩＰプロキシ１００とＳＩＰ端末２００ｂとの間のＴＬＳハンドシェイクとは、並行して実行される。これにより、コネクション確立処理により生じる遅延時間をより小さくすることができる。

ステップＳ６０３で、ＳＩＰプロキシ１００は、ＳＩＰ端末２００ａとＳＩＰプロキシ１００との間でＴＬＳコネクションを確立するため、ＴＬＳハンドシェイクを実行する（ステップＳ６０３）。

具体的には、ＳＩＰ端末２００ａのコネクション確立部２０３とＳＩＰプロキシ１００のコネクション確立部１０３は、それぞれ送受信部２０１および送受信部１０１によって相互にＴＬＳメッセージを送受信し、ＴＬＳコネクションの確立を行う。なお、ＴＬＳハンドシェイクでは、９つ程度のＴＬＳメッセージの交換処理が実行される。これによって、ＳＩＰ端末２００ａとＳＩＰプロキシ１００との間でＳＩＰメッセージを送受信するための暗号パラメータの合意が行われる。

また、ＳＩＰプロキシ１００の取得部１０４は、コネクション確立部１０３に、ＳＩＰ端末２００ｂとの間のＴＬＳコネクションの確立を依頼する。コネクション確立部１０３は、ＳＩＰ端末２００ｂとの間でＴＬＳコネクションを確立するため、ＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージを作成し、送受信部１０１を介してＳＩＰ端末２００ｂに送信する（ステップＳ６０４）。

ＳＩＰ端末２００ｂの送受信部２０１は、ＳＩＰプロキシ１００からのＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージを受信し、コネクション確立部２０３に通知する。そして、コネクション確立部２０３によって、ＳＩＰプロキシ１００とＳＩＰ端末２００ｂとの間でＴＬＳコネクションを確立するためのＴＬＳハンドシェイクが実行される（ステップＳ６０５）。この処理は、ステップＳ６０３と同様である。これによって、ＳＩＰ端末２００ｂとＳＩＰプロキシ１００との間でＳＩＰメッセージを送受信するための暗号パラメータの合意が行われる。

ステップＳ６０３によってＴＬＳコネクションが確立されると、ＳＩＰ端末２００ａの送受信部１０１は、コネクション確立部２０３が管理している暗号パラメータを利用してＳＩＰ ＩＮＶＩＴＥリクエストメッセージを暗号化し、確立したＴＬＳコネクションを利用して、ＳＩＰプロキシ１００に対して送信する（ステップＳ６０６）。

次に、ＳＩＰプロキシ１００は、以下のような手順により、受信したＳＩＰ ＩＮＶＩＴＥリクエストメッセージをＳＩＰ端末２００ｂに転送する（ステップＳ６０７）。

まず、ＳＩＰプロキシ１００の送受信部１０１は、ＳＩＰ端末２００ａから送信されたＳＩＰ ＩＮＶＩＴＥリクエストメッセージを受信し、コネクション管理テーブル１２１に格納されている暗号パラメータを利用してこれを復号し、メッセージ処理部１０２に転送する。

メッセージ処理部１０２は、受信したＳＩＰメッセージが、ユーザ２宛のＳＩＰ ＩＮＶＩＴＥリクエストメッセージであることを認識する。また、メッセージ処理部１０２は、ＳＩＰヘッダのＲｅｑｕｅｓｔ-ＵＲＩなどを参照し、ユーザ２宛のメッセージの転送先となるＳＩＰ端末２００を決定する。なお、メッセージ処理部１０２は、例えばＳＩＰロケーションサーバ（図示せず）に問い合わせることによって転送先を決定するように構成してもよい。

ユーザ２宛のＳＩＰメッセージの送信先がＳＩＰ端末２００ｂであることを識別すると、メッセージ処理部１０２は、宛先をＳＩＰ端末２００ｂとして、送受信部１０１に対してＳＩＰメッセージデータを転送する。送受信部１０１は、ステップＳ６０５によってＳＩＰ端末２００ｂとの間のＴＬＳコネクションが確立済みであることを確認した後、ＳＩＰメッセージを、コネクション管理テーブル１２１に格納されている暗号パラメータを利用して暗号化し、既に確立しているＳＩＰ端末２００ａとの間のＴＬＳコネクションを利用して、ＳＩＰ端末２００ｂに対して配送する（ステップＳ６０７）。

なお、予測した転送先と実際の転送先が異なる場合は、事前に確立したＴＬＳコネクションを利用できないため、実際の転送先ＳＩＰ端末２００との間でＴＬＳコネクションを確立してからＳＩＰメッセージを暗号化し、転送する必要がある。この場合、本発明によるＳＩＰメッセージ転送の高速化の効果は得られない。

次に、ＳＩＰ端末２００ｂは、以下のような手順により、受信したＳＩＰ ＩＮＶＩＴＥリクエストメッセージに対する応答をＳＩＰプロキシ１００に送信する（ステップＳ６０８）。

まず、ＳＩＰ端末２００ｂの送受信部２０１は、ＳＩＰ ＩＮＶＩＴＥリクエストメッセージを受信し、コネクション確立部２０３が管理している暗号パラメータを利用してこれを復号し、メッセージ処理部２０２に対して転送する。メッセージ処理部２０２は、受信したＳＩＰメッセージを処理し、受信したＳＩＰメッセージがユーザ２宛のＳＩＰ ＩＮＶＩＴＥリクエストメッセージであることを認識する。また、メッセージ処理部２０２は、ＳＩＰ端末２００ｂのアプリケーション２０４に対して、ユーザ２宛のＳＩＰメッセージを通知する。なお、アプリケーション２０４は、その機能にしたがい、例えば、ユーザ２を呼び出す処理を行う。

アプリケーション２０４によってユーザ２が応答したとすると、メッセージ処理部２０２は、ＳＩＰ端末２００ａを宛先とする２００ ＯＫレスポンスメッセージを作成する。送受信部２０１は作成されたメッセージを、コネクション確立部２０３が管理している暗号パラメータを利用して暗号化し、既に確立しているＳＩＰプロキシ１００との間のＴＬＳコネクションを利用して、ＳＩＰプロキシ１００に対して配送する（ステップＳ６０８）。

次に、ＳＩＰプロキシ１００は、以下のような手順により、受信した２００ ＯＫレスポンスメッセージをＳＩＰ端末２００ａに転送する（ステップＳ６０９）。

まず、ＳＩＰプロキシ１００の送受信部１０１は、２００ ＯＫレスポンスメッセージを受信し、コネクション管理テーブル１２１に格納されている暗号パラメータを利用してこれを復号し、メッセージ処理部１０２に転送する。

メッセージ処理部１０２は、受信したＳＩＰメッセージが、ユーザ１宛の２００ ＯＫレスポンスメッセージであることを認識し、ＳＩＰ端末２００ａ宛てに転送するために送受信部１０１に転送する。送受信部１０１は、２００ ＯＫレスポンスメッセージをコネクション管理テーブル１２１に格納されている暗号パラメータを利用して暗号化し、既に確立しているＳＩＰ端末２００ａとの間のＴＬＳコネクションを利用して、ＳＩＰ端末２００ａに対して配送する（ステップＳ６０９）。

次に、ＳＩＰ端末２００ａは、以下のような手順により、受信した２００ ＯＫレスポンスメッセージに対する応答をＳＩＰプロキシ１００に送信する（ステップＳ６１０）。

まず、ＳＩＰ端末２００ａの送受信部２０１は、２００ ＯＫレスポンスメッセージを受信し、コネクション確立部２０３が管理している暗号パラメータを利用してこれを復号し、メッセージ処理部２０２に対して転送する。メッセージ処理部２０２は、受信したレスポンスメッセージが、ユーザ２宛のＳＩＰ ＩＮＶＩＴＥリクエストメッセージに対するレスポンスメッセージであることを認識する。ここでアプリケーション２０４は、ユーザ１に対して通知を行ってもよい。

ＳＩＰ端末２００ａのメッセージ処理部２０２は、ＳＩＰ端末２００ｂに宛てたＳＩＰ ＡＣＫリクエストメッセージを作成する。送受信部２０１は作成されたメッセージを、コネクション確立部２０３に格納されている暗号パラメータを利用して暗号化し、既に確立しているＳＩＰプロキシ１００との間のＴＬＳコネクションを利用して、ＳＩＰプロキシ１００に対して配送する（ステップＳ６１０）。

次に、ＳＩＰプロキシ１００は、以下のような手順により、受信したＳＩＰ ＡＣＫリクエストメッセージをＳＩＰ端末２００ｂに転送する（ステップＳ６１１）。

まず、ＳＩＰプロキシ１００の送受信部１０１は、ＳＩＰ端末２００ａから送信されたＳＩＰ ＡＣＫリクエストメッセージを受信し、コネクション管理テーブル１２１に格納されている暗号パラメータを利用してこれを復号し、メッセージ処理部１０２に対して転送する。

メッセージ処理部１０２は、受信したＳＩＰメッセージが、ユーザ２宛のＳＩＰ ＡＣＫリクエストメッセージであることを認識する。また、メッセージ処理部１０２は、ＳＩＰヘッダのＲｅｑｕｅｓｔ-ＵＲＩなどを参照し、ユーザ２宛のメッセージの転送先となるＳＩＰ端末２００を決定する。

ユーザ２宛のメッセージの送信先がＳＩＰ端末２００ｂであることを識別すると、メッセージ処理部１０２は、宛先をＳＩＰ端末２００ｂとして、送受信部１０１に対してＳＩＰメッセージデータを転送する。送受信部１０１は、ＳＩＰメッセージをコネクション管理テーブル１２１に格納されている暗号パラメータを利用して暗号化し、既に確立しているＳＩＰ端末２００ａとの間のＴＬＳコネクションを利用して、ＳＩＰ端末２００ｂに対して配送する（ステップＳ６１１）。

次に、ＳＩＰ端末２００ｂは、以下のような手順により、受信したＳＩＰ ＡＣＫリクエストメッセージを処理する（ステップＳ６１２）。

まず、ＳＩＰ端末２００ｂの送受信部１０１は、ＳＩＰ ＡＣＫリクエストメッセージを受信し、コネクション確立部２０３が管理している暗号パラメータを利用してこれを復号し、メッセージ処理部２０２に対して転送する。メッセージ処理部２０２は、受信したメッセージが、ユーザ２宛のＳＩＰ ＡＣＫリクエストメッセージであることを認識する。ここでアプリケーション２０４は、ユーザ２に対して通知を行ってもよい。

このように、本実施の形態によれば、ＴＬＳコネクションの確立要求（ＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージ）を受信した時点で、後で受信するＳＩＰメッセージ（ＳＩＰ ＩＮＶＩＴＥリクエストメッセージ）の転送先を予測して事前にＴＬＳコネクションを確立することができる。これにより、転送すべきＳＩＰメッセージ（ＳＩＰ ＩＮＶＩＴＥリクエストメッセージなど）を受信した後にＴＬＳコネクションを確立する従来の方法に比べてメッセージ転送の遅延を削減することができる。

次に、従来の方法による中継処理の概要について説明する。図７は、従来のＳＩＰプロキシによる中継処理の全体の流れを示すフローチャートである。

本実施の形態の図６と比較すると、従来の方法では、ステップＳ６０２に相当する転送先予測処理が存在しない点が異なっている。また、従来のＳＩＰプロキシ（以下、ＳＩＰプロキシＢという。）と送信先のＳＩＰ端末（以下、ＳＩＰ端末Ｃという。）との間のＴＬＳハンドシェイクが、ＳＩＰ ＩＮＶＩＴＥリクエストメッセージを受信した後に実行される点（ステップＳ７０４〜ステップＳ７０５）が異なっている。

ステップＳ７０１、ステップＳ７０２、ステップＳ７０３は、それぞれ図６のステップＳ６０１、ステップＳ６０３、ステップＳ６０６と同様の処理である。

ステップＳ７０３で送信元のＳＩＰ端末（以下、ＳＩＰ端末Ａという。）がＳＩＰ ＩＮＶＩＴＥリクエストメッセージを送信した後、ＳＩＰプロキシＢは、ＳＩＰ端末ＡからＳＩＰ ＩＮＶＩＴＥリクエストメッセージを受信し、暗号パラメータを利用してこれを復号する。また、ＳＩＰプロキシＢは、ＳＩＰ仕様にしたがって受信したメッセージを処理し、受信したＳＩＰメッセージが、ユーザ２宛のＳＩＰ ＩＮＶＩＴＥリクエストメッセージであることを認識する。

ＳＩＰプロキシＢは、ユーザ２宛のメッセージの送信先であるＳＩＰ端末Ｃを識別すると、ＳＩＰ端末Ｃとの間のＴＬＳコネクションを確立するためのＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージを作成してＳＩＰ端末Ｃに送信する（ステップＳ７０４）

ステップＳ７０５のＳＩＰプロキシＢとＳＩＰ端末Ｃとの間のＴＬＳハンドシェイクは、ステップＳ６０５と同様の処理である。

次に、従来のＳＩＰプロキシＢでは、ＴＬＳコネクションが確立されると、暗号パラメータを利用してＳＩＰ ＩＮＶＩＴＥリクエストメッセージを暗号化し、確立したＴＬＳコネクションを利用して、ＳＩＰ端末Ｂに対して送信する（ステップＳ７０６）。

ステップＳ７０７〜ステップＳ７１１の２００ ＯＫレスポンス送信処理、ＳＩＰ ＡＣＫリクエストメッセージ送受信処理は、ステップＳ６０８〜ステップＳ６１２までと同様の処理であるため、その説明を省略する。

このように、従来の方法では、ステップＳ７０３で送信されたＳＩＰメッセージを受信した後に、受信したＳＩＰメッセージの宛先を識別し（ステップＳ７０４）、識別した宛先との間でＴＬＳコネクションを確立している（ステップＳ７０５）。このため、ＳＩＰメッセージの配送時間の遅延が生じていた。

一方、図６で説明したように、本実施の形態の方法では、ＳＩＰメッセージを受信する前に、ＳＩＰプロキシ１００とＳＩＰ端末２００ａとの間のＴＬＳコネクション確立と、ＳＩＰプロキシ１００とＳＩＰ端末２００ｂとの間のＴＬＳコネクション確立が並行に行われるため、高速にＳＩＰ ＩＮＶＩＴＥリクエストメッセージの転送を行うことが可能となる。

なお、以上では、事前にＴＬＳコネクションの確立を行うＳＩＰ端末２００を１台のみとして説明したが、予測テーブル１２２に複数の転送先の情報を記憶し、複数のＳＩＰ端末２００との間でさらに並行してＴＬＳコネクションを確立するように構成してもよい。

このように、第１の実施の形態にかかる中継装置では、ＴＬＳコネクションの確立要求を受付けたときに事前に記憶した情報を参照して配送先ＳＩＰエンティティを予測し、当該ＳＩＰエンティティとの間のＴＬＳコネクションの確立を事前に実行することができる。このため、中継装置がメッセージ配送のため実行する通信確立処理により生じるメッセージ配送時の遅延を削減することができる。

（第２の実施の形態）
第２の実施の形態にかかる中継装置は、ＳＩＰメッセージに含まれる送信元を特定する情報と、配送先ＳＩＰエンティティとを対応づけて記憶し、転送するＳＩＰメッセージを受信したときに、記憶した情報を参照して配送先ＳＩＰエンティティを予測し、当該ＳＩＰエンティティとの間のＴＬＳコネクションの確立を事前に実行するものである。

なお、第２の実施の形態では、ＳＩＰプロキシの構成が異なっているが、その他の装置（ＳＩＰ端末２００、ルータ３００）およびネットワーク構成は第１の実施の形態と同様であるため、その説明を省略する。

図８は、第２の実施の形態にかかるＳＩＰプロキシ８００の構成を示すブロック図である。図８に示すように、ＳＩＰプロキシ８００は、記憶部８２０と、送受信部１０１と、メッセージ処理部１０２と、コネクション確立部１０３と、取得部８０４とを備えている。

第２の実施の形態では、記憶部８２０に記憶された情報のデータ構造、および取得部８０４の機能が第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかるＳＩＰプロキシ１００の構成を表すブロック図である図１と同様であるので、同一符号を付し、ここでの説明は省略する。

記憶部８２０は、第１の実施の形態の記憶部１２０と同様にメッセージを中継する処理で用いる各種情報を記憶するものであり、コネクション管理テーブル１２１と、予測テーブル８２２とを格納している。コネクション管理テーブル１２１のデータ構造は第１の実施の形態の図３と同様であるので、ここでの説明は省略する。

第２の実施の形態の予測テーブル８２２は、ＳＩＰメッセージ内に含まれる情報から、転送するＳＩＰメッセージの転送先となるＳＩＰ端末２００を特定するための情報を格納するテーブルである。図９は、第２の実施の形態の予測テーブル８２２のデータ構造の詳細を示す説明図である。

図９に示すように、予測テーブル８２２は、ＳＩＰメッセージの種類を識別するメソッド名と、ＳＩＰメッセージの送信元ＵＲＩと、コンタクトアドレスと、予測ＳＩＰメッセージ転送先とを対応づけて格納している。

メソッド名には、「Ｐｕｂｌｉｓｈ」、「Ｒｅｇｉｓｔｅｒ」のように、ＳＩＰメソッドに対応した名称が設定される。送信元ＵＲＩは、例えばＳＩＰメッセージのＦｒｏｍヘッダに含まれるＵＲＩを表す。コンタクトアドレスは、例えば、ＳＩＰメッセージのＣｏｎｔａｃｔヘッダに含まれるＵＲＩを表す。

なお、予測ＳＩＰメッセージ転送先と関連付ける情報は上記に限られず、ＳＩＰメッセージのボディ部の情報を含む、ＳＩＰメッセージ内のあらゆる情報を関連付けることができる。例えば、ボディ部のＳＤＰ内に格納されるメディア種別などによって予測ＳＩＰメッセージ転送先を決定するように構成してもよい。

図８に戻り、取得部８０４は、送受信部１０１から、受信したメッセージのメソッド名、送信元ＵＲＩおよびコンタクトアドレスなどのアドレス情報を受け取り、受け取ったメソッド名およびアドレス情報に対応する予測ＳＩＰメッセージ転送先を予測テーブル８２２から取得するものである。

次に、このように構成された第２の実施の形態にかかるＳＩＰプロキシ８００による中継処理について図１０を用いて説明する。図１０は、第２の実施の形態における中継処理の全体の流れを示すフローチャートである。

以下では、事前に交換したＳＩＰメッセージであるＳＩＰ ＰｕｂｌｉｓｈメッセージまたはＳＩＰ Ｒｅｇｉｓｔｅｒメッセージに含まれる情報（Ｆｒｏｍヘッダ情報、コンタクトアドレス情報など）から、以後に受信するＳＩＰ ＩＮＶＩＴＥリクエストメッセージなどのＳＩＰメッセージの転送先アドレスを予測する場合を例として説明する。

ここで、事前にＳＩＰ Ｒｅｇｉｓｔｅｒを行う場合としては、ＳＩＰ端末２００をＳＩＰシステムに接続し、アドレスの登録を行う通常のシステムが該当する。

また、事前にＳＩＰ Ｐｕｂｌｉｓｈを行う場合としては、ＳＩＰ端末２００で、（１）受話器を上げる、（２）最初のダイヤルをプッシュする、（３）オフフック状態にする、（４）発呼用インタフェースを起動するなどのタイミングで、ＳＩＰ ＰｕｂｌｉｓｈなどのＳＩＰメッセージを送信し、ＳＩＰ端末２００の状態をＳＩＰシステムの一部で共有するシステムなどが考えられる。

これらのシステムにおいて、ＳＩＰ ＲｅｇｉｓｔｅｒやＳＩＰ Ｐｕｂｌｉｓｈの後に、自動的に特定のＳＩＰ ＵＲＩに対してＳＩＰ ＩＮＶＩＴＥを実行するシステム（ホットラインシステムなど）が第２の実施の形態が適用できる具体例である。

ここで、ＳＩＰプロキシ８００の記憶部８２０の予測テーブル８２２には、メソッドがＳＩＰ ＲｅｇｉｓｔｅｒもしくはＳＩＰ Ｐｕｂｌｉｓｈであり、送信元ＵＲＩがＳＩＰ端末２００ａ上のユーザ１である場合、予測ＳＩＰメッセージ転送先として、ＳＩＰ端末２００ｂのＩＰアドレスとＳＩＰの通常ポートが予測されるよう、情報が格納されているとする。

最初に、ＳＩＰ端末２００ａの送受信部２０１が、ＳＩＰプロキシ８００宛にＴＬＳコネクションの確立を要求するためのＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージを送信する（ステップＳ１００１）。

なお、この処理の前提として、送信先の決定処理およびメッセージ作成処理が以下のような手順で実行される。まず、ＳＩＰ端末２００ａ上のユーザ１がアプリケーション２０４を操作することなどにより、アプリケーション２０４がメッセージ処理部２０２にＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージまたはＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージの作成を依頼する。そして、メッセージ処理部２０２が、ＳＩＰ仕様にしたがって、メッセージを作成し、送信先をＳＩＰプロキシ８００であると決定する。

作成されたメッセージは、送受信部１０１に転送される。送受信部１０１は、コネクション確立部２０３に、ＳＩＰプロキシ８００との間のＴＬＳコネクションの確立を依頼する。ＳＩＰ端末２００ａのコネクション確立部２０３は、ＳＩＰプロキシ８００との間でＴＬＳコネクションを確立するため、ＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージを作成し、送受信部１０１に転送する。

このようにして作成されたＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージが送受信部２０１によってＳＩＰプロキシ８００に送信され（ステップＳ１００１）、ＳＩＰプロキシ８００の送受信部１０１によって受信される。

ステップＳ１００２のＴＬＳハンドシェイクは、図６のステップＳ６０３と同様の処理であるため、その説明を省略する。

ＴＬＳコネクションが確立されると、ＳＩＰ端末２００ａの送受信部１０１は、コネクション確立部２０３が管理している暗号パラメータを利用してＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージまたはＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを暗号化し、確立したＴＬＳコネクションを利用して、ＳＩＰプロキシ８００に対して送信する（ステップＳ１００３）。（図１０においては、ＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージの場合を示す。）

次に、ＳＩＰプロキシ８００の送受信部１０１は、ＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージまたはＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを受信し、コネクション管理テーブル１２１に格納されている暗号パラメータを利用してこれを復号し、メッセージ処理部１０２に対して転送する。メッセージ処理部１０２は、ＳＩＰ仕様にしたがって、受信したＳＩＰメッセージの処理を行う。

また、送受信部１０１は、受信したＳＩＰメッセージのメソッド名、Ｆｒｏｍヘッダ値から取得した送信元ＵＲＩおよびコンタクトアドレスを、取得部８０４に対して通知する。取得部８０４は、予測テーブル８２２を参照し、通知されたメソッド名、送信元ＵＲＩ、およびコンタクトアドレスに対応する予測ＳＩＰメッセージ転送先を取得する（ステップＳ１００４）。ここでは、ＳＩＰ端末２００ａから受信したＳＩＰメッセージに関する予測ＳＩＰメッセージ転送先は、ＳＩＰ端末２００ｂであると決定される。

このように転送先を予測した後、以下のステップＳ１００５〜ステップＳ１００６で、ＳＩＰ端末２００ｂとの間のＴＬＳコネクションの確立処理が行われる。なお、ステップＳ１００５〜ステップＳ１００６のＴＬＳコネクションの確立処理と、ステップＳ１００７のレスポンス送信処理は、並行して実行される。

ステップＳ１００５〜ステップＳ１００６のＴＬＳハンドシェイクは、図６のステップＳ６０４〜ステップＳ６０５と同様の処理であるため、その説明を省略する。ステップＳ１００７では、受信したメッセージの種類に応じて以下のような手順で処理が行われる。

まず、受信したメッセージが、ＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージであった場合、メッセージ処理部１０２が、ＳＩＰロケーションサーバに対して、ＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージに示されているＡｏＲ（Address of Record）およびコンタクトアドレスを登録する処理を行う。また、メッセージ処理部１０２は、ＳＩＰ仕様にしたがって、ＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージに対するレスポンスメッセージとして、ＳＩＰ端末２００ａに宛てた２００ ＯＫレスポンスメッセージを作成し、送受信部１０１に転送する。

一方、受信したメッセージが、ＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージであった場合、メッセージ処理部１０２が、ＳＩＰヘッダのＲｅｑｕｅｓｔ-ＵＲＩなどを参照し、受信したＳＩＰメッセージの転送先を決定する。このために、例えばＳＩＰロケーションサーバに問い合わせることなどを行ってもよい。メッセージ処理部１０２は、決定した転送先を宛て先として、送受信部１０１に対してＳＩＰメッセージデータを転送する。送受信部１０１は、コネクション確立部１０３に、メッセージ転送先との間のＴＬＳコネクションの確立を依頼する。ＳＩＰプロキシ８００のコネクション確立部１０３は、メッセージ転送先との間でＴＬＳコネクションを確立するため、ＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージを作成し、送受信部１０１を介して転送先に送信する。ここでは詳細な説明および図示を省略するが、以後は通常のＳＩＰ ＰＵＢＬＩＳＨメッセージの処理シーケンス通りに、ＴＬＳコネクションを確立して、ＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを転送する。送受信部１０１は、メッセージ転送先からＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージに対応する２００ ＯＫレスポンスメッセージを受信すると、コネクション管理テーブル１２１に格納されている暗号パラメータを利用してこれを復号し、メッセージ処理部１０２に対して転送する。メッセージ処理部１０２は、受信したＳＩＰメッセージが、ユーザ１宛であることを認識し、ＳＩＰ端末２００ａ宛てに転送するため、これを送受信部１０１に転送する。

送受信部１０１は、ＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージまたはＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージに対応する２００ ＯＫレスポンスメッセージを、コネクション確立部２０３が管理している暗号パラメータを利用して暗号化し、既に確立しているＳＩＰ端末２００ａとの間のＴＬＳコネクションを利用して、ＳＩＰ端末２００ａに対して配送する（ステップＳ１００７）。

次に、ＳＩＰ端末２００ｂは、以下のような手順により、受信した２００ ＯＫレスポンスメッセージを処理する（ステップＳ１００８）。

まず、ＳＩＰ端末２００ａの送受信部１０１は、２００ ＯＫレスポンスメッセージを受信し、コネクション確立部２０３が管理している暗号パラメータを利用してこれを復号し、メッセージ処理部２０２に対して転送する。メッセージ処理部２０２は、受信したレスポンスメッセージが、ＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージまたはＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージに対するレスポンスメッセージであることを認識する。ここでアプリケーション２０４は、ユーザ１に対して通知を行ってもよい。

次に、ＳＩＰ端末２００ａ上の設定により自動的に、もしくはユーザ１がアプリケーション２０４を操作することなどにより、アプリケーション２０４がメッセージ処理部２０２に対して、ユーザ２を宛先とするＳＩＰ ＩＮＶＩＴＥリクエストメッセージの作成を依頼する。そして、メッセージ処理部２０２が、ＳＩＰ仕様にしたがって、ユーザ２に宛てたＳＩＰ ＩＮＶＩＴＥリクエストメッセージを作成し、このメッセージの送信先をＳＩＰプロキシ８００であると決定する。

作成されたメッセージは、送受信部２０１に転送される。送受信部２０１は、コネクション確立部２０３が管理している暗号パラメータを利用してＳＩＰ ＩＮＶＩＴＥリクエストメッセージを暗号化し、既に確立しているＳＩＰプロキシ８００との間のＴＬＳコネクションを利用して、ＳＩＰプロキシ８００に対して配送する（ステップＳ１００９）。

ステップＳ１０１０からステップＳ１０１５までの、ＳＩＰ ＩＮＶＩＴＥリクエストメッセージ転送処理、２００ ＯＫレスポンス送信処理、ＳＩＰ ＡＣＫリクエストメッセージ送受信処理は、第１の実施の形態にかかるＳＩＰプロキシ１００におけるステップＳ６０７〜ステップＳ６１２までと同様の処理であるため、その説明を省略する。

このように、本実施の形態によれば、転送されるＳＩＰメッセージ（ＳＩＰ ＩＮＶＩＴＥリクエストメッセージ）を受信する前に送信されるＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージもしくはＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージを受信した時点で、後で受信するＳＩＰメッセージの転送先を予測して事前にＴＬＳコネクションを確立することができる。これによりメッセージ転送の遅延を削減することができる。

次に、従来の方法による中継処理の概要について説明する。図１１は、従来のＳＩＰプロキシによる中継処理の全体の流れを示すフローチャートである。

本実施の形態の図１０と比較すると、従来の方法では、ステップＳ１００４に相当する転送先予測処理が存在しない点が異なっている。また、ＳＩＰプロキシＢとＳＩＰ端末Ｃとの間のＴＬＳハンドシェイクが、ＳＩＰ ＩＮＶＩＴＥリクエストメッセージを受信した後に実行される点（ステップＳ１１０７〜ステップＳ１１０８）が異なっている。

ステップＳ１１０１〜ステップＳ１１０３は、図１０のステップＳ１００１〜ステップＳ１００３と同様の処理である。また、ステップＳ１１０４〜ステップＳ１１０６は、図１０のステップＳ１００７〜ステップＳ１００９と同様の処理である。

ステップＳ１１０６でＳＩＰ端末ＡがＳＩＰ ＩＮＶＩＴＥリクエストメッセージを送信した後、ＳＩＰプロキシＢは、ＳＩＰ端末ＡからＳＩＰ ＩＮＶＩＴＥリクエストメッセージを受信し、暗号パラメータを利用してこれを復号する。また、ＳＩＰプロキシＢは、ＳＩＰ仕様にしたがって受信したメッセージを処理し、受信したＳＩＰメッセージが、ユーザ２宛のＳＩＰ ＩＮＶＩＴＥリクエストメッセージであることを認識する。

ＳＩＰプロキシＢは、ユーザ２宛のメッセージの送信先であるＳＩＰ端末Ｃを識別すると、ＳＩＰ端末Ｃとの間のＴＬＳコネクションを確立するためのＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージを作成してＳＩＰ端末Ｃに送信する（ステップＳ１１０７）。

ステップＳ１１０８のＳＩＰプロキシＢとＳＩＰ端末Ｃとの間のＴＬＳハンドシェイクは、図１０のステップＳ１００６と同様の処理である。また、ステップＳ１１０９〜ステップＳ１１１４は、図１０のステップＳ１０１０〜ステップＳ１０１５と同様の処理である。

このように、従来の方法では、ステップＳ１１０６で送信されたＳＩＰメッセージを受信した後に、受信したＳＩＰメッセージの宛先を識別し（ステップＳ１１０７）、識別した宛先との間でＴＬＳコネクションを確立している（ステップＳ１１０８）。このため、ＳＩＰメッセージの配送時間の遅延が生じていた。

一方、図１０で説明したように、本実施の形態の方法では、ＳＩＰ ＩＮＶＩＴＥリクエストメッセージを受信する前に、ＳＩＰプロキシ８００とＳＩＰ端末２００ｂとの間のＴＬＳコネクション確立を実行するため、高速にＳＩＰ ＩＮＶＩＴＥリクエストメッセージの転送を行うことが可能となる。

すなわち、ＳＩＰプロキシ８００とＳＩＰ端末２００ｂとの間のＴＬＳコネクション確立処理（ステップＳ１００６）を、ＳＩＰ ＲＥＧＩＳＴＥＲリクエストメッセージまたはＳＩＰ ＰＵＢＬＩＳＨリクエストメッセージの処理（ステップＳ１００７）と同時に事前に行っているため、ＳＩＰ ＩＮＶＩＴＥリクエストメッセージを転送するとき（ステップＳ１００９）に新たにコネクション確立を行う処理遅延が生じない。

このように、第２の実施の形態にかかる中継装置では、転送するＳＩＰメッセージを受信したときに事前に記憶した情報を参照して配送先ＳＩＰエンティティを予測し、当該ＳＩＰエンティティとの間のＴＬＳコネクションの確立を事前に実行することができる。このため、中継装置がメッセージ配送のため実行する通信確立処理により生じるメッセージ配送時の遅延を削減することができる。

なお、上記各実施の形態では、シグナリングプロトコルとしてＳＩＰを用いる例について説明したが、適用できるプロトコルはこれに限られるものではなく、Ｈ．３２３、ＭＧＣＰ（Media Gateway Control Protocol）、Ｍｅｇａｃｏ（Media Gateway Control）など従来から用いられているあらゆるシグナリングプロトコルに適用できる。また、上記各実施の形態では、暗号化プロトコルとして、ＴＬＳを用いる例について説明したが、ＩＰｓｅｃ（Security Architecture for Internet Protocol）などの他のプロトコルを用いるように構成してもよい。暗号化プロトコルとしてＩＰｓｅｃを用いる場合は、例えば鍵交換を開始するためのＩＳＡＫＭＰ（Internet Security Association and Key Management Protocol）パケットが、コネクションの確立を要求するメッセージ（ＴＬＳにおけるＴＬＳ ｃｌｉｅｎｔ ｈｅｌｌｏメッセージ）に相当する。

次に、第１または第２の実施の形態にかかる中継装置のハードウェア構成について図１２を用いて説明する。図１２は、第１または第２の実施の形態にかかる中継装置のハードウェア構成を示す説明図である。

第１または第２の実施の形態にかかる中継装置は、ＣＰＵ５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、ＨＤＤ、ＣＤ（Compact Disc）ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス６１を備えており、通常のコンピュータを利用したハードウェア構成となっている。

第１または第２の実施の形態にかかる中継装置で実行される通信確立プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。

また、第１または第２の実施の形態にかかる中継装置で実行される通信確立プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１または第２の実施の形態にかかる中継装置で実行される通信確立プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

また、第１または第２の実施の形態の通信確立プログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

第１または第２の実施の形態にかかる中継装置で実行される通信確立プログラムは、上述した各部（送受信部、メッセージ処理部、コネクション確立部、取得部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体から通信確立プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。

以上のように、本発明にかかる装置、方法およびプログラムは、セキュアなコネクションを確立してＳＩＰなどのシグナリングプロトコルを利用してメッセージを中継する中継装置に適している。

第１の実施の形態にかかる通信システムのネットワーク構成を示すブロック図である。 第１の実施の形態にかかるＳＩＰプロキシの構成を示すブロック図である。 コネクション管理テーブルのデータ構造の詳細を示す説明図である。 第１の実施の形態の予測テーブルのデータ構造の詳細を示す説明図である。 第１の実施の形態にかかるＳＩＰ端末の構成を示すブロック図である。 第１の実施の形態における中継処理の全体の流れを示すフローチャートである。 従来のＳＩＰプロキシによる中継処理の全体の流れを示すフローチャートである。 第２の実施の形態にかかるＳＩＰプロキシの構成を示すブロック図である。 第２の実施の形態の予測テーブルのデータ構造の詳細を示す説明図である。 第２の実施の形態における中継処理の全体の流れを示すフローチャートである。 従来のＳＩＰプロキシによる中継処理の全体の流れを示すフローチャートである。 第１または第２の実施の形態にかかる中継装置のハードウェア構成を示す説明図である。

符号の説明

５１ ＣＰＵ
５２ ＲＯＭ
５３ ＲＡＭ
５４ 通信Ｉ／Ｆ
６１ バス
１００ ＳＩＰプロキシ
１０１ 送受信部
１０２ メッセージ処理部
１０３ コネクション確立部
１０４ 取得部
１２０ 記憶部
１２１ コネクション管理テーブル
１２２ 予測テーブル
２００ａ、２００ｂ、２００ｃ ＳＩＰ端末
２０１ 送受信部
２０２ メッセージ処理部
２０３ コネクション確立部
２０４ アプリケーション
３００ ルータ
８００ ＳＩＰプロキシ
８０４ 取得部
８２０ 記憶部
８２２ 予測テーブル

Claims (16)

1. 端末装置との間で通信を確立し、前記端末装置間で送受信されるメッセージを、確立した通信によって中継する中継装置であって、
   前記端末装置を識別する第１識別情報と、前記端末装置から送信されたメッセージの転送先として予測される他の端末装置を識別する第２識別情報とを対応づけて記憶する記憶部と、
   前記他の端末装置に転送する転送メッセージの前に受信され、通信に関する処理要求と前記第１識別情報とを含む要求メッセージを前記端末装置から受信する受信部と、
   受信した前記要求メッセージに含まれる前記第１識別情報に対応する前記第２識別情報を前記記憶部から取得する取得部と、
   取得した前記第２識別情報の前記他の端末装置との間で通信を確立する確立部と、
   を備えたことを特徴とする中継装置。
2. 前記受信部は、前記処理要求として、前記転送メッセージを送信するための通信の確立要求と、前記第１識別情報とを含む前記要求メッセージを前記端末装置から受信すること、
   を特徴とする請求項１に記載の中継装置。
3. 前記受信部は、ＴＬＳ（Transport Layer Security）プロトコルによる前記確立要求と、前記第１識別情報とを含む前記要求メッセージを前記端末装置から受信すること、
   を特徴とする請求項２に記載の中継装置。
4. 前記受信部は、ＩＰｓｅｃプロトコルによる前記確立要求と、前記第１識別情報とを含む前記要求メッセージを前記端末装置から受信すること、
   を特徴とする請求項２に記載の中継装置。
5. 前記記憶部は、前記第１識別情報として前記端末装置のＩＰアドレスと、前記第２識別情報とを対応づけて記憶し、
   前記受信部は、前記第１識別情報として前記端末装置のＩＰアドレスを含む前記要求メッセージを前記端末装置から受信し、
   前記取得部は、受信した前記要求メッセージに含まれる前記ＩＰアドレスに対応する前記第２識別情報を前記記憶部から取得すること、
   を特徴とする請求項２に記載の中継装置。
6. 前記記憶部は、前記端末装置のＩＰアドレスと通信を確立するポート番号とを前記第１識別情報として前記第２識別情報と対応づけて記憶し、
   前記受信部は、前記第１識別情報として前記端末装置のＩＰアドレスと前記ポート番号とを含む前記要求メッセージを前記端末装置から受信し、
   前記取得部は、受信した前記要求メッセージに含まれるＩＰアドレスと前記ポート番号とに対応する前記第２識別情報を前記記憶部から取得すること、
   を特徴とする請求項２に記載の中継装置。
7. 前記受信部は、前記端末装置との間で確立された通信によって送信された前記要求メッセージを前記端末装置から受信すること、
   を特徴とする請求項１に記載の中継装置。
8. 前記受信部は、前記要求メッセージとして、ＳＩＰ（Session Initiation Protocol）のＲＥＧＩＳＴＥＲメッセージを前記端末装置から受信すること、
   を特徴とする請求項７に記載の中継装置。
9. 前記受信部は、前記要求メッセージとして、ＳＩＰのＰＵＢＬＩＳＨメッセージを前記端末装置から受信すること、
   を特徴とする請求項７に記載の中継装置。
10. 前記記憶部は、前記第１識別情報として前記端末装置に対応するＳＩＰのＵＲＩ（Uniform Resource Identifier）と、前記第２識別情報とを対応づけて記憶し、
    前記受信部は、前記第１識別情報として前記ＵＲＩを含む前記要求メッセージを前記端末装置から受信し、
    前記取得部は、受信した前記要求メッセージに含まれる前記ＵＲＩに対応する前記第２識別情報を前記記憶部から取得すること、
    を特徴とする請求項７に記載の中継装置。
11. 前記記憶部は、前記第１識別情報として前記端末装置に対応するＳＩＰのコンタクトアドレスと、前記第２識別情報とを対応づけて記憶し、
    前記受信部は、前記第１識別情報として前記コンタクトアドレスを含む前記要求メッセージを前記端末装置から受信し、
    前記取得部は、受信した前記要求メッセージに含まれる前記コンタクトアドレスに対応する前記第２識別情報を前記記憶部から取得すること、
    を特徴とする請求項７に記載の中継装置。
12. 前記記憶部は、メッセージの種類と、前記第１識別情報と、前記第２識別情報とを対応づけて記憶し、
    前記取得部は、さらに、受信した前記要求メッセージの種類と取得した前記第１識別情報とに対応する前記第２識別情報を前記記憶部から取得すること、
    を特徴とする請求項７に記載の中継装置。
13. 前記確立部は、取得した前記第２識別情報の前記他の端末装置との間でＴＬＳ（Transport Layer Security）プロトコルによって通信を確立すること、
    を特徴とする請求項１に記載の中継装置。
14. 前記確立部は、取得した前記第２識別情報の前記他の端末装置との間でＩＰｓｅｃプロトコルによって通信を確立すること、
    を特徴とする請求項１に記載の中継装置。
15. 端末装置との間で通信を確立し、前記端末装置間で送受信されるメッセージを、確立した通信によって中継する中継装置における通信確立方法であって、
    受信部によって、他の端末装置に転送する転送メッセージの前に受信され、通信に関する処理要求と前記端末装置を識別する第１識別情報とを含む要求メッセージを前記端末装置から受信する受信ステップと、
    取得部によって、前記第１識別情報と、前記端末装置から送信されたメッセージの転送先として予測される前記他の端末装置を識別する第２識別情報とを対応づけて記憶する記憶部から、受信した前記要求メッセージに含まれる前記第１識別情報に対応する前記第２識別情報を取得する取得ステップと、
    確立部によって、取得した前記第２識別情報の前記他の端末装置との間で通信を確立する確立ステップと、
    を備えたことを特徴とする通信確立方法。
16. 端末装置との間で通信を確立し、前記端末装置間で送受信されるメッセージを、確立した通信によって中継する中継装置における通信確立プログラムであって、
    他の端末装置に転送する転送メッセージの前に受信され、通信に関する処理要求と前記端末装置を識別する第１識別情報とを含む要求メッセージを前記端末装置から受信する受信手順と、
    前記第１識別情報と、前記端末装置から送信されたメッセージの転送先として予測される前記他の端末装置を識別する第２識別情報とを対応づけて記憶する記憶部から、受信した前記要求メッセージに含まれる前記第１識別情報に対応する前記第２識別情報を取得する取得手順と、
    取得した前記第２識別情報の前記他の端末装置との間で通信を確立する確立手順と、
    をコンピュータに実行させる通信確立プログラム。

Images