إرشادات للترقية السلسة من Cisco Meeting Server 2.9 إلى 3.0 (وما بعده)

المقدمة

يصف هذا المستند تحديات ترقية نشر Cisco Meeting Server الذي يشغل الإصدار 2.9 (أو إصدار سابق) إلى 3.0 (أو إصدار أحدث) وكيفية معالجة تلك التحديات لعملية ترقية سلسة.

الميزات التي تمت إزالتها: تمت إزالة XMPP (الذي يؤثر على WebRTC)، وجهات الاتصال/موازن التحميل، WebBridge

الميزات التي تم تغييرها: أصبحت أجهزة التسجيل والتسييل الآن SIP، كما تم إستبدال WebBridge ب WebBridge3

يغطي هذا المستند الموضوعات التي تحتاج إلى مراعاتها قبل الترقية فقط. وهو لا يغطي جميع الميزات الجديدة المتوفرة في 3.x.

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

المتطلبات

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

• إدارة سي إم إس
• ترقيات CMS
• إنشاء الشهادة وتوقيعها

وكل ما ذكر هنا يوجز في وثائق مختلفة.  من المستحسن دائما قراءة ملاحظات إصدار المنتج والتراجع إلى أدلة البرمجة وأدلة النشر إذا كنت بحاجة إلى مزيد من التوضيح حول الميزات: أدلة تكوين وتثبيت CMS وملاحظات إصدار منتج CMS .

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

تستند المعلومات الواردة في هذا المستند إلى خادم الاجتماعات من Cisco.

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

معلومات أساسية

يهدف هذا المستند إلى أن يكون إرشادا في حالة توفر نشر CMS 2.9.x (أو إصدار سابق) بالفعل، بغض النظر عن حالة دمج واحد أو المرونة، وعندما تخطط للترقية إلى CMS 3.0.  تتعلق المعلومات الواردة في هذا المستند بجميع نماذج CMS.  

ملاحظة: لا يمكن ترقية السلسلة X إلى CMS 3.0. يجب عليك التخطيط لاستبدال خوادم السلسلة X في أقرب وقت ممكن.

معلومات مهمة حول الترقيات

