JP2006518948A

JP2006518948A - マルチメディア・ストリーミングにおけるストリーミング品質適合と制御機構のシグナリング方法

Info

Publication number: JP2006518948A
Application number: JP2006500321A
Authority: JP
Inventors: バリスアクス，エムレ; ダニーロディエゴクルチョ，イゴール; レオン，デイビッド; バルサ，ビクトール; ワン，ル−シャン
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2003-02-13
Filing date: 2004-02-13
Publication date: 2006-08-17
Also published as: US20040196852A1; KR100759954B1; KR20050106592A; WO2004072766A3; US7558869B2; CA2515952A1; EP1593107A4; EP1593047A4; EP1593107A2; JP2006525693A; EP1593047A2; EP1593046A2; WO2004072765A3; WO2004072764A2; US20040193762A1; WO2004072764A3; US20040196849A1; WO2004072765A2; WO2004072766A2

Abstract

データ配信処理の適合に関して、マルチメディアストリーミングサービスにおけるクライアントとサーバ間のシグナリングとネゴシエーションの方法。データ配信において使用される適合機構または機能を確かめるために、パーティの１つは、他のパーティにサポートする適合機構または機能を示す情報を与える。その情報を受信するとすぐに、その別のパーティは、明確なＲＴＳＰ応答を使用して、その機構または機能のサポートを示す。サーバかクライアントは、ネゴシエーションを開始する。シグナリングとネゴシエーションの実行は、特に３ＧＰＳＳセッションにおける、ＡＶＰＦ使用、ＲＴＰ再伝送ペイロードフォーマット使用、および、ＳＰＴＰ使用をカバーする。

Description

本発明は、一般にマルチメディア・ストリーミングに関し、特に、ストリーミング品質適合および制御機構のシグナリングに関する。

マルチメディア・ストリーミング・サービスにおいては、３つの参加者：ストリーミング・サーバ、ストリーミング・クライアント、そのサーバとクライアント間の接続を与える根本的なネットワーク、が含まれる。そのサーバは、マルチメディア・ストリーミング・コンテンツをクライアントに配信する機能を提供する。その目的のために、クライアントとサーバは、機能交換（capability exchange）、コンテンツ配信方法のネゴシエーション（negotiation）、コンテンツ配信制御等の方法に関して、ネットワーク上を互いに通信する。そのような情報交換は、明確なネットワーク・プロトコールを介して実行される。

うまく構成され、開始されるマルチメディア・ストリーミング・セッションのために、サーバとクライアントは、プロトコールの最小の組をサポートする必要があり、その最小の組は、サーバによって標準プロトコールとして選択される。そのようなサービスの例は、３ＧＰＰＴＳ２６．２３４Ｖ５．１．０、“透過的エンドツーエンドパケット切替ストリーミングサービス（ＰＳＳ：Transparent End-to-End Packet Switched Service）；プロトコールとコーデック（リリース５）”、２００２年６月、（以後ＴＳ２６．２３４として参照される。）である。さらに、サービスがデータ配信と再生性能の観点から成功するために、そのサービスにおけるデータ配信制御機構も明確でなければならない。基礎をなすネットワーク特性における挙動の変化をもたらすために、そのような機構は、データ配信処理を適合させるために使用される。

適合機構（adaptation mechanism）または機能（capability）の明白な制御位置に基づく３つの適した適合処理は次のようである：

クライアント−ドリブン適合
クライアントは、適合機能または機能の制御を有し、適合に必要な決定を行う。その決定は、ネットワーク、サーバ、または、サービス規定内の他の情報資源から集められた情報に基づいている。

サーバ−ドリブン適合
サーバは、適合機能または機能の制御を有し、適合に必要な決定を行う。その決定は、ネットワーク、クライアント、または、サービス規定内の他の情報資源から集められた情報に基づいている。

共同の適合
適合機能または機能の制御は、サーバとクライアント間に分配される。サーバとクライアントの両方は、ネットワーク、サーバ、クライアント、または、サービス規定内の他の情報資源から集められた情報に基づいて、適合に必要な行動をとる。

サービス状況において、上述の各適合処理の状況の中で規定される１つ以上の適合機構または機能がある。各適合機構または機能はサービス内で標準化されるケースがあるが、サーバまたはクライアントが実行することはオプションのままであるケースがある。

それ故、機能識別機構が、サポートされる適合機構または機能、および、適合機能シグナリングおよびネゴシエーション機構を識別し、かつ、サーバとクライアントが、サービス状況の中で規定された適合機構または機能の特定の組の使用に同意するための確かな必要性がある。

従来技術では、３ＧＰＳＳ（リリース５）の付録Ｇは、シグナリング機構を定義し、そのシグナリング機構は、その使用を信号で送り、および、パラメータをサポートするために使用されるが、これは、完璧な解決策となっていない。

本発明は、データ配信処理の適合に関して、マルチメディア・ストリーミング・サービスにおけるクライアントとサーバ間のシグナリング（signaling）およびネゴシエーション（negotiation）の方法を提供する。その方法は、機能交換機構またはマルチメディアストリーミング制御プロトコールを使用することによって実行される。本発明によれば、シグナリングおよびネゴシエーションの方法は、特定の３ＧＰＳＳセッションにおけるＡＶＰＦ（ＰＴＣＰベースフィードバック用拡張ＲＴＰプロファイル）使用；特定の３ＧＰＳＳセッションにおけるＲＴＰ再伝送ペイロードフォーマット使用；かつ、特定の３ＧＰＳＳセッションにおけるＳＲＴＰの使用において実行される。

本発明によれば、その方法は、マルチメディア・ストリーミング・サービスが明確で、および／または、標準化された適合処理を有し、かつ、各適合処理が、適合機能または機能を与えるツールである明確で、および／または、標準化された機構から構成されるとき実行され、そしてその機構または機能は、適合機能性または機能性を調整するためのツールとなる。さらに、各適合機構または機能は、サーバ状況において、明確、および／または、標準化され、また、サーバとクライアント間でよく知られた属性を有する。

従って、本発明は、マルチメディア・ストリーミング・サービスにおけるクライアントとサーバ間のシグナリングおよびネゴシエーションの方法であって、データ配信のための前記サービスにおける複数の適合機構または機能は、クライアントによってサポートされ、各適合機構または機能は、属性を有する。その方法は：
クライアントによってサポートされる適合機構または機能を規定する属性を示す情報を出力するクライアントと、
出力情報に基づいて１つ以上の属性を選択するサーバと、
そのサーバによって選択される１以上の属性によって規定される１以上の適合機構または機能を知ることを、クライアントに許すために、選択属性を示す情報をさらに出力するサーバとを備える。

本発明によれば、クライアントは、機能交換機構を介して、または、マルチメディアストリーミング制御プロトコールを介して上述の情報を出力する。

あるいは、上記方法は、
２つのパーティの１つによって、２つのパーティの他の１つへ１以上の適合機構または機能を情報を出力し、
その情報に応答して、他のパーティから、そのパーティへメッセージを搬送し、１以上の適合機構または機能のサポートを認識する。

クライアントとサーバのどちらかは、ネゴシエーションを開始できる。クライアントがネゴシエーションを開始する場合、クライアントは、サーバに複数の属性を出力する；そして、サーバは、そのサポートを認識するための出力情報に基づいて１以上の出力情報を選択する。

本発明によれば、データ配信処理の適合に関して、マルチメディア・ストリーミング・サービスにおけるクライアントとサーバ間のシグナリングおよびネゴシエーションの方法は、機能交換機構またはマルチメディアストリーム制御プロトコールを介して実行される。そのデータ配信処理の適合は、１つ以上の適合機構または機能の１つ以上の属性に基づいており、その１つ以上の属性は、マルチメディア・ストリーミング・サービスにおける適合処理を決定するために使用される。

シグナリングおよびネゴシエーションは、機能交換機構を介して実行されるとき、その手続は以下のように述べられる。

− クライアントは、機能交換機構のために規定されたその機能プロファイルの中で、クライアントによって実行される適合機構または機能の属性を宣言する；

− サーバは、機能プロファイルを獲得する；

− サーバは、どの適合機構または機能がクライアントによって実行されるか知るので、サーバは、適合処理に衝突しない属性のサブセットを選択する。選択された属性のサブセットによれば、サーバはマルチメディアセッション記述を調整し、そのセッション記述をクライアントへ宣言する。

− セッション記述に基づいて、クライアントは、特定のマルチメディアセッションのためにサーバによって実行された適合機構または機能選択を知る。クライアントは、デフォルトでセッション記述の中で宣言された適合機構と機能を受諾する。なぜなら、宣言された記述は、クライアントによって宣言された属性または適合機構機能のサブセットを含むからである。

シグナリングおよびネゴシエーションがマルチメディアストリーミング制御プロトコールを介して実行されるとき、その手続は以下のように述べられる。

− クライアントは、クライアントによって実行される適合機構または機能の属性を、ストリーミングセッションの制御のために規定されたマルチメディアストリーミング制御プロトコールの中に含める。

− これらの属性に基づいて、サーバは、どの適合機構または機能が、クライアントによって実行され、または、要求されるかを知る。サーバは、適合処理と衝突しない属性のサブセットを選択し、かつ、クライアントに対して、選択または未選択属性を信号伝達する。制御通信の現段階に依存して、サーバは、選択された属性に従って、マルチメディアセッション記述を調整し、および、クライアントにセッション記述を宣言し、かつ、

− サーバからの応答に基づいて、クライアントは、どの属性がサーバに選択されるかを知る。クライアントはデフォルトでサーバによって選択された属性により規定される適合機構または機能を受諾する。なぜなら、選択された適合機構または機能は、クライアントによって宣言された適合機構または機能のサブセットであるからである。

本発明に従って、シグナリングおよびネゴシエーションの方法は、ＴＳ２６．２３４または後のリリースに基づいて、マルチメディア・ストリーミング・サービスの中で実行され得る。

本実装は、次の機構をシグナリングし、および、ネゴシエーションする規定をカバーする。

− 特定の３ＧＰＳＳセッションにおけるＡＶＰＦ使用（例えば、ＩＥＴＦ draft-ietf-avt-rtcp-feedback-04:“ＲＴＣＰベースフィードバックのための拡張ＲＴＰプロファイル（Extended RTP profile for RTCP-based Feedback）（ＲＴＰ／ＡＶＰＦ）”）オット（Ott）等、２００２、ここでは、draft-avpf-04として参照する）；

− 特定の３ＧＰＳＳセッションにおけるＲＴＰ再伝送ペイロードフォーマット（例えば、ＩＥＴＦ draft-ietf-avt-rpt-retransmission-05:“ＲＴＰ再伝送ペイロードフォーマット（RTP Retransmission Payload Format）”、レイ（Rey）等、２００２、ここでは、draft-retransmission-05として参照する）；

− 特定の３ＧＰＳＳセッションにおけるＳＰＴＰ使用（例えば、ＩＥＴＦ draft-ietf-avt-srtp-05:“セキュアリアルタイムトランスポートプロトコール（The Secure Real-time Transport Protocol）”、バウガー（Baugher）等、２００２、ここでは、draft-srtp-05として参照する）。

Ｉ．特定の３ＧＰＳＳセッションにおけるＡＶＰＦ使用
draft-avpf-04で定義されるＡＶＰＦがクライアントによってサポートされ、かつ、クライアントはＡＶＰＦサポートを信号伝達する場合、そのとき、サーバは、適合処理の中で、draft-avpf-04で定義されるＡＶＰＦ特性のいかなる組合せを使用しても良い。ＡＶＰＦのサポート可能な特性（例えば、即時のフィードバックモード、早期のＲＴＣＰパケットサポート等）のための明確な機構識別子がある場合、クライアントは、その特性の各々を分割して信号伝達する。

属性“AVPFSupport”を、ＲＤＦ（リソース記述フレームワーク）スキーマボキャブラリで規定し、映像および音声メディアのためのdraft-avpf-04で規定されたＡＶＰＦのサポートを信号伝達する。

属性“UnSupportedAdaptationSupport”を、適合機構または機能としてＲＤＦスキーマボキャブラリで規定し、その属性は、サーバではなくクライアントでサポートされる。

属性“SupportedAdaptationSupport”を、適合機構または機能としてＲＤＦスキーマボキャブラリで規定し、その属性は、サーバでもサポートされる。

“x-avpfsupport”を、明確なＳＤＰ（セッション記述プロトコール）属性とし、それは、ＳＶＰＦがサポートされる場合、ＳＤＰの音声および映像（または、両方のメディアタイプでの使用のためのセッションレベル）メディア区分に含まれる。

“x-unsupportedadaptationsupport”を明確なＳＤＰ属性とし、それは、サポートされる場合、ＳＤＰ（セッションまたはメディア層）に含まれる。

“x-supportedadaptationsupport”を明確なＳＤＰ属性とし、それは、サポートされる場合、ＳＤＰ（セッションまたはメディア層）に含まれる。

Ａ．適した機能交換機構を介したシグナリングおよびネゴシエーション
− クライアントは、RTSP DESCRIBE要求を、機能交換サーバに存在するクライアント機能情報を指すＵＲＩと共にサーバに送る。

− サーバは、機能交換サーバからのクライアントの機能宣言を取ってくる。その宣言は、図１に示すように、クライアント側のストリーミング機能のための部分を含む。

その宣言におけるボールド線は、クライアントの適合機構サポート機能を表す。属性値が正（ＴＲＵＥ）である場合、機構または機能はクライアントによってサポートされるということに注意が必要である。逆に、属性値が誤（ＦＡＬＳＥ）である場合、その機構または機能は、クライアントによってサポートされない。例えば、属性AVPFsupprtが正（ＴＲＵＥ）である場合、クライアントは、特定のセッション内で映像および音声メディアコンポーネントのためのＡＶＰＦサポートを有するということを宣言する。

− この機能を理解して、サーバは、ＡＶＰＦ機能とSupportedAdaptationSupport機能を含んだクライアントに送られるべきＳＤＰ記述を調整する。ＳＤＰ記述は、図２に示される。サーバは、UnsupportedAdaptationSupportに基づいてＳＤＰ属性を含めない。というのは、サーバは、そのためのサポートを有さないからである。ＳＤＰ記述におけるボールド線は、ＡＶＰＦの使用と、SupportedAdaptationSupportのためのサポートを指示する。

ＳＤＰ記述を受け取ることによって、クライアントは、ＡＶＰＦは映像（video）コンポネントのために使用され、音声（audio）メディアコンポネントのために使用されないことを知る。そのような場合、“a=x-avpfsupport”は、セッションレベルＳＤＰ属性である。クライアントは、UnsupportedAdaptationSupportは使用されず、SupportedAdaptationSupport機構または機能は、音声と映像メディア両方のために使用されるということも理解する。

Ｂ．適したマルチメディアストリーミング制御プロトコールを介するシグナリングおよびネゴシエーション
３ＧＰＳＳにおいて、ＲＴＳＰプロトコールは、マルチメディアセッションを制御するために使用される。

“x-avpfsupport”を明確なＲＴＳＰオプションタグにし、それは、クライアントではＡＶＰＦサポートを指示する。

“x-unsupportedadaptationsupport”は、明確なＲＴＳＰオプションタグにし、それは、クライアントによってサポートされるとき、ＲＴＳＰメッセージで信号伝達される。このタグで表される機構は、サーバによってサポートされないと仮定される。

“x-supportedadaptationsupport”は、明確なＲＴＳＰオプションタグとし、それは、クライアントによってサポートされるとき、ＲＴＳＰメッセージで信号伝達される。

クライアントは、マルチメディア・セッションのためのＲＴＳＰＵＲＬを知ると仮定される。

− クライアントは、より好ましい適合機構または機能の選定と共にDESCRIBE要求を送る。

クライアント->サーバ：
DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq:1
Require: x-avpfsupport, x-unsupportedadaptationsupport,x-supporteddataadaptationsupport

− クライアントは、RTSP Require要求ヘッダを使用して、サポートされた機構または機能を信号伝達する。

− クライアントによってサポートされる機構または機能に従って、サーバはうまくＳＤＰを調整するために、クライアントは、RTSP DESCRIBEメソッドで、または、RTSP DESCRIBEメソッド前に、RTSP要求でサポートされる機構または機能を信号伝達する。

− サーバは、RTSP要求を検討し、x-unsupportedadaptationsupportではなく、x-avpfsupport、および、x-supportedadaptationsupportを使用すると理解する。

サーバは２つの適した方法を有して応答する：

代替１：
− サーバは、メッセージ本体にサポートされない機構および機能を含んで、RTSP551“オプションはサポートされません（Option Not Supported）”応答を送る：

サーバ->クライアント
RTSP/1.0 551 Option Not Supported
CSeq:1
Unsupported: x-unsupportedadaptationsupport

− クライアントは、サポートされた機構または機能のみと共に別のDESCRIBE要求を出す。

クライアント->サーバ：
DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq:2
Require: x-avpfsupport,x-supportedadaptationsupport
− サーバは、図３に示すＳＤＰ記述をも含む、RTSP 200 OKメッセージと共に応答する。

代替２：
− サーバは、ＲＴＳＰ５５１ステータス応答無しで未サポート機構／機能情報を含む、RTSP DESCRIBE応答を送る。RTSP DESCRIBE応答を、図４に示す。

− サーバは、RTSP Unsupported応答ヘッダを使用して、特定のセッションのために使用する可能性の無い未サポート機構、もしくは、適合機構または機能を信号伝達し、かつ、適切なＳＤＰ属性を使用して、選択された適合機構または機能の使用を信号伝達する。

− クライアントがDESCRIBE応答をＳＤＰ記述と共に受け取るとき、クライアントは、どの適合機構または機能がこの特定のセッションでの使用に選択されるかを知る。

クライアントが、他のソースからＳＤＰ記述を受け取る場合では、クライアントは、ＳＤＰ記述を分析し、ＲＴＳＰセッションＵＲＬを見つけ出す。それから、RTSP DESCRIBE要求を送って、適合機構または機能をシグナリングし、ネゴシエーションを行う。クライアントは、前もってＭＭＳ回収されたＳＤＰ記述を分析することによって適合機構または機能の組を調整する。これは、サーバ側の混乱状態を解決する。なぜなら、サーバは、そのような使用シナリオにおいて、ＳＤＰ記述の内容を正確に知らないからである。

II．特定の３ＧＰＳＳセッションにおけるＲＴＰ再伝送ペイロードフォーマット使用
属性“RtxSupport”を、ＲＤＦスキーマボキャブラリにおいて規定して、映像および音声メディアのためのドラフト再伝送で規定されるＲＴＰ再伝送機構の使用を信号伝達する。ＲＴＸサポートは、自動的にクライアント側でＡＢＶＦサポートに規定される。

属性“UnSupportedAdaptationSupport”を、適合機構または機能として、ＲＤＦスキーマボキャブラリで規定し、それは、サーバではなくクライアントでサポートされる。

属性“SupportedAdaptationSupport”を、適合機構または機能として、ＲＤＦスキーマボキャブラリで規定し、それは、サーバでサポートされる。

属性“x-rtxsupport”を、明確なＳＤＰ属性にし、それは、ＲＴＰ再伝送ペイロードフォーマットがサポートされるとき、ＳＤＰの映像および音声（または、両メディアタイプでの使用のためのセッション層）メディア区分に含まれる。

属性“x-unsupportedadaptationsupport”を、明確なＳＤＰ属性にし、それは、サポートされるとき、ＳＤＰ（セッションまたはメディアレベル）に含まれる。

属性“x-supportedadaptationsupport”を、明確なＳＤＰ属性にし、それは、サポートされるとき、ＳＤＰ（セッションまたはメディアレベル）に含まれる。

Ａ．適した機能交換機構を介するシグナリングとネゴシエーション
− クライアントは、RTSP DESCRIBE要求をサーバに、機能交換サーバに存在するクライアント機能情報を指すＵＲＩと共に送る。

− サーバは、機能交換サーバからクライアントの機能宣言を取ってくる。その宣言は、図５に示されるように、クライアント側のストリーミング機能のための部分を含める。

宣言の中のボールド線は、クライアントの適合機構サポート機能を表す。RtxSupportは、正（ＴＲＵＥ）の場合、クライアントは、特定のセッションの映像および音声メディアのためのＲＴＰ再伝送ペイロードフォーマットを有することを宣言する。

− この機能を理解して、サーバは、ＲＴＰ再伝送機能とSupportedAdaptationSupport機能を含む、クライアントに送るべきＳＤＰ記述を調整する。図６にＳＤＰ記述が示される。サーバは、UnsupportedAdaptationSupportに基づいてＳＤＰ属性を含まない。なぜなら、サーバはそのためのサポートを有さないからである。ＳＤＰ記述内のボールド線は、ＲＴＰ再伝送ペイロードフォーマットの使用とSupportedAdaptationSupportのためのサポートを指示する。

− このＳＤＰ記述を受け取ることによって、クライアントは、ＲＴＰ再伝送は、音声（audio）コンポーネントではなく、映像（video）コンポーネントに使用されることを知る。UnsupportedAdaptationSupportは使用されず、SupportedAdaptationSupport機構および機能が映像および音声メディア両方のために使用される。

Ｂ．適したマルチメディアストリーミング制御プロトコールを介したシグナリングおよびネゴシエーション
３ＧＰＳＳ、ＲＴＳＰプロトコールは、マルチメディアセッションを制御するために使用される。

“x-rtxsupport”は、明確なＲＴＳＰオプションタグとし、それは、ＲＴＰ再伝送ペイロードフォーマットがクライアントによってサポートされることを示す。

“x-unsupportedadaptationsupport”は、明確なＲＴＳＰオプションタグとし、それは、クライアントによってサポートされるとき、ＲＴＳＰメッセージの中で信号伝達される。このタグによって表される機構と機能は、サーバによってサポートされないと仮定する。

“x-supportedadaptationsupport”は、明確なＲＴＳＰオプションタグとし、それは、クライアントによってサポートされるとき、ＲＴＳＰメッセージの中で信号伝達される。

クライアントは、マルチメディアセッションのためのＲＴＳＰＵＲＬを知っていると仮定される。

− クライアントは、DESCRIBE要求を好ましい適合機構または機能の選択と共に送る。

クライアント->サーバ：
DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq: 1
Require: x-rtxsupport, x-unsupportedadaptationsupport, x-supportedadaptationsupport

− クライアントは、RTSP Require要求ヘッダを使用して、サポートされる適合機構または機能を信号伝達する。

− クライアントによってサポートされた適合機構または機能に従って、サーバがＳＤＰをうまく調整するために、クライアントは、RTSP DESCRIBEメソッドで、または、RTSP DESCRIBEメソッド前に、RTSP要求においてサポートされる適合機構または機能を信号伝達する。

− サーバは、ＲＴＳＰ要求を検討し、それは、x-unsupportedadaptationsupportではなく、x-rtxsupportとx-supportedadaptationsupportを使用できることを理解する。

サーバは、２つの適した方法を有して応答する。

代替１：
− サーバは、メッセージ本体に未サポート機構または機能が含まれる、RTSP551“オプションはサポートされない（Option Not Supported）”を送る。
サーバ->クライアント
RTSP/1.0 551 Option not supported
Cseq: 1
Unsuported: x-unsupportedadaptationsupport

− クライアントは、サポートされる機構または機能のみと共に別のDESCRIBE要求を出す。

クライアント->サーバ：
DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq: 2
Require: x-rtxsupport, x-supportedadaptationsupport

− サーバは、図７に示すようにＳＤＰ記述をも含む、ＲＴＳＰ２００ＯＫメッセージで応答する。

代替２：
− サーバは、RTSP551状態応答無しで、未サポート機構／機能情報を含む、RTSP DESCRIBE応答を送る。そのRTSP DESCRIBE応答は、図８に示される。

− サーバは、RTSP Unsupported応答ヘッダを使用して、特定セッション用に使用され得ない未サポート機構または機能を信号伝達し、かつ、適当なＳＤＰ属性を使用して、選択された適合機構または機能の使用を信号伝達する。

− クライアントはＳＤＰ記述と共にDESCRIBE応答を受け取るとき、クライアントは、どの適合機構または機能の組がこの特定セッションでの使用のために選択されるかを知る。

クライアントが別ソース、例えば、ＭＭＳを介して、ＳＤＰ記述を受け取るケースでは、クライアントはＳＤＰ記述を分析し、ＲＴＳＰセッションＵＲＬを見つけ出す。

それから、クライアントは、RTSP DESCRIBE要求を送って、適合機構と機能をシグナリングし、および、ネゴシエーションを行う。クライアントは、前もってＭＭＳ回収されたＳＤＰ記述を分析することによって、適合機構または機能の組を調整することが出来る。これはサーバ側の混乱を解決する。なぜなら、サーバは、そのような使用シナリオにおいては、ＳＤＰ記述の内容を正確に知らないからである。

III ．特定の３ＧＰＳＳセッションにおけるＳＲＴＰ使用
属性“SRTPSupport”は、ＲＤＦスキーマボキャブラリで規定され、映像および音声メディアのためのdraft-srtp-05で規定されたＳＲＴＰのサポートをシグナリングする。

属性“UnsupportedAdaptationSupport”は、適合機構または機能としてＲＤＦスキーマボキャブラリで規定され、それは、サーバではなく、クライアントでサポートされる。

属性“SupportedAdaptationSupport”は、適合機構または機能としてＲＤＦスキーマボキャブラリで規定され、それは、サーバでもサポートされる。

“x-srtpsupport”は、明確なＳＤＰ属性とされ、それは、ＳＲＴＰがサポートされるとき、ＳＤＰの映像および音声（または、両メディアタイプにおける使用のためのセッションレベル）メディア区分に含まれる。

“x-unsupportedadaptationsupport”は、明確なＳＤＰ属性であり、それは、サポートされるとき、ＳＤＰ（セッションまたはメディアレベル）に含まれる。

“x-supportedadaptationsupport”は、明確なＳＤＰ属性であり、それは、サポートされるとき、ＳＤＰ（セッションまたはメディアレベル）に含まれる。

Ａ．適した機能交換機構を介したシグナリングおよびネゴシエーション
− クライアントは、機能交換サーバに存在するクライアント機能情報を指すＵＲＩと共にサーバに、RTSP DESCRIBE要求を送る。

− サーバは、機能交換サーバからクライアントの機能宣言を取ってくる。その宣言は、図９に示されるように、クライアント側ストリーミング機能の部分を含ませる。宣言におけるボールド線は、クライアントの適合機構サポート機能を表す。SRTPSupportは、TRUEであるとき、クライアントが特定セッションにおける映像および音声メディアコンポーネントのためのＳＲＴＰサポートを有することを宣言する。

− この機能を理解して、サーバは、ＳＲＴＰ機能と、SupportedAdaptationSupport機能を含む、クライアントに送られるべきＳＤＰ記述を調整する。そのＳＤＰ記述は、図１０に示される。サーバは、UnsupportedAdaptationSupportに基づいて、ＳＤＰ属性を含まない。というのは、サーバは、そのためのサポートを含まないからである。

ＳＤＰ記述の中のボールド線は、SRTPの使用およびSupportedAdaptationSupportのためのサポートを示す。

− ＳＤＰ記述を受け取ることによって、クライアントは、ＳＲＴＰが映像および音声コンポネントに使用されることを知る。クライアントは、UnsupportedAdaptationSupportは、使用されず、SupportedAdaptationSupport機構または機能は、映像および音声メディアの両方に使用されることも理解する。

“x-srtpsupport”は、明確なＲＴＳＰオプションタグとし、それは、クライアント上でのＳＲＴＰサポートを示す。

“x-unsupportedadaptationsupport”は、明確なＲＴＳＰオプションタグとし、それは、クライアントによってサポートされるとき、ＲＴＳＰメッセージ内で信号伝達される。このタグによって表される機構と機能は、サーバによってサポートされないと仮定する。

“x-supportedadaptationsupport”は、明確なＲＴＳＰオプションタグとし、それは、クライアントによってサポートされるとき、ＲＴＳＰメッセージ内で信号伝達される。

クライアントは、マルチメディアセッション用ＲＴＳＰＵＲＬを知っていると仮定される。

クライアント->サーバ：
DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq: 1
Require: x-srtpsupport, x-unsupportedadaptationsupport, x-supportedadaptationsupport

− サーバは、RTSP要求を検討し、そして、x-unsupportedadaptationsupportではなく、x-srtpsupportおよびx-supportedadaptationsupportが使えることを理解する。

サーバは、２つの適した方法を有して応答する。
代替１：
− サーバは、メッセージ本体に未サポート機構または機能を含む、RTSP551“オプションはサポートされない（Option Not Supported）”を送る。

サーバ->クライアント
RTSP/1.0 551 Option not supported
Cseq: 1
Unsuported: x-unsupportedadaptationsupport

クライアント->サーバ：
DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq: 2
Require: x-srtpsupport, x-supportedadaptationsupport

− サーバは、図１１に示すようにＳＤＰ記述をも含む、ＲＴＳＰ２００ＯＫメッセージで応答する。

代替２：
− サーバは、ＲＴＳＰ５５１ステータス応答無しで、未サポート機構／機能情報を含む、RTSP DESCRIBE応答を送る。RTSP DESCRIBE応答を、図１２に示す。

− サーバは、RTSP Unsupported応答ヘッダを使用して、特定セッションのために使用できない未サポート機構、または、適合機構もしくは機能を信号伝達し、および、適当なＳＤＰ属性を使用して、選択された適合機構または機能の使用を信号伝達する。

− クライアントがＳＤＰ記述と共にDESCRIBE応答を受け取るとき、クライアントは、どの適合機構または機能が、特定セッションにおける使用のために選択されるかを知る。

クライアントは、別ソースから、例えば、ＭＭＳを介して、ＳＤＰ記述を受け取るケースでは、クライアントは、ＳＤＰ記述を分析して、ＲＴＳＰセッションＵＲＬを見つけ出す。それから、クライアントは、RTSP DESCRIBE要求を適合機構または機能をシグナリングし、ネゴシエーションを行うために送る。クライアントは、前もって、ＭＭＳ回収されたＳＤＰ記述を分析することによって、適合機構または機能の組を調整する。これは、サーバサイド上の混乱を解決する。なぜなら、サーバは、そのような使用シナリオにおいては、ＳＤＰ記述の内容を正確に知らないからである。

要するに、本発明は、データ配信処理の適合に関し、マルチメディア・ストリーミング・サービス・システムにおけるサーバとクライアント間のシグナリングとネゴシエーションの方法を与える。シグナリングとネゴシエーションの手続は、図１３によって説明される。図１３におけるフローチャートで説明されるように、適合機構または機能をネゴシエーションするために、クライアントは、ステップ１１０で、クライアントへの複数の属性を、サーバに信号伝達する。これらの属性は、クライアントによって実行される適合機構または機能のものである。その属性は、機能交換機構のために規定されたクライアントの機能プロファイルにおいて、または、ストリーミングセッションの制御のために規定されるマルチメディアストリーミング制御プロトコールにおいてのどちらかに含まれる。ステップ１２０では、サーバは、機能プロファイルまたはマルチメディアストリーミング制御プロトコールから属性を獲得し、これらの属性のサブセットを選択する。選択された属性に基づいて、ステップ１３０で、サーバは、マルチメディアセッション記述を調整し、クライアントへ記述を送る。セッション記述に基づいて、クライアントは、サーバによって選択された属性を知る。ステップ１４０では、クライアントは、デフォルトで、選択された属性によって規定された適合機構または機能を受け入れる。本発明により、シグナリングおよびネゴシエーション方法は、特定の３ＧＰＳＳセッションにおけるＡＶＰＴ使用、ＲＴＰ再伝送ペイロードフォーマット使用、または、ＳＰＴＰ使用において実行される。

本発明により、シグナリングとネゴシエーションの方法は、図１４に示されるフローチャートのように、サーバによっても開始される。示されるように、サーバは、ステップ２１０において、クライアントの開始無しで、適合機構または機能をクライアントに示す。このケースでは、クライアント側から適合機構または機能の指示は無いが、サーバ側からある。サーバから指示を獲得した後で、クライアントは、ＲＴＳＰ応答における明確な属性を使用して、ステップ２２０で、サーバにその機能のためのサポートを示す。

このように、本発明は、それらの好ましい実施例について記述されたが、本発明の範囲から離れることなくなされる、先行および様々な他の変形、省略および形式上の逸脱、および、それらの詳細は、当業者によって理解されるだろう。

本発明により、シグナリングおよびネゴシエーションの部分として、クライアントによる宣言を示す図である。本発明により、クライアントに選択された属性を指示するためにサーバによって送られるＳＤＰ記述を示す図である。サーバによって送られるＲＴＳＰメッセージの中のＳＤＰ記述を示す図である。サーバによって送られるＲＴＳＰＤＥＳＣＲＩＢＥ応答を示す図である。本発明の別の実施例により、シグナリングおよびネゴシエーション処理の部分としてクライアントによる宣言を示す図である。本発明の他の実施例により、クライアントへ選択された属性を示すために、サーバによって送られるＳＤＰ記述を示す図である。サーバによって送られるＲＴＳＰメッセージの中のＳＤＰ記述を示す図である。サーバによって送られるＲＴＳＰＤＥＳＣＲＩＢＥ応答を示す図である。本発明の更に別の実施例により、シグナリングおよびネゴシエーション処理の部分としてクライアントによる宣言を示す図である。本発明により、クライアントへ選択された属性を指示するためにサーバによって送られるＳＤＰ記述を示す図である。サーバによって送られるＲＴＳＰメッセージの中のＳＤＰ記述を示す図である。サーバによって送られるＲＴＳＰＤＥＳＣＲＩＢＥ応答を示す図である。データ配信処理の適合に関して、ネゴシエーションを開始するクライアントとサーバ間のシグナリングとネゴシエーションの方法を説明するフローチャートを示す図である。シグナリングと、サーバが開始するネゴシエーションの方法を説明する図である。

Claims

マルチメディア・ストリーミング・サービスにおけるクライアントとサーバ間のシグナリングおよびネゴシエーションの方法において、データ配信のための前記サービスにおける複数の適合機構または機能は、前記クライアントによってサポートされ、各適合機構または機能は、属性を有し、
前記クライアントは、該クライアントによってサポートされる前記適合機構または機能を規定する前記属性を示す情報を出力し、
前記サーバは、前記出力情報に基づいて１つ以上の前記属性を選択し、
前記サーバは、さらに、該サーバによって選択される前記１以上の属性によって規定される前記１以上の適合機構または機能を知ることを、前記クライアントに許すために、該選択属性を示す情報を出力することによって特徴付けられる方法。
前記クライアントは、機能交換機構を介して前記情報を出力することを特徴とする請求項１に記載の方法。
前記クライアントは、マルチメディアストリーミング制御プロトコールを介して前記情報を出力することを特徴とする請求項１に記載の方法。
前記サーバは、さらに、前記クライアントが情報を出力する前に、該クライアントへ機能の指示を出力することによって特徴付けられる請求項１に記載の方法。
マルチメディア・ストリーミング・サービスにおけるクライアントとサーバを含む２つのパーティ間のシグナリングおよびネゴシエーションのための方法において、データ配信のための前記サーバにおける使用のための複数の適合機構または機能は、前記クライアントによってサポートされ、各適合機構または機能は属性を有し、
前記２つのパーティの１つによって、該２つのパーティの他の１つへ１以上の適合機構または機能を示す情報を出力し、
前記情報に応答して、前記他のパーティから、前記パーティへメッセージを搬送し、前記１以上の適合機構または機能のサポートを認識することによって特徴付けられる方法。
前記１つのパーティは、前記サーバであり、かつ、前記他のパーティは、前記クライアントであって、
前記クライアントは、前記応答メッセージ内で、前記１以上の適合機構または機能を規定する前記属性を用いてサポートを認識することを特徴とする請求項５に記載の方法。
前記１つのパーティは、前記クライアントであり、かつ、前記他のパーティは、前記サーバであって、
前記クライアントは、複数の属性を出力し、かつ、
前記サーバは、前記サポートを認識するための前記出力情報に基づいて１以上の前記出力属性を選択することを特徴とする請求項５に記載の方法。