المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

ما هي المعلمة maxPeerVideoStreams ومتى تدخل حيز التنفيذ؟

مثال على النشر والسيناريوهات

1. تم تعيين maxPeerVideoStreams على 4 مع تمكين LoadBalancing

2. تم تعيين maxPeerVideoStreams على 4 مع تعطيل LoadBalancing

3. تم تعيين maxPeerVideoStreams على 9 مع تمكين LoadBalancing

4. تم تعيين maxPeerVideoStreams على 9 مع تعطيل LoadBalancing

استكشاف الأخطاء وإصلاحها

معلومات ذات صلة

المقدمة

يصف هذا المستند السلوك المتوقع للمعلمة maxPeerVideoStreams عند إستخدامه في نظام مجموعة Cisco Meeting Server (CMS).

يتم ذكر هذه المعلمة في دليل المرجع السريع للمسؤول.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

- مكون Cisco Meeting Server Call Bridge (وتجميعها)

- تكوين واجهة برمجة التطبيقات (API) لخادم الاجتماعات من Cisco

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى إصدارات البرامج والمكونات المادية التالية:

- CMS 2.9.x

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

ما هي المعلمة maxPeerVideoStreams ومتى تدخل حيز التنفيذ؟

تم إدخال المعلمة maxPeerVideoStreams لأول مرة في الإصدار 2.3 من CMS. تتحكم هذه المعلمة في عدد تدفقات فيديو المشارك التي يمكن لخادم CMS إرسالها عبر مكالمة موزعة إلى خادم CMS آخر. يجب تعيينها على كل خادم CMS بشكل منفصل. تكون المعلمة maxPeerVideoStreams فعالة لعقد مؤتمر كبير وموزع عندما يكون هناك أكثر من 4 مشاركين في كل CallBridge.

ملاحظة: تعد MaxPeerVideoStreams ذات صلة فقط بمجموعة CMS التي تتألف من خادمين أو أكثر، وهي غير ذات صلة بخادم CMS واحد.

إذا لم يتم تعيين maxPeerVideoStreams، فإن السلوك الافتراضي ل CMS هو إرسال 4 تدفقات فيديو كحد أقصى عبر مكالمة موزعة إلى خادم CMS الآخر، فهذا هو السلوك السابق ل CMS 2.3. باستخدام CMS 2.3 وأعلى، من الممكن الآن تغيير هذا السلوك وتكوين CMS لإرسال 9 تدفقات فيديو كحد أقصى عبر المكالمة الموزعة بدلا من 4 فقط.

تصبح أهمية هذه المعلمة أكثر وضوحا مع المؤتمرات الكبيرة، إستضافة عدد كبير من المشاركين، واستخدام تخطيط AllEqual، الذي يسمح بحد أقصى 25 جزء ليتم عرضها على شاشة مشارك واحد. في هذه الحالة، إذا تم توزيع مؤتمر على خادمي CMS (على سبيل المثال CMS1 و CMS2)، وتم إستضافة أكثر من 4 مشاركين على كل خادم CMS لهذا المؤتمر (5 أو أكثر)، يتمكن المشاركون المستضافون على CMS1 فقط من مشاهدة الفيديو من 4 مشاركين من المشاركين عن بعد والذين تتم إستضافتهم على CMS2، بالإضافة إلى الفيديو من جميع المشاركين المحليين الآخرين المستضافين على مضيف خادم CMS (CMS1) المحلي، حتى إذا كان CMS2 يحتوي على 8 مشاركين نشطين حاليا. ينطبق الأمر نفسه على المشاركين المستضافين على CMS2 - لا يستطيعون مشاهدة الفيديو إلا من 4 مشاركين من المشاركين عن بعد الذين يستضيفهم CMS1 وفيديو المشاركين الآخرين المستضاف على نفس CMS2، حتى لو كان CMS1 يحتوي على 10 مشاركين نشطين.

ملاحظة: لا تزال ميزة maxPeerVideoStreams (معاينة) بيتا.

مثال على النشر والسيناريوهات

تستند المعلومات الواردة في هذا المستند إلى مثال النشر التالي:

- مجموعة CMS المكونة من خادمين، CMS1 و CMS2

- يسمح LoadLimit المكون على هذه الخوادم بإجراء 17 مكالمة، بعد بدء توزيع المكالمات

- يتم تكوين مجموعة توجيه CUCM لخوادم CMS باستخدام التوزيع الدائري

- يتم إستخدام تخطيط AllEqual، أو 5x5، وهذا للسماح بالحد الأقصى من أجزاء المشاركين، وهو 25

- 30 مشاركا ينضمون إلى Space1، الذي له أولوية (لموازنة التحميل) على CMS1

1. تم تعيين maxPeerVideoStreams على 4 مع تمكين LoadBalancing

- بما أن موازنة التحميل ممكنة وأولوية space1 على CMS1، فإن أول 17 مشاركا ينضمون إلى CMS1، حتى يصل إلى كامل سعته. ينضم المشارك المقبل 18 إلى CMS2 ويتم إنشاء مكالمة موزعة

تم تعيين maxPeerVideoStreams إلى 4 مع تمكين موازنة الأحمال

- هناك 17 مشاركا في الدورة الأولى (1 - 17)، و 13 مشاركا بشأن الدورة الثانية (18 - 30)

- المشاركين 1-17 يشاهدون المشاركين المحليين ال 16 الآخرين من الدورة الأولى للجمعية، إضافة إلى 4 مشاركين فقط من الدورة الثانية للجمعية، يعرض ما مجموعه 20 مشاركا على شاشات المشاركين 1-17

- ويشاهد المشاركون 18-30 المشاركين المحليين ال 12 الآخرين من الدورة الثانية للجنة السلامة البحرية، إضافة إلى 4 مشاركين فقط من الدورة الأولى للجنة السلامة البحرية، يعرض ما مجموعه 16 مشاركا على شاشات المشاركين 18-30