الطريقة الوحيدة المدعومة لترقية CMS هي ترقية تدريجية.  وقت كتابة هذا، CMS 3.5 تم إطلاق.  إذا كنت في CMS 2.9، يجب عليك الترقية بطريقة تدريجية (2.9 —> 3.0 —> 3.1 —> 3.2 —> 3.3 —> 3.4 —> 3.5 (عملية ترقية الملاحظة لها تغييرات اعتبارا من CMS 3.5، لذلك اقرأ ملاحظات الإصدار بعناية!!)

إذا لم تقم بإجراء ترقية تدريجية، وتعاني من سلوك غير عادي، يمكن أن يطلب منك TAC الرجوع إلى إصدار أقدم والبدء من جديد.

كما يجب على CMS، اعتبارا من CMS 3.4، إستخدام الترخيص الذكي.  لا يمكنك الترقية إلى CMS 3.4 أو الأحدث ولا تزال تستخدم التراخيص التقليدية.  لا تقم بالترقية إلى CMS 3.4 أو الأحدث إلا إذا قمت بإعداد "الترخيص الذكي".

ملخص للأشياء التي يجب أخذها بعين الإعتبار

أستخدم هذه الأسئلة للتنقل إلى الأقسام المتعلقة بوضعك.  يشير كل إعتبار إلى إرتباط تشعبي إلى وصف أكثر تفصيلا مقدم في هذا المستند.

التراخيص

هل لديك ما يكفي من التراخيص الشخصية متعددة الأطراف (PMP) / التراخيص المشتركة متعددة الأطراف (SMP) على الخوادم الخاصة بك قبل الترقية؟

في 3.0 يتم تخصيص تراخيص PMP، حتى في حالة عدم تسجيل دخول المستخدم. على سبيل المثال، إذا كنت قد قمت باستيراد 10000 مستخدم من خلال بروتوكول LDAP، ولكن لديك 100 ترخيص PMP فقط، فإن هذا يخرجك من حالة التوافق بمجرد الترقية إلى 3.0.  بالنسبة لحالة الاستخدام هذه، تأكد من التحقق من عدم تعيين المستأجرين الذين لديهم مجموعة ملفات تعريف مستخدم و/أو نظام/ملفات تعريف لمعرفة ما إذا تم تعيين ملف تعريف مستخدم مع HASlicense بقيمة true أم لا.

كيفية التحقق من UserProfile على واجهة برمجة التطبيقات ومعرفة ما إذا كان لديك مجموعة HASlicense=true (بمعنى مستخدمي PMP المرخص لهم)، تتم تغطيتها بمزيد من التفاصيل في هذا القسم. 

هل لديك عدسات PMP/SMP في ملف CMS.lic الحالي؟

نظرا لتغييرات سلوك الترخيص في 3.0 وما بعده، يجب عليك تأكيد ما إذا كانت لديك تراخيص كافية ل PMP/SMP قبل إجراء الترقية. وهذا موضح بمزيد من التفصيل في هذا القسم.

هل تم نشر مدير الاجتماعات (CMM) من Cisco؟

يتطلب CMS 3.0 وجود CMM 3.0 بسبب التغييرات في كيفية التعامل مع التراخيص. يوصى بنشر CMM 2.9 قبل إجراء ترقية لبيئتك إلى 3.0 حيث يمكنك مراجعة تقريرك الذي مدته 90 يوما حول إستهلاك التراخيص على مدار 90 يوما الماضية. وهذا موضح بمزيد من التفصيل في هذا القسم.

هل لديك ترخيص ذكي؟

يتطلب CMS 3.0 وجود CMM 3.0 بسبب التغييرات في كيفية التعامل مع التراخيص. إذا كنت تستخدم "الترخيص الذكي" من خلال CMM بالفعل، تأكد من أن لديك تراخيص PMP و SMP مرتبطة بمجموعتك.

WebBridge (عميل WebRTC و CMA)

هل تستخدم WebRTC في CMS 2.9؟

لقد تغير WebBridge في CMS 3. 0 بشكل ملحوظ.  للحصول على إرشادات حول الترحيل من WebBridge2 إلى WebBridge3 واستخدام تطبيق ويب، يتم العثور على المعلومات في هذا القسم.

هل يستخدم المستخدمون لديك عميل CMA السميك؟

بما أن هذه العملاء تستند إلى XMPP، فلا يمكن إستخدام هذه العملاء بعد الآن بعد الترقية نظرا لإزالة خادم XMPP. إذا كان هذا ينطبق على حالة الاستخدام الخاصة بك، فيمكنك العثور على مزيد من المعلومات في هذا القسم.

هل تستخدم الدردشة في WebRTC؟

تمت إزالة وظيفة الدردشة من تطبيق ويب في 3.0. في CMS 3.2، تتم إعادة إدخال المحادثة، ولكنها ليست مستمرة.  يمكنك العثور على مزيد من المعلومات حول هذه الميزة في هذا القسم.

هل يقوم المستخدمون لديك بإجراء مكالمات من نقطة إلى نقطة من WebRTC إلى الأجهزة؟

في CMS 3.0، لا يمكن لمستخدم تطبيق ويب الاتصال مباشرة بجهاز آخر بعد الآن. يجب الآن الانضمام إلى مساحة الاجتماع، والحصول على الإذن لإضافة مشاركين إلى الاجتماع للقيام بنفس الإجراء.  يمكنك العثور على مزيد من المعلومات حول هذا الجزء في هذا القسم.

هل يقوم المستخدمون بإنشاء CoSpaces الخاصة بهم من WebRTC؟

في 3.0، لكي يتمكن مستخدمو تطبيق الويب من إنشاء مساحاتهم الخاصة من العميل، يلزم إنشاء CoSpaceTemplate في واجهة برمجة تطبيقات (API) وتخصيصه للمستخدم. يمكن أن يكون ذلك يدويا أو تلقائيا أثناء إستيراد LDAP.  تمت إزالة CanCreateCoSpaces من UserProfile.  يمكنك العثور على مزيد من المعلومات حول هذه الميزة في هذا القسم.

تغييرات واجهة المستخدم الرسومية (GUI) للويب

هل لديك إعدادات WebBridge تم تكوينها في واجهة المستخدم الرسومية (GUI) لمسؤول الويب؟

تتم إزالة إعدادات WebBridge من واجهة المستخدم الرسومية (GUI) في 3.0، لذلك يجب عليك تكوين جسور الويب في واجهة برمجة التطبيقات (API) ولاحظ ما هي إعداداتك الحالية في واجهة المستخدم الرسومية (GUI) حتى يمكنك تكوين ملفات تعريف WebBridgeProfile في واجهة برمجة التطبيقات وفقا لذلك.  يمكنك العثور على مزيد من المعلومات حول هذا التغيير في هذا القسم.

هل لديك إعدادات خارجية تم تكوينها في واجهة المستخدم الرسومية (GUI) لمسؤول الويب؟

تمت إزالة الإعدادات الخارجية من واجهة المستخدم الرسومية (GUI) في CMS 3.1.  إذا كان لديك إما WebBridge URL أو IVR مكون في CMS 3.0 أو واجهة المستخدم الرسومية (Configuration —> General —> External Settings) الخاصة بك، فقد تمت إزالة هذه الإعدادات من صفحة الويب ويجب الآن تكوينها في واجهة برمجة التطبيقات. لا تتم إضافة الإعدادات السابقة قبل الترقية إلى 3.1 إلى واجهة برمجة التطبيقات، ويجب القيام بذلك يدويا.  يمكنك العثور على مزيد من المعلومات حول هذا التغيير في هذا القسم.

المسجلات / المنظومات

هل تستخدم حاليا أي مسجل (سجلات) CMS و/أو جهاز (أجهزة) تسلسلي؟

يعتمد الآن مكون مسجل CMS و Streamer على SIP بدلا من XMPP. لذلك بما أن XMPP يتم إزالته، فإن هذه تحتاج أن يكون نسخت بعد الترقية. يمكنك العثور على مزيد من المعلومات حول هذا التغيير في هذا القسم.

اعتبارات Expressway من Cisco

ما هو إصدار Expressway الحالي من Cisco إذا كنت تستخدم Expressway إلى WebRTC للوكيل؟ 

تتطلب CMS 3.0 الإصدار Expressway 12.6 أو إصدار أحدث.  يمكنك العثور على مزيد من المعلومات حول ميزة وكيل WebRTC هذه في هذا القسم.

CMS Edge

هل لديك حاليا CMS Edge في بيئتك؟

يتم إدخال CMS Edge مرة أخرى على CMS 3.1 مع إمكانية توسع أعلى للاتصالات الخارجية.  يمكنك العثور على مزيد من المعلومات حول هذا الجزء في هذا القسم.

CMS (Acano) X-series

هل لديك حاليا خوادم من السلسلة X في بيئتك؟ 

لا يمكن ترقية هذا الخادم إلى CMS 3.0 ويجب أن تنظر في إستبدال هذه العناصر قريبا (نقل إلى جهاز ظاهري أو جهاز CMS قبل الترقية إلى 3.0). يمكنك العثور على إشعار انتهاء دورة الحياة حول هذه الخوادم في هذا الارتباط.

SIP Edge

هل تستخدم حاليا SIP Edge في بيئتك؟

تم إهمال SIP Edge بالكامل اعتبارا من CMS 3.0.  يجب إستخدام Expressway من Cisco لإدخال مكالمات SIP إلى CMS الخاصة بك. يرجى الاتصال بممثل حساب Cisco حول كيفية الحصول على Expressways لمؤسستك.

المزيد من المعلومات

الترخيص - فحص التراخيص قبل الترقية

تعد حالة ترخيص عدم التوافق هي المشكلة الأكثر تأثيرا عند الترقية إلى الإصدار 3.0 أو أعلى من الإصدار 2.x. يوضح هذا القسم كيفية تحديد مقدار تراخيص PMP/SMP التي تحتاج إليها لإجراء ترقية سلسة.

قبل ترقية عملية النشر إلى 3. 0، قم بنشر CMM 2. 9 وفحص تقرير 90 يوما ضمن علامة التبويب تراخيص لمعرفة ما إذا كان إستخدام الترخيص قد بقي تحت مبلغ الترخيص المخصص الحالي على عقد CMS:

إذا كنت تستخدم الترخيص التقليدي (يتم تثبيت ملف CMS محليا على عقد CMS الخاصة بك)، فتحقق من ملف ترخيص CMS لمعرفة كميات التراخيص الشخصية والمشتركة (100 / 100 طبقا للصورة هنا) على كل من عقد CMS (قم بالتنزيل من خلال WinSCP من كل عقدة CallBridge).

إذا كنت تستخدم الترخيص الذكي بالفعل، فتحقق من عدد تراخيص PMP/SMP التي تم تعيينها في البوابة الذكية لبرنامج Cisco لخوادم CMS.

افتح التقرير لمدة 90 يوما (ملف ZIP باسم license-data.zip) وافتح الملف الذي يحمل اسم daily-peak.csv.

في Excel، قم بفرز عمود PMP حسب Z إلى A للحصول على القيم الأعلى إلى الأعلى ثم قم بتنفيذ نفس الإجراء لعمود SMP.  هل القيم التي تراها في هذا الملف أقل من التراخيص المتوفرة في ملف ترخيص CMS؟ إذا كان الجواب نعم، فأنتم على ما يرام ومتقيدون كاملا. وإذا لم يكن الأمر كذلك، فإن ذلك يؤدي إلى إنشاء تحذيرات و/أو أخطاء على النحو المشار إليه في الشكل 6 في القسم 1.7.3 من دليل نشر نظام إدارة المحتوى الذي يمكنك العثور على مزيد من المعلومات عنه أيضا في القسم 1.7.4.

وفقا للصورة على سبيل المثال، تم إستخدام 2.1667 ترخيصا للأجهزة متعددة المعالجات (SMP)، ولم يتم إستخدام أي تراخيص للأجهزة متعددة المعالجات (PMP) وفقا للحد الأقصى من التراخيص خلال الأيام التسعين الماضية. يشير ملف CMS.lic إلى 100 وحدة من كل نوع من الترخيص بحيث يكون هذا الإعداد متوافق تماما. لذلك لا توجد مشاكل متعلقة بالترخيص عند ترقية هذا الإعداد إلى CMS 3.0. ومع ذلك، لا يزال هناك مشكلة عندما يكون قد تم إستيراد 10000 مستخدم من خلال LDAP على الإعداد. كما هو الحال حينئذ، يكون لديك 100 ترخيص PMP فقط، ولكنك تقوم بتخصيص 10000 (مع تعيين UserProfile مع HASlicense على True) لذلك في هذه الحالة تكون خارج نطاق التوافق بمجرد الترقية إلى 3.0. المزيد حول هذا في القسم التالي.

حدد عدد المستخدمين الذين تم تعيينهم لترخيص PMP بمجرد الترقية

يتم تعيين ترخيص PMP تلقائيا لكل المستخدمين الذين يتم استيرادهم واستخدام ملف تعريف المستخدم مع HASlicense=true في CMS 3.0. 

في واجهة برمجة التطبيقات، تحقق من عدد ملفات تعريف المستخدمين لديك وتحقق مما إذا كان لدى أي منهم مجموعة "hasLicense=true".  إذا كان الأمر كذلك، فعليك التحقق من مكان تعيين ملفات تعريف المستخدمين هذه. 

يمكن تعيين UserProfile على أي من هذه المستويات:

1. مصادر LDAP
2. مستأجرين
3. النظام/ملفات التعريف

تحقق من كافة المواقع الثلاثة لملفات تعريف المستخدمين المعينة التي تحتوي على HASlicense=true.

1 - مصادر/مستأجرين نظام المساعدة الإنمائية

لكل LDAPsource يستخدم مستأجرا أو ملف تعريف مستخدم، يتم تعيين ترخيص PMP للمستخدمين الذين تم استيرادهم مع هذا ldapSource عندما يتم تعيين المعلمة hasLicense إلى True.  في حالة وجود مستأجر، يجب النقر فوق معرف المستأجر لمعرفة ما إذا كان لديه ملف تعريف مستخدم معين، ثم التحقق مما إذا كان ملف تعريف المستخدم هذا مكونا ب 'hasLicense=true'.  في حالة عدم وجود مستأجر، ولكن يوجد مجموعة UserProfile، انقر فوقها لمعرفة ما إذا كان لديه 'hasLicense=true'.  إذا كانت إحدى الطريقتين تحتوي على 'hasLicense=true'، فيمكنك التحقق من عدد المستخدمين الذين تم استيرادهم عن طريق تنفيذ GET ل 'api/v1/users' والتصفية للمجال المستخدم ل jidMapping على تعيين الأقل المرتبط ب ldapSource على سبيل المثال.

ملاحظة: قد يكون هذا أكثر تعقيدا في الحالات الأخرى التي تحتاج فيها إلى التحقق من ذلك باستخدام تعيينات ActiveDirectory وعوامل التصفية التي قمت بإنشائها.

الخطوة 1. العثور على معرف التعيين من ldapSource.

الخطوة 2. ابحث عن ldapMappings للعثور على jidMapping.

الخطوة 3. البحث في API/v1/المستخدمين عن المجال المستخدم في jidMapping.

الخطوة 4. إضافة المستخدمين الذين تم العثور عليهم من كل ldapSource.  هذا هو عدد مستخدمي LDAP المستوردين الذين يحتاجون إلى تراخيص PMP. 

2 - النظام/ملفات التعريف

إذا تم تعيين UserProfile على مستوى النظام/ملفات التعريف، وكان لملف تعريف المستخدم هذا "hasLicense=true"، يتم تعيين ترخيص PMP لأي مستخدم تم إستيراده إلى CMS عند ترقية الخادم.  إذا قمت باستيراد 10000 مستخدم ولكن لديك 100 PMPs فقط، يؤدي ذلك إلى عدم توافقك عند الترقية إلى CMS 3.0، وقد يتسبب في ظهور رسالة لمدة 30 ثانية على الشاشة والمطالبة الصوتية في بداية المكالمات.  

إذا كان UserProfile على مستوى النظام يشير إلى أن المستخدمين يحصلون على PMP، انتقل إلى API/V1/المستخدمين لمعرفة عدد المستخدمين الموجودين في المجموع:

إذا كنت قد استوردت مسبقا كل المستخدمين من LDAP الخاص بك، ولكن تأكد الآن أنك تحتاج فقط إلى مجموعة فرعية معينة من تلك القائمة، قم بإنشاء مرشح أفضل في LDAPsource الخاص بك بحيث يستورد فقط المستخدمين الذين تريد أن يتم تعيين تراخيص PMP لهم. راجع عامل التصفية على ldapSource ثم قم بتنفيذ مزامنة LDAP جديدة في API/v1/ldapsync.  يؤدي ذلك إلى إستيراد المستخدمين المطلوبين فقط وإزالة كافة المستخدمين الآخرين من عملية الاستيراد السابقة هذه. 

ملاحظة: إذا قمت بهذا بشكل صحيح وكانت عملية الاستيراد الجديدة تقوم فقط بإزالة المستخدمين غير المرغوب فيهم، فلن تتغير معرفات CoSpace CallID والأسرار المتبقية، ولكن إذا قمت بخطأ، قد يؤدي ذلك إلى تغيير كافة معرفات الاتصال والأسرار.  قم بإجراء عملية نسخ إحتياطي لعقد قاعدة البيانات قبل محاولة القيام بذلك إذا كنت قلقا بشأن ذلك!

هل لديك تراخيص SMP كافية؟

عندما كنت تنظر إلى قممك اليومية من تقرير ال 90 يوم ل CMM، هل لديك ما يكفي من تراخيص SMP لتغطية قمتك؟  يتم إستخدام تراخيص SMP عندما لا يتم تعيين ترخيص PMP لمالك الاجتماع (إما كمالك CoSpace / إجتماع مخصص / إجتماع TMS مجدول).  إذا كنت تستخدم SMP عمدا ولديك ما يكفي لتغطية أوقات الذروة، فلا بأس بذلك. إذا قمت بفحص فترة الذروة التي تبلغ 90 يوما ل SMP ومن غير الواضح لماذا يتم إستهلاكها، فإليك بعض الأشياء التي يجب التحقق منها.

1. تستخدم المكالمات المؤقتة (كما تم تصعيدها من CUCM) ترخيص SMP إذا كان الجهاز المستخدم للدمج غير مقترن بمستخدم تم تعيين ترخيص PMP له في CMS من خلال UserProfile.  يوفر CUCM المعرف الفريد العمومي للمستخدم الذي يقوم بتصعيد الاجتماع.  إذا كان GUID هذا يماثل مستخدم LDAP مستورد من خادم الاجتماعات بترخيص PMP معين، يتم إستخدام ترخيص ذلك المستخدم.

2. إذا لم يتم تعيين ترخيص PMP لمالك CoSpace، فإن الاستدعاءات إلى تلك CoSpaces المحددة تستخدم ترخيص SMP.

3. إذا تم جدولة الاجتماع في الإصدار 15.6 من TMS أو الأحدث، يتم إرسال مالك الاجتماع إلى CMS وإذا لم يتم تعيين ترخيص PMP لذلك المستخدم، يستخدم هذا الاجتماع ترخيص SMP.

تكوين CMM

بدءا من CMS 3.0، يلزم توفر CMM 3.0 حتى يعمل CMS بشكل صحيح.  CMM مسؤول عن ترخيص CMS، لذلك إذا كنت تخطط لترقية CMS إلى 3.0، يجب أن يكون لديك خادم CMM.  يوصى بنشر CMM 2.9 أثناء وجودك على CMS 2.9 حتى يمكنك التحقق من إستهلاك الترخيص قبل الترقية.

يقوم CMM بفحص جميع المكالمات الإضافية الخاصة بترخيص SMP و PMP وترخيص CallBridge.  وهو يستخدم الرقم الأعلى على مستوى الأجهزة المختلفة داخل نظام المجموعة. 

على سبيل المثال، إذا كان CMS1 يحتوي على 20 ترخيص PMP و 10 تراخيص SMP، وكان CMS2 يحتوي على 40 ترخيص PMP و 5 تراخيص SMP في الترخيص التقليدي، فإن CMM أفادت بأن لديك 40 ترخيص PMP و 10 تراخيص SMP لاستخدامها.

إذا كان لديك تراخيص PMP أكثر من المستخدمين المستوردين، فليس لديك أي مشاكل متعلقة بتراخيص PMP (أو SMP) ولكن إذا قمت بالتحقق من أن الحد الأقصى هو 90 يوما ووجدت أنك قد أستخدمت أكثر من المتاح، لا يزال يمكنك الترقية إلى CMS 3.0 واستخدام ترخيص الإصدار التجريبي لمدة 90 يوما على CMM لفرز الأشياء باستخدام ترخيصك، أو إتخاذ إجراء قبل الترقية.

تكوين WebBridge (عميل WebRTC و CMA)

يعمل CMS 3.0 على إزالة مكون خادم XMPP، وبذلك، يعمل على إزالة WebBridge والقدرة على إستخدام عميل CMA المثبت لديك.  WebBridge3 هو ما يتم إستخدامه الآن لتوصيل مستخدمي تطبيق الويب (المشار إليهم سابقا باسم مستخدمي WebRTC) بالاجتماعات باستخدام المستعرض.  عند الترقية إلى 3.0، يلزمك تكوين webbridge3. 

ملاحظة: لا يعمل عميل CMA السميك بعد الترقية إلى CMS 3. 0!

يقوم هذا الفيديو بتوجيهك خلال العملية الخاصة بكيفية إنشاء شهادات WebBridge 3.

https://video.cisco.com/detail/video/6232772471001?autoStart=true&q=cms

قبل الترقية إلى 3.0، يجب على العملاء التخطيط لكيفية تكوين WebBridge3. وأهم الخطوات يتم إبرازها هنا.

1. تحتاج إلى مفتاح وسلسلة نتائج ل WebBridge3.  يمكن إستخدام شهادة WebBridge القديمة إذا كانت تحتوي على كافة CMS server FQDNs أو عناوين IP على أنها اسم موضوع بديل (SAN)/ اسم مشترك (CN) التي تقوم بتشغيل WebBridge3، وإذا تم الوفاء بأي من هذه:

أ. لا تحتوي الشهادة على إستخدام مفتاح محسن (بمعنى أنه يمكن إستخدامها إما كعميل أو خادم).

ب. تشتمل الشهادة على مصادقة العميل والخادم.  يحتاج بروتوكول HTTPs فقط إلى مصادقة الخادم، بينما تتطلب شهادة C2W كلا من الخادم والعميل).

