Cisco Meeting Server 2.5.2. Cluster sa Scalable at Resilient mode na may function ng pag-record ng video conference

Sa isyung ito ay ipapakita at ipaliwanag ko ang ilan sa mga intricacies ng pagse-set up ng isang CMS server sa failover cluster mode.


ТеорияSa pangkalahatan, mayroong tatlong uri ng pag-deploy ng CMS server:

• Single Pinagsama(Single na pinagsama), i.e. isa itong server kung saan tumatakbo ang lahat ng kinakailangang serbisyo. Sa karamihan ng mga kaso, ang ganitong uri ng deployment ay angkop lamang para sa panloob na pag-access ng kliyente at sa mas maliliit na kapaligiran kung saan ang scalability at redundancy na mga limitasyon ng isang server ay hindi isang kritikal na isyu, o sa mga sitwasyon kung saan ang CMS ay gumaganap lamang ng ilang mga function, tulad ng ad hoc mga kumperensya sa Cisco UCM.

  Tinatayang scheme ng trabaho:
  

• Single Split(Single Split) pinalawak ang nakaraang uri ng deployment sa pamamagitan ng pagdaragdag ng hiwalay na server para sa panlabas na pag-access. Sa mga legacy na deployment, nangangahulugan ito ng pag-deploy ng CMS server sa isang demilitarized network segment (DMZ) kung saan maa-access ito ng mga external na kliyente, at isang CMS server sa network core kung saan maa-access ng mga internal na kliyente ang CMS. Ang partikular na modelo ng pag-deploy na ito ay pinapalitan na ngayon ng tinatawag na uri Single Edge, na binubuo ng mga server Cisco Expressway, na maaaring mayroon o magkakaroon ng marami sa parehong mga kakayahan sa pag-bypass ng Firewall kaya hindi na kailangan ng mga kliyente na magdagdag ng nakalaang edge na CMS server.

  Tinatayang scheme ng trabaho:
  

• Nasusukat at nababanat(Scalable at Fault Tolerant) Kasama sa uri na ito ang redundancy para sa bawat component, na nagpapahintulot sa system na lumago kasama ng iyong mga pangangailangan sa pinakamataas na kapasidad nito habang nagbibigay ng redundancy kung sakaling mabigo. Ginagamit din nito ang konsepto ng Single Edge para magbigay ng secure na external na access. Ito ang tipong titingnan natin sa episode na ito. Kung nauunawaan namin kung paano i-deploy ang ganitong uri ng cluster, hindi lang namin mauunawaan ang iba pang mga uri ng deployment, ngunit mauunawaan din namin kung paano gumawa ng mga cluster ng CMS server para ma-accommodate ang potensyal na paglaki ng demand.

Bago lumipat sa pag-deploy, kailangan mong maunawaan ang ilang mga pangunahing bagay, lalo

Mga pangunahing bahagi ng software ng CMS:

• Database: Binibigyang-daan kang pagsamahin ang ilang configuration, gaya ng dial plan, mga puwang ng user, at mga user mismo. Sinusuportahan ang clustering para sa mataas na kakayahang magamit (single master) lamang.
• Tumawag kay Bridge: isang serbisyo para sa audio at video conferencing na nagbibigay ng ganap na kontrol sa pamamahala at pagproseso ng mga tawag at mga proseso ng multimedia. Sinusuportahan ang clustering para sa mataas na kakayahang magamit at scalability.
• XMPP server: responsable para sa pagpaparehistro at pagpapatunay ng mga kliyente gamit ang Cisco Meeting Application at/o WebRTC(real-time na komunikasyon, o sa browser lang), pati na rin ang intercomponent signaling. Maaaring i-cluster para sa mataas na availability lamang.
• Tulay sa Web: Nagbibigay ng access sa kliyente sa WebRTC.
• Loadbalancer: Nagbibigay ng isang punto ng koneksyon para sa Cisco Meeting Apps sa Single Split mode. Nakikinig sa panlabas na interface at port para sa mga papasok na koneksyon. Sa parehong paraan, ang load balancer ay tumatanggap ng mga papasok na TLS na koneksyon mula sa XMPP server, kung saan maaari itong lumipat ng mga koneksyon sa TCP mula sa mga panlabas na kliyente.
  Sa aming senaryo ay hindi ito kakailanganin.
• TURN server: Nagbibigay ng teknolohiyang bypass ng Firewall na nagbibigay-daan
  ilagay ang aming CMS sa likod ng isang Firewall o NAT para kumonekta sa mga external na kliyente gamit ang Cisco Meeting App o SIP device. Sa aming senaryo ay hindi ito kakailanganin.
• Web Admin: Administrative interface at API access, kabilang ang para sa mga espesyal na Unified CM conference.

Mga Mode ng Pag-configure

Hindi tulad ng karamihan sa iba pang mga produkto ng Cisco, sinusuportahan ng Cisco Meeting Server ang tatlong paraan ng pagsasaayos upang mapaunlakan ang anumang uri ng deployment.

• Command line (CLI): Command line interface na kilala bilang MMP para sa paunang configuration at mga gawain sa certificate.
• Web Administrator: Pangunahin para sa mga configuration na nauugnay sa CallBridge, lalo na kapag nagse-set up ng isang hindi naka-cluster na server.
• REST API: Ginagamit para sa pinakakumplikadong mga gawain sa pagsasaayos at mga naka-cluster na gawaing nauugnay sa database.

Bilang karagdagan sa itaas, ginagamit ang protocol SFTP upang maglipat ng mga file—karaniwan ay mga lisensya, certificate, o log—papunta at mula sa CMS server.

Sa mga gabay sa pag-deploy mula sa Cisco, nakasulat ito sa puti at Ingles na kailangang i-deploy ang cluster kahit tatlo mga server (node) sa konteksto ng mga database. kasi Tanging sa isang kakaibang bilang ng mga node gagana ang mekanismo para sa pagpili ng bagong Database Master, at sa pangkalahatan ang Database Master ay may koneksyon sa karamihan ng CMS server database.

