JP2009118361A - 通信制御装置ならびに通信制御方法 - Google Patents

Abstract

【課題】帯域制御処理を実行できない既存のクライアント端末においても、ＱｏＳ保証されたストリーミング型コンテンツ配信サービスを受けることを可能とする通信制御装置ならびに通信制御方法を提供する。
【解決手段】ＲＴＳＰを用いたストリーミング型コンテンツ配信サービスにおいて、ホームネットワークとＱｏＳ制御可能な外部ネットワークとの間に設置される通信制御装置１０５であって、ＲＴＳＰクライアント機器とＲＴＳＰサーバ機器との間で送受信されるＲＴＳＰメッセージを取得するメッセージ取得部４０２と、メッセージ取得部４０２にて取得した前記ＲＴＳＰメッセージから、ＱｏＳ制御に必要な情報を取得するＱｏＳ制御情報生成部４０３と、ＱｏＳ制御情報生成部４０３にて取得したＱｏＳ制御に必要な情報を元に、前記ＲＴＳＰサーバ機器との間で映像伝送用のＱｏＳセッションを確立するＱｏＳ制御部４０４とを有する。
【選択図】図４

Description

本発明は、通信制御装置ならびに通信制御方法に関し、特に、ＲＴＳＰ（Real Time Streaming Protocol）を用いて映像、音楽等のコンテンツの再生制御を行うストリーミング型コンテンツ配信サービスに用いられる通信制御装置ならびに通信制御方法に適用して有効な技術に関するものである。

ブロードバンドネットワークの普及により、ＰＣやネットワーク接続ＴＶ（ＩＰＴＶ）、ＳＴＢ（Set Top Box）等をクライアント端末とした、ネットワークを介した映像や音楽等のコンテンツ配信サービスが拡大している。

このようなコンテンツ配信サービスは、ストリーミング型とダウンロード型に大別することができる。このうち、ストリーミング型のコンテンツ配信サービスにおいては、コンテンツ配信サーバは、クライアント端末でのコンテンツの再生速度に合わせてコンテンツを配信する必要がある。よって、このようなサービスの多くはＲＴＳＰ（Real Time Streaming Protocol）等のプロトコルを用いてコンテンツの再生要求、停止要求といった再生制御を行い、再生要求を受けてＲＴＰ（Real-time Transport Protocol）等のプロトコルを用いてコンテンツを伝送する方法が取られる。

このようなストリーミング型のコンテンツ配信サービスにおいては、クライアント端末とコンテンツ配信サーバとの間のネットワーク帯域が十分に確保されない場合、もしくは時間的にネットワーク帯域が十分に確保できないことがある場合において、再生中のコンテンツが途中で止まる、途切れるといった問題が発生する可能性がある。

近年、ＮＧＮ（Next Generation Network）のような帯域保証（ＱｏＳ（Quality of Service）保証）可能なネットワークが登場するに至り、上記のような問題のあったストリーミング型のコンテンツ配信サービスにおいて、コンテンツが途中で止まったり、途切れたりすることを防止する、すなわちＱｏＳ保証を行う方法が開示されている。

例えば、特開２００５−１２６５５号公報（特許文献１）には、端末装置がコンテンツ配信サブシステムにセッション確立を要求した際に、ＳＩＰ（Session Initiation Protocol）セッション制御サブシステムが、コンテンツ配信サブシステムから当該コンテンツの視聴に必要な帯域の情報を取得し、帯域制御サブシステムに当該帯域情報に含まれる帯域値の帯域予約の要求を行い、帯域制御サブシステムで確保された帯域でコンテンツ配信サブシステムから端末装置に当該コンテンツを送信する方法が開示されている。

また、特開２００４−２８９６２７号公報（特許文献２）には、ストリーミングコンテンツの配信要求がクライアント端末から通信ネットワークを介して送信される際に、映像配信サーバの現在の使用可能帯域に関連する帯域リソース情報を監視するサーバリソース監視部と、通信ネットワーク上の複数の中継点に対応する複数のルータ、クライアント端末および映像配信サーバの間の複数の通信経路それぞれの現在の使用可能帯域に関連するネットワークリソース情報を監視するネットワークリソース監視部とを備えたストリーミングコンテンツ配信要求受付制御システムが開示されている。

また、このようなストリーミング型コンテンツ配信システムにおいては、コンテンツはＵＤＰ（User Datagram Protocol）で配送する場合が多い為、コンテンツ配信サーバから、ＮＡＴ（Network Address Translation）を利用して構成されたネットワーク上のクライアント端末へのコンテンツデータの到達問題（いわゆるＮＡＴ越え問題）も存在し、この問題を解決するための方法も開示されている。

例えば、特開２００５−５１６８０号公報（特許文献３）には、動画端末がサーバにＮＡＴテーブル作成パケットを送信するようにし、また、ＲＴＳＰなどの制御系通信プロトコルで、サーバが送るマルチメディアデータの送り先ポートを決めるという従来の方法を改め、サーバがコンテンツの配信を開始する前に、動画端末からのＮＡＴテーブル作成パケットの受信を待ち、サーバが送るコンテンツ配信の宛先のＩＰアドレスおよびポート番号として、このパケットの発信元ＩＰアドレスおよび発信元ポート番号を使うことによりＮＡＴ越えの問題を解決する方法が開示されている。
特開２００５−１２６５５号公報（図１） 特開２００４−２８９６２７号公報（図１） 特開２００５−５１６８０号公報（図４）

上述の従来技術にはそれぞれ以下のような課題がある。まず、特許文献１に示される方法では、端末装置が帯域制御のためにＳＩＰ制御を行う必要がある。ユーザ宅には今後、ＰＣ、ＳＴＢ、ネットワーク接続ＴＶ等の複数の端末装置が設置されることが考えられるが、特許文献１に示される方法で帯域制御を実現するためには、これら全ての端末装置をＳＩＰ制御可能なもので揃えなければならない。

例えば、ユーザ宅にインターネット等の帯域制御不可能なネットワーク上におけるストリーミング型コンテンツ配信サービス対応の端末装置が既にあったとしても、ＮＧＮのような帯域制御可能なネットワーク上におけるストリーミング型コンテンツ配信サービスをそのまま受けることはできず、ユーザに機器の買い替え、交換、ソフトウェア更新といったコストや手間を強いることになる。

また、特許文献２に示される方法では、ストリーミングコンテンツ配信要求受付制御システムは、コンテンツの配送経路を決定する為に、該当コンテンツの必要帯域情報を用いる。コンテンツの配送経路の決定は、ＷＷＷポータルサーバ上でユーザがコンテンツを選択した際に行われる為、ストリーミングコンテンツ配信要求受付制御システムでは、ＷＷＷポータルサーバで選択されたコンテンツのＩＤ情報からコンテンツの必要帯域情報を取得するためのコンテンツ管理テーブルをあらかじめ準備しておかなければならない。

すなわち、特許文献２に示される方法では、帯域制御やコンテンツ配送経路設定の処理とコンテンツそのものの情報とが密接に関係した構造となっており、単にコンテンツ配信サービスを行いたいサービス提供事業者にとっては、既存の映像配信システムを利用できない等、参入の敷居を高める構成となっている。

また、特許文献３に示される方法では、サーバから動画端末へのＮＡＴ越えを実現する為に、動画端末はＮＡＴテーブル作成パケットを送出する必要があり、また、サーバはＮＡＴテーブル作成パケットの受信を待ってからコンテンツの送出を開始する構成となるため、動画端末、サーバ双方が上記手順に対応した装置でなければならない。例えば、ユーザが従来から所持している動画端末を用いた場合や、一般のストリーミング型コンテンツ配信サーバを用いた場合はＮＡＴ越えを実現することができない。

すなわち、特許文献３に示される方法の実現のためには、コンテンツ配信サービス提供事業者は当該方法に準拠したサーバを用意し、さらにサービス提供事業者からユーザにも当該方法に準拠した動画端末を配布する、もしくはユーザが当該方法に準拠した動画端末を購入する等のコストや手間を強いることになる。

そこで本発明の目的は、帯域制御処理を実行できない既存のクライアント端末においても、ＱｏＳ保証されたストリーミング型コンテンツ配信サービスを受けることを可能とする通信制御装置ならびに通信制御方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。

本発明の代表的な実施の形態による通信制御装置は、クライアント端末が接続されるホームネットワークと映像配信サーバが接続されるＱｏＳ制御可能な外部ネットワークとの間に設置される通信制御装置であって、クライアント端末と映像配信サーバとの間で送受信されるＲＴＳＰメッセージに含まれる情報からＱｏＳ制御やＮＡＴ越えに必要な情報を取得し、クライアント端末の代わりに映像配信サーバとの間のＱｏＳセッションの確立や、ＮＡＴ越えの為のポートフォワード設定を行うことを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、通信制御装置でＱｏＳセッション制御を一元的に実行することにより、ＱｏＳ制御手段を有しないクライアント端末を用いて通信制御装置と映像配信サーバとの間のＱｏＳ制御セッションの確立が可能であり、ユーザにとってクライアント端末をＱｏＳ制御可能なものに置き換えるコストが不要であり、管理コストも小さい帯域保証型コンテンツ配信システムを実現することができる。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

図１は、本発明の一実施の形態である映像配信システムの構成の一例を示す図である。図１において、当該映像配信システムは、映像配信サーバ１０２、帯域制御サーバ１０３、通信制御装置１０５、映像受信表示装置１０７、１０８を有する構成となっている。

映像配信サーバ１０２と帯域制御サーバ１０３と通信制御装置１０５とは、ＮＧＮ（Next Generation Network）等のＱｏＳ（Quality of Service）制御可能なネットワーク１０１と接続しており、所定の手順に従って情報の送受信を行うことができる。また、通信制御装置１０５と映像受信表示装置１０７、１０８は、ユーザ宅１０４内に設置され、有線または無線で構成されるホームネットワーク１０６と接続しており、所定の手順に従って情報の送受信を行うことができる。

通信制御装置１０５は、ネットワーク１０１とホームネットワーク１０６の両方と接続しており、ユーザ宅１０４内に設置された機器にとって、ネットワーク１０１に接続された機器と情報の送受信を行うためのゲートウェイとしての機能を有する。

図２は、通信制御装置１０５のハードウェア構成の一例を示す図である。図２において、通信制御装置１０５は、ＣＰＵ２０１、メインメモリ２０２、ＥＰＲＯＭ２０３、第１ネットワークＩ／Ｆ２０４、第２ネットワークＩ／Ｆ２０５、不揮発性記憶装置２０６を有する構成となっており、これらはそれぞれバス２０７と接続され、所定の手順に従って情報の送受信を行うことができる。

ＥＰＲＯＭ２０３にはブートプログラムが記憶されており、また、不揮発性記憶装置２０６には各種プログラムが記憶されている。通信制御装置１０５が起動すると、ＥＰＲＯＭ２０３に記憶されたブートプログラムによって不揮発性記憶装置２０６から各種プログラムがメインメモリ２０２へと読み出される。ＣＰＵ２０１はメインメモリ２０２に読み出された各種プログラムを実行することにより、第１ネットワークＩ／Ｆ２０４や第２ネットワークＩ／Ｆ２０５等による信号の送受信等を行う。

第１ネットワークＩ／Ｆ２０４は、ホームネットワーク１０６と接続しており、ホームネットワーク１０６に接続する機器との間で情報の送受信を行うことができる。第１ネットワークＩ／Ｆ２０４は、ネットワークカード等により実現することができる。同様に、第２ネットワークＩ／Ｆ２０５は、ネットワーク１０１と接続しており、ネットワーク１０１と接続する機器との間で情報の送受信を行うことができる。第２ネットワークＩ／Ｆ２０５も、ネットワークカード等により実現することができる。

不揮発性記憶装置２０６には、上述のように、ＣＰＵ２０１がメインメモリ２０２に読み出して実行するための各種プログラムが記憶されている。不揮発性記憶装置２０６は、フラッシュメモリやＨＤＤ（ハードディスクドライブ）、光ディスク等により実現することができる。

図３は、映像受信表示装置１０７のハードウェア構成の一例を示す図である。映像受信表示装置１０８のハードウェア構成も映像受信表示装置１０７と同様である。図３において、映像受信表示装置１０７は、ＣＰＵ３０１、メインメモリ３０２、ＥＰＲＯＭ３０３、出力装置３０４、ネットワークＩ／Ｆ３０５、不揮発性記憶装置３０６、入力装置３０７、映像再生装置３０８を有する構成となっており、これらはそれぞれバス３０９と接続され、所定の手順にしたがって情報の送受信を行うことができる。

ＥＰＲＯＭ３０３にはブートプログラムが記憶されており、また、不揮発性記憶装置３０６には各種プログラムが記憶されている。映像受信表示装置１０７が起動すると、ＥＰＲＯＭ３０３に記憶されたブートプログラムによって不揮発性記憶装置３０６から各種プログラムがメインメモリ３０２へと読み出される。ＣＰＵ３０１はメインメモリ３０２に読み出された各種プログラムを実行することにより、出力装置３０４、ネットワークＩ／Ｆ３０５、入力装置３０７、映像再生装置３０８等による信号の送受信等を行う。

出力装置３０４は、映像再生装置３０８で伸張（デコード）されたコンテンツや、ユーザの操作に応答するための情報を表示等により出力するための手段であり、ＣＲＴ、液晶ディスプレイ、プラズマディスプレイ、プロジェクタ、スピーカ、ヘッドフォン等によって実現される。また、出力装置３０４は、ＴＶ等のコンテンツ再生端末とは異なる装置で実現してもよい。この場合、映像受信表示装置１０７には別途Ｄ／Ａコンバータ等のＴＶ信号生成装置を具備し、当該装置と出力装置３０４とはＡＶケーブルや同軸ケーブル等で接続される。

ネットワークＩ／Ｆ３０５は、通信網を介して他の装置と情報を送受信するための手段であり、例えばネットワークアダプタ、無線送受信装置等によって実現される。不揮発性記憶装置３０６には、上述のように、ＣＰＵ３０１がメインメモリ３０２に読み出して実行するための各種プログラムが記憶されており、例えばＨＤＤ、フラッシュメモリ、光ディスク等によって実現することができる。

入力装置３０７は、ユーザが必要な命令や情報を入力するための手段であり、例えばＴＶ受信機で使用されるリモコンや、ＰＣで使用されるキーボード、マウス等によって実現される。映像再生装置３０８は、音声や映像等のコンテンツをデコードし、デコードされたコンテンツを出力装置３０４に送信する装置である。

なお、上述した通信制御装置１０５および映像受信表示装置１０７の構成は、図２および図３に示す構成に限られないことは当然である。例えば、映像受信表示装置１０７において、コンテンツのデコードが全てソフトウェアプログラムによって実現され、ＣＰＵ３０１で実行されるような場合は、映像再生装置３０８を有さない構成となる。この場合、当該ソフトウェアプログラムは不揮発性記憶装置３０６に記憶され、ＣＰＵ３０１によってメインメモリ３０２上に読み出されて実行される。

映像配信サーバ１０２のハードウェア構成は、図示しないが、少なくとも１台以上のコンピュータ（ＣＰＵ、メインメモリ、不揮発性記憶装置、入力装置、出力装置、ネットワークＩ／Ｆ等を含む）から構成されており、不揮発性記憶装置からメインメモリに読み出され、ＣＰＵによって実行される各種プログラムには、ＲＴＳＰ（Real Time Streaming Protocol）、ＲＴＰ（Real-time Transport Protocol）等のコンテンツ配信用のプロトコル、およびＳＩＰ（Session Initiation Protocol）等のＱｏＳセッション制御用のプロトコルが実装されている。

帯域制御サーバ１０３のハードウェア構成は、図示しないが、少なくとも１台以上のコンピュータ（ＣＰＵ、メインメモリ、不揮発性記憶装置、入力装置、出力装置、ネットワークＩ／Ｆ等を含む）から構成されており、不揮発性記憶装置からメインメモリに読み出され、ＣＰＵによって実行される各種プログラムには、ＳＩＰ等のＱｏＳセッション制御用のプロトコルが実装されている。

次に、本実施の形態における通信制御装置１０５の機能の概要について説明する。図４は、通信制御装置１０５の機能構成の概要を示す図である。ルーティング部４０１は、図１におけるネットワーク１０１とホームネットワーク１０６との間のメッセージのルーティングを行う。このルーティング機能により、通信制御装置１０５は、ネットワーク１０１とホームネットワーク１０６との間のゲートウェイとして機能する。後述するＮＡＴ越えのためのポートフォワードの機能も、ルーティング部４０１で実現される。

メッセージ取得部４０２は、詳細は後述するが、ルーティング部４０１を介して映像受信表示装置１０７と映像配信サーバ１０３との間で送受信されるＲＴＳＰメッセージを取得するＲＴＳＰメッセージ取得機能を有する。ＱｏＳ制御情報生成部４０３は、メッセージ取得部４０２で取得されたＲＴＳＰメッセージから、後述するＱｏＳセッション制御のための情報およびポートフォワード設定のための情報を取得・生成し、テーブル群４０５に記憶する。

ＱｏＳ制御部４０４は、ＱｏＳ制御情報生成部４０３で取得・生成されたＱｏＳセッション制御のための情報を元に、ＳＩＰ等のＱｏＳセッション制御用のプロトコルにより、映像配信サーバ１０３との間でＱｏＳセッションを確立する。タイムアウト監視部４０６は、通信制御装置１０５と映像受信表示装置１０７および映像配信サーバ１０２との間で確立される複数の通信セッションのタイムアウトを一元的に監視する機能を有する。

ルーティング部４０１、メッセージ取得部４０２、ＱｏＳ制御情報生成部４０３、ＱｏＳ制御部４０４、タイムアウト監視部４０６の各部は、例えば不揮発性記憶装置２０６に記憶されるプログラムによって実現され、当該プログラムがメインメモリ２０２に読み出された後、ＣＰＵ２０１によって実行されることで、通信制御装置１０５は各機能を実現する。なお、上記各部をプログラムではなく回路によって構成することも当然可能である。また、テーブル群４０５は、上記プログラムの実行時にメインメモリ２０２上に作成される。

次に、本実施の形態の映像配信システムにおいて、通信制御装置１０５が扱うテーブル群４０５の内容について説明する。テーブル群４０５に含まれるテーブルは、通信制御装置１０５内で唯一のテーブルである「システム共通テーブル」と、映像受信表示装置１０７、１０８からのＲＴＳＰコネクション毎に記憶するテーブルである「コネクション内テーブル」とに分類することができる。

図５は、接続情報管理テーブル５００の構成とデータの例を示す図である。接続情報管理テーブル５００はコネクション内テーブルに該当し、対象のＲＴＳＰコネクションに係る映像受信表示装置１０７と映像配信サーバ１０２の情報や、コネクションのステータス等を管理する。接続情報管理テーブル５００は、クライアントアドレス５０１、サーバアドレス５０２、タイムアウト５０３、タイマー５０４、状態５０５の各項目から構成される。

図６は、利用可能ポート番号テーブル６００の構成とデータの例を示す図である。利用可能ポート番号テーブル６００はシステム共通テーブルに該当し、通信制御装置１０５においてＲＴＳＰコネクションに係る通信に利用可能なポート番号の範囲を記憶する。利用可能ポート番号テーブル６００は、利用可能ポート番号範囲６０１の項目から構成される。

図７は、利用ポート番号テーブル７００の構成とデータの例を示す図である。利用ポート番号テーブル７００はシステム共通テーブルに該当し、通信制御装置１０５においてＲＴＳＰコネクションに係る通信に既に利用されているポート番号を記憶する。利用ポート番号テーブル７００は、利用ポート番号７０１の項目から構成される。

図８は、ＲＴＳＰ通信利用ポート番号テーブル８００の構成とデータの例を示す図である。ＲＴＳＰ通信利用ポート番号テーブル８００はコネクション内テーブルに該当し、対象のＲＴＳＰコネクションについて、通信制御装置１０５が映像配信サーバ１０２との間でＲＴＳＰメッセージの送受信に利用しているポート番号を記憶する。ＲＴＳＰ通信利用ポート番号テーブル８００は、ＲＴＳＰ通信利用ポート番号８０１の項目から構成される。

図９は、映像データ受信情報テーブル９００の構成とデータの例を示す図である。映像データ受信情報テーブル９００はコネクション内テーブルに該当し、対象のＲＴＳＰコネクションについて、通信制御装置１０５が映像配信サーバ１０２から映像データを受信し、映像受信表示装置１０７へ送信するためのポートの情報等を管理する。映像データ受信情報テーブル９００は、通信制御装置ポート９０１、サーバポート９０２、クライアントポート９０３、帯域９０４の各項目から構成される。

次に、本実施の形態の映像配信システムにおける動作の概要について説明する。図１に示す構成において、映像受信表示装置１０７、１０８は、映像配信サーバ１０２等のＲＴＳＰサーバとの間でＲＴＳＰメッセージを送受信するＲＴＳＰクライアントであり、ＲＴＳＰメッセージの送受信によって、音声や映像等のコンテンツの再生制御を行う。

ネットワーク１０１は、ＮＧＮ等のＱｏＳ制御可能なネットワークであり、ネットワーク１０１に接続する機器は、帯域制御サーバ１０３に対して、例えば、「どのＩＰアドレスの機器の何番ポートとどのＩＰアドレスの機器の何番ポートとの間で何Ｋｂｐｓの帯域を確保する」、といったＱｏＳセッション制御要求を行うことによって、ネットワーク１０１に接続した機器間で品質の高い通信を行うことができる。なお、本実施の形態においては、以下、ＱｏＳセッション制御のプロトコルにはＳＩＰを用いるものとして説明を行う。

映像配信サーバ１０２は、映像受信表示装置１０７等のＲＴＳＰクライアントとの間でＲＴＳＰメッセージの送受信を行うＲＴＳＰサーバである。また、帯域制御サーバ１０３等のＳＩＰサーバとの間でＱｏＳセッション制御情報を送受信するＳＩＰクライアントでもある。

帯域制御サーバ１０３は、通信制御装置１０５、映像配信サーバ１０２等のＳＩＰクライアントとの間でＱｏＳセッション制御情報の送受信を行い、実際のＱｏＳ制御を実行するＳＩＰサーバである。また、図１には図示しないが、帯域制御サーバ１０３は、ＩＭＳ（IP Multimedia System）の一部であり、ＳＩＰクライアントからのＱｏＳセッション制御要求に応じてＩＭＳ内の各サーバ、例えば、ＨＳＳ（Home Subscriber Server）、共通イネーブラ、ＡＳ（Application Server）等と必要な情報の送受信を行い、ＱｏＳセッション制御を行う。

通信制御装置１０５は、帯域制御サーバ１０３等のＳＩＰサーバとの間でＱｏＳセッション制御情報の送受信を行うＳＩＰクライアントである。また、通信制御装置１０５は、ネットワーク１０１、ホームネットワーク１０６の両方と接続しており、メッセージ取得部４０２において、ホームネットワーク１０６側に接続された映像受信表示装置１０７等のＲＴＳＰクライアントが送信するＲＴＳＰメッセージ、およびネットワーク１０１側に接続された映像配信サーバ１０２等のＲＴＳＰサーバが送信するＲＴＳＰメッセージを取得するＲＴＳＰメッセージ取得機能を有する。

ここで、上記ＲＴＳＰメッセージ取得機能について説明する。ＲＴＳＰメッセージ取得機能において、映像受信表示装置１０７等のＲＴＳＰクライアント機器が送信するＲＴＳＰメッセージを取得するにはいくつかの方法があるが、その内の２つの方法について以下に説明する。

第１のＲＴＳＰメッセージ取得方法は、通信制御装置１０５にて、ＲＴＳＰメッセージを取得するためのポートを監視し、映像受信表示装置１０７等のＲＴＳＰクライアント機器にＲＴＳＰプロキシ設定として通信制御装置１０５の当該ポートを設定した上で、映像受信表示装置１０７等のＲＴＳＰクライアント機器から映像配信サーバ１０２等のＲＴＳＰサーバ機器へＲＴＳＰメッセージを送信する方法である。

ＲＴＳＰクライアント機器は、ＲＴＳＰサーバ機器とＲＴＳＰメッセージの送受信を行うための通信路を確立する。第１のＲＴＳＰメッセージ取得方法では、ＲＴＳＰクライアント機器は、接続先の情報（ＲＴＳＰサーバ機器のＩＰアドレスおよびポート）を含む通信路確立要求を、ＲＴＳＰプロキシ設定に指定された通信制御装置１０５のＲＴＳＰメッセージ監視ポートに対して送信することになる。

通信制御装置１０５では、ＲＴＳＰメッセージ監視ポートに到達する接続元の情報（ＲＴＳＰクライアント機器のＩＰアドレスおよびポート）、接続先の情報（ＲＴＳＰサーバ機器のＩＰアドレスおよびポート）を含む通信路確立要求を取得して通信路を確立する。これ以降、ＲＴＳＰクライアント機器は、当該通信路を介してＲＴＳＰメッセージを送信するため、通信制御装置１０５は、ＲＴＳＰクライアント機器からのＲＴＳＰメッセージを取得することができる。

上述した第１のＲＴＳＰメッセージ取得方法では、映像受信表示装置１０７等のＲＴＳＰクライアント機器においてＲＴＳＰプロキシ設定が可能であることが必須となる。映像受信表示装置１０７においてＲＴＳＰプロキシ設定が可能でない場合は、通信制御装置１０５は、以下に説明する第２のＲＴＳＰメッセージ取得方法にてＲＴＳＰメッセージを取得する必要がある。

第２のＲＴＳＰメッセージ取得方法は、通信制御装置１０５に対して、ホームネットワーク１０６側からの通信により入力される特定の情報を、通信制御装置１０５のＲＴＳＰメッセージ監視ポートに対してリダイレクトするような設定を行う方法である。例えば、通信制御装置１０５のオペレーティングシステムがＬｉｎｕｘ（登録商標）の場合は、以下のような設定により実現できる。

まず、Ｌｉｎｕｘのカーネルをリダイレクト設定が可能なように構成しておく。そして、例えば、“iptables -t nat -A PREROUTING -p tcp --dport 554 -j REDIRECT --to-ports 10554”のコマンドによって、Ｌｉｎｕｘに対してポートのリダイレクトの設定を行う。この設定によれば、通信制御装置１０５を通る５５４番ポート（ＲＴＳＰで用いられるWell Known Port）宛の通信を、例えば１０５５４番ポート宛にリダイレクトすることができる。

通信制御装置１０５にてあらかじめ上記のようなポートのリダイレクト設定を行い、リダイレクト先のポートを監視することによって、通信制御装置１０５は、ＲＴＳＰクライアント機器がＲＴＳＰサーバ機器とＲＴＳＰメッセージの送受信を行うための通信路確立要求を取得することができる。

第２のＲＴＳＰメッセージ取得方法では、ＲＴＳＰクライアント機器は、ＲＴＳＰサーバ機器のＲＴＳＰ待ち受けポート（通常は５５４番ポート）に対して通信路確立要求を送信する。ホームネットワーク１０６に接続するＲＴＳＰクライアント機器から、ネットワーク１０１に接続するＲＴＳＰサーバ機器に対しての通信は、必ず通信制御装置１０５を経由する。

通信制御装置１０５は、ＲＴＳＰクライアント機器が送信したＲＴＳＰサーバ機器宛の通信をリダイレクトし、リダイレクト先の監視ポートにて接続元の情報（ＲＴＳＰクライアント機器のＩＰアドレスおよびポート）および接続先の情報（ＲＴＳＰサーバ機器のＩＰアドレスおよびポート）を含む通信路確立要求を取得し、ＲＴＳＰクライアント機器との間に通信路を確立する。これ以降、ＲＴＳＰクライアント機器は、当該通信路を介してＲＴＳＰメッセージを送信するため、通信制御装置１０５は、ＲＴＳＰクライアント機器からのＲＴＳＰメッセージを取得することができる。

上述した第２のＲＴＳＰメッセージ取得方法では、映像受信表示装置１０７等のＲＴＳＰクライアント機器にはＲＴＳＰプロキシ設定等の特別な設定は必要なく、ＲＴＳＰクライアント機器は、通常の方法で単に映像配信サーバ１０２等のＲＴＳＰサーバ機器に対しての通信を行っているだけである。

上述した第１のＲＴＳＰメッセージ取得方法あるいは第２のＲＴＳＰメッセージ取得方法を用いたＲＴＳＰメッセージ取得機能により、通信制御装置１０５は、映像受信表示装置１０７等のＲＴＳＰクライアント機器が映像配信サーバ１０２等のＲＴＳＰサーバ機器に対して送信する通信路確立要求を取得することができる。言い換えると、通信制御装置１０５は、映像受信表示装置１０７等のＲＴＳＰクライアント機器が送信する通信路確立要求を取得することにより、ＲＴＳＰクライアント機器との間に通信路を確立することができる。以下、このＲＴＳＰクライアント機器と通信制御装置１０５との間の通信路を第１の通信路と記述する。

上述した第１あるいは第２のＲＴＳＰメッセージ取得方法により、ＲＴＳＰクライアント機器と第１の通信路を確立した通信制御装置１０５は、取得した通信路確立要求に含まれる接続元の情報（ＲＴＳＰクライアント機器のＩＰアドレスおよびポート）および接続先の情報（ＲＴＳＰサーバ機器のＩＰアドレスおよびポート）を取得することができる。ここで取得したＲＴＳＰサーバ機器の情報を用いて、通信制御装置１０５はさらに、ＲＴＳＰサーバ機器と接続するための通信路を確立することができる。以下、このＲＴＳＰサーバ機器と通信制御装置１０５との間の通信路を第２の通信路と記述する。

通信制御装置１０５は、第１の通信路を経由して受信したＲＴＳＰメッセージの内容を解析し、必要な情報を取得したり、適切に書き換えたりした後、第２の通信路を経由してＲＴＳＰサーバ機器に送信する。その後、通信制御装置１０５は、ＲＴＳＰサーバ機器からの応答であるＲＴＳＰメッセージを第２の通信路を経由して受信する。通信制御装置１０５は、取得したＲＴＳＰメッセージの内容を解析し、必要な情報を取得したり、適切に書き換えたりした後、第１の通信路を経由してＲＴＳＰクライアント機器に対して送信する。

送受信されるＲＴＳＰメッセージには、ＱｏＳセッション制御に必要な情報（ＱｏＳ制御を行う各機器のＩＰアドレスとポートおよび必要な帯域の情報）も含まれている。本実施の形態の映像配信システムは、上述のように、通信制御装置１０５によって、ＲＴＳＰクライアント機器とＲＴＳＰサーバ機器との間で送受信されるＲＴＳＰメッセージからＱｏＳセッション制御に必要な情報を取得し、ＲＴＳＰクライアント機器による再生制御が行われるまでの間に、ＲＴＳＰサーバ機器と通信制御装置１０５との間でＱｏＳ制御を行うことによって、ＱｏＳセッション制御機能を有しないＲＴＳＰクライアント機器が、ＱｏＳ保証された映像等のコンテンツ配信サービスを受けることを可能とするシステムである。

以下、本実施の形態の映像配信システムにおける動作の流れについて説明する。以下の説明において、通信制御装置１０５は上述した第１あるいは第２のＲＴＳＰメッセージ取得方法を用いて、ＲＴＳＰクライアント機器が送信するＲＴＳＰメッセージを取得することができるように設定されているものとする。なお、第１のＲＴＳＰメッセージ取得方法を用いる場合は、映像受信表示装置１０７等のＲＴＳＰクライアント機器に対してあらかじめＲＴＳＰプロキシ設定がされているものとする。

まず、図１０〜図１３を用いて、本実施の形態の映像配信システムにおける動作の流れの概要を説明する。

図１０は、通信路（第１の通信路および第２の通信路）の確立の際の動作の流れを示すシーケンス図である。まず、映像受信表示装置１０７が、通信制御装置１０５を経由して、映像配信サーバ１０２宛に通信路確立要求を送信する。通信制御装置１０５は、上述のＲＴＳＰメッセージ取得機能によって当該通信路確立要求を取得し、映像受信表示装置１０７との間に第１の通信路を確立する（１００１）。

次に、通信制御装置１０５は、メインメモリ２０２上にＲＴＳＰコネクション毎に作成されるワークメモリに、接続情報管理テーブル５００を新規に作成する（１００２）。次に、通信制御装置１０５は、通信路確立要求に含まれる接続元（クライアント）ＩＰアドレスおよび接続先（サーバ）ＩＰアドレスを取得して、接続情報管理テーブル５００のクライアントアドレス５０１およびサーバアドレス５０２に記憶する（１００３）。

次に、通信制御装置１０５は、システムであらかじめ決めておくタイムアウトの初期値（例えば１２０秒）を、接続情報管理テーブル５００のタイムアウト５０３およびタイマー５０４に設定する（１００４）。なお、ここで設定するタイムアウト値は、後にＲＴＳＰ ＳＥＴＵＰレスポンスを受信した際に取得するＲＴＳＰセッションのタイムアウト値に書き換えられることになる。

次に、通信制御装置１０５は、通信制御装置１０５と映像配信サーバ１０２との間でＲＴＳＰメッセージの送受信を行うためのポートを決定する（１００５）。ここではまず、システム共通テーブルである利用可能ポート番号テーブル６００から利用可能ポート番号範囲６０１を取得し、次に、システム共通テーブルである利用ポート番号テーブル７００に記憶している利用ポート番号７０１を全て読み出す。

通信制御装置１０５は、利用可能ポート番号範囲６０１のうち、利用ポート番号７０１に含まれない、すなわち現在利用されていないポートを一つ選び、それをＲＴＳＰメッセージの送受信に用いるポートとし、当該ポートを新たに利用ポート番号テーブル７００に追記する。また、ＲＴＳＰ通信利用ポート番号テーブル８００をワークメモリ上に作成し、当該ポートをＲＴＳＰ通信利用ポート番号８０１として記憶する。

次に、通信制御装置１０５は、帯域制御サーバ１０３に対し、映像配信サーバ１０２との間にＲＴＳＰ用ＱｏＳセッションを確立することを要求する（１００６）。このとき、ＲＴＳＰメッセージ自体はリアルタイム性が必要とされず、情報量もあまり多くない為、確保する帯域の指定は必要ない。すなわち、通信制御装置１０５のＩＰアドレスと上記で決定したＲＴＳＰ通信利用ポート番号８０１、および映像配信サーバ１０２のＩＰアドレスおよびポートの情報を用いてＲＴＳＰ用ＱｏＳセッションを確立する。

次に、通信制御装置１０５は、確立したＲＴＳＰ用ＱｏＳセッションを通して第２の通信路を確立する（１００７）。最後に、接続情報管理テーブル５００の状態５０５を“Ｉｎｉｔ”に設定する（１００８）。

また、図示しないが、上記のように通信路（第１の通信路、ＲＴＳＰ用ＱｏＳセッション、第２の通信路）が確立すると、タイムアウト監視部４０６が起動する。タイムアウト監視部４０６は、接続情報管理テーブル５００のタイマー５０４に設定した値を１秒毎にデクリメントし、タイマー５０４の値が０になった時点でタイムアウトと判定する。タイムアウトが発生すると、通信制御装置１０５は、上記で確立した各通信路を切断する。

なお、詳細は後述するが、タイマー５０４の値は、タイムアウトと判定される前に新たなＲＴＳＰメッセージを受信することで、タイムアウト５０３に設定した値にリセットされる。すなわち、タイムアウトとは、次のＲＴＳＰメッセージが到達するまでの待ち時間である。

図１１は、再生準備の際の動作の流れを示すシーケンス図である。これ以降、ＲＴＳＰクライアント機器とＲＴＳＰサーバ機器との間ではＲＴＳＰメッセージの送受信が行われる。ＲＴＳＰには、メッセージの送受信を行うための各種のメソッドが定義されている。例えば、ＯＰＴＩＯＮＳ、ＤＥＳＣＲＩＢＥ、ＳＥＴＵＰ、ＰＬＡＹ、ＰＡＵＳＥ、ＡＮＮＯＵＮＣＥ、ＴＥＡＲＤＯＷＮ等であり、それぞれについてリクエストとレスポンスのメソッドが定義されている。ＲＴＳＰクライアント機器やＲＴＳＰサーバ機器は、これらのメソッドを介して情報を送受信し、音声や映像等のコンテンツ再生に必要な情報の交換を行う。

図１１に示す再生準備の動作では、映像用ＱｏＳセッションの確立に必要な情報を収集する。すなわち、ＱｏＳセッション制御に必要なコンテンツの帯域情報、およびＱｏＳセッションの両端の機器のＩＰアドレスおよびポートの情報を収集する。このうち、コンテンツの帯域情報はＲＴＳＰ ＤＥＳＣＲＩＢＥレスポンス、ＩＰアドレスおよびポートの情報はＲＴＳＰ ＳＥＴＵＰレスポンスからそれぞれ取得することができる。

まず、映像受信表示装置１０７は、第１の通信路を介して通信制御装置１０５へとＲＴＳＰ ＤＥＳＣＲＩＢＥリクエストを送信する（１１０１）。ＲＴＳＰ ＤＥＳＣＲＩＢＥリクエストを受信した通信制御装置１０５は、接続情報管理テーブル５００のタイマー５０４の値をタイムアウト５０３の値にリセットする（１１０２）。なお、これ以降全てのメソッドについて、第１の通信路から情報を受信した際には必ずタイマーをリセットする。

次に、通信制御装置１０５は、取得したＲＴＳＰメッセージの内容を第２の通信路を介して映像配信サーバ１０２へと送信する（１１０３）。次に、映像配信サーバ１０２は、ＲＴＳＰ ＤＥＳＣＲＩＢＥリクエストの内容を元に処理を行い、応答をＲＴＳＰ ＤＥＳＣＲＩＢＥレスポンスとして第２の通信路を介して通信制御装置１０５へと送信する（１１０４）。

通信制御装置１０５は、ＲＴＳＰ ＤＥＳＣＲＩＢＥレスポンスを取得し、そこに含まれるコンテンツの情報のうちコンテンツのビットレートの情報を取得する。そして、映像データ受信情報テーブル９００をワークメモリ上に作成し、帯域９０４の項目にその値を記憶する（１１０５）。その後、通信制御装置１０５は、取得したＲＴＳＰ ＤＥＳＣＲＩＢＥレスポンスを、第１の通信路を介して映像受信表示装置１０７へと送信する（１１０６）。

次に、映像受信表示装置１０７は、ＲＴＳＰ ＳＥＴＵＰリクエストを第１の通信路を介して通信制御装置１０５へと送信する（１１０７）。通信制御装置１０５は、第１の通信路を介してＲＴＳＰ ＳＥＴＵＰリクエストを取得し、タイマーをリセットし（１１０８）、ＲＴＳＰ ＳＥＴＵＰリクエスト処理を行う（１１０９）。

すなわち、ＲＴＳＰ ＳＥＴＵＰリクエストを受信した通信制御装置１０５は、ＲＴＳＰ ＳＥＴＵＰリクエストから映像データ受信ポートであるclient_portの値を読み出し、映像データ受信情報テーブル９００のクライアントポート９０３に記憶する。次に、利用可能ポート番号テーブル６００および利用ポート番号テーブル７００を参照して利用可能なポートを決定し、これを通信制御装置１０５での映像データ受信ポートとして、ＲＴＳＰ ＳＥＴＵＰリクエストのclient_portの値をその値に書き換える。さらに、その値を映像データ受信情報テーブル９００の通信制御装置ポート９０１に記憶する。

次に、通信制御装置１０５は、ＲＴＳＰ ＳＥＴＵＰリクエストを第２の通信路を介して映像配信サーバ１０２へと送信し（１１１０）、その応答であるＲＴＳＰ ＳＥＴＵＰレスポンスを受信する（１１１１）。その後、通信制御装置１０５は、受信したＲＴＳＰ ＳＥＴＵＰレスポンスの内部処理を行う（１１１２）。

すなわち、ＲＴＳＰ ＳＥＴＵＰレスポンスに含まれるＲＴＳＰセッション情報のタイムアウト値を取得し、接続情報管理テーブル５００のタイムアウト５０３の値を、取得したタイムアウト値で上書きする。また、ＲＴＳＰ ＳＥＴＵＰレスポンスに含まれる映像データ送信ポートであるserver_portの値を読み出し、映像データ受信情報テーブル９００のサーバポート９０２に記憶する。

また、ＲＴＳＰ ＳＥＴＵＰレスポンスのclient_portの値を読み出し、この値が映像データ受信情報テーブル９００の通信制御装置ポート９０１の値と等しいかを確認する。等しくなければ、通信制御装置ポート９０１の値を取得したclient_portの値で上書きする。また、ＲＴＳＰ ＳＥＴＵＰレスポンスのclient_portの値を、映像データ受信情報テーブル９００のクライアントポート９０３の値に書き換える。

その後、映像データを映像受信表示装置１０７に伝送する為のポートフォワード設定を行う（１１１２）。すなわち、通信制御装置１０５の、映像データ受信情報テーブル９００の通信制御装置ポート９０１に記憶したポートに到達した映像データを、映像受信表示装置１０７の、映像データ受信情報テーブル９００のクライアントポート９０３に記憶したポートへとフォワードする為の設定を行う。

これは、例えば、通信制御装置１０５のオペレーティングシステムがＬｉｎｕｘの場合は、例えば、“iptables -t nat -A PREROUTING -p udp --dport [映像データ受信情報テーブル９００の通信制御装置ポート９０１の値] -j DNAT --to-destination [接続情報管理テーブル５００のクライアントアドレス５０１の値]:[映像データ受信情報テーブル９００のクライアントポート９０３の値]”のコマンドで設定することができる。

次に、通信制御装置１０５は、映像データ受信情報テーブル９００に記憶した内容を元に、帯域制御サーバ１０３に対して、映像配信サーバ１０２との間の映像用ＱｏＳセッションの確立要求を行う（１１１３）。すなわち、通信制御装置１０５のＩＰアドレスおよび映像データ受信情報テーブル９００の通信制御装置ポート９０１に記憶したポートと、映像配信サーバ１０２のＩＰアドレスおよび映像データ受信情報テーブル９００のサーバポート９０２に記憶したポートとの間に、映像データ受信情報テーブル９００の帯域９０４に設定された分の帯域を確保するように要求する。

映像用ＱｏＳセッションが確立したら、通信制御装置１０５は、接続情報管理テーブル５００の状態５０５を“Ｒｅａｄｙ”に変更し（１１１４）、ＲＴＳＰ ＳＥＴＵＰレスポンスを第１の通信路を介して映像受信表示装置１０７へと送信する（１１１５）。

図１２は、映像再生の際の動作の流れを示すシーケンス図である。まず、映像受信表示装置１０７は、ＲＴＳＰ ＰＬＡＹリクエストを、第１の通信路を介して通信制御装置１０５へと送信する（１２０１）。通信制御装置１０５は、ＲＴＳＰ ＰＬＡＹリクエストを受信し、タイマーをリセットし（１２０２）、第２の通信路を介してＲＴＳＰ ＰＬＡＹリクエストを映像配信サーバ１０２へと送信する（１２０３）。

その後、ＲＴＳＰ ＰＬＡＹレスポンスを受信し（１２０４）、接続情報管理テーブル５００の状態５０５を“Ｐｌａｙｉｎｇ”に変更して（１２０５）、ＲＴＳＰ ＰＬＡＹレスポンスを、第１の通信路を介して映像受信表示装置１０７へと送信する（１２０６）。

映像配信サーバ１０２は、ＲＴＳＰ ＰＬＡＹリクエストを受信すると、映像データの伝送を開始する（１２０７）。映像データは、映像配信サーバ１０２と通信制御装置１０５との間では、通信制御装置１０５がＲＴＳＰ ＳＥＴＵＰレスポンス受信時に確立した映像用ＱｏＳセッション内を伝送される。通信制御装置１０５が受信した映像データは、ＲＴＳＰ ＳＥＴＵＰレスポンス受信時に設定したポートフォワード設定に従って、映像受信表示装置１０７へと送信される（１２０７）。

映像データの伝送中、映像受信表示装置１０７は、ＲＴＳＰセッションがタイムアウトしない程度の間隔で、接続維持用のメッセージを通信制御装置１０５に送信する（１２０８）。これには通常、ＲＴＳＰの状態に変更を与えないＲＴＳＰ ＯＰＴＩＯＮＳメソッドか単純なハートビートを用いる。通信制御装置１０５は、これらの情報を受信した際はタイマーをリセットし（１２０９）、受信した情報を映像配信サーバ１０２へと送信する（１２１０）。

図１３は、再生停止の際の動作の流れを示すシーケンス図である。まず、映像受信表示装置１０７は、ＲＴＳＰ ＰＡＵＳＥリクエストを、第１の通信路を介して通信制御装置１０５へと送信する（１３０１）。通信制御装置１０５は、タイマーリセットを行い（１３０２）、ＲＴＳＰ ＰＡＵＳＥリクエストを第２の通信路を介して映像配信サーバ１０２へと送信する（１３０３）。

その後、ＲＴＳＰ ＰＡＵＳＥレスポンスを受信し（１３０４）、接続情報管理テーブル５００の状態５０５を“Ｒｅａｄｙ”に変更して（１３０５）、ＲＴＳＰ ＰＡＵＳＥレスポンスを、第１の通信路を介して映像受信表示装置１０７へと送信する（１３０６）。

次に、映像受信表示装置１０７は、ＲＴＳＰ ＴＥＡＲＤＯＷＮリクエストを第１の通信路を介して通信制御装置１０５へと送信する（１３０７）。通信制御装置１０５は、タイマーリセットを行い（１３０８）、ＲＴＳＰ ＴＥＡＲＤＯＷＮリクエストを第２の通信路を介して映像配信サーバ１０２へと送信する（１３０９）。ＲＴＳＰ ＴＥＡＲＤＯＷＮリクエストを受信した映像配信サーバ１０２は、映像データの伝送を終了し、ＲＴＳＰ ＴＥＡＲＤＯＷＮレスポンスを通信制御装置１０５に送信する（１３１０）。

次に、通信制御装置１０５は、帯域制御サーバ１０３に対し、映像配信サーバ１０２との間の映像用ＱｏＳセッションの終了要求を行い、映像用ＱｏＳセッションを終了する（１３１１）。その後、通信制御装置１０５は、ポートフォワード設定を解除し（１３１２）、映像データ受信情報テーブル９００の通信制御装置ポート９０１に記憶されている値を利用ポート番号テーブル７００から削除し、第２の通信路を切断する（１３１３）。

次に、通信制御装置１０５は、帯域制御サーバ１０３に対し、映像配信サーバ１０２との間のＲＴＳＰ用ＱｏＳセッションの終了要求を行い、ＲＴＳＰ用ＱｏＳセッションを終了する（１３１４）。その際、ＲＴＳＰ通信利用ポート番号テーブル８００のＲＴＳＰ通信利用ポート番号８０１に記憶されている値を利用ポート番号テーブル７００から削除する。

その後、接続情報管理テーブル５００の状態５０５を“接続なし”に設定し（１３１５）、第１の通信路を介してＲＴＳＰ ＴＥＡＲＤＯＷＮレスポンスを映像受信表示装置１０７へと送信する（１３１６）。その後、第１の通信路を切断し（１３１７）、コネクション内テーブルである接続情報管理テーブル５００、ＲＴＳＰ通信利用ポート番号テーブル８００、映像データ受信情報テーブル９００を削除する（１３１８）。

ここで、本実施の形態での通信制御方法における、通信制御装置１０５が記憶するＲＴＳＰコネクションの状態遷移について説明する。図１４は、本実施の形態におけるＲＴＳＰコネクションの状態遷移図である。また、図１５は、本実施の形態におけるＲＴＳＰコネクションの状態遷移テーブルを示す図である。図１４における遷移１〜７は、図１５におけるＮｏ．１〜７のイベントにそれぞれ対応している。

図１４において、まず最初は“コネクション無し”の状態である。“コネクション無し”状態にて、通信制御装置１０５がＲＴＳＰクライアント機器からの接続要求を受けて、第１の通信路の確立、ＲＴＳＰ用ＱｏＳセッションの確立、第２の通信路の確立を行うと、ＲＴＳＰコネクションは“Ｉｎｉｔ”状態に遷移する。

“Ｉｎｉｔ”状態にて、通信制御装置１０５がＲＴＳＰ ＳＥＴＵＰレスポンスを受信し、映像用ＱｏＳセッションが確立すると“Ｒｅａｄｙ”状態に遷移する。“Ｒｅａｄｙ”状態にて、通信制御装置１０５がＲＴＳＰ ＰＬＡＹレスポンスを受信すると“Ｐｌａｙｉｎｇ”状態に遷移する。“Ｐｌａｙｉｎｇ”状態にて、通信制御装置１０５がＲＴＳＰ ＰＡＵＳＥレスポンスを受信すると“Ｒｅａｄｙ”状態に遷移する。

また、“Ｐｌａｙｉｎｇ”状態にて、接続がタイムアウトする、もしくは通信制御装置１０５がＲＴＳＰ ＴＥＡＲＤＯＷＮレスポンスを受信すると、映像用ＱｏＳセッションおよびＲＴＳＰ用ＱｏＳセッションを終了し、“コネクション無し”状態に遷移する。“Ｒｅａｄｙ”状態にて、接続がタイムアウトする、もしくは通信制御装置１０５がＲＴＳＰ ＴＥＡＲＤＯＷＮレスポンスを受信すると、映像用ＱｏＳセッションおよびＲＴＳＰ用ＱｏＳセッションを終了し、“コネクション無し”状態に遷移する。“Ｉｎｉｔ”状態にて、接続がタイムアウトすると、ＲＴＳＰ用ＱｏＳセッションを終了し、“コネクション無し”状態に遷移する。

上述のように、通信制御装置１０５は、ＲＴＳＰコネクションについて、ＲＴＳＰセッションの状況とＲＴＳＰ用および映像用ＱｏＳセッションの状況とを統一的に表す“状態”を用いて管理する。この“状態”は、ＲＴＳＰコネクション毎に接続情報管理テーブル５００の状態５０５に記憶している。

次に、図１６〜図２４を用いて、本実施の形態の映像配信システムにおける通信制御装置１０５での個別の処理の流れを説明する。

図１６は、通信路確立の処理の流れを示すフローチャートである。まず、ステップＳ１６０１で、映像受信表示装置１０７から第１の通信路確立要求を受信する。次に、ステップＳ１６０２で、当該接続に関する接続情報管理テーブル５００を作成する。次に、ステップＳ１６０３で、第１の通信路の情報における接続元および接続先のＩＰアドレスを取得し、接続情報管理テーブル５００のクライアントアドレス５０１、サーバアドレス５０２に記憶する。

次に、ステップＳ１６０４で、システムで決めるタイムアウト時間を接続情報管理テーブル５００のタイムアウト５０３に記憶する。次に、ステップＳ１６０５で、後述する通信制御装置１０５の利用ポート決定の手順によりＲＴＳＰ通信利用ポートを決定し、ステップＳ１６０６で、決定したＲＴＳＰ通信利用ポートをＲＴＳＰ通信利用ポート番号テーブル８００に記憶する。その後、ステップＳ１６０７で、ＲＴＳＰ用ＱｏＳセッションを確立し、ステップＳ１６０８で、第２の通信路を確立する。

図１７は、ＲＴＳＰリクエストの処理の流れを示すフローチャートである。まず、ステップＳ１７０１で、第１の通信路を介して映像受信表示装置１０７からＲＴＳＰリクエストデータを受信する。次に、ステップＳ１７０２で、接続情報管理テーブル５００のタイマー５０４をリセットする。次に、ステップＳ１７０３で、受信したＲＴＳＰリクエストがＳＥＴＵＰリクエストかどうかを調べる。

受信したＲＴＳＰリクエストがＳＥＴＵＰリクエストである場合は、ステップＳ１７０４へ進み、ＳＥＴＵＰリクエストでない場合は、ステップＳ１７０５へ進む。ステップＳ１７０４では、後述するＳＥＴＵＰリクエスト処理を行い、ステップＳ１７０５へ進む。ステップＳ１７０５では、第２の通信路を介して映像配信サーバ１０２にＲＴＳＰリクエストデータを送信する。

図１８は、ＳＥＴＵＰリクエストのサブルーチンの処理の流れを示すフローチャートである。まず、ステップＳ１８０１で、受信したＲＴＳＰリクエストデータから映像データ受信ポートを取得し、映像データ受信情報テーブル９００のクライアントポート９０３に記憶する。

次に、ステップＳ１８０２で、後述する通信制御装置１０５の利用ポート決定の手順により、通信制御装置１０５の映像データ受信ポートを決定し、映像データ受信情報テーブル９００の通信制御装置ポート９０１に記憶する。次に、ステップＳ１８０３で、ＲＴＳＰリクエストデータの映像データ受信ポートを、ステップＳ１８０２で決定した通信制御装置１０５の映像データ受信ポートの値に書き換える。

図１９は、通信制御装置１０５の利用ポート決定のサブルーチンの処理の流れを示すフローチャートである。まず、ステップＳ１９０１で、通信制御装置１０５の利用可能ポート番号テーブル６００から、利用可能ポート番号範囲６０１を取得する。次に、ステップＳ１９０２で、通信制御装置１０５の利用ポート番号テーブル７００に記載の利用ポート番号７０１を全て取得する。次に、ステップＳ１９０３で、利用可能ポート番号範囲６０１のうち、利用ポート番号７０１に含まれない番号を１つ選択し、その番号を利用ポート番号テーブル７００に追記する。

図２０は、映像配信サーバ１０２からのＲＴＳＰレスポンスの処理の流れを示すフローチャートである。まず、ステップＳ２００１で、第２の通信路を介して映像配信サーバ１０２からＲＴＳＰレスポンスデータを受信する。次に、ステップＳ２００２で、受信したＲＴＳＰレスポンスがＤＥＳＣＲＩＢＥレスポンスかどうかを調べる。

受信したＲＴＳＰレスポンスがＤＥＳＣＲＩＢＥレスポンスである場合は、ステップＳ２００３へ進む。ＤＥＳＣＲＩＢＥレスポンスでない場合は、ステップＳ２００４へ進む。ステップＳ２００３では、後述するＤＥＳＣＲＩＢＥレスポンス処理を行い、ステップＳ２００８へ進む。ステップＳ２００４では、受信したＲＴＳＰレスポンスがＳＥＴＵＰレスポンスかどうかを調べる。

ステップＳ２００４で、受信したＲＴＳＰレスポンスがＳＥＴＵＰレスポンスである場合は、ステップＳ２００５へ進む。ＳＥＴＵＰレスポンスでない場合は、ステップＳ２００６へ進む。ステップＳ２００５では、後述するＳＥＴＵＰレスポンス処理を行い、ステップＳ２００８へ進む。ステップＳ２００６では、受信したＲＴＳＰレスポンスがＴＥＡＲＤＯＷＮレスポンスかどうかを調べる。

ステップＳ２００６で、受信したＲＴＳＰレスポンスがＴＥＡＲＤＯＷＮレスポンスである場合は、ステップＳ２００７へ進む。ＴＥＡＲＤＯＷＮレスポンスでない場合は、ステップＳ２００８へ進む。ステップＳ２００７では、後述するＴＥＡＲＤＯＷＮレスポンス処理を行い、ステップＳ２００８へ進む。ステップＳ２００８では、状態変更処理を行う。

次に、ステップＳ２００９で、第１の通信路を介して映像受信表示装置１０７へとＲＴＳＰレスポンスデータを送信する。次に、ステップＳ２０１０で、送信したＲＴＳＰレスポンスがＴＥＡＲＤＯＷＮレスポンスかどうかを調べる。送信したＲＴＳＰレスポンスがＴＥＡＲＤＯＷＮレスポンスである場合は、ステップＳ２０１１へ進む。ＴＥＡＲＤＯＷＮレスポンスでない場合は、処理を終了する。ステップＳ２０１１では、第１の通信路を切断し、次に、ステップＳ２０１２で、コネクション内テーブルである接続情報管理テーブル５００、ＲＴＳＰ通信利用ポート番号テーブル８００、映像データ受信情報テーブル９００を削除する。

図２１は、ＤＥＳＣＲＩＢＥレスポンスのサブルーチンの処理の流れを示すフローチャートである。まず、ステップＳ２１０１で、受信したＲＴＳＰレスポンスデータから映像のビットレート情報を取得する。次に、ステップＳ２１０２で、映像データ受信情報テーブル９００の帯域９０４に、取得したビットレート情報を記憶する。

図２２は、ＳＥＴＵＰレスポンスのサブルーチンの処理の流れを示すフローチャートである。まず、ステップＳ２２０１で、受信したＲＴＳＰレスポンスデータから映像データ受信ポートを取得する。次に、ステップＳ２２０２で、ステップＳ２２０１で取得した映像データ受信ポートが、映像データ受信情報テーブル９００の通信制御装置ポート９０１に記憶している値と同一であるかを確認する。同一である場合はステップＳ２２０４に進む。同一でない場合は、ステップＳ２２０３で、映像データ受信情報テーブル９００の通信制御装置ポート９０１を、ステップＳ２２０１で取得した映像データ受信ポートの値で上書きし、ステップＳ２２０４に進む。

ステップＳ２２０４では、受信したＲＴＳＰレスポンスデータから映像データ送信ポートを取得し、映像データ受信情報テーブル９００のサーバポート９０２に記憶する。次に、ステップＳ２２０５で、受信したＲＴＳＰレスポンスデータからＲＴＳＰセッションのタイムアウト時間を取得し、接続情報管理テーブル５００のタイムアウト５０３に上書きする。次に、ステップＳ２２０６で、受信したＲＴＳＰレスポンスデータの映像データ受信ポートを、映像データ受信情報テーブル９００のクライアントポート９０３の値で書き換える。

次に、ステップＳ２２０７で、接続情報管理テーブル５００のクライアントアドレス５０１と映像データ受信情報テーブル９００の情報を用いて、ポートフォワード設定を行う。次に、ステップＳ２２０６で、映像データ受信情報テーブル９００の情報を用いて、映像用ＱｏＳセッションを確立する。

図２３は、ＴＥＡＲＤＯＷＮレスポンスのサブルーチンの処理の流れを示すフローチャートである。まず、ステップＳ２３０１で、映像用ＱｏＳセッションを終了し、ステップＳ２３０２で、ポートフォワード設定を解除する。次に、ステップＳ２３０３で、第２の通信路を切断し、ステップＳ２３０４で、ＲＴＳＰ用ＱｏＳセッションを終了する。

