Cisco Meeting Server 2.5.2. Klasi í skalanlegum og fjaðrandi stillingu með upptökuaðgerð fyrir myndbandsfundi

Í þessu hefti mun ég sýna og útskýra nokkrar ranghala við að setja upp CMS miðlara í failover cluster ham.


ТеорияAlmennt séð eru þrjár gerðir af uppsetningu CMS netþjóns:

• Single Combined(Eins samanlagt), þ.e. þetta er einn netþjónn þar sem öll nauðsynleg þjónusta er í gangi. Í flestum tilfellum hentar þessi tegund af uppsetningu aðeins fyrir innri aðgang viðskiptavinar og í smærri umhverfi þar sem sveigjanleiki og offramboðstakmarkanir eins miðlara eru ekki mikilvægt mál, eða í aðstæðum þar sem CMS sinnir aðeins ákveðnum aðgerðum, svo sem ad hoc ráðstefnur um Cisco UCM.

  Áætlað vinnukerfi:
  

• Einstök skipting(Single Split) framlengir fyrri dreifingargerð með því að bæta við sérstökum netþjóni fyrir ytri aðgang. Í eldri dreifingum þýddi þetta að dreifa CMS netþjóni í demilitarized network segment (DMZ) þar sem ytri viðskiptavinir gátu fengið aðgang að honum, og einn CMS miðlara í netkjarnanum þar sem innri viðskiptavinir gætu fengið aðgang að CMS. Þessu tiltekna dreifingarlíkani er nú vikið út fyrir svokallaða gerð Single Edge, sem samanstendur af netþjónum Cisco hraðbraut, sem annaðhvort hafa eða munu hafa marga af sömu Firewall framhjáháttargetu svo viðskiptavinir þurfa ekki að bæta við sérstökum Edge CMS netþjóni.

  Áætlað vinnukerfi:
  

• Skalanlegt og seigur(Skalanlegt og bilunarþolið) Þessi tegund felur í sér offramboð fyrir hvern íhlut, sem gerir kerfinu kleift að vaxa með þínum þörfum upp í hámarksgetu á sama tíma og það veitir offramboð ef bilun kemur upp. Það notar einnig Single Edge hugmyndina til að veita öruggan ytri aðgang. Þetta er týpan sem við munum skoða í þessum þætti. Ef við skiljum hvernig á að dreifa þessari tegund af klasa, munum við ekki aðeins skilja aðrar tegundir dreifingar, heldur munum við einnig geta skilið hvernig á að búa til klasa af CMS netþjónum til að mæta hugsanlegum vexti í eftirspurn.

Áður en þú ferð yfir í dreifingu þarftu að skilja nokkur grundvallaratriði, þ.e

Helstu CMS hugbúnaðarhlutar:

• Gagnasafn: Gerir þér kleift að sameina nokkrar stillingar, eins og hringiáætlun, notendarými og notendur sjálfa. Styður þyrping fyrir mikið framboð (einn meistari).
• Hringdu í Bridge: þjónusta fyrir hljóð- og myndfundi sem veitir fulla stjórn á stjórnun og úrvinnslu símtala og margmiðlunarferla. Styður þyrping fyrir mikið framboð og sveigjanleika.
• XMPP þjónn: ábyrgur fyrir skráningu og auðkenningu viðskiptavina sem nota Cisco Meeting Application og/eða WebRTC(rauntíma samskipti, eða einfaldlega í vafranum), sem og millihlutamerki. Aðeins hægt að setja í hóp fyrir mikið framboð.
• Vefbrú: Veitir viðskiptavinum aðgang að WebRTC.
• Hleðslujafnari: Býður upp á einn tengipunkt fyrir Cisco Meeting Apps í Single Split ham. Hlustar á ytra viðmót og tengi fyrir komandi tengingar. Jafnframt tekur álagsjafnarinn við komandi TLS tengingum frá XMPP þjóninum, þar sem hann getur skipt um TCP tengingar frá ytri viðskiptavinum.
  Í atburðarás okkar mun það ekki vera þörf.
• TURN þjónn: Veitir Firewall framhjátækni sem leyfir
  setja CMS okkar á bak við eldvegg eða NAT til að tengja utanaðkomandi viðskiptavini með Cisco Meeting App eða SIP tæki. Í atburðarás okkar mun það ekki vera þörf.
• Vefstjóri: Stjórnunarviðmót og API aðgangur, þar á meðal fyrir sérstakar Unified CM ráðstefnur.

Stillingarstillingar

Ólíkt flestum öðrum Cisco vörum styður Cisco Meeting Server þrjár stillingaraðferðir til að mæta hvers kyns uppsetningu.

• Skipanalína (CLI): Skipanalínuviðmót þekkt sem MMP fyrir upphafsstillingar og vottunarverkefni.
• Vefstjóri: Fyrst og fremst fyrir CallBridge tengdar stillingar, sérstaklega þegar settur er upp einn netþjónn sem er ekki í hópi.
• REST API: Notað fyrir flóknustu stillingarverkefni og þyrpingartengd gagnagrunnsverkefni.

Til viðbótar við ofangreint er samskiptareglan notuð SFTP til að flytja skrár—venjulega leyfi, vottorð eða annála—til og frá CMS netþjóninum.

Í dreifingarleiðbeiningum frá Cisco er skrifað á hvítu og ensku að það þurfi að dreifa þyrpingunni að minnsta kosti þrjú netþjóna (hnúta) í samhengi við gagnagrunna. Vegna þess að Aðeins með oddafjölda hnúta mun vélbúnaðurinn til að velja nýjan gagnagrunnsmeistara virka og almennt hefur gagnagrunnsstjórinn tengingu við flestar CMS netþjónagagnagrunninn.

