خادم اجتماعات Cisco 2.5.2. الكتلة في وضع التدرج والمرونة مع تسجيل مؤتمر الفيديو

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


نظريةبشكل عام ، هناك ثلاثة أنواع من نشر خادم CMS:

• واحد مجتمعة(واحد مدمج) ، أي إنه خادم واحد يقوم بتشغيل جميع الخدمات الضرورية. في معظم الحالات ، لا ينطبق هذا النوع من النشر إلا على وصول العميل الداخلي وفي البيئات الأصغر حيث لا تمثل قابلية توسيع الخادم الفردي وقيود التكرار مشكلة حرجة ، أو في المواقف التي يؤدي فيها نظام إدارة المحتوى وظائف معينة فقط ، مثل المؤتمرات المخصصة على Cisco UCM.

  مخطط العمل التقريبي:
  

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

  مخطط العمل التقريبي:
  

• قابلة للتطوير والمرونة(قابل للتحجيم ومتسامح مع الخطأ) يتضمن هذا النوع التكرار لكل مكون ، مما يسمح للنظام بالنمو مع احتياجاتك إلى أقصى سعة له مع توفير التكرار في حالة حدوث عطل. كما أنه يستخدم مفهوم Single Edge لتوفير وصول خارجي آمن. هذا هو النوع الذي سنغطيه في هذه الحلقة. إذا فهمنا كيفية نشر هذا النوع من المجموعات ، فلن نفهم فقط الأنواع الأخرى من النشر ، ولكن يمكننا أيضًا فهم كيفية إنشاء مجموعات من خوادم CMS ، مع مراعاة النمو المحتمل للاحتياجات.

قبل الانتقال إلى النشر ، تحتاج إلى فهم بعض الأشياء الأساسية ، وهي

مكونات البرامج الرئيسية لنظام إدارة المحتوى:

• قاعدة البيانات: يسمح لك بدمج بعض التكوينات مثل خطة الاتصال ومساحات المستخدمين والمستخدمين أنفسهم. يدعم التجميع من أجل التوفر العالي (رئيسي واحد) فقط.
• اتصل بالجسر: خدمة لعقد المؤتمرات الصوتية والمرئية ، تتيح التحكم الكامل في إدارة ومعالجة المكالمات وعمليات الوسائط المتعددة. يدعم التجميع من أجل التوافر العالي وقابلية التوسع.
• خادم XMPP: مسؤول عن تسجيل العملاء والمصادقة عليهم باستخدام تطبيق اجتماع Cisco و / أو WebRTC (الاتصال في الوقت الفعلي ، أو ببساطة في المتصفح)، فضلا عن الإشارات البينية. لا يمكن تجميعها إلا من أجل التوافر العالي.
• جسر الويب: يوفر وصول العميل إلى WebRTC.
• تحميل: يوفر نقطة اتصال واحدة لتطبيقات اجتماعات Cisco في وضع الانقسام الفردي. يستمع إلى الواجهة الخارجية والمنفذ للاتصالات الواردة. وبالمثل ، يقبل موازن التحميل اتصالات TLS الواردة من خادم XMPP ، والتي يمكن من خلالها تبديل اتصالات TCP من العملاء الخارجيين.
  في السيناريو الخاص بنا ، لن تكون هناك حاجة.
• خادم TURN: يوفر تقنية تجاوز جدار الحماية التي تسمح بذلك
  قم بتعليق نظام إدارة المحتوى الخاص بنا خلف جدار حماية أو NAT لتوصيل العملاء الخارجيين باستخدام تطبيق Cisco Meeting App أو أجهزة SIP. في السيناريو الخاص بنا ، لن تكون هناك حاجة.
• مدير الويب: واجهة إدارية ووصول إلى واجهة برمجة التطبيقات ، بما في ذلك مؤتمرات CM الموحدة المخصصة.

أوضاع التكوين

على عكس معظم منتجات Cisco الأخرى ، يدعم Cisco Meeting Server ثلاث طرق تكوين لتمكين أي نوع من النشر.

• سطر الأوامر (CLI): واجهة سطر الأوامر ، والمعروفة باسم MMP ، لمهام التكوين الأولية والشهادات.
• مسؤول الويب: بشكل أساسي للتكوين المرتبط بـ CallBridge ، خاصةً عند تكوين خادم واحد غير مجمع.
• REST API: يستخدم في مهام قاعدة البيانات العنقودية والتكوين الأكثر تعقيدًا.

بالإضافة إلى ما سبق البروتوكول SFTP لنقل الملفات - عادةً التراخيص أو الشهادات أو السجلات - من وإلى CMS.

في أدلة النشر من Cisco ، تمت كتابته باللغتين الإنجليزية والأبيض أن الكتلة بحاجة إلى النشر ثلاثة على الأقل الخوادم (العقد) في سياق قواعد البيانات. لأن فقط مع عدد فردي من العقد ، ستكون آلية اختيار عمل رئيسي جديد لقاعدة البيانات ، وبشكل عام ، يكون لقاعدة البيانات الرئيسية اتصال بمعظم قاعدة بيانات خادم CMS.

وكما تبين الممارسة ، فإن خادمين (عقدتين) لا يكفيان حقًا. تعمل آلية التحديد عند إعادة تمهيد الخادم الرئيسي ، ويصبح الخادم التابع هو الخادم الرئيسي فقط بعد رفع الخادم المعاد تشغيله. ومع ذلك ، إذا "خرج" الخادم الرئيسي فجأة في مجموعة مكونة من خادمين ، فلن يصبح الخادم التابع هو الخادم الرئيسي ، وإذا "خرج" الخادم التابع ، فسيصبح الخادم الرئيسي المتبقي هو الخادم التابع.

