目錄

簡介

必要條件

需求

採用元件

什麼是maxPeerVideoStreams引數？它何時生效？

部署和方案示例

1.maxPeerVideoStreams設定為4，同時啟用負載均衡

2.禁用負載均衡時，maxPeerVideoStreams設定為4

3.maxPeerVideoStreams設定為9，同時啟用負載均衡

4.禁用負載均衡時，maxPeerVideoStreams設定為9

疑難排解

相關資訊

簡介

本文描述在思科會議伺服器(CMS)群集中使用引數maxPeerVideoStreams時的預期行為。

管理員快速參考指南中提到了此引數。

必要條件

需求

思科建議您瞭解以下主題：

- Cisco Meeting Server Call Bridge元件（及其群集）

- Cisco Meeting Server 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仍是beta（預覽）功能。

部署和方案示例

本檔案中的資訊是根據以下範例部署：

- 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個本地參與者，除了來自CMS1的僅4個參與者之外，總共16個參與者顯示在參與者18 - 30的螢幕上

- 總而言之：CMS1託管的參與者可看到20個參與者，CMS2託管的參與者可在他們的螢幕上看到16個參與者

2.禁用負載均衡時，maxPeerVideoStreams設定為4

- 由於loadbalancing未啟用，因此參與者從第二次呼叫開始在兩個CMS伺服器上加入會議。這是因為CUCM路由組設定為circular，這意味著呼叫按順序傳送到兩個CMS伺服器。呼叫1傳送到CMS1，呼叫2傳送到CMS2，呼叫3傳送到CMS1，呼叫4傳送到CMS2

- 這意味著預計每個CallBridge上有15名參與者 — CMS1上有15名參與者，CMS2上有15名參與者

maxPeerVideoStreams設定為4，但禁用了負載平衡

- CMS1上的參與者會看到來自CMS1的其他14個本地參與者，除了CMS2的4個參與者之外，總共18個參與者顯示在CMS1參與者的螢幕上

- CMS2上的參與者會看到來自CMS2的其他14個本地參與者，除了CMS1的4個參與者之外，總共18個參與者顯示在CMS2參與者的螢幕上

- 總而言之：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路由組設定為circular，這意味著呼叫按順序傳送到兩個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個參與者

疑難排解

目前尚無適用於此組態的具體疑難排解資訊。

您可以使用Collaboration Solutions Analyzer工具進行日誌分析。

相關資訊

- 思科會議伺服器上的負載平衡邏輯

- CMS配置文檔

- CMS API和MMP程式設計指南