JP4703576B2 - コネクションを維持する装置、方法およびプログラム - Google Patents

Description

この発明は、中継する通信についてのコネクションを維持する装置、方法およびプログラムに関するものである。

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

また、ＳＩＰ端末は特定のＳＩＰプロキシに接続され、ＳＩＰメッセージの送受信を行う際は、常にその特定のＳＩＰプロキシを介して行う。このような特定のＳＩＰプロキシをアウトバウンドプロキシという。

例えば、ＳＩＰ端末ＡのアウトバウンドプロキシをＳＩＰプロキシＡ、ＳＩＰ端末ＢのアウトバウンドプロキシをＳＩＰプロキシＢとすると、ＳＩＰ端末Ａが、ＳＩＰ端末Ｂへ宛てたＳＩＰメッセージは、常にＳＩＰ端末ＡからＳＩＰプロキシＡおよびＳＩＰプロキシＢを経由してＳＩＰ端末Ｂへ転送される。なお、このような通信モデルは、一般にＳＩＰ台形通信モデルと呼ばれる。

従来のＳＩＰシステムにおけるＳＩＰエンティティは、ＳＩＰにおける基本的なメッセージ交換であるトランザクション期間またはダイアログ期間と、ＴＬＳコネクションの維持期間とを同期させていた。

以下にトランザクション期間とＴＬＳコネクションの維持期間との同期に関して具体的に説明する。ＳＩＰメッセージ交換は、通常、トランザクションという単位で行われる。トランザクションとは、送信側ＳＩＰ端末が受信側ＳＩＰ端末に宛てて送信するＳＩＰリクエストメッセージと、これを受信した受信側ＳＩＰ端末が送信側ＳＩＰ端末に宛てて送信するＳＩＰレスポンスメッセージとから構成される。

トランザクション単位でＴＬＳコネクションを維持する場合、各ＳＩＰエンティティは、ＳＩＰメッセージのトランザクションを識別し、あるＳＩＰリクエストメッセージが送信される際に、それを転送する先となるＳＩＰエンティティとの間にＴＬＳコネクションを確立して維持し、ＳＩＰレスポンスメッセージが送信された後に、それを転送した先となるＳＩＰエンティティとの間のＴＬＳコネクションを破棄する。

次に、ダイアログ期間とＴＬＳコネクションの維持期間との同期に関して具体的に説明する。ダイアログとは、ＳＩＰメッセージによって送信側ＳＩＰ端末と受信側ＳＩＰ端末との間でメディアセッションを開始してから終了するまでのＳＩＰ端末間の関係のことを指す。メディアセッションを開始する際には、ＳＩＰ端末はＳＩＰ ＩＮＶＩＴＥメッセージを交換する。メディアセッションを終了する際には、ＳＩＰ端末は、ＳＩＰ ＢＹＥメッセージを交換する。

ダイアログ単位でＴＬＳコネクションを維持する場合、各ＳＩＰエンティティは、ＳＩＰのダイアログを識別し、ＳＩＰ ＩＮＶＩＴＥメッセージ交換の際に、それを転送する先となるＳＩＰエンティティとの間にＴＬＳコネクションを確立し、ダイアログの間ＴＬＳコネクションを維持し、ＳＩＰ ＢＹＥメッセージを交換した後に、それを転送した先となるＳＩＰエンティティとの間のＴＬＳコネクションを破棄する。

従来は、このような方法により、ＴＬＳコネクションの維持期間とＳＩＰメッセージのトランザクション期間またはダイアログ期間とが同期していた。

ＴＬＳコネクションを確立するとメモリなどの計算リソースを消費するため、特に多数のＳＩＰ端末と接続するＳＩＰプロキシは、ＳＩＰ端末との間で確立した全てのＴＬＳコネクションを維持することができない場合がある。反対に、ＴＬＳコネクションの確立には時間がかかるため、ＳＩＰメッセージの転送遅延を削減するためには、可能な限りＴＬＳコネクションは維持することが望ましい。このように、ＴＬＳコネクションの確立に関しては、リソース消費量低減と転送遅延削減との間でトレードオフの関係がある。

例えば、接続されるＳＩＰ端末が少ないＳＩＰプロキシの場合、リソース消費量の問題が存在しないため、あるトランザクションまたはダイアログが終了しても、そのままＴＬＳコネクションを維持しておくことも可能であり、このような実装も多く見られる。

一方、一つのＳＩＰプロキシに多数のＳＩＰ端末が接続される場合、各ＳＩＰ端末のＳＩＰアプリケーションの使用状況によっては、ＳＩＰプロキシが全てのＴＬＳコネクションを維持することができない場合がある。この場合、ＳＩＰプロキシは、維持しているＴＬＳコネクションのうち、例えば最も使用頻度の低いＴＬＳコネクションを選択し、これを破棄するなどの処理を行う。これにより、使用頻度の高いＴＬＳコネクションを維持することができる。

非特許文献１では、所定の期間、コネクションを維持すべきこと、およびＳＩＰメッセージを送信するトランスポートにおいてコネクションが破棄されていた場合は新たにコネクションを確立することが規定されている。具体的には、ＳＩＰメッセージを転送するためのトランスポート（ＴＣＰまたはＴＬＳコネクション）の維持に関しては、コネクション上で最後のメッセージを送受信した後も、６４×Ｔ１秒間、そのコネクションを維持することが望ましいことが示されている。ここで、Ｔ１とは、ＲＴＴ（Round Trip Time）の予測値であり、そのデフォルト値は５００ｍｓである。

また、ＳＩＰレスポンスメッセージを送信する際、ＳＩＰリクエストメッセージを送信した時に確立したトランスポートのコネクションを利用して転送し、そのコネクションが既に破棄されていた場合は、新たにコネクションを確立することが示されている。

なお、あるＳＩＰエンティティが特定のＴＬＳコネクションの維持を所望する場合、接続しているＳＩＰエンティティに対してｋｅｅｐ−ａｌｉｖｅメッセージを送信する方法などにより、接続しているＳＩＰエンティティにコネクションの維持を要求することが可能である。

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>

しかしながら、非特許文献１などの方法では、ＳＩＰ台形通信モデルのＳＩＰエンティティ間のすべての経路のコネクションを適切に維持できないという問題があった。例えば、ｋｅｅｐ−ａｌｉｖｅメッセージを送信する方法は、主に２つのＳＩＰエンティティ間の単独のＴＬＳコネクションを維持することを意図するものである。このため、上述のようなＳＩＰ台形通信モデルの４つのＳＩＰエンティティ間で確立される３つのＴＬＳコネクションのすべての維持を要求することができなかった。

また、ｋｅｅｐ−ａｌｉｖｅメッセージを利用する方法は、余分なトラフィックを発生させるため、複数のＳＩＰ端末が接続されるＳＩＰプロキシなどでは利用できないことも問題となる。

さらに、維持するＴＬＳコネクションの選択を使用頻度のみによって決定する方法では、単純に使用頻度により維持するＴＬＳコネクションを決定すべきでない場合には適切にコネクションの維持を行うことができない。例えば、使用頻度は低いが、高い応答性が必要なＳＩＰアプリケーションのトランザクションまたはダイアログが破棄され、不必要なＴＬＳコネクションが維持される場合があった。

本発明は、上記に鑑みてなされたものであって、複数の装置を経由するコネクションを適切に維持することができる装置、方法およびプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、第１端末から受信したメッセージを中継装置を介して第２端末に中継し、前記第２端末から送信されたメッセージを前記中継装置を介して受信して前記第１端末に中継するサーバ装置であって、リソースの使用状況を管理するリソース管理部と、前記第１端末と前記第２端末との間でメッセージを中継するためのコネクションを維持するための第１条件を含む第１メッセージを前記第１端末から受信する受信部と、受信した前記第１メッセージに含まれる前記第１条件と前記使用状況とに基づいて、前記コネクションを維持するために許可する第１コネクション維持条件を決定する決定部と前記第１メッセージに前記第１コネクション維持条件を追加する追加部と、前記第１コネクション維持条件が追加された前記第１メッセージを前記第２端末に中継するために、前記中継装置に送信する送信部と、決定された前記第１コネクション維持条件で前記コネクションを維持する維持部と、を備えたことを特徴とする。

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

また、本発明は、中継装置を介して外部端末と通信する端末装置であって、リソースの使用状況を管理するリソース管理部と、前記使用状況に基づいて、前記外部端末との間でメッセージを中継するためのコネクションを維持するために許可する第１コネクション維持条件を決定する決定部と、決定された前記第１コネクション維持条件を含む第１メッセージを前記中継装置に送信する送信部と、前記第１メッセージに対する応答として前記外部端末から送信されたメッセージであって、前記コネクションを維持するために前記外部端末および前記中継装置の少なくとも一方が要求した第２条件を含む第２メッセージを前記中継装置から受信する受信部と、を備え、前記決定部は、受信した前記第２条件に基づいて、さらに前記コネクションを維持するために許可する第２コネクション維持条件を決定すること、を備えたことを特徴とする。

本発明によれば、端末上のアプリケーションの要求に応じて、システム全体で適切なコネクションを維持することができるという効果を奏する。

以下に添付図面を参照して、この発明にかかるコネクションを維持する装置、方法およびプログラムの最良な実施の形態を詳細に説明する。

上述のように、従来の方法では、ＳＩＰエンティティ間のすべての経路のコネクションを適切に維持できないという問題があった。具体的には、例えば以下のような問題が生じていた。

まず、高い応答性を得るためにＴＬＳコネクションを維持することを考えると、送信側または受信側のＳＩＰ端末のアプリケーションの種別や要求に依存して、ＴＬＳコネクションの維持と破棄が決定されることが望ましい。

例えば、テキストメッセージの交換を行うアプリケーションにより特定のＳＩＰ端末間でテキストメッセージを送受信する場合、そのメッセージを転送するトランザクションのためのＴＬＳコネクションは、アプリケーションの応答性を高めるために、経由する全ての装置間で維持されていることが望まれる。

一方、システムを構成する全ての端末に対してテキストメッセージを同報通信する場合、全ての端末との間のＴＬＳコネクションを維持することに意味はないため、ＴＬＳコネクションは、トランザクションが終了したら即座に破棄されることが望まれる。

しかし、従来の方法では、上記のようなアプリケーションの個別の要求に対応してＴＬＳコネクションの維持期間を判断することができなかった。

また、ＳＩＰメッセージが交換される送信側ＳＩＰ端末、ＳＩＰメッセージを中継する２つのＳＩＰプロキシ、および受信側ＳＩＰ端末の間でそれぞれ確立される、計３つのＴＬＳコネクションを維持する必要がある。このため、ＴＬＳコネクションの維持または破棄は、あるＳＩＰエンティティ単独で決定するのではなく、他のＳＩＰエンティティ間のＴＬＳコネクションの維持状況も考慮して決定することが望ましいが、従来はそれを実現する具体的方法が存在しなかった。

このような問題を解決するため、本実施の形態にかかるサーバ装置は、端末装置からコネクションの維持を要求する維持条件を含むメッセージを受信し、自装置のリソース使用状況から当該維持条件を許可できるか否かを判断し、判断結果をさらにメッセージの中継先である外部装置に転送するものである。

図１は、本実施の形態にかかるサーバ装置であるＳＩＰプロキシ１００を含む通信システム全体の構成を示すブロック図である。同図に示すように、本実施の形態の通信システムは、複数のＳＩＰプロキシ１００ａ、１００ｂと、複数のＳＩＰ端末２００ａ、２００ｂ、２００ｃ、２００ｄ、２００ｅ、２００ｘ、２００ｙ、２００ｚとを含んでいる。

すなわち、ＳＩＰ端末２００のうちいずれか２つをそれぞれ送信端末および受信端末とし、２つのＳＩＰプロキシ１００ａ、１００ｂを経由して通信を行う、ＳＩＰ台形通信モデルを形成している。なお、ＳＩＰプロキシ１００ａ、１００ｂは同様の機能を備えるため、以下では単にＳＩＰプロキシ１００という場合がある。同様に、ＳＩＰ端末２００ａ〜２００ｚを、単にＳＩＰ端末２００という場合がある。ただし図１は、ＳＩＰエンティティの物理的な接続を示すものではなく、ＳＩＰメッセージの交換を行う関係を図示したものである。

なお、以下ではこのようにＳＩＰを用いたＳＩＰシステムを例に本実施の形態を説明するが、適用可能なシステムはＳＩＰシステムに限られず、複数の装置を経由して端末間でメッセージを送受信する形態のシステムであればあらゆる通信システムに本実施の形態の手法を適用できる。

ＳＩＰプロキシ１００は、ＳＩＰメッセージをＳＩＰ端末２００間で転送する中継サーバである。ＳＩＰ端末２００は特定のＳＩＰプロキシ１００をアウトバウンドプロキシとして選択する。そして、ＳＩＰ端末２００は、常にアウトバウンドプロキシを介してＳＩＰメッセージの送受信を行う。

なお、ＳＩＰプロキシ１００ａとＳＩＰプロキシ１００ｂとの間のＴＬＳコネクションは、そのダイアログの受信側ＳＩＰ端末２００と送信側ＳＩＰ端末２００のペアごとに新規に確立してもよい。また、単独のＴＬＳコネクションを確立し、このＴＬＳコネクションにより全てのＳＩＰメッセージを転送するように構成してもよい。ＳＩＰプロキシ１００の構成の詳細については後述する。

ＳＩＰ端末２００は、シグナリングプロトコルとしてＳＩＰを使用するＳＩＰアプリケーションを動作させる端末装置である。ＳＩＰアプリケーションとしては、典型的には、高機能ＩＰ電話端末やテキストメッセージサービスのクライアントソフトウェアが該当する。ＳＩＰ端末２００の構成の詳細については後述する。

次に、ＳＩＰプロキシ１００の構成の詳細について説明する。図２は、ＳＩＰプロキシ１００の詳細な構成を示すブロック図である。同図に示すように、ＳＩＰプロキシ１００は、記憶部１２０と、受信部１０１と、送信部１０２と、リソース管理部１１１と、決定部１１２と、コネクション管理部１１３と、メッセージ処理部１１４とを備えている。

記憶部１２０は、ＴＬＳコネクションを維持する処理で参照する各種情報を記憶するものであり、メソッド条件テーブル１２１と、時間条件テーブル１２２と、メッセージ数条件テーブル１２３と、コネクション管理テーブル１２４とを格納している。

なお、メソッド条件テーブル１２１、時間条件テーブル１２２、およびメッセージ数条件テーブル１２３は、後述する決定部１１２が決定したＴＬＳコネクション維持のための条件をそれぞれ記憶するテーブルである。各テーブルの格納する情報を、１つの条件テーブルにまとめて記憶するように構成してもよいし、このうちの一部のみを記憶するように構成してもよい。

メソッド条件テーブル１２１は、ＳＩＰで実行されるメソッドによって定められたＴＬＳコネクション維持のための条件（ＳＩＰメソッド条件）を記憶するものである。図３は、メソッド条件テーブル１２１のデータ構造の一例を示す説明図である。

同図に示すように、メソッド条件テーブル１２１は、接続するＳＩＰエンティティのアドレスおよびポートを表す接続先と、ＴＬＳコネクションを破棄する条件とするＳＩＰメソッド条件とを格納する。例えば、最初のレコードでは、「proxyB.example.com:5061」で特定されるＳＩＰプロキシ１００に対して、ＳＩＰのＢＹＥメッセージの転送が完了するまではＴＬＳコネクションを維持するＳＩＰメソッド条件が指定されている。

時間条件テーブル１２２は、ＴＬＳコネクションの維持時間によって定められたＴＬＳコネクション維持のための条件（時間条件）を記憶するものである。図４は、時間条件テーブル１２２のデータ構造の一例を示す説明図である。

同図に示すように、時間条件テーブル１２２は、接続先と、ＴＬＳコネクションの維持時間を定めた時間条件とを格納する。例えば、最初のレコードでは、ＴＬＳコネクション確立から３６００秒経過時まではＴＬＳコネクションを維持する時間条件が指定されている。

メッセージ数条件テーブル１２３は、ＴＬＳコネクションによって送受信されたＳＩＰメッセージ数によって定められたＴＬＳコネクション維持のための条件（ＳＩＰメッセージ数条件）を記憶するものである。図５は、メッセージ数条件テーブル１２３のデータ構造の一例を示す説明図である。

同図に示すように、メッセージ数条件テーブル１２３は、接続先と、ＴＬＳコネクションを破棄する閾値となる転送メッセージの個数を定めたＳＩＰメッセージ数条件とを格納する。例えば、最初のレコードでは、確立したＴＬＳコネクションによって５００個のメッセージが送受信されるまでは、ＴＬＳコネクションを維持するＳＩＰメッセージ数条件が指定されている。

コネクション管理テーブル１２４は、維持しているＴＬＳコネクションに関する情報を格納するものである。図６は、コネクション管理テーブル１２４のデータ構造の一例を示す説明図である。

同図に示すように、コネクション管理テーブル１２４は、ＴＬＳコネクションに関する情報として、接続先と、ＴＬＳコネクションを識別するためのＴＬＳコネクションＩＤと、トランザクションを識別するためのトランザクションＩＤと、ダイアログを識別するためのダイアログＩＤと、使用頻度と、ＴＬＳコネクションの開始時刻と、ＴＬＳコネクションにより送受信されたメッセージ数とを対応づけて記憶している。

使用頻度は、例えば、そのＴＬＳコネクションを利用してパケットが送信されたときに更新される。また、開始時刻は、コネクションの維持条件が時間条件で指定されているときに、コネクション開始から経過した時間を算出して時間条件を満たすか否かを判定するために参照される。同様に、メッセージ数は、コネクションの維持条件がＳＩＰメッセージ数条件で指定されているときに、コネクションによって送受信されたメッセージ数が指定された条件を超えていないか判定するために参照される。

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

受信部１０１は、ＳＩＰ端末２００または他のＳＩＰプロキシ１００などの、他のＳＩＰエンティティからＳＩＰメッセージを含むパケットを受信するものである。また、受信部１０１は、パケットを受信するときに利用するＴＬＳコネクションを、コネクション管理部１１３を用いて特定する。また、パケットを受信する際に新たにＴＬＳコネクションを作成する必要がある場合は、受信部１０１はコネクション管理部１１３に依頼して新たにＴＬＳコネクションを作成する。

送信部１０２は、他のＳＩＰエンティティに対してＳＩＰメッセージを含むパケットを送信するものである。また、送信部１０２は、パケットを送信するときに利用するＴＬＳコネクションを、コネクション管理部１１３を用いて特定する。また、パケットを送信する際に新たにＴＬＳコネクションを作成する必要がある場合は、送信部１０２はコネクション管理部１１３に依頼して新たにＴＬＳコネクションを作成する。

