[要約] RFC 5239は、集中型会議のためのフレームワークを提供するものであり、要約すると以下のようになります。1. RFC 5239は、集中型会議のためのフレームワークを提供する。 2. 目的は、効率的な会議の実施と管理を支援すること。 3. セキュリティやプロトコルの標準化に関するガイドラインも提供する。
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では、このドキュメントに示されている集中会議モデルのコンテキストで、集中会議のフレームワークと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.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、BCP 14、[RFC2119]で説明されているように解釈され、準拠の実装の要件レベルを示します。
This Centralized Conferencing Framework document generalizes, when appropriate, the SIP Conferencing Framework [RFC4353] terminology and introduces new concepts, as listed below. Further details and clarification of the new terms and concepts are provided in the subsequent sections of this document.
この集中化された会議フレームワークドキュメントは、必要に応じて、SIP会議フレームワーク[RFC4353]という用語を一般化し、以下にリストするように新しい概念を紹介します。新しい用語と概念の詳細と明確化は、このドキュメントの後続のセクションで提供されています。
Active conference: The term "active conference" refers to a conference object that has been created and activated via the allocation of its identifiers (e.g., conference object identifier and conference identifier) and the associated focus. An active conference is created based on either a system default conference blueprint or a specific conference reservation.
Call Signaling protocol: The call signaling protocol is used between a participant and a focus. In this context, the term "call" means a channel or session used for media streams.
コールシグナル伝達プロトコル：コールシグナリングプロトコルは、参加者とフォーカスの間で使用されます。これに関連して、「呼び出し」という用語は、メディアストリームに使用されるチャネルまたはセッションを意味します。
Conference blueprint: A conference blueprint is a static conference object within a conferencing system, which describes a typical conference setting supported by the system. A conference blueprint is the basis for creation of dynamic conference objects. A system may maintain multiple blueprints. Each blueprint is comprised of the initial values and ranges for the elements in the object, conformant to the data schemas for the conference information.
会議の青写真：会議の青写真は、会議システム内の静的な会議オブジェクトであり、システムがサポートする典型的な会議設定を説明しています。会議の青写真は、動的な会議オブジェクトを作成するための基礎です。システムは複数の青写真を維持する場合があります。各青写真は、会議情報のデータスキーマに準拠した、オブジェクト内の要素の初期値と範囲で構成されています。
Conference control protocol (CCP): A conference control protocol provides the interface for data manipulation and state retrieval for the centralized conferencing data, represented by the conference object.
会議制御プロトコル（CCP）：会議制御プロトコルは、会議オブジェクトで表される集中会議データのデータ操作と状態検索のインターフェイスを提供します。
Conference factory: A conference factory is a logical entity that generates unique URI(s) to identify and represent a conference focus.
会議工場：会議工場は、会議の焦点を特定して表現するための一意のURIを生成する論理的エンティティです。
Conference identifier (ID): A conference identifier is a call signaling protocol-specific URI that identifies a conference focus and its associated conference instance.
会議識別子（ID）：会議識別子は、会議の焦点とそれに関連する会議インスタンスを識別するコールシグナル伝達プロトコル固有のURIです。
Conference information: The conference information includes definitions for basic conference features, such as conference identifiers, membership, signaling, capabilities, and media types applicable to a wide range of conferencing applications. The conference information also includes the media and application-specific data for enhanced conferencing features or capabilities, such as media mixers. The conference information is the data type (i.e., the XML schema) for a conference object.
会議情報：会議情報には、会議識別子、メンバーシップ、シグナル、機能、幅広い会議アプリケーションに適用されるメディアタイプなど、基本的な会議機能の定義が含まれています。会議情報には、メディアミキサーなどの会議機能や機能を強化するためのメディアとアプリケーション固有のデータも含まれています。会議情報は、会議オブジェクトのデータ型（つまり、XMLスキーマ）です。
Conference instance: A conference instance refers to an internal implementation of a specific conference, represented as a set of logical conference objects and associated identifiers.
Conference object: A conference object represents a conference at a certain stage (e.g., description upon conference creation, reservation, activation, etc.), which a conferencing system maintains in order to describe the system capabilities and to provide access to the services available for each object independently. The conference object schema is based on the conference information.
会議オブジェクト：会議オブジェクトは、特定の段階での会議（例：会議の作成、予約、アクティベーションなどに関する説明など）を表します。これは、システム機能を説明し、利用可能なサービスにアクセスできるようにするために、会議システムが維持しています。各オブジェクトは独立して。会議のオブジェクトスキーマは、会議情報に基づいています。
Conference object identifier (ID): A conference object identifier is a URI that uniquely identifies a conference object and is used by a conference control protocol to access and modify the conference information.
Conference Object Identifier（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).
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会議のフレームワーク[RFC4353]は、ユーザーエージェント[RFC4579]ドキュメントのSIPコールコントロール会議とともに、これらのタイプのシナリオに対応しています。
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.
....................................................................
. 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.
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].
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.
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.
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を生成するための1つの方法です。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.
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のマッピングがあります。焦点は、Active Conferenceオブジェクトによってサポートされている各信号プロトコルの一意の会議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.
ユーザーが会議の作成または参加を希望する場合、ユーザーが特定の会議の会議オブジェクト識別子を持っていない場合、より一般的なシグナル伝達メカニズムが適用されます。ユーザーは、会議システムにアクセスするために事前に構成された会議オブジェクト識別子を持ち、他のシグナル伝達プロトコルを使用し、会議システムはそれらを特定の会議オブジェクト識別子にマッピングできます。会議が確立されると、ユーザーが会議データを操作するか、高度な会議機能を活用するには、会議オブジェクト識別子が必要です。同じ概念は、他のシグナル伝達プロトコルを使用して会議に参加するユーザーにも当てはまります。彼らは最初に特定の会議システムでサポートされている他のシグナリングプロトコルのいずれかを使用して会議に参加することができますが、会議オブジェクト識別子を使用して、会議データを操作するか、高度な会議機能を活用する必要があります。前述のように、ユーザーが会議オブジェクト識別子を学習するメカニズムは変化し、データモデルと会議パッケージを使用して、または電子メールやWebインターフェイスなどのバンドメカニズムを完全に使用して、会議制御プロトコルを介して行うことができます。
The conference object identifier logically maps to other protocol-specific identifiers associated with the conference instance, such as the BFCP 'confid'. The mapping of the conference object identifier can be viewed to contain sensitive information in many conferencing systems. The conferencing system must ensure that the data is protected, that only authorized users can manipulate that information via the conferencing control protocol, and that only the appropriate users receive the information through the notification protocol. In general, this information would not be expected to be distributed to the average conference participant.
会議オブジェクト識別子は、BFCP「confid」などの会議インスタンスに関連付けられた他のプロトコル固有の識別子に論理的にマップします。会議オブジェクト識別子のマッピングは、多くの会議システムに機密情報が含まれていると表示できます。会議システムは、データが保護されていること、認定されたユーザーのみが会議制御プロトコルを介してその情報を操作できること、および通知プロトコルを通じて適切なユーザーのみが情報を受け取ることができることを確認する必要があります。一般に、この情報は平均的な会議参加者に分配されることは期待されません。
Each user within a conferencing system MUST be allocated a unique conference user identifier. The conference user identifier is defined in [XCON-COMMON]. The conference user identifier is used in association with the conference object identifier to uniquely identify a user within the scope of conferencing system. There is also a requirement for identifying conferencing system users who may not be participating in a conference instance. Examples of these users would be a non-participating 'Floor Control Chair' or 'Media Policy Controller'. The conference user identifier is REQUIRED, in conference control protocol requests, to uniquely determine who is issuing commands, so that appropriate policies can be applied to the requested command.
会議システム内の各ユーザーには、一意の会議ユーザー識別子を割り当てる必要があります。会議ユーザー識別子は[XCON-Common]で定義されています。Conferenceユーザー識別子は、会議オブジェクト識別子に関連して使用され、会議システムの範囲内でユーザーを一意に識別します。会議のインスタンスに参加していない可能性のある会議システムユーザーを特定するための要件もあります。これらのユーザーの例は、参加していない「フロアコントロールチェア」または「メディアポリシーコントローラー」です。会議ユーザー識別子は、会議制御プロトコル要求で、要求されたコマンドに適切なポリシーを適用できるように、誰がコマンドを発行しているかを一意に決定する必要があります。
A typical mode for distributing the user identifier is out of band during conferencing client configuration; thus, the mechanism is outside the scope of the centralized conferencing framework and protocols. However, a conferencing system MUST also be capable of allocating and distributing a user identifier during the first signaling interaction with the conferencing system, such as an initial request for blueprints or adding a new user to an existing conference using the conference control protocol. When a user joins a conference using a signaling-specific protocol, such as SIP for a dial-in conference, a conference user identifier MUST be assigned if one is not already associated with that user. While this conference user identifier isn't required for the participant to join the conference, it is REQUIRED to be allocated and assigned by the conferencing system such that it is available for use for any subsequent conference control protocol operations and/or notifications associated with that conference. For example, the conference user identifier would be sent in any notifications that may be sent to existing participants, such as the moderator, when this user joins.
ユーザー識別子を配布するための典型的なモードは、クライアントの構成を会議中にバンド外です。したがって、メカニズムは、集中会議のフレームワークとプロトコルの範囲外です。ただし、会議システムは、会議制御プロトコルを使用して既存の会議に新しいユーザーを追加するなど、会議システムとの最初の信号相互作用中にユーザー識別子を割り当てて配布することもできなければなりません。ユーザーが、ダイヤルイン会議のSIPなどのシグナル固有のプロトコルを使用して会議に参加する場合、そのユーザーにまだ関連付けられていない場合は、会議ユーザー識別子を割り当てる必要があります。この会議のユーザー識別子は、参加者が会議に参加するためには必要ありませんが、会議システムによって割り当てられ、割り当てられる必要があります。そのため、それに関連する会議管理プロトコル操作および/またはそれに関連する通知に使用できるようになります。会議。たとえば、会議ユーザー識別子は、このユーザーが参加したときにモデレーターなどの既存の参加者に送信される可能性のある通知で送信されます。
The conference user identifier is logically associated with the other user identifiers assigned to the conferencing client for other protocol interfaces, such as an authenticated SIP user. The mapping of the conference user identifier to signaling specific user identifiers requires that methods for protecting and securing a user's identity are considered. Section 11.1 addresses "User Authentication and Authorization" and Section 11.2 addresses the "Security and Privacy of User Identity". In addition, the conferencing system MUST ensure the appropriate access control around any internal data structure that maintains this persistent data. This information would typically only be available to a conferencing system administrator.
Conferenceユーザー識別子は、認証されたSIPユーザーなどの他のプロトコルインターフェイスについて、会議クライアントに割り当てられた他のユーザー識別子に論理的に関連付けられています。Conferenceユーザー識別子が特定のユーザー識別子を信号するためのマッピングには、ユーザーのIDを保護および保護する方法が考慮される必要があります。セクション11.1は、「ユーザー認証と承認」に対処し、セクション11.2には「ユーザーIDのセキュリティとプライバシー」に対処します。さらに、会議システムは、この永続的なデータを維持する内部データ構造の周りの適切なアクセス制御を確保する必要があります。この情報は通常、会議システム管理者のみが利用できます。
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
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.
このセクションで定義されている概念は、集中化された会議メカニズム、URISとプロトコルを通じて反映されるため、論理的な表現のみです。もちろん、実際のシステム実現は、提示されたモデルとは異なる場合があります。意図は、会議システムとクライアントのアクションを協議することに基づいて、データにインターフェイスを提供する際の論理要素の役割を説明し、結果のプロトコルへの意味を説明することです。
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は、子1と子供2の2つの子オブジェクトを作成します。親Bのデータ要素は変更できます（つまり、「親が強制できる」データ要素はありません）。要素に応じて、変更は反映されます。子1と子2の変化は、親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).
会議をスケジュールする機能は、会議システムソリューションの重要な部分を形成します。通常、個々の会議の予約には、指定された「開始」時間と「終了」時間があり、指定された単一の「固定」時間（例：「start」= 09.00 gmt、 'end' = 'start' 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.
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.
関連するICALオブジェクトを含む新しい会議予約を作成するためのCCPリクエストが検証され、結果の会議予約が作成されます。会議の予約は、セクション6.2.1で導入され、[XCON-Common]で定義されているように、会議オブジェクト識別子（例：XCON：HD87928374）によって会議システム内で独自に表されます。このユニークな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要求に含まれるICLの定義が一連の繰り返し会議インスタンスを表すことを例外としてほぼ同じです（例：会議「開始」時間、終了時間、毎週発生する）。会議システムは、この要求を最初の例と同じように扱います。CCP要求は、関連するICALオブジェクトとともに検証され、会議の予約が作成されます。この例で作成された会議の予約とその会議オブジェクトIDは、単一の会議ではなく、一連の繰り返される会議インスタンス全体を表しています。クライアントが提供されたConference Object 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オブジェクトは既存のシリーズの範囲のみを指していることを特定します。会議システムは、シリーズ内の変更された会議インスタンスを表すために、元の会議予約をクローニングすることにより、子供を作成します。クローン化された子オブジェクトは、元の親オブジェクトとは独立していないため、スケジューリングにおける潜在的な競合を防ぎます（たとえば、シリーズ全体の「開始時間」の変更）。カンファレンスインスタンスの変更されたシリーズを表すCloned Conferenceの予約には、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を使用した通知のモデルは、[RFC3265]で[RFC3265]で定義され、[RFC4575]で定義されている会議をサポートする詳細があります。
The conference user identifier and associated role are used by the conferencing system to filter the notifications such that they contain only information that is allowed to be sent to that user.
会議のユーザー識別子と関連する役割は、会議システムによって使用され、通知をフィルタリングして、そのユーザーに送信できる情報のみが含まれます。
The conference control protocol provides for data manipulation and state retrieval for the centralized conferencing data, represented by the conference object. The details of the conference control protocol are provided in separate documents.
会議制御プロトコルは、会議オブジェクトで表される集中会議データのデータ操作と状態検索を提供します。会議制御プロトコルの詳細は、個別のドキュメントで提供されています。
A floor control protocol allows an authorized client to manage access to a specific floor and to grant, deny or revoke access of other conference users to that floor. Floor control is not a mandatory mechanism for a conferencing system implementation, but it provides advanced media input control features for conference users. A mechanism for floor control within a conferencing system is defined in the "Binary Floor Control Protocol (BFCP)" specification [RFC4582].
フロアコントロールプロトコルにより、認定クライアントは特定のフロアへのアクセスを管理し、そのフロアへの他の会議ユーザーのアクセスを許可、拒否、または取り消すことができます。フロアコントロールは、会議システムの実装のための必須メカニズムではありませんが、会議ユーザーに高度なメディア入力制御機能を提供します。会議システム内の床制御のメカニズムは、「バイナリフロアコントロールプロトコル（BFCP）」仕様[RFC4582]で定義されています。
Within this framework, a client supporting floor control needs to obtain information for connecting to a floor control server to enable it to issue floor requests. This connection information can be retrieved using information provided by mechanisms such as negotiation using the SDP [RFC4566] offer/answer [RFC3264] exchange on the signaling interface with the focus. Section 11.3 provides a discussion of client authentication of a floor control server.
このフレームワーク内で、フロアコントロールをサポートするクライアントは、フロアコントロールサーバーに接続するための情報を取得して、フロアリクエストを発行できるようにする必要があります。この接続情報は、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]で定義されているように、「UserID」SDP属性に一意の会議ユーザー識別子が含まれます。
A media session within a conferencing system can have any number of floors (0 or more) that are represented by the conference identifier. When using SDP offer/answer exchange to negotiate a floor control connection with the focus using the call signaling interface, the unique conference identifier is contained in the 'floorid' SDP attribute, as defined in [RFC4583], e.g., a=floorid:1 m-stream:10 . Each 'floorid' attribute, representing a unique floor, has an 'm-stream' tag containing one or more identifiers. The identifiers represent individual SDP media sessions (as defined using 'm=' from SDP) using the SDP 'Label' attribute, as defined in [RFC4574].
会議システム内のメディアセッションには、会議の識別子で表される任意の数のフロア（0以上）を持つことができます。SDPオファー/回答交換を使用して、コールシグナリングインターフェイスを使用してフォーカスとフロアコントロール接続を交渉する場合、[RFC4583]で定義されている「FloorID」SDP属性に一意の会議識別子が含まれています。M-Stream：10。一意のフロアを表す各「FloorID」属性には、1つ以上の識別子を含む「M-Stream」タグがあります。識別子は、[RFC4574]で定義されているように、SDP 'ラベル'属性を使用して、個々のSDPメディアセッション（SDPからの「M = 'を使用して定義されています）を表します。
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.
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は、特定の会議システムで利用可能な会議の青写真を決定する1つのクライアントの「アリス」の例を示し、目的の青写真に基づいて会議を作成します。
+--------------------------------+
| Conferencing System |
"Alice" | +------------+|
+--------+ | | ||
| |CCP Request <blueprints> | +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| |<--------------------------|Control |~~~>|Blueprint(s)||
+--------+CCP Response<blueprintA, | |Server | | ||
... | +-----------+ +------------+|
blueprintZ, | |
confUserID> | |
"Alice" |
+--------+ | |
| |CCP Request <reserve, | +------------+|
| | blueprintAConfObjID,| +-----------+ | ||
| Client |-------------------------->|Conference | |Conference ||
| | confUserID> | |Control |~~~>|BlueprintA ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <reservationConfObjID, | | | \|/ |
confID> | | | /|\ |
| | | V |
| | | +------------+|
| | |~~~>|Conference ||
| | | |Reservation ||
| +-----------+ +------------+|
"Alice" | | |
+--------+ | | |
| |CCP Request <add, | V |
| |reservationConfObjID, | +-----------+ +------------+|
| Client |-------------------------->|Conference | |Active ||
| | confID,confUserID> | |Control |~~~>|Conference ||
| |<--------------------------|Server | | ||
| |CCP Response | | | +------------+|
+--------+ <activeConfObjID, | | | |
confID> | +-----------+ |
+--------------------------------+
Figure 8: Client Creation of Conference Using Blueprints
図8：青写真を使用した会議のクライアント作成
Upon receipt of the conference control protocol request for blueprints, the conferencing system would first authenticate "Alice" (and allocate a conference user identifier, if necessary) and then ensure that "Alice" has the appropriate authority based on system policies to receive any blueprints supported by that system. Any blueprints that "Alice" is authorized to use are returned in a response, along with the conference user ID.
青写真の会議制御プロトコル要求を受け取ると、会議システムは最初に「アリス」を認証し（必要に応じて会議ユーザー識別子を割り当てます）、「アリス」が青写真を受け取るためのシステムポリシーに基づいて適切な権限を持っていることを確認します。そのシステムによってサポートされています。「Alice」が使用する権限があるという青写真は、会議のユーザー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.
会議を予約するための会議管理プロトコルの回答を受け取ったとき、「アリス」は、その予約を使用してアクティブな会議を作成したり、既存の予約に基づいて追加の予約を作成したりすることができます。この例では、「アリス」はMeetme Conference Bridgeを予約しています。したがって、「アリス」は、必要な会議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.
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.
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.
+--------------------------------+
| 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.
「ボブ」がこの会議システムの新しいユーザーである場合、会議ユーザー識別子がBOB用に作成されます。「アリス」によって「ボブ」に提供されたアドレス指定情報に基づいて、会議に「ボブ」を追加するためのコールシグナリングは、焦点を通じて扇動されます。
Once the call signaling indicates that "Bob" has been successfully added to the specific conference, per updates to the state, and depending upon the policies, other participants (including "Bob") may be notified of the addition of "Bob" to the conference via the conference notification service.
コールシグナリングが「ボブ」が特定の会議に正常に追加され、州の更新ごとに正常に追加され、ポリシーに応じて、他の参加者（「ボブ」を含む）に「ボブ」の追加が通知される場合があります。会議通知サービスによる会議。
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コンテンツを使用してRe 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に示すように、親会議オブジェクト（つまり、独立したオブジェクトではありません）に暗黙的にリンクされ、親会議オブジェクト識別子に関連付けられています。SideBar Conference Object（例：Parent Conferenceインスタンスの外部からのメンバーは参加できません。ParentConferenceが終了した場合、サイドバーカンファレンスは存在できません。
+--------------+
| 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.
会議を予約するための会議管理プロトコルの回答を受け取ったとき、「アリス」は、その予約を使用してアクティブな会議を作成したり、既存の予約に基づいて追加の予約を作成したりすることができます。この例では、「アリス」は「ボブ」がサイドバーに関与することを望んでいるため、メンバーシップを操作します。「アリス」はまた、元の会議のビデオのみを望んでおり、オーディオをサイドバーの参加者に制限することを望んでいます。あるいは、「アリス」はメディア値を操作して、メイン会議から音声を減らして受信することができます。「Alice」は、予約の情報を更新し、アクティブな会議を作成するために、会議管理プロトコルリクエストを送信します。
Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conferencing system must also validate the updated information in the reservation, ensuring that a member like "Bob" is already a user of this conferencing system.
会議のオブジェクトIDで特定されたように、会議管理プロトコルのリクエストを受け取り、サイドバー向けのアクティブな会議を作成するためのコントロールプロトコルリクエストを受けたとき、会議システムは、「アリス」がその特定に関連するポリシーに基づいて適切な権限を持つことを保証します。操作を実行するための会議オブジェクト。会議システムは、予約の更新された情報も検証し、「ボブ」のようなメンバーがすでにこの会議システムのユーザーであることを確認する必要があります。
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.
会議を予約するための会議管理プロトコルの回答を受け取ったとき、「アリス」は、その予約を使用してアクティブな会議を作成したり、既存の予約に基づいて追加の予約を作成したりすることができます。この例では、「アリス」は「ボブ」と「エセル」のみを望んでおり、新しい参加者「フレッド」がサイドバーに関与することを望んでいます。したがって、彼女はメンバーシップを操作します。「アリス」は、サイドバーの参加者がメイン会議からメディアを受け取らないようにメディアを設定します。「Alice」は、予約の情報を更新し、アクティブな会議を作成するために、会議管理プロトコルリクエストを送信します。
Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conferencing system must also validate the updated information in the reservation, ensuring whether members like "Fred" are already a user of this conferencing system or whether he 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で特定されたように、会議管理プロトコルのリクエストを受け取り、サイドバー向けのアクティブな会議を作成するためのコントロールプロトコルリクエストを受けたとき、会議システムは、「アリス」がその特定に関連するポリシーに基づいて適切な権限を持つことを保証します。操作を実行するための会議オブジェクト。会議システムは、予約の更新された情報も検証し、「Fred」のようなメンバーがすでにこの会議システムのユーザーであるか、または新しいユーザーであるかどうかを確認する必要があります。「フレッド」はこの会議システムの新しいユーザーであるため、会議ユーザー識別子が「フレッド」用に作成されます。「アリス」によって「フレッド」に提供されたアドレス指定情報に基づいて、会議に「フレッド」を追加するコールシグナル伝達が焦点を通して扇動されます。
Depending upon the policies, the initiator of the request (i.e., "Alice") and the participants in the sidebar (i.e., "Bob" and "Ethel") may be notified of his addition to the sidebar via the conference notification service.
ポリシーに応じて、リクエストのイニシエーター（つまり、「アリス」）とサイドバーの参加者（つまり、「ボブ」と「エセル」）には、会議通知サービスを介してサイドバーに追加されることを通知する場合があります。
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のマッピングを維持しています。アナリストは、メインカンファレンスの間に永久にミュートされています。アナリストは、話をしたいときにサイドバーに移されます。特定の時間に1人のアナリストのみが床に与えられます。メイン会議のすべての参加者は、サイドバー会議からオーディオを受け取り、メインカンファレンスでパネリストが提供するオーディオを受け取ります。
+--------------------------------+
| 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.
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人の参加者だけのサイドバーとして処理できますが、サイドバー内でオーディオを使用するのではなく、「アリス」はサイドバーに追加のテキストベースのメディアストリームを追加できます。このドキュメントでは、ささやきと呼ばれるもう1つのコンテキストは、特定のユーザーを対象とした1回のメディアが含まれる状況を指します。ささやきの例は、会議の椅子または会議に参加する新しい参加者にのみ注入された発表です。
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.
+--------------------------------+
| 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.
「Alice」がこの会議システムの新しいユーザーである場合、「Alice」用の会議ユーザー識別子が作成されます。「アリス」が提供するアドレス指定情報に基づいて、会議に「アリス」を追加するためのコールシグナリングが焦点を通して扇動されます。
Once the call signaling indicates that "Alice" has been successfully added to the specific conference, per updates to the state, and depending upon the policies, other participants (e.g., "Bob") are notified of the addition of "Alice" to the conference via the conference notification service, and an announcement is provided to all the participants indicating that "Alice" has joined the conference.
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.
スーパーバイザーの機能を1つのステップにとると、エージェントがスーパーバイザーと顧客を聞くことができるシナリオをさらに紹介します。顧客は引き続きエージェントのみを聞くことができます。このシナリオには、エージェントとスーパーバイザーが関与するサイドバーの作成が含まれます。エージェントとスーパーバイザーの両方が、メイン会議からオーディオを受け取ります。エージェントが話すと、メイン会議で顧客が聞いています。監督者が話すとき、それはサイドバー会議のエージェントによってのみ聞かれます。
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.
+--------------------------------+
| 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.
会議を予約するための会議管理プロトコルの回答を受け取ったとき、「アリス」は、その予約を使用してアクティブな会議を作成したり、既存の予約に基づいて追加の予約を作成したりすることができます。この例では、「アリス」は「ボブ」がサイドバーに関与することを望んでいます。したがって、彼女はメンバーシップを操作します。「アリス」はまた、オリジナルの会議から自分でオーディオと「ボブ」を受け取ることを望んでいますが、自分からの発信オーディオがサイドバーの参加者に制限されることを望んでいます。、そのため、「アリス」と顧客「キャロル」の両方が「ボブ」から同じオーディオを聞くように。「Alice」は、予約の情報を更新し、アクティブな会議を作成するために、会議管理プロトコルリクエストを送信します。
Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. Based upon the addressing information provided for "Bob" by "Alice", the call signaling to add "Bob" to the sidebar with the appropriate media characteristics is instigated through the focus.
会議のオブジェクトIDで特定されたように、会議管理プロトコルのリクエストを受け取り、サイドバー向けのアクティブな会議を作成するためのコントロールプロトコルリクエストを受けたとき、会議システムは、「アリス」がその特定に関連するポリシーに基づいて適切な権限を持つことを保証します。操作を実行するための会議オブジェクト。「アリス」によって「ボブ」に提供されたアドレス指定情報に基づいて、適切なメディア特性を使用してサイドバーに「ボブ」を追加するためのコールシグナリングが焦点を通して扇動されます。
"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 [RFC3261]、ユーザーエージェントのSIP会議[RFC4579]、および基本的なSIP会議の実現にはSIP会議パッケージ[RFC4575]のみを使用します。
This centralized conferencing framework document defines a particular centralized conferencing system and the logical entities implementing it. It also defines a particular data model and refers to the set of protocols (beyond call signaling means) to be used among the logical entities for implementing advanced conferencing features. The purpose of the XCON Working Group and this framework is to achieve interoperability between the logical entities from different vendors for controlling different aspects of advanced conferencing applications.
この集中化された会議フレームワークドキュメントは、特定の集中会議システムとそれを実装する論理エンティティを定義します。また、特定のデータモデルを定義し、高度な会議機能を実装するために論理エンティティで使用される一連のプロトコル（コールシグナル伝達手段を超えて）を指します。XCONワーキンググループの目的とこのフレームワークは、高度な会議アプリケーションのさまざまな側面を制御するために、さまざまなベンダーの論理エンティティ間の相互運用性を達成することです。
The logical entities defined in the two frameworks are not intended to be mapped one-to-one. The two frameworks differ in the interpretation of the internal conferencing system decomposition and the corresponding operations. Nevertheless, the basic SIP [RFC3261], the SIP Conferencing for User Agents [RFC4579], and the SIP Conference Package [RFC4575] are fully compatible with both framework documents. The basis for compatibility is provided by including the basic data elements defined in [RFC4575] in the Conference Information Data Model for Centralized Conferencing (XCON) [XCON-COMMON]. User agents that only support [RFC4579] and do not support the Conferencing Control Protocol are still provided basic SIP conferencing, but cannot take advantage of any of the advanced features.
2つのフレームワークで定義されている論理エンティティは、1対1でマッピングすることを意図していません。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).
この会議のフレームワークのセキュリティを取り巻くいくつかの問題があります。一連の問題には、実際のプロトコルと関連する承認メカニズムの確保が含まれます。この最初の一連の問題は、セクション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で説明されている会議でのユーザーのIDのプライバシーとセキュリティが含まれます。
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.
多くのポリシー認可の決定は、ユーザーの身元またはユーザーが持つ可能性のある役割に基づいています。会議システムは通常、ユーザーが自分の身元を検証するために認証を必要とします。ユーザーがシステムにアイデンティティを認証する方法はいくつかあります。通話信号プロトコルのいずれかを使用して会議に参加するユーザーには、特定のプロトコルのユーザー認証メカニズムで十分です。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）を知ることで承認される場合があります。時々、ピンが不要にならず、会議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コールシグナリングを相関させます。したがって、会議に参加するには、単一のピンまたはパスワードが必要なだけです。
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.
会議システムが認可されたユーザーのIDを提示する場合、システムによってIDが証明または検証された方法に関する情報を提供することを選択できます。ユーザーは、完全に認知されていないユーザーとしてシステムに入ることもあります。この事実は、利害関係者にも通知する必要があります。
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.
ゲストユーザーがシステムと対話するとき、それは多くの場合、特定の会議のコンテキストにあります。この場合、ユーザーは会議に固有のピンまたはパスワードを提供し、ユーザーがその会議で特定の役割を引き受けることを許可することができます。ゲストユーザーは、その役割を持つユーザーに許可されているアクションを実行できます。
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桁）を含む共有秘密です。会議システムがPSTNのオーディオに使用される場合、ピンを使用して認証する必要があることがよくあります。通常、ユーザーが正しいピンを数回続けて提供できない場合、PSTNコールは切断されます。コールを行い、ピンに入るためにポイントに到達するという速度により、4桁のピンをもピンスペースを徹底的に検索することがかなり難しくなります。高速インターフェイスを使用して会議システムに接続する場合、1秒あたり数千回の試行を行うことができることが多く、ピンスペースをすばやく検索できます。このため、高速クエリまたは多くの同時クエリを提供するインターフェイスのいずれかの承認にピンを使用することは適切ではありません。
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のアイデアがありますが、これは、プライバシーの考慮事項により、このアイデンティティを他のユーザーに明らかにすることができるという意味ではありません。ユーザーは、他のユーザーに自分の身元を明らかにするためのさまざまなオプションを選択できます。ユーザーは、他のユーザーが会議の参加者であることが「匿名」であることを確認できないように「隠されている」ことができます。「他のユーザーが自分のアイデンティティを見ることができる場所。複数の「匿名」ユーザーがいる場合、他の当事者は、それらを独立した「匿名」当事者と見なすことができ、会議に「匿名の」当事者がいくつあるかを伝えることができます。他の参加者への可視性は自分の役割に依存していることに注意してください。たとえば、ユーザーの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, 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.
このドキュメントは、IETF XCONワーキンググループの参加者の間での建築的議論の結果です。著者は、「会議のオブジェクトツリー」の提案と一般的なフィードバック、「セキュリティ上の考慮事項」セクションへの入力を提供してくれたカレンジェニングス、キースランツ、デイブモーガン、オスカーノーゴ、ロニイーブ、ウメシュチャンドラ、アヴシャロム、ヘニングシュルツリンヌ、カレンジェニングスの一般的なフィードバックに感謝したいと思います。Houri、Sean Olson、Rohan Mahy、Brian Rosen、Pierre Tane、Bob Braudes、Gregory Sperounes、Gonzalo Camarilloのレビューと建設的な入力。さらに、著者は、彼のGen-Artレビューのコメントについてスコット・ブリムに感謝し、彼のSecdirレビューのコメントについてKurt Zeilengaに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、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.、Frederick、R。、およびV. Jacobson、「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] Dawson、F。and 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] Levin、O。、およびR.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のためのフレームワーク」、RFC 4353、2006年2月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、「会議状態のセッション開始プロトコル（SIP）イベントパッケージ」、RFC 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.、Ott、J.、Schulzrinne、H。、およびX. Wu、「床制御プロトコルの要件」、RFC 4376、2006年2月。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4597] Even、R。およびN. Ismail、「会議シナリオ」、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] Camarillo、G.、Ott、J。、およびK. Drage、「バイナリフロアコントロールプロトコル（BFCP）」、RFC 4582、2006年11月。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, August 2006.
[RFC4574] Levin、O。およびG. Camarillo、「セッション説明プロトコル（SDP）ラベル属性」、RFC 4574、2006年8月。
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
[RFC4583] Camarillo、G。、「セッション説明プロトコル（SDP）バイナリフロアコントロールプロトコル（BFCP）ストリームの形式」、RFC 4583、2006年11月。
[XCON-COMMON] Novo, O., Camarillo, G., Morgan, D., and R. Even, "Conference Information Data Model for Centralized Conferencing (XCON)", Work in Progress, March 2008.
[Xcon-Common] Novo、O.、Camarillo、G.、Morgan、D。、およびR.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「The Message Session Relay Protocol（MSRP）」、RFC 4975、2007年9月。
[RFC5018] Camarillo, G., "Connection Establishment in the Binary Floor Control Protocol (BFCP)", RFC 5018, September 2007.
[RFC5018] Camarillo、G。、「バイナリフロアコントロールプロトコル（BFCP）における接続確立」、RFC 5018、2007年9月。
Authors' Addresses
著者のアドレス
Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX
メアリーバーンズノルテル2201レイクサイドブルバードリチャードソン、テキサス
EMail: mary.barnes@nortel.com
Chris Boulton Avaya Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA
クリス・ボールトン・アヴァヤビルディング3ウェルンファーレーンセントメロンカーディフ、サウスウェールズCF3 5EA
EMail: cboulton@avaya.com
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
Orit Levin Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: oritl@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。