"メディアストリームのメディア記述をクライアント500,1000に提供する方法であって、前記クライアント500,1000を、メディア記述配信規則を有するメディア記述配信サービスに加入させるステップ300と、メディア記述配信の要求をメディアサーバ520へ送信するステップ310と、前記メディアサーバ520からメディア記述を受信するステップ320と、前記受信したメディア記述が前記メディア記述配信規則に適合していることを検証するステップ340と、前記検証が肯定であった場合、前記クライアント500,1000に対する前記メディア記述の配信を開始するステップ350と、を備えることを特徴とする方法。前記クライアントを前記メディア記述配信サービスに加入させる前記ステップのための加入要求を受信するステップを備えることを特徴とする請求項1に記載の方法。前記加入要求は、前記クライアントのアドレスと、前記メディア記述配信サービスを示すものと、どのメディアを配信すべきかと、のうちの少なくとも1つを指定することを特徴とする請求項2に記載の方法。前記メディア記述の前記配信は、前記受信したメディア記述を前記クライアントへ送信することを含むことを特徴とする請求項1乃至3のいずれか1項に記載の方法。前記メディア記述の前記配信は、前記クライアントが前記メディアから前記メディア記述を取得できるようにする情報を前記クライアントへ送信することを含むことを特徴とする請求項1乃至4のいずれか1項に記載の方法。前記メディア記述配信規則は、少なくとも1つの事前定義されたコンテンツ要件を指定し、前記検証するステップにおいて、前記受信したメディア記述の内容が前記事前定義されたコンテンツ要件と比較されることを特徴とする請求項1乃至5のいずれか1項に記載の方法。前記メディア記述配信規則は、少なくとも2つのメディア記述の関係に関わり、前記検証するステップにおいて、前記受信したメディア記述は前記少なくとも2つのメディア記述のうちの1つであることを特徴とする請求項1乃至6のいずれか1項に記載の方法。別のメディア記述が受信され、前記別のメディア記述は、前記少なくとも2つのメディア記述のうちの2番目のものであることを特徴とする請求項7に記載の方法。前記別のメディア記述は、前記メディア記述と比べて時間的に早くに受信され、前記メディア記述配信規則は、前記メディア記述が前記別のメディア記述の更新である場合にのみ前記メディア記述が送信されるということを指定することを特徴とする請求項8に記載の方法。前記別のメディア記述は、メディア記述配信の別の要求を前記メディアサーバに対して送信したことに応えて受信されることを特徴とする請求項8又は9に記載の方法。前記クライアントへ送信される、前記メディア記述と、前記クライアントが前記メディア記述を取得できるようにする前記情報と、のうちの少なくとも一方は、第1のトランスポートプロトコルに従って通信され、前記メディアサーバへ送信されるメディア記述配信の前記要求と、前記メディアサーバから受信される前記メディア記述と、のうちの少なくとも一方は、第2のトランスポートプロトコルに従って通信されることを特徴とする請求項4乃至10のいずれか1項に記載の方法。メディア記述配信の前記別の要求と、前記メディアサーバから受信される前記別のメディア記述と、のうちの少なくとも一方は、前記第2のトランスポートプロトコルに従って通信されることを特徴とする請求項11に記載の方法。前記加入要求は、前記第1のトランスポートプロトコルに従って通信されることを特徴とする請求項3、11、又は12に記載の方法。前記第1のトランスポートプロトコルは、セッション開始プロトコルSIPであることを特徴とする請求項11乃至13のいずれか1項に記載の方法。前記第2のトランスポートプロトコルは、ハイパーテキストトランスファープロトコルHTTPであることを特徴とする請求項9乃至14のいずれか1項に記載の方法。メディアストリームのメディア記述をクライアント500,1000に提供する方法であって、前記クライアント500,1000をメディア記述配信サービスに加入させる加入要求をメディア記述配信管理デバイス510,910へ送信するステップ400と、前記メディア記述配信管理デバイス510,910から前記メディア記述を受信するステップ410と、を備えることを特徴とする方法。メディアストリームのメディア記述をクライアント500,1000に提供する方法であって、前記クライアント500,1000をメディア記述配信サービスに加入させる加入要求をメディア記述配信管理デバイス510,910へ送信するステップ400と、前記メディア記述配信管理デバイス510,910から、前記クライアント500,1000がメディアサーバ520から前記メディア記述を取得できるようにする情報を受信するステップ420と、前記受信した情報に従い、前記メディア記述を取得する要求を前記メディアサーバ520へ送信するステップ430と、前記メディアサーバ520から前記メディア記述を受信するステップ440と、を備えることを特徴とする方法。前記加入要求は、前記クライアントのアドレスと、前記メディア記述配信サービスを示すものと、どのメディアを配信すべきかと、のうちの少なくとも1つを指定することを特徴とする請求項16又は17に記載の方法。前記加入要求は、第1のトランスポートプロトコルに従って通信され、前記メディア記述を取得する前記要求と、前記メディアサーバから受信される前記メディア記述と、のうちの少なくとも一方は、第2のトランスポートプロトコルに従って通信されることを特徴とする請求項16乃至18のいずれか1項に記載の方法。前記第1のトランスポートプロトコルは、セッション開始プロトコルSIPであることを特徴とする請求項19に記載の方法。前記第2のトランスポートプロトコルは、ハイパーテキストトランスファープロトコルHTTPであることを特徴とする請求項20に記載の方法。請求項1乃至15のいずれか1項に記載の方法の各ステップを実行するように構成されたメディア記述配信管理デバイス510,910。少なくとも1つの受信ユニットRx91,Rx92と、少なくとも1つの送信ユニットTx91,Tx92と、処理ユニットP9と、を備えることを特徴とする請求項22に記載のメディア記述配信管理デバイス。請求項16乃至21のいずれか1項に記載の方法の各ステップを実行するように構成されたクライアントデバイス500,1000。少なくとも1つの受信ユニットRx101,Rx102と、少なくとも1つの送信ユニットTx101,Tx102と、処理ユニットP10と、を備えることを特徴とする請求項24に記載のクライアントデバイス。請求項22又は23に記載のメディア記述配信管理デバイス510,910と、請求項24又は25に記載のクライアントデバイス500,1000と、メディアサーバ520と、を備えることを特徴とするシステム。メディア記述配信管理デバイス510,910の処理ユニットP9にロード可能なコンピュータプログラムであって、前記処理ユニットによって処理されると、請求項1乃至15のいずれか1項に記載の方法の各ステップを実行するように構成されたコードを含むことを特徴とするコンピュータプログラム。クライアントデバイス500,1000の処理ユニットP10にロード可能なコンピュータプログラムであって、前記処理ユニットによって処理されると、請求項16乃至21のいずれか1項に記載の方法の各ステップを実行するように構成されたコードを含むことを特徴とするコンピュータプログラム。以下で、メディアストリームのメディア記述をクライアントに提供するための方法およびデバイスについて、より詳細に記述する。図3で分かるとおり、クライアントが、メディア記述配信規則を備えたメディア記述配信サービスに加入する300。メディア記述配信のための要求が、メディアサーバに送信され310、メディアサーバからメディア記述が受信される320。受信されたメディア記述がメディア記述配信規則に適合することが検証される340。検証が肯定されたイエス場合、クライアントに対するメディア記述の配信が開始される350。検証が肯定されなかったノー場合、メディア記述の配信は開始されないことがある360。図4の上の部分で分かるとおり、クライアントをメディア記述配信サービスに加入させるための加入要求が、メディア記述配信管理デバイスに送信される400。メディア記述配信管理デバイスから、メディア記述を受信することができる410。ステップ410の代わりに、図4の下の部分に示すように、クライアントがメディア記述をメディアサーバから取得できるようにする情報が、メディア記述配信管理デバイスから受信され420、受信された情報に従ってメディア記述を取得するための要求が、メディアサーバに送信され430、そして、メディア記述が、メディアサーバから受信されてもよい440。メディア記述は、背景技術のセクションにあるように定義され、メディアプレゼンテーション記述またはMPDとも表されてもよく、例えば、メディアストリームを記述してもよいメディアストリームは、さまざまな利用可能なメディアストリーム品質と、利用可能な品質のうちの少なくとも1つに従ってメディアストリームを取得する可能性という点で、複数の連続したストリーム要素を含んでいてもよい。さらにメディア記述は、クライアントにおけるメディアストリームの処理をサポートするための情報、例えば、フェッチされてクライアントで再生されることになるセグメントの選択肢、を含んでいてもよい。しかし、メディア記述の実施形態の中には、不完全だと思われるもの、例えば、メディアサーバにメディアセグメントを要求するのに必要なメディアリンクを含んでいないものもあるだろう。例えば、そのようなメディア記述は、空であるかまたは、開始時刻だけは定義しているが1つ以上のメディアリンクが欠けていることもありうる。そのような不完全なメディア記述を除外するため、クライアントが加入しているメディア記述配信サービスのメディア記述配信規則が設けられてもよい。例えば、データファイルが、メディアサーバからメディア記述として受信されてもよいが、例えば、所定のコンテンツ要件に適合しているメディアファイルだけがクライアントに配信されなければならないことを指定する、メディア記述配信規則に適合しないことが検証されてもよい。そのようなコンテンツ要件の一例は、少なくとも1つのメディアリンクが存在していなければならないという指定であってもよい。このような除外されたメディア記述は、クライアントに送信されないため、メッセージを減らすことになる。さらに、検証の中で、受信されたメディア記述が、以前に受信されたメディア記述と比べて更新であるかどうかを分析し、更新されていないメディア記述の送信を抑制して、それ以上のメッセージが通信経路上でクライアントに送信されることを減らしてもよい。典型的には、メディア記述配信サービスへの加入は、クライアントから受信した加入要求によって行われる。加入要求は、典型的には、メディア記述が配信されるクライアントのアドレスを配信の中で指定する。また、加入要求は、メディア記述配信サービスを示すものインジケーションを含んでいてもよく、メディア記述配信規則の明示的な指定を伴っていてもよいし、伴っていなくてもよい。例えば、規則は、サービスに加入する時に暗示的に設定されてもよいし、クライアントによって入力または調整されてメディア記述配信管理デバイスに実装されてもよく、すなわち、規則は、メディア配信サービスのクライアントおよび/またはサービスプロバイダによって設定されてよい。さらに、加入要求は、どのメディア記述またはどのメディア記述の集合が配信されることになるのかを指定してもよい。しかし、メディアサーバがメディア記述を取得できるようにするため、メディア記述配信管理デバイスは、メディアサーバに送信されるメディア記述要求の中に含めるメディア記述識別子を判定するように構成されてもよい。その代わりに、または、それに加えて、メディア記述配信管理デバイスは、クライアント識別子をメディアサーバに送信してもよく、メディアサーバは、メディア記述をクライアント毎に、例えば、1つのメディア記述をクライアント毎および時間単位毎に管理してもよい。所与のクライアントについて、要求された時刻になると、対応するメディア記述が、メディアサーバからメディア記述配信管理デバイスに送信される。例えば、SIPSubscribeメッセージは、クライアントのアドレスをfromヘッダの中に含んでいてもよい。さらに、SIPSubscribeメッセージは、MPD更新だけがクライアントデバイスに配信されなければならないというメディア記述配信規則を含んだメディア記述配信サービスの一例として、例えばMPD更新のような、イベントの指定を含んでいてもよい。さらに、SIPINVITEのユーザ部分の中に、または別個のSIPメッセージの中に、配信されることになる少なくとも1つのMPDについての識別子が含まれていてもよい。このMPD識別子は、後でメディアサーバにMPDを要求するのに用いられるのと必ずしも同一ではない。受信されたMPD識別子に基づいて、メディア記述配信管理デバイスがメディアサーバを識別してもよい。その代わりに、またはそれに加えて、例えば、クライアント毎に、さらなるメディアサーバ識別メカニズムがあってもよいし、あるいは、メディア記述配信管理デバイス毎に、1つだけメディアサーバがあってもよいだろう。先に述べた識別子、サービスおよび規則の通信および処理の代わりに、またはそれらに加えて、これらが、オペレータによる維持管理を介して設定されたり管理されたりするように構成されてもよく、例えばクライアントが、そのように加入してもよい。図5に、クライアント500、MDmediadescription:メディア記述配信マネージャ510、およびメディアサーバ520を、各デバイス間で通信されるメッセージSR50、MDD51、MDD52、Q51-Q57、R51-R57、および、各デバイスで行われるプロセスS50、A51-A57と共に示す。任意オプションであるメッセージSR50、Q52-Q57については、点線で示す。クライアント500が、例えば、加入要求SR50の受信によってトリガされたMD配信マネージャ510において、メディア記述配信サービスに加入するS50。メディア記述のための要求Q51が、MD配信マネージャ510からメディアサーバ520に送信され、応答R51の中で、第1のメディア記述MD1が戻される。第1のメディア記述MD1が、メディア記述配信サービスのメディア記述配信規則を適用することによって分析されるA51。規則は、所定のメディア記述コンテンツ要件に適合する、最初に受信されたメディア記述が、クライアントに送信されなければならないということを指定してもよい。分析の中で、受信されたメディア記述MD1が、この規則に適合することが検証される。その結果、メディア記述MD1が、例えば、メディア記述MD1を含むメッセージMDD51をクライアントに送信することによって、クライアント500に配信される。続いて、MD配信マネージャ510は、メディア記述MD1を含んでいる別のメッセージR52-R54と、メディア記述MD1の更新であるメディア記述MD2を含んでいる別のメッセージR55-R57とを受信してもよい。別のメッセージR52-R57は、図のように別の要求Q52-Q57によってトリガされてもよいし、あるいは、プッシュサービスが、例えば、図のようにメディア記述を含んでいるメッセージR52-R57を定期的に送信するようにメディアサーバ520をトリガしてもよい。本実施形態によれば、分析プロセスA52-A57において適用されることになるメディア記述配信サービスのメディア記述配信規則は、2つのメディア記述の関係に関わり、後で受信された各メディア記述と、それに対応する、前に受信されたメディア記述とを比較すること、例えば、メッセージR52を介して受信されたMD1と、メッセージR51を介して受信されたMD1とを比較すること、などによって、後で受信された各メディア記述が分析されるA52-A57ということを指定する規則を伴う。後で受信されたメディア記述が、前に受信されたメディア記述の更新として検証されなかった場合、後で受信されたメディア記述は、クライアント500に送信されないであろうそれは、更新の場合に、更新は送信されるであろうと指定することと同等の定義であり、すなわち、後で受信されたメディア記述が、前に受信されたメディア記述の更新として検証された場合、後で受信されたメディア記述は、クライアント500に送信される。現在の例によれば、メッセージR52-R54はそれぞれ、第1のメディア記述を含んでおり、分析A52-A54の結果としてどのメディア記述もクライアントに送信されない。メッセージR55は、第1のメディア記述MD1の更新である第2のメディア記述MD2を含んでいる。更新のメディア記述配信規則を、メッセージR54を介して、および、メッセージR55を介して受信されたメディア記述に適用すると、後で受信されたメディア記述は変更された、すなわち、これは第1のメディア記述MD1の更新であるということが判定される。その結果、後で受信されたメディア記述MD2は、例えばメッセージMDD52を介して、クライアント500に配信される。以下のメッセージR56およびR57はそれぞれ、前に受信されたメディア記述MD2を含んでいるため、それらはいずれも、R55を介して最初に受信されたMD2の更新ではないことが、プロセスA56およびA57においてそれぞれ認識される。それゆえ、メッセージR56およびR57を介して受信されたメディア記述MD2は、クライアント500に配信されない。図6は、本発明の第2の実施形態による別のシグナリング図である。図6は、メッセージR51を介して受信された第1のメディア記述MD1’が、例えば、メディア記述が、空であるか、またはリンクが不足しているか、または事前に定義されたコンテンツ要件からそれ以外のかたちで逸脱しているため、事前に定義されたメディア記述コンテンツ要件に適合しないと判定されるという点で図5と異なる。その結果、第1の分析A51の後、第1のメディア記述MD’は、クライアント500に送信されない。メッセージR51に続いてメッセージR52-R54を介して受信されたすべてのメディア記述は、事前に定義された要件に適合することもなく、更新となることもなく、すなわち、メディア記述MD1’の配信は、事前に定義されたコンテンツ要件に基づくメディア記述配信規則によって、および/または、先に受信されたメディア記述と後で受信されたメディア記述との比較に基づく更新の検証に基づくメディア記述配信規則によって、抑制することができる。メッセージR55を介して受信されたメディア記述MD2は、両方の規則に適合しており、従ってクライアント500に配信される。本発明はさらに、IMS制御のインフラストラクチャにおけるMPD配信のための手順において、特に、MPD更新をクライアントに提供するために実施されてもよい。HTTPサーバに対するMPD更新のための頻繁な定期的なポーリング要求が、HTTP/SIPアダプタによって行われてもよい。そのようにして、HTTP/SIPアダプタは、常に現行のMPDに追いついた状態である。次いでUEは、MPDUpdateイベントについてのセッションの開始時にHTTP/SIPアダプタに対して加入することができる。その後、HTTP/SIPアダプタは、MPDが更新されるとすぐにUEに通知することができる。通知メッセージは、更新されたMPDと、更新されたMPDをフェッチするためのMPDURIとのいずれか一方を含んでいてもよい。IMS制御のインフラストラクチャにおいてメッセージフローの中に含まれる要素には、例えばクライアントの一例として移動電話などのUEユーザ装置と、IMCNサブシステムIPMultimediaCoreNetworkと、SCFSessionControlFunctionと、プロトコル変換機能性を持つメディア配信サーバをホストするデバイスの一例としてあるいは、別の言い方をすれば、プロトコル変換機能性を持つメディア記述配信管理デバイスの一例としてHTTP/SIPアダプタと、メディアサーバの一例としてHTTPサーバとがある。IMCNサブシステムおよびSCFは、標準的なIMSコンポーネントであってもよく、通常、本発明を実装する場合には、影響を受けない。本発明の中で記述する諸特徴から恩恵を得るには、UEは、好ましくは、本明細書で説明した諸特徴を実装しなければならない。さらに、HTTP/SIPアダプタおよび少なくとも1つのHTTPサーバは、典型的には、本明細書に記述した方法を実装する場合に拡張されてもよい。例えば、MPDおよびさまざまなメディア品質が、さまざまなサーバを介して分散される場合、2つ以上のHTTPサーバが用いられてもよい。さらに、単純なHTTPサーバの代わりに、CDNContentDistributionNetwork全体が用いられてもよい。しかし、これらの分散型の実施形態は、スタンドアロンデバイスであってもよいし、あるいは、接続可能な複数のデバイスの集合、すなわちシステムであってもよいが、いずれも、メディアサーバという用語で呼ばれうる。従って、HTTP/SIPアダプタおよびHTTPサーバは、同一のハードウェア上の、あるいは単一のソフトウェアの中の、コンポーネントとして実装されてもよい。この場合、2つのコンポーネントの間のインタフェースは、異なる可能性があり、すなわち、HTTPベースでない可能性があるその場合、SIP/HTTPアダプタの文字通りの意味は、このSIP/HTTPアダプタとHTTPサーバとの間にはHTTPインタフェースが存在しないかもしれないので、誤解を招くかもしれない。これらの2つのデバイスの間の非HTTPインタフェースの一例は、例えば、APIApplicationProgrammingInterfaceの呼び出しに基づいていてもよい。発明者らは、背景のセクションの中に記述され、図2に示したIMS制御のHTTPプログレッシブダウンロードは、MPDをUEにトランスポートする可能性を提供しうることを解明した。UEは、SIPINVITE図2のメッセージ1-3をHTTP/SIPサーバに送信することによってMPDの配信を要求してもよく、HTTP/SIPサーバは、今度はMPDをメッセージ4を介してHTTPサーバに要求する。HTTPサーバは、要求されたMPDを含むHTTPPOSTメッセージ5を返し、それは、その後、SIP200OKメッセージ6-8を介してUEに転送される。代替的なMPD配信として、MPDではなくMPDURIが、HTTPサーバからメッセージ5-8を介してUEに送信されてもよく、UEは、その後、MPDURIを含むHTTPGETメッセージ9をHTTPサーバに送信することによってMPDの配信を要求することができる。HTTPサーバは、所望のMPDを含むHTTPResponseによって応答してもよい。MPDを受信すると、UEは、HTTPサーバでDASHセッションを開始し、それに応じて、受信されたセグメントを処理することができる。DASHセッションの進行の過程で、MPDがHTTPサーバにおいて更新される可能性がある。新規のSIPINVITEはそれぞれ、新たなセッションを常に開始させるのだから、UEは、MPD更新についての情報を取得することを目的として、上記のパラグラフで説明した方法を繰り返し適用することはできない。しかし、すでに上記で説明したようにHTTPサーバとのHTTP-要求-応答を介してMPD更新を要求することは、前に記述したように、問題である。従って、発明者らは、特にMPD更新については、公知のIMS制御によるHTTPプログレッシブダウンロードは、以下の実施形態の中で示すとおり、本発明による大幅な修正なくしては、まだ適用できないことを解明した。次に、IMS制御によるDASHについて1つ以上のMPDをUEに提供するためのシグナルフローの一例を示す図7を参照しよう。セッションを開始するため、UEは、SIPINVITEステップ1-3をSIP/HTTPアダプタに送信する。SIP/HTTPアダプタとHTTPサーバとが、2つの別個のエンティティである場合、SIP/HTTPアダプタは、HTTP要求、例えば、POST要求またはGET要求を、最初のMPDに対するURLおよび/または最初のMPD自体を取得するために、HTTPサーバに発信するステップ45。HTTP応答ステップ5の一部として、HTTPサーバは、適切なポーリング間隔例えば10秒毎にポーリングするについての情報をSIP/HTTPアダプタに送信する。MPDURLまたはMPD自体を含むSIP200OKが、UEに送信されるステップ6-8。MPDが受信された場合、HTTPサーバからメディアセグメントをフェッチすることによって、DASHが直接起動されてもよいステップ8c。MPDURLが受信された場合、DASHセッションが起動されるステップ8c前に、MPDがHTTP要求/応答を介してフェッチされるステップ8a8b。ステップ8でSIP200OKメッセージを受信した後、UEは、SIPSUBSCRIBEをSIP/HTTPアダプタに向けて発信するステップ9-11。このメッセージと共に、UEは、イベントMPDUpdateに、すなわち、更新されたMPDだけがUEに提供されることになることを指定するメディア記述配信規則を備えたメディア記述配信サービスに加入する。ステップ12-14は、その加入を確認する、SIP/HTTPアダプタからUEへのSIP200OKメッセージを含んでいる。ここで、SIP/HTTPアダプタは、例えば10秒毎に、HTTPサーバに向かって、HTTP要求、例えばPOST要求またはGET要求を発信することによって、MPDの更新についてポーリングしている。HTTPサーバは、要求されたMPDを含むHTTP200OKを使って応答するステップ16。MPDに変化がない場合、ステップ1516が数回続けて行われる。HTTP要求の時間間隔は、事前に交渉されるSIP/HTTPアダプタとHTTPアダプタとの間のポーリング間隔によって、例えば10秒毎のように決められる。MPDが変更されたことをSIP/HTTPアダプタが認識した場合、SIPNOTIFYメッセージがUEに送信されるステップ17-19。SIPNOTIFYは、更新されたMPD自体と、更新されたMPDのURLとのいずれか一方を含んでいる。受信した後、UEは、SIP200OKをSIP/HTTPアダプタに発信するステップ20-22。更新されたMPDのURLが受信された場合、UEは、HTTPを介して更新されたMPDをフェッチするステップ22a22b。DASHセッションは、更新されたMPDの中のメディアセグメントを前述のようにフェッチすることによって継続される図示せず。図7では、SIPSubscribeメッセージ9-11が、DASHセッションの開始のだいぶ前にSIP/HTTPアダプタにも送信されてよい。これによって、クライアントが、一種のコンテンツ発行イベントに加入できるようになるであろう。最初は、MPDは空であるかまたは今後の開始時刻を示しているかもしれないが、MPDがメディアリンクを含むとすぐに、UEは、MPDまたはMPDのURLを含めてSIPNOTIFYメッセージを入手するであろう。この場合、SIPNOTIFYを受信した後、UEは、上述のようにプロセスを開始し、ステップ9は、すでに以前に実行されたのだから、中止することができる。図8に一例を示すが、すなわち、メッセージ11が受信された後、SIPinviteメッセージ図8には図示せずがHTTP/SIPアダプタに送信されてDASHセッションが開始され、メッセージ14aおよび14bを介して受信されることになるMPDが適用される連続的なメディア要素が受信されてもよい。メッセージ14aとSIPInviteメッセージとは、同時に送信されてもよいし、あるいは、その他の方法で時間的に相関されてもよく、それによってMPDとメディアストリームとが同時に受信されて同期し、こうしてUEにおけるMPDに基づくメディアストリーム処理が最適化される。別の実施形態によれば、HTTP/SIPアダプタは、図7のステップ4および5または15および16、あるいは、図8のステップ7および8の中で、その他のメカニズムまたは追加のメカニズムを利用してもよい。MPD変更のための更新の定期的なポーリングの代わりに、HTTP/SIPアダプタは、HTTPサーバによって提供される可能性があるプッシュメカニズムを利用してもよい。また、このプッシュサービスは、プッシュアグリゲータとして動作しうる別のノードまたはサービスによって提供される可能性もあるだろう。これによって、SIP/HTTPアダプタとUEとの間のリンクにかかる負荷だけでなく、SIP/HTTPアダプタとHTTPサーバとの間のそれも低減するであろう。このリンク上でプッシュを用いることは、MPD更新の頻度が分からない場合に、特に有利である。次に、メディア記述配信管理デバイス910およびクライアントデバイス1000の実施形態をそれぞれ示す図9および図10を参照しよう。典型的には、メディア記述配信管理デバイス910は、クライアントとは受信ユニットRx91および送信ユニットTx91を介して通信し、メディアサーバとは受信ユニットRx92および送信ユニットTx92を介して通信するようになっており、特に、クライアントとの通信が第1のトランスポートプロトコル例えばSIPに従って行われ、かつ、メディアサーバとの通信が第1のプロトコルとは異なる第2のトランスポートプロトコル例えばHTTPに従って行われる場合にそうである。しかし、クライアントおよびメディアサーバとの通信は同一のプロトコルを介して行われるけれども、別個の受信ユニットおよび送信ユニットを用いるような実装もあるかもしれない。あるいは、例えば、さまざまなトランスポートプロトコルに従って通信できる送信ユニットまたは受信ユニットの場合、単一の受信ユニットまたは単一の送信ユニットが、メディアサーバとクライアントデバイス1000とのどちらとも通信できるような実装もあるかもしれない。この場合、一組の受信ユニットおよび送信ユニットだけが、例えば受信ユニットRx91および送信ユニットTx91だけが、クライアントとの通信用だけでなくメディアサーバとの通信用にも用いられ、他方の組の受信ユニットと送信ユニットとは、その時の例によれば受信ユニットRx92および送信ユニットTx92であろうが、必要ないであろう。別個のユニットとして描かれているが、送信ユニットと受信ユニットとは、1つのトランシーバユニットとして実施されてもよい。メディア記述配信管理デバイス910の一実施形態によれば、処理ユニットP9は、クライアントをメディア記述配信サービスに加入させるように構成されてもよく、ここでは、このメディア記述配信サービスはメディア記述配信規則を含んでいる。送信ユニットTx92は、メディア記述配信のための要求をメディアサーバに送信するように構成されてもよい。受信ユニットRx92は、メディア記述をメディアサーバから受信するように構成されてもよい。処理ユニットP9は、受信されたメディア記述がメディア記述配信規則に適合することを検証するように構成されてもよい。処理ユニットP9は、検証が肯定されたと判定した場合、例えばメディア記述または、クライアントがメディア記述をメディアサーバから取得できるようにする情報を、送信ユニットTx91または送信ユニットTx92を介してクライアントに送信することによって、クライアントに対するメディア記述の配信を開始する。本方法の別のステップが、関係するユニットによって行われてもよく、例えば加入要求が受信ユニットRx91を介して受信されてもよいし、受信された別のメディア記述がストレージユニットS9の中に格納されてもよい。より早い時刻に受信された別のメディア記述が、メディア記述配信管理デバイス910のストレージユニットに格納されてもよい。後になってメディア記述が受信された時、その別のメディア記述をストレージユニットから検索することができる。両方のメディア記述は、メディア記述配信管理デバイス910の処理ユニットに入力され、メディア記述配信規則に従って、対応する検証が行われる。すなわち、後に受信されたメディア記述は先に受信された別のメディア記述の更新であるかどうかが検証され、後に受信されたメディア記述は更新であると判定された場合、クライアントへの配信が開始される。典型的には、クライアントデバイス1000は、受信ユニットRx101と送信ユニットTx101とを介して、例えば、メディア記述に加入サブスクライブしてこれをメディア記述配信管理デバイス910から受信するために、メディア記述配信管理デバイス910と通信する。メディアサーバとの通信が、同じ受信ユニットRx101および送信ユニットTx101を介して行われてもよいし、および/または、受信ユニットRx102および送信ユニットTx102を介して行われてもよい。後者の選択肢は、特に、メディア記述配信管理デバイス910との通信が第1のトランスポートプロトコルに従って行われ、かつ、メディアサーバとの通信が第2のトランスポートプロトコルに従って行われる場合に、適用可能である。しかし、メディア記述配信管理デバイス910およびメディアサーバとの通信は同一のプロトコルを介して行われるけれども、別個の受信ユニットおよび送信ユニットを用いるような実装もあるかもしれない。あるいは、例えば、さまざまなトランスポートプロトコルに従って通信できる送信ユニットまたは受信ユニットの場合、単一の受信ユニットまたは単一の送信ユニットが、メディアサーバとメディア記述配信管理デバイス910とのどちらとも通信できるような実装もあるかもしれない。この場合、一組の受信ユニットおよび送信ユニットだけが、例えば受信ユニットRx91および送信ユニットTx91だけが、メディアサーバとの通信用だけでなくメディア記述配信管理デバイスとの通信用にも用いられ、他方の組の受信ユニットと送信ユニットとは、その時の例によれば受信ユニットRx102および送信ユニットTx102であろうが、必要ないであろう。別個のユニットとして描かれているが、送信ユニットと受信ユニットとは、1つのトランシーバユニットとして実施されてもよい。クライアントデバイス1000の一実施形態によれば、送信ユニットTx101は、クライアントをメディア配信サービスに加入させるための加入要求をメディア記述配信管理デバイス910に送信するように構成されてもよい。受信ユニットRx101は、メディア記述をメディア記述配信管理デバイス910から受信するように構成されてもよい。前に記述した受信の代わりに、受信ユニットRx101は、クライアントがメディア記述をメディアサーバから取得できるようにする情報をメディア記述配信管理デバイス910から受信するように構成されてもよい。送信ユニットTx101またはTx102は、受信された情報に従ってメディア記述を取得するための要求をメディアサーバに送信するように構成されてもよいし、受信ユニットRx101またはRx102は、メディア記述をメディアサーバから受信するように構成されてもよい。本方法の別のステップが、関係するユニットによって行われてもよく、例えば、受信されたメディア記述がストレージユニットS10の中に格納されてもよい。メディアサーバおよびメディア記述配信管理デバイス910と通信するのに、異なるトランスポートプロトコルが用いられる場合、クライアントがメディア記述を取得できるようにするために受信された情報は、処理ユニットP10によって第1のトランスポートプロトコルによる1つのフォーマットから第2のプロトコルによるもう1つのフォーマットへと変換されてもよい。別のプロトコル変換プロセスが、処理ユニットP10によって行われてもよい。本発明は、特にクライアントとメディアサーバとの間の、シグナリングのオーバヘッドの大幅な減少を実現する。本発明はさらに、メディア記述更新の場合にクライアントへの迅速な通知を実現すると共に、更新されたコンテンツと、および/または、メディアサーバに関する更新された品質と、および/または、例えば、更新されたMPDがより高品質でのメディア表現を指示する場合にIMCNサブシステムにおいてより高速の送信ビットレートのベアラを予約するための、電気通信システムの別のコンポーネントという点に関して、更新されたメディアストリームを要求するためのクライアントによる反応の迅速化をも実現する。"