ولكن في سياق XMPP ، سيكون من الضروري حقًا تجميع مجموعة من ثلاثة خوادم ، لأن على سبيل المثال ، إذا قمت بتعطيل خدمة XMPP على أحد الخوادم التي يكون فيها XMMP في حالة القائد ، فسيظل على خادم XMPP المتبقي في حالة التابع وستتوقف اتصالات CallBridge بـ XMPP ، لأن تتصل CallBridge حصريًا بـ XMPP بحالة القائد. وهذا أمر بالغ الأهمية ، لأن. لن تمر أي مكالمة.

أيضًا في أدلة النشر نفسها ، يتم عرض مجموعة بها خادم XMPP واحد.

ومع الأخذ في الاعتبار ما سبق ، يتضح سبب ذلك: إنه يعمل لأنه في وضع تجاوز الفشل.

في حالتنا ، سيكون خادم XMPP موجودًا في جميع العقد الثلاثة.

من المفترض أن جميع خوادمنا الثلاثة تعمل.

سجلات DNS

قبل أن تبدأ في تكوين الخوادم ، تحتاج إلى إنشاء سجلات DNS А и SRV الأنواع:

لاحظ أن سجلات DNS لدينا لها مجالان هما example.com و أسيوط.example.com. example.com هو مجال يمكن لجميع المشتركين في Cisco Unified Communication Manager استخدامه لمعرفات الموارد المنتظمة (URIs) الخاصة بهم ، والتي من المحتمل أن تكون موجودة في بنيتك الأساسية أو من المحتمل أن تكون موجودة. أو يطابق المجال example.com نفس المجال الذي يستخدمه المستخدمون لعناوين بريدهم الإلكتروني. أو قد يحتوي عميل Jabber على الكمبيوتر المحمول الخاص بك على URI [البريد الإلكتروني محمي]. اِختِصاص أسيوط.example.com هو المجال الذي سيتم تكوينه لمستخدمي Cisco Meeting Server. سيكون مجال Cisco Meeting Server أسيوط.example.com ، لذلك سيحتاج مستخدم Jabber نفسه إلى استخدام URI user @ لتسجيل الدخول إلى Cisco Meeting Serverأسيوط.example.com.

التكوين الأساسي

يتم عرض جميع الإعدادات الموضحة أدناه على خادم واحد ، ولكن يلزم إجراؤها على كل خادم في المجموعة.

جودة الخدمة

منذ CMS يولد في الوقت الحقيقي حركة المرور الحساسة للتأخير وفقدان الحزم ، يوصى في معظم الحالات بتكوين جودة الخدمة (QoS). للقيام بذلك ، يدعم نظام إدارة المحتوى تعليم الحزم برموز الخدمة المتباينة (DSCPs) التي ينشئها. بينما تعتمد أولويات حركة المرور المستندة إلى DSCP على كيفية معالجة حركة المرور من خلال مكونات الشبكة الخاصة بالبنية التحتية الخاصة بك ، في حالتنا سنقوم بتهيئة نظام إدارة المحتوى الخاص بنا باستخدام أولوية DSCP النموذجية بناءً على أفضل ممارسات جودة الخدمة.

في كل خادم ، أدخل هذه الأوامر

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

لذلك تم وضع علامة على كل حركة مرور الفيديو AF41 (DSCP 0x22) ، وتم وضع علامة على جميع حركات المرور الصوتية بعلامة EF (DSCP 0x2E) ، وحركة مرور أخرى مثل SIP و XMPP تستخدم AF31 (DSCP 0x1A).

نتحقق من:

NTP

بروتوكول وقت الشبكة (NTP) مهم ليس فقط لتوفير طوابع زمنية دقيقة للمكالمات والمؤتمرات ، ولكن أيضًا للتحقق من الشهادات.

أضف خادم NTP إلى بنيتك الأساسية باستخدام أمر مثل

ntp server add <server>

في حالتنا ، هناك نوعان من هذه الخوادم ، لذلك سيكون هناك فريقان.
نتحقق من:

وقم بتعيين المنطقة الزمنية لخادمنا

DNS

تتم إضافة خوادم DNS إلى نظام إدارة المحتوى بأمر مثل:

dns add forwardzone <domain-name> <server ip>

في حالتنا ، هناك نوعان من هذه الخوادم ، لذلك سيكون هناك فريقان.
نتحقق من:

تكوين واجهة الشبكة

نقوم بتكوين الواجهة بأمر من النموذج:

ipv4 <interface> add <address>/<prefix length> <gateway>

نتحقق من:

اسم الخادم (اسم المضيف)

يتم تعيين اسم الخادم بأمر من النموذج:

hostname <name>

ونعيد التشغيل.


هذا يكمل التكوين الأساسي.

الشهادات

نظريةيتطلب Cisco Meeting Server اتصالات مشفرة بين مختلف المكونات ، ونتيجة لذلك ، فإن شهادات X.509 مطلوبة لجميع عمليات نشر CMS. إنها تساعد في ضمان أن الخدمة / الخادم موثوق بها من قبل الخوادم / الخدمات الأخرى.

تتطلب كل خدمة شهادة ، ولكن إنشاء شهادات منفصلة لكل خدمة يمكن أن يكون مربكًا ومعقدًا بشكل مفرط. لحسن الحظ ، يمكننا إنشاء زوج مفاتيح عام / خاص للشهادة ثم إعادة استخدامه عبر خدمات متعددة. في حالتنا ، سيتم استخدام نفس الشهادة لـ Call Bridge و XMPP Server و Web Bridge و Web Admin. وبالتالي ، تحتاج إلى إنشاء زوج مفاتيح عام وخاص لشهادة لكل خادم في المجموعة.