図２４は、タイムアウト処理の流れを示すフローチャートである。まず、ステップＳ２４０１で、接続情報管理テーブル５００のタイマー５０４の値が０となったことを検知する。次に、ステップＳ２４０２で、接続情報管理テーブル５００の状態５０５が“Ｒｅａｄｙ”または“Ｐｌａｙｉｎｇ”かどうかを確認する。

接続情報管理テーブル５００の状態５０５が“Ｒｅａｄｙ”または“Ｐｌａｙｉｎｇ”でない場合は、ステップＳ２４０５へ進む。接続情報管理テーブル５００の状態５０５が“Ｒｅａｄｙ”または“Ｐｌａｙｉｎｇ”である場合は、ステップＳ２４０３へ進む。ステップＳ２４０３では、映像用ＱｏＳセッションを終了し、ステップＳ２４０４で、ポートフォワード設定を解除し、ステップＳ２４０５へ進む。

ステップＳ２４０５では、第２の通信路を切断し、ステップＳ２４０６で、ＲＴＳＰ用ＱｏＳセッションを終了する。次に、ステップＳ２４０７で、第１の通信路を切断し、ステップＳ２４０８で、コネクション内テーブルである接続情報管理テーブル５００、ＲＴＳＰ通信利用ポート番号テーブル８００、映像データ受信情報テーブル９００を削除する。

以上に説明したような本実施の形態における通信制御装置１０５は、ホームネットワーク１０６に接続する複数のＲＴＳＰクライアント機器からの接続を別個に管理することができる。例えば、映像受信表示装置１０７が映像再生中に、新たに映像受信表示装置１０８が接続した場合、映像受信表示装置１０８と通信制御装置１０５との間には新たな第１の通信路が確立され、通信制御装置１０５と映像配信サーバ１０２の間にも新たな第２の通信路が確立される。

接続情報管理テーブル５００、ＲＴＳＰ通信利用ポート番号テーブル８００、映像データ受信情報テーブル９００といったコネクション内テーブルは、接続毎にワークメモリ上に確保される為、それぞれの接続による状態遷移や接続情報は別個に管理することができる。

また同様に、本実施の形態における通信制御装置１０５は、ホームネットワーク１０６に接続する１台のＲＴＳＰクライアント機器から複数の接続が行われた場合、それぞれの接続を別個に管理することができる。例えば、映像受信表示装置１０７上のアプリケーションＡが映像再生中に、新たに映像受信表示装置１０７上のアプリケーションＢが接続した場合、映像受信表示装置１０７上のアプリケーションＢと通信制御装置１０５との間には新たな第１の通信路が確立され、通信制御装置１０５と映像配信サーバ１０２の間にも新たな第２の通信路が確立される。

すなわち、通信制御装置１０５は、ホームネットワーク１０６に接続する複数のＲＴＳＰクライアント機器（同一機器内で動作する別アプリケーションも含む）のＱｏＳセッション制御を一元的に管理することができ、ホームネットワーク１０６に接続するＱｏＳセッション制御機能を有しない全てのＲＴＳＰクライアント機器に対して、ＱｏＳ保証型のコンテンツ配信サービスを提供することができる。

なお、本実施の形態の映像配信システムにおいて、通信制御装置１０５は、ＲＴＳＰ用ＱｏＳセッションおよび映像用ＱｏＳセッションの２種類のＱｏＳセッションを管理するが、ＲＴＳＰメッセージの送受信そのものは映像データの伝送に比べるとリアルタイム性が必要とされず、また伝送データ量も小さい。そのため、ＲＴＳＰ用ＱｏＳセッションを確立しない構成としても良い。この場合、ＲＴＳＰメッセージの送受信はＢＥ（Best Effort）通信で行われることになる。方法としては、上述した手順のうち、ＲＴＳＰ用ＱｏＳセッションに関する手順を省略することによって実現できる。

また、本実施の形態における映像配信システムでは、上述した通信制御方法を、通信制御装置１０５、すなわちネットワーク１０１とホームネットワーク１０６とのゲートウェイとなる機器上に実装して動作させる構成としたが、このようなゲートウェイ機器以外、例えば、デジタルテレビやＳＴＢ、ＨＤＤレコーダ等に実装しても良い。

ただし、この場合は、ＲＴＳＰメッセージ取得方法として、上述の第１のＲＴＳＰメッセージ取得方法を用いる必要がある。すなわち、ＲＴＳＰクライアント機器にＲＴＳＰプロキシ設定が可能であり、ＲＴＳＰプロキシとして、上述した通信制御方法が実装されているデジタルテレビやＳＴＢ、ＨＤＤレコーダを指定することになる。

また、この場合でも、映像データの伝送の為のポートフォワード設定はゲートウェイ機器に行う必要があり、デジタルテレビやＳＴＢ、ＨＤＤレコーダ等から、ホームネットワーク１０６を介して、ゲートウェイ機器に対してポートフォワード設定を行う必要がある。このようなネットワークを介したポートフォワード設定は、例えばＵＰｎＰ（Universal Plug and Play）等の技術を用いて実現することが可能である。

以上に説明したように、本実施の形態における通信制御装置１０５によれば、通信制御装置１０５でＱｏＳセッション制御を一元的に管理・実行することにより、ＱｏＳ制御手段を有しない映像受信表示装置１０７、１０８を用いて、通信制御装置１０５と映像配信サーバ１０２との間のＱｏＳ制御セッションの確立が可能であり、ユーザにとって映像受信表示装置１０７、１０８をＱｏＳ制御可能なものに置き換えるコストが不要となり、管理コストも小さい帯域保証型コンテンツ配信システムを実現することができる。

また、通信制御装置１０５を介して送受信されるＲＴＳＰメッセージから帯域制御のための情報を取得して生成することができるため、コンテンツ配信サービス提供者にとっては、コンテンツ毎の帯域情報を別途管理する等の仕組みが不要となり、帯域制御を用いたコンテンツ配信サービスを、帯域制御およびコンテンツ配信に必要な制御のみ行う映像配信サーバ１０２で行うことが可能となる。

また、通信制御装置１０５を介して送受信されるＲＴＳＰメッセージのみから、情報を取得してポートフォワードの設定を行うことにより、ＮＡＴ越えを実現することが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、通信制御装置ならびに通信制御方法に利用可能であり、特に、ＲＴＳＰ（Real Time Streaming Protocol）を用いて映像、音楽等のコンテンツの再生制御を行うストリーミング型コンテンツ配信サービスに用いられる通信制御装置ならびに通信制御方法に利用可能である。

本発明の一実施の形態である映像配信システムの構成の一例を示す図である。 本発明の一実施の形態における通信制御装置のハードウェア構成の一例を示す図である。 本発明の一実施の形態における映像受信表示装置のハードウェア構成の一例を示す図である。 本発明の一実施の形態における通信制御装置の機能構成の概要を示す図である。 本発明の一実施の形態における接続情報管理テーブルの構成とデータの例を示す図である。 本発明の一実施の形態における利用可能ポート番号テーブルの構成とデータの例を示す図である。 本発明の一実施の形態における利用ポート番号テーブルの構成とデータの例を示す図である。 本発明の一実施の形態におけるＲＴＳＰ通信利用ポート番号テーブルの構成とデータの例を示す図である。 本発明の一実施の形態における映像データ受信情報テーブルの構成とデータの例を示す図である。 本発明の一実施の形態における通信路の確立の際の動作の流れを示すシーケンス図である。 本発明の一実施の形態における再生準備の際の動作の流れを示すシーケンス図である。 本発明の一実施の形態における映像再生の際の動作の流れを示すシーケンス図である。 本発明の一実施の形態における再生停止の際の動作の流れを示すシーケンス図である。 本発明の一実施の形態におけるＲＴＳＰコネクションの状態遷移図である。 本発明の一実施の形態におけるＲＴＳＰコネクションの状態遷移テーブルを示す図である。 本発明の一実施の形態における通信路確立の処理の流れを示すフローチャートである。 本発明の一実施の形態におけるＲＴＳＰリクエストの処理の流れを示すフローチャートである。 本発明の一実施の形態におけるＳＥＴＵＰリクエストのサブルーチンの処理の流れを示すフローチャートである。 本発明の一実施の形態における通信制御装置の利用ポート決定のサブルーチンの処理の流れを示すフローチャートである。 本発明の一実施の形態における映像配信サーバからのＲＴＳＰレスポンスの処理の流れを示すフローチャートである。 本発明の一実施の形態におけるＤＥＳＣＲＩＢＥレスポンスのサブルーチンの処理の流れを示すフローチャートである。 本発明の一実施の形態におけるＳＥＴＵＰレスポンスのサブルーチンの処理の流れを示すフローチャートである。 本発明の一実施の形態におけるＴＥＡＲＤＯＷＮレスポンスのサブルーチンの処理の流れを示すフローチャートである。 本発明の一実施の形態におけるタイムアウト処理の流れを示すフローチャートである。

符号の説明

１０１…ネットワーク、１０２…映像配信サーバ、１０３…帯域制御サーバ、１０４…ユーザ宅、１０５…通信制御装置、１０６…ホームネットワーク、１０７…映像受信表示装置、１０８…映像受信表示装置、
２０１…ＣＰＵ、２０２…メインメモリ、２０３…ＥＰＲＯＭ、２０４…第１ネットワークＩ／Ｆ、２０５…第２ネットワークＩ／Ｆ、２０６…不揮発性記憶装置、２０７…バス、
３０１…ＣＰＵ、３０２…メインメモリ、３０３…ＥＰＲＯＭ、３０４…出力装置、３０５…ネットワークＩ／Ｆ、３０６…不揮発性記憶装置、３０７…入力装置、３０８…映像再生装置、３０９…バス、
４０１…ルーティング部、４０２…メッセージ取得部、４０３…ＱｏＳ制御情報生成部、４０４…ＱｏＳ制御部、４０５…テーブル群、４０６…タイムアウト監視部、
５００…接続情報管理テーブル、５０１…クライアントアドレス、５０２…サーバアドレス、５０３…タイムアウト、５０４…タイマー、５０５…状態、
６００…利用可能ポート番号テーブル、６０１…利用可能ポート番号範囲、
７００…利用ポート番号テーブル、７０１…利用ポート番号、
８００…ＲＴＳＰ通信利用ポート番号テーブル、８０１…ＲＴＳＰ通信利用ポート番号、
９００…映像データ受信情報テーブル、９０１…通信制御装置ポート、９０２…サーバポート、９０３…クライアントポート、９０４…帯域。

