(57)【要約】【課題】  着信者の要求によりセキュリティを確保したセッション中継装置、端末装置およびセッション確立方法を提供する。【解決手段】  第１の端末１５Bから第１の端末１５Bを特定するＩＤと接続情報とが送信されたとき、ＩＤと接続情報とをデータベース１８０に記録し、第２の端末１５Aからの第１の端末１５Bとの接続要求を受信したとき、データベース１８０を参照して、接続要求を第１の端末１５Bに送信可否を判断する。【選択図】  図２
2007006306.tif 000002
【特許請求の範囲】
【請求項１】
通信ネットワーク上で第１の端末と第２の端末との間のセッションの確立のための通信手順を実行するセッション中継装置であって、
前記第１の端末から前記第１の端末を特定するＩＤと接続情報とが送信されたとき、前記ＩＤと前記接続情報とをデータベースに記録し、
前記第２の端末からの前記第１の端末との接続要求を受信したとき、前記データベースを参照して、前記接続要求を前記第１の端末に送信可否を判断することを特徴とするセッション中継装置。
【請求項２】
通信ネットワーク上で第１の端末と第２の端末との間のセッションの確立のための通信手順を実行するセッション中継装置であって、
前記第１の端末とのＴＣＰ/ＩＰ通信を行うＴＣＰ/ＩＰ通信部と、前記ＴＣＰ/ＩＰ通信部と通信を行うＳＩＰ通信部と、前記ＴＣＰ/ＩＰ通信部および前記ＳＩＰ通信部と通信を行うＴＬＳ通信部と、端末から送信されたレジスタ情報を記録するレジスタ情報データベースと、前記レジスタ情報データベース操作部と、セキュリティ判定部とを含み、
前記第１の端末から前記第１の端末を特定するＩＤと接続情報とが送信されたとき、前記レジスタ情報データベース操作部は、前記ＩＤと前記接続情報とを前記レジスタ情報データベースに記録し、
前記第２の端末からの前記第１の端末との接続要求を受信したとき、前記セキュリティ判定部は、前記レジスタ情報データベース操作部を介して前記データベースを参照して、前記接続要求を前記第１の端末に送信可否を判断することを特徴とするセッション中継装置。
【請求項３】
請求項１または請求項２に記載のセッション中継装置であって、
前記接続情報には、暗号情報を含むことを特徴とするセッション中継装置。
【請求項４】
通信ネットワーク上でセッション中継装置を介して他の端末装置とセッションを確立する端末装置であって、
ＩＤと接続情報とをデータベースに記録し、
前記他の端末からの接続要求を受信したとき、前記データベースを参照して、前記接続要求の受け入れ可否を判断することを特徴とする端末装置。
【請求項５】
ＳＩＰプロキシサーバとのＴＣＰ/ＩＰ通信を行うＴＣＰ/ＩＰ通信部と、前記ＴＣＰ/ＩＰ通信部と通信を行うＳＩＰ通信部と、前記ＴＣＰ/ＩＰ通信部および前記ＳＩＰ通信部と通信を行うＴＬＳ通信部と、ＩＤと接続情報とを記録されたレジスタ情報データベースと、前記レジスタ情報データベース操作部と、セキュリティ判定部とを含み、
前記ＳＩＰプロキシサーバから接続要求を受信したとき、前記セキュリティ判定部は、前記レジスタ情報データベース操作部を介して前記データベースを参照して、前記接続要求の受け入れ可否を判断することを特徴とする端末装置。
【請求項６】
請求項４または請求項５に記載の端末装置であって、
前記接続情報には、暗号情報を含むことを特徴とする端末中継装置。
【請求項７】
レジスタ情報データベースに登録された端末へのセッション確立要求を受信したとき、セキュリティ情報を更新するステップと、
前記レジスタ情報データベースを参照するステップと、
セッション確立要求を前記端末に送信するか判定するステップとを含むセッション確立方法。
【請求項８】
請求項７に記載のセッション確立方法であって、
セッション確立を要求した他の端末宛に、応答メッセージを送信するステップをさらに含むことを特徴とするセッション確立方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セッション中継装置、端末装置およびセッション確立方法に係り、着信側端末の要求に基づいてセキュアなセッションを確立するセッション中継装置、端末装置およびセッション確立方法に関する。
【背景技術】
【０００２】
ＩＰ電話に代表されるピアツーピア（peer to peer）通信において、シグナリングプロトコルとして使用されているＳＩＰは、トランスポートプロトコルにＴＬＳ（Transport Layer Security、ＳＳＬ（Secure Socket Layer））を使用してシグナリングのセキュリティを確保することができる。非特許文献１は、ＩＥＴＦが発行したＳＩＰに関するＲＦＣである。
【０００３】
【非特許文献１】J. Rosenberg、外７名、”SIP: Session Initiation Protocol”、[online]、2002年６月、IETF、[平成１７年４月１９日検索]、インターネット<URL:http://www.ietf.org/rfc/rfc3261.txt>
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ＳＩＰは発信者がセキュリティを求めるには有効である。しかし、ＳＩＰはhop-by-hopでＴＬＳを確立するため、着信者がセキュリティを求めることを考慮していない。
【０００５】
本発明の目的は、着信者の要求によりセキュリティを確保したセッション中継装置、端末装置およびセッション確立方法を提供することにある。
【課題を解決するための手段】
【０００６】
第１の端末から第１の端末を特定するＩＤと接続情報とが送信されたとき、前記ＩＤと接続情報とをデータベースに記録し、第２の端末からの第１の端末との接続要求を受信したとき、データベースを参照して、接続要求を第１の端末に送信可否を判断するセッション中継装置により達成できる。
【０００７】
また、ＳＩＰプロキシサーバとのＴＣＰ/ＩＰ通信を行うＴＣＰ/ＩＰ通信部と、ＴＣＰ/ＩＰ通信部と通信を行うＳＩＰ通信部と、ＴＣＰ/ＩＰ通信部およびＳＩＰ通信部と通信を行うＴＬＳ通信部と、ＩＤと接続情報とを記録されたレジスタ情報データベースと、レジスタ情報データベース操作部と、セキュリティ判定部とを含み、ＳＩＰプロキシサーバから接続要求を受信したとき、セキュリティ判定部は、レジスタ情報データベース操作部を介してデータベースを参照して、前記接続要求の受け入れ可否を判断する端末装置により達成できる。
【０００８】
さらに、レジスタ情報データベースに登録された端末へのセッション確立要求を受信したとき、セキュリティ情報を更新するし、レジスタ情報データベースを参照し、セッション確立要求を端末に送信するか判定するセッション確立方法により達成できる。
【発明の効果】
【０００９】
本発明によれば、着信者の要求によりセキュリティを確保したセッション中継装置、端末装置およびセッション確立方法を提供することができる。
【発明を実施するための最良の形態】
【００１０】
以下本発明の実施の形態について、実施例を用いて、図面を参照しながら説明する。 
【実施例１】
【００１１】
図１ないし図１６を用いて実施例１を説明する。ここで、図１はネットワークの構成を説明するブロック図である。図２は着信端末を収容するドメインのセッション中継装置のブロック図である。図３は着信端末の要部ブロック図である。図４は発信端末の要部ブロック図である。図５は着信端末とセッション中継装置の通信を説明するシーケンス図である。図６は着信端末のレジスタ情報の登録画面を説明する図である。図７はREGISTERリクエストを説明する図である。図８はREGISTERリクエストを受信したセッション中継装置のセキュリティ情報登録部の動作を説明するフロー図である。図９はセッション中継装置のレジスタ情報データベースを説明する図である。
【００１２】
図１０は発信端末とセッション中継装置Ａとセッション中継装置Ｂと着信端末の通信を説明するシーケンス図である。図１１はセッション中継装置のセキュリティ履歴追加部の動作を説明するフロー図である。図１２はセッション中継装置Ａからセッション中継装置Ｂに送られるINVITEリクエストを説明する図である。図１３はセッション中継装置のセキュリティ判定部の動作を説明するフロー図である。図１４はセッション中継装置のセキュリティ応答部の動作を説明する図である。図１５はセッション中継装置Ｂからセッション中継装置Ａに送られるFORBIDDENリクエストを説明する図である。図１６は発信端末のセキュリティ情報作成部の動作を説明する図である。
【００１３】
まず、図１ないし図４を用いてネットワーク構成とセッション管理装置と端末の機能ブロックを説明する。
図１において、ドメインＡを管理するセッション中継装置１０ＡとドメインＢを管理するセッション中継装置１０Ｂはネットワークで接続されている。ここでドメインＡの端末（発信端末）１５ＡからドメインＢの端末（着信端末）１５Ｂへのセッション確立要求が発信された実施例を以下説明する。なお、端末１５Ｂのユーザはセキュリティの確保を求めている。
なお、ＩＰアドレスは以下の通りとする。
セッション中継装置１０Ａ：192.168.100.10
セッション中継装置１０Ｂ：192.168.100.20
端末１５Ａ              ：192.168.10.1
端末１５Ｂ              ：192.168.20.1
図２において、セッション中継装置１０Ｂは、着信端末１５Ｂ、セッション中継装置１０Ａと通信を行い、ネットワーク層とトランスポート層（ＴＣＰ）を管理するＴＣＰ/ＩＰ通信機能ブロック１００と、ＴＣＰ/ＩＰ通信機能ブロック１００と通信を行い、ＳＩＰメッセージの処理を行うピアツーピアセッション中継制御ブロック１２０と、ＴＣＰ/ＩＰ通信機能ブロック１００とピアツーピアセッション中継制御ブロック１２０との間で、トランスポート層でＴＬＳが用いられたとき、暗号化と復号化を行うＴＬＳ通信機能ブロック１１０とを含んでいる。セッション中継装置１０Ｂは、また、セキュリティ情報登録部１３０、セキュリティ履歴情報追加部１４０、セキュリティ判定部１５０、レジスタ情報操作部１６０、セキュリティ応答部１７０を含んでいる。なお、これら各部の動作は、フロー図を用いて後述する。各ブロックおよび各部は、ハードウェアで実現しても、メモリ上で実行されるソフトウェアで実現してもよい。各部の機能は、まとめても良いし、さらに分割してもよい。
【００１４】
セッション中継装置１０Ｂは、さらに、レジスタ情報を蓄積するレジスタ情報データベース１８０と、セッション情報を蓄積するセッション情報データベース１９０を含んでいる。なお、図２のセッション中継装置１０Ｂは、着信端末に接続したセッション中継装置の機能を記載していることに注意されたい。セッション中継装置は、レジストラ機能を備えたＳＩＰプロキシサーバと呼ぶこともできる。ピアツーピアセッション中継制御ブロックは、ＳＩＰ通信中継制御ブロックと呼ぶこともできる。
【００１５】
図３に示す着信端末１５Ｂは、図１で説明したセッション中継装置とほぼ同じ構成を含んでいる。即ち、ＴＣＰ/ＩＰ通信機能ブロック１００と、ピアツーピアセッション制御ブロック２２０と、ＴＬＳ通信機能ブロック１１０と、セキュリティ情報登録部１３０、セキュリティ判定部１５０、レジスタ情報操作部１６０、セキュリティ応答部１７０を含んでいる。また、着信端末１５Ｂは、周辺機器２５０およびレジスタ情報操作部と接続されたレジスタ情報入力部２５０を含む。各ブロックおよび各部は、ハードウェアで実現しても、メモリ上で実行されるソフトウェアで実現してもよい。各部の機能は、まとめても良いし、さらに分割してもよい。周辺機器は、モニタ、入力手段等である。
【００１６】
着信端末１５Ｂは、さらに、レジスタ情報を蓄積するレジスタ情報データベース１８０と、セッション情報を蓄積するセッション情報データベース１９０を含んでいる。なお、図３の着信端末１５Ｂは、着信端末の機能を記載していることに注意されたい。ピアツーピアセッション制御ブロックは、ＳＩＰ通信制御ブロックと呼ぶこともできる。
【００１７】
図４に示す発信端末１５Ａは、着信端末と同じ様に、ＴＣＰ/ＩＰ通信機能ブロック１００と、ＴＬＳ通信機能ブロック１１０と、ピアツーピアセッション制御ブロック２２０を含んでいる。また、発信端末１５Ａは、ＴＣＰ/ＩＰ通信機能ブロック１００、ＴＬＳ通信機能ブロック１１０およびピアツーピアセッション制御ブロック２２０と接続されたセキュリティ情報作成部３５０を含む。各ブロックおよび各部は、ハードウェアで実現しても、メモリ上で実行されるソフトウェアで実現してもよい。各部の機能は、まとめても良いし、さらに分割してもよい。
【００１８】
発信端末１５Ａは、さらに、セッション情報を蓄積するセッション情報データベース１９０を含んでいる。なお、図４の発信端末１５Ａは、発信端末の機能のみを記載している。端末は、発信端末になる場合も、着信端末となる場合もあるので、実際には図３と図４の各機能ブロック（各ブロック、各部、各ＤＢ）のオアを取った構成となる。
【００１９】
前述したように着信端末のユーザは、セキュリティの確保を求めている。このときユーザは端末を操作して、端末のドメインを管理するセッション管理装置にその旨を登録する必要がある。これを図５ないし図９で説明する。
【００２０】
図５において、着信端末のユーザは着信端末を操作して、レジスタ情報を作成する（Ｓ５０１）。着信端末１５Ｂはレジスタ情報を載せたREGISTERリクエストをセッション中継装置１０Ｂに送信する（Ｓ５０２）。REGISTERリクエストを受信したセッション中継装置１０Ｂは、レジスタ情報を記録するレジスタ情報ＤＢにREGISTERリクエストに含んでいるレジスタ情報を記録し（Ｓ５０３）、200 OKレスポンスを着信端末１５Ｂに送信する（Ｓ５０４）ことで、着信端末１５Ｂのレジスタ登録が終了する。
【００２１】
図６は、着信端末１５Ｂのモニタ画面のＧＵＩである。ユーザ名４０１欄には端末１５ＢのユーザであるUserB、ＩＰアドレス４０２欄には端末１５Ｂの192.168.20.1、トランスポート４０３欄にはｔｌｓの前のみにチェックがいれられ、デフォルトポートである5061が記載されている。これによって、UserBはセキュアな通信を望んでいることがわかる。
【００２２】
なお、暗号４０４欄では４種類の暗号に対応し鍵長512ビットであること、ハッシュ４０５欄では２種類のハッシュに対応することが分かる。この状態で登録ボタン４０６を押すと、REGISTERメッセージが作成され、セクション中継装置に送信される。
【００２３】
図７において、REGISTERリクエストは、現在位置をレジストラに登録するＳＩＰメッセージであり、スタートラインには、ＳＩＰメッセージの種類（この場合REGISTER）と宛先アドレス（192.168.100.20）を含む。Viaヘッダにはリクエストの発信元アドレス（192.168.20.1）を含む。FromヘッダとToヘッダは、REGISTERリクエストなので、共にREGISTERリクエスト発信者のＳＩＰ-ＵＲＩ（Universal Resource Identifier）を含む。Call-IDヘッダは送信元で指定したセッション識別子を記載する。Cseq（Command Sequence）ヘッダは、同一セッションにおけるコマンドの順序（１）とメソッド名（REGISTER）である。Content-Lengthヘッダは、メッセージボディのＳＤＰ(Session Description Protocol）の定義情報である。Contactヘッダには、UserBの通信アドレスとポート番号、選択したトランスポート（この場合ＴＬＳ）、有効期限、暗号（sec-crypt）タグ、鍵長（sec-key）タグ、ハッシュ（sec-hash）タグが記載されている。ここで、Contactヘッダが８個あるのは、図６の４種類の暗号と２種類のハッシュの組み合わせ（４×２）のためである。
【００２４】
図８において、図２のセキュリティ情報登録部１３０は、REGISTERリクエストを解析する。具体的には、図８のステップ５１１とステップ５１６の間を、Contactヘッダの数だけ繰り返す。このループは、Contactヘッダに、sec-cryptタグ、sec-keyタグ、sec-hashタグが全てある調査する（Ｓ５１２）ことで始まる。Ｎｏの場合、ステップ５１６に遷移し、次のContactヘッダに移行する。Ｙｅｓの場合、レジスタ情報データベースの該当するレコードのSec-cryptフィールドにsec-cryptタグの値を登録し（Ｓ５１３）、レジスタ情報データベースの該当するレコードのSec-keyフィールドにsec-keyタグの値を登録し（Ｓ５１４）、レジスタ情報データベースの該当するレコードのSec-hashフィールドにsec-hashタグの値を登録する（Ｓ５１５）。このあと、ステップ５１６に遷移し、次のContactヘッダに移行する。
【００２５】
図８で説明した処理によって作成された図２のレジスタ情報ＤＢ１８０の一部を図９を用いて説明する。図９は、レジスタ情報ＤＢ１８０のUserBに関するレコード４１０である。レジスタ情報ＤＢは、Fromヘッダから取得するＳＵＰ-ＵＲフィールドＩ４１１と、Contactヘッダから取得するContactフィールド４１２、セッション中継装置の時計から取得する時刻であるTimestampフィールド４１３と、いずれもContactヘッダから取得するTimerフィールド４１４、Transportフィールド４１５、portフィールド４１６、Sec-cyptフィールド４１７、Sec-keyフィールド４１８およびSec-hashフィールド４１９とで構成される。SUP-URIフィールド４１１、Contactフィールド４１２、Timestampフィールド４１３、Timerフィールド４１４、Transportフィールド４１５、portフィールド４１６は、各レコードで共通であり、コピーする。Sec-cyptフィールド４１７、Sec-keyフィールド４１８およびSec-hashフィールド４１９は、図８の手順で登録される。
【００２６】
図１０を参照して、発信端末の着信端末の間のセッション確立を説明する。
まず、発信端末１５Ａは自ドメインのセッション中継装置１０ＡにメッセージプロトコルとしてＵＤＰを用いて、ToヘッダにSIP-URIとしてUseBを記載したINVITEリクエストを送信する（Ｓ５２１）。INVITEリクエストを受信したセッション中継装置１０Ａは、セキュリティ履歴情報を更新し（Ｓ５２２）、更新したINVITEリクエストをセッション中継装置１０Ｂに送信する（Ｓ５２３）。なお、セキュリティ履歴情報の更新は、図１１を用いて後述する。また、更新したINVITEリクエストは、メッセージプロトコルとしてＴＣＰを用い、図１２を用いて後述する。
【００２７】
更新したINVITEリクエストを受信したセッション中継装置１０Ｂは、セキュリティ履歴情報を更新し（Ｓ５２４）、セキュリティ判定部１５０で判定をする（Ｓ５２５）。この場合は、判定結果は不一致なのでセキュリティ応答部１７０で、応答メッセージを作成する（Ｓ５２６）。なお、セキュリティ判定部で判定とセキュリティ応答部での応答メッセージの作成は、図１３および図１４を用いて後述する。また、セッション中継装置１０Ａはステップ５２３のあと、発信端末１５Ａに100 Tryingを送信する（Ｓ５２７）。
【００２８】
応答メッセージの作成後、セッション中継装置１０Ｂはセッション中継装置１０Ａに、応答メッセージである403 Forbiddenを送信する（Ｓ５２８）。403 Forbiddenを受信したセッション中継装置１０Ａは、セッション中継装置１０ＢにＡＣＫを返し（Ｓ５２９）、発信端末１５Ａに403 Forbiddenを送信する（Ｓ５３１）。なお、ステップ５２８で送信される403 Forbiddenは図１５を用いて後述する。
【００２９】
403 Forbiddenを受信した発信端末１５Ａは、ＡＣＫを返し（Ｓ５３２）、セキュリティ情報作成部３７０でトランスポートプロトコルとしてＴＬＳを用いて再セッションを確立する。発信端末１５Ａは、セッション中継装置１０ＡにメッセージプロトコルとしてＴＬＳを用いて、INVITEリクエストを送信する（Ｓ５３４）。INVITEリクエストを受信したセッション中継装置１０Ａは、セキュリティ履歴情報を更新し（Ｓ５３５）、INVITEリクエストをセッション中継装置１０Ｂに送信する（Ｓ５３６）。なお、INVITEリクエストは、メッセージプロトコルとしてＴＬＳを用いる。
【００３０】
INVITEリクエストを受信したセッション中継装置１０Ｂは、セキュリティ履歴情報を更新し（Ｓ５３７）、セキュリティ判定部で判定をする（Ｓ５３８）。この場合は判定結果は一致であり、セッション中継装置１０Ｂは、メッセージプロトコルとしてＴＬＳを用いたINVITEリクエストを着信端末１５Ｂに送信し（Ｓ５４１）、セッション中継装置１０Ａに100 Tryingを送信する（Ｓ５４２）。なお、セッション中継装置１０Ａはステップ５３６のあと、発信端末１５Ａに100 Tryingを送信する（Ｓ５３９）。
【００３１】
ＴＬＳを用いたINVITEリクエストを受信した着信端末１５Ｂは、セッション中継装置１０Ｂに180 Ringingを返信する（Ｓ５４３）。180 Ringingは、セッション中継装置１０Ｂ、セッション中継装置１０Ａを経て、発信端末１５Ａが受信する（Ｓ５４４〜Ｓ５４５）。着信端末１５Ｂは、またセッション中継装置１０Ｂに200 ＯＫを送信する（Ｓ５４６）。200 ＯＫは、セッション中継装置１０Ｂ、セッション中継装置１０Ａを経て、発信端末１５Ａが受信する（Ｓ５４７〜Ｓ５４８）。
【００３２】
200 ＯＫを受信した発信端末１５Ａは、ＡＣＫを返す（Ｓ５４９）。このＡＣＫは、セッション中継装置１０Ａ、セッション中継装置１０Ｂを経て、着信端末１５Ｂが受信する（Ｓ５５１〜Ｓ５５２）。なお、図１０においてメッセージ着信側のセクション中継装置１０Ａ、１０Ｂの内部処理の順序と、メッセージ発信側のセクション中継装置１０Ｂ、１０Ａの100 Tryingの順序はステップの番号の順とは限らない。
以上のシーケンスでセッションを確立した発信端末１５Ａと着信端末１５Ｂは、これ以降セッション中継装置１０Ａ、１０Ｂを経ずに通信を行なう。
【００３３】
図１１を参照して、図２のセッション中継装置１０のセキュリティ履歴情報追加部１４０が実施するセキュリティ履歴情報追加を説明する。このセキュリティ履歴情報追加は、図１０のステップ５２２、ステップ５２４、ステップ５３５、ステップ５３７で実施される。
【００３４】
セキュリティ履歴情報追加部１４０は、受信したINVITEメッセージを解析してトランスポートプロトコルごとに処理を分ける（Ｓ６５１〜Ｓ５６３）。トランスポートプロトコルがＵＤＰのときには、新たに追加するViaヘッダに「transport=udp」を追加する（Ｓ５６４）。一方、トランスポートプロトコルがＴＣＰのときには、新たに追加するViaヘッダに「transport=tcp」を追加する（Ｓ５６５）。
【００３５】
また、トランスポートプロトコルがＴＬＳのときには、新たに追加するViaヘッダに「transport=tls」を追加し（Ｓ５６７）、使われていた暗号、鍵長、ハッシュを、それぞれ新たに追加するViaヘッダの「sec-crypt=」、「sec-key=」、「sec-hash=」の後に追加する（Ｓ５６８〜Ｓ５７０）。
以上によって作成された図１０のステップ５２３で送信されるINVITEリクエストを図１２に示す。
【００３６】
図１２において、スタートラインには、ＳＩＰメッセージの種類（この場合INVITE）と宛先のSIP-URIを含む。最初のViaヘッダは発信端末１５Ａが入れたもので、リクエストの発信元アドレス（192.168.100.10）を含む。２番目のViaヘッダはセッション中継装置１０Ａが追加したもので、セッション中継装置１０Ａのアドレス（192.168.100.20）と、発信端末１５ＡがINVITEリクエストをＵＤＰで送信してきたため「transport=udp」を含む。FromヘッダはINVITEリクエスト発信者のSIP-URI、ToヘッダはINVITEリクエスト着信先のSIP-URIを含む。
【００３７】
図１３を参照して、図２のセッション中継装置１０のセキュリティ判定部１５０が実施するセキュリティ判定を説明する。このセキュリティ判定は、図１０のステップ５２５とステップ５３８で実施される。
念のためステップ５２５とステップ５３８とで判定対象となるViaヘッダの情報を確認すると、Viaヘッダの情報は、ステップ５２４とステップ５３７とで一つ増加し、
ステップ５２６：Via: SIP/2.0/UDP 192.168.10.1
Via: SIP/2.0/UDP 192.168.100.10; transport=udp
Via: SIP/2.0/UDP 192.168.100.20; transport=tcp
ステップ５３８：Via: SIP/2.0/UDP 192.168.10.1
Via: SIP/2.0/UDP 192.168.100.10; transport=tls
Via: SIP/2.0/UDP 192.168.100.20; transport=tls
となっている。
【００３８】
セキュリティ判定部１５０の処理は、ステップ５２５とステップ５３８とで更新した転送メッセージ内の２番目以降のViaヘッダ全てについてループする（Ｓ６０１−Ｓ６１０）。また、レジスタ情報ＤＢのレコードのSIP-URIと、転送メッセージのToヘッダが一致する全レコードについてループする（Ｓ６０２−Ｓ６０９）。なお、ループの入れ子は逆でも良い。
【００３９】
二つの入れ子の内側で、まず、転送メッセージのViaヘッダに記載されたtransportタグと、レジスタ情報ＤＢ内容４１０のTransportフィールド４１５を比較する（Ｓ６０３）。Ｎｏならば次のループに移行し、Ｙｅｓならばtransportタグの内容によって処理を変える。具体的には、udpまたはtcpなら処理を終了する（Ｓ６０４）。tls以外のプロトコルならば次のループに移行し（Ｓ６０５）、tlsならばsec-cryptタグがSec-cryptフィールドと等しいか確認し（Ｓ６０６）、sec-keyタグがSec-keyフィールド以上となっているか確認し（Ｓ６０７）、sec-hashタグがSec-hashフィールドと等しいか確認する（Ｓ６０８）。ステップ６０６〜ステップ６０８が全てＹｅｓの場合処理を終了する。逆に一つでもＮｏがあれば次のループに移行する。
【００４０】
即ち、（１）transportタグとTransportフィールドとが等しく、プロトコルがudpまたはtcp、（２）transportタグとTransportフィールドとが等しく、プロトコルがtlsで暗号の条件が一致、のViaヘッダが含まれていない場合、ステップ６１１のセキュリティ応答部の処理を経て終了することになる。
【００４１】
図９のTransportフィールドは全てtlsなので、ステップ５２６の処理では、不一致（Forbiddenを返信）となる。また、ステップ５３８の処理では、Viaヘッダにtlsを含み図１６を用いて後述するステップ５３３で適切な暗号条件が追加されているので、一致（INVITEを転送）となる。
【００４２】
図１４を用いて、図２のセッション中継装置１０のセキュリティ応答部１７０が実施する応答メッセージ作成を説明する。この応答メッセージ作成は、図１０のステップ５２６で実施される。
【００４３】
セキュリティ応答部１７０の処理は、レジスタ情報ＤＢのSIP-URIフィールド４１１と、応答メッセージのToヘッダが一致する全レコードについてステップ６２１とステップ６２３との間でループする。ループの中では、Transportフィールド、Sec-cryptフィールド，Sec-keyフィールド，Sec-hashフィールドの値からSecurity-requiredヘッダを作成し応答メッセージに追加する（Ｓ６２２）。
【００４４】
図１５に示す応答メッセージは、スタートラインに403 Forbiddenを含む。Viaヘッダは図１０のステップ５２５で追加した３番目のヘッダを削除し、二つに戻っている。図１４で説明したSecurity-requiredヘッダには、tlsを含み、８種類の暗号条件の一つが記載されている。
【００４５】
Forbiddenメッセージを受信した発信端末１５Ａのセキュリティ情報作成部３７０の動作を図１６を用いて説明する。セキュリティ情報作成部３７０は、ForbiddenメッセージにSecurity-requiredヘッダがあるか解析する（Ｓ６３１）。セキュリティ情報作成部３７０は、Security-requiredヘッダが無ければ終了し、最初のSecurity-requiredヘッダの値が、udp（Ｓ６３２）、tcp（Ｓ６３３）、tls（Ｓ６３４）、それ以外（終了）に区分する。udpならばトランスポートプロトコルにUDPを使用して再セッション確立する（Ｓ６３５）。tcpならばトランスポートプロトコルにTCPを使用して再セッション確立する（Ｓ６３６）。tlsならばトランスポートプロトコルにTLSを使用し、パラメタとして自身が使用可能なsec-cryptタグ、sec-keyタグ、sec-hashタグの値を使用して再セッション確立する（Ｓ６３７）。
【００４６】
本実施例に拠れば、着信者の要求によりセキュリティを確保したピアツーピア通信手段を提供することができる。
本実施例を適用できるピアツーピア通信には、ＩＰ電話、ＴＶ電話、ビデオ会議、コールセンタ、セントレックサービスシステム、インスタントメッセージ、プレゼンス、家電制御を含みこれらに限られない。
【実施例２】
【００４７】
図１７を用いて実施例２を説明する。ここで、図１７は、発信端末とセッション中継装置Ａとセッション中継装置Ｂと着信端末の通信を説明するシーケンス図である。
実施例２の実施例１との違いは、セキュリティ判定と応答メッセージ作成をセッション中継装置１０Ｂでは無く、着信端末１５Ｂが行う点である。実施例１の大部分の図面は実施例２と共通であるが、読み替える点をまず列挙する。
【００４８】
まず、図６で入力した情報は自分自身（着信端末１５Ｂ）で使用する。図７のREGISTERリクエストでContactヘッダの暗号情報は不要である。図８は、着信端末１５Ｂのセキュリティ情報登録部１３０が実施し、図９も着信端末１５Ｂのレジスタ情報ＤＢ１８０のUserBに関するレコード４１０である。図１０の前半を図１７で説明し、後半は共通である。図１３は、着信端末１５Ｂのセキュリティ判定部１５０が実施する。図１４は、着信端末１５Ｂのセキュリティ応答部１７０が実施する。着信端末１５Ｂのセキュリティ応答部１７０が作成する応答メッセージは、セッション中継装置１０Ｂが追加した次の
Viaヘッダを図１５に追加した形式である。
Via: SIP/2.0/UDP 192.168.100.20;branch=z9hG4bK9b5f6b0f-6475-11d9-8029-b963a492ae17;transport=tcp
以下、図１０の前半２／３に相当する図１７について、図１０との相違点のみ説明する。
INVITEリクエストを受信したセッション中継装置１０Ｂは、セキュリティ履歴情報を更新し（Ｓ６４１）、INVITEリクエストを着信端末１５Ｂに送信する（Ｓ６４２）。INVITEリクエストを受信した着信端末１５Ｂは、セキュリティ判定部１５０で判定をする（Ｓ６４３）。この場合は、判定結果は不一致なのでセキュリティ応答部１７０で、応答メッセージを作成する（Ｓ６４４）。着信端末１５Ｂは、作成した403 Forbiddenをセッション中継装置１０Ｂに送信する。403 Forbiddenを受信したセッション中継装置１０Ｂは、ＡＣＫを返し、セッション中継装置１０Ａに403 Forbiddenを送信する。
【００４９】
ＴＬＳを用いたINVITEリクエストを受信したセッション中継装置１０Ｂは、セキュリティ履歴情報を更新し（Ｓ６５１）、INVITEリクエストを着信端末１５Ｂに送信する（Ｓ６５２）。INVITEリクエストを受信した着信端末１５Ｂは、セキュリティ判定部１５０で判定をする（Ｓ６５３）。この場合は、判定結果は一致なので、着信端末１５Ｂは、セッション中継装置１０Ｂに180 Ringingを返信する（Ｓ６５４）。
本実施例に拠れば、着信端末の設定によってセキュリティを確保したピアツーピア通信手段を提供することができる。
【図面の簡単な説明】
【００５０】
【図１】ネットワークの構成を説明するブロック図である。
【図２】着信端末を収容するドメインのセッション中継装置のブロック図である。
【図３】着信端末の要部ブロック図である。図４は発信端末の要部ブロック図である。
【図４】発信端末の要部ブロック図である。
【図５】着信端末とセッション中継装置の通信を説明するシーケンス図である。
【図６】着信端末のレジスタ情報の登録画面を説明する図である。
【図７】REGISTERリクエストを説明する図である。
【図８】REGISTERリクエストを受信したセッション中継装置のセキュリティ情報登録部の動作を説明するフロー図である。
【図９】セッション中継装置のレジスタ情報データベースを説明する図である。
【図１０】発信端末とセッション中継装置Ａとセッション中継装置Ｂと着信端末の通信を説明するシーケンス図である。
【図１１】セッション中継装置のセキュリティ履歴追加部の動作を説明するフロー図である。
【図１２】セッション中継装置Ａからセッション中継装置Ｂに送られるINVITEリクエストを説明する図である。
【図１３】セッション中継装置のセキュリティ判定部の動作を説明するフロー図である。
【図１４】セッション中継装置のセキュリティ応答部の動作を説明する図である。
【図１５】セッション中継装置Ｂからセッション中継装置Ａに送られるFORBIDDENリクエストを説明する図である。
【図１６】発信端末のセキュリティ情報作成部の動作を説明する図である。
【図１７】実施例２の発信端末とセッション中継装置Ａとセッション中継装置Ｂと着信端末の通信を説明するシーケンス図である。
【符号の説明】
【００５１】
１０…セッション中継装置、１５…端末、１００…ＴＣＰ/ＩＰ通信機能ブロック、１１０…ＴＬＳ通信機能ブロック、１２０…ピアツーピアセッション中継制御ブロック、１３０…セキュリティ情報登録部、１４０…セキュリティ履歴情報追加部、１５０…セキュリティ判定部、１６０…レジスタ情報操作部、１７０…セキュリティ応答部、１８０…レジスタ情報データベース、１９０…セッション情報データベース、２２０…ピアツーピアセッション制御ブロック、２３０…レジスタ情報入力部、２５０…周辺機器、３７０…セキュリティ情報作成部、４０１…ユーザ名、４０２…ＩＰアドレス、４０３…トランスポート、４０４…暗号、４０５…ハッシュ、４０６…登録ボタン、４１０…レジスタ情報ＤＢの一部、４１１…SIP-URIフィールド、４１２…Contactフィールド、４１３…Timestampフィールド、４１４…Timerフィールド、４１５…Transportフィールド、４１６…portフィールド、４１７…Sec-cyptフィールド、４１８…Sec-keyフィールド、４１９…Sec-hashフィールド。
【図１】
2007006306.tif 000003
【図２】
2007006306.tif 000004
【図３】
2007006306.tif 000005
【図４】
2007006306.tif 000006
【図５】
2007006306.tif 000007
【図６】
2007006306.tif 000008
【図７】
2007006306.tif 000009
【図８】
2007006306.tif 000010
【図９】
2007006306.tif 000011
【図１０】
2007006306.tif 000012
【図１１】
2007006306.tif 000013
【図１２】
2007006306.tif 000014
【図１３】
2007006306.tif 000015
【図１４】
2007006306.tif 000016
【図１５】
2007006306.tif 000017
【図１６】
2007006306.tif 000018
【図１７】
2007006306.tif 000019