RFC5239 日本語訳
5239 A Framework for Centralized Conferencing. M. Barnes, C. Boulton,O. Levin. June 2008. (Format: TXT=146927 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Barnes
Request for Comments: 5239 Nortel
Category: Standards Track C. Boulton
Avaya
O. Levin
Microsoft Corporation
June 2008
コメントを求めるワーキンググループM.バーンズ要求をネットワークでつないでください: 5239年のノーテルカテゴリ: 標準化過程C.ボールトンAvaya O.レヴィンマイクロソフト社2008年6月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このドキュメントはCentralized Conferencingのためにフレームワークを定義します。 フレームワークは、集結されたユニキャスト会議でメディアを交換するのに、SIP、H.323、Jabber、Q.931またはISDN User Partなどの様々な呼び出しシグナリングプロトコル(ISUP)を使用することで関係者を許容します。 Centralized Conferencing Frameworkは論理的な実体と命名規則を定義します。 また、フレームワークは1セットの会議プロトコルについて概説します、高度な会議アプリケーションを組立てるために。(プロトコルは呼び出しシグナリングプロトコルを補足しています)。 フレームワークは会議システムのビルダーの利益のためにすべての定義されたコンポーネントを一緒にくくります。
Barnes, et al. Standards Track [Page 1] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[1ページ]RFC5239
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Centralized Conferencing Data . . . . . . . . . . . . . . . . 10
5.1. Conference Information . . . . . . . . . . . . . . . . . . 11
5.2. Conference policies . . . . . . . . . . . . . . . . . . . 12
6. Centralized Conferencing Constructs and Identifiers . . . . . 12
6.1. Conference Identifier . . . . . . . . . . . . . . . . . . 13
6.2. Conference Object . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Conference Object Identifier . . . . . . . . . . . . . 15
6.3. Conference User Identifier . . . . . . . . . . . . . . . . 16
7. Conferencing System Realization . . . . . . . . . . . . . . . 17
7.1. Cloning Tree . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Ad Hoc Example . . . . . . . . . . . . . . . . . . . . . . 20
7.3. Advanced Example . . . . . . . . . . . . . . . . . . . . . 21
7.4. Scheduling a Conference . . . . . . . . . . . . . . . . . 23
8. Conferencing Mechanisms . . . . . . . . . . . . . . . . . . . 26
8.1. Call Signaling . . . . . . . . . . . . . . . . . . . . . . 26
8.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 26
8.3. Conference Control Protocol . . . . . . . . . . . . . . . 26
8.4. Floor Control . . . . . . . . . . . . . . . . . . . . . . 26
9. Conferencing Scenario Realizations . . . . . . . . . . . . . . 28
9.1. Conference Creation . . . . . . . . . . . . . . . . . . . 28
9.2. Participant Manipulations . . . . . . . . . . . . . . . . 30
9.3. Media Manipulations . . . . . . . . . . . . . . . . . . . 32
9.4. Sidebar Manipulations . . . . . . . . . . . . . . . . . . 33
9.4.1. Internal Sidebar . . . . . . . . . . . . . . . . . . . 35
9.4.2. External Sidebar . . . . . . . . . . . . . . . . . . . 37
9.5. Floor Control Using Sidebars . . . . . . . . . . . . . . . 40
9.6. Whispering or Private Messages . . . . . . . . . . . . . . 42
9.7. Conference Announcements and Recordings . . . . . . . . . 44
9.8. Monitoring for DTMF . . . . . . . . . . . . . . . . . . . 46
9.9. Observing and Coaching . . . . . . . . . . . . . . . . . . 46
10. Relationships between SIP and Centralized Conferencing
Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11. Security Considerations . . . . . . . . . . . . . . . . . . . 50
11.1. User Authentication and Authorization . . . . . . . . . . 51
11.2. Security and Privacy of Identity . . . . . . . . . . . . . 53
11.3. Floor Control Server Authentication . . . . . . . . . . . 53
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . . 54
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 4。 概要. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5。 会議データ. . . . . . . . . . . . . . . . 10 5.1を集結しました。 コンファレンス情報. . . . . . . . . . . . . . . . . . 11 5.2。 コンファレンス方針. . . . . . . . . . . . . . . . . . . 12 6。 会議構造物と識別子. . . . . 12 6.1を集結しました。 コンファレンス識別子. . . . . . . . . . . . . . . . . . 13 6.2。 コンファレンスオブジェクト. . . . . . . . . . . . . . . . . . . . 13 6.2.1。 コンファレンスオブジェクト識別子. . . . . . . . . . . . . 15 6.3。 コンファレンスユーザ識別子. . . . . . . . . . . . . . . . 16 7。 会議システム実現. . . . . . . . . . . . . . . 17 7.1。 木. . . . . . . . . . . . . . . . . . . . . . . 17 7.2のクローンを作ります。 臨時の例. . . . . . . . . . . . . . . . . . . . . . 20 7.3。 高度な例. . . . . . . . . . . . . . . . . . . . . 21 7.4。 コンファレンス. . . . . . . . . . . . . . . . . 23 8の計画をします。 会議メカニズム. . . . . . . . . . . . . . . . . . . 26 8.1。 シグナリング. . . . . . . . . . . . . . . . . . . . . . 26 8.2に電話をしてください。 通知. . . . . . . . . . . . . . . . . . . . . . 26 8.3。 コンファレンス制御プロトコル. . . . . . . . . . . . . . . 26 8.4。 床のコントロール. . . . . . . . . . . . . . . . . . . . . . 26 9。 会議シナリオ実現. . . . . . . . . . . . . . 28 9.1。 コンファレンス作成. . . . . . . . . . . . . . . . . . . 28 9.2。 関与している操作. . . . . . . . . . . . . . . . 30 9.3。 メディア操作. . . . . . . . . . . . . . . . . . . 32 9.4。 サイドバー操作. . . . . . . . . . . . . . . . . . 33 9.4.1。 内部のサイドバー. . . . . . . . . . . . . . . . . . . 35 9.4.2。 外部のサイドバー. . . . . . . . . . . . . . . . . . . 37 9.5。 サイドバー. . . . . . . . . . . . . . . 40 9.6を使用する床のコントロール。 私語かプライベート・メッセージ. . . . . . . . . . . . . . 42 9.7。 コンファレンス発表と録音. . . . . . . . . 44 9.8。 DTMF. . . . . . . . . . . . . . . . . . . 46 9.9のために、モニターします。 観測とコーチ. . . . . . . . . . . . . . . . . . 46 10。 一口と集結された会議フレームワーク. . . . . . . . . . . . . . . . . . . . . . . . . . 49 11との関係。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 50 11.1。 ユーザー認証と承認. . . . . . . . . . 51 11.2。 アイデンティティ. . . . . . . . . . . . . 53 11.3のセキュリティとプライバシー。 床のコントロールサーバー証明. . . . . . . . . . . 53 12。 承認. . . . . . . . . . . . . . . . . . . . . . . 53 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 54 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 54 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 54
Barnes, et al. Standards Track [Page 2] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[2ページ]RFC5239
1. Introduction
1. 序論
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.
このドキュメントはCentralized Conferencingのためにフレームワークを定義します。 フレームワークは、集結されたユニキャスト会議でメディアを交換するのに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.
Centralized Conferencing Frameworkは論理的な実体と命名規則を定義します。 また、フレームワークは1セットの会議プロトコルについて概説します、高度な会議アプリケーションを組立てるために。(プロトコルは呼び出しシグナリングプロトコルを補足しています)。
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.
Centralized Conferencing FrameworkはSIP Conferencing Framework[RFC4353]に提示される機能論的モデルと互換性があります。 このドキュメントのセクション10はCentralized Conferencing FrameworkとSIP Conferencing Frameworkとの関係について論じます、本書では提示されたCentralized Conferencingモデルの文脈で。
2. Conventions
2. コンベンション
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, [RFC2119] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTがこと解釈されるのは中でBCP14について説明しました、[RFC2119]であり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
3. Terminology
3. 用語
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.
このCentralized Conferencing Frameworkドキュメントは、適切であるときに、SIP Conferencing Framework[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.
活発な会議: 「活発な会議」という用語は識別子(例えば、会議オブジェクト識別子と会議識別子)の配分で作成されて、動いた会議オブジェクトと関連焦点について言及します。 活発な会議はシステム・デフォルト会議青写真か特定の会議の予約のどちらかに基づいて創設されます。
Barnes, et al. Standards Track [Page 3] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[3ページ]RFC5239
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.
呼び出しSignalingは議定書を作ります: 呼び出しシグナリングプロトコルは関係者と焦点の間で使用されます。 このような関係においては、「呼ぶ」という用語はメディアストリームに使用されるチャンネルかセッションを意味します。
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.
コンファレンス青写真: 会議青写真は会議システムの中の静的な会議オブジェクトです。システムはシステムによってサポートされた典型的な会議設定について説明します。 会議青写真はダイナミックな会議オブジェクトの創案の基礎です。 システムは複数の青写真を維持するかもしれません。 各青写真は、オブジェクト(会議情報のためのデータschemasへのconformant)で初期の値から成って、要素のために及びます。
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.
コンファレンスインスタンス: 会議インスタンスは1セットの論理的な会議オブジェクトと関連識別子として代表された特定の会議の内部の実装について言及します。
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.
コンファレンスオブジェクト: 会議オブジェクトはある段階(例えば、会議作成、予約、起動などの記述)で会議を代表します。(会議システムは、システム能力について説明して、独自に各オブジェクトに利用可能なサービスへのアクセスを提供するためにそれを維持します)。 会議オブジェクト図式は会議情報に基づいています。
Barnes, et al. Standards Track [Page 4] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[4ページ]RFC5239
Conference object identifier (ID): A conference object identifier is
a URI that uniquely identifies a conference object and is used by
a conference control protocol to access and modify the conference
information.
コンファレンスオブジェクト識別子(ID): 会議情報に会議オブジェクト識別子は唯一会議オブジェクトを特定するURIであり、会議制御プロトコルによって使用されて、アクセスして、変更します。
Conference policies: Conference policies collectively refers to a
set of rights, permissions, and limitations pertaining to
operations being performed on a certain conference object.
コンファレンス方針: コンファレンス方針はある会議オブジェクトに実行される操作に関係する1セットの権利、許容、および限界をまとめて示します。
Conference reservation: A conference reservation is a conference
object, which is created from either a system default or client
selected blueprint.
コンファレンスの予約: 会議の予約は会議オブジェクトです。(そのオブジェクトはシステム・デフォルトかクライアントの選択された青写真のどちらかから作成されます)。
Conference state: The conference state reflects the state of a
conference instance and is represented using a specific, well-
defined schema.
コンファレンス州: 会議状態は、会議インスタンスの状態を反映して、特定の、そして、よく定義された図式を使用することで表されます。
Conferencing system: Conferencing system refers to a conferencing
solution based on the data model discussed in this framework
document and built using the protocol specifications referenced in
this framework document.
会議システム: 会議システムはこのフレームワークドキュメントで議論して、このフレームワークドキュメントで参照をつけられるプロトコル仕様を使用することで造られたデータモデルに基づく会議ソリューションについて言及します。
Conference user identifier (ID): A unique identifier for a user
within the scope of a conferencing system. A user may have
multiple conference user identifiers within a conferencing system
(e.g., to represent different roles).
コンファレンスユーザ識別子(ID): 会議システムの範囲の中のユーザにとって、ユニークな識別子。 ユーザは会議システム(例えば異なる役割を表す)の中に複数の会議ユーザ識別子を持っているかもしれません。
Floor: Floor refers to a set of data or resources associated with a
conference instance, for which a conference participant, or group
of participants, is granted temporary access.
床: 床は1セットのデータか会議インスタンスに関連しているリソースを示します。(一時的なアクセサリーはリソースに関して会議の参加者、または関係者のグループに与えられます)。
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.
焦点: 焦点は各参加との呼び出しシグナリングインタフェースがクライアントと活動的な状態を表す会議オブジェクトであることを支持する論理的な実体です。 そういうものとして、焦点は、それぞれのサポートしているシグナリングプロトコルのために終点として機能して、すべてのプライマリ会議会員資格操作(例えば、接合してください、そして、いなくなってください、そして、会議インスタンスをアップデートする)と会議の参加者と焦点の間のメディア交渉/メインテナンスに責任があります。
Barnes, et al. Standards Track [Page 5] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[5ページ]RFC5239
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 Controlなどのようにプロトコル(RTCP)([RFC3550]では、定義される)かMessage Session Relayプロトコル([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.
役割: 役割は関係者が実行できる会議操作のセットのための文脈を提供します。 1セットの基本的な会議操作をユーザに提供して、デフォルトの役割(例えば、標準の会議の参加者)はいつも存在するでしょう。 システムの特定の認証と承認に基づいて、ユーザは代替の役割を引き受けるかもしれません、会議議長などのように、より広い会議操作へのアクセスを許して。
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.
ささやき声: ささやき声はサイドバーを使用することで達成された特定の会議インスタンスの中で1回のメディア入力に(a) 特定の関係者にかかわります。 ささやき声に関する例は学会主催者だけ、または、会議に参加する新しい関係者に注入された発表でしょう。
4. Overview
4. 概要
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シグナリングの機能性を使用することでそれをサポートすることができるでしょう。 Userエージェント[RFC4579]ドキュメントのためのSIP Call Control Conferencingに伴うSIP Conferencing Framework[RFC4353]はこれらのタイプのシナリオを扱います。
Barnes, et al. Standards Track [Page 6] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[6ページ]RFC5239
In addition to the basic features, however, a conferencing system supporting the centralized conferencing model proposed in this framework document can offer richer functionality, by including dedicated conferencing applications with explicitly defined capabilities, reserved recurring conferences, along with providing the standard protocols for managing and controlling the different attributes of these conferences.
しかしながら、基本的特徴に加えて、このフレームワークドキュメントで提案された集結された会議モデルをサポートする会議システムは、より豊かな機能性を提供できます、明らかに定義された能力があるひたむきな会議アプリケーションを含んでいることによって、予約された再発会議、これらの会議の異なった属性を管理して、制御するのに標準プロトコルを提供すると共に。
The core requirements for centralized conferencing are outlined in [RFC4245]. These requirements are applicable for conferencing systems using various call signaling protocols, including SIP. Additional conferencing requirements are provided in [RFC4376] and [RFC4597].
集結された会議のためのコア要件は[RFC4245]に概説されています。 SIPを含む様々な呼び出しシグナリングプロトコルを使用する会議システムに、これらの要件は適切です。 [RFC4376]と[RFC4597]に追加会議要件を提供します。
The centralized conferencing system proposed by this framework is built around a fundamental concept of a conference object. A conference object provides the data representation of a conference during each of the various stages of a conference (e.g., creation, reservation, active, completed, etc.). A conference object is accessed via the logical functional elements, with whom a conferencing client interfaces, using the various protocols identified in Figure 1. The functional elements defined for a conferencing system described by the framework are a conference control server, floor control server, any number of Foci, and a notification service. A conference control protocol (CCP) provides the interface between a conference and media control client and the conference control server. A floor control protocol (e.g., Binary Floor Control Protocol (BFCP)) provides the interface between a floor control client and the floor control server. A call signaling protocol (e.g., SIP, H.323, Jabber, Q.931, ISUP, etc.) provides the interface between a call signaling client and a focus. A notification protocol (e.g. SIP Notify [RFC3265]) provides the interface between the conferencing client and the notification service.
このフレームワークによって提案された集結された会議システムは会議オブジェクトに関する基本概念の周りに構築されます。 会議オブジェクトはそれぞれの会議(例えば、作成、アクティブで、完成した予約など)の様々なステージの間、会議のデータ代理を提供します。 論理的な機能要素で会議オブジェクトはアクセスされます、会議クライアントがだれを連結するかと共に、図1で特定された様々なプロトコルを使用して。 フレームワークによって説明された会議システムのために定義された機能要素は、会議制御サーバと、床の制御サーバと、いろいろなFociと、通知サービスです。 会議制御プロトコル(CCP)はコントロールクライアントと会議制御サーバを会議とメディアとのインタフェースに提供します。床の制御プロトコル(例えば、Binary Floor Controlプロトコル(BFCP))は床のコントロールクライアントと床の制御サーバとのインタフェースを提供します。呼び出しシグナリングプロトコル(例えば、SIP、H.323、Jabber、Q.931、ISUPなど)は呼び出しシグナリングクライアントと焦点とのインタフェースを提供します。 通知プロトコル(例えば、SIP Notify[RFC3265])は会議クライアントと通知サービスとのインタフェースを提供します。
A conferencing system can support a subset of the conferencing functions depicted in the conferencing system logical decomposition in Figure 1 and described in this document. However, there are some essential components that would typically be used by most other advanced functions, such as the notification service. For example, the notification service is used to correlate information, such as the list of participants with their media streams, between the various other components.
会議システムは図1における会議のシステムの論理的な分解で表現されて、本書では説明された会議機能の部分集合をサポートできます。 しかしながら、他のほとんどの拡張機能によって通常使用されるいくつかの必須成分があります、通知サービスなどのように。 例えば、通知サービスは情報を関連させるのに利用されます、彼らのメディアストリームをもっている関係者のリストなどのように、他の様々なコンポーネントの間で。
Barnes, et al. Standards Track [Page 7] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[7ページ]RFC5239
....................................................................
. 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 .
....................................................................
.................................................................... . 会議システム…+-----------------------------------------------------+ . . | 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+-------------------+ +--------------+ +-------+ +------------+ . . | コンファレンスコントロール| | 床のコントロール| |増殖巣| |通知| . . | サーバ| | サーバ| | | |サービス| . . +-------------------+ +--------------+ +-------+ +------------+ . . ^ ^ ^ | . ..............|.................|...........|..........|............ | | | | |コンファレンス|バイナリー|呼び出し|通知|コントロール|床|シグナリング|プロトコル|プロトコル|コントロール|プロトコル| | |プロトコル| | | | | | ..............|.................|...........|..........|............ . V V V V+----------------+ +------------+ +----------+ +------------+ . . | コンファレンス| | 床| | 呼び出し| |通知| . . | そして、メディア| | コントロール| | シグナリング| | クライアント| . . | コントロール| | クライアント| | クライアント| | | . . | クライアント| | | | | | | . . +----------------+ +------------+ +----------+ +------------+… 会議クライアント。
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
会議のメディアグラフは、集結されて、分散されていて両方のどんな組み合わせでありも、メディアタイプ単位で潜在的に異なることができます。 集結されたケース、セッションが確立されるメディアでは、メディアミキサーは関係者の焦点とそれぞれによって制御されました。 分散している(すなわち、分配された)場合では、メディアグラフはaです。
Barnes, et al. Standards Track [Page 8] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[8ページ]RFC5239
multicast or multi-unicast mesh among the participants. Consequently, the media processing (e.g., mixing) can be controlled either by the focus alone or by the participants. The concepts in this framework document clearly map to a centralized media model. The concepts can also apply to the decentralized media case; however, the details of such are left for future study.
関係者の中のマルチキャストかマルチユニキャストメッシュ。 その結果、焦点だけか関係者がメディア処理(例えば、混合)を制御できます。 このフレームワークにおける概念は明確に集結されたメディアモデルに地図を記録します。 また、分散メディアケースに概念は適用できます。 しかしながら、そのようなものの詳細は今後の研究に発たれます。
Section 5 of this document provides more details on the conference object. Section 6 defines the constructs and identifiers that MUST be implemented to manage the conference objects, instances, and users associated with a conferencing system. Section 7 of this document describes how a conferencing system is logically built using the defined high level data model and how the conference objects are maintained. Section 8 describes the fundamental conferencing mechanisms and provides a high level overview of the protocols. Section 9 then provides realizations of various conferencing scenarios, detailing the manipulation of the conference objects using the defined protocols. Section 10 of this document summarizes the relationship between this Centralized Conferencing Framework and the SIP Conferencing Framework.
このドキュメントのセクション5は会議オブジェクトに関するその他の詳細を提供します。 セクション6は会議システムに関連している会議オブジェクト、インスタンス、およびユーザを管理するために実装しなければならない構造物と識別子を定義します。 このドキュメントのセクション7は、会議システムが定義された高い平らなデータモデルを使用することで論理的にどのように構築されるか、そして、会議オブジェクトがどのように維持されるかを説明します。 セクション8は、基本的な会議メカニズムについて説明して、プロトコルの高い平らな概要を提供します。 そして、定義されたプロトコルを使用することで会議オブジェクトの操作を詳しく述べて、セクション9は様々な会議シナリオの実現を提供します。 このドキュメントのセクション10はこのCentralized Conferencing FrameworkとSIP Conferencing Frameworkとの関係をまとめます。
Barnes, et al. Standards Track [Page 9] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[9ページ]RFC5239
5. Centralized Conferencing Data
5. 集結された会議データ
The centralized conference data is logically represented by the conference object. A conference object is of type 'Conference information type', as illustrated in Figure 2. The conference information type is extensible.
集結された会議データは会議オブジェクトによって論理的に表されます。 タイプ'コンファレンス情報タイプ'には会議オブジェクトが図2で例証されるようにあります。 会議情報タイプは広げることができます。
+------------------------------------------------------+ | C o n f e r e n c e o b j e c t | | | | +--------------------------------------------------+ | | | Conference information type | | | | | | | | +----------------------------------------------+ | | | | | Conference description (times, duration) | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Membership (roles, capacity, names) | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Signaling (protocol, direction, status) | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Floor information | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Sidebars, Etc. | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Mixer algorithm, inputs, and outputs | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Floor controls | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | Etc. | | | | | +----------------------------------------------+ | | | +--------------------------------------------------+ | +------------------------------------------------------+
+------------------------------------------------------+ | C o n f e r e n c e o b j e c t| | | | +--------------------------------------------------+ | | | コンファレンス情報タイプ| | | | | | | | +----------------------------------------------+ | | | | | コンファレンス記述(回、持続時間)| | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | 会員資格(役割、容量、名前)| | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | シグナリング(プロトコル、方向、状態)| | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | 床の情報| | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | サイドバーなど | | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | ミキサーアルゴリズム、入力、および出力| | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | 床のコントロール| | | | | +----------------------------------------------+ | | | | +----------------------------------------------+ | | | | | など | | | | | +----------------------------------------------+ | | | +--------------------------------------------------+ | +------------------------------------------------------+
Figure 2: Conference Object Type Decomposition
図2: コンファレンスオブジェクト・タイプ分解
In a system based on this conferencing framework, the same conference object type is used for representation of a conference during different stages of a conference, such as expressing conferencing system capabilities, reserving conferencing resources, or reflecting the state of ongoing conferences. Section 7 describes the usage semantics of the conference objects. The exact XML schema of the
この会議フレームワークに基づくシステムでは、同じ会議のオブジェクト・タイプは会議の代理に会議の異なったステージの間、使用されます、会議システム能力を言い表すのなどように、会議リソースを予約するか、または進行中の会議の状態を反映して。 セクション7は会議オブジェクトの用法意味論について説明します。 XML図式を強要します。
Barnes, et al. Standards Track [Page 10] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[10ページ]RFC5239
conference object, including the organization of the conference information is detailed in a separate document [XCON-COMMON].
会議は反対して、会議情報の組織を含んでいるのは別々のドキュメント[XCON-COMMON]で詳細です。
Along with the basic data model, as defined in [XCON-COMMON], the realization of this framework requires a policy infrastructure. The policies required by this framework to manage and control access to the data include local, system level boundaries associated with specific data elements, such as the membership, and the ranges and limitations of other data elements. Additional policy considerations for a system realization based on this data model are discussed in Section 5.2.
基礎データモデルと共に、このフレームワークの実現は[XCON-COMMON]で定義されるように方針インフラストラクチャを必要とします。 管理するこのフレームワークとコントロールデータへのアクセスで必要である方針は特定のデータ要素に関連しているローカルのシステムレベル境界を含んでいます、他のデータ要素の会員資格や、範囲や限界などのように。 セクション5.2でこのデータモデルに基づくシステム実現のための追加方針問題について議論します。
5.1. Conference Information
5.1. コンファレンス情報
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.
どんな会議でも利用される会議情報には1人の巻き癖に関するデータがあります、特定の会議メディア自然の如何にかかわらず(例えば混合アルゴリズムは働いて、高度な床のコントロールは適用されましたなど)。 会議情報のこの巻き癖に関するデータは会議オブジェクト能力を表す定義を含んでいます、会員資格、役割、呼び出しシグナリング、そして、会議寿命の異なったステージに関連しているメディア状態が循環します。 この巻き癖の会議情報は会議タイプを使用することで表されるかもしれません、SIP会議イベントパッケージ[RFC4575]で定義されるように。 通常、会議情報へのリード・オンリー・アクセスの関係者はこの巻き癖の会議情報だけに興味を持っているでしょう。
In order to support more complex media manipulations and enhanced conferencing features, the conference information, as defined in the data model [XCON-COMMON], contains additional data beyond that defined in the SIP conference event package [RFC4575]. The information defined in the data model [XCON-COMMON] provides specific media mixing details, available floor controls, and other data necessary to support enhanced conferencing features. This information allows authorized clients to manipulate the mixer's behavior via the focus, with the resultant distribution of the media to all or individual participants. By doing so, a client can change its own state and/or the state of other participants in the conference.
より複雑なメディア操作と高められた会議機能をサポートするために、データモデル[XCON-COMMON]で定義される会議情報はSIP会議イベントパッケージ[RFC4575]で定義されたそれを超えて追加データを含んでいます。 データモデル[XCON-COMMON]で定義された情報は詳細、利用可能な床のコントロール、およびサポートするのに必要な他のデータが高めた特定のメディア混合に会議機能を提供します。 認可されたクライアントは焦点を通ってこの情報でミキサーの振舞いを操ることができます、すべてか個々の関係者へのメディアの結果の分配で。 そうすることによって、クライアントはそれ自身の状態、そして/または、会議の他の関係者の状態を変えることができます。
New centralized conferencing specifications can extend the basic conference-type, as defined in the data model [XCON-COMMON], and introduce additional data elements to be used within the conference information type.
新しい集結された会議仕様は、データモデル[XCON-COMMON]で定義されるように基本的な会議タイプを広げていて、会議情報タイプの中で使用されるために追加データ要素を紹介できます。
Barnes, et al. Standards Track [Page 11] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[11ページ]RFC5239
5.2. Conference policies
5.2. コンファレンス方針
Conference policies collectively refers to a set of rights, permissions and limitations pertaining to operations being performed on a certain conference object.
コンファレンス方針はある会議オブジェクトに実行される操作に関係する1セットの権利、許容、および限界をまとめて示します。
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.
さらに、会議通知インタフェースは、特定のデータ要素がそのような通知に登録するユーザに送られるのを許容します。 適切なアクセス制御を提供するのが重要であるので、特定のデータ要素を見るのに権限を与えられるユーザだけが通知でデータを受信します。
6. Centralized Conferencing Constructs and Identifiers
6. 集結された会議構造物と識別子
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.
このセクションは、会議システムに関連しているクライアントに演説して、管理するために集結された会議フレームワーク構造物と識別子REQUIREDに関連している識別子の詳細を明らかにします。 識別子の配分、特性、および機能的役割の概要を提供します。
Barnes, et al. Standards Track [Page 12] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[12ページ]RFC5239
6.1. Conference Identifier
6.1. コンファレンス識別子
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つのメソッドです、呼び出しシグナリングインタフェースを使用して。 [RFC4579]で会議工場のSIPシグナリングの使用に関する詳細を見つけることができます。 -メカニズムを括ってください。また、独占である状態で会議制御プロトコルかもう一方、包含を使用することで会議識別子を得ることができます、出かけている、-、本書では集結された会議フレームワークがわかるなら、会議システムはデフォルト呼び出しシグナリングが議定書を作るときSIPをサポートするREQUIREDです。 他の呼び出しシグナリングプロトコル(例えば、ISUP)はOPTIONALです。
6.2. Conference Object
6.2. コンファレンスオブジェクト
A conference object provides the logical representation of a conference instance in a certain stage, such as a conference blueprint representing a conferencing system's capabilities, the data representing a conference reservation, and the conference state during an active conference. Each conference object is independently addressable through the conference control protocol interface (see Section 8.3). A conferencing system MUST provide a default blueprint representing the basic capabilities provided by that specific conferencing system.
会議オブジェクトはある段階の会議インスタンスの論理的な表現を提供します、活発な会議の間に会議システムの能力、会議の予約を表すデータ、および会議州を代表する会議青写真のように。 それぞれの会議オブジェクトは会議制御プロトコルインタフェースを通して独自にアドレス可能です(セクション8.3を見てください)。 会議システムはその特定の会議システムによって提供された基本的な能力を表すデフォルト青写真を提供しなければなりません。
Figure 3 illustrates the relationships between the conference identifier, the focus, and the conference object ID within the context of a logical conference instance, with the conference object corresponding to an active conference.
図3は論理的な会議インスタンスの文脈の中で会議識別子と、焦点と、会議オブジェクトIDとの関係を例証します、活発な会議に対応する会議オブジェクトで。
A conference object representing a conference in the active state can have multiple call signaling conference identifiers; for example, one for each call signaling protocol supported. There is a one-to-one mapping between an active conference object and a conference focus. The focus is addressed by explicitly associating unique conference IDs for each signaling protocol supported by the active conference object.
活動的な状態で会議を代表する会議オブジェクトは複数の呼び出しシグナリング会議識別子を持つことができます。 例えば、シグナリングプロトコルがサポートした各呼び出しあたり1つ。 活性会議オブジェクトと会議焦点の間には、1〜1つのマッピングがあります。 焦点は、活性会議オブジェクトによってサポートされたそれぞれのシグナリングプロトコルのために明らかにユニークな会議IDを関連づけることによって、扱われます。
Barnes, et al. Standards Track [Page 13] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[13ページ]RFC5239
....................................................................
. 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 |
+----------------+ +--------------+ +---------------+
.................................................................... . コンファレンスインスタンス… +---------------------------------------------------+ . . | コンファレンスオブジェクト識別子| . . | | . . | | . . +---------------------------------------------------+ . . ^ ^ . . | | . . v| . . ................................................... | . . . 集中してください。| . . . . | . . . +----------------------------------+ . | . . . |コンファレンス識別子(プロトコルY)| . | . . . +------------------------------------+ | . | . . . | コンファレンス識別子(ISUP)| | . | . . . +--------------------------------------+ |-+ . | . . . | コンファレンス識別子(一口)| |^ . | . . . | |-+| . | . . . | |^ | . | . . . +--------------------------------------+| | . | . . ............^...............................|.|.... | . . | | | | . ................|...............................|.|......|.......... | | | | |一口| | |コンファレンス| ISUP| |Y|コントロール| | | |プロトコル| +---------------+ | | | | | | | | | | v v対+に----------------+ +--------------+ +---------------+ | 会議| | 会議| | コンファレンス| | クライアント| | クライアント| | クライアント| | 1 | | 2 | | X| +----------------+ +--------------+ +---------------+
Figure 3: Identifier Relationships for an Active Conference
図3: アクティブなコンファレンスのための識別子関係
Barnes, et al. Standards Track [Page 14] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[14ページ]RFC5239
6.2.1. Conference Object Identifier
6.2.1. コンファレンスオブジェクト識別子
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.
それぞれの会議オブジェクトを外部的にアクセスしやすくするように、会議システムはシステムに異なった会議オブジェクトあたり1つのユニークな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.
ユーザが会議に創設したいか、または参加したがっていて、ユーザに特定の会議のための会議オブジェクト識別子がないとき、より一般的なシグナル伝達機構は適用されます。 他のシグナリングプロトコルは使用されるかもしれません、そして、ユーザには、会議システムにアクセスするあらかじめ設定された会議オブジェクト識別子があるかもしれませんか、または会議システムは特定の会議オブジェクト識別子にそれらを写像します。 会議がいったん設立されると、会議オブジェクト識別子はユーザが会議データのどれかを操るか、または高度な会議機能のどれかを利用するREQUIREDです。 同じ概念は他のシグナリングプロトコルを使用することで会議に参加するユーザに適用されます。 彼らは初めは、特定の会議システムによってサポートされた他のシグナリングプロトコルのどれかを使用するのにおいて会議に参加できますが、会議データのどれかを操るか、または高度な会議機能のどれかを利用するのに会議オブジェクト識別子を使用しなければなりません。 既述のとおり、ユーザが会議オブジェクト識別子を知っているメカニズムは、異なって、会議制御プロトコル、データモデルを使用して、および会議パッケージか完全にメールかウェブインタフェースなどのバンドメカニズムから脱しているかもしれません。
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'を論理的に写像します。 多くの会議システムの機密情報を含むように会議オブジェクト識別子に関するマッピングを見ることができます。会議システムは、データが保護されて、認定ユーザだけが会議制御プロトコルでその情報を操ることができて、適切なユーザだけが通知プロトコルを通して知らせを聞くのを確実にしなければなりません。 一般に、この情報によって普通の会議の参加者に分配されないと予想されるでしょう。
Barnes, et al. Standards Track [Page 15] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[15ページ]RFC5239
6.3. Conference User Identifier
6.3. コンファレンスユーザ識別子
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]で定義されます。 会議ユーザ識別子は、会議システムの範囲の中で唯一ユーザを特定するのに会議オブジェクト識別子と関連して使用されます。 また、会議インスタンスに参加していないかもしれない会議システムユーザを特定するための要件があります。 これらのユーザの例は、非参加している'床のControl議長'か'メディアPolicy Controller'でしょう。 会議ユーザ識別子は会議制御プロトコル要求でだれが命令を出しているかを唯一決定するためにはREQUIREDです、適切な方針を要求されたコマンドに適用できるように。
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などのシグナリング特有のプロトコルを使用することでユーザが会議に参加して、1つが既にそのユーザに関連づけられないなら、会議ユーザ識別子を割り当てなければなりません。 関係者が会議に参加するのにこの会議ユーザ識別子は必要ではありませんが、それはそれがどんなその後の会議制御プロトコル操作、そして/または、その会議に関連している通知の使用にも利用可能であるように会議システムで割り当てられた、割り当てられるべきREQUIREDです。 例えば、既存の関係者に送られるどんな通知でも会議ユーザ識別子を送るでしょう、議長などのように、このユーザが加わるとき。
The conference user identifier is logically associated with the other user identifiers assigned to the conferencing client for other protocol interfaces, such as an authenticated SIP user. The mapping of the conference user identifier to signaling specific user identifiers requires that methods for protecting and securing a user's identity are considered. Section 11.1 addresses "User Authentication and Authorization" and Section 11.2 addresses the "Security and Privacy of User Identity". In addition, the conferencing system MUST ensure the appropriate access control around any internal data structure that maintains this persistent data. This information would typically only be available to a conferencing system administrator.
会議ユーザ識別子は他のプロトコルインタフェースのために会議クライアントに割り当てられる他のユーザ識別子に論理的に関連しています、認証されたSIPユーザのように。 特定のユーザ識別子に合図することへの会議ユーザ識別子に関するマッピングは、ユーザのアイデンティティを保護して、保証するためのメソッドが考えられるのを必要とします。 セクション11.1は「ユーザー認証と承認」を扱います、そして、セクション11.2は「ユーザのアイデンティティのセキュリティとプライバシー」を扱います。 さらに、会議システムはこの永続的なデータを保守するどんな内部のデータ構造の周りでも適切なアクセス制御を確実にしなければなりません。 会議システム管理者だけに、この情報は通常利用可能でしょう。
Barnes, et al. Standards Track [Page 16] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[16ページ]RFC5239
7. Conferencing System Realization
7. 会議システム実現
Implementations based on this centralized conferencing framework can range from systems supporting ad hoc conferences, with default behavior only, to sophisticated systems with the ability to schedule recurring conferences, each with distinct characteristics, being integrated with external resource reservation tools, and providing snapshots of the conference information at any of the stages of the conference life-cycle.
この集結された会議フレームワークに基づく実装は会議ライフサイクルのステージのいずれでもデフォルトの振舞いだけと、再発会議の計画をする能力がある精巧なシステムと、それぞれはっきりした性格で外部の資源予約ツールについて統合しているのを会議にサポートして、会議情報のスナップを提供に臨時にサポートするシステムから変化できます。
A conference object is the logical representation of a conference instance at a certain stage, such as capabilities description upon conference creation, reservation, activation, etc., which a conferencing system maintains in order to describe the system capabilities and to provide access to the available services provided by the conferencing system. Consequently, this centralized conferencing framework does not mandate the actual usage of the conference object, but rather defines the general cloning tree concept and the mechanisms required for its realization, as described in detail in Section 7.1.
会議オブジェクトはある段階の会議インスタンスの論理的な表現です、会議作成、予約、起動などの能力記述などのように。(会議システムは、システム能力について説明して、会議システムによって提供された営業品目へのアクセスを提供するためになどを維持します)。 その結果、この集結された会議フレームワークは、会議オブジェクトの実際の使用法を強制しませんが、むしろ一般的なクローニング木の概念を定義します、そして、メカニズムが実現に必要です、セクション7.1で詳細に説明されるように。
Ad hoc and advanced conferencing examples are provided in Section 7.2 and Section 7.3, with the latter providing additional description of the conference object in terms of the stages of a conference, to support scheduled and other advanced conference capabilities. The scheduling of a conference based on these concepts and mechanisms is then detailed in Section 7.4
臨時の、そして、高度な会議の例をセクション7.2とセクション7.3に提供します、後者が予定されていて他の高度な会議能力をサポートするために会議のステージに関して会議オブジェクトの追加記述を提供していて。 これらの概念とメカニズムに基づく会議のスケジューリングはその時、セクション7.4で詳細です。
As discussed in Section 5.2, the overall policy in terms of permissions and limitations is outside the scope of this framework document. The policies applicable to the conference object as a whole in terms of read/write access would require a conferencing system have access to basic policy information to make the decisions. In the examples in this section, the policies are shown logically associated with the conference objects to emphasize the general requirement for policy functionality necessary for the realization of this framework.
セクション5.2で議論するように、このフレームワークドキュメントの範囲の外に許容と制限による総合的な方針があります。 /が会議システムを必要とするとアクセスに書く読書で全体で会議オブジェクトに適切な方針は、決定をするように基本方針情報に近づく手段を持っています。 このセクションの例では、方針はこのフレームワークの実現に必要な方針の機能性のための一般的な要件を強調する会議オブジェクトに論理的に関連していた状態で示されます。
7.1. Cloning Tree
7.1. クローニング木
The concept defined in this section is a logical representation only, as it is reflected through the centralized conferencing mechanisms: the URIs and the protocols. Of course, the actual system realization can differ from the presented model. The intent is to illustrate the role of the logical elements in providing an interface to the data, based on conferencing system and conferencing client actions, and describe the resultant protocol implications.
それが集結された会議メカニズムを通して反映されるとき、このセクションで定義された概念は論理的な表現専用です: URIとプロトコル。 もちろん、実際のシステム実現は提示されたモデルと異なることができます。 意図は、会議システムと会議クライアント動作に基づくデータにインタフェースを提供する際に論理要素の役割を例証して、結果のプロトコル含意について説明することです。
Barnes, et al. Standards Track [Page 17] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[17ページ]RFC5239
Any conference object in a conferencing system is created by either being explicitly cloned from an existing parent object or being implicitly cloned from a default system conference blueprint. A conference blueprint is a static conference object used to describe a typical conference setting supported by the system. Each system can maintain multiple blueprints, typically each describing a different conferencing type using the conference information format. This document uses the "cloning" metaphor instead of the "inheritance" metaphor because it more closely fits the idea of object replication, rather than a data type re-usage and extension concept.
会議システムのどんな会議オブジェクトも、既存の親オブジェクトから明らかにクローンを作られるか、またはデフォルトシステム会議青写真からそれとなくクローンを作られることによって、作成されます。 会議青写真はシステムによってサポートされた典型的な会議設定について説明するのに使用される静的な会議オブジェクトです。 会議情報形式を使用することで異なった会議タイプについて通常それぞれ説明して、各システムは複数の青写真を維持できます。 より密接にデータ型再用法と拡大概念よりむしろオブジェクト模写の考えに合うので、このドキュメントは「継承」比喩の代わりに「クローニング」比喩を使用します。
The cloning operation needs to specify whether or not the link between the parent and child needs to be maintained in the system. If no link between the parent and child exists, the objects become independent and the child is not impacted by any operations on the parent object nor subject to any limitations of the parent object.
クローニング操作は、親子の間のリンクが、システムで維持される必要であるかどうか指定する必要があります。 親子の間のリンクが全く存在していないなら、オブジェクトは独立するようになります、そして、どんな操作でも子供は親オブジェクトと親オブジェクトのどんな限界を条件として影響を与えられません。
Once the new object is created, it can be addressed by a unique conference object URI assigned by the system, as described in Section 6.2.1. By default, the newly created object contains all the data existing in the parent object. The newly created object can expand the data it contains, within the schema types supported by the parent. It can also restrict the read/write access to its objects. However, unless the object is independent, it cannot modify the access restrictions imposed by the parent object.
新しいオブジェクトがいったん作成されると、システムによって割り当てられたユニークな会議オブジェクトURIでそれを扱うことができます、セクション6.2.1で説明されるように。 デフォルトで、新たに作成されたオブジェクトは親オブジェクトに存在するすべてのデータを含んでいます。 新たに作成されたオブジェクトはそれが親によってサポートされた図式タイプの中に含むデータを広げることができます。 また、それは/がオブジェクトへのアクセスを書く読みを制限する場合があります。 しかしながら、オブジェクトが独立していない場合、それは親オブジェクトによって課されたアクセス制限を変更できません。
Any piece of data in the child object can be independently accessed and, by default, can be independently modified without affecting the parent data.
親データに影響しないで、子供オブジェクトのどんなデータに独自にアクセスできて、デフォルトで独自に変更できます。
Unless the object is independent, the parent object can enforce a different policy by marking certain data elements as "parent enforceable". The values of these data elements cannot be changed by directly accessing the child object, nor can they be expanded in the child object alone.
オブジェクトが独立していない場合、「親実施できる」としてあるデータが要素であるとマークすることによって、親オブジェクトは異なった方針を実施できます。 直接子供オブジェクトにアクセスすることによって、これらのデータ要素の値を変えることができません、そして、子供オブジェクトで単独でそれらを広げることができません。
Figure 4 illustrates an example of a conference (Parent B), which is created independent of its Parent (Parent A). Parent B creates two child objects, Child 1 and Child 2. Any of the data elements of Parent B can be modified (i.e., there are no "parent enforceable" data elements), and depending upon the element, the changes will be reflected in Child 1 and Child 2 , whereas changes to Parent A will not impact the data elements of Parent B. Any "parent enforceable" data elements, as defined by Parent B, cannot be modified in the child objects.
図4は会議(親B)に関する例を例証します。(会議はParent(親A)の如何にかかわらず創設されます)。 親Bは2子供のオブジェクト、Child1、およびChild2を作成します。 Parent Bのデータ要素のどれかを変更できます、そして、(すなわち、「親実施できる」データ要素が全くありません)要素によって、変化はChild1とChild2に反映されるでしょう、そして、Parent Aへの変化に影響を与えないでしょうが、子供オブジェクトでParent Bによって定義されるParentのB.のAnyの「親実施できる」データ要素のデータ要素は変更できません。
Barnes, et al. Standards Track [Page 18] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[18ページ]RFC5239
+---+-----------------------+
| p | |
| o | P A R E N T A |
| l | |
| i | C O N F E R E N C E |
| c | |
| i | O B J E C T |
| e | |
+-s-+-----------------------+
|
\| /
\/ INDEPENDENT
/\
/| \
V
+---+-----------------------+
| p | |
| o | P A R E N T B |
| l | |
| i | C O N F E R E N C E |
| c | |
| i | O B J E C T |
| e | |
+-s-+-----------------------+
| |
| |
| ---------------------------
| |
V V
+---+-----------------------+ +---+-----------------------+
| p | | | p | |
| o | C H I L D 1 | | o | C H I L D 2 |
| l | | | l | |
| i | C O N F E R E N C E | | i | C O N F E R E N C E |
| c | | | c | |
| i | O B J E C T | | i | O B J E C T |
| e | | | e | |
+-s-+-----------------------+ +-s-+-----------------------+
+---+-----------------------+ | p| | | o | P A R E N T A| | l| | | i| N C O F E RのE N C E| | c| | | i| ○ B J E C T| | e| | +s+-----------------------+ | \| /\/独立者/\/| \対+---+-----------------------+ | p| | | o | PはR E N T Bです。| | l| | | i| N C O F E RのE N C E| | c| | | i| ○ B J E C T| | e| | +s+-----------------------+ | | | | | --------------------------- | | +に対するV---+-----------------------+ +---+-----------------------+ | p| | | p| | | o | C H I L D1| | o | C H I L D2| | l| | | l| | | i| N C O F E RのE N C E| | i| N C O F E RのE N C E| | c| | | c| | | i| ○ B J E C T| | i| ○ 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.
定義されたクローニングモデルとその道具を使用して、以下のセクションはどうこのフレームワークに基づく異系統を実現できるかに関する例を示しています。
Barnes, et al. Standards Track [Page 19] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[19ページ]RFC5239
7.2. Ad Hoc Example
7.2. 臨時の例
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で指定されるように。 会議工場は内部的にSession記述プロトコル(SDP)本体で要求しているクライアント特権に基づいていて、メディア系列を含めて、会議青写真であることがサポートされたシステムの1つを選択できます。
The selected blueprint with its default values is copied by the server into a newly created conference object, referred to as an 'Active Conference'. At this point, the conference object becomes independent from its blueprint. A new conference object identifier, a new conference identifier, and a new focus are allocated by the server.
デフォルト値がある選択された青写真はサーバによって'アクティブなコンファレンス'と呼ばれた新たに作成された会議オブジェクトにコピーされます。 ここに、会議オブジェクトは青写真から独立するようになります。 サーバは新しい会議オブジェクト識別子、新しい会議識別子、および新しい焦点を割り当てます。
During the conference lifetime, an authorized client can manipulate the conference object, by performing operations such as adding participants, using the conference control protocol.
会議生涯、認可されたクライアントは会議オブジェクトを操作できます、関係者を加えなどなどの操作を実行することによって、会議制御プロトコルを使用して。
+---+-----------------------+
| p | |
| o | System Default |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Active |
| l | |
| i | Conference |
| c | |
| i | |
| e | |
+-s-+-----------------------+
+---+-----------------------+ | p| | | o | システム・デフォルト| | l| | | i| コンファレンス| | c| | | i| 青写真| | e| | +s+-----------------------+ | \| / \/ /\ /| \対+---+-----------------------+ | p| | | o | アクティブ| | l| | | i| コンファレンス| | c| | | i| | | e| | +s+-----------------------+
Figure 5: Conference Ad-hoc Creation and Lifetime
図5: コンファレンスの臨時の作成と生涯
Barnes, et al. Standards Track [Page 20] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[20ページ]RFC5239
7.3. Advanced Example
7.3. 高度な例
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.
他方では、システムは関係者の最大数や参加者名簿などのいくつかの会議サブオブジェクトを親実施できると定義できます。 その結果、親会議の予約だけにアクセスすることによって、これらのオブジェクトを変更できます。 自動的にローカルの方針を条件としてこれらのオブジェクトへの変化をそれぞれの子供の予約に適用できます。
Barnes, et al. Standards Track [Page 21] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[21ページ]RFC5239
+---+-----------------------+
| p | |
| o | Selected |
| l | |
| i | Conference |
| c | |
| i | Blueprint |
| e | |
+-s-+-----------------------+
|
\| /
\/
/\
/| \
V
+---+-----------------------+
| p | |
| o | Conference |
| l | |
| i | Reservation |
| c | |
| i | |
| e | |
+-s-+-----------------------+
| | |
| | |
| | |
| | |
+---|--|--V-----------------+
+-+---|--V------------------+ |
+-+-+---V-------------------+ | |
| p | | | |
| o | Child Conference | | |
| l | | | |
| i | Reservation | | |
| c | | | |
| i | | |-+
| e | |-+
+-s-+-----------------------+
+---+-----------------------+ | p| | | o | 選択されます。| | l| | | i| コンファレンス| | c| | | i| 青写真| | e| | +s+-----------------------+ | \| / \/ /\ /| \対+---+-----------------------+ | p| | | o | コンファレンス| | l| | | i| 予約| | c| | | i| | | e| | +s+-----------------------+ | | | | | | | | | | | | +---|--|--V-----------------+ +-+---|--V------------------+ | +-+-+---V-------------------+ | | | p| | | | | o | 子供コンファレンス| | | | l| | | | | i| 予約| | | | 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
時間が'始め'時間が達しているか、クライアント実施であったというどちらかシステム決断を通した会議条件の計画をするようになるとき、活発な会議は会議の予約に基づいてクローンを作られます。 臨時の例のように、活発な会議は親から独立しています、そして、会議の予約への変化が活発な会議に影響を与えないでしょう。 いくらか
Barnes, et al. Standards Track [Page 22] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[22ページ]RFC5239
desired changes must be targeted towards the active conference. An example of this interaction is shown in Section 9.1.
活発な会議に向かって必要な変化を狙わなければなりません。 この相互作用に関する例はセクション9.1に示されます。
7.4. Scheduling a Conference
7.4. コンファレンスの計画をします。
The capability to schedule conferences forms an important part of the conferencing system solution. An individual conference reservation typically has a specified 'start' and 'end' time, with the times being specified relative to a single specified 'fixed' time (e.g., 'start' = 09.00 GMT, 'end'= 'start'+2), subject to system considerations. In most advanced conferencing solutions, it is possible to not only schedule an individual occurrence of a conference reservation, but also schedule a series of related conferences (e.g., a weekly meeting that starts on Thursday at 09.00 GMT).
会議の計画をする能力は会議システムソリューションの重要な部分を形成します。 個々の会議の予約には、指定された'始め'と'終わり'時間が通常あります、システム問題を条件として回がただ一つの指定された'修理された'時間(例えば、'始め'=グリニッジ標準時09.00、'終わり'=は+2に'始まる')に比例して指定されている状態で。 ほとんどの高度な会議ソリューションでは、会議の予約の個々の発生の計画をするだけではなく、一連の関連会議(例えば、木曜日のグリニッジ標準時09.00からの週会)の計画もするのも可能です。
To be able to achieve such functionality, a conferencing system needs to be able to appropriately schedule and maintain conference reservations that form part of a recurring conference. The mechanism proposed in this document makes use of the "Internet Calendaring and Scheduling Core Object" specification defined in [RFC2445] in union with the concepts introduced in Section 5 for the purpose of achieving advanced conference scheduling capability.
そのような機能性を達成できるように、会議システムは、会議の予約が再発会議のそのフォーム部分であることを適切に計画をして、支持できる必要があります。 本書では提案されたメカニズムは一体となっている高度な会議スケジューリング能力を達成する目的のためにセクション5で紹介されている概念で[RFC2445]で定義された「インターネットCalendaringとスケジューリングコアオブジェクト」仕様を利用します。
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"オブジェクトに有効な会議の予約と参照を含みます。
Barnes, et al. Standards Track [Page 23] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[23ページ]RFC5239
+--------------+ +-------Conferencing System-----------------+
| Generic ICAL | | |
| Resource | | ..Conference Instance.... |
+--------------+ | . . +-----------+|
^ ^ | . +-------------------+ . | Conference||
| | | . |Conference Objects |<--| Control ||
| ----------------->. +-------------------+ . | Server ||
| | . . +-----------+|
| | ......................... ^ |
| | ^ | |
+-----|--------------+ | | |
| v | | |
| +--------------+ | | |
| | Resource |<------------------+ | |
| | Scheduler | | |
| +--------------+ | |
| | |
+---------------------------------------------------------|------+
|
|
+-Request-+
| |
+----+ |
|ICAL| |
+----+----+
|
|
|
Conference Control|
Protocol |
|
+-------------+
| Conferencing|
| Client |
+-------------+
+--------------+ +-------会議システム-----------------+ | ジェネリックICAL| | | | リソース| | ..コンファレンスインスタンス… | +--------------+ | . . +-----------+| ^ ^ | . +-------------------+ . | コンファレンス|| | | | . |コンファレンスオブジェクト| <--、| コントロール|| | ----------------->。 +-------------------+ . | サーバ|| | | . . +-----------+| | | ......................... ^ | | | ^ | | +-----|--------------+ | | | | v| | | | +--------------+ | | | | | リソース| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | スケジューラ| | | | +--------------+ | | | | | +---------------------------------------------------------|------+ | | +要求+| | +----+ | |ICAL| | +----+----+ | | | コンファレンスコントロール| プロトコル| | +-------------+ | 会議| | クライアント| +-------------+
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要求は有効にされます、そして、結果の会議の予約は作成されます。 会議オブジェクト識別子(例えば、xcon: hd87928374)によって会議の予約は会議システムの中に唯一表されます、セクション6.2.1で導入されて、[XCON-COMMON]で定義されるように。 このユニークなURIをクライアントに返して、会議の予約に参照をつけるのに使用できます、何か今後の操作が必要であるなら(例えば、'始め'時間を変更してください)、CCP要求を使用して。
Barnes, et al. Standards Track [Page 24] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[24ページ]RFC5239
The previous example explains how a client creates a basic conference reservation using an iCal reference in association with a conference control protocol. Figure 7 can also be applied when explaining how a series of conferences are scheduled in the system. The description is almost identical with the exception that the iCal definition that is included in a CCP request represents a series of recurring conference instances (e.g., conference 'start' time, 'end' time, occur weekly). The conferencing system will treat this request the same as the first example. The CCP request will be validated, along with the associated iCal object, and the conference reservation is created. The conference reservation and its conference object ID, created for this example, represent the entire series of recurring conference instances rather than a single Conference. If the client uses the conference object ID provided and a CCP request to adjust the conference reservation, every conference instance in the series will be altered. This includes all future occurrences, such as a conference scheduled as an infinite series, subject to the limitations of the available calendaring interface.
前の例で、クライアントが会議制御プロトコルと関連してiCal参照を使用することでどう基本的な会議の予約を作成するかがわかります。 また、一連の会議がシステムでどう予定されているかを説明するとき、図7を適用できます。 記述は例外とほとんど同じです。CCP要求に含まれているiCal定義は一連の再発会議インスタンスを表します(例えば会議'始め'時間('終わり'時間)は毎週起こります)。 会議システムは同じように最初の例としてこの要求を扱うでしょう。 CCP要求は関連iCalオブジェクトと共に有効にされるでしょう、そして、会議の予約は作成されます。 この例のために作成された会議の予約とその会議オブジェクトIDはただ一つのコンファレンスよりむしろ再発会議インスタンスのシリーズもの全巻を表します。 クライアントが提供された会議オブジェクトIDと会議の予約を調整するというCCP要求を使用すると、シリーズにおけるあらゆる会議インスタンスが変更されるでしょう。 これはすべての将来の発生を含んでいます、無限のシリーズとして利用可能なcalendaringインタフェースの制限を条件として予定されていた会議のように。
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に起こる予定であった会議の予約です。次の3週間だけ、ミーティングは、グリニッジ標準時10.00に代替の開催地に起こるように変更されています。 図7が念頭にあると、クライアントは再発会議インスタンスの既存の会議の予約を変更する目的がことであるCCP要求を構成するでしょう。 クライアントは会議システムによって提供された、会議システムの中で明らかに会議の予約に参照をつけた会議オブジェクトIDを入れるでしょう。 CCP要求は会議条件(例えば、会合場所の変更)へのすべての必要な変化を含むでしょう。
The conferencing system matches the incoming CCP request to the existing conference reservation but identifies that the associated iCal object only refers to a range of the existing series. The conferencing system creates a child, by cloning the original conference reservation, to represent the altered conference instances within the series. The cloned child object is not independent of the original parent object, thus preventing any potential conflicts in scheduling (e.g., a change to the whole series ''start' time'). The cloned conference reservation, representing the altered series of conference instances, has its own associated conference object ID that is returned to the client using a CCP response. This conference object ID is then used by the client to make any future alterations on the newly defined sub-series. This process can be repeated any number of times as the newly returned conference object ID representing an altered (cloned) series of conference instances, can
会議システムは、既存の会議の予約に入って来るCCP要求に合っていますが、関連iCalオブジェクトがさまざまな既存のシリーズを示すだけであるのを特定します。 会議システムは子供を創造します、シリーズの中に変えられた会議インスタンスを表すために当初の会議の予約のクローンを作ることによって。 'クローン児オブジェクトはオリジナルの親オブジェクトから独立していません、その結果、(例えば、全シリーズ「スタート'時間'への変化)の計画をする際にどんな潜在的闘争も防ぎます」。 クローンの会議の予約には、変えられたシリーズの会議インスタンスを表して、CCP応答を使用することでクライアントに返されるそれ自身の関連会議オブジェクトIDがあります。 そして、この会議オブジェクトIDは、新たに定義されたサブシリーズにおけるどんな今後の変更もするのにクライアントによって使用されます。 変えられた(クローンの)シリーズの会議インスタンスを表す新たに返された会議オブジェクトIDとしていろいろな回このプロセスを繰り返すことができます、缶
Barnes, et al. Standards Track [Page 25] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[25ページ]RFC5239
itself be manipulated using a CCP request for the newly created conference object ID . This provides a flexible approach to the scheduling of recurring conference instances.
新たに作成された会議オブジェクトIDにCCP要求を使用することで操られてください。それ自体、これは再発会議インスタンスのスケジューリングへの柔軟性のあるアプローチを提供します。
8. Conferencing Mechanisms
8. 会議メカニズム
8.1. Call Signaling
8.1. シグナリングに電話をしてください。
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要求は、焦点に伝えられて、会議方針に対してチェックされます。 承認されるなら、関係者は、焦点からの/に呼び出しシグナリングを使用することで加えられるか、または削除されます。
8.2. Notifications
8.2. 通知
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]で定義されて、[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.
会議ユーザ識別子と関連役割が会議システムによって使用されて、通知をフィルターにかけるので、それらはそのユーザに送ることができる情報だけを含んでいます。
8.3. Conference Control Protocol
8.3. コンファレンス制御プロトコル
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.
会議制御プロトコルは会議オブジェクトによって表された集結された会議データのためのデータ操作と州の検索に備えます。 会議制御プロトコルの詳細は別々のドキュメントに明らかにされます。
8.4. Floor Control
8.4. 床のコントロール
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
床の制御プロトコルで、認可されたクライアントは、他の会議のユーザのその床へのアクセスを特定の床へのアクセスを管理して、与えるか、否定するか、または取り消します。 床のコントロールはa義務的ではありません。
Barnes, et al. Standards Track [Page 26] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[26ページ]RFC5239
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].
しかし、会議システムの実現のためのメカニズム、それは会議のユーザのために入力コントロール機能を高度なメディアに提供します。 会議システムの中の床のコントロールのためのメカニズムは「2進の床の制御プロトコル(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を含まなければなりません。 SDPモデルが[RFC4583]で説明されるように使用されているとき、この識別子は'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あたり1つの会議ユーザIDによって唯一代理をされます。 すべての床のコントロールメッセージにこの会議ユーザIDを含まなければなりません。 呼び出しシグナリングプロトコルを使用する焦点との床のコントロール接続を交渉するのにSDP申し出/答え交換を使用するとき、ユニークな会議ユーザ識別子は'ユーザID'SDP属性に含まれています、[RFC4583]で定義されるように。
A media session within a conferencing system can have any number of floors (0 or more) that are represented by the conference identifier. When using SDP offer/answer exchange to negotiate a floor control connection with the focus using the call signaling interface, the unique conference identifier is contained in the 'floorid' SDP attribute, as defined in [RFC4583], e.g., a=floorid:1 m-stream:10 . Each 'floorid' attribute, representing a unique floor, has an 'm-stream' tag containing one or more identifiers. The identifiers represent individual SDP media sessions (as defined using 'm=' from SDP) using the SDP 'Label' attribute, as defined in [RFC4574].
会議システムの中のメディアセッションは会議識別子によって表されるいろいろな床(0以上)を持つことができます。 '呼び出しシグナリングインタフェースを使用する焦点との床のコントロール接続を交渉するのにSDP申し出/答え交換を使用するとき、ユニークな会議識別子は'floorid'SDP属性に含まれています、[RFC4583]で定義されるように、例えば、a=floorid: ユニークな床を表して、mストリーム: 10がそれぞれ'floorid'結果と考える1がそうした、-流れてください、'1つ以上の識別子を含むタグ。 '識別子は個々のSDPメディアセッションを表します。(定義されるように、使用しているのは、[RFC4574]で定義されるように='SDP) 使用からのSDP'ラベル'属性です。
Barnes, et al. Standards Track [Page 27] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[27ページ]RFC5239
9. Conferencing Scenario Realizations
9. 会議シナリオ実現
This section addresses how advanced conferencing scenarios, many of which have been described in [RFC4597], are realized using this centralized conferencing framework. The objective of this section is to further illustrate the model, mechanisms, and protocols presented in the previous sections and also serves to validate that the model, mechanisms, and protocols are sufficient to support advanced conferencing scenarios.
このセクションは高度な会議シナリオ(それの多くが[RFC4597]で説明される)がこの集結された会議フレームワークを使用することでどう実現されるかを扱います。 このセクションの目的はさらにモデル、メカニズム、およびセクションが前に提示されて、また有効にするモデル、メカニズム、およびプロトコルがそうであるサーブが高度な会議シナリオをサポートすることができるくらい提示されたプロトコルを例証することです。
The scenarios provide a high level primitive view of the necessary operations and general logic flow. The details shown in the scenarios are for illustrative purposes only and don't necessarily reflect the actual structure of the conference control protocol messages nor the detailed data, including states, which are defined in separate documents. It should be noted that not all entities impacted by the request are shown in the diagram (e.g., focus), but rather the emphasis is on the new entities introduced by this centralized conferencing framework.
シナリオは必要な操作と一般的な論理の流れの高い平らな原始の意見を提供します。 シナリオに示された詳細は、説明に役立った目的だけのためにあって、必ず制御プロトコルが通信して、州を含む中で別々の状態で定義される詳細データが記録する会議の実際の構造を反映するというわけではありません。 要求で影響を与えられたというわけではないすべての実体が強調がこの集結された会議フレームワークによって導入された新しい実体にあるのがダイヤグラム(例えば、焦点)、しかし、むしろ示されることに注意されるべきです。
9.1. Conference Creation
9.1. コンファレンス作成
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.
エイト環は、特定の会議システムに利用可能な会議青写真を決定して、必要な青写真に基づく会議を創設しながら、クライアント「アリス」という1に関する例を提供します。
Barnes, et al. Standards Track [Page 28] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[28ページ]RFC5239
+--------------------------------+
| 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> | +-----------+ |
+--------------------------------+
+--------------------------------+ | 会議システム| 「アリス」| +------------+| +--------+ | | || | |CCPは、<が>を青写真にとるよう要求します。| +-----------+ | || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|コンファレンス| |コンファレンス|| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|コントロール|~~~>|青写真|| +--------+ CCP応答<blueprintA| |サーバ| | || ... | +-----------+ +------------+| blueprintZ| | confUserID>。| | 「アリス」| +--------+ | | | |CCPは<蓄えを要求します。| +------------+| | | blueprintAConfObjID| +-----------+ | || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|コンファレンス| |コンファレンス|| | | confUserID>。| |コントロール|~~~>|BlueprintA|| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|サーバ| | || | |CCP応答| | | +------------+| +--------+ <reservationConfObjID| | | \|/ | confID>。| | | /|\ | | | | V| | | | +------------+| | | |~~~>|コンファレンス|| | | | |予約|| | +-----------+ +------------+| 「アリス」| | | +--------+ | | | | |CCP要求<は加えます。| V| | |reservationConfObjID| +-----------+ +------------+| | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|コンファレンス| |アクティブ|| | | confID、confUserID>。| |コントロール|~~~>|コンファレンス|| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|サーバ| | || | |CCP応答| | | +------------+| +--------+ <activeConfObjID| | | | confID>。| +-----------+ | +--------------------------------+
Figure 8: Client Creation of Conference Using Blueprints
エイト環: 青写真を使用するコンファレンスのクライアント作成
Upon receipt of the conference control protocol request for blueprints, the conferencing system would first authenticate "Alice" (and allocate a conference user identifier, if necessary) and then ensure that "Alice" has the appropriate authority based on system policies to receive any blueprints supported by that system. Any blueprints that "Alice" is authorized to use are returned in a response, along with the conference user ID.
青写真を求める会議制御プロトコル要求を受け取り次第、会議システムは、最初に、「アリス」(必要なら、会議ユーザ識別子を割り当てる)を認証して、次に、「アリス」がそのシステムによってサポートされたどんな青写真も受け取るために適切な権威をシステム方針に基づかせているのを確実にするでしょう。 会議ユーザIDに伴う応答で「アリス」が使用するのが認可されるどんな青写真も返します。
Barnes, et al. Standards Track [Page 29] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[29ページ]RFC5239
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カンフェレンス・ブリッジを予約しました。 したがって、「アリス」は必要な会議IDを必要な関係者に含む会議情報を提供します。 「アリス」を含む最初の関係者であるときに、会議、活発な会議、および焦点に追加されるという要求は作成されます。 焦点はIDが要求で受けた会議に関連しています。 会議を操る権威を持っているどんな関係者も応答で活性会議オブジェクトに関する会議オブジェクト識別子を受け取るでしょう。
9.2. Participant Manipulations
9.2. 関与している操作
There are different ways to affect a participant state in a conference. A participant can join and leave the conference using call signaling means only, such as SIP. This kind of operation is called "1st party signaling" and does not affect the state of other participants in the conference.
会議で関与している状態に影響する異なった方法があります。 関係者は、SIPなどの呼び出しシグナリング手段だけを使用することで会議に参加して、出ることができます。 この種類の操作は、「最初のパーティーシグナリング」と呼ばれて、会議の他の関係者の状態のふりをしません。
Barnes, et al. Standards Track [Page 30] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[30ページ]RFC5239
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.
また、呼び出しシグナリングだけを使用して、焦点を通って他の会議の参加者(いわゆる「3番目のパーティーコントロール」)を監督するための株式会社操作もいくつかのシグナリングプロトコルに利用可能であるかもしれません。 例えば、「一口ユーザエージェントのための会議」[RFC4579]はこの機能性を達成するのにどうREFERとSIPを使用できるかを示しています。
In order to perform richer conference control, a user client needs to implement a conference control protocol client. By using a conference control protocol, the client can affect its own state, the state of other participants, and the state of various resources (such as media mixers) that may indirectly affect the state of any of the conference participants.
より豊かな会議コントロールを実行するために、ユーザクライアントは、会議の制御プロトコルクライアントを実装する必要があります。 会議制御プロトコルを使用することによって、クライアントはそれ自身の州、他の関係者の州、および間接的に会議の参加者のどれかの状態に影響するかもしれない様々なリソース(メディアミキサーなどの)の状態に影響できます。
Figure 9 provides an example of one client "Alice" impacting the state of another client "Bob". This example assumes an established conference. In this example, "Alice" wants to add "Bob" to the conference.
図9は、別のクライアント「ボブ」の状態に影響を与えながら、クライアント「アリス」という1に関する例を提供します。 この例は設立された会議を仮定します。 この例では、「アリス」は「ボブ」を会議に追加したがっています。
+--------------------------------+
| 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"
+--------------------------------+ | 会議システム| 「アリス」| +---------+--+| +--------+ | |方針| || | |CCPは<を要求します。| +-----------+ +---------+ || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|コンファレンス| | アクティブ|| | | コンファレンスオブジェクトID| |コントロール|~~~>|コンファレンス|| +--------+は、「ボブ」>と言い足します。| |サーバ| | || | +-----------+ +-------+ || | |「アリス」| || 「キャロル」| ' ' '| +--------+が<「ボブ」=に通知する、「">"は加えました。|+------------+ ' ' '| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|通知|<~~~| || | クライアント|. . ||サービス| +-------+ || +--------+--+ . || | |「ボブ」| || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +-------+----+| | クライアント|「ボブ」=が「加えた」<に通知してください。>|+------------+ | +--------+ +--------------------------------+ 「ボブ」
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によって特定されるように特定の会議でパーティー(「ボブ」)を「加える」という会議制御プロトコル要求を受け取り次第、会議システムは、「アリス」が操作を実行するために適切な権威をその特定の会議オブジェクトに関連している方針に基づかせているのを確実にします。 また、会議システムは、「ボブ」が既にこの会議システムのユーザであるかどうかかそれとも彼が新しいユーザであるかどうか決定しなければなりません。
Barnes, et al. Standards Track [Page 31] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[31ページ]RFC5239
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.
「ボブ」がこの会議システムのための新しいユーザであるなら、コンファレンスUser Identifierはボブのために作成されます。 「アリス」によって「ボブ」に提供されたアドレス指定情報に基づいて、「ボブ」を会議に追加するのを示す呼び出しは焦点を通って扇動されます。
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.
一度、呼び出しシグナリングは、首尾よく状態へのアップデートあたりの特定の会議に「ボブ」を追加してあって、方針によって、会議通知サービスで他の関係者(「ボブ」を含んでいます)が「ボブ」の追加について会議に通知されるかもしれないのを示します。
9.3. Media Manipulations
9.3. メディア操作
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.
会議でメディアを操る異なった方法があります。 関係者は、例えば、新しいSDP内容がSIPだけを使用している状態で再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に関する例を提供します。 この例は設立された会議を仮定します。 この例では、Roleが会議の「議長」である「アリス」というクライアントは中型マルチパーティ会議で「ボブ」に音を消したがっています、彼のデバイスが音を消されないで(彼は明らかに呼び出しを聞いていません)、彼のオフィス環境におけるバックグラウンドノイズが会議に破壊的であるときに。
Barnes, et al. Standards Track [Page 32] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[32ページ]RFC5239
+--------------------------------+
| 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"
+--------------------------------+ | 会議システム| 「アリス」| +---------+--+| +--------+ | |方針| || | |CCPは<を要求します。| +-----------+ +---------+ || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|コンファレンス| |アクティブ|| | | コンファレンスオブジェクトID| |コントロール|~~~>|コンファレンス|| +--------+ 無言の「ボブ」>。| |サーバ| | || | +-----------+ +-------+ || | |「アリス」| || 「キャロル」| ' ' '| +--------+は無言の<「ボブ」=">"に通知します。|+------------+ ' ' '| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|通知|<~~~| || | クライアント|. . ||サービス| +-------+ || +--------+--+ . || | |「ボブ」| || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +-------+----+| | クライアント| 「<「ボブ」=無言に通知してください」>|+------------+ | +--------+ +--------------------------------+ 「ボブ」
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.
方針によって、会議通知サービスで他の関係者(「ボブ」を含んでいます)はこの変化について通知されるかもしれません。
9.4. Sidebar Manipulations
9.4. サイドバー操作
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
サイドバーを表す会議オブジェクトは、既存の会議に関連している親のクローンを作って、サイドバーに特定のどんな情報もアップデートすることによって、作成されます。 サイドバー会議オブジェクトはそうです。
Barnes, et al. Standards Track [Page 33] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[33ページ]RFC5239
implicitly linked to the parent conference object (i.e., it is not an independent object) and is associated with the parent conference object identifier, as shown in Figure 11. A conferencing system manages and enforces the parent and appropriate localized restrictions on the sidebar conference object (e.g., no members from outside the parent conference instance can join, sidebar conference cannot exist if parent conference is terminated, etc.).
図11に示されるようにそれとなく親会議オブジェクトにリンクして(すなわち、それは独立しているオブジェクトではありません)、親会議オブジェクト識別子に関連づけられます。 会議システムは、管理して、親と適切なローカライズしている制限にサイドバー会議オブジェクトに押しつけます(例えば、親会議インスタンスの外からのどんなメンバーも加わることができないで、親会議が終えられるのなどなら、サイドバー会議は存在できません)。
+--------------+
| Conference |
| Object |
| Identifier |
+--------------+
|
|
|
+---------------------+---------------------+
| | |
+-------+-------+ +-------+-------+ +-------+-------+
| Sidebar | | Sidebar | | Sidebar |
| Conference | | Conference | | Conference |
| Object | | Object | | Object |
| Identifier | | Identifier | | Identifier |
+-------+-------+ +-------+-------+ +---------------+
+--------------+ | コンファレンス| | オブジェクト| | 識別子| +--------------+ | | | +---------------------+---------------------+ | | | +-------+-------+ +-------+-------+ +-------+-------+ | サイドバー| | サイドバー| | サイドバー| | コンファレンス| | コンファレンス| | コンファレンス| | オブジェクト| | オブジェクト| | オブジェクト| | 識別子| | 識別子| | 識別子| +-------+-------+ +-------+-------+ +---------------+
Figure 11: Conference Object Mapping
図11: コンファレンスオブジェクトマッピング
Figure 11 illustrates the relationship between a conference object and associated sidebar conference objects within a conferencing system. Each sidebar conference object has a unique conference object identifier, as described in Section 6.2.1. The main conference object identifier acts as a top level identifier for associated sidebars.
図11は会議システムの中で会議オブジェクトと関連サイドバー会議オブジェクトとの関係を例証します。 それぞれのサイドバー会議オブジェクトには、ユニークな会議オブジェクト識別子がセクション6.2.1で説明されるようにあります。 主な会議オブジェクト識別子は関連サイドバーのための最高平らな識別子として機能します。
A sidebar conference object identifier follows many of the concepts outlined in the cloning tree model described in Section 7.1. A sidebar conference object contains a subset of members from the original conference object. Properties of the sidebar conference object can be manipulated by a Conference Control Protocol using the unique conference object identifier for the sidebar. It is also possible for the top level conference object to enforce policy on the sidebar object (similar to parent enforceable, as discussed in Section 7.1).
サイドバー会議オブジェクト識別子はセクション7.1で説明されたクローニング木のモデルで概説された概念の多くに続きます。 サイドバー会議オブジェクトはオリジナルの会議オブジェクトからのメンバーの部分集合を含んでいます。 コンファレンスControlプロトコルは、サイドバーにユニークな会議オブジェクト識別子を使用することでサイドバー会議オブジェクトの特性を操作できます。 また、トップ平らな会議オブジェクトが方針にサイドバーオブジェクト(セクション7.1の議論するとして実施できる親と同様の)に押しつけるのも、可能です。
Barnes, et al. Standards Track [Page 34] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[34ページ]RFC5239
9.4.1. Internal Sidebar
9.4.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に関する例を提供します。 「アリス」は、まだ主な会議に関連しているビデオを見ている間、「ボブ」とのサイド議論をするためにサイドバーを作成したがっています。 あるいはまた、換算体積で主な会議からのオーディオを維持できました。 「アリス」は、活性会議オブジェクトに基づく会議の予約を作成するために会議システムに要求を送ることによって、サイドバーを開始します。 「アリス」と「ボブ」は主な会議に関する当直表に残っているでしょう、他の関係者が主な会議への彼らの参加を意識できるように、内部のサイドバー会議が起こっている間。
Barnes, et al. Standards Track [Page 35] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[35ページ]RFC5239
+--------------------------------+
| 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" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+
+--------------------------------+ | 会議システム| | +---------+--+| | |方針| || | +---------+ || | |アクティブ|| | |コンファレンス|| 「アリス」| +-------+ || +--------+ | |「アリス」| || | |CCP Req<createSidebar| +-------+ || | | activeConfObjID| +-----------+ |「ボブ」| || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|コンファレンス| +-------+ || | | confUserID>。| |コントロール|~~~>|「キャロル」| || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|サーバ| +-------+----+| | |CCP応答| | | | | +--------+ <sidebarResvConfObjID| | | | | confID>。| | | V| | | | +---------+--+| | | | |方針| || | | |~~~>+---------+ || | | | | || | +-----------+ | || 「アリス」| | サイドバー|| +--------+ | | 予約|| | |CCPは<アップデートを要求します。| +-----------+ | || | | sidebarResvConfObjID| | | | || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |~~~>| || | | confID、confUserID| | | +------------+| | | ビデオは親と等しいです。| | | | | | | オーディオはサイドバー>と等しいです。| |コンファレンス| | | | | | |コントロール| V| | | | |サーバ| +---------+--+| | |CCP応答| | | |方針| || | | <activeSideConfObjID| | | +---------+ || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |アクティブ|| +--------+ confID>。| | | |サイドバー|| | | | |コンファレンス|| | +-----------+ +-------+ || | |「アリス」| || 「ボブ」| | | || +--------+は加えられた<「ボブ」=>に通知します。|+------------+ +-------+ || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|通知|<~~~| | || | クライアント| ||サービス| |「ボブ」| || +--------+ || | +-------+----+| |+------------+ | +--------------------------------+
Figure 12: Client Creation of a Sidebar Conference
図12: サイドバーコンファレンスのクライアント作成
Barnes, et al. Standards Track [Page 36] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[36ページ]RFC5239
Upon receipt of the conference control protocol request to "reserve" a new sidebar conference, based upon the active conference received in the request, the conferencing system uses the received active conference to clone a conference reservation for the sidebar. As discussed previously, the sidebar reservation is NOT independent of the active conference (i.e., parent). The conferencing system also reserves or allocates a conference ID to be used for any subsequent protocol requests from any of the members of the conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the sidebar reservation through the conference instance.
要求で受けられた活発な会議に基づく新しいサイドバー会議を「予約する」という会議制御プロトコル要求を受け取り次第、会議システムは、サイドバーの会議の予約のクローンを作るのに容認された活発な会議を使用します。 以前に議論するように、サイドバーの予約は活発な会議(すなわち、親)から独立していません。 また、会議システムは、会議のメンバーのどれかからのどんなその後のプロトコル要求にも使用されるために会議IDを予約するか、または割り当てます。 会議システムはIDが会議インスタンスを通してサイドバーの予約に関連づけたこの会議IDと会議オブジェクトの間のマッピングを維持します。
Upon receipt of the conference control protocol response to reserve the conference, "Alice" can now create an active conference using that reservation or create additional reservations based upon the existing reservations. In this example, "Alice" wants only "Bob" to be involved in the sidebar, thus she manipulates the membership. "Alice" also only wants the video from the original conference and wants the audio to be restricted to the participants in the sidebar. Alternatively, "Alice" could manipulate the media values to receive the audio from the main conference at a reduced volume. "Alice" sends a conference control protocol request to update the information in the reservation and to create an active conference.
会議を控える会議制御プロトコル応答を受け取り次第、「アリス」は、今、その予約を使用することで活発な会議を創設するか、または既存の予約に基づく追加予約を作成できます。 この例では、「アリス」は「ボブ」だけ、にサイドバーにかかわって欲しいです、その結果、彼女は会員資格を操ります。 「アリス」は、また、オリジナルの会議からビデオが欲しいだけであり、オーディオをサイドバーの関係者に制限して欲しいです。 あるいはまた、「アリス」は、換算体積で主な会議からオーディオを受け取るためにメディア値を操るかもしれません。 「アリス」は予約における情報をアップデートして、活発な会議を創設するという会議制御プロトコル要求を送ります。
Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conferencing system must also validate the updated information in the reservation, ensuring that a member like "Bob" is already a user of this conferencing system.
予約をアップデートして、サイドバーのための活発な会議を創設するという会議制御プロトコル要求を受け取り次第、会議オブジェクトIDによって特定されるように、会議システムは、「アリス」が操作を実行するために適切な権威をその特定の会議オブジェクトに関連している方針に基づかせているのを確実にします。 また、会議システムは予約におけるアップデートされた情報を有効にしなければなりません、「ボブ」のようなメンバーが既にこの会議システムのユーザであることを確実にして。
Depending upon the policies, the initiator of the request (i.e., "Alice") and the participants in the sidebar (i.e., "Bob") may be notified of his addition to the sidebar via the conference notification service.
会議通知サービスでサイドバー(すなわち、「ボブ」)で方針、要求(すなわち、「アリス」)の創始者、および関係者に頼るのは彼の追加についてサイドバーに通知されるかもしれません。
9.4.2. External Sidebar
9.4.2. 外部のサイドバー
Figure 13 provides an example of one client "Alice" involved in an active conference with "Bob", "Carol", "David", and "Ethel". "Alice" gets an important text message via a whisper from "Bob" that a critical customer needs to talk to "Alice", "Bob", and "Ethel". "Alice" creates a sidebar to have a side discussion with the customer "Fred" including the participants in the current conference with the
図13はクライアント「アリス」という「ボブ」、「キャロル」、「デヴィッド」、および「エセル」との活発な会議にかかわる1に関する例を提供します。 「アリス」は重要な顧客が、「アリス」、「ボブ」、および「エセル」と話す必要があるという「ボブ」からのささやき声を通した重要なテキストメッセージを得ます。 「アリス」は現在の会議の関係者を含んでいる顧客「フレッド」との横の議論をするサイドバーを作成します。
Barnes, et al. Standards Track [Page 37] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[37ページ]RFC5239
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.
「キャロル」と「デヴィッド」の例外。(」は活発な会議に残っています)。 「アリス」は、活性会議オブジェクトに基づく会議の予約を作成するために会議システムに要求を送ることによって、サイドバーを開始します。 「アリス」、「ボブ」、および「エセル」は保持州に主な会議に関する当直表に留まっているでしょう。 他の関係者にとって、これらの関係者の保持状態が目に見えるかどうかが個々の、そして、ローカルの方針によります。
+--------------------------------+
| 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 ||
| +-----------+ +-------+ ||
+--------------------------------+ | 会議システム| | +---------+--+| | |方針| || | +---------+ || | |アクティブ|| | |コンファレンス|| 「アリス」| +-------+ || +--------+ | |「アリス」| || | |CCP Req<createSidebar| +-------+ || | | activeConfObjID| +-----------+ |「ボブ」| || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|コンファレンス| +-------+ || | | confUserID>。| |コントロール|~~~>|「キャロル」| || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|サーバ| +-------+ || | |CCP応答| | | |「デヴィッド」| || +--------+ <sidebarResvConfObjID| | | +-------+ || confID>。| | | |「エセル」| || | | | +-------+----+| | | | | | | | | V| | | | +---------+--+| | | | |方針| || | | |~~~>+---------+ || | +-----------+ | || 「アリス」| | サイドバー|| +--------+ | | 予約|| | |CCPは<アップデートを要求します。| +-----------+ | || | | sidebarResvConfObjID| | | | || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |~~~>| || | | confID、confUserID| | | +------------+| | | ビデオはサイドバーと等しいです。| | | | | | | オーディオはサイドバー>と等しいです。| |コンファレンス| | | | | | |コントロール| V| | | | |サーバ| +---------+--+| | |CCP応答| | | |方針| || | | <activeSideConfObjID| | | +---------+ || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |アクティブ|| +--------+ confID>。| | | |サイドバー|| | | | |コンファレンス|| | +-----------+ +-------+ ||
Barnes, et al. Standards Track [Page 38] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[38ページ]RFC5239
| |"Alice"| ||
"Bob" | +-------+ ||
+--------+ NOTIFY <"Bob"=added, |+------------+ |"Bob" | ||
| Client |<-------------------------|Notification|<~~~+-------+ ||
+--------+ "Ethel"=added, ||Service | |"Ethel"| ||
"Fred"=added,> || | +-------+ ||
"Ethel" +---| | |"Fred" | ||
+--------+ NOTIFY <"Bob"=added,| |+------------+ +-------+----+|
| Client | <--------------------+ +--------------------------------+
+--------+ "Ethel"=added,"Fred"=added,>
| |「アリス」| || 「ボブ」| +-------+ || +--------+は「ボブ」=が加えた<に通知します。|+------------+ |「ボブ」| || | クライアント| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|通知|<~~~+-------+ || +--------+ 「エセル」=は加えました。||サービス| |「エセル」| || 加えられた「フレッド」=、>。|| | +-------+ || 「エセル」+---| | |「フレッド」| || +--------+は「ボブ」=が加えた<に通知します。| |+------------+ +-------+----+| | クライアント| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ +--------------------------------+ +--------+ 加えられた「フレッド」=が加えた「エセル」=、>。
Figure 13: Client Creation of an External Sidebar
図13: 外部のサイドバーのクライアント作成
Upon receipt of the conference control protocol request to "reserve" a new sidebar conference, based upon the active conference received in the request, the conferencing system uses the received active conference to clone a conference reservation for the sidebar. As discussed previously, the sidebar reservation is NOT independent of the active conference (i.e., parent). The conferencing system also reserves or allocates a conference ID to be used for any subsequent protocol requests from any of the members of the conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the sidebar reservation through the conference instance.
要求で受けられた活発な会議に基づく新しいサイドバー会議を「予約する」という会議制御プロトコル要求を受け取り次第、会議システムは、サイドバーの会議の予約のクローンを作るのに容認された活発な会議を使用します。 以前に議論するように、サイドバーの予約は活発な会議(すなわち、親)から独立していません。 また、会議システムは、会議のメンバーのどれかからのどんなその後のプロトコル要求にも使用されるために会議IDを予約するか、または割り当てます。 会議システムはIDが会議インスタンスを通してサイドバーの予約に関連づけたこの会議IDと会議オブジェクトの間のマッピングを維持します。
Upon receipt of the conference control protocol response to reserve the conference, "Alice" can now create an active conference using that reservation or create additional reservations based upon the existing reservations. In this example, "Alice" wants only "Bob" and "Ethel", along with the new participant "Fred" to be involved in the sidebar; thus, she manipulates the membership. "Alice" sets the media such that the participants in the sidebar don't receive any media from the main conference. "Alice" sends a conference control protocol request to update the information in the reservation and to create an active conference.
会議を控える会議制御プロトコル応答を受け取り次第、「アリス」は、今、その予約を使用することで活発な会議を創設するか、または既存の予約に基づく追加予約を作成できます。 この例では、「アリス」は新しい関与している「フレッド」に伴う「ボブ」と「エセル」だけ、にサイドバーにかかわって欲しいです。 したがって、彼女は会員資格を操ります。 「アリス」がメディアを設定するので、サイドバーの関係者は主な会議からどんなメディアも受け取りません。 「アリス」は予約における情報をアップデートして、活発な会議を創設するという会議制御プロトコル要求を送ります。
Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conferencing system must also validate the updated information in the reservation, ensuring whether members like "Fred" are already a user of this conferencing system or whether he
予約をアップデートして、サイドバーのための活発な会議を創設するという会議制御プロトコル要求を受け取り次第、会議オブジェクトIDによって特定されるように、会議システムは、「アリス」が操作を実行するために適切な権威をその特定の会議オブジェクトに関連している方針に基づかせているのを確実にします。 または、また、会議システムは予約におけるアップデートされた情報を有効にしなければなりません、「フレッド」のようなメンバーが既にこの会議システムのユーザであるか否かに関係なく、確実にして彼
Barnes, et al. Standards Track [Page 39] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[39ページ]RFC5239
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.
新しいユーザはそうですか? 「フレッド」がこの会議システムのための新しいユーザであるので、会議ユーザ識別子は「フレッド」のために作成されます。 「アリス」によって「フレッド」に提供されたアドレス指定情報に基づいて、「フレッド」を会議に追加するのを示す呼び出しは焦点を通って扇動されます。
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.
会議通知サービスでサイドバー(すなわち、「ボブ」と「エセル」)で方針、要求(すなわち、「アリス」)の創始者、および関係者に頼るのは彼の追加についてサイドバーに通知されるかもしれません。
9.5. Floor Control Using Sidebars
9.5. サイドバーを使用する床のコントロール
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人のアナリストだけに床を与えます。 主な会議のすべての関係者がサイドバー会議からオーディオを受け取ります、パネリストによって主な会議に提供されたオーディオと同様に。
Barnes, et al. Standards Track [Page 40] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[40ページ]RFC5239
+--------------------------------+
| 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" | ||
|+------------+ +-------+----+|
+--------------------------------+
+--------------------------------+ | 会議システム| | +---------+--+| | |方針| || | +---------+ || | |アクティブ|| | |コンファレンス|| | +-------+ || | |「アリス」| || | +-------+ || | +-----------+ |「ボブ」| || | |コンファレンス| +-------+ || | |コントロール|~~~>|"A1""| || | |サーバ| +-------+ || | | | |"A2""| || | | | +-------+ || | | | |"A3""| || | | | +-------+----+| | | | | | | | | V| | | | +---------+--+| | | | |方針| || | | |~~~>+---------+ || | | | |アクティブ|| | +-----------+ |サイドバー|| "A1""| |コンファレンス|| +--------+ 床の要求<"A1""|+------------+ +-------+ || | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|床のCtrl| |「キャロル」| || |クライアント| activeSideConfObjID||サーバ|~~~>|、| || +--------+ confID>。|| | +-------+----+| |+------------+ | | | V| | +---------+--+| | |方針| || | +---------+ || | |アクティブ|| | |サイドバー|| "A1""| |コンファレンス|| +--------+ 床は<"A1""を与えました。|+------------+ +-------+ || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|床のCtrl|<~~~|「キャロル」| || | クライアント| activeSideConfObjID||サーバ| +-------+ || +--------+ confID>。|| | |"A1""| || |+------------+ +-------+----+| +--------------------------------+
Figure 14: Floor Control with Sidebars
図14: サイドバーとの床のコントロール
Barnes, et al. Standards Track [Page 41] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[41ページ]RFC5239
When "A1" wishes to ask a question, he sends a Floor Request message to the floor control server. Upon receipt of the request, the floor control server notifies the moderator, "Carol" of the active sidebar conference, who's serving as the floor chair. Note, that this signaling flow is not shown in the diagram. Since no other analysts have yet requested the floor, "Carol" indicates to the floor control server that "A1" may be granted the floor.
質問するというA1"願望、彼は床の制御サーバに床の要求メッセージを送ります。(会議は床のいすとして勤めています)。いつ、「要求を受け取り次第、床の制御サーバは活発なサイドバー会議について議長、「キャロル」に通知するか」。 このシグナリング流動がダイヤグラムで示されないというメモ。 他のどんなアナリストもまだ床を要求していないので、「キャロル」は、「床をA1"に与えるかもしれません。」と床の制御サーバに示します。
9.6. Whispering or Private Messages
9.6. 私語しているか個人的なメッセージ
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.
ちょうど2人の関係者と共にサイドバーとしてプライベート・メッセージに関するケースを扱うことができます、セクション9.4.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.
図15は「ボブ」と「キャロル」との固定長会議の議長を務めているユーザ「アリス」という1に関する例を提供します。 構成がそのようなものであるので、10だけが会議に何分も残っているとき、いすだけが警告を提供しています。 その時、「アリス」は会議システムによって作成されたサイドバーに動かされます、そして、「アリス」だけ、が発表を受けます。
Barnes, et al. Standards Track [Page 42] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[42ページ]RFC5239
+--------------------------------+
| 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 > || | +---/---+\---+|
|+------------+ / \ |
+--------------------------------+
+--------------------------------+ | 会議システム| | +---------+--+| | |方針| || | +---------+ || | |アクティブ|| | |コンファレンス|| | +-------+ || | |「アリス」| || | +-------+ || | +-----------+ |「ボブ」| || | |コンファレンス| +-------+ || | |コントロール|~~~>|「キャロル」| || | |サーバ| +-------+----+| | | | | | | | | | | | | | V| | | | +---------+--+| | | | |方針| || | | |~~~>+---------+ || | | | | || | +-----------+ |サイドバー|| 「アリス」| |コンファレンス|| +--------+は「アリス」=が加えた<に通知します。|+------------+ +-------+ || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|通知| | | || | クライアント| activeSideConfObjID||サービス|<~~~|「アリス」| || +--------+ confID>。|| | +-------+----+| |+------------+ | ~~~「アリス」に提供された発表~~~ | +-----------+ | | |コンファレンス| | | |コントロール| | | |サーバ| | | | | | | | | \---------+--/| | | | |\ /|| | | |~~~>+\/|| | | | | \ / || | +-----------+ |シド\バー/|| 「アリス」| |Conf\re/Ce|| +--------+は「アリス」=が取り外した<に通知します。|+------------+ +-----\/+ || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|通知|<~~~| /\| || | クライアント| activeSideConfObjID||サービス| |「アリ/Ce\」|| +--------+ confID>。|| | +---/---+\---+| |+------------+ / \ | +--------------------------------+
Figure 15: Whisper
図15: ささやき声
Barnes, et al. Standards Track [Page 43] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[43ページ]RFC5239
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.
会議システムが、10だけがサイドバーに行われた予約を作成するより「アリス」が議長を務めている会議に何分もむしろセクション9.4.1に残っていることを決定すると、会議システムは直接活発なサイドバー会議を創設します、「アリス」に関連している活発な会議に基づいて。 以前に議論するように、サイドバー会議は活発な会議(すなわち、親)から独立していません。 また、会議システムは、サイドバー会議のどんなその後の操作にも使用されるために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.
発表の完成のときに、サイドバーから「アリス」を取り除きます、そして、サイドバー会議を削除します。 方針によって、会議通知サービスで「アリス」は彼女の取り外しについてサイドバーから通知されるかもしれません。
9.7. Conference Announcements and Recordings
9.7. コンファレンス発表と録音
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に示されます。
Barnes, et al. Standards Track [Page 44] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[44ページ]RFC5239
+--------------------------------+
| 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~~~
| |
+--------------------------------+
+--------------------------------+ | 会議システム| 「アリス」| +-----------+ | +--------+ | |コンファレンス| | | |CCPは<を要求します。| |コントロール| | | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |サーバ| | | |ボブのConference ID| | | | +--------+は>を接合します。| | | | | | | | | ~ ~ | ~~~「アリス」に提供された発表~~~ ~~~ ケタは「アリス」を取りました。~~~ | ~ ~ +---------+--+| | | |~~~>|方針| || | | | +---------+ || | | | |アクティブ|| | | | |コンファレンス|| | | | +-------+ || | | | |「ボブ」| || | | | +-------+ || | | | |「キャロル」| || | | | +-------+----+| | ~ ~ | ~~~「アリス」に提供された発表~~~ ~~~ アリスは彼女の名前を記録します。~~~ | ~ ~ +---------+--+| | | | |方針| || | | | +---------+ || | | |~~~>|アクティブ|| | +-----------+ |コンファレンス|| | +-------+ || | |「ボブ」| || 「ボブ」| +-------+ || +--------+は「アリス」=が加えた<に通知します。|+------------+ |「キャロル」| || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|通知| +-------+ || | クライアント| activeSideConfObjID||サービス|<~~~|「アリス」| || +--------+ confID>。|| | +-------+----+| |+------------+ | ~~~すべての党に提供された発表~~~ | | +--------------------------------+
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
「ボブ」の会議に参加する「アリス」からの会議制御プロトコル要求を受け取り次第、会議システムは要求に会議オブジェクトに受け取られた識別子を写像します。
Barnes, et al. Standards Track [Page 45] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[45ページ]RFC5239
representing "Bob's" active conference. The conferencing system determines that a password is required for this specific conference; thus, an announcement asking "Alice" to enter the password is provided to "Alice". Once "Alice" enters the password, it is validated against the policies associated with "Bob's" active conference. The conferencing system then connects to a server that prompts and records "Alice"'s name. The conferencing system must also determine whether "Alice" is already a user of this conferencing system or whether she is a new user.
「ボブ」の活発な会議を代表します。 会議システムは、パスワードがこの特定の会議に必要であることを決定します。 したがって、パスワードを入力するように「アリス」に頼む発表を「アリス」に提供します。 「アリス」がいったんパスワードを入力すると、それは「ボブ」の活発な会議に関連している方針に対して有効にされます。 そして、会議システムは」の「アリスものというプロンプトと記録が命名するサーバに接続します。 また、会議システムは、「アリス」が既にこの会議システムのユーザであるかどうかかそれとも彼女が新しいユーザであるかどうか決定しなければなりません。
If "Alice" is a new user for this conferencing system, a conference user identifier is created for "Alice". Based upon the addressing information provided by "Alice", the call signaling to add "Alice" to the conference is instigated through the focus.
「アリス」がこの会議システムのための新しいユーザであるなら、会議ユーザ識別子は「アリス」のために作成されます。 「アリス」によって提供されたアドレス指定情報に基づいて、「アリス」を会議に追加するのを示す呼び出しは焦点を通って扇動されます。
Once the call signaling indicates that "Alice" has been successfully added to the specific conference, per updates to the state, and depending upon the policies, other participants (e.g., "Bob") are notified of the addition of "Alice" to the conference via the conference notification service, and an announcement is provided to all the participants indicating that "Alice" has joined the conference.
一度、呼び出しシグナリングは、首尾よく「アリス」を特定の会議に追加してあって、方針に状態にアップデートして、よることに従って会議通知サービスで他の関係者(例えば、「ボブ」)が「アリス」の追加について会議に通知されて、発表が「アリス」が会議に参加したのを示す参加者各位に提供されるのを示します。
9.8. Monitoring for DTMF
9.8. DTMFのためのモニター
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に示されます。
9.9. Observing and Coaching
9.9. 観測とコーチ
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
また、この能力は、監督がエージェントが顧客と共に特定の呼び出しをどう扱っているかを観測するようにメカニズムを提供するときセンターアプリケーションと呼ぶのに申し込むかもしれません。 このシナリオはそうであることができます。
Barnes, et al. Standards Track [Page 46] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[46ページ]RFC5239
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.
既存の活発な会議に自分たちを追加している監督によって扱われて、aで、オーディオメディア経路だけを聴いてください。 エージェントが監督が呼び出しに参加する時を意識しているかどうかが、構成可能であるべきです。
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.
観測とコーチに関する例は図17に示されます。 この例では、コールセンターのエージェント「ボブ」は顧客「キャロル」との会議にかかわります。 「ボブ」が新しいエージェントであり、「アリス」が、標準より長い間、「キャロル」との呼び出しには彼がいるのがわかるので、彼女は、必要に応じて呼び出しとコーチ「ボブ」を観測すると決めます。
Barnes, et al. Standards Track [Page 47] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[47ページ]RFC5239
+--------------------------------+
| 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" | ||
+--------+ || | +-------+----+|
|+------------+ |
+--------------------------------+
+--------------------------------+ | 会議システム| | +---------+--+| | |方針| || | +---------+ || | |アクティブ|| | |コンファレンス|| 「アリス」| | || +--------+ | | || | |CCP Req<createSidebar| +-------+ || | | activeConfObjID| +-----------+ |「ボブ」| || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|コンファレンス| +-------+ || | | confUserID>。| |コントロール|~~~>|「キャロル」| || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|サーバ| +-------+----+| | |CCP応答| | | | | +--------+ <sidebarResvConfObjID| | | | | confID>。| | | V| | | | +---------+--+| | | | |方針| || | | |~~~>+---------+ || | | | | || | +-----------+ | || 「アリス」| | サイドバー|| +--------+ | | 予約|| | |CCPは<アップデートを要求します。| +-----------+ | || | | sidebarResvConfObjID| | | | || | クライアント|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |~~~>| || | | confID、confUserID>。| | | +------------+| | | | | | | | | | | |コンファレンス| | | | | | |コントロール| V| | | | |サーバ| +---------+--+| | |CCP応答| | | |方針| || | | <activeSideConfObjID| | | +---------+ || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |アクティブ|| +--------+ confID>。| | | |サイドバー|| | | | |コンファレンス|| | +-----------+ +-------+ || | |「アリス」| || 「ボブ」| | | || +--------+は「ボブ」=が加えた<に通知します。|+------------+ +-------+ || | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|通知|<~~~| | || | クライアント| 「いす」=「アリス」||サービス| |「ボブ」| || +--------+ || | +-------+----+| |+------------+ | +--------------------------------+
Figure 17: Supervisor Creating a Sidebar for Observing/Coaching
図17: 観測するか、またはコーチするためのサイドバーを作成する監督
Barnes, et al. Standards Track [Page 48] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[48ページ]RFC5239
Upon receipt of the conference control protocol request from "Alice" to "reserve" a new sidebar conference, based upon the active conference received in the request, the conferencing system uses the received active conference to clone a conference reservation for the sidebar. The conferencing system also reserves or allocates a conference ID to be used for any subsequent protocol requests from any of the members of the conference. The conferencing system maintains the mapping between this conference ID and the conference object ID associated with the sidebar reservation through the conference instance.
要求で受けられた活発な会議に基づく新しいサイドバー会議を「予約する」「アリス」からの会議制御プロトコル要求を受け取り次第、会議システムは、サイドバーの会議の予約のクローンを作るのに容認された活発な会議を使用します。 また、会議システムは、会議のメンバーのどれかからのどんなその後のプロトコル要求にも使用されるために会議IDを予約するか、または割り当てます。 会議システムはIDが会議インスタンスを通してサイドバーの予約に関連づけたこの会議IDと会議オブジェクトの間のマッピングを維持します。
Upon receipt of the conference control protocol response to reserve the conference, "Alice" can now create an active conference using that reservation or create additional reservations based upon the existing reservations. In this example, "Alice" wants only "Bob" to be involved in the sidebar; thus, she manipulates the membership. "Alice" also wants the audio to be received by herself and "Bob" from the original conference, but wants any outgoing audio from herself to be restricted to the participants in the sidebar, whereas "Bob's" outgoing audio should go to the main conference, so that both "Alice" and the customer "Carol" hear the same audio from "Bob". "Alice" sends a conference control protocol request to update the information in the reservation and to create an active conference.
会議を控える会議制御プロトコル応答を受け取り次第、「アリス」は、今、その予約を使用することで活発な会議を創設するか、または既存の予約に基づく追加予約を作成できます。 この例では、「アリス」は「ボブ」だけ、にサイドバーにかかわって欲しいです。 したがって、彼女は会員資格を操ります。 「アリス」は、また、自分と「ボブ」にオリジナルの会議からオーディオを受け取って欲しいのですが、自分からのどんな出発しているオーディオもサイドバーの関係者に制限して欲しいのですが、「ボブ」の出発しているオーディオは主な会議に動くはずです、「アリス」と顧客「キャロル」の両方が「ボブ」から同じオーディオを聞くように。 「アリス」は予約における情報をアップデートして、活発な会議を創設するという会議制御プロトコル要求を送ります。
Upon receipt of the conference control protocol request to update the reservation and to create an active conference for the sidebar, as identified by the conference object ID, the conferencing system ensures that "Alice" has the appropriate authority based on the policies associated with that specific conference object to perform the operation. Based upon the addressing information provided for "Bob" by "Alice", the call signaling to add "Bob" to the sidebar with the appropriate media characteristics is instigated through the focus.
予約をアップデートして、サイドバーのための活発な会議を創設するという会議制御プロトコル要求を受け取り次第、会議オブジェクトIDによって特定されるように、会議システムは、「アリス」が操作を実行するために適切な権威をその特定の会議オブジェクトに関連している方針に基づかせているのを確実にします。 「アリス」によって「ボブ」に提供されたアドレス指定情報に基づいて、適切なメディアの特性で「ボブ」をサイドバーに追加するのを示す呼び出しは焦点を通って扇動されます。
"Bob" is notified of his addition to the sidebar via the conference notification service; thus, he is aware that "Alice", the supervisor, is available for coaching him through this call.
会議通知サービスで「ボブ」は彼の追加についてサイドバーに通知されます。 したがって、彼は「アリス」(監督)がこの呼び出しで彼をコーチするのに利用可能であることを意識しています。
10. Relationships between SIP and Centralized Conferencing Frameworks
10. 一口と集結された会議フレームワークとの関係
The SIP Conferencing Framework [RFC4353] provides an overview of a wide range of centralized conferencing solutions known today in the conferencing industry. The document introduces a terminology and logical entities in order to systemize the overview and to show the common core of many of these systems. The logical entities and the listed scenarios in the SIP Conferencing Framework are used to
SIP Conferencing Framework[RFC4353]は今日会議産業で知られているさまざまな集結された会議ソリューションの概要を提供します。 ドキュメントは、概要をsystemizeして. 論理的な実体とSIP Conferencing Frameworkの記載されたシナリオが使用されているこれらのシステムの多くの一般的なコアを示しているために用語と論理的な実体を紹介します。
Barnes, et al. Standards Track [Page 49] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[49ページ]RFC5239
illustrate how SIP [RFC3261] can be used as a signaling means in these conferencing systems. The SIP Conferencing Framework does not define new conference control protocols to be used by the general conferencing system. It uses only basic SIP [RFC3261], the SIP Conferencing for User Agents [RFC4579], and the SIP Conference Package [RFC4575] for basic SIP conferencing realization.
シグナリングがこれらの会議システムで意味するようにどう、SIP[RFC3261]を使用できるかを例証してください。SIP Conferencing Frameworkは、一般的な会議システムによって使用されるために新しい会議制御プロトコルを定義しません。 それは基本的なSIP[RFC3261]、UserエージェントのためのSIP Conferencing[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]、UserエージェントのためのSIP Conferencing[RFC4579]、およびSIPコンファレンスパッケージ[RFC4575]は両方のフレームワークドキュメントと完全に互換性があります。 コンファレンス情報Data Modelに[RFC4575]で定義された基礎データ要素を含んでいることによって、Centralized Conferencing(XCON)[XCON-COMMON]に互換性の基礎を提供します。 [RFC4579]をサポートするだけであり、Conferencing Controlプロトコルをサポートしないユーザエージェントは、まだ基本的なSIP会議を提供していますが、高度な特徴のいずれも利用できません。
11. Security Considerations
11. セキュリティ問題
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
この会議フレームワークのセキュリティを囲むいくつかの問題があります。 1セットの問題は、実際のプロトコルと関連承認メカニズムを固定することを伴います。問題のこの第一セットはセクション8で説明されたプロトコルに特定の仕様と方針コントロールで扱われるべきです。 秘密情報の必要性の操作と検索に使用されるプロトコル
Barnes, et al. Standards Track [Page 50] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[50ページ]RFC5239
to support a confidentiality and integrity mechanism. Similar requirements apply for the floor control protocols. Section 11.3 discusses an approach for client authentication of a floor control server. It is RECOMMENDED that all the protocols that interface with the conferencing system implement Transport Layer Security (TLS).
秘密性と保全メカニズムをサポートするために。 同様の要件は床の制御プロトコルに申し込みます。 セクション11.3は床の制御サーバのクライアント認証のためのアプローチについて論じます。会議システムに接続するすべてのプロトコルがTransport Layer Security(TLS)を実装するのは、RECOMMENDEDです。
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は、権限のある機関だけが能力にアクセスするためにデータを操ることができるのを保証するために会議オブジェクトに関連している方針を論じます。 もう1セットの問題はセクション11.2で議論する会議における、ユーザのアイデンティティのプライバシーとセキュリティを伴います。
A final issue is related to Denial of Service (DoS) attacks on the conferencing system itself. In order to minimize the potential for DoS attacks, it is recommended that conferencing systems require user authentication and authorization for any client participating in a conference. It is recommended that the specific signaling and media protocols include mechanisms to minimize the potential for DoS.
最終的な問題は会議システム自体に対するサービス妨害(DoS)攻撃に関連します。 DoS攻撃の可能性を最小にするために、会議システムが会議に参加するどんなクライアントのためにもユーザー認証と承認を必要とするのは、お勧めです。 特定のシグナリングとメディアプロトコルがDoSの可能性を最小にするためにメカニズムを含んでいるのは、お勧めです。
11.1. User Authentication and Authorization
11.1. ユーザー認証と承認
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.
多くの方針承認決定がユーザのアイデンティティかユーザが持っているかもしれない役割に基づいています。 会議システムは、彼らのアイデンティティを有効にするためにユーザの認証を通常必要とします。 ユーザがシステムへのアイデンティティを認証するかもしれないいくつかの方法があります。 呼び出しシグナリングプロトコルの1つを使用することで会議に参加するユーザのために、特定のプロトコルのためのユーザー認証メカニズムはしばしば十分です。 会議制御プロトコルを合図するか、または使用することでSIPを通して会議に参加するユーザのケースのために、TLSはRECOMMENDEDです。
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.
また、会議システムが知るかもしれない、(例えば、外、-、-メカニズム) ほとんど特定のユーザと案配パスワードを括って、これらのユーザが権限を与えられるのを許容してください。 いくつかの場合(例えば、Public Switched Telephone Network(PSTN)ユーザ)、追加承認が、ユーザが会議に参加するのを許容するのに必要であるかもしれません。 これはInteractive Voice Response(IVR)システムか他の手段の形にあるかもしれません。 また、それで特定の会議IDとパーソナルIdentification(暗証番号)を知っていることによって、ユーザは権限を与えられるかもしれません。 時々、暗証番号は必要ではありません、そして、会議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
複数のメカニズムでユーザが権限を与えられる場合では、他の承認メカニズムとの呼び出しシグナリングインタフェースの承認を関連させるのは(望まれているなら)会議システムまで達しています。会議システムがメソッドを制限することによって複数のメカニズムに関する問題を避けることができる、どれ
Barnes, et al. Standards Track [Page 51] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[51ページ]RFC5239
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.
会議に参加できます。 例えば、ウェブインタフェースを会議に提供する多くの会議システムが、会議に参加するためのダイヤルアウトモードを強制することによって、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.
会議システムが認定ユーザのアイデンティティを提示するとき、それは、アイデンティティがシステムによって立証されたか、または確かめられた方法の情報を提供するのを選ぶかもしれません。 また、ユーザは完全に非認証されたユーザとしてシステムに来るかもしれません--この事実は、また、利害関係者とコミュニケートする必要があります。
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.
ユーザが会議システムの上で利用可能な様々なメカニズムを通していったん認証されて、権限を与えられると、会議ユーザ識別子は認証と承認に使用されたかもしれない特定のユーザ識別子に合図するいずれにも関連しています。 この会議ユーザ識別子を会議通知インタフェースを通して特定のユーザに提供するかもしれなくて、会議制御プロトコルを使用することで会議システムと対話するユーザに提供するでしょう。 この会議ユーザ識別子が会議オブジェクトにおけるどんなその後の操作にも必要です。
Barnes, et al. Standards Track [Page 52] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[52ページ]RFC5239
11.2. Security and Privacy of Identity
11.2. アイデンティティのセキュリティとプライバシー
This conferencing system has an idea of the identity of a user, but this does not mean it can reveal this identity to other users, due to privacy considerations. Users can select various options for revealing their identity to other users. A user can be "hidden" such that other users can not see they are participants in the conference, "anonymous" such that users can see that another user is there, but not see the identity of the user, or they can be "public" where other users can see their identity. If there are multiple "anonymous" users, other parties will be able to see them as independent "anonymous" parties and will be able to tell how many "anonymous" parties are in the conference. Note, that the visibility to other participants is dependent on their roles. For example, users' identity (including "anonymous" and "hidden") may be displayed to the moderator or administrator, subject to a conferencing system's local policies. "Hidden" status is often used by automated or machine participants of a conference (e.g., call recording) and is also used in many call center situations.
この会議システムには、ユーザのアイデンティティの考えがありますが、これは、他のユーザへのこのアイデンティティを明らかにすることができることを意味しません、プライバシー問題のため。 ユーザは他のユーザへの彼らのアイデンティティを明らかにするための様々なオプションを選択できます。 他のユーザがユーザが、別のユーザがそこにいるのを見ることができるように彼らは会議の関係者です、「匿名であること」がわかりませんが、ユーザのアイデンティティを見ることができませんし、また彼らが他のユーザが彼らのアイデンティティを見ることができるところで「公共であることができ」なるようにユーザを「隠すことができます」。 複数の「匿名」のユーザがいると、相手は、独立している「匿名」のパーティーであると彼らをみなすことができて、いくつの「匿名」のパーティーが会議中であるかを言うことができるでしょう。 他の関係者への目に見えることが彼らの役割に依存しているというメモ。 例えば、会議システムのローカルの方針を条件としてユーザのアイデンティティ(「匿名包含すること」の、そして、「隠された」)を議長か管理者に表示するかもしれません。 「隠された」状態は、しばしば会議の自動化されるかマシン関係者によって使用されて(例えば、録音と呼びます)、また、多くのコールセンター状況で使用されます。
Since a conferencing system based on this framework allocates a unique conference user identifier for each user of the conferencing system, it is not necessary to distribute any signaling specific user identifier to other users or participants. Access to any signaling specific user identifiers can be controlled by applying the appropriate access control to the signaling specific user identifiers in the data schema.
このフレームワークに基づく会議システムが会議システムの各ユーザのためにユニークな会議ユーザ識別子を割り当てるので、どんな合図している特定のユーザ識別子も他のユーザか関係者に分配するのは必要ではありません。 データ図式の合図している特定のユーザ識別子に適切なアクセス制御を適用することによって、いずれへの特定のユーザ識別子を示すアクセスは制御できます。
11.3. Floor Control Server Authentication
11.3. 床のコントロールサーバー証明
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 Connection特権階級ドキュメント[RFC5018]で説明されたメカニズムを利用します。
12. Acknowledgements
12. 承認
This document is a result of architectural discussions among IETF XCON Working Group participants. The authors would like to thank Henning Schulzrinne for the "Conference Object Tree" proposal and general feedback, Cullen Jennings for providing input for the "Security Considerations" section, and Keith Lantz, Dave Morgan, Oscar Novo, Roni Even, Umesh Chandra, Avshalom Houri, Sean Olson,
このドキュメントはIETF XCON作業部会の関係者の中の建築議論の結果です。 作者は「コンファレンスオブジェクト木」提案と一般的なフィードバックについてヘニングSchulzrinneに感謝したがっています、提供するためのジョニングスが「セキュリティ問題」セクション、およびキース・ランツのために入力したカレン、デイヴ・モーガン、オスカーノボ、ロニEven、Umeshチャンドラ、Avshalom Houri、ショーン・オルソン
Barnes, et al. Standards Track [Page 53] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[53ページ]RFC5239
Rohan Mahy, Brian Rosen, Pierre Tane, Bob Braudes, Gregory Sperounes, and Gonzalo Camarillo for their reviews and constructive input. In addition, the authors would like to thank Scott Brim for his gen-art review comments and Kurt Zeilenga for his secdir review comments.
彼らのレビューと建設的な入力のためのRohanマーイ、ブライアン・ローゼン、ピアーTane、ボブBraudes、グレゴリーSperounes、およびゴンサロ・キャマリロ。 さらに、作者は彼のsecdirレビューコメントのために彼の芸術に情報を得ているレビューコメントとカートZeilengaについてスコットBrimに感謝したがっています。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
13.2. Informative References
13.2. 有益な参照
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566, July 2006.
[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、2006年7月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
Model with Session Description Protocol (SDP)",
RFC 3264, June 2002.
[RFC3264] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3265] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring
and Scheduling Core Object Specification (iCalendar)",
RFC 2445, November 1998.
[RFC2445] ドーソンとF.とStenerson、D.、「インターネットCalendaringとスケジューリングはオブジェクト仕様(iCalendar)の芯を取る」RFC2445、1998年11月。
[RFC4245] Levin, O. and R. Even, "High-Level Requirements for
Tightly Coupled SIP Conferencing", RFC 4245,
November 2005.
[RFC4245]レヴィン、O.、およびR.、同等である、「密結合一口会議のためのハイレベルの要件」、RFC4245、11月2005日
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[RFC4353] 2006年2月のローゼンバーグ、J.、「セッション開始プロトコル(一口)がある会議のためのフレームワーク」RFC4353。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A
Session Initiation Protocol (SIP) Event Package for
Conference State", RFC 4575, August 2006.
[RFC4575] ローゼンバーグ、J.、Schulzrinne、H.、およびO.レヴィン、「コンファレンス状態へのセッション開始プロトコル(一口)イベントパッケージ」、RFC4575(2006年8月)。
Barnes, et al. Standards Track [Page 54] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議フレームワーク2008年6月に集結された標準化過程[54ページ]RFC5239
[RFC4376] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
"Requirements for Floor Control Protocols", RFC 4376,
February 2006.
2006年2月の[RFC4376]KoskelainenとP.とオットとJ.とSchulzrinne、H.とX.ウー、「床の制御プロトコルのための要件」RFC4376。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios",
RFC 4597, August 2006.
[RFC4597]、同等である、R.N.イスマイル、「会議シナリオ」RFC4597、8月2006日
[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.レヴィン、「セッション開始プロトコル(一口)は、ユーザエージェントのためにコントロール--会議を召集します」、BCP119、RFC4579、2006年8月。
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary
Floor Control Protocol (BFCP)", RFC 4582,
November 2006.
[RFC4582]キャマリロ、G.、オット、J.、およびK.Drage、「2進の床の制御プロトコル(BFCP)」、RFC4582 2006年11月。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574,
August 2006.
[RFC4574] レヴィンとO.とG.キャマリロ、「セッション記述プロトコル(SDP)ラベル属性」、RFC4574、2006年8月。
[RFC4583] Camarillo, G., "Session Description Protocol (SDP)
Format for Binary Floor Control Protocol (BFCP)
Streams", RFC 4583, November 2006.
[RFC4583]キャマリロ、G.、「2進の床の制御プロトコル(BFCP)の流れのためのセッション記述プロトコル(SDP)形式」、RFC4583、2006年11月。
[XCON-COMMON] Novo, O., Camarillo, G., Morgan, D., and R. Even,
"Conference Information Data Model for Centralized
Conferencing (XCON)", Work in Progress, March 2008.
[XCON一般的な] 「コンファレンスインフォメーション・データは集結された会議(XCON)のためにモデル化さえする」ノボ、O.、キャマリロ、G.、モーガン、D.、およびR.は進行中(2008年3月)で働いています。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975,
September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジョニングス、「メッセージセッションリレープロトコル(MSRP)」、RFC4975 2007年9月。
[RFC5018] Camarillo, G., "Connection Establishment in the Binary
Floor Control Protocol (BFCP)", RFC 5018,
September 2007.
[RFC5018]キャマリロ、G.、「2進の床の制御プロトコル(BFCP)へのコネクション確立」、RFC5018、2007年9月。
Barnes, et al. Standards Track [Page 55] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議枠組みの2008年6月に集結された標準化過程[55ページ]RFC5239
Authors' Addresses
作者のアドレス
Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX
メアリバーンズノーテル2201の湖畔Blvdリチャードソン(テキサス)
EMail: mary.barnes@nortel.com
メール: mary.barnes@nortel.com
Chris Boulton Avaya Building 3 Wern Fawr Lane St Mellons Cardiff, South Wales CF3 5EA
クリスボールトンAvaya Building3Wern Fawrレーン通りメロン・カーディフ、南ウェールズCF3 5EA
EMail: cboulton@avaya.com
メール: cboulton@avaya.com
Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052
Oritレヴィンマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: oritl@microsoft.com
メール: oritl@microsoft.com
Barnes, et al. Standards Track [Page 56] RFC 5239 Centralized Conferencing Framework June 2008
バーンズ、他 会議枠組みの2008年6月に集結された標準化過程[56ページ]RFC5239
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Barnes, et al. Standards Track [Page 57]
バーンズ、他 標準化過程[57ページ]
一覧
スポンサーリンク