- ملخص: يقوم المشاركون المستضافون على CMS1 بزيارة 20 مشاركا، بينما يقوم المشاركون المستضافون على CMS2 برؤية 16 مشاركا على شاشاشاتهم

2. تم تعيين maxPeerVideoStreams على 4 مع تعطيل LoadBalancing

- وبما أن موازنة حمل غير ممكنة، ينضم المشاركون إلى المؤتمر على كلا خادمي CMS بدءا من المكالمة الثانية. وهذا يرجع لأن مجموعة مسار CUCM تم تعيينها على دائري، مما يعني أنه يتم إرسال المكالمات إلى كلا خادمي CMS بشكل تسلسلي. يتم إرسال المكالمة 1 إلى CMS1، يتم إرسال المكالمة 2 إلى CMS2، يتم إرسال المكالمة 3 إلى CMS1، يتم إرسال المكالمة 4 إلى CMS2

- هذا يعني أنه من المتوقع أن يجد 15 مشاركا يستضيفهم كل CallBridge - هناك 15 مشاركا في CMS1 و 15 مشاركا في CMS2

تم تعيين maxPeerVideoStreams إلى 4 مع تعطيل موازنة حمل

- يقوم المشاركون في الدورة الأولى CMS1 بمقابلة 14 مشاركا محليا آخرين من الدورة الأولى CMS، إضافة إلى 4 مشاركين من الدورة الثانية CMS، يتم عرض ما مجموعه 18 مشاركا على شاشات المشاركين في الدورة الأولى CMS1

- شاهد المشاركون في الدورة ال 14 مشاركا محليا من الدورة CMS2، إضافة إلى 4 مشاركين من الدورة، يظهر ما مجموعه 18 مشاركا على شاشات المشاركين في الدورة

- ملخص: كل من المشاركين في الدورة الأولى لمؤتمر إدارة المحتوى (CMS1) والمشاركين في الدورة الثانية لمؤتمر إدارة المحتوى (CMS2) يشاهدون 18 مشاركا على شاشاشاتهم

3. تم تعيين maxPeerVideoStreams على 9 مع تمكين LoadBalancing

- بما أن موازنة التحميل ممكنة وأولوية space1 موجودة على CMS1، ينضم المشاركون إلى CMS1 حتى تصل إلى سعتها الكاملة. ينضم المشارك المقبل 18 إلى CMS2 ويتم إنشاء مكالمة موزعة

تم تعيين maxPeerVideoStreams إلى 9 مع تمكين loadBalancing

- هناك 17 مشاركا في الدورة الأولى (1 - 17)، و 13 مشاركا بشأن الدورة الثانية (18 - 30)

- المشاركين 1-17 يشاهدون المشاركين المحليين ال 16 الآخرين من CMS1، بالإضافة إلى 9 مشاركين من CMS2، يعرض ما مجموعه 25 مشاركا على شاشات المشاركين 1-17

- ويشاهد المشاركون 18-30 المشاركين المحليين ال 12 الآخرين من الدورة الثانية للجنة السلامة البحرية، إضافة إلى 9 مشاركين من الدورة الأولى للجمعية، يعرض ما مجموعه 21 مشاركا على شاشات المشاركين 18-30

- ملخص: شاهد المشاركون في الدورة الأولى للجمعية 25 مشاركا، وشاهد المشاركون في الدورة 21 مشاركا على شاشاتهم

4. تم تعيين maxPeerVideoStreams على 9 مع تعطيل LoadBalancing

- وبما أن موازنة حمل غير ممكنة، ينضم المشاركون إلى المؤتمر على كلا خادمي CMS بدءا من المكالمة الثانية. وهذا يرجع لأن مجموعة مسار CUCM تم تعيينها على دائري، مما يعني أنه يتم إرسال المكالمات إلى كلا خادمي CMS بشكل تسلسلي. يتم إرسال المكالمة 1 إلى CMS1، يتم إرسال المكالمة 2 إلى CMS2، يتم إرسال المكالمة 3 إلى CMS1، يتم إرسال المكالمة 4 إلى CMS2

- هذا يعني أنه من المتوقع العثور على 15 مشاركا يستضيفهم كل CallBridge - يوجد 15 مشاركا على CMS1 و 15 مشاركا على CMS2

تم تعيين maxPeerVideoStreams إلى 9 مع تعطيل موازنة حمل

- يقوم المشاركون في الدورة الأولى CMS1 بمقابلة ال 14 مشاركا محليا الآخرين من الدورة الأولى CMS، إضافة إلى 9 مشاركين من الدورة الثانية CMS، يعرض ما مجموعه 23 مشاركا على شاشات المشاركين في الدورة الأولى CMS1

- شاهد المشاركون في الدورة ال 14 مشاركا محليا من الدورة CMS2، بالإضافة إلى 9 مشاركين من الدورة، يظهر ما مجموعه 23 مشاركا على شاشات المشاركين في الدورة

- ملخص: كل من المشاركين في الدورة الأولى لمؤتمر إدارة المحتوى (CMS1) والمشاركين في الدورة الثانية لمؤتمر إدارة المحتوى (CMS2) يشاهدون 23 مشاركا على شاشاشاتهم

استكشاف الأخطاء وإصلاحها

هناك حاليا ما من خاص أستكشاف الأخطاء وإصلاحها معلومات متوفرة لهذا التكوين.

يمكنك إستخدام أداة محلل حلول التعاون لتحليل السجل.

معلومات ذات صلة

- منطق موازنة التحميل على خادم الاجتماعات من Cisco

- وثائق تكوين CMS

- أدلة برمجة CMS API و MMP