At tulad ng ipinapakita sa pagsasanay, dalawang server (node) ay talagang hindi sapat. Ang mekanismo ng pagpili ay gumagana kapag ang Master ay na-reboot, ang Slave server ay nagiging Master lamang pagkatapos na ang reboot na server ay dinala. Gayunpaman, kung sa isang kumpol ng dalawang server ang Master server ay biglang lumabas, ang Slave server ay hindi magiging Master, at kung ang Slave ay lumabas, ang natitirang Master server ay magiging Slave.

Ngunit sa konteksto ng XMPP, talagang kinakailangan na mag-ipon ng isang kumpol ng tatlong server, dahil kung, halimbawa, hindi mo pinagana ang serbisyo ng XMPP sa isa sa mga server kung saan ang XMMP ay nasa Leader status, pagkatapos ay sa natitirang server ang XMPP ay mananatili sa Follower status at ang mga koneksyon ng CallBridge sa XMPP ay mahuhulog, dahil Eksklusibong kumokonekta ang CallBridge sa XMPP na may status na Leader. At ito ay kritikal, dahil... wala ni isang tawag na dadaan.

Gayundin sa parehong deployment gabay ang isang cluster na may isang XMPP server ay ipinapakita.

At isinasaalang-alang ang nasa itaas, nagiging malinaw kung bakit: gumagana ito dahil nasa failover mode ito.

Sa aming kaso, ang XMPP server ay naroroon sa lahat ng tatlong node.

Ipinapalagay na ang lahat ng tatlo sa aming mga server ay pataas.

Mga tala ng DNS

Bago ka magsimulang mag-set up ng mga server, kailangan mong gumawa ng mga DNS record А и Ang SRV mga uri:

Pakitandaan na sa aming mga DNS record mayroong dalawang domain na example.com at conf.example.com. Ang Example.com ay isang domain na magagamit ng lahat ng mga subscriber ng Cisco Unified Communication Manager para sa kanilang mga URI, na malamang na nasa iyong imprastraktura o malamang na naroroon. O tumutugma ang example.com sa parehong domain na ginagamit ng mga user para sa kanilang mga email address. O ang Jabber client sa iyong laptop ay maaaring may URI [protektado ng email]. Domain confAng .example.com ay ang domain na iko-configure para sa mga user ng Cisco Meeting Server. Ang domain ng Cisco Meeting Server ay conf.example.com, kaya para sa parehong user ng Jabber, ang user@ URI ay kailangang gamitin para mag-log in sa Cisco Meeting Serverconf.example.com.

Pangunahing pagsasaayos

Ang lahat ng mga setting na inilarawan sa ibaba ay ipinapakita sa isang server, ngunit kailangan nilang gawin sa bawat server sa cluster.

QoS

Dahil nabuo ang CMS real-time sensitibo sa trapiko sa mga pagkaantala at pagkawala ng packet, sa karamihan ng mga kaso, inirerekomendang i-configure ang kalidad ng serbisyo (QoS). Upang makamit ito, sinusuportahan ng CMS ang mga packet ng pag-tag gamit ang Differentiated Services Codes (DSCPs) na nabuo nito. Bagama't nakadepende ang DSCP-based na traffic prioritization sa kung paano pinoproseso ang trapiko ng mga bahagi ng network ng iyong imprastraktura, sa aming sitwasyon ay iko-configure namin ang aming CMS na may tipikal na DSCP prioritization batay sa pinakamahuhusay na kagawian sa QoS.

Sa bawat server ilalagay namin ang mga command na ito

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

Kaya, ang lahat ng trapiko ng video ay minarkahan ng AF41 (DSCP 0x22), lahat ng trapiko ng boses ay minarkahan ng EF (DSCP 0x2E), iba pang mga uri ng mababang latency na trapiko gaya ng SIP at XMPP ay gumagamit ng AF31 (DSCP 0x1A).

Namin suriin:

NTP

Ang Network Time Protocol (NTP) ay mahalaga hindi lamang para sa pagbibigay ng mga tumpak na timestamp ng mga tawag at kumperensya, kundi pati na rin para sa pag-verify ng mga sertipiko.

Magdagdag ng mga NTP server sa iyong imprastraktura na may tulad ng command

ntp server add <server>

Sa aming kaso, mayroong dalawang ganoong server, kaya magkakaroon ng dalawang koponan.
Namin suriin:

At itakda ang time zone para sa aming server

DNS

Nagdaragdag kami ng mga DNS server sa CMS na may utos tulad ng:

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

Sa aming kaso, mayroong dalawang ganoong server, kaya magkakaroon ng dalawang koponan.
Namin suriin:

Network Interface Configuration

I-configure namin ang interface gamit ang isang command tulad ng:

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

Namin suriin:

Pangalan ng server (Hostname)

Itinakda namin ang pangalan ng server na may utos tulad ng:

hostname <name>

At nag-reboot kami.


Kinukumpleto nito ang pangunahing pagsasaayos.

Mga Certificate

ТеорияNangangailangan ang Cisco Meeting Server ng naka-encrypt na komunikasyon sa pagitan ng iba't ibang bahagi, at bilang resulta, kinakailangan ang mga X.509 na certificate para sa lahat ng deployment ng CMS. Tumutulong sila na matiyak na ang mga serbisyo/server ay pinagkakatiwalaan ng ibang mga server/serbisyo.

Ang bawat serbisyo ay nangangailangan ng isang sertipiko, ngunit ang paggawa ng hiwalay na mga sertipiko para sa bawat serbisyo ay maaaring humantong sa pagkalito at hindi kinakailangang kumplikado. Sa kabutihang-palad, maaari kaming bumuo ng isang public-private key pair ng isang certificate at pagkatapos ay muling gamitin ang mga ito sa maraming serbisyo. Sa aming kaso, ang parehong sertipiko ay gagamitin para sa Call Bridge, XMPP Server, Web Bridge at Web Admin. Kaya, kailangan mong lumikha ng isang pares ng pampubliko at pribadong certificate key para sa bawat server sa cluster.

Ang database clustering, gayunpaman, ay may ilang mga espesyal na kinakailangan sa sertipiko at samakatuwid ay nangangailangan ng sarili nitong mga sertipiko na naiiba sa iba pang mga serbisyo. Gumagamit ang CMS ng certificate ng server, na katulad ng mga certificate na ginagamit ng ibang mga server, ngunit mayroon ding certificate ng kliyente na ginagamit para sa mga koneksyon sa database. Ginagamit ang mga sertipiko ng database para sa parehong pagpapatunay at pag-encrypt. Sa halip na magbigay ng username at password para kumonekta ang kliyente sa database, nagpapakita ito ng sertipiko ng kliyente na pinagkakatiwalaan ng server. Ang bawat server sa database cluster ay gagamit ng parehong pampubliko at pribadong key pair. Nagbibigay-daan ito sa lahat ng server sa cluster na mag-encrypt ng data sa paraang maaari lang itong i-decrypt ng ibang mga server na nagbabahagi rin ng parehong key pair.

Para gumana ang redundancy, ang mga database cluster ay dapat na binubuo ng hindi bababa sa 3 server, ngunit hindi hihigit sa 5, na may maximum na round-trip na oras na 200 ms sa pagitan ng sinumang miyembro ng cluster. Ang limitasyong ito ay mas mahigpit kaysa sa pag-cluster ng Call Bridge, kaya kadalasan ito ang salik na naglilimita sa mga pag-deploy sa heograpiya.

Ang tungkulin ng database para sa isang CMS ay may ilang natatanging kinakailangan. Hindi tulad ng iba pang mga tungkulin, nangangailangan ito ng isang sertipiko ng kliyente at server, kung saan ang sertipiko ng kliyente ay may isang partikular na field ng CN na ipinakita sa server.

Gumagamit ang CMS ng database ng postgres na may isang master at ilang ganap na magkaparehong mga replika. Mayroon lamang isang pangunahing database sa isang pagkakataon (ang "database server"). Ang natitirang mga miyembro ng cluster ay mga replika o "mga kliyente ng database."

Ang isang database cluster ay nangangailangan ng isang nakalaang server certificate at isang client certificate. Dapat silang pirmahan ng mga sertipiko, karaniwang isang panloob na pribadong awtoridad sa sertipiko. Dahil ang sinumang miyembro ng database cluster ay maaaring maging master, ang database server at client certificate pairs (naglalaman ng pampubliko at pribadong key) ay dapat makopya sa lahat ng mga server upang maipagpalagay nila ang pagkakakilanlan ng client o database server. Bilang karagdagan, ang CA root certificate ay dapat na mai-load upang matiyak na ang mga client at server certificate ay maaaring ma-verify.

Kaya, lumikha kami ng isang kahilingan para sa isang sertipiko na gagamitin ng lahat ng mga serbisyo ng server maliban sa database (magkakaroon ng isang hiwalay na kahilingan para dito) na may isang utos tulad ng:

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

Sa CN isinusulat namin ang pangkalahatang pangalan ng aming mga server. Halimbawa, kung ang mga hostname ng aming mga server server01, server02, server03, pagkatapos ay magiging CN server.example.com

Ginagawa namin ang parehong sa natitirang dalawang server na may pagkakaiba na ang mga command ay maglalaman ng kaukulang "hostname"

Bumubuo kami ng dalawang kahilingan para sa mga sertipiko na gagamitin ng serbisyo ng database na may mga utos tulad ng:

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

pki csr dbclusterclient CN:postgres

saan dbclusterserver и dbclusterclient mga pangalan ng aming mga kahilingan at mga sertipiko sa hinaharap, hostname1(2)(3) mga pangalan ng kaukulang mga server.

Ginagawa lang namin ang pamamaraang ito sa isang server (!), at ia-upload namin ang mga certificate at kaukulang .key na file sa ibang mga server.

Paganahin ang client certificate mode sa AD CS

Kailangan mo ring pagsamahin ang mga sertipiko para sa bawat server sa isang file.Sa *NIX:

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

Sa Windows/DOS:

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

At i-upload sa bawat server:
1. "Indibidwal" na sertipiko ng server.
2. Root certificate (kasama ang mga intermediate, kung mayroon man).
3. Mga sertipiko para sa database (“server” at “client”) at mga file na may extension na .key, na nabuo noong lumilikha ng kahilingan para sa mga certificate ng database ng “server” at “client”. Ang mga file na ito ay dapat na pareho sa lahat ng mga server.
4. File ng lahat ng tatlong "indibidwal" na sertipiko.

Bilang resulta, dapat kang makakuha ng isang bagay na tulad ng larawan ng file na ito sa bawat server.

Cluster ng Database

Ngayong na-upload mo na ang lahat ng certificate sa mga CMS server, maaari mong i-configure at paganahin ang database clustering sa pagitan ng tatlong node. Ang unang hakbang ay ang pumili ng isang server bilang master node ng database cluster at ganap na i-configure ito.

Master Database

Ang unang hakbang sa pag-set up ng pagtitiklop ng database ay tukuyin ang mga sertipiko na gagamitin para sa database. Ginagawa ito gamit ang isang utos tulad ng:

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

Ngayon sabihin natin sa CMS kung aling interface ang gagamitin para sa database clustering gamit ang command:

database cluster localnode a

Pagkatapos ay sinisimulan namin ang database ng kumpol sa pangunahing server gamit ang utos:

database cluster initialize

Mga Node ng Database ng Kliyente

Ginagawa namin ang parehong pamamaraan, sa halip na utos lamang ang database cluster ay nagpasimula magpasok ng command tulad ng:

database cluster join <ip address existing master>

kung saan ip address ang umiiral na master ip address ng CMS server kung saan nasimulan ang cluster, Master lang.

Sinusuri namin kung paano gumagana ang aming database cluster sa lahat ng mga server gamit ang command:

database cluster status

Ginagawa namin ang parehong sa natitirang ikatlong server.

Bilang resulta, lumalabas na ang aming unang server ay ang Master, ang iba ay mga Alipin.

