Katika toleo hili nitaonyesha na kuelezea baadhi ya ugumu wa kusanidi seva ya CMS katika hali ya nguzo ya kushindwa.
NadhariaKwa ujumla, kuna aina tatu za uwekaji wa seva ya CMS:
- Single Pamoja(Single pamoja), i.e. hii ni seva moja ambayo huduma zote muhimu zinafanya kazi. Mara nyingi, aina hii ya utumiaji inafaa tu kwa ufikiaji wa mteja wa ndani na katika mazingira madogo ambapo vikwazo vya uwekaji na upunguzaji wa seva moja si suala muhimu, au katika hali ambapo CMS hufanya kazi fulani pekee, kama vile dharula. mikutano juu ya Cisco UCM.
Mpango wa takriban wa kazi:
- Mgawanyiko Mmoja(Mgawanyiko Mmoja) huongeza aina ya awali ya matumizi kwa kuongeza seva tofauti kwa ufikiaji wa nje. Katika utumaji uliopitwa na wakati, hii ilimaanisha kupeleka seva ya CMS katika sehemu ya mtandao isiyohamishika (DMZ) ambapo wateja wa nje wangeweza kuifikia, na seva moja ya CMS katika msingi wa mtandao ambapo wateja wa ndani wangeweza kufikia CMS. Mtindo huu mahususi wa upelekaji sasa unabadilishwa na kinachojulikana kama aina Ukingo Mmoja, ambayo inajumuisha seva Cisco Expressway, ambayo ina au itakuwa na uwezo mwingi sawa wa kukwepa Firewall ili wateja hawahitaji kuongeza seva ya CMS yenye makali maalum.
Mpango wa takriban wa kazi:
- Mzito na Ustahimilivu(Inaweza Kuvumilia na Kustahimili Makosa) Aina hii ni pamoja na kutotumika tena kwa kila sehemu, kuruhusu mfumo ukue na mahitaji yako hadi kiwango chake cha juu huku ukitoa usaidizi iwapo kutafeli. Pia hutumia dhana ya Single Edge kutoa ufikiaji salama wa nje. Hii ndiyo aina tutakayoiangalia katika kipindi hiki. Ikiwa tutaelewa jinsi ya kusambaza aina hii ya nguzo, hatutaelewa tu aina nyingine za uwekaji, lakini pia tutaweza kuelewa jinsi ya kuunda makundi ya seva za CMS ili kukidhi ukuaji wa mahitaji unaowezekana.
Kabla ya kuendelea na kupelekwa, unahitaji kuelewa baadhi ya mambo ya msingi, yaani
Vipengele kuu vya programu ya CMS:
- Database: Hukuruhusu kuchanganya baadhi ya usanidi, kama vile mpango wa kupiga simu, nafasi za watumiaji na watumiaji wenyewe. Inaauni nguzo kwa upatikanaji wa juu (bwana mmoja) pekee.
- Piga simu Bridge: huduma ya mikutano ya sauti na video ambayo hutoa udhibiti kamili wa usimamizi na uchakataji wa simu na michakato ya medianuwai. Inaauni nguzo kwa upatikanaji wa juu na scalability.
- Seva ya XMPP: kuwajibika kwa usajili na uthibitishaji wa wateja kwa kutumia Maombi ya Mkutano wa Cisco na/au WebRTC(mawasiliano ya wakati halisi, au tu kwenye kivinjari), pamoja na ishara ya sehemu. Inaweza kuunganishwa kwa upatikanaji wa juu tu.
- Daraja la Wavuti: Hutoa ufikiaji wa mteja kwa WebRTC.
- Kipakiaji: Hutoa sehemu moja ya muunganisho kwa Programu za Mikutano za Cisco katika hali ya Mgawanyiko Mmoja. Inasikiliza kiolesura cha nje na mlango kwa miunganisho inayoingia. Kwa usawa, kiweka usawazishaji kinakubali miunganisho inayoingia ya TLS kutoka kwa seva ya XMPP, ambayo kupitia kwayo inaweza kubadilisha miunganisho ya TCP kutoka kwa wateja wa nje.
Katika hali yetu haitahitajika. - GEUZA seva: Hutoa Firewall bypass teknolojia ambayo inaruhusu
weka CMS yetu nyuma ya Firewall au NAT ili kuunganisha wateja wa nje kwa kutumia Cisco Meeting App au vifaa vya SIP. Katika hali yetu haitahitajika. - Msimamizi wa Wavuti: Kiolesura cha kiutawala na ufikiaji wa API, ikijumuisha kwa mikutano maalum ya Umoja wa CM.
Njia za Usanidi
Tofauti na bidhaa zingine nyingi za Cisco, Seva ya Mikutano ya Cisco inasaidia mbinu tatu za usanidi ili kushughulikia aina yoyote ya utumaji.
- Mstari wa amri (CLI): Kiolesura cha mstari wa amri kinachojulikana kama MMP kwa usanidi wa awali na majukumu ya cheti.
- Msimamizi wa Mtandao: Kimsingi kwa usanidi unaohusiana na CallBridge, haswa wakati wa kusanidi seva moja isiyojumuishwa.
- API YA REST: Hutumika kwa kazi ngumu zaidi za usanidi na kazi zilizounganishwa zinazohusiana na hifadhidata.
Mbali na hapo juu, itifaki hutumiwa SFTP kuhamisha failiβkawaida leseni, vyeti, au kumbukumbuβkwenda na kutoka kwa seva ya CMS.
Katika miongozo ya upelekaji kutoka Cisco imeandikwa kwa nyeupe na Kiingereza kwamba nguzo inahitaji kutumwa. angalau tatu seva (nodi) katika muktadha wa hifadhidata. Kwa sababu Ni kwa idadi isiyo ya kawaida tu ya nodi ndipo utaratibu wa kuchagua Mkuu mpya wa Hifadhidata utafanya kazi, na kwa ujumla Mkuu wa Hifadhidata ana muunganisho na hifadhidata nyingi za seva ya CMS.
Na kama inavyoonyesha mazoezi, seva mbili (nodi) hazitoshi kabisa. Utaratibu wa uteuzi hufanya kazi Mwalimu anapowashwa upya, seva ya Mtumwa inakuwa Mwalimu baada tu ya seva iliyowashwa upya kuletwa. Walakini, ikiwa katika kundi la seva mbili seva ya Mwalimu itatoka ghafla, basi seva ya Mtumwa haitakuwa Mwalimu, na ikiwa Mtumwa atatoka, basi seva ya Mwalimu iliyobaki itakuwa Mtumwa.
Lakini katika muktadha wa XMPP, itakuwa muhimu sana kukusanya nguzo ya seva tatu, kwa sababu. ikiwa, kwa mfano, utalemaza huduma ya XMPP kwenye mojawapo ya seva ambazo XMMP iko katika hali ya Kiongozi, basi kwenye seva iliyobaki XMPP itasalia katika hali ya Mfuasi na miunganisho ya CallBridge kwa XMPP itazimika, kwa sababu CallBridge inaunganishwa pekee na XMPP yenye hadhi ya Kiongozi. Na hii ni muhimu, kwa sababu ... hakuna hata simu moja itapigiwa.
Pia katika miongozo sawa ya upelekaji nguzo yenye seva moja ya XMPP inaonyeshwa.
Na kwa kuzingatia hapo juu, inakuwa wazi kwa nini: inafanya kazi kwa sababu iko katika hali ya kushindwa.
Kwa upande wetu, seva ya XMPP itakuwepo kwenye nodi zote tatu.
Inachukuliwa kuwa seva zetu zote tatu ziko juu.
Rekodi za DNS
Kabla ya kuanza kusanidi seva, unahitaji kuunda rekodi za DNS Π ΠΈ SRV aina:
Tafadhali kumbuka kuwa katika rekodi zetu za DNS kuna vikoa viwili mfano.com na conf.mfano.com. Example.com ni kikoa ambacho wateja wote wa Kidhibiti cha Mawasiliano cha Cisco Unified wanaweza kutumia kwa URIs zao, ambazo kuna uwezekano mkubwa kuwa ziko katika miundombinu yako au kuna uwezekano mkubwa ziwepo. Au example.com inalingana na kikoa kile kile ambacho watumiaji hutumia kwa anwani zao za barua pepe. Au mteja wa Jabber kwenye kompyuta yako ya mkononi anaweza kuwa na URI [barua pepe inalindwa]. Kikoa conf.example.com ndicho kikoa ambacho kitasanidiwa kwa watumiaji wa Seva ya Mikutano ya Cisco. Kikoa cha Seva ya Mkutano wa Cisco itakuwa conf.example.com, kwa hivyo kwa mtumiaji yule yule wa Jabber, mtumiaji@ URI angehitaji kutumiwa kuingia katika Seva ya Mikutano ya Cisco.conf.mfano.com.
Usanidi wa kimsingi
Mipangilio yote iliyoelezwa hapa chini inaonyeshwa kwenye seva moja, lakini inahitaji kufanywa kwenye kila seva kwenye nguzo.
QoS
Kwa kuwa CMS inazalisha halisi wakati trafiki nyeti kwa ucheleweshaji na upotezaji wa pakiti, katika hali nyingi inashauriwa kusanidi ubora wa huduma (QoS). Ili kufanikisha hili, CMS inasaidia pakiti za kuweka lebo na Misimbo ya Huduma Tofauti (DSCPs) inazozalisha. Ingawa uwekaji kipaumbele wa trafiki kulingana na DSCP unategemea jinsi trafiki inavyochakatwa na vipengele vya mtandao vya miundombinu yako, kwa upande wetu tutasanidi CMS yetu kwa kipaumbele cha kawaida cha DSCP kulingana na mbinu bora za QoS.
Kwenye kila seva tutaingiza amri hizi
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1AKwa hivyo, trafiki yote ya video iliwekwa alama AF41 (DSCP 0x22), trafiki yote ya sauti iliwekwa alama EF (DSCP 0x2E), aina zingine za trafiki ya muda wa chini kama vile SIP na XMPP hutumia AF31 (DSCP 0x1A).
Tunaangalia:
NTP
Itifaki ya Muda wa Mtandao (NTP) ni muhimu sio tu kwa kutoa muhuri sahihi wa saa za simu na mikutano, lakini pia kwa kuthibitisha vyeti.
Ongeza seva za NTP kwenye miundombinu yako kwa amri kama
ntp server add <server>
Kwa upande wetu, kuna seva mbili kama hizo, kwa hivyo kutakuwa na timu mbili.
Tunaangalia:
Na weka eneo la saa kwa seva yetu
DNS
Tunaongeza seva za DNS kwa CMS kwa amri kama:
dns add forwardzone <domain-name> <server ip>
Kwa upande wetu, kuna seva mbili kama hizo, kwa hivyo kutakuwa na timu mbili.
Tunaangalia:
Usanidi wa Kiolesura cha Mtandao
Tunasanidi kiolesura na amri kama:
ipv4 <interface> add <address>/<prefix length> <gateway>
Tunaangalia:
Jina la seva (Jina la mwenyeji)
Tunaweka jina la seva na amri kama:
hostname <name>
Na tunaanzisha upya.
Hii inakamilisha usanidi wa msingi.
Vyeti
NadhariaSeva ya Mikutano ya Cisco inahitaji mawasiliano yaliyosimbwa kwa njia fiche kati ya vipengele mbalimbali, na kwa hivyo, vyeti vya X.509 vinahitajika kwa matumizi yote ya CMS. Zinasaidia kuhakikisha kuwa huduma/seva inaaminiwa na seva/huduma zingine.
Kila huduma inahitaji cheti, lakini kuunda vyeti tofauti kwa kila huduma kunaweza kusababisha kuchanganyikiwa na utata usiohitajika. Kwa bahati nzuri, tunaweza kutengeneza jozi za ufunguo wa cheti cha umma na faragha na kisha kuzitumia tena kwenye huduma nyingi. Kwa upande wetu, cheti sawa kitatumika kwa Call Bridge, Seva ya XMPP, Daraja la Wavuti na Msimamizi wa Wavuti. Kwa hivyo, unahitaji kuunda jozi ya funguo za cheti cha umma na cha kibinafsi kwa kila seva kwenye nguzo.
Mkusanyiko wa hifadhidata, hata hivyo, una mahitaji maalum ya cheti na kwa hivyo unahitaji vyeti vyake ambavyo ni tofauti na vile vya huduma zingine. CMS hutumia cheti cha seva, ambacho ni sawa na vyeti vinavyotumiwa na seva zingine, lakini pia kuna cheti cha mteja kinachotumika kwa miunganisho ya hifadhidata. Vyeti vya hifadhidata hutumiwa kwa uthibitishaji na usimbaji fiche. Badala ya kutoa jina la mtumiaji na nenosiri ili mteja aunganishe kwenye hifadhidata, inatoa cheti cha mteja ambacho kinaaminiwa na seva. Kila seva katika kundi la hifadhidata itatumia jozi sawa za funguo za umma na za kibinafsi. Hii huruhusu seva zote kwenye kundi kusimba data kwa njia fiche kwa njia ambayo inaweza tu kusimbwa na seva zingine ambazo pia zinashiriki jozi sawa za funguo.
Ili upunguzaji kazi ufanye kazi, makundi ya hifadhidata lazima yawe na kiwango cha chini cha seva 3, lakini zisizidi 5, na muda wa juu wa safari ya kwenda na kurudi wa ms 200 kati ya washiriki wowote wa kundi hilo. Kikomo hiki kina vikwazo zaidi kuliko kuunganisha kwa Call Bridge, kwa hivyo mara nyingi ndicho kikwazo katika usambazaji wa kijiografia.
Jukumu la hifadhidata kwa CMS lina mahitaji kadhaa ya kipekee. Tofauti na majukumu mengine, inahitaji cheti cha mteja na seva, ambapo cheti cha mteja kina uga mahususi wa CN unaowasilishwa kwa seva.
CMS hutumia hifadhidata ya postgres iliyo na bwana mmoja na nakala kadhaa zinazofanana kabisa. Kuna hifadhidata moja tu ya msingi kwa wakati mmoja ("seva ya hifadhidata"). Wanachama waliobaki wa nguzo ni nakala au "wateja wa hifadhidata".
Kundi la hifadhidata linahitaji cheti maalum cha seva na cheti cha mteja. Lazima zitiwe saini na vyeti, kwa kawaida mamlaka ya ndani ya cheti cha kibinafsi. Kwa sababu mwanachama yeyote wa kundi la hifadhidata anaweza kuwa bwana, seva ya hifadhidata na jozi za cheti cha mteja (zilizo na funguo za umma na za kibinafsi) lazima zinakiliwe kwa seva zote ili ziweze kuchukua utambulisho wa mteja au seva ya hifadhidata. Zaidi ya hayo, cheti cha mizizi ya CA lazima kipakiwa ili kuhakikisha kuwa cheti cha mteja na seva kinaweza kuthibitishwa.
Kwa hivyo, tunaunda ombi la cheti ambacho kitatumiwa na huduma zote za seva isipokuwa hifadhidata (kutakuwa na ombi tofauti la hii) na amri kama:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
Katika CN tunaandika jina la jumla la seva zetu. Kwa mfano, ikiwa majina ya wapangishi wa seva zetu seva01, seva02, seva03, basi CN itakuwa server.example.com
Tunafanya vivyo hivyo kwenye seva mbili zilizobaki na tofauti ambayo amri zitakuwa na "majina ya mwenyeji" yanayolingana.
Tunatoa maombi mawili ya vyeti ambavyo vitatumiwa na huduma ya hifadhidata kwa amri kama vile:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresambapo dbclusterserver ΠΈ dbclusterclient majina ya maombi yetu na vyeti vya siku zijazo, jina la mwenyeji1(2)(3) majina ya seva zinazolingana.
Tunafanya utaratibu huu kwenye seva moja tu (!), na tutapakia vyeti na faili zinazolingana za .key kwa seva zingine.
Washa hali ya cheti cha mteja katika AD CS
Pia unahitaji kuunganisha vyeti kwa kila seva kwenye faili moja.Kwenye *NIX:
cat server01.cer server02.cer server03.cer > server.cerKwenye Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
Na pakia kwa kila seva:
1. Cheti cha seva cha "Mtu binafsi".
2. Cheti cha mizizi (pamoja na wale wa kati, ikiwa wapo).
3. Vyeti vya hifadhidata ("seva" na "mteja") na faili zilizo na kiendelezi cha ufunguo wa ., ambazo zilitolewa wakati wa kuunda ombi la vyeti vya hifadhidata vya "seva" na "mteja". Faili hizi lazima ziwe sawa kwenye seva zote.
4. Faili ya vyeti vyote vitatu vya "mtu binafsi".
Kama matokeo, unapaswa kupata kitu kama picha hii ya faili kwenye kila seva.
Kundi la Hifadhidata
Kwa kuwa sasa vyeti vyote vimepakiwa kwa seva za CMS, unaweza kusanidi na kuwezesha mkusanyiko wa hifadhidata kati ya nodi tatu. Hatua ya kwanza ni kuchagua seva moja kama nodi kuu ya nguzo ya hifadhidata na kuisanidi kikamilifu.
Hifadhidata kuu
Hatua ya kwanza katika kusanidi urudiaji wa hifadhidata ni kubainisha vyeti ambavyo vitatumika kwa hifadhidata. Hii inafanywa kwa kutumia amri kama hii:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Sasa hebu tuambie CMS ni kiolesura gani cha kutumia kwa kuunganisha hifadhidata na amri:
database cluster localnode aKisha tunaanzisha hifadhidata ya nguzo kwenye seva kuu na amri:
database cluster initialize
Nodi za Hifadhidata ya Wateja
Tunafanya utaratibu sawa, tu badala ya amri nguzo ya hifadhidata kuanzisha ingiza amri kama:
database cluster join <ip address existing master>ambapo anwani ya ip iliyopo ya anwani kuu ya ip ya seva ya CMS ambayo nguzo ilianzishwa, kwa kifupi Master.
Tunaangalia jinsi nguzo yetu ya hifadhidata inavyofanya kazi kwenye seva zote kwa amri:
database cluster status
Tunafanya vivyo hivyo kwenye seva ya tatu iliyobaki.
Kama matokeo, inageuka kuwa seva yetu ya kwanza ni Mwalimu, wengine ni Watumwa.
Huduma ya Msimamizi wa Wavuti
Washa huduma ya msimamizi wa wavuti:
webadmin listen a 445Port 445 ilichaguliwa kwa sababu port 443 inatumika kwa ufikiaji wa mtumiaji kwa mteja wa wavuti
Tunasanidi huduma ya Msimamizi wa Wavuti na faili za cheti na amri kama vile:
webadmin certs <keyfile> <certificatefile> <ca bundle>Na uwashe Msimamizi wa Wavuti kwa amri:
webadmin enable
Ikiwa kila kitu kiko sawa, tutapokea njia za SUCCESS zinazoonyesha kuwa Msimamizi wa Wavuti amesanidiwa ipasavyo kwa mtandao na cheti. Tunaangalia utendakazi wa huduma kwa kutumia kivinjari na kuingiza anwani ya msimamizi wa wavuti, kwa mfano: : 445
Piga Cluster ya Bridge
Call Bridge ndiyo huduma pekee iliyopo katika kila usambazaji wa CMS. Call Bridge ndio njia kuu ya mkutano. Pia hutoa kiolesura cha SIP ili simu ziweze kupitishwa au kutoka humo kwa, kwa mfano, Cisco Unified CM.
Amri zilizoelezwa hapa chini lazima zitekelezwe kwenye kila seva iliyo na vyeti vinavyofaa.
Hivyo:
Tunahusisha vyeti na huduma ya Call Bridge na amri kama vile:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Tunafunga huduma za CallBridge kwenye kiolesura tunachohitaji kwa amri:
callbridge listen aNa anza tena huduma kwa amri:
callbridge restart
Sasa kwa kuwa tumesanidi Madaraja yetu ya Simu, tunaweza kusanidi nguzo za Daraja la Simu. Kuunganisha kwa Daraja la Simu ni tofauti na hifadhidata au nguzo za XMPP. Call Bridge Cluster inaweza kusaidia kutoka nodi 2 hadi 8 bila vikwazo vyovyote. Haitoi tu upungufu, lakini pia kusawazisha mzigo ili mikutano iweze kusambazwa kikamilifu kwenye seva za Call Bridge kwa kutumia usambazaji wa simu mahiri. CMS ina vipengele vya ziada, vikundi vya Call Bridge na vipengele vinavyohusiana ambavyo vinaweza kutumika kwa usimamizi zaidi.
Uunganishaji wa daraja la simu husanidiwa kimsingi kupitia kiolesura cha msimamizi wa wavuti
Utaratibu ulioelezewa hapa chini lazima ufanyike kwenye kila seva kwenye nguzo.
Hivyo,
1. Pitia kwenye wavuti hadi Usanidi > Nguzo.
2. Katika Piga kitambulisho cha Bridge Kama jina la kipekee, ingiza callbridge[01,02,03] inayolingana na jina la seva. Majina haya ni ya kiholela, lakini lazima yawe ya kipekee kwa kundi hili. Zina maelezo kwa asili kwa sababu zinaonyesha kuwa ni vitambulishi vya seva [01,02,03].
3.B Madaraja ya Wito yaliyounganishwa ingiza URL za msimamizi wa wavuti za seva zetu kwenye nguzo, [01,02,03].example.com:445, katika uga wa Anwani. Hakikisha kutaja bandari. Unaweza kuacha kikoa cha SIP cha Peer link kikiwa tupu.
4. Ongeza cheti kwa uaminifu wa CallBridge wa kila seva, faili ambayo ina vyeti vyote vya seva zetu, ambazo tuliunganisha kwenye faili hii mwanzoni kabisa, kwa amri kama:
callbridge trust cluster <trusted cluster certificate bundle>Na anza tena huduma kwa amri:
callbridge restart
Kama matokeo, kwenye kila seva unapaswa kupata picha hii:
Kundi la XMPP
Huduma ya XMPP katika CMS inatumika kushughulikia usajili na uthibitishaji wote wa Programu za Mikutano za Cisco (CMA), ikijumuisha mteja wa wavuti wa CMA WebRTC. Call Bridge yenyewe pia hufanya kazi kama mteja wa XMPP kwa madhumuni ya uthibitishaji na kwa hivyo lazima isanidiwe kama wateja wengine. Uvumilivu wa hitilafu wa XMPP ni kipengele ambacho kimetumika katika mazingira ya uzalishaji tangu toleo la 2.1
Amri zilizoelezwa hapa chini lazima zitekelezwe kwenye kila seva iliyo na vyeti vinavyofaa.
Hivyo:
Tunahusisha vyeti na huduma ya XMPP kwa amri kama vile:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Kisha fafanua kiolesura cha kusikiliza na amri:
xmpp listen aHuduma ya XMPP inahitaji kikoa cha kipekee. Huku ndiko kuingia kwa watumiaji. Kwa maneno mengine, mtumiaji anapojaribu kuingia kwa kutumia programu ya CMA (au kupitia mteja wa WebRTC), anaingiza userID@logindomain. Kwa upande wetu itakuwa userid@conf.mfano.com. Kwa nini sio tu example.com? Katika utumaji wetu mahususi, tulichagua kikoa chetu cha Unified CM ambacho watumiaji wa Jabber watatumia katika Unified CM kama example.com, kwa hivyo tulihitaji kikoa tofauti kwa watumiaji wa CMS ili kupitisha simu kwenda na kutoka kwa CMS kupitia vikoa vya SIP.
Sanidi kikoa cha XMPP kwa kutumia amri kama:
xmpp domain <domain>Na uwezeshe huduma ya XMPP na amri:
xmpp enableKatika huduma ya XMPP, lazima uunde kitambulisho kwa kila Call Bridge ambacho kitatumika wakati wa kujisajili na huduma ya XMPP. Majina haya ni ya kiholela (na hayahusiani na majina ya kipekee uliyosanidi kwa nguzo za daraja la simu). Ni lazima uongeze madaraja matatu ya simu kwenye seva moja ya XMPP na kisha uweke vitambulisho hivyo kwenye seva zingine za XMPP kwenye nguzo kwa sababu usanidi huu hauingii kwenye hifadhidata ya nguzo. Baadaye tutasanidi kila Call Bridge ili kutumia jina hili na siri ili kujisajili na huduma ya XMPP.
Sasa tunahitaji kusanidi huduma ya XMPP kwenye seva ya kwanza iliyo na Daraja tatu za Call Bridge01, callbridge02 na callbridge03. Kila akaunti itapewa manenosiri nasibu. Baadaye zitaingizwa kwenye seva zingine za Call Bridge ili kuingia kwenye seva hii ya XMPP. Ingiza amri zifuatazo:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Kama matokeo, tunaangalia kile kilichotokea na amri:
xmpp callbridge list
Picha sawa inapaswa kuonekana kwenye seva zilizobaki baada ya hatua zilizoelezwa hapo chini.
Ifuatayo, tunaongeza mipangilio sawa kwenye seva mbili zilizobaki, tu na amri
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Tunaongeza Siri kwa uangalifu sana ili, kwa mfano, hakuna nafasi za ziada ndani yake.
Kama matokeo, kila seva inapaswa kuwa na picha sawa:
Ifuatayo, kwenye seva zote kwenye nguzo, tunabainisha kwa uaminifu faili iliyo na vyeti vyote vitatu, vilivyoundwa mapema na amri kama hii:
xmpp cluster trust <trust bundle>Tunawasha hali ya nguzo ya xmpp kwenye seva zote za nguzo kwa amri:
xmpp cluster enableKwenye seva ya kwanza ya nguzo, tunaanzisha uundaji wa nguzo ya xmpp kwa amri:
xmpp cluster initializeKwenye seva zingine, ongeza nguzo kwa xmpp na amri kama:
xmpp cluster join <ip address head xmpp server>Tunaangalia kwenye kila seva mafanikio ya kuunda nguzo ya XMPP kwenye kila seva na amri:
xmpp status
xmpp cluster statusSeva ya kwanza:
Seva ya pili:
Seva ya tatu:
Kuunganisha Daraja la Simu kwa XMPP
Kwa kuwa sasa nguzo ya XMPP inaendeshwa, unahitaji kusanidi huduma za Daraja la Simu ili kuunganisha kwenye nguzo ya XMPP. Usanidi huu unafanywa kupitia msimamizi wa wavuti.
Kwenye kila seva, nenda kwa Usanidi> Jumla na kwenye uwanja Jina la Unique Call Bridge andika majina ya kipekee yanayolingana na seva ya Call Bridge callbridge[01,02,03]... Uwanjani Domain conf.example.ru na nywila sambamba, unaweza kupeleleza juu yao
kwenye seva yoyote kwenye nguzo na amri:
xmpp callbridge list
Acha uga wa "Seva" tupu Callbridge itafanya uchunguzi wa DNS SRV kwa _xmpp-component._tcp.conf.example.comkupata seva ya XMPP inayopatikana. Anwani za IP za kuunganisha madaraja ya simu kwa XMPP zinaweza kutofautiana kwa kila seva, inategemea ni maadili gani yanarejeshwa kwa ombi la rekodi. _xmpp-component._tcp.conf.example.com callbridge, ambayo kwa upande inategemea mipangilio ya kipaumbele kwa rekodi fulani ya DNS.
Ifuatayo, nenda kwa Hali> Jumla ili kuthibitisha kama huduma ya Bibi-Piga Simu imeunganishwa kwa huduma ya XMPP.
Daraja la Wavuti
Kwenye kila seva kwenye nguzo, wezesha huduma ya Daraja la Wavuti kwa amri:
webbridge listen a:443Tunasanidi huduma ya Daraja la Wavuti na faili za cheti na amri kama:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge inasaidia HTTPS. Itaelekeza HTTP kwa HTTPS ikiwa imesanidiwa kutumia "http-redirect".
Ili kuwezesha uelekezaji upya wa HTTP, tumia amri ifuatayo:
webbridge http-redirect enableIli kuruhusu Call Bridge kujua kwamba Web Bridge inaweza kuamini miunganisho kutoka kwa Call Bridge, tumia amri:
webbridge trust <certfile>ambapo hii ni faili iliyo na cheti zote tatu kutoka kwa kila seva kwenye nguzo.
Picha hii inapaswa kuwa kwenye kila seva kwenye nguzo.
Sasa tunahitaji kuunda mtumiaji na jukumu la "appadmin", tunaihitaji ili tuweze kusanidi nguzo yetu (!), na sio kila seva kwenye nguzo kando, kwa njia hii mipangilio itatumika kwa usawa kwa kila seva licha ya ukweli kwamba zitafanywa mara moja.
Kwa usanidi zaidi tutatumia .
Kwa idhini, chagua Msingi katika sehemu ya Uidhinishaji
Ili kutuma kwa usahihi amri kwa seva ya CMS, unahitaji kuweka usimbaji unaohitajika
Tunataja Webbridge na amri POST na parameter url na thamani
Katika daraja la wavuti yenyewe, tunaonyesha vigezo vinavyohitajika: upatikanaji wa wageni, upatikanaji wa ulinzi, nk.
Piga Vikundi vya Bridge
Kwa chaguo-msingi, CMS haifanyi matumizi bora zaidi ya rasilimali za mikutano zinazopatikana kwake.
Kwa mfano, kwa mkutano na washiriki watatu, kila mshiriki anaweza kuishia kwenye Madaraja matatu tofauti ya Wito. Ili washiriki hawa watatu wawasiliane wao kwa wao, Call Bridges itaanzisha kiotomatiki miunganisho kati ya seva zote na wateja katika Nafasi moja, ili yote ionekane kana kwamba wateja wote wako kwenye seva moja. Kwa bahati mbaya, upande wa chini wa hii ni kwamba mkutano mmoja wa watu 3 sasa utatumia bandari 9 za media. Ni wazi kuwa haya ni matumizi yasiyofaa ya rasilimali. Zaidi ya hayo, Daraja la Simu linapojazwa kupita kiasi, mbinu chaguomsingi ni kuendelea kupokea simu na kutoa huduma iliyopunguzwa ya ubora kwa wateja wote wa Call Bridge.
Matatizo haya yanatatuliwa kwa kutumia kipengele cha Call Bridge Group. Kipengele hiki kilianzishwa katika toleo la 2.1 la programu ya Cisco Meeting Server na kimepanuliwa ili kusaidia kusawazisha upakiaji kwa simu zinazoingia na zinazotoka kwenye Programu ya Cisco Meeting (CMA), ikijumuisha washiriki wa WebRTC.
Ili kutatua tatizo la kuunganisha upya, vikomo vitatu vya upakiaji vimeanzishwa kwa kila Daraja la Simu:
LoadLimit - huu ndio upeo wa juu wa mzigo wa nambari kwa Daraja fulani la Simu. Kila jukwaa lina kikomo cha upakiaji kinachopendekezwa, kama vile 96000 kwa CMS1000 na 1.25 GHz kwa kila vCPU kwa mashine pepe. Simu tofauti hutumia kiasi fulani cha rasilimali kulingana na azimio na kasi ya fremu ya mshiriki.
NewConferenceLoadLimitBasisPoints (default 50% loadLimit) - huweka kikomo cha upakiaji wa seva, baada ya hapo mikutano mipya inakataliwa.
ExstingConferenceLoadLimitBasisPoints (chaguo-msingi 80% ya loadLimit) - thamani ya upakiaji wa seva ambayo baada ya hapo washiriki wanaojiunga na mkutano uliopo watakataliwa.
Ingawa kipengele hiki kiliundwa kwa ajili ya usambazaji wa simu na kusawazisha upakiaji, vikundi vingine kama vile Seva za TURN, Seva za Daraja la Wavuti na Rekoda pia vinaweza kutumwa kwa Vikundi vya Call Bridge ili pia viweze kupangwa vizuri kwa matumizi bora. Ikiwa kitu chochote kati ya hivi hakijatolewa kwa kikundi cha simu, kinachukuliwa kuwa kinapatikana kwa seva zote bila kipaumbele chochote.
Vigezo hivi vimeundwa hapa: :445/api/v1/system/configuration/cluster
Ifuatayo, tunaonyesha kwa kila callbridge ambayo ni ya kikundi cha callbridge:
Callbridge ya kwanza
Callbridge ya pili
Callbridge ya tatu
Kwa hivyo, tulisanidi kikundi cha Call Brdige ili kutumia kwa ufanisi zaidi rasilimali za Kundi la Seva ya Mikutano ya Cisco.
Inaleta watumiaji kutoka kwa Saraka Inayotumika
Huduma ya Msimamizi wa Wavuti ina sehemu ya usanidi wa LDAP, lakini haitoi chaguzi ngumu za usanidi, na habari haijahifadhiwa kwenye hifadhidata ya nguzo, kwa hivyo usanidi utalazimika kufanywa, ama kwa mikono kwenye kila seva kupitia kiolesura cha Wavuti, au kupitia API, na ili "mara tatu "Usiinuke" bado tutaweka data kupitia API.
Kutumia URL kufikia :445/api/v1/ldapServers huunda kifaa cha Seva ya LDAP, kikibainisha vigezo kama vile:
- IP ya seva
- nambari ya bandari
- jina la mtumiaji
- password
- kupata
Salama - chagua kweli au uwongo kulingana na bandari, 389 - sio salama, 636 - inalindwa.
Kupanga vigezo vya chanzo cha LDAP kwa sifa katika Seva ya Mkutano wa Cisco.
Uchoraji wa ramani wa LDAP unaonyesha sifa katika saraka ya LDAP kwa sifa katika CMS. Tabia halisi:
- jidMapping
- Upangaji wa majina
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Maelezo ya sifaJIDI inawakilisha kitambulisho cha mtumiaji cha kuingia kwenye CMS. Kwa kuwa hii ni seva ya Microsoft Active Directory LDAP, CMS JID inaelekeza kwa sAMAccountName katika LDAP, ambayo kimsingi ni Kitambulisho cha kuingia katika Saraka Inayotumika. Pia kumbuka kuwa unachukua sAMAccountName na kuongeza kikoa conf.pod6.cms.lab hadi mwisho wake kwa sababu hii ndiyo njia ya kuingia ambayo watumiaji wako watatumia kuingia kwenye CMS.
Upangaji wa majina inalingana na kile kilicho katika uga wa Jina la Saraka Inayotumika na sehemu ya jina la CMS ya mtumiaji.
coSpaceNameMapping huunda jina la nafasi ya CMS kulingana na uga wa displayName. Sifa hii, pamoja na sifa ya coSpaceUriMapping, ndiyo inayohitajika ili kuunda nafasi kwa kila mtumiaji.
coSpaceUriMapping inafafanua sehemu ya mtumiaji ya URI inayohusishwa na nafasi ya kibinafsi ya mtumiaji. Baadhi ya vikoa vinaweza kusanidiwa kupigwa kwenye nafasi. Ikiwa sehemu ya mtumiaji inalingana na sehemu hii kwa mojawapo ya vikoa hivi, simu itaelekezwa kwenye nafasi ya mtumiaji huyo.
coSpaceSecondaryUriMapping inafafanua URI ya pili kufikia nafasi. Hii inaweza kutumika kuongeza lakabu ya nambari ya kuelekeza simu kwenye nafasi ya mtumiaji aliyeletwa kama njia mbadala ya URI ya herufi na nambari iliyofafanuliwa katika kigezo cha coSpaceUriMapping.
Seva ya LDAP na ramani ya LDAP imesanidiwa. Sasa unahitaji kuziunganisha pamoja kwa kuunda chanzo cha LDAP.
Kutumia URL kufikia :445/api/v1/ldapChanzo huunda kitu Chanzo cha LDAP, ukibainisha vigezo kama vile:
- server
- ramani
- baseDn
- kuchuja
Sasa kwa kuwa usanidi wa LDAP umekamilika, unaweza kufanya operesheni ya maingiliano ya mwongozo.
Tunafanya hivyo ama katika kiolesura cha Wavuti cha kila seva kwa kubofya Sawazisha sasa sehemu Active Directory
au kupitia API na amri POST kutumia URL kufikia :445/api/v1/ldapSyncs
Mikutano ya Ad-Hoc
Hii ni nini?Katika dhana ya jadi, mkutano ni wakati washiriki wawili wanazungumza wao kwa wao, na mmoja wa washiriki (kwa kutumia kifaa kilichosajiliwa na Unified CM) bonyeza kitufe cha "Mkutano", anamwita mtu mwingine, na baada ya kuzungumza na mtu huyo wa tatu. , bonyeza kitufe cha "Kongamano" tena. ili kujiunga na washiriki wote katika mkutano wa pande tatu.
Kinachotofautisha mkutano wa Ad-Hoc na mkutano ulioratibiwa katika CMS ni kwamba mkutano wa Ad-Hoc sio tu wito wa SIP kwa CMS. Mwanzilishi wa mkutano anapobofya kitufe cha Mkutano mara ya pili ili kualika kila mtu kwenye mkutano huo huo, Umoja wa CM lazima upige simu ya API kwa CMS ili kuunda mkutano wa moja kwa moja ambapo simu zote huhamishiwa. Haya yote hutokea bila kutambuliwa na washiriki.
Hii inamaanisha kuwa CM Iliyounganishwa lazima isanidi kitambulisho cha API na anwani/mlango wa WebAdmin wa huduma pamoja na Shina la SIP moja kwa moja kwenye seva ya CMS ili kuendelea kupiga simu.
Ikihitajika, CUCM inaweza kuunda nafasi katika CMS ili kila simu iweze kufikia CMS na kulingana na kanuni ya simu zinazoingia ambayo imekusudiwa kwa nafasi.
Kuunganishwa na CUCM imeundwa kwa njia sawa na ilivyoelezwa katika makala isipokuwa kwamba kwenye Cisco UCM unahitaji kuunda vigogo vitatu vya CMS, Madaraja matatu ya Mkutano, katika Wasifu wa Usalama wa SIP taja Majina matatu ya Masomo, Vikundi vya Njia, Orodha za Njia, Vikundi vya Rasilimali za Vyombo vya Habari na Orodha za Vikundi vya Rasilimali za Vyombo vya Habari, na kuongeza sheria chache za uelekezaji. kwa Seva ya Mikutano ya Cisco.
Wasifu wa Usalama wa SIP:
Vigogo:
Kila shina inaonekana sawa:
Daraja la Mkutano
Kila Bridge Bridge inaonekana sawa:
Kikundi cha Njia
Orodha ya Njia
Kikundi cha Rasilimali za Vyombo vya Habari
Orodha ya Vikundi vya Rasilimali za Vyombo vya Habari
Wito Kanuni
Tofauti na mifumo ya juu zaidi ya usimamizi wa simu kama vile CM Unified au Expressway, CMS hutafuta tu kikoa katika sehemu ya Ombi la SIP-URI kwa simu mpya. Kwa hivyo ikiwa SIP INVITE ni ya kunywa: [barua pepe inalindwa]CMS inajali domain.com pekee. CMS hufuata sheria hizi ili kubaini mahali pa kuelekeza simu:
1. CMS hujaribu kwanza kulinganisha kikoa cha SIP na vikoa vilivyosanidiwa katika kanuni za simu zinazoingia. Simu hizi zinaweza kisha kuelekezwa kwenye nafasi (βzinazolengwaβ) au watumiaji mahususi, IVR za ndani, au maeneo ambayo Microsoft Lync/Skype for Business (S4B) yaliyounganishwa moja kwa moja.
2. Ikiwa hakuna ulinganifu katika kanuni za simu zinazoingia, CMS itajaribu kulinganisha kikoa kilichosanidiwa katika jedwali la kusambaza simu. Ikiwa mechi itafanywa, sheria inaweza kukataa simu kwa uwazi au kusambaza simu. Kwa wakati huu, CMS inaweza kuandika upya kikoa, ambacho wakati mwingine ni muhimu kwa kupiga simu kwa vikoa vya Lync. Unaweza pia kuchagua kupitisha urushaji, kumaanisha kuwa hakuna sehemu yoyote itakayorekebishwa zaidi, au utumie mpango wa ndani wa kupiga simu wa CMS. Ikiwa hakuna ulinganifu katika sheria za kusambaza simu, chaguo-msingi ni kukataa simu. Kumbuka kwamba katika CMS, ingawa simu "inatumwa", vyombo vya habari bado vimefungwa kwa CMS, ambayo inamaanisha itakuwa katika njia ya kuashiria na trafiki ya vyombo vya habari.
Kisha ni simu zinazotumwa tu ndizo zinazozingatia sheria za simu zinazotoka. Mipangilio hii huamua mahali ambapo simu zinatumwa, aina ya shina (iwe ni simu mpya ya Lync au simu ya kawaida ya SIP), na mabadiliko yoyote ambayo yanaweza kufanywa ikiwa uhamishaji hautachaguliwa katika sheria ya usambazaji wa simu.
Hapa kuna kumbukumbu halisi ya kile kinachotokea wakati wa mkutano wa Ad-Hoc
Picha ya skrini inaonyesha vibaya (sijui jinsi ya kuifanya iwe bora), kwa hivyo nitaandika logi kama hii:
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:12Mkutano wa Ad-Hoc wenyewe:
Sheria za Simu Zinazoingia
Kusanidi vigezo vya simu zinazoingia ni muhimu ili uweze kupokea simu katika CMS. Kama ulivyoona kwenye usanidi wa LDAP, watumiaji wote waliingizwa na kikoa conf.pod6.cms.lab. Kwa hivyo kwa uchache, unataka simu kwa kikoa hiki ili kulenga nafasi. Utahitaji pia kuweka sheria kwa kila kitu ambacho kimekusudiwa kwa jina la kikoa lililohitimu kikamilifu (na labda hata anwani ya IP) ya kila seva ya CMS. Kidhibiti chetu cha simu za nje, Unified CM, kitasanidi vigogo vya SIP vilivyowekwa kwa kila seva za CMS kibinafsi. Kulingana na iwapo misururu hii ya SIP inalenga ni anwani ya IP au FQDN ya seva itabainisha ikiwa CMS inahitaji kusanidiwa ili kukubali simu zinazoelekezwa kwa anwani yake ya IP au FQDN.
Kikoa ambacho kina sheria ya uingizaji wa kipaumbele cha juu zaidi hutumiwa kama kikoa cha nafasi zozote za watumiaji. Watumiaji wanaposawazisha kupitia LDAP, CMS huunda nafasi kiotomatiki, lakini sehemu ya mtumiaji tu ya URI (coSpaceUriMapping), kwa mfano, user.space. Sehemu URI kamili hutolewa kulingana na sheria hii. Kwa kweli, ikiwa ungeingia kwenye Daraja la Wavuti kwa wakati huu, utaona kuwa URI ya Nafasi haina kikoa. Kwa kuweka sheria hii kama kipaumbele cha juu zaidi, unaweka kikoa kwa nafasi zinazozalishwa kuwa conf.mfano.com.
Sheria za Simu Zinazotoka
Ili kuruhusu watumiaji kupiga simu zinazotoka kwa Kundi la Unified CM, lazima usanidi sheria zinazotoka nje. Kikoa cha vituo vilivyosajiliwa na Unified CM, kama vile Jabber, ni example.com. Simu kwa kikoa hiki zinapaswa kuelekezwa kama simu za kawaida za SIP kwa nodi za Uchakataji wa simu za CM. Seva kuu ni cucm-01.example.com, na ya ziada ni cucm-02.example.com.
Sheria ya kwanza inaelezea uelekezaji rahisi zaidi wa simu kati ya seva za nguzo.
Shamba Ndani kutoka kwa kikoa inawajibika kwa kile kitakachoonyeshwa katika SIP-URI ya mpigaji simu kwa mtu anayeitwa baada ya ishara ya "@". Ikiwa tutaiacha tupu, basi baada ya ishara "@" kutakuwa na anwani ya IP ya CUCM ambayo simu hii inapita. Ikiwa tutabainisha kikoa, basi baada ya alama ya "@" kutakuwa na kikoa. Hii ni muhimu ili kuweza kupiga simu tena, vinginevyo haitawezekana kupiga tena kupitia SIP-URI name@ip-anwani.
Piga simu unapobainishwa Ndani kutoka kwa kikoa
Piga simu wakati NOT imeonyeshwa Ndani kutoka kwa kikoa
Hakikisha umebainisha kwa uwazi Zilizosimbwa au Zisizosimbwa kwa simu zinazotoka, kwa sababu hakuna kitu kinachofanya kazi na kigezo Kiotomatiki.
Kurekodi
Mikutano ya video hurekodiwa na seva ya Rekodi. Kinasa sauti ni sawa kabisa na Seva ya Mikutano ya Cisco. Kinasa sauti hakihitaji usakinishaji wa leseni zozote. Leseni za kurekodi zinahitajika kwa seva zinazoendesha huduma za CallBridge, i.e. leseni ya Kurekodi inahitajika na lazima itumike kwa kipengele cha CallBridge, na si kwa seva inayoendesha Kinasa sauti. Kinasa sauti kinafanya kazi kama mteja wa Itifaki ya Kueneza Ujumbe na Uwepo (XMPP), kwa hivyo ni lazima seva ya XMPP iwashwe kwenye seva inayopangisha CallBridge.
Kwa sababu Tuna kundi na leseni inahitaji "kunyooshwa" kwenye seva zote tatu kwenye nguzo. Kisha kwa urahisi katika akaunti yako ya kibinafsi katika leseni tunahusisha (kuongeza) anwani za MAC za violesura vya seva zote za CMS zilizojumuishwa kwenye nguzo.
Na hii ndio picha ambayo inapaswa kuwa kwenye kila seva kwenye nguzo
Kwa ujumla, kuna hali kadhaa za kuweka Kinasa sauti, lakini tutashikamana na hii:
Kabla ya kusanidi Kinasa sauti, unahitaji kuandaa mahali ambapo mikutano ya video itarekodiwa. Kweli hapa , jinsi ya kusanidi Kurekodi zote. Ninazingatia mambo muhimu na maelezo:
1. Ni bora kuteleza cheti kutoka kwa seva ya kwanza kwenye nguzo.
2. Hitilafu ya "Kinasa sauti haipatikani" inaweza kutokea kwa sababu cheti kisicho sahihi kimebainishwa katika Dhamana ya Kinasa sauti.
3. Kuandika kunaweza kusifanye kazi ikiwa saraka ya NFS iliyobainishwa kwa kurekodi sio saraka ya mizizi.
Wakati mwingine kuna haja ya kurekodi moja kwa moja mkutano wa mtumiaji mmoja maalum au nafasi.
Kwa hili, CallProfiles mbili zinaundwa:
Na kurekodi kumezimwa
Na kazi ya kurekodi kiotomatiki
Ifuatayo, "tunaunganisha" CallProfile na kazi ya kurekodi moja kwa moja kwenye nafasi inayotaka.
Katika CMS imethibitishwa kwamba ikiwa CallProfile imefungwa kwa uwazi kwenye nafasi au nafasi yoyote, basi CallProfile hii inafanya kazi tu kuhusiana na nafasi hizi mahususi. Na ikiwa CallProfile haijafungwa kwa nafasi yoyote, basi kwa chaguo-msingi inatumika kwa nafasi hizo ambazo hakuna CallProfile imefungwa kwa uwazi.
Wakati ujao nitajaribu kueleza jinsi CMS inavyofikiwa nje ya mtandao wa ndani wa shirika.
Vyanzo:
Chanzo: mapenzi.com