JP4627506B2

JP4627506B2 - Ｈｔｔｐ対応端末をｓｉｐ対応サーバに接続する代理接続方法、プロキシサーバ及びプログラム

Info

Publication number: JP4627506B2
Application number: JP2006055971A
Authority: JP
Inventors: 尚樹今井; 学磯村; 浩規堀内
Original assignee: KDDI Corp
Current assignee: KDDI Corp
Priority date: 2006-03-02
Filing date: 2006-03-02
Publication date: 2011-02-09
Anticipated expiration: 2026-03-02
Also published as: JP2007233803A

Description

本発明は、代理接続方法、プロキシサーバ及びプログラムに関する。

３ＧＰＰ２(3rd Generation Partnership Project 2：第３世代移動体通信システムの標準規格)や３ＧＰＰでは、携帯通信網のオールＩＰ(Internet Protocol)化に関するＩＭＳ／ＭＭＤ(IP Multimedia Subsystem / Multimedia Domain)プラットフォームの標準化が進められている。ＩＭＳ／ＭＭＤプラットフォーム（以下では「オールＩＰコアネットワーク」という）は、ＩＰｖ６技術や次世代ネットワーク（ＮＧＮ：Next Generation Network）によって構成される。オールＩＰコアネットワークでは、音声を含むマルチメディア通信の制御にＳＩＰ(Session Initiation Protocol)を用いている。従って、ＳＩＰ対応の携帯電話機は、オールＩＰコアネットワークに直接的に接続することができる。

特開２００２−１８３００３号公報 Imai et al., 「A Unified Resource Switching forReal-time Communication in a Ubiquitous Networking Environment」、Globecom 2005、AN04-2、Nov.2005.

ＩＭＳ／ＭＭＤプラットフォームでは、ＩＰｖ６や、ＩＭＳ−ＡＫＡ等の認証・暗号化プロトコルを用いる必要がある。しかしながら、現在の携帯電話機は、ＩＰｖ６のプロトコルスタックを備えておらず、複雑且つ高演算量を必要とする暗号化プロトコルを処理できるほどの処理性能を備えていない場合が多い。

このようなＩＭＳ／ＭＭＤ非対応端末は、ＳＩＰに対応しておらず、オールＩＰコアネットワークに接続されたＷｅｂサーバと通信をすることができない。また、ＩＭＳ／ＭＭＤ非対応端末は、ＨＴＴＰ(HyperText Transfer Protocol)には対応しているけれども、ＳＩＰのレジストラサーバに対して登録認証処理をすることはできない。

そこで、本発明は、ＨＴＴＰ対応端末をＳＩＰ対応サーバに接続することができる代理接続方法、プロキシサーバ及びプログラムを提供することを目的とする。

本発明によれば、ＨＴＴＰに対応する端末と、ＳＩＰに対応するレジストラサーバ及びＷｅｂサーバとの間に接続されたプロキシサーバにおける代理接続方法において、
端末からＨＴＴＰリクエストを受信した際に、該端末との間でＨＴＴＰ認証シーケンスを実行する第１のステップと、
ＨＴＴＰ認証シーケンスによって端末ＵＲＩを取得し、該端末ＵＲＩをSIP-URIとするREGISTERリクエストをレジストラサーバへ送信する第２のステップと、
レジストラサーバから登録完了レスポンスを受信した際に、ＨＴＴＰリクエストをＷｅｂサーバへ送信する第３のステップと、
Ｗｅｂサーバから受信したＨＴＴＰレスポンスを、端末へ送信する第４のステップと
を有することを特徴とする。

本発明の代理接続方法における他の実施形態によれば、
第１のステップは、端末からＨＴＴＰリクエストを受信した際に、端末へWWW-Authenticateヘッダを含むＨＴＴＰレスポンスを送信するステップと、端末から、Authorizationヘッダを含むＨＴＴＰリクエストを受信するステップとを有し、
第２のステップは、Authorizationヘッダに含まれる端末ＵＲＩをSIP-URIとするREGISTERリクエストをレジストラサーバへ送信することも好ましい。

本発明の代理接続方法における他の実施形態によれば、
第２のステップは、端末のＩＰアドレスに対応付けて、端末ＵＲＩ及びサーバＵＲＬを保持し、
第３のステップは、端末ＵＲＩに対応するサーバＵＲＬのＷｅｂサーバへＨＴＴＰリクエストを送信することも好ましい。

本発明によれば、ＨＴＴＰに対応する端末と、ＳＩＰに対応するレジストラサーバ及びＷｅｂサーバとの間に接続されたプロキシサーバにおいて、
端末に対するＨＴＴＰサーバ手段と、
ＨＴＴＰサーバ手段を介して端末からＨＴＴＰリクエストを受信した際に、該端末との間でＨＴＴＰ認証シーケンスを実行する端末認証手段と、
ＨＴＴＰ認証シーケンスによって端末ＵＲＩを取得し、該端末ＵＲＩをSIP-URIとするREGISTERリクエストをレジストラサーバへ送信するＳＩＰクライアント手段と、
ＳＩＰクライアントを介してレジストラサーバから登録完了レスポンスを受信した際に、ＨＴＴＰリクエストをＷｅｂサーバへ送信し、Ｗｅｂサーバから受信したＨＴＴＰレスポンスを、ＨＴＴＰサーバ手段へ通知して端末へ送信するＨＴＴＰクライアント手段と
を有することを特徴とする。

本発明のプロキシサーバにおける他の実施形態によれば、
端末認証手段は、ＨＴＴＰサーバ手段によって端末からＨＴＴＰリクエストを受信した際に、端末へWWW-Authenticateヘッダを含むＨＴＴＰレスポンスを送信し、端末から、Authorizationヘッダを含むＨＴＴＰリクエストを受信するものであり、
ＳＩＰクライアント手段は、Authorizationヘッダに含まれる端末ＵＲＩをSIP-URIとしてREGISTERリクエストに含めることも好ましい。

本発明のプロキシサーバにおける他の実施形態によれば、
端末のＩＰアドレスに対応付けて、端末ＵＲＩ及びサーバＵＲＬを保持するＨＴＴＰリクエストテーブル蓄積手段を更に有し、
ＨＴＴＰクライアント手段は、端末ＵＲＩに基づくサーバＵＲＬのＷｅｂサーバへＨＴＴＰリクエストを送信することも好ましい。

本発明によれば、ＨＴＴＰに対応する端末と、ＳＩＰに対応するレジストラサーバ及びＷｅｂサーバとの間に接続されたプロキシサーバに搭載されたコンピュータを機能させるプログラムにおいて、
端末に対するＨＴＴＰサーバ手段と、
ＨＴＴＰサーバ手段を介して端末からＨＴＴＰリクエストを受信した際に、該端末との間でＨＴＴＰ認証シーケンスを実行する端末認証手段と、
ＨＴＴＰ認証シーケンスによって端末ＵＲＩを取得し、該端末ＵＲＩをSIP-URIとするREGISTERリクエストをレジストラサーバへ送信するＳＩＰクライアント手段と、
ＳＩＰクライアントを介してレジストラサーバから登録完了レスポンスを受信した際に、ＨＴＴＰリクエストをＷｅｂサーバへ送信し、Ｗｅｂサーバから受信したＨＴＴＰレスポンスを、ＨＴＴＰサーバ手段へ通知して端末へ送信するＨＴＴＰクライアント手段と
してコンピュータを機能させることを特徴とする。

本発明のプロキシサーバ用のプログラムにおける他の実施形態によれば、
端末認証手段は、ＨＴＴＰサーバ手段によって端末からＨＴＴＰリクエストを受信した際に、端末へWWW-Authenticateヘッダを含むＨＴＴＰレスポンスを送信し、端末から、Authorizationヘッダを含むＨＴＴＰリクエストを受信するものであり、
ＳＩＰクライアント手段は、Authorizationヘッダに含まれる端末ＵＲＩをSIP-URIとしてREGISTERリクエストに含めるようにコンピュータを機能させることも好ましい。

本発明のプロキシサーバ用のプログラムにおける他の実施形態によれば、
端末のＩＰアドレスに対応付けて、端末ＵＲＩ及びサーバＵＲＬを保持するＨＴＴＰリクエストテーブル蓄積手段を更に有し、
ＨＴＴＰクライアント手段は、端末ＵＲＩに基づくサーバＵＲＬのＷｅｂサーバへＨＴＴＰリクエストを送信するようにコンピュータを機能させることも好ましい。

本発明によれば、ＨＴＴＰ対応端末をＳＩＰ対応サーバに接続することができる。端末が、ＩＰｖ４のプロトコルスタックしか備えておらず、処理性能が低い場合であっても、ＩＭＳ／ＭＭＤプラットフォームに接続されたＷｅｂサーバに接続することができる。ＨＴＴＰ対応端末であっても、ユーザのロケーション情報を管理するレジストラサーバに登録することができる。

以下では、図面を用いて、本発明を実施するための最良の形態について詳細に説明する。

図１は、本発明におけるシステム構成図である。

図１によれば、オールＩＰコアネットワーク６には、ＩＭＳ／ＭＭＤ対応のＷｅｂサーバ４及びレジストラサーバ５のようなサーバ群が接続されている。ＩＭＳ／ＭＭＤ対応端末３は、直接的にオールＩＰコアネットワーク６に接続され、Ｗｅｂサーバ４及びレジストラサーバ５と通信をすることができる。端末３は、起動時に予め、レジストラサーバ５に対して、登録認証を実行し、その後、Ｗｅｂサーバ４と通信が可能となる。レジストラサーバとは、ＩＰネットワーク上の居場所を示すロケーション情報を管理するサーバをいう。

オールＩＰコアネットワーク６は、移動通信網７及び固定通信網８にも接続されている。移動通信網７には、携帯電話機のようなＩＭＳ／ＭＭＤ非対応端末２と、本発明のプロキシサーバ１とが接続されている。プロキシサーバ１は、ＩＭＳ／ＭＭＤ非対応の携帯電話機２が、ＩＭＳ／ＭＭＤ対応のサーバと通信できるように介在する。また、図１によれば、固定通信網８にもプロキシサーバ１が接続されている。固定通信網８に接続されるプロキシサーバ１は、例えばホームネットワークに接続され、ＩＭＳ／ＭＭＤ非対応端末２と通信する。本発明におけるプロキシサーバ１は、ＩＭＳ／ＭＭＤ非対応の端末２が、ＩＭＳ／ＭＭＤ対応のサーバ群と通信できるように介在する。尚、端末２は、ユーザによって操作可能な携帯電話機、パーソナルコンピュータ等の機器であって、ＨＴＴＰクライアントのネットワーク機能を有する。

ＩＭＳ／ＭＭＤ非対応の端末２は、ＨＴＴＰに対応するものとする。また、ＩＭＳ／ＭＭＤ対応のサーバは、ＳＩＰに対応するものとする。本発明によれば、プロキシサーバ１が、代理接続処理を実行するために、端末２のロケーション情報をレジストラサーバ５に登録する必要がある。その後、端末２は、プロキシサーバ１を介してＷｅｂサーバ４と通信できるようにする。

図２は、本発明におけるシーケンス図である。

（Ｓ２０１）端末２は、ＨＴＴＰリクエストをプロキシサーバ１へ送信する。このＨＴＴＰリクエストは、端末に搭載された既存のＷｅｂブラウザが、Ｗｅｂサーバのホームページを閲覧するために送信するリクエストと同じものである。従って、ＨＴＴＰリクエストの宛先アドレスは、ＩＭＳ／ＭＭＤ対応のＷｅｂサーバのＩＰアドレスとなる。

例えば、端末２は、以下のＨＴＴＰリクエストをプロキシサーバ１へ送信する。
GET http://www.example.com/sample.html HTTP/1.1

（Ｓ２０２）ＨＴＴＰリクエストを受信したプロキシサーバ１は、登録状態テーブルを確認する。登録状態テーブルは、ＨＴＴＰリクエストの送信元ＩＰアドレスに対応付けて、端末ＵＲＩと、登録状態とを蓄積する。登録状態には、例えば「認証中」「登録中」「登録済み」がある。

表１は、登録状態テーブルを表す。

（Ｓ２０３）表１によれば、ＨＴＴＰリクエストを送信した端末２のＩＰアドレスは、登録状態テーブルに含まれていない。この場合、プロキシサーバ１は、登録状態テーブルを更新する。具体的には、登録状態テーブルに、新たに当該端末２の項目を作成し、ＩＰアドレスを格納し、登録状態を「認証中」とする。例えば、表２のようになる。

尚、当該端末２のＩＰアドレスが、登録状態テーブルに既に含まれており、登録状態が「登録中」である場合には、後述するＨＴＴＰリクエストテーブルに、ＨＴＴＰリクエストのサーバＵＲＬを保持する。この場合は、当該ＨＴＴＰリクエストの直前に、他の端末からのＨＴＴＰリクエストによって代理接続が現に実行されていることを意味する。ここで、保持されたＨＴＴＰリクエストは、Ｗｅｂサーバへアクセスする際に、一括して実行される。

（Ｓ２０４）プロキシサーバ１は、ＨＴＴＰリクエストを送信した端末２に対して、４０１(Unauthorized)レスポンスを送信する。４０１レスポンスは、WWW-Authenticateヘッダを含む。例えば、以下のようなレスポンスが送信される。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="example.com"
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5CCC069C403EBAF9F0171E9517F40E41",
qop="auth,auth-int"

（Ｓ２０５）WWW-Authenticateを受信した端末は、再びＨＴＴＰリクエストをプロキシサーバ１へ送信する。ここで、ＨＴＴＰリクエストは、Authorizationヘッダを含む。Authorizationヘッダは、username及びuriを含む。プロキシサーバ１は、username及びuri（プライベート識別子）と、認証情報とを取得する。
GET http://www.example.com/sample.html HTTP/1.1
Authorization: Digest
username="rickey"
uri="sip:ricky@example.com"
realm="example.com"
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5CCC069C403EBAF9F0171E9517F40E41",
qop="auth,auth-int"

（Ｓ２０６）Authorizationヘッダを含むＨＴＴＰリクエストを受信したプロキシサーバ１は、認証テーブルを確認する。これにより、プロキシサーバ１は、代理接続の前に、端末を認証することができる。

プロキシサーバ１は、Ｓ２０５で取得したユーザ認証情報が、自身がもつユーザ認証情報と一致するかどうか確認する。一致しない場合はＮＧとして、４０３(Forbidden)を端末２へ送信する。そして、登録状態テーブルの端末２に対する項目を削除する。

（Ｓ２０７）次に、プロキシサーバ１は、登録状態テーブルを更新する。登録状態テーブルに、Authorizationヘッダに含まれる端末uriをSIP-URIとして格納する。そして、登録状態テーブルの登録状態を「登録中」に変更する。

（Ｓ２０８）次に、プロキシサーバ１は、そのＨＴＴＰリクエストを、ＨＴＴＰリクエストテーブルに保存する。ＨＴＴＰリクエストテーブルは、端末毎に、登録中のサーバＵＲＬを保持するテーブルである。ここで、新たな項目に、端末のＩＰアドレスに対応付けて、SIP-URI及びサーバＵＲＬを保持する。

（Ｓ２０９）次に、プロキシサーバ１は、REGISTER（登録）リクエストを作成する。レジストラサーバに登録される端末のＩＰアドレスとしては、プロキシサーバ１のＩＰアドレスを使用する。REGISTERリクエストは、例えば、以下のようになる。
REGISTER sip:ss1.example.com SIP/2.0
Max-Forwards: 70
Via: SIP/2.0/UDP 192.0.2.201;branch=z9hG4bK74aj7
From: <sip:ricky@example.com>;tag=9fxctr75e
To: <sip:ricky@example.com>
Call-ID: 38576@192.0.2.201
CSeq: 27084 REGISTER
Contact: <sip:ricky@192.0.2.201>
Contact-Length: 0

Fromヘッダ及びToヘッダは、端末２から受信したＨＴＴＰリクエストのAuthorizationヘッダの端末URIをSIP-URIとして含む。Fromヘッダは、リクエストの送信元を表す。Toヘッダは、リクエストの送信先を表し、REGISTERリクエストの場合、ユーザのアドレス−オブ−レコード(AoR:Address
of Record)を表す。これにより、レジストラサーバ５は、ＨＴＴＰ対応端末２を、プロキシサーバ１を介して登録することができる。

（Ｓ２１０）プロキシサーバ１は、レジストラサーバ５へREGISTERリクエストを送信する。

（Ｓ２１１）レジストラサーバ５は、端末rickyのロケーション情報を登録すると、以下のようなレスポンスを、プロキシサーバ１へ応答する。
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.201;branch=z9hG4bK74aj7
From: <sip:ricky@example.com>;tag=9fxctr75e
To: <sip:ricky@example.com>;tag=37GkEhw16
Call-ID: 38576@192.0.2.201
CSeq: 27084 REGISTER
Contact: <sip:ricky@192.0.2.201>;expires=3600
Contact-Length: 0

（Ｓ２１２）プロキシサーバ１は、登録状態テーブルの端末２の登録状態を「登録中」に変更する。

（Ｓ２１３）プロキシサーバ１は、ＨＴＴＰリクエストテーブルを参照し、端末２のＩＰアドレスに対応するサーバＵＲＬを用いて、Ｗｅｂサーバ４へＨＴＴＰリクエストを送信する。ＨＴＴＰリクエストを送信した場合、ＨＴＴＰリクエストテーブルから、サーバＵＲＬは削除される。

（Ｓ２１２）Ｗｅｂサーバ４は、プロキシサーバ１へＨＴＴＰレスポンスを送信する。
（Ｓ２１３）Ｗｅｂサーバ４からＨＴＴＰレスポンスを受信したプロキシサーバ１は、端末２へそのＨＴＴＰレスポンスを転送する。このように、プロキシサーバ１は、代理接続中に、端末２の端末ＵＲＩ等の接続情報を管理することにより、オールＩＰコアネットワークからのシグナリングを、ＳＩＰ非対応の端末２へ通知することができる。

尚、通常、ユーザ端末がＷｅｂブラウジングをする際には、ＩＰアドレスではなくＦＱＤＮ(www.dion.ne.jp等)によりアクセス先を指定する。ＦＱＤＮをＩＰアドレスに変換する作業は、ＷｅｂブラウザがＤＮＳ(Domain Name Server)サービスを利用して実行する。従って、端末は、ＨＴＴＰリクエストを送信する前に、ＤＮＳ要求を送信することがほとんどである。しかしながら、ホームネットワークでは、ＤＮＳサービスはブロードバンドルータ等で実行されるため、ＤＮＳサービス自体がREGISTER処理の前であったとしても問題ない。

図３は、本発明におけるプロキシサーバの機能構成図である。

図３によれば、プロキシサーバ１は、ＨＴＴＰサーバ部１０１と、端末認証部１０２と、ＳＩＰクライアント部１０３と、ＨＴＴＰクライアント部１０４と、認証テーブル蓄積部１０５と、登録状態テーブル蓄積部１０６と、ＨＴＴＰリクエストテーブル蓄積部１０７とを有する。これら各機能部は、プロキシサーバに搭載されたコンピュータを機能させるプログラムによっても実現できる。

ＨＴＴＰサーバ部１０１は、ＨＴＴＰに対応する端末に対して、サーバとしての機能を有する。

端末認証部１０２は、ＨＴＴＰサーバ部１０１を介して端末からＨＴＴＰリクエストを受信した際に、その端末との間でＨＴＴＰ認証シーケンスを実行する。具体的には、端末認証部１０２は、端末へWWW-Authenticateヘッダを含むＨＴＴＰレスポンスを送信し、端末から、Authorizationヘッダを含むＨＴＴＰリクエストを受信する。認証情報は、認証テーブル蓄積部１０５に蓄積されている。

ＳＩＰクライアント部１０３は、ＨＴＴＰ認証シーケンスによって端末ＵＲＩを取得し、該端末ＵＲＩをSIP-URIとするREGISTERリクエストをレジストラサーバへ送信する。ここで、Authorizationヘッダに含まれる端末ＵＲＩが、SIP-URIとして、REGISTERリクエストに含められる。

ＨＴＴＰクライアント部１０４は、ＳＩＰクライアントを介してレジストラサーバから登録完了レスポンスを受信した際に、ＨＴＴＰリクエストをＷｅｂサーバへ送信し、Ｗｅｂサーバから受信したＨＴＴＰレスポンスを、ＨＴＴＰサーバ部１０１へ通知して端末へ送信する。ＨＴＴＰクライアント部１０４は、端末ＵＲＩに基づくサーバＵＲＬのＷｅｂサーバへＨＴＴＰリクエストを送信する。ＨＴＴＰリクエストテーブル蓄積部１０７は、端末のＩＰアドレスに対応付けて、端末ＵＲＩ及びサーバＵＲＬを保持する。また、登録状態テーブル蓄積部１０６は、登録状態の進行を表示する。

前述した本発明における種々の実施形態によれば、当業者は、本発明の技術思想及び見地の範囲における種々の変更、修正及び省略を容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

本発明におけるシステム構成図である。本発明におけるシーケンス図である。本発明におけるプロキシサーバの機能構成図である。

符号の説明

１プロキシサーバ
１０１ＨＴＴＰサーバ部
１０２端末認証部
１０３ＳＩＰクライアント部
１０４ＨＴＴＰクライアント部
１０５認証テーブル蓄積部
１０６登録状態テーブル蓄積部
１０７ＨＴＴＰリクエストテーブル蓄積部
２ＩＭＳ／ＭＭＤ非対応端末
３ＩＭＳ／ＭＭＤ対応端末
４Ｗｅｂサーバ
５レジストラサーバ
６オールＩＰコアネットワーク、ＩＭＳ／ＭＭＤプラットホーム
７移動通信網
８固定通信網

Claims

ＨＴＴＰに対応する端末と、ＳＩＰに対応するレジストラサーバ及びＷｅｂサーバとの間に接続されたプロキシサーバにおける代理接続方法において、
前記端末からＨＴＴＰリクエストを受信した際に、該端末との間でＨＴＴＰ認証シーケンスを実行する第１のステップと、
前記ＨＴＴＰ認証シーケンスによって端末ＵＲＩを取得し、該端末ＵＲＩをSIP-URIとするREGISTERリクエストを前記レジストラサーバへ送信する第２のステップと、
前記レジストラサーバから登録完了レスポンスを受信した際に、前記ＨＴＴＰリクエストをＷｅｂサーバへ送信する第３のステップと、
前記Ｗｅｂサーバから受信したＨＴＴＰレスポンスを、前記端末へ送信する第４のステップと
を有することを特徴とする代理接続方法。
前記第１のステップは、
前記端末からＨＴＴＰリクエストを受信した際に、前記端末へWWW-Authenticateヘッダを含むＨＴＴＰレスポンスを送信するステップと、
前記端末から、Authorizationヘッダを含むＨＴＴＰリクエストを受信するステップとを有し、
前記第２のステップは、前記Authorizationヘッダに含まれる端末ＵＲＩをSIP-URIとするREGISTERリクエストを前記レジストラサーバへ送信する
ことを特徴とする請求項１に記載の代理接続方法。
前記第２のステップは、前記端末のＩＰアドレスに対応付けて、前記端末ＵＲＩ及びサーバＵＲＬを保持し、
前記第３のステップは、前記端末ＵＲＩに対応するサーバＵＲＬのＷｅｂサーバへＨＴＴＰリクエストを送信する
ことを特徴とする請求項１又は２に記載の代理接続方法。
ＨＴＴＰに対応する端末と、ＳＩＰに対応するレジストラサーバ及びＷｅｂサーバとの間に接続されたプロキシサーバにおいて、
前記端末に対するＨＴＴＰサーバ手段と、
前記ＨＴＴＰサーバ手段を介して前記端末からＨＴＴＰリクエストを受信した際に、該端末との間でＨＴＴＰ認証シーケンスを実行する端末認証手段と、
前記ＨＴＴＰ認証シーケンスによって端末ＵＲＩを取得し、該端末ＵＲＩをSIP-URIとするREGISTERリクエストを前記レジストラサーバへ送信するＳＩＰクライアント手段と、
前記ＳＩＰクライアントを介して前記レジストラサーバから登録完了レスポンスを受信した際に、前記ＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信し、前記Ｗｅｂサーバから受信したＨＴＴＰレスポンスを、前記ＨＴＴＰサーバ手段へ通知して前記端末へ送信するＨＴＴＰクライアント手段と
を有することを特徴とするプロキシサーバ。
前記端末認証手段は、前記ＨＴＴＰサーバ手段によって前記端末からＨＴＴＰリクエストを受信した際に、前記端末へWWW-Authenticateヘッダを含むＨＴＴＰレスポンスを送信し、前記端末から、Authorizationヘッダを含むＨＴＴＰリクエストを受信するものであり、
前記ＳＩＰクライアント手段は、前記Authorizationヘッダに含まれる端末ＵＲＩをSIP-URIとしてREGISTERリクエストに含める
ことを特徴とする請求項４に記載のプロキシサーバ。
前記端末のＩＰアドレスに対応付けて、前記端末ＵＲＩ及びサーバＵＲＬを保持するＨＴＴＰリクエストテーブル蓄積手段を更に有し、
前記ＨＴＴＰクライアント手段は、前記端末ＵＲＩに基づくサーバＵＲＬのＷｅｂサーバへＨＴＴＰリクエストを送信する
ことを特徴とする請求項４又は５に記載のプロキシサーバ。
ＨＴＴＰに対応する端末と、ＳＩＰに対応するレジストラサーバ及びＷｅｂサーバとの間に接続されたプロキシサーバに搭載されたコンピュータを機能させるプログラムにおいて、
前記端末に対するＨＴＴＰサーバ手段と、
前記ＨＴＴＰサーバ手段を介して前記端末からＨＴＴＰリクエストを受信した際に、該端末との間でＨＴＴＰ認証シーケンスを実行する端末認証手段と、
前記ＨＴＴＰ認証シーケンスによって端末ＵＲＩを取得し、該端末ＵＲＩをSIP-URIとするREGISTERリクエストを前記レジストラサーバへ送信するＳＩＰクライアント手段と、
前記ＳＩＰクライアントを介して前記レジストラサーバから登録完了レスポンスを受信した際に、前記ＨＴＴＰリクエストを前記Ｗｅｂサーバへ送信し、前記Ｗｅｂサーバから受信したＨＴＴＰレスポンスを、前記ＨＴＴＰサーバ手段へ通知して前記端末へ送信するＨＴＴＰクライアント手段と
してコンピュータを機能させることを特徴とするプロキシサーバ用のプログラム。
前記端末認証手段は、前記ＨＴＴＰサーバ手段によって前記端末からＨＴＴＰリクエストを受信した際に、前記端末へWWW-Authenticateヘッダを含むＨＴＴＰレスポンスを送信し、前記端末から、Authorizationヘッダを含むＨＴＴＰリクエストを受信するものであり、
前記ＳＩＰクライアント手段は、前記Authorizationヘッダに含まれる端末ＵＲＩをSIP-URIとしてREGISTERリクエストに含める
ようにコンピュータを機能させることを特徴とする請求項７に記載のプロキシサーバ用のプログラム。
前記端末のＩＰアドレスに対応付けて、前記端末ＵＲＩ及びサーバＵＲＬを保持するＨＴＴＰリクエストテーブル蓄積手段を更に有し、
前記ＨＴＴＰクライアント手段は、前記端末ＵＲＩに基づくサーバＵＲＬのＷｅｂサーバへＨＴＴＰリクエストを送信する
ようにコンピュータを機能させることを特徴とする請求項７又は８に記載のプロキシサーバ用のプログラム。