ومع ذلك ، فإن تجميع قاعدة البيانات له بعض متطلبات الشهادة الخاصة ، وبالتالي يتطلب شهاداته الخاصة ، والتي تختلف عن تلك الخاصة بالخدمات الأخرى. يستخدم نظام إدارة المحتوى شهادة خادم ، تشبه الشهادات التي تستخدمها الخوادم الأخرى ، ولكن هناك أيضًا شهادة عميل تُستخدم لاتصالات قاعدة البيانات. تُستخدم شهادات قاعدة البيانات لكل من المصادقة والتشفير. بدلاً من توفير اسم مستخدم وكلمة مرور للعميل للاتصال بقاعدة البيانات ، فإنه يقدم شهادة عميل يثق بها الخادم. سيستخدم كل خادم في مجموعة قاعدة البيانات نفس زوج المفاتيح العام / الخاص. يسمح هذا لجميع الخوادم في المجموعة بتشفير البيانات بحيث لا يمكن فك تشفيرها إلا عن طريق الخوادم الأخرى التي تستخدم أيضًا نفس زوج المفاتيح.

لكي يعمل التكرار ، يجب أن تتكون مجموعات قاعدة البيانات من 3 خوادم على الأقل ، بحد أقصى 5 خوادم ، مع وقت ذهاب وإياب بحد أقصى 200 مللي ثانية بين أي عضو في الكتلة. هذا الحد أكثر تقييدًا من نظام مجموعات Call Bridge ، لذلك غالبًا ما يكون العامل المحدد في عمليات النشر المتفرقة جغرافيًا.

يحتوي دور قاعدة البيانات لنظام إدارة المحتوى على عدد من المتطلبات الفريدة. على عكس الأدوار الأخرى ، فإنه يتطلب شهادة العميل والخادم ، حيث تحتوي شهادة العميل على حقل CN محدد يتم تقديمه إلى الخادم.

يستخدم نظام إدارة المحتوى قاعدة بيانات postgres بها نسخ رئيسية واحدة وعدة نسخ متماثلة متطابقة. لا توجد سوى قاعدة بيانات رئيسية واحدة في أي وقت ("خادم قاعدة البيانات"). بقية أعضاء الكتلة هي النسخ المتماثلة أو "عملاء قاعدة البيانات".

تتطلب مجموعة قاعدة البيانات شهادة خادم مخصصة وشهادة عميل. يجب أن يتم التوقيع عليها بشهادات ، وعادة ما تكون CA داخليًا خاصًا. نظرًا لأن أي عضو في مجموعة قاعدة البيانات يمكن أن يصبح هو الرئيسي ، يجب نسخ أزواج خادم قاعدة البيانات وشهادة العميل (التي تحتوي على المفاتيح العامة والخاصة) إلى جميع الخوادم حتى يتمكنوا من تحمل هوية العميل أو خادم قاعدة البيانات. بالإضافة إلى ذلك ، يجب تحميل شهادة المرجع المصدق الجذر لضمان إمكانية التحقق من شهادات العميل والخادم.

لذلك ، نشكل طلبًا للحصول على شهادة ستستخدمها جميع خدمات الخادم باستثناء قاعدة البيانات (سيكون هناك طلب منفصل لهذا) بأمر مثل:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

في CN نكتب الاسم العام لخوادمنا. على سبيل المثال ، إذا كانت أسماء المضيف لخوادمنا server01, server02, server03، فسيكون CN server.example.com

نفعل الشيء نفسه على الخادمين المتبقيين مع اختلاف أن الأوامر ستحتوي على "أسماء المضيف" المقابلة

نشكل طلبين للحصول على الشهادات التي ستستخدمها خدمة قاعدة البيانات بأوامر النموذج:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

حيث com.dbclusterserver и com.dbclusterclient أسماء طلباتنا وشهاداتنا المستقبلية ، اسم المضيف 1 (2) (3) أسماء الخوادم المعنية.

نقوم بتنفيذ هذا الإجراء على خادم واحد فقط (!) ، وسنقوم بتحميل الشهادات وملفات .key المقابلة إلى خوادم أخرى.

تفعيل وضع شهادة العميل في AD CS

تحتاج أيضًا إلى دمج الشهادات لكل خادم في ملف واحدفي * NIX:

cat server01.cer server02.cer server03.cer > server.cer

على نظام التشغيل Windows / DOS:

copy server01.cer + server02.cer + server03.cer  server.cer

وتحميل لكل سيرفر:
1. شهادة خادم "فردية".
2. الشهادة الأساسية (مع الشهادات المتوسطة إن وجدت).
3. شهادات لقاعدة البيانات ("الخادم" و "العميل") والملفات ذات الامتداد .key ، والتي تم إنشاؤها عند إنشاء طلب لشهادة "الخادم" و "العميل" لقاعدة البيانات. يجب أن تكون هذه الملفات هي نفسها على كافة الخوادم.
4. ملف الشهادات "الفردية" الثلاث.

نتيجة لذلك ، يجب الحصول على صورة الملف نفسها تقريبًا على كل خادم.

كتلة قاعدة البيانات

الآن بعد أن تم تحميل جميع الشهادات على خوادم CMS ، يمكنك إعداد وتمكين تجميع قاعدة البيانات عبر العقد الثلاثة. تتمثل الخطوة الأولى في تحديد خادم واحد كعقدة رئيسية لمجموعة قاعدة البيانات وتكوينه بالكامل.

قاعدة البيانات الرئيسية

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

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

الآن دعنا نخبر CMS عن الواجهة التي يجب استخدامها لتجميع قاعدة البيانات باستخدام الأمر:

database cluster localnode a

ثم نقوم بتهيئة قاعدة بيانات الكتلة على الخادم الرئيسي بالأمر:

database cluster initialize

عقد قاعدة بيانات العميل

نقوم بنفس الإجراء ، فقط بدلاً من الأمر تهيئة كتلة قاعدة البيانات أدخل أمرًا مثل:

database cluster join <ip address existing master>

