JP2011508491A - マルチメディア・ストリームの送信方法およびシステム - Google Patents

Abstract

第１終端端末から第２終端端末にマルチメディア・ストリームを送信する方法について記載する。第１終端端末および第２終端端末は、マルチメディア・ストリームを第１終端端末から第２終端端末に送信することを可能にするために、少なくとも１つのゲートウェイに接続されている。本方法は、第１終端端末が、当該第１終端端末とゲートウェイとの間に第１マルチメディア・セッションを設定するように、ゲートウェイを招待し、第１マルチメディア・セッションを第１プロトコルによって制御するステップと、ゲートウェイが、この招待に応答して、第２終端端末にこの保留中の招待を通知するステップと、第２終端端末が、この通知に応答して、第２終端端末とゲートウェイとの間に第２マルチメディア・セッションを設定し、第２マルチメディア・セッションを第２プロトコルによって制御するステップと、ゲートウェイが、招待に応答して、第１マルチメディア・セッションを設定するステップと、第１終端端末から第２終端端末にマルチメディア・ストリームを送信するステップとを備えている。第１プロトコルはＳＩＰとすることができ、第２プロトコルはＲＴＳＰとすることができる。
【選択図】図７

Description

本発明は、第１端末から第２端末にマルチメディア・ストリームを送信する方法およびシステムに関する。特に、本発明は、第１端末から第１マルチメディア・ストリームを送信し、第２端末において関連付けられた第２ストリームを受信する方法およびシステムに関するものである。更に、本発明は、このようなシステムにおいて用いるためのゲートウェイおよびデバイスに関するものである。

従来技術

３ＧＰＰおよび３ＧＰＰ２規格によって定められているＩＰマルチメディア・サブシステム（ＩＭＳ）は、ボイス・オーバー・ＩＰ（ＶｏＩＰ）およびＩＰＴＶのような、新たなマルチメディア・サービスの範囲全体に及ぶ扉を開いた。ＩＭＳサービス・アーキテクチャは、種々のタイプのマルチメディア・サービスを組み合わせることを可能にする。

サービスの一種では、自宅にいる視聴者が、例えば、自宅においてウェブカム(webcam)を用いて、生のＴＶショーにリアル・タイムで参加することを可能にするものもある。ウェブカムが生成するマルチメディア・ストリームは、リアル・タイム・トランスポート・プロトコル（ＲＴＰ）を用いて、自宅にいるユーザからＩＰネットワークを通じてＴＶスタジオに搬送される。ＩＭＳベース・アーキテクチャでは、クライアント間におけるこのようなマルチメディア・ストリーミング・セッションは、セッション開始プロトコル（ＳＩＰ ; Session Initiation Protocol）を用いて設定されるが、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ ; Real Time Streaming Protocol）は、マルチメディア・コンテンツをサーバからクライアントにストリーミングするために用いられるのが通例である。

ＳＩＰドメインおよびＲＴＳＰドメイン間にインターフェースを設けるシステムは、通常ＳＩＲ−ＲＴＳＰゲートウェイと呼ばれており、当技術分野では周知である。ＥＴＳＩ ＴＩＳＰＡＮ標準化（ＷＩ２０４８、ＴＳ １８２ ０２７）の中では、例えば、セット・トップ・ボックス、パーソナル・コンピュータ、パーソナル・ディジタル・アシスタント（ＰＤＡ）、またはマルチメディア能力を備えた移動体電話機のようなデバイス内に構成されている端末が、ＳＩＰを用いて、選択したコンテンツ提供業者とのマルチメディア・セッションを設定するアーキテクチャが提案されている。セッションの確立後、ＲＴＳＰを用いて、ストリーミングされるコンテンツを選択し、読み出し、制御する。更に、コロンビア大学（Kundan Singh and Henning Schulzrinne, "Unified Messaging using SIP and RTSP"（ＳＩＰおよびＲＴＳＰを用いた統一メッセージング）、IP Telecom Services Workshop, Sept 2000, Atlanta, Georgia, US）が、マルチメディア統一メッセージング用ＳＩＰ−ＲＴＳＰゲートウェイを開発している。

これらのシステムは、ユーザ側においてＳＩＰおよびＲＴＳＰクライアントを用い、ＳＩＰクライアントおよびＲＴＳＰサーバをネットワークにおいて用いることによって、ユーザがマルチメディア設定セッションを開始して、マルチメディア・コンテンツをＲＴＳＰサーバからユーザにストリーミングすることを可能にする。

異なるプロトコル・ドメイン間においてマルチメディアをストリーミングするために用いることができる別のゲートウェイ・システムが、TAKEI K ET AL "Design of gateway system between different signaling protocols of the multimedia session on the internet"（インターネット上のマルチメディア・セッションの異なるシグナリング・プロトコル間におけるゲートウェイ・システムの設計） INFORMATION NETWORKING, 2001. PROCEEDINGS. 15TH INTERNATIONAL CONFERENCE ON 31 JANUARY - 2 FEBRUARY, PISCATAWAY, NJ, USA, IEEE, 2001, PAGES 297-302, ISBN: 0-7695-0951-7/01に記載されている。このシステムは、ＳＩＰおよびＨ３２３プロトコル・ドメインを相互に作用させる(interwork) ために用いられる。双方のプロトコルは、ピア・ツー・ピア型プロトコルであり、セッションの双方向設定／開始に対応する。

これら既知のシステムに関する問題の１つは、これらが前述のサービスに必要な機能全てを提供しないことであり、このために、ユーザが生成したコンテンツをユーザから（送信端）からスタジオに（受信端）にストリーミングされるように、ユーザがマルチメディア・セッションを設定しなければならないが、スタジオが、ユーザ生成コンテンツのストリームを制御したい場合もあり得る。ストリームを制御する既知のプロトコルの１つにＲＴＳＰがあり、これによって、ＲＴＳＰクライアント機能を有する受信端が、ストリームを一時停止すること、あるいは順送りまたは逆送りすること、あるいは異なる速度でストリームを再生することができる。他方の送信端が、マルチメディア・ストリーミング・セッションを設定および維持するためにＳＩＰプロトコルしか用いることができない場合、既知の先行技術のシステムでは、前述のサービスを実現することができない。何故なら、ＳＩＰプロトコルは、例えば、ＲＴＳＰプロトコルができるような仕方でストリームを制御する手段を提供しないからである。

先行技術のシステムで発生する可能性がある、マルチメディアのストリーミングに関する別の問題は、マルチメディアを受信するためにクライアント−サーバ型プロトコルのクライアント機能しか受信端に装備されていない場合、マルチメディア・セッションを開始することしかできない場合があることである。送信端が、例えば、ＳＩＰプロトコルのようなピア・ツー・ピア型プロトコルを用いて、マルチメディア・ストリーミング・セッションを開始したい場合、受信端はこのような招待に応答することができない。既知のＳＩＰ−ＲＴＳＰゲートウェイおよび既知のＳＩＰ−Ｈ３２３ゲートウェイのような先行技術のシステムは、この問題に対する解決策を提供することができない。

先行技術のシステムでは、ユーザが生成したマルチメディアを多数の受信端にストリーミングしなければならないとき、更に別の様々な問題が発生する可能性がある。これらの受信端は全て、マルチメディア・ストリームを受信しようとするとき、異なる能力または好みを有する可能性がある。１つの受信端はライブ・ストリームを受信することを望むが、他の受信端は前述のようにストリームを制御できるようになることを望むこともあり得る。加えて、これらの好みおよび能力、ならびに受信端のネットワーク・アドレスは、送信端には知られていない場合がある。

本発明の目的は、先行技術において知られている欠点の内少なくとも１つを低減または解消すること、そして第１端末から第１マルチメディア・ストリームを送信し、第２端末において関連付けられた第２マルチメディア・ストリームを受信する方法およびシステムを提供することである。

一実施形態では、第１端末および第２端末は、前記第１マルチメディア・ストリームの送信および関連付けられた第２ストリームの受信を可能にするために、少なくとも１つのゲートウェイに接続されている。この方法は、
−第１プロトコルを用いて、第１端末とゲートウェイとの間で第１マルチメディア・セッション情報の交換を開始するステップと、
−第２プロトコルを用いて、第２端末とゲートウェイとの間で第２マルチメディア・セッション情報の交換を開始するために、トリガを第２端末に供給するステップと、
−当該トリガの供給に応答して、第２端末が、第３プロトコルを用いて、第２端末とゲートウェイとの間で第２マルチメディア・セッション情報の交換を開始する、ステップであって、第３プロトコルが第２プロトコルとは異なるものである、ステップと、
−第１端末から第１マルチメディア・ストリームを送信し、第２端末において関連付けられた第２マルチメディア・ストリームを受信するステップと、
を備えている。

このように、本方法は、第１端末のユーザが、リアル・タイムのユーザ生成コンテンツのマルチメディア・ストリームを第２端末に送信することを可能にし、これによって、第１端末が異なるマルチメディア・プロトコルを用いて、第２端末が関連マルチメディア・ストリームを受信するために用いるように、マルチメディア・ストリームを設定する。

この実施形態による方法では、ゲートウェイが、第１プロトコル、例えば、ＳＩＰをサポートする第１端末を、異なる（第３）プロトコル、例えば、ＲＴＳＰをサポートする第２端末に接続することができる。第１端末、即ち、ユーザ側における（発信元）ＳＩＰクライアントに対しては、ゲートウェイは（着信先）ＳＩＰクライアントとして動作する。ゲートウェイは、第１マルチメディア・セッションの仕様についての情報を第１端末と交換する。第１マルチメディア・セッションでは、マルチメディア・ストリームを第１端末から送信する。第２端末、即ち、ＲＴＳＰクライアントに対しては、ゲートウェイはユーザの代わりにＲＴＳＰサーバとして動作し、これによって、第２端末は、第２マルチメディア・セッションの仕様についての情報をゲートウェイと交換するためにＲＴＳＰを用いる。第２マルチメディア・セッションでは、マルチメディア・ストリームは第２端末によって受信される。

第２端末は、当該第２端末が用いるプロトコルとは異なる第２プロトコルを用いてトリガされ、第２マルチメディア・セッション情報を交換し、新たなマルチメディア・ストリームの入手可能性を第２端末に通知し、ＲＴＳＰクライアントを活性化して、ゲートウェイのＲＴＳＰサーバ機能に接続する。任意に、ＲＴＳＰクライアントの活性化は、第２端末のユーザの承認後でなければ行えないようにしてもよい。こうすると、この承認ステップは、単に完全自動プロセスの一部となる。

ゲートウェイは、ＳＩＰクライアントおよびＲＴＳＰサーバの双方として動作することができ、第２端末をゲートウェイに接続するために、トリガを第２端末に供給することができる。本発明は、異なるプロトコルを用いてトリガを供給し、次いで、第２端末がこのプロトコルを用いて、マルチメディアの受信に備えるという考えに基づいている。この考えは、一部のプロトコルは、マルチメディア・セッションを一方向でしか開始することができないという洞察に基づく。トリガ（メッセージ）は、ユーザ生成コンテンツを第１端末から第２端末に送信することを可能にするために、ユーザからのＳＩＰクライアントおよびスタジオからのＲＴＳＰクライアントを接続できることを保証する。

本発明による方法の更に別の実施形態では、第１メディア・セッション情報の交換は、第１端末に第２マルチメディア・セッション情報の少なくとも一部を供給することを含み、第１端末からの第１マルチメディア・ストリームの送信は、供給に応答して開始される。これには、本方法の柔軟性を高める利点がある。関係する双方のマルチメディア・セッションの予め決められている仕様を、ストリームの送信および受信に関与する端末に供給するのは、もはやゲートウェイではないが、ゲートウェイは第２受信端末からの設定値を用いて（要求されて）、これらを第１の送信側端末に供給すること、またはその逆を行うことができる。そして、同じ便益を得るために、ゲートウェイは第１送信側端末からの設定を用いて（要求されて）、これらを第２の受信側端末に供給することもできる。双方の状況において、マルチメディア・ストリームの送信および受信は、それぞれ、これらの設定の交換の後でなければ開始することができない。

この方法の一実施形態では、第１プロトコルは、ピア・ツー・ピア型プロトコル、好ましくは、セッション開始プロトコル（ＳＩＰ）である。ピア・ツー・ピア型プロトコルの利点は、両側がストリーミングセッションの設定を開始できることである。したがって、本発明では、第１端末がマルチメディア・ストリームを提供してもよく、ゲートウェイが最初に第１端末にマルチメディア・ストリームを要求してもよい。ＳＩＰプロトコルは、マルチメディア・セッションでは極一般に用いられているプロトコルであり、したがって、多くのデバイスおよびネットワーク・アーキテクチャがこのプロトコルをサポートする。

本方法の更に別の実施形態では、第３プロトコルは、クライアント−サーバ型プロトコル、好ましくは、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）である。通例、クライアント−サーバ型プロトコルは、一方向で開始するマルチメディア・セッション設定しかサポートしないように設計されているプロトコルである。クライアントだけが設定を開始できるのが通例である。したがって、本発明は、第２の受信側端末がこのようなプロトコルのクライアント能力だけを有し、したがってこのようなプロトコルを通じて招待を受けることができない場合に、有利に用いられる。ＲＴＳＰプロトコルの仕様は、受信側の第２端末が入来するストリームを制御しこのプロトコルの特殊制御オプションを用いたいときに有利である場合もある。

本方法の更に別の実施形態では、トリガを第２端末に供給するステップは、ゲートウェイによって開始される。例えば、第１端末ではなく、ゲートウェイにトリガを提供させることは、第１端末が正しいトリガ能力を有しておらず、第２端末にどのようにして到達すべきか分からない場合、そして、受信端末が多数ありこれらに到達する必要がある場合に有利であると言える。

本方法の更に別の実施形態では、トリガは、ゲートウェイのネットワーク・アドレス、好ましくは、ＵＲＩまたはＵＲＩ参照を含む。これは、第２端末にはデフォルト・アドレスが定められていない場合、またはマルチメディア・ストリームを受信するために通常用いられるデフォルト（プロキシ）アドレスが適用できない場合に有利であると言える。

本方法の別の実施形態では、第１マルチメディア・セッション情報の交換は、第２端末の識別子のゲートウェイへのプロビジョニングを含む。これは、トリガを第２端末に供給するのがゲートウェイである場合に有利であると言える。その状況では、ゲートウェイが、到達すべき第２端末のアドレスを特定できなければならない。

本方法の更に別の実施形態では、本方法は、トリガの第２端末へのプロビジョニングの前に、第２端末の識別子をリゾルブしてネットワーク・アドレスを得る追加のステップを備えている。この状況が発生する可能性があるのは、トリガがゲートウェイによって送られ、識別子が第２端末のネットワーク・アドレスを含まないときである。識別子は、非公開ユーザのグループＩＤとすることもでき、その場合、全ての受信側端末の全てのネットワーク・アドレスを最初に識別する必要がある。

本方法による別の実施形態では、第１プロトコルおよび第２プロトコルが同一である。これによって、本発明の実現がシンプルなものになる。これと同様の状況は、受信側端末がＲＴＳＰおよびＳＩＰのクライアント能力の双方を有する場合に起こる可能性がある。この場合、トリガは、ＳＩＰプロトコルを用いて供給することができ、一方、マルチメディア・ストリームの受信の開始および設定は、ＲＴＳＰクライアントを用いて行うことができるので、ＳＩＰに欠如する制御機能（トリック・プレー）を可能にする。

本方法の別の実施形態では、関連付けられた第２のマルチメディア・ストリームはマルチキャスト・ストリームである。これは、多数の受信側端末にライブ・マルチメディア・ストリームを提供できるときに有利であると言える。これらは、トリガを供給され、第２マルチメディア・セッション情報の交換においてゲートウェイからマルチキャスト・アドレスを受信した後に、ＩＧＭＰを用いてそのマルチキャストにサイン・アップすることができる。

