JP4663100B2 - サーバー、クライアント、通信開始方法及び通信開始プログラム - Google Patents

サーバー、クライアント、通信開始方法及び通信開始プログラム Download PDF

Info

Publication number
JP4663100B2
JP4663100B2 JP2000353439A JP2000353439A JP4663100B2 JP 4663100 B2 JP4663100 B2 JP 4663100B2 JP 2000353439 A JP2000353439 A JP 2000353439A JP 2000353439 A JP2000353439 A JP 2000353439A JP 4663100 B2 JP4663100 B2 JP 4663100B2
Authority
JP
Japan
Prior art keywords
server
client
session
setup
media data
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.)
Expired - Fee Related
Application number
JP2000353439A
Other languages
English (en)
Other versions
JP2002157175A (ja
Inventor
大治 井戸
徹 寺田
優希 堀内
誠治 浦
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 Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
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 Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
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

Images

Landscapes

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

Description

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

Claims (33)

  1. メディアデータの送信準備をサーバーに対してリクエストする複数のＳＥＴＵＰコマンドを第１のＩＤを付与して連続して送信するリクエスト生成部と、
    前記複数のＳＥＴＵＰコマンドによりリクエストしたメディアデータが送信可能であることを通知する複数の肯定レスポンスを前記サーバーから受信するレスポンス受信部と、を備え、
    前記複数の肯定レスポンスには、前記第１のＩＤとは異なる第２のＩＤが付与されている、
    クライアント。
  2. 前記リクエスト生成部は、前記複数のＳＥＴＵＰコマンドとメディアデータの送信を要求するＰＬＡＹコマンドとを第１のＩＤを付与して連続して前記サーバーに送信し、
    前記レスポンス受信部は、前記複数のＳＥＴＵＰコマンドによりリクエストしたメディアデータが送信可能であることを通知する複数の肯定レスポンスと、前記ＰＬＡＹコマンドに対応する肯定レスポンスとを受信し、
    前記複数の肯定レスポンスと前記ＰＬＡＹコマンドに対応する肯定レスポンスには、前記第１のＩＤとは異なる第２のＩＤが付与されている、
    請求項１に記載のクライアント。
  3. 前記リクエスト生成部は、前記複数の肯定レスポンスの受信前に前記複数のＳＥＴＵＰコマンドを送信する、
    請求項１又は請求項２に記載のクライアント。
  4. メディアデータの送信準備をサーバーに対してリクエストする複数のＳＥＴＵＰコマンドを第１のＩＤを付与して連続して送信するリクエスト生成部と、
    前記複数のＳＥＴＵＰコマンドによりリクエストしたメディアデータが送信可能であることを通知する複数の肯定レスポンスを前記サーバーから受信するレスポンス受信部と、を備え、
    前記リクエスト生成部は、前記複数の肯定レスポンスの受信前に前記複数のＳＥＴＵＰコマンドを送信する、
    クライアント。
  5. 前記リクエスト生成部は、ＳＥＴＵＰコマンドに対する肯定レスポンス受信前に、前記複数のＳＥＴＵＰコマンドとメディアデータの送信を要求するＰＬＡＹコマンドとを第１のＩＤを付与して連続して前記サーバーに送信する、
    請求項４に記載のクライアント。
  6. 前記複数のＳＥＴＵＰコマンドは、ビデオのＳＥＴＵＰコマンドとオーディオのＳＥＴＵＰコマンドとを含む、
    請求項１乃至請求項５のいずれか１項に記載のクライアント。
  7. 前記複数のＳＥＴＵＰコマンドは、ＲＴＳＰプロトコルを用いたコマンドである、
    請求項１乃至請求項６のいずれか１項に記載のクライアント。
  8. 前記複数のＳＥＴＵＰコマンドでリクエストしたメディアデータを前記サーバーから受信するメディア受信部を備える、
    請求項１乃至請求項７のいずれか１項に記載のクライアント。
  9. クライアントからメディアデータの送信準備をリクエストする複数のＳＥＴＵＰコマンドを同一のＩＤを用いて連続して送信されるサーバーであって、
    メディアデータの送信準備をリクエストする複数のＳＥＴＵＰコマンドが同一のクライアントから送信されたか否かをＩＤに基づいて判定する第一判定手段と、
    前記複数のＳＥＴＵＰコマンドが同一のクライアントから送信された場合、前記複数のリクエストに対して同一のセッションを開設するセッション設定手段と、を備える、
    サーバー。
  10. 前記第一判定手段は、前記クライアントから送信されたＩＤとは異なるＩＤを新たに生成し、
    前記セッション設定手段は、前記新たに生成したＩＤを用いてセッションを開設する、
    請求項９に記載のサーバー。
  11. 前記開設されたセッションで前記ＳＥＴＵＰコマンドに対応するメディアデータを前記クライアントに送信するメディア送信手段を具備する、
    請求項９又は請求項１０に記載のサーバー。
  12. メディアデータの送信準備をサーバーに対してリクエストする複数のＳＥＴＵＰコマンドを第１のＩＤを付与して連続して送信するリクエスト生成ステップと、
    前記複数のＳＥＴＵＰコマンドによりリクエストしたメディアデータが送信可能であることを通知する複数の肯定レスポンスを前記サーバーから受信するレスポンス受信ステップと、を備え、
    前記複数の肯定レスポンスには、前記第１のＩＤとは異なる第２のＩＤが付与されている、
    通信開始方法。
  13. 前記リクエスト生成ステップは、前記複数のＳＥＴＵＰコマンドとメディアデータの送信を要求するＰＬＡＹコマンドとを第１のＩＤを付与して連続して前記サーバーに送信し、
    前記レスポンス受信ステップは、前記複数のＳＥＴＵＰコマンドによりリクエストしたメディアデータが送信可能であることを通知する複数の肯定レスポンスと、前記ＰＬＡＹコマンドに対応する肯定レスポンスとを受信し、
    前記複数の肯定レスポンスと前記ＰＬＡＹコマンドに対応する肯定レスポンスには、前記第１のＩＤとは異なる第２のＩＤが付与されている、
    請求項１２に記載の通信開始方法。
  14. 前記リクエスト生成ステップは、前記複数の肯定レスポンスの受信前に前記複数のＳＥＴＵＰコマンドを送信する、
    請求項１２又は請求項１３に記載の通信開始方法。
  15. メディアデータの送信準備をサーバーに対してリクエストする複数のＳＥＴＵＰコマンドを第１のＩＤを付与して連続して送信するリクエスト生成ステップと、
    前記複数のＳＥＴＵＰコマンドによりリクエストしたメディアデータが送信可能であることを通知する複数の肯定レスポンスを前記サーバーから受信するレスポンス受信ステップと、を備え、
    前記リクエスト生成ステップは、前記複数の肯定レスポンスの受信前に前記複数のＳＥＴＵＰコマンドを送信する、
    通信開始方法。
  16. 前記リクエスト生成ステップは、ＳＥＴＵＰコマンドに対する肯定レスポンス受信前に、前記複数のＳＥＴＵＰコマンドとメディアデータの送信を要求するＰＬＡＹコマンドとを第１のＩＤを付与して連続して前記サーバーに送信する、
    請求項１５に記載の通信開始方法。
  17. 前記複数のＳＥＴＵＰコマンドは、ビデオのＳＥＴＵＰコマンドとオーディオのＳＥＴＵＰコマンドとを含む、
    請求項１２乃至請求項１６のいずれか１項に記載の通信開始方法。
  18. 前記複数のＳＥＴＵＰコマンドは、ＲＴＳＰプロトコルを用いたコマンドである、
    請求項１２乃至請求項１７のいずれか１項に記載の通信開始方法。
  19. リクエストしたメディアデータを前記サーバーから受信するメディア受信ステップを備える、
    請求項１２乃至請求項１８のいずれか１項に記載の通信開始方法。
  20. クライアントからメディアデータの送信準備をリクエストする複数のＳＥＴＵＰコマンドを同一のＩＤを用いて連続して送信されるサーバーにおける通信開始方法であって、
    メディアデータの送信準備をリクエストする複数のＳＥＴＵＰコマンドが同一のクライアントから送信されたか否かをＩＤに基づいて判定する第一判定ステップと、
    前記複数のＳＥＴＵＰコマンドが同一のクライアントから送信された場合、前記複数のリクエストに対して同一のセッションを開設するセッション設定ステップと、を備える、
    通信開始方法。
  21. 前記第一判定ステップは、前記クライアントから送信されたＩＤとは異なるＩＤを新たに生成し、
    前記セッション設定ステップは、前記新たに生成したＩＤを用いてセッションを開設する、
    請求項２０に記載の通信開始方法。
  22. 前記開設されたセッションで前記ＳＥＴＵＰコマンドに対応するメディアデータを前記クライアントに送信するメディア送信ステップを具備する、
    請求項２０又は請求項２１に記載の通信開始方法。
  23. コンピュータに、
    メディアデータの送信準備をサーバーに対してリクエストする複数のＳＥＴＵＰコマンドを第１のＩＤを付与して連続して送信するリクエスト生成ステップと、
    前記複数のＳＥＴＵＰコマンドによりリクエストしたメディアデータが送信可能であることを通知する複数の肯定レスポンスを前記サーバーから受信するレスポンス受信ステップと、を実行させるための通信開始プログラムであって、
    前記複数の肯定レスポンスには、前記第１のＩＤとは異なる第２のＩＤが付与されている、
    通信開始プログラム。
  24. 前記リクエスト生成ステップは、前記複数のＳＥＴＵＰコマンドとメディアデータの送信を要求するＰＬＡＹコマンドとを第１のＩＤを付与して連続して前記サーバーに送信し、
    前記レスポンス受信ステップは、前記複数のＳＥＴＵＰコマンドによりリクエストしたメディアデータが送信可能であることを通知する複数の肯定レスポンスと、前記ＰＬＡＹコマンドに対応する肯定レスポンスとを受信し、
    前記複数の肯定レスポンスと前記ＰＬＡＹコマンドに対応する肯定レスポンスには、前記第１のＩＤとは異なる第２のＩＤが付与されている、
    請求項２３に記載の通信開始プログラム。
  25. 前記リクエスト生成ステップは、前記複数の肯定レスポンスの受信前に前記複数のＳＥＴＵＰコマンドを送信する、
    請求項２３又は請求項２４に記載の通信開始プログラム。
  26. コンピュータに、
    メディアデータの送信準備をサーバーに対してリクエストする複数のＳＥＴＵＰコマンドを第１のＩＤを付与して連続して送信するリクエスト生成ステップと、
    前記複数のＳＥＴＵＰコマンドによりリクエストしたメディアデータが送信可能であることを通知する複数の肯定レスポンスを前記サーバーから受信するレスポンス受信ステップと、を実行させるための通信開始プログラムであって、
    前記リクエスト生成ステップは、前記複数の肯定レスポンスの受信前に前記複数のＳＥＴＵＰコマンドを送信する、
    通信開始プログラム。
  27. 前記リクエスト生成ステップは、ＳＥＴＵＰコマンドに対する肯定レスポンス受信前に、前記複数のＳＥＴＵＰコマンドとメディアデータの送信を要求するＰＬＡＹコマンドとを第１のＩＤを付与して連続して前記サーバーに送信する、
    請求項２６に記載の通信開始プログラム。
  28. 前記複数のＳＥＴＵＰコマンドは、ビデオのＳＥＴＵＰコマンドとオーディオのＳＥＴＵＰコマンドとを含む、
    請求項２３乃至請求項２７のいずれか１項に記載の通信開始プログラム。
  29. 前記複数のＳＥＴＵＰコマンドは、ＲＴＳＰプロトコルを用いたコマンドである、
    請求項２３乃至請求項２８のいずれか１項に記載の通信開始プログラム。
  30. リクエストしたメディアデータを前記サーバーから受信するメディア受信ステップをさらに実行させる、
    請求項２３乃至請求項２９のいずれか１項に記載の通信開始プログラム。
  31. クライアントからメディアデータの送信準備をリクエストする複数のＳＥＴＵＰコマンドを同一のＩＤを用いて連続して送信されるサーバーに、
    メディアデータの送信準備をリクエストする複数のＳＥＴＵＰコマンドが同一のクライアントから送信されたか否かをＩＤに基づいて判定する第一判定ステップと、
    前記複数のＳＥＴＵＰコマンドが同一のクライアントから送信された場合、前記複数のリクエストに対して同一のセッションを開設するセッション設定ステップと、を実行させる、
    通信開始プログラム。
  32. 前記第一判定ステップは、前記クライアントから送信されたＩＤとは異なるＩＤを新たに生成し、
    前記セッション設定ステップは、前記新たに生成したＩＤを用いてセッションを開設する、
    請求項３１に記載の通信開始プログラム。
  33. 前記開設されたセッションで前記ＳＥＴＵＰコマンドに対応するメディアデータを前記クライアントに送信するメディア送信ステップをさらに実行させる、
    請求項３１又は請求項３２に記載の通信開始プログラム。
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 JP2002157175A (ja) 2002-05-31
JP4663100B2 true 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)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7356687B2 (en) * 2002-05-21 2008-04-08 General Instrument Corporation Association of security parameters for a collection of related streaming protocols
JP2004038575A (ja) 2002-07-03 2004-02-05 Sony Corp データ送受信システム及びデータ送受信方法、情報提供装置及び情報提供方法、並びにデータ受信装置及びデータ受信方法
JP2004112113A (ja) * 2002-09-13 2004-04-08 Matsushita Electric Ind 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
JP4965683B2 (ja) * 2010-04-12 2012-07-04 日本電信電話株式会社 再送判定装置、再送判定方法、再送判定プログラム、及び再送判定システム
KR20130133084A (ko) * 2010-04-30 2013-12-05 인터디지탈 패튼 홀딩스, 인크 네트워크 통신에서의 경량 프로토콜 및 에이전트