リソース管理部１１１は、ＴＬＳコネクションの確立に使用する計算リソースの使用状況を管理するものである。特に、リソース管理部１１１は、ＴＬＳコネクションによるメモリ使用量を管理する。なお、管理する計算リソースはメモリ使用量に限られず、ＣＰＵ（Central Processing Unit）利用率などのあらゆる計算リソースが管理対象となりうる。

決定部１１２は、ＳＩＰエンティティから通知されたＳＩＰメッセージのヘッダから、後述するメッセージ処理部１１４によって抽出されたコネクション維持条件の要求と、自装置のリソース使用状況とから、自装置がＴＬＳコネクション維持のために許可できる条件を決定するものである。決定部１１２は、リソース使用状況からコネクションを維持できないと判断したときは、コネクションを維持しないことを決定する場合もある。

コネクション管理部１１３は、パケット送受信の際に使用するＴＬＳコネクションの管理を行うものであり、維持部１１３ａと、破棄部１１３ｂとを備えている。

維持部１１３ａは、決定部１１２によりＴＬＳコネクションを維持することが決定された場合に、決定された条件にしたがってＴＬＳコネクションの維持を行うものである。ＴＬＳコネクション維持のための方法は従来から用いられているあらゆる方法を適用できる。例えば、コネクション管理テーブル１２４の使用頻度を参照し、使用頻度の低いＴＬＳコネクションを破棄する機能が備えられている場合には、使用頻度が高くなるように当該テーブルを定期的に更新することによりコネクションの破棄を回避するように構成できる。

破棄部１１３ｂは、決定部１１２によりＴＬＳコネクションを維持しないことが決定された場合や、維持のための条件が満たされなくなったときに、ＴＬＳコネクションの破棄を行うものである。

また、破棄部１１３ｂは、リソース管理部１１１からメモリ使用量が逼迫していることの通知を受けたときに、現在管理しているＴＬＳコネクションのうち、使用頻度が最も低いコネクションなどを選択して、選択したコネクションを破棄する機能を備えてもよい。

なお、コネクション管理部１１３は、受信部１０１または送信部１０２から新規ＴＬＳコネクションの作成依頼を受けた場合は、新たにＴＬＳコネクションを作成する機能を有する。

メッセージ処理部１１４は、ＳＩＰプロトコル仕様に従って、送受信するＳＩＰメッセージに関する各種処理を実行するものである。具体的には、メッセージ処理部１１４は、受信部１０１からＳＩＰメッセージを受け取り、これを転送するためにＳＩＰプロトコル仕様に従ってＳＩＰメッセージのヘッダを再構成する。また、メッセージ処理部１１４は、再構成したＳＩＰメッセージを、送信先のＳＩＰエンティティに転送するために送信部１０２に送出する。

また、メッセージ処理部１１４は、ＳＩＰプロトコル仕様に従い、ダイアログまたはトランザクションが完了した際、そのＴ１×６４秒後に、コネクション管理部１１３に対してコネクションの破棄を指示することもできる。Ｔ１は上述のようにＲＴＴの予測値であり、デフォルト値は５００ｍｓである。

本実施の形態のメッセージ処理部１１４は、本実施の形態のために拡張したＳＩＰプロトコルフォーマットに従って、ＳＩＰメッセージのヘッダを構成する機能をさらに有する。特に、転送するＳＩＰメッセージのヘッダに、自装置のリソース使用状況等から決定部１１２により決定された維持条件を追加する追加部１１４ａを備えている。ＳＩＰプロトコルフォーマットの拡張の詳細については後述する。

次に、ＳＩＰ端末２００の構成の詳細について説明する。図７は、ＳＩＰ端末２００の詳細な構成を示すブロック図である。同図に示すように、ＳＩＰ端末２００は、記憶部１２０と、受信部１０１と、送信部１０２と、リソース管理部１１１と、決定部２１２と、コネクション管理部１１３と、メッセージ処理部２１４と、アプリケーション部２１５とを備えている。

記憶部１２０、受信部１０１、送信部１０２、リソース管理部１１１、およびコネクション管理部１１３の機能は、ＳＩＰプロキシ１００の各構成部の機能と同様であるため、同一符号を付し、ここでの説明は省略する。

決定部２１２は、後述するアプリケーション部２１５が要求したＴＬＳコネクションの維持条件と、自装置のリソース使用状況とから、当該維持条件を許可できるか否かを決定するものである。また、決定部２１２は、他のＳＩＰ端末２００から維持条件を含むＳＩＰメッセージを受信した場合は、受信した維持条件と、自装置のリソース使用状況とから当該維持条件を許可できるか否かを決定する。

さらに、決定部２１２は、処理の開始時に決定した維持条件を含むＳＩＰメッセージに対して他のエンティティが応答したＳＩＰメッセージ内の維持条件を参照して、開始時に決定した維持条件を変更することを決定する場合もある。

メッセージ処理部２１４は、ＳＩＰプロキシ１００のメッセージ処理部１１４と同様に、ＳＩＰプロトコル仕様に従って、送受信するＳＩＰメッセージに関する各種処理を実行するものである。具体的には、メッセージ処理部２１４は、アプリケーション部２１５からアプリケーションを動作させるために必要なＳＩＰメッセージの構成の依頼を受けて、ＳＩＰメッセージのヘッダおよびボディを構成する。また、メッセージ処理部２１４は、このように構成したＳＩＰメッセージを送信部１０２に送出する。

また、メッセージ処理部２１４は、受信部１０１が受信したＳＩＰメッセージを受け取り、受け取ったＳＩＰメッセージのヘッダおよびボディの構成を解釈する。そして、メッセージ処理部２１４は、解釈したＳＩＰメッセージの内容のうち必要な情報をアプリケーション部２１５に通知する。

さらに、本実施の形態のメッセージ処理部２１４は、ＳＩＰプロキシ１００のメッセージ処理部１１４と同様に、拡張したＳＩＰプロトコルフォーマットに従って、ＳＩＰメッセージのヘッダを構成する機能をさらに有する。このため、メッセージ処理部２１４は、ＳＩＰプロキシ１００のメッセージ処理部１１４内の追加部１１４ａと同様の機能を有する追加部２１４ａを備えている。

アプリケーション部２１５は、ＩＰ電話やテキストメッセージサービスなどのＳＩＰアプリケーションを実行するものである。アプリケーション部２１５は、例えば、図示しない表示装置などのユーザインターフェースを介してユーザに当該ＳＩＰアプリケーションの各種機能を提供する。

次に、本実施の形態を実現するために拡張されたＳＩＰプロトコルフォーマットの一例について、図８〜図１３を用いて説明する。

なお、図８〜図１０は、ＳＩＰ端末２００ａから、ＳＩＰプロキシ１００ａおよびＳＩＰプロキシ１００ｂを介して、ＳＩＰ端末２００ｂに送信および転送される各ＳＩＰ Ｉｎｖｉｔｅリクエストの一例である。また、図１１〜図１３は、当該ＳＩＰ Ｉｎｖｉｔｅリクエストに対する応答であって、ＳＩＰ端末２００ｂから、ＳＩＰプロキシ１００ｂおよびＳＩＰプロキシ１００ａを介して、ＳＩＰ端末２００ａに送信および転送される各ＳＩＰ Ｉｎｖｉｔｅレスポンスの一例である。

このように、以下ではＳＩＰ Ｉｎｖｉｔｅリクエストおよびレスポンスを例に説明するが、拡張すべきＳＩＰメッセージはこれに限られるものではない。

まず、拡張したＳＩＰメッセージは、本実施の形態の拡張機能を扱うＳＩＰメッセージであることをＳＩＰエンティティに識別させるための値を含む。これは例えば、ＳＩＰメッセージの「Require」ヘッダおよび「Proxy-Require」ヘッダに、本拡張機能を表す識別子として、「CONN-STAT」オプションタグを定義して含めることで実現可能である。

ＳＩＰメッセージを受信したＳＩＰエンティティは、「Require」ヘッダまたは「Proxy-Require」ヘッダに、「CONN-STAT」タグが含まれている場合、そのＳＩＰメッセージの送信元であるＳＩＰエンティティが、本拡張機能を利用していることを識別する。また、本拡張機能に対応していない従来のＳＩＰエンティティは、識別不可能な値が「Require」ヘッダまたは「Proxy-Require」ヘッダに含まれていることを検出すると、理解できない拡張機能を受け取った旨のＳＩＰレスポンスメッセージをＳＩＰプロトコル仕様に従って作成し、送信元のＳＩＰエンティティに対して送信する。

さらに、拡張したＳＩＰメッセージは、送信元のＳＩＰ端末２００が、当該ＳＩＰメッセージの交換に伴って確立させるＴＬＳコネクションに対して要求する維持条件を、当該ＳＩＰメッセージが経由する全てのＳＩＰプロキシ１００および送信先のＳＩＰ端末２００に対して通知するための変数を含む。

これは例えば、ＳＩＰメッセージの「Request-URI」および「To」ヘッダフィールドのＳＩＰ−ＵＲＩに、ＴＬＳコネクションの維持条件要求を記述するパラメタを定義して付加することで実現可能である。例えば、付加するパラメタとして、「conn-stat-req」を定義し、その値として、ＴＬＳコネクションを維持する条件を記述する。

例えば、５００のＳＩＰメッセージを転送する間、ＴＬＳコネクションを維持することを要求する場合は、「conn-stat-req=cont 500 Messages」のような形式で条件を記述できる。また、例えば、次にＳＩＰ ＢＹＥメッセージを転送するまでＴＬＳコネクション維持することを要求する場合は、「conn-stat-req=cont until BYE」のように条件を記述できる。また、例えば、３６００秒間、ＴＬＳコネクションを維持することを要求する場合は、「conn-stat-req=cont 3600 sec.」のように条件を記述することができる。

