JP2010212825A - 通信システム、ｓｉｐサーバ、ｓｉｐ端末、及びセキュリティ通信方法 - Google Patents

Abstract

【課題】ＳＩＰサーバのリソース圧迫を回避し、ＳＩＰサーバからＳＩＰ端末へのＴＬＳセッション要求を送信可能とする。
【解決手段】ＳＩＰサーバ１１とＳＩＰ端末１２とがＩＰネットワーク１３経由で接続される通信システム１であって、ＳＩＰサーバからＳＩＰ端末へのＳＩＰリクエスト送信時、ＳＩＰサーバが、ＳＩＰ端末にＴＣＰコネクションを行うＳＩＰサーバ側コネクション管理部１１０と、ＳＩＰ端末がＳＩＰサーバとのＴＣＰコネクションの確立を契機にＳＩＰサーバへ動的にＴＬＳセッションを確立するＳＩＰ端末側コネクション管理部１２０とを備え、ＳＩＰサーバ側コネクション管理部１１０は、ＴＬＳセッションが確立したことを検知してＳＩＰ端末にＳＩＰリクエストを送信する。
【選択図】図４

Description

本発明は、ＩＥＴＦ ＲＦＣ３２６１で定義されているＳＩＰ（Session Initiation Protocol）を利用して通信を行う、通信システム、ＳＩＰサーバ、ＳＩＰ端末、及びセキュリティ通信方法に関する。

例えば、図７に示す通信システム１００において、ＩＰネットワーク１０３を経由したＳＩＰサーバ１０１とＳＩＰ端末１０２Ａ〜１０２Ｎ（以下、断りのない限り単にＳＩＰ端末１０２という）との間の通信は、ＩＥＴＦ ＲＦＣ２２４６で定義されるＴＬＳ（Transport Layer Security）上でＳＩＰ通信を行う場合に適用できる。ＳＩＰについては非特許文献１に詳述されている。

図７において、ＳＩＰサーバ１０１は、ＲＦＣ３２６１で定義されるプロキシサーバとレジストラサーバとの双方の機能を有している。
ＳＩＰ端末１０２は、ＳＩＰ端末１０２自身のＩＰアドレスや使用するポート番号をＲＦＣ３２６１で定義されるレジストラ（ＲＥＧＩＳＴＥＲ）メッセージとしてＳＩＰサーバ１０１に送信する。ＳＩＰサーバ１０１は、ＲＥＧＩＳＴＥＲメッセージを受信するとレジストラサーバとして振る舞い、ＲＥＧＩＳＴＥＲメッセージからＳＩＰ端末１０２のＩＰアドレスやポート番号を認識する。

また、ＳＩＰ端末１０２は、他のＳＩＰ１０２端末と通信を行うために、ＲＦＣ３２６１で定義されるＩＮＶＩＴＥメッセージをＳＩＰサーバ１０１へ送信する。
ＳＩＰサーバ１０１は、ＩＮＶＩＴＥメッセージを受信するとプロキシサーバとして振る舞い、ＩＮＶＩＴＥメッセージに含まれるＲｅｑｕｅｓｔ−ＵＲＩから、着信先のＳＩＰ端末１０２を決定し、ＩＮＶＩＴＥメッセージを転送する。

前記したようにＳＩＰ端末１０２間の通信を実現するが、ＳＩＰサーバ１０１とＳＩＰ端末１０２との間のＳＩＰ通信をセキュリティ面で保護する観点から、ＳＩＰサーバ１０１とＳＩＰ端末１０２との間のＳＩＰ通信はＴＬＳ上で行うものとする。ＴＬＳについては、非特許文献２に詳述されている。

ところで、非特許文献１には、ＴＬＳを利用したＳＩＰ端末・ＳＩＰサーバ間の通信に関する記述として、プロキシサーバ・リダイレクトサーバ・レジストラサーバは、ＴＬＳを実装しなければならず、さらに１方向・双方向の認証を両方ともサポートしなければならないとあり、また、ＵＡ（User Agent：図１０のＩＰ端末１０２に相当）は、ＴＬＳを最初に接続してＴＬＳクライアントとして振る舞うことが強く推奨されるとある。なお、ＵＡはＴＬＳサーバとして振る舞う機能を持ってもよい。

前記したように、ＲＦＣ３２６１では、ＳＩＰ端末１０２がＴＬＳクライアントになることを強く推奨している。その理由を以下に説明する。
すなわち、ＲＦＣ３２６１では、ＴＬＳの暗号化スイートとして、公開鍵暗号方式の一つであるＲＳＡ（Rivest Shamir Adleman）方式を利用した暗号化スイートＴＬＳ-ＲＳＡ-ＷＩＴＨ-ＡＥＳ-１２８-ＣＢＣ-ＳＨＡを最低限サポートすることになっている。

ＲＳＡを用いた暗号化スイートの場合、ＴＣＰ(Transmission Control Protocol)と異なり、ＴＬＳサーバとして振る舞うにためには、公開鍵を含むサーバ証明書と秘密鍵とが必要になる。そのため、ＳＩＰ端末１０２がＴＬＳサーバとして振る舞うには、全ＳＩＰ端末１０２にサーバ証明書と秘密鍵とを配置することが必要となるが、ＳＩＰ端末１０２は、一般にＩＰ電話端末として膨大な数になるため、全ＳＩＰ端末１０２にサーバ証明書と秘密鍵を発行するのは現実的ではない。

そのため、サーバ証明書と秘密鍵とは、ＳＩＰサーバ１０１等の数が限られるサーバにのみ配置するモデルがＲＦＣ３２６１に記述されている。
ＩＥＴＦ ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｉｐｓ−０９に関しても、例えば、３．１項にＳＩＰでＴＬＳを利用するモデルが記述されている。ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｉｐｓ−９０の３．１．２項には、ＵＡ（＝ＳＩＰ端末１０２）がＴＬＳサーバとなる場合、サーバ証明書をＵＡに配置することになり、非現実的である旨が記述されている。

