"第1のメディアストリーム及び第2のメディアストリームを同期する方法であって、前記第1メディアストリーム及び前記第2メディアストリームがネットワーク内の少なくとも1つのメディア供給元によって第1のメディア経路及び第2のメディア経路を通じて1又はそれ以上の端末に伝送され、前記方法が、前記第1メディア経路及び前記第2メディア経路における第1の場所に位置する測定モジュールを用いて、前記第1メディアストリーム及び前記第2メディアストリーム内のメディアパケットの到達時間に関連付けられるタイミング情報を測定するステップと、前記ネットワークにおいて、前記タイミング情報に基づいて少なくとも1つのバッファについてのバッファ指示を生成するステップであって、前記バッファが前記第1メディア経路及び前記第2メディア経路のうち少なくとも1つにおける第2の場所に位置するステップと、前記1又はそれ以上の端末におけるメディアパケットの到達時間が実質的に同期されるように、前記メディア経路を通じて前記1又はそれ以上の端末に伝送される1又はそれ以上のメディアパケットを遅延させるステップと、を含む、方法。請求項1に記載の方法において、前記第1メディア経路が前記メディア供給元及び第1の端末の間に設けられ、前記第2メディア経路が前記メディア供給元と第2の端末の間に設けられる、方法。請求項1又は2に記載の方法において、前記測定モジュールが、前記1又はそれ以上の端末に位置するか、前記1若しくはそれ以上の端末を前記ネットワークに接続する1若しくはそれ以上のアクセスラインに沿った位置に配置され、並びに/又は前記バッファが前記ネットワーク内、好ましくは境界ネットワークノード及び/若しくはアクセスネットワークノードに位置する、方法。請求項1から3のいずれかに記載の方法において、前記バッファ指示が、同期サーバ好ましくはメディア同期サーバによって生成され、前記測定モジュール及び前記バッファが、同期測定クライアント及び同期バッファリンングクライアントとしてそれぞれ構成され、前記方法が、更に、タイミング情報を前記同期測定クライアントから受信するステップと、バッファ指示を前記同期バッファリングクライアントに伝送するステップと、を含む、方法。請求項4に記載の方法において、前記バッファ指示が、1若しくはそれ以上の同期設定指示レポート、好ましくはRTCP同期設定指示レポートにより前記同期バッファリングクライアントに送信され、及び/又は前記タイミング情報が1若しくはそれ以上の同期ステータス情報レポートにより前記同期サーバに送信される、方法。請求項5に記載の方法において、前記同期ステータス情報レポートが前記同期バッファリングクライアントを介して前記同期サーバに送信される、方法。請求項6に記載の方法において、前記同期バッファリングクライアントは、1つの端末から前記同期サーバに送信される同期ステータス情報レポートを修正するように構成され、及び/又は前記同期バッファリングクライアントは、同期設定指示レポートを端末に転送するように構成される、方法。請求項1に記載の方法において、前記第1メディア経路が第1メディア供給元及び1つの端末の間に設けられ、前記第2メディア経路が前記第1メディア供給元又は更なる第2のメディア供給元と前記端末との間に設けられる、方法。請求項1に記載の方法において、前記第1測定モジュールがネットワークノード、好ましくは境界ネットワークノード及び/又はアクセスネットワークノードに位置し、前記バッファが前記1又はそれ以上の端末に位置するか、前記1又はそれ以上の端末を前記ネットワークに接続する前記1又はそれ以上のアクセスラインに沿った位置に配置される、方法。請求項1から9のいずれか一項に記載の方法において、前記1又はそれ以上の端末のうち少なくとも1つが、メディアストリームにおける前記メディアパケットの到達時間の変動を測定し、前記到達時間に基づいて変動がバッファリングポイントから生じた遅延に関係するかについて判定するように構成される、方法。請求項1から9のいずれか一項に記載の方法において、前記バッファポイントが可変遅延バッファを含み、当該可変遅延バッファが前記ネットワークから受信した遅延指示に基づいてメディアストリームを遅延させるように構成され、前記遅延が0.5秒と10秒との間、好ましくは1秒と5秒との間で選択され、及び/又は前記バッファが該バッファに接続される2又はそれ以上の端末の間で共有される、方法。第1のメディアストリーム及び第2のメディアストリームを同期するシステムであって、第1のメディアストリーム及び第2のメディアストリームを第1のメディア経路及び第2のメディア経路を通じて1又はそれ以上の端末に伝送する少なくとも1つのメディア供給元と、少なくとも1つの測定モジュールが受信する前記第1メディアストリーム及び前記第2メディアストリーム内のメディアパケットに関連付けられるタイミング情報を測定する当該少なくとも1つの測定モジュールであって、前記第1メディア経路及び前記第2メディア経路における第1の場所に位置する、測定モジュールと、メディア経路を通じて前記1又はそれ以上の端末に伝送されるメディアパケットを、遅延指示に基づいて遅延させるように構成される少なくとも1つのバッファであって、前記バッファが前記第1メディア経路又は前記第2メディア経路のうち少なくとも1つにおける第2の場所に位置するバッファと、前記1又はそれ以上の端末におけるメディアパケットの到達時間が実質的に同期されるように、前記タイミング情報に基づいて前記少なくとも1つのバッファについてのバッファ指示を生成する同期サーバと、を備える、システム。請求項12に記載のシステムで使用するためのバッファモジュールであって、好ましくは同期バッファリングクライアントであり、メディア経路を通じて端末に伝送されるメディアを、バッファ指示に基づいて遅延させるように構成され、前記バッファモジュールが、可変遅延バッファと、バッファ指示を受信する受信機であって、前記バッファ指示が前記可変遅延にメディアストリームを遅延させる情報を所定の遅延期間にわたり提供する受信機と、1又はそれ以上の遅延したメディアストリームを1又はそれ以上の端末に伝送する送信機と、任意に、ポインタ情報を含むバッファリストであって、該ポインタ情報が前記バッファモジュールに2又はそれ以上の端末間で前記可変遅延バッファにおける前記メディアパケットを共有させる、バッファリストと、を備える、バッファモジュール。請求項12に記載のシステムで使用するための同期サーバであって、1又はそれ以上のメディアストリーム内のメディアパケットの到達時間に関連付けられたタイミング情報を受信する受信機と、バッファ指示を生成するように構成されるプロセッサであって、該バッファ指示が前記タイミング情報に基づいて算出される遅延情報を含む、プロセッサと、前記バッファ指示を少なくとも1つのバッファに伝送するための送信機と、を備える、同期サーバ。メディア再生のための端末であって、請求項12に記載のシステムにおいて使用されるように構成され、前記端末が、前記端末が受信するメディアパケットの到達時間に関連付けられたタイミング情報を測定するための測定モジュールと、タイミング情報を前記ネットワーク内の同期サーバに伝送するための送信機と、任意に、メディアストリーム内のメディアパケットの前記到達時間の変動を測定し、該測定に基づいて、変動がバッファリングポイントから生じた遅延に関係するかについて判定するように構成される測定ユニットと、を備える端末。コンピュータ上でランするときに、請求項1から11のいずれか一項に記載の方法を実行するように構成されるソフトウェアコード部を含む、コンピュータプログラム製品。発明の目的は、公知のサービス提供システムの欠点の少なくとも1つを減らすか又は除去することである。第1の態様において、本発明は第1のメディアストリーム及び第2のメディアストリームを同期する方法に関し、第1メディアストリーム及び第2メディアストリームがネットワーク内の少なくとも1つのメディア供給元によって第1のメディア経路及び第2のメディア経路を通じて1又はそれ以上の端末に伝送される。本方法は、第1メディア経路及び第2メディア経路における第1の場所に位置する測定モジュールを用いて、第1メディアストリーム及び第2メディアストリーム内のメディアパケットの到達時間に関連付けられるタイミング情報を測定するステップ、ネットワークにおいて、当該タイミング情報に基づいて少なくとも1つのバッファについてのバッファ指示を生成するステップであって、バッファが第1メディア経路及び第2メディア経路のうち少なくとも1つにおける第2の場所に位置するステップ、1又はそれ以上の端末におけるメディアパケットの到達時間が実質的に同期されるように、メディア経路を通じて1又はそれ以上の端末に伝送される1又はそれ以上のメディアパケットを遅延させるステップを含む。一実施形態においては、第1メディア経路をメディア供給元と第1の端末との間に設け、第2メディア経路をメディア供給元と第2の端末との間に設けることができる。このような構成は、つまり、宛先間同期について方式を提供する。他の実施形態においては、測定モジュールが、1又はそれ以上の端末に位置するか、1若しくはそれ以上の端末をネットワークに接続する1若しくはそれ以上のアクセスラインに沿った位置に配置することができ、並びに/又はネットワーク内、好ましくは境界ネットワークノード及び/若しくはアクセスネットワークノードに位置することができる。更なる実施形態において、バッファは、ホームゲートウェイに、又はホームロケーションにおける互換性がある機能において位置することができる。ホームゲートウェイの後方に存在する端末が個々に追加のバッファリング能力を有する必要はないものの、それぞれが時間情報を測定するための測定モジュールをなおも備えることができる結果、個々の遅延をなおも決定することができるということが利点である。このことは、例えばトランスコーディング、ミクシング、スケーラブルビデオコーデック関連動作等といったホームゲートウェイでのストリーム適合により、異なる遅延を経験している、ホームゲートウェイの後方にある異なる端末が存在するかに特に関係する。他の実施形態においては、測定モジュールは、ホームゲートウェイに位置することができ、及びバッファはネットワーク内の更なるノードに位置することができる。このことは、バッファの後方の端末がもはや測定モジュールと共に構成する必要がないという利点がある。また、このホームゲートウェイは追加のバッファリング容量を有する必要はない。何故なら、これは、ネットワークの更なるノードにより解決されるからである。最後に、ネットワークアドレスの変換問題のために、エンド端末は、元のマルチキャストストリームを直接受信できなくてもよく、それ故、最も理想的な測定位置を提供することができない。更なる別の実施形態では、測定モジュールは、ホームゲートウェイに位置するが、バッファは端末に位置することができる。このことは、ホームゲートウェイ及び御端末の適合性を必要とするだけであるが、ネットワークの更なるノードの適合性を必要としないために、有利である。一実施形態において、ホームゲートウェイは、本発明によるネットワークノードとして振る舞うか、又は本発明による端末として振る舞う。更なる実施形態において、バッファ指示は、同期サーバ、好ましくはメディア同期アプリケーションサーバによって生成することができ、そして、測定モジュール及びバッファは、それぞれ同期測定クライアント及び同期バッファリングクライアントとして構成することができる。本方法は、同期測定クライアントからタイミング情報を受信するステップ、及びバッファ指示を同期バッファリングクライアントに伝送するステップを更に含むことができる。更なる別の実施形態において、バッファ指示は、1若しくはそれ以上の同期設定指示レポート、好ましくはRTCP同期設定指示レポートにより同期バッファリングクライアントに送信することができ、及び/又はタイミング情報が1若しくはそれ以上の同期ステータス情報レポートにより同期サーバに送信することができる。一実施形態において、同期ステータス情報レポートは、同期バッファリングクライアントを介して同期サーバに送信することができる。変形形態において、同期バッファリングクライアントは、1つの端末から同期サーバに送信される同期ステータス情報レポートを修正するように構成することができ、及び/又は同期バッファリングクライアントは、同期設定指示レポートを端末に転送するように構成することができる。他の変形形態において、第1メディア経路は第1メディア供給元と1つの端末との間に設けることができ、第2メディア経路は第1メディア供給元又は更なる第2のメディア供給元とその端末との間に設けることができる。更なる別の変形形態において、第1測定モジュールがネットワークノード、好ましくは境界ネットワークノード及び/又はアクセスネットワークノードに位置することができ、バッファが1又はそれ以上の端末に位置するか、1又はそれ以上の端末をネットワークに接続する1又はそれ以上のアクセスラインに沿った位置に配置することができる。更なる変形形態において、1又はそれ以上の端末のうち少なくとも1つが、メディアストリームにおけるメディアパケットの到達時間の変動を測定し、この到達時間に基づいて変動がバッファリングポイントから生じた遅延に関係するかについて判定するように構成することができる。更なる別の変形形態において、バッファが可変遅延バッファを含み、当該可変遅延バッファがネットワークから受信した遅延指示に基づいてメディアストリームを遅延させるように構成することができる。一実施形態において、この遅延は0.5秒と10秒との間、好ましくは1秒と5秒との間で選択されることができる。別の実施形態において、このバッファポイントが当該バッファに接続される2又はそれ以上の端末の間で共有することができる。別の態様において、本発明は、第1のメディアストリーム及び第2のメディアストリームを同期するシステムに関することができ、当該システムは、第1メディアストリーム及び第2メディアストリームを第1のメディア経路及び第2のメディア経路を通じて1又はそれ以上の端末に伝送する少なくとも1つのメディア供給元、少なくとも1つの測定モジュールが受信する第1メディアストリーム及び第2メディアストリーム内のメディアパケットに関連付けられるタイミング情報を測定する当該少なくとも1つの測定モジュールであって、第1メディア経路及び第2メディア経路における第1の場所に位置する測定モジュール、メディア経路を通じて1又はそれ以上の端末に伝送されるメディアパケットを遅延指示に基づいて遅延させるように構成される少なくとも1つのバッファであって、当該バッファが第1メディア経路又は第2メディア経路のうち少なくとも1つにおける第2の場所に位置するバッファ、1又はそれ以上の端末におけるメディアパケットの到達時間が実質的に同期されるように、タイミング情報に基づいて少なくとも1つのバッファについてのバッファ指示を生成する同期サーバを備える。更なる態様において、本発明は、バッファモジュールに関することができ、好ましくは同期バッファリングクライアントであり、メディア経路を通じて端末に伝送されるメディアを、バッファ指示に基づいて遅延させるように構成され、当該バッファモジュールが、可変遅延バッファ、バッファ指示を受信する受信機であって、当該バッファ指示が可変遅延にメディアストリームを遅延させる情報を所定の遅延期間にわたり提供する受信機、1又はそれ以上の遅延したメディアストリームを1又はそれ以上の端末に伝送する送信機、任意に、ポインタ情報を含むバッファリストであって、当該ポインタ情報がバッファモジュールに2又はそれ以上の端末間で可変遅延バッファにおけるメディアパケットを共有させる、バッファリストを備える。さらに他の態様において、本発明は同期サーバに関することができ、1又はそれ以上のメディアストリーム内のメディアパケットの到達時間に関連付けられたタイミング情報を受信する受信機、バッファ指示を生成するように構成されるプロセッサであって、当該バッファ指示がタイミング情報に基づいて算出される遅延情報を含むプロセッサ、バッファ指示を少なくとも1つのバッファに伝送するための送信機を備える。別の態様において、本発明はメディア再生のための端末に関することができ、端末が受信するメディアパケットの到達時間に関連付けられたタイミング情報を測定するための測定モジュール、タイミング情報をネットワーク内の同期サーバに伝送するための送信機、任意に、メディアストリーム内のメディアパケットの到達時間の変動を測定し、当該測定に基づいて、変動がバッファリングポイントから生じた遅延に関係するかについて判定するように構成される測定ユニットを備える。本発明は、また、ソフトウェアコード部を含むコンピュータプログラム製品に関することができ、コンピュータ上でランするときに、上述の方法のステップのいずれかにより本方法を実行するように構成される。本発明は、更に、添付の図面を参照して説明される。図面は本発明による実施形態を模式的に示している。尚、本発明がこれら特定の実施形態にいかなる形でも限定されないことが理解されよう。図1は、従来型のメディア配信システム100について示しており、当該システムは、エッジアクセスノード112例えば、xDSLシステムのDSLAM又はDOCSIS/ケーブルシステムのCMTSを介してメディア配信ネットワーク114に接続されるUE102―110を備えている。メディア供給元111は、少なくとも一つのメディアストリーム113をこのエッジノードに伝送する。エッジノードと端末と間のルートが単純アクセス構成における単一のネットワークセグメント、即ちアクセスリンクを備えるに過ぎないので、ホームネットワーク内のユーザ位置においてエッジノードと端末の間にそれほど多くの遅延は存在しない。したがって、エッジノードと異なる端末との間に遅延が生じていたときは、その遅延は、程度の差はあるものの同一であり、その結果、エッジノードに接続される異なるUEを仕様したメディア再生は、程度の差はあるものの同期されている。しかしながら、異なるマルチメディア機器の使用は、その結果、エッジノードとこれに接続される異なるUEとの間の異なる遅延が存在することがあるという状況になる場合がある。図1はエッジノード及び3つの居住環境住宅116―120を示す。ここでは、そのエッジノードは、メディアストリーム122、例えばMPEG4メディアストリームを異なるUEに配信する。UE3のユーザは、配信されたメディアストリームを直接閲覧するために、UE102を使用することができ、それ故、更なる遅延は居住環境116には存在しない。UE1のユーザは配信されたメディアストリームを閲覧するためにそのデバイスを使用せず、第2のUE2、例えばMPEG―2メディアプレーヤをUE1に接続している。UE1はUE2にメディアストリームを配信する。トランスポートストリームを転送する前に、UE1は、最初にMPEG―4メディアストリームをMPEG―2メディアストリーム124にコード変換する。同様に、UE4のユーザは、メディアストリームを閲覧するために、モバイルデバイス110の形態の更なるUE5を有する。モバイルデバイスは、ワイヤレスでUE5に接続され、UE5は、MPEG―4メディアストリームをモバイルデバイスでの使用に適したメディアフォーマットにコード変換する。したがって、アクセスリンクのトランスコーダの使用は、以下を含む重要な遅延を導くこともある。即ち、ジッタバッファリングに関する、追加のパケット化及びデパケット化の処理に対する遅延、並びに追加のトランスポート及びトランスコードコード変換の遅延である。これらの追加の遅延特に後者は重要なものであり、これにより、様々なUEの再生について許容できない差を導出する。これらの差は、公知のネットワークベースの同期スキームを用いて補償することができない。ここでは、アクセスノードにおいて実装された同期クライアントSC126が同期サーバ101と同期情報を交換する。このような方式では、SC126は、メディアパケット到達時間を測定し、同期ステータス情報を生成し、及びメディアストリームの再生を遅延させるための機能を有する。同期サーバは、SC126から、及び他のアクセス/エッジノードに含まれる他のSCから図1には図示せず、同期ステータス情報を収集し、遅延情報を算出して、同期設定情報134を送信することができる。同期設定情報134は、宛先間同期方式に関わる2又はそれ以上のアクセス/エッジノードに接続されるUEにおけるメディア再生が実質的に同期されるように、可変遅延バッファを設定するための情報を使用する。大規模な配備及びネットワーク制御に適しているにもかかわらず、このような同期方式は、アクセスラインで生成する遅延を補償することができない。何故ならば、異なるエッジノードに到達するメディアストリームの到達時間の差だけがこの方式で考慮されるからである。これらノードを超えて蓄積する遅延のいかなる相違も、メディアストリームがそれぞれのUEへの異なる経路上で継続するときには、もはや考慮されない。アクセスラインという用語は、SC、例えばエッジノードを含むネットワークノード及びUEの間の全ての接続及び要素を広義に意味する用語として用いる。これは、ホームネットワーク部分、又はUEに到達する前に他のネットワークにリダイレクトされているメディアストリームの場合には他のネットワーク部分もまた含むこともできる。したがって、この技術において、宛先間方式の改良を含む同期方式の改良の必要がある。この宛先間同期は、改良された同期パフォーマンスを提供して、そして、大規模アプリケーションでも計測可能な同期方式を提供する。図2は、本発明の一実施形態によるコンテンツ配信システム200について少なくとも一部分を示している。本システムは、コンテンツを、1以上のネットワークノード204,206を介してユーザ機器UE208―212に配信するための少なくとも一つのメディア供給元202を含む。UEは、アクセスノード、即ちネットワークのエッジにあるネットワークノードに、アクセスライン214―218を介して接続される。通例、ネットワークはパケット交換ネットワークに関することができる。ここでは、コンテンツは、1以上のメディアストリーム220,222、例えばビデオオンデマンドストリーム、又はライブでのマルチキャストテレビジョン放送において、UEに送信される。ネットワークノードは、アクセスノード、例えばデジタル加入者ラインアクセスマルチプレクサDSLAM、ケーブルモデム終端システムCMTS光アクセスノード又はエッジルータ若しくはヘッドエンドに関することができる。更に、UE端末とも呼ばれるは、メディアストリームを処理する能力を有するいかなるデバイス、例えば、メディア再生デバイス、又は1つに接続されたデバイス例えばセットトップボックスに関することができる。このようなデバイスは、携帯電話、テレビジョン受像機、IP電話、ゲームコンソール、スマートメータデバイス等を含むことができる。再生という用語は、ストリーム内のコンテンツの部分をユーザ又は更なるデバイスに表示又は呈示するものとして理解することができる。UEとエッジノードのアクセスラインは、中間要素図示せず、例えば1又はそれ以上のトランスコーダ及び/又はミキサを、図1にて図示したのと類似の方法で含むことができる。図1を参照して説明するように、これら中間要素は、UEに接続された各アクセスラインにおける異なる遅延を生じさせることになり、その結果、同期した又は少なくとも実質的に同期したUEの再生は可能でない。したがって、このような望ましくない遅延の補償を可能にするために、UEは測定ユニット、例えば同期測定クライアントMSC246―250を備えることができ、メディアパケット到達時間情報を判断するように構成される。このメディアパケット到達時間情報は、MSCによって使用され、同期ステータス情報224―228を生成する。同期ステータス情報224―228は、ネットワーク内の同期サーバ230以下、メディア同期アプリケーションサーバMSASと称する。に送信される。したがって、このMSCによって、メディアパケットの到達時間情報を測定するための測定ポイントとしてUEにサービス提供させ、同期ステータス情報のこの情報をネットワークにレポートさせる。MSASは、ネットワーク内のバッファリングポイントについて遅延情報を算出するために、同期グループに所属している全てのUEの同期ステータス情報を使用する。このバッファリングポイントは、同期を必要とするメディアストリームのメディア経路に位置する。MSASは、UEのメディア再生を実質的に同期するために、遅延情報をバッファリングポイントに提供することができる。一実施形態において、このようなバッファリングポイントは、ネットワークノード、例えばアクセスノード等のバッファリング同期クライアントBSCとして実装することができる。同期化を達成するために、このBSCは可変遅延バッファ232、234に関連付けられる。可変遅延バッファは、MSASによってネットワークノードに送信される同期設定情報236、238によって制御することができる。BSCに関連付けられるこのバッファは、以降においてBSCバッファと称される。BSCバッファは、例えば概して0.5秒と5秒間の範囲の比較的大きい遅延を処理するように構成される。更には、BSCバッファは、それがMSASからの同期設定情報を通じて遅延指示を受信し、これら指示に従ってその遅延設定を適合するという意味では、制御されるネットワークである。UEは、更に、通例は適応ジッタバッファの形態のジッタバッファ240、242、244を含むことができ、このジッタバッファは、通例20ミリ秒と50ミリ秒と間の範囲、最大100ミリ秒と200ミリ秒との間で、小さい遅延変動を補償することができる。通例は、補償される最大ジッタは、メディアストリームの再生を開始する前に導かれるバッファリング遅延サイズに等しい。このような適応ジッタバッファは、メディアストリームの変動即ち、メディアパケット到達時間の統計的な差を測定するように構成され、バッファ長サイズを動的に適応させることでこれら変動を補償する。このことは、BSCバッファに関連付けられたバッファと対照的であり、BSCバッファは、MSASからその遅延設定を受信する。公知のネットワーク制御同期方式とは対照的に、本発明による同期方式は別個の測定ポイント例えばMSC、及び別個のバッファリングポイント例えばBSCを使用する。ここでは、測定ポイント及びバッファリングポイントはメディアの宛先例えばUEとメディア供給元との間の媒体経路上の異なる位置に配置される。MSCは、アクセスラインのどこか、又はUEにさえ位置することができるため、同期方式はアクセスラインの遅延の補償を考慮に入れる。一実施形態において、MSCはUEに位置することができ、BSCはアクセスノードに位置することができる。更なる実施形態において、MSCは、ローカルネットワーク又はホームネットワークに関連付けられるノードに位置することができる。別の更なる実施形態において、MSCはネットワーク内、例えばアクセスノードに位置することができ、BSCはアクセスラインに、又はUEにさえ位置することができる。したがって、本発明は、同期化を提供するための機能が別々の測定ポイント及びバッファリングポイントによって提供されるという洞察に依存するものである。したがって、公知の宛先間同期方式とは対照的であり、公知の宛先間同期方式では同期化のために必要となる機能即ち、測定及びバッファリングは、単一の論理エンティティにおいて共に実装されてきた。これらの機能性を分離することは、満たされるべき多くの技術的課題を露呈する。上記実施形態の利点及びこれらに関連する利点について、以下に図2―12を参照することよって、更に詳細に説明する。詳細を説明するに際し、これらを解決する解決策に対する明白な洞察と同様に、技術的な課題についても明記する。同期化は、メディアストリーム、例えばRTP又はMPEGパケット等の基本メディアユニット内の、又はこれに関連付けられた時間情報に基づく。UEのMSCに到達する各パケットは、RTPタイムスタンプ及びNTPタイムスタンプに関連付けることができる。RTPタイムスタンプは、RTPデータパケットにおける第1オクテットについてサンプリングする瞬間を反映する。このタイムスタンプの初期値は、ランダム値である。このRTPタイムスタンプは、サンプリング期間を計数するので、第2のRTPパケットが第1のRTPパケットの後に160のサンプルを開始する場合には、第2のRTPタイムスタンプは第1のものより160高くなる。これに対し、NTPタイムスタンプは、絶対ウォールクロック時間である。NTPは、IETFRFC1305において規定されるように、1900年1月1日から開示される64ビットカウンタである。このNTPにより用いられる64ビットのタイムスタンプは、32ビットの秒部分及び32ビットの小数秒部品を備える。それは、RTPタイムスタンプによって特定される第1オクテットがUEで特定の時点を通過する絶対時間を表す。この特定時点は、例えば、UEの再生時点とすることができ、ここでは、NTPタイムスタンプは、指定されたオクテットがユーザに再生される時を示す。あるいは、それは、MSCが指定されたオクテットを最初に受信した、進入入力の時点としてもよい。本発明により測定及びバッファリングポジションを分離するときに応じられる1つの技術的な課題は、同期動作を有するネットワークジッタの存在及び潜在的干渉に関する。ジッタのためにランダムなオフセットがRTPパケット間に存在するにもかかわらず、UEは呈示の正確な時間を決定し、RTPタイムスタンプは、特定のビデオフレーム又は音声サンプルが、メディアストリームの他の部分と比較して、どの時間に再生されなければならないかを決定する。したがって、ネットワーク、例えばアクセスノードのBSCがバッファリングパケットによってメディアストリームを遅延させ、又はメディアパケットを放棄することによってメディアストリームの速度を上げる通例は一度これらのパッケをバッファリングすることだけが可能であるのであれば、UEが通常の方法でRTPタイムスタンプを使用する場合に課題が生じる。例えば、RTPタイムスタンプがパケットの再生をUEによって要求されている間に、ネットワーク内のBSCがパケットを遅延させる場合に、UEは課題に直面することになる。同様に、BSCがパケットを放棄して、その結果、RTPタイムスタンプのギャップになる。その一方で、UEは、あたかもギャップが存在しないかのように再生を続けなければならない。そのうえ、例えばBSCを用いてネットワーク内のどこかにあるメディアストリームを遅延させることは、UEでのメディアストリームの再生は、その同一の遅延によって実行されないということを自動的に意味するものではない。例えば、BSCによって導かれる遅延が、伝送されたメディアの周波数に対して比較的小さい場合例えば100ms、UEは、あたかも遅延がメディアストリームに全く導かれていないかのように、呈示を継続することが可能であろう。導かれた遅延が比較的小さい場合、UEはこれをジッタとして認めることができて、遅延に補償するためにそのジッタバッファを使用することができる。より大きな遅延がBSCによって導かれる場合例えば1秒以上、UEはその実装に従って反応することができる。例えば、UEは、それをメディアストリーム内のギャップと判断することができる。新しいパケットが到達しないために、UEでのジッタバッファは、メディアストリームの呈示により空にされ、再生を継続することができない。次いで、遅延メディアストリームに関連づけられた新しいパケットがUEに到達する場合、UEは、再びジッタバッファリングを開始し、メディアストリームの再生を継続することができる。一旦ジッタバッファがその時点を充たすと、再生を継続することができる。他のUEは、再びバッファリングを開始することができない。例えば、メディアストリームのギャップに応答して、UEは、メディアストリームがもはや利用できないと判断し、再生を停止することができる。この課題を解決するために、一実施形態において、UEは、ネットワーク遅延メディアストリームを受信するように適合することができる。このことは、小さい遅延について、UEがジッタと導かれた小さい遅延との間の差分を認識するようにプログラムすることができることを意味する。ジッタは伝送周波数の前後の統計的な変動を表すので、後にいくつかのパケットが予想されて到達する場合であっても、平均して、メディアパケット到達時間は一定のままである。換言すれば、ジッタバッファのメディアパケット量は、ある安定性のある平均時点の前後で変動することができる。これと対照的に、故意に導かれた遅延は、決定的な特徴を有し、全ての更なるメディアパケットを後に到着させる。多くの遅延したメディアパケットを測定することによって、統計上の遅延とネットワークバッファにより導かれる遅延との差分を決定することができる。UEがネットワークバッファ遅延の発生を判断する場合、そのUEはこれらパケットを異なって扱うことができ、メディア呈示において同一の遅延を導くことができる。特定のUEは、いわゆる適応ジッタバッファを含むことができる。適応ジッタバッファは、メディアパケットの到達時の変更に適応することができる。例えば、多くのパケットが遅れて到達する場合、適応ジッタバッファはこの挙動を補償するためにサイズを増加することができる。このことは、UEを、遅延しているメディアストリームについて呈示を遅延させることが可能なように調整するために、特定の種類の適応ジッタバッファを含むUEとみなすことができる。より遅延を長くするために、UEは、適当な方法で反応するようにプログラムすることができる。このことは、このような長い遅延が検出される場合にUEが再生を停止すべきではないことを意味する。その代わりに、それは、単により長く待たなければならない。このような遅延は、より長い時間期間、例えば1秒以上の間、どのメディアパケットも到達しないときに検出することができる。このようなギャップの後に新しいメディアパケットが到着する場合、それらは以前のパケットとともに継続的に再生されることになる。更に、長い遅延が検出される場合には、この適応ジッタバッファは、バッファ設定を再設定することを要求することができる。長い遅延の後、適応ジッタバッファ設定は、あまりに高く設定することができる。したがって、この長い遅延の後に、このジッタバッファは遅延を導くことができる。この遅延は要求されたのより長い。一旦遅延が導かれると、例えばメディアパケットをスキップすることによって、BSCはまた、再度遅延を減少させることもできる。このような処理は、また課題を導く場合もある。パケットがBSCによって欠落される場合、UEはこれがパケット遅延又はパケットロスであると知覚することができる。UEは、新しい遅延していないパケットで再生を継続する代わりに、パケットがまだ到着するかどうか見るために待つことができる。したがって、それらの実装に応じて、UEは、失ったパケットとは異なって応答することができる。このことは、UEをプログラミングすることにより解決することができ、平均して及び大きな遅延を検出するのと同一の方法で予想よりも早く到達した新しいメディアパケットに追従される失ったメディアパケットを、UEによって、遅延が削減され、及びメディア再生が新たに到達した遅延されていないパケットと共に直接継続するように解釈することができる失ったパケットをパケットロスとして解釈するのではない。BSCバッファによって導かれる遅延を取り扱うことの他の解決策は、BSCメディアを認識させ、又は少なくともRTPを認識されることである。BSCは、UEにメディアパケットを転送する前に入来するメディアストリームのRTPタイムスタンプを変更するように構成することができる。しかしながら、全てのRTPパケットが、必ずしも1つのメディアパケットを含むわけではない。オーディオについて、RTPパケットは、多数オーディオサンプルを含むことができる。これとは対照的に、ビデオについて、同一のRTPタイムスタンプを有する多数RTPパケットは、1つのビデオフレームを含むことができる。このことは、RTPパケットのサイズ及びメディアパケット、即ちオーディオ又はビデオのサイズに依存する。したがって、RTPパケットにおいてRTPタイムスタンプを変更するために、BSCは、メディアについて、RTPパケットが搬送していると認識して、それに応じてタイムスタンプを変更するように構成される。タイムスタンプの変更は、比較的容易に実現することができる。全てのパケットが一定量の時間遅れることになる場合、新しいタイムスタンプが、バッファされたパケットについてその時間量を減算することによって、算出することができる。RTPタイムスタンプを、ETSIRFC3550において規定されるメディアストリームのクロック周波数に基づいて増やす。この点、時間量msをRTPタイムスタンプから減算することを可能にするために、そのクロック周波数が必要となる。多くのペイロードタイプのために、クロック周波数は、公知であり、例えばIETFRFC3551において詳述される。時間どおりパケットを監視し、クロック周波数をペイロードタイプに関連付けることによりクロック周波数を取得することによって、BSCは、メディアストリームで使用されるペイロードタイプを取得することができる。あるいは、このペイロードタイプは、同期設定メッセージにおいて、MSASからBSCまで送信することができる。BSCバッファによって導かれる遅延を取扱うことの更なる解決作としては、UE及びBSCが同期設定指示を受信することができるということがある。これら同期設定指示は、メディアストリームの再生時間についての指示を含む。BSCが遅延を導いて、宛先間同期を達成する場合であっても、UEは、その再生を調整する手段として、同期設定指示を使用することができる。同期設定指示からの情報を通じて、UEは、メディアストリームからのパケットが遅く到達するという事実を認識している。何故ならばBSCがそれらを遅延させたからである。UEが同期設定指示を受信することを可能にする同期方式について、以下に図5及び図6を参照することによって更に詳細に説明する。1又はそれ以上のアクセスラインが中間要素、例えばエンドユーザのUEにメディアストリームを転送する転送UEを備える場合、この転送UEは、エンドユーザのUEからネットワークまで生じている同期ステータス情報メッセージ例えばRTCPメッセージのフォーマットを転送することを可能とすべきである。このような処理は、IETFRFC3550に説明される技術によって実現することができる。その技術については本願明細書に組み込まれるものとする。RFC3550は、メディア経路の2種類の中間要素を規定する。即ち、ミキサ及び変換器である。変換器は、RTP及びRTCPのメッセージを変更することなく転送することができる。したがって、転送UEが変換器のように機能する場合には、RTCPメッセージを後方及び前方に転送することは課題を提起しない。しかしながら、UEが例えば他のコーデックにメディアストリームを変換するトランスコーダとして機能する場合、UEはRTCPメッセージを処理するように構成しなければならない。トランスコーディングの間、UEは、RTPメディアパケット及びRTPタイムスタンプを修正する。したがって、RTCPメッセージをトランスコーディングの中間要素を介してネットワークに送信可能とするために、それは、一緒に属する入来し発出するタイムスタンプを追跡し続ける。換言すれば、トランスコーディングするUEは入力におけるメディアパケットのタイムスタンプを出力におけるメディアパケットのタイムスタンプに、またその逆に、相関させることができる。エンドユーザのUEが同期ステータス情報メッセージを送信する場合、この情報はトランスコードされたRTPストリームのRTPタイムスタンプを含むか又はこれに基づく。したがって、トランスコーディングUEは、入来タイムスタンプと発出タイムスタンプの間の相関情報を使用して、RTPタイムスタンプを入来するRTPストリームの関連付けられた値に変更する必要がある。このように、MSASに送信されるRTCPメッセージは、正しいRTPタイムスタンプに基づく同期ステータス情報を収容する。この処理については、RFC3550において更に詳細に説明する。図3は、本発明の他の実施形態によるコンテンツ配信システムの少なくとも一部を示している。特に、この実施形態では、ETSITISPANTS183063及びTS182027に規定されるIMSベースのIPTV300アーキテクチャに基づいて、コンテンツ配信システムの実施を示している。本システムは、コール/セッション制御機能CSCFのセットを含むIMSコア307を備える。即ち、例えばプロキシCSCFP―CSCF、問合せCSCFI―CSCF及び配給CSCFS―CSCFである。このIMSコアは、更に、ユーザ機器UE305、及びネットワークにおいてIPTVサービスを制御するIPTVサービス制御機能SCF306に接続され、並びに、メディア制御機能MCF202及びメディア配信機能MDF303を含むメディア制御MF301に接続されて、トランスポート機能TF304を介したユーザ機器UEへのメディアコンテンツ及び制御パケットの配信を制御する。TS182027からのIPTVアーキテクチャは、メディア同期アプリケーションサーバMSAS308と共に拡張される。MSAS308は、宛先間同期機能を実行するように構成される。宛先間メディア同期は、特定のメディア、例えば、ビデオフラグメント及び/又はオーディオサンプルについて、異なった宛先で、同時に又は少なくともほとんど同一の時点で、呈示することを可能にする同期機構に関するものである。同期が同期技術と関連づけるインター転送先のメディアは、例えば同じことの異なる目的地の、又は、最も少なくほとんど同じ時のビデオ断片及び/又は音声サンプルの提出を可能にする。IMSシステムは、メディアバッファリングに適用してもよい。メディアバッファリングは、例えば、1又はそれ以上の可変遅延バッファを用いたトランスポート機能で行うことができる。バッファは、同期ステータス情報レポートに付加されるMSASからバッファ設定情報を受信することができる。例えば、RTCP受信機は、同期拡張と共にレポートし、そして、UEがRTPトランスポート制御のためにネットワークに送信する。同期化は、例えば少なくとも1つの可変遅延バッファを用いたバッファリング、及びトランスポート機能における関連付けられたバッファリング同期クライアントBSC310と連携して、UEの位置における測定同期クライアントMSC309によって決定される同期ステータス情報を用いることで実行することができる。MSASは、異なるMSCから同期ステータス情報を収集することができ、また、同期設定指示を送信することによって、関連付けられるBSCにおいてバッファリング処理を制御することができる。IMSコアは、同期設定指示をリソースアドミッション及び制御サブシステムRACS311を用いてトランスポート機能のBSCに送信することができる。図3のIPTVシステムは、セッション開始プロトコルSIPを用いて、ユーザ端末間の、又はユーザ端末とSCF及びMFを備えるアプリケーションサーバ間のセッションをセットアップ及び制御することができる。セッション記述プロトコルSDPは、SIP信号メッセージによって搬送され、セッション内のメディアコンポーネントを記載及び交渉するために用いることができる。更に、リアルタイムストリーミングプロトコルRTPは、例えば、ブロードキャストトリックモード、コンテンツオンデマンドCoD、及びネットワークパーソナルビデオレコーダNPVRを提供するメディア制御のために用いられ、また、リアルタイムトランスポートプロトコル及びRTP制御プロトコルRTCPは、メディアトランスポート及びその制御のためにそれぞれ用いられる。図4は、本発明の一実施形態による、シグナリングフロー400をしめしており、ここでは、IPマルチキャストチャネルへ加入したUEの受信機が同期される。このシナリオは、例えば2人のユーザが、異なる位置の異なるUEに対して同期される方法により同一のライブコンテンツ例えばマルチキャストされたサッカーの試合を視聴することを望むときに、適用することができる。宛先間同期は、継続するチャットセッション又はオープンしている電話ラインを介して、1ユーザが他のユーザの数秒前にゴールを見るというリスクをとることなく、試合を共に楽しみながら、ユーザ間の相互作用を可能にすることができる。第1ステップ402において、UEはIMSコアにメディアセッションのセットアップを要求する。このリクエストメッセージは、例えばETSITS182027及びETSITS183063で規定されたSIPインバイトメッセージとすることができる。このリクエストは、IMSコアによってSCFに転送することができるステップ404。SCFはベーシックIPTVメディア配信について高度なサービスを提供する。このSCFは、セットアップされるセッションについての更なる情報を含む応答メッセージ、例えばSIP200OKメッセージと共にこの要求に返答することができる。この更なる情報は、MSASのアドレス、例えばURL又はIPアドレス、及び同期する端末のグループを特定するためのグループ同期識別子SyncGroupIdを含むことができる。このグループ同期識別子は、例えば応答メッセージのSDPパラメータとして含むことができる。IMSコアは、引き続き、応答メッセージを要求元UEへ戻しステップ406、412、そして、要求されたメディアセッションが同期を要求とすることをRACSに通知する。このRACSは、ETSITS183017によりDiameterメッセージを使用して通知されることができる。Diameterは、拡張可能なプロトコルであり、同期化の目的で、必要となる同期情報を収容する新規な属性値ペアを規定することによって、延長することができる。特に、Diameter同期設定要求408は、同期セッションを特定する情報、例えばSyncGroupId、同期されるメディアストリームを特定するための情報例えば、SIP応答メッセージ内の1又はそれ以上のセッション記述プロトコルSDPパラメータ、関係するUEを特定するための情報例えば、メディアストリームをセットアップするUEのIPアドレス、及びこの特定のメディア同期に対する同期サーバとして割り当てられたMSASのアドレスを含むことができる。例えばDHCPを使用して、ネットワークは、IPアドレスをUEに割り当てることができる。ネットワークは、IPアドレスの特定の範囲内で、IPアドレスをUEに割り当てることができ、IPアドレスはBSCを収容するあるネットワークノードに関連付けられてもよい。RACSは、IPアドレス範囲のリスト及びIPアドレス範囲の各々に関連付けられるBSCのアドレスを用いて提供又は構成することができる。同期設定要求メッセージ408におけるUEのIPアドレスを用いて、このRACSは、リストに基づきBSCを特定することができる。BSCは、メディアセッションに関連付けられたバッファリングメディアストリームに適している。BSCは、メディア供給元とUEの間の媒体経路内にあり、又は、それに関連付けられている場合、UEと共に使用可能である。RACSが同期化のためのバッファとして用いられるBSCのIPアドレスを決定した後、それはこのアドレスを同期設定要求に挿入することができる。同期設定要求は、引き続き、例えばDiameterメッセージ410を用いてMSASに転送される。メッセージ410は、IMSコアからRACSに送信される同期設定要求408と同一又は類似のフォーマットを有することができる。また、BSC識別子、例えばBSCIPアドレスを収容する属性値ペアを用いて拡張することができる。BSCを割り当てる、又は位置を特定する機構は、上記の実施形態に限定されない。一実施形態において、SCFは、UE及びBSCについてのリストを保持することができる。このリストを使用して、BSCをUEが要求したメディアセッションに割り当てることができ、選択したBSCを直接MSASに伝達することができる。他の実施形態において、RACSは、直接MSASに通知せず、それをSCFによって割り当てられたMSASへレポートするようにBSCに指示する。さらに別の実施形態において、BSCアドレスを、UEに伝達することができる。このUEは、その後に、ステータス情報レポートの一部としてMSASにこのアドレスを伝達することができる。この変形形態において、BSCアドレスは、例えばBSCIPアドレス及び、任意に、ポート番号を含むRTCPメッセージ内のフィールドと関連付けることができる。したがって、SCF及び/又は、RACSが適切なBSCをUEに割り当てるように構成することができる。一実施形態において、このようなBSCは、エッジノード、例えばDSLAM又はCMTS内に共に位置することができる。どのUE1又は複数が特定のエッジノードの後方にあるか即ち、1又はそれ以上のUEのエッジノードへの関連付けを特定することの課題は、様々な方法で解決することができる。通例は、UEに接続されたエッジノードが、DHCPを用いてUEにIPアドレス供給する。UEに割り当てられるIPアドレスが一意なものである場合、それがどのエッジノードに割り当てられているかについて、インジケータとして使用することができる。ネットワーク内のエッジノードに対するIPアドレス範囲の割当ては、例えば、手動での構成によって予め決定することができ、ネットワークにアクセス可能であるデータベース内のどこかに格納されたリストに保持することができる。このリストは、コピーすることができるか又は、SCF及び/又はRACSによってアクセス可能とすることができる。適切なBSCを選択するための更なる変形例として、ネットワーク内で既に利用可能なネットワークトポロジ情報に基づいてもよい。例えば、多くの固定ネットワークは、ネットワーク管理システムを備える。このシステムはどの顧客がどのアクセスラインの後方にいるかについて追跡する。同様に、例えば呼設定及びハンドオーバに対処するために、モバイルネットワークは、継続して、どの基地局がどの端末によって使用されるかについて追跡する。したがって、このような状況下において、ネットワークトポロジ情報は、ネットワーク内で全て既に利用可能である。また、このネットワークトポロジ情報は、適切なBSCを選択する目的で使用することができる。他の変形形態において、BSCはネットワークノードに位置することができる。このネットワークノードは、ネットワーク階層の高いところにあり、即ち、ネットワークノードは、全て又は大部分の少なくともメディアストリームが進行するネットワークノードである。更なるもう一つのオプションとして、メディア供給元とUEの間のルートを決定することができる。このことは、メディア供給元からUEへ又はその逆の経路探索メッセージを送信することによって、実現できる。経路探索メッセージは、大部分のオペレーティングシステムで利用可能であり、時折、tracepath又はtracertと呼ばれる。この経路探索メッセージは、ネットワーク内の2つのエンティティ間を伝わる全てのネットワークノードのリストを戻すことができる。BSC機能性を収容する全てのノードのリストが利用可能である場合、BSC機能性を収容する1つネットワークノードが、経路探索動作によって戻されるネットワークノードのリストから選択することができる。これから図4のフローに戻る。ステップ410において、MSASは、同期セッションセットアップ情報を含む同期設定要求を受信する。同期セッションセットアップ情報は、次のものを含む多くの情報項目を含むことができる。即ち、-UEに関連付けられる識別子、例えばUEにより現在用いられているIPアドレスに関連付けられる識別子、-BSCに関連付けられる識別子、例えばBSCのIPアドレス及びあるいはポート番号、-同期グループに関連付けられる識別子、例えば同期グループIDSyncGroupId、そして-コンテンツに関連付けられる識別子、例えばメディアストリームに関連付けられた1又はそれ以上のSDPパラメータ、である。1つのSDPパラメータは、メディアパケットを送信するためのポート番号に関することができる。UEのIPアドレスと組み合わされるこのポート番号は、メディアストリームに対する識別子として使用することができる。メディアコンテンツを特定するための他の変形例は、IETFRFC3550に規定されたSSRCを使用してもよい。SSRCは、メディア供給元によってメディアストリームに割り当てられ、メディアストリームのセットアップの間にMSASに伝達することができる。MSASは、この情報をメモリ又はデータベースに格納することができる。更に、それは、この情報をMSASにおける現在の同期情報に相関させることができる。例えば、一実施形態において、SyncGroupIdに基づいて、MSASは、どの他のメディア宛先が同一の同期グループの一部であるかについて判断することができる。この情報は、遅延設定を算出するために、後の段階で、MSASによって使用することができる。UEによって受信される応答メッセージ412は、MSAS及びSyncGroupIdの位置を含んでいる、メディアセットアップ及び同期について必要とされる全ての情報をUEに提供することができる。任意には、バッファリングが他のエンティティにおいて実行されるという指標を含むことができる。セッションセットアップの承認ステップ414,416の後に、UEは、例えば、選択したマルチキャストストリームの配信を要求するためにIGMPを使用することができる。同期化目的のために、UEのMSCは、次いで、同期ステータス情報をMSASに送信することができるステップ418。これに応じて、MSASは、同期設定指示を生成して、BSCにこれらの指示を転送することができるステップ420。同期ステータス情報及び同期設定インストラクションの伝送は、例えば拡張されたRTCP送信機及び受信機のレポートを用いて機構をレポートするRTCPを使用して実現することができる、そして、受信機がレポートする。当該レポートについて以下に更に詳細に説明する。MSCから受信する同期ステータス情報は、メディアストリーム内の特定のサンプルを特定するためのRTPタイムスタンプ及びNTPタイムスタンプを含むことができる。例えば、RTCP受信機レポートが1234のRTPタイムスタンプ及び2月3日、10時14分15秒を示すNTPタイムスタンプを収容するとき、それは、メディアストリーム内のサンプル1234が正確に2月3日10時14分15秒に生じたことを意味する。このように、NTPタイムスタンプは、UEがレポートするサンプリングイベントの実際の絶対時間を表わす。同期化目的のために、宛先間メディア同期に関わる全てのUEは、例えばNTPネットワークタイムプロトコルに基づいて公知技術を用いて同期されるクロックを使用することが想定される。RTPタイムスタンプは、RTPデータパケットの第1オクテットのサンプリングの瞬間を反映する。このサンプリングの瞬間は、同期及びジッタ算出を可能にするために、時点において単調に及び線形にインクリメントするクロックから導出されなければならない。RTPタイムスタンプは、このように、メディアストリーム内のサンプルの瞬間の時点に関する情報を提供する。同期化は、さまざまなタイミングイベントに基づくもの、例えばUEによってメディアを受信する時間又はメディアがユーザに呈示される時間に基づくものとすることができる。本例示では、同期ステータス情報のRTPタイムスタンプが、示されたNTP時間で受信するメディアパケットを反映することが想定される。MSASは、1又はそれ以上の同期グループにおける異なるメディアの宛先通例はUEのMSCについての同期ステータス情報を受信及び管理する。収集した同期ステータス情報に基づいて、MSASは、引き続き、UEに関連付けられたBSCについての遅延設定指示を算出することができる。これらの遅延設定指示は、最も多くの遅延を有するメディアの宛先を特定して、次いでその特定した最も多く遅延したメディアの宛先の再生時間に一致させるために導くことが必要となる他のメディアの宛先の遅延量を計算することによって算出される。遅延設定指示はBSCについての指示に関し、RTPタイムスタンプ及びNTPタイムスタンプの所与のタイムスタンプの組合せに仮想的に一致させるような方法で、BSCがメディアパケットを処理することを可能にする。遅延設定指示の算出は、基準タイムスタンプ、例えばNTPタイムスタンプの選択、また、全てのメディアの宛先についての関連付けられたRTPタイムスタンプの算出を含むことができる。第一の実施形態において、例えばMSASは、特定のRTPタイムスタンプを選択することができ、また、どのNTPタイムスタンプでそれらが選択されたRTPタイムスタンプと関連付けられたメディアパケットを処理すべきかについて、メディアの宛先ごとに算出することができる。他の実施形態において、MSASは、NTPタイムスタンプを選択することができ、どのRTPタイムスタンプが選択されたNTPタイムスタンプと関連付けられるべきかについて、メディアの宛先ごとに算出することができる。MSASが現在のNTP又はRTPタイムスタンプを選択する必要はないことに留意されたい。問題となるのは、NTP及びRPTの間の関係であり、現在のタイムスタンプ、又は、過去又は現在における仮想的な同期時点を反映しているタイムスタンプを使用することができる。RTPタイムスタンプが、IETFRFC3550による絶対時間ではなく周波数を示すので、サンプリングレートを決定することが必要となる。このことは、例えば公知のIETFRFC3551からペイロードタイプ及びそれらの関連付けられた特定のサンプリングレートを決定すること、又は2若しくはそれ以上のステータス情報レポートを用いることのいずれかによって、行うことができる。例えば、第1の状況レポートはNTPタイムスタンプNTP_xと共にRTPタイムスタンプRTP_x、及びNTPタイムスタンプNTP_yと共に第2の状況レポートRTPタイムスタンプRTP_yを収容することができる。ここでは、NTP_yはNTP_xより後の時点に関する。この情報に基づいて、周波数又はクロックレート=RTP_y―RTP_x/NTP_y―NTP_xを判断することができる。レポートされたメディアパケットの到達時間は、例えばネットワークジッタのため、いくつか不正確性を含むこともある。これらの不正確性は、除去することができる、又は、2若しくはそれ以上のステータス情報レポートを使用することにより少なくても削減することができる。算出された値が、頻繁に用いられるある固定のクロックレート例えば8000Hz、44100Hz及び90000Hzのに近い場合、MSASはこれら公知の値の1つが使われると想定することができる。一旦MSASがクロックレートを決定すると、BSCについての遅延設定指示は算出することができる。UE1及びUE2のそれぞれに関連付けられたステータス情報レポート値についての次の例を検討する。90000Hzのクロックレートが以下に用いられる。即ち、-UE1は、NTP時間の01時23分45.678秒NTP_UE1におけるRTPタイムスタンプ2070000RTP_UEl_Reportedをレポートする、及び-UE2は、NTP時間01時23分46.678秒NTP_UE2におけるRTPタイムスタンプ2250000RTP_UE2_Reportedをレポートする。MSASは、まず、基準タイムスタンプの選択、及び当該基準タイムスタンプを基礎として使用する他のタイムスタンプの計算により、最も大きい遅延を決定する。例えば、MSASは、UE1のNTPタイムスタンプを選択し、このNTP時間におけるUE2のRTPタイムスタンプを算出することができる。即ち、RTP_UE2_calculated=RTP_UE2_reported90000NTP_UE1―NTP_UE2この算出の結果はRTP_UE2_calculated=2160000であり、UE1が最も遅延したUEであることを示す。換言すれば、NTP_UE1時間においてで、UE2のRTPタイムスタンプ値は、UE1と関連付けられたものよりも大きい。したがって、宛先間同期を達成するために、UE2は再生を遅延させる必要がある。遅延設定指示を算出した後に、MSASは、指示を適当なBSCに送信することができる。これらの指示は、算出したRTP及びNTPのタイムスタンプ、並びに遅延されるメディアストリームを識別するための手段一例では、UEのIPアドレス及びメディアを受信するポート番号、又はRTPプロトコルで用いられるメディアストリームのSSRC識別子を例えば収容することができる。MSC及びBSCがメディ経路における異なる位置に配置されるので、BSCは、UEでMSCによって送信された同期ステータス情報についてのナレッジ、及びどのメディアユニットをUEが現在呈示しているかについてのナレッジを有さない。したがって、それは、遅延を導くべきであるか又は取り除くべきかどうか決定することができない。この理由のために、一実施形態において、MSASは、UEにおいてMSCから遅延設定指示に対して発せられるステータス情報レポートを含むことができ、その結果、BSCは、MSASによって決定されるように、必要となる遅延をRTP及びNTPのタイムスタンプに基づいて算出することができる。したがって、UE1及びUE2についての遅延設定指示は、UE1のステータス情報レポートからの値及びRTP_UE2_calculated値を含むことができ、UE1が遅延無を必要とすることを決定し、UE2が第2の遅延2160000―2070000=90000、これは正確に1秒の所与のクロックレートに等しいを決定することを可能にする。一旦BSCが指示を受信すると、それはストリーム識別手段に基づいて適切なストリームの配置し、その指示に基づいて導く又は取り除くための遅延量を算出することができる。その後に、このBSCは、必要とされる遅延を導くことができる。遅延は、幾らかの時間にわたりメディアパケットを送信するのを停止することにより、又は、RTPパケット及びRTCPパケットの両方のRTPタイムスタンプを変更することにより、実現することができる。遅延設定指示は、過去からのNTP又はRTPのタイムスタンプを含むことができる。所与のNTP及びRTPのタイムスタンプが一致するように、遅延設定指示の受信機、例えばBSCは、メディアストリームの遅延を導くべきである。パケットが全て対処されることの準備ができているRTPタイムスタンプをその指示が収容する場合であっても、その指示の受信機は、その指示を、現在対処されるタイムスタンプに変換しなければならない。NTP及びRTPのタイムスタンプは、また、受信機において決して到達しないメディアパケットと関連付けることもできる。ある意味で、このようなタイムスタンプは、仮想的であるとみなすことができる。同期を命ずるのは、NTP及びRTPタイムスタンプの組合せである。MSASは、UEに対し、UEがあたかもRTPタイムスタンプ、NTPタイムスタンプにあるべきである、又はあることができるように振る舞うことを通知する。MSCが決定及び送信した同期ステータス情報が異なるパケット処理時間例えばパケット到達時間、パケット呈示時間又はパケットデコード時間に基づく又は関連付けることができるので、遅延設定指示は、原則として、同一のパケット処理時間に基づくべきである。例えば、同期ステータス情報が、パケット到達時間に基づく場合、遅延設定指示は、また、パケット到達時間に基づくとすべきでもある。異なる処理時点到達、デコーディング、呈示の間の時間差が一定で公知である場合には、このステータスレポートはパケット到達時間に基づいてもよく、その一方で、設定指示はパケット呈示時間に基づいてもよい。NTP及びRTPのタイムスタンプの代わりに、他の実施形態において、BSCに送信される遅延設定指示は、をセットしているインストラクションは、他の実施形態では、BSCに対して第2のメディアストリームを1000ミリ秒バッファする指示を含むことができる。あるいは、遅延設定指示は、BSCに対し、1000ミリ秒の遅延が実現されるように、宛先間同期のバッファサイズ遅延を増加させるように指示することができる。これらの場合では、必要となる遅延を算出するのはMSASである。図5は、本発明の更なる別の実施形態による、コンテンツ配信システム500の少なくとも一部を示している。特に、図5では、図2を参照して記載したものと類似のIMSベースのIPTVアーキテクチャの一部を示している。本システムは、基本処理機能及び基本転送機能ECF/EFF504を備えるトランスポート機能502及びBSC506を備える。BSC506はこのECF/EFF又はその一部と共に配置される。MDF508は、宛先としてメディアストリーム510をUE512に届ける。メディアストリームは、TF502を通じて、BSC506を介してUEのMSC514まで移送される。メディアストリーム510の受信に応答して、UEのMSCは、同期ステータス情報メッセージ516、即ち同期ステータス情報レポートを、MSAS518に対して生成する。図3及び図4を参照して説明したシステムとは対照的に、同期ステータス情報メッセージは、BSC506を介してMSASに送信される。受信した同期ステータス情報に基づいて、このMSASは、引き続き、同期設定指示518を算出して、これらの指示をUEにBSCを介して送信する。しかしながら、UEにこれらのメッセージを転送する代わりに、BSCは、これら同期設定指示を遮断し、これらをUEに転送しない。この例では、UE、MDF及びMSASのいずれもが、BSCが呈示している任務を認識するというわけではない。このBSCは、メディアストリーム及び全ての同期メッセージの両方の経路にあるので、それは、これらのメッセージ及びメディアストリームを遮断し、監視し及び/又は調整することができる。図6は、図5を参照して説明したシステムに関連付けられるメッセージフロー600を示している。特に、図6は、同期メッセージについてのメッセージフロー及びMDFからUEまで届けられるメディアストリームを示している。第1ステップ602において、UEは、同期ステータス情報レポートをMSASに送信する。このレポートは、ステータス情報を収容するRTCP拡張レポートブロックで拡張されるRTCP受信機レポートの形態を有することができる。このレポートがMSASに転送される前に、このメッセージはECF/EFFによって遮断される。このメッセージは、2つの理由により、ECF/EFFによって遮断される。第1の理由は、ECF/EFFのBSCによっていかなるバッファリングも実行するために、BSCが同期ステータス情報レポートの情報、例えばMSCの特定のメディアストリームパケットのパケット到達時間についてのタイミング情報を使用できるということである。BSCが、それによってどのくらいメディアストリームを遅延させるかを認識することを望む場合、BSCは、いくつかの方法でこの情報を受信及び/又は決定することができる。第1の変形形態において、MSASは、例えばy秒の間メディアストリームxを遅延させるという形態で、絶対指示を送信することができる。BSCは、UEから発している同期状況レポートから、いかなるナレッジなしにこれらの指示を実行することができる。他の変形形態において、MSASは、これらのメディアパケットが指定された時間に到達したときに、メディアを再生するという形態で指示を送信することができる。その場合、例えばUEから発している同期状況レポートに含まれているようにUEにおいてパケット到達時間を認識しているときに、BSCはこれらの指示を実行することができる。UEからMSASまで送信される同期ステータス情報メッセージを遮断することによって、BSCは、到達時間情報を含むこれらメッセージの情報を認識する。BSCは、MSASからUEまで送信される同期設定インストラクションに収容される情報と結合して使用するために、一時的にこの情報を格納することができる。そのように、ステータス情報及び設定指示を使用して、BSCは、メディアストリームを遅延させるべきか、及びどれくらい遅延させるべきかを決定することができる。この同期ステータス情報メッセージを遮断する第2の理由は、それにより、BSCがメッセージ内の情報を調整することを可能にするからである。MSC及びBSCがメディア経路上の異なる位置に配置されるため、この情報の調整が必要となる。MSCがUEに位置する状況において、BSCにより導かれるメディアストリームの遅延は、到達時間情報の遅延に結果としてなるであろう。MSC及びBSCが共に1つの同期クライアントに位置する場合には、このような状況は発生しない。一旦パケットが到着したならば、即ち、メディアパケット到達時間を決定した後に、いかなる遅延もが導かれる。したがって、メディアストリームはMSCに到達する前に遅延されるので、同期ステータス情報メッセージは、BSC及びMSCが1つの位置で結合される状況と比較した際に、異なるタイミング情報を収容するであろう。この効果を補正するために、BSCは、UEからMSASまで送信される同期ステータス情報メッセージを調整することができる。BSCは、どの時間量までメディアストリームを遅延させるかについて認識しているので、この値をステータス情報レポートにおいて報告される到達時間から減算することができる。BSCがこの動作を実行しない場合には、BSCがメディアストリームを遅延させない状況において、又は、BSCが時間内のある時点で行うことよりも少なくストリームを遅延させる状況において、UEは、とても後にメディアパケットを受信するようである。したがって、BSCが遅延を導くときに、ステータス情報メッセージがそれを反映するように調整することができる。レポートでの情報の遮断及び調整の後に、BSCは同期ステータス情報をMSASに送信することができステップ604、これに応答して同期設定指示をUEに戻すことができるステップ606。再度、BSCはこれら同期設定指示を遮断し、ステータス情報及び設定指示から導かれる時間量によってメディアストリームを遅延させることができる。BSCは、UEに同期メッセージを転送することもでき、又はそうしないこともできる。このことは、ステップ608の破線矢印によって示されている。BSCが設定指示を実行するので、UEはそれらにメディア呈示を遅延させることを要求しない。それにもかかわらず、設定指示を実行するのに加えて、BSCは、また、UEに指示を転送することもできる。このUEは、これら指示の情報を用いて、メディアパケットを処理する、例えば適切な時間にそれらを呈示することができる。図7は、RTPメディアストリームに関連付けられた宛先間メディア同期情報をレポートするための考えられるRTCPXRのブロックタイプの一例を示したものである。この規定は、IETFRFC3611に基づく。このRTCPXRは、RTPパケットの受信時間及び呈示時間に関する情報を、例えば、IETFRFC3550に規定される送信機、IETFdraft―ietf―avt―rtcpssm―19において規定されるフィードバックターゲット、又はIETFRFC3550において規定される第三者モニタに対してレポートするのに用いられる。このRTCPXRは、また、例えば図3及び図6のメッセージフローにおいて示されるような同期メディア再生に関わる、同期ステータス情報、並びに様々な要素、特にMSC、BSC及びMSASの間の同期設定指示を交換するのに用いられる。IETFRFC3611において規定されるとおり、最初の64ビットは、RTCPXRのヘッダを形成する。宛先間同期RTCPXRは、以下のフィールドの1又はそれ以上を含むことができる。即ち、-パケット送信機のSSRCが特定のRTCPパケットの発信者を特定する。-ブロックタイプBTは8ビットであり、ブロックフォーマットを特定する。-同期パケット送信機タイプSPSTは4ビットであり、このフィールドは、この特性の拡張レポートについてのパケット送信機の役割を特定する。これは、以下の値を有することができる。即ち、1.SC:パケット送信機は、同期ステータス情報をレポートするために、このXRを使用する。タイムスタンプは、SC入力に関する。MSAS:パケット送信機は、同期設定指示をレポートするために、このXRを使用する。タイムスタンプは仮想SCの入力に関し、当該仮想SCは、このMSASに接続するSCが同期されるのを参照するものとして動作する。-予約ビットResrv:3ビットである。-パケット呈示NTPタイムスタンプフラグP:1ビットであり、ビットは、パケット呈示NTPタイムスタンプが値を収容するときは1に、それが空である場合には0に設定する。このフラグがゼロに設定される場合には、パケット呈示NTPタイムスタンプは検査されない。-ブロック長:16ビットであり、このRTCPBlockTypeが固定長を有するので、これは7に設定される。-ペイロードタイプPT:7ビットであり、このフィールドは、IETFRFC3551にしたがってメディアペイロードのフォーマットを特定する。このメディアペイロードは、RTPタイムスタンプのクロックレートに関連付けられる。このクロックレートは、RTPタイムスタンプにタイムベースを提供する。-予約のビットResrv:25ビットである。-メディアストリーム相関識別子:32ビットであり、この識別子は、同期されたメディアストリームを相関させるのに用いる。値が0全てのビットが0に設定されるは、このフィールドが空であることを示す。値が2^32―1全てのビットが1に設定されるは、将来の使用のために予約されている。RTCPパケット送信機がSC又はMSASSPST=1又はSPST=2であるときは、メディアストリーム相関識別子が同期グループIDSyncGroupIdにマップする。-SSRC:32ビットであり、メディア供給元のSSRCは、XRが関係するRTPパケットにおけるRTPヘッダで搬送されるSSRC識別子の値にセットされる。-パケット受信NTPタイムスタンプ:64ビットであり、このNTPタイムスタンプは、XRが関係するRTPパケットの第1オクテットの到達ウォールクロック時間である。SPST=2に対し、それは、同期グループの他のSCが同期することができる仮想SCに関する。-パケット受信RTPタイムスタンプ:32ビットであり、このタイムスタンプは、XRが関係するRTPパケットにおけるRTPヘッダで搬送されるRTPタイムスタンプの値を有する。-パケット呈示NTPタイムスタンプ:32ビットであり、このタイムスタンプは、関連付けられたRTPパケットの第1オクテットに収容されるデータがユーザに呈示されるNTP時間を反映する。それは、最も重要でない16ビットのNTP秒部分、及び最も重要な16ビットのNTP少数部分を含む。このフィールドが空である場合には、それは0にセットされ、パケット呈示NTPタイムスタンプフラグPは0にセットされる。図8は、本発明の一実施形態によるBSC800を示している。特に、それはバッファ802を含むBSC800を示しており、第1UE1804及び第2のUE2806によって共有される。UE1は、第1の同期メディアストリーム808を受信し、UE2は、第2の同期メディアストリーム810を受信する。この例において、メディアストリーム808及び810は、入来するメディアストリーム812から発しており、第1メディアストリームの特定パケットがUE2よりUE1に早く送信されるという例外を有する同一の内容に関係する、同一のメディアストリームである。このBSCは、BSCの処理を制御するためのコントローラ814を備える。例えば、このコントローラは、MSASから同期設定情報816を受信し、同期グループ内の異なるUEに関連付けられた遅延を算出し、1又はそれ以上の遅延メディアストリームをUEに伝送することができる。UE1及びUE2が互いに同期された閲覧セッションにあり即ち、これらは同じ同期グループに属する、BSCとUE1の間のメディア経路に関連するネットワーク遅延がBSCとUE2の間のメディア経路に関連するネットワーク遅延より大きいにために、BSCは遅延を導いて、UEとBSCを備えるアクセスノードとの間のアクセスラインの遅延を補償する。したがって、特定のメディアパケット、例えばビデオフレーム又は音声サンプルは、UE1及びUE2が実質的に同期される方法でメディアストリームを受信することを可能にするために、UE1により早く送信しなければならない。図8に、2つのUE間で共有することを示す。同じBSCを用いて同一のコンテンツを閲覧し、及び/又は1つの同期グループに所属するUEは、バッファを共有することができる。他の実施形態において、BSCは、異なる同期グループについての同一のコンテンツのバッファリングを実行することができる。いずれの場合においても、バッファ容量及びBSCへ入来するネットワーク負荷の点で、単一のバッファを使用することがより効率的である。バッファは、First―InーFirstーOutFIFO方式により動作することができる。発しているメディアストリーム812から受信する新しいバッファは、バッファ802に追加され、バッファ内で最も長いパケットが最初に除去される。バッファは、UE識別子820及び関連付けられるポインタ822を含むバッファリスト818を保持することにより多数UEで共有することができる。ここでは、IDがBSCを共有するUEを特定する。そして、ポインタがその対応するUEに送信される次のパケットをポイントする。例えば、バッファリスト818は、UE1に関連付けられる第1のポインタを含むことができ、バッファ内のパケット5及びUE2と関連付けられた第2ポインタをポイントし、バッファのパケット8をポイントする。パケットが特定のUEに送信されるたびに、BSCはリスト、特にその中のポインタを維持及び更新する必要がある。BSCは、継続的に各メディアストリームをバッファする必要はない。例えば、このBSCは、当該BSCが異なるUEに関連付けられた遅延を変更して取り扱うことを可能とするために、15秒間メディアストリームをバッファするだけでよい。図9A及び図9Bは、宛先間同期の目的のバッファリング方式の概略図を示している。これらの図は、本発明と関係した更なる利点を示しており、特に、改良した時間を変更するチャネルの効果に関連した利点について示している。図9Aは、UE902が測定機能904及びバッファリング機能906を備える同期クライアントを備えるシステムを示している。このような場合には、バッファ機能は、宛先間バッファ及びジッタバッファの両方として機能するように構成することができる。UEは、UE902のユーザに表示されるビデオフレームを収容する第1のメディアストリーム908を受信する。UE902は、宛先間同期セッションの一部とすることができる。したがって、同期化を可能にするために、UE902は、バッファリング機能、で受信したメディアのバッファリングを実行することを必要とすることもある。この場合は、10個のメディアユニット、例えばビデオフレームである。バッファ機能はまた、ジッタバッファとして機能するために、数を追加したフレーム、例えば5つのビデオフレームがバッファされ、これにより、バッファ機能において合計15個のビデオフレームをバッファリングする。ある時点で、UEのユーザは、第1のメディアストリーム908から第2のメディアストリーム910へ切り替える必要があることもある。チャネル変更の間、このUEは、まず、第2ストリーム910からメディアユニットのバッファリングを開始する必要があり得る。宛先間同期なしで、短い期間だけが、ジッタを取り扱う目的でバッファリングされることを必要とする。しかしながら、UEのバッファ機能がまた、宛先間同期の目的でバッファリングをも行うため、ビデオフレームの追加のバッファリングが、バッファされたビデオフレームのユーザへの表示を開始する前に、必要となる。例えば、メディアユニットが毎秒25個のフレームを有するビデオストリームに関する場合には、フレームのみを、ジッタバッファリング目的のためにバッファすることが必要となる。これは、概ね200ミリ秒の遅延を導く。このような遅延は、チャネルを変更するのになお使用可能な時間としてもよい。しかしながら、図9AのBSCは、ジッタ及び宛先間同期の両方を取り扱うための15個のフレームをバッファリングすることを必要とする。このようなバッファリングは、600ミリ秒、即ちジッタのみを取扱う状況に対するものと比べて3倍の遅延を引き起こすことになる。チャネル変更時間のこのような増加は、ユーザ体験を劣化させ得るだろう。図9Bは、MSC及びBSCがUEとメディア供給元との間のメディア経路上で異なる位置すなわち複数の位置に配置される方式に関する。この場合、UE912は、MSC914及びジッタバッファ916を収容する。第1のBSC1918は、ネットワーク内のメディア供給元とUEとの間のメディア経路のどこかに位置する。BSC1918は、現在の第1チャンネルについてバッファリングすることができる。即ち、第1チャンネルを含む第1ストリーム920が10個のメディアユニット例えばビデオフレームについて、これらフレームがUE912に転送される前にバッファされる。ネットワークは、更に、第2のチャネルを含む第2のメディアストリーム924をバッファする第2のBSC922を備える。図9Aの方式と比較すると、図9Bの方式はいくつかの利点を提供している。第1に、ジッタバッファのサイズこの例では3個のメディアユニットは、BSCとUEの間のより短いメディア経路のために、減少することができる。ジッタはネットワーク内で導出され、したがって、ネットワーク経路がより長くより短くなると、メディアストリーム内のパケットの遅延差がより大きくより小さくなる。図9Bの例では、第1のBSC1は、実質的に如何なるジッタもない規則的な間隔を有するメディアストリーム926内のメディアユニットを送出する。より短いメディア経路は、ジッタをより小さくし、したがってより小さいジッタバッファを必要とする。1秒当たり25個のフレームレートを使用すると、図9Aで示される方式において必要される5つのフレームのバッファリングに関連付けられた200ミリ秒の遅延ではなく、120ミリ秒の遅延が導かれる。第2に、チャネル変更時間は、UEが宛先間同期の目的のためにバッファする必要がないことから、より短い。その代わりに、BSC1を収容するネットワーク内のノードは、宛先間同期に必要とされる10個のフレームについてバッファリングの後処理をする。第2のメディアストリームが第2BSC2912によってすでにバッファされているので、メディア再生は直ちに開始することができる。毎秒25個のフレームレートでは、チャネル変更の間の追加の400ミリ秒の遅延を保存することができる。したがって、チャネル変更の遅延は120ミリ秒に減らすことができ、これにより、図9Aの例示における600ミリ秒の遅延と比較したときにチャネル変更時間の重大な削減をもたらす。ザッピングに関する課題の1つは、宛先間同期の目的のために新しいチャンネルについてのバッファサイズを決定することである。最も単純な解決策は、例えば同一の時間量又は同一のビデオフレーム量の古いチャネルと同様に、新しいチャネルを遅延させることである。しかしながら、新しいチャンネルの遅延を決定するより正確な方法がまた可能である。一実施形態において、BSCは、異なるメディアストリームに関連付けられる特定のステータス情報の履歴を格納することができ、また、この履歴を用いて正確な同期設定指示を決定することができる。例えば、メディアストリームAに関連付けられたステータス情報レポートに基づいて、MSASは、設定指示をBSCに送信することができ、UE及びこの同期グループに対してxミリ秒の間ストリームを遅延させる。UEがメディアストリームBへ切り替えるときに、最初に、BSCは、メディアストリームAに対して用いられたのと同一量のミリ秒についてメディアストリームBを遅延させる。しかしながら、UEからの新しいステータス情報レポートをMSASが受信する場合には、UEに対してストリームBをyミリ秒遅延させることを命じる新しい同期設定命令を算出し、BSCへ送信する。変更した唯一のものがメディアストリームであるので、yとxの間の差は、これらメディアストリーム間で切り替わるために他の端末で使用することができる。十分なチャネル変更がBSCを用いてUEについて発生する場合には、BSCは、様々なチャネルに対する想定遅延を含むチャネル切替リストを作成することができる。このリストは、1つのチャネルから別のチャネルへ切り替える任意のUEについて適切な遅延を選択するために用いることができる。図10は、本発明の別の実施例によるコンテンツ配信システム1000の少なくとも一部分を示している。本実施形態において、このシステムは、多くのUEに1又はそれ以上のネットワークノードを介してメディアストリームを届けるためにメディア供給元1002を備える。UEによってメディアストリームの同期化された再生を可能とするために、各UE1004―1008がBSC1010―1016を備え、MSC1018、1020はネットワーク1022内においてメディア供給元と各UEの間のメディア経路上のどこかに位置する同期方式が実装される。MSCは、メディア供給元からのメディアストリーム1024を受信し、また、このストリームをメディアストリーム1026―1030としてUEに転送する。この例では、メディアストリーム1024はマルチキャストストリームとして配信することができる。ここでは、このマルチキャストされたメディアストリームはマルチキャストホップにおいて3つのメディアストリーム1026―1030に分割される。MSC1018、1020は、マルチキャストストリームを異なるUEに届けるのに分割する必要がある位置に配置される。このような位置は、xDSLネットワークのDSLAM又はケーブルネットワークのCMTSといったネットワークのエッジノードとすることができる。ネットワーク内のMSC及びUEのBSCの使用は、MSCの位置からその特定にMSCを通じて伝送されるメディアトラフィックを受信する異なるUEへのメディアのトランスポート間であまり大きな遅延差がない場合には、ほぼ正常に実行することになる。例えば図1に示したような、大きな差が存在する場合には、このようなシナリオは、宛先間同期の目的で最適には実行しないことになる。MSC1018、1020は、メディアユニット到達時間の測定を実行することができ、これら測定された到達時間情報を同期ステータス情報1032、1034として同期サーバMSAS1036にレポートすることができる。このMSASは、全てのMSCから全ての同期ステータス情報を収集することができる。この同期ステータス情報は、宛先間同期に必要となるメディアストリーム及びUEに関する。次いで、適切な同期設定指示を算出して、これら指示1038―1042を、それぞれBSCを備えた異なるUEに送信する。なお、これは、宛先間同期に関わる全てのUEがネットワーク内の単一のMSCの後方にある場合には、あまり役立たないことに注意されたい。図10に示すような同期方式は、2つの明確な利点を有する。第1の利点は、この方式が宛先官同期の目的のためにネットワークを移動するのに必要なメッセージをより少なくするという事実に関する。UEがMSC及びBSCの両方を備える場合例えば図9Aを参照のことには、全てのUEはそれら自身の同期ステータス情報メッセージを同期サーバに送信する。図10に示される実施形態において、ネットワーク内の1つのMSCは、多数UEに代わって1つのステータス情報メッセージを送信ことができ、これにより、メッセージの数を著しく減少させることができる。全てのUEは、なおもそれらの自身の同期設定指示を受信することになるが、通例は、ステータス情報メッセージの数がより大きくなるか、少なくとも設定指示メッセージの数に等しくなるであろう。UEはMSASにステータス情報メッセージを定期的に送信することができる。その結果、初期の同期の後に発生し得る同期欠如の経過を追うことができる。しかしながら、一旦、宛先間同期がある時点において実現され、及び、ネットワーク遅延がむしろ変動しない結果、メディア配信が実質的に同期を維持されたときには、更なる設定指示は必要でなくなる。何故ならば遅延の変更をなくすのはBCSにより行われる必要があるからである。したがって、ネットワーク内にMSCを配置することによってステータス情報メッセージの数を減らすことは、宛先間同期に関わるメッセージについてのより大きな部分の減少を提供できる。図10の同期方式と関連した第2の利点は、それが同期サーバMSASによって実行される処理量を削減するということである。MSASは、関連のある遅延設定指示を算出できるようにするために、特定の宛先間同期グループについての全ての同期ステータス情報メッセージを処理する必要があろう。より少数のステータス情報メッセージにより、算出はより複雑でなくなり、及び更に必要な処理はより少なくなるだろう。図11は、本願を他の同期タイプについてコンテキストで示したものである。宛先間同期の目的のために同期クライアントをBSC及びMSCに分割する代わりに、図11では、ストリーム間同期即ち、リップシンクの適用を示している。図11は、メディアストリームの配信に関するケースを例示する。当該メディアストリームは、他の供給元からの追加のメディアストリームによって強化される。このような追加のメディアストリームの例示では、異なるオーディオストリーム、例えばスポーツの試合の放送における異なる解説者、としてもよい。この異なるオーディオストリームは異なる供給元で発生し、次いで、オリジナルのゲームをブロードキャストすることができるので、ストリーム間同期は別個に調整されなければならない。この特定の状況において、ストリーム間同期は宛先間同期と同様の課題が懸念される。例えば、このオーディオは、オリジナルの放送に応答して作成することができる。このことは、オリジナルの放送を閲覧している人が、代替のオーディオストリームを受信する前に相当な秒数にわたりビデオストリームをバッファする必要があることを、意味する。更には、その機器は、再生機器が短い時間期間のみにわたり例えば、100ミリ秒のオーダーでジッタバッファするように通常構成されるように、延長された時間期間にわたりバッファするように構成しなくてもよい。別の課題は、この場合にはまた、チャネルが変更する遅延を非常に長くできるということにも関する。チャネル変更の後に代替のオーディオストリームがビデオのタイミングと一致して利用可能となる前に、ビデオが数秒間バッファされる必要があるという状況は、チャネル変更遅延を利用可能でないものにする。そのような状況において、ネットワーク内のMSC/BSCの複合を備える同期クライアントの使用は、適切な同期機能を提供しないだろう。このことは、MPEGのような現在のビデオエンコード方式が異なるタイプのフレーム例えばI―フレーム、B―フレーム及びPフレームを使用するので、通常は、ビデオがオーディオよりも長い時間期間にわたりバッファリングを必要とするという事実に起因する。このようなビデオエンコード方式が双方向のエンコード方法に適用される場合には、エンコードするのに特定のフレームが初期フレーム、いくらかは将来のフレーム及びいくらかはその両方に依存することもある。したがって、多くのフレームが特定フレームを出コードするために必要とされ、バッファする必要があるこれらのフレームは、それらのフレームをデコードしないうちに開始することができる。したがって、これらの問題を解決するために、同期化方式が必要となり、そこでは、BSC及びMSCは、1又はそれ以上のメディア供給元及びUEの間のメディア経路に沿った別々の場所に位置する。図11は、1又はそれ以上のメディアストリームに関連付けられたメディアユニット到達時間情報についてレポートするために、MSC1106を有するUE1104を備えるホーム環境1102を示す。このUEは、ディスプレイ1108及びオーディオ出力デバイス1110に接続することができる。このUEは、ビデオストリーム1112及び別個の関連するオーディオストリーム1114を受信する。ビデオ及びオーディオストリームの双方は、ビデオ及びオーディオストリームのメディア経路内のネットワークに位置しオーディオ及びビデオストリームをバッファするための別個のBSCバッファ1118、1120を備えるBSC1116を通過することができる。このBSCは、ネットワーク内のどこかに位置する2つの別個のメディア供給元1122、1124から、ビデオストリーム及びオーディオストリームを受信することができる。MSAS1126は、MSCからステータス情報レポート1128を受信し、このステータス設定レポートに基づいて同期設定指示1130を算出することができる。同期設定指示1130は、その後BSCに送信される。UEは、それ故、共に属するオーディオ及びビデオストリームの場合にはネットワーク内の異なるメディア供給元から発生することができる又はできない、2又はそれ以上の別個のメディアストリームを受信する。宛先間同期を実行するために、UEはIETFRFC3550に規定されたRTCP送信機レポートを受信することができる。これらRTCP送信機レポートは、メディア供給元からUEまで送信され、メディアパケットが送信されたより具体的には、サンプルされた時間と対応するRTPメディアストリームについてのRTPタイムスタンプとの間の関係を含むことができる。宛先間同期は、それ故、異なるストリームの異なるメディアパケットが送信されたより具体的には、サンプルされた時間をマッチングすることによって、及び異なるメディアストリームの対応するRTPタイムスタンプを実質的に探すことによって、達成することができる。MSASが遅延設定指示を算出することを可能にするために、それは、異なるストリーム間での相関時間を必要とする。ストリームが共に同一の供給元から送信されるか、又は関連したメディアパケットについて同一のサンプリング時間を使用して送信される場合には、通常のRTCP手順をなお適用する。その場合には、このMSASは、MSCによって送信された同期ステータス情報においてレポートされるタイムスタンプを相関させるために、RTCP送信機レポートに収容される情報を必要とする。タイムスタンプを相関されるためのこの情報は、さまざまな方法で、例えばMSASにRTCP送信機レポートをルーティングすることにより、取得することができる。例えば、このUEはMSASにこの送信機レポートを転送することができ、又は、このネットワークはこの送信機レポートのコピーをMSASに送信することができる。この情報を得るための他の方法は、RTCPメッセージのシグナリング経路内にネットワークのMSASを配置することによるものである。このことは、例えば、BSCを有するMSASを共に配置することによって達成できる。異なるメディアストリームが同一の供給元から発生するか、又は関連したメディアパケットについて同一のサンプリング時間を使用しない場合には、MSASはオーディオストリーム及びビデオストリームに関連付けられたステータス情報レポートのタイムスタンプ間の相関に関する情報をなおも必要とする。一実施形態において、相関情報は、例えば両方のストリームを呈示する何者か、及び遅延を手動で変えることができる何者かによって手動で供給し、同期を達成することができる。一旦同期が達成されると、手動で導かれた遅延をレポートし、MSASに送信することができる。別の実施例では、メディアパケットの供給元は、同期ステータス情報のタイムスタンプ間の相関について供給することができる。例えば、第2のメディアストリームが別の第1のメディアストリームに応答して作成される場合には、その第2メディアストリームの供給元は、第2メディアストリームのサンプリング時間と第2メディアストリームの供給元によって受信されるRTCP送信機レポートに収容される第1メディアストリームのそれとの間の相関についてレポートすることができる。このコンテキストでは、他の課題もまた発生する。オーディオ及びビデオストリームが別個のUEによって受信する場合には、これらのUEは、メディアパケット到達時間が各UEによってレポートされたことを認識していないので、ストリーム間同期を実行することができない。しかしながら、BSCがネットワーク内に位置する場合には、UEは双方ともMSCを備えることができ、到達時間についてBSCにレポートすることができる。次いで、BSCは、異なるUEを代表してストリーム間同期を達成するために、必要なバッファリングを実行することができる。図12は、本発明の一実施例による分散同期システムを備えるメディア配信ネットワークを示している。このような分散アーキテクチャの導入により、いくらか利点を供することができる。例えば、遅延差は、メディア配信のネットワーク経路のさまざまな部分で生じることもある。したがって、遅延の差の発生源に依存して、異なる場所での遅延を補償することは有利なものとなる。更に、メディア経路の下り方向のあらゆるUE又はネットワークノードが同期機能性を提供することができるかについては、前もって知られていない。ネットワーク内の異なるノードにおいて同期化機能を導入ことにより、最善の同期化は、異なるネットワークノードの所与の同期能力を達成することができる。更には、UE上の宛先間同期が最終的に達成できる場合であっても、チャネル変更時間は、メディアストリームがネットワーク内である程度同期される場合には、より低いものとなる。図12は、全てのUE1202―1208がメディアストリーム1210を受信している概要を示している。これらUEは、あるネットワークノード1212、1214、例えばネットワーク1216、1218のエッジノードに接続される。これらUEの各々は、同期ステータス情報1220、1222をMSAS1224、1226に送信する。これらMSASは、遅延設定指示1228、1230を算出することができ、これらをネットワークノード1212、1214に送信することができる。このことは、UEがローカルに同期されることを可能にする。異なるネットワークノード1212は、また、メディアストリーム1210を同期外で受信することもできる。MSC及びBSC機能性を含む完全な宛先間同期がUE上で実行される場合であっても、これらのネットワークノードを少なくとも同期させることはまた有利となり得る。ネットワークノード1212のうち1つが特定のメディアストリームについて他方のネットワークノードに対して1秒の遅れていると仮定する。ネットワークノードについての同期化がない場合、他の全てのネットワークノードの後方にあるあらゆるUEもが、宛先間同期を達成するために、この1秒にわたりバッファしなければならないだろう。これらのネットワークノード1212上の差をバッファリングすることで、これらのUEのチャネル変更時間はその1秒によって減らす。他の利点としては、UE1202、1204のいくつかが宛先間同期を実行することができない場合に、メディアストリーム1210をなおも受信するであろう。ネットワークノード1212は、同期ステータス情報1232を更なるMSAS1234に送信することができる。更なるMSAS1234は、更なる同期設定指示1236を算出し、BSCを収容するネットワークノード1238に送信することができる。メディア経路でのネットワークノードでのバッファリングの利点は、バッファメモリの総容量が削減されるということである。即ち、異なるネットワークノード1212は、ネットワークノード1238に収容されるバッファを共有することができる。加えて、メディアストリームのダウンストリーム経路上のあらゆるノードネットワークノード又はUEが、宛先間メディア同期についてバッファリングを実行することができない場合には、このメディアストリームはなおもある程度同期することができる。これら異なる宛先間同期は、異なるレベルで発生することができる。ネットワーク1212において、ネットワークノード1212は、ノード1238のネットワーク内で内部的に同期され、そして、ネットワーク1218において、ネットワークノード1214はネットワーク階層においてより高い、更に別のネットワークノード1240を用いることで同期される。より高いネットワーク階層では、ノードは、メディアストリームの経路ではより早いことを意味する。この例では、同期ステータス情報1242をMSAS1244に送信することによって、コアネットワークノード1238が同期される。このMSAS1244は、同期設定指示1246を算出し、BSCを備えるネットワークノード1240に送信することができる。このネットワークノード1240は、例えば、メディアストリームを異なるネットワーク及びネットワーク運用業者に届けるための配信ポイントでもよい。しかし、ネットワーク1218からは、エッジノード1214はまた、同期ステータス情報1248をMSAS1244に送信し、これによって、ネットワークノード1240内で同一のBSCを使用する。如何なる一つの実施形態に関して記載した如何なる特徴も、単独で、又は記載した他の特徴と組み合わせて使用することができ、また、如何なる他の実施形態の1又はそれ以上の特徴と組み合わせて使用することができ、又は、如何なる他の実施形態の如何なる組み合せで使用することができることを理解すべきである。本発明の一実施形態は、コンピュータシステム用のプログラム製品として実施することができる。このプログラム製品におけるプログラムは、実施形態本願明細書において説明した方法を含むの機能を定義して、また、様々なコンピュータ可読記憶媒体上に収容することができる。コンピュータ可読記憶媒体の例示は、以下を含むが、これに限定されるものではない。即ち、i情報が永続的に格納される非書込可能な記憶媒体例えば、CD―ROMドライブ、フラッシュメモリ、ROMチップ又は如何なるタイプのソリッドステート不揮発性半導体メモリによって読み取り可能なCD―ROMディスクのようなコンピュータ内のリードオンリーメモリデバイス、及びii変更可能な情報が格納される書込可能な記憶媒体例えば、ディスケットドライブ若しくはハードディスクドライブ内のフロッピー登録商標ディスク、又は如何なるタイプのソリッドステートランダムアクセス半導体メモリ、である。更に、本発明は、IMSに限定されず、ソフトスイッチ設計に基づいて実施することもできる。これにより、基本ユーザ加入機能、IPセッション管理及び特定のVoIPサービス機能が、完全に、又は部分的にネットワーク内の1又はそれ以上の信頼性のあるアプリケーションサーバ内で統合される。更に、3GPPのLongTermEvolutionLTE又は3GPPのServiceArchitectureEvolutionSAEのネットワークのような他のサービス提供ネットワークを用いて本発明の実施がまた予見される。更に、本発明は上記の実施形態に限定されなず、添付の特許請求の範囲の範囲内で変形することができる。"