ＳＩＰメッセージを受信したＳＩＰエンティティは、指定されたパラメタ「conn-stat-req」の値を参照することで、このＳＩＰメッセージを送信したＳＩＰ端末２００が、当該ＳＩＰメッセージを転送するために利用するＴＬＳコネクションの維持条件に関してどのような要求を通知しているかを識別することができる。

図８は、ＳＩＰ端末２００ａからＳＩＰプロキシ１００ａに送信されるＳＩＰ Ｉｎｖｉｔｅリクエストの一例を示す説明図である。同図に示すように、拡張されたＳＩＰ Ｉｎｖｉｔｅリクエストには、維持条件要求８０１、８０２（conn-stat-req=cont 500 Messages）が付加されている。また、本拡張機能を含むことを表す識別子として、「Require」ヘッダおよび「Proxy-Require」ヘッダに、それぞれオプションタグ８０３（CONN-STAT）およびオプションタグ８０４（CONN-STAT）が付加されている。

以上は、送信元のＳＩＰ端末２００が作成して送信するＳＩＰメッセージの拡張を表している。これに加え、拡張したＳＩＰメッセージは、ＳＩＰメッセージの中継を行う複数のＳＩＰプロキシ１００や送信先のＳＩＰ端末２００が、送信元のＳＩＰ端末２００が要求したＴＬＳコネクション維持条件に対する応答状況を、転送するその他の複数のＳＩＰエンティティに対して通知するための値を含む。維持条件要求に対する応答状況とは、当該要求を元に判断した、許可できる維持条件や、当該要求を受入れられないことを表す情報（拒絶情報）を意味する。

例えば、応答状況を記述するためのヘッダとして、「Conn-cont」ヘッダを定義してＳＩＰメッセージに含めることで実現可能である。記述の方法としては、そのＳＩＰエンティティのＦＱＤＮ（Fully Qualified Domain Name）と、利用しているトランスポートの種別（ＴＬＳなど）と、応答状況とを、ＳＩＰエンティティごとに記述する方法などを用いることができる。

例えば、ＳＩＰメッセージ送信元の維持条件要求の通りにＴＬＳコネクションを維持することを許可する場合は、「Conn-cont:SIP/2.0/TLS proxyA.example.com cont ok」のように記述することができる。なお、「ok」の代わりに、要求と同じ維持条件を記述するように構成してもよい。

また、例えば、ＳＩＰメッセージ送信元の維持条件要求の通りにはＴＬＳコネクションの維持ができないが、記述した別の条件でＴＬＳコネクションを維持することを許可する場合は、「Conn-cont: SIP/2.0/TLS proxyB.example.com cont 400 Messages」のように記述することができる。この例は、維持条件要求は「cont 500 Messages」であったが、維持条件を厳しくして（４００のＳＩＰメッセージを転送する間、ＴＬＳコネクションを維持する）許可する場合を表している。

また、例えば、ＳＩＰメッセージ送信元の維持条件要求を許可できない場合には、「Conn-cont:SIP/2.0/TLS procyC.example.com cont ng」などのような形式の拒絶情報を記述することができる。

図９は、ＳＩＰプロキシ１００ａからＳＩＰプロキシ１００ｂに転送されるＳＩＰ Ｉｎｖｉｔｅリクエストの一例を示す説明図である。同図に示すように、メッセージを転送する場合、拡張されたＳＩＰ Ｉｎｖｉｔｅリクエストには、ＳＩＰプロキシ１００ｂの応答状況を記述するための「Conn-cont」ヘッダとその値を含む行９０１が追加されている。

図１０は、ＳＩＰプロキシ１００ｂから送信先であるＳＩＰ端末２００ｂに転送されるＳＩＰ Ｉｎｖｉｔｅリクエストの一例を示す説明図である。同図に示すように、拡張されたＳＩＰ Ｉｎｖｉｔｅリクエストには、さらにＳＩＰプロキシ１００ｂの応答状況を記述するための「Conn-cont」ヘッダとその値を含む行１００１が追加されている。このように、拡張されたＳＩＰメッセージでは、メッセージが転送されるたびに転送するＳＩＰエンティティの応答状況を記述する情報が付加される。

図１１は、図１０のようなＳＩＰ Ｉｎｖｉｔｅリクエストを受信したＳＩＰ端末２００ｂが応答メッセージとして作成し、ＳＩＰプロキシ１００ｂに送信したＳＩＰ Ｉｎｖｉｔｅレスポンスの一例を示す説明図である。図１１に示すように、拡張されたＳＩＰ Ｉｎｖｉｔｅレスポンスには、ＳＩＰ Ｉｎｖｉｔｅリクエストを中継した各ＳＩＰプロキシ１００の応答状況１１０１と、ＳＩＰ端末２００ｂが自装置のリソース使用状況を元に判断して追加した応答状況１１０２とが含まれる。

図１２は、ＳＩＰプロキシ１００ｂからＳＩＰプロキシ１００ａに転送されるＳＩＰ Ｉｎｖｉｔｅレスポンスの一例を示す説明図である。同図に示すように、レスポンスとして転送されるＳＩＰメッセージには、原則として新たな「Conn-cont」ヘッダは追加されない。ただし、送信元のＳＩＰ端末２００ｂの応答状況１２０１を参照してさらに自装置が許可する維持条件を変更して応答状況１２０２に設定する場合がある。

図１３は、ＳＩＰプロキシ１００ａからＳＩＰ端末２００ａに転送されるＳＩＰ Ｉｎｖｉｔｅレスポンスの一例を示す説明図である。この場合も図１２と同様に、転送元のＳＩＰエンティティの応答状況１３０１を参照して変更された応答状況１３０２が設定される場合がある。

次に、このように構成された本実施の形態にかかるＳＩＰプロキシ１００によるメッセージ送受信処理について図１４を用いて説明する。

なお、以下では、ＳＩＰアプリケーションとしてテキストメッセージサービスが実行され、ＳＩＰプロキシ１００ａおよび１００ｂを介して、ＳＩＰ端末２００ａがＳＩＰ端末２００ｂとの間で５００回、ＳＩＰメッセージを交換する場合を例に説明する。すなわち、この例では、ＳＩＰ端末２００ａは、ＳＩＰメッセージを５００回転送するまで全てのＴＬＳコネクションを維持することをＴＬＳコネクション維持条件の要求として含むＳＩＰメッセージを送信する。

また、以下で、ＳＩＰ端末２００ａ、ＳＩＰプロキシ１００ａ、ＳＩＰプロキシ１００ｂ、およびＳＩＰ端末２００ｂのＦＱＤＮを、それぞれ「termA.example.com」、「proxyA.example.com」、「proxyB.example.com」、および「termB.example.com」とする。また、ＳＩＰ端末２００ａを利用しているユーザのＳＩＰ ＵＲＩ（ＡｏＲ（Address of Record））を、「[email protected]」、コンタクトアドレスを「[email protected]」とする。さらに、ＳＩＰ端末２００ｂを利用しているユーザのＳＩＰ ＵＲＩを「[email protected]」、コンタクトアドレスを「[email protected]」とする。

図１４は、本実施の形態におけるメッセージ送受信処理の全体の流れを示すフローチャートである。なお、同図では、メッセージ送受信処理で各ＳＩＰエンティティが実行する処理の概要のみを示し、詳細については図１５以降で説明する。

まず、ＳＩＰ端末２００ａが、ＳＩＰアプリケーションの実行にともないＳＩＰ端末２００ａがＳＩＰ端末２００ｂに送信するＳＩＰメッセージを生成して送信するリクエスト送信処理を実行する（ステップＳ１４０１）。

次に、ＳＩＰプロキシ１００ａが、ＳＩＰ端末２００ａが送信したリクエストをＳＩＰプロキシ１００ｂに転送するリクエスト転送処理を実行する（ステップＳ１４０２）。

次に、ＳＩＰプロキシ１００ｂが、ＳＩＰプロキシ１００ａから受信したリクエストをさらにＳＩＰ端末２００ｂに転送するリクエスト転送処理を実行する（ステップＳ１４０３）。なお、ステップＳ１４０２とステップＳ１４０３のリクエスト転送処理の内容は、送信元と送信先のＳＩＰエンティティが異なるのみで基本的な機能は同様である。

次に、ＳＩＰ端末２００ｂが、ＳＩＰプロキシ１００ｂからリクエストを受信し、受信したリクエストに対するレスポンスとなるＳＩＰメッセージを作成してＳＩＰプロキシ１００ｂに送信するレスポンス送信処理を実行する（ステップＳ１４０４）。

次に、ＳＩＰプロキシ１００ｂが、ＳＩＰ端末２００ｂが送信したレスポンスをＳＩＰプロキシ１００ａに転送するレスポンス転送処理を実行する（ステップＳ１４０５）。

次に、ＳＩＰプロキシ１００ａが、ＳＩＰプロキシ１００ｂから受信したレスポンスをさらにＳＩＰ端末２００ａに転送するレスポンス転送処理を実行する（ステップＳ１４０６）。なお、ステップＳ１４０５とステップＳ１４０６のレスポンス転送処理の内容は、送信元と送信先のＳＩＰエンティティが異なるのみで基本的な機能は同様である。

最後に、ＳＩＰ端末２００ａが、ＳＩＰプロキシ１００ａからレスポンスを受信するレスポンス受信処理を実行し（ステップＳ１４０７）、メッセージ送受信処理を終了する。