2. إذا كنت تريد إنشاء شهادة جديدة لشهادة WebBridge3 https، يوصى بتوقيعها بشكل عام (لتجنب تحذيرات الشهادات على العميل عند إستخدام تطبيق ويب).  يمكن إستخدام نفس هذا المرجع ل "WebBridge3 c2w cert"، ويجب أن يحتوي المرجع على FQDN الخاص بخوادم WebBrige في شبكة منطقة التخزين (SAN)/CN.

3. تحتاج CallBridge إلى الاتصال ب WebBridge3 الجديد باستخدام منفذ تم تكوينه في أمر webBridge3 c2w listen. هذا يمكن أن يكون أي منفذ متوفر، مثل 449. يحتاج المستخدمون إلى التأكد من أن جسور الاتصال يمكن أن تتصل ب WebBridge3 على هذا المنفذ، كما يجب إجراء أي تغييرات على جدار الحماية مسبقا، إذا لزم الأمر.  لا يمكن أن يكون نفس المنفذ المستخدم من قبل "webbridge https" للاستماع إليه.

قبل ترقية CMS إلى 3.0، يوصى بإجراء عملية نسخ إحتياطي باستخدام "لقطة إحتياطية <servername_date>"، ثم تسجيل الدخول إلى صفحة WebAdmin على عقد CallBridge لإزالة كافة إعدادات XMPP وإعدادات WebBridge.  ثم قم بالاتصال ب MMP على الخوادم الخاصة بك، وقم بإجراء هذه الخطوات على جميع الخوادم الأساسية التي تحتوي على بروتوكول XMPP و WebBridge عبر اتصال SSH:

