Cisco Meeting Server 2.5.2. ចង្កោមនៅក្នុងរបៀបដែលអាចធ្វើមាត្រដ្ឋានបាន និងធន់ជាមួយនឹងមុខងារថតវីដេអូសន្និសីទ

នៅក្នុងបញ្ហានេះ ខ្ញុំនឹងបង្ហាញ និងពន្យល់ពីភាពស្មុគ្រស្មាញមួយចំនួននៃការដំឡើងម៉ាស៊ីនមេ CMS នៅក្នុងរបៀបចង្កោមបរាជ័យ។


ទ្រឹស្តីជាទូទៅ ការដាក់ពង្រាយម៉ាស៊ីនមេ CMS មានបីប្រភេទ៖

• រួមបញ្ចូលគ្នាតែមួយ(រួមបញ្ចូលគ្នាតែមួយ), i.e. នេះគឺជាម៉ាស៊ីនមេមួយ ដែលសេវាកម្មចាំបាច់ទាំងអស់កំពុងដំណើរការ។ ក្នុងករណីភាគច្រើន ប្រភេទនៃការដាក់ពង្រាយនេះគឺសមរម្យសម្រាប់តែការចូលប្រើម៉ាស៊ីនភ្ញៀវខាងក្នុង និងក្នុងបរិស្ថានតូចជាង ដែលការកំណត់ទំហំ និងការប្រើប្រាស់ឡើងវិញនៃម៉ាស៊ីនមេតែមួយមិនមែនជាបញ្ហាសំខាន់ ឬក្នុងស្ថានភាពដែល CMS ដំណើរការតែមុខងារមួយចំនួនដូចជា ad hoc ជាដើម។ សន្និសីទ Cisco UCM ។

  គ្រោងការណ៍ប្រហាក់ប្រហែលនៃការងារ៖
  

• ការបែងចែកតែមួយ(Single Split) ពង្រីកប្រភេទការដាក់ពង្រាយពីមុនដោយបន្ថែមម៉ាស៊ីនមេដាច់ដោយឡែកសម្រាប់ការចូលប្រើខាងក្រៅ។ នៅក្នុងការដាក់ពង្រាយកេរ្តិ៍ដំណែល នេះមានន័យថាការដាក់ពង្រាយម៉ាស៊ីនមេ CMS នៅក្នុងផ្នែកបណ្តាញគ្មានយោធា (DMZ) ដែលអតិថិជនខាងក្រៅអាចចូលប្រើវាបាន និងម៉ាស៊ីនមេ CMS មួយនៅក្នុងស្នូលបណ្តាញដែលអតិថិជនខាងក្នុងអាចចូលប្រើ CMS ។ គំរូនៃការដាក់ពង្រាយពិសេសនេះឥឡូវនេះត្រូវបានជំនួសដោយប្រភេទដែលគេហៅថា គែមតែមួយដែលរួមមានម៉ាស៊ីនមេ ស៊ីស្កូ Expresswayដែលអាចមាន ឬនឹងមានសមត្ថភាពឆ្លងកាត់ Firewall ដូចគ្នាជាច្រើន ដូច្នេះអតិថិជនមិនចាំបាច់បន្ថែមម៉ាស៊ីនមេ CMS គែមជាក់លាក់ទេ។

  គ្រោងការណ៍ប្រហាក់ប្រហែលនៃការងារ៖
  

• អាចធ្វើមាត្រដ្ឋានបាន និងធន់(អាចធ្វើមាត្រដ្ឋានបាន និងអត់អោនភាព) ប្រភេទនេះរួមបញ្ចូលទាំងការលែងត្រូវការតទៅទៀតសម្រាប់សមាសធាតុនីមួយៗ ដែលអនុញ្ញាតឱ្យប្រព័ន្ធរីកចម្រើនជាមួយនឹងតម្រូវការរបស់អ្នកដល់សមត្ថភាពអតិបរមារបស់វា ខណៈពេលដែលផ្តល់នូវភាពមិនដូចគ្នាក្នុងករណីបរាជ័យ។ វាក៏ប្រើគំនិត Single Edge ដើម្បីផ្តល់នូវការចូលប្រើខាងក្រៅប្រកបដោយសុវត្ថិភាព។ នេះជាប្រភេទដែលយើងនឹងមើលក្នុងវគ្គនេះ។ ប្រសិនបើយើងយល់ពីរបៀបដាក់ពង្រាយប្រភេទ cluster នេះ យើងនឹងមិនត្រឹមតែយល់អំពីប្រភេទនៃការដាក់ឱ្យប្រើប្រាស់ផ្សេងទៀតប៉ុណ្ណោះទេ ប៉ុន្តែយើងក៏នឹងអាចយល់ពីរបៀបបង្កើត clusters នៃ CMS servers ដើម្បីសម្រួលដល់កំណើនសក្តានុពលនៃតម្រូវការផងដែរ។

មុន​នឹង​បន្ត​ការ​ដាក់​ពង្រាយ អ្នក​ត្រូវ​យល់​ពី​ចំណុច​មូលដ្ឋាន​មួយ​ចំនួន ពោល​គឺ

សមាសធាតុកម្មវិធី CMS សំខាន់ៗ៖

• មូលដ្ឋានទិន្នន័យ៖ អនុញ្ញាតឱ្យអ្នកបញ្ចូលគ្នានូវការកំណត់រចនាសម្ព័ន្ធមួយចំនួន ដូចជាគម្រោងការហៅទូរសព្ទ ចន្លោះអ្នកប្រើប្រាស់ និងអ្នកប្រើប្រាស់ខ្លួនឯង។ គាំទ្រ​ការ​ដាក់​ចង្កោម​សម្រាប់​ភាព​អាច​រក​បាន​ខ្ពស់ (មេ​តែ​មួយ)។
• ហៅស្ពាន៖ សេវាកម្មសម្រាប់ការប្រជុំជាអូឌីយ៉ូ និងវីដេអូដែលផ្តល់ការគ្រប់គ្រងពេញលេញលើការគ្រប់គ្រង និងដំណើរការការហៅទូរសព្ទ និងដំណើរការពហុព័ត៌មាន។ គាំទ្រការដាក់ចង្កោមសម្រាប់ភាពអាចរកបាន និងលទ្ធភាពធ្វើមាត្រដ្ឋានខ្ពស់។
• ម៉ាស៊ីនមេ XMPP៖ ទទួលខុសត្រូវចំពោះការចុះឈ្មោះ និងការផ្ទៀងផ្ទាត់អតិថិជនដោយប្រើកម្មវិធី Cisco Meeting និង/ឬ WebRTC(ការប្រាស្រ័យទាក់ទងតាមពេលវេលាជាក់ស្តែង ឬគ្រាន់តែនៅក្នុងកម្មវិធីរុករកតាមអ៊ីនធឺណិត)ក៏ដូចជាការបញ្ជូនសញ្ញាអន្តរសមាសធាតុ។ អាចត្រូវបានចង្កោមសម្រាប់តែភាពអាចរកបានខ្ពស់។
• ស្ពានបណ្តាញ៖ ផ្តល់ការចូលប្រើរបស់អតិថិជនទៅកាន់ WebRTC ។
• Loadbalancer៖ ផ្តល់ចំណុចតភ្ជាប់តែមួយសម្រាប់កម្មវិធី Cisco Meeting នៅក្នុងរបៀបបំបែកតែមួយ។ ស្តាប់ចំណុចប្រទាក់ខាងក្រៅ និងច្រកសម្រាប់ការតភ្ជាប់ចូល។ ស្មើភាពគ្នា តុល្យការផ្ទុកទទួលយកការតភ្ជាប់ TLS ចូលពីម៉ាស៊ីនមេ XMPP ដែលតាមរយៈនោះវាអាចប្តូរការតភ្ជាប់ TCP ពីម៉ាស៊ីនភ្ញៀវខាងក្រៅ។
  នៅក្នុងសេណារីយ៉ូរបស់យើងវានឹងមិនត្រូវការទេ។
• បើកម៉ាស៊ីនមេ៖ ផ្តល់បច្ចេកវិទ្យាផ្លូវកាត់ Firewall ដែលអនុញ្ញាត
  ដាក់ ​​CMS របស់យើងនៅពីក្រោយ Firewall ឬ NAT ដើម្បីភ្ជាប់អតិថិជនខាងក្រៅដោយប្រើ Cisco Meeting App ឬឧបករណ៍ SIP ។ នៅក្នុងសេណារីយ៉ូរបស់យើងវានឹងមិនត្រូវការទេ។
• អ្នកគ្រប់គ្រងគេហទំព័រ៖ ចំណុចប្រទាក់រដ្ឋបាល និងការចូលប្រើ API រួមទាំងសម្រាប់សន្និសីទ CM បង្រួបបង្រួមពិសេស។

របៀបកំណត់រចនាសម្ព័ន្ធ