後述するように、このメッセージ送受信処理の間に、拡張したＳＩＰメッセージを用いてＴＬＳコネクションの維持条件を順次転送するため、各ＳＩＰエンティティは転送された維持条件にしたがいＴＬＳコネクションを維持することができる。すなわち、送信元のＳＩＰ端末２００ａから維持条件を通知して、ＳＩＰ台形通信モデルのＳＩＰエンティティ間のすべての経路のコネクションを維持することが可能となる。

次に、ＳＩＰ端末２００ａによって実行されるステップＳ１４０１のリクエスト送信処理の詳細について説明する。図１５は、リクエスト送信処理の全体の流れを示すフローチャートである。

まず、アプリケーション部２１５が、テキストメッセージサービスのアプリケーションを実行し、通信相手であるＳＩＰ端末２００ｂに送信するメッセージとして、コネクション維持条件の要求を含むリクエストの作成および送信をメッセージ処理部２１４に対して依頼する（ステップＳ１５０１）。

具体的には、アプリケーション部２１５は、ユーザインターフェースによる入力情報等を参照し、メッセージ処理部２１４に対して、ＳＩＰ ＵＲＩが「[email protected]」であるユーザに宛てたＳＩＰメッセージの作成を依頼する。なお、以下では、ＳＩＰ端末２００ａからＳＩＰ端末２００ｂへ送信するＳＩＰメッセージをリクエストと呼ぶ場合がある。また、このとき、アプリケーション部２１５は、ＳＩＰメッセージを５００回転送するまでＴＬＳコネクションを維持する条件を要求する。

次に、メッセージ処理部２１４が、依頼された維持条件の要求を含むリクエストを生成する（ステップＳ１５０２）。具体的には、メッセージ処理部２１４は、まずＳＩＰのプロトコル仕様の通りに、ＳＩＰメッセージを構成する。ここで、メッセージ処理部２１４は、ＳＩＰメッセージの送信先がＳＩＰプロキシ１００ａ（proxyA.example.com）であると決定する。

そして、メッセージ処理部２１４は、拡張機能を指定する情報として、リクエストの「Require」ヘッダおよび「Proxy-Require」ヘッダに「CONN-STAT」オプションタグを付加する。また、メッセージ処理部２１４は、「Request-URI」および「To」ヘッダフィールドのＳＩＰ−ＵＲＩに、維持条件要求を指定した「conn-stat-req」オプションパラメタを記述する。

例えば、メッセージ処理部２１４は、「INVITE sips:[email protected] ;conn-stat-req= cont 500 Messages SIP/2.0;」などの維持条件要求を指定する。これにより、例えば、図８に示すようなリクエストが生成される。

次に、決定部２１２が、リソース管理部１１１が管理する、メモリ使用量などの自装置上の現在のリソースの使用状況を取得する（ステップＳ１５０３）。そして、決定部２１２は、取得したリソース使用状況から、依頼されたコネクション維持条件を満たすことができるか否かを判断する（ステップＳ１５０４）。例えば、決定部２１２は、予め求められたＴＬＳコネクション維持に必要なメモリ量が、現在の空きメモリ量より大きい場合に、維持条件を満たすことができないと判断する。

コネクション維持条件を満たすことができないと判断された場合は（ステップＳ１５０４：ＮＯ）、メッセージ処理部２１４は、生成されたリクエストからコネクション維持条件の要求を削除する（ステップＳ１５０５）。具体的には、メッセージ処理部２１４は、ヘッダに追加した拡張用の「CONN-STAT」オプションタグや、維持条件要求の指定である「conn-stat-req」パラメタを削除する。

維持条件の要求を削除した後（ステップＳ１５０５）、または、ステップＳ１５０４でコネクション維持条件を満たすことができると判断された場合は（ステップＳ１５０４：ＹＥＳ）、送信部１０２が、コネクション管理テーブル１２４を参照し、ＳＩＰプロキシ１００ａとの間でＴＬＳコネクションが存在するか否かを判断する（ステップＳ１５０６）。

ＴＬＳコネクションが存在しない場合は（ステップＳ１５０６：ＮＯ）、コネクション管理部１１３が、ＳＩＰプロキシ１００ａとの間のＴＬＳコネクションを新規作成する（ステップＳ１５０７）。具体的には、コネクション管理部１１３は、送信部１０２からパケットの送信先、トランザクションＩＤ、ダイアログＩＤの通知を受け、通知された情報から新規にＴＬＳコネクションを作成する。なお、コネクション管理部１１３は、ＴＬＳコネクションを作成したとき、パケットの送信先（接続先）、トランザクションＩＤ、およびダイアログＩＤ等を対応づけてコネクション管理テーブル１２４に登録する。

ＴＬＳコネクションを作成後、または、ステップＳ１５０６でＴＬＳコネクションが存在すると判断された場合（ステップＳ１５０６：ＹＥＳ）、送信部１０２は、当該ＴＬＳコネクションを用いて、ステップＳ１５０２で生成されたリクエストをＳＩＰプロキシ１００ａに対して送信する（ステップＳ１５０８）。具体的には、送信部１０２は、メッセージ処理部２１４が生成したリクエストからネットワークに送信可能なパケットを構築し、構築したパケットをＴＬＳコネクションを用いてＳＩＰプロキシ１００ａに送信する。

次に、ＳＩＰプロキシ１００ａによって実行されるステップＳ１４０２のリクエスト転送処理の詳細について説明する。図１６は、リクエスト転送処理の全体の流れを示すフローチャートである。

まず、受信部１０１が、ＳＩＰ端末２００ａから送信されたパケットを受信してリクエストを構築し、メッセージ処理部１１４に送出する（ステップＳ１６０１）。

次に、メッセージ処理部１１４が、ＳＩＰプロトコル仕様に従って、受信したリクエストのヘッダを更新し、転送するリクエストを生成する（ステップＳ１６０２）ここで、メッセージ処理部１１４は、ＳＩＰメッセージの転送先がＳＩＰプロキシ１００ｂ（proxyB.example.com）であると決定する。

また、このとき、メッセージ処理部１１４は、「Proxy-Require」ヘッダに「CONN-STAT」オプションタグが付加されていることより、このＳＩＰメッセージの送信元が本実施の形態の拡張機能に対応していることを識別する。なお、拡張機能に対応していないＳＩＰプロキシが本ＳＩＰメッセージを受信したときは、対応不可能な拡張を受け取ったことを示す情報（例えば「420 Bad Extension」）を含んだレスポンスをＳＩＰ端末２００ａに返信し、ＳＩＰメッセージの転送は行わない。

次に、メッセージ処理部１１４は、受信したリクエストから維持条件の要求を取得する（ステップＳ１６０３）。具体的には、メッセージ処理部１１４は、受信したリクエストの「conn-stat-req」パラメタの値を取得する。上述の例では、メッセージ処理部１１４は、ＳＩＰ端末２００ａが、５００回のＳＩＰメッセージを送受信する間ＴＬＳコネクションを維持する要求を意味する「conn-stat-req= cont 500 Messages」を取得する。

次に、決定部１１２が、リソース管理部１１１が管理する、メモリ使用量などの自装置上の現在のリソースの使用状況を取得する（ステップＳ１６０４）。そして、決定部１１２は、取得したリソース使用状況から、要求されたコネクション維持条件を満たすことができるか否かを判断する（ステップＳ１６０５）。

なお、ＴＬＳコネクションを維持できるか否かの判断では、転送元であるＳＩＰ端末２００ａとの間のＴＬＳコネクションと、転送先であるＳＩＰプロキシ１００ｂとの間のＴＬＳコネクションの双方を維持できるか否かをもって判断する必要がある。

ただし、ＳＩＰプロキシ１００ａとＳＩＰプロキシ１００ｂとの間で単独のＴＬＳコネクションを用いて全てのＳＩＰメッセージを転送している場合、そのＴＬＳコネクションに関しては、維持条件要求は常に満たされると判断される。

また、維持条件を満たすことができる場合には、要求された維持条件そのものを許可できる場合と、要求された維持条件より厳しい条件であればＴＬＳコネクションの維持を許可できる場合とを含む。

コネクション維持条件を満たすことができる場合は（ステップＳ１６０５：ＹＥＳ）、決定部１１２は、許可できる維持条件を決定する（ステップＳ１６０６）。そして、追加部１１４ａが、決定された維持条件をリクエストのヘッダに追加する（ステップＳ１６０７）。例えば、要求された条件が「conn-stat-req= cont 500 Messages」であり、この条件のとおりに維持できると判断した場合は、追加部１１４ａは、「Conn-cont: SIP/2.0/TLS proxyA.example.com cont 500 Messages」のような「Conn-cont」ヘッダを追加する。

ステップＳ１６０５で、コネクション維持条件を満たすことができないと判断された場合は（ステップＳ１６０５：ＮＯ）、追加部１１４ａは、要求された維持条件を拒絶することを表す拒絶情報をリクエストのヘッダに追加する（ステップＳ１６０８）。例えば、追加部１１４ａは、「Conn-cont: SIP/2.0/TLS proxyA.example.com cont ng」のような形式で記述された拒絶情報を追加する。

追加部１１４ａが許可する維持条件または拒絶情報を追加した後、メッセージ処理部１１４は、構築したリクエストを送信部１０２に送出する。

送信部１０２は、受け取ったリクエストから、ネットワークに送信可能なパケットを構築し、ＳＩＰプロキシ１００ｂに送信する（ステップＳ１６０９）。