以上説明のように、サーバ証明書と秘密鍵は、装置数が限られるサーバにのみ配置するモデルが一般的である。
なお、ＳＩＰ端末１０２がＴＬＳサーバとして振る舞わず、ＴＬＳクライアントとしてのみ振る舞う場合、ＳＩＰサーバ１０１からＳＩＰ端末１０２へのＴＬＳ接続要求を行えない。例えば、ＳＩＰ端末１０２ＡがＳＩＰ端末１０２Ｂと通信を行う場合、発側となるＳＩＰ端末１０２ＡからＳＩＰサーバ１０１へＩＮＶＩＴＥメッセージが送信され、ＳＩＰサーバ１０１が着側となるＳＩＰ端末１０２ＢへＩＮＶＩＴＥメッセージを転送させる。

このとき、ＳＩＰサーバ１０１が着側ＳＩＰ端末１０２ＢへＩＮＶＩＴＥを転送させるためには、ＳＩＰ端末１０２ＢからＳＩＰサーバ１０１へＴＬＳセッションをあらかじめ接続しておく必要がある。そのため、ＲＦＣ３２６１ ２６．３．２．１項で、ＳＩＰ端末１０２がＳＩＰサーバ１０１へＲＥＧＩＳＴＥＲを送信した後、図８のレジストレーション処理の動作シーケンス図に示されるように、ＳＩＰ端末１０２と、ＳＩＰサーバ１０１との間でＴＬＳセッションをオープンしたままとする仕様になっている。

図８には、ＲＦＣ３２６１に基づいた、ＳＩＰサーバ１０１と、着側のＳＩＰ端末１０２のレジストレーションからＳＩＰ端末間の通信確立に至るまでのＳＩＰ信号の流れが示されている。
以下、図８のＲＦＣ３２６１におけるＳＩＰサーバ１０１のレジストレーション処理の流れについて簡単に説明する。

図８において、ＳＩＰ端末１０２は、まず、ＳＩＰサーバ１０１に対してＴＣＰ接続を行う。処理（Ｐ８１）は、ＴＣＰ接続処理（スリーウェイハンドシェイク）である。ＴＣＰ接続が完了すると、処理（Ｐ８２）に示されように、ＴＬＳセッションを確立するため、ＳＩＰ端末１０２は、ＳＩＰサーバ１０１へＴＬＳハンドシェイクを実行する。
このＴＬＳハンドシェイクは、処理（Ｐ８１）で確立したＴＣＰコネクション上で行う。ＴＬＳハンドシェイクが完了すると、処理（Ｐ８３）に示されるように、ＳＩＰ端末１０２は、ＲＦＣ３２６１の１０項に示すとおりＳＩＰサーバ１０１へＲＥＧＩＳＴＥＲ信号を送信してレジストレーション処理を実行する。

ＲＦＣ３２６１のモデルでは、レジストレーション完了後、ＳＩＰサーバ１０１とＳＩＰ端末１０２との間のＴＬＳセッションは切断せず、保持する方式になっている。これにより、処理（Ｐ８４）のように、ＳＩＰサーバ１０１側からＳＩＰ端末１０２側へＳＩＰリクエストを送信する場合、処理（Ｐ８２）で確立したＴＬＳセッションを利用することで、ＳＩＰサーバ１０１からＳＩＰ端末１０２の方向へリクエストを送信可能にしている。

ＩＥＴＦ ＲＦＣ３２６１ 「ＩＥＴＦドラフト：ｄｒａｆｔ−iｅｔｆ−ｓｉｐ−ｓｉｐｓ−０９」 ＜インターネットＵＲＬ＞ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐ−ｓｉｐｓ−０９．ｔｘｔ （２００９−２−２２日閲覧） ＩＥＴＦ ＲＦＣ２２４６ 「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌｖ．１．０」 ＜インターネットＵＲＬ＞ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｉｃ／ ｒｆｃ２２４６．ｔｘｔ（２００９−２−２２日閲覧）

前記したモデルの場合、ＲＦＣ３２６１ ２６．４．３項で指摘されているように、ＳＩＰサーバ１０１が全ＳＩＰ端末１０２とＴＬＳセッションを確立し、保持することになり、ＳＩＰサーバ１０１のメモリ等のリソースを圧迫する問題がある。
一方、ＳＩＰサーバ１０１とＳＩＰ端末１０２との間でＴＬＳセッションを保持せず、ＳＩＰリクエストを送信するときのみ動的にＴＬＳセッションを確立させる場合、ＳＩＰ端末１０２は、サーバ証明書を配置しないためＴＬＳサーバにはなれず、ＳＩＰサーバ１０１からＳＩＰ端末１０２方向へのＴＬＳセッション要求を送信できない問題がある。

本発明は前記した課題を解決するためになされたものであり、ＳＩＰサーバとＳＩＰ端末との間でＴＬＳセッションを保持せず、ＳＩＰリクエストを送信するときのみ動的にＴＬＳセッションを確立させることを実現し、このことにより、ＳＩＰサーバのリソース圧迫を回避し、かつ、ＳＩＰサーバからＳＩＰ端末へのＴＬＳセッション要求を送信可能な、通信システム、ＳＩＰサーバ、ＳＩＰ端末、及びセキュリティ通信方法を提供することを目的とする。

前記目的を達成するために、本発明の通信システムは、ＳＩＰサーバとＳＩＰ端末とがＩＰネットワーク経由で接続される通信システムであって、前記ＳＩＰサーバから前記ＳＩＰ端末へのＳＩＰリクエスト送信時、前記ＳＩＰサーバが、前記ＳＩＰ端末にＴＣＰコネクションを行うＳＩＰサーバ側コネクション管理部と、前記ＳＩＰ端末が前記ＳＩＰサーバとのＴＣＰコネクションの確立を契機に前記ＳＩＰサーバへ動的にＴＬＳセッションを確立するＳＩＰ端末側コネクション管理部とを備え、前記ＳＩＰサーバ側コネクション管理部は、前記ＴＬＳセッションが確立したことを検知して前記ＳＩＰ端末に前記ＳＩＰリクエストを送信するものである。

