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
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は、この文書の一元会議モデルの文脈では、集中会議Frameworkと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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」は、[RFC2119]、BCP 14に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
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（S）を生成する論理エンティティです。
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.
フロアチェア：フロアチェアは、1階へのアクセスを管理するために許可され、アクセスを許可、拒否、または取り消すことができ、フロア制御プロトコル準拠のクライアント、人間の参加者または自動化されたエンティティのいずれか、です。フロアチェアは、会議のインスタンス内の参加者である必要はありません。
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）の特定の参加者（複数可）に1回のメディア入力を含む、サイドバーを使用して達成します。ささやきの例では、唯一の会議議長や会議に参加する新しい参加者に注入された発表となります。
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.
集中型の会議は、会議フォーカスと呼ばれる中央のエンドポイントと、会議参加者と呼ばれる、エンドポイントの関連付けです。焦点は、各界面シグナリング別個のコールを維持することによって、参加者と直接ピア関係を有しています。したがって、この集中型の会議モデルでは、コールシグナリンググラフは常にスターです。
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コール制御会議とSIP会議フレームワーク[RFC4353]ユーザーエージェントのための[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に同定誰と論理的な機能要素を介してアクセスされます病巣の数、および通知サービス。会議制御プロトコル（CCP）は、会議やメディア制御クライアントと会議制御サーバとの間のインターフェースを提供します。フロア制御プロトコル（例えば、バイナリフロア制御プロトコル（BFCP））はフロア制御クライアントとフロア制御サーバとの間のインターフェースを提供します。コールシグナリングプロトコル（例えば、SIP、H.323、Jabberの、Q.931、ISUPなど）コールシグナリングクライアントと焦点との間のインタフェースを提供します。通知プロトコル（例えばSIPを通知[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 .
....................................................................
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は、この一元化会議Frameworkと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. | | |
| | +----------------------------------------------+ | |
| +--------------------------------------------------+ |
+------------------------------------------------------+
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 conference object, including the organization of the conference information is detailed in a separate document [XCON-COMMON].
この会議フレームワークに基づくシステムでは、同じ会議オブジェクトタイプは、例えば、会議システムの機能を発現する会議リソースを予約する、または進行中の会議の状態を反映するものとして、会議の異なる段階の間会議の表現に使用されます。第7節は、会議オブジェクトの利用意味を説明しています。会議情報の組織を含む会議オブジェクトの正確なXMLスキーマは、別の文書[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.
アクティブ状態の会議を表す会議オブジェクトは、会議識別子をシグナリングする複数のコールを有することができます。例えば、各コールシグナリングプロトコルのための1つがサポートされています。アクティブな会議の対象と会議の焦点との間の1対1のマッピングがあります。フォーカスは、明示的にアクティブな会議オブジェクトによってサポートされる各シグナリングプロトコルの一意の会議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 |
+----------------+ +--------------+ +---------------+
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.
ユーザは、会議を作成したり、参加したいとユーザが特定の会議の会議オブジェクト識別子を有していない場合、より一般的なシグナル伝達機構が適用されます。ユーザがアクセスするための事前構成会議オブジェクト識別子を有することができる会議システム又は他のシグナリングプロトコルを使用することができ、会議システムは、特定の会議オブジェクト識別子にそれらをマッピングします。会議が確立されると、会議のオブジェクト識別子は、会議データのいずれかを操作したり、高度な会議機能のいずれかを利用するユーザーのために必要です。同じ概念は、他のシグナリングプロトコルを使用して会議に参加するユーザーに適用されます。彼らは、最初に特定の会議システムによってサポートされる他のシグナリングプロトコルのいずれかを使用して会議に参加することが可能であるが、会議オブジェクト識別子は、会議データのいずれかを操作したり、高度な会議機能のいずれかを利用するために使用されなければなりません。前述のように、会議オブジェクト識別子のユーザが学習する機構は異なり、会議制御プロトコルを介して、データ・モデル、会議パッケージを使用して、または完全に電子メールまたはウェブインターフェースとしてバンドメカニズムの外であってもよいです。
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.
ユーザ識別子を配布するための典型的なモードでは、クライアントの設定を会議中にバンドの外にあります。したがって、機構は、集中型会議フレームワークおよびプロトコルの範囲外です。しかし、会議システムは、割り当てと分配ユーザ識別子を会議システムと第1のシグナリング相互作用の間に、そのような青写真のための最初の要求として、または会議制御プロトコルを使用して既存の会議に新しいユーザを追加することができなければなりません。ユーザがダイヤルイン会議のため、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.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.
新しいオブジェクトが作成されたら、セクション6.2.1で説明したように、それは、システムによって割り当てられた固有の会議オブジェクトのURIによって対処することができます。デフォルトでは、新しく作成されたオブジェクトは、親オブジェクト内に存在するすべてのデータが含まれています。新しく作成されたオブジェクトは、親でサポートされているスキーマ・タイプの中、それに含まれるデータを拡張することができます。また、そのオブジェクトへの読み取り/書き込みアクセスを制限することができます。オブジェクトが独立していない限り、しかし、それは親オブジェクトによって課さアクセス制限を変更することはできません。
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は、親（親A）とは独立して作成された会議（親B）の一例を示す図です。親Bは2つのつの子オブジェクト、子供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-+-----------------------+
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-+-----------------------+
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-+-----------------------+
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 GMT木曜日に始まり、毎週のミーティング）。
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.
このような機能を実現できるようにするには、会議システムは、適切にスケジュールし、定期的な会議の一部を形成して会議の予約を維持できるようにする必要があります。この文書で提案されたメカニズムは、高度な会議のスケジューリング機能を実現するために、第5節で紹介した概念と労働組合の「インターネットカレンダーとスケジュールのコアオブジェクト」[RFC2445]で定義された仕様を利用します。
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 |
+-------------+
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のオブジェクトを含め、検証され、得られた会議予約が作成されます。セクション6.2.1に導入され、[XCON-COMMON]で定義されるように、（hd87928374例えば、XCON）会議予約を一意会議オブジェクト識別子によって会議システム内で表現されます。このユニークなURIがクライアントに返され、将来の操作が必要な場合はCCP要求を使用して、（例えば、「スタート」の時間を変更する）、会議予約を参照するために使用することができます。
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は、繰り返し会議インスタンスのシリーズ全体ではなく、1つの会議を表します。クライアントが提供する会議オブジェクト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 GMTで毎週月曜日に発生するようにスケジュールされた会議予約です。のみ次の3週間は、会議が代替開催地に10.00 GMTに発生するように変更されています。念頭に置いて、図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 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.
会議システムは、既存の会議予約に着信CCP要求に一致するが、関連iCalのオブジェクトは、既存の一連の範囲を意味することを識別する。会議システムは、シリーズ内の変更された会議インスタンスを表すために、元の会議予約をクローニングすることによって、子を作成します。クローン化された子オブジェクトは、このようにスケジュール内の任意の潜在的な競合を防止する、元の親オブジェクトとは無関係ではない（例えば、全シリーズ「」開始「時間」に変化します）。会議インスタンスの変更された系列を表すクローン化された会議の予約は、CCPの応答を使用してクライアントに返され、自身の関連する会議オブジェクトIDを有しています。この会議のオブジェクトIDは、新たに定義されたサブシリーズ上の任意の将来の変更を行うために、クライアントによって使用されます。このプロセスは、会議インスタンスの変更された（クローン）シリーズを表す新たに戻さ会議オブジェクトIDとして任意の回数繰り返すことができ、それ自体は、新しく作成された会議オブジェクト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を使用して会議に参加することを要求します。適用可能なポリシーをチェックした後、フォーカスがその要求を受け付けるいずれか（例えば、パークされたコールのために参加する管理者の承認を待っている間）リクエストのステータスに関連する進行表示を送信する、またはコールシグナリングインターフェースを使用してその要求を拒否する。
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].
会議システムは、会議通知サービスを実装するための責任があります。会議通知サービスは、参加者を含め、許可の当事者に会議インスタンスの状態に関する最新情報を提供します。 SIPを使用して通知するためのモデルは、[RFC4575]で定義された会議をサポートするために仕様と[RFC3265]で定義されています。
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.
この枠組みの中で、フロア制御をサポートするクライアントは、フロア要求を発行することを可能にするために、フロア制御サーバに接続するための情報を取得する必要があります。この接続情報は、フォーカスとシグナリング・インタフェース上の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オファー/アンサー交換を使用する場合、一意の会議ユーザ識別子は、[RFC4583]で定義されるように、「ユーザID」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オファー/アンサー交換を使用する場合、一意の会議識別子が「floorid」に含まれるSDP属性、例えば、[RFC4583]、A = flooridで定義されている：1 M-ストリーム：10。各「floorid」属性は、一意のフロアを表す1つまたは複数の識別子を含む「M-ストリーム」タグを有しています。 SDP「ラベル」属性を使用して（SDPから「= M」を使用して定義されるような）[RFC4574]で定義されるように識別子は、個々のSDPメディアセッションを表します。
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.
シナリオは、必要な操作及び一般的なロジックフローのハイレベルの原始的ビューを提供します。シナリオに示された詳細は、例示の目的のみのためであり、必ずしも別の文書で定義されている状態、を含む会議制御プロトコルメッセージも詳細なデータの実際の構造を反映していません。要求によって影響を受けないすべてのエンティティは、図（例えば、焦点）に示されているのではなく、重点は、この集中型会議フレームワークによって導入された新しいエンティティであることに留意されたいです。
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は、一つのクライアント「アリス」は、特定の会議システムに利用可能な会議の青写真を決定し、所望の設計図に基づいて会議を作成する例を提供します。
+--------------------------------+
| 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.
青写真のための会議制御プロトコル要求を受信すると、会議システムは、最初の「アリス」を認証することになる（及び必要に応じて、会議のユーザ識別子を割り当て）、次いで「アリス」は、任意の青写真を受信するために、システムポリシーに基づいて適切な権限を持っていることを確認しますそのシステムでサポートされています。 「アリス」の使用を許可されている任意の青写真は、会議のユーザー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.
青写真を含む会議制御プロトコルの応答を受信すると、「アリス」は、会議を作成するために使用する青写真を判定する。 「アリス」は青写真（すなわち、クローン）に基づいて、会議オブジェクトを作成し、そのようなメンバーシップリストと「開始」時間として該当フィールドを修正します。 「アリス」は、更新された設計図に基づいて会議予約を作成するために、会議システムに要求を送信します。
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.
会議を予約する会議制御プロトコルの応答を受信すると、「アリス」は、今では予約を使用してアクティブな会議を作成したり、既存の予約に基づいて、追加の予約を作成することができます。この例では、「アリスは」ミートミー会議ブリッジを予約しました。したがって、「アリス」は、所望の参加者に、必要な会議IDを含む、会議の情報を提供します。 「アリス」を含む最初の参加者が、会議に追加することを要求すると、アクティブな会議やフォーカスが作成されます。フォーカスは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]は、この機能を達成するために使用することができる方法REFERとSIP示します。
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は、一つのクライアント「アリス」は、別のクライアント「ボブ」の状態に影響を与えるの例を提供します。この例では、確立された会議を前提としています。この例では、「アリスは」会議に「ボブ」を追加したいです。
+--------------------------------+
| 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によって識別される特定の会議で党（「ボブ」）を「追加」する会議制御プロトコル要求を受信すると、会議システムは、「アリス」は、それに関連付けられたポリシーに基づいて、適切な権限を持っていることを保証します操作を実行するために特定の会議オブジェクト。会議システムはまた、「ボブ」はすでにこの会議システムの利用者であるか、彼が新しいユーザーであるかどうかを判断する必要があります。
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.
「ボブ」は、この会議システムのための新しいユーザーであれば、会議のユーザ識別子は、ボブのために作成されます。 「アリス」で「ボブ」のために提供アドレッシング情報に基づいて、会議に「ボブ」を追加するコールシグナリングは、フォーカスによって扇動されます。
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.
コールシグナリングは「ボブ」は、正常な状態への更新ごとに、特定の会議に追加されている、との方針に応じて、（「ボブ」を含む）他の参加者が「ボブ」の追加を通知することができることを示していたら、会議通知サービスを介して会議。
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コンテンツに再INVITEを送信するなどして、独自のメディアストリームを変更することができます。このような操作は、「第一党のシグナル伝達」と呼ばれ、彼らは会議に他の参加者の状態に影響を与えることはありません。
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は、1つのクライアント「アリス」は、別のクライアント「ボブ」のメディア状態に影響を与えるの例を提供します。この例では、確立された会議を前提としています。この例では、クライアントは、その役割会議の「司会者」である「アリス」は、彼のデバイスがミュートされていない（と彼は明らかに耳を傾けていないとして、中規模マルチパーティ会議の「ボブ」をミュートしたいです彼のオフィス環境での呼び出し）とバックグラウンドノイズは、会議に破壊的です。
+--------------------------------+
| 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によって識別される特定の会議で党（「ボブ」）を「ミュート」にする会議制御プロトコル要求を受信すると、会議サーバは、「アリス」は、それに関連付けられたポリシーに基づいて、適切な権限を持っていることを保証します操作を実行するために特定の会議オブジェクト。 「ボブの」ステータスが「がrecvonly」としてマークされ、会議オブジェクトは、「ボブの」メディアは会議メディアで「混合」ではないことがあることを反映するように更新されます。
Depending upon the policies, other participants (including "Bob") may be notified of this change via the conference notification service.
ポリシーに応じて、（「ボブ」を含む）他の参加者は、会議通知サービスを介して、この変更を通知することができます。
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 |
+-------+-------+ +-------+-------+ +---------------+
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は、「ボブ」と「キャロル」とアクティブな会議に関与する1つのクライアント「アリス」の例を提供します。 「アリス」は、まだメインの会議に関連するビデオを見ながら、「ボブ」との側の議論を持っているサイドバーを作成したいと考えています。あるいは、メイン会議からの音声は、減少した体積に維持することができます。 「アリスは、」アクティブな会議のオブジェクトに基づいて会議予約を作成するための会議システムに要求を送信することにより、サイドバーを開始します。 「アリス」と「ボブは」内部サイドバーの会議が行われている間に、他の参加者は、メイン会議への参加を認識することができように、メイン会議の名簿に残るでしょう。
+--------------------------------+
| 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.
会議を予約する会議制御プロトコルの応答を受信すると、「アリス」は、今では予約を使用してアクティブな会議を作成したり、既存の予約に基づいて、追加の予約を作成することができます。この例では、「アリスは」これ彼女はメンバーシップを操作する、唯一の「ボブ」サイドバーに関与することを望んでいます。 「アリス」だけのオリジナルの会議からビデオを望んでいると音声は、サイドバーの参加者に制限されることを望んでいます。また、「アリス」は減少した容積でメイン会議からの音声を受信するために、メディアの値を操作できます。 「アリス」は、予約の情報を更新し、アクティブな会議を作成する会議制御プロトコル要求を送信します。
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によって識別されるように、サイドバーのためのアクティブな会議を作成する会議制御プロトコル要求を受信すると、会議システムは、「アリス」は、特定の関連付けられたポリシーに基づいて適切な権限を有することを保証します操作を実行するための会議オブジェクト。会議システムはまた、「ボブ」のようなメンバーはすでにこの会議システムの利用者であることを確実にすること、予約で更新された情報を検証する必要があります。
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.
ポリシーに応じて、要求（すなわち、「アリス」）とサイドバーの参加者（すなわち、「ボブ」）のイニシエータは、会議通知サービスを介してサイドバーに彼のほかの通知をすることができます。
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 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.
図13は、「ボブ」、「キャロル」、「デービッド」、および「エセル」とアクティブな会議に関与する1つのクライアント「アリス」の例を提供します。 「アリス」は重要な顧客が「アリス」、「ボブ」、および「エセルを」話をする必要があり、「ボブ」からのささやきを経由して、重要なテキストメッセージを取得します。 「アリス」はアクティブな会議に残る「キャロル」と「デビッド」、を除いて、現在の会議の参加者を含め、顧客「フレッド」との側の議論を持っているサイドバーを作成します。 「アリスは、」アクティブな会議のオブジェクトに基づいて会議予約を作成するための会議システムに要求を送信することにより、サイドバーを開始します。 「アリス」、「ボブ」、および「エセルは」ホールド状態での主な会議の名簿に残るでしょう。これらの参加者の保留状態が他の参加者に表示されているかどうかは、個人や地域の政策に依存します。
+--------------------------------+
| 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,>
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.
会議を予約する会議制御プロトコルの応答を受信すると、「アリス」は、今では予約を使用してアクティブな会議を作成したり、既存の予約に基づいて、追加の予約を作成することができます。この例では、「アリス」は、サイドバーに関与していることが新たに参加「フレッド」と一緒に、唯一の「ボブ」と「エセル」を望んでいます。このように、彼女はメンバーシップを操作します。 「アリスは」メディアは、このようなサイドバーの参加者がメイン会議から任意のメディアを受けていないことを設定します。 「アリス」は、予約の情報を更新し、アクティブな会議を作成する会議制御プロトコル要求を送信します。
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 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.
予約を更新するために、会議オブジェクトIDによって識別されるように、サイドバーのためのアクティブな会議を作成する会議制御プロトコル要求を受信すると、会議システムは、「アリス」は、特定の関連付けられたポリシーに基づいて適切な権限を有することを保証します操作を実行するための会議オブジェクト。会議システムはまた、「フレッド」のようなメンバーはすでにこの会議システムのか、彼が新しいユーザーであるかどうか、ユーザーであるかどうかを確認して、予約で更新された情報を検証する必要があります。 「フレッド」は、この会議システムのための新しいユーザーであることから、会議のユーザ識別子が「フレッド」のために作成されます。 「アリス」で「フレッド」のために提供アドレッシング情報に基づいて、会議に「フレッド」を追加するコールシグナリングは、フォーカスによって扇動されます。
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.
ポリシーに応じて、要求のイニシエータ（すなわち、「アリス」）とサイドバー（すなわち、「ボブ」と「エセル」）の参加者は、会議通知サービスを介してサイドバーに彼のほかの通知をすることができます。
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は、会議のこのタイプの関与する構成の一例を提供します。前サイドバーの例のように、サイドバーと共にメイン会議があります。 「アリス」と「ボブ」、「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" | ||
|+------------+ +-------+----+|
+--------------------------------+
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」は質問をしたいとき、彼はフロア制御サーバにフロア要求メッセージを送信します。要求を受信すると、フロア制御サーバは、フロアチェアとしての積極的なサイドバー会議の「キャロル」を、司会者に通知します。このシグナリングフローが図に示されていないことに留意されたいです。他のアナリストは、まだ床を要求していないので、「キャロル」を「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の例と同様、単に2人の参加者とのサイドバーとして取り扱うことができるのではなく、サイドバー内のオーディオを使用するよりも、「アリス」は、サイドバーに追加のテキストベースのメディアストリームを追加することができます。ささやきと呼ばれる他の文脈では、本書で特定のユーザ（単数または複数）を標的とする一回メディアを含む状況をいいます。ささやきの例では、唯一の会議議長や会議に参加する新しい参加者に注入された発表となります。
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は、一人のユーザの例として、「ボブ」と「キャロル」の固定長会議の議長の「アリス」を提供します。構成は会議に残された唯一の10分がある場合のみ、椅子が警告を提供しているようなものです。その時、「アリス」は会議システムとのみ「アリス」の発表を受けてによって作成されたサイドバーに移動されます。
+--------------------------------+
| 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.
会議システムは、議長はなく、9.4.1項にサイドバーのために行われたように予約を作成して、「アリス」会議に残された唯一の10分が存在すると判断した場合、会議システムが直接ベース、アクティブサイドバー会議を作成します「アリス」に関連したアクティブな会議に。前述したように、サイドバー会議は、アクティブな会議（すなわち、親）の独立していません。会議システムはまた、サイドバーの会議の任意のその後の操作に使用する会議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.
すぐにアクティブなサイドバー会議の作成時に、アナウンスメディアは、「アリス」に提供されます。ポリシーに応じて、「アリスは、」会議通知サービスを介してサイドバーに彼女のほかの通知をすることができます。 「アリス」は、メイン会議からメディアを受信し続けています。
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.
発表が完了すると、「アリス」は、サイドバーから削除され、サイドバーの会議が削除されます。ポリシーに応じて、「アリスは、」会議通知サービスを経由してサイドバーからの彼女の除去を通知することができます。
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.
各参加者は、システムからの発表および/または記録サービスの異なるタイプを必要とすることができます。 「ボブ」は、サイドバーを作成するために、テレフォニーユーザインターフェイスを使用してもよいが、例えば「アリス」、会議議長は、ロールコールを聞きすることができます。いくつかの発表は、このような「この会議は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.
デュアルトーン多重周波数（DTMF）を収集するとともに、会議の記録とアナウンスの例は、このフレームワークのコンテキスト内で、図16に示されています。
+--------------------------------+
| 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 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.
「ボブ」会議に参加するための「アリス」から会議制御プロトコル要求を受信すると、会議システムは、「ボブの」アクティブな会議を表す会議オブジェクトへの要求で受信した識別子をマッピングします。会議システムは、パスワードは、この特定の会議のために必要であると判断し、このように、パスワードを入力し、「アリス」を尋ねる発表は「アリス」に提供されます。 「アリス」はパスワードを入力したら、それは「ボブの」アクティブな会議に関連付けられたポリシーに照らして検証されます。会議システムは、要求されますと、レコード「アリス」の名前のサーバーに接続します。会議システムはまた、「アリス」はすでにこの会議システムの利用者であるか、彼女が新しいユーザーであるかどうかを判断する必要があります。
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.
「アリス」は、この会議システムのための新しいユーザーであれば、会議のユーザ識別子が「アリス」のために作成されます。 「アリス」が提供するアドレス情報に基づいて、コールシグナリングは、フォーカスによって扇動された会議に「アリス」を追加します。
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.
コールシグナリングは「アリス」は、正常な状態への更新ごとに、特定の会議に追加されている、との方針に応じて、他の参加者（例えば、「ボブ」）はへの「アリス」の追加が通知されていることを示していたら、会議通知サービスを介した会議、および発表は「アリス」は、会議に参加したことを示す、すべての参加者に提供されます。
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.
DTMFモニタリングの例は、フレームワークエレメントのコンテキスト内で、図16に示されています。
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に示され、コールセンターエージェント「ボブ」は、「キャロル」、顧客との会議に関与しています。 「ボブ」は、新しいエージェントと「アリス」は、彼が通常よりも長いため、「キャロル」とのコールにされていることを認識しているので、彼女は、必要に応じて通話やコーチ「ボブ」を遵守することを決定します。
+--------------------------------+
| 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.
要求で受信したアクティブな会議に基づいて「予約」を「アリス」の新しいサイドバー会議から会議制御プロトコル要求を受信すると、会議システムは、サイドバーのための会議予約をクローニングするために、受信したアクティブな会議を使用します。会議システムはまた、留保または会議のメンバーのいずれかからの任意の後続のプロトコル要求に使用される会議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.
会議を予約する会議制御プロトコルの応答を受信すると、「アリス」は、今では予約を使用してアクティブな会議を作成したり、既存の予約に基づいて、追加の予約を作成することができます。この例では、「アリス」は、サイドバーに関与していることが唯一の「ボブ」を望んでいます。このように、彼女はメンバーシップを操作します。 「アリス」も、音声はオリジナルの会議から自分自身と「ボブ」によって受信されることを希望するが、「ボブの」送信オーディオがメインの会議に行くべき一方で、自分自身からの任意の発信オーディオは、サイドバーの参加者に限定されることを望んで、「アリス」と顧客の両方が「キャロル」を「ボブ」から同じ音声を聞くことになります。 「アリス」は、予約の情報を更新し、アクティブな会議を作成する会議制御プロトコル要求を送信します。
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によって識別されるように、サイドバーのためのアクティブな会議を作成する会議制御プロトコル要求を受信すると、会議システムは、「アリス」は、特定の関連付けられたポリシーに基づいて適切な権限を有することを保証します操作を実行するための会議オブジェクト。 「アリス」が「ボブ」のために提供アドレッシング情報に基づいて、適切なメディア特性を有するサイドバーに「ボブ」を追加するコールシグナリングは、フォーカスを介して扇動されます。
"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.
「ボブは、」会議通知サービスを介してサイドバーに自分以外が通知されます。このように、彼は「アリス」、スーパーバイザーは、この呼び出しを通じて彼をコーチングのために利用可能であることを認識しています。
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 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会議フレームワーク[RFC4353]会議業界で、今日知られている集中型の会議ソリューションの広い範囲の概要を説明します。文書には、概要を体系化し、これらのシステムの多くの共通のコアを表示するために、専門用語や論理エンティティを導入しています。 SIP会議フレームワークにおける論理エンティティと記載されているシナリオは、シグナリングがこれらの会議システムでの手段としてSIP [RFC3261]を使用することができる方法を説明するために使用されます。 SIP会議フレームワークは、一般的な会議システムで使用されるように、新たな会議制御プロトコルを定義していません。これは、基本的なSIP会議実現のためにのみ、基本的なSIP [RFC3261]、ユーザエージェントのSIPカンファレンス[RFC4579]、および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.
2つのフレームワークで定義された論理エンティティが一対一にマッピングされることを意図するものではありません。 2つのフレームワークは、内部会議システムの分解および対応する動作の解釈が異なります。それにもかかわらず、基本的なSIP [RFC3261]、ユーザエージェントのSIPカンファレンス[RFC4579]、およびSIP会議パッケージ[RFC4575]は、両方のフレームワークの文書と完全に互換性があります。互換性のための基礎は、集中型会議のための会議情報データモデル（XCON）[XCON-COMMON]に[RFC4575]で定義された基本的なデータ要素を含むことによって提供されます。のみ[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 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).
この会議の枠組みのセキュリティを取り巻くいくつかの問題があります。問題の1つのセットは、実際のプロトコルと関連した認証メカニズムを確保することを伴います。問題のこの最初のセットは、第8章とポリシー制御で説明したプロトコルに固有の仕様で対処しなければなりません。操作や機密情報の検索に使用されるプロトコルは、機密性と完全性メカニズムをサポートする必要があります。同様の要件は、フロア制御プロトコルに対して適用されます。 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攻撃の可能性を最小限にするためには、会議システムは、会議に参加するすべてのクライアントのユーザー認証と承認を必要とすることをお勧めします。特定のシグナリングおよびメディアプロトコルが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.
多くの政策認可決定は利用者の身元またはユーザーが持っているかもしれ役割に基づいています。会議システムは、典型的には、自分のアイデンティティを検証するために、ユーザーの認証が必要です。ユーザーがシステムにそのIDを認証可能性があるいくつかの方法があります。コールシグナリングプロトコルのいずれかを使用して会議に参加するユーザーのために、特定のプロトコルのためのユーザ認証メカニズムは、多くの場合、十分です。 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文字）までを含むパスワードを持っています。数値のみであり、多くの場合（多くの場合、10ビットまたは3桁の数字など、いくつかのような）ビットのかなり小さい数を含む共有秘密 - PINは、特別なパスワードのケースです。会議システムは、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.
この会議システムは、ユーザのアイデンティティのアイデアを持っているが、これはプライバシーの配慮のために、他のユーザーにこの身元を明らかにすることができますという意味ではありません。ユーザーが他のユーザーに自分の身元を明らかにするためのさまざまなオプションを選択することができます。ユーザーは「隠された」は、他のユーザーが会議に参加している見ることができないように、「匿名」のユーザーは、他のユーザーが存在していることがわかりますが、ユーザーのIDが表示されない、または、彼らは「公共可能できるようにすることができます"ここで他のユーザーが自分の身元を確認することができます。複数の「匿名」ユーザーがいる場合は、他の当事者は、独立した「匿名」の当事者としてそれらを見ることができますし、多くの「匿名」当事者が会議にどのように伝えることができるようになります。他の参加者への視界が自分の役割に依存していることに、注意してください。例えば、（ 『匿名』と 『非表示』を含む）ユーザーのアイデンティティは会議システムのローカルポリシーが適用モデレータまたは管理者に表示されることがあります。 「隠された」状態は、多くの場合、会議の自動化や機械の参加者によって使用されている（例えば、記録を呼び出す）とも多くのコールセンターの状況で使用されています。
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に記載されているように、クライアントを認証するために使用することができます。そのような認証のために使用される正確なメカニズムが使用される呼制御プロトコルに依存して変化し得ます。 SIPなどSDPオファー/アンサーモデルを使用する呼制御プロトコルを使用しているクライアントは、[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ワーキンググループの参加者の間で建築議論の結果です。著者は、「セキュリティの考慮事項」セクションの入力を提供するための「会議オブジェクト・ツリー」の提案および一般的なフィードバック、カレン・ジェニングスのためのヘニングSchulzrinneとに感謝したい、とキースランツ、デイヴ・モーガン、オスカー・ノボ、ロニでも、Umeshチャンドラ、Avshalomうフーリー、ショーン・オルソン、
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.
彼らのレビューと建設的な入力のためのロハンマーイ、ブライアン・ローゼン、ピエール・タネ、ボブBraudes、グレゴリーSperounes、そしてゴンサロ・カマリロ。また、作者は彼のsecdirレビューコメントのための彼の世代の技術のレビューコメントのためのスコット・ブリムとクルトZeilengaに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、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.、フレデリック、R.、およびV.ヤコブソン、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。
[RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[RFC2445]ドーソン、F.とStenerson、D.、 "インターネットカレンダーおよびスケジューリング中核オブジェクト仕様（iCalendar形式）"、RFC 2445、1998年11月。
[RFC4245] Levin, O. and R. Even, "High-Level Requirements for Tightly Coupled SIP Conferencing", RFC 4245, November 2005.
でも、[RFC4245]レヴィン、O.とR.、 "密結合SIP会議のための高レベルの要件"、RFC 4245、2005年11月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]ローゼンバーグ、J.、Schulzrinneと、H.、およびO.レヴィン、 "Aセッション開始プロトコル（SIP）の会議の状態のためのイベントパッケージ"、RFC 4575、2006年8月。
[RFC4376] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, "Requirements for Floor Control Protocols", RFC 4376, February 2006.
[RFC4376] Koskelainen、P.、オット、J.、Schulzrinneと、H.、およびX.呉、 "フロア制御プロトコルのための要件"、RFC 4376、2006年2月。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4597]であっても、R.とN.イスマイル、 "会議のシナリオ"、RFC 4597、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]ジョンストン、A.、およびO.レヴィン、 "セッション開始プロトコル（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]キャマリロ、G.、オット、J.、およびK.糖剤、 "バイナリフロア制御プロトコル（BFCP）"、RFC 4582、2006年11月。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4574]レヴィン、O.およびG.キャマリロ、 "セッション記述プロトコル（SDP）label属性"、RFC 4574、2006年8月。
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
、RFC 4583、2006年11月[RFC4583]キャマリロ、G.、 "バイナリフロア制御プロトコル（BFCP）ストリームのセッション記述プロトコル（SDP）フォーマット"。
[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]ノボ、O.、カマリロ、G.、モルガン、D.、およびR.でも、 "会議情報データモデルの集中会議（XCON）について"、進歩、2008年3月での作業。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
[RFC5018] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, September 2007.
[RFC5018]キャマリロ、G.、 "バイナリフロア制御プロトコルでの接続の確立（BFCP）"、RFC 5018、2007年9月。
Authors' Addresses
著者のアドレス
Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX
メアリー・バーンズノーテル2201レイクサイドブルバードリチャードソン、テキサス州
EMail: mary.barnes@nortel.com
メールアドレス：mary.barnes@nortel.com
Chris Boulton Avaya Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA
クリスボールトンアバイアビル3 Wern Fawrレーンセントメロンズカーディフ、サウスウェールズCF3 5EA
EMail: cboulton@avaya.com
メールアドレス：cboulton@avaya.com
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
oriTレヴィンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: oritl@microsoft.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。