Network Working Group M. Barnes
Request for Comments: 5239 Nortel
Category: Standards Track C. Boulton
Avaya
O. Levin
Microsoft Corporation
June 2008
Network Working Group M. Barnes
Request for Comments: 5239 Nortel
Category: Standards Track C. Boulton
Avaya
O. Levin
Microsoft Corporation
June 2008
A Framework for Centralized Conferencing
集中式会议的框架
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems.
本文档定义了集中式会议的框架。该框架允许使用各种呼叫信令协议（如SIP、H.323、Jabber、Q.931或ISDN用户部分（ISUP））的参与者在集中式单播会议中交换媒体。集中式会议框架定义了逻辑实体和命名约定。该框架还概述了一组会议协议，这些协议是对呼叫信令协议的补充，用于构建高级会议应用程序。该框架将所有定义的组件绑定在一起，以利于会议系统的构建者。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10
5.1. Conference Information . . . . . . . . . . . . . . . . . . 11
5.2. Conference policies . . . . . . . . . . . . . . . . . . . 12
6. Centralized Conferencing Constructs and Identifiers . . . . . 12
6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13
6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15
6.3. Conference User Identifier . . . . . . . . . . . . . . . . 16
7. Conferencing System Realization . . . . . . . . . . . . . . . 17
7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Ad Hoc Example . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 21
7.4. Scheduling a Conference . . . . . . . . . . . . . . . . . 23
8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26
8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26
8.3. Conference Control Protocol . . . . . . . . . . . . . . . 26
8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 26
9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 28
9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 28
9.2. Participant Manipulations . . . . . . . . . . . . . . . . 30
9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 32
9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 33
9.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35
9.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37
9.5. Floor Control Using Sidebars . . . . . . . . . . . . . . . 40
9.6. Whispering or Private Messages . . . . . . . . . . . . . . 42
9.7. Conference Announcements and Recordings . . . . . . . . . 44
9.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46
9.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46
10. Relationships between SIP and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11. Security Considerations . . . . . . . . . . . . . . . . . . . 50
11.1. User Authentication and Authorization . . . . . . . . . . 51
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 53
11.3. Floor Control Server Authentication . . . . . . . . . . . 53
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . . 54
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10
5.1. Conference Information . . . . . . . . . . . . . . . . . . 11
5.2. Conference policies . . . . . . . . . . . . . . . . . . . 12
6. Centralized Conferencing Constructs and Identifiers . . . . . 12
6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13
6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15
6.3. Conference User Identifier . . . . . . . . . . . . . . . . 16
7. Conferencing System Realization . . . . . . . . . . . . . . . 17
7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Ad Hoc Example . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 21
7.4. Scheduling a Conference . . . . . . . . . . . . . . . . . 23
8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26
8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26
8.3. Conference Control Protocol . . . . . . . . . . . . . . . 26
8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 26
9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 28
9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 28
9.2. Participant Manipulations . . . . . . . . . . . . . . . . 30
9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 32
9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 33
9.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35
9.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37
9.5. Floor Control Using Sidebars . . . . . . . . . . . . . . . 40
9.6. Whispering or Private Messages . . . . . . . . . . . . . . 42
9.7. Conference Announcements and Recordings . . . . . . . . . 44
9.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46
9.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46
10. Relationships between SIP and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11. Security Considerations . . . . . . . . . . . . . . . . . . . 50
11.1. User Authentication and Authorization . . . . . . . . . . 51
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 53
11.3. Floor Control Server Authentication . . . . . . . . . . . 53
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . . 54
This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISUP, to exchange media in a centralized unicast conference. Other than references to general functionality (e.g., establishment and teardown), details of these call signaling protocols are outside the scope of this document.
本文档定义了集中式会议的框架。该框架允许使用各种呼叫信令协议（如SIP、H.323、Jabber、Q.931或ISUP）的参与者在集中式单播会议中交换媒体。除参考一般功能（如建立和拆卸）外，这些呼叫信令协议的详细信息不在本文档范围内。
The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications.
集中式会议框架定义了逻辑实体和命名约定。该框架还概述了一组会议协议，这些协议是对呼叫信令协议的补充，用于构建高级会议应用程序。
The Centralized Conferencing Framework is compatible with the functional model presented in the SIP Conferencing Framework [RFC4353]. Section 10 of this document discusses the relationship between the Centralized Conferencing Framework and the SIP Conferencing Framework, in the context of the Centralized Conferencing model presented in this document.
集中式会议框架与SIP会议框架[RFC4353]中提供的功能模型兼容。本文档第10节在本文档中介绍的集中式会议模型的上下文中讨论了集中式会议框架和SIP会议框架之间的关系。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, [RFC2119] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14、[RFC2119]中的说明进行解释，并指出合规实施的要求级别。
This Centralized Conferencing Framework document generalizes, when appropriate, the SIP Conferencing Framework [RFC4353] terminology and introduces new concepts, as listed below. Further details and clarification of the new terms and concepts are provided in the subsequent sections of this document.
本集中式会议框架文档在适当时概括了SIP会议框架[RFC4353]术语，并引入了新概念，如下所示。本文件后续章节提供了新术语和概念的进一步详细信息和澄清。
Active conference: The term "active conference" refers to a conference object that has been created and activated via the allocation of its identifiers (e.g., conference object identifier and conference identifier) and the associated focus. An active conference is created based on either a system default conference blueprint or a specific conference reservation.
活动会议：术语“活动会议”指通过分配其标识符（例如，会议对象标识符和会议标识符）和相关焦点而创建和激活的会议对象。根据系统默认会议蓝图或特定会议预订创建活动会议。
Call Signaling protocol: The call signaling protocol is used between a participant and a focus. In this context, the term "call" means a channel or session used for media streams.
呼叫信令协议：呼叫信令协议用于参与者和焦点之间。在此上下文中，术语“呼叫”意指用于媒体流的信道或会话。
Conference blueprint: A conference blueprint is a static conference object within a conferencing system, which describes a typical conference setting supported by the system. A conference blueprint is the basis for creation of dynamic conference objects. A system may maintain multiple blueprints. Each blueprint is comprised of the initial values and ranges for the elements in the object, conformant to the data schemas for the conference information.
会议蓝图：会议蓝图是会议系统中的静态会议对象，它描述了系统支持的典型会议设置。会议蓝图是创建动态会议对象的基础。一个系统可以维护多个蓝图。每个蓝图由对象中元素的初始值和范围组成，符合会议信息的数据模式。
Conference control protocol (CCP): A conference control protocol provides the interface for data manipulation and state retrieval for the centralized conferencing data, represented by the conference object.
会议控制协议（CCP）：会议控制协议为集中会议数据（由会议对象表示）的数据操作和状态检索提供接口。
Conference factory: A conference factory is a logical entity that generates unique URI(s) to identify and represent a conference focus.
会议工厂：会议工厂是一个逻辑实体，它生成唯一的URI来标识和表示会议焦点。
Conference identifier (ID): A conference identifier is a call signaling protocol-specific URI that identifies a conference focus and its associated conference instance.
会议标识符（ID）：会议标识符是呼叫信令协议特定的URI，用于标识会议焦点及其关联的会议实例。
Conference information: The conference information includes definitions for basic conference features, such as conference identifiers, membership, signaling, capabilities, and media types applicable to a wide range of conferencing applications. The conference information also includes the media and application-specific data for enhanced conferencing features or capabilities, such as media mixers. The conference information is the data type (i.e., the XML schema) for a conference object.
会议信息：会议信息包括基本会议功能的定义，如适用于各种会议应用程序的会议标识符、成员资格、信令、功能和媒体类型。会议信息还包括用于增强会议功能或功能（如媒体混音器）的媒体和特定于应用程序的数据。会议信息是会议对象的数据类型（即XML模式）。
Conference instance: A conference instance refers to an internal implementation of a specific conference, represented as a set of logical conference objects and associated identifiers.
会议实例：会议实例是指特定会议的内部实现，表示为一组逻辑会议对象和相关标识符。
Conference object: A conference object represents a conference at a certain stage (e.g., description upon conference creation, reservation, activation, etc.), which a conferencing system maintains in order to describe the system capabilities and to provide access to the services available for each object independently. The conference object schema is based on the conference information.
会议对象：会议对象表示特定阶段的会议（例如，会议创建、预订、激活等时的描述），会议系统维护该阶段，以描述系统功能并独立提供对每个对象可用服务的访问。会议对象模式基于会议信息。
Conference object identifier (ID): A conference object identifier is a URI that uniquely identifies a conference object and is used by a conference control protocol to access and modify the conference information.
会议对象标识符（ID）：会议对象标识符是唯一标识会议对象并由会议控制协议用于访问和修改会议信息的URI。
Conference policies: Conference policies collectively refers to a set of rights, permissions, and limitations pertaining to operations being performed on a certain conference object.
会议策略：会议策略统称为一组与在特定会议对象上执行的操作有关的权限、权限和限制。
Conference reservation: A conference reservation is a conference object, which is created from either a system default or client selected blueprint.
会议预订：会议预订是一个会议对象，它是根据系统默认或客户机选择的蓝图创建的。
Conference state: The conference state reflects the state of a conference instance and is represented using a specific, well-defined schema.
会议状态：会议状态反映会议实例的状态，并使用特定的、定义良好的模式表示。
Conferencing system: Conferencing system refers to a conferencing solution based on the data model discussed in this framework document and built using the protocol specifications referenced in this framework document.
会议系统：会议系统是指基于本框架文件中讨论的数据模型并使用本框架文件中引用的协议规范构建的会议解决方案。
Conference user identifier (ID): A unique identifier for a user within the scope of a conferencing system. A user may have multiple conference user identifiers within a conferencing system (e.g., to represent different roles).
会议用户标识符（ID）：会议系统范围内用户的唯一标识符。用户可以在会议系统内具有多个会议用户标识符（例如，用于表示不同的角色）。
Floor: Floor refers to a set of data or resources associated with a conference instance, for which a conference participant, or group of participants, is granted temporary access.
楼层：楼层是指与会议实例关联的一组数据或资源，会议参与者或参与者组被授予临时访问权限。
Floor chair: A floor chair is a floor control protocol compliant client, either a human participant or automated entity, who is authorized to manage access to one floor and can grant, deny, or revoke access. The floor chair does not have to be a participant in the conference instance.
落地椅：落地椅是一种符合落地控制协议的客户端，可以是人工参与者，也可以是自动实体，有权管理对一个楼层的访问，并可以授予、拒绝或撤销访问权限。会议主席不必是会议实例的参与者。
Focus: A focus is a logical entity that maintains the call signaling interface with each participating client and the conference object representing the active state. As such, the focus acts as an endpoint for each of the supported signaling protocols and is responsible for all primary conference membership operations (e.g., join, leave, update the conference instance) and for media negotiation/maintenance between a conference participant and the focus.
焦点：焦点是一个逻辑实体，它维护与每个参与客户端和代表活动状态的会议对象的呼叫信令接口。因此，焦点充当每个支持的信令协议的端点，并负责所有主要会议成员操作（例如，加入、离开、更新会议实例）以及会议参与者和焦点之间的媒体协商/维护。
Media graph: The media graph is the logical representation of the flow of media for a conference.
媒体图：媒体图是会议媒体流的逻辑表示。
Media mixer: A media mixer is the logical entity with the capability to combine media inputs of the same type, transcode the media, and distribute the result(s) to a single or multiple outputs. In this context, the term "media" means any type of data being delivered over the network using appropriate transport means, such as RTP/ RTP Control Protocol (RTCP) (defined in [RFC3550]) or Message Session Relay Protocol (defined in [RFC4975]).
媒体混合器：媒体混合器是一种逻辑实体，能够组合相同类型的媒体输入，对媒体进行转码，并将结果分发到单个或多个输出。在此上下文中，术语“媒体”是指使用适当的传输手段通过网络传送的任何类型的数据，例如RTP/RTP控制协议（RTCP）（在[RFC3550]中定义）或消息会话中继协议（在[RFC4975]中定义）。
Role: A role provides the context for the set of conference operations that a participant can perform. A default role (e.g., standard conference participant) will always exist, providing a user with a set of basic conference operations. Based on system-specific authentication and authorization, a user may take on alternate roles, such as conference moderator, allowing access to a wider set of conference operations.
角色：角色为参与者可以执行的一组会议操作提供上下文。默认角色（例如，标准会议参与者）将始终存在，为用户提供一组基本会议操作。基于特定于系统的身份验证和授权，用户可以担任备用角色，例如会议主持人，允许访问更广泛的会议操作集。
Sidebar: A sidebar is a separate conference instance that only exists within the context of a parent conference instance. The objective of a sidebar is to be able to provide additional or alternate media only to specific participants.
侧栏：侧栏是一个单独的会议实例，仅存在于父会议实例的上下文中。侧边栏的目标是仅向特定参与者提供附加或替代媒体。
Whisper: A whisper involves a one-time media input to (a) specific participant(s) within a specific conference instance, accomplished using a sidebar. An example of a whisper would be an announcement injected only to the conference chair or to a new participant joining a conference.
窃窃私语：窃窃私语涉及到对特定会议实例中特定参与者的一次性媒体输入，使用侧边栏完成。耳语的一个例子是只向会议主席或参加会议的新参与者发出通知。
A centralized conference is an association of endpoints, called conference participants, with a central endpoint, called a conference focus. The focus has direct peer relationships with the participants by maintaining a separate call signaling interface with each. Consequently, in this centralized conferencing model, the call signaling graph is always a star.
集中式会议是端点（称为会议参与者）与中心端点（称为会议焦点）的关联。focus通过与每个参与者保持单独的呼叫信令接口，与参与者建立直接的对等关系。因此，在这种集中式会议模型中，呼叫信令图始终是星形的。
The most basic conference supported in this model would be an ad hoc, unmanaged conference, which would not necessarily require any of the functionality defined within this framework. For example, it could be supported using basic SIP signaling functionality with a participant serving as the focus; the SIP Conferencing Framework [RFC4353] together with the SIP Call Control Conferencing for User Agents [RFC4579] documents address these types of scenarios.
此模型中支持的最基本的会议是临时的、非托管的会议，它不一定需要此框架中定义的任何功能。例如，可以使用参与者作为焦点的基本SIP信令功能来支持它；SIP会议框架[RFC4353]以及用户代理SIP呼叫控制会议[RFC4579]文档解决了这些类型的场景。
In addition to the basic features, however, a conferencing system supporting the centralized conferencing model proposed in this framework document can offer richer functionality, by including dedicated conferencing applications with explicitly defined capabilities, reserved recurring conferences, along with providing the standard protocols for managing and controlling the different attributes of these conferences.
但是，除了基本功能外，支持本框架文件中提出的集中式会议模型的会议系统还可以提供更丰富的功能，包括具有明确定义功能的专用会议应用程序、保留的定期会议、，同时提供管理和控制这些会议的不同属性的标准协议。
The core requirements for centralized conferencing are outlined in [RFC4245]. These requirements are applicable for conferencing systems using various call signaling protocols, including SIP. Additional conferencing requirements are provided in [RFC4376] and [RFC4597].
[RFC4245]概述了集中式会议的核心要求。这些要求适用于使用各种呼叫信令协议（包括SIP）的会议系统。[RFC4376]和[RFC4597]中提供了其他会议要求。
The centralized conferencing system proposed by this framework is built around a fundamental concept of a conference object. A conference object provides the data representation of a conference during each of the various stages of a conference (e.g., creation, reservation, active, completed, etc.). A conference object is accessed via the logical functional elements, with whom a conferencing client interfaces, using the various protocols identified in Figure 1. The functional elements defined for a conferencing system described by the framework are a conference control server, floor control server, any number of Foci, and a notification service. A conference control protocol (CCP) provides the interface between a conference and media control client and the conference control server. A floor control protocol (e.g., Binary Floor Control Protocol (BFCP)) provides the interface between a floor control client and the floor control server. A call signaling protocol (e.g., SIP, H.323, Jabber, Q.931, ISUP, etc.) provides the interface between a call signaling client and a focus. A notification protocol (e.g. SIP Notify [RFC3265]) provides the interface between the conferencing client and the notification service.
该框架提出的集中式会议系统是围绕会议对象的基本概念构建的。会议对象在会议的各个阶段（例如，创建、预订、活动、完成等）提供会议的数据表示。会议对象通过逻辑功能元素进行访问，会议客户端使用图1中标识的各种协议与逻辑功能元素进行交互。框架描述的会议系统的功能元素包括会议控制服务器、楼层控制服务器、任意数量的Foci和通知服务。会议控制协议（CCP）提供会议和媒体控制客户端与会议控制服务器之间的接口。地板控制协议（例如，二进制地板控制协议（BFCP））提供地板控制客户端和地板控制服务器之间的接口。呼叫信令协议（例如，SIP、H.323、Jabber、Q.931、ISUP等）提供呼叫信令客户端和焦点之间的接口。通知协议（例如SIP Notify[RFC3265]）提供会议客户端和通知服务之间的接口。
A conferencing system can support a subset of the conferencing functions depicted in the conferencing system logical decomposition in Figure 1 and described in this document. However, there are some essential components that would typically be used by most other advanced functions, such as the notification service. For example, the notification service is used to correlate information, such as the list of participants with their media streams, between the various other components.
会议系统可以支持图1中会议系统逻辑分解中描述的以及本文档中描述的会议功能子集。但是，还有一些基本组件通常会被大多数其他高级功能（如通知服务）使用。例如，通知服务用于在各种其他组件之间关联信息，例如参与者列表及其媒体流。
....................................................................
. Conferencing System .
. .
. +-----------------------------------------------------+ .
. | C o n f e r e n c e o b j e c t | .
. +-+---------------------------------------------------+ | .
. | C o n f e r e n c e o b j e c t | | .
. +-+---------------------------------------------------+ | | .
. | C o n f e r e n c e o b j e c t | | | .
. | | | | .
. | | |-+ .
. | |-+ .
. +-----------------------------------------------------+ .
. ^ ^ ^ | .
. | | | | .
. v v v v .
. +-------------------+ +--------------+ +-------+ +------------+ .
. | Conference Control| | Floor Control| |Foci | |Notification| .
. | Server | | Server | | | |Service | .
. +-------------------+ +--------------+ +-------+ +------------+ .
. ^ ^ ^ | .
..............|.................|...........|..........|............
| | | |
|Conference |Binary |Call |Notification
|Control |Floor |Signaling |Protocol
|Protocol |Control |Protocol |
| |Protocol | |
| | | |
..............|.................|...........|..........|............
. V V V V .
. +----------------+ +------------+ +----------+ +------------+ .
. | Conference | | Floor | | Call | |Notification| .
. | and Media | | Control | | Signaling| | Client | .
. | Control | | Client | | Client | | | .
. | Client | | | | | | | .
. +----------------+ +------------+ +----------+ +------------+ .
. .
. Conferencing Client .
....................................................................
....................................................................
. Conferencing System .
. .
. +-----------------------------------------------------+ .
. | C o n f e r e n c e o b j e c t | .
. +-+---------------------------------------------------+ | .
. | C o n f e r e n c e o b j e c t | | .
. +-+---------------------------------------------------+ | | .
. | C o n f e r e n c e o b j e c t | | | .
. | | | | .
. | | |-+ .
. | |-+ .
. +-----------------------------------------------------+ .
. ^ ^ ^ | .
. | | | | .
. v v v v .
. +-------------------+ +--------------+ +-------+ +------------+ .
. | Conference Control| | Floor Control| |Foci | |Notification| .
. | Server | | Server | | | |Service | .
. +-------------------+ +--------------+ +-------+ +------------+ .
. ^ ^ ^ | .
..............|.................|...........|..........|............
| | | |
|Conference |Binary |Call |Notification
|Control |Floor |Signaling |Protocol
|Protocol |Control |Protocol |
| |Protocol | |
| | | |
..............|.................|...........|..........|............
. V V V V .
. +----------------+ +------------+ +----------+ +------------+ .
. | Conference | | Floor | | Call | |Notification| .
. | and Media | | Control | | Signaling| | Client | .
. | Control | | Client | | Client | | | .
. | Client | | | | | | | .
. +----------------+ +------------+ +----------+ +------------+ .
. .
. Conferencing Client .
....................................................................
Figure 1: Conferencing System Logical Decomposition
图1：会议系统逻辑分解
The media graph of a conference can be centralized, decentralized, or any combination of both and potentially differ per media type. In the centralized case, the media sessions are established between a media mixer controlled by the focus and each one of the participants. In the decentralized (i.e., distributed) case, the media graph is a
会议的媒体图可以是集中式、分散式或两者的任意组合，并且可能因媒体类型而异。在集中的情况下，在由焦点控制的媒体混合器和每个参与者之间建立媒体会话。在分散（即分布式）的情况下，媒体图是
multicast or multi-unicast mesh among the participants. Consequently, the media processing (e.g., mixing) can be controlled either by the focus alone or by the participants. The concepts in this framework document clearly map to a centralized media model. The concepts can also apply to the decentralized media case; however, the details of such are left for future study.
参与者之间的多播或多单播网格。因此，媒体处理（例如，混合）可以单独由焦点控制，也可以由参与者控制。本框架文档中的概念清楚地映射到一个集中式媒体模型。这些概念也适用于分散媒体的情况；然而，这些细节将留待将来研究。
Section 5 of this document provides more details on the conference object. Section 6 defines the constructs and identifiers that MUST be implemented to manage the conference objects, instances, and users associated with a conferencing system. Section 7 of this document describes how a conferencing system is logically built using the defined high level data model and how the conference objects are maintained. Section 8 describes the fundamental conferencing mechanisms and provides a high level overview of the protocols. Section 9 then provides realizations of various conferencing scenarios, detailing the manipulation of the conference objects using the defined protocols. Section 10 of this document summarizes the relationship between this Centralized Conferencing Framework and the SIP Conferencing Framework.
本文件第5节提供了有关会议对象的更多详细信息。第6节定义了管理与会议系统相关联的会议对象、实例和用户所必须实现的结构和标识符。本文档第7节描述了如何使用定义的高级数据模型逻辑构建会议系统，以及如何维护会议对象。第8节描述了基本的会议机制，并提供了协议的高级概述。然后，第9节提供了各种会议场景的实现，详细说明了使用定义的协议对会议对象的操作。本文档第10节总结了此集中式会议框架和SIP会议框架之间的关系。
The centralized conference data is logically represented by the conference object. A conference object is of type 'Conference information type', as illustrated in Figure 2. The conference information type is extensible.
集中式会议数据在逻辑上由会议对象表示。会议对象的类型为“会议信息类型”，如图2所示。会议信息类型是可扩展的。
+------------------------------------------------------+
| C o n f e r e n c e o b j e c t |
| |
| +--------------------------------------------------+ |
| | Conference information type | |
| | | |
| | +----------------------------------------------+ | |
| | | Conference description (times, duration) | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Membership (roles, capacity, names) | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Signaling (protocol, direction, status) | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Floor information | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Sidebars, Etc. | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Mixer algorithm, inputs, and outputs | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Floor controls | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Etc. | | |
| | +----------------------------------------------+ | |
| +--------------------------------------------------+ |
+------------------------------------------------------+
+------------------------------------------------------+
| C o n f e r e n c e o b j e c t |
| |
| +--------------------------------------------------+ |
| | Conference information type | |
| | | |
| | +----------------------------------------------+ | |
| | | Conference description (times, duration) | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Membership (roles, capacity, names) | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Signaling (protocol, direction, status) | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Floor information | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Sidebars, Etc. | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Mixer algorithm, inputs, and outputs | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Floor controls | | |
| | +----------------------------------------------+ | |
| | +----------------------------------------------+ | |
| | | Etc. | | |
| | +----------------------------------------------+ | |
| +--------------------------------------------------+ |
+------------------------------------------------------+
Figure 2: Conference Object Type Decomposition
图2：会议对象类型分解
In a system based on this conferencing framework, the same conference object type is used for representation of a conference during different stages of a conference, such as expressing conferencing system capabilities, reserving conferencing resources, or reflecting the state of ongoing conferences. Section 7 describes the usage semantics of the conference objects. The exact XML schema of the
在基于此会议框架的系统中，相同的会议对象类型用于在会议的不同阶段表示会议，例如表示会议系统功能、保留会议资源或反映正在进行的会议的状态。第7节描述了会议对象的使用语义。的确切XML模式
conference object, including the organization of the conference information is detailed in a separate document [XCON-COMMON].
会议对象，包括会议信息的组织，在单独的文档[XCON-COMMON]中有详细说明。
Along with the basic data model, as defined in [XCON-COMMON], the realization of this framework requires a policy infrastructure. The policies required by this framework to manage and control access to the data include local, system level boundaries associated with specific data elements, such as the membership, and the ranges and limitations of other data elements. Additional policy considerations for a system realization based on this data model are discussed in Section 5.2.
除了[XCON-COMMON]中定义的基本数据模型外，该框架的实现还需要一个策略基础设施。该框架要求的管理和控制数据访问的策略包括与特定数据元素（如成员资格）相关的本地、系统级边界，以及其他数据元素的范围和限制。第5.2节讨论了基于此数据模型的系统实现的其他政策考虑。
There is a core set of data in the conference information that is utilized in any conference, independent of the specific conference media nature (e.g., the mixing algorithms performed, the advanced floor control applied, etc.). This core set of data in the conference information contains the definitions representing the conference object capabilities, membership, roles, call signaling, and media status relevant to different stages of the conference life-cycle. This core set of conference information may be represented using the conference-type, as defined in the SIP conference event package [RFC4575]. Typically, participants with read-only access to the conference information would be interested in this core set of conference information only.
会议信息中有一组核心数据，用于任何会议，与特定会议媒体性质无关（例如，执行的混合算法、应用的高级地板控制等）。会议信息中的这组核心数据包含表示与会议生命周期不同阶段相关的会议对象能力、成员资格、角色、呼叫信令和媒体状态的定义。这组核心会议信息可以使用SIP会议事件包[RFC4575]中定义的会议类型来表示。通常，以只读方式访问会议信息的参与者只对这组核心会议信息感兴趣。
In order to support more complex media manipulations and enhanced conferencing features, the conference information, as defined in the data model [XCON-COMMON], contains additional data beyond that defined in the SIP conference event package [RFC4575]. The information defined in the data model [XCON-COMMON] provides specific media mixing details, available floor controls, and other data necessary to support enhanced conferencing features. This information allows authorized clients to manipulate the mixer's behavior via the focus, with the resultant distribution of the media to all or individual participants. By doing so, a client can change its own state and/or the state of other participants in the conference.
为了支持更复杂的媒体操作和增强的会议功能，数据模型[XCON-COMMON]中定义的会议信息包含SIP会议事件包[RFC4575]中定义的额外数据。数据模型[XCON-COMMON]中定义的信息提供了特定的媒体混合详细信息、可用的楼层控制以及支持增强型会议功能所需的其他数据。此信息允许授权客户端通过焦点操纵混音器的行为，从而将媒体分发给所有或单个参与者。通过这样做，客户机可以更改自己的状态和/或会议中其他参与者的状态。
New centralized conferencing specifications can extend the basic conference-type, as defined in the data model [XCON-COMMON], and introduce additional data elements to be used within the conference information type.
新的集中式会议规范可以扩展数据模型[XCON-COMMON]中定义的基本会议类型，并引入在会议信息类型中使用的其他数据元素。
Conference policies collectively refers to a set of rights, permissions and limitations pertaining to operations being performed on a certain conference object.
会议策略统称为与在特定会议对象上执行的操作相关的一组权限、权限和限制。
The set of rights describes the read/write access privileges for the conference object as a whole. This access would usually be granted and defined in terms of giving the read-only or read/write access to clients with certain roles in the conference. Managing this access would require a conferencing system to have access to basic policy information to make the decisions, but doesn't necessarily require an explicit representation in the policy model. As such, for this framework document, the policies represented by the set of rights are reflected in the system realization (Section 7).
权限集描述了会议对象作为一个整体的读/写访问权限。这种访问权通常被授予并定义为向会议中具有特定角色的客户端提供只读或读/写访问权。管理此访问权限需要会议系统能够访问基本策略信息以做出决策，但不一定需要在策略模型中明确表示。因此，对于本框架文件，权利集所代表的政策反映在系统实现中（第7节）。
The permissions and limits require explicit policy mechanisms and are outside the scope of the data model [XCON-COMMON] and this framework document. However, there are some important policy considerations for a conferencing system. A conferencing system associates specific policies in the form of permissions and limitations with each user in a conferencing system. The permissions may vary depending upon the role associated with a specific conference user identifier. A conferencing system should provide a default user role that only allows participation in a conference through the default signaling means.
权限和限制需要明确的策略机制，并且不在数据模型[XCON-COMMON]和本框架文档的范围内。但是，对于会议系统，有一些重要的策略考虑。会议系统以权限和限制的形式将特定策略与会议系统中的每个用户相关联。权限可能因与特定会议用户标识符关联的角色而异。会议系统应提供默认用户角色，仅允许通过默认信令方式参与会议。
The conference object identifier provides access to the data associated with a specific conference. It is important to ensure that elements in the data have individual policy controls to provide flexibility in defining the various roles and specific data elements that may be manipulated by users with specific roles.
会议对象标识符提供对与特定会议关联的数据的访问。重要的是确保数据中的元素具有单独的策略控制，以便在定义具有特定角色的用户可能操纵的各种角色和特定数据元素时提供灵活性。
In addition, the conference notification interface allows specific data elements to be sent to users that register for such notifications. It is important that the appropriate access control is provided so that only users that are authorized to view specific data elements receive the data in the notifications.
此外，会议通知界面允许向注册此类通知的用户发送特定数据元素。必须提供适当的访问控制，以便只有授权查看特定数据元素的用户才能接收通知中的数据。
This section provides details of the identifiers associated with the centralized conferencing framework constructs and the identifiers REQUIRED to address and manage the clients associated with a conferencing system. An overview of the allocation, characteristics, and functional role of the identifiers is provided.
本节提供与集中式会议框架结构相关联的标识符的详细信息，以及寻址和管理与会议系统相关联的客户端所需的标识符。本文概述了标识符的分配、特征和功能作用。
The conference identifier (conference ID) is a call signaling protocol-specific URI that identifies a specific conference focus and its associated conference instance. A conference factory is one method for generating a unique conference ID, to identify and address a conference focus, using a call signaling interface. Details on the use of a conference factory for SIP signaling can be found in [RFC4579]. The conference identifier can also be obtained using the conference control protocol or other, including proprietary, out-of-band mechanisms. To realize the centralized conferencing framework in this document, a conferencing system is REQUIRED to support SIP as the default call signaling protocol. Other call signaling protocols (e.g., ISUP) are OPTIONAL.
会议标识符（会议ID）是呼叫信令协议特定的URI，用于标识特定的会议焦点及其关联的会议实例。会议工厂是使用呼叫信令接口生成唯一会议ID以识别和寻址会议焦点的一种方法。有关使用会议工厂进行SIP信令的详细信息，请参见[RFC4579]。还可以使用会议控制协议或其他（包括专有的）带外机制来获得会议标识符。为了实现本文中的集中式会议框架，需要一个会议系统来支持SIP作为默认的呼叫信令协议。其他呼叫信令协议（如ISUP）是可选的。
A conference object provides the logical representation of a conference instance in a certain stage, such as a conference blueprint representing a conferencing system's capabilities, the data representing a conference reservation, and the conference state during an active conference. Each conference object is independently addressable through the conference control protocol interface (see Section 8.3). A conferencing system MUST provide a default blueprint representing the basic capabilities provided by that specific conferencing system.
会议对象提供特定阶段中会议实例的逻辑表示，例如表示会议系统功能的会议蓝图、表示会议保留的数据以及活动会议期间的会议状态。每个会议对象都可以通过会议控制协议接口独立寻址（见第8.3节）。会议系统必须提供表示该特定会议系统提供的基本功能的默认蓝图。
Figure 3 illustrates the relationships between the conference identifier, the focus, and the conference object ID within the context of a logical conference instance, with the conference object corresponding to an active conference.
图3说明了逻辑会议实例上下文中会议标识符、焦点和会议对象ID之间的关系，会议对象对应于活动会议。
A conference object representing a conference in the active state can have multiple call signaling conference identifiers; for example, one for each call signaling protocol supported. There is a one-to-one mapping between an active conference object and a conference focus. The focus is addressed by explicitly associating unique conference IDs for each signaling protocol supported by the active conference object.
表示处于活动状态的会议的会议对象可以具有多个呼叫信令会议标识符；例如，支持的每个呼叫信令协议一个。活动会议对象和会议焦点之间存在一对一映射。通过为活动会议对象支持的每个信令协议显式关联唯一的会议ID，可以解决该问题。
....................................................................
. Conference Instance .
. .
. .
. +---------------------------------------------------+ .
. | Conference Object Identifier | .
. | | .
. | | .
. +---------------------------------------------------+ .
. ^ ^ .
. | | .
. v | .
. ................................................... | .
. . Focus . | .
. . . | .
. . +----------------------------------+ . | .
. . |Conference Identifier (Protocol Y)| . | .
. . +------------------------------------+ | . | .
. . | Conference Identifier (ISUP) | | . | .
. . +--------------------------------------+ |-+ . | .
. . | Conference Identifier (SIP) | |^ . | .
. . | |-+| . | .
. . | |^ | . | .
. . +--------------------------------------+| | . | .
. ............^...............................|.|.... | .
. | | | | .
................|...............................|.|......|..........
| | | |
|SIP | | |Conference
| ISUP | |Y |Control
| | | |Protocol
| +---------------+ | |
| | | |
| | | |
v v v v
+----------------+ +--------------+ +---------------+
| Conferencing | | Conferencing | | Conference |
| Client | | Client | | Client |
| 1 | | 2 | | X |
+----------------+ +--------------+ +---------------+
....................................................................
. Conference Instance .
. .
. .
. +---------------------------------------------------+ .
. | Conference Object Identifier | .
. | | .
. | | .
. +---------------------------------------------------+ .
. ^ ^ .
. | | .
. v | .
. ................................................... | .
. . Focus . | .
. . . | .
. . +----------------------------------+ . | .
. . |Conference Identifier (Protocol Y)| . | .
. . +------------------------------------+ | . | .
. . | Conference Identifier (ISUP) | | . | .
. . +--------------------------------------+ |-+ . | .
. . | Conference Identifier (SIP) | |^ . | .
. . | |-+| . | .
. . | |^ | . | .
. . +--------------------------------------+| | . | .
. ............^...............................|.|.... | .
. | | | | .
................|...............................|.|......|..........
| | | |
|SIP | | |Conference
| ISUP | |Y |Control
| | | |Protocol
| +---------------+ | |
| | | |
| | | |
v v v v
+----------------+ +--------------+ +---------------+
| Conferencing | | Conferencing | | Conference |
| Client | | Client | | Client |
| 1 | | 2 | | X |
+----------------+ +--------------+ +---------------+
Figure 3: Identifier Relationships for an Active Conference
图3：活动会议的标识符关系
In order to make each conference object externally accessible, the conferencing system MUST allocate a unique URI per distinct conference object in the system. The conference object identifier is defined in [XCON-COMMON]. A conferencing system allocates a conferencing object identifier for every conference blueprint, for every conference reservation, and for every active conference. The distribution of the conference object identifier depends upon the specific use case and includes a variety of mechanisms, such as through the conference control protocol mechanism, the data model and conference package, or out-of-band mechanisms such as email.
为了使每个会议对象都可以从外部访问，会议系统必须为系统中每个不同的会议对象分配唯一的URI。会议对象标识符在[XCON-COMMON]中定义。会议系统为每个会议蓝图、每个会议预订和每个活动会议分配会议对象标识符。会议对象标识符的分布取决于特定用例，并且包括各种机制，例如通过会议控制协议机制、数据模型和会议包，或者带外机制，例如电子邮件。
When a user wishes to create or join a conference and the user does not have the conference object identifier for the specific conference, more general signaling mechanisms apply. A user may have a pre-configured conference object identifier to access the conferencing system or other signaling protocols may be used and the conferencing system maps those to a specific conference object identifier. Once a conference is established, a conference object identifier is REQUIRED for the user to manipulate any of the conferencing data or take advantage of any of the advanced conferencing features. The same notion applies to users joining a conference using other signaling protocols. They are able to initially join a conference using any of the other signaling protocols supported by the specific conferencing system, but the conference object identifier MUST be used to manipulate any of the conferencing data or take advantage of any of the advanced conferencing features. As mentioned previously, the mechanism by which the user learns of the conference object identifier varies and could be via the conference control protocol, using the data model and conference package or entirely out of band mechanisms such as email or a web interface.
当用户希望创建或加入会议并且用户没有特定会议的会议对象标识符时，应用更通用的信令机制。用户可以具有预先配置的会议对象标识符来访问会议系统，或者可以使用其他信令协议，并且会议系统将这些协议映射到特定的会议对象标识符。建立会议后，用户需要会议对象标识符来操作任何会议数据或利用任何高级会议功能。同样的概念也适用于使用其他信令协议加入会议的用户。他们能够使用特定会议系统支持的任何其他信令协议最初加入会议，但必须使用会议对象标识符来操纵任何会议数据或利用任何高级会议功能。如前所述，用户学习会议对象标识符的机制不同，并且可以通过会议控制协议，使用数据模型和会议包，或者完全带外机制，例如电子邮件或web界面。
The conference object identifier logically maps to other protocol-specific identifiers associated with the conference instance, such as the BFCP 'confid'. The mapping of the conference object identifier can be viewed to contain sensitive information in many conferencing systems. The conferencing system must ensure that the data is protected, that only authorized users can manipulate that information via the conferencing control protocol, and that only the appropriate users receive the information through the notification protocol. In general, this information would not be expected to be distributed to the average conference participant.
会议对象标识符在逻辑上映射到与会议实例相关联的其他协议特定标识符，例如BFCP“confid”。在许多会议系统中，可以查看会议对象标识符的映射以包含敏感信息。会议系统必须确保数据受到保护，只有授权用户才能通过会议控制协议操作该信息，并且只有适当的用户通过通知协议接收信息。一般来说，这些信息不会分发给一般的会议参与者。
Each user within a conferencing system MUST be allocated a unique conference user identifier. The conference user identifier is defined in [XCON-COMMON]. The conference user identifier is used in association with the conference object identifier to uniquely identify a user within the scope of conferencing system. There is also a requirement for identifying conferencing system users who may not be participating in a conference instance. Examples of these users would be a non-participating 'Floor Control Chair' or 'Media Policy Controller'. The conference user identifier is REQUIRED, in conference control protocol requests, to uniquely determine who is issuing commands, so that appropriate policies can be applied to the requested command.
必须为会议系统中的每个用户分配一个唯一的会议用户标识符。会议用户标识符在[XCON-COMMON]中定义。会议用户标识符与会议对象标识符联合使用，以唯一地标识会议系统范围内的用户。还需要识别可能未参与会议实例的会议系统用户。这些用户的例子包括不参与的“发言权控制主席”或“媒体政策控制者”。在会议控制协议请求中，需要会议用户标识符来唯一地确定谁在发出命令，以便对请求的命令应用适当的策略。
A typical mode for distributing the user identifier is out of band during conferencing client configuration; thus, the mechanism is outside the scope of the centralized conferencing framework and protocols. However, a conferencing system MUST also be capable of allocating and distributing a user identifier during the first signaling interaction with the conferencing system, such as an initial request for blueprints or adding a new user to an existing conference using the conference control protocol. When a user joins a conference using a signaling-specific protocol, such as SIP for a dial-in conference, a conference user identifier MUST be assigned if one is not already associated with that user. While this conference user identifier isn't required for the participant to join the conference, it is REQUIRED to be allocated and assigned by the conferencing system such that it is available for use for any subsequent conference control protocol operations and/or notifications associated with that conference. For example, the conference user identifier would be sent in any notifications that may be sent to existing participants, such as the moderator, when this user joins.
用于分发用户标识符的典型模式是在会议客户端配置期间带外；因此，该机制超出了集中式会议框架和协议的范围。然而，会议系统还必须能够在与会议系统的第一信令交互期间分配和分发用户标识符，例如对蓝图的初始请求或使用会议控制协议向现有会议添加新用户。当用户使用特定于信令的协议（例如拨入会议的SIP）加入会议时，如果尚未与该用户关联，则必须分配会议用户标识符。虽然参与者加入会议不需要此会议用户标识符，但需要由会议系统分配和分配，以便可用于任何后续会议控制协议操作和/或与该会议相关的通知。例如，当该用户加入时，会议用户标识符将在可能发送给现有参与者（例如主持人）的任何通知中发送。
The conference user identifier is logically associated with the other user identifiers assigned to the conferencing client for other protocol interfaces, such as an authenticated SIP user. The mapping of the conference user identifier to signaling specific user identifiers requires that methods for protecting and securing a user's identity are considered. Section 11.1 addresses "User Authentication and Authorization" and Section 11.2 addresses the "Security and Privacy of User Identity". In addition, the conferencing system MUST ensure the appropriate access control around any internal data structure that maintains this persistent data. This information would typically only be available to a conferencing system administrator.
会议用户标识符在逻辑上与分配给会议客户端用于其他协议接口的其他用户标识符相关联，例如经认证的SIP用户。会议用户标识符到信令特定用户标识符的映射要求考虑用于保护和保护用户身份的方法。第11.1节涉及“用户身份验证和授权”，第11.2节涉及“用户身份的安全和隐私”。此外，会议系统必须确保对维护此持久数据的任何内部数据结构进行适当的访问控制。此信息通常仅对会议系统管理员可用。
Implementations based on this centralized conferencing framework can range from systems supporting ad hoc conferences, with default behavior only, to sophisticated systems with the ability to schedule recurring conferences, each with distinct characteristics, being integrated with external resource reservation tools, and providing snapshots of the conference information at any of the stages of the conference life-cycle.
基于此集中式会议框架的实现可以从支持临时会议（仅具有默认行为）的系统，到能够安排定期会议的复杂系统，每个会议都具有不同的特征，并与外部资源保留工具集成，以及在会议生命周期的任何阶段提供会议信息的快照。
A conference object is the logical representation of a conference instance at a certain stage, such as capabilities description upon conference creation, reservation, activation, etc., which a conferencing system maintains in order to describe the system capabilities and to provide access to the available services provided by the conferencing system. Consequently, this centralized conferencing framework does not mandate the actual usage of the conference object, but rather defines the general cloning tree concept and the mechanisms required for its realization, as described in detail in Section 7.1.
会议对象是特定阶段会议实例的逻辑表示，如会议创建、预订、激活等时的功能描述。，会议系统维护它以描述系统功能并提供对会议系统提供的可用服务的访问。因此，这种集中式会议框架并不要求实际使用会议对象，而是定义了通用的克隆树概念及其实现所需的机制，如第7.1节所述。
Ad hoc and advanced conferencing examples are provided in Section 7.2 and Section 7.3, with the latter providing additional description of the conference object in terms of the stages of a conference, to support scheduled and other advanced conference capabilities. The scheduling of a conference based on these concepts and mechanisms is then detailed in Section 7.4
第7.2节和第7.3节提供了特别会议和高级会议示例，第7.3节提供了关于会议阶段的会议对象的额外描述，以支持预定会议和其他高级会议功能。第7.4节详细介绍了基于这些概念和机制的会议日程安排
As discussed in Section 5.2, the overall policy in terms of permissions and limitations is outside the scope of this framework document. The policies applicable to the conference object as a whole in terms of read/write access would require a conferencing system have access to basic policy information to make the decisions. In the examples in this section, the policies are shown logically associated with the conference objects to emphasize the general requirement for policy functionality necessary for the realization of this framework.
如第5.2节所述，权限和限制方面的总体政策不在本框架文件的范围内。在读/写访问方面，适用于整个会议对象的策略将要求会议系统能够访问基本策略信息以做出决策。在本节的示例中，显示了与会议对象逻辑关联的策略，以强调实现此框架所需的策略功能的一般要求。
The concept defined in this section is a logical representation only, as it is reflected through the centralized conferencing mechanisms: the URIs and the protocols. Of course, the actual system realization can differ from the presented model. The intent is to illustrate the role of the logical elements in providing an interface to the data, based on conferencing system and conferencing client actions, and describe the resultant protocol implications.
本节中定义的概念只是一种逻辑表示，因为它通过集中式会议机制（URI和协议）反映出来。当然，实际的系统实现可能不同于所提出的模型。其目的是根据会议系统和会议客户端操作，说明逻辑元素在提供数据接口方面的作用，并描述由此产生的协议含义。
Any conference object in a conferencing system is created by either being explicitly cloned from an existing parent object or being implicitly cloned from a default system conference blueprint. A conference blueprint is a static conference object used to describe a typical conference setting supported by the system. Each system can maintain multiple blueprints, typically each describing a different conferencing type using the conference information format. This document uses the "cloning" metaphor instead of the "inheritance" metaphor because it more closely fits the idea of object replication, rather than a data type re-usage and extension concept.
会议系统中的任何会议对象都是通过从现有父对象显式克隆或从默认系统会议蓝图隐式克隆来创建的。会议蓝图是一个静态会议对象，用于描述系统支持的典型会议设置。每个系统都可以维护多个蓝图，通常每个蓝图使用会议信息格式描述不同的会议类型。本文档使用“克隆”隐喻而不是“继承”隐喻，因为它更符合对象复制的概念，而不是数据类型重用和扩展的概念。
The cloning operation needs to specify whether or not the link between the parent and child needs to be maintained in the system. If no link between the parent and child exists, the objects become independent and the child is not impacted by any operations on the parent object nor subject to any limitations of the parent object.
克隆操作需要指定是否需要在系统中维护父级和子级之间的链接。如果父对象和子对象之间不存在链接，则对象将变得独立，并且子对象不受父对象上任何操作的影响，也不受父对象的任何限制。
Once the new object is created, it can be addressed by a unique conference object URI assigned by the system, as described in Section 6.2.1. By default, the newly created object contains all the data existing in the parent object. The newly created object can expand the data it contains, within the schema types supported by the parent. It can also restrict the read/write access to its objects. However, unless the object is independent, it cannot modify the access restrictions imposed by the parent object.
创建新对象后，可以通过系统分配的唯一会议对象URI对其进行寻址，如第6.2.1节所述。默认情况下，新创建的对象包含父对象中存在的所有数据。新创建的对象可以在父对象支持的模式类型内扩展它包含的数据。它还可以限制对其对象的读/写访问。但是，除非对象是独立的，否则它无法修改父对象施加的访问限制。
Any piece of data in the child object can be independently accessed and, by default, can be independently modified without affecting the parent data.
子对象中的任何数据都可以独立访问，并且默认情况下，可以独立修改，而不会影响父数据。
Unless the object is independent, the parent object can enforce a different policy by marking certain data elements as "parent enforceable". The values of these data elements cannot be changed by directly accessing the child object, nor can they be expanded in the child object alone.
除非对象是独立的，否则父对象可以通过将某些数据元素标记为“父可强制执行”来强制执行不同的策略。这些数据元素的值不能通过直接访问子对象来更改，也不能仅在子对象中进行扩展。
Figure 4 illustrates an example of a conference (Parent B), which is created independent of its Parent (Parent A). Parent B creates two child objects, Child 1 and Child 2. Any of the data elements of Parent B can be modified (i.e., there are no "parent enforceable" data elements), and depending upon the element, the changes will be reflected in Child 1 and Child 2 , whereas changes to Parent A will not impact the data elements of Parent B. Any "parent enforceable" data elements, as defined by Parent B, cannot be modified in the child objects.
图4展示了一个会议（父级B）的示例，该会议是独立于其父级（父级a）创建的。父对象B创建两个子对象，子对象1和子对象2。母公司B的任何数据元素都可以修改（即，没有“母公司可执行”的数据元素），根据元素的不同，更改将反映在子公司1和子公司2中，而对母公司A的更改不会影响母公司B的数据元素。母公司B定义的任何“母公司可执行”数据元素，无法在子对象中修改。
+---+-----------------------+
| p | |
| o | P A R E N T A |
| l | |
| i | C O N F E R E N C E |
| c | |
| i | O B J E C T |
| e | |
+-s-+-----------------------+
|
\| /
\/ INDEPENDENT
/\
/| \
V
+---+-----------------------+
| p | |
| o | P A R E N T B |
| l | |
| i | C O N F E R E N C E |
| c | |
| i | O B J E C T |
| e | |
+-s-+-----------------------+
| |
| |
| ---------------------------
| |
V V
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | C H I L D 1 | | o | C H I L D 2 |
| l | | | l | |
| i | C O N F E R E N C E | | i | C O N F E R E N C E |
| c | | | c | |
| i | O B J E C T | | i | O B J E C T |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
+---+-----------------------+
| p | |
| o | P A R E N T A |
| l | |
| i | C O N F E R E N C E |
| c | |
| i | O B J E C T |
| e | |
+-s-+-----------------------+
|
\| /
\/ INDEPENDENT
/\
/| \
V
+---+-----------------------+
| p | |
| o | P A R E N T B |
| l | |
| i | C O N F E R E N C E |
| c | |
| i | O B J E C T |
| e | |
+-s-+-----------------------+
| |
| |
| ---------------------------
| |
V V
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | C H I L D 1 | | o | C H I L D 2 |
| l | | | l | |
| i | C O N F E R E N C E | | i | C O N F E R E N C E |
| c | | | c | |
| i | O B J E C T | | i | O B J E C T |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
Figure 4: The Cloning Tree
图4：克隆树
Using the defined cloning model and its tools, the following sections show examples of how different systems based on this framework can be realized.
使用定义的克隆模型及其工具，以下各节将举例说明如何实现基于此框架的不同系统。
Figure 5 illustrates how an ad hoc conference can be created and managed in a conferencing system. A client can create a conference by establishing a call signaling channel with a conference factory, as specified in Section 6.1. The conference factory can internally select one of the system supported conference blueprints based on the requesting client privileges and the media lines included in the Session Description Protocol (SDP) body.
图5说明了如何在会议系统中创建和管理临时会议。如第6.1节所述，客户可以通过与会议工厂建立呼叫信令信道来创建会议。会议工厂可以根据请求的客户端权限和会话描述协议（SDP）正文中包含的媒体线路，在内部选择系统支持的会议蓝图之一。
The selected blueprint with its default values is copied by the server into a newly created conference object, referred to as an 'Active Conference'. At this point, the conference object becomes independent from its blueprint. A new conference object identifier, a new conference identifier, and a new focus are allocated by the server.
服务器将所选蓝图及其默认值复制到新创建的会议对象（称为“活动会议”）中。此时，会议对象将独立于其蓝图。新会议对象标识符、新会议标识符和新焦点由服务器分配。
During the conference lifetime, an authorized client can manipulate the conference object, by performing operations such as adding participants, using the conference control protocol.
在会议生存期内，授权客户端可以通过使用会议控制协议执行添加参与者等操作来操纵会议对象。
+---+-----------------------+
| p | |
| o | System Default |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Active |
| l | |
| i | Conference |
| c | |
| i | |
| e | |
+-s-+-----------------------+
+---+-----------------------+
| p | |
| o | System Default |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Active |
| l | |
| i | Conference |
| c | |
| i | |
| e | |
+-s-+-----------------------+
Figure 5: Conference Ad-hoc Creation and Lifetime
图5：会议临时创建和生存期
Figure 6 illustrates how a recurring conference can be specified according to system capabilities, scheduled, reserved, and managed in a conferencing system. A client would first query a conferencing system for its capabilities. This can be done by requesting a list of the conference blueprints the system supports. Each blueprint contains a specific combination of capabilities and limitations of the conference server in terms of supported media types (e.g., audio, video, text, or combinations of these), participant roles, maximum number of participants of each role, availability of floor control, controls available for participants, availability and type of sidebars, the definitions and names of media streams, etc.
图6说明了如何根据会议系统中的系统功能、计划、保留和管理来指定定期会议。客户机将首先查询会议系统的功能。这可以通过请求系统支持的会议蓝图列表来实现。每个蓝图包含会议服务器在支持的媒体类型（例如，音频、视频、文本或这些媒体的组合）、参与者角色、每个角色的最大参与者人数、楼层控制的可用性、参与者可用的控制等方面的能力和限制的具体组合，侧栏的可用性和类型、媒体流的定义和名称等。
The selected blueprint with its default values is cloned by the client into a newly created conference object, referred to as a conference reservation, that specifies the resources needed from the system for this conference instance. At this point, the conference reservation becomes independent from its blueprint. The client can also change the default values, within the system ranges, and add additional information, such as the list of participants and the conference 'start' time, to the conference reservation.
客户端将所选蓝图及其默认值克隆到新创建的会议对象（称为会议保留）中，该会议对象指定此会议实例所需的系统资源。此时，会议保留将独立于其蓝图。客户端还可以在系统范围内更改默认值，并向会议预订中添加其他信息，如与会者列表和会议“开始”时间。
At this point, the client can ask the conference server to create new conference reservations by attaching the conference reservation to the request. As a result, the server can allocate the needed resources, create the additional conference objects for the child conference reservations, and allocate the conference object identifiers for all -- the original conference reservation and for each child conference reservation.
此时，客户机可以要求会议服务器通过将会议预订附加到请求来创建新的会议预订。因此，服务器可以分配所需的资源，为子会议预订创建额外的会议对象，并为所有人（原始会议预订和每个子会议预订）分配会议对象标识符。
From this point on, any authorized client is able to access and modify each of the conference objects independently. By default, changes to an individual child conference reservation will affect neither the parent conference reservation, from which it was created, nor its siblings.
从这一点开始，任何授权的客户端都可以独立地访问和修改每个会议对象。默认情况下，对单个子会议保留所做的更改既不会影响创建它的父会议保留，也不会影响它的同级会议保留。
On the other hand, some of the conference sub-objects, such as the maximum number of participants and the participants list, can be defined by the system as parent enforceable. As a result, these objects can be modified by accessing the parent conference reservation only. The changes to these objects can be applied automatically to each of the child reservations, subject to local policy.
另一方面，一些会议子对象，例如最大参与者数量和参与者列表，可以由系统定义为父对象。因此，只能通过访问父会议预订来修改这些对象。根据本地策略，对这些对象的更改可以自动应用于每个子保留。
+---+-----------------------+
| p | |
| o | Selected |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Conference |
| l | |
| i | Reservation |
| c | |
| i | |
| e | |
+-s-+-----------------------+
| | |
| | |
| | |
| | |
+---|--|--V-----------------+
+-+---|--V------------------+ |
+-+-+---V-------------------+ | |
| p | | | |
| o | Child Conference | | |
| l | | | |
| i | Reservation | | |
| c | | | |
| i | | |-+
| e | |-+
+-s-+-----------------------+
+---+-----------------------+
| p | |
| o | Selected |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Conference |
| l | |
| i | Reservation |
| c | |
| i | |
| e | |
+-s-+-----------------------+
| | |
| | |
| | |
| | |
+---|--|--V-----------------+
+-+---|--V------------------+ |
+-+-+---V-------------------+ | |
| p | | | |
| o | Child Conference | | |
| l | | | |
| i | Reservation | | |
| c | | | |
| i | | |-+
| e | |-+
+-s-+-----------------------+
Figure 6: Advanced Conference Definition, Creation, and Lifetime
图6：高级会议定义、创建和生存期
When the time comes to schedule the conference reservation, either via the system determination that the 'start' time has been reached or via client invocation, an active conference is cloned based on the conference reservation. As in the ad hoc example, the active conference is independent from the parent, and changes to the conference reservation will not impact the active conference. Any
当通过系统确定已达到“开始”时间或通过客户端调用来安排会议预订时，将根据会议预订克隆活动会议。如特别示例中所示，活动会议独立于父会议，对会议保留的更改不会影响活动会议。任何
desired changes must be targeted towards the active conference. An example of this interaction is shown in Section 9.1.
所需的更改必须针对活跃的会议。第9.1节给出了这种相互作用的示例。
The capability to schedule conferences forms an important part of the conferencing system solution. An individual conference reservation typically has a specified 'start' and 'end' time, with the times being specified relative to a single specified 'fixed' time (e.g., 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system considerations. In most advanced conferencing solutions, it is possible to not only schedule an individual occurrence of a conference reservation, but also schedule a series of related conferences (e.g., a weekly meeting that starts on Thursday at 09.00 GMT).
安排会议的功能是会议系统解决方案的重要组成部分。单个会议预订通常有一个指定的“开始”和“结束”时间，具体时间是相对于单个指定的“固定”时间指定的（例如，“开始”=09.00 GMT，“结束”=“开始”+2），具体取决于系统因素。在大多数高级会议解决方案中，不仅可以安排单独的会议预订，还可以安排一系列相关会议（例如，从周四格林威治标准时间09:00开始的每周会议）。
To be able to achieve such functionality, a conferencing system needs to be able to appropriately schedule and maintain conference reservations that form part of a recurring conference. The mechanism proposed in this document makes use of the "Internet Calendaring and Scheduling Core Object" specification defined in [RFC2445] in union with the concepts introduced in Section 5 for the purpose of achieving advanced conference scheduling capability.
为了能够实现这种功能，会议系统需要能够适当地安排和维护会议预定，这些预定是定期会议的一部分。本文件中提出的机制利用了[RFC2445]中定义的“互联网日历和调度核心对象”规范，并结合第5节中介绍的概念，以实现高级会议调度功能。
Figure 7 illustrates a simplified view of a client interacting with a conferencing system. The client is using the conference control protocol to add a new conference reservation to the conferencing system by interfacing with the conference control server. A CCP request contains a valid conference reservation and reference by value to an "iCal" object that contains scheduling information about the conference (e.g., 'start' time, 'end' time).
图7展示了与会议系统交互的客户端的简化视图。客户机使用会议控制协议通过与会议控制服务器的接口向会议系统添加新的会议预订。CCP请求包含有效的会议预订和对“iCal”对象的值引用，该对象包含有关会议的日程安排信息（例如，“开始”时间、“结束”时间）。
+--------------+ +-------Conferencing System-----------------+
| Generic ICAL | | |
| Resource | | ..Conference Instance.... |
+--------------+ | . . +-----------+|
^ ^ | . +-------------------+ . | Conference||
| | | . |Conference Objects |<--| Control ||
| ----------------->. +-------------------+ . | Server ||
| | . . +-----------+|
| | ......................... ^ |
| | ^ | |
+-----|--------------+ | | |
| v | | |
| +--------------+ | | |
| | Resource |<------------------+ | |
| | Scheduler | | |
| +--------------+ | |
| | |
+---------------------------------------------------------|------+
|
|
+-Request-+
| |
+----+ |
|ICAL| |
+----+----+
|
|
|
Conference Control|
Protocol |
|
+-------------+
| Conferencing|
| Client |
+-------------+
+--------------+ +-------Conferencing System-----------------+
| Generic ICAL | | |
| Resource | | ..Conference Instance.... |
+--------------+ | . . +-----------+|
^ ^ | . +-------------------+ . | Conference||
| | | . |Conference Objects |<--| Control ||
| ----------------->. +-------------------+ . | Server ||
| | . . +-----------+|
| | ......................... ^ |
| | ^ | |
+-----|--------------+ | | |
| v | | |
| +--------------+ | | |
| | Resource |<------------------+ | |
| | Scheduler | | |
| +--------------+ | |
| | |
+---------------------------------------------------------|------+
|
|
+-Request-+
| |
+----+ |
|ICAL| |
+----+----+
|
|
|
Conference Control|
Protocol |
|
+-------------+
| Conferencing|
| Client |
+-------------+
Figure 7: Resource Scheduling
图7：资源调度
A CCP request to create a new conference reservation is validated, including the associated iCal object, and the resultant conference reservation is created. The conference reservation is uniquely represented within the conferencing system by a conference object identifier (e.g., xcon:hd87928374), as introduced in Section 6.2.1 and defined in [XCON-COMMON]. This unique URI is returned to the client and can be used to reference the conference reservation, if any future manipulations are required (e.g., alter 'start' time), using a CCP request.
验证创建新会议预订的CCP请求，包括关联的iCal对象，并创建结果会议预订。会议预订在会议系统中由会议对象标识符（例如xcon:hd87928374）唯一表示，如第6.2.1节所述，并在[xcon-COMMON]中定义。如果将来需要任何操作（例如，更改“开始”时间），则使用CCP请求将此唯一URI返回给客户端，并可用于引用会议预订。
The previous example explains how a client creates a basic conference reservation using an iCal reference in association with a conference control protocol. Figure 7 can also be applied when explaining how a series of conferences are scheduled in the system. The description is almost identical with the exception that the iCal definition that is included in a CCP request represents a series of recurring conference instances (e.g., conference 'start' time, 'end' time, occur weekly). The conferencing system will treat this request the same as the first example. The CCP request will be validated, along with the associated iCal object, and the conference reservation is created. The conference reservation and its conference object ID, created for this example, represent the entire series of recurring conference instances rather than a single Conference. If the client uses the conference object ID provided and a CCP request to adjust the conference reservation, every conference instance in the series will be altered. This includes all future occurrences, such as a conference scheduled as an infinite series, subject to the limitations of the available calendaring interface.
前面的示例解释了客户端如何使用与会议控制协议关联的iCal引用创建基本会议预订。在解释如何在系统中安排一系列会议时，也可以使用图7。除了CCP请求中包含的iCal定义表示一系列重复出现的会议实例（例如，会议“开始”时间、“结束”时间、每周发生）外，描述几乎相同。会议系统将与第一个示例一样处理此请求。将验证CCP请求以及相关的iCal对象，并创建会议预订。为本例创建的会议预订及其会议对象ID表示整个重复会议实例系列，而不是单个会议。如果客户端使用提供的会议对象ID和CCP请求来调整会议预订，则该系列中的每个会议实例都将被更改。这包括将来发生的所有事件，例如，根据可用日历界面的限制，安排为无限系列的会议。
A conferencing system that supports the scheduling of a series of conference instances should also be able to support manipulation within a specific range of the series. A good example is a conference reservation that has been scheduled to occur every Monday at 09.00 GMT. For the next three weeks only, the meeting has been altered to occur at 10.00 GMT in an alternative venue. With Figure 7 in mind, the client will construct a CCP request whose purpose is to modify the existing conference reservation for the recurring conference instance. The client will include the conference object ID provided by the conferencing system to explicitly reference the conference reservation within the conferencing system. A CCP request will contain all the required changes to the conference reservation (e.g., change of venue).
支持安排一系列会议实例的会议系统还应能够支持在该系列的特定范围内进行操作。一个很好的例子是预定于每周一格林威治标准时间09:00举行的会议预订。仅在接下来的三周内，会议已更改为格林威治标准时间10:00在其他地点举行。考虑到图7，客户机将构造一个CCP请求，其目的是修改定期会议实例的现有会议预订。客户端将包括会议系统提供的会议对象ID，以明确引用会议系统内的会议预订。CCP请求将包含对会议预订所需的所有变更（例如，变更地点）。
The conferencing system matches the incoming CCP request to the existing conference reservation but identifies that the associated iCal object only refers to a range of the existing series. The conferencing system creates a child, by cloning the original conference reservation, to represent the altered conference instances within the series. The cloned child object is not independent of the original parent object, thus preventing any potential conflicts in scheduling (e.g., a change to the whole series ''start' time'). The cloned conference reservation, representing the altered series of conference instances, has its own associated conference object ID that is returned to the client using a CCP response. This conference object ID is then used by the client to make any future alterations on the newly defined sub-series. This process can be repeated any number of times as the newly returned conference object ID representing an altered (cloned) series of conference instances, can
会议系统将传入的CCP请求与现有会议预订相匹配，但确定关联的iCal对象仅指现有系列的一个范围。会议系统通过克隆原始会议保留来创建子级，以表示系列中已更改的会议实例。克隆的子对象并不独立于原始父对象，因此可以防止调度中的任何潜在冲突（例如，更改整个系列的“开始”时间）。克隆的会议预订（表示已更改的一系列会议实例）具有自己的关联会议对象ID，该ID使用CCP响应返回给客户端。然后，客户机将使用此会议对象ID对新定义的子系列进行任何未来更改。此过程可以重复任意次数，因为新返回的会议对象ID表示一系列已更改（克隆）的会议实例
itself be manipulated using a CCP request for the newly created conference object ID . This provides a flexible approach to the scheduling of recurring conference instances.
可以使用新创建的会议对象ID的CCP请求来操纵它本身。这为安排定期会议实例提供了一种灵活的方法。
The focus is the central component of the conference. Participants interface with the focus using an appropriate call signaling protocol (CSP). Participants request to establish or join a conference using the CSP. After checking the applicable policies, a focus then either accepts the request, sends a progress indication related to the status of the request (e.g., for a parked call while awaiting moderator approval to join), or rejects that request using the call signaling interface.
重点是会议的核心部分。参与者使用适当的呼叫信令协议（CSP）与焦点进行交互。参与者要求使用CSP建立或加入会议。在检查适用的策略后，focus然后接受请求，发送与请求状态相关的进度指示（例如，等待主持人批准加入时暂停的呼叫），或者使用呼叫信令接口拒绝该请求。
During an active conference, a conference control protocol can be used to affect the conference state. For example, CCP requests to add and delete participants are communicated to the focus and checked against the conference policies. If approved, the participants are added or deleted using the call signaling to/from the focus.
在活动会议期间，可以使用会议控制协议来影响会议状态。例如，CCP添加和删除参与者的请求将传达给焦点，并根据会议政策进行检查。如果获得批准，则使用呼叫信号向/从焦点添加或删除参与者。
A conferencing system is responsible for implementing a conference notification service. The conference notification service provides updates about the conference instance state to authorized parties, including participants. A model for notifications using SIP is defined in [RFC3265] with the specifics to support conferencing defined in [RFC4575].
会议系统负责实现会议通知服务。会议通知服务向授权方（包括参与者）提供有关会议实例状态的更新。[RFC3265]中定义了使用SIP的通知模型，并提供了支持[RFC4575]中定义的会议的详细信息。
The conference user identifier and associated role are used by the conferencing system to filter the notifications such that they contain only information that is allowed to be sent to that user.
会议系统使用会议用户标识符和关联角色过滤通知，使其仅包含允许发送给该用户的信息。
The conference control protocol provides for data manipulation and state retrieval for the centralized conferencing data, represented by the conference object. The details of the conference control protocol are provided in separate documents.
会议控制协议为会议对象表示的集中式会议数据提供数据操作和状态检索。会议控制协议的细节在单独的文件中提供。
A floor control protocol allows an authorized client to manage access to a specific floor and to grant, deny or revoke access of other conference users to that floor. Floor control is not a mandatory
楼层控制协议允许授权客户端管理对特定楼层的访问，并允许、拒绝或撤销其他会议用户对该楼层的访问。楼层控制不是强制性的
mechanism for a conferencing system implementation, but it provides advanced media input control features for conference users. A mechanism for floor control within a conferencing system is defined in the "Binary Floor Control Protocol (BFCP)" specification [RFC4582].
用于会议系统实现的机制，但它为会议用户提供高级媒体输入控制功能。“二进制地板控制协议（BFCP）”规范[RFC4582]中定义了会议系统中的地板控制机制。
Within this framework, a client supporting floor control needs to obtain information for connecting to a floor control server to enable it to issue floor requests. This connection information can be retrieved using information provided by mechanisms such as negotiation using the SDP [RFC4566] offer/answer [RFC3264] exchange on the signaling interface with the focus. Section 11.3 provides a discussion of client authentication of a floor control server.
在此框架内，支持楼层控制的客户端需要获取连接到楼层控制服务器的信息，以使其能够发出楼层请求。该连接信息可以使用机制提供的信息检索，例如在与focus的信令接口上使用SDP[RFC4566]提供/应答[RFC3264]交换进行协商。第11.3节讨论了楼层控制服务器的客户端身份验证。
As well as the client to the floor control server connection information, a client wishing to interact with a floor control server requires access to additional information. This information associates floor control interactions with the appropriate floor instance. Once a connection has been established and authenticated (see [RFC4582] for authentication details), a specific floor control message requires detailed information to uniquely identify a conference, a user, and a floor.
除了客户端到楼层控制服务器的连接信息外，希望与楼层控制服务器交互的客户端还需要访问其他信息。此信息将楼层控制交互与相应的楼层实例相关联。一旦建立了连接并进行了身份验证（有关身份验证的详细信息，请参阅[RFC4582]），特定的楼层控制消息需要详细信息来唯一标识会议、用户和楼层。
The conference is uniquely identified by the conference object ID per Section 6.2.1. This conference object ID must be included in all floor control messages. When the SDP model is used as described in [RFC4583], this identifier maps to the 'confid' SDP attribute.
根据第6.2.1节，会议由会议对象ID唯一标识。此会议对象ID必须包含在所有楼层控制消息中。如[RFC4583]所述使用SDP模型时，此标识符映射到“confid”SDP属性。
Each authorized user associated with a conference object is uniquely represented by a conference user ID per Section 6.3. This conference user ID must be included in all floor control messages. When using SDP offer/answer exchange to negotiate a floor control connection with the focus using the call signaling protocol, the unique conference user identifier is contained in the 'userid' SDP attribute, as defined in [RFC4583].
根据第6.3节，与会议对象关联的每个授权用户由会议用户ID唯一表示。此会议用户ID必须包含在所有楼层控制消息中。当使用SDP提供/应答交换通过呼叫信令协议与focus协商楼层控制连接时，唯一的会议用户标识符包含在[RFC4583]中定义的“userid”SDP属性中。
A media session within a conferencing system can have any number of floors (0 or more) that are represented by the conference identifier. When using SDP offer/answer exchange to negotiate a floor control connection with the focus using the call signaling interface, the unique conference identifier is contained in the 'floorid' SDP attribute, as defined in [RFC4583], e.g., a=floorid:1 m-stream:10 . Each 'floorid' attribute, representing a unique floor, has an 'm-stream' tag containing one or more identifiers. The identifiers represent individual SDP media sessions (as defined using 'm=' from SDP) using the SDP 'Label' attribute, as defined in [RFC4574].
会议系统中的媒体会话可以具有由会议标识符表示的任意楼层数（0或更多）。当使用SDP提供/应答交换通过呼叫信令接口与focus协商楼层控制连接时，唯一的会议标识符包含在[RFC4583]中定义的“floorid”SDP属性中，例如，a=floorid:1 m-stream:10。表示唯一楼层的每个“floorid”属性都有一个包含一个或多个标识符的“m-stream”标记。标识符表示使用SDP“标签”属性的单个SDP媒体会话（使用SDP中的“m=”定义），如[RFC4574]中所定义。
This section addresses how advanced conferencing scenarios, many of which have been described in [RFC4597], are realized using this centralized conferencing framework. The objective of this section is to further illustrate the model, mechanisms, and protocols presented in the previous sections and also serves to validate that the model, mechanisms, and protocols are sufficient to support advanced conferencing scenarios.
本节介绍如何使用此集中式会议框架实现高级会议场景，其中许多场景已在[RFC4597]中描述。本节的目的是进一步说明前几节中介绍的模型、机制和协议，并验证模型、机制和协议是否足以支持高级会议场景。
The scenarios provide a high level primitive view of the necessary operations and general logic flow. The details shown in the scenarios are for illustrative purposes only and don't necessarily reflect the actual structure of the conference control protocol messages nor the detailed data, including states, which are defined in separate documents. It should be noted that not all entities impacted by the request are shown in the diagram (e.g., focus), but rather the emphasis is on the new entities introduced by this centralized conferencing framework.
这些场景提供了必要操作和一般逻辑流的高级基本视图。场景中显示的细节仅用于说明目的，不一定反映会议控制协议消息的实际结构，也不一定反映详细数据，包括单独文档中定义的状态。应该注意的是，图中并没有显示受请求影响的所有实体（例如，focus），而是强调了这个集中会议框架引入的新实体。
There are different ways to create a conference. A participant can create a conference using call signaling means only, such as SIP detailed in [RFC4579]. For a conferencing client to have more flexibility in defining the characteristics and capabilities of a conference, a conferencing client would implement a conference control protocol client. By using a conference control protocol, the client can determine the capabilities of a conferencing system and its various resources.
创建会议有不同的方法。参与者只能使用呼叫信令方式创建会议，如[RFC4579]中详述的SIP。为了使会议客户端能够更灵活地定义会议的特征和功能，会议客户端将实现会议控制协议客户端。通过使用会议控制协议，客户端可以确定会议系统的功能及其各种资源。
Figure 8 provides an example of one client "Alice" determining the conference blueprints available for a particular conferencing system and creating a conference based on the desired blueprint.
图8提供了一个客户机“Alice”确定特定会议系统可用的会议蓝图并基于所需蓝图创建会议的示例。
+--------------------------------+
| Conferencing System |
"Alice" | +------------+|
+--------+ | | ||
| |CCP Request <blueprints> | +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| |<--------------------------|Control |~~~>|Blueprint(s)||
+--------+CCP Response<blueprintA, | |Server | | ||
... | +-----------+ +------------+|
blueprintZ, | |
confUserID> | |
"Alice" |
+--------+ | |
| |CCP Request <reserve, | +------------+|
| | blueprintAConfObjID,| +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| | confUserID> | |Control |~~~>|BlueprintA ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <reservationConfObjID, | | | \|/ |
confID> | | | /|\ |
| | | V |
| | | +------------+|
| | |~~~>|Conference ||
| | | |Reservation ||
| +-----------+ +------------+|
"Alice" | | |
+--------+ | | |
| |CCP Request <add, | V |
| |reservationConfObjID, | +-----------+ +------------+|
| Client |-------------------------->|Conference | |Active ||
| | confID,confUserID> | |Control |~~~>|Conference ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <activeConfObjID, | | | |
confID> | +-----------+ |
+--------------------------------+
+--------------------------------+
| Conferencing System |
"Alice" | +------------+|
+--------+ | | ||
| |CCP Request <blueprints> | +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| |<--------------------------|Control |~~~>|Blueprint(s)||
+--------+CCP Response<blueprintA, | |Server | | ||
... | +-----------+ +------------+|
blueprintZ, | |
confUserID> | |
"Alice" |
+--------+ | |
| |CCP Request <reserve, | +------------+|
| | blueprintAConfObjID,| +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| | confUserID> | |Control |~~~>|BlueprintA ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <reservationConfObjID, | | | \|/ |
confID> | | | /|\ |
| | | V |
| | | +------------+|
| | |~~~>|Conference ||
| | | |Reservation ||
| +-----------+ +------------+|
"Alice" | | |
+--------+ | | |
| |CCP Request <add, | V |
| |reservationConfObjID, | +-----------+ +------------+|
| Client |-------------------------->|Conference | |Active ||
| | confID,confUserID> | |Control |~~~>|Conference ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <activeConfObjID, | | | |
confID> | +-----------+ |
+--------------------------------+
Figure 8: Client Creation of Conference Using Blueprints
图8：使用蓝图创建会议的客户端
Upon receipt of the conference control protocol request for blueprints, the conferencing system would first authenticate "Alice" (and allocate a conference user identifier, if necessary) and then ensure that "Alice" has the appropriate authority based on system policies to receive any blueprints supported by that system. Any blueprints that "Alice" is authorized to use are returned in a response, along with the conference user ID.
在收到会议控制协议蓝图请求后，会议系统将首先验证“Alice”（并在必要时分配会议用户标识符），然后根据系统策略确保“Alice”具有接收该系统支持的任何蓝图的适当权限。“Alice”被授权使用的任何蓝图都会在响应中返回，同时返回会议用户ID。
Upon receipt of the conference control protocol response containing the blueprints, "Alice" determines which blueprint to use for the conference to be created. "Alice" creates a conference object based on the blueprint (i.e., clones) and modifies applicable fields, such as membership list and 'start' time. "Alice" then sends a request to the conferencing system to create a conference reservation based upon the updated blueprint.
在收到包含蓝图的会议控制协议响应后，“Alice”确定用于创建会议的蓝图。“Alice”基于蓝图（即克隆）创建会议对象，并修改适用字段，如成员列表和“开始”时间。“Alice”然后向会议系统发送请求，根据更新的蓝图创建会议预订。
Upon receipt of the conference control protocol request to "reserve" a conference based upon the blueprint in the request, the conferencing system ensures that the blueprint received is a valid blueprint (i.e., the values of the various field are within range). The conferencing system determines the appropriate read/write access of any users to be added to a conference based on this blueprint (using membership, roles, etc.). The conferencing system uses the received blueprint to clone a conference reservation. The conferencing system also reserves or allocates a conference ID to be used for any subsequent protocol requests from any of the members of the conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the reservation through the conference instance.
在收到基于请求中的蓝图“保留”会议的会议控制协议请求后，会议系统确保收到的蓝图是有效的蓝图（即，各个字段的值在范围内）。会议系统根据此蓝图（使用成员资格、角色等）确定要添加到会议中的任何用户的适当读/写访问权限。会议系统使用收到的蓝图克隆会议预订。会议系统还保留或分配会议ID，用于会议任何成员的任何后续协议请求。会议系统通过会议实例维护此会议ID和与预订关联的会议对象ID之间的映射。
Upon receipt of the conference control protocol response to reserve the conference, "Alice" can now create an active conference using that reservation or create additional reservations based upon the existing reservations. In this example, "Alice" has reserved a meetme conference bridge. Thus, "Alice" provides the conference information, including the necessary conference ID, to desired participants. When the first participant, including "Alice", requests to be added to the conference, an active conference and focus are created. The focus is associated with the conference ID received in the request. Any participants that have the authority to manipulate the conference would receive the conference object identifier of the active conference object in the response.
在收到保留会议的会议控制协议响应后，“Alice”现在可以使用该保留创建活动会议，或基于现有保留创建其他保留。在本例中，“Alice”已预订meetme会议桥。因此，“Alice”向期望的参与者提供会议信息，包括必要的会议ID。当第一个参与者（包括“Alice”）请求添加到会议时，将创建一个活动会议和焦点。焦点与请求中接收到的会议ID相关联。任何有权操纵会议的参与者都将在响应中收到活动会议对象的会议对象标识符。
There are different ways to affect a participant state in a conference. A participant can join and leave the conference using call signaling means only, such as SIP. This kind of operation is called "1st party signaling" and does not affect the state of other participants in the conference.
在会议中，有不同的方式影响与会者国。参与者只能使用呼叫信令手段（例如SIP）加入和离开会议。这种操作称为“第一方信令”，不影响会议其他参与者的状态。
Limited operations for controlling other conference participants (a so called "3rd party control") through the focus, using call signaling only, may also be available for some signaling protocols. For example, "Conferencing for SIP User Agents" [RFC4579] shows how SIP with REFER can be used to achieve this functionality.
仅使用呼叫信令，通过焦点控制其他会议参与者（所谓的“第三方控制”）的有限操作也可用于某些信令协议。例如，“SIP用户代理会议”[RFC4579]显示了如何使用SIP和REFER来实现此功能。
In order to perform richer conference control, a user client needs to implement a conference control protocol client. By using a conference control protocol, the client can affect its own state, the state of other participants, and the state of various resources (such as media mixers) that may indirectly affect the state of any of the conference participants.
为了执行更丰富的会议控制，用户客户端需要实现会议控制协议客户端。通过使用会议控制协议，客户端可以影响其自身的状态、其他参与者的状态以及可能间接影响任何会议参与者的状态的各种资源（例如媒体混合器）的状态。
Figure 9 provides an example of one client "Alice" impacting the state of another client "Bob". This example assumes an established conference. In this example, "Alice" wants to add "Bob" to the conference.
图9提供了一个客户机“Alice”影响另一个客户机“Bob”状态的示例。本例假设一个已建立的会议。在本例中，“Alice”希望将“Bob”添加到会议中。
+--------------------------------+
| Conferencing System |
"Alice" | +---------+--+|
+--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | | Active ||
| | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Add, "Bob" > | |Server | | ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Carol" | ' ' '|
+--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+|
| Client |NOTIFY <"Bob"="added">|+------------+ |
+--------+ +--------------------------------+
"Bob"
+--------------------------------+
| Conferencing System |
"Alice" | +---------+--+|
+--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | | Active ||
| | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Add, "Bob" > | |Server | | ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Carol" | ' ' '|
+--------+ NOTIFY <"Bob"="added"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+|
| Client |NOTIFY <"Bob"="added">|+------------+ |
+--------+ +--------------------------------+
"Bob"
Figure 9: Client Manipulation of Conference - Add a Party
图9：会议的客户端操作-添加一方
Upon receipt of the conference control protocol request to "add" a party ("Bob") in the specific conference as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conferencing system must also determine whether "Bob" is already a user of this conferencing system or whether he is a new user.
在收到由会议对象ID标识的在特定会议中“添加”一方（“Bob”）的会议控制协议请求后，会议系统确保“Alice”具有基于与该特定会议对象相关联的策略的适当权限来执行操作。会议系统还必须确定“Bob”是否已经是此会议系统的用户，或者他是否是新用户。
If "Bob" is a new user for this conferencing system, a Conference User Identifier is created for Bob. Based upon the addressing information provided for "Bob" by "Alice", the call signaling to add "Bob" to the conference is instigated through the focus.
如果“Bob”是此会议系统的新用户，则会为Bob创建会议用户标识符。根据“Alice”为“Bob”提供的寻址信息，通过focus发起向会议添加“Bob”的呼叫信令。
Once the call signaling indicates that "Bob" has been successfully added to the specific conference, per updates to the state, and depending upon the policies, other participants (including "Bob") may be notified of the addition of "Bob" to the conference via the conference notification service.
一旦呼叫信令指示“Bob”已成功添加到特定会议，根据状态的更新，并且取决于策略，可通过会议通知服务通知其他参与者（包括“Bob”）将“Bob”添加到会议。
There are different ways to manipulate the media in a conference. A participant can change its own media streams by, for example, sending re-INVITE with new SDP content using SIP only. This kind of operation is called "1st party signaling" and they do not affect the state of other participants in the conference.
在会议中操纵媒体的方式多种多样。参与者可以更改自己的媒体流，例如，仅使用SIP发送带有新SDP内容的重新邀请。这种操作称为“第一方信令”，不会影响会议其他参与者的状态。
In order to perform richer conference control, a user client needs to implement a conference control protocol client. By using a conference control protocol, the client can manipulate the state of various resources, such as media mixers, which may indirectly affect the state of any of the conference participants.
为了执行更丰富的会议控制，用户客户端需要实现会议控制协议客户端。通过使用会议控制协议，客户端可以操纵各种资源（例如媒体混合器）的状态，这可能间接影响任何会议参与者的状态。
Figure 10 provides an example of one client "Alice" impacting the media state of another client "Bob". This example assumes an established conference. In this example, the client, "Alice" whose Role is "moderator" of the conference, wants to mute "Bob" on a medium-size multi-party conference, as his device is not muted (and he's obviously not listening to the call) and background noise in his office environment is disruptive to the conference.
图10提供了一个客户端“Alice”影响另一个客户端“Bob”媒体状态的示例。本例假设一个已建立的会议。在本例中，扮演会议“主持人”角色的客户“Alice”希望在中型多方会议上使“Bob”静音，因为他的设备没有静音（而且他显然没有接听电话），办公室环境中的背景噪音会干扰会议。
+--------------------------------+
| Conferencing System |
"Alice" | +---------+--+|
+--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | |Active ||
| | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Mute, "Bob" > | |Server | | ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Carol" | ' ' '|
+--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+|
| Client | NOTIFY <"Bob"=mute">|+------------+ |
+--------+ +--------------------------------+
"Bob"
+--------------------------------+
| Conferencing System |
"Alice" | +---------+--+|
+--------+ | |policies | ||
| |CCP Request < | +-----------+ +---------+ ||
| Client |-------------------------->|Conference | |Active ||
| | Conference Object ID, | |Control |~~~>|Conference ||
+--------+ Mute, "Bob" > | |Server | | ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Carol" | ' ' '|
+--------+ NOTIFY <"Bob"=mute"> |+------------+ ' ' '|
| |<-------------------------|Notification|<~~~| ||
| Client |. . ||Service | +-------+ ||
+--------+--+ . || | |"Bob" | ||
| |<----------------------| | +-------+----+|
| Client | NOTIFY <"Bob"=mute">|+------------+ |
+--------+ +--------------------------------+
"Bob"
Figure 10: Client Manipulation of Conference - Mute a Party
图10：会议的客户端操作-使一方静音
Upon receipt of the conference control protocol request to "mute" a party ("Bob") in the specific conference as identified by the conference object ID, the conference server ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. "Bob's" status is marked as "recvonly" and the conference object is updated to reflect that "Bob's" media is not to be "mixed" with the conference media.
在收到由会议对象ID标识的对特定会议中的一方（“Bob”）进行“静音”的会议控制协议请求后，会议服务器确保“Alice”具有基于与该特定会议对象相关联的策略的适当权限来执行该操作。“Bob’s”状态标记为“RecvoOnly”，会议对象将更新以反映“Bob’s”媒体不会与会议媒体“混合”。
Depending upon the policies, other participants (including "Bob") may be notified of this change via the conference notification service.
根据政策，其他参与者（包括“Bob”）可能会通过会议通知服务被通知此更改。
A sidebar can be viewed as a separate Conference instance that only exists within the context of a parent conference instance. Although viewed as an independent conference instance, it can not exist without a parent. A sidebar is created using the same mechanisms employed for a standard conference, as described in Section 7.1.
侧栏可以被视为仅存在于父会议实例上下文中的单独会议实例。尽管它被视为一个独立的会议实例，但它不能没有父级而存在。侧栏是使用与标准会议相同的机制创建的，如第7.1节所述。
A conference object representing a sidebar is created by cloning the parent associated with the existing conference and updating any information specific to the sidebar. A sidebar conference object is
通过克隆与现有会议关联的父级并更新特定于侧栏的任何信息，可以创建表示侧栏的会议对象。一个侧栏会议对象是
implicitly linked to the parent conference object (i.e., it is not an independent object) and is associated with the parent conference object identifier, as shown in Figure 11. A conferencing system manages and enforces the parent and appropriate localized restrictions on the sidebar conference object (e.g., no members from outside the parent conference instance can join, sidebar conference cannot exist if parent conference is terminated, etc.).
隐式链接到父会议对象（即，它不是独立对象），并与父会议对象标识符关联，如图11所示。会议系统管理并对侧边栏会议对象实施父级和适当的本地化限制（例如，来自父级会议实例之外的成员不能加入，如果父级会议终止，侧边栏会议将不存在，等等）。
+--------------+
| Conference |
| Object |
| Identifier |
+--------------+
|
|
|
+---------------------+---------------------+
| | |
+-------+-------+ +-------+-------+ +-------+-------+
| Sidebar | | Sidebar | | Sidebar |
| Conference | | Conference | | Conference |
| Object | | Object | | Object |
| Identifier | | Identifier | | Identifier |
+-------+-------+ +-------+-------+ +---------------+
+--------------+
| Conference |
| Object |
| Identifier |
+--------------+
|
|
|
+---------------------+---------------------+
| | |
+-------+-------+ +-------+-------+ +-------+-------+
| Sidebar | | Sidebar | | Sidebar |
| Conference | | Conference | | Conference |
| Object | | Object | | Object |
| Identifier | | Identifier | | Identifier |
+-------+-------+ +-------+-------+ +---------------+
Figure 11: Conference Object Mapping
图11：会议对象映射
Figure 11 illustrates the relationship between a conference object and associated sidebar conference objects within a conferencing system. Each sidebar conference object has a unique conference object identifier, as described in Section 6.2.1. The main conference object identifier acts as a top level identifier for associated sidebars.
图11说明了会议系统中会议对象和相关侧栏会议对象之间的关系。每个侧栏会议对象都有一个唯一的会议对象标识符，如第6.2.1节所述。主会议对象标识符充当相关侧栏的顶级标识符。
A sidebar conference object identifier follows many of the concepts outlined in the cloning tree model described in Section 7.1. A sidebar conference object contains a subset of members from the original conference object. Properties of the sidebar conference object can be manipulated by a Conference Control Protocol using the unique conference object identifier for the sidebar. It is also possible for the top level conference object to enforce policy on the sidebar object (similar to parent enforceable, as discussed in Section 7.1).
侧栏会议对象标识符遵循第7.1节中描述的克隆树模型中概述的许多概念。侧栏会议对象包含来自原始会议对象的成员子集。会议控制协议可以使用侧栏的唯一会议对象标识符来操纵侧栏会议对象的属性。顶级会议对象也可以在侧栏对象上强制执行策略（类似于第7.1节中讨论的父级强制执行）。
Figure 12 provides an example of one client "Alice" involved in active conference with "Bob" and "Carol". "Alice" wants to create a sidebar to have a side discussion with "Bob" while still viewing the video associated with the main conference. Alternatively, the audio from the main conference could be maintained at a reduced volume. "Alice" initiates the sidebar by sending a request to the conferencing system to create a conference reservation based upon the active conference object. "Alice" and "Bob" would remain on the roster of the main conference, such that other participants could be aware of their participation in the main conference, while an internal-sidebar conference is occurring.
图12提供了一个客户机“Alice”与“Bob”和“Carol”参与活动会议的示例。“Alice”想要创建一个侧边栏，以便在观看与主要会议相关的视频时与“Bob”进行旁白讨论。或者，可以将主要会议的音频保持在较低的音量。“Alice”通过向会议系统发送请求来启动侧栏，以根据活动会议对象创建会议预订。“Alice”和“Bob”将保留在主要会议的名册上，这样其他与会者就可以知道他们参加了主要会议，而内部侧栏会议正在举行。
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | +-------+ ||
+--------+ | |"Alice"| ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+----+|
| |CCP Response | | | | |
+--------+ <sidebarResvConfObjID, | | | | |
confID> | | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID, | | | +------------+|
| | video=parent, | | | | |
| | audio=sidebar> | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | | | ||
+--------+ NOTIFY <"Bob"=added> |+------------+ +-------+ ||
| |<-------------------------|Notification|<~~~| | ||
| Client | ||Service | |"Bob" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | +-------+ ||
+--------+ | |"Alice"| ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+----+|
| |CCP Response | | | | |
+--------+ <sidebarResvConfObjID, | | | | |
confID> | | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID, | | | +------------+|
| | video=parent, | | | | |
| | audio=sidebar> | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | | | ||
+--------+ NOTIFY <"Bob"=added> |+------------+ +-------+ ||
| |<-------------------------|Notification|<~~~| | ||
| Client | ||Service | |"Bob" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+
Figure 12: Client Creation of a Sidebar Conference
图12：侧栏会议的客户端创建
Upon receipt of the conference control protocol request to "reserve" a new sidebar conference, based upon the active conference received in the request, the conferencing system uses the received active conference to clone a conference reservation for the sidebar. As discussed previously, the sidebar reservation is NOT independent of the active conference (i.e., parent). The conferencing system also reserves or allocates a conference ID to be used for any subsequent protocol requests from any of the members of the conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the sidebar reservation through the conference instance.
在收到会议控制协议请求“保留”新的侧栏会议后，会议系统根据请求中接收到的活动会议，使用接收到的活动会议克隆侧栏的会议保留。如前所述，侧边栏保留并不独立于活动会议（即父会议）。会议系统还保留或分配会议ID，用于会议任何成员的任何后续协议请求。会议系统通过会议实例维护此会议ID和与侧栏保留关联的会议对象ID之间的映射。
Upon receipt of the conference control protocol response to reserve the conference, "Alice" can now create an active conference using that reservation or create additional reservations based upon the existing reservations. In this example, "Alice" wants only "Bob" to be involved in the sidebar, thus she manipulates the membership. "Alice" also only wants the video from the original conference and wants the audio to be restricted to the participants in the sidebar. Alternatively, "Alice" could manipulate the media values to receive the audio from the main conference at a reduced volume. "Alice" sends a conference control protocol request to update the information in the reservation and to create an active conference.
在收到保留会议的会议控制协议响应后，“Alice”现在可以使用该保留创建活动会议，或基于现有保留创建其他保留。在本例中，“Alice”只希望“Bob”参与侧边栏，因此她操纵成员资格。“Alice”还只想要来自原始会议的视频，并希望音频仅限于侧边栏中的参与者。或者，“Alice”可以操纵媒体值，以较小的音量接收来自主会议的音频。“Alice”发送会议控制协议请求，以更新预订中的信息并创建活动会议。
Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conferencing system must also validate the updated information in the reservation, ensuring that a member like "Bob" is already a user of this conferencing system.
在收到会议控制协议请求以更新保留并为侧栏创建活动会议（由会议对象ID标识）后，会议系统确保“Alice”具有基于与特定会议对象相关联的策略的适当权限来执行操作。会议系统还必须验证预订中的更新信息，确保像“Bob”这样的成员已经是此会议系统的用户。
Depending upon the policies, the initiator of the request (i.e., "Alice") and the participants in the sidebar (i.e., "Bob") may be notified of his addition to the sidebar via the conference notification service.
根据策略，请求的发起人（即“Alice”）和侧栏中的参与者（即“Bob”）可以通过会议通知服务被通知他添加到侧栏中。
Figure 13 provides an example of one client "Alice" involved in an active conference with "Bob", "Carol", "David", and "Ethel". "Alice" gets an important text message via a whisper from "Bob" that a critical customer needs to talk to "Alice", "Bob", and "Ethel". "Alice" creates a sidebar to have a side discussion with the customer "Fred" including the participants in the current conference with the
图13提供了一个客户“Alice”参与与“Bob”、“Carol”、“David”和“Ethel”的活动会议的示例。“Alice”通过“Bob”的耳语收到一条重要的短信，关键客户需要与“Alice”、“Bob”和“Ethel”通话。“Alice”创建一个侧边栏，与客户“Fred”进行侧边讨论，其中包括与
exception of "Carol" and "David", who remain in the active conference. "Alice" initiates the sidebar by sending a request to the conferencing system to create a conference reservation based upon the active conference object. "Alice", "Bob", and "Ethel" would remain on the roster of the main conference in a hold state. Whether or not the hold state of these participants is visible to other participants depends upon the individual and local policy.
“卡罗尔”和“大卫”除外，他们仍在活跃的会议中。“Alice”通过向会议系统发送请求来启动侧栏，以根据活动会议对象创建会议预订。“爱丽丝”、“鲍勃”和“埃塞尔”仍将以搁置状态保留在主要会议的名册上。这些参与者的持有状态是否对其他参与者可见取决于个人和当地政策。
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | +-------+ ||
+--------+ | |"Alice"| ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+ ||
| |CCP Response | | | |"David"| ||
+--------+ <sidebarResvConfObjID, | | | +-------+ ||
confID> | | | |"Ethel"| ||
| | | +-------+----+|
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID, | | | +------------+|
| | video=sidebar, | | | | |
| | audio=sidebar> | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | +-------+ ||
+--------+ | |"Alice"| ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+ ||
| |CCP Response | | | |"David"| ||
+--------+ <sidebarResvConfObjID, | | | +-------+ ||
confID> | | | |"Ethel"| ||
| | | +-------+----+|
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID, | | | +------------+|
| | video=sidebar, | | | | |
| | audio=sidebar> | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | +-------+ ||
+--------+ NOTIFY <"Bob"=added, |+------------+ |"Bob" | ||
| Client |<-------------------------|Notification|<~~~+-------+ ||
+--------+ "Ethel"=added, ||Service | |"Ethel"| ||
"Fred"=added,> || | +-------+ ||
"Ethel" +---| | |"Fred" | ||
+--------+ NOTIFY <"Bob"=added,| |+------------+ +-------+----+|
| Client | <--------------------+ +--------------------------------+
+--------+ "Ethel"=added,"Fred"=added,>
| |"Alice"| ||
"Bob" | +-------+ ||
+--------+ NOTIFY <"Bob"=added, |+------------+ |"Bob" | ||
| Client |<-------------------------|Notification|<~~~+-------+ ||
+--------+ "Ethel"=added, ||Service | |"Ethel"| ||
"Fred"=added,> || | +-------+ ||
"Ethel" +---| | |"Fred" | ||
+--------+ NOTIFY <"Bob"=added,| |+------------+ +-------+----+|
| Client | <--------------------+ +--------------------------------+
+--------+ "Ethel"=added,"Fred"=added,>
Figure 13: Client Creation of an External Sidebar
图13：客户端创建外部侧栏
Upon receipt of the conference control protocol request to "reserve" a new sidebar conference, based upon the active conference received in the request, the conferencing system uses the received active conference to clone a conference reservation for the sidebar. As discussed previously, the sidebar reservation is NOT independent of the active conference (i.e., parent). The conferencing system also reserves or allocates a conference ID to be used for any subsequent protocol requests from any of the members of the conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the sidebar reservation through the conference instance.
在收到会议控制协议请求“保留”新的侧栏会议后，会议系统根据请求中接收到的活动会议，使用接收到的活动会议克隆侧栏的会议保留。如前所述，侧边栏保留并不独立于活动会议（即父会议）。会议系统还保留或分配会议ID，用于会议任何成员的任何后续协议请求。会议系统通过会议实例维护此会议ID和与侧栏保留关联的会议对象ID之间的映射。
Upon receipt of the conference control protocol response to reserve the conference, "Alice" can now create an active conference using that reservation or create additional reservations based upon the existing reservations. In this example, "Alice" wants only "Bob" and "Ethel", along with the new participant "Fred" to be involved in the sidebar; thus, she manipulates the membership. "Alice" sets the media such that the participants in the sidebar don't receive any media from the main conference. "Alice" sends a conference control protocol request to update the information in the reservation and to create an active conference.
在收到保留会议的会议控制协议响应后，“Alice”现在可以使用该保留创建活动会议，或基于现有保留创建其他保留。在本例中，“Alice”只希望“Bob”和“Ethel”以及新参与者“Fred”参与侧边栏；因此，她操纵会员资格。“Alice”设置媒体，使侧边栏中的参与者不会从主会议接收任何媒体。“Alice”发送会议控制协议请求，以更新预订中的信息并创建活动会议。
Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conferencing system must also validate the updated information in the reservation, ensuring whether members like "Fred" are already a user of this conferencing system or whether he
在收到会议控制协议请求以更新保留并为侧栏创建活动会议（由会议对象ID标识）后，会议系统确保“Alice”具有基于与特定会议对象相关联的策略的适当权限来执行操作。会议系统还必须验证预订中的更新信息，以确保像“Fred”这样的成员是否已经是此会议系统的用户，或者
is a new user. Since "Fred" is a new user for this conferencing system, a conference user identifier is created for "Fred". Based upon the addressing information provided for "Fred" by "Alice", the call signaling to add "Fred" to the conference is instigated through the focus.
是一个新用户。由于“Fred”是此会议系统的新用户，因此将为“Fred”创建会议用户标识符。根据“Alice”为“Fred”提供的寻址信息，通过focus发起向会议添加“Fred”的呼叫信令。
Depending upon the policies, the initiator of the request (i.e., "Alice") and the participants in the sidebar (i.e., "Bob" and "Ethel") may be notified of his addition to the sidebar via the conference notification service.
根据策略，可以通过会议通知服务通知请求的发起人（即“Alice”）和侧栏中的参与者（即“Bob”和“Ethel”）他添加到侧栏中。
Floor control with sidebars can be used to realize conferencing scenarios such as an analyst briefing. In this scenario, the conference call has a panel of speakers who are allowed to talk in the main conference. The other participants are the analysts, who are not allowed to speak unless they have the floor. To request access to the floor, they have to join a new sidebar with the moderator and ask their question. The moderator can also whisper to each analyst what their status/position in the floor control queue, similar to the example in Figure 15.
带有侧栏的楼层控制可用于实现会议场景，如分析师简报。在这种情况下，电话会议有一组发言者，他们可以在主要会议上发言。其他参与者是分析师，除非他们有发言权，否则不得发言。为了请求进入会场，他们必须加入一个新的侧边栏，与主持人一起提问。主持人还可以悄悄告诉每个分析师他们在楼层控制队列中的状态/位置，类似于图15中的示例。
Figure 14 provides an example of the configuration involved for this type of conference. As in the previous sidebar examples, there is the main conference along with a sidebar. "Alice" and "Bob" are the main participants in the conference, with "A1", "A2", and "A3" representing the analysts. The sidebar remains active throughout the conference, with the moderator, "Carol", serving as the chair. As discussed previously, the sidebar conference is NOT independent of the active conference (i.e., parent). The analysts are provided the conference object ID associated with the active sidebar when they join the main conference. The conferencing system also allocates a conference ID to be used for any subsequent manipulations of the sidebar conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the active sidebar conference through the conference instance. The analysts are permanently muted while in the main conference. The analysts are moved to the sidebar when they wish to speak. Only one analyst is given the floor at a given time. All participants in the main conference receive audio from the sidebar conference, as well as audio provided by the panelists in the main conference.
图14提供了此类会议所涉及的配置示例。在前面的侧栏示例中，有一个主会议和一个侧栏。“Alice”和“Bob”是会议的主要参与者，“A1”、“A2”和“A3”代表分析师。侧边栏在整个会议期间保持活跃，主持人“卡罗尔”担任主席。如前所述，侧边栏会议并不独立于活动会议（即父级会议）。当分析师加入主会议时，会向他们提供与活动侧栏关联的会议对象ID。会议系统还分配会议ID，用于侧栏会议的任何后续操作。会议系统通过会议实例维护此会议ID和与活动侧栏会议关联的会议对象ID之间的映射。分析师们在主要会议上一直保持沉默。分析员想发言时会移到侧栏。在给定的时间内，只有一名分析师发言。主会议的所有参与者都会收到侧边栏会议的音频，以及主会议中小组成员提供的音频。
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
| +-------+ ||
| |"Alice"| ||
| +-------+ ||
| +-----------+ |"Bob" | ||
| |Conference | +-------+ ||
| |Control |~~~>|"A1" | ||
| |Server | +-------+ ||
| | | |"A2" | ||
| | | +-------+ ||
| | | |"A3" | ||
| | | +-------+----+|
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | |Active ||
| +-----------+ |Sidebar ||
"A1" | |Conference ||
+--------+ Floor Request <"A1", |+------------+ +-------+ ||
| |------------------------->|Floor Ctrl | |"Carol"| ||
|Client | activeSideConfObjID,||Server |~~~>| | ||
+--------+ confID > || | +-------+----+|
|+------------+ | |
| V |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Sidebar ||
"A1" | |Conference ||
+--------+ Floor Granted <"A1", |+------------+ +-------+ ||
| |<-------------------------|Floor Ctrl |<~~~|"Carol"| ||
| Client | activeSideConfObjID,||Server | +-------+ ||
+--------+ confID > || | |"A1" | ||
|+------------+ +-------+----+|
+--------------------------------+
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
| +-------+ ||
| |"Alice"| ||
| +-------+ ||
| +-----------+ |"Bob" | ||
| |Conference | +-------+ ||
| |Control |~~~>|"A1" | ||
| |Server | +-------+ ||
| | | |"A2" | ||
| | | +-------+ ||
| | | |"A3" | ||
| | | +-------+----+|
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | |Active ||
| +-----------+ |Sidebar ||
"A1" | |Conference ||
+--------+ Floor Request <"A1", |+------------+ +-------+ ||
| |------------------------->|Floor Ctrl | |"Carol"| ||
|Client | activeSideConfObjID,||Server |~~~>| | ||
+--------+ confID > || | +-------+----+|
|+------------+ | |
| V |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Sidebar ||
"A1" | |Conference ||
+--------+ Floor Granted <"A1", |+------------+ +-------+ ||
| |<-------------------------|Floor Ctrl |<~~~|"Carol"| ||
| Client | activeSideConfObjID,||Server | +-------+ ||
+--------+ confID > || | |"A1" | ||
|+------------+ +-------+----+|
+--------------------------------+
Figure 14: Floor Control with Sidebars
图14：带侧栏的地板控制
When "A1" wishes to ask a question, he sends a Floor Request message to the floor control server. Upon receipt of the request, the floor control server notifies the moderator, "Carol" of the active sidebar conference, who's serving as the floor chair. Note, that this signaling flow is not shown in the diagram. Since no other analysts have yet requested the floor, "Carol" indicates to the floor control server that "A1" may be granted the floor.
当“A1”想要提问时，他向楼层控制服务器发送楼层请求消息。收到请求后，楼层控制服务器通知主持人“Carol”活动侧栏会议，由他担任楼层主席。注意，图中未显示此信令流。由于还没有其他分析师请求发言权，“Carol”向发言权控制服务器表示“A1”可能获得发言权。
The case of private messages can be handled as a sidebar with just two participants, similar to the example in Section 9.4.1, but rather than using audio within the sidebar, "Alice" could add an additional text based media stream to the sidebar. The other context, referred to as whisper, in this document refers to situations involving one time media targeted to specific user(s). An example of a whisper would be an announcement injected only to the conference chair or to a new participant joining a conference.
与第9.4.1节中的示例类似，私人消息可以作为只有两个参与者的侧栏处理，但“Alice”可以在侧栏中添加额外的基于文本的媒体流，而不是在侧栏中使用音频。本文档中的另一个上下文称为耳语，指的是涉及针对特定用户的一次性媒体的情况。耳语的一个例子是只向会议主席或参加会议的新参与者发出通知。
Figure 15 provides an example of one user "Alice" who's chairing a fixed length conference with "Bob" and "Carol". The configuration is such that only the chair is providing a warning when there are only 10 minutes left in the conference. At that time, "Alice" is moved into a sidebar created by the conferencing system and only "Alice" receives the announcement.
图15提供了一个用户“Alice”与“Bob”和“Carol”主持固定长度会议的示例。这种配置使得只有主席在会议只剩下10分钟时发出警告。此时，“Alice”被移动到会议系统创建的侧栏中，只有“Alice”收到通知。
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
| +-------+ ||
| |"Alice"| ||
| +-------+ ||
| +-----------+ |"Bob" | ||
| |Conference | +-------+ ||
| |Control |~~~>|"Carol"| ||
| |Server | +-------+----+|
| | | | |
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ |Sidebar ||
"Alice" | |Conference ||
+--------+ NOTIFY <"Alice"=added, |+------------+ +-------+ ||
| |<-------------------------|Notification| | | ||
| Client | activeSideConfObjID,||Service |<~~~|"Alice"| ||
+--------+ confID > || | +-------+----+|
|+------------+ |
~~~Announcement provided to "Alice"~~~
| +-----------+ |
| |Conference | |
| |Control | |
| |Server | |
| | | |
| | | \---------+--/|
| | | |\ /||
| | |~~~>+ \ / ||
| | | | \ / ||
| +-----------+ |Sid\bar / ||
"Alice" | |Conf\re/ce ||
+--------+ NOTIFY <"Alice"=removed,|+------------+ +-----\/+ ||
| |<-------------------------|Notification|<~~~| /\| ||
| Client | activeSideConfObjID,||Service | |"Ali/ce\ ||
+--------+ confID > || | +---/---+\---+|
|+------------+ / \ |
+--------------------------------+
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
| +-------+ ||
| |"Alice"| ||
| +-------+ ||
| +-----------+ |"Bob" | ||
| |Conference | +-------+ ||
| |Control |~~~>|"Carol"| ||
| |Server | +-------+----+|
| | | | |
| | | | |
| | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ |Sidebar ||
"Alice" | |Conference ||
+--------+ NOTIFY <"Alice"=added, |+------------+ +-------+ ||
| |<-------------------------|Notification| | | ||
| Client | activeSideConfObjID,||Service |<~~~|"Alice"| ||
+--------+ confID > || | +-------+----+|
|+------------+ |
~~~Announcement provided to "Alice"~~~
| +-----------+ |
| |Conference | |
| |Control | |
| |Server | |
| | | |
| | | \---------+--/|
| | | |\ /||
| | |~~~>+ \ / ||
| | | | \ / ||
| +-----------+ |Sid\bar / ||
"Alice" | |Conf\re/ce ||
+--------+ NOTIFY <"Alice"=removed,|+------------+ +-----\/+ ||
| |<-------------------------|Notification|<~~~| /\| ||
| Client | activeSideConfObjID,||Service | |"Ali/ce\ ||
+--------+ confID > || | +---/---+\---+|
|+------------+ / \ |
+--------------------------------+
Figure 15: Whisper
图15：耳语
When the conferencing system determines that there are only 10 minutes left in the conference which "Alice" is chairing, rather than creating a reservation as was done for the sidebar in Section 9.4.1, the conferencing system directly creates an active sidebar conference, based on the active conference associated with "Alice". As discussed previously, the sidebar conference is NOT independent of the active conference (i.e., parent). The conferencing system also allocates a conference ID to be used for any subsequent manipulations of the sidebar conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the active sidebar conference through the conference instance.
当会议系统确定“Alice”主持的会议只剩下10分钟，而不是像第9.4.1节中对侧栏所做的那样创建预订时，会议系统会根据与“Alice”关联的活动会议直接创建活动侧栏会议。如前所述，侧边栏会议并不独立于活动会议（即父级会议）。会议系统还分配会议ID，用于侧栏会议的任何后续操作。会议系统通过会议实例维护此会议ID和与活动侧栏会议关联的会议对象ID之间的映射。
Immediately upon creation of the active sidebar conference, the announcement media is provided to "Alice". Depending upon the policies, "Alice" may be notified of her addition to the sidebar via the conference notification service. "Alice" continues to receive the media from the main conference.
创建活动侧栏会议后，立即向“Alice”提供公告媒体。根据策略的不同，“Alice”可能会通过会议通知服务被通知添加到侧栏中。“爱丽丝”继续接受主要会议的媒体采访。
Upon completion of the announcement, "Alice" is removed from the sidebar, and the sidebar conference is deleted. Depending upon the policies, "Alice" may be notified of her removal from the sidebar via the conference notification service.
公告完成后，“Alice”将从侧栏中删除，侧栏会议将被删除。根据策略的不同，“Alice”可能会通过会议通知服务从侧栏中被删除。
Each participant can require a different type of announcement and/or recording service from the system. For example, "Alice", the conference chair, could be listening to a roll call while "Bob" may be using a telephony user interface to create a sidebar. Some announcements would apply to all the participants such as "This conference will end in 10 minutes". Recording is often required to capture the names of participants as they join a conference, typically after the participant has entered an access code, as discussed in Section 9.8. These recorded names are then announced to all the participants as the new participant is added to the active conference.
每个参与者都可以要求系统提供不同类型的公告和/或录音服务。例如，会议主席“Alice”可能正在听点名，而“Bob”可能正在使用电话用户界面创建侧边栏。一些公告将适用于所有与会者，如“本次会议将在10分钟后结束”。如第9.8节所述，通常在参与者输入访问代码后，记录参与者参加会议时的姓名时需要进行记录。当新的参与者被添加到活动会议中时，这些记录的姓名将被宣布给所有参与者。
An example of a conferencing recording and announcement, along with collecting the dual tone multi-frequency (DTMF), within the context of this framework, is shown in Figure 16.
图16显示了一个会议录制和公告的示例，以及在此框架中收集双音多频（DTMF）的示例。
+--------------------------------+
| Conferencing System |
"Alice" | +-----------+ |
+--------+ | |Conference | |
| |CCP Request < | |Control | |
| Client |--------------------------->| |Server | |
| |Bob's Conference ID, | | | |
+--------+ Join > | | | |
| | | |
| ~ ~ |
~~~Announcement provided to "Alice"~~~
~~~ Digits collected from "Alice"~~~
| ~ ~ +---------+--+|
| | |~~~>|policies | ||
| | | +---------+ ||
| | | |Active ||
| | | |Conference ||
| | | +-------+ ||
| | | |"Bob" | ||
| | | +-------+ ||
| | | |"Carol"| ||
| | | +-------+----+|
| ~ ~ |
~~~Announcement provided to "Alice"~~~
~~~ Alice records her name ~~~
| ~ ~ +---------+--+|
| | | |policies | ||
| | | +---------+ ||
| | |~~~>|Active ||
| +-----------+ |Conference ||
| +-------+ ||
| |"Bob" | ||
"Bob " | +-------+ ||
+--------+ NOTIFY <"Alice"=added, |+------------+ |"Carol"| ||
| |<-------------------------|Notification| +-------+ ||
| Client | activeSideConfObjID,||Service |<~~~|"Alice"| ||
+--------+ confID > || | +-------+----+|
|+------------+ |
~~~Announcement provided to All Parties~~~
| |
+--------------------------------+
+--------------------------------+
| Conferencing System |
"Alice" | +-----------+ |
+--------+ | |Conference | |
| |CCP Request < | |Control | |
| Client |--------------------------->| |Server | |
| |Bob's Conference ID, | | | |
+--------+ Join > | | | |
| | | |
| ~ ~ |
~~~Announcement provided to "Alice"~~~
~~~ Digits collected from "Alice"~~~
| ~ ~ +---------+--+|
| | |~~~>|policies | ||
| | | +---------+ ||
| | | |Active ||
| | | |Conference ||
| | | +-------+ ||
| | | |"Bob" | ||
| | | +-------+ ||
| | | |"Carol"| ||
| | | +-------+----+|
| ~ ~ |
~~~Announcement provided to "Alice"~~~
~~~ Alice records her name ~~~
| ~ ~ +---------+--+|
| | | |policies | ||
| | | +---------+ ||
| | |~~~>|Active ||
| +-----------+ |Conference ||
| +-------+ ||
| |"Bob" | ||
"Bob " | +-------+ ||
+--------+ NOTIFY <"Alice"=added, |+------------+ |"Carol"| ||
| |<-------------------------|Notification| +-------+ ||
| Client | activeSideConfObjID,||Service |<~~~|"Alice"| ||
+--------+ confID > || | +-------+----+|
|+------------+ |
~~~Announcement provided to All Parties~~~
| |
+--------------------------------+
Figure 16: Recording and Announcements
图16：记录和公告
Upon receipt of the conference control protocol request from "Alice" to join "Bob's" conference, the conferencing system maps the identifier received in the request to the conference object
在收到来自“Alice”的加入“Bob”会议的会议控制协议请求后，会议系统将在请求中接收到的标识符映射到会议对象
representing "Bob's" active conference. The conferencing system determines that a password is required for this specific conference; thus, an announcement asking "Alice" to enter the password is provided to "Alice". Once "Alice" enters the password, it is validated against the policies associated with "Bob's" active conference. The conferencing system then connects to a server that prompts and records "Alice"'s name. The conferencing system must also determine whether "Alice" is already a user of this conferencing system or whether she is a new user.
代表“鲍勃”的活动会议。会议系统确定此特定会议需要密码；因此，向“Alice”提供了一条要求“Alice”输入密码的公告。“Alice”输入密码后，将根据与“Bob”活动会议相关的策略对其进行验证。然后，会议系统连接到一个服务器，该服务器提示并记录“Alice”的名字。会议系统还必须确定“Alice”是否已经是此会议系统的用户，或者她是否是新用户。
If "Alice" is a new user for this conferencing system, a conference user identifier is created for "Alice". Based upon the addressing information provided by "Alice", the call signaling to add "Alice" to the conference is instigated through the focus.
如果“Alice”是此会议系统的新用户，则会为“Alice”创建会议用户标识符。根据“Alice”提供的寻址信息，通过focus发起向会议添加“Alice”的呼叫信令。
Once the call signaling indicates that "Alice" has been successfully added to the specific conference, per updates to the state, and depending upon the policies, other participants (e.g., "Bob") are notified of the addition of "Alice" to the conference via the conference notification service, and an announcement is provided to all the participants indicating that "Alice" has joined the conference.
一旦呼叫信令指示“Alice”已成功添加到特定会议，根据状态更新，并根据策略，通过会议通知服务通知其他参与者（例如，“Bob”）已将“Alice”添加到会议中，并向所有与会者发出公告，表明“爱丽丝”已加入会议。
The conferencing system also needs the capability to monitor for DTMF from each individual participant. This would typically be used to enter the identifier and/or access code for joining a specific conference.
会议系统还需要能够监控每个参与者的DTMF。这通常用于输入用于加入特定会议的标识符和/或访问代码。
An example of DTMF monitoring, within the context of the framework elements, is shown in Figure 16.
图16显示了框架元素上下文中的DTMF监控示例。
The capability to observe a conference allows a participant with the appropriate authority to listen to the conference, typically without being an active participant and often as a hidden participant. When such a capability is available on a conferencing system, there is often an announcement provided to each participant as they join the conference indicating the call may be monitored. This capability is useful in the context of conferences, which might be experiencing technical difficulties, thus allowing a technician to listen in to evaluate the type of problem.
观察会议的能力允许具有适当权限的参与者收听会议，通常不作为积极参与者，通常作为隐藏参与者。当会议系统上有这样的功能时，通常会在每个参与者加入会议时向他们发出通知，表明呼叫可能被监控。此功能在可能遇到技术困难的会议中非常有用，因此允许技术人员收听以评估问题类型。
This capability could also apply to call center applications as it provides a mechanism for a supervisor to observe how the agent is handling a particular call with a customer. This scenario can be
此功能也适用于呼叫中心应用程序，因为它为主管提供了一种机制，以观察代理如何处理与客户的特定呼叫。这种情况可能会发生
handled by a supervisor adding themselves to the existing active conference, with a listen only audio media path. Whether the agent is aware of when the supervisor joins the call should be configurable.
由主管通过仅收听音频媒体路径将自己添加到现有活动会议中进行处理。代理是否知道主管何时加入呼叫应该是可配置的。
Taking the supervisor capability one step further introduces a scenario whereby the agent can hear the supervisor, as well as the customer. The customer can still only hear the agent. This scenario would involve the creation of a sidebar involving the agent and the supervisor. Both the agent and supervisor receive the audio from the main conference. When the agent speaks, it is heard by the customer in the main conference. When the supervisor speaks, it is heard only by the agent in the sidebar conference.
将主管功能进一步引入一个场景，代理可以听到主管和客户的声音。客户仍然只能听到代理的声音。此场景将涉及创建一个涉及代理和主管的侧栏。代理和主管都接收来自主会议的音频。当代理发言时，客户会在主会议上听到。当主管发言时，只有代理在侧边栏会议上才能听到。
An example of observing and coaching is shown in Figure 17. In this example, call center agent "Bob" is involved in a conference with customer "Carol". Since "Bob" is a new agent and "Alice" sees that he has been on the call with "Carol" for longer than normal, she decides to observe the call and coach "Bob" as necessary.
观察和指导的示例如图17所示。在本例中，呼叫中心代理“Bob”参与了与客户“Carol”的会议。由于“鲍勃”是一名新经纪人，“爱丽丝”看到他与“卡罗尔”通话的时间比平时长，她决定观察通话情况，并在必要时指导“鲍勃”。
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | | ||
+--------+ | | ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+----+|
| |CCP Response | | | | |
+--------+ <sidebarResvConfObjID, | | | | |
confID> | | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID> | | | +------------+|
| | | | | | |
| | | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | | | ||
+--------+ NOTIFY <"Bob"=added, |+------------+ +-------+ ||
| |<-------------------------|Notification|<~~~| | ||
| Client | "chair"="Alice" ||Service | |"Bob" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+
+--------------------------------+
| Conferencing System |
| +---------+--+|
| |policies | ||
| +---------+ ||
| |Active ||
| |Conference ||
"Alice" | | ||
+--------+ | | ||
| |CCP Req <createSidebar, | +-------+ ||
| | activeConfObjID, | +-----------+ |"Bob" | ||
| Client |-------------------------->|Conference | +-------+ ||
| | confUserID> | |Control |~~~>|"Carol"| ||
| |<--------------------------|Server | +-------+----+|
| |CCP Response | | | | |
+--------+ <sidebarResvConfObjID, | | | | |
confID> | | | V |
| | | +---------+--+|
| | | |policies | ||
| | |~~~>+---------+ ||
| | | | ||
| +-----------+ | ||
"Alice" | | Sidebar ||
+--------+ | | Reservation||
| |CCP Request <update, | +-----------+ | ||
| | sidebarResvConfObjID,| | | | ||
| Client |-------------------------->| |~~~>| ||
| | confID,confUserID> | | | +------------+|
| | | | | | |
| | | |Conference | | |
| | | |Control | V |
| | | |Server | +---------+--+|
| |CCP Response | | | |policies | ||
| | <activeSideConfObjID,| | | +---------+ ||
| |<--------------------------| | |Active ||
+--------+ confID> | | | |Sidebar ||
| | | |Conference ||
| +-----------+ +-------+ ||
| |"Alice"| ||
"Bob" | | | ||
+--------+ NOTIFY <"Bob"=added, |+------------+ +-------+ ||
| |<-------------------------|Notification|<~~~| | ||
| Client | "chair"="Alice" ||Service | |"Bob" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+
Figure 17: Supervisor Creating a Sidebar for Observing/Coaching
图17：主管创建用于观察/指导的侧栏
Upon receipt of the conference control protocol request from "Alice" to "reserve" a new sidebar conference, based upon the active conference received in the request, the conferencing system uses the received active conference to clone a conference reservation for the sidebar. The conferencing system also reserves or allocates a conference ID to be used for any subsequent protocol requests from any of the members of the conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the sidebar reservation through the conference instance.
在接收到来自“Alice”的会议控制协议请求以“保留”一个新的侧栏会议后，会议系统基于请求中接收到的活动会议，使用接收到的活动会议克隆侧栏的会议保留。会议系统还保留或分配会议ID，用于会议任何成员的任何后续协议请求。会议系统通过会议实例维护此会议ID和与侧栏保留关联的会议对象ID之间的映射。
Upon receipt of the conference control protocol response to reserve the conference, "Alice" can now create an active conference using that reservation or create additional reservations based upon the existing reservations. In this example, "Alice" wants only "Bob" to be involved in the sidebar; thus, she manipulates the membership. "Alice" also wants the audio to be received by herself and "Bob" from the original conference, but wants any outgoing audio from herself to be restricted to the participants in the sidebar, whereas "Bob's" outgoing audio should go to the main conference, so that both "Alice" and the customer "Carol" hear the same audio from "Bob". "Alice" sends a conference control protocol request to update the information in the reservation and to create an active conference.
在收到保留会议的会议控制协议响应后，“Alice”现在可以使用该保留创建活动会议，或基于现有保留创建其他保留。在本例中，“Alice”只希望侧边栏中包含“Bob”；因此，她操纵会员资格。“Alice”还希望自己和“Bob”从原始会议接收音频，但希望自己发出的任何音频仅限于侧边栏中的参与者，而“Bob”发出的音频应转到主会议，以便“Alice”和客户“Carol”都能听到“Bob”发出的相同音频。“Alice”发送会议控制协议请求，以更新预订中的信息并创建活动会议。
Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. Based upon the addressing information provided for "Bob" by "Alice", the call signaling to add "Bob" to the sidebar with the appropriate media characteristics is instigated through the focus.
在收到会议控制协议请求以更新保留并为侧栏创建活动会议（由会议对象ID标识）后，会议系统确保“Alice”具有基于与特定会议对象相关联的策略的适当权限来执行操作。基于“Alice”为“Bob”提供的寻址信息，通过focus发起将“Bob”添加到具有适当媒体特征的侧栏的呼叫信令。
"Bob" is notified of his addition to the sidebar via the conference notification service; thus, he is aware that "Alice", the supervisor, is available for coaching him through this call.
“Bob”通过会议通知服务被通知添加到侧栏中；因此，他知道主管“Alice”可以通过此电话指导他。
The SIP Conferencing Framework [RFC4353] provides an overview of a wide range of centralized conferencing solutions known today in the conferencing industry. The document introduces a terminology and logical entities in order to systemize the overview and to show the common core of many of these systems. The logical entities and the listed scenarios in the SIP Conferencing Framework are used to
SIP会议框架[RFC4353]概述了会议行业目前已知的各种集中式会议解决方案。本文档介绍了术语和逻辑实体，以便系统化概述，并展示其中许多系统的共同核心。SIP会议框架中的逻辑实体和列出的场景用于
illustrate how SIP [RFC3261] can be used as a signaling means in these conferencing systems. The SIP Conferencing Framework does not define new conference control protocols to be used by the general conferencing system. It uses only basic SIP [RFC3261], the SIP Conferencing for User Agents [RFC4579], and the SIP Conference Package [RFC4575] for basic SIP conferencing realization.
说明SIP[RFC3261]如何在这些会议系统中用作信令手段。SIP会议框架未定义通用会议系统使用的新会议控制协议。它仅使用基本SIP[RFC3261]、用于用户代理的SIP会议[RFC4579]和用于基本SIP会议实现的SIP会议包[RFC4575]。
This centralized conferencing framework document defines a particular centralized conferencing system and the logical entities implementing it. It also defines a particular data model and refers to the set of protocols (beyond call signaling means) to be used among the logical entities for implementing advanced conferencing features. The purpose of the XCON Working Group and this framework is to achieve interoperability between the logical entities from different vendors for controlling different aspects of advanced conferencing applications.
此集中式会议框架文档定义了一个特定的集中式会议系统以及实现它的逻辑实体。它还定义了一个特定的数据模型，并引用了在逻辑实体之间用于实现高级会议功能的一组协议（超越呼叫信令手段）。XCON工作组和该框架的目的是实现来自不同供应商的逻辑实体之间的互操作性，以控制高级会议应用程序的不同方面。
The logical entities defined in the two frameworks are not intended to be mapped one-to-one. The two frameworks differ in the interpretation of the internal conferencing system decomposition and the corresponding operations. Nevertheless, the basic SIP [RFC3261], the SIP Conferencing for User Agents [RFC4579], and the SIP Conference Package [RFC4575] are fully compatible with both framework documents. The basis for compatibility is provided by including the basic data elements defined in [RFC4575] in the Conference Information Data Model for Centralized Conferencing (XCON) [XCON-COMMON]. User agents that only support [RFC4579] and do not support the Conferencing Control Protocol are still provided basic SIP conferencing, but cannot take advantage of any of the advanced features.
这两个框架中定义的逻辑实体并不打算一一映射。这两个框架对内部会议系统分解和相应操作的解释不同。然而，基本SIP[RFC3261]、用户代理SIP会议[RFC4579]和SIP会议包[RFC4575]与这两个框架文档完全兼容。通过将[RFC4575]中定义的基本数据元素包含在集中式会议（XCON）[XCON-COMMON]的会议信息数据模型中，提供了兼容性的基础。仅支持[RFC4579]且不支持会议控制协议的用户代理仍提供基本SIP会议，但无法利用任何高级功能。
There are a wide variety of potential attacks related to conferencing, due to the natural involvement of multiple endpoints and the many, often user-invoked, capabilities provided by the conferencing system. Examples of attacks include the following: an endpoint attempting to listen to conferences 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 conferences it is not allowed to create.
由于多个端点的自然参与以及会议系统提供的许多（通常是用户调用的）功能，与会议相关的潜在攻击种类繁多。攻击的示例包括：一个端点试图侦听其无权参与的会议，一个端点试图断开其他用户的连接或使其静音，以及一个端点在试图创建不允许创建的会议时窃取服务。
There are several issues surrounding security of this conferencing framework. One set of issues involves securing the actual protocols and the associated authorization mechanisms. This first set of issues should be addressed in the specifications specific to the protocols described in Section 8 and policy control. The protocols used for manipulation and retrieval of confidential information need
围绕此会议框架的安全性存在几个问题。一组问题涉及保护实际协议和相关授权机制。第一组问题应在第8节和策略控制中所述协议的特定规范中解决。用于处理和检索机密信息的协议需要
to support a confidentiality and integrity mechanism. Similar requirements apply for the floor control protocols. Section 11.3 discusses an approach for client authentication of a floor control server. It is RECOMMENDED that all the protocols that interface with the conferencing system implement Transport Layer Security (TLS).
支持机密性和完整性机制。类似要求适用于地板控制协议。第11.3节讨论了楼层控制服务器的客户端身份验证方法。建议与会议系统接口的所有协议都实现传输层安全性（TLS）。
There are also security issues associated with the authorization to perform actions on the conferencing system to invoke specific capabilities. Section 5.2 discusses the policies associated with the conference object to ensure that only authorized entities are able to manipulate the data to access the capabilities. Another set of issues involves the privacy and security of the identity of a user in the conference, which is discussed in Section 11.2.
还存在与授权在会议系统上执行操作以调用特定功能相关的安全问题。第5.2节讨论了与会议对象相关的策略，以确保只有经授权的实体才能操作数据以访问功能。另一组问题涉及会议中用户身份的隐私和安全，第11.2节对此进行了讨论。
A final issue is related to Denial of Service (DoS) attacks on the conferencing system itself. In order to minimize the potential for DoS attacks, it is recommended that conferencing systems require user authentication and authorization for any client participating in a conference. It is recommended that the specific signaling and media protocols include mechanisms to minimize the potential for DoS.
最后一个问题与对会议系统本身的拒绝服务（DoS）攻击有关。为了将DoS攻击的可能性降至最低，建议会议系统要求参与会议的任何客户端都具有用户身份验证和授权。建议特定的信令和媒体协议包括将拒绝服务可能性降至最低的机制。
Many policy authorization decisions are based on the identity of the user or the role that a user may have. Conferencing systems typically require authentication of users to validate their identity. There are several ways that a user might authenticate its identity to the system. For users joining a conference using one of the call signaling protocols, the user authentication mechanisms for the specific protocol often suffice. For the case of users joining the conference via SIP signaling or using the conference control protocol, TLS is RECOMMENDED.
许多策略授权决策都基于用户的身份或用户可能具有的角色。会议系统通常需要用户身份验证来验证其身份。用户可以通过多种方式向系统验证其身份。对于使用呼叫信令协议之一加入会议的用户，特定协议的用户认证机制通常就足够了。对于通过SIP信令或使用会议控制协议加入会议的用户，建议使用TLS。
The conferencing system may also know (e.g., out-of-band mechanisms) about specific users and assign passwords to allow these users to be authorized. In some cases (e.g., Public Switched Telephone Network (PSTN) users), additional authorization may be required to allow the user to participate in the conference. This may be in the form of an Interactive Voice Response (IVR) system or other means. The users may also be authorized by knowing a particular conference ID and a Personal Identification (PIN) for it. Sometimes, a PIN is not required and the conference ID is used as a shared secret.
会议系统还可以知道（例如，带外机制）特定用户的情况，并分配密码以允许授权这些用户。在某些情况下（例如，公共交换电话网（PSTN）用户），可能需要额外的授权才能允许用户参加会议。这可以是交互式语音应答（IVR）系统或其他方式的形式。用户还可以通过知道特定会议ID和其个人标识（PIN）来被授权。有时，不需要PIN，会议ID用作共享机密。
In the cases where a user is authorized via multiple mechanisms, it is up to the conferencing system to correlate (if desired) the authorization of the call signaling interface with other authorization mechanisms. A conferencing system can avoid the problem with multiple mechanisms by restricting the methods by which
在通过多个机制授权用户的情况下，由会议系统将呼叫信令接口的授权与其他授权机制相关联（如果需要）。会议系统可以通过限制使用多种机制的方法来避免问题
a conference can be joined. For example, many conferencing systems that provide a web interface for conferences correlate the PSTN call signaling by forcing a dial-out mode for joining the conference. Thus, there is only the need for a single PIN or password to join the conference.
可以参加会议。例如，许多为会议提供web接口的会议系统通过强制拨号模式加入会议来关联PSTN呼叫信令。因此，加入会议只需要一个PIN或密码。
When a conferencing system presents the identity of authorized users, it may choose to provide information about the way the identity was proven or verified by the system. A user may also come as a completely unauthenticated user into the system -- this fact needs also to be communicated to interested parties.
当会议系统显示授权用户的身份时，它可以选择提供有关系统证明或验证身份的方式的信息。用户也可能以完全未经验证的用户身份进入系统——这一事实也需要传达给相关方。
When guest users interact with the system, it is often in the context of a particular conference. In this case, the user may provide a PIN or a password that is specific to the conferences and authorizes the user to take on a certain role in that conference. The guest user can then perform actions that are allowed to any user with that role.
当来宾用户与系统交互时，通常是在特定会议的上下文中。在这种情况下，用户可以提供特定于会议的PIN或密码，并授权用户在该会议中担任特定角色。然后，来宾用户可以执行任何具有该角色的用户都可以执行的操作。
The term password refers to the usual, reasonable sized and hard to predict shared secret. Today, users often have passwords containing up to 30 bits (8-16 characters) of entropy. A PIN is a special password case -- a shared secret that is only numeric and often contains a fairly small number of bits (often as few as 10 bits or 3 digits). When conferencing systems are used for audio on the PSTN, there is often a need to authenticate using a PIN. Typically, if the user fails to provide the correct PIN a few times in a row, the PSTN call is disconnected. The rate of making the calls and getting to the point to enter a PIN makes it fairly hard to do an exhaustive search of the PIN space even for 4 digit PINs. When using a high speed interface to connect to a conferencing system, it is often possible to do thousands of attempts per second and the PIN space could quickly be searched. Because of this, it is not appropriate to use PINs for authorization on any of the interfaces that provide fast queries or many simultaneous queries.
术语密码是指通常的、大小合理且难以预测的共享秘密。如今，用户的密码通常包含多达30位（8-16个字符）的熵。PIN码是一种特殊的密码形式——一种仅为数字的共享秘密，通常包含相当少的位（通常只有10位或3位）。当会议系统用于PSTN上的音频时，通常需要使用PIN进行身份验证。通常，如果用户连续几次未能提供正确的PIN，PSTN呼叫将断开。打电话和直接输入PIN码的速度使得即使是4位PIN码，也很难对PIN码空间进行彻底搜索。当使用高速接口连接到会议系统时，通常每秒可以进行数千次尝试，并且可以快速搜索PIN空间。因此，在提供快速查询或许多同时查询的任何接口上使用PIN进行授权都是不合适的。
Once a user is authenticated and authorized through the various mechanisms available on the conferencing system, a conference user identifier is associated with any signaling specific user identifiers that may have been used for authentication and authorization. This conference user identifier may be provided to a specific user through the conference notification interface and will be provided to users that interact with the conferencing system using the conference control protocol. This conference user identifier is required for any subsequent operations on the conference object.
一旦用户通过会议系统上可用的各种机制被认证和授权，会议用户标识符就与可能已经用于认证和授权的任何信令特定用户标识符相关联。该会议用户标识符可通过会议通知接口提供给特定用户，并将提供给使用会议控制协议与会议系统交互的用户。此会议用户标识符对于会议对象上的任何后续操作都是必需的。
This conferencing system has an idea of the identity of a user, but this does not mean it can reveal this identity to other users, due to privacy considerations. Users can select various options for revealing their identity to other users. A user can be "hidden" such that other users can not see they are participants in the conference, "anonymous" such that users can see that another user is there, but not see the identity of the user, or they can be "public" where other users can see their identity. If there are multiple "anonymous" users, other parties will be able to see them as independent "anonymous" parties and will be able to tell how many "anonymous" parties are in the conference. Note, that the visibility to other participants is dependent on their roles. For example, users' identity (including "anonymous" and "hidden") may be displayed to the moderator or administrator, subject to a conferencing system's local policies. "Hidden" status is often used by automated or machine participants of a conference (e.g., call recording) and is also used in many call center situations.
此会议系统具有用户身份的概念，但这并不意味着出于隐私考虑，它可以将此身份透露给其他用户。用户可以选择各种选项向其他用户显示其身份。一个用户可以是“隐藏的”，这样其他用户就看不到他们是会议的参与者，“匿名的”，这样用户就可以看到另一个用户在那里，但看不到用户的身份，或者他们可以是“公开的”，其他用户可以看到他们的身份。如果有多个“匿名”用户，其他各方将能够将其视为独立的“匿名”方，并能够知道会议中有多少“匿名”方。请注意，对其他参与者的可见性取决于他们的角色。例如，根据会议系统的本地策略，可以向主持人或管理员显示用户的身份（包括“匿名”和“隐藏”）。“隐藏”状态通常由会议的自动或机器参与者使用（例如，通话记录），并且也用于许多呼叫中心情况。
Since a conferencing system based on this framework allocates a unique conference user identifier for each user of the conferencing system, it is not necessary to distribute any signaling specific user identifier to other users or participants. Access to any signaling specific user identifiers can be controlled by applying the appropriate access control to the signaling specific user identifiers in the data schema.
由于基于此框架的会议系统为会议系统的每个用户分配唯一的会议用户标识符，因此无需将任何信令特定的用户标识符分配给其他用户或参与者。可以通过对数据模式中的信令特定用户标识符应用适当的访问控制来控制对任何信令特定用户标识符的访问。
The floor control protocol contains mechanisms that clients can use to authenticate servers, and that servers can use to authenticate clients, as described in Section 9 of [RFC4582]. The precise mechanisms used for such authentication can vary depending on the call control protocol used. Clients using call control protocols that employ an SDP offer/answer model, such as SIP, use the mechanism described in Section 8 of [RFC4583]. Clients using other call control protocols make use of the mechanisms described in the BFCP Connection Establishment document [RFC5018].
如[RFC4582]第9节所述，楼层控制协议包含客户端可用于验证服务器的机制，以及服务器可用于验证客户端的机制。用于此类身份验证的精确机制可能因使用的呼叫控制协议而异。使用采用SDP提供/应答模型（如SIP）的呼叫控制协议的客户端使用[RFC4583]第8节中描述的机制。使用其他呼叫控制协议的客户端使用BFCP连接建立文档[RFC5018]中描述的机制。
This document is a result of architectural discussions among IETF XCON Working Group participants. The authors would like to thank Henning Schulzrinne for the "Conference Object Tree" proposal and general feedback, Cullen Jennings for providing input for the "Security Considerations" section, and Keith Lantz, Dave Morgan, Oscar Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson,
本文件是IETF XCON工作组参与者之间架构讨论的结果。作者要感谢Henning Schulzrinne提出的“会议对象树”提案和一般反馈，Cullen Jennings为“安全考虑”部分提供的意见，以及Keith Lantz、Dave Morgan、Oscar Novo、Roni Even、Umesh Chandra、Avshalom Houri、Sean Olson、，
Rohan Mahy, Brian Rosen, Pierre Tane, Bob Braudes, Gregory Sperounes, and Gonzalo Camarillo for their reviews and constructive input. In addition, the authors would like to thank Scott Brim for his gen-art review comments and Kurt Zeilenga for his secdir review comments.
感谢Rohan Mahy、Brian Rosen、Pierre Tane、Bob Braudes、Gregory Sperounes和Gonzalo Camarillo的评论和建设性意见。此外，作者还要感谢Scott Brim的gen art review评论和Kurt Zeilenga的secdir评论。
[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月。
[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月。
[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月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[RFC2445]Dawson，F.和Stenerson，D.，“互联网日历和调度核心对象规范（iCalendar）”，RFC 24451998年11月。
[RFC4245] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005.
[RFC4245]Levin，O.和R.Een，“紧耦合SIP会议的高级别要求”，RFC 42452005年11月。
[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月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[RFC4376] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, February 2006.
[RFC4376]Koskelainen，P.，Ott，J.，Schulzrinne，H.，和X.Wu，“地板控制协议的要求”，RFC 4376，2006年2月。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4597]伊恩，R.和N.伊斯梅尔，“会议场景”，RFC4597，2006年8月。
[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月。
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4582]Camarillo，G.，Ott，J.，和K.Drage，“二进制地板控制协议（BFCP）”，RFC 4582，2006年11月。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4574]Levin，O.和G.Camarillo，“会话描述协议（SDP）标签属性”，RFC 45742006年8月。
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
[RFC4583]Camarillo，G.“二进制地板控制协议（BFCP）流的会话描述协议（SDP）格式”，RFC4583，2006年11月。
[XCON-COMMON] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference Information Data Model for Centralized Conferencing (XCON)", Work in Progress, March 2008.
[XCON-COMMON]Novo，O.，Camarillo，G.，Morgan，D.，和R.Een，“集中会议的会议信息数据模型（XCON）”，正在进行的工作，2008年3月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]Campbell，B.，Mahy，R.，和C.Jennings，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
[RFC5018] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, September 2007.
[RFC5018]Camarillo，G.“二进制地板控制协议（BFCP）中的连接建立”，RFC 5018，2007年9月。
Authors' Addresses
作者地址
Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX
德克萨斯州理查森湖畔大道2201号玛丽·巴恩斯北电
EMail: mary.barnes@nortel.com
EMail: mary.barnes@nortel.com
Chris Boulton Avaya Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA
Chris Boulton Avaya大厦3 Wern Fawr Lane St Mellons Cardiff，南威尔士CF3 5EA
EMail: cboulton@avaya.com
EMail: cboulton@avaya.com
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
奥利特·莱文微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: oritl@microsoft.com
EMail: oritl@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.