また、本発明のＳＩＰサーバは、ＳＩＰ端末とはＩＰネットワーク経由で接続されるＳＩＰサーバであって、前記ＳＩＰ端末へのＳＩＰリクエスト送信時、前記ＳＩＰ端末にＴＣＰコネクションを行うＳＩＰサーバ側コネクション管理部を備え、前記ＳＩＰサーバ側コネクション管理部は、前記ＳＩＰ端末とのＴＣＰコネクションの確立を契機に前記ＳＩＰ端末が動的にＴＬＳセッションを確立したことを検知して前記ＳＩＰ端末に前記ＳＩＰリクエストを送信するものである。

また、本発明のＳＩＰ端末は、ＳＩＰサーバとはＩＰネットワーク経由で接続されるＳＩＰ端末であって、前記ＳＩＰサーバとの間のＴＣＰコネクションの確立を契機に前記ＳＩＰサーバへ動的にＴＬＳセッションを確立するＳＩＰ端末側コネクション管理部とを備え、前記ＳＩＰ端末側コネクション管理部は、前記ＳＩＰサーバから前記ＳＩＰ端末へのＳＩＰリクエスト送信時、前記ＳＩＰサーバとのＴＣＰコネクションの確立を契機に前記ＳＩＰサーバへ動的にＴＬＳセッションを確立するものである。

また、本発明のセキュリティ通信方法は、ＳＩＰサーバとＳＩＰ端末とが、ＩＰネッワーク経由で接続される通信システムにおけるセキュリティ通信方法であって、前記ＳＩＰサーバから前記ＳＩＰ端末へのＳＩＰリクエスト送信時、前記ＳＩＰサーバが、前記ＳＩＰ端末にＴＣＰコネクションを行うステップと、前記ＳＩＰ端末が前記ＳＩＰサーバとのＴＣＰコネクションの確立を契機に前記ＳＩＰサーバへ動的にＴＬＳセッションを確立するステップと、前記ＳＩＰサーバが、前記ＴＬＳセッションが確立したことを検知して前記ＳＩＰ端末に前記ＳＩＰリクエストを送信するステップと、を有するのである。

本発明によれば、ＳＩＰサーバとＳＩＰ端末との間でＴＬＳセッションを保持せず、ＳＩＰリクエストを送信するときのみ動的にＴＬＳセッションを確立させることができる。これにより、ＳＩＰサーバのリソース圧迫を回避し、かつ、ＳＩＰサーバからＳＩＰ端末へのＴＬＳセッション要求を送信することができる。

本発明の実施の形態に係る通信システムのシステム構成の一例を示す図である。 本発明の実施の形態に係る通信システムのレジストレーション処理の流れを示す動作シーケンス図である。 本発明の実施の形態に係る通信システムにおいて、ＳＩＰサーバからＳＩＰ端末へＳＩＰリクエストを送信する場合の動作の流れを示す動作シーケンス図である。 本発明の実施の形態にＳＩＰサーバとＳＩＰ端末の内部構成を示すブロック図である。 本発明の実施の形態に係るＳＩＰサーバ（ＳＩＰサーバ側コネクション管理部）の動作を示すフローチャートである。 本発明の実施の形態に係るＳＩＰ端末（ＳＩＰ端末側コネクション管理部）の動作を示すフローチャートである。 従来の通信システムのシステム構成の一例を示す図である。 従来の通信システムにおけるＩＰサーバと着側のＳＩＰ端末との間のレジストレーションから通信確立に至るまでのＳＩＰ信号の流れを示す動作シーケンス図である。

（通信システム１の構成）
図１は、本発明の実施の形態に係る通信システムのシステム構成の一例を示す図である。
図１に示されるように、本発明の実施の形態に係る通信システム１は、ＳＩＰサーバ１１とＳＩＰ端末１２Ａ〜１２ＮとがＩＰネッワーク１３経由で接続される。
ここで、特徴的には、ＳＩＰサーバ１１とＳＩＰ端末１２Ａ〜１２Ｎとの間でＴＬＳセッションを保持せず、ＳＩＰサーバ１１がＳＩＰリクエストを送信する場合にのみ動的にＴＬＳセッションを確立させ、これにより、ＳＩＰサーバ１１とＳＩＰ端末１２Ａ〜１２Ｎとの間にＴＬＳ（証明書と秘密鍵の発行）の常駐を不要としたことにある。

このため、本発明の実施の形態に係る通信システム１によれば、ＳＩＰサーバ１１からＳＩＰ端末１２Ａ〜１２ＮへＴＣＰで接続し、ＴＣＰの接続を検出したＳＩＰ端末１２Ａ〜１２Ｎは、ＳＩＰサーバ１１へＴＬＳ接続を行う。
なお、図１に示す本発明の実施の形態に係る通信システム１では、図７に示す従来の通信システム１００との差異を明確にするため、ＳＩＰサーバ１１とＳＩＰ端末１２Ａ〜１２Ｎとの間にＴＬＳが動的に保持される様子を動的ＴＬＳ２０として、また、従来の通信システム１００では、ＳＩＰサーバ１１とＳＩＰ端末１２Ａ〜１２Ｎとの間にＴＬＳが保持されている様子を常駐ＴＬＳ３０として、それぞれ模式的に示してある。

（通信システム１の動作）
図２は、本発明の実施の形態に係る通信システム１の動作を示す動作シーケンス図であり、ここでは、ＳＩＰサーバ１１とＳＩＰ端末１２（１２Ａ〜１２Ｎ）との間のＲＦＣ３２６１にしたがうレジストレーションの流れを示している。

図２において、ＳＩＰ端末１２は、まず、ＳＩＰサーバ１１に対してＴＣＰコネクションを行う（処理Ｐ２１）。
ＴＣＰ接続が完了すると、ＳＩＰ端末１２は、ＴＬＳセッションを確立するためにＳＩＰサーバ１１に対してＴＬＳハンドシェイクを実行する（処理Ｐ２２）。このＴＬＳハンドシェイクは、処理Ｐ２１で確立したＴＣＰコネクション上で行う。ＴＬＳハンドシェイクが完了すると、ＳＩＰ端末１２は、ＲＦＣ３２６１の１０項に示すとおりＳＩＰサーバ１０１へＲＥＧＩＳＴＥＲ信号を送信してレジストレーションを実行する（処理Ｐ２３）。