Og eins og æfingin sýnir eru tveir netþjónar (hnútar) í raun ekki alveg nóg. Valbúnaðurinn virkar þegar Master er endurræst, Slave miðlarinn verður Master aðeins eftir að endurræsti miðlarinn er tekinn upp. Hins vegar, ef í þyrping af tveimur netþjónum slokknar skyndilega á Master þjóninum, þá verður Þrælaþjónninn ekki Master, og ef Slaveinn fer út, þá verður Master Server sem eftir er að Slave.

En í tengslum við XMPP, þá væri í raun nauðsynlegt að setja saman þyrping af þremur netþjónum, vegna þess að ef þú t.d. slökktir á XMPP þjónustunni á einum af netþjónunum þar sem XMMP er í leiðtogastöðu, þá mun XMPP haldast á þjóninum sem eftir er í Follower stöðu og CallBridge tengingar við XMPP falla niður, vegna þess að CallBridge tengist eingöngu XMPP með leiðtogastöðu. Og þetta er mikilvægt vegna þess að... ekki eitt einasta símtal fer í gegn.

Einnig í sömu dreifingarleiðbeiningum er sýnt fram á þyrping með einum XMPP netþjóni.

Og með hliðsjón af ofangreindu verður ljóst hvers vegna: það virkar vegna þess að það er í bilunarham.

Í okkar tilviki mun XMPP þjónninn vera til staðar á öllum þremur hnútunum.

Gert er ráð fyrir að allir þrír netþjónarnir okkar séu uppi.

DNS skrár

Áður en þú byrjar að setja upp netþjóna þarftu að búa til DNS færslur А и SRV tegundir:

Vinsamlegast athugaðu að í DNS skránum okkar eru tvö lén example.com og conf.example.com. Example.com er lén sem allir Cisco Unified Communication Manager áskrifendur geta notað fyrir URI sína, sem er líklega til staðar í innviðum þínum eða er líklegt til að vera til staðar. Eða example.com passar við sama lén og notendur nota fyrir netföngin sín. Eða Jabber biðlarinn á fartölvunni þinni gæti verið með URI [netvarið]. Lén conf.example.com er lénið sem verður stillt fyrir notendur Cisco Meeting Server. Lén Cisco Meeting Server verður conf.example.com, þannig að fyrir sama Jabber notanda þyrfti að nota user@ URI til að skrá sig inn á Cisco Meeting Serverconf.example.com.

Grunnstilling

Allar stillingar sem lýst er hér að neðan eru sýndar á einum netþjóni, en þær þarf að gera á hverjum netþjóni í klasanum.

QoS

Þar sem CMS býr til raunverulegur-tími umferð sem er viðkvæm fyrir töfum og pakkatapi, í flestum tilfellum er mælt með því að stilla gæði þjónustunnar (QoS). Til að ná þessu styður CMS merking pakka með Differentiated Services Codes (DSCP) sem það býr til. Þó að forgangsröðun umferðar sem byggir á DSCP fari eftir því hvernig umferðin er unnin af nethlutum innviðakerfisins þíns, munum við í okkar tilfelli stilla CMS okkar með dæmigerðri DSCP forgangsröðun sem byggir á bestu starfsvenjum QoS.

Á hverjum netþjóni munum við slá inn þessar skipanir

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

Þannig var öll vídeóumferð merkt AF41 (DSCP 0x22), öll raddumferð var merkt EF (DSCP 0x2E), aðrar tegundir umferðar með lítilli leynd eins og SIP og XMPP nota AF31 (DSCP 0x1A).

Við athugum:

NTP

Network Time Protocol (NTP) er ekki aðeins mikilvægt til að veita nákvæma tímastimpla símtala og ráðstefnuhalds, heldur einnig til að staðfesta vottorð.

Bættu NTP netþjónum við innviði þína með skipun eins og

ntp server add <server>

Í okkar tilviki eru tveir slíkir netþjónar, þannig að það verða tvö lið.
Við athugum:

Og stilltu tímabeltið fyrir netþjóninn okkar

DNS

Við bætum DNS netþjónum við CMS með skipun eins og:

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

Í okkar tilviki eru tveir slíkir netþjónar, þannig að það verða tvö lið.
Við athugum:

Stilling netviðmóts

Við stillum viðmótið með skipun eins og:

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

Við athugum:

Nafn netþjóns (hýsingarheiti)

Við stillum nafn netþjónsins með skipun eins og:

hostname <name>

Og við endurræsum.


Þetta lýkur grunnstillingunni.

Vottorð

ТеорияCisco Meeting Server krefst dulkóðaðra samskipta milli ýmissa íhluta og þar af leiðandi þarf X.509 vottorð fyrir alla CMS dreifingu. Þeir hjálpa til við að tryggja að þjónustan/þjónninn sé treyst af öðrum netþjónum/þjónustum.

Hver þjónusta krefst vottorðs, en að búa til aðskilin vottorð fyrir hverja þjónustu getur leitt til ruglings og óþarfa flækjustigs. Sem betur fer getum við búið til opinber-einka lyklapar vottorðs og síðan endurnýtt þau í mörgum þjónustum. Í okkar tilviki verður sama vottorð notað fyrir Call Bridge, XMPP Server, Web Bridge og Web Admin. Þannig þarftu að búa til par af opinberum og einkavottorðslyklum fyrir hvern netþjón í klasanum.

Gagnagrunnsþyrping hefur þó nokkrar sérstakar vottorðakröfur og krefst þess vegna eigin vottorða sem eru frábrugðin öðrum þjónustum. CMS notar miðlaravottorð, sem er svipað og vottorð sem aðrir netþjónar nota, en það er líka biðlaravottorð sem er notað fyrir gagnagrunnstengingar. Gagnagrunnsvottorð eru notuð bæði til auðkenningar og dulkóðunar. Í stað þess að gefa upp notandanafn og lykilorð fyrir viðskiptavininn til að tengjast gagnagrunninum, sýnir það viðskiptavottorð sem er treyst af þjóninum. Hver þjónn í gagnagrunnsklasanum mun nota sama opinbera og einkalyklaparið. Þetta gerir öllum netþjónum í klasanum kleift að dulkóða gögn á þann hátt að aðeins er hægt að afkóða þau af öðrum netþjónum sem einnig deila sama lyklaparinu.

Til þess að offramboð virki verða gagnagrunnsklasar að vera að lágmarki 3 netþjónar, en ekki fleiri en 5, með hámarksferð fram og til baka 200 ms milli meðlima klasans. Þessi takmörk eru meira takmarkandi en fyrir kallabrúarþyrping, svo það er oft takmarkandi þátturinn í landfræðilega dreifðri dreifingu.

Gagnagrunnshlutverkið fyrir CMS hefur fjölda einstaka kröfur. Ólíkt öðrum hlutverkum, krefst það viðskiptavinar og netþjónsvottorðs, þar sem biðlaravottorðið hefur tiltekið CN reit sem er kynnt fyrir netþjóninum.

CMS notar postgres gagnagrunn með einum meistara og nokkrum alveg eins eftirmyndum. Það er aðeins einn aðalgagnagrunnur í einu („gagnagrunnsþjónninn“). Þeir sem eftir eru af klasanum eru eftirlíkingar eða „gagnagrunnsbiðlarar“.

Gagnagrunnsþyrping krefst sérstakrar netþjónsvottorðs og viðskiptavinarvottorðs. Þau verða að vera undirrituð með skírteinum, venjulega innri einkavottorðsstofnun. Vegna þess að allir meðlimir gagnagrunnsklasans geta orðið meistarar, verður að afrita gagnagrunnsþjóninn og biðlaravottorðapörin (sem innihalda almenna og einkalyklana) á alla netþjóna svo þeir geti tekið á sig auðkenni biðlarans eða gagnagrunnsþjónsins. Að auki verður að hlaða CA rótarvottorðinu til að tryggja að hægt sé að sannreyna biðlara- og netþjónsvottorð.

Þannig að við búum til beiðni um vottorð sem verður notað af öllum netþjónum nema gagnagrunninum (það verður sérstök beiðni um þetta) með skipun eins og:

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

Í CN skrifum við almennt nafn netþjóna okkar. Til dæmis, ef hýsingarnöfn netþjóna okkar netþjónn01, netþjónn02, netþjónn03, þá verður CN server.example.com

Við gerum það sama á hinum tveimur netþjónunum sem eftir eru með þeim mun að skipanirnar innihalda samsvarandi „hýsingarnöfn“

Við búum til tvær beiðnir um vottorð sem verða notuð af gagnagrunnsþjónustunni með skipunum eins og:

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

pki csr dbclusterclient CN:postgres

þar sem dbclusterserver и dbclusterclient nöfn beiðna okkar og framtíðarvottorðs, hýsingarnafn1(2)(3) nöfn samsvarandi netþjóna.

Við framkvæmum þessa aðferð aðeins á einum netþjóni (!) og við munum hlaða upp skírteinum og samsvarandi .key skrám á aðra netþjóna.

Virkjaðu biðlaravottorðsham í AD CS

Þú þarft líka að sameina vottorðin fyrir hvern netþjón í eina skrá.Á *NIX:

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

Á Windows/DOS:

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

Og hlaðið upp á hvern netþjón:
1. „Einstakur“ netþjónsvottorð.
2. Rótarvottorð (ásamt millistigum, ef einhver er).
3. Vottorð fyrir gagnagrunninn („þjónn“ og „viðskiptavinur“) og skrár með .key endingu, sem voru búnar til við gerð beiðni um „þjónn“ og „viðskiptavinur“ gagnagrunnsskírteini. Þessar skrár verða að vera eins á öllum netþjónum.
4. Skrá yfir öll þrjú „stök“ skírteinin.

Fyrir vikið ættir þú að fá eitthvað eins og þessa skráarmynd á hverjum netþjóni.

Gagnagrunnsklasi

Nú þegar þú hefur öll skírteini hlaðið upp á CMS netþjónana geturðu stillt og virkjað gagnagrunnsþyrping á milli hnútanna þriggja. Fyrsta skrefið er að velja einn netþjón sem aðalhnút gagnagrunnsklasans og stilla hann að fullu.

Aðalgagnagrunnur

Fyrsta skrefið í að setja upp afritun gagnagrunns er að tilgreina skilríkin sem verða notuð fyrir gagnagrunninn. Þetta er gert með því að nota skipun eins og:

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

Nú skulum við segja CMS hvaða viðmót á að nota fyrir gagnagrunnsþyrping með skipuninni:

database cluster localnode a

Síðan frumstillum við klasagagnagrunninn á aðalþjóninum með skipuninni:

database cluster initialize

Hnútar viðskiptavinagagnagrunns

Við gerum sömu aðferð, aðeins í stað skipunarinnar gagnagrunnsþyrping frumstilla sláðu inn skipun eins og:

database cluster join <ip address existing master>

þar sem ip-tala núverandi aðal-ip-tala CMS-þjónsins sem þyrpingin var frumstillt á, einfaldlega Master.

Við athugum hvernig gagnagrunnsþyrpingin okkar virkar á öllum netþjónum með skipuninni:

database cluster status

Við gerum það sama á þriðja þjóninum sem eftir er.

Fyrir vikið kemur í ljós að fyrsti þjónninn okkar er meistarinn, hinir eru þrælar.

Vefstjórnunarþjónusta

Virkjaðu vefstjórnandaþjónustuna:

webadmin listen a 445

Port 445 var valið vegna þess að port 443 er notað fyrir notandaaðgang að vefþjóninum

Við stillum vefstjórnarþjónustuna með vottorðaskrám með skipun eins og:

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

Og virkjaðu Web Admin með skipuninni:

webadmin enable

Ef allt er í lagi munum við fá SUCCESS línur sem gefa til kynna að Web Admin sé rétt stillt fyrir netið og vottorðið. Við athugum virkni þjónustunnar með vafra og sláum inn heimilisfang vefstjórans, til dæmis: cms.example.com: 445

Hringdu í Bridge Cluster

Call Bridge er eina þjónustan sem er til staðar í hverri CMS uppsetningu. Call Bridge er aðal ráðstefnubúnaðurinn. Það býður einnig upp á SIP tengi þannig að hægt er að beina símtölum til eða frá því með til dæmis Cisco Unified CM.

Skipanirnar sem lýst er hér að neðan verða að vera framkvæmdar á hverjum netþjóni með viðeigandi vottorðum.
Svo:

Við tengjum vottorð við Call Bridge þjónustuna við skipun eins og:

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

Við bindum CallBridge þjónustu við viðmótið sem við þurfum með skipuninni:

callbridge listen a

Og endurræstu þjónustuna með skipuninni:

callbridge restart

Nú þegar við höfum stillt kallabrýrnar okkar getum við stillt uppkallsbrúarþyrpinguna. Call Bridge þyrping er frábrugðin gagnagrunni eða XMPP þyrping. Call Bridge Cluster getur stutt frá 2 til 8 hnútum án nokkurra takmarkana. Það veitir ekki aðeins offramboð heldur einnig álagsjafnvægi svo að hægt sé að dreifa ráðstefnum á virkan hátt yfir Call Bridge netþjóna með því að nota skynsamlega símtaladreifingu. CMS hefur viðbótareiginleika, Call Bridge hópa og tengda eiginleika sem hægt er að nota til frekari stjórnun.

Símtalsbrúarþyrping er stillt fyrst og fremst í gegnum vefstjórnendaviðmótið
Aðferðin sem lýst er hér að neðan verður að fara fram á hverjum netþjóni í klasanum.
Svo,

1. Farðu í gegnum vefinn í Configuration > Cluster.
2. Í Hringdu í Bridge auðkenni Sem einstakt nafn skaltu slá inn callbridge[01,02,03] sem samsvarar nafni netþjónsins. Þessi nöfn eru handahófskennd en verða að vera einstök fyrir þennan klasa. Þau eru lýsandi í eðli sínu vegna þess að þau gefa til kynna að þau séu netþjónaauðkenni [01,02,03].
3.B Clustered Call Bridges sláðu inn vefslóðir vefstjóra netþjóna okkar í þyrpingunni, CMS[01,02,03].example.com:445, í reitnum Heimilisfang. Vertu viss um að tilgreina höfnina. Þú getur skilið jafningjatengil SIP lén eftir autt.
4. Bættu vottorði við CallBridge traust hvers netþjóns, skráin sem inniheldur öll vottorð netþjónanna okkar, sem við sameinuðum í þessa skrá strax í upphafi, með skipun eins og:

callbridge trust cluster <trusted cluster certificate bundle>

Og endurræstu þjónustuna með skipuninni:

callbridge restart

Þess vegna ættir þú að fá þessa mynd á hverjum netþjóni:

XMPP þyrping

XMPP þjónustan í CMS er notuð til að sjá um alla skráningu og auðkenningu fyrir Cisco Meeting Apps (CMA), þar á meðal CMA WebRTC vefþjóninn. Símtalsbrúin sjálf virkar einnig sem XMPP viðskiptavinur í auðkenningarskyni og verður því að vera stillt eins og aðrir viðskiptavinir. XMPP bilanaþol er eiginleiki sem hefur verið studdur í framleiðsluumhverfi frá útgáfu 2.1

Skipanirnar sem lýst er hér að neðan verða að vera framkvæmdar á hverjum netþjóni með viðeigandi vottorðum.
Svo:

Við tengjum vottorð við XMPP þjónustuna við skipun eins og:

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

Skilgreindu síðan hlustunarviðmótið með skipuninni:

xmpp listen a

XMPP þjónustan krefst einstakts léns. Þetta er innskráning fyrir notendur. Með öðrum orðum, þegar notandi reynir að skrá sig inn með CMA appinu (eða í gegnum WebRTC biðlarann), slær hann inn userID@logindomin. Í okkar tilfelli mun það vera userid@conf.example.com. Af hverju er það ekki bara example.com? Í tiltekinni uppsetningu okkar völdum við Unified CM lénið okkar sem Jabber notendur munu nota í Unified CM sem example.com, svo við þurftum annað lén fyrir CMS notendur til að beina símtölum til og frá CMS í gegnum SIP lén.

Settu upp XMPP lén með því að nota skipun eins og:

xmpp domain <domain>

Og virkjaðu XMPP þjónustuna með skipuninni:

xmpp enable

Í XMPP þjónustunni verður þú að búa til skilríki fyrir hverja Call Bridge sem verður notuð við skráningu hjá XMPP þjónustunni. Þessi nöfn eru handahófskennd (og tengjast ekki einstöku nöfnum sem þú stilltir fyrir kallabrúarþyrping). Þú verður að bæta við þremur kallabrúum á einum XMPP þjóni og slá svo inn þau skilríki á öðrum XMPP þjónum í þyrpingunni vegna þess að þessi uppsetning passar ekki inn í klasagagnagrunninn. Síðar munum við stilla hverja Call Bridge til að nota þetta nafn og leyndarmál til að skrá sig hjá XMPP þjónustunni.

Nú þurfum við að stilla XMPP þjónustuna á fyrsta netþjóninum með þremur Call Bridges callbridge01, callbridge02 og callbridge03. Hverjum reikningi verður úthlutað handahófi lykilorðum. Þeir verða síðar færðir inn á aðra Call Bridge netþjóna til að skrá sig inn á þennan XMPP netþjón. Sláðu inn eftirfarandi skipanir:

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

Fyrir vikið athugum við hvað gerðist með skipuninni:

xmpp callbridge list

Nákvæmlega sama myndin ætti að birtast á þeim netþjónum sem eftir eru eftir skrefin sem lýst er hér að neðan.

Næst bætum við nákvæmlega sömu stillingum á hinum tveimur netþjónum sem eftir eru, aðeins með skipunum

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

Við bætum Secret mjög varlega inn svo að það séu til dæmis engin aukabil í því.


Þess vegna ætti hver netþjónn að hafa sömu mynd:

Næst, á öllum netþjónum í klasanum, tilgreinum við í trausti skrána sem inniheldur öll þrjú skilríkin, búin til áður með skipun eins og þessari:

xmpp cluster trust <trust bundle>

Við virkum xmpp klasaham á öllum klasaþjónum með skipuninni:

xmpp cluster enable

Á fyrsta netþjóni klasans, byrjum við að búa til xmpp klasa með skipuninni:

xmpp cluster initialize

Á öðrum netþjónum skaltu bæta klasa við xmpp með skipun eins og:

xmpp cluster join <ip address head xmpp server>

Við athugum á hverjum netþjóni árangur þess að búa til XMPP þyrping á hverjum netþjóni með skipunum:

xmpp status
xmpp cluster status

Fyrsti þjónn:

Annar þjónn:

Þriðji þjónn:

Að tengja Call Bridge við XMPP

Nú þegar XMPP þyrpingin er í gangi þarftu að stilla Call Bridge þjónustuna til að tengjast XMPP þyrpingunni. Þessi stilling er gerð í gegnum vefstjórann.

Á hverjum netþjóni, farðu í Stillingar > Almennt og í reitinn Einstakt Call Bridge nafn skrifaðu einstök kallabrúarnöfn sem samsvara þjóninum callbridge[01,02,03]... Á sviði lén conf.example.ru og samsvarandi lykilorð, þú getur njósnað um þau
á hvaða netþjóni sem er í klasanum með skipuninni:

xmpp callbridge list

Skildu "Server" reitinn eftir tóman Callbridge mun framkvæma DNS SRV leit fyrir _xmpp-component._tcp.conf.example.comtil að finna tiltækan XMPP netþjón. IP vistföngin til að tengja kallbrýr við XMPP geta verið mismunandi á hverjum netþjóni, það fer eftir því hvaða gildum er skilað í skráningarbeiðnina _xmpp-component._tcp.conf.example.com callbridge, sem aftur fer eftir forgangsstillingum fyrir tiltekna DNS skrá.

Næst skaltu fara í Staða > Almennt til að staðfesta hvort Call Bride þjónustan hafi tengst XMPP þjónustunni.

Vefbrú

Á hverjum netþjóni í klasanum, virkjaðu Web Bridge þjónustuna með skipuninni:

webbridge listen a:443

Við stillum Web Bridge þjónustuna með vottorðsskrám með skipun eins og:

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

Web Bridge styður HTTPS. Það mun beina HTTP til HTTPS ef það er stillt til að nota "http-redirect".
Til að virkja HTTP tilvísun, notaðu eftirfarandi skipun:

webbridge http-redirect enable

Til að láta Call Bridge vita að Web Bridge geti treyst tengingum frá Call Bridge skaltu nota skipunina:

webbridge trust <certfile>

þar sem þetta er skrá sem inniheldur öll þrjú skilríkin frá hverjum netþjóni í klasanum.

Þessi mynd ætti að vera á öllum netþjónum í þyrpingunni.


Nú þurfum við að búa til notanda með “appadmin” hlutverkið, við þurfum það þannig að við getum stillt klasann okkar(!), en ekki hvern netþjón í klasanum fyrir sig, þannig verður stillingunum beitt jafnt á hvern netþjón þrátt fyrir staðreynd að þær verða gerðar einu sinni.


Fyrir frekari uppsetningu munum við nota Póstþjónn.

Fyrir heimild, veldu Basic í heimildarhlutanum

Til að senda skipanir rétt á CMS netþjóninn þarftu að stilla nauðsynlega kóðun

Við tilgreinum Webbridge með skipuninni POST með færibreytu url og merkingu cms.example.com



Í vefbrúnni sjálfri tilgreinum við nauðsynlegar breytur: gestaaðgangur, varinn aðgangur osfrv.

Hringdu í Bridge Groups

Sjálfgefið er að CMS nýtir ekki alltaf á sem hagkvæmastan hátt þau ráðstefnutilföng sem hún hefur tiltæk.

Til dæmis, fyrir fund með þremur þátttakendum, getur hver þátttakandi endað á þremur mismunandi kallabrúum. Til þess að þessir þrír þátttakendur geti átt samskipti sín á milli mun Call Bridges sjálfkrafa koma á tengingum á milli allra netþjóna og viðskiptavina á sama svæði, þannig að allt lítur út fyrir að allir viðskiptavinir séu á sama netþjóni. Því miður er gallinn við þetta sá að ein þriggja manna ráðstefna mun nú neyta 3 fjölmiðlagátta. Þetta er augljóslega óhagkvæm nýting auðlinda. Að auki, þegar símtalabrú er sannarlega ofhlaðin, er sjálfgefið kerfi að halda áfram að taka við símtölum og veita minni gæðaþjónustu til allra áskrifenda þeirrar hringingarbrúar.

Þessi vandamál eru leyst með því að nota Call Bridge Group eiginleikann. Þessi eiginleiki var kynntur í útgáfu 2.1 af Cisco Meeting Server hugbúnaðinum og hefur verið útvíkkaður til að styðja álagsjafnvægi fyrir bæði inn- og útleið Cisco Meeting App (CMA) símtöl, þar á meðal WebRTC þátttakendur.

Til að leysa endurtengingarvandamálið hafa þrjú stillanleg álagsmörk verið tekin upp fyrir hverja símtalsbrú:

LoadLimit — þetta er hámarks tölulegt álag fyrir tiltekna hringibrú. Hver pallur hefur ráðlagða hleðslumörk, svo sem 96000 fyrir CMS1000 og 1.25 GHz á vCPU fyrir sýndarvélina. Mismunandi símtöl neyta ákveðins magns af fjármagni eftir upplausn og rammahraða þátttakanda.
NewConferenceLoadLimitBasisPoints (sjálfgefið 50% loadLimit) - setur hleðslumörk miðlara, eftir það er nýjum ráðstefnum hafnað.
Núverandi ConferenceLoadLimitBasisPoints (sjálfgefið 80% af loadLimit) - hleðslugildi miðlara eftir það sem þátttakendum sem taka þátt í núverandi ráðstefnu verður hafnað.

Þó að þessi eiginleiki hafi verið hannaður fyrir símtaladreifingu og álagsjöfnun, er einnig hægt að úthluta öðrum hópum eins og TURN Servers, Web Bridge Servers og Recorders til Call Bridge Groups svo að þeir geti einnig verið rétt flokkaðir til að nota sem best. Ef einhverjum af þessum hlutum er ekki úthlutað í símtalahóp er gert ráð fyrir að þeir séu aðgengilegir öllum netþjónum án sérstaks forgangs.

Þessar breytur eru stilltar hér: cms.example.com:445/api/v1/system/configuration/cluster

Næst gefum við til kynna fyrir hverri kallabrú hvaða kallabrúarhópi hún tilheyrir:

Fyrsta kallbrúin

Önnur kallabrú

Þriðja kallbrúin


Þannig stilltum við Call Brdige hópinn til að nýta auðlindir Cisco Meeting Server klasans á skilvirkari hátt.

Flytur inn notendur úr Active Directory

Vefstjórnunarþjónustan er með LDAP stillingarhluta, en hún býður ekki upp á flókna stillingarvalkosti og upplýsingarnar eru ekki geymdar í klasagagnagrunninum, þannig að stillingar verða að fara fram, annað hvort handvirkt á hverjum netþjóni í gegnum vefviðmótið, eða í gegnum API, og svo að við „þrisvar sinnum „Ekki standa upp“ munum við samt stilla gögnin í gegnum API.

Notar vefslóð til að fá aðgang cms01.example.com:445/api/v1/ldapServers búa til LDAP Server hlut, tilgreina færibreytur eins og:

• IP miðlara
• hafnarnúmer
• notandanafn
• lykilorð
• tryggja

Öruggt - veldu satt eða ósatt eftir gáttinni, 389 - ekki öruggt, 636 - varið.


Kortleggja LDAP frumbreytur við eiginleika í Cisco Meeting Server.
LDAP kortlagningin kortleggur eiginleikana í LDAP skránni við eiginleikana í CMS. Raunverulegir eiginleikar:

• jidMapping
• nafnakortlagning
• coSpaceNameMapping
• coSpaceUriMapping
• coSpace SecondaryUriMapping

Lýsing á eiginleikumIADB táknar innskráningarauðkenni notandans í CMS. Þar sem þetta er Microsoft Active Directory LDAP þjónn, er CMS JID kortað á sAMAccountName í LDAP, sem er í raun Active Directory innskráningarauðkenni notandans. Athugaðu líka að þú tekur sAMAccountName og bætir léninu conf.pod6.cms.lab við í lok þess vegna þess að þetta er innskráningin sem notendur þínir munu nota til að skrá sig inn á CMS.

nafnakortlagning samsvarar því sem er að finna í Active Directory displayName reitnum við CMS nafn reitsins.

coSpaceNameMapping býr til CMS svæðisheiti byggt á reitnum displayName. Þessi eiginleiki, ásamt coSpaceUriMapping eigindinni, er það sem þarf til að búa til pláss fyrir hvern notanda.

coSpaceUriMapping skilgreinir notendahluta URI sem tengist persónulegu svæði notandans. Hægt er að stilla sum lén til að hringja í geiminn. Ef notendahlutinn passar við þennan reit fyrir eitt af þessum lénum verður símtalinu beint á rými þess notanda.

coSpace SecondaryUriMapping skilgreinir aðra URI til að ná til rúms. Þetta er hægt að nota til að bæta við tölulegu samnefni til að beina símtölum inn á rými innflutts notanda sem valkostur við alfanumerískt URI sem er skilgreint í coSpaceUriMapping færibreytunni.

LDAP þjónninn og LDAP kortlagningin eru stillt. Nú þarftu að tengja þau saman með því að búa til LDAP heimild.

Notar vefslóð til að fá aðgang cms01.example.com:445/api/v1/ldapSource búa til LDAP Source hlut, tilgreina færibreytur eins og:

• miðlara
• kortlagning
• grunnDn
• sía

Nú þegar LDAP uppsetningu er lokið geturðu framkvæmt handvirka samstillingu.

Við gerum þetta annað hvort í vefviðmóti hvers netþjóns með því að smella Samstilla núna kafla Active Directory


eða í gegnum API með skipuninni POST nota vefslóð til að fá aðgang cms01.example.com:445/api/v1/ldapSyncs

Ad-hoc ráðstefnur

Hvað er þetta?Í hefðbundnu hugtakinu er ráðstefna þegar tveir þátttakendur eru að tala saman og annar þátttakendanna (notar tæki sem skráð er hjá Unified CM) ýtir á "Conference" hnappinn, hringir í hinn aðilann og eftir að hafa talað við þann þriðja aðila , ýtir aftur á "ráðstefnu" hnappinn til að taka þátt í öllum þátttakendum í þríhliða ráðstefnunni.

Það sem aðgreinir Ad-Hoc ráðstefnu frá áætlaðri ráðstefnu í CMS er að Ad-Hoc ráðstefna er ekki bara SIP símtal til CMS. Þegar upphafsmaður ráðstefnunnar smellir í annað sinn á Ráðstefnuhnappinn til að bjóða öllum á sama fund, verður Unified CM að hringja API í CMS til að búa til ráðstefnu á flugi sem öll símtöl eru síðan flutt til. Allt þetta gerist óséður af þátttakendum.

Þetta þýðir að Unified CM verður að stilla API skilríki og WebAdmin heimilisfang/gátt þjónustunnar sem og SIP trunk beint á CMS þjóninn til að halda símtalinu áfram.

Ef nauðsyn krefur getur CUCM búið til pláss í CMS þannig að hvert símtal geti náð til CMS og passa við innhringingarregluna sem er ætluð fyrir rými.

Samþætting við CUCM stillt á sama hátt og lýst er í greininni áðan nema að á Cisco UCM þarftu að búa til þrjá trunk fyrir CMS, þrjár ráðstefnubrýr, í SIP öryggisprófílnum tilgreina þrjú efnisnöfn, leiðarhópa, leiðarlista, miðlaúrræðishópa og fjölmiðlaúrræðishópa og bæta við nokkrum leiðarreglum til Cisco Meeting Server.

SIP öryggissnið:


Koffort:


Hvert skott lítur eins út:




Ráðstefnubrú


Hver ráðstefnubrú lítur eins út:


Leiðarhópur


Leiðalisti


Media Resource Group


Listi yfir fjölmiðlaauðlindir

Kallareglur

Ólíkt fullkomnari símtalastjórnunarkerfum eins og Unified CM eða Expressway, leitar CMS aðeins upp lénið í SIP Request-URI reitnum fyrir ný símtöl. Svo ef SIP INVITE er fyrir sopa: [netvarið]CMS er aðeins sama um domain.com. CMS fylgir þessum reglum til að ákvarða hvert á að beina símtali:

1. CMS reynir fyrst að passa SIP lénið við lénin sem eru stillt í reglum um innhringingu. Þessum símtölum er síðan hægt að beina til („miðað“) rými eða tiltekinna notenda, innri IVR eða beint samþætta Microsoft Lync/Skype for Business (S4B) áfangastaði.
2. Ef það er engin samsvörun í reglum um innhringingu mun CMS reyna að passa við lénið sem er stillt í áframsendingartöflunni. Ef samsvörun er gerð getur reglan beinlínis hafnað símtalinu eða framsent símtalið. Á þessum tíma gæti CMS endurskrifað lénið, sem er stundum gagnlegt til að hringja í Lync lén. Þú getur líka valið að fara framhjá kasti, sem þýðir að engum reitunum verður breytt frekar, eða notað innri CMS-skífuáætlun. Ef það er engin samsvörun í reglum um símtalaflutning er sjálfgefið að hafna símtalinu. Hafðu í huga að í CMS, þó að símtalið sé „framsent“, er miðillinn enn bundinn CMS, sem þýðir að hann verður í merkja- og fjölmiðlaumferðarleiðinni.
Þá falla einungis framsend símtöl undir reglur um úthringingar. Þessar stillingar ákvarða áfangastaði þar sem símtöl eru send, tegund stofnkerfis (hvort sem það er nýtt Lync-símtal eða venjulegt SIP-símtal) og allar breytingar sem hægt er að framkvæma ef flutningur er ekki valinn í framsendingarreglu símtala.

Hér er raunverulegur skrá yfir það sem gerist á ad-hoc ráðstefnu

Skjáskotið sýnir það illa (ég veit ekki hvernig ég á að gera það betra), svo ég mun skrifa logann svona:

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

Sjálf ad-hoc ráðstefnan:


Reglur um innhringingu
Það er nauðsynlegt að stilla færibreytur innhringinga til að geta tekið á móti símtali í CMS. Eins og þú sást í LDAP uppsetningunni voru allir notendur fluttir inn með léninu conf.pod6.cms.lab. Þannig að að minnsta kosti viltu að símtöl í þetta lén miði á rými. Þú þarft líka að setja upp reglur fyrir allt sem er ætlað fyrir fullgilt lén (og jafnvel IP tölu) hvers CMS netþjóna. Ytri símtalstýring okkar, Unified CM, mun stilla SIP trunk tileinkað hverjum CMS netþjóna fyrir sig. Það fer eftir því hvort áfangastaður þessara SIP trunks er IP tölu eða FQDN netþjónsins mun ákvarða hvort CMS þarf að vera stillt til að taka við símtölum sem beint er á IP tölu þess eða FQDN.

Lénið sem hefur hæsta forgangsregluna á heimleið er notað sem lén fyrir hvaða notendarými sem er. Þegar notendur samstilla í gegnum LDAP býr CMS sjálfkrafa til rými, en aðeins notendahluta URI (coSpaceUriMapping), til dæmis user.space. Hluti lén Full URI er mynduð út frá þessari reglu. Reyndar, ef þú myndir skrá þig inn á Web Bridge á þessum tímapunkti, myndirðu sjá að Space URI er ekki með lén. Með því að setja þessa reglu sem hæsta forgang ertu að stilla lénið fyrir mynduðu rýmin samþ.example.com.


Reglur um úthringingar

Til að leyfa notendum að hringja á útleið í Sameinað CM klasann verður þú að stilla reglur á útleið. Lén endapunkta sem skráðir eru hjá Unified CM, eins og Jabber, er example.com. Símtöl á þetta lén ættu að vera beint sem venjuleg SIP-símtöl til Sameinaðs CM símtalavinnsluhnúta. Aðalþjónninn er cucm-01.example.com og viðbótarþjónninn er cucm-02.example.com.

Fyrsta reglan lýsir einföldustu leiðsögn símtala milli klasaþjóna.

Field Staðbundið frá léni ber ábyrgð á því sem birtist í SIP-URI þess sem hringir fyrir þann sem hringt er í á eftir „@“ tákninu. Ef við skiljum það eftir tómt, þá á eftir „@“ tákninu verður IP-tala CUCM sem þetta símtal fer í gegnum. Ef við tilgreinum lén, þá verður í raun lén á eftir „@“ tákninu. Þetta er nauðsynlegt til að hægt sé að hringja til baka, annars er ekki hægt að hringja til baka í gegnum SIP-URI nafn@ip-tölu.

Hringdu þegar tilgreint er Staðbundið frá léni


Hringdu hvenær EKKI gefið til kynna Staðbundið frá léni


Vertu viss um að tilgreina sérstaklega Dulkóðað eða Ódulkóðað fyrir úthringingar, því ekkert virkar með Auto færibreytunni.

Recording

Myndfundir eru teknir upp af upptökuþjóni. Upptökutæki er nákvæmlega það sama og Cisco Meeting Server. Upptökutæki krefst ekki uppsetningar á neinum leyfum. Upptökuleyfi eru nauðsynleg fyrir netþjóna sem keyra CallBridge þjónustu, þ.e. Upptökuleyfi er krafist og það verður að nota á CallBridge íhlutinn, en ekki á þjóninn sem keyrir upptökutæki. Upptökutæki hegðar sér eins og Extensible Messaging and Presence Protocol (XMPP) viðskiptavinur, þannig að XMPP þjónninn verður að vera virkur á þjóninum sem hýsir CallBridge.

Vegna þess að Við erum með þyrping og leyfið þarf að „teygja“ yfir alla þrjá netþjóna þyrpingarinnar. Síðan einfaldlega inn á persónulega reikninginn þinn í leyfunum sem við tengjum (bæta við) MAC vistföngum a-viðmóta allra CMS netþjóna sem eru í klasanum.

Og þetta er myndin sem ætti að vera á hverjum netþjóni í klasanum

Almennt séð eru nokkrar aðstæður til að setja upptökutæki, en við munum halda okkur við þetta:


Áður en upptökutæki er sett upp þarftu að undirbúa stað þar sem myndbandsráðstefnurnar verða í raun teknar upp. Reyndar hér tengill, hvernig á að setja upp alla upptöku. Ég einbeiti mér að mikilvægum atriðum og smáatriðum:

1. Það er betra að renna skírteininu frá fyrsta þjóninum í þyrpingunni.
2. Villan „Undanlegur upptökutæki“ getur komið upp vegna þess að rangt vottorð er tilgreint í upptökutæki.
3. Ritun virkar kannski ekki ef NFS skráin sem tilgreind er fyrir upptöku er ekki rótarskráin.

Stundum er þörf á að taka sjálfkrafa upp ráðstefnu eins tiltekins notanda eða svæðis.

Fyrir þetta eru tveir CallProfiles búnir til:
Með slökkt á upptöku


Og með sjálfvirkri upptökuaðgerð


Næst „hengjum“ við CallProfile með sjálfvirkri upptökuaðgerð á viðkomandi rými.


Í CMS er það svo staðfest að ef CallProfile er beinlínis bundið við hvaða bil eða bil sem er, þá virkar þetta CallProfile aðeins í tengslum við þessi tilteknu rými. Og ef CallProfile er ekki bundið neinu bili, þá er það sjálfgefið notað á þau svæði sem ekkert CallProfile er beinlínis bundið við.

Næst mun ég reyna að lýsa því hvernig aðgangur er að CMS utan innra nets stofnunarinnar.

Heimildir:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later. pdf

Heimild: www.habr.com