1. تعطيل xmpp
2. إعادة تعيين xmpp
3. XMPP CERTS none
4. بدون مجال XMPP
5. تعطيل WebBridge
6. WebBridge لا تنصت
7. لا توجد شهادة WebBridge
8. WebBridge Trust none

بمجرد الترقية إلى 3.0، ابدأ بتكوين WebBridge3 على جميع الخوادم التي كانت تشغل WebBridge سابقا.  يجب القيام بهذا نظرا لوجود سجلات DNS موجودة بالفعل تشير إلى هذه الخوادم، لذا بهذه الطريقة تتأكد من أنه إذا تم إرسال مستخدم إلى WebBridge3، فإنه جاهز لمعالجة الطلب.

تكوين WebBridge3 (عبر اتصال SSH بالكامل)

الخطوة 1. تكوين منفذ الاستماع ل Webbridge3 http.

WebBridge3 https مع الاستماع إلى: 443

الخطوة 2. تكوين شهادات Webbridge3 لاتصالات المستعرض.  هذه هي الشهادة المرسلة إلى المستعرضات ويجب توقيعها من قبل مرجع مصدق عام (CA) وتحتوي على FQDN المستخدم في المستعرض للثقة في الاتصال.

WebBridge3 https certs wb3.key wb3trust.cer (يلزم أن تكون هذه سلسلة ثقة: قم بإنشاء وحدة ثقة تحتوي على وحدة نهاية في الأعلى، تليها وحدات CA الوسيطة بالترتيب، مع الانتهاء من RootCA).