本方法の更に別の実施形態では、第１マルチメディア・ストリームはマルチキャスト・ストリームである。これは、第１送信側端末がそのマルチメディア・ストリームをマルチキャストするために用いることができるマルチキャスト・アドレスを有する（受信した）ときに有利である。

本方法の更に別の実施形態では、第１マルチメディア・ストリームは、関連付けられた第２マルチメディア・ストリームと同じマルチメディア・ストリームである。この場合、（ライブ）コンテンツは、ライブで／送信側第１端末から大きな遅れが全くなく受信することもできる。追加のトリック・プレー（制御）機能を可能にするためには、送信されたマルチメディア・ストリームは、ＲＴＳＰサーバのようなマルチメディア・サーバの制御の下で、最初にある場所でストリーミングしバッファした後に、それを関連付けられた第２ストリームとして第２端末に送信する必要がある。すると、この追加の制御機能（例えば、順送り、逆送り、一次停止）をこの関連付けられた第２ストリームに実行することができる。

本方法の別の実施形態では、第１端末およびゲートウェイは、双方とも同じデバイス内に構成されており、第１プロトコルは内部プロトコルである。これは、ネットワーク（またはスタジオ／受信端）が本発明によるゲートウェイ機能を有していないときに、有利な実施態様となることができる。好ましくは、この状況は、送信側端末と受信側端末との間に１対１の関係が存在し、双方の端末が移動体デバイス内に構成されているときに起こるとよい。

一態様では、本発明は、第１端末からマルチメディア・ストリームを送信し、第２端末において、関連付けられた第２のマルチメディア・ストリームを受信するシステムに関する。このシステムは、
少なくとも１つのゲートウェイに接続されている第１端末および第２端末を備えており、
第１端末は、（ｉ）第１プロトコルを用いて、ゲートウェイと第１マルチメディア・セッション情報を交換する手段と、（ｉｉ）第１マルチメディア・ストリームを送信する手段とを備えており、
ゲートウェイまたは第１端末は、（ｉｉｉ）第３プロトコルを用いて第２端末とゲートウェイとの間で第２マルチメディア・セッション情報の交換を開始するために、第２プロトコルを用いて第２端末をトリガする手段を備えており、
第２端末は、（ｉｖ）第２プロトコルを用いて、トリガを受信する手段と、（ｖ）トリガに応答して、第３プロトコルを用いて、ゲートウェイと第２マルチメディア・セッション情報の交換を開始する手段と、（ｖｉ）第１マルチメディア・ストリームと関連付けられた第２マルチメディア・ストリームを受信する手段とを備えている。

本発明によるこのシステムの別の実施形態では、ゲートウェイは、更に、第１マルチメディア・セッション情報を第２マルチメディア・セッション情報に関連付ける手段を備えている。これは、ゲートウェイがデフォルトのコンフィギュレーションを有しておらず、どのように送信側端末および受信側端末に命令するか分からないが、より柔軟な構成が必要なときに有利であると言える。マルチメディア・セッションを設定するとき、関与する端末の設定要求および能力を考慮にいれる。

本発明の更に別の態様は、本発明によるシステムにおいて用いるために構成されるゲートウェイに関する。このゲートウェイは、
−第１プロトコルを用いて、ゲートウェイと第１マルチメディア・セッション情報とを交換する手段と、
−第２端末をトリガする手段であって、トリガは第２プロトコルを用いて供給され、これに応答して、第２端末が、ゲートウェイとの第２マルチメディア・セッション情報の交換を開始することができる、手段と、
−第３プロトコルを用いて、第２端末と第２マルチメディア・セッション情報を交換する手段であって、第３プロトコルが第１プロトコルとは異なるものである、手段と、
を備えている。

本発明によるゲートウェイの別の実施形態では、ゲートウェイは、更に、第１マルチメディア・セッション情報および第２マルチメディア・セッション情報を互いに関連付ける手段を備えている。

本発明によるゲートウェイの更に別の実施形態では、ゲートウェイは、ＳＩＰクライアント機能およびＲＴＳＰサーバ機能を備えている。
本発明によるゲートウェイの更に別の実施形態では、ゲートウェイは、ＩＭＳネットワーク・アーキテクチャに組み込まれ、第１プロトコルがＳＩＰであり、第３プロトコルがＲＴＳＰであり、
−第１マルチメディア・セッション情報を交換する手段は、ＩＭＳ内部にあるサービス制御機能の一部であり、
−第２端末をトリガする手段は、ＩＭＳ内部にあるサービス制御機能の一部であり、
−第２マルチメディア・セッション情報を交換する手段は、ＩＭＳ内部にあるメディア機能の一部である。

ＩＭＳは、増々普及しつつあり、マルチメディア・サービスをその顧客にプロビジョニングするために運用業者間で用いられている。本発明の実施形態による分散型ゲートウェイが特に有利であるのは、ＩＭＳアーキテクチャにおいて既に存在する標準（化された）コンポーネントや機能を用いて実現できるからである。

本発明の一実施形態では、第１端末が第２端末に接続されている。更に、第１端末および第２端末は、マルチメディア・ストリームを第１端末から第２端末に送信することを可能にするために、少なくとも１つのゲートウェイに接続されている。本方法は、（ｉ）第１端末が、当該第１端末とゲートウェイとの間に第１マルチメディア・セッションを設定するように、ゲートウェイを招待し、第１マルチメディア・セッションを第１プロトコルによって制御するステップと、（ｉｉ）ゲートウェイが、この招待に応答して、第２端末にこの保留中の招待を通知するステップと、（ｉｉｉ）第２端末が、この通知に応答して、第２端末とゲートウェイとの間に第２マルチメディア・セッションを設定し、第２マルチメディア・セッションを第２プロトコルによって制御するステップと、（ｉｖ）ゲートウェイが、招待に応答して、第１マルチメディア・セッションを設定するステップと、（ｖ）第１端末から第２端末にマルチメディア・ストリームを送信するステップとを備えている。

したがって、この実施形態による方法は、第１マルチメディア・プロトコルを用いる第１端末のユーザが、リアル・タイムユーザ生成コンテンツを、第２マルチメディア・プロトコルを用いる第２端末にストリーミングすることを可能にする。この場合、第１端末および第２端末は双方ともクライアントとして動作する。

この実施形態による方法では、ゲートウェイは、第１プロトコル、例えば、ＳＩＰをサポートする第１端末を、第２プロトコル、例えば、ＲＴＳＰをサポートする第２端末に接続することができる。第１端末、即ち、ユーザ側における（発信元）ＳＩＰクライアントに対して、ゲートウェイは（着信先）ＳＩＰクライアントとして動作する。ゲートウェイは、ユーザからマルチメディア・セッションを受信することができることを確認し、第１端末にマルチメディア・セッション情報を提供する。第２端末、即ち、ＲＴＳＰクライアントに対して、ゲートウェイは、ユーザの代わりにＲＴＳＰサーバとして動作し、第２端末はセッション制御にＲＴＳＰを用いる。

ゲートウェイは、入来したセッションが保留中であることを第２端末に知らせ、ゲートウェイのＲＴＳＰサーバ機能に接続することをＲＴＳＰクライアントに通知する。
つまり、ゲートウェイはＳＩＰおよびＲＴＳＰ双方に対してサーバとして動作し、第２端末ＲＴＳＰクライアントに接続するために通知メッセージを用いる。このメッセージは、トリガ・メッセージとして作用し、ユーザ生成コンテンツを第１端末から第２端末に送信することを可能にするために、ユーザからの旧来のＳＩＰクライアントおよびスタジオからのＲＴＳＰクライアントを接続できることを保証する。

一実施形態では、第１プロトコルはセッション開始プロトコル（ＳＩＰ）である。別の実施形態では、第１端末はSIP INVITEをゲートウェイに送信する。
別の実施形態では、第２プロトコルはリアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）である。