処理Ｐ２３でレジストレーションを実行するにあたり、ＳＩＰ端末１２は、ＲＥＧＩＳＴＥＲメッセージのＣｏｎｔａｃｔヘッダにＳＩＰ端末１２のＩＰアドレスと着信ＴＬＳポートのポート番号とを設定し、ＳＩＰサーバ１１へ送信する。
ＳＩＰサーバは１１、レジストレーションにおいて、２００ ＯＫを返却した直後、ＳＩＰ端末情報管理部ＳＩＰサーバ１１のＴＬＳポート情報に、ＲＥＧＩＳＴＥＲメッセージのＣｏｎｔａｃｔヘッダに設定されていた着信ＴＬＳポートのポート番号を登録する。レジストレーション完了後、ＳＩＰサーバ１１とＳＩＰ端末１２は、ＴＬＳセッションを切断し（Ｐ２４）、さらにＴＣＰコネクションも切断している（処理Ｐ２５）。

図３は、本発明の実施の形態に係る通信システムの動作を示す動作シーケンス図であり、ＳＩＰサーバ１１からＳＩＰ端末１２へＳＩＰリクエストを送信する際の処理の流れが示されている。

ここでは、ＳＩＰサーバ１１とＳＩＰ端末１２との間のＴＬＳセッションが存在しないため、ＳＩＰサーバ１１は、まずＳＩＰ端末１２へＴＣＰ接続を要求してＴＣＰコネクションを確立する（Ｐ３１）。
ＳＩＰサーバ１１はＴＣＰコネクションが確立すると、ＳＩＰ端末１２からのＴＬＳ接続を待ち受け、ＳＩＰサーバ１１からのＴＣＰコネクションを検出したＳＩＰ端末１２は、ＳＩＰ端末１２自身がＴＬＳクライアントとして振る舞い、ＳＩＰサーバ１１へＴＬＳ接続を行い、ＴＬＳセッションを確立する（Ｐ３２）。ＳＩＰサーバはＴＬＳセッション確立を検出すると、ＳＩＰ端末に対してＳＩＰリクエストを送信する（Ｐ３３）。

前記したように、本発明の実施の形態に係る通信システムによれば、ＳＩＰ端末１２は、ＴＣＰサーバとして振る舞い、ＳＩＰサーバ１１からのＴＣＰコネクションを検出すると、ＴＬＳクライアントとしてＳＩＰサーバ１１へアクセスする。一方、ＳＩＰサーバ１１は、ＳＩＰリクエスト送信時ＴＣＰクライアントとして振る舞い、ＴＣＰコネクション確立後、ＳＩＰ端末１２からのＴＬＳ接続要求を待ち受けるＴＬＳサーバとして振る舞う。
このことにより、ＳＩＰサーバ１１とＳＩＰ端末１２との間にＴＬＳセッションを常駐させることなく、ＳＩＰサーバ１１からＳＩＰ端末１２へのリクエスト送信を実現することができる。

（ＳＩＰサーバ１１の構成）
図４は、本発明の実施の形態に係る通信システム１を構成するＳＩＰサーバ１１とＳＩＰ端末１２の内部構成を示すブロック図である。
図４に示すＳＩＰサーバ１１は、ＲＦＣ３２６１のＳＩＰレジストラとＳＩＰプロキシを兼ねるものとする。ＳＩＰサーバ１は、サーバ側コネクション管理部１１０と、呼処理部１１１と、ＳＩＰ端末情報管理部１１２と、を含む。

呼処理部１１１は、ＲＦＣ３２６１に記述されるＳＩＰレジストラ、ＳＩＰプロキシの機能を提供し、ＲＦＣ３２６１のＵＡＣ（User Agent Client）、ＵＡＳ（User Agent Server）として振る舞い、ＲＦＣ３２６１ １２項で定義されるＳＩＰダイアログを管理する。呼処理部はまた、ＳＩＰ端末１２からのＳＩＰメッセージを、サーバ側コネクション管理部１１０を経由して送受信する。
ＳＩＰ端末情報管理部１１０は、ＳＩＰ端末１２へアクセスするために必要な情報として、端末ＵＲＩ（ＳＩＰ端末１２のＳＩＰ−ＵＲＩ）、着信ＴＬＳポート番号、ＴＬＳ接続状態、ＳＩＰダイアログ状態を管理する。

端末ＵＲＩ（Uniform Resource Identifier）とは、ＳＩＰ端末１２を識別するためのＳＩＰ−ＵＲＩであり、ＳＩＰ端末１２のＩＰアドレスは、端末ＵＲＩのホスト部（例えば、端末ＵＲＩが、“ｓｉｐ：ｕｓｅｒｎａｍｅ@１９２．１６８．１．１”の場合、１９２．１６８．１．１がＩＰアドレス）に含まれるものとする。また、着信ＴＬＳポート番号は、ＳＩＰサーバ１１がＳＩＰ端末１２へＴＬＳ接続する場合に使用するポート番号である。
ＴＬＳ接続状態は、ＳＩＰサーバ１１−ＳＩＰ端末１２間でＴＬＳセッションが確立されているか否かを示す状態であり、”接続中”もしくは”切断”状態がある。ＳＩＰダイアログ状態は、端末ＵＲＩで識別されるＳＩＰ端末１２と通信中のＳＩＰダイアログが呼処理部１１１に存在するか否かを管理する。

呼処理部１１１に端末ＵＲＩで識別されるＳＩＰ端末１２と通信中のＳＩＰダイアログが存在すればＳＩＰダイアログ状態は”通信中”、存在しなければＳＩＰダイアログ状態は、”切断”となる。
サーバ側コネクション管理部１１０は、すべてのＳＩＰ端末１２Ａ〜１２ＮとのＴＣＰコネクション、ＴＬＳセッションの切断・接続を検出し、ＳＩＰメッセージをＳＩＰ端末１２から受信すると、ＳＩＰ端末情報管理部１１２の情報を更新するとともに、呼処理部１１１へＳＩＰメッセージを転送し、ＳＩＰメッセージ送信要求を呼処理部１１１から受信すると、ＳＩＰ端末情報管理部１１２の情報を更新するとともに、ＳＩＰ端末１２へメッセージを送信する機能を有する。

