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
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
集中式会议操作协议（CCMP）呼叫流示例
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批准的所有文件都适用于任何级别的互联网标准；见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.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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 ....................................................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
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消息传递功能丰富的概述。
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-FLOWS]中相同的术语，调用流中使用以下术语和缩写。此外，请注意，本文件中使用的术语“呼叫流”具有非常一般的含义，因为媒体不限于语音。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在逻辑上等同于在媒体控制调用流[call-flows]中使用用户代理客户端（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.
会议服务器（ConfS）：在本文档中，术语“会议服务器”可与媒体控制体系结构框架[RFC5567]中使用的术语“应用服务器（AS）”互换使用。会议服务器旨在充当XCON框架中定义的会议控制服务器，即，它能够处理CCMP请求并发出CCMP响应。
Media Server (MS): as defined in the media control architectural framework [RFC5567].
媒体服务器（MS）：如媒体控制体系结构框架[RFC5567]中所定义。
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.
本文档提供了详细调用流的示例，这些调用流可以基于XCON框架[RFC5239]的系统实现和CCMP[RFC6503]的实现来实现。这是会议服务器和会议控制客户端之间使用会议控制协议的简单指南。目的是为协议开发人员、软件开发人员和研究人员提供信息基础参考。
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]、呼叫信令或二进制地板控制协议（BFCP）[RFC4582]的详细信息。本文档参考了媒体控制呼叫流[call-flows]、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节概述了CCMP，以及一些与实现相关的细节和相关事项，如HTTPS传输和通知。第5节向读者展示了CCMP提供的创建新会议的不同方法的示例。第6节更一般地介绍了通过CCMP可以实现的与用户相关的不同操作，提供了许多有趣的场景。第7节讨论了可能涉及使用边栏的几个场景。第8节说明了如何使用CCMP从系统中删除会议和用户。最后，第9节提供了实现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
本节简要介绍了集中式会议操作协议（CCMP）[RFC6503]的工作原理以及如何在网络上传输。关注客户机-服务器通信相关方面的典型CCMP交互是
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文件。本节旨在帮助读者理解实际的协议交互。
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节中，通过将HTTPS用作传输，介绍了有效的CCMP交互。最后，第4.3节介绍了通知。
The document then presents and describes some actual flows in detail in the sections to follow.
然后，本文档在接下来的章节中详细介绍和描述了一些实际流程。
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是一个基于XML的协议[W3C.REC-XML-20081126]。它被设计成一个请求/响应协议。它是完全无状态的，这意味着实现可以彼此独立地安全地处理事务。
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
虽然CCMP充当操纵会议对象的手段，但CCMP不定义这些会议对象。单独的文档指定如何构造会议对象及其所有组件（集中式会议的会议信息数据模型（XCON）[RFC6501]）。根据请求类型和相关操作，CCMP承载根据上述协议的多个会议对象（或任何对象作为一个整体）
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请求并携带错误的会议对象注定会导致失败。因此，建议感兴趣的实现人员在仔细检查数据模型处理程序时特别小心，以避免潜在的错误。
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用户无法在会议对象中分配数据模型中的强制元素。例如，中国移动可能要求直接创建新的会议；在这种情况下，会议对象假定一个“实体”属性，该属性唯一地标识将要召开的会议。因此，中国移动无法事先知道该实体是什么，因为它是在请求后由CONF生成的。对于这种情况，CCMP规范描述了使用专用占位符通配符（即“AUTO_GENERATE_X”，其中X是整数）使会议对象符合数据模型：然后，通配符将被具有正确值的CONF替换。
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消息的一部分发送，CONF将以200 OK HTTPS响应进行回复。在这两种情况下，HTTPS消息都携带CCMP消息作为有效负载，这反映在内容类型头（“应用程序/CCMP+xml”）中。图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 |
| |
' '
' '
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").
根据以下行中的协议转储，中国移动已向CONF发出CCMP请求（blueprintRequest消息，要求检索蓝图，即，<operation>元素设置为“retrieve”）。请求已作为HTTPS POST（消息1.）的有效负载携带到先前已知的位置。已指定必需的主机头，并且内容类型头也已正确设置（“应用程序/ccmp+xml”）。
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").
会议依次处理了请求并作出了相应的答复。响应（blueprintResponse消息，其<response code>设置为成功值“200”）已作为200 OK HTTPS响应（消息2.）的有效负载进行传输。与前面一样，内容类型标头已正确设置（“应用程序/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)
1. CMCC->ConfS（HTTPS POST，CCMP请求）--------------------------------------POST/Xcon/CCMP HTTP/1.1内容长度：657内容类型：应用程序/CCMP+xml主机：example.com:443连接：保持活动用户代理：Apache HttpClient/4.0.1（java 1.5）
<?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-blueprint-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-blueprint-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:AudioRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
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
2. 中国移动通信公司<-ConfS（200-to-POST，CCMP-response）-------------------------------------------------------------HTTP/1.1 200 OK X-Powered-By:Servlet/2.5服务器：Sun GlassFish通信服务器1.5内容类型：应用程序/CCMP+xml；字符集=ISO-8859-1内容长度：1652日期：2010年2月4日星期四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" 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>
</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>
</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>
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>：该元素由中国移动提供，通过其XCON-USERID指向请求者；除少数情况（在以下部分中介绍）外，此元素必须始终包含有效值；
o <confObjID>: this element refers to the target conference object,
according to the request in place;
o <confObjID>: this element refers to the target conference object,
according to the request in place;
o <operation>: this element specifies the operation the CMCC wants to perform, according to the specific request type.
o <operation>：此元素根据特定请求类型指定中国移动希望执行的操作。
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.
除了这些元素之外，CMCC（比如Alice，其XCON-USERID为“XCON USERID:Alice@example.com）还提供了一个附加元素，<blueprintRequest>。该元素的名称因中国移动感兴趣的请求类型而异。在这一特定场景中，中国移动有兴趣获取有关特定蓝图的详细信息（由其XCON-URI“XCON:AudioRoom@example.com，反映在提供的<confObjID>目标元素中），因此请求包含在空的<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消息，ConfS已经用包含<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.
在不提供该交互的其他细节的情况下，值得注意的是，这是中国移动通信公司和ConfS之间可能发生的最简单的CCMP通信示例，蓝图请求：该场景将在第5.2节中进行更详细的描述。
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实现中的呼叫信令协议时，必须支持XCON事件包[RFC6502]，它扩展了会议状态[RFC4575]的SIP事件包。SIP客户端使用XCON事件包的SIP 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 |
| |<--------------------------|
| | |
' ' '
' ' '
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消息传递详细信息。
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
本节提供了与使用CCMP和XCON框架构造创建会议的各种方式相关的详细信息。如前所述，媒体控制、呼叫信令和楼层控制协议的细节（如适用）在流中注释，而不显示所有细节。这也适用于CCMP，其流仅与协议相关，隐藏可能已使用的传输的任何细节（例如HTTPS）。然而，为了澄清起见，第5.1节中的第一个示例提供了媒体控制消息的详细信息，以及本文件其余部分中使用的标准注释。在随后的流中，只有这个
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.
包括注释（用小写字母标识），鼓励读者参考相关文档中的调用流以了解其他协议的详细信息。呼叫信令的注释位于会议服务器垂直条的左侧，媒体控制消息的注释位于右侧。
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消息，将<operation>元素设置为“create”作为唯一参数，同时发送与请求客户端自身关联的<confUserID>。这将导致创建一个默认会议，其中XCON-URI以<confObjID>元素的形式出现，XCON-USERID以<confUserID>元素的形式出现（请求中已经存在相同的元素），而<confInfo>参数中会议对象的数据都在confResponse消息中返回。此示例还将在创建时将发出用户添加到会议，并将<allowed users list>的<target>子元素中的“method”属性设置为“dial out”。
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>元素中返回新的会议数据不是强制性的：如果的<confInfo>参数未包含在成功的confResponse/create消息中，可以触发返回的<confObjID>的后续confRequest/retrieve消息，以向请求客户端提供详细的会议描述。
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的客户端可以使用特定的信令接口（如SIP[RFC3261]（使用[RFC4579]中所述的会议焦点的信令接口）或其他支持的信令协议（与XCON无关）加入会议。但是，这些详细信息没有显示在消息流中。本文档中的消息流通过小写字母项（即，（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.
如前所述，该示例还显示了会议系统如何利用其他标准协议组件实现完整功能。媒体控制框架[RFC5567]就是一个例子，它允许会议系统配置会议混音、交互式语音应答（IVR）对话框以及类似应用程序可能需要的各种媒体相关交互。为了向读者提供关于这些交互的一些见解，本示例中的会议服务器还通过媒体控制通道在创建会议时配置和启动混频器（事务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. | *****|
' ' ' ' '
' ' ' ' '
' ' ' ' '
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：创建基本会议-完整流程
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. confResponse/create message ("success", created conference object returned)
2. 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>
Default conference initiated by Alice
</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>
<?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>
Default conference initiated by Alice
</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>
</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>
</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>
Figure 4: Create Basic Conference Detailed Messaging
图4：创建基本会议详细消息
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.
前面的示例显示了使用默认值创建新会议的过程。这意味着客户没有提供关于如何创建会议的信息。XCON框架（以及CCMP）允许实现模板。这些模板称为“会议蓝图”，基本上是具有预定义设置的会议对象。这意味着客户可能会得到一份蓝图列表，选择最适合自己需要的蓝图，并使用所选蓝图创建新的会议。
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提供了一个客户机Alice的示例，它发现了可用于特定会议系统的会议蓝图，并基于所需蓝图创建了一个会议。特别是，Alice对那些适合表示视频会议的蓝图感兴趣，即音频和视频都可用的会议，因此她利用CCMP提供的过滤机制提出选择性蓝图检索请求。这将导致三个不同的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) |
|<------------------------------|
| |
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. Alice首先向会议服务器发现过程标识的会议服务器发送blueprintsRequest消息。此请求包含设置为发出请求的用户（在本例中，是属于Alice的用户）的XCON-USERID的<confUserID>和<xpathFilter>元素，Alice通过该元素指定她只希望获得提供音频和视频支持的蓝图：为此，此字段中包含的xpath查询为：“/conference info[会议说明/可用媒体/条目/类型='audio'和会议说明/可用媒体/条目/类型='video']“。在收到blueprintsRequest消息后，会议服务器将首先根据<confUserID>参数确保Alice具有基于系统策略的适当权限，以接收该系统支持的请求类型的蓝图。
2. All blueprints that Alice is authorized to use are returned in a blueprintsResponse message in the <blueprintsInfo> element.
2. Alice被授权使用的所有蓝图将在<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>.
3. 在收到包含蓝图的blueprints响应消息后，Alice确定用于创建会议的蓝图。Alice发送blueprintRequest消息以获取由<confObjID>标识的特定蓝图。
4. The conference server returns the details associated with the specific blueprint identified by the <confObjID> in the <confInfo> element within the blueprintResponse message.
4. 会议服务器返回与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. Alice最后向会议服务器发送一条带有“create”<operation>的confRequest消息，以创建一个会议预约，克隆所选的蓝图。这是通过在<confObjID>参数中写入blueprint的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.
6. 在收到confRequest/create消息后，会议服务器使用收到的蓝图克隆会议，分配新的XCON-URI（在本例中称为“confObjID*”）。然后，会议服务器发送confResponse消息，其中包括与新创建的会议实例关联的新“ConfBjID*”作为<ConfBjID>参数的值。收到confResponse消息后，Alice现在可以向会议添加其他用户。
1. blueprintsRequest message (Alice requires the list of the available blueprints with video support)
1. blueprintsRequest消息（Alice需要具有视频支持的可用蓝图列表）
<?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-blueprints-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<ccmp:blueprintsRequest>
<xpathFilter>/conference-info[conference-description/
available-media/entry/type='audio'
and
conference-description/available-media/entry/type='video']
</xpathFilter>
</ccmp:blueprintsRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-blueprints-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<ccmp:blueprintsRequest>
<xpathFilter>/conference-info[conference-description/
available-media/entry/type='audio'
and
conference-description/available-media/entry/type='video']
</xpathFilter>
</ccmp:blueprintsRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
2. blueprintsResponse message (the server provides a descriptions of the available blueprints fitting Alice's request)
2. 蓝图响应消息（服务器提供符合Alice请求的可用蓝图的描述）
<?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-blueprints-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintsResponse>
<blueprintsInfo>
<info:entry>
<info:uri>xcon:VideoRoom@example.com</info:uri>
<info:display-text>VideoRoom</info:display-text>
<info:purpose>Video Room:
conference room with public access,
where both audio and video are available,
4 users can talk and be seen at the same time,
and the floor requests are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<?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-blueprints-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintsResponse>
<blueprintsInfo>
<info:entry>
<info:uri>xcon:VideoRoom@example.com</info:uri>
<info:display-text>VideoRoom</info:display-text>
<info:purpose>Video Room:
conference room with public access,
where both audio and video are available,
4 users can talk and be seen at the same time,
and the floor requests are automatically accepted.
</info:purpose>
</info:entry>
<info:entry>
<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>
<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>
3. blueprintRequest/retrieve message (Alice wants the "VideoRoom" blueprint)
3. 蓝图请求/检索消息（Alice想要“视频室”蓝图）
<?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-blueprint-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-blueprint-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>retrieve</operation>
<ccmp:blueprintRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
4. blueprintResponse/retrieve message ("VideoRoom" conference object returned)
4. Blueprint响应/检索消息（“VideoRoom”会议对象返回）
<?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:VideoRoom@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintResponse>
<blueprintInfo entity="xcon:VideoRoom@example.com">
<info:conference-description>
<info:display-text>VideoRoom</info:display-text>
<?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:VideoRoom@example.com</confObjID>
<operation>retrieve</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<ccmp:blueprintResponse>
<blueprintInfo entity="xcon:VideoRoom@example.com">
<info:conference-description>
<info:display-text>VideoRoom</info:display-text>
<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>
<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>
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:VideoRoom@example.com</confObjID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
6. confResponse/create message (cloned conference object returned)
6. confResponse/create消息（返回克隆的会议对象）
<?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" 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>
</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>
</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>
Figure 6: Create Conference (Blueprint) Detailed Messaging
图6：创建会议（蓝图）详细消息
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.
客户机还可以通过发送带有“create”<operation>的confRequest消息以及要创建的会议的<confInfo>元素形式的所需数据来创建会议。该请求还包括设置为请求实体的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.
这种方法允许客户机（在本例中为Alice）完全描述会议对象的外观，而不依赖默认值或蓝图；例如，应该提供哪些媒体、主题、允许加入的用户、任何与日程安排相关的信息，等等。这可以通过在创建请求中提供完整的会议对象供服务器解析来实现。
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
此<confInfo>参数必须符合数据模型规范。这意味着“实体”属性是必需的，文档中不能缺少该属性。但是，在本例中，客户机实际上正在请求创建一个新的会议，该会议尚不存在，因此“实体”属性未知。如第4.1节所述，CCMP允许使用通配符占位符。此占位符（“xcon:自动生成_1@example.com“在本例中）仅用于确保<confInfo>元素符合数据模型，并且随后将由具有实际值的会议服务器替换。因此，当会议服务器实际创建会议时，也会为其创建一个有效的“实体”属性值，该值将取代
of the wildcard value when the actual conference object provided by the client is populated.
填充客户端提供的实际会议对象时的通配符值。
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.
为了给会议对象添加什么，我们假设Alice也对提供与调度相关的信息感兴趣。因此，在本例中，Alice还通过<confInfo>中包含的<conference time>元素指定她想要创建的会议必须在某个日期发生，从某个开始时间到某个停止时间，并且必须每周复制一次。
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").
此外，Alice通过<allowed users list>元素指出，在开始时，会议系统必须调用Bob、Carol和她自己来加入会议（事实上，对于与上述客户机之一相对应的每个<target>字段，“method”属性设置为“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.
Alice准备好<confInfo>元素并将其作为请求的一部分发送到服务器后，如果会议系统可以支持特定类型的会议（功能等），则请求将导致创建会议。我们假设请求已成功，因此，confResponse消息中返回了<confObjID>参数形式的XCON-URI和<confUserID>参数形式的XCON-USERID（同样，与请求实体相同）。
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>参数中的successful confResponse消息不会返回创建的会议对象。尽管如此，Alice仍然可以通过发出confRequest消息来检索实际的会议对象，该消息在前一个响应的<ConfBjid>中返回的XCON-URI上带有“retrieve”<operation>。如本节开头所述，该请求将说明如何将<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
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***>|
| | | |
| | | |
' ' ' '
' ' ' '
' ' ' '
| | | |
| |<<###################>>|
| | 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/create消息（Alice建议创建一个会议对象）
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<operation>create</operation>
<ccmp:confRequest>
<confInfo entity="xcon:AUTO_GENERATE_1@example.com">
<info:conference-description>
<info:display-text>
Dial-out conference initiated by Alice
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<operation>create</operation>
<ccmp:confRequest>
<confInfo entity="xcon:AUTO_GENERATE_1@example.com">
<info:conference-description>
<info:display-text>
Dial-out conference initiated by Alice
</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: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>
</info:users>
</confInfo>
</ccmp:confRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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:6845432@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:confResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
<?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:6845432@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:confResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 8: Create Basic Conference Detailed Messaging
图8：创建基本会议详细消息
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.
在本例中，客户机发送一条带有“create”<operation>的confRequest消息，以及<confUserID>元素中的她的XCON-USERID和<confObjID>元素中要从中克隆新会议的会议的XCON-URI。
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
第5.2节提供了客户如何根据蓝图创建会议的示例。本例中的客户机了解会议预订或活动会议的方式类似于blueprint示例中的第一步，只是查询不同类型的会议
objects supported by the specific conferencing system. For instance, in this example, the client clones a conference reservation (i.e., an inactive conference).
特定会议系统支持的对象。例如，在此示例中，客户端克隆会议预约（即，非活动会议）。
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.
如果会议系统可以支持特定类型会议（功能等）的新实例，则请求将导致创建会议，并在<confObjID>参数中以新值的形式显示XCON-URI，以反映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) |
| |
|<------------------------------|
| |
' '
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. Alice是一个会议系统客户端，根据现有会议预订发送confRequest消息以克隆会议。Alice指出应该从请求中提供的<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
2. 在收到包含“创建”<operation>和<confObjID>中前述XCON-URI的confRequest消息后，会议服务器确保收到的XCON-URI有效。会议服务器根据此XCON-URI（使用成员资格、角色等）确定要添加到会议的任何用户的适当读/写访问权限。会议
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.
服务器使用收到的<confObjID>克隆会议预订。会议服务器还保留或分配一个新的XCON-URI（图9中称为“confObjID*”），用于克隆的会议对象。当然，这个新标识符不同于与要克隆的会议相关联的标识符，因为它代表不同的会议对象。来自会议任何成员的任何后续协议请求必须使用此新标识符。会议服务器通过会议实例维护此会议ID和与预订关联的父会议对象ID之间的映射，并且此映射通过新会议对象中<conference description>的<cloning parent>元素显式寻址。
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:6845432@example.com</confObjID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:6845432@example.com</confObjID>
<operation>create</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. confResponse/create message (created conference object returned)
2. confResponse/create消息（返回已创建的会议对象）
<?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>
<?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 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 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>
Figure 10: Create Basic Conference (Clone) Detailed Messaging
图10：创建基本会议（克隆）详细消息
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
第5节展示了使用CCMP创建会议的几种不同方式的示例。本节重点介绍与用户相关的场景，即在
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.
会议的生命周期，如添加新用户和处理其媒体。以下场景基于XCON框架中记录的场景。这些示例假设已经正确地建立了会议，如适用，根据第5节中的示例之一，使用媒体。
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添加到已建立的会议中。在下面的示例中，我们假设Bob是系统的新用户，这意味着Alice还需要提供有关他的一些详细信息。事实上，Bob已经作为用户出现在会议系统中的情况更容易解决，稍后将讨论。
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") |
| | |<----------|
| | | |
' ' ' '
' ' ' '
' ' ' '
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. Alice发送一条userRequest消息，并执行“创建”操作，以将Bob添加到由<confObjID>中的XCON-URI标识的特定会议中。“create”<operation>还确保将Bob创建为整个会议系统中的用户。这是通过在请求中添加一个<userInfo>元素来完成的，该元素将Bob描述为用户。这是为了让会议系统了解Bob的特征所必需的。如果Bob已经是注册用户，Alice只需在<userInfo>字段的“entity”属性中通过他的XCON-USERID引用他，而不提供其他数据。事实上，该数据（例如，包括Bob随后用于拨出的SIP-URI）将通过引用现有注册来获得。会议服务器根据与特定会议对象关联的策略确保Alice具有执行操作的适当权限。如前所述，将为Bob创建一个新的XCON-USERID，并使用<userInfo>相应地更新会议对象。如第5.3节所示，占位符通配符（“xcon userid:AUTO_GENERATE_1@example.com“在下面的CCMP消息中）用于<userInfo>元素的“entity”属性，稍后将由实际的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. Bob已成功添加到会议对象，并为其分配了一个XCON-USERID（“XCON USERID:Bob@example.com"); 该标识符在响应中报告为返回的<userInfo>的“entity”属性的值；
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. 在本示例中，将Bob添加到会议的呼叫信令也通过focus发起。如前所述，这是特定于实现的。事实上，会议系统可能在用户创建后完成不同的操作，就像它可能什么都不做一样。例如，在可能的操作中，Bob可以作为<target>元素添加到<allowed users list>元素，其加入“方法”可以是“拨入”或“拨出”。此外，还可能涉及带外通知机制，例如，通过邮件通知Bob新会议，包括日期、密码、预期参与者等细节（见第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.
一旦Bob成功添加到指定的会议中，根据状态更新，并根据策略，其他参与者（包括Bob本人）可能会通过正在使用的会议通知服务被通知将Bob添加到会议中。
<?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" 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>
2. userResponse/create message (a new XCON-USERID is created for Bob and he is added to the conference)
2. userResponse/create message（为Bob创建一个新的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" 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>
<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>
<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>
Figure 12: Add Party Message Details
图12：添加参与方消息详细信息
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和楼层控制之间的相互作用。事实上，处理基于CCMP和BFCP的媒体控制必须被视为多层：即，参与者可以获得BFCP权限，但可以通过CCMP进行静音。如果是这样的话，他在会议上仍然会保持沉默，只有在两个协议都允许的情况下才会解除沉默。
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提供了一个客户机Alice影响另一个客户机Bob媒体状态的示例。本例假设一个已建立的会议。在本例中，会议主持人Alice希望让Bob在中型多方会议上静音，因为他的设备没有静音（而且他显然没有在听电话），而且他办公室环境中的背景噪音会干扰会议。假定不涉及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
静音可以使用与目标用户音频相关联的<mute>控制元素完成，在这种情况下，会议服务器必须更新与用户媒体流相关联的设置。静音/取消静音也可以通过直接修改与目标用户的媒体流相关的设置来实现，这是本例中所示的方法。具体来说，Bob的<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.
<media>与音频信息相关的部分，由“id”属性标识。修改包括在静音情况下将音频<status>设置为“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") | |
| | |<-----------| |
| | | | |
' ' ' ' '
' ' ' ' '
' ' ' ' '
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
1. Alice发送一条userRequest消息，其中包含一个“update”<operation>，Bob的<endpoint>的<media>元素中的<status>字段设置为“revconly”。为了对自己进行身份验证，Alice在<subject>请求参数中提供了她的注册凭据（即用户名和密码）。<subject>参数是一个可选参数：只要会议服务器打算对每个参数进行身份验证，就可以系统地使用它
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].
请求者。在这种情况下，如果客户端未提供所需的身份验证信息，会议服务器将使用CCMP“authenticationRequired”<response code>进行应答，这表明如果不包含适当的<subject>参数，则无法处理请求。会议服务器根据与特定会议对象关联的策略确保Alice具有执行操作的适当权限。它确认允许Alice请求指定的修改，因为她是目标会议的主持人，并更新会议对象中的<userInfo>，以反映Bob的媒体不能与会议媒体混合。如果会议服务器的多媒体功能依赖于远程媒体服务器，则随后会通过与MS的相关协议交互相应地更改Bob的媒体配置文件。该示例描述了使用媒体服务器控制体系结构处理这种情况的可能方法[RFC5567]在[CALL-FLOWS]中的图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.
2. 然后将带有“200”<response code>（“success”）的userResponse消息发送给Alice。根据策略，会议服务器可以通过可能正在使用的任何会议通知服务将此更新通知其他参与者（包括Bob）。
<?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" 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>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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" 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>
Figure 14: Mute Message Details
图14：静音消息详细信息
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没有严格的关系（CCMP信令实际上与第6.1节中的相同），但了解XCON兼容体系结构的几个组件如何相互作用以实现这一点是一个有趣的场景。
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所示，Alice正在加入Bob的会议，该会议要求她首先输入密码。成功输入密码后，一则公告提示Alice说出她的名字，以便记录。将Alice添加到活动会议时，将向所有现有与会者播放录制的内容。[CALL-FLOWS]的图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 +->| |
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) | |
|<---------------------------| |
| | |
' ' '
| | |
| | |
| (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.
1. 从Alice收到要添加到Bob会议的userRequest消息后，会议服务器确定此特定会议需要密码。因此，要求Alice输入密码的公告被发回。这可以通过典型的IVR功能实现。Alice输入密码后，将根据与Bob的活动会议相关的策略对其进行验证。然后，会议服务器连接到一个服务器，该服务器提示并记录Alice的姓名。会议服务器还必须确定Alice是否已经是此会议系统的用户，或者她是否是新用户。在本例中，Alice是此会议系统的新用户，因此将为Alice创建一个新的XCON-USERID。根据Alice提供的联系信息，通过focus发起将Alice添加到会议的呼叫信令。
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. 会议服务器向Alice发送一条userResponse消息，该消息包含在会议系统分配给她的XCON-USERID中。这将允许Alice稍后在会议上执行操作（如果她有适当的策略），包括注册与会议相关的事件通知。一旦呼叫信令指示Alice已成功添加到特定会议，根据状态更新，并根据策略，其他参与者（例如Bob）通过会议通知服务将Alice加入会议，并向所有与会者发出通知，表明Alice已加入会议。
1. userRequest/create message (a new conferencing system client, Alice, enters Bob's conference)
1. userRequest/create消息（一个新的会议系统客户端Alice进入Bob的会议）
<?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">
<?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">
<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: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>
2. userResponse/create message (Alice provided with a new XCON-USERID and added to the conference)
2. 用户响应/创建消息（Alice提供了一个新的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" 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>
Figure 16: Announcement Messaging Details
图16：公告消息传递详细信息
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
会议系统通常还需要监控每个参与者的双音多频（DTMF）功能。这通常用于输入用于加入特定会议的标识符和/或访问代码。此功能也经常被使用
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).
利用此漏洞实现参与者与非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].
图15显示了框架元素上下文中的DTMF监控示例。会议服务器可将媒体控制体系结构和协议[RFC5567]用于所有DTMF交互。[CALL-FLOWS]中给出了会议实例中DTMF拦截的示例。
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操作会议对象（例如，加入、更新、删除）。在这种情况下，密码将包含在会议数据模型相应的<conference URI>条目中的<conference password>元素中。然后，该密码必须包含在发送给该会议的CCMP请求的<conference password>字段中。
In the following example, Alice, a conferencing system client, attempts to join a password-protected conference.
在下面的示例中，会议系统客户端Alice尝试加入受密码保护的会议。
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.
1. Alice发送一条带有“create”<operation>的userRequest消息，以将自己添加到带有XCON-URI的会议中“XCON:8977777@example.com“（写入<confObjID>参数中）。Alice通过userRequest消息的<confUserID>字段提供她的XCON-USERID，并省略了<userInfo>one（第一方加入）。在第一次尝试中，她没有插入任何密码参数。
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/create消息后，会议服务器检测到指示的会议在未提供适当密码的情况下不可加入。将向Alice返回带有“423”<response code>（“需要会议密码”）的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. 通过带外机制获取密码后，Alice在新userRequest/create消息的适当<conference password>请求字段中提供密码，并将更新后的请求发送回服务器。
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. 会议服务器检查提供的密码，然后将Alice添加到受保护的会议。然后，向Alice发送一条带有“200”<response code>（“success”）的userResponse消息。
1. userRequest/create message (Alice tries to enter the conference without providing the password)
1. 用户请求/创建消息（Alice试图在不提供密码的情况下进入会议）
<?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:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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:8977794@example.com</confObjID>
<operation>create</operation>
<ccmp:userRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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" 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" 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:8977794@example.com</confObjID>
<operation>create</operation>
<conference-password>8601</conference-password>
<?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:8977794@example.com</confObjID>
<operation>create</operation>
<conference-password>8601</conference-password>
<ccmp:userRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<ccmp:userRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
4. userResponse/create message (Alice has been added to the conference)
4. 用户响应/创建消息（Alice已添加到会议）
<?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" 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>
Figure 17: Password-Protected Conference Join Messages Details
图17：受密码保护的会议加入消息详细信息
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.
本节使用侧边栏讨论一些典型场景，如耳语、私人消息和辅导场景。第一小节介绍了如何创建、配置和管理通用侧栏的一些示例。
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提供了一个客户Alice与Bob和Carol参加活动会议的示例。Alice想创建一个侧边栏，以便在观看与主会议相关的视频时与Bob进行旁白讨论。或者，可以将主要会议的音频保持在较低的音量。Alice通过向ConfS发送请求来启动侧栏，以根据活动会议对象创建会议预订。Alice和Bob将保留在主要会议的名册上，这样其他与会者就可以在内部侧边栏会议举行时知道他们参加了主要会议。此外，Bob决定他对在后台接收会议音频不感兴趣（即使是Alice配置的较低音量），因此修改侧边栏以使该流对他无效。
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) |
|--------------------------------------------->|
| | |
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) |
| |<----------------------|
| | |
' ' '
' ' '
' ' '
| | (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.
1. 在收到CCMP sidebarByValRequest消息以根据XCON-URI位于请求中接收到的<confObjID>中的会议创建新的侧栏后，会议服务器使用此类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.
2. 关系信息在sidebarByValResponse消息中提供，特别是在<sidebar parent>元素中。下面提供了一个完整的主/父会议表示的转储，并展示了创建侧栏的克隆过程是如何进行的。
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消息以预订会议后，Alice现在可以使用该预订创建活动会议，或者基于现有预订创建其他预订。在本例中，Alice只希望Bob参与侧边栏；因此，她操纵成员资格，以便在<allowed users list>部分中只显示其中两个成员。Alice还希望在侧边栏中提供原始会议的音频和视频。对于属于侧边栏本身的媒体，Alice希望音频仅限于侧边栏中的参与者（即Bob和她自己）。此外，Alice操纵媒体值，以较小的音量接收来自主会议的音频，这样她和Bob之间的通信就不会受到影响。Alice发送带有“更新”操作的sidebarByValRequest消息以及包含上述侧栏修改的<sidebarByValInfo>。
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.
4. 在收到sidebarByValRequest消息以更新侧栏保留时，会议服务器确保Alice具有基于与特定会议对象关联的策略的适当权限来执行该操作。会议服务器还必须验证保留中的更新信息，确保像Bob这样的成员已经是此会议服务器的用户。更新了<confObjID>标识的会议数据后，会议服务器将向Alice发送sidebarByValResponse消息。根据策略，请求的发起人（即Alice）和侧栏中的参与者（即Bob）可以通过会议通知服务被通知他添加到侧栏中。
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. 此时，Bob向会议服务器发送一条userRequest消息，并执行“更新”操作，以完全禁用来自父会议的背景音频，因为这会阻止他理解Alice在侧边栏中所说的内容。
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
6. 请注意，Bob的请求只会更改Bob的媒体透视图。Alice继续接收来自Bob的音频和来自家长会议的背景。该请求可以由会议服务器中继到处理混合的媒体服务器（如果存在）。变更完成后
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.
会议服务器向Bob发送userResponse消息。根据策略，可以通过会议通知服务将此更改通知请求的发起人（即Bob）和侧栏中的参与者（即Alice）。
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" 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">
<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>
<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>
Figure 19: Conference with Alice, Bob, and Carol
图19：与Alice、Bob和Carol的会议
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/create消息（Alice创建一个内部侧栏）
<?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-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByValRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByValRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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" 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
</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>
</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>
3. sidebarByValRequest/update message (Alice updates the created sidebar)
3. sidebarByValRequest/update消息（Alice更新创建的侧栏）
<?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-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description>
<info:display-text>
private sidebar Alice - Bob
</info:display-text>
<info:available-media>
<info:entry label="123">
<?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-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8974545@example.com</confObjID>
<operation>update</operation>
<ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:8974545@example.com">
<info:conference-description>
<info:display-text>
private 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>
<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>
<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>
4. sidebarByValResponse/update message (sidebar's updates accepted)
4. sidebarByValResponse/update消息（接受侧边栏的更新）
<?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>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByValResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
<?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>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByValResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
<?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-user-request-message-type">
<confUserID>xcon-userid:Bob@example.com</confUserID>
<confObjID>xcon:8974545@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:display-text>
main conference audio
</info:display-text>
<info:label>123</info:label>
<info:status>inactive</info:status>
</info:media>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-user-request-message-type">
<confUserID>xcon-userid:Bob@example.com</confUserID>
<confObjID>xcon:8974545@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:display-text>
main conference audio
</info:display-text>
<info:label>123</info:label>
<info:status>inactive</info:status>
</info:media>
</info:endpoint>
</userInfo>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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" 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>
Figure 20: Internal Sidebar Messaging Details
图20：内部侧栏消息传递详细信息
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
图21提供了一个针对侧栏的不同方法的示例。在这个场景中，一个客户Alice与Bob、Carol、David和Ethel进行了一次活跃的会议。Alice通过Bob的耳语收到一条重要的短信，关键客户需要与Alice、Bob和Ethel交谈。Alice创建了一个侧边栏，与客户Fred进行侧边讨论，其中包括当前会议的参与者，Carol和David除外，他们仍在活跃的会议中。与前一个场景的不同之处在于Fred不是父会议的一部分：这意味着可能涉及不同的策略，考虑到Fred可能会访问来自父会议的信息，如果侧边栏被相应地配置。因此，在此场景中，我们假设Alice在侧边栏中禁用原始（父）会议中的所有媒体。这意味着，在上一个示例中，Alice和Bob仍然在后台听到来自主会议的音频，但这次没有背景可用。Alice通过向会议服务器发送请求来启动侧栏，以根据活动会议对象创建会议预订。艾丽斯、鲍勃和埃塞尔仍将以搁置状态留在主要会议的名册上。这些参与者的持有状态是否对其他参与者可见取决于个人和当地政策。但是，提供保持状态允许主会议的参与者看到会议中的其他人正忙着。请注意，Alice可以创建一个单独的会议，让Bob和Ethel与Fred交谈。然而，创建边栏在某种程度上有一个优势
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.
允许使用Bob和Ethel在主会议中使用的一些相同设置（例如，角色、楼层控制等）创建会议，并允许进行更新，以更新媒体，例如提供来自主会议的音频。
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) |
|<---------------------------------------------|
| | |
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) |
| |<----------------------|
| | |
' ' '
' ' '
' ' '
| | 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.
1. 收到sidebarByRefRequest消息以创建新的侧栏会议后，会议服务器将根据请求中<confObjID>指定的活动会议，使用该活动会议克隆侧栏的会议预订。侧边栏保留不独立于活动会议（即父会议）。与前面一样，会议服务器分配了一个新的XCON-URI（“图21中的confObjID*”），用于向侧边栏保留发送任何后续协议请求。侧栏XCON-URI和与主会议关联的URI之间的映射由会议服务器维护，并从侧栏会议对象中的<sidebar parent>元素收集。
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>.
2. 收到sidebarByRefResponse消息（确认侧边栏对象已成功创建）后，Alice决定侧边栏中只包含Bob和Ethel以及新参与者Fred。因此，她相应地操纵成员资格。Alice还在<conference info>中设置媒体，使侧边栏中的参与者不会从主会议接收任何媒体。所有这些设置都通过新的sidebarByRefRequest消息提供给会议服务器，并带有“update”<operation>。
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
3. Alice发送上述sidebarByRefRequest消息以更新预订中的信息并创建活动会议。在收到sidebarByRefRequest/update消息后，会议服务器确保Alice具有基于与特定会议对象关联的策略的适当权限来执行操作。会议服务器还验证预订中的更新信息。由于Fred是此会议系统的新用户，因此将为Fred创建会议用户标识符（XCON-USERID）。具体来说，Fred是通过只提供他的SIPURI添加到会议中的。根据Alice提供给Fred的联系信息，可通过focus（例如，如果Fred有
a "dial-out" value for the 'method' attribute in his <target> field under <allowed-users-list>) at the actual activation of the sidebar.
侧边栏实际激活时，<allowed users list>下的他的<target>字段中的“method”属性的“拨号”值。
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. 会议服务器发送侧边栏回复消息，并且根据策略，可以通过会议通知服务通知请求的发起人（即Alice）和侧边栏中的参与者（即Bob和Ethel）他添加到侧边栏中。
1. sidebarByRefRequest/create message (Alice creates an external sidebar)
1. sidebarByRefRequest/create消息（Alice创建外部侧栏）
<?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-sidebarByRef-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-sidebarByRef-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
2. sidebarByRefResponse/create message (created sidebar returned)
2. sidebarByRefResponse/create消息（已创建的边栏返回）
<?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-sidebarByRef-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971212@example.com">
<info:conference-description>
<info:display-text>
SIDEBAR CONFERENCE registered by Alice
</info:display-text>
<?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-sidebarByRef-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>1</version>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971212@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
</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>
<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>
<?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"
<?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>
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>
<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>
<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>
<?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-sidebarByRef-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByRefResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
<?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-sidebarByRef-response-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8971212@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByRefResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 22: External Sidebar Messaging Details
图22：外部边栏消息传递详细信息
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节中的示例。与前面的示例不同，Alice不需要在侧边栏中使用音频，只需在侧边栏中添加一个额外的基于文本的媒体流，就可以将她的文本消息传递给Bob，同时仍可以观看和收听主会议。
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).
在这个场景中，Alice向会议服务器请求在主会议上下文（如图19所示）中创建一个私人聊天室，其中涉及的参与者只有Bob和她自己。这可以通过以下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. Alice将sidebarByValRequest/create消息转发给会议服务器，在<confObjID>参数中包含主会议XCON-URI，在<sidebarByValInfo>字段中包含所需的侧栏会议对象。这样，使用用户提供的会议信息从会议服务器请求侧栏创建。请注意，与前面的侧栏示例不同，在本例中，提供了一个用于描述侧栏的全新会议对象：不涉及克隆，而<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. 会议服务器在检查Alice的权限并验证请求中包含的会议对象后，通过val conference创建所需的侧栏，并为其创建一个新的XCON-URI。侧栏不是如第7.1节和第7.2节所示克隆主会议对象，而是根据用户提供的会议信息创建的。但是，主会议和新创建的侧栏之间的父关系仍然由会议服务器维护（由于选择了CCMP请求消息类型——sidebarByVal类型）它由sidebarByValResponse消息中返回的<sidebarByValInfo>元素中的<sidebar parent>元素反映。请注意，根据CCMP规范，在这种“成功”响应中返回创建的边栏数据不是强制性的。
1. sidebarByValRequest/create message (Alice creates a private chat room between Bob and herself)
1. sidebarByValRequest/create消息（Alice在Bob和她自己之间创建了一个私人聊天室）
<?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-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:AUTO_GENERATE_1@example.com">
<?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-sidebarByVal-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977878@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByValRequest>
<sidebarByValInfo entity="xcon:AUTO_GENERATE_1@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="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>
<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>
<?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">
<?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>
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: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>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
</info:users>
</sidebarByValInfo>
</ccmp:sidebarByValResponse>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 23: Sidebar for Private Messages Scenario
图23：私有消息场景的侧栏
"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所示。在本例中，呼叫中心代理Bob参与了与客户Carol的会议。由于鲍勃是一名新经纪人，爱丽丝发现他与卡罗尔的通话时间比平时长，因此她决定观察通话情况，并在必要时对鲍勃进行辅导。当然，会议系统必须确保客户Carol不知道教练Alice在场。这使得使用侧边栏对于场景的成功是必要的。
Consider the following as the conference document associated with the video conference involving Bob (the call agent) and Carol (the customer) (Figure 24):
将下面的内容视为涉及鲍伯（呼叫代理）和凯罗尔（客户）的视频会议相关的会议文档（图24）：
<?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:8978383@example.com">
<info:conference-description>
<info:display-text>
CUSTOMER SERVICE conference
</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>sip:8978383@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>service audio</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
<?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:8978383@example.com">
<info:conference-description>
<info:display-text>
CUSTOMER SERVICE conference
</info:display-text>
<info:conf-uris>
<info:entry>
<info:uri>sip:8978383@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>service audio</info:display-text>
<info:type>audio</info:type>
<info:status>sendrecv</info:status>
</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>
</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>
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) |
| |<----------------------|
| | |
' ' '
' ' '
' ' '
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>.
1. 在收到Alice发出的sidbarByRefRequest/create消息以从请求中收到的<confObjID>创建新的侧栏会议后，会议服务器使用收到的活动会议克隆侧栏的会议预订。会议服务器还分配一个新的XCON-URI，用于定向到新侧栏的任何后续协议请求。会议服务器维护此侧栏会议ID和与主会议实例关联的侧栏会议ID之间的映射。会议服务器发送一条sidebarByRefResponse消息，该消息包含<confObjID>字段中的新XCON-URI和<sidebarByRefInfo>中的其他相关信息。
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.
2. 收到sidebarByRefResponse消息后，Alice将处理响应中<sidebarByRefInfo>中接收的数据。Alice只希望Bob参与侧边栏；因此，她更新了<allowed users list>，只包括Bob和她自己。Alice还希望自己和Bob从原始会议接收音频，但希望自己传出的音频仅限于侧边栏中的参与者，而Bob传出的音频应转到主会议，以便Alice和客户Carol听到Bob发出的相同音频。Alice发送一条sidebarByRefRequest消息，其中包含<sidebarByRefInfo>元素中更新的边栏信息的“更新”<operation>。
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.
3. 在收到sidebarByRefRequest/update消息后，会议服务器确保Alice具有基于与特定会议对象关联的策略的适当权限来执行操作。为了请求在侧栏中插入进一步的媒体流（即，在本例中是从Alice到Bob的音频流），请求者必须在<sidebarByRefInfo>的<available media>字段中提供一个新的<entry>元素。该新<entry>的强制“label”属性用伪值“AUTO_GENERATE_1”填充，但当媒体流在服务器端有效分配时，它将包含真正的服务器生成的媒体流标识符。类似地，<media>元素中引用Alice和Bob的<endpoint>下的新侧栏音频流的强制“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
4. 验证数据后，会议服务器发送sidebarByRefResponse消息。根据Alice为Bob提供的联系信息，呼叫信令将Bob添加到
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.
具有适当媒体特征的侧边栏是通过焦点激发的。Bob通过会议通知服务被通知添加到侧栏中；因此，他知道主管Alice可以通过此电话指导他。
<?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-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8978383@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-sidebarByRef-request-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8978383@example.com</confObjID>
<operation>create</operation>
<ccmp:sidebarByRefRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-sidebarByRef-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>1</version>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971313@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>
<?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-sidebarByRef-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>create</operation>
<response-code>200</response-code>
<response-string>Success</response-string>
<version>1</version>
<ccmp:sidebarByRefResponse>
<sidebarByRefInfo entity="xcon:8971313@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
</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>
<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>
3. sidebarByRefRequest/update message (Alice introduces unilateral sidebar audio and excludes Carol from the sidebar)
3. sidebarByRefRequest/update消息（Alice引入单边侧边栏音频并将Carol排除在侧边栏之外）
<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="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">
<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>
<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>
<?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-sidebarByRef-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByRefResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
<?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-sidebarByRef-response-message-type">
<confUserID>xcon-userid:alice@example.com</confUserID>
<confObjID>xcon:8971313@example.com</confObjID>
<operation>update</operation>
<response-code>200</response-code>
<response-string>success</response-string>
<version>2</version>
<ccmp:sidebarByRefResponse/>
</ccmpResponse>
</ccmp:ccmpResponse>
Figure 26: Coaching and Observing Messaging Details
图26：指导和观察消息传递细节
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节中的示例之一，使用媒体。
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的示例。本例假设与Alice、Bob、Claire和Duck举行了一次已确定的会议。在本例中，Alice希望将Bob从会议中删除，以便该组可以在没有Bob参与的情况下继续参加同一会议。
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") |
| | |<----------|
| | | |
' ' ' '
' ' ' '
' ' ' '
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. Alice发送带有“delete”<operation>的userRequest消息。会议服务器根据与特定会议对象关联的策略确保Alice具有执行操作的适当权限。
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. 基于<userInfo>元素中Bob的会议对象中的联系人和媒体信息，会议系统启动删除Bob的过程（例如，通过焦点发起从会议中删除Bob的呼叫信令）。会议服务器更新会议对象中的数据，从而从<users>列表中删除Bob。更新数据后，会议服务器向发送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.
爱丽丝。根据政策，其他参与者（例如Claire）可能会通过会议通知服务被通知将Bob从会议中移除。
<?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:8977794@example.com</confObjID>
<operation>delete</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com"/>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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:8977794@example.com</confObjID>
<operation>delete</operation>
<ccmp:userRequest>
<userInfo entity="xcon-userid:Bob@example.com"/>
</ccmp:userRequest>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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" 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>
Figure 28: Removing a Participant Messaging Details
图28：删除参与者消息传递详细信息
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) |
| |
|<------------------------------|
| |
' '
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. 会议系统客户端Alice发送一条confRequest消息，其中包含一个“删除”操作，该操作将在<confObjID>参数中携带的XCON-URI标识的会议上执行。会议服务器基于接收请求中包含的<confUserID>，确保Alice具有完成操作的适当权限。
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. 在验证Alice的权限后，会议服务器启动删除会议对象的过程，断开参与者的连接并删除相关资源（如混合器实例）。然后，会议服务器向Alice返回confResponse消息，其中“200”为<response code>，已删除的会议XCON-URI位于<confObjID>字段中。
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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-conf-request-message-type">
<confUserID>xcon-userid:Alice@example.com</confUserID>
<confObjID>xcon:8977794@example.com</confObjID>
<operation>delete</operation>
<ccmp:confRequest/>
</ccmpRequest>
</ccmp:ccmpRequest>
<?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" 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>
Figure 30: Deleting a Conference Messaging Details
图30：删除会议消息传递详细信息
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.
XCON框架中记录了适用于实现这些调用流的安全注意事项，CCMP文档中记录了其他安全注意事项。关于必要安全性的声明将在特定流程中讨论；但是，这仅用于提供信息。鼓励实施者仔细考虑规范文件中的安全要求。
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.
这份文件的详细内容来源于Lorenzo Miniero、Simon Pietro Romano、Tobia Castaldi及其同事在那不勒斯大学的原型工作。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.
[RFC5239]Barnes，M.，Boulton，C.，和O.Levin，“集中会议的框架”，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]Novo，O.，Camarillo，G.，Morgan，D.，和J.Urpalainen，“集中会议的会议信息数据模型（XCON）”，RFC 65012012年3月。
[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]Camarillo，G.，Srinivasan，S.，Even，R.，和J.Urpalainen，“集中会议的会议事件包数据格式扩展（XCON）”，RFC 65022002，2012年3月。
[RFC6503] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, "Centralized Conferencing Manipulation Protocol", RFC 6503, March 2012.
[RFC6503]Barnes，M.，Boulton，C.，Romano，S.，和H.Schulzrinne，“集中式会议操纵协议”，RFC65032012年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]Bray，T.，Paoli，J.，Sperberg McQueen，C.，Maler，E.，和F.Yergeau，“可扩展标记语言（xml）1.0（第五版）”，万维网联盟建议REC-xml-20081126，2008年11月<http://www.w3.org/TR/2008/REC-xml-20081126>.
[CALL-FLOWS] Amirante, A., Castaldi, T., Miniero, L., and S. Romano, "Media Control Channel Framework (CFW) Call Flow Examples", Work in Progress, July 2011.
[呼叫流]Amirante，A.，Castaldi，T.，Miniero，L.，和S.Romano，“媒体控制渠道框架（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]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“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]Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]Johnston，A.和O.Levin，“会话发起协议（SIP）呼叫控制-用户代理会议”，BCP 119，RFC 4579，2006年8月。
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4582]Camarillo，G.，Ott，J.，和K.Drage，“二进制地板控制协议（BFCP）”，RFC 4582，2006年11月。
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", RFC 4597, August 2006.
[RFC4597]伊恩，R.和N.伊斯梅尔，“会议场景”，RFC4597，2006年8月。
[RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.
[RFC5567]Melanchuk，T.，“媒体服务器控制的体系结构框架”，RFC5567，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.Boulton，“媒体控制频道框架的混音控制包”，RFC 65052012年3月。
Authors' Addresses
作者地址
Mary Barnes Polycom TX USA
美国德克萨斯州玛丽·巴恩斯宝利通公司
EMail: mary.ietf.barnes@gmail.com
EMail: mary.ietf.barnes@gmail.com
Lorenzo Miniero Meetecho Via Carlo Poerio 89/a Napoli 80121 Italy
Lorenzo Miniero Meetecho Via Carlo Poerio 89/a那不勒斯80121意大利
EMail: lorenzo@meetecho.com
EMail: lorenzo@meetecho.com
Roberta Presta University of Napoli Via Claudio 21 Napoli 80125 Italy
罗伯塔普雷斯塔大学那不勒斯经由克劳迪奥21那不勒斯80125意大利
EMail: roberta.presta@unina.it
EMail: roberta.presta@unina.it
Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy
西蒙彼得洛罗马诺大学那不勒斯经由克劳迪奥21那不勒斯80125意大利
EMail: spromano@unina.it
EMail: spromano@unina.it