説明

動的なRTCPリレー

1つ以上のRTPストリームに関連づけられたRTCPメッセージを動的にリレーする方法およびシステムが記載される。各RTPストリームはメディアセッションに関連づけられ、送信器ノード(MF)および1つ以上の受信器ノード(UE)に関連づけられる。方法は以下のステップを含む。少なくとも1つの制御ノード(MSAS)を少なくとも1つのRTPストリームに割り当てるステップ。前記RTPストリームに関連づけられた受信器ノードに前記制御ノードのアドレスを提供するステップ(4)であって、セッション制御プロトコルメッセージまたはHTTPメッセージにおいて前記アドレスが前記受信器ノードに提供され、前記アドレスが、関連づけられた送信器ノードのアドレスとは異なるステップ。および、前記セッション制御プロトコルメッセージまたはHTTPメッセージに含まれる前記アドレスを用いて、前記受信器ノードが前記制御ノードに受信器RTCPメッセージを送信するステップ(8)。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ネットワークにおいてRTCPメッセージを動的にリレーすることに関し、排他的にではないが、ネットワークにおいてRTCPメッセージを動的にリレーするための方法およびシステム、そのようなシステムにおいて使用するネットワーク要素およびユーザ機器、および該方法を実行するコンピュータプログラム製品に関する。
【背景技術】
【0002】
現在では、リアルタイムトランスポート(RTP)プロトコルが、1つ以上の受信器にIPベースのネットワークを介してマルチメディアデータをストリーミングするために、および、関連するRTPコントロールプロトコル(RTCP)が、メディアストリームに関する制御および管理情報を提供したりするために、それぞれ広く用いられる。RTCPプロトコルは、様々な異なる方法のために用いられることが可能な、柔軟なプロトコルである。RTCPプロトコルは、複数のソースメディアストリームの間の同期、例えば映像および音声のストリームの間のリップシンクを、単一の送信先によって可能にする機構の中核となっている。代替として、RTCPプロトコルは、サービスの質またはネットワーク全体を監視するために用いられる。RTCPフィードバックに基づいて、オペレータは適切な方策をとってネットワークの機能を向上させることができる。オペレータは、RTCPメッセージによって提供された情報に基づいて、例えば、コード化すべきメディアソースを指示することによって、あるルート上のネットワーク輻輳を解消し、より少ない帯域消費でメディアストリームを送信することができる。
【0003】
例えば、IPマルチメディアサブシステム(IMS)アーキテクチャは、セッション開始プロトコル(SIP)の柔軟性によって可能となる広範囲のサービスをサポートする統一されたアーキテクチャであるが、トランスポートプロトコルとしてRTPを用いる。IMSはある3GPPおよび3GPP2標準(例えば3GPP TS 22.228、TS 23.218、TS 23.228、TS 24.228、TS 24.229、TS 29.228、TS 29.229、TS 29.328、およびTS 23.320 リリース5〜7など)によって定義される。IPTVのためにIMSを用いることは、あるETSI仕様(例えばETSI TS 182 027およびETSI TS 183 063など)によって定義される。ひとたびセッションがセッション開始プロトコル(SIP)を用いることを確立すると、リアルタイムトランスポート(RTP)プロトコルが、メディアソースまたは送信器から受信器へとマルチメディアをストリーミングするために用いられ、選択として、リップシンクおよびサービスの質の情報のためにメディア送信器と受信器の間でRTCPプロトコルを用いる。同様に、TS 183 064に記載されるようなIPTVアーキテクチャに統合された次世代ネットワーク(NGN)は、HTTPを用いてRTPメディアセッションをセットアップする。
【0004】
いくつかの用途、例えば送信先(グループ)間の同期、選択的な監視およびコンテンツ適合などのために、RTCPメッセージ経路において個々のアクティブな要素を有することが有利でありうる。例えば特許文献1は、RTCP制御メッセージをインターセプトし、送信器と受信器の間で送信されたデータの品質を測定するためのプロキシサーバを記載している。さらに、特許文献2は、メディア送信器と受信器の間でRTCPメッセージを監視し、RTCP制御メッセージをインターセプトおよび修正してそれらの修正された制御メッセージをさらに受信器に転送することが可能な、中間メディアプロセッサを記載している。
【0005】
ネットワークにおけるそのような知られているアクティブな要素の実施に関する1つの問題は、それらの要素がまずRTCPメッセージを受信して、RTCPメッセージから情報を引き出すことを可能にする必要があるということに関する。従来技術による解決法は様々な方法でこれらの問題に対処する。
【0006】
1つの解決法は、ネットワークノード内にアクティブな要素を配置し、すべてのRTCPメッセージ、および場合によってはすべてのRTPメディアパケットがそこを通過し、アクティブな要素にそれらのRTCPパケットをインターセプトおよび検査するように指示して、RTCPパケットから有用な情報を引き出すことである。この解決法は、アクティブな要素の使用をネットワーク内のある位置にのみ静的に制限することである。さらに、それらのタイプの状況においては、通常はわずかな量のRTCPトラフィックのみが監視されるので、そのような解決法は、ネットワークリソースを使用する効率的な方法を提供しない。最後に、サードパーティに制御されるアクティブな要素が、そのネットワーク上のRTCPトラフィックの全部または少なくとも一部をインターセプトおよび検査することを、オペレータが可能にしそうにないため、そのような解決法は、それらのアクティブな要素を使用する可能性を、サードパーティによって制御されるサードパーティのサービスに限定する。
【0007】
それらのアクティブな要素をネットワーク内で使用するための他の解決法は、構成前の(preconfigured)メディア送信器、メディア受信器およびアクティブな要素を用いて、アクティブな要素を介したRTCPメッセージ経路をリレーすることである。構成前であることは上記の欠点のいくつかを軽減することができるが、かなり静的であるという欠点を有する。ある方法でひとたび送信器、受信器およびアクティブな要素が、RTCPメッセージをリレーするように構成前になると、ネットワークがその状況に拘束される。それは、オペレータが、異なるRTCPに基づくサービスのための異なるアクティブな要素を柔軟に選択することを可能にしない。また、例えばアクティブな要素が不調であるか更新を要する場合、1つのアクティブな要素を他の要素に素早く変更することを可能にしない。同様に、アクティブな要素がサードパーティによって管理されて制御される場合、構成前を用いる解決法は非常に柔軟性がない。
【0008】
より一般的には、現在の世界的IPネットワーク環境においては、多くの新しいメディア送信器が毎日毎秒ネットワークに接続される。したがって、受信器、送信器およびアクティブな要素内の静的な構成を適合させることによってこれらのメディア送信元についていき、適切なアクティブな要素を介してメディアの適切な送信器または受信器からRTCPメッセージをリレーすることはほとんど不可能である。
【0009】
したがって、従来技術に対して、RTCPメッセージをリレーする際に一層の柔軟性を提供する方法およびシステムの要求がある。
【先行技術文献】
【特許文献】
【0010】
【特許文献1】米国特許公開第2008/0320132号明細書
【特許文献2】国際公開第2009/070202号
【発明の概要】
【発明が解決しようとする課題】
【0011】
本発明の目的は、従来技術で知られている欠点の少なくとも1つを減少または消滅させ、本発明の第一の形態において、1つ以上のRTPストリームに関連づけられたRTCPメッセージを動的にリレーする方法を提供することである。ここで各RTPストリームはメディアセッションに関連し、送信器ノードおよび1つ以上の受信器ノードに関連する。本方法は以下のステップを含む。少なくとも1つの制御ノードを少なくとも1つのRTPストリームに割り当てるステップ。前記RTPストリームに関連づけられた受信器ノードに前記制御ノードのアドレスを提供するステップであって、セッション制御プロトコルメッセージまたはHTTPメッセージにおいて前記アドレスが前記受信器ノードに提供され、前記アドレスが、関連づけられた送信器ノードのアドレスとは異なるステップ。および、前記セッション制御プロトコルメッセージまたはHTTPメッセージに含まれる前記アドレスを用いて、前記受信器ノードが前記制御ノードに受信器RTCPメッセージを送信するステップ。したがって、セッション制御プロトコルメッセージまたはHTTPメッセージをUEと、制御ノード、例えばIMS IPTVシステム内のIPTC SCFまたはNGN集積IPTVシステム内のCFIAと、の間で交換することによって、リレー情報、例えばアクティブなネットワーク要素のアドレスおよび同期セッションIDなどのセッション識別子が、メディアセッションに含まれるネットワーク要素、例えばUE、メディア送信器およびさらなるネットワーク要素、に提供されることができ、それによってメディア制御メッセージ、例えばRTCPメッセージが、さらなるネットワーク要素を介してリレーされることを可能とし、該さらなるネットワーク要素は、メディア同期アプリケーションサーバ(MSAS)、(サード)パーティメディアセッションモニタ、セッション境界コントローラなどのアプリケーションサーバであってもよい。
【0012】
(SIPの場合と同様に)セッション制御プロトコルメッセージを用いるセッション制御状態装置の実施および維持を原則として必要としないため、実施が簡単であるという利点を、HTTPは提供する。さらに、HTTPは多くの方法(例えばURI、SDP、XMLなど)の搬送パラメータを許容し、同期グループ(Sync Group)などのセッショングループを生成および削除するために用いられてもよい。
【0013】
一実施形態では、前記方法は以下のステップをさらに含む。前記RTPストリームと関連づけられたグループ同期識別子を前記受信器ノードに提供するステップ、および、受信器RTCPメッセージ内の前記グループ同期識別子を前記制御ノードに送信するステップ。
【0014】
さらなる一実施形態では、方法は以下のステップをさらに含む。前記受信器ノードが同期ステータス情報を生成するステップ。送信器RTCPメッセージ内の前記同期ステータス情報を前記制御ノードに送信するステップであって、前記制御ノードが、前記送信器RTCPメッセージと関連づけられたRTPストリームを、前記制御ノードに割り当てられた1つ以上の他のRTPストリームと同期させる同期機能を有する、ステップ。
【0015】
さらに別の一実施形態では、前記方法は以下のステップをさらに含む。前記同期機能が前記同期ステータス情報を用いて同期設定情報を計算するステップ。前記制御ノードが前記受信器ノードに前記同期設定情報を送信するステップ。前記受信器ノードが前記同期設定情報を用いて前記受信器ノードに関連づけられた遅延バッファに指示するステップ。
【0016】
一実施形態では、方法は以下のステップをさらに含む。前記RTPストリームに関連づけられた前記送信器ノードに、前記制御ノードのアドレスを提供するステップであって、前記アドレスはセッション制御プロトコルメッセージまたはHTTPメッセージ内の前記送信器ノードに提供される、ステップ。前記送信器ノードが前記制御ノードに送信器RTCPメッセージを送信するステップであって、前記セッション制御プロトコルメッセージ内に含まれる前記アドレスを使用する、ステップ。
【0017】
別の実施形態では、前記方法は以下のステップをさらに含む。制御ノードが1つ以上の受信器RTCPメッセージおよび1つ以上の送信器RTCPメッセージを受信し、前記受信器RTCPメッセージ内および前記送信器RTCPメッセージ内のRTPセッション識別子、好ましくはSSRCが同一である場合、受信器RTCPメッセージを送信器RTCPに関連づけるステップ。関連づけられた送信器RTCPメッセージが発信されるアドレスに、制御ノードが受信器RTCPメッセージを送信する、および/または、関連づけられた受信器RTCPメッセージが発信されるアドレスに、制御ノードが送信器RTCPメッセージを送信するステップ。
【0018】
一変形例では、前記受信器RTCPメッセージの少なくとも1つが同期ステータス情報を含み、前記方法はさらに以下のステップを含む。前記受信器RTCPメッセージから前記同期ステータス情報を取り除くステップ。前記受信器制御メッセージを前記関連づけられた送信器ノードに送信するステップ。
【0019】
さらなる変形例では、前記方法はさらに以下のステップを含む。前記同期機能が同期設定情報を提供するステップ。および、前記受信器ノードに送信器RTCPメッセージ内の前記同期設定情報を送信するステップ。
【0020】
さらなる変形例では、方法はさらに以下のステップを含む。少なくとも1つの送信器ノードが、前記RTPストリームの少なくとも1つおよび関連づけられた送信器RTCPメッセージを、1つ以上の受信器ノードにマルチキャストするステップ。
【0021】
さらなる実施形態では、方法はさらに以下のステップを含む。受信器ノードが前記RTCPメッセージの少なくとも1つを前記制御ノードに送信するステップ。
【0022】
一実施形態では、方法は以下のステップを含む。前記マルチキャストに関連づけられたメンバグループに制御ノードを参加させる要求を送信する、または、前記制御ノードに送信器RTCPメッセージを提供するために送信器ノードと制御ノードの間のユニキャスト接続を提供するステップ。
【0023】
別の実施形態では、方法は以下のステップを含む。制御ノードが、1つ以上の受信器RTCPメッセージおよび1つ以上の送信器RTCPメッセージを受信し、前記受信器RTCPメッセージ内および前記送信器RTCPメッセージ内のRTPセッション識別子、好ましくはSSRCが同一である場合、受信器RTCPメッセージと送信器RTCPを関連づけるステップ。関連づけられた送信器RTCPメッセージが発信されるアドレスに、制御ノードが受信器RTCPメッセージを送信する、および/または、関連づけられた受信器RTCPメッセージが発信されるアドレスに、制御ノードが送信器RTCPメッセージを送信するステップ。
【0024】
さらに別の実施形態では、前記セッション記述プロトコルはSIPプロトコルまたはRTSPプロトコルである。さらなる変形例では、前記制御ノードは受信器ノードのグループを同期させる同期サーバである。または、前記制御ノードは、前記制御メッセージ内の情報、特にサービスの質、データトラフィック情報、および/またはデータ管理情報を監視するための、および/または、1つ以上の所定の規則に基づいて前記制御メッセージ内の情報を修正するための、1つ以上の機能を有する。
【0025】
別の態様では、本発明はRTCPメッセージを動的にリレーするシステムに関し、システムは、1つ以上の受信器ノードによって生成された1つ以上の受信器RTCPメッセージ、および/または1つ以上の送信器ノードによって生成された送信器RTCPメッセージを受信する制御ノードと、前記制御ノードに関連づけられたリレー制御機能であって、前記制御機能が、前記RTPストリームに関連づけられた受信器ノードおよび/または送信器ノードに前記制御ノードのアドレスを提供するように構成され、前記アドレスはセッション制御プロトコルメッセージにおいて前記受信器ノードおよび/または送信器ノードに提供された、リレー制御機能と、前記セッション制御プロトコルメッセージ内に含まれる前記アドレスを用いて、前記制御ノードにRTCPメッセージを送信するように構成された少なくとも1つの受信器ノードと、を有する。
【0026】
一変形例では、システムは、前記セッション制御プロトコルメッセージまたはHTTPメッセージ内に含まれる前記アドレスを用いて、前記制御ノードにRTCPメッセージを送信するように構成された少なくとも1つの送信器ノードを含み、前記制御ノードがさらに、1つ以上の受信器ノードから発信される受信器RTCPメッセージおよび/または1つ以上の送信器ノードから発信される送信器RTCPメッセージを受信する少なくとも1つの入力と、前記受信器RTCPメッセージ内および前記送信器RTCPメッセージ内のRTPセッション識別子、好ましくはSSRCが同一である場合、送信器RTCPに受信器RTCPメッセージを関連づけるマッピング機能と、関連づけられた送信器RTCPメッセージが発信されるアドレスに受信器RTCPメッセージを送信する、および/または、関連づけられた受信器RTCPメッセージが発信されるアドレスに送信器RTCPメッセージを送信する、少なくとも1つの出力と、を有する。
【0027】
さらなる変形例では、前記受信器ノードは前記受信器RTCPメッセージ内の同期ステータス情報を挿入するように構成される。
【0028】
一変形例のシステムでは、前記システムはさらに、前記制御ノードに関連づけられた同期機能を含み、前記機能は、1つ以上の受信器ノードによって前記制御ノードに送信された1つ以上の受信器RTCPメッセージ内の同期ステータス情報を受信し、前記同期ステータス情報に基づいて、前記1つ以上の受信器ノードに関する同期設定情報を算出するように構成され、前記同期設定情報は、1つ以上の受信器ノードが、少なくとも1つのRTPストリームを時間遅延させることを可能にする。
【0029】
別の態様において、本発明は上記のようなシステムにおいて使用する受信器ノードに関し、受信器ノードは、制御ノードのアドレスを含むセッション制御プロトコルメッセージまたはHTTPメッセージを受信し、前記セッション制御プロトコルメッセージ内に含まれる前記アドレスを用いて、前記受信器ノードによって生成された受信器RTCPメッセージを前記制御ノードに送信するように構成され、リレークライアントと、同期ステータス情報を生成し、前記同期ステータス情報を受信器RTCPメッセージ内に挿入し、前記受信器RTCPメッセージを前記制御ノードに送信するように構成された同期クライアントと、を有する。
【0030】
本発明はまた、上記のようなシステムにおいて使用する制御ノードに関し、制御ノードは、1つ以上の受信器ノードから発信される受信器RTCPメッセージおよび/または1つ以上の送信器ノードから発信される送信器RTCPメッセージを受信する少なくとも1つの入力と、前記受信器RTCPメッセージ内および前記送信器RTCPメッセージ内のRTPセッション識別子、好ましくはSSRCが同一である場合、受信器RTCPメッセージを送信器RTCPに関連づけるマッピング機能と、関連づけられた送信器RTCPメッセージが発信されるアドレスに受信器RTCPメッセージを送信する、および/または、関連づけられた受信器RTCPメッセージが発信されるアドレスに送信器RTCPメッセージを送信する、少なくとも1つの出力と、所望により、1つ以上の受信器RTCPメッセージ内の1つ以上の受信器ノードによって前記制御ノードに送信された同期ステータス情報を受信し、前記同期ステータス情報に基づいて、前記1つ以上の受信器ノードに関する同期設定情報を算出するように構成された同期機能と、を有し、前記同期設定情報は、1つ以上の受信器ノードが、少なくとも1つのRTPストリームを時間遅延させることを可能にする。
【0031】
本発明はさらに、1つ以上のネットワークノードのメモリ内で実行された場合に上記の方法ステップを実行するように構成されたソフトウェアコード部分を含む、コンピュータプログラム製品に関する。
【0032】
本発明は添付の図面を参照してさらに記載され、該図面は本発明による実施形態を概略的に示す。本発明はこれらの特定の実施形態に何ら制限されるものではないことが理解される。
【図面の簡単な説明】
【0033】
【図1】本発明の一実施形態によるシステムを示す図である。
【図2】本発明の一実施形態による方法のメッセージフロー図である。
【図3】本発明の一実施形態による方法の代替のメッセージフロー図である。
【図4】本発明の一態様によるRTCP XRリポートブロックの可能な定義を示す図である。
【図5】本発明のさらなる実施形態によるRTCP XRリポートブロックに関する可能な定義を示す図である。
【図6】本発明のさらなる実施形態による別のメッセージフロー図である。
【図7】IPマルチキャストシナリオにおける本発明による一実施形態のためのメッセージフロー図である。
【図8】本発明のさらなる態様によるRTCP XRリポートブロックに関する可能な定義を示す図である。
【図9】本発明のさらなる実施形態による別のフロー図である。
【図10】本発明の一実施形態によるさらなるシステムの図である。
【図11】本発明の一実施形態によるメッセージフロー図である。
【図12】本発明のさらなる実施形態によるIPマルチキャストシナリオによるフロー図である。
【発明を実施するための形態】
【0034】
図1は、ETSI TISPAN TS 183 063およびTS 182 027によって定義されたIMSベースのIPTVシステム100の例を示す図である。システムは本発明の第1の実施形態によるRTCPメッセージを動的にリレーするように構成されている。システムは、セル/セッション制御機能(CSCF)、例えばプロキシCSCF(P−CSCF)、問い合わせCSCF(I−CSCF)、およびサービングSCSF(S−CSCF)のセットを構成するIMSコア107を含む。IMSコアはユーザ機器(UE)105、ネットワーク(例えばブロードキャストSCR、コンテンツオンデマンドSCFなど)内のIPTVサービスを制御するIPTVサービス制御機能(SCF)106、およびメディア機能(MF)101に接続される。メディア機能は、メディア制御機能(MCF)102およびメディア配信機能(MDF)103を含み、メディア配信機能はメディアコンテンツの配信を制御し、搬送機能(TF)104を介するユーザ機器へのパケットを制御する。
【0035】
TS182 027からのアーキテクチャは、送信先間同期機能を実行するように構成されたメディア同期アプリケーションサーバ(MSAS)108によって拡張される。送信先間メディア同期とは、あるメディアが表示される時刻がそのメディアの異なる送信先と同じである、すなわち、同じ映像の断片または音声サンプルが異なる送信先で同時に再生されることを意味する。ユーザ機器またはネットワークノードにおける同期活動は、同期クライアント(SC)109の位置においてバッファ110を用いて実施されてもよい。同期クライアントはMSASと相互作用して、受信されたメディアストリームを遅延させるようにバッファに指示することによってバッファの作用を連係させる。
【0036】
図1におけるIPTVシステムはセッション初期化プロトコル(SIP)を用いて、ユーザ端末間の、またはユーザ端末とSCFおよびMFを含むアプリケーションサーバとの間のセッションをセットアップおよび制御する。SIPシグナリングによって搬送されるセッション記述プロトコル(SDP)が用いられて、セッション内のメディア構成要素を記述およびネゴシエート(negotiate)する。さらに、リアルタイムストリーミングプロトコル(RTSP)が用いられて、例えばブロードキャストトリックモード、コンテンツオンデマンド(CoD)およびネットワークパーソナルビデオレコーダ(NPVR)などのメディア制御が提供され、リアルタイムトランスポートプロトコル(RTP)が用いられて、メディアが搬送される。
【0037】
図2はUEがユニキャストコンテンツオンデマンドメディアストリームを受信する場合の本発明の例示的な実施形態によるプロトコルフロー図である。この実施形態において、UEのユーザはコンテンツオンデマンド(CoD)を受信することおよび、他のUEの1人以上のユーザと同期してそれを見ることを望む。特定のUEのCoD RTPストリームのプレイアウト時間は、したがって、他の関連するCoD RTPストリーム(例えば同じ映画)を受信する他方のUEのプレイアウト時間と同期させる必要がある。
【0038】
この例において、SIPプロトコルが使用されて、ETSI TS 183 063 RTSP方法1によるセッションセットアップが行われる。第1のステップにおいて、UEはSCFに初期SIP INVITEメッセージを送信する。このSIP INVITEは、特定のUEが所属する同期グループを識別する、SyncGroupIdと呼ばれるパラメータを含む。この例において、SyncGroupIdはUEにすでに知られていると考えられている。しかしながら他の実施例もまた可能である。SyncGroupIdは、例えばセッション設置アップの間にSCFによって割り当てられてもよく、ステップ4のSIP 200 OKメッセージにおいて最初にUEと通信してもよい。
【0039】
同期グループは、1つ以上の指定されたメディアストリームに関して同期される必要があるUEのグループである。そのようなグループの例は、互いに同期して同じコンテンツオンデマンド(映画)を見ることを要求する、2つの異なる位置において2つの異なるユーザに所属する2つのUEであってもよい。
【0040】
SyncGroupIdパラメータはセッション記述プロトコル(SDP)セッションレベル属性、例えばa=RTCP−xr:sync−group=<value>として実施されてもよい。一実施形態では、IETF RFC 3611から知られるRTCP−xr属性フィールドが用いられてもよい。というのは、RTCPプロトコルのアプリケーション特有の拡張に関する情報を通信する意図があるからである。SCFはセットアップ要求を受信し、ユーザを同期グループに加えてもよい。そしてSCFは、この同期セッションに適切なMSASを選択してもよい。ステップ2において、SIP INVITEメッセージがSyncGroupIdと選択されたMSASのネットワークアドレスの両方を含む適切なMFに送信される。このMSASアドレスは別のセッションレベル属性に含まれてもよい、例えば、IETF RFC 3650からのSDPにおけるRTCP属性を用いてもよい。MFに送信されたRTCP属性もまたポート番号を含んでもよい。MFは、このセッションに関連するRTCPメッセージの送信先である新しいアドレス指示としてSIPメッセージ内に含まれるRTCP属性からの情報を用いてもよい。代替のポート番号がSIP INVITEメッセージ内で通信されていない場合は、MFはIETF RFC 3550に従って、RTCPメッセージを送信するためのデフォルトのRTCPポート番号、すなわちRTPポート番号を取り出して1を加えたもの、を用いてもよい。
【0041】
セッションセットアップ(SIP INVITE)メッセージを受信すると、MFは要求されたRTPストリームをSSRC識別子に割り当てる。ステップ3において、MFはSIP 200 OK応答をSIP INVITEに送信し、該SIP 200 OK応答はSyncGroupIdと、メディアストリームに関して新しく生成されたSSRC識別子の両方を含む。メディアストリームを一意的に識別するSSRCは、IETF RFC 5576に基づいてSDPにおけるメディアレベル属性を用いて送信されてもよい。ステップ4において、SCFはUEにSIP 200 OKメッセージを送信し、それは最終確認としての応答である。このSIP 200 OKメッセージは要求されたメディアストリームのSSRC、MSASアドレス、および、選択として、1つ以上の代替のRTCPポート番号を含む。加えて、SIPメッセージは新しく割り当てられた、または了承されたSyncGroupIdを含んでもよい。UEは、このセッションに関するRTCPメッセージを送信する新しいアドレスの指示として、受信されたMSASアドレスおよび代替のポート情報を用いてもよい。さらに、特に、メディアストリームの送信元(送信器)アドレスと異なるアドレスを有するMSASに、RTCPを介して同期ステータス情報を送信するためにこれらの新しいアドレス指示を用いてもよい。
【0042】
代替のポート番号がSIP OK メッセージにおいて通信されない場合、UEはIETF RFC 3550に従って、RTCPメッセージを送信するためのデフォルトのRTCPポート番号、すなわちRTPポート番号を取り出して1を加えたもの、を用いてもよい。ステップ5および6において、UEおよびSCFの両方が、SIP ACKメッセージと共に受信されたSIP OKメッセージに応答する。
【0043】
ステップ7において、RTSP制御は実際のメディアストリームをセットアップするために用いられ、メディアストリームはMFからUEへのストリーミングを開始する。メディアストリームのセットアップの方法はETSI TS 183 063に記載される。ステップ8において、メディアストリーム配信の最中に、UEは同期ステータス情報およびSyncGroupIdにそのRTCP受信器レポート(RTCP RR)を含めてもよい。これは、例えばRTCP拡張レポート(RTCP XR)を用いて行われてもよく、IETF RFC 3550に従ってSDES PRIVアイテムの形態で行われてもよい。UEはこの情報をRTCPメッセージとしてMSASに送信する。
【0044】
ステップ9において、MFはそのRTCP送信器レポート(RTCP SR)をRTCPメッセージとしてMSASに送信する。送信を行うメディア発信元(MF)と受信を行うメディア送信先(UE)の両方のRTCPメッセージが、MSASによって受信され、共通のメディアストリーム識別子(SSRC)を有する。
【0045】
MSASは今や、受信するレポートのそれぞれにおいてSSRCを合致させるように、UEから受信されたRTCPメッセージをMFに転送し、MFから受信されたRTCPメッセージをUEに転送する。SSRC識別子は所与のRTPストリームごとに一意的であり、したがって、同一のSSRC識別子を含む、メディア送信器(MF)からのRTCPメッセージとメディア受信器(UE)からのRTCPメッセージは、合致することができる。ステップ10および11において、受信されたメディア送信器レポートRTCPメッセージは、合致するメディア受信器レポートRTCPメッセージが発信されるIPアドレスに送信され、逆もまた同様である。MSASは、同一のSyncGroupIDを有する複数のUEから受信されるRTCPメッセージからの同期ステータス情報を用いて、同期セッション内に含まれるUEのそれぞれに対する設定指示を算出する。同期グループ内のそれぞれのUEに関する遅延情報を含んでもよいこれらの設定指示は、特別なRTCP XR内に含まれてもよく、上記のような機構を用いて各UEにRTCPメッセージとして送信されてもよい。
【0046】
図3は本発明の一実施形態による別の例示的なメッセージフロー図である。この実施形態において、ETSI TS 183 063 RTSP方法2に従って、メディアセッションはSIPおよびRTSPの組み合わせを用いてセットアップされる。ステップ1から6は図2に記載されたメッセージフロー図のステップ1から6と同様であり、したがってさらに詳細には記載しない。図2および3のステップ1から6に関するメッセージフロー図の唯一の相違は、図3によって示される方法のSIP OKメッセージ(ステップ3および4)においてはSSRC識別子が存在しないことである。その結果として、図3におけるメッセージフロー図の後続のステップは、図2のそれらとわずかに異なる。
【0047】
ETSI TS 183 063 RTSP方法2に従って、(SIP INVITEを用いるかわりに)RTSP DESCRIBEメッセージを用いてメディアレベル属性が(ネゴシエート/交換に)セットアップされる。MFによって生成されて割り当てられたSSRC識別子は、RTPメディアストリームに一意的なメディアレベル属性であるから、MFは、SSRC識別子ではなくSyncGroupIdおよびMSASアドレスを含むSIP200 OKでSIP INVITEに応答する。RTSPチャネルのSIPセッションのセットアップの後、UEはRTSP DESCRIBEメッセージを用いて実際のメディアストリームをセットアップする。ステップ7でMFがこのDESCRIBEメッセージを受信すると、MFはSSRC識別子を生成して割り当て、この識別子をRTSP 200 OKメッセージに加え、RTSP 200 OKメッセージは、ステップ8においてDESCRIBEメッセージに応じてUEに送信される。これは、IETF RFC 5576に従ってSDPにおけるメディアレベル属性を用いて、RTSP 200 OKメッセージに含まれるメディアのSDP記述内で行われてもよい。メディアフローの開始から、RTCPリレー機構を含む後続のステップは、図2および図3にそれぞれ記載された実施形態と同様である。
【0048】
一般に、同期ステータス情報は各同期クライアント(SC)のメディア受信に関するタイミング情報として最良に記載されることができる。同期クライアント(SC)はユーザ機器(UE)または、メディアパケットの受信が測定可能なネットワーク内の他の任意のポイントに位置することができる。SCは同期サーバ(MSASとも呼ばれる)と協働して、異なる受信器で受信されたストリームを同期させるか、同じ受信器で受信された異なるストリームを同期させる。受信器はメディアストリームの最終送信先であっても中間送信先であってもよい。同期ステータス情報を決定するためのサンプリングポイントのそれぞれが、同期ポイントと呼ばれてもよい。
【0049】
図4は、同期ステータス情報を搬送するためのRTCP XRレポートブロックに関する可能な定義を示す。第1の行はヘッダ情報を含み、ヘッダ情報はRTCP XRレポートブロック、予約されたスペース、およびブロック長を定義する所定のブロックタイプを含む。第2の行はRTPメディアストリームのSSRC識別子を含み、そこでRTCPレポートブロックがレポートを行う。第3の行はRTPストリームの受信器のNTPタイムスタンプを含む。このNTPタイムスタンプは64ビットを必要とし、最も重要なワードおよび最も重要でないワードに分けられる。最後に、このNTP時間(タイムスタンプ)に受信されたパケットのRTPタイムスタンプ、およびこのNTP時間に表示される(プレイアウトされる/提示される)パケットのRTPタイムスタンプが与えられる。受信器のグループ同期は、パケット受信タイムスタンプに基づいて行われてもよく、実際のパケット表示/提示タイムスタンプに基づいて行われてもよく、同期サーバの構造に依存する。異なるタイプのUEが、受信インターフェイスと表示インターフェイスの間で異なる遅延を示す可能性があるため、ユーザエクスペリエンスを最大にするためには、実際の表示/提示タイムスタンプを用いることが好ましい。しかしながら、異機種ネットワーク環境にあるすべてのユーザ機器が実際の表示時間をレポートすることができるとは限らないため、好ましくは(しかしながら必要ではないが)パケット受信とパケット表示の両方のタイムスタンプが、UE(受信器)によってMSASに送信されるRTCP XRレポートに含まれる。
【0050】
一般的には、同期設定指示は、同期クライアント(SC)がどれだけメディアストリームを遅延させるかをそこから直接的にまたは間接的に導き出すことができる指示(または指標)として最良に記載される。メディアストリームは、例えばブロードキャスト(BC)チャネル、ユニキャストまたはマルチキャスト(チャネル)であってもよい。同期クライアントはしたがって、関連するメディアストリームを遅延させるように、適切なバッファにさらに指示してもよい。
【0051】
図5は、同期設定指示を搬送するためのRTCP XRレポートブロックの可能な定義を示す。IETFインターネットドラフトdraft−ietf−avt−rtcpssm−18による受信器要約情報パケットのフォーマットがここで用いられる。この例におけるRTCP XRブロックが、すべてのRTPタイムスタンプの算出の根拠となるNTPタイムスタンプをレポートする。それは、すべてのUEのRTPタイムスタンプがマッピングされるNTPタイムスタンプを含み、その特定の時刻における同期グループ内の全てのUEのRTPタイムスタンプの最小値および最大値を含む。報告は複数のRTPタイムスタンプを含んでもよく、しかしながら、送信先間同期の目的のためには、RTPタイムスタンプの最小値(最も遅延しているストリームに対応する)のみが必要となる。この情報(同期設定指示)から、各同期クライアントが、最も遅延しているストリームに対して自身のストリームをどれだけ遅延させるべきか算出することが可能である。
【0052】
代替として、MSASは(すべてのSCから受信されたRTPタイムスタンプの測定値の中で最小の値よりも小さい)任意の値を送信するだけでもよく、それはSCが自身のストリームを同期させるために用いられるべきものである。これはネットワークにおける自然な遅延の変動を抑制し、SCがバッファを頻繁に再調整する必要をなくす。
【0053】
図6は本発明の実施形態による別の例示のフロー図である。メッセージフロー図は図2のフロー図のメディアセッションセットアップおよび同期機構と同様であるが、図6に記載の実施形態は、2つのUE(UE1およびUE2)のそれぞれが異なるメディアソース(MF1およびMF2)からのメディアストリームを受信し、両方のメディアストリームを同期させる必要があるという状況を示すという点で異なる。
【0054】
この実施形態において、SCFはセッションセットアップの最中に、個々のセッションの両方に同じMSAS(MSASアドレスおよび選択としてRTCPポート番号)を割り当てる。これにより、UE1、UE2、MF1およびMF2のいずれもが、同じMSASにそれらのRTCPメッセージを送信する。MF1からUE1へのメディアストリームに関するSSRC識別子は、MF2からUE2へのメディアストリームに関するSSRC識別子と異なるため、MSASはMF1から受信するRTCPメッセージ(およびそれに含まれるレポート)をUE1から受信するRTCPメッセージと合致させることが可能であり、同様に、MF2と合致するRTCPメッセージをUE2から受信するRTCPメッセージと一致させることが可能である。したがって、MSASは、すでに明細書中に記載された機構を用いて、正しいUE(メディアストリーム受信器)およびMF(メディアストリーム送信器)にRTCPを転送してもよい。
【0055】
MSASは、UE1とUE2から受信されたRTCPメッセージから抽出された関連の同期設定情報に基づいて、UE1に到達する(またはUE1によって表示/提示される)メディアストリームとUE2に到達する(またはUE2によって表示/提示される)メディアストリームを同期させる遅延設定指示を算出または決定してもよい。MSASはUE1に送信されるRTPストリームに関連する同期ステータス情報を、UE2に送信されるRTPストリームに関連する同期ステータス情報と合致させることができる。というのは、UE1とUE2の双方が、MSASに送信されるそれらのRTCPメッセージの少なくとも一方内で、MSASに同一のSyncGroupIdパラメータをレポートするかレポートしたからである。MSASは、以前に記載したように、MFから受信されたRTCPメッセージに遅延設定指示を加え、それからそれぞれのUEにそれらメッセージを送信する。
【0056】
異なる発信元から異なるUEへの異なるメディアストリームの同期は、MF1とMF2がそれぞれのメディアストリームをプレイアウトしたときに、MF1とMF2のいずれかが無作為なオフセットではなく同一のRTPタイムスタンプを用いることを要求し、または、RTPタイムスタンプ間の相関が、アプリオリに知られているか、MSASが遅延設定指示の算出または決定を開始する前にMSASに提供されていることを要求する。
【0057】
通常は、IPマルチキャストの最中に、RTPパケットおよびRTCPパケットの両方がマルチキャスト機構を用いて送信される。メディアの送信器と受信器の両方が、メディアトラフィックと同じマルチキャストアドレスにそれらのRTCPレポートを送信するが、RTPトラフィックと比較して2番目に大きいポート番号を用いる。インターネットドラフトdraft−ietf−avt−rtcpssm−18において、システムは単一発信元マルチキャスト(SSM)における使用のために記載され、メディアは1つのみの送信元から多くの受信器にストリーミングされる。SSMにおいてメディアの受信機は通常は同一のマルチキャストアドレスに(RTCPを)送信するべきではない。これは、多くの視聴者を伴うIPTVマルチキャストの場合、割り当てられたネットワークリソースが、必要とされないだろうコンテンツのないトラフィック(例えばRTCP制御メッセージ)で溢れることがないように、特にあてはまる。ドラフトは、受信器によるRTCPレポートの送信のためにユニキャスト機構の使用を提案する。受信器はいわゆるフィードバックターゲットにそれらのRTCPレポートをユニキャストする。さらに、送信器からのメディアを受信する配信元が導入され、配信元はそのメディアを受信機に配信する。同様に、配信元は送信器と受信器の間のRTCPメッセージの配信を担当する。
【0058】
フィードバックターゲットは配信元から離れていてもよいが、配信元の搬送アドレスはフィードバックターゲット内に構成されていなければならず、したがってフィードバックターゲットはRTCPメッセージを配信元にリレーすることができる。同様に、本明細書によれば、受信器はフィードバックターゲットアドレスにあらかじめ構成される必要があり、したがって受信器はそれらのRTCPメッセージをどこに送信するかアプリオリに知っている。言い換えれば、メディアの受信器によって生成されたRTCPメッセージのリレー機構全体は安定であり(あらかじめ構成されており)、ネットワーク内に配信元と呼ばれる新しいエンティティの存在が必要となる。
【0059】
図7はIPマルチキャストシナリオにおける本発明の例示的な実施形態のメッセージフロー図である。この実施形態はマルチキャストチャネルに加入する受信器(UE)の送信先間同期に関する。このシナリオは、例えば2人のユーザが、異なった位置の異なったUEで同期して同じライブコンテンツ(例えばマルチキャストのサッカー試合)を視聴することを望む場合に当てはまる。彼らは継続的なチャットセッションまたはオープンな電話回線を有して、一方のユーザが相手よりも前にゴールの瞬間を見るという危険を冒すことなく、一緒に試合を楽しむことができる。
【0060】
本明細書に詳述された本発明は、コンテンツプロバイダとは異なる第3者によって配信されることができる、追加の「別々に一緒に見る(watching apart together)」同期サービスの基礎として用いられてもよいとみなされる。このシナリオに適した、本発明の可能な実施形態は下に記載される。この実施形態では、同期サービスはユーザがマルチキャストに参加する前、セッションのセットアップの最中に開始される。
【0061】
ETSI TS 183 063によれば、受信者がマルチキャストに参加することを望む場合、適切なSCFとのセッションをまずセットアップする必要がある。それは、図7のステップ1から3に従って、SIPメッセージを用いることによって行うことができる。この実施形態では、ステップ1のUEによって送信されたSIP INVITEは、SyncGroupIdと呼ばれるパラメータをすでに含み、SyncGroupIdはUEが属する同期グループを識別する。代替として、SyncGroupIdはSCFによって割り当てられ、ステップ2でUEに送信される。
【0062】
SyncGroupIdがどのようにしてパッケージされるかの例示的な実施例は、セッション記述プロトコル(SDP)セッションレベル属性、例えばa=RTCP−xr:sync−group=<value>を用いる。SCFはセットアップ要求を受信し、適切な同期グループにユーザを加えることができる。SCFはしたがって、この同期セッションに関する適切なMSASを選択して、INVITEへの応答、すなわちステップ2のSIP 200 OKメッセージ内でMSAS搬送アドレスを送信する。このMSASアドレスは、例えばIETF RFC 3605からのSDP内のRTCP属性を用いており、例えば別のセッションレベル属性内に含まれることができる。ポート番号はIETF RFC 3550に従って、すなわちRTPポート番号を取り出して1を加えるように、通常のRTCPポート番号と同様に選択されてもよい。
【0063】
次に、ステップ4において、メディアフローは特定のメディアストリームに加入するように、例えばIGMPを用いてセットアップされる。UEは今や、ステップ5において、SCFから受信されたMSASアドレス(RTCPリレーアドレス)を用いて、同期ステータス情報を含むRTCPメッセージをMSASに直接送信することができる。これらのRTCPメッセージは同期ステータス情報およびSyncGroupIdを送信するために適切に拡張された受信器レポートメッセージであってもよい。この実施形態では、すべてのマルチキャスト受信器が同一のRTPタイムスタンプを含む同一のマルチキャストストリームを受信し、したがって、MSASは同期指示を算出するためにいかなるRTCP送信器レポート情報も必要としない。同様に、MSASは、UEから受信されたRTCPメッセージが送信される必要があるメディア送信器を決定するための送信レポートを要求しない。というのは、SSM構造のメディア送信器は多くの場合にUE(メディア受信器)からいかなるRTCPメッセージもまったく受信しないからである。様々なRTCPメッセージ間に合致がまったくないことが、この実施形態において必要となり、したがってRTCPメッセージ内に含まれるSSRCもまたMSASによっては用いられない。そのかわりに、ステップ6で示されるように、MSASは、適切なUEへのユニキャストRTCPメッセージ(例えばそのような設定を含むRTCP拡張レポート)を用いて、以前に受信したRTCPメッセージの発信されたアドレスを用いるだけで、その同期設定指示を送信するのみでよい。
【0064】
特定の場合のマルチキャスト環境においてはMSASは同期に関する送信器レポートを要求してもよい。例えば、異なる受信者は同一のコンテンツを、たとえば一方のマルチキャストチャネルは高品位ストリームであるのに対し別のマルチキャストチャネルはSDストリームであるように、異なるストリームで見るためである。これらの送信器レポートはいくつかの異なる方法でMSASによって得られてもよい。
【0065】
図8はMSASによってRTCP送信器レポートを受信するための3つの実施形態を表す。第1の実施形態(選択肢1)において、マルチキャストの受信器は送信器レポートに、それがMSASにRTCPメッセージとして送信した受信器レポートを加える。すべてのマルチキャスト受信器は同一のマルチキャストアドレス上で、しかし異なるポート番号上で、送信器レポートを受信する。すべてのマルチキャスト受信器は、これらの送信器レポートのコピーをMSASに送信してもよい。
【0066】
第2の実施形態(選択肢2)において、MSASはマルチキャストチャネルに加入する。MSASは適切なIGMPメッセージを送信し、マルチキャストグループのメンバとなる。MSASはしたがって、RTCPメッセージを含むこのグループに送信されたすべてのメッセージを受信する。マルチキャストトラフィックの粒度はアドレスにのみ依存し、ポート番号には依存しないため、このことはMSASがすべてのメディアトラフィックを受信することを意味する。これを阻止するために、ネットワークは好ましくはメディアトラフィックを除去してRTCPトラフィックのみを転送する。このことは多少は容易に達成される。というのは、標準配置において、RTPは偶数のポート番号のみを用いるべきであり、RTCPは奇数のポート番号のみを用いるべきだからである。
【0067】
第3の実施形態(選択肢3)において、メディア発信元(メディア機能MF)はユニキャスト機構を用いて、その送信器レポートのコピーをMSASに送信する。
【0068】
MSASが送信器レポートを受信することが可能な場合、それはもはや、受信器レポートを送信することを可能にするために、メディア発信元の送信アドレスの構成を必要としない。それどころか、メディア送信器の正しい搬送アドレスを決定するために上記の機構を用いて、メディア受信器からのRTCPメッセージからのSSRCをメディア送信器からのRTCPメッセージからにSSRCと一致させる同一の動的な機構を用いてもよい。
【0069】
この代替の実施形態によるメッセージフロー図がさらに図9に示される。例として、メディア受信器(UE)からMSASによってステップ5で受信されたRTCP RR(受信器レポート)メッセージが、メディア送信器からMSASによってステップ6において受信された適切なRTCP SR(送信器レポート)と、SSRCにおいて合致する。ステップ7において、合致に基づいて、MSASはRTCP RRメッセージをMFに転送する。この動的なリレー機構は、メディア送信器の搬送アドレスによってMSASをあらかじめ構成することを、もはや不要にする。それは、したがって、RTCPメッセージをリレーする柔軟で明解な方法を提供する。
【0070】
図9において示される実施形態においては、MSASによってメディア送信器からRTCPメッセージの受信を可能にするためにいくつかの構成が必要となるかもしれないことに留意する。MSASが、(例えば前記RTCPメッセージを得るために)例えばマルチキャストアドレスへの認可を必要とする場合、それはこのアドレスと共にあらかじめ構成されているか、何か他の機構によってこのアドレスを得る必要がある。メディア送信器(MF)がユニキャスト機構を用いてそのマルチキャストされたRTCPメッセージのコピーを送信する必要がある場合、それはMSASのユニキャストアドレスを必要とする。受信器がRTCPメディア送信器メッセージをMSASに転送する場合、MSASはMFの搬送アドレスを知ることがなく、したがってこの場合にはMSASはメディア送信器に受信器レポートを転送することができない。したがって、送信器はそのRTCPメッセージ内にメディア送信器(MF)の送信アドレスを含んでもよく、しかしながら、このことはRTCPへの別の拡張を定義することを必要とする。
【0071】
図10は本発明の別の実施形態の概略を示す。特に、図10はETSI TISPAN TS 183 064によって定義されたものとして次世代ネットワーク(NGN)統合IPTVシステムの概略を示す。そのようなNGN統合IPシステムのアーキテクチャの一般的なレイアウトは、図1を参照して記載されたIMSシステムとほぼ同様であり、本発明のさらなる実施形態に基づくRTCPメッセージを動的にリレーすることに適している。
【0072】
NGN統合IPTVシステムはIPTVコア(IPTV−C)1007および、HTTPベースの顧客に向いたIPTVアプリケーション(CFIA)1006を含む。IPTV−Cは、システムに接続されたユーザ機器UE1、UE2 1005がCFIAによって許可されているかどうかをチェックし、メディア制御機能(MCF)1002およびメディアコンテンツの配信を制御するメディア配信機能(MDF)1003を含むメディア機能(MF)1001の適切な選択を提供し、搬送機能(TF)1004を介してユーザ機器へのパケットを制御するように構成される。
【0073】
図1に記載のIMSシステムと同様に、NGN統合IPTVシステムは1つ以上のメディア同期アプリケーションサーバ(MSAS)1008で拡張されており、それは送信先間同期機能を実行するように構成される。ユーザ機器またはネットワークノードにおける同期動作は、同期クライアント(SC)1009の位置においてバッファ1010を用いて実行されてもよい。
【0074】
CFIAは、システムに接続されたUEが接続されてもよい異なる送信先間同期サービスに関連した動的な同期グループを維持するために構成される。さらに、CFIAは前記同期サービスに関する情報をCFIAに提供するサービス発見および選択(SD&S)機能(図示しない)に、例えば電子番組ガイド(EPG)からの情報の助けによって、接続されてもよい。
【0075】
システムはメディア制御のためにリアルタイムストリーミングプロトコル(RTSP)を用い、メディア搬送のためにリアルタイムトランスポートプロトコル(RTP)を用いる。しかしながら、図1のIPTVシステムとは対照的に、NGN拡張IPTVシステムはハイパーテキストトランスポートプロトコル(HTTP)を用いて、ユーザ端末間またはユーザ端末とMFを含むアプリケーションサーバとの間の(RTP)メディアセッションをセットアップする。処理状態を把握しない(stateless)プロトコルとしてHTTPは、(例えばSIPなどの処理状態を把握する(stateful)プロトコルの場合のように)セッション制御状態の実施および維持が原則として必要ないため、実施が容易であるという利点がある。さらに、HTTPはパラメータを搬送するために多くの方法(例えば、URI、SDP、XMLなど)を可能にし、同期グループを生成および削除するために用いられてもよい。実施例および関連する利点は以下の図11および図12に、参照によってより詳細に記載される。
【0076】
図11は、ユニキャストコンテンツオンデマンドメディアストリームを受信するUEに関する、本発明の例示的な実施形態によるプロトコルフロー1100を示す。図2のプロトコルフローと同様に、図11のプロトコルフローは、1人以上の他のUEのユーザと共にコンテンツを見るために同期されるコンテンツオンデマンド(CoD)を要求するUEのユーザに関連する。
【0077】
この実施形態において、セッションのセットアップはHTTPを用いて達成される。第1のステップ1において、UEは、同期グループを識別するSyncGroupIdを含むHTTP GETメッセージを、CFIAに属する特定のUEに送信する。SyncGroupIdはすでにUEに知られていてもよい。代替として、SyncGroupIdはセッションセットアップの間にUEによって、例えば生成されてもよい。
【0078】
SyncGroupIdパラメータはXML、SDP、SOAPまたは任意の他の適切なプロトコルを用いてHTTPメッセージ内で運搬されてもよい。適切な実施例は以下に記載される。CFIAはHTTP GETメッセージを受信し、ユーザをSyncGroupIdに基づいて適切な同期グループに加えてもよい。CFIAはしたがって、この同期セッションに関する適切なMSASを選択して、選択されたMSASにアドレスを関連づけてもよい。
【0079】
ステップ2において、HTTP GETメッセージが、選択されたMSASのSyncGroupIdおよびネットワークアドレスの両方を含む適切なMFに送信される。このMSASアドレスはXML、SDP、SOAPを用いるHTTPメッセージ内で、または別の適切な埋め込まれたセッションレベル属性、例えばIETF RFC 3605におけるRTCP属性内で運搬されてもよい。MFに送信されたHTTPメッセージはポート番号を含んでもよい。
【0080】
MFはHTTPメッセージ内の情報を検索してもよく、そこに含まれるアドレスおよびポート情報を、そのセッションに関連するRTCPメッセージをそのアドレスに送信する指示であるとみなしてもよい。
【0081】
HTTPメッセージの受信の際、MFは要求されたRTPストリームにSSRC識別子を割り当てる。ステップ3において、MFはHTTP 200 OKメッセージをCFIAに返送し、200 OKメッセージはSyncGroupIdとメディアストリームに関して新しく生成されたSSRC識別子との両方を含む。
【0082】
ステップ4においてCFIAは200 OKメッセージをUEに送信し、それは最終確認としての応答である。この200 OKメッセージは要求されたメディアストリームのSSRCのSSRC、MSASアドレス、および選択として代替のRTCPポート番号を含む。加えて、このHTTPメッセージは新しく割り振られた、または同意されたSyncGroupIdを含んでもよい。UEは、受信されたMSASアドレスおよび代替としてのポート番号を、そのセッションに関連するRTCPメッセージをそのアドレスに送信する指示であるとみなしてもよい。より特別には、UEはこれらの新しいアドレス指示を用いて、メディアストリームの送信元(送信器)のアドレスとは異なるアドレスを有するMSASに、同期ステータス情報をRTCPメッセージを介して送信してもよい。
【0083】
その後、ステップ5〜9において、RTSP制御を用いて実際のメディアストリームをセットアップし、メディアストリームはRTCP受信器レポート(RTCP RR)およびRTCP拡張レポート(RTCP XR)を用いてMFからUEにストリーミングを開始する。これらのステップはFig.2に記載のプロセスと同一であり、TS 183 063により詳細に記載される。
【0084】
同様に、HTTPは、HTTPセッションをCFIAと共に最初にセットアップすることによってマルチキャストに参加することを要求するUEのために用いることができる。このプロセスは図12に記載され、図7のSIPを根拠にしたメッセージフローと同一である。
【0085】
HTTPは、異なるプロトコルを用いて、例えばSyncGroupId、MSASのアドレスなどのパラメータを運搬することができる。一実施形態では、これらのパラメータは拡張マークアップ言語プロトコル(XML)を用いて運搬されてもよい。例えば、UEとCFIAの間のパラメータを送信するためのhttpメッセージはXMLボディを有してもよい。例えばUEは以下のHTTP要求を用いてCFIAから同期情報を要求してもよい。

