RFC 6504 - Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples 日本語訳

URL : https://tools.ietf.org/html/rfc6504
タイトル : RFC 6504 - 一元化会議操作プロトコル（CCMP）のコールフロー例
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                         M. Barnes
Request for Comments: 6504                                       Polycom
Category: Informational                                       L. Miniero
ISSN: 2070-1721                                                 Meetecho
                                                               R. Presta
                                                             S P. Romano
                                                    University of Napoli
                                                              March 2012

         Centralized Conferencing Manipulation Protocol (CCMP)
                           Call Flow Examples

Abstract

抽象

This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503). The objective is to provide detailed examples for reference by both protocol researchers and developers.

この文書は、詳細なコールが集中会議（XCON）（RFC 5239）のためのフレームワークで文書化シナリオに流れ、XCONシナリオ（RFC 4597）を提供します。コールフローは、会議制御クライアントとの集中会議操作プロトコル（CCMP）（RFC 6503）を使用して会議制御サーバ間のインタフェースの使用を文書化します。目的は、プロトコルの研究者及び開発者の両方によって参照のために詳細な例を提供することです。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6504.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6504で取得することができます。

著作権表示

著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Overview ........................................................4
   4. Working with CCMP ...............................................4
      4.1. CCMP and the Data Model ....................................5
      4.2. Using HTTP/TLS as a Transport ..............................6
      4.3. Conference Notifications ..................................10
   5. Conference Creation ............................................11
      5.1. Basic Conference Creation .................................12
      5.2. Conference Creation Using Blueprints ......................16
      5.3. Conference Creation Using User-Provided Conference
           Information ...............................................23
      5.4. Cloning an Existing Conference ............................28
   6. Conference Users Scenarios and Examples ........................31
      6.1. Adding a Party ............................................32
      6.2. Muting a Party ............................................35
      6.3. Conference Announcements and Recordings ...................38
      6.4. Monitoring for DTMF .......................................41
      6.5. Entering a Password-Protected Conference ..................42
   7. Sidebars Scenarios and Examples ................................44
      7.1. Internal Sidebar ..........................................45
      7.2. External Sidebar ..........................................54
      7.3. Private Messages ..........................................60
      7.4. Observing and Coaching ....................................64
   8. Removing Participants and Deleting Conferences .................71
      8.1. Removing a Party ..........................................71
      8.2. Deleting a Conference .....................................74
   9. Security Considerations ........................................75
   10. Acknowledgements ..............................................76
   11. References ....................................................76
      11.1. Normative References .....................................76
      11.2. Informative References ...................................76

1. Introduction

1. はじめに

This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) [RFC5239] and in the XCON scenarios [RFC4597]. The XCON scenarios describe a broad range of use cases taking advantage of the advanced conferencing capabilities provided by a system realization of the XCON framework. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503].

この文書では、集中型会議（XCON）[RFC5239]のためのフレームワークおよびXCONシナリオ[RFC4597]に記載されたシナリオの詳細なコールフローを提供します。 XCONシナリオはXCONフレームワークのシステム実現によって提供される高度な会議機能を利用して、ユースケースの広い範囲を説明します。コールフローは、会議制御クライアントとの集中会議操作プロトコル（CCMP）[RFC6503]を使用して会議制御サーバ間のインタフェースの使用を文書化します。

Due to the broad range of functionality provided by the XCON framework and the flexibility of the CCMP messaging, these call flows should not be considered inclusive of all the functionality that can provided by the XCON framework and protocol implementations. These flows represent a sample to provide an overview of the feature-rich capabilities of the XCON framework and CCMP messaging for protocol developers, software developers, and researchers.

起因XCONフレームワークとCCMPメッセージングの柔軟性が提供する機能の広い範囲に、これらのコールフローは、XCONフレームワークとプロトコルの実装によって提供されることができるすべての機能を含むと考えるべきではありません。これらのフローは、プロトコルの開発者、ソフトウェア開発者、および研究者のためのXCONフレームワークとCCMPメッセージングの機能豊富な機能の概要を提供するために、サンプルを表しています。

2. Terminology

2.用語

This document uses the same terminology as found in the Architectural Framework for Media Server Control [RFC5567] and in the Media Control Channel Framework Call Flow Examples [CALL-FLOWS], with the following terms and abbreviations used in the call flows. Also, note that the term "call flows" is used in a very generic sense in this document since the media is not limited to voice. The calls supported by the XCON framework and CCMP can consist of media such as text, voice, and video, including multiple media types in a single active conference.

メディアサーバ制御のためのアーキテクチャーのフレームワーク[RFC5567]にし、メディア制御チャネルフレームワークのコールフローの例[CALL-フロー]に見られるようなこの文書では、コールフローで使用される以下の用語および略語で、同じ用語を使用しています。また、メディアは音声に限定されるものではないので、用語「コールフロー」は、この文書では非常に一般的な意味で使用されていることに注意してください。 XCONフレームワークとCCMPによってサポートコールは、単一のアクティブな会議における複数のメディアタイプを含むテキスト、音声、およびビデオなどのメディアからなることができます。

Conference and Media Control Client (CMCC): as defined in the XCON framework. In the flows in this document, the CMCC is logically equivalent to the use of a User Agent Client (UAC) as the client notation in the media control call flows [CALL-FLOWS]. A CMCC differs from a generic media client in being an XCON-aware entity, thus, also being able to issue CCMP requests.

会議やメディアコントロールクライアント（CMCC）：XCONフレームワークで定義されています。この文書の流れにおいて、CMCCは、メディア制御コールフローにおけるクライアント表記としてユーザエージェントクライアント（UAC）の使用と論理的に等価である[コールフロー]。 CMCCは、このように、XCON対応のエンティティであることに、一般的なメディア・クライアントと異なっても、CCMP要求を発行することができるという。

Conference Server (ConfS): In this document, the term "conference server" is used interchangeably with the term "Application Server (AS)" as used in the media control architectural framework [RFC5567]. A conference server is intended to be able to act as a conference control server, as defined in the XCON framework, i.e., it is able to handle CCMP requests and issue CCMP responses.

会議サーバ（会議通話数）：この文書では、用語「会議サーバは、」メディア制御アーキテクチャフレームワーク[RFC5567]で使用される用語「アプリケーションサーバ（AS）」と交換可能に使用されます。会議サーバはXCONフレームワークで定義されているように、会議制御サーバとして機能することができるように意図され、すなわち、CCMP要求と問題CCMP応答を処理することができます。

Media Server (MS): as defined in the media control architectural framework [RFC5567].

メディアサーバ（MS）：メディア制御アーキテクチャフレームワーク[RFC5567]で定義されます。

3. Overview

3.概要

This document provides a sampling of detailed call flows that can be implemented based on a system realization of the XCON framework [RFC5239] and implementation of CCMP [RFC6503]. This is intended to be a simple guide for the use of the conference control protocol between the conference server and the conference control client. The objective is to provide an informational base reference for protocol developers, software developers, and researchers.

この文書では、CCMP [RFC6503]のXCONフレームワーク[RFC5239]及び実装のシステム実現に基づいて実施することができる詳細なコールフローのサンプリングを提供します。これは、会議サーバと会議制御クライアント間の会議制御プロトコルを使用するための簡単なガイドであることを意図しています。目的は、プロトコルの開発者、ソフトウェア開発者、および研究者のための情報ベース基準を提供することです。

This document focuses on the interaction between the conference and media control client and the conferencing system, specifically the conference server. The scenarios are based on those described in the XCON framework, many of which are based on the advanced conferencing capabilities described in the XCON scenarios. Additional scenarios have been added to provide examples of other real-life scenarios that are anticipated to be supported by the framework. With the exception of an initial example with media control messaging, the examples do not include the details for the media control [RFC6505], call signaling, or Binary Floor Control Protocols (BFCPs) [RFC4582]. This document references the scenarios in the media control call flows [CALL-FLOWS], SIP call control conferencing, [RFC4579], and BFCP documents.

この文書では、会議やメディアコントロールクライアントと会議システム、特に会議サーバ間の相互作用に焦点を当てています。シナリオはXCONのシナリオで説明した高度な会議機能に基づいており、その多くXCONフレームワークに記載されているものに基づいています。追加シナリオは、フレームワークによってサポートされると予想されている他の現実のシナリオの例を提供するために追加されました。メディア制御メッセージとの初期の例を除いて、実施例は、メディア制御[RFC6505]、コールシグナリング、またはバイナリフロア制御プロトコル（BFCPs）[RFC4582]の詳細を含んでいません。この文書では、メディア制御コールフローシナリオを参照し、[コールフロー]、SIP呼制御会議、[RFC4579]、およびBFCP文書。

The rest of this document is organized as follows. Section 4 presents an overview on CCMP, together with some implementation-related details and related matters like HTTPS transport and notifications. Section 5 presents the reader with examples showing the different approaches CCMP provides to create a new conference. Section 6 more generally addresses the different user-related manipulations that can be achieved by means of CCMP, by presenting a number of interesting scenarios. Section 7 addresses several scenarios that may involve the use of sidebars. Section 8 shows how CCMP can be used to remove conferences and users from the system. Finally, Section 9 provides a few details on the security considerations when it comes to implementing CCMP.

このドキュメントの残りは以下の通り構成されています。第4節では、一緒にいくつかの実装に関連する詳細およびHTTPSトランスポートや通知などの関連事項で、CCMPの概要を説明します。第5節では、CCMPは、新しい会議を作成するために提供して異なるアプローチを示す例を読者に提示します。第6節は、より一般的に興味深いシナリオの数を提示することによって、CCMPの手段によって達成することができる別のユーザーに関連した操作に対応しています。第7節は、サイドバーの使用を含むことができるいくつかのシナリオに対処しています。第8章は、CCMPは、システムからの会議とユーザーを除去するために使用することができる方法を示しています。それはCCMPを実装することになると最後に、第9節は、セキュリティ上の考慮事項についていくつかの詳細を提供します。

4. Working with CCMP

4. CCMPでの作業

This section provides a brief introduction as to how the Centralized Conferencing Manipulation Protocol (CCMP) [RFC6503] works and how it can be transported across a network. A typical CCMP interaction focusing on relevant aspects of the client-server communication is described. Please note that this section assumes the reader has read and understood the CCMP document. This section is intended to help the reader understand the actual protocol interactions.

このセクションでは、中央集中型の会議操作プロトコル（CCMP）[RFC6503]は動作し、それがネットワーク経由で輸送することができる方法方法についての簡単な紹介を提供します。クライアント - サーバ間の通信の関連する側面に焦点を当てた、典型的なCCMPの相互作用が記述されています。このセクションでは、読者が読み、CCMPの文書を理解している前提としていますのでご注意ください。このセクションでは、読者が実際のプロトコルの相互作用を理解するためのものです。

First, a description of the protocol itself is provided Section 4.1, including some implementation considerations. In Section 4.2, an effective CCMP interaction is presented by exploiting HTTPS as a transport. Finally, notifications are described in Section 4.3.

まず、プロトコル自体の説明は、いくつかの実装上の考慮事項を含む、セクション4.1が設けられています。セクション4.2で、有効なCCMP相互作用は、トランスポートとしてHTTPSを利用することによって提示されます。最後に、通知は、セクション4.3で説明されています。

The document then presents and describes some actual flows in detail in the sections to follow.

文書は、提示し、従うことのセクションで詳細にいくつかの実際の流れを説明しています。

4.1. CCMP and the Data Model

4.1. CCMPとデータモデル

CCMP is an protocol based on XML [W3C.REC-xml-20081126]. It has been designed as a request/response protocol. It is completely stateless, which means implementations can safely handle transactions independently from each other.

CCMPは、[W3C.REC-XML-20081126] XMLに基づくプロトコルです。これは、要求/応答プロトコルとして設計されています。これは実装が安全に互いに独立してトランザクションを処理できることを意味し、完全にステートレスです。

The protocol allows for the manipulation of conference objects and related users. This manipulation allows a conference and media control client (briefly CMCC in all the following sections) to create, update, and remove basically everything that is related to the objects handled by a conferencing system. This is reflected in the allowed operations (retrieve, create, update, delete) and the specified request types (ranging from the manipulation of blueprints and conferences to users and sidebars). For instance, CCMP provides ways to:

プロトコルは、会議オブジェクトと関連するユーザーの操作を可能にします。この操作は、会議やメディアコントロールクライアント（すべての次のセクションで簡単にCMCC）は会議システムで扱うオブジェクトに関連している基本的にすべてのものを作成、更新、および削除することができます。これは、許可された操作（作成、更新、取得、削除）と（ユーザとサイドバーへの青写真と会議の操作範囲）指定された要求のタイプに反映されます。例えば、CCMPはに方法を提供しています。

o retrieve the list of registered and/or active conferences in the system;

Oシステムにおける登録及び/またはアクティブな会議のリストを取得します。

o create new conferences by exploiting several different approaches;

O、いくつかの異なるアプローチを活用することによって、新しい会議を作成します。

o add/remove users to/from a conference;

O /追加会議へ/からユーザーを削除。

o update a conference with respect to all of its aspects;

Oその態様の全てに関して会議を更新します。

and so on.

等々。

While CCMP acts as the means to manipulate conference objects, CCMP does not define these conference objects. A separate document specifies how a conference object and all its components have to be constructed (Conference Information Data Model for Centralized Conferencing (XCON) [RFC6501]). CCMP, depending upon the request type and the related operation, carries pieces of conference objects (or any object as a whole) according to the aforementioned specification. This means that any implementation aiming at being compliant with CCMP has to make sure that the transported objects are completely compliant with the data model specification and coherent with the constraints defined therein. To make this clearer, there are elements that are mandatory in a conference object: issuing a syntactically correct CCMP request that carries a wrong conference object is doomed to result in a failure. For this reason, it is suggested that the interested implementers take special care in carefully checking the data model handlers as well in order to avoid potential mistakes.

CCMPは、会議オブジェクトを操作するための手段として機能している間、CCMPは、これらの会議オブジェクトを定義していません。別の文書には、会議オブジェクトとそのすべてのコンポーネントは、（集中管理会議（XCON）[RFC6501]のための会議情報データモデル）を構築する必要があるかを指定します。 CCMPは、要求タイプと関連する操作に応じて、前述の仕様に応じて会議オブジェクト（または全体として任意のオブジェクト）の部分を運びます。これはCCMPに準拠している目指し任意の実装では、転送されたオブジェクトが、その中に定義された制約と完全にデータモデルの仕様に準拠し、コヒーレントであることを確認しなければならないことを意味します。これをより明確にするために、会議のオブジェクトに必須の要素があります。間違った会議オブジェクトを運ぶ構文的に正しいCCMP要求が失敗に終わる運命にされて発行します。このため、興味のある実装は慎重に潜在的なミスを避けるために、同様のデータモデルハンドラを確認するには、特別な注意を払うことが示唆されます。

However, there are cases when a mandatory element in the data model cannot be assigned in a conference object by a CCMP user. For example, a CMCC may be requesting the direct creation of a new conference; in this case, a conference object assumes an 'entity' attribute uniquely identifying the conference to be in place. Thus, the CMCC has no way to know a priori what the entity will be, since it is generated by the ConfS after the request. For scenarios like this one, the CCMP specification describes the use of a dedicated placeholder wildcard (i.e., "AUTO_GENERATE_X", where X is an integer) to make the conference object compliant with the data model: the wildcard would then be replaced by the ConfS with the right value.

しかし、データモデルの必須の要素は、CCMPユーザによって会議オブジェクトに割り当てることができない場合があります。例えば、CMCCは、新しい会議の直接の作成を要求することができます。この場合、会議オブジェクトは、一意の場所にあるように、会議を識別する「エンティティ」属性を想定しています。それは、要求後の会議通話数によって生成されるので、このように、CMCCは、実体がどうなるかを先験的に知る方法がありません。このようなシナリオでは、CCMP仕様は、データ・モデルと会議オブジェクトが対応するための専用のプレースホルダのワイルドカード（Xは整数である、すなわち、「AUTO_GENERATE_X」）の使用を記載している：ワイルドカードは、その後会議通話数によって置き換えられます右の値を持ちます。

4.2. Using HTTP/TLS as a Transport

4.2. トランスポートとしてのHTTP / TLSを使用します

CCMP requires that implementations support HTTP/TLS as the transport mechanism. Per CCMP, a CMCC sends a request as part of an HTTPS POST message, and the ConfS would reply with a 200 OK HTTPS response. In both cases, the HTTPS messages carry the CCMP messages as payload, which is reflected in the Content-Type header ("application/ccmp+xml"). Figure 1 presents a ladder diagram of such an interaction, which is followed by a dump of the exchanged HTTPS messages for further analysis. The examples in the remainder of this document show only the CCMP interactions.

CCMPは、実装が転送メカニズムとしてHTTP / TLSをサポートする必要があります。 CCMPあたり、CMCCは、HTTPS POSTメッセージの一部として要求を送信し、会議通話数は200 OK HTTPS応答で応答します。両方の場合において、HTTPSメッセージは、Content-Typeヘッダ（「アプリケーション/ CCMP + XML」）に反映されるペイロードとしてCCMPメッセージを運びます。図1は、さらなる分析のためにHTTPSで交換されるメッセージのダンプが続くような相互作用のラダー図を示します。この文書の残りの部分の例は、CCMP相互作用を示しています。

    CMCC                                           ConfS
      |                                              |
      | 1. HTTPS POST (CCMP request)                 |
      |--------------------------------------------->|
      |                                              |
      |                                              |--+ Parse request,
      |                                              |  | update object
      |                                              |<-+ and reply
      |                                              |
      |                    2. 200 OK (CCMP response) |
      |<---------------------------------------------|
      |                                              |
      |--+ Parse response and                        |
      |  | update local copy                         |
      |<-+ of conference object                      |
      |                                              |
      '                                              '
      '                                              '

Figure 1: CCMP on HTTPS

図1：HTTPS上のCCMP

Per the protocol dump in the following lines, the CMCC has issued a CCMP request (a blueprintRequest message asking for a blueprint retrieval, i.e., with the <operation> element set to "retrieve" ) towards the ConfS. The request has been carried as payload of an HTTPS POST (message 1.) towards a previously known location. The mandatory Host header has been specified, and the Content-Type header has been correctly set as well ("application/ccmp+xml").

次の行のプロトコルダンプごとに、CMCCは、会議通話数に向かって（「取得」に設定<動作>要素で、すなわち青写真検索を要求blueprintRequestメッセージ）CCMP要求を発行しました。要求は、以前から知られている位置に向かってHTTPS POST（メッセージ1）のペイロードとして搬送されてきました。（「アプリケーション/ CCMP + XML」）は必須のホストヘッダーが指定されている、とContent-Typeヘッダが正しくも設定されています。

The ConfS, in turn, has handled the request and replied accordingly. The response (a blueprintResponse message with a <response-code> set to a successful value, "200") has been carried as payload of a 200 OK HTTPS response (message 2.). As before, the Content-Type header has been correctly set ("application/ccmp+xml").

会議通話数は、順番に、要求を処理し、それに応じて答えました。応答（成功した値が、「200」に設定し、<レスポンスコード>とblueprintResponseメッセージ）が200 OK HTTPS応答（メッセージ2）のペイロードとして搬送されてきました。前と同じように、Content-Typeヘッダが正しく（ "アプリケーション/ CCMP + XML"）に設定されています。

1. CMCC -> ConfS (HTTPS POST, CCMP request)
------------------------------------------
   POST /Xcon/Ccmp HTTP/1.1
   Content-Length: 657
   Content-Type: application/ccmp+xml
   Host: example.com:443
   Connection: Keep-Alive
   User-Agent: Apache-HttpClient/4.0.1 (java 1.5)

2. CMCC <- ConfS (200 to POST, CCMP response)
---------------------------------------------
   HTTP/1.1 200 OK
   X-Powered-By: Servlet/2.5
   Server: Sun GlassFish Communications Server 1.5
   Content-Type: application/ccmp+xml;charset=ISO-8859-1
   Content-Length: 1652
   Date: Thu, 04 Feb 2010 14:47:56 GMT

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-blueprint-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:AudioRoom@example.com</confObjID> <operation>retrieve</operation> <response-code>200</response-code> <response-string>success</response-string> <ccmp:blueprintResponse> <blueprintInfo entity="xcon:AudioRoom@example.com"> <info:conference-description> <info:display-text>AudioRoom</info:display-text> <info:maximum-user-count>2</info:maximum-user-count> <info:available-media> <info:entry label="audioLabel"> <info:type>audio</info:type> </info:entry> </info:available-media> </info:conference-description> <info:users> <xcon:join-handling>allow</xcon:join-handling>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-情報" のxmlns：インフォ= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP = "壷：IETF：のparams：XML：NS：XCON：CCMP"> <ccmpResponseののxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-青写真応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> [XCON AudioRoom @ example.com </ confObjID> <操作>取得</操作> <レスポンスコード> 200 </レスポンスコード> <レスポンス文字列>成功</レスポンス文字列> <CCMP：blueprintResponse> <blueprintInfo実体= "XCON ：AudioRoom@example.com "> <情報：会議-記述> <情報：表示テキスト> AudioRoom </情報：表示テキスト> <情報：最大ユーザー数> 2 </情報：最大ユーザー数> <情報：使用可能なメディア> <情報：エントリラベル= "audioLabel"> <情報：タイプ>オーディオ</情報：タイプ> </情報：エントリ> </情報：利用可能メディア> </情報：conference-記述> <情報：ユーザー> <XCON：参加ハンドリング> </ XCON許可：参加ハンドリング>

</info:users> <xcon:floor-information> <xcon:floor-request-handling>confirm </xcon:floor-request-handling> <xcon:conference-floor-policy> <xcon:floor id="audioLabel"></xcon:floor> </xcon:conference-floor-policy> </xcon:floor-information> </blueprintInfo> </ccmp:blueprintResponse> </ccmpResponse> </ccmp:ccmpResponse>

</情報：ユーザー> <XCON：床-情報> <XCON：床リクエストハンドリング>確認</ XCON：床リクエストハンドリング> <XCON：会議階ポリシー> <XCON：フロアID = "audioLabel 「> </ XCON：床> </ XCON：会議階ポリシー> </ XCON：床情報> </ blueprintInfo> </ CCMP：blueprintResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

For completeness, the following provides some details of the CCMP interaction. Despite the simplicity of the request, this flow provides some relevant information on how CCMP messages are built. Specifically, both the CCMP request and the CCMP response share a subset of the message:

完全を期すため、以下はCCMP相互作用のいくつかの詳細を提供します。リクエストの単純さにもかかわらず、このフローは、CCMPメッセージが構築されている方法についていくつかの関連情報を提供します。具体的には、CCMP要求及びCCMP応答の両方が、メッセージのサブセットを共有します。

o <confUserID>: this element, provided by the CMCC, refers to the requester by means of his XCON-USERID; except in a few scenarios (presented in the following sections), this element must always contain a valid value;

O <confUserID>：CMCCによって提供され、この要素は、彼のXCON-USERIDによってリクエスタを指します。（次のセクションで説明）いくつかのシナリオを除いて、この要素は常に有効な値が含まれている必要があります。

o <confObjID>: this element refers to the target conference object, according to the request in place;

O <confObjID>：この要素は、代わりに、要求に応じて、目標会議オブジェクトを指します。