الخطوة 3. قم بتكوين منفذ لاستخدامه في الاستماع لاتصالات CallBridge إلى إتصالات WebBridge (c2w).  بما أن 443 يتم إستخدامه لمنفذ إستماع webbridge3 https، فيجب أن يكون هذا التكوين منفذا مختلفا ومتوفرا مثل 449 على سبيل المثال.

WebBridge3 c2w استمع إلى a:449

4. تكوين الشهادات التي يرسلها WebBridge إلى CallBridge للثقة c2w

WebBridge3 c2w certs wb3.key wb3trust.cer

5. قم بتكوين مخزن الثقة الذي يستخدمه WB3 بالثقة في شهادة CallBridge.  يجب أن يكون هذا هو نفس الشهادة المستخدمة في حزمة cllbridge ca (ويجب أن تكون حزمة من الشهادات الوسيطة في الأعلى، و cCA الجذر في النهاية، متبوعة بإرجاع عملية نقل واحدة).

WebBridge3 c2w Trust rootca.cer

6. تمكين WebBridge3

تمكين WebBridge3

تغييرات تكوين CallBridge (في جميع أنحاء اتصال SSH)

الخطوة 1. قم بتكوين الثقة في CallBridge باستخدام شهادة/حزمة CA التي وقعت على شهادة WebBridge3 c2w.

CallBridge Trust c2w rootca.cer

الخطوة 2. قم بإعادة تشغيل CallBridge لتفعيل الثقة الجديدة.  يؤدي هذا إلى إسقاط كافة المكالمات على هذا الاتصال المعين، لذا أستخدم هذا بحذر.

إعادة تشغيل CallBridge

تكوين واجهة برمجة التطبيقات (API) ل CallBridges للاتصال ب WebBridge3

1. قم بإنشاء كائن WebBridge جديد باستخدام POST في واجهة برمجة التطبيقات (API) ومنحه قيمة URL باستخدام FQDN ومنفذ تم تكوينه على القائمة البيضاء للواجهة WebBridge c2w (الخطوة 3 في تكوين WebBridge3)

c2w://webbridge.darmckin.local:449

عند هذه النقطة، يعمل WebBridge3 مرة أخرى، ويمكنك ضم المساحات كضيف أو إذا قمت باستيراد مستخدمين مسبقا، فيجب أن يكونوا قادرين على تسجيل الدخول.

أذونات إنشاء مساحة مستخدم تطبيق ويب

هل تم إستخدام المستخدمين لديك ليتمكنوا من إنشاء مساحاتهم الخاصة في WebRTC؟  اعتبارا من CMS 3.0، لا يمكن لمستخدمي تطبيق ويب إنشاء CoSpaces الخاصة بهم ما لم يكن لديهم قالب Cospace معين لهم يسمح بذلك.

حتى مع تعيين CoSpaceTemplate، لا يؤدي ذلك إلى إنشاء مساحة يمكن للآخرين الاتصال بها (لا يوجد URI أو لا يوجد معرف اتصال أو رمز مرور)، ولكن إذا كان CoSpace لديه CallLegProfile مع 'addParticipantAllowed'، فيمكنهم الاتصال من المساحة.

للحصول على سلاسل الطلب التي يمكن إستخدامها لاستدعاء المساحة الجديدة، يجب أن يحتوي CoSpaceTemplate على إعداد accessMethodTemplate (راجع 2.9 ملاحظات الإصدار - https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-2-9/Cisco-Meeting-Server-Release-Notes-2-9-6.pdf).

في واجهة برمجة التطبيقات، قم بإنشاء coSpaceTemplate (قوالب) ثم قم بإنشاء AccessMethodTemplate (قوالب) وقم بتعيين coSpaceTemplate إلى ldapUserCoSpaceTemplateSources أو يمكنك تعيين coSpaceTemplate يدويا لمستخدم في API/V1/المستخدمين.

يمكنك إنشاء CoSpaceTemplates و AccessMethodsTemplates وتعيينهما.  انظر دليل واجهة برمجة تطبيقات CMS للحصول على مزيد من المعلومات (https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-programming-reference-guides-list.html)

CoSpaceTemplate (تكوين API)

الاسم: أي اسم تريد منحه CoSpaceTemplate.

الوصف: وصف موجز إذا كان ذلك مطلوبا.

CallProfile: هل تريد إستخدام White CallProfile أية مسافات تم إنشاؤها باستخدام هذا القالب؟ وفي حالة عدم توفيره، فإنه يستخدم ما يتم ضبطه على مستوى النظام/ملف التعريف.

calllegPrrofile: ما هي أنواع CallLegProfile التي تريد إستخدام أي مسافات تم إنشاؤها باستخدام هذا القالب؟  وفي حالة عدم توفيره، فإنه يستخدم ما يتم ضبطه على مستوى النظام/ملف التعريف.

dialInSecurityProfile: ما هو الطلب InSecurityProfile الذي تريد إستخدام أي مساحات تم إنشاؤها بهذا القالب؟ وفي حالة عدم توفيره، فإنه يستخدم ما يتم ضبطه على مستوى النظام/ملف التعريف.

AccessMethodTemplate (تكوين API)

الاسم: أي اسم تريد منحه CoSpaceTemplate.

UriGenerator: التعبير المطلوب إستخدامه لإنشاء قيم URI لقالب طريقة الوصول هذه؛ المجموعة المسموح بها من الأحرف هي 'a' إلى 'z'، 'a' إلى 'z'، '0' إلى '9'، '.'، '-'، '_'، و'$'؛ إذا لم تكن فارغة يجب أن تحتوي على حرف '$' واحد بالضبط.  مثال على هذا هو $.space الذي يستخدم الاسم الذي يقدمه المستخدم عند إنشاء المساحة وإضافة ".space" إليها. يقوم "إجتماع الفريق" بإنشاء عنوان url 'Team.Meeting.space@domain'.