GET http://cfia.etsi.org/syncgroup/?SyncGroupId=217a5bd0
HTTP/1.1
User−Agent: IPTVClient/1.0

代替として、URLは別のフォーマットをとってもよく、例えばhttp://cfia.etsi.org/syncgroup/217a5bd0 HTTP/1.1。 応答して、CFIAは、SyncGroupId 217a5bd0に関連するパラメータを伴うXMLボディを含むHTTP応答を介して、要求された情報を送信することができる。

HTTP/1.1 200 OK
Server: CFIA/1.0
Content−Type: application/vnd.etsi.iptvsyncgroup+xml
Content−Length: 35

<?xml version=”l.0” ?>
<syncgroup id=”217a5bd0”>
<rtcp ssrc=”AF” recv=”192.168.1.100:1234” />
</syncgroup>

この例において、XMLボディはこの同期セッションに関連するSSRCおよび、MSAS(recv)のIPアドレスおよびポート番号を識別する。XMLボディに関連するXMLスキーマは以下のように示される。

<?xml version=”l.0” ?>
<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema”>

<xs:element name=”syncgroup”>
<xs:complexType>
<xs:sequence>
<xs:element name=”participant”>
<xs:complexType>
<xs:attribute name=”id” type=”xs:string”/>
</xs:complexType>
</xs:element>
<xs:element name=”rtcp”>
<xs:complexType>
<xs:attribute name=”ssrc” type=”xs:string”/>
<xs:attribute name=”recv” type=”xs:string”/>
</xs:complexType>
</xs:element>
<xs:attribute name=”id” type=”xs:string”/>
<xs:sequence>
</xs:complexType>
</xs:element>

</xs:schema>

同一のまたは類似したXMLボディを得るために、このXMLスキームの多くの変形例が可能であることに留意すべきである。
【0086】
別の実施形態では、シンプルオブジェクトアクセスプロトコル(SOAP)がパラメータを搬送するために用いられてもよい。そのメッセージフォーマットに関しては、SOAPは拡張可能マークアップ言語(XML)に依存する。UEとCFIAの間のHTTP要求および関連するHTTP応答の1つの可能なSOAP実施例が、以下に示される。

POST /syncgroup HTTP/1.1
Host: www.etsi.org
Content−Type: application/soap+xml; charset=utf−8
Content−Length: nnn

<?xml version=”l.0” encoding=”utf−8”?>
<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema−instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<syncgroupJoinRequest xmlns=”http://www.etsi.org/sync”>
<syncgroup id=217a5bd0>
<participant id=”userA@etsi.org” />
</syncgroup>
</syncgroupJoinRequest>
</soap:Body>
</soap:Envelope>

HTTP/1.1 200 OK
Content−Type: application/soap+xml; charset=utf−8
Content−Length: nnn

<?xml version=”l.0” encoding=”utf−8”?>
<soap:Envelope xmlns:xsi=”http://www.w3.org/2001/XMLSchema−instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:Body>
<syncgroupJoinResponse xmlns=”http://www.etsi.org/sync”>
<syncgroup id=”217A5bd0”>
<participant id=”userA@etsi.org” />
<rtcp ssrc=”AF” recv=”192.168.1.100:1234” />
</syncgroup>
</syncgroupJoinResponse>
</soap:Body>
</soap:Envelope>
【0087】
さらに別の実施形態では、SIPの場合に用いられる方法と同様に、パラメータはSDPボディによって搬送される。この場合には、HTTP要求の可能なSDP実施形態および、UEとCFIAの間で送信される関連するHTTP応答が以下に示される。

GET /syncgroup/217A5bd0 HTTP/1.1
Host: www.etsi.org
Accept: application/sdp

HTTP/1.0 200 OK
Content−Type: application/sdp
v=0
o=− 2890844526 2890842807 IN IP4 192.16.24.202
a=ssrc:<ssrc−id> <attribute>:<value>.
a=rtcp−xr:sync−group=<value>
a=rtcp:port [nettype space addrtype space connection−address]
【0088】
したがって、HTTPはパラメータ、特に同期パラメータを、UE、CFIAおよびMF間で搬送する非常に柔軟な方法を提供する。さらに、さらなる変形例において、HTTP PUT(またはPOST)およびHTTP DELETEメッセージは、存在する同期グループにUEが加入するか離れるかを可能にすることができる。その意味では、HTTPはさらなる柔軟性も可能にする。存在する同期グループに加入する1つの実施例は以下に示される。

PUT http://cfia.etsi.org/syncgroups/217A5bd0/participants
HTTP/1.1
User−Agent: IPTVClient/1.0
Content−Type: application/vnd.etsi.iptvsyncgroup+xml
Content−Length: 35

<?xml version=”l.0” ?>
<syncgroup id=”217A5bd0”>
<participant id=”userB@etsi.org” />
</syncgroup>

HTTP/1.1 201 Created
Server: CFIA/1.0
Location: http://cfia.etsi.org/syncgroups/217A5bd0
Content−Type: application/vnd.etsi.iptvsyncgroup+xml
Content−Length: 35

<?xml version=”l.0” ?>
<syncgroup id<=>”217a5bd0”>
<participant id=”userA@etsi.org” />
<participant id=”userB@etsi.org” />
<rtcp ssrc=”AF” recv=”192.168.1.100:1234” />
</syncgroup>
【0089】
この実施形態において、UEは、同期グループ217a5bd0にuserB@etsi.orgを加えることをCFIAに要求するHTTP PUTメッセージを送信する。それの返答として、UEは、UEが加えられたCFIAの確認を受信する。さらに、返答メッセージはSSRCおよび同期グループに関連するMSASのアドレスに関する情報を有する。選択として、返答メッセージはさらに情報を、例えばこの場合はuserA@etsi.orgとuserB@etsi.orgとして識別される同期グループの加入者の情報を含む。
【0090】
存在する同期グループを離れることは、HTTP DELETEメッセージ、DELETE http://msas.etsi.org/syncgroup/217a5bd0/participants/userA@etsi.org http /1.1, User−Agent: IPTVClient/1.0をCFIAに送信することによって実施される。
【0091】
同様にして、新しい同期グループが、CFIAへのHTTP POSTメッセージを感知することによって生成される。

POST http://cfia.etsi.org/syncgroups HTTP/1.1
User−Agent: IPTVClient/1.0
Content−Type: application/vnd.etsi.iptvsyncgroup+xml
Content−Length: 35

<?xml version=”l.0” ?>
<syncgroup>
<participant id=”userA@etsi.org” />
</syncgroup>

HTTP/1.1 201 Created
Server: CFIA/1.0
Location: http://cfia.etsi.org/syncgroups/217a5bd0
Content−Type: application/vnd.etsi.iptvsyncgroup+xml
Content−Length: 35

<syncgroup id=”217a5bd0”>
<participant id=”userA@etsi.org” />
<rtcp ssrc=”AF” recv=”192.168.1.100:1234” />
</syncgroup>
【0092】
本発明の実施形態はコンピュータシステムにおける使用のためのプログラム製品として実施されてもよい。プログラム製品のプログラムは(本明細書に記載された方法を含む)本実施形態の機能を定義して、様々なコンピュータ読み取り可能な記憶媒体上に含まれることができる。概略的なコンピュータ読み取り可能な記憶媒体は、(i)情報が恒久的に記憶される書き込み不可能な記憶媒体(例えば、CD−ROMドライブによって読み取り可能なCD−ROMディスク、フラッシュメモリ、ROMチップまたは任意のタイプのソリッドステートな不揮発性半導体メモリなどのコンピュータ内の読み取り専用メモリ装置)、(ii)変更可能な情報が記憶される書き込み可能な記憶媒体(例えば、ディスケットドライブ内のフロッピー(登録商標)ディスクまたはハードディスクドライブまたは任意のタイプのソリッドステートなランダムアクセス半導体メモリ)を含むが、それらには限られない。
【0093】
いかなる実施形態に関連して記載されたいかなる特徴も単独で使用されてもよく、または、記載された他の特徴と組み合わせて使用されてもよく、そして、任意の他の実施形態の1つ以上の特徴と組み合わせて使用されてもよく、または任意の他の実施形態の任意の組み合わせと組み合わせて使用されてもよい。さらに、添付の特許請求の範囲に定義されているが、上記されない均等物および変形例もまた、本発明の範囲から離れることなく用いられる。

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

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate


【公表番号】特表2013−502123(P2013−502123A)
【公表日】平成25年1月17日(2013.1.17)
【国際特許分類】
【出願番号】特願2012−524187(P2012−524187)
【出願日】平成22年7月30日(2010.7.30)
【国際出願番号】PCT/EP2010/061135
【国際公開番号】WO2011/018368
【国際公開日】平成23年2月17日(2011.2.17)
【出願人】(500098057)コニンクリジケ ケーピーエヌ エヌブィー (9)
【出願人】(595115802)
【氏名又は名称原語表記】Nederlandse Organisatie voor toegepast−natuurwetenschappelijk onderzoek TNO
【Fターム(参考)】