មិនដូចផលិតផល Cisco ផ្សេងទៀតទេ Cisco Meeting Server គាំទ្រវិធីសាស្ត្រកំណត់រចនាសម្ព័ន្ធបី ដើម្បីសម្រួលដល់ប្រភេទនៃការដាក់ពង្រាយណាមួយ។

• បន្ទាត់ពាក្យបញ្ជា (CLI)៖ ចំណុចប្រទាក់បន្ទាត់ពាក្យបញ្ជាដែលគេស្គាល់ថាជា MMP សម្រាប់ការកំណត់រចនាសម្ព័ន្ធដំបូង និងកិច្ចការវិញ្ញាបនបត្រ។
• អ្នកគ្រប់គ្រងគេហទំព័រ៖ ជាចម្បងសម្រាប់ការកំណត់រចនាសម្ព័ន្ធដែលទាក់ទងនឹង CallBridge ជាពិសេសនៅពេលដំឡើងម៉ាស៊ីនមេដែលមិនមែនជាចង្កោមតែមួយ។
• REST API៖ ប្រើ​សម្រាប់​កិច្ចការ​កំណត់​រចនាសម្ព័ន្ធ​ស្មុគស្មាញ​បំផុត និង​កិច្ចការ​ដែល​ទាក់ទង​នឹង​មូលដ្ឋាន​ទិន្នន័យ​ជា​ក្រុម។

បន្ថែមពីលើខាងលើពិធីការត្រូវបានប្រើ SFTP ដើម្បីផ្ទេរឯកសារ—ជាធម្មតាអាជ្ញាប័ណ្ណ វិញ្ញាបនបត្រ ឬកំណត់ហេតុ—ទៅ និងពីម៉ាស៊ីនមេ CMS ។

នៅក្នុងការណែនាំអំពីការដាក់ពង្រាយពី Cisco វាត្រូវបានសរសេរជាពណ៌ស និងជាភាសាអង់គ្លេស ដែលចង្កោមត្រូវដាក់ពង្រាយ យ៉ាងហោចណាស់បី ម៉ាស៊ីនមេ (ថ្នាំង) នៅក្នុងបរិបទនៃមូលដ្ឋានទិន្នន័យ។ ដោយសារតែ មានតែជាមួយនឹងចំនួនសេសនៃថ្នាំងប៉ុណ្ណោះដែលយន្តការសម្រាប់ជ្រើសរើសការងារ Masterbase Master ថ្មី ហើយជាទូទៅ Database Master មានការតភ្ជាប់ជាមួយមូលដ្ឋានទិន្នន័យ CMS server ភាគច្រើន។

ហើយដូចការអនុវត្តបង្ហាញ ម៉ាស៊ីនមេពីរ (ថ្នាំង) ពិតជាមិនគ្រប់គ្រាន់ទេ។ យន្តការជ្រើសរើសដំណើរការនៅពេលដែល Master ត្រូវបានចាប់ផ្តើមឡើងវិញ Slave server ក្លាយជា Master លុះត្រាតែម៉ាស៊ីនមេដែលចាប់ផ្ដើមឡើងវិញត្រូវបានបង្កើតឡើង។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើនៅក្នុងចង្កោមនៃ servers ពីរដែល Master server រលត់ភ្លាមៗនោះ Slave server នឹងមិនក្លាយជា Master ហើយប្រសិនបើ Slave រលត់ នោះ Master server ដែលនៅសល់នឹងក្លាយជា Slave។

ប៉ុន្តែនៅក្នុងបរិបទនៃ XMPP វាពិតជាចាំបាច់ក្នុងការប្រមូលផ្តុំចង្កោមនៃម៉ាស៊ីនមេចំនួនបី ពីព្រោះ ឧទាហរណ៍ ប្រសិនបើអ្នកបិទសេវាកម្ម XMPP នៅលើម៉ាស៊ីនមេណាមួយដែល XMMP ស្ថិតក្នុងស្ថានភាព Leader បន្ទាប់មកនៅលើ Server ដែលនៅសល់ XMPP នឹងនៅតែស្ថិតក្នុងស្ថានភាព Follower ហើយការភ្ជាប់ CallBridge ទៅ XMPP នឹងរលត់ ពីព្រោះ CallBridge ភ្ជាប់ផ្តាច់មុខទៅ XMPP ជាមួយនឹងស្ថានភាព Leader ។ ហើយនេះគឺជាការរិះគន់ព្រោះ ... ការហៅតែមួយនឹងមិនឆ្លងកាត់ទេ។

ផងដែរនៅក្នុងការដាក់ពង្រាយដូចគ្នាណែនាំចង្កោមជាមួយម៉ាស៊ីនមេ XMPP មួយត្រូវបានបង្ហាញ។

ហើយដោយគិតគូរពីចំណុចខាងលើ វាច្បាស់ណាស់ថាហេតុអ្វី៖ វាដំណើរការព្រោះវាស្ថិតក្នុងរបៀបបរាជ័យ។

ក្នុងករណីរបស់យើង ម៉ាស៊ីនមេ XMPP នឹងមានវត្តមាននៅលើថ្នាំងទាំងបី។

វាត្រូវបានសន្មត់ថាម៉ាស៊ីនមេរបស់យើងទាំងបីគឺឡើង។

កំណត់ត្រា DNS

មុនពេលអ្នកចាប់ផ្តើមដំឡើងម៉ាស៊ីនមេ អ្នកត្រូវបង្កើតកំណត់ត្រា DNS А и អេសអេសអេស ប្រភេទ៖

សូមចំណាំថានៅក្នុងកំណត់ត្រា DNS របស់យើងមានដែនពីរ example.com និង conf.example.com ។ Example.com គឺជាដែនដែលអតិថិជន Cisco Unified Communication Manager ទាំងអស់អាចប្រើប្រាស់សម្រាប់ URI របស់ពួកគេ ដែលទំនងជាមានវត្តមាននៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នក ឬទំនងជាមានវត្តមាន។ ឬ example.com ត្រូវគ្នានឹងដែនដូចគ្នាដែលអ្នកប្រើប្រាស់ប្រើសម្រាប់អាសយដ្ឋានអ៊ីមែលរបស់ពួកគេ។ ឬម៉ាស៊ីនភ្ញៀវ Jabber នៅលើកុំព្យូទ័រយួរដៃរបស់អ្នកអាចមាន URI [អ៊ីមែលការពារ]. ដែន conf.example.com គឺជាដែនដែលនឹងត្រូវកំណត់រចនាសម្ព័ន្ធសម្រាប់អ្នកប្រើប្រាស់ Cisco Meeting Server។ ដែនរបស់ Cisco Meeting Server នឹងមាន conf.example.com ដូច្នេះសម្រាប់អ្នកប្រើប្រាស់ Jabber ដូចគ្នា អ្នកប្រើប្រាស់@ URI នឹងត្រូវប្រើដើម្បីចូលទៅក្នុង Cisco Meeting Serverconf.example.com ។

ការកំណត់រចនាសម្ព័ន្ធមូលដ្ឋាន

ការកំណត់ទាំងអស់ដែលបានពិពណ៌នាខាងក្រោមត្រូវបានបង្ហាញនៅលើម៉ាស៊ីនមេតែមួយ ប៉ុន្តែពួកវាត្រូវធ្វើនៅលើម៉ាស៊ីនមេនីមួយៗនៅក្នុងចង្កោម។

QoS ។

ចាប់តាំងពី CMS បង្កើត ពេលវេលា​ពិតប្រាកដ ចរាចរណ៍ប្រកាន់អក្សរតូចធំចំពោះការពន្យាពេល និងការបាត់បង់កញ្ចប់ព័ត៌មាន ក្នុងករណីភាគច្រើនវាត្រូវបានណែនាំឱ្យកំណត់រចនាសម្ព័ន្ធគុណភាពនៃសេវាកម្ម (QoS)។ ដើម្បីសម្រេចបាននូវចំណុចនេះ CMS គាំទ្រកញ្ចប់ដាក់ស្លាកជាមួយនឹងលេខកូដសេវាកម្មផ្សេងគ្នា (DSCPs) ដែលវាបង្កើត។ ទោះបីជាការកំណត់អាទិភាពចរាចរណ៍ដែលមានមូលដ្ឋានលើ DSCP អាស្រ័យលើរបៀបដែលចរាចរត្រូវបានដំណើរការដោយសមាសធាតុបណ្តាញនៃហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកក៏ដោយ ក្នុងករណីរបស់យើងយើងនឹងកំណត់រចនាសម្ព័ន្ធ CMS របស់យើងជាមួយនឹងការកំណត់អាទិភាព DSCP ធម្មតាដោយផ្អែកលើការអនុវត្តល្អបំផុត 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

Network Time Protocol (NTP) មានសារៈសំខាន់មិនត្រឹមតែសម្រាប់ការផ្តល់ពេលវេលាត្រឹមត្រូវនៃការហៅទូរសព្ទ និងសន្និសីទប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងសម្រាប់ការផ្ទៀងផ្ទាត់វិញ្ញាបនបត្រផងដែរ។

បន្ថែមម៉ាស៊ីនមេ NTP ទៅហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកជាមួយនឹងពាក្យបញ្ជាដូចជា

ntp server add <server>

ក្នុងករណីរបស់យើងមានម៉ាស៊ីនមេបែបនេះពីរ ដូច្នេះនឹងមានក្រុមពីរ។
កំពុងពិនិត្យ:

ហើយកំណត់តំបន់ពេលវេលាសម្រាប់ម៉ាស៊ីនមេរបស់យើង។

ឈ្មោះ DNS

យើងបន្ថែមម៉ាស៊ីនមេ DNS ទៅ CMS ដោយប្រើពាក្យបញ្ជាដូចជា៖

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 ។ ដូច្នេះ អ្នកត្រូវបង្កើតកូនសោវិញ្ញាបនបត្រសាធារណៈ និងឯកជនមួយគូសម្រាប់ម៉ាស៊ីនមេនីមួយៗនៅក្នុងចង្កោម។

ទោះជាយ៉ាងណាក៏ដោយ ការរៀបចំក្រុមមូលដ្ឋានទិន្នន័យមានតម្រូវការវិញ្ញាបនបត្រពិសេសមួយចំនួន ហើយដូច្នេះទាមទារវិញ្ញាបនបត្រផ្ទាល់ខ្លួនរបស់វា ដែលខុសពីសេវាកម្មផ្សេងទៀត។ CMS ប្រើវិញ្ញាបនបត្រម៉ាស៊ីនមេ ដែលស្រដៀងនឹងវិញ្ញាបនបត្រដែលប្រើដោយម៉ាស៊ីនមេផ្សេងទៀត ប៉ុន្តែក៏មានវិញ្ញាបនបត្រអតិថិជនដែលប្រើសម្រាប់ការតភ្ជាប់មូលដ្ឋានទិន្នន័យផងដែរ។ វិញ្ញាបនបត្រមូលដ្ឋានទិន្នន័យត្រូវបានប្រើសម្រាប់ទាំងការផ្ទៀងផ្ទាត់ និងការអ៊ិនគ្រីប។ ជំនួសឱ្យការផ្តល់ឈ្មោះអ្នកប្រើប្រាស់ និងពាក្យសម្ងាត់សម្រាប់ម៉ាស៊ីនភ្ញៀវដើម្បីភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ វាបង្ហាញវិញ្ញាបនបត្រអតិថិជនដែលត្រូវបានជឿទុកចិត្តដោយម៉ាស៊ីនមេ។ ម៉ាស៊ីនមេនីមួយៗនៅក្នុងចង្កោមមូលដ្ឋានទិន្នន័យនឹងប្រើគូសោសាធារណៈ និងឯកជនដូចគ្នា។ នេះអនុញ្ញាតឱ្យម៉ាស៊ីនមេទាំងអស់នៅក្នុងចង្កោមអាចអ៊ិនគ្រីបទិន្នន័យតាមរបៀបដែលវាអាចត្រូវបានឌិគ្រីបដោយម៉ាស៊ីនមេផ្សេងទៀតដែលចែករំលែកគូសោដូចគ្នាផងដែរ។

ដើម្បីឱ្យដំណើរការដដែលៗ ចង្កោមមូលដ្ឋានទិន្នន័យត្រូវតែមានយ៉ាងហោចណាស់ 3 ម៉ាស៊ីនមេ ប៉ុន្តែមិនលើសពី 5 ជាមួយនឹងពេលវេលាធ្វើដំណើរទៅមកអតិបរមា 200 ms រវាងសមាជិកចង្កោមណាមួយ។ ដែនកំណត់នេះរឹតតែតឹងរ៉ឹងជាងសម្រាប់ Call Bridge clustering ដូច្នេះវាច្រើនតែជាកត្តាកំណត់ក្នុងការដាក់ពង្រាយតាមភូមិសាស្ត្រ។

តួនាទីមូលដ្ឋានទិន្នន័យសម្រាប់ CMS មានតម្រូវការពិសេសមួយចំនួន។ មិនដូចតួនាទីផ្សេងទៀតទេ វាទាមទារវិញ្ញាបនបត្រម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេ ដែលវិញ្ញាបនបត្រអតិថិជនមានវាល CN ជាក់លាក់ដែលត្រូវបានបង្ហាញដល់ម៉ាស៊ីនមេ។

CMS ប្រើមូលដ្ឋានទិន្នន័យ postgres ដែលមានមេមួយ និងចម្លងដូចគ្នាទាំងស្រុងមួយចំនួន។ មានមូលដ្ឋានទិន្នន័យចម្បងតែមួយក្នុងពេលតែមួយ (“ម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យ”)។ សមាជិកដែលនៅសល់នៃចង្កោមគឺចម្លង ឬ "អតិថិជនមូលដ្ឋានទិន្នន័យ"។

ចង្កោមមូលដ្ឋានទិន្នន័យទាមទារវិញ្ញាបនបត្រម៉ាស៊ីនមេជាក់លាក់ និងវិញ្ញាបនបត្រអតិថិជន។ ពួកគេត្រូវតែចុះហត្ថលេខាដោយវិញ្ញាបនបត្រ ជាធម្មតាអាជ្ញាធរវិញ្ញាបនបត្រឯកជនផ្ទៃក្នុង។ ដោយសារតែសមាជិកណាមួយនៃក្រុមមូលដ្ឋានទិន្នន័យអាចក្លាយជាមេនោះ ម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យ និងគូវិញ្ញាបនបត្រអតិថិជន (មានកូនសោសាធារណៈ និងឯកជន) ត្រូវតែចម្លងទៅកាន់ម៉ាស៊ីនមេទាំងអស់ ដូច្នេះពួកគេអាចសន្មតអត្តសញ្ញាណរបស់ម៉ាស៊ីនភ្ញៀវ ឬម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យ។ លើសពីនេះទៀត វិញ្ញាបនបត្រឫសគល់ CA ត្រូវតែត្រូវបានផ្ទុក ដើម្បីធានាថា វិញ្ញាបនបត្រម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេអាចត្រូវបានផ្ទៀងផ្ទាត់។

ដូច្នេះ យើងបង្កើតសំណើរសម្រាប់វិញ្ញាបនបត្រដែលនឹងត្រូវបានប្រើដោយសេវាកម្មម៉ាស៊ីនមេទាំងអស់ លើកលែងតែមូលដ្ឋានទិន្នន័យ (វានឹងមានសំណើដាច់ដោយឡែកសម្រាប់វា) ជាមួយនឹងពាក្យបញ្ជាដូចជា៖

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

នៅក្នុង CN យើងសរសេរឈ្មោះទូទៅនៃម៉ាស៊ីនមេរបស់យើង។ ឧទាហរណ៍ ប្រសិនបើ hostnames នៃ servers របស់យើង។ ម៉ាស៊ីនបម្រើ ១, ម៉ាស៊ីនបម្រើ ១, ម៉ាស៊ីនបម្រើ ១បន្ទាប់មក CN នឹងក្លាយជា server.example.com

យើងធ្វើដូចគ្នានៅលើម៉ាស៊ីនមេពីរដែលនៅសល់ជាមួយនឹងភាពខុសគ្នាដែលពាក្យបញ្ជានឹងមាន "ឈ្មោះម៉ាស៊ីន" ដែលត្រូវគ្នា

យើងបង្កើតសំណើពីរសម្រាប់វិញ្ញាបនបត្រដែលនឹងត្រូវបានប្រើដោយសេវាមូលដ្ឋានទិន្នន័យជាមួយនឹងពាក្យបញ្ជាដូចជា៖

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

pki csr dbclusterclient CN:postgres

ដែលជាកន្លែងដែល dbclusterserver и 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

បន្ទាប់មកយើងចាប់ផ្តើមមូលដ្ឋានទិន្នន័យ cluster នៅលើម៉ាស៊ីនមេដោយប្រើពាក្យបញ្ជា៖

database cluster initialize

ថ្នាំងមូលដ្ឋានទិន្នន័យអតិថិជន

យើងធ្វើនីតិវិធីដូចគ្នា ជំនួសឲ្យពាក្យបញ្ជាប៉ុណ្ណោះ។ ចាប់ផ្ដើម​ចង្កោម​មូលដ្ឋាន​ទិន្នន័យ បញ្ចូលពាក្យបញ្ជាដូចជា៖

database cluster join <ip address existing master>

ដែលជាកន្លែងដែលអាសយដ្ឋាន ip អាសយដ្ឋានមេដែលមានស្រាប់របស់ម៉ាស៊ីនមេ CMS ដែលចង្កោមត្រូវបានចាប់ផ្តើម គ្រាន់តែជាមេ។

យើងពិនិត្យមើលពីរបៀបដែលក្រុមមូលដ្ឋានទិន្នន័យរបស់យើងដំណើរការលើម៉ាស៊ីនមេទាំងអស់ដោយប្រើពាក្យបញ្ជា៖

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 Bridges របស់យើង យើងអាចកំណត់រចនាសម្ព័ន្ធ Call Bridge clustering ។ ការដាក់ចង្កោម Call Bridge គឺខុសពី Database ឬ XMPP clustering។ Call Bridge Cluster អាចគាំទ្រពី 2 ទៅ 8 nodes ដោយមិនមានការរឹតបន្តឹងណាមួយឡើយ។ វាមិនត្រឹមតែផ្តល់ភាពច្របូកច្របល់ប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងផ្ទុកតុល្យភាពផងដែរ ដើម្បីឱ្យសន្និសីទអាចត្រូវបានចែកចាយយ៉ាងសកម្មនៅទូទាំងម៉ាស៊ីនមេ Call Bridge ដោយប្រើការចែកចាយការហៅទូរសព្ទឆ្លាតវៃ។ CMS មានមុខងារបន្ថែម ក្រុម Call Bridge និងមុខងារពាក់ព័ន្ធដែលអាចប្រើបានសម្រាប់ការគ្រប់គ្រងបន្ថែមទៀត។

ការហៅជាក្រុមស្ពានត្រូវបានកំណត់រចនាសម្ព័ន្ធជាចម្បងតាមរយៈចំណុចប្រទាក់អ្នកគ្រប់គ្រងគេហទំព័រ
នីតិវិធីដែលបានពិពណ៌នាខាងក្រោមត្រូវតែត្រូវបានអនុវត្តនៅលើម៉ាស៊ីនមេនីមួយៗនៅក្នុងចង្កោម។
ហើយដូច្នេះ,

1. ចូលទៅកាន់គេហទំព័រ ការកំណត់រចនាសម្ព័ន្ធ > ចង្កោម។
2. ក្នុង ហៅអត្តសញ្ញាណស្ពាន ជាឈ្មោះតែមួយគត់ សូមបញ្ចូល callbridge[01,02,03] ដែលត្រូវគ្នានឹងឈ្មោះម៉ាស៊ីនមេ។ ឈ្មោះទាំងនេះគឺបំពាន ប៉ុន្តែត្រូវតែមានតែមួយគត់សម្រាប់ចង្កោមនេះ។ ពួកវាមានលក្ខណៈពិពណ៌នាដោយធម្មជាតិ ពីព្រោះពួកគេបង្ហាញថាពួកគេជាអ្នកកំណត់អត្តសញ្ញាណម៉ាស៊ីនមេ [01,02,03]។
៥.ខ ស្ពានហៅជាក្រុម បញ្ចូល URL អ្នកគ្រប់គ្រងគេហទំព័រនៃម៉ាស៊ីនមេរបស់យើងនៅក្នុងចង្កោម, ផ្នែកគ្រប់គ្រងតុលាការ[01,02,03].example.com:445 នៅក្នុងវាលអាសយដ្ឋាន។ ត្រូវប្រាកដថាបញ្ជាក់ច្រក។ អ្នកអាចទុក Peer link domain SIP ទទេ។
4. បន្ថែមវិញ្ញាបនបត្រទៅ CallBridge trust នៃ server នីមួយៗ ឯកសារដែលមានវិញ្ញាបនបត្រទាំងអស់នៃ servers របស់យើង ដែលយើងបញ្ចូលទៅក្នុងឯកសារនេះតាំងពីដើមដំបូង ដោយមានពាក្យបញ្ជាដូចជា៖

callbridge trust cluster <trusted cluster certificate bundle>

ហើយចាប់ផ្តើមសេវាកម្មឡើងវិញដោយប្រើពាក្យបញ្ជា៖

callbridge restart

ជាលទ្ធផល នៅលើម៉ាស៊ីនមេនីមួយៗ អ្នកគួរតែទទួលបានរូបភាពនេះ៖

ចង្កោម XMPP

សេវាកម្ម XMPP នៅក្នុង CMS ត្រូវបានប្រើដើម្បីគ្រប់គ្រងការចុះឈ្មោះ និងការផ្ទៀងផ្ទាត់ទាំងអស់សម្រាប់កម្មវិធី Cisco Meeting Apps (CMA) រួមទាំងកម្មវិធីបណ្តាញ CMA WebRTC ផងដែរ។ Call Bridge ខ្លួនវាក៏ដើរតួជាម៉ាស៊ីនភ្ញៀវ XMPP សម្រាប់គោលបំណងផ្ទៀងផ្ទាត់ ហេតុដូច្នេះហើយត្រូវតែកំណត់រចនាសម្ព័ន្ធដូចអតិថិជនផ្សេងទៀតដែរ។ ការអត់ឱនកំហុស XMPP គឺជាលក្ខណៈពិសេសមួយដែលត្រូវបានគាំទ្រនៅក្នុងបរិស្ថានផលិតកម្មចាប់តាំងពីកំណែ 2.1

ពាក្យបញ្ជាដែលបានពិពណ៌នាខាងក្រោមត្រូវតែត្រូវបានប្រតិបត្តិនៅលើម៉ាស៊ីនមេនីមួយៗជាមួយនឹងវិញ្ញាបនបត្រសមស្រប។
ដូច្នេះ:

យើងភ្ជាប់វិញ្ញាបនបត្រជាមួយសេវាកម្ម XMPP ជាមួយនឹងពាក្យបញ្ជាដូចជា៖

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

បន្ទាប់មកកំណត់ចំណុចប្រទាក់ស្តាប់ដោយប្រើពាក្យបញ្ជា៖

xmpp listen a

សេវាកម្ម XMPP ទាមទារដែនតែមួយគត់។ នេះជាការចូលសម្រាប់អ្នកប្រើប្រាស់។ ម្យ៉ាងវិញទៀត នៅពេលដែលអ្នកប្រើប្រាស់ព្យាយាមចូលដោយប្រើកម្មវិធី CMA (ឬតាមរយៈម៉ាស៊ីនភ្ញៀវ WebRTC) ពួកគេបញ្ចូល userID@logindomain។ ក្នុងករណីរបស់យើងវានឹង userid@conf.example.com ។ ហេតុអ្វីបានជាវាមិនមែនគ្រាន់តែជា example.com? នៅក្នុងការដាក់ឱ្យប្រើប្រាស់ពិសេសរបស់យើង យើងបានជ្រើសរើសដែន Unified CM របស់យើងដែលអ្នកប្រើប្រាស់ Jabber នឹងប្រើក្នុង Unified CM ជា example.com ដូច្នេះយើងត្រូវការដែនផ្សេងសម្រាប់អ្នកប្រើប្រាស់ CMS ដើម្បីបញ្ជូនការហៅទៅ និងមកពី CMS តាមរយៈដែន SIP ។

ដំឡើងដែន XMPP ដោយប្រើពាក្យបញ្ជាដូចជា៖

xmpp domain <domain>

ហើយបើកសេវាកម្ម XMPP ដោយប្រើពាក្យបញ្ជា៖

xmpp enable

នៅក្នុងសេវាកម្ម XMPP អ្នកត្រូវតែបង្កើតលិខិតសម្គាល់សម្រាប់ Call Bridge នីមួយៗដែលនឹងត្រូវបានប្រើនៅពេលចុះឈ្មោះជាមួយសេវាកម្ម XMPP ។ ឈ្មោះទាំងនេះគឺបំពាន (ហើយមិនទាក់ទងទៅនឹងឈ្មោះតែមួយគត់ដែលអ្នកបានកំណត់រចនាសម្ព័ន្ធសម្រាប់ការហៅជាក្រុមស្ពាន)។ អ្នកត្រូវតែបន្ថែមស្ពានហៅចំនួនបីនៅលើម៉ាស៊ីនមេ XMPP មួយហើយបន្ទាប់មកបញ្ចូលព័ត៌មានសម្ងាត់ទាំងនោះនៅលើម៉ាស៊ីនមេ XMPP ផ្សេងទៀតនៅក្នុងចង្កោម ពីព្រោះការកំណត់នេះមិនសមនឹងមូលដ្ឋានទិន្នន័យរបស់ចង្កោមទេ។ ក្រោយមក យើងនឹងកំណត់រចនាសម្ព័ន្ធ Call Bridge នីមួយៗ ដើម្បីប្រើឈ្មោះនេះ និងការសម្ងាត់ដើម្បីចុះឈ្មោះជាមួយសេវាកម្ម XMPP ។

ឥឡូវនេះយើងត្រូវកំណត់រចនាសម្ព័ន្ធសេវាកម្ម XMPP នៅលើម៉ាស៊ីនមេដំបូងដែលមាន Call Bridges ចំនួនបី 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 cluster mode នៅលើ server cluster ទាំងអស់ដោយប្រើពាក្យបញ្ជា៖

xmpp cluster enable

នៅលើ server ទីមួយនៃ cluster យើងចាប់ផ្តើមបង្កើត xmpp cluster ដោយប្រើពាក្យបញ្ជា៖

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 Callbridge[01,02,03]។ оле ដែន conf.example.ru និងពាក្យសម្ងាត់ដែលត្រូវគ្នា អ្នកអាចឈ្លបយកការណ៍លើពួកគេ។
នៅលើម៉ាស៊ីនមេណាមួយនៅក្នុងចង្កោមដោយប្រើពាក្យបញ្ជា៖

xmpp callbridge list

ទុកឱ្យវាល "ម៉ាស៊ីនមេ" ទទេ ខលប្រីដ នឹងធ្វើការស្វែងរក DNS SRV សម្រាប់ _xmpp-component._tcp.conf.example.comដើម្បីស្វែងរកម៉ាស៊ីនមេ XMPP ដែលមាន។ អាសយដ្ឋាន IP សម្រាប់ភ្ជាប់ callbridges ទៅ XMPP អាចមានភាពខុសគ្នានៅលើ server នីមួយៗ វាអាស្រ័យលើតម្លៃអ្វីដែលត្រូវត្រលប់ទៅការស្នើសុំ record _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 ដឹងថា Web Bridge អាចទុកចិត្តការតភ្ជាប់ពី Call Bridge សូមប្រើពាក្យបញ្ជា៖

webbridge trust <certfile>

ដែលនេះជាឯកសារដែលមានវិញ្ញាបនបត្រទាំងបីពីម៉ាស៊ីនមេនីមួយៗនៅក្នុងចង្កោម។

រូបភាពនេះគួរតែមាននៅលើគ្រប់ម៉ាស៊ីនមេនៅក្នុងចង្កោម។


ឥឡូវនេះយើងត្រូវបង្កើតអ្នកប្រើប្រាស់ដែលមានតួនាទី "appadmin" យើងត្រូវការវា ដូច្នេះយើងអាចកំណត់រចនាសម្ព័ន្ធ cluster របស់យើង (!) ហើយមិនមែន server នីមួយៗនៅក្នុង cluster ដាច់ដោយឡែកពីគ្នាទេ វិធីនេះការកំណត់នឹងត្រូវបានអនុវត្តស្មើៗគ្នាចំពោះ server នីមួយៗ ទោះបីជា ការពិតដែលថាពួកគេនឹងត្រូវបានធ្វើឡើងម្តង។


សម្រាប់ការដំឡើងបន្ថែមទៀតយើងនឹងប្រើ អ្នករត់សំបុត្រ.

សម្រាប់ការអនុញ្ញាត សូមជ្រើសរើស Basic ក្នុងផ្នែកការអនុញ្ញាត

ដើម្បីផ្ញើពាក្យបញ្ជាទៅម៉ាស៊ីនមេ CMS បានត្រឹមត្រូវ អ្នកត្រូវកំណត់ការអ៊ិនកូដដែលត្រូវការ

យើងបញ្ជាក់ Webbridge ជាមួយនឹងពាក្យបញ្ជា POST ជាមួយប៉ារ៉ាម៉ែត្រ url និងអត្ថន័យ cms.example.com



នៅក្នុង webbridge ខ្លួនវា យើងបង្ហាញពីប៉ារ៉ាម៉ែត្រដែលត្រូវការ៖ ការចូលប្រើជាភ្ញៀវ ការចូលប្រើដែលត្រូវបានការពារ។ល។

ហៅក្រុមស្ពាន

តាមលំនាំដើម CMS មិនតែងតែធ្វើឱ្យការប្រើប្រាស់ធនធានសន្និសីទប្រកបដោយប្រសិទ្ធភាពបំផុតដែលមានសម្រាប់វានោះទេ។

ឧទាហរណ៍ សម្រាប់ការប្រជុំជាមួយអ្នកចូលរួមបីនាក់ អ្នកចូលរួមម្នាក់ៗអាចបញ្ចប់នៅលើ Call Bridges បីផ្សេងគ្នា។ ដើម្បីឱ្យអ្នកចូលរួមទាំងបីនេះទំនាក់ទំនងគ្នាទៅវិញទៅមក Call Bridges នឹងបង្កើតការភ្ជាប់ដោយស្វ័យប្រវត្តិរវាង servers និង clients ទាំងអស់នៅក្នុង Space តែមួយ ដូច្នេះវាមើលទៅហាក់ដូចជា clients ទាំងអស់នៅលើ server តែមួយ។ ជាអកុសល ការធ្លាក់ចុះនៃនេះគឺថាសន្និសិទមនុស្ស 3 នាក់តែមួយនឹងប្រើប្រាស់ច្រកប្រព័ន្ធផ្សព្វផ្សាយចំនួន 9 ។ នេះច្បាស់ណាស់ថាជាការប្រើប្រាស់ធនធានមិនមានប្រសិទ្ធភាព។ លើសពីនេះ នៅពេលដែល Call Bridge ពិតជាផ្ទុកលើសទម្ងន់ យន្តការលំនាំដើមគឺត្រូវបន្តទទួលយកការហៅទូរសព្ទ និងផ្តល់សេវាកម្មកាត់បន្ថយគុណភាពដល់អតិថិជនទាំងអស់នៃ Call Bridge នោះ។

បញ្ហាទាំងនេះត្រូវបានដោះស្រាយដោយប្រើមុខងារ Call Bridge Group។ លក្ខណៈពិសេសនេះត្រូវបានណែនាំនៅក្នុងកំណែ 2.1 នៃកម្មវិធី Cisco Meeting Server ហើយត្រូវបានពង្រីកដើម្បីគាំទ្រការផ្ទុកតុល្យភាពសម្រាប់ការហៅទូរសព្ទ Cisco Meeting App (CMA) ទាំងក្នុង និងក្រៅប្រទេស រួមទាំងអ្នកចូលរួម WebRTC ផងដែរ។

ដើម្បីដោះស្រាយបញ្ហាការតភ្ជាប់ឡើងវិញ ដែនកំណត់ផ្ទុកដែលអាចកំណត់រចនាសម្ព័ន្ធបានចំនួនបីត្រូវបានណែនាំសម្រាប់ស្ពានហៅនីមួយៗ៖

ដែនកំណត់ផ្ទុក - នេះគឺជាបន្ទុកជាលេខអតិបរមាសម្រាប់ Call Bridge ជាក់លាក់មួយ។ វេទិកានីមួយៗមានដែនកំណត់ផ្ទុកដែលបានណែនាំ ដូចជា 96000 សម្រាប់ CMS1000 និង 1.25 GHz ក្នុងមួយ vCPU សម្រាប់ម៉ាស៊ីននិម្មិត។ ការហៅទូរសព្ទផ្សេងៗគ្នាប្រើប្រាស់បរិមាណជាក់លាក់នៃធនធាន អាស្រ័យលើដំណោះស្រាយ និងអត្រាស៊ុមរបស់អ្នកចូលរួម។
NewConferenceLoadLimitBasisPoints (លំនាំដើម 50% loadLimit) - កំណត់ដែនកំណត់ផ្ទុកម៉ាស៊ីនមេ បន្ទាប់ពីសន្និសីទថ្មីត្រូវបានបដិសេធ។
ExistingConferenceLoadLimitBasisPoints (លំនាំដើម 80% នៃ loadLimit) - តម្លៃផ្ទុកម៉ាស៊ីនមេ បន្ទាប់ពីអ្នកចូលរួមដែលចូលរួមសន្និសីទដែលមានស្រាប់នឹងត្រូវបានបដិសេធ។

ខណៈពេលដែលលក្ខណៈពិសេសនេះត្រូវបានរចនាឡើងសម្រាប់ការចែកចាយការហៅទូរសព្ទ និងសមតុល្យការផ្ទុក ក្រុមផ្សេងទៀតដូចជា TURN Servers, Web Bridge Servers និង Recorders ក៏អាចត្រូវបានកំណត់ទៅ Call Bridge Groups ដូច្នេះពួកគេក៏អាចត្រូវបានដាក់ជាក្រុមយ៉ាងត្រឹមត្រូវសម្រាប់ការប្រើប្រាស់ដ៏ល្អប្រសើរផងដែរ។ ប្រសិនបើវត្ថុណាមួយក្នុងចំណោមវត្ថុទាំងនេះមិនត្រូវបានចាត់ឱ្យទៅក្រុមហៅទេ ពួកវាត្រូវបានសន្មតថាមានសម្រាប់ម៉ាស៊ីនមេទាំងអស់ដោយគ្មានអាទិភាពជាក់លាក់ណាមួយឡើយ។

ប៉ារ៉ាម៉ែត្រទាំងនេះត្រូវបានកំណត់នៅទីនេះ៖ cms.example.com:445/api/v1/system/configuration/cluster

បន្ទាប់ យើង​បង្ហាញ​ទៅ​ក្រុម​ callbridge នីមួយៗ​ដែល​ក្រុម callbridge ដែល​វា​ជា​កម្មសិទ្ធិ៖

ស្ពានហៅដំបូង

ស្ពានហៅទីពីរ

ស្ពានហៅទីបី


ដូច្នេះហើយ យើងបានកំណត់រចនាសម្ព័ន្ធក្រុម Call Brdige ដើម្បីប្រើប្រាស់ធនធានរបស់ Cisco Meeting Server cluster ឱ្យកាន់តែមានប្រសិទ្ធភាព។

កំពុងនាំចូលអ្នកប្រើប្រាស់ពី Active Directory

សេវាកម្មគ្រប់គ្រងគេហទំព័រមានផ្នែកកំណត់រចនាសម្ព័ន្ធ LDAP ប៉ុន្តែវាមិនផ្តល់ជម្រើសនៃការកំណត់រចនាសម្ព័ន្ធស្មុគស្មាញទេ ហើយព័ត៌មានមិនត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យចង្កោមទេ ដូច្នេះការកំណត់រចនាសម្ព័ន្ធនឹងត្រូវធ្វើឡើងដោយដៃនៅលើម៉ាស៊ីនមេនីមួយៗតាមរយៈចំណុចប្រទាក់គេហទំព័រ ឬតាមរយៈ API ហើយដើម្បីឱ្យយើង "កុំក្រោកឡើង" បីដង យើងនឹងនៅតែកំណត់ទិន្នន័យតាមរយៈ API ដដែល។

ការប្រើប្រាស់ URL ដើម្បីចូលប្រើ cms01.example.com:445/api/v1/ldapServers បង្កើតវត្ថុម៉ាស៊ីនមេ LDAP ដោយបញ្ជាក់ប៉ារ៉ាម៉ែត្រដូចជា៖

• ម៉ាស៊ីនមេ IP
• លេខច្រក
• ឈ្មោះ​អ្នកប្រើប្រាស់
• ពាក្យសម្ងាត់
• ធានា

សុវត្ថិភាព - ជ្រើសរើសពិតឬមិនពិតអាស្រ័យលើច្រក 389 - មិនមានសុវត្ថិភាព 636 - ការពារ។


ការគូសផែនទីប្រភព LDAP ទៅនឹងគុណលក្ខណៈនៅក្នុង Cisco Meeting Server ។
ការគូសផែនទី LDAP គូសផែនទីគុណលក្ខណៈនៅក្នុងថត LDAP ទៅនឹងគុណលក្ខណៈនៅក្នុង CMS ។ លក្ខណៈសម្បត្តិជាក់ស្តែង៖

• jidMapping
• ការធ្វើផែនទីឈ្មោះ
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

ការពិពណ៌នាអំពីគុណលក្ខណៈចាឌី តំណាងឱ្យលេខសម្គាល់ចូលរបស់អ្នកប្រើនៅក្នុង CMS ។ ដោយសារនេះជាម៉ាស៊ីនមេ Microsoft Active Directory LDAP ទើប CMS JID ផ្គូផ្គងទៅ sAMAccountName ក្នុង LDAP ដែលសំខាន់គឺលេខសម្គាល់ចូល Active Directory របស់អ្នកប្រើប្រាស់។ ចំណាំផងដែរថាអ្នកយក sAMAccountName ហើយបន្ថែមដែន conf.pod6.cms.lab ទៅចុងបញ្ចប់របស់វា ព្រោះនេះគឺជាការចូលដែលអ្នកប្រើប្រាស់របស់អ្នកនឹងប្រើដើម្បីចូលទៅក្នុង CMS ។

ការធ្វើផែនទីឈ្មោះ ផ្គូផ្គងអ្វីដែលមាននៅក្នុងប្រអប់ Active Directory displayName ទៅនឹងវាលឈ្មោះ CMS របស់អ្នកប្រើ។

coSpaceNameMapping បង្កើតឈ្មោះចន្លោះ CMS ដោយផ្អែកលើវាលបង្ហាញឈ្មោះ។ គុណលក្ខណៈនេះ រួមជាមួយនឹងគុណលក្ខណៈ coSpaceUriMapping គឺជាអ្វីដែលតម្រូវឱ្យបង្កើតចន្លោះសម្រាប់អ្នកប្រើប្រាស់ម្នាក់ៗ។

coSpaceUriMapping កំណត់ផ្នែកអ្នកប្រើប្រាស់នៃ URI ដែលទាក់ទងនឹងទំហំផ្ទាល់ខ្លួនរបស់អ្នកប្រើប្រាស់។ ដែនមួយចំនួនអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីហៅចូលទៅក្នុងលំហ។ ប្រសិនបើផ្នែករបស់អ្នកប្រើត្រូវគ្នានឹងវាលនេះសម្រាប់ដែនមួយក្នុងចំណោមដែនទាំងនេះ ការហៅទូរសព្ទនឹងត្រូវបានដឹកនាំទៅកាន់លំហរបស់អ្នកប្រើនោះ។

coSpaceSecondaryUriMapping កំណត់ URI ទីពីរ ដើម្បីទៅដល់លំហ។ វាអាចត្រូវបានប្រើដើម្បីបន្ថែមឈ្មោះក្លែងក្លាយជាលេខសម្រាប់បញ្ជូនការហៅទៅកាន់ចន្លោះរបស់អ្នកប្រើដែលបាននាំចូលជាជម្រើសជំនួស URI អក្សរក្រមលេខដែលបានកំណត់ក្នុងប៉ារ៉ាម៉ែត្រ coSpaceUriMapping ។

ម៉ាស៊ីនមេ LDAP និងផែនទី LDAP ត្រូវបានកំណត់រចនាសម្ព័ន្ធ។ ឥឡូវអ្នកត្រូវភ្ជាប់ពួកវាជាមួយគ្នាដោយបង្កើតប្រភព LDAP ។

ការប្រើប្រាស់ URL ដើម្បីចូលប្រើ cms01.example.com:445/api/v1/ldapSource បង្កើតវត្ថុប្រភព LDAP ដោយបញ្ជាក់ប៉ារ៉ាម៉ែត្រដូចជា៖

• ម៉ាស៊ីនបម្រើ
• ផែនទី
• មូលដ្ឋានDn
• តម្រង

ឥឡូវនេះការកំណត់រចនាសម្ព័ន្ធ LDAP ត្រូវបានបញ្ចប់ អ្នកអាចអនុវត្តប្រតិបត្តិការធ្វើសមកាលកម្មដោយដៃ។

យើងធ្វើនេះទាំងនៅក្នុង Web interface នៃ server នីមួយៗដោយចុច ធ្វើសមកាលកម្មឥឡូវនេះ ផ្នែក Active Directory


ឬតាមរយៈ API ជាមួយនឹងពាក្យបញ្ជា POST ដោយប្រើ URL ដើម្បីចូលប្រើ cms01.example.com:445/api/v1/ldapSyncs

សន្និសីទ Ad-Hoc

តើនេះជាអ្វី?នៅក្នុងគំនិតប្រពៃណី សន្និសីទគឺនៅពេលដែលអ្នកចូលរួមពីរនាក់កំពុងនិយាយគ្នា ហើយអ្នកចូលរួមម្នាក់ (ដោយប្រើឧបករណ៍ដែលបានចុះឈ្មោះជាមួយ Unified CM) ចុចប៊ូតុង "សន្និសិទ" ហៅទៅកាន់អ្នកផ្សេងទៀត ហើយបន្ទាប់ពីនិយាយទៅកាន់ភាគីទីបីនោះ។ ចុចប៊ូតុង "សន្និសិទ" ម្តងទៀត។ ដើម្បីចូលរួមអ្នកចូលរួមទាំងអស់នៅក្នុងសន្និសីទត្រីភាគី។

អ្វីដែលខុសប្លែកពីសន្និសីទ Ad-Hoc ពីសន្និសីទដែលបានកំណត់ពេលនៅក្នុង CMS គឺថាសន្និសីទ Ad-Hoc មិនមែនគ្រាន់តែជាការហៅ SIP ទៅកាន់ CMS នោះទេ។ នៅពេលអ្នកផ្តួចផ្តើមសន្និសីទចុចប៊ូតុង Conference ជាលើកទីពីរ ដើម្បីអញ្ជើញអ្នកគ្រប់គ្នាឱ្យចូលរួមកិច្ចប្រជុំតែមួយនោះ Unified CM ត្រូវតែធ្វើការហៅ API ទៅកាន់ CMS ដើម្បីបង្កើតសន្និសិទតាមយន្តហោះ ដែលការហៅទូរសព្ទទាំងអស់ត្រូវបានផ្ទេរ។ ទាំងអស់នេះកើតឡើងដោយអ្នកចូលរួមដោយមិនបានកត់សម្គាល់។

នេះមានន័យថា Unified CM ត្រូវតែកំណត់រចនាសម្ព័ន្ធអត្តសញ្ញាណ API និងអាសយដ្ឋាន/ច្រក WebAdmin នៃសេវាកម្ម ព្រមទាំង SIP Trunk ដោយផ្ទាល់ទៅកាន់ម៉ាស៊ីនមេ CMS ដើម្បីបន្តការហៅទូរសព្ទ។