Claims (18)

1. ＲＴＳＰを用いてコンテンツを配信するストリーミング型コンテンツ配信サービスにおいて、ホームネットワークとＱｏＳ制御可能な外部ネットワークとの間に設置される通信制御装置であって、
   前記ホームネットワークに接続するＲＴＳＰクライアント機器と、前記ＱｏＳ制御可能な外部ネットワークに接続するＲＴＳＰサーバ機器との間で該通信制御装置を経由して送受信されるＲＴＳＰメッセージを取得するメッセージ取得部と、
   前記メッセージ取得部にて取得した前記ＲＴＳＰメッセージから、ＱｏＳ制御に必要な情報である、前記コンテンツのビットレートと、前記ＲＴＳＰクライアント機器のＩＰアドレスと、前記ＲＴＳＰクライアント機器の映像データ受信ポートと、前記ＲＴＳＰサーバ機器のＩＰアドレスと、前記ＲＴＳＰサーバ機器の映像データ送信ポートとを取得するＱｏＳ制御情報生成部と、
   前記ＱｏＳ制御情報生成部にて前記ＲＴＳＰメッセージから取得したＱｏＳ制御に必要な情報を元に、前記ＲＴＳＰサーバ機器との間で映像伝送用のＱｏＳセッションを確立するＱｏＳ制御部とを有することを特徴とする通信制御装置。
2. 請求項１記載の通信制御装置において、
   前記メッセージ取得部は、該通信制御装置におけるポートのリダイレクト設定によって、前記ＲＴＳＰメッセージを取得することを特徴とする通信制御装置。
3. 請求項１記載の通信制御装置において、
   前記ＱｏＳ制御情報生成部は、前記コンテンツのビットレートを、前記ＲＴＳＰメッセージの内のＤＥＳＣＲＩＢＥレスポンスメッセージから取得することを特徴とする通信制御装置。
4. 請求項１記載の通信制御装置において、
   前記ＱｏＳ制御情報生成部は、前記ＲＴＳＰクライアント機器の映像データ受信ポートを、前記ＲＴＳＰメッセージの内のＳＥＴＵＰリクエストメッセージから取得することを特徴とする通信制御装置。
5. 請求項１記載の通信制御装置において、
   前記ＱｏＳ制御情報生成部は、前記ＲＴＳＰサーバ機器の映像データ送信ポートを、前記ＲＴＳＰメッセージの内のＳＥＴＵＰレスポンスメッセージから取得することを特徴とする通信制御装置。
6. 請求項１記載の通信制御装置において、
   前記ＲＴＳＰサーバ機器との間の前記ＲＴＳＰメッセージの送受信を、ＲＴＳＰメッセージ送受信用のＱｏＳセッションを確立して行うことを特徴とする通信制御装置。
7. 請求項１記載の通信制御装置において、
   前記ＲＴＳＰクライアント機器と該通信制御装置との間、および該通信制御装置と前記ＲＴＳＰサーバ機器との間の通信に関する接続情報と、
   前記ＲＴＳＰクライアント機器と該通信制御装置との間、および該通信制御装置と前記ＲＴＳＰサーバ機器との間のＲＴＳＰセッションに関する情報と、
   該通信制御装置と前記ＲＴＳＰサーバ機器との間の映像伝送用のＱｏＳセッションに関する情報とを元に、
   前記ＲＴＳＰクライアント機器と前記ＲＴＳＰサーバ機器との間の前記コンテンツの配信に係るＲＴＳＰコネクションについての状態を一意に決定して管理することを特徴とする通信制御装置。
8. 請求項１記載の通信制御装置において、
   該通信制御装置と前記ＲＴＳＰサーバ機器との間のＲＴＳＰセッションにおけるタイムアウト値に基づいて、前記ＲＴＳＰクライアント機器と該通信制御装置との間のＲＴＳＰセッションのタイムアウトを監視するタイムアウト監視部を有し、
   タイムアウトを検知した場合は、前記ＲＴＳＰクライアント機器と前記ＲＴＳＰサーバ機器との間の前記コンテンツの配信に係るＲＴＳＰコネクションを終了することを特徴とする通信制御装置。
9. 請求項１記載の通信制御装置において、
   前記ＱｏＳ制御情報生成部にて取得した、前記ＲＴＳＰクライアント機器のＩＰアドレスと、前記ＲＴＳＰクライアント機器の映像データ受信ポートとを元に、
   前記ＲＴＳＰサーバ機器から送信された前記コンテンツを前記ＲＴＳＰクライアント機器へ伝送するためのポートフォワード設定を行うことを特徴とする通信制御装置。
10. ＲＴＳＰを用いてコンテンツを配信するストリーミング型コンテンツ配信サービスにおいて、ホームネットワークとＱｏＳ制御可能な外部ネットワークとの間に設置される通信制御装置における通信制御方法であって、
    前記通信制御装置は、
    前記ホームネットワークに接続するＲＴＳＰクライアント機器と、前記ＱｏＳ制御可能な外部ネットワークに接続するＲＴＳＰサーバ機器との間で前記通信制御装置を経由して送受信されるＲＴＳＰメッセージを取得し、
    前記ＲＴＳＰメッセージから、ＱｏＳ制御に必要な情報である、前記コンテンツのビットレートと、前記ＲＴＳＰクライアント機器のＩＰアドレスと、前記ＲＴＳＰクライアント機器の映像データ受信ポートと、前記ＲＴＳＰサーバ機器のＩＰアドレスと、前記ＲＴＳＰサーバ機器の映像データ送信ポートとを取得し、
    前記ＲＴＳＰメッセージから取得したＱｏＳ制御に必要な情報を元に、前記ＲＴＳＰサーバ機器との間で映像伝送用のＱｏＳセッションを確立することを特徴とする通信制御方法。
11. 請求項１０記載の通信制御方法において、
    前記通信制御装置は、
    前記ＲＴＳＰメッセージを取得する際に、前記通信制御装置におけるポートのリダイレクト設定によって、前記ＲＴＳＰメッセージを取得することを特徴とする通信制御方法。
12. 請求項１０記載の通信制御方法において、
    前記通信制御装置は、
    前記ＲＴＳＰメッセージからＱｏＳ制御に必要な情報を取得する際に、前記コンテンツのビットレートを、前記ＲＴＳＰメッセージの内のＤＥＳＣＲＩＢＥレスポンスメッセージから取得することを特徴とする通信制御方法。
13. 請求項１０記載の通信制御方法において、
    前記通信制御装置は、
    前記ＲＴＳＰメッセージからＱｏＳ制御に必要な情報を取得する際に、前記ＲＴＳＰクライアント機器の映像データ受信ポートを、前記ＲＴＳＰメッセージの内のＳＥＴＵＰリクエストメッセージから取得することを特徴とする通信制御方法。
14. 請求項１０記載の通信制御方法において、
    前記通信制御装置は、
    前記ＲＴＳＰメッセージからＱｏＳ制御に必要な情報を取得する際に、前記ＲＴＳＰサーバ機器の映像データ送信ポートを、前記ＲＴＳＰメッセージの内のＳＥＴＵＰレスポンスメッセージから取得することを特徴とする通信制御方法。
15. 請求項１０記載の通信制御方法において、
    前記通信制御装置は、
    前記ＲＴＳＰサーバ機器との間の前記ＲＴＳＰメッセージの送受信を、ＲＴＳＰメッセージ送受信用のＱｏＳセッションを確立して行うことを特徴とする通信制御方法。
16. 請求項１０記載の通信制御方法において、
    前記通信制御装置は、
    前記ＲＴＳＰクライアント機器と前記通信制御装置との間、および前記通信制御装置と前記ＲＴＳＰサーバ機器との間の通信に関する接続情報と、
    前記ＲＴＳＰクライアント機器と前記通信制御装置との間、および前記通信制御装置と前記ＲＴＳＰサーバ機器との間のＲＴＳＰセッションに関する情報と、
    前記通信制御装置と前記ＲＴＳＰサーバ機器との間の映像伝送用のＱｏＳセッションに関する情報とを元に、
    前記ＲＴＳＰクライアント機器と前記ＲＴＳＰサーバ機器との間の前記コンテンツの配信に係るＲＴＳＰコネクションについての状態を一意に決定して管理することを特徴とする通信制御方法。
17. 請求項１０記載の通信制御方法において、
    前記通信制御装置は、
    前記ＲＴＳＰサーバ機器との間のＲＴＳＰセッションにおけるタイムアウト値に基づいて、前記ＲＴＳＰクライアント機器との間のＲＴＳＰセッションのタイムアウトを監視するタイムアウト監視部を有し、
    タイムアウトを検知した場合は、前記ＲＴＳＰクライアント機器と前記ＲＴＳＰサーバ機器との間の前記コンテンツの配信に係るＲＴＳＰコネクションを終了することを特徴とする通信制御方法。
18. 請求項１０記載の通信制御方法において、
    前記通信制御装置は、
    前記ＲＴＳＰメッセージから取得した、前記ＲＴＳＰクライアント機器のＩＰアドレスと、前記ＲＴＳＰクライアント機器の映像データ受信ポートとを元に、
    前記ＲＴＳＰサーバ機器から送信された前記コンテンツを前記ＲＴＳＰクライアント機器へ伝送するためのポートフォワード設定を行うことを特徴とする通信制御方法。

Images