[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP2002157175A - サーバー、クライアント、ゲートウェイ及び通信開始方法 - Google Patents

サーバー、クライアント、ゲートウェイ及び通信開始方法

Info

Publication number
JP2002157175A
JP2002157175A JP2000353439A JP2000353439A JP2002157175A JP 2002157175 A JP2002157175 A JP 2002157175A JP 2000353439 A JP2000353439 A JP 2000353439A JP 2000353439 A JP2000353439 A JP 2000353439A JP 2002157175 A JP2002157175 A JP 2002157175A
Authority
JP
Japan
Prior art keywords
session
client
server
request
transmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2000353439A
Other languages
English (en)
Other versions
JP4663100B2 (ja
Inventor
Taiji Ido
大治 井戸
Toru Terada
徹 寺田
Yuuki Horiuchi
優希 堀内
Seiji Ura
誠治 浦
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Priority to JP2000353439A priority Critical patent/JP4663100B2/ja
Publication of JP2002157175A publication Critical patent/JP2002157175A/ja
Application granted granted Critical
Publication of JP4663100B2 publication Critical patent/JP4663100B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)
  • Facsimile Transmission Control (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

(57)【要約】 【課題】 セッションを確立する時間を短縮するこ
と。 【解決手段】 セッションＩＤ割当部１１２は、複数の
リクエストが同じクライアントから送信されたセッショ
ンＩＤを使用している場合、セッションＩＤ割当部１１
２は、同じセッションＩＤをレスポンス送信部１１３に
出力する。また、異なるクライアントから同じセッショ
ンＩＤが送信された場合、セッションＩＤ割当部１１２
は、使用可能な別のセッションＩＤを新たに生成してレ
スポンス送信部１１３に出力する。レスポンス送信部１
１３は、セッションＩＤ割当部１１２から出力されたセ
ッションＩＤとＡＣＫコマンドとをクライアント１００
に送信する。メディア送信部１１４は、メディア送信の
準備ができた後に、レスポンス送信部１１３にメディア
送信の準備が完了したことを通知し、メディアデータを
クライアント１００に送信する。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、マルチメディアデ
ィジタルデータを伝送、再生するためのサーバー、クラ
イアント、ゲートウェイ及び通信開始方法に関し、特に
インターネットや無線通信網を通して、画像や音声など
のマルチメディアディジタルデータを伝送、再生するた
めのサーバー、クライアント、ゲートウェイ及び通信開
始方法に関する。
【０００２】
【従来の技術】インターネットや無線通信網などのパケ
ット通信回線を通して、画像や音声などのディジタルデ
ータ（マルチメディアデータ）を伝送し、ストリーミン
グアプリケーションを実行する場合、ＩＥＴＦ（Ｉｎｔ
ｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏ
ｒｃｅ）で定められているＲＦＣ２３２６またはＲＴＳ
Ｐ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏ
ｔｏｃｏｌ）等のプロトコルにしたがってデータをやり
取りする。ここで、ＲＴＳＰは、マルチメディアデータ
を再生するクライアントと、マルチメディアデータを保
存し提供するサーバーとの間の通信手順や制御方法を定
めたプロトコルである。
【０００３】ＲＴＳＰは、ＴＣＰ（Transmission Cont
rol Protocol）等の信頼性のあるプロトコル上で用い
られ、伝送すべきストリームの特定、伝送プロトコルの
指定、ストリーム送信開始、ポーズ、及び中止となどの
制御を行う機能を備える。
【０００４】ＴＣＰは、ＩＰ（Internet Protocol）層
の上で動作し、プロトコルの上位層にあるクライアント
に対して、信頼性のある順番の保証された、フロー制御
されたエンド−エンドのオクテットストリームを提供す
るように設計されたプロトコルである。
【０００５】図１５は、ストリーミングアプリケーショ
ンの概念を示した図である。マルチメディアデータを再
生する場合、クライアント１１は、ディジタルデータ
（コンテンツ）が保存されているサーバー１２に対し、
最初にセッション開設やメディアの再生開始といったリ
クエスト（制御コマンド）を送信する。サーバー１２は
クライアント１１からの制御コマンドに応じて指定され
たディジタルデータの送信を開始、または停止する。
【０００６】サーバー１２とクライアント１１は、上記
のようなプロトコルを用いてインターネット１３や無線
網を通じて互いに接続されている。
【０００７】図１６は、ＲＴＳＰを用いたストリーミン
グのプロトコル構成の一例を示す図である。サーバーと
クライアントは、お互いにＩＰを用いて通信を行う。
【０００８】また、ＩＰの上位にはＴＣＰやＲＴＰ／Ｕ
ＤＰ（Real Time Transport Protocol／User Datagram
Protocol）を用いたサーバーとクライアントとの間の通
信の通信手順が規定されている。オーディオデータ及び
ビデオデータなどのコンテンツデータは、リアルタイム
で送信する必要があるので、ＲＴＰ／ＵＤＰといったフ
ロー制御や順序制御を行わずにデータを送信するプロト
コル上で伝送されることが多い。
【０００９】ＵＤＰは、インターネットのホストのペア
間で交換されるデータグラムの多重化をサポートするプ
ロトコルである。ＵＤＰは、データグラムの再送信、パ
ケット化、再構成、フロー制御、及び輻輳回避等の機能
を提供していないので、ＵＤＰの上位プロトコルは、こ
れらの機能を提供する必要がある。
【００１０】また、ＲＴＳＰで用いられる制御コマンド
は、リアルタイム性よりも信頼性が重視されることが多
いので、ＴＣＰ上で使用されることが普通である。
【００１１】以下、ＲＴＳＰを用いた通信開始手順につ
いて図１７を用いて説明する。図１７は、従来のセッシ
ョン開設及び再生開始の手順を説明するためのシーケン
ス図である。
【００１２】クライアントは再生したいオーディオやビ
デオなどのメディアを選択し、各メディアの再生準備を
サーバーに対してリクエスト信号を送信する（ＳＥＴＵ
Ｐコマンド）。
【００１３】サーバーは、要求されたメディアを伝送準
備可能であることを通知するために肯定レスポンス信号
（ＡＣＫコマンド：ACKNOWLEDGEMENT）を送信すると同
時に、セッションを固有に識別するセッションＩＤをク
ライアントに発行する。
【００１４】クライアントがＡＣＫコマンドを受信する
とセットアップが完了する。クライアントは再生するす
べてのメディアに関するセットアップが完了した後、マ
ルチメディアデータを送るようにサーバーにリクエスト
信号（ＰＬＡＹコマンド）を送信する。
【００１５】複数のメディアデータを同一セッションで
再生する場合には、前記複数メディアのセッションＩＤ
が同一になるようにする必要がある。図１７に示すよう
に、第１のセットアップが終了し、セッションＩＤがサ
ーバーからクライアントに付与された後、クライアント
は第２番目以降のメディアについて付与された前記セッ
ションＩＤを指定してセットアップを行う。このような
方法により共通のセッションＩＤを用いれば、複数のメ
ディアデータを同一のセッションで送信することができ
る。
【００１６】また、ＲＴＳＰでは複数メディアデータを
扱う時に、セッションＩＤがすでに付与されている場合
には、同一のＳＥＴＵＰコマンドを複数同時に送信する
ことができる。
【００１７】図１８は、従来のセッション開設及び再生
開始の手順を説明するためのシーケンス図である。
【００１８】図１８に示すように、第２番目以降のＳＥ
ＴＵＰコマンドについては、サーバーから各ＳＥＴＵＰ
コマンドに対する各ＡＣＫコマンドを受信するのを待た
ずに、連続してセットアップリクエスト信号をサーバー
に送信することができる。
【００１９】第２番目以降のＳＥＴＵＰコマンドを連続
して送信することによって、セットアップ完了までの時
間を短縮することができる。
【００２０】
【発明が解決しようとする課題】しかしながら、従来の
通信開始方法においては、クライアントとサーバーの間
にセッションを確立するために、同一セッションの個々
のリクエストについて返答を受信した後に次のリクエス
トを送信するので、セッションを確立するまでの時間が
長いという問題がある。
【００２１】本発明はかかる点に鑑みてなされたもので
あり、クライアントとサーバーの間にセッションを確立
する時間を短縮するサーバークライアント及び通信開始
方法を提供することを目的とする。
【００２２】
【課題を解決するための手段】本発明のサーバーは、ク
ライアント固有の情報に基づいて複数のリクエストが同
一のクライアントから送信されたか否かを判定する第一
判定手段と、前記複数のリクエストが同一のクライアン
トから送信された場合、前記複数のリクエストに対して
同一のセッションを開設するセッション設定手段と、前
記開設されたセッションで前記リクエストに対応するオ
ブジェクトを前記クライアントに送信するメディア送信
手段と、を具備する構成を採る。
【００２３】この構成によれば、サーバーは、クライア
ントを区別する情報を用いて複数のリクエストが同じク
ライアントから送信されたか否か判断して、同じクライ
アントから送信された複数のリクエストに対して同一の
セッションを開設することにより、クライアントは、同
一のセッションのリクエストを連続してサーバーに送信
することができる。
【００２４】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【００２５】本発明のサーバーは、セッション設定手段
は、クライアントから送信されたセッションＩＤを用い
てセッションを開設する構成を採る。
【００２６】この構成によれば、クライアントが生成し
たセッションＩＤを用いてセッションを開設することに
より、クライアントは、同一のセッションのリクエスト
を連続してサーバーに送信することができ、サーバーか
らの返答を待つ時間を減少させることができ、クライア
ントとサーバーの間にセッションを確立する時間を短縮
することができる。
【００２７】本発明のサーバーは、第一判定手段は、ク
ライアントから送信されたセッションＩＤが使用可能で
あるか否か判定し、前記セッションＩＤが使用不可能で
ある場合、使用可能なセッションＩＤを新たに生成し、
セッション設定手段は、前記新たに生成したセッション
ＩＤを用いてセッションを開設する構成を採る。
【００２８】この構成によれば、セッションＩＤが重複
する場合でも、サーバーが生成したセッションＩＤを用
いることにより、セッションを開設することができるの
で、クライアントは、同一のセッションのリクエストを
連続してサーバーに送信することができる。
【００２９】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【００３０】本発明のクライアントは、同一のセッショ
ンで通信を行うリクエストに対して、連続してリクエス
トを上記記載のサーバーに送信する第一リクエスト送信
手段と、前記リクエストに対応するオブジェクトを受信
するメディア受信手段と、を具備する構成を採る。
【００３１】本発明のクライアントは、第一リクエスト
送信手段は、オブジェクトの送信準備を連続してサーバ
ーに要求する構成を採る。
【００３２】本発明のクライアントは、第一リクエスト
送信手段は、オブジェクトの送信準備とオブジェクトの
送信開始とを連続してサーバーに要求する構成を採る。
【００３３】これらの構成によれば、サーバーは、クラ
イアントを区別する情報を用いて複数のリクエストが同
じクライアントから送信されたか否か判断して、同じク
ライアントから送信された複数のリクエストに対して同
一のセッションを開設することにより、クライアント
は、同一のセッションのリクエストを連続してサーバー
に送信することができる。
【００３４】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【００３５】本発明のクライアントは、セッションＩＤ
を生成するセッションＩＤ生成手段を具備し、第一リク
エスト送信手段は、リクエストと共に前記セッションＩ
Ｄをサーバーに送信する構成を採る。
【００３６】この構成によれば、クライアントが生成し
たセッションＩＤを用いてセッションを開設することに
より、クライアントは、同一のセッションのリクエスト
を連続してサーバーに送信することができ、サーバーか
らの返答を待つ時間を減少させることができ、クライア
ントとサーバーの間にセッションを確立する時間を短縮
することができる。
【００３７】本発明のクライアントは、セッションＩＤ
生成手段は、クライアント固有の情報に基づいてセッシ
ョンＩＤを生成する構成を採る。
【００３８】本発明のクライアントは、セッションＩＤ
生成手段は、クライアントに設定したインターネットプ
ロトコルアドレスを用いてセッションＩＤを生成する構
成を採る。
【００３９】本発明のクライアントは、セッションＩＤ
生成手段は、クライアントの物理アドレスを用いてセッ
ションＩＤを生成する構成を採る。
【００４０】これらの構成によれば、セッションＩＤの
重複をさけることができる。
【００４１】本発明のクライアントは、下位プロトコル
が、送信するリクエストの確実な到着及び送信順序と到
着順序が同じであることを保証するプロトコルであるか
否かを判断する第二判定手段を具備し、第一リクエスト
送信手段は、送信するリクエストの確実な到着及び送信
順序と到着順序が同じであることを保証しないプロトコ
ルである場合、オブジェクトの送信準備の要求に対する
返答を受信した後にオブジェクトの送信開始を要求する
構成を採る。
【００４２】この構成によれば、クライアントは、要求
の確実な到着及び送信順序と到着順序が同じであること
を保証するプロトコルを用いる場合には、送信準備の要
求と送信の要求を連続して送信することにより、サーバ
ーは、同一セッションの全ての送信準備の要求を受信し
た後に、送信開始の要求を受信することができる。
【００４３】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【００４４】本発明のゲートウェイは、同一のセッショ
ンで通信を行うリクエストに対して、クライアントから
送信されたリクエストを一時記憶する記憶手段と、オブ
ジェクトの送信準備の要求に対する返答をサーバーから
受信した後に、前記オブジェクトの送信を要求する第二
リクエスト送信手段と、を具備する構成を採る。
【００４５】この構成によれば、送信準備の要求に対す
る返答をサーバーから受信した後に、送信をサーバーに
要求することにより、クライアントは、送信準備の要求
と送信の要求を連続して送信することができる。
【００４６】従って、本発明の通信開始方法と異なる通
信開始方法を用いる通信装置との通信を行うことがで
き、かつクライアントとサーバーの間にセッションを確
立する時間を短縮することができる。
【００４７】本発明のゲートウェイは、サーバーとの通
信に用いるセッションＩＤとクライアントとの通信に用
いるセッションＩＤとを関連つけて記憶し、サーバーと
の通信に用いるセッションＩＤをクライアントとの通信
に用いるセッションＩＤに変換し、クライアントとの通
信に用いるセッションＩＤをサーバーとの通信に用いる
セッションＩＤに変換する変換手段、を具備する構成を
採る。
【００４８】この構成によれば、クライアントとの通信
に用いるセッションＩＤとサーバーとの通信に用いるセ
ッションＩＤを対応つけて記憶し、セッションＩＤを変
換することにより、本発明の通信開始方法と異なる通信
開始方法を用いる通信装置との通信を行うことができ、
かつクライアントとサーバーの間にセッションを確立す
る時間を短縮することができる。
【００４９】本発明の通信開始方法は、クライアント
は、複数のリクエストを連続してサーバーに送信し、前
記サーバーは、クライアント固有の情報に基づいて複数
のリクエストが同一のクライアントから送信されたか否
かを判定し、前記複数のリクエストが同一のクライアン
トから送信された場合、前記複数のリクエストに対して
同一のセッションを開設するようにした。
【００５０】本発明の通信開始方法は、クライアント
は、複数のオブジェクトの送信準備を連続してサーバー
に要求し、前記サーバーは、クライアント固有の情報に
基づいて複数のリクエストが同一のクライアントから送
信されたか否かを判定し、前記複数のリクエストが同一
のクライアントから送信された場合、前記複数のリクエ
ストに対して同一のセッションを開設するようにした。
【００５１】本発明の通信開始方法は、クライアント
は、オブジェクトの送信準備の要求と、前記オブジェク
トの送信の要求とを連続してサーバーに送信し、前記サ
ーバーは、クライアント固有の情報に基づいて複数のリ
クエストが同一のクライアントから送信されたか否かを
判定し、前記複数のリクエストが同一のクライアントか
ら送信された場合、前記複数のリクエストに対して同一
のセッションを開設するようにした。
【００５２】これらの方法によれば、サーバーは、クラ
イアントを区別する情報を用いて複数のリクエストが同
じクライアントから送信されたか否か判断して、同じク
ライアントから送信された複数のリクエストに対して同
一のセッションを開設することにより、クライアント
は、同一のセッションのリクエストを連続してサーバー
に送信することができる。
【００５３】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【００５４】本発明の通信開始方法は、クライアント
は、セッションＩＤを生成し、前記セッションＩＤとリ
クエストとを共にサーバーに送信し、前記サーバーは、
前記セッションＩＤが使用可能である場合、前記セッシ
ョンＩＤを用いてセッションを開設し、前記セッション
ＩＤが使用不可能である場合、使用可能なセッションＩ
Ｄを新たに生成して、前記新たに生成したセッションＩ
Ｄを用いてセッションを開設するようにした。
【００５５】この方法によれば、クライアントが生成し
たセッションＩＤを用いてセッションを開設することに
より、クライアントは、同一のセッションのリクエスト
を連続してサーバーに送信することができ、サーバーか
らの返答を待つ時間を減少させることができ、クライア
ントとサーバーの間にセッションを確立する時間を短縮
することができる。
【００５６】また、セッションＩＤが重複する場合で
も、サーバーが生成したセッションＩＤを用いることに
より、セッションを開設することができるので、クライ
アントは、同一のセッションのリクエストを連続してサ
ーバーに送信することができる。
【００５７】本発明の通信開始方法は、下位プロトコル
が、送信するリクエストの確実な到着及び送信順序と到
着順序が同じであることを保証するプロトコルであるか
否かを判断し、送信するリクエストの確実な到着及び送
信順序と到着順序が同じであることを保証しないプロト
コルである場合、オブジェクトを要求するリクエストの
返答を受信した後にオブジェクトの送信開始を要求する
ようにした。
【００５８】この方法によれば、クライアントは、要求
の確実な到着及び送信順序と到着順序が同じであること
を保証するプロトコルを用いる場合には、送信準備の要
求と送信の要求を連続して送信することにより、サーバ
ーは、同一セッションの全ての送信準備の要求を受信し
た後に、送信開始の要求を受信することができる。
【００５９】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【００６０】
【発明の実施の形態】本発明の骨子は、サーバーとクラ
イアント間の同一セッションの通信において、クライア
ントは、同一のセッションのリクエストを連続してサー
バーに送信し、サーバーは、クライアントを区別する情
報を用いて複数のリクエストが同じクライアントから送
信されか否かを判定し、複数のリクエストが同じクライ
アントから送信された場合、前記複数のリクエストに対
して同一のセッションを開設することである。
【００６１】以下、本発明の実施の形態について、図面
を参照して詳細に説明する。
【００６２】（実施の形態１）図１は、本発明の実施の
形態１に係るサーバー及びクライアントの構成を示すブ
ロック図である。
【００６３】図１において、クライアント１００は、要
求セッションＩＤ生成部１０１と、リクエスト生成部１
０２と、レスポンス受信部１０３と、メディア受信部１
０４と、メディア再生部１０５とから主に構成される。
また、サーバー１１０は、リクエスト受信部１１１と、
セッションＩＤ割当部１１２と、レスポンス送信部１１
３と、メディア送信部１１４とから主に構成される。
【００６４】要求セッションＩＤ生成部１０１は、新た
なセッションを設定する場合、セッションＩＤを生成し
てリクエスト生成部１０２に出力する。
【００６５】リクエスト生成部１０２は、サーバー１１
０と通信を開始する場合、最初にメディアデータの送信
を要求するＳＥＴＵＰコマンドと、要求セッションＩＤ
生成部１０１から出力されたセッションＩＤとをサーバ
ー１１０に送信する。
【００６６】また、リクエスト生成部１０２は、レスポ
ンス受信部１０３からメディアデータが送信可能である
ことを通知された後に、各メディアデータの送信を要求
するＰＬＡＹコマンドをレスポンス受信部１０３から出
力されたセッションＩＤと共にサーバー１１０に送信す
る。
【００６７】レスポンス受信部１０３は、サーバー１１
０から受信したセッションＩＤをリクエスト生成部１０
２に出力する。また、レスポンス受信部１０３は、サー
バー１１０からＡＣＫコマンドを受信した場合、リクエ
スト生成部１０２にメディアデータがサーバーから送信
可能であることを通知する。
【００６８】また、レスポンス受信部１０３は、サーバ
ー１１０からクライアント１００にメディアデータを伝
送することを通知するＡＣＫコマンドを受信した場合、
メディアデータが送信されることをメディア受信部１０
４に通知する。
【００６９】メディア受信部１０４は、レスポンス受信
部１０３からメディアデータが送信されることを通知さ
れた場合、サーバー１１０から送信されたメディアデー
タを受信してメディア再生部１０５に出力する。
【００７０】メディア再生部１０５は、メディア受信部
１０４から出力されたメディアデータを再生する。
【００７１】リクエスト受信部１１１は、クライアント
１００からセッションＩＤを受信すると、このセッショ
ンＩＤをセッションＩＤ割当部１１２に出力する。
【００７２】また、リクエスト受信部１１１は、クライ
アント１００からＳＥＴＵＰコマンドを受信すると、メ
ディアデータを送信する準備をメディア送信部１１４に
指示する。また、リクエスト受信部１１１は、クライア
ント１００からＰＬＡＹコマンドを受信すると、メディ
アデータの送信をメディア送信部１１４に指示する。
【００７３】セッションＩＤ割当部１１２は、リクエス
ト受信部１１１から出力されたセッションＩＤが使用可
能か否か判断し、使用可能である場合、セッションＩＤ
割当部１１２は、リクエスト受信部１１１から出力され
たセッションＩＤをレスポンス送信部１１３に出力す
る。
【００７４】また、セッションＩＤ割当部１１２は、同
じＩＤがすでに使用されている等の理由により、リクエ
スト受信部１１１から出力されたセッションＩＤとが使
用できない場合、使用可能なセッションＩＤを発行して
レスポンス送信部１１３に出力する。
【００７５】また、セッションＩＤ割当部１１２は、Ｉ
Ｐアドレス等のクライアントを識別することが可能な情
報を用いて同じクライアントから送信されたセッション
ＩＤか否かを判断する。
【００７６】複数のリクエストが同じクライアントから
送信されたセッションＩＤを使用している場合、セッシ
ョンＩＤ割当部１１２は、１つのセッションで複数のメ
ディアを扱うと判断して同じセッションＩＤをレスポン
ス送信部１１３に出力する。
【００７７】また、異なるクライアントから同じセッシ
ョンＩＤが送信された場合、セッションＩＤ割当部１１
２は、このセッションＩＤがすでに使用されていると判
断し、使用可能な別のセッションＩＤを新たに生成して
レスポンス送信部１１３に出力する。
【００７８】レスポンス送信部１１３は、メディア送信
部１１４からメディア送信の準備が出来たことの通知を
受けると、セッションＩＤ割当部１１２から出力された
セッションＩＤとＡＣＫコマンドとをクライアント１０
０に送信する。
【００７９】メディア送信部１１４は、リクエスト受信
部１１１から出力された指示に従い、メディア送信の準
備を行う。そして、メディア送信部１１４は、メディア
送信の準備ができた後に、レスポンス送信部１１３にメ
ディア送信の準備が完了したことを通知し、送信の指示
に従ってメディアデータをクライアント１００に送信す
る。
【００８０】次に、上記構成を有するサーバー及びクラ
イアントにおける、セッション開設及び再生開始の手順
の一例を、シーケンス図を用いて説明する。図２は、本
発明の実施の形態１に係るセッション開設及び再生開始
の手順を説明するための第１のシーケンス図である。
【００８１】図２において、クライアント１００の要求
セッションＩＤ生成部１０１は、セッションＩＤ（１２
３４５６７８）を生成し、リクエスト生成部１０２は、
このセッションＩＤを第１番目のメディア（ＶＩＤＥＯ
１）のＳＥＴＵＰコマンドと共にサーバー１１０に送信
する。
【００８２】次に、クライアント１００において、リク
エスト生成部１０２は、第２番目のメディア（ＶＩＤＥ
Ｏ２）のＳＥＴＵＰコマンドと第１メディアと同一の要
求セッションＩＤ（１２３４５６７８）をサーバー１１
０に送信する。
【００８３】次に、クライアント１００において、リク
エスト生成部１０２は、第３番目のメディア（ＡＵＤＩ
Ｏ１）のＳＥＴＵＰコマンドと第１メディアと同一の要
求セッションＩＤ（１２３４５６７８）をサーバー１１
０に送信する。
【００８４】サーバー１１０において、セッションＩＤ
割当部１１２は、受信したセッションＩＤ（１２３４５
６７８）が使用可能か否か判断し、受信したセッション
ＩＤ（１２３４５６７８）が使用可能である場合、レス
ポンス送信部１１３は、ＶＩＤＥＯ１のＳＥＴＵＰコマ
ンドに対するＡＣＫコマンドをクライアント１００に送
信する。ＶＩＤＥＯ２のＳＥＴＵＰコマンド及びＡＵＤ
ＩＯ１のＳＥＴＵＰコマンドと共に送信されたセッショ
ンＩＤに対しても同様にＡＣＫコマンドをそれぞれ送信
する。
【００８５】クライアント１００は、全てのメディアの
ＡＣＫコマンドを受信することによりサーバー１１０側
でメディアデータのセットアップが完了したことがわか
り、次にメディアの送信要求（ＰＬＡＹ）コマンドをサ
ーバー１１０に送信する。
【００８６】サーバー１１０は、ＰＬＡＹに対応するＡ
ＣＫコマンドをクライアント１００に送信し、その後、
マルチメディアデータの送信を開始する。サーバー１１
０は、マルチメディアデータを全て送信し終えるかクラ
イアント１００から停止要求がなされるまでマルチメデ
ィアデータをクライアント１００に送信し続ける。
【００８７】次に、クライアントが発行したセッション
ＩＤが使用できない場合について図３を用いて説明す
る。図３は、本発明の実施の形態１に係るセッション開
設及び再生開始の手順を説明するための第２のシーケン
ス図である。
【００８８】図３において、クライアント１００は、セ
ッションＩＤ（１２３４５６７８）を生成し、このセッ
ションＩＤをＶＩＤＥＯ１のＳＥＴＵＰコマンドと共に
サーバー１１０に送信する。
【００８９】次に、クライアントは、ＶＩＤＥＯ２のＳ
ＥＴＵＰコマンドとＶＩＤＥＯ１と同一の要求セッショ
ンＩＤ（１２３４５６７８）を送信する。クライアント
は、ＡＵＤＩＯ１のＳＥＴＵＰコマンドとＶＩＤＥＯ１
と同一の要求セッションＩＤ（１２３４５６７８）を送
信する。
【００９０】サーバー１１０は、受信したセッションＩ
Ｄ（１２３４５６７８）が使用不可能であると判断した
場合、使用可能なセッションＩＤ（７７７７７７７）を
新たに生成してクライアント１００に送信する。ＶＩＤ
ＥＯ２のＳＥＴＵＰコマンド及びＡＵＤＩＯ１のＳＥＴ
ＵＰコマンドと共に送信されたセッションＩＤ（１２３
４５６７８）に対しても同様にサーバー１１０が新たに
生成したセッションＩＤ（７７７７７７７）をクライア
ント１００に送信する。
【００９１】クライアント１００は、全てのメディアの
ＡＣＫコマンドとサーバー１１０が新たに生成したセッ
ションＩＤ（７７７７７７７）を受信することによりサ
ーバー１１０側でメディアデータのセットアップが完了
したことがわかる。
【００９２】そこで、クライアント１００は、全てのメ
ディアのＡＣＫコマンドを受信した後に、サーバー１１
０が新たに生成したセッションＩＤ（７７７７７７７）
とＰＬＡＹコマンドとをサーバー１１０に送信して、マ
ルチメディアデータを送信するようサーバー１１０に要
求する。
【００９３】サーバー１１０は、ＰＬＡＹコマンドに対
してＡＣＫコマンドをクライアント１００に送信し、そ
の後、マルチメディアデータの送信を開始する。サーバ
ー１１０は、マルチメディアデータを全て送信し終える
かクライアント１００から停止要求がなされるまでマル
チメディアデータをクライアント１００に送信し続け
る。
【００９４】このように、サーバーは、クライアントを
区別する情報を用いて複数のリクエストが同じクライア
ントから送信されたか否か判断して、同じクライアント
から送信された複数のリクエストに対して同一のセッシ
ョンを開設することにより、クライアントは、同一のセ
ッションのリクエストを連続してサーバーに送信するこ
とができる。
【００９５】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【００９６】また、クライアントが生成したセッション
ＩＤを用いてセッションを開設することにより、クライ
アントは、同一のセッションのリクエストを連続してサ
ーバーに送信することができ、サーバーからの返答を待
つ時間を減少させることができ、クライアントとサーバ
ーの間にセッションを確立する時間を短縮することがで
きる。
【００９７】また、セッションＩＤが重複する場合で
も、サーバーが生成したセッションＩＤを用いることに
より、セッションを開設することができるので、クライ
アントは、同一のセッションのリクエストを連続してサ
ーバーに送信することができる。
【００９８】なお、本実施の形態では、再生するメディ
アデータがビデオ２つ、オーディオ１つの場合を示した
が、それ以外のメディアの構成を採ることもできる。
【００９９】また、クライアントが生成するセッション
ＩＤは、クライアント固有に設定された情報に基づいて
生成することもできる。例えば、クライアントのＩＰア
ドレスやＭＡＣ（Media Access Control）アドレス等
をセッションＩＤとして生成することもできる。また、
携帯電話をクライアントとした場合、携帯電話の番号を
セッションＩＤとして生成することもできる。この場
合、セッションＩＤの重複をさけることができる。
【０１００】（実施の形態２）図４は、本発明の実施の
形態２に係るサーバー及びクライアントの構成を示すブ
ロック図である。但し、図１と同一の構成となるものに
ついては、図１と同一番号を付し、詳しい説明を省略す
る。
【０１０１】本発明の実施の形態２のサーバー及びクラ
イアントは、送信方法判定部２０１と、リクエスト生成
部２０２とを具備し、通信に用いる下位プロトコルがリ
クエストの確実な到着及び送信順序と到着順序が同じで
あることを保証か否かを判断して、リクエストの送信タ
イミングを決定する点が実施の形態１のサーバー及びク
ライアントと異なる。
【０１０２】以下、ＴＣＰをリクエストの確実な到着及
び送信順序と到着順序が同じであることを保証するプロ
トコル、ＵＤＰをリクエストの確実な到着及び送信順序
と到着順序が同じであることを保証しないプロトコルの
例として説明する。
【０１０３】図４において、送信方法判定部２０１は、
プロトコル情報に基づいてリクエストを送信する際に用
いる下位プロトコルが、ＴＣＰであるか否かを判断し
て、判断結果をリクエスト生成部２０２に出力する。
【０１０４】具体的には、送信方法判定部２０１は、リ
クエストを送信する際に用いる下位プロトコルが、ＴＣ
ＰであるかＵＤＰであるか判断して、判断結果をリクエ
スト生成部２０２に出力する。
【０１０５】レスポンス受信部１０３は、サーバー１１
０から受信したセッションＩＤをリクエスト生成部２０
２に出力する。また、レスポンス受信部１０３は、サー
バー１１０からＡＣＫコマンドを受信した場合、リクエ
スト生成部２０２にメディアデータが送信可能であるこ
とを通知する。
【０１０６】リクエスト生成部２０２は、メディアの再
生準備をサーバー１１０に要求するＳＥＴＵＰコマンド
をサーバー１１０に送信する。
【０１０７】そして、リクエスト生成部２０２は、送信
方法判定部２０１における判定の結果、下位プロトコル
がＵＤＰである場合、レスポンス受信部１０３からメデ
ィアデータが伝送可能であることを通知された後に、各
メディアデータの送信を要求するＰＬＡＹコマンドをレ
スポンス受信部１０３から出力されたセッションＩＤと
共にサーバー１１０に送信する。
【０１０８】また、リクエスト生成部２０２は、送信方
法判定部２０１における判定の結果、下位プロトコルが
ＴＣＰである場合、レスポンス受信部１０３から出力さ
れるメディアデータが伝送可能であることを通知される
または通知されないことに関係なく、メディアの再生準
備をサーバー１１０に要求するＳＥＴＵＰコマンドを出
力した後に、レスポンス受信部１０３から出力されたセ
ッションＩＤとＰＬＡＹコマンドとをサーバー１１０に
送信する。
【０１０９】次に、上記構成を有するクライアントの動
作について図５に示すフロー図を用いて説明する。
【０１１０】図５は、本発明の実施の形態２に係るクラ
イアントの動作の例を示すフロー図である。
【０１１１】ＳＴ３０１では、リクエスト生成部２０２
が、ＰＬＡＹコマンドをレスポンス受信部１０３から出
力されたセッションＩＤと共にサーバー１１０に送信す
る。
【０１１２】ＳＴ３０２では、送信方法判定部２０１
が、リクエストを送信する際に用いる下位プロトコル
が、ＴＣＰかＵＤＰかを判断し、下位プロトコルがＴＣ
Ｐである場合、ＳＴ３０４に進む。
【０１１３】また、下位プロトコルがＵＤＰである場
合、ＳＴ３０７に進む。
【０１１４】ＳＴ３０３では、リクエスト生成部２０２
が、メディアデータの送信を要求したすべてのリクエス
トに対してレスポンス受信部１０３からメディアデータ
が伝送可能であることを通知された場合、ＳＴ３０４に
進む。
【０１１５】ＳＴ３０４では、リクエスト生成部２０２
が、ＰＬＡＹコマンドをレスポンス受信部１０３から出
力されたセッションＩＤと共にサーバー１１０に送信す
る。
【０１１６】ＳＴ３０５では、レスポンス受信部１０３
が、サーバー１１０に送信したＰＬＡＹコマンドに対し
てレスポンス受信部１０３からメディアデータが伝送開
始することを通知された場合、ＳＴ３０６に進む。
【０１１７】ＳＴ３０６では、メディア受信部１０４が
サーバー１１０から送信されたメディアデータを受信す
る。
【０１１８】ＳＴ３０７では、リクエスト生成部２０２
が、ＰＬＡＹコマンドをレスポンス受信部１０３から出
力されたセッションＩＤと共にサーバー１１０に送信す
る。
【０１１９】ＳＴ３０８では、レスポンス受信部１０３
が、サーバー１１０に送信したＳＴＵＰコマンド及びＰ
ＬＡＹコマンドに対してレスポンス受信部１０３からメ
ディアデータが伝送開始することを通知された場合、Ｓ
Ｔ３０９に進む。
【０１２０】ＳＴ３０９では、メディア受信部１０４が
サーバー１１０から送信されたメディアデータを受信す
る。
【０１２１】次に、上記構成を有するサーバー及びクラ
イアントにおける、セッション開設及び再生開始の手順
の一例を、シーケンス図を用いて説明する。図６は、本
発明の実施の形態２に係るセッション開設及び再生開始
の手順を説明するためのシーケンス図である。
【０１２２】図６において、クライアント２００におい
て、リクエスト生成部１０２は、第１番目のメディア
（ＶＩＤＥＯ１）のＳＥＴＵＰコマンドをサーバー１１
０に送信する。
【０１２３】サーバー１１０において、セッションＩＤ
割当部１１２は、セッションＩＤ（１２３４５６７８）
を生成し、このセッションＩＤとＶＩＤＥＯ１のＳＥＴ
ＵＰコマンドに対するＡＣＫコマンドとをクライアント
２００に送信する。
【０１２４】次に、クライアント２００において、リク
エスト生成部１０２は、ＶＩＤＥＯ２のＳＥＴＵＰコマ
ンドとサーバー１１０から送信されたセッションＩＤ
（１２３４５６７８）とをサーバー１１０に送信する。
【０１２５】次に、クライアント２００において、リク
エスト生成部１０２は、ＡＵＤＩＯ１のＳＥＴＵＰコマ
ンドと第２メディアと同一のセッションＩＤ（１２３４
５６７８）とをサーバー１１０に送信する。その後、ク
ライアント２００は、ＰＬＡＹコマンドをサーバー１１
０に送信する。
【０１２６】サーバー１１０において、クライアント２
００からＶＩＤＥＯ２のＳＥＴＵＰコマンドを受信し、
ＶＩＤＥＯ２のデータを送信準備が整った後に、レスポ
ンス送信部１１３は、ＶＩＤＥＯ２のＳＥＴＵＰコマン
ドに対するＡＣＫコマンドをクライアント２００に送信
する。
【０１２７】また、ＡＵＤＩＯ１のＳＥＴＵＰコマンド
と共に送信されたセッションＩＤに対しても同様にＡＣ
Ｋコマンドをクライアント２００に送信する。
【０１２８】サーバー１１０は、クライアント２００か
らＰＬＹＡコマンドを受信すると、ＰＬＡＹに対応する
ＡＣＫコマンドをクライアント２００に送信し、その
後、マルチメディアデータの送信を開始する。サーバー
１１０は、マルチメディアデータを全て送信し終えるか
クライアント２００から停止要求がなされるまでマルチ
メディアデータをクライアント２００に送信し続ける。
【０１２９】クライアントは、要求の確実な到着及び送
信順序と到着順序が同じであることを保証するプロトコ
ルを用いる場合には、送信準備の要求と送信の要求を連
続して送信することにより、サーバーは、同一セッショ
ンの全ての送信準備の要求を受信した後に、送信開始の
要求を受信することができる。
【０１３０】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【０１３１】なお、本実施の形態では、下位プロトコル
として、ＴＣＰとＵＤＰを用いて説明しているが、これ
に限らず、ＴＣＰの代わりにリクエストの確実な到着及
び送信順序と到着順序が同じであることを保証するプロ
トコル、ＵＤＰの代わりにリクエストの確実な到着及び
送信順序と到着順序が同じであることを保証しないプロ
トコルを用いることができる。
【０１３２】（実施の形態３）図７は、本発明の実施の
形態３に係るサーバー及びクライアントの構成を示すブ
ロック図である。但し、図１と同一の構成となるものに
ついては、図１と同一番号を付し、詳しい説明を省略す
る。
【０１３３】本発明の実施の形態３のサーバー及びクラ
イアントは、送信方法判定部３０１と、リクエスト生成
部３０２とを具備し、通信に用いる下位プロトコルがリ
クエストの確実な到着及び送信順序と到着順序が同じで
あることを保証するか否かを判断して、この順番が保証
される場合、メディアデータを要求するリクエストとメ
ディアデータの送信を要求するリクエストを連続して送
信する点が実施の形態１のサーバー及びクライアントと
異なる。
【０１３４】以下、ＴＣＰをリクエストの確実な到着及
び送信順序と到着順序が同じであることを保証するプロ
トコル、ＵＤＰをリクエストの確実な到着及び送信順序
と到着順序が同じであることを保証しないプロトコルの
例として説明する。
【０１３５】図７において送信方法判定部３０１は、プ
ロトコル情報に基づいてリクエストを送信する際に用い
る下位プロトコルが、ＴＣＰであるかＵＤＰであるかを
判断して、判断結果をリクエスト生成部３０２に出力す
る。
【０１３６】レスポンス受信部１０３は、サーバー１１
０からセッションＩＤを受信してリクエスト生成部３０
２に出力する。
【０１３７】また、レスポンス受信部１０３は、サーバ
ー１１０からＡＣＫコマンドを受信した場合、メディア
データが送信可能であることをリクエスト生成部３０２
に通知する。
【０１３８】リクエスト生成部３０２は、メディアの再
生準備をサーバー１１０に要求するＳＥＴＵＰコマンド
をサーバー１１０に送信する。
【０１３９】そして、リクエスト生成部３０２は、送信
方法判定部３０１における判定の結果、下位プロトコル
がＵＤＰである場合、レスポンス受信部１０３からメデ
ィアデータが伝送可能であることを通知されると、ＰＬ
ＡＹコマンドをレスポンス受信部１０３から出力された
セッションＩＤと共にサーバー１１０に送信する。
【０１４０】また、リクエスト生成部３０２は、送信方
法判定部３０１における判定の結果、下位プロトコルが
ＴＣＰである場合、レスポンス受信部１０３から出力さ
れるメディアデータが伝送可能であることの通知に関係
なく、メディアの再生準備をサーバー１１０に要求する
ＳＥＴＵＰコマンドを出力した後に、ＰＬＡＹコマンド
をレスポンス受信部１０３から出力されたセッションＩ
Ｄと共にサーバー１１０に送信する。
【０１４１】次に、上記構成を有するサーバー及びクラ
イアントにおける、セッション開設及び再生開始の手順
の一例を、シーケンス図を用いて説明する。図８は、本
発明の実施の形態３に係るセッション開設及び再生開始
の手順を説明するためのシーケンス図である。
【０１４２】最初にクライアント３００において、要求
セッションＩＤ生成部１０１は、セッションＩＤ（１２
３４５６７８）を生成し、リクエスト生成部３０２は、
このセッションＩＤをＶＩＤＥＯ１のＳＥＴＵＰコマン
ドと共にサーバー１１０に送信する。
【０１４３】次に、クライアント３００において、リク
エスト生成部３０２は、ＶＩＤＥＯ２のＳＥＴＵＰコマ
ンドと第１番目のメディアと同一のセッションＩＤ（１
２３４５６７８）をサーバー１１０に送信する。
【０１４４】次に、クライアント３００において、リク
エスト生成部３０２は、ＡＵＤＩＯ１のＳＥＴＵＰコマ
ンドと第１番目のメディアと同一のセッションＩＤ（１
２３４５６７８）をサーバー１１０に送信する。
【０１４５】次に、クライアント３００において、リク
エスト生成部３０２は、ＰＬＡＹコマンドをサーバー１
１０に送信する。
【０１４６】サーバー１１０において、セッションＩＤ
割当部１１２は、受信したセッションＩＤ（１２３４５
６７８）が使用可能か否か判断し、受信したセッション
ＩＤ（１２３４５６７８）が使用可能である場合、レス
ポンス送信部１１３は、ＶＩＤＥＯ１のＳＥＴＵＰコマ
ンドに対するＡＣＫコマンドをクライアント３００に送
信する。
【０１４７】サーバー１１０において、レスポンス送信
部１１３は、ＶＩＤＥＯ２のＳＥＴＵＰコマンドに対す
るＡＣＫコマンドをクライアント３００に送信する。ま
た、レスポンス送信部１１３は、ＡＵＤＩＯ１のＳＥＴ
ＵＰコマンドに対しても同様にＡＣＫコマンドをクライ
アント３００に送信する。
【０１４８】サーバー１１０は、クライアント２００か
ら要求されたマルチメディアデータの送信準備が整った
後、ＰＬＡＹに対応するＡＣＫコマンドをクライアント
３００に送信し、その後、マルチメディアデータの送信
を開始する。サーバー１１０は、マルチメディアデータ
を全て送信し終えるかクライアント３００から停止要求
がなされるまでマルチメディアデータをクライアント３
００に送信し続ける。
【０１４９】このように、サーバーは、クライアントを
区別する情報を用いて複数のリクエストが同じクライア
ントから送信されたか否か判断して、同じクライアント
から送信された複数のリクエストに対して同一のセッシ
ョンを開設することにより、クライアントは、同一のセ
ッションのリクエストを連続してサーバーに送信するこ
とができる。
【０１５０】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【０１５１】さらに、サーバーは、クライアントを区別
する情報を用いて複数のリクエストが同じクライアント
から送信されたか否か判断して、同じクライアントから
送信された複数のリクエストに対して同一のセッション
を開設することにより、クライアントは、要求の確実な
到着及び送信順序と到着順序が同じであることを保証す
るプロトコルを用いる場合に、送信準備の要求と送信の
要求を連続して送信することができる。
【０１５２】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【０１５３】なお、本実施の形態では、下位プロトコル
として、ＴＣＰとＵＤＰを用いて説明しているが、これ
に限らず、ＴＣＰの代わりにリクエストの確実な到着及
び送信順序と到着順序が同じであることを保証するプロ
トコル、ＵＤＰの代わりにリクエストの確実な到着及び
送信順序と到着順序が同じであることを保証しないプロ
トコルを用いることができる。
【０１５４】（実施の形態４）図９は、本発明の実施の
形態４に係るサーバー、ゲートウェイ及びクライアント
の構成を示すブロック図である。但し、図１または図４
と同一の構成となるものについては、図１または図４と
同一番号を付し、詳しい説明を省略する。
【０１５５】本発明の実施の形態４では、ゲートウェイ
を介して、通信手順の異なるプロトコル間での通信を可
能とする点が実施の形態１と異なる。
【０１５６】図９において、ゲートウェイ４００は、リ
クエスト受信部４０１と、リクエスト送信部４０２と、
バッファ４０３と、レスポンス受信部４０４と、レスポ
ンス送信部４０５と、メディア中継部４０６とから主に
構成される。
【０１５７】リクエスト生成部２０２は、要求セッショ
ンＩＤ生成部１０１から出力されたセッションＩＤとメ
ディアの再生準備をサーバー１１０に要求するＳＥＴＵ
Ｐコマンドとをゲートウェイ４００に送信する。
【０１５８】そして、リクエスト生成部２０２は、送信
方法判定部２０１における判定の結果、下位プロトコル
がリクエストの確実な到着及び送信順序と到着順序が同
じであることを保証しないプロトコルである場合、レス
ポンス受信部１０３からメディアデータが伝送可能であ
ることを通知されると、ＰＬＡＹコマンドをレスポンス
受信部１０３から出力されたセッションＩＤと共にゲー
トウェイ４００に送信する。
【０１５９】また、リクエスト生成部２０２は、送信方
法判定部２０１における判定の結果、下位プロトコルが
リクエストの確実な到着及び送信順序と到着順序が同じ
であることを保証するプロトコルである場合、レスポン
ス受信部１０３から出力されるメディアデータが伝送可
能であることを通知に関係なく、メディアの再生準備を
サーバー１１０に要求するＳＥＴＵＰコマンドを出力し
た後に、ＰＬＡＹコマンドをレスポンス受信部１０３か
ら出力されたセッションＩＤと共にゲートウェイ４００
に送信する。
【０１６０】リクエスト受信部４０１は、クライアント
２００から送信されたリクエストを受信してリクエスト
送信部４０２に出力する。
【０１６１】リクエスト送信部４０２は、リクエスト受
信部４０１から出力されたリクエストがマルチメディア
データを要求するＳＥＴＵＰコマンドである場合、リク
エストをサーバー１１０に送信する。
【０１６２】また、リクエスト送信部４０２は、リクエ
スト受信部４０１から出力されたリクエストがＰＬＡＹ
コマンドである場合、リクエストをバッファ４０３に出
力し、同じセッションＩＤを使用するＳＥＴＵＰコマン
ドに対するＡＣＫコマンドを受信した通知をレスポンス
受信部４０４から受け取った後に、バッファ４０３から
ＰＬＡＹコマンドを含むリクエストを取り出してサーバ
ー１１０に送信する。
【０１６３】バッファ４０３は、リクエスト送信部４０
２から出力されたリクエストを記憶する。
【０１６４】レスポンス送信部１１３は、メディア送信
部１１４からメディア送信の準備が出来たことの通知を
受けると、セッションＩＤ割当部１１２から出力された
セッションＩＤとＡＣＫコマンドとをクライアント２０
０に送信する。
【０１６５】レスポンス受信部４０４は、レスポンス送
信部１１３から出力されたＡＣＫコマンドを受信してレ
スポンス送信部４０５に出力する。また、レスポンス受
信部４０４は、ＡＣＫコマンドを受信したことをリクエ
スト送信部４０２に通知する。
【０１６６】レスポンス送信部４０５は、レスポンス受
信部４０４から出力されたＡＣＫコマンドをクライアン
ト２００に送信する。
【０１６７】メディア送信部１１４は、リクエスト受信
部１１１から出力された指示に従い、メディア送信の準
備を行う。そして、メディア送信部１１４は、メディア
送信の準備ができた後に、レスポンス送信部１１３にメ
ディア送信の準備が出来たことを通知し、メディアデー
タをゲートウェイ４００に送信する。
【０１６８】メディア中継部４０６は、サーバー１１０
から送信されたメディアデータをクライアント２００に
送信する。
【０１６９】次に、上記構成を有するサーバー、ゲート
ウェイ及びクライアントにおける、セッション開設及び
再生開始の手順の一例を、シーケンス図を用いて説明す
る。図１０は、本発明の実施の形態４に係るセッション
開設及び再生開始の手順を説明するためのシーケンス図
である。
【０１７０】図１０において、クライアント２００にお
いて、リクエスト生成部２０２は、ＶＩＤＥＯ１のＳＥ
ＴＵＰコマンドをゲートウェイ４００に送信し、ゲート
ウェイ４００は、このＳＥＴＵＰコマンドをサーバー１
１０に送信する。
【０１７１】サーバー１１０において、セッションＩＤ
割当部１１２は、セッションＩＤ（１２３４５６７８）
を生成し、このセッションＩＤとＶＩＤＥＯ１のＳＥＴ
ＵＰコマンドに対するＡＣＫコマンドをゲートウェイ４
００に送信し、ゲートウェイ４００は、このセッション
ＩＤとＡＣＫコマンドとをクライアント２００に送信す
る。
【０１７２】次に、クライアント２００において、レス
ポンス受信部１０３は、セッションＩＤとＡＣＫコマン
ドとを受け取ると、リクエスト生成部２０２は、ＶＩＤ
ＥＯ２のＳＥＴＵＰコマンドとサーバー１１０から送信
されたセッションＩＤ（１２３４５６７８）をゲートウ
ェイ４００に送信する。
【０１７３】次に、クライアント２００において、リク
エスト生成部２０２は、ＡＵＤＩＯ１のＳＥＴＵＰコマ
ンドと第１番目のメディアと同一のセッションＩＤ（１
２３４５６７８）をゲートウェイ４００に送信する。
【０１７４】そして、クライアント２００は、ＰＬＡＹ
コマンドをゲートウェイ４００に送信する。
【０１７５】ゲートウェイ４００は、クライアント２０
０から送信されたＶＩＤＥＯ２のＳＥＴＵＰコマンド、
ＡＵＤＩＯ１のＳＥＴＵＰコマンド、及びＰＬＡＹのう
ち、ＶＩＤＥＯ２のＳＥＴＵＰコマンド及びＡＵＤＩＯ
１のＳＥＴＵＰコマンドをセッションＩＤと共にサーバ
ー１１０に送信し、ＰＬＡＹをバッファ４０３に記憶す
る。
【０１７６】サーバー１１０において、レスポンス送信
部１１３は、ＶＩＤＥＯ２のＳＥＴＵＰコマンドに対す
るＡＣＫコマンドをクライアント２００に送信する。ま
た、ＡＵＤＩＯ１のＳＥＴＵＰコマンドと共に送信され
たセッションＩＤに対しても同様にＡＣＫコマンドをク
ライアント２００に送信する。
【０１７７】ゲートウェイ４００は、サーバー１１０か
らＶＩＤＥＯ２のＳＥＴＵＰコマンド及びＡＵＤＩＯ１
のＳＥＴＵＰコマンドに対するＡＣＫコマンドを受信し
て、同一のセッションＩＤで要求した全てのＥＴＵＰ要
求に対するＡＣＫコマンドを受信した後にバッファ４０
３からＰＬＡＹリクエストを取り出してサーバー１１０
に送信する。
【０１７８】また、ゲートウェイ４００は、受信したＶ
ＩＤＥＯ２のＳＥＴＵＰコマンド及びＡＵＤＩＯ１のＳ
ＥＴＵＰコマンドに対するＡＣＫコマンドをクライアン
ト２００に送信する。
【０１７９】サーバー１１０は、クライアント２００か
ら要求されたマルチメディアデータの送信準備が整った
後、受信したＰＬＡＹに対応するＡＣＫコマンドをゲー
トウェイ４００に送信し、その後にマルチメディアデー
タをゲートウェイ４００に送信し始める。サーバー１１
０は、マルチメディアデータを全て送信し終えるかクラ
イアント２００からゲートウェイ４００を通して停止要
求がなされるまでマルチメディアデータを、ゲートウェ
イ４００を通してクライアント２００に送信し続ける。
【０１８０】クライアントは、要求の確実な到着及び送
信順序と到着順序が同じであることを保証するプロトコ
ルを用いる場合には、送信準備の要求と送信の要求を連
続して送信することにより、サーバーは、同一セッショ
ンの全ての送信準備の要求を受信した後に、送信開始の
要求を受信することができる。
【０１８１】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【０１８２】また、本実施の形態のゲートウェイによれ
ば、送信準備の要求に対する返答をサーバーから受信し
た後に、送信をサーバーに要求することにより、クライ
アントは、送信準備の要求と送信の要求を連続して送信
することができる。
【０１８３】従って、本発明の通信開始方法と異なる通
信開始方法を用いる通信装置との通信を行うことがで
き、かつクライアントとサーバーの間にセッションを確
立する時間を短縮することができる。
【０１８４】（実施の形態５）図１１は、本発明の実施
の形態５に係るサーバー、ゲートウェイ及びクライアン
トの構成を示すブロック図である。但し、図１または図
７と同一の構成となるものについては、図１または図７
と同一番号を付し、詳しい説明を省略する。
【０１８５】実施の形態５のゲートウェイは、セッショ
ンＩＤ変換部５０２を具備し、クライアントとの通信に
用いるセッションＩＤとサーバーとの通信に用いるセッ
ションＩＤを対応つけて記憶し、セッションＩＤを変換
する点が実施の形態４と異なる。
【０１８６】図１１において、ゲートウェイ５００は、
リクエスト受信部５０１と、セッションＩＤ変換部５０
２と、リクエスト送信部５０３と、バッファ５０４と、
レスポンス受信部５０５と、レスポンス送信部５０６
と、メディア中継部５０７とから主に構成される。
【０１８７】リクエスト生成部３０２は、メディアの再
生準備をサーバー１１０に要求するＳＥＴＵＰコマンド
を要求セッションＩＤ生成部１０１から出力されたセッ
ションＩＤと共にゲートウェイ５００に送信する。
【０１８８】そして、リクエスト生成部３０２は、送信
方法判定部３０１における判定の結果、下位プロトコル
がリクエストの確実な到着及び送信順序と到着順序が同
じであることを保証しないプロトコルである場合、レス
ポンス受信部１０３からメディアデータが伝送可能であ
ることを通知されると、ＰＬＡＹコマンドをレスポンス
受信部１０３から出力されたセッションＩＤと共にゲー
トウェイ５００に送信する。
【０１８９】また、リクエスト生成部３０２は、送信方
法判定部３０１における判定の結果、下位プロトコルが
リクエストの確実な到着及び送信順序と到着順序が同じ
であることを保証するプロトコルである場合、レスポン
ス受信部１０３から出力されるメディアデータが伝送可
能であることを通知に関係なく、メディアの再生準備を
サーバー１１０に要求するＳＥＴＵＰコマンドを出力し
た後に、ＰＬＡＹコマンドをレスポンス受信部１０３か
ら出力されたセッションＩＤと共にゲートウェイ５００
に送信する。
【０１９０】リクエスト受信部５０１は、クライアント
３００から送信されたリクエストを受信してリクエスト
送信部５０３に出力し、クライアント３００から送信さ
れたセッションＩＤをセッションＩＤ変換部５０２に出
力する。
【０１９１】セッションＩＤ変換部５０２は、リクエス
ト受信部５０１から出力されたセッションＩＤをサーバ
ー１１０から送信されたセッションＩＤに変換してリク
エスト送信部５０３に出力する。変換するセッションＩ
Ｄが設定されていない場合、セッションＩＤ変換部５０
２は、セッションＩＤが設定されていないことをリクエ
スト送信部５０３に出力する。
【０１９２】また、セッションＩＤ変換部５０２は、レ
スポンス受信部５０５から出力されたセッションＩＤを
クライアント３００から送信されたセッションＩＤに変
換してレスポンス送信部５０６に出力する。
【０１９３】リクエスト送信部５０３は、リクエスト受
信部５０１から出力されたリクエストに対して、ゲート
ウェイ５００とサーバー１１０との間の通信のセッショ
ンＩＤが設定されていない場合、このリクエストとセッ
ションＩＤの要求とをサーバー１１０に送信する。
【０１９４】また、リクエスト送信部５０３は、リクエ
スト受信部５０１から出力されたリクエストに対する返
答を受信していない場合、同一セッションの他のリクエ
ストをバッファ５０４に出力する。
【０１９５】そして、リクエスト送信部５０３は、リク
エストに対する返答を受信した後に、他のリクエストを
一つバッファ５０４から取り出してセッションＩＤ変換
部５０２から出力されたセッションＩＤと共にサーバー
１１０に送信する。この時、ゲートウェイ５００は、受
信した順番と同じ順番でリクエストをサーバー１１０に
送信する。
【０１９６】バッファ５０４は、リクエスト送信部５０
３から出力されたリクエストを記憶する。
【０１９７】レスポンス送信部１１３は、セッションＩ
Ｄ割当部１１２から出力されたセッションＩＤをゲート
ウェイ５００に送信する。また、レスポンス送信部１１
３は、リクエストの返答としてＡＣＫコマンドをゲート
ウェイ５００に送信する。
【０１９８】レスポンス受信部５０５は、レスポンス送
信部１１３から出力されたＡＣＫコマンドを受信してレ
スポンス送信部５０６に出力し、レスポンス送信部１１
３から出力されたセッションＩＤをセッションＩＤ変換
部５０２に出力する。また、レスポンス受信部５０５
は、ＡＣＫコマンドを受信したことをリクエスト送信部
５０３に通知する。
【０１９９】レスポンス送信部５０６は、レスポンス受
信部５０５から出力されたＡＣＫコマンドをセッション
ＩＤ変換部５０２から出力されたセッションＩＤと共に
クライアント３００に送信する。
【０２００】メディア送信部１１４は、リクエスト受信
部１１１から出力された指示に従い、メディア送信の準
備を行う。メディア送信部１１４は、メディア送信の準
備ができた後に、レスポンス送信部１１３にメディア送
信の準備が出来たことを通知し、メディアデータをゲー
トウェイ５００に送信する。
【０２０１】メディア中継部５０７は、サーバー１１０
から送信されたメディアデータをクライアント３００に
送信する。
【０２０２】次に、上記構成を有するサーバー及びクラ
イアントにおける、セッションＩＤ変換について説明す
る。
【０２０３】ゲートウェイは、複数のクライアントまた
は複数のサーバーの通信の中継を行うので、複数のクラ
イアント及び複数のサーバーを識別する必要がある。
【０２０４】図１２は、本実施の形態に係るクライアン
ト、ゲートウェイ、及びサーバーの構成を示す図であ
る。
【０２０５】図１２において、ゲートウェイ６０１は、
クライアント６１１、クライアント６１２及びクライア
ント６１３と同一セグメントのネットワークで接続して
いる。また、ゲートウェイ６０１は、サーバー６２１及
びサーバー６２２と同一セグメントのネットワークで接
続している。
【０２０６】クライアント６１１、クライアント６１２
及びクライアント６１３は、ゲートウェイ６０１を介し
てプロトコル変換を行いサーバー６２１及びサーバー６
２２と通信を行う。
【０２０７】図１３は、上記構成を有するゲートウェイ
におけるセッションＩＤ変換テーブルの一例を示す図で
ある。
【０２０８】図１３において、クライアント情報とクラ
イアントとゲートウェイ間で用いられるセッションＩＤ
の一組と、サーバー情報とサーバーとゲートウェイ間で
用いられるセッションＩＤの一組がそれぞれ対応してい
る。
【０２０９】ここで、クライアント情報は、複数のクラ
イアントを識別する情報であり、例としてＩＰアドレス
を用いている。同様に、サーバー情報は、複数のサーバ
ーを識別する情報であり、例としてＩＰアドレスを用い
ている。
【０２１０】ここでは、クライアント６１１のＩＰアド
レスを１９２．１６８．０．１０１、クライアント６１
２のＩＰアドレスを１９２．１６８．０．１０２、クラ
イアント３のＩＰアドレスを１９２．１６８．０．１０
３とし、サーバー６２１のＩＰアドレスを１９２．２０
０．０．１、サーバー６２２のＩＰアドレスを１９２．
２００．０．２とする。
【０２１１】クライアント６１１、クライアント６１
２、及びクライアント６１３は、同一セグメントのネッ
トワークでゲートウェイ６０１と接続されている。ま
た、サーバー６２１及びサーバー６２２は、クライアン
ト６１１、クライアント６２１、及びクライアント６１
３と異なるセグメントのネットワークでゲートウェイ６
０１と接続されている。
【０２１２】例えば、クライアント６１１がセッション
ＩＤ１２３４５６７８とリクエストをサーバー６１１に
送信する場合、ゲートウェイ６０１は、このセッション
ＩＤとリクエストをサーバー６１１に送信する。
【０２１３】サーバー６１１は、ゲートウェイ６０１か
ら送信されたセッションＩＤ１２３４５６７８が使用可
能であると判断し、このセッションＩＤとＡＣＫ信号を
ゲートウェイ６０１に送信する。
【０２１４】ゲートウェイ６０１は、サーバー６１１か
ら送信されたセッションＩＤ１２３４５６７８とクライ
アント６１１から送信されたセッションＩＤ１２３４５
６７８を対応つけて記憶し、以降クライアント６１１の
セッションＩＤ１２３４５６７８とサーバー６１１のセ
ッションＩＤ１２３４５６７８との通信を確保する。
【０２１５】次に、クライアント６１２がセッションＩ
Ｄ１２３４５６７８とリクエストをサーバー６２１に送
信する場合、ゲートウェイ６０１は、このセッションＩ
Ｄがすでに使用されているので新たなセッションＩＤの
要求とリクエストをサーバー６２１に送信する。
【０２１６】サーバー６２１は、新たなセッションＩＤ
００００１１１１とＡＣＫ信号をゲートウェイ６０１に
送信する。
【０２１７】ゲートウェイ６０１は、サーバー６２１か
ら送信されたセッションＩＤ００００１１１１とクライ
アント６１１から送信されたセッションＩＤ１２３４５
６７８を対応つけて記憶し、以降クライアント６１１の
セッションＩＤ１２３４５６７８とサーバー６２１のセ
ッションＩＤ００００１１１１との通信を確保する。
【０２１８】同様に、複数のサーバーで同じセッション
ＩＤを生成した場合でも、サーバーを識別する情報を用
いて通信を区別することができる。
【０２１９】例えば、クライアント６１３とサーバー６
２２の通信においてサーバー６２２がセッションＩＤ０
０００１１１１を生成してゲートウェイ６０１に送信し
た場合、ゲートウェイ６０１は、同じセッションＩＤを
生成したサーバー６２１とサーバー６２２とを、ＩＰア
ドレスを用いて識別し、それぞれの通信相手であるサー
バー６２１とサーバー６２２を区別して信号を送信す
る。
【０２２０】次に、上記構成を有するサーバー、ゲート
ウェイ及びクライアントにおける、セッション開設及び
再生開始の手順の一例を、シーケンス図を用いて説明す
る。図１４は、本発明の実施の形態５に係るセッション
開設及び再生開始の手順を説明するためのシーケンス図
である。
【０２２１】図１４において、クライアント３００にお
いて、リクエスト生成部３０２は、第１番目のメディア
（ＶＩＤＥＯ１）のＳＥＴＵＰコマンドをゲートウェイ
５００に送信し、ゲートウェイ５００は、このＳＥＴＵ
Ｐコマンドをサーバー１１０に送信する。
【０２２２】次に、クライアント３００において、リク
エスト生成部３０２は、ＶＩＤＥＯ２のＳＥＴＵＰコマ
ンドをゲートウェイ５００に送信する。
【０２２３】次に、クライアント３００において、リク
エスト生成部３０２は、ＡＵＤＩＯ１のＳＥＴＵＰコマ
ンドをゲートウェイ５００に送信する。
【０２２４】ゲートウェイ５００は、クライアント３０
０から送信されたＶＩＤＥＯ１のＳＥＴＵＰコマンドを
サーバー１１０に出力し、ＶＩＤＥＯ２のＳＥＴＵＰコ
マンド及びＡＵＤＩＯ１のＳＥＴＵＰコマンドをバッフ
ァ５０４に記憶する。
【０２２５】サーバー１１０において、ＶＩＤＥＯ１の
ＳＥＴＵＰコマンドに対応するデータの送信準備できた
後、セッションＩＤ割当部１１２は、セッションＩＤ
（１２３４５６７８）を生成し、このセッションＩＤと
ＶＩＤＥＯ１のＳＥＴＵＰコマンドに対するＡＣＫコマ
ンドをゲートウェイ５００に送信する。
【０２２６】ゲートウェイ５００は、ＶＩＤＥＯ１のＳ
ＥＴＵＰコマンドに対するＡＣＫコマンドを受信した後
に、ＶＩＤＥＯ２のＳＥＴＵＰコマンドをサーバー１１
０に送信し、サーバー１１０から出力されたセッション
ＩＤ（００００１１１１）をセッションＩＤ変換部５０
２において変換したセッションＩＤ（１２３４５６７
８）とＡＣＫコマンドとをクライアント３００に送信す
る。
【０２２７】サーバー１１０において、ＶＩＤＥＯ２の
ＳＥＴＵＰコマンドに対応するデータの送信準備できた
後、レスポンス送信部１１３は、ＶＩＤＥＯ２のＳＥＴ
ＵＰコマンドに対するＡＣＫコマンドをゲートウェイ５
００に送信する。
【０２２８】ゲートウェイ５００は、ＶＩＤＥＯ２のＳ
ＥＴＵＰコマンドに対するＡＣＫコマンドを受信した後
に、ＡＵＤＩＯ１のＳＥＴＵＰコマンドをサーバー１１
０に送信し、サーバー１１０から出力されたセッション
ＩＤ（００００１１１１）をセッションＩＤ変換部５０
２において変換したセッションＩＤ（１２３４５６７
８）とＡＣＫコマンドとをクライアント３００に送信す
る。
【０２２９】サーバー１１０において、ＡＵＤＩＯ１の
ＳＥＴＵＰコマンドに対応するデータの送信準備できた
後、レスポンス送信部１１３は、ＡＵＤＩＯ１のＳＥＴ
ＵＰコマンドに対するＡＣＫコマンドをゲートウェイ５
００に送信する。
【０２３０】ゲートウェイ５００は、ＡＵＤＩＯ１のＳ
ＥＴＵＰコマンドに対するＡＣＫコマンドを受信した後
に、サーバー１１０から出力されたセッションＩＤ（０
０００１１１１）をセッションＩＤ変換部５０２におい
て変換したセッションＩＤ（１２３４５６７８）とＡＣ
Ｋコマンドとをクライアント３００に送信する。
【０２３１】クライアント３００は、送信したＳＥＴＵ
ＰコマンドにＡＣＫコマンドを全て受信した後、ＰＬＡ
ＹコマンドとセッションＩＤ（１２３４５６７８）とを
ゲートウェイ５００に送信する。
【０２３２】ゲートウェイ５００は、セッションＩＤ
（１２３４５６７８）をセッションＩＤ変換部５０２に
おいて変換したセッションＩＤ（００００１１１１）と
クライアント３００から送信されたＰＬＡＹとをサーバ
ー１１０に送信する。
【０２３３】サーバー１１０は、受信したＰＬＡＹに対
応するＡＣＫコマンドをゲートウェイ５００に送信し、
その後にマルチメディアデータをゲートウェイ５００に
送信し始める。サーバー１１０は、マルチメディアデー
タを全て送信し終えるかクライアント３００からゲート
ウェイ５００を通して停止要求がなされるまでマルチメ
ディアデータを、ゲートウェイ５００を通してクライア
ント３００に送信し続ける。
【０２３４】このように、サーバーは、クライアントを
区別する情報を用いて複数のリクエストが同じクライア
ントから送信されたか否か判断して、同じクライアント
から送信された複数のリクエストに対して同一のセッシ
ョンを開設することにより、クライアントは、同一のセ
ッションのリクエストを連続してサーバーに送信するこ
とができる。
【０２３５】従って、サーバーからの返答を待つ時間を
減少させることができ、クライアントとサーバーの間に
セッションを確立する時間を短縮することができる。
【０２３６】また、本実施の形態のゲートウェイによれ
ば、クライアントとの通信に用いるセッションＩＤとサ
ーバーとの通信に用いるセッションＩＤを対応つけて記
憶し、セッションＩＤを変換することにより、本発明の
通信開始方法と異なる通信開始方法を用いる通信装置と
の通信を行うことができ、かつクライアントとサーバー
の間にセッションを確立する時間を短縮することができ
る。
【０２３７】なお、本発明のサーバー、ゲートウェイ及
びクライアントでは、再生するメディアデータの種類及
び数は特に限定されない。
【０２３８】また、クライアントが生成するセッション
ＩＤは、クライアント固有に設定された情報に基づいて
生成することもできる。例えば、クライアントのＩＰア
ドレスやＭＡＣ（Media Access Control）アドレス等
をセッションＩＤとして生成することもできる。また、
携帯電話をクライアントとした場合、携帯電話の番号を
セッションＩＤとして生成することもできる。
【０２３９】
【発明の効果】以上説明したように、本発明によれば、
クライアントは、同一のセッションのリクエストを連続
してサーバーに送信し、サーバーは、クライアントを区
別する情報を用いて複数のリクエストが同じクライアン
トから送信されか否かを判定し、複数のリクエストが同
じクライアントから送信された場合、前記複数のリクエ
ストに対して同一のセッションを開設することにより、
クライアントとサーバーの間にセッションを確立する時
間を短縮することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態１に係るサーバー及びクラ
イアントの構成を示すブロック図
【図２】上記実施の形態に係るセッション開設及び再生
開始の手順を説明するための第１のシーケンス図
【図３】上記実施の形態に係るセッション開設及び再生
開始の手順を説明するための第２のシーケンス図
【図４】本発明の実施の形態２に係るサーバー及びクラ
イアントの構成を示すブロック図
【図５】上記実施の形態に係るクライアントの動作の例
を示すフロー図
【図６】上記実施の形態に係るセッション開設及び再生
開始の手順を説明するためのシーケンス図
【図７】本発明の実施の形態３に係るサーバー及びクラ
イアントの構成を示すブロック図
【図８】上記実施の形態に係るセッション開設及び再生
開始の手順を説明するためのシーケンス図
【図９】本発明の実施の形態４に係るサーバー、ゲート
ウェイ及びクライアントの構成を示すブロック図
【図１０】上記実施の形態に係るセッション開設及び再
生開始の手順を説明するためのシーケンス図
【図１１】本発明の実施の形態５に係るサーバー、ゲー
トウェイ及びクライアントの構成を示すブロック図
【図１２】本実施の形態に係るクライアント、ゲートウ
ェイ、及びサーバーの構成を示す図
【図１３】上記構成を有するゲートウェイにおけるセッ
ションＩＤ変換テーブルの一例を示す図
【図１４】上記実施の形態に係るセッション開設及び再
生開始の手順を説明するためのシーケンス図
【図１５】ストリーミングアプリケーションの概念を示
した図
【図１６】ＲＴＳＰを用いたストリーミングのプロトコ
ル構成の一例を示す図
【図１７】従来のセッション開設及び再生開始の手順を
説明するためのシーケンス図
【図１８】従来のセッション開設及び再生開始の手順を
説明するためのシーケンス図
【符号の説明】 １０１ 要求セッションＩＤ生成部 １０２、２０２、３０２ リクエスト生成部 １０３、４０４、５０５ レスポンス受信部 １０４ メディア受信部 １０５ メディア再生部 １１１、４０１、５０１ リクエスト受信部 １１２ セッションＩＤ割当部 １１３、４０５、５０６ レスポンス送信部 １１４ メディア送信部 ２０１、３０１ 送信方法判定部 ４０２、５０３ リクエスト送信部 ４０３、５０４ バッファ ４０６、５０７ メディア中継部 ５０２ セッションＩＤ変換部
フロントページの続き (51)Int.Cl.7 識別記号 ＦＩ テーマコート゛(参考） // Ｈ０４Ｌ 12/56 Ｈ０４Ｌ 13/00 ３０７Ａ ５Ｋ０３４ (72)発明者 堀内 優希 大阪府門真市大字門真1006番地 松下電器 産業株式会社内 (72)発明者 浦 誠治 大阪府門真市大字門真1006番地 松下電器 産業株式会社内 Ｆターム(参考） 5B085 AA08 BC02 BG07 5B089 GA11 GA21 GA31 HB18 KA05 KB06 KC28 KC47 KG03 5C064 BA01 BB05 BC10 BC18 BD02 BD09 5C075 AB90 CA03 CD22 5K030 GA01 HA06 HB11 JA07 LA02 LB02 5K034 AA01 DD01 FF01 FF02 HH01 HH02 KK29 LL01 LL02

Claims (18)

    【特許請求の範囲】
  1. 【請求項１】 クライアント固有の情報に基づいて複数
    のリクエストが同一のクライアントから送信されたか否
    かを判定する第一判定手段と、前記複数のリクエストが
    同一のクライアントから送信された場合、前記複数のリ
    クエストに対して同一のセッションを開設するセッショ
    ン設定手段と、前記開設されたセッションで前記リクエ
    ストに対応するオブジェクトを前記クライアントに送信
    するメディア送信手段と、を具備することを特徴とする
    サーバー。
  2. 【請求項２】 セッション設定手段は、クライアントか
    ら送信されたセッションＩＤを用いてセッションを開設
    することを特徴とする請求項１に記載のサーバー。
  3. 【請求項３】 第一判定手段は、クライアントから送信
    されたセッションＩＤが使用可能であるか否か判定し、
    前記セッションＩＤが使用不可能である場合、使用可能
    なセッションＩＤを新たに生成し、セッション設定手段
    は、前記新たに生成したセッションＩＤを用いてセッシ
    ョンを開設することを特徴とする請求項２に記載のサー
    バー。
  4. 【請求項４】 同一のセッションで通信を行うリクエス
    トに対して、連続してリクエストを請求項１に記載のサ
    ーバーに送信する第一リクエスト送信手段と、前記リク
    エストに対応するオブジェクトを受信するメディア受信
    手段と、を具備することを特徴とするクライアント。
  5. 【請求項５】 第一リクエスト送信手段は、オブジェク
    トの送信準備を連続してサーバーに要求することを特徴
    とする請求項４に記載のクライアント。
  6. 【請求項６】 第一リクエスト送信手段は、オブジェク
    トの送信準備とオブジェクトの送信開始とを連続してサ
    ーバーに要求することを特徴とする請求項４または請求
    項５に記載のクライアント。
  7. 【請求項７】 セッションＩＤを生成するセッションＩ
    Ｄ生成手段を具備し、第一リクエスト送信手段は、リク
    エストと共に前記セッションＩＤをサーバーに送信する
    ことを特徴とする請求項４から請求項６のいずれかに記
    載のクライアント。
  8. 【請求項８】 セッションＩＤ生成手段は、クライアン
    ト固有の情報に基づいてセッションＩＤを生成すること
    を特徴とする請求項７に記載のクライアント。
  9. 【請求項９】 セッションＩＤ生成手段は、クライアン
    トに設定したインターネットプロトコルアドレスを用い
    てセッションＩＤを生成することを特徴とする請求項８
    に記載のクライアント。
  10. 【請求項１０】 セッションＩＤ生成手段は、クライア
    ントの物理アドレスを用いてセッションＩＤを生成する
    ことを特徴とする請求項８に記載のクライアント。
  11. 【請求項１１】 下位プロトコルが、送信するリクエス
    トの確実な到着及び送信順序と到着順序が同じであるこ
    とを保証するプロトコルであるか否かを判断する第二判
    定手段を具備し、第一リクエスト送信手段は、送信する
    リクエストの確実な到着及び送信順序と到着順序が同じ
    であることを保証しないプロトコルである場合、オブジ
    ェクトの送信準備の要求に対する返答を受信した後にオ
    ブジェクトの送信開始を要求することを特徴とする請求
    項４から請求項１０のいずれかに記載のクライアント。
  12. 【請求項１２】 同一のセッションで通信を行うリクエ
    ストに対して、クライアントから送信されたリクエスト
    を一時記憶する記憶手段と、オブジェクトの送信準備の
    要求に対する返答をサーバーから受信した後に、前記オ
    ブジェクトの送信を要求する第二リクエスト送信手段
    と、を具備することを特徴とするゲートウェイ。
  13. 【請求項１３】 サーバーとの通信に用いるセッション
    ＩＤとクライアントとの通信に用いるセッションＩＤと
    を関連つけて記憶し、サーバーとの通信に用いるセッシ
    ョンＩＤをクライアントとの通信に用いるセッションＩ
    Ｄに変換し、クライアントとの通信に用いるセッション
    ＩＤをサーバーとの通信に用いるセッションＩＤに変換
    する変換手段、を具備することを特徴とする請求項１２
    に記載のゲートウェイ。
  14. 【請求項１４】 クライアントは、複数のリクエストを
    連続してサーバーに送信し、前記サーバーは、クライア
    ント固有の情報に基づいて複数のリクエストが同一のク
    ライアントから送信されたか否かを判定し、前記複数の
    リクエストが同一のクライアントから送信された場合、
    前記複数のリクエストに対して同一のセッションを開設
    することを特徴とする通信開始方法。
  15. 【請求項１５】 クライアントは、複数のオブジェクト
    の送信準備を連続してサーバーに要求し、前記サーバー
    は、クライアント固有の情報に基づいて複数のリクエス
    トが同一のクライアントから送信されたか否かを判定
    し、前記複数のリクエストが同一のクライアントから送
    信された場合、前記複数のリクエストに対して同一のセ
    ッションを開設することを特徴とする通信開始方法。
  16. 【請求項１６】 クライアントは、オブジェクトの送信
    準備の要求と、前記オブジェクトの送信の要求とを連続
    してサーバーに送信し、前記サーバーは、クライアント
    固有の情報に基づいて複数のリクエストが同一のクライ
    アントから送信されたか否かを判定し、前記複数のリク
    エストが同一のクライアントから送信された場合、前記
    複数のリクエストに対して同一のセッションを開設する
    ことを特徴とする通信開始方法。
  17. 【請求項１７】 クライアントは、セッションＩＤを生
    成し、前記セッションＩＤとリクエストとを共にサーバ
    ーに送信し、前記サーバーは、前記セッションＩＤが使
    用可能である場合、前記セッションＩＤを用いてセッシ
    ョンを開設し、前記セッションＩＤが使用不可能である
    場合、使用可能なセッションＩＤを新たに生成して、前
    記新たに生成したセッションＩＤを用いてセッションを
    開設することを特徴とする請求項１４から請求項１６の
    いずれかに記載の通信開始方法。
  18. 【請求項１８】 下位プロトコルが、送信するリクエス
    トの確実な到着及び送信順序と到着順序が同じであるこ
    とを保証するプロトコルであるか否かを判断し、送信す
    るリクエストの確実な到着及び送信順序と到着順序が同
    じであることを保証しないプロトコルである場合、オブ
    ジェクトを要求するリクエストの返答を受信した後にオ
    ブジェクトの送信開始を要求することを特徴とする請求
    項１４から請求項１７のいずれかに記載の通信開始方
    法。
JP2000353439A 2000-11-20 2000-11-20 サーバー、クライアント、通信開始方法及び通信開始プログラム Expired - Fee Related JP4663100B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2000353439A JP4663100B2 (ja) 2000-11-20 2000-11-20 サーバー、クライアント、通信開始方法及び通信開始プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000353439A JP4663100B2 (ja) 2000-11-20 2000-11-20 サーバー、クライアント、通信開始方法及び通信開始プログラム

Publications (2)

Publication Number Publication Date
JP2002157175A true JP2002157175A (ja) 2002-05-31
JP4663100B2 JP4663100B2 (ja) 2011-03-30

Family

ID=18826204

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000353439A Expired - Fee Related JP4663100B2 (ja) 2000-11-20 2000-11-20 サーバー、クライアント、通信開始方法及び通信開始プログラム

Country Status (1)

Country Link
JP (1) JP4663100B2 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004098134A1 (ja) * 2002-09-13 2004-11-11 Matsushita Electric Industrial Co., Ltd. リアルタイム通信の適応制御方法
JP2005526294A (ja) * 2002-05-21 2005-09-02 ジェネラル・インスツルメント・コーポレーション 関連するストリーミングプロトコル群に対するセキュリティパラメータの統合
US7561518B2 (en) 2002-07-03 2009-07-14 Sony Corporation Data sending/receiving system and method, information providing apparatus and method, and data receiving apparatus and method
US7634570B2 (en) 2003-03-12 2009-12-15 Microsoft Corporation Managing state information across communication sessions between a client and a server via a stateless protocol
JP2011223414A (ja) * 2010-04-12 2011-11-04 Nippon Telegr & Teleph Corp <Ntt> 再送判定装置、再送判定方法、再送判定プログラム、及び再送判定システム
JP2013529336A (ja) * 2010-04-30 2013-07-18 インターデイジタル パテント ホールディングス インコーポレイテッド ネットワーク通信における軽量プロトコルおよびエージェント

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000311135A (ja) * 1999-03-31 2000-11-07 Internatl Business Mach Corp <Ibm> 通信方法、記録媒体及びウェブ・サーバ
JP2002544608A (ja) * 1999-05-10 2002-12-24 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 様々なネットワークを介して匿名ユーザ間でのインテリジェントなセッションを確立する分散システム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000311135A (ja) * 1999-03-31 2000-11-07 Internatl Business Mach Corp <Ibm> 通信方法、記録媒体及びウェブ・サーバ
JP2002544608A (ja) * 1999-05-10 2002-12-24 テレフオンアクチーボラゲット エル エム エリクソン（パブル） 様々なネットワークを介して匿名ユーザ間でのインテリジェントなセッションを確立する分散システム

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005526294A (ja) * 2002-05-21 2005-09-02 ジェネラル・インスツルメント・コーポレーション 関連するストリーミングプロトコル群に対するセキュリティパラメータの統合
JP4722478B2 (ja) * 2002-05-21 2011-07-13 ジェネラル・インスツルメント・コーポレーション 関連するストリーミングプロトコル群に対するセキュリティパラメータの統合
US7561518B2 (en) 2002-07-03 2009-07-14 Sony Corporation Data sending/receiving system and method, information providing apparatus and method, and data receiving apparatus and method
WO2004098134A1 (ja) * 2002-09-13 2004-11-11 Matsushita Electric Industrial Co., Ltd. リアルタイム通信の適応制御方法
US7634570B2 (en) 2003-03-12 2009-12-15 Microsoft Corporation Managing state information across communication sessions between a client and a server via a stateless protocol
JP2011223414A (ja) * 2010-04-12 2011-11-04 Nippon Telegr & Teleph Corp <Ntt> 再送判定装置、再送判定方法、再送判定プログラム、及び再送判定システム
JP2013529336A (ja) * 2010-04-30 2013-07-18 インターデイジタル パテント ホールディングス インコーポレイテッド ネットワーク通信における軽量プロトコルおよびエージェント
US9584630B2 (en) 2010-04-30 2017-02-28 Interdigital Patent Holdings, Inc. Light weight protocol and agent in a network communication

Also Published As

Publication number Publication date
JP4663100B2 (ja) 2011-03-30

Similar Documents

Publication Publication Date Title
US8094667B2 (en) RTP video tunneling through H.221
US9673996B1 (en) Redirection of a streaming media session in an anticipated failover scenario
US7675939B2 (en) Transmission apparatus and method, reception apparatus and method, communication system, recording medium, and program
US6862277B2 (en) Method and apparatus for multi-media communication over multiple networks
EP1745387B1 (en) Fast startup for streaming media
CN101313554B (zh) 基于ip多媒体子系统的交互式媒体会话建立系统和方法、装置
US8683007B2 (en) Seamless transfer of media streams
RU2597490C2 (ru) Способы связи в реальном времени, обеспечивающие паузу и возобновление, и связанные с ними устройства
CN108965776B (zh) 一种通信方法以及通信系统
US20050071494A1 (en) Method and apparatus for providing fixed bandwidth communications over a local area network
EP1578128A1 (en) Method an apparatus for conferencing with bandwidth control
EP1578129A1 (en) Method and apparatus for conferencing with stream selectivity
JP2003218934A (ja) 走査フォーマット変換装置及び方法
JPWO2006051594A1 (ja) 通信ネットワークにおけるｉｐパケット中継方法およびゲートウエイ装置
EP2413564A1 (en) Method and apparatus for transmitting and receiving streaming data based on RTSP sessions
US20130290517A1 (en) Nat traversal under tcp for real time streaming protocol
WO2012174927A1 (zh) 一种视频监控系统及媒体穿越网络地址转换设备的方法
JPWO2005094077A1 (ja) 多地点会議システムおよび多地点会議装置
JP4491521B2 (ja) Ｒｔｐによるｄｔｍｆ転送方法
US8385328B2 (en) Apparatus and method for providing mirroring service in VolP system including IP-PBX
JP2002157175A (ja) サーバー、クライアント、ゲートウェイ及び通信開始方法
US7277423B1 (en) Method and system for buffering media to reduce apparent latency in initiating a packet-based real-time media session
JP4049123B2 (ja) 電子機器及び制御方法
WO2012083805A1 (zh) 一种视频通话的实现方法、系统及装置
CN112788348A (zh) 一种点播方法、装置、设备、系统及存储介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20071116

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100401

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100518

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100629

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20101221

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110105

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140114

Year of fee payment: 3

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees