リアルタイム・ストリーミング・プロトコル・イベントを通知する方法、装置及びシステム
リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知する方法は、イベント状態をモニタすること、及びイベント状態の変化が検知された場合にイベント状態受信エンティティに対してイベント状態の変化を示す通知を送信すること、を含む。コンピュータプログラム及びコンピュータ読み取り可能な記憶媒体が提供され、上記のＲＴＳＰイベントを通知する方法のステップをコンピュータが実行できるようにする。ＲＴＳＰイベントを通知する装置は、イベント状態をモニタするように構成されたイベント状態モニタリングユニットと、イベント状態モニタリングユニットがイベント状態の変化を検知した場合に、イベント状態の変化を示す通知を送信するように構成されたメッセージ送信ユニットと、を含む。ＲＴＳＰイベントを通知するシステムは、ＲＴＳＰイベントの上記のＲＴＳＰイベント通知装置を含む。上記の技術的な解決手段により、イベント状態が変化した場合に、対応するネットワークエンティティに対してイベント状態が通知される。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２００７年７月２０日に中国特許庁へ出願された「リアルタイム・ストリーミング・プロトコル・イベントを通知する方法、装置及びシステム」という標題の中国特許出願第２００７１０１３０１０８．２号に基づく優先権を主張するものであり、参照によりその内容全体が本明細書に組み込まれる。
【０００２】
本発明は通信技術に関し、特に、リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ：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）に関する情報を送信するように、更に構成されている。これは、要求メッセージを送信する時点で、既にクライアントとサーバとの間のイベント状態が不一致となっているからである。
【００９３】
ＲＴＳＰイベントを通知するシステムが、本発明の第１の実施形態において提供される。図８に示すように、このシステムは、イベント状態をモニタすると共に、イベント状態の変化に応じてイベント状態の変化を示す通知を送信するように構成され、実際にはサーバ又はクライアントである、ＲＴＳＰイベント通知装置８０１と、通知を受信するように構成されたＲＴＳＰイベント通知受信装置８０２と、を含む。
【００９４】
通常、ＲＴＳＰイベント通知装置がサーバである場合には、ＲＴＳＰイベント通知受信装置はクライアントであり、ＲＴＳＰイベント通知装置がクライアントである場合には、ＲＴＳＰイベント通知受信装置はサーバである。しかしながら、ＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置の両方がサーバであり、又はＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置の両方がクライアントであることもあり得る。
【００９５】
明らかに、本発明における技術的な解決手段は、イベント状態をモニタし、イベント状態の変化に関する情報を対応するネットワークエンティティに通知することで、ネットワークエンティティ間でのイベント状態の整合性を確保し、ユーザエクスペリエンスを向上させる。
【００９６】
図９に示すように、本発明の第２の実施形態に係るＲＴＳＰイベントを通知するシステムは、イベント状態のモニタを要求する要求メッセージを送信するように構成されたＲＴＳＰイベントモニタリング要求装置９００と、要求メッセージの受信後にイベント状態をモニタすると共に、イベント状態の変化に応じてイベント状態の変化を示す通知を送信するように構成されたＲＴＳＰイベント通知装置９０１と、通知を受信するように構成されたＲＴＳＰイベント通知受信装置９０２と、を含む。
【００９７】
実際には、ＲＴＳＰイベントモニタリング要求装置とＲＴＳＰイベント通知装置とは、同一のネットワークエンティティであるか、又は別々のネットワークエンティティである。
【００９８】
本実施形態においては、ＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置との間にＲＴＳＰセッションが設定された後に、ＲＴＳＰイベントモニタリング要求装置が、要求メッセージをＲＴＳＰイベント通知装置に送信し、イベント状態のモニタを要求する。従って、イベント状態の変化を検知すると、ＲＴＳＰイベント通知装置が、ＲＴＳＰイベント通知受信装置にイベント状態の変化を通知する。その結果、ＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置との間でイベント状態は一致した状態に維持され、ユーザエクスペリエンスが向上する。更に、ＲＴＳＰイベントモニタリング要求装置が、再生状態のモニタを要求する要求メッセージを送信することで、ネットワークのフレキシビリティが向上する。
【００９９】
当業者にはわかるように、前述の実施形態の全部又は一部のステップは、プログラムの指示を受けるハードウェアで実装されてもよい。プログラムはコンピュータ読み取り可能な記憶媒体に格納されてもよい。プログラムが実行される場合には、プログラムは以下のステップを実行する。
１．イベント状態モニタリングエンティティがイベント状態をモニタする。
２．イベント状態の変化を検知すると、イベント状態モニタリングエンティティが、イベント状態受信エンティティに対してイベント状態の変化を示す通知を送信する。
【０１００】
記憶媒体は、読み出し専用メモリ（ＲＯＭ）、磁気ディスク、又はコンパクトディスク（ＣＤ）であってよい。
【０１０１】
上記に詳述したのは、本発明におけるＲＴＳＰイベントを通知する方法、装置、及びシステムである。本発明はいくつかの例示的な実施形態によって説明されているが、本発明はこれらの実施形態に制限されるものではない。本発明の精神及び範囲から逸脱することなく、当業者が修正及び変更を本発明に対して行えることは明らかである。以下の特許請求の範囲及びその均等物によって定義される保護範囲にある修正又は変更は、本発明に含まれることが意図されている。
【技術分野】
【０００１】
本願は、２００７年７月２０日に中国特許庁へ出願された「リアルタイム・ストリーミング・プロトコル・イベントを通知する方法、装置及びシステム」という標題の中国特許出願第２００７１０１３０１０８．２号に基づく優先権を主張するものであり、参照によりその内容全体が本明細書に組み込まれる。
【０００２】
本発明は通信技術に関し、特に、リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ：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）に関する情報を送信するように、更に構成されている。これは、要求メッセージを送信する時点で、既にクライアントとサーバとの間のイベント状態が不一致となっているからである。
【００９３】
ＲＴＳＰイベントを通知するシステムが、本発明の第１の実施形態において提供される。図８に示すように、このシステムは、イベント状態をモニタすると共に、イベント状態の変化に応じてイベント状態の変化を示す通知を送信するように構成され、実際にはサーバ又はクライアントである、ＲＴＳＰイベント通知装置８０１と、通知を受信するように構成されたＲＴＳＰイベント通知受信装置８０２と、を含む。
【００９４】
通常、ＲＴＳＰイベント通知装置がサーバである場合には、ＲＴＳＰイベント通知受信装置はクライアントであり、ＲＴＳＰイベント通知装置がクライアントである場合には、ＲＴＳＰイベント通知受信装置はサーバである。しかしながら、ＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置の両方がサーバであり、又はＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置の両方がクライアントであることもあり得る。
【００９５】
明らかに、本発明における技術的な解決手段は、イベント状態をモニタし、イベント状態の変化に関する情報を対応するネットワークエンティティに通知することで、ネットワークエンティティ間でのイベント状態の整合性を確保し、ユーザエクスペリエンスを向上させる。
【００９６】
図９に示すように、本発明の第２の実施形態に係るＲＴＳＰイベントを通知するシステムは、イベント状態のモニタを要求する要求メッセージを送信するように構成されたＲＴＳＰイベントモニタリング要求装置９００と、要求メッセージの受信後にイベント状態をモニタすると共に、イベント状態の変化に応じてイベント状態の変化を示す通知を送信するように構成されたＲＴＳＰイベント通知装置９０１と、通知を受信するように構成されたＲＴＳＰイベント通知受信装置９０２と、を含む。
【００９７】
実際には、ＲＴＳＰイベントモニタリング要求装置とＲＴＳＰイベント通知装置とは、同一のネットワークエンティティであるか、又は別々のネットワークエンティティである。
【００９８】
本実施形態においては、ＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置との間にＲＴＳＰセッションが設定された後に、ＲＴＳＰイベントモニタリング要求装置が、要求メッセージをＲＴＳＰイベント通知装置に送信し、イベント状態のモニタを要求する。従って、イベント状態の変化を検知すると、ＲＴＳＰイベント通知装置が、ＲＴＳＰイベント通知受信装置にイベント状態の変化を通知する。その結果、ＲＴＳＰイベント通知装置とＲＴＳＰイベント通知受信装置との間でイベント状態は一致した状態に維持され、ユーザエクスペリエンスが向上する。更に、ＲＴＳＰイベントモニタリング要求装置が、再生状態のモニタを要求する要求メッセージを送信することで、ネットワークのフレキシビリティが向上する。
【００９９】
当業者にはわかるように、前述の実施形態の全部又は一部のステップは、プログラムの指示を受けるハードウェアで実装されてもよい。プログラムはコンピュータ読み取り可能な記憶媒体に格納されてもよい。プログラムが実行される場合には、プログラムは以下のステップを実行する。
１．イベント状態モニタリングエンティティがイベント状態をモニタする。
２．イベント状態の変化を検知すると、イベント状態モニタリングエンティティが、イベント状態受信エンティティに対してイベント状態の変化を示す通知を送信する。
【０１００】
記憶媒体は、読み出し専用メモリ（ＲＯＭ）、磁気ディスク、又はコンパクトディスク（ＣＤ）であってよい。
【０１０１】
上記に詳述したのは、本発明におけるＲＴＳＰイベントを通知する方法、装置、及びシステムである。本発明はいくつかの例示的な実施形態によって説明されているが、本発明はこれらの実施形態に制限されるものではない。本発明の精神及び範囲から逸脱することなく、当業者が修正及び変更を本発明に対して行えることは明らかである。以下の特許請求の範囲及びその均等物によって定義される保護範囲にある修正又は変更は、本発明に含まれることが意図されている。
【特許請求の範囲】
【請求項１】
リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知する方法であって、
イベント状態をモニタすること、及び、
前記イベント状態の変化が検知された場合に、イベント状態受信エンティティに対してイベント状態の変化を示す通知を送信すること、
を含む方法。
【請求項２】
前記イベント状態をモニタする前に、前記イベント状態のモニタを要求する要求メッセージを受信すること、を更に含む請求項１に記載の方法。
【請求項３】
前記イベント状態受信エンティティに対して前記通知を送信する前に、
前記要求メッセージが前記イベント状態受信エンティティに関する情報を有するか否かを判断すること、及び、
前記要求メッセージが前記イベント状態受信エンティティに関する情報を有する場合には、前記情報に従って前記イベント状態受信エンティティに対して前記通知を送信し、前記要求メッセージが前記イベント状態受信エンティティに関する情報を有しない場合には、事前設定されたローカルポリシー又は格納された環境設定ファイルに従って前記イベント状態受信エンティティに対して前記通知を送信すること、
を更に含む請求項２に記載の方法。
【請求項４】
前記要求メッセージを受信した後に、前記イベント通知受信エンティティに対して前記イベントの現在の状態に関する情報を送信すること、を更に含む請求項２又は３に記載の方法。
【請求項５】
前記通知及び前記要求メッセージは、ＲＴＳＰベースのメッセージである、請求項２又は３に記載の方法。
【請求項６】
前記イベント状態をモニタすることが、事前設定されたローカルポリシー又は格納された環境設定ファイルに従って前記イベント状態をモニタすることである、請求項１に記載の方法。
【請求項７】
前記イベント状態をモニタした時点で前記イベントが発生する場合には、前記送信される通知が前記イベントの発生に関する情報を有し、
前記イベント状態のモニタ開始前に前記イベントが発生し且つ前記イベント状態が変化している場合には、前記送信される通知が前記イベントの変化した状態に関する情報を有する、
請求項１に記載の方法。
【請求項８】
前記イベントの前記発生に関する情報を有する前記通知を受信した後に、前記イベント状態受信エンティティが、事前設定されたローカルポリシー又は格納された環境設定ファイルに従って動作を実行する、請求項７に記載の方法。
【請求項９】
前記イベントの変化した状態に関する情報を有する前記通知を受信した後に、前記イベント状態受信エンティティが、前記対応するイベント状態を前記変化した状態に更新する、請求項７に記載の方法。
【請求項１０】
前記イベントは、事前設定された状態に応じた偶発イベント、ストリーミングメディアの再生状態、又はネットワーク状態である、請求項１〜３及び請求項６〜９のいずれか１項に記載の方法。
【請求項１１】
前記イベント状態をモニタすることが、偶発イベントの発生をモニタすることである、請求項１〜３及び請求項６〜９に記載の方法。
【請求項１２】
前記通知は、イベント状態受信エンティティに対して前記偶発イベントの発生を通知するように構成される、請求項１１に記載の方法。
【請求項１３】
前記イベント状態をモニタすることが、連続的イベントの状態変化をモニタすることである、請求項１〜３及び請求項６〜９に記載の方法。
【請求項１４】
前記通知は、イベント状態受信エンティティに対して前記連続的イベントの変化した状態を通知するように構成される、請求項１３に記載の方法。
【請求項１５】
クライアントにより、イベント状態をモニタすること、及び、
前記イベント状態の変化を検知した場合に、イベント状態受信エンティティに対して前記イベント状態の変化を示す通知を送信することにおいて、前記イベント状態受信エンティティはサーバであること、
を特に含む請求項１〜３及び請求項６〜９のいずれか１項に記載の方法。
【請求項１６】
サーバにより、イベント状態をモニタすること、及び、
前記イベント状態の変化を検知した場合に、イベント状態受信エンティティに対して前記イベント状態の変化を示す通知を送信することにおいて、前記イベント状態受信エンティティはクライアントであること、
を特に含む請求項１〜３及び請求項６〜９のいずれか１項に記載の方法。
【請求項１７】
コンピュータプログラムコードを含み、前記コンピュータプログラムコードがコンピュータで実行されると請求項１〜１４の任意のステップをコンピュータが実行可能となるコンピュータプログラム。
【請求項１８】
コンピュータプログラムコードを記憶し、前記コンピュータプログラムコードがコンピュータで実行されると請求項１〜１４の任意のステップをコンピュータが実行可能となるコンピュータ読み取り可能な記憶媒体。
【請求項１９】
リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知する装置であって、
イベント状態をモニタするように構成されたイベント状態モニタリングユニットと、
前記イベント状態モニタリングユニットが前記イベント状態の変化を検知した場合に、前記イベント状態の変化を示す通知を送信するように構成されたメッセージ送信ユニットと、
を含む装置。
【請求項２０】
メッセージ受信ユニットを更に含み、
前記メッセージ受信ユニットは、前記イベント状態をモニタすることを要求する要求メッセージを受信するように構成され、
前記イベント状態モニタリングユニットは、更に、前記メッセージ受信ユニットが前記要求メッセージを受信した後に、前記イベント状態をモニタするように構成されている、
請求項１９に記載の装置。
【請求項２１】
前記イベント状態のモニタを開始する前に前記イベントが発生する場合に、前記メッセージ送信ユニットは、更に、前記メッセージ受信ユニットが前記要求メッセージを受信した後に、前記イベントの現在の状態に関する情報を送信するように構成されている、
請求項２０に記載の装置。
【請求項２２】
リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知するシステムであって、
イベント状態をモニタすると共に、前記イベント状態の変化に応じて前記イベント状態の変化を示す通知を送信するように構成されたＲＴＳＰイベント通知装置と、
前記通知を受信するように構成されたＲＴＳＰイベント通知受信装置と、
を含むシステム。
【請求項２３】
ＲＴＳＰイベントモニタリング要求装置を更に含み、
前記ＲＴＳＰイベントモニタリング要求装置は、前記イベント状態をモニタすることを要求する要求メッセージを送信するように構成され、
前記ＲＴＳＰイベント通知装置は、更に、前記要求メッセージを受信した後に、前記イベント状態をモニタするように構成されている、
請求項２２に記載のシステム。
【請求項１】
リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知する方法であって、
イベント状態をモニタすること、及び、
前記イベント状態の変化が検知された場合に、イベント状態受信エンティティに対してイベント状態の変化を示す通知を送信すること、
を含む方法。
【請求項２】
前記イベント状態をモニタする前に、前記イベント状態のモニタを要求する要求メッセージを受信すること、を更に含む請求項１に記載の方法。
【請求項３】
前記イベント状態受信エンティティに対して前記通知を送信する前に、
前記要求メッセージが前記イベント状態受信エンティティに関する情報を有するか否かを判断すること、及び、
前記要求メッセージが前記イベント状態受信エンティティに関する情報を有する場合には、前記情報に従って前記イベント状態受信エンティティに対して前記通知を送信し、前記要求メッセージが前記イベント状態受信エンティティに関する情報を有しない場合には、事前設定されたローカルポリシー又は格納された環境設定ファイルに従って前記イベント状態受信エンティティに対して前記通知を送信すること、
を更に含む請求項２に記載の方法。
【請求項４】
前記要求メッセージを受信した後に、前記イベント通知受信エンティティに対して前記イベントの現在の状態に関する情報を送信すること、を更に含む請求項２又は３に記載の方法。
【請求項５】
前記通知及び前記要求メッセージは、ＲＴＳＰベースのメッセージである、請求項２又は３に記載の方法。
【請求項６】
前記イベント状態をモニタすることが、事前設定されたローカルポリシー又は格納された環境設定ファイルに従って前記イベント状態をモニタすることである、請求項１に記載の方法。
【請求項７】
前記イベント状態をモニタした時点で前記イベントが発生する場合には、前記送信される通知が前記イベントの発生に関する情報を有し、
前記イベント状態のモニタ開始前に前記イベントが発生し且つ前記イベント状態が変化している場合には、前記送信される通知が前記イベントの変化した状態に関する情報を有する、
請求項１に記載の方法。
【請求項８】
前記イベントの前記発生に関する情報を有する前記通知を受信した後に、前記イベント状態受信エンティティが、事前設定されたローカルポリシー又は格納された環境設定ファイルに従って動作を実行する、請求項７に記載の方法。
【請求項９】
前記イベントの変化した状態に関する情報を有する前記通知を受信した後に、前記イベント状態受信エンティティが、前記対応するイベント状態を前記変化した状態に更新する、請求項７に記載の方法。
【請求項１０】
前記イベントは、事前設定された状態に応じた偶発イベント、ストリーミングメディアの再生状態、又はネットワーク状態である、請求項１〜３及び請求項６〜９のいずれか１項に記載の方法。
【請求項１１】
前記イベント状態をモニタすることが、偶発イベントの発生をモニタすることである、請求項１〜３及び請求項６〜９に記載の方法。
【請求項１２】
前記通知は、イベント状態受信エンティティに対して前記偶発イベントの発生を通知するように構成される、請求項１１に記載の方法。
【請求項１３】
前記イベント状態をモニタすることが、連続的イベントの状態変化をモニタすることである、請求項１〜３及び請求項６〜９に記載の方法。
【請求項１４】
前記通知は、イベント状態受信エンティティに対して前記連続的イベントの変化した状態を通知するように構成される、請求項１３に記載の方法。
【請求項１５】
クライアントにより、イベント状態をモニタすること、及び、
前記イベント状態の変化を検知した場合に、イベント状態受信エンティティに対して前記イベント状態の変化を示す通知を送信することにおいて、前記イベント状態受信エンティティはサーバであること、
を特に含む請求項１〜３及び請求項６〜９のいずれか１項に記載の方法。
【請求項１６】
サーバにより、イベント状態をモニタすること、及び、
前記イベント状態の変化を検知した場合に、イベント状態受信エンティティに対して前記イベント状態の変化を示す通知を送信することにおいて、前記イベント状態受信エンティティはクライアントであること、
を特に含む請求項１〜３及び請求項６〜９のいずれか１項に記載の方法。
【請求項１７】
コンピュータプログラムコードを含み、前記コンピュータプログラムコードがコンピュータで実行されると請求項１〜１４の任意のステップをコンピュータが実行可能となるコンピュータプログラム。
【請求項１８】
コンピュータプログラムコードを記憶し、前記コンピュータプログラムコードがコンピュータで実行されると請求項１〜１４の任意のステップをコンピュータが実行可能となるコンピュータ読み取り可能な記憶媒体。
【請求項１９】
リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知する装置であって、
イベント状態をモニタするように構成されたイベント状態モニタリングユニットと、
前記イベント状態モニタリングユニットが前記イベント状態の変化を検知した場合に、前記イベント状態の変化を示す通知を送信するように構成されたメッセージ送信ユニットと、
を含む装置。
【請求項２０】
メッセージ受信ユニットを更に含み、
前記メッセージ受信ユニットは、前記イベント状態をモニタすることを要求する要求メッセージを受信するように構成され、
前記イベント状態モニタリングユニットは、更に、前記メッセージ受信ユニットが前記要求メッセージを受信した後に、前記イベント状態をモニタするように構成されている、
請求項１９に記載の装置。
【請求項２１】
前記イベント状態のモニタを開始する前に前記イベントが発生する場合に、前記メッセージ送信ユニットは、更に、前記メッセージ受信ユニットが前記要求メッセージを受信した後に、前記イベントの現在の状態に関する情報を送信するように構成されている、
請求項２０に記載の装置。
【請求項２２】
リアルタイム・ストリーミング・プロトコル（ＲＴＳＰ）イベントを通知するシステムであって、
イベント状態をモニタすると共に、前記イベント状態の変化に応じて前記イベント状態の変化を示す通知を送信するように構成されたＲＴＳＰイベント通知装置と、
前記通知を受信するように構成されたＲＴＳＰイベント通知受信装置と、
を含むシステム。
【請求項２３】
ＲＴＳＰイベントモニタリング要求装置を更に含み、
前記ＲＴＳＰイベントモニタリング要求装置は、前記イベント状態をモニタすることを要求する要求メッセージを送信するように構成され、
前記ＲＴＳＰイベント通知装置は、更に、前記要求メッセージを受信した後に、前記イベント状態をモニタするように構成されている、
請求項２２に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２０１０−５３４３６８（Ｐ２０１０−５３４３６８Ａ）
【公表日】平成２２年１１月４日（２０１０．１１．４）
【国際特許分類】
【出願番号】特願２０１０−５１７２５８（Ｐ２０１０−５１７２５８）
【出願日】平成２０年７月１８日（２００８．７．１８）
【国際出願番号】ＰＣＴ／ＣＮ２００８／０７１６９０
【国際公開番号】ＷＯ２００９／０１２７０１
【国際公開日】平成２１年１月２９日（２００９．１．２９）
【出願人】（５０２３８５８７２）華為技術有限公司 (139)
【Ｆターム（参考）】
【公表日】平成２２年１１月４日（２０１０．１１．４）
【国際特許分類】
【出願日】平成２０年７月１８日（２００８．７．１８）
【国際出願番号】ＰＣＴ／ＣＮ２００８／０７１６９０
【国際公開番号】ＷＯ２００９／０１２７０１
【国際公開日】平成２１年１月２９日（２００９．１．２９）
【出願人】（５０２３８５８７２）華為技術有限公司 (139)
【Ｆターム（参考）】
[ Back to top ]