Serbisyo sa Web Admin

Paganahin ang serbisyo ng web administrator:

webadmin listen a 445

Pinili ang Port 445 dahil ginagamit ang port 443 para sa access ng user sa web client

Kino-configure namin ang serbisyo ng Web Admin na may mga certificate file na may command tulad ng:

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

At paganahin ang Web Admin gamit ang command:

webadmin enable

Kung maayos ang lahat, makakatanggap kami ng SUCCESS na mga linya na nagsasaad na ang Web Admin ay wastong na-configure para sa network at certificate. Sinusuri namin ang pag-andar ng serbisyo gamit ang isang web browser at ipinasok ang address ng web administrator, halimbawa: cms.example.com: 445

Tawagan ang Bridge Cluster

Ang Call Bridge ay ang tanging serbisyong naroroon sa bawat pag-deploy ng CMS. Ang Call Bridge ay ang pangunahing mekanismo ng pagpupulong. Nagbibigay din ito ng interface ng SIP upang ang mga tawag ay mai-ruta papunta o mula rito sa pamamagitan ng, halimbawa, ng Cisco Unified CM.

Ang mga utos na inilarawan sa ibaba ay dapat na isagawa sa bawat server na may naaangkop na mga sertipiko.
Kaya:

Iniuugnay namin ang mga sertipiko sa serbisyo ng Call Bridge sa isang command tulad ng:

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

Binibinhi namin ang mga serbisyo ng CallBridge sa interface na kailangan namin gamit ang command:

callbridge listen a

At i-restart ang serbisyo gamit ang command:

callbridge restart

Ngayong na-configure na namin ang aming Call Bridges, maaari naming i-configure ang Call Bridge clustering. Ang Call Bridge clustering ay iba sa database o XMPP clustering. Maaaring suportahan ng Call Bridge Cluster ang mula 2 hanggang 8 node nang walang anumang mga paghihigpit. Nagbibigay ito hindi lamang ng redundancy, kundi pati na rin ang load balancing upang ang mga kumperensya ay maaaring aktibong maipamahagi sa mga server ng Call Bridge gamit ang matalinong pamamahagi ng tawag. Ang CMS ay may mga karagdagang feature, Call Bridge group at mga kaugnay na feature na magagamit para sa karagdagang pamamahala.

Pangunahing naka-configure ang call bridge clustering sa pamamagitan ng web admin interface
Ang pamamaraang inilarawan sa ibaba ay dapat isagawa sa bawat server sa cluster.
Kaya,

1. Pumunta sa web sa Configuration > Cluster.
2. In Tawagan ang pagkakakilanlan ng Bridge Bilang isang natatanging pangalan, ilagay ang callbridge[01,02,03] na naaayon sa pangalan ng server. Ang mga pangalan na ito ay arbitrary, ngunit dapat na natatangi para sa cluster na ito. Ang mga ito ay likas na mapaglarawan dahil ipinapahiwatig nila na sila ay mga tagatukoy ng server [01,02,03].
3.B Clustered Call Bridges ilagay ang mga URL ng web administrator ng aming mga server sa cluster, cms[01,02,03].example.com:445, sa field ng Address. Tiyaking tukuyin ang port. Maaari mong iwanang walang laman ang peer link na SIP domain.
4. Magdagdag ng certificate sa CallBridge trust ng bawat server, ang file kung saan naglalaman ng lahat ng certificate ng aming mga server, na pinagsama namin sa file na ito sa simula pa lang, na may command tulad ng:

callbridge trust cluster <trusted cluster certificate bundle>

At i-restart ang serbisyo gamit ang command:

callbridge restart

Bilang resulta, sa bawat server dapat mong makuha ang larawang ito:

XMPP Cluster

Ang serbisyo ng XMPP sa CMS ay ginagamit upang pangasiwaan ang lahat ng pagpaparehistro at pagpapatunay para sa Cisco Meeting Apps (CMA), kabilang ang CMA WebRTC web client. Ang Call Bridge mismo ay gumaganap din bilang isang XMPP client para sa mga layunin ng pagpapatunay at samakatuwid ay dapat na i-configure tulad ng ibang mga kliyente. Ang XMPP fault tolerance ay isang feature na sinusuportahan sa mga production environment mula noong bersyon 2.1

Ang mga utos na inilarawan sa ibaba ay dapat na isagawa sa bawat server na may naaangkop na mga sertipiko.
Kaya:

Iniuugnay namin ang mga sertipiko sa serbisyo ng XMPP sa isang utos tulad ng:

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

Pagkatapos ay tukuyin ang interface ng pakikinig gamit ang command:

xmpp listen a

Ang serbisyo ng XMPP ay nangangailangan ng isang natatanging domain. Ito ang login para sa mga user. Sa madaling salita, kapag sinubukan ng isang user na mag-login gamit ang CMA app (o sa pamamagitan ng WebRTC client), pinapasok nila ang userID@logindomain. Sa aming kaso ito ay magiging userid@conf.example.com. Bakit hindi na lang example.com? Sa aming partikular na deployment, pinili namin ang aming Unified CM domain na gagamitin ng mga user ng Jabber sa Unified CM bilang example.com, kaya kailangan namin ng ibang domain para sa mga user ng CMS upang iruta ang mga tawag papunta at mula sa CMS sa pamamagitan ng mga SIP domain.

Mag-set up ng XMPP domain gamit ang isang command tulad ng:

xmpp domain <domain>

At paganahin ang serbisyo ng XMPP gamit ang utos:

xmpp enable

Sa serbisyo ng XMPP, dapat kang lumikha ng mga kredensyal para sa bawat Call Bridge na gagamitin kapag nagrerehistro sa serbisyo ng XMPP. Ang mga pangalang ito ay arbitrary (at hindi nauugnay sa mga natatanging pangalan na iyong na-configure para sa call bridge clustering). Dapat kang magdagdag ng tatlong tulay ng tawag sa isang server ng XMPP at pagkatapos ay ilagay ang mga kredensyal na iyon sa iba pang mga server ng XMPP sa cluster dahil hindi umaangkop ang configuration na ito sa database ng cluster. Mamaya ay iko-configure namin ang bawat Call Bridge para gamitin ang pangalan at sikretong ito para magparehistro sa serbisyo ng XMPP.

Ngayon ay kailangan nating i-configure ang serbisyo ng XMPP sa unang server na may tatlong Call Bridges callbridge01, callbridge02 at callbridge03. Ang bawat account ay bibigyan ng mga random na password. Ipapasok sila sa ibang pagkakataon sa ibang mga server ng Call Bridge upang mag-log in sa XMPP server na ito. Ipasok ang sumusunod na mga utos:

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

Bilang resulta, sinusuri namin kung ano ang nangyari sa utos:

xmpp callbridge list

Ang eksaktong parehong larawan ay dapat na lumitaw sa natitirang mga server pagkatapos ng mga hakbang na inilarawan sa ibaba.

Susunod, idagdag namin ang eksaktong parehong mga setting sa natitirang dalawang server, kasama lamang ang mga utos

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

Nagdaragdag kami ng Lihim nang maingat upang, halimbawa, walang mga karagdagang puwang dito.


Bilang resulta, ang bawat server ay dapat magkaroon ng parehong larawan:

Susunod, sa lahat ng mga server sa kumpol, tinukoy namin sa tiwala ang file na naglalaman ng lahat ng tatlong mga sertipiko, na nilikha nang mas maaga gamit ang isang utos na tulad nito:

xmpp cluster trust <trust bundle>

Pinagana namin ang xmpp cluster mode sa lahat ng cluster server gamit ang command:

xmpp cluster enable

Sa unang server ng cluster, sinimulan namin ang paglikha ng isang xmpp cluster gamit ang command:

xmpp cluster initialize

Sa ibang mga server, magdagdag ng cluster sa xmpp na may command tulad ng:

xmpp cluster join <ip address head xmpp server>

Sinusuri namin sa bawat server ang tagumpay ng paglikha ng XMPP cluster sa bawat server gamit ang mga command:

xmpp status
xmpp cluster status

Unang server:

Pangalawang server:

Pangatlong server:

Pagkonekta ng Call Bridge sa XMPP

Ngayong tumatakbo na ang XMPP cluster, kailangan mong i-configure ang Call Bridge services para kumonekta sa XMPP cluster. Ginagawa ang configuration na ito sa pamamagitan ng web admin.

Sa bawat server, pumunta sa Configuration > General at sa field Natatanging pangalan ng Call Bridge magsulat ng mga natatanging pangalan na naaayon sa server Call Bridge callbridge[01,02,03]... Sa patlang Domain conf.example.ru at kaukulang mga password, maaari mong tiktikan ang mga ito
sa anumang server sa kumpol na may utos:

xmpp callbridge list

Iwanang walang laman ang field na “Server”. Callbridge gagawa ng DNS SRV lookup para sa _xmpp-component._tcp.conf.example.compara makahanap ng available na XMPP server. Ang mga IP address para sa pagkonekta ng mga callbridge sa XMPP ay maaaring magkakaiba sa bawat server, depende ito sa kung anong mga halaga ang ibinalik sa kahilingan sa talaan _xmpp-component._tcp.conf.example.com callbridge, na depende naman sa mga setting ng priyoridad para sa isang naibigay na tala ng DNS.

Susunod, pumunta sa Status > General para i-verify kung matagumpay na nakakonekta ang serbisyo ng Call Bride sa serbisyo ng XMPP.

Tulay sa Web

Sa bawat server sa cluster, paganahin ang serbisyo ng Web Bridge gamit ang command:

webbridge listen a:443

Kino-configure namin ang serbisyo ng Web Bridge na may mga certificate file na may command tulad ng:

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

Sinusuportahan ng Web Bridge ang HTTPS. Ire-redirect nito ang HTTP sa HTTPS kung naka-configure na gumamit ng "http-redirect".
Upang paganahin ang pag-redirect ng HTTP, gamitin ang sumusunod na command:

webbridge http-redirect enable

Upang ipaalam sa Call Bridge na mapagkakatiwalaan ng Web Bridge ang mga koneksyon mula sa Call Bridge, gamitin ang command:

webbridge trust <certfile>

kung saan ito ay isang file na naglalaman ng lahat ng tatlong mga sertipiko mula sa bawat server sa cluster.

Ang larawang ito ay dapat nasa bawat server sa cluster.


Ngayon ay kailangan naming lumikha ng isang user na may "appadmin" na tungkulin, kailangan namin ito upang mai-configure namin ang aming cluster(!), at hindi ang bawat server sa cluster nang hiwalay, sa ganitong paraan ang mga setting ay ilalapat nang pantay-pantay sa bawat server sa kabila ng katotohanan na sila ay gagawin nang isang beses.


Para sa karagdagang setup gagamitin namin Kartero.

Para sa awtorisasyon, piliin ang Basic sa seksyong Authorization

Upang maipadala nang tama ang mga command sa CMS server, kailangan mong itakda ang kinakailangang pag-encode

Tinukoy namin ang Webbridge gamit ang utos POST may parameter url at kahulugan cms.example.com



Sa webbridge mismo, ipinapahiwatig namin ang mga kinakailangang parameter: pag-access ng bisita, protektadong pag-access, atbp.

Tawagan ang Bridge Groups

Bilang default, hindi palaging ginagawa ng CMS ang pinakamabisang paggamit ng mga mapagkukunan ng kumperensya na magagamit nito.

Halimbawa, para sa isang pulong na may tatlong kalahok, ang bawat kalahok ay maaaring mapunta sa tatlong magkakaibang Call Bridges. Upang ang tatlong kalahok na ito ay makipag-usap sa isa't isa, ang Call Bridges ay awtomatikong magtatatag ng mga koneksyon sa pagitan ng lahat ng mga server at mga kliyente sa parehong Space, upang ang lahat ay magmukhang lahat ng mga kliyente ay nasa parehong server. Sa kasamaang palad, ang downside nito ay ang isang solong 3-tao na kumperensya ay kumonsumo na ngayon ng 9 media port. Ito ay malinaw na isang hindi mahusay na paggamit ng mga mapagkukunan. Bukod pa rito, kapag ang isang Call Bridge ay tunay na na-overload, ang default na mekanismo ay ang patuloy na pagtanggap ng mga tawag at magbigay ng pinababang kalidad ng serbisyo sa lahat ng mga subscriber ng Call Bridge na iyon.

Ang mga problemang ito ay nalutas gamit ang tampok na Call Bridge Group. Ang feature na ito ay ipinakilala sa bersyon 2.1 ng Cisco Meeting Server software at pinalawig upang suportahan ang load balancing para sa parehong papasok at papalabas na mga tawag sa Cisco Meeting App (CMA), kabilang ang mga kalahok sa WebRTC.

Upang malutas ang problema sa muling pagkonekta, tatlong na-configure na limitasyon sa pagkarga ang ipinakilala para sa bawat Call Bridge:

LoadLimit — ito ang pinakamataas na pagkarga ng numero para sa isang partikular na Call Bridge. Ang bawat platform ay may inirerekomendang limitasyon sa pagkarga, gaya ng 96000 para sa CMS1000 at 1.25 GHz bawat vCPU para sa virtual machine. Ang iba't ibang mga tawag ay gumagamit ng isang tiyak na halaga ng mga mapagkukunan depende sa resolution at frame rate ng kalahok.
NewConferenceLoadLimitBasisPoints (default 50% loadLimit) - nagtatakda ng limitasyon sa pag-load ng server, pagkatapos nito ay tatanggihan ang mga bagong kumperensya.
Umiiral naConferenceLoadLimitBasisPoints (default 80% ng loadLimit) - ang halaga ng pag-load ng server pagkatapos kung saan ang mga kalahok na sasali sa isang umiiral na kumperensya ay tatanggihan.

Bagama't ang feature na ito ay idinisenyo para sa pamamahagi ng tawag at pagbalanse ng load, ang ibang mga grupo gaya ng TURN Servers, Web Bridge Servers at Recorder ay maaari ding italaga sa Call Bridge Groups upang maayos din silang maipangkat para sa pinakamainam na paggamit. Kung ang alinman sa mga bagay na ito ay hindi itinalaga sa isang grupo ng tawag, ang mga ito ay ipinapalagay na magagamit sa lahat ng mga server nang walang anumang partikular na priyoridad.

Ang mga parameter na ito ay na-configure dito: cms.example.com:445/api/v1/system/configuration/cluster

Susunod, ipinapahiwatig namin sa bawat callbridge kung aling pangkat ng callbridge ito nabibilang:

Unang callbridge

Pangalawang callbridge

Pangatlong callbridge


Kaya, na-configure namin ang grupong Call Brdige para mas mahusay na magamit ang mga mapagkukunan ng cluster ng Cisco Meeting Server.

Pag-import ng mga user mula sa Active Directory

Ang serbisyo ng Web Admin ay may seksyon ng pagsasaayos ng LDAP, ngunit hindi ito nagbibigay ng mga kumplikadong opsyon sa pagsasaayos, at ang impormasyon ay hindi nakaimbak sa database ng kumpol, kaya kailangang gawin ang pagsasaayos, alinman sa mano-mano sa bawat server sa pamamagitan ng Web interface, o sa pamamagitan ng ang API, at para “tatlong beses kaming “Huwag bumangon” itatakda pa rin namin ang data sa pamamagitan ng API.

Paggamit ng URL para ma-access cms01.example.com:445/api/v1/ldapServers ay lumikha ng LDAP Server object, na tumutukoy sa mga parameter gaya ng:

• IP ng server
• numero ng port
• имя пользователя
• password
• hindi makatatakas

Secure - piliin ang true o false depende sa port, 389 - hindi secure, 636 - protektado.


Pagma-map ng mga parameter ng source ng LDAP sa mga attribute sa Cisco Meeting Server.
Minamapa ng LDAP mapping ang mga attribute sa LDAP directory sa mga attribute sa CMS. Ang aktwal na mga katangian:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Paglalarawan ng mga katangianJID kumakatawan sa login ID ng user sa CMS. Dahil isa itong Microsoft Active Directory LDAP server, ang CMS JID ay nagmamapa sa sAMAccountName sa LDAP, na kung saan ay ang Active Directory login ID ng user. Tandaan din na kukuha ka ng sAMAccountName at idagdag ang domain na conf.pod6.cms.lab sa dulo nito dahil ito ang login na gagamitin ng iyong mga user para mag-log in sa CMS.

nameMapping tumutugma sa kung ano ang nilalaman sa field ng Active Directory displayName sa field ng pangalan ng CMS ng user.

coSpaceNameMapping lumilikha ng pangalan ng espasyo ng CMS batay sa field ng displayName. Ang katangiang ito, kasama ang katangian ng coSpaceUriMapping, ang kinakailangan upang lumikha ng espasyo para sa bawat user.

coSpaceUriMapping tumutukoy sa bahagi ng user ng URI na nauugnay sa personal na espasyo ng user. Ang ilang mga domain ay maaaring i-configure upang i-dial sa espasyo. Kung tumugma ang bahagi ng user sa field na ito para sa isa sa mga domain na ito, ididirekta ang tawag sa espasyo ng user na iyon.

coSpaceSecondaryUriMapping tumutukoy sa pangalawang URI upang maabot ang espasyo. Magagamit ito para magdagdag ng numeric na alias para sa pagruruta ng mga tawag sa na-import na espasyo ng user bilang alternatibo sa alphanumeric URI na tinukoy sa parameter ng coSpaceUriMapping.

Ang LDAP server at LDAP mapping ay na-configure. Ngayon ay kailangan mong i-link ang mga ito nang magkasama sa pamamagitan ng paggawa ng LDAP source.

Paggamit ng URL para ma-access cms01.example.com:445/api/v1/ldapSource lumikha ng object ng LDAP Source, na tumutukoy sa mga parameter gaya ng:

• server
• paggawa ng mga mapa
• baseDn
• filter

Ngayong kumpleto na ang configuration ng LDAP, maaari mong isagawa ang manual na operasyon ng pag-synchronize.

Ginagawa namin ito alinman sa Web interface ng bawat server sa pamamagitan ng pag-click I-sync ngayon seksyon Active Directory


o sa pamamagitan ng API na may utos POST gamit ang URL para ma-access cms01.example.com:445/api/v1/ldapSyncs

Mga kumperensya ng Ad-Hoc

Ano ito?Sa tradisyonal na konsepto, ang kumperensya ay kapag ang dalawang kalahok ay nag-uusap sa isa't isa, at ang isa sa mga kalahok (gamit ang isang device na nakarehistro sa Unified CM) ay pinindot ang "Conference" na button, tinawagan ang ibang tao, at pagkatapos makipag-usap sa ikatlong partido na iyon. , pinindot muli ang "Conference" na buton. upang sumali sa lahat ng kalahok sa tripartite conference.

Ang pinagkaiba ng Ad-Hoc conference sa nakaiskedyul na conference sa CMS ay ang Ad-Hoc conference ay hindi lang isang SIP call sa CMS. Kapag na-click ng conference initiator ang button ng Conference sa pangalawang pagkakataon para imbitahan ang lahat sa parehong meeting, dapat gumawa ng API call ang Unified CM sa CMS para gumawa ng on-the-fly conference kung saan ililipat ang lahat ng tawag. Ang lahat ng ito ay nangyayari nang hindi napapansin ng mga kalahok.

Nangangahulugan ito na dapat i-configure ng Unified CM ang mga kredensyal ng API at WebAdmin address/port ng serbisyo pati na rin ang SIP Trunk nang direkta sa CMS server upang ipagpatuloy ang tawag.

Kung kinakailangan, ang CUCM ay maaaring dynamic na lumikha ng isang puwang sa CMS upang maabot ng bawat tawag ang CMS at tumugma sa panuntunan ng papasok na tawag na inilaan para sa mga espasyo.

Pagsasama sa CUCM na-configure sa parehong paraan tulad ng inilarawan sa artikulo mas maaga maliban na sa Cisco UCM kailangan mong lumikha ng tatlong trunks para sa CMS, tatlong Conference Bridges, sa SIP Security Profile tukuyin ang tatlong Subject Names, Route Groups, Route Lists, Media Resourse Groups at Media Resourse Group Lists, at magdagdag ng ilang panuntunan sa pagruruta sa Cisco Meeting Server.

Profile ng Seguridad ng SIP:


Trunks:


Ang bawat puno ng kahoy ay mukhang pareho:




Tulay ng Kumperensya


Magkamukha ang bawat Conference Bridge:


Grupo ng Ruta


Listahan ng Ruta


Grupo ng Mapagkukunan ng Media


Listahan ng Grupo ng Media Resource

Mga Panuntunan sa Tawag

Hindi tulad ng mas advanced na mga sistema ng pamamahala ng tawag gaya ng Unified CM o Expressway, hinahanap lang ng CMS ang domain sa field ng SIP Request-URI para sa mga bagong tawag. Kaya kung ang SIP INVITE ay para sa paghigop: [protektado ng email]Ang CMS ay nagmamalasakit lamang sa domain.com. Sinusunod ng CMS ang mga panuntunang ito upang matukoy kung saan iruruta ang isang tawag:

1. Sinusubukan muna ng CMS na itugma ang domain ng SIP sa mga domain na na-configure sa mga panuntunan sa papasok na tawag. Ang mga tawag na ito ay maaaring i-ruta sa ("naka-target") na mga espasyo o mga partikular na user, mga panloob na IVR, o direktang pinagsamang mga patutunguhan ng Microsoft Lync/Skype for Business (S4B).
2. Kung walang tugma sa mga panuntunan sa papasok na tawag, susubukan ng CMS na itugma ang domain na na-configure sa talahanayan ng pagpapasa ng tawag. Kung may tugma, maaaring tahasang tanggihan ng panuntunan ang tawag o ipasa ang tawag. Sa oras na ito, maaaring muling isulat ng CMS ang domain, na kung minsan ay kapaki-pakinabang para sa pagtawag sa mga domain ng Lync. Maaari mo ring piliing ipasa ang throw, na nangangahulugang wala sa mga field ang higit pang babaguhin, o gumamit ng panloob na CMS dial plan. Kung walang tugma sa mga panuntunan sa pagpapasa ng tawag, ang default ay tanggihan ang tawag. Tandaan na sa CMS, kahit na ang tawag ay "ipinasa", ang media ay nakatali pa rin sa CMS, na nangangahulugang ito ay nasa signaling at media traffic path.
Pagkatapos ay ang mga ipinasa na tawag lamang ang napapailalim sa mga panuntunan sa papalabas na tawag. Tinutukoy ng mga setting na ito ang mga destinasyon kung saan ipinapadala ang mga tawag, ang uri ng trunk (kung ito ay isang bagong tawag sa Lync o isang karaniwang tawag sa SIP), at anumang mga conversion na maaaring isagawa kung ang paglipat ay hindi pinili sa panuntunan sa pagpapasa ng tawag.

Narito ang aktwal na log ng kung ano ang mangyayari sa panahon ng isang Ad-Hoc conference

Ang screenshot ay nagpapakita ng hindi maganda (hindi ko alam kung paano ito gagawing mas mahusay), kaya isusulat ko ang log tulad nito:

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

Ang Ad-Hoc conference mismo:


Mga Panuntunan sa Papasok na Tawag
Ang pag-configure ng mga parameter ng mga papasok na tawag ay kinakailangan upang makatanggap ng tawag sa CMS. Gaya ng nakita mo sa setup ng LDAP, na-import ang lahat ng user gamit ang domain na conf.pod6.cms.lab. Kaya sa pinakamababa, gusto mong tumawag sa domain na ito upang mag-target ng mga espasyo. Kakailanganin mo ring mag-set up ng mga panuntunan para sa lahat ng bagay na inilaan para sa ganap na kwalipikadong pangalan ng domain (at maaaring maging ang IP address) ng bawat isa sa mga server ng CMS. Ang aming panlabas na kontrol sa tawag, ang Unified CM, ay magko-configure ng mga SIP trunks na nakatuon sa bawat isa sa mga CMS server nang paisa-isa. Depende kung ang destinasyon ng mga SIP trunks na ito ay isang IP address o ang FQDN ng server ay tutukuyin kung ang CMS ay kailangang i-configure upang tanggapin ang mga tawag na nakadirekta sa IP address nito o FQDN.

Ang domain na may pinakamataas na priyoridad na papasok na panuntunan ay ginagamit bilang domain para sa anumang mga espasyo ng user. Kapag nagsi-sync ang mga user sa pamamagitan ng LDAP, awtomatikong gumagawa ang CMS ng mga espasyo, ngunit ang bahagi lang ng user ng URI (coSpaceUriMapping), halimbawa, user.space. Bahagi domain Ang buong URI ay nabuo batay sa panuntunang ito. Sa katunayan, kung mag-log in ka sa Web Bridge sa puntong ito, makikita mo na ang Space URI ay walang domain. Sa pamamagitan ng pagtatakda ng panuntunang ito bilang pinakamataas na priyoridad, itinatakda mo ang domain para sa mga nabuong espasyo conf.example.com.


Mga Panuntunan sa Papalabas na Tawag

Upang payagan ang mga user na gumawa ng mga papalabas na tawag sa Unified CM cluster, dapat mong i-configure ang mga papalabas na panuntunan. Ang domain ng mga endpoint na nakarehistro sa Unified CM, gaya ng Jabber, ay example.com. Ang mga tawag sa domain na ito ay dapat na iruta bilang mga karaniwang SIP na tawag sa Unified CM call processing node. Ang pangunahing server ay cucm-01.example.com, at ang karagdagang server ay cucm-02.example.com.

Inilalarawan ng unang panuntunan ang pinakasimpleng pagruruta ng mga tawag sa pagitan ng mga cluster server.

Field Lokal mula sa domain ay responsable para sa kung ano ang ipapakita sa SIP-URI ng tumatawag para sa taong tinatawagan pagkatapos ng simbolo na "@". Kung hahayaan natin itong walang laman, pagkatapos ng simbolong “@” ay magkakaroon ng IP address ng CUCM kung saan dumaraan ang tawag na ito. Kung tutukuyin namin ang isang domain, pagkatapos ng simbolo na "@" ay magkakaroon talaga ng isang domain. Ito ay kinakailangan upang makatawag muli, kung hindi, hindi ito magiging posible na tumawag muli sa pamamagitan ng SIP-URI name@ip-address.

Tumawag kapag tinukoy Lokal mula sa domain


Tumawag kung kailan HINDI ipinahiwatig Lokal mula sa domain


Tiyaking tahasang tukuyin ang Naka-encrypt o Hindi Naka-encrypt para sa mga papalabas na tawag, dahil walang gumagana sa Auto parameter.

Pagtatala

Ang mga video conference ay nire-record ng Record server. Ang Recorder ay eksaktong kapareho ng Cisco Meeting Server. Recorder ay hindi nangangailangan ng pag-install ng anumang mga lisensya. Kinakailangan ang mga lisensya sa pagre-record para sa mga server na nagpapatakbo ng mga serbisyo ng CallBridge, i.e. isang lisensya sa Pagre-record ay kinakailangan at dapat ilapat sa bahagi ng CallBridge, at hindi sa server na tumatakbo sa Recorder. Ang Recorder ay kumikilos bilang isang Extensible Messaging and Presence Protocol (XMPP) client, kaya ang XMPP server ay dapat na pinagana sa server na nagho-host ng CallBridge.

kasi Mayroon kaming isang kumpol at ang lisensya ay kailangang "iunat" sa lahat ng tatlong mga server sa kumpol. Pagkatapos ay sa iyong personal na account sa mga lisensyang iniuugnay namin (idagdag) ang mga MAC address ng a-interface ng lahat ng CMS server na kasama sa cluster.

At ito ang larawan na dapat nasa bawat server sa cluster

Sa pangkalahatan, mayroong ilang mga sitwasyon para sa paglalagay ng Recorder, ngunit mananatili kami dito:


Bago mag-set up ng Recorder, kailangan mong maghanda ng isang lugar kung saan aktwal na ire-record ang mga video conference. Actually dito link, kung paano i-set up ang lahat ng Pagre-record. Nakatuon ako sa mahahalagang punto at detalye:

1. Mas mainam na i-slip ang certificate mula sa unang server sa cluster.
2. Maaaring mangyari ang error na "Hindi available ang Recorder" dahil ang maling certificate ay tinukoy sa Recorder Trust.
3. Maaaring hindi gumana ang pagsusulat kung ang direktoryo ng NFS na tinukoy para sa pag-record ay hindi ang direktoryo ng ugat.

Minsan may pangangailangan na awtomatikong mag-record ng kumperensya ng isang partikular na user o espasyo.

Para dito, dalawang CallProfile ang nilikha:
Nang hindi pinagana ang pagre-record


At may function na awtomatikong pag-record


Susunod, "ilakip" namin ang isang CallProfile na may awtomatikong function ng pag-record sa kinakailangang espasyo.


Sa CMS ito ay lubos na itinatag na kung ang isang CallProfile ay tahasang nakatali sa anumang espasyo o espasyo, ang CallProfile na ito ay gagana lamang kaugnay sa mga partikular na espasyong ito. At kung ang CallProfile ay hindi nakatali sa anumang espasyo, bilang default ay inilalapat ito sa mga puwang kung saan walang CallProfile ang tahasang nakatali.

Sa susunod na pagkakataon ay susubukan kong ilarawan kung paano ina-access ang CMS sa labas ng panloob na network ng organisasyon.

Pinagmulan:

• 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

Pinagmulan: www.habr.com