この際、ＳＩＰプロキシ１００ｂとの間にＴＬＳコネクションが存在しない場合は、図１５のステップＳ１５０７と同様の方法で、コネクション管理部１１３により新規にＴＬＳコネクションを作成する。

なお、一般には、ＳＩＰプロキシ１００ａとＳＩＰプロキシ１００ｂとの間のＴＬＳコネクションはＳＩＰシステムを動作させる上で重要であるため、常に維持されて管理されることが多い。

ＳＩＰプロキシ１００ｂによって実行されるステップＳ１４０３のリクエスト転送処理は、原則として上記図１６のフローチャートと同様であるが、以下の点が相違する。

まず、パケットの受信元がＳＩＰプロキシ１００ａであることと、パケットの送信先がＳＩＰ端末２００ｂであることが相違する。

また、決定部１１２が、ＴＬＳコネクションの維持条件要求を許可するか否かを判断するとき、（Ａ）リソース管理部１１１が管理するリソース使用状況、（Ｂ）「conn-stat-req」パラメタの値の他に、（Ｃ）ＳＩＰプロキシ１００ａが付加した「Conn-cont」ヘッダ情報も加味して判断できることが相違する。

（Ｃ）の情報により、決定部１１２は、自装置より送信元ＳＩＰ端末側（ここではＳＩＰ端末２００ａ）に存在するＳＩＰエンティティ（ここではＳＩＰプロキシ１００ａのみ）が、「conn-stat-req」パラメタに示された送信元ＳＩＰ端末２００の維持条件要求の通りにＴＬＳコネクションを維持すると回答したか否かを判断可能となる。すなわち、決定部１１２は、ＳＩＰメッセージが経由した全てのＴＬＳコネクションが維持される可能性があるか否かの判断が可能となる。

次に、ＳＩＰ端末２００ｂによって実行されるステップＳ１４０４のレスポンス送信処理の詳細について説明する。図１７は、レスポンス送信処理の全体の流れを示すフローチャートである。

まず、受信部１０１は、ＳＩＰプロキシ１００ｂから送信されたＳＩＰメッセージに対応するパケットを受信してリクエストを構築し、メッセージ処理部２１４に送出する（ステップＳ１７０１）。

メッセージ処理部２１４は、ＳＩＰプロトコル仕様に従って、受信したＳＩＰメッセージを解釈し、解釈結果に応じて、アプリケーション部２１５に対してテキストメッセージ情報を提示する。そして、アプリケーション部２１５は、受信したリクエストに応じて、ユーザに対するアプリケーションを実行する（ステップＳ１７０２）。

次に、アプリケーション部２１５の依頼に応じて、メッセージ処理部２１４が、ＳＩＰ端末２００ａに返信するＳＩＰメッセージであるレスポンスを生成する（ステップＳ１７０３）。このとき、メッセージ処理部２１４は、受信したリクエストに含まれている全ての「Conn-cont」ヘッダをそのまま含むレスポンスを生成する。

次に、メッセージ処理部２１４は、受信したリクエストからＴＬＳコネクションの維持条件の要求を取得する（ステップＳ１７０４）。具体的には、まずメッセージ処理部２１４は、「Require」ヘッダに「CONN-STAT」オプションタグが付加されていることより、このＳＩＰメッセージの送信元が、本実施の形態の拡張機能に対応していることを識別する。

なお、拡張機能に対応していないＳＩＰ端末が本ＳＩＰメッセージを受信したときは、対応不可能な拡張を受け取ったことを示す情報（例えば「420 Bad Extension」）を含んだレスポンスをＳＩＰ端末２００ａに返信し、ＳＩＰメッセージに関する処理は行わない。

そして、メッセージ処理部２１４は、「conn-stat-req」パラメタの値から、要求されたＴＬＳコネクションの維持条件を取得する。上述の例では、メッセージ処理部２１４は、ＳＩＰ端末２００ａが、５００回のＳＩＰメッセージを送受信する間ＴＬＳコネクションを維持する要求を意味する「conn-stat-req= cont 500 Messages」を取得する。

また、ＳＩＰ端末２００ｂは、当該ＳＩＰメッセージを転送した他の全てのＳＩＰエンティティの応答状況を「Conn-cont」ヘッダの値から取得する。

次に、決定部２１２が、リソース管理部１１１が管理する、メモリ使用量などの自装置上の現在のリソースの使用状況を取得する（ステップＳ１７０５）。そして、決定部２１２は、取得したリソース使用状況から、要求されたコネクション維持条件を満たすことができるか否かを判断する（ステップＳ１７０６）。このとき、決定部２１２は、他のＳＩＰエンティティの応答状況である「Conn-cont」ヘッダの値も加味して維持条件の認否を判断することができる。

コネクション維持条件を満たすことができる場合は（ステップＳ１７０６：ＹＥＳ）、決定部２１２は、許可できる維持条件を決定する（ステップＳ１７０７）。そして、追加部２１４ａが、決定された維持条件をレスポンスのヘッダに追加する（ステップＳ１７０８）。

次に、決定部２１２は、決定した維持条件を対応する条件テーブルに保存する（ステップＳ１７０９）。例えば、「conn-stat-req= cont 500 Messages」のようにメッセージ数で維持条件を決定した場合は、決定部２１２は、メッセージ数条件テーブル１２３に、接続先としてＳＩＰプロキシ１００ｂのアドレスおよびポート番号を保存し、ＳＩＰメッセージ数条件として「500 Messages」を保存する。

さらに、維持部１１３ａは、決定された維持条件によるＴＬＳコネクションの維持を開始する（ステップＳ１７１０）。

ステップＳ１７０６で、コネクション維持条件を満たすことができないと判断された場合は（ステップＳ１７０６：ＮＯ）、追加部２１４ａは、要求された維持条件を拒絶することを表す拒絶情報をレスポンスのヘッダに追加する（ステップＳ１７１１）。

追加部２１４ａが許可する維持条件または拒絶情報を追加した後、メッセージ処理部２１４は、構築したレスポンスを送信部１０２に送出する。

送信部１０２は、受け取ったレスポンスから、ネットワークに送信可能なパケットを構築し、ＳＩＰプロキシ１００ｂに送信する（ステップＳ１７１２）。

次に、ＳＩＰプロキシ１００ｂによって実行されるステップＳ１４０５のレスポンス転送処理の詳細について説明する。図１８は、レスポンス転送処理の全体の流れを示すフローチャートである。

まず、受信部１０１が、ＳＩＰ端末２００ｂから送信されたパケットを受信してレスポンスを構築し、メッセージ処理部１１４に送出する（ステップＳ１８０１）。

次に、メッセージ処理部１１４が、ＳＩＰプロトコル仕様に従って、受信したリクエストのヘッダを更新し、転送するレスポンスを生成する（ステップＳ１８０２）ここで、メッセージ処理部１１４は、ＳＩＰメッセージの転送先がＳＩＰプロキシ１００ａ（proxyA.example.com）であると決定する。

次に、メッセージ処理部１１４は、受信したレスポンスから維持条件の要求を取得する（ステップＳ１８０３）。具体的には、メッセージ処理部１１４は、受信したレスポンスの「conn-stat-req」パラメタの値、および「Conn-cont」ヘッダの値を取得する。この段階では、ＳＩＰプロキシ１００ｂは、取得した「Conn-cont」ヘッダの値から、ＳＩＰメッセージの転送に利用される全てのＴＬＳコネクションの維持に関する応答状況を識別することができる。

次に、決定部１１２は、取得した維持条件の要求および他のＳＩＰエンティティの応答状況から、維持条件を変更するか否かを判断する（ステップＳ１８０４）。すなわち、決定部１１２は、リクエスト転送時に決定した維持条件を、ＳＩＰ端末２００ｂの応答内容に合わせる形で変更してもよい。

例えば、リクエスト転送時には１２００秒間維持する時間条件を決定したが、ＳＩＰ端末２００ｂが３６００秒間維持する時間条件を応答した場合、ＳＩＰ端末２００ｂに合わせて３６００秒間維持する時間条件に変更してもよい。同様に、リクエスト転送時には３６００秒間維持する時間条件を決定したが、ＳＩＰ端末２００ｂが１２００秒間維持する時間条件を応答した場合、ＳＩＰ端末２００ｂに合わせて１２００秒間維持する時間条件に変更してもよい。

維持条件を変更すると判断した場合は（ステップＳ１８０４：ＹＥＳ）、決定部１１２は、維持条件を変更する（ステップＳ１８０５）。そして、追加部１１４ａが、変更した維持条件をレスポンスのヘッダに追加する（ステップＳ１８０６）。

維持条件を変更しないと判断された場合（ステップＳ１８０４：ＹＥＳ）、または追加部１１４ａが維持条件を追加した後（ステップＳ１８０６）、決定部１１２は、決定した維持条件を対応する条件テーブルに保存する（ステップＳ１８０７）。さらに、維持部１１３ａは、決定された維持条件によるＴＬＳコネクションの維持を開始する（ステップＳ１８０８）。ここで、維持条件として「Conn-cont」ヘッダに書かれた内容と実際のＴＬＳコネクションの維持期間が一致することとなる。

次に、送信部１０２は、メッセージ処理部１１４から受け取ったレスポンスから、ネットワークに送信可能なパケットを構築し、ＳＩＰプロキシ１００ａに送信する（ステップＳ１８０９）。

ＳＩＰプロキシ１００ａによって実行されるステップＳ１４０６のレスポンス転送処理は、原則として上記図１８のフローチャートと同様であるが、以下の点が相違する。

まず、パケットの受信元がＳＩＰプロキシ１００ｂであることと、パケットの送信先がＳＩＰ端末２００ａであることが相違する。