Citations (1)

* 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> 通信方法、記録媒体及びウェブ・サーバ

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6564261B1 (en) * 1999-05-10 2003-05-13 Telefonaktiebolaget Lm Ericsson (Publ) Distributed system to intelligently establish sessions between anonymous users over various networks

Patent Citations (1)

* 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> 通信方法、記録媒体及びウェブ・サーバ

Also Published As

Publication number Publication date
JP2002157175A (ja) 2002-05-31

Similar Documents

Publication Publication Date Title
US7675939B2 (en) Transmission apparatus and method, reception apparatus and method, communication system, recording medium, and program
US8683007B2 (en) Seamless transfer of media streams
US9673996B1 (en) Redirection of a streaming media session in an anticipated failover scenario
US7447775B1 (en) Methods and apparatus for supporting transmission of streaming data
US20050071494A1 (en) Method and apparatus for providing fixed bandwidth communications over a local area network
JP2003218934A (ja) 走査フォーマット変換装置及び方法
EP3515083B1 (en) Method and apparatus for performing synchronization operation on contents
US20130290517A1 (en) Nat traversal under tcp for real time streaming protocol
US8806048B2 (en) Method and apparatus for transmitting and receiving streaming data based on real-time streaming protocol (RTSP) session
WO2012174927A1 (zh) 一种视频监控系统及媒体穿越网络地址转换设备的方法
WO2011095056A1 (zh) 一种远程桌面体系的音频处理方法和设备
KR20050113618A (ko) 송수신 시스템, 수신 장치 및 방법
WO2009039891A1 (en) Method of controlling a communication device
US8667159B2 (en) Communication device, communication method, and computer product
WO2013116975A1 (zh) 流媒体播放方法、设备及系统
CN101674228A (zh) 实现流媒体通信的方法、装置及系统
WO2002098109A1 (en) Packet reception apparatus and packet reception method
JP2007142786A (ja) ハンドオーバサーバ及びそれと通信可能な移動通信端末
JP4663100B2 (ja) サーバー、クライアント、通信開始方法及び通信開始プログラム
CN111107445B (zh) 一种媒体协议流优化方法及系统
JP2000151680A (ja) マルチメディア通信装置
JP4049123B2 (ja) 電子機器及び制御方法
CN112788348A (zh) 一种点播方法、装置、设备、系统及存储介质
CN101179502A (zh) 一种流媒体数据的转发系统和转发方法
Ott et al. Disconnection tolerance for SIP-based real-time media sessions

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