简介
本文档介绍在思科会议服务器(CMS)集群中使用参数maxPeerVideoStreams时的预期行为。
此参数在《管理员快速参考指南》中提及。
先决条件
要求
Cisco 建议您了解以下主题:
- 思科会议服务器呼叫网桥组件(及其集群)
- 思科会议服务器API配置
使用的组件
本文档中的信息基于以下软件和硬件版本:
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您的网络处于活动状态,请确保您了解所有命令的潜在影响。
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个参与者
故障排除
当前没有可用于此配置的特定故障排除信息。
您可以使用协作解析器工具进行日志分析。
相关信息