CallLegProfile: ما هو CallLegProfile الذي تريد إستخدام أي أساليب وصول تم إنشاؤها باستخدام هذا القالب؟  وإذا لم يتم توفيره، فإنه يستخدم ما تم ضبطه على مستوى CoSpaceTemplate وإذا لم يكن هناك، أستخدم ما هو على مستوى النظام/ملف التعريف.

GenerateUniqueCallId: ما إذا كان يتم إنشاء معرف رقمي فريد لطريقة الوصول هذه التي تتجاوز المعرف العمومي لمساحة الأمان أم لا.

dialInSecurityProfile: أي طلب InSecurityProfile تريد إستخدام أي طرق وصول تم إنشاؤها مع هذا القالب؟ وإذا لم يتم توفيره، فإنه يستخدم ما تم ضبطه على مستوى CoSpaceTemplate وإذا لم يكن هناك، أستخدم ما هو على مستوى النظام/ملف التعريف.

دالة الدردشة

أزال CMS 3.0 وظيفة الدردشة المستمرة، لكن في CMS 3.2 الدردشة غير المتواصلة داخل المساحات التي تم إرجاعها.  تتوفر المحادثة لمستخدمي تطبيق ويب ولا يتم تخزينها في أي مكان.  بمجرد تثبيت CMS 3.2، يمكن لمستخدمي تطبيق ويب بشكل افتراضي إرسال رسائل أخرى أثناء الاجتماعات.  تتوفر هذه الرسائل فقط أثناء الاجتماع، ويتم رؤية الرسائل المتبادلة فقط بعد الانضمام. لا يمكنك الانضمام في وقت متأخر والتمرير للخلف لرؤية الرسائل السابقة.

مكالمات نقطة إلى نقطة من WebRTC

في CMS 2.9.x، تمكن المشاركون في WebRTC من الاتصال مباشرة بموكلهم إلى جهات اتصال أخرى.  بدءا من CMS 3.0، لم يعد هذا ممكنا. يجب على المستخدمين الآن تسجيل الدخول والانضمام إلى مساحة. ومن هناك، إذا كان لديهم إذن في CallLegProfile (تم تعيين المعلمة addParticipants إلى True)، يمكنهم إضافة جهات اتصال أخرى.  هذا يتسبب في CMS أن يتصل بالمشارك ويلتقون على مساحة في CMS.

تغييرات ملحوظة في إعدادات WebBridge

قام CMS 3.0 و 3.1 بإزالة بعض إعدادات WebBridge من واجهة المستخدم الرسومية (GUI) أو نقلها، كما يلزم تكوينها في واجهة برمجة التطبيقات (API) للحفاظ على التجربة المتناسقة للمستخدمين.  في 3.x، أستخدم API/V1/webBridges وAPI/V1/webBridgeProfile. 

تحقق من التكوين الذي قمت بتكوينه حاليا حتى تتمكن، عند الترقية إلى 3.0، من تكوين ملفات تعريف WebBridge و WebBridge في API وفقا لذلك.

في 3.0، تمت إزالة إعدادات جسر الويب على واجهة المستخدم الرسومية، ثم في CMS 3.1، تمت إزالة حقول الوصول الخارجي أيضا.

إعدادات جسر الويب في واجهة المستخدم الرسومية (GUI)

• URI عميل حساب Guest - تم إستخدام هذا بواسطة CallBridge للعثور على WebBridge.  إذا كان لديك العديد من WebBridges في عملية النشر الخاصة بك ل WebRTC، فيجب أن يكون هذا الحقل فارغا بالفعل، كما يجب أن يكون لديك عناوين URL فريدة في API/V1/webbridges لكل WebBridge يحتاج CallBridge للاتصال به.  احذف أي شيء في هذا الحقل وتأكد من تكوين WebBridges في واجهة برمجة التطبيقات.

• مجال JID لحساب الضيف - لم يعد هذا مستخدما في CMS 3.0 ويمكنك حذف هذا.
• وصول الضيف عبر المعرف ورمز المرور - تمت إزالته وليس إستبداله في CMS 3.0.
• وصول الضيف عبر إرتباطات Hyper - قابل للتكوين الآن تحت ملفات تعريف WebBridgeProfile في واجهة برمجة التطبيقات (API) في إعداد "AllowSecret".

إشعار في CMS 3.0، تمت إزالة حقول الخادم من API/V1/WebBridges.

• ResourceArchive - الآن في ملفات تعريف WebBridge.
• idEntryMode - مهمل الآن.
• allowWeblinkAccess - الآن في ملفات تعريف WebBridge على هيئة allowSecrets.
• showSignin - الآن في ملفات تعريف WebBridge ك userPortalEnabled.
• resolveCoSpaceCallIds- الآن في ملفات تعريف WebBridge.
• ResolveLyncConferenceIDs - الآن في ملفات تعريف WebBridge.

WebBridgeProfile

• ResourceArchive - إذا كنت تستخدم خلفيات مخصصة وتم تخزين أرشيف الموارد على خادم ويب، فأدخل عنوان URL هنا.
• AllowPasscode - إذا كان خطأ، لا يملك المستخدمون خيارا للانضمام إلى الاجتماعات كضيوف.  يمكنهم فقط تسجيل الدخول أو إستخدام عنوان URL يحتوي على معلومات المساحة والسر
• AllowSecrets - إذا تم تعيين هذا إلى خطأ، فلن يتمكن المستخدمون من الانضمام إلى الفراغات باستخدام عنوان URL مثل https://meet.company.com/meeting/040478?secret=gPDnucF8is4W1cS87_l.zw. يحتاج المستخدمون إلى إستخدام https://meet.company.com وإدخال معرف المكالمة/معرف الاجتماع/URI ورمز PIN/رمز المرور في حالة تكوين واحد.
• UserPortalEnabled - إذا تم تعيين هذا إلى خطأ، فإن صفحة الإنزال لبوابة تطبيق الويب لا تظهر خيار تسجيل الدخول. وهو يعرض فقط الحقول الخاصة بإدخال معرف المكالمة/معرف الاجتماع/URI ورمز PIN/رمز المرور في حالة تكوين واحد.
• AllowUnauthenticatedGuest - إذا تم تعيينها إلى False، لا يمكن للضيوف الانضمام إلى أي إجتماعات - حتى مع URL الكامل الذي يحتوي على معرف الاجتماع والسر.  عند حدوث خطأ، يمكن فقط للمستخدمين الذين يمكنهم تسجيل الدخول الانضمام إلى الاجتماعات.  مثال.  يحاول User2 إستخدام عنوان URL لاجتماع User1.  بعد إدخال عنوان URL، يجب على User2 تسجيل الدخول لمتابعة إجتماع User1.
• ResolveCoSpaceCallIds - إذا تم تعيينه إلى "خطأ"، يمكن للضيوف الانضمام إلى الاجتماعات فقط من خلال إدخال URI و PIN/Passcode إذا تم إستخدامه.  معرف المكالمة/معرف الاجتماع/المعرف الرقمي غير مقبول.
• resolveCoSpaceUris - 3 إعدادات ممكنة: إيقاف تشغيل و domainSuggestionDisabled و domainSuggestionEnabled. ما إذا كان WebBridge يقبل CoSpace و CoSpace AccessMethod SIP URIs بغرض السماح للزوار بالانضمام إلى إجتماعات CoSpace أم لا.

