(57)【要約】  本発明は、ＩＰＴＶサービスのメディア記述情報を取得する方法及び装置を提供する。方法は以下のステップを含む。ネットワーク側の装置は、ユーザ端末によってコアＩＭＳを介して送信された、メディア記述情報を取得するためのＳＩＰ要求を受信し、要求はコンテンツ識別情報を運び、ネットワーク側の装置は、コンテンツ識別情報に対応するメディア記述情報を運ぶＳＩＰ応答メッセージを作成し、ＳＩＰ応答メッセージを、コアＩＭＳを介してユーザ端末に送信する。本発明では、メディア記述情報をＳＩＰメッセージから取得して、ＣＯＤサービスのセッションを確立することができる。
2011501304.tif 000002
【特許請求の範囲】
【請求項１】
メディア記述情報を取得するためのセッション開始プロトコル（ＳＩＰ）要求を、ネットワーク装置によって受信し、ここで、前記ＳＩＰ要求は、ユーザ装置（ＵＥ）によってコアＩＰマルチメディアサブシステム（ＩＭＳ）を介して送信され、コンテンツ識別子を運び、
前記コンテンツ識別子に対応する前記メディア記述情報を運ぶＳＩＰ応答を、前記ネットワーク装置によって、前記コアＩＭＳを介して前記ＵＥに送信すること
を含む、インターネットプロトコルテレビジョン（ＩＰＴＶ）サービスのメディア記述情報を取得する方法。
【請求項２】
前記メディア記述情報は、コンテンツ制御チャネルパラメータ及び／又はコンテンツ配信チャネルパラメータを含む、請求項１に記載の方法。
【請求項３】
前記コンテンツ識別子に対応する前記メディア記述情報を運ぶ前記応答を、前記ネットワーク装置が送信する前に、前記方法は、
前記ネットワーク装置によって、前記メディア記述情報をコンテンツディスクリプタ機能から取得すること
を更に含む、請求項１に記載の方法。
【請求項４】
前記ネットワーク装置は、サービス制御機能（ＳＣＦ）又はメディア機能（ＭＦ）である、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記メディア記述情報を取得するための前記ＳＩＰ要求は、ＯＰＴＩＯＮＳ又はＩＮＶＩＴＥメッセージである、請求項１に記載の方法。
【請求項６】
前記メディア記述情報は、前記応答内で、セッション記述プロトコル（ＳＤＰ）又は拡張可能なマークアップ言語（ＸＭＬ）モードで運ばれる、請求項１に記載の方法。
【請求項７】
メディア記述情報を取得するためのセッション開始プロトコル（ＳＩＰ）要求を受信するように構成された、受信ユニット（１）と（ここで、前記ＳＩＰ要求は、ユーザ装置（ＵＥ）によってコアＩＰマルチメディアサブシステム（ＩＭＳ）を介して送信され、コンテンツ識別子を運ぶ）、
応答（前記応答内で、セッション記述プロトコル（ＳＤＰ）が、前記コンテンツ識別子に対応する前記メディア記述情報を運ぶ）を生成するように構成された、生成ユニット（２）と、
前記応答を、前記コアＩＭＳを介して前記ＵＥに送信するように構成された、送信ユニット（３）とを備える、ネットワーク装置。
【請求項８】
前記メディア記述情報をコンテンツディスクリプタ機能から取得するように構成された、取得ユニット（４）を更に備える、請求項７に記載のネットワーク装置。
【請求項９】
前記ネットワーク装置は、サービス制御機能（ＳＣＦ）又はメディア機能（ＭＦ）である、請求項７に記載のネットワーク装置。
【請求項１０】
ユーザ装置（ＵＥ）によって送信された制御モード情報を、ネットワーク装置によって受信し、
セッション開始プロトコル（ＳＩＰ）ヘッダフィールド内、又は、メッセージボディのセッション記述プロトコル（ＳＤＰ）属性行内で運ばれる前記制御モード情報を、前記ネットワーク装置によって前記ＵＥに返すこと
を含む、メディア制御及びネゴシエーション方法。
【請求項１１】
前記ＳＩＰヘッダフィールドは、Contactヘッダフィールド又はRequest-Dispositionヘッダフィールドを含む、請求項１０に記載の方法。
【請求項１２】
前記メッセージボディの前記ＳＤＰ属性行は、属性行「a=<attribute>:<value>」を含み、「attribute」はメディア制御モード属性を識別し、「value」は制御モード情報を示す、請求項１０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信技術に関し、特に、インターネットプロトコルテレビジョン（ＩＰＴＶ）サービスのメディア記述情報を取得する方法及び装置に関する。
【背景技術】
【０００２】
ＩＰマルチメディアサブシステム（ＩＭＳ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）Ｒ５規格で追加された、広帯域符号分割多元接続（ＷＣＤＭＡ）ネットワーク上の既存のパケット交換（ＰＳ）ドメイン内のサブシステムである。ＩＭＳは、上位層制御シグナリング及びメディア配信のためのベアラチャネルとしてＰＳドメインを使用し、サービス制御プロトコルとしてセッション開始プロトコル（ＳＩＰ）を導入し、単純さ、拡張性、及び簡便なメディア結合などの、ＳＩＰの特徴を利用することによって、かつ、サービス制御をベアラ制御から分離することによって、豊富なマルチメディアサービスを提供する。ＩＭＳの標準化に参加している国際的な標準化組織としては、３ＧＰＰと、ＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  ａｎｄ  Ｉｎｔｅｒｎｅｔ  ｃｏｎｖｅｒｇｅｄ  Ｓｅｒｖｉｃｅｓ  ａｎｄ  Ｐｒｏｔｏｃｏｌｓ  ｆｏｒ  Ａｄｖａｎｃｅｄ  Ｎｅｔｗｏｒｋｉｎｇ）とが挙げられる。３ＧＰＰは、移動アクセスの観点からＩＭＳを研究する。ＴＩＳＰＡＮは、固定アクセスの観点から、ＩＭＳに対する要求を提起し、次に、３ＧＰＰによってＩＭＳが完成される。最後に、固定アクセス及び移動アクセスのための統合された制御がＩＭＳ上で実施される。
【０００３】
ＩＭＳベースのＩＰＴＶは、登録、認証、ルーティング、セッション制御及びセットアップ、サービストリガ、課金、並びに、エンドツーエンドのサービス品質（ＱｏＳ）などの、既存のメカニズムを十分に活用して、ストリーミングサービスと、ストリーミングサービス及びリアルタイムセッションサービスを統合したマルチメディアサービスとをユーザに提供するために、ＴＩＳＰＡＮによって提案された全ＩＭＳアーキテクチャにおけるＩＰＴＶサービスを提供する。すなわち、ユーザからコンテンツまでのマルチメディアセッションが、ＩＭＳの既存のセッション制御メカニズムによって完成される。セッションセットアップ中に、メディアストリームの伝送のためのベアラリソースが確保される必要がある。
【０００４】
従来技術では、コンテンツオンデマンド（ＣｏＤ）サービスプロセスにおけるセッションセットアップの主な特徴は以下の通りである。ＣｏＤサービスプロセスにおいて、ユーザは、見られるコンテンツに対する、前送り、巻き戻し、及び一時停止などの、ＶＣＲ制御を実行する可能性があり、従って、ＶＣＲ動作のために使用されるメディア制御チャネルと、見られるコンテンツを伝送するために使用されるメディア配信チャネルとが、サービスのために確立される必要がある。メディア制御チャネルとメディア配信チャネルとを確立する様々なモードに従って、ＴＩＳＰＡＮによって規定されたＣｏＤサービスプロセスは２つのモードを含む。第１のモードでは、メディア制御チャネルとメディア配信チャネルとが、ＳＩＰセッションセットアップ中に同時に確立される。第２のモードでは、メディア制御チャネルが初期セッションセットアップ中に確立され、次に、メディア配信チャネルが、セッション変更を介して確立される。
【０００５】
第１のモードを使用するための必須条件は、ユーザ装置（ＵＥ）が、コンテンツのメディア行（例えば、音声、映像、及びテキストメディア行）などの、見られるコンテンツのメディア情報を、電子番組案内（ＥＰＧ）から取得済みであるということである。従って、メディア配信チャネルがネゴシエートされて確立されることが可能である。第２のモードが採用される場合は、メディア制御チャネル（一般に、ＲＴＳＰチャネル）が、ＳＩＰセッションセットアッププロセスを介して、ネゴシエートされて確立され、メディア交換制御セッションが、ＵＥとメディア機能（ＭＦ）との間にセットアップされ、メディアのネットワークパラメータ情報が、メディア制御メッセージを交換することによって取得され、次に、コンテンツ配信チャネルが、セッション変更中に確立される。
【０００６】
実際には、第１のモードと比較して、第２のモードは、セッションセットアップに長い時間を要する、という欠点を有する。一般的なプロセスは、以下の通りである。（ＳＩＰメッセージを使用することによって）最初にセッションがセットアップされた後で、ＵＥとネットワーク（ＭＦ）とは、メディア制御メッセージ（一般に、ＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージ）を発してメディア制御セッションをセットアップし、メディア制御セッションメッセージ内でメディアコンテンツを交換し、最後に、（ＳＩＰメッセージを使用することによる）セッション変更プロセスを介してメディアチャネルが確立される。結果として、ユーザのサービス体験は貧弱なものとなる。従って、現在の仕様における第２のモードの適用に対する制限は、以下の通りである。初期セッション中にコンテンツ配信チャネルを確立すること、すなわち、第２のモードは、ネットワークが、コンテンツ配信チャネルのネットワークパラメータ情報ではなく、メディア制御チャネルのネットワークパラメータ情報のみをユーザに提供する場合のみ選択可能である。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来技術における、以下の問題が明らかとなった。
【０００８】
第２のモードが採用される場合、より多くの相互作用がＵＥとネットワークとの間で必要とされ、より多くの要求がＵＥに対して提起され、セッションセットアップは遅らされ、ユーザ体験は貧弱なものとなる。
【課題を解決するための手段】
【０００９】
本発明は、ＳＩＰメッセージを介してメディア記述情報を取得してＣｏＤサービスのセッションをセットアップするための、ＩＰＴＶサービスのメディア記述情報を取得する方法及び装置を提供する。
【００１０】
本発明の第１の態様として、ＩＰＴＶサービスのメディア記述情報を取得する方法は、
メディア記述情報を取得するためのＳＩＰ要求を、ネットワーク装置によって受信し、ここで、ＳＩＰ要求は、ＵＥによってコアＩＭＳを介して送信され、コンテンツ識別子を運び、
コンテンツ識別子に対応するメディア記述情報を運ぶＳＩＰ応答を、ネットワーク装置によって、コアＩＭＳを介してＵＥに送信することを含む。
【００１１】
本発明の第２の態様として、ネットワーク装置は、
メディア記述情報を取得するためのＳＩＰ要求を受信するように構成された、受信ユニットと（ここで、ＳＩＰ要求は、ＵＥによってコアＩＭＳを介して送信され、コンテンツ識別子を運ぶ）、
応答（その中で、セッション記述プロトコル（ＳＤＰ）が、コンテンツ識別子に対応するメディア記述情報を運ぶ）を生成するように構成された、生成ユニットと、
応答を、コアＩＭＳを介してＵＥに送信するように構成された、送信ユニットとを含む。
【００１２】
本発明の第３の態様として、メディア制御及びネゴシエーション方法は、
ＵＥによって送信された制御モード情報を、ネットワーク装置によって受信し、
ネットワーク装置によって、制御モード情報をＵＥに返すことを含み、制御モード情報は、ＳＩＰヘッダフィールド内、又は、メッセージボディのＳＤＰ属性行内で運ばれる(the control mode information is carried in a SIP header field or SDP attribute line of a message body)。
【発明の効果】
【００１３】
本発明において、ＵＥは、制御パラメータ、ネットワークパラメータ、及びコンテンツメディア記述などの情報を、サービス制御機能（ＳＣＦ）又はＭＦなどの関連するエンティティから取得し、次に、それらのパラメータに従って、対応する動作を実行することができる。
【図面の簡単な説明】
【００１４】
【図１】従来技術におけるＣｏＤサービスを説明するフロー図である。
【図２】本発明の第２の実施形態における、メディア記述情報を取得するシステムの構成である。
【図３】本発明の第３の実施形態における、メディア記述情報を取得する方法のフロー図である。
【図４】本発明の第４の実施形態における、メディア記述情報を取得する方法のフロー図である。
【図５】本発明の第５の実施形態における、メディア制御を実施する方法のフローチャートである。
【図６】本発明の第６の実施形態における、メディア制御を実施する方法のフローチャートである。
【図７】本発明の第７の実施形態における、メディア制御を実施するシステムの構成である。
【図８】本発明の第８の実施形態における、ＵＥがＣｏＤセッション要求を発する前にメディア情報を取得する方法のフロー図である。
【図９】本発明の第９の実施形態における、ＵＥがＣｏＤセッション要求を発する前にメディア情報を取得する、別の方法のフロー図である。
【図１０】本発明の第１０の実施形態における、ＵＥがＣｏＤセッション要求を発する際にメディア情報を取得する方法のフロー図である。
【図１１】本発明の第１１の実施形態における、ＵＥがＣｏＤセッション要求を発する際にメディア情報を取得する、別の方法のフロー図である。
【図１２】本発明の第１２の実施形態におけるネットワーク装置の構成である。
【図１３】本発明の第１３の実施形態における、最終的に使用される制御モードをＵＥとネットワークエンティティとがネゴシエーションを介して決定するフロー図である。
【発明を実施するための形態】
【００１５】
従来技術では、リアルタイムストリーミングプロトコル（ＲＴＳＰ）ベースのセッションネゴシエーション及びセットアッププロセスが、前述の動作モードを十分に支持し、例えば、集約モード（ａｇｇｒｅｇａｔｉｏｎ  ｍｏｄｅ）が作成された場合、全てのメディア配信チャネルが同期式に制御されることが可能であり、又は、個別モード（ｓｅｐａｒａｔｅ  ｍｏｄｅ）が採用された場合、各メディア配信チャネルが個別に制御されることが可能である。
【００１６】
ＩＭＳのＣｏＤサービスでは、ＲＴＳＰセッションに関連するパラメータが、ＳＩＰセッションセットアップ中にネゴシエートされる。ＲＴＳＰのＳｅｔｕｐメッセージなどの、ＲＴＳＰセッションセットアッププロセスは存在せず、代わりに、ＳＩＰセッションがセットアップされた後で、ＶＣＲ動作制御を実行するために、ＲＴＳＰメッセージが使用される。関連するＲＴＳＰパラメータは、ＳＩＰ／ＳＤＰメッセージ内で運ばれてネゴシエートされ(The related RTSP parameters are carried and negotiated in a SIP/SDP message)、従って、ＩＭＳベースのＩＰＴＶサービス環境では、ＳＩＰ／ＳＤＰメッセージは、ＣｏＤサービスにおけるコンテンツの、１つ以上のメディア配信チャネルのためのＶＣＲ動作を示さない可能性があり（すなわち、ＵＥがＲＴＳＰメッセージを介してＶＣＲ動作を実行する場合、コンテンツの１つ以上のメディアチャネルのためのＶＣＲ動作が実行されない可能性があり）、すなわち、従来技術におけるＳＩＰ／ＳＤＰメッセージは、ＵＥに情報を転送しない可能性がある。
【００１７】
本発明の第１の実施形態は、メディア制御指示の方法を提供する。この方法は、各メディアストリームの制御状態を、ＳＤＰ内で指定される属性行を介して示すものであり、すなわち、ＳＤＰが、複数のメディア配信チャネルについて、同期制御、個別制御、又はハイブリッド制御（同期制御と個別制御との共存）を識別する。同期制御は、複数のメディアストリームを同時に制御するものであり、個別制御は、１つのメディアストリームを制御するものである。属性は複数のモードで表されてもよい。それらのモードを説明するいくつかの例を以下に示す。
【００１８】
以下の全ての実施形態において、属性行に関連付けられたメディア配信チャネルに対応するメディアストリームは、対応するメディア制御チャネルによって制御される必要があり、属性行に関連付けられていないメディア配信チャネルに対応するメディアストリームは、対応するメディア制御チャネルによって制御されない。
【００１９】
第１のモードでは、属性行を使用して、メディア配信チャネルとメディア制御チャネルとの間の関係、すなわち、ＳＤＰにおける対応する記述情報の関係を記述する。
【００２０】
第１のモードでは、属性行「a=<attribute>:<value>」を使用し、ここで、「attribute」は、ＲＴＳＰセッション制御などのメディア制御属性を識別し、これは、文字セット又はその他であってもよく、「value」は、メディア制御チャネルに関する情報を識別し、これは、文字セット（ＲＴＳＰ  ＵＲＬ又はその他）あるいは数（ＲＴＳＰセッション識別子又はその他）であってもよい。
【００２１】
属性行は、全てのメディア配信チャネルを制御するメディア制御チャネルを記述するように、第１のメディア行「m=」の前に配置されて、セッションレベル属性として働いてもよい。
【００２２】
属性行は、１つのメディア配信チャネルを制御するメディア制御チャネルを記述するように、メディア行「m=」の後に配置されて、メディアレベル属性として働いてもよい。
【００２３】
以下の実施形態における属性行では、「a=control:<RTSP URL>」を例に取る。その他の記述モードが採用されてもよい。
【００２４】
例１のセッションレベル属性行は以下の通りである。
a=control:rtsp://foo/twister
m=audio 1306 RTP/AVP 0//音声メディア配信チャネルのメディア行を記述
m=video 1308 RTP/AVP 26//映像メディア配信チャネルのメディア行を記述
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=fmtp:rtsp h-uri=rtsp://foo/twister
【００２５】
「a=control:」属性行は、セッションレベル属性として働き、これは、音声メディア配信チャネル及び映像メディア配信チャネルに対応するメディアストリームについての同期制御を示し、メディア制御情報は、属性行内の「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「m=」はメディア行であり、<RTSP URL>は「rtsp://foo/twister」であってもよく、但し実際には、特定の形態はこれに限定されない。
【００２６】
例２のメディアレベル属性行は以下の通りである。
m=audio 1306 RTP/AVP 0//音声メディア配信チャネルのメディア行を記述
a=control:rtsp://foo/twister
m=video 1308 RTP/AVP 26//映像メディア配信チャネルのメディア行を記述
a=control:rtsp://foo/twister
m=text 1310 RTP/AVP wb//テキストメディア配信チャネルのメディア行を記述
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=fmtp:rtsp h-uri=rtsp://foo/twister
【００２７】
「a=control:」属性行は、メディアレベル属性として働き、これは、音声メディア配信チャネル及び映像メディア配信チャネルに対応するメディア制御情報が、属性行内の「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報であることを示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。テキストメディア配信チャネルは、対応する「a=control:」属性行を有さず、これは、制御のための対応するメディア制御チャネルがないことを示す。「m=」はメディア行であり、<RTSP URL>は「rtsp://foo/twister」であってもよく、但し実際には、特定の形態はこれに限定されない。
【００２８】
例３のメディアレベル属性行は以下の通りである。
m=audio 1306 RTP/AVP 0//音声メディア配信チャネルのメディア行を記述
a=control:rtsp://foo/twister/audio
m=video 1308 RTP/AVP 26//映像メディア配信チャネルのメディア行を記述
a=control:rtsp://foo/twister/ video
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=fmtp:rtsp h-uri=rtsp://foo/twister/audio
m=application 11 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=fmtp:rtsp h-uri= rtsp://foo/twister/video
【００２９】
「m=audio」は音声メディア行であり、「a=control:rtsp://foo/twister/audio」は、音声メディア行に対応する音声メディアストリームを個別に制御するための属性行であり、「m=video」は映像メディア行であり、「control:rtsp://foo/twister/ video」は、映像メディア行に対応する映像メディアストリームを個別に制御するための属性行である。音声メディア配信チャネルに対応するメディア制御情報は、その属性行内の「rtsp://foo/twister/audio」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報を示し、映像メディア配信チャネルに対応するメディア制御情報は、その属性行内の「rtsp://foo/twister/video」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」及び「m=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００３０】
加えて、このモードでは、ＵＥが各メディアを個別に制御してもよく、同期制御は強制されないが、実際の適用中には、複数のメディアが同期式に制御されてもよく、例えば、全てのメディアストリームを同期式に制御するために、複数の制御メッセージが同時に送信され、各制御メッセージが１つのメディアチャネルを制御する。
【００３１】
第２のモードでは、グループ属性行を使用して、メディア配信チャネルとメディア制御チャネルとの間の関係、すなわち、ＳＤＰにおける対応する記述情報の関係を記述する。
【００３２】
第２のモードでは、グループ属性行「a=group:semantics*(spaceidentification-tag)」を使用する。
【００３３】
「semantics」は、メディア制御属性を識別し、これは、文字セット又はその他であってもよく、「identification-tag」は、メディアストリーム識別子を示し、これは、数、トークン、又はその他であってもよい。グループ属性行は、識別子が「identification-tag」であるメディアストリームが、統一されたメディア制御チャネルによって制御されることを示す。メディアストリーム識別子は、「a=mid:」ストリーム識別子属性行内のストリーム識別子値、又は「a=label:」ストリームラベル属性行内のストリームラベル値である。
【００３４】
例４は、以下の通りである。
a=group:<control attribute (control) stream identifier (1 2)>
a=control:rtsp://foo/twister
m=audio 1306 RTP/AVP 0
a=mid:1
m=video 1308 RTP/AVP 26
a=mid:2
m=text 1310 RTP/AVP wb
a=control:rtsp://foo/twister/text
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=fmtp:rtsp h-uri=rtsp://foo/twister
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=fmtp:rtsp h-uri=rtsp://foo/twister/text
【００３５】
「a=group: <control attribute (control) stream identifier (1 2)>」は、グループ属性行であり、これは、メディアストリーム識別子１に対応する音声メディアストリーム及びメディアストリーム識別子２に対応する映像メディアストリームについての同期制御を示し、「a=control:rtsp://foo/twister」は、２つのメディア配信チャネルに対応するメディア制御情報が、属性行内の「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報であることを更に示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「m=text 1310 RTP/AVP wb」メディア行に対応するテキストメディアストリームは、個別に制御され、メディア制御情報は、「rtsp://foo/twister/text」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報を示す。「a=」及び「m=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００３６】
例５は、以下の通りである。
a=group:<control attribute (control) label identifier (1)>
a=control:rtsp://foo/twister
m=audio 1306 RTP/AVP 0
a=label:1
m=video 1308 RTP/AVP 26
a=label:1
m=text 1310 RTP/AVP wb
a=control:rtsp://foo/twister/text
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=fmtp:rtsp h-uri=rtsp://foo/twister
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=fmtp:rtsp h-uri=rtsp://foo/twister/text
【００３７】
「a=group:<control attribute (control) label identifier (1)>」は、グループ属性行であり、これは、ラベル識別子１に対応する音声メディアストリーム及び映像メディアストリームについての同期制御を示し、「a=control:rtsp://foo/twister」は、２つのメディア配信チャネルに対応するメディア制御情報が、属性行内の「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報であることを更に示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。テキストメディアストリームは、個別に制御されてもよく、メディア制御情報は、「rtsp://foo/twister/text」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報を示す。「a=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００３８】
例６は、以下の通りである。
a=group:rtspcontrol 1 2
m=audio 1306 RTP/AVP 0//メディア配信チャネルのメディア行を記述
a=mid:1
m=video 1308 RTP/AVP 26//メディア配信チャネルのメディア行を記述
a=mid:2
m=text 1310 RTP/AVP wb
a=mid:3
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=mid:4
【００３９】
「a=group:rtspcontrol 1 2」は、グループ属性行であり、これは、メディアストリーム識別子１に対応する音声メディアストリーム及びメディアストリーム識別子２に対応する映像メディアストリームについての同期制御を示し、メディア制御チャネル情報は、メディア制御チャネルに対応するメディア記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。メディアストリーム識別子４に対応するテキストメディアストリームについてのメディアストリームを制御するためのメディア制御チャネルは存在しない。「a=」及び「m=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００４０】
メディアストリーム識別子が「a=label:」ストリームラベル属性行を採用するモードは、例６におけるモードに類似している。違いは、例６における「a=mid:」属性行が、「a=label:」属性行に置き換えられること、及び、グループ属性行内のメディアストリーム識別子が、「a=label:」属性行内のラベル値に変更されることである。
【００４１】
第２のモードでは、グループ属性行「a=group:semantics*(space identification-tag)」を使用してもよい。
【００４２】
「semantics」は、メディア制御属性を識別し、これは、文字セット又はその他であってもよく、「identification-tag」は、メディア制御チャネルに関する情報、及びメディアストリーム識別子に関する情報を識別する。メディア制御チャネルに関する情報は、文字セット又は数であってもよく、文字セットは、ＲＴＳＰ  ＵＲＬ又はその他であってもよく、数は、ＲＴＳＰセッション識別子、ＲＴＳＰメディア制御ストリーム識別子、又はその他であってもよく、ＲＴＳＰメディア制御ストリーム識別子及びメディアストリーム識別子は、数、トークン、又はその他であってもよい。ＲＴＳＰメディア制御ストリーム識別子及びメディアストリーム識別子は、「a=mid:」ストリーム識別子属性行内のストリーム識別子値、又は「a=label:」ストリームラベル属性行内のストリームラベル値である。
【００４３】
例７は、以下の通りである。
a=group:control rtsp://foo/twister 1 2
m=audio 1306 RTP/AVP 0
a=mid:1
m=video 1308 RTP/AVP 26
a=mid:2
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=mid:3
a=fmtp:rtsp h-uri=rtsp://foo/twister
【００４４】
「a=group:control rtsp://foo/twister 1 2」は、グループ属性行であり、これは、メディアストリーム識別子１に対応する音声メディアストリーム及びメディアストリーム識別子２に対応する映像メディアストリームについての同期制御を示し、メディア制御情報は、「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」及び「m=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００４５】
例８は、以下の通りである。
a=group:rtspcontrol 3 1 2
m=audio 1306 RTP/AVP 0//音声メディア配信チャネルのメディア行を記述
a=mid:1
m=video 1308 RTP/AVP 26//映像メディア配信チャネルのメディア行を記述
a=mid:2
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=mid:3
【００４６】
「a=group:rtspcontrol 3 1 2」は、グループ属性行であり、これは、メディアストリーム識別子１に対応する音声メディアストリーム及びメディアストリーム識別子２に対応する映像メディアストリームについての同期制御を示し、メディア制御情報は、メディアストリーム識別子３に対応するメディア記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」及び「m=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００４７】
メディアストリーム識別子が「a=label:」ストリームラベル属性行を採用するモードは、例８におけるモードに類似している。違いは、例８における「a=mid:」属性行が、「a=label:」属性行に置き換えられること、及び、グループ属性行内のメディアストリーム識別子が、「a=label:」属性行内のラベル値に変更されることである。
【００４８】
第２のモードでは、グループ属性行「a=group:semantics*(space identification-tag)」を使用してもよい。
【００４９】
「semantics」は、メディア制御チャネルに関する情報を識別し、これは、文字セット（ＲＴＳＰ  ＵＲＬ又はその他）あるいは数（ＲＴＳＰセッション識別子、ＲＴＳＰメディア制御ストリーム識別子、又はその他）であってもよい。
【００５０】
「identification-tag」は、メディアストリーム識別子を示し、これは、数、トークン、又はその他であってもよい。グループ属性行は、識別子が「identification-tag」であるメディアストリームが、統一されたメディア制御チャネルによって制御されることを示す。メディアストリーム識別子は、「a=mid:」ストリーム識別子属性行内のストリーム識別子値、又は「a=label:」ストリームラベル属性行内のストリームラベル値である。
【００５１】
例９は、以下の通りである。
a=group:rtsp://foo/twister 1 2
m=audio 1306 RTP/AVP 0
a=mid:1
m=video 1308 RTP/AVP 26
a=mid:2
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=mid:3
a=fmtp:rtsp h-uri=rtsp://foo/twister
【００５２】
「a=group:rtsp://foo/twister 1 2」は、グループ属性行であり、これは、メディアストリーム識別子１に対応する音声メディアストリーム及びメディアストリーム識別子２に対応する映像メディアストリームについての同期制御を示し、メディア制御情報は、「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」及び「m=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００５３】
メディアストリーム識別子が「a=label:」ストリームラベル属性行を採用するモードは、例９におけるモードに類似している。違いは、例９における「a=mid:」属性行が、「a=label:」属性行に置き換えられること、及び、グループ属性行内のメディアストリーム識別子が、「a=label:」属性行内のラベル値に変更されることである。
【００５４】
第３のモードでは、属性行を使用して、メディア配信チャネルのメディア行に対応するメディアストリームと、対応するメディア制御チャネルとの間の関係、すなわち、ＳＤＰにおける対応する記述情報の関係を記述する。
【００５５】
第３のモードでは、属性行「a=<attribute>:<value>」を使用し、ここで、「attribute」は、メディア制御属性を識別し、これは、文字セット又はその他であってもよく、「value」は、メディア制御チャネルに関する情報、及びメディアストリーム識別子に関する情報を識別する。メディア制御チャネルに関する情報は、文字セット又は数であってもよく、文字セットは、ＲＴＳＰ  ＵＲＬ又はその他であってもよく、数は、ＲＴＳＰセッション識別子、ＲＴＳＰメディア制御ストリーム識別子、又はその他であってもよく、ＲＴＳＰメディア制御ストリーム識別子及びメディアストリーム識別子は、数、トークン、又はその他であってもよい。ＲＴＳＰメディア制御ストリーム識別子及びメディアストリーム識別子は、「a=mid:」ストリーム識別子属性行内のストリーム識別子値、又は「a=label:」ストリームラベル属性行内のストリームラベル値である。
【００５６】
例１０は、以下の通りである。
A=rtspcontrol:rtsp://foo/twister 1 2
m=audio 1306 RTP/AVP 0
a=mid:1
m=video 1308 RTP/AVP 26
a=mid:2
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=mid:3
a=fmtp:rtsp h-uri=rtsp://foo/twister
【００５７】
「a=rtspcontrol:rtsp://foo/twister 1 2」は、メディアストリーム識別子１に対応する音声メディアストリーム及びメディアストリーム識別子２に対応する映像メディアストリームについての同期制御を示し、メディア制御情報は、「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００５８】
例１１は、以下の通りである。
A=rtspcontrol:rtsp://foo/twister 1
m=audio 1306 RTP/AVP 0
a=label:1
m=video 1308 RTP/AVP 26
a=label:1
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=fmtp:rtsp h-uri=rtsp://foo/twister
【００５９】
「a=rtspcontrol:rtsp://foo/twister 1」は、メディアストリームラベル識別子１に対応する音声メディアストリーム及び映像メディアストリームについての同期制御を示し、メディア制御情報は、「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬに対応するメディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００６０】
第４のモードでは、属性行を使用して、メディア配信チャネルのメディア行に対応するメディアストリームと、対応するメディア制御チャネルとの間の関係、すなわち、ＳＤＰにおける対応する記述情報の関係を記述する。
【００６１】
第４のモードでは、属性行「a=<attribute>:<value>」を使用し、ここで、「attribute」は、メディア制御属性を識別し、これは、文字セット又はその他であってもよく、「value」は、制御されるメディアストリームの識別子情報を識別する。メディアストリーム識別子に関する情報は、数、トークン、又はその他であってもよい。メディアストリーム識別子は、「a=mid:」ストリーム識別子属性行内のストリーム識別子値、又は「a=label:」ストリームラベル属性行内のストリームラベル値である。
【００６２】
例１２は、以下の通りである。
m=audio 1306 RTP/AVP 0//音声配信チャネルのメディア行を記述
a=label:1
m=video 1308 RTP/AVP 26//映像配信チャネルのメディア行を記述
a=label:1
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=rtspcontrol:1
【００６３】
「a=rtspcontrol:1」は、ラベル識別子１を有するメディアストリームが、対応するメディア制御チャネルによって制御されることを示し、「a=label:1」ラベル属性行は、音声ラベル識別子及び映像ラベル識別子が両方とも１であることと、音声及び映像メディアストリームが同期式に制御されることとを示し、メディア制御情報は、メディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。実際の拡張中に、「rtspcontrol」以外の文字が使用されてもよい。
【００６４】
例１３は、以下の通りである。
m=audio 1306 RTP/AVP 0//音声配信チャネルのメディア行を記述
a=mid:1
m=video 1308 RTP/AVP 26//映像配信チャネルのメディア行を記述
a=mid:2
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=rtspcontrol:1 2
【００６５】
「a=rtspcontrol:1 2」は、ストリーム識別子１及び２を有するメディアストリームが、対応するメディア制御チャネルによって制御されることを示し、「a=mid:」属性行は、音声ストリーム識別子及び映像ストリーム識別子が、それぞれ、１及び２であることと、音声及び映像メディアストリームが同期式に制御されることとを示し、メディア制御情報は、メディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。実際の拡張中に、「rtspcontrol」以外の文字が使用されてもよい。
【００６６】
複数のメディア制御チャネル（ＲＴＳＰなど）のメディア行と、複数のメディア配信チャネル（ＲＴＰなど）のメディア行とが利用可能である場合、複数のメディア制御チャネル（ＲＴＳＰなど）のメディア行の下の属性行（「a=rtspcontrol:」など）内の異なるメディアストリーム識別子と、メディア配信チャネル（ＲＴＰなど）のメディア行の下の、「a=label:」属性行内のストリームラベル値又は「a=mid:」属性行内のストリーム識別子値とを一致させることによって、異なるメディア制御チャネル（ＲＴＳＰなど）が、異なるメディアを制御するように指示され、例えば、１つのメディア制御チャネル（ＲＴＳＰなど）が音声メディアを制御し、別のメディア制御チャネル（ＲＴＳＰなど）が映像メディア及びテキストメディアを制御する。
【００６７】
第５のモードでは、メディア制御チャネル（ＲＴＳＰなど）のメディア行の下の属性行を使用して、メディア配信チャネルのメディア行に対応するメディアストリームと、対応するメディア制御チャネルとの間の関係、すなわち、ＳＤＰにおける対応する記述情報の関係を記述する。
【００６８】
第５のモードでは、属性行「a=<attribute>:<value>」を使用し、ここで、「attribute」は、メディア制御属性を識別し、これは、文字セット又はその他であってもよく、「value」は、メディア制御チャネルに関する情報、及びメディアストリーム識別子に関する情報を識別する。メディア制御チャネルに関する情報は、文字セット又は数であってもよく、文字セットは、ＲＴＳＰ  ＵＲＬ又はその他であってもよく、数は、ＲＴＳＰセッション識別子、ＲＴＳＰメディア制御ストリーム識別子、又はその他であってもよく、ＲＴＳＰメディア制御ストリーム識別子及びメディアストリーム識別子は、数、トークン、又はその他であってもよい。ＲＴＳＰメディア制御ストリーム識別子及びメディアストリーム識別子は、「a=mid:」ストリーム識別子属性行内のストリーム識別子値、又は「a=label:」ストリームラベル属性行内のストリームラベル値である。
【００６９】
例１４は、以下の通りである。
m=audio 1306 RTP/AVP 0
a=mid:1
m=video 1308 RTP/AVP 26
a=mid:2
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
A=rtspcontrol:rtsp://foo/twister 1 2
【００７０】
「a=rtspcontrol:rtsp://foo/twister 1 2」は、ストリーム識別子１及び２を有するメディアストリームが、「a=rtspcontrol」属性行（「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬを有する属性行）に対応するメディア制御チャネルによって制御されることを示し、「a=mid:」は、音声ストリーム識別子及び映像ストリーム識別子が、それぞれ、１及び２であることと、音声及び映像メディアストリームが同期式に制御されることとを示し、メディア制御情報は、メディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。実際の拡張中に、「rtspcontrol」以外の文字が使用されてもよい。
【００７１】
例１５は、以下の通りである。
m=audio 1306 RTP/AVP 0
a=label:1
m=video 1308 RTP/AVP 26
a=label:1
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=rtspcontrol:rtsp://foo/twister 1
【００７２】
「a=rtspcontrol:rtsp://foo/twister 1」は、ラベル識別子１を有するメディアストリームが、「a=rtspcontrol」属性行（「rtsp://foo/twister」というＲＴＳＰ  ＵＲＬを有する属性行）に対応するメディア制御チャネルによって制御されることを示し、「a=label:」は、音声ラベル識別子及び映像ラベル識別子が両方とも１であることと、音声及び映像メディアストリームが同期式に制御されることとを示し、メディア制御情報は、メディア制御チャネルの記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。実際の拡張中に、「rtspcontrol」以外の文字が使用されてもよい。
【００７３】
複数のメディア制御チャネル（ＲＴＳＰなど）のメディア行と、複数のメディア配信チャネル（ＲＴＰなど）のメディア行とが利用可能である場合、複数のメディア制御チャネル（ＲＴＳＰなど）のメディア行の下の属性行（「a=rtspcontrol:」など）内の異なるメディアストリーム識別子と、メディア配信チャネル（ＲＴＰなど）のメディア行の下の、「a=label:」属性行内のストリームラベル値又は「a=mid:」属性行内のストリーム識別子値とを一致させることによって、異なるメディア制御チャネル（ＲＴＳＰなど）が、異なるメディアを制御するように指示され、例えば、１つのメディア制御チャネル（ＲＴＳＰなど）が音声メディアを制御し、別のメディア制御チャネル（ＲＴＳＰなど）が映像メディア及びテキストメディアを制御する。
【００７４】
前述の実施形態では、ＲＴＳＰ  ＵＲＬを運ぶ属性行を例に取った。実際には、属性行は、ＳＩＰ  ＵＲＩ、ＴＶ  ＵＲＩ、又はメディアコンテンツを識別することが可能な任意の識別子を運んでもよい。
【００７５】
この実施形態では、属性行は、メディア制御チャネル（ＲＴＳＰなど）によって制御されるメディア配信チャネル（ＲＴＰなど）を示すために使用される。実施の形態はより柔軟である。すなわち、属性行は、１つのメディア制御チャネルの場合に制御される１つ以上のメディア配信チャネルを、又は、複数のメディア制御チャネルの場合に各メディア制御チャネルによって制御される１つ以上のメディアチャネルを示すために使用されてもよい。
【００７６】
本発明の第２の実施形態は、メディア制御セッション情報を取得するシステムを提供する。図２に示すように、システムは、
コンテンツ識別子を運ぶ要求を、コアＩＭＳを介してネットワーク装置２００に送信するように構成された、ＵＥ  １００と、
ＵＥ  １００によってコアＩＭＳを介して送信された要求を受信した後で、コンテンツ識別子に対応するメディア制御セッション情報を運ぶ、メディア制御グループの属性行を、コアＩＭＳを介してＵＥ  １００に送信するように構成された、ネットワーク装置２００と、
メディア制御セッション情報をネットワーク装置２００に提供するように構成された、コンテンツディスクリプタ機能エンティティ３００とを含む。
【００７７】
本発明の一実施形態は、ネットワーク装置を提供する。ネットワーク装置は、
様々なメディア制御セッション情報を運ぶ、メディア制御グループの属性行を有する応答を生成するように構成された、応答生成ユニット２１０と、
応答を、コアＩＭＳを介してＵＥに送信するように構成された、応答送信ユニット２２０と、
コンテンツ識別子に対応するメディア制御セッション情報を取得するように構成された、記述情報取得ユニット２３０とを含む。
【００７８】
本発明の一実施形態は、メディア制御セッション情報を取得するシステムを更に提供する。システムは、
コンテンツ識別子を運ぶ要求を、コアＩＭＳを介してネットワーク装置２００に送信するように構成された、ＵＥ  １００と、
ＵＥ  １００によってコアＩＭＳを介して送信された要求を受信した後で、コンテンツ識別子に対応するメディア制御セッション情報を運ぶメディア制御属性行（a=<attribute>:<value>）を、コアＩＭＳを介してＵＥ  １００に送信するように構成された、ネットワーク装置２００と（ここで、「attribute」は、メディア制御属性を識別し、「value」は、メディアストリーム識別子を識別する）、
メディア制御セッション情報をネットワーク装置２００に提供するように構成された、コンテンツディスクリプタ機能エンティティ３００とを含む。
【００７９】
本発明の一実施形態は、ネットワーク装置を更に提供する。ネットワーク装置は、
メディア制御セッション情報を運ぶメディア制御属性行（a=<attribute>:<value>）を有する応答を生成するように構成された、応答生成ユニット２１０と（ここで、「attribute」は、メディア制御属性を識別し、「value」は、メディアストリーム識別子を識別する）、
応答を、コアＩＭＳを介してＵＥに送信するように構成された、応答送信ユニット２２０と、
コンテンツ識別子に対応するメディア制御セッション情報を取得するように構成された、記述情報取得ユニット２３０とを含む。
【００８０】
本発明の第３の実施形態における、メディア記述情報を取得する方法は、以下の通りである。ＵＥは、ＣｏＤサービス要求を発し、その中では、ＳＤＰ  Ｏｆｆｅｒが、メディア制御チャネル及びメディア配信チャネルをネゴシエートすることに関する情報を運び、ＭＦは、コンテンツディスクリプタ機能エンティティから、同じコンテンツの様々なメディア構成要素の制御記述を取得した後で、ＳＤＰ  ＡｎｓｗｅｒをＵＥに返す。図３に示すように、プロセスは以下のステップを含む。
【００８１】
ステップＳ３０１：ＵＥは、コンテンツ識別子とＳＤＰ  Ｏｆｆｅｒとを運ぶＣｏＤサービス要求を、コアＩＭＳに発する。サービス要求は、ＳＩＰ  ＩＮＶＩＴＥメッセージ又はその他の要求であってもよい。
【００８２】
ステップＳ３０２：コアＩＭＳは、ＣｏＤサービス要求をＳＣＦに転送する。
【００８３】
ステップＳ３０３：ＳＣＦは、コンテンツ識別子に従って、適切なＭＦを選択し、次に、ＳＤＰ  ＯｆｆｅｒをＭＦに送信する。
【００８４】
ステップＳ３０４：ＭＦは、コンテンツディスクリプタ機能から、コンテンツ識別子に対応する同じコンテンツの様々なメディア構成要素の制御記述情報（１つのコンテンツに対応する複数のメディアストリームによって採用される、同期制御モード、個別制御モード、又はハイブリッド制御モードなど）を取得する。コンテンツディスクリプタ機能は、ＭＦの内部機能モジュールとして、又は、独立した機能エンティティとして働いてもよい。このステップは省略可能である。
【００８５】
ステップＳ３０５〜Ｓ３０７：同じコンテンツの様々なメディア構成要素の制御記述情報に従って、ＭＦは、属性行を含む対応するＳＤＰ  Ａｎｓｗｅｒ（各メディアストリームの制御セッション情報を示すための、第１の実施形態で説明した情報など）を生成し、ＭＦは、２００  ＯＫ、１８３要求、又はその他であってもよいサービス応答を介して、ＵＥにＳＤＰ  Ａｎｓｗｅｒを返す。
【００８６】
本発明の第４の実施形態における、メディア記述情報を取得する方法は、以下の通りである。ＵＥは、ＣｏＤサービス要求を発し、その中では、ＳＤＰ  Ｏｆｆｅｒが、メディア制御チャネル及びメディア配信チャネルをネゴシエートすることに関する情報を運び、ＳＣＦは、コンテンツディスクリプタ機能エンティティから、同じコンテンツの様々なメディア構成要素の制御記述を取得した後で、ＳＤＰ  ＡｎｓｗｅｒをＵＥに返す。図４に示すように、プロセスは以下のステップを含む。
【００８７】
ステップＳ４０１〜Ｓ４０２：ＵＥは、コンテンツ識別子とＳＤＰ  Ｏｆｆｅｒとを運ぶＣｏＤサービス要求を、コアＩＭＳを介してＳＣＦに発する。サービス要求は、ＳＩＰ  ＩＮＶＩＴＥメッセージ又はその他の要求であってもよい。
【００８８】
ステップＳ４０３：ＳＣＦは、コンテンツ識別子に従って、適切なＭＦを選択し、次に、ＳＤＰ  ＯｆｆｅｒをＭＦに送信する。
【００８９】
ステップＳ４０４：ＭＦは、コンテンツ制御チャネル及びコンテンツ配信チャネルの記述情報を運ぶＳＤＰ  Ａｎｓｗｅｒを、ＳＣＦに返す。
【００９０】
ステップＳ４０５：ＳＣＦは、コンテンツディスクリプタ機能から、コンテンツ識別子に対応する同じコンテンツの様々なメディア構成要素の制御記述情報（１つのコンテンツに対応する複数のメディアストリームによって採用される、同期制御モード、個別制御モード、又はハイブリッド制御モードなど）を取得する。コンテンツディスクリプタ機能は、ＳＣＦの内部機能モジュールとして、又は、独立した機能エンティティとして働いてもよい。このステップは省略可能である。
【００９１】
ステップＳ４０６〜Ｓ４０７：同じコンテンツの様々なメディア構成要素の制御記述情報に従って、ＳＣＦは、属性行を含む対応するＳＤＰ  Ａｎｓｗｅｒ（各メディアストリームの制御セッション情報を示すための、第１の実施形態で説明した情報など）を生成し、ＳＣＦは、２００  ＯＫ、１８３要求、又はその他であってもよいサービス応答を介して、ＵＥにＳＤＰ  Ａｎｓｗｅｒを返す。
【００９２】
図５に示すように、本発明の第５の実施形態は、メディア制御を実施する方法を提供する。方法は以下のステップを含む。
【００９３】
ステップＳ５０１：ＵＥは、メディア制御チャネルとメディア配信チャネルとの間の関係に関する情報を運ぶ要求を、コアＩＭＳを介してネットワーク装置に送信する。
【００９４】
メディア制御チャネルとメディア配信チャネルとの間の関係に関する情報は、サービス選択機能（ＳＳＦ）から取得されて、第１の実施形態で説明したモードで、要求のＳＤＰ属性行内で運ばれ、コアＩＭＳを介してネットワーク装置に送信されてもよい。
【００９５】
説明を容易にするために、要求内で関係情報を運ぶモードを以下に例示する。
a=group:rtspcontrol 1 2
m=audio 1306 RTP/AVP 0//メディア配信チャネルのメディア行を記述
a=mid:1
m=video 1308 RTP/AVP 26//メディア配信チャネルのメディア行を記述
a=mid:2
m=text 1310 RTP/AVP wb
a=mid:3
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=mid:4
【００９６】
「a=group:rtspcontrol 1 2」は、グループ属性行であり、これは、メディアストリーム識別子１に対応する音声メディアストリーム及びメディアストリーム識別子２に対応する映像メディアストリームについての同期制御を示し、メディア制御チャネル情報は、メディア制御チャネルに対応するメディア記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。メディアストリーム識別子４に対応するテキストメディアストリームについてのメディアストリームを制御するためのメディア制御チャネルは存在しない。「a=」及び「m=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【００９７】
メディアストリーム識別子が「a=label:」ストリームラベル属性行を採用するモードは、例６におけるモードに類似している。違いは、例６における「a=mid:」属性行が、「a=label:」属性行に置き換えられること、及び、グループ属性行内のメディアストリーム識別子が、「a=label:」属性行内のラベル値に変更されることである。
【００９８】
前述のモードは、本発明の例示的実施形態にすぎない。その他のモードについては、第１の実施形態における詳細な説明を参照されたい。モードの変更は、本発明の保護範囲に影響を及ぼさない。
【００９９】
ステップＳ５０２：ネットワーク装置は、メディア記述情報を運ぶ応答をＵＥに返す。
【０１００】
具体的には、メディア記述情報は、応答のＳＤＰ属性行内で運ばれてもよい、メディア配信チャネル及び／又はメディア制御チャネルに関する情報である。
【０１０１】
ステップＳ５０３：ＵＥは、関係情報とメディア記述情報とに従って、メディア制御を実行する。
【０１０２】
この実施形態におけるネットワーク装置は、ネットワーク装置の前述の機能を実施することが可能な、ＳＣＦ、ＭＦ、又はその他のネットワークエンティティであり、特定のエンティティの変形は、本発明の保護範囲に影響を及ぼさない。
【０１０３】
図６に示すように、本発明の第６の実施形態は、メディア制御を実施する方法を提供する。方法は以下のステップを含む。
【０１０４】
ステップＳ６０１：ＵＥは、サービス要求を、コアＩＭＳを介してネットワーク装置に送信する。
【０１０５】
ＵＥは、コンテンツ識別子を運ぶＣｏＤサービス要求を、コアＩＭＳに発する。サービス要求は、ＳＩＰ  ＩＮＶＩＴＥメッセージ又はその他の要求であってもよい。
【０１０６】
ステップＳ６０２：ネットワーク装置は、関係情報とメディア記述情報とを運ぶ応答をＵＥに返す。
【０１０７】
関係情報は、メディア制御チャネルとメディア配信チャネルとの間の関係に関する情報を示し、第１の実施形態で説明したモードで、応答のＳＤＰ属性行内で運ばれる。
【０１０８】
説明を容易にするために、要求内で関係情報を運ぶモードを以下に例示する。
a=group:rtspcontrol 3 1 2
m=audio 1306 RTP/AVP 0//音声メディア配信チャネルのメディア行を記述
a=mid:1
m=video 1308 RTP/AVP 26//映像メディア配信チャネルのメディア行を記述
a=mid:2
m=application 9 TCP iptv_rtsp//メディア制御チャネルのメディア行を記述
a=mid:3
【０１０９】
「a=group:rtspcontrol 3 1 2」は、グループ属性行であり、これは、メディアストリーム識別子１に対応する音声メディアストリーム及びメディアストリーム識別子２に対応する映像メディアストリームについての同期制御を示し、メディア制御情報は、メディアストリーム識別子３に対応するメディア記述情報を示し、記述情報は、メディア行と、属性行と、ＲＴＳＰセッション属性行と、ＲＴＳＰメディアストリーム識別子の属性行とのうちの１つ以上（ただしこれに限定されない）を含む。「a=」及び「m=」行の記述は、単なる例であり、特定の形態を限定することを意図するものではない。
【０１１０】
メディアストリーム識別子が「a=label:」ストリームラベル属性行を採用するモードは、例８におけるモードに類似している。違いは、例８における「a=mid:」属性行が、「a=label:」属性行に置き換えられること、及び、グループ属性行内のメディアストリーム識別子が、「a=label:」属性行内のラベル値に変更されることである。
【０１１１】
前述のモードは、本発明の例示的実施形態にすぎない。その他のモードについては、第１の実施形態における詳細な説明を参照されたい。モードの変更は、本発明の保護範囲に影響を及ぼさない。
【０１１２】
ステップＳ６０３：ＵＥは、関係情報とメディア記述情報とに従って、メディア制御を実行する。
【０１１３】
この実施形態におけるネットワーク装置は、ネットワーク装置の前述の機能を実施することが可能な、ＳＣＦ、ＭＦ、又はその他のネットワークエンティティであり、特定のエンティティの変形は、本発明の保護範囲に影響を及ぼさない。
【０１１４】
図７に示すように、本発明の第７の実施形態は、メディア制御を実施するシステムを提供する。システムは、メディア制御チャネルとメディア配信チャネルとの間の関係に関する情報を取得し、関係情報とメディア記述情報とに従ってメディア制御を実行するように構成された、ＵＥ  １を含む。
発明
【０１１５】
ＵＥ  １は、要求（その中で、ＳＤＰが関係情報を運ぶ）を、コアＩＭＳを介してネットワーク装置２に送信するように更に構成される。
【０１１６】
更に、システムは、応答（その中で、ＳＤＰが、メディア制御チャネルとメディア配信チャネルとの間の関係に関する情報を運ぶ）を送信するように構成された、ネットワーク装置２も含んでもよい。
【０１１７】
更に、システムは、メディア制御チャネルとメディア配信チャネルとの間の関係に関する情報をＵＥ  １に提供するように構成された、ＳＳＦ  ３も含んでもよい。ＳＳＦは、ＥＰＧ情報のエンティティなどの、ＩＭＳベースのＩＰＴＶアーキテクチャにおけるサービス選択情報を提供する。
【０１１８】
システムの前述の実施形態では、ネットワーク装置２は、ＳＣＦ、ＭＦ、又はその他のエンティティであってもよい。
【０１１９】
本発明の一実施形態は、ＵＥ  １を更に提供する。ＵＥ  １は、
メディア制御チャネルとメディア配信チャネルとの間の関係に関する情報を取得するように構成された、取得ユニット１１と、
関係情報とメディア記述情報とに従ってメディア制御を実行するように構成された、制御ユニット１２とを含む。
【０１２０】
更に、ＵＥ  １は、要求（その中で、ＳＤＰが、メディア制御チャネルとメディア配信チャネルとの間の関係に関する情報を運ぶ）を送信するように構成された、送信ユニット１３も含んでもよい。
【０１２１】
本発明の一実施形態は、ネットワーク装置２を更に提供する。ネットワーク装置２は、
要求を受信するように構成された、受信ユニット２１と、
応答（その中で、ＳＤＰが、メディア制御チャネルとメディア配信チャネルとの間の関係に関する情報を運ぶ）を送信するように構成された、送信ユニット２２とを含む。
【０１２２】
更に、ＳＳＦ  ３は、ＥＰＧなどのサービス選択情報を提供するように構成される。
【０１２３】
この実施形態では、ネットワーク装置２は、ＳＣＦ、ＭＦ、又はその他のエンティティであってもよい。
【０１２４】
本発明の実施形態では、メディア制御チャネル（ＲＴＳＰなど）によって制御されるメディア配信チャネル（ＲＴＰなど）を記述するために、ＳＩＰ／ＳＤＰメッセージの属性行が使用され、かくして、ＣｏＤサービスにおけるコンテンツの、全てのメディア配信チャネルについての同期ＶＣＲ動作、又は、１つのメディア配信チャネルについてのＶＣＲ動作が実施される。
【０１２５】
従来技術では、ＣｏＤサービスプロセスにおけるセッションセットアップの主な特徴は以下の通りである。ＣｏＤサービスプロセスにおいて、ユーザは、見られるコンテンツに対する、前送り、巻き戻し、及び一時停止などの、ＶＣＲ制御を実行する可能性があり、従って、ＶＣＲ動作のために使用されるメディア制御チャネルと、見られるコンテンツを伝送するために使用されるメディア配信チャネルとが、サービスのために確立される必要がある。メディア制御チャネルとメディア配信チャネルとを確立する様々なモードに従って、ＴＩＳＰＡＮによって規定されたＣｏＤサービスプロセスは２つのモードを含む。第１のモードでは、メディア制御チャネルとメディア配信チャネルとが、ＳＩＰセッションセットアップ中に同時に確立される。第２のモードでは、メディア制御チャネルが初期セッションセットアップ中に確立され、次に、メディア配信チャネルが、セッション変更を介して確立される。
【０１２６】
第１のモードを使用するための必須条件は、ＵＥが、コンテンツのメディア行（例えば、音声、映像、及びテキストメディア行）などの、見られるコンテンツのメディア情報を、電子番組案内（ＥＰＧ）から取得済みであるということである。従って、メディア配信チャネルがネゴシエートされて確立されることが可能である。第２のモードが採用される場合は、メディア制御チャネル（一般に、ＲＴＳＰチャネル）が、ＳＩＰセッションセットアッププロセスを介して、ネゴシエートされて確立され、メディア交換制御セッションが、ＵＥとＭＦとの間にセットアップされ、メディアのネットワークパラメータ情報が、メディア制御メッセージを交換することによって取得され、次に、コンテンツ配信チャネルが、セッション変更中に確立される。
【０１２７】
実際には、第１のモードと比較して、第２のモードは、セッションセットアップに長い時間を要する、という欠点を有する。一般的なプロセスは、以下の通りである。（ＳＩＰメッセージを使用することによって）最初にセッションがセットアップされた後で、ＵＥとネットワーク（ＭＦ）とは、メディア制御メッセージ（一般に、ＲＴＳＰ  ＤＥＳＣＲＩＢＥメッセージ）を発してメディア制御セッションをセットアップし、メディア制御セッションメッセージ内でメディアコンテンツを交換し、最後に、（ＳＩＰメッセージを使用することによる）セッション変更プロセスを介してメディアチャネルが確立される。結果として、ユーザのサービス体験は貧弱なものとなる。従って、現在の仕様における第２のモードの適用に対する制限は、以下の通りである。初期セッションセットアップ中にコンテンツ配信チャネルを確立すること、すなわち、第２のモードは、ネットワークが、コンテンツ配信チャネルのネットワークパラメータ情報ではなく、メディア制御チャネルのネットワークパラメータ情報のみをユーザに提供する場合のみ選択可能である。しかし、第２のモードが採用される場合、より多くの相互作用がＵＥとネットワークとの間で必要とされ、より多くの要求がＵＥに対して提起され、セッションセットアップは遅らされ、ユーザ体験は貧弱なものとなる。
【０１２８】
本発明の実施形態では、コンテンツのネットワークパラメータ又はメディア情報をＳＳＦから取得することができない場合（例えば、ＵＥが、ＥＰＧの機能と同等であるＳＳＦにアクセスすることができず、通常はＨＴＴＰを採用する場合、又は、ＵＥがＳＳＦにアクセスすることはできるが、必要とされる情報をＳＳＦが提供しない場合、又は、ＵＥがＳＳＦにアクセスしない場合）に、ＳＩＰセッションメッセージのうちのＯＰＴＩＯＮＳメソッドを使用して、サービス要求を直接発して、コンテンツのネットワークパラメータ及び／又はメディア情報を動的に取得し、これにより、ＵＥがＳＳＦからネットワークパラメータを取得しない場合に、ＵＥは、仕様の第１のモード又は仕様の改良された第２のモードを採用できるようになる。
【０１２９】
ＣｏＤセッション要求を発する前に、ＵＥは、ＳＩＰ  ＯＰＴＩＯＮＳメソッドを使用して、ネットワークに要求を発して、ネットワークエンティティ（図７のＭＦ）の、メディア制御チャネル（ＲＴＳＰなど）のネットワークパラメータ情報、及び／又は、要求されたコンテンツのネットワークパラメータ、及び／又は、メディア配信チャネルの記述情報を要求し、ネットワークは、メディア制御チャネルのネットワークパラメータ情報、及び／又は、要求されたコンテンツのネットワークパラメータ、及び／又は、メディア配信チャネルの記述情報を、ＳＩＰ  ＯＰＴＩＯＮＳメッセージへの応答内で返す。従って、ＵＥは、セッション要求を発する前に、メディア制御チャネル（ＲＴＳＰなど）のネットワークパラメータ、及びメディア配信チャネルに関する情報を取得することができる。故に、前述の第１のモードを使用して、ＣｏＤサービス要求を発し、メディア制御チャネルとメディア配信チャネルとを確立することが可能である。
【０１３０】
更に、第２のモードが採用される場合、メディア制御チャネル（ＲＴＳＰなど）の確立に関する初期ネゴシエーションの後で、メディア配信チャネルに関する情報を取得するために制御メッセージが使用される必要があり、次に、ＳＩＰを介してセッションがセットアップされる。従って、このモードの効率は低い。
【０１３１】
第２のモードにおける、メディア制御チャネルの確立に関する初期ネゴシエーション中に、ＵＥは、ＳＩＰ  ＯＰＴＩＯＮＳメソッドを使用することによって要求を発して、要求されたコンテンツのネットワークパラメータ、及び／又は、メディア配信チャネルに関する情報を、ＳＩＰセッションセットアップ中に、又はＳＩＰセッションセットアップの後で取得してもよく（このステップにより、ＵＥとネットワークとが、コンテンツのネットワークパラメータ、及び／又は、メディア配信チャネルに関する情報を、メディア制御チャネルを介して取得するプロセスは完了する）、要求された情報が取得された後で、仕様に記載されているセッション変更プロセスを介して、メディア配信チャネルが確立される。この解決法においては、コンテンツのネットワークパラメータ、及び／又は、メディア配信チャネルに関する情報を取得するステップは、メディア制御チャネルをネゴシエートして確立するステップと共に実行されてもよく、前述の解決法では、２つのステップは順に完了される。従って、本解決法は、セッションセットアップ中の、ＵＥと複数のネットワークエンティティとの間の過剰な相互作用だけでなく、メディア制御チャネルのセットアップ及びメディア配信チャネルのセットアップを含む、全体的なセッションセットアップの時間の短縮に寄与し、ユーザのサービス体験を向上させる。
【０１３２】
本発明の第８の実施形態では、ＣｏＤセッション要求を発する前に、ＵＥは、メディア制御チャネルのネットワークパラメータ情報、及び／又は、メディア配信チャネルのネットワークパラメータを要求する。図８に示すように、プロセスは以下のステップを含む。
【０１３３】
ステップＳ８０１：ＣｏＤセッション要求を発する前に、ＵＥは、ＳＩＰ  ＯＰＴＩＯＮＳ要求をコアＩＭＳに発する。運ばれるメッセージパラメータは、以下の通りである。
OPTIONS sip:XXXMoiveID@XXtele.com SIP/2.0
Via:SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:XXXMoivelD@XXtele.com>
From: Alice<sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 0
【０１３４】
このステップにおける要求のパラメータ記述は、例としてのみ役立つ。実際の実施中には、記述形態はこれに限定されず、他の記述形態が採用されてもよい。メッセージは、要求されたＣｏＤ識別子、すなわち、XXXMoiveIDを運ぶ。メッセージ内で、Acceptヘッダフィールドは、受信されるメッセージボディのタイプがＳＤＰメッセージであることを示す。ＳＤＰメッセージは、実施中には、ＸＭＬメッセージ又は別のタイプのメッセージであってもよい。受信されるメッセージボディのタイプがＸＭＬメッセージ又は別のタイプのメッセージであることを可能にするには、Acceptヘッダフィールド内の「application/sdp」を「application/xml」又は「application/xxx」に変更する。
【０１３５】
ステップＳ８０２：コアＩＭＳは、要求を、ＣｏＤサービスを提供するＳＣＦに転送する。
【０１３６】
ステップＳ８０３：XXXMoiveIDに従って、ＳＣＦは、適切なＭＦを選択する。選択機能は、ＭＦ上で完了してもよく、ＭＦが他の適切なＭＦを選択して要求を転送し、あるいは、選択機能は別の独立した機能エンティティ上で完了する。特定のモードが本発明と関係があるわけではない。
【０１３７】
ステップＳ８０４：ＳＣＦは、要求を、選択されたＭＦに転送する。
【０１３８】
ステップＳ８０５：XXXMoiveIDに従って、ＭＦは、コンテンツのメディア記述情報と、メディア制御チャネル及び／又はメディア配信チャネルのネットワークパラメータ情報とを、コンテンツディスクリプタ機能から取得する。コンテンツディスクリプタ機能は、ＭＦ内の機能であってもよく、又は独立した機能エンティティであってもよい。このステップは省略可能である。
【０１３９】
ステップＳ８０６：ＭＦは、２００  ＯＫメッセージをＳＣＦに返し、２００  ＯＫメッセージは以下のパラメータを運ぶ。
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877;received=192.0.2.4
To: <sip: XXXMoiveID@XXtele.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip: XXXMoiveID@XXtele.com>
Accept: application/sdp
Content-Type: application/sdp
Content-Length: 164
v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93//ネットワークアドレス情報
s=RTSP Session
i=An Example of RTSP Session Usage
a=control:rtsp://foo/twister//メディア制御セッション情報
t=0 0
m=audio 0 RTP/AVP 0//音声符号などの、音声行メディア情報
a=control:rtsp://foo/twister/audio
m=video 0 RTP/AVP 26//映像符号などの、映像行メディア情報
a=control:rtsp://foo/twister/video
...//その他の可能なメディア属性情報
【０１４０】
このステップにおける応答のパラメータ記述は、例としてのみ役立つ。実際の実施中には、記述形態はこれに限定されず、他の記述形態が採用されてもよい。要求内のAcceptヘッダフィールドは、受信されるメッセージボディのタイプがＳＤＰメッセージであることを示しており、従って、応答内のメッセージボディのタイプもＳＤＰメッセージである。実際の実施中に、要求のAcceptヘッダフィールド内で示される、受信されるメッセージボディのタイプは、ＸＭＬメッセージ又は別のタイプのメッセージであってもよく、それに応じて、応答内のメッセージボディのタイプも、ＸＭＬメッセージ又は別のタイプのメッセージであってもよい。メッセージボディのタイプがＸＭＬメッセージ又は別のタイプのメッセージであることを可能にするには、Content-Typeヘッダフィールド内の「application/sdp」を「application/xml」又は「application/xxx」に変更する。メディア制御セッション情報の記述モードは、第１の実施形態で説明した別のモードであってもよい。
【０１４１】
ＸＭＬモードの場合、メッセージボディの詳細な内容の例は、以下の通りである。
<xml description>
Audio/Video/Text//メディア構成
Codec//様々なメディアのコーデック
...//異なるメディア構成要素が、独立したＶＣＲ動作、及び継続時間を許可するかどうかなどの、その他のコンテンツ記述情報
<xml description>
【０１４２】
ステップＳ８０７：ＳＣＦは、２００  ＯＫメッセージをコアＩＭＳに返す。
【０１４３】
ステップＳ８０８：コアＩＭＳは、２００  ＯＫメッセージをＵＥに返す。
【０１４４】
要求されたコンテンツのメディア配信情報を動的に取得した後、ＵＥは、コンテンツのメディア行（例えば、音声、映像、及びテキストメディア行）などの、見られるコンテンツのメディア情報を、ＥＰＧから取得済みである。次に、現在の仕様で規定された第１のモードが採用されてもよく、すなわち、メディア制御チャネルとメディア配信チャネルとが、初期セッションセットアップ中に同時に確立される。
【０１４５】
本発明の第９の実施形態では、ＣｏＤセッション要求を発する前に、ＵＥは、メディア制御チャネル及び／又はメディア配信チャネルの、ネットワークパラメータ情報を取得する。図９に示すように、プロセスは以下のステップを含む。
【０１４６】
ステップＳ９０１：ＣｏＤセッション要求を発する前に、ＵＥは、ＳＩＰ  ＯＰＴＩＯＮＳ要求をコアＩＭＳに発する。運ばれるメッセージパラメータは、以下の通りである。
OPTIONS sip:XXXMoiveID@XXtele.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip: XXXMoiveID@XXtele.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/xml
Content-Length: 0
【０１４７】
このステップにおける要求のパラメータ記述は、例としてのみ役立つ。実際の実施中には、記述形態はこれに限定されず、他の記述形態が採用されてもよい。メッセージは、要求されたＣｏＤ識別子、すなわち、XXXMoiveIDを運ぶ。メッセージ内で、Acceptヘッダフィールドは、受信されるメッセージボディのタイプがＸＭＬメッセージであることを示す。ＸＭＬメッセージは、実施中には、ＳＤＰメッセージ又は別のタイプのメッセージであってもよい。受信されるメッセージボディのタイプがＳＤＰメッセージ又は別のタイプのメッセージであることを可能にするには、Acceptヘッダフィールド内の「application/xml」を「application/sdp」又は「application/xxx」に変更する。
【０１４８】
ステップＳ９０２：コアＩＭＳは、要求を、ＣｏＤサービスを提供するＳＣＦに転送する。
【０１４９】
ステップＳ９０３：XXXMoiveIDに従って、ＳＣＦは、コンテンツのメディア記述情報と、メディア制御チャネル及び／又はメディア配信チャネルのネットワークパラメータ情報とを、コンテンツディスクリプタ機能から取得する。コンテンツディスクリプタ機能は、ＳＣＦ内の機能であってもよく、又は独立した機能エンティティであってもよい。このステップは省略可能である。
【０１５０】
ステップＳ９０４：ＳＣＦは、２００  ＯＫメッセージをコアＩＭＳに返し、２００  ＯＫメッセージは以下のパラメータを運ぶ。
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877;received=192.0.2.4
To: <sip: XXXMoiveID@XXtele.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip: XXXMoiveID@XXtele.com>
Accept: application/xml
Content-Type: application/xml
Content-Length: 164
<xml description>
Audio/Video/Text//メディア構成
Codec//様々なメディアのコーデック
...//異なるメディア構成要素が、独立したＶＣＲ動作、及び継続時間を許可するかどうかなどの、その他のコンテンツ記述情報
<xml description>
【０１５１】
このステップにおける応答のパラメータ記述は、例としてのみ役立つ。実際の実施中には、記述形態はこれに限定されず、他の記述形態が採用されてもよい。要求内のAcceptヘッダフィールドは、受信されるメッセージボディのタイプがＸＭＬメッセージであることを示しており、従って、応答内のメッセージボディのタイプもＸＭＬメッセージである。実際の実施中に、要求のAcceptヘッダフィールド内で示される、受信されるメッセージボディのタイプは、ＳＤＰメッセージ又は別のタイプのメッセージであってもよく、それに応じて、応答内のメッセージボディのタイプも、ＳＤＰメッセージ又は別のタイプのメッセージであってもよい。メッセージボディのタイプがＳＤＰメッセージ又は別のタイプのメッセージであることを可能にするには、Content-Typeヘッダフィールド内の「application/xml」を「application/sdp」又は「application/xxx」に変更する。
【０１５２】
ＳＤＰモードの場合、メッセージボディの詳細な内容の例は、以下の通りである。
v=0
m=audio 0 RTP/AVP 0//音声符号などの、音声行メディア情報
a=control:rtsp://foo/twister/audio
m=video 0 RTP/AVP 26//映像符号などの、映像行メディア情報
a=control:rtsp://foo/twister/video
...//その他の可能なメディア属性情報
【０１５３】
メディア制御セッション情報の記述モードは、第１の実施形態で説明した別のモードであってもよい。
【０１５４】
ステップＳ９０５：コアＩＭＳは、２００  ＯＫメッセージをＵＥに返す。
【０１５５】
要求されたコンテンツのメディア制御チャネル及び／又はメディア配信チャネルのネットワークパラメータをＵＥが取得した後で、現在の仕様で規定された第１のモードが採用されてもよく、すなわち、メディア制御チャネルとコンテンツチャネルとが、初期セッションセットアップ中に同時に確立される。
【０１５６】
本発明の第１０の実施形態では、ＵＥは、ＣｏＤセッション要求を発する際に、メディア配信チャネルに関する情報を要求する。図１０に示すように、プロセスは以下のステップを含む。
【０１５７】
第２のモードに従って、ＵＥは、初期セッションセットアップを開始し、メディア制御チャネルのみをネゴシエートする。このプロセスにおいて、ＵＥは、メディア配信チャネルに関する情報を取得するプロセスも開始してもよい。図１０のｓ１００１〜ｓ１００７に示すように、詳細なプロセスは以下の通りである。
【０１５８】
ステップＳ１００１：ＵＥは、ＳＩＰ  ＯＰＴＩＯＮＳ要求をコアＩＭＳに発する。運ばれるメッセージパラメータは、以下の通りである。
OPTIONS sip:XXXMoiveID@XXtele.com SIP/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKhjhs8ass877//パラメータは、初期セッションセットアッププロセスにおけるＳＩＰメッセージパラメータと同じであり、以下のパラメータ処理メカニズムは、初期セッションセットアッププロセスにおけるパラメータ処理メカニズムに類似している:
Max-Forwards: 70
To: <sip: XXXMoiveID@XXtele.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:alice@pc33.atlanta.com>
Accept: application/sdp
Content-Length: 0
【０１５９】
このステップにおける要求のパラメータ記述は、例としてのみ役立つ。実際の実施中には、記述形態はこれに限定されず、他の記述形態が採用されてもよい。メッセージは、要求されたＣｏＤ識別子、すなわち、XXXMoiveIDを運ぶ。メッセージ内で、Acceptヘッダフィールドは、受信されるメッセージボディのタイプがＳＤＰメッセージであることを示す。ＳＤＰメッセージは、実施中には、ＸＭＬメッセージ又は別のタイプのメッセージであってもよい。受信されるメッセージボディのタイプがＸＭＬメッセージ又は別のタイプのメッセージであることを可能にするには、Acceptヘッダフィールド内の「application/sdp」を「application/xml」又は「application/xxx」に変更する。
【０１６０】
ステップＳ１００２：コアＩＭＳは、要求を、ＣｏＤサービスを提供するＳＣＦに転送する。
【０１６１】
ステップＳ１００３：ＳＣＦは、要求を、初期セッションセットアップ中に選択されたＭＦに転送する。
【０１６２】
ステップＳ１００４：要求されたコンテンツ識別子、すなわち、XXXMoiveIDに従って、ＭＦは、コンテンツのメディア記述情報、及び／又は、メディア配信チャネルのネットワークパラメータ情報を、コンテンツディスクリプタ機能から取得する。コンテンツディスクリプタ機能は、ＭＦ内の機能であってもよく、又は独立した機能エンティティであってもよい。このステップは省略可能である。
【０１６３】
ステップＳ１００５：ＭＦは、２００  ＯＫメッセージをＳＣＦに返し、応答は以下のパラメータを運ぶ。
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877;received=192.0.2.4
To: <sip: XXXMoiveID@XXtele.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip: XXXMoiveID@XXtele.com>
Accept: application/sdp
Content-Type: application/sdp
Content-Length: 164
v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93//ネットワークアドレス情報
t=0 0
m=audio 0 RTP/AVP 0//音声符号などの、音声行メディア情報
a=control:rtsp://foo/twister/audio
m=video 0 RTP/AVP 26//映像符号などの、映像行メディア情報
a=control:rtsp://foo/twister/video
...//その他の可能なメディア属性情報
【０１６４】
このステップにおける応答のパラメータ記述は、例としてのみ役立つ。実際の実施中には、記述形態はこれに限定されず、他の記述形態が採用されてもよい。要求内のAcceptヘッダフィールドは、受信されるメッセージボディのタイプがＳＤＰメッセージであることを示しており、従って、応答内のメッセージボディのタイプもＳＤＰメッセージである。実際の実施中に、要求のAcceptヘッダフィールド内で示される、受信されるメッセージボディのタイプは、ＸＭＬメッセージ又は別のタイプのメッセージであってもよく、それに応じて、応答内のメッセージボディのタイプも、ＸＭＬメッセージ又は別のタイプのメッセージであってもよい。メッセージボディのタイプがＸＭＬメッセージ又は別のタイプのメッセージであることを可能にするには、Content-Typeヘッダフィールド内の「application/sdp」を「application/xml」又は「application/xxx」に変更する。メディア制御セッション情報の記述モードは、第１の実施形態で説明した別のモードであってもよい。
【０１６５】
ＸＭＬメッセージの内容は、第５の実施形態におけるものに類似している。
【０１６６】
ステップＳ１００６：ＳＣＦは、２００  ＯＫメッセージをコアＩＭＳに返す。
【０１６７】
ステップＳ１００７：コアＩＭＳは、２００  ＯＫメッセージをＵＥに返す。
【０１６８】
要求されたコンテンツのメディア配信チャネル情報をＵＥが取得した後、現在の仕様で規定されたセッション変更プロセスが、メディア配信チャネルをネゴシエートして確立するために使用され、これは、元のプロセス（メディア制御チャネルが確立され、メディア制御チャネルのインタラクションによって、要求されたコンテンツのメディア配信チャネル情報が取得された後で、メディア配信チャネルを確立するためにセッション変更プロセスが開始される）とは異なる。従って、ＣｏＤセッションセットアッププロセスは改良される。
【０１６９】
この実施形態では、ＳＩＰ  ＯＰＴＩＯＮＳメッセージが処理のためにＭＦに送信され、メディア配信チャネルに関する情報が返される。ＳＩＰ  ＯＰＴＩＯＮＳメッセージは、ＳＣＦによって処理されてもよく、その処理モードは第６の実施形態におけるものに類似している。
【０１７０】
本発明の第１１の実施形態では、ＵＥがＣｏＤサービス要求を発し、メディア制御チャネルをネゴシエートすることに関する情報がＳＤＰ  Ｏｆｆｅｒ内で運ばれ、ＭＦが、コンテンツ配信チャネルのメディア記述情報を取得した後で、ＸＭＬ又はリンクモードでの、コンテンツ配信チャネルのメディア記述情報を運ぶ、ＳＤＰ  ＡｎｓｗｅｒをＵＥに返す。図１１に示すように、プロセスは以下のステップを含む。
【０１７１】
ステップＳ１１０１：ＵＥは、コンテンツ識別子とＳＤＰ  Ｏｆｆｅｒとを運ぶＣｏＤサービス要求を、コアＩＭＳに発する。サービス要求は、ＳＩＰ  ＩＮＶＩＴＥメッセージ又はその他の要求であってもよい。
【０１７２】
ステップＳ１１０２：コアＩＭＳは、ＣｏＤサービス要求をＳＣＦに転送する。
【０１７３】
ステップＳ１１０３：ＳＣＦは、コンテンツ識別子を介して、適切なＭＦを選択し、次に、ＳＤＰ  ＯｆｆｅｒをＭＦに送信する。
【０１７４】
ステップＳ１１０４：ＭＦは、コンテンツディスクリプタ機能から、コンテンツ識別子に対応するコンテンツ配信チャネルのメディア記述情報を取得する。コンテンツディスクリプタ機能は、ＭＦの内部機能モジュールとして、又は、独立した機能エンティティとして働いてもよい。このステップは省略可能である。
【０１７５】
ステップＳ１１０５〜Ｓ１１０７：取得した、コンテンツ配信チャネルのメディア記述情報に従って、ＭＦは、ＸＭＬ又はリンクモードでの、コンテンツ配信チャネルのメディア記述情報を、返されるサービス応答（例えば、２００  ＯＫメッセージ、１８３要求、又は別のメッセージ）内で運ぶ、対応するＳＤＰ  Ａｎｓｗｅｒを生成する。ＸＭＬ記述は、前述の実施形態におけるものに類似している。
【０１７６】
要求されたコンテンツのメディア配信チャネル情報をＵＥが取得した後、現在の仕様で規定されたセッション変更プロセスが、メディア配信チャネルをネゴシエートして確立するために使用され、これは、元のプロセス（メディア制御チャネルが確立され、メディア制御チャネルのインタラクションによって、要求されたコンテンツのメディア配信チャネル情報が取得された後で、メディア配信チャネルを確立するためにセッション変更プロセスが開始される）とは異なる。従って、ＣｏＤセッションセットアッププロセスは改良される。
【０１７７】
この実施形態では、ＳＩＰ  ＩＮＶＩＴＥメッセージなどの要求が処理のためにＭＦに送信され、ＭＦは、問い合わせ動作の後で、ＸＭＬ又はリンクモードでの、コンテンツ配信チャネルのメディア記述情報を、応答内で返す。あるいは、ＭＦは、ＳＣＦに応答を返し、ＳＣＦが、問い合わせ動作の後で、ＸＭＬ又はリンクモードでの、コンテンツ配信チャネルのメディア記述情報を、応答内で返し、この処理モードは第６の実施形態におけるものに類似している。
【０１７８】
第８、第９、第１０、及び第１１の実施形態は、いくつかのシナリオにおける典型的な例である。ＳＩＰの適用の柔軟性により、前述の使用モードは複数のシナリオにおいて適用されることが可能である。加えて、拡張されたAcceptヘッダフィールド内で示される特定の能力情報により、コンテンツの特定の記述情報が取得され、例えば、ＳＩＰでは、メディアの符号タイプ及び言語を示すために、それぞれ、Accept-Encoding及びAccept-Languageが定義されている。本発明の技術的解決法では、ＳＩＰ  ＯＰＴＩＯＮＳメソッドを使用しており（ＳＩＰでは、このメソッドは能力情報を取得するためのものである）、この技術的解決法では、Ｓｕｂｓｃｒｉｂｅ／Ｎｏｔｉｆｙモード又はＲｅｆｅｒモードなどの、別のＳＩＰメソッドを使用してもよい。これらのＳＩＰメソッドはＳＩＰ仕様に準拠し、適用方法は本発明の実施形態に類似している。
【０１７９】
省略可能な一方法は、以下の通りである。ＵＥの、初期セッション要求（Ｉｎｖｉｔｅメッセージなど）内で運ばれる、ＳＤＰ  Ｏｆｆｅｒがヌルであり（この場合、ＵＥは、ネットワークパラメータを取得せず、有効なＳＤＰ  Ｏｆｆｅｒを発さない可能性がある）、ネットワークエンティティ（例えば、ＳＣＦ又はＭＦ）によって返される応答内のＳＤＰ  Ａｎｓｗｅｒもヌルであり、応答は、要求されたコンテンツ識別子の、メディア制御チャネル及び／又はメディア配信チャネルの記述情報と、ネットワークパラメータとを運ぶ。記述は、ＳＩＰメッセージボディ内の、ＸＭＬ言語での記述であってもよく、あるいは、要求されたコンテンツのメディア制御チャネル及び／又はメディア配信チャネルの、アドレスリンク又はＳＤＰ記述情報、及び／又は、ネットワークパラメータに関する情報である。
【０１８０】
本発明の、前述の第８、第９、第１０、及び第１１の実施形態における、ＩＰＴＶサービスのメディア記述情報を取得する方法に従って、本発明の第１２の実施形態は、ネットワーク装置を提供する。図１２に示すように、装置は、
メディア記述情報を取得するためのＳＩＰ要求を受信するように構成された、受信ユニット１と（ここで、ＳＩＰ要求は、ＵＥによってコアＩＭＳを介して送信され、コンテンツ識別子を運ぶ）、
応答（その中で、ＳＤＰが、コンテンツ識別子に対応するメディア記述情報を運ぶ）を生成するように構成された、生成ユニット２と、
応答を、コアＩＭＳを介してＵＥに送信するように構成された、送信ユニット３とを含む。
【０１８１】
ネットワーク装置は、
コンテンツディスクリプタ機能からメディア記述情報を取得するように構成された、取得ユニット４を更に含む。
【０１８２】
この実施形態におけるネットワーク装置は、ネットワーク装置の前述の機能を実施することが可能な、ＳＣＦ、ＭＦ、又はその他のネットワークエンティティであり、特定のエンティティの変形は、本発明の保護範囲に影響を及ぼさない。
【０１８３】
本発明の第１３の実施形態は、セッションセットアップ中の、制御モードに関するネゴシエーションについて説明する。ＵＥは、セッションセットアップ中に、様々なメディアについての、同期制御モード及び個別制御モードなどの、サポートされている制御モードを、ネットワークとネゴシエートしてもよい。以下の実施形態ではＭＦを例に取るが、実際の実施中には、その他のネットワークエンティティがセッションセットアップ中に使用されてもよい。ＵＥは、その所望の、又はサポートされているモードを選択して、モードをＭＦに通知してもよく、ＭＦは、そのサポートされているモードに従って、最終的に使用される制御モードを決定する。特定の制御モードは、前述の第１の実施形態における任意のモードであってもよい。ＩＭＳにおけるモードの一実施形態は、以下の通りである。
【０１８４】
ステップＳ１３０１：ＵＥは、様々なメディアについての、ＵＥの、サポートされている又は選択されたモードを、コアＩＭＳに通知する。ＵＥは、そのＵＥのサポートされているモード（同期制御モード及び／又は個別制御モードであってもよい）をＭＦに通知する。あるいは、ＵＥは、そのＵＥの好ましいモード（個別制御モード又は同期制御モードなど）をＭＦに通知してもよい。実際の実施中に、ＵＥは、サービス要求（例えば、ＳＩＰ  ＩＮＶＩＴＥメッセージ）、又はＯＰＴＩＯＮＳメッセージを介して、ＭＦに通知してもよい。具体的には、制御モードは、ＳＩＰヘッダフィールド内、又はメッセージボディのＳＤＰ属性行内で運ばれてもよい。
【０１８５】
（１）制御モードがＳＩＰヘッダフィールド内で運ばれる場合、制御モードは、ＵＥの機能によって、又はＵＥにとって好ましいモードによって実施されてもよい。例えば、制御モードは、Contactヘッダフィールド、Request-Dispositionヘッダフィールド、Accept-Contactヘッダフィールド、又はReject-Contactヘッダフィールド内で運ばれる。
【０１８６】
ａ．Contactヘッダフィールドの場合：
Contact: <sip:user@host.example.com>;ControlMode="aggregate"
【０１８７】
ｂ．Request-Dispositionヘッダフィールドの場合：
Request-Disposition: aggregate
【０１８８】
「ControlMode」が指定されてもよく、値は「aggregate」又は「non-aggregate」であってもよい。
【０１８９】
Accept-Contact又はReject-Contactヘッダフィールド内で制御モードを運ぶ方法は、Request-Dispositionヘッダフィールド内で制御モードを運ぶ方法に類似している。
【０１９０】
「ControlMode」は例としてのみ役立ち、その他の文字列が使用されてもよい。
【０１９１】
（２）制御モードは、ＳＩＰメッセージボディ内で運ばれてもよい。ＳＩＰメッセージボディがＳＤＰメッセージを使用する場合、制御モードは、属性行、すなわち、「a=<attribute>:<value>」内で運ばれてもよい。
【０１９２】
「attribute」は、メディア制御モード属性を識別し、これは、文字セット又はその他であってもよく、「value」は、制御モードを識別し、これは、文字セット、数、トークン、又はその他であってもよい。
【０１９３】
属性行は、セッションレベル又はメディアレベルにおいて配置されてもよい。メディア制御チャネル（ＲＴＳＰなど）のメディア行の下の、制御モード属性行は、以下の通りである。
......
m=video 3400 RTP/AVP 98
......
m=audio 3456 RTP/AVP 97
......
m=application 10000 TCP/RTSP iptv_rtsp
......
a=ControlMode:aggregate//制御モード属性行
【０１９４】
あるいは、例えば次のように、「a=fmtp」属性行が使用されてもよい。
a=fmtp:rtsp ControlMode:aggregate
【０１９５】
前述のＳＤＰ属性行は、同期制御モード及び個別制御モードのうちでのネゴシエーションをＵＥがサポートすることを示す。加えて、ネゴシエーションでは、同期制御モードが採用されることが期待される。
【０１９６】
本発明の実施形態では、ＵＥとＭＦとが、それら又は相手側が同期制御モード及び個別制御モードをサポートするかどうかと、それらの所望のモードとに関して、相互にネゴシエートする。この着想を実施するために、前述のモードに加えて、属性行のその他の構築モードが使用されてもよく、そのような構築モードは本発明の保護範囲に含まれる。
a=aggregate-control:TRUE/False  又は
a=fmtp:rtsp aggregate-control TRUE/False
【０１９７】
ステップＳ１３０２〜Ｓ１３０３：ＵＥは、要求を、コアＩＭＳ及びＳＣＦを介してＭＦに送信する。
【０１９８】
ステップＳ１３０４：要求されたコンテンツ識別子、すなわち、XXXMoiveIDに従って、ＭＦは、コンテンツのメディア記述情報、及び／又は、メディア制御チャネルとメディア配信チャネルとのネットワークパラメータ情報を、コンテンツディスクリプタ機能から取得する。コンテンツディスクリプタ機能は、ＭＦ内の機能であってもよく、又は独立した機能エンティティであってもよい。このステップは省略可能である。
【０１９９】
ステップＳ１３０５：ＭＦは、サポートされている、又は決定されたモードを返す。
【０２００】
ＭＦは、ＭＦの、サポートされている、又は選択された制御モードをＵＥに通知するために、応答を返す。
【０２０１】
ステップＳ１３０１に対応して、実際の実施中に、応答は、２００  ＯＫ又は１８３メッセージなどの応答のＳＩＰヘッダフィールド内で運ばれてもよく、又は、メッセージボディのＳＤＰ属性行内で運ばれてもよい。
【０２０２】
メッセージがＳＩＰヘッダフィールド内で運ばれる場合、その方法は、ステップＳ１３０１の方法に類似している。
【０２０３】
メッセージが、メッセージボディのＳＤＰ属性行内で運ばれる例は、以下の通りである。ＭＦによって選択された特定のモードに加えて、ＭＦは、制御モードのＵＲＬ及びセッション識別子などの、関連するモードのパラメータを更に運ぶ。
m=video 3400 RTP/AVP 98
......
m=audio 3456 RTP/AVP 97
......
m=application 10000 TCP/RTSP iptv_rtsp
......
a=ControlMode:aggregate//又はa=fmtp:ControlMode aggregate
a=fmtp:iptv_rtsp h-uri=rtsp://MCF.example.com/video-position
a=fmtp:iptv_rtsp h-session: 123456
a=m-stream:1,2
【０２０４】
個別モードでは、複数のパラメータに関する情報が返される。
m=video 3400 RTP/AVP 98
......
m=audio 3456 RTP/AVP 97
......
m=application 10000 TCP/RTSP iptv_rtsp
......
a=ControlMode:non-aggregate//又はa=fmtp:ControlMode non-aggregate
a=fmtp:iptv_rtsp h-uri=rtsp://MCF.example.com/video-position/video1
a=fmtp:rtsp h-session: 123456
a=m-stream:1
a=fmtp:iptv_rtsp h-uri=rtsp://MCF.example.com/audio-position/audio1
a=fmtp:rtsp h-session: 234567
a=m-stream:2
【０２０５】
上記は、メディア制御チャネルとメディア配信チャネルとの間の制御関係を記述する。すなわち、メディア制御属性行は、第１の実施形態で説明した任意のモードを採用してもよい。
【０２０６】
ステップＳ１３０６〜Ｓ１３０７：ＭＦは、応答を、ＳＣＦ及びコアＩＭＳを介してＵＥに送信する。
【０２０７】
この実施形態では、ＳＩＰ  ＩＮＶＩＴＥメッセージ又はＯＰＴＩＯＮＳメッセージなどの要求が処理のためにＭＦに送信され、ＭＦは、問い合わせ動作の後で、サポートされている制御モードを、応答内で返す。あるいは、ＭＦは、ＳＣＦに応答を返してもよく、ＳＣＦが、問い合わせ動作の後で、サポートされている制御モードを、応答内で返し、この処理モードは第３の実施形態におけるものに類似している。
【０２０８】
本発明の実施形態の前述の説明により、本発明の実施形態は、ハードウェアによって、又は、必要なハードウェアプラットフォームと組み合わせたソフトウェアによって実施されてもよいということを、当業者は理解できる。従って、本発明の技術的解決法は、ソフトウェアとして作製されてもよい。ソフトウェアは、例えば、ＣＤ−ＲＯＭ，ＵＳＢディスク、又はモバイルハードディスクなどの、不揮発性記憶媒体内に記憶されてもよく、そして、例えば、パーソナルコンピュータ、サーバ、又はネットワーク装置などの、コンピュータ装置に、本発明の各実施形態において提供された方法を実行するよう指示する、いくつかの命令を含んでもよい。
【０２０９】
本発明について、いくつかの例示的実施形態を介して説明してきたが、本発明はそのような実施形態に限定されない。本発明の範囲から逸脱することなく、当業者が本発明に対して様々な修正及び変形を加えることができることは明白である。本発明は、それらの修正及び変形を、それらが特許請求の範囲又はその均等物によって規定される保護範囲に入るならば、包含することを意図するものである。
【図１】
2011501304.tif 000003
【図２】
2011501304.tif 000004
【図３】
2011501304.tif 000005
【図４】
2011501304.tif 000006
【図５】
2011501304.tif 000007
【図６】
2011501304.tif 000008
【図７】
2011501304.tif 000009
【図８】
2011501304.tif 000010
【図９】
2011501304.tif 000011
【図１０】
2011501304.tif 000012
【図１１】
2011501304.tif 000013
【図１２】
2011501304.tif 000014
【図１３】
2011501304.tif 000015
【手続補正書】
【提出日】平成22年5月20日(2010.5.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メディア記述情報を取得するためのセッション開始プロトコル（ＳＩＰ）要求を、ネットワーク装置によって受信し、ここで、前記ＳＩＰ要求は、ユーザ装置（ＵＥ）によってコアＩＰマルチメディアサブシステム（ＩＭＳ）を介して送信され、コンテンツ識別子を運び、
前記コンテンツ識別子に対応する前記メディア記述情報を運ぶＳＩＰ応答を、前記ネットワーク装置によって、前記コアＩＭＳを介して前記ＵＥに送信すること
を含む、インターネットプロトコルテレビジョン（ＩＰＴＶ）サービスのメディア記述情報を取得する方法。
【請求項２】
前記メディア記述情報は、コンテンツ制御チャネルパラメータ及びコンテンツ配信チャネルパラメータの少なくとも一方を含む、請求項１に記載の方法。
【請求項３】
前記コンテンツ識別子に対応する前記メディア記述情報を運ぶ前記応答を、前記ネットワーク装置が送信する前に、前記方法は、
前記ネットワーク装置によって、前記メディア記述情報をコンテンツディスクリプタ機能から取得すること
を更に含む、請求項１に記載の方法。
【請求項４】
前記ネットワーク装置は、サービス制御機能（ＳＣＦ）又はメディア機能（ＭＦ）である、請求項１〜３のいずれか一項に記載の方法。
【請求項５】
前記メディア記述情報を取得するための前記ＳＩＰ要求は、ＯＰＴＩＯＮＳ又はＩＮＶＩＴＥメッセージである、請求項１に記載の方法。
【請求項６】
前記メディア記述情報は、前記応答内で、セッション記述プロトコル（ＳＤＰ）又は拡張可能なマークアップ言語（ＸＭＬ）モードで運ばれる、請求項１に記載の方法。
【請求項７】
メディア記述情報を取得するためのセッション開始プロトコル（ＳＩＰ）要求を受信するように構成された、受信ユニット（１）と（ここで、前記ＳＩＰ要求は、ユーザ装置（ＵＥ）によってコアＩＰマルチメディアサブシステム（ＩＭＳ）を介して送信され、コンテンツ識別子を運ぶ）、
応答（前記応答内で、セッション記述プロトコル（ＳＤＰ）が、前記コンテンツ識別子に対応する前記メディア記述情報を運ぶ）を生成するように構成された、生成ユニット（２）と、
前記応答を、前記コアＩＭＳを介して前記ＵＥに送信するように構成された、送信ユニット（３）とを備える、ネットワーク装置。
【請求項８】
前記メディア記述情報をコンテンツディスクリプタ機能から取得するように構成された、取得ユニット（４）を更に備える、請求項７に記載のネットワーク装置。
【請求項９】
前記ネットワーク装置は、サービス制御機能（ＳＣＦ）又はメディア機能（ＭＦ）である、請求項７に記載のネットワーク装置。
【請求項１０】
ユーザ装置（ＵＥ）によって送信された制御モード情報を、ネットワーク装置によって受信し、
セッション開始プロトコル（ＳＩＰ）ヘッダフィールド内、又は、メッセージボディのセッション記述プロトコル（ＳＤＰ）属性行内で運ばれる前記制御モード情報を、前記ネットワーク装置によって前記ＵＥに返すこと
を含む、メディア制御及びネゴシエーション方法。
【請求項１１】
前記ＳＩＰヘッダフィールドは、Contactヘッダフィールド又はRequest-Dispositionヘッダフィールドを含む、請求項１０に記載の方法。
【請求項１２】
前記メッセージボディの前記ＳＤＰ属性行は、属性行「a=<attribute>:<value>」を含み、「attribute」はメディア制御モード属性を識別し、「value」は制御モード情報を示す、請求項１０に記載の方法。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０２０９
【補正方法】変更
【補正の内容】
【０２０９】
本発明について、いくつかの例示的実施形態を介して説明してきたが、本発明はそのような実施形態に限定されない。
【国際調査報告】
2011501304.tif 000016
2011501304.tif 000017
2011501304.tif 000018
2011501304.tif 000019
2011501304.tif 000020
2011501304.tif 000021
2011501304.tif 000022