🥇Pelayan Mesyuarat Cisco 2.5.2. Kelompok dalam mod Boleh Skala dan Berdaya tahan dengan rakaman persidangan video

Dalam isu ini, saya akan menunjukkan dan menerangkan beberapa kehalusan menyediakan pelayan CMS dalam mod kelompok failover.

TeoriSecara umum, terdapat tiga jenis penggunaan pelayan CMS:

Single Gabungan(Gabungan tunggal), i.e. ia adalah satu pelayan yang menjalankan semua perkhidmatan yang diperlukan. Dalam kebanyakan kes, penggunaan jenis ini hanya terpakai untuk akses pelanggan dalaman dan dalam persekitaran yang lebih kecil di mana kebolehskalaan pelayan tunggal dan had redundansi bukanlah isu kritikal, atau dalam situasi di mana CMS hanya melaksanakan fungsi tertentu, seperti persidangan ad hoc di Cisco UCM.
Skim kerja anggaran:

Pembelahan Tunggal(Single Shared) memanjangkan jenis penggunaan sebelumnya dengan menambahkan pelayan yang berasingan untuk akses luaran. Dalam pelaksanaan warisan, ini bermakna menggunakan pelayan CMS dalam segmen rangkaian yang dipisahkan tentera (DMZ) di mana pelanggan luaran boleh mengaksesnya dan satu pelayan CMS dalam teras rangkaian tempat pelanggan dalaman mengakses CMS. Model penggunaan khusus ini kini digantikan oleh jenis yang dipanggil tepi tunggal, yang terdiri daripada pelayan Lebuhraya Cisco, yang sama ada mempunyai atau akan mempunyai banyak keupayaan pintasan Firewall yang sama, jadi pelanggan tidak perlu menambah pelayan kelebihan CMS khusus.
Skim kerja anggaran:

Berskala dan Berdaya tahan(Boleh Skala dan Toleransi Kesalahan) Jenis ini termasuk lebihan untuk setiap komponen, membenarkan sistem berkembang dengan keperluan anda ke kapasiti maksimumnya sambil menyediakan lebihan sekiranya berlaku kegagalan. Ia juga menggunakan konsep Tepi Tunggal untuk menyediakan akses luaran yang selamat. Ini adalah jenis yang akan kami bincangkan dalam episod ini. Jika kami memahami cara untuk menggunakan kluster jenis ini, kami bukan sahaja akan memahami jenis penggunaan lain, tetapi kami juga boleh memahami cara membuat kluster pelayan CMS, dengan mengambil kira potensi pertumbuhan keperluan.

Sebelum beralih ke penempatan, anda perlu memahami beberapa perkara asas, iaitu

Komponen perisian utama CMS:

Pangkalan Data: membolehkan anda menggabungkan beberapa konfigurasi seperti pelan dail, ruang pengguna dan pengguna itu sendiri. Menyokong pengelompokan untuk ketersediaan tinggi (tuan tunggal) sahaja.
Panggil Bridge: perkhidmatan untuk persidangan audio dan video, membawa kawalan penuh ke atas pengurusan dan pemprosesan panggilan dan proses multimedia. Menyokong pengelompokan untuk ketersediaan dan kebolehskalaan yang tinggi.
pelayan XMPP: bertanggungjawab untuk mendaftar dan mengesahkan pelanggan menggunakan Aplikasi Cisco Meeting dan/atau WebRTC(komunikasi masa nyata, atau hanya dalam penyemak imbas), serta isyarat antara komponen. Hanya boleh dikelompokkan untuk ketersediaan tinggi.
jambatan web: Menyediakan akses pelanggan kepada WebRTC.
pengimbang muatan: Menyediakan satu titik sambungan untuk Cisco Meeting Apps dalam mod Single Split. Mendengar pada antara muka luaran dan port untuk sambungan masuk. Begitu juga, pengimbang beban menerima sambungan TLS masuk daripada pelayan XMPP, yang melaluinya ia boleh menukar sambungan TCP daripada klien luaran.
Dalam senario kami, ia tidak akan diperlukan.
TURN pelayan: Menyediakan teknologi pintasan Firewall yang membolehkan
gantung CMS kami di belakang Firewall atau NAT untuk menyambungkan pelanggan luaran menggunakan Cisco Meeting App atau peranti SIP. Dalam senario kami, ia tidak diperlukan.
Pentadbir Web: Antara muka pentadbiran dan akses API, termasuk untuk persidangan ad hoc Unified CM.

Mod Konfigurasi

Tidak seperti kebanyakan produk Cisco yang lain, Cisco Meeting Server menyokong tiga kaedah konfigurasi untuk membolehkan sebarang jenis penggunaan.

Barisan Perintah (CLI): Antara muka baris arahan, dikenali sebagai MMP, untuk tugas konfigurasi awal dan sijil.
Pentadbir Web: Terutamanya untuk konfigurasi berkaitan CallBridge, terutamanya apabila mengkonfigurasi pelayan bukan berkelompok tunggal.
REST API: Digunakan untuk konfigurasi yang paling kompleks dan tugas pangkalan data kelompok.

Sebagai tambahan kepada perkara di atas, protokol SFTP untuk memindahkan fail—biasanya lesen, sijil atau log—ke dan dari CMS.

Dalam panduan penggunaan daripada Cisco, ia ditulis dalam bahasa Inggeris dan putih bahawa kluster perlu digunakan sekurang-kurangnya tiga pelayan (nod) dalam konteks pangkalan data. Kerana hanya dengan bilangan nod yang ganjil mekanisme untuk memilih Master Pangkalan Data baru akan berfungsi, dan secara umum Master Pangkalan Data mempunyai sambungan kepada kebanyakan pangkalan data pelayan CMS.

Dan seperti yang ditunjukkan oleh amalan, dua pelayan (nod) benar-benar tidak mencukupi. Mekanisme pemilihan berfungsi apabila Master dibut semula, pelayan Slave menjadi Master hanya selepas pelayan but semula dinaikkan. Walau bagaimanapun, jika dalam kelompok dua pelayan pelayan Master tiba-tiba "keluar", maka pelayan Hamba tidak akan menjadi Tuan, dan jika Hamba "keluar", maka pelayan Master yang tinggal akan menjadi Hamba.

Tetapi dalam konteks XMPP, ia benar-benar perlu untuk memasang kelompok tiga pelayan, kerana jika, sebagai contoh, anda melumpuhkan perkhidmatan XMPP pada salah satu pelayan di mana XMMP berada dalam status Pemimpin, maka pada pelayan XMPP yang tinggal ia akan kekal dalam status Pengikut dan sambungan CallBridge ke XMPP akan terputus, kerana CallBridge menyambung secara eksklusif kepada XMPP dengan status Pemimpin. Dan ini adalah kritikal, kerana. tiada panggilan akan diteruskan.

Juga dalam panduan penggunaan yang sama, kelompok dengan satu pelayan XMPP ditunjukkan.

Dan dengan mengambil kira perkara di atas, menjadi jelas mengapa: ia berfungsi kerana ia berada dalam mod failover.

Dalam kes kami, pelayan XMPP akan hadir pada ketiga-tiga nod.

Diandaikan bahawa ketiga-tiga pelayan kami sudah siap.

rekod DNS

Sebelum anda mula mengkonfigurasi pelayan, anda perlu mencipta rekod DNS А и SRV jenis:

Ambil perhatian bahawa rekod DNS kami mempunyai dua domain example.com dan conf.example.com. Example.com ialah domain yang boleh digunakan oleh semua pelanggan Pengurus Komunikasi Cisco Unified untuk URI mereka, yang mungkin terdapat dalam infrastruktur anda atau mungkin ada. Atau domain example.com sepadan dengan domain yang sama yang digunakan pengguna untuk alamat e-mel mereka. Atau klien Jabber pada komputer riba anda mungkin mempunyai URI [e-mel dilindungi]. Domain conf.example.com ialah domain yang akan dikonfigurasikan untuk pengguna Cisco Meeting Server. Domain Cisco Meeting Server akan menjadi conf.example.com, jadi pengguna Jabber yang sama perlu menggunakan pengguna URI@ untuk log masuk ke Cisco Meeting Serverconf.example.com.

Konfigurasi asas

Semua tetapan yang diterangkan di bawah ditunjukkan pada satu pelayan, tetapi ia perlu dilakukan pada setiap pelayan dalam kelompok.

QoS

Sejak CMS menjana masa sebenar trafik yang sensitif kepada kelewatan dan kehilangan paket, dalam kebanyakan kes adalah disyorkan untuk mengkonfigurasi kualiti perkhidmatan (QoS). Untuk melakukan ini, CMS menyokong penandaan paket dengan kod perkhidmatan dibezakan (DSCP) yang dijananya. Walaupun keutamaan trafik berasaskan DSCP bergantung pada cara trafik dikendalikan oleh komponen rangkaian infrastruktur anda, dalam kes kami, kami akan mengkonfigurasi CMS kami dengan keutamaan DSCP biasa berdasarkan amalan terbaik QoS.

Pada setiap pelayan, masukkan arahan ini

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

Jadi semua trafik video telah ditag AF41 (DSCP 0x22), semua trafik suara telah ditag EF (DSCP 0x2E), trafik kependaman rendah lain seperti SIP dan XMPP menggunakan AF31 (DSCP 0x1A).

Kami menyemak:

NTP

Protokol Masa Rangkaian (NTP) adalah penting bukan sahaja untuk menyediakan cap masa yang tepat untuk panggilan dan persidangan, tetapi juga untuk mengesahkan sijil.

Tambahkan pelayan NTP pada infrastruktur anda dengan arahan seperti

ntp server add <server>

Dalam kes kami, terdapat dua pelayan sedemikian, jadi akan ada dua pasukan.
Kami menyemak:

Dan tetapkan zon waktu untuk pelayan kami

DNS

Pelayan DNS ditambahkan pada CMS dengan arahan seperti:

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

Dalam kes kami, terdapat dua pelayan sedemikian, jadi akan ada dua pasukan.
Kami menyemak:

Konfigurasi antara muka rangkaian

Kami mengkonfigurasi antara muka dengan arahan borang:

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

Kami menyemak:

Nama pelayan(nama hos)

Nama pelayan ditetapkan dengan arahan borang:

hostname <name>

Dan kami but semula.

Ini melengkapkan konfigurasi asas.

Sijil

TeoriCisco Meeting Server memerlukan komunikasi yang disulitkan antara pelbagai komponen, dan sebagai hasilnya, sijil X.509 diperlukan untuk semua penggunaan CMS. Mereka membantu memastikan perkhidmatan/pelayan itu dipercayai oleh pelayan/perkhidmatan lain.

Setiap perkhidmatan memerlukan sijil, tetapi membuat sijil berasingan untuk setiap perkhidmatan boleh mengelirukan dan terlalu rumit. Nasib baik, kami boleh menjana pasangan kunci awam/peribadi sijil dan kemudian menggunakannya semula merentas berbilang perkhidmatan. Dalam kes kami, sijil yang sama akan digunakan untuk Call Bridge, XMPP Server, Web Bridge dan Web Admin. Oleh itu, anda perlu membuat sijil pasangan kunci awam dan peribadi untuk setiap pelayan dalam kluster.

Pengelompokan pangkalan data, bagaimanapun, mempunyai beberapa keperluan sijil khas dan oleh itu memerlukan sijilnya sendiri, yang berbeza daripada perkhidmatan lain. CMS menggunakan sijil pelayan, yang serupa dengan sijil yang digunakan oleh pelayan lain, tetapi terdapat juga sijil klien yang digunakan untuk sambungan pangkalan data. Sijil pangkalan data digunakan untuk kedua-dua pengesahan dan penyulitan. Daripada menyediakan nama pengguna dan kata laluan untuk pelanggan menyambung ke pangkalan data, ia memberikan sijil pelanggan yang dipercayai pelayan. Setiap pelayan dalam kluster pangkalan data akan menggunakan pasangan kunci awam/peribadi yang sama. Ini membolehkan semua pelayan dalam kluster menyulitkan data supaya ia hanya boleh dinyahsulit oleh pelayan lain yang juga menggunakan pasangan kunci yang sama.

Untuk lebihan berfungsi, kluster pangkalan data mesti terdiri daripada sekurang-kurangnya 3 pelayan, sehingga maksimum 5, dengan masa perjalanan pergi balik maksimum 200ms antara mana-mana ahli kluster. Had ini lebih terhad daripada pengelompokan Call Bridge, jadi ia selalunya menjadi faktor pengehad dalam penyebaran geografi.

Peranan pangkalan data untuk CMS mempunyai beberapa keperluan unik. Tidak seperti peranan lain, ia memerlukan sijil pelanggan dan pelayan, di mana sijil pelanggan mempunyai medan CN khusus yang dibentangkan kepada pelayan.

CMS menggunakan pangkalan data postgres dengan satu induk dan beberapa replika yang sama. Terdapat hanya satu pangkalan data induk pada bila-bila masa ("pelayan pangkalan data"). Selebihnya ahli kluster adalah replika atau "pelanggan pangkalan data".

Kelompok pangkalan data memerlukan sijil pelayan khusus dan sijil pelanggan. Mereka mesti ditandatangani dengan sijil, biasanya CA persendirian dalaman. Memandangkan mana-mana ahli kluster pangkalan data boleh menjadi tuan, pelayan pangkalan data dan pasangan sijil pelanggan (mengandungi kunci awam dan peribadi) mesti disalin ke semua pelayan supaya mereka boleh menganggap identiti klien atau pelayan pangkalan data. Di samping itu, sijil CA akar mesti dimuatkan untuk memastikan sijil pelanggan dan pelayan boleh disahkan.

Jadi, kami membentuk permintaan untuk sijil yang akan digunakan oleh semua perkhidmatan pelayan dengan pengecualian pangkalan data (akan ada permintaan berasingan untuk ini) dengan arahan seperti:

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

Dalam CN kami menulis nama umum pelayan kami. Contohnya, jika nama hos pelayan kami server01, server02, server03, maka CN akan menjadi server.example.com

Kami melakukan perkara yang sama pada dua pelayan yang tinggal dengan perbezaan bahawa arahan akan mengandungi "nama hos" yang sepadan

Kami membentuk dua permintaan untuk sijil yang akan digunakan oleh perkhidmatan pangkalan data dengan arahan borang:

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

pki csr dbclusterclient CN:postgres

mana dbclusterserver и dbclusterclient nama permintaan kami dan sijil masa hadapan, nama hos1(2)(3) nama pelayan masing-masing.

Kami melaksanakan prosedur ini hanya pada satu pelayan (!), dan kami akan memuat naik sijil dan fail .key-yang sepadan ke pelayan lain.

Dayakan mod sijil pelanggan dalam AD CS

Anda juga perlu menggabungkan sijil untuk setiap pelayan ke dalam satu failPada *NIX:

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

Pada Windows/DOS:

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

Dan muat naik ke setiap pelayan:
1. Sijil pelayan "Individu".
2. Sijil akar (bersama-sama dengan sijil perantaraan, jika ada).
3. Sijil untuk pangkalan data ("pelayan" dan "klien") dan fail dengan sambungan .key, yang dijana semasa membuat permintaan untuk sijil "pelayan" dan "klien" pangkalan data. Fail ini mestilah sama pada semua pelayan.
4. Fail ketiga-tiga sijil "individu".

Akibatnya, lebih kurang gambar fail yang sama harus diperoleh pada setiap pelayan.

Kluster Pangkalan Data

Memandangkan anda mempunyai semua sijil yang dimuat naik ke pelayan CMS, anda boleh menyediakan dan mendayakan pengelompokan pangkalan data merentas tiga nod. Langkah pertama ialah memilih satu pelayan sebagai nod induk kluster pangkalan data dan mengkonfigurasinya sepenuhnya.

Pangkalan Data Induk

Langkah pertama dalam menyediakan replikasi pangkalan data ialah menentukan sijil yang akan digunakan untuk pangkalan data. Ini dilakukan dengan arahan seperti:

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

Sekarang mari beritahu CMS antara muka yang hendak digunakan untuk pengelompokan pangkalan data dengan arahan:

database cluster localnode a

Kemudian kami memulakan pangkalan data kluster pada pelayan utama dengan arahan:

database cluster initialize

Nod Pangkalan Data Pelanggan

Kami melakukan prosedur yang sama, hanya bukannya arahan kluster pangkalan data memulakan masukkan arahan seperti:

database cluster join <ip address existing master>

di mana alamat ip alamat ip induk sedia ada pelayan CMS di mana kluster dimulakan, hanya Master.

Kami menyemak cara kluster pangkalan data kami berfungsi pada semua pelayan dengan arahan:

database cluster status

Kami melakukan perkara yang sama pada pelayan ketiga yang tinggal.

Hasilnya, ternyata pelayan pertama kami adalah Master, selebihnya adalah Hamba.

Perkhidmatan Pentadbiran Web

Dayakan perkhidmatan pentadbir web:

webadmin listen a 445

Port 445 dipilih kerana port 443 digunakan untuk akses pengguna kepada klien web

Kami mengkonfigurasi perkhidmatan Pentadbir Web dengan fail sijil dengan arahan seperti:

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

Dan dayakan Pentadbir Web dengan arahan:

webadmin enable

Jika semuanya baik, kami akan mendapat baris SUCCESS yang menunjukkan bahawa Pentadbir Web dikonfigurasikan dengan betul untuk rangkaian dan sijil. Kami menyemak kesihatan perkhidmatan menggunakan pelayar web dan masukkan alamat pentadbir web, contohnya: cms.example.com: 445

Panggil Kluster Jambatan

Call Bridge ialah satu-satunya perkhidmatan yang ada dalam setiap penggunaan CMS. Call Bridge ialah mekanisme persidangan utama. Ia juga menyediakan antara muka SIP supaya panggilan boleh dihalakan ke atau daripadanya, seperti oleh Cisco Unified CM.

Perintah yang diterangkan di bawah mesti dijalankan pada setiap pelayan dengan sijil yang sesuai.
Jadi:

Kaitkan sijil dengan perkhidmatan Call Bridge dengan arahan seperti:

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

Kami mengikat perkhidmatan CallBridge ke antara muka yang kami perlukan dengan arahan:

callbridge listen a

Dan mulakan semula perkhidmatan dengan arahan:

callbridge restart

Memandangkan kami telah mengkonfigurasi Jambatan Panggilan, kami boleh menyediakan pengelompokan Jambatan Panggilan. Pengelompokan Call Bridge berbeza daripada pengelompokan pangkalan data atau XMPP. Call Bridge Cluster boleh menyokong 2 hingga 8 nod tanpa sebarang had. Ia menyediakan bukan sahaja redundansi, tetapi juga pengimbangan beban, supaya persidangan boleh diedarkan secara aktif antara pelayan Call Bridge menggunakan pengedaran panggilan pintar. CMS mempunyai ciri tambahan, kumpulan Call Bridge dan ciri berkaitan yang boleh digunakan untuk pengurusan selanjutnya.

Pengelompokan jambatan panggilan dikonfigurasikan terutamanya melalui antara muka pentadbir web
Prosedur berikut mesti dijalankan pada setiap pelayan kluster.
Oleh itu,

1. Kami pergi melalui web dalam Configuration> Cluster.
2.Dalam panggil identiti jambatan sebagai nama unik, masukkan callbridge[01,02,03] sepadan dengan nama pelayan. Nama-nama ini adalah sewenang-wenangnya, tetapi mesti unik untuk kelompok ini. Ia bersifat deskriptif kerana ia menunjukkan bahawa ia adalah ID pelayan [01,02,03].
3.B Jambatan Panggilan Berkelompok masukkan URL pentadbir web pelayan kami dalam kelompok, cms[01,02,03].example.com:445, dalam medan Alamat. Pastikan untuk menentukan pelabuhan. Anda boleh membiarkan domain SIP pautan rakan sebaya kosong.
4. Kami menambah sijil kepada kepercayaan CallBridge untuk setiap pelayan, fail yang mengandungi semua sijil pelayan kami yang kami gabungkan ke dalam fail ini pada mulanya, dengan arahan seperti:

callbridge trust cluster <trusted cluster certificate bundle>

Dan mulakan semula perkhidmatan dengan arahan:

callbridge restart

Akibatnya, pada setiap pelayan anda akan mendapat gambar berikut:

Kluster XMPP

Perkhidmatan XMPP dalam CMS digunakan untuk mengendalikan semua pendaftaran dan pengesahan untuk Cisco Meeting Apps (CMA), termasuk Klien Web CMA WebRTC. Jambatan Panggilan itu sendiri juga bertindak sebagai pelanggan XMPP untuk tujuan pengesahan dan oleh itu mesti dikonfigurasikan seperti pelanggan lain. Failover XMPP ialah ciri yang telah disokong dalam persekitaran pengeluaran sejak versi 2.1

Perintah yang diterangkan di bawah mesti dijalankan pada setiap pelayan dengan sijil yang sesuai.
Jadi:

Kaitkan sijil dengan perkhidmatan XMPP dengan arahan seperti:

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

Kemudian tentukan antara muka mendengar dengan arahan:

xmpp listen a

Perkhidmatan XMPP memerlukan domain yang unik. Ini adalah log masuk untuk pengguna. Dalam erti kata lain, apabila pengguna cuba log masuk menggunakan apl CMA (atau melalui klien WebRTC), mereka memasukkan userID@logindomain. Dalam kes kami ia akan menjadi userid@conf.example.com. Mengapa ia bukan sahaja example.com? Dalam penggunaan khusus kami, kami memilih domain Unified CM kami yang akan digunakan oleh pengguna Jabber dalam Unified CM sebagai example.com, jadi kami memerlukan domain yang berbeza untuk pengguna CMS menghalakan panggilan ke dan dari CMS melalui domain SIP.

Sediakan domain XMPP dengan arahan seperti:

xmpp domain <domain>

Dan dayakan perkhidmatan XMPP dengan arahan:

xmpp enable

Dalam perkhidmatan XMPP, anda mesti mencipta kelayakan untuk setiap Call Bridge yang akan digunakan semasa mendaftar dengan perkhidmatan XMPP. Nama-nama ini adalah sewenang-wenangnya (dan tidak berkaitan dengan nama unik yang anda konfigurasikan untuk pengelompokan jambatan panggilan). Anda mesti menambah tiga jambatan panggilan pada satu pelayan XMPP dan kemudian masukkan bukti kelayakan ini pada pelayan XMPP lain dalam kelompok kerana konfigurasi ini tidak sesuai dengan pangkalan data kelompok. Kemudian, kami akan mengkonfigurasi setiap Call Bridge untuk menggunakan nama dan rahsia ini untuk mendaftar dengan perkhidmatan XMPP.

Sekarang kita perlu menyediakan perkhidmatan XMPP pada pelayan pertama dengan tiga Call Bridges callbridge01, callbridge02 dan callbridge03. Setiap akaun akan diberikan kata laluan rawak. Kemudian, mereka akan dimasukkan pada pelayan Call Bridge lain untuk log masuk ke pelayan XMPP ini. Masukkan arahan berikut:

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

Akibatnya, kami menyemak apa yang berlaku dengan arahan:

xmpp callbridge list

Gambar yang sama sepatutnya ada pada pelayan lain selepas langkah yang diterangkan di bawah.

Seterusnya, kami menambah tetapan yang sama pada baki dua pelayan, hanya dengan arahan

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

Kami menambah Rahsia dengan sangat berhati-hati supaya ruang tambahan tidak secara tidak sengaja masuk ke dalamnya, sebagai contoh.

Akibatnya, setiap pelayan harus mempunyai gambar yang sama:

Seterusnya, pada semua pelayan kluster, kami menentukan secara amanah fail yang mengandungi ketiga-tiga sijil, yang dibuat lebih awal dengan arahan borang:

xmpp cluster trust <trust bundle>

Dayakan mod kluster xmpp pada semua pelayan kluster dengan arahan:

xmpp cluster enable

Pada pelayan pertama kluster, kami memulakan penciptaan kluster xmpp dengan arahan:

xmpp cluster initialize

Pada pelayan lain, kami menambah kluster ke xmpp dengan arahan seperti:

xmpp cluster join <ip address head xmpp server>

Pada setiap pelayan, kami menyemak kejayaan mencipta kluster XMPP pada setiap pelayan dengan arahan:

xmpp status
xmpp cluster status

Pelayan pertama:

Pelayan kedua:

Pelayan ketiga:

Menyambungkan Call Bridge ke XMPP

Memandangkan kluster XMPP sedang aktif dan berjalan, kita perlu mengkonfigurasi perkhidmatan Call Bridge untuk menyambung ke kluster XMPP. Konfigurasi ini dilakukan melalui pentadbir web.

Kami pergi pada setiap pelayan dalam Konfigurasi> Umum dan di lapangan Nama Jambatan Panggilan yang unik kami menulis nama unik Jambatan Panggilan yang sepadan dengan pelayan callbridge[01,02,03]... Di ladang domain conf.example.ru dan kata laluan yang sepadan, anda boleh mengintipnya
pada mana-mana pelayan kluster dengan arahan:

xmpp callbridge list

Biarkan medan "Pelayan" kosong. callbridge akan melakukan carian DNS SRV untuk _xmpp-component._tcp.conf.example.comuntuk mencari pelayan XMPP yang tersedia. Alamat IP untuk menyambungkan jambatan panggilan ke XMPP mungkin berbeza pada setiap pelayan, ia bergantung pada nilai yang dikembalikan kepada permintaan tulis _xmpp-component._tcp.conf.example.com callbridge, yang seterusnya bergantung pada tetapan keutamaan untuk rekod DNS ini.

Seterusnya, pergi ke Status > Umum untuk melihat sama ada perkhidmatan Call Bride berjaya disambungkan ke perkhidmatan XMPP.

jambatan web

Pada setiap pelayan kluster, dayakan perkhidmatan Jambatan Web dengan arahan:

webbridge listen a:443

Kami mengkonfigurasi perkhidmatan Jambatan Web dengan fail sijil dengan arahan seperti:

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

Jambatan Web menyokong HTTPS. Ia akan mengubah hala HTTP ke HTTPS jika dikonfigurasikan untuk menggunakan "http-redirect".
Untuk mendayakan pengalihan HTTP, gunakan arahan berikut:

webbridge http-redirect enable

Untuk memberitahu Call Bridge bahawa Web Bridge boleh dipercayai untuk sambungan daripada Call Bridge, gunakan arahan:

webbridge trust <certfile>

di manakah fail yang mengandungi ketiga-tiga sijil daripada setiap pelayan dalam kluster.

Gambar sedemikian hendaklah pada setiap pelayan kluster.

Sekarang kita perlu mencipta pengguna dengan peranan "appadmin", kita memerlukannya supaya kita boleh mengkonfigurasi kluster kita (!), Dan bukan setiap pelayan kluster secara berasingan, jadi tetapan akan digunakan secara sama rata pada setiap pelayan, walaupun mereka akan dibuat sekali.

Untuk penyesuaian selanjutnya, kami akan gunakan Postman.

Untuk kebenaran, pilih Asas dalam bahagian Kebenaran

Untuk menghantar arahan dengan betul kepada pelayan CMS, anda perlu menetapkan pengekodan yang dikehendaki

Tentukan Webbridge dengan arahan SELEPAS dengan parameter url dan makna cms.example.com

Dalam jambatan web itu sendiri, kami menentukan parameter yang kami perlukan: akses tetamu, akses selamat dan sebagainya.

Panggil Kumpulan Jambatan

Secara lalai, CMS tidak selalu menggunakan sepenuhnya sumber persidangan yang tersedia untuknya.

