[要約] RFC 8845は、複数のストリームを使用したテレプレゼンスのためのフレームワークを定義しています。このRFCの目的は、異なるデバイスやネットワーク条件下での高品質なテレプレゼンス体験を実現することです。
Internet Engineering Task Force (IETF) M. Duckworth, Ed.
Request for Comments: 8845
Category: Standards Track A. Pepperell
ISSN: 2070-1721 Acano
S. Wenger
Tencent
January 2021
Framework for Telepresence Multi-Streams
TelePresenceマルチストリームのためのフレームワーク
Abstract
概要
This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting, and rendering the media streams. This protocol is used in addition to SIP signaling and Session Description Protocol (SDP) negotiation for setting up a telepresence session.
このドキュメントは、TelePresence Conferenceのデバイスを相互運用することを可能にするためのプロトコルのためのフレームワークを定義します。プロトコルは、送信システムおよび受信システムがメディアストリームを送信、選択、およびレンダリングすることについての合理的な決定を下すことができるように、複数のメディアストリームに関する情報の通信を可能にする。このプロトコルは、TelePresenceセッションを設定するためのSIPシグナリングおよびセッション記述プロトコル（SDP）ネゴシエーションに加えて使用されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8845.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc8845で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Requirements Language
3. Definitions
4. Overview and Motivation
5. Description of the Framework/Model
6. Spatial Relationships
7. Media Captures and Capture Scenes
7.1. Media Captures
7.1.1. Media Capture Attributes
7.2. Multiple Content Capture
7.2.1. MCC Attributes
7.3. Capture Scene
7.3.1. Capture Scene Attributes
7.3.2. Capture Scene View Attributes
7.4. Global View List
8. Simultaneous Transmission Set Constraints
9. Encodings
9.1. Individual Encodings
9.2. Encoding Group
9.3. Associating Captures with Encoding Groups
10. Consumer's Choice of Streams to Receive from the Provider
10.1. Local Preference
10.2. Physical Simultaneity Restrictions
10.3. Encoding and Encoding Group Limits
11. Extensibility
12. Examples - Using the Framework (Informative)
12.1. Provider Behavior
12.1.1. Three-Screen Endpoint Provider
12.1.2. Encoding Group Example
12.1.3. The MCU Case
12.2. Media Consumer Behavior
12.2.1. One-Screen Media Consumer
12.2.2. Two-Screen Media Consumer Configuring the Example
12.2.3. Three-Screen Media Consumer Configuring the Example
12.3. Multipoint Conference Utilizing Multiple Content Captures
12.3.1. Single Media Captures and MCC in the Same
Advertisement
12.3.2. Several MCCs in the Same Advertisement
12.3.3. Heterogeneous Conference with Switching and
Composition
12.3.4. Heterogeneous Conference with Voice-Activated
Switching
13. IANA Considerations
14. Security Considerations
15. References
15.1. Normative References
15.2. Informative References
Acknowledgements
Authors' Addresses
Current telepresence systems, though based on open standards such as RTP [RFC3550] and SIP [RFC3261], cannot easily interoperate with each other. A major factor limiting the interoperability of telepresence systems is the lack of a standardized way to describe and negotiate the use of multiple audio and video streams comprising the media flows. This document provides a framework for protocols to enable interoperability by handling multiple streams in a standardized way. The framework is intended to support the use cases described in "Use Cases for Telepresence Multistreams" [RFC7205] and to meet the requirements in "Requirements for Telepresence Multistreams" [RFC7262]. This includes cases using multiple media streams that are not necessarily telepresence.
現在のテレプレゼンスシステムは、RTP [RFC3550]やSIP [RFC3261]などのオープンスタンダードに基づいていますが、互いに簡単に相互運用できません。テレプレゼンスシステムの相互運用性を制限する主な要因は、メディアフローを含む複数のオーディオおよびビデオストリームの使用を説明およびネゴシエートするための標準化された方法がないことです。このドキュメントは、標準化された方法で複数のストリームを処理することによって相互運用性を可能にするためのプロトコルのためのフレームワークを提供します。フレームワークは、「TelePresence Multistreams for TelePresence Multistreamsの使用例」[RFC7205]で説明されているユースケースをサポートし、「Telepresence Multistreamsの要件」[RFC7262]の要件を満たすことを目的としています。これには、必ずしもテレプレゼンスではない複数のメディアストリームを使用する場合が含まれます。
The basic session setup for the use cases is based on SIP [RFC3261] and SDP offer/answer [RFC3264]. In addition to basic SIP & SDP offer/answer, signaling that is ControLling mUltiple streams for tElepresence (CLUE) specific is required to exchange the information describing the multiple Media Streams. The motivation for this framework, an overview of the signaling, and the information required to be exchanged are described in subsequent sections of this document. Companion documents describe the signaling details [RFC8848], the data model [RFC8846], and the protocol [RFC8847].
ユースケースの基本セッション設定はSIP [RFC3261]とSDPオファー/アンサー[RFC3264]に基づいています。基本的なSIPおよびSDPオファー/回答に加えて、複数のメディアストリームを記述する情報を交換するためには、テレプレゼンス（Chure）固有の複数のストリームを制御しているシグナリングが必要です。このフレームワークのモチベーション、シグナリングの概要、および交換するのに必要な情報は、この文書の後続のセクションで説明されています。コンパニオン文書はシグナリングの詳細[RFC8848]、データモデル[RFC8846]、およびプロトコル[RFC8847]を記述します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The terms defined below are used throughout this document and in companion documents. Capitalization is used in order to easily identify a defined term.
以下に定義された用語は、この文書およびコンパニオン文書全体で使用されます。自己資本化は、定義された用語を簡単に識別するために使用されます。
Advertisement: A CLUE message a Media Provider sends to a Media Consumer describing specific aspects of the content of the Media and any restrictions it has in terms of being able to provide certain Streams simultaneously.
広告：メディアプロバイダがメディアプロバイダに送信され、メディアの内容の特定の側面を記述するメディアコンシューマに送信し、それが特定のストリームを同時に提供することができるという点でもある。
Audio Capture (AC): Media Capture for audio. Denoted as "ACn" in the examples in this document.
オーディオキャプチャ（AC）：オーディオのメディアキャプチャ。この文書の例では「ACN」と表記されています。
Capture: Same as Media Capture.
キャプチャ：メディアキャプチャと同じです。
Capture Device: A device that converts physical input, such as audio, video, or text, into an electrical signal, in most cases to be fed into a Media encoder.
キャプチャデバイス：オーディオ、ビデオ、テキストなどの物理入力を電気信号に変換するデバイス、ほとんどの場合、メディアエンコーダに供給される。
Capture Encoding: A specific Encoding of a Media Capture, to be sent by a Media Provider to a Media Consumer via RTP.
キャプチャエンコーディング：メディアプロバイダによってメディアコンシューマを介して送信されるメディアキャプチャの特定のエンコーディング。
Capture Scene: A structure representing a spatial region captured by one or more Capture Devices, each capturing Media representing a portion of the region. The spatial region represented by a Capture Scene may correspond to a real region in physical space, such as a room. A Capture Scene includes attributes and one or more Capture Scene Views, with each view including one or more Media Captures.
キャプチャシーン：1つ以上のキャプチャデバイスによってキャプチャされた空間領域を表す構造。各キャプチャメディアは、領域の一部を表す。捕捉シーンによって表される空間領域は、部屋のような物理的空間内の実領域に対応し得る。キャプチャシーンは、属性と1つ以上のキャプチャシーンビューを含み、各ビューは1つ以上のメディアキャプチャを含む。
Capture Scene View (CSV): A list of Media Captures of the same Media type that together form one way to represent the entire Capture Scene.
キャプチャシーンビュー（CSV）：キャプチャシーン全体を表す1つの方法を組み合わせた同じメディアタイプのメディアキャプチャのリスト。
CLUE: CLUE is an acronym for "ControLling mUltiple streams for tElepresence", which is the name of the IETF working group in which this document and certain companion documents have been developed. Often, CLUE-* refers to something that has been designed by the CLUE working group; for example, this document may be called the CLUE-framework document herein and elsewhere.
CLUE：CLUEは、この文書と特定のコンパニオン文書が開発されているIETFワーキンググループの名前である「TelePresence用の複数のストリームを制御する」の頭字語です。しばしば、Clue- *は、手がかりワーキンググループによって設計されているものを指します。例えば、この文書は、ここで、他の場所にあるCLUEフレームワーク文書と呼ばれることがある。
CLUE-capable device: A device that supports the CLUE data channel [RFC8850], the CLUE protocol [RFC8847] and the principles of CLUE negotiation; it also seeks CLUE-enabled calls.
CLUE対応デバイス：CLUEデータチャネル[RFC8850]、CLUEプロトコル[RFC8847]、および手がかりネゴシエーションの原則をサポートするデバイス。また、CLUE対応コールを探します。
CLUE-enabled call: A call in which two CLUE-capable devices have successfully negotiated support for a CLUE data channel in SDP [RFC4566]. A CLUE-enabled call is not necessarily immediately able to send CLUE-controlled Media; negotiation of the data channel and of the CLUE protocol must complete first. Calls between two CLUE-capable devices that have not yet successfully completed negotiation of support for the CLUE data channel in SDP are not considered CLUE-enabled.
clue-enabled呼び出し：SDP [RFC4566]のCLUEデータチャネルのサポートに成功した2つのCLUE対応デバイスが正常にネゴシエートされたコール。CLUE対応の呼び出しは、必ずしもCLUE制御メディアを送信することができません。データチャネルと手がかりプロトコルの交渉は最初に完了する必要があります。SDP内のCLUEデータチャネルのサポートのネゴシエーションをまだ正常に完了していない2つのClue対応デバイス間のコールは、CLUE対応とは見なされません。
Conference: Used as defined in "A Framework for Conferencing within the Session Initiation Protocol (SIP)" [RFC4353].
会議：「セッション開始プロトコル（SIP）内の会議のためのフレームワーク（SIP）」[RFC4353]で定義されているように使用されます。
Configure Message: A CLUE message a Media Consumer sends to a Media Provider specifying which content and Media Streams it wants to receive, based on the information in a corresponding Advertisement message.
メッセージを構成する：CLUEメッセージは、対応する広告メッセージ内の情報に基づいて、受信したいコンテンツとメディアストリームを指定するメディアプロバイダに送信します。
Consumer: Short for Media Consumer.
消費者：メディアコンシューマのための短い。
Encoding: Short for Individual Encoding.
エンコード：個々のエンコーディングの場合は短い。
Encoding Group: A set of Encoding parameters representing a total Media Encoding capability to be subdivided across potentially multiple Individual Encodings.
エンコードグループ：潜在的に複数の個々のエンコーディングを分割するための総メディアエンコード機能を表す一連の符号化パラメータ。
Endpoint: A CLUE-capable device that is the logical point of final termination through receiving, decoding and Rendering, and/or initiation through capturing, encoding, and sending of Media Streams. An Endpoint consists of one or more physical devices that source and sink Media Streams, and exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera rooms to handheld devices.
エンドポイント：受信、復号化、レンダリング、および/またはメディアストリームのキャプチャ、エンコード、および送信による開始を通じて、最終終了の論理的なポイントであるCLUE対応デバイス。エンドポイントは、メディアストリームとシンクメディアストリームとシンクメディアストリーム、および厳密に1つの[RFC4353]参加者（順番に1つのSIPユーザーエージェントを含む）で構成されています。エンドポイントは、マルチスクリーン/マルチカメラルームからハンドヘルドデバイスへのものです。
Global View: A set of references to one or more CSVs of the same Media type that are defined within Scenes of the same Advertisement. A Global View is a suggestion from the Provider to the Consumer for one set of CSVs that provide a useful representation of all the Scenes in the Advertisement.
グローバルビュー：同じアドバタイズメントのシーン内に定義されている同じメディアタイプの1つ以上のCSVへの参照。グローバルビューは、広告内のすべてのシーンの有用な表現を提供する1セットのCSVのためのプロバイダから消費者への提案です。
Global View List: A list of Global Views included in an Advertisement. A Global View List may include Global Views of different Media types.
グローバルビューリスト：広告に含まれているグローバルビューのリスト。グローバルビューリストは、さまざまなメディアタイプのグローバルビューを含めることができます。
Individual Encoding: a set of parameters representing a way to encode a Media Capture to become a Capture Encoding.
個々のエンコーディング：メディアキャプチャをエンコードする方法を表す一連のパラメータ。
Multipoint Control Unit (MCU): a CLUE-capable device that connects two or more Endpoints into one single multimedia Conference [RFC7667]. An MCU includes a Mixer like that described in [RFC4353], without the requirement of [RFC4353] to send Media to each participant.
マルチポイント制御装置（MCU）：2つ以上のエンドポイントを1つのマルチメディアカンファレンスに接続する手対応装置[RFC7667]。MCUには、[RFC4353]のようなミキサーが含まれています。
Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, video, or timed text.
メディア：適切なエンコーディングの後に、オーディオ、ビデオ、またはタイミングテキストを含むRTPを介して伝達できるデータ。
Media Capture (MC): A source of Media, such as from one or more Capture Devices or constructed from other Media Streams.
Media Capture（MC）：1つ以上のキャプチャデバイスなどのメディアのソース、または他のメディアストリームから構築されています。
Media Consumer: A CLUE-capable device that intends to receive Capture Encodings.
メディアコンシューマ：キャプチャエンコーディングを受信するつもりの対応デバイス。
Media Provider: A CLUE-capable device that intends to send Capture Encodings.
メディアプロバイダ：キャプチャエンコーディングを送信するつもりのある手触りのあるデバイス。
Multiple Content Capture (MCC): A Capture that mixes and/or switches other Captures of a single type (for example, all audio or all video). Particular Media Captures may or may not be present in the resultant Capture Encoding, depending on time or space. Denoted as "MCCn" in the example cases in this document.
複数のコンテンツキャプチャ（MCC）：1つのタイプの他のキャプチャ（たとえば、すべてのオーディオまたはすべてのビデオなど）をミックスしたり切り替えたりするキャプチャ。特定のメディアキャプチャは、時間または空間に応じて、結果として生じるキャプチャ符号化に存在しなくてもよい。この文書の例として「MCCN」として表されます。
Plane of Interest: The spatial plane within a Scene containing the most-relevant subject matter.
興味のある平面：最も関連性のある主題を含むシーン内の空間平面。
Provider: Same as a Media Provider.
プロバイダ：メディアプロバイダと同じです。
Render: The process of generating a representation from Media, such as displayed motion video or sound emitted from loudspeakers.
レンダリング：表示された動画やスピーカーから放出された音声など、メディアからの表現を生成するプロセス。
Scene: Same as a Capture Scene.
シーン：キャプチャシーンと同じです。
Simultaneous Transmission Set: A set of Media Captures that can be transmitted simultaneously from a Media Provider.
同時送信セットメディアプロバイダから同時に送信できるメディアキャプチャのセット。
Single Media Capture: A Capture that contains Media from a single source Capture Device, e.g., an Audio Capture from a single microphone or a Video Capture from a single camera.
単一メディアキャプチャ：単一のソースキャプチャデバイスからのメディア、例えば単一のマイクロフォンまたは単一のカメラからのビデオキャプチャーからのオーディオキャプチャーを含むキャプチャ。
Spatial Relation: The arrangement of two objects in space, in contrast to relation in time or other relationships.
空間的関係：時間的または他の関係の関係とは対照的に、空間内の2つの物体の配置。
Stream: A Capture Encoding sent from a Media Provider to a Media Consumer via RTP [RFC3550].
ストリーム：RTP [RFC3550]を介してメディアプロバイダからメディアコンシューマに送信されたキャプチャエンコーディング。
Stream Characteristics: The Media Stream attributes commonly used in non-CLUE SIP/SDP environments (such as Media codec, bitrate, resolution, profile/level, etc.) as well as CLUE-specific attributes, such as the Capture ID or a spatial location.
ストリーム特性：Chaple IDや空間などの手がかり固有の属性だけでなく、非Clue SIP / SDP環境（メディアコーデック、ビットレート、解像度、プロファイル/レベルなど）で一般的に使用されているメディアストリーム属性ロケーション。
Video Capture (VC): Media Capture for video. Denoted as VCn in the example cases in this document.
Video Capture（VC）：ビデオ用のメディアキャプチャ。この文書の例の例では、VCNとして表されます。
Video Composite: A single image that is formed, normally by an RTP mixer inside an MCU, by combining visual elements from separate sources.
ビデオコンポジット：通常、MCU内のRTPミキサーによって形成されている単一の画像。
This section provides an overview of the functional elements defined in this document to represent a telepresence or multistream system. The motivations for the framework described in this document are also provided.
このセクションでは、この文書で定義されている機能要素の概要を示します。テレプレゼンスまたはマルチストリームシステムを表します。この文書に記載されているフレームワークの動機も提供されています。
Two key concepts introduced in this document are the terms "Media Provider" and "Media Consumer". A Media Provider represents the entity that sends the Media and a Media Consumer represents the entity that receives the Media. A Media Provider provides Media in the form of RTP packets; a Media Consumer consumes those RTP packets. Media Providers and Media Consumers can reside in Endpoints or in Multipoint Control Units (MCUs). A Media Provider in an Endpoint is usually associated with the generation of Media for Media Captures; these Media Captures are typically sourced from cameras, microphones, and the like. Similarly, the Media Consumer in an Endpoint is usually associated with renderers, such as screens and loudspeakers. In MCUs, Media Providers and Consumers can have the form of outputs and inputs, respectively, of RTP mixers, RTP translators, and similar devices. Typically, telepresence devices, such as Endpoints and MCUs, would perform as both Media Providers and Media Consumers, the former being concerned with those devices' transmitted Media and the latter with those devices' received Media. In a few circumstances, a CLUE-capable device includes only Consumer or Provider functionality, such as recorder-type Consumers or webcam-type Providers.
この文書で紹介されている2つの重要な概念は、「メディアプロバイダ」と「メディアコンシューマ」という用語です。メディアプロバイダは、メディアを送信するエンティティを表し、メディアコンシューマはメディアを受信するエンティティを表します。メディアプロバイダは、RTPパケットの形式でメディアを提供します。メディアコンシューマはこれらのRTPパケットを消費します。メディアプロバイダーとメディア消費者は、エンドポイントまたはマルチポイントコントロールユニット（MCU）に常駐することができます。エンドポイント内のメディアプロバイダは通常、メディアキャプチャのためのメディアの生成に関連しています。これらのメディアキャプチャは通常、カメラ、マイクロフォンなどから供給されます。同様に、エンドポイント内のメディアコンシューマは通常、スクリーンやスピーカーなどのレンダラーに関連付けられています。 MCUでは、メディアプロバイダーと消費者は、RTPミキサー、RTPトランスレータ、および類似のデバイスの出力と入力の形式を持つことができます。通常、エンドポイントやMCUなどのテレプレゼンスデバイスは、メディアプロバイダーとメディア消費者の両方として実行され、前者はこれらのデバイスの送信メディア、およびそれらのデバイスの受信メディアとの後者に関係します。いくつかの状況では、手軽のデバイスは、レコーダー型消費者またはウェブカメラ型プロバイダなどの消費者またはプロバイダ機能のみを含む。
The motivations for the framework outlined in this document include the following:
この文書で概説されているフレームワークの動機には、次のものがあります。
(1) Endpoints in telepresence systems typically have multiple Media Capture and Media Render devices, e.g., multiple cameras and screens. While previous system designs were able to set up calls that would capture Media using all cameras and display Media on all screens, for example, there was no mechanism that could associate these Media Captures with each other in space and time, in a cross-vendor interoperable way.
（1）テレプレゼンスシステム内のエンドポイントは通常、複数のメディアキャプチャおよびメディアレンダリング装置、例えば複数のカメラおよび画面を有する。以前のシステム設計は、すべてのスクリーン上のすべてのカメラと表示メディアを使用してメディアをキャプチャするコールを設定することができたが、例えば、これらのメディアキャプチャを互いに関連付けることができるメカニズムは終了しませんでした。相互運用方法
(2) The mere fact that there are multiple Media Capture and Media Render devices, each of which may be configurable in aspects such as zoom, leads to the difficulty that a variable number of such devices can be used to capture different aspects of a region. The Capture Scene concept allows for the description of multiple setups for those multiple Media Capture devices that could represent sensible operation points of the physical Capture Devices in a room, chosen by the operator. A Consumer can pick and choose from those configurations based on its rendering abilities and then inform the Provider about its choices. Details are provided in Section 7.
（2）複数のメディアキャプチャおよびメディアレンダリングデバイスが複数あるという事実は、ズームのような側面において構成可能であり得ることができ、そのようなデバイスの可変数が領域の異なる側面を捕捉することができるという困難さをもたらすことにつながる。。キャプチャシーンの概念は、オペレータによって選択された部屋内の物理キャプチャデバイスの賢明な動作ポイントを表すことができる複数のメディアキャプチャデバイスの複数のセットアップの説明を可能にします。消費者は、そのレンダリング能力に基づいてそれらの構成から選択して選択し、その選択についてプロバイダに知らせることができます。詳細はセクション7で提供されています。
(3) In some cases, physical limitations or other reasons disallow the concurrent use of a device in more than one setup. For example, the center camera in a typical three-camera conference room can set its zoom objective to capture either the middle few seats only or all seats of a room, but not both concurrently. The Simultaneous Transmission Set concept allows a Provider to signal such limitations. Simultaneous Transmission Sets are part of the Capture Scene description and are discussed in Section 8.
（3）場合によっては、物理的な制限またはその他の理由から、複数のセットアップでデバイスの同時使用を許可しません。たとえば、典型的な3カメラ会議室の中央カメラは、ズーム対物レンズを、ムードフックシートのみまたは部屋の座席のみを捉えるように設定することができますが、どちらも同時に使用できません。同時送信セットの概念により、プロバイダはそのような制限をシグナリングすることができます。同時送信セットはキャプチャシーンの説明の一部であり、セクション8で説明されています。
(4) Often, the devices in a room do not have the computational complexity or connectivity to deal with multiple Encoding options simultaneously, even if each of these options is sensible in certain scenarios, and even if the simultaneous transmission is also sensible (i.e., in case of multicast Media distribution to multiple Endpoints). Such constraints can be expressed by the Provider using the Encoding Group concept, which is described in Section 9.
（4）しばしば、これらのオプションのそれぞれが特定のシナリオで賢明であっても、室内のデバイスは、これらのオプションが特定のシナリオで賢明であっても、（すなわち、マルチキャストメディア配信の場合、複数のエンドポイントへのものです。そのような制約は、符号化グループの概念を使用してプロバイダによって表現することができ、これはセクション9で説明されている。
(5) Due to the potentially large number of RTP Streams required for a Multimedia Conference involving potentially many Endpoints, each of which can have many Media Captures and Media renderers, it has become common to multiplex multiple RTP Streams onto the same transport address, so as to avoid using the port number as a multiplexing point and the associated shortcomings such as NAT/firewall traversal. The large number of possible permutations of sensible options a Media Provider can make available to a Media Consumer makes a mechanism desirable that allows it to narrow down the number of possible options that a SIP offer/answer exchange has to consider. Such information is made available using protocol mechanisms specified in this document and companion documents. The Media Provider and Media Consumer may use information in CLUE messages to reduce the complexity of SIP offer/answer messages. Also, there are aspects of the control of both Endpoints and MCUs that dynamically change during the progress of a call, such as audio-level-based screen switching, layout changes, and so on, which need to be conveyed. Note that these control aspects are complementary to those specified in traditional SIP-based conference management, such as Binary Floor Control Protocol (BFCP). An exemplary call flow can be found in Section 5.
（5）多くのメディアキャプチャおよびメディアレンダラを含む多くのエンドポイントを含むマルチメディア会議に必要な潜在的に多数のRTPストリームが必要となるため、複数のRTPストリームを同じトランスポートアドレスに多重化することが一般的になっているので、ポート番号を多重化点として使用しないように、NAT /ファイアウォールトラバーサルなどの関連する欠点。賢明なオプションの多数の可能な順列メディアプロバイダがメディアコンシューマに入手可能にすることができるメカニズムは、SIPオファー/アンサー交換が考慮されなければならない可能性のあるオプションの数を絞り込むことを可能にするメカニズムを作ります。このような情報は、このドキュメントおよびコンパニオン文書で指定されたプロトコルメカニズムを使用して利用可能になります。メディアプロバイダおよびメディアコンシューマは、SIPオファー/アンサーメッセージの複雑さを軽減するために、CLUEメッセージ内の情報を使用することができる。また、オーディオレベルベースの画面切り替え、レイアウトの変更など、呼び出しの進行中に動的に変化するエンドポイントとMCUの制御の態様があります。これは伝送される必要があります。これらの制御面は、バイナリフロア制御プロトコル（BFCP）など、従来のSIPベースの会議管理で指定されたものと相補的です。例示的な呼出しフローはセクション5に見出すことができる。
Finally, all this information needs to be conveyed, and the notion of support for it needs to be established. This is done by the negotiation of a "CLUE channel", a data channel negotiated early during the initiation of a call. An Endpoint or MCU that rejects the establishment of this data channel, by definition, does not support CLUE-based mechanisms, whereas an Endpoint or MCU that accepts it is indicating support for CLUE as specified in this document and its companion documents.
最後に、この情報をすべて伝える必要があり、それをサポートする必要があります。これは、「手がかりチャネル」の交渉によって行われ、通話の開始中にネゴシエートされたデータチャネル。定義によってこのデータチャネルの確立を拒否するエンドポイントまたはMCUは、Checureベースのメカニズムをサポートしていませんが、これを受け入れるエンドポイントまたはMCUは、このドキュメントとそのコンパニオン文書で指定されているような手がかりのサポートを示しています。
The CLUE framework specifies how multiple Media Streams are to be handled in a telepresence Conference.
Clue Frameworkは、TelePresence Conferenceで複数のメディアストリームを処理する方法を指定します。
A Media Provider (transmitting Endpoint or MCU) describes specific aspects of the content of the Media and the Media Stream Encodings it can send in an Advertisement; and the Media Consumer responds to the Media Provider by specifying which content and Media Streams it wants to receive in a Configure message. The Provider then transmits the asked-for content in the specified Streams.
メディアプロバイダ（送信エンドポイントまたはMCU）は、メディアの内容の特定の態様とそれが広告に送信することができるメディアストリームエンコードを記述する。そして、メディアコンシューマは、設定メッセージ内で受信したいコンテンツとメディアストリームを指定することによってメディアプロバイダに応答します。プロバイダは、指定されたストリーム内のサポートされたコンテンツを送信します。
This Advertisement and Configure typically occur during call initiation, after CLUE has been enabled in a call, but they MAY also happen at any time throughout the call, whenever there is a change in what the Consumer wants to receive or (perhaps less common) what the Provider can send.
このアドバタイズメントと構成は通常、Callが呼び出し中に有効になった後、コールの開始中に発生しますが、消費者が受信したいものに変更がある場合はいつでも、または（おそらく一般的ではありません）プロバイダは送信できます。
An Endpoint or MCU typically acts as both Provider and Consumer at the same time, sending Advertisements and sending Configurations in response to receiving Advertisements. (It is possible to be just one or the other.)
エンドポイントまたはMCUは通常、プロバイダとコンシューマの両方として同時に、アドバタイズメントを送信し、アドバタイズメントの受信に応答して構成を送信する。（ただ一方またはもう一方にすることが可能です。）
The data model [RFC8846] is based around two main concepts: a Capture and an Encoding. A Media Capture, such as of type audio or video, has attributes to describe the content a Provider can send. Media Captures are described in terms of CLUE-defined attributes, such as Spatial Relationships and purpose of the Capture. Providers tell Consumers which Media Captures they can provide, described in terms of the Media Capture attributes.
データモデル[RFC8846]は、キャプチャとエンコーディングの2つの主な概念に基づいています。AudioまたはVideoの型などのメディアキャプチャには、プロバイダが送信できるコンテンツを記述する属性があります。メディアキャプチャは、キャプチャの空間的な関係や目的などの手がかり定義された属性に関して説明されています。プロバイダは、メディアキャプチャ属性に関して説明できるメディアキャプチャを消費者に伝えます。
A Provider organizes its Media Captures into one or more Capture Scenes, each representing a spatial region, such as a room. A Consumer chooses which Media Captures it wants to receive from the Capture Scenes.
プロバイダは、そのメディアキャプチャを1つ以上のキャプチャシーンに編成し、それぞれが部屋のような空間領域を表す。消費者は、キャプチャーシーンから受信したいメディアキャプチャを選択します。
In addition, the Provider can send the Consumer a description of the Individual Encodings it can send in terms of identifiers that relate to items in SDP [RFC4566].
さらに、プロバイダは、SDP [RFC4566]の項目に関連する識別子の観点から送信できる個々のエンコーディングの説明を消費者に送信できます。
The Provider can also specify constraints on its ability to provide Media, and a sensible design choice for a Consumer is to take these into account when choosing the content and Capture Encodings it requests in the later offer/answer exchange. Some constraints are due to the physical limitations of device; for example, a camera may not be able to provide zoom and non-zoom views simultaneously. Other constraints are system based, such as maximum bandwidth.
プロバイダはまた、メディアを提供する能力に制約を指定することができ、コンシューマのための賢明な設計選択は、コンテンツを選択し、後のオファー/回答Exchangeでそれを要求する際にエンコードをキャプチャするときにこれらを考慮に入れることです。いくつかの制約は装置の物理的な制限によるものです。たとえば、カメラはズームビューと非ズームビューを同時に提供できない場合があります。その他の制約は、最大帯域幅などのシステムベースです。
The following diagram illustrates the information contained in an Advertisement.
次の図は、広告に含まれる情報を示しています。
...................................................................
. Provider Advertisement +--------------------+ .
. | Simultaneous Sets | .
. +------------------------+ +--------------------+ .
. | Capture Scene N | +--------------------+ .
. +-+----------------------+ | | Global View List | .
. | Capture Scene 2 | | +--------------------+ .
. +-+----------------------+ | | +----------------------+ .
. | Capture Scene 1 | | | | Encoding Group N | .
. | +---------------+ | | | +-+--------------------+ | .
. | | Attributes | | | | | Encoding Group 2 | | .
. | +---------------+ | | | +-+--------------------+ | | .
. | | | | | Encoding Group 1 | | | .
. | +----------------+ | | | | parameters | | | .
. | | V i e w s | | | | | bandwidth | | | .
. | | +---------+ | | | | | +-------------------+| | | .
. | | |Attribute| | | | | | | V i d e o || | | .
. | | +---------+ | | | | | | E n c o d i n g s || | | .
. | | | | | | | | Encoding 1 || | | .
. | | View 1 | | | | | | || | | .
. | | (list of MCs) | | |-+ | +-------------------+| | | .
. | +----|-|--|------+ |-+ | | | | .
. +---------|-|--|---------+ | +-------------------+| | | .
. | | | | | A u d i o || | | .
. | | | | | E n c o d i n g s || | | .
. v | | | | Encoding 1 || | | .
. +---------|--|--------+ | | || | | .
. | Media Capture N |------>| +-------------------+| | | .
. +-+---------v--|------+ | | | | | .
. | Media Capture 2 | | | | |-+ .
. +-+--------------v----+ |-------->| | | .
. | Media Capture 1 | | | | |-+ .
. | +----------------+ |---------->| | .
. | | Attributes | | |_+ +----------------------+ .
. | +----------------+ |_+ .
. +---------------------+ .
. .
...................................................................
Figure 1: Advertisement Structure
図1：広告構造
Figure 2 illustrates the call flow used by a simple system (two Endpoints) in compliance with this document. A very brief outline of the call flow is described in the text that follows.
図2は、この文書に準拠して単純なシステム（2つのエンドポイント）が使用するコールフローを示しています。コールフローの非常に簡単な概要は、以下のテキストで説明されています。
+-----------+ +-----------+
| Endpoint1 | | Endpoint2 |
+----+------+ +-----+-----+
| INVITE (BASIC SDP+CLUECHANNEL) |
|--------------------------------->|
| 200 0K (BASIC SDP+CLUECHANNEL)|
|<---------------------------------|
| ACK |
|--------------------------------->|
| |
|<################################>|
| BASIC MEDIA SESSION |
|<################################>|
| |
| CONNECT (CLUE CTRL CHANNEL) |
|=================================>|
| ... |
|<================================>|
| CLUE CTRL CHANNEL ESTABLISHED |
|<================================>|
| |
| ADVERTISEMENT 1 |
|*********************************>|
| ADVERTISEMENT 2 |
|<*********************************|
| |
| CONFIGURE 1 |
|<*********************************|
| CONFIGURE 2 |
|*********************************>|
| |
| REINVITE (UPDATED SDP) |
|--------------------------------->|
| 200 0K (UPDATED SDP)|
|<---------------------------------|
| ACK |
|--------------------------------->|
| |
|<################################>|
| UPDATED MEDIA SESSION |
|<################################>|
| |
v v
Figure 2: Basic Information Flow
図2：基本情報の流れ
An initial offer/answer exchange establishes a basic Media session, for example, audio-only, and a CLUE channel between two Endpoints. With the establishment of that channel, the Endpoints have consented to use the CLUE protocol mechanisms and, therefore, MUST adhere to the CLUE protocol suite as outlined herein.
初期オファー/回答Exchangeは、基本的なメディアセッション、たとえば、オーディオ専用、および2つのエンドポイント間の手がかりチャネルを確立します。そのチャネルの確立により、エンドポイントは手がかりプロトコルメカニズムを使用することが同意しており、したがって、本明細書に概説されているように手がかりプロトコルスイートに付着しなければならない。
Over this CLUE channel, the Provider in each Endpoint conveys its characteristics and capabilities by sending an Advertisement as specified herein. The Advertisement is typically not sufficient to set up all Media. The Consumer in the Endpoint receives the information provided by the Provider and can use it for several purposes. It uses it, along with information from an offer/answer exchange, to construct a CLUE Configure message to tell the Provider what the Consumer wishes to receive. Also, the Consumer may use the information provided to tailor the SDP it is going to send during any following SIP offer/answer exchange, and its reaction to SDP it receives in that step. It is often a sensible implementation choice to do so. Spatial relationships associated with the Media can be included in the Advertisement, and it is often sensible for the Media Consumer to take those spatial relationships into account when tailoring the SDP. The Consumer can also limit the number of Encodings it must set up resources to receive, and not waste resources on unwanted Encodings, because it has the Provider's Advertisement information ahead of time to determine what it really wants to receive. The Consumer can also use the Advertisement information for local rendering decisions.
この手がかりチャネルの上に、各エンドポイントのプロバイダは、ここで指定されたように広告を送信することによってその特性と機能を伝達します。広告は通常、すべてのメディアを設定するのに十分ではありません。エンドポイント内の消費者は、プロバイダによって提供された情報を受け取り、それをいくつかの目的のために使用することができる。それはオファー/アンサー交換からの情報とともにそれを使用して、消費者が受信したいのかプロバイダーに指示するための手がかり設定メッセージを構築します。また、消費者は、SDPを調整するために提供された情報を使用してもよく、それは次のSIPオファー/アンサー交換の間に送信される予定の情報、およびそのステップで受信するSDPへの反応を使用することができる。そうすることはしばしば賢明な実装の選択です。メディアに関連した空間的関係は広告に含めることができ、SDPを調整するときにそれらの空間的関係を考慮に入れることはしばしば賢明である。消費者はまた、それが受信したいのかを判断するためにプロバイダの広告情報を受信するために、浪費されたエンコーディング上のリソースを浪費する必要があるエンコードの数を制限することもできます。消費者はまた、地域のレンダリング決定のために広告情報を使用することができる。
This initial CLUE exchange is followed by an SDP offer/answer exchange that not only establishes those aspects of the Media that have not been "negotiated" over CLUE, but also has the effect of setting up the Media transmission itself, involving potentially security exchanges, Interactive Connectivity Establishment (ICE), and whatnot. This step is considered "plain vanilla SIP".
この最初の手がかり交換の後には、手がかりを介して「交渉」されていないメディアの側面を確立するだけでなく、セキュリティ交換が潜在的にセキュリティ交換を伴うメディア送信自体を設定する効果もあります。インタラクティブ接続確立（氷）、および何でも。この手順は「普通のバニラSIP」と見なされます。
During the lifetime of a call, further exchanges MAY occur over the CLUE channel. In some cases, those further exchanges lead to a modified system behavior of Provider or Consumer (or both) without any other protocol activity such as further offer/answer exchanges. For example, a Configure Message requesting that the Provider place a different Capture source into a Capture Encoding, signaled over the CLUE channel, ought not to lead to heavy-handed mechanisms like SIP re-invites. In other cases, however, after the CLUE negotiation, an additional offer/answer exchange becomes necessary. For example, if both sides decide to upgrade the call from one screen to a multi-screen call, and more bandwidth is required for the additional video channels compared to what was previously negotiated using offer/ answer, a new offer/answer exchange is required.
呼び出しの存続期間中、さらなる交換は手がかりチャネルの上に起こり得る。場合によっては、さらなる交換は、さらなる提供/回答交換などの他のプロトコルアクティビティがなくても、プロバイダまたは消費者（またはその両方）の修正されたシステム挙動をもたらす。たとえば、プロバイダが異なるキャプチャソースをキャプチャエンコーディングに配置するように要求している構成メッセージは、CLUEチャネルを介してシグナリングされているため、SIP再招待状のような重いメカニズムにつながりません。しかしながら、他の場合には、手がかり交渉後、追加のオファー/回答交換が必要になる。たとえば、両方のサイズが1つの画面からマルチスクリーンコールへの通話をアップグレードすることにした場合、以前にオファー/アンサーを使用して交渉されたものと比較して追加のビデオチャンネルに多くの帯域幅が必要な場合は、新しいオファー/回答交換が必要です。。
One aspect of the protocol outlined herein, and specified in more detail in companion documents, is that it makes available to the Consumer information regarding the Provider's capabilities to deliver Media and attributes related to that Media such as their Spatial Relationship. The operation of the renderer inside the Consumer is unspecified in that it can choose to ignore some information provided by the Provider and/or not Render Media Streams available from the Provider (although the Consumer follows the CLUE protocol and, therefore, gracefully receives and responds to the Provider's information using a Configure operation).
本明細書で概説され、コンパニオン文書においてより詳細に規定されるプロトコルの一態様は、それがプロバイダの機能に関する消費者情報がそれらの空間的関係などのそのメディアに関連する媒体および属性を提供することを可能にすることである。コンシューマ内のレンダラの動作は、プロバイダから提供される情報を無視すること、および/またはプロバイダから入手可能な情報を無視することを選択することができます（ただし、消費者はCLUEプロトコルに従いますが、したがって、適切に受信して応答します。構成操作を使用してプロバイダの情報に。
A CLUE-capable device interoperates with a device that does not support CLUE. The CLUE-capable device can determine, by the result of the initial offer/answer exchange, if the other device supports and wishes to use CLUE. The specific mechanism for this is described in [RFC8848]. If the other device does not use CLUE, then the CLUE-capable device falls back to behavior that does not require CLUE.
手掛け対応デバイスは、手がかりをサポートしない装置と相互運用する。他のデバイスがサポートしてCLUEを使用したい場合は、最初のオファー/アンサー交換の結果によって判断できます。これに対する特定のメカニズムは[RFC8848]に記載されています。もう一方のデバイスがCLUEを使用しない場合、Clue対応デバイスは手がかりを必要としない動作に戻ります。
As for the Media, Provider and Consumer have an end-to-end communication relationship with respect to (RTP-transported) Media; and the mechanisms described herein and in companion documents do not change the aspects of setting up those RTP flows and sessions. In other words, the RTP Media sessions conform to the negotiated SDP whether or not CLUE is used.
メディアに関しては、プロバイダと消費者は（RTP輸送）メディアに関してエンドツーエンドの通信関係を有する。そして、本明細書で説明されているメカニズムおよびコンパニオン文書は、それらのRTPフローおよびセッションを設定するという側面を変更しない。言い換えれば、RTPメディアセッションは、Chegueが使用されているかどうかにかかわらずネゴシエートされたSDPに準拠しています。
In order for a Consumer to perform a proper rendering, it is often necessary (or at least helpful) for the Consumer to have received spatial information about the Streams it is receiving. CLUE defines a coordinate system that allows Media Providers to describe the Spatial Relationships of their Media Captures to enable proper scaling and spatially sensible rendering of their Streams. The coordinate system is based on a few principles:
消費者が適切なレンダリングを実行するためには、消費者が受信しているストリームに関する空間情報を受信したことがしばしば必要（または少なくとも有用である）である。手がかりは、メディアプロバイダーがそれらのメディアキャプチャの空間的関係を記述することを可能にする座標系を定義して、それらのストリームの適切なスケーリングおよび空間的に賢明なレンダリングを可能にする。座標系はいくつかの原則に基づいています。
* Each Capture Scene has a distinct coordinate system, unrelated to the coordinate systems of other Scenes.
* 各キャプチャシーンは、他のシーンの座標系とは無関係の異なる座標系を有する。
* Simple systems that do not have multiple Media Captures to associate spatially need not use the coordinate model, although it can still be useful to provide an Area of Capture.
* 空間的に関連付けるために複数のメディアキャプチャを持たない単純なシステムは、座標モデルを使用する必要はなく、キャプチャの領域を提供するのに役立ちます。
* Coordinates can either be in real, physical units (millimeters), have an unknown scale, or have no physical scale. Systems that know their physical dimensions (for example, professionally installed Telepresence room systems) MUST provide those real-world measurements to enable the best user experience for advanced receiving systems that can utilize this information. Systems that don't know specific physical dimensions but still know relative distances MUST use "Unknown Scale". "No Scale" is intended to be used only where Media Captures from different devices (with potentially different scales) will be forwarded alongside one another (e.g., in the case of an MCU).
* 座標は、実数、物理単位（ミリメートル）のいずれか、未知のスケールを持ち、物理的なスケールを持たないことができます。それらの物理的な寸法（たとえば、専門的に設置されたテレプレゼンスルームシステム）を知っているシステムは、この情報を利用できる高度な受信システムのための最良のユーザーエクスペリエンスを可能にするためにそれらの実世界の測定値を提供しなければなりません。特定の物理的な寸法を知らないが、それでも相対的な距離が知られているシステムは「不明なスケール」を使用しなければなりません。「スケールなし」は、（潜在的に異なるスケールで）異なる装置からのメディアキャプチャが互いに並んで転送される（例えば、MCUの場合）。
- "Millimeters" means the scale is in millimeters.
- 「ミリメートル」はスケールがミリメートル単位であることを意味します。
- "Unknown Scale" means the scale is not necessarily in millimeters, but the scale is the same for every Capture in the Capture Scene.
- 「不明なスケール」とは、スケールが必ずしもミリメートルではないことを意味しますが、キャプチャシーン内のキャプチャーごとにスケールは同じです。
- "No Scale" means the scale could be different for each Capture -- an MCU Provider that advertises two adjacent Captures and picks sources (which can change quickly) from different Endpoints might use this value; the scale could be different and changing for each Capture. But the areas of capture still represent a Spatial Relation between Captures.
- 「スケールなし」とは、各キャプチャごとにスケールが異なる可能性があることを意味します。スケールは、各キャプチャに対して異なり変化する可能性があります。しかし、キャプチャの領域は依然としてキャプチャ間の空間的関係を表しています。
* The coordinate system is right-handed Cartesian X, Y, Z with the origin at a spatial location of the Provider's choosing. The Provider MUST use the same coordinate system with the same scale and origin for all coordinates within the same Capture Scene.
* 座標系は、プロバイダの選択の空間位置にある原点を持つ右利きのデカルトx、y、zです。プロバイダは、同じキャプチャシーン内のすべての座標に対して同じスケールとオリジンを持つ同じ座標系を使用する必要があります。
The direction of increasing coordinate values is as follows: X increases from left to right, from the point of view of an observer at the front of the room looking toward the back; Y increases from the front of the room to the back of the room; Z increases from low to high (i.e., floor to ceiling).
座標値の増加の方向は以下の通りである。y部屋の前面から部屋の後ろまで増加する。Zは低くから高く（すなわち、床から天井まで）増加する。
Cameras in a Scene typically point in the direction of increasing Y, from front to back. But there could be multiple cameras pointing in different directions. If the physical space does not have a well-defined front and back, the Provider chooses any direction for X, Y, and Z consistent with right-handed coordinates.
シーン内のカメラは、通常、前面から背面まで、yが増加する方向を向いています。しかし、複数のカメラが異なる方向を向く可能性があります。物理スペースに正確に定義された前後に、プロバイダは右利きの座標と一致するX、Y、およびZの方向を選択します。
This section describes how Providers can describe the content of Media to Consumers.
このセクションでは、プロバイダはメディアのコンテンツを消費者に記述できる方法について説明します。
Media Captures are the fundamental representations of Streams that a device can transmit. What a Media Capture actually represents is flexible:
メディアキャプチャは、デバイスが送信できるストリームの基本表現です。メディアキャプチャが実際に表すのは柔軟です。
* It can represent the immediate output of a physical source (e.g., camera, microphone) or 'synthetic' source (e.g., laptop computer, DVD player).
* それは物理的な源（例えば、カメラ、マイクロフォン）または「合成」ソース（例えば、ラップトップコンピュータ、DVDプレーヤー）の即時出力を表すことができる。
* It can represent the output of an audio mixer or video composer.
* オーディオミキサーまたはビデオ作曲家の出力を表すことができます。
* It can represent a concept such as 'the loudest speaker'.
* それは「最も大きい話者」のような概念を表すことができます。
* It can represent a conceptual position such as 'the leftmost Stream'.
* 「左端のストリーム」などの概念的な位置を表すことができます。
To identify and distinguish between multiple Capture instances, Captures have a unique identity. For instance, VC1, VC2, AC1, and AC2 (where VC1 and VC2 refer to two different Video Captures and AC1 and AC2 refer to two different Audio Captures).
複数のキャプチャインスタンスを識別して区別するために、キャプチャは一意のIDを持ちます。たとえば、VC1、VC2、AC1、およびAC2（VC1とVC2は2つの異なるビデオキャプチャとAC1とAC2は2つの異なるオーディオキャプチャを参照）を参照してください。
Some key points about Media Captures:
メディアキャプチャに関するいくつかの重要なポイント：
* A Media Capture is of a single Media type (e.g., audio or video).
* メディアキャプチャは単一のメディアタイプ（例えば、オーディオまたはビデオ）のものです。
* A Media Capture is defined in a Capture Scene and is given an Advertisement unique identity. The identity may be referenced outside the Capture Scene that defines it through an MCC.
* メディアキャプチャはキャプチャシーンで定義され、広告の一意のIDが与えられます。IDは、MCCを介して定義するキャプチャシーンの外側で参照され得る。
* A Media Capture may be associated with one or more CSVs.
* メディアキャプチャは、1つまたは複数のCSVに関連付けられてもよい。
* A Media Capture has exactly one set of spatial information.
* メディアキャプチャは、全く1セットの空間情報を持っています。
* A Media Capture can be the source of at most one Capture Encoding.
* メディアキャプチャは、最大1つのキャプチャエンコーディングのソースです。
Each Media Capture can be associated with attributes to describe what it represents.
各メディアキャプチャは、それが表すものを説明するための属性に関連付けることができます。
Media Capture attributes describe information about the Captures. A Provider can use the Media Capture attributes to describe the Captures for the benefit of the Consumer of the Advertisement message. All these attributes are optional. Media Capture attributes include:
メディアキャプチャ属性は、キャプチャに関する情報を記述します。プロバイダは、アドバタイズメントメッセージのコンシューマの利点のためのキャプチャを記述するためにメディアキャプチャ属性を使用することができる。これらすべての属性はオプションです。メディアキャプチャ属性は次のとおりです。
* Spatial information, such as Point of Capture, Point on Line of Capture, and Area of Capture, (all of which, in combination, define the capture field of, for example, a camera).
* キャプチャのポイント、キャプチャライン、キャプチャの領域などの空間情報（すべて、組み合わせて、カメラのキャプチャフィールドを定義します）。
* Other descriptive information to help the Consumer choose between Captures (e.g., description, presentation, view, priority, language, person information, and type).
* 消費者がキャプチャ（例えば、説明、プレゼンテーション、ビュー、優先順位、言語、人情報、およびタイプ）を選択するのを助けるための他の記述的情報。
The subsections below define the Capture attributes.
以下のサブセクションはキャプチャ属性を定義します。
The Point of Capture attribute is a field with a single Cartesian (X, Y, Z) point value that describes the spatial location of the capturing device (such as camera). For an Audio Capture with multiple microphones, the Point of Capture defines the nominal midpoint of the microphones.
キャプチャ属性の点は、キャプチャデバイス（カメラなど）の空間位置を記述する単一のデカルト（x、y、z）ポイント値を持つフィールドです。複数のマイクロフォンを使用したオーディオキャプチャの場合、キャプチャのポイントはマイクロフォンの名目上の中点を定義します。
The Point on Line of Capture attribute is a field with a single Cartesian (X, Y, Z) point value that describes a position in space of a second point on the axis of the capturing device, toward the direction it is pointing; the first point being the Point of Capture (see above).
キャプチャ属性の点は、捕捉装置の軸上の2番目の点の空間内の位置を指している方向に向かって記述する単一のデカルト（x、y、z）点値を有するフィールドである。最初の点はキャプチャのポイントです（上記参照）。
Together, the Point of Capture and Point on Line of Capture define the direction and axis of the capturing device, for example, the optical axis of a camera or the axis of a microphone. The Media Consumer can use this information to adjust how it Renders the received Media if it so chooses.
まとめると、キャプチャのキャプチャとポイントのポイントは、キャプチャデバイスの方向と軸、たとえばカメラの光軸またはマイクロフォンの軸を定義します。メディアコンシューマはこの情報を使用して、受信したメディアを選択した場合にどのようにレンダリングするかを調整できます。
For an Audio Capture, the Media Consumer can use this information along with the Audio Capture Sensitivity Pattern to define a three-dimensional volume of capture where sounds can be expected to be picked up by the microphone providing this specific Audio Capture. If the Consumer wants to associate an Audio Capture with a Video Capture, it can compare this volume with the Area of Capture for video Media to provide a check on whether the Audio Capture is indeed spatially associated with the Video Capture. For example, a video Area of Capture that fails to intersect at all with the audio volume of capture, or is at such a long radial distance from the microphone Point of Capture that the audio level would be very low, would be inappropriate.
オーディオキャプチャのために、メディアコンシューマはこの情報をオーディオキャプチャ感度パターンと共に使用して、この特定のオーディオキャプチャを提供するマイクロフォンによってサウンドを拾うことが期待される3次元ボリュームのキャプチャを定義することができる。消費者がオーディオキャプチャをビデオキャプチャと関連付けることを望んでいる場合、それはこのボリュームをビデオメディアのキャプチャの領域と比較して、オーディオキャプチャがビデオキャプチャに空間的に関連付けられているかどうかをチェックすることができます。たとえば、キャプチャのオーディオボリュームを持つすべての復帰に失敗したキャプチャのビデオエリアは、オーディオレベルが非常に低くなると、キャプチャのマイクロフォンポイントからそのような長い半径方向の距離にあることが不適切となります。
The Area of Capture is a field with a set of four (X, Y, Z) points as a value that describes the spatial location of what is being "captured". This attribute applies only to Video Captures, not other types of Media. By comparing the Area of Capture for different Video Captures within the same Capture Scene, a Consumer can determine the Spatial Relationships between them and Render them correctly.
キャプチャの領域は、4つの（x、y、z）ポイントのセットが "キャプチャされている"の空間位置を表す値としてです。この属性は、他の種類のメディアではなく、ビデオキャプチャにのみ適用されます。同じキャプチャシーン内のさまざまなビデオキャプチャのキャプチャの領域を比較することで、消費者がそれらの間の空間的関係を決定し、それらを正しくレンダリングすることができます。
The four points MUST be co-planar, forming a quadrilateral, which defines the Plane of Interest for the particular Media Capture.
4つの点は共平面でなければならず、四辺形を形成する必要があり、それは特定のメディアキャプチャのための関心のある平面を定義する。
If the Area of Capture is not specified, it means the Video Capture might be spatially related to other Captures in the same Scene, but there is no detailed information on the relationship. For a switched Capture that switches between different sections within a larger area, the Area of Capture MUST use coordinates for the larger potential area.
キャプチャの領域が指定されていない場合は、ビデオキャプチャが同じシーン内の他のキャプチャに空間的に関連している可能性があることを意味しますが、関係に関する詳細な情報はありません。より大きな領域内の異なるセクション間を切り替えるスイッチキャプチャの場合、キャプチャの領域は、より大きな電位領域の座標を使用する必要があります。
The Mobility of Capture attribute indicates whether or not the Point of Capture, Point on Line of Capture, and Area of Capture values stay the same over time, or are expected to change (potentially frequently). Possible values are static, dynamic, and highly dynamic.
Capture属性の移動性は、キャプチャのポイント、キャプチャラインのポイント、およびキャプチャ値の領域が時間の経過とともに同じままであるかどうかを示します。可能な値は静的、動的、そして非常に動的です。
An example for "dynamic" is a camera mounted on a stand that is occasionally hand-carried and placed at different positions in order to provide the best angle to capture a work task. A camera worn by a person who moves around the room is an example for "highly dynamic". In either case, the effect is that the Point of Capture, Capture Axis, and Area of Capture change with time.
「動的」の例は、時折手を持ち上げられ、作業タスクをキャプチャするための最良の角度を提供するために異なる位置に配置されているスタンドに取り付けられたカメラです。部屋の周りを移動する人が着用するカメラは、「非常に動的」の例です。いずれの場合も、その効果はキャプチャのポイント、キャプチャ軸、およびキャプチャの領域が時間とともに変化することです。
The Point of Capture of a static Capture MUST NOT move for the life of the CLUE session. The Point of Capture of dynamic Captures is categorized by a change in position followed by a reasonable period of stability -- in the order of magnitude of minutes. Highly dynamic Captures are categorized by a Point of Capture that is constantly moving. If the Area of Capture, Point of Capture, and Point on Line of Capture attributes are included with dynamic or highly dynamic Captures, they indicate spatial information at the time of the Advertisement.
静的キャプチャのキャプチャのポイントは、手がかりセッションの寿命のために動いてはならない。動的キャプチャのキャプチャのポイントは、位置の変化とそれに続く合理的な安定期間 - 数分の順に分類されます。動的なキャプチャは、常に動いているキャプチャのポイントによって分類されます。キャプチャの領域、キャプチャのポイント、およびキャプチャ属性のポイントが動的なキャプチャまたは非常に動的なキャプチャに含まれる場合、それらは広告の時点で空間情報を示します。
The Audio Capture Sensitivity Pattern attribute applies only to Audio Captures. This attribute gives information about the nominal sensitivity pattern of the microphone that is the source of the Capture. Possible values include patterns such as omni, shotgun, cardioid, and hyper-cardioid.
Audio Capture Sensitivity Pattern属性は、オーディオキャプチャにのみ適用されます。この属性は、キャプチャの源であるマイクロフォンの公称感度パターンに関する情報を提供します。可能な値には、OMNI、ショットガン、CardioID、およびHyper-CardioIDなどのパターンが含まれます。
The Description attribute is a human-readable description (which could be in multiple languages) of the Capture.
description属性は、キャプチャの人間が読める記述（複数の言語である可能性があります）です。
The Presentation attribute indicates that the Capture originates from a presentation device, that is, one that provides supplementary information to a Conference through slides, video, still images, data, etc. Where more information is known about the Capture, it MAY be expanded hierarchically to indicate the different types of presentation Media, e.g., presentation.slides, presentation.image, etc.
プレゼンテーション属性は、キャプチャがプレゼンテーションデバイス、すなわち、スライド、ビデオ、静止画像、データなどを介して会議に補足情報を提供するものが、キャプチャについてより多くの情報が知られている場合、それは階層的に拡張される可能性があることを示している。PresentationSlides、Presentation.Imageなどのさまざまな種類のプレゼンテーションメディアを示すこと
Note: It is expected that a number of keywords will be defined that provide more detail on the type of presentation. Refer to [RFC8846] for how to extend the model.
注：プレゼンテーションの種類について詳しく説明する多くのキーワードが定義されます。モデルを拡張する方法については、[RFC8846]を参照してください。
The View attribute is a field with enumerated values, indicating what type of view the Capture relates to. The Consumer can use this information to help choose which Media Captures it wishes to receive. Possible values are as follows:
View属性は、列挙値を持つフィールドで、キャプチャがどのようなビューに関連しているのかを示します。消費者はこの情報を使用して、どのメディアキャプチャが受信したいかを選択するのを助けることができます。可能な値は次のとおりです。
Room: Captures the entire Scene
部屋：シーン全体をキャプチャします
Table: Captures the conference table with seated people
テーブル：会議テーブルを着席している人とキャプチャします
Individual: Captures an individual person
個人：個々の人を捕まえる
Lectern: Captures the region of the lectern including the presenter, for example, in a classroom-style conference room
レクターン：プレゼンターを含むレクターの領域を、例えば教室スタイルの会議室で捉えています
Audience: Captures a region showing the audience in a classroom-style conference room
視聴者：教室スタイルの会議室で聴衆を示す地域をキャプチャする
The Language attribute indicates one or more languages used in the content of the Media Capture. Captures MAY be offered in different languages in case of multilingual and/or accessible Conferences. A Consumer can use this attribute to differentiate between them and pick the appropriate one.
言語属性は、メディアキャプチャの内容で使用される1つ以上の言語を示します。多言語および/またはアクセス可能な会議の場合、キャプチャはさまざまな言語で提供される可能性があります。消費者はこの属性を使用してそれらの間を区別し、適切なものを選択することができます。
Note that the Language attribute is defined and meaningful both for Audio and Video Captures. In case of Audio Captures, the meaning is obvious. For a Video Capture, "Language" could, for example, be sign interpretation or text.
言語属性は、オーディオキャプチャとビデオキャプチャの両方で定義され、意味があることに注意してください。オーディオキャプチャの場合、意味は明らかです。ビデオキャプチャの場合、「言語」は、たとえば、署名解釈やテキストになります。
The Language attribute is coded per [RFC5646].
言語属性は[RFC5646]ごとにコーディングされています。
The Person Information attribute allows a Provider to provide specific information regarding the people in a Capture (regardless of whether or not the Capture has a Presentation attribute). The Provider may gather the information automatically or manually from a variety of sources; however, the xCard [RFC6351] format is used to convey the information. This allows various information, such as Identification information (Section 6.2 of [RFC6350]), Communication Information (Section 6.4 of [RFC6350]), and Organizational information (Section 6.6 of [RFC6350]), to be communicated. A Consumer may then automatically (i.e., via a policy) or manually select Captures based on information about who is in a Capture. It also allows a Consumer to Render information regarding the people participating in the Conference or to use it for further processing.
Person Information属性により、プロバイダはキャプチャ内の人々に関する特定の情報を提供することを可能にします（キャプチャのプレゼンテーション属性があるかどうかにかかわらず）。プロバイダは、さまざまな情報源から自動的にまたは手動で情報を収集することがあります。ただし、XCARD [RFC6351]フォーマットは情報を伝えるために使用されます。これにより、識別情報（RFC6350のセクション6.2）、通信情報（RFC6350]のセクション6.4）、組織情報（RFC6350]のセクション6.6）など、さまざまな情報が伝達されます。その後、消費者は自動的に（すなわち、ポリシーを介して）またはキャプチャ中の情報に基づいてキャプチャを選択することができる。また、消費者が会議に参加している人々に関する情報をレンダリングすること、またはそれをさらなる処理のために使用することを可能にします。
The Provider may supply a minimal set of information or a larger set of information. However, it MUST be compliant to [RFC6350] and supply a "VERSION" and "FN" property. A Provider may supply multiple xCards per Capture of any KIND (Section 6.1.4 of [RFC6350]).
プロバイダは、最小限の情報またはより大きな情報セットを供給することができる。ただし、[RFC6350]に準拠しており、「バージョン」と「FN」プロパティを入力する必要があります。プロバイダは、任意の種類のキャプチャごとに複数のXcardsを提供することができます（[RFC6350]のセクション6.1.4）。
In order to keep CLUE messages compact, the Provider SHOULD use a URI to point to any LOGO, PHOTO, or SOUND contained in the xCard rather than transmitting the LOGO, PHOTO, or SOUND data in a CLUE message.
CLUEメッセージをコンパクトに保つために、プロバイダは、ロゴ、写真、またはサウンドデータをCLUEメッセージに送信するのではなく、XCardに含まれるロゴ、写真、またはサウンドを指すようにURIを使用する必要があります。
The Person Type attribute indicates the type of people contained in the Capture with respect to the meeting agenda (regardless of whether or not the Capture has a Presentation attribute). As a Capture may include multiple people, the attribute may contain multiple values. However, values MUST NOT be repeated within the attribute.
Person Type属性は、（キャプチャーがプレゼンテーション属性があるかどうかにかかわらず）、会議の議題に関するキャプチャに含まれている人々の種類を示します。キャプチャが複数の人々を含めることができるので、属性に複数の値を含めることができます。ただし、値を属性内で繰り返してはいけません。
An Advertiser associates the person type with an individual Capture when it knows that a particular type is in the Capture. If an Advertiser cannot link a particular type with some certainty to a Capture, then it is not included. On reception of a Capture with a Person Type attribute, a Consumer knows with some certainty that the Capture contains that person type. The Capture may contain other person types, but the Advertiser has not been able to determine that this is the case.
特定のタイプがキャプチャ内にあることを知っている場合、広告主は個人のタイプを個々のキャプチャと関連付けます。広告主が特定の種類をいくつかの確実性をキャプチャにリンクできない場合は含まれません。Person Type属性を使用したキャプチャを受信すると、消費者はキャプチャにその人の種類が含まれていることを確認しています。キャプチャには他の人種が含まれているかもしれませんが、広告主はこれが事実であると判断できませんでした。
The types of Captured people include:
捕獲された人々の種類は次のとおりです。
Chair: the person responsible for running the meeting according to the agenda.
議長：議題に従って会議を実行する責任がある人。
Vice-Chair: the person responsible for assisting the chair in running the meeting.
副議長：会議を実行している椅子を支援する責任がある人。
Minute Taker: the person responsible for recording the minutes of the meeting.
分採集：会議の議事録を録音する責任がある人。
Attendee: the person has no particular responsibilities with respect to running the meeting.
出席者：その人は、会議の実行に関して特に責任を負いません。
Observer: an Attendee without the right to influence the discussion.
オブザーバー：議論に影響を与える権利なしの出席者。
Presenter: the person scheduled on the agenda to make a presentation in the meeting. Note: This is not related to any "active speaker" functionality.
発表者：会議にプレゼンテーションをするためにアジェンダにスケジュールされた人。注：これは「アクティブなスピーカー」機能とは関係ありません。
Translator: the person providing some form of translation or commentary in the meeting.
翻訳者：会議で何らかの形の翻訳または解説を提供する人。
Timekeeper: the person responsible for maintaining the meeting schedule.
TimeKeeper：会議スケジュールを維持する責任がある人。
Furthermore, the Person Type attribute may contain one or more strings allowing the Provider to indicate custom meeting-specific types.
さらに、Person Type属性には、プロバイダがカスタム会議固有の型を示すことができる1つ以上の文字列を含めることができます。
The Priority attribute indicates a relative priority between different Media Captures. The Provider sets this priority, and the Consumer MAY use the priority to help decide which Captures it wishes to receive.
優先属性属性は、さまざまなメディアキャプチャ間の相対優先順位を示します。プロバイダはこの優先順位を設定し、消費者は優先順位を使用して、どのキャプチャを受信したいかを決定するのに役立ちます。
The Priority attribute is an integer that indicates a relative priority between Captures. For example, it is possible to assign a priority between two presentation Captures that would allow a remote Endpoint to determine which presentation is more important. Priority is assigned at the individual Capture level. It represents the Provider's view of the relative priority between Captures with a priority. The same priority number MAY be used across multiple Captures. It indicates that they are equally important. If no priority is assigned, no assumptions regarding relative importance of the Capture can be assumed.
priority属性は、キャプチャ間の相対優先順位を示す整数です。例えば、リモートエンドポイントがどのプレゼンテーションがより重要であるかを判断できるようにする2つのプレゼンテーションキャプチャ間で優先順位を割り当てることが可能である。個々のキャプチャレベルで優先順位が割り当てられています。優先順位を持つキャプチャ間の相対優先順位のプロバイダーのビューを表します。複数のキャプチャにまたがって同じ優先順位番号が使用されることがあります。それは彼らが同様に重要であることを示しています。優先順位が割り当てられていない場合、キャプチャの相対的な重要度に関する仮定は想定できません。
The Embedded Text attribute indicates that a Capture provides embedded textual information. For example, the Video Capture may contain speech-to-text information composed with the video image.
埋め込みText属性は、キャプチャが埋め込まれたテキスト情報を提供することを示します。例えば、ビデオキャプチャは、ビデオ画像と構成されるテキスト情報を含むことができる。
The Related To attribute indicates the Capture contains additional complementary information related to another Capture. The value indicates the identity of the other Capture to which this Capture is providing additional information.
属性に関する関数は、キャプチャに別のキャプチャに関する追加の補完情報が含まれています。値は、このキャプチャが追加情報を提供している他のキャプチャのIDを示します。
For example, a Conference can utilize translators or facilitators that provide an additional audio Stream (i.e., a translation or description or commentary of the Conference). Where multiple Captures are available, it may be advantageous for a Consumer to select a complementary Capture instead of or in addition to a Capture it relates to.
例えば、会議は、追加のオーディオストリーム（すなわち、会議の翻訳または説明または解説）を提供する翻訳者またはファシリテータを利用することができる。複数のキャプチャが利用可能である場合、消費者がそれに関連するキャプチャの代わりにまたはそれに加えて、コンパウンドが補完的キャプチャを選択することが有利であり得る。
The MCC indicates that one or more Single Media Captures are multiplexed (temporally and/or spatially) or mixed in one Media Capture. Only one Capture type (i.e., audio, video, etc.) is allowed in each MCC instance. The MCC may contain a reference to the Single Media Captures (which may have their own attributes) as well as attributes associated with the MCC itself. An MCC may also contain other MCCs. The MCC MAY reference Captures from within the Capture Scene that defines it or from other Capture Scenes. No ordering is implied by the order that Captures appear within an MCC. An MCC MAY contain no references to other Captures to indicate that the MCC contains content from multiple sources, but no information regarding those sources is given. MCCs either contain the referenced Captures and no others or have no referenced Captures and, therefore, may contain any Capture.
MCCは、1つ以上の単一のメディアキャプチャが多重化されている（時間的および/または空間的に）、または1つのメディアキャプチャで混合されていることを示します。各MCCインスタンスでは、キャプチャタイプ（すなわち、オーディオ、ビデオなど）だけが許可されています。MCCは、MCC自体に関連付けられた属性と同様に、単一のメディアキャプチャ（それら自身の属性を有する可能性がある）への参照を含み得る。MCCには他のMCCも含めることができます。MCCは、それを定義する、または他のキャプチャーシーンからのキャプチャシーン内からのキャプチャを参照することができる。キャプチャがMCC内に表示される順序によって順序付けされていません。MCCには、MCCに複数のソースからのコンテンツが含まれているが、それらの情報源に関する情報は与えられていないことを示すために、他のキャプチャへの参照は含まれていない可能性がある。MCCSは参照されたキャプチャを含み、他のものは含まれていないか、参照されていないキャプチャを持っていないため、キャプチャを含めることができます。
One or more MCCs may also be specified in a CSV. This allows an Advertiser to indicate that several MCC Captures are used to represent a Capture Scene. Table 14 provides an example of this case.
1つまたは複数のMCCSもCSVで指定されてもよい。これにより、広告主が複数のMCCキャプチャがキャプチャシーンを表すために使用されることを示すことができます。表14はこの場合の例を示しています。
As outlined in Section 7.1, each instance of the MCC has its own Capture identity, i.e., MCC1. It allows all the individual Captures contained in the MCC to be referenced by a single MCC identity.
セクション7.1で概説されているように、MCCの各インスタンスはそれ自体のキャプチャ識別情報、すなわちMCC1を有する。MCCに含まれているすべての個々のキャプチャを単一のMCC IDによって参照できます。
The example below shows the use of a Multiple Content Capture:
以下の例は、複数のコンテンツキャプチャの使用を示しています。
+===================+=========================+
| Capture Scene #1 | |
+===================+=========================+
| VC1 | {MC attributes} |
+-------------------+-------------------------+
| VC2 | {MC attributes} |
+-------------------+-------------------------+
| VC3 | {MC attributes} |
+-------------------+-------------------------+
| MCC1(VC1,VC2,VC3) | {MC and MCC attributes} |
+-------------------+-------------------------+
| CSV(MCC1) | |
+-------------------+-------------------------+
Table 1: Multiple Content Capture Concept
表1：複数のコンテンツキャプチャの概念
This indicates that MCC1 is a single Capture that contains the Captures VC1, VC2, and VC3, according to any MCC1 attributes.
これは、MCC1が任意のMCC1属性に従って、キャプチャVC1、VC2、およびVC3を含む単一のキャプチャであることを示しています。
Media Capture attributes may be associated with the MCC instance and the Single Media Captures that the MCC references. A Provider should avoid providing conflicting attribute values between the MCC and Single Media Captures. Where there is conflict the attributes of the MCC, a Provider should override any that may be present in the individual Captures.
メディアキャプチャ属性は、MCCインスタンスと関連付けられ、単一のメディアはMCC参照をキャプチャします。プロバイダは、MCCと単一のメディアキャプチャとの間に矛盾する属性値を提供することを避けるべきです。MCCの属性に矛盾がある場合、プロバイダは個々のキャプチャに存在する可能性があるものをオーバーライドする必要があります。
A Provider MAY include as much or as little of the original source Capture information as it requires.
プロバイダは、それが必要とされるのと同じように、またはほとんどのソースキャプチャ情報のほとんどを含めることができる。
There are MCC-specific attributes that MUST only be used with Multiple Content Captures. These are described in the sections below. The attributes described in Section 7.1.1 MAY also be used with MCCs.
複数のコンテンツキャプチャでのみ使用する必要があるMCC固有の属性があります。以下のセクションで説明します。セクション7.1.1に記載されている属性もMCCSで使用できます。
The spatial-related attributes of an MCC indicate its Area of Capture and Point of Capture within the Scene, just like any other Media Capture. The spatial information does not imply anything about how other Captures are composed within an MCC.
MCCの空間関連属性は、他のメディアキャプチャと同じように、シーン内のキャプチャの領域とキャプチャのポイントを示します。空間情報は、MCC内で他のキャプチャがどのように構成されているかについてのものを意味するものではありません。
For example: a virtual Scene could be constructed for the MCC Capture with two Video Captures with a MaxCaptures attribute set to 2 and an Area of Capture attribute provided with an overall area. Each of the individual Captures could then also include an Area of Capture attribute with a subset of the overall area. The Consumer would then know how each Capture is related to others within the Scene, but not the relative position of the individual Captures within the composed Capture.
たとえば、MAXCAPTURES属性が2に設定されている2つのビデオキャプチャを使用してMCCキャプチャのために仮想シーンを構築することができます。各個々のキャプチャは、全体の領域のサブセットを持つキャプチャ属性の領域も含まれ得る。消費者は、各キャプチャがシーン内の他の人とどのように関連しているかを知っていますが、合成されたキャプチャ内の個々のキャプチャの相対的な位置ではありません。
+===============+===================================+
| Capture Scene | |
| #1 | |
+===============+===================================+
| VC1 | AreaofCapture=(0,0,0)(9,0,0) |
| | (0,0,9)(9,0,9) |
+---------------+-----------------------------------+
| VC2 | AreaofCapture=(10,0,0)(19,0,0) |
| | (10,0,9)(19,0,9) |
+---------------+-----------------------------------+
| MCC1(VC1,VC2) | MaxCaptures=2 |
| | AreaofCapture=(0,0,0)(19,0,0) |
| | (0,0,9)(19,0,9) |
+---------------+-----------------------------------+
| CSV(MCC1) | |
+---------------+-----------------------------------+
Table 2: Example of MCC and Single Media Capture Attributes
表2：MCCおよび単一メディアキャプチャ属性の例
The subsections below describe the MCC-only attributes.
以下のサブセクションはMCC専用属性を説明しています。
The MaxCaptures attribute indicates the maximum number of individual Captures that may appear in a Capture Encoding at a time. The actual number at any given time can be less than or equal to this maximum. It may be used to derive how the Single Media Captures within the MCC are composed/switched with regard to space and time.
maxcaptures属性は、一度にキャプチャエンコーディングに表示される可能性がある個々のキャプチャの最大数を示します。特定の時間の実際の数は、この最大値以下にすることができます。MCC内の単一のメディアキャプチャが空間と時間に関して構成/切り替えられる方法を導き出すために使用され得る。
A Provider can indicate that the number of Captures in an MCC Capture Encoding is equal ("=") to the MaxCaptures value or that there may be any number of Captures up to and including ("<=") the MaxCaptures value. This allows a Provider to distinguish between an MCC that purely represents a composition of sources and an MCC that represents switched sources or switched and composed sources.
プロバイダは、MCCキャプチャエンコード内のキャプチャ数（ "="）がMAXCAPTURES値に等しい（ "="）、またはMAXCAPTURES値までの任意の数のキャプチャ（ "<="）があるかもしれないことを示すことができます。これにより、プロバイダは、純粋なソースの構成を表すMCCと、交換されたソースや切り替えされたソースを表すMCCとを区別することができます。
MaxCaptures may be set to one so that only content related to one of the sources is shown in the MCC Capture Encoding at a time, or it may be set to any value up to the total number of Source Media Captures in the MCC.
MAXCAPTURESは、一度にMCCキャプチャエンコーディングにあるコンテンツのみが表示されるか、またはMCC内のソースメディアキャプチャの総数まで任意の値に設定されてもよい。
The bullets below describe how the setting of MaxCaptures versus the number of Captures in the MCC affects how sources appear in a Capture Encoding:
以下の箇条書きは、MAXCAPTURESの設定がMCCのキャプチャ数とキャプチャの数がキャプチャエンコーディングにどのように表示されるかに影響する方法を説明しています。
* A switched case occurs when MaxCaptures is set to <= 1 and the number of Captures in the MCC is greater than 1 (or not specified) in the MCC. Zero or one Captures may be switched into the Capture Encoding. Note: zero is allowed because of the "<=".
* MAXCAPTURESが<= 1に設定され、MCC内のキャプチャ数がMCCで1より大きい（または指定されていない）場合、スイッチドケースが発生します。ゼロまたは1つのキャプチャをキャプチャ符号化に切り替えることができる。注： "<="のためにゼロが許可されています。
* A switched case occurs when MaxCaptures is set to = 1 and the number of Captures in the MCC is greater than 1 (or not specified) in the MCC. Only one Capture source is contained in a Capture Encoding at a time.
* MAXCAPTURESが= 1に設定され、MCC内のキャプチャ数がMCCで1より大きい場合（または指定されていない）場合、スイッチドケースが発生します。一度にキャプチャエンコーディングに含まれるキャプチャソースは1つだけです。
* A switched and composed case occurs when MaxCaptures is set to <= N (with N > 1) and the number of Captures in the MCC is greater than N (or not specified). The Capture Encoding may contain purely switched sources (i.e., <=2 allows for one source on its own), or it may contain composed and switched sources (i.e., a composition of two sources switched between the sources).
* MAXCAPTURESが<= n（n> 1で）に設定されているときにスイッチングされて構成されたケースは、MCC内のキャプチャ数がnより大きい（または指定されていない）。キャプチャ符号化は、純粋に切り替えされたソースを含み得る（すなわち、<= 2はそれ自体1つのソースを可能にする）、またはそれが構成要素および切り替えされたソース（すなわち、ソース間で切り替えられた2つのソースの構成を含む）を含み得る。
* A switched and composed case occurs when MaxCaptures is set to = N (with N > 1) and the number of Captures in the MCC is greater than N (or not specified). The Capture Encoding contains composed and switched sources (i.e., a composition of N sources switched between the sources). It is not possible to have a single source.
* MAXCAPTURESが= Nに設定されている場合（N> 1を持つ）ときには、スイッチングされて構成されたケースが発生し、MCC内のキャプチャ数はNより大きい（または指定されていない）。キャプチャ符号化は、構成および切り替えされたソース（すなわち、ソース間で切り替えられたN個のソースの構成）を含む。単一のソースを持つことはできません。
* A switched and composed case occurs when MaxCaptures is set <= to the number of Captures in the MCC. The Capture Encoding may contain Media switched between any number (up to the MaxCaptures) of composed sources.
* MAXCAPTURESがMCC内のキャプチャ数に設定されているときに、スイッチングされて構成されたケースが発生します。キャプチャ符号化は、合成されたソースの任意の数（最大キャプチャ）の間で切り替えられたメディアを含み得る。
* A composed case occurs when MaxCaptures is set = to the number of Captures in the MCC. All the sources are composed into a single Capture Encoding.
* MAXCAPTURESがMCC内のキャプチャ数に設定されている場合、合成ケースが発生します。すべてのソースは単一のキャプチャ符号化に構成されています。
If this attribute is not set, then as a default, it is assumed that all source Media Capture content can appear concurrently in the Capture Encoding associated with the MCC.
この属性が設定されていない場合、デフォルトとして、MCCに関連付けられているキャプチャエンコーディングですべてのソースメディアキャプチャコンテンツが同時に表示されることがあると仮定されます。
For example, the use of MaxCaptures equal to 1 on an MCC with three Video Captures, VC1, VC2, and VC3, would indicate that the Advertiser in the Capture Encoding would switch between VC1, VC2, and VC3 as there may be only a maximum of one Capture at a time.
たとえば、3つのビデオキャプチャ、VC1、VC2、およびVC3を3つのMCC上で1に等しいMAXCAPTURESの使用は、キャプチャエンコーディング内の広告主がVC1、VC2、およびVC3を切り替えることを示します。一度に1回の捕獲の。
The Policy MCC attribute indicates the criteria that the Provider uses to determine when and/or where Media content appears in the Capture Encoding related to the MCC.
Policy MCC属性は、プロバイダーがMCCに関連するキャプチャエンコーディングにいつ/またはメディアコンテンツが表示されるかを決定するためにプロバイダーが使用する基準を示します。
The attribute is in the form of a token that indicates the policy and an index representing an instance of the policy. The same index value can be used for multiple MCCs.
属性は、ポリシーを示すトークンとポリシーのインスタンスを表すインデックスの形式です。複数のMCCには同じインデックス値を使用できます。
The tokens are as follows:
トークンは次のとおりです。
SoundLevel: This indicates that the content of the MCC is determined by a sound-level-detection algorithm. The loudest (active) speaker (or a previous speaker, depending on the index value) is contained in the MCC.
SoundLevel：MCCの内容がサウンドレベル検出アルゴリズムによって決定されていることを示します。MCCには、最も大きい（アクティブな）スピーカー（またはインデックス値に応じて前のスピーカー）が含まれています。
RoundRobin: This indicates that the content of the MCC is determined by a time-based algorithm. For example, the Provider provides content from a particular source for a period of time and then provides content from another source, and so on.
Roundrobin：これは、MCCの内容が時間ベースのアルゴリズムによって決定されることを示しています。たとえば、プロバイダは特定のソースから一定期間コンテンツを提供し、次に別のソースからコンテンツを提供します。
An index is used to represent an instance in the policy setting. An index of 0 represents the most current instance of the policy, i.e., the active speaker, 1 represents the previous instance, i.e., the previous active speaker, and so on.
インデックスは、ポリシー設定内のインスタンスを表すために使用されます。index 0は、ポリシーの最新のインスタンス、すなわちアクティブスピーカ1を表し、1は前のインスタンス、すなわち前のアクティブスピーカなどを表す。
The following example shows a case where the Provider provides two Media Streams, one showing the active speaker and a second Stream showing the previous speaker.
次の例は、プロバイダが2つのメディアストリームを提供する場合を示し、1つはアクティブスピーカーと前のスピーカーを示す第2のストリームとを示す。
+==================+=====================+
| Capture Scene #1 | |
+==================+=====================+
| VC1 | |
+------------------+---------------------+
| VC2 | |
+------------------+---------------------+
| MCC1(VC1,VC2) | Policy=SoundLevel:0 |
| | MaxCaptures=1 |
+------------------+---------------------+
| MCC2(VC1,VC2) | Policy=SoundLevel:1 |
| | MaxCaptures=1 |
+------------------+---------------------+
| CSV(MCC1,MCC2) | |
+------------------+---------------------+
Table 3: Example Policy MCC Attribute Usage
表3：ポリシーの例MCC属性の使用法
The SynchronizationID MCC attribute indicates how the individual Captures in multiple MCC Captures are synchronized. To indicate that the Capture Encodings associated with MCCs contain Captures from the same source at the same time, a Provider should set the same SynchronizationID on each of the concerned MCCs. It is the Provider that determines what the source for the Captures is, so a Provider can choose how to group together Single Media Captures into a combined "source" for the purpose of switching them together to keep them synchronized according to the SynchronizationID attribute. For example, when the Provider is in an MCU, it may determine that each separate CLUE Endpoint is a remote source of Media. The SynchronizationID may be used across Media types, i.e., to synchronize audio- and video-related MCCs.
SynchronizationID MCC属性は、複数のMCCキャプチャ内の個々のキャプチャが同期されているかを示します。MCCSに関連付けられているキャプチャエンコーディングに同じソースからのキャプチャが同時にキャプチャを含むことを示すために、プロバイダは関係した各MCCS上で同じSynchronizationIDを設定する必要があります。キャプチャの送信元が何であるかを決定するプロバイダであるため、プロバイダは、SynchronizationID属性に従ってそれらを同期させ続けるために、それらを一緒に切り替えることを目的として、単一のメディアキャプチャを組み合わせた "ソース"にまとめられた「ソース」にまとめる方法を選択できます。たとえば、プロバイダがMCU内にある場合、各個別のCLUEエンドポイントがメディアのリモートソースであると判断することができます。同期IDは、メディアタイプ、すなわちオーディオおよびビデオ関連のMCCを同期させるために、メディアタイプ間で使用され得る。
Without this attribute it is assumed that multiple MCCs may provide content from different sources at any particular point in time.
この属性がないと、複数のMCCが特定の時点で異なるソースからコンテンツを提供できると想定されています。
For example:
例えば：
+=======================+=====================+
| Capture Scene #1 | |
+=======================+=====================+
| VC1 | Description=Left |
+-----------------------+---------------------+
| VC2 | Description=Center |
+-----------------------+---------------------+
| VC3 | Description=Right |
+-----------------------+---------------------+
| AC1 | Description=Room |
+-----------------------+---------------------+
| CSV(VC1,VC2,VC3) | |
+-----------------------+---------------------+
| CSV(AC1) | |
+=======================+=====================+
| Capture Scene #2 | |
+=======================+=====================+
| VC4 | Description=Left |
+-----------------------+---------------------+
| VC5 | Description=Center |
+-----------------------+---------------------+
| VC6 | Description=Right |
+-----------------------+---------------------+
| AC2 | Description=Room |
+-----------------------+---------------------+
| CSV(VC4,VC5,VC6) | |
+-----------------------+---------------------+
| CSV(AC2) | |
+=======================+=====================+
| Capture Scene #3 | |
+=======================+=====================+
| VC7 | |
+-----------------------+---------------------+
| AC3 | |
+=======================+=====================+
| Capture Scene #4 | |
+=======================+=====================+
| VC8 | |
+-----------------------+---------------------+
| AC4 | |
+=======================+=====================+
| Capture Scene #5 | |
+=======================+=====================+
| MCC1(VC1,VC4,VC7) | SynchronizationID=1 |
| | MaxCaptures=1 |
+-----------------------+---------------------+
| MCC2(VC2,VC5,VC8) | SynchronizationID=1 |
| | MaxCaptures=1 |
+-----------------------+---------------------+
| MCC3(VC3,VC6) | MaxCaptures=1 |
+-----------------------+---------------------+
| MCC4(AC1,AC2,AC3,AC4) | SynchronizationID=1 |
| | MaxCaptures=1 |
+-----------------------+---------------------+
| CSV(MCC1,MCC2,MCC3) | |
+-----------------------+---------------------+
| CSV(MCC4) | |
+-----------------------+---------------------+
Table 4: Example SynchronizationID MCC Attribute Usage
表4：SynchronizationID MCC属性の使用例の例
The above Advertisement would indicate that MCC1, MCC2, MCC3, and MCC4 make up a Capture Scene. There would be four Capture Encodings (one for each MCC). Because MCC1 and MCC2 have the same SynchronizationID, each Encoding from MCC1 and MCC2, respectively, would together have content from only Capture Scene 1 or only Capture Scene 2 or the combination of VC7 and VC8 at a particular point in time. In this case, the Provider has decided the sources to be synchronized are Scene #1, Scene #2, and Scene #3 and #4 together. The Encoding from MCC3 would not be synchronized with MCC1 or MCC2. As MCC4 also has the same SynchronizationID as MCC1 and MCC2, the content of the audio Encoding will be synchronized with the video content.
上記の広告は、MCC1、MCC2、MCC3、およびMCC4がキャプチャシーンを構成することを示している。4つのキャプチャエンコーディング（各MCC用）があります。MCC1とMCC2は同じSynchronizationIDを持ち、それぞれMCC1とMCC2からのエンコーディングがまとめられます。この場合、プロバイダは、同期されるべきソースをシーン＃1、シーン＃2、およびシーン＃3および＃4であると判断した。MCC3からのエンコーディングはMCC1またはMCC2と同期されません。MCC4もMCC1とMCC2と同じSynchronizationIDを持ち、オーディオエンコーディングの内容はビデオコンテンツと同期されます。
The Allow Subset Choice MCC attribute is a boolean value, indicating whether or not the Provider allows the Consumer to choose a specific subset of the Captures referenced by the MCC. If this attribute is true, and the MCC references other Captures, then the Consumer MAY select (in a Configure message) a specific subset of those Captures to be included in the MCC, and the Provider MUST then include only that subset. If this attribute is false, or the MCC does not reference other Captures, then the Consumer MUST NOT select a subset.
Allow Subset Choice MCC属性はブール値で、プロバイダがコンシューマがMCCによって参照されるキャプチャの特定のサブセットを選択できるかどうかを示します。この属性が真の場合、およびMCCが他のキャプチャを参照している場合、コンシューマはMCCに含まれるキャプチャの特定のサブセットを（構成メッセージ内で）選択することができ、プロバイダはそのサブセットのみを含める必要があります。この属性がfalseの場合、またはMCCが他のキャプチャを参照していない場合、コンシューマはサブセットを選択してはいけません。
In order for a Provider's individual Captures to be used effectively by a Consumer, the Provider organizes the Captures into one or more Capture Scenes, with the structure and contents of these Capture Scenes being sent from the Provider to the Consumer in the Advertisement.
プロバイダの個々のキャプチャを消費者によって効果的に使用するために、プロバイダは、これらのキャプチャシーンの構造と内容が広告内でプロバイダから消費者に送信されている、1つ以上のキャプチャシーンにキャプチャを編成します。
A Capture Scene is a structure representing a spatial region containing one or more Capture Devices, each capturing Media representing a portion of the region. A Capture Scene includes one or more Capture Scene Views (CSVs), with each CSV including one or more Media Captures of the same Media type. There can also be Media Captures that are not included in a CSV. A Capture Scene represents, for example, the video image of a group of people seated next to each other, along with the sound of their voices, which could be represented by some number of VCs and ACs in the CSVs. An MCU can also describe in Capture Scenes what it constructs from Media Streams it receives.
キャプチャシーンは、1つまたは複数のキャプチャデバイスを含む空間領域を表す構造であり、各キャプチャメディアはその一部を表す。キャプチャシーンは、1つ以上のキャプチャシーンビュー（CSV）を含み、各CSVは同じメディアタイプの1つまたは複数のメディアキャプチャを含む。CSVに含まれていないメディアキャプチャもあります。捕捉シーンは、例えば、互いの隣に隣接して座っている人々のグループのビデオ画像を表す。MCUは、それが受信したメディアストリームから構築するものをキャプチャーシーンに記述することもできます。
A Provider MAY advertise one or more Capture Scenes. What constitutes an entire Capture Scene is up to the Provider. A simple Provider might typically use one Capture Scene for participant Media (live video from the room cameras) and another Capture Scene for a computer-generated presentation. In more-complex systems, the use of additional Capture Scenes is also sensible. For example, a classroom may advertise two Capture Scenes involving live video: one including only the camera capturing the instructor (and associated audio) the other including camera(s) capturing students (and associated audio).
プロバイダは、1つ以上のキャプチャーシーンをアドバタイズすることができる。キャプチャシーン全体を構成するものはプロバイダー次第です。単純なプロバイダは、通常、参加者メディア（部屋カメラからのライブビデオ）およびコンピュータ生成されたプレゼンテーションのための別のキャプチャシーンの1つのキャプチャシーンを使用することができる。より複雑なシステムでは、追加のキャプチャーシーンの使用も賢明です。例えば、教室はライブビデオを含む2つのキャプチャシーンを宣伝することができる：カメラのみを含むカメラのみを含む（そしてそれに関連するオーディオ）、学生を捕獲する（そしてそれに関連するオーディオ）。
A Capture Scene MAY (and typically will) include more than one type of Media. For example, a Capture Scene can include several CSVs for Video Captures and several CSVs for Audio Captures. A particular Capture MAY be included in more than one CSV.
キャプチャシーンは（そして通常は典型的には意志）、複数の種類のメディアを含むことができる。例えば、キャプチャシーンは、ビデオキャプチャ用のいくつかのCSV、およびオーディオキャプチャのためのいくつかのCSVを含むことができる。特定の捕獲は、複数のCSVに含まれてもよい。
A Provider MAY express Spatial Relationships between Captures that are included in the same Capture Scene. However, there is no Spatial Relationship between Media Captures from different Capture Scenes. In other words, Capture Scenes each use their own spatial measurement system as outlined in Section 6.
プロバイダは、同じキャプチャシーンに含まれているキャプチャ間の空間的関係を表現することができます。ただし、さまざまな捕獲シーンからのメディアキャプチャ間に空間的な関係はありません。言い換えれば、キャプチャーシーンはそれぞれ、セクション6に概説されているようにそれら自身の空間測定システムを使用します。
A Provider arranges Captures in a Capture Scene to help the Consumer choose which Captures it wants to Render. The CSVs in a Capture Scene are different alternatives the Provider is suggesting for representing the Capture Scene. Each CSV is given an advertisement-unique identity. The order of CSVs within a Capture Scene has no significance. The Media Consumer can choose to receive all Media Captures from one CSV for each Media type (e.g., audio and video), or it can pick and choose Media Captures regardless of how the Provider arranges them in CSVs. Different CSVs of the same Media type are not necessarily mutually exclusive alternatives. Also note that the presence of multiple CSVs (with potentially multiple Encoding options in each view) in a given Capture Scene does not necessarily imply that a Provider is able to serve all the associated Media simultaneously (although the construction of such an over-rich Capture Scene is probably not sensible in many cases). What a Provider can send simultaneously is determined through the Simultaneous Transmission Set mechanism, described in Section 8.
プロバイダはキャプチャシーン内のキャプチャをアレンジして、消費者がレンダリングしたいキャプチャを選択するのを助ける。キャプチャシーン内のCSVは異なる選択肢であり、プロバイダはキャプチャシーンを表すことを提案している。各CSVには広告独自のIDが与えられます。キャプチャシーン内のCSVの順序は重要ではありません。メディアコンシューマは、各メディアタイプ（例えば、オーディオおよびビデオ）について、1つのCSVからすべてのメディアキャプチャを受信することを選択できます。または、プロバイダがどのようにCSVで配置するかに関係なく、メディアキャプチャを選択して選択することもできます。同じメディアタイプの異なるCSVは必ずしも相互に排他的な代替手段ではありません。また、特定のキャプチャシーン内の複数のCSV（各ビューで潜在的に複数の符号化オプションを有する）の存在は必ずしもプロバイダが同時にすべての関連メディアにサービスを提供することができることを必ずしも意味するものではない（そのような過剰なキャプチャの構築シーンはおそらく多くの場合賢明ではありません）。プロバイダが同時に送信できるのは、セクション8で説明されている同時送信セット機構を通して決定される。
Captures within the same CSV MUST be of the same Media type -- it is not possible to mix audio and Video Captures in the same CSV, for instance. The Provider MUST be capable of encoding and sending all Captures (that have an Encoding Group) in a single CSV simultaneously. The order of Captures within a CSV has no significance. A Consumer can decide to receive all the Captures in a single CSV, but a Consumer could also decide to receive just a subset of those Captures. A Consumer can also decide to receive Captures from different CSVs, all subject to the constraints set by Simultaneous Transmission Sets, as discussed in Section 8.
同じCSV内のキャプチャは同じメディアタイプでなければなりません。たとえば、同じCSVにオーディオとビデオキャプチャを混在させることはできません。プロバイダは、単一のCSVに同時に1つのCSVにすべてのキャプチャをエンコードして送信することができなければなりません。CSV内のキャプチャの順序は意味はありません。消費者は、単一のCSVですべてのキャプチャを受信することを決定できますが、消費者はそれらのキャプチャのサブセットだけを受信することも決定できます。消費者はまた、セクション8で説明したように、異なるCSVからのキャプチャを受信することを決定することができる。
When a Provider advertises a Capture Scene with multiple CSVs, it is essentially signaling that there are multiple representations of the same Capture Scene available. In some cases, these multiple views would be used simultaneously (for instance, a "video view" and an "audio view"). In some cases, the views would conceptually be alternatives (for instance, a view consisting of three Video Captures covering the whole room versus a view consisting of just a single Video Capture covering only the center of a room). In this latter example, one sensible choice for a Consumer would be to indicate (through its Configure and possibly through an additional offer/ answer exchange) the Captures of that CSV that most closely matched the Consumer's number of display devices or screen layout.
プロバイダが複数のCSVでキャプチャシーンをアドバタイズすると、利用可能な同じキャプチャシーンの複数の表現があることが本質的にシグナリングされています。場合によっては、これらの複数のビューは同時に使用されます（たとえば、「ビデオビュー」と「オーディオビュー」）。場合によっては、ビューは概念的に選択されます（たとえば、部屋全体をカバーする3つのビデオキャプチャからなるビューは、部屋の中心だけをカバーする単一のビデオキャプチャ）。後者の例では、消費者のための1つの賢明な選択は、消費者の表示装置またはスクリーンレイアウトの数と最も密接に一致するそのCSVのキャプチャを示すことを（その構成を通して、追加のオファー/アンサー交換を通して）ことを示すことです。
The following is an example of four potential CSVs for an Endpoint-style Provider:
以下は、エンドポイントスタイルプロバイダ用の4つの潜在的なCSVの例です。
1. (VC0, VC1, VC2) - left, center, and right camera Video Captures
1. （VC0、VC1、VC2） - 左、センター、右のカメラのビデオキャプチャ
2. (MCC3) - Video Capture associated with loudest room segment
2. （MCC3） - 最も大きい部屋セグメントに関連するビデオキャプチャ
3. (VC4) - Video Capture zoomed out view of all people in the room
3. （VC4） - ビデオキャプチャズームアウトルームのすべての人のズボンアウト
4. (AC0) - main audio
4. （AC0） - メインオーディオ
The first view in this Capture Scene example is a list of Video Captures that have a Spatial Relationship to each other. Determination of the order of these Captures (VC0, VC1, and VC2) for rendering purposes is accomplished through use of their Area of Capture attributes. The second view (MCC3) and the third view (VC4) are alternative representations of the same room's video, which might be better suited to some Consumers' rendering capabilities. The inclusion of the Audio Capture in the same Capture Scene indicates that AC0 is associated with all of those Video Captures, meaning it comes from the same spatial region. Therefore, if audio were to be Rendered at all, this audio would be the correct choice, irrespective of which Video Captures were chosen.
このキャプチャシーンの例の最初のビューは、互いに空間的関係を持つビデオキャプチャのリストです。レンダリング目的のためのこれらのキャプチャ（VC0、VC1、およびVC2）の順序の決定は、それらのキャプチャ属性の領域を使用することによって達成される。第2のビュー（MCC3）および第3のビュー（VC4）は、同じ部屋のビデオの代替表現であり、それはいくつかの消費者のレンダリング機能に適している可能性がある。同じキャプチャシーンでオーディオキャプチャを含めると、AC0がそれらのビデオキャプチャのすべてに関連付けられていることを示しています。つまり、同じ空間領域からのものです。したがって、オーディオがまったくレンダリングされた場合、このオーディオはどのビデオキャプチャが選択されたかにかかわらず、正しい選択です。
Capture Scene attributes can be applied to Capture Scenes as well as to individual Media Captures. Attributes specified at this level apply to all constituent Captures. Capture Scene attributes include the following:
キャプチャシーン属性は、シーンと個々のメディアキャプチャと同様にキャプチャーシーンに適用できます。このレベルで指定された属性は、すべての構成要素キャプチャに適用されます。キャプチャシーン属性には、次のものがあります。
* Human-readable description of the Capture Scene, which could be in multiple languages;
* キャプチャシーンの人間が読める説明、これは複数の言語である可能性があります。
* xCard Scene information
* Xcardシーン情報
* Scale information ("Millimeters", "Unknown Scale", "No Scale"), as described in Section 6.
* セクション6で説明したように、スケール情報（「ミリメートル」、「不明スケール」、「ノースケール」）。
The Scene Information attribute provides information regarding the Capture Scene rather than individual participants. The Provider may gather the information automatically or manually from a variety of sources. The Scene Information attribute allows a Provider to indicate information such as organizational or geographic information allowing a Consumer to determine which Capture Scenes are of interest in order to then perform Capture selection. It also allows a Consumer to Render information regarding the Scene or to use it for further processing.
シーン情報属性は、個々の参加者ではなくキャプチャシーンに関する情報を提供します。プロバイダは、さまざまなソースから自動的にまたは手動で情報を収集することができます。シーン情報属性により、プロバイダは、担当者がどのキャプチャシーンが興味のあるキャプチャシーンが興味があるかを判断することを可能にするようなプロバイダを提供することを可能にする。また、消費者がシーンに関する情報をレンダリングしたり、さらなる処理のために使用することもできます。
As per Section 7.1.1.10, the xCard format is used to convey this information and the Provider may supply a minimal set of information or a larger set of information.
セクション7.1.1.10によると、Xcardフォーマットはこの情報を伝えるために使用され、プロバイダは最小限の情報またはより大きな情報セットを供給することができる。
In order to keep CLUE messages compact the Provider SHOULD use a URI to point to any LOGO, PHOTO, or SOUND contained in the xCard rather than transmitting the LOGO, PHOTO, or SOUND data in a CLUE message.
Clue Messagesをコンパクトに保つために、プロバイダーは、Clueメッセージ内のロゴ、写真、またはサウンドデータを送信するのではなく、XCardに含まれているロゴ、写真、またはサウンドを指すようにURIを使用する必要があります。
A Capture Scene can include one or more CSVs in addition to the Capture-Scene-wide attributes described above. CSV attributes apply to the CSV as a whole, i.e., to all Captures that are part of the CSV.
キャプチャシーンは、上述のキャプチャシーン全体の属性に加えて1つまたは複数のCSVを含むことができる。CSV属性は、CSV全体、すなわち、CSVの一部であるすべてのキャプチャに適用されます。
CSV attributes include the following:
CSV属性には次のものがあります。
* A human-readable description (which could be in multiple languages) of the CSV.
* CSVの人間が読める記述（複数の言語である可能性があります）。
An Advertisement can include an optional Global View list. Each item in this list is a Global View. The Provider can include multiple Global Views, to allow a Consumer to choose sets of Captures appropriate to its capabilities or application. The choice of how to make these suggestions in the Global View list for what represents all the Scenes for which the Provider can send Media is up to the Provider. This is very similar to how each CSV represents a particular Scene.
広告はオプションのグローバルビューリストを含めることができます。このリストの各項目はグローバルビューです。プロバイダは、コンシューマがその機能やアプリケーションに適したキャプチャのセットを選択できるようにするために、複数のグローバルビューを含めることができます。プロバイダがメディアを送信できるすべてのシーンを表すもののために、グローバルビューリストにこれらの提案を作成する方法の選択は、メディアをプロバイダに送信できます。これは、各CSVが特定のシーンをどのように表すかと非常によく似ています。
As an example, suppose an Advertisement has three Scenes, and each Scene has three CSVs, ranging from one to three Video Captures in each CSV. The Provider is advertising a total of nine Video Captures across three Scenes. The Provider can use the Global View list to suggest alternatives for Consumers that can't receive all nine Video Captures as separate Media Streams. For accommodating a Consumer that wants to receive three Video Captures, a Provider might suggest a Global View containing just a single CSV with three Captures and nothing from the other two Scenes. Or a Provider might suggest a Global View containing three different CSVs, one from each Scene, with a single Video Capture in each.
一例として、広告に3つのシーンがあるとし、各シーンには3つのCSVがあり、各CSVの1から3のビデオキャプチャの範囲です。プロバイダは、3つのシーンにわたって合計9つのビデオキャプチャを広告しています。プロバイダは、すべての9つのビデオキャプチャを個別のメディアストリームとして受信できない消費者向けの代替案を提案するために、グローバルビューリストを使用できます。3つのビデオキャプチャを受け取りたい消費者を収容するために、プロバイダは、3つのキャプチャを持つ単一のCSVを含むグローバルビューを提案し、他の2つのシーンから何も示されていません。あるいは、プロバイダは、各シーンから1つずつ、それぞれのビデオキャプチャを備えた3つの異なるCSVを含むグローバルビューを提案するかもしれません。
Some additional rules:
いくつかの追加規則：
* The ordering of Global Views in the Global View list is insignificant.
* グローバルビューリスト内のグローバルビューの順序はわかりません。
* The ordering of CSVs within each Global View is insignificant.
* 各グローバルビュー内のCSVの順序は重要ではありません。
* A particular CSV may be used in multiple Global Views.
* 特定のCSVは、複数のグローバルビューで使用できます。
* The Provider must be capable of encoding and sending all Captures within the CSVs of a given Global View simultaneously.
* プロバイダは、特定のグローバルビューのCSV内のすべてのキャプチャを同時にエンコードして送信することができなければなりません。
The following figure shows an example of the structure of Global Views in a Global View List.
次の図は、グローバルビューリストのグローバルビューの構造の一例を示しています。
........................................................
. Advertisement .
. .
. +--------------+ +-------------------------+ .
. |Scene 1 | |Global View List | .
. | | | | .
. | CSV1 (v)<----------------- Global View (CSV 1) | .
. | <-------. | | .
. | | *--------- Global View (CSV 1,5) | .
. | CSV2 (v) | | | | .
. | | | | | .
. | CSV3 (v)<---------*------- Global View (CSV 3,5) | .
. | | | | | | .
. | CSV4 (a)<----------------- Global View (CSV 4) | .
. | <-----------. | | .
. +--------------+ | | *----- Global View (CSV 4,6) | .
. | | | | | .
. +--------------+ | | | +-------------------------+ .
. |Scene 2 | | | | .
. | | | | | .
. | CSV5 (v)<-------' | | .
. | <---------' | .
. | | | (v) = video .
. | CSV6 (a)<-----------' (a) = audio .
. | | .
. +--------------+ .
`......................................................'
Figure 3: Global View List Structure
図3：グローバルビューリストの構造
In many practical cases, a Provider has constraints or limitations on its ability to send Captures simultaneously. One type of limitation is caused by the physical limitations of capture mechanisms; these constraints are represented by a Simultaneous Transmission Set. The second type of limitation reflects the encoding resources available, such as bandwidth or video encoding throughput (macroblocks/second). This type of constraint is captured by Individual Encodings and Encoding Groups, discussed below.
多くの実用的な場合には、プロバイダは同時にキャプチャを送信する能力に制約または制限を持っています。1つのタイプの制限は、捕捉機構の物理的な制限によって引き起こされます。これらの制約は同時送信セットによって表されます。第2のタイプの制限は、帯域幅またはビデオ符号化スループット（マクロブロック/秒）など、利用可能な符号化リソースを反映している。この種の制約は、後述する個々のエンコーディングおよび符号化グループによってキャプチャされます。
Some Endpoints or MCUs can send multiple Captures simultaneously; however, sometimes there are constraints that limit which Captures can be sent simultaneously with other Captures. A device may not be able to be used in different ways at the same time. Provider Advertisements are made so that the Consumer can choose one of several possible mutually exclusive usages of the device. This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular Media type (e.g., audio, video, or text) that can be sent at the same time. There are different Simultaneous Transmission Sets for each Media type in the Advertisement. This is easier to show in an example.
いくつかのエンドポイントまたはMCUは複数のキャプチャを同時に送信できます。しかし、どのキャプチャを他のキャプチャと同時に送信できるかを制限する制約がある場合があります。装置は同時にさまざまな方法で使用できない場合があります。プロバイダ広告は、消費者がデバイスのいくつかの可能な排他的な使用法のうちの1つを選択できるように行われます。このタイプの制約は、同時に送信できる特定のメディアタイプ（例えば、オーディオ、ビデオ、テキスト）のすべてのキャプチャをリストします。広告内の各メディアタイプに対して異なる同時送信セットが異なります。例では表示が簡単です。
Consider the example of a room system where there are three cameras, each of which can send a separate Capture covering two people each: VC0, VC1, and VC2. The middle camera can also zoom out (using an optical zoom lens) and show all six people, VC3. But the middle camera cannot be used in both modes at the same time; it has to either show the space where two participants sit or the whole six seats, but not both at the same time. As a result, VC1 and VC3 cannot be sent simultaneously.
それぞれが3つのカメラがある部屋システムの例を検討してください。ミドルカメラはズームアウト（光学ズームレンズを使用）、6人すべてのVC3を表示することもできます。しかし、ミドルカメラは両方のモードで同時に使用することはできません。2人の参加者が座るスペースを見せていて、6席全体が同時に表示されます。その結果、VC1とVC3を同時に送信できません。
Simultaneous Transmission Sets are expressed as sets of the Media Captures that the Provider could transmit at the same time (though, in some cases, it is not intuitive to do so). If a Multiple Content Capture is included in a Simultaneous Transmission Set, it indicates that the Capture Encoding associated with it could be transmitted as the same time as the other Captures within the Simultaneous Transmission Set. It does not imply that the Single Media Captures contained in the Multiple Content Capture could all be transmitted at the same time.
同時送信セットは、プロバイダが同時に送信できるメディアキャプチャのセットとして表現されます（ただし、場合によっては直感的ではない）。複数のコンテンツキャプチャが同時送信セットに含まれている場合、それは同時送信セット内の他のキャプチャと同じ時間としてそれに関連するキャプチャエンコーディングが送信され得ることを示す。複数のコンテンツキャプチャに含まれている単一のメディアキャプチャがすべて同時に送信されることができることを意味しません。
In this example, the two Simultaneous Transmission Sets are shown in Table 5. If a Provider advertises one or more mutually exclusive Simultaneous Transmission Sets, then, for each Media type, the Consumer MUST ensure that it chooses Media Captures that lie wholly within one of those Simultaneous Transmission Sets.
この例では、2つの同時伝送セットが表5に示されています。プロバイダが1つまたは複数の相互に排他的な同時伝送セットをアドバタイズする場合、各メディアタイプについて、消費者はそれが一方の1つの中にあるメディアキャプチャを選択する必要があります。それらの同時伝送セット。
+===================+
| Simultaneous Sets |
+===================+
| {VC0, VC1, VC2} |
+-------------------+
| {VC0, VC3, VC2} |
+-------------------+
Table 5: Two Simultaneous Transmission Sets
表5：2つの同時伝送セット
A Provider OPTIONALLY can include the Simultaneous Transmission Sets in its Advertisement. These constraints apply across all the Capture Scenes in the Advertisement. It is a syntax-conformance requirement that the Simultaneous Transmission Sets MUST allow all the Media Captures in any particular CSV to be used simultaneously. Similarly, the Simultaneous Transmission Sets MUST reflect the simultaneity expressed by any Global View.
プロバイダは、任意選択でその広告における同時送信セットを含むことができる。これらの制約は、広告内のすべてのキャプチャーシーンにわたって適用されます。同時送信セットが特定のCSVのすべてのメディアキャプチャを同時に使用することを許可することは、同時伝送要件です。同様に、同時伝送セットは、任意のグローバルビューで表される同時性を反映しなければなりません。
For shorthand convenience, a Provider MAY describe a Simultaneous Transmission Set in terms of CSVs and Capture Scenes. If a CSV is included in a Simultaneous Transmission Set, then all Media Captures in the CSV are included in the Simultaneous Transmission Set. If a Capture Scene is included in a Simultaneous Transmission Set, then all its CSVs (of the corresponding Media type) are included in the Simultaneous Transmission Set. The end result reduces to a set of Media Captures, of a particular Media type, in either case.
省略される利便性のために、プロバイダはCSVとキャプチャーシーンに関して設定された同時送信セットを記述することができる。CSVが同時送信セットに含まれている場合、CSV内のすべてのメディアキャプチャは同時送信セットに含まれています。キャプチャシーンが同時送信セットに含まれている場合、そのすべてのCSV（対応するメディアタイプの）は同時送信セットに含まれています。どちらの場合でも、最終結果は特定のメディアタイプの一連のメディアキャプチャに減少します。
If an Advertisement does not include Simultaneous Transmission Sets, then the Provider MUST be able to simultaneously provide all the Captures from any one CSV of each Media type from each Capture Scene. Likewise, if there are no Simultaneous Transmission Sets and there is a Global View list, then the Provider MUST be able to simultaneously provide all the Captures from any particular Global View (of each Media type) from the Global View list.
広告に同時送信セットが含まれていない場合、プロバイダは各メディアタイプの任意の1つのCSVからのすべてのキャプチャを各キャプチャシーンから同時に提供できなければなりません。同様に、同時送信セットがない場合、グローバルビューリストがある場合、プロバイダは（各メディアタイプの）グローバルビューリストから（各メディアタイプの）すべてのキャプチャを同時に提供できなければなりません。
If an Advertisement includes multiple CSVs in a Capture Scene, then the Consumer MAY choose one CSV for each Media type, or it MAY choose individual Captures based on the Simultaneous Transmission Sets.
広告がキャプチャシーン内に複数のCSVを含む場合、消費者は各メディアタイプに対して1つのCSVを選択することができ、あるいは同時送信セットに基づいて個々のキャプチャを選択することができる。
Individual Encodings and Encoding Groups are CLUE's mechanisms allowing a Provider to signal its limitations for sending Captures, or combinations of Captures, to a Consumer. Consumers can map the Captures they want to receive onto the Encodings, with the Encoding parameters they want. As for the relationship between the CLUE-specified mechanisms based on Encodings and the SIP offer/answer exchange, please refer to Section 5.
個々のエンコーディングとエンコーディンググループは、CLUEのメカニズムで、プロバイダーがキャプチャーの送信、またはキャプチャの組み合わせを消費者に知らせることを可能にします。消費者は、符号化パラメータを求めて、受信したいキャプチャをエンコーディングにマッピングできます。符号化に基づく手がかり機構とSIPオファー/アンサー交換との関係については、セクション5を参照してください。
An Individual Encoding represents a way to encode a Media Capture as a Capture Encoding, to be sent as an encoded Media Stream from the Provider to the Consumer. An Individual Encoding has a set of parameters characterizing how the Media is encoded.
個々のエンコーディングは、メディアキャプチャをキャプチャエンコーディングとしてエンコードする方法を表し、プロバイダからコンシューマへのエンコードされたメディアストリームとして送信される方法を表します。個々のエンコーディングは、メディアがどのようにエンコードされるかを特徴付ける一連のパラメータを有する。
Different Media types have different parameters, and different encoding algorithms may have different parameters. An Individual Encoding can be assigned to at most one Capture Encoding at any given time.
異なるメディアタイプは異なるパラメータを有し、異なる符号化アルゴリズムが異なるパラメータを有することがある。個々のエンコーディングは、常に1つのキャプチャエンコーディングに割り当てることができます。
Individual Encoding parameters are represented in SDP [RFC4566], not in CLUE messages. For example, for a video Encoding using H.26x compression technologies, this can include parameters such as follows:
個々のエンコーディングパラメータは、CLUEメッセージではなく、SDP [RFC4566]に表されます。たとえば、H.26x圧縮テクノロジを使用したビデオエンコーディングの場合、これには次のようなパラメータを含めることができます。
* Maximum bandwidth; * Maximum picture size in pixels; * Maximum number of pixels to be processed per second;
* 最大帯域幅*ピクセル単位の最大画像サイズ。* 1秒間に処理される最大画素数。
The bandwidth parameter is the only one that specifically relates to a CLUE Advertisement, as it can be further constrained by the maximum group bandwidth in an Encoding Group.
帯域幅パラメータは、符号化グループ内の最大群帯域幅によってさらに制約されることができるように、特に手がかり広告に関連する唯一のものである。
An Encoding Group includes a set of one or more Individual Encodings, and parameters that apply to the group as a whole. By grouping multiple Individual Encodings together, an Encoding Group describes additional constraints on bandwidth for the group. A single Encoding Group MAY refer to Encodings for different Media types.
符号化グループは、一組の個々のエンコーディングのセット、およびそのグループ全体に適用されるパラメータを含む。複数の個々のエンコーディングをまとめてグループ化することによって、符号化グループは、グループの帯域幅に対する追加の制約を記述します。単一のエンコーディンググループは、さまざまなメディアタイプのエンコーディングを指すことがあります。
The Encoding Group data structure contains:
エンコーディンググループデータ構造には、次のものがあります。
* Maximum bitrate for all Encodings in the group combined;
* グループ内のすべてのエンコーディングの最大ビットレート。
* A list of identifiers for the Individual Encodings belonging to the group.
* グループに属する個々のエンコーディングの識別子のリスト。
When the Individual Encodings in a group are instantiated into Capture Encodings, each Capture Encoding has a bitrate that MUST be less than or equal to the max bitrate for the particular Individual Encoding. The "maximum bitrate for all Encodings in the group" parameter gives the additional restriction that the sum of all the individual Capture Encoding bitrates MUST be less than or equal to this group value.
グループ内の個々のエンコーディングがキャプチャエンコーディングにインスタンス化されると、各キャプチャエンコーディングはビットレートを持ち、特定の個々のエンコーディングのためのMAX BITERATEに必要です。「グループ内のすべてのエンコーディングの最大ビットレート」パラメータは、すべての個々のキャプチャエンコーディングビットレートの合計がこのグループ値以下でなければならないという追加の制限を与えます。
The following diagram illustrates one example of the structure of a Media Provider's Encoding Groups and their contents.
次の図は、メディアプロバイダの符号化グループとその内容の構造の一例を示しています。
,-------------------------------------------------.
| Media Provider |
| |
| ,--------------------------------------. |
| | ,--------------------------------------. |
| | | ,--------------------------------------. |
| | | | Encoding Group | |
| | | | ,-----------. | |
| | | | | | ,---------. | |
| | | | | | | | ,---------.| |
| | | | | Encoding1 | |Encoding2| |Encoding3|| |
| `.| | | | | | `---------'| |
| `.| `-----------' `---------' | |
| `--------------------------------------' |
`-------------------------------------------------'
Figure 4: Encoding Group Structure
図4：符号化グループ構造
A Provider advertises one or more Encoding Groups. Each Encoding Group includes one or more Individual Encodings. Each Individual Encoding can represent a different way of encoding Media. For example, one Individual Encoding may be 1080p60 video, another could be 720p30, with a third being 352x288p30, all in, for example, H.264 format.
プロバイダは1つ以上のエンコーディンググループをアドバタイズします。各符号化グループは1つ以上の個々のエンコーディングを含む。各個々のエンコーディングは、メディアを符号化する異なる方法を表すことができる。例えば、1つの個々の符号化は1080p60ビデオであり得、他のものは720p30であり得、3つ目は352×288p30、例えばH.264フォーマットである。
While a typical three-codec/display system might have one Encoding Group per "codec box" (physical codec, connected to one camera and one screen), there are many possibilities for the number of Encoding Groups a Provider may be able to offer and for the Encoding values in each Encoding Group.
典型的な3コーデック/ディスプレイシステムは、「コーデックボックス」ごとに1つのエンコーディンググループを持つことがあります（物理コーデック、1つのカメラと1画面に接続されている）、プロバイダが提供できる符号化グループの数には多くの可能性があります。各エンコーディンググループ内の符号化値について。
There is no requirement for all Encodings within an Encoding Group to be instantiated at the same time.
符号化グループ内のすべてのエンコーディングを同時にインスタンス化する必要はありません。
Each Media Capture, including MCCs, MAY be associated with one Encoding Group. To be eligible for configuration, a Media Capture MUST be associated with one Encoding Group, which is used to instantiate that Capture into a Capture Encoding. When an MCC is configured, all the Media Captures referenced by the MCC will appear in the Capture Encoding according to the attributes of the chosen Encoding of the MCC. This allows an Advertiser to specify Encoding attributes associated with the Media Captures without the need to provide an individual Capture Encoding for each of the inputs.
MCCを含む各メディアキャプチャは、1つのエンコードグループに関連付けられてもよい。構成の対象になるには、メディアキャプチャを1つのエンコーディンググループに関連付ける必要があります。これは、そのキャプチャをキャプチャエンコーディングにインスタンス化するために使用されます。MCCが構成されている場合、MCCによって参照されるすべてのメディアキャプチャは、MCCの選択されたエンコーディングの属性に従ってキャプチャエンコーディングに表示されます。これにより、各入力に対して個々のキャプチャ符号化を提供する必要なしに、広告主がメディアキャプチャに関連付けられている符号化属性を指定することができる。
If an Encoding Group is assigned to a Media Capture referenced by the MCC, it indicates that this Capture may also have an individual Capture Encoding.
符号化グループがMCCによって参照されるメディアキャプチャに割り当てられる場合、このキャプチャも個々のキャプチャエンコーディングを有することがあることを示す。
For example:
例えば：
+==================+=================+
| Capture Scene #1 | |
+==================+=================+
| VC1 | EncodeGroupID=1 |
+------------------+-----------------+
| VC2 | |
+------------------+-----------------+
| MCC1(VC1,VC2) | EncodeGroupID=2 |
+------------------+-----------------+
| CSV(VC1) | |
+------------------+-----------------+
| CSV(MCC1) | |
+------------------+-----------------+
Table 6: Example Usage of Encoding with MCC and Source Captures
表6：MCCとソースキャプチャを使用したエンコーディングの使用例
This would indicate that VC1 may be sent as its own Capture Encoding from EncodeGroupID=1 or that it may be sent as part of a Capture Encoding from EncodeGroupID=2 along with VC2.
これは、VC1がEncodeGroupID = 1からのそれ自身のキャプチャエンコーディングとして送信されてもよく、またはそれがvc2と共にEncodeGroupID = 2からのキャプチャエンコーディングの一部として送信され得ることを示すであろう。
More than one Capture MAY use the same Encoding Group.
複数のキャプチャが同じ符号化グループを使用することができる。
The maximum number of Capture Encodings that can result from a particular Encoding Group constraint is equal to the number of Individual Encodings in the group. The actual number of Capture Encodings used at any time MAY be less than this maximum. Any of the Captures that use a particular Encoding Group can be encoded according to any of the Individual Encodings in the group.
特定のエンコーディンググループ制約から生じる可能性があるキャプチャエンコーディングの最大数は、グループ内の個々のエンコーディングの数と同じです。いつでも使用されるキャプチャエンコーディングの実際の数はこの最大値より小さくなる可能性があります。特定の符号化グループを使用するキャプチャのいずれかは、グループ内の個々のエンコーディングのいずれかに従って符号化することができる。
It is a protocol conformance requirement that the Encoding Groups MUST allow all the Captures in a particular CSV to be used simultaneously.
それは、符号化グループが特定のCSV内のすべてのキャプチャを同時に使用することを許可する必要があるプロトコル適合要件です。
After receiving the Provider's Advertisement message (which includes Media Captures and associated constraints), the Consumer composes its reply to the Provider in the form of a Configure message. The Consumer is free to use the information in the Advertisement as it chooses, but there are a few obviously sensible design choices, which are outlined below.
プロバイダの広告メッセージ（メディアキャプチャと関連の制約を含む）を受信した後、コンシューマは構成メッセージの形式でプロバイダへの返信を構成します。消費者はそれが選択するにつれて広告内の情報を自由に使用することができますが、明らかに賢明な設計の選択肢がいくつかあります。
If multiple Providers connect to the same Consumer (i.e., in an MCU-less multiparty call), it is the responsibility of the Consumer to compose Configures for each Provider that both fulfill each Provider's constraints as expressed in the Advertisement, as well as its own capabilities.
複数のプロバイダが同じコンシューマに接続されている場合（すなわち、MCUが小さいマルチパーティコールで）、それは広告で表現されているように各プロバイダの制約を満たすような各プロバイダの構成を構成することが消費者の責任である。機能
In an MCU-based multiparty call, the MCU can logically terminate the Advertisement/Configure negotiation in that it can hide the characteristics of the receiving Endpoint and rely on its own capabilities (transcoding/transrating/etc.) to create Media Streams that can be decoded at the Endpoint Consumers. The timing of an MCU's sending of Advertisements (for its outgoing ports) and Configures (for its incoming ports, in response to Advertisements received there) is up to the MCU and is implementation dependent.
MCUベースのマルチパーティ呼び出しでは、MCUは、受信エンドポイントの特性を非表示にし、それ自身の機能（トランスコーディング/トランスレーション/ etc）に依存しているという点で、広告/コンフィグレーションを論理的に終了させることができます（トランスコーディング/トランスレーション/ etc）。エンドポイント消費者で復号されました。MCUの広告の送信のタイミング（その発信ポートの場合）と設定（そこにある広告に対応して）がMCU次第で、実装に依存しています。
As a general outline, a Consumer can choose, based on the Advertisement it has received, which Captures it wishes to receive, and which Individual Encodings it wants the Provider to use to encode the Captures.
一般的な概要として、消費者はそれが受信したアドバタイズメントに基づいて選択することができます。
On receipt of an Advertisement with an MCC, the Consumer treats the MCC as per other non-MCC Captures with the following differences:
MCCを使用した広告を受け取ると、消費者は以下の違いを伴って他の非MCCキャプチャに従ってMCCを扱います。
* The Consumer would understand that the MCC is a Capture that includes the referenced individual Captures (or any Captures, if none are referenced) and that these individual Captures are delivered as part of the MCC's Capture Encoding.
* 消費者は、MCCが参照された個々のキャプチャ（または誰も参照されていない場合は任意のキャプチャ）を含み、これらの個々のキャプチャがMCCのキャプチャエンコーディングの一部として提供されるキャプチャであることを理解します。
* The Consumer may utilize any of the attributes associated with the referenced individual Captures and any Capture Scene attributes from where the individual Captures were defined to choose Captures and for Rendering decisions.
* 消費者は、参照されている個々のキャプチャに関連する属性のいずれかを利用し、個々のキャプチャがキャプチャを選択し、決定決定を選択するために定義されたキャプチャシーン属性を利用することができる。
* If the MCC attribute Allow Subset Choice is true, then the Consumer may or may not choose to receive all the indicated Captures. It can choose to receive a subset of Captures indicated by the MCC.
* MCC属性がサブセットの選択を許可する場合は、消費者は表示されているすべてのキャプチャを受信することを選択してもしなくてもよい。MCCが示すキャプチャのサブセットを受信することを選択できます。
For example, if the Consumer receives:
たとえば、消費者が受信した場合
MCC1(VC1,VC2,VC3){attributes}
A Consumer could choose all the Captures within an MCC; however, if the Consumer determines that it doesn't want VC3, it can return MCC1(VC1,VC2). If it wants all the individual Captures, then it returns only the MCC identity (i.e., MCC1). If the MCC in the Advertisement does not reference any individual Captures, or the Allow Subset Choice attribute is false, then the Consumer cannot choose what is included in the MCC: it is up to the Provider to decide.
消費者はMCC内のすべてのキャプチャを選択することができます。ただし、消費者がVC3を望まないと判断した場合は、MCC1（VC1、VC2）を返すことができます。それがすべての個々のキャプチャを望む場合、それはMCC ID（すなわち、MCC1）のみを返します。広告内のMCCが個々のキャプチャを参照していない場合、または[サブセット選択]属性が偽の場合、消費者はMCCに含まれているものを選択できません。決定するプロバイダー次第です。
A Configure Message includes a list of Capture Encodings. These are the Capture Encodings the Consumer wishes to receive from the Provider. Each Capture Encoding refers to one Media Capture and one Individual Encoding.
設定メッセージには、キャプチャエンコーディングのリストが含まれています。これらは消費者がプロバイダから受信したいキャプチャエンコーディングです。各キャプチャエンコーディングは、1つのメディアキャプチャと1つの個々のエンコーディングを指します。
For each Capture the Consumer wants to receive, it configures one of the Encodings in that Capture's Encoding Group. The Consumer does this by telling the Provider, in its Configure Message, which Encoding to use for each chosen Capture. Upon receipt of this Configure from the Consumer, common knowledge is established between Provider and Consumer regarding sensible choices for the Media Streams. The setup of the actual Media channels, at least in the simplest case, is left to a following offer/answer exchange. Optimized implementations may speed up the reaction to the offer/ answer exchange by reserving the resources at the time of finalization of the CLUE handshake.
消費者が受信したいキャプチャーをキャプチャしたい場合は、そのキャプチャのエンコーディング・グループ内の1つのエンコーディングを設定します。消費者はこれをプロバイダに指示することによってこれを行い、選択した各キャプチャに使用するエンコーディングをエンコードします。消費者からこの構成を受信すると、メディアストリームの賢明な選択に関してプロバイダと消費者の間で一般的な知識が確立されます。実際のメディアチャンネルのセットアップは、少なくとも最も単純な場合でも、次のオファー/回答交換に残されています。最適化された実装は、手がかりハンドシェイクのファイナライズ時にリソースを予約することによって、オファー/アンケート交換に対する反応をスピードアップすることができる。
CLUE Advertisements and Configure Messages don't necessarily require a new SDP offer/answer for every CLUE message exchange. But the resulting Encodings sent via RTP must conform to the most-recent SDP offer/answer result.
手がかり広告とメッセージの設定は必ずしもすべての手がかりメッセージ交換に対して新しいSDPオファー/回答を必要としません。しかし、RTPを介して送信された結果のエンコーディングは、最新のSDPオファー/アンサーグ結果に準拠している必要があります。
In order to meaningfully create and send an initial Configure, the Consumer needs to have received at least one Advertisement, and an SDP offer defining the Individual Encodings, from the Provider.
初期設定を有意に作成して送信するために、コンシューマは少なくとも1つの広告を受信し、プロバイダから個々のエンコーディングを定義するSDPオファーを受信する必要があります。
In addition, the Consumer can send a Configure at any time during the call. The Configure MUST be valid according to the most recently received Advertisement. The Consumer can send a Configure either in response to a new Advertisement from the Provider or on its own, for example, because of a local change in conditions (people leaving the room, connectivity changes, multipoint related considerations).
さらに、消費者は通話中いつでも設定を送信できます。設定は最近受信された広告に従って有効でなければなりません。コンシューマは、プロバイダからの新しいアドバタイズメントに応答して、プロバイダからの新しい広告に応答して、またはそれ自体で、例えば、地域の変更（部屋を離れる人、接続性の変更、マルチポイント関連の考慮事項）のいずれかを送信できます。
When choosing which Media Streams to receive from the Provider, and the encoding characteristics of those Media Streams, the Consumer advantageously takes several things into account: its local preference, simultaneity restrictions, and encoding limits.
プロバイダから受信するメディアストリーム、およびそれらのメディアストリームの符号化特性を選択するとき、消費者は有利にいくつかのことを考慮に入れることができる：その地域の好み、同時性制限、および符号化限界。
A variety of local factors influence the Consumer's choice of Media Streams to be received from the Provider:
さまざまなローカル要因が、プロバイダから受信するメディアストリームの消費者の選択に影響します。
* If the Consumer is an Endpoint, it is likely that it would choose, where possible, to receive Video and Audio Captures that match the number of display devices and audio system it has.
* 消費者がエンドポイントである場合、可能な限り、表示装置とオーディオシステムの数と一致するビデオとオーディオキャプチャを受信することができる可能性があります。
* If the Consumer is an MCU, it may choose to receive loudest speaker Streams (in order to perform its own Media composition) and avoid pre-composed Video Captures.
* 消費者がMCUである場合、それは（独自のメディア構成を実行するために）最も大きいスピーカーストリームを受信し、事前に構成されたビデオキャプチャを避けることを選択するかもしれません。
* User choice (for instance, selection of a new layout) may result in a different set of Captures, or different Encoding characteristics, being required by the Consumer.
* ユーザ選択（例えば、新しいレイアウトの選択）は、消費者によって必要とされている、一連のキャプチャ、または異なる符号化特性をもたらす可能性がある。
Often there are physical simultaneity constraints of the Provider that affect the Provider's ability to simultaneously send all of the Captures the Consumer would wish to receive. For instance, an MCU, when connected to a multi-camera room system, might prefer to receive both individual video Streams of the people present in the room and an overall view of the room from a single camera. Some Endpoint systems might be able to provide both of these sets of Streams simultaneously, whereas others might not (if the overall room view were produced by changing the optical zoom level on the center camera, for instance).
多くの場合、コンシューマが受信したいと思うすべてのキャプチャを同時に送信するプロバイダの能力に影響を与えるプロバイダの物理的な同時性制約があります。例えば、MCUは、マルチカメラルームシステムに接続されているときに、部屋に存在する人々の個々のビデオストリームと、単一のカメラから部屋の全体的な見方を受け取ることを好む。いくつかのエンドポイントシステムは、これらのストリームセットのセットを同時に提供できることがありますが、他のものは同時に使用できますが（例えば、中央カメラの光学ズームレベルを変更することによって全体的な室のビューが生成された場合）。
Each of the Provider's Encoding Groups has limits on bandwidth, and the constituent potential Encodings have limits on the bandwidth, computational complexity, video frame rate, and resolution that can be provided. When choosing the Captures to be received from a Provider, a Consumer device MUST ensure that the Encoding characteristics requested for each individual Capture fits within the capability of the Encoding it is being configured to use, as well as ensuring that the combined Encoding characteristics for Captures fit within the capabilities of their associated Encoding Groups. In some cases, this could cause an otherwise "preferred" choice of Capture Encodings to be passed over in favor of different Capture Encodings -- for instance, if a set of three Captures could only be provided at a low resolution then a three screen device could switch to favoring a single, higher quality, Capture Encoding.
プロバイダの符号化グループのそれぞれは帯域幅に制限があり、構成潜在的な符号化は帯域幅、計算量の複雑さ、ビデオフレームレート、および解像度に制限されている。プロバイダから受信するキャプチャを選択するとき、コンシューマデバイスは、それが使用するエンコーディングの機能内の各個々のキャプチャに対して要求された符号化特性が、キャプチャのための符号化特性を確実にすることを確実にする必要がある。関連するエンコーディンググループの機能内にフィットします。場合によっては、異なるキャプチャエンコーディングを支持すると、さまざまなキャプチャエンコーディングを支持するように渡すように捕捉エンコーディングの選択が渡される可能性があります。たとえば、3つのキャプチャのセットが低解像度でしか提供できない場合は、3つのスクリーンデバイスがあります。単一の、高品質の、キャプチャエンコーディングを支持するように切り替えることができます。
One important characteristics of the Framework is its extensibility. The standard for interoperability and handling multiple Streams must be future-proof. The framework itself is inherently extensible through expanding the data model types. For example:
フレームワークの1つの重要な特徴はその拡張性です。相互運用性と複数のストリームを処理するための標準は将来証明でなければなりません。フレームワーク自体は、データモデルタイプを拡張することによって本質的に拡張可能です。例えば：
* Adding more types of Media, such as telemetry, can done by defining additional types of Captures in addition to audio and video.
* テレメトリなどのメディアの種類の追加は、オーディオとビデオに加えて追加の種類のキャプチャを定義することによって行うことができます。
* Adding new functionalities, such as 3-D Video Captures, may require additional attributes describing the Captures.
* 3-Dビデオキャプチャなどの新しい機能を追加するには、キャプチャを記述する追加の属性が必要になる場合があります。
The infrastructure is designed to be extended rather than requiring new infrastructure elements. Extension comes through adding to defined types.
インフラストラクチャは、新しいインフラストラクチャ要素を必要とするのではなく拡張されるように設計されています。拡張子は定義された型に追加されます。
This section gives some examples, first from the point of view of the Provider, then the Consumer, then some multipoint scenarios.
このセクションでは、最初にプロバイダ、次に消費者、次にいくつかのマルチポイントシナリオからいくつかの例を示します。
This section shows some examples in more detail of how a Provider can use the framework to represent a typical case for telepresence rooms. First, an Endpoint is illustrated, then an MCU case is shown.
このセクションでは、プロバイダーがフレームワークを使用してTelePresence Roomsの典型的な場合を表す方法の詳細についていくつかの例を示します。まず、エンドポイントを説明し、次にMCUケースを示す。
Consider an Endpoint with the following description:
以下の説明でエンドポイントを検討してください。
Three cameras, three displays, and a six-person table
3つのカメラ、3つのディスプレイ、そして6人のテーブル
* Each camera can provide one Capture for each 1/3-section of the table.
* 各カメラは、テーブルの1/3セクションごとに1回のキャプチャを提供できます。
* A single Capture representing the active speaker can be provided (voice-activity-based camera selection to a given encoder input port implemented locally in the Endpoint).
* アクティブスピーカーを表す単一のキャプチャを提供することができます（エンドポイント内にローカルに実装されている特定のエンコーダ入力ポートへの音声アクティビティベースのカメラの選択）。
* A single Capture representing the active speaker with the other two Captures shown picture in picture (PiP) within the Stream can be provided (again, implemented inside the Endpoint).
* ストリーム内のピップ（PIP）内の図示されているピクチャ（PIP）のピクチャ（PIP）のピクチャのピクチャを含むアクティブスピーカーを表す単一のキャプチャを（再びエンドポイント内に実装されています）。
* A Capture showing a zoomed out view of all six seats in the room can be provided.
* 部屋の6席全てのズームアウトビューを示すキャプチャーを提供することができます。
The Video and Audio Captures for this Endpoint can be described as follows.
このエンドポイントのビデオおよびオーディオキャプチャは、次のように説明できます。
Video Captures:
ビデオキャプチャ：
VC0 (the left camera Stream), Encoding Group=EG0, view=table
vc0（左カメラストリーム）、encoding group = eg0、view = table
VC1 (the center camera Stream), Encoding Group=EG1, view=table
VC1（センターカメラストリーム）、encoding group = eg1、view = table
VC2 (the right camera Stream), Encoding Group=EG2, view=table
vc2（右カメラストリーム）、encoding group = EG2、View = table
MCC3 (the loudest panel Stream), Encoding Group=EG1, view=table,
MaxCaptures=1, policy=SoundLevel
MCC4 (the loudest panel Stream with PiPs), Encoding Group=EG1,
view=room, MaxCaptures=3, policy=SoundLevel
VC5 (the zoomed out view of all people in the room), Encoding Group=EG1, view=room
VC5（部屋のすべての人のズームアウトビュー）、engoding group = EG1、View = Room
VC6 (presentation Stream), Encoding Group=EG1, presentation
vc6（プレゼンテーション・ストリーム）、encoding group = EG1、プレゼンテーション
The following diagram is a top view of the room with three cameras, three displays, and six seats. Each camera captures two people. The six seats are not all in a straight line.
次の図は、3つのカメラ、3つのディスプレイ、および6席の部屋の上面図です。各カメラは二人を捕獲します。6席はすべて直線ではありません。
,-. d
( )`--.__ +---+
`-' / `--.__ | |
,-. | `-.._ |_-+Camera 2 (VC2)
( ).' <--(AC1)-+-''`+-+
`-' |_...---'' | |
,-.c+-..__ +---+
( )| ``--..__ | |
`-' | ``+-..|_-+Camera 1 (VC1)
,-. | <--(AC2)..--'|+-+ ^
( )| __..--' | | |
`-'b|..--' +---+ |X
,-. |``---..___ | | |
( )\ ```--..._|_-+Camera 0 (VC0) |
`-' \ <--(AC0) ..-''`-+ |
,-. \ __.--'' | | <----------+
( ) |..-'' +---+ Y
`-' a (0,0,0) origin is under Camera 1
Figure 5: Room Layout Top View
図5：部屋のレイアウトの上面図
The two points labeled 'b' and 'c' are intended to be at the midpoint between the seating positions, and where the fields of view of the cameras intersect.
'b'と 'c'と表示された2つの点は、座席位置とカメラの視野が交差する場所の中点にあることを意図しています。
The Plane of Interest for VC0 is a vertical plane that intersects points 'a' and 'b'.
VC0の関心面は、点「a」および 'b'と交差する垂直面です。
The Plane of Interest for VC1 intersects points 'b' and 'c'. The plane of interest for VC2 intersects points 'c' and 'd'.
VC1の関心面は点「B」と「C」と交差する。VC2の関心面は点「C」と「D」と交差する。
This example uses an area scale of millimeters.
この例では、ミリメートルの面スケールを使用しています。
Areas of capture:
キャプチャの分野：
bottom left bottom right top left top right VC0 (-2011,2850,0) (-673,3000,0) (-2011,2850,757) (-673,3000,757) VC1 ( -673,3000,0) ( 673,3000,0) ( -673,3000,757) ( 673,3000,757) VC2 ( 673,3000,0) (2011,2850,0) ( 673,3000,757) (2011,3000,757) MCC3(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) MCC4(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) VC5 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757) VC6 none
左下左下左上右上VC0（-2011,2850,0）（-673,3000,7）（-2011,2850,757）（-673,3000,757）VC1（-673,3000,0）（673,3000,757）（673,3000,757）VC2（673,3000,0）（2011,2850,7）（673,3000,757）（2011,3000,757））MCC3（-2011,2850,2）（2011,2850,0）（-2011,2850,757）（2011,3000,757）MCC4（-2011,2850,2）（2011,2850,0）（ - 2011,2850,757）（2011,3000,757）VC5（-2011,2850,0）（2011,2850,0）（-2011,2850,757）（2011,3000,757）VC6なし
Points of capture:
キャプチャのポイント：
VC0 (-1678,0,800) VC1 (0,0,800) VC2 (1678,0,800) MCC3 none MCC4 none VC5 (0,0,800) VC6 none
VC0（-1678,0,800）VC1（0,0,800）VC2（1678,0,800）MCC3なしMCC4なしVC5（0,0,800）VC6なし
In this example, the right edge of the VC0 area lines up with the left edge of the VC1 area. It doesn't have to be this way. There could be a gap or an overlap. One additional thing to note for this example is the distance from 'a' to 'b' is equal to the distance from 'b' to 'c' and the distance from 'c' to 'd'. All these distances are 1346 mm. This is the planar width of each Area of Capture for VC0, VC1, and VC2.
この例では、VC0エリアの右端はVC1領域の左端にあります。このようにする必要はありません。ギャップや重なりがある可能性があります。この例で注意する追加のものは、 'a'から 'b'までの距離であり、 'b'から 'c'への距離、 'c'から 'd'までの距離に等しいです。これらすべての距離は1346 mmです。これは、VC0、VC1、VC2の各キャプチャ領域の平面幅です。
Note the text in parentheses (e.g., "the left camera Stream") is not explicitly part of the model, it is just explanatory text for this example, and it is not included in the model with the Media Captures and attributes. Also, MCC4 doesn't say anything about how a Capture is composed, so the Media Consumer can't tell based on this Capture that MCC4 is composed of a "loudest panel with PiPs".
括弧内のテキスト（例えば、「左側のカメラストリーム」）はモデルの明示的な部分ではなく、この例の説明テキストであり、メディアキャプチャと属性を持つモデルには含まれません。また、MCC4はキャプチャがどのように構成されているかについて何も言わないので、MCC4が「PIPSの最も大きいパネル」で構成されているこのキャプチャに基づいて、メディアコンシューマはこのキャプチャに基づいてわかりません。
Audio Captures:
オーディオキャプチャ：
Three ceiling microphones are located between the cameras and the table, at the same height as the cameras. The microphones point down at an angle toward the seating positions.
カメラとテーブルの間の3つの天井マイクロフォンがカメラと同じ高さで配置されています。マイクロフォンは着座位置に向かって角度で垂れ下がる。
* AC0 (left), Encoding Group=EG3
* AC0（左）、符号化グループ= EG3
* AC1 (right), Encoding Group=EG3
* AC1（右）、符号化グループ= EG3
* AC2 (center), Encoding Group=EG3
* AC2（中央）、符号化グループ= EG3
* AC3 being a simple pre-mixed audio Stream from the room (mono), Encoding Group=EG3
* AC3は部屋からの単純なプリミックスオーディオストリームである（MONO）、encoding group = EG3
* AC4 audio Stream associated with the presentation video (mono) Encoding Group=EG3, presentation
* Presentation Videing（Mono）エンコーディングGroup = EG3、プレゼンテーションに関連付けられたAC4オーディオストリーム
Point of Capture: Point on Line of Capture: AC0 (-1342,2000,800) (-1342,2925,379) AC1 ( 1342,2000,800) ( 1342,2925,379) AC2 ( 0,2000,800) ( 0,3000,379) AC3 ( 0,2000,800) ( 0,3000,379) AC4 none
キャプチャのポイント：キャプチャのポイント：AC0（-1342,2000,800）（-1342,2925,379）AC1（1342,2000,800）（1342,2925,379）AC2（0,2000,800）（0,3000,379）AC3（0,2000,800）（0,3000,379）AC4なし
The physical simultaneity information is:
物理的な同時性情報は次のとおりです。
Simultaneous Transmission Set #1 {VC0, VC1, VC2, MCC3, MCC4, VC6}
Simultaneous Transmission Set #2 {VC0, VC2, VC5, VC6}
This constraint indicates that it is not possible to use all the VCs at the same time. VC5 cannot be used at the same time as VC1 or MCC3 or MCC4. Also, using every member in the set simultaneously may not make sense -- for example, MCC3 (loudest) and MCC4 (loudest with PiP). In addition, there are Encoding constraints that make choosing all of the VCs in a set impossible. VC1, MCC3, MCC4, VC5, and VC6 all use EG1 and EG1 has only three ENCs. This constraint shows up in the Encoding Groups, not in the Simultaneous Transmission Sets.
この制約は、すべてのVCSを同時に使用することが不可能であることを示しています。VC1またはMCC3またはMCC4と同時にVC5を使用することはできません。また、セット内のすべてのメンバーを同時に使用することで、MCC3（最大）、MCC4（PIPで最も大きい）などの意味がありません。さらに、セット内のすべてのVCを選択することを可能にするエンコード制約があります。VC1、MCC3、MCC4、VC5、およびVC6はすべてEG1とEG1を使用しています。この制約は、同時送信セットではなく、符号化グループに表示されます。
In this example, there are no restrictions on which Audio Captures can be sent simultaneously.
この例では、オーディオキャプチャを同時に送信できるのは制限はありません。
Encoding Groups:
エンコードグループ：
This example has three Encoding Groups associated with the Video Captures. Each group can have three Encodings, but with each potential Encoding having a progressively lower specification. In this example, 1080p60 transmission is possible (as ENC0 has a maxPps value compatible with that). Significantly, as up to three Encodings are available per group, it is possible to transmit some Video Captures simultaneously that are not in the same view in the Capture Scene, for example, VC1 and MCC3 at the same time. The information below about Encodings is a summary of what would be conveyed in SDP, not directly in the CLUE Advertisement.
この例には、ビデオキャプチャに関連付けられている3つのエンコードグループがあります。各グループは3つのエンコーディングを持つことができますが、各電位符号化は漸進的に仕様を有する。この例では、1080p60の伝送が可能です（ENC0はそれに互換性のあるMAXPPS値を持っています）。重要なことに、グループごとに最大3つのエンコーディングが入手可能であるため、キャプチャシーン内の同じビューに含まれていないいくつかのビデオキャプチャを同時に送信することができます。エンコーディングについて以下の情報は、直接的な広告で直接SDPで伝達されるものの概要です。
encodeGroupID=EG0, maxGroupBandwidth=6000000
encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
maxPps=124416000, maxBandwidth=4000000
encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30,
maxPps=27648000, maxBandwidth=4000000
encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30,
maxPps=15552000, maxBandwidth=4000000
encodeGroupID=EG1 maxGroupBandwidth=6000000
encodeID=ENC3, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
maxPps=124416000, maxBandwidth=4000000
encodeID=ENC4, maxWidth=1280, maxHeight=720, maxFrameRate=30,
maxPps=27648000, maxBandwidth=4000000
encodeID=ENC5, maxWidth=960, maxHeight=544, maxFrameRate=30,
maxPps=15552000, maxBandwidth=4000000
encodeGroupID=EG2 maxGroupBandwidth=6000000
encodeID=ENC6, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
maxPps=124416000, maxBandwidth=4000000
encodeID=ENC7, maxWidth=1280, maxHeight=720, maxFrameRate=30,
maxPps=27648000, maxBandwidth=4000000
encodeID=ENC8, maxWidth=960, maxHeight=544, maxFrameRate=30,
maxPps=15552000, maxBandwidth=4000000
Figure 6: Example Encoding Groups for Video
図6：ビデオの符号化グループの例
For audio, there are five potential Encodings available, so all five Audio Captures can be encoded at the same time.
オーディオの場合は、5つの潜在的なエンコーディングがありますので、5つのオーディオキャプチャーすべてが同時にエンコードできます。
encodeGroupID=EG3, maxGroupBandwidth=320000
encodeID=ENC9, maxBandwidth=64000
encodeID=ENC10, maxBandwidth=64000
encodeID=ENC11, maxBandwidth=64000
encodeID=ENC12, maxBandwidth=64000
encodeID=ENC13, maxBandwidth=64000
Figure 7: Example Encoding Group for Audio
図7：オーディオのエンコードグループの例
Capture Scenes:
キャプチャーシーン：
The following table represents the Capture Scenes for this Provider. Recall that a Capture Scene is composed of alternative CSVs covering the same spatial region. Capture Scene #1 is for the main people Captures, and Capture Scene #2 is for presentation.
次の表は、このプロバイダのキャプチャーシーンを表します。キャプチャシーンが同じ空間領域をカバーする代替のCSVで構成されていることを思い出してください。キャプチャシーン＃1は、主な人がキャプチャし、Capture Scene＃2がプレゼンテーション用です。
Each row in the table is a separate CSV.
テーブル内の各行は別のCSVです。
+==================+
| Capture Scene #1 |
+==================+
| VC0, VC1, VC2 |
+------------------+
| MCC3 |
+------------------+
| MCC4 |
+------------------+
| VC5 |
+------------------+
| AC0, AC1, AC2 |
+------------------+
| AC3 |
+==================+
| Capture Scene #2 |
+==================+
| VC6 |
+------------------+
| AC4 |
+------------------+
Table 7: Example CSVs
表7：CSVの例
Different Capture Scenes are distinct from each other and do not overlap. A Consumer can choose a view from each Capture Scene. In this case, the three Captures, VC0, VC1, and VC2, are one way of representing the video from the Endpoint. These three Captures should appear adjacent to each other. Alternatively, another way of representing the Capture Scene is with the Capture MCC3, which automatically shows the person who is talking; this is the same for the MCC4 and VC5 alternatives.
さまざまなキャプチャーシーンは互いに異なり、重ならない。消費者は各キャプチャシーンからビューを選択できます。この場合、3つのキャプチャ、VC0、VC1、およびVC2は、エンドポイントからビデオを表す1つの方法です。これら3つのキャプチャは互いに隣接して表示されます。あるいは、キャプチャシーンを表す別の方法はキャプチャMCC3と共に、それは自動的に話している人を表示する。これはMCC4とVC5の選択肢についても同じです。
As in the video case, the different views of audio in Capture Scene #1 represent the "same thing", in that one way to receive the audio is with the three Audio Captures (AC0, AC1, and AC2), and another way is with the mixed AC3. The Media Consumer can choose an audio CSV it is capable of receiving.
ビデオケースと同様に、キャプチャシーン＃1内の音声の異なるビューは「同じこと」を表しているので、オーディオを受信する方法は3つのオーディオキャプチャ（AC0、AC1、およびAC2）があり、別の方法は混合AC3で。メディア消費者は、受信可能なオーディオCSVを選択できます。
The spatial ordering is understood by the Media Capture attribute's Area of Capture, Point of Capture, and Point on Line of Capture.
空間順序付けは、メディアキャプチャ属性のキャプチャ属性のキャプチャの分野、キャプチャのポイント、およびキャプチャのラインのポイントによって理解されます。
A Media Consumer would likely want to choose a CSV to receive, partially based on how many Streams it can simultaneously receive. A Consumer that can receive three video Streams would probably prefer to receive the first view of Capture Scene #1 (VC0, VC1, and VC2) and not receive the other views. A Consumer that can receive only one video Stream would probably choose one of the other views.
メディアコンシューマは、同時に受信できるストリームの数に部分的に受信するためのCSVを選択したいと思うでしょう。3つのビデオストリームを受信することができる消費者は、キャプチャシーン＃1（VC0、VC1、およびVC2）の最初のビューを受信することを好み、他のビューを受信しないであろう。1つのビデオストリームのみを受信できる消費者は、おそらく他のビューの1つを選択するでしょう。
If the Consumer can receive a presentation Stream too, it would also choose to receive the only view from Capture Scene #2 (VC6).
消費者がプレゼンテーションストリームを受信できる場合は、キャプチャシーン＃2（VC6）から唯一のビューを受信することも選択します。
This is an example of an Encoding Group to illustrate how it can express dependencies between Encodings. The information below about Encodings is a summary of what would be conveyed in SDP, not directly in the CLUE Advertisement.
これは、エンコーディング間の依存関係を表現できる方法を説明するためのエンコードグループの例です。エンコーディングについて以下の情報は、直接的な広告で直接SDPで伝達されるものの概要です。
encodeGroupID=EG0 maxGroupBandwidth=6000000
encodeID=VIDENC0, maxWidth=1920, maxHeight=1088,
maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000
encodeID=VIDENC1, maxWidth=1920, maxHeight=1088,
maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000
encodeID=AUDENC0, maxBandwidth=96000
encodeID=AUDENC1, maxBandwidth=96000
encodeID=AUDENC2, maxBandwidth=96000
Here, the Encoding Group is EG0. Although the Encoding Group is capable of transmitting up to 6 Mbit/s, no individual video Encoding can exceed 4 Mbit/s.
ここで、符号化グループはEG0である。符号化グループは最大6 Mビット/秒を送信することができるが、個々のビデオエンコーディングは4 Mbit / sを超えることはない。
This Encoding Group also allows up to three audio Encodings, AUDENC<0-2>. It is not required that audio and video Encodings reside within the same Encoding Group, but if so, then the group's overall maxBandwidth value is a limit on the sum of all audio and video Encodings configured by the Consumer. A system that does not wish or need to combine bandwidth limitations in this way should instead use separate Encoding Groups for audio and video in order for the bandwidth limitations on audio and video to not interact.
このエンコーディンググループは、最大3つのオーディオエンコーディング、Audenc <0-2>を使用することもできます。オーディオおよびビデオのエンコーディングが同じエンコーディンググループ内に存在することは必須ではないが、その場合、グループの全体的なMAXBANDWIDTH値は、消費者によって構成されたすべてのオーディオとビデオエンコードの合計の制限です。このようにして帯域幅の制限を組み合わせることを望まない、または必要としないシステムは、オーディオおよびビデオの帯域幅の制限が対話しないように、オーディオおよびビデオの別々のエンコーディンググループを使用する必要があります。
Audio and video can be expressed in separate Encoding Groups, as in this illustration.
この図のように、オーディオとビデオは別々のエンコーディンググループで表現できます。
encodeGroupID=EG0 maxGroupBandwidth=6000000
encodeID=VIDENC0, maxWidth=1920, maxHeight=1088,
maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000
encodeID=VIDENC1, maxWidth=1920, maxHeight=1088,
maxFrameRate=60, maxPps=62208000, maxBandwidth=4000000
encodeGroupID=EG1 maxGroupBandwidth=500000
encodeID=AUDENC0, maxBandwidth=96000
encodeID=AUDENC1, maxBandwidth=96000
encodeID=AUDENC2, maxBandwidth=96000
This section shows how an MCU might express its Capture Scenes, intending to offer different choices for Consumers that can handle different numbers of Streams. Each MCC is for video. A single Audio Capture is provided for all single and multi-screen configurations that can be associated (e.g., lip-synced) with any combination of Video Captures (the MCCs) at the Consumer.
このセクションでは、MCUがそのキャプチャーシーンを表現する方法を示しています。これは、さまざまな数のストリームを処理できる消費者向けに異なる選択肢を提供するつもりです。各MCCはビデオ用です。単一のオーディオキャプチャは、コンシューマのビデオキャプチャ（MCC）の任意の組み合わせ（例えば、LIP同期）を関連付けることができるすべてのシングルスクリーン構成およびマルチスクリーン構成に対して提供される。
+==========================+==================================+
| Capture Scene #1 | |
+==========================+==================================+
| MCC | for a one-screen Consumer |
+--------------------------+----------------------------------+
| MCC1, MCC2 | for a two-screen Consumer |
+--------------------------+----------------------------------+
| MCC3, MCC4, MCC5 | for a three-screen Consumer |
+--------------------------+----------------------------------+
| MCC6, MCC7, MCC8, MCC9 | for a four-screen Consumer |
+--------------------------+----------------------------------+
| AC0 | AC representing all participants |
+--------------------------+----------------------------------+
| CSV(MCC0) | |
+--------------------------+----------------------------------+
| CSV(MCC1,MCC2) | |
+--------------------------+----------------------------------+
| CSV(MCC3,MCC4,MCC5) | |
+--------------------------+----------------------------------+
| CSV(MCC6,MCC7,MCC8,MCC9) | |
+--------------------------+----------------------------------+
| CSV(AC0) | |
+--------------------------+----------------------------------+
Table 8: MCU Main Capture Scenes
表8：MCUのメインキャプチャーシーン
If/when a presentation Stream becomes active within the Conference, the MCU might re-advertise the available Media as:
/会議内でプレゼンテーションストリームがアクティブになる場合、MCUは利用可能なメディアを次のように再アドバタイズすることがあります。
+==================+======================================+
| Capture Scene #2 | Note |
+==================+======================================+
| VC10 | Video Capture for presentation |
+------------------+--------------------------------------+
| AC1 | Presentation audio to accompany VC10 |
+------------------+--------------------------------------+
| CSV(VC10) | |
+------------------+--------------------------------------+
| CSV(AC1) | |
+------------------+--------------------------------------+
Table 9: MCU Presentation Capture Scene
表9：MCUプレゼンテーションキャプチャシーン
This section gives an example of how a Media Consumer might behave when deciding how to request Streams from the three-screen Endpoint described in the previous section.
このセクションでは、前のセクションで説明されている3画面エンドポイントからストリームを要求する方法を決定するときに、メディアコンシューマが動作する方法の例を示します。
The receive side of a call needs to balance its requirements (based on number of screens and speakers), its decoding capabilities, available bandwidth, and the Provider's capabilities in order to optimally configure the Provider's Streams. Typically, it would want to receive and decode Media from each Capture Scene advertised by the Provider.
コールの受信側は、プロバイダのストリームを最適に構成するために、その要件（スクリーンとスピーカー数に基づく）、その復号機能、利用可能な帯域幅、およびプロバイダの機能のバランスをとる必要があります。通常、プロバイダによってアドバタイズされた各キャプチャシーンからメディアを受信してデコードしたいと思う。
A sane, basic, algorithm might be for the Consumer to go through each CSV in turn and find the collection of Video Captures that best matches the number of screens it has (this might include consideration of screens dedicated to presentation video display rather than "people" video) and then decide between alternative views in the video Capture Scenes based either on hard-coded preferences or on user choice. Once this choice has been made, the Consumer would then decide how to configure the Provider's Encoding Groups in order to make best use of the available network bandwidth and its own decoding capabilities.
SANE、BASIC、アルゴリズムは、消費者が各CSVを通過し、それが持っている画面の数に最も適したビデオキャプチャのコレクションを見つけることができます（これには、プレゼンテーションビデオディスプレイに専用の画面の検討を含めることができます）「ビデオ）してから、ハードコードされた環境設定またはユーザー選択に基づいて、ビデオキャプチャシーンの代替ビューの間を決定します。この選択が行われたら、消費者は利用可能なネットワーク帯域幅と独自の復号化機能を最大限に活用するためにプロバイダのエンコーディンググループを設定する方法を決定します。
MCC3, MCC4, and VC5 are all different views by themselves, not grouped together in a single view; so, the receiving device should choose between one of those. The choice would come down to whether to see the greatest number of participants simultaneously at roughly equal precedence (VC5), a switched view of just the loudest region (MCC3), or a switched view with PiPs (MCC4). An Endpoint device with a small amount of knowledge of these differences could offer a dynamic choice of these options, in-call, to the user.
MCC3、MCC4、およびVC5は、単一のビューでグループ化されていない、それら自体によってすべての異なるビューです。したがって、受信装置はそれらのうちの1つを選択するべきです。選択は、大幅に等しい優先順位（VC5）、最大の領域（MCC3）の切り替えビュー、またはピップ付きのスイッチビュー（MCC4）の切り替えビューで同時に最大数の参加者を見るかどうかに留まります。これらの違いについてのわずかな知識を持つエンドポイントデバイスは、これらのオプション、通話中の動的な選択をユーザーに提供できます。
Mixing systems with an even number of screens, "2n", and those with "2n+1" cameras (and vice versa) is always likely to be the problematic case. In this instance, the behavior is likely to be determined by whether a "two-screen" system is really a "two-decoder" system, i.e., whether only one received Stream can be displayed per screen or whether more than two Streams can be received and spread across the available screen area. To enumerate three possible behaviors here for the two-screen system when it learns that the far end is "ideally" expressed via three Capture Streams:
偶数のスクリーン、「2N」、および「2N 1」カメラを持つもの（およびその逆）を持つものの混合システムは、常に問題のある場合である可能性があります。この場合、この動作は、「2画面」システムが本当に「2デコーダ」システムであるかどうか、すなわち1画面ごとに1つの受信ストリームだけを表示できるかどうか、または2つ以上のストリームがあるかどうかによって決定される可能性が高い。利用可能な画面領域にわたって受信して広がります。2スクリーンシステムに対してここで3つの可能な動作を列挙すると、遠端が3つのキャプチャストリームを介して「理想的に」表現されていることを学習したとき：
1. Fall back to receiving just a single Stream (MCC3, MCC4, or VC5 as per the one-screen Consumer case above) and either leave one screen blank or use it for presentation if/when a presentation becomes active.
1. 1つのスクリーンの消費者のケースに従って単一のストリーム（MCC3、MCC4、またはVC5）だけを受信し、プレゼンテーションがアクティブになる場合は、1画面を空白のままにするか、プレゼンテーション用に使用する場合は、/表示用に使用してください。
2. Receive three Streams (VC0, VC1, and VC2) and display across two screens (either with each Capture being scaled to 2/3 of a screen and the center Capture being split across two screens), or, as would be necessary if there were large bezels on the screens, with each Stream being scaled to 1/2 the screen width and height and there being a fourth "blank" panel. This fourth panel could potentially be used for any presentation that became active during the call.
2. 3つのストリーム（VC0、VC1、およびVC2）を受け取り、2つの画面にまたがって表示されている（各キャプチャーが2つのスクリーンの2/3に拡大縮小され、中央のキャプチャーが2つのスクリーンに分割されている）、または必要に応じて必要な場合は、スクリーン上の大きなベゼルは、各ストリームがスクリーンの幅と高さに拡大縮小され、4番目の「空白」パネルがあります。この4番目のパネルは、通話中にアクティブになったプレゼンテーションに潜在的に使用できます。
3. Receive three Streams, decode all three, and use control information indicating which was the most active to switch between showing the left and center Streams (one per screen) and the center and right Streams.
3. 3つのストリームを受け取り、3つすべてをデコードし、左右のストリームと中央のストリーム（1画面ごとに）と中央のストリームを表示するのに最適で最もアクティブな制御情報を使用します。
For an Endpoint capable of all three methods of working described above, again it might be appropriate to offer the user the choice of display mode.
上記の3つの方法のすべての方法が可能なエンドポイントの場合、再びユーザーに表示モードの選択を提供することが適切かもしれません。
This is the most straightforward case: the Media Consumer would look to identify a set of Streams to receive that best matched its available screens; so, the VC0 plus VC1 plus VC2 should match optimally. The spatial ordering would give sufficient information for the correct Video Capture to be shown on the correct screen. The Consumer would need to divide a single Encoding Group's capability by 3 either to determine what resolution and frame rate to configure the Provider with or to configure the individual Video Captures' Encoding Groups with what makes most sense (taking into account the receive side decode capabilities, overall call bandwidth, the resolution of the screens plus any user preferences such as motion vs. sharpness).
これは最も簡単な場合です。メディアコンシューマは、利用可能なスクリーンを最も適合させたということを受け取る一連のストリームを識別します。そのため、VC0 Plus VC1 Plus VC2は最適に一致する必要があります。空間順序付けは正しい画面に表示されるべき正しいビデオキャプチャのための十分な情報を与えるでしょう。消費者は、プロバイダを構成するための、または個々のビデオキャプチャのエンコーディンググループをどのように構成するかを決定するために、（受信側のデコード機能を考慮に入れて設定するために、単一のエンコーディンググループの機能を3つより分割する必要があります。、全体的なコール帯域幅、スクリーンの解像度と、動きや鮮明さなどの任意のユーザー設定）。
The use of MCCs allows the MCU to construct outgoing Advertisements describing complex Media switching and composition scenarios. The following sections provide several examples.
MCCSの使用により、MCUは複雑なメディアの切り替えと構成シナリオを記述する発信広告を構築できます。次のセクションではいくつかの例を示します。
Note: in the examples the identities of the CLUE elements (e.g., Captures, Capture Scene) in the incoming Advertisements overlap. This is because there is no coordination between the Endpoints. The MCU is responsible for making these unique in the outgoing Advertisement.
注：例では、着信広告内の手がかり要素（例えば、キャプチャ、キャプチャシーン）のアイデンティティが重なり合っています。これは、エンドポイント間に調整がないためです。MCUはこれらのユニークな広告の中でこれらのユニークなものを作る責任があります。
Four Endpoints are involved in a Conference where CLUE is used. An MCU acts as a middlebox between the Endpoints with a CLUE channel between each Endpoint and the MCU. The MCU receives the following Advertisements.
4つのエンドポイントは、CLUEが使用されている会議に参加しています。MCUは、各エンドポイントとMCUの間の手がかりチャネルを持つエンドポイント間のミドルボックスとして機能します。MCUは次の広告を受け取ります。
+==================+================================+
| Capture Scene #1 | Description=AustralianConfRoom |
+==================+================================+
| VC1 | Description=Audience |
| | EncodeGroupID=1 |
+------------------+--------------------------------+
| CSV(VC1) | |
+------------------+--------------------------------+
Table 10: Advertisement Received from Endpoint A
表10：エンドポイントAから受信した広告
+==================+===========================+
| Capture Scene #1 | Description=ChinaConfRoom |
+==================+===========================+
| VC1 | Description=Speaker |
| | EncodeGroupID=1 |
+------------------+---------------------------+
| VC2 | Description=Audience |
| | EncodeGroupID=1 |
+------------------+---------------------------+
| CSV(VC1, VC2) | |
+------------------+---------------------------+
Table 11: Advertisement Received from Endpoint B
表11：エンドポイントBから受信した広告
Note: Endpoint B indicates that it sends two Streams.
注：エンドポイントBは、2つのストリームを送信することを示します。
+==================+=========================+
| Capture Scene #1 | Description=USAConfRoom |
+==================+=========================+
| VC1 | Description=Audience |
| | EncodeGroupID=1 |
+------------------+-------------------------+
| CSV(VC1) | |
+------------------+-------------------------+
Table 12: Advertisement Received from Endpoint C
表12：エンドポイントCから受信した広告
If the MCU wanted to provide a Multiple Content Captures containing a round-robin switched view of the audience from the three Endpoints and the speaker, it could construct the following Advertisement:
MCUが、3つのエンドポイントとスピーカーからのオーディエンスのラウンドロビン切り替えビューを含む複数のコンテンツキャプチャを提供したい場合は、次のアドバタイズメントを作成できます。
+=======================+================================+
| Capture Scene #1 | Description=AustralianConfRoom |
+=======================+================================+
| VC1 | Description=Audience |
+-----------------------+--------------------------------+
| CSV(VC1) | |
+=======================+================================+
| Capture Scene #2 | Description=ChinaConfRoom |
+=======================+================================+
| VC2 | Description=Speaker |
+-----------------------+--------------------------------+
| VC3 | Description=Audience |
+-----------------------+--------------------------------+
| CSV(VC2, VC3) | |
+=======================+================================+
| Capture Scene #3 | Description=USAConfRoom |
+=======================+================================+
| VC4 | Description=Audience |
+-----------------------+--------------------------------+
| CSV(VC4) | |
+=======================+================================+
| Capture Scene #4 | |
+=======================+================================+
| MCC1(VC1,VC2,VC3,VC4) | Policy=RoundRobin:1 |
| | MaxCaptures=1 |
| | EncodingGroup=1 |
+-----------------------+--------------------------------+
| CSV(MCC1) | |
+-----------------------+--------------------------------+
Table 13: Advertisement Sent to Endpoint F - One Encoding
表13：エンドポイントFに送信された広告 - 1つのエンコーディング
Alternatively, if the MCU wanted to provide the speaker as one Media Stream and the audiences as another, it could assign an Encoding Group to VC2 in Capture Scene 2 and provide a CSV in Capture Scene #4 as per the example below.
あるいは、MCUがスピーカに1つのメディアストリームおよびオーディエンスを別のメディアストリームとして提供したい場合は、キャプチャシーン2内の符号化グループをVC2に割り当て、以下の例に従ってキャプチャシーン＃4にCSVを提供することができる。
+===================+================================+
| Capture Scene #1 | Description=AustralianConfRoom |
+===================+================================+
| VC1 | Description=Audience |
+-------------------+--------------------------------+
| CSV(VC1) | |
+===================+================================+
| Capture Scene #2 | Description=ChinaConfRoom |
+===================+================================+
| VC2 | Description=Speaker |
| | EncodingGroup=1 |
+-------------------+--------------------------------+
| VC3 | Description=Audience |
+-------------------+--------------------------------+
| CSV(VC2, VC3) | |
+===================+================================+
| Capture Scene #3 | Description=USAConfRoom |
+===================+================================+
| VC4 | Description=Audience |
+-------------------+--------------------------------+
| CSV(VC4) | |
+===================+================================+
| Capture Scene #4 | |
+===================+================================+
| MCC1(VC1,VC3,VC4) | Policy=RoundRobin:1 |
| | MaxCaptures=1 |
| | EncodingGroup=1 |
| | AllowSubset=True |
+-------------------+--------------------------------+
| MCC2(VC2) | MaxCaptures=1 |
| | EncodingGroup=1 |
+-------------------+--------------------------------+
| CSV2(MCC1,MCC2) | |
+-------------------+--------------------------------+
Table 14: Advertisement Sent to Endpoint F - Two Encodings
表14：エンドポイントFに送信された広告 - 2つのエンコーディング
Therefore, a Consumer could choose whether or not to have a separate speaker-related Stream and could choose which Endpoints to see. If it wanted the second Stream but not the Australian conference room, it could indicate the following Captures in the Configure message:
したがって、消費者は、別々のスピーカー関連のストリームを持つかどうかを選択し、どのエンドポイントを見るかを選択できます。それが2番目のストリームを望んでいたがオーストラリアの会議室ではない場合は、次のキャプチャを設定してください。
+---------------+----------+
| MCC1(VC3,VC4) | Encoding |
+---------------+----------+
| VC2 | Encoding |
+---------------+----------+
Table 15: MCU Case: Consumer Response
表15：MCUケース：コンシューマレスポンス
Multiple MCCs can be used where multiple Streams are used to carry Media from multiple Endpoints. For example:
複数のStreamsが複数のエンドポイントからメディアを伝送するために使用される複数のMCCを使用できます。例えば：
A Conference has three Endpoints D, E, and F. Each Endpoint has three Video Captures covering the left, middle, and right regions of each conference room. The MCU receives the following Advertisements from D and E.
会議には3つのエンドポイントD、E、およびFがあります。各エンドポイントには、各会議室の左側、中央、および右側の領域が3つのビデオキャプチャがあります。MCUはDとEから次の広告を受信します。
+==================+================================+
| Capture Scene #1 | Description=AustralianConfRoom |
+==================+================================+
| VC1 | CaptureArea=Left |
+------------------+--------------------------------+
| | EncodingGroup=1 |
+------------------+--------------------------------+
| VC2 | CaptureArea=Center |
+------------------+--------------------------------+
| | EncodingGroup=1 |
+------------------+--------------------------------+
| VC3 | CaptureArea=Right |
+------------------+--------------------------------+
| | EncodingGroup=1 |
+------------------+--------------------------------+
| CSV(VC1,VC2,VC3) | |
+------------------+--------------------------------+
Table 16: Advertisement Received from Endpoint D
表16：エンドポイントDから受信した広告
+==================+===========================+
| Capture Scene #1 | Description=ChinaConfRoom |
+==================+===========================+
| VC1 | CaptureArea=Left |
+------------------+---------------------------+
| | EncodingGroup=1 |
+------------------+---------------------------+
| VC2 | CaptureArea=Center |
+------------------+---------------------------+
| | EncodingGroup=1 |
+------------------+---------------------------+
| VC3 | CaptureArea=Right |
+------------------+---------------------------+
| | EncodingGroup=1 |
+------------------+---------------------------+
| CSV(VC1,VC2,VC3) | |
+------------------+---------------------------+
Table 17: Advertisement Received from Endpoint E
表17：エンドポイントEから受信した広告
The MCU wants to offer Endpoint F three Capture Encodings. Each Capture Encoding would contain all the Captures from either Endpoint D or Endpoint E, depending on the active speaker. The MCU sends the following Advertisement:
MCUはエンドポイントF 3キャプチャエンコーディングを提供したいです。各キャプチャエンコーディングは、アクティブスピーカーに応じて、エンドポイントDまたはエンドポイントEのいずれかのキャプチャを含みます。MCUは次の広告を送信します。
+=====================+================================+
| Capture Scene #1 | Description=AustralianConfRoom |
+=====================+================================+
| VC1 | |
+---------------------+--------------------------------+
| VC2 | |
+---------------------+--------------------------------+
| VC3 | |
+---------------------+--------------------------------+
| CSV(VC1,VC2,VC3) | |
+=====================+================================+
| Capture Scene #2 | Description=ChinaConfRoom |
+=====================+================================+
| VC4 | |
+---------------------+--------------------------------+
| VC5 | |
+---------------------+--------------------------------+
| VC6 | |
+---------------------+--------------------------------+
| CSV(VC4,VC5,VC6) | |
+=====================+================================+
| Capture Scene #3 | |
+=====================+================================+
| MCC1(VC1,VC4) | CaptureArea=Left |
| | MaxCaptures=1 |
| | SynchronizationID=1 |
| | EncodingGroup=1 |
+---------------------+--------------------------------+
| MCC2(VC2,VC5) | CaptureArea=Center |
| | MaxCaptures=1 |
| | SynchronizationID=1 |
| | EncodingGroup=1 |
+---------------------+--------------------------------+
| MCC3(VC3,VC6) | CaptureArea=Right |
| | MaxCaptures=1 |
| | SynchronizationID=1 |
| | EncodingGroup=1 |
+---------------------+--------------------------------+
| CSV(MCC1,MCC2,MCC3) | |
+---------------------+--------------------------------+
Table 18: Advertisement Sent to Endpoint F
表18：エンドポイントFに送信された広告
Consider a Conference between Endpoints with the following characteristics:
以下の特性を持つエンドポイント間の会議を検討してください。
Endpoint A - 4 screens, 3 cameras
エンドポイントA - 4スクリーン、3カメラ
Endpoint B - 3 screens, 3 cameras
エンドポイントB - 3スクリーン、3カメラ
Endpoint C - 3 screens, 3 cameras
エンドポイントC - 3スクリーン、3カメラ
Endpoint D - 3 screens, 3 cameras
エンドポイントD - 3スクリーン、3カメラ
Endpoint E - 1 screen, 1 camera
エンドポイントE - 1画面、1カメラ
Endpoint F - 2 screens, 1 camera
エンドポイントF - 2スクリーン、1カメラ
Endpoint G - 1 screen, 1 camera
エンドポイントG - 1画面、1カメラ
This example focuses on what the user in one of the three-camera multi-screen Endpoints sees. Call this person User A, at Endpoint A. There are four large display screens at Endpoint A. Whenever somebody at another site is speaking, all the Video Captures from that Endpoint are shown on the large screens. If the talker is at a three-camera site, then the video from those three cameras fills three of the screens. If the person speaking is at a single-camera site, then video from that camera fills one of the screens, while the other screens show video from other single-camera Endpoints.
この例では、3カメラのマルチスクリーンエンドポイントのうちの1つにユーザーがどのように見えます。エンドポイントAでこの人ユーザーAを呼んでください。エンドポイントAに4つの大きなディスプレイスクリーンがあります。別のサイトにいる誰かが話しているときはいつでも、そのエンドポイントからのすべてのビデオキャプチャが大きな画面に表示されます。トーカが3カメラサイトにある場合、それらの3つのカメラからのビデオは3つのスクリーンを埋めます。話す人がシングルカメラサイトにある場合、そのカメラからのビデオはスクリーンの1つを満たしますが、他のスクリーンは他のシングルカメラエンドポイントからのビデオを表示します。
User A hears audio from the four loudest talkers.
ユーザーAは4つの最大の話者から音声を聞きます。
User A can also see video from other Endpoints, in addition to the current person speaking, although much smaller in size. Endpoint A has four screens, so one of those screens shows up to nine other Media Captures in a tiled fashion. When video from a three-camera Endpoint appears in the tiled area, video from all three cameras appears together across the screen with correct Spatial Relationship among those three images.
ユーザAはまた、現在のサイズがはるかに小さいが、現在の人物に加えて他のエンドポイントからのビデオを見ることもできる。エンドポイントAには4つのスクリーンがあります。3カメラエンドポイントからのビデオがタイル張り領域に現れると、3つのカメラのすべてのカメラからのビデオが画面間で一緒になって、それらの3つの画像の間で正しい空間的関係が表示されます。
+---+---+---+ +-------------+ +-------------+ +-------------+
| | | | | | | | | |
+---+---+---+ | | | | | |
| | | | | | | | | |
+---+---+---+ | | | | | |
| | | | | | | | | |
+---+---+---+ +-------------+ +-------------+ +-------------+
Figure 8: Endpoint A - Four-Screen Display
図8：エンドポイントA - 4画面表示
User B at Endpoint B sees a similar arrangement, except there are only three screens, so the nine other Media Captures are spread out across the bottom of the three displays, in a PiP format. When video from a three-camera Endpoint appears in the PiP area, video from all three cameras appears together across one screen with correct Spatial Relationship.
エンドポイントBのユーザBは、3つの画面しかない以外は同様の構成を見ているので、9つのディスプレイの下部にある9つの他のメディアキャプチャがPIP形式で拡散される。3カメラエンドポイントからのビデオがPIP領域に表示されると、3つのカメラすべてからのビデオが1画面にわたって正しい空間的関係を持つ1画面に表示されます。
+-------------+ +-------------+ +-------------+
| | | | | |
| | | | | |
| | | | | |
| +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ |
| +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ |
+-------------+ +-------------+ +-------------+
Figure 9: Endpoint B - Three-Screen Display with PiPs
図9：エンドポイントB - ピップ付き3画面表示
When somebody at a different Endpoint becomes the current speaker, then User A and User B both see the video from the new person speaking appear on their large screen area, while the previous speaker takes one of the smaller tiled or PiP areas. The person who is the current speaker doesn't see themselves; they see the previous speaker in their large screen area.
異なるエンドポイントの誰かが現在のスピーカーになると、ユーザーAとユーザーBは両方ともスピーチの大きなスクリーンエリアに表示されているビデオが表示されますが、前のスピーカーは小さい方のタイル張りまたはPIP領域の1つを取ります。現在の話者である人は自分自身を見ません。彼らは彼らの大きなスクリーン領域に前のスピーカーを見ます。
One of the points of this example is that Endpoints A and B each want to receive three Capture Encodings for their large display areas, and nine Encodings for their smaller areas. A and B are be able to each send the same Configure message to the MCU, and each receive the same conceptual Media Captures from the MCU. The differences are in how they are Rendered and are purely a local matter at A and B.
この例の点の1つは、エンドポイントAとBがそれぞれ、それらの大きなディスプレイ領域に対して3つのキャプチャエンコーディングを受信し、それらのより小さな領域のための9つのエンコーディングを受け取りたいということです。AとBはそれぞれMCUに同じ構成メッセージを送信することができ、それぞれがMCUから同じ概念メディアを受け取る。違いは、それらがどのようにレンダリングされており、純粋にAとBの地域的な問題です。
The Advertisements for such a scenario are described below.
そのようなシナリオのための広告は以下の通りである。
+=====================+========================+
| Capture Scene #1 | Description=Endpoint x |
+=====================+========================+
| VC1 | EncodingGroup=1 |
+---------------------+------------------------+
| VC2 | EncodingGroup=1 |
+---------------------+------------------------+
| VC3 | EncodingGroup=1 |
+---------------------+------------------------+
| AC1 | EncodingGroup=2 |
+---------------------+------------------------+
| CSV1(VC1, VC2, VC3) | |
+---------------------+------------------------+
| CSV2(AC1) | |
+---------------------+------------------------+
Table 19: Advertisement Received at the MCU from Endpoints A to D
表19：Endpoints AからDへのMCUで受信された広告
+==================+========================+
| Capture Scene #1 | Description=Endpoint y |
+==================+========================+
| VC1 | EncodingGroup=1 |
+------------------+------------------------+
| AC1 | EncodingGroup=2 |
+------------------+------------------------+
| CSV1(VC1) | |
+------------------+------------------------+
| CSV2(AC1) | |
+------------------+------------------------+
Table 20: Advertisement Received at the MCU from Endpoints E to G
表20：Endpoints EからGにMCUで受信された広告
Rather than considering what is displayed, CLUE concentrates more on what the MCU sends. The MCU doesn't know anything about the number of screens an Endpoint has.
表示されるものを検討するのではなく、ClueはMCUが送信するものにもっと集中します。MCUは、エンドポイントが持っている画面の数について何もわからない。
As Endpoints A to D each advertise that three Captures make up a Capture Scene, the MCU offers these in a "site switching" mode. That is, there are three Multiple Content Captures (and Capture Encodings) each switching between Endpoints. The MCU switches in the applicable Media into the Stream based on voice activity. Endpoint A will not see a Capture from itself.
A~Dには、3つのキャプチャがキャプチャシーンを構成することを宣伝するため、MCUは「サイト切り替え」モードでこれらを提供します。つまり、エンドポイント間で切り替わる複数のコンテンツキャプチャ（およびキャプチャエンコーディング）が3つあります。MCUは、音声アクティビティに基づいて該当するメディア内のストリームに切り替わります。エンドポイントAはそれ自体からのキャプチャを見ません。
Using the MCC concept, the MCU would send the following Advertisement to Endpoint A:
MCCの概念を使用して、MCUは次のアドバタイズメントをエンドポイントAに送信します。
+=====================+========================+
| Capture Scene #1 | Description=Endpoint B |
+=====================+========================+
| VC4 | CaptureArea=Left |
+---------------------+------------------------+
| VC5 | CaptureArea=Center |
+---------------------+------------------------+
| VC6 | CaptureArea=Right |
+---------------------+------------------------+
| AC1 | |
+---------------------+------------------------+
| CSV(VC4,VC5,VC6) | |
+---------------------+------------------------+
| CSV(AC1) | |
+=====================+========================+
| Capture Scene #2 | Description=Endpoint C |
+=====================+========================+
| VC7 | CaptureArea=Left |
+---------------------+------------------------+
| VC8 | CaptureArea=Center |
+---------------------+------------------------+
| VC9 | CaptureArea=Right |
+---------------------+------------------------+
| AC2 | |
+---------------------+------------------------+
| CSV(VC7,VC8,VC9) | |
+---------------------+------------------------+
| CSV(AC2) | |
+=====================+========================+
| Capture Scene #3 | Description=Endpoint D |
+=====================+========================+
| VC10 | CaptureArea=Left |
+---------------------+------------------------+
| VC11 | CaptureArea=Center |
+---------------------+------------------------+
| VC12 | CaptureArea=Right |
+---------------------+------------------------+
| AC3 | |
+---------------------+------------------------+
| CSV(VC10,VC11,VC12) | |
+---------------------+------------------------+
| CSV(AC3) | |
+=====================+========================+
| Capture Scene #4 | Description=Endpoint E |
+=====================+========================+
| VC13 | |
+---------------------+------------------------+
| AC4 | |
+---------------------+------------------------+
| CSV(VC13) | |
+---------------------+------------------------+
| CSV(AC4) | |
+=====================+========================+
| Capture Scene #5 | Description=Endpoint F |
+=====================+========================+
| VC14 | |
+---------------------+------------------------+
| AC5 | |
+---------------------+------------------------+
| CSV(VC14) | |
+---------------------+------------------------+
| CSV(AC5) | |
+=====================+========================+
| Capture Scene #6 | Description=Endpoint G |
+=====================+========================+
| VC15 | |
+---------------------+------------------------+
| AC6 | |
+---------------------+------------------------+
| CSV(VC15) | |
+---------------------+------------------------+
| CSV(AC6) | |
+---------------------+------------------------+
Table 21: Advertisement Sent to Endpoint A - Source Part
表21：エンドポイントAに送信された広告
The above part of the Advertisement presents information about the sources to the MCC. The information is effectively the same as the received Advertisements, except that there are no Capture Encodings associated with them and the identities have been renumbered.
広告の上記の部分は、ソースに関する情報をMCCに提示します。情報は受信広告と同じであり、それらに関連付けられたキャプチャエンコーディングがないことを除いて、アイデンティティが変更されたことを除いて、受信アドバタイズメントと同じである。
In addition to the source Capture information, the MCU advertises site switching of Endpoints B to G in three Streams.
ソースキャプチャ情報に加えて、MCUは3つのストリーム内のエンドポイントBのサイトスイッチングを宣伝する。
+=====================+==============================+
| Capture Scene #7 | Description=Output3streammix |
+=====================+==============================+
| MCC1(VC4,VC7,VC10, | CaptureArea=Left |
| VC13) | MaxCaptures=1 |
| | SynchronizationID=1 |
| | Policy=SoundLevel:0 |
| | EncodingGroup=1 |
+---------------------+------------------------------+
| MCC2(VC5,VC8,VC11, | CaptureArea=Center |
| VC14) | MaxCaptures=1 |
| | SynchronizationID=1 |
| | Policy=SoundLevel:0 |
| | EncodingGroup=1 |
+---------------------+------------------------------+
| MCC3(VC6,VC9,VC12, | CaptureArea=Right |
| VC15) | MaxCaptures=1 |
| | SynchronizationID=1 |
| | Policy=SoundLevel:0 |
| | EncodingGroup=1 |
+---------------------+------------------------------+
| MCC4() (for audio) | CaptureArea=whole Scene |
| | MaxCaptures=1 |
| | Policy=SoundLevel:0 |
| | EncodingGroup=2 |
+---------------------+------------------------------+
| MCC5() (for audio) | CaptureArea=whole Scene |
| | MaxCaptures=1 |
| | Policy=SoundLevel:1 |
| | EncodingGroup=2 |
+---------------------+------------------------------+
| MCC6() (for audio) | CaptureArea=whole Scene |
| | MaxCaptures=1 |
| | Policy=SoundLevel:2 |
| | EncodingGroup=2 |
+---------------------+------------------------------+
| MCC7() (for audio) | CaptureArea=whole Scene |
| | MaxCaptures=1 |
| | Policy=SoundLevel:3 |
| | EncodingGroup=2 |
+---------------------+------------------------------+
| CSV(MCC1,MCC2,MCC3) | |
+---------------------+------------------------------+
| CSV(MCC4,MCC5,MCC6, | |
| MCC7) | |
+---------------------+------------------------------+
Table 22: Advertisement Sent to Endpoint A - Switching Parts
表22：エンドポイントAに送信された広告
The above part describes the three main switched Streams that relate to site switching. MaxCaptures=1 indicates that only one Capture from the MCC is sent at a particular time. SynchronizationID=1 indicates that the source sending is synchronized. The Provider can choose to group together VC13, VC14, and VC15 for the purpose of switching according to the SynchronizationID. Therefore, when the Provider switches one of them into an MCC, it can also switch the others even though they are not part of the same Capture Scene.
上記の部分では、サイト切り替えに関連する3つの主な切り替えストリームについて説明します。MAXCAPTURES = 1 MCCからの1つのキャプチャのみが特定の時間に送信されることを示します。SynchronizationID = 1は、送信元送信が同期されていることを示します。プロバイダは、同期IDに従って切り替えることを目的として、VC13、VC14、およびVC15をグループ化することを選択できます。したがって、プロバイダがそれらのうちの1つをMCCに切り替えると、同じキャプチャシーンの一部ではないとしても他のものを切り替えることもできます。
All the audio for the Conference is included in Scene #7. There isn't necessarily a one-to-one relation between any Audio Capture and Video Capture in this Scene. Typically, a change in the loudest talker will cause the MCU to switch the audio Streams more quickly than switching video Streams.
会議のためのオーディオはすべてシーン＃7に含まれています。このシーンのオーディオキャプチャとビデオキャプチャの間には必ずしも1対1の関係はありません。通常、最も大きい話者の変更により、MCUはビデオストリームを切り替えるよりも迅速にオーディオストリームを切り替えることになります。
The MCU can also supply nine Media Streams showing the active and previous eight speakers. It includes the following in the Advertisement:
MCUはまた、アクティブな8つのスピーカーを示す9つのメディアストリームを供給することができる。それは広告の中で次のものを含みます：
+========================+===========================+
| Capture Scene #8 | Description=Output9stream |
+========================+===========================+
| MCC8(VC4,VC5,VC6,VC7, | MaxCaptures=1 |
| VC8,VC9,VC10,VC11, | Policy=SoundLevel:0 |
| VC12,VC13,VC14,VC15) | EncodingGroup=1 |
+------------------------+---------------------------+
| MCC9(VC4,VC5,VC6,VC7, | MaxCaptures=1 |
| VC8,VC9,VC10,VC11, | Policy=SoundLevel:1 |
| VC12,VC13,VC14,VC15) | EncodingGroup=1 |
+========================+===========================+
| to | to |
+========================+===========================+
| MCC16(VC4,VC5,VC6,VC7, | MaxCaptures=1 |
| VC8,VC9,VC10,VC11, | Policy=SoundLevel:8 |
| VC12,VC13,VC14,VC15) | EncodingGroup=1 |
+------------------------+---------------------------+
| CSV(MCC8,MCC9,MCC10, | |
| MCC11,MCC12,MCC13, | |
| MCC14,MCC15,MCC16) | |
+------------------------+---------------------------+
Table 23: Advertisement Sent to Endpoint A - 9 Switched Parts
表23：エンドポイントA - 9スイッチ部品に送信された広告
The above part indicates that there are nine Capture Encodings. Each of the Capture Encodings may contain any Captures from any source site with a maximum of one Capture at a time. Which Capture is present is determined by the policy. The MCCs in this Scene do not have any spatial attributes.
上記の部分は、9つのキャプチャエンコーディングがあることを示しています。キャプチャエンコーディングのそれぞれは、一度に最大1回のキャプチャを持つ任意のソースサイトからの任意のキャプチャを含み得る。どのキャプチャが存在するかはポリシーによって決まります。このシーンのMCCには、空間属性はありません。
Note: The Provider alternatively could provide each of the MCCs above in its own Capture Scene.
注：プロバイダは、上記の各MCCをそれ自身のキャプチャシーンに提供することもできます。
If the MCU wanted to provide a composed Capture Encoding containing all of the nine Captures, it could advertise in addition:
MCUが9つのキャプチャのすべてを含む合成キャプチャエンコーディングを提供したい場合は、さらに宣伝できました。
+========================+=======================+
| Capture Scene #9 | Description=NineTiles |
+========================+=======================+
| MCC13(MCC8,MCC9,MCC10, | MaxCaptures=9 |
| MCC11,MCC12,MCC13, | EncodingGroup=1 |
| MCC14,MCC15,MCC16) | |
+------------------------+-----------------------+
| CSV(MCC13) | |
+------------------------+-----------------------+
Table 24: Advertisement Sent to Endpoint A - 9 Composed Parts
表24：エンドポイントA - 9コンポーネント部品に送信された広告
As MaxCaptures is 9, it indicates that the Capture Encoding contains information from nine sources at a time.
MAXCAPTURESが9の場合、キャプチャエンコーディングに一度に9つのソースからの情報が含まれていることを示します。
The Advertisement to Endpoint B is identical to the above, other than the fact that Captures from Endpoint A would be added and the Captures from Endpoint B would be removed. Whether the Captures are Rendered on a four-screen display or a three-screen display is up to the Consumer to determine. The Consumer wants to place Video Captures from the same original source Endpoint together, in the correct spatial order, but the MCCs do not have spatial attributes. So, the Consumer needs to associate incoming Media packets with the original individual Captures in the Advertisement (such as VC4, VC5, and VC6) in order to know the spatial information it needs for correct placement on the screens. The Provider can use the RTCP CaptureId source description (SDES) item and associated RTP header extension, as described in [RFC8849], to convey this information to the Consumer.
エンドポイントBへの広告は、エンドポイントAからのキャプチャが追加され、エンドポイントBからのキャプチャが削除されること以外は上記と同じです。キャプチャが4画面表示または3画面表示でレンダリングされているか3画面表示が消費者になるのは決定します。消費者は、正しい空間順で、同じ元のソースエンドポイントからビデオキャプチャを同じ元のソースエンドポイントにまとめたいが、MCCSには空間属性がありません。したがって、消費者は、着信メディアパケットを、スクリーン上の正しい配置に必要な空間情報を知るために、広告の元の個々のキャプチャ（VC4、VC5、VC6など）に関連付ける必要があります。プロバイダは、[RFC8849]で説明されているように、RTCP CaptureIDソース記述（SDES）項目および関連RTPヘッダー拡張を使用して、この情報をコンシューマに伝えることができます。
This example illustrates how multipoint "voice-activated switching" behavior can be realized, with an Endpoint making its own decision about which of its outgoing video Streams is considered the "active talker" from that Endpoint. Then, an MCU can decide which is the active talker among the whole Conference.
この例では、そのエンドポイントのどちらの発信ビデオストリームがそのエンドポイントから「アクティブトークマ」と見なされるかについてのエンドポイントを独自の決定にすることで、マルチポイント「ボイスアクティブ化スイッチング」動作を実現できる方法を示します。その後、MCUは、会議全体の中でアクティブな話者であるかを決めることができます。
Consider a Conference between Endpoints with the following characteristics:
以下の特性を持つエンドポイント間の会議を検討してください。
Endpoint A - 3 screens, 3 cameras
エンドポイントA - 3スクリーン、3カメラ
Endpoint B - 3 screens, 3 cameras
エンドポイントB - 3スクリーン、3カメラ
Endpoint C - 1 screen, 1 camera
エンドポイントC - 1画面、1カメラ
This example focuses on what the user at Endpoint C sees. The user would like to see the Video Capture of the current talker, without composing it with any other Video Capture. In this example, Endpoint C is capable of receiving only a single video Stream. The following tables describe Advertisements from Endpoints A and B to the MCU, and from the MCU to Endpoint C, that can be used to accomplish this.
この例では、エンドポイントCのユーザーが何見るかに焦点を当てています。他のビデオキャプチャと一緒に構成することなく、ユーザーは現在のトーカのビデオキャプチャを見たいと思います。この例では、エンドポイントCは単一のビデオストリームのみを受信することができます。次の表は、エンドポイントAとBからMCUへの広告、およびMCUからエンドポイントCまでの広告を説明しています。
+===================+=========================+
| Capture Scene #1 | Description=Endpoint x |
+===================+=========================+
| VC1 | CaptureArea=Left |
| | EncodingGroup=1 |
+-------------------+-------------------------+
| VC2 | CaptureArea=Center |
| | EncodingGroup=1 |
+-------------------+-------------------------+
| VC3 | CaptureArea=Right |
| | EncodingGroup=1 |
+-------------------+-------------------------+
| MCC1(VC1,VC2,VC3) | MaxCaptures=1 |
| | CaptureArea=whole Scene |
| | Policy=SoundLevel:0 |
| | EncodingGroup=1 |
+-------------------+-------------------------+
| AC1 | CaptureArea=whole Scene |
| | EncodingGroup=2 |
+-------------------+-------------------------+
| CSV1(VC1, VC2, | |
| VC3) | |
+-------------------+-------------------------+
| CSV2(MCC1) | |
+-------------------+-------------------------+
| CSV3(AC1) | |
+-------------------+-------------------------+
Table 25: Advertisement Received at the MCU from Endpoints A and B
表25：エンドポイントAとBからMCUで受信された広告
Endpoints A and B are advertising each individual Video Capture, and also a switched Capture MCC1 that switches between the other three based on who is the active talker. These Endpoints do not advertise distinct Audio Captures associated with each individual Video Capture, so it would be impossible for the MCU (as a Media Consumer) to make its own determination of which Video Capture is the active talker based just on information in the audio Streams.
エンドポイントAとBは、各個々のビデオキャプチャ、およびアクティブトーカーであるWHOが誰であるかをベースにした他の3つを切り替える切り替えキャプチャMCC1も広告しています。これらのエンドポイントは、各個々のビデオキャプチャに関連する異なるオーディオキャプチャをアドバタイズしていないため、（メディアコンシューマとして）MCUがオーディオストリーム内の情報だけに基づいてアクティブトーカーのどのビデオキャプチャーであるかを独自の決定にすることは不可能です。。
+======================+========================+
| Capture Scene #1 | Description=conference |
+======================+========================+
| MCC1() | CaptureArea=Left |
| | MaxCaptures=1 |
| | SynchronizationID=1 |
| | Policy=SoundLevel:0 |
| | EncodingGroup=1 |
+----------------------+------------------------+
| MCC2() | CaptureArea=Center |
| | MaxCaptures=1 |
| | SynchronizationID=1 |
| | Policy=SoundLevel:0 |
| | EncodingGroup=1 |
+----------------------+------------------------+
| MCC3() | CaptureArea=Right |
| | MaxCaptures=1 |
| | SynchronizationID=1 |
| | Policy=SoundLevel:0 |
| | EncodingGroup=1 |
+----------------------+------------------------+
| MCC4() | CaptureArea=whole |
| | Scene |
| | MaxCaptures=1 |
| | Policy=SoundLevel:0 |
| | EncodingGroup=1 |
+----------------------+------------------------+
| MCC5() (for audio) | CaptureArea=whole |
| | Scene |
| | MaxCaptures=1 |
| | Policy=SoundLevel:0 |
| | EncodingGroup=2 |
+----------------------+------------------------+
| MCC6() (for audio) | CaptureArea=whole |
| | Scene |
| | MaxCaptures=1 |
| | Policy=SoundLevel:1 |
| | EncodingGroup=2 |
+----------------------+------------------------+
| CSV1(MCC1,MCC2,MCC3) | |
+----------------------+------------------------+
| CSV2(MCC4) | |
+----------------------+------------------------+
| CSV3(MCC5,MCC6) | |
+----------------------+------------------------+
Table 26: Advertisement Sent from the MCU to Endpoint C
表26：MCUからエンドポイントCに送信された広告
The MCU advertises one Scene, with four video MCCs. Three of them in CSV1 give a left, center, and right view of the Conference, with site switching. MCC4 provides a single Video Capture representing a view of the whole Conference. The MCU intends for MCC4 to be switched between all the other original source Captures. In this example, Advertisement of the MCU is not giving all the information about all the other Endpoints' Scenes and which of those Captures are included in the MCCs. The MCU could include all that if it wants to give the Consumers more information, but it is not necessary for this example scenario.
MCUは4つのビデオMCCで1つのシーンを宣伝します。そのうちの3つはCSV1で3つの会議の左側、中央、右側のビューを備えています。MCC4は、会議全体のビューを表す単一のビデオキャプチャを提供します。MCUは、MCC4が他のすべての元のソースキャプチャ間で切り替えることを意図しています。この例では、MCUの広告は他のすべてのエンドポイントのシーンに関するすべての情報を提供していて、これらのキャプチャがMCCSに含まれています。MCUには、消費者にもっと情報を与えたいのであれば、この例のシナリオには必要ありません。
The Provider advertises MCC5 and MCC6 for audio. Both are switched Captures, with different SoundLevel policies indicating they are the top two dominant talkers. The Provider advertises CSV3 with both MCCs, suggesting the Consumer should use both if it can.
プロバイダはMCC5とMCC6をオーディオのためにアドバタイズします。どちらも切り替えられたキャプチャーで、さまざまなSoundLevelポリシーがあり、それらが上位2つの支配的な話者です。プロバイダはCSV3を両方のMCCSでアドバタイズし、消費者が可能な場合は両方を使用する必要があります。
Endpoint C, in its Configure Message to the MCU, requests to receive MCC4 for video and MCC5 and MCC6 for audio. In order for the MCU to get the information it needs to construct MCC4, it has to send Configure Messages to Endpoints A and B asking to receive MCC1 from each of them, along with their AC1 audio. Now the MCU can use audio energy information from the two incoming audio Streams from Endpoints A and B to determine which of those alternatives is the current talker. Based on that, the MCU uses either MCC1 from A or MCC1 from B as the source of MCC4 to send to Endpoint C.
Endpoint CはMCUへの設定メッセージ内で、ビデオとMCC5、およびMCC6のためのMCC4を受信するように要求します。MCUがMCC4を構成するために必要な情報を取得するためには、それぞれのAC1オーディオとともに、それらのそれぞれからMCC1を受信するように依頼しているエンドポイントAおよびBにメッセージを送信する必要があります。MCUは、エンドポイントAおよびBからの2つの入力オーディオストリームからオーディオエネルギー情報を使用して、どの選択肢が現在のトークマであるかを判断できます。それに基づいて、MCUはMCC4のソースとしてAまたはMCC1からMCC1を使用して、エンドポイントCに送信する。
This document has no IANA actions.
この文書にはIANAの行動がありません。
There are several potential attacks related to telepresence, specifically the protocols used by CLUE. This is the case due to conferencing sessions, the natural involvement of multiple Endpoints, and the many, often user-invoked, capabilities provided by the systems.
テレプレゼンス、特にCLUEによって使用されるプロトコルに関連するいくつかの攻撃がいくつかあります。これは、会議セッション、複数のエンドポイントの自然な関与、およびシステムによって提供される多くの場合、ユーザーが呼び出された多くの機能による場合です。
An MCU involved in a CLUE session can experience many of the same attacks as a conferencing system such as the one enabled by the Conference Information Data Model for Centralized Conferencing (XCON) framework [RFC5239]. Examples of attacks include the following: an Endpoint attempting to listen to sessions in which it is not authorized to participate, an Endpoint attempting to disconnect or mute other users, and theft of service by an Endpoint in attempting to create telepresence sessions it is not allowed to create. Thus, it is RECOMMENDED that an MCU implementing the protocols necessary to support CLUE follow the security recommendations specified in the conference control protocol documents. In the case of CLUE, SIP is the conferencing protocol, thus the security considerations in [RFC4579] MUST be followed. Other security issues related to MCUs are discussed in the XCON framework [RFC5239]. The use of xCard with potentially sensitive information provides another reason to implement recommendations in Section 11 of [RFC5239].
手がかりセッションに関わるMCUは、集中会議（XCON）フレームワーク[RFC5239]の会議情報データモデルによって有効になっている会議システムと同じ攻撃の多くを経験することができます。攻撃の例は次のとおりです。作成する。したがって、Chyueをサポートするのに必要なプロトコルを実装することをお勧めします。会議管理プロトコル文書で指定されているセキュリティ推奨事項に従ってください。手がかりの場合、SIPは会議プロトコルであるため、[RFC4579]のセキュリティ上の考慮事項に従う必要があります。 MCUに関連するその他のセキュリティ問題は、XCON Framework [RFC5239]で説明されています。潜在的に敏感な情報を持つXcardの使用は[RFC5239]のセクション11で推奨事項を実装するもう1つの理由を提供します。
One primary security concern, surrounding the CLUE framework introduced in this document, involves securing the actual protocols and the associated authorization mechanisms. These concerns apply to Endpoint-to-Endpoint sessions as well as sessions involving multiple Endpoints and MCUs. Figure 2 in Section 5 provides a basic flow of information exchange for CLUE and the protocols involved.
この文書で導入された手がかりフレームワークを取り巻く1つの主なセキュリティ上の問題は、実際のプロトコルと関連する許可メカニズムを保護することを含む。これらの懸念は、エンドポイント間エンドポイントセッション、複数のエンドポイントとMCUを含むセッションに適用されます。セクション5の図2は、手がかりおよび関係するプロトコルのための情報交換の基本的な流れを提供する。
As described in Section 5, CLUE uses SIP/SDP to establish the session prior to exchanging any CLUE-specific information. Thus, the security mechanisms recommended for SIP [RFC3261], including user authentication and authorization, MUST be supported. In addition, the Media MUST be secured. Datagram Transport Layer Security (DTLS) / Secure Real-time Transport Protocol (SRTP) MUST be supported and SHOULD be used unless the Media, which is based on RTP, is secured by other means (see [RFC7201] [RFC7202]). Media security is also discussed in [RFC8848] and [RFC8849]. Note that SIP call setup is done before any CLUE-specific information is available, so the authentication and authorization are based on the SIP mechanisms. The entity that will be authenticated may use the Endpoint identity or the Endpoint user identity; this is an application issue and not a CLUE-specific issue.
セクション5で説明されているように、ClueはSIP / SDPを使用して、手がかり固有の情報を交換する前にセッションを確立します。したがって、ユーザー認証と許可を含むSIP [RFC3261]に推奨されているセキュリティメカニズムをサポートする必要があります。さらに、媒体は固定されなければなりません。データグラムトランスポートレイヤセキュリティ（DTLS）/セキュアリアルタイムトランスポートプロトコル（SRTP）は、RTPに基づくメディアが他の手段によって保護されていない限り、サポートされている必要があります（[RFC7201] [RFC7202]を参照）。メディアセキュリティについても[RFC8848]および[RFC8849]で説明します。SIP呼び出し設定は、CLUE固有の情報が利用可能な前に行われるため、認証と許可はSIPメカニズムに基づいています。認証されるエンティティは、エンドポイントIDまたはエンドポイントユーザーIDを使用することができます。これはアプリケーションの問題であり、手がかり固有の問題ではありません。
A separate data channel is established to transport the CLUE protocol messages. The contents of the CLUE protocol messages are based on information introduced in this document. The CLUE data model [RFC8846] defines, through an XML schema, the syntax to be used. One type of information that could possibly introduce privacy concerns is the xCard information, as described in Section 7.1.1.10. The decision about which xCard information to send in the CLUE channel is an application policy for point-to-point and multipoint calls based on the authenticated identity that can be the Endpoint identity or the user of the Endpoint. For example, the telepresence multipoint application can authenticate a user before starting a CLUE exchange with the telepresence system and have a policy per user.
手がかりプロトコルメッセージを転送するために別のデータチャネルが確立されます。手がかりプロトコルメッセージの内容は、この文書で導入された情報に基づいています。CLUEデータモデル[RFC8846]は、XMLスキーマを介して、使用される構文を定義します。セクション7.1.1.10で説明されているように、プライバシーに関する懸念を導入する可能性がある1種類の情報は、XCard情報です。Clueチャネルで送信するXCARD情報に関する決定は、エンドポイントIDまたはエンドポイントのユーザーになることができる認証されたIDに基づくポイントツーポイントとマルチポイントコールのアプリケーションポリシーです。たとえば、TelePresenceマルチポイントアプリケーションは、TelePresenceシステムとのCLUE交換を開始する前にユーザーを認証し、ユーザーごとにポリシーを持つことができます。
In addition, the (text) description field in the Media Capture attribute (Section 7.1.1.6) could possibly reveal sensitive information or specific identities. The same would be true for the descriptions in the Capture Scene (Section 7.3.1) and CSV (Section 7.3.2) attributes. An implementation SHOULD give users control over what sensitive information is sent in an Advertisement. One other important consideration for the information in the xCard as well as the description field in the Media Capture and CSV attributes is that while the Endpoints involved in the session have been authenticated, there are no assurance that the information in the xCard or description fields is authentic. Thus, this information MUST NOT be used to make any authorization decisions.
さらに、メディアキャプチャ属性（セクション7.1.1.6）の（テキスト）記述フィールド（セクション7.1.1.6）は、機密情報または特定のIDを明らかにする可能性があります。Capture Scene（7.3.1項）およびCSV（7.3.2節）の属性の説明については、同じことが当てはまります。実装は、広告でどの機密情報が送信されるかをユーザーに制御する必要があります。Xcardの情報に関する他の重要な考慮事項およびメディアキャプチャとCSV属性の説明フィールドは、セッションに関わるエンドポイントが認証されているが、XcardまたはDescriptionフィールドの情報があるという保証はありません。本物の。したがって、この情報は許可の決定を下すために使用してはいけません。
While other information in the CLUE protocol messages does not reveal specific identities, it can reveal characteristics and capabilities of the Endpoints. That information could possibly uniquely identify specific Endpoints. It might also be possible for an attacker to manipulate the information and disrupt the CLUE sessions. It would also be possible to mount a DoS attack on the CLUE Endpoints if a malicious agent has access to the data channel. Thus, it MUST be possible for the Endpoints to establish a channel that is secure against both message recovery and message modification. Further details on this are provided in the CLUE data channel solution document [RFC8850].
手がかりプロトコルメッセージ内の他の情報は特定のIDを明らかにしないが、エンドポイントの特性と機能を明らかにすることができます。その情報はおそらく特定のエンドポイントを一意に識別することができます。攻撃者が情報を操作し、手がかりセッションを混乱させることも可能であるかもしれません。悪意のあるエージェントがデータチャネルにアクセスできる場合は、手がかりエンドポイントにDOS攻撃をマウントすることも可能です。したがって、エンドポイントが、メッセージの回復とメッセージの変更の両方に対して安全なチャネルを確立することが可能でなければなりません。これについての詳細は、手がかりデータチャネルソリューション文書[RFC8850]に提供されています。
There are also security issues associated with the authorization to perform actions at the CLUE Endpoints to invoke specific capabilities (e.g., rearranging screens, sharing content, etc.). However, the policies and security associated with these actions are outside the scope of this document and the overall CLUE solution.
手がかりエンドポイントでアクションを実行して、特定の機能を実行して、特定の機能を実行して、特定の機能を実行するための承認に関連するセキュリティ問題もあります（たとえば、画面を並べ替え、コンテンツの共有など）。ただし、これらのアクションに関連するポリシーとセキュリティは、この文書の範囲外と全体的な手がかりソリューションです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https：//ww.rfc-editor.org/ info / rfc3264>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]ハンドリー、M.、Jacobson、V.、およびC.Perkins、「SDP：セッション記述プロトコル」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https：//www.rfc-editor.org/情報/ RFC4566>。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006, <https://www.rfc-editor.org/info/rfc4579>.
[RFC4579] Johnston、A.およびO. Levin、「セッション開始プロトコル（SIP）コール制御 - ユーザーエージェントの会議」、BCP 119、RFC 4579、DOI 10.17487 / RFC4579、2006年8月、<https：//www.rfc-editor.org/info/rfc4579>。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008, <https://www.rfc-editor.org/info/rfc5239>.
[RFC5239] Barnes、M.、Boulton、C.、O. Levin、「集中会議のためのフレームワーク」、RFC 5239、DOI 10.17487 / RFC5239、2008年6月、<https：//www.rfc-editor.org/情報/ RFC5239>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646] Phillips、A.、ED。そして、「言語を特定するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<https：//www.rfc-editor.org/info/rfc5646>。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/info/rfc6350>.
[RFC6350] PerreAll、S.、 "VCard Format Specification"、RFC 6350、DOI 10.17487 / RFC6350、2011年8月、<https：//www.rfc-editor.org/info/rfc6350>。
[RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011, <https://www.rfc-editor.org/info/rfc6351>.
[RFC6351] PerreAll、S.、 "Xcard：Vcard XML表現"、RFC 6351、DOI 10.17487 / RFC6351、2011年8月、<https://www.rfc-editor.org/info/rfc6351>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8846] Presta, R. and S P. Romano, "An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model", RFC 8846, DOI 10.17487/RFC8846, January 2021, <http://www.rfc-editor.org/info/rfc8846>.
[RFC8846] Presta、R.およびS P. Romano、 "TelePresence（Clue）データモデルのための複数のストリームのためのXMLスキーマ"、RFC 8846、DOI 10.17487 / RFC8846、2021年1月、<http：//ww.rfc-editor.org/info/rfc8846>。
[RFC8847] Presta, R. and S P. Romano, "Protocol for Controlling Multiple Streams for Telepresence (CLUE)", RFC 8847, DOI 10.17487/RFC8847, January 2021, <https://www.rfc-editor.org/info/rfc8847>.
[RFC8847] Presta、R.およびS P. Romano、「テレプレゼンスのための複数のストリームを制御するためのプロトコル（CLUE）」、RFC 8847、DOI 10.17487 / RFC8847、2021年1月、<https：//www.rfc-editor.org/情報/ RFC8847>。
[RFC8848] Hanton, R., Kyzivat, P., Xiao, L., and C. Groves, "Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)", RFC 8848, DOI 10.17487/RFC8848, January 2021, <https://www.rfc-editor.org/info/rfc8848>.
[RFC8848]ハントン、R。、KYZIVAT、P.、Xiao、L.、およびC.グローブ、「テレプレゼンスのための複数のストリームを制御するためのセッションシグナリング（CLUE）」、RFC 8848、DOI 10.17487 / RFC8848、<HTTPS//www.rfc-editor.org/info/rfc8848>。
[RFC8850] Holmberg, C., "Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel", RFC 8850, DOI 10.17487/RFC8850, January 2021, <https://www.rfc-editor.org/info/rfc8850>.
[RFC8850] Holmberg、C、「テレプレゼンスのための複数のストリームの制御」、RFC 8850、DOI 10.17487 / RFC8850、1月2021年1月、<https：//www.rfc-editor.org/info/rfc8850>。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <https://www.rfc-editor.org/info/rfc4353>.
[RFC4353] Rosenberg、J。、「セッション開始プロトコル（SIP）」、RFC 4353、DOI 10.17487 / RFC4353、<https://www.rfc-editor.org/info/rfc4353との会議のためのフレームワーク>。
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <https://www.rfc-editor.org/info/rfc7201>.
[RFC7201] Westerlund、M.およびC. Perkins、RFC 7201、DOI 10.17487 / RFC7201、2014年4月、<https://www.rfc-editor.org/info/rfc7201>。
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014, <https://www.rfc-editor.org/info/rfc7202>.
[RFC7202] Perkins、C、M.Westerlund、「RTPフレームワークの確保：なぜRTPは、なぜ単一のメディアセキュリティソリューションを義務付けていないのか」、RFC 7202、DOI 10.17487 / RFC7202、2014年4月、<https：//www.rfc-editor.org/info/rfc7202>。
[RFC7205] Romanow, A., Botzko, S., Duckworth, M., and R. Even, Ed., "Use Cases for Telepresence Multistreams", RFC 7205, DOI 10.17487/RFC7205, April 2014, <https://www.rfc-editor.org/info/rfc7205>.
[RFC7205] Romanow、A.、Botzko、S.、Duckworth、M.、およびR.さえ、ED。、「テレプレゼンスマルチストリームのユースケース」、RFC 7205、DOI 10.17487 / RFC7205、2014年4月、<https：//www.rfc-editor.org/info/rfc7205>。
[RFC7262] Romanow, A., Botzko, S., and M. Barnes, "Requirements for Telepresence Multistreams", RFC 7262, DOI 10.17487/RFC7262, June 2014, <https://www.rfc-editor.org/info/rfc7262>.
[RFC7262] Romanow、A.、Botzko、S.、M. Barnes、「TelePresence Multistreamsの要件」、RFC 7262、DOI 10.17487 / RFC7262、2014年6月、<https：//www.rfc-editor.org/info/ RFC7262>。
[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <https://www.rfc-editor.org/info/rfc7667>.
[RFC7667] Westerlund、M.およびS.Wenger、 "RTPトポロジ"、RFC 7667、DOI 10.17487 / RFC7667、2015年11月、<https：//www.rfc-editor.org/info/rfc7667>。
[RFC8849] Even, R. and J. Lennox, "Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures", RFC 8849, DOI 10.17487/RFC8849, January 2021, <https://www.rfc-editor.org/info/rfc8849>.
[RFC8849]偶数、R.およびJ.Lennox、「TelePresence（Clue）メディアキャプチャのための複数のストリームを制御するためのRTPストリームのマッピング」、RFC 8849、DOI 10.17487 / RFC8849、2021年1月、<https：///www.rfc-編集者.ORG / INFO / RFC8849>。
Acknowledgements
謝辞
Allyn Romanow and Brian Baldino were authors of early draft versions. Mark Gorzynski also contributed much to the initial approach. Many others also contributed, including Christian Groves, Jonathan Lennox, Paul Kyzivat, Rob Hanton, Roni Even, Christer Holmberg, Stephen Botzko, Mary Barnes, John Leslie, and Paul Coverdale.
Allyn RomanowとBrian Baldinoは早期ドラフトバージョンの著者でした。Mark Gorzynskiはまた、最初のアプローチに大きな貢献しました。また、キリスト教の畑、Jonathan Lennox、Paul Kyzivat、Rob Hanton、Roniさえ、Christer Holmberg、Stephen Botzko、Mary Barnes、John Leslie、Paul Coverdaleなど、貢献しました。
Authors' Addresses
著者の住所
Mark Duckworth (editor)
マークダックワース（編集）
Email: mrducky73@outlook.com
Andrew Pepperell Acano Uxbridge United Kingdom
Andrew Pepperell Acano Uxブリッジイギリス
Email: apeppere@gmail.com
Stephan Wenger Tencent 2747 Park Blvd. Palo Alto, CA 94306 United States of America
ステファンウェンガーTencent 2747 Park Blvd。Palo Alto、CA 94306アメリカ合衆国
Email: stewe@stewe.org