JP2010534368A - リアルタイム・ストリーミング・プロトコル・イベントを通知する方法、装置及びシステム - Google Patents

Abstract

リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知する方法は、イベント状態をモニタすること、及びイベント状態の変化が検知された場合にイベント状態受信エンティティに対してイベント状態の変化を示す通知を送信すること、を含む。コンピュータプログラム及びコンピュータ読み取り可能な記憶媒体が提供され、上記のＲＴＳＰイベントを通知する方法のステップをコンピュータが実行できるようにする。ＲＴＳＰイベントを通知する装置は、イベント状態をモニタするように構成されたイベント状態モニタリングユニットと、イベント状態モニタリングユニットがイベント状態の変化を検知した場合に、イベント状態の変化を示す通知を送信するように構成されたメッセージ送信ユニットと、を含む。ＲＴＳＰイベントを通知するシステムは、ＲＴＳＰイベントの上記のＲＴＳＰイベント通知装置を含む。上記の技術的な解決手段により、イベント状態が変化した場合に、対応するネットワークエンティティに対してイベント状態が通知される。

Description

本願は、２００７年７月２０日に中国特許庁へ出願された「リアルタイム・ストリーミング・プロトコル・イベントを通知する方法、装置及びシステム」という標題の中国特許出願第２００７１０１３０１０８．２号に基づく優先権を主張するものであり、参照によりその内容全体が本明細書に組み込まれる。

本発明は通信技術に関し、特に、リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ：Real-Time Streaming Protocol）のイベントを通知する方法、装置及びシステムに関する。

ＲＴＳＰは、基本的にリアルタイムデータの伝送を制御するためのアプリケーションレベルのプロトコルである。ＲＴＳＰは、ビデオデータやオーディオデータ等のリアルタイムデータを、オンデマンドで制御し再生するための拡張可能なフレームワークを提供する。ＲＴＳＰは、多重データ伝送セッションを制御し、伝送チャネルを選択するための方法を提供し、リアルタイム転送プロトコル（ＲＴＰ：Real Time Transport Protocol）に基づく伝送メカニズムを選択するための方法を提供するために設計されている。

図１に示すように、従来技術におけるＲＴＳＰシグナリング相互作用プロセス（RTSP signaling interaction process）は、以下のステップを含んでいる。

ステップ１０１：クライアントが、ＤＥＳＣＲＩＢＥ要求をサーバに送信し、ＲＴＳＰからのプレゼンテーションの記述を要求する。この要求は、メディアコンテンツの記述と各メディアストリームの識別子とを有する。例えば、メディアコンテンツの記述には、メディアコンテンツ内のメディアストリームの数と、メディアの種類やコーディング／デコーディングの種類などの各メディアストリームに関する詳細と、が含まれる。クライアントとはＲＴＳＰクライアントであり、サーバとはＲＴＳＰサーバである。

ステップ１０２：サーバが、成功応答（２００ ＯＫ）をクライアントに返すと共に、要求された情報を記述する。

クライアントがリソース記述情報を取得するプロセスは、クライアントがサーバからのメディアを要求すると共にそのメディアに対して制御動作を実行する前に情報を取得するプロセスとは全く関係の無いプロセスである。この情報は、ＨＴＴＰやｅメールなどのその他の手段によっても取得可能である。

ステップ１０３：クライアントが、ＳＥＴＵＰメッセージをサーバに送信し、メディアストリームの設定を要求する。このメッセージは、設定されるメディアストリームが、例えばマルチメディアコンテンツの中のオーディオメディアストリームなのかビデオメディアストリームなのかを特定する、メディアストリーム識別子を有する。

ステップ１０４：サーバが、成功応答（２００ ＯＫ）をクライアントに返して、メディアストリームの設定が完了する。

ステップ１０３とステップ１０４とが、メディアストリームの設定完了プロセスである。メディアストリームの設定が完了した後も、サーバはメディアの再生又はメディアストリームの伝送を開始しない。再生を開始するには、クライアントがサーバにＰＬＡＹメッセージを明確に送信し、メディアの再生を要求する必要がある。マルチメディアコンテンツは、一般に、複数のマルチメディアストリームを含む。複数のメディアを再生するには、クライアントが、サーバとの間にマルチメディアストリームを設定する必要がある。ＲＴＳＰにおいては、クライアントが所望するメディアストリームの各々について、クライアントとサーバとの間で１対１の設定が必要である。即ち、ステップ１０３又はステップ１０４における対話プロセスが繰り返し行われる。

ステップ１０５：クライアントが、ＰＬＡＹメッセージをサーバに送信し、メディアの再生の開始を要求する。このメッセージは、再生用に確立されたメディアストリームを特定するメディアストリーム識別子を有するか、又は確立されたプレゼンテーションパッケージ内の全部のメディアストリームの再生を特定するプレゼンテーション識別子を有する。

ステップ１０６：ステップ１０５に応答して、サーバが、成功応答（２００ ＯＫ）をクライアントに返し、メディアストリームの再生の開始を知らせる。

メディアストリームはメディアチャンネルを介して伝送される。

ステップ１０５とステップ１０６とが、メディアチャンネルの設定プロセスを構成する。ステップ１０５及びステップ１０６での対話が完了した後に、クライアントが、メディアチャンネルを介してサーバからメディアストリームを受信し、受信したメディアストリームをデコードしてユーザ端末のインタフェースを介してユーザにそのメディアストリームを表示するか、そのメディアストリームをローカルに格納する。

ストリーミングのアプリケーションにおいては、クライアントがサーバに対して要求コマンドの実行を要求した後、サーバがそのコマンドを実行する際に正常又は異常なイベントが発生する場合には、サーバはそのイベント又は要求実行の最新状態をクライアントに対して何らかのモードで通知する必要がある。しかしながら、ＲＴＳＰアプリケーションでは、サーバは、ＰＬＡＹメッセージを受信した後で、クライアントに対して要求されたメディアの再生を開始し、同時に成功応答（２００ ＯＫ）をクライアントに返す。その後で、メディアの再生プロセスにおける例外的イベント（例えば、メディアファイルの読み出しにおけるサーバの例外）とか、クライアントにより処理される必要のある非例外的なイベント（例えば、リアルタイムストリーミングのアプリケーションにおいて、ユーザが早送りを要求しているが、再生の進行が現時刻のプログラムに到達してしまった場合）が発生する場合には、従来のＲＴＳＰプロトコルは関連するメカニズムや技術を何も提供しないので、サーバが上記の例外やイベントをクライアントに通知することができない。その結果、クライアントとサーバとの間で状態が不一致となり、ユーザエクスペリエンス（user experience）が不十分なものとなる。

本発明の実施形態は、イベント状態の変化に応じて、対応するネットワークエンティティにイベント状態が通知されるように、ＲＴＳＰイベントを通知する方法、装置及びシステムを提供する。

本発明の実施形態の目的は、以下の技術的な解決手段を通じて達成される。

本発明の実施形態におけるＲＴＳＰイベントを通知する方法は、
イベント状態をモニタするステップと、
イベント状態の変化が検知された場合に、イベント状態受信エンティティに対してイベント状態の変化を示す通知を送信するステップと、を含む。

本発明の実施形態において提供されるコンピュータプログラムは、コンピュータプログラムコードを含む。そのコンピュータプログラムコードは、コンピュータで実行されると、ＲＴＳＰイベント状態を通知する方法の任意のステップをコンピュータが実行できるようにする。

本発明の実施形態で提供されるコンピュータ読み取り可能な記憶媒体は、コンピュータプログラムコードを記憶する。そのコンピュータプログラムコードは、コンピュータで実行されると、ＲＴＳＰイベント状態を通知する方法の任意のステップをコンピュータが実行できるようにする。

本発明の実施形態におけるＲＴＳＰイベントを通知する装置は、
イベント状態をモニタするように構成されたイベント状態モニタリングユニットと、
イベント状態モニタリングユニットがイベント状態の変化を検知した場合に、イベント状態の変化を示す通知を送信するように構成されたメッセージ送信ユニットと、を含む。

本発明の実施形態におけるＲＴＳＰを通知するシステムは、
イベント状態をモニタし、イベント状態の変化に応じて、イベント状態の変化を示す通知を送信するように構成されたＲＴＳＰイベント通知装置と、
その通知を受信するように構成されたＲＴＳＰイベント通知受信装置と、を含む。

本発明における技術的な解決手段は、イベント状態をモニタして、イベント状態の変化を対応するネットワークエンティティに通知する。このようにして、ネットワークエンティティ間でのイベント状態の整合性を確保し、ユーザエクスペリエンスを向上させる。

従来技術におけるＲＴＳＰシグナリング相互作用のフローチャートである。 本発明の第１の実施形態におけるＲＴＳＰイベントを通知する方法のフローチャートである。 本発明の第２の実施形態におけるＲＴＳＰイベントを通知する方法のシグナリングフローチャートである。 本発明の第３の実施形態におけるＲＴＳＰイベントを通知する方法のシグナリングフローチャートである。 本発明の第４の実施形態におけるＲＴＳＰイベントを通知する方法のシグナリングフローチャートである。 本発明の第１の実施形態におけるＲＴＳＰイベントを通知する装置の構成を示す図である。 本発明の第２の実施形態におけるＲＴＳＰイベントを通知する装置の構成を示す図である。 本発明の第１の実施形態におけるＲＴＳＰイベントを通知するシステムの構成を示す図である。 本発明の第２の実施形態におけるＲＴＳＰイベントを通知するシステムの構成を示す図である。

本発明の技術的な解決手段、目的及び利点をより明確にするために、添付した図面を参照して、本発明の実施形態を以下で詳細に説明する。

図２に示すように、本発明の第１の実施形態におけるＲＴＳＰイベントを通知する方法は、以下のステップを含む。

ステップ２０１：イベント状態モニタリングエンティティが、イベント状態をモニタする。

イベント状態モニタリングエンティティは、メディアチャンネルを設定するサーバ及びクライアントのいずれか一方でもよく、又はサードパーティのネットワークエンティティでもよい。

イベント状態モニタリングは、例えばユーザ操作やデコーディングの失敗のような例外の発生など、偶発イベント（contingent event）の発生に関するモニタリングである。また、イベント状態モニタリングは、例えばストリーミングメディアの再生状態などの連続的イベントの状態変化に関するモニタリングや、再生状態から早送り状態への変化のようなネットワーク状態に関するモニタリングである。即ち、イベント状態に関するモニタリングは、偶発イベントの発生に関するモニタリングと、連続的イベントの状態変化に関するモニタリングとを含む。

ＲＴＳＰプロセスにおいては、クライアントがサーバに対して要求コマンドの実行を要求した後に、サーバがそのコマンドを実行する際に正常又は異常なイベントが発生する場合には、サーバはそのイベント又は要求実行の最新状態（the latest condition of executing the request）をクライアントに対して通知する必要がある。従って、サーバはそのイベントの状態をモニタする必要がある。同様に、サーバがクライアントに対して要求コマンドの実行を要求した後に、クライアントがそのコマンドを実行する際に正常又は異常なイベントが発生する場合には、クライアントはそのイベント又は要求実行の最新状態をサーバに対して通知する必要がある。従って、クライアントはそのイベントの状態をモニタする必要がある。

イベント状態は、能動的（actively）又は受動的（passively）にモニタされ得る。能動的モニタリングにおいては、モニタされるイベントと、イベント状態の変化に関する情報を受信するためのネットワークエンティティと、が事前設定される。イベントはデフォルトによりモニタされてよい。例えば、クライアントがストリーミングメディアの再生を要求した場合、サーバはストリーミングメディアの再生状態を当然モニタする。受動的モニタリングにおいては、ネットワークエンティティからイベント状態のモニタリング要求を受信した後に、モニタリングが実行される。このエンティティは、イベント状態をモニタするエンティティ以外の任意のネットワークエンティティであってよい。

ステップ２０２：イベント状態の変化が検知された場合に、イベント状態モニタリングエンティティが、イベント状態受信エンティティに対してイベント状態の変化を示す通知を送信する。

イベント状態受信エンティティは、イベント状態モニタリングエンティティと共に変化する。例えば、イベント状態モニタリングエンティティがサーバである場合には、通常、イベント状態受信エンティティはクライアントである。しかし、イベント状態受信エンティティは、別のネットワーク装置であり得る。

特に、従来のＲＴＳＰはイベントの通知をすることができない、即ち、イベント状態の変化を示す通知を送信することができないので、従来のＲＴＳＰは拡張される必要がある。ＲＴＳＰを拡張するための方法は、イベントの種類によって変わる。

イベント状態の変化を示す通知は、モニタされるイベント状態によって変化する。モニタリングの目的が、イベントが発生するか否かをチェックすることにある場合には、通知はイベントの発生に関する情報を含む。モニタリングの目的が、イベント状態が変化したか否かをチェックすることにある場合には、通知はイベントの変化した状態に関する情報を含むが、これに限られるものではない。イベント状態の変化を示す通知は、偶発イベント又は連続的イベントの状態変化（例えば、再生状態から早送り状態への変化）の発生を、イベント状態受信エンティティに通知することを意図している。連続的イベントの状態変化を通知する場合、通知には変化後の状態と変化前の状態とが含まれる。

イベント状態が能動的にモニタされる場合には、イベント状態をモニタするエンティティが、イベント状態の変化を示す通知を受信するエンティティを決定する。イベント状態が受動的にモニタされ且つイベント状態の変化を示す通知を受信するエンティティが事前設定されている場合には、イベント状態をモニタするエンティティが、事前設定されたエンティティに対して通知を送信する。あるいは、通知を受信するエンティティが事前設定されていない場合には、イベント状態をモニタするエンティティが、イベント状態の変化を示す通知を受信するエンティティを決定する。

明らかに、本発明における技術的な解決手段は、イベント状態をモニタし、イベント状態の変化を対応するネットワークエンティティに通知することで、ネットワークエンティティ間でのイベント状態の整合性を確保し、ユーザエクスペリエンスを向上させる。

ここでのイベントは、事前設定された状態に応じた偶発イベント（a contingent event compliant with preset conditions）、再生中のメディアストリームの状態、又はネットワークの状態である。事前設定された状態に応じた偶発イベントは、イベント状態モニタリングエンティティのイベント状態とイベント状態受信エンティティのイベント状態との間の不一致をもたらす、例えばユーザの操作情報のようなイベントである。偶発イベントは、特定の状況に従って予め定義されてもよい。

図３に示すように、本発明の第２の実施形態におけるＲＴＳＰイベントを通知する方法は、以下のステップを含む。

ステップ３０１：クライアントが、ＳＥＴＵＰメッセージをサーバに送信し、メディアストリームの設定を要求する。

ステップ３０２：サーバが、成功応答（２００ ＯＫ）をクライアントに返して、メディアストリームが設定される。

ステップ３０３：クライアントが、ＰＬＡＹメッセージをサーバに送信し、メディアストリームの過去からの高速再生を要求する。

ステップ３０４：サーバが、成功応答（２００ ＯＫ）をクライアントに返して、メディアストリームの高速再生を開始する。

メディアストリームはメディアチャンネルを介して伝送される。

サーバがメディアストリームの再生の状態をモニタする。再生が進行してある時点に到達すると、サーバは高速再生を継続できなくなる。例えば、サーバが生番組（live program）を再生している場合には、サーバは標準再生状態に移行する。サーバがビデオ・オン・デマンド（ＶｏＤ）番組を再生している場合には、高速再生の進行が現在の生放送時刻に到達すると、再生は通常停止する。その後のサーバの処理は、再生されている番組に依存する。例えば、生番組が再生されている場合には、ある時点で再生状態を変えるイベントが起きたが、クライアントが早送りから標準再生に移行したことに気づかないとすると、クライアントはインタフェース上で早送りを表示させ続けようとする。その結果、サーバとクライアントの間の状態に不一致が生じる。この場合、サーバはクライアントに対して最新の再生状態を送信する必要がある。

ステップ３０５：サーバが、イベント状態の変化を示す通知をクライアントに送信する。この通知は、イベント通知メッセージ（Event Notification message）であり得る。こうして最新の再生状態がクライアントに通知される。

従来のＲＴＳＰは、関連する通知メカニズムを備えていないので、サーバがイベント通知をクライアントに送信できるように、ＲＴＳＰを拡張する必要がある。前述のアプリケーション・シナリオに対して、考えられる通知メッセージは以下のとおりである。

NOTIFY rtsp://rtspclient.example.com RTSP/2.0
Content-Type: application/playback-status
Content-Length: …
Allow: play, pause
playback-speed:1
playback-scale:1
playback-range=now-

ここで「Allow: play, pause（許可：再生、一時停止）」は、現在許可される操作は再生と一時停止であることを意味する。「playback-speed:1（再生スピード：１）」及び「playback-scale:1（再生スケール：１）」は、標準速度での再生を示す。「playback-range=now-（再生範囲＝現在〜）」は、現時刻からの標準再生の開始を意味する。

ステップ３０６：イベント通知を受信した後、クライアントは成功応答（２００ ＯＫ）をサーバに返す。

この実施形態では、サーバがストリーミングメディアの再生状態をモニタする。再生状態が変化すると、サーバは最新の再生状態をクライアントに送信する。従って、クライアントとサーバの間で再生状態が一致した状態に維持され、ユーザエクスペリエンスが向上する。

図４に示すように、本発明の第３の実施形態におけるＲＴＳＰイベントを通知する方法は、以下のステップを含む。

ステップ４０１：クライアントが、ＳＥＴＵＰメッセージをサーバに送信し、メディアストリームの設定を要求する。

ステップ４０２：サーバが、成功応答（２００ ＯＫ）をクライアントに返して、メディアストリームが設定される。

ステップ４０３：クライアントが、ＰＬＡＹメッセージをサーバに送信し、メディアストリームの過去からの高速再生を要求する。

ステップ４０４：サーバが、成功応答（２００ ＯＫ）をクライアントに返して、メディアストリームの高速再生を開始する。

メディアチャンネルがメディアストリームの伝送に使用される。

ステップ４０５：サードエンティティが、サーバに要求を送信して、イベント状態のモニタを要求する。その結果、再生状態の変化に応じて、サーバが最新の再生状態をクライアントに通知する。

サードエンティティは、ネットワーク内の任意のエンティティでよく、例えばネットワーク管理装置や、ネットワークをモニタするモニタリング装置などである。また、サードエンティティは、クライアント又はサーバでもよい。

従来のＲＴＳＰは、対応する要求メッセージを備えていないので、ＲＴＳＰを拡張する必要がある。本発明の実施形態で与えられるＲＴＳＰベースの要求メッセージは以下のとおりである。

EVENTREQ rtsp://rtspserver.example.com RTSP/2.0
Event: play-status
Event-Session: the-session-to-be-monitored
Notify-To: rtsp://rtspclient.example.com
Notify-Session: the-session-for-event-notification
Content-Length: 0

メッセージ中のフィールドを以下で説明する。

イベント：このフィールドはモニタすべきイベントを特定する。メッセージがこのフィールドを有していない場合には、メッセージの受信者がモニタするイベントを決定するか、イベント要求を拒否する。

イベントセッション：このフィールドはイベントがモニタされるＲＴＳＤＰセッションを特定する。メッセージが「イベントセッション」のヘッダフィールドを有していない場合には、デフォルトにより、要求に対応するセッションのイベントがモニタされる必要があるか、メッセージ受信者がモニタするセッションを決定する。例えば、「ＥＶＥＮＴＲＥＱ」フィールドが、「セッション」ヘッダフィールドを有している場合には、ＥＶＥＮＴＲＥＱメッセージを含むセッション自身がモニタされるか、全部のセッションがモニタされる。

通知先（Notify-To）：このフィールドはイベントが通知されるエンティティを示す。メッセージがこのヘッダフィールドを有していない場合には、メッセージの受信者が、この要求を拒否するか、事前設定されたローカルポリシー又は格納されている環境設定ファイルに従って、この通知を受信するエンティティを決定する。例えば、イベント通知はＥＶＥＮＴＲＥＱメッセージの送信者に対して送信される、又はイベント通知は「通知セッション」フィールドにより特定されるセッションのピアエンティティへ送信される。

通知セッション（Notify-Session）：このフィールドはイベント通知が送信されるセッションを特定する。メッセージがこのヘッダフィールドを有していない場合には、メッセージ受信者が、イベント通知が送信される又は送信先から除外されるセッションを決定する。

サーバが上記の４つのフィールドのいずれも受信しない場合には、サーバは、ローカルな環境設定情報に従ったイベント状態をモニタするためにデフォルト要求メッセージ（default request message）を生成する。例えば、メディアの再生がＰＬＡＹメッセージを介して要求される場合には、再生状態を報告することは当然の要求事項である。従って、クライアントが通知メッセージを受信可能であることをサーバが知っている場合には、要求メッセージが受信されていなくても、デフォルトによってクライアントが再生状態イベントなどの基本イベントのモニタリングを要求したとみなされる。

ステップ４０６：要求メッセージを受信した後、サーバは、成功応答（２００ ＯＫ）をサードエンティティに返す。

高速再生の進行がある時点に到達すると、サーバは高速再生を続けられなくなり、再生状態の変化を検知する。

ステップ４０７：サーバは、クライアントに通知を送信する。この通知は、再生状態の変化及び最新の再生状態を示す。

ステップ４０８：クライアントは、成功応答（２００ ＯＫ）をサーバに返す。

この実施形態においては、クライアントとサーバとの間にＲＴＳＰセッションが設定された後、サードエンティティがサーバに再生状態のモニタを要求する。従って、サーバが再生状態の変化を検知すると、サーバが再生状態の変化を示す通知をクライアントに送信する。こうしてサーバとクライアントとの間の再生状態を一致させて、ユーザエクスペリエンスを向上させる。更に、サードエンティティが再生状態のモニタリングを要求することで、ネットワークのフレキシビリティを改善する。

実際には、最新の再生状態を受信した後、クライアントは、表示された再生状態をサーバから送信された最新の再生状態に更新する。従って、クライアントにより表示された状態は、実際の再生状態に一致しており、ユーザエクスペリエンスが改善される。

図５に示すように、本発明の第４の実施形態におけるＲＴＳＰイベントを通知する方法は、以下のステップを含む。

ステップ５０１：クライアントが、ＳＥＴＵＰメッセージをサーバに送信し、メディアストリームの設定を要求する。

ステップ５０２：サーバが、成功応答（２００ ＯＫ）をクライアントに返して、メディアストリームが設定される。

ステップ５０３：クライアントが、ＰＬＡＹメッセージをサーバに送信し、メディアストリームの再生を要求する。

ステップ５０４：サーバが、成功応答（２００ ＯＫ）をクライアントに返して、メディアストリームの高速再生を開始する。成功応答（２００ ＯＫ）は要求メッセージを有し、ユーザ操作のモニタを要求する。

メディアチャンネルがメディアストリームの伝送に使用される。

ステップ５０５：要求メッセージを受信した後、クライアントが、ユーザの現在の操作を示す通知をサーバに送信する。

ステップ５０６：ユーザの現在の操作に関する情報を受信した後、サーバは、成功応答（２００ ＯＫ）をクライアントに返す。

クライアントはユーザ操作をモニタする。ある時点でユーザ操作が変化すると、クライアントはその変化を検知する。

ステップ５０７：ユーザ操作の変化を検知すると、クライアントは、サーバに通知を送信して、変更されたユーザ操作に関する情報を知らせる。

ステップ５０８：変更されたユーザ操作に関する情報を受信した後、サーバは、成功応答（２００ ＯＫ）をクライアントに返す。

この実施形態では、要求メッセージが成功応答（２００ ＯＫ）で伝えられる。しかし実際には、要求メッセージは、別個の要求メッセージでもよく、サーバとクライアント間に交換される他のメッセージで伝えられてもよい。この実施形態では、サーバが、従来技術で交換されるメッセージに要求メッセージを追加して、ユーザ操作のモニタをクライアントに要求する。従って、ユーザ操作が変化すると、クライアントが、変更されたユーザ操作に関する情報をサーバへ送信し、サーバとユーザとの間のイベント状態が同一に保持される。

実際には、変更されたユーザ操作に関する情報を受信した後、サーバがユーザ操作に応じた操作を実行する。例えば、ユーザ操作がストリーミングメディアの高速再生の場合には、サーバは、変更されたユーザ操作に関する情報を受信後、ストリーミングメディアの再生を高速再生に変更する。また、ユーザ操作が一時停止の場合には、サーバは、ストリーミングメディアの再生を中断する。特に、ストリーミングデータの送信が中断される。

ＲＴＳＰイベント通知方法に対応して、本発明の第１の実施形態において、ＲＴＳＰイベントを通知する装置が提供される。図６に示すように、この装置は、イベント状態をモニタするように構成されたイベント状態モニタリングユニット６０１と、イベント状態モニタリングユニットがイベント状態の変化を検知した場合に、イベント状態の変化を示す通知を送信するように構成されたメッセージ送信ユニット６０２と、を含む。

明らかに、本発明における技術的な解決手段は、イベント状態をモニタし、イベント状態の変化に関する情報を対応するネットワークエンティティに通知することで、ネットワークエンティティ間でのイベント状態の整合性を確保し、ユーザエクスペリエンスを向上させる。

ＲＴＳＰイベントを通知する装置が、本発明の第２の実施形態において提供される。第１の実施形態の装置と比較すると、第２の実施形態に係るＲＴＳＰイベントを通知する装置は、メッセージ受信ユニットをさらに含む。

図７に示すように、第２の実施形態に係る装置は、イベント状態のモニタを要求する要求メッセージを受信するように構成されたメッセージ受信ユニット７００と、メッセージ受信ユニットが要求メッセージを受信した後にイベント状態をモニタするように構成されたイベント状態モニタリングユニット７０１と、イベント状態モニタリングユニットがイベント状態の変化を検知した場合に、イベント状態の変化を示す通知を送信するように構成されたメッセージ送信ユニット７０２と、を含む。

この実施形態では、ＲＴＳＰイベントを通知する装置は、要求メッセージを受信した後にイベント状態をモニタし、イベント状態が変化した場合にイベント状態の変化に関する情報を送信する。従って、サーバとクライアントとの間でイベント状態が一致した状態に維持され、ユーザの満足度が改善される。

実際には、イベント状態をモニタリングした時点で既に発生しているイベントの状態をモニタする必要がある場合には、メッセージ送信ユニットは、クライアントとサーバとの間のイベント状態を一致させるように要求する要求メッセージをメッセージ受信ユニットが受信した後に、イベントの現在の状態（current state）に関する情報を送信するように、更に構成されている。これは、要求メッセージを送信する時点で、既にクライアントとサーバとの間のイベント状態が不一致となっているからである。

ＲＴＳＰイベントを通知するシステムが、本発明の第１の実施形態において提供される。図８に示すように、このシステムは、イベント状態をモニタすると共に、イベント状態の変化に応じてイベント状態の変化を示す通知を送信するように構成され、実際にはサーバ又はクライアントである、ＲＴＳＰイベント通知装置８０１と、通知を受信するように構成されたＲＴＳＰイベント通知受信装置８０２と、を含む。

通常、ＲＴＳＰイベント通知装置がサーバである場合には、ＲＴＳＰイベント通知受信装置はクライアントであり、ＲＴＳＰイベント通知装置がクライアントである場合には、ＲＴＳＰイベント通知受信装置はサーバである。しかしながら、ＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置の両方がサーバであり、又はＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置の両方がクライアントであることもあり得る。

明らかに、本発明における技術的な解決手段は、イベント状態をモニタし、イベント状態の変化に関する情報を対応するネットワークエンティティに通知することで、ネットワークエンティティ間でのイベント状態の整合性を確保し、ユーザエクスペリエンスを向上させる。

図９に示すように、本発明の第２の実施形態に係るＲＴＳＰイベントを通知するシステムは、イベント状態のモニタを要求する要求メッセージを送信するように構成されたＲＴＳＰイベントモニタリング要求装置９００と、要求メッセージの受信後にイベント状態をモニタすると共に、イベント状態の変化に応じてイベント状態の変化を示す通知を送信するように構成されたＲＴＳＰイベント通知装置９０１と、通知を受信するように構成されたＲＴＳＰイベント通知受信装置９０２と、を含む。

実際には、ＲＴＳＰイベントモニタリング要求装置とＲＴＳＰイベント通知装置とは、同一のネットワークエンティティであるか、又は別々のネットワークエンティティである。

本実施形態においては、ＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置との間にＲＴＳＰセッションが設定された後に、ＲＴＳＰイベントモニタリング要求装置が、要求メッセージをＲＴＳＰイベント通知装置に送信し、イベント状態のモニタを要求する。従って、イベント状態の変化を検知すると、ＲＴＳＰイベント通知装置が、ＲＴＳＰイベント通知受信装置にイベント状態の変化を通知する。その結果、ＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置との間でイベント状態は一致した状態に維持され、ユーザエクスペリエンスが向上する。更に、ＲＴＳＰイベントモニタリング要求装置が、再生状態のモニタを要求する要求メッセージを送信することで、ネットワークのフレキシビリティが向上する。

当業者にはわかるように、前述の実施形態の全部又は一部のステップは、プログラムの指示を受けるハードウェアで実装されてもよい。プログラムはコンピュータ読み取り可能な記憶媒体に格納されてもよい。プログラムが実行される場合には、プログラムは以下のステップを実行する。
１．イベント状態モニタリングエンティティがイベント状態をモニタする。
２．イベント状態の変化を検知すると、イベント状態モニタリングエンティティが、イベント状態受信エンティティに対してイベント状態の変化を示す通知を送信する。

記憶媒体は、読み出し専用メモリ（ＲＯＭ）、磁気ディスク、又はコンパクトディスク（ＣＤ）であってよい。

上記に詳述したのは、本発明におけるＲＴＳＰイベントを通知する方法、装置、及びシステムである。本発明はいくつかの例示的な実施形態によって説明されているが、本発明はこれらの実施形態に制限されるものではない。本発明の精神及び範囲から逸脱することなく、当業者が修正及び変更を本発明に対して行えることは明らかである。以下の特許請求の範囲及びその均等物によって定義される保護範囲にある修正又は変更は、本発明に含まれることが意図されている。

Claims (23)

1. リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知する方法であって、
   イベント状態をモニタすること、及び、
   前記イベント状態の変化が検知された場合に、イベント状態受信エンティティに対してイベント状態の変化を示す通知を送信すること、
   を含む方法。
2. 前記イベント状態をモニタする前に、前記イベント状態のモニタを要求する要求メッセージを受信すること、を更に含む請求項１に記載の方法。
3. 前記イベント状態受信エンティティに対して前記通知を送信する前に、
   前記要求メッセージが前記イベント状態受信エンティティに関する情報を有するか否かを判断すること、及び、
   前記要求メッセージが前記イベント状態受信エンティティに関する情報を有する場合には、前記情報に従って前記イベント状態受信エンティティに対して前記通知を送信し、前記要求メッセージが前記イベント状態受信エンティティに関する情報を有しない場合には、事前設定されたローカルポリシー又は格納された環境設定ファイルに従って前記イベント状態受信エンティティに対して前記通知を送信すること、
   を更に含む請求項２に記載の方法。
4. 前記要求メッセージを受信した後に、前記イベント通知受信エンティティに対して前記イベントの現在の状態に関する情報を送信すること、を更に含む請求項２又は３に記載の方法。
5. 前記通知及び前記要求メッセージは、ＲＴＳＰベースのメッセージである、請求項２又は３に記載の方法。
6. 前記イベント状態をモニタすることが、事前設定されたローカルポリシー又は格納された環境設定ファイルに従って前記イベント状態をモニタすることである、請求項１に記載の方法。
7. 前記イベント状態をモニタした時点で前記イベントが発生する場合には、前記送信される通知が前記イベントの発生に関する情報を有し、
   前記イベント状態のモニタ開始前に前記イベントが発生し且つ前記イベント状態が変化している場合には、前記送信される通知が前記イベントの変化した状態に関する情報を有する、
   請求項１に記載の方法。
8. 前記イベントの前記発生に関する情報を有する前記通知を受信した後に、前記イベント状態受信エンティティが、事前設定されたローカルポリシー又は格納された環境設定ファイルに従って動作を実行する、請求項７に記載の方法。
9. 前記イベントの変化した状態に関する情報を有する前記通知を受信した後に、前記イベント状態受信エンティティが、前記対応するイベント状態を前記変化した状態に更新する、請求項７に記載の方法。
10. 前記イベントは、事前設定された状態に応じた偶発イベント、ストリーミングメディアの再生状態、又はネットワーク状態である、請求項１〜３及び請求項６〜９のいずれか１項に記載の方法。
11. 前記イベント状態をモニタすることが、偶発イベントの発生をモニタすることである、請求項１〜３及び請求項６〜９に記載の方法。
12. 前記通知は、イベント状態受信エンティティに対して前記偶発イベントの発生を通知するように構成される、請求項１１に記載の方法。
13. 前記イベント状態をモニタすることが、連続的イベントの状態変化をモニタすることである、請求項１〜３及び請求項６〜９に記載の方法。
14. 前記通知は、イベント状態受信エンティティに対して前記連続的イベントの変化した状態を通知するように構成される、請求項１３に記載の方法。
15. クライアントにより、イベント状態をモニタすること、及び、
    前記イベント状態の変化を検知した場合に、イベント状態受信エンティティに対して前記イベント状態の変化を示す通知を送信することにおいて、前記イベント状態受信エンティティはサーバであること、
    を特に含む請求項１〜３及び請求項６〜９のいずれか１項に記載の方法。
16. サーバにより、イベント状態をモニタすること、及び、
    前記イベント状態の変化を検知した場合に、イベント状態受信エンティティに対して前記イベント状態の変化を示す通知を送信することにおいて、前記イベント状態受信エンティティはクライアントであること、
    を特に含む請求項１〜３及び請求項６〜９のいずれか１項に記載の方法。
17. コンピュータプログラムコードを含み、前記コンピュータプログラムコードがコンピュータで実行されると請求項１〜１４の任意のステップをコンピュータが実行可能となるコンピュータプログラム。
18. コンピュータプログラムコードを記憶し、前記コンピュータプログラムコードがコンピュータで実行されると請求項１〜１４の任意のステップをコンピュータが実行可能となるコンピュータ読み取り可能な記憶媒体。
19. リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知する装置であって、
    イベント状態をモニタするように構成されたイベント状態モニタリングユニットと、
    前記イベント状態モニタリングユニットが前記イベント状態の変化を検知した場合に、前記イベント状態の変化を示す通知を送信するように構成されたメッセージ送信ユニットと、
    を含む装置。
20. メッセージ受信ユニットを更に含み、
    前記メッセージ受信ユニットは、前記イベント状態をモニタすることを要求する要求メッセージを受信するように構成され、
    前記イベント状態モニタリングユニットは、更に、前記メッセージ受信ユニットが前記要求メッセージを受信した後に、前記イベント状態をモニタするように構成されている、
    請求項１９に記載の装置。
21. 前記イベント状態のモニタを開始する前に前記イベントが発生する場合に、前記メッセージ送信ユニットは、更に、前記メッセージ受信ユニットが前記要求メッセージを受信した後に、前記イベントの現在の状態に関する情報を送信するように構成されている、
    請求項２０に記載の装置。
22. リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知するシステムであって、
    イベント状態をモニタすると共に、前記イベント状態の変化に応じて前記イベント状態の変化を示す通知を送信するように構成されたＲＴＳＰイベント通知装置と、
    前記通知を受信するように構成されたＲＴＳＰイベント通知受信装置と、
    を含むシステム。
23. ＲＴＳＰイベントモニタリング要求装置を更に含み、
    前記ＲＴＳＰイベントモニタリング要求装置は、前記イベント状態をモニタすることを要求する要求メッセージを送信するように構成され、
    前記ＲＴＳＰイベント通知装置は、更に、前記要求メッセージを受信した後に、前記イベント状態をモニタするように構成されている、
    請求項２２に記載のシステム。

Images