- عند التعيين إلى 'إيقاف'، يتم تعطيل الانضمام بواسطة URI.

- عند التعيين إلى 'domainSuggestionDisabled' يتم تمكين الانضمام بواسطة URI ولكن لم يتم إكمال مجال URI تلقائيا أو التحقق من صحته على WebBridges باستخدام ملف تعريف ويب هذا.

- عند التعيين إلى 'domainSuggestionEnabled' يتم تمكين الانضمام بواسطة URI ويمكن إكمال مجال URI تلقائيا والتحقق من صحته على WebBridges باستخدام ملف تعريف ويب هذا.

تمت إزالة قسم الوصول الخارجي من واجهة المستخدم الرسومية (GUI) عبر الويب

في CMS 3.1، تمت إزالة قسم الوصول الخارجي من واجهة المستخدم الرسومية (GUI) للويب. إذا كان لديك هذه العناصر المكونة قبل الترقية، فعليك إعادة تكوينها في واجهة برمجة التطبيقات (API) ضمن ملفات تعريف webBbridgeProfile.

أولا، تحتاج إلى إنشاء WebBridgeProfile كما هو موضح في القسم السابق. بمجرد أن تقوم بإنشاء WebBridgeProfile، يمكنك إنشاء رقم IVR و/أو URI Web Bridge من خلال الروابط المتاحة في API تحت WebBridgeProfile الذي تم إنشاؤه حديثا.

يمكنك إنشاء ما يصل إلى 32 رقم IVR أو 32 عنوان WebBridge لكل ملف تعريف

التسجيل أو الدفق

كان مكون المسجل والشريط على CMS 2.9.x وما قبله من عملاء XMPP، ومن CMS 3.0، كانا قائمين على SIP.  يسمح هذا الآن بتغيير تخطيطات التسجيلات والدفق باستخدام التخطيط الافتراضي في API. كما يتم الآن عرض تسميات الأسماء في جلسة التسجيل/الدفق.  راجع ملاحظات إصدار CMS 3.0 للحصول على مزيد من المعلومات حول ميزات التسجيل/الدفق - https://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Release_Notes/Version-3-0/Cisco-Meeting-Server-Release-Notes-3-0.pdf.

إذا كان لديك مسجل أو جهاز تعقب Streamer تم تكوينه في 2.9.x، فأنت بحاجة إلى إعادة تكوين الإعدادات في MMP و API حتى تستمر هذه الإعدادات في العمل بعد الترقية.

قبل ترقية CMS إلى 3.0، يوصى بإجراء عملية نسخ إحتياطي باستخدام "لقطة إحتياطية <servername_date>"، ثم تسجيل الدخول إلى صفحة WebAdmin على عقد CallBridge لإزالة جميع إعدادات XMPP.  ثم قم بالاتصال ب MMP على الخوادم الخاصة بك، وقم بتنفيذ الخطوات التالية على جميع الخوادم الأساسية التي تحتوي على XMPP عبر اتصال SSH:

1. تعطيل xmpp
2. إعادة تعيين xmpp
3. XMPP CERTS none
4. بدون مجال XMPP

مسجل

MMP

تظهر الأرقام مثالا للتكوينات التي ظهرت على CMS 2.9.1 عند تكوين المسجل، وكيف يبدو بعد الترقية مباشرة إلى 3.0.

بعد الترقية، يجب إعادة تكوين المسجل:

الخطوة 1. قم بتكوين واجهة الاستماع ل SIP.

