[要約] RFC 7262は、テレプレゼンスのマルチストリームに関する要件を定義しています。その目的は、高品質なテレプレゼンス体験を提供するために、複数のストリームを同時に処理するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) A. Romanow
Request for Comments: 7262 Cisco Systems
Category: Informational S. Botzko
ISSN: 2070-1721 Polycom
M. Barnes
MLB@Realtime Communications, LLC
June 2014
Requirements for Telepresence Multistreams
TelePresence Multistreamsの要件
Abstract
概要
This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein.
このメモは、テレプレゼンス（CLUE）の複数のストリームを制御するための動作とプロトコルを説明することにより、テレプレゼンスの相互運用を可能にする仕様の要件について説明します。さらに、問題の説明と関連する定義もここに含まれます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7262.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7262で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Informative References . . . . . . . . . . . . . . . . . . . 11
Telepresence systems greatly improve collaboration. In a telepresence conference (as used herein), the goal is to create an environment that gives the users a feeling of (co-located) presence -- the feeling that a local user is in the same room with other local users and remote parties. Currently, systems from different vendors often do not interoperate because they do the same tasks differently, as discussed in the Problem Statement section below (see Section 4).
テレプレゼンスシステムはコラボレーションを大幅に改善します。 （ここで使用する）テレプレゼンス会議では、目標は、ユーザーに（同じ場所に配置された）プレゼンス（ローカルユーザーが他のローカルユーザーやリモートパーティーと同じ部屋にいるような感覚）を感じさせる環境を作ることです。現在、異なるベンダーのシステムは、以下の「問題の説明」セクション（セクション4を参照）で説明されているように、同じタスクを異なる方法で実行するため、相互運用できないことがよくあります。
The approach taken in this memo is to set requirements for a future specification(s) that, when fulfilled by an implementation of the specification(s), provide for interoperability between IETF protocol-based telepresence systems. It is anticipated that a solution for the requirements set out in this memo likely involves the exchange of adequate information about participating sites; this information that is currently not standardized by the IETF.
このメモで採用されているアプローチは、仕様の実装によって満たされると、IETFプロトコルベースのテレプレゼンスシステム間の相互運用性を提供する将来の仕様の要件を設定することです。このメモに記載されている要件の解決策には、参加サイトに関する適切な情報の交換が含まれる可能性が高いと予想されます。現在IETFによって標準化されていないこの情報。
The purpose of this document is to describe the requirements for a specification that enables interworking between different SIP-based [RFC3261] telepresence systems, by exchanging and negotiating appropriate information. In the context of the requirements in this document and related solution documents, this includes both point-to-point SIP sessions as well as SIP-based conferences as described in the SIP conferencing framework [RFC4353] and the SIP-based conference control [RFC4579] specifications. Non-IETF protocol-based systems, such as those based on ITU-T Rec. H.323 [ITU.H323], are out of scope. These requirements are for the specification, they are not requirements on the telepresence systems implementing the solution/ protocol that will be specified.
このドキュメントの目的は、適切な情報を交換および交渉することにより、異なるSIPベースの[RFC3261]テレプレゼンスシステム間の相互作用を可能にする仕様の要件を説明することです。このドキュメントおよび関連するソリューションドキュメントの要件に関連して、これには、ポイントツーポイントのSIPセッションとSIPベースの会議の両方が含まれます。これは、SIP会議フレームワーク[RFC4353]およびSIPベースの会議制御[RFC4579]で説明されています。 】仕様。 ITU-T Rec。に基づくシステムなどの非IETFプロトコルベースのシステムH.323 [ITU.H323]は範囲外です。これらの要件は仕様に対するものであり、指定されるソリューション/プロトコルを実装するテレプレゼンスシステムに対する要件ではありません。
Today, telepresence systems of different vendors can follow radically different architectural approaches while offering a similar user experience. CLUE will not dictate telepresence architectural and implementation choices; however, it will describe a protocol architecture for CLUE and how it relates to other protocols. CLUE enables interoperability between telepresence systems by exchanging information about the systems' characteristics. Systems can use this information to control their behavior to allow for interoperability between those systems.
今日、異なるベンダーのテレプレゼンスシステムは、同様のユーザーエクスペリエンスを提供しながら、根本的に異なるアーキテクチャアプローチに従うことができます。 CLUEはテレプレゼンスのアーキテクチャと実装の選択を指示しません。ただし、CLUEのプロトコルアーキテクチャと、それが他のプロトコルとどのように関連するかについて説明します。 CLUEは、システムの特性に関する情報を交換することにより、テレプレゼンスシステム間の相互運用を可能にします。システムはこの情報を使用して動作を制御し、それらのシステム間の相互運用を可能にすることができます。
A telepresence session requires at least one sending and one receiving endpoint. Multiparty telepresence sessions include more than 2 endpoints and centralized infrastructure such as Multipoint Control Units (MCUs) or equivalent. CLUE specifies the syntax, semantics, and control flow of information to enable the best possible user experience at those endpoints.
テレプレゼンスセッションには、少なくとも1つの送信エンドポイントと1つの受信エンドポイントが必要です。マルチパーティテレプレゼンスセッションには、2つを超えるエンドポイントと、マルチポイントコントロールユニット（MCU）などの集中インフラストラクチャが含まれます。 CLUEは、情報の構文、セマンティクス、および制御フローを指定して、これらのエンドポイントで可能な限り最高のユーザーエクスペリエンスを実現します。
Sending endpoints, or MCUs, are not mandated to use any of the CLUE specifications that describe their capabilities, attributes, or behavior. Similarly, it is not envisioned that endpoints or MCUs will ever have to take information received into account. However, by making available as much information as possible, and by taking into account as much information as has been received or exchanged, MCUs and endpoints are expected to select operation modes that enable the best possible user experience under their constraints.
送信エンドポイント、つまりMCUは、それらの機能、属性、または動作を説明するCLUE仕様を使用するように義務付けられていません。同様に、エンドポイントまたはMCUが受信した情報を考慮に入れる必要があることは想定されていません。ただし、MCUとエンドポイントは、できるだけ多くの情報を利用できるようにし、受信または交換された情報を考慮に入れることにより、制約の下で可能な限り最高のユーザーエクスペリエンスを実現する操作モードを選択することが期待されます。
The document structure is as follows: definitions are set out, followed by a description of the problem of telepresence interoperability that led to this work. Then the requirements for a specification addressing the current shortcomings are enumerated and discussed.
ドキュメントの構造は次のとおりです。定義が設定され、この作業につながったテレプレゼンスの相互運用性の問題の説明が続きます。次に、現在の欠点に対処する仕様の要件を列挙して説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The following terms are used throughout this document and serve as a reference for other documents.
次の用語は、このドキュメント全体で使用され、他のドキュメントのリファレンスとして機能します。
Audio Mixing: refers to the accumulation of scaled audio signals to produce a single audio stream. See "RTP Topologies" [RFC5117].
オーディオミキシング：スケーリングされたオーディオ信号を蓄積して単一のオーディオストリームを生成することを指します。 「RTPトポロジ」[RFC5117]を参照してください。
Conference: used as defined in "A Framework for Conferencing within the Session Initiation Protocol (SIP)" [RFC4353].
会議：「セッション開始プロトコル（SIP）内の会議のフレームワーク」[RFC4353]で定義されているとおりに使用されます。
Endpoint: 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 participant [RFC4353] (which, in turn, includes exactly one SIP user agent). In contrast to an endpoint, an MCU may also send and receive media streams, but it is not the initiator or the final terminator in the sense that media is captured or rendered. Endpoints can be anything from multiscreen/multicamera rooms to handheld devices.
エンドポイント：メディアストリームのキャプチャ、エンコード、送信による受信、デコード、レンダリング、および/または開始による最終的な終了の論理的なポイント。エンドポイントは、メディアストリームをソースおよびシンクする1つ以上の物理デバイスと、1人の参加者[RFC4353]（順番に1人のSIPユーザーエージェントを含む）で構成されます。エンドポイントとは対照的に、MCUはメディアストリームを送受信することもありますが、メディアがキャプチャまたはレンダリングされるという意味では、イニシエーターや最終ターミネーターではありません。エンドポイントは、マルチスクリーン/マルチカメラルームからハンドヘルドデバイスまで何でもかまいません。
Endpoint Characteristics: include placement of capture and rendering devices, capture/render angle, resolution of cameras and screens, spatial location, and mixing parameters of microphones. Endpoint characteristics are not specific to individual media streams sent by the endpoint.
エンドポイントの特性：キャプチャおよびレンダリングデバイスの配置、キャプチャ/レンダリングの角度、カメラと画面の解像度、空間位置、およびマイクのミキシングパラメーターが含まれます。エンドポイントの特性は、エンドポイントによって送信される個々のメディアストリームに固有のものではありません。
Layout: How rendered media streams are spatially arranged with respect to each other on a telepresence endpoint with a single screen and a single loudspeaker, and how rendered media streams are arranged with respect to each other on a telepresence endpoint with multiple screens or loudspeakers. Note that audio as well as video are encompassed by the term layout -- in other words, included is the placement of audio streams on loudspeakers as well as video streams on video screens.
レイアウト：レンダリングされたメディアストリームが、1つの画面と1つのスピーカーを備えたテレプレゼンスエンドポイントで互いに空間的に配置される方法と、レンダリングされたメディアストリームが、複数の画面またはスピーカーを備えたテレプレゼンスエンドポイントで互いにどのように配置されるか。オーディオだけでなくビデオもレイアウトという用語に含まれることに注意してください。言い換えると、スピーカーのオーディオストリームとビデオ画面のビデオストリームの配置が含まれます。
Local: Sender and/or receiver physically co-located ("local") in the context of the discussion.
ローカル：ディスカッションのコンテキストで送信者または受信者、あるいはその両方が物理的に同じ場所（「ローカル」）に配置されます。
MCU: Multipoint Control Unit (MCU) - a device that connects two or more endpoints together into one single multimedia conference [RFC5117]. An MCU may include a mixer [RFC4353].
MCU：マルチポイントコントロールユニット（MCU）-2つ以上のエンドポイントを1つのマルチメディア会議[RFC5117]に接続するデバイス。 MCUはミキサ[RFC4353]を含む場合があります。
Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, video, or timed text.
メディア：オーディオ、ビデオ、または時間指定されたテキストを含む、適切なエンコーディング後にRTPを介して伝達できるデータ。
Model: a set of assumptions a telepresence system of a given vendor adheres to and expects the remote telepresence system(s) to also adhere to.
モデル：特定のベンダーのテレプレゼンスシステムが準拠し、リモートテレプレゼンスシステムも準拠することを期待する一連の仮定。
Remote: Sender and/or receiver on the other side of the communication channel (depending on context); i.e., not local. A remote can be an endpoint or an MCU.
リモート：コンテキストに応じて、通信チャネルの反対側にある送信側および/または受信側。つまり、ローカルではありません。リモートは、エンドポイントまたはMCUにすることができます。
Render: the process of generating a representation from a media, such as displayed motion video or sound emitted from loudspeakers.
レンダリング：表示されたモーションビデオやスピーカーから発せられる音など、メディアから表現を生成するプロセス。
Telepresence: an environment that gives non-co-located users or user groups a feeling of (co-located) presence -- the feeling that a local user is in the same room with other local users and the remote parties. The inclusion of Remote parties is achieved through multimedia communication including at least audio and video signals of high fidelity.
テレプレゼンス：同じ場所に配置されていないユーザーまたはユーザーグループに、（同じ場所に配置された）存在感-ローカルユーザーが他のローカルユーザーやリモートパーティと同じ部屋にいるような感覚を与える環境。リモートパーティを含めるには、少なくとも忠実度の高いオーディオ信号とビデオ信号を含むマルチメディア通信を使用します。
In order to create a "being there" experience characteristic of telepresence, media inputs need to be transported, received, and coordinated between participating systems. Different telepresence systems take diverse approaches in crafting a solution, or they implement similar solutions quite differently.
テレプレゼンスに特徴的な「存在」体験を生み出すためには、参加システム間でメディア入力を転送、受信、調整する必要があります。異なるテレプレゼンスシステムは、ソリューションを作成する際にさまざまなアプローチをとるか、または同様のソリューションをまったく異なる方法で実装します。
They use disparate techniques, and they describe, control and negotiate media in dissimilar fashions. Such diversity creates an interoperability problem. The same issues are solved in different ways by different systems, so that they are not directly interoperable. This makes interworking difficult at best and sometimes impossible.
彼らは異なる手法を使用し、メディアを異なる方法で記述、制御、交渉します。このような多様性は相互運用性の問題を引き起こします。同じ問題は異なるシステムによって異なる方法で解決されるため、直接相互運用できません。これにより、インターワークはせいぜい困難になり、時には不可能になります。
Worse, even if those extensions are based on common standards such as SIP, many telepresence systems use proprietary protocol extensions to solve telepresence-related problems.
さらに悪いことに、これらの拡張がSIPなどの一般的な標準に基づいている場合でも、多くのテレプレゼンスシステムは独自のプロトコル拡張を使用してテレプレゼンス関連の問題を解決します。
Some degree of interworking between systems from different vendors is possible through transcoding and translation. This requires additional devices, which are expensive, are often not entirely automatic, and sometimes introduce unwelcome side effects, such as additional delay or degraded performance. Specialized knowledge is currently required to operate a telepresence conference with endpoints from different vendors, for example to configure transcoding and translating devices. Often such conferences do not start as planned or are interrupted by difficulties that arise.
トランスコーディングと変換により、異なるベンダーのシステム間のある程度の相互作用が可能になります。これには、高価で多くの場合完全に自動化されていない追加のデバイスが必要であり、追加の遅延やパフォーマンスの低下などの望ましくない副作用が生じる場合があります。現在、トランスコーディングデバイスや翻訳デバイスの設定など、さまざまなベンダーのエンドポイントとテレプレゼンス会議を運用するには、専門知識が必要です。多くの場合、このような会議は予定どおりに開始されないか、発生した問題によって中断されます。
The general problem that needs to be solved can be described as follows. Today, each endpoint renders the audio and video captures it receives according to an implicitly assumed model that stipulates how to produce a realistic depiction of the remote location. If all endpoints are manufactured by the same vendor, they all share the same implicit model and render the received captures correctly. However, if the devices are from different vendors, the models used for rendering presence can and usually do differ. The result can be that the telepresence systems actually connect, but the user experience will suffer, for example one system assumes that the first video stream is captured from the right camera, whereas the other assumes the first video stream is captured from the left camera.
解決する必要がある一般的な問題は、次のように説明できます。今日、各エンドポイントは、リモートロケーションの現実的な描写を生成する方法を規定する暗黙的に想定されたモデルに従って、受信するオーディオおよびビデオキャプチャをレンダリングします。すべてのエンドポイントが同じベンダーによって製造されている場合、それらはすべて同じ暗黙モデルを共有し、受信したキャプチャを正しくレンダリングします。ただし、デバイスが異なるベンダーのものである場合、プレゼンスのレンダリングに使用されるモデルは異なる場合があり、通常は異なります。その結果、テレプレゼンスシステムは実際に接続されますが、ユーザーエクスペリエンスは低下します。たとえば、1つのシステムは最初のビデオストリームが右カメラからキャプチャされると想定し、もう1つのシステムは最初のビデオストリームが左カメラからキャプチャされると想定します。
If Alice and Bob are at different sites, Alice needs to tell Bob about the camera and sound equipment arrangement at her site so that Bob's receiver can create an accurate rendering of her site. Alice and Bob need to agree on what the salient characteristics are as well as how to represent and communicate them. Characteristics may include number, placement, capture/render angle, resolution of cameras and screens, spatial location, and audio mixing parameters of microphones.
アリスとボブが別々のサイトにいる場合、ボブのレシーバーが自分のサイトの正確なレンダリングを作成できるように、アリスはボブに自分のサイトでのカメラと音響機器の配置について知らせる必要があります。アリスとボブは、顕著な特徴とは何か、またそれらをどのように表現して伝えるかについて合意する必要があります。特性には、数、配置、キャプチャ/レンダリングの角度、カメラと画面の解像度、空間位置、およびマイクのオーディオミキシングパラメータが含まれます。
The telepresence multistream work seeks to describe the sender situation in a way that allows the receiver to render it realistically even though it may have a different rendering model than the sender.
テレプレゼンスマルチストリーム作業は、送信者とは異なるレンダリングモデルを使用している場合でも、受信者が現実的にレンダリングできるように送信者の状況を説明しようとします。
Although some aspects of these requirements can be met by existing technology, such as the Session Description Protocol (SDP) [RFC4566], they are stated here to have a complete record of the requirements for CLUE. Determining whether a requirement needs new work or not will be part of the solution development, and is not discussed in this document. Note that the term "solution" is used in these requirements to mean the protocol specifications, including extensions to existing protocols as well as any new protocols, developed to support the use cases. The solution might introduce additional functionality that is not mapped directly to these requirements; e.g., the detailed information carried in the signaling protocol(s). In cases where the requirements are directly relevant to specific use cases as described in [RFC7205], a reference to the use case is provided.
これらの要件の一部の側面は、Session Description Protocol（SDP）[RFC4566]などの既存のテクノロジーで満たすことができますが、CLUEの要件の完全な記録があるとここで説明されています。要件に新しい作業が必要かどうかを判断することは、ソリューション開発の一部となるため、このドキュメントでは説明しません。これらの要件で「ソリューション」という用語は、使用例をサポートするために開発された、既存のプロトコルの拡張や新しいプロトコルを含むプロトコル仕様を意味することに注意してください。ソリューションは、これらの要件に直接マップされていない追加機能を導入する可能性があります。たとえば、シグナリングプロトコルで伝達される詳細情報。 [RFC7205]で説明されているように、要件が特定のユースケースに直接関連する場合は、ユースケースへの参照が提供されます。
REQ-1: The solution MUST support a description of the spatial arrangement of source video images sent in video streams that enables a satisfactory reproduction at the receiver of the original scene. This applies to each site in a point-to-point or a multipoint meeting and refers to the spatial ordering within a site, not to the ordering of images between sites.
REQ-1：ソリューションは、元のシーンのレシーバーで満足のいく再生を可能にするビデオストリームで送信されるソースビデオ画像の空間配置の説明をサポートする必要があります。これは、ポイントツーポイント会議またはマルチポイント会議の各サイトに適用され、サイト間の画像の順序ではなく、サイト内の空間順序を指します。
This requirement relates to all the use cases described in [RFC7205].
この要件は、[RFC7205]で説明されているすべての使用例に関連しています。
REQ-1a: The solution MUST support a means of allowing the preservation of the order of images in the captured scene. For example, if John is to Susan's right in the image capture, John is also to Susan's right in the rendered image.
REQ-1a：ソリューションは、キャプチャされたシーンでの画像の順序の保持を可能にする手段をサポートする必要があります。たとえば、ジョンが画像キャプチャでスーザンの右にいる場合、ジョンはレンダリングされた画像でもスーザンの右にいます。
REQ-1b: The solution MUST support a means of allowing the preservation of order of images in the scene in two dimensions - horizontal and vertical.
REQ-1b：ソリューションは、シーン内のイメージの順序を2次元（水平および垂直）で保持できるようにする手段をサポートする必要があります。
REQ-1c: The solution MUST support a means to identify the relative location, within a scene, of the point of capture of individual video captures in three dimensions.
REQ-1c：ソリューションは、シーン内で、個々のビデオキャプチャのキャプチャポイントの相対的な位置を3次元で識別する手段をサポートする必要があります。
REQ-1d: The solution MUST support a means to identify the area of coverage, within a scene, of individual video captures in three dimensions.
REQ-1d：ソリューションは、シーン内の個々のビデオキャプチャのカバレッジエリアを3次元で識別する手段をサポートする必要があります。
REQ-2: The solution MUST support a description of the spatial arrangement of captured source audio sent in audio streams that enables a satisfactory reproduction at the receiver in a spatially correct manner. This applies to each site in a point to point or a multipoint meeting and refers to the spatial ordering within a site, not the ordering of channels between sites.
REQ-2：ソリューションは、空間的に正しい方法でレシーバーで満足のいく再生を可能にするオーディオストリームで送信されるキャプチャされたソースオーディオの空間配置の説明をサポートする必要があります。これは、ポイントツーポイントまたはマルチポイント会議の各サイトに適用され、サイト間のチャネルの順序ではなく、サイト内の空間の順序を指します。
This requirement relates to all the use cases described in [RFC7205], but is particularly important in the Heterogeneous Systems use case.
この要件は、[RFC7205]で説明されているすべての使用例に関連していますが、異機種システムの使用例では特に重要です。
REQ-2a: The solution MUST support a means of preserving the spatial order of audio in the captured scene. For example, if John sounds as if he is on Susan's right in the captured audio, John voice is also placed on Susan's right in the rendered image.
REQ-2a：ソリューションは、キャプチャされたシーンのオーディオの空間順序を維持する手段をサポートする必要があります。たとえば、ジョンがキャプチャされたオーディオでスーザンの右にいるように聞こえる場合、レンダリングされた画像でジョンの声もスーザンの右に配置されます。
REQ-2b: The solution MUST support a means to identify the number and spatial arrangement of audio channels including monaural, stereophonic (2.0), and 3.0 (left, center, right) audio channels.
REQ-2b：ソリューションは、モノラル、ステレオ（2.0）、および3.0（左、中央、右）オーディオチャネルを含むオーディオチャネルの数と空間配置を識別する手段をサポートする必要があります。
REQ-2c: The solution MUST support a means to identify the point of capture of individual audio captures in three dimensions.
REQ-2c：ソリューションは、3つの次元で個々のオーディオキャプチャのキャプチャポイントを識別する手段をサポートする必要があります。
REQ-2d: The solution MUST support a means to identify the area of coverage of individual audio captures in three dimensions.
REQ-2d：ソリューションは、3次元で個々のオーディオキャプチャのカバレッジエリアを識別する手段をサポートする必要があります。
REQ-3: The solution MUST enable individual audio streams to be associated with one or more video image captures, and individual video image captures to be associated with one or more audio captures, for the purpose of rendering proper position.
REQ-3：ソリューションでは、適切な位置をレンダリングするために、個々のオーディオストリームを1つ以上のビデオ画像キャプチャに関連付け、個々のビデオ画像キャプチャを1つ以上のオーディオキャプチャに関連付ける必要があります。
This requirement relates to all the use cases described in [RFC7205].
この要件は、[RFC7205]で説明されているすべての使用例に関連しています。
REQ-4: The solution MUST enable interoperability between endpoints that have a different number of similar devices. For example, an endpoint may have 1 screen, 1 loudspeaker, 1 camera, 1 mic, and another endpoint may have 3 screens, 2 loudspeakers, 3 cameras and 2 microphones. Or, in a multipoint conference, an endpoint may have 1 screen, another may have 2 screens, and a third may have 3 screens. This includes endpoints where the number of devices of a given type is zero.
REQ-4：ソリューションでは、類似したデバイスの数が異なるエンドポイント間の相互運用性を有効にする必要があります。たとえば、エンドポイントには1つの画面、1つのスピーカー、1つのカメラ、1つのマイクがあり、別のエンドポイントには3つの画面、2つのスピーカー、3つのカメラ、2つのマイクがあります。または、マルチポイント会議では、エンドポイントに1つの画面があり、別のエンドポイントに2つの画面があり、3つ目の画面に3つの画面がある場合があります。これには、特定のタイプのデバイスの数がゼロであるエンドポイントが含まれます。
This requirement relates to the Point-to-Point Meeting: Symmetric and Multipoint Meeting use cases described in [RFC7205].
この要件は、[RFC7205]で説明されているポイントツーポイント会議：対称およびマルチポイント会議の使用例に関連しています。
REQ-5: The solution MUST support means of enabling interoperability between telepresence endpoints where cameras are of different picture aspect ratios.
REQ-5：ソリューションは、カメラの画像アスペクト比が異なるテレプレゼンスエンドポイント間の相互運用を可能にする手段をサポートする必要があります。
REQ-6: The solution MUST provide scaling information that enables rendering of a video image at the actual size of the captured scene.
REQ-6：ソリューションは、キャプチャされたシーンの実際のサイズでビデオ画像のレンダリングを可能にするスケーリング情報を提供する必要があります。
REQ-7: The solution MUST support means of enabling interoperability between telepresence endpoints where displays are of different resolutions.
REQ-7：ソリューションは、ディスプレイの解像度が異なるテレプレゼンスエンドポイント間の相互運用を可能にする手段をサポートする必要があります。
REQ-8: The solution MUST support methods for handling different bit rates in the same conference.
REQ-8：ソリューションは、同じ会議で異なるビットレートを処理する方法をサポートする必要があります。
REQ-9: The solution MUST support means of enabling interoperability between endpoints that send and receive different numbers of media streams.
REQ-9：ソリューションは、異なる数のメディアストリームを送受信するエンドポイント間の相互運用性を有効にする手段をサポートする必要があります。
This requirement relates to the Heterogeneous Systems and Multipoint Meeting use cases.
この要件は、異機種システムとマルチポイント会議の使用例に関連しています。
REQ-10: The solution MUST ensure that endpoints that support telepresence extensions can establish a session with a SIP endpoint that does not support the telepresence extensions. For example, in the case of a SIP endpoint that supports a single audio and a single video stream, an endpoint that supports the telepresence extensions would setup a session with a single audio and single video stream using existing SIP and SDP mechanisms.
REQ-10：ソリューションは、テレプレゼンス拡張をサポートするエンドポイントが、テレプレゼンス拡張をサポートしないSIPエンドポイントとのセッションを確立できることを確認する必要があります。たとえば、単一のオーディオおよび単一のビデオストリームをサポートするSIPエンドポイントの場合、テレプレゼンス拡張をサポートするエンドポイントは、既存のSIPおよびSDPメカニズムを使用して単一のオーディオおよび単一のビデオストリームでセッションをセットアップします。
REQ-11: The solution MUST support a mechanism for determining whether or not an endpoint or MCU is capable of telepresence extensions.
REQ-11：ソリューションは、エンドポイントまたはMCUがテレプレゼンス拡張に対応しているかどうかを判断するメカニズムをサポートする必要があります。
REQ-12: The solution MUST support a means to enable more than two endpoints to participate in a teleconference.
REQ-12：ソリューションは、3つ以上のエンドポイントが電話会議に参加できるようにする手段をサポートする必要があります。
This requirement relates to the Multipoint Meeting use case.
この要件は、マルチポイント会議の使用例に関連しています。
REQ-13: The solution MUST support both transcoding and switching approaches for providing multipoint conferences.
REQ-13：ソリューションは、マルチポイント会議を提供するためのトランスコーディングとスイッチングの両方のアプローチをサポートする必要があります。
REQ-14: The solution MUST support mechanisms to allow media from one source endpoint or/and multiple source endpoints to be sent to a remote endpoint at a particular point in time. Which media is sent at a point in time may be based on local policy.
REQ-14：ソリューションは、特定の時点で1つのソースエンドポイントまたは複数のソースエンドポイントからのメディアをリモートエンドポイントに送信できるようにするメカニズムをサポートする必要があります。ある時点で送信されるメディアは、ローカルポリシーに基づいている場合があります。
REQ-15: The solution MUST provide mechanisms to support the following:
REQ-15：ソリューションは、以下をサポートするメカニズムを提供する必要があります。
* Presentations with different media sources
* メディアソースが異なるプレゼンテーション
* Presentations for which the media streams are visible to all endpoints
* メディアストリームがすべてのエンドポイントに表示されるプレゼンテーション
* Multiple, simultaneous presentation media streams, including presentation media streams that are spatially related to each other.
* 相互に空間的に関連するプレゼンテーションメディアストリームを含む、複数の同時プレゼンテーションメディアストリーム。
The requirement relates to the Presentation use case.
この要件は、プレゼンテーションの使用例に関連しています。
REQ-16: The specification of any new protocols for the solution MUST provide extensibility mechanisms.
REQ-16：ソリューションの新しいプロトコルの仕様は、拡張メカニズムを提供する必要があります。
REQ-17: The solution MUST support a mechanism for allowing information about media captures to change during a conference.
REQ-17：ソリューションは、メディアキャプチャに関する情報を会議中に変更できるようにするメカニズムをサポートする必要があります。
REQ-18: The solution MUST provide a mechanism for the secure exchange of information about the media captures.
REQ-18：ソリューションは、メディアキャプチャに関する情報を安全に交換するためのメカニズムを提供する必要があります。
This document has benefited from all the comments on the CLUE mailing list and a number of discussions. So many people contributed that it is not possible to list them all. However, the comments provided by Roberta Presta, Christian Groves and Paul Coverdale during WGLC were particularly helpful in completing the WG document.
このドキュメントは、CLUEメーリングリストのすべてのコメントと多数のディスカッションの恩恵を受けています。多くの人々が貢献したため、それらすべてをリストすることは不可能です。ただし、WGLC中にRoberta Presta、Christian Groves、Paul Coverdaleが提供したコメントは、WG文書の完成に特に役立ちました。
REQ-18 identifies the need to securely transport the information about media captures. It is important to note that session setup for a telepresence session will use SIP for basic session setup and either SIP or the Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503] for a multiparty telepresence session. Information carried in the SIP signaling can be secured by the SIP security mechanisms as defined in [RFC3261]. In the case of conference control using CCMP, the security model and mechanisms as defined in the Centralized Conferencing (XCON) Framework [RFC5239] and CCMP [RFC6503] documents would meet the requirement. Any additional signaling mechanism used to transport the information about media captures needs to define the mechanisms by which the information is secure. The details for the mechanisms needs to be defined and described in the CLUE framework document and related solution document(s).
REQ-18は、メディアキャプチャに関する情報を安全に転送する必要性を認識しています。テレプレゼンスセッションのセッションセットアップでは、基本的なセッションセットアップにはSIPを使用し、マルチパーティテレプレゼンスセッションにはSIPまたは集中会議操作プロトコル（CCMP）[RFC6503]を使用することに注意してください。 SIPシグナリングで運ばれる情報は、[RFC3261]で定義されているSIPセキュリティメカニズムによって保護できます。 CCMPを使用した会議制御の場合、集中会議（XCON）フレームワーク[RFC5239]およびCCMP [RFC6503]ドキュメントで定義されているセキュリティモデルとメカニズムが要件を満たします。メディアキャプチャに関する情報の転送に使用される追加のシグナリングメカニズムでは、情報を保護するメカニズムを定義する必要があります。メカニズムの詳細は、CLUEフレームワークドキュメントおよび関連するソリューションドキュメントで定義および説明する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353] Rosenberg、J。、「Session Initiation Protocol（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579] Johnston、A.およびO. Levin、「Session Initiation Protocol（SIP）Call Control-Conferencing for User Agents」、BCP 119、RFC 4579、2006年8月。
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.
[RFC5117] Westerlund、M。およびS. Wenger、「RTPトポロジ」、RFC 5117、2008年1月。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.
[RFC5239] Barnes、M.、Boulton、C。、およびO. Levin、「集中会議のフレームワーク」、RFC 5239、2008年6月。
[RFC6503] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, March 2012.
[RFC6503] Barnes、M.、Boulton、C.、Romano、S。、およびH. Schulzrinne、「Centralized Conferencing Manipulation Protocol」、RFC 6503、2012年3月。
[RFC7205] Romanow, A., Botzko, S., Duckworth, M., and R. Even, "Use Cases for Telepresence Multistreams", RFC 7205, April 2014.
[RFC7205] Romanow、A.、Botzko、S.、Duckworth、M。、およびR. Even、「テレプレゼンスマルチストリームの使用例」、RFC 7205、2014年4月。
[ITU.H323] ITU-T, "Packet-based Multimedia Communications Systems", ITU-T Recommendation H.323, December 2009.
[ITU.H323] ITU-T、「パケットベースのマルチメディア通信システム」、ITU-T勧告H.323、2009年12月。
Authors' Addresses
著者のアドレス
Allyn Romanow Cisco Systems San Jose, CA 95134 USA
Allyn Romanow Cisco Systems San Jose、CA 95134 USA
EMail: allyn@cisco.com
Stephen Botzko Polycom Andover, MA 01810 USA
Ｓてｐへん ぼｔ↑お ぽｌｙこｍ あんどゔぇｒ、 ま ０１８１０ うさ
EMail: stephen.botzko@polycom.com
Mary Barnes MLB@Realtime Communications, LLC
メアリーバーンズMLB @ Realtime Communications、LLC
EMail: mary.ietf.barnes@gmail.com