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
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
远程呈现多流的要求
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
本文件旨在描述通过交换和协商适当信息，实现不同基于SIP的[RFC3261]临场感系统之间互通的规范要求。根据本文件中的要求
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会话以及SIP会议框架[RFC4353]和基于SIP的会议控制[RFC4579]规范中描述的基于SIP的会议。基于非IETF协议的系统，如基于ITU-T Rec.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通过交换有关系统特征的信息来实现远程呈现系统之间的互操作性。系统可以使用这些信息来控制其行为，以实现这些系统之间的互操作性。
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.
远程呈现会话至少需要一个发送和一个接收端点。多方临场感会话包括两个以上的端点和集中式基础设施，如多点控制单元（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不必使用任何描述其功能、属性或行为的线索规范。类似地，端点或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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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.
端点：通过接收、解码和呈现最终终止的逻辑点，和/或通过捕获、编码和发送媒体流发起的逻辑点。一个端点由一个或多个发送和接收媒体流的物理设备以及恰好一个参与者[RFC4353]（而该参与者恰好包括一个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.
布局：渲染媒体流如何在具有单个屏幕和单个扬声器的远程呈现端点上彼此空间排列，以及渲染媒体流如何在具有多个屏幕或扬声器的远程呈现端点上彼此排列。请注意，音频和视频都包含在术语布局中——换句话说，包括在扬声器上放置音频流以及在视频屏幕上放置视频流。
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）-将两个或多个端点连接到一个多媒体会议中的设备[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.
远程：通信信道另一侧的发送方和/或接收方（取决于上下文）；i、 不是本地的。远程设备可以是端点或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.
需要解决的一般问题可以描述如下。如今，每个端点都根据隐式假设的模型渲染它接收的音频和视频捕获，该模型规定了如何生成远程位置的真实描述。如果所有端点由同一供应商制造，则它们都共享相同的隐式模型，并正确呈现接收到的捕获。但是，如果设备来自不同的供应商，则用于呈现状态的模型可以而且通常确实不同。结果可能是远程呈现系统实际连接，但用户体验将受到影响，例如，一个系统假设第一个视频流是从右摄像头捕获的，而另一个系统假设第一个视频流是从左摄像头捕获的。
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.
如果Alice和Bob在不同的地点，Alice需要告诉Bob她所在地点的摄像机和音响设备布置，以便Bob的接收器能够准确呈现她的地点。Alice和Bob需要就突出的特征以及如何表示和传达这些特征达成一致。特征可能包括数量、位置、捕捉/渲染角度、摄像机和屏幕的分辨率、空间位置以及麦克风的音频混音参数。
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.
telepresence multistream的工作旨在以一种允许接收者真实渲染的方式来描述发送者的情况，即使它可能具有与发送者不同的渲染模型。
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.
尽管这些需求的某些方面可以通过现有技术得到满足，例如会话描述协议（SDP）[RFC4566]，但此处对这些需求进行了说明，以完整记录对CLUE的需求。确定需求是否需要新的工作将是解决方案开发的一部分，本文档不讨论。请注意，这些需求中使用的术语“解决方案”是指协议规范，包括为支持用例而开发的现有协议以及任何新协议的扩展。该解决方案可能会引入未直接映射到这些需求的附加功能；e、 例如，信令协议中承载的详细信息。如果需求与[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：解决方案必须支持一种方法，允许保留捕获场景中图像的顺序。例如，如果John在图像捕获中位于Susan的右侧，则John在渲染图像中也位于Susan的右侧。
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：解决方案必须支持一种方法，允许在二维（水平和垂直）中保留场景中图像的顺序。
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：该解决方案必须支持一种方法，以识别三维中单个视频捕获的捕获点在场景中的相对位置。
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：解决方案必须支持一种方法来识别场景中单个视频捕获的三维覆盖区域。
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：解决方案必须支持在捕获的场景中保持音频空间顺序的方法。例如，如果John在捕获的音频中听起来好像位于Susan的右侧，则John voice也会在渲染图像中位于Susan的右侧。
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：解决方案必须支持在三维空间中识别单个音频捕获点的方法。
REQ-2d: The solution MUST support a means to identify the area of coverage of individual audio captures in three dimensions.
REQ-2d：解决方案必须支持在三维空间中识别单个音频捕获覆盖区域的方法。
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：为了呈现正确的位置，解决方案必须使单个音频流与一个或多个视频图像捕获相关联，并使单个视频图像捕获与一个或多个音频捕获相关联。
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个屏幕。这包括给定类型的设备数为零的端点。
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：解决方案必须支持允许两个以上端点参与电话会议的方法。
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：解决方案必须支持允许在特定时间点将来自一个源端点或/和多个源端点的媒体发送到远程端点的机制。在某个时间点发送的媒体可能取决于当地政策。
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.
本文件得益于线索邮件列表上的所有评论和大量讨论。有这么多人捐款，所以不可能全部列出。然而，Roberta Presta、Christian Groves和Paul Coverdale在工作组会议期间提供的意见对完成工作组文件特别有帮助。
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.，“会话启动协议（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：会话描述协议”，RFC4566，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，“会话发起协议（SIP）呼叫控制-用户代理会议”，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 51172008年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，“集中式会议操纵协议”，RFC65032012年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.偶，“远程呈现多流的用例”，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思科系统公司95134
EMail: allyn@cisco.com
EMail: allyn@cisco.com
Stephen Botzko Polycom Andover, MA 01810 USA
Stephen Botzko Polycom Andover，马萨诸塞州，美国01810
EMail: stephen.botzko@polycom.com
EMail: stephen.botzko@polycom.com
Mary Barnes MLB@Realtime Communications, LLC
玛丽·巴恩斯MLB@Realtime通信有限责任公司
EMail: mary.ietf.barnes@gmail.com
EMail: mary.ietf.barnes@gmail.com