يقوم Recorder SIP بالإصغاء إلى A 5060 5061 (الواجهة والمنافذ التي تم إعداد مسجل SIP للاستماع إليها ل TCP و TLS، بكل إحترام. إذا كنت لا تريد إستخدام TLS، يمكنك إستخدام Recorder SIP Listen a 5060 none')

الخطوة 2. قم بتكوين الشهادات التي يستخدمها المسجل إذا كنت تستخدم اتصال TLS.

Recorder SIP الشهادات <key-file> <crt-file> [crt-bundle] (بدون هذه الشهادات، لا تبدأ خدمة TLS في المسجل. يستعمل المسجل crt-bundle للتحقق من شهادة callBridge.)

الخطوة 3. قم بتكوين حد المكالمة.

حد المسجل <0-500|none>(يحدد الحد لعدد التسجيلات المتزامنة التي يمكن للخادم أن يخدمها. هذا الجدول موجود في الوثائق الخاصة بنا ويجب أن يتوافق حد المسجل مع الموارد الموجودة على الخادم.)

API

في API/v1/callProfile، يلزمك تكوين sipRecorderUri. هذا هو URI الذي يقوم CallBridge بتحديثه عندما يتعين عليه بدء تسجيل. يجب إضافة مجال URI هذا إلى جدول القواعد الصادرة والإشارة إلى المسجل (أو عنصر التحكم في الاستدعاء) كوكيل SIP لاستخدامه.

يوضح هذا الشكل طلبا مباشرا لمكون المسجل على القواعد الصادرة التي تم العثور عليها في التكوين > المكالمات الصادرة.

يوضح هذا الشكل إستدعاء لمكون مسجل عبر التحكم في المكالمات (على سبيل المثال، Cisco Unified Communications Manager (CUCM) أو Expressway).

ملاحظة: إذا قمت بتكوين المسجل لاستخدام SIP TLS وإذا كانت المكالمات معطلة، فتحقق من عقدة CallBridge في MMP لمعرفة ما إذا كان لديك تمكين التحقق من SIP ل TLS.  أمر MMP هو tls sip'.   قد تفشل المكالمات لأن شهادة المسجل غير موثوق بها من قبل CallBridge.  يمكنك إختبار هذا الإجراء من خلال تعطيل هذا الأمر على CallBridge باستخدام TLS sip verify disable'.

مسجلات متعددة؟

قم بتكوين كل واحدة كما هو موضح، ثم قم بضبط القواعد الصادرة وفقا لذلك.  إذا كنت تستخدم طريقة تسجيل مباشرة، فقم بتغيير قاعدة مسجل الصادر الحالية إلى سلوك "متابعة" وإضافة قاعدة صادرة جديدة أسفل الطريقة السابقة مع الأولوية أقل من الأولى.  عندما يصل المسجل الأول إلى حد الاستدعاء، فإنه يرسل 488 غير مقبول هنا مرة أخرى إلى CallBridge، ويتحرك CallBridge إلى القاعدة التالية.

إذا كنت ترغب في موازنة حمل مسجلاتك، فاستخدم التحكم في المكالمات وقم بضبط توجيه التحكم في المكالمات حتى يتمكن من إجراء المكالمات إلى مسجلات متعددة.

شعاع

MMP

بعد الترقية من 2.9.x إلى 3.0، يلزمك إعادة تكوين Streamer.

الخطوة 1. قم بتكوين واجهة الاستماع ل SIP.

Streamer sip استمع إلى 6000 6001 (الواجهة والمنافذ التي تم إعداد SIP Streamer لها للاستماع إلى TCP و TLS، بكل إحترام.  إذا كنت لا ترغب في إستخدام TLS، فيمكنك إستخدام STREAMER SIP Listen a 6000 none)

الخطوة 2. قم بتكوين الشهادات التي يستخدمها المشعب إذا كنت تستخدم اتصال TLS.

Streamer sip certs <key-file> <crt-file> [crt-bundle] (بدون هذه الشهادات، لا تبدأ خدمة TLS في Streamer. يستخدم Streamer حزمة CRT للتحقق من شهادة CallBridge.)

الخطوة 3. تكوين حد المكالمة

حد Streamer <0-500|none> (يحدد الحد لعدد التدفقات المتزامنة التي يمكن للخادم خدمتها. هذا الجدول موجود في الوثائق الخاصة بنا ويجب أن يتوافق حد الدوران مع الموارد الموجودة على الخادم.)

API

في API/v1/callProfile، يلزمك تكوين sipStreamUri. هذا هو URI الذي يقوم CallBridge بتحديثه عند الحاجة إلى بدء الدفق. يجب إضافة مجال URI هذا إلى جدول القواعد الصادرة والإشارة إلى Streamer (أو عنصر تحكم الاستدعاء) كوكيل SIP لاستخدامه.

يوضح هذا الشكل طلبا مباشرا لمكون Streamer على القواعد الصادرة التي تم العثور عليها في التكوين > المكالمات الصادرة.

يوضح هذا الشكل إستدعاء لمكون مسجل عبر التحكم في المكالمات (على سبيل المثال، Cisco Unified Communications Manager (CUCM) أو Expressway).

ملاحظة: إذا قمت بتكوين المشعب لاستخدام SIP TLS وإذا كانت المكالمات معطلة، فتحقق من عقدة CallBridge في MMP لمعرفة ما إذا كان لديك تمكين التحقق من بروتوكول SIP ل TLS.  أمر MMP هو tls sip'.   قد تفشل المكالمات لأن شهادة Streamer غير موثوق بها من قبل CallBridge.  يمكنك إختبار هذا الإجراء من خلال تعطيل هذا الأمر على CallBridge باستخدام TLS sip verify disable'.

هل تحتاج إلى عدة أنساق؟

قم بتكوين كل واحدة كما هو موضح، ثم قم بضبط القواعد الصادرة وفقا لذلك.  إذا كنت تستخدم طريقة Direct to Streamer، فقم بتغيير قاعدة Outbound to Recorder الحالية إلى سلوك "Continue" وإضافة قاعدة صادرة جديدة أسفل الطريقة السابقة مع الأولوية أقل من الأولى.  عندما يصل الطبق الأول إلى الحد المسموح به للمكالمات، فإنه يرسل 488 غير مقبول هنا مرة أخرى إلى CallBridge، وتنتقل قيمة CallBridge إلى القاعدة التالية.

إذا كنت ترغب في موازنة الأحمال على الأجهزة المجدولة الخاصة بك، فاستخدم التحكم في المكالمات وقم بضبط توجيه التحكم في المكالمات حتى يتمكن من إجراء المكالمات إلى عدة أجهزة مبسطة.

إعتبار Expressway

إذا كنت تستخدم Cisco Expressway لوكيل الويب، فيجب عليك التأكد من تشغيل Expressway ل X12.6 على الأقل قبل ترقية CMS. هذا مطلوب من قبل CMS 3.0 لكي يعمل وكيل ويب ولكي يكون مدعوما.

أزدادت سعة المشاركين في تطبيق الويب عبر Expressway عند إستخدامها مع CMS 3.0.  بالنسبة لطريق سريع كبير OVA، تكون القدرة المتوقعة 150 مكالمة عالية الدقة بالكامل (1080p30) أو 200 مكالمة من نوع آخر (على سبيل المثال 720p30). يمكنك زيادة هذه السعة من خلال تجميع ExpressWay، حتى 6 عقد (حيث يتم إستخدام 4 للتوسعة و 2 للتكرار، حتى حد أقصى 600 مكالمة فائقة الدقة بالكامل، أو 800 مكالمة من النوع الآخر).

CMS Edge

يتم إعادة إدخال CMS Edge في CMS 3.1 لأن ذلك يوفر سعات أعلى من تلك التي يوفرها Expressway لجلسات تطبيقات الويب الخارجية. هناك نوعان من التكوينات الموصى بها.

مواصفات الحافة الصغيرة

ذاكرة وصول عشوائي (RAM) سعة 4 جيجابايت و 4 وحدات معالجة مركزية (CPU) وواجهة شبكة بسرعة 1 جيجابت في الثانية

تحتوي مواصفات VM Edge هذه على طاقة كافية لتغطية سعة تحميل صوت وفيديو CMS1000 واحدة، وهي 48 × 1080 بكسل و 96 × 720 بكسل و 192 × 480 بكسل و 1000 مكالمة صوتية.

بالنسبة لعملية النشر، يوصى بأن يكون هناك خادم طرفي صغير واحد لكل CMS1000 أو 4 خوادم طرفية صغيرة لكل CMS2000.

مواصفات الحافة الكبيرة

ذاكرة وصول عشوائي (RAM) سعة 8 جيجابايت و 16 وحدة معالجة مركزية (CPU) بسرعة 10 جيجابت في الثانية لواجهة الشبكة

تتوفر مواصفات VM Edge هذه على طاقة كافية لتغطية سعة صوت وفيديو CMS2000 واحدة، وهي 350 × 1080 بكسل و 700 × 720 بكسل و 1000 × 480 بكسل و 3000 مكالمة صوتية.

بالنسبة لعملية النشر، يوصى بوجود خادم واحد كبير الحجم لكل CMS2000، أو لكل 4 CMS1000.