在CMS集群中使用maxPeerVideoStreams参数时的预期行为

简介

本文档介绍在思科会议服务器(CMS)群集中使用参数maxPeerVideoStreams时的预期行为。 

管理员快速参考指南中提到了此参数。 

先决条件

要求

Cisco 建议您了解以下主题：

• Cisco Meeting Server Call Bridge组件（及其集群）
• 思科会议服务器API配置

使用的组件

本文档中的信息基于以下软件和硬件版本：

• CMS 2.9.x

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

什么是maxPeerVideoStreams参数？它何时生效？

maxPeerVideoStreams参数首次引入CMS版本2.3。此参数控制CMS服务器可通过分布式呼叫向另一个CMS服务器发送多少参与视频流。需要在每个CMS服务器上单独设置它。 当每个CallBridge上有4个以上的参与者时，maxPeerVideoStreams参数对于大型分布式会议有效。

注意：maxPeerVideoStreams仅在包含两台或多台服务器的CMS集群中相关，它与单个CMS服务器无关。 

如果未设置maxPeerVideoStreams，则CMS的默认行为是通过分布式呼叫向其他CMS服务器发送最多4个视频流，此行为早于CMS 2.3。使用CMS 2.3及更高版本，现在可以更改该行为并配置CMS，使其通过分布式呼叫发送最多9个视频流，而不是仅发送4个。

此参数的重要性在大型会议、托管大量参与者以及使用AllEqual布局时变得更加明确，该布局允许单个参与者的屏幕上最多显示25个窗格。在这种情况下，如果会议通过两个CMS服务器（例如CMS1和CMS2）分发，并且此会议的每个CMS服务器上托管了超过4个参与者（5个或更多），则托管在CMS1上的参与者只能看到来自托管在CMS2上的远程参与者的最多4个参与者的视频，以及托管于其本地CMS(CMS1)服务器主机上的所有其他本地参与者的视频，即使CMS2当前有8个活动参与者也是如此。这同样适用于CMS2上托管的参与者 — 即使CMS1有10个活动参与者，它们也只能看到来自CMS1上托管的远程参与者的最多4个参与者的视频和同一CMS2上托管的其它参与者的视频。

注意：maxPeerVideoStreams仍是测试版（预览）功能。 

部署和方案示例

本文档中的信息基于以下示例部署：

• CMS集群，包含两台服务器：CMS1和CMS2
• 在这些服务器上配置的Loadlimit允许在呼叫分配开始后进行17次呼叫
• 为CMS服务器配置的CUCM路由组具有循环分配
• 使用AllEqual布局或5x5，这是为了允许最大可能参与者窗格，即25
• 30个参与者加入space1，该参与者在CMS1上具有优先级（用于负载均衡）

1. maxPeerVideoStreams设置为4，同时启用负载均衡

• 由于启用了loadbalancing，并且space1的优先级在CMS1上，因此前17个参与者将加入CMS1，直至其达到其全部容量。即将到来的学员18加入CMS2并创建分布式呼叫

maxPeerVideoStreams设置为4，且启用了负载均衡

• CMS1有17名参与者(1 - 17),CMS2有13名参与者(18 - 30)  
• 与会者1-17可以看到CMS1中的其他16个本地与会者，除了CMS2中只有4个参与者之外，总共有20个参与者显示在与会者1-17的屏幕上
• 参与者18 - 30会看到CMS2中的其他12个本地参与者，除了仅4个来自CMS1的参与者之外，总共16个参与者显示在参与者18 - 30的屏幕上
• 简而言之：CMS1托管的参与者可看到20个参与者，CMS2托管的参与者可在屏幕上看到16个参与者

2. maxPeerVideoStreams设置为4，同时禁用负载均衡

• 由于loadbalancing未启用，参与者从第二次呼叫开始加入两个CMS服务器上的会议。这是因为CUCM Route Group设置为circular，这意味着将按顺序向两个CMS服务器发送呼叫。呼叫1发送到CMS1，呼叫2发送到CMS2，呼叫3发送到CMS1，呼叫4发送到CMS2
• 这意味着预计每个CallBridge上托管的参与者为15人 — CMS1上有15人，CMS2上有15人

maxPeerVideoStreams设置为4，且已禁用负载均衡

• CMS1上的参与者会看到CMS1中的其他14个本地参与者，除CMS2中的4个参与者外，CMS1参与者的屏幕上还会显示总共18个参与者
• CMS2上的参与者可看到CMS2的其他14个本地参与者，除CMS1的4个参与者外，CMS2参与者的屏幕上还会显示总共18个参与者
• 总结：CMS1参与者和CMS2参与者在其屏幕上都看到18个参与者

3. maxPeerVideoStreams设置为9，同时启用负载均衡

• 由于loadbalancing已启用，并且space1的优先级在CMS1上，因此参与者在CMS1上加入直到其达到全部容量。即将到来的学员18加入CMS2并创建分布式呼叫

maxPeerVideoStreams设置为9，同时启用负载均衡

• CMS1有17名参与者(1 - 17),CMS2有13名参与者(18 - 30)  
• 与会者1-17可以看到CMS1中的其他16个本地与会者，除CMS2中的9个与会者外，共25个与会者显示在与会者1-17的屏幕上
• 与会者18 - 30可以看到CMS2的其他12个本地与会者，除CMS1的9个与会者外，共21个与会者显示在与会者18 - 30的屏幕上
• 总结：CMS1参与者可看到25个参与者，CMS2参与者可在屏幕上看到21个参与者

4. maxPeerVideoStreams设置为9，同时禁用负载均衡

• 由于loadbalancing未启用，参与者从第二次呼叫开始加入两个CMS服务器上的会议。这是因为CUCM Route Group设置为circular，这意味着将按顺序向两个CMS服务器发送呼叫。呼叫1发送到CMS1，呼叫2发送到CMS2，呼叫3发送到CMS1，呼叫4发送到CMS2
• 这意味着，预计每个CallBridge上托管的参与者数量为15 - CMS1上托管的参与者数量为15,CMS2上托管的参与者数量为15

maxPeerVideoStreams设置为9，且禁用负载均衡

• CMS1上的参与者会看到CMS1中的其他14个本地参与者，除CMS2中的9个参与者外，CMS1参与者的屏幕上还会显示总共23个参与者
• CMS2上的参与者可看到CMS2的其他14个本地参与者，除CMS1的9个参与者外，CMS2参与者的屏幕上还会显示总共23个参与者
• 总结：CMS1参与者和CMS2参与者在其屏幕上都看到23个参与者

故障排除

当前没有可用于此配置的特定故障排除信息。

可以使用Collaboration Solutions Analyzer工具进行日志分析。

相关信息

• 思科会议服务器上的负载平衡逻辑
• CMS配置文档
• CMS API和MMP编程指南