Sebagai contoh, untuk mesyuarat dengan tiga peserta, setiap peserta mungkin berada di tiga Call Bridge'ax yang berbeza. Untuk membolehkan ketiga-tiga peserta ini berkomunikasi antara satu sama lain, Call Bridges secara automatik akan mewujudkan sambungan antara semua pelayan dan pelanggan dalam Ruang yang sama, supaya semuanya kelihatan seperti semua pelanggan berada pada pelayan yang sama. Malangnya, kelemahan ini ialah satu persidangan 3 orang kini akan menggunakan 9 port media. Ini jelas merupakan penggunaan sumber yang tidak cekap. Selain itu, apabila Jambatan Panggilan benar-benar sesak, mekanisme lalai adalah untuk terus menerima panggilan dan menyediakan perkhidmatan berkualiti rendah kepada semua pelanggan Jambatan Panggilan itu.

Masalah ini diselesaikan menggunakan ciri Call Bridge Group. Ciri ini telah diperkenalkan dalam versi 2.1 Cisco Meeting Server Software dan telah diperluaskan untuk menyokong pengimbangan beban untuk kedua-dua panggilan masuk dan keluar, Cisco Meeting App (CMA), termasuk peserta WebRTC.

Untuk menyelesaikan masalah penyambungan semula, tiga had beban boleh dikonfigurasikan telah diperkenalkan untuk setiap Jambatan Panggilan:

had beban ialah beban berangka maksimum untuk Jambatan Panggilan tertentu. Setiap platform mempunyai had beban yang disyorkan, seperti 96000 untuk CMS1000 dan 1.25 GHz setiap pemproses maya untuk mesin maya. Panggilan yang berbeza menggunakan sejumlah sumber bergantung pada resolusi peserta dan kadar bingkai.
NewConferenceLoadLimitBasisPoints (lalai 50% loadLimit) - menetapkan had beban pelayan selepas itu persidangan baharu ditolak.
Konferensi Sedia AdaLoadLimitBasisPoints (lalai 80% daripada loadLimit) - Nilai beban pelayan selepas itu peserta menyertai persidangan sedia ada akan ditolak.

Walaupun ciri ini direka bentuk untuk pengedaran panggilan dan pengimbangan beban, kumpulan lain seperti pelayan TURN, pelayan Jambatan Web dan perakam juga boleh diberikan kepada Kumpulan Jambatan Panggilan supaya mereka juga boleh dikumpulkan dengan betul untuk kegunaan optimum. Jika mana-mana objek ini tidak diberikan kepada kumpulan panggilan, ia diandaikan tersedia untuk semua pelayan tanpa sebarang keutamaan tertentu.

Tetapan ini dikonfigurasikan di sini: cms.example.com:445/api/v1/system/configuration/cluster

Seterusnya, kami menunjukkan kepada setiap callbridge yang tergolong dalam kumpulan callbridge:

Jambatan panggilan pertama

Jambatan panggilan kedua

Jambatan panggilan ketiga

Oleh itu, kami mengkonfigurasi kumpulan Call Brdige untuk menggunakan sumber kluster Pelayan Mesyuarat Cisco dengan lebih cekap.

Mengimport pengguna daripada Active Directory

Perkhidmatan Pentadbir Web mempunyai bahagian konfigurasi LDAP, tetapi ia tidak menyediakan pilihan konfigurasi yang kompleks dan maklumat tidak disimpan dalam pangkalan data kluster, jadi konfigurasi perlu dilakukan, sama ada secara manual pada setiap pelayan melalui antara muka Web, atau melalui API, dan supaya kami "tiga kali tidak bangun "kami masih akan menetapkan data melalui API.

Menggunakan URL untuk mengakses cms01.example.com:445/api/v1/ldapServers mencipta objek LDAP Server, menentukan parameter seperti:

IP pelayan
nombor port
nama pengguna
kata laluan
mendapatkan

Selamat - benar atau salah bergantung pada port, 389 - tidak selamat, 636 - selamat.

Memetakan Pilihan Sumber LDAP kepada Atribut dalam Pelayan Mesyuarat Cisco.
Pemetaan LDAP memetakan atribut dalam direktori LDAP kepada atribut dalam CMS. Sebenarnya atribut:

jidMapping
pemetaan nama
coSpaceNameMapping
coSpaceUriMapping
coSpaceSecondaryUriMapping

Penerangan tentang sifatJID mewakili ID log masuk pengguna dalam CMS. Memandangkan ini ialah pelayan LDAP Microsoft Active Directory, CMS JID memetakan ke sAMAccountName dalam LDAP, yang pada asasnya ialah ID log masuk Active Directory pengguna. Juga ambil perhatian bahawa anda mengambil sAMAccountName dan menambah domain conf.pod6.cms.lab pada penghujungnya kerana itu adalah log masuk yang akan digunakan pengguna anda untuk log masuk ke CMS.

pemetaan nama memetakan apa yang terkandung dalam medan Active Directory displayName ke medan nama CMS pengguna.

coSpaceNameMapping mencipta ruang'a nama CMS berdasarkan medan paparanName. Atribut ini, bersama-sama dengan atribut coSpaceUriMapping, adalah perkara yang diperlukan untuk mencipta ruang untuk setiap pengguna.

coSpaceUriMapping mentakrifkan bahagian pengguna URI yang dikaitkan dengan ruang peribadi pengguna. Sesetengah domain boleh dikonfigurasikan untuk ditetapkan kepada ruang. Jika bahagian pengguna sepadan dengan medan ini untuk salah satu domain ini, panggilan akan dihalakan ke ruang pengguna tersebut.

coSpaceSecondaryUriMapping menentukan URI kedua untuk mencapai ruang. Ini boleh digunakan untuk menambah alias berangka untuk menghalakan panggilan ke ruang pengguna yang diimport sebagai alternatif kepada URI alfanumerik yang dinyatakan dalam parameter coSpaceUriMapping.

