सिस्को मीटिंग सर्वर 2.5.2. वीडियो कॉन्फ़्रेंस रिकॉर्डिंग फ़ंक्शन के साथ स्केलेबल और लचीला मोड में क्लस्टर

इस अंक में मैं फेलओवर क्लस्टर मोड में सीएमएस सर्वर स्थापित करने की कुछ जटिलताओं को दिखाऊंगा और समझाऊंगा।


Теорияसामान्य तौर पर, CMS सर्वर परिनियोजन तीन प्रकार के होते हैं:

• एकल संयुक्त(एकल संयुक्त), अर्थात्। यह एक सर्वर है जिस पर सभी आवश्यक सेवाएँ चल रही हैं। ज्यादातर मामलों में, इस प्रकार की तैनाती केवल आंतरिक क्लाइंट एक्सेस के लिए और छोटे वातावरणों में उपयुक्त होती है जहां एकल सर्वर की स्केलेबिलिटी और अतिरेक सीमाएं एक महत्वपूर्ण मुद्दा नहीं होती हैं, या ऐसी स्थितियों में जहां सीएमएस केवल कुछ कार्य करता है, जैसे तदर्थ सिस्को यूसीएम पर सम्मेलन।

  कार्य की अनुमानित योजना:
  

• एकल विभाजन(सिंगल स्प्लिट) बाहरी पहुंच के लिए एक अलग सर्वर जोड़कर पिछले परिनियोजन प्रकार का विस्तार करता है। विरासती तैनाती में, इसका मतलब एक सीएमएस सर्वर को एक डिमिलिटराइज्ड नेटवर्क सेगमेंट (डीएमजेड) में तैनात करना है जहां बाहरी ग्राहक इसे एक्सेस कर सकते हैं, और नेटवर्क कोर में एक सीएमएस सर्वर जहां आंतरिक क्लाइंट सीएमएस तक पहुंच सकते हैं। इस विशेष परिनियोजन मॉडल को अब तथाकथित प्रकार द्वारा प्रतिस्थापित किया जा रहा है एकल किनारा, जिसमें सर्वर शामिल हैं सिस्को एक्सप्रेसवे, जिसमें या तो समान फ़ायरवॉल बायपास क्षमताएं हैं या होंगी, इसलिए ग्राहकों को एक समर्पित एज सीएमएस सर्वर जोड़ने की आवश्यकता नहीं है।

  कार्य की अनुमानित योजना:
  

• स्केलेबल और लचीला(स्केलेबल और फॉल्ट टॉलरेंट) इस प्रकार में प्रत्येक घटक के लिए अतिरेक शामिल है, जो विफलता के मामले में अतिरेक प्रदान करते हुए सिस्टम को आपकी आवश्यकताओं के साथ अपनी अधिकतम क्षमता तक बढ़ने की अनुमति देता है। यह सुरक्षित बाहरी पहुंच प्रदान करने के लिए सिंगल एज अवधारणा का भी उपयोग करता है। इस प्रकरण में हम इसी प्रकार को देखेंगे। यदि हम समझते हैं कि इस प्रकार के क्लस्टर को कैसे तैनात किया जाए, तो हम न केवल अन्य प्रकार की तैनाती को समझ पाएंगे, बल्कि हम यह भी समझ पाएंगे कि मांग में संभावित वृद्धि को समायोजित करने के लिए सीएमएस सर्वर के क्लस्टर कैसे बनाएं।

तैनाती पर आगे बढ़ने से पहले, आपको कुछ बुनियादी बातों को समझने की आवश्यकता है, अर्थात्

मुख्य सीएमएस सॉफ्टवेयर घटक:

• डाटाबेस: आपको कुछ कॉन्फ़िगरेशन को संयोजित करने की अनुमति देता है, जैसे डायल प्लान, उपयोगकर्ता स्थान और स्वयं उपयोगकर्ता। केवल उच्च उपलब्धता (एकल मास्टर) के लिए क्लस्टरिंग का समर्थन करता है।
• कॉल ब्रिज: ऑडियो और वीडियो कॉन्फ्रेंसिंग के लिए एक सेवा जो कॉल और मल्टीमीडिया प्रक्रियाओं के प्रबंधन और प्रसंस्करण पर पूर्ण नियंत्रण प्रदान करती है। उच्च उपलब्धता और मापनीयता के लिए क्लस्टरिंग का समर्थन करता है।
• एक्सएमपीपी सर्वर: सिस्को मीटिंग एप्लिकेशन और/या वेबआरटीसी का उपयोग करके ग्राहकों के पंजीकरण और प्रमाणीकरण के लिए जिम्मेदार(वास्तविक समय संचार, या बस ब्राउज़र में), साथ ही इंटरकंपोनेंट सिग्नलिंग। केवल उच्च उपलब्धता के लिए क्लस्टर किया जा सकता है।
• वेब ब्रिज: क्लाइंट को WebRTC तक पहुंच प्रदान करता है।
• भार संतुलन: सिंगल स्प्लिट मोड में सिस्को मीटिंग ऐप्स के लिए एकल कनेक्शन बिंदु प्रदान करता है। आने वाले कनेक्शन के लिए बाहरी इंटरफ़ेस और पोर्ट को सुनता है। समान रूप से, लोड बैलेंसर एक्सएमपीपी सर्वर से आने वाले टीएलएस कनेक्शन को स्वीकार करता है, जिसके माध्यम से यह बाहरी क्लाइंट से टीसीपी कनेक्शन स्विच कर सकता है।
  हमारे परिदृश्य में इसकी आवश्यकता नहीं होगी.
• सर्वर चालू करें: फ़ायरवॉल बायपास तकनीक प्रदान करता है जो अनुमति देता है
  सिस्को मीटिंग ऐप या एसआईपी उपकरणों का उपयोग करके बाहरी ग्राहकों को जोड़ने के लिए हमारे सीएमएस को फ़ायरवॉल या एनएटी के पीछे रखें। हमारे परिदृश्य में इसकी आवश्यकता नहीं होगी.
• वेब एडमिन: विशेष एकीकृत सीएम सम्मेलनों सहित प्रशासनिक इंटरफ़ेस और एपीआई पहुंच।

कॉन्फ़िगरेशन मोड

अधिकांश अन्य सिस्को उत्पादों के विपरीत, सिस्को मीटिंग सर्वर किसी भी प्रकार की तैनाती को समायोजित करने के लिए तीन कॉन्फ़िगरेशन विधियों का समर्थन करता है।

• कमांड लाइन (सीएलआई): प्रारंभिक कॉन्फ़िगरेशन और प्रमाणपत्र कार्यों के लिए कमांड लाइन इंटरफ़ेस को एमएमपी के रूप में जाना जाता है।
• वेब प्रशासक: मुख्य रूप से कॉलब्रिज से संबंधित कॉन्फ़िगरेशन के लिए, विशेष रूप से एकल गैर-क्लस्टर सर्वर स्थापित करते समय।
• बाकी एपीआई: सबसे जटिल कॉन्फ़िगरेशन कार्यों और क्लस्टर्ड डेटाबेस से संबंधित कार्यों के लिए उपयोग किया जाता है।

उपरोक्त के अतिरिक्त, प्रोटोकॉल का उपयोग किया जाता है SFTP सीएमएस सर्वर से फ़ाइलें - आमतौर पर लाइसेंस, प्रमाणपत्र, या लॉग - स्थानांतरित करने के लिए।

सिस्को के परिनियोजन गाइड में सफेद और अंग्रेजी में लिखा है कि क्लस्टर को तैनात करने की आवश्यकता है कम से कम तीन डेटाबेस के संदर्भ में सर्वर (नोड्स)। क्योंकि केवल विषम संख्या में नोड्स के साथ ही नए डेटाबेस मास्टर को चुनने का तंत्र काम करेगा, और सामान्य तौर पर डेटाबेस मास्टर का अधिकांश सीएमएस सर्वर डेटाबेस के साथ संबंध होता है।

और जैसा कि अभ्यास से पता चलता है, दो सर्वर (नोड्स) वास्तव में पर्याप्त नहीं हैं। चयन तंत्र तब काम करता है जब मास्टर को रिबूट किया जाता है, रिबूट सर्वर को लाने के बाद ही स्लेव सर्वर मास्टर बन जाता है। हालाँकि, यदि दो सर्वरों के समूह में मास्टर सर्वर अचानक बाहर चला जाता है, तो स्लेव सर्वर मास्टर नहीं बन जाएगा, और यदि स्लेव बाहर चला जाता है, तो शेष मास्टर सर्वर स्लेव बन जाएगा।

लेकिन एक्सएमपीपी के संदर्भ में, तीन सर्वरों के क्लस्टर को इकट्ठा करना वास्तव में आवश्यक होगा, क्योंकि यदि, उदाहरण के लिए, आप उन सर्वरों में से एक पर एक्सएमपीपी सेवा को अक्षम करते हैं जिसमें एक्सएमएमपी लीडर स्थिति में है, तो शेष सर्वर पर एक्सएमपीपी फॉलोअर स्थिति में रहेगा और एक्सएमपीपी से कॉलब्रिज कनेक्शन बंद हो जाएगा, क्योंकि कॉलब्रिज लीडर स्टेटस के साथ विशेष रूप से एक्सएमपीपी से जुड़ता है। और यह महत्वपूर्ण है, क्योंकि... एक भी कॉल नहीं जाएगी.

साथ ही उसी परिनियोजन गाइड में एक XMPP सर्वर के साथ एक क्लस्टर का प्रदर्शन किया जाता है।

और उपरोक्त को ध्यान में रखते हुए, यह स्पष्ट हो जाता है कि क्यों: यह काम करता है क्योंकि यह फेलओवर मोड में है।

हमारे मामले में, एक्सएमपीपी सर्वर तीनों नोड्स पर मौजूद होगा।

यह माना जाता है कि हमारे तीनों सर्वर चालू हैं।

डीएनएस रिकॉर्ड

इससे पहले कि आप सर्वर स्थापित करना शुरू करें, आपको DNS रिकॉर्ड बनाना होगा А и SRV प्रकार:

कृपया ध्यान दें कि हमारे DNS रिकॉर्ड में दो डोमेन हैं example.com और conf.example.com. example.com एक डोमेन है जिसे सभी सिस्को यूनिफाइड कम्युनिकेशन मैनेजर सब्सक्राइबर अपने यूआरआई के लिए उपयोग कर सकते हैं, जो संभवतः आपके बुनियादी ढांचे में मौजूद है या मौजूद होने की संभावना है। या example.com उसी डोमेन से मेल खाता है जिसका उपयोग उपयोगकर्ता अपने ईमेल पते के लिए करते हैं। या आपके लैपटॉप पर जैबर क्लाइंट के पास यूआरआई हो सकता है [ईमेल संरक्षित]. कार्यक्षेत्र conf.example.com वह डोमेन है जिसे सिस्को मीटिंग सर्वर उपयोगकर्ताओं के लिए कॉन्फ़िगर किया जाएगा। सिस्को मीटिंग सर्वर का डोमेन होगा conf.example.com, इसलिए उसी जैबर उपयोगकर्ता के लिए, सिस्को मीटिंग सर्वर में लॉग इन करने के लिए उपयोगकर्ता@यूआरआई का उपयोग करना होगाconf.example.com.

मूल विन्यास

नीचे वर्णित सभी सेटिंग्स एक सर्वर पर दिखाई गई हैं, लेकिन उन्हें क्लस्टर में प्रत्येक सर्वर पर करने की आवश्यकता है।

QoS

चूंकि सीएमएस उत्पन्न करता है वास्तविक समय देरी और पैकेट हानि के प्रति संवेदनशील ट्रैफ़िक, ज्यादातर मामलों में सेवा की गुणवत्ता (क्यूओएस) को कॉन्फ़िगर करने की अनुशंसा की जाती है। इसे प्राप्त करने के लिए, सीएमएस अपने द्वारा उत्पन्न विभेदित सेवा कोड (डीएससीपी) के साथ टैगिंग पैकेट का समर्थन करता है। हालाँकि डीएससीपी-आधारित ट्रैफ़िक प्राथमिकता इस बात पर निर्भर करती है कि ट्रैफ़िक को आपके बुनियादी ढांचे के नेटवर्क घटकों द्वारा कैसे संसाधित किया जाता है, हमारे मामले में हम क्यूओएस सर्वोत्तम प्रथाओं के आधार पर अपने सीएमएस को विशिष्ट डीएससीपी प्राथमिकता के साथ कॉन्फ़िगर करेंगे।

प्रत्येक सर्वर पर हम ये कमांड दर्ज करेंगे

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 server add <server>

हमारे मामले में, ऐसे दो सर्वर हैं, इसलिए दो टीमें होंगी।
हम जाँच:

और हमारे सर्वर के लिए समय क्षेत्र निर्धारित करें

डीएनएस

हम DNS सर्वर को CMS में एक कमांड के साथ जोड़ते हैं:

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

हमारे मामले में, ऐसे दो सर्वर हैं, इसलिए दो टीमें होंगी।
हम जाँच:

नेटवर्क इंटरफ़ेस कॉन्फ़िगरेशन

हम इंटरफ़ेस को एक कमांड के साथ कॉन्फ़िगर करते हैं जैसे:

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

हम जाँच:

सर्वर नाम (होस्टनाम)

हम सर्वर नाम को एक कमांड के साथ सेट करते हैं जैसे:

hostname <name>

और हम रिबूट करते हैं।


यह बुनियादी विन्यास पूरा करता है.

प्रमाण पत्र

Теорияसिस्को मीटिंग सर्वर को विभिन्न घटकों के बीच एन्क्रिप्टेड संचार की आवश्यकता होती है, और परिणामस्वरूप, सभी सीएमएस तैनाती के लिए X.509 प्रमाणपत्र की आवश्यकता होती है। वे यह सुनिश्चित करने में सहायता करते हैं कि सेवाएँ/सर्वर अन्य सर्वरों/सेवाओं द्वारा विश्वसनीय है।

प्रत्येक सेवा के लिए एक प्रमाणपत्र की आवश्यकता होती है, लेकिन प्रत्येक सेवा के लिए अलग प्रमाणपत्र बनाने से भ्रम और अनावश्यक जटिलता पैदा हो सकती है। सौभाग्य से, हम एक प्रमाणपत्र की सार्वजनिक-निजी कुंजी जोड़ी उत्पन्न कर सकते हैं और फिर उन्हें कई सेवाओं में पुन: उपयोग कर सकते हैं। हमारे मामले में, कॉल ब्रिज, एक्सएमपीपी सर्वर, वेब ब्रिज और वेब एडमिन के लिए समान प्रमाणपत्र का उपयोग किया जाएगा। इस प्रकार, आपको क्लस्टर में प्रत्येक सर्वर के लिए सार्वजनिक और निजी प्रमाणपत्र कुंजियों की एक जोड़ी बनाने की आवश्यकता है।

हालाँकि, डेटाबेस क्लस्टरिंग के लिए कुछ विशेष प्रमाणपत्र आवश्यकताएँ होती हैं और इसलिए इसके स्वयं के प्रमाणपत्रों की आवश्यकता होती है जो अन्य सेवाओं से भिन्न होते हैं। सीएमएस एक सर्वर प्रमाणपत्र का उपयोग करता है, जो अन्य सर्वरों द्वारा उपयोग किए जाने वाले प्रमाणपत्रों के समान है, लेकिन डेटाबेस कनेक्शन के लिए एक क्लाइंट प्रमाणपत्र भी उपयोग किया जाता है। डेटाबेस प्रमाणपत्र का उपयोग प्रमाणीकरण और एन्क्रिप्शन दोनों के लिए किया जाता है। क्लाइंट को डेटाबेस से कनेक्ट करने के लिए उपयोगकर्ता नाम और पासवर्ड प्रदान करने के बजाय, यह एक क्लाइंट प्रमाणपत्र प्रस्तुत करता है जिस पर सर्वर द्वारा भरोसा किया जाता है। डेटाबेस क्लस्टर में प्रत्येक सर्वर समान सार्वजनिक और निजी कुंजी जोड़ी का उपयोग करेगा। यह क्लस्टर के सभी सर्वरों को डेटा को इस तरह से एन्क्रिप्ट करने की अनुमति देता है कि इसे केवल अन्य सर्वरों द्वारा ही डिक्रिप्ट किया जा सकता है जो समान कुंजी जोड़ी साझा करते हैं।

काम करने के लिए अतिरेक के लिए, डेटाबेस क्लस्टर में न्यूनतम 3 सर्वर शामिल होने चाहिए, लेकिन 5 से अधिक नहीं, किसी भी क्लस्टर सदस्यों के बीच अधिकतम राउंड-ट्रिप समय 200 एमएस होना चाहिए। यह सीमा कॉल ब्रिज क्लस्टरिंग की तुलना में अधिक प्रतिबंधात्मक है, इसलिए यह अक्सर भौगोलिक रूप से वितरित तैनाती में सीमित कारक है।

सीएमएस के लिए डेटाबेस भूमिका में कई विशिष्ट आवश्यकताएं होती हैं। अन्य भूमिकाओं के विपरीत, इसके लिए क्लाइंट और सर्वर प्रमाणपत्र की आवश्यकता होती है, जहां क्लाइंट प्रमाणपत्र में एक विशिष्ट CN फ़ील्ड होता है जो सर्वर पर प्रस्तुत किया जाता है।

सीएमएस एक मास्टर और कई पूरी तरह से समान प्रतिकृतियों के साथ पोस्टग्रेज डेटाबेस का उपयोग करता है। एक समय में केवल एक ही प्राथमिक डेटाबेस होता है ("डेटाबेस सर्वर")। क्लस्टर के शेष सदस्य प्रतिकृतियां या "डेटाबेस क्लाइंट" हैं।

डेटाबेस क्लस्टर को एक समर्पित सर्वर प्रमाणपत्र और क्लाइंट प्रमाणपत्र की आवश्यकता होती है। उन्हें प्रमाणपत्रों द्वारा हस्ताक्षरित किया जाना चाहिए, आमतौर पर एक आंतरिक निजी प्रमाणपत्र प्राधिकारी द्वारा। क्योंकि डेटाबेस क्लस्टर का कोई भी सदस्य मास्टर बन सकता है, डेटाबेस सर्वर और क्लाइंट सर्टिफिकेट जोड़े (सार्वजनिक और निजी कुंजी युक्त) को सभी सर्वरों पर कॉपी किया जाना चाहिए ताकि वे क्लाइंट या डेटाबेस सर्वर की पहचान मान सकें। इसके अलावा, यह सुनिश्चित करने के लिए कि क्लाइंट और सर्वर प्रमाणपत्र सत्यापित किए जा सकते हैं, सीए रूट प्रमाणपत्र लोड किया जाना चाहिए।

इसलिए, हम एक प्रमाणपत्र के लिए एक अनुरोध बनाते हैं जिसका उपयोग डेटाबेस को छोड़कर सभी सर्वर सेवाओं द्वारा किया जाएगा (इसके लिए एक अलग अनुरोध होगा) जैसे कमांड के साथ:

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

सीएन में हम अपने सर्वर का सामान्य नाम लिखते हैं। उदाहरण के लिए, यदि हमारे सर्वर के होस्टनाम server01, server02, server03, तो CN होगा सर्वर.example.com

हम शेष दो सर्वरों पर भी ऐसा ही करते हैं, इस अंतर के साथ कि कमांड में संबंधित "होस्टनाम" होंगे

हम प्रमाणपत्रों के लिए दो अनुरोध उत्पन्न करते हैं जिनका उपयोग डेटाबेस सेवा द्वारा निम्न आदेशों के साथ किया जाएगा:

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

pki csr dbclusterclient CN:postgres

जहां dbक्लस्टरसर्वर и dbक्लस्टरक्लाइंट हमारे अनुरोधों और भविष्य के प्रमाणपत्रों के नाम, होस्टनाम1(2)(3) संबंधित सर्वर के नाम.

हम यह प्रक्रिया केवल एक सर्वर (!) पर करते हैं, और हम प्रमाणपत्र और संबंधित .key फ़ाइलें अन्य सर्वर पर अपलोड करेंगे।

AD CS में क्लाइंट प्रमाणपत्र मोड सक्षम करें

आपको प्रत्येक सर्वर के प्रमाणपत्रों को एक फ़ाइल में मर्ज करने की भी आवश्यकता है।*एनआईएक्स पर:

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

विंडोज़/डॉस पर:

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

और प्रत्येक सर्वर पर अपलोड करें:
1. "व्यक्तिगत" सर्वर प्रमाणपत्र.
2. मूल प्रमाणपत्र (मध्यवर्ती प्रमाण पत्र सहित, यदि कोई हो)।
3. डेटाबेस के लिए प्रमाणपत्र ("सर्वर" और "क्लाइंट") और .key एक्सटेंशन वाली फ़ाइलें, जो "सर्वर" और "क्लाइंट" डेटाबेस प्रमाणपत्रों के लिए अनुरोध बनाते समय उत्पन्न की गई थीं। ये फ़ाइलें सभी सर्वर पर समान होनी चाहिए.
4. तीनों "व्यक्तिगत" प्रमाणपत्रों की फ़ाइल।

परिणामस्वरूप, आपको प्रत्येक सर्वर पर इस फ़ाइल चित्र जैसा कुछ मिलना चाहिए।

डेटाबेस क्लस्टर

अब जब आपके पास सीएमएस सर्वर पर सभी प्रमाणपत्र अपलोड हो गए हैं, तो आप तीन नोड्स के बीच डेटाबेस क्लस्टरिंग को कॉन्फ़िगर और सक्षम कर सकते हैं। पहला कदम डेटाबेस क्लस्टर के मास्टर नोड के रूप में एक सर्वर का चयन करना और इसे पूरी तरह से कॉन्फ़िगर करना है।

मास्टर डेटाबेस

डेटाबेस प्रतिकृति स्थापित करने में पहला कदम उन प्रमाणपत्रों को निर्दिष्ट करना है जिनका उपयोग डेटाबेस के लिए किया जाएगा। यह एक कमांड का उपयोग करके किया जाता है जैसे:

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

अब सीएमएस को बताएं कि कमांड के साथ डेटाबेस क्लस्टरिंग के लिए किस इंटरफ़ेस का उपयोग करना है:

database cluster localnode a

फिर हम कमांड के साथ मुख्य सर्वर पर क्लस्टर डेटाबेस को आरंभ करते हैं:

database cluster initialize

क्लाइंट डेटाबेस नोड्स

हम वही प्रक्रिया करते हैं, केवल कमांड के बजाय डेटाबेस क्लस्टर प्रारंभ करें एक कमांड दर्ज करें जैसे:

database cluster join <ip address existing master>

जहां आईपी पता मौजूदा मास्टर सीएमएस सर्वर का आईपी पता है जिस पर क्लस्टर प्रारंभ किया गया था, बस मास्टर।

हम जाँचते हैं कि हमारा डेटाबेस क्लस्टर कमांड के साथ सभी सर्वरों पर कैसे काम करता है:

database cluster status

हम शेष तीसरे सर्वर पर भी ऐसा ही करते हैं।

परिणामस्वरूप, यह पता चलता है कि हमारा पहला सर्वर मास्टर है, बाकी गुलाम हैं।

वेब व्यवस्थापक सेवा

वेब व्यवस्थापक सेवा सक्षम करें:

webadmin listen a 445

पोर्ट 445 को इसलिए चुना गया क्योंकि पोर्ट 443 का उपयोग वेब क्लाइंट तक उपयोगकर्ता की पहुंच के लिए किया जाता है

हम वेब एडमिन सेवा को प्रमाणपत्र फ़ाइलों के साथ एक कमांड के साथ कॉन्फ़िगर करते हैं:

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

और कमांड के साथ वेब एडमिन को सक्षम करें:

webadmin enable

यदि सब कुछ ठीक रहा, तो हमें SUCCESS पंक्तियाँ प्राप्त होंगी जो दर्शाती हैं कि वेब एडमिन नेटवर्क और प्रमाणपत्र के लिए सही ढंग से कॉन्फ़िगर किया गया है। हम वेब ब्राउज़र का उपयोग करके सेवा की कार्यक्षमता की जांच करते हैं और वेब व्यवस्थापक का पता दर्ज करते हैं, उदाहरण के लिए: cms.example.com: 445

ब्रिज क्लस्टर को कॉल करें

कॉल ब्रिज प्रत्येक सीएमएस परिनियोजन में मौजूद एकमात्र सेवा है। कॉल ब्रिज मुख्य कॉन्फ्रेंसिंग तंत्र है। यह एक एसआईपी इंटरफ़ेस भी प्रदान करता है ताकि कॉल को उदाहरण के लिए, सिस्को यूनिफाइड सीएम द्वारा या उससे रूट किया जा सके।

नीचे वर्णित आदेशों को प्रत्येक सर्वर पर उचित प्रमाणपत्रों के साथ निष्पादित किया जाना चाहिए।
तो:

हम प्रमाणपत्रों को कॉल ब्रिज सेवा के साथ एक कमांड के साथ जोड़ते हैं:

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

हम कॉलब्रिज सेवाओं को कमांड के साथ आवश्यक इंटरफ़ेस से जोड़ते हैं:

callbridge listen a

और कमांड के साथ सेवा को पुनरारंभ करें:

callbridge restart

अब जब हमने अपना कॉल ब्रिज कॉन्फ़िगर कर लिया है, तो हम कॉल ब्रिज क्लस्टरिंग कॉन्फ़िगर कर सकते हैं। कॉल ब्रिज क्लस्टरिंग डेटाबेस या एक्सएमपीपी क्लस्टरिंग से अलग है। कॉल ब्रिज क्लस्टर बिना किसी प्रतिबंध के 2 से 8 नोड्स तक का समर्थन कर सकता है। यह न केवल अतिरेक प्रदान करता है, बल्कि लोड संतुलन भी प्रदान करता है ताकि कॉन्फ्रेंस को बुद्धिमान कॉल वितरण का उपयोग करके कॉल ब्रिज सर्वर पर सक्रिय रूप से वितरित किया जा सके। सीएमएस में अतिरिक्त सुविधाएं, कॉल ब्रिज समूह और संबंधित सुविधाएं हैं जिनका उपयोग आगे के प्रबंधन के लिए किया जा सकता है।

कॉल ब्रिज क्लस्टरिंग को मुख्य रूप से वेब एडमिन इंटरफ़ेस के माध्यम से कॉन्फ़िगर किया गया है
नीचे वर्णित प्रक्रिया क्लस्टर में प्रत्येक सर्वर पर की जानी चाहिए।
इस प्रकार,

1. वेब के माध्यम से कॉन्फ़िगरेशन> क्लस्टर पर जाएं।
2। कॉल ब्रिज पहचान एक अद्वितीय नाम के रूप में, सर्वर नाम के अनुरूप कॉलब्रिज[01,02,03] दर्ज करें। ये नाम मनमाने हैं, लेकिन इस क्लस्टर के लिए अद्वितीय होने चाहिए। वे प्रकृति में वर्णनात्मक हैं क्योंकि वे संकेत देते हैं कि वे सर्वर पहचानकर्ता हैं [01,02,03]।
3.बी क्लस्टर्ड कॉल ब्रिज क्लस्टर में हमारे सर्वर के वेब व्यवस्थापक यूआरएल दर्ज करें, सीएमएस[01,02,03].example.com:445, पता फ़ील्ड में। पोर्ट निर्दिष्ट करना सुनिश्चित करें. आप पीयर लिंक एसआईपी डोमेन को खाली छोड़ सकते हैं।
4. प्रत्येक सर्वर के कॉलब्रिज ट्रस्ट में एक प्रमाणपत्र जोड़ें, जिसकी फ़ाइल में हमारे सर्वर के सभी प्रमाणपत्र शामिल हैं, जिन्हें हमने शुरुआत में ही इस फ़ाइल में एक कमांड के साथ विलय कर दिया था:

callbridge trust cluster <trusted cluster certificate bundle>

और कमांड के साथ सेवा को पुनरारंभ करें:

callbridge restart

परिणामस्वरूप, प्रत्येक सर्वर पर आपको यह चित्र मिलना चाहिए:

एक्सएमपीपी क्लस्टर

सीएमएस में एक्सएमपीपी सेवा का उपयोग सीएमए वेबआरटीसी वेब क्लाइंट सहित सिस्को मीटिंग ऐप्स (सीएमए) के लिए सभी पंजीकरण और प्रमाणीकरण को संभालने के लिए किया जाता है। कॉल ब्रिज स्वयं भी प्रमाणीकरण उद्देश्यों के लिए एक एक्सएमपीपी क्लाइंट के रूप में कार्य करता है और इसलिए इसे अन्य क्लाइंट की तरह कॉन्फ़िगर किया जाना चाहिए। एक्सएमपीपी दोष सहिष्णुता एक ऐसी सुविधा है जिसे संस्करण 2.1 से उत्पादन परिवेश में समर्थित किया गया है

नीचे वर्णित आदेशों को प्रत्येक सर्वर पर उचित प्रमाणपत्रों के साथ निष्पादित किया जाना चाहिए।
तो:

हम प्रमाणपत्रों को XMPP सेवा के साथ एक कमांड के साथ जोड़ते हैं:

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

फिर कमांड के साथ श्रवण इंटरफ़ेस को परिभाषित करें:

xmpp listen a

एक्सएमपीपी सेवा के लिए एक अद्वितीय डोमेन की आवश्यकता होती है। यह उपयोगकर्ताओं के लिए लॉगिन है. दूसरे शब्दों में, जब कोई उपयोगकर्ता CMA ऐप (या WebRTC क्लाइंट के माध्यम से) का उपयोग करके लॉगिन करने का प्रयास करता है, तो वे userID@logindomain दर्ज करते हैं। हमारे मामले में यह userid@ होगाconf.example.com. यह सिर्फ example.com क्यों नहीं है? हमारी विशेष तैनाती में, हमने अपना यूनिफाइड सीएम डोमेन चुना है जिसे जैबर उपयोगकर्ता यूनिफाइड सीएम में example.com के रूप में उपयोग करेंगे, इसलिए हमें सीएमएस उपयोगकर्ताओं के लिए एसआईपी डोमेन के माध्यम से सीएमएस से कॉल रूट करने के लिए एक अलग डोमेन की आवश्यकता थी।

निम्न कमांड का उपयोग करके एक XMPP डोमेन सेट करें:

xmpp domain <domain>

और कमांड के साथ एक्सएमपीपी सेवा सक्षम करें:

xmpp enable

एक्सएमपीपी सेवा में, आपको प्रत्येक कॉल ब्रिज के लिए क्रेडेंशियल बनाना होगा जिसका उपयोग एक्सएमपीपी सेवा के साथ पंजीकरण करते समय किया जाएगा। ये नाम मनमाने हैं (और कॉल ब्रिज क्लस्टरिंग के लिए आपके द्वारा कॉन्फ़िगर किए गए अद्वितीय नामों से संबंधित नहीं हैं)। आपको एक एक्सएमपीपी सर्वर पर तीन कॉल ब्रिज जोड़ना होगा और फिर क्लस्टर में अन्य एक्सएमपीपी सर्वर पर उन क्रेडेंशियल्स को दर्ज करना होगा क्योंकि यह कॉन्फ़िगरेशन क्लस्टर डेटाबेस में फिट नहीं होता है। बाद में हम एक्सएमपीपी सेवा के साथ पंजीकरण करने के लिए इस नाम और रहस्य का उपयोग करने के लिए प्रत्येक कॉल ब्रिज को कॉन्फ़िगर करेंगे।

अब हमें तीन कॉल ब्रिज कॉलब्रिज01, कॉलब्रिज02 और कॉलब्रिज03 के साथ पहले सर्वर पर एक्सएमपीपी सेवा को कॉन्फ़िगर करने की आवश्यकता है। प्रत्येक खाते को यादृच्छिक पासवर्ड सौंपे जाएंगे। बाद में उन्हें इस एक्सएमपीपी सर्वर में लॉग इन करने के लिए अन्य कॉल ब्रिज सर्वर पर दर्ज किया जाएगा। निम्नलिखित आदेश दर्ज करें:

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

हम सीक्रेट को बहुत सावधानी से जोड़ते हैं ताकि, उदाहरण के लिए, इसमें कोई अतिरिक्त स्थान न रहे।


परिणामस्वरूप, प्रत्येक सर्वर पर एक ही चित्र होना चाहिए:

इसके बाद, क्लस्टर के सभी सर्वरों पर, हम इस तरह के कमांड के साथ पहले बनाए गए सभी तीन प्रमाणपत्रों वाली फ़ाइल को ट्रस्ट में निर्दिष्ट करते हैं:

xmpp cluster trust <trust bundle>

हम कमांड के साथ सभी क्लस्टर सर्वर पर xmpp क्लस्टर मोड सक्षम करते हैं:

xmpp cluster enable

क्लस्टर के पहले सर्वर पर, हम कमांड के साथ एक xmpp क्लस्टर का निर्माण शुरू करते हैं:

xmpp cluster initialize

अन्य सर्वर पर, कमांड के साथ xmpp में एक क्लस्टर जोड़ें:

xmpp cluster join <ip address head xmpp server>

हम प्रत्येक सर्वर पर कमांड के साथ एक एक्सएमपीपी क्लस्टर बनाने की सफलता की जांच करते हैं:

xmpp status
xmpp cluster status

पहला सर्वर:

दूसरा सर्वर:

तीसरा सर्वर:

कॉल ब्रिज को एक्सएमपीपी से जोड़ना

अब जब एक्सएमपीपी क्लस्टर चल रहा है, तो आपको एक्सएमपीपी क्लस्टर से कनेक्ट करने के लिए कॉल ब्रिज सेवाओं को कॉन्फ़िगर करने की आवश्यकता है। यह कॉन्फ़िगरेशन वेब एडमिन के माध्यम से किया जाता है.

प्रत्येक सर्वर पर, कॉन्फ़िगरेशन > सामान्य और फ़ील्ड में जाएँ अनोखा कॉल ब्रिज नाम सर्वर कॉल ब्रिज के अनुरूप अद्वितीय नाम लिखें कॉलब्रिज[01,02,03]. оле डोमेन conf.example.ru और संबंधित पासवर्ड, आप उनकी जासूसी कर सकते हैं
कमांड के साथ क्लस्टर में किसी भी सर्वर पर:

xmpp callbridge list

"सर्वर" फ़ील्ड को खाली छोड़ दें कॉलब्रिज के लिए DNS SRV लुकअप निष्पादित करेगा _xmpp-component._tcp.conf.example.comउपलब्ध XMPP सर्वर ढूँढ़ने के लिए। कॉलब्रिज को एक्सएमपीपी से जोड़ने के लिए आईपी पते प्रत्येक सर्वर पर भिन्न हो सकते हैं, यह इस पर निर्भर करता है कि रिकॉर्ड अनुरोध पर कौन से मान लौटाए गए हैं _xmpp-component._tcp.conf.example.com कॉलब्रिज, जो बदले में किसी दिए गए DNS रिकॉर्ड के लिए प्राथमिकता सेटिंग्स पर निर्भर करता है।

इसके बाद, यह सत्यापित करने के लिए स्टेटस > जनरल पर जाएं कि कॉल ब्राइड सेवा एक्सएमपीपी सेवा से सफलतापूर्वक जुड़ी है या नहीं।

वेब ब्रिज

क्लस्टर में प्रत्येक सर्वर पर, कमांड के साथ वेब ब्रिज सेवा को सक्षम करें:

webbridge listen a:443

हम वेब ब्रिज सेवा को प्रमाणपत्र फ़ाइलों के साथ एक कमांड के साथ कॉन्फ़िगर करते हैं:

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

वेब ब्रिज HTTPS को सपोर्ट करता है। यदि इसे "http-रीडायरेक्ट" का उपयोग करने के लिए कॉन्फ़िगर किया गया है तो यह HTTP को HTTPS पर रीडायरेक्ट कर देगा।
HTTP पुनर्निर्देशन सक्षम करने के लिए, निम्न आदेश का उपयोग करें:

webbridge http-redirect enable

कॉल ब्रिज को यह बताने के लिए कि वेब ब्रिज कॉल ब्रिज के कनेक्शन पर भरोसा कर सकता है, कमांड का उपयोग करें:

webbridge trust <certfile>

जहां यह एक फ़ाइल है जिसमें क्लस्टर में प्रत्येक सर्वर से सभी तीन प्रमाणपत्र शामिल हैं।

यह चित्र क्लस्टर के प्रत्येक सर्वर पर होना चाहिए.


अब हमें "एपैडमिन" भूमिका के साथ एक उपयोगकर्ता बनाने की आवश्यकता है, हमें इसकी आवश्यकता है ताकि हम अपने क्लस्टर (!) को कॉन्फ़िगर कर सकें, और क्लस्टर में प्रत्येक सर्वर को अलग से नहीं, इस तरह सेटिंग्स प्रत्येक सर्वर पर समान रूप से लागू की जाएंगी तथ्य यह है कि वे एक बार बनाए जाएंगे।


आगे के सेटअप के लिए हम उपयोग करेंगे पोस्टमैन.

प्राधिकरण के लिए, प्राधिकरण अनुभाग में बेसिक का चयन करें

सीएमएस सर्वर पर कमांड को सही ढंग से भेजने के लिए, आपको आवश्यक एन्कोडिंग सेट करने की आवश्यकता है

हम कमांड के साथ वेबब्रिज निर्दिष्ट करते हैं पोस्ट पैरामीटर के साथ यूआरएल और अर्थ cms.example.com



वेबब्रिज में ही, हम आवश्यक मापदंडों को इंगित करते हैं: अतिथि पहुंच, संरक्षित पहुंच, आदि।

ब्रिज ग्रुप को कॉल करें

डिफ़ॉल्ट रूप से, सीएमएस हमेशा अपने पास उपलब्ध कॉन्फ्रेंसिंग संसाधनों का सबसे कुशल उपयोग नहीं करता है।

उदाहरण के लिए, तीन प्रतिभागियों के साथ एक बैठक के लिए, प्रत्येक प्रतिभागी तीन अलग-अलग कॉल ब्रिज पर समाप्त हो सकता है। इन तीन प्रतिभागियों को एक-दूसरे के साथ संवाद करने के लिए, कॉल ब्रिज स्वचालित रूप से एक ही स्पेस में सभी सर्वर और क्लाइंट के बीच कनेक्शन स्थापित करेगा, ताकि ऐसा लगे कि सभी क्लाइंट एक ही सर्वर पर हैं। दुर्भाग्य से, इसका नकारात्मक पक्ष यह है कि एक 3-व्यक्ति सम्मेलन में अब 9 मीडिया पोर्ट की खपत होगी। यह स्पष्टतः संसाधनों का अकुशल उपयोग है। इसके अतिरिक्त, जब कोई कॉल ब्रिज वास्तव में अतिभारित होता है, तो डिफ़ॉल्ट तंत्र कॉल स्वीकार करना जारी रखता है और उस कॉल ब्रिज के सभी ग्राहकों को कम गुणवत्ता वाली सेवा प्रदान करता है।

कॉल ब्रिज ग्रुप सुविधा का उपयोग करके इन समस्याओं का समाधान किया जाता है। यह सुविधा सिस्को मीटिंग सर्वर सॉफ़्टवेयर के संस्करण 2.1 में पेश की गई थी और इसे वेबआरटीसी प्रतिभागियों सहित इनबाउंड और आउटबाउंड सिस्को मीटिंग ऐप (सीएमए) कॉल दोनों के लिए लोड संतुलन का समर्थन करने के लिए बढ़ाया गया है।

पुनः कनेक्शन समस्या को हल करने के लिए, प्रत्येक कॉल ब्रिज के लिए तीन विन्यास योग्य लोड सीमाएँ पेश की गई हैं:

लोडलिमिट — यह किसी विशेष कॉल ब्रिज के लिए अधिकतम संख्यात्मक भार है। प्रत्येक प्लेटफ़ॉर्म की एक अनुशंसित लोड सीमा होती है, जैसे CMS96000 के लिए 1000 और वर्चुअल मशीन के लिए 1.25 GHz प्रति vCPU। विभिन्न कॉल प्रतिभागी के रिज़ॉल्यूशन और फ़्रेम दर के आधार पर एक निश्चित मात्रा में संसाधनों का उपभोग करते हैं।
NewConferenceLoadLimitBasisPoints (डिफ़ॉल्ट 50% लोडलिमिट) - सर्वर लोड सीमा निर्धारित करता है, जिसके बाद नए सम्मेलन अस्वीकार कर दिए जाते हैं।
मौजूदाConferenceLoadLimitBasisPoints (डिफ़ॉल्ट 80% लोडलिमिट) - सर्वर लोड मान जिसके बाद मौजूदा कॉन्फ्रेंस में शामिल होने वाले प्रतिभागियों को अस्वीकार कर दिया जाएगा।

जबकि यह सुविधा कॉल वितरण और लोड संतुलन के लिए डिज़ाइन की गई थी, अन्य समूहों जैसे TURN सर्वर, वेब ब्रिज सर्वर और रिकॉर्डर को भी कॉल ब्रिज समूहों को सौंपा जा सकता है ताकि उन्हें भी इष्टतम उपयोग के लिए उचित रूप से समूहीकृत किया जा सके। यदि इनमें से कोई भी ऑब्जेक्ट किसी कॉल समूह को नहीं सौंपा गया है, तो उन्हें बिना किसी विशेष प्राथमिकता के सभी सर्वरों के लिए उपलब्ध माना जाता है।

ये पैरामीटर यहां कॉन्फ़िगर किए गए हैं: cms.example.com:445/एपीआई/वी1/सिस्टम/कॉन्फ़िगरेशन/क्लस्टर

इसके बाद, हम प्रत्येक कॉलब्रिज को इंगित करते हैं कि वह किस कॉलब्रिज समूह से संबंधित है:

पहला कॉलब्रिज

दूसरा कॉलब्रिज

तीसरा कॉलब्रिज


इस प्रकार, हमने सिस्को मीटिंग सर्वर क्लस्टर के संसाधनों का अधिक कुशलता से उपयोग करने के लिए कॉल ब्रिडिज समूह को कॉन्फ़िगर किया।

सक्रिय निर्देशिका से उपयोगकर्ताओं को आयात करना

वेब एडमिन सेवा में एक एलडीएपी कॉन्फ़िगरेशन अनुभाग है, लेकिन यह जटिल कॉन्फ़िगरेशन विकल्प प्रदान नहीं करता है, और जानकारी क्लस्टर डेटाबेस में संग्रहीत नहीं होती है, इसलिए कॉन्फ़िगरेशन करना होगा, या तो वेब इंटरफ़ेस के माध्यम से प्रत्येक सर्वर पर मैन्युअल रूप से, या इसके माध्यम से एपीआई, और इसलिए कि हम "तीन बार" उठें नहीं "हम अभी भी एपीआई के माध्यम से डेटा सेट करेंगे।

एक्सेस करने के लिए यूआरएल का उपयोग करना cms01.example.com:445/api/v1/ldapServers एक LDAP सर्वर ऑब्जेक्ट बनाते हैं, जैसे पैरामीटर निर्दिष्ट करते हैं:

• सर्वर आईपी
• पोर्ट संख्या
• उपयोगकर्ता नाम
• пароль
• सुरक्षित

सुरक्षित - पोर्ट के आधार पर सही या गलत का चयन करें, 389 - सुरक्षित नहीं, 636 - संरक्षित।


सिस्को मीटिंग सर्वर में विशेषताओं के लिए एलडीएपी स्रोत पैरामीटर को मैप करना।
एलडीएपी मैपिंग एलडीएपी निर्देशिका में मौजूद विशेषताओं को सीएमएस में मौजूद विशेषताओं से मैप करती है। वास्तविक गुण:

• jidमैपिंग
• नाम मानचित्रण
• सहस्पेसनाममैपिंग
• सहस्पेसयूरीमैपिंग
• सहस्पेससेकेंडरीयूरीमैपिंग

गुणों का वर्णनआईएडीबी सीएमएस में उपयोगकर्ता की लॉगिन आईडी का प्रतिनिधित्व करता है। चूँकि यह एक Microsoft सक्रिय निर्देशिका LDAP सर्वर है, CMS JID LDAP में sAMAccountName पर मैप करता है, जो अनिवार्य रूप से उपयोगकर्ता की सक्रिय निर्देशिका लॉगिन आईडी है। यह भी ध्यान दें कि आप sAMAccountName लें और उसके अंत में डोमेन conf.pod6.cms.lab जोड़ें क्योंकि यह वह लॉगिन है जिसका उपयोग आपके उपयोगकर्ता CMS में लॉग इन करने के लिए करेंगे।

नाम मानचित्रण सक्रिय निर्देशिका डिस्प्लेनाम फ़ील्ड में मौजूद सामग्री को उपयोगकर्ता के सीएमएस नाम फ़ील्ड से मेल खाता है।

सहस्पेसनाममैपिंग डिस्प्लेनेम फ़ील्ड के आधार पर एक सीएमएस स्पेस नाम बनाता है। यह विशेषता, coSpaceUriMapping विशेषता के साथ, प्रत्येक उपयोगकर्ता के लिए एक स्थान बनाने के लिए आवश्यक है।

सहस्पेसयूरीमैपिंग उपयोगकर्ता के व्यक्तिगत स्थान से जुड़े यूआरआई के उपयोगकर्ता भाग को परिभाषित करता है। कुछ डोमेन को स्पेस में डायल करने के लिए कॉन्फ़िगर किया जा सकता है। यदि उपयोगकर्ता भाग इनमें से किसी एक डोमेन के लिए इस फ़ील्ड से मेल खाता है, तो कॉल उस उपयोगकर्ता के स्थान पर निर्देशित की जाएगी।

सहस्पेससेकेंडरीयूरीमैपिंग अंतरिक्ष तक पहुंचने के लिए दूसरे यूआरआई को परिभाषित करता है। इसका उपयोग कोस्पेसयूरीमैपिंग पैरामीटर में परिभाषित अल्फ़ान्यूमेरिक यूआरआई के विकल्प के रूप में आयातित उपयोगकर्ता के स्थान पर कॉल रूट करने के लिए एक संख्यात्मक उपनाम जोड़ने के लिए किया जा सकता है।

एलडीएपी सर्वर और एलडीएपी मैपिंग कॉन्फ़िगर की गई है। अब आपको एलडीएपी स्रोत बनाकर उन्हें एक साथ जोड़ने की जरूरत है।

एक्सेस करने के लिए यूआरएल का उपयोग करना cms01.example.com:445/api/v1/ldapSource एक एलडीएपी स्रोत ऑब्जेक्ट बनाएं, जैसे पैरामीटर निर्दिष्ट करें:

• सर्वर
• मानचित्रण
• आधारDn
• फ़िल्टर

अब जब एलडीएपी कॉन्फ़िगरेशन पूरा हो गया है, तो आप मैन्युअल सिंक्रनाइज़ेशन ऑपरेशन कर सकते हैं।

हम इसे प्रत्येक सर्वर के वेब इंटरफ़ेस में क्लिक करके करते हैं अभी सिंक करें अनुभाग सक्रिय निर्देशिका


या कमांड के साथ एपीआई के माध्यम से पोस्ट एक्सेस करने के लिए यूआरएल का उपयोग करना cms01.example.com:445/api/v1/ldapSyncs

तदर्थ सम्मेलन

यह क्या है?पारंपरिक अवधारणा में, एक सम्मेलन तब होता है जब दो प्रतिभागी एक-दूसरे से बात कर रहे होते हैं, और प्रतिभागियों में से एक (यूनिफाइड सीएम के साथ पंजीकृत डिवाइस का उपयोग करके) "सम्मेलन" बटन दबाता है, दूसरे व्यक्ति को कॉल करता है, और उस तीसरे पक्ष से बात करने के बाद , त्रिपक्षीय सम्मेलन में सभी प्रतिभागियों से जुड़ने के लिए "सम्मेलन" बटन को फिर से दबाएँ।

एक तदर्थ सम्मेलन को सीएमएस में एक निर्धारित सम्मेलन से अलग करने वाली बात यह है कि एक तदर्थ सम्मेलन सीएमएस के लिए सिर्फ एक एसआईपी कॉल नहीं है। जब कॉन्फ़्रेंस आरंभकर्ता सभी को एक ही मीटिंग में आमंत्रित करने के लिए कॉन्फ़्रेंस बटन पर दूसरी बार क्लिक करता है, तो यूनिफ़ाइड सीएम को ऑन-द-फ़्लाई कॉन्फ़्रेंस बनाने के लिए सीएमएस को एक एपीआई कॉल करना होगा, जिसमें सभी कॉल स्थानांतरित हो जाती हैं। यह सब प्रतिभागियों द्वारा ध्यान दिए बिना होता है।

इसका मतलब यह है कि यूनिफाइड सीएम को कॉल जारी रखने के लिए एपीआई क्रेडेंशियल्स और सेवा के वेबएडमिन एड्रेस/पोर्ट के साथ-साथ एसआईपी ट्रंक को सीधे सीएमएस सर्वर पर कॉन्फ़िगर करना होगा।

यदि आवश्यक हो, तो सीयूसीएम गतिशील रूप से सीएमएस में एक स्थान बना सकता है ताकि प्रत्येक कॉल सीएमएस तक पहुंच सके और रिक्त स्थान के लिए आने वाले इनकमिंग कॉल नियम से मेल खा सके।

सीयूसीएम के साथ एकीकरण लेख में वर्णित अनुसार ही कॉन्फ़िगर किया गया है पूर्व सिवाय इसके कि सिस्को यूसीएम पर आपको सीएमएस के लिए तीन ट्रंक, तीन कॉन्फ़्रेंस ब्रिज बनाने की आवश्यकता है, एसआईपी सुरक्षा प्रोफ़ाइल में तीन विषय नाम, रूट समूह, रूट सूचियां, मीडिया रिसोर्स समूह और मीडिया रिसोर्स समूह सूचियां निर्दिष्ट करें, और कुछ रूटिंग नियम जोड़ें सिस्को मीटिंग सर्वर के लिए.

एसआईपी सुरक्षा प्रोफ़ाइल:


चड्डी:


प्रत्येक ट्रंक एक जैसा दिखता है:




सम्मेलन पुल


प्रत्येक कॉन्फ़्रेंस ब्रिज एक जैसा दिखता है:


मार्ग समूह


मार्ग सूची


मीडिया संसाधन समूह


मीडिया संसाधन समूह सूची

कॉल नियम

यूनिफाइड सीएम या एक्सप्रेसवे जैसे अधिक उन्नत कॉल प्रबंधन प्रणालियों के विपरीत, सीएमएस केवल नई कॉल के लिए एसआईपी अनुरोध-यूआरआई फ़ील्ड में डोमेन को देखता है। तो यदि SIP आमंत्रण घूंट के लिए है: [ईमेल संरक्षित]सीएमएस को केवल Domain.com की परवाह है। किसी कॉल को कहां रूट करना है यह निर्धारित करने के लिए सीएमएस इन नियमों का पालन करता है:

1. सीएमएस सबसे पहले एसआईपी डोमेन को इनकमिंग कॉल नियमों में कॉन्फ़िगर किए गए डोमेन से मिलाने का प्रयास करता है। फिर इन कॉलों को ("लक्षित") स्थानों या विशिष्ट उपयोगकर्ताओं, आंतरिक आईवीआर, या सीधे एकीकृत माइक्रोसॉफ्ट लिंक/स्काइप फॉर बिजनेस (एस4बी) गंतव्यों पर रूट किया जा सकता है।
2. यदि इनकमिंग कॉल नियमों में कोई मिलान नहीं है, तो सीएमएस कॉल फ़ॉरवर्डिंग तालिका में कॉन्फ़िगर किए गए डोमेन से मिलान करने का प्रयास करेगा। यदि कोई मेल बनता है, तो नियम स्पष्ट रूप से कॉल को अस्वीकार कर सकता है या कॉल को अग्रेषित कर सकता है। इस समय, सीएमएस डोमेन को फिर से लिख सकता है, जो कभी-कभी लिंक डोमेन को कॉल करने के लिए उपयोगी होता है। आप पास थ्रो का चयन भी कर सकते हैं, जिसका अर्थ है कि किसी भी फ़ील्ड को आगे संशोधित नहीं किया जाएगा, या आंतरिक सीएमएस डायल योजना का उपयोग करें। यदि कॉल फ़ॉरवर्डिंग नियमों में कोई मेल नहीं है, तो कॉल को अस्वीकार करना डिफ़ॉल्ट है। ध्यान रखें कि सीएमएस में, हालांकि कॉल "फॉरवर्डेड" है, मीडिया अभी भी सीएमएस से बंधा हुआ है, जिसका अर्थ है कि यह सिग्नलिंग और मीडिया ट्रैफ़िक पथ में होगा।
तब केवल अग्रेषित कॉल ही आउटगोइंग कॉल नियमों के अधीन होंगी। ये सेटिंग्स उन गंतव्यों को निर्धारित करती हैं जहां कॉल भेजी जाती हैं, ट्रंक प्रकार (चाहे यह एक नया लिंक कॉल या एक मानक एसआईपी कॉल हो), और कोई भी रूपांतरण जो कॉल फ़ॉरवर्डिंग नियम में स्थानांतरण का चयन नहीं होने पर किया जा सकता है।

एड-हॉक सम्मेलन के दौरान क्या होता है इसका वास्तविक लॉग यहां दिया गया है

स्क्रीनशॉट इसे खराब तरीके से दिखाता है (मुझे नहीं पता कि इसे बेहतर कैसे बनाया जाए), इसलिए मैं लॉग को इस तरह लिखूंगा:

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

तदर्थ सम्मेलन स्वयं:


इनकमिंग कॉल नियम
सीएमएस में कॉल प्राप्त करने में सक्षम होने के लिए इनकमिंग कॉल के मापदंडों को कॉन्फ़िगर करना आवश्यक है। जैसा कि आपने एलडीएपी सेटअप में देखा, सभी उपयोगकर्ताओं को conf.pod6.cms.lab डोमेन के साथ आयात किया गया था। तो कम से कम, आप रिक्त स्थान को लक्षित करने के लिए इस डोमेन पर कॉल करना चाहते हैं। आपको प्रत्येक सीएमएस सर्वर के पूर्णतः योग्य डोमेन नाम (और शायद आईपी पते) के लिए इच्छित सभी चीज़ों के लिए नियम स्थापित करने की भी आवश्यकता होगी। हमारा बाहरी कॉल नियंत्रण, यूनिफाइड सीएम, प्रत्येक सीएमएस सर्वर को व्यक्तिगत रूप से समर्पित एसआईपी ट्रंक को कॉन्फ़िगर करेगा। इस पर निर्भर करते हुए कि इन एसआईपी ट्रंक का गंतव्य एक आईपी पता है या सर्वर का एफक्यूडीएन यह निर्धारित करेगा कि सीएमएस को अपने आईपी पते या एफक्यूडीएन पर निर्देशित कॉल स्वीकार करने के लिए कॉन्फ़िगर करने की आवश्यकता है या नहीं।

जिस डोमेन में सर्वोच्च प्राथमिकता वाला इनबाउंड नियम होता है, उसे किसी भी उपयोगकर्ता स्थान के लिए डोमेन के रूप में उपयोग किया जाता है। जब उपयोगकर्ता एलडीएपी के माध्यम से सिंक करते हैं, तो सीएमएस स्वचालित रूप से रिक्त स्थान बनाता है, लेकिन केवल यूआरआई (कोस्पेसयूरीमैपिंग) का उपयोगकर्ता भाग, उदाहरण के लिए, उपयोगकर्ता.स्पेस। भाग डोमेन इस नियम के आधार पर पूर्ण यूआरआई उत्पन्न होता है। वास्तव में, यदि आप इस बिंदु पर वेब ब्रिज में लॉग इन करते हैं, तो आप देखेंगे कि स्पेस यूआरआई के पास कोई डोमेन नहीं है। इस नियम को सर्वोच्च प्राथमिकता के रूप में सेट करके, आप जेनरेट किए गए रिक्त स्थान के लिए डोमेन सेट कर रहे हैं कॉन्फ़.example.com.


आउटगोइंग कॉल नियम

उपयोगकर्ताओं को यूनिफाइड सीएम क्लस्टर में आउटबाउंड कॉल करने की अनुमति देने के लिए, आपको आउटबाउंड नियमों को कॉन्फ़िगर करना होगा। यूनिफाइड सीएम के साथ पंजीकृत एंडपॉइंट का डोमेन, जैसे जैबर, example.com है। इस डोमेन पर कॉल को मानक एसआईपी कॉल के रूप में यूनिफाइड सीएम कॉल प्रोसेसिंग नोड्स पर रूट किया जाना चाहिए। मुख्य सर्वर cucm-01.example.com है, और अतिरिक्त सर्वर cucm-02.example.com है।

पहला नियम क्लस्टर सर्वर के बीच कॉल की सबसे सरल रूटिंग का वर्णन करता है।

क्षेत्र डोमेन से स्थानीय कॉल करने वाले के एसआईपी-यूआरआई में "@" चिन्ह के बाद कॉल किए जाने वाले व्यक्ति के लिए क्या प्रदर्शित होगा, इसके लिए जिम्मेदार है। यदि हम इसे खाली छोड़ देते हैं, तो "@" चिन्ह के बाद CUCM का IP पता होगा जिससे यह कॉल गुजरती है। यदि हम एक डोमेन निर्दिष्ट करते हैं, तो "@" चिन्ह के बाद वास्तव में एक डोमेन होगा। वापस कॉल करने में सक्षम होने के लिए यह आवश्यक है, अन्यथा SIP-URI name@ip-address के माध्यम से वापस कॉल करना संभव नहीं होगा।

निर्दिष्ट होने पर कॉल करें डोमेन से स्थानीय


कब कॉल करें नहीं संकेत डोमेन से स्थानीय


आउटगोइंग कॉल के लिए एन्क्रिप्टेड या अनएन्क्रिप्टेड को स्पष्ट रूप से निर्दिष्ट करना सुनिश्चित करें, क्योंकि ऑटो पैरामीटर के साथ कुछ भी काम नहीं करता है।

रिकॉर्डिंग

वीडियो कॉन्फ्रेंस रिकॉर्ड सर्वर द्वारा रिकॉर्ड की जाती हैं। रिकॉर्डर बिल्कुल सिस्को मीटिंग सर्वर जैसा ही है। रिकॉर्डर को किसी भी लाइसेंस की स्थापना की आवश्यकता नहीं है। कॉलब्रिज सेवाएं चलाने वाले सर्वरों के लिए रिकॉर्डिंग लाइसेंस आवश्यक हैं। एक रिकॉर्डिंग लाइसेंस आवश्यक है और इसे कॉलब्रिज घटक पर लागू किया जाना चाहिए, न कि रिकॉर्डर चलाने वाले सर्वर पर। रिकॉर्डर एक एक्स्टेंसिबल मैसेजिंग और प्रेजेंस प्रोटोकॉल (एक्सएमपीपी) क्लाइंट के रूप में व्यवहार करता है, इसलिए कॉलब्रिज होस्ट करने वाले सर्वर पर एक्सएमपीपी सर्वर सक्षम होना चाहिए।

क्योंकि हमारे पास एक क्लस्टर है और लाइसेंस को क्लस्टर के सभी तीन सर्वरों में "विस्तारित" करने की आवश्यकता है। फिर बस आपके व्यक्तिगत खाते में लाइसेंस में हम क्लस्टर में शामिल सभी सीएमएस सर्वरों के ए-इंटरफ़ेस के मैक पते को जोड़ते हैं (जोड़ते हैं)।

और यह वह चित्र है जो क्लस्टर के प्रत्येक सर्वर पर होना चाहिए

सामान्य तौर पर, रिकॉर्डर रखने के लिए कई परिदृश्य हैं, लेकिन हम इस पर कायम रहेंगे:


रिकॉर्डर स्थापित करने से पहले, आपको एक जगह तैयार करनी होगी जहां वीडियो कॉन्फ्रेंस वास्तव में रिकॉर्ड की जाएंगी। दरअसल यहाँ लिंक, सभी रिकॉर्डिंग कैसे सेट करें। मैं महत्वपूर्ण बिंदुओं और विवरणों पर ध्यान केंद्रित करता हूं:

1. प्रमाणपत्र को क्लस्टर के पहले सर्वर से खिसकाना बेहतर है।
2. "रिकॉर्डर अनुपलब्ध" त्रुटि इसलिए हो सकती है क्योंकि रिकॉर्डर ट्रस्ट में गलत प्रमाणपत्र निर्दिष्ट है।
3. यदि रिकॉर्डिंग के लिए निर्दिष्ट एनएफएस निर्देशिका रूट निर्देशिका नहीं है तो लिखना काम नहीं कर सकता है।

कभी-कभी किसी विशिष्ट उपयोगकर्ता या स्थान के सम्मेलन को स्वचालित रूप से रिकॉर्ड करने की आवश्यकता होती है।

इसके लिए, दो कॉलप्रोफ़ाइलें बनाई गई हैं:
रिकॉर्डिंग अक्षम होने पर


और स्वचालित रिकॉर्डिंग फ़ंक्शन के साथ


इसके बाद, हम आवश्यक स्थान पर एक स्वचालित रिकॉर्डिंग फ़ंक्शन के साथ एक कॉलप्रोफ़ाइल को "संलग्न" करते हैं।


सीएमएस में यह इस प्रकार स्थापित है कि यदि कोई कॉलप्रोफाइल स्पष्ट रूप से किसी स्थान या स्थान से बंधा हुआ है, तो यह कॉलप्रोफाइल केवल इन विशिष्ट स्थानों के संबंध में ही काम करता है। और यदि कॉलप्रोफाइल किसी स्थान से बंधा नहीं है, तो डिफ़ॉल्ट रूप से यह उन स्थानों पर लागू होता है, जहां कोई भी कॉलप्रोफाइल स्पष्ट रूप से बाध्य नहीं है।

अगली बार मैं यह बताने का प्रयास करूंगा कि संगठन के आंतरिक नेटवर्क के बाहर सीएमएस तक कैसे पहुंचा जाता है।

सूत्रों का कहना है:

• www.cisco.com/c/dam/en/us/td/docs/conference/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conference/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conference/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conference/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later। पीडीएफ

स्रोत: www.habr.com