បើចាំបាច់ CUCM អាចបង្កើតលំហនៅក្នុង CMS ថាមវន្ត ដូច្នេះការហៅនីមួយៗអាចទៅដល់ CMS និងត្រូវគ្នានឹងច្បាប់ហៅចូលដែលមានបំណងសម្រាប់ដកឃ្លា។

ការរួមបញ្ចូលជាមួយ CUCM កំណត់រចនាសម្ព័ន្ធតាមរបៀបដូចដែលបានពិពណ៌នានៅក្នុងអត្ថបទ មុននេះ លើកលែងតែនៅលើ Cisco UCM អ្នកត្រូវបង្កើត trunks បីសម្រាប់ CMS, Conference Bridges ចំនួនបី នៅក្នុង SIP Security Profile បញ្ជាក់ឈ្មោះប្រធានបទចំនួនបី ផ្លូវក្រុម បញ្ជីផ្លូវ ក្រុម Media Resourse Groups និង Media Resourse Group Lists និងបន្ថែមច្បាប់កំណត់ផ្លូវមួយចំនួន។ ទៅកាន់ Cisco Meeting Server។

ទម្រង់សុវត្ថិភាព SIP:


គល់ឈើ:


ដើមនីមួយៗមើលទៅដូចគ្នា៖




ស្ពានសន្និសីទ


ស្ពានសន្និសិទនីមួយៗមើលទៅដូចគ្នា៖


ក្រុមផ្លូវ


បញ្ជីផ្លូវ


ក្រុមធនធានប្រព័ន្ធផ្សព្វផ្សាយ


បញ្ជីក្រុមធនធានប្រព័ន្ធផ្សព្វផ្សាយ

ច្បាប់ហៅទូរសព្ទ

មិនដូចប្រព័ន្ធគ្រប់គ្រងការហៅទូរសព្ទកម្រិតខ្ពស់ដូចជា Unified CM ឬ Expressway ទេ CMS រកមើលតែដែននៅក្នុងវាល SIP Request-URI សម្រាប់ការហៅទូរសព្ទថ្មី។ ដូច្នេះប្រសិនបើ SIP INVITE គឺសម្រាប់ sip: [អ៊ីមែលការពារ]CMS ខ្វល់តែអំពី domain.com ប៉ុណ្ណោះ។ CMS អនុវត្តតាមច្បាប់ទាំងនេះដើម្បីកំណត់កន្លែងដែលត្រូវបញ្ជូនការហៅទូរសព្ទ៖

1. CMS ដំបូងព្យាយាមផ្គូផ្គងដែន SIP ជាមួយនឹងដែនដែលបានកំណត់រចនាសម្ព័ន្ធនៅក្នុងច្បាប់ហៅចូល។ បន្ទាប់មកការហៅទូរសព្ទទាំងនេះអាចត្រូវបានបញ្ជូនទៅកាន់កន្លែង ("គោលដៅ") ឬអ្នកប្រើប្រាស់ជាក់លាក់, IVRs ខាងក្នុង ឬរួមបញ្ចូលដោយផ្ទាល់នូវគោលដៅ Microsoft Lync/Skype for Business (S4B)។
2. ប្រសិនបើមិនមានការផ្គូផ្គងនៅក្នុងច្បាប់ហៅចូលទេ CMS នឹងព្យាយាមផ្គូផ្គងដែនដែលបានកំណត់រចនាសម្ព័ន្ធនៅក្នុងតារាងបញ្ជូនបន្តការហៅ។ ប្រសិនបើការប្រកួតត្រូវបានធ្វើឡើង ច្បាប់អាចបដិសេធការហៅទូរសព្ទ ឬបញ្ជូនបន្តការហៅចេញ។ នៅ​ពេល​នេះ CMS អាច​សរសេរ​ដែន​ឡើង​វិញ ដែល​ពេល​ខ្លះ​មាន​ប្រយោជន៍​សម្រាប់​ការ​ហៅ​ទៅ Lync domains។ អ្នកក៏អាចជ្រើសរើស pass throw ដែលមានន័យថាគ្មានវាលណាមួយនឹងត្រូវបានកែប្រែបន្ថែម ឬប្រើផែនការហៅទូរសព្ទ CMS ខាងក្នុង។ ប្រសិនបើមិនមានការផ្គូផ្គងនៅក្នុងច្បាប់បញ្ជូនបន្តការហៅទេ លំនាំដើមគឺត្រូវបដិសេធការហៅ។ សូមចងចាំថានៅក្នុង CMS ទោះបីជាការហៅត្រូវបាន "បញ្ជូនបន្ត" ប្រព័ន្ធផ្សព្វផ្សាយនៅតែភ្ជាប់ទៅនឹង CMS ដែលមានន័យថាវានឹងស្ថិតនៅក្នុងផ្លូវបញ្ជូនសញ្ញា និងប្រព័ន្ធផ្សព្វផ្សាយ។
បន្ទាប់មក​មានតែ​ការហៅ​ទូរសព្ទ​ដែល​បាន​បញ្ជូនបន្ត​ប៉ុណ្ណោះ​ដែល​ជា​កម្មវត្ថុ​នៃ​ច្បាប់​ហៅ​ចេញ។ ការកំណត់ទាំងនេះកំណត់ទិសដៅដែលការហៅទូរសព្ទត្រូវបានផ្ញើ ប្រភេទដើម (ថាតើវាជាការហៅទូរសព្ទ Lync ថ្មី ឬការហៅ SIP ស្តង់ដារ) និងការបំប្លែងណាមួយដែលអាចត្រូវបានអនុវត្តប្រសិនបើការផ្ទេរមិនត្រូវបានជ្រើសរើសនៅក្នុងច្បាប់បញ្ជូនបន្តការហៅ។

នេះគឺជាកំណត់ហេតុជាក់ស្តែងនៃអ្វីដែលកើតឡើងក្នុងអំឡុងពេលសន្និសីទ Ad-Hoc

រូបថត​អេក្រង់​បង្ហាញ​ថា​វា​មិន​ល្អ (ខ្ញុំ​មិន​ដឹង​ពី​វិធី​ធ្វើ​ឱ្យ​វា​កាន់​តែ​ប្រសើរ) ដូច្នេះ​ខ្ញុំ​នឹង​សរសេរ​កំណត់​ហេតុ​ដូច​នេះ៖

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

សន្និសីទ Ad-Hoc ខ្លួនវាផ្ទាល់៖


ច្បាប់​ហៅ​ចូល
ការកំណត់រចនាសម្ព័ន្ធប៉ារ៉ាម៉ែត្រនៃការហៅចូលគឺចាំបាច់ដើម្បីអាចទទួលការហៅចូលនៅក្នុង CMS ។ ដូចដែលអ្នកបានឃើញនៅក្នុងការដំឡើង LDAP អ្នកប្រើប្រាស់ទាំងអស់ត្រូវបាននាំចូលជាមួយដែន conf.pod6.cms.lab ។ ដូច្នេះយ៉ាងហោចណាស់ អ្នកចង់ហៅទៅកាន់ដែននេះដើម្បីកំណត់គោលដៅដកឃ្លា។ អ្នកក៏នឹងត្រូវរៀបចំច្បាប់សម្រាប់អ្វីគ្រប់យ៉ាងដែលមានបំណងសម្រាប់ឈ្មោះដែនដែលមានសមត្ថភាពពេញលេញ (ហើយប្រហែលជាអាសយដ្ឋាន IP) នៃម៉ាស៊ីនមេ CMS នីមួយៗ។ ការគ្រប់គ្រងការហៅទូរសព្ទខាងក្រៅរបស់យើង Unified CM នឹងកំណត់រចនាសម្ព័ន្ធ SIP trunks ដែលឧទ្ទិសដល់ម៉ាស៊ីនមេ CMS នីមួយៗដោយឡែកពីគ្នា។ អាស្រ័យលើថាតើទិសដៅនៃ SIP trunks ទាំងនេះគឺជាអាសយដ្ឋាន IP ឬ FQDN របស់ម៉ាស៊ីនមេនឹងកំណត់ថាតើ CMS ចាំបាច់ត្រូវកំណត់រចនាសម្ព័ន្ធដើម្បីទទួលយកការហៅទៅកាន់អាសយដ្ឋាន IP របស់វា ឬ FQDN ដែរឬទេ។

ដែនដែលមានច្បាប់ចូលជាអាទិភាពខ្ពស់បំផុត ត្រូវបានប្រើជាដែនសម្រាប់ចន្លោះអ្នកប្រើប្រាស់ណាមួយ។ នៅពេលដែលអ្នកប្រើប្រាស់ធ្វើសមកាលកម្មតាមរយៈ LDAP CMS បង្កើតចន្លោះដោយស្វ័យប្រវត្តិ ប៉ុន្តែមានតែផ្នែកអ្នកប្រើប្រាស់នៃ URI (coSpaceUriMapping) ឧទាហរណ៍ user.space។ ផ្នែក ការការពារ URI ពេញលេញត្រូវបានបង្កើតដោយផ្អែកលើច្បាប់នេះ។ តាមការពិត ប្រសិនបើអ្នកត្រូវចូលទៅក្នុង Web Bridge នៅចំណុចនេះ អ្នកនឹងឃើញថា Space URI មិនមានដែនទេ។ តាមរយៈការកំណត់ច្បាប់នេះជាអាទិភាពខ្ពស់បំផុត អ្នកកំពុងកំណត់ដែនសម្រាប់ចន្លោះដែលបានបង្កើត conf ។example.com ។


ច្បាប់ហៅចេញ

ដើម្បីអនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ធ្វើការហៅចេញទៅកាន់ក្រុម Unified CM អ្នកត្រូវតែកំណត់រចនាសម្ព័ន្ធច្បាប់ចេញក្រៅ។ ដែននៃចំណុចបញ្ចប់ដែលបានចុះឈ្មោះជាមួយ Unified CM ដូចជា Jabber គឺ example.com ។ ការហៅទៅកាន់ដែននេះគួរតែត្រូវបានបញ្ជូនជាការហៅ SIP ស្តង់ដារទៅកាន់ថ្នាំងដំណើរការការហៅទូរសព្ទដែលបង្រួបបង្រួម CM ។ ម៉ាស៊ីនមេគឺ cucm-01.example.com ហើយម៉ាស៊ីនមេបន្ថែមគឺ cucm-02.example.com ។

ច្បាប់ទីមួយពិពណ៌នាអំពីការកំណត់ផ្លូវសាមញ្ញបំផុតនៃការហៅទូរសព្ទរវាងម៉ាស៊ីនមេចង្កោម។

វាល ក្នុងស្រុកពីដែន ទទួលខុសត្រូវចំពោះអ្វីដែលនឹងត្រូវបានបង្ហាញនៅក្នុង SIP-URI របស់អ្នកហៅចូលសម្រាប់អ្នកដែលត្រូវបានហៅតាមនិមិត្តសញ្ញា “@”។ ប្រសិនបើយើងទុកវាឱ្យនៅទទេ នោះបន្ទាប់ពីនិមិត្តសញ្ញា “@” នឹងមានអាសយដ្ឋាន IP របស់ CUCM ដែលការហៅនេះឆ្លងកាត់។ ប្រសិនបើយើងបញ្ជាក់ដែនមួយ នោះបន្ទាប់ពីនិមិត្តសញ្ញា “@” ពិតជានឹងមានដែន។ នេះគឺចាំបាច់ដើម្បីអាចហៅត្រឡប់មកវិញ បើមិនដូច្នោះទេ វានឹងមិនអាចហៅត្រឡប់មកវិញតាមរយៈ SIP-URI name@ip-address បានទេ។

ហៅទូរស័ព្ទទៅពេលដែលបានបញ្ជាក់ ក្នុងស្រុកពីដែន


ហៅទៅពេលណា НЕ ចង្អុលបង្ហាញ ក្នុងស្រុកពីដែន


ត្រូវប្រាកដថាបញ្ជាក់យ៉ាងច្បាស់ថាបានអ៊ិនគ្រីប ឬមិនបានអ៊ិនគ្រីបសម្រាប់ការហៅចេញ ពីព្រោះគ្មានអ្វីដំណើរការជាមួយប៉ារ៉ាម៉ែត្រស្វ័យប្រវត្តិទេ។

ការកត់ត្រា

សន្និសីទវីដេអូត្រូវបានថតដោយម៉ាស៊ីនមេកំណត់ត្រា។ ឧបករណ៍ថតចម្លងគឺដូចគ្នាទៅនឹង Cisco Meeting Server។ ឧបករណ៍ថតសំឡេងមិនតម្រូវឱ្យមានការដំឡើងអាជ្ញាប័ណ្ណណាមួយឡើយ។ អាជ្ញាប័ណ្ណថតត្រូវបានទាមទារសម្រាប់ម៉ាស៊ីនមេដែលកំពុងដំណើរការសេវាកម្ម CallBridge ពោលគឺឧ។ អាជ្ញាប័ណ្ណថតត្រូវបានទាមទារ ហើយត្រូវតែអនុវត្តចំពោះសមាសភាគ CallBridge ហើយមិនមែនចំពោះម៉ាស៊ីនមេដែលកំពុងដំណើរការកម្មវិធីថតសំឡេងនោះទេ។ កម្មវិធីថតចម្លងមានឥរិយាបទជាអតិថិជន Extensible Messaging and Presence Protocol (XMPP) ដូច្នេះម៉ាស៊ីនមេ XMPP ត្រូវតែបើកនៅលើម៉ាស៊ីនមេដែលបង្ហោះ CallBridge ។

ដោយសារតែ យើង​មាន​ចង្កោម​មួយ ហើយ​អាជ្ញាបណ្ណ​ត្រូវ​តែ​ត្រូវ​បាន​ "ពង្រីក" នៅ​ទូទាំង​ម៉ាស៊ីន​បម្រើ​ទាំង​បី​ក្នុង​ចង្កោម។ បន្ទាប់មកគ្រាន់តែនៅក្នុងគណនីផ្ទាល់ខ្លួនរបស់អ្នកនៅក្នុងអាជ្ញាប័ណ្ណដែលយើងភ្ជាប់ (បន្ថែម) អាសយដ្ឋាន MAC នៃចំណុចប្រទាក់ A នៃម៉ាស៊ីនមេ CMS ទាំងអស់ដែលបានរួមបញ្ចូលនៅក្នុងចង្កោម។

ហើយនេះគឺជារូបភាពដែលគួរតែមាននៅលើគ្រប់ server នៅក្នុង cluster

ជាទូទៅ មានសេណារីយ៉ូជាច្រើនសម្រាប់ការដាក់ Recorder ប៉ុន្តែយើងនឹងនៅជាប់នឹងចំណុចនេះ៖


មុននឹងដំឡើងកម្មវិធីថតសំឡេង អ្នកត្រូវរៀបចំកន្លែងដែលសន្និសីទវីដេអូនឹងត្រូវបានថត។ តាមពិតនៅទីនេះ តំណ, របៀបតំឡើងការថតទាំងអស់។ ខ្ញុំផ្តោតលើចំណុចសំខាន់ៗ និងព័ត៌មានលម្អិត៖

1. វាជាការល្អប្រសើរជាងមុនក្នុងការរអិលវិញ្ញាបនបត្រពីម៉ាស៊ីនមេដំបូងនៅក្នុងចង្កោម។
2. កំហុស "មិន​អាច​ថត​បាន​" អាច​នឹង​កើត​ឡើង​ដោយ​សារ​តែ​វិញ្ញាបនបត្រ​ខុស​ត្រូវ​បាន​បញ្ជាក់​នៅ​ក្នុង Recorder Trust ។
3. ការសរសេរអាចនឹងមិនដំណើរការប្រសិនបើថត NFS ដែលបានបញ្ជាក់សម្រាប់ការថតមិនមែនជាថត root ។

ពេលខ្លះមានតម្រូវការក្នុងការកត់ត្រាសន្និសិទរបស់អ្នកប្រើប្រាស់ជាក់លាក់មួយ ឬកន្លែងទំនេរដោយស្វ័យប្រវត្តិ។

សម្រាប់ការនេះ CallProfiles ពីរត្រូវបានបង្កើតឡើង៖
ជាមួយនឹងការថតត្រូវបានបិទ


ហើយជាមួយនឹងមុខងារថតដោយស្វ័យប្រវត្តិ


បន្ទាប់យើង "ភ្ជាប់" CallProfile ជាមួយនឹងមុខងារថតដោយស្វ័យប្រវត្តិទៅកន្លែងដែលត្រូវការ។


នៅក្នុង CMS វាត្រូវបានបង្កើតឡើងដូច្នេះថាប្រសិនបើ CallProfile ត្រូវបានភ្ជាប់យ៉ាងជាក់លាក់ទៅនឹងចន្លោះ ឬចន្លោះណាមួយនោះ CallProfile នេះដំណើរការតែទាក់ទងនឹងចន្លោះជាក់លាក់ទាំងនេះប៉ុណ្ណោះ។ ហើយប្រសិនបើ CallProfile មិនត្រូវបានចងភ្ជាប់ទៅចន្លោះណាមួយទេ នោះតាមលំនាំដើម វាត្រូវបានអនុវត្តទៅចន្លោះទាំងនោះដែលគ្មាន CallProfile ត្រូវបានចងយ៉ាងច្បាស់លាស់។

លើកក្រោយខ្ញុំនឹងព្យាយាមពណ៌នាពីរបៀបដែល CMS ត្រូវបានចូលប្រើនៅខាងក្រៅបណ្តាញខាងក្នុងរបស់ស្ថាប័ន។

ប្រភព:

• 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-later។ pdf

ប្រភព: www.habr.com