ProHoster > Blog > administratë > Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Në këtë numër do të tregoj dhe shpjegoj disa nga ndërlikimet e konfigurimit të një serveri CMS në modalitetin e grupit të dështimit.
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

teoriNë përgjithësi, ekzistojnë tre lloje të vendosjes së serverit CMS:

  • Të vetme të kombinuara(Tek i kombinuar), d.m.th. ky është një server në të cilin funksionojnë të gjitha shërbimet e nevojshme. Në shumicën e rasteve, ky lloj vendosjeje është i përshtatshëm vetëm për akses të brendshëm të klientit dhe në mjedise më të vogla ku shkallëzueshmëria dhe kufizimet e tepricës së një serveri të vetëm nuk janë një çështje kritike, ose në situata kur CMS kryen vetëm funksione të caktuara, si p.sh. ad hoc konferenca mbi Cisco UCM.

    Skema e përafërt e punës:
    Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

  • Single Split(Single Split) zgjeron llojin e mëparshëm të vendosjes duke shtuar një server të veçantë për akses të jashtëm. Në vendosjet e vjetra, kjo nënkuptonte vendosjen e një serveri CMS në një segment të rrjetit të çmilitarizuar (DMZ) ku klientët e jashtëm mund të aksesonin atë, dhe një server CMS në bërthamën e rrjetit ku klientët e brendshëm mund të hynin në CMS. Ky model i veçantë i vendosjes tani po zëvendësohet nga i ashtuquajturi tip Single Edge, i cili përbëhet nga serverë Cisco Expressway, të cilat ose kanë ose do të kenë shumë të njëjtat aftësi anashkaluese të Firewall-it, kështu që klientët nuk kanë nevojë të shtojnë një server të dedikuar CMS.

    Skema e përafërt e punës:
    Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

  • I shkallëzuar dhe elastik(I shkallëzueshëm dhe tolerant ndaj gabimeve) Ky lloj përfshin tepricë për çdo komponent, duke e lejuar sistemin të rritet me nevojat tuaja në kapacitetin e tij maksimal, ndërsa ofron tepricë në rast dështimi. Ai gjithashtu përdor konceptin Single Edge për të siguruar akses të jashtëm të sigurt. Ky është lloji që do të shohim në këtë episod. Nëse kuptojmë se si të vendosim këtë lloj grupi, ne jo vetëm që do të kuptojmë llojet e tjera të vendosjeve, por do të jemi gjithashtu në gjendje të kuptojmë se si të krijojmë grupe të serverëve CMS për të akomoduar rritjen e mundshme të kërkesës.

Përpara se të kaloni në vendosje, duhet të kuptoni disa gjëra themelore, domethënë

Komponentët kryesorë të softuerit CMS:

  • Baza e të dhënave: Ju lejon të kombinoni disa konfigurime, të tilla si plani i numrit, hapësirat e përdoruesit dhe vetë përdoruesit. Mbështet grupimin vetëm për disponueshmëri të lartë (master i vetëm).
  • Call Bridge: një shërbim për konferenca audio dhe video që ofron kontroll të plotë mbi menaxhimin dhe përpunimin e thirrjeve dhe proceseve multimediale. Mbështet grupimin për disponueshmëri dhe shkallëzim të lartë.
  • Serveri XMPP: përgjegjës për regjistrimin dhe vërtetimin e klientëve duke përdorur aplikacionin Cisco Meeting dhe/ose WebRTC(komunikim në kohë reale, ose thjesht në shfletues), si dhe sinjalizimi ndërkomponent. Mund të grumbullohet vetëm për disponueshmëri të lartë.
  • Ura e Uebit: Ofron akses klientit në WebRTC.
  • balancues i ngarkesës: Ofron një pikë të vetme lidhjeje për aplikacionet Cisco Meeting në modalitetin Single Split. Dëgjon ndërfaqen e jashtme dhe portin për lidhjet hyrëse. Njëlloj, balancuesi i ngarkesës pranon lidhjet hyrëse TLS nga serveri XMPP, përmes të cilit mund të ndërrojë lidhjet TCP nga klientët e jashtëm.
    Në skenarin tonë nuk do të jetë e nevojshme.
  • KTRO serverin: Ofron teknologjinë e anashkalimit të murit të zjarrit që lejon
    vendoseni CMS-në tonë pas një Firewall ose NAT për të lidhur klientët e jashtëm duke përdorur aplikacionin Cisco Meeting ose pajisjet SIP. Në skenarin tonë nuk do të jetë e nevojshme.
  • Administruesi i uebit: Ndërfaqja administrative dhe aksesi në API, duke përfshirë konferencat speciale të Unifikuara CM.

Mënyrat e konfigurimit

Ndryshe nga shumica e produkteve të tjera Cisco, Cisco Meeting Server mbështet tre metoda konfigurimi për të akomoduar çdo lloj vendosjeje.

  • Linja e komandës (CLI): Ndërfaqja e linjës së komandës e njohur si MMP për konfigurimin fillestar dhe detyrat e certifikatës.
  • Administratori i Uebit: Kryesisht për konfigurimet e lidhura me CallBridge, veçanërisht kur vendosni një server të vetëm jo të grupuar.
  • REST API: Përdoret për detyrat më komplekse të konfigurimit dhe detyrat e grupuara të bazës së të dhënave.

Përveç sa më sipër, përdoret protokolli SFTP për të transferuar skedarë—zakonisht licenca, certifikata ose regjistra—në dhe nga serveri CMS.

Në udhëzuesit e vendosjes nga Cisco është shkruar në të bardhë dhe anglisht se grupi duhet të vendoset të paktën tre serverët (nyjet) në kontekstin e bazave të të dhënave. Sepse Vetëm me një numër tek nyjet do të funksionojë mekanizmi për zgjedhjen e një Masteri të ri të bazës së të dhënave dhe në përgjithësi Masteri i bazës së të dhënave ka një lidhje me shumicën e bazës së të dhënave të serverit CMS.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Dhe siç tregon praktika, dy serverë (nyje) nuk janë vërtet të mjaftueshëm. Mekanizmi i përzgjedhjes funksionon kur Master riniset, serveri Slave bëhet Master vetëm pasi serveri i rindezur të shfaqet. Megjithatë, nëse në një grup prej dy serverësh serveri Master del papritmas, atëherë serveri Slave nuk do të bëhet Master, dhe nëse Slave del jashtë, atëherë serveri Master i mbetur do të bëhet Slave.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Por në kontekstin e XMPP, do të ishte vërtet e nevojshme të mblidhej një grup prej tre serverësh, sepse nëse, për shembull, çaktivizoni shërbimin XMPP në një nga serverët në të cilin XMMP është në statusin Leader, atëherë në serverin e mbetur XMPP do të mbetet në statusin e ndjekësit dhe lidhjet e CallBridge me XMPP do të bien, sepse CallBridge lidhet ekskluzivisht me XMPP me statusin e Liderit. Dhe kjo është kritike, sepse... nuk do të bëhet asnjë telefonatë e vetme.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Gjithashtu në të njëjtat udhëzues vendosjeje demonstrohet një grup me një server XMPP.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Dhe duke marrë parasysh sa më sipër, bëhet e qartë pse: funksionon sepse është në modalitetin failover.

Në rastin tonë, serveri XMPP do të jetë i pranishëm në të tre nyjet.

Supozohet se të tre serverët tanë janë në funksion.

Regjistrimet DNS

Para se të filloni konfigurimin e serverëve, duhet të krijoni regjistrime DNS А и SRV llojet:

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Ju lutemi vini re se në të dhënat tona DNS ka dy domene example.com dhe conf.shembull.com. Example.com është një domen që mund të përdorin të gjithë pajtimtarët e Cisco Unified Communication Manager për URI-të e tyre, i cili ka shumë të ngjarë të jetë i pranishëm në infrastrukturën tuaj ose ka të ngjarë të jetë i pranishëm. Ose example.com përputhet me të njëjtin domen që përdoruesit përdorin për adresat e tyre të emailit. Ose klienti Jabber në laptopin tuaj mund të ketë një URI [email mbrojtur]. Domeni conf.example.com është domeni që do të konfigurohet për përdoruesit e Cisco Meeting Server. Domeni i Serverit të Takimeve Cisco do të jetë conf.example.com, kështu që për të njëjtin përdorues Jabber, user@ URI duhet të përdoret për t'u identifikuar në Serverin e Takimeve Ciscoconf.shembull.com.

Konfigurimi bazë

Të gjitha cilësimet e përshkruara më poshtë shfaqen në një server, por ato duhet të kryhen në secilin server në grup.

QoS

Meqenëse CMS gjeneron në kohë reale trafiku i ndjeshëm ndaj vonesave dhe humbjeve të paketave, në shumicën e rasteve rekomandohet konfigurimi i cilësisë së shërbimit (QoS). Për të arritur këtë, CMS mbështet etiketimin e paketave me kodet e shërbimeve të diferencuara (DSCP) që gjeneron. Megjithëse prioritizimi i trafikut i bazuar në DSCP varet nga mënyra se si trafiku përpunohet nga komponentët e rrjetit të infrastrukturës suaj, në rastin tonë ne do të konfigurojmë CMS-në tonë me prioritizimin tipik DSCP bazuar në praktikat më të mira QoS.

Në secilin server do të fusim këto komanda

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

Kështu, i gjithë trafiku i videove u shënua AF41 (DSCP 0x22), i gjithë trafiku zanor u shënua EF (DSCP 0x2E), llojet e tjera të trafikut me vonesë të ulët si SIP dhe XMPP përdorin AF31 (DSCP 0x1A).

kontrolloni:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

NTP

Protokolli i Kohës së Rrjetit (NTP) është i rëndësishëm jo vetëm për sigurimin e vulave kohore të sakta të thirrjeve dhe konferencave, por edhe për verifikimin e certifikatave.

Shtoni serverët NTP në infrastrukturën tuaj me një komandë si

ntp server add <server>

Në rastin tonë, ka dy serverë të tillë, kështu që do të ketë dy ekipe.
kontrolloni:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Dhe vendosni zonën kohore për serverin tonë
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

DNS

Ne shtojmë serverë DNS në CMS me një komandë si:

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

Në rastin tonë, ka dy serverë të tillë, kështu që do të ketë dy ekipe.
kontrolloni:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Konfigurimi i ndërfaqes së rrjetit

Ne konfigurojmë ndërfaqen me një komandë si:

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

kontrolloni:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Emri i serverit (emri i hostit)

Ne vendosëm emrin e serverit me një komandë si:

hostname <name>

Dhe ne rinisim.
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Kjo plotëson konfigurimin bazë.

Certifikimi

teoriServeri Cisco Meeting kërkon komunikim të koduar midis komponentëve të ndryshëm dhe si rezultat, certifikatat X.509 kërkohen për të gjitha vendosjet e CMS. Ato ndihmojnë për të siguruar që shërbimet/serveri të besohet nga serverë/shërbime të tjera.

Çdo shërbim kërkon një certifikatë, por krijimi i certifikatave të veçanta për secilin shërbim mund të çojë në konfuzion dhe kompleksitet të panevojshëm. Për fat të mirë, ne mund të gjenerojmë çiftin e çelësave publik-privat të një certifikate dhe më pas t'i ripërdorim ato nëpër shërbime të shumta. Në rastin tonë, e njëjta certifikatë do të përdoret për Call Bridge, Server XMPP, Web Bridge dhe Web Admin. Kështu, ju duhet të krijoni një palë çelësash certifikatash publike dhe private për çdo server në grup.

Megjithatë, grupimi i bazës së të dhënave ka disa kërkesa të veçanta për certifikata dhe për këtë arsye kërkon certifikatat e veta që janë të ndryshme nga ato të shërbimeve të tjera. CMS përdor një certifikatë serveri, e cila është e ngjashme me certifikatat e përdorura nga serverët e tjerë, por ekziston gjithashtu një certifikatë klienti që përdoret për lidhjet e bazës së të dhënave. Certifikatat e bazës së të dhënave përdoren si për vërtetim ashtu edhe për kriptim. Në vend që të sigurojë një emër përdoruesi dhe fjalëkalim për klientin që të lidhet me bazën e të dhënave, ai paraqet një certifikatë klienti që i besohet serverit. Çdo server në grupin e bazës së të dhënave do të përdorë të njëjtin çift çelësash publik dhe privat. Kjo i lejon të gjithë serverët në grup të kripojnë të dhënat në atë mënyrë që ato të mund të deshifrohen vetëm nga serverë të tjerë që ndajnë gjithashtu të njëjtin çift çelësash.

Që teprica të funksionojë, grupet e bazës së të dhënave duhet të përbëhen nga një minimum prej 3 serverësh, por jo më shumë se 5, me një kohë maksimale vajtje-ardhje prej 200 ms midis çdo anëtari të grupit. Ky kufi është më kufizues sesa për grupimin e urës së thirrjeve, kështu që shpesh është faktori kufizues në vendosjet e shpërndara gjeografikisht.

Roli i bazës së të dhënave për një CMS ka një numër kërkesash unike. Ndryshe nga rolet e tjera, ai kërkon një certifikatë klienti dhe serveri, ku certifikata e klientit ka një fushë specifike CN që i paraqitet serverit.

CMS përdor një bazë të dhënash postgres me një master dhe disa kopje krejtësisht identike. Ekziston vetëm një bazë e të dhënave kryesore në të njëjtën kohë ("serveri i bazës së të dhënave"). Anëtarët e mbetur të grupit janë kopje ose "klientë të bazës së të dhënave".

Një grup bazë të dhënash kërkon një certifikatë të dedikuar të serverit dhe një certifikatë klienti. Ato duhet të nënshkruhen nga certifikata, zakonisht një autoritet i brendshëm privat i certifikatës. Për shkak se çdo anëtar i grupit të bazës së të dhënave mund të bëhet master, serveri i bazës së të dhënave dhe çiftet e certifikatave të klientit (që përmbajnë çelësat publikë dhe privatë) duhet të kopjohen në të gjithë serverët në mënyrë që ata të mund të marrin identitetin e klientit ose serverit të bazës së të dhënave. Përveç kësaj, certifikata rrënjësore CA duhet të ngarkohet për të siguruar që certifikatat e klientit dhe serverit mund të verifikohen.

Pra, ne krijojmë një kërkesë për një certifikatë që do të përdoret nga të gjitha shërbimet e serverit përveç bazës së të dhënave (do të ketë një kërkesë të veçantë për këtë) me një komandë si:

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

Në CN ne shkruajmë emrin e përgjithshëm të serverëve tanë. Për shembull, nëse emrat e hosteve të serverëve tanë server 01, server 02, server 03, atëherë CN do të jetë server.shembull.com

Ne bëjmë të njëjtën gjë në dy serverët e mbetur me ndryshimin që komandat do të përmbajnë "emrat e hosteve" përkatës.

Ne gjenerojmë dy kërkesa për certifikata që do të përdoren nga shërbimi i bazës së të dhënave me komanda si:

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

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

pki csr dbclusterclient CN:postgres

ku serveri dbcluster и dbclusterclient emrat e kërkesave tona dhe certifikatat e ardhshme, emri i hostit1(2)(3) emrat e serverëve përkatës.

Ne e kryejmë këtë procedurë vetëm në një server (!) dhe do të ngarkojmë certifikatat dhe skedarët .key përkatës në serverë të tjerë.

Aktivizo modalitetin e certifikatës së klientit në AD CSServeri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Ju gjithashtu duhet të bashkoni certifikatat për çdo server në një skedar.Në *NIX: 

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

Në Windows/DOS: 

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

Dhe ngarkoni në secilin server:
1. Certifikata e serverit “Individual”.
2. Certifikata rrënjësore (së bashku me ato të ndërmjetme, nëse ka).
3. Certifikatat për bazën e të dhënave (“server” dhe “klient”) dhe skedarë me ekstensionin .key, të cilat janë krijuar gjatë krijimit të një kërkese për certifikatat e bazës së të dhënave “server” dhe “klient”. Këta skedarë duhet të jenë të njëjtë në të gjithë serverët.
4. Dosja e të tre certifikatave “individuale”.

Si rezultat, duhet të merrni diçka si kjo fotografi e skedarit në secilin server.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Grupi i bazës së të dhënave

Tani që i keni të gjitha certifikatat të ngarkuara në serverët CMS, mund të konfiguroni dhe aktivizoni grupimin e bazës së të dhënave midis tre nyjeve. Hapi i parë është të zgjidhni një server si nyjen kryesore të grupit të bazës së të dhënave dhe ta konfiguroni plotësisht atë.

Baza e të dhënave Master

Hapi i parë në konfigurimin e riprodhimit të bazës së të dhënave është të specifikoni certifikatat që do të përdoren për bazën e të dhënave. Kjo bëhet duke përdorur një komandë si:

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

Tani le t'i tregojmë CMS-së se cilën ndërfaqe të përdorë për grumbullimin e bazës së të dhënave me komandën:

database cluster localnode a

Pastaj ne inicializojmë bazën e të dhënave të grupimit në serverin kryesor me komandën:

database cluster initialize

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Nyjet e bazës së të dhënave të klientit

Ne bëjmë të njëjtën procedurë, vetëm në vend të komandës Inicializimi i grupit të bazës së të dhënave shkruani një komandë si:

database cluster join <ip address existing master>

ku adresa ip adresa ekzistuese ip e serverit CMS në të cilin grupi është inicializuar, thjesht Master.