o <operation>: this element specifies the operation the CMCC wants to perform, according to the specific request type.

O <操作>：この要素は、特定の要求の種類に応じて、CMCCは実行したい操作を指定します。

Besides those elements, the CMCC (let's say Alice, whose XCON-USERID is "xcon-userid:Alice@example.com") has also provided an additional element, <blueprintRequest>. The name of that element varies according to the request type in which the CMCC is interested. In this specific scenario, the CMCC was interested in acquiring details concerning a specific blueprint (identified by its XCON-URI "xcon:AudioRoom@example.com", as reflected in the provided <confObjID> target element), and so the request consisted in an empty <blueprintRequest> element. It will be clearer in the following sections that different request types may require different elements and, as a consequence, different content.

<blueprintRequest>、追加的な要素をも提供している。これらの要素のほかに、CMCCは（のがそのXCON-USERID「Alice@example.comはXCON-ユーザID」でアリスを、としましょう）。その要素の名前は、CMCCが興味を持っている要求の種類に応じて変化します。などの要求が単位：この特定のシナリオでは、CMCCは、特定の青写真に関する詳細を取得するに興味を持っていた（設けられた<confObjID>ターゲット要素に反映されるように、そのXCON-URI「AudioRoom@example.com XCON」によって識別されます）空の<blueprintRequest>要素インチこれは、異なる要求タイプが異なる要素と、結果として、異なるコンテンツを必要とし得ることを、以下の節で明確にされます。

Considering the request was a blueprintRequest message, the ConfS has replied with a blueprintResponse message containing a <blueprintResponse> element. This element includes a complete dump of the conference object (compliant with the data model) describing the requested blueprint.

blueprintRequestメッセージが要求をした考慮し、会議通話数は、<blueprintResponse>要素を含むblueprintResponseメッセージで返信してきました。この要素は、要求された青写真を記述する（データモデルに準拠）会議オブジェクトの完全なダンプが含まれています。

Without providing additional details of this interaction, it is worth noting that this was the example of the simplest CCMP communication that could take place between a CMCC and a ConfS, a blueprint request: this scenario will be described in more detail in Section 5.2.

この相互作用のさらなる詳細を提供することなく、これはCMCCと会議通話数との間で起こり得る最も簡単なCCMP通信、青写真要求の例だったことは注目に値する：このシナリオでは、5.2節でより詳細に説明します。

4.3. Conference Notifications

4.3. 会議の通知

The XCON framework [RFC5239] identifies several different possible protocol interactions between a conference server and a conferencing client. One of those interactions is generically called "notification protocol" providing a mechanism for all clients interested in being informed by the server whenever something relevant happens in a conference. When SIP is used as the call signaling protocol in a CCMP implementation, the XCON event package [RFC6502], which extends the SIP event package for conference state [RFC4575] must be supported. A SIP client uses the SIP SUBSCRIBE message for the XCON event package to subscribe to notifications related to a specific conference. A SIP client would receive notifications describing all the changes to the document via a SIP NOTIFY message. An example ladder diagram is presented in Figure 2; in this figure, we assume a CMCC has updated a conference object, and a previously subscribed SIP client is notified of the update.

XCONフレームワーク[RFC5239]は、会議サーバと会議クライアントとの間のいくつかの異なる可能なプロトコル相互作用を識別する。これらの相互作用の一つは、一般的に、関連する何かが会議中に起こるたび、サーバによって通知されることに興味のすべてのクライアントのためのメカニズムを提供する「通知プロトコル」と呼ばれています。 SIPは、CCMP実装においてプロトコルシグナリングコールとして使用する場合、会議の状態のためのSIPイベント・パッケージを拡張XCONイベントパッケージ[RFC6502]、[RFC4575]はサポートされなければなりません。 SIPクライアントはSIPが特定の会議に関連した通知をサブスクライブしXCONイベントパッケージのSUBSCRIBEメッセージを使用しています。 SIPクライアントはSIP NOTIFYメッセージを経由して、ドキュメントへのすべての変更を記述した通知を受け取ることになります。例えばラダー図を図2に示されています。この図では、我々はCMCCは、会議オブジェクトを更新したと仮定して、以前に加入SIPクライアントは、更新が通知されます。

       CMCC                   ConfS                        UAC
        |                       |                           |
        |                       |          1. SIP SUBSCRIBE |
        |                       |<--------------------------|
        |             Handle +--|                           |
        |                new |  |                           |
        |       subscription +->| 2. SIP 200 OK             |
        |                       |-------------------------->|
        |                       |                           |
        '                       '                           '
        '                       '                           '
        |                       |                           |
        | 3. CCMP (add user)    |                           |
        |---------------------->|                           |
        |                       |--+ Add user               |
        |                       |  | to conf.               |
        |                       |<-+ object                 |
        |     4. CCMP (success) |                           |
        |<----------------------|                           |
        |                       | 5. SIP NOTIFY (changes)   |
        |                       |-------------------------->|
        |                       |             6. SIP 200 OK |
        |                       |<--------------------------|
        |                       |                           |
        '                       '                           '
        '                       '                           '

Figure 2: XCON Event Package: SIP Notifications

図2：XCONイベントパッケージ：SIP通知

The detailed flows in this document generically present a notification, when appropriate, but do not include the SIP messaging details.

このドキュメントの詳細な流れを総称存在通知は、適切な、しかし、SIPメッセージの詳細が含まれていません。

5. Conference Creation

5.会議の作成

This section provides details associated with the various ways in which a conference can be created using CCMP and the XCON framework constructs. As previously mentioned, the details of the media control, call signaling, and floor control protocols, where applicable, are annotated in the flows without showing all the details. This also applies to CCMP, whose flows are related to the protocol alone, hiding any detail concerning the transport that may have been used (e.g., HTTPS). However, for clarification purposes, the first example in Section 5.1 provides the details of the media control messaging with the standard annotation used throughout the remainder of this document. In subsequent flows, only this annotation (identified by lowercase letters) is included, and the reader is encouraged to refer to the call flows in the relevant documents for details about the other protocols. The annotations for the call signaling are on the left side of the conference server vertical bar, and those for the media control messaging are on the right side.

このセクションでは、会議がCCMPとXCONフレームワーク構築物を使用して作成することができる様々な方法に関連した詳細を提供します。先に述べたように、メディア制御、コールシグナリング、およびフロア制御プロトコル、適用可能な場合の詳細は、すべての詳細を示すことなく流れに注釈されています。これはまた、（例えば、HTTPS）を使用されている可能性があり移送に関する任意の詳細を隠し、その流れのみプロトコルに関連しているCCMP、に適用されます。しかしながら、明確化のために、5.1節の最初の例は、この文書の残りの部分の全体にわたって使用される標準的な注釈付きメディア制御メッセージの詳細を提供します。その後の流れは、（小文字で識別される）のみ注釈が含まれており、読者は他のプロトコルの詳細については、関連文書におけるコールフローを参照することが推奨されます。コールシグナリングのための注釈には、会議サーバ垂直バーの左側にある、とメディア制御メッセージングのためのものは右側にあります。

5.1. Basic Conference Creation

5.1. 基本的な会議の作成

The simplest manner in which a conference can be created is accomplished by the client sending a confRequest message with the <operation> element set to "create" as the only parameter to the conference server, together with the <confUserID> associated with the requesting client itself. This results in the creation of a default conference, with an XCON-URI in the form of the <confObjID> element, the XCON-USERID in the form of the <confUserID> element (the same one already present in the request), and the data for the conference object in the <confInfo> parameter all returned in the confResponse message. This example also adds the issuing user to the conference upon creation with the 'method' attribute in the <target> child element of <allowed-users-list> set to "dial-out".

会議を作成することができる最も簡単な方法は、一緒に、会議サーバへの唯一のパラメータとして「作成」に設定<動作>要素とconfRequestメッセージを送信するクライアントによって達成される<confUserID>要求側クライアントに関連付けられています自体。これは、<confObjID>要素、<confUserID>要素の形でXCON-USERID（要求中に既に存在するものと同じもの）の形態でXCON-URIと、デフォルトの会議の生成をもたらす、及び<confInfo>パラメータでの会議オブジェクトのデータは、すべてのconfResponseメッセージで返さ。また、この例では、「ダイヤルアウト」に設定し、<許可ユーザーリスト>の<対象>の子要素で「メソッド」属性に作成時に会議に発行ユーザーを追加します。

The specific data for the conference object is returned in the confResponse message in the <confInfo> parameter. This allows the client (with the appropriate authorization) to manipulate these data and add additional participants to the conference, as well as change the data during the conference. In addition, the client may distribute the conferencing information to other participants allowing them to join, the details of which are provided in additional flows. Please notice that, according to the CCMP specification, the return of the new conference data in the <confInfo> element is not mandatory: if the <confInfo> parameter of is not included in the successful confResponse/create message, a subsequent confRequest/retrieve message of the returned <confObjID> can be triggered to provide the requesting client with the detailed conference description.

会議オブジェクトの特定のデータが<confInfo>パラメータでconfResponseメッセージで返されます。これは、（適切な権限を持つ）クライアントは、これらのデータを操作し、会議に追加の参加者を追加するだけでなく、会議中にデータを変更することができます。また、クライアントは、彼らが参加することができ、他の参加者に会議情報を配信する、の詳細が追加フローで提供されていることがあります。 CCMPの仕様に応じて、以下のことを注意してください、<confInfo>要素の新しい会議データのリターンは必須ではありません：成功confResponseには含まれていないの<confInfo>パラメータは/メッセージを作成した場合、その後のconfRequestが/取得します返さ<confObjID>のメッセージは、詳細な会議の説明を要求しているクライアントを提供するために、トリガすることができます。

Clients that are not XCON-aware can join the conference using a specific signaling interface such as SIP [RFC3261] (using the signaling interface to the conference focus as described in [RFC4579]), or other supported signaling protocols, being XCON-agnostic with respect to them. However, these details are not shown in the message flows. The message flows in this document identify the point in the message flows at which this signaling occurs via the lowercase letter items (i.e., (a)...(x)) along with the appropriate text for the processing done by the conference server.

XCON-認識していないクライアントを有するXCONに依存しないこと、SIPなどの特定のシグナリング・インタフェース[RFC3261]（[RFC4579]に記載されているように、会議フォーカスにシグナリング・インタフェースを使用して）、または他のサポートされているシグナリングプロトコルを使用して会議に参加することができそれらに関して。しかし、これらの詳細は、メッセージ・フローには表示されません。メッセージは、この文書に流れるメッセージ内のポイントを識別するこのシグナリングは、会議サーバによって行われる処理のために適切なテキストと共に小文字項目（すなわち、（A）...（x））を介して起こる流れます。

As previously described, this example also shows how the conferencing system may make use of other standard protocol components for complete functionality. An example of that is the media control framework [RFC5567], which allows the conferencing system to configure conference mixes, Interactive Voice Response (IVR) dialogs, and all sorts of media-related interactions an application like this may need. In order to provide the reader with some insight on these interactions, the conference server in this example also configures and starts a mixer via a media control channel as soon as the conference is created (transactions A1 and A2), and attaches clients to it when necessary (e.g., when CMCC1 joins the conference by means of SIP signaling, its media channels are attached to the media server (MS) in B1/B2). Note, that the media control interfaces are NOT shown in the remaining call flows in this document but rather follow the same annotation as with the SIP signaling such that (b) correlates with the A1 and A2 transactions and (d) correlates with the B1 and B2 transactions.

前述のように、この例では、会議システムは、完全な機能のための他の標準的なプロトコルコンポーネントを利用することができる方法を示しています。その一例は、会議システムは、対話型音声応答（IVR）ダイアログ、及びこのようなアプリケーションが必要とするメディア関連の相互作用のあらゆる会議ミックスを設定することを可能にするメディア制御フレームワーク[RFC5567]です。これらの相互作用に関するいくつかの洞察を読者に提供するために、この例では、会議サーバも設定し、できるだけ早く会議（A1とA2トランザクション）に作成されるように、メディア制御チャネルを介してミキサを開始し、その際にクライアントをアタッチ必要（CMCC1は、SIPシグナリングによって会議に参加するとき、例えば、そのメディアチャネルがB1 / B2にメディアサーバ（MS）に取り付けられています）。メディア制御インターフェースが残りの呼び出しに示されていないことに留意されたいが、この文書に流れるむしろSIP（b）は、A1とA2のトランザクションと相関し、（d）はB1と相関するようなシグナリングと同じ注釈に従うとB2取引。

   CMCC1          CMCC2        CMCCx       ConfS          MS
     |               |           |           |             |
     |(1)confRequest(confUserID, create)     |             |
     |-------------------------------------->|             |
     |               |         (a)Create +---|             |
     |               |           |Conf   |   |             |
     |               |           |Object |   |             |
     |               |           |& IDs  +-->|             |
     |               |           |           | A1. CONTROL |
     |               |           |           |+++++++++++>>|
     |               |           |           |(create conf)|--+ (b)
     |               |           |           |             |  | create
     |               |           |           |             |  | conf and
     |               |           |           | A2. 200 OK  |<-+ its ID
     |               |           |           |<<+++++++++++|
     |               |           |           |(confid=Y)   |
     |(2)confResponse(confUserID,confObjID,  |             |
     |                create, 200, success,  |             |
     |                version, confInfo)     |             |
     |<--------------------------------------|             |
     |               |           |           |             |
     |               |     (c) Focus     +---|             |
     |               |         sets up   |   |             |
     |               |         signaling |   |             |
     |               |         to CMCC1  +-->|             |
     |               |           |           |             |
     |               |           |           | B1. CONTROL |
     |               |           |           |+++++++++++>>|
     |               |           |           | (join CMCC1 |
     |               |           |           | <->confY)   |
     |               |           |           |             |
     |               |           |           |             |--+(d) join
     |               |           |           |             |  | CMCC1 &
     |               |           |           | B2.200 OK   |<-+ conf Y
     |               |           |           |<<+++++++++++|
     |               |           |           |             |
     |<<#################################################>>|
     |        Now the CMCC1 is mixed in the conference     |
     |<<#################################################>>|
     |               |           |           |             |
     |******CMCC1 may then manipulate conference data *****|
     |****** and add addt'l users, etc.      |        *****|
     '               '           '           '             '
     '               '           '           '             '
     '               '           '           '             '

Figure 3: Create Basic Conference - Complete flow

図3：基本的な会議を作成します - 完全な流れ

1. confRequest/create message (Alice creates a default conference)

1. confRequest /（アリスは、デフォルトの会議を作成します）メッセージを作成

2. confResponse/create message ("success", created conference object returned)

2. confResponse /メッセージを作成する（「成功」は、作成した会議オブジェクトが返されます）

</info:entry> </info:conf-uris> <info:maximum-user-count>10 </info:maximum-user-count> <info:available-media> <info:entry label="11"> <info:type>audio</info:type> </info:entry> </info:available-media> </info:conference-description> <info:conference-state> <info:active>false</info:active> </info:conference-state> <info:users> <xcon:join-handling>allow</xcon:join-handling> <xcon:allowed-users-list> <xcon:target uri="xcon-userid:Alice@example.com" method="dial-out"/> </xcon:allowed-users-list> </info:users> </confInfo> </ccmp:confResponse> </ccmpResponse> </ccmp:ccmpResponse>

</情報：エントリ> </情報：CONF-のURI> <情報：最大ユーザー数> 10 </情報：最大ユーザー数> <情報：使用可能なメディア> <情報：エントリラベル= "11" > <情報：タイプ>オーディオ</情報：タイプ> </情報：エントリ> </情報：利用可能メディア> </情報：会議-記述> <情報：会議状態> <情報：<アクティブ>偽/詳細：> <アクティブ/情報：会議状態> <情報：ユーザー> <XCON：参加ハンドリング>許可</ XCON：参加ハンドリング> <XCON：許可ユーザー・リスト> <[XCONターゲットURI = "XCON -userid：Alice@example.com」メソッド= "ダイヤルアウト" /> </ XCON：許可ユーザー・リスト> </情報：ユーザー> </ confInfo> </ CCMP：confResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 4: Create Basic Conference Detailed Messaging

図4：基本的な会議の詳細なメッセージを作成します。

5.2. Conference Creation Using Blueprints

5.2. 青写真を使用して会議の作成

The previous example showed the creation of a new conference using default values. This means the client provided no information about how she wanted the conference to be created. The XCON framework (and CCMP as a consequence) allows for the implementation of templates. These templates are called "conference blueprints" and are basically conference objects with predefined settings. This means that a client might get a list of blueprints, choose the one that most fits his needs, and use the chosen blueprint to create a new conference.

前の例では、デフォルト値を使用して、新しい会議の作成を示しました。これにより、クライアントは、彼女が作成する会議を望んでいたかについての情報を提供しないことを意味します。（結果として及びCCMP）XCONフレームワークは、テンプレートの実装を可能にします。これらのテンプレートは、「会議の青写真」と呼ばれ、基本的には事前に定義された設定を使用してオブジェクトを会議しています。これは、クライアントが、青写真のリストを取得し、最も自分のニーズに合ったものを選択して、新しい会議を作成するために選ばれた青写真を使用する場合がありますことを意味します。

Figure 5 provides an example of one client, Alice, discovering the conference blueprints available for a particular conferencing system and creating a conference based on the desired blueprint. In particular, Alice is interested in those blueprints suitable to represent a video conference, i.e., a conference in which both audio and video are available, so she makes use of the filter mechanism provided by CCMP to make a selective blueprints retrieve request. This results in three distinct CCMP transactions.

図5は、特定の会議システムに利用可能な会議の青写真を発見し、所望の設計図に基づいて会議を作成し、一つのクライアント、アリスの例を提供します。具体的には、アリスは、ビデオ会議、オーディオとビデオの両方が利用可能である、すなわち、会議を表すのに適したもの青写真に興味があるので、彼女は、選択青写真が要求を取得するためにCCMPが提供するフィルタ機構を利用します。これは、3つの異なるCCMP取引になります。

   CMCC Alice                   ConfS
    |                               |
    | (1) blueprintsRequest         |
    |    (confUserID,xpathFilter)   |
    |------------------------------>|
    |                               |
    |        (2) blueprintsResponse |
    |           (confUserID,        |
    |            200, success,      |
    |            blueprintsInfo)    |
    |                               |
    |<------------------------------|
    |                               |
    |--+                            |
    |  | choose preferred           |
    |  | blueprint from the         |
    |  | list (blueprintName)       |
    |<-+                            |
    |                               |
    | (3) blueprintRequest          |
    | (confUserID,confObjID,        |
    |  retrieve)                    |
    |------------------------------>|
    |                               |
    |      4) blueprintResponse     |
    |         (confUserID,confObjID,|
    |          retrieve, 200,       |
    |          success, confInfo)   |
    |<------------------------------|
    |                               |
    | (5) confRequest(confUserID,   |
    |     confObjID,create)         |
    |------------------------------>|
    |                               |
    |                 (a)Create +---|
    |                    Conf   |   |
    |                    Object |   |
    |                    & IDs  +-->|
    |                               |--+ (b) MS
    |                               |  | creates
    |                               |  | conf and
    |                               |<-+ its ID
    |                               |   (confid=Y)
    |(6) confResponse               |
    | (confUserID, confObjID*,      |
    |  create, 200, success)        |
    |<------------------------------|
    |                               |

| | | | ' ' ' '

｜｜｜｜ ’ ’ ’ ’

Figure 5: Client Creation of Conference Using Blueprints

図5：青写真を使用して会議のクライアントの作成

1. Alice first sends a blueprintsRequest message to the conference server identified by the conference server discovery process. This request contains the <confUserID> set to the XCON-USERID of the user issuing the request (in this case, the one belonging to Alice) and the <xpathFilter> element by which Alice specifies she desires to obtain only blueprints providing support for both audio and video: for this purpose, the xpath query contained in this field is: "/conference-info[conference-description/ available-media/entry/type='audio' and conference-description/ available-media/entry/type='video']". Upon receipt of the blueprintsRequest message, the conference server would first ensure, on the basis of the <confUserID> parameter, that Alice has the appropriate authority based on system policies to receive the requested kind of blueprints supported by that system.

1.アリスは最初の会議サーバの検出プロセスによって識別される会議サーバにblueprintsRequestメッセージを送信します。この要求は、<confUserID>（この場合、アリスに属する1）要求を発行したユーザとアリスは、彼女は両方のためのサポートを提供するだけ青写真を得ることを望む指定することによって、<としてXPathFilter>要素のXCON-USERIDに設定が含まれていますオーディオとビデオ：この目的のために、この分野に含まれているXPathクエリは次のとおりです。「/会議-情報[会議-説明/利用可能メディア/項目/タイプ= 『オーディオ』と会議-説明/利用可能メディア/項目/タイプ= '動画']」。 blueprintsRequestメッセージを受信すると、会議サーバは、最初に、アリスがそのシステムでサポートされている設計図の要求された種類を受信するためのシステムポリシーに基づいて、適切な権限を持っていることを、<confUserID>パラメータに基づいて、確実にするでしょう。

2. All blueprints that Alice is authorized to use are returned in a blueprintsResponse message in the <blueprintsInfo> element.

アリスが使用を許可されている2.すべての青写真は、<blueprintsInfo>要素でblueprintsResponseメッセージで返されます。

3. Upon receipt of the blueprintsResponse message containing the blueprints, Alice determines which blueprint to use for the conference to be created. Alice sends a blueprintRequest message to get the specific blueprint as identified by the <confObjID>.

青写真を含むblueprintsResponseメッセージを受信3.アリスは、会議を作成するために使用する青写真を判定する。アリスは<confObjID>によって識別される特定の青写真を取得するためにblueprintRequestメッセージを送信します。

4. The conference server returns the details associated with the specific blueprint identified by the <confObjID> in the <confInfo> element within the blueprintResponse message.

前記会議サーバはblueprintResponseメッセージ内の<confInfo>要素の<confObjID>によって識別される特定の青写真に関連付けられた詳細情報を返します。

5. Alice finally sends a confRequest message with a "create" <operation> to the conference server to create a conference reservation cloning the chosen blueprint. This is achieved by writing the blueprint's XCON-URI in the <confObjID> parameter.

5.アリスは最終的に選ばれた青写真をクローニング会議予約を作成するために、会議サーバに「作成」<操作>とconfRequestメッセージを送信します。これは、<confObjID>パラメータで青写真のXCON-URIを記述することによって達成されます。

6. Upon receipt of the confRequest/create message, the conference server uses the received blueprint to clone a conference, allocating a new XCON-URI (called "confObjID*" in the example). The conference server then sends a confResponse message including the new "confObjID*" associated with the newly created conference instance as the value of the <confObjID> parameter. Upon receipt of the confResponse message, Alice can now add other users to the conference.

confRequestを受信する6 /メッセージを作成し、会議サーバは、新しいXCON-URI（この例では「confObjID *」と呼ばれる）を割り当て、会議をクローニングするために、受信した青写真を使用します。会議サーバは、<confObjID>パラメータの値として、新しく作成された会議のインスタンスに関連付けられた新しい「confObjID *」を含むconfResponseメッセージを送信します。 confResponseメッセージを受信すると、アリスは今会議に他のユーザーを追加することができます。

1. blueprintsRequest message (Alice requires the list of the available blueprints with video support)

1. blueprintsRequestメッセージ（アリスがビデオサポートで利用可能な青写真のリストが必要です）

2. blueprintsResponse message (the server provides a descriptions of the available blueprints fitting Alice's request)

2. blueprintsResponseメッセージ（サーバは、アリスのリクエストを適合利用可能な設計図の説明を提供します）

<info:uri>xcon:VideoConference1@example.com</info:uri> <info:display-text>VideoConference1</info:display-text> <info:purpose>Public Video Conference: conference where both audio and video are available, only one user can talk </info:purpose> </info:entry> </blueprintsInfo> </ccmp:blueprintsResponse> </ccmpResponse> </ccmp:ccmpResponse>

<情報：URI> [XCON VideoConference1@example.com </情報：URI> <情報：表示テキスト> VideoConference1 </情報：表示テキスト> <情報：目的>公共ビデオ会議：オーディオとビデオの両方がある会議利用できる、唯一のユーザーが話をすることができます。</情報：目的> </情報：エントリ> </ blueprintsInfo> </ CCMP：blueprintsResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

3. blueprintRequest/retrieve message (Alice wants the "VideoRoom" blueprint)

3. blueprintRequest /（アリスは「VideoRoom」青写真を望んでいる）のメッセージを検索

4. blueprintResponse/retrieve message ("VideoRoom" conference object returned)

4. blueprintResponse /メッセージを取得する（ "VideoRoom" 会議オブジェクトが返されます）

<info:maximum-user-count>4</info:maximum-user-count> <info:available-media> <info:entry label="audioLabel"> <info:type>audio</info:type> </info:entry> <info:entry label="videoLabel"> <info:type>video</info:type> </info:entry> </info:available-media> </info:conference-description> <info:users> <xcon:join-handling>allow</xcon:join-handling> </info:users> <xcon:floor-information> <xcon:floor-request-handling>confirm </xcon:floor-request-handling> <xcon:conference-floor-policy> <xcon:floor id="audioFloor"> <xcon:media-label>audioLabel</xcon:media-label> </xcon:floor> <xcon:floor id="videoFloor"> <xcon:media-label>videoLabel</xcon:media-label> </xcon:floor> </xcon:conference-floor-policy> </xcon:floor-information> </blueprintInfo> </ccmp:blueprintResponse> </ccmpResponse> </ccmp:ccmpResponse>

<情報：最大ユーザー数> 4 </情報：最大ユーザー数> <情報：使用可能なメディア> <情報：エントリラベル=「audioLabel」> <情報：タイプ>オーディオ</情報：タイプ> < /情報：エントリ> <情報：エントリラベル= "videoLabel"> <情報：タイプ>ビデオ</情報：タイプ> </情報：エントリ> </情報：利用可能メディア> </情報：会議記述> <情報：ユーザー> <XCON：参加ハンドリング> </ XCON許可：参加ハンドリング> </情報：ユーザー> <XCON：床-情報> <XCON：床リクエストハンドリング>確認</ XCON：フロア要求-handling> <XCON：会議階ポリシー> <XCON：床のid = "audioFloor"> <XCON：メディアラベル> audioLabel </ XCON：メディアラベル> </ XCON：床> <XCON：フロアID = "videoFloor"> <XCON：メディアラベル> videoLabel </ XCON：メディアラベル> </ XCON：床> </ XCON：会議階ポリシー> </ XCON：床情報> </ blueprintInfo> </ CCMP：blueprintResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

5. confRequest/create message (Alice clones the "VideoRoom" blueprint)

5. confRequest /メッセージを作成（アリスクローン「VideoRoom」青写真）

6. confResponse/create message (cloned conference object returned)

6. confResponse /メッセージを作成する（クローニングされた会議オブジェクトが返されます）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-conf-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>create</operation> <response-code>200</response-code> <response-string>success</response-string> <version>1</version> <ccmp:confResponse> <confInfo entity="xcon:8977794@example.com"> <info:conference-description> <info:display-text> New conference by Alice cloned from VideoRoom </info:display-text> <info:conf-uris> <info:entry> <info:uri> xcon:8977794@example.com </info:uri> <info:display-text> conference xcon-uri </info:display-text> <xcon:conference-password> 8601 </xcon:conference-password> </info:entry> </info:conf-uris> <info:maximum-user-count>10</info:maximum-user-count> <info:available-media> <info:entry label="11"> <info:type>audio</info:type> </info:entry> <info:entry label="12"> <info:type>video</info:type> </info:entry> </info:available-media> </info:conference-description> <info:users> <xcon:join-handling>allow</xcon:join-handling>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-情報" のxmlns：インフォ= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP = "壷：IETF：のparams：XML：NS：XCON：CCMP"> <ccmpResponseののxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-CONF-応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8977794 @ example.com </ confObjID> <操作> </操作> <レスポンスコード> 200 </レスポンスコード> <レスポンス文字列>成功</レスポンス文字列> <バージョン> 1 </バージョン> <CCMPを作成します。 confResponse> <confInfo実体= "XCON：8977794@example.com"> <情報：会議-記述> <情報：表示テキスト>アリスによる新しい会議がVideoRoomからクローニング</情報：表示テキスト> <情報：conf- URI> <情報：エントリ> <情報：URI> [XCON 8977794@example.com </情報：URI> <情報：表示テキスト>会議XCON-URI </情報：表示テキスト> <XCON：会議パスワード> 8601 </ XCON：会議パスワード> </情報：エントリ> </情報：CONF-のURI> <情報：M aximum-ユーザー数> 10 </情報：最大ユーザー数> <情報：使用可能なメディア> <情報：エントリラベル= "11"> <情報：タイプ>オーディオ</情報：タイプ> </情報：エントリ> <情報：エントリラベル= "12"> <情報：タイプ>ビデオ</情報：タイプ> </情報：エントリ> </情報：利用可能メディア> </情報：会議-記述が> <情報：ユーザー> <XCON：参加ハンドリング> </ XCON許可：参加ハンドリング>

</info:users> <xcon:floor-information> <xcon:floor-request-handling> confirm</xcon:floor-request-handling> <xcon:conference-floor-policy> <xcon:floor id="1"> <xcon:media-label>11</xcon:media-label> </xcon:floor> <xcon:floor id="2"> <xcon:media-label>12</xcon:media-label> </xcon:floor> </xcon:conference-floor-policy> </xcon:floor-information> </confInfo> </ccmp:confResponse> </ccmpResponse> </ccmp:ccmpResponse>

</情報：ユーザー> <XCON：床-情報> <XCON：床リクエストハンドリング>確認</ XCON：床リクエストハンドリング> <XCON：会議階ポリシー> <XCON：床のid = "1 "> <XCON：メディアラベル> 11 </ XCON：メディアラベル> </ XCON：フロア> <XCON：フロアID =" 2" > <XCON：メディアラベル> 12 </ XCON：メディアラベル> </ XCON：床> </ XCON：会議階ポリシー> </ XCON：床情報> </ confInfo> </ CCMP：confResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 6: Create Conference (Blueprint) Detailed Messaging

図6は、：会議（青写真）の詳細なメッセージを作成します。

5.3. Conference Creation Using User-Provided Conference Information

5.3. ユーザー提供の会議情報を使用して会議の作成

A conference can also be created by the client sending a confRequest message with the "create" <operation>, along with the desired data in the form of the <confInfo> element for the conference to be created. The request also includes the <confUserID> set to the XCON-USERID of the requesting entity.

会議はまた、会議を作成するための<confInfo>要素の形で所望のデータと共に、「作成」<動作>とconfRequestメッセージを送信するクライアントによって作成することができます。要求は、要求側エンティティのXCON-USERIDに<confUserID>セットを含みます。

This approach allows for a client (in this example Alice) to completely describe what the conference object should look like, without relying on defaults or blueprints; for example, which media should be available, the topic, the users allowed to join, any scheduling-related information, and so on. This can be done by providing, in the creation request, a full conference object for the server to parse.

このアプローチは完全に会議オブジェクトは、デフォルトまたは青写真に頼ることなく、どのように見えるかを記述するためのクライアント（この例では、アリス）が可能になります。例えば、メディアが利用可能であるべき、トピックは、ユーザーがように、すべてのスケジューリング関連情報を参加させ、。これは、作成要求に、サーバーの完全な会議オブジェクトは、解析するために、提供することによって行うことができます。

This <confInfo> parameter must comply with the data model specification. This means that the 'entity' attribute is mandatory and cannot be missing in the document. However, in this example, the client is actually requesting the creation of a new conference, which doesn't exist yet, so the 'entity' attribute is unknown. As discussed in Section 4.1, CCMP allows for the use of a wildcard placeholder. This placeholder ("xcon:AUTO_GENERATE_1@example.com" in the example) is only to ensure the <confInfo> element is compliant with the data model and would subsequently be replaced by the conference server with the actual value. Thus, when the conference server actually creates the conference, a valid value for the 'entity' attribute is created for it as well, which takes the place of the wildcard value when the actual conference object provided by the client is populated.

この<confInfo>パラメータは、データモデルの仕様に準拠しなければなりません。これは、「エンティティの属性は必須であり、文書に不足していることができないことを意味します。しかし、この例では、クライアントは、実際にはまだ存在しない新しい会議の作成を要求しているので、「エンティティの属性は不明です。セクション4.1で議論するように、CCMPは、ワイルドカードプレースホルダの使用を可能にします。このプレースホルダ（「XCON：AUTO_GENERATE_1@example.com」例では）<confInfo>要素は、データモデルに準拠して、その後実際の値との会議サーバによって置き換えられる確実にするだけです。会議サーバは、実際に会議を作成するときにこのように、「エンティティの属性の有効な値は、クライアントによって提供される実際の会議オブジェクトが移入されたときにワイルドカード値の行われる、同様にそれのために作成されます。

To give a flavor of what could be added to the conference object, we assume Alice is also interested in providing scheduling-related information. So, in this example, Alice also specifies by the <conference-time> element included in the <confInfo> that the conference she wants to create has to occur on a certain date spanning from a certain start time to a certain stop time and has to be replicated weekly.

会議オブジェクトに追加することができるものの味を与えるために、私たちは、アリスはまた、スケジューリング関連情報の提供に興味を持っていると仮定します。したがって、この例では、アリスはまた彼女が作りたい会議は、特定の停止時間に一定の開始時刻から及ぶ特定の日付に発生することがあり、持っていること<confInfo>に含ま<会議-時間>要素で指定します毎週複製します。

Moreover, Alice indicates by means of the <allowed-users-list> element that at the start time Bob, Carol, and herself have to be called by the conferencing system to join the conference (in fact, for each <target> field corresponding to one of the aforementioned clients, the 'method' attribute is set to "dial-out").

また、アリスは、開始時に、ボブ、キャロル、および自身が各<対象>フィールド対応するため、実際に会議に（参加する会議システムによって呼び出されなければならないこと<許可ユーザリスト>要素によって示し上記のクライアントのいずれかに、「メソッド」属性は、「ダイヤルアウト」するために）設定されています。

Once Alice has prepared the <confInfo> element and sent it as part of her request to the server, if the conferencing system can support that specific type of conference (capabilities, etc.), then the request results in the creation of a conference. We assume the request has been successful, and as a consequence, the XCON-URI in the form of the <confObjID> parameter and the XCON-USERID in the form of the <confUserID> parameter (again, the same as the requesting entity) are returned in the confResponse message.

アリスは<confInfo>要素を作成し、サーバーへの彼女の要求の一部として、それを送信した後は会議システムは、会議の特定のタイプ（能力、など）をサポートできる場合、その要求は、会議の作成になります。私たちは、リクエストが成功したと仮定し、そして結果として、<confObjID>パラメータの形でXCON-URIと<confUserID>パラメータの形でXCON-USERID（再び、要求しているエンティティと同じ） confResponseメッセージで返されます。

In this example, the created conference object is not returned in the successful confResponse message in the <confInfo> parameter. Nevertheless, Alice could still retrieve the actual conference object by issuing a confRequest message with a "retrieve" <operation> on the XCON-URI returned in the <confObjID> of the previous response. Such a request would show how, as described at the beginning of this section, the 'entity' attribute of the conference object in the <confInfo> field is replaced with the actual information (i.e., "xcon:6845432@example.com").

この例では、作成した会議オブジェクトは、<confInfo>パラメータで成功confResponseメッセージで返されません。それにもかかわらず、アリスはまだXCON-URIに「取得」<操作>とconfRequestメッセージを発行することにより、実際の会議オブジェクトを取得でき<confObjID>前の応答の中で返されます。このような要求は、このセクションの冒頭で説明したように、<confInfo>フィールド内の会議オブジェクトの「実体」属性が実際の情報に置き換えられている方法を示します（つまり、「XCON：6845432@example.com」）。

   Alice            Bob        Carol       ConfS
     |               |           |           |
     |               |           |           |
     |(1)confRequest(confUserID, |           |
     |         create, confInfo) |           |
     |               |           |           |
     |-------------------------------------->|
     |               |           |           |
     |               |         (a)Create +---|
     |               |           |Conf   |   |
     |               |           |Object |   |
     |               |           |& IDs  +-->|
     |               |           |           |--+ (b) MS
     |               |           |           |  | creates
     |               |           |           |  | conf and
     |               |           |           |<-+ its ID
     |               |           |           |   (confid=Y)
     |(2)confResponse(confUserID,|           |
     |       confObjID, create,  |           |
     |       200, success, version)          |
     |<--------------------------------------|
     |               |           |           |
    ===========================================
    ...             ...         ...         ...
    ========== START TIME OCCURS ==============
     |               |     (c) Focus     +---|
     |               |         sets up   |   |
     |               |         signaling |   |
     |               |         to Alice  +-->|
     |               |           |           |
     |               |           |           |--+(d) MS joins
     |               |           |           |  | Alice &
     |               |           |           |<-+ conf Y
     |               |           |           |
     |               |           |           |
     |<<###################################>>|
     | Alice is mixed in the conference      |
     |<<###################################>>|
     |               |           |           |
     |               |     (e)Focus      +---|
     |               |        sets up    |   |
     |               |        signaling  |   |
     |               |        to Bob     |   |
     |               |           |       +-->|
     |               |           |           |
     |               |           |           |--+(f)MS joins
     |               |           |           |  | Bob &
     |               |           |           |<-+ conf Y

     |               |           |           |
     |               |<<###################>>|
     |               |  Bob is mixed too     |
     |               |<<###################>>|
     |               |           |           |
     |               |     (g )Focus     +---|
     |               |         sets up   |   |
     |               |         signaling |   |
     |               |         to Carol  |   |
     |               |         CMCCx     +-->|
     |               |           |           |
     |               |           |           |--+(h)MS joins
     |               |           |           |  | CMCCx &
     |               |           |           |<-+ conf Y
     |               |           |           |
     |               |           |<<#######>>|
     |               |           |Carol mixed|
     |               |           |<<#######>>|
     |               |           |           |
     |               |           |           |
     |               |           |           |
     |<***All parties connected to conf Y***>|
     |               |           |           |
     |               |           |           |
     '               '           '           '
     '               '           '           '
     '               '           '           '

Figure 7: Create Basic Conference from User-Provided Conference Info

図7：ユーザー提供のコンファレンス情報から基本的な会議を作成します。

1. confRequest/create message (Alice proposes a conference object to be created)

1. confRequest /メッセージを作成する（アリスは、会議オブジェクトを作成することを提案しています）

                  </info:display-text>
                   <info:maximum-user-count>10</info:maximum-user-count>
                   <info:available-media>
                          <info:entry label="AUTO_GENERATE_2">
                              <info:type>audio</info:type>
                          </info:entry>
                   </info:available-media>
                   <xcon:conference-time>
                    <xcon:entry>
                     <xcon:base>
                       BEGIN:VCALENDAR
                       VERSION:2.0
                       PRODID:-//Mozilla.org/NONSGML
                                 Mozilla Calendar V1.0//EN
                       BEGIN:VEVENT
                       DTSTAMP: 20100127T140728Z
                       UID: 20100127T140728Z-345FDA-alice@example.com
                       ORGANIZER:MAILTO:alice@example.com
                       DTSTART:20100127T143000Z
                       RRULE:FREQ=WEEKLY
                       DTEND: 20100127T163000Z
                       END:VEVENT
                       END:VCALENDAR
                     </xcon:base>
                     <xcon:mixing-start-offset
                      required-participant="moderator">
                          2010-01-27T14:29:00Z
                     </xcon:mixing-start-offset>
                     <xcon:mixing-end-offset
                      required-participant="participant">
                          2010-01-27T16:31:00Z
                     </xcon:mixing-end-offset>
                     <xcon:must-join-before-offset>
                          2010-01-27T15:30:00Z
                     </xcon:must-join-before-offset>
                    </xcon:entry>
                   </xcon:conference-time>
               </info:conference-description>
               <info:users>
                  <xcon:join-handling>allow</xcon:join-handling>
                  <xcon:allowed-users-list>
                     <xcon:target uri="xcon-userid:alice@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:bob83@example.com"
                                   method="dial-out"/>
                     <xcon:target uri="sip:carol@example.com"
                                   method="dial-out"/>
                   </xcon:allowed-users-list>

</info:users> </confInfo> </ccmp:confRequest> </ccmpRequest> </ccmp:ccmpRequest>

</情報：ユーザー> </ confInfo> </ CCMP：confRequest> </ ccmpRequest> </ CCMP：ccmpRequest>

2. confResponse/create message ("200", "success")

2. confResponse /メッセージを作成する（ "200"、 "成功"）

Figure 8: Create Basic Conference Detailed Messaging

図8：基本的な会議の詳細なメッセージを作成します。

5.4. Cloning an Existing Conference

5.4. 既存の会議のクローニング

A client can also create another conference by cloning an existing conference, such as an active conference or conference reservation. This approach can be seen as a logical extension of the creation of a new conference using a blueprint: the difference is that, instead of cloning the predefined settings listed in a blueprint, the settings of an existing conference would be cloned.

また、クライアントは、このようなアクティブな会議や会議予約などの既存の会議を、クローニングすることにより、別の会議を作成することができます。このアプローチは、青写真を使用して、新しい会議の作成の論理的拡張とみなすことができる：差ではなく設計図に記載されている定義済みの設定をクローニングする、既存の会議の設定がクローン化されるであろう、ということです。

In this example, the client sends a confRequest message with the "create" <operation>, along with her XCON-USERID in the <confUserID> element and the XCON-URI of the conference from which a new conference is to be cloned in the <confObjID> element.

この例では、クライアントが新しい会議がでクローン化しようとするから、<confUserID>要素と会議のXCON-URIの彼女XCON-USERIDとともに、「作成」<操作>とconfRequestメッセージを送信します<confObjID>要素。

An example of how a client can create a conference based on a blueprint is provided in Section 5.2. The manner by which a client in this example might learn about a conference reservation or active conferences is similar to the first step in the blueprint example, with the exception of querying for different types of conference objects supported by the specific conferencing system. For instance, in this example, the client clones a conference reservation (i.e., an inactive conference).

クライアントは、設計図に基づいて会議を作成する方法の例は、セクション5.2で提供されています。この例では、クライアントは、会議予約やアクティブな会議を学ぶかもしれれる方法は、特定の会議システムでサポートされている会議の異なるタイプのオブジェクトをクエリを除いて、青写真の例の最初のステップと同様です。例えば、この例では、クライアントは、会議予約（即ち、非アクティブ会議）を複製し。

If the conferencing system can support a new instance of the specific type of conference (capabilities, etc.), then the request results in the creation of a conference, with an XCON-URI in the form of a new value in the <confObjID> parameter to reflect the newly cloned conference object returned in the confResponse message.

会議システムは、新しい値の形でXCON-URIと会議（機能、等）、会議の作成におけるその要求の結果、特定のタイプの新しいインスタンスをサポートすることができる場合、<confObjID> confResponseメッセージで返さ新しくクローニングされた会議オブジェクトを反映するパラメータ。

   Alice                          ConfS
    |                               |
    |(1)confRequest(confUserID,     |
    |       confObjID, create)      |
    |------------------------------>|
    |                 (a)Create +---|
    |                    Conf   |   |
    |                    Object |   |
    |                    & IDs  +-->|
    |                               |--+ (b) MS
    |                               |  | creates
    |                               |  | conf and
    |                               |<-+ its ID
    |                               |   (confid=Y)
    |                               |
    |(2)confResponse(confUserID,    |
    |      confObjID*,create,       |
    |      200, success,            |
    |      version, confInfo)       |
    |                               |
    |<------------------------------|
    |                               |
    '                               '

Figure 9: Create Basic Conference - Clone

図9：基本的な会議を作成 - クローン

1. Alice, a conferencing system client, sends a confRequest message to clone a conference based on an existing conference reservation. Alice indicates this conference should be cloned from the specified parent conference represented by the XCON-URI in the <confObjID> provided in the request.

1.アリス、会議システムのクライアントは、既存の会議予約に基づいて会議をクローニングするconfRequestメッセージを送信します。アリスは、この会議が<confObjID>要求に設けにXCON-URIによって表される指定された親会議からクローン化されるべきであることを示します。

2. Upon receipt of the confRequest message containing a "create" <operation> and the aforementioned XCON-URI in the <confObjID>, the conference server ensures that such received XCON-URI is valid. The conference server determines the appropriate read/ write access of any users to be added to a conference based on this XCON-URI (using membership, roles, etc.). The conference server uses the received <confObjID> to clone a conference reservation. The conference server also reserves or allocates a new XCON-URI (called "confObjID*" in Figure 9) to be used for the cloned conference object. This new identifier is, of course, different from the one associated with the conference to be cloned, since it represents a different conference object. Any subsequent protocol requests from any of the members of the conference must use this new identifier. The conference server maintains the mapping between this conference ID and the parent conference object ID associated with the reservation through the conference instance, and this mapping is explicitly addressed through the <cloning-parent> element of the <conference-description> in the new conference object.

「作成」<動作>を含むconfRequestメッセージを受信すると2とで前述XCON-URI <confObjID>、会議サーバは、受信XCON-URIが有効であることを確実にします。会議サーバは、任意のユーザの適切な読み取り/書き込みアクセスが（等メンバーシップ、ロールを使用して）このXCON-URIに基づいて、会議に追加することを決定します。会議サーバは、会議予約のクローンを作成するために、<confObjID>、受信を使用しています。会議サーバはまた、留保またはクローニングされた会議の目的のために使用される（図9の「confObjID *」と呼ばれる）新しいXCON-URIを割り当てます。この新たな識別子は、もちろん、それは異なる会議オブジェクトを表すので、クローン化される会議に関連付けられたものとは異なります。会議のメンバーのいずれかから、それ以降のプロトコルの要求は、この新しい識別子を使用する必要があります。会議サーバは、この会議ID、会議インスタンスを介して予約に関連付けられている親会議オブジェクトIDの間のマッピングを維持し、このマッピングは、明示的に新しい会議における<会議記述>の<クローニング親>要素を介してアドレス指定されますオブジェクト。

1. confRequest/create message (Alice clones an existing conference)

1. confRequest /メッセージを作成する（アリスのクローン既存の会議）

2. confResponse/create message (created conference object returned)

2. confResponse /メッセージを作成します（作成した会議オブジェクトが返されます）

<ccmp:confResponse> <confInfo entity="xcon:8977794@example.com"> <info:conference-description> <info:display-text> New conference by Alice cloned from 6845432 </info:display-text> <info:maximum-user-count>10</info:maximum-user-count> <info:available-media> <info:entry label="11"> <info:type>audio</info:type> </info:entry> </info:available-media> <xcon:cloning-parent> xcon:6845432@example.com </xcon:cloning-parent> </info:conference-description> <info:users> <xcon:join-handling>allow</xcon:join-handling> <xcon:allowed-users-list> <xcon:target uri="sip:alice@example.com" method="dial-out"/> <xcon:target uri="sip:bob83@example.com" method="dial-out"/> <xcon:target uri="sip:carol@example.com" method="dial-out"/> </xcon:allowed-users-list> </info:users> <xcon:floor-information> <xcon:floor-request-handling> confirm</xcon:floor-request-handling> <xcon:conference-floor-policy> <xcon:floor id="1"> <xcon:media-label>11</xcon:media-label> </xcon:floor> </xcon:conference-floor-policy> </xcon:floor-information> </confInfo> </ccmp:confResponse> </ccmpResponse> </ccmp:ccmpResponse>

<CCMP：confResponse> <confInfo実体= "XCON：8977794@example.com"> <情報：会議-説明>：<：表示テキスト/インフォメーション> <情報<表示テキストインフォメーション>アリスによる新しい会議が6845432からクローニング：最大ユーザー数> 10 </情報：最大ユーザー数> <情報：使用可能なメディア> <情報：エントリラベル=「11」> <情報：タイプ>オーディオ</情報：タイプ> </情報：エントリ> </情報：利用可能メディア> <XCON：クローニング親> [XCON 6845432@example.com </ XCON：クローニング親> </情報：会議-記述> <情報：ユーザー> <XCONは：参加します-handling>許可</ XCON：参加ハンドリング> <XCON：許可ユーザー・リスト> <[XCONターゲットURI = "SIP：alice@example.com" メソッド= "ダイヤルアウト" /> <XCON：ターゲットURI = "SIP：bob83@example.com" メソッド= "ダイヤルアウト" /> <XCON：ターゲットURI = "SIP：carol@example.com" メソッド= "ダイヤルアウト" /> </ XCON：許可ユーザー-list> </情報：ユーザー> <XCON：床-情報> <XCON：床リクエストハンドリング>確認</ XCON：床リクエストハンドリング> <XCON：会議階ポリシー> <XCON：フロアID = "1"> <XCON：メディアラベル> 11 </ XCON：メディアラベル> </ XCON：床> </ XCON：会議階ポリシー> </ XCON：floo R-情報> </ confInfo> </ CCMP：confResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 10: Create Basic Conference (Clone) Detailed Messaging

図10：基本会議（クローン）の詳細なメッセージを作成します。

6. Conference Users Scenarios and Examples

6.会議ユーザーシナリオと例

Section 5 showed examples describing the several different ways a conference might be created using CCMP. This section focuses on user-related scenarios, i.e., typical scenarios that may occur during the lifetime of a conference, like adding new users and handling their media. The following scenarios are based on those documented in the XCON framework. The examples assume that a conference has already been correctly established, with media, if applicable, per one of the examples in Section 5.

第5節では、会議がCCMPを使用して作成される可能性がありますいくつかの異なる方法を記述した例を示しました。このセクションでは、ユーザーに関連するシナリオ、新しいユーザーを追加し、そのメディアを扱うように、会議の存続期間中に発生する可能性があり、すなわち、一般的なシナリオに焦点を当てています。次のシナリオはXCONフレームワークで文書に基づくもの。例が該当する場合、会議がすでに正常に第5節で例の一つにつき、メディアで、確立されたことを前提としています。

6.1. Adding a Party

6.1. パーティーを追加します

In this example, Alice wants to add Bob to an established conference. In the following example we assume Bob is a new user of the system, which means Alice also needs to provide some details about him. In fact, the case of Bob already present as a user in the conferencing system is much easier to address, and will be discussed later.

この例では、アリスは、確立された会議にボブを追加したいです。次の例では、ボブがアリスがまた彼についていくつかの詳細を提供する必要がある意味システムの新しいユーザーであると仮定します。実際には、会議システムにおけるユーザーとして既に存在しているボブの場合は、対処する方がはるかに簡単です、そして後述します。

    Alice          Bob
    CMCC1          CMCC2       CMCCx       ConfS
     |               |           |           |
     |(1) userRequest(confUserID,|           |
     |    confObjID, create,     |           |
     |    userInfo)  |           |           |
     |-------------------------------------->|
     |               |           |           |
     |               |        (a) Create +---|
     |               |           | Bob   |   |
     |               |           | as a  |   |
     |               |           | user  +-->|
     |               |           |           |
     |(2) userResponse(confUserID, confObjID |
     |      create, 200, success, userInfo)  |
     |<--------------------------------------|
     |               |           |           |
     |               |           | (b) Focus |
     |               |           |   sets up |
     |               |           | signaling |
     |               |           |    to Bob |
     |               |<----------------------|
     |               |           |           |
     |               |           | (c) Notify|
     |               |           | ("Bob just|
     |               |           |  joined") |
     |               |           |<----------|
     |               |           |           |
     '               '           '           '
     '               '           '           '
     '               '           '           '

Figure 11: Client Manipulation of Conference - Add a Party

図11：会議のクライアントの操作 - パーティーを追加

1. Alice sends a userRequest message with an operation of "create" to add Bob to the specific conference as identified by the XCON-URI in the <confObjID>. The "create" <operation> also makes sure that Bob is created as a user in the whole conferencing system. This is done by adding in the request a <userInfo> element describing Bob as a user. This is needed in order to let the conferencing system be aware of Bob's characteristics. In case Bob was already a registered user, Alice would just have referenced him through his XCON-USERID in the 'entity' attribute of the <userInfo> field, without providing additional data. In fact, that data (including, for instance, Bob's SIP-URI to be used subsequently for dial-out) would be obtained by referencing the extant registration. The conference server ensures that Alice has the appropriate authority based on the policies associated with that specific conference object to perform the operation. As mentioned before, a new XCON-USERID is created for Bob, and the <userInfo> is used to update the conference object accordingly. As already seen in Section 5.3, a placeholder wildcard ("xcon-userid:AUTO_GENERATE_1@example.com" in the CCMP messages below) is used for the 'entity' attribute of the <userInfo> element, to be replaced by the actual XCON-USERID later;

1.アリスは<confObjID>にXCON-URIによって識別される特定の会議にボブを追加するために、「作成」の操作とuserRequestメッセージを送信します。「作成」<操作>はまた、ボブは全体会議システムにおけるユーザーとして作成されていることを確認します。これは、要求にユーザとしてボブを説明<ユーザー情報>要素を追加することによって行われます。これは会議システムは、ボブの特性を認識してもらうために必要とされています。ボブがすでに登録済みのユーザーだった場合、アリスは、単に追加のデータを提供することなく、<のUserInfo>フィールドの「実体」属性の彼XCON-USERIDを通じて彼を参照しているだろう。実際には、データ（例えば含むが、ボブのSIP-URIがダイヤルアウトするために続いて使用される）ことが現存登録を参照することによって得られるであろう。会議サーバは、アリスが操作を実行するために、その特定の会議オブジェクトに関連付けられたポリシーに基づいて適切な権限を持っていることを保証します。前に述べたように、新しいXCON-USERIDは、ボブのために作成され、<のUserInfo>に応じて会議オブジェクトを更新するために使用されます。既にセクション5.3に見られるように、プレースホルダのワイルドカード（「XCON-ユーザーID：AUTO_GENERATE_1@example.com」以下CCMPメッセージでは）実際のXCONによって置換される、<ユーザー情報>要素の「エンティティ」属性のために使用されます後で-userid;

2. Bob is successfully added to the conference object, and an XCON-USERID is allocated for him ("xcon-userid:Bob@example.com"); this identifier is reported in the response as the value of the 'entity' attribute of the returned <userInfo>;

2.ボブが正常に会議オブジェクトに追加され、XCON-USERIDは彼のために割り当てられている（「XCON-ユーザーID：Bob@example.com」）;この識別子は返さ<USERINFO>の「実体」属性の値として応答で報告されました。

3. In the presented example, the call signaling to add Bob to the conference is instigated through the focus as well. As noted previously, this is implementation specific. In fact, a conferencing system may accomplish different actions after the user creation, just as it may do nothing at all. Among the possible actions, for instance, Bob may be added as a <target> element to the <allowed-users-list> element, whose joining 'method' may be either "dial-in" or "dial-out". Besides, out-of-band notification mechanisms may be involved as well, e.g., to notify Bob via mail of the new conference, including details as the date, password, expected participants, and so on (see Section 4.3).

3.提示された例では、会議にボブを追加するコールシグナリングは同様に焦点を通して扇動されます。先に述べたように、これは実装固有のものです。実際には、会議システムは、それがすべてで何もしないことと同じように、ユーザーの作成した後に異なるアクションを達成することができます。可能なアクションの中でも、例えば、ボブは接合「メソッド」「インダイヤル」または「ダイヤルアウト」のいずれであってもよい。<許可ユーザリスト>要素に、<target>に要素として添加してもよいです。また、アウト・オブ・バンド通知メカニズムは、日付などの詳細、パスワード、予想の参加者など（4.3節を参照）を含めた新しい会議のメールボブに通知するために、例えば、同様に関与している可能性があります。

Once Bob has been successfully added to the specified conference, per updates to the state, and depending upon the policies, other participants (including Bob himself) may be notified of the addition of Bob to the conference via the conference notification service in use.

ボブは、正常な状態への更新ごとに、指定された会議に追加されている、との方針によっては、（ボブ本人を含む）他の参加者は、使用中の会議通知サービスを介して会議にボブの追加を通知することができる。いったん

1. userRequest/create message (Alice adds Bob)

1. userRequest /メッセージを作成する（アリスはボブが追加されます）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-request-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977878@example.com</confObjID> <operation>create</operation> <ccmp:userRequest> <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com"> <info:display-text>Bob</info:display-text> <info:associated-aors> <info:entry> <info:uri>mailto:bob.depippis@example.com</info:uri> <info:display-text>Bob's email</info:display-text> </info:entry> </info:associated-aors> <info:endpoint entity="sip:bob83@example.com"> <info:display-text>Bob's laptop</info:display-text> </info:endpoint> </userInfo> </ccmp:userRequest> </ccmpRequest> </ccmp:ccmpRequest>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpRequestののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpRequestのxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-ユーザ要求メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8977878 @ example.com </ confObjID> <操作>作成</操作> <CCMP：userRequest> <のUserInfo実体= "XCON-ユーザーID：AUTO_GENERATE_1@example.com"> <情報：表示テキスト>ボブ</情報：ディスプレイ - テキスト> <情報：関連する-のAOR> <情報：エントリ> <情報：URI>のmailto：bob.depippis@example.com </情報：URI> <情報：表示テキスト>ボブのメール</情報：表示テキスト> </情報：エントリ> </情報：関連する-のAOR> <情報：エンドポイント実体= "一口：bob83@example.com"> <情報：表示テキスト>ボブのラップトップ</情報：表示テキスト> </情報：エンドポイント> </ USERINFO> </ CCMP：userRequest> </ ccmpRequest> </ CCMP：ccmpRequest>

2. userResponse/create message (a new XCON-USERID is created for Bob and he is added to the conference)

2. userResponse /メッセージを作成する（新しいXCON-USERIDがボブのために作成され、彼は会議に追加されます）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977878@example.com</confObjID> <operation>create</operation> <response-code>200</response-code> <response-string>success</response-string> <version>10</version> <ccmp:userResponse> <userInfo entity="xcon-userid:Bob@example.com"> <info:display-text>Bob</info:display-text> <info:associated-aors> <info:entry>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpResponseののxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-ユーザ応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8977878 @ example.com </ confObjID> <操作>作成</操作> <レスポンスコード> 200 </レスポンスコード> <レスポンス文字列>成功</レスポンス文字列> <バージョン> 10 </バージョン> <CCMP： userResponse> <ユーザ情報エンティティ= "XCON-ユーザーID：Bob@example.com"> <情報：表示テキスト>ボブ</情報：表示テキスト> <情報：関連する-のAOR> <情報：エントリ>

<info:uri>mailto:bob.depippis@example.com</info:uri> <info:display-text>Bob's email</info:display-text> </info:entry> </info:associated-aors> <info:endpoint entity="sip:bob83@example.com"> <info:display-text>Bob's laptop</info:display-text> </info:endpoint> </userInfo> </ccmp:userResponse> </ccmpResponse> </ccmp:ccmpResponse>

<情報：URI>のmailto：bob.depippis@example.com </情報：URI> <情報：表示テキスト>ボブのメール</情報：表示テキスト> </情報：エントリ> </情報：関連する-のAOR > <情報：エンドポイント実体= "一口：bob83@example.com"> <情報：表示テキスト>ボブのラップトップ</情報：表示テキスト> </情報：エンドポイント> </ USERINFO> </ CCMP：userResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 12: Add Party Message Details

図12：党メッセージの詳細を追加します。

6.2. Muting a Party

6.2. パーティーをミュート

This section provides an example of the muting of a party in an active conference. We assume that the user to mute has already been added to the conference. The document only addresses muting and not unmuting, since the latter would involve an almost identical CCMP message flow anyway. However, if any external floor control is involved, whether a particular conferencing client can actually mute/ unmute itself must be considered by the conferencing system.

このセクションでは、アクティブな会議で党のミュートの例を提供します。私たちは、ユーザーが既に会議に追加されているミュートすることを前提としています。文書は後者のみがほぼ同じCCMPメッセージがとにかく流れ伴うだろうから、者のミュートおよびミュート解除されていないアドレス。しかし、任意の外部のフロア制御は、特定の会議クライアントが実際にミュート/ミュート解除自体をできるかどうか、関係している場合は、会議システムによって考慮されなければなりません。

Please notice that interaction between CCMP and floor control should be carefully considered. In fact, handling CCMP- and BFCP-based media control has to be considered as multiple layers: that is, a participant may have the BFCP floor granted, but be muted by means of CCMP. If so, he would still be muted in the conference, and would only be unmuted if both the protocols allowed for this.

CCMPとフロア制御の間の相互作用を慎重に考慮しなければならないことに注意してください。つまり、参加者がBFCPフロアが許可されていますが、CCMPによってミュートさ：実際には、CCMP-とBFCPベースのメディアコントロールを処理することは、複数の層として考慮しなければなりません。もしそうなら、彼はまだ会議にミュートされるだろう、とプロトコルの両方が、このために許可されている場合のみ、ミュートになります。

Figure 13 provides an example of one client, Alice, impacting the media state of another client, Bob. This example assumes an established conference. In this example, Alice, who is the moderator of the conference, wants to mute Bob on a medium-sized 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. BFCP floor control is assumed not to be involved.

図13は、別のクライアント、ボブのメディア状態に影響を与え、一つのクライアント、アリスの例を提供します。この例では、確立された会議を前提としています。彼のデバイスがミュートされていないとして、この例では、会議の司会者であるアリスは、中型マルチパーティ会議にボブをミュートしたい（そして、彼は明らかにコールを聞いていない）と彼のオフィスでバックグラウンドノイズ環境は、会議に破壊的です。 BFCPフロア制御が関与していないと想定されます。

Muting can be accomplished using the <mute> control element associated with the target user's audio, in which case the conference server must update the settings associated with the user's media streams. Muting/unmuting can also be accomplished by directly modifying the settings related to the target user's media streams, which is the approach shown in this example. Specifically, Bob's <userInfo> is updated by modifying the <endpoint> element in the

ミューティングは、会議サーバは、ユーザのメディア・ストリームに関連付けられた設定を更新する必要があり、その場合、ターゲットユーザのオーディオ、関連付けられた<ミュート>制御要素を用いて達成することができます。ミュート/ミュート解除はまた、この例に示されているアプローチである、直接ターゲットユーザのメディア・ストリームに関連する設定を変更することによって達成することができます。具体的には、ボブのは、<のUserInfo>に<エンドポイント>要素を変更することによって更新されます

<media> part related to audio information, identified by the 'id' attribute. The modification consists in setting the audio <status> to "recvonly", in case of muting.

<メディア>「ID」属性によって識別された音声情報に関連する部分。変更は、ミュートの場合には、「recvonlyで」にオーディオ<状態>の設定で構成されています。

    Alice          Bob
    CMCC1          CMCC2       CMCCx        ConfS                MS
     |               |           |            |                  |
     |(1) userRequest(subject,   |            |                  |
     |    confUserID,confObjID,  |            |                  |
     |    update,userInfo)       |            |                  |
     |               |           |            |                  |
     |--------------------------------------->|                  |
     |               |           |            | Mute Bob         |
     |               |           |            |----------------->|
     |               |           |            |           200 OK |
     |               |           |            |<-----------------|
     |               |           |            |                  |
     |               |<====== XXX Bob excluded from mix XXX ====>|
     |               |           |            |                  |
     |               |         (a) Update +---|                  |
     |               |             Bob in |   |                  |
     |               |         data model |   |                  |
     |               |            (muted) +-->|                  |
     |               |           |            |                  |
     | (2)userResponse(confUserID,confObjID,  |                  |
     |           update,200,success,version)  |                  |
     |<---------------------------------------|                  |
     |               |           |            |                  |
     |               |           | (b) Notify |                  |
     |               |           |   ("Bob is |                  |
     |               |           |    muted") |                  |
     |               |           |<-----------|                  |
     |               |           |            |                  |
     '               '           '            '                  '
     '               '           '            '                  '
     '               '           '            '                  '

Figure 13: Client Manipulation of Conference - Mute a Party

図13：会議のクライアントの操作 - パーティーミュート

1. Alice sends a userRequest message with an "update" <operation> and the <userInfo> with the <status> field in the <media> element for Bob's <endpoint> set to "revconly". In order to authenticate herself, Alice provides in the <subject> request parameter her registration credentials (i.e., username and password). The <subject> parameter is an optional one: its use can be systematic whenever the conference server envisages to authenticate each requester. In such cases, if the client does not provide the required authentication information, the conferencing server answers with a CCMP "authenticationRequired" <response-code>, indicating that the request cannot be processed without including the proper <subject> parameter. The conference server ensures that Alice has the appropriate authority based on the policies associated with that specific conference object to perform the operation. It recognizes that Alice is allowed to request the specified modification, since she is moderator of the target conference, and updates the <userInfo> in the conference object reflecting that Bob's media is not to be mixed with the conference media. If the conference server relies on a remote media server for its multimedia functionality, it subsequently changes Bob's media profile accordingly by means of the related protocol interaction with the MS. An example describing a possible way of dealing with such a situation using the media server control architecture [RFC5567] is described in Figure 31, "Simple Bridging: Framework Transactions (2)", in [CALL-FLOWS].

1.アリスはボブの<終点>「revconly」に設定のための<メディア>要素に<状態>フィールドで「更新」<操作>と<のUserInfo>とuserRequestメッセージを送信します。自分自身を認証するために、アリスは、<対象>リクエストパラメータに彼女の登録資格（つまり、ユーザ名とパスワード）を提供します。 <対象>パラメータはオプションです：会議サーバは、各要求者を認証するために想定したときに、その使用は、体系的なことができます。このような場合には、クライアントは、要求が適切<対象>パラメータを含めずに処理することができないことを示し、必要な認証情報、CCMP「authenticationRequired」<応答コード>との会議サーバの答えを提供しない場合。会議サーバは、アリスが操作を実行するために、その特定の会議オブジェクトに関連付けられたポリシーに基づいて適切な権限を持っていることを保証します。それは彼女がターゲット会議の司会者であることから、アリスは、指定された修正を要求することが許可されていることを認識し、ボブのメディアが会議メディアと混合されるようにされていないことを反映した会議オブジェクトに<のUserInfo>を更新します。会議サーバは、そのマルチメディア機能のためのリモートメディアサーバーに依存している場合、それはその後、MSとの関連プロトコルの相互作用によって、それに応じて、ボブのメディアプロファイルを変更します。メディアサーバ制御アーキテクチャ[RFC5567]を使用して、このような状況に対処する可能な方法を説明する例が、図31に記載されている：[コールフロー〕で「単純ブリッジフレームワークの取引（2）」。

2. A userResponse message with a "200" <response-code> ("success") is then sent to Alice. Depending upon the policies, the conference server may notify other participants (including Bob) of this update via any conference notification service that may be in use.

「200」<レスポンスコード>（「成功」）2. A userResponseメッセージをアリスに送信されます。ポリシーに応じて、会議サーバが使用されている可能性のある会議通知サービスを介して、このアップデートの（ボブ含む）他の参加者に通知することができます。

1. userRequest/update message (Alice mutes Bob)

1. userRequest /更新メッセージ（アリスがボブをミュート）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpRequest xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-request-message-type"> <subject> <username>Alice83</username> <conference-password>13011983</conference-password> </subject> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977878@example.com</confObjID> <operation>update</operation> <ccmp:userRequest> <userInfo entity="xcon-userid:Bob@example.com"> <info:endpoint entity="sip:bob83@example.com"> <info:media id="1"> <info:label>123</info:label> <info:status>recvonly</info:status> </info:media> </info:endpoint>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpRequestののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpRequestのxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-ユーザ要求メッセージ型"> <サブジェクト> <名> Alice83 </ユーザー名> <会議パスワード> 13011983 </会議パスワード> </被験者> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> [XCON 8977878@example.com </ confObjID> <動作>更新</動作> <CCMP：userRequest> <ユーザ情報エンティティ= "XCON-ユーザーID：Bob@example.com"> <情報：エンドポイント実体= "一口：bob83@example.com"> <情報：メディアID = "1"> <INFO：ラベル> 123 </情報：ラベル> <情報：状態>がrecvonly </情報：状態> </情報：メディア> </情報：エンドポイント>

</userInfo> </ccmp:userRequest> </ccmpRequest> </ccmp:ccmpRequest>

</のUserInfo> </ CCMP：userRequest> </ ccmpRequest> </ CCMP：ccmpRequest>

2. userResponse/update message (Bob has been muted)

2. userResponse /更新メッセージ（ボブがミュートされています）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977878@example.com</confObjID> <operation>update</operation> <response-code>200</response-code> <response-string>success</response-string> <version>7</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpResponseののxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-ユーザ応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8977878 @ example.com </ confObjID> <動作>更新</操作> <レスポンスコード> 200 </レスポンスコード> <応答文字列>成功</応答文字列> <バージョン> 7 </バージョン> <CCMP。 userResponse /> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 14: Mute Message Details

図14：ミュートメッセージ詳細

6.3. Conference Announcements and Recordings

6.3. 会議アナウンスと録音

This section deals with features that are typically required in a conferencing system, such as public announcements (e.g., to notify vocally that a new user joined a conference) and name recording. While this is not strictly CCMP-related (the CCMP signaling is actually the same as the one seen in Section 6.1), it is an interesting scenario to address to see how several components of an XCON-compliant architecture interact with each other to make it happen.

このセクションでは、そのような公共アナウンス（例えば、新しいユーザーが会議に参加することを音声で通知する）と名前記録として、典型的には会議システムで必要とされる機能を扱います。これは厳密にCCMP関連はありませんが、それはXCON準拠アーキテクチャのいくつかのコンポーネントは、それを作るためにどのように相互作用するかを確認するために対処するための興味深いシナリオがある（CCMPシグナリングは、実際には6.1節で見たものと同じです）起こります。

In this example, as shown in Figure 15, Alice is joining Bob's conference that requires that she first enter a passcode. After successfully entering the passcode, an announcement prompts Alice to speak her name so it can be recorded. When Alice is added to the active conference, the recording is played back to all the existing participants. A very similar example is presented in Figure 33 of [CALL-FLOWS].

図15に示すように、この例では、アリスは彼女が最初にパスコードを入力する必要がボブの会議に参加しています。成功したパスコードを入力した後、発表はそれを記録することができますので、アリスは彼女の名前を話すように求められます。アリスは、アクティブな会議に追加されると、記録が既存のすべての参加者に再生されます。非常に類似した例は、[CALL-流れる]の図33に示されています。

   CMCC  Alice                    ConfS                         MS
        |                            |                            |
        |(1)userRequest(confObjID,   |                            |
        |         create,userInfo)   |                            |
        |--------------------------->|                            |
        |                            |--+ Alice is                |
        |                            |  | new in the              |
        |                            |<-+ system (create          |
        |                            |    confUserID)             |
        |           ConfS handles +--|                            |
        |           SIP signaling |  |                            |
        |    (Alice<->ConfS<->MS) +->|                            |
        |                            |                            |
        |                            |--+ A password is           |
        |                            |  | required for            |
        |                            |<-+ that conference         |
        |                            |                            |
        |                            | Request IVR menu (PIN)     |
        |                            |--------------------------->|
        |                            |                            |
        |<========= MS gets PIN from Alice through DTMF =========>|
        |                            |                            |
        |                            |        Provided PIN is...  |
        |                            |<---------------------------|
        |                   Check +--|                            |
        |                     PIN |  |                            |
        |                         +->|                            |
        |                            |--+ Alice must              |
        |                            |  | record her              |
        |                            |<-+ name                    |
        |                            |                            |
        |                            | Request name recording     |
        |                            |--------------------------->|
        |                            |                            |
        |<========= MS records Alice's audio RTP (name) =========>|
        |                            |                            |
        |                            |            Audio recording |
        |                            |<---------------------------|
        |                Complete +--|                            |
        |                creation |  |                            |
        |                of Alice +->|                            |

        |                            |                            |
        |                            |                            |
        | (2)userResponse(confUserID,|                            |
        |       confObjID,create,200,|                            |
        |           success,version) |                            |
        |<---------------------------|                            |
        |                            |                            |
        '                            '                            '

Figure 15: Recording and Announcements

図15：記録とお知らせ

1. Upon receipt of the userRequest message from Alice to be added to Bob's conference, the conference server determines that a password is required for this specific conference. Thus, an announcement asking Alice to enter the password is sent back. This may be achieved by means of typical IVR functionality. Once Alice enters the password, it is validated against the policies associated with Bob's active conference. The conference server then connects to a server that prompts and records Alice's name. The conference server must also determine whether Alice is already a user of this conferencing system or whether she is a new user. In this case, Alice is a new user for this conferencing system, so a new XCON-USERID is created for Alice. Based upon the contact information provided by Alice, the call signaling to add Alice to the conference is instigated through the focus.

ボブの会議に追加するアリスからuserRequestメッセージを受信すると1、会議サーバは、パスワードは、この特定の会議のために必要であると判断します。このように、パスワードを入力するようにアリスを尋ねる発表が送り返されます。これは典型的なIVR機能によって達成することができます。アリスはパスワードを入力したら、それはボブのアクティブな会議に関連付けられたポリシーに照らして検証されます。会議サーバは、要求されますとアリスの名前を記録し、サーバーに接続します。会議サーバはまた、アリスはすでにこの会議システムの利用者であるかどうか、彼女は新しいユーザーであるかどうかを決定しなければなりません。この場合、アリスは、この会議システムのための新しいユーザーであるので、新しいXCON-USERIDはアリスのために作成されます。アリスが提供する連絡先情報に基づいて、会議にアリスを追加するためにコールシグナリングは、フォーカスによって扇動されます。

2. The conference server sends Alice a userResponse message that includes in the <confUserID> the XCON-USERID assigned by the conferencing system to her. This would allow Alice to later perform operations on the conference (if she were to have the appropriate policies), including registering for event notifications associated with the conference. 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.

2.会議サーバは、アリスに彼女に会議システムによって割り当てられた<confUserID> XCON-USERIDに含まuserResponseメッセージを送信します。会議に関連したイベント通知の登録を含め、（彼女は適切なポリシーを持っていた場合）これは、アリスが後で会議上で操作を実行できるようになります。コールシグナリングは、アリスが正常な状態にアップデートごとに、特定の会議に追加されたことを示し、およびポリシーに応じて、他の参加者（例えば、ボブ）は、会議通知サービスを介して会議にアリスの追加が通知されるとそして発表は、アリスは、会議に参加したことを示すすべての参加者に提供されます。

1. userRequest/create message (a new conferencing system client, Alice, enters Bob's conference)

1. userRequest /メッセージを作成する（新しい会議システムのクライアント、アリスは、ボブの会議に入ります）

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpRequestののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP」のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-情報">

<ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-request-message-type"> <confObjID>xcon:bobConf@example.com</confObjID> <operation>create</operation> <ccmp:userRequest> <userInfo entity="xcon-userid:AUTO_GENERATE_1@example.com"> <info:associated-aors> <info:entry> <info:uri> mailto:Alice83@example.com </info:uri> <info:display-text>email</info:display-text> </info:entry> </info:associated-aors> <info:endpoint entity="sip:alice_789@example.com"/> </userInfo> </ccmp:userRequest> </ccmpRequest> </ccmp:ccmpRequest>

<ccmpRequestのxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance" XSI：タイプ= "CCMP：CCMP-ユーザ要求メッセージ型"> <confObjID> [XCON bobConf @例。 COM </ confObjID> <操作> </操作> <CCMP：userRequest>作成<ユーザ情報エンティティ= "XCON-ユーザーID：AUTO_GENERATE_1@example.comを"> <情報：関連する-のAOR> <情報：エントリ> <情報：URI >のmailto：Alice83@example.com </情報：URI> <情報：表示テキスト>電子メール</情報：表示テキスト> </情報：エントリ> </情報：関連する-のAOR> <情報：エンドポイントの実体= "SIP：alice_789@example.com" /> </ USERINFO> </ CCMP：userRequest> </ ccmpRequest> </ CCMP：ccmpRequest>

2. userResponse/create message (Alice provided with a new XCON-USERID and added to the conference)

2. userResponse /メッセージを作成（アリスは、新しいXCON-USERIDを備え、会議に追加しました）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:bobConf@example.com</confObjID> <operation>create</operation> <response-code>200</response-code> <response-string>success</response-string> <version>5</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpResponseののxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-ユーザ応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> [XCON bobConf @ example.com </ confObjID> <操作> </操作> <レスポンスコード> 200 </レスポンスコード> <レスポンス文字列>成功</レスポンス文字列> <バージョン> 5 </バージョン> <CCMPを作成します。 userResponse /> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 16: Announcement Messaging Details

図16：アナウンスメッセージ詳細

6.4. Monitoring for DTMF

6.4. DTMFの監視

Conferencing systems also often need the capability to monitor for dual-tone multi-frequency (DTMF) from each individual participant. This would typically be used to enter the identifier and/or access code for joining a specific conference. This feature is also often exploited to achieve interaction between participants and the conferencing system for non-XCON-aware user agents (e.g., using DTMF tones to get muted/unmuted).

会議システムは、多くの場合、個々の参加者からのデュアルトーン多重周波数（DTMF）を監視する機能を必要としています。これは、典型的には、特定の会議に参加するための識別子および/またはアクセスコードを入力するために使用されるであろう。この機能は、多くの場合、参加者と非XCON対応のユーザーエージェントのための会議システム（例えば、ミュート/ミュート解除を取得するためにDTMFトーンを使用して）の間の相互作用を達成するために利用されます。

An example of DTMF monitoring, within the context of the framework elements, is shown in Figure 15. The media control architecture and protocols [RFC5567] can be used by the conference server for all the DTMF interactions. Examples for DTMF interception in conference instances are presented in [CALL-FLOWS].

DTMFモニタリングの例は、フレームワークエレメントのコンテキスト内で、メディア制御アーキテクチャとプロトコル[RFC5567]は、すべてのDTMF相互作用のための会議サーバによって使用することができ、図15に示されています。会議インスタンスでDTMF傍受のための例は、[CALL-フロー]に提示されています。

6.5. Entering a Password-Protected Conference

6.5. パスワードで保護された会議を入力します

Some conferences may require a password to be provided by a user who wants to manipulate the conference objects (e.g., join, update, delete) via CCMP. In this case, a password would be included in the <conference-password> element in the appropriate <conference-uris> entry of the conference data model. Such password must be then included in the <conference-password> field in the CCMP request addressed to that conference.

いくつかの会議はCCMPを経由して（例えば参加、更新、削除）会議オブジェクトを操作したいユーザが提供するパスワードが必要な場合があります。この場合、パスワードは、会議データモデルの適切な<会議-のURI>エントリ内の<会議パスワード>要素に含まれることになります。このようなパスワードは、その会議に宛てCCMPリクエストに<会議パスワード>フィールドに含まれている必要があります。

In the following example, Alice, a conferencing system client, attempts to join a password-protected conference.

次の例では、アリス、会議システムのクライアントは、パスワードで保護された会議に参加しようとします。

1. Alice sends a userRequest message with a "create" <operation> to add herself in the conference with XCON-URI "xcon:8977777@example.com" (written in the <confObjID> parameter). Alice provides her XCON-USERID via the <confUserID> field of the userRequest message and leaves out the <userInfo> one (first-party join). In this first attempt, she doesn't insert any password parameter.

（<confObjID>パラメータで書かれた）：1.アリスはXCON-URI「8977777@example.com XCON」と会見で自分自身を追加し、「作成」<操作>とuserRequestメッセージを送信します。アリスはuserRequestメッセージの<confUserID>フィールドを経由して、彼女のXCON-USERIDを提供し、（第一当事者が参加）<のUserInfo> 1を残します。この最初の試みでは、彼女は、任意のパスワードパラメータを挿入しません。

2. Upon receipt the userRequest/create message, the conference server detects that the indicated conference is not joinable without providing the appropriate passcode. A userResponse message with a "423" <response-code> ("conference password required") is returned to Alice to indicate that her join has been refused and that she has to resend her request including the appropriate conference password in order to participate.

2.受信するuserRequestは/メッセージを作成し、会議サーバは、指示会議が適切なパスコードを設けることなく、参加可能でないことを検出します。「423」<応答コード>（「必要な会議パスワード」）とuserResponseメッセージを拒否し、彼女が参加するために適切な会議パスワードなど、彼女の要求を再送信しなければならないことをされてきた彼女が参加することを示すためにアリスに返されます。

3. After getting the passcode through out-of-band mechanisms, Alice provides it in the proper <conference-password> request field of a new userRequest/create message and sends the updated request back to the server.

3.アウトオブバンドメカニズムを介してパスコードを取得した後、アリスは、メッセージを作成/新しいuserRequestの適切<会議パスワード>要求フィールドでそれを提供し、バックサーバに更新要求を送信します。

4. The conference server checks the provided password and then adds Alice to the protected conference. After that, a userResponse message with a "200" <response-code> ("success") is sent to Alice.

4.会議サーバは、提供されたパスワードをチェックして、保護された会議にアリスが追加されます。その後、「200」<レスポンスコード>（「成功」）とuserResponseメッセージがアリスに送信されます。

1. userRequest/create message (Alice tries to enter the conference without providing the password)

1. userRequest /（アリスはパスワードを入力せずに会議を入力しようとすると）メッセージを作成

2. userResponse/create message ("423", "conference password required")

2. userResponse /メッセージを作成する（ "423"、 "会議パスワードが必要"）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>create</operation> <response-code>423</response-code> <response-string>conference password required</response-string> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpResponseののxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-ユーザ応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8977794 @ example.com </ confObjID> <操作> </操作> <レスポンスコード> 423 </レスポンスコード> <レスポンス文字列>を作成会議パスワードが必要</レスポンス文字列> <CCMP：userResponse /> </ ccmpResponse > </ CCMP：ccmpResponse>

3. userRequest/create message (Alice provides the password)

3. userRequest /（アリスはパスワードを提供します）メッセージを作成

<ccmp:userRequest/> </ccmpRequest> </ccmp:ccmpRequest>

<CCMP：userRequest /> </ ccmpRequest> </ CCMP：ccmpRequest>

4. userResponse/create message (Alice has been added to the conference)

4. userResponse /（アリスが会議に追加された）メッセージを作成

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>create</operation> <response-code>200</response-code> <response-string>success</response-string> <version>10</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpResponseののxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-ユーザ応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8977794 @ example.com </ confObjID> <操作>作成</操作> <レスポンスコード> 200 </レスポンスコード> <レスポンス文字列>成功</レスポンス文字列> <バージョン> 10 </バージョン> <CCMP： userResponse /> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 17: Password-Protected Conference Join Messages Details

図17：パスワードで保護された会議のメッセージの詳細に参加

7. Sidebars Scenarios and Examples

7.サイドバーのシナリオと例

While creating conferences and manipulating users and their media are sufficient for many scenarios, there may be cases when more complex management is needed.

会議を作成し、ユーザーを操作し、そのメディアは多くのシナリオには十分ですが、より複雑な管理が必要とされるとき、ケースがあるかもしれません。

In fact, a feature typically required in conferencing systems is the ability to create sidebars. A sidebar is basically a child conference that usually includes a subset of the participants of the parent conference and a subset of its media as well. Sidebars are typically required whenever some of the participants in a conference want a private discussion, without interfering with the main conference.

実際には、一般的に会議システムに必要な機能は、サイドバーを作成する機能です。サイドバーは、基本的には通常、親会議の参加者のサブセットと同様にそのメディアのサブセットが含ま子会議です。会議の参加者の一部がメイン会議に干渉することなく、プライベートな議論をしたい時はいつでもサイドバーは、一般的に必要とされています。

This section deals with some typical scenarios using a sidebar, like whispering, private messaging, and coaching scenarios. The first subsections present some examples of how a generic sidebar can be created, configured, and managed.

ささやき、プライベートメッセージング、およびコーチングのシナリオのように、サイドバーを使用して、いくつかの一般的なシナリオとこのセクションで扱っています。最初のサブセクションでは、一般的なサイドバーは、作成、構成、および管理することができる方法のいくつかの例を提示します。

7.1. Internal Sidebar

7.1. 内部サイドバー

Figure 18 provides an example of one client, Alice, involved in an 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 ConfS 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. Besides, Bob decides that he is not interested in still receiving the conference audio in background (not even at a lower volume as Alice configured) and so modifies the sidebar in order to make that stream inactive for him.

図18は、ボブとキャロルとアクティブな会議に関与する1つのクライアント、アリスの例を提供します。アリスはまだメインの会議に関連するビデオを見ながら、ボブとサイドの議論を持っているサイドバーを作成したいと考えています。あるいは、メイン会議からの音声は、減少した体積に維持することができます。アリスは、アクティブな会議のオブジェクトに基づいて会議予約を作成するために、会議通話数にリクエストを送信することにより、サイドバーを開始します。アリスとボブは、内部サイドバーの会議が行われている間に、他の参加者は、メイン会議への参加を認識することができように、メイン会議の名簿に残るでしょう。また、ボブは、彼が（いなくてもアリスが設定されて低い音量で）まだ、バックグラウンドで会議の音声を受信することに関心はないと判断したので、彼のためにそのストリームを非アクティブにするためにサイドバーを変更します。

  Alice                   Bob                    ConfS
    |                      |                       |
    |(1) sidebarByValRequest(confUserID,           |
    |                  confObjID,create)           |
    |--------------------------------------------->|
    |                      |                       |
    |                      |        (a) Create +---|
    |                      |    sidebar-by-val |   |
    |                      |     (new conf obj |   |
    |                      |       cloned from +-->|
    |                      |        confObjID)     | Sidebar now has
    |                      |                       | id confObjID*
    |(2) sidebarByValResponse(confUserID,          | (parent mapping
    |     (confObjID*,create,200,success,          | conf<->sidebar)
    |         version,sidebarByValInfo)            |
    |<---------------------------------------------|
    |                      |                       |
    |(3) sidebarByValRequest                       |
    |       (confUserID, confObjID*,               |
    |       update,sidebarByValInfo)               |
    |--------------------------------------------->|
    |                      |                       |

    |                      |        (b) Update +---|
    |                      |    sidebar-by-val |   |
    |                      |     (media, users |   |
    |                      |       etc.)       +-->|
    |                      |                       | Sidebar is
    |                      |                       | modified
    |(4) sidebarByValResponse(confUserID,          |
    |                 confObjID*, update,          |
    |              200, success, version)          |
    |<---------------------------------------------|
    |                      |                       |
    |                      |(5) userRequest        |
    |                      |      (confUserID',    |
    |                      |       confObjID*,     |
    |                      |       update,userInfo)|
    |                      |---------------------->|
    |                      |                       |
    |                      |        (c) Update +---|
    |                      |     user settings |   |
    |                      |     (Bob's media) |   |
    |                      |                   +-->|
    |                      |                       | Sidebar is modified
    |                      |                       | (original audio
    |                      |                       | inactive for Bob)
    |                      |(6) userResponse       |
    |                      |     (confUserID',     |
    |                      |      confObjID*,      |
    |                      |      update, 200,     |
    |                      |      success,version) |
    |                      |<----------------------|
    |                      |                       |
    '                      '                       '
    '                      '                       '
    '                      '                       '

Figure 18: Client Creation of a Sidebar Conference

図18：サイドバー会議のクライアントの作成

1. Upon receipt of CCMP sidebarByValRequest message to create a new sidebar based upon the conference whose XCON-URI is in the <confObjID> received in the request, the conference server uses such XCON-URI to clone a conference reservation for the sidebar. The sidebar reservation is NOT independent of the active main conference (i.e., parent). The conference server also allocates a new XCON-URI ("confObjID*" in Figure 18) for that sidebar to be used for any subsequent protocol requests from any of the members of the conference. The new XCON-URI is returned in the response message <confObjID> parameter.

そのXCON-URI <confObjID>にある要求で受信した会議に基づいて新たなサイドバーを作成するためのCCMP sidebarByValRequestメッセージを受信すると1、会議サーバは、サイドバーのための会議予約をクローニングするために、このようなXCON-URIを使用します。サイドバー予約がアクティブメイン会議（すなわち、親）の独立していません。会議サーバは、会議のメンバーのいずれかからの任意の後続のプロトコル要求に使用されるそのサイドバーのための新しいXCON-URI（図18における「confObjID *」）を割り当てます。新しいXCON-URIは、応答メッセージ<confObjID>パラメータに返されます。

2. The relationship information is provided in the sidebarByValResponse message, specifically in the <sidebar-parent> element. A dump of the complete representation of the main/parent conference is provided below as well to show how the cloning process for the creation of the sidebar could take place.

前記関係情報は、具体的には、<サイドバー親>要素に、sidebarByValResponseメッセージにおいて提供されます。メイン/親会議の完全な表現のダンプは、サイドバーの作成のためのクローニングプロセスが起こり得るかを示すために、同様の下に設けられています。

3. Upon receipt of the sidebarByValResponse message 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 so that only the two of them appear in the <allowed-users-list> section. Alice also wants both audio and video from the original conference to be available in the sidebar. For what concerns the media belonging to the sidebar itself, Alice wants the audio to be restricted to the participants in the sidebar (that is, Bob and herself). Additionally, Alice manipulates the media values to receive the audio from the main conference at a reduced volume, so that the communication between her and Bob isn't affected. Alice sends a sidebarByValRequest message with an operation of "update" along with the <sidebarByValInfo> containing the aforementioned sidebar modifications.

3.会議を予約するsidebarByValResponseメッセージを受信すると、アリスは今その予約を使用してアクティブな会議を作成したり、既存の予約に基づいて、追加の予約を作成することができます。この例では、アリスはボブがサイドバーに関与することを希望します。それらの2つだけが、<許可ユーザーリスト>セクションに表示されるようにこのように、彼女はメンバーシップを操作します。アリスはまた、元の会議からのオーディオとビデオの両方がサイドバーで利用できるようにしたいと考えています。メディアは、サイドバー自体に属するに関する何のために、アリスは、オーディオがサイドバー（つまり、ボブと自分自身）の参加者に制限されることを望んでいます。また、アリスはボブとの間の通信に影響がないように、減少した容積でメイン会議からの音声を受信するために、メディアの値を操作します。アリスは<sidebarByValInfo>は、上記サイドバーの修飾を含むと共に、「更新」の操作とsidebarByValRequestメッセージを送信します。

4. Upon receipt of the sidebarByValRequest message to update the sidebar reservation, the conference server ensures that Alice has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conference server must also validate the updated information in the reservation, ensuring that a member like Bob is already a user of this conference server. Once the data for the conference identified by the <confObjID> is updated, the conference server sends a sidebarByValResponse message to Alice. 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.

サイドバーの予約を更新するためsidebarByValRequestメッセージを受信4.会議サーバは、アリスが操作を実行するために、その特定の会議オブジェクトに関連付けられたポリシーに基づいて適切な権限を持っていることを保証します。会議サーバはまた、ボブのようなメンバーはすでにこの会議サーバのユーザであることを確認して、予約で更新された情報を検証する必要があります。 <confObjID>で識別される会議のためのデータが更新されると、会議サーバは、アリスにsidebarByValResponseメッセージを送信します。ポリシーに応じて、サイドバー（すなわち、ボブ）における要求のイニシエータ（すなわち、アリス）と参加者は、会議通知サービスを介してサイドバーに彼のほかの通知をすることができます。

5. At this point, Bob sends a userRequest message to the conference server with an operation of "update" to completely disable the background audio from the parent conference, since it prevents him from understanding what Alice says in the sidebar.

それはアリスがサイドバーに言っていることを理解から彼を防ぐため、この時点で5、ボブは、完全に親会議からのバックグラウンドオーディオを無効にするには、「更新」の操作で会議サーバにuserRequestメッセージを送信します。

6. Notice that Bob's request only changes the media perspective for Bob. Alice keeps on receiving both the audio from Bob and the background from the parent conference. This request may be relayed by the conference server to the media server handling the mixing, if present. Upon completion of the change, the conference server sends a userResponse message to Bob. Depending upon the policies, the initiator of the request (i.e., Bob) and the participants in the sidebar (i.e., Alice) may be notified of this change via the conference notification service.

ボブの要求は唯一のボブのためのメディアの視点を変更する6.注意してください。アリスはボブからオーディオと親会議から背景の両方を受信し続けています。この要求が存在する場合、混合を扱うメディアサーバに、会議サーバによって中継されてもよいです。変更が完了すると、会議サーバは、ボブにuserResponseメッセージを送信します。ポリシーに応じて、サイドバー（すなわち、アリス）における要求のイニシエーター（すなわち、ボブ）と参加者は、会議通知サービスを介してこの変更を通知されてもよいです。

The following conference object represents the conference in which the sidebar is to be created. It will be used by the conference server to create the new conference object associated with the sidebar.

次の会議オブジェクトは、サイドバーが作成される会議を表します。サイドバーに関連付けられている新しい会議のオブジェクトを作成するために、会議サーバによって使用されます。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <info:conference-info xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" entity="xcon:8977878@example.com"> <info:conference-description> <info:display-text>MAIN CONFERENCE</info:display-text> <info:conf-uris> <info:entry> <info:uri>sip:8977878@example.com</info:uri> <info:display-text>conference sip uri</info:display-text> </info:entry> </info:conf-uris> <info:available-media> <info:entry label="123"> <info:display-text>main conference audio</info:display-text> <info:type>audio</info:type> <info:status>sendrecv</info:status> </info:entry> <info:entry label="456"> <info:display-text>main conference video</info:display-text> <info:type>video</info:type> <info:status>sendrecv</info:status> <xcon:controls> <xcon:video-layout>single-view</xcon:video-layout> </xcon:controls> </info:entry> </info:available-media> </info:conference-description> <info:conference-state> <info:active>true</info:active> </info:conference-state> <info:users> <info:user entity="xcon-userid:Alice@example.com"> <info:display-text>Alice</info:display-text> <info:endpoint entity="sip:Alice@example.com"> <info:media id="1">

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <情報：会議-情報のxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP = "壷：IETF：のparams：XML：NS：XCON：CCMP" のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-情報" 実体= "XCON：8977878@example.com"> <情報：会議の記述> <情報：表示テキスト> MAIN会議</情報：表示テキスト> <情報：CONF-のURI> <情報：エントリ> <情報：URI> SIP：8977878@example.com </情報：URI> <情報：表示テキスト>会議SIP URI </情報：表示テキスト> </情報：エントリ> </情報：CONF-のURI> <情報：使用可能なメディア> <情報：エントリラベル= "123 「> <情報：表示テキスト>メイン会議オーディオ</情報：表示テキスト> <情報：タイプ>オーディオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> <情報：エントリラベル= "456"> <情報：表示テキスト>メイン会議ビデオ</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> <XCON：コントロール> <XCON：ビデオレイアウト>シングルビュー</ XCON：ビデオレイアウト> </ XCON：コントロール> </情報：エントリ> </情報：利用可能メディア> </情報：会議-des cription> <情報：会議状態> <情報：アクティブ>真</情報：アクティブ> </情報：会議状態> <情報：ユーザー> <情報：ユーザエンティティ= "XCON-ユーザーID：Alice@example.com "> <情報：表示テキスト>アリス</情報：表示テキスト> <情報：エンドポイントエンティティ=" SIP：Alice@example.com "> <情報：メディアID =" 1" >

<info:label>123</info:label> <info:status>sendrecv</info:status> </info:media> <info:media id="2"> <info:label>456</info:label> <info:status>sendrecv</info:status> </info:media> </info:endpoint> </info:user> <info:user entity="xcon-userid:Bob@example.com"> <info:display-text>Bob</info:display-text> <info:endpoint entity="sip:bob83@example.com"> <info:media id="1"> <info:label>123</info:label> <info:status>sendrecv</info:status> </info:media> <info:media id="2"> <info:label>456</info:label> <info:status>sendrecv</info:status> </info:media> </info:endpoint> </info:user> <info:user entity="xcon-userid:Carol@example.com"> <info:display-text>Carol</info:display-text> <info:endpoint entity="sip:carol@example.com"> <info:media id="1"> <info:label>123</info:label> <info:status>sendrecv</info:status> </info:media> <info:media id="2"> <info:label>456</info:label> <info:status>sendrecv</info:status> </info:media> </info:endpoint> </info:user> </info:users> </info:conference-info>

<情報：ラベル> 123 </情報：ラベル> <情報：状態> SENDRECV </情報：状態> </情報：メディア> <情報：メディアID = "2"> <INFO：ラベル> 456 </情報：ラベル> <情報：状態> SENDRECV </情報：状態> </情報：メディア> </情報：エンドポイント> </情報：ユーザー> <情報：ユーザエンティティ= "XCON-ユーザーID：Bob@example.com"> <情報：表示テキスト>ボブ</情報：表示テキスト> <情報：エンドポイントエンティティ= "SIP：bob83@example.com"> <情報：メディアID = "1"> <INFO：ラベル> 123 </情報：ラベル> <情報：状態> SENDRECV </情報：状態> </情報：メディア> <情報：メディアID = "2"> <INFO：ラベル> 456 </情報：ラベル> <情報：ステータス> SENDRECV </情報：状態> </情報：メディア> </情報：エンドポイント> </情報：ユーザー> <情報：ユーザエンティティ= "XCON-ユーザーID：Carol@example.com"> <情報：表示テキスト>キャロル</情報：表示テキスト> <情報：エンドポイント実体= "一口：carol@example.com"> <情報：メディアID = "1"> <INFO：ラベル> 123 </情報：ラベル> <情報：ステータス> SENDRECV </情報：状態> </情報：メディア> <情報：メディアID = "2"> <INFO：ラベル> 456 </情報：ラベル> <情報：状態> SENDRECV </情報：状態> </情報：メディア> </情報：エンドポイント> </情報：ユーザー> </情報：ユーザー> </情報：会議-インフォメーション>

Figure 19: Conference with Alice, Bob, and Carol

図19：アリス、ボブ、およびキャロルの会議

The sidebar creation happens through a cloning of the parent conference. Once the sidebar is created, an update request makes sure that the sidebar is customized as needed. The following protocol dump makes the process clearer.

サイドバーの作成は、親会議のクローニングによって起こります。サイドバーが作成されたら、更新要求は、必要に応じてサイドバーがカスタマイズされていることを確認します。次のプロトコル・ダンプは、プロセスが明確になります。

1. sidebarByValRequest/create message (Alice creates an internal sidebar)

1. sidebarByValRequest /（アリスが内部サイドバーを作成する）メッセージを作成

2. sidebarByValResponse/create message (sidebar returned)

2. sidebarByValResponse /メッセージを作成し（サイドバーを返します）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-sidebarByVal-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8974545@example.com</confObjID> <operation>create</operation> <response-code>200</response-code> <response-string>success</response-string> <version>1</version> <ccmp:sidebarByValResponse> <sidebarByValInfo entity="xcon:8974545@example.com"> <info:conference-description> <info:display-text> SIDEBAR CONFERENCE registered by Alice </info:display-text> <info:available-media> <info:entry label="123"> <info:display-text> main conference audio </info:display-text> <info:type>audio</info:type> <info:status>sendrecv</info:status> </info:entry> <info:entry label="456"> <info:display-text> main conference video

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-情報" のxmlns：インフォ= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP = "壷：IETF：のparams：XML：NS：XCON：CCMP"> <ccmpResponseののxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-sidebarByVal応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8974545 @ example.com </ confObjID> <操作> </操作> <レスポンスコード> 200 </レスポンスコード> <レスポンス文字列>成功</レスポンス文字列> <バージョン> 1 </バージョン> <CCMPを作成します。 sidebarByValResponse> <sidebarByValInfo実体= "XCON：8974545@example.com"> <情報：会議-記述> <情報：アリスによって登録された表示テキスト>サイドバー会議</情報：表示テキスト> <情報：使用可能なメディア> <情報：エントリラベル= "123"> <情報：表示テキスト>メイン会議オーディオ</情報：表示テキスト> <情報：タイプ>オーディオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> <情報：エントリラベル= "456"> <情報：表示テキスト>メイン会議ビデオ

</info:display-text> <info:type>video</info:type> <info:status>sendrecv</info:status> </info:entry> </info:available-media> </info:conference-description> <info:conference-state> <info:active>false</info:active> </info:conference-state> <info:users> <xcon:allowed-users-list> <xcon:target method="dial-in" uri="xcon-userid:Alice@example.com"/> <xcon:target method="dial-in" uri="xcon-userid:Bob@example.com"/> <xcon:target method="dial-in" uri="xcon-userid:Carol@example.com"/> </xcon:allowed-users-list> <xcon:sidebar-parent> xcon:8977878@example.com </xcon:sidebar-parent> </info:users> </sidebarByValInfo> </ccmp:sidebarByValResponse> </ccmpResponse> </ccmp:ccmpResponse>

</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> </情報：利用可能メディア> </情報：会議記述> <情報：会議状態> <情報：アクティブ>偽</情報：アクティブ> </情報：会議状態> <情報：ユーザー> <XCON：許可ユーザー・リスト> <[XCONターゲット方法= "ダイヤルイン" URI = "XCON-ユーザーID：Alice@example.com" /> <XCON：ターゲットメソッド= "ダイヤルイン" URI = "XCON-ユーザーID：Bob@example.com" /> <[XCONターゲットメソッド= "ダイヤルイン" のuri = "XCON-ユーザーID：Carol@example.com" /> </ XCON：許可ユーザー・リスト> <XCON：サイドバーの親> [XCON 8977878@example.com </ XCON ：サイドバーの親> </情報：ユーザー> </ sidebarByValInfo> </ CCMP：sidebarByValResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

3. sidebarByValRequest/update message (Alice updates the created sidebar)

3. sidebarByValRequest /更新メッセージ（アリスが作成したサイドバーを更新します）

<info:display-text> main conference audio </info:display-text> <info:type>audio</info:type> <info:status>recvonly</info:status> <xcon:controls> <xcon:gain>-60</xcon:gain> </xcon:controls> </info:entry> <info:entry label="456"> <info:display-text> main conference video </info:display-text> <info:type>video</info:type> <info:status>recvonly</info:status> </info:entry> <info:entry label="AUTO_GENERATE_1"> <info:display-text> sidebar audio </info:display-text> <info:type>audio</info:type> <info:status>sendrecv</info:status> </info:entry> <info:entry label="AUTO_GENERATE_2"> <info:display-text> sidebar video </info:display-text> <info:type>video</info:type> <info:status>sendrecv</info:status> </info:entry> </info:available-media> </info:conference-description> <info:users> <xcon:allowed-users-list> <xcon:target method="dial-out" uri="xcon-userid:Alice@example.com"/> <xcon:target method="dial-out" uri="xcon-userid:Bob@example.com"/> </xcon:allowed-users-list> </info:users> </sidebarByValInfo> </ccmp:sidebarByValRequest> </ccmpRequest> </ccmp:ccmpRequest>

<情報：表示テキスト>メイン会議オーディオ</情報：表示テキスト> <情報：タイプ>オーディオ</情報：タイプ> <情報：状態>がrecvonly </情報：状態> <XCON：コントロール> <[XCON]ゲイン> -60 </ XCON：ゲイン> </ XCON：コントロール> </情報：エントリ> <情報：エントリラベル= "456"> <情報：表示テキスト>メイン会議ビデオ</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：状態>がrecvonly </情報：状態> </情報：エントリ> <情報：エントリラベル= "AUTO_GENERATE_1"> <情報：表示テキスト>サイドバーのオーディオ< /情報：表示テキスト> <情報：タイプ>オーディオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> <情報：エントリラベル= "AUTO_GENERATE_2"> <情報：表示テキスト>サイドバーのビデオ</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> </情報：available-メディア> </情報：会議-記述> <情報：ユーザー> <XCON：許可ユーザー・リスト> <XCON：ターゲット・メソッド= "ダイヤルアウト" のuri = "XCON-ユーザーID：Alice@example.com" /> <XCON：ターゲット・メソッド= "ダイヤルアウト" のuri = "XCON-ユーザーID：Bob@example.com" /> </ XCON：許可ユーザー・リスト> </情報：ユーザー> </ sidebarByValInfo > </ CCMP：sidebarByValRequest> </ ccmpRequest> </ CCMP：ccmpRequest>

4. sidebarByValResponse/update message (sidebar's updates accepted)

4. sidebarByValResponse /更新メッセージ（サイドバーの更新が認められました）

5. userRequest/update message (Bob updates his media)

5. userRequest /更新メッセージ（ボブは彼のメディアを更新します）

6. userResponse/update message (Bob's preferences are set)

6. userResponse /更新メッセージ（ボブのプリファレンスが設定されています）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-response-message-type"> <confUserID>xcon-userid:Bob@example.com</confUserID> <confObjID>xcon:8974545@example.com</confObjID> <operation>update</operation> <response-code>200</response-code> <response-string>success</response-string> <version>3</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpResponseののxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-ユーザ応答メッセージ型"> <confUserID> XCON-ユーザーID：Bob@example.com </ confUserID> <confObjID> XCON：8974545 @ example.com </ confObjID> <動作>更新</操作> <レスポンスコード> 200 </レスポンスコード> <応答文字列>成功</応答文字列> <バージョン> 3 </バージョン> <CCMP。 userResponse /> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 20: Internal Sidebar Messaging Details

図20：内部サイドバーメッセージング詳細

7.2. External Sidebar

7.2. 外部サイドバー

Figure 21 provides an example of a different approach towards sidebars. In this scenario, one client, Alice, is involved in an active conference with Bob, Carol, David, and Ethel. Alice gets an important text message via a whisper from Bob that a critical customer needs to talk to Alice, Bob, and Ethel. Alice creates a sidebar to have a side discussion with the customer Fred including the participants in the current conference with the exception of Carol and David, who remain in the active conference. The difference from the previous scenario is that Fred is not part of the parent conference: this means that different policies might be involved, considering that Fred may access information coming from the parent conference, in case the sidebar was configured accordingly. For this reason, in this scenario, we assume that Alice disables all the media from the original (parent) conference within the sidebar. This means that, while in the previous example Alice and Bob still heard the audio from the main conference in background, this time no background is made available. Alice initiates the sidebar by sending a request to the conference server 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. However, providing the hold state allows the participants in the main conference to see that others in the conference are busy. Note, that a separate conference could have been created by Alice to allow Bob and Ethel to talk to Fred. However, creating a sidebar has somewhat of an advantage by allowing the conference to be created using some of the same settings (e.g., role, floor control, etc.) that Bob and Ethel had in the main conference and it would allow for updates such that the media could be updated, for example, to provide audio from the main conference.

図21は、サイドバーに向かって異なるアプローチの例を提供します。このシナリオでは、1つのクライアント、アリスは、ボブ、キャロル、デイヴィッド、エセルとアクティブな会議に関与しています。アリスは、重要な顧客はアリス、ボブ、エセルに話をする必要がボブからのささやきを経由して、重要なテキストメッセージを取得します。アリスは、アクティブな会議に残るキャロルとDavidの例外を除いて、現在の会議の参加者を含む顧客フレッドとサイドの議論を持っているサイドバーを作成します。前のシナリオとの違いは、フレッドは、親会議の一部ではないということです。これは、フレッドは、サイドバーが適切に設定された場合には、親会議からの情報にアクセスすることができることを考えると、異なるポリシーが関与しているかもしれないことを意味しています。このため、このシナリオでは、私たちは、アリスは、サイドバー内の元の（親）の会議からすべてのメディアを無効にしていることを前提としています。これは、前の例では、アリスとボブはまだバックグラウンドでメイン会議からの音声を聞いている間、この時間がないバックグラウンドが使用可能になる、ということを意味しています。アリスは、アクティブな会議のオブジェクトに基づいて会議予約を作成するために、会議サーバにリクエストを送信することにより、サイドバーを開始します。アリス、ボブとエセルはホールド状態での主な会議の名簿に残るでしょう。これらの参加者の保留状態が他の参加者に表示されているかどうかは、個人や地域の政策に依存します。ただし、ホールド状態を提供することが主な会議の参加者が会議中に他の人が忙しくしていることを確認することができます。別の会議は、ボブとエセルはフレッドと話をできるようにするためにアリスによって作成されている可能性があることに注意してください。しかし、サイドバーを作成することは、ボブとエセルはメイン会議に持っていたし、それはそのような更新を可能にすることを会議は、（例えば、役割、フロア制御、）同じ設定の一部を使用して作成することができるようにすることで、やや優位の持っていますメディアを更新することができること、例えば、メイン会議からの音声を提供します。

 Alice                   Bob                   ConfS
   |                      |                       |
   |(1) sidebarByRefRequest(confUserID,           |
   |                 confObjID, create)           |
   |--------------------------------------------->|
   |                      |                       |
   |                      |        (a) Create +---|
   |                      |    sidebar-by-ref |   |
   |                      |     (new conf obj |   |
   |                      |       cloned from +-->|
   |                      |        confObjID)     | Sidebar now has
   |                      |                       | id confObjID*
   |(2) sidebarByRefResponse(confUserID,          | (parent mapping
   |      confObjID*,create,200,success,          | conf<->sidebar)
   |           version,sidebarByRefInfo)          |
   |<---------------------------------------------|
   |                      |                       |
   |(3) sidebarByRefRequest(confUserID,           |
   |      confObjID*,update,sidebarByRefInfo)     |
   |--------------------------------------------->|
   |                      |                       |
   |                      |        (b) Create +---|
   |                      |      new user for |   |
   |                      |            Fred   |   |
   |                      |                   +-->|
   |                      |                       |
   |                      |        (c) Update +---|
   |                      |    sidebar-by-ref |   |
   |                      |     (media, users |   |
   |                      |     policy, etc.) +-->|
   |                      |                       | Sidebar is modified:
   |                      |                       | media from the
   |                      |                       | parent conference is
   |                      |                       | not available to
   |(4) sidebarByRefResponse(confUserID,          | anyone
   |                 confObjID*, update,          |
   |             200, success, version)           |
   |<---------------------------------------------|
   |                      |                       |

   |                      |        Notify (Fred   |
   |                      |              added to |
   |                      |        sidebar users) |
   |                      |<----------------------|
   |                      |                       |
   '                      '                       '
   '                      '                       '
   '                      '                       '

Figure 21: Client Creation of an External Sidebar

図21：外部サイドバーのクライアント作成

1. Upon receipt of the sidebarByRefRequest message to create a new sidebar conference, based upon the active conference specified by <confObjID> in the request, the conference server uses that active conference to clone a conference reservation for the sidebar. The sidebar reservation is NOT independent of the active conference (i.e., parent). The conference server, as before, allocates a new XCON-URI ("confObjID*" in Figure 21) to be used for any subsequent protocol requests toward the sidebar reservation. The mapping between the sidebar XCON-URI and the one associated with the main conference is maintained by the conference server and it is gathered from the <sidebar-parent> element in the sidebar conference object.

リクエストに<confObjID>で指定されたアクティブな会議に基づいた新しいサイドバーの会議を作成するsidebarByRefRequestメッセージを受信すると1は、会議サーバは、アクティブな会議は、サイドバーのための会議予約のクローンを作成することを使用しています。サイドバーのご予約は、アクティブな会議（すなわち、親）の独立していません。会議サーバは、以前のように、（図21で「confObjID *」）新しいXCON-URIを割り当てるサイドバー予約に向かって後続のプロトコル要求に使用されます。サイドバーXCON-URIとメイン会議に関連する一つとの間のマッピングは、会議サーバによって維持され、それがサイドバー会議オブジェクト内の<サイドバー親>要素から収集されます。

2. Upon receipt of the sidebarByRefResponse message, which acknowledges the successful creation of the sidebar object, Alice decides that only Bob and Ethel, along with the new participant Fred are to be involved in the sidebar. Thus, she manipulates the membership accordingly. Alice also sets the media in the <conference-info> such that the participants in the sidebar don't receive any media from the main conference. All these settings are provided to the conferencing server by means of a new sidebarByRefRequest message, with an "update" <operation>.

サイドバーのオブジェクトの作成に成功したことを認めてsidebarByRefResponseメッセージを受け取ると2.は、アリスはボブとエセルは、新しい参加者と一緒にフレッドは、サイドバーに関与することを決定しました。このように、彼女はそれに応じてメンバーシップを操作します。アリスはまた、サイドバーの参加者がメイン会議から任意のメディアを受信しないように、<会議・インフォメーション>内のメディアを設定します。すべてのこれらの設定は、「更新」<操作>で、新しいsidebarByRefRequestメッセージによって、会議サーバに提供されています。

3. Alice sends the aforementioned sidebarByRefRequest message to update the information in the reservation and to create an active conference. Upon receipt of the sidebarByRefRequest/update message, the conference server ensures that Alice has the appropriate authority based on the policies associated with that specific conference object to perform the operation. The conference server also validates the updated information in the reservation. Since Fred is a new user for this conferencing system, a conference user identifier (XCON-USERID) is created for Fred. Specifically, Fred is added to the conference by only providing his SIP URI. Based upon the contact information provided for Fred by Alice, the call signaling to add Fred to the conference may be instigated through the focus (e.g., if Fred had a "dial-out" value for the 'method' attribute in his <target> field under <allowed-users-list>) at the actual activation of the sidebar.

3.アリスは、予約の情報を更新し、アクティブな会議を作成するために、前述のsidebarByRefRequestメッセージを送信します。 sidebarByRefRequest /更新メッセージを受信すると、会議サーバは、アリスが操作を実行するために、その特定の会議オブジェクトに関連付けられたポリシーに基づいて適切な権限を持っていることを保証します。会議サーバも予約で更新された情報を検証します。フレッドはこの会議システムのための新しいユーザーであることから、会議のユーザ識別子（XCON-USERID）がフレッドのために作成されます。具体的には、フレッドは彼のSIP URIを提供することで、会議に追加されます。アリスによってフレッドのために設けられたコンタクト情報に基づいて、会議にフレッドを追加するためにコールシグナリングがフォーカスによって扇動することができる（例えば、フレッドは彼の<対象>に「メソッド」属性のための「ダイヤルアウト」の値を持っていた場合サイドバーの実際の起動時の<許可ユーザリスト>下フィールド）。

4. The conference server sends a sidebarByRefResponse message and, 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.

4.会議サーバはsidebarByRefResponseメッセージを送信し、ポリシーに応じて、要求（すなわち、アリス）のイニシエータとサイドバー（すなわち、ボブとエセル）の参加者は、経由してサイドバーに彼のほかの通知をすることができます会議通知サービス。

1. sidebarByRefRequest/create message (Alice creates an external sidebar)

1. sidebarByRefRequest /（アリスが外部サイドバーを作成する）メッセージを作成

2. sidebarByRefResponse/create message (created sidebar returned)

2. sidebarByRefResponse /メッセージを作成します（作成したサイドバーが返されます）

<info:available-media> <info:entry label="123"> <info:display-text> main conference audio </info:display-text> <info:type>audio</info:type> <info:status>sendrecv</info:status> </info:entry> <info:entry label="456"> <info:display-text> main conference video </info:display-text> <info:type>video</info:type> <info:status>sendrecv</info:status> </info:entry> </info:available-media> </info:conference-description> <info:conference-state> <info:active>false</info:active> </info:conference-state> <info:users> <xcon:allowed-users-list> <xcon:target method="dial-in" uri="xcon-userid:Alice@example.com"/> <xcon:target method="dial-in" uri="xcon-userid:Bob@example.com"/> <xcon:target method="dial-in" uri="xcon-userid:Carol@example.com"/> <xcon:target method="dial-in" uri="xcon-userid:David@example.com"/> <xcon:target method="dial-in" uri="xcon-userid:Ethel@example.com"/> </xcon:allowed-users-list> <xcon:sidebar-parent> xcon:8977878@example.com </xcon:sidebar-parent> </info:users> </sidebarByRefInfo> </ccmp:sidebarByRefResponse> </ccmpResponse> </ccmp:ccmpResponse>

<情報：使用可能なメディア> <情報：エントリラベル=「123」> <情報：表示テキスト>メイン会議オーディオ</情報：表示テキスト> <情報：タイプ>オーディオ</情報：タイプ> <情報：ステータス> SENDRECV </情報：状態> </情報：エントリ> <情報：エントリラベル= "456"> <情報：表示テキスト>メイン会議ビデオ</情報：表示テキスト> <情報：タイプ>ビデオ< /情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> </情報：利用可能メディア> </情報：会議-記述> <情報：会議状態> <情報：アクティブ>偽</情報：アクティブ> </情報：会議状態> <情報：ユーザー> <XCON：許可ユーザー・リスト> <XCON：ターゲット・メソッド= "ダイヤルイン" のuri = "XCON-ユーザーID：アリス@ example.com "/> <XCON：ターゲット・メソッド=" ダイヤルイン "のuri = "XCON-ユーザーID：Bob@example.com"/> <XCON：ターゲット・メソッド= "ダイヤルイン" のuri =" XCON-ユーザーID： Carol@example.com "/> <XCON：ターゲット・メソッド=" ダイヤルイン "のuri = "XCON-ユーザーID：David@example.com"/> <XCON：ターゲット・メソッド= "ダイヤルイン" のuri =" xcon-ユーザーID：Ethel@example.com "/> </ XCON：許可ユーザー・リスト> <XCON：サイドバーの親> [XCON 8977878@example.com </ XCON：サイドバーの親> </情報：ユーザー> </ sidebarByRefInfo > </ CCMP：sidebarByRefResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

3. sidebarByRefRequest/update message (Alice updates the sidebar)

3. sidebarByRefRequest /更新メッセージ（アリスがサイドバーを更新します）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpRequest xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-sidebarByRef-request-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8971212@example.com</confObjID> <operation>update</operation> <ccmp:sidebarByRefRequest> <sidebarByRefInfo entity="xcon:8971212@example.com"> <info:conference-description> <info:display-text> sidebar with Alice, Bob, Ethel and Fred </info:display-text> <info:available-media> <info:entry label="123"> <info:display-text> main conference audio </info:display-text> <info:type>audio</info:type> <info:status>inactive</info:status> </info:entry> <info:entry label="456"> <info:display-text> main conference video </info:display-text> <info:type>video</info:type> <info:status>inactive</info:status> </info:entry> <info:entry label="AUTO_GENERATE_1"> <info:display-text> sidebar audio </info:display-text> <info:type>audio</info:type> <info:status>sendrecv</info:status> </info:entry> <info:entry label="AUTO_GENERATE_2"> <info:display-text> sidebar video </info:display-text> <info:type>video</info:type> <info:status>sendrecv</info:status> <xcon:controls> <xcon:video-layout> single-view </xcon:video-layout> </xcon:controls> </info:entry> </info:available-media> </info:conference-description>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpRequestののxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-情報" のxmlns：インフォ= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP = "壷：IETF：のparams：XML：NS：XCON：CCMP"> <ccmpRequestのxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-sidebarByRef要求メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8971212 @ example.com </ confObjID> <操作>更新</操作> <CCMP：sidebarByRefRequest> <sidebarByRefInfo実体= "XCON：8971212@example.com"> <情報：会議-説明>：と<情報表示テキスト>サイドバーアリス、ボブ、エセルとフレッド</情報：表示テキスト> <情報：使用可能なメディア> <情報：エントリラベル=「123」> <情報：表示テキスト>メイン会議オーディオ</情報：表示テキスト> <情報：タイプ>オーディオ</情報：タイプ> <情報：状況>非アクティブ</情報：状態> </情報：エントリ> <情報：エントリラベル= "456"> <情報：表示テキスト>メイン会議ビデオ</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：ステータス> INA ctive </情報：状態> </情報：エントリ> <情報：エントリラベル= "AUTO_GENERATE_1"> <情報：表示テキスト>サイドバーのオーディオ</情報：表示テキスト> <情報：タイプ>オーディオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> <情報：エントリラベル= "AUTO_GENERATE_2"> <情報：表示テキスト>サイドバーのビデオ</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> <XCON：コントロール> <XCON：ビデオレイアウト>シングルビュー</ XCON：ビデオレイアウト> </ XCON：コントロール> </情報：エントリ> </情報：利用可能メディア> </情報：会議記述>

<info:conference-state> <info:active>false</info:active> </info:conference-state> <info:users> <xcon:allowed-users-list> <xcon:target method="dial-out" uri="xcon-userid:Alice@example.com"/> <xcon:target method="dial-out" uri="xcon-userid:Bob@example.com"/> <xcon:target method="dial-out" uri="sip:fred@example.com"/> </xcon:allowed-users-list> </info:users> </sidebarByRefInfo> </ccmp:sidebarByRefRequest> </ccmpRequest> </ccmp:ccmpRequest>

<情報：会議状態> <情報：アクティブ>偽</情報：アクティブ> </情報：会議状態> <情報：ユーザー> <XCON：許可ユーザー・リスト> <XCON：ターゲット・メソッド= "ダイヤルインAlice@example.com "/> <[XCON：ターゲット・メソッド= " "URI =" XCON-ユーザIDアウトダイヤルアウト" のuri = "XCON-ユーザーID：Bob@example.com"/> <XCON：ターゲット・メソッド="ダイヤルアウト」のuri = "一口：fred@example.com" /> </ XCON：許可ユーザー・リスト> </情報：ユーザー> </ sidebarByRefInfo> </ CCMP：sidebarByRefRequest> </ ccmpRequest> </ CCMP ：ccmpRequest>

4. sidebarByRefResponse/update message (sidebar updated)

4. sidebarByRefResponse /更新メッセージ（サイドバーは、更新されました）

Figure 22: External Sidebar Messaging Details

図22：外部サイドバーメッセージング詳細

7.3. Private Messages

7.3. プライベートメッセージ

The case of private messages can be handled as a sidebar with just two participants, similar to the example in Section 7.1. Unlike the previous example, rather than using audio within the sidebar, Alice could just add an additional text-based media stream to the sidebar in order to convey her textual messages to Bob, while still viewing and listening to the main conference.

プライベートメッセージの場合は、7.1節の例と同様、単に2人の参加者とのサイドバーとして取り扱うことができます。まだ閲覧してメイン会議を聞きながら、前の例とは異なり、むしろサイドバー内のオーディオを使用するよりも、アリスはちょうど、ボブに彼女のテキストメッセージを伝えるためにサイドバーに追加のテキストベースのメディアストリームを追加することができます。

In this scenario, Alice requests to the conference server the creation of a private chat room within the main conference context (presented in Figure 19) in which the involved participants are just Bob and herself. This can be achieved through the following CCMP transaction (Figure 23).

このシナリオでは、アリスは、会議サーバへの関与、参加者がちょうどボブと彼女自身である、（図19に示される）、メイン会議コンテキスト内のプライベートチャットルームの作成を依頼します。これは、次のCCMPトランザクション（図23）を介して達成することができます。

1. Alice forwards a sidebarByValRequest/create message to the conference server with the main conference XCON-URI in the <confObjID> parameter and the desired sidebar conference object in the <sidebarByValInfo> field. In this way, a sidebar creation using user-provided conference information is requested from the conference server. Please note that, unlike the previous sidebar examples, in this case, a completely new conference object to describe the sidebar is provided: there is no cloning involved, while the <confObjID> still enforces the parent-child relationship between the main conference and the to-be-created sidebar.

1.アリスはsidebarByValRequestを転送/ <confObjID>パラメータと<sidebarByValInfo>フィールドに所望のサイドバー会議オブジェクトでメイン会議XCON-URIと会議サーバにメッセージを作成します。このように、ユーザーが提供する会議情報を使用して、サイドバーの作成は、会議サーバから要求されます。何のクローニング関与はありません、<confObjID>は、まだメイン会議との間に親子関係を強制しながら：前のサイドバーの例とは異なり、この場合には、サイドバーを記述するための完全に新しい会議オブジェクトが提供されることに注意してください作成がサイドバー。

2. The conference server, after checking Alice's rights and validating the conference object carried in the request, creates the required sidebar-by-val conference and a new XCON-URI for it. Instead of cloning the main conference object, as shown in Sections 7.1 and 7.2, the sidebar is created on the basis of the user-provided conference information. However, the parent relationship between the main conference and the newly created sidebar is still maintained by the conference server (as a consequence of the chosen CCMP request message type -- the sidebarByVal one) and it is reflected by the <sidebar-parent> element in the <sidebarByValInfo> element returned in the sidebarByValResponse message. Please notice that, according to the CCMP specification, the return of the created sidebar data in this kind of "success" response is not mandatory.

2.会議サーバは、アリスの権利をチェックし、リクエストで運ば会議オブジェクトを検証した後、必要なサイドバー・バイ・ヴァル会議およびそれのための新しいXCON-URIを作成します。代わりに、セクション7.1及び7.2に示すように、メイン会議オブジェクトをクローニングする、サイドバーは、ユーザが提供した会議情報に基づいて作成されます。しかし、メイン会議と新しく作成されたサイドバーの間の親子関係は、依然として（選択されたCCMP要求メッセージタイプの結果として - sidebarByVal 1）会議サーバによって維持され、それは、<サイドバー親>要素によって反射され<sidebarByValInfo>要素にsidebarByValResponseメッセージで返さ。それを注意してください、CCMPの仕様に応じて、「成功」応答のこの種で作成されたサイドバーのデータのリターンは必須ではありません。

1. sidebarByValRequest/create message (Alice creates a private chat room between Bob and herself)

1. sidebarByValRequest /（アリスはボブと自分の間にプライベートチャットルームを作成します）メッセージを作成

<info:conference-description> <info:display-text> private textual sidebar alice - bob </info:display-text> <info:available-media> <info:entry label="123"> <info:display-text> main conference audio </info:display-text> <info:type>audio</info:type> <info:status>recvonly</info:status> </info:entry> <info:entry label="456"> <info:display-text> main conference video </info:display-text> <info:type>video</info:type> <info:status>recvonly</info:status> </info:entry> <info:entry label="AUTO_GENERATE_2"> <info:display-text> sidebar text </info:display-text> <info:type>text</info:type> <info:status>sendrecv</info:status> </info:entry> </info:available-media> </info:conference-description> <info:users> <xcon:allowed-users-list> <xcon:target method="dial-out" uri="xcon-userid:Alice@example.com"/> <xcon:target method="dial-out" uri="xcon-userid:Bob@example.com"/> </xcon:allowed-users-list> </info:users> </sidebarByValInfo> </ccmp:sidebarByValRequest> </ccmpRequest> </ccmp:ccmpRequest>

<情報：会議-記述> <情報：表示テキスト>民間のテキストサイドバーアリス - ボブ</情報：表示テキスト> <情報：使用可能なメディア> <情報：エントリラベル= "123"> <情報：ディスプレイ - テキスト>メイン会議オーディオ</情報：表示テキスト> <情報：タイプ>オーディオ</情報：タイプ> <情報：状態>がrecvonly </情報：状態> </情報：エントリ> <情報：エントリラベル=」 456" > <情報：表示テキスト>メイン会議ビデオ</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：状態>がrecvonly </情報：状態> </情報：エントリー> <情報：エントリラベル= "AUTO_GENERATE_2"> <情報：表示テキスト>サイドバーのテキスト</情報：表示テキスト> <情報：タイプ>テキスト</情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> </情報：利用可能メディア> </情報：会議-記述> <情報：ユーザー> <XCON：許可ユーザー・リスト> <XCON：ターゲット・メソッド= "ダイヤルアウト" のuri = "XCON-ユーザーID：Alice@example.com" /> <XCON：ターゲット・メソッド= "ダイヤルアウト" のuri = "XCON-ユーザーID：Bob@example.com" /> </ XCON：許可ユーザーリスト> </情報：ユーザー> </ sidebarByValInfo> </ CCMP：sidebarByValRequest> </ ccmpRequest> </ CCMP：ccmpRequest>

2. sidebarByValResponse/create message (sidebar returned)

2. sidebarByValResponse /メッセージを作成し（サイドバーを返します）

<ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-sidebarByVal-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8974545@example.com</confObjID> <operation>create</operation> <response-code>200</response-code> <response-string>success</response-string> <version>1</version> <ccmp:sidebarByValResponse> <sidebarByValInfo entity="xcon:8974545@example.com"> <info:conference-description> <info:display-text> private textual sidebar alice - bob </info:display-text> <info:available-media> <info:entry label="123"> <info:display-text> main conference audio </info:display-text> <info:type>audio</info:type> <info:status>recvonly</info:status> </info:entry> <info:entry label="456"> <info:display-text> main conference video </info:display-text> <info:type>video</info:type> <info:status>recvonly</info:status> </info:entry> <info:entry label="789"> <info:display-text> sidebar text </info:display-text> <info:type>text</info:type> <info:status>sendrecv</info:status> </info:entry> </info:available-media> <xcon:sidebar-parent> xcon:8977878@example.com </xcon:sidebar-parent> </info:conference-description> <info:users> <xcon:allowed-users-list> <xcon:target method="dial-out" uri="xcon-userid:Alice@example.com"/> <xcon:target method="dial-out" uri="xcon-userid:Bob@example.com"/> </xcon:allowed-users-list>

<ccmpResponse用のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance" XSI：タイプ= "CCMP：CCMP-sidebarByVal応答メッセージ型"> <confUserID> XCON-ユーザーID：アリス@ example.com </ confUserID> <confObjID> [XCON 8974545@example.com </ confObjID> <操作> </操作> <レスポンスコード> 200 </レスポンスコード> <レスポンス文字列>成功</レスポンスを作成します-string> <バージョン> 1 </バージョン> <CCMP：sidebarByValResponse> <sidebarByValInfo実体= "XCON：8974545@example.com"> <情報：会議-記述> <情報：表示テキスト>民間のテキストサイドバーアリス - ボブ</情報：表示テキスト> <情報：使用可能なメディア> <情報：エントリラベル=「123」> <情報：表示テキスト>メイン会議オーディオ</情報：表示テキスト> <情報：タイプ>オーディオ< /情報：タイプ> <情報：状態>がrecvonly </情報：状態> </情報：エントリ> <情報：エントリラベル= "456"> <情報：表示テキスト>メイン会議ビデオ</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：状態>がrecvonly </情報：状態> </情報：エントリ> <情報：エントリラベル= "789"> <情報：表示テキスト>サイドバーのテキスト</情報：表示テキスト> <情報：タイプ>テキスト</中FO：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> </情報：利用可能メディア> <XCON：サイドバーの親> [XCON 8977878@example.com </ XCON：sidebar-親> </情報：会議-記述> <情報：ユーザー> <XCON：許可ユーザー・リスト> <XCON：ターゲット・メソッド= "ダイヤルアウト" のuri = "XCON-ユーザーID：Alice@example.com" /> <XCON：ターゲット・メソッド= "ダイヤルアウト" のuri = "XCON-ユーザーID：Bob@example.com" /> </ XCON：許可ユーザーリスト>

</info:users> </sidebarByValInfo> </ccmp:sidebarByValResponse> </ccmpResponse> </ccmp:ccmpResponse>

</情報：ユーザー> </ sidebarByValInfo> </ CCMP：sidebarByValResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 23: Sidebar for Private Messages Scenario

図23：プライベートメッセージシナリオのためのサイドバー

7.4. Observing and Coaching

7.4. 観察とコーチング

"Observing and Coaching" is one of the most interesting sidebar-related scenarios. In fact, it highlights two different interactions that have to be properly coordinated.

「観察とコーチング」最も興味深いサイドバーに関連するシナリオの一つです。実際には、それが適切に調整されなければなら二つの異なる相互作用を強調しています。

An example of observing and coaching is shown in Figure 25. 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. Of course, the conferencing system must make sure that the customer Carol is not aware of the presence of the coach Alice. This makes the use of a sidebar necessary for the success of the scenario.

観察とコーチングの例は、この例では、図25に示され、コールセンターエージェントボブは、顧客キャロルとの会議に関与しています。ボブは新しいエージェントで、アリスは彼が通常よりも長くキャロルとのコールにされていることを見ているので、彼女は必要に応じて通話やコーチ、ボブを観察することを決定します。もちろん、会議システムは、顧客キャロルコーチアリスの存在を認識していないことを確認する必要があります。これは、シナリオの成功のために必要なサイドバーを使用しています。

Consider the following as the conference document associated with the video conference involving Bob (the call agent) and Carol (the customer) (Figure 24):

ボブ（コールエージェント）とキャロル（顧客）（図24）を含むビデオ会議に関連した会議文書として次の点を考慮します。

</info:entry> <info:entry label="456"> <info:display-text>service video</info:display-text> <info:type>video</info:type> <info:status>sendrecv</info:status> <xcon:controls> <xcon:video-layout>single-view</xcon:video-layout> </xcon:controls> </info:entry> </info:available-media> </info:conference-description> <info:conference-state> <info:active>true</info:active> </info:conference-state> <info:users> <info:user entity="xcon-userid:bob@example.com"> <info:display-text>Bob - call agent</info:display-text> <info:endpoint entity="sip:bob@example.com"> <info:media id="1"> <info:label>123</info:label> <info:status>sendrecv</info:status> </info:media> <info:media id="2"> <info:label>456</info:label> <info:status>sendrecv</info:status> </info:media> </info:endpoint> </info:user> <info:user entity="xcon-userid:carol@example.com"> <info:display-text>Carol - customer</info:display-text> <info:endpoint entity="sip:carol@example.com"> <info:media id="1"> <info:label>123</info:label> <info:status>sendrecv</info:status> </info:media> <info:media id="2"> <info:label>456</info:label> <info:status>sendrecv</info:status> </info:media> </info:endpoint> </info:user> </info:users> </info:conference-info>

</情報：エントリ> <情報：エントリラベル= "456"> <情報：表示テキスト>サービスビデオ</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：ステータス> SENDRECV </情報：状態> <XCON：コントロール> <XCON：ビデオレイアウト>シングルビュー</ XCON：ビデオレイアウト> </ XCON：コントロール> </情報：エントリ> </情報：利用可能メディア> </情報：会議-記述> <情報：会議状態> <情報：アクティブ>真</情報：アクティブ> </情報：会議状態> <情報：ユーザー> <情報：ユーザエンティティ= "XCON-ユーザーID ：bob@example.com "> <情報：表示テキスト>ボブ - コールエージェント</情報：表示テキスト> <情報：エンドポイント実体=" 一口：bob@example.com "> <情報：メディアID =" 1 "> <INFO：ラベル> 123 </情報：ラベル> <情報：ステータス> SENDRECV </情報：ステータス> </情報：メディア> <情報：メディアID =" 2" > <INFO：ラベル> 456 < /情報：ラベル> <情報：状態> SENDRECV </情報：状態> </情報：メディア> </情報：エンドポイント> </情報：ユーザー> <情報：ユーザエンティティ= "XCON-ユーザーID：キャロル例@。 comの "> <情報：表示テキスト>キャロル - 顧客</情報：表示テキスト> <情報：エンドポイント実体=" 一口：carol@example.com "> <情報：メディアID =" 1" > <情報：ラベル> 123 </情報：ラベル> <情報：ステータス> SE ndrecv </情報：状態> </情報：メディア> <情報：メディアID = "2"> <INFO：ラベル> 456 </情報：ラベル> <情報：状態> SENDRECV </情報：状態> </情報：メディア> </情報：エンドポイント> </情報：ユーザー> </情報：ユーザー> </情報：会議-インフォメーション>

Figure 24: A Call-Center Conference Object Example

図24：コール・センター会議オブジェクトの例

Alice                   Bob                    ConfS
  |                      |                       |
  |(1) sidebarByRefRequest(confUserID,           |
  |                 confObjID, create)           |
  |--------------------------------------------->|
  |                      |                       |
  |                      |        (a) Create +---|
  |                      |    sidebar-by-ref |   |
  |                      |     (new conf obj |   |
  |                      |       cloned from +-->|
  |                      |        confObjID)     | Sidebar now has
  |                      |                       | id confObjID*
  |(2) sidebarByRefResponse(confUserID,          | (parent mapping
  |      confObjID*,create,200,success,          | conf<->sidebar)
  |           version,sidebarByRefInfo)          |
  |<---------------------------------------------|
  |                      |                       |
  |(3) sidebarByRefRequest(confUserID,           |
  |      confObjID*,update,sidebarByRefInfo)     |
  |--------------------------------------------->|
  |                      |                       |
  |                      |        (b) Update +---|
  |                      |    sidebar-by-val |   |
  |                      |     (media, users |   |
  |                      |     policy, etc.) +-->|
  |                      |                       | Sidebar is modified:
  |                      |                       | unilateral sidebar
  |                      |                       | audio, Carol excluded
  |                      |                       | from the sidebar
  |(4) sidebarByRefResponse(confUserID,          |
  |                 confObjID*, update,          |
  |               200, success, version)         |
  |<---------------------------------------------|
  |                      |                       |
  |                      |         Notify (Bob   |
  |                      |    he's been added to |
  |                      |        sidebar users) |
  |                      |<----------------------|
  |                      |                       |
  '                      '                       '
  '                      '                       '
  '                      '                       '

Figure 25: Supervisor Creating a Sidebar for Observing/Coaching

図25：スーパーバイザは、観察するためのサイドバーの作成/コーチング

1. Upon receipt of the sidbarByRefRequest/create message from Alice to create a new sidebar conference from the <confObjID> received in the request, the conference server uses the received active conference to clone a conference reservation for the sidebar. The conference server also allocates a new XCON-URI to be used for any subsequent protocol requests directed to the new sidebar. The conference server maintains the mapping between this sidebar conference ID and the one associated with the main conference instance. The conference server sends a sidebarByRefResponse message with the new XCON-URI in the <confObjID> field and other relevant information in the <sidebarByRefInfo>.

sidbarByRefRequestを受信すると1 / <confObjID>から新しいサイドバー会議を作成するために、アリスからのメッセージを作成する要求で受信し、会議サーバは、サイドバーのための会議予約をクローニングするために、受信したアクティブな会議を使用します。会議サーバは、新しいXCON-URIは、新しいサイドバーに向け、後続のプロトコル要求のために使用されるように割り当てられます。会議サーバは、このサイドバー会議IDとメイン会議インスタンスに関連する一つとの間のマッピングを維持します。会議サーバは、<sidebarByRefInfo>で<confObjID>フィールドに新しいXCON-URIおよびその他の関連情報をsidebarByRefResponseメッセージを送信します。

2. Upon receipt of the sidebarByRefResponse message, Alice manipulates the data received in the <sidebarByRefInfo> in the response. Alice wants only Bob to be involved in the sidebar; thus, she updates the <allowed-users-list> to include only Bob and herself. 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 sidebarByRefRequest message with an "update" <operation> including the updated sidebar information in the <sidebarByRefInfo> element.

sidebarByRefResponseメッセージを受信2.、アリスは、応答の<sidebarByRefInfo>で受信したデータを操作します。アリスはボブがサイドバーに関与することを希望します。このように、彼女はボブと彼女自身を含めて、<許可ユーザ・リスト>を更新します。アリスはまた、音声はオリジナルの会議から自分とボブによって受信されることを希望するが、ボブの送信音声がメインの会議に行くべき一方で、サイドバーの参加者に限定される彼女自身からすべての発信オーディオを望んでいるので、アリスの両方と顧客キャロルは、ボブから同じ音声を聞きます。アリスは<sidebarByRefInfo>要素内の更新サイドバーの情報を含む「更新」<動作>とsidebarByRefRequestメッセージを送信します。

3. Upon receipt of the sidebarByRefRequest/update message, the conference server ensures that Alice has the appropriate authority based on the policies associated with that specific conference object to perform the operation. In order to request the insertion of a further media stream in the sidebar (i.e., in this example an audio stream from Alice to Bob), the requester has to provide a new <entry> element in the <available-media> field of the <sidebarByRefInfo>. The mandatory 'label' attribute of that new <entry> is filled with a dummy value "AUTO_GENERATE_1", but it will contain the real server-generated media stream identifier when the media stream is effectively allocated on the server side. Similarly, the mandatory 'id' attribute in the <media> element referring to the new sidebar audio stream under both Alice's and Bob's <endpoint> contains a wildcard value, respectively, "AUTO_GENERATE_2" and "AUTO_GENERATE_3": those values will be replaced with the appropriated server-generated identifiers upon the creation of the referred media stream. We are assuming the conference server is able to recognize those dummy values as placeholders.

sidebarByRefRequest /更新メッセージを受信すると3は、会議サーバは、アリスが操作を実行するために、その特定の会議オブジェクトに関連付けられたポリシーに基づいて適切な権限を持っていることを保証します。サイドバーでさらにメディアストリーム（ボブにアリスから、すなわち、この例では、オーディオストリーム）の挿入を要求するために、要求者は、<利用可能なメディア>フィールドに新しい<entry>要素を提供しなければなりません<sidebarByRefInfo>。その新しい<エントリー>の必須「ラベル」属性はダミー値「AUTO_GENERATE_1」で満たされているが、メディア・ストリームを効果的にサーバー側で割り当てられた場合には、実サーバが生成するメディアストリーム識別子が含まれています。同様に、両方のアリスとボブの下に新しいサイドバーのオーディオストリームを参照する<メディア>要素で必須「ID」属性は、<エンドポイント>は、それぞれ、ワイルドカード値が含まれている、「AUTO_GENERATE_2」と「AUTO_GENERATE_3は」：これらの値が置き換えられます呼ばメディアストリームの作成時に、サーバが生成した識別子を充当。私たちは、会議サーバは、プレースホルダとして、これらのダミーの値を認識することが可能であると仮定しています。

4. After validating the data, the conference server sends a sidebarByRefResponse message. Based upon the contact 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. 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.

4.データを検証した後、会議サーバはsidebarByRefResponseメッセージを送信します。アリスによってボブのために設けられたコンタクト情報に基づいて、適切なメディア特性を有するサイドバーにボブを追加するコールシグナリングは、フォーカスを介して扇動されます。ボブは、会議通知サービスを経由してサイドバーに自分以外が通知されます。このように、彼はアリス、スーパーバイザは、この呼び出しを通じて彼をコーチングのために利用可能であることを認識しています。

1. sidebarByRefRequest/create message (Alice as coach creates a sidebar)

1. sidebarByRefRequest /（コーチは、サイドバーを作成するようにアリス）メッセージを作成

2. sidebarByRefResponse/create message (sidebar created)

2. sidebarByRefResponse /メッセージを作成します（サイドバーが作成）

<info:status>sendrecv</info:status> </info:entry> <info:entry label="456"> <info:display-text> main conference video </info:display-text> <info:type>video</info:type> <info:status>sendrecv</info:status> </info:entry> </info:available-media> <xcon:sidebar-parent> xcon:8971313@example.com </xcon:sidebar-parent> </info:conference-description> <info:conference-state> <info:active>false</info:active> </info:conference-state> <info:users> <xcon:allowed-users-list> <xcon:target method="dial-in" uri="xcon-userid:alice@example.com"/> <xcon:target method="dial-in" uri="xcon-userid:bob@example.com"/> <xcon:target method="dial-in" uri="xcon-userid:carol@example.com"/> </xcon:allowed-users-list> </info:users> </sidebarByRefInfo> </ccmp:sidebarByRefResponse> </ccmpResponse> </ccmp:ccmpResponse>

<情報：状態> SENDRECV </情報：状態> </情報：エントリ> <情報：エントリラベル= "456"> <情報：表示テキスト>メイン会議ビデオ</情報：表示テキスト> <情報：タイプ>ビデオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> </情報：利用可能メディア> <XCON：サイドバーの親> [XCON 8971313@example.com </ XCON：サイドバーの親> </情報：会議-記述> <情報：会議状態> <情報：アクティブ>偽</情報：アクティブ> </情報：会議状態> <情報：ユーザー> <XCON：許可-usersリスト> <XCON：ターゲット・メソッド= "ダイヤルイン" のuri = "XCON-ユーザーID：alice@example.com" /> <XCON：ターゲット・メソッド= "ダイヤルイン" URIは= "XCON-ユーザーID：ボブ@ example.com "/> <XCON：ターゲット・メソッド=" ダイヤルイン」のuri = "XCON-ユーザーID：carol@example.com" /> </ XCON：許可ユーザー・リスト> </情報：ユーザー> < / sidebarByRefInfo> </ CCMP：sidebarByRefResponse> </ ccmpResponse> </ CCMP：ccmpResponse>

3. sidebarByRefRequest/update message (Alice introduces unilateral sidebar audio and excludes Carol from the sidebar)

3. sidebarByRefRequest /更新メッセージ（アリスが片側サイドバーオーディオを導入し、サイドバーからキャロルを除きます）

<ccmp:ccmpRequest xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info" xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"> <ccmpRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-sidebarByRef-request-message-type"> <confUserID>xcon-userid:alice@example.com</confUserID> <confObjID>xcon:8971313@example.com</confObjID> <operation>update</operation> <ccmp:sidebarByRefRequest> <sidebarByRefInfo entity="xcon:8971313@example.com">

<CCMP：ccmpRequestののxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-情報" のxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP = "壷：IETF：paramsは：XML：NS：XCON：CCMP "> <ccmpRequestのxmlns：XSI =" http://www.w3.org/2001/XMLSchema-instance "XSI：タイプ=" CCMP：CCMP-sidebarByRef、要求 - メッセージタイプ "> <confUserID> XCON-ユーザーID：alice@example.com </ confUserID> <confObjID> [XCON 8971313@example.com </ confObjID> <動作>更新</動作> <CCMP：sidebarByRefRequest> <sidebarByRefInfo実体= "XCON：8971313@example.com">

<info:conference-description> <info:display-text> Coaching sidebar Alice and Bob </info:display-text> <info:available-media> <info:entry label="AUTO_GENERATE_1"> <info:display-text> Alice-to-Bob audio </info:display-text> <info:type>audio</info:type> <info:status>sendrecv</info:status> </info:entry> </info:available-media> </info:conference-description> <info:conference-state> <info:active>false</info:active> </info:conference-state> <info:users> <info:user entity="xcon-userid:alice@example.com"> <info:endpoint entity="sip:alice@example.com"> <info:media id="AUTO_GENERATE_2"> <info:label>AUTO_GENERATE_1</info:label> <info:status>sendonly</info:status> </info:media> </info:endpoint> </info:user> <info:user entity="xcon-userid:bob@example.com"> <info:endpoint entity="sip:bob@example.com"> <info:media id="AUTO_GENERATE_3"> <info:label>AUTO_GENERATE_1</info:label> <info:status>recvonly</info:status> </info:media> </info:endpoint> </info:user> <xcon:allowed-users-list> <xcon:target method="dial-in" uri="xcon-userid:alice@example.com"/> <xcon:target method="dial-out" uri="xcon-userid:bob@example.com"/> </xcon:allowed-users-list> </info:users> </sidebarByRefInfo> </ccmp:sidebarByRefRequest> </ccmpRequest> </ccmp:ccmpRequest>

<情報：会議-記述> <情報：表示テキスト>コーチングのサイドバーアリスとボブ</情報：表示テキスト> <情報：使用可能なメディア> <情報：エントリラベル= "AUTO_GENERATE_1"> <情報：表示テキスト>アリス・ツー・ボブ・オーディオ</情報：表示テキスト> <情報：タイプ>オーディオ</情報：タイプ> <情報：状態> SENDRECV </情報：状態> </情報：エントリ> </情報：利用可能-media> </情報：会議-記述> <情報：会議状態> <情報：アクティブ>偽</情報：アクティブ> </情報：会議状態> <情報：ユーザー> <情報：ユーザエンティティ=」 XCON-ユーザーID：alice@example.com "> <情報：エンドポイント実体=" 一口：alice@example.com "> <情報：メディアID =" AUTO_GENERATE_2" > <INFO：ラベル> AUTO_GENERATE_1 </情報：ラベル> <情報：状態> sendonlyの</情報：状態> </情報：メディア> </情報：エンドポイント> </情報：ユーザー> <情報：ユーザエンティティ= "XCON-ユーザーID：bob@example.com"> <情報：エンドポイントの実体= "一口：bob@example.com"> <情報：メディアID = "AUTO_GENERATE_3"> <INFO：ラベル> AUTO_GENERATE_1 </情報：ラベル> <情報：状態>がrecvonly </情報：状態> </情報：メディア> </情報：エンドポイント> </情報：ユーザー> <XCON：許可ユーザー・リスト> <XCON：ターゲット・メソッド=」ダイヤルイン」のuri = "XCON-ユーザーID：alice@example.com" /> <XCON：ターゲットメソッド= "ダイヤルアウト" のuri = "XCON-ユーザーID：bob@example.com" /> </ XCON：許可-usersリスト> </情報：ユーザー> </ sidebarByRefInfo> </ CCMP：sidebarByRefRequest> </ ccmpRequest> </ CCMP：ccmpRequest>

4. sidebarByRefRequest/update message (updates accepted)

4. sidebarByRefRequest /更新メッセージ（更新可）

Figure 26: Coaching and Observing Messaging Details

図26：コーチングと観測メッセージング詳細

8. Removing Participants and Deleting Conferences

8.参加者を削除し、会議を削除

The following scenarios detail the basic operations associated with removing participants from conferences and entirely deleting conferences. The examples assume that a conference has already been correctly established, with media, if applicable, per one of the examples in Section 5.

次のシナリオの詳細を会議から参加者を除去し、全体会議の削除に関連付けられている基本的な操作。例が該当する場合、会議がすでに正常に第5節で例の一つにつき、メディアで、確立されたことを前提としています。

8.1. Removing a Party

8.1. パーティーを削除します

Figure 27 provides an example of a client, Alice, removing another participant, Bob, from a conference. This example assumes an established conference with Alice, Bob, Claire, and Duck. In this example, Alice wants to remove Bob from the conference so that the group can continue in the same conference without Bob's participation.

図27は、会議から別の参加者、ボブ、削除、クライアント、アリスの例を提供します。この例では、アリス、ボブ、クレア、およびアヒルとの確立された会議を想定しています。この例では、アリスは、グループがボブの参加せず、同じ会議に継続できるように会議からボブを削除したいです。

   Alice            Bob       Claire       ConfS
     |               |           |           |
     |(1) userRequest(confUserID,|           |
     |         confObjID, delete,|           |
     |         userInfo)         |           |
     |-------------------------------------->|
     |               |           |           |
     |               |           | (a) Focus |
     |               |           | tears down|
     |               |           | signaling |
     |               |           |  to Bob   |
     |               |<----------------------|
     |               |                       |
     |               |         (b)Deletes+---|
     |               |           | Bob   |   |
     |               |           | as a  |   |
     |               |           | user  +-->|
     |               |           | in        |
     |               |           | confObj   |
     |               |           |           |
     |(2) userResponse(confUserID,confObjID, |
     |           delete,200,success,version) |
     |<--------------------------------------|
     |               |           |           |
     |               |           |           |
     |               |           | (c) Notify|
     |               |           | ("Bob just|
     |               |           |  left")   |
     |               |           |<----------|
     |               |           |           |
     '               '           '           '
     '               '           '           '
     '               '           '           '

Figure 27: Client Manipulation of Conference - Remove a Party

図27：会議のクライアントの操作 - パーティーを削除

1. Alice sends a userRequest message with a "delete" <operation>. The conference server ensures that Alice has the appropriate authority based on the policies associated with that specific conference object to perform the operation.

1.アリスは、<操作>「削除」とuserRequestメッセージを送信します。会議サーバは、アリスが操作を実行するために、その特定の会議オブジェクトに関連付けられたポリシーに基づいて適切な権限を持っていることを保証します。

2. Based upon the contact and media information in the conference object for Bob in the <userInfo> element, the conferencing system starts the process to remove Bob (e.g., the call signaling to remove Bob from the conference is instigated through the focus). The conference server updates the data in the conference object, thus, removing Bob from the <users> list. After updating the data, the conference server sends a userResponse message to

2. <ユーザー情報>要素内のボブのための会議オブジェクトに接触し、メディア情報に基づいて、会議システム（例えば、会議からボブを除去するための呼シグナリングは、フォーカスを介して扇動される）ボブを除去するための処理を開始します。会議サーバは、<ユーザー>リストからボブの除去、したがって、会議オブジェクト内のデータを更新します。データを更新した後、会議サーバはにuserResponseメッセージを送信します

       Alice.  Depending upon the policies, other participants (e.g.,
       Claire) may be notified of the removal of Bob from the conference
       via the conference notification service.

1. userRequest/delete message (Alice deletes Bob)

1. userRequest /（アリスがボブを削除）メッセージを削除

2. userResponse/delete message (Bob has been deleted)

2. userResponse /メッセージを削除（ボブが削除されています）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-user-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>delete</operation> <response-code>200</response-code> <response-string>success</response-string> <version>17</version> <ccmp:userResponse/> </ccmpResponse> </ccmp:ccmpResponse>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpResponseののxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-ユーザ応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8977794 @ example.com </ confObjID> <操作> </操作> <レスポンスコード> 200 </レスポンスコード> <レスポンス文字列>成功</レスポンス文字列> <バージョン> 17 </バージョン> <CCMPを削除します。 userResponse /> </ ccmpResponse> </ CCMP：ccmpResponse>

Figure 28: Removing a Participant Messaging Details

図28：参加者のメッセージ詳細を削除します

8.2. Deleting a Conference

8.2. 会議を削除します

In this section, an example of a successful conference deletion is provided (Figure 29).

このセクションでは、成功した会議の削除の例は（図29）が設けられています。

   Alice                          ConfS
    |                               |
    |(1)confRequest(confUserID,     |
    |       confObjID, delete)      |
    |------------------------------>|
    |                 (a)Delete +---|
    |                    Conf   |   |
    |                    Object |   |
    |                           +-->|
    |                               |--+ (b) MS
    |                               |  | removes related
    |                               |  | mixer instances and
    |                               |<-+ their participants
    |                               |    (SIP signaling as well)
    |                               |
    |(2)confResponse(confUserID,    |
    |      confObjID,delete,200,    |
    |      success)                 |
    |                               |
    |<------------------------------|
    |                               |
    '                               '

Figure 29: Deleting a Conference

図29：会議を削除します

1. The conferencing system client Alice sends a confRequest message with a "delete" operation to be performed on the conference identified by the XCON-URI carried in the <confObjID> parameter. The conference server, on the basis of the <confUserID> included in the receipt request, ensures that Alice has the appropriate authority to fulfill the operation.

1.会議システムのクライアントアリスは「削除」操作でconfRequestメッセージを送るには、<confObjID>パラメータで運ばXCON-URIによって識別される会議で行うことができます。会議サーバは、<confUserID>領収書要求に含まれるに基づいて、アリスは操作を満たすために適切な権限を持っていることを保証します。

2. After validating Alice's rights, the conference server instigates the process to delete the conference object, disconnecting participants and removing associated resources such as mixer instances. Then, the conference server returns a confResponse message to Alice with "200" as <response-code> and the deleted conference XCON-URI in the <confObjID> field.

2.アリスの権利を検証した後、会議サーバは、参加者を切断して、そのようなミキサーのインスタンスなどの関連するリソースを削除し、会議オブジェクトを削除するプロセスを扇動します。その後、会議サーバは、<レスポンスコード>と<confObjID>フィールド内の削除会議XCON-URIである「200」とアリスへconfResponseメッセージを返します。

1. confRequest/delete message (Alice deletes a conference)

1. confRequest /削除メッセージ（アリスは、会議を削除します）

2. confResponse/delete message ("200", "success")

2. confResponse /メッセージを削除（ "200"、 "成功"）

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ccmp:ccmpResponse xmlns:info="urn:ietf:params:xml:ns:conference-info" xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp" xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info"> <ccmpResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ccmp:ccmp-conf-response-message-type"> <confUserID>xcon-userid:Alice@example.com</confUserID> <confObjID>xcon:8977794@example.com</confObjID> <operation>delete</operation> <response-code>200</response-code> <response-string>success</response-string> <ccmp:confResponse/> </ccmpResponse> </ccmp:ccmpResponse>

<？xml version = "1.0" エンコード= "UTF-8" スタンドアロン= "はい"？> <CCMP：ccmpResponseののxmlns：情報= "壷：IETF：のparams：XML：NS：会議-情報" のxmlns：CCMP =」 URN：IETF：のparams：XML：NS：XCON：CCMP "のxmlns：XCON = "壷：IETF：のparams：XML：NS：XCON-会議-INFO"> <ccmpResponseののxmlns：XSI =" のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス」のxsi：タイプ= "CCMP：CCMP-CONF-応答メッセージ型"> <confUserID> XCON-ユーザーID：Alice@example.com </ confUserID> <confObjID> XCON：8977794 @ example.com </ confObjID> <操作>削除</操作> <レスポンスコード> 200 </レスポンスコード> <レスポンス文字列>成功</レスポンス文字列> <CCMP：confResponse /> </ ccmpResponse> < / CCMP：ccmpResponse>

Figure 30: Deleting a Conference Messaging Details

図30：会議メッセージング詳細を削除します

9. Security Considerations

9.セキュリティの考慮事項

The security considerations applicable to the implementation of these call flows are documented in the XCON framework, with additional security considerations documented in the CCMP document. Statements with regard to the necessary security are discussed in particular flows; however, this is for informational purposes only. The implementer is encouraged to carefully consider the security requirements in the normative documents.

これらのコールフローの実装に適用されるセキュリティ上の考慮事項は、CCMPの文書に記載追加のセキュリティを考慮して、XCONフレームワークに記載されています。必要なセキュリティに関する声明は、特定のフローに記載されています。しかし、これは情報提供のみを目的としています。実装者は慎重規範文書のセキュリティ要件を考慮することが奨励されます。

10. Acknowledgements

10.謝辞

The detailed content for this document is derived from the prototype work of Lorenzo Miniero, Simon Pietro Romano, Tobia Castaldi, and their colleagues at the University of Napoli.

このドキュメントの詳細な内容は、ロレンツォMiniero、サイモン・ピエトロロマーノ、トビアCastaldi、そしてナポリ大学の同僚のプロトタイプの仕事から派生しています。

11. References

11.参考文献

11.1. Normative References

11.1. 引用規格

[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.

[RFC5239]バーンズ、M.、ボールトン、C.、およびO.レヴィン、 "集中型会議のためのフレームワーク"、RFC 5239、2008年6月。

[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012.

[RFC6501]ノボ、O.、カマリロ、G.、モルガン、D.、およびJ. Urpalainen、RFC 6501、2012年3月 "の集中会議（XCON）のための会議情報データモデル"。

[RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, March 2012.

[RFC6502]キャマリロ、G.、スリニバサン、S.、でも、R.、およびJ. Urpalainen、RFC 6502、2012年3月 "の集中会議（XCON）のための会議イベントパッケージのデータ形式の拡張子"。

[RFC6503] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, March 2012.

[RFC6503]バーンズ、M.、ボールトン、C.、ロマーノ、S.、およびH. Schulzrinneと、 "一元会議操作プロトコル"、RFC 6503、2012年3月。

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.

[W3C.REC-XML-20081126]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.、MALER、E.、およびF. Yergeau、 "拡張マークアップ言語（XML）1.0（第5版）"、 World Wide Web Consortium（W3C）の勧告REC-XML-20081126、2008年11月、<http://www.w3.org/TR/2008/REC-xml-20081126>。

11.2. Informative References

11.2. 参考文献

[CALL-FLOWS] Amirante, A., Castaldi, T., Miniero, L., and S. Romano, "Media Control Channel Framework (CFW) Call Flow Examples", Work in Progress, July 2011.

[CALL-フロー] Amirante、A.、Castaldi、T.、Miniero、L.、およびS.ロマーノ、 "メディア制御チャネルフレームワーク（CFW）はフローの例を呼び出す"、進歩、2011年7月での作業。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。

[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.

[RFC4575]ローゼンバーグ、J.、Schulzrinneと、H.、およびO.レヴィン、 "Aセッション開始プロトコル（SIP）の会議の状態のためのイベントパッケージ"、RFC 4575、2006年8月。

[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.

[RFC4579]ジョンストン、A.、およびO.レヴィン、 "セッション開始プロトコル（SIP）呼制御 - ユーザエージェントのための会議"、BCP 119、RFC 4579、2006年8月。

[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.

[RFC4582]キャマリロ、G.、オット、J.、およびK.糖剤、 "バイナリフロア制御プロトコル（BFCP）"、RFC 4582、2006年11月。

[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.

[RFC4597]であっても、R.とN.イスマイル、 "会議のシナリオ"、RFC 4597、2006年8月。

[RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.

[RFC5567] Melanchuk、T.、 "メディアサーバ制御のためのアーキテクチャーのフレームワーク"、RFC 5567、2009年6月。

[RFC6505] McGlashan, S., Melanchuk, T., and C. Boulton, "A Mixer Control Package for the Media Control Channel Framework", RFC 6505, March 2012.

[RFC6505] McGlashan、S.、Melanchuk、T.、およびC.ボールトン、 "メディア制御チャネルフレームワークのためのミキサーコントロールパッケージ"、RFC 6505、2012年3月。

Authors' Addresses

著者のアドレス

Mary Barnes Polycom TX USA

メアリー・バーンズポリコムTX USA

EMail: mary.ietf.barnes@gmail.com

メールアドレス：mary.ietf.barnes@gmail.com

Lorenzo Miniero Meetecho Via Carlo Poerio 89/a Napoli 80121 Italy

ロレンツォMiniero Meetecho経由カーロ・ポアーリオ80121分の89ナポリイタリア

EMail: lorenzo@meetecho.com

メールアドレス：lorenzo@meetecho.com

Roberta Presta University of Napoli Via Claudio 21 Napoli 80125 Italy

クラウディオ21 80125ナポリイタリアViaナポリのロベルタ仏式大学

EMail: roberta.presta@unina.it

メールアドレス：roberta.presta@unina.it

Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy

ナポリのシモン・ペテロロマーノ大学経由クラウディオ21 80125ナポリイタリア

EMail: spromano@unina.it

メールアドレス：spromano@unina.it