حيث عنوان IP الحالي عنوان IP الرئيسي لخادم CMS الذي تمت تهيئة الكتلة عليه ، ببساطة Master.

نتحقق من كيفية عمل مجموعة قواعد البيانات الخاصة بنا على جميع الخوادم باستخدام الأمر:

database cluster status

نفعل الشيء نفسه على الخادم الثالث المتبقي.

نتيجة لذلك ، اتضح أن خادمنا الأول هو السيد والباقي عبيد.

خدمة إدارة الويب

قم بتمكين خدمة مسؤول الويب:

webadmin listen a 445

تم تحديد المنفذ 445 نظرًا لاستخدام المنفذ 443 لوصول المستخدم إلى عميل الويب

نقوم بتهيئة خدمة مسؤول الويب بملفات الشهادات بأمر مثل:

webadmin certs <keyfile> <certificatefile> <ca bundle>

وقم بتمكين Web Admin بالأمر:

webadmin enable

إذا كان كل شيء على ما يرام ، فسنحصل على سطور نجاح تشير إلى أن مسؤول الويب قد تم تكوينه بشكل صحيح للشبكة والشهادة. نتحقق من صحة الخدمة باستخدام متصفح الويب وإدخال عنوان مسؤول الويب ، على سبيل المثال: cms.example.com: 445

اتصل بريدج كلاستر

Call Bridge هي الخدمة الوحيدة الموجودة في كل عملية نشر CMS. Call Bridge هي آلية عقد المؤتمرات الرئيسية. كما يوفر واجهة SIP بحيث يمكن توجيه المكالمات إليها أو منها ، مثل Cisco Unified CM.

يجب تشغيل الأوامر أدناه على كل خادم بالشهادات المناسبة.
لذلك:

إقران الشهادات بخدمة Call Bridge بأمر مثل:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

نربط خدمات CallBridge بالواجهة التي نحتاجها باستخدام الأمر:

callbridge listen a

وأعد تشغيل الخدمة بالأمر:

callbridge restart

الآن بعد أن تم تكوين جسور الاتصال الخاصة بنا ، يمكننا إعداد مجموعة Call Bridge. يختلف تجميع Call Bridge عن قاعدة البيانات أو مجموعات XMPP. يمكن لـ Call Bridge Cluster دعم 2 إلى 8 عقد دون أي قيود. إنه لا يوفر التكرار فحسب ، بل يوفر أيضًا موازنة الحمل ، بحيث يمكن توزيع المؤتمرات بشكل نشط بين خوادم Call Bridge باستخدام توزيع المكالمات الذكي. يحتوي CMS على ميزات إضافية ومجموعات Call Bridge والميزات ذات الصلة التي يمكن استخدامها لمزيد من الإدارة.

يتم تكوين مجموعة جسر الاتصال بشكل أساسي من خلال واجهة مسؤول الويب
يجب تنفيذ الإجراء التالي على كل خادم مجموعة.
وهكذا،

1. نتصفح الويب في التكوين> الكتلة.
2. ال هوية جسر الاتصال كاسم فريد ، أدخل callbridge [01,02,03،01,02,03،XNUMX] المطابق لاسم الخادم. هذه الأسماء عشوائية ، لكن يجب أن تكون فريدة لهذه المجموعة. وهي وصفية من حيث أنها تشير إلى أنها معرفات الخادم [XNUMX،XNUMX،XNUMX].
3. ب جسور الاتصال العنقودية أدخل عناوين URL لمسؤول الويب لخوادمنا في المجموعة ، سم[01,02,03،445،XNUMX] .example.com: XNUMX ، في حقل العنوان. تأكد من تحديد المنفذ. يمكنك ترك مجال Peer link SIP فارغًا.
4. نضيف شهادة إلى Trust of CallBridge لكل خادم ، يحتوي ملفها على جميع شهادات خوادمنا التي دمجناها في هذا الملف في البداية ، بأمر مثل:

callbridge trust cluster <trusted cluster certificate bundle>

وأعد تشغيل الخدمة بالأمر:

callbridge restart

نتيجة لذلك ، يجب أن تحصل على الصورة التالية في كل خادم:

مجموعة XMPP

تُستخدم خدمة XMPP في CMS للتعامل مع جميع عمليات التسجيل والمصادقة لتطبيقات اجتماعات Cisco (CMA) ، بما في ذلك CMA WebRTC Web Client. يعمل Call Bridge نفسه أيضًا كعميل XMPP لأغراض المصادقة ، وبالتالي يجب تكوينه مثل العملاء الآخرين. تجاوز فشل XMPP هي ميزة تم دعمها في بيئات الإنتاج منذ الإصدار 2.1

يجب تشغيل الأوامر أدناه على كل خادم بالشهادات المناسبة.
لذلك:

إقران الشهادات بخدمة XMPP بأمر مثل:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

ثم حدد واجهة الاستماع بالأمر:

xmpp listen a

تتطلب خدمة XMPP مجالًا فريدًا. هذا هو تسجيل الدخول للمستخدمين. بمعنى آخر، عندما يحاول المستخدم تسجيل الدخول باستخدام تطبيق CMA (أو من خلال عميل WebRTC)، فإنه يدخل userID@logindomain. في حالتنا سيكون معرف المستخدم@أسيوط.example.com. لماذا لا يقتصر الأمر على example.com؟ في عملية النشر الخاصة بنا ، اخترنا مجال CM الموحد الذي سيستخدمه مستخدمو Jabber في Unified CM مثل example.com ، لذلك نحتاج إلى مجال مختلف لمستخدمي CMS لتوجيه المكالمات من وإلى CMS عبر نطاقات SIP.

قم بإعداد مجال XMPP بأمر مثل:

xmpp domain <domain>

وتمكين خدمة XMPP بالأمر:

xmpp enable

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

نحتاج الآن إلى إعداد خدمة XMPP على الخادم الأول مع ثلاثة جسور Callbridge01 و callbridge02 و callbridge03. سيتم تعيين كلمات مرور عشوائية لكل حساب. لاحقًا ، سيتم إدخالها على خوادم Call Bridge الأخرى لتسجيل الدخول إلى خادم XMPP هذا. أدخل الأوامر التالية:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

نتيجة لذلك ، نتحقق مما حدث للأمر:

xmpp callbridge list

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

بعد ذلك ، نضيف نفس الإعدادات بالضبط على الخادمين المتبقيين ، فقط باستخدام الأوامر

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

نضيف Secret بعناية شديدة حتى لا تدخل إليه مسافات إضافية عن طريق الخطأ ، على سبيل المثال.


نتيجة لذلك ، يجب أن يكون لكل خادم نفس الصورة:

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

xmpp cluster trust <trust bundle>

قم بتمكين وضع الكتلة xmpp على جميع خوادم الكتلة باستخدام الأمر:

xmpp cluster enable

في الخادم الأول من الكتلة ، بدأنا في إنشاء مجموعة xmpp باستخدام الأمر:

xmpp cluster initialize

على الخوادم الأخرى ، نضيف الكتلة إلى xmpp بأمر مثل:

xmpp cluster join <ip address head xmpp server>

في كل خادم ، نتحقق من نجاح إنشاء مجموعة XMPP على كل خادم باستخدام الأوامر:

xmpp status
xmpp cluster status

الخادم الأول:

الخادم الثاني:

الخادم الثالث:

توصيل Call Bridge بـ XMPP

الآن بعد أن تم تشغيل مجموعة XMPP ، نحتاج إلى تكوين خدمات Call Bridge للاتصال بمجموعة XMPP. يتم هذا التكوين من خلال مسؤول الويب.

نذهب على كل خادم في التكوين> عام وفي الميدان اسم فريد لجسر الاتصال نكتب الأسماء الفريدة لـ Call Bridge المقابلة للخادم كولبريدج [01,02,03،XNUMX،XNUMX]. п поле نطاق conf.example.ru وكلمات المرور المقابلة ، يمكنك التجسس عليها
على أي خادم كتلة باستخدام الأمر:

xmpp callbridge list

اترك حقل "الخادم" فارغًا. كالبريدج سيتم إجراء بحث DNS SRV عن _xmpp-component._tcp.conf.example.comللعثور على خادم XMPP متاح. قد تختلف عناوين IP لتوصيل جسور الاتصال بـ XMPP على كل خادم ، ويعتمد ذلك على القيم التي يتم إرجاعها إلى طلب الكتابة _xmpp-component._tcp.conf.example.com callbridge ، والتي تعتمد بدورها على إعدادات الأولوية لسجل DNS هذا.

بعد ذلك ، انتقل إلى الحالة> عام لمعرفة ما إذا كانت خدمة Call Bride متصلة بنجاح بخدمة XMPP.

جسر الويب

في كل خادم كتلة ، قم بتمكين خدمة Web Bridge بالأمر:

webbridge listen a:443

نقوم بتكوين خدمة Web Bridge بملفات الشهادات بأمر مثل:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

يدعم Web Bridge بروتوكول HTTPS. سيعيد توجيه HTTP إلى HTTPS إذا تم تكوينه لاستخدام "http-redirect".
لتمكين إعادة توجيه HTTP ، استخدم الأمر التالي:

webbridge http-redirect enable

لإخبار Call Bridge أنه يمكن الوثوق بجسر الويب للاتصالات من Call Bridge ، استخدم الأمر:

webbridge trust <certfile>

أين هو الملف الذي يحتوي على جميع الشهادات الثلاث من كل خادم في الكتلة.

يجب أن تكون هذه الصورة على كل خادم من الكتلة.


نحتاج الآن إلى إنشاء مستخدم له دور "appadmin" ، فنحن بحاجة إليه حتى نتمكن من تكوين نظامنا العنقودي (!) ، وليس كل خادم من الخوادم على حدة ، لذلك سيتم تطبيق الإعدادات بالتساوي على كل خادم ، على الرغم من سوف يصنعون مرة واحدة.


لمزيد من التخصيص ، سوف نستخدم ساعي البريد.

للحصول على إذن ، حدد أساسي في قسم التفويض

لإرسال الأوامر بشكل صحيح إلى خوادم CMS ، تحتاج إلى ضبط التشفير المطلوب

حدد Webbridge باستخدام الأمر سأعين مع المعلمة URL والمعنى cms.example.com



في Webbridge نفسها ، نحدد المعلمات التي نحتاجها: وصول الضيف ، والوصول الآمن ، وما إلى ذلك.

اتصل بمجموعات الجسر

بشكل افتراضي ، لا يقوم نظام إدارة المحتوى دائمًا بالاستفادة القصوى من موارد المؤتمرات المتاحة له.

على سبيل المثال ، بالنسبة لاجتماع مع ثلاثة مشاركين ، قد يكون كل مشارك على ثلاثة Call Bridge'ax مختلفة. من أجل أن يتواصل هؤلاء المشاركون الثلاثة مع بعضهم البعض ، ستقوم Call Bridges تلقائيًا بإنشاء اتصالات بين جميع الخوادم والعملاء في نفس المساحة ، بحيث يبدو أن جميع العملاء على نفس الخادم. لسوء الحظ ، فإن الجانب السلبي لهذا هو أن مؤتمرًا واحدًا من 3 أشخاص سيستهلك الآن 9 منافذ وسائط. من الواضح أن هذا استخدام غير فعال للموارد. أيضًا ، عندما يكون Call Bridge مزدحمًا حقًا ، فإن الآلية الافتراضية هي الاستمرار في تلقي المكالمات وتقديم خدمة منخفضة الجودة لجميع المشتركين في Call Bridge.

يتم حل هذه المشكلات باستخدام ميزة Call Bridge Group. تم تقديم هذه الميزة في الإصدار 2.1 من Cisco Meeting Server Software وتم توسيعها لدعم موازنة الحمل لكل من المكالمات الواردة والصادرة ، تطبيق Cisco Meeting App (CMA) ، بما في ذلك المشاركين في WebRTC.

لحل مشكلة إعادة الاتصال ، تم تقديم ثلاثة حدود تحميل قابلة للتكوين لكل Call Bridge:

حد التحميل هو أقصى حمل رقمي لجسر اتصال معين. لكل منصة حد تحميل موصى به ، مثل 96000 لـ CMS1000 و 1.25 جيجاهرتز لكل معالج افتراضي للجهاز الظاهري. تستهلك المكالمات المختلفة قدرًا معينًا من الموارد اعتمادًا على دقة المشارك ومعدل الإطارات.
NewConferenceLoadLimitBasisPoints (الافتراضي 50٪ loadLimit) - يحدد حد تحميل الخادم وبعد ذلك يتم رفض المؤتمرات الجديدة.
ExistingConferenceLoadLimitBasisPoints (افتراضي 80٪ من loadLimit) - قيمة تحميل الخادم وبعدها سيتم رفض المشاركين الذين ينضمون إلى مؤتمر موجود.

بينما تم تصميم هذه الميزة لتوزيع المكالمات وموازنة التحميل ، يمكن أيضًا تعيين مجموعات أخرى مثل خوادم TURN وخوادم Web Bridge والمسجلات إلى Call Bridge Group بحيث يمكن أيضًا تجميعها بشكل صحيح للاستخدام الأمثل. إذا لم يتم تعيين أي من هذه الكائنات لمجموعة اتصال ، فمن المفترض أن تكون متاحة لجميع الخوادم دون أي أولوية معينة.

تم تكوين هذه الإعدادات هنا: cms.example.com: 445 / api / v1 / النظام / التكوين / الكتلة

بعد ذلك ، نشير إلى كل callbridge أي مجموعة callbridge تنتمي إليها:

أول كولبريدج

ثاني كولبريدج

ثالث جسر الاتصال


وبالتالي ، قمنا بتكوين مجموعة Call Brdige لاستخدام موارد مجموعة Cisco Meeting Server بشكل أكثر كفاءة.

استيراد المستخدمين من Active Directory

تحتوي خدمة Web Admin على قسم تكوين LDAP ، لكنها لا توفر خيارات تكوين معقدة ، ولا يتم تخزين المعلومات في قاعدة بيانات المجموعة ، لذلك يجب إجراء التكوين ، إما يدويًا على كل خادم من خلال واجهة الويب ، أو من خلال واجهة برمجة التطبيقات ، وحتى "لا ننهض ثلاث مرات" سنستمر في تعيين البيانات من خلال واجهة برمجة التطبيقات.

استخدام URL للوصول cms01.example.com: تقوم 445 / api / v1 / ldapServers بإنشاء كائن خادم LDAP ، مع تحديد معلمات مثل:

• خادم IP
• رقم المنفذ
• имя пользователя
• كلمة السر
• تأمين

آمن - صحيح أو خطأ حسب المنفذ ، 389 - غير آمن ، 636 - آمن.


تعيين خيارات مصدر LDAP للسمات في خادم اجتماعات Cisco.
يعيّن تعيين LDAP السمات الموجودة في دليل LDAP إلى السمات الموجودة في نظام إدارة المحتوى. في الواقع السمات:

• jidMapping
• الاسم
• coSpaceNameMapping
• com.coSpaceUriMapping
• coSpaceSecondaryUriMapping

وصف السماتJID يمثل معرف تسجيل الدخول للمستخدم في نظام إدارة المحتوى. نظرًا لأن هذا هو خادم Microsoft Active Directory LDAP ، يتم تعيين CMS JID إلى sAMAccountName في LDAP ، وهو في الأساس معرف تسجيل دخول المستخدم في Active Directory. لاحظ أيضًا أنك تأخذ sAMAccountName وتضيف المجال conf.pod6.cms.lab إلى نهايته لأن هذا هو تسجيل الدخول الذي سيستخدمه المستخدمون لتسجيل الدخول إلى نظام إدارة المحتوى.

الاسم تعيين ما هو موجود في حقل اسم عرض Active Directory إلى حقل اسم CMS الخاص بالمستخدم.

coSpaceNameMapping ينشئ space'a اسم CMS بناءً على حقل displayName. هذه السمة ، جنبًا إلى جنب مع السمة coSpaceUriMapping ، هي ما هو مطلوب لخلق مساحة لكل مستخدم.

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

coSpaceSecondaryUriMapping يحدد URI الثاني للوصول إلى الفضاء. يمكن استخدام هذا لإضافة اسم مستعار رقمي لتوجيه المكالمات إلى مساحة المستخدم المستورد كبديل لمعرف URI الأبجدي الرقمي المحدد في المعلمة coSpaceUriMapping.

تم تكوين خادم LDAP وتعيين LDAP. الآن نحن بحاجة إلى ربطهم معًا عن طريق إنشاء مصدر LDAP.

استخدام URL للوصول cms01.example.com: 445 / api / v1 / ldapSource قم بإنشاء كائن مصدر LDAP ، مع تحديد معلمات مثل:

• الخادم
• رسم الخرائط
• قاعدة
• تصفية

الآن وبعد اكتمال إعداد LDAP ، يمكنك إجراء عملية المزامنة اليدوية.

نقوم بذلك إما في واجهة الويب لكل خادم عن طريق النقر زامن الآن "لنقل البيانات قسم نشط الدليل


أو عبر أمر API سأعين باستخدام URL للوصول cms01.example.com: 445 / api / v1 / ldapSyncs

المؤتمرات المخصصة

ما هو هذا النظام؟في المفهوم التقليدي للمؤتمر ، يحدث هذا عندما يتحدث اثنان من المشاركين مع بعضهما البعض ، ويضغط أحد المشاركين (باستخدام جهاز مسجل في Unified CM) على الزر "مؤتمر" ، ويتصل بالشخص الآخر ، وبعد التحدث مع هذا الثالث الطرف ، يضغط على الزر "مؤتمر" مرة أخرى للانضمام إلى جميع المشاركين في المؤتمر الثلاثي الأطراف.

الفرق بين مؤتمر Ad-Hoc ومؤتمر CMS المجدول هو أن المؤتمر المخصص ليس مجرد مكالمة SIP إلى CMS. عندما ينقر منشئ المؤتمر على زر المؤتمر مرة ثانية لدعوة الجميع إلى نفس الاجتماع ، يجب على CM الموحد إجراء مكالمة API إلى CMS لإنشاء مؤتمر فوري يتم تحويل جميع المكالمات إليه بعد ذلك. كل هذا يحدث بشكل غير مرئي للمشاركين.

هذا يعني أنه يجب على CM الموحد تكوين بيانات اعتماد API وعنوان / منفذ خدمة WebAdmin ، بالإضافة إلى SIP Trunk مباشرة إلى خادم CMS من أجل متابعة المكالمة.

إذا لزم الأمر ، يمكن لـ CUCM إنشاء مساحة ديناميكية في CMS بحيث يمكن لكل مكالمة الوصول إلى CMS ومطابقة قاعدة المكالمات الواردة المخصصة للمسافات.

التكامل مع CUCM تم تكوينه بنفس الطريقة الموضحة في المقالة في وقت سابق باستثناء أنه على Cisco UCM ، تحتاج إلى إنشاء ثلاثة خطوط رئيسية لـ CMS ، وثلاثة جسور للمؤتمرات ، وتحديد ثلاثة أسماء موضوعات في ملف تعريف أمان SIP ، ومجموعة المسار ، وقائمة المسار ، ومجموعة Media Resourse ، وقائمة مجموعة Media Resourse ، وإضافة بعض قواعد التوجيه إلى Cisco خادم الاجتماع.

ملف تعريف أمان SIP:


جذوع:


كل صندوق يبدو متشابهًا:




جسر مؤتمر


يبدو كل جسر مؤتمر متشابهًا:


مجموعة الطريق


قائمة الطريق


مجموعة الموارد الإعلامية


قائمة مجموعة موارد الوسائط

قواعد الاتصال

على عكس أنظمة التحكم في المكالمات الأكثر تقدمًا مثل Unified CM أو Expressway ، بالنسبة للمكالمات الجديدة ، يبحث CMS فقط عن المجال في حقل SIP Request-URI. لذلك إذا كان SIP INVITE مخصصًا لرشفة: [البريد الإلكتروني محمي]، فإن نظام إدارة المحتوى يهتم فقط بـ domain.com. يتبع نظام إدارة المحتوى هذه القواعد لتحديد مكان توجيه المكالمة:

1. أولاً ، يحاول نظام إدارة المحتوى تعيين مجال SIP إلى المجالات التي تم تكوينها في قواعد معالجة المكالمات الواردة. يمكن بعد ذلك توجيه هذه المكالمات إلى مساحات ("مستهدفة") أو مستخدمين محددين أو IVRs داخلية أو وجهات Microsoft Lync / Skype for Business (S4B) المدمجة مباشرة.
2. في حالة عدم وجود تطابق في قواعد معالجة المكالمات الواردة ، سيحاول نظام إدارة المحتوى مطابقة النطاق الذي تم تكوينه في جدول إعادة توجيه المكالمات. إذا تم إنشاء تطابق ، يمكن للقاعدة رفض المكالمة صراحةً أو إعادة توجيه المكالمة. خلال هذا الوقت ، قد يعيد CMS كتابة المجال ، وهو أمر مفيد أحيانًا للاتصال بمجالات Lync. يمكنك أيضًا اختيار تمرير الرمي ، مما يعني أنه لن يتم تغيير أي من الحقول ، أو استخدام خطة اتصال CMS داخلية. إذا لم يكن هناك تطابق في قواعد إعادة توجيه المكالمات ، فسيتم استخدام رفض المكالمة افتراضيًا. اعلم أنه في CMS ، على الرغم من "إعادة توجيه" المكالمة ، لا تزال الوسائط مرتبطة بـ CMS ، مما يعني أنها ستكون في مسار الإشارات وحركة مرور الوسائط.
عندئذٍ تخضع المكالمات المُعاد توجيهها فقط لقواعد المكالمات الصادرة. تحدد هذه الإعدادات الوجهات التي يتم فيها إرسال المكالمات ونوع الخط الرئيسي (سواء كانت مكالمة Lync جديدة أو SIP قياسيًا) وأي ترجمات يمكن إجراؤها إذا لم يتم تحديد التحويل في قاعدة إعادة توجيه المكالمات.

هذا هو السجل الفعلي لما يحدث أثناء المؤتمر المخصص

تظهر لقطة الشاشة بشكل سيئ (لا أعرف كيفية القيام بذلك بشكل أفضل) ، لذلك سأكتب السجل على النحو التالي:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

المؤتمر المخصص نفسه:


قواعد المكالمات الواردة
يلزم تكوين إعدادات المكالمات الواردة لتتمكن من تلقي مكالمة في نظام إدارة المحتوى. كما رأيت في إعداد LDAP ، تم استيراد جميع المستخدمين بنطاق conf.pod6.cms.lab. لذلك ، على الأقل ، تريد المكالمات إلى هذا المجال لاستهداف المساحات. ستحتاج أيضًا إلى إعداد قواعد لأي شيء يخص FQDN (وربما حتى عنوان IP) لكل خادم من خوادم CMS. سيُنشئ عنصر التحكم في المكالمات الخارجية ، Unified CM ، قنوات SIP مخصصة لكل خادم من خوادم CMS على حدة. ما إذا كانت وجهة خطوط SIP هذه هي عنوان IP أو FQDN الخاص بالخادم سيحدد ما إذا كان يلزم تكوين CMS لقبول المكالمات الموجهة إلى عنوان IP الخاص به أو FQDN.

يتم استخدام المجال الذي يحتوي على أعلى أولوية للقاعدة الواردة كمجال لأي مساحات مستخدم. عندما يقوم المستخدمون بالمزامنة عبر LDAP ، يقوم نظام إدارة المحتوى تلقائيًا بإنشاء مسافات ، ولكن فقط جزء المستخدم من URI (coSpaceUriMapping) ، مثل user.space. جزء نطاق يتم إنشاء URI الكامل بناءً على هذه القاعدة. في الواقع ، إذا كنت ستقوم بتسجيل الدخول إلى Web Bridge في هذه المرحلة ، فسترى أن Space URI لا يحتوي على مجال. من خلال تعيين هذه القاعدة كأولوية قصوى ، فإنك تقوم بتعيين المجال للمساحات التي تم إنشاؤها أسيوط.example.com.


قواعد المكالمات الصادرة

للسماح للمستخدمين بإجراء مكالمات صادرة إلى كتلة Unified CM ، يجب عليك تكوين القواعد الصادرة. مجال نقاط النهاية المسجلة في Unified CM ، مثل Jabber ، هو example.com. يجب توجيه المكالمات إلى هذا المجال كمكالمات SIP قياسية إلى عقد معالجة مكالمات CM الموحدة. الخادم الرئيسي هو cucm-01.example.com ، والخادم الثانوي هو cucm-02.example.com.

تصف القاعدة الأولى أبسط توجيه للمكالمات بين خوادم الكتلة.

حقل محلي من المجال مسؤول عن ما سيتم عرضه في SIP-URI لمتصل الشخص الذي يتم استدعاؤه بعد الرمز "@". إذا تركناه فارغًا ، فبعد الرمز "@" سيكون هناك عنوان IP الخاص بـ CUCM'a الذي تمر من خلاله هذه المكالمة. إذا حددنا مجالًا ، فسيكون هناك مجال بالفعل بعد الرمز "@". يعد هذا ضروريًا لتتمكن من معاودة الاتصال ، وإلا فلن يكون من الممكن إعادة الاتصال باستخدام اسم SIP-URI @ عنوان IP.

اتصل عند الإشارة محلي من المجال


عندما اتصل NOT غير معروف محلي من المجال


تأكد من التحديد الصريح "مشفر" أو "غير مشفر" للمكالمات الصادرة ، لأنه لا شيء يعمل مع المعلمة "تلقائي".

تسجيل

يتم تسجيل مؤتمرات الفيديو بواسطة خادم السجل. المسجل هو بالضبط نفس خادم اجتماعات سيسكو. المسجل لا يتطلب أي تراخيص ليتم تثبيتها على نفسه. تراخيص التسجيل مطلوبة للخوادم التي تقوم بتشغيل خدمات CallBridge ، أي مطلوب ترخيص التسجيل ويجب تطبيقه على مكون CallBridge ، وليس على الخادم الذي يقوم بتشغيل المُسجل. يتصرف المُسجل كعميل بروتوكول المراسلة والتواجد الموسع (XMPP) ، لذلك يجب تمكين خادم XMPP على الخادم الذي يستضيف CallBridge.

لأن لدينا مجموعة ويجب أن "يمتد" الترخيص ليشمل جميع خوادم المجموعة الثلاثة. ثم ببساطة في الحساب الشخصي في التراخيص نقوم بربط (إضافة) عناوين MAC الخاصة بواجهات a لجميع خوادم CMS المضمنة في المجموعة.

وهذه الصورة يجب أن تكون على كل خادم الكتلة

بشكل عام ، هناك عدة سيناريوهات لوضع المسجل ، لكننا سنلتزم بهذا:


قبل إعداد المُسجل ، تحتاج إلى إعداد مكان يتم فيه تسجيل مؤتمرات الفيديو بالفعل. في الواقع هنا رابطكيفية إعداد التسجيل بالكامل. سأركز على النقاط والتفاصيل المهمة:

1. من الأفضل إزالة الشهادة من الخادم الأول في مجموعة.
2. قد يحدث الخطأ "المسجل غير متوفر" بسبب تحديد شهادة خاطئة في ثقة المسجل.
3. قد لا يتم إجراء الكتابة إذا لم تكن الكتابة المحددة هي الدليل الجذر في NFS.

في بعض الأحيان تكون هناك حاجة لتسجيل مؤتمر تلقائيًا لمستخدم أو مساحة معينة.

لهذا ، يتم إنشاء ملفي CallProfiles:
مع تعطيل وظيفة التسجيل


مع وظيفة التسجيل التلقائي


بالإضافة إلى المساحة اللازمة ، نقوم "بربط" ملف تعريف CallProfile بوظيفة التسجيل التلقائية.


في CMS ، تم إثبات أنه إذا تم ربط CallProfile بشكل صريح ببعض المساحات أو المسافات ، فإن CallProfile هذا يعمل فقط لهذه المساحات المحددة. وإذا لم يكن CallProfile مرتبطًا بأي مساحة ، فسيتم تطبيقه افتراضيًا على تلك المسافات التي لا يرتبط بها CallProfile بشكل صريح.

سأحاول في المرة القادمة وصف كيفية الوصول إلى نظام إدارة المحتوى خارج الشبكة الداخلية للمؤسسة.

مصادر:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and- لاحقًا. بي دي إف

المصدر: www.habr.com