更に別の実施形態では、ゲートウェイは、第１端末の招待に応答して、第２端末に通知メッセージを送信し、第２端末を活性化して、第２端末とゲートウェイとの間に第２マルチメディア・セッションを設定する。

一実施形態では、前述の方法は、−第１端末が第１マルチメディア・セッション情報をゲートウェイに送信するステップと、−ゲートウェイが第１マルチメディア・セッション情報を第２端末に送信するステップとを備えている。

別の実施形態では、この方法は、−第２端末が第２マルチメディア・セッション情報をゲートウェイに送信するステップと、−ゲートウェイが第２マルチメディア・セッション情報を第１端末に送信するステップとを備えている。第１マルチメディア・セッション情報および／または第２マルチメディア・セッション情報は、別の実施形態では、セッション記述プロトコル（ＳＤＰ ; Session Description Protocol）を用いて送信される。

更に別の実施形態では、第１端末はＳＩＰクライアントを構成し、および／または第２端末はＲＴＳＰクライアントを構成する。
更に別の実施形態では、本発明は、マルチメディア・ストリームを第１端末から第２端末に送信する方法に関し、第１端末および第２端末がそれぞれ第１ゲートウェイおよび第２ゲートウェイに接続されている。これらのゲートウェイは、第１端末および第２端末の間でマルチメディア・セッションを設定することができる。この方法は、（ｉ）第１ゲートウェイが、第２端末とのマルチメディア・セッションを設定するために第１端末を準備し、第１プロトコルを第１端末の準備に用いるステップと、（ｉｉ）第１ゲートウェイが、第１端末と第２端末との間にマルチメディア・セッションを設定するように第２ゲートウェイを招待し、第２プロトコルによってこのマルチメディア・セッションを設定するステップと、（ｉｉｉ）第２ゲートウェイが、招待に応答して、第１端末とのマルチメディア・セッションを準備することを第２端末に通知し、第２端末の準備のために第１プロトコルを用いるステップと、（ｉｖ）招待に応答して、第１端末と第２端末との間にマルチメディア・セッションを設定するステップと、（ｖ）第１端末から第２端末にマルチメディア・ストリームを送信するステップとを備えている。

この実施形態では、ユーザ位置における第１のＳＩＰ−ＲＴＳＰゲートウェイ、およびスタジオ位置における第２のＳＩＰ−ＲＴＳＰゲートウェイの目的は、旧来のＳＩＰおよびＲＴＳＰ機能間において正しいＲＴＰ情報（ＩＰアドレス、ポート番号、ＳＤＰセッション記述子等）を交換することである。これによって、ＲＴＰストリームを設定し、ＳＩＰセッションによって制御することが可能となり、ユーザがＴＶスタジオをトリガして、ストリーミングされたユーザ生成コンテンツを読み出すことが可能になる。ＲＴＳＰプロトコルは、ＲＴＰストリームを制御するために用いることができる。

一実施形態では、第１プロトコルはリアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）とすることができる。別の実施形態では、第２プロトコルはセッション開始プロトコル（ＳＩＰ）である。

別の実施形態では、第２ゲートウェイは、第１ゲートウェイの招待に応答して、第２端末を活性化し第１端末と第２端末との間にマルチメディア・セッションを設定するために、通知メッセージを第２端末に送信する。

一実施形態では、本方法は、更に、−第１ゲートウェイが、第１プロトコルにカプセル化されているＳＤＰプロトコルを用いて第１端末からの第１マルチメディア・セッション情報を受信し、第２プロトコルにカプセル化されているＳＰＤプロトコルを用いて第１マルチメディア・セッション情報を第２ゲートウェイに送信するステップと、−第２ゲートウェイが、第１プロトコルにカプセル化されているＳＤＰプロトコルを用いて、第１ゲートウェイから第１マルチメディア・セッション情報を受信し、第１マルチメディア・セッション情報を第２端末に送信するステップとを備えている。

別の実施形態では、本方法は、更に、−第２ゲートウェイが、第１マルチメディア・セッション情報の受信に応答して、第１プロトコルにカプセル化されているＳＤＰプロトコルを用いて、第２端末からの第２マルチメディア・セッション情報を受信し、第２プロトコルにカプセル化されているＳＰＤプロトコルを用いて、第２マルチメディア・セッション情報を第１ゲートウェイに送信するステップと、−第２ゲートウェイが、第１プロトコルにカプセル化されているＳＤＰプロトコルを用いて、第２ゲートウェイから第２マルチメディア・セッション情報を受信し、第２マルチメディア・セッション情報を第１端末に送信するステップとを備えている。

第１端末から第２端末へのマルチメディア・ストリームの送信は、一実施形態では、ＲＴＳＰプロトコルによって制御される。
更に別の実施形態では、第１端末は、第１ゲートウェイに接続されているＲＴＳＰサーバを備えており、および／または第２端末は、第２ゲートウェイに接続されているＲＴＳＰクライアントを備えている。

更に別の態様では、本発明は、第１端末から第２端末にマルチメディア・ストリームを送信するシステムに関する。一実施形態では、このシステムは、少なくとも１つのゲートウェイに接続されている第１端末および第２端末を備えている。第１端末は、（ｉ）ゲートウェイに、第１端末との第１マルチメディア・セッションを設定するように招待する手段であって、第１マルチメディア・セッションを第１プロトコルによって制御する、手段と、（ｉｉ）第１マルチメディア・セッションにおいてマルチメディア・ストリームをゲートウェイに送信する手段とを備えており、ゲートウェイは、（ｉｉｉ）第１端末の招待に応答して、ゲートウェイと第２端末との間に第２マルチメディア・セッションを設定することを通知する手段であって、第２マルチメディア・セッションを第２プロトコルによって制御する手段と、（ｉｖ）前述の招待に応答して、第１マルチメディア・セッションを設定する手段と、（ｖ）マルチメディア・ストリームを第２端末に送信する手段とを備えている。

別の実施形態では、第１端末から第２端末にマルチメディア・ストリームを送信するシステムを提供する。このシステムは、第１ゲートウェイおよび第２ゲートウェイにそれぞれ接続されている第１端末および第２端末を備えている。これらのゲートウェイは、第１端末および第２端末の間にマルチメディア・セッションを設定することができる。第１ゲートウェイは、（ｉ）第２端末とのマルチメディア・セッションを設定するために第１端末を準備する手段であって、第１プロトコルを第１端末の準備に用いる手段と、（ｉｉ）第１端末との間にマルチメディア・セッションを設定するように第２ゲートウェイを招待する手段であって、第２プロトコルによってこのマルチメディア・セッションを設定する手段とを備えている。第２ゲートウェイは、（ｉｉｉ）招待に応答して、第１端末とのマルチメディア・セッションを準備することを第２端末に通知する手段であって、第２端末の準備のために第１プロトコルを用いる手段と、（ｉｖ）招待に応答して、第１端末と第２端末との間にマルチメディア・セッションを設定する手段とを備えている。

更に別の態様では、本発明は、本発明による方法において用いるために構成される第１端末を備えているデバイスに関する。このデバイスは、更に、本発明によるゲートウェイを備えている。これは、（運用業者の）ネットワークが本発明によるゲートウェイを備えていないまたはサポートしていないときに有利であると言える。このデバイスは、例えば、インターネットを通じて到達可能な自宅のコンピュータにライブ・ストリームを提供したい第１移動体デバイスとすることができる。

本発明の別の態様では、本発明は、本発明による方法において用いるために構成される第２端末を備えているデバイスに関する。第２端末は、
−第２プロトコル使用下において供給されるトリガを受信する手段と、
−第２端末へのトリガの供給に応答して、ゲートウェイとの第２マルチメディア・セッション情報の交換を開始する手段であって、開始および交換が、第３プロトコル使用下において実行され、第３プロトコルが第２プロトコルと異なるものである、手段と、
−第１マルチメディア・ストリームに関連付けられた第２マルチメディア・ストリームを受信する手段と、
を備えている。

好ましくは、このデバイスは、第２端末がＲＴＳＰクライアントを構成するように構成され、第２マルチメディア・ストリーム・セッション情報の交換を開始するために用いられる第３プロトコルは、ＲＴＳＰプロトコルである。これには、このデバイスが今やマルチメディア・ストリームの受信を制御し、これによってＲＴＳＰプロトコルによって提供される、利用可能なトリック・プレー機能を用いることができるという利点がある。

更に別の態様では、本発明は、また、端末またはゲートウェイのメモリにおいて実行すると、本発明による方法ステップを実行するように構成されているソフトウェア・コード部を備えている、コンピュータ・プログラム生産物に関する。

以下に添付図面を参照して、本発明について更に例示する。添付図面は、本発明による実施形態を模式的に示す。尚、本発明はこれら具体的な実施形態には全く限定されないことは言うまでもない。

図１は、本発明を用いることができるシステムの一例を示す。 図２は、ＳＩＰプロトコルを用いた情報の流れを簡略化した例を示す。 図３は、ＲＴＳＰプロトコルを用いた情報の流れの一例を示す。 図４は、本発明の実施形態の一例を示す。 図５ａは、本発明の実施形態例におけるＳＩＰクライアント、ＳＩＰ−ＲＴＳＰゲートウェイ、およびＲＴＳＰクライアント間における情報の流れを示す。 図５ｂは、本発明の別の実施形態例におけるＳＩＰクライアント、ＳＩＰ−ＲＴＳＰゲートウェイ、およびＲＴＳＰクライアント間における情報の流れを示す。 図５ｃは、 第1端末およびゲートウェイの双方が移動体デバイ内に構成されている場合の、本発明の実施形態例における、ＳＩＰクライアント、ＳＩＰ−ＲＴＳＰゲートウェイ、およびＲＴＳＰクライアント間における情報の流れを示す。 図６は、本発明において用いるために構成されるＩＭＳアーキテクチャを示す。 図７は、本発明において用いるために構成されるＩＭＳアーキテクチャ例における情報の流れを示す。

図１は、本発明を用いることができるシステムの一例を示す。自宅位置(home-location)において、例えば、セット・トップ・ボックスの中に構成された第１端末１が、ディスプレイ・デバイス、例えば、テレビジョンに接続されている。更に、第１端末はＴＶ信号２を受信する。ＴＶ信号２は、テレビジョン・スタジオによってブロードキャストされ、自宅にいるユーザの生のマルチメディア参加を提供する番組を提供する。一実施形態では、ユーザのマルチメディア参加は、例えば、端末に接続されているウェブ−カム３を用いて実現することができる。ウェブ−カムによって生成されたマルチメディア・ストリーム４は、ＩＰネットワーク５を通じて、ＴＶスタジオに位置する第２端末６にストリーミングされる。ＴＶスタジオでは、第２端末６がユーザ生成マルチメディア・ストリーム４を受信する。このようにして、ユーザからスタジオに生ビデオ・フィードを提供することができる。

このようなサービスでは、（ｉ）自宅にいるユーザが、自宅に設置されている第１端末１とスタジオに設置されている第２端末６との間でマルチメディア・セッションを設定し、マルチメディア・セッションがユーザ生成マルチメディア・コンテンツ４のスタジオへのストリーミングを可能にすること、（ｉｉ）スタジオが、自宅に設置されている端末によって送られたマルチメディア・ストリームを制御する（例えば、再生、一次停止、停止）ことができることが必要となる。

尚、図１に関して説明したように、自宅位置にあるシステムがマルチメディア参加を可能にすることは、種々の代替方法でも実現できることは言うまでもない。当業者であれば、第１端末１、ディスプレイ・デバイス、およびウェブ−カムを、例えば、パーソナル・コンピュータ、ディジタル・アシスタント（ＰＤＡ）、マルチメディア能力を備えた移動体電話機のような１つのデバイスに統合できることが理解できよう。同様に、スタジオにおけるシステムは、例えば、第２端末を備えているメディア・サーバであってもよく、第２端末は、マルチメディア・ストリーム読み出し(retrieval)のためにＲＴＳＰクライアントを備えている。あるいは、第２端末は、ミキサまたはトランスコーダ内に配置し、マルチメディア・ストリーム適応化に合わせて構成することもできる。

更に別の変形では、第２端末は、別の（自宅）位置に配置されたデバイスの一部であってもよく、ユーザ間マルチメディア・ストリーム送信に用いてもよい。第２端末を構成するデバイスは、専用セット・トップ・ボックス（ＳＴＢ）、パーソナル・コンピュータ、またはメディア・プレーヤ・ソフトウェアを内蔵する移動体電話機とすることもできる。

第１端末は、デバイスにおける機能ユニット、またはマルチメディア・ストリームの送信を管理（開始、取り決め、監視、および制御）することができるデバイスとみなすこともできる。同様に、第２端末も、デバイスにおける機能ユニット、またはマルチメディア・ストリームの受信を管理（開始、取り決め、監視、および制御）することができるデバイスとみなすこともできる。

ＩＭＳアーキテクチャでは、２つのＳＩＰクライアント、例えば、２台のＩＰフォン間においてマルチメディア・セッションを設定するおよび／または取り決めるために、ＳＩＰプロトコルが用いられる。ここで、クライアントという用語は、デバイスまたは端末の一定の能力を示すことができる。例えば、ＳＩＰクライアントとは、ＳＩＰプロトコルを用いるために構成されるデバイス、またはＳＩＰ能力を有する端末を指すことができる。

ＳＩＰプロトコルを用いたフローの一例を図２に示す。通例、第１ＳＩＰクライアントがSIP INVITE７を第２ＳＩＰクライアントに送る。一方、第２ＳＩＰクライアントは、SIP 200 OK８メッセージを第１ＳＩＰクライアントに送信することによって、この招待を受け入れる。双方のメッセージは、マルチメディア・セッションに関する情報を搬送することができる。この情報は、セッション記述プロトコル（ＳＤＰ）を用いて交換され、セッション記述プロトコルはＳＩＰプロトコルの中にカプセル化することができる。マルチメディア・セッション情報は、とりわけ、ＩＰアドレス、ＲＴＰストリームのポート番号、メディアのタイプ（音声、音響、ビデオ等）、およびコデック情報を含むことができる。その後、ＳＩＰクライアント間で、ＲＴＰプロトコル９を用いて、マルチメディアをストリーミングすることができる。

しかしながら、ＳＩＰはインタラクティブ・メディア・セッションを設定しサポートするように設計されている。ＳＩＰはアグリゲート・ストリーミング制御の一形態（即ち、異なる位置から多数のストリームを１回の制御セッションで制御する能力）を設けるが、ビデオ・オン・デマンド（ＶｏＤ）のようなストリーミング・アプリケーションにおいて用いられるＲＴＳＰプロトコルが提供するような効率的な制御には備えていない。ＲＴＳＰは、クライアントが、ＶＣＲライクなコマンド、例えば、再生、一次停止、停止、順方向スキップ、逆方向スキップ等を発行することによって、ストリーミング・メディア（ＲＴＳＰ）サーバをリモートに制御することを可能にし、更にサーバ上にあるファイルへの時間に基づくアクセスを可能にする。更に、旧来の機器にはＳＩＰクライアントが備えられていない場合もあるので、旧来の機器はＲＴＳＰの使用が必要となることもある。

図３は、ＲＴＳＰプロトコルを用いたフローの一例を模式的に示す。ＲＴＳＰクライアントとＲＴＳＰサーバとの間でＲＴＳＰマルチメディア・セッションを設定し制御する際、ＲＴＳＰセッションに必要な情報を両側に提供するために、クライアントとサーバとの間で標準的なＲＴＳＰメッセージ１０（OPTIONS, DESCRIBE, SETUP, PLAY）を交換する。ＲＴＳＰプロトコルの動作設計では、このようなセッションの設定を開始するのは、常にＲＴＳＰクライアントであって、ＲＴＳＰサーバではない。ＳＩＰと同様、ＲＴＳＰセッション情報もセッション記述プロトコル（ＳＤＰ）を用いて交換される。セッション記述プロトコルは、ＲＴＳＰプロトコルにカプセル化することができる。一旦セッションが設定されたなら、サーバからクライアント１１に、ＲＴＰプロトコルを用いて、マルチメディアをストリーミングすることができる。ＲＴＳＰによって、クライアントはストリーミングを制御することができる。
図４は、本発明による実施形態の一例を表すシステムの模式図を示す。この実施形態では、自宅に配置されている第１端末１２は、ＳＩＰクライアント１３を構成する。ＳＩＰクライアント１３は、ＳＩＰ−ＲＴＳＰゲートウェイ１５によってＳＩＰセッション１４を設定することができる。ＳＩＰ−ＲＴＳＰゲートウェイは、ＴＶスタジオにおいて第２端末１６も構成することができるデバイスに配置することもできる。第２端末１６は、ＲＴＳＰクライアントを構成する。

ユーザ側にある第１端末の（発信元）ＳＩＰクライアントに対して、ゲートウェイは（着信）ＳＩＰクライアントとして動作する。ゲートウェイは、第１端末からマルチメディア・セッションを受信できることを確認し、ユーザ側にある第１端末に、セッションの詳細およびＲＴＰポート番号について通知する。この第１マルチメディア・ストリーム・セッション情報は、ＳＤＰプロトコルを用いて交換することができる。ＳＤＰプロトコルは、ＳＩＰメッセージの中にカプセル化することもできる。

更に、ゲートウェイは、第２端末を特定するために用いられる、第１端末から受信した識別子をリゾルブ(resolve)して、第２端末のネットワーク・アドレスにすることができるとよい。このリゾルブ・プロセス(resolution process)は、ゲートウェイによって、またはゲートウェイの制御下において別のモジュールによって実行することができる。識別子は、既に第２端末の適したネットワーク・アドレスになっていてもよく、この場合、リゾルブは不要となる。

第１マルチメディア・ストリーム・セッション情報の交換開始に応答して、適したネットワーク・アドレスが供給された後に、ゲートウェイはトリガ・メッセージを第２端末に送ることができる。トリガ・メッセージは、ＲＴＳＰクライアントに、ゲートウェイとのＲＴＳＰセッションを開始するように命令する。ゲートウェイは、それ自体がトリガを送る必要はないが、別のモジュール（ショート・メッセージ・サービス・センタＳＭＳＣのような）に、ゲートウェイに代わってそうするように命令することもできる。

したがって、ＲＴＳＰクライアント１８を構成する第２端末に対して、ＳＩＰ−ＲＴＳＰゲートウェイはＲＴＳＰサーバとして動作し、これによって、ＲＴＳＰクライアントはＲＴＰストリーム１９のＲＴＳＰセッション制御を行うことができる。ＲＴＰストリーム１９は、第１端末（ＳＩＰクライアント）から送信され、第２端末（ＲＴＳＰクライアントを構成する）において関連付けられた第２のマルチメディア・ストリームとして受信される。

第１マルチメディア・ストリームは、関連付けられた第２マルチメディア・ストリームと同じマルチメディア・ストリームであってもよい。その場合、コンテンツは直接第１端末から第２端末にストリーミングされる。送信された第１ストリームは、関連付けられた第２のストリームとして第２端末に送信される前に、ＲＴＳＰサーバの制御下でバッファされない。これには、コンテンツが「ライブ・モード」(live modus)で第２端末に提示されているという利点がある。このモードでは、ＲＴＳＰクライアントのトリック・プレー機能（一次停止、早送り等）は、ストリームを制御するために用いることができない。

図５（ａ）は、ＳＩＰクライアント（第１端末内に構成されている）、ＳＩＰ−ＲＴＳＰゲートウェイ、およびＲＴＳＰクライアント（第２端末内に構成されている）間における情報の流れの実施形態例を示す。第１ステップ２０において、第１端末におけるＳＩＰクライアントによって、第１マルチメディア・ストリーム・セッション情報（ＳＩＰセッション）の交換が開始される。第１端末は、SIP INVITEをゲートウェイに送り、第１マルチメディア・ストリームを第２端末にストリーミングしたいことを示す。更に別の変形では、第１端末は、Ｈ．３２３またはＭＰＥＧ−４配信マルチメディア統合フレームワーク（ＤＭＩＦ ; Delivery Multimedia Integration Framework）デフォルト・シグナリング・プロトコル（ＤＤＳＰ ; Default Signaling Protocol）のような別のプロトコルを用いて、第１マルチメディア・ストリーム・セッション情報の交換を開始することもできる。
第２ステップ２１において、ゲートウェイは招待を受け入れ、これに応答して、ＳＩＰ−ＲＴＳＰゲートウェイとのＲＴＳＰセッションを開始するためのトリガを第２端末に供給する。任意に、ゲートウェイは、トリガを供給する前に、第１端末におけるＳＩＰクライアントが送信した第２端末の識別子を最初にリゾルブしなければならない場合もある。第２端末のネットワーク・アドレスを入手するためのリゾルブ・プロセスは、ＤＮＳ、ＥＮＵＭ、またはその他のデータベース・クエリを含むこともある。

ゲートウェイは、ゲートウェイが生成した識別子のような、余分な情報をトリガに加えることができる。この識別子は、ゲートウェイが、第２端末からの入来ＲＴＳＰ要求（このＲＴＳＰ要求は、第２マルチメディア・ストリーム・セッション情報の交換の一部である）をＳＩＰセッションと関連付けるために用いることができる。トリガにおけるこの情報は、ＲＴＳＰ ＵＲＩに含めてもよい。

このトリガは、トリガ・メッセージの形態をなすことができ、例えば、ＳＩＰコンテンツ・非ダイレクト要求（ＲＦＣ４４８３）、ショート・メッセージ・サービス（ＳＭＳ）メッセージ、または非構造化補遺サービス・データ（ＵＳＳＤ ; Unstructured Supplementary Service Data）メッセージである。更に、トリガ・メッセージは、ＲＴＳＰクライアントにおける企業固有のアプリケーション・プログラミング・インターフェース（ＡＰＩ）または制御インターフェース、例えば、ＳＯＡＰを用いるウェブ・サービス・インターフェース、リモート・プロシージャ・コール（ＲＰＣ）、またはテルネット・インターフェースを用いて、ＲＴＳＰクライアントに受け渡すこともできる。このようなインターフェースは、マルチメディア・ストリームを要求する「手動ユーザ入力」をシミュレートすることができる。

入来するトリガ・メッセージは、トリガ・プロトコル・スタック（例えば、ＳＯＡＰスタックまたはＲＰＣスタック）によって解釈することができる。トリガ・プロトコル・スタックは、ＲＴＳＰクライアントにマルチメディア・ストリームを要求するように命令する、または別のモジュールにそうするように命令するように構成するとよい。あるいは、第２端末が、Microsoft Media Server プロトコルＭＭＳ、またはハイパーテキスト・トランスファ・プロトコルＨＴＴＰのような別のプロトコルを用いて、マルチメディア・ストリームを要求してもよい。

その後、第３ステップ２２において、ゲートウェイは、ＳＤＰ情報をＲＴＳＰクライアントに送信し、ＲＴＳＰクライアントから、ＲＴＰストリームを送るべき正しいＲＴＰポートを読み出すことによって、第２端末内に構成されているＲＴＳＰクライアントとの第２マルチメディア・セッション情報の交換を処理する。この交換の間、ゲートウェイは命令をＲＴＳＰクライアントに与える。例えば、命令には、（関連付けられた第２の）マルチメディア・ストリームを受信するために用いるべきＲＴＰポート番号、あるいは、例えば、ストリームを読み出すことができるマルチキャスト−またはその他のアドレスが含まれる。

第４ステップ２３において、ゲートウェイは、ＳＩＰ２００ ＯＫメッセージを用いて、ＳＩＰクライアントに対してＳＩＰセッションを確認し、ＳＩＰクライアントに、第１マルチメディア・ストリームを送信するために用いられるＲＴＰポート番号を供給し、ＳＤＰ情報を確認する。最後に、第５のそして最後のステップ２４において、第１端末はＲＴＰマルチメディア・ストリームを第２端末にストリーミングし始める。

組み合わせＳＩＰ／ＲＴＳＰセッション（図５（ａ）には示されていない）の終了は、前述したこのようなセッションの開始と同様に処理することができる。（第１端末の）ＳＩＰクライアントがセッションを終了したいことを示すと、ゲートウェイはSIP BYEメッセージをRTSP REDIRECTメッセージ（位置ヘッダ(location header)なし）に変換することができる。RTSP REDIRECTメッセージは、更新されたバージョンのＲＴＳＰのドラフトにおいて見出すことができる（Schulzrinne et alによる２００７年１１月１９日付けReal Time Streaming Protocol 2.0のインターネット・ドラフトＲＦＣ２３２６バージョン１６を参照のこと）。（第２端末）のＲＴＳＰクライアントがセッションを終了したいことを示すと、ゲートウェイは、RTSP TEARDOWNメッセージをSIP BYEメッセージに変換する（すると、SIP BYEメッセージは、続いて、第１端末内に構成されているＳＩＰクライアントに送られる）。

更に別の実施形態では、マルチメディアのストリーミングは、最初にゲートウェイによって開始することもできる。その場合、ゲートウェイは、第２端末内に構成されているＲＴＳＰクライアントに、トリガ・メッセージを供給し、それ自体のＳＩＰクライアント機能によって、第１端末のＳＩＰクライアントにＳＩＰセッションを設定するように招待する。ＳＩＰクライアント、ゲートウェイ、およびＲＴＳＰクライアント間における情報の流れを、図５（ｂ）に模式的に示す。

更に別の実施形態では、第１端末内にゲートウェイを設置してもよい。その場合、第１マルチメディア・ストリーム・セッション情報の交換に用いられる第１プロトコルは、単なる内部プロトコルでよい。次いで、第１端末のユーザ・インターフェースの刺激(stimulus)によって、セッションをトリガすることができる。この方式を図５（ｃ）に模式的に示す。図５（ｃ）では、第１端末を移動体デバイス内に構成してもよい。あるいは、第１端末によって受け取られる刺激は、外部ソースから来てもよい。その場合、例えば、移動体デバイスが受信したＳＭＳメッセージがセッションをトリガすることができる。

図６は、ＥＴＳＩ ＴＩＳＰＡＮによって規定された、ＩＭＳベース・ＩＰＴＶアーキテクチャにおける本発明の実施態様を示す。このアーキテクチャは、例えば、第１端末（ＵＥ１ ６０１）に命令するＩＭＳベース（ユーザ生成）コンテンツ・サービスの第１加入者が、彼のマルチメディア・ストリームを、第２端末（ＵＥ２ ６０２）に命令する第２加入者にストリーミングしたいというような状況に用いることができる。

この実施形態では、本発明によるゲートウェイは、分散型であり、第１マルチメディア・ストリーム・セッション・情報のＵＥ１との交換は、サービス制御機能（ＳＣＦ６０３）によって処理されるのが通例であり、第２マルチメディア・ストリーム・セッション情報のＵＥ２との交換は、メディア機能（ＭＦ６０５）によって処理される。ＵＥ２に対するトリガのプロビジョニングは、ＳＣＦ６０３によって制御および／または実行することができる。変形では、ＭＦにおけるメディア制御機能ＭＣＦ６０６がトリガを送り、どのようにマルチメディア・ストリームを配信するかについてメディア配信機能ＭＤＦ６０７に命令することができる。この例では、第１加入者がＳＩＰを用いて、第１マルチメディア・ストリームを送信するためのマルチメディア・セッションを設定し、一方第２加入者はＲＴＳＰを用いて、関連付けられた第２のマルチメディア・ストリームを受信する。

第１加入者が第２加入者にマルチメディア・ストリームを受信するように招待するために、図７のフロー図に示す以下のステップを実行する。第１ステップ７０１において、第１加入者（ＵＥ１ ６０１を用いる）が、ＩＭＳコア６０４を通じてサービス制御機能ＳＣＦ６０３とのＳＩＰセッションを設定することによって、彼のマルチメディア・ストリームを第２加入者（ＵＥ２ ６０２を用いる）と共有することを望む場合があり得る。SIP INVITE要求は、例えば、ＵＲＩ収容リストを用いた、加入者端末アドレスのリストを含むことができ、あるいはセッション外部で、例えば、ＸＭＬコンフィギュレーション・アクセス・プロトコルＸＣＡＰを用いて、サービス制御機能（ＳＣＦ）にリストを送ることもできる。ＸＭＬコンフィギュレーション・アクセス・プロトコルＸＣＡＰの識別子は、SIP INVITE要求に含めることができる。あるいは、コミュニティ（非公開ユーザ・グループ）ＴＶのようなサービスの場合、多数の加入者に一度にアドレスする必要があるので、SIP INVITE要求はコミュニティに対する参照だけを、コミュニティ（非公開ユーザ・グループ）識別子の形態で備えていればよい。このコミュニティ識別子は、多数のトリガを全てのコミュニティ加入者に供給する前に、リゾルブする必要がある。

第２ステップ７０２において、ＳＣＦは、バック・ツー・バック・ユーザ・エージェント（Ｂ２ＢＵＡ）として動作することができ、可能ならばＩＭＳコアを通じて、セッション要求をメディア制御機能ＭＣＦ６０６に送る。ＭＣＦへのセッション要求は、どこでマルチメディア・ストリームを受信するか、そしてどのようにそれを配信するかについての情報を含む。あるいは、ＳＣＦは、ＭＥＧＡＣＯ／Ｈ．２４８またはＳＯＡＰのような別のプロトコルをＭＣＦに宛てて用いてもよい。

第３ステップにおいて、ＭＣＦは、第１マルチメディア・ストリームのためのＲＴＰポートおよびアドレスを設定し、それをＲＴＳＰ ＵＲＩと関連付けるために、マルチメディア・ストリーム情報をＭＤＦ６０７に送ることができる。ＭＣＦは、例えば、ＳＩＰまたはＭＥＧＡＣＯ／Ｈ．２４８を用いて、マルチメディア・ストリーム情報を交換することができる。

第４ステップ７０４において、ＳＣＦへのＭＣＦ応答は、第１マルチメディア・ストリームを送信すべきアドレスまたはＲＴＰポート、および／またはゲートウェイのＲＴＳＰサーバ機能に接触するためにＵＥ２によって用いられるＲＴＳＰ ＵＲＩのような情報を含むことができる。

第５ステップ７０５において、第１マルチメディア・ストリーム・セッション情報の交換の間に、そのＳＩＰクライアント機能を用いて、ＳＣＦはＵＥ１に応答を返送する。
第６ステップ７０６において、ＵＥ１ ６０１は、ＭＣＦによって指示された仕方および／または場所に、マルチメディア・ストリームを送信する。

第７ステップ７０７において、ＳＣＦは、ＭＣＦからの情報を用いて、ＵＥ２にトリガを供給する。このトリガは、ＳＩＰコンテンツ間接要求とすることができる。この要求は、ＭＦによって供給されたＲＴＳＰ ＵＲＬ、またはゲートウェイにどのように接触するかについてのＵＥ２のための別の指示を含むことができる。また、トリガは、ＵＥ２との既存のＳＩＰセッション内で、またはＳＩＰ参照(REFER)要求を用いることによって送ることもできる。

第８ステップ７０８において、招待されたＵＥ２ ６０２は、ＳＩＰコンテンツ間接要求に応答して、マルチメディア・コンテンツ（関連付けられた第２のマルチメディア・ストリーム７０９）を受信するために、ＭＤＦとのＲＴＳＰセッションを開始する（図７における７０８の第２マルチメディア・ストリーム・セッション情報の交換）。ＲＴＳＰ ＵＲＩは、ＭＤＦがＲＴＳＰセッションをＳＩＰセッションと関連付けるために、トリガ・メッセージの中に与えられた識別子を含むことができる。ＲＴＳＰセッション（関連付けられた第２のマルチメディア・ストリーム）は、ユニキャストまたはマルチキャストでもよい。マルチキャストを用いる場合、ＭＦはＵＥ１の入来（ユニキャスト）第１マルチメディア・ストリームを、マルチキャスト・ストリームとして配信する。すると、ＵＥ２は、確立されたＲＴＳＰセッションに応答して、関連付けられた第２のマルチメディア・ストリームを受信するためにＩＧＭＰ要求を送る。

第９ステップにおいて、ＳＣＦがSIP SUBSCRIBEメッセージをＭＦ（図７には示されていない）に送ることによって関心を示した場合、ＭＦは、ＲＴＳＰセッションのステータスをＳＣＦに通知し続けるために、SIP NOTIFYメッセージをＳＣＦに送ることができる。

本発明は、以上に記載した実施形態に限定されるのではなく、実施形態は、添付した請求項の範囲内で様々に変化してもよい。例えば、スタジオという用語は、職業用放送スタジオだけを意味するように解釈してはならない。本明細書の意味の範囲内では、スタジオは、マルチメディア機能を提供することができるスタジオと同様の全てのシステムに関係があり、例えば、パーソナル・コンピュータ・システム、または自宅位置にいるユーザにライブ・コンテンツをストリーミングすることができ、応答してユーザからのユーザ生成コンテンツを受信することができるその他のマルチメディア・システムにも関係がある。

Claims (16)

1. 第１端末から第１のマルチメディア・ストリームを送信し、第２端末において、関連付けられた第２のマルチメディア・ストリームを受信する方法であって、前記第１端末および前記第２端末は、前記第１マルチメディア・ストリームの送信および前記関連付けられた第２マルチメディア・ストリームの受信を可能にするために、少なくとも１つのゲートウェイに接続されており、前記方法は、
   −第１プロトコルを用いて、前記第１端末と前記ゲートウェイとの間で第１マルチメディア・セッション情報の交換を開始するステップと、
   −第２プロトコルを用いて、前記第２端末と前記ゲートウェイとの間で第２マルチメディア・セッション情報の交換を開始するために、トリガを前記第２端末に供給するステップと、
   −前記トリガの供給に応答して、前記第２端末が、第３プロトコルを用いて、前記第２端末と前記ゲートウェイとの間で第２マルチメディア・セッション情報の交換を開始する、ステップであって、前記第３プロトコルが前記第２プロトコルとは異なるものである、ステップと、
   −前記第１端末から第１マルチメディア・ストリームを送信し、前記第２端末において関連付けられた第２マルチメディア・ストリームを受信するステップと、
   を備えている、方法。
2. 請求項１記載の方法において、前記第１マルチメディア・セッション情報の交換は、前記第１端末に前記第２マルチメディア・セッション情報の少なくとも一部を供給することを含み、前記第１端末からの前記第１マルチメディア・ストリームの送信は、前記供給に応答して開始される、方法。
3. 請求項１または２記載の方法において、前記第２マルチメディア・セッション情報の交換は、前記第２端末に前記第１マルチメディア・セッション情報の少なくとも一部を供給することを含み、前記関連付けられた第２マルチメディア・ストリームの前記第２端末による受信は、前記供給に応答して開始される、方法。
4. 請求項１から３記載の方法において、前記第１プロトコルは、ピア・ツー・ピア型プロトコル、好ましくは、セッション開始プロトコル（ＳＩＰ）である、方法。
5. 請求項１から４記載の方法において、前記第３プロトコルは、クライアント−サーバ型プロトコル、好ましくは、リアル・タイム・ストリーミング・プロトコル（ＲＴＳＰ）である、方法。
6. 請求項１から５記載の方法において、トリガを前記第２端末に供給する前記ステップは、前記ゲートウェイによって開始される、方法。
7. 請求項１から６記載の方法において、前記第１マルチメディア・セッション情報の交換は、前記第２端末の識別子の前記ゲートウェイへのプロビジョニングを含む、方法。
8. 請求項７記載の方法において、前記トリガの前記第２端末へのプロビジョニングの前に、前記第２端末の識別子をリゾルブしてネットワーク・アドレスを得る追加のステップを備えている、方法。
9. 請求項１から８記載の方法において、前記第１プロトコルおよび前記第２プロトコルが同一である、方法。
10. 請求項１から９記載の方法において、前記第１マルチメディア・ストリームは、前記関連付けられた第２マルチメディア・ストリームと同じマルチメディア・ストリームである、方法。
11. 第１端末から第１のマルチメディア・ストリームを送信し、第２端末において、関連付けられた第２のマルチメディア・ストリームを受信するシステムであって、
    少なくとも１つのゲートウェイに接続されている第１端末および第２端末を備えており、
    前記第１端末は、（ｉ）第１プロトコルを用いて、前記ゲートウェイと第１マルチメディア・セッション情報を交換する手段と、（ｉｉ）第１マルチメディア・ストリームを送信する手段とを備えており、
    前記ゲートウェイまたは第１端末は、（ｉｉｉ）第３プロトコルを用いて前記第２端末と前記ゲートウェイとの間で第２マルチメディア・セッション情報の交換を開始するために、第２プロトコルを用いて第２端末をトリガする手段を備えており、
    前記第２端末は、（ｉｖ）第２プロトコルを用いて、トリガを受信する手段と、ｖ）該トリガに応答して、第３プロトコルを用いて、前記ゲートウェイと第２マルチメディア・セッション情報の交換を開始する手段と、（ｖｉ）前記第１マルチメディア・ストリームと関連付けられた第２マルチメディア・ストリームを受信する手段とを備えている、システム。
12. 請求項１１記載のシステムにおいて用いるために構成されるゲートウェイであって、
    −第１プロトコルを用いて、前記ゲートウェイと第１マルチメディア・セッション情報を交換する手段と、
    −前記第２端末をトリガする手段であって、トリガが第２プロトコルを用いて供給され、これに応答して、前記第２端末が、前記ゲートウェイとの第２マルチメディア・セッション情報の交換を開始することができる、手段と、
    −前記第３プロトコルを用いて、前記第２端末と第２マルチメディア・セッション情報を交換する手段であって、前記第３プロトコルが前記第１プロトコルとは異なるものである、手段と、
    を備えている、ゲートウェイ。
13. ＩＭＳネットワーク・アーキテクチャに組み込まれた、請求項１２記載のゲートウェイであって、前記第１プロトコルがＳＩＰであり、前記第３プロトコルがＲＴＳＰであり、
    −第１マルチメディア・セッション情報を交換する手段は、ＩＭＳ内におけるサービス制御機能の一部であり、
    −前記第２端末をトリガする前記手段は、ＩＭＳ内におけるサービス制御機能の一部であり、
    −第２マルチメディア・セッション情報を交換する手段は、ＩＭＳ内におけるメディア機能の一部である、ゲートウェイ。
14. 請求項１１記載のシステムにおいて用いるために構成される第１端末を備えているデバイスであって、更に、請求項１２または１３記載のゲートウェイを備えている、デバイス。
15. 請求項１１記載のシステムにおいて用いるために構成される第２端末を備えているデバイスであって、前記第２端末が、
    −第２プロトコル使用下において供給されるトリガを受信する手段と、
    −前記第２端末への前記トリガの供給に応答して、前記ゲートウェイとの第２マルチメディア・セッション情報の交換を開始する手段であって、前記開始および交換が、第３プロトコル使用下において実行され、前記第３プロトコルが前記第２プロトコルと異なるものである、手段と、
    −第１マルチメディア・ストリームに関連付けられた第２マルチメディア・ストリームを受信する手段と、
    を備えている、デバイス。
16. 端末またはゲートウェイのメモリにおいて実行すると、請求項１から１０のいずれかに記載の方法ステップを実行するように構成されているソフトウェア・コード部を備えている、コンピュータ・プログラム生産物。

Images