また、決定部１１２が、維持条件の変更を判断するとき、ＳＩＰプロキシ１００ａが変更した後の「Conn-cont」ヘッダ情報も加味して判断できることが相違する。

すなわち、決定部１１２は、自装置よりＳＩＰ端末側（ここではＳＩＰ端末２００ｂ）のＳＩＰエンティティ（ここではＳＩＰプロキシ１００ｂ、ＳＩＰ端末２００ｂ）が実際に維持しているＴＬＳコネクションの維持期間を参照して、自装置の実際のＴＬＳ維持期間を更新することができる。

次に、ＳＩＰ端末２００ａによって実行されるステップＳ１４０７のレスポンス受信処理の詳細について説明する。図１９は、レスポンス受信処理の全体の流れを示すフローチャートである。

まず、受信部１０１が、ＳＩＰプロキシ１００ａから送信されたパケットを受信してレスポンスを構築し、メッセージ処理部２１４に送出する（ステップＳ１９０１）。

次に、メッセージ処理部２１４は、ＳＩＰプロトコル仕様に従って受信したレスポンスを解釈し、維持条件の要求を取得する（ステップＳ１９０２）。具体的には、メッセージ処理部２１４は、受信したレスポンスの「Conn-cont」ヘッダの値を取得する。これにより、ＳＩＰ端末２００ａは、ＳＩＰメッセージの転送に利用される全てのＴＬＳコネクションの維持に関する応答状況を識別することができる。

次に、決定部２１２は、取得した他のＳＩＰエンティティの応答状況から、維持条件を変更するか否かを判断する（ステップＳ１９０３）。

例えば、自装置より宛先に近いＳＩＰエンティティ（ここではＳＩＰ端末２００ｂ、ＳＩＰプロキシ１００ｂ、ＳＩＰプロキシ１００ａ）のいずれかが維持要求を満たさないと回答している場合、ＳＩＰ端末２００ａ自身も維持要求を満たさないように維持条件を変更すると判断するように構成してもよい。

具体的には、例えば、ＳＩＰ端末２００ｂとＳＩＰプロキシ１００ｂの間のＴＬＳコネクション、およびＳＩＰプロキシ１００ｂとＳＩＰプロキシ１００ａの間のＴＬＳコネクションの２つのＴＬＳコネクションについて、共に維持条件要求が受け入れられた場合に限って、ＳＩＰプロキシ１００ａとＳＩＰ端末２００ａとの間のＴＬＳコネクションを維持するという判断が可能である。

また、別の具体例としては、上記２つのＴＬＳコネクションについて、いずれか１つ以上の維持条件要求が受け入れられなかった場合でも、それに関わらず、ＳＩＰプロキシ１００ａとＳＩＰ端末２００ａとの間のＴＬＳコネクションを維持するという判断も可能である。

維持条件を変更すると判断した場合は（ステップＳ１９０３：ＹＥＳ）、決定部２１２は、維持条件を変更する（ステップＳ１９０４）。

維持条件を変更しないと判断した場合（ステップＳ１９０３：ＹＥＳ）、決定部２１２は、決定した維持条件を対応する条件テーブルに保存する（ステップＳ１９０５）。さらに、維持部１１３ａは、決定された維持条件によるＴＬＳコネクションの維持を開始する（ステップＳ１９０６）。

これにより、ＳＩＰメッセージに含まれる「Conn-cont」ヘッダの示すとおりに、ＴＬＳコネクションの維持要求が満たされることになる。ただし、あるＳＩＰエンティティのリソース管理部１１１が、計算リソースが逼迫してＴＬＳコネクションを維持できなくなったと判断した場合、コネクション管理テーブル１２４で保持するＴＬＳコネクションのうちいずれかが破棄される可能性もある。

その後、必要な場合は、レスポンスに含まれるデータがアプリケーション部２１５に通知され、アプリケーション部２１５が、レスポンスに応じた処理を実行する（ステップＳ１９０７）。

次に、このように構成された本実施の形態にかかる各ＳＩＰエンティティが実行するコネクション管理処理について図２０を用いて説明する。図２０はコネクション管理処理の全体の流れを示すフローチャートである。

なお、コネクション管理処理とは、維持条件要求が受け入れられたＴＬＳコネクションを利用してＳＩＰメッセージが転送される場合に、各ＳＩＰエンティティが維持条件を判定してＴＬＳコネクションの維持または破棄を管理する処理をいう。なお、以下では、ＳＩＰ端末２００によるコネクション管理処理を例に説明するが、ＳＩＰプロキシ１００についても同様の流れでコネクション管理処理が実行される。

まず、ＳＩＰ端末２００の受信部１０１は受信したパケットをＳＩＰメッセージとして構成しメッセージ処理部２１４に送出する（ステップＳ２００１）。次に、メッセージ処理部２１４は、ＳＩＰプロトコル仕様および本実施の形態に記述された拡張仕様にしたがいＳＩＰメッセージを処理する。そして、メッセージ処理部２１４は、ＴＬＳコネクション維持条件に関する情報を決定部２１２に通知する（ステップＳ２００２）。

例えば、ＳＩＰメッセージ数条件によりＴＬＳコネクションを維持している場合、メッセージ処理部２１４は、転送したＳＩＰメッセージ数を決定部２１２に通知する。また、ＳＩＰメソッド条件により、ＴＬＳコネクションを維持している場合、メッセージ処理部２１４は、処理したＳＩＰメソッドを決定部２１２に通知する。また、時間条件によりＴＬＳコネクションを維持している場合、メッセージ処理部２１４は、経過時間を決定部２１２に通知する。なお、決定部２１２でタイマを保持し、ＴＬＳコネクション維持期間を判定するように構成してもよい。

通知を受けた決定部２１２は、各条件テーブルを参照して、維持条件を満たすか否かを判断する（ステップＳ２００３）。維持条件を満たさない場合は（ステップＳ２００３：ＮＯ）、決定部２１２は、コネクション管理部１１３に対して、ＴＬＳコネクションの破棄を通知する。そして、破棄部１１３ｂが、通知されたＴＬＳコネクションを破棄する（ステップＳ２００４）。ただし、そのＴＬＳコネクションを他のダイアログなどとも共有している場合、そのＴＬＳコネクションは維持される。例えば、ＳＩＰプロキシ１００ａとＳＩＰプロキシ１００ｂとの間で、単独のＴＬＳコネクションを用いて全てのＳＩＰメッセージを転送する場合が該当する。

維持条件を満たす場合は（ステップＳ２００３：ＹＥＳ）、ＴＬＳコネクションは破棄されずにコネクション管理処理を終了する。

以上のように、本実施の形態にかかるサーバ装置は、ＳＩＰ端末からコネクションの維持を要求する維持条件を含むメッセージを受信し、自装置のリソース使用状況から要求された維持条件を許可できるか否かを判断し、判断結果をさらにメッセージの中継先である外部のＳＩＰプロキシに転送することができる。そして、要求された維持条件に対する外部のＳＩＰプロキシおよび受信側のＳＩＰ端末の応答状況をさらに考慮して、維持条件の認否を決定し、コネクションを維持または破棄することができる。

このため、端末上のアプリケーションの要求に応じて、システム全体で適切なコネクションを維持することが可能となる。

次に、本実施の形態にかかるサーバ装置のハードウェア構成について説明する。図２１は、本実施の形態にかかるサーバ装置のハードウェア構成を示す説明図である。

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

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

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

また、本実施の形態のサーバプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。

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

以上のように、本発明にかかるコネクションを維持する装置、方法およびプログラムは、ＳＩＰ台形通信モデルのように端末間の通信を中継する通信システムにおける各装置間のコネクションを維持する装置、方法およびプログラムに適している。

本実施の形態にかかるサーバ装置を含む通信システム全体の構成を示すブロック図である。 ＳＩＰプロキシの詳細な構成を示すブロック図である。 メソッド条件テーブルのデータ構造の一例を示す説明図である。 時間条件テーブルのデータ構造の一例を示す説明図である。 メッセージ数条件テーブルのデータ構造の一例を示す説明図である。 コネクション管理テーブルのデータ構造の一例を示す説明図である。 ＳＩＰ端末の詳細な構成を示すブロック図である。 送信されるＳＩＰ Ｉｎｖｉｔｅリクエストの一例を示す説明図である。 転送されるＳＩＰ Ｉｎｖｉｔｅリクエストの一例を示す説明図である。 転送されるＳＩＰ Ｉｎｖｉｔｅリクエストの一例を示す説明図である。 送信されるＳＩＰ Ｉｎｖｉｔｅレスポンスの一例を示す説明図である。 転送されるＳＩＰ Ｉｎｖｉｔｅレスポンスの一例を示す説明図である。 転送されるＳＩＰ Ｉｎｖｉｔｅレスポンスの一例を示す説明図である。 本実施の形態におけるメッセージ送受信処理の全体の流れを示すフローチャートである。 リクエスト送信処理の全体の流れを示すフローチャートである。 リクエスト転送処理の全体の流れを示すフローチャートである。 レスポンス送信処理の全体の流れを示すフローチャートである。 レスポンス転送処理の全体の流れを示すフローチャートである。 レスポンス受信処理の全体の流れを示すフローチャートである。 コネクション管理処理の全体の流れを示すフローチャートである。 本実施の形態にかかるサーバ装置のハードウェア構成を示す説明図である。

符号の説明

