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

简介

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

此参数在《管理员快速参考指南》中提及。 

先决条件

要求

Cisco 建议您了解以下主题：

• 思科会议服务器呼叫网桥组件（及其集群）
• 思科会议服务器API配置

使用的组件

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

• CMS 2.9.x

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

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

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

注意：maxPeerVideoStreams仅与由两台或多台服务器组成的CMS群集相关，与单个CMS服务器无关。 

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

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

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

部署和场景示例

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

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

1.maxPeerVideoStreams设置为4，启用了loadBalancing

• 由于负载均衡已启用且CMS1上的space1优先级为，因此前17个参与者会加入CMS1，直到其满载。即将加入的参与者18在CMS2上加入，并创建分布式呼叫

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

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

2.maxPeerVideoStreams设置为4，并禁用了loadBalancing

• 由于负载平衡未启用，因此，从第二次呼叫开始，参加者将加入两个CMS服务器上的会议。这是因为CUCM路由组设置为循环，这意味着呼叫按顺序发送到两个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，启用了loadBalancing

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

4.maxPeerVideoStreams设置为9，并禁用了loadBalancing

• 由于负载平衡未启用，因此，从第二次呼叫开始，参加者将加入两个CMS服务器上的会议。这是因为CUCM路由组设置为循环，这意味着呼叫按顺序发送到两个CMS服务器。呼叫1被发送到CMS1，呼叫2被发送到CMS2，呼叫3被发送到CMS1，呼叫4被发送到CMS2
• 这意味着，它预计会在每个CallBridge上找到15个托管参与者 — 15个参与者在CMS1上，15个参与者在CMS2上

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

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

故障排除

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

您可以使用协作解析器工具进行日志分析。

相关信息

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