JP5675807B2 - 動的なｒｔｃｐリレー - Google Patents

Description

本発明は、ネットワークにおいてＲＴＣＰメッセージを動的にリレーすることに関し、排他的にではないが、ネットワークにおいてＲＴＣＰメッセージを動的にリレーするための方法およびシステム、そのようなシステムにおいて使用するネットワーク要素およびユーザ機器、および該方法を実行するコンピュータプログラム製品に関する。

現在では、リアルタイムトランスポート（ＲＴＰ）プロトコルが、１つ以上の受信器にＩＰベースのネットワークを介してマルチメディアデータをストリーミングするために、および、関連するＲＴＰコントロールプロトコル（ＲＴＣＰ）が、メディアストリームに関する制御および管理情報を提供したりするために、それぞれ広く用いられる。ＲＴＣＰプロトコルは、様々な異なる方法のために用いられることが可能な、柔軟なプロトコルである。ＲＴＣＰプロトコルは、複数のソースメディアストリームの間の同期、例えば映像および音声のストリームの間のリップシンクを、単一の送信先によって可能にする機構の中核となっている。代替として、ＲＴＣＰプロトコルは、サービスの質またはネットワーク全体を監視するために用いられる。ＲＴＣＰフィードバックに基づいて、オペレータは適切な方策をとってネットワークの機能を向上させることができる。オペレータは、ＲＴＣＰメッセージによって提供された情報に基づいて、例えば、コード化すべきメディアソースを指示することによって、あるルート上のネットワーク輻輳を解消し、より少ない帯域消費でメディアストリームを送信することができる。

例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）アーキテクチャは、セッション開始プロトコル（ＳＩＰ）の柔軟性によって可能となる広範囲のサービスをサポートする統一されたアーキテクチャであるが、トランスポートプロトコルとしてＲＴＰを用いる。ＩＭＳはある３ＧＰＰおよび３ＧＰＰ２標準（例えば３ＧＰＰ ＴＳ ２２．２２８、ＴＳ ２３．２１８、ＴＳ ２３．２２８、ＴＳ ２４．２２８、ＴＳ ２４．２２９、ＴＳ ２９．２２８、ＴＳ ２９．２２９、ＴＳ ２９．３２８、およびＴＳ ２３．３２０ リリース５〜７など）によって定義される。ＩＰＴＶのためにＩＭＳを用いることは、あるＥＴＳＩ仕様（例えばＥＴＳＩ ＴＳ １８２ ０２７およびＥＴＳＩ ＴＳ １８３ ０６３など）によって定義される。ひとたびセッションがセッション開始プロトコル（ＳＩＰ）を用いることを確立すると、リアルタイムトランスポート（ＲＴＰ）プロトコルが、メディアソースまたは送信器から受信器へとマルチメディアをストリーミングするために用いられ、選択として、リップシンクおよびサービスの質の情報のためにメディア送信器と受信器の間でＲＴＣＰプロトコルを用いる。同様に、ＴＳ １８３ ０６４に記載されるようなＩＰＴＶアーキテクチャに統合された次世代ネットワーク（ＮＧＮ）は、ＨＴＴＰを用いてＲＴＰメディアセッションをセットアップする。

いくつかの用途、例えば送信先（グループ）間の同期、選択的な監視およびコンテンツ適合などのために、ＲＴＣＰメッセージ経路において個々のアクティブな要素を有することが有利でありうる。例えば特許文献１は、ＲＴＣＰ制御メッセージをインターセプトし、送信器と受信器の間で送信されたデータの品質を測定するためのプロキシサーバを記載している。さらに、特許文献２は、メディア送信器と受信器の間でＲＴＣＰメッセージを監視し、ＲＴＣＰ制御メッセージをインターセプトおよび修正してそれらの修正された制御メッセージをさらに受信器に転送することが可能な、中間メディアプロセッサを記載している。

ネットワークにおけるそのような知られているアクティブな要素の実施に関する１つの問題は、それらの要素がまずＲＴＣＰメッセージを受信して、ＲＴＣＰメッセージから情報を引き出すことを可能にする必要があるということに関する。従来技術による解決法は様々な方法でこれらの問題に対処する。

１つの解決法は、ネットワークノード内にアクティブな要素を配置し、すべてのＲＴＣＰメッセージ、および場合によってはすべてのＲＴＰメディアパケットがそこを通過し、アクティブな要素にそれらのＲＴＣＰパケットをインターセプトおよび検査するように指示して、ＲＴＣＰパケットから有用な情報を引き出すことである。この解決法は、アクティブな要素の使用をネットワーク内のある位置にのみ静的に制限することである。さらに、それらのタイプの状況においては、通常はわずかな量のＲＴＣＰトラフィックのみが監視されるので、そのような解決法は、ネットワークリソースを使用する効率的な方法を提供しない。最後に、サードパーティに制御されるアクティブな要素が、そのネットワーク上のＲＴＣＰトラフィックの全部または少なくとも一部をインターセプトおよび検査することを、オペレータが可能にしそうにないため、そのような解決法は、それらのアクティブな要素を使用する可能性を、サードパーティによって制御されるサードパーティのサービスに限定する。

それらのアクティブな要素をネットワーク内で使用するための他の解決法は、構成前の（ｐｒｅｃｏｎｆｉｇｕｒｅｄ）メディア送信器、メディア受信器およびアクティブな要素を用いて、アクティブな要素を介したＲＴＣＰメッセージ経路をリレーすることである。構成前であることは上記の欠点のいくつかを軽減することができるが、かなり静的であるという欠点を有する。ある方法でひとたび送信器、受信器およびアクティブな要素が、ＲＴＣＰメッセージをリレーするように構成前になると、ネットワークがその状況に拘束される。それは、オペレータが、異なるＲＴＣＰに基づくサービスのための異なるアクティブな要素を柔軟に選択することを可能にしない。また、例えばアクティブな要素が不調であるか更新を要する場合、１つのアクティブな要素を他の要素に素早く変更することを可能にしない。同様に、アクティブな要素がサードパーティによって管理されて制御される場合、構成前を用いる解決法は非常に柔軟性がない。

より一般的には、現在の世界的ＩＰネットワーク環境においては、多くの新しいメディア送信器が毎日毎秒ネットワークに接続される。したがって、受信器、送信器およびアクティブな要素内の静的な構成を適合させることによってこれらのメディア送信元についていき、適切なアクティブな要素を介してメディアの適切な送信器または受信器からＲＴＣＰメッセージをリレーすることはほとんど不可能である。

したがって、従来技術に対して、ＲＴＣＰメッセージをリレーする際に一層の柔軟性を提供する方法およびシステムの要求がある。

米国特許公開第２００８／０３２０１３２号明細書 国際公開第２００９／０７０２０２号

本発明の目的は、従来技術で知られている欠点の少なくとも１つを減少または消滅させ、本発明の第一の形態において、１つ以上のＲＴＰストリームに関連づけられたＲＴＣＰメッセージを動的にリレーする方法を提供することである。ここで各ＲＴＰストリームはメディアセッションに関連し、送信器ノードおよび１つ以上の受信器ノードに関連する。本方法は以下のステップを含む。少なくとも１つの制御ノードを少なくとも１つのＲＴＰストリームに割り当てるステップ。前記ＲＴＰストリームに関連づけられた受信器ノードに前記制御ノードのアドレスを提供するステップであって、セッション制御プロトコルメッセージまたはＨＴＴＰメッセージにおいて前記アドレスが前記受信器ノードに提供され、前記アドレスが、関連づけられた送信器ノードのアドレスとは異なるステップ。および、前記セッション制御プロトコルメッセージまたはＨＴＴＰメッセージに含まれる前記アドレスを用いて、前記受信器ノードが前記制御ノードに受信器ＲＴＣＰメッセージを送信するステップ。したがって、セッション制御プロトコルメッセージまたはＨＴＴＰメッセージをＵＥと、制御ノード、例えばＩＭＳ ＩＰＴＶシステム内のＩＰＴＣ ＳＣＦまたはＮＧＮ集積ＩＰＴＶシステム内のＣＦＩＡと、の間で交換することによって、リレー情報、例えばアクティブなネットワーク要素のアドレスおよび同期セッションＩＤなどのセッション識別子が、メディアセッションに含まれるネットワーク要素、例えばＵＥ、メディア送信器およびさらなるネットワーク要素、に提供されることができ、それによってメディア制御メッセージ、例えばＲＴＣＰメッセージが、さらなるネットワーク要素を介してリレーされることを可能とし、該さらなるネットワーク要素は、メディア同期アプリケーションサーバ（ＭＳＡＳ）、（サード）パーティメディアセッションモニタ、セッション境界コントローラなどのアプリケーションサーバであってもよい。

（ＳＩＰの場合と同様に）セッション制御プロトコルメッセージを用いるセッション制御状態装置の実施および維持を原則として必要としないため、実施が簡単であるという利点を、ＨＴＴＰは提供する。さらに、ＨＴＴＰは多くの方法（例えばＵＲＩ、ＳＤＰ、ＸＭＬなど）の搬送パラメータを許容し、同期グループ（Ｓｙｎｃ Ｇｒｏｕｐ）などのセッショングループを生成および削除するために用いられてもよい。

一実施形態では、前記方法は以下のステップをさらに含む。前記ＲＴＰストリームと関連づけられたグループ同期識別子を前記受信器ノードに提供するステップ、および、受信器ＲＴＣＰメッセージ内の前記グループ同期識別子を前記制御ノードに送信するステップ。

さらなる一実施形態では、方法は以下のステップをさらに含む。前記受信器ノードが同期ステータス情報を生成するステップ。受信器ＲＴＣＰメッセージ内の前記同期ステータス情報を前記制御ノードに送信するステップであって、前記制御ノードが、前記受信器ＲＴＣＰメッセージと関連づけられたＲＴＰストリームを、前記制御ノードに割り当てられた１つ以上の他のＲＴＰストリームと同期させる同期機能を有する、ステップ。

さらに別の一実施形態では、前記方法は以下のステップをさらに含む。前記同期機能が前記同期ステータス情報を用いて同期設定情報を計算するステップ。前記制御ノードが前記受信器ノードに前記同期設定情報を送信するステップ。前記受信器ノードが前記同期設定情報を用いて前記受信器ノードに関連づけられた遅延バッファに指示するステップ。

一実施形態では、方法は以下のステップをさらに含む。前記ＲＴＰストリームに関連づけられた前記送信器ノードに、前記制御ノードのアドレスを提供するステップであって、前記アドレスはセッション制御プロトコルメッセージまたはＨＴＴＰメッセージ内の前記送信器ノードに提供される、ステップ。前記送信器ノードが前記制御ノードに送信器ＲＴＣＰメッセージを送信するステップであって、前記セッション制御プロトコルメッセージ内に含まれる前記アドレスを使用する、ステップ。

別の実施形態では、前記方法は以下のステップをさらに含む。制御ノードが１つ以上の受信器ＲＴＣＰメッセージおよび１つ以上の送信器ＲＴＣＰメッセージを受信し、前記受信器ＲＴＣＰメッセージ内および前記送信器ＲＴＣＰメッセージ内のＲＴＰセッション識別子、好ましくはＳＳＲＣが同一である場合、受信器ＲＴＣＰメッセージを送信器ＲＴＣＰに関連づけるステップ。関連づけられた送信器ＲＴＣＰメッセージが発信されるアドレスに、制御ノードが受信器ＲＴＣＰメッセージを送信する、および／または、関連づけられた受信器ＲＴＣＰメッセージが発信されるアドレスに、制御ノードが送信器ＲＴＣＰメッセージを送信するステップ。

一変形例では、前記受信器ＲＴＣＰメッセージの少なくとも１つが同期ステータス情報を含み、前記方法はさらに以下のステップを含む。前記受信器ＲＴＣＰメッセージから前記同期ステータス情報を取り除くステップ。前記受信器制御メッセージを前記関連づけられた送信器ノードに送信するステップ。

さらなる変形例では、前記方法はさらに以下のステップを含む。前記同期機能が同期設定情報を提供するステップ。および、前記受信器ノードに送信器ＲＴＣＰメッセージ内の前記同期設定情報を送信するステップ。

さらなる変形例では、方法はさらに以下のステップを含む。少なくとも１つの送信器ノードが、前記ＲＴＰストリームの少なくとも１つおよび関連づけられた送信器ＲＴＣＰメッセージを、１つ以上の受信器ノードにマルチキャストするステップ。

さらなる実施形態では、方法はさらに以下のステップを含む。受信器ノードが前記ＲＴＣＰメッセージの少なくとも１つを前記制御ノードに送信するステップ。

一実施形態では、方法は以下のステップを含む。前記マルチキャストに関連づけられたメンバグループに制御ノードを参加させる要求を送信する、または、前記制御ノードに送信器ＲＴＣＰメッセージを提供するために送信器ノードと制御ノードの間のユニキャスト接続を提供するステップ。

別の実施形態では、方法は以下のステップを含む。制御ノードが、１つ以上の受信器ＲＴＣＰメッセージおよび１つ以上の送信器ＲＴＣＰメッセージを受信し、前記受信器ＲＴＣＰメッセージ内および前記送信器ＲＴＣＰメッセージ内のＲＴＰセッション識別子、好ましくはＳＳＲＣが同一である場合、受信器ＲＴＣＰメッセージと送信器ＲＴＣＰを関連づけるステップ。関連づけられた送信器ＲＴＣＰメッセージが発信されるアドレスに、制御ノードが受信器ＲＴＣＰメッセージを送信する、および／または、関連づけられた受信器ＲＴＣＰメッセージが発信されるアドレスに、制御ノードが送信器ＲＴＣＰメッセージを送信するステップ。

さらに別の実施形態では、前記セッション記述プロトコルはＳＩＰプロトコルまたはＲＴＳＰプロトコルである。さらなる変形例では、前記制御ノードは受信器ノードのグループを同期させる同期サーバである。または、前記制御ノードは、前記制御メッセージ内の情報、特にサービスの質、データトラフィック情報、および／またはデータ管理情報を監視するための、および／または、１つ以上の所定の規則に基づいて前記制御メッセージ内の情報を修正するための、１つ以上の機能を有する。

別の態様では、本発明はＲＴＣＰメッセージを動的にリレーするシステムに関し、システムは、１つ以上の受信器ノードによって生成された１つ以上の受信器ＲＴＣＰメッセージ、および／または１つ以上の送信器ノードによって生成された送信器ＲＴＣＰメッセージを受信する制御ノードと、前記制御ノードに関連づけられたリレー制御機能であって、前記制御機能が、前記ＲＴＰストリームに関連づけられた受信器ノードおよび／または送信器ノードに前記制御ノードのアドレスを提供するように構成され、前記アドレスはセッション制御プロトコルメッセージにおいて前記受信器ノードおよび／または送信器ノードに提供された、リレー制御機能と、前記セッション制御プロトコルメッセージ内に含まれる前記アドレスを用いて、前記制御ノードにＲＴＣＰメッセージを送信するように構成された少なくとも１つの受信器ノードと、を有する。

一変形例では、システムは、前記セッション制御プロトコルメッセージまたはＨＴＴＰメッセージ内に含まれる前記アドレスを用いて、前記制御ノードにＲＴＣＰメッセージを送信するように構成された少なくとも１つの送信器ノードを含み、前記制御ノードがさらに、１つ以上の受信器ノードから発信される受信器ＲＴＣＰメッセージおよび／または１つ以上の送信器ノードから発信される送信器ＲＴＣＰメッセージを受信する少なくとも１つの入力と、前記受信器ＲＴＣＰメッセージ内および前記送信器ＲＴＣＰメッセージ内のＲＴＰセッション識別子、好ましくはＳＳＲＣが同一である場合、送信器ＲＴＣＰに受信器ＲＴＣＰメッセージを関連づけるマッピング機能と、関連づけられた送信器ＲＴＣＰメッセージが発信されるアドレスに受信器ＲＴＣＰメッセージを送信する、および／または、関連づけられた受信器ＲＴＣＰメッセージが発信されるアドレスに送信器ＲＴＣＰメッセージを送信する、少なくとも１つの出力と、を有する。

さらなる変形例では、前記受信器ノードは前記受信器ＲＴＣＰメッセージ内の同期ステータス情報を挿入するように構成される。

一変形例のシステムでは、前記システムはさらに、前記制御ノードに関連づけられた同期機能を含み、前記機能は、１つ以上の受信器ノードによって前記制御ノードに送信された１つ以上の受信器ＲＴＣＰメッセージ内の同期ステータス情報を受信し、前記同期ステータス情報に基づいて、前記１つ以上の受信器ノードに関する同期設定情報を算出するように構成され、前記同期設定情報は、１つ以上の受信器ノードが、少なくとも１つのＲＴＰストリームを時間遅延させることを可能にする。

別の態様において、本発明は上記のようなシステムにおいて使用する受信器ノードに関し、受信器ノードは、制御ノードのアドレスを含むセッション制御プロトコルメッセージまたはＨＴＴＰメッセージを受信し、前記セッション制御プロトコルメッセージ内に含まれる前記アドレスを用いて、前記受信器ノードによって生成された受信器ＲＴＣＰメッセージを前記制御ノードに送信するように構成され、リレークライアントと、同期ステータス情報を生成し、前記同期ステータス情報を受信器ＲＴＣＰメッセージ内に挿入し、前記受信器ＲＴＣＰメッセージを前記制御ノードに送信するように構成された同期クライアントと、を有する。

本発明はまた、上記のようなシステムにおいて使用する制御ノードに関し、制御ノードは、１つ以上の受信器ノードから発信される受信器ＲＴＣＰメッセージおよび／または１つ以上の送信器ノードから発信される送信器ＲＴＣＰメッセージを受信する少なくとも１つの入力と、前記受信器ＲＴＣＰメッセージ内および前記送信器ＲＴＣＰメッセージ内のＲＴＰセッション識別子、好ましくはＳＳＲＣが同一である場合、受信器ＲＴＣＰメッセージを送信器ＲＴＣＰに関連づけるマッピング機能と、関連づけられた送信器ＲＴＣＰメッセージが発信されるアドレスに受信器ＲＴＣＰメッセージを送信する、および／または、関連づけられた受信器ＲＴＣＰメッセージが発信されるアドレスに送信器ＲＴＣＰメッセージを送信する、少なくとも１つの出力と、所望により、１つ以上の受信器ＲＴＣＰメッセージ内の１つ以上の受信器ノードによって前記制御ノードに送信された同期ステータス情報を受信し、前記同期ステータス情報に基づいて、前記１つ以上の受信器ノードに関する同期設定情報を算出するように構成された同期機能と、を有し、前記同期設定情報は、１つ以上の受信器ノードが、少なくとも１つのＲＴＰストリームを時間遅延させることを可能にする。

本発明はさらに、１つ以上のネットワークノードのメモリ内で実行された場合に上記の方法ステップを実行するように構成されたソフトウェアコード部分を含む、コンピュータプログラム製品に関する。

本発明は添付の図面を参照してさらに記載され、該図面は本発明による実施形態を概略的に示す。本発明はこれらの特定の実施形態に何ら制限されるものではないことが理解される。

本発明の一実施形態によるシステムを示す図である。 本発明の一実施形態による方法のメッセージフロー図である。 本発明の一実施形態による方法の代替のメッセージフロー図である。 本発明の一態様によるＲＴＣＰ ＸＲリポートブロックの可能な定義を示す図である。 本発明のさらなる実施形態によるＲＴＣＰ ＸＲリポートブロックに関する可能な定義を示す図である。 本発明のさらなる実施形態による別のメッセージフロー図である。 ＩＰマルチキャストシナリオにおける本発明による一実施形態のためのメッセージフロー図である。 本発明のさらなる態様によるＲＴＣＰ ＸＲリポートブロックに関する可能な定義を示す図である。 本発明のさらなる実施形態による別のフロー図である。 本発明の一実施形態によるさらなるシステムの図である。 本発明の一実施形態によるメッセージフロー図である。 本発明のさらなる実施形態によるＩＰマルチキャストシナリオによるフロー図である。

図１は、ＥＴＳＩ ＴＩＳＰＡＮ ＴＳ １８３ ０６３およびＴＳ １８２ ０２７によって定義されたＩＭＳベースのＩＰＴＶシステム１００の例を示す図である。システムは本発明の第１の実施形態によるＲＴＣＰメッセージを動的にリレーするように構成されている。システムは、セル／セッション制御機能（ＣＳＣＦ）、例えばプロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、問い合わせＣＳＣＦ（Ｉ−ＣＳＣＦ）、およびサービングＳＣＳＦ（Ｓ−ＣＳＣＦ）のセットを構成するＩＭＳコア１０７を含む。ＩＭＳコアはユーザ機器（ＵＥ）１０５、ネットワーク（例えばブロードキャストＳＣＲ、コンテンツオンデマンドＳＣＦなど）内のＩＰＴＶサービスを制御するＩＰＴＶサービス制御機能（ＳＣＦ）１０６、およびメディア機能（ＭＦ）１０１に接続される。メディア機能は、メディア制御機能（ＭＣＦ）１０２およびメディア配信機能（ＭＤＦ）１０３を含み、メディア配信機能はメディアコンテンツの配信を制御し、搬送機能（ＴＦ）１０４を介するユーザ機器へのパケットを制御する。

ＴＳ１８２ ０２７からのアーキテクチャは、送信先間同期機能を実行するように構成されたメディア同期アプリケーションサーバ（ＭＳＡＳ）１０８によって拡張される。送信先間メディア同期とは、あるメディアが表示される時刻がそのメディアの異なる送信先と同じである、すなわち、同じ映像の断片または音声サンプルが異なる送信先で同時に再生されることを意味する。ユーザ機器またはネットワークノードにおける同期活動は、同期クライアント（ＳＣ）１０９の位置においてバッファ１１０を用いて実施されてもよい。同期クライアントはＭＳＡＳと相互作用して、受信されたメディアストリームを遅延させるようにバッファに指示することによってバッファの作用を連係させる。

図１におけるＩＰＴＶシステムはセッション初期化プロトコル（ＳＩＰ）を用いて、ユーザ端末間の、またはユーザ端末とＳＣＦおよびＭＦを含むアプリケーションサーバとの間のセッションをセットアップおよび制御する。ＳＩＰシグナリングによって搬送されるセッション記述プロトコル（ＳＤＰ）が用いられて、セッション内のメディア構成要素を記述およびネゴシエート（ｎｅｇｏｔｉａｔｅ）する。さらに、リアルタイムストリーミングプロトコル（ＲＴＳＰ）が用いられて、例えばブロードキャストトリックモード、コンテンツオンデマンド（ＣｏＤ）およびネットワークパーソナルビデオレコーダ（ＮＰＶＲ）などのメディア制御が提供され、リアルタイムトランスポートプロトコル（ＲＴＰ）が用いられて、メディアが搬送される。

図２はＵＥがユニキャストコンテンツオンデマンドメディアストリームを受信する場合の本発明の例示的な実施形態によるプロトコルフロー図である。この実施形態において、ＵＥのユーザはコンテンツオンデマンド（ＣｏＤ）を受信することおよび、他のＵＥの１人以上のユーザと同期してそれを見ることを望む。特定のＵＥのＣｏＤ ＲＴＰストリームのプレイアウト時間は、したがって、他の関連するＣｏＤ ＲＴＰストリーム（例えば同じ映画）を受信する他方のＵＥのプレイアウト時間と同期させる必要がある。

この例において、ＳＩＰプロトコルが使用されて、ＥＴＳＩ ＴＳ １８３ ０６３ ＲＴＳＰ方法１によるセッションセットアップが行われる。第１のステップにおいて、ＵＥはＳＣＦに初期ＳＩＰ ＩＮＶＩＴＥメッセージを送信する。このＳＩＰ ＩＮＶＩＴＥは、特定のＵＥが所属する同期グループを識別する、ＳｙｎｃＧｒｏｕｐＩｄと呼ばれるパラメータを含む。この例において、ＳｙｎｃＧｒｏｕｐＩｄはＵＥにすでに知られていると考えられている。しかしながら他の実施例もまた可能である。ＳｙｎｃＧｒｏｕｐＩｄは、例えばセッション設置アップの間にＳＣＦによって割り当てられてもよく、ステップ４のＳＩＰ ２００ ＯＫメッセージにおいて最初にＵＥと通信してもよい。

同期グループは、１つ以上の指定されたメディアストリームに関して同期される必要があるＵＥのグループである。そのようなグループの例は、互いに同期して同じコンテンツオンデマンド（映画）を見ることを要求する、２つの異なる位置において２つの異なるユーザに所属する２つのＵＥであってもよい。

ＳｙｎｃＧｒｏｕｐＩｄパラメータはセッション記述プロトコル（ＳＤＰ）セッションレベル属性、例えばａ＝ＲＴＣＰ−ｘｒ：ｓｙｎｃ−ｇｒｏｕｐ＝＜ｖａｌｕｅ＞として実施されてもよい。一実施形態では、ＩＥＴＦ ＲＦＣ ３６１１から知られるＲＴＣＰ−ｘｒ属性フィールドが用いられてもよい。というのは、ＲＴＣＰプロトコルのアプリケーション特有の拡張に関する情報を通信する意図があるからである。ＳＣＦはセットアップ要求を受信し、ユーザを同期グループに加えてもよい。そしてＳＣＦは、この同期セッションに適切なＭＳＡＳを選択してもよい。ステップ２において、ＳＩＰ ＩＮＶＩＴＥメッセージがＳｙｎｃＧｒｏｕｐＩｄと選択されたＭＳＡＳのネットワークアドレスの両方を含む適切なＭＦに送信される。このＭＳＡＳアドレスは別のセッションレベル属性に含まれてもよい、例えば、ＩＥＴＦ ＲＦＣ ３６５０からのＳＤＰにおけるＲＴＣＰ属性を用いてもよい。ＭＦに送信されたＲＴＣＰ属性もまたポート番号を含んでもよい。ＭＦは、このセッションに関連するＲＴＣＰメッセージの送信先である新しいアドレス指示としてＳＩＰメッセージ内に含まれるＲＴＣＰ属性からの情報を用いてもよい。代替のポート番号がＳＩＰ ＩＮＶＩＴＥメッセージ内で通信されていない場合は、ＭＦはＩＥＴＦ ＲＦＣ ３５５０に従って、ＲＴＣＰメッセージを送信するためのデフォルトのＲＴＣＰポート番号、すなわちＲＴＰポート番号を取り出して１を加えたもの、を用いてもよい。

セッションセットアップ（ＳＩＰ ＩＮＶＩＴＥ）メッセージを受信すると、ＭＦは要求されたＲＴＰストリームをＳＳＲＣ識別子に割り当てる。ステップ３において、ＭＦはＳＩＰ ２００ ＯＫ応答をＳＩＰ ＩＮＶＩＴＥに送信し、該ＳＩＰ ２００ ＯＫ応答はＳｙｎｃＧｒｏｕｐＩｄと、メディアストリームに関して新しく生成されたＳＳＲＣ識別子の両方を含む。メディアストリームを一意的に識別するＳＳＲＣは、ＩＥＴＦ ＲＦＣ ５５７６に基づいてＳＤＰにおけるメディアレベル属性を用いて送信されてもよい。ステップ４において、ＳＣＦはＵＥにＳＩＰ ２００ ＯＫメッセージを送信し、それは最終確認としての応答である。このＳＩＰ ２００ ＯＫメッセージは要求されたメディアストリームのＳＳＲＣ、ＭＳＡＳアドレス、および、選択として、１つ以上の代替のＲＴＣＰポート番号を含む。加えて、ＳＩＰメッセージは新しく割り当てられた、または了承されたＳｙｎｃＧｒｏｕｐＩｄを含んでもよい。ＵＥは、このセッションに関するＲＴＣＰメッセージを送信する新しいアドレスの指示として、受信されたＭＳＡＳアドレスおよび代替のポート情報を用いてもよい。さらに、特に、メディアストリームの送信元（送信器）アドレスと異なるアドレスを有するＭＳＡＳに、ＲＴＣＰを介して同期ステータス情報を送信するためにこれらの新しいアドレス指示を用いてもよい。

代替のポート番号がＳＩＰ ＯＫ メッセージにおいて通信されない場合、ＵＥはＩＥＴＦ ＲＦＣ ３５５０に従って、ＲＴＣＰメッセージを送信するためのデフォルトのＲＴＣＰポート番号、すなわちＲＴＰポート番号を取り出して１を加えたもの、を用いてもよい。ステップ５および６において、ＵＥおよびＳＣＦの両方が、ＳＩＰ ＡＣＫメッセージと共に受信されたＳＩＰ ＯＫメッセージに応答する。

ステップ７において、ＲＴＳＰ制御は実際のメディアストリームをセットアップするために用いられ、メディアストリームはＭＦからＵＥへのストリーミングを開始する。メディアストリームのセットアップの方法はＥＴＳＩ ＴＳ １８３ ０６３に記載される。ステップ８において、メディアストリーム配信の最中に、ＵＥは同期ステータス情報およびＳｙｎｃＧｒｏｕｐＩｄにそのＲＴＣＰ受信器レポート（ＲＴＣＰ ＲＲ）を含めてもよい。これは、例えばＲＴＣＰ拡張レポート（ＲＴＣＰ ＸＲ）を用いて行われてもよく、ＩＥＴＦ ＲＦＣ ３５５０に従ってＳＤＥＳ ＰＲＩＶアイテムの形態で行われてもよい。ＵＥはこの情報をＲＴＣＰメッセージとしてＭＳＡＳに送信する。

ステップ９において、ＭＦはそのＲＴＣＰ送信器レポート（ＲＴＣＰ ＳＲ）をＲＴＣＰメッセージとしてＭＳＡＳに送信する。送信を行うメディア発信元（ＭＦ）と受信を行うメディア送信先（ＵＥ）の両方のＲＴＣＰメッセージが、ＭＳＡＳによって受信され、共通のメディアストリーム識別子（ＳＳＲＣ）を有する。

ＭＳＡＳは今や、受信するレポートのそれぞれにおいてＳＳＲＣを合致させるように、ＵＥから受信されたＲＴＣＰメッセージをＭＦに転送し、ＭＦから受信されたＲＴＣＰメッセージをＵＥに転送する。ＳＳＲＣ識別子は所与のＲＴＰストリームごとに一意的であり、したがって、同一のＳＳＲＣ識別子を含む、メディア送信器（ＭＦ）からのＲＴＣＰメッセージとメディア受信器（ＵＥ）からのＲＴＣＰメッセージは、合致することができる。ステップ１０および１１において、受信されたメディア送信器レポートＲＴＣＰメッセージは、合致するメディア受信器レポートＲＴＣＰメッセージが発信されるＩＰアドレスに送信され、逆もまた同様である。ＭＳＡＳは、同一のＳｙｎｃＧｒｏｕｐＩＤを有する複数のＵＥから受信されるＲＴＣＰメッセージからの同期ステータス情報を用いて、同期セッション内に含まれるＵＥのそれぞれに対する設定指示を算出する。同期グループ内のそれぞれのＵＥに関する遅延情報を含んでもよいこれらの設定指示は、特別なＲＴＣＰ ＸＲ内に含まれてもよく、上記のような機構を用いて各ＵＥにＲＴＣＰメッセージとして送信されてもよい。

図３は本発明の一実施形態による別の例示的なメッセージフロー図である。この実施形態において、ＥＴＳＩ ＴＳ １８３ ０６３ ＲＴＳＰ方法２に従って、メディアセッションはＳＩＰおよびＲＴＳＰの組み合わせを用いてセットアップされる。ステップ１から６は図２に記載されたメッセージフロー図のステップ１から６と同様であり、したがってさらに詳細には記載しない。図２および３のステップ１から６に関するメッセージフロー図の唯一の相違は、図３によって示される方法のＳＩＰ ＯＫメッセージ（ステップ３および４）においてはＳＳＲＣ識別子が存在しないことである。その結果として、図３におけるメッセージフロー図の後続のステップは、図２のそれらとわずかに異なる。

ＥＴＳＩ ＴＳ １８３ ０６３ ＲＴＳＰ方法２に従って、（ＳＩＰ ＩＮＶＩＴＥを用いるかわりに）ＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージを用いてメディアレベル属性が（ネゴシエート／交換に）セットアップされる。ＭＦによって生成されて割り当てられたＳＳＲＣ識別子は、ＲＴＰメディアストリームに一意的なメディアレベル属性であるから、ＭＦは、ＳＳＲＣ識別子ではなくＳｙｎｃＧｒｏｕｐＩｄおよびＭＳＡＳアドレスを含むＳＩＰ２００ ＯＫでＳＩＰ ＩＮＶＩＴＥに応答する。ＲＴＳＰチャネルのＳＩＰセッションのセットアップの後、ＵＥはＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージを用いて実際のメディアストリームをセットアップする。ステップ７でＭＦがこのＤＥＳＣＲＩＢＥメッセージを受信すると、ＭＦはＳＳＲＣ識別子を生成して割り当て、この識別子をＲＴＳＰ ２００ ＯＫメッセージに加え、ＲＴＳＰ ２００ ＯＫメッセージは、ステップ８においてＤＥＳＣＲＩＢＥメッセージに応じてＵＥに送信される。これは、ＩＥＴＦ ＲＦＣ ５５７６に従ってＳＤＰにおけるメディアレベル属性を用いて、ＲＴＳＰ ２００ ＯＫメッセージに含まれるメディアのＳＤＰ記述内で行われてもよい。メディアフローの開始から、ＲＴＣＰリレー機構を含む後続のステップは、図２および図３にそれぞれ記載された実施形態と同様である。

一般に、同期ステータス情報は各同期クライアント（ＳＣ）のメディア受信に関するタイミング情報として最良に記載されることができる。同期クライアント（ＳＣ）はユーザ機器（ＵＥ）または、メディアパケットの受信が測定可能なネットワーク内の他の任意のポイントに位置することができる。ＳＣは同期サーバ（ＭＳＡＳとも呼ばれる）と協働して、異なる受信器で受信されたストリームを同期させるか、同じ受信器で受信された異なるストリームを同期させる。受信器はメディアストリームの最終送信先であっても中間送信先であってもよい。同期ステータス情報を決定するためのサンプリングポイントのそれぞれが、同期ポイントと呼ばれてもよい。

図４は、同期ステータス情報を搬送するためのＲＴＣＰ ＸＲレポートブロックに関する可能な定義を示す。第１の行はヘッダ情報を含み、ヘッダ情報はＲＴＣＰ ＸＲレポートブロック、予約されたスペース、およびブロック長を定義する所定のブロックタイプを含む。第２の行はＲＴＰメディアストリームのＳＳＲＣ識別子を含み、そこでＲＴＣＰレポートブロックがレポートを行う。第３の行はＲＴＰストリームの受信器のＮＴＰタイムスタンプを含む。このＮＴＰタイムスタンプは６４ビットを必要とし、最も重要なワードおよび最も重要でないワードに分けられる。最後に、このＮＴＰ時間（タイムスタンプ）に受信されたパケットのＲＴＰタイムスタンプ、およびこのＮＴＰ時間に表示される（プレイアウトされる／提示される）パケットのＲＴＰタイムスタンプが与えられる。受信器のグループ同期は、パケット受信タイムスタンプに基づいて行われてもよく、実際のパケット表示／提示タイムスタンプに基づいて行われてもよく、同期サーバの構造に依存する。異なるタイプのＵＥが、受信インターフェイスと表示インターフェイスの間で異なる遅延を示す可能性があるため、ユーザエクスペリエンスを最大にするためには、実際の表示／提示タイムスタンプを用いることが好ましい。しかしながら、異機種ネットワーク環境にあるすべてのユーザ機器が実際の表示時間をレポートすることができるとは限らないため、好ましくは（しかしながら必要ではないが）パケット受信とパケット表示の両方のタイムスタンプが、ＵＥ（受信器）によってＭＳＡＳに送信されるＲＴＣＰ ＸＲレポートに含まれる。

一般的には、同期設定指示は、同期クライアント（ＳＣ）がどれだけメディアストリームを遅延させるかをそこから直接的にまたは間接的に導き出すことができる指示（または指標）として最良に記載される。メディアストリームは、例えばブロードキャスト（ＢＣ）チャネル、ユニキャストまたはマルチキャスト（チャネル）であってもよい。同期クライアントはしたがって、関連するメディアストリームを遅延させるように、適切なバッファにさらに指示してもよい。

図５は、同期設定指示を搬送するためのＲＴＣＰ ＸＲレポートブロックの可能な定義を示す。ＩＥＴＦインターネットドラフトｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｃｐｓｓｍ−１８による受信器要約情報パケットのフォーマットがここで用いられる。この例におけるＲＴＣＰ ＸＲブロックが、すべてのＲＴＰタイムスタンプの算出の根拠となるＮＴＰタイムスタンプをレポートする。それは、すべてのＵＥのＲＴＰタイムスタンプがマッピングされるＮＴＰタイムスタンプを含み、その特定の時刻における同期グループ内の全てのＵＥのＲＴＰタイムスタンプの最小値および最大値を含む。報告は複数のＲＴＰタイムスタンプを含んでもよく、しかしながら、送信先間同期の目的のためには、ＲＴＰタイムスタンプの最小値（最も遅延しているストリームに対応する）のみが必要となる。この情報（同期設定指示）から、各同期クライアントが、最も遅延しているストリームに対して自身のストリームをどれだけ遅延させるべきか算出することが可能である。

代替として、ＭＳＡＳは（すべてのＳＣから受信されたＲＴＰタイムスタンプの測定値の中で最小の値よりも小さい）任意の値を送信するだけでもよく、それはＳＣが自身のストリームを同期させるために用いられるべきものである。これはネットワークにおける自然な遅延の変動を抑制し、ＳＣがバッファを頻繁に再調整する必要をなくす。

図６は本発明の実施形態による別の例示のフロー図である。メッセージフロー図は図２のフロー図のメディアセッションセットアップおよび同期機構と同様であるが、図６に記載の実施形態は、２つのＵＥ（ＵＥ１およびＵＥ２）のそれぞれが異なるメディアソース（ＭＦ１およびＭＦ２）からのメディアストリームを受信し、両方のメディアストリームを同期させる必要があるという状況を示すという点で異なる。

この実施形態において、ＳＣＦはセッションセットアップの最中に、個々のセッションの両方に同じＭＳＡＳ（ＭＳＡＳアドレスおよび選択としてＲＴＣＰポート番号）を割り当てる。これにより、ＵＥ１、ＵＥ２、ＭＦ１およびＭＦ２のいずれもが、同じＭＳＡＳにそれらのＲＴＣＰメッセージを送信する。ＭＦ１からＵＥ１へのメディアストリームに関するＳＳＲＣ識別子は、ＭＦ２からＵＥ２へのメディアストリームに関するＳＳＲＣ識別子と異なるため、ＭＳＡＳはＭＦ１から受信するＲＴＣＰメッセージ（およびそれに含まれるレポート）をＵＥ１から受信するＲＴＣＰメッセージと合致させることが可能であり、同様に、ＭＦ２と合致するＲＴＣＰメッセージをＵＥ２から受信するＲＴＣＰメッセージと一致させることが可能である。したがって、ＭＳＡＳは、すでに明細書中に記載された機構を用いて、正しいＵＥ（メディアストリーム受信器）およびＭＦ（メディアストリーム送信器）にＲＴＣＰを転送してもよい。

ＭＳＡＳは、ＵＥ１とＵＥ２から受信されたＲＴＣＰメッセージから抽出された関連の同期設定情報に基づいて、ＵＥ１に到達する（またはＵＥ１によって表示／提示される）メディアストリームとＵＥ２に到達する（またはＵＥ２によって表示／提示される）メディアストリームを同期させる遅延設定指示を算出または決定してもよい。ＭＳＡＳはＵＥ１に送信されるＲＴＰストリームに関連する同期ステータス情報を、ＵＥ２に送信されるＲＴＰストリームに関連する同期ステータス情報と合致させることができる。というのは、ＵＥ１とＵＥ２の双方が、ＭＳＡＳに送信されるそれらのＲＴＣＰメッセージの少なくとも一方内で、ＭＳＡＳに同一のＳｙｎｃＧｒｏｕｐＩｄパラメータをレポートするかレポートしたからである。ＭＳＡＳは、以前に記載したように、ＭＦから受信されたＲＴＣＰメッセージに遅延設定指示を加え、それからそれぞれのＵＥにそれらメッセージを送信する。

異なる発信元から異なるＵＥへの異なるメディアストリームの同期は、ＭＦ１とＭＦ２がそれぞれのメディアストリームをプレイアウトしたときに、ＭＦ１とＭＦ２のいずれかが無作為なオフセットではなく同一のＲＴＰタイムスタンプを用いることを要求し、または、ＲＴＰタイムスタンプ間の相関が、アプリオリに知られているか、ＭＳＡＳが遅延設定指示の算出または決定を開始する前にＭＳＡＳに提供されていることを要求する。

通常は、ＩＰマルチキャストの最中に、ＲＴＰパケットおよびＲＴＣＰパケットの両方がマルチキャスト機構を用いて送信される。メディアの送信器と受信器の両方が、メディアトラフィックと同じマルチキャストアドレスにそれらのＲＴＣＰレポートを送信するが、ＲＴＰトラフィックと比較して２番目に大きいポート番号を用いる。インターネットドラフトｄｒａｆｔ−ｉｅｔｆ−ａｖｔ−ｒｔｃｐｓｓｍ−１８において、システムは単一発信元マルチキャスト（ＳＳＭ）における使用のために記載され、メディアは１つのみの送信元から多くの受信器にストリーミングされる。ＳＳＭにおいてメディアの受信機は通常は同一のマルチキャストアドレスに（ＲＴＣＰを）送信するべきではない。これは、多くの視聴者を伴うＩＰＴＶマルチキャストの場合、割り当てられたネットワークリソースが、必要とされないだろうコンテンツのないトラフィック（例えばＲＴＣＰ制御メッセージ）で溢れることがないように、特にあてはまる。ドラフトは、受信器によるＲＴＣＰレポートの送信のためにユニキャスト機構の使用を提案する。受信器はいわゆるフィードバックターゲットにそれらのＲＴＣＰレポートをユニキャストする。さらに、送信器からのメディアを受信する配信元が導入され、配信元はそのメディアを受信機に配信する。同様に、配信元は送信器と受信器の間のＲＴＣＰメッセージの配信を担当する。

フィードバックターゲットは配信元から離れていてもよいが、配信元の搬送アドレスはフィードバックターゲット内に構成されていなければならず、したがってフィードバックターゲットはＲＴＣＰメッセージを配信元にリレーすることができる。同様に、本明細書によれば、受信器はフィードバックターゲットアドレスにあらかじめ構成される必要があり、したがって受信器はそれらのＲＴＣＰメッセージをどこに送信するかアプリオリに知っている。言い換えれば、メディアの受信器によって生成されたＲＴＣＰメッセージのリレー機構全体は安定であり（あらかじめ構成されており）、ネットワーク内に配信元と呼ばれる新しいエンティティの存在が必要となる。

図７はＩＰマルチキャストシナリオにおける本発明の例示的な実施形態のメッセージフロー図である。この実施形態はマルチキャストチャネルに加入する受信器（ＵＥ）の送信先間同期に関する。このシナリオは、例えば２人のユーザが、異なった位置の異なったＵＥで同期して同じライブコンテンツ（例えばマルチキャストのサッカー試合）を視聴することを望む場合に当てはまる。彼らは継続的なチャットセッションまたはオープンな電話回線を有して、一方のユーザが相手よりも前にゴールの瞬間を見るという危険を冒すことなく、一緒に試合を楽しむことができる。

本明細書に詳述された本発明は、コンテンツプロバイダとは異なる第３者によって配信されることができる、追加の「別々に一緒に見る（ｗａｔｃｈｉｎｇ ａｐａｒｔ ｔｏｇｅｔｈｅｒ）」同期サービスの基礎として用いられてもよいとみなされる。このシナリオに適した、本発明の可能な実施形態は下に記載される。この実施形態では、同期サービスはユーザがマルチキャストに参加する前、セッションのセットアップの最中に開始される。

ＥＴＳＩ ＴＳ １８３ ０６３によれば、受信者がマルチキャストに参加することを望む場合、適切なＳＣＦとのセッションをまずセットアップする必要がある。それは、図７のステップ１から３に従って、ＳＩＰメッセージを用いることによって行うことができる。この実施形態では、ステップ１のＵＥによって送信されたＳＩＰ ＩＮＶＩＴＥは、ＳｙｎｃＧｒｏｕｐＩｄと呼ばれるパラメータをすでに含み、ＳｙｎｃＧｒｏｕｐＩｄはＵＥが属する同期グループを識別する。代替として、ＳｙｎｃＧｒｏｕｐＩｄはＳＣＦによって割り当てられ、ステップ２でＵＥに送信される。

ＳｙｎｃＧｒｏｕｐＩｄがどのようにしてパッケージされるかの例示的な実施例は、セッション記述プロトコル（ＳＤＰ）セッションレベル属性、例えばａ＝ＲＴＣＰ−ｘｒ：ｓｙｎｃ−ｇｒｏｕｐ＝＜ｖａｌｕｅ＞を用いる。ＳＣＦはセットアップ要求を受信し、適切な同期グループにユーザを加えることができる。ＳＣＦはしたがって、この同期セッションに関する適切なＭＳＡＳを選択して、ＩＮＶＩＴＥへの応答、すなわちステップ２のＳＩＰ ２００ ＯＫメッセージ内でＭＳＡＳ搬送アドレスを送信する。このＭＳＡＳアドレスは、例えばＩＥＴＦ ＲＦＣ ３６０５からのＳＤＰ内のＲＴＣＰ属性を用いており、例えば別のセッションレベル属性内に含まれることができる。ポート番号はＩＥＴＦ ＲＦＣ ３５５０に従って、すなわちＲＴＰポート番号を取り出して１を加えるように、通常のＲＴＣＰポート番号と同様に選択されてもよい。

次に、ステップ４において、メディアフローは特定のメディアストリームに加入するように、例えばＩＧＭＰを用いてセットアップされる。ＵＥは今や、ステップ５において、ＳＣＦから受信されたＭＳＡＳアドレス（ＲＴＣＰリレーアドレス）を用いて、同期ステータス情報を含むＲＴＣＰメッセージをＭＳＡＳに直接送信することができる。これらのＲＴＣＰメッセージは同期ステータス情報およびＳｙｎｃＧｒｏｕｐＩｄを送信するために適切に拡張された受信器レポートメッセージであってもよい。この実施形態では、すべてのマルチキャスト受信器が同一のＲＴＰタイムスタンプを含む同一のマルチキャストストリームを受信し、したがって、ＭＳＡＳは同期指示を算出するためにいかなるＲＴＣＰ送信器レポート情報も必要としない。同様に、ＭＳＡＳは、ＵＥから受信されたＲＴＣＰメッセージが送信される必要があるメディア送信器を決定するための送信レポートを要求しない。というのは、ＳＳＭ構造のメディア送信器は多くの場合にＵＥ（メディア受信器）からいかなるＲＴＣＰメッセージもまったく受信しないからである。様々なＲＴＣＰメッセージ間に合致がまったくないことが、この実施形態において必要となり、したがってＲＴＣＰメッセージ内に含まれるＳＳＲＣもまたＭＳＡＳによっては用いられない。そのかわりに、ステップ６で示されるように、ＭＳＡＳは、適切なＵＥへのユニキャストＲＴＣＰメッセージ（例えばそのような設定を含むＲＴＣＰ拡張レポート）を用いて、以前に受信したＲＴＣＰメッセージの発信されたアドレスを用いるだけで、その同期設定指示を送信するのみでよい。

特定の場合のマルチキャスト環境においてはＭＳＡＳは同期に関する送信器レポートを要求してもよい。例えば、異なる受信者は同一のコンテンツを、たとえば一方のマルチキャストチャネルは高品位ストリームであるのに対し別のマルチキャストチャネルはＳＤストリームであるように、異なるストリームで見るためである。これらの送信器レポートはいくつかの異なる方法でＭＳＡＳによって得られてもよい。

図８はＭＳＡＳによってＲＴＣＰ送信器レポートを受信するための３つの実施形態を表す。第１の実施形態（選択肢１）において、マルチキャストの受信器は送信器レポートに、それがＭＳＡＳにＲＴＣＰメッセージとして送信した受信器レポートを加える。すべてのマルチキャスト受信器は同一のマルチキャストアドレス上で、しかし異なるポート番号上で、送信器レポートを受信する。すべてのマルチキャスト受信器は、これらの送信器レポートのコピーをＭＳＡＳに送信してもよい。

第２の実施形態（選択肢２）において、ＭＳＡＳはマルチキャストチャネルに加入する。ＭＳＡＳは適切なＩＧＭＰメッセージを送信し、マルチキャストグループのメンバとなる。ＭＳＡＳはしたがって、ＲＴＣＰメッセージを含むこのグループに送信されたすべてのメッセージを受信する。マルチキャストトラフィックの粒度はアドレスにのみ依存し、ポート番号には依存しないため、このことはＭＳＡＳがすべてのメディアトラフィックを受信することを意味する。これを阻止するために、ネットワークは好ましくはメディアトラフィックを除去してＲＴＣＰトラフィックのみを転送する。このことは多少は容易に達成される。というのは、標準配置において、ＲＴＰは偶数のポート番号のみを用いるべきであり、ＲＴＣＰは奇数のポート番号のみを用いるべきだからである。

第３の実施形態（選択肢３）において、メディア発信元（メディア機能ＭＦ）はユニキャスト機構を用いて、その送信器レポートのコピーをＭＳＡＳに送信する。

ＭＳＡＳが送信器レポートを受信することが可能な場合、それはもはや、受信器レポートを送信することを可能にするために、メディア発信元の送信アドレスの構成を必要としない。それどころか、メディア送信器の正しい搬送アドレスを決定するために上記の機構を用いて、メディア受信器からのＲＴＣＰメッセージからのＳＳＲＣをメディア送信器からのＲＴＣＰメッセージからにＳＳＲＣと一致させる同一の動的な機構を用いてもよい。

この代替の実施形態によるメッセージフロー図がさらに図９に示される。例として、メディア受信器（ＵＥ）からＭＳＡＳによってステップ５で受信されたＲＴＣＰ ＲＲ（受信器レポート）メッセージが、メディア送信器からＭＳＡＳによってステップ６において受信された適切なＲＴＣＰ ＳＲ（送信器レポート）と、ＳＳＲＣにおいて合致する。ステップ７において、合致に基づいて、ＭＳＡＳはＲＴＣＰ ＲＲメッセージをＭＦに転送する。この動的なリレー機構は、メディア送信器の搬送アドレスによってＭＳＡＳをあらかじめ構成することを、もはや不要にする。それは、したがって、ＲＴＣＰメッセージをリレーする柔軟で明解な方法を提供する。

図９において示される実施形態においては、ＭＳＡＳによってメディア送信器からＲＴＣＰメッセージの受信を可能にするためにいくつかの構成が必要となるかもしれないことに留意する。ＭＳＡＳが、（例えば前記ＲＴＣＰメッセージを得るために）例えばマルチキャストアドレスへの認可を必要とする場合、それはこのアドレスと共にあらかじめ構成されているか、何か他の機構によってこのアドレスを得る必要がある。メディア送信器（ＭＦ）がユニキャスト機構を用いてそのマルチキャストされたＲＴＣＰメッセージのコピーを送信する必要がある場合、それはＭＳＡＳのユニキャストアドレスを必要とする。受信器がＲＴＣＰメディア送信器メッセージをＭＳＡＳに転送する場合、ＭＳＡＳはＭＦの搬送アドレスを知ることがなく、したがってこの場合にはＭＳＡＳはメディア送信器に受信器レポートを転送することができない。したがって、送信器はそのＲＴＣＰメッセージ内にメディア送信器（ＭＦ）の送信アドレスを含んでもよく、しかしながら、このことはＲＴＣＰへの別の拡張を定義することを必要とする。

図１０は本発明の別の実施形態の概略を示す。特に、図１０はＥＴＳＩ ＴＩＳＰＡＮ ＴＳ １８３ ０６４によって定義されたものとして次世代ネットワーク（ＮＧＮ）統合ＩＰＴＶシステムの概略を示す。そのようなＮＧＮ統合ＩＰシステムのアーキテクチャの一般的なレイアウトは、図１を参照して記載されたＩＭＳシステムとほぼ同様であり、本発明のさらなる実施形態に基づくＲＴＣＰメッセージを動的にリレーすることに適している。

ＮＧＮ統合ＩＰＴＶシステムはＩＰＴＶコア（ＩＰＴＶ−Ｃ）１００７および、ＨＴＴＰベースの顧客に向いたＩＰＴＶアプリケーション（ＣＦＩＡ）１００６を含む。ＩＰＴＶ−Ｃは、システムに接続されたユーザ機器ＵＥ１、ＵＥ２ １００５がＣＦＩＡによって許可されているかどうかをチェックし、メディア制御機能（ＭＣＦ）１００２およびメディアコンテンツの配信を制御するメディア配信機能（ＭＤＦ）１００３を含むメディア機能（ＭＦ）１００１の適切な選択を提供し、搬送機能（ＴＦ）１００４を介してユーザ機器へのパケットを制御するように構成される。

図１に記載のＩＭＳシステムと同様に、ＮＧＮ統合ＩＰＴＶシステムは１つ以上のメディア同期アプリケーションサーバ（ＭＳＡＳ）１００８で拡張されており、それは送信先間同期機能を実行するように構成される。ユーザ機器またはネットワークノードにおける同期動作は、同期クライアント（ＳＣ）１００９の位置においてバッファ１０１０を用いて実行されてもよい。

ＣＦＩＡは、システムに接続されたＵＥが接続されてもよい異なる送信先間同期サービスに関連した動的な同期グループを維持するために構成される。さらに、ＣＦＩＡは前記同期サービスに関する情報をＣＦＩＡに提供するサービス発見および選択（ＳＤ＆Ｓ）機能（図示しない）に、例えば電子番組ガイド（ＥＰＧ）からの情報の助けによって、接続されてもよい。

システムはメディア制御のためにリアルタイムストリーミングプロトコル（ＲＴＳＰ）を用い、メディア搬送のためにリアルタイムトランスポートプロトコル（ＲＴＰ）を用いる。しかしながら、図１のＩＰＴＶシステムとは対照的に、ＮＧＮ拡張ＩＰＴＶシステムはハイパーテキストトランスポートプロトコル（ＨＴＴＰ）を用いて、ユーザ端末間またはユーザ端末とＭＦを含むアプリケーションサーバとの間の（ＲＴＰ）メディアセッションをセットアップする。処理状態を把握しない（ｓｔａｔｅｌｅｓｓ）プロトコルとしてＨＴＴＰは、（例えばＳＩＰなどの処理状態を把握する（ｓｔａｔｅｆｕｌ）プロトコルの場合のように）セッション制御状態の実施および維持が原則として必要ないため、実施が容易であるという利点がある。さらに、ＨＴＴＰはパラメータを搬送するために多くの方法（例えば、ＵＲＩ、ＳＤＰ、ＸＭＬなど）を可能にし、同期グループを生成および削除するために用いられてもよい。実施例および関連する利点は以下の図１１および図１２に、参照によってより詳細に記載される。

図１１は、ユニキャストコンテンツオンデマンドメディアストリームを受信するＵＥに関する、本発明の例示的な実施形態によるプロトコルフロー１１００を示す。図２のプロトコルフローと同様に、図１１のプロトコルフローは、１人以上の他のＵＥのユーザと共にコンテンツを見るために同期されるコンテンツオンデマンド（ＣｏＤ）を要求するＵＥのユーザに関連する。

この実施形態において、セッションのセットアップはＨＴＴＰを用いて達成される。第１のステップ１において、ＵＥは、同期グループを識別するＳｙｎｃＧｒｏｕｐＩｄを含むＨＴＴＰ ＧＥＴメッセージを、ＣＦＩＡに属する特定のＵＥに送信する。ＳｙｎｃＧｒｏｕｐＩｄはすでにＵＥに知られていてもよい。代替として、ＳｙｎｃＧｒｏｕｐＩｄはセッションセットアップの間にＵＥによって、例えば生成されてもよい。

ＳｙｎｃＧｒｏｕｐＩｄパラメータはＸＭＬ、ＳＤＰ、ＳＯＡＰまたは任意の他の適切なプロトコルを用いてＨＴＴＰメッセージ内で運搬されてもよい。適切な実施例は以下に記載される。ＣＦＩＡはＨＴＴＰ ＧＥＴメッセージを受信し、ユーザをＳｙｎｃＧｒｏｕｐＩｄに基づいて適切な同期グループに加えてもよい。ＣＦＩＡはしたがって、この同期セッションに関する適切なＭＳＡＳを選択して、選択されたＭＳＡＳにアドレスを関連づけてもよい。

ステップ２において、ＨＴＴＰ ＧＥＴメッセージが、選択されたＭＳＡＳのＳｙｎｃＧｒｏｕｐＩｄおよびネットワークアドレスの両方を含む適切なＭＦに送信される。このＭＳＡＳアドレスはＸＭＬ、ＳＤＰ、ＳＯＡＰを用いるＨＴＴＰメッセージ内で、または別の適切な埋め込まれたセッションレベル属性、例えばＩＥＴＦ ＲＦＣ ３６０５におけるＲＴＣＰ属性内で運搬されてもよい。ＭＦに送信されたＨＴＴＰメッセージはポート番号を含んでもよい。

ＭＦはＨＴＴＰメッセージ内の情報を検索してもよく、そこに含まれるアドレスおよびポート情報を、そのセッションに関連するＲＴＣＰメッセージをそのアドレスに送信する指示であるとみなしてもよい。

ＨＴＴＰメッセージの受信の際、ＭＦは要求されたＲＴＰストリームにＳＳＲＣ識別子を割り当てる。ステップ３において、ＭＦはＨＴＴＰ ２００ ＯＫメッセージをＣＦＩＡに返送し、２００ ＯＫメッセージはＳｙｎｃＧｒｏｕｐＩｄとメディアストリームに関して新しく生成されたＳＳＲＣ識別子との両方を含む。

ステップ４においてＣＦＩＡは２００ ＯＫメッセージをＵＥに送信し、それは最終確認としての応答である。この２００ ＯＫメッセージは要求されたメディアストリームのＳＳＲＣのＳＳＲＣ、ＭＳＡＳアドレス、および選択として代替のＲＴＣＰポート番号を含む。加えて、このＨＴＴＰメッセージは新しく割り振られた、または同意されたＳｙｎｃＧｒｏｕｐＩｄを含んでもよい。ＵＥは、受信されたＭＳＡＳアドレスおよび代替としてのポート番号を、そのセッションに関連するＲＴＣＰメッセージをそのアドレスに送信する指示であるとみなしてもよい。より特別には、ＵＥはこれらの新しいアドレス指示を用いて、メディアストリームの送信元（送信器）のアドレスとは異なるアドレスを有するＭＳＡＳに、同期ステータス情報をＲＴＣＰメッセージを介して送信してもよい。

その後、ステップ５〜９において、ＲＴＳＰ制御を用いて実際のメディアストリームをセットアップし、メディアストリームはＲＴＣＰ受信器レポート（ＲＴＣＰ ＲＲ）およびＲＴＣＰ拡張レポート（ＲＴＣＰ ＸＲ）を用いてＭＦからＵＥにストリーミングを開始する。これらのステップはＦｉｇ．２に記載のプロセスと同一であり、ＴＳ １８３ ０６３により詳細に記載される。

同様に、ＨＴＴＰは、ＨＴＴＰセッションをＣＦＩＡと共に最初にセットアップすることによってマルチキャストに参加することを要求するＵＥのために用いることができる。このプロセスは図１２に記載され、図７のＳＩＰを根拠にしたメッセージフローと同一である。

ＨＴＴＰは、異なるプロトコルを用いて、例えばＳｙｎｃＧｒｏｕｐＩｄ、ＭＳＡＳのアドレスなどのパラメータを運搬することができる。一実施形態では、これらのパラメータは拡張マークアップ言語プロトコル（ＸＭＬ）を用いて運搬されてもよい。例えば、ＵＥとＣＦＩＡの間のパラメータを送信するためのｈｔｔｐメッセージはＸＭＬボディを有してもよい。例えばＵＥは以下のＨＴＴＰ要求を用いてＣＦＩＡから同期情報を要求してもよい。

ＧＥＴ ｈｔｔｐ：／／ｃｆｉａ．ｅｔｓｉ．ｏｒｇ／ｓｙｎｃｇｒｏｕｐ／？ＳｙｎｃＧｒｏｕｐＩｄ＝２１７ａ５ｂｄ０
ＨＴＴＰ／１．１
Ｕｓｅｒ−Ａｇｅｎｔ： ＩＰＴＶＣｌｉｅｎｔ／１．０

代替として、ＵＲＬは別のフォーマットをとってもよく、例えばｈｔｔｐ：／／ｃｆｉａ．ｅｔｓｉ．ｏｒｇ／ｓｙｎｃｇｒｏｕｐ／２１７ａ５ｂｄ０ ＨＴＴＰ／１．１。 応答して、ＣＦＩＡは、ＳｙｎｃＧｒｏｕｐＩｄ ２１７ａ５ｂｄ０に関連するパラメータを伴うＸＭＬボディを含むＨＴＴＰ応答を介して、要求された情報を送信することができる。

ＨＴＴＰ／１．１ ２００ ＯＫ
Ｓｅｒｖｅｒ： ＣＦＩＡ／１．０
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｅｔｓｉ．ｉｐｔｖｓｙｎｃｇｒｏｕｐ＋ｘｍｌ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３５

＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”ｌ．０” ？＞
＜ｓｙｎｃｇｒｏｕｐ ｉｄ＝”２１７ａ５ｂｄ０”＞
＜ｒｔｃｐ ｓｓｒｃ＝”ＡＦ” ｒｅｃｖ＝”１９２．１６８．１．１００：１２３４” ／＞
＜／ｓｙｎｃｇｒｏｕｐ＞

この例において、ＸＭＬボディはこの同期セッションに関連するＳＳＲＣおよび、ＭＳＡＳ（ｒｅｃｖ）のＩＰアドレスおよびポート番号を識別する。ＸＭＬボディに関連するＸＭＬスキーマは以下のように示される。

＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”ｌ．０” ？＞
＜ｘｓ：ｓｃｈｅｍａ ｘｍｌｎｓ：ｘｓ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ”＞

＜ｘｓ：ｅｌｅｍｅｎｔ ｎａｍｅ＝”ｓｙｎｃｇｒｏｕｐ”＞
＜ｘｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓ：ｓｅｑｕｅｎｃｅ＞
＜ｘｓ：ｅｌｅｍｅｎｔ ｎａｍｅ＝”ｐａｒｔｉｃｉｐａｎｔ”＞
＜ｘｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓ：ａｔｔｒｉｂｕｔｅ ｎａｍｅ＝”ｉｄ” ｔｙｐｅ＝”ｘｓ：ｓｔｒｉｎｇ”／＞
＜／ｘｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓ：ｅｌｅｍｅｎｔ＞
＜ｘｓ：ｅｌｅｍｅｎｔ ｎａｍｅ＝”ｒｔｃｐ”＞
＜ｘｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜ｘｓ：ａｔｔｒｉｂｕｔｅ ｎａｍｅ＝”ｓｓｒｃ” ｔｙｐｅ＝”ｘｓ：ｓｔｒｉｎｇ”／＞
＜ｘｓ：ａｔｔｒｉｂｕｔｅ ｎａｍｅ＝”ｒｅｃｖ” ｔｙｐｅ＝”ｘｓ：ｓｔｒｉｎｇ”／＞
＜／ｘｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓ：ｅｌｅｍｅｎｔ＞
＜ｘｓ：ａｔｔｒｉｂｕｔｅ ｎａｍｅ＝”ｉｄ” ｔｙｐｅ＝”ｘｓ：ｓｔｒｉｎｇ”／＞
＜ｘｓ：ｓｅｑｕｅｎｃｅ＞
＜／ｘｓ：ｃｏｍｐｌｅｘＴｙｐｅ＞
＜／ｘｓ：ｅｌｅｍｅｎｔ＞

＜／ｘｓ：ｓｃｈｅｍａ＞

同一のまたは類似したＸＭＬボディを得るために、このＸＭＬスキームの多くの変形例が可能であることに留意すべきである。

別の実施形態では、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）がパラメータを搬送するために用いられてもよい。そのメッセージフォーマットに関しては、ＳＯＡＰは拡張可能マークアップ言語（ＸＭＬ）に依存する。ＵＥとＣＦＩＡの間のＨＴＴＰ要求および関連するＨＴＴＰ応答の１つの可能なＳＯＡＰ実施例が、以下に示される。

ＰＯＳＴ ／ｓｙｎｃｇｒｏｕｐ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ｅｔｓｉ．ｏｒｇ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｓｏａｐ＋ｘｍｌ； ｃｈａｒｓｅｔ＝ｕｔｆ−８
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ｎｎｎ

＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”ｌ．０” ｅｎｃｏｄｉｎｇ＝”ｕｔｆ−８”？＞
＜ｓｏａｐ：Ｅｎｖｅｌｏｐｅ ｘｍｌｎｓ：ｘｓｉ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ−ｉｎｓｔａｎｃｅ” ｘｍｌｎｓ：ｘｓｄ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ” ｘｍｌｎｓ：ｓｏａｐ＝”ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｓｏａｐ／ｅｎｖｅｌｏｐｅ／”＞
＜ｓｏａｐ：Ｂｏｄｙ＞
＜ｓｙｎｃｇｒｏｕｐＪｏｉｎＲｅｑｕｅｓｔ ｘｍｌｎｓ＝”ｈｔｔｐ：／／ｗｗｗ．ｅｔｓｉ．ｏｒｇ／ｓｙｎｃ”＞
＜ｓｙｎｃｇｒｏｕｐ ｉｄ＝２１７ａ５ｂｄ０＞
＜ｐａｒｔｉｃｉｐａｎｔ ｉｄ＝”ｕｓｅｒＡ＠ｅｔｓｉ．ｏｒｇ” ／＞
＜／ｓｙｎｃｇｒｏｕｐ＞
＜／ｓｙｎｃｇｒｏｕｐＪｏｉｎＲｅｑｕｅｓｔ＞
＜／ｓｏａｐ：Ｂｏｄｙ＞
＜／ｓｏａｐ：Ｅｎｖｅｌｏｐｅ＞

ＨＴＴＰ／１．１ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｓｏａｐ＋ｘｍｌ； ｃｈａｒｓｅｔ＝ｕｔｆ−８
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ｎｎｎ

＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”ｌ．０” ｅｎｃｏｄｉｎｇ＝”ｕｔｆ−８”？＞
＜ｓｏａｐ：Ｅｎｖｅｌｏｐｅ ｘｍｌｎｓ：ｘｓｉ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ−ｉｎｓｔａｎｃｅ” ｘｍｌｎｓ：ｘｓｄ＝”ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／ＸＭＬＳｃｈｅｍａ” ｘｍｌｎｓ：ｓｏａｐ＝”ｈｔｔｐ：／／ｓｃｈｅｍａｓ．ｘｍｌｓｏａｐ．ｏｒｇ／ｓｏａｐ／ｅｎｖｅｌｏｐｅ／”＞
＜ｓｏａｐ：Ｂｏｄｙ＞
＜ｓｙｎｃｇｒｏｕｐＪｏｉｎＲｅｓｐｏｎｓｅ ｘｍｌｎｓ＝”ｈｔｔｐ：／／ｗｗｗ．ｅｔｓｉ．ｏｒｇ／ｓｙｎｃ”＞
＜ｓｙｎｃｇｒｏｕｐ ｉｄ＝”２１７Ａ５ｂｄ０”＞
＜ｐａｒｔｉｃｉｐａｎｔ ｉｄ＝”ｕｓｅｒＡ＠ｅｔｓｉ．ｏｒｇ” ／＞
＜ｒｔｃｐ ｓｓｒｃ＝”ＡＦ” ｒｅｃｖ＝”１９２．１６８．１．１００：１２３４” ／＞
＜／ｓｙｎｃｇｒｏｕｐ＞
＜／ｓｙｎｃｇｒｏｕｐＪｏｉｎＲｅｓｐｏｎｓｅ＞
＜／ｓｏａｐ：Ｂｏｄｙ＞
＜／ｓｏａｐ：Ｅｎｖｅｌｏｐｅ＞

さらに別の実施形態では、ＳＩＰの場合に用いられる方法と同様に、パラメータはＳＤＰボディによって搬送される。この場合には、ＨＴＴＰ要求の可能なＳＤＰ実施形態および、ＵＥとＣＦＩＡの間で送信される関連するＨＴＴＰ応答が以下に示される。

ＧＥＴ ／ｓｙｎｃｇｒｏｕｐ／２１７Ａ５ｂｄ０ ＨＴＴＰ／１．１
Ｈｏｓｔ： ｗｗｗ．ｅｔｓｉ．ｏｒｇ
Ａｃｃｅｐｔ： ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ

ＨＴＴＰ／１．０ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｓｄｐ
ｖ＝０
ｏ＝− ２８９０８４４５２６ ２８９０８４２８０７ ＩＮ ＩＰ４ １９２．１６．２４．２０２
ａ＝ｓｓｒｃ：＜ｓｓｒｃ−ｉｄ＞ ＜ａｔｔｒｉｂｕｔｅ＞：＜ｖａｌｕｅ＞．
ａ＝ｒｔｃｐ−ｘｒ：ｓｙｎｃ−ｇｒｏｕｐ＝＜ｖａｌｕｅ＞
ａ＝ｒｔｃｐ：ｐｏｒｔ ［ｎｅｔｔｙｐｅ ｓｐａｃｅ ａｄｄｒｔｙｐｅ ｓｐａｃｅ ｃｏｎｎｅｃｔｉｏｎ−ａｄｄｒｅｓｓ］

したがって、ＨＴＴＰはパラメータ、特に同期パラメータを、ＵＥ、ＣＦＩＡおよびＭＦ間で搬送する非常に柔軟な方法を提供する。さらに、さらなる変形例において、ＨＴＴＰ ＰＵＴ（またはＰＯＳＴ）およびＨＴＴＰ ＤＥＬＥＴＥメッセージは、存在する同期グループにＵＥが加入するか離れるかを可能にすることができる。その意味では、ＨＴＴＰはさらなる柔軟性も可能にする。存在する同期グループに加入する１つの実施例は以下に示される。

ＰＵＴ ｈｔｔｐ：／／ｃｆｉａ．ｅｔｓｉ．ｏｒｇ／ｓｙｎｃｇｒｏｕｐｓ／２１７Ａ５ｂｄ０／ｐａｒｔｉｃｉｐａｎｔｓ
ＨＴＴＰ／１．１
Ｕｓｅｒ−Ａｇｅｎｔ： ＩＰＴＶＣｌｉｅｎｔ／１．０
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｅｔｓｉ．ｉｐｔｖｓｙｎｃｇｒｏｕｐ＋ｘｍｌ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３５

＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”ｌ．０” ？＞
＜ｓｙｎｃｇｒｏｕｐ ｉｄ＝”２１７Ａ５ｂｄ０”＞
＜ｐａｒｔｉｃｉｐａｎｔ ｉｄ＝”ｕｓｅｒＢ＠ｅｔｓｉ．ｏｒｇ” ／＞
＜／ｓｙｎｃｇｒｏｕｐ＞

ＨＴＴＰ／１．１ ２０１ Ｃｒｅａｔｅｄ
Ｓｅｒｖｅｒ： ＣＦＩＡ／１．０
Ｌｏｃａｔｉｏｎ： ｈｔｔｐ：／／ｃｆｉａ．ｅｔｓｉ．ｏｒｇ／ｓｙｎｃｇｒｏｕｐｓ／２１７Ａ５ｂｄ０
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｅｔｓｉ．ｉｐｔｖｓｙｎｃｇｒｏｕｐ＋ｘｍｌ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３５

＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”ｌ．０” ？＞
＜ｓｙｎｃｇｒｏｕｐ ｉｄ＜＝＞”２１７ａ５ｂｄ０”＞
＜ｐａｒｔｉｃｉｐａｎｔ ｉｄ＝”ｕｓｅｒＡ＠ｅｔｓｉ．ｏｒｇ” ／＞
＜ｐａｒｔｉｃｉｐａｎｔ ｉｄ＝”ｕｓｅｒＢ＠ｅｔｓｉ．ｏｒｇ” ／＞
＜ｒｔｃｐ ｓｓｒｃ＝”ＡＦ” ｒｅｃｖ＝”１９２．１６８．１．１００：１２３４” ／＞
＜／ｓｙｎｃｇｒｏｕｐ＞

この実施形態において、ＵＥは、同期グループ２１７ａ５ｂｄ０にｕｓｅｒＢ＠ｅｔｓｉ．ｏｒｇを加えることをＣＦＩＡに要求するＨＴＴＰ ＰＵＴメッセージを送信する。それの返答として、ＵＥは、ＵＥが加えられたＣＦＩＡの確認を受信する。さらに、返答メッセージはＳＳＲＣおよび同期グループに関連するＭＳＡＳのアドレスに関する情報を有する。選択として、返答メッセージはさらに情報を、例えばこの場合はｕｓｅｒＡ＠ｅｔｓｉ．ｏｒｇとｕｓｅｒＢ＠ｅｔｓｉ．ｏｒｇとして識別される同期グループの加入者の情報を含む。

存在する同期グループを離れることは、ＨＴＴＰ ＤＥＬＥＴＥメッセージ、ＤＥＬＥＴＥ ｈｔｔｐ：／／ｍｓａｓ．ｅｔｓｉ．ｏｒｇ／ｓｙｎｃｇｒｏｕｐ／２１７ａ５ｂｄ０／ｐａｒｔｉｃｉｐａｎｔｓ／ｕｓｅｒＡ＠ｅｔｓｉ．ｏｒｇ ｈｔｔｐ ／１．１， Ｕｓｅｒ−Ａｇｅｎｔ： ＩＰＴＶＣｌｉｅｎｔ／１．０をＣＦＩＡに送信することによって実施される。

同様にして、新しい同期グループが、ＣＦＩＡへのＨＴＴＰ ＰＯＳＴメッセージを感知することによって生成される。

ＰＯＳＴ ｈｔｔｐ：／／ｃｆｉａ．ｅｔｓｉ．ｏｒｇ／ｓｙｎｃｇｒｏｕｐｓ ＨＴＴＰ／１．１
Ｕｓｅｒ−Ａｇｅｎｔ： ＩＰＴＶＣｌｉｅｎｔ／１．０
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｅｔｓｉ．ｉｐｔｖｓｙｎｃｇｒｏｕｐ＋ｘｍｌ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３５

＜？ｘｍｌ ｖｅｒｓｉｏｎ＝”ｌ．０” ？＞
＜ｓｙｎｃｇｒｏｕｐ＞
＜ｐａｒｔｉｃｉｐａｎｔ ｉｄ＝”ｕｓｅｒＡ＠ｅｔｓｉ．ｏｒｇ” ／＞
＜／ｓｙｎｃｇｒｏｕｐ＞

ＨＴＴＰ／１．１ ２０１ Ｃｒｅａｔｅｄ
Ｓｅｒｖｅｒ： ＣＦＩＡ／１．０
Ｌｏｃａｔｉｏｎ： ｈｔｔｐ：／／ｃｆｉａ．ｅｔｓｉ．ｏｒｇ／ｓｙｎｃｇｒｏｕｐｓ／２１７ａ５ｂｄ０
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｅｔｓｉ．ｉｐｔｖｓｙｎｃｇｒｏｕｐ＋ｘｍｌ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ： ３５

＜ｓｙｎｃｇｒｏｕｐ ｉｄ＝”２１７ａ５ｂｄ０”＞
＜ｐａｒｔｉｃｉｐａｎｔ ｉｄ＝”ｕｓｅｒＡ＠ｅｔｓｉ．ｏｒｇ” ／＞
＜ｒｔｃｐ ｓｓｒｃ＝”ＡＦ” ｒｅｃｖ＝”１９２．１６８．１．１００：１２３４” ／＞
＜／ｓｙｎｃｇｒｏｕｐ＞

本発明の実施形態はコンピュータシステムにおける使用のためのプログラム製品として実施されてもよい。プログラム製品のプログラムは（本明細書に記載された方法を含む）本実施形態の機能を定義して、様々なコンピュータ読み取り可能な記憶媒体上に含まれることができる。概略的なコンピュータ読み取り可能な記憶媒体は、（ｉ）情報が恒久的に記憶される書き込み不可能な記憶媒体（例えば、ＣＤ−ＲＯＭドライブによって読み取り可能なＣＤ−ＲＯＭディスク、フラッシュメモリ、ＲＯＭチップまたは任意のタイプのソリッドステートな不揮発性半導体メモリなどのコンピュータ内の読み取り専用メモリ装置）、（ｉｉ）変更可能な情報が記憶される書き込み可能な記憶媒体（例えば、ディスケットドライブ内のフロッピー（登録商標）ディスクまたはハードディスクドライブまたは任意のタイプのソリッドステートなランダムアクセス半導体メモリ）を含むが、それらには限られない。

いかなる実施形態に関連して記載されたいかなる特徴も単独で使用されてもよく、または、記載された他の特徴と組み合わせて使用されてもよく、そして、任意の他の実施形態の１つ以上の特徴と組み合わせて使用されてもよく、または任意の他の実施形態の任意の組み合わせと組み合わせて使用されてもよい。さらに、添付の特許請求の範囲に定義されているが、上記されない均等物および変形例もまた、本発明の範囲から離れることなく用いられる。

Claims (19)

1. メディアストリームに関する制御および管理情報を提供する第１のプロトコルのメッセージを動的にリレーする方法であって、メッセージは１つ以上の第２のプロトコルに基づくマルチメディアストリームに関連づけられ、第２のプロトコルはＩＰに基づくネットワークを介してマルチメディアデータをストリーミングするように構成され、各ストリームはメディアセッションに関連づけられ、送信器ノードおよび１つ以上の受信器ノードと関連づけられ、方法は、
   少なくとも１つの制御ノードを少なくとも１つのストリームに割り当てるステップと、
   前記ストリームに関連づけられた受信器ノードに前記制御ノードのアドレスを提供するステップであって、セッション制御プロトコルメッセージまたはＨＴＴＰメッセージにおいて前記アドレスが前記受信器ノードに提供され、前記アドレスが、関連づけられた送信器ノードのアドレスとは異なるステップと、
   前記セッション制御プロトコルメッセージまたはＨＴＴＰメッセージに含まれる前記アドレスを用いて、前記受信器ノードが前記制御ノードに第１のプロトコルの受信器メッセージを送信するステップと、を含む、
   メッセージを動的にリレーする方法。
2. 第１のプロトコルがＲＴＣＰ、第２のプロトコルがＲＴＰ、ストリームがＲＴＰストリームである、請求項１に記載の方法。
3. 前記ＲＴＰストリームと関連づけられたグループ同期識別子を前記受信器ノードに提供するステップと、
   受信器ＲＴＣＰメッセージ内の前記グループ同期識別子を前記制御ノードに送信するステップと、
   をさらに含む、請求項２に記載の方法。
4. 前記受信器ノードが同期ステータス情報を生成するステップと、
   受信器ＲＴＣＰメッセージ内の前記同期ステータス情報を前記制御ノードに送信するステップであって、前記制御ノードが、前記受信器ＲＴＣＰメッセージと関連づけられたＲＴＰストリームを、前記制御ノードに割り当てられた１つ以上の他のＲＴＰストリームと同期させる同期機能を有する、ステップと、
   をさらに含む、請求項２または３に記載の方法。
5. 前記同期機能が前記同期ステータス情報を用いて同期設定情報を計算するステップと、
   前記制御ノードが前記受信器ノードに前記同期設定情報を送信するステップと、
   前記受信器ノードは前記同期設定情報を用いて前記受信器ノードに関連づけられた遅延バッファに指示するステップと、
   をさらに含む、請求項４に記載の方法。
6. 前記ＲＴＰストリームに関連づけられた前記送信器ノードに、前記制御ノードのアドレスを提供するステップであって、前記アドレスはセッション制御プロトコルメッセージ内の前記送信器ノードに提供される、ステップと、
   前記送信器ノードが前記制御ノードに送信器ＲＴＣＰメッセージを送信するステップであって、前記セッション制御プロトコルメッセージ内に含まれる前記アドレスを使用する、ステップと、
   をさらに含む、請求項２から５のいずれか一項に記載の方法。
7. 制御ノードが１つ以上の受信器ＲＴＣＰメッセージおよび１つ以上の送信器ＲＴＣＰメッセージを受信し、前記受信器ＲＴＣＰメッセージ内および前記送信器ＲＴＣＰメッセージ内のＲＴＰセッション識別子、好ましくはＳＳＲＣが同一である場合、受信器ＲＴＣＰメッセージを送信器ＲＴＣＰメッセージに関連づけるステップと、
   関連づけられた送信器ＲＴＣＰメッセージが発信されるアドレスに、制御ノードが受信器ＲＴＣＰメッセージを送信する、および／または、関連づけられた受信器ＲＴＣＰメッセージが発信されるアドレスに、制御ノードが送信器ＲＴＣＰメッセージを送信するステップと、
   をさらに含む、請求項６に記載の方法。
8. 前記受信器ＲＴＣＰメッセージの少なくとも１つが同期ステータス情報を含み、前記方法はさらに、
   前記受信器ＲＴＣＰメッセージから前記同期ステータス情報を取り除くステップと、
   前記受信器ＲＴＣＰメッセージを前記関連づけられた送信器ノードに送信するステップと、
   をさらに含む、請求項４から７のいずれか一項に記載の方法。
9. 前記同期機能が同期設定情報を提供するステップと、
   前記受信器ノードに送信器ＲＴＣＰメッセージ内の前記同期設定情報を送信するステップと、
   をさらに含む、請求項７に記載の方法。
10. 少なくとも１つの送信器ノードが、前記ＲＴＰストリームの少なくとも１つおよび関連づけられた送信器ＲＴＣＰメッセージを、１つ以上の受信器ノードにマルチキャストするステップ
    をさらに含む、請求項２から５のいずれか一項に記載の方法。
11. 受信器ノードが前記ＲＴＣＰメッセージの少なくとも１つを前記制御ノードに送信するステップ
    をさらに含む、請求項１０に記載の方法。
12. 前記マルチキャストに関連づけられたメンバグループに制御ノードを参加させる要求を送信する、または、前記制御ノードに送信器ＲＴＣＰメッセージを提供するために送信器ノードと制御ノードの間のユニキャスト接続を提供するステップ
    を含む、請求項１０に記載の方法。
13. 制御ノードが、１つ以上の受信器ＲＴＣＰメッセージおよび１つ以上の送信器ＲＴＣＰメッセージを受信し、前記受信器ＲＴＣＰメッセージ内および前記送信器ＲＴＣＰメッセージ内のＲＴＰセッション識別子、好ましくはＳＳＲＣが同一である場合、受信器ＲＴＣＰメッセージと送信器ＲＴＣＰメッセージを関連づけるステップと、
    関連づけられた送信器ＲＴＣＰメッセージが発信されるアドレスに、制御ノードが受信器ＲＴＣＰメッセージを送信する、および／または、関連づけられた受信器ＲＴＣＰメッセージが発信されるアドレスに、制御ノードが送信器ＲＴＣＰメッセージを送信するステップと、
    を含む、請求項１０に記載の方法。
14. メディアストリームに関する制御および管理情報を提供するための第１のプロトコルのメッセージを動的にリレーするシステムであって、
    １つ以上の受信器ノードによって生成された第１のプロトコルの１つ以上の受信器メッセージ、および／または１つ以上の送信器ノードによって生成された第１のプロトコルの送信器メッセージを受信する制御ノードと、
    前記制御ノードに関連づけられたリレー制御機能であって、前記制御機能が、第２のプロトコルに基づいたマルチメディアストリームに関連づけられた受信器ノードおよび／または送信器ノードに前記制御ノードのアドレスを提供するように構成され、前記アドレスはセッション制御プロトコルメッセージまたはＨＴＴＰメッセージにおいて前記受信器ノードおよび／または送信器ノードに提供され、前記第２のプロトコルはＩＰに基づいたネットワークを介してマルチメディアデータをストリーミングするように構成される、リレー制御機能と、
    前記セッション制御プロトコルメッセージまたはＨＴＴＰメッセージ内に含まれる前記アドレスを用いて、前記制御ノードに第１のプロトコルのメッセージを送信するように構成された少なくとも１つの受信器ノードと、
    を有する、システム。
15. 第１のプロトコルがＲＴＣＰであり、第２のプロトコルがＲＴＰであり、ストリームがＲＴＰストリームである、請求項１４に記載のシステム。
16. 前記セッション制御プロトコルメッセージまたはＨＴＴＰメッセージ内に含まれる前記アドレスを用いて、前記制御ノードにＲＴＣＰメッセージを送信するように構成された少なくとも１つの送信器ノードをさらに含み、
    前記制御ノードがさらに、
    １つ以上の受信器ノードから発信される受信器ＲＴＣＰメッセージおよび／または１つ以上の送信器ノードから発信される送信器ＲＴＣＰメッセージを受信する少なくとも１つの入力と、
    前記受信器ＲＴＣＰメッセージ内および前記送信器ＲＴＣＰメッセージ内のＲＴＰセッション識別子、好ましくはＳＳＲＣが同一である場合、送信器ＲＴＣＰメッセージに受信器ＲＴＣＰメッセージを関連づけるマッピング機能と、
    関連づけられた送信器ＲＴＣＰメッセージが発信されるアドレスに受信器ＲＴＣＰメッセージを送信する、および／または、関連づけられた受信器ＲＴＣＰメッセージが発信されるアドレスに送信器ＲＴＣＰメッセージを送信する、少なくとも１つの出力と、を有する、
    請求項１５に記載のシステム。
17. 請求項１５または１６に記載のシステムにおいて使用する受信器ノードであって、受信器ノードは、制御ノードのアドレスを含むセッション制御プロトコルメッセージまたはＨＴＴＰメッセージを受信し、前記セッション制御プロトコルメッセージ内に含まれる前記アドレスを用いて、前記受信器ノードによって生成された受信器ＲＴＣＰメッセージを前記制御ノードに送信するように構成され、
    同期ステータス情報を生成し、前記同期ステータス情報を受信器ＲＴＣＰメッセージ内に挿入し、前記受信器ＲＴＣＰメッセージを前記制御ノードに送信するように構成された同期クライアントをさらに有する受信器ノード。
18. 請求項１５または１６に記載のシステムにおいて使用する制御ノードであって、
    １つ以上の受信器ノードから発信される受信器ＲＴＣＰメッセージおよび／または１つ以上の送信器ノードから発信される送信器ＲＴＣＰメッセージを受信する少なくとも１つの入力と、
    前記受信器ＲＴＣＰメッセージ内および前記送信器ＲＴＣＰメッセージ内のＲＴＰセッション識別子、好ましくはＳＳＲＣが同一である場合、受信器ＲＴＣＰメッセージを送信器ＲＴＣＰメッセージに関連づけるマッピング機能と、
    関連づけられた送信器ＲＴＣＰメッセージが発信されるアドレスに受信器ＲＴＣＰメッセージを送信する、および／または、関連づけられた受信器ＲＴＣＰメッセージが発信されるアドレスに送信器ＲＴＣＰメッセージを送信する、少なくとも１つの出力と、
    所望により、１つ以上の受信器ＲＴＣＰメッセージ内の１つ以上の受信器ノードによって前記制御ノードに送信された同期ステータス情報を受信し、前記同期ステータス情報に基づいて、前記１つ以上の受信器ノードに関する同期設定情報を算出するように構成された同期機能と、を有し、前記同期設定情報は、１つ以上の受信器ノードが、少なくとも１つのＲＴＰストリームを時間遅延させることを可能にする、制御ノード。
19. １つ以上の送信器ノード、受信器ノード、および／または制御ノードのメモリ内で実行された場合に、請求項１から１３のいずれか一項に記載の方法ステップを実行するように構成されたソフトウェアコード部分を含む、コンピュータプログラム。

Images