Дар ин шумора ман баъзе нозукиҳои таъсиси сервери CMS-ро дар реҷаи кластери ивазкунӣ нишон медиҳам ва шарҳ медиҳам.
ТеорияУмуман, се намуди ҷойгиркунии сервери CMS вуҷуд дорад:
- Якҷоя(Ягонаи якҷоя), яъне. ин як серверест, ки дар он тамоми хидматҳои зарурӣ кор мекунанд. Дар аксари мавридҳо, ин навъи ҷойгиркунӣ танҳо барои дастрасии дохилии муштарӣ ва дар муҳитҳои хурдтаре мувофиқ аст, ки дар он маҳдудиятҳои миқёспазирӣ ва зиёдатии як сервер як масъалаи муҳим нестанд ё дар ҳолатҳое, ки CMS танҳо вазифаҳои муайянро иҷро мекунад, ба монанди ad hoc. конфронсҳо оид ба Cisco UCM.
Схемаи тахминии кор:
- Тақсими ягона(Single Split) навъи ҷойгиркунии қаблиро тавассути илова кардани сервери алоҳида барои дастрасии беруна васеъ мекунад. Дар истиқрори кӯҳна, ин маънои ҷойгиркунии сервери CMS дар сегменти шабакаи бемилитаризатсияшуда (DMZ), ки муштариёни беруна метавонанд ба он дастрасӣ пайдо кунанд ва як сервери CMS дар маркази шабака, ки муштариёни дохилӣ метавонанд ба CMS дастрасӣ пайдо кунанд. Ин модели мушаххаси густариш ҳоло бо навъи ба ном иваз карда мешавад Як канори, ки аз серверҳо иборат аст Cisco Expressway.
Схемаи тахминии кор:
- Миқёспазир ва устувор(Миқёспазир ва таҳаммулпазири хато) Ин навъи изофӣ барои ҳар як ҷузъро дар бар мегирад, ки ба система имкон медиҳад, ки бо эҳтиёҷоти шумо то ҳадди тавонмандии худ афзоиш ёбад ва дар сурати нокомӣ изофӣ таъмин кунад. Он инчунин консепсияи Single Edge-ро барои таъмини дастрасии бехатари беруна истифода мебарад. Ин намудест, ки мо дар ин қисмат дида мебароем. Агар мо фаҳмем, ки чӣ гуна ин навъи кластерро ҷойгир кардан мумкин аст, мо на танҳо дигар намудҳои ҷойгиркуниро мефаҳмем, балки инчунин мефаҳмем, ки чӣ тавр сохтани кластерҳои серверҳои CMS барои қонеъ кардани афзоиши эҳтимолии талабот.
Пеш аз гузаштан ба ҷойгиркунӣ, шумо бояд баъзе чизҳои асосиро фаҳмед, яъне
Қисмҳои асосии нармафзори CMS:
- Махзани: Ба шумо имкон медиҳад, ки баъзе конфигуратсияҳоро, аз қабили нақшаи рақамӣ, фазои корбар ва худи корбаронро якҷоя кунед. Дастгирии кластер барои дастрасии баланд (мағозаи ягона) танҳо.
- Bridge занг занед: хидмат барои конфронси аудио ва видео, ки назорати пурраи идоракунӣ ва коркарди зангҳо ва равандҳои мултимедиявиро таъмин мекунад. Кластерро барои дастрасии баланд ва миқёспазирӣ дастгирӣ мекунад.
- сервери XMPP: масъул барои бақайдгирӣ ва аутентификатсияи муштариён бо истифода аз замимаи Cisco Meeting ва/ё WebRTC(муоширати вақти воқеӣ ё танҳо дар браузер), инчунин сигнализацияи байникомпонентхо. Танҳо барои дастрасии баланд гурӯҳбандӣ кардан мумкин аст.
- Web Bridge: Дастрасии муштариро ба WebRTC таъмин мекунад.
- Мувозинатдиҳанда: Нуқтаи ягонаи пайвастшавиро барои Барномаҳои Cisco Meeting дар реҷаи ягона тақсим мекунад. Интерфейси беруна ва портро барои пайвастҳои воридотӣ гӯш мекунад. Ба ҳамин монанд, тавозуни сарборӣ пайвастҳои TLS-и воридшударо аз сервери XMPP қабул мекунад, ки тавассути он метавонад пайвастҳои TCP-ро аз муштариёни беруна иваз кунад.
Дар сенарияи мо он лозим нест. - Сервери TURN: Технологияи гузариши Сипарро таъмин мекунад, ки имкон медиҳад
CMS-и худро дар паси Сипар ё NAT ҷойгир кунед, то муштариёни берунаро бо истифода аз Cisco Meeting App ё дастгоҳҳои SIP пайваст кунед. Дар сенарияи мо он лозим нест. - Администратори веб: Интерфейси маъмурӣ ва дастрасии API, аз ҷумла барои конфронсҳои махсуси Unified CM.
Усулҳои конфигуратсия
Баръакси аксари маҳсулоти дигари Cisco, Cisco Meeting Server се усули конфигуратсияро барои мувофиқ кардани ҳама гуна намуди ҷойгиркунӣ дастгирӣ мекунад.
- Сатри фармон (CLI): Интерфейси сатри фармон бо номи MMP барои конфигуратсия ва вазифаҳои сертификатсия маълум.
- Администратори веб: Асосан барои конфигуратсияҳои марбут ба CallBridge, махсусан ҳангоми насб кардани сервери ягонаи кластерӣ.
- оромии API: Барои вазифаҳои мураккабтарини конфигуратсия ва вазифаҳои марбут ба пойгоҳи додаҳои кластерӣ истифода мешавад.
Илова ба гуфтаҳои боло, протокол истифода мешавад SFTP барои интиқол додани файлҳо - одатан иҷозатномаҳо, сертификатҳо ё гузоришҳо - ба сервери CMS.
Дар дастурҳои густариши Cisco бо забонҳои сафед ва англисӣ навишта шудааст, ки кластер бояд ҷойгир карда шавад камаш се серверҳо (гиреҳҳо) дар заминаи пойгоҳи додаҳо. Зеро Танҳо бо шумораи тоқ гиреҳҳо механизми интихоби устоди нави пойгоҳи додаҳо кор хоҳад кард ва дар маҷмӯъ Устоди пойгоҳи додаҳо бо аксари пойгоҳи сервери CMS робита дорад.
Ва тавре ки таҷриба нишон медиҳад, ду сервер (гиреҳ) воқеан кофӣ нестанд. Механизми интихоб вақте кор мекунад, ки Master бозоғоз мешавад, сервери ғулом танҳо пас аз ба кор андохтани сервери азнавборшуда Мастер мешавад. Аммо, агар дар кластери ду сервер ногаҳон сервери Мастер хомӯш шавад, сервери ғулом Мастер намегардад ва агар ғулом хомӯш шавад, сервери боқимондаи Master ба ғулом табдил меёбад.
Аммо дар заминаи XMPP, дар ҳақиқат ҷамъ кардани кластери се сервер лозим буд, зеро агар, масалан, шумо хидмати XMPP-ро дар яке аз серверҳое, ки дар он XMMP дар мақоми пешво аст, ғайрифаъол кунед, пас дар сервери боқимондаи XMPP дар ҳолати Follower боқӣ мемонад ва пайвастҳои CallBridge ба XMPP қатъ мешаванд, зеро CallBridge танҳо ба XMPP бо мақоми Пешво пайваст мешавад. Ва ин муҳим аст, зеро ... ягон занг хам намеравад.
Инчунин дар ҳамон дастурҳои ҷойгиркунӣ кластер бо як сервери XMPP намоиш дода мешавад.
Ва бо назардошти гуфтаҳои дар боло зикршуда, маълум мешавад, ки чаро: он кор мекунад, зеро он дар ҳолати нокомӣ аст.
Дар ҳолати мо, сервери XMPP дар ҳар се гиреҳ мавҷуд аст.
Тахмин меравад, ки ҳар се сервери мо кор мекунанд.
сабтҳои DNS
Пеш аз оғози насб кардани серверҳо, шумо бояд сабтҳои DNS эҷод кунед А и SRV намудҳо:
Лутфан таваҷҷӯҳ намоед, ки дар сабтҳои DNS-и мо ду домени example.com ва conf.example.com. Example.com доменест, ки ҳамаи муштариёни Cisco Unified Communication Manager метавонанд барои URI-ҳои худ истифода баранд, ки эҳтимолан дар инфрасохтори шумо мавҷуд аст ё эҳтимол вуҷуд дорад. Ё example.com ба ҳамон домене мувофиқат мекунад, ки корбарон барои суроғаҳои почтаи электронии худ истифода мебаранд. Ё мизоҷи Jabber дар ноутбуки шумо метавонад URI дошта бошад [почтаи электронӣ ҳифз карда шудааст]. Домен conf.example.com доменест, ки барои корбарони Cisco Meeting Server танзим карда мешавад. Домени сервери вохӯрии Cisco хоҳад буд conf.example.com, бинобар ин барои ҳамон корбари Jabber, user@ URI бояд барои ворид шудан ба сервери Cisco Meeting истифода шавадconf.example.com.
Конфигуратсияи асосӣ
Ҳама танзимоти дар зер тавсифшуда дар як сервер нишон дода шудаанд, аммо онҳо бояд дар ҳар як сервери кластер иҷро карда шаванд.
QoS
Азбаски CMS тавлид мекунад вақти ҳақиқӣ Трафик ба таъхирҳо ва талафоти бастаҳо ҳассос аст, дар аксари ҳолатҳо тавсия дода мешавад, ки сифати хидматро (QoS) танзим кунед. Барои ноил шудан ба ин, CMS пакетҳои барчаспро бо рамзҳои хидматҳои дифференсиалӣ (DSCPs), ки тавлид мекунад, дастгирӣ мекунад. Гарчанде ки афзалияти трафик дар асоси 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 <name>
Ва мо аз нав оғоз мекунем.
Ин конфигуратсияи асосиро анҷом медиҳад.
Сертификатҳо
ТеорияCisco Meeting Server иртиботи рамзгузориро байни ҷузъҳои гуногун талаб мекунад ва дар натиҷа, сертификатҳои X.509 барои ҳама ҷойгиркунии CMS талаб карда мешаванд. Онҳо кӯмак мекунанд, ки хидматҳо/серверҳо аз ҷониби дигар серверҳо/хизматрасониҳо эътимод дошта бошанд.
Ҳар як хидмат сертификатро талаб мекунад, аммо эҷоди шаҳодатномаҳои алоҳида барои ҳар як хидмат метавонад боиси нофаҳмиҳо ва мураккабии нолозим гардад. Хушбахтона, мо метавонем ҷуфти калидҳои давлатӣ ва хусусии сертификатро тавлид кунем ва сипас онҳоро дар хидматҳои сершумор дубора истифода барем. Дар ҳолати мо, ҳамон сертификат барои Call Bridge, XMPP Server, Web Bridge ва Web Admin истифода мешавад. Ҳамин тариқ, шумо бояд барои ҳар як сервер дар кластер як ҷуфт калидҳои сертификати давлатӣ ва хусусӣ эҷод кунед.
Аммо кластеризатсияи пойгоҳи додаҳо дорои баъзе талаботҳои махсуси сертификатсия мебошад ва аз ин рӯ, сертификатҳои худро талаб мекунад, ки аз дигар хидматҳо фарқ мекунанд. CMS сертификати серверро истифода мебарад, ки ба сертификатҳое, ки аз ҷониби серверҳои дигар истифода мешаванд, шабеҳ аст, аммо инчунин сертификати муштарӣ барои пайвастшавӣ ба пойгоҳи додаҳо мавҷуд аст. Шаҳодатномаҳои пойгоҳи додаҳо ҳам барои аутентификатсия ва ҳам барои рамзгузорӣ истифода мешаванд. Ба ҷои пешниҳоди номи корбар ва парол барои пайвастшавӣ ба муштарӣ, он шаҳодатномаи муштариро пешниҳод мекунад, ки сервер эътимод дорад. Ҳар як сервер дар кластери пойгоҳи додаҳо як ҷуфт калидҳои ҷамъиятӣ ва хусусиро истифода мебарад. Ин ба ҳамаи серверҳои кластер имкон медиҳад, ки маълумотро тавре рамзгузорӣ кунанд, ки он танҳо аз ҷониби серверҳои дигар, ки як ҷуфт калидро мубодила мекунанд, рамзкушоӣ карда шаванд.
Барои кор кардани зиёдатӣ, кластерҳои пойгоҳи додаҳо бояд аз ҳадди ақал 3 сервер иборат бошанд, вале на бештар аз 5, бо вақти максималии гардиш 200 мс байни ҳама аъзои кластер. Ин маҳдудият нисбат ба кластерсозии Call Bridge маҳдудтар аст, аз ин рӯ аксар вақт омили маҳдудкунанда дар густариши аз ҷиҳати ҷуғрофӣ тақсимшуда мебошад.
Нақши пойгоҳи додаҳо барои CMS як қатор талаботи беназир дорад. Баръакси нақшҳои дигар, он сертификати муштарӣ ва серверро талаб мекунад, ки дар он шаҳодатномаи муштарӣ майдони мушаххаси CN дорад, ки ба сервер пешниҳод карда мешавад.
CMS пойгоҳи додаҳои postgres бо як устод ва якчанд репликаҳои комилан якхеларо истифода мебарад. Дар як вақт танҳо як пойгоҳи додаҳо мавҷуд аст («сервери пойгоҳи додаҳо»). Аъзоёни боқимондаи кластер нусхаҳо ё "мизоҷони пойгоҳи додаҳо" мебошанд.
Кластери пойгоҳи додаҳо сертификати сервери махсус ва сертификати муштариро талаб мекунад. Онҳо бояд аз ҷониби сертификатҳо, одатан мақомоти дохилии сертификатсия имзо карда шаванд. Азбаски ҳар як узви кластери пойгоҳи додаҳо метавонад устод гардад, сервери пойгоҳи додаҳо ва ҷуфтҳои сертификати муштарӣ (ки дорои калидҳои умумӣ ва хусусӣ) бояд ба ҳама серверҳо нусхабардорӣ карда шаванд, то онҳо шахсияти муштарӣ ё сервери пойгоҳи додаҳоро қабул кунанд. Илова бар ин, сертификати решаи CA бояд бор карда шавад, то сертификатҳои муштарӣ ва серверро тасдиқ кунанд.
Ҳамин тавр, мо дархостро барои сертификат эҷод мекунем, ки онро ҳама хидматҳои сервер ба истиснои пойгоҳи додаҳо истифода хоҳанд бурд (барои ин дархости алоҳида вуҷуд дорад) бо фармони зерин:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
Дар CN мо номи умумии серверҳои худро менависем. Масалан, агар номҳои мизбони серверҳои мо сервер01, сервер02, сервер03, он гоҳ CN хоҳад буд server.example.com
Мо дар ду сервери боқимонда ҳамин корро мекунем, бо фарқияти он, ки фармонҳо "номҳои мизбон" -и мувофиқро дар бар мегиранд.
Мо ду дархостро барои сертификатҳо тавлид мекунем, ки аз ҷониби хидмати пойгоҳи додаҳо бо фармонҳои зерин истифода мешаванд:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresки dbclusterserver и dbclusterclient номҳои дархостҳои мо ва сертификатҳои оянда, номи мизбон1(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 бор кардаед, шумо метавонед кластерсозии пойгоҳи додаҳоро байни се гиреҳ танзим ва фаъол созед. Қадами аввал ин интихоб кардани як сервер ҳамчун гиреҳи асосии кластери пойгоҳи додаҳо ва пурра танзим кардани он мебошад.
Пойгоҳи додаҳо
Қадами аввал дар танзими нусхабардории пойгоҳи додаҳо ин муайян кардани сертификатҳое мебошад, ки барои пойгоҳи додаҳо истифода мешаванд. Ин бо истифода аз фармон ба монанди:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Акнун биёед ба CMS бигӯем, ки кадом интерфейсро барои кластерсозии пойгоҳи додаҳо бо фармон истифода барад:
database cluster localnode aСипас, мо базаи кластерро дар сервери асосӣ бо фармони зерин оғоз мекунем:
database cluster initialize
Гиреҳҳои пойгоҳи додаҳои муштарӣ
Мо ҳамон тартибро иҷро мекунем, танҳо ба ҷои фармон оғоз кардани кластери пойгоҳи додаҳо фармонеро ворид кунед, ба монанди:
database cluster join <ip address existing master>ки дар он суроғаи IP мавҷудаи IP суроғаи устои сервери CMS, ки кластер дар он оғоз карда шудааст, танҳо Master.
Мо тафтиш мекунем, ки кластери базаи мо дар ҳама серверҳо бо фармони зерин чӣ гуна кор мекунад:
database cluster status
Мо дар сервери сеюми боқимонда ҳамин корро мекунем.
Дар натиҷа маълум мешавад, ки сервери аввалини мо устод аст, боқимондаҳо ғулом мебошанд.
Хадамоти администратори веб
Хидмати администратори вебро фаъол созед:
webadmin listen a 445Порт 445 интихоб шуд, зеро порти 443 барои дастрасии корбар ба муштарии веб истифода мешавад
Мо хидмати Web Admin-ро бо файлҳои сертификатсия бо фармони зерин танзим мекунем:
webadmin certs <keyfile> <certificatefile> <ca bundle>Ва бо фармони Admin Web-ро фаъол созед:
webadmin enable
Агар ҳамааш хуб бошад, мо сатрҳои SUCCESS мегирем, ки нишон медиҳанд, ки администратори веб барои шабака ва сертификат дуруст танзим шудааст. Мо бо истифода аз браузери веб фаъолияти хидматро тафтиш мекунем ва суроғаи администратори вебро ворид мекунем, масалан: : 445
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
Акнун, ки мо пулҳои занги худро танзим кардаем, мо метавонем кластеркунии пули зангро танзим кунем. Кластерсозии Bridge аз пойгоҳи додаҳо ё кластеркунии XMPP фарқ мекунад. Call Bridge Cluster метавонад аз 2 то 8 гиреҳро бидуни маҳдудият дастгирӣ кунад. Он на танҳо зиёдатӣ, балки мувозинати сарбориро низ таъмин мекунад, то конфронсҳо дар серверҳои Call Bridge бо истифода аз тақсимоти интеллектуалии зангҳо фаъолона паҳн карда шаванд. CMS дорои хусусиятҳои иловагӣ, гурӯҳҳои Call Bridge ва хусусиятҳои марбута мебошад, ки метавонанд барои идоракунии минбаъда истифода шаванд.
Кластеркунии пули зангҳо асосан тавассути интерфейси администратори веб танзим карда мешавад
Тартиби дар зер тавсифшуда бояд дар ҳар як сервери кластер иҷро карда шавад.
Ва ҳамин тавр,
1. Ба воситаи веб ба Конфигуратсия > Кластер гузаред.
2. Дар Ба шахсияти Bridge занг занед Ҳамчун номи беназир, callbridge[01,02,03]-ро ворид кунед, ки ба номи сервер мувофиқ аст. Ин номҳо ихтиёрӣ ҳастанд, аммо бояд барои ин кластер беназир бошанд. Онҳо табиати тавсифӣ доранд, зеро онҳо нишон медиҳанд, ки онҳо идентификаторҳои сервер мебошанд [01,02,03].
3.B Пулҳои зангҳои кластерӣ URL-и администратори веби серверҳои моро дар кластер ворид кунед, [01,02,03].example.com:445, дар майдони Суроға. Боварӣ ҳосил кунед, ки портро муайян кунед. Шумо метавонед домени Peer link SIP-ро холӣ гузоред.
4. Ба эътимоди CallBridge-и ҳар як сервер шаҳодатнома илова кунед, ки файли он тамоми сертификатҳои серверҳои моро дар бар мегирад, ки мо онҳоро дар аввал ба ин файл ҳамроҳ кардем, бо фармони зерин:
callbridge trust cluster <trusted cluster certificate bundle>Ва хидматро бо фармон аз нав оғоз кунед:
callbridge restart
Дар натиҷа, дар ҳар як сервер шумо бояд ин тасвирро гиред:
Кластери XMPP
Хидмати XMPP дар CMS барои идора кардани ҳама бақайдгирӣ ва аутентификатсия барои Cisco Meeting Apps (CMA), аз ҷумла муштарии веб CMA WebRTC истифода мешавад. Худи пули занг низ ҳамчун муштарии XMPP барои мақсадҳои аутентификатсия амал мекунад ва аз ин рӯ бояд мисли дигар мизоҷон танзим карда шавад. Таҳаммулпазирии хатогиҳои XMPP хусусиятест, ки дар муҳити истеҳсолӣ аз версияи 2.1 дастгирӣ карда мешавад
Фармонҳои дар зер тавсифшуда бояд дар ҳар як сервер бо сертификатҳои мувофиқ иҷро карда шаванд.
Пас,
Мо сертификатҳоро бо хидмати XMPP бо фармони монанди:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Пас интерфейси гӯширо бо фармон муайян кунед:
xmpp listen aХидмати XMPP домени беназирро талаб мекунад. Ин вуруд барои корбарон аст. Ба ибораи дигар, вақте ки корбар кӯшиш мекунад, ки бо истифода аз барномаи CMA (ё тавассути муштарии WebRTC) ворид шавад, онҳо userID@logindomain-ро ворид мекунанд. Дар ҳолати мо он userid@ хоҳад будconf.example.com. Чаро он танҳо example.com нест? Дар густариши махсуси мо, мо домени Unified CM-и худро интихоб кардем, ки корбарони Jabber дар Unified CM ҳамчун example.com истифода хоҳанд кард, аз ин рӯ ба мо барои корбарони CMS барои масири зангҳо ба ва аз CMS тавассути доменҳои SIP домени дигар лозим буд.
Домени XMPP-ро бо фармони зерин насб кунед:
xmpp domain <domain>Ва хидмати XMPP-ро бо фармон фаъол созед:
xmpp enableДар хидмати XMPP, шумо бояд барои ҳар як пули занг, ки ҳангоми сабти ном дар хидмати XMPP истифода мешаванд, эътимоднома эҷод кунед. Ин номҳо худсаронаанд (ва ба номҳои беназире, ки шумо барои кластеркунии пули занг танзим кардаед, алоқаманд нестанд). Шумо бояд се пули зангро дар як сервери XMPP илова кунед ва он маълумотро дар дигар серверҳои XMPP дар кластер ворид кунед, зеро ин конфигуратсия ба пойгоҳи додаҳои кластер мувофиқат намекунад. Баъдтар мо ҳар як пули зангро барои истифодаи ин ном ва махфӣ барои сабти ном дар хидмати XMPP танзим мекунем.
Ҳоло ба мо лозим аст, ки хидмати XMPP-ро дар сервери аввал бо се 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 callbridge03Мо хеле бодиққат Secret илова мекунем, то масалан, дар он ҷойҳои иловагӣ вуҷуд надошта бошанд.
Дар натиҷа, ҳар як сервер бояд як тасвир дошта бошад:
Баъдан, дар ҳама серверҳои кластер, мо файли дорои ҳар се сертификатро, ки қаблан бо фармони зерин сохта шуда буд, бо эътимод муайян мекунем:
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Сервери аввал:
Сервери дуюм:
Сервери сеюм:
Пайваст кардани пули занг ба XMPP
Ҳоло, ки кластери XMPP кор мекунад, шумо бояд хидматҳои Call Bridge-ро барои пайваст шудан ба кластери XMPP танзим кунед. Ин конфигуратсия тавассути администратори веб анҷом дода мешавад.
Дар ҳар як сервер, ба Конфигуратсия > Умумӣ ва дар майдон гузаред Номи беназири Bridge Call нависед номҳои беназир мувофиқ ба сервер Call Bridge callbridge[01,02,03]... Дар саҳро Domain conf.example.ru ва паролҳои мувофиқ, шумо метавонед дар онҳо ҷосусӣ кунед
дар ягон сервери кластер бо фармони:
xmpp callbridge list
Майдони "Сервер" -ро холӣ гузоред Коллбридж ҷустуҷӯи DNS SRV барои анҷом хоҳад дод _xmpp-component._tcp.conf.example.comбарои ёфтани сервери дастраси XMPP. Суроғаҳои IP барои пайваст кардани зангҳо ба XMPP дар ҳар як сервер метавонанд фарқ кунанд, аз он вобаста аст, ки кадом арзишҳо ба дархости сабт баргардонида мешаванд _xmpp-component._tcp.conf.example.com callbridge, ки дар навбати худ аз танзимоти афзалиятнок барои сабти додаи DNS вобаста аст.
Баъдан, ба Ҳолат> Умумӣ гузаред, то тафтиш кунед, ки оё хидмати 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" эҷод кунем, ба мо лозим аст, ки кластери худро (!) танзим кунем, на ҳар як сервер дар кластер, ин тавр танзимот ба ҳар як сервер сарфи назар аз факт, ки онхо як бор сохта мешаванд.
Барои танзими минбаъда мо истифода хоҳем кард .
Барои иҷозатдиҳӣ, дар қисмати Авторизатсия асосӣ -ро интихоб кунед
Барои дуруст фиристодани фармонҳо ба сервери CMS, шумо бояд рамзгузории лозимиро танзим кунед
Мо бо фармони Webbridge муайян мекунем POST бо параметр URL ва маъно
Дар худи webbridge мо параметрҳои заруриро нишон медиҳем: дастрасии меҳмонон, дастрасии муҳофизатшуда ва ғайра.
Ба гурӯҳҳои Bridge занг занед
Бо нобаёнӣ, CMS на ҳама вақт аз захираҳои конфронси барои он дастрас самараноктар истифода мебарад.
Масалан, барои вохӯрӣ бо се иштирокчӣ, ҳар як иштирокчӣ метавонад дар се пули зангҳои гуногун ба анҷом расад. Барои он ки ин се иштирокчӣ бо ҳамдигар муошират кунанд, Call Bridges ба таври худкор байни ҳама серверҳо ва мизоҷон дар як фазо робита барқарор мекунад, ба тавре ки ҳама ба назар чунин менамояд, ки ҳама муштариён дар як сервер ҳастанд. Мутаассифона, манфии ин аст, ки як конфронси 3-нафарӣ ҳоло 9 порти медиаро истеъмол мекунад. Ин бешубҳа истифодаи бесамари захираҳост. Илова бар ин, вақте ки пули занг воқеан пурбор мешавад, механизми пешфарз ин идома додани қабули зангҳо ва расонидани хидмати пастсифат ба ҳамаи муштариёни ин пули занг мебошад.
Ин мушкилот бо истифода аз хусусияти Call Bridge Group ҳал карда мешаванд. Ин хусусият дар версияи 2.1 нармафзори Cisco Meeting Server муаррифӣ шуд ва барои дастгирии мувозинати сарборӣ барои зангҳои воридотӣ ва содиротии Cisco Meeting App (CMA), аз ҷумла иштирокчиёни WebRTC васеъ карда шудааст.
Барои ҳалли мушкилоти дубора пайвастшавӣ, барои ҳар як пули занг се маҳдудияти танзимшавандаи сарборӣ ҷорӣ карда шудааст:
Маҳдудияти сарборӣ — ин сарбории максималии ададӣ барои як пули махсуси занг аст. Ҳар як платформа дорои маҳдудияти тавсияшудаи сарборӣ мебошад, ба монанди 96000 барои CMS1000 ва 1.25 ГГц барои як vCPU барои мошини виртуалӣ. Зангҳои гуногун вобаста ба қарор ва суръати кадри иштирокчӣ миқдори муайяни захираҳоро истеъмол мекунанд.
NewConferenceLoadLimitBasisPoints (пешфарз 50% loadLimit) - маҳдудияти сарбории серверро муқаррар мекунад, ки пас аз он конфронсҳои нав рад карда мешаванд.
Пойнтҳои мавҷудаи ConferenceLoadLimitBasis (пешфарз 80% аз loadLimit) - арзиши сарбории сервер, ки пас аз он иштирокчиён ба конфронси мавҷуда ҳамроҳ мешаванд, рад карда мешаванд.
Дар ҳоле ки ин хусусият барои тақсими зангҳо ва мувозинати сарборӣ тарҳрезӣ шуда буд, дигар гурӯҳҳо, аз қабили TURN Серверҳо, Серверҳои Web Bridge ва Сабткунакҳо низ метавонанд ба Гурӯҳҳои Call Bridge таъин карда шаванд, то онҳо инчунин барои истифодаи оптималӣ дуруст гурӯҳбандӣ карда шаванд. Агар ягонтои ин объектҳо ба гурӯҳи занг таъин нашуда бошанд, онҳо тахмин мезананд, ки барои ҳама серверҳо бе ягон афзалияти махсус дастрасанд.
Ин параметрҳо дар ин ҷо танзим карда мешаванд: :445/api/v1/система/конфигуратсия/кластер
Баъдан, мо ба ҳар як callbridge нишон медиҳем, ки он ба кадом гурӯҳи callbridge мансуб аст:
Аввалин Callbridge
Callbridge дуюм
Пойгоҳи сеюм
Ҳамин тариқ, мо гурӯҳи Call Brdige-ро барои самараноктар истифода бурдани захираҳои кластери Cisco Meeting Server танзим кардем.
Воридоти корбарон аз Active Directory
Хизматрасонии Web Admin дорои бахши конфигуратсияи LDAP мебошад, аммо он имконоти мураккаби конфигуратсияро таъмин намекунад ва маълумот дар пойгоҳи додаҳои кластер нигоҳ дошта намешавад, бинобар ин конфигуратсия бояд ба таври дастӣ дар ҳар як сервер тавассути интерфейси веб ё тавассути API, ва ба тавре ки мо "се маротиба "Бархезед" мо то ҳол маълумотро тавассути API муқаррар хоҳем кард.
Истифодаи URL барои дастрасӣ :445/api/v1/ldapServers объекти сервери LDAP-ро эҷод карда, параметрҳоро ба монанди:
- IP сервер
- рақами порт
- истифодабаранда
- парол
- таъмин
Амн - вобаста ба порт ҳақиқӣ ё дурӯғро интихоб кунед, 389 - бехатар нест, 636 - ҳифзшуда.
Харитасозии параметрҳои манбаи LDAP ба атрибутҳо дар Cisco Meeting Server.
Харитасозии LDAP атрибутҳоро дар феҳристи LDAP ба атрибутҳо дар CMS харита мекунад. Хусусиятҳои воқеӣ:
- jidMapping
- Харитаи ном
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Тавсифи атрибутҳоҶид ID-и воридшавии корбарро дар CMS муаррифӣ мекунад. Азбаски ин сервери Microsoft Active Directory LDAP аст, CMS JID ба sAMAccountName дар LDAP харита мекунад, ки аслан ID-и воридшавии корбар Active Directory мебошад. Инчунин қайд кунед, ки шумо sAMAccountName-ро мегиред ва домени conf.pod6.cms.lab-ро ба охири он илова мекунед, зеро ин логинест, ки корбарони шумо барои ворид шудан ба CMS истифода хоҳанд кард.
Харитаи ном ба он чизе ки дар майдони Active Directory displayName мавҷуд аст, ба майдони номи CMS корбар мувофиқат мекунад.
coSpaceNameMapping дар асоси майдони displayName номи фазои CMS эҷод мекунад. Ин атрибут дар якҷоягӣ бо атрибути coSpaceUriMapping он чизест, ки барои эҷоди фазои ҳар як корбар зарур аст.
coSpaceUriMapping қисми корбарии URI-ро, ки бо фазои шахсии корбар алоқаманд аст, муайян мекунад. Баъзе доменҳоро метавон танзим кард, ки ба фазо занг зананд. Агар қисми корбар ба ин майдон барои яке аз ин доменҳо мувофиқат кунад, занг ба фазои он корбар равона карда мешавад.
coSpaceSecondaryUriMapping URI дуюмро барои расидан ба фазо муайян мекунад. Ин метавонад барои илова кардани тахаллуси рақамӣ барои масири зангҳо ба фазои корбари воридшуда ҳамчун алтернатива ба URI алфавитӣ-рақамӣ, ки дар параметри coSpaceUriMapping муайян шудааст, истифода шавад.
Сервери LDAP ва харитасозии LDAP танзим карда шудаанд. Акнун шумо бояд онҳоро тавассути эҷоди манбаи LDAP бо ҳам пайваст кунед.
Истифодаи URL барои дастрасӣ :445/api/v1/ldapSource объекти LDAP Source эҷод карда, параметрҳоро ба монанди:
- сервер
- харитасозӣ
- асосДн
- филтр
Акнун, ки конфигуратсияи LDAP ба анҷом расид, шумо метавонед амалиёти ҳамоҳангсозии дастӣ иҷро кунед.
Мо инро ё дар интерфейси веби ҳар як сервер тавассути клик иҷро мекунем Ҳозир ҳамоҳанг кунед фасли Рӯйхати фаъол
ё тавассути API бо фармон POST бо истифода аз URL барои дастрасӣ :445/api/v1/ldapSyncs
Конфронсҳои муваққатӣ
Ин чист?Дар консепсияи анъанавӣ конфронс ин аст, ки ду иштирокчӣ бо ҳамдигар сӯҳбат мекунанд ва яке аз иштирокчиён (бо истифода аз дастгоҳи дар Unified CM сабтшуда) тугмаи "Конференсия" -ро пахш карда, ба шахси дигар занг мезанад ва пас аз гуфтугӯ бо он шахси сеюм , тугмаи «Конференция»-ро бори дигар пахш мекунад, то ба хамаи иштироккунандагони конференцияи сетарафа хамрох шавад.
Он чизе, ки конфронси махсусро аз конфронси ба нақша гирифташуда дар CMS фарқ мекунад, дар он аст, ки конфронси муваққатӣ танҳо занги SIP ба CMS нест. Вақте ки ташаббускори конфронс бори дуюм тугмаи Конфронсро клик мекунад, то ҳамаро ба як вохӯрӣ даъват кунад, Unified CM бояд ба CMS API занг занад, то конфронси зудро эҷод кунад, ки ҳама зангҳо ба он интиқол дода мешаванд. Хамаи ин аз тарафи иштирокчиён бехабар руй медихад.
Ин маънои онро дорад, ки Unified CM бояд маълумотҳои API ва суроға/порти WebAdmin ва инчунин SIP Trunk-ро мустақиман ба сервери CMS барои идомаи занг танзим кунад.
Агар лозим бошад, CUCM метавонад ба таври динамикӣ дар CMS фосила эҷод кунад, то ҳар як занг тавонад ба CMS бирасад ва ба қоидаи занги воридотӣ, ки барои фосила пешбинӣ шудааст, мувофиқат кунад.
Интегратсия бо CUCM ҳамон тавре ки дар мақола тавсиф шудааст, танзим карда шудааст ба истиснои он ки дар Cisco UCM ба шумо лозим аст, ки се тана барои CMS, се пули конфронс эҷод кунед, дар Профили амнияти SIP се Номи мавзӯъҳо, Гурӯҳҳои масир, Рӯйхати масир, Гурӯҳҳои ВАО ва Рӯйхати Гурӯҳи Ресурсҳои ВАО-ро муайян кунед ва чанд қоидаҳои масирро илова кунед ба сервери вохӯрии Cisco.
Профили амнияти SIP:
Танахо:
Ҳар як танаи якхела менамояд:
Пули конфронс
Ҳар як пули конфронс якхела менамояд:
Гурӯҳи роҳ
Рӯйхати масир
Гурӯҳи захираҳои ВАО
Рӯйхати гурӯҳи захираҳои ВАО
Қоидаҳои занг
Баръакси системаҳои пешрафтаи идоракунии зангҳо ба монанди Unified CM ё Expressway, CMS танҳо доменро дар майдони SIP Request-URI барои зангҳои нав меҷӯяд. Пас, агар SIP INVITE барои хӯриш бошад: [почтаи электронӣ ҳифз карда шудааст]CMS танҳо дар бораи domain.com ғамхорӣ мекунад. CMS ин қоидаҳоро риоя мекунад, то дар куҷо масири зангро муайян кунад:
1. CMS аввал кӯшиш мекунад, ки домени SIP-ро бо доменҳое, ки дар қоидаҳои занги воридотӣ танзим шудаанд, мувофиқ созад. Сипас, ин зангҳо метавонанд ба ҷойҳои ("ҳадафнок") ё корбарони мушаххас, IVRҳои дохилӣ ё мустақиман ҳамгирошудаи Microsoft Lync/Skype for Business (S4B) равона карда шаванд.
2. Агар дар қоидаҳои зангҳои воридотӣ мувофиқат надошта бошад, CMS кӯшиш мекунад, ки ба домени дар ҷадвали интиқоли занг танзимшуда мувофиқат кунад. Агар мувофиқат анҷом дода шавад, қоида метавонад зангро ба таври возеҳ рад кунад ё зангро равон кунад. Дар айни замон, CMS метавонад доменро аз нав нависад, ки баъзан барои занг задан ба доменҳои Lync муфид аст. Шумо инчунин метавонед гузаришро интихоб кунед, ки ин маънои онро дорад, ки ҳеҷ яке аз майдонҳо минбаъд тағир дода намешаванд ё нақшаи занги дохилии 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Худи конфронси муваққатӣ:
Қоидаҳои зангҳои даромад
Танзими параметрҳои зангҳои воридотӣ барои қабули занг дар CMS зарур аст. Тавре ки шумо дар танзимоти LDAP дидед, ҳамаи корбарон бо домени conf.pod6.cms.lab ворид карда шуданд. Ҳамин тавр, ҳадди аққал шумо мехоҳед, ки ба ин домен занг занед, то фазоҳоро ҳадаф кунад. Шумо инчунин бояд қоидаҳоро барои ҳама чизе, ки барои номи домени пурраи тахассусӣ (ва шояд ҳатто суроғаи IP) ҳар як сервери CMS пешбинӣ шудааст, муқаррар кунед. Назорати зангҳои берунии мо, Unified CM, транкаҳои SIP-ро ба ҳар як сервери CMS алоҳида танзим мекунад. Вобаста аз он, ки оё макони таъиноти ин trunks SIP суроғаи IP аст ё FQDN-и сервер муайян мекунад, ки оё CMS бояд барои қабули зангҳо ба суроғаи IP ё FQDN-и он танзим карда шавад.
Домене, ки дорои афзалияти баландтарин қоидаҳои воридотӣ мебошад, ҳамчун домен барои ҳама гуна фазои корбар истифода мешавад. Вақте ки корбарон тавассути LDAP ҳамоҳанг мекунанд, CMS ба таври худкор фосилаҳо эҷод мекунад, аммо танҳо қисми корбари URI (coSpaceUriMapping), масалан, user.space. Қисми URI пурра дар асоси ин қоида тавлид мешавад. Дар асл, агар шумо дар ин лаҳза ба Web Bridge ворид шавед, шумо хоҳед дид, ки Space URI домен надорад. Бо гузоштани ин қоида ҳамчун афзалияти баландтарин, шумо доменро барои ҷойҳои тавлидшуда муқаррар мекунед конф.example.com.
Қоидаҳои зангҳои содиротӣ
Барои ба корбарон имкон додани зангҳои содиротӣ ба кластери Unified CM, шумо бояд қоидаҳои содиротро танзим кунед. Домени нуқтаҳои ниҳоӣ, ки дар Unified CM ба қайд гирифта шудаанд, ба монанди Jabber, example.com аст. Зангҳо ба ин домен бояд ҳамчун зангҳои стандартии SIP ба гиреҳҳои коркарди зангҳои Unified CM равона карда шаванд. Сервери асосӣ cucm-01.example.com ва сервери иловагӣ cucm-02.example.com мебошад.
Қоидаи аввал соддатарин масири зангҳоро байни серверҳои кластер тавсиф мекунад.
соҳа Маҳаллӣ аз домен барои он чизе, ки дар SIP-URI зангзананда барои шахсе, ки пас аз аломати "@" занг мезанад, масъул аст. Агар мо онро холӣ гузорем, пас аз рамзи "@" суроғаи IP-и CUCM хоҳад буд, ки тавассути он ин занг мегузарад. Агар мо доменро муайян кунем, пас пас аз рамзи "@" воқеан домен пайдо мешавад. Ин барои бозпас занг задан лозим аст, вагарна тавассути SIP-URI name@ip-адрес занг задан ғайриимкон аст.
Ҳангоми нишондода занг занед Маҳаллӣ аз домен
Кай занг занед ҲАМА нишон дода шудааст Маҳаллӣ аз домен
Боварӣ ҳосил кунед, ки барои зангҳои содиротӣ Рамзшуда ё Рамзнашударо аниқ муайян кунед, зеро бо параметри Авто ҳеҷ чиз кор намекунад.
Сабти ном
Конфронсҳои видеоӣ аз ҷониби сервери Record сабт карда мешаванд. Сабткун маҳз бо Cisco Meeting Server аст. Сабткун насби ягон иҷозатномаро талаб намекунад. Барои серверҳое, ки хидматҳои CallBridge доранд, иҷозатномаҳои сабт талаб карда мешаванд, яъне. иҷозатномаи сабт талаб карда мешавад ва бояд ба ҷузъҳои CallBridge татбиқ карда шавад, на ба сервери сабткунандаи сабт. Сабткун ҳамчун муштарии паёмнависӣ ва ҳузури васеъшаванда (XMPP) амал мекунад, бинобар ин сервери XMPP бояд дар сервери мизбони CallBridge фаъол карда шавад.
Зеро Мо кластер дорем ва литсензия бояд дар ҳар се сервери кластер "дароз" карда шавад. Пас танҳо дар ҳисоби шахсии шумо дар литсензияҳо, мо суроғаҳои MAC-и интерфейсҳои a-и ҳама серверҳои CMS-ро, ки ба кластер дохил карда шудаанд, пайваст мекунем (илова мекунем).
Ва ин расмест, ки бояд дар ҳар сервер дар кластер бошад
Умуман, якчанд сенарияи ҷойгиркунии Сабткун вуҷуд дорад, аммо мо ба ин риоя хоҳем кард:
Пеш аз насб кардани Сабткун, шумо бояд ҷойеро омода кунед, ки дар он видеоконфронсҳо воқеан сабт карда мешаванд. Дар асл дар ин ҷо , чӣ тавр танзим кардани ҳама Сабт. Ман ба нуктаҳо ва тафсилоти муҳим тамаркуз мекунам:
1. Беҳтар аст, ки сертификатро аз сервери аввалини кластер бардоред.
2. Хатои "Сабткунак дастнорас" метавонад рух диҳад, зеро шаҳодатномаи нодуруст дар Trust Recorder Recorder нишон дода шудааст.
3. Навиштан метавонад кор накунад, агар директорияи NFS, ки барои сабт таъин шудааст, директорияи решавӣ набошад.
Баъзан зарурати ба таври худкор сабт кардани конфронси як корбар ё фазои мушаххас вуҷуд дорад.
Барои ин ду CallProfiles сохта мешаванд:
Бо хомӯш кардани сабт
Ва бо функсияи сабти худкор
Баъдан, мо CallProfile-ро бо функсияи сабти худкор ба фазои зарурӣ "васл мекунем".
Дар CMS ончунон муқаррар шудааст, ки агар CallProfile ба ягон фазо ё фазо ба таври возеҳ пайваст бошад, пас ин CallProfile танҳо дар робита бо ин ҷойҳои мушаххас кор мекунад. Ва агар CallProfile ба ягон фосила пайваст набошад, он гоҳ ба таври нобаёнӣ он ба он ҷойҳое татбиқ карда мешавад, ки ҳеҷ CallProfile ба таври возеҳ пайваст нашудааст.
Дафъаи дигар ман кӯшиш мекунам тавсиф кунам, ки чӣ тавр ба CMS берун аз шабакаи дохилии созмон дастрасӣ пайдо мекунад.
Манбаъҳо:
Манбаъ: will.com