５１ ＣＰＵ
５２ ＲＯＭ
５３ ＲＡＭ
５４ 通信Ｉ／Ｆ
６１ バス
１００ａ、１００ｂ プロキシ
１０１ 受信部
１０２ 送信部
１１１ リソース管理部
１１２ 決定部
１１３ コネクション管理部
１１３ａ 維持部
１１３ｂ 破棄部
１１４ メッセージ処理部
１１４ａ 追加部
１２０ 記憶部
１２１ メソッド条件テーブル
１２２ 時間条件テーブル
１２３ メッセージ数条件テーブル
１２４ コネクション管理テーブル
２００ａ、２００ｂ ＳＩＰ端末
２１２ 決定部
２１４ メッセージ処理部
２１４ａ 追加部
２１５ アプリケーション部
８０１、８０２ 維持条件要求
８０３、８０４ オプションタグ
９０１ 行
１００１ 行
１１０１、１１０２ 応答状況
１２０１、１２０２ 応答状況
１３０１、１３０２ 応答状況

Claims (17)

1. 第１端末から受信したメッセージを中継装置を介して第２端末に中継し、前記第２端末から送信されたメッセージを前記中継装置を介して受信して前記第１端末に中継するサーバ装置であって、
   リソースの使用状況を管理するリソース管理部と、
   前記第１端末と前記第２端末との間でメッセージを中継するためのコネクションを維持するための第１条件を含む第１メッセージを前記第１端末から受信する受信部と、
   受信した前記第１メッセージに含まれる前記第１条件と前記使用状況とに基づいて、前記コネクションを維持するために許可する第１コネクション維持条件を決定する決定部と
   前記第１メッセージに前記第１コネクション維持条件を追加する追加部と、
   前記第１コネクション維持条件が追加された前記第１メッセージを前記第２端末に中継するために、前記中継装置に送信する送信部と、
   決定された前記第１コネクション維持条件で前記コネクションを維持する維持部と、
   を備えたことを特徴とするサーバ装置。
2. 第１端末から中継装置を介して受信したメッセージを第２端末に中継し、前記第２端末から送信されたメッセージを受信して前記中継装置を介して前記第１端末に中継するサーバ装置であって、
   リソースの使用状況を管理するリソース管理部と、
   前記第１端末と前記第２端末との間でメッセージを中継するためのコネクションを維持するための第１条件を含む第１メッセージを前記中継装置から受信する受信部と、
   受信した前記第１メッセージに含まれる前記第１条件と前記使用状況とに基づいて、前記コネクションを維持するために許可するコネクション維持条件を決定する決定部と、
   前記第１メッセージに前記コネクション維持条件を追加する追加部と、
   前記コネクション維持条件が追加された前記第１メッセージを前記第２端末に送信する送信部と、
   決定された前記コネクション維持条件で前記コネクションを維持する維持部と、
   を備えたことを特徴とするサーバ装置。
3. 前記受信部は、さらに、前記第１メッセージに対する応答として前記第２端末から送信されたメッセージであって、前記コネクションを維持するために前記中継装置および前記第２端末の少なくとも一方が要求した第４条件を含む第３メッセージを前記中継装置から受信し、
   前記決定部は、さらに、受信した前記第３メッセージに含まれる前記第４条件に基づいて、前記コネクションを維持するために許可する前記第２コネクション維持条件を決定し、
   前記送信部は、前記第２コネクション維持条件を含む第２メッセージを前記第１端末に送信し、
   前記維持部は、前記第２コネクション維持条件で前記コネクションを維持すること、
   を特徴とする請求項１に記載のサーバ装置。
4. 前記決定部は、前記第１コネクション維持条件を前記第２コネクション維持条件として決定すること、
   を特徴とする請求項３に記載のサーバ装置。
5. 前記受信部は、さらに前記コネクションの維持を拒絶することを表す第１拒絶情報を含む前記第３メッセージを前記中継装置から受信し、
   前記決定部は、受信した前記第３メッセージに含まれる前記第１拒絶情報に基づいて、前記第２コネクション維持条件を決定すること、
   を特徴とする請求項３に記載のサーバ装置。
6. 前記決定部は、前記第３メッセージに前記第１拒絶情報が含まれる場合に、前記第１条件による前記コネクションの維持を拒絶することを決定し、前記第３メッセージに前記第１拒絶情報が含まれない場合に、前記第２コネクション維持条件を決定すること、
   を特徴とする請求項５に記載のサーバ装置。
7. 前記決定部は、受信した前記第１メッセージに含まれる前記第１条件と前記使用状況とに基づいて、前記第１条件による前記コネクションの維持を拒絶するか否かを判断し、拒絶しない場合に前記第１コネクション維持条件を決定し、
   前記追加部は、さらに、前記コネクションの維持を拒絶することが決定された場合に、前記第１メッセージに前記第１条件による前記コネクションの維持を拒絶することを表す第２拒絶情報を追加し、
   前記送信部は、さらに、前記第２拒絶情報を追加した前記第１メッセージを前記中継装置に送信すること、
   を特徴とする請求項１に記載のサーバ装置。
8. 前記受信部は、予め定められた第４メッセージを受信するまで前記コネクションを維持することを要求する前記第１条件を受信すること、
   を特徴とする請求項１に記載のサーバ装置。
9. 前記受信部は、予め定められた第１時間が経過するまで前記コネクションを維持することを要求する前記第１条件を受信すること、
   を特徴とする請求項１に記載のサーバ装置。
10. 前記受信部は、メッセージの送受信数が予め定められた第１閾値を超えるまで前記コネクションを維持することを要求する前記第１条件を受信すること、
    を特徴とする請求項１に記載のサーバ装置。
11. 前記決定部は、予め定められた第５メッセージを受信するまで前記コネクションを維持することを許可する前記第１コネクション維持条件を決定すること、
    を特徴とする請求項１に記載のサーバ装置。
12. 前記決定部は、予め定められた第２時間が経過するまで前記コネクションを維持することを許可する前記第１コネクション維持条件を決定すること、
    を特徴とする請求項１に記載のサーバ装置。
13. 前記決定部は、メッセージの送受信数が予め定められた第２閾値を超えるまで前記コネクションを維持することを許可する前記第１コネクション維持条件を決定すること、
    を特徴とする請求項１に記載のサーバ装置。
14. 前記受信部は、前記第１メッセージとして、ＳＩＰ（Session Initiation Protocol）により送受信されるメッセージであって、ＴＬＳ（Transport Layer Security）プロトコルによるＴＬＳコネクションを維持することを要求する前記第１条件をヘッダに含むＳＩＰメッセージを前記第１端末から受信し、
    前記追加部は、前記ＳＩＰメッセージの前記ヘッダに前記第１コネクション維持条件を追加すること、
    を特徴とする請求項１に記載のサーバ装置。
15. 第１端末から受信したメッセージを中継装置を介して第２端末に中継し、前記第２端末から送信されたメッセージを前記中継装置を介して受信して前記第１端末に中継するサーバ装置におけるコネクション維持方法であって、
    リソース管理部によって、リソースの使用状況を管理するリソース管理ステップと、
    受信部によって、前記第１端末と前記第２端末との間でメッセージを中継するためのコネクションを維持するための第１条件を含む第１メッセージを前記第１端末から受信する受信ステップと、
    決定部によって、受信した前記第１メッセージに含まれる前記第１条件と前記使用状況とに基づいて、前記コネクションを維持するために許可する第１コネクション維持条件を決定する決定ステップと、
    追加部によって、前記第１メッセージに前記第１コネクション維持条件を追加する追加ステップと、
    送信部によって、前記第１コネクション維持条件が追加された前記第１メッセージを前記第２端末に中継するために、前記中継装置に送信する送信ステップと、
    維持部によって、決定された前記第１コネクション維持条件で前記コネクションを維持する維持ステップと、を備えたことを特徴とするコネクション維持方法。
16. 第１端末から受信したメッセージを中継装置を介して第２端末に中継し、前記第２端末から送信されたメッセージを前記中継装置を介して受信して前記第１端末に中継するサーバ装置におけるコネクション維持プログラムであって、
    リソースの使用状況を管理するリソース管理手順と、
    前記第１端末と前記第２端末との間でメッセージを中継するためのコネクションを維持するための第１条件を含む第１メッセージを前記第１端末から受信する受信手順と、
    受信した前記第１メッセージに含まれる前記第１条件と前記使用状況とに基づいて、前記コネクションを維持するために許可する第１コネクション維持条件を決定する決定手順と、
    前記第１メッセージに前記第１コネクション維持条件を追加する追加手順と、
    前記第１コネクション維持条件が追加された前記第１メッセージを前記第２端末に中継するために、前記中継装置に送信する送信手順と、
    決定された前記第１コネクション維持条件で前記コネクションを維持する維持手順と、
    をコンピュータに実行させるコネクション維持プログラム。
17. 中継装置を介して外部端末と通信する端末装置であって、
    リソースの使用状況を管理するリソース管理部と、
    前記使用状況に基づいて、前記外部端末との間でメッセージを中継するためのコネクションを維持するために許可する第１コネクション維持条件を決定する決定部と、
    決定された前記第１コネクション維持条件を含む第１メッセージを前記中継装置に送信する送信部と、
    前記第１メッセージに対する応答として前記外部端末から送信されたメッセージであって、前記コネクションを維持するために前記外部端末および前記中継装置の少なくとも一方が要求した第２条件を含む第２メッセージを前記中継装置から受信する受信部と、を備え、
    前記決定部は、受信した前記第２条件に基づいて、さらに前記コネクションを維持するために許可する第２コネクション維持条件を決定すること、
    を備えたことを特徴とする端末装置。

Images