在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上具有优先级（用于负载均衡）的space1

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

• 由于负载均衡已启用且CMS1上的space1的优先级为，因此前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个本地参加者，除了来自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个本地参与者，除了4个CMS1的参与者，CMS2参与者的屏幕上还显示了总共18个参与者
• 小结：CMS1参与者和CMS2参与者都在其屏幕上看到18个参与者

3.maxPeerVideoStreams设置为9，并启用了负载均衡

• 由于启用负载均衡且CMS1上的space1的优先级为，因此参与者将加入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路由组设置为循环，这意味着呼叫将按顺序发送到两个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编程指南