（ＳＩＰ端末１２の構成）
一方、ＳＩＰ端末１２は、端末側コネクション管理部１２０と、ＳＩＰ処理部１２１と、自端末情報管理部１２２とを含む。
ＳＩＰ処理部１２１は、ＲＦＣ３２６１でのＵＡとしての機能を持ち、端末側コネクション管理部１２０を経由してＳＩＰサーバ１１とのＳＩＰメッセージ送受信を行う。自端末情報管理部１２２は、ＴＬＳ接続状態とＳＩＰダイアログ状態とを保持する。ＴＬＳセッション状態は、ＳＩＰサーバ１１と自ＳＩＰ端末１２のＴＬＳセッションが確立されているか否かを示す状態であり、”接続中”もしくは”切断”状態がある。ＳＩＰダイアログ状態は、ＳＩＰ処理部１２１にＳＩＰサーバ１１と通信中のダイアログが存在するか否かを示し、存在すれば”通信中”、存在しなければ”切断”となる。

端末側コネクション管理部１２０は、ＳＩＰサーバ１１とのＴＣＰコネクション、ＴＬＳセッションの切断・接続を検出し、ＳＩＰサーバからＳＩＰメッセージを受信すると、自端末情報管理部１２２の情報を更新するとともに、ＳＩＰ処理部１２１へＳＩＰメッセージを転送し、ＳＩＰメッセージ送信要求をＳＩＰ処理部１２１から受信すると、自端末情報管理部１２２の情報を更新するとともに、ＳＩＰサーバ１１へＳＩＰメッセージを送信する機能を有する。

図５は、ＳＩＰサーバ１１のサーバ側コネクション管理部１１０の動作、図６は、ＳＩＰ端末１２の端末側コネクション管理部１２０の動作を示すフローチャートである。
図５、図６に示すフローチャートでは、ＳＩＰサーバ１１−ＳＩＰ端末１２間でＴＬＳセッションが複数生成されることはなく一個のみ生成されるものとする。なお、同一のＳＩＰ端末１２−ＳＩＰサーバ１１間で複数のＳＩＰダイアログが生成されることがあるが、ＴＬＳセッションは共有する。

（ＳＩＰサーバ１１：サーバ側コネクション管理部１１０の動作）
図５において、まず、ＳＩＰサーバ１１のサーバ側コネクション管理部１１０は、イベント待ちの状態になっている（ステップＳ５０１）。サーバ側コネクション管理部１１０は、ＩＰネットワーク１３経由でＳＩＰメッセージが到着し、呼処理部１１１からＳＩＰメッセージ送信要求を受信し、ＳＩＰ端末１２とのＴＣＰコネクション確立、又は切断、ＳＩＰ端末１２とのＴＬＳセッション確立、又は切断、のいずれかのイベントを検出すると、呼処理部１１１からＳＩＰメッセージの送信要求があるか否かを判定する（ステップＳ５０２）。

送信要求があった場合（ステップＳ５０２“Ｙｅｓ”）、サーバ側コネクション管理部１１０は、呼処理部１１１からのＳＩＰメッセージを送信するために、ＳＩＰ端末１２とのＴＬＳセッションが確立済みか否かを判定する（ステップＳ５０３）。ここで、ＴＬＳセッションが確立済みであれば（ステップＳ５０３“Ｙｅｓ”）、後記するステップＳ５０６のＳＩＰメッセージ送信処理を実行し、確立されていなければ、ＳＩＰ端末１２へＴＣＰ接続を要求する（ステップＳ５０４）。

図３の動作シーケンス図を用いて説明したように、ＳＩＰ端末１２は、ＳＩＰサーバ１１からのＴＣＰコネクションが確立されると、ＳＩＰ端末１２からＳＩＰサーバ１１へＴＬＳ接続を要求する。このときサーバ側コネクション管理部１１０は、ＴＣＰ接続要求後、ＳＩＰ端末１２とのＴＬＳセッション確立が完了するのを待ち受ける（ステップＳ５０５）。
ＴＬＳセッションが確立すると、サーバ側コネクション管理部１１０は、ＳＩＰ端末情報管理部１１２の情報のうち、ＴＬＳセッションが確立した対向ＳＩＰ端末１２を表す端末ＵＲＩのＴＬＳ接続状態を”接続中”に更新し、ＳＩＰ端末１２と接続するＴＬＳセッションへ、呼処理部から送信要求されたＳＩＰメッセージを送信する（ステップＳ５０６）。

メッセージ送信後、サーバ側コネクション管理部１１０は、呼処理部１１１のＳＩＰダイアログを判定し、メッセージ送信先のＳＩＰ端末１２とのＳＩＰダイアログが呼処理部１１１に存在しなければ、ＳＩＰダイアログ状態を”切断”に設定し、ＳＩＰダイアログが呼処理部１１１に存在すれば、”通信中”に設定し、ステップＳ５１２の処理に移行する（ＲＦＣ３２６１では、ＳＩＰダイアログは、ＩＮＶＩＴＥやＢＹＥ、４ＸＥレスポンス等のＳＩＰメッセージの送受信を契機に生成され、削除される）。

一方、ステップＳ５０２のメッセージ送信要求有無判定処理において、メッセージ送信要求が無いと判定された場合（ステップＳ５０２“Ｎｏ”）、サーバ側コネクション管理部１１０は、ＴＬＳセッションが確立済みか否かを判定する（ステップＳ５０７）。
ここで、ＴＬＳセッションが確立されていなければ（ステップＳ５０７“Ｎｏ”）、サーバ側コネクション管理部１１０は、更に、ＳＩＰ端末１２からＴＣＰ接続要求が有るか否かを判定する（ステップＳ５０８）。ＴＣＰコネクションが確立していれば（ステップＳ５０８“Ｙｅｓ”）、サーバ側コネクション管理部１１０は、ＳＩＰ端末１２からのＴＬＳセッション確立を待ち合わせる（ステップＳ５０９）。

ステップＳ５０７でＴＬＳセッションが確立済みと判定されると（ステップＳ５０７“Ｙｅｓ”）、サーバ側コネクション管理部１１０は、ＳＩＰ端末情報管理部１１２のうち、ＴＬＳセッションが確立した対向ＳＩＰ端末１２を示す端末ＵＲＩのＴＬＳ接続状態を”接続中”に更新し、確立したＴＬＳセッションでＳＩＰ端末１２からのＳＩＰメッセージ（到着メッセージ）が有るか否かを判定する（ステップＳ５１０）。
ＴＬＳセッションにＳＩＰメッセージが到着していれば（ステップＳ５１０“Ｙｅｓ”）、ＴＬＳセッションからＳＩＰメッセージを受信して呼処理部１１１へ転送する（ステップＳ５１１）。呼処理部１１１へＳＩＰメッセージを転送後、ＳＩＰメッセージを送信したＳＩＰ端末１２とのダイアログが呼処理部１１１に存在しなければ、ＳＩＰ端末情報管理部１１２の当該ＳＩＰ端末１２のＳＩＰダイアログ状態を”切断”に設定し、ＳＩＰダイアログが呼処理部１１１に存在すれば、”通信中”に設定し、ＳＩＰ端末１２との不要なＴＬＳセッション、ＴＣＰコネクションを切断する（ステップＳ５１２）。

サーバ側コネクション管理部１１０は、ＳＩＰ端末情報管理部１１２の情報で、ＳＩＰダイアログ情報が”切断”で、かつＴＬＳ接続状態が”接続中”のエントリがあるか否かを判定し、該当するエントリがあれば、そのエントリの端末ＵＲＩに該当するＳＩＰ端末１２とのＴＬＳセッション、ＴＣＰコネクションの切断処理を行い、ＳＩＰ端末情報管理部１１２のＴＬＳ接続状態を”切断”に設定する。

サーバ側コネクション管理部１１０は、次に、ＳＩＰ端末情報管理部１１２のＴＬＳ接続状態が”接続中”であるＳＩＰ端末１２とのＴＬＳセッションが、切断されているか否かを判定する。
ここで、サーバ側コネクション管理部１１０は、ＳＩＰ端末１２からＴＬＳセッションを切断された、又は、ＩＰネットワーク１３の障害によりＳＩＰ端末１２と通信できず、ＴＣＰコネクションのｋｅｅｐ ａｌｉｖｅがタイムアウトしていた場合、ＳＩＰサーバ１１で管理しているＴＬＳセッション、ＴＣＰコネクションの情報を更新し、リソースを解放する（ＴＬＳセッション用に確保しているメモリの解放やＴＣＰコネクションに使用するソケットの解放など）。さらに、切断されたＴＬＳセッションに関連するＳＩＰ端末情報管理部１１２のＴＬＳ接続状態を”切断”に設定する。これらの処理を完了すると、終了要求の有無を判定し（ステップＳ５１４）、終了されなければ（ステップＳ５１４“Ｙｅｓ”）、ステップＳ５０１のイベント待ちの処理に戻る。

（ＳＩＰ端末１２：端末側コネクション管理部１２０の動作）
図６において、まず、ＳＩＰ端末１２の端末側コネクション管理部１２０は、イベント待ちの状態になっている（ステップＳ６０１）。端末側コネクション管理部１２０は、ＩＰネットワーク１３からのＳＩＰメッセージ到着、ＳＩＰ処理部１２１からのＳＩＰメッセージ送信要求の受信、ＳＩＰサーバ１１とのＴＣＰコネクション確立、又は切断、ＳＩＰ端末１２とのＴＬＳセッション確立、又は切断、のいずれか一つのイベントを検出すると、ＳＩＰ処理部１２１からＳＩＰメッセージの送信要求があるか否かを判定する（ステップＳ６０２）。

ここで、送信要求が無い場合（ステップＳ６０２“Ｎｏ”）、ステップＳ６０７のＴＬＳセッション確立済み判定処理に移り、送信要求がある場合（ステップＳ６０２“Ｙｅｓ”）、端末側コネクション管理部１２０は、ＳＩＰ処理部１２１からのＳＩＰメッセージを送信するために、ＳＩＰサーバ１１とのＴＬＳセッションが確立済みか否かを判定する（ステップＳ６０３）。
ＴＬＳセッション確立済みであれば（ステップＳ６０３“Ｙｅｓ”）、ステップＳ６０６のＳＩＰメッセージ送信処理へ、ＴＬＳセッション確立済みでなければ（ステップＳ６０３“Ｎｏ”）、ＳＩＰサーバ１１へＴＣＰ接続を要求する（ステップＳ６０４）。

ＴＣＰコネクションが確立すると、端末側コネクション管理部１２０は、ＳＩＰサーバ１１へＴＬＳ接続を要求する（ステップＳ６０５）。ＴＬＳセッションが確立すると、端末側コネクション管理部１２０は、自端末情報管理部１２２のＴＬＳ接続状態を”接続中”に設定し、ＴＬＳセッションへＳＩＰ処理部１２１から送信要求されたＳＩＰメッセージを送信する（ステップＳ６０６）。メッセージ送信後、ＳＩＰ処理部１２１のＳＩＰダイアログを確認し、メッセージ送信先のＳＩＰ端末１２とのＳＩＰダイアログがＳＩＰ処理部１２１に存在しなければ、ＳＩＰダイアログ状態を”切断”に設定し、ＳＩＰダイアログがＳＩＰ処理部１２１に存在すれば、”通信中”に設定し、後記するステップＳ６１２のＳＩＰダイアログ状態の確認処理に移行する。

一方、ステップＳ６０２でＳＩＰ処理部１２１からメッセージ送信要求が無かった場合（ステップＳ６０２“Ｎｏ”）、端末側コネクション管理部１２０は、ＴＬＳセッションが確立済みか否かを判定する（ステップＳ６０７）。
ここで、ＴＬＳセッション確立済みならば（ステップＳ６０７“Ｙｅｓ”）、ステップＳ６１０の処理へ、ＴＬＳセッションが確立されてなければ（ステップＳ６０７“Ｎｏ”）、更に、ＳＩＰサーバ１１からＴＣＰコネクションが確立されたか否かを判定する（ステップＳ６０８）。

ここで、ＴＣＰコネクションが確立されていなければ（ステップＳ６０８“Ｎｏ”）、ステップＳ６１４の処理へ、確立していれば（ステップＳ６０８“Ｙｅｓ”）、ＳＩＰサーバ１１からのＴＣＰコネクションが確立したので、図３の動作シーケンス図で説明したように、ＳＩＰ端末１２からＴＬＳセッションを確立させるため、端末側コネクション管理部１２０は、ＳＩＰサーバ１１へＴＬＳセッション確立を要求する（ステップＳ６０９）。
ＴＬＳセッションが確立すれば、自端末情報管理部１２２のＴＬＳ接続状態を、”接続中”に更新し、ＴＬＳセッションにＳＩＰサーバ１１からのＳＩＰメッセージが到着しているか否かを判定する（ステップＳ６１０）。

ここで、ＴＬＳセッションに到着メッセージがあれば（ステップＳ６１０“Ｙｅｓ”）、端末側コネクション管理部１２０は、ＴＬＳセッションからＳＩＰメッセージを受信してＳＩＰ処理部１２１へ転送する（ステップＳ６１１）。
ＳＩＰ処理部１２１へＳＩＰメッセージを転送後、端末側コネクション管理部１２０は、ＳＩＰダイアログ状態を確認する（ステップＳ６１２）。具体的に、端末側コネクション管理部１２０は、ＳＩＰダイアログがＳＩＰ処理部１２１に存在しなければ、ＳＩＰ端末情報管理部１２２の当該ＳＩＰ端末１２のＳＩＰダイアログ状態を”切断”に設定し、ＳＩＰダイアログが存在すれば、ＳＩＰダイアログ状態を“通信中”に設定する。そして、自端末情報管理部１２２のＳＩＰダイアログ状態が”切断”であり、かつＴＬＳ接続状態が”接続中”となっていれば、ＳＩＰサーバ１１とのＴＬＳセッション、ＴＣＰコネクションを切断する。ＴＬＳセッション・ＴＣＰコネクションを切断した場合、自端末情報管理部１２２のＴＬＳ接続状態を”切断”に設定する。

この処理を経てＴＬＳセッション状態の確認処理を実行する（ステップＳ６１３）。具体的に、端末側コネクション管理部１２０は、自端末情報管理部１２２のＴＬＳ接続状態が”接続中”である場合、ＳＩＰ端末１２とのＴＬＳセッションが、切断されていないかを確認する。ここで、端末側コネクション管理部１２０は、ＳＩＰサーバ１１からＴＬＳセッションが切断され、もしくはＩＰネットワーク１３の障害によりＴＣＰコネクションのｋｅｅｐ ａｌｉｖｅがタイムアウトした場合、ＴＬＳセッション、ＴＣＰコネクションを切断し、ＴＬＳ接続状態を”切断”に設定する。これらの処理を完了すると、終了要求の有無を判定し（ステップＳ６１４）、終了されなければ（ステップＳ６１４“Ｙｅｓ”）、ステップＳ６０１のイベント待ちの処理に戻る。

以上説明のように本発明の実施の形態に係る通信システム１によれば、ＳＩＰサーバ１１からＳＩＰメッセージ送信時、図５に示すステップＳ５０４〜Ｓ５０６、及び図６のステップＳ６０８〜Ｓ６１０に示されるように、ＳＩＰサーバ１１がＳＩＰ端末１２へＴＣＰ接続を要求し、ＳＩＰ端末１２がＴＣＰコネクション確立を契機にＳＩＰサーバ１１へＴＬＳ接続を要求することにより、ＳＩＰ端末１２にＴＬＳのサーバ証明書を配置せず、また、ＳＩＰ端末１２−ＳＩＰサーバ１１間で常時ＴＬＳセッション、ＴＣＰコネクションを保持することなく、ＳＩＰサーバ１１からＳＩＰ端末１２へＴＬＳ上のＳＩＰメッセージ送信することが可能になる。

なお、前記した本発明の実施の形態に係る通信システム１によれば、ＳＩＰサーバ１１を一個のみ例示したが、ＳＩＰサーバ１１が複数存在する場合にも同様に適用できる。
また、ＳＩＰサーバ１１は、ＲＦＣ３２６１のＳＩＰプロキシキとＳＩＰレジストラの機能を有するものとして説明したが、ＳＩＰプロキシとＳＩＰレジストラが物理的に別のサーバに機能分散される場合も同様に適用できる。この場合、ＳＩＰ端末１２の着信ＴＬＳポートをＲＥＧＩＳＴＥＲのＣｏｎｔａｃｔヘッダに設定してＳＩＰレジストラに登録し、ＳＩＰプロキシからＳＩＰ端末１２へのＳＩＰメッセージ送信時、ＲＦＣ３２６１のＦｉｇｕｒｅ２に示されるように、ＳＩＰプロキシがロケーションサーバを通して登録されたＳＩＰ端末１２の着信ＴＬＳポートを取得し、着信ＴＬＳポートに対してＳＩＰサーバ１１からＴＣＰ接続を行う。このことにより、ＳＩＰプロキシとＳＩＰ端末１２間の通信に本発明を適用することができる。

また、本発明の実施の形態に係る通信システム１によれば、ＲＦＣ３２６１にしたがい着信ＴＬＳポートをＳＩＰレジストラへ登録するためにＲＥＧＩＳＴＥＲのＣｏｎｔａｃｔヘッダを利用したが、例えば、ＳＩＰサーバ１１にあらかじめＳＩＰ端末１２の着信ＴＬＳポートをコンフィグで設定しておく等、ＳＩＰ端末１２の着信ＴＬＳポートをＳＩＰサーバ１１が認識する手段がＲＥＧＩＳＴＥＲのＣｏｎｔａｃｔヘッダでない場合にも適用が可能である。
また、本発明の実施の形態に係る通信システム１によれば、同一のＳＩＰ端末１２−ＳＩＰサーバ１１間に生成されるダイアログは、同じＴＬＳセッションを共有する構成になっているが、ダイアログ毎にＴＬＳセッションを生成することも可能である。

以上、好ましい実施の形態を上げて本発明を説明したが、本発明は必ずしも上記実施の形態に限定されるものでなく、その技術的歯槽の範囲内において様々に変形して実施することができる。

１ 通信システム
１１，１０１ ＳＩＰサーバ
１２，１０２ ＳＩＰ端末
１３ ＩＰネットワーク
２０ 動的ＴＬＳ
３０ 常駐ＴＬＳ
１１０ サーバ側コネクション管理部
１１１ 呼処理部
１１２ ＳＩＰ端末情報管理部
１２０ 端末側コネクション管理部
１２１ ＳＩＰ処理部
１２２ 自端末情報管理部

Claims (9)

1. ＳＩＰサーバとＳＩＰ端末とがＩＰネットワーク経由で接続される通信システムであって、
   前記ＳＩＰサーバから前記ＳＩＰ端末へのＳＩＰリクエスト送信時、前記ＳＩＰサーバが、前記ＳＩＰ端末にＴＣＰコネクションを行うＳＩＰサーバ側コネクション管理部と、
   前記ＳＩＰ端末が前記ＳＩＰサーバとのＴＣＰコネクションの確立を契機に前記ＳＩＰサーバへ動的にＴＬＳセッションを確立するＳＩＰ端末側コネクション管理部とを備え、
   前記ＳＩＰサーバ側コネクション管理部は、
   前記ＴＬＳセッションが確立したことを検知して前記ＳＩＰ端末に前記ＳＩＰリクエストを送信することを特徴とする通信システム。
2. 前記ＳＩＰサーバ側コネクション管理部は、
   前記ＳＩＰサーバと前記ＳＩＰ端末との間のＳＩＰダイアログが１以上未処理の場合、前記ＳＩＰサーバと前記ＳＩＰ端末との間のすべてのダイアログが終了した場合に、前記ＳＩＰサーバと前記ＳＩＰ端末との間のＴＣＰコネクションを切断し、
   前記ＳＩＰ端末側コネクション管理部は、
   前記ＳＩＰサーバと前記ＳＩＰ端末との間のＳＩＰダイアログが１以上未処理の場合、前記ＳＩＰサーバと前記ＳＩＰ端末との間のすべてのダイアログが終了した場合に、前記ＳＩＰサーバと前記ＳＩＰ端末との間のＴＬＳセッションを切断する、
   ことを特徴とする請求項１に記載の通信システム。
3. 前記ＳＩＰ端末側コネクション管理部は、
   前記ＴＬＳセッションを確立する際に生成されたＴＬＳセッションが存在する場合、前記ＳＩＰ端末から前記ＳＩＰサーバへのメッセージ送信に際し、前記存在するＴＬＳセッションを再利用して同じＴＬＳセッションの生成を禁止することを特徴とする請求項１又は請求項２に記載の通信システム。
4. ＳＩＰ端末とはＩＰネットワーク経由で接続されるＳＩＰサーバであって、
   前記ＳＩＰ端末へのＳＩＰリクエスト送信時、前記ＳＩＰ端末にＴＣＰコネクションを行うＳＩＰサーバ側コネクション管理部を備え、
   前記ＳＩＰサーバ側コネクション管理部は、
   前記ＳＩＰ端末とのＴＣＰコネクションの確立を契機に前記ＳＩＰ端末が動的にＴＬＳセッションを確立したことを検知して前記ＳＩＰ端末に前記ＳＩＰリクエストを送信することを特徴とするＳＩＰサーバ。
5. 前記ＳＩＰサーバ側コネクション管理部は、
   前記ＳＩＰ端末との間のＳＩＰダイアログが１以上未処理の場合、前記ＳＩＰ端末との間のすべてのダイアログが終了した場合に、前記ＳＩＰ端末との間のＴＣＰコネクションを切断することを特徴とする請求項４に記載のＳＩＰサーバ。
6. ＳＩＰサーバとＩＰネットワーク経由で接続されるＳＩＰ端末であって、
   前記ＳＩＰサーバとの間のＴＣＰコネクションの確立を契機に前記ＳＩＰサーバへ動的にＴＬＳセッションを確立するＳＩＰ端末側コネクション管理部とを備え、
   前記ＳＩＰ端末側コネクション管理部は、
   前記ＳＩＰサーバから前記ＳＩＰ端末へのＳＩＰリクエスト送信時、前記ＳＩＰサーバとのＴＣＰコネクションの確立を契機に前記ＳＩＰサーバへ動的にＴＬＳセッションを確立することを特徴とするＳＩＰ端末。
7. 前記ＳＩＰ端末側コネクション管理部は、
   前記ＳＩＰサーバとの間のＳＩＰダイアログが１以上未処理の場合、前記ＳＩＰサーバとの間のすべてのダイアログが終了した場合に、前記ＳＩＰサーバとの間のＴＬＳセッションを切断することを特徴とする請求項６に記載のＳＩＰ端末。
8. 前記ＳＩＰ端末側コネクション管理部は、
   前記ＴＬＳセッションを確立する際に生成されたＴＬＳセッションが存在する場合、前記ＳＩＰサーバへのメッセージ送信に際し、前記存在するＴＬＳセッションを再利用して同じＴＬＳセッションの生成を禁止することを特徴とする請求項６又は請求項７に記載のＳＩＰ端末。
9. ＳＩＰサーバとＳＩＰ端末とが、ＩＰネットワーク経由で接続される通信システムにおけるセキュリティ通信方法であって、
   前記ＳＩＰサーバから前記ＳＩＰ端末へのＳＩＰリクエスト送信時、前記ＳＩＰサーバが、前記ＳＩＰ端末にＴＣＰコネクションを行うステップと、
   前記ＳＩＰ端末が前記ＳＩＰサーバとのＴＣＰコネクションの確立を契機に前記ＳＩＰサーバへ動的にＴＬＳセッションを確立するステップと、
   前記ＳＩＰサーバが、前記ＴＬＳセッションが確立したことを検知して前記ＳＩＰ端末に前記ＳＩＰリクエストを送信するステップと、
   を有することを特徴とするセキュリティ通信方法。
   

Images