JP5042370B2 - Ｉｐｔｖサービスのメディア記述情報を取得する方法及び装置 - Google Patents

Ｉｐｔｖサービスのメディア記述情報を取得する方法及び装置 Download PDF

Info

Publication number
JP5042370B2
JP5042370B2 JP2010530255A JP2010530255A JP5042370B2 JP 5042370 B2 JP5042370 B2 JP 5042370B2 JP 2010530255 A JP2010530255 A JP 2010530255A JP 2010530255 A JP2010530255 A JP 2010530255A JP 5042370 B2 JP5042370 B2 JP 5042370B2
Authority
JP
Japan
Prior art keywords
media
rtsp
control
line
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2010530255A
Other languages
English (en)
Other versions
JP2011501304A (ja
Inventor
ペン、ツァオジュン
ヤン、ジュン
リ、ジンチェン
ワン、フェン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2011501304A publication Critical patent/JP2011501304A/ja
Application granted granted Critical
Publication of JP5042370B2 publication Critical patent/JP5042370B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Description

本発明は、通信技術に関し、特に、インターネットプロトコルテレビジョン（ＩＰＴＶ）サービスのメディア記述情報を取得する方法及び装置に関する。
ＩＰマルチメディアサブシステム（ＩＭＳ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）Ｒ５規格で追加された、広帯域符号分割多元接続（ＷＣＤＭＡ）ネットワーク上の既存のパケット交換（ＰＳ）ドメイン内のサブシステムである。ＩＭＳは、上位層制御シグナリング及びメディア配信のためのベアラチャネルとしてＰＳドメインを使用し、サービス制御プロトコルとしてセッション開始プロトコル（ＳＩＰ）を導入し、単純さ、拡張性、及び簡便なメディア結合などの、ＳＩＰの特徴を利用することによって、かつ、サービス制御をベアラ制御から分離することによって、豊富なマルチメディアサービスを提供する。ＩＭＳの標準化に参加している国際的な標準化組織としては、３ＧＰＰと、ＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ ｃｏｎｖｅｒｇｅｄ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｉｎｇ）とが挙げられる。３ＧＰＰは、移動アクセスの観点からＩＭＳを研究する。ＴＩＳＰＡＮは、固定アクセスの観点から、ＩＭＳに対する要求を提起し、次に、３ＧＰＰによってＩＭＳが完成される。最後に、固定アクセス及び移動アクセスのための統合された制御がＩＭＳ上で実施される。
ＩＭＳベースのＩＰＴＶは、登録、認証、ルーティング、セッション制御及びセットアップ、サービストリガ、課金、並びに、エンドツーエンドのサービス品質（ＱｏＳ）などの、既存のメカニズムを十分に活用して、ストリーミングサービスと、ストリーミングサービス及びリアルタイムセッションサービスを統合したマルチメディアサービスとをユーザに提供するために、ＴＩＳＰＡＮによって提案された全ＩＭＳアーキテクチャにおけるＩＰＴＶサービスを提供する。すなわち、ユーザからコンテンツまでのマルチメディアセッションが、ＩＭＳの既存のセッション制御メカニズムによって完成される。セッションセットアップ中に、メディアストリームの伝送のためのベアラリソースが確保される必要がある。
従来技術では、コンテンツオンデマンド（ＣｏＤ）サービスプロセスにおけるセッションセットアップの主な特徴は以下の通りである。ＣｏＤサービスプロセスにおいて、ユーザは、見られるコンテンツに対する、前送り、巻き戻し、及び一時停止などの、ＶＣＲ制御を実行する可能性があり、従って、ＶＣＲ動作のために使用されるメディア制御チャネルと、見られるコンテンツを伝送するために使用されるメディア配信チャネルとが、サービスのために確立される必要がある。メディア制御チャネルとメディア配信チャネルとを確立する様々なモードに従って、ＴＩＳＰＡＮによって規定されたＣｏＤサービスプロセスは２つのモードを含む。第１のモードでは、メディア制御チャネルとメディア配信チャネルとが、ＳＩＰセッションセットアップ中に同時に確立される。第２のモードでは、メディア制御チャネルが初期セッションセットアップ中に確立され、次に、メディア配信チャネルが、セッション変更を介して確立される。
第１のモードを使用するための必須条件は、ユーザ装置（ＵＥ）が、コンテンツのメディア行（例えば、音声、映像、及びテキストメディア行）などの、見られるコンテンツのメディア情報を、電子番組案内（ＥＰＧ）から取得済みであるということである。従って、メディア配信チャネルがネゴシエートされて確立されることが可能である。第２のモードが採用される場合は、メディア制御チャネル（一般に、ＲＴＳＰチャネル）が、ＳＩＰセッションセットアッププロセスを介して、ネゴシエートされて確立され、メディア交換制御セッションが、ＵＥとメディア機能（ＭＦ）との間にセットアップされ、メディアのネットワークパラメータ情報が、メディア制御メッセージを交換することによって取得され、次に、コンテンツ配信チャネルが、セッション変更中に確立される。
実際には、第１のモードと比較して、第２のモードは、セッションセットアップに長い時間を要する、という欠点を有する。一般的なプロセスは、以下の通りである。（ＳＩＰメッセージを使用することによって）最初にセッションがセットアップされた後で、ＵＥとネットワーク（ＭＦ）とは、メディア制御メッセージ（一般に、ＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージ）を発してメディア制御セッションをセットアップし、メディア制御セッションメッセージ内でメディアコンテンツを交換し、最後に、（ＳＩＰメッセージを使用することによる）セッション変更プロセスを介してメディアチャネルが確立される。結果として、ユーザのサービス体験は貧弱なものとなる。従って、現在の仕様における第２のモードの適用に対する制限は、以下の通りである。初期セッション中にコンテンツ配信チャネルを確立すること、すなわち、第２のモードは、ネットワークが、コンテンツ配信チャネルのネットワークパラメータ情報ではなく、メディア制御チャネルのネットワークパラメータ情報のみをユーザに提供する場合のみ選択可能である。
従来技術における、以下の問題が明らかとなった。
第２のモードが採用される場合、より多くの相互作用がＵＥとネットワークとの間で必要とされ、より多くの要求がＵＥに対して提起され、セッションセットアップは遅らされ、ユーザ体験は貧弱なものとなる。
本発明は、ＳＩＰメッセージを介してメディア記述情報を取得してＣｏＤサービスのセッションをセットアップするための、ＩＰＴＶサービスのメディア記述情報を取得する方法及び装置を提供する。
本発明の第１の態様として、ＩＰＴＶサービスのメディア記述情報を取得する方法は、
メディア記述情報を取得するためのＳＩＰ要求を、ネットワーク装置によって受信し、ここで、ＳＩＰ要求は、ＵＥによってコアＩＭＳを介して送信され、コンテンツ識別子を運び、
コンテンツ識別子に対応するメディア記述情報を運ぶＳＩＰ応答を、ネットワーク装置によって、コアＩＭＳを介してＵＥに送信することを含む。
本発明の第２の態様として、ネットワーク装置は、
メディア記述情報を取得するためのＳＩＰ要求を受信するように構成された、受信ユニットと（ここで、ＳＩＰ要求は、ＵＥによってコアＩＭＳを介して送信され、コンテンツ識別子を運ぶ）、
応答（その中で、セッション記述プロトコル（ＳＤＰ）が、コンテンツ識別子に対応するメディア記述情報を運ぶ）を生成するように構成された、生成ユニットと、
応答を、コアＩＭＳを介してＵＥに送信するように構成された、送信ユニットとを含む。
本発明の第３の態様として、メディア制御及びネゴシエーション方法は、
ＵＥによって送信された制御モード情報を、ネットワーク装置によって受信し、
ネットワーク装置によって、制御モード情報をＵＥに返すことを含み、制御モード情報は、ＳＩＰヘッダフィールド内、又は、メッセージボディのＳＤＰ属性行内で運ばれる(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:[email protected] SIP/2.0
Via:SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip:[email protected]>
From: Alice<sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:[email protected]>
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: [email protected]>;tag=93810874
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip: [email protected]>
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:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
Max-Forwards: 70
To: <sip: [email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:[email protected]>
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: [email protected]>;tag=93810874
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip: [email protected]>
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:[email protected] SIP/2.0
Via:SIP/2.0/UDPpc33.atlanta.com;branch=z9hG4bKhjhs8ass877//パラメータは、初期セッションセットアッププロセスにおけるＳＩＰメッセージパラメータと同じであり、以下のパラメータ処理メカニズムは、初期セッションセットアッププロセスにおけるパラメータ処理メカニズムに類似している:
Max-Forwards: 70
To: <sip: [email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:[email protected]>
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: [email protected]>;tag=93810874
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip: [email protected]>
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:[email protected]>;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
上記は、メディア制御チャネルとメディア配信チャネルとの間の制御関係を記述する。すなわち、メディア制御属性行は、第１の実施形態で説明した任意のモードを採用してもよい。
ステップＳ１３０６〜Ｓ１３０７：ＭＦは、応答を、ＳＣＦ及びコアＩＭＳを介してＵＥに送信する。
この実施形態では、ＳＩＰ ＩＮＶＩＴＥメッセージ又はＯＰＴＩＯＮＳメッセージなどの要求が処理のためにＭＦに送信され、ＭＦは、問い合わせ動作の後で、サポートされている制御モードを、応答内で返す。あるいは、ＭＦは、ＳＣＦに応答を返してもよく、ＳＣＦが、問い合わせ動作の後で、サポートされている制御モードを、応答内で返し、この処理モードは第３の実施形態におけるものに類似している。
本発明の実施形態の前述の説明により、本発明の実施形態は、ハードウェアによって、又は、必要なハードウェアプラットフォームと組み合わせたソフトウェアによって実施されてもよいということを、当業者は理解できる。従って、本発明の技術的解決法は、ソフトウェアとして作製されてもよい。ソフトウェアは、例えば、ＣＤ−ＲＯＭ，ＵＳＢディスク、又はモバイルハードディスクなどの、不揮発性記憶媒体内に記憶されてもよく、そして、例えば、パーソナルコンピュータ、サーバ、又はネットワーク装置などの、コンピュータ装置に、本発明の各実施形態において提供された方法を実行するよう指示する、いくつかの命令を含んでもよい。
本発明について、いくつかの例示的実施形態を介して説明してきたが、本発明はそのような実施形態に限定されない。

Claims (9)

  1. メディア記述情報を取得するためのセッション開始プロトコル（ＳＩＰ）要求を、ネットワーク装置によって受信し、ここで、前記ＳＩＰ要求は、ユーザ装置（ＵＥ）によってコアＩＰマルチメディアサブシステム（ＩＭＳ）を介して送信され、コンテンツ識別子を運び、
    前記コンテンツ識別子に対応する前記メディア記述情報を運ぶＳＩＰ応答を、前記ネットワーク装置によって、前記コアＩＭＳを介して前記ＵＥに送信すること
    を含む、インターネットプロトコルテレビジョン（ＩＰＴＶ）サービスのメディア記述情報を取得する方法。
  2. 前記メディア記述情報は、コンテンツ制御チャネルパラメータ及びコンテンツ配信チャネルパラメータの少なくとも一方を含む、請求項１に記載の方法。
  3. 前記コンテンツ識別子に対応する前記メディア記述情報を運ぶ前記応答を、前記ネットワーク装置が送信する前に、前記方法は、
    前記ネットワーク装置によって、前記メディア記述情報をコンテンツディスクリプタ機能から取得すること
    を更に含む、請求項１に記載の方法。
  4. 前記ネットワーク装置は、サービス制御機能（ＳＣＦ）又はメディア機能（ＭＦ）である、請求項１〜３のいずれか一項に記載の方法。
  5. 前記メディア記述情報を取得するための前記ＳＩＰ要求は、ＯＰＴＩＯＮＳ又はＩＮＶＩＴＥメッセージである、請求項１に記載の方法。
  6. 前記メディア記述情報は、前記応答内で、セッション記述プロトコル（ＳＤＰ）又は拡張可能なマークアップ言語（ＸＭＬ）モードで運ばれる、請求項１に記載の方法。
  7. メディア記述情報を取得するためのセッション開始プロトコル（ＳＩＰ）要求を受信するように構成された、受信ユニット（１）と（ここで、前記ＳＩＰ要求は、ユーザ装置（ＵＥ）によってコアＩＰマルチメディアサブシステム（ＩＭＳ）を介して送信され、コンテンツ識別子を運ぶ）、
    応答（前記応答内で、セッション記述プロトコル（ＳＤＰ）が、前記コンテンツ識別子に対応する前記メディア記述情報を運ぶ）を生成するように構成された、生成ユニット（２）と、
    前記応答を、前記コアＩＭＳを介して前記ＵＥに送信するように構成された、送信ユニット（３）とを備える、ネットワーク装置。
  8. 前記メディア記述情報をコンテンツディスクリプタ機能から取得するように構成された、取得ユニット（４）を更に備える、請求項７に記載のネットワーク装置。
  9. 前記ネットワーク装置は、サービス制御機能（ＳＣＦ）又はメディア機能（ＭＦ）である、請求項７に記載のネットワーク装置。
JP2010530255A 2007-10-22 2008-10-21 Ｉｐｔｖサービスのメディア記述情報を取得する方法及び装置 Active JP5042370B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
CN200710181370 2007-10-22
CN200710181370.X 2007-10-22
CN200710195706.8 2007-12-12
CN200710195706 2007-12-12
CN200810091604.6 2008-04-03
CN2008100916046A CN101459664B (zh) 2007-10-22 2008-04-03 一种获取iptv业务媒体描述信息的方法及装置
PCT/CN2008/072776 WO2009056037A1 (fr) 2007-10-22 2008-10-21 Procédé et dispositif d'obtention d'informations de description de supports d'un service iptv

Publications (2)

Publication Number Publication Date
JP2011501304A JP2011501304A (ja) 2011-01-06
JP5042370B2 true JP5042370B2 (ja) 2012-10-03

Family

ID=40590546

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010530255A Active JP5042370B2 (ja) 2007-10-22 2008-10-21 Ｉｐｔｖサービスのメディア記述情報を取得する方法及び装置

Country Status (5)

Country Link
US (1) US8307049B2 (ja)
EP (1) EP2148505A4 (ja)
JP (1) JP5042370B2 (ja)
CN (1) CN101459664B (ja)
WO (1) WO2009056037A1 (ja)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8374172B2 (en) * 2009-04-03 2013-02-12 At&T Intellectual Property I, L.P. Method and apparatus for managing communication sessions
US9781197B2 (en) 2009-11-30 2017-10-03 Samsung Electronics Co., Ltd. Methods and apparatus for selection of content delivery network (CDN) based on user location
CN102158897B (zh) * 2010-02-12 2015-04-01 中兴通讯股份有限公司 基于网络负荷进行编码选择的方法和***
CN102137277B (zh) * 2010-08-17 2014-04-30 华为技术有限公司 实现交互式轮播频道的方法、装置及***
US10637891B2 (en) * 2010-11-02 2020-04-28 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices for media description delivery
TW201225701A (en) * 2010-11-18 2012-06-16 Interdigital Patent Holdings Method and apparatus for inter-user equipment transfer
CN102143150A (zh) * 2010-12-10 2011-08-03 华为技术有限公司 一种获取媒体内容的方法、设备及***
US8788578B2 (en) 2011-07-11 2014-07-22 Roku, Inc. Method and apparatus for customized provisioning of on-line application channels
US9143722B2 (en) * 2011-11-22 2015-09-22 Cisco Technology, Inc. Method and apparatus for providing session description for a media session
CN103200430B (zh) * 2012-01-04 2017-05-31 华为终端有限公司 个人内容分享方法、***、服务器和终端设备
WO2014026316A1 (zh) * 2012-08-13 2014-02-20 华为技术有限公司 媒体数据传输方法及设备
JP2015043484A (ja) * 2013-08-26 2015-03-05 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
FR3034608A1 (fr) * 2015-03-31 2016-10-07 Orange Procede de priorisation de flux medias dans un reseau de communications
BR112019008833A2 (pt) * 2016-11-04 2019-07-09 Huawei Tech Co Ltd método de processamento de pacote de dados, elemento de rede do plano de controle, e elemento de rede do plano do usuário
CN108377474A (zh) * 2016-11-14 2018-08-07 展讯通信（上海）有限公司 一种多通路终端通话转移方法及装置
CN110891123B (zh) * 2018-09-07 2021-10-26 华为技术有限公司 交互信息传输方法及装置
CN112019480B (zh) * 2019-05-30 2022-09-16 中国电信股份有限公司 多媒体通信方法、装置、***和存储介质

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060239247A1 (en) * 2005-04-26 2006-10-26 Peter Postmus Method and session initiation protocol (SIP) server with end-point capabilities check
US20070220553A1 (en) * 2005-09-30 2007-09-20 Bellsouth Intellectual Property Corporation Methods, systems, and computer program products for providing customized content
US9083564B2 (en) * 2005-10-13 2015-07-14 At&T Intellectual Property I, L.P. System and method of delivering notifications
US20080288458A1 (en) * 2005-12-08 2008-11-20 Nortel Networks Limited Session Initiation Protocol (Sip) Multicast Management Method
US7830868B2 (en) * 2006-02-06 2010-11-09 Research In Motion Limited System and method for effecutating a SIP call in a network environment including IMS
CN101026615B (zh) 2006-02-18 2011-09-14 华为技术有限公司 一种基于ims的流媒体网络***
CN100525376C (zh) 2006-02-24 2009-08-05 海尔集团公司 一种多功能电视机
JP4927879B2 (ja) * 2006-02-24 2012-05-09 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｉｐｔｖのための、ｉｍｓ対応のコントロールチャネル
CN101401427B (zh) * 2006-03-07 2012-08-15 艾利森电话股份有限公司 用于iptv***的时间偏移和追踪播放
CN101438256B (zh) * 2006-03-07 2011-12-21 索尼株式会社 信息处理设备、信息通信***、信息处理方法
CN100493091C (zh) * 2006-03-10 2009-05-27 清华大学 基于会话初始化协议的流媒体直播p2p网络方法
CN100477667C (zh) * 2006-05-10 2009-04-08 中国电信股份有限公司 在网络电视网络中实现消息类业务的方法及***
CN100429659C (zh) * 2006-10-10 2008-10-29 北京新岸线网络技术有限公司 基于内容的视频分析融合***
CN100518292C (zh) * 2006-10-27 2009-07-22 华为技术有限公司 一种获取epg的方法及iptv业务***
CN100518297C (zh) * 2006-11-24 2009-07-22 中兴通讯股份有限公司 基于sip协议的多点控制单元视频会议***及实现方法
US8656445B2 (en) * 2006-11-27 2014-02-18 Genband Us Llc Multimedia subsystem control for internet protocol based television services
US20080141306A1 (en) * 2006-12-07 2008-06-12 Telefonaktiebolaget Lm Ericsson (Publ) Method of sending media program information to a subscriber and nodes therefor
CN101039329B (zh) 2006-12-28 2012-03-28 中兴通讯股份有限公司 基于媒体交付的网络电视***的媒体交付***
CN101035251A (zh) * 2007-04-19 2007-09-12 中兴通讯股份有限公司 基于ip多媒体子***的iptv业务***
CN101052044B (zh) * 2007-05-18 2010-04-21 华为技术有限公司 一种ims中iptv流媒体业务实现方法、网络设备及终端设备

Also Published As

Publication number Publication date
CN101459664A (zh) 2009-06-17
US20100121963A1 (en) 2010-05-13
CN101459664B (zh) 2010-10-20
US8307049B2 (en) 2012-11-06
JP2011501304A (ja) 2011-01-06
EP2148505A1 (en) 2010-01-27
WO2009056037A1 (fr) 2009-05-07
EP2148505A4 (en) 2010-07-14

Similar Documents

Publication Publication Date Title
JP5042370B2 (ja) Ｉｐｔｖサービスのメディア記述情報を取得する方法及び装置
EP1988666B1 (en) A streaming media network system, a realization method and a enable entity of streaming media service
EP2087692B1 (en) Media channel management
KR101433225B1 (ko) Ｉｍｓ 아키텍쳐 네트워크에서 ｉｐ 텔레비젼 서비스에 액세스하기 위한 시스템
WO2009117919A1 (zh) 一种内容点播业务的建立方法、***和装置
MX2013001513A (es) Control de sesion para transmision de flujo continuo de medios.
WO2007093124A1 (fr) Procédé et système d&#39;ordonnancement de ressources multimédia
WO2009024092A1 (fr) Procédé et système permettant la commande d&#39;autorisation de ressource de service
WO2009052762A1 (fr) Procédé, dispositif et système d&#39;amélioration de service de diffusion (bc)
KR20090123781A (ko) 멀티캐스트 세션을 통해 수신한 어플리케이션에 기초한 ｉｐｔｖ 서비스 이용 방법 및 장치
WO2008098500A1 (fr) Procédé et appareil pour découvrir un service de flux de données multimédia et appareil pour découvrir un service
WO2011015015A1 (zh) 内容上行方法及内容交付功能实体
WO2010028601A1 (zh) 以文件方式传输媒体内容的方法、***及设备
WO2010028591A1 (zh) 实现客户端录制的方法、***及录制控制实体
WO2009049518A1 (fr) Procédé, système et entité d&#39;établissement de session de système de télévision par internet ip
CN101483532B (zh) 一种媒体流复制的方法、***及设备
WO2009006820A1 (fr) Procédé et système pour fournir un flux multimédia durant une commutation de serveurs multimédias
WO2008122245A1 (fr) Equipement et moyen pour réaliser des services iptv en utilisant des protocoles internet
JP2010010892A (ja) 通信制御装置と通信システムおよび通信制御方法
WO2010012233A1 (zh) 一种交互信息的传送方法、***和装置
WO2009024077A1 (fr) Procédé et dispositif pour acquérir un paramètre de service iptv
CN101459525B (zh) 一种实现媒体控制的方法、***及设备
WO2009012714A1 (fr) Procédé et dispositif pour commander les médias en flux
WO2008122246A1 (fr) Procédé et système servant à découvrir des affaires multimédias en mode continu
CN102150407B (zh) 网络电视频道业务实现方法和相关设备

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20111027

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111115

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120215

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120626

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120710

R150 Certificate of patent or registration of utility model

Ref document number: 5042370

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150720

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250