Pelayan LDAP dan pemetaan LDAP dikonfigurasikan. Sekarang kita perlu memautkannya bersama-sama dengan mencipta sumber LDAP.

Menggunakan URL untuk mengakses cms01.example.com:445/api/v1/ldapSource mencipta objek Sumber LDAP, menentukan parameter seperti:

server
pemetaan
asasDn
menapis

Setelah persediaan LDAP selesai, anda boleh melakukan operasi penyegerakan manual.

Kami melakukan ini sama ada dalam antara muka Web setiap pelayan dengan mengklik Segerakkan sekarang seksyen Active Directory

atau melalui arahan API SELEPAS menggunakan URL untuk mengakses cms01.example.com:445/api/v1/ldapSyncs

Persidangan ad hoc

Apakah ini?Dalam konsep tradisional persidangan, ini adalah apabila dua peserta bercakap antara satu sama lain, dan salah seorang peserta (menggunakan peranti yang didaftarkan dalam Unified CM) menekan butang "Persidangan", memanggil orang lain, dan selepas bercakap dengan ketiga ini parti, tekan butang "Persidangan" sekali lagi untuk menyertai semua peserta dalam persidangan tiga pihak.

Perbezaan antara persidangan Ad-Hoc dan persidangan CMS yang dijadualkan ialah persidangan Ad-Hoc bukan sekadar panggilan SIP kepada CMS. Apabila pemula persidangan mengklik butang Persidangan kali kedua untuk menjemput semua orang ke mesyuarat yang sama, CM Bersepadu mesti membuat panggilan API kepada CMS untuk membuat persidangan segera, yang kemudiannya semua panggilan dipindahkan. Semua ini berlaku secara tidak kelihatan kepada peserta.

Ini bermakna Unified CM mesti mengkonfigurasi bukti kelayakan API dan alamat/port perkhidmatan WebAdmin, serta SIP Trunk terus ke pelayan CMS untuk meneruskan panggilan.

Jika perlu, CUCM boleh mencipta ruang dalam CMS secara dinamik supaya setiap panggilan boleh mencapai CMS dan sepadan dengan peraturan panggilan masuk yang bertujuan untuk ruang.

Integrasi dengan CUCM dikonfigurasikan dengan cara yang sama seperti yang diterangkan dalam artikel sebelum ini kecuali pada Cisco UCM anda perlu mencipta tiga batang untuk CMS, tiga Jambatan Persidangan, nyatakan tiga Nama Subjek dalam Profil Keselamatan SIP, Kumpulan Laluan, Senarai Laluan, Kumpulan Sumber Media dan Senarai Kumpulan Sumber Media, dan tambah beberapa peraturan penghalaan ke Cisco Pelayan Mesyuarat.

Profil Keselamatan SIP:

Batang:

Setiap batang kelihatan sama:

Jambatan Persidangan

Setiap Jambatan Persidangan kelihatan sama:

Kumpulan Laluan

Senarai Laluan

Kumpulan Sumber Media

Senarai Kumpulan Sumber Media

Peraturan panggilan

Tidak seperti sistem kawalan panggilan yang lebih maju seperti Unified CM atau Expressway, untuk panggilan baharu, CMS hanya mencari domain dalam medan SIP Request-URI. Jadi jika SIP INVITE adalah untuk menghirup: [e-mel dilindungi], CMS hanya mengambil berat tentang domain.com. CMS mengikut peraturan ini untuk menentukan tempat untuk menghalakan panggilan:

1. Pertama, CMS cuba memetakan domain SIP kepada domain yang dikonfigurasikan dalam peraturan pengendalian panggilan masuk. Panggilan ini kemudiannya boleh dihalakan ke ruang ("sasaran") atau pengguna tertentu, IVR dalaman atau destinasi Microsoft Lync/Skype for Business (S4B) bersepadu secara langsung.
2. Jika tiada padanan dalam peraturan pengendalian panggilan masuk, CMS akan cuba memadankan domain yang dikonfigurasikan dalam jadual pemajuan panggilan. Jika perlawanan diwujudkan, peraturan boleh menolak panggilan secara eksplisit atau mengubah hala panggilan. Pada masa ini, CMS mungkin menulis semula domain, yang kadangkala berguna untuk memanggil domain Lync. Anda juga boleh memilih untuk melepasi lontaran, yang bermaksud tiada satu pun medan akan diubah lagi atau menggunakan pelan dail CMS dalaman. Jika tiada padanan dalam peraturan pemajuan panggilan, penolakan panggilan digunakan secara lalai. Harap maklum bahawa dalam CMS, walaupun panggilan "dimajukan", media masih terikat kepada CMS, yang bermaksud ia akan berada dalam laluan isyarat dan trafik media.
Kemudian hanya panggilan yang dimajukan tertakluk pada peraturan panggilan keluar. Tetapan ini menentukan destinasi tempat panggilan dihantar, jenis batang (sama ada panggilan Lync baharu atau SIP standard) dan sebarang terjemahan yang boleh dilakukan jika pemindahan tidak dipilih dalam peraturan pemajuan panggilan.

Berikut ialah log sebenar perkara yang berlaku semasa persidangan Ad-Hoc

Tangkapan skrin menunjukkan kurang baik (saya tidak tahu cara melakukannya dengan lebih baik), jadi saya akan menulis log seperti ini:

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

Persidangan Ad-Hoc itu sendiri:

Peraturan panggilan masuk
Mengkonfigurasi tetapan panggilan masuk diperlukan untuk dapat menerima panggilan dalam CMS. Seperti yang anda lihat dalam persediaan LDAP, semua pengguna telah diimport dengan domain conf.pod6.cms.lab. Jadi sekurang-kurangnya, anda mahukan panggilan ke domain ini untuk menyasarkan ruang. Anda juga perlu menyediakan peraturan untuk apa-apa sahaja untuk FQDN (dan mungkin juga alamat IP) bagi setiap pelayan CMS. Kawalan panggilan luaran kami, Unified CM, akan menyediakan batang SIP khusus untuk setiap pelayan CMS secara individu. Sama ada destinasi batang SIP ini ialah alamat IP atau FQDN pelayan akan menentukan sama ada CMS perlu dikonfigurasikan untuk menerima panggilan yang diarahkan ke alamat IP atau FQDNnya.

Domain yang mempunyai peraturan masuk keutamaan tertinggi digunakan sebagai domain untuk mana-mana ruang pengguna. Apabila pengguna menyegerak melalui LDAP, CMS mencipta ruang secara automatik, tetapi hanya bahagian pengguna URI (coSpaceUriMapping), seperti user.space. Bahagian domain URI penuh dijana berdasarkan peraturan ini. Malah, jika anda melog masuk ke Web Bridge pada ketika ini, anda akan melihat bahawa Space URI tidak mempunyai domain. Dengan menetapkan peraturan ini sebagai keutamaan tertinggi, anda menetapkan domain untuk ruang yang dijana conf.example.com.

Peraturan panggilan keluar

Untuk membenarkan pengguna membuat panggilan keluar ke kluster CM Bersepadu, anda mesti mengkonfigurasi peraturan keluar. Domain titik akhir yang didaftarkan dengan Unified CM, seperti Jabber, ialah example.com. Panggilan ke domain ini harus dihalakan sebagai panggilan SIP standard ke nod pemprosesan panggilan CM Bersepadu. Pelayan utama ialah cucm-01.example.com dan pelayan kedua ialah cucm-02.example.com.

Peraturan pertama menerangkan penghalaan panggilan paling mudah antara pelayan kluster.

Bidang Tempatan daripada domain bertanggungjawab untuk apa yang akan dipaparkan dalam SIP-URI pemanggil orang yang dipanggil selepas simbol "@". Jika kita biarkan kosong, maka selepas simbol "@" akan terdapat alamat ip CUCM'a yang melaluinya panggilan ini. Jika kita menentukan domain, maka selepas simbol "@", sebenarnya akan ada domain. Ini adalah perlu untuk dapat membuat panggilan semula, jika tidak, anda tidak akan dapat memanggil semula menggunakan nama@ip-address SIP-URI.

Panggil apabila ditunjukkan Tempatan daripada domain

hubungi bila TIDAK ditunjukkan Tempatan daripada domain

Pastikan anda menyatakan secara eksplisit Encrypted atau Unencrypted untuk panggilan keluar, kerana tiada apa yang berfungsi dengan parameter Auto.

Rakaman

Persidangan video dirakam oleh Pelayan Rakam. Perakam adalah Pelayan Mesyuarat Cisco yang sama. Perakam tidak memerlukan sebarang lesen dipasang pada dirinya sendiri. Lesen rakaman diperlukan untuk pelayan yang menjalankan perkhidmatan CallBridge, i.e. Lesen Rakaman diperlukan dan mesti digunakan pada komponen CallBridge, bukan pada pelayan yang menjalankan Perakam. Perakam berkelakuan seperti pelanggan Extensible Messaging and Presence Protocol (XMPP), jadi pelayan XMPP mesti didayakan pada pelayan yang mengehos CallBridge.

Kerana kami mempunyai kluster dan lesen perlu "diregangkan" kepada ketiga-tiga pelayan kluster. Kemudian hanya dalam akaun peribadi dalam lesen yang kami kaitkan (menambah) alamat MAC antara muka-a semua pelayan CMS yang disertakan dalam kelompok.

Dan gambar ini sepatutnya ada pada setiap pelayan kluster

Secara umum, terdapat beberapa senario untuk meletakkan Perakam, tetapi kami akan berpegang pada ini:

Sebelum menyediakan Perakam, anda perlu menyediakan tempat di mana persidangan video sebenarnya akan dirakam. Sebenarnya di sini pautanbagaimana untuk menyediakan keseluruhan Rakaman. Saya akan memberi tumpuan kepada perkara dan butiran penting:

1. Adalah lebih baik untuk melepaskan sijil dari pelayan pertama dalam kelompok.
2. Ralat "Recorder unavailable" mungkin berlaku kerana sijil yang salah dinyatakan dalam Amanah Perakam.
3. Tulisan mungkin tidak berfungsi jika tulis yang ditentukan bukan direktori akar dalam NFS.

Kadangkala terdapat keperluan untuk merakam persidangan secara automatik bagi satu pengguna atau ruang tertentu.

Untuk ini, dua CallProfiles dicipta:
Dengan fungsi rakaman dilumpuhkan

Dan dengan fungsi rakaman automatik

Selanjutnya ke ruang yang diperlukan kami "mengikat" CallProfile dengan fungsi rekod automatik.

Dalam CMS, ia telah ditetapkan bahawa jika CallProfile diikat secara eksplisit pada beberapa ruang atau ruang, maka CallProfile ini hanya berfungsi untuk ruang khusus ini. Dan jika CallProfile tidak terikat pada mana-mana ruang, maka secara lalai ia digunakan pada ruang yang tiada CallProfile terikat secara eksplisit.

Lain kali saya akan cuba menerangkan cara CMS diakses di luar rangkaian dalaman organisasi.

Sumber:

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

Sumber: www.habr.com

Cisco Meeting Server 2.5.2. Kelompok dalam mod Boleh Skala dan Berdaya Tahan dengan rakaman persidangan video