在本期中，我将展示并解释在故障转移集群模式下设置 CMS 服务器的一些复杂问题。
Теория一般来说，CMS服务器部署有以下三种类型：
- 单组合（单个组合），即这是一台运行所有必要服务的服务器。 在大多数情况下，这种类型的部署仅适用于内部客户端访问以及单个服务器的可扩展性和冗余限制不是关键问题的较小环境，或者 CMS 只执行某些功能（例如 ad hoc）的情况。 Cisco UCM 会议。
大致工作方案：
- 单分裂（单分割）通过添加单独的服务器用于外部访问来扩展以前的部署类型。 在传统部署中，这意味着在外部客户端可以访问的非军事网段 (DMZ) 中部署一台 CMS 服务器，并在内部客户端可以访问 CMS 的网络核心中部署一台 CMS 服务器。 这种特定的部署模型现在正在被所谓的类型所取代 单边，由服务器组成 思科高速公路，它具有或将具有许多相同的防火墙绕过功能，因此客户端无需添加专用的边缘 CMS 服务器。
大致工作方案：
- 可扩展且有弹性（可扩展且容错）此类型包括每个组件的冗余，允许系统根据您的需求增长到其最大容量，同时在发生故障时提供冗余。 它还使用单边缘概念来提供安全的外部访问。 这就是我们将在本集中看到的类型。 如果我们了解如何部署这种类型的集群，我们不仅能够了解其他类型的部署，而且还能够了解如何创建 CMS 服务器集群来适应潜在的需求增长。
在继续部署之前，您需要了解一些基本知识，即
主要 CMS 软件组件：
- 数据库：允许您组合一些配置，例如拨号计划、用户空间和用户本身。 仅支持集群以实现高可用性（单主）。
- 呼叫桥：音频和视频会议服务，可完全控制呼叫和多媒体进程的管理和处理。 支持集群以实现高可用性和可扩展性。
- XMPP 服务器：负责使用思科会议应用程序和/或 WebRTC 进行客户端的注册和身份验证（实时通信，或只是在浏览器中），以及组件间信号传输。 只能为了高可用性而集群。
- 网桥：提供对 WebRTC 的客户端访问。
- 负载均衡器：为单分割模式下的思科会议应用程序提供单个连接点。 侦听外部接口和端口的传入连接。 同样，负载均衡器接受来自 XMPP 服务器的传入 TLS 连接，通过该连接它可以切换来自外部客户端的 TCP 连接。
在我们的场景中，不需要它。 - TURN服务器：提供防火墙旁路技术，允许
将我们的 CMS 置于防火墙或 NAT 后面，以使用思科会议应用程序或 SIP 设备连接外部客户端。 在我们的场景中，不需要它。 - 网络管理员：管理界面和 API 访问，包括特殊的 Unified CM 会议。
配置模式
与大多数其他思科产品不同，思科会议服务器支持三种配置方法来适应任何类型的部署。
- 命令行 (CLI)：称为 MMP 的命令行界面，用于初始配置和证书任务。
- 网页管理员：主要用于 CallBridge 相关配置，尤其是在设置单个非集群服务器时。
- REST API：用于最复杂的配置任务和集群数据库相关任务。
除了上述之外，还使用该协议 SFTP 与 CMS 服务器之间传输文件（通常是许可证、证书或日志）。
思科的部署指南中用白色和英文写着需要部署集群 至少三个 数据库上下文中的服务器（节点）。 因为只有奇数个节点时，选择新Database Master的机制才会起作用，并且一般来说Database Master与大多数CMS服务器数据库都有连接。
实践表明，两台服务器（节点）确实不够。 选择机制在Master重新启动时起作用，只有在重新启动的服务器启动后，Slave服务器才成为Master。 但是，如果在两台服务器组成的集群中，Master 服务器突然宕机，那么 Slave 服务器就不会成为 Master，而如果 Slave 宕机，那么剩下的 Master 服务器就会成为 Slave。
但在 XMPP 的背景下，确实有必要组装一个由三台服务器组成的集群，因为例如，如果您在 XMMP 处于 Leader 状态的其中一台服务器上禁用 XMPP 服务，那么在其余服务器上，XMPP 将保持 Follower 状态，并且 CallBridge 与 XMPP 的连接将断开，因为CallBridge 专门连接到具有领导者状态的 XMPP。 这很关键，因为…… 一个电话都不会接通。
在同一部署指南中还演示了具有一台 XMPP 服务器的集群。
考虑到上述情况，原因就很清楚了：它之所以有效，是因为它处于故障转移模式。
在我们的例子中，XMPP 服务器将出现在所有三个节点上。
假设我们的所有三台服务器都已启动。
DNS 记录
在开始设置服务器之前，您需要创建 DNS 记录 А и SRV 类型：
请注意，在我们的 DNS 记录中有两个域 example.com 和 CONF.example.com。 example.com 是所有 Cisco Unified Communications Manager 订阅者都可以将其用作 URI 的域，该域很可能存在于您的基础设施中或很可能存在。 或者 example.com 与用户用于其电子邮件地址的域相匹配。 或者您笔记本电脑上的 Jabber 客户端可能有一个 URI [电子邮件保护]。 领域 CONF.example.com 是将为 Cisco Meeting Server 用户配置的域。 思科会议服务器的域将是 CONF.example.com，因此对于同一个 Jabber 用户，需要使用 user@ URI 登录 Cisco Meeting ServerCONF.example.com。
基本配置
下面描述的所有设置均显示在一台服务器上，但需要在集群中的每台服务器上完成。
服务质量
由于 CMS 生成 实时的 流量对延迟和数据包丢失敏感，大多数情况下建议配置服务质量 (QoS)。 为了实现这一点，CMS 支持使用它生成的差分服务代码 (DSCP) 来标记数据包。 尽管基于 DSCP 的流量优先级取决于基础设施的网络组件处理流量的方式，但在我们的示例中，我们将使用基于 QoS 最佳实践的典型 DSCP 优先级来配置 CMS。
在每个服务器上我们将输入这些命令
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A因此，所有视频流量都标记为 AF41 (DSCP 0x22)，所有语音流量都标记为 EF (DSCP 0x2E)，其他类型的低延迟流量（例如 SIP 和 XMPP）使用 AF31 (DSCP 0x1A)。
检查：
NTP
网络时间协议 (NTP) 不仅对于提供准确的通话和会议时间戳很重要，而且对于验证证书也很重要。
使用如下命令将 NTP 服务器添加到您的基础设施中
ntp server add <server>
在我们的例子中，有两个这样的服务器，所以会有两个团队。
检查：
并设置我们服务器的时区
DNS
我们使用以下命令将 DNS 服务器添加到 CMS：
dns add forwardzone <domain-name> <server ip>
在我们的例子中，有两个这样的服务器，所以会有两个团队。
检查：
网络接口配置
我们使用如下命令配置接口：
ipv4 <interface> add <address>/<prefix length> <gateway>
检查：
服务器名称（主机名）
我们使用如下命令设置服务器名称：
hostname <name>
然后我们重新启动。
这样就完成了基本配置。
证书
ТеорияCisco Meeting Server 需要各个组件之间的加密通信，因此所有 CMS 部署都需要 X.509 证书。 它们有助于确保服务/服务器受到其他服务器/服务的信任。
每个服务都需要一个证书，但为每个服务创建单独的证书可能会导致混乱和不必要的复杂性。 幸运的是，我们可以生成证书的公钥-私钥对，然后在多个服务中重复使用它们。 在我们的例子中，相同的证书将用于呼叫桥接器、XMPP 服务器、Web 桥接器和 Web 管理。 因此，您需要为集群中的每台服务器创建一对公钥和私钥证书密钥。
然而，数据库集群有一些特殊的证书要求，因此需要有自己的与其他服务不同的证书。 CMS 使用服务器证书，该证书与其他服务器使用的证书类似，但还有用于数据库连接的客户端证书。 数据库证书用于身份验证和加密。 它不提供客户端连接数据库的用户名和密码，而是提供服务器信任的客户端证书。 数据库集群中的每台服务器都将使用相同的公钥和私钥对。 这允许集群中的所有服务器以只能由也共享相同密钥对的其他服务器解密的方式加密数据。
为了实现冗余，数据库集群必须至少包含 3 台服务器，但不得超过 5 台，任何集群成员之间的最大往返时间为 200 毫秒。 此限制比呼叫桥群集更具限制性，因此它通常是地理分布式部署中的限制因素。
CMS 的数据库角色有许多独特的要求。 与其他角色不同，它需要客户端和服务器证书，其中客户端证书具有呈现给服务器的特定 CN 字段。
CMS 使用具有一个主数据库和多个完全相同的副本的 postgres 数据库。 一次只有一个主数据库（“数据库服务器”）。 集群的其余成员是副本或“数据库客户端”。
数据库集群需要专用服务器证书和客户端证书。 它们必须由证书签名，通常是内部私有证书颁发机构。 由于数据库集群的任何成员都可以成为主服务器，因此必须将数据库服务器和客户端证书对（包含公钥和私钥）复制到所有服务器，以便它们可以采用客户端或数据库服务器的身份。 另外，还必须加载CA根证书，以保证客户端和服务器端的证书能够被验证。
因此，我们创建一个证书请求，该证书将由除数据库之外的所有服务器服务使用（对此将有一个单独的请求），命令如下：
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
在 CN 中，我们写下我们服务器的通用名称。 例如，如果我们服务器的主机名 服务器01, 服务器02, 服务器03，那么 CN 将是 服务器.example.com
我们在其余两台服务器上执行相同的操作，不同之处在于命令将包含相应的“主机名”
我们生成两个证书请求，数据库服务将使用这些证书，命令如下：
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgres哪里 数据库集群服务器 и 数据库集群客户端 我们的请求和未来证书的名称， 主机名1(2)(3) 相应服务器的名称。
我们仅在一台服务器上执行此过程（！），并将证书和相应的 .key 文件上传到其他服务器。
在 AD CS 中启用客户端证书模式
您还需要将每台服务器的证书合并到一个文件中。在 *NIX 上：
cat server01.cer server02.cer server03.cer > server.cer在 Windows/DOS 上：
copy server01.cer + server02.cer + server03.cer server.cer
并上传到各个服务器：
1.“个人”服务器证书。
2. 根证书（连同中间证书，如果有的话）。
3. 数据库（“服务器”和“客户端”）的证书以及带有 .key 扩展名的文件，这些证书是在创建“服务器”和“客户端”数据库证书的请求时生成的。 这些文件在所有服务器上必须相同。
4. 所有三份“个人”证书的归档。
因此，您应该在每台服务器上获得类似此文件图片的内容。
数据库集群
现在您已将所有证书上传到 CMS 服务器，您可以在三个节点之间配置和启用数据库集群。 第一步是选择一台服务器作为数据库集群的主节点并对其进行全面配置。
主数据库
设置数据库复制的第一步是指定将用于数据库的证书。 这是使用如下命令完成的：
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>现在让我们使用以下命令告诉 CMS 使用哪个接口进行数据库集群：
database cluster localnode a然后我们使用以下命令初始化主服务器上的集群数据库：
database cluster initialize
客户端数据库节点
我们执行相同的过程，只是代替命令 数据库集群初始化 输入如下命令：
database cluster join <ip address existing master>其中 ip 地址 初始化集群的 CMS 服务器的现有主 IP 地址，简称为 Master。
我们使用以下命令检查数据库集群在所有服务器上的工作情况：
database cluster status
我们在剩余的第三台服务器上执行相同的操作。
结果发现我们的第一台服务器是Master，其余的都是Slave。
网络管理服务
启用Web管理员服务：
webadmin listen a 445选择端口 445 是因为端口 443 用于用户访问 Web 客户端
我们使用证书文件配置 Web 管理服务，命令如下：
webadmin certs <keyfile> <certificatefile> <ca bundle>并使用以下命令启用 Web Admin：
webadmin enable
如果一切顺利，我们将收到 SUCCESS 行，表明 Web 管理已正确配置网络和证书。 我们使用网络浏览器检查服务的功能并输入网络管理员的地址，例如： ：445
呼叫桥集群
呼叫桥是每个 CMS 部署中唯一存在的服务。 呼叫桥是主要的会议机制。 它还提供一个 SIP 接口，以便可以通过 Cisco Unified CM 等将呼叫路由至该接口或从该接口路由出呼叫。
必须在具有适当证书的每台服务器上执行下面描述的命令。
所以：
我们使用如下命令将证书与呼叫桥接服务关联起来：
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]我们使用以下命令将 CallBridge 服务绑定到我们需要的接口：
callbridge listen a并使用以下命令重新启动服务：
callbridge restart
现在我们已经配置了呼叫桥，我们可以配置呼叫桥集群。 呼叫桥群集不同于数据库或 XMPP 群集。 呼叫桥集群可以支持 2 到 8 个节点，没有任何限制。 它不仅提供冗余，还提供负载平衡，以便可以使用智能呼叫分配在呼叫桥服务器之间主动分配会议。 CMS 具有附加功能、呼叫桥接组和可用于进一步管理的相关功能。
呼叫桥集群主要通过 Web 管理界面进行配置
必须在集群中的每台服务器上执行下述过程。
因此，
1. 通过 Web 访问配置 > 集群。
2。 该 呼叫桥身份 输入与服务器名称相对应的 callbridge[01,02,03] 作为唯一名称。 这些名称是任意的，但对于该集群必须是唯一的。 它们本质上是描述性的，因为它们表明它们是服务器标识符[01,02,03]。
3.B 集群呼叫桥 输入集群中服务器的 Web 管理员 URL， [01,02,03].example.com:445，位于地址字段中。 请务必指定端口。 您可以将对等链接 SIP 域留空。
4. 在每个服务器的CallBridge信任中添加一个证书，该文件包含我们服务器的所有证书，我们一开始就合并到这个文件中，命令如下：
callbridge trust cluster <trusted cluster certificate bundle>并使用以下命令重新启动服务：
callbridge restart
因此，在每台服务器上您都应该得到这样的图片：
XMPP集群
CMS 中的 XMPP 服务用于处理思科会议应用程序 (CMA) 的所有注册和身份验证，包括 CMA WebRTC Web 客户端。 呼叫桥本身还充当用于身份验证目的的 XMPP 客户端，因此必须像其他客户端一样进行配置。 XMPP容错是从2.1版本开始在生产环境中支持的功能
必须在具有适当证书的每台服务器上执行下面描述的命令。
所以：
我们使用如下命令将证书与 XMPP 服务关联起来：
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]然后使用命令定义监听接口：
xmpp listen aXMPP 服务需要唯一的域。 这是用户的登录。 换句话说，当用户尝试使用 CMA 应用程序（或通过 WebRTC 客户端）登录时，他们输入 userID@logindomain。 在我们的例子中，它将是 userid@CONF.example.com。 为什么不只是 example.com？ 在我们的特定部署中，我们选择了 Jabber 用户将在 Unified CM 中使用的 Unified CM 域作为 example.com，因此我们需要一个不同的域供 CMS 用户通过 SIP 域将呼叫路由到 CMS 或从 CMS 路由。
使用如下命令设置 XMPP 域：
xmpp domain <domain>并使用以下命令启用 XMPP 服务：
xmpp enable在 XMPP 服务中，您必须为注册 XMPP 服务时使用的每个呼叫桥创建凭据。 这些名称是任意的（并且与您为呼叫桥群集配置的唯一名称无关）。 您必须在一台 XMPP 服务器上添加三个呼叫桥，然后在集群中的其他 XMPP 服务器上输入这些凭据，因为此配置不适合集群数据库。 稍后我们将配置每个呼叫桥以使用此名称和密钥来注册 XMPP 服务。
现在我们需要在第一台服务器上配置 XMPP 服务，其中包含三个呼叫桥 callbridge01、callbridge02 和 callbridge03。 每个帐户将被分配随机密码。 稍后将在其他呼叫桥服务器上输入它们以登录到此 XMPP 服务器。 输入以下命令：
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03结果，我们用命令检查发生了什么：
xmpp callbridge list
完成下述步骤后，其余服务器上应该会出现完全相同的图片。
接下来，我们在其余两台服务器上添加完全相同的设置，仅使用命令
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03我们非常小心地添加 Secret，以便其中没有多余的空格。
因此，每个服务器应该有相同的图片：
接下来，在集群中的所有服务器上，我们以信任方式指定包含所有三个证书的文件，该文件是之前使用如下命令创建的：
xmpp cluster trust <trust bundle>我们使用以下命令在所有集群服务器上启用 xmpp 集群模式：
xmpp cluster enable在集群的第一台服务器上，我们使用以下命令启动 xmpp 集群的创建：
xmpp cluster initialize在其他服务器上，使用如下命令将集群添加到 xmpp：
xmpp cluster join <ip address head xmpp server>我们使用以下命令检查每台服务器是否成功创建 XMPP 集群：
xmpp status
xmpp cluster status第一个服务器：
第二台服务器：
第三台服务器：
将呼叫桥连接到 XMPP
现在 XMPP 集群正在运行，您需要配置呼叫桥接服务以连接到 XMPP 集群。 此配置是通过网络管理员完成的。
在每台服务器上，转至配置 > 常规并在字段中 唯一的呼叫桥名称 写入与服务器 Call Bridge 对应的唯一名称 呼叫桥[01,02,03]... 在现场 域名 conf.example.ru 以及相应的密码，您可以监视它们
在集群中的任何服务器上使用以下命令：
xmpp callbridge list
将“服务器”字段留空 呼叫桥 将执行 DNS SRV 查找 _xmpp-component._tcp.conf.example.com查找可用的 XMPP 服务器。 每个服务器上用于将 Callbridge 连接到 XMPP 的 IP 地址可能有所不同，这取决于记录请求返回的值 _xmpp-component._tcp.conf.example.com callbridge，这又取决于给定 DNS 记录的优先级设置。
接下来，进入“状态 > 常规”，验证 Call Bride 服务是否成功连接到 XMPP 服务。
网桥
在集群中的每台服务器上，使用以下命令启用 Web Bridge 服务：
webbridge listen a:443我们使用证书文件配置 Web Bridge 服务，命令如下：
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge 支持 HTTPS。 如果配置为使用“http-redirect”，它将把 HTTP 重定向到 HTTPS。
要启用 HTTP 重定向，请使用以下命令：
webbridge http-redirect enable要让 Call Bridge 知道 Web Bridge 可以信任来自 Call Bridge 的连接，请使用以下命令：
webbridge trust <certfile>其中这是一个包含集群中每台服务器的所有三个证书的文件。
该图片应该位于集群中的每台服务器上。
现在我们需要创建一个具有“appadmin”角色的用户，我们需要它，以便我们可以配置我们的集群（！），而不是单独配置集群中的每个服务器，这样设置将平等地应用于每个服务器，尽管事实上它们只会被制作一次。
为了进一步设置，我们将使用 .
对于授权，请在“授权”部分中选择“基本”
为了正确发送命令到CMS服务器，需要设置所需的编码
我们使用以下命令指定 Webbridge 解决方案&帖子 带参数 网址 和意义
在网桥本身中，我们指示所需的参数：访客访问、受保护的访问等。
呼叫桥接组
默认情况下，CMS 并不总是最有效地利用可用的会议资源。
例如，对于具有三个参与者的会议，每个参与者最终可能会进入三个不同的呼叫桥。 为了使这三个参与者能够相互通信，呼叫桥将自动在同一空间中的所有服务器和客户端之间建立连接，这样看起来就好像所有客户端都在同一服务器上一样。 不幸的是，这样做的缺点是单个 3 人会议现在将消耗 9 个媒体端口。 这显然是对资源的低效利用。 此外，当呼叫桥真正过载时，默认机制是继续接受呼叫并向该呼叫桥的所有订户提供降低质量的服务。
使用呼叫桥接组功能可以解决这些问题。 此功能在 Cisco Meeting Server 软件 2.1 版中引入，并已扩展为支持入站和出站 Cisco Meeting App (CMA) 呼叫（包括 WebRTC 参与者）的负载平衡。
为了解决重新连接问题，为每个呼叫桥引入了三个可配置的负载限制：
负载限制 — 这是特定呼叫桥的最大数字负载。 每个平台都有建议的负载限制，例如 CMS96000 为 1000，虚拟机每个 vCPU 为 1.25 GHz。 不同的调用会消耗一定量的资源，具体取决于参与者的分辨率和帧速率。
新会议负载限制基础点 （默认 50% loadLimit）- 设置服务器负载限制，超过此限制后新会议将被拒绝。
现有会议负载限制基本点 （默认为 loadLimit 的 80%）- 服务器负载值，超过该值后，参加者加入现有会议将被拒绝。
虽然此功能是为呼叫分配和负载平衡而设计的，但其他组（例如 TURN 服务器、Web Bridge 服务器和录音机）也可以分配给呼叫桥组，以便它们也可以正确分组以实现最佳使用。 如果这些对象中的任何一个未分配给呼叫组，则假定它们对所有服务器可用，没有任何特定优先级。
这些参数在这里配置： ：445 / api / v1 /系统/配置/集群
接下来，我们向每个 Callbridge 指示它属于哪个 Callbridge 组：
第一个呼叫桥
第二个呼叫桥
第三呼叫桥
因此，我们配置了呼叫桥接组，以更有效地使用 Cisco Meeting Server 集群的资源。
从 Active Directory 导入用户
Web Admin 服务有一个 LDAP 配置部分，但它不提供复杂的配置选项，并且信息不存储在集群数据库中，因此必须通过 Web 界面在每个服务器上手动完成配置，或者通过API，所以我们“三声不起来”仍然会通过API来设置数据。
使用URL访问 :445/api/v1/ldapServers 创建 LDAP Server 对象，指定参数，例如：
- 服务器 IP
- 端口号
- 用户名
- 密码
- 安全
安全 - 根据端口选择 true 或 false，389 - 不安全，636 - 受保护。
将 LDAP 源参数映射到 Cisco Meeting Server 中的属性。
LDAP 映射将 LDAP 目录中的属性映射到 CMS 中的属性。 实际属性：
- jid映射
- 名称映射
- coSpace名称映射
- coSpaceUri映射
- coSpaceSecondaryUriMapping
属性说明JID 代表用户在CMS中的登录ID。 由于这是 Microsoft Active Directory LDAP 服务器，因此 CMS JID 映射到 LDAP 中的 sAMAccountName，这本质上是用户的 Active Directory 登录 ID。 另请注意，您采用 sAMAccountName 并将域 conf.pod6.cms.lab 添加到其末尾，因为这是您的用户将用于登录 CMS 的登录名。
名称映射 将 Active Directory displayName 字段中包含的内容与用户的 CMS 名称字段进行匹配。
coSpace名称映射 根据 displayName 字段创建 CMS 空间名称。 该属性与 coSpaceUriMapping 属性一起是为每个用户创建空间所必需的。
coSpaceUri映射 定义与用户个人空间关联的 URI 的用户部分。 某些域可以配置为拨入太空。 如果用户部分与这些域之一的此字段匹配，则呼叫将定向到该用户的空间。
coSpaceSecondaryUriMapping 定义第二个 URI 来到达空间。 这可用于添加数字别名，以将调用路由到导入的用户空间，作为 coSpaceUriMapping 参数中定义的字母数字 URI 的替代方案。
LDAP 服务器和 LDAP 映射已配置。 现在您需要通过创建 LDAP 源将它们链接在一起。
使用URL访问 :445/api/v1/ldapSource 创建 LDAP Source 对象，指定参数，例如：
- 服务器
- 制图
- 基本Dn
- 过滤
现在LDAP配置已完成，您可以执行手动同步操作。
我们可以在每个服务器的 Web 界面中单击 立即同步 部分 活动目录
或通过 API 使用以下命令 解决方案&帖子 使用URL访问 :445/api/v1/ldapSyncs
临时会议
这是什么？在传统概念中，会议是指两个参与者正在相互交谈，其中一个参与者（使用注册了 Unified CM 的设备）按下“会议”按钮，呼叫另一个人，并与该第三方通话后，再次按“会议”按钮，将所有与会者加入三方会议。
Ad-Hoc 会议与 CMS 中的预定会议的区别在于 Ad-Hoc 会议不仅仅是对 CMS 的 SIP 呼叫。 当会议发起者再次单击“会议”按钮邀请所有人参加同一个会议时，Unified CM 必须对 CMS 进行 API 调用以创建一个即时会议，然后将所有呼叫转接至该会议。 所有这一切都在参与者没有注意到的情况下发生。
这意味着 Unified CM 必须将服务的 API 凭据和 WebAdmin 地址/端口以及直接连接到 CMS 服务器的 SIP 中继配置为继续呼叫。
如果有必要，CUCM可以在CMS中动态创建一个空间，以便每个呼叫都可以到达CMS并匹配用于空间的来电规则。
与 CUCM 集成 按照文章中描述的相同方式配置 除了在 Cisco UCM 上，您需要为 CMS 创建三个中继、三个会议桥、在 SIP 安全配置文件中指定三个主题名称、路由组、路由列表、媒体资源组和媒体资源组列表，并添加一些路由规则到思科会议服务器。
SIP 安全配置文件:
内裤:
每个行李箱看起来都一样：
会议桥
每个会议桥看起来都一样：
航线组
路线列表
媒体资源组
媒体资源组列表
通话规则
与 Unified CM 或 Expressway 等更高级的呼叫管理系统不同，CMS 仅在 SIP 请求 URI 字段中查找新呼叫的域。 因此，如果 SIP INVITE 用于 sip： [电子邮件保护]CMS 只关心domain.com。 CMS 遵循以下规则来确定将呼叫路由到何处：
1. CMS 首先尝试将 SIP 域与来电规则中配置的域进行匹配。 然后，这些呼叫可以路由到（“目标”）空间或特定用户、内部 IVR 或直接集成的 Microsoft Lync/Skype for Business (S4B) 目的地。
2. 如果来电规则中没有匹配的内容，CMS 将尝试匹配呼叫转接表中配置的域。 如果匹配，规则可以显式拒绝呼叫或转接呼叫。 此时，CMS 可能会重写域，这有时对于调用 Lync 域很有用。 您还可以选择传递 throw，这意味着不会进一步修改任何字段，或者使用内部 CMS 拨号计划。 如果呼叫转移规则不匹配，则默认拒绝呼叫。 请记住，在 CMS 中，虽然呼叫被“转发”，但媒体仍然绑定到 CMS，这意味着它将位于信令和媒体流量路径中。
那么只有转接的呼叫才受去电规则的约束。 这些设置确定呼叫发送的目的地、中继类型（是新的 Lync 呼叫还是标准 SIP 呼叫）以及在呼叫转接规则中未选择转接时可以执行的任何转换。
这是临时会议期间发生的情况的实际日志
截图显示效果很差（我不知道如何让它变得更好），所以我会这样写日志：
Info 127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info call create failed to find coSpace -- attempting to retrieve from database
Info API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G
Info 127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba
Info call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"
Info API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)
Info conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Info conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"
Info call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"
Info call 7: setting up UDT RTP session for DTLS (combined media and control)
Info conference "001036270012": unencrypted call legs now present
Info participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"
Info API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)
Info call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"
Info call 8: setting up UDT RTP session for DTLS (combined media and control)
Info call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"
Info API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)
Info call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"
Info call 9: setting up UDT RTP session for DTLS (combined media and control)
Info call 8: compensating for far end not matching payload types
Info participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 7: compensating for far end not matching payload types
Info call 8: non matching payload types mode 1/0
Info call 8: answering offer in non matching payload types mode
Info call 8: follow-up single codec offer received
Info call 8: non matching payload types mode 1/0
Info call 8: answering offer in non matching payload types mode
Info call 8: sending response to single-codec additional offer
Info call 9: compensating for far end not matching payload types
Info participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Info call 9: BFCP (client role) now active
Info call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info call 9: BFCP (client role) now active
Info call 7: ending; remote SIP teardown - connected for 0:13
Info call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e
Info participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info call 9: on hold
Info call 9: non matching payload types mode 1/0
Info call 9: answering offer in non matching payload types mode
Info call 8: on hold
Info call 8: follow-up single codec offer received
Info call 8: non matching payload types mode 1/0
Info call 8: answering offer in non matching payload types mode
Info call 8: sending response to single-codec additional offer
Info call 9: ending; remote SIP teardown - connected for 0:12临时会议本身：
来电规则
为了能够在 CMS 中接收呼叫，需要配置来电参数。 正如您在 LDAP 设置中看到的，所有用户都是通过域 conf.pod6.cms.lab 导入的。 因此，您至少希望调用该域以定位空间。 您还需要为每个 CMS 服务器的完全限定域名（甚至可能是 IP 地址）设置所有规则。 我们的外部呼叫控制 Unified CM 将单独配置专用于每个 CMS 服务器的 SIP 中继。 根据这些 SIP 干线的目的地是 IP 地址还是服务器的 FQDN，将确定 CMS 是否需要配置为接受定向到其 IP 地址或 FQDN 的呼叫。
具有最高优先级入站规则的域将用作任何用户空间的域。 当用户通过 LDAP 同步时，CMS 会自动创建空间，但仅创建 URI 的用户部分 (coSpaceUriMapping)，例如 user.space。 部分 完整的 URI 是根据此规则生成的。 事实上，如果您此时登录 Web Bridge，您会看到 Space URI 没有域。 通过将此规则设置为最高优先级，您可以将生成的空间的域设置为 配置文件example.com。
呼出规则
要允许用户向 Unified CM 集群发出出站呼叫，您必须配置出站规则。 向 Unified CM 注册的端点（例如 Jabber）的域是 example.com。 对此域的呼叫应作为标准 SIP 呼叫路由至 Unified CM 呼叫处理节点。 主服务器是 cucm-01.example.com，附加服务器是 cucm-02.example.com。
第一条规则描述了集群服务器之间最简单的呼叫路由。
领域 来自域的本地 负责在“@”符号之后在呼叫者的 SIP-URI 中显示被呼叫者的内容。 如果我们将其留空，那么在“@”符号之后将是该调用所通过的 CUCM 的 IP 地址。 如果我们指定一个域，那么“@”符号后面实际上会有一个域。 为了能够回叫，这是必要的，否则将无法通过 SIP-URI name@ip-address 回叫。
指定时调用 来自域的本地
打电话时 不 已指示 来自域的本地
请务必为拨出呼叫明确指定“加密”或“未加密”，因为“自动”参数不起作用。
录音
视频会议由录制服务器录制。 录音机与 Cisco Meeting Server 完全相同。 Recorder 不需要安装任何许可证。 运行 CallBridge 服务的服务器需要录制许可证，即需要录制许可证，并且必须将其应用于 CallBridge 组件，而不是应用于运行 Recorder 的服务器。 Recorder 充当可扩展消息传递和状态协议 (XMPP) 客户端，因此必须在托管 CallBridge 的服务器上启用 XMPP 服务器。
因为我们有一个集群，许可证需要在集群中的所有三台服务器上“延伸”。 然后，只需在您的个人帐户中的许可证中关联（添加）集群中包含的所有 CMS 服务器的 a 接口的 MAC 地址即可。
这是集群中每台服务器上应该出现的图片
一般来说，放置Recorder有几种场景，但我们会坚持这种：
在设置Recorder之前，您需要准备一个实际录制视频会议的地方。 其实在这里 ，如何设置所有录音。 我重点关注要点和细节：
1. 最好从集群中的第一台服务器中获取证书。
2. 由于记录器信任中指定了错误的证书，可能会出现“记录器不可用”错误。
3. 如果指定录制的NFS目录不是根目录，则可能无法写入。
有时需要自动录制某个特定用户或空间的会议。
为此，创建两个 CallProfile：
禁用录音
并具有自动录音功能
接下来，我们将具有自动录音功能的CallProfile“附加”到所需空间。
在 CMS 中，它是这样建立的：如果 CallProfile 显式绑定到任何空间或空间，则该 CallProfile 仅在与这些特定空间相关时起作用。 如果 CallProfile 未绑定到任何空间，则默认情况下它将应用于未显式绑定 CallProfile 的那些空间。
下次我将尝试描述如何在组织内部网络之外访问 CMS。
来源：
来源： habr.com