У гэтым выпуску я пакажу і растлумачу некаторыя тонкасці налады CMS сервера ў рэжыме адмоваўстойлівага кластара.
ТэорыяНаогул існуе тры тыпу разгортвання CMS сервера:
- Single Combined(Адзіны камбінаваны), г.зн. гэта адзін сервер, на якім запушчаны ўсе неабходныя сервісы. У большасці выпадкаў гэты тып разгортвання прымяняецца толькі для доступу ўнутраных кліентаў і ў невялікіх асяроддзях, дзе абмежаванні маштабаванасці і надмернасці аднаго сервера не з'яўляюцца крытычнай праблемай, або ў сітуацыях, калі CMS выконвае толькі пэўныя функцыі, такія як спецыяльныя канферэнцыі на Cisco UCM.
Прыкладная схема працы:
- Адзіночны Спліт(Адзіны падзелены) пашырае папярэдні тып разгортвання, дадаючы асобны сервер для вонкавага доступу. У састарэлых разгортваннях гэта азначала разгортванне сервера CMS у дэмілітарызаваным сегменце сеткі (DMZ), дзе вонкавыя кліенты маглі б атрымаць да яго доступ, і аднаго сервера CMS у ядры сеткі, дзе атрымліваюць доступ да CMS унутраныя кліенты. Гэтая канкрэтная мадэль разгортвання зараз выцясняецца так званым тыпам Single Edge, Які складаецца з сервераў Cisco Expressway, якія альбо маюць, альбо будуць мець многія з магчымасцяў абыходу Firewall'a, таму кліентам не трэба дадаваць выдзелены памежны сервер CMS.
Прыкладная схема працы:
- Scalable and Resilient(Маштабаваны і адмоваўстойлівы) гэты тып уключае ў сябе надмернасць для кожнага кампанента, што дазваляе сістэме расці з вашымі патрэбамі да максімальнай ёмістасці, забяспечваючы пры гэтым надмернасць у выпадку збою. Ён таксама выкарыстоўвае канцэпцыю Single Edge для забеспячэння бяспечнага вонкавага доступу. Гэта тып, які мы разгледзім у гэтым выпуску. Калі мы будзем разумець, як разгарнуць кластар гэтага тыпу, мы не толькі зразумеем іншыя тыпы разгортвання, але і зможам зразумець, як ствараць кластары CMS сервераў з улікам патэнцыйнага росту запатрабаванняў.
Перш чым пераходзіць да разгортвання трэба разумець некаторыя базавыя рэчы, а менавіта
Асноўныя праграмныя кампаненты CMS:
- База дадзеных: дазваляе аб'ядноўваць некаторыя канфігурацыі, такія як абаненцкая група, прасторы карыстальнікаў і саміх карыстальнікаў. Падтрымлівае кластарызацыю толькі для высокай даступнасці (адзін майстар).
- Call Bridge: сэрвіс для аўдыё- і відэаканферэнцый, які замыкае на сабе поўны кантроль за кіраваннем і апрацоўкай выклікамі і мультымедыя працэсамі. Падтрымлівае кластарызацыю для высокай даступнасці і маштабаванасці.
- XMPP server: адказвае за рэгістрацыю і аўтэнтыфікацыю кліентаў выкарыстоўвалых прыкладанне Cisco Meeting Application і/або WebRTC(real-time communication, ну ці папросту ў браўзэры), а таксама міжкампанентную сігналізацыю. Можа быць кластарызаваны толькі для высокай даступнасці.
- Web Bridge: дае доступ кліентаў у WebRTC.
- Loadbalancer: забяспечвае адзіную кропку падключэння для прыкладанняў Cisco Meeting App у рэжыме Single Split. Праслухоўвае знешні інтэрфейс і порт для ўваходных злучэнняў. У роўнай ступені балансавальнік нагрузкі прымае ўваходныя TLS злучэння з XMPP-сервера, праз якія ён можа перамыкаць TCP-злучэнні ад вонкавых кліентаў.
У нашым сцэнары ён не спатрэбіцца. - TURN server: забяспечвае тэхналогію абыходу Firewall'а, якая дазваляе
вывесіць наш CMS за Firewall'ам ці NAT'ам для падлучэння вонкавых кліентаў выкарыстоўвалых Cisco Meeting App або SIP прылады. У нашым сцэнары ён не спатрэбіцца. - Web Admin: адміністрацыйны інтэрфейс і доступ да API, у тым ліку для спецыяльных канферэнцый Unified CM.
Рэжымы канфігурацыі
У адрозненне ад большасці іншых прадуктаў Cisco, Cisco Meeting Server падтрымлівае тры метады наладкі, якія дазваляюць разгарнуць любы від разгортвання.
- Камандны радок (CLI): Інтэрфейс каманднага радка, вядомы як MMP, для задач пачатковай наладкі і сертыфікатаў.
- Вэб-адміністратар: у першую чаргу для канфігурацыі, звязанай з CallBridge, асабліва пры наладзе аднаго некластэрызаванага сервера.
- REST API: выкарыстоўваецца для самых складаных задач па наладзе і задач, звязаных з кластарнай базай дадзеных.
Акрамя вышэйпаказанага, выкарыстоўваецца пратакол SFTP для перадачы файлаў - звычайна ліцэнзій, сертыфікатаў або часопісаў - на сервер CMS і з яго.
У deployment guide'ах ад Cisco ангельскай па белым напісана, што кластар трэба разгортваць мінімум з трох сервераў(нодаў) у кантэксце баз дадзеных. Т.к. толькі з няцотнай колькасцю вузлоў адпрацуе механізм выбару новага Майстра базы дадзеных, і наогул Майстар базы дадзеных мае сувязь з большай часткай базы дадзеных CMS сервера.
І як практыка паказвае двух сервераў (нодаў) сапраўды не зусім дастаткова. Механізм выбару адпрацоўвае пры перазагрузцы Master'а, Slave сервер становіцца Master'ам вылучна пасля ўзняцця перазагружанага сервера. Аднак, калі ў кластары з двух сервераў Master сервер раптам "згас", то Slave сервер Master'ам не стане, а калі "згас" Slave то і пакінуты Master сервер стане Slave'ом.
А вось у кантэксце XMPP сапраўды трэба было б збіраць кластар з трох сервераў, т.я. калі, напрыклад, адключыць XMPP службу на адным з сервераў у якім XMMP у статуце Leader, то на пакінутым серверы XMPP так і застанецца ў статуце Follower і падлучэнні CallBridge'й да XMPP адваляцца, т.к. CallBridge падключаецца выключна да XMPP са статутам Leader. А гэта крытычна, т.я. ніводны званок не пройдзе.
Таксама ў гэтых жа deployment guide'ах дэманструецца кластар з адным XMPP серверам.
І з улікам вышэй сказанага становіцца зразумела чаму: працуе таму, што ў рэжыме failover.
У нашым выпадку XMPP сервер будзе прысутнічаць на ўсіх трох нодах.
Мяркуецца, што ўсе тры нашыя сэрвэры паднятыя.
DNS запісы
Перш чым прыступаць да налады сервераў неабходна завесці DNS запісы А и СРВ тыпаў:
Звярніце ўвагу, што ў нашых DNS запісах прысутнічае два дамены example.com і конф.example.com. Example.com з'яўляецца даменам, які могуць выкарыстоўваць для сваіх URI усе абаненты Cisco Unified Communication Manager, які хутчэй за ўсё ў вашай інфраструктуры прысутнічае або з высокай доляй верагоднасці прысутнічаць будзе. Або дамен example.com адпавядае таму ж дамену, які карыстачы выкарыстоўваюць для сваіх адрасоў электроннай пошты. Ці ж кліент Jabber на вашым ноўтбуку можа мець URI. [электронная пошта абаронена]. Дамен конф.example.com - гэта той дамен, які будзе настроены для карыстальнікаў Cisco Meeting Server'a. Даменам Cisco Meeting Server'a будзе конф.example.com, таму для таго ж карыстальніка Jabber для ўваходу ў Cisco Meeting Server трэба будзе выкарыстоўваць URI user@конф.example.com.
Базавая канфігурацыя
Усе налады апісваныя ніжэй паказаны на адным серверы, але правесці іх трэба на кожным серверы кластара.
QoS
Паколькі CMS генеруе рэальнага часу трафік, адчувальны да затрымак і страты пакетаў, у большасці выпадкаў рэкамендуецца наладзіць якасць абслугоўвання (QoS). Для гэтага CMS падтрымлівае маркіроўку пакетаў кодамі дыферэнцыраваных паслуг (DSCP), якія ён генеруе. Хоць прыярытэта трафіку на аснове DSCP залежыць ад таго, якім чынам трафік апрацоўваецца сеткавымі кампанентамі вашай інфраструктуры, у нашым выпадку мы наладзім наш CMS з тыповым размеркаваннем прыярытэтаў DSCP на аснове лепшых практык QoS.
На кожным серверы ўвядзем вось гэтыя каманды
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1AТакім чынам, увесь відэа трафік быў пазначаны AF41 (DSCP 0x22), увесь галасавы трафік пазначаны EF (DSCP 0x2E), іншыя віды трафіку з нізкай затрымкай, такія як SIP і XMPP, выкарыстоўваюць AF31 (DSCP 0x1A).
правяраем:
NTP
Сеткавы пратакол часу (NTP) важны не толькі для забеспячэння дакладных часавых адзнак званкоў і канферэнцый, але таксама і для праверкі сертыфікатаў.
Дадаем сервера NTP вашай інфраструктуры камандай выгляду
ntp server add <server>
У нашым выпадку такіх сервераў два, таму і каманд будзе дзве.
правяраем:
І задаём часовую зону для нашага сервера
DNS
DNS серверы ў CMS дадаем камандай выгляду:
dns add forwardzone <domain-name> <server ip>
У нашым выпадку такіх сервераў два, таму і каманд будзе дзве.
правяраем:
Канфігурацыя сеткавага інтэрфейсу
Наладжваем а інтэрфейс камандай выгляду:
ipv4 <interface> add <address>/<prefix length> <gateway>
правяраем:
Імя сервера(Hostname)
Імя сервера задаём камандай выгляду:
hostname <name>
І перазагружаем.
На гэтым базавая канфігурацыя скончана.
Сертыфікаты
ТэорыяCisco Meeting Server патрабуе шыфраванай сувязі паміж рознымі кампанентамі, і ў выніку сертыфікаты X.509 патрабуюцца для ўсіх разгортванняў CMS. Яны дапамагаюць забяспечыць давер да службаў/серверу іншым серверам/службам.
Для кожнай службы патрабуецца сертыфікат, аднак стварэнне асобных сертыфікатаў для кожнай службы можа прывесці да блытаніны і лішняй складанасці. На шчасце, мы можам згенераваць пару адкрытага і зачыненага ключоў сертыфіката, а затым паўторна выкарыстоўваць іх для некалькіх службаў. У нашым выпадку адзін і той жа сертыфікат будзе выкарыстоўвацца для Call Bridge, сэрвэра XMPP, Web Bridge і Web Admin. Такім чынам трэба стварыць па пары адчыненага і зачыненага ключоў сертыфіката на кожны сервер у кластары.
Кластарызацыя базы дадзеных, аднак, мае некаторыя асаблівыя патрабаванні да сертыфікатаў і таму патрабуе сваіх уласных сертыфікатаў, адрозных ад сертыфікатаў астатніх службаў. CMS выкарыстоўвае сертыфікат сервера, які падобны на сертыфікаты, якія выкарыстоўваюцца іншымі серверамі, але ёсць таксама сертыфікат кліента, які выкарыстоўваецца для злучэнняў з базай дадзеных. Сертыфікаты базы дадзеных выкарыстоўваюцца як для аўтэнтыфікацыі, так і для шыфравання. Замест таго, каб прадастаўляць імя карыстальніка і пароль для падлучэння кліента да базы дадзеных, ён прадстаўляе сертыфікат кліента, якому давярае сервер. Кожны сервер у кластары базы дадзеных будзе выкарыстоўваць адну і тую ж пару адчыненага і зачыненага ключоў. Гэта дазваляе ўсім серверам у кластары шыфраваць дадзеныя такім чынам, каб яны маглі быць расшыфраваны толькі іншымі серверамі, якія таксама выкарыстоўваюць тую ж самую пару ключоў.
Каб рэзерваванне працавала, кластары базы дадзеных павінны складацца як мінімум з 3 сервераў, але не больш за 5, з максімальным часам праходжання сігналу ў абодвух напрамках 200 мс паміж любымі членамі кластара. Гэтая мяжа з'яўляецца больш абмежавальным, чым для кластарызацыі Call Bridge, таму ён часта з'яўляецца абмяжоўвалым фактарам у геаграфічна размеркаваных разгортваннях.
Роля базы даных для CMS мае шэраг унікальных патрабаванняў. У адрозненне ад іншых роляў, ён патрабуе сертыфіката кліента і сервера, дзе сертыфікат кліента мае пэўную поле CN, якое ўяўляецца серверу.
CMS выкарыстоўвае базу дадзеных postgres з адным галоўным і некалькімі поўнасцю ідэнтычнымі рэплікамі. У кожны момант часу існуе толькі адна асноўная база дадзеных (сервер базы дадзеных). Астатнія члены кластара з'яўляюцца рэплікамі ці "кліентамі базы дадзеных".
Для кластара базы дадзеных патрабуюцца сертыфікат выдзеленага сервера і сертыфікат кліента. Яны павінны быць падпісаны сертыфікатамі, звычайна унутраным прыватным цэнтрам сертыфікацыі. Паколькі любы з членаў кластара базы дадзеных можа стаць галоўным, пары сертыфікатаў сервера базы дадзеных і кліента (якія змяшчаюць адкрыты і закрыты ключы) павінны быць скапіяваныя на ўсе серверы, каб яны маглі прыняць ідэнтычнасць кліента або сервера базы дадзеных. Акрамя таго, каранёвы сертыфікат CA павінен быць загружаны, каб гарантаваць, што сертыфікаты кліента і сервера могуць быць правераны.
Такім чынам, які фармуецца запыт для сертыфіката, які будзе выкарыстоўвацца ўсімі службамі сервера за выключэннем database(для гэтага будзе асобны запыт) камандай выгляду:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
У CN пішам абагульненую назву нашых сервераў. Напрыклад, калі hostname'ы нашых сервераў server01, server02, server03, то CN будзе server.example.com
Тое самае які робіцца на пакінутых двух серверах з тым адрозненнем, што ў камандах будуць якія адпавядаюць «hostname'ы»
Фарміруем два запыты для сертыфікатаў, якія будуць выкарыстоўвацца службай database камандамі выгляду:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresдзе dbclusterserver и dbclusterclient імёны нашых запытаў і будучых сертыфікатаў, hostname1(2)(3) імёны адпаведных сервераў.
Гэтую працэдуру мы выконваем толькі на адным серверы(!), а сертыфікаты і адпаведныя .key-файлы загрузім на іншыя серверы.
Уключэнне рэжыму кліенцкага сертыфіката ў AD CS
Яшчэ трэба зліць у адзін файл сертыфікаты для кожнага сервераУ *NIX:
cat server01.cer server02.cer server03.cer > server.cerУ Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
І загрузіць на кожны сервер:
1. "Індывідуальны" сертыфікат сервера.
2. Каранёвы сертыфікат (разам з прамежкавымі калі такія ёсць).
3. Сертыфікаты для базы дадзеных («серверны» і «кліенцкі») і файлы з пашырэннем .key, якія сфармаваліся пры стварэнні запыту для «сервернага» і «кліенцкага» сертыфіката базы дадзеных. Гэтыя файлы павінны быць на ўсіх серверах аднымі і тымі ж.
4. Файл усіх трох "індывідуальных" сертыфікатаў.
У выніку павінна атрымацца прыкладна такая файлавая карціна на кожным сэрвэры.
Кластар базы даных
Цяпер, калі ў вас ёсць усе сертыфікаты, загружаныя на серверы CMS, вы можаце наладзіць і ўключыць кластарызацыю базы дадзеных паміж трыма вузламі. Першым крокам з'яўляецца выбар аднаго сервера ў якасці галоўнага вузла кластара базы дадзеных і яго поўная настройка.
Master Database
Першым крокам у наладзе рэплікацыі базы дадзеных з'яўляецца ўказанне сертыфікатаў, якія будуць выкарыстоўвацца для базы дадзеных. Гэта робіцца з дапамогай каманды віду:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Цяпер пакажам CMS, які інтэрфейс выкарыстоўваць для кластарызацыі баз дадзеных камандай:
database cluster localnode aЗатым ініцыялізуем базу дадзеных кластара на галоўным серверы камандай:
database cluster initialize
Client Database Nodes
Прарабляем тую ж самую працэдуру, толькі замест каманды database cluster initialize уводзім каманду выгляду:
database cluster join <ip address existing master>дзе ip address existing master ip адрас CMS сервера на якім была праведзена ініцыялізацыя кластара, папросту Master'a.
Правяраем як працуе наш кластар базы дадзеных на ўсіх серверах камандай:
database cluster status
Тое самае які робіцца і на пакінутым трэцім серверы.
У выніку атрымліваецца, што першы наш сервер з'яўляецца Master'ам, астатнія Slave'амі.
Web Admin Service
Уключаем службу вэб-адміністратара:
webadmin listen a 445445 порт абраны таму, што 443 порт выкарыстоўваецца для доступу карыстальнікаў у web-кліент
Наладжваем Web Admin службу з файламі сертыфікатаў камандай выгляду:
webadmin certs <keyfile> <certificatefile> <ca bundle>І ўключаем Web Admin камандай:
webadmin enable
Калі ўсё добра, то мы атрымаем радкі SUCCESS, у якіх пазначана, што Web Admin правільна наладжаны для сеткі і сертыфіката. Правяраем працаздольнасць службы з дапамогай вэб-браўзэра і ўводны адрас вэб-адміністратара, напрыклад: : 445
Call Bridge Cluster
Call Bridge з'яўляецца адзінай службай, якая прысутнічае ў кожным разгортванні CMS. Call Bridge з'яўляецца асноўным механізмам канферэнц-сувязі. Ён таксама забяспечвае SIP інтэрфейс, так што выклікі могуць маршрутызавацца да яго ці з яго, напрыклад Cisco Unified CM'ам.
Апісаныя ніжэй каманды трэба выканаць на кожным серверы з адпаведнымі сертыфікатамі.
Такім чынам:
Звязваем сертыфікаты са службай Call Bridge камандай віду:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Прывязваем службы CallBridge да патрэбнага нам інтэрфейсу камандай:
callbridge listen aІ перазапускаем службу камандай:
callbridge restart
Цяпер, калі ў нас ёсць настроены Call Bridge'ы, мы можам наладзіць кластарызацыю Call Bridge. Кластарызацыя Call Bridge адрозніваецца ад кластарызацыі базы дадзеных ці XMPP. Call Bridge Cluster можа падтрымліваць ад 2 да 8 вузлоў без якіх-небудзь абмежаванняў. Ён забяспечвае не толькі надмернасць, але і размеркаванне нагрузкі, дзякуючы чаму канферэнцыі могуць актыўна размяркоўвацца паміж серверамі Call Bridge з дапамогай інтэлектуальнага размеркавання выклікаў. CMS мае дадатковыя функцыі, групы Call Bridge і злучаныя з імі функцыі, якія можна выкарыстоўваць для далейшага кіравання.
Кластарызацыя маста выклікаў наладжваецца ў асноўным праз інтэрфейс вэб-адміністратара
Ніжэйапісаную працэдуру трэба правесці на кожным серверы кластара.
Такім чынам,
1. Заходзім праз web у Configuration > Cluster.
2. У Call Bridge identity у якасці ўнікальнага імя ўводзім callbridge[01,02,03] адпаведнае імя сервера. Гэтыя імёны адвольныя, але павінны быць унікальнымі для гэтага кластара. Яны маюць апісальны характар, паколькі паказваюць на тое, што гэта ідэнтыфікатары сервераў [01,02,03, XNUMX, XNUMX].
3.У Clustered Call Bridges уводзім URL-адрасы вэб-адміністратара нашых сервераў у кластары, [01,02,03].example.com:445, у полі Address. Абавязкова пазначце порт. Вы можаце пакінуць Peer link SIP domain пустым.
4. Дадаем у давер CallBridge'у кожнага сервера сертыфікат, файл якога змяшчае ўсе сертыфікаты нашых сервераў, якія мы злілі ў гэты файл у самым пачатку, камандай выгляду:
callbridge trust cluster <trusted cluster certificate bundle>І перазапускаем службу камандай:
callbridge restart
У выніку на кожным серверы павінна атрымацца вось такая карціна:
XMPP Cluster
Служба XMPP у CMS выкарыстоўваецца для апрацоўкі ўсёй рэгістрацыі і аўтэнтыфікацыі для Cisco Meeting Apps (CMA), у тым ліку вэб-кліента CMA WebRTC. Сам Call Bridge таксама дзейнічае, як кліент XMPP для мэт аўтэнтыфікацыі і таму павінен быць наладжаны як іншыя кліенты. Адмаўстойлівасць XMPP – гэта функцыя, якая падтрымліваецца ў вытворчых асяроддзях, пачынаючы з версіі 2.1
Апісаныя ніжэй каманды трэба выканаць на кожным серверы з адпаведнымі сертыфікатамі.
Такім чынам:
Звязваем сертыфікаты са службай XMPP камандай віду:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Затым вызначыце інтэрфейс праслухоўвання камандай:
xmpp listen aДля службы XMPP патрабуецца ўнікальны дамен. Гэта лагін для карыстальнікаў. Іншымі словамі, калі карыстач спрабуе ўвайсці ў сістэму з дапамогай прыкладання CMA (ці праз кліент WebRTC), ён уводзіць userID@logindomain. У нашым выпадку гэта будзе userid@конф.example.com. Чаму гэта не проста example.com? У нашым канкрэтным разгортванні мы абралі наш дамен Unified CM, які карыстачы Jabber будуць выкарыстоўваць у Unified CM, як example.com, таму нам патрэбен іншы дамен для карыстачоў CMS, каб маршрутызаваць выклікі ў CMS і з CMS праз дамены SIP.
Наладзьце дамен XMPP з дапамогай каманды выгляду:
xmpp domain <domain>І ўключаем службу XMPP камандай:
xmpp enableУ службе XMPP неабходна стварыць уліковыя дадзеныя для кожнага Call Bridge, якія будуць выкарыстоўвацца пры рэгістрацыі ў службе XMPP. Гэтыя імёны з'яўляюцца адвольнымі (і не звязаныя з унікальнымі імёнамі, якія вы наладзілі для кластарызацыі моста выклікаў). На адным серверы XMPP неабходна дадаць тры масты выклікаў, а затым увесці гэтыя ўліковыя дадзеныя на іншых серверах XMPP у кластары, паколькі гэтая канфігурацыя не змяшчаецца ў кластарную базу дадзеных. Пазней мы наладзім кожны Call Bridge для выкарыстання гэтага імя і сакрэту для рэгістрацыі ў службе XMPP.
Цяпер нам трэба наладзіць службу XMPP на першым серверы з трыма Call Bridge'амі callbridge01, callbridge02 і callbridge03. Кожнаму ўліковаму запісу будуць прызначаны выпадковыя паролі. Пазней яны будуць уведзены на іншых серверах Call Bridge для ўваходу на гэты XMPP-сервер. Уводзім наступныя каманды:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03У выніку правяраем што атрымалася камандай:
xmpp callbridge list
У дакладнасці такая ж карціна павінны быць на астатніх серверах пасля дзеянняў апісаных ніжэй.
Далей дадаем на пакінутых двух серверах сапраўды такія налады, толькі камандамі
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Secret дадаем вельмі акуратна, каб выпадкова ў яго напрыклад не патрапілі лішнія прабелы.
У выніку на кожным серверы павінна быць такая аднолькавая карціна:
Далей на ўсіх серверах кластара паказваем у давер файл які змяшчае ўсе тры сертыфікаты, створаны раней камандай выгляду:
xmpp cluster trust <trust bundle>Уключаем рэжым xmpp кластара на ўсіх серверах кластара камандай:
xmpp cluster enableНа першым сэрвэры кластара ініцыюем стварэнне xmpp кластара камандай:
xmpp cluster initializeНа астатніх серверах дадаем у xmpp кластар камандай выгляду:
xmpp cluster join <ip address head xmpp server>Правяраем на кожным серверы паспяховасць стварэння XMPP кластара на кожным серверы камандамі:
xmpp status
xmpp cluster statusПершы сервер:
Другі сервер:
Трэці сервер:
Падключэнне Call Bridge да XMPP
Цяпер, калі кластар XMPP запушчаны, неабходна наладзіць службы Call Bridge для падлучэння да кластара XMPP. Гэтая канфігурацыя выконваецца праз вэб-адміністратар.
Заходзім на кожным серверы ў Configuration > General і ў поле Unique Call Bridge name пішам адпаведныя серверу ўнікальныя імёны Call Bridge callbridge[01,02,03]. У полі дамен conf.example.ru і адпаведныя паролі, падглядзець іх можна
на любым серверы кластара камандай:
xmpp callbridge list
Поле "Сервер" пакідаем пустым, Выклічны мост выканае пошук DNS SRV для _xmpp-component._tcp.conf.example.com, Каб знайсці даступны сервер XMPP. IP адрасы падлучэння callbridge'ей да XMPP могуць адрознівацца на кожным серверы, гэта залежыць ад таго якія значэнні вяртаюцца на запыт па запісе _xmpp-component._tcp.conf.example.com callbridge'у, што ў сваю чаргу залежыць ад налад прыярытэтаў для дадзенага DNS запісу.
Далей пераходзім у Status > General, каб пераканацца, ці паспяхова служба Call Bride падлучаная да службы XMPP.
Web Bridge
На кожным серверы кластара ўключаем службу Web Bridge камандай:
webbridge listen a:443Наладжваем Web Bridge службу з файламі сертыфікатаў камандай выгляду:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge падтрымлівае HTTPS. Ён будзе перанакіроўваць HTTP на HTTPS, калі настроены для выкарыстання "http-redirect".
Каб уключыць перанакіраванне HTTP, выкарыстоўвайце наступную каманду:
webbridge http-redirect enableКаб Call Bridge даў зразумець, што Web Bridge'у можна давяраць злучэнням з Call Bridge, выкарыстайце каманду:
webbridge trust <certfile>дзе гэта файл, які змяшчае ўсе тры сертыфікаты ад кожнага сервера ў кластары.
Такая карціна павінна быць на кожным серверы кластара.
Зараз нам трэба стварыць карыстача з роляй «appadmin», ён нам патрэбен для таго каб мы маглі наладжваць наш кластар(!), а не кожны сервер кластара па асобнасці, такім чынам налады будуць ужывацца аднолькава на кожны сервер пры тым, што вырабляцца яны будуць адзін раз.
Для далейшай налады мы будзем выкарыстоўваць .
Для аўтарызацыі выбіраемы Basic у падзеле Autorization
Для карэктнай адпраўкі каманд на серверы CMS трэба выставіць патрэбную кадоўку
Паказваем Webbridge'і камандай POST з параметрам URL-адрасы і значэннем
У самім webbridge'e паказваем патрэбныя параметры: гасцявы доступ, абаронены доступ і іншае.
Call Bridge Groups
Па змаўчанні CMS не заўсёды максімальна эфектыўна выкарыстоўвае даступныя ёй рэсурсы канферэнц-сувязі.
Напрыклад, для сустрэчы з трыма ўдзельнікамі кожны ўдзельнік можа аказацца на трох розных Call Bridge'ax. Для таго каб гэтыя тры ўдзельнікі маглі мець зносіны сябар з сябрам, Call Bridge'ы аўтаматычна ўсталююць злучэнні паміж усімі серверамі і кліентамі ў адным і тым жа Space'e, каб выглядала гэта ўсё так, як быццам усе кліенты на адным серверы. На жаль, недахопам гэтага з'яўляецца тое, што адна канферэнцыя з 3 чалавек зараз будзе спажываць 9 медыя-партоў. Гэта, відавочна, неэфектыўнае выкарыстанне рэсурсаў. Акрамя таго, калі Call Bridge сапраўды перагружаны, механізм па змаўчанні складаецца ў тым, каб працягваць прымаць выклікі і падаваць паслугі з паніжанай якасцю ўсім абанентам гэтага Call Bridge'a.
Гэтыя праблемы вырашаюцца пры дапамозе функцыі Call Bridge Group. Гэтая функцыя была прадстаўлена ў версіі 2.1 праграмнага забеспячэння Cisco Meeting Server і была пашырана для падтрымкі балансавання нагрузкі як для ўваходных, так і для выходных выклікаў, Cisco Meeting App (CMA), у тым ліку ўдзельнікаў WebRTC.
Для вырашэння праблемы перападключэння былі ўведзены тры наладжвальныя абмежаванні нагрузкі для кожнага Call Bridge:
LoadLimit - Гэта максімальная лічбавая нагрузка для канкрэтнага Call Bridge. У кожнай платформы ёсць рэкамендуемае лімітавае значэнне нагрузкі, напрыклад 96000 для CMS1000 і 1.25 GHz на віртуальны працэсар для віртуальнай машыны. Розныя выклікі спажываюць пэўную колькасць рэсурсаў у залежнасці ад дазволу і частаты кадраў удзельніка.
NewConferenceLoadLimitBasisPoints (па змаўчанні 50% loadLimit) - усталёўвае мяжа загрузкі сервера, пасля якога новыя канферэнцыі адхіляюцца.
ExistingConferenceLoadLimitBasisPoints (па змаўчанні 80% ад loadLimit) - значэнне загрузкі сервера, пасля якога ўдзельнікі, якія далучаюцца да існуючай канферэнцыі, будуць адхіленыя.
У той час, як гэтая функцыя была распрацавана для размеркавання выклікаў і размеркавання нагрузкі, іншыя групы, такія, як серверы TURN, серверы Web Bridge і прылады запісу, таксама могуць быць прызначаны для Call Bridge Groups, так што яны таксама могуць быць правільна згрупаваны для аптымальнага выкарыстання. Калі які-небудзь з гэтых аб'ектаў не прызначаны групе выклікаў, мяркуецца, што яны даступныя ўсім серверам без якога-небудзь вызначанага прыярытэту.
Гэтыя параметры наладжваюцца тут: :445/api/v1/system/configuration/cluster
Далей паказваем кожнаму callbridge'у да якой callbridge-групе ён належыць:
Першы callbridge
Другі callbridge
Трэці callbridge
Такім чынам мы наладзілі групу Call Brdige'й для больш эфектыўнага выкарыстання рэсурсаў кластара Cisco Meeting Server'a.
Імпарт карыстальнікаў з Active Directory
Служба Web Admin мае падзел канфігурацыі LDAP, але ён не падае складаныя параметры канфігурацыі, і інфармацыя не захоўваецца ў кластарнай базе дадзеных, таму наладу прыйдзецца выконваць, альбо ўручную на кожным серверы праз Web-інтэрфейс, альбо праз API, і каб нам "тры разы" не ўставаць» дадзеныя мы будзем задаваць усёткі праз API.
Выкарыстоўваючы URL-адрас для доступу :445/api/v1/ldapServers ствараем аб'ект LDAP Server'a, паказваючы такія параметры, як:
- IP-адрас сервера
- нумар порта
- Імя карыстальніка
- пароль
- забяспечваць
Secure - true або false выбіраемы ў залежнасці ад порта, 389 - не абаронены, 636 - абаронены.
Адлюстроўваем LDAP параметры крыніцы на атрыбуты ў Cisco Meeting Server'e.
Адлюстраванне LDAP супастаўляе атрыбуты ў каталогу LDAP з атрыбутамі ў CMS. Уласна атрыбуты:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Апісанне атрыбутаўJID уяўляе ідэнтыфікатар уваходу карыстальніка ў CMS. Паколькі гэта LDAP-сервер Microsoft Active Directory, JID CMS супастаўляецца з sAMAccountName у LDAP, які ў сутнасці з'яўляецца ідэнтыфікатарам уваходу ў Active Directory карыстальніка. Таксама звярніце ўвагу, што вы бераце sAMAccountName і дадаеце дамен conf.pod6.cms.lab да яго канца, таму што гэта лагін, які вашыя карыстальнікі будуць выкарыстоўваць для ўваходу ў CMS.
nameMapping супастаўляе тое, што змяшчаецца ў полі Active Directory displayName, з полем імя CMS карыстальніка.
coSpaceNameMapping стварае імя space'a CMS на аснове поля displayName. Гэты атрыбут разам з атрыбутам coSpaceUriMapping з'яўляюцца тое, што патрабуецца для стварэння space'a для кожнага карыстальніка.
coSpaceUriMapping вызначае карыстацкую частку URI, злучаную з асабістым space'ом карыстача. Некаторыя дамены могуць быць настроены для набору ў space. Калі карыстацкая частка супадае з гэтым полем для аднаго з гэтых даменаў, выклік будзе накіраваны ў space гэтага карыстальніка.
coSpaceSecondaryUriMapping вызначае XNUMX. URI, каб дасягнуць space'a. Гэта можа выкарыстоўвацца для дадання лікавага псеўданіма для маршрутызацыі выклікаў у space імпартаванага карыстача ў якасці альтэрнатывы літарна-лічбаваму URI, вызначанаму ў параметры coSpaceUriMapping.
Сервер LDAP і супастаўленне LDAP настроены. Цяпер трэба звязаць іх разам, стварыўшы крыніцу LDAP.
Выкарыстоўваючы URL-адрас для доступу :445/api/v1/ldapSource ствараем аб'ект LDAP Source, паказваючы такія параметры, як:
- сервер
- адлюстраванне
- baseDn
- фільтраваць
Цяпер, калі налада LDAP завершана, можна выканаць аперацыю ручной сінхранізацыі.
Які робіцца гэта альбо ў Web-інтэрфейсе кожнага сервера націснуўшы Сінхранізаваць зараз у раздзеле Active Directory
альбо праз API камандай POST выкарыстоўваючы URL-адрас для доступу :445/api/v1/ldapSyncs
Ad-Hoc канферэнцыі
Што гэта?У традыцыйным паняцці канферэнцыя гэта, калі два ўдзельнікі размаўляюць адзін з адным, а адзін з удзельнікаў (выкарыстоўваючы прыладу, зарэгістраванае ў Unified CM) націскае кнопку «Канферэнцыя», выклікае іншага чалавека і пасля размовы з гэтым трэцім бокам націскае зноў націсніце кнопку «Канферэнцыя» , каб далучыцца да ўсіх удзельнікаў трохбаковай канферэнцыі.
Ad-Hoc канферэнцыю ад запланаванай канферэнцыі ў CMS адрознівае тое, што Ad-Hoc канферэнцыя - гэта не проста выклік SIP для CMS. Калі ініцыятар канферэнцыі націскае кнопку "Канферэнцыя" ў другі раз, каб запрасіць усіх на адзін і той жа збор, Unified CM павінен выканаць выклік API для CMS, каб стварыць канферэнцыю "на лета", на якую затым перадаюцца ўсе выклікі. Усё гэта адбываецца незаўважна для ўдзельнікаў.
Гэта азначае, што Unified CM павінен наладзіць уліковыя дадзеныя API і адрас / порт WebAdmin службы, а таксама SIP-Trunk непасрэдна на сервер CMS для працягу выкліку.
Пры неабходнасці CUCM можа дынамічна ствараць space ў CMS, каб кожны выклік мог дайсці да CMS і адпавядаць правілу ўваходных выклікаў, якое прызначана для space'аў.
Інтэграцыя з CUCM наладжваецца гэтак жа, як апісана ў артыкуле за выключэннем таго, што на Cisco UCM трэба стварыць тры транка для CMS, тры Conference Bridge'a, у SIP Security Profile пазначыць тры Subject Name'a, Route Group'у, Route List, Media Resourse Group і Media Resourse Group List, а у Cisco Meeting Server'e крыху дадаць правілаў маршрутызацыі.
SIP Security Profile:
Транкі:
Кожны транк выглядае аднолькава:
Канферэнц-мост
Кожны Conference Bridge выглядае аднолькава:
Route Group
Спіс маршрутаў
Media Resourse Group
Media Resourse Group List
Правілы выклікаў
У адрозненне ад больш дасканалых сістэм кіравання выклікамі, такіх як Unified CM ці Expressway, для новых выклікаў CMS праглядае дамен толькі ў поле SIP Request-URI. Так што, калі SIP INVITE прызначаны для sip: [электронная пошта абаронена], CMS клапоціцца толькі аб domain.com. CMS варта гэтым правілам для вызначэння, куды накіраваць званок:
1. Спачатку CMS спрабуе супаставіць дамен SIP з даменамі, настроенымі ў правілах апрацоўкі ўваходных выклікаў. Затым гэтыя выклікі можна накіроўваць у ("мэтавыя") прасторы або канкрэтным карыстальнікам, унутраным IVR або напрамую інтэграваным адрасатам Microsoft Lync/Skype для бізнесу (S4B).
2. Калі ў правілах апрацоўкі ўваходных выклікаў няма супадзенняў, CMS паспрабуе супаставіць дамен, настроены ў табліцы пераадрасацыі выклікаў. Калі супастаўленне ўсталявана, правіла можа відавочна адхіліць выклік ці пераадрасаваць выклік. У гэты час CMS можа перапісаць дамен, што часам карысна для званкоў у дамены Lync. Вы таксама можаце выбраць pass throw, што азначае, што ніводнае з палёў не будзе дадаткова зменена, ці выкарыстоўваць унутраную абаненцкую групу CMS. Калі ў правілах пераадрасацыі выклікаў няма супадзенняў, па змаўчанні выкарыстоўваецца адхіленне выкліку. Майце на ўвазе, што ў CMS, хоць выклік "пераадрасаваны", мультымедыя ўсё яшчэ прывязваецца да CMS, што азначае, што ён будзе знаходзіцца ў шляху сігналізацыі і мультымедыя трафіку.
Тады толькі пераадрасаваныя выклікі падпарадкоўваюцца правілам зыходных выклікаў. Гэтыя параметры вызначаюць адрасатаў, куды адпраўляць выклікі, тып злучальнай лініі (няхай гэта будзе новы выклік Lync або стандартным SIP) і любыя пераўтварэнні, якія могуць быць выкананы, калі ў правіле пераадрасацыі выклікаў не абраная перадача.
Вось уласна лог таго, што адбываецца пры Ad-Hoc канферэнцыі
На скрыншоце відаць дрэнна(не ведаю як зрабіць лепш), таму напішу лог так:
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Сама Ad-Hoc канферэнцыя:
Правілы ўваходных выклікаў
Настройка параметраў уваходных выклікаў неабходна для магчымасці прыёму выкліку ў CMS. Як вы бачылі ў наладзе LDAP, усе карыстачы былі імпартаваныя з даменам conf.pod6.cms.lab. Таму, прынамсі, вы жадаеце, каб выклікі ў гэты дамен прызначаліся для прабелаў. Вам таксама трэба будзе ўсталяваць правілы для ўсяго, што прызначана для поўнага даменнага імя (і, магчыма, нават для IP-адрасы) кожнага з сервераў CMS. У нашым вонкавым кантролі выклікаў, Unified CM, будуць наладжаны магістралі SIP, прызначаныя для кожнага з сервераў CMS індывідуальна. У залежнасці ад таго, ці з'яўляецца прызначэнне гэтых магістраляў SIP IP-адрасам, ці поўнае даменнае імя сервера будзе вызначаць, ці трэба наладзіць CMS для прыёму выклікаў, накіраваных на яго IP-адрас або поўнае даменнае імя.
Дамен, мелы правіла ўваходнага трафіку з найвышэйшым прыярытэтам, выкарыстоўваецца ў якасці дамена для любых карыстацкіх space'ов. Калі карыстачы сінхранізуюцца праз LDAP, CMS аўтаматычна стварае space'ы, але толькі карыстацкую частку URI (coSpaceUriMapping), напрыклад, user.space. Частка поўнага URI ствараецца на аснове гэтага правіла. Фактычна, калі б вы ўвайшлі ў Web Bridge на гэтым этапе, вы б убачылі, што ў Space URI няма дамена. Усталяваўшы гэтае правіла ў якасці найвышэйшага прыярытэту, вы задаяце дамен для згенераваных space'ов як канф.example.com.
Правілы выходных выклікаў
Каб дазволіць карыстачам здзяйсняць выходныя выклікі ў кластар Unified CM, неабходна наладзіць правілы выходных злучэнняў. Даменам канчатковых кропак, зарэгістраваных у Unified CM, такіх як Jabber, з'яўляецца example.com. Выклікі ў гэты дамен варта накіроўваць як стандартныя SIP-выклікі на вузлы апрацоўкі выклікаў Unified CM. У якасці асноўнага выступае cucm-01.example.com сервер, у якасці дадатковага cucm-02.example.com.
Першае ж правіла апісвае найпростую маршрутызацыю званкоў паміж серверамі кластара.
Поле Local from domain адказвае за тое, што будзе адлюстроўвацца ў SIP-URI таго, хто тэлефануе, у таго каму тэлефануюць пасля знака «@». Калі мы яго пакінем пустым, то пасля знака "@" будзе ip-адрас CUCM'a праз які гэты званок праходзіць. Калі ж мы пакажам дамен, то пасля знака "@" уласна і будзе дамен. Гэта трэба для таго, каб была магчымасць ператэлефанаваць назад, інакш датэлефанавацца назад па SIP-URI імя@ip-адрас будзе немагчыма.
Званок калі пазначаны Local from domain
Званок калі НЕ паказаны Local from domain
Абавязкова відавочна пакажыце Encrypted ці Unencrypted будуць выходныя званкі, таму пры параметры Auto нічога не працуе.
запіс
Запіс відэаканферэнцый вядзецца Record-серверам. Recorder уяўляе з сябе сапраўды такі ж Cisco Meeting Server. Recorder не патрабуе ўстаноўкі на сябе ніякіх ліцэнзій. Ліцэнзіі на запіс патрабуюцца серверам на якіх запушчаны службы CallBridge, г.зн. ліцэнзія Recording неабходна і павінна прымяняцца да кампанента CallBridge, а не да сервера дзе запушчаны Recorder. Recorder паводзіць сябе, як кліент які пашыраецца пратаколу абмену паведамленнямі і прысутнасці (XMPP), таму сервер XMPP павінен быць уключаны на серверы, на якім размешчаны CallBridge.
Т.к. у нас кластар і ліцэнзію трэба "расцягнуць" на ўсе тры серверы кластара. То проста ў асабістым кабінеце ў ліцэнзіях асацыюем(дадаем) MAC-адрасы a-інтэрфейсаў усіх CMS сервераў якія ўваходзяць у кластар.
І вось такая карціна павінна быць на кожным серверы кластара.
Наогул сцэнарыяў размяшчэння Recorder'a некалькі, але мы будзем прытрымлівацца такога:
Перад тым, як наладжваць Recorder, патрабуецца падрыхтаваць месца куды ўласна і будуць запісвацца відэаканферэнцыі. Уласна вось , як наладзіць увесь Recording. Я ацэньваю ўвагу на важных момантах і дэталях:
1. Сертыфікат лепш падсунуць ад першага сервера ў кластары.
2. Памылка "Recorder unavailable" можа ўзнікаць таму, што паказаны не той сертыфікат у Recorder Trust.
3. Запіс можа не ісці, калі для запісу паказаны не каранёвы каталог у NFS.
Часам узнікае неабходнасць аўтаматычна запісваць канферэнцыю аднаго канкрэтнага карыстальніка ці space'a.
Для гэтага ствараюцца два CallProfile'a:
З адключанай функцыяй запісу
І з аўтаматычнай функцыяй запісу
Далей да патрэбнага space'у «прыкручваем» CallProfile з аўтаматычнай функцыяй запісу.
У CMS так заведзена, што калі CallProfile відавочна прывязаны да якія-небудзь space'ам ці space'у, то і працуе гэты CallProfile у дачыненні толькі да гэтых пэўных space'аў. А калі CallProfile не прывязаны ні да аднаго space'у, то па змаўчанні ён ужываецца да тых space'ам да якіх відавочна не прывязаны ніводны CallProfile.
У наступны раз паспрабую апісаць, якімі спосабамі здзяйсняецца доступ да CMS за межамі ўнутранай сеткі арганізацыі.
Крыніцы:
Крыніца: habr.com