(57)【要約】【課題】ストリームデータを送受信する場合のネットワーク帯域を効率的に利用する中継装置を提供すること。【解決手段】ストリーム送信装置２とストリーム受信装置３との間のストリームデータの送受信のために用いる通信が確立されているか否かを表す通信状態を記憶する通信状態記憶部１２１と、ストリーム受信装置３がネットワーク６から切断されたか否かを検知する切断検知部１０３と、ストリーム受信装置３がネットワーク６から切断されたことが検知され、かつ、通信が確立されていることを表すか否かを判断する異常終了判断部１０４と、ストリーム受信装置３がネットワーク６から切断されたことが検知され、かつ、通信が確立されていることを表すと判断された場合に、通信終了要求メッセージをストリーム送信装置２に送信する終了要求送信部１０５と、を備えた。【選択図】        図１
2010081067.tif 000002
【特許請求の範囲】
【請求項１】
ストリームデータを送信する送信装置と第１ネットワークを介して接続され、前記ストリームデータを受信する受信装置と第２ネットワークを介して接続され、前記送信装置と前記受信装置との間で前記ストリームデータを中継する中継装置であって、
前記送信装置と前記受信装置との間の前記ストリームデータの送受信のために用いる通信が確立されているか否かを表す通信状態を記憶する通信状態記憶部と、
前記受信装置が前記第２ネットワークから切断されたことを検知する切断検知部と、
前記切断検知部で切断されたことが検知された場合に、前記通信が確立されていることを表すか否かを判断する判断部と、
前記判断部で通信が確立されていることを表すと判断された場合に、通信の終了を要求する要求メッセージを前記送信装置に送信する送信部とを備えたことを特徴とする中継装置。
【請求項２】
前記切断検知部は、前記第２ネットワークに接続されていることを確認する確認メッセージをマルチキャストで前記第２ネットワークに送信し、前記確認メッセージに対する応答メッセージを前記受信装置から受信したか否かを判断し、受信しなかった場合に、前記受信装置が前記第２ネットワークから切断されたことを検知することを特徴とする請求項１に記載の中継装置。
【請求項３】
前記確認メッセージは、ＡＲＰ（Address Resolution Protocol）、ＮＤＰ（Neighbor Discovery Protocol）、ＬＬＤＰ（Link Layer Discovery Protocol）、ＬＬＴＤ（Link Layer Topology Discovery）、またはＵＰｎＰ  ＳＳＤＰ（Universal Plug and Play Simple Service Discovery Protocol）に準拠したメッセージであることを特徴とする請求項２に記載の中継装置。
【請求項４】
前記切断検知部は、前記受信装置との間で接続確認用の通信を確立し、接続確認用の通信が切断された否かを判断し、切断された場合に、前記受信装置が前記第２ネットワークから切断されたことを検知することを特徴とする請求項１に記載の中継装置。
【請求項５】
前記通信状態記憶部は、前記送信装置と前記受信装置との間の前記ストリームデータの送受信のために用いる複数の通信のそれぞれについて前記通信状態を記憶し、
前記判断部は、前記受信装置が切断されたことが検知された場合に、前記複数の通信のうち、少なくとも１つの通信が確立されていることを表すか否かを判断し、
前記送信部は、前記複数の通信のうち、少なくとも１つの通信が確立されていることを表すと前記判断部で判断された場合に、確立されている前記通信の終了を要求する前記要求メッセージを前記送信装置に送信することを特徴とする請求項１に記載の中継装置。
【請求項６】
前記送信部は、前記複数の通信の前記要求メッセージを送信する場合に、前記複数の通信のうち、後に確立した通信を優先して前記要求メッセージを送信することを特徴とする請求項５に記載の中継装置。
【請求項７】
前記ストリームデータの送受信のために用いる通信は、ＲＴＳＰ（Real Time Streaming Protocol）を含む、前記ストリームデータの再生を制御するプロトコルに準拠した通信であることを特徴とする請求項１に記載の中継装置。
【請求項８】
前記送信装置と前記受信装置との間で送受信される前記ストリームデータはマルチキャストで送受信するストリームデータであり、
前記ストリームデータの送受信のために用いる通信は、ＩＧＭＰ（Internet Group Management Protocol）およびＭＬＤ（Multicast Listener Discovery）を含む、前記ストリームデータを送信するマルチキャストストリームを制御するプロトコルに準拠した通信であることを特徴とする請求項１に記載の中継装置。
【請求項９】
前記ストリームデータの送受信のために用いる通信は、ＳＩＰ（Session Initiation Protocol）およびＲＳＶＰ（Resource Reservation Protocol）を含む、前記ストリームデータを送受信する通信の帯域を制御するプロトコルに準拠した通信であることを特徴とする請求項１に記載の中継装置。
【請求項１０】
前記ストリームデータの送信が中断された位置を特定する位置情報を記憶可能な中断状態記憶部をさらに備え、
前記送信部は、さらに、前記要求メッセージを送信したときに前記位置情報を前記中断状態記憶部に保存し、前記送信装置と前記受信装置との間の前記ストリームデータの送受信のために用いる通信が再度確立されたときに、保存されている前記位置情報を前記受信装置に送信することを特徴とする請求項１に記載の中継装置。
【請求項１１】
ストリームデータを送信する送信装置と第１ネットワークを介して接続され、前記ストリームデータを受信する受信装置と第２ネットワークを介して接続され、前記送信装置と前記受信装置との間で前記ストリームデータを中継する中継装置で実行される中継方法であって、
前記中継装置は、前記送信装置と前記受信装置との間の前記ストリームデータの送受信のために用いる通信が確立されているか否かを表す通信状態を記憶する通信状態記憶部を備え、
切断検知部が、前記受信装置が前記第２ネットワークから切断されたことを検知する切断検知ステップと、
判断部が、前記切断検知部で切断されたことが検知された場合に、前記通信が確立されていることを表すか否かを判断する判断ステップと、
送信部が、前記判断部で通信が確立されていることを表すと判断された場合に、通信の終了を要求する要求メッセージを前記送信装置に送信する送信ステップとを備えたことを特徴とする中継方法。
【請求項１２】
ストリームデータを送信する送信装置と第１ネットワークを介して接続され、前記ストリームデータを受信する受信装置と第２ネットワークを介して接続され、前記送信装置と前記受信装置との間で前記ストリームデータを中継する中継装置で実行される中継プログラムであって、
前記中継装置は、前記送信装置と前記受信装置との間の前記ストリームデータの送受信のために用いる通信が確立されているか否かを表す通信状態を記憶する通信状態記憶部を備え、
前記中継装置を、
前記受信装置が前記第２ネットワークから切断されたことを検知する切断検知部と、
前記切断検知部で切断されたことが検知された場合に、前記通信が確立されていることを表すか否かを判断する判断部と、
前記判断部で通信が確立されていることを表すと判断された場合に、前記通信の終了を要求する要求メッセージを前記送信装置に送信する送信部として機能させるための中継プログラム。
【請求項１３】
ネットワークを介して接続された送信装置からストリームデータを受信する受信装置であって、
前記ストリームデータの送受信のために用いる通信が確立されているか否かを表す通信状態と、前記通信状態を記憶した記憶日時とを記憶する通信状態記憶部と、
前記受信装置が起動されたときに、現在の日時と前記記憶日時との差分が予め定められた期間より小さいか否か、かつ、前記通信が確立されていることを表すか否かを判断する判断部と、
前記判断部で、前記差分が前記期間より小さく、かつ、前記通通信が確立されていることを表すと判断された場合に、前記通信の終了を要求する要求メッセージを前記送信装置に送信する送信部とを備えたことを特徴とする受信装置。
【請求項１４】
前記通信状態記憶部は、前記ストリームデータの送受信のために用いる複数の通信のそれぞれについて前記通信状態を記憶し、
前記判断部は、前記受信装置が起動されたときに、現在の日時と前記記憶日時との差分が予め定められた期間より小さいか否か、かつ、前記複数の通信のうち、少なくとも１つの前記通信が確立されていることを表すか否かを判断し、
前記送信部は、前記差分が前記期間より小さく、かつ、前記複数の通信のうち、少なくとも１つの前記通信が確立されていることを表すと前記判断部で判断された場合に、確立されている前記通信の終了を要求する前記要求メッセージを前記送信装置に送信することを特徴とする請求項１３に記載の受信装置。
【請求項１５】
前記送信部は、前記複数の通信の前記要求メッセージを送信する場合に、前記複数の通信のうち、後に確立した通信を優先して前記要求メッセージを送信することを特徴とする請求項１４に記載の受信装置。
【請求項１６】
前記ストリームデータの送受信のために用いる通信は、ＲＴＳＰ（Real Time Streaming Protocol）を含む、前記ストリームデータの再生を制御するプロトコルに準拠した通信であることを特徴とする請求項１３に記載の受信装置。
【請求項１７】
前記送信装置と前記受信装置との間で送受信される前記ストリームデータはマルチキャストで送受信するストリームデータであり、
前記ストリームデータの送受信のために用いる通信は、ＩＧＭＰ（Internet Group Management Protocol）およびＭＬＤ（Multicast Listener Discovery）を含む、前記ストリームデータを送信するマルチキャストストリームを制御するプロトコルに準拠した通信であることを特徴とする請求項１３に記載の受信装置。
【請求項１８】
前記ストリームデータの送受信のために用いる通信は、ＳＩＰ（Session Initiation Protocol）およびＲＳＶＰ（Resource Reservation Protocol）を含む、前記ストリームデータを送受信する通信の帯域を制御するプロトコルに準拠した通信であることを特徴とする請求項１３に記載の受信装置。
【請求項１９】
前記ストリームデータの送信が中断された位置を特定する位置情報を記憶可能な中断状態記憶部をさらに備え、
前記送信部は、さらに、前記要求メッセージを送信したときに前記位置情報を前記中断状態記憶部に保存し、前記送信装置と前記受信装置との間の前記ストリームデータの送受信のために用いる通信が再度確立されたときに、保存されている前記位置情報を前記受信装置に送信することを特徴とする請求項１３に記載の受信装置。
【請求項２０】
ネットワークを介して接続された送信装置からストリームデータを受信する受信装置で実行される通信終了方法であって、
前記受信装置は、前記ストリームデータの送受信のために用いる通信が確立されているか否かを表す通信状態と、前記通信状態を記憶した記憶日時とを記憶する通信状態記憶部を備え、
判断部が、前記受信装置が起動されたときに、現在の日時と前記記憶日時との差分が予め定められた期間より小さいか否か、かつ、前記通信が確立されていることを表すか否かを判断する判断ステップと、
送信部が、前記差分が前記期間より小さく、かつ、前記通信が確立されていることを表すと前記判断部で判断された場合に、前記通信の終了を要求する要求メッセージを前記送信装置に送信する送信ステップとを備えたことを特徴とする通信終了方法。
【請求項２１】
ネットワークを介して接続された送信装置からストリームデータを受信する受信装置で実行される通信終了プログラムであって、
前記受信装置は、前記ストリームデータの送受信のために用いる通信が確立されているか否かを表す通信状態と、前記通信状態を記憶した記憶日時とを記憶する通信状態記憶部を備え、
前記受信装置を、
前記受信装置が起動されたときに、現在の日時と前記記憶日時との差分が予め定められた期間より小さいか否か、かつ、前記通信が確立されていることを表すか否かを判断する判断部と、
前記差分が前記期間より小さく、かつ、前記通信が確立されていることを表すと前記判断部で判断された場合に、前記通信の終了を要求する要求メッセージを前記送信装置に送信する送信部として機能させるための通信終了プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ストリームデータを送信する送信装置と受信装置との間でメッセージを中継する中継装置、中継方法、中継プログラム、受信装置、通信終了方法および通信終了プログラムに関する。
【背景技術】
【０００２】
近年、ＩＰ網を利用して高品質の映像コンテンツを提供するＶｏＤ（Video on Demand）サービスやＩＰ放送サービスが普及し始めている。前者のＶｏＤサービスについては、コンテンツの再生、一時停止、早送り、および早戻しなどの再生制御のためにＲＴＳＰ（Real Time Streaming Protocol）というシグナリング通信プロトコルが利用されている。
【０００３】
一方、後者のＩＰ放送サービスについても、ＩＰマルチキャストが利用されるため、ＩＧＭＰ（Internet Group Management Protocol）やＭＬＤ（Multicast Listener Discovery）というプロトコルがマルチキャストストリームの受信制御に利用されている。
【０００４】
また、高品質の映像コンテンツ伝送に１０Ｍｂｐｓを超える帯域が利用される可能性があるため、ＩＰ電話の呼制御プロトコルであるＳＩＰ（Session Initiation Protocol）を、映像コンテンツストリームの帯域制御に利用する検討も進められており、実際に運用される可能性が高い。
【０００５】
ＲＴＳＰやＳＩＰ等のプロトコルは、クライアント・サーバ間で通信セッションの状態情報を持つ。すなわち、ステートフルなシグナリング通信プロトコルであるといえる。このように、ＶｏＤサービスやＩＰＴＶ（Internet Protocol Television）サービスを含むＩＰ放送サービスでは、ストリーム（再生）制御や帯域保証のために、ステートフルなシグナリング通信が一般的に利用されている。
【０００６】
特開２００６−９４３３８では、中断中のストリーミングセッションが維持され続けることを防止して、ストリーミング再生を行うことができなくなるユーザが発生するのを抑制する技術が提案されている。
【０００７】
【特許文献１】特開２００６−９４３３８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、ステートフルなシグナリング通信プロトコルでは、不正に電源が切断された場合などに通信帯域を無駄に消費するという問題があった。例えば、ステートフルなシグナリング通信プロトコルを利用するデジタルテレビやＳＴＢ（Set Top Box）などのＩＰＴＶサービスの受信装置が、瞬断の影響などにより、急に電源オフ状態に遷移したとする。このような場合、受信装置は、送信装置との間で正常なシグナリング通信の終了シーケンスを経ることができないため、例えば以下のような問題が発生し得る。
【０００９】
第１に、ストリーム通信に利用されている帯域が、プロトコルごとに定められた一定期間解放されない。ＩＧＭＰのクエリ間隔、ＲＴＳＰのキープアライブ間隔、または、ＳＩＰ通信のセッション有効期限間隔などが、この一定期間に相当する。例えば、１５Ｍｂｐｓの映像ストリームをＩＰ放送として受信している際に、デジタルテレビの主電源を落とすと、ＩＧＭＰのクエリ間隔（例えば１分間）の期間、視聴していないストリームがホームネットワークの通信帯域を占有することになる。
【００１０】
第２に、電源オフ直後に電源を投入し、再生を要求した場合、二重の帯域確保とみなされる。これは、デジタルテレビのようなコンシューマ機器では、頻繁に行われる操作である。この場合、例えば一時的に１５Ｍｂｐｓのストリーム２本分に相当する、合計３０Ｍｂｐｓの帯域が、受信装置を含めたサブネットで占有されることになる。
【００１１】
上記特許文献１の方法は、一時停止してから一定時間経過するまでに一時停止が解除されないときにサーバに対して接続切断要求を送信するものである。このため、第１の問題と同様に、一定期間、帯域が無駄に占有されるという問題が生じうる。
【００１２】
本発明は、上記に鑑みてなされたものであって、ストリームデータを送受信する場合のネットワーク帯域を効率的に利用することができる中継装置、中継方法、中継プログラム、受信装置、通信終了方法および通信終了プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１３】
上述した課題を解決し、目的を達成するために、本発明は、ストリームデータを送信する送信装置と第１ネットワークを介して接続され、前記ストリームデータを受信する受信装置と第２ネットワークを介して接続され、前記送信装置と前記受信装置との間で前記ストリームデータを中継する中継装置であって、前記送信装置と前記受信装置との間の前記ストリームデータの送受信のために用いる通信が確立されているか否かを表す通信状態を記憶する通信状態記憶部と、前記受信装置が前記第２ネットワークから切断されたことを検知する切断検知部と、前記切断検知部で切断されたことが検知された場合に、前記通信が確立されていることを表すか否かを判断する判断部と、前記判断部で通信が確立されていることを表すと判断された場合に、前記通信の終了を要求する要求メッセージを前記送信装置に送信する送信部とを備えたことを特徴とする。
【００１４】
また、本発明は、ネットワークを介して接続された送信装置からストリームデータを受信する受信装置であって、前記ストリームデータの送受信のために用いる通信が確立されているか否かを表す通信状態と、前記通信状態を記憶した記憶日時とを記憶する通信状態記憶部と、前記受信装置が起動されたときに、現在の日時と前記記憶日時との差分が予め定められた期間より小さいか否か、かつ、前記前記通信が確立されていることを表すか否かを判断する判断部と、前記差分が前記期間より小さく、かつ、前記通信が確立されていることを表すと前記判断部で判断された場合に、前記通信の終了を要求する要求メッセージを前記送信装置に送信する送信部とを備えたことを特徴とする。
【００１５】
また、本発明は、上記装置を実行することができる方法およびプログラムである。
【発明の効果】
【００１６】
本発明によれば、ストリームデータを送受信する場合のネットワーク帯域を効率的に利用することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１７】
以下に添付図面を参照して、この発明にかかる中継装置、中継方法、中継プログラム、受信装置、通信終了方法および通信終了プログラムの最良な実施の形態を詳細に説明する。
【００１８】
（第１の実施の形態）
第１の実施の形態にかかる中継装置は、ＩＰ放送サービスのようにマルチキャストでコンテンツ配信サーバなどの送信装置から送信されるコンテンツを、ＳＴＢなどの受信装置に中継する。このとき、受信装置のネットワークへの接続状態を監視し、受信装置がネットワークから切断されたにも関わらずコンテンツ配信のための通信が確立中であった場合に、受信装置に代わって通信の終了シーケンスを実行する。
【００１９】
図１は、第１の実施の形態にかかる中継装置であるストリーム中継装置１を含むコンテンツ配信システムの構成例を示すブロック図である。図１に示すように、ストリーム中継装置１は、ネットワーク５と、ネットワーク６の双方に接続されており、ネットワーク５上のストリーム送信装置２と、ネットワーク６上のストリーム受信装置３との間の通信を中継する。
【００２０】
ネットワーク５は、例えばＮＧＮ（Next Generation Network）のような、品質保証されたＷＡＮ（Wide Area Network）である。また、ネットワーク６は、例えばホームネットワークのような家庭内のＬＡＮ（Local Area Network）である。なお、ネットワーク５およびネットワーク６の形態はこれらに限定されるものではない。
【００２１】
エッジルータ４は、ストリーム中継装置１とネットワーク５とを接続する。エッジルータ４は、例えば、ストリーム受信装置３がＩＰ放送を受信する際に送信するマルチキャストアドレスへのＪｏｉｎパケットや、ＩＰ放送の視聴を終了する際に送信するＬｅａｖｅパケットを受信する。
【００２２】
ストリーム送信装置２は、ＩＰ放送サービスを提供するコンテンツ配信サーバである。なお、コンテンツとは、主に音声データを含む映像データである。本実施の形態では、特に、伝送に広帯域を必要とするＨＤ（High Definition）コンテンツを想定している。
【００２３】
なお、ストリーム送信装置２は、ネットワーク５に直接接続するものであっても構わないし、例えばサービス事業者の企業内ＬＡＮ等の内部に存在し、他のルータ等の装置（図示せず）を介してネットワーク５に接続するものであっても構わない。
【００２４】
ストリーム受信装置３は、ＩＰ放送サービスを受信するＳＴＢ、デジタルテレビ、パーソナルコンピュータ、ＨＤＤ（Hard Disk Drive）レコーダ等のクライアント装置である。ストリーム受信装置３は、ストリーム中継装置１を経由してストリーム送信装置２と通信する。なお、ストリーム受信装置３は、ストリーム中継装置１に直接接続するものであっても構わないし、例えば家庭内ＬＡＮ等の内部に存在し、ブロードルータやスイッチングハブ等の他の装置を介してストリーム中継装置１に接続するものであっても構わない。また、ネットワーク６上には、複数のストリーム受信装置３が存在してもよい。
【００２５】
ストリーム送信装置２とストリーム受信装置３との間に発生する通信には、コンテンツ自体をＩＰ放送として伝送するマルチキャストストリーム通信だけでなく、このマルチキャストアドレスへの参加、離脱を行うシグナリング通信も含まれる。シグナリング通信には、ＩＧＭＰやＭＬＤが利用される。
【００２６】
図１で、ストリーム送信装置２およびストリーム受信装置３は、それぞれ複数存在しても構わない。以下では、１つのストリーム送信装置２と、１つのストリーム受信装置３に着目して説明する。
【００２７】
次に、ストリーム中継装置１の機能および構成の詳細について説明する。図１に示すように、ストリーム中継装置１は、ＷＡＮポート１１１と、ＬＡＮポート１１２と、通信状態記憶部１２１と、中継部１０１と、パケット監視部１０２と、切断検知部１０３と、異常終了判断部１０４と、終了要求送信部１０５と、を備えている。
【００２８】
ＷＡＮポート１１１は、ストリーム中継装置１をネットワーク５に接続するためのポートである。ＬＡＮポート１１２は、ストリーム中継装置１をネットワーク６に接続するためのポートである。ＬＡＮポート１１２は、１つに限定する必要はなく、複数備わっていてもよい。
【００２９】
通信状態記憶部１２１は、ストリーム送信装置２と、ストリーム受信装置３との間でストリームデータを送受信するために用いられる通信の通信状態を記憶する。本実施の形態では、マルチキャストストリームの受信制御に利用するＭＬＤが、ストリームデータを送受信するために用いられる通信に相当する。
【００３０】
図２は、通信状態記憶部１２１に記憶されるデータの一例を示す図である。図２に示すように、通信状態記憶部１２１は、ストリーム受信装置３を識別する受信装置識別情報と、プロトコル種別と、通信状態と、通信情報と、接続状態と、を対応づけたデータを記憶している。
【００３１】
プロトコル種別は、ストリームデータを送受信するために用いられる通信のプロトコルの種別を表す。通信状態は、プロトコル種別で表されるプロトコルの通信の状態を設定する。ＭＬＤの場合は、例えば、ＩＰ放送を受信するためのマルチキャストアドレスに参加中の状態を表すＪｏｉｎ、または、当該マルチキャストアドレスから離脱した状態を表すＬｅａｖｅなどが通信状態として設定される。
【００３２】
通信情報は、後述する終了要求送信部１０５が、プロトコル種別に応じて予め定められた通信の終了を要求する要求メッセージを生成するために必要な情報を設定する。例えば、通信を確立している各装置を特定可能なアドレスおよびポート番号等の情報が設定される同図に示すように、ＭＬＤの場合は、例えば宛先ＩＰアドレス（dst_ipaddr）、宛先ポート番号（dst_port）、送信元ＩＰアドレス（src_ipaddr）、および送信元ポート番号（src_port）が通信情報として設定される。なお、同図の通信情報は一例であり、パケットに含まれる他の情報を記憶するように構成してもよい。
【００３３】
接続状態は、ストリーム受信装置３がネットワーク６に接続されているか否かを表す。本実施の形態では、接続状態＝１のとき接続されていることを表し、接続状態＝０のとき接続されていないことを表すものとする。
【００３４】
なお、通信状態記憶部１２１が、送受信したプロトコルメッセージの一定数の履歴を保持するように構成してもよい。また、通信状態記憶部１２１は、ＨＤＤ、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。
【００３５】
図１に戻り、中継部１０１は、ストリーム中継装置１の主機能である通信パケットの中継処理を実行する。具体的には、中継部１０１は、ネットワーク５上の機器とネットワーク６上の機器との間で送受信される通信パケットを、ＬＡＮポート１１２およびＷＡＮポート１１１を介して転送する。
【００３６】
パケット監視部１０２は、中継部１０１を通過するシグナリング通信パケットを監視し、ストリーム送信装置２とストリーム受信装置３との間の通信の通信状態等を通信状態記憶部１２１に保存する。本実施の形態では、パケット監視部１０２は、ＭＬＤの通信パケットを監視し、当該通信パケットから、ストリーム受信装置３の識別情報と、プロトコル種別と、送信元および宛先のアドレス情報（ＩＰアドレスおよびポート番号）と、マルチキャストアドレスへ参加しているか（Ｊｏｉｎ）または離脱しているか（Ｌｅａｖｅ）を表す通信状態とを決定し、通信状態記憶部１２１に保存する。
【００３７】
切断検知部１０３は、ストリーム受信装置３がネットワーク６から切断されたか否かを検知する。例えば、切断検知部１０３は、まず、定期的にネットワーク６上に生存確認用のマルチキャストパケットを送信する。そして、一定期間以内に当該マルチキャストパケットに対する応答パケットを送信しない機器を、ネットワーク６から切断されたものとして検知する。
【００３８】
反対に、ストリーム受信装置３が一定間隔でネットワーク６に対して生存通知用マルチキャストパケットを送信し、切断検知部１０３が、一定期間以内に当該生存通知用マルチキャストパケットを受信できない機器を、ネットワーク６から切断されたものとして検知するように構成してもよい。
【００３９】
切断検知部１０３は、例えば、ＡＲＰ（Address Resolution Protocol）、ＮＤＰ（Neighbor Discovery Protocol）、ＬＬＤＰ（Link Layer Discovery Protocol）、ＬＬＴＤ（Link Layer Topology Discovery）、およびＳＳＤＰ（Simple Service Discovery Protocol）を利用して、生存確認用のパケットを送受信するように構成することができる。
【００４０】
なお、切断検知方法はこれに限られるものではない。例えば、切断検知部１０３が、ユニキャスト通信を用いて切断を検知するように構成してもよい。具体的には、まず、切断検知部１０３が、通信状態記憶部１２１の接続状態が「１」（ネットワーク６に接続されている）である機器に対して生存確認用のユニキャスト通信を確立し、定期的にキープアライブパケットを送信することでこの通信を維持する。そして、切断検知部１０３は、この通信が閉じられたことを検知したときに、この通信の通信先である機器がネットワーク６から切断されたものとして検知する。ユニキャスト通信としては、例えば、ＴＣＰ（Transmission Control Protocol）コネクションを用いることができる。以下、本実施の形態では、ＴＣＰコネクションを用いて切断を検知するものとして説明する。
【００４１】
なお、通信状態記憶部１２１の通信状態を参照し、通信状態が「Ｊｏｉｎ」の機器に対してのみ、生存確認用のユニキャスト通信を確立するように構成してもよい。これにより、必要な機器のみを対象として通信を確立できるため、不要なネットワークトラフィックを削減できる。上述のように接続状態が「１」である機器を対象とする構成では、通信状態を判定する処理等が不要となるため、処理が簡易化される。
【００４２】
異常終了判断部１０４は、ストリーム受信装置３が正常な終了シーケンスを経ずにストリーム送信装置２との通信を終了したことを判断する。具体的には、異常終了判断部１０４は、通信状態記憶部１２１の通信状態がマルチキャストストリーム受信中の状態（Ｊｏｉｎ）を表し、かつ、切断検知部１０３によってネットワーク６から切断されたことが検知された場合に、対応するストリーム受信装置３が正常な終了シーケンスを経ずに終了したと判断する。
【００４３】
終了要求送信部１０５は、ストリーム受信装置３が正常な終了シーケンスを経ずに終了したと判断された場合に、シグナリング通信の終了を要求する要求メッセージ（マルチキャスト離脱パケット）を生成し、ストリーム送信装置２に送信する。具体的には、終了要求送信部１０５は、通信状態記憶部１２１のプロトコル種別および通信情報を参照し、ＭＬＤのＬｅａｖｅパケットを生成してストリーム送信装置２に送信する。
【００４４】
なお、ＭＬＤの場合は、Ｌｅａｖｅパケットの送信により終了シーケンスが完了する。プロトコルによっては、要求メッセージに対して正常に終了したことを表す応答メッセージを受信したことにより、終了シーケンスが正常に完了したと判断する必要がある。このようなプロトコルの場合、例えば、終了要求送信部１０５が、正常に終了したことを表す応答メッセージを受信するまで要求メッセージを再送信するように構成する。
【００４５】
次に、このように構成された第１の実施の形態にかかるストリーム中継装置１によるストリーム中継処理について図３を用いて説明する。図３は、第１の実施の形態におけるストリーム中継処理の全体の流れを示すフローチャートである。
【００４６】
まず、ストリーム受信装置３が起動され、ネットワーク６に接続される（ステップＳ３０１）。ストリーム受信装置３は、起動時にＵＰｎＰ（Universal Plug and Play）のＳＳＤＰ（Simple Service Discovery Protocol）パケットを送信する（ステップＳ３０２）。
【００４７】
ストリーム中継装置１のパケット監視部１０２は、このＳＳＤＰパケットを受信することによって、ストリーム受信装置３の接続を検知する（ステップＳ３０３）。なお、パケット監視部１０２は、ＩＰｖ４ネットワークであればＡＲＰ（Address Resolution Protocol）、ＩＰｖ６ネットワークであればＮＤＰ（Neighbor Discovery Protocol）を利用してストリーム受信装置３の接続を検知するように構成してもよい。パケット監視部１０２は、接続を検知したストリーム受信装置３の識別情報、接続状態を通信状態記憶部１２１に記憶する。
【００４８】
なお、シグナリング通信プロトコルのパケットを受信したとき（後述のステップＳ３０５）に、このパケットから取得したプロトコル種別、通信状態、および通信情報と、識別情報および接続状態とを対応づけて通信状態記憶部１２１に記憶してもよい。また、パケット監視部１０２が、シグナリング通信プロトコルのパケットの受信をもって、ストリーム受信装置３の接続を検知するように構成してもよい。
【００４９】
次に、ストリーム受信装置３が、ユーザによるＩＰ放送サービスの視聴要求を受け付ける（ステップＳ３０４）。ストリーム受信装置３は、該当するＩＰ放送のマルチキャストアドレスに対するＭＬＤ  Ｊｏｉｎパケットをストリーム中継装置１に送信する（ステップＳ３０５）。
【００５０】
ストリーム中継装置１の中継部１０１は、ＭＬＤ  Ｊｏｉｎパケットを受信する。パケット監視部１０２は、検出したＭＬＤ  Ｊｏｉｎパケット情報から、プロトコル種別（ＭＬＤ）、通信状態（Ｊｏｉｎ）、および通信情報を取得し、通信状態記憶部１２１に蓄積する（ステップＳ３０６）。
【００５１】
さらに、ストリーム中継装置１の切断検知部１０３は、ストリーム受信装置３との間に、生存確認用のＴＣＰコネクションを確立し、一定間隔でキープアライブパケットを送信してＴＣＰコネクションを維持し続ける（ステップＳ３０７）。切断検知部１０３は、このＴＣＰコネクションが切断されたことを検知した場合に、ストリーム受信装置３がネットワーク６から切断されたと判断する。
【００５２】
ストリーム受信装置３は、ＭＬＤ  Ｊｏｉｎパケット送信の結果、コンテンツのＲＴＰ（Real Time Transport Protocol）ストリームの受信を開始する（ステップＳ３０８）。
【００５３】
この後、ストリーム受信中に、ストリーム受信装置３の電源がオフ状態に遷移したと仮定する（ステップＳ３０９）。この場合、ストリーム中継装置１の切断検知部１０３は、ステップＳ３０７で確立したＴＣＰコネクションが切断されたことにより、ストリーム受信装置３がネットワーク６から切断されたことを検知する（ステップＳ３１０、ステップＳ３１１）。この場合、切断検知部１０３は、通信状態記憶部１２１の接続状態を「０」に更新する。
【００５４】
ストリーム中継装置１の異常終了判断部１０４は、通信状態記憶部１２１を参照し、通信状態が通信確立中（Ｊｏｉｎ）であるにも関わらず接続状態が「０」であることを検知する。これにより、異常終了判断部１０４は、ストリーム受信装置３がＩＰ放送のマルチキャストアドレスに対して正常な終了シーケンスを実行せずに、すなわち、ＭＬＤのＬｅａｖｅパケットを送信せずに電源オフ状態に遷移したことを検知する（ステップＳ３１２）。
【００５５】
なお、異常終了判断部１０４が、通信状態記憶部１２１の接続状態を参照する代わりに、切断検知部１０３から検知結果の通知を受け、通知された検知結果を参照して上記判断を実行するように構成してもよい。
【００５６】
最後に、ストリーム中継装置１の終了要求送信部１０５は、ステップＳ３０６で記憶した通信情報を利用してＭＬＤ  Ｌｅａｖｅパケットを生成し、エッジルータ４に対して送信する（ステップＳ３１３）。これにより、マルチキャストストリームのネットワーク６への流入が停止される。
【００５７】
以上のような処理により、ストリーム中継装置１は、エッジルータ４が定期的に送信するＭＬＤクエリの間隔を待たずに、正常な終了シーケンスを踏まずに電源オフ状態に遷移したストリーム受信装置３が参加したマルチキャストストリームを停止させ、ネットワーク６の通信帯域が無駄に消費されることを防止できる。
【００５８】
このように、第１の実施の形態にかかる中継装置では、受信装置のネットワークへの接続状態を監視し、受信装置がネットワークから切断されたにも関わらずコンテンツ配信のための通信が確立中であった場合に、受信装置に代わって通信の終了要求パケットを送信装置に送信する。これにより、ストリームデータを送受信する場合のネットワーク帯域が無駄に消費されることを回避し、帯域を効率的に利用することが可能となる。
【００５９】
（第２の実施の形態）
第１の実施の形態では、ＩＰ放送サービスのようにマルチキャストでストリームデータを送信する中継装置を例に説明した。第２の実施の形態では、ＶｏＤサービスのようにユニキャストで送信されるストリームデータを中継する中継装置に適用した例を説明する。
【００６０】
図４は、第２の実施の形態にかかるストリーム中継装置２１を含むコンテンツ配信システムの構成例を示すブロック図である。図４に示すように、ストリーム中継装置２１は、ネットワーク５上のストリーム送信装置２２と、ネットワーク６上のストリーム受信装置２３との間の通信を中継する。
【００６１】
同図に示すように、本実施の形態では、ネットワーク５の構成要素としてエッジルータ４が含まれていない。ストリーム送信装置２２は、ＶｏＤサービスを提供するコンテンツ配信サーバである。ストリーム受信装置２３は、ＶｏＤサービスを受信するＳＴＢ、デジタルテレビ、パーソナルコンピュータ、ＨＤＤレコーダ等のクライアント装置である。
【００６２】
ストリーム送信装置２２とストリーム受信装置２３との間に発生する通信には、コンテンツ自体を伝送するユニキャストストリーム通信が含まれる。本実施の形態では、ストリームの再生制御にＲＴＳＰを用いる例について説明する。
【００６３】
次に、ストリーム中継装置２１の機能および構成の詳細について説明する。同図に示すように、ストリーム中継装置２１は、ＷＡＮポート１１１と、ＬＡＮポート１１２と、通信状態記憶部２２１と、中断状態記憶部２２２と、中継部１０１と、パケット監視部２０２と、切断検知部１０３と、異常終了判断部２０４と、終了要求送信部２０５と、を備えている。
【００６４】
第２の実施の形態では、通信状態記憶部２２１に記憶されるデータと、パケット監視部２０２、異常終了判断部２０４、および終了要求送信部２０５の機能と、中断状態記憶部２２２を追加したことと、が第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかるストリーム中継装置１の構成を表すブロック図である図１と同様であるので、同一符号を付し、ここでの説明は省略する。
【００６５】
通信状態記憶部２２１は、第１の実施の形態の通信状態記憶部１２１と同様にストリームデータを送受信するために用いられる通信の通信状態を記憶する。第２の実施の形態では、上述のようにＲＴＳＰが、ストリームデータを送受信するために用いられる通信に相当する。このため、ＲＴＳＰの通信状態を記憶する点が、第１の実施の形態の通信状態記憶部１２１と異なっている。
【００６６】
図５は、通信状態記憶部２２１に記憶されるデータの一例を示す図である。図５に示すように、本実施の形態では、プロトコル種別、通信状態、および通信情報に記憶されるデータの内容が第１の実施の形態と異なっている。
【００６７】
プロトコル種別には、ＲＴＳＰが設定される。通信状態には、ＲＴＳＰ  ＳＥＴＵＰリクエストパケット送信前の状態を表すセッション構築前（Init）、セッション構築後（Ready）、およびＲＴＳＰ  ＰＬＡＹリクエストによって遷移するストリームデータ再生中（Playing）などのＲＴＳＰのセッションステータス情報のいずれかが設定される。通信情報には、宛先ＩＰアドレス（dst_ipaddr）、宛先ポート番号（dst_port）、送信元ＩＰアドレス（src_ipaddr）、送信元ポート番号（src_port）、およびネゴシエーション済みセッションを識別する識別情報（Session）などが設定される。
【００６８】
図４に戻り、中断状態記憶部２２２は、ストリーム通信の終了を要求する要求パケット（要求メッセージ）に対する応答として終了要求送信部２０５が受信した応答パケットに含まれる中断時のストリーム状態を記憶する。例えば、中断状態記憶部２２２は、ストリームデータの再生を中断した位置を表す位置情報を含むストリーム状態を記憶する。
【００６９】
パケット監視部２０２は、ＭＬＤの代わりにＲＴＳＰの通信パケットを監視し、当該パケットから取得した通信状態等を通信状態記憶部２２１に保存する点が、第１の実施の形態のパケット監視部１０２と異なっている。本実施の形態では、パケット監視部２０２は、ＲＴＳＰの通信パケットを監視し、当該通信パケットから、プロトコル種別（ＲＴＳＰ）と、送信元および宛先のアドレス情報（ＩＰアドレスおよびポート番号）と、ＲＴＳＰの通信状態（ＲＴＳＰのセッションステータス情報）と、通信情報とを決定し、通信状態記憶部２２１に保存する。
【００７０】
なお、パケット監視部２０２は、通信状態記憶部２２１に保存する通信情報をＲＴＳＰの通信パケットのヘッダ情報等から取得する。例えば、ネゴシエーション済みセッション情報（Session）は、ＲＴＳＰのＳｅｓｓｉｏｎヘッダ情報から取得できる。
【００７１】
異常終了判断部２０４は、通信状態記憶部２２１の通信状態がセッション構築後（Ready）またはストリームデータ再生中（Playing）を表し、かつ、切断検知部１０３によってネットワーク６から切断されたことが検知された場合に、対応するストリーム受信装置２３が正常な終了シーケンスを経ずに終了したと判断する。
【００７２】
終了要求送信部２０５は、通信の終了を要求する要求メッセージとして、マルチキャスト離脱パケット（ＭＬＤ  Ｌｅａｖｅパケット）の代わりに、ストリームの送信停止を要求するＲＴＳＰ  ＰＡＵＳＥパケットを生成して送信する点が、第１の実施の形態の終了要求送信部１０５と異なっている。
【００７３】
次に、このように構成された第２の実施の形態にかかるストリーム中継装置２１によるストリーム中継処理について図６を用いて説明する。図６は、第２の実施の形態におけるストリーム中継処理の全体の流れを示すフローチャートである。
【００７４】
なお、同図では各ＲＴＳＰリクエストに対するレスポンスを省略しているが、実際には、各ＲＴＳＰリクエストに対して２００ＯＫレスポンスが応答される。
【００７５】
まず、ストリーム受信装置２３が起動され、ネットワーク６に接続される（ステップＳ６０１）。次に、ストリーム受信装置２３が、ユーザによるＶｏＤサービスのコンテンツ再生要求を受け付ける（ステップＳ６０２）。ストリーム受信装置２３は、該当するＶｏＤコンテンツのソースアドレスに対し、ＲＴＳＰを利用したセッション確立と再生要求パケットを送信する（ステップＳ６０３、ステップＳ６０４、ステップＳ６０５）。具体的には、ストリーム受信装置２３は、ＲＴＳＰ  ＤＥＳＣＲＩＢＥパケット、ＲＴＳＰ  ＳＥＴＵＰパケット、およびＲＴＳＰ  ＰＬＡＹパケットを送信する。なお、ＲＴＳＰ  ＤＥＳＣＲＩＢＥパケットの送信を省略するように構成してもよい。
【００７６】
これらのパケットを受信したストリーム中継装置２１のパケット監視部２０２は、ストリーム受信装置２３の接続を検知する（ステップＳ６０６）。そして、パケット監視部２０２は、ＲＴＳＰパケット情報から、プロトコル種別（ＲＴＳＰ）、通信状態、および通信情報を取得し、通信状態記憶部２２１に蓄積する（ステップＳ６０７）。
【００７７】
さらに、ストリーム中継装置２１の切断検知部１０３は、ストリーム受信装置２３との間に、生存確認用のＴＣＰコネクションを確立し、一定間隔でキープアライブパケットを送信してＴＣＰコネクションを維持し続ける（ステップＳ６０８）。
【００７８】
ストリーム受信装置２３は、ＲＴＳＰ  ＰＬＡＹパケット送信の結果、コンテンツのＲＴＰストリームの受信を開始する（ステップＳ６０９）。
【００７９】
この後、ストリーム受信中に、ストリーム受信装置２３の電源がオフ状態に遷移したと仮定する（ステップＳ６１０）。この場合、ストリーム中継装置２１の切断検知部１０３は、ステップＳ６０８で確立したＴＣＰコネクションが切断されたことにより、ストリーム受信装置２３がネットワーク６から切断されたことを検知する（ステップＳ６１１、ステップＳ６１２）。
【００８０】
ストリーム中継装置２１の異常終了判断部２０４は、ストリーム受信装置２３がストリーム送信装置２２に対して再生中止を要求せずに、すなわち、ＲＴＳＰ  ＰＡＵＳＥパケットを送信せずに電源オフ状態に遷移したことを検知する（ステップＳ６１３）。
【００８１】
最後に、ストリーム中継装置２１の終了要求送信部２０５は、ステップＳ６０７で記憶した通信情報を利用してＲＴＳＰ  ＰＡＵＳＥパケットを生成し、ストリーム送信装置２２に対して送信する（ステップＳ６１４）。これにより、ユニキャストストリームのネットワーク６への流入が停止される。
【００８２】
以上のような処理により、ストリーム中継装置２１は、ＲＴＳＰ通信セッションのタイムアウト間隔を待たずに、正常な終了シーケンスを踏まずに電源オフ状態に遷移したストリーム受信装置２３が確立したユニキャストストリームを停止させ、ネットワーク６の通信帯域が無駄に消費されることを防止できる。
【００８３】
なお、従来のＶｏＤサービスでは、電源断等により再生が中断した場合に、再生中断位置が把握できなかった。このため、ストリーム受信装置２３の電源を再投入して、中断位置の続きから視聴することができなかった。
【００８４】
そこで、本実施の形態では、ステップＳ６１４で送信したＲＴＳＰ  ＰＡＵＳＥパケットに対するレスポンス情報（再生中断位置情報等）を中断状態記憶部２２２に蓄積することで、再度ストリーム受信装置２３から同一コンテンツへの再生要求が発生した場合に、蓄積した情報を利用して、再生中断位置をストリーム受信装置２３に対して提示する。これにより、ストリーム受信装置２３は、再生が中断された位置を特定し、この再生中断位置から再生を再開することが可能となる。
【００８５】
同図のステップＳ６１５〜ステップＳ６２０は、このようにして再生を再開する場合の処理の概要を表している。
【００８６】
すなわち、まず、ストリーム受信装置２３が再起動され、ネットワーク６に接続される（ステップＳ６１５）。ストリーム受信装置２３は、起動時にＵＰｎＰのＳＳＤＰパケットを送信する（ステップＳ６１６）。
【００８７】
ストリーム中継装置２１のパケット監視部２０２は、このＳＳＤＰパケットを受信することによって、ストリーム受信装置２３の接続を検知する（ステップＳ６１７）。ストリーム中継装置２１は、このときに通知されるストリーム受信装置２３の受信ポートに対して中断状態記憶部２２２に保存された再生中断位置を通知する（ステップＳ６１８）。再生中断位置は、ＨＴＴＰ（Hypertext Transfer Protocol）のＰＯＳＴメソッドを利用して行ってもよいし、生存確認用に確立するＴＣＰコネクションを利用して独自プロトコルによって通知してもよい。
【００８８】
ストリーム受信装置２３は、通知された再生中断位置や再生を中断したコンテンツの名称等を画面に表示し（ステップＳ６１９）、ユーザに対して視聴再開を促す。そして、ストリーム受信装置２３は、ユーザによるコンテンツ再生再開要求を受け付ける（ステップＳ６２０）。この後の処理は、ステップＳ６０３以降の処理と同様であるため説明を省略する。
【００８９】
このように、第２の実施の形態にかかる中継装置では、ＶｏＤサービスのようにユニキャストで送信されるストリームデータを中継する場合にも、受信装置がネットワークから切断されたにも関わらずコンテンツ配信のための通信が確立中であった場合に、受信装置に代わって通信の終了要求パケットを送信装置に送信することができる。
【００９０】
（第３の実施の形態）
第２の実施の形態では、ストリーム通信のために送信装置と受信装置間で利用されるシグナリング通信はＲＴＳＰのみであった。第３の実施の形態では、複数のシグナリング通信プロトコルがストリーム通信のために利用される例について説明する。具体的には、ストリーム通信の帯域制御にＳＩＰを利用し、再生制御にＲＴＳＰを利用する例について説明する。
【００９１】
図７は、第３の実施の形態にかかるストリーム中継装置３１を含むコンテンツ配信システムの構成例を示すブロック図である。図７に示すように、ストリーム中継装置３１は、ネットワーク５上のストリーム送信装置３２と、ネットワーク６上のストリーム受信装置３３との間の通信を中継する。
【００９２】
ストリーム送信装置３２は、ＳＩＰを用いて帯域を確保した上で、ＲＴＳＰを用いてＶｏＤサービスを提供するコンテンツ配信サーバである。ストリーム受信装置３３は、ＳＩＰで確保した帯域でＲＴＳＰによりＶｏＤサービスを受信するＳＴＢ、デジタルテレビ、パーソナルコンピュータ、ＨＤＤレコーダ等のクライアント装置である。
【００９３】
本実施の形態では、ストリーム送信装置３２とストリーム受信装置３３との間に発生する通信には、コンテンツ自体を伝送するユニキャストストリーム通信（ＲＴＳＰ）だけでなく、このストリーム通信セッションを確立、制御するためのシグナリング通信（ＳＩＰ）も含まれる。なお、帯域制御には、ＳＩＰ以外に例えばＲＳＶＰ（Resouce Reservation Protocol）を利用することもできる。
【００９４】
次に、ストリーム中継装置３１の機能および構成の詳細について説明する。同図に示すように、ストリーム中継装置３１は、ＷＡＮポート１１１と、ＬＡＮポート１１２と、通信状態記憶部３２１と、中断状態記憶部２２２と、中継部１０１と、パケット監視部３０２と、切断検知部１０３と、異常終了判断部３０４と、終了要求送信部３０５と、を備えている。
【００９５】
第３の実施の形態では、通信状態記憶部３２１に記憶されるデータと、パケット監視部３０２、異常終了判断部３０４、および終了要求送信部３０５の機能と、が第２の実施の形態と異なっている。その他の構成および機能は、第２の実施の形態にかかるストリーム中継装置２１の構成を表すブロック図である図４と同様であるので、同一符号を付し、ここでの説明は省略する。
【００９６】
通信状態記憶部３２１は、第２の実施の形態の通信状態記憶部２２１と同様にストリームデータを送受信するために用いられる通信の通信状態を記憶する。第３の実施の形態では、上述のようにＲＴＳＰおよびＳＩＰが、ストリームデータを送受信するために用いられる通信に相当する。このため、ＲＴＳＰおよびＳＩＰそれぞれの通信状態を記憶する点が、第２の実施の形態の通信状態記憶部２２１と異なっている。
【００９７】
図８は、通信状態記憶部３２１に記憶されるデータの一例を示す図である。図８に示すように、本実施の形態では、ＲＴＳＰの通信状態だけでなく、ＳＩＰの通信状態も記憶する点が第２の実施の形態と異なっている。
【００９８】
同図の２行目に示すように、ＳＩＰの通信状態の場合は、プロトコル種別には、ＳＩＰが設定される。通信状態には、ＳＩＰのインビテーションにより遷移するＳＩＰのセッション確立中（Session Initiated）、セッション確立のためのネゴシエーション実行中（Session Negotiating）などのＳＩＰセッション状態のいずれかが設定される。通信情報には、宛先ＩＰアドレス（dst_ipaddr）、宛先ポート番号（dst_port）、送信元ＩＰアドレス（src_ipaddr）、送信元ポート番号（src_port）、およびＳＩＰダイアログを識別するコールＩＤ（Call-ID）などが設定される。
【００９９】
図７に戻り、パケット監視部３０２は、ＲＴＳＰだけでなくＳＩＰの通信パケットを監視し、当該パケットから取得した通信状態等を通信状態記憶部３２１に保存する点が、第２の実施の形態のパケット監視部２０２と異なっている。すなわち、パケット監視部２０２は、ＲＴＳＰに加え、ＳＩＰの通信パケットを監視し、当該通信パケットから、プロトコル種別（ＳＩＰ）と、送信元および宛先のアドレス情報（ＩＰアドレスおよびポート番号）と、ＳＩＰの通信状態（ＳＩＰセッション状態情報）と、通信情報とを決定し、通信状態記憶部３２１に保存する。
【０１００】
なお、パケット監視部３０２は、通信状態記憶部３２１に保存する通信情報をＳＩＰの通信パケットのヘッダ情報等から取得する。例えば、コールＩＤ（Call-ID）は、ＳＩＰのＣａｌｌ−ＩＤヘッダから取得することができる。
【０１０１】
異常終了判断部３０４は、通信状態記憶部３２１の複数のシグナリング通信（ＲＴＳＰおよびＳＩＰ）の通信状態のいずれかが通信確立中（ＲＴＳＰの場合「Ready」または「Playing」、ＳＩＰの場合「Session Initiated」）を表し、かつ、切断検知部１０３によってネットワーク６から切断されたことが検知された場合に、対応するストリーム受信装置３３が正常な終了シーケンスを経ずに終了したと判断する。
【０１０２】
終了要求送信部３０５は、通信の終了を要求する要求メッセージとして、ストリームの送信停止を要求するＲＴＳＰ  ＰＡＵＳＥパケットだけでなく、ＳＩＰのセッション終了を要求するＳＩＰ  ＢＹＥパケットを生成して送信する点が、第２の実施の形態の終了要求送信部２０５と異なっている。
【０１０３】
なお、終了要求送信部３０５は、複数の通信の確立順序を考慮して、複数の要求メッセージの送信順序を決定する。具体的には、終了要求送信部３０５は、後に確立した通信を終了するための要求メッセージを、先に確立した通信の要求メッセージより先に送信する。例えば、通常はＳＩＰ  ＩＮＶＩＴＥリクエストによって通信帯域を確保した後にＲＴＳＰの通信セッションが確立される。このため、終了要求送信部３０５は、先にＲＴＳＰ  ＰＡＵＳＥパケットを生成して送信し、その後、ＳＩＰ  ＢＹＥパケットを生成して送信する。
【０１０４】
また、終了要求送信部３０５は、通信状態記憶部３２１の複数のシグナリング通信（ＲＴＳＰおよびＳＩＰ）のうち、通信状態が通信の終了を表す通信に対しては、要求メッセージを送信しない。
【０１０５】
次に、このように構成された第３の実施の形態にかかるストリーム中継装置３１によるストリーム中継処理について図９を用いて説明する。図９は、第３の実施の形態におけるストリーム中継処理の全体の流れを示すフローチャートである。
【０１０６】
なお、同図では、ＳＩＰリクエストおよびＲＴＳＰリクエストに対するレスポンスを省略しているが、実際には、各リクエストに対して２００ＯＫレスポンスが応答される。
【０１０７】
まず、ストリーム受信装置３３が起動され、ネットワーク６に接続される（ステップＳ９０１）。このとき、ストリーム受信装置３３は、ＳＩＰ  ＲＥＧＩＳＴＥＲリクエストを宅内のＳＩＰレジストラに送信して登録処理を行う（ステップＳ９０２）。同図では、ストリーム中継装置３１にＳＩＰレジストラ機能が搭載されているものとしている。
【０１０８】
ストリーム中継装置３１は、ＳＩＰ  ＲＥＧＩＳＴＥＲリクエストの受信により、ストリーム受信装置３３の接続を検知する（ステップＳ９０３）。なお、第１および第２の実施の形態と同様の方法で接続を検知してもよい。
【０１０９】
次に、ストリーム受信装置３３が、ユーザによるＶｏＤサービスのコンテンツ再生要求を受け付ける（ステップＳ９０４）。ストリーム受信装置３３は、ＳＩＰ  ＩＮＶＩＴＥリクエストをストリーム中継装置３１に送信することによって、ストリーム用（および再生制御用）の通信帯域を確保する（ステップＳ９０５、ステップＳ９０６）。さらに、ストリーム受信装置３３は、該当するＶｏＤコンテンツのソースアドレスに対し、ＲＴＳＰを利用したセッション確立と再生要求パケットを送信する（ステップＳ９０７、ステップＳ９０８）。
【０１１０】
これらのパケットを受信したストリーム中継装置３１のパケット監視部３０２は、ＳＩＰパケット情報およびＲＴＳＰパケット情報から、プロトコル種別（ＳＩＰおよびＲＴＳＰ）、通信状態、および各通信情報を取得し、通信状態記憶部３２１に蓄積する（ステップＳ９０９）。
【０１１１】
ストリーム受信装置３３は、ＲＴＳＰ  ＰＬＡＹパケット送信の結果、コンテンツのＲＴＰストリームの受信を開始する（ステップＳ９１０）。
【０１１２】
なお、本実施の形態では、切断検知部１０３が、ＴＣＰコネクションを用いる方法ではなく、生存確認用マルチキャストパケットに対する応答パケットの検知有無によって切断を検知する方法を用いるものとする。第２の実施の形態と同様に、ＴＣＰコネクションを用いる方法を適用してもよい。
【０１１３】
この後、ストリーム受信中に、ストリーム受信装置３３の電源がオフ状態に遷移したと仮定する（ステップＳ９１１）。この場合、ストリーム中継装置３１の切断検知部１０３は、ネットワーク６上に定期的に送信している生存確認用マルチキャストパケットに対して一定期間応答がないことにより、ストリーム受信装置３３がネットワーク６から切断されたことを検知する（ステップＳ９１２、ステップＳ９１３）。
【０１１４】
ストリーム中継装置３１の異常終了判断部３０４は、ストリーム受信装置３３がストリーム送信装置３２に対して再生中止を要求せずに、すなわち、ＳＩＰ  ＢＹＥパケットおよびＲＴＳＰ  ＰＡＵＳＥパケットを送信せずに電源オフ状態に遷移したことを検知する（ステップＳ９１４）。
【０１１５】
最後に、ストリーム中継装置３１の終了要求送信部３０５は、ステップＳ９０９で記憶した通信情報を利用して、ＲＴＳＰ  ＰＡＵＳＥパケットおよびＳＩＰ  ＢＹＥリクエストパケットを順に生成し、ストリーム送信装置３２に対して送信する（ステップＳ９１５、ステップＳ９１６）。これにより、ユニキャストストリームのネットワーク６への流入が停止される。
【０１１６】
なお、この後、ストリーム受信装置３３を再起動して再生を再開する場合の処理は、図６のステップＳ６１５〜ステップＳ６２０と同様であるため、図９では省略している。
【０１１７】
このように、第３の実施の形態にかかる中継装置では、複数のシグナリング通信を用いてストリームデータを送受信する場合にも、受信装置がネットワークから切断されたにも関わらず複数のシグナリング通信のいずれかが確立中であった場合に、受信装置に代わって通信の終了要求パケットを送信装置に送信することができる。
【０１１８】
なお、第１から第３の実施の形態は、任意に組み合わせて実施することが可能である。これは、ストリーム中継装置の通信状態記憶部に、マルチキャストストリームの制御パケット、再生制御パケット、および帯域制御パケットの情報を混在させることが可能であることを意味する。
【０１１９】
（第４の実施の形態）
第１から第３の実施の形態では、ストリームデータを中継する中継装置が、ストリーム受信装置に代わって通信の終了シーケンスを実行するように構成した。第４の実施の形態では、電源オフの後に再起動したときに、ストリーム受信装置自体が異常終了したか否かを判定し、異常終了したと判定した場合に、正常な終了シーケンスを実行して再起動前に確立した通信を終了する。
【０１２０】
図１０は、第３の実施の形態にかかるストリーム受信装置４３を含むコンテンツ配信システムの構成例を示すブロック図である。図１０に示すように、ストリーム受信装置４３は、ネットワーク５に接続されており、同時にネットワーク５にはストリーム送信装置４２も接続されている。
【０１２１】
ネットワーク５は、上述のように、例えばＮＧＮのような品質保証されたＷＡＮを想定しているが、これに限定されるものではない。むしろ、ネットワーク５は、上述のネットワーク５とネットワーク６とを合わせたネットワーク、すなわち、ブロードバンドルータ装置等で相互接続されたＷＡＮと宅内ネットワーク（ＬＡＮ）を合わせたネットワークとして捉える方が、現実的な実施形態に近いといえる。
【０１２２】
ストリーム送信装置４２は、ＩＰ放送サービスおよびＶｏＤサービスを提供するコンテンツ配信サーバである。
【０１２３】
ストリーム受信装置４３は、ＩＰ放送サービスおよびＶｏＤサービスを受信するＳＴＢ、デジタルテレビ、パーソナルコンピュータ、ＨＤＤレコーダ等のクライアント装置である。
【０１２４】
ストリーム送信装置４２とストリーム受信装置４３との間に発生する通信には、ＩＰ放送サービスに関しては、コンテンツ自体をＩＰ放送として伝送するマルチキャストストリーム通信だけでなく、このマルチキャストアドレスへの参加、離脱を行うシグナリング通信も含まれる。このシグナリング通信には、例えばＩＧＭＰやＭＬＤが利用される。ＶｏＤサービスに関しては、コンテンツを伝送するユニキャストストリーム通信だけでなく、コンテンツストリームの再生制御や、帯域制御を行うシグナリング通信も含まれる。再生制御には、例えばＲＴＳＰが利用される。また、帯域制御には、例えばＳＩＰ、ＲＳＶＰが利用される。
【０１２５】
次に、ストリーム受信装置４３の機能および構成の詳細について説明する。同図に示すように、ストリーム受信装置４３は、ＬＡＮポート４１２と、通信状態記憶部４２１と、中断状態記憶部４２２と、通信部４０１と、パケット監視部４０２と、異常終了判断部４０４と、終了要求送信部４０５と、を備えている。
【０１２６】
ＬＡＮポート４１２は、ストリーム受信装置４３をネットワーク５に接続するためのポートである。
【０１２７】
通信状態記憶部４２１は、ストリーム送信装置４２との間でストリームデータを送受信するために用いられる通信の通信状態を記憶する。例えばＩＰ放送サービスを利用する場合は、ＩＧＭＰおよびＭＬＤなどが、ストリームデータを送受信するために用いられる通信に相当する。また、例えばＶｏＤサービスを利用する場合は、ＳＩＰおよびＲＴＳＰなどが、ストリームデータを送受信するために用いられる通信に相当する。
【０１２８】
図１１は、通信状態記憶部４２１に記憶されるデータの一例を示す図である。図１１に示すように、通信状態記憶部４２１は、プロトコル種別と、通信状態と、通信情報と、通信状態を記憶した日時を表すタイムスタンプと、を対応づけたデータを記憶している。プロトコル種別、通信状態、および通信情報の内容は、第１から第３の実施の形態と同様である。
【０１２９】
中断状態記憶部４２２は、ストリームデータの再生を中断した位置を表す再生中断位置情報を記憶する。再生中断位置情報は、後述するパケット監視部４０２によって保存される。
【０１３０】
通信部４０１は、ストリーム送信装置４２との間で、コンテンツストリームの受信や、コンテンツストリーム受信のためのシグナリング通信に関するメッセージの送受信を行う。
【０１３１】
パケット監視部４０２は、通信部４０１で送受信されるシグナリング通信パケットを監視し、ストリーム送信装置４２との間の通信の通信状態等を通信状態記憶部４２１に保存する。本実施の形態では、パケット監視部４０２は、利用するサービスに応じて、ＩＧＭＰ、ＭＬＤ、ＳＩＰ、およびＲＴＳＰなどの通信パケットを監視し、当該通信パケットから、プロトコル種別と、送信元および宛先のアドレス情報（ＩＰアドレスおよびポート番号）と、シグナリング通信の通信状態とを決定し、タイムスタンプを付加して通信状態記憶部４２１に保存する。
【０１３２】
また、パケット監視部４０２は、ストリームデータ受信中に、定期的に（例えば１０秒間隔で）再生位置のスナップショット（再生中断位置情報）を中断状態記憶部４２２に保存する。これにより、ストリーム受信装置４３は、瞬断などの理由によりＶｏＤ視聴中に正常な終了シーケンスを経ずに電源オフ状態に遷移したとしても、再起動時に、この再生中断位置情報を参照することで、適切な位置からＶｏＤ視聴を再開することができる。
【０１３３】
異常終了判断部４０４は、起動時に、ストリーム受信装置４３が正常な終了シーケンスを経ずにストリーム送信装置４２との通信を終了したことを判断する。具体的には、異常終了判断部４０４は、通信状態記憶部４２１の通信状態が通信確立中の状態を表す場合に、自装置が正常な終了シーケンスを経ずに終了したと判断する。
【０１３４】
なお、正常な終了シーケンスで終了した場合に、通信状態記憶部４２１に記憶されたデータを削除し、異常終了判断部４０４が、通信状態記憶部４２１にデータが残されている場合に、自装置が正常な終了シーケンスを経ずに終了したと判断するように構成してもよい。
【０１３５】
異常終了判断部４０４が正常な終了シーケンスを経ずに終了したと判断した場合であっても、一定期間を経過した場合は、各プロトコルの機能によって通信が終了される場合がある。例えば、ＲＴＳＰのキープアライブ間隔を経過した場合は、ＲＴＳＰの通信が切断される。このため、異常終了判断部４０４は、タイムスタンプの日時から現在の日時までの時間が、プロトコルに応じて定められた一定期間より小さいか否かをさらに判断する。
【０１３６】
終了要求送信部４０５は、ストリーム受信装置４３が正常な終了シーケンスを経ずに終了し、かつ、タイムスタンプの日時から現在の日時までの時間が、プロトコルに応じて定められた一定期間より小さいと判断された場合に、シグナリング通信の終了を要求する要求メッセージを生成し、ストリーム送信装置４２に送信する。具体的には、終了要求送信部４０５は、通信状態記憶部４２１のプロトコル種別および通信情報を参照し、利用している通信プロトコルに応じて、例えばマルチキャスト離脱パケット（ＭＬＤのＬｅａｖｅパケット）、または、シグナリング通信の切断要求パケット（ＲＴＳＰ  ＰＡＵＳＥパケット）を生成してストリーム送信装置４２に送信する。
【０１３７】
次に、このように構成された第４の実施の形態にかかるストリーム受信装置４３によるストリーム受信処理について図１２を用いて説明する。図１２は、第４の実施の形態におけるストリーム受信処理の全体の流れを示すフローチャートである。
【０１３８】
なお、同図では、第１の実施の形態と同様に、ストリーム送信装置４２がＭＬＤを用いてＩＰ放送サービスを提供する場合のストリーム受信処理を例に説明する。
【０１３９】
まず、ストリーム受信装置４３が起動され、ネットワーク５に接続される（ステップＳ１２０１）。次に、ストリーム受信装置４３が、ユーザによるＩＰ放送サービスの視聴要求を受け付ける（ステップＳ１２０２）。ストリーム受信装置４３の通信部４０１は、該当するＩＰ放送のマルチキャストアドレスに対するＭＬＤ  Ｊｏｉｎパケットをストリーム送信装置４２に送信する（ステップＳ１２０３）。
【０１４０】
ストリーム受信装置４３のパケット監視部４０２は、送信したＭＬＤ  Ｊｏｉｎパケットから、プロトコル種別（ＭＬＤ）、通信状態（Ｊｏｉｎ）、および通信情報を取得し、通信状態記憶部４２１に蓄積する（ステップＳ１２０４）。
【０１４１】
ストリーム受信装置４３の通信部４０１は、コンテンツのＲＴＰ（Real Time Transport Protocol）ストリームの受信を開始する（ステップＳ１２０５）。
【０１４２】
この後、ストリーム受信中に、ストリーム受信装置４３の電源がオフ状態に遷移し（ステップＳ１２０６）、さらに電源が投入されてストリーム受信装置４３が再起動されたと仮定する（ステップＳ１２０７）。
【０１４３】
ストリーム受信装置４３の異常終了判断部４０４は、通信状態記憶部４２１の通信状態が通信確立中の状態であり、かつ、対応するタイムスタンプの日時から現在の日時までの時間が、プロトコルに応じて定められた一定期間より小さいか否かを判断する（ステップＳ１２０８）。この条件を満たす場合、異常終了判断部４０４は、ストリーム受信装置４３が正常な終了シーケンスを経ずに異常終了したと判断する。
【０１４４】
異常終了したと判断した場合は、ストリーム受信装置４３の終了要求送信部４０５は、ステップＳ１２０４で記憶した通信情報を利用してＭＬＤ  Ｌｅａｖｅパケットを生成し、ストリーム送信装置４２に対して送信する（ステップＳ１２０９）。これにより、マルチキャストストリームのネットワーク５への流入が停止される。
【０１４５】
本実施の形態では、この後、中断状態記憶部４２２の再生中断位置を参照して再生を再開することができる。すなわち、ストリーム受信装置４３は、まず中断状態記憶部４２２から再生中断位置を取得する（ステップＳ１２１０）。そして、ストリーム受信装置４３は、取得した再生中断位置や再生を中断したコンテンツの名称等を画面に表示し（ステップＳ１２１１）、ユーザに対して視聴再開を促す。そして、ストリーム受信装置４３は、ユーザによるコンテンツ再生再開要求を受け付ける（ステップＳ１２１２）。この後の処理は、ステップＳ１２０３以降の処理と同様であるため説明を省略する。
【０１４６】
なお、第２および第３の実施の形態のように、ストリーム送信装置４２がＶｏＤサービスを提供する場合についても、同様の処理により、再起動後に正常な終了シーケンスを実行するように構成することができる。
【０１４７】
このように、第４の実施の形態にかかる受信装置では、電源オフの後に再起動したときに、ストリーム受信装置自体が異常終了したか否かを判定し、異常終了したと判定した場合に、正常な終了シーケンスを実行して再起動前に確立した通信を終了することができる。これにより、ストリームデータを送受信する場合のネットワーク帯域を効率的に利用することが可能となる。
【０１４８】
次に、第１〜第４の実施の形態にかかる各装置（中継装置または受信装置）のハードウェア構成について図１３を用いて説明する。図１３は、第１〜第４の実施の形態にかかる装置のハードウェア構成を示す説明図である。
【０１４９】
第１〜第４の実施の形態にかかる装置は、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、各部を接続するバス６１を備えている。
【０１５０】
第１〜第４の実施の形態にかかる装置で実行される各プログラム（中継装置で実行される中継プログラムまたは受信装置で実行される通信終了プログラム）は、ＲＯＭ５２等に予め組み込まれて提供される。
【０１５１】
第１〜第４の実施の形態にかかる装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。
【０１５２】
さらに、第１〜第４の実施の形態にかかる装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１〜第４の実施の形態にかかる装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【０１５３】
第１〜第３の実施の形態にかかる中継装置で実行される中継プログラムは、上述した各部（中継部、パケット監視部、切断検知部、異常終了判断部、終了要求送信部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１が上記ＲＯＭ５２から中継プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、各部が主記憶装置上に生成されるようになっている。
【０１５４】
また、第４の実施の形態にかかる受信装置で実行される通信終了プログラムは、上述した各部（通信部、パケット監視部、異常終了判断部、終了要求送信部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１が上記ＲＯＭ５２から通信終了プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、各部が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【０１５５】
以上のように、本発明にかかる中継装置、中継方法、中継プログラム、受信装置、通信終了方法および通信終了プログラムは、ＩＰ放送サービスおよびＶｏＤサービスなどのようにストリームデータを送受信する装置、方法、およびプログラムに適している。
【図面の簡単な説明】
【０１５６】
【図１】第１の実施の形態にかかるコンテンツ配信システムの構成例を示すブロック図である。
【図２】第１の実施の形態の通信状態記憶部に記憶されるデータの一例を示す図である。
【図３】第１の実施の形態におけるストリーム中継処理の全体の流れを示すフローチャートである。
【図４】第２の実施の形態にかかるコンテンツ配信システムの構成例を示すブロック図である。
【図５】第２の実施の形態の通信状態記憶部に記憶されるデータの一例を示す図である。
【図６】第２の実施の形態におけるストリーム中継処理の全体の流れを示すフローチャートである。
【図７】第３の実施の形態にかかるコンテンツ配信システムの構成例を示すブロック図である。
【図８】第３の実施の形態の通信状態記憶部に記憶されるデータの一例を示す図である。
【図９】第３の実施の形態におけるストリーム中継処理の全体の流れを示すフローチャートである。
【図１０】第４の実施の形態にかかるコンテンツ配信システムの構成例を示すブロック図である。
【図１１】第４の実施の形態の通信状態記憶部に記憶されるデータの一例を示す図である。
【図１２】第４の実施の形態におけるストリーム受信処理の全体の流れを示すフローチャートである。
【図１３】第１〜第４の実施の形態にかかる装置のハードウェア構成を示す説明図である。
【符号の説明】
【０１５７】
１、２１、３１  ストリーム中継装置
２、２２、３２、４２  ストリーム送信装置
３、２３、３３、４３  ストリーム受信装置
４  エッジルータ
５、６  ネットワーク
５１  ＣＰＵ
５２  ＲＯＭ
５３  ＲＡＭ
５４  通信Ｉ／Ｆ
６１  バス
１０１  中継部
１０２、２０２、３０２、４０２  パケット監視部
１０３  切断検知部
１０４、２０４、３０４、４０４  異常終了判断部
１０５、２０５、３０５、４０５  終了要求送信部
１１１  ＷＡＮポート
１１２、４１２  ＬＡＮポート
１２１、２２１、３２１、４２１  通信状態記憶部
２２２、４２２  中断状態記憶部
４０１  通信部
【図１】
2010081067.tif 000003
【図２】
2010081067.tif 000004
【図３】
2010081067.tif 000005
【図４】
2010081067.tif 000006
【図５】
2010081067.tif 000007
【図６】
2010081067.tif 000008
【図７】
2010081067.tif 000009
【図８】
2010081067.tif 000010
【図９】
2010081067.tif 000011
【図１０】
2010081067.tif 000012
【図１１】
2010081067.tif 000013
【図１２】
2010081067.tif 000014
【図１３】
2010081067.tif 000015