Ne kontrollojmë se si funksionon grupi ynë i bazës së të dhënave në të gjithë serverët me komandën:

database cluster status

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Ne bëjmë të njëjtën gjë në serverin e tretë të mbetur.

Si rezultat, rezulton se serveri ynë i parë është Master, pjesa tjetër janë skllevër.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Shërbimi i Administrimit të Uebit

Aktivizo shërbimin e administratorit të uebit:

webadmin listen a 445

Porti 445 u zgjodh sepse porti 443 përdoret për aksesin e përdoruesit në klientin në ueb

Ne konfigurojmë shërbimin Web Admin me skedarë certifikatash me një komandë si:

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

Dhe aktivizoni Web Admin me komandën:

webadmin enable

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Nëse gjithçka është mirë, do të marrim linja SUCCESS që tregojnë se Administratori i Uebit është konfiguruar saktë për rrjetin dhe certifikatën. Ne kontrollojmë funksionalitetin e shërbimit duke përdorur një shfletues në internet dhe futim adresën e administratorit të uebit, për shembull: cms.example.com: 445

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Call Bridge Cluster

Call Bridge është i vetmi shërbim i pranishëm në çdo vendosje CMS. Call Bridge është mekanizmi kryesor i konferencave. Ai gjithashtu siguron një ndërfaqe SIP në mënyrë që thirrjet të mund të drejtohen në ose nga ajo, për shembull, një CM e Unifikuar Cisco.

Komandat e përshkruara më poshtë duhet të ekzekutohen në çdo server me certifikatat e duhura.
Pra:

Ne i lidhim certifikatat me shërbimin Call Bridge me një komandë si:

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

Ne lidhim shërbimet e CallBridge me ndërfaqen që na nevojitet me komandën:

callbridge listen a

Dhe rinisni shërbimin me komandën:

callbridge restart

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Tani që kemi konfiguruar Call Bridges, ne mund të konfigurojmë grupimin e urës së thirrjeve. Grumbullimi i urës së thirrjeve është i ndryshëm nga grupimi i bazës së të dhënave ose XMPP. Call Bridge Cluster mund të mbështesë nga 2 deri në 8 nyje pa asnjë kufizim. Ai siguron jo vetëm tepricë, por edhe balancimin e ngarkesës në mënyrë që konferencat të mund të shpërndahen në mënyrë aktive nëpër serverët e Call Bridge duke përdorur shpërndarje inteligjente të thirrjeve. CMS ka veçori shtesë, grupe Call Bridge dhe veçori të ngjashme që mund të përdoren për menaxhim të mëtejshëm.

Grumbullimi i urës së thirrjeve konfigurohet kryesisht përmes ndërfaqes së administratorit në internet
Procedura e përshkruar më poshtë duhet të kryhet në çdo server në grup.
Pra,

1. Kaloni nëpër ueb te Konfigurimi > Grup.
2. në Call Bridge ID Si emër unik, vendosni callbridge[01,02,03] që korrespondon me emrin e serverit. Këta emra janë arbitrar, por duhet të jenë unikë për këtë grup. Ato janë përshkruese në natyrë sepse tregojnë se janë identifikues të serverit [01,02,03].
3.B Urat e thirrjeve të grumbulluara futni URL-të e administratorit të uebit të serverëve tanë në grup, CMS[01,02,03].example.com:445, në fushën Adresa. Sigurohuni që të specifikoni portin. Mund ta lini bosh domenin SIP të lidhjes Peer.
4. Shtoni një certifikatë në besimin CallBridge të çdo serveri, skedari i të cilit përmban të gjitha certifikatat e serverëve tanë, të cilat i kemi bashkuar në këtë skedar që në fillim, me një komandë si: 

callbridge trust cluster <trusted cluster certificate bundle>

Dhe rinisni shërbimin me komandën:

callbridge restart

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Si rezultat, në secilin server duhet të merrni këtë foto:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Grupi XMPP

Shërbimi XMPP në CMS përdoret për të trajtuar të gjithë regjistrimin dhe vërtetimin për aplikacionet e takimeve Cisco (CMA), duke përfshirë klientin në internet CMA WebRTC. Vetë Call Bridge gjithashtu vepron si një klient XMPP për qëllime vërtetimi dhe për këtë arsye duhet të konfigurohet si klientët e tjerë. Toleranca e gabimeve XMPP është një veçori që është mbështetur në mjediset e prodhimit që nga versioni 2.1

Komandat e përshkruara më poshtë duhet të ekzekutohen në çdo server me certifikatat e duhura.
Pra:

Ne i lidhim certifikatat me shërbimin XMPP me një komandë si:

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

Pastaj përcaktoni ndërfaqen e dëgjimit me komandën:

xmpp listen a

Shërbimi XMPP kërkon një domen unik. Ky është login për përdoruesit. Me fjalë të tjera, kur një përdorues përpiqet të identifikohet duke përdorur aplikacionin CMA (ose përmes klientit WebRTC), ai fut userID@logindomain. Në rastin tonë do të jetë userid@conf.shembull.com. Pse nuk është vetëm shembull.com? Në vendosjen tonë të veçantë, ne zgjodhëm domenin tonë të unifikuar CM që përdoruesit e Jabber do ta përdorin në Unified CM si shembull.com, kështu që na duhej një domen tjetër për përdoruesit e CMS për të drejtuar thirrjet drejt dhe nga CMS përmes domeneve SIP.

Vendosni një domen XMPP duke përdorur një komandë si:

xmpp domain <domain>

Dhe aktivizoni shërbimin XMPP me komandën:

xmpp enable

Në shërbimin XMPP, duhet të krijoni kredenciale për çdo Call Bridge që do të përdoret kur regjistroheni me shërbimin XMPP. Këta emra janë arbitrarë (dhe nuk lidhen me emrat unikë që keni konfiguruar për grupimin e urës së thirrjeve). Duhet të shtoni tre ura thirrjesh në një server XMPP dhe më pas t'i vendosni ato kredenciale në serverët e tjerë XMPP në grup, sepse ky konfigurim nuk përshtatet në bazën e të dhënave të grupit. Më vonë ne do të konfigurojmë çdo Call Bridge për të përdorur këtë emër dhe sekret për t'u regjistruar në shërbimin XMPP.

Tani duhet të konfigurojmë shërbimin XMPP në serverin e parë me tre Call Bridges callbridge01, callbridge02 dhe callbridge03. Secilës llogari do t'i caktohen fjalëkalime të rastësishme. Ata më vonë do të futen në serverë të tjerë Call Bridge për t'u identifikuar në këtë server XMPP. Futni komandat e mëposhtme:

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

Si rezultat, ne kontrollojmë se çfarë ndodhi me komandën:

xmpp callbridge list

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Pikërisht e njëjta foto duhet të shfaqet në serverët e mbetur pas hapave të përshkruar më poshtë.

Më pas, ne shtojmë saktësisht të njëjtat cilësime në dy serverët e mbetur, vetëm me komanda

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

Ne e shtojmë Secret me shumë kujdes që, për shembull, të mos ketë hapësira shtesë në të.
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Si rezultat, çdo server duhet të ketë të njëjtën pamje:

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Më pas, në të gjithë serverët në grup, ne specifikojmë në besim skedarin që përmban të tre certifikatat, të krijuara më herët me një komandë si kjo:

xmpp cluster trust <trust bundle>

Ne aktivizojmë modalitetin e grupit xmpp në të gjithë serverët e grupimeve me komandën:

xmpp cluster enable

Në serverin e parë të grupit, ne fillojmë krijimin e një grupi xmpp me komandën:

xmpp cluster initialize

Në serverët e tjerë, shtoni një grup në xmpp me një komandë si:

xmpp cluster join <ip address head xmpp server>

Ne kontrollojmë në secilin server suksesin e krijimit të një grupi XMPP në secilin server me komandat:

xmpp status
xmpp cluster status

Serveri i parë:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri i dytë:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri i tretë:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Lidhja e Call Bridge me XMPP

Tani që grupi XMPP po funksionon, ju duhet të konfiguroni shërbimet e Call Bridge për t'u lidhur me grupin XMPP. Ky konfigurim bëhet përmes administratorit të internetit.

Në secilin server, shkoni te Konfigurimi > Të përgjithshme dhe në fushë Emri unik i Call Bridge shkruani emra unikë Call Bridge që korrespondojnë me serverin callbridge[01,02,03]Me Në fushë Fushë conf.example.ru dhe fjalëkalimet përkatëse, ju mund t'i spiunoni ato
në çdo server në grup me komandën:

xmpp callbridge list

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Lëreni fushën "Server" bosh Calbridge do të kryejë një kërkim DNS SRV për _xmpp-component._tcp.conf.example.compër të gjetur një server XMPP të disponueshëm. Adresat IP për lidhjen e urave telefonike me XMPP mund të ndryshojnë në secilin server, kjo varet nga ato vlera që kthehen në kërkesën e regjistrimit _xmpp-component._tcp.conf.example.com callbridge, e cila nga ana tjetër varet nga cilësimet e përparësisë për një rekord të caktuar DNS.

Më pas, shkoni te Statusi > Të përgjithshme për të verifikuar nëse shërbimi Call Bride është lidhur me sukses me shërbimin XMPP.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Ura e Uebit

Në secilin server në grup, aktivizoni shërbimin Web Bridge me komandën:

webbridge listen a:443

Ne konfigurojmë shërbimin Web Bridge me skedarë certifikatash me një komandë si:

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

Web Bridge mbështet HTTPS. Ai do të ridrejtojë HTTP në HTTPS nëse konfigurohet të përdorë "http-redirect".
Për të aktivizuar ridrejtimin HTTP, përdorni komandën e mëposhtme:

webbridge http-redirect enable

Për të bërë të ditur Call Bridge se Web Bridge mund të besojë lidhjet nga Call Bridge, përdorni komandën:

webbridge trust <certfile>

ku ky është një skedar që përmban të tre certifikatat nga secili server në grup.

Kjo fotografi duhet të jetë në çdo server në grup.
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Tani duhet të krijojmë një përdorues me rolin "appadmin", na duhet në mënyrë që të mund të konfigurojmë grupin tonë (!), dhe jo çdo server në grup veç e veç, në këtë mënyrë cilësimet do të aplikohen në mënyrë të barabartë për secilin server pavarësisht fakti që ato do të bëhen një herë.
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Për konfigurim të mëtejshëm do të përdorim postier.

Për autorizim, zgjidhni Basic në seksionin Autorizim

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Për të dërguar saktë komanda në serverin CMS, duhet të vendosni kodimin e kërkuar

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Specifikojmë Webbridge me komandën POST me parametër url dhe kuptimi cms.example.com

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Në vetë webbridge, ne tregojmë parametrat e kërkuar: aksesi i mysafirëve, aksesi i mbrojtur, etj.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Thirrni grupet e urës

Si parazgjedhje, CMS nuk përdor gjithmonë në mënyrë më efikase burimet e konferencave të disponueshme për të.

Për shembull, për një takim me tre pjesëmarrës, secili pjesëmarrës mund të përfundojë në tre ura të ndryshme thirrjesh. Në mënyrë që këta tre pjesëmarrës të komunikojnë me njëri-tjetrin, Call Bridges do të krijojë automatikisht lidhje midis të gjithë serverëve dhe klientëve në të njëjtën Hapësirë, në mënyrë që gjithçka të duket sikur të gjithë klientët janë në të njëjtin server. Fatkeqësisht, e keqja e kësaj është se një konferencë e vetme me 3 persona tani do të konsumojë 9 porte mediatike. Ky është padyshim një përdorim joefikas i burimeve. Për më tepër, kur një Call Bridge është vërtet e mbingarkuar, mekanizmi i parazgjedhur është të vazhdohet të pranojë telefonata dhe të ofrojë shërbime me cilësi të reduktuar për të gjithë abonentët e asaj Call Bridge.

Këto probleme zgjidhen duke përdorur veçorinë Call Bridge Group. Kjo veçori u prezantua në versionin 2.1 të softuerit Cisco Meeting Server dhe është zgjeruar për të mbështetur balancimin e ngarkesës për thirrjet hyrëse dhe dalëse të Cisco Meeting App (CMA), duke përfshirë pjesëmarrësit në WebRTC.

Për të zgjidhur problemin e rilidhjes, janë futur tre kufizime të konfigurueshme të ngarkesës për çdo Call Bridge:

Kufiri i Ngarkesës — kjo është ngarkesa numerike maksimale për një Call Bridge të veçantë. Çdo platformë ka një kufi të rekomanduar ngarkese, si p.sh. 96000 për CMS1000 dhe 1.25 GHz për vCPU për makinën virtuale. Thirrjet e ndryshme konsumojnë një sasi të caktuar burimesh në varësi të rezolucionit dhe shpejtësisë së kuadrove të pjesëmarrësit.
NewConferenceLoadLimitBasisPoints (i parazgjedhur 50% loadLimit) - vendos kufirin e ngarkesës së serverit, pas së cilës refuzohen konferencat e reja.
ExistingConferenceLoadLimitBasisPoints (e parazgjedhur 80% e loadLimit) - vlera e ngarkesës së serverit pas së cilës pjesëmarrësit që i bashkohen një konference ekzistuese do të refuzohen.

Ndërkohë që kjo veçori është krijuar për shpërndarjen e thirrjeve dhe balancimin e ngarkesës, grupe të tjera si TURN Serverët, Serverët e Urës së Uebit dhe Regjistruesit mund t'u caktohen gjithashtu Call Bridge Groups në mënyrë që ato gjithashtu të mund të grupohen siç duhet për përdorim optimal. Nëse ndonjë prej këtyre objekteve nuk i caktohet një grupi thirrjesh, ata supozohet se janë të disponueshëm për të gjithë serverët pa ndonjë përparësi të veçantë.

Këta parametra janë konfiguruar këtu: cms.example.com:445/api/v1/system/configuration/cluster

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Më pas, ne i tregojmë secilës callbridge se cilit grup callbridge i përket:

Ura e parë telefonike
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Ura e dytë e thirrjes
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Ura e tretë e thirrjes
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Kështu, ne konfiguruam grupin Call Brdige për të përdorur në mënyrë më efikase burimet e grupit të Serverit të Takimeve Cisco.

Importimi i përdoruesve nga Active Directory

Shërbimi Web Admin ka një seksion konfigurimi LDAP, por ai nuk ofron opsione komplekse konfigurimi dhe informacioni nuk ruhet në bazën e të dhënave të grupimit, kështu që konfigurimi do të duhet të bëhet, ose manualisht në secilin server nëpërmjet ndërfaqes së uebit, ose përmes API, dhe në mënyrë që ne "tri herë "Mos u ngrit" ne do të vendosim përsëri të dhënat përmes API-së.

Përdorimi i URL-së për të hyrë cms01.example.com:445/api/v1/ldapServers krijojnë një objekt të Serverit LDAP, duke specifikuar parametra të tillë si:

  • IP e serverit
  • numri i portit
  • emri i përdoruesit
  • fjalëkalim
  • i sigurt

Sigurt - zgjidhni true ose false në varësi të portit, 389 - jo i sigurt, 636 - i mbrojtur.
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Hartimi i parametrave të burimit LDAP me atributet në Serverin e Takimeve Cisco.
Hartëzimi LDAP lidh atributet në drejtorinë LDAP me atributet në CMS. Atributet aktuale:

  • jidMapping
  • harta e emrit
  • coSpaceNameMapping
  • coSpaceUriMapping
  • coSpaceSecondaryUriMapping

Përshkrimi i atributeveIADB përfaqëson ID-në e hyrjes së përdoruesit në CMS. Meqenëse ky është një server LDAP i Microsoft Active Directory, CMS JID hartohet në sAMAccountName në LDAP, i cili në thelb është ID-ja e hyrjes në Active Directory e përdoruesit. Gjithashtu vini re se merrni sAMAccountName dhe shtoni domenin conf.pod6.cms.lab në fund të tij, sepse ky është identifikimi që përdoruesit tuaj do të përdorin për t'u identifikuar në CMS.

harta e emrit përputhet me atë që përmbahet në fushën "Emri i ekranit të Active Directory" me fushën e emrit CMS të përdoruesit.

coSpaceNameMapping krijon një emër të hapësirës CMS bazuar në fushën displayName. Ky atribut, së bashku me atributin coSpaceUriMapping, është ajo që kërkohet për të krijuar një hapësirë ​​për çdo përdorues.

coSpaceUriMapping përcakton pjesën e përdoruesit të URI-së të lidhur me hapësirën personale të përdoruesit. Disa domene mund të konfigurohen për t'u thirrur në hapësirë. Nëse pjesa e përdoruesit përputhet me këtë fushë për një nga këto domene, thirrja do të drejtohet në hapësirën e atij përdoruesi.

coSpaceSecondaryUriMapping përcakton një URI të dytë për të arritur hapësirën. Kjo mund të përdoret për të shtuar një pseudonim numerik për drejtimin e thirrjeve në hapësirën e përdoruesit të importuar si një alternativë ndaj URI-së alfanumerik të përcaktuar në parametrin coSpaceUriMapping.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Serveri LDAP dhe harta LDAP janë konfiguruar. Tani ju duhet t'i lidhni ato së bashku duke krijuar një burim LDAP.

Përdorimi i URL-së për të hyrë cms01.example.com:445/api/v1/ldapSource krijoni një objekt Burimi LDAP, duke specifikuar parametra të tillë si:

  • server
  • planifikim
  • bazëDn
  • filter

Tani që konfigurimi i LDAP ka përfunduar, mund të kryeni operacionin e sinkronizimit manual.

Ne e bëjmë këtë ose në ndërfaqen Web të çdo serveri duke klikuar Sinkronizo tani seksion Active Directory
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

ose nëpërmjet API-së me komandën POST duke përdorur URL për të hyrë cms01.example.com:445/api/v1/ldapSyncs

Konferenca ad-hoc

Çfarë është kjo?Në konceptin tradicional, një konferencë është kur dy pjesëmarrës janë duke folur me njëri-tjetrin, dhe njëri prej pjesëmarrësve (duke përdorur një pajisje të regjistruar me Unified CM) shtyp butonin "Konferenca", thërret personin tjetër dhe pasi flet me atë palë të tretë , shtyp sërish butonin "Konferenca" për t'u bashkuar me të gjithë pjesëmarrësit në konferencën trepalëshe.

Ajo që e dallon një konferencë Ad-Hoc nga një konferencë e planifikuar në një CMS është se një konferencë Ad-Hoc nuk është thjesht një thirrje SIP në CMS. Kur iniciatori i konferencës klikon butonin e konferencës për herë të dytë për të ftuar të gjithë në të njëjtin takim, CM e unifikuar duhet të bëjë një thirrje API në CMS për të krijuar një konferencë në lëvizje, në të cilën të gjitha thirrjet transferohen më pas. E gjithë kjo ndodh pa u vënë re nga pjesëmarrësit.

Kjo do të thotë që Unified CM duhet të konfigurojë kredencialet API dhe adresën/portin WebAdmin të shërbimit, si dhe trunkun SIP direkt në serverin CMS për të vazhduar thirrjen.

Nëse është e nevojshme, CUCM mund të krijojë në mënyrë dinamike një hapësirë ​​në CMS në mënyrë që çdo thirrje të mund të arrijë në CMS dhe të përputhet me rregullin e thirrjes hyrëse që është menduar për hapësirat.

Integrimi me CUCM konfiguruar në të njëjtën mënyrë siç përshkruhet në artikull më herët përveç se në Cisco UCM ju duhet të krijoni tre trunk për CMS, tre ura të konferencës, në profilin e sigurisë SIP specifikoni tre emra subjektesh, grupet e rrugëve, listat e rrugëve, grupet e burimeve të mediave dhe listat e grupeve të burimeve të mediave dhe shtoni disa rregulla rrugëtimi në Serverin e Takimeve Cisco.

Profili i Sigurisë SIP:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Trungjet:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Çdo trung duket i njëjtë:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Ura e Konferencës
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Çdo urë e konferencës duket e njëjtë:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Grupi i rrugëve
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Lista e rrugëve
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Grupi i Burimeve Mediatike
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Lista e grupeve të burimeve mediatike
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Rregullat e thirrjes

Ndryshe nga sistemet më të avancuara të menaxhimit të thirrjeve si Unified CM ose Expressway, CMS kërkon vetëm domenin në fushën SIP Request-URI për thirrje të reja. Pra, nëse SIP INVITE është për gllënjkë: [email mbrojtur]CMS kujdeset vetëm për domain.com. CMS ndjek këto rregulla për të përcaktuar se ku të drejtohet një telefonatë:

1. CMS së pari përpiqet të përputhet me domenin SIP me domenet e konfiguruara në rregullat e thirrjeve hyrëse. Këto telefonata më pas mund të drejtohen në hapësira ("të synuara") ose përdorues specifikë, IVR të brendshme ose destinacione të integruara drejtpërdrejt të Microsoft Lync/Skype për Biznes (S4B).
2. Nëse nuk ka përputhje në rregullat e thirrjeve hyrëse, CMS do të përpiqet të përputhet me domenin e konfiguruar në tabelën e përcjelljes së thirrjeve. Nëse bëhet një përputhje, rregulli mund të refuzojë në mënyrë eksplicite thirrjen ose ta përcjellë thirrjen. Në këtë kohë, CMS mund të rishkruajë domenin, i cili ndonjëherë është i dobishëm për thirrjen e domeneve Lync. Ju gjithashtu mund të zgjidhni të kaloni hedhjen, që do të thotë se asnjë nga fushat nuk do të modifikohet më tej, ose të përdorni një plan të brendshëm të telefonimit CMS. Nëse nuk ka përputhje në rregullat e përcjelljes së thirrjeve, parazgjedhja është refuzimi i telefonatës. Mbani parasysh se në CMS, megjithëse thirrja është "përcjellur", media është ende e lidhur me CMS, që do të thotë se do të jetë në rrugën e sinjalizimit dhe trafikut të medias.
Atëherë vetëm thirrjet e përcjella i nënshtrohen rregullave të thirrjeve dalëse. Këto cilësime përcaktojnë destinacionet ku dërgohen telefonatat, llojin e trungut (qoftë një telefonatë e re Lync ose një telefonatë standarde SIP) dhe çdo konvertim që mund të kryhet nëse transferimi nuk zgjidhet në rregullin e përcjelljes së thirrjeve.

Këtu është regjistri aktual i asaj që ndodh gjatë një konference Ad-Hoc

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Pamja e ekranit e tregon atë dobët (nuk di si ta përmirësoj), kështu që do ta shkruaj regjistrin si ky:

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

Vetë konferenca ad-hoc:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Rregullat e thirrjeve hyrëse
Konfigurimi i parametrave të thirrjeve në hyrje është i nevojshëm për të qenë në gjendje të merrni një telefonatë në CMS. Siç e patë në konfigurimin e LDAP, të gjithë përdoruesit u importuan me domenin conf.pod6.cms.lab. Pra, të paktën, ju dëshironi që thirrjet në këtë domen për të synuar hapësirat. Do t'ju duhet gjithashtu të vendosni rregulla për gjithçka që synohet për emrin e domain-it plotësisht të kualifikuar (dhe ndoshta edhe adresën IP) të secilit prej serverëve CMS. Kontrolli ynë i jashtëm i thirrjeve, Unified CM, do të konfigurojë trunk-et SIP të dedikuara për secilin prej serverëve CMS individualisht. Në varësi të faktit nëse destinacioni i këtyre trunk-eve SIP është një adresë IP ose FQDN e serverit do të përcaktojë nëse CMS duhet të konfigurohet për të pranuar thirrje të drejtuara në adresën e tij IP ose FQDN.

Domeni që ka rregullin hyrës me prioritet më të lartë përdoret si domen për çdo hapësirë ​​përdoruesi. Kur përdoruesit sinkronizohen nëpërmjet LDAP, CMS krijon automatikisht hapësira, por vetëm pjesën e përdoruesit të URI-së (coSpaceUriMapping), për shembull, user.space. Pjesë sferë URI e plotë krijohet bazuar në këtë rregull. Në fakt, nëse do të identifikoheshit në Web Bridge në këtë pikë, do të shihni se URI Hapësirë ​​nuk ka një domen. Duke vendosur këtë rregull si prioritetin më të lartë, ju po vendosni domenin për hapësirat e krijuara konf.shembull.com.
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Rregullat e thirrjeve dalëse

Për t'i lejuar përdoruesit të bëjnë thirrje dalëse në grupin e unifikuar CM, duhet të konfiguroni rregullat dalëse. Domeni i pikave fundore të regjistruara me CM të unifikuar, si Jabber, është shembull.com. Thirrjet drejt këtij domeni duhet të drejtohen si thirrje standarde SIP drejt nyjeve të unifikuara të përpunimit të thirrjeve CM. Serveri kryesor është cucm-01.example.com dhe serveri shtesë është cucm-02.example.com.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave
Rregulli i parë përshkruan drejtimin më të thjeshtë të thirrjeve ndërmjet serverëve të grupimit.

Fushë Lokale nga domeni është përgjegjës për atë që do të shfaqet në SIP-URI të telefonuesit për personin që thirret pas simbolit "@". Nëse e lëmë bosh, atëherë pas simbolit “@” do të jetë adresa IP e CUCM përmes së cilës kalon kjo thirrje. Nëse specifikojmë një domen, atëherë pas simbolit "@" do të ketë në të vërtetë një domen. Kjo është e nevojshme për të qenë në gjendje të telefononi, përndryshe nuk do të jetë e mundur të telefononi përsëri përmes SIP-URI name@ip-adresa.

Telefononi kur tregohet Lokale nga domeni
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Thirrni kur NUK tregohet Lokale nga domeni
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Sigurohuni që të specifikoni në mënyrë eksplicite Encrypted ose Unencrypted për thirrjet dalëse, sepse asgjë nuk funksionon me parametrin Auto.

Regjistrimi

Video-konferencat regjistrohen nga serveri i Regjistrimit. Regjistruesi është saktësisht i njëjtë me Serverin e Takimeve Cisco. Regjistruesi nuk kërkon instalimin e asnjë licence. Licencat e regjistrimit kërkohen për serverët që ekzekutojnë shërbimet e CallBridge, d.m.th. kërkohet një licencë regjistrimi dhe duhet të aplikohet në komponentin CallBridge dhe jo te serveri që funksionon Recorder. Regjistruesi sillet si një klient i Zgjerueshëm i Mesazheve dhe Protokollit të Prezencës (XMPP), kështu që serveri XMPP duhet të aktivizohet në serverin që pret CallBridge.

Sepse Ne kemi një grup dhe licenca duhet të "shtrihet" në të tre serverët në grup. Pastaj thjesht në llogarinë tuaj personale në licencat ne shoqërojmë (shtojmë) adresat MAC të ndërfaqeve a të të gjithë serverëve CMS të përfshirë në grup.

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Dhe kjo është fotografia që duhet të jetë në çdo server në grup

Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Në përgjithësi, ekzistojnë disa skenarë për vendosjen e Regjistruesit, por ne do t'i përmbahemi kësaj:
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Përpara se të konfiguroni Regjistruesin, duhet të përgatisni një vend ku do të regjistrohen realisht videokonferencat. Në fakt këtu lidhje, si të konfiguroni të gjithë regjistrimin. Përqendrohem në pika dhe detaje të rëndësishme:

1. Është më mirë të hiqni certifikatën nga serveri i parë në grup.
2. Gabimi "Regjistruesi nuk është i disponueshëm" mund të ndodhë sepse certifikata e gabuar është specifikuar në Trustin e Regjistruesit.
3. Shkrimi mund të mos funksionojë nëse drejtoria NFS e specifikuar për regjistrim nuk është direktoria kryesore.

Ndonjëherë ka nevojë të regjistrohet automatikisht një konferencë e një përdoruesi ose hapësire specifike.

Për këtë, krijohen dy CallProfiles:
Me regjistrim të çaktivizuar
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Dhe me funksion regjistrimi automatik
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Më pas, ne "bashkëngjisim" një CallProfile me një funksion regjistrimi automatik në hapësirën e kërkuar.
Serveri Cisco Meeting 2.5.2. Grup në modalitetin e shkallëzuar dhe elastik me funksionin e regjistrimit të videokonferencave

Në CMS është vendosur kështu që nëse një CallProfile është i lidhur në mënyrë eksplicite me ndonjë hapësirë ​​ose hapësirë, atëherë ky CallProfile funksionon vetëm në lidhje me këto hapësira specifike. Dhe nëse CallProfile nuk është i lidhur me asnjë hapësirë, atëherë si parazgjedhje ai aplikohet në ato hapësira për të cilat asnjë CallProfile nuk është i lidhur në mënyrë eksplicite.

Herën tjetër do të përpiqem të përshkruaj se si aksesohet CMS jashtë rrjetit të brendshëm të organizatës.

Burimet:

Burimi: www.habr.com

Shto një koment