(57)【要約】データ配信処理の適合に関して、マルチメディアストリーミングサービスにおけるクライアントとサーバ間のシグナリングとネゴシエーションの方法。データ配信において使用される適合機構または機能を確かめるために、パーティの１つは、他のパーティにサポートする適合機構または機能を示す情報を与える。その情報を受信するとすぐに、その別のパーティは、明確なＲＴＳＰ応答を使用して、その機構または機能のサポートを示す。サーバかクライアントは、ネゴシエーションを開始する。シグナリングとネゴシエーションの実行は、特に３Ｇ  ＰＳＳセッションにおける、ＡＶＰＦ使用、ＲＴＰ再伝送ペイロードフォーマット使用、および、ＳＰＴＰ使用をカバーする。
2006518948.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア・ストリーミング・サービスにおけるクライアントとサーバ間のシグナリングおよびネゴシエーションの方法において、データ配信のための前記サービスにおける複数の適合機構または機能は、前記クライアントによってサポートされ、各適合機構または機能は、属性を有し、
前記クライアントは、該クライアントによってサポートされる前記適合機構または機能を規定する前記属性を示す情報を出力し、
前記サーバは、前記出力情報に基づいて１つ以上の前記属性を選択し、
前記サーバは、さらに、該サーバによって選択される前記１以上の属性によって規定される前記１以上の適合機構または機能を知ることを、前記クライアントに許すために、該選択属性を示す情報を出力することによって特徴付けられる方法。
【請求項２】
前記クライアントは、機能交換機構を介して前記情報を出力することを特徴とする請求項１に記載の方法。
【請求項３】
前記クライアントは、マルチメディアストリーミング制御プロトコールを介して前記情報を出力することを特徴とする請求項１に記載の方法。
【請求項４】
前記サーバは、さらに、前記クライアントが情報を出力する前に、該クライアントへ機能の指示を出力することによって特徴付けられる請求項１に記載の方法。
【請求項５】
マルチメディア・ストリーミング・サービスにおけるクライアントとサーバを含む２つのパーティ間のシグナリングおよびネゴシエーションのための方法において、データ配信のための前記サーバにおける使用のための複数の適合機構または機能は、前記クライアントによってサポートされ、各適合機構または機能は属性を有し、
前記２つのパーティの１つによって、該２つのパーティの他の１つへ１以上の適合機構または機能を示す情報を出力し、
前記情報に応答して、前記他のパーティから、前記パーティへメッセージを搬送し、前記１以上の適合機構または機能のサポートを認識することによって特徴付けられる方法。
【請求項６】
前記１つのパーティは、前記サーバであり、かつ、前記他のパーティは、前記クライアントであって、
前記クライアントは、前記応答メッセージ内で、前記１以上の適合機構または機能を規定する前記属性を用いてサポートを認識することを特徴とする請求項５に記載の方法。
【請求項７】
前記１つのパーティは、前記クライアントであり、かつ、前記他のパーティは、前記サーバであって、
前記クライアントは、複数の属性を出力し、かつ、
前記サーバは、前記サポートを認識するための前記出力情報に基づいて１以上の前記出力属性を選択することを特徴とする請求項５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にマルチメディア・ストリーミングに関し、特に、ストリーミング品質適合および制御機構のシグナリングに関する。
【背景技術】
【０００２】
マルチメディア・ストリーミング・サービスにおいては、３つの参加者：ストリーミング・サーバ、ストリーミング・クライアント、そのサーバとクライアント間の接続を与える根本的なネットワーク、が含まれる。そのサーバは、マルチメディア・ストリーミング・コンテンツをクライアントに配信する機能を提供する。その目的のために、クライアントとサーバは、機能交換（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要求を好ましい適合機構または機能の選択と共に送る。
【０１１１】
クライアント->サーバ：
DESCRIBE  rtsp://foo/twister RTSP/1.0
CSeq: 1
Require: x-srtpsupport, x-unsupportedadaptationsupport, x-supportedadaptationsupport
【０１１２】
−  クライアントは、RTSP Require要求ヘッダを使用して、サポートされる適合機構または機能を信号伝達する。
【０１１３】
−  クライアントによってサポートされた適合機構または機能に従って、サーバがＳＤＰをうまく調整するために、クライアントは、RTSP DESCRIBEメソッドで、または、RTSP DESCRIBEメソッド前に、RTSP要求においてサポートされる適合機構または機能を信号伝達する。
【０１１４】
−  サーバは、RTSP要求を検討し、そして、x-unsupportedadaptationsupportではなく、x-srtpsupportおよび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-srtpsupport, x-supportedadaptationsupport
【０１１９】
−  サーバは、図１１に示すようにＳＤＰ記述をも含む、ＲＴＳＰ  ２００  ＯＫメッセージで応答する。
【０１２０】
代替２：
−  サーバは、ＲＴＳＰ  ５５１  ステータス応答無しで、未サポート機構／機能情報を含む、RTSP DESCRIBE応答を送る。RTSP DESCRIBE応答を、図１２に示す。
【０１２１】
−  サーバは、RTSP Unsupported応答ヘッダを使用して、特定セッションのために使用できない未サポート機構、または、適合機構もしくは機能を信号伝達し、および、適当なＳＤＰ属性を使用して、選択された適合機構または機能の使用を信号伝達する。
【０１２２】
−  クライアントがＳＤＰ記述と共にDESCRIBE応答を受け取るとき、クライアントは、どの適合機構または機能が、特定セッションにおける使用のために選択されるかを知る。
【０１２３】
クライアントは、別ソースから、例えば、ＭＭＳを介して、ＳＤＰ記述を受け取るケースでは、クライアントは、ＳＤＰ記述を分析して、ＲＴＳＰセッションＵＲＬを見つけ出す。それから、クライアントは、RTSP DESCRIBE要求を適合機構または機能をシグナリングし、ネゴシエーションを行うために送る。クライアントは、前もって、ＭＭＳ回収されたＳＤＰ記述を分析することによって、適合機構または機能の組を調整する。これは、サーバサイド上の混乱を解決する。なぜなら、サーバは、そのような使用シナリオにおいては、ＳＤＰ記述の内容を正確に知らないからである。
【０１２４】
要するに、本発明は、データ配信処理の適合に関し、マルチメディア・ストリーミング・サービス・システムにおけるサーバとクライアント間のシグナリングとネゴシエーションの方法を与える。シグナリングとネゴシエーションの手続は、図１３によって説明される。図１３におけるフローチャートで説明されるように、適合機構または機能をネゴシエーションするために、クライアントは、ステップ１１０で、クライアントへの複数の属性を、サーバに信号伝達する。これらの属性は、クライアントによって実行される適合機構または機能のものである。その属性は、機能交換機構のために規定されたクライアントの機能プロファイルにおいて、または、ストリーミングセッションの制御のために規定されるマルチメディアストリーミング制御プロトコールにおいてのどちらかに含まれる。ステップ１２０では、サーバは、機能プロファイルまたはマルチメディアストリーミング制御プロトコールから属性を獲得し、これらの属性のサブセットを選択する。選択された属性に基づいて、ステップ１３０で、サーバは、マルチメディアセッション記述を調整し、クライアントへ記述を送る。セッション記述に基づいて、クライアントは、サーバによって選択された属性を知る。ステップ１４０では、クライアントは、デフォルトで、選択された属性によって規定された適合機構または機能を受け入れる。本発明により、シグナリングおよびネゴシエーション方法は、特定の３Ｇ  ＰＳＳセッションにおけるＡＶＰＴ使用、ＲＴＰ再伝送ペイロードフォーマット使用、または、ＳＰＴＰ使用において実行される。
【０１２５】
本発明により、シグナリングとネゴシエーションの方法は、図１４に示されるフローチャートのように、サーバによっても開始される。示されるように、サーバは、ステップ２１０において、クライアントの開始無しで、適合機構または機能をクライアントに示す。このケースでは、クライアント側から適合機構または機能の指示は無いが、サーバ側からある。サーバから指示を獲得した後で、クライアントは、ＲＴＳＰ応答における明確な属性を使用して、ステップ２２０で、サーバにその機能のためのサポートを示す。
【０１２６】
このように、本発明は、それらの好ましい実施例について記述されたが、本発明の範囲から離れることなくなされる、先行および様々な他の変形、省略および形式上の逸脱、および、それらの詳細は、当業者によって理解されるだろう。
【図面の簡単な説明】
【０１２７】
【図１】本発明により、シグナリングおよびネゴシエーションの部分として、クライアントによる宣言を示す図である。
【図２】本発明により、クライアントに選択された属性を指示するためにサーバによって送られるＳＤＰ記述を示す図である。
【図３】サーバによって送られるＲＴＳＰメッセージの中のＳＤＰ記述を示す図である。
【図４】サーバによって送られるＲＴＳＰ  ＤＥＳＣＲＩＢＥ応答を示す図である。
【図５】本発明の別の実施例により、シグナリングおよびネゴシエーション処理の部分としてクライアントによる宣言を示す図である。
【図６】本発明の他の実施例により、クライアントへ選択された属性を示すために、サーバによって送られるＳＤＰ記述を示す図である。
【図７】サーバによって送られるＲＴＳＰメッセージの中のＳＤＰ記述を示す図である。
【図８】サーバによって送られるＲＴＳＰ  ＤＥＳＣＲＩＢＥ応答を示す図である。
【図９】本発明の更に別の実施例により、シグナリングおよびネゴシエーション処理の部分としてクライアントによる宣言を示す図である。
【図１０】本発明により、クライアントへ選択された属性を指示するためにサーバによって送られるＳＤＰ記述を示す図である。
【図１１】サーバによって送られるＲＴＳＰメッセージの中のＳＤＰ記述を示す図である。
【図１２】サーバによって送られるＲＴＳＰ  ＤＥＳＣＲＩＢＥ応答を示す図である。
【図１３】データ配信処理の適合に関して、ネゴシエーションを開始するクライアントとサーバ間のシグナリングとネゴシエーションの方法を説明するフローチャートを示す図である。
【図１４】シグナリングと、サーバが開始するネゴシエーションの方法を説明する図である。
【図１】
2006518948.tif 000003
【図２】
2006518948.tif 000004
【図３】
2006518948.tif 000005
【図４】
2006518948.tif 000006
【図５】
2006518948.tif 000007
【図６】
2006518948.tif 000008
【図７】
2006518948.tif 000009
【図８】
2006518948.tif 000010
【図９】
2006518948.tif 000011
【図１０】
2006518948.tif 000012
【図１１】
2006518948.tif 000013
【図１２】
2006518948.tif 000014
【図１３】
2006518948.tif 000015
【図１４】
2006518948.tif 000016
【国際調査報告】
2006518948.tif 000017