JP2008092300A - 通信装置およびセッション管理サーバ - Google Patents

Abstract

【課題】セッション管理サーバにクライアントがデータ通信を行うＩＰアドレスとＳＩＰ−ＵＲＩを登録しておく方法を確立する。
【解決手段】セッション管理サーバに予めクライアントを使用するユーザのＡＯＲ情報とクライアント上のアプリケーションがデータ通信を行うＩＰアドレス情報の組を設定しておくことで、セッションを張る際の相手クライアントのＩＰアドレス情報からユーザ情報であるＡＯＲ情報を取得する。これによって、クライアント上のアプリケーションを使用しているユーザが通信したい相手との通信確立を容易且つ自動で行うことが可能である。
【選択図】図２２

Description

本発明は通信装置およびセッション管理サーバに係り、通信相手に対して暗号化データ通信を行う際に通信相手のＩＰアドレスから相手先情報を解決することでその後のデータ通信路確立を容易にする通信装置およびセッション管理サーバに関する。

インターネット上でＶｏＩＰ（Voice over IP）やインスタントメッセージング等のリアルタイムサービスに用いられるプロトコルとしてＳＩＰ（Session Initiation Protocol）の標準化が行われ、ＩＥＴＦ ＲＦＣ３２６１（非特許文献１）として制定されている。

通信サービスの実現に当たってはセンタ側でプロキシ(Proxy)の機能と登録情報(Registrar)の機能を併せ持つセッション管理サーバの提供が必要となる。セッション管理サーバは多数の端末からの接続要求を受け付け、相手クライアントとの通信(以降セッションと呼ぶ)の状態を管理する。一方クライアントは相手と通信するためにＡＯＲ（Address-of-Record）と呼ばれる「ユーザ＠ドメイン名」形式を持つ識別子（ＳＩＰ−ＵＲＩ（Uniform Resource Identifier））を使用してセッション管理サーバに接続要求を送出する。接続要求を受信したセッション管理サーバは、接続先の宛先を解決し、相手のクライアントに対して接続要求を転送する。セッション管理サーバは、セッション情報のネゴシエーションを行い、データ通信を実際に行うＩＰアドレス情報やデータプロトコルなどを相手クライアントとの間で決定し、データ通信路を確立する。

ＳＩＰを用いた通信メリットは、暗号化通信の認証手順のような通信相手と事前にネゴシエーションを必要とする場合、セッション管理サーバは相手が変わるたびに何度も認証することが無いので、簡便に行える。また、ＳＩＰでは通信相手のＩＰアドレスを知らなくとも、ＳＩＰ−ＵＲＩを知っていれば良い。

特許文献１には、クライアントのアプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをＩＰアドレスで指定した形で接続要求を発行した時、クライアントまたはセッション管理サーバで、上記ＩＰアドレスをドメイン識別可能な所望のリソース識別子に自動的に変換する発明が記載されている。

特開２００６−１２８７５１号公報 ＩＥＴＦ、ＲＦＣ３２６１

セッション管理サーバ経由でのセッション確立を前提としたネットワークシステムでは、クライアント上で実行される各アプリケーションは、接続先サーバを指定するための識別子としてサーバの所属ドメインを特定可能なＳＩＰ−ＵＲＩを使用する必要がある。

しかし、現在のクライアントのアプリケーションは一般的にＳＩＰを使用しないものも数多く存在し、そのようなアプリケーションは相手サーバ、相手クライアントの指定にはＡＯＲ形式のＳＩＰ−ＵＲＩは使用せず、ＩＰアドレス情報のような接続先装置情報のみを使用する。クライアントが相手クライアントとセキュアに通信（暗号化通信）する際、データ通信路のセキュリティを高めることと、相手クライアントが正規の通信相手かを認証する必要があり、正規の通信相手とのみ暗号化通信を行う場合は、ＳＩＰ−ＵＲＩのような相手を特定する情報が必要となる。本発明は、ＳＩＰ−ＵＲＩをセキュアに取得可能な通信装置とセッション管理サーバを提供する。

上述した課題は、セッション管理サーバと接続され、セッション管理サーバとＳＩＰによる通信を行い、セッション管理サーバに通信に用いるＩＰアドレスとＩＤとを送信する通信装置により、達成できる。

また、通信装置と接続され、通信装置とＳＩＰによる通信を行い、通信装置から受信した通信装置が通信に用いるＩＰアドレスとＩＤと保持するセッション管理サーバにより、達成できる。

セッション管理サーバに接続された通信装置は、相手装置のＡＯＲ情報をセッション管理サーバから取得することで、通信したい相手とのセッションを確立できる。

以下、本発明の実施の形態について、実施例を用い図面を参照しながら説明する。なお、同一部位には同じ参照番号を振り、説明は繰り返さない。

図１はネットワークのブロック図である。図１において、クライアント１００−Ａ、セッション管理サーバ２００、クライアント１００−Ｂは、ＳＩＰ通信ネットワーク３００で接続されている。また、クライアント１００−Ａとクライアント１００−Ｂは、データ通信ネットワーク３１０で接続されている。クライアント１００は、ＳＩＰ通信に使用するＩＰアドレス（１９２．１６８．０．１または１９２．１６８．０．３）とＡＯＲ形式の識別子であるＳＩＰ−ＵＲＩ（ｓｉｐ：ｃｌｉｅｎｔＡ＠ａｂｃ．ｃｏｍまたはｓｉｐ：ｃｌｉｅｎｔＢ＠ａｂｃ．ｃｏｍ）、データ通信に使用するＩＰアドレス（１９２．１６８．１．１または１９２．１６８．１．３）を備える。セッション管理サーバ２００は、ＳＩＰ通信に使用するＩＰアドレス（１９２．１６８．０．２）と識別子（ａｂｃ．ｃｏｍ）を備える。

図２ないし図４を参照して、クライアントとセッション管理サーバの機能ブロックを説明する。ここで、図２はクライアントの機能ブロック図である。図３はセッション管理装置の機能ブロック図である。図４はクライアントのＳＩＰメッセージ処理部の機能ブロック図である。

図２において、クライアント１００は、ネットワークインターフェースカード（ＮＩＣ）１１０と、ＮＩＣ１１０のドライバ１２０と、仮想ＮＩＣ１３０と、仮想ＮＩＣ１３０の仮想ドライバ１４０と、ＴＣＰ/ＩＰ処理部１５０と、ＳＩＰクライアント処理部１６０と、アプリケーション処理部１７０とから構成される。また、ＳＩＰクライアント処理部１６０は、送受信処理部１６１と、暗号化/復号化処理部１６２と、ポリシー管理部１６３と、セッション管理部１６４と、認証/証明書管理部１６５と、ＳＩＰメッセージ処理部１６６とから構成される。仮想ＮＩＣ１３０は、１枚のＮＩＣ１１０に複数のＩＰアドレスを定義する。仮想ドライバ１４０は、複数のプログラムが同時にリソースを使用できるよう、ドライバ１２０をサポートし、仮想ＮＩＣ１３０がＮＩＣ１１０を使用するプログラムのために、ＮＩＣ１１０の状態を監視する。

図３において、セッション管理サーバ２００は、ネットワークインターフェースカード（ＮＩＣ）２１０と、ドライバ２２０と、ＴＣＰ/ＩＰ処理部２５０と、ＳＩＰクライアント処理部２６０とから構成される。また、ＳＩＰクライアント処理部２６０は、認証/証明書管理部２６５と、ＳＩＰメッセージ処理部２６６とから構成される。

図４において、クライアント１００のＳＩＰメッセージ処理部１６６は、セッション制御処理部１６６１と、ロケーション管理部１６６２と、ＡＯＲ解決処理部１６６３と、ＡＯＲ登録処理部１６６４とから構成される。

図５を参照して、クライアントとセッション管理サーバのハードウェアブロックを説明する。ここで、図５は、クライアントとセッション管理サーバのハードウェアブロック図である。

図５において、クライアント１００は、バス３２０に接続された中央演算装置（ＣＰＵ）３３０と、メモリ３４０と、ハードディスクドライブ（ＨＤＤ）３５０と、ＮＩＣ１１０と、入出力部３６０とから構成される。同様に、セッション管理サーバ２００は、バス３２０に接続された中央演算装置（ＣＰＵ）３３０と、メモリ３４０と、ハードディスクドライブ（ＨＤＤ）３５０と、ＮＩＣ２１０と、入出力部３６０とから構成される。

図２または図３と図５との対比から明らかなように、図２のＮＩＣ１１０または図３のＮＩＣ２１０以外の機能ブロックは、図５のＣＰＵ３３０が実行するプログラムにより、実現される。

図６を参照して、２台のクライアントとセッション管理サーバとの間の認証処理から、パケット送信までのシーケンスを説明する。ここで、図６は、２台のクライアントとセッション管理サーバとの間の認証処理から、パケット送信までを説明するシーケンス図である。

図６において、セッション管理サーバ２００に接続されたクライアント１００−Ａ、１００−Ｂの電源が投入されると、クライアント１００−Ａとセッション管理サーバ２００間およびクライアント１００−Ｂとセッション管理サーバ２００間で認証処理が実行される（Ｔ１０１、Ｔ１１１）。クライアント１００−Ａ、１００−Ｂは、セッション管理サーバ２００に対してログイン処理を行う。具体的には、クライアント１００−Ａ、１００−Ｂは、ログインメッセージであるＲＥＧＩＳＴＥＲを送信する（Ｔ１０２、Ｔ１１２）。ＲＥＧＩＳＴＥＲを受信したセッション管理サーバ２００は、ＲＥＧＩＳＴＯＲに含まれるロケーション情報をＳＩＰメッセージ処理部２６６に保持するＡＯＲ管理テーブル登録する。ここで、ロケーション情報とはクライアント１００のＳＩＰ−ＵＲＩ（ｓｉｐ：ｃｌｉｅｎｔＡ＠ａｂｃ．ｃｏｍまたはｓｉｐ：ｃｌｉｅｎｔＢ＠ａｂｃ．ｃｏｍ）と、ＳＩＰ通信ネットワーク３００に接続されたポートのＩＰアドレス（１９２．１６８．０．１または１９２．１６８．０．３）である。セッション管理サーバ２００は、２００ ＯＫをクライアント１００−Ａ、１００−Ｂにそれぞれ送信し（Ｔ１０３、Ｔ１１３）、ログイン処理は完結する。

クライアント１００−Ａ、１００−Ｂは、セッション管理サーバ２００に、拡張ＳＩＰメッセージであるＳＥＴＡＯＲを送信する（Ｔ１０４、Ｔ１１４）。ここで、ＳＥＴＡＯＲには、クライアント１００のＳＩＰ−ＵＲＩ（ｓｉｐ：ｃｌｉｅｎｔＡ＠ａｂｃ．ｃｏｍまたはｓｉｐ：ｃｌｉｅｎｔＢ＠ａｂｃ．ｃｏｍ）と、データ通信ネットワーク３１０に接続されたポートのＩＰアドレス（１９２．１６８．１．１または１９２．１６８．１．３）が記載されている。セッション管理サーバ２００は、ＳＩＰメッセージ処理部２６６に保持するＡＯＲ管理テーブルに、クライアント１００−Ａ、１００−ＢのＩＰアドレス（１９２．１６８．１．１および１９２．１６８．１．３）とＳＩＰ−ＵＲＩ（ｓｉｐ：ｃｌｉｅｎｔＡ＠ａｂｃ．ｃｏｍおよびｓｉｐ：ｃｌｉｅｎｔＢ＠ａｂｃ．ｃｏｍ）を関連づけて登録する。セッション管理サーバ２００は、２００ ＯＫをクライアント１００−Ａ、１００−Ｂにそれぞれ送信する（Ｔ１０５、Ｔ１１５）。以上により、クライアント１００のセッション管理サーバ２００へのログインを終了する。なお、クライアント１００−Ａのログイン（Ｔ１０１〜Ｔ１０５）と、クライアント１００−Ｂのログイン（Ｔ１１１〜Ｔ１１５）とは、互いに独立である。

クライアント１００−Ａのユーザが、アプリケーション処理部１７０のアプリケーションプログラムを立ち上げ、クライアント１００−Ｂへのデータ送信が必要な処理を行ったことを契機として、クライアント１００−Ａは、セッション管理サーバ２００にＡＯＲ取得要求メッセージ（ＧＥＴＡＯＲ）を送信する（Ｔ１２１）。ＧＥＴＡＯＲには、クライアント１００−ＡのＳＩＰ−ＵＲＩ（ｓｉｐ：ｃｌｉｅｎｔＡ＠ａｂｃ．ｃｏｍ）と、通信相手（クライアント１００−Ｂ）のＩＰアドレス（１９２．１６８．１．３）とが記載されている。

セッション管理サーバ２００は、ＧＥＴＡＯＲを受信すると通信相手のＩＰアドレスをキーにＡＯＲ管理テーブルを検索して、クライアント１００−ＢのＳＩＰ−ＵＲＩ（ｓｉｐ：ｃｌｉｅｎｔＢ＠ａｂｃ．ｃｏｍ）を含む２００ ＯＫをクライアント１００−Ａに送信する（Ｔ１２２）。

クライアント１００−Ａは、受信した２００ ＯＫに含まれた通信相手のＳＩＰ−ＵＲＩ（ｓｉｐ：ｃｌｉｅｎｔＢ＠ａｂｃ．ｃｏｍ）を送信先とするＩＮＶＩＴＥをセッション管理サーバ２００に送信する（Ｔ１２３）。セッション管理サーバ２００は、クライアント１００−Ａに１００Ｔｒｙｉｎｇを送信し（Ｔ１２４）、クライアント１００−ＢにＩＮＶＩＴＥを送信する（Ｔ１２５）。ＩＮＶＩＴＥを受信したクライアント１００−Ｂは、セッション管理サーバ２００に、一旦１００Ｔｒｙｉｎｇを送信し（Ｔ１２６）、さらに２００ ＯＫを送信する（Ｔ１２７）。

セッション管理サーバ２００は、クライアント１００−Ｂからの２００ ＯＫ受信により、２００ ＯＫをクライアント１００−Ａに送信する（Ｔ１２８）。クライアント１００−Ａは、セッション管理サーバ２００からの２００ ＯＫ受信により、クライアント１００−ＢのＳＩＰ−ＵＲＩ（ｓｉｐ：ｃｌｉｅｎｔＢ＠ａｂｃ．ｃｏｍ）を送信先とするＡＣＫをセッション管理サーバ２００に送信する（Ｔ１２９）。セッション管理サーバ２００は、クライアント１００−ＢにＡＣＫを送信する（Ｔ１３０）。

クライアント１００−ＢがＡＣＫを受信することによって、クライアント１００−Ａとクライアント１００−Ｂとの間のデータ通信ネットワーク３１０を介するデータ通信路が確立される。クライアント１００−Ａは、確立されたデータ通信路を介するパケットを送信する（Ｔ１３１）。

図７ないし図１２を参照して、クライアントの内部の動作を説明する。ここで、図７は起動時の認証ネゴシエーションを説明するシーケンス図である。図８は起動時のロケーション登録を説明するシーケンス図である。図９はＳＥＴＡＯＲの送信と応答受信を説明するシーケンス図である。図１０はＧＥＴＡＯＲの送信と応答受信を説明するシーケンス図である。図１１はＩＮＶＩＴＥの送信と応答受信とＡＣＫの送信を説明するシーケンス図である。図１２は終了時の認証ネゴシエーションと終了時のＳＥＴＡＯＲの送信と応答受信を説明するシーケンス図である。

図７において、クライアント１００の電源が供給されるとブートプログラムが起動され、ＳＩＰクライアント処理部１６０の各部が起動し、ポリシー管理部１６３がポリシー管理データを読み込む。ＳＩＰメッセージ処理部１６６は認証要求を認証/証明書管理部１６５に送信する（Ｔ１５１）。認証要求を受信した認証/証明書管理部１６５は、認証要求メッセージを組み立て、メッセージをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ１５２）。メッセージを受信したＴＣＰ/ＩＰ処理部１５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットを仮想ドライバ１４０に送信する（Ｔ１５３）。パケットを受信した仮想ドライバ１４０は、フレームを送受信処理部１６１に送信する（Ｔ１５４）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェック（暗号化要否）を問い合わせる（Ｔ１５５）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、「暗号化せず」を受信し（Ｔ１５６）、フレームをドライバ１２０に送信する（Ｔ１５７）。フレームを受信したドライバ１２０は、ＮＩＣ１１０から、セッション管理サーバ２００にパケットを送信する（Ｔ１５８）。

セッション管理サーバ２００からのパケットは、ＮＩＣ１１０を介してドライバ１２０で受信する（Ｔ１６１）。パケットを受信したドライバ１２０は、フレームを送受信処理部１６１に送信する（Ｔ１６２）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェック（受信パケットの問題有無）を問い合わせる（Ｔ１６３）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、ＯＫを受信し（Ｔ１６４）、フレームを仮想ドライバ１２０に送信する（Ｔ１６５）。仮想ドライバ１２０はドライバ１１０が受信したパケットをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ１６６）。パケットを受信したＴＣＰ/ＩＰ処理部１５０は、メッセージを取り出して、メッセージを認証/証明管理部１６５に送信する（Ｔ１６７）。メッセージを受信した認証/証明管理部１６５は、認証/証明書チェックを実施し、この場合問題ないこと認証処理終了として、ＳＩＰメッセージ処理部１６６に送信する（Ｔ１６８）。以上にて、クライアント１００とセッション管理サーバ２００との間の認証ネゴシエーションが終了する。

図８において、認証処理終了を受け取ったＳＩＰメッセージ処理部１６６は、ＲＥＧＩＳＴＥＲメソッドを生成し、メッセージをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ１７１）。メッセージを受信したＴＣＰ/ＩＰ処理部１５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットを仮想ドライバ１４０に送信する（Ｔ１７２）。パケットを受信した仮想ドライバ１４０は、フレームを送受信処理部１６１に送信する（Ｔ１７３）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェックを問い合わせる（Ｔ１７４）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、「暗号化せず」を受信し（Ｔ１７５）、フレームをドライバ１２０に送信する（Ｔ１７６）。フレームを受信したドライバ１２０は、ＮＩＣ１１０から、セッション管理サーバ２００にＲＥＧＩＳＴＥＲパケットを送信する（Ｔ１７７）。

セッション管理サーバ２００からの２００ ＯＫをＮＩＣ１１０を介してドライバ１２０で受信する（Ｔ１８１）。パケットを受信したドライバ１２０は、フレームを送受信処理部１６１に送信する（Ｔ１８２）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェックを問い合わせる（Ｔ１８３）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、ＯＫを受信し（Ｔ１８４）、フレームを仮想ドライバ１２０に送信する（Ｔ１８５）。仮想ドライバ１２０はドライバ１１０が受信したパケットをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ１８６）。パケットを受信したＴＣＰ/ＩＰ処理部１５０は、メッセージを取り出して、メッセージをＳＩＰメッセージ処理部１６６に送信する（Ｔ１８７）。以上にて、クライアント１００とセッション管理サーバ２００との間のシグナリングチャンネルの確立が終了する。

図９において、シグナリングチャネル確立のメッセージを受け取ったＳＩＰメッセージ処理部１６６は、ＳＥＴＡＯＲメソッドを生成し、メッセージをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ１９１）。メッセージを受信したＴＣＰ/ＩＰ処理部１５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットを仮想ドライバ１４０に送信する（Ｔ１９２）。パケットを受信した仮想ドライバ１４０は、フレームを送受信処理部１６１に送信する（Ｔ１９３）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェックを問い合わせる（Ｔ１９４）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、「暗号化せず」を受信し（Ｔ１９５）、フレームをドライバ１２０に送信する（Ｔ１９６）。フレームを受信したドライバ１２０は、ＮＩＣ１１０から、セッション管理サーバ２００にＳＥＴＡＯＲパケットを送信する（Ｔ１９７）。なお、セッション管理サーバの２００ ＯＫの送信以降は図８と同様なので、説明を省く。

図１０において、アプリケーション処理部１７０は、ユーザ操作に対応するメッセージをＴＣＰ/ＩＰ処理部１５０に送信する。メッセージを受信したＴＣＰ/ＩＰ処理部１５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットを仮想ドライバ１４０に送信する（Ｔ２０２）。パケットを受信した仮想ドライバ１４０は、フレームを送受信処理部１６１に送信する（Ｔ２０３）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェックと問い合わせる（Ｔ２０４）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、暗号化必要を受信し（Ｔ２０６）、ＳＩＰメッセージ処理部１０６に、ＡＯＲ解決要求を送信する（Ｔ２０６）。

ＡＯＲ解決要求を受け取ったＳＩＰメッセージ処理部１６６は、ＧＥＴＡＯＲメソッドを生成し、メッセージをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ２０７）。メッセージを受信したＴＣＰ/ＩＰ処理部１５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットを仮想ドライバ１４０に送信する（Ｔ２０８）。パケットを受信した仮想ドライバ１４０は、フレームを送受信処理部１６１に送信する（Ｔ２０９）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェックと問い合わせる（Ｔ２１０）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、暗号化せずを受信し（Ｔ２１１）、フレームをドライバ１２０に送信する（Ｔ２１２）。フレームを受信したドライバ１２０は、ＮＩＣ１１０から、セッション管理サーバ２００にＧＥＴＡＯＲパケットを送信する（Ｔ２１３）。なお、セッション管理サーバの２００ ＯＫの送信以降は図８と同様なので、説明を省く。

図１１において、ＧＥＴＡＯＲに対する２００ ＯＫを受け取ったＳＩＰメッセージ処理部１６６は、ＩＮＶＩＴＥメソッドを生成し、メッセージをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ２１１）。メッセージを受信したＴＣＰ/ＩＰ処理部１５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットを仮想ドライバ１４０に送信する（Ｔ２１２）。パケットを受信した仮想ドライバ１４０は、フレームを送受信処理部１６１に送信する（Ｔ２１３）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェックと問い合わせる（Ｔ２１４）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、「暗号化せず」を受信し（Ｔ２１５）、フレームをドライバ１２０に送信する（Ｔ２１６）。フレームを受信したドライバ１２０は、ＮＩＣ１１０から、セッション管理サーバ２００にＩＮＶＩＴＥパケットを送信する（Ｔ２１７）。セッション管理サーバの２００ ＯＫの送信からＳＩＰメッセージ処理部１６６による受信までは、図８と同様なので、説明を省く。

２００ ＯＫを受信したＳＩＰメッセージ処理部１６６は、ＡＣＫメソッドを生成し、メッセージをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ２２１）。メッセージを受信したＴＣＰ/ＩＰ処理部１５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットを仮想ドライバ１４０に送信する（Ｔ２２２）。パケットを受信した仮想ドライバ１４０は、フレームを送受信処理部１６１に送信する（Ｔ２２３）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェックと問い合わせる（Ｔ２２４）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、「暗号化せず」を受信し（Ｔ２２５）、フレームをドライバ１２０に送信する（Ｔ２２６）。フレームを受信したドライバ１２０は、ＮＩＣ１１０から、セッション管理サーバ２００にＡＣＫパケットを送信する（Ｔ２２７）。セッション管理サーバ２００は、相手のクライアントにＡＣＫパケットを送信することにより、クライアント間のデータ通信路によるセッションが確立された状態となる。

図１２において、アプリケーション処理部１７０は、アプリケーション終了をＳＩＰメッセージ処理部１６０に通知する（Ｔ２３０）。アプリケーション終了を受け取ったＳＩＰメッセージ処理部１６６は、ｅｘｐｉｒｅ＝０のＲＥＧＩＳＴＥＲメソッドを生成し、メッセージをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ２３１）。メッセージを受信したＴＣＰ/ＩＰ処理部１５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットを仮想ドライバ１４０に送信する（Ｔ２３２）。パケットを受信した仮想ドライバ１４０は、フレームを送受信処理部１６１に送信する（Ｔ２３３）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェックと問い合わせる（Ｔ２３４）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、「暗号化せず」を受信し（Ｔ２３５）、フレームをドライバ１２０に送信する（Ｔ２３６）。フレームを受信したドライバ１２０は、ＮＩＣ１１０から、セッション管理サーバ２００にｅｘｐｉｒｅ＝０のＲＥＧＩＳＴＥＲパケットを送信する（Ｔ２３７）。セッション管理サーバ２００は、ＡＯＲ管理テーブルから、ＲＥＧＩＳＴＥＲリクエストに記載されたＩＰアドレスと、ＳＩＰ−ＵＲＩを削除する。また、レジストラからも削除する。セッション管理サーバの２００ ＯＫの送信からＳＩＰメッセージ処理部１６６による受信までは、図８と同様なので、説明を省く。

２００ ＯＫを受信したＳＩＰメッセージ処理部１６６は、ｃｏｎｔａｃｔ行のＩＰアドレスの次にｍｏｄｅ＝ｄｅｌを記載したＳＥＴＡＯＲメソッドを生成し、メッセージをＴＣＰ/ＩＰ処理部１５０に送信する（Ｔ２４１）。メッセージを受信したＴＣＰ/ＩＰ処理部１５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットを仮想ドライバ１４０に送信する（Ｔ２４２）。パケットを受信した仮想ドライバ１４０は、フレームを送受信処理部１６１に送信する（Ｔ２４３）。フレームを受信した送受信処理部１６１は、ポリシー管理部１６３にポリシーチェックと問い合わせる（Ｔ２４４）。この場合、送受信処理部１６１は、ポリシー管理部１６３から、「暗号化せず」を受信し（Ｔ２４５）、フレームをドライバ１２０に送信する（Ｔ２４６）。フレームを受信したドライバ１２０は、ＮＩＣ１１０から、セッション管理サーバ２００にＳＥＴＡＯＲパケットを送信する（Ｔ２４７）。ＳＥＴＡＯＲリクエストを受信したセッション管理サーバ２００は、ＡＯＲ管理テーブルから、ＳＥＴＡＯＲリクエストに記載されたＩＰアドレスと、ＳＩＰ−ＵＲＩを削除する。セッション管理サーバの２００ ＯＫの送信からＳＩＰメッセージ処理部１６６による受信までは、図８と同様なので、説明を省く。２００ ＯＫを受信したＳＩＰメッセージ処理部１６６は、アプリケーション処理部１７０に、アプリケーション終了完了通知を送信する（Ｔ２５０）。

図１３ないし図１６を用いて、クライアントの動作を説明する。ここで、図１３と図１４はクライアントのＳＩＰクライアント処理部の動作フロー図である。図１５はクライアントのＴＣＰ/ＩＰ処理部の受信時の動作フロー図である。図１６はクライアントのＳＩＰメッセージ処理部のメッセージ受信部の動作フロー図である。

図１３において、仮想ドライバ１４０からのフレームを送受処理部１６１が受信したとき、フレームを送受処理部１６１は、まずポリシー管理部１６３に対して、暗号化が必要か問い合わせる（Ｓ３０１）。ポリシー管理部１６３からの回答が、「必要でない」ならば、そのままドライバ１２０へフレームを送信して（Ｓ３０２）、終了する。一方、ステップ３０１の回答が「必要」ならば、セッション管理部１６４に対して、セッション確立済みか確認する（Ｓ３０３）。確立済みならば、暗号化/復号化処理部１６２で暗号化処理（Ｓ３０４）のあと、ステップ３０２に遷移する。ステップ３０３で、確立していないならば、セッション管理部１６４に対して、シグナリング確立済みか確認する（Ｓ３０５）。確立していないならば、パケットを廃棄する（Ｓ３０６）。ステップ３０５で、確立済みならば、ＡＯＲ解決処理部１６６３に対して、あて先ＡＯＲが判明しているか確認する（Ｓ３０７）。判明しているならば、ステップ３０２に遷移する。一方、ステップ３０７で、判明していないならば、ＳＩＰメッセージ処理部１６６にＡＯＲ解決要求を送信して（Ｓ３０８）、終了する。

図１４において、ドライバ１２０からのフレームを送受処理部１６１が受信したとき、ポリシー管理部１６３に対して、ポリシーチェックの確認をする（Ｓ３２１）。ポリシー管理部１６３からの回答が、「ＮＧ」ならば、そのままパケットを廃棄して（Ｓ３２２）、終了する。一方、ステップ３２１の回答が「ＯＫ」ならば、暗号化/復号化処理部１６２に対して、暗号化されているかの確認をする（Ｓ３２３）。暗号化/復号化処理部１６２からの回答が、「暗号化されていない」ならば、そのままパケットを仮想ドライバ１４０に送信して（Ｓ３２４）、終了する。一方、ステップ３２３の回答が「暗号化されている」ならば、暗号化/復号化処理部１６２で復号化処理し（Ｓ３２５）、ステップ３２４に遷移する。

図１５において、仮想ドライバ１４０からのパケットを受信したＴＣＰ/ＩＰ処理部１５０は、ＴＣＰ/ＩＰ、Ｅｔｈｅｒフレームを分解する（Ｓ３３１）。ＴＣＰ/ＩＰ処理部１５０は、送信ポートによる処理の振り分けを実施し（Ｓ３３２）、メッセージを受信する（Ｓ３３３〜Ｓ３３５）。

図１６Ａにおいて、ＴＣＰ/ＩＰ処理部１５０より、メッセージを受信したＳＩＰメッセージ処理部１６６は、ＳＩＰメッセージヘッダ解析を実施する（Ｓ３４１）。ＩＮＶＩＴＥリクエストのとき、ＳＩＰメッセージ処理部１６６はパラメータチェックし実施する（Ｓ３４２）。ＮＧのとき、エラー応答を生成し（Ｓ３４３）、送受信処理部１６１からＴＣＰ/ＩＰ処理部へメッセージを送信して（Ｓ３４４）、終了する。ステップ３４２において、ＯＫのとき、セッション管理部１６４はセッション情報を登録する（Ｓ３４５）。ＳＩＰメッセージ処理部１６６は２００ ＯＫを生成し（Ｓ３４６）、ステップ３４４に遷移する。

ステップ３４１において、ＢＹＥリクエストのとき、セッション管理部１６４はセッション管理チェックを実施する（Ｓ３４８）。該当セッションがないとき、エラー応答を生成し（Ｓ３４９）、ステップ３４４に遷移する。ステップ３４８でセッションがあったとき、セッション管理部１６４はセッション情報を削除する（Ｓ３５０）。ＳＩＰメッセージ処理部１６６は２００ ＯＫを生成し（Ｓ３５１）、ステップ３４４に遷移する。

ステップ３４１において、２００ ＯＫのとき、セッション管理部１６４は成功応答解析実施する（Ｓ３５３）。ここで、成功応答解析とは２００ ＯＫに対応するリクエストの解析である。ステップ３５３でリクエストがＲＥＧＩＳＴＥＲのとき、ＲＥＧＩＳＴＥＲのｅｘｐｉｒｅが、「０」か判定する（Ｓ３５４）。「ｅｘｐｉｒｅ＝０」なら、アプリケーション処理部１７０にアプリケーション終了完了通知を送信し（Ｓ３５５）、終了する。ステップ３５４で「ｅｘｐｉｒｅ≠０」なら、レジストラ情報を登録し（Ｓ３５６）、ＳＥＴＡＯＲメソッドを生成し（Ｓ３５７）、ステップ３４４に遷移する。ステップ３５３でリクエストがＩＮＶＩＴＥのとき、ＳＩＰメッセージ処理部１６６は、ＡＣＫを生成し（Ｓ３５９）、ステップ３４４に遷移する。ステップ３５３でリクエストがＲＥＧＩＳＴＥＲまたはＩＮＶＩＴＥ以外のとき、Ａ１１（図１６Ｂ）に遷移する。

ステップ３４１において、ＡＣＫのとき、処理を終了する。
ステップ３４１において、上述以外のリクエストまたは応答のとき、エラー応答を生成し（Ｓ３６０）、ステップ３４４に遷移する。

図１６Ｂにおいて、ＳＩＰメッセージ処理部は１６６は、再び成功応答解析を行う（Ｓ３６１）。リクエストがＧＥＴＡＯＲのとき、ＡＯＲ解決処理部１６６３、ＡＯＲ登録処理を行う（Ｓ３６２）。ＳＩＰメッセージ処理部１６６は、ＩＮＶＩＴＥメソッドを生成し（Ｓ３６３）、送受信処理部１６１からＴＣＰ/ＩＰ処理部へメッセージを送信する（Ｓ３６４）。ステップ３６１で、リクエストがＳＥＴＡＯＲまたはＢＹＥならそのまま終了する。ステップ３６１で、リクエストが上述以外なら、リクエストを廃棄する。

図１７を用いて、セッション管理サーバの動作を説明する。ここで、図１７はセッション管理サーバのＳＩＰクライアント処理部の動作フロー図である。なお、図１７において、ＳＥＴＡＯＲはコンタクト行が１行のみを前提としている。複数のコンタクト行を含む場合、「ｍｏｄｅ=ｎｅｗ」（図３４Ｂで説明）を含む場合は、若干複雑になる。

図１７において、ＴＣＰ/ＩＰ処理部２５０からＳＩＰメッセージを受信したＳＩＰクライアント処理部２６０は、ＳＩＰメッセージ処理部２６６にてＳＩＰメッセージヘッダ解析を実施する（Ｓ４０１）。

ＳＩＰメッセージがＳＥＴＡＯＲのとき、ロケーション管理部１６６２はレジストラをチェックする（Ｓ４０２）。レジストラに登録が無いとき、ＳＩＰメッセージ処理部２６６は、エラー応答を生成し（Ｓ４０３）、ＴＣＰ/ＩＰ処理部２５０へＳＩＰメッセージを送信して（Ｓ４０４）、終了する。ステップ４０２で、レジストラに登録があるとき、ＳＩＰメッセージ処理部２６６は、パラメータチェックを実施する（Ｓ４０５）。ＮＧのとき、エラー応答を生成し（Ｓ４０６）、ステップ４０４に遷移する。ステップ４０５でＯＫのとき、ＳＩＰメッセージ処理部２６６は、ＳＥＴＡＯＲが登録か削除か判定する（Ｓ４０７）。登録のとき、ＡＯＲ登録処理部１６６４はＡＯＲを登録する（Ｓ４０８）。ＳＩＰメッセージ処理部２６６は、２００ ＯＫを生成し（Ｓ４０９）、ステップ４０４に遷移する。一方、ステップ４０６で削除のとき、ＡＯＲ登録処理部１６６４はＡＯＲを削除する（Ｓ４１０）。ＳＩＰメッセージ処理部２６６は、２００ ＯＫを生成し（Ｓ４１１）、ステップ４０４に遷移する。

ステップ４０１でＳＩＰメッセージがＲＥＧＩＳＴＥＲのとき、ＲＥＧＩＳＴＥＲメソッドの、ｅｘｐｉｒｅが「０」か判定する（Ｓ４２１）。「０」でなければ、レジストラ登録し（Ｓ４２２）、ＡＯＲ登録する（Ｓ４２３）。ＳＩＰメッセージ処理部２６６は、２００ ＯＫを生成し（Ｓ４２４）、ステップ４０４に遷移する。ステップ４２１で「０」のとき、ＡＯＲ解決処理部１６６３は、ＡＯＲ管理テーブルを検索し（Ｓ４２５）、検索がヒットしたとき、当該レコードを削除し（Ｓ４２６）、レジストラを削除する（Ｓ４２７）。ＳＩＰメッセージ処理部２６６は、２００ ＯＫを生成し（Ｓ４２８）、ステップ４０４に遷移する。なお、ステップ４２５でヒットしなかったとき、ステップ４２６をジャンプする。
ステップ４０１でＳＩＰメッセージがＧＥＴＡＯＲのとき、図１７ＢのＡ１２に遷移する。

図１７Ｂにおいて、図１７Ａのステップ４０１でＳＩＰメッセージがＧＥＴＡＯＲのとき、ＳＩＰメッセージ処理部２６６はパラメータチェックを実施し（Ｓ４３１）、ＮＧならエラー応答を生成し（Ｓ４３２）、ＴＣＰ/ＩＰ処理部２５０へ送信して（Ｓ４３３）、終了する。ステップ４３１でＯＫのとき、ＡＯＲ登録処理部１６６４はＡＯＲ管理テーブルを検索する（Ｓ４３４）。検索にヒットしないとき、ＳＩＰメッセージ処理部２６６は、エラー応答を生成し（Ｓ４３５）、ステップ４３３に遷移する。ステップ４３４で検索ヒットするとき、ＳＩＰメッセージ処理部２６６は、２００ ＯＫを生成し（Ｓ４３５）、ステップ４３３に遷移する。

図１８を参照して、ＡＯＲ管理テーブルを説明する。ここで、図１８はＡＯＲ管理テーブルを説明する図である。
図１８において、セッション管理サーバ２００が保持するＡＯＲ管理テーブル２７０Ａはクライアント１００のＩＰアドレス２７１ＡとＳＩＰ−ＵＲＩ ２７２Ａとを対応付けて管理している。図１８に記載されたＩＰアドレス２７１ＡとＳＩＰ−ＵＲＩ ２７２はＡ、ＲＥＧＩＳＴＥＲリクエストまたはＳＥＴＳＯＲリクエストに基づいて登録される。

図１９を参照して、ポリシー管理テーブルを説明する。ここで、図１９はポリシー管理テーブルを説明する図である。
図１９において、クライアント１００のポリシー管理部１６３が保持するポリシー管理テーブル１８０は、始点ＩＰアドレス１８１、そのサブネットマスク１８２、始点ポート番号１８３、終点ＩＰアドレス１８４、そのサブネットマスク１８５、終点ポート番号１８６、プロトコルタイプ１８７、ポリシー１８８とからなる。ポリシー管理テーブル１８０は、セッションを確立してもよいかの判定を行うテーブルである。また、ポリシー１８８の「ａｐｐｌｙ」は暗号を適用することを、「ｄｉｓｃａｒｄ」は廃棄を、「ｂｙｐａｓｓ」は平文を適用することを意味する。

図２０および図２１を参照して、ＳＩＰメッセージを説明する。ここで、図２０はＳＥＴＡＯＲメッセージを説明する図である。図２１はＩＮＶＩＴＥメッセージを説明する図である。

図２０Ａにおいて、セッション管理サーバのＡＯＲ管理テーブルにＳＩＰ−ＵＲＩとＩＰアドレスの対を書き込むＳＥＴＡＯＲメッセージは、リクエストラインにＳＩＰメッセージ種類を示す「ＳＥＴＡＯＲ」を含み、ＦｒｏｍヘッダおよびＴｏヘッダには、クライアント１００−ＡのＳＩＰ−ＵＲＩであるｃｌｉｅｎｔＡ＠ａｂｃ．ｃｏｍを含み、Ｃｏｎｔａｃｔ行にはクライアント１００−ＡのＩＰアドレス１９２．１６８．０．１および１９２．１６８．１．１を含んでいる。なお、クライアント１００−ＡのＩＰアドレス１９２．１６８．０．１は、ＲＥＧＩＳＴＥＲリクエストでもＡＯＲ管理テーブルに登録されるが、ＳＥＴＡＯＲに含んでいても良い。

図２０Ｂにおいて、セッション管理サーバのＡＯＲ管理テーブルにＳＩＰ−ＵＲＩとＩＰアドレスの対を書き込むＳＥＴＡＯＲメッセージは、セッション管理サーバのＡＯＲ管理テーブルからＳＩＰ−ＵＲＩとＩＰアドレスの対を削除することも可能である。すなわち、Ｃｏｎｔａｃｔ行にはクライアント１００−ＡのＩＰアドレス１９２．１６８．０．１および１９２．１６８．１．１に続けて「ｍｏｄｅ＝ｄｅｌ」を含んでいる。この記載により、セッション管理サーバのＡＯＲ管理テーブルからＳＩＰ−ＵＲＩとＩＰアドレスの対を削除する。なお、追加と削除は同じ、ＳＥＴＡＯＲリクエストで可能である。

図２１において、通信相手にセッションへの参加を招待する要求メッセージであるＩＮＶＩＴＥメッセージは、リクエストラインにＳＩＰメッセージ種類を示す「ＩＮＶＩＴＥ」を含み、Ｆｒｏｍヘッダにクライアント１００−ＡのＳＩＰ−ＵＲＩであるｃｌｉｅｎｔＡ＠ａｂｃ．ｃｏｍを含み、Ｔｏヘッダにクライアント１００−ＢのＳＩＰ−ＵＲＩであるｃｌｉｅｎｔＢ＠ａｂｃ．ｃｏｍを含む。ここで、Ｆｒｏｍヘッダには送信元クライアントのＵＲＩ、Ｔｏヘッダには受信元クライアントのＵＲＩが記載されている。また、ＩＮＶＩＴＥメッセージボディのｃ行には、送信元であるクライアント１００−Ａのデータ通信ネット３１０に接続されたポートのＩＰアドレス １９２．１６８．１．１を含んでいる。

本実施例に拠れば、クライアントにＳＩＰを実装し、セッション管理管理サーバにＳＥＴＡＯＲメソッドを使用して、クライアントがデータ通信で使用するＩＰアドレスとＳＩＰ−ＵＲＩを登録する事により、当該セッション管理サーバにＲＥＧＩＳＴＥＲ登録されていないポートでも、セキュアな通信が可能となる。

なお、上述した実施例ではＲＥＧＩＳＴＥＲリクエストを拡張して、ＲＥＧＩＳＴＥＲリクエストでもＡＯＲ管理テーブルを更新するとした。これは、ＧＥＴＡＯＲリクエストが常にＡＯＲ管理テーブルのみを参照すればよいからである。しかし、ＲＥＧＩＳＴＥＲリクエストでは、レジストラのみの更新として、レジストラを参照するＧＥＴＡＯＲとＡＯＲ管理テーブルを参照するＧＥＴＡＯＲを別に定義しても良い。また、上述したＳＥＴＡＯＲリクエストによれば、ＡＯＲ管理テーブルのみを参照するＧＥＴＡＯＲリクエストであっても良い。

図２２はネットワークのブロック図である。図２２において、制御装置５００−Ａ、セッション管理サーバ２００、制御装置５００−Ｂは、ＳＩＰ通信ネットワーク３００で接続されている。また、制御装置５００−Ａと、クライアント１００−Ｃとクライアント１００−Ｄとは、データ通信ネットワーク３１０−１で接続されている。同様に、制御装置５００−Ｂと、クライアント１００−Ｅとクライアント１００−Ｆとは、データ通信ネットワーク３１０−１で接続されている。制御装置（Gateway）５００は、ＳＩＰ通信に使用するＩＰアドレス（１９２．１６８．０．１または１９２．１６８．０．２）とＡＯＲ形式の識別子であるＳＩＰ−ＵＲＩ（ｓｉｐ：ｇｗＡ＠ａｂｃ．ｃｏｍまたはｓｉｐ：ｇｗＢ＠ａｂｃ．ｃｏｍ）、データ通信に使用するＩＰアドレス（１９２．１６８．１．１または１９２．１６８．１．２）を備える。セッション管理サーバ２００は、ＳＩＰ通信に使用するＩＰアドレス（１９２．１６８．０．２）と識別子（ａｂｃ．ｃｏｍ）を備える。クライアント４００はデータ通信に使用するＩＰアドレス（１９２．１６８．１．２、１９２．１６８．１．３、１９２．１６８．２．２または１９２．１６８．２．３）を備える。

図２３および図４を参照して制御装置の機能ブロックを説明する。ここで、図２３は制御装置の機能ブロック図である。

図２３において、制御装置５００は、ネットワークインターフェースカード（ＮＩＣ）５１０−Ａ、５１０−Ｂと、ＮＩ５１１０のドライバ５２０と、ＴＣＰ/ＩＰ処理部５５０と、ＳＩＰクライアント処理部５６０と、アプリケーション処理部５７０とから構成される。また、ＳＩＰクライアント処理部５６０は、送受信処理部５６１と、暗号化/復号化処理部５６２と、ポリシー管理部５６３と、セッション管理部５６４と、認証/証明書管理部５６５と、ＳＩＰメッセージ処理部５６６とから構成される。
制御装置５００のＳＩＰメッセージ処理部５６６は、実施例１の図４で説明したＳＩＰメッセージ処理部１６６と同様な構成である。

図２４を参照して、クライアントの機能ブロックを説明する。ここで、図２４は実施例２のクライアントの機能ブロック図である。図２４において、クライアント４００は、ＮＩＣ４１０、ドライバ４２０、ＴＣＰＩＰ処理部４５０、アプリケーション部４７０から構成される。

図２５を参照して、制御装置のハードウェアブロックを説明する。ここで、図２５は制御装置のハードウェアブロック図である。図２５において、制御装置５００は、バス３２０に接続された中央演算装置（ＣＰＵ）３３０と、メモリ３４０と、ハードディスクドライブ（ＨＤＤ）３５０と、ＮＩＣ５１０−Ａ、５１０−Ｂと、入出力部３６０とから構成される。なお、クライアント装置４００のハードウェアブロック図は、図５と同様である。

図２３と図２５、図２４と図５との対比から明らかなように、図２３のＮＩＣ５１０または図２４のＮＩＣ４１０以外の機能ブロックは、図２５または図５のＣＰＵ３３０が実行するプログラムにより、実現される。

図２６を参照して、２台のクライアントと２台の制御装置とセッション管理サーバとの間の認証処理から、パケット送信までのシーケンスを説明する。ここで、図２６は、２台のクライアントと２台の制御装置とセッション管理サーバとの間の認証処理から、パケット送信までを説明するシーケンス図である。

図２６において、セッション管理サーバ２００に接続された制御装置５００−Ａ、５００−Ｂの電源が投入されると、制御装置５００−Ａとセッション管理サーバ２００間および制御装置５００−Ｂとセッション管理サーバ２００間で認証処理が実行される（Ｔ５０１、Ｔ５１１）。制御装置５００−Ａ、５００−Ｂは、セッション管理サーバ２００に対してログイン処理を行う。具体的には、制御装置５００−Ａ、５００−Ｂは、ログインメッセージであるＲＥＧＩＳＴＥＲを送信する（Ｔ５０２、Ｔ５１２）。ＲＥＧＩＳＴＥＲを受信したセッション管理サーバ２００は、ＲＥＧＩＳＴＯＲに含まれるロケーション情報をレジストラに登録し、２００ ＯＫを制御装置５００−Ａ、５００−Ｂにそれぞれ送信し（Ｔ５０３、Ｔ５１３）、ログイン処理は完結する。

制御装置５００−Ａ、５００−Ｂは、セッション管理サーバ２００に、拡張ＳＩＰメッセージであるＳＥＴＡＯＲを送信する（Ｔ５０４、Ｔ５１４）。ここで、ＳＥＴＡＯＲには、制御装置５００のＳＩＰ−ＵＲＩ（ｓｉｐ：ｇｗＡ＠ａｂｃ．ｃｏｍまたはｓｉｐ：ｇｗＢ＠ａｂｃ．ｃｏｍ）と各ポートのＩＰアドレス（１９２．１６８．０．１、１９２．１６８．１．１または１９２．１６８．０．３、１９２．１６８．２．１）、配下のクライアントのＩＰアドレス（１９２．１６８．１．２、１９２．１６８．１．３または１９２．１６８．２．２、１９２．１６８．２．３）が記載されている。セッション管理サーバ２００は、ＳＩＰメッセージ処理部５６６に保持するＡＯＲ管理テーブルに、制御装置５００−Ａ、５００−Ｂの各ポートのＩＰアドレスおよび制御装置５００配下のクライアントのＩＰアドレスと、ＳＩＰ−ＵＲＩ（ｓｉｐ：ｇｗＡ＠ａｂｃ．ｃｏｍおよびｓｉｐ：ｇｗＢ＠ａｂｃ．ｃｏｍ）とを関連づけて登録する。セッション管理サーバ２００は、２００ ＯＫを制御装置５００−Ａ、５００−Ｂにそれぞれ送信する（Ｔ５０５、Ｔ５１５）。以上により、制御装置５００のセッション管理サーバ２００へのログインを終了する。
なお、制御装置５００−Ａのログイン（Ｔ５０１〜Ｔ５０５）と、制御装置５００−Ｂのログイン（Ｔ５１１〜Ｔ５１５）とは、互いに独立である。

クライアント４００−Ｃのユーザが、アプリケーション処理部４７０のアプリケーションプログラムを立ち上げ、クライアント４００−Ｆへのデータ送信が必要な処理を行ったことを契機として、クライアント４００−Ｃは、パケットを制御装置５００−Ａに送信する（Ｔ５２０）。制御装置５００−Ａは、セッション管理サーバ２００にＡＯＲ取得要求メッセージ（ＧＥＴＡＯＲ）を送信する（Ｔ５２１）。ＧＥＴＡＯＲには、制御装置５００−ＡのＳＩＰ−ＵＲＩ（ｓｉｐ：ｇｗＡ＠ａｂｃ．ｃｏｍ）と、通信相手（クライアント４００−Ｆ）のＩＰアドレス（１９２．１６８．２．３）とが記載されている。

セッション管理サーバ２００は、ＧＥＴＡＯＲを受信すると通信相手のＩＰアドレスをキーにＡＯＲ管理テーブルを検索して、制御装置５００−ＢのＳＩＰ−ＵＲＩ（ｓｉｐ：ｇｗＢ＠ａｂｃ．ｃｏｍ）を含む２００ ＯＫを制御装置５００−Ａに送信する（Ｔ５２２）。

制御装置５００−Ａは、受信した２００ ＯＫに含まれた通信相手のＳＩＰ−ＵＲＩ（ｓｉｐ：ｇｗＢ＠ａｂｃ．ｃｏｍ）を送信先とするＩＮＶＩＴＥをセッション管理サーバ２００に送信する（Ｔ５２３）。セッション管理サーバ２００は、制御装置５００−Ａに暫定応答である１００Ｔｒｙｉｎｇを送信し（Ｔ５２４）、制御装置５００−ＢにＩＮＶＩＴＥを送信する（Ｔ５２５）。ＩＮＶＩＴＥを受信した制御装置５００−Ｂは、セッション管理サーバ２００に、暫定応答である１００ Ｔｒｙｉｎｇを送信し（Ｔ５２６）、さらに２００ ＯＫを送信する（Ｔ５２７）。

セッション管理サーバ２００は、制御装置５００−Ｂからの２００ ＯＫ受信により、２００ ＯＫを制御装置５００−Ａに送信する（Ｔ５２８）。制御装置５００−Ａは、セッション管理サーバ２００からの２００ ＯＫ受信により、制御装置５００−ＢのＳＩＰ−ＵＲＩ（ｓｉｐ：ｇｗＢ＠ａｂｃ．ｃｏｍ）を送信先とするＡＣＫをセッション管理サーバ２００に送信する（Ｔ５２９）。セッション管理サーバ２００は、制御装置５００−ＢにＡＣＫを送信する（Ｔ５３０）。制御装置５００−ＢがＡＣＫを受信することによって、制御装置５００−Ａと制御装置５００−Ｂとの間のＳＩＰ通信ネットワーク３００を介するデータ通信路が確立される。

制御装置５００−Ａは、確立されたデータ通信路を介するパケットを制御装置５００−Ｂに送信する（Ｔ５３１）。パケットを受信した制御装置５００−Ｂは、クライアント４００−４にパケットを送信する（Ｔ５３２）。

図２７と図２８を参照して、制御装置の内部の動作を説明する。ここで、図２７は起動時の認証ネゴシエーションを説明するブロック図である。図２８はＧＥＴＡＯＲないしＩＮＶＩＴＥとそれらの応答を説明するシーケンス図である。

図２７において、制御装置５００の電源が供給されるとブートプログラムが起動され、ＳＩＰクライアント処理部５６０の各部が起動し、ポリシー管理部５６３がポリシー管理データを読み込む。ＳＩＰメッセージ処理５１６６は認証要求を認証/証明書管理部５６５に送信する（Ｔ６０１）。認証要求を受信した認証/証明書管理部５６５は、認証要求メッセージを組み立て、メッセージをＴＣＰ/ＩＰ処理部５５０に送信する（Ｔ６０２）。メッセージを受信したＴＣＰ/ＩＰ処理部５５０はＴＣＰ/ＩＰフレーム、Ｅｔｈｅｒフレームを組み立て、パケットをドライバ５１０−Ｂに送信する（Ｔ６０３）。パケットを受信したドライバ５１０−Ｂはセッション管理サーバ２００にパケットを送信する（Ｔ６０４）。

セッション管理サーバ２００は、この場合認証ＯＫのパケットを、ドライバ５１０−Ｂに送信する（Ｔ６０５）。ドライバ５１０−ＢはこのパケットをＴＣＰ/ＩＰ処理部５５０に転送する（Ｔ６０６）。ＴＣＰ/ＩＰ処理部５５０はメッセージを取り出し、取り出したメッセージを認証/証明書管理部５６５に送信する。認証/証明書管理部５６５は、この場合認証ＯＫなので、認証処理終了を送信し（Ｔ６０８）、認証ネゴシエーションを終了する。

図２８において、クライアント４００−Ｃがクライアント４００−Ｆ宛てのパケットを送信する（Ｔ６１１）。パケットを受信したドライバ５２０−Ａは、フレームを取り出して、ポリシー管理部５６３に送信する（Ｔ６１２）。ポリシー管理部５６３は、ポリシー管理テーブルを参照して、この場合暗号化要と判断し、暗号化/復号化処理部５６２にパケットを送信する（Ｔ６１３）。暗号化/復号化処理部５６２は、セッション確立済みか、またシグナリング確立済みか判定する。この場合、セッション未確立済、かつシグナリング確立済みなので、暗号化/復号化処理部５６２は、ＳＩＰメッセージ処理部５６６にパケットを送信する（Ｔ６１４）。ＳＩＰメッセージ処理部５６６は、ＧＥＴＡＯＲリクエストを生成して、ＴＣＰ/ＩＰ処理部５５０に送信する（Ｔ６１５）。ＴＣＰ/ＩＰ処理部５５０は、パケットを生成して、ドライバ５２０−Ｂに送信する（Ｔ６１６）。ドライバ５２０−Ｂは、フレームを組み立て、ＧＥＴＡＯＲメッセージをセッション管理サーバ２００に送信する（Ｔ６１７）。

なお、ＧＥＴＡＯＲメッセージの送信の詳細およびＳＥＴＡＯＲメッセージの送信の詳細は、図９および図１０において、アプリケーション処理部１７０をクライアント４００−Ｃと、ＳＩＰメッセージ処理部１６６をＳＩＰメッセージ処理部５６６と、認証/証明書管理部１６５を認証/証明書管理部５６５と、ＴＣＰ/ＩＰ処理部１５０をＴＣＰ/ＩＰ処理部５５０と、仮想ドライバ１４０をドライバ５２０−Ａと、ポリシー管理部１６３をポリシー管理部５６３と、ドライバ２００をドライバ５２０−Ｂと読み替えたものと同一である。

図２８に戻って、ＧＥＴＡＯＲメッセージを受信したセッション管理サーバ２００は、２００ ＯＫをドライバ５２０−Ｂに送信する（Ｔ６２１）。ドライバ５２０−Ｂは、受信した２００ ＯＫが自ＩＰアドレス宛か判定する（Ｔ６２２）。この場合、自ＩＰアドレス宛なので、ドライバ５２０−Ｂは、メッセージをＳＩＰメッセージ処理部５６６に送信する（Ｔ６２３）。ＳＩＰメッセージ処理部５６６は、受信した２００ ＯＫが、ＧＥＴＡＯＲに対応することを判定し、２００ ＯＫに含まれるＳＩＰ−ＵＲＩを保存する。ＳＩＰメッセージ処理部５６６は、ＩＮＶＩＴＥリクエストを生成して、ＴＣＰ/ＩＰ処理部５５０に送信する（Ｔ６２６）。ＴＣＰ/ＩＰ処理部５５０は、パケットを生成して、ドライバ５２０−Ｂに送信する（Ｔ６２７）。ドライバ５２０−Ｂは、フレームを組み立て、ＩＮＶＩＴＥメッセージをセッション管理サーバ２００に送信する（Ｔ６２８）。

ＩＮＶＩＴＥメッセージを受信したセッション管理サーバ２００は、クライアント４００−Ｆからの２００ ＯＫを受信して、２００ ＯＫをドライバ５２０−Ｂに送信する（Ｔ６３１）。ドライバ５２０−Ｂは、受信した２００ ＯＫが自ＩＰアドレス宛か判定する（Ｔ６３２）。この場合、自ＩＰアドレス宛なので、ドライバ５２０−Ｂは、メッセージをＳＩＰメッセージ処理部５６６に送信する（Ｔ６３３）。ＳＩＰメッセージ処理部５６６は、受信した２００ ＯＫが、ＩＮＶＩＴＥに対応することを判定し、セッション確立完了を、暗号化/復号化処理部５６２に送信する（Ｔ６３４）。ＳＩＰメッセージ処理部５６６は、ＡＣＫ応答を生成して、ＴＣＰ/ＩＰ処理部５５０に送信する（Ｔ６３５）。ＴＣＰ/ＩＰ処理部５５０は、パケットを生成して、ドライバ５２０−Ｂに送信する（Ｔ６３６）。ドライバ５２０−Ｂは、フレームを組み立て、ＡＣＫ応答をセッション管理サーバ２００に送信する（Ｔ６３７）。

以上の手順で、クライアント４００−Ｃとクライアント４００−Ｆの間のセッション（データチャネル）が確立された。なお、ＩＮＶＩＴＥリクエストに対する２００ ＯＫおよびＡＣＫの詳細は、Ｔ６２２とＴ６３２を除いて、図１１と同様である。ここで、Ｔ６２２とＴ６３２は、制御装置５００がクライアント４００を接続しているために必要な判断である。

以下、図２９ないし図３２を参照して、制御装置の各機能ブロックの動作を説明する。ここで、図２９はドライバの動作を説明するフロー図である。図３０はポリシー管理部の動作を説明するフロー図である。図３１は暗号化/復号化処理部の動作を説明するフロー図である。図３２はＳＩＰメッセージ処理部の動作を説明するフロー図である。なお、ここでは実施例１と異なる点についてのみ、説明する。

図２９において、ドライバ５２０−Ｂが、ＮＩＣ５１０−Ｂからパケットを受信すると、ＴＣＰ/ＩＰ処理部でＴＣＰ/ＩＰフレームおよびＥｔｈｅｒフレームを分解する（Ｓ７０１）。ドライバ５２０−Ｂは、自装置のＩＰアドレス宛か判定する（Ｓ７０２）。ドライバ５２０−Ｂは、自ＩＰアドレス宛ならばＳＩＰメッセージ処理部へフレームを送信する（Ｓ７０３）。一方、ステップ７０２で自ＩＰアドレス宛でないならば、ドライバ５２０−Ｂは、ポリシー管理部へフレームを送信する（Ｓ７０４）。

図３０において、ポリシー管理部５６３はドライバ５２０−Ａからフレームを受信すると、ポリシー管理テーブルを参照し、ポリシーを選択する（Ｓ７１１）。選択されたポリシーが「Ａａｐｐｌｙ」ならば、ポリシー管理部５６３は、パケットを暗号化/復号化処理部５６２に送信する（Ｓ７１２）。「ｂｙｐａｓｓ」ならば、ポリシー管理部５６３は、パケットをドライバ５２０−Ｂに送信する（Ｓ７１３）。「ｄｉｓｃａｒｄ」ならば、ポリシー管理部５６３は、パケットを廃棄する（Ｓ７１４）。

図３１において、ドライバ５２０−Ａからのパケットを受信したとき、暗号化/復号化処理部５６２は、セッション管理部５６４にセッション確立済みか問合せる（Ｓ７２１）。確立済みなら、暗号化/復号化処理部５６２は、暗号化処理を実施し（Ｓ７２２）、ＴＣＰ/ＩＰ処理部５５０にメッセージを送信する（Ｓ７２３）。ステップ７２１で確立していないなら、ドライバ５２０−Ａは、セッション管理部５６４にシグナリング確立済みか問い合せる（Ｓ７２４）。確立済みなら、暗号化/復号化処理部５６２は、ＳＩＰメッセージ処理部５６６にメッセージを送信する（Ｓ７２５）。ステップ７２４で確立していないなら、ドライバ５２０−Ａは、パケットを廃棄する（Ｓ７２６）。

図３２において、暗号化/復号化処理部５６２からパケットを受信したとき、ＳＩＰメッセージ処理部５６６は、宛先ＡＯＲが判明しているか確認する（Ｓ７３１）。判明していないとき、ＧＥＴＡＯＲメッソッドを生成し（Ｓ７３２）、ＴＣＰ/ＩＰ処理部５５０にメッセージを送信する（Ｓ７３４）。一方、ステップ７３１で判明しているとき、ＳＩＰメッセージ処理部５６６は、ＩＮＶＩＴＥメッソッドを生成し（Ｓ７３３）、ステップ７３４に遷移する。

図３３を参照して、ＡＯＲ管理テーブルを説明する。ここで、図３３はＡＯＲ管理テーブルを説明する図である。
図３３において、セッション管理サーバ２００が保持するＡＯＲ管理テーブル２７０Ｂは、制御装置５００とクライアント４００のＩＰアドレス２７１Ｂと、制御装置５００のＳＩＰ−ＵＲＩ ２７２Ｂとを対応付けて管理している。図１８に記載されたＩＰアドレス２７１ＢとＳＩＰ−ＵＲＩ ２７２Ｂは、ＳＥＴＡＯＲリクエストに基づいて登録される。
なお、ポリシー管理テーブルは図１９を用いて説明した通りである。

図３４および図３５を参照して、ＳＩＰメッセージを説明する。ここで、図３４はＳＥＴＡＯＲメッセージを説明する図である。図３５はＩＮＶＩＴＥメッセージを説明する図である。

図３４Ａにおいて、セッション管理サーバのＡＯＲ管理テーブルにＳＩＰ−ＵＲＩとＩＰアドレスの対を書き込むＳＥＴＡＯＲメッセージは、リクエストラインにＳＩＰメッセージ種類を示す「ＳＥＴＡＯＲ」を含み、ＦｒｏｍヘッダおよびＴｏヘッダには、制御装置５００−ＡのＳＩＰ−ＵＲＩであるｇｗＡ＠ａｂｃ．ｃｏｍを含み、Ｃｏｎｔａｃｔ行には制御装置５００−ＡのＩＰアドレス１９２．１６８．０．１および１９２．１６８．１．１ならびにクライアント４００−Ｃ、４００−ＤのＩＰアドレス１９２．１６８．１．２および１９２．１６８．１．３を含んでいる。

図３４Ｂにおいて、セッション管理サーバのＡＯＲ管理テーブルにＳＩＰ−ＵＲＩとＩＰアドレスの対を書き込むＳＥＴＡＯＲメッセージは、セッション管理サーバのＡＯＲ管理テーブルからＳＩＰ−ＵＲＩとＩＰアドレスの対を一括削除することも可能である。すなわち、Ｃｏｎｔａｃｔ行には制御装置５００−ＡのＩＰアドレス１９２．１６８．１．１に続けて「ｍｏｄｅ＝ｎｅｗ」を含んでいる。この記載により、セッション管理サーバのＡＯＲ管理テーブルから当該ＳＩＰ−ＵＲＩに対応する全てのＩＰアドレスの対を削除したあと、Ｃｏｎｔａｃｔ行に記載されたＩＰアドレスを追加する。制御装置５００は、配下のクライアントの数か頻繁に増減するので、「ｍｏｄｅ＝ｎｅｗ」により、セッション管理サーバのＡＯＲ管理テーブルの内容を自装置と合わせることができる。なお、「ｍｏｄｅ＝ｎｅｗ」はどのＣｏｎｔａｃｔ行に記載されても、同じ結果となる。

図３５において、通信相手にセッションへの参加を招待する要求メッセージであるＩＮＶＩＴＥメッセージは、リクエストラインにＳＩＰメッセージ種類を示す「ＩＮＶＩＴＥ」を含み、Ｆｒｏｍヘッダに制御装置５００−ＡのＳＩＰ−ＵＲＩであるｇｗＡ＠ａｂｃ．ｃｏｍを含み、Ｔｏヘッダに制御装置５００−ＢのＳＩＰ−ＵＲＩであるｇｗＢ＠ａｂｃ．ｃｏｍを含む。ここで、Ｆｒｏｍヘッダには送信元クライアントのＵＲＩ、Ｔｏヘッダには受信元クライアントのＵＲＩが記載されている。また、ＩＮＶＩＴＥメッセージボディのｃ行には、送信元である制御装置５００−Ａに接続されたクライアント４００−ＣのＩＰアドレス １９２．１６８．１．２を含んでいる。

本実施例に拠れば、セッション管理管理サーバにＳＥＴＡＯＲメソッドにより、クライアントのＩＰアドレスとクライアントを接続する制御装置のＳＩＰ−ＵＲＩを登録する事により、クライアントにＳＩＰを実装しなくとも、セキュアな通信が可能となる。

ネットワークのブロック図である。 クライアントの機能ブロック図である。 セッション管理装置の機能ブロック図である。 セッション管理装置のＳＩＰメッセージ処理部の機能ブロック図である。 クライアントとセッション管理サーバのハードウェアブロック図である。 ２台のクライアントとセッション管理サーバとの間の認証処理から、パケット送信までを説明するシーケンス図である。 起動時の認証ネゴシエーションを説明するシーケンス図である。 起動時のロケーション登録を説明するシーケンス図である。 ＳＥＴＡＯＲの送信と応答受信を説明するシーケンス図である。 ＧＥＴＡＯＲの送信と応答受信を説明するシーケンス図である。 ＩＮＶＩＴＥの送信と応答受信とＡＣＫの送信を説明するシーケンス図である。 終了時の認証ネゴシエーションと終了時のＳＥＴＡＯＲの送信と応答受信を説明するシーケンス図である。 クライアントのドライバの動作フロー図である。 クライアントの仮想ドライバの動作フロー図である。 クライアントのＴＣＰ/ＩＰ処理部の受信時の動作フロー図である。 クライアントのＳＩＰメッセージ処理部のメッセージ受信部の動作フロー図（その１）である。 クライアントのＳＩＰメッセージ処理部のメッセージ受信部の動作フロー図（その２）である。 セッション管理サーバのＳＩＰクライアント処理部の動作フロー図（その１）である。 セッション管理サーバのＳＩＰクライアント処理部の動作フロー図（その２）である。 ＡＯＲ管理テーブルを説明する図である。 ポリシー管理テーブルを説明する図である。 ＳＥＴＡＯＲメッセージを説明する図である。 ＳＥＴＡＯＲメッセージ（削除）を説明する図である。 ＩＮＶＩＴＥメッセージを説明する図である。 ネットワークのブロック図である。 制御装置の機能ブロック図である。 クライアントの機能ブロック図である。 制御装置のハードウェアブロック図である。 ２台のクライアントと２台の制御装置とセッション管理サーバとの間の認証処理から、パケット送信までを説明するシーケンス図である。 起動時の認証ネゴシエーションを説明するブロック図である。 ＧＥＴＡＯＲないしＩＮＶＩＴＥとそれらの応答を説明するシーケンス図である。 ドライバの動作を説明するフロー図である。 ポリシー管理部の動作を説明するフロー図である。 暗号化/復号化処理部の動作を説明するフロー図である。 ＳＩＰメッセージ処理部の動作を説明するフロー図である。 ＡＯＲ管理テーブルを説明する図である。 ＳＥＴＡＯＲメッセージ（追加）を説明する図である。 ＳＥＴＡＯＲメッセージ（一括削除＋追加）を説明する図である。 ＩＮＶＩＴＥメッセージを説明する図である。

符号の説明

１００…クライアント、１１０…ネットワークインターフェースカード（ＮＩＣ）、１２０…ドライバ、１３０…仮想ＮＩＣ、１４０…仮想ドライバ、１５０…ＴＣＰ/ＩＰ処理部、１６０…ＳＩＰクライアント処理部、１７０…アプリケーション処理部、１８０…ポリシー管理テーブル、２００…セッション管理サーバ、２１０…ネットワークインターフェースカード（ＮＩＣ）、２２０…ドライバ、２５０…ＴＣＰ/ＩＰ処理部、２６０…ＳＩＰクライアント処理部、２７０…ＡＯＲ管理テーブル、３００…ＳＩＰ通信ネットワーク、３１０…データ通信ネットワーク、３２０…バス、３３０…中央演算装置（ＣＰＵ）、３４０…メモリ、３５０…ハードディスクドライブ（ＨＤＤ）、３６０…入出力部、４００…クライアント、４１０…ネットワークインターフェースカード（ＮＩＣ）、４２０…ドライバ、４５０…ＴＣＰ/ＩＰ処理部、４７０…アプリケーション処理部、５００…制御装置、５１０…ネットワークインターフェースカード（ＮＩＣ）、５２０…ドライバ、５５０…ＴＣＰ/ＩＰ処理部、５６０…ＳＩＰクライアント処理部、５７０…アプリケーション処理部、５８０…ポリシー管理テーブル。

Claims (5)

1. セッション管理サーバと接続され、該セッション管理サーバとＳＩＰによる通信を行う通信装置において、
   前記セッション管理サーバに通信に用いるＩＰアドレスとＩＤとを送信することを特徴とする通信装置。
2. 請求項１に記載の通信装置であって、
   配下にクライアントを備え、前記ＩＰアドレスは前記クライアントのＩＰアドレスであることを特徴とする通信装置。
3. 第１の通信装置と接続され、前記第１の通信装置とＳＩＰによる通信を行うセッション管理サーバにおいて、
   前記第１の通信装置から受信した前記通信装置が通信に用いるＩＰアドレスとＩＤと保持することを特徴とするセッション管理サーバ。
4. 請求項３に記載のセッション管理サーバであって、
   さらに第２の通信装置と接続され、
   前記第２の通信装置から受信した前記ＩＰアドレスを記載した要求に基づいて、前記ＩＤを前記第２の通信装置に送信することを特徴とするセッション管理サーバ。
5. 請求項３に記載のセッション管理サーバであって、
   前記第１の通信装置がログオフする際に、前記ＩＰアドレスと前記ＩＤとを削除することを特徴とするセッション管理サーバ。

Images