Энэ дугаарт би CMS серверийг failover кластер горимд тохируулах зарим нарийн ширийн зүйлийг харуулж, тайлбарлах болно.
ОнолЕрөнхийдөө CMS серверийн байршуулалтын гурван төрөл байдаг:
- Ганц бие хосолсон(Нэг хосолсон), i.e. Энэ бол шаардлагатай бүх үйлчилгээ ажиллаж байгаа нэг сервер юм. Ихэнх тохиолдолд энэ төрлийн байршуулалт нь зөвхөн дотоод үйлчлүүлэгчийн хандалтад тохиромжтой бөгөөд нэг серверийн өргөтгөх чадвар, нөөцийн хязгаарлалт нь чухал асуудал биш юмуу эсвэл CMS нь зөвхөн тодорхой функцийг гүйцэтгэдэг, тухайлбал түр зуурын үйлчилгээ үзүүлдэг жижиг орчинд тохиромжтой. Cisco UCM дээрх бага хурал.
Ажлын ойролцоо схем:
- Ганц хуваагдал(Single Split) нь гадаад хандалтад зориулж тусдаа сервер нэмж өмнөх байршуулалтын төрлийг өргөтгөдөг. Хуучин байршуулалтад энэ нь CMS серверийг гадаад үйлчлүүлэгчид хандах боломжтой цэрэггүй сүлжээний сегмент (DMZ) болон дотоод үйлчлүүлэгчид CMS-д хандах боломжтой сүлжээний цөмд нэг CMS сервер байрлуулах гэсэн үг юм. Энэхүү тусгай байршуулалтын загварыг одоо төрлөөр сольж байна Нэг ирмэгсерверүүдээс бүрддэг Cisco хурдны зам, эдгээр нь ижил Галт ханыг тойрч гарах олон боломжуудтай эсвэл байх тул үйлчлүүлэгчид тусгай захын CMS сервер нэмэх шаардлагагүй болно.
Ажлын ойролцоо схем:
- Өргөтгөх боломжтой, уян хатан(Өргөтгөх боломжтой, алдааг тэсвэрлэх чадвартай) Энэ төрөлд бүрэлдэхүүн хэсэг тус бүрийн нөөцийг багтаасан бөгөөд системийг таны хэрэгцээнд нийцүүлэн хамгийн дээд хүчин чадлаараа өсгөх боломжийг олгодог бөгөөд бүтэлгүйтсэн тохиолдолд нөөцийг бий болгодог. Мөн аюулгүй гадаад хандалтыг хангахын тулд Single Edge концепцийг ашигладаг. Энэ бол бид энэ ангид үзэх болно. Хэрэв бид энэ төрлийн кластерыг хэрхэн байрлуулахыг ойлговол бусад төрлийн байршуулалтыг ойлгохоос гадна эрэлтийн өсөлтийг хангахын тулд CMS серверүүдийн кластеруудыг хэрхэн үүсгэхийг ойлгох боломжтой болно.
Байршил руу шилжихээсээ өмнө та зарим үндсэн зүйлийг ойлгох хэрэгтэй, тухайлбал
CMS програм хангамжийн үндсэн бүрэлдэхүүн хэсгүүд:
- Өгөгдлийн сан: Залгах төлөвлөгөө, хэрэглэгчийн орон зай, хэрэглэгчид өөрсдөө гэх мэт зарим тохиргоог нэгтгэх боломжийг танд олгоно. Зөвхөн өндөр хүртээмжтэй (ганц мастер) кластер хийхийг дэмждэг.
- Bridge руу залга: дуудлага, мультимедиа процессыг удирдах, боловсруулахад бүрэн хяналт тавих аудио болон видео хурлын үйлчилгээ. Өндөр хүртээмжтэй, өргөтгөх боломжтой кластерийг дэмждэг.
- XMPP сервер: Cisco Meeting Application болон/эсвэл WebRTC ашиглан үйлчлүүлэгчдийг бүртгэх, баталгаажуулах үүрэгтэй.бодит цагийн харилцаа холбоо, эсвэл зүгээр л хөтөч дээр), түүнчлэн бүрэлдэхүүн хэсгүүдийн дохиолол. Зөвхөн өндөр хүртээмжтэй байхын тулд кластерт оруулах боломжтой.
- Вэб гүүр: Үйлчлүүлэгчийн WebRTC-д хандах боломжийг олгоно.
- Ачаалал тэнцвэржүүлэгч: Single Split горимд Cisco Meeting Apps-д зориулсан нэг холболтын цэгээр хангана. Ирж буй холболтын гадаад интерфейс болон портыг сонсдог. Үүнтэй адилаар ачаалал тэнцвэржүүлэгч нь XMPP серверээс ирж буй TLS холболтуудыг хүлээн авдаг бөгөөд үүгээрээ дамжуулан TCP холболтыг гадаад үйлчлүүлэгчээс сольж болно.
Бидний хувилбарт энэ нь шаардлагагүй болно. - Серверийг TURN: Галт ханыг тойрч гарах технологиор хангадаг
Cisco Meeting App эсвэл SIP төхөөрөмжүүдийг ашиглан гадны үйлчлүүлэгчдийг холбохын тулд CMS-ийг Галт хана эсвэл NAT-ийн ард байрлуул. Бидний хувилбарт энэ нь шаардлагагүй болно. - Вэб админ: Удирдлагын интерфэйс ба API хандалт, үүнд нэгдсэн CM-ийн тусгай бага хурал зэрэг орно.
Тохиргооны горимууд
Cisco-ийн бусад ихэнх бүтээгдэхүүнээс ялгаатай нь Cisco Meeting Server нь ямар ч төрлийн суулгацыг тохируулах гурван тохиргооны аргыг дэмждэг.
- Тушаалын мөр (CLI): Анхны тохиргоо болон сертификатын ажлуудад зориулагдсан MMP гэгддэг командын мөрийн интерфейс.
- Вэб администратор: Голчлон CallBridge-тэй холбоотой тохиргоонд, ялангуяа нэг кластергүй серверийг тохируулахад зориулагдсан.
- REST API: Хамгийн төвөгтэй тохиргооны ажил болон өгөгдлийн сантай холбоотой кластерийн даалгаварт ашигладаг.
Дээрхээс гадна протоколыг ашигладаг SFTP ихэвчлэн лиценз, гэрчилгээ, бүртгэл зэрэг файлуудыг CMS сервер рүү шилжүүлэх.
Cisco-ийн байршуулах гарын авлагад кластерыг байрлуулах шаардлагатай гэж цагаан болон англи хэлээр бичсэн байдаг. дор хаяж гурав өгөгдлийн сангийн контекст дэх серверүүд (зангилаа). Учир нь Зөвхөн сондгой тооны зангилаатай бол шинэ мэдээллийн сангийн мастер сонгох механизм ажиллах бөгөөд ерөнхийдөө Өгөгдлийн сангийн мастер нь CMS серверийн өгөгдлийн сангийн ихэнхтэй холбогддог.
Практикаас харахад хоёр сервер (зангилаа) нь үнэхээр хангалтгүй юм. Сонгох механизм нь Мастер дахин ачаалагдах үед ажилладаг бөгөөд дахин ачаалагдсан сервер гарч ирсний дараа л Slave сервер Мастер болдог. Гэсэн хэдий ч, хэрэв хоёр серверийн кластерт мастер сервер гэнэт унтарвал Slave сервер Мастер болохгүй, хэрэв Slave унтарвал үлдсэн Мастер сервер нь Slave болно.
Гэхдээ XMPP-ийн хувьд гурван серверээс бүрдсэн кластер цуглуулах шаардлагатай болно, учир нь жишээ нь, хэрэв та XMMP нь Ахлагчийн статустай байгаа серверүүдийн аль нэг дээр XMPP үйлчилгээг идэвхгүй болговол, үлдсэн сервер дээр XMPP нь Дагагчийн төлөвт үлдэх бөгөөд CallBridge-ийн XMPP холболт тасрах болно. CallBridge нь зөвхөн Удирдагч статустай XMPP-д холбогддог. Энэ нь маш чухал, учир нь ... нэг ч дуудлага ирэхгүй.
Мөн ижил байршуулалтын гарын авлагад нэг XMPP сервер бүхий кластерыг харуулсан болно.
Дээр дурдсан зүйлсийг харгалзан үзвэл яагаад энэ нь тодорхой болсон: энэ нь дампуурлын горимд байгаа тул ажилладаг.
Манай тохиолдолд XMPP сервер нь бүх гурван зангилаа дээр байх болно.
Манай гурван сервер бүгд ажиллаж байгаа гэж таамаглаж байна.
DNS бичлэгүүд
Та серверүүдийг тохируулж эхлэхээсээ өмнө DNS бичлэгүүдийг үүсгэх хэрэгтэй А и SRV төрөл:
Манай DNS бүртгэлд example.com болон хоёр домайн байгааг анхаарна уу conf.example.com. Example.com нь Cisco нэгдсэн холбооны менежерийн бүх захиалагчдын URI-д ашиглах боломжтой домэйн бөгөөд энэ нь таны дэд бүтцэд байгаа эсвэл байх магадлалтай. Эсвэл example.com нь хэрэглэгчдийн имэйл хаягт ашигладаг ижил домайнтай таарч байна. Эсвэл таны зөөврийн компьютер дээрх Jabber клиент URI-тай байж болно [имэйлээр хамгаалагдсан]. Домэйн conf.example.com нь Cisco Meeting Server хэрэглэгчдэд зориулагдсан домэйн юм. Cisco Meeting Server-ийн домайн байх болно conf.example.com, тиймээс ижил Jabber хэрэглэгчийн хувьд Cisco Meeting Server-д нэвтрэхийн тулд user@ URI ашиглах шаардлагатай болно.conf.example.com.
Үндсэн тохиргоо
Доор тайлбарласан бүх тохиргоог нэг сервер дээр харуулсан боловч кластер дахь сервер бүр дээр хийх шаардлагатай.
QoS
CMS үүсгэснээс хойш Бодит цаг Траффик саатал, пакет алдагдахад мэдрэмтгий байдаг тул ихэнх тохиолдолд үйлчилгээний чанарыг (QoS) тохируулахыг зөвлөж байна. Үүнд хүрэхийн тулд CMS нь үүсгэсэн ялгавартай үйлчилгээний кодууд (DSCP) бүхий пакетуудыг шошголохыг дэмждэг. Хэдийгээр DSCP-д суурилсан траффикийг эрэмбэлэх нь таны дэд бүтцийн сүлжээний бүрэлдэхүүн хэсгүүдийн траффикийг хэрхэн боловсруулж байгаагаас шалтгаалдаг ч манай тохиолдолд бид CMS-ээ QoS-ийн шилдэг туршлагууд дээр үндэслэн ердийн DSCP-ийн тэргүүлэх ач холбогдол бүхий тохируулах болно.
Сервер бүр дээр бид эдгээр тушаалуудыг оруулна
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
Бид дараах тушаалаар CMS-д DNS серверүүдийг нэмдэг.
dns add forwardzone <domain-name> <server ip>
Манайд ийм сервер хоёр байгаа тул хоёр баг байх болно.
Бид шалгадаг:
Сүлжээний интерфейсийн тохиргоо
Бид интерфэйсийг дараах тушаалаар тохируулдаг.
ipv4 <interface> add <address>/<prefix length> <gateway>
Бид шалгадаг:
Серверийн нэр (Хост нэр)
Бид серверийн нэрийг дараах тушаалаар тохируулна:
hostname <name>
Мөн бид дахин ачаална.
Энэ нь үндсэн тохиргоог хийж дуусгана.
Сертификат
ОнолCisco Meeting Server нь янз бүрийн бүрэлдэхүүн хэсгүүдийн хооронд шифрлэгдсэн харилцаа холбоог шаарддаг бөгөөд үүний үр дүнд CMS-ийн бүх байршуулалтад X.509 гэрчилгээ шаардлагатай байдаг. Эдгээр нь үйлчилгээ/серверийг бусад сервер/үйлчилгээнд найдвартай байлгахад тусалдаг.
Үйлчилгээ бүр нь гэрчилгээ шаарддаг боловч үйлчилгээ тус бүрт тусдаа гэрчилгээ үүсгэх нь төөрөгдөл, шаардлагагүй төвөгтэй байдалд хүргэж болзошгүй юм. Аз болоход бид гэрчилгээний нийтийн-хувийн түлхүүрийн хослолыг үүсгэж, дараа нь олон үйлчилгээнд дахин ашиглах боломжтой. Манай тохиолдолд ижил гэрчилгээг 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.cerWindows/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>Энд кластерыг эхлүүлсэн CMS серверийн одоо байгаа мастер IP хаяг нь зүгээр л Мастер.
Манай өгөгдлийн сангийн кластер бүх сервер дээр хэрхэн ажилладагийг бид дараах тушаалаар шалгадаг.
database cluster status
Бид үлдсэн гурав дахь сервер дээр ижил зүйлийг хийдэг.
Үүний үр дүнд бидний анхны сервер бол Мастер, бусад нь Боолууд юм.
Вэб админ үйлчилгээ
Вэб администраторын үйлчилгээг идэвхжүүлэх:
webadmin listen a 445445-р портыг вэб клиент рүү нэвтрэхэд ашигладаг тул 443-р портыг сонгосон
Бид вэб админ үйлчилгээг гэрчилгээний файлуудтай дараах тушаалаар тохируулдаг.
webadmin certs <keyfile> <certificatefile> <ca bundle>Вэб админыг дараах тушаалаар идэвхжүүлнэ үү.
webadmin enable
Хэрэв бүх зүйл сайн байвал бид вэб админыг сүлжээ болон гэрчилгээнд зөв тохируулсан болохыг харуулсан АМЖИЛТЫН мөрүүдийг хүлээн авах болно. Бид вэб хөтөч ашиглан үйлчилгээний ажиллагааг шалгаж, вэб администраторын хаягийг оруулна, жишээлбэл: : 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
Одоо бид Дуудлагын гүүрээ тохируулсан тул бид Дуудлагын гүүрний кластерийг тохируулах боломжтой. Call Bridge кластер нь мэдээллийн сан эсвэл XMPP кластераас ялгаатай. Call Bridge Cluster нь 2-8 цэгийг ямар ч хязгаарлалтгүйгээр дэмжих боломжтой. Энэ нь зөвхөн илүүдэлтэй байхаас гадна ачааллын тэнцвэржүүлэлтийг хангадаг бөгөөд ингэснээр ухаалаг дуудлагын түгээлтийг ашиглан Call Bridge серверүүдэд хурлыг идэвхтэй тарааж болно. CMS нь нэмэлт функцууд, Call Bridge бүлгүүд болон цаашдын удирдлагад ашиглагдах холбогдох функцуудтай.
Дуудлагын гүүрний кластерийг үндсэндээ вэб админ интерфэйсээр тохируулдаг
Доор тайлбарласан процедурыг кластер дахь сервер бүр дээр хийх ёстой.
Тэгэхээр
1. Вебээр дамжуулан Configuration > Cluster руу очно уу.
2. Дотор нь Бриджийн дугаарыг дуудах Өвөрмөц нэр болгон серверийн нэрэнд тохирох callbridge[01,02,03]-г оруулна уу. Эдгээр нэр дурын боловч энэ кластерт өвөрмөц байх ёстой. Тэдгээр нь серверийн таниулбар [01,02,03] гэдгийг харуулж байгаа учраас тэдгээр нь дүрслэх шинж чанартай байдаг.
3. Б Кластерт дуудлагын гүүрнүүд кластерт манай серверүүдийн вэб администраторын URL хаягийг оруулах, [01,02,03].example.com:445, Хаяг талбарт. Портыг зааж өгөхөө мартуузай. Та Peer link SIP домайныг хоосон орхиж болно.
4. Сервер бүрийн CallBridge итгэмжлэлд серверийн бүх гэрчилгээг агуулсан гэрчилгээг нэмж, бидний эхэнд нэгтгэсэн серверийн гэрчилгээг дараах тушаалаар хийнэ үү.
callbridge trust cluster <trusted cluster certificate bundle>Мөн дараах тушаалаар үйлчилгээг дахин эхлүүлнэ үү.
callbridge restart
Үүний үр дүнд сервер бүр дээр та дараах зургийг авах ёстой.
XMPP кластер
CMS дахь XMPP үйлчилгээг CMA WebRTC вэб клиент зэрэг Cisco Meeting Apps (CMA)-ын бүх бүртгэл, баталгаажуулалтыг зохицуулахад ашигладаг. Дуудлагын гүүр нь өөрөө баталгаажуулах зорилгоор XMPP үйлчлүүлэгчийн үүрэг гүйцэтгэдэг тул бусад үйлчлүүлэгчдийн нэгэн адил тохируулагдсан байх ёстой. XMPP алдааны хүлцэл нь 2.1 хувилбараас хойш үйлдвэрлэлийн орчинд дэмжигдсэн функц юм
Доор тайлбарласан тушаалуудыг сервер бүр дээр зохих гэрчилгээтэй гүйцэтгэх ёстой.
Тиймээс:
Бид гэрчилгээг XMPP үйлчилгээтэй дараах тушаалаар холбодог:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Дараа нь дараах тушаалаар сонсох интерфэйсийг тодорхойлно.
xmpp listen aXMPP үйлчилгээ нь өвөрмөц домэйн шаарддаг. Энэ бол хэрэглэгчдэд зориулсан нэвтрэлт юм. Өөрөөр хэлбэл, хэрэглэгч CMA програм (эсвэл WebRTC клиентээр дамжуулан) ашиглан нэвтрэхийг оролдох үед userID@logindomain гэж бичнэ. Манай тохиолдолд энэ нь userid@ байх болно.conf.example.com. Яагаад зөвхөн example.com биш юм бэ? Бид тусгайлан байршуулахдаа Jabber хэрэглэгчид Unified CM-д ашиглах Unified CM домайнаа example.com болгон сонгосон тул CMS хэрэглэгчдэд SIP домэйнуудаар дамжуулан CMS руу болон түүнээс гарах дуудлагыг чиглүүлэх өөр домэйн хэрэгтэй болсон.
XMPP домэйныг дараах тушаалыг ашиглан тохируулна уу:
xmpp domain <domain>XMPP үйлчилгээг дараах тушаалаар идэвхжүүлнэ үү.
xmpp enableXMPP үйлчилгээнд та XMPP үйлчилгээнд бүртгүүлэхдээ ашиглах Дуудлагын гүүр бүрт итгэмжлэл үүсгэх ёстой. Эдгээр нэр дур зоргоороо байдаг (мөн таны дуудлагын гүүрний кластерт тохируулсан өвөрмөц нэртэй холбоогүй). Та нэг XMPP сервер дээр гурван дуудлагын гүүр нэмж, дараа нь кластерын бусад XMPP серверүүд дээрх итгэмжлэлүүдийг оруулах ёстой, учир нь энэ тохиргоо нь кластерийн мэдээллийн санд тохирохгүй байна. Дараа нь бид Call Bridge бүрийг XMPP үйлчилгээнд бүртгүүлэхийн тулд энэ нэр болон нууцыг ашиглахаар тохируулах болно.
Одоо бид эхний сервер дээрх XMPP үйлчилгээг callbridge01, callbridge02, callbridge03 гэсэн гурван Call Bridges-тэй тохируулах хэрэгтэй. Бүртгэл бүрт санамсаргүй нууц үг оноох болно. Тэдгээрийг дараа нь энэ XMPP серверт нэвтрэхийн тулд бусад Call Bridge серверүүд дээр оруулах болно. Дараах тушаалуудыг оруулна уу:
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Бид нууцыг маш болгоомжтой нэмдэг бөгөөд жишээлбэл, дотор нь нэмэлт зай байхгүй болно.
Үүний үр дүнд сервер бүр ижил зурагтай байх ёстой:
Дараа нь кластерын бүх серверүүд дээр бид өмнө нь дараах тушаалаар үүсгэсэн бүх гурван гэрчилгээг агуулсан файлыг итгэлтэйгээр зааж өгнө.
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 кластер ажиллаж байгаа тул та XMPP кластерт холбогдохын тулд Call Bridge үйлчилгээг тохируулах хэрэгтэй. Энэ тохиргоог вэб админаар дамжуулан хийдэг.
Сервер бүр дээр Тохиргоо > Ерөнхий хэсэг болон талбарт очно уу Дуудлагын гүүрний өвөрмөц нэр Call Bridge серверт тохирох өвөрмөц нэрийг бичих callbridge[01,02,03]. Бүрэн домэйн conf.example.ru болон харгалзах нууц үг, та тэдгээрийг тагнаж болно
кластерын дурын сервер дээр дараах тушаалыг ашиглана:
xmpp callbridge list
"Сервер" талбарыг хоосон орхино уу Callbridge нь DNS SRV хайлт хийх болно _xmpp-component._tcp.conf.example.comболомжтой XMPP серверийг олохын тулд. Дуудлагын гүүрийг XMPP руу холбох IP хаяг нь сервер бүрт өөр өөр байж болох бөгөөд энэ нь бичлэгийн хүсэлтэд ямар утгыг буцааж өгөхөөс хамаарна. _xmpp-component._tcp.conf.example.com callbridge бөгөөд энэ нь эргээд тухайн DNS бичлэгийн тэргүүлэх тохиргооноос хамаарна.
Дараа нь, Дуудлага сүйт бүсгүй үйлчилгээ XMPP үйлчилгээнд амжилттай холбогдсон эсэхийг шалгахын тулд Status > General хэсэгт очно уу.
Вэб гүүр
Кластер дахь сервер бүр дээр Вэб гүүр үйлчилгээг дараах тушаалаар идэвхжүүлнэ үү.
webbridge listen a:443Бид Web Bridge үйлчилгээг гэрчилгээний файлуудтай дараах тушаалаар тохируулдаг.
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge HTTPS-ийг дэмждэг. Энэ нь "http-redirect" ашиглахаар тохируулагдсан бол HTTP-г HTTPS руу дахин чиглүүлэх болно.
HTTP дахин чиглүүлэлтийг идэвхжүүлэхийн тулд дараах тушаалыг ашиглана уу.
webbridge http-redirect enableВэб гүүр нь Call Bridge-ийн холболтод итгэж болохыг Call Bridge-д мэдэгдэхийн тулд дараах тушаалыг ашиглана уу:
webbridge trust <certfile>Энэ нь кластер дахь сервер бүрийн гурван гэрчилгээг агуулсан файл юм.
Энэ зураг нь кластерын бүх сервер дээр байх ёстой.
Одоо бид "appadmin" үүрэг бүхий хэрэглэгчийг үүсгэх хэрэгтэй. Энэ нь кластерын сервер бүрийг тусад нь биш, харин кластер (!)-ээ тохируулахын тулд хэрэгтэй бөгөөд ингэснээр тохиргоо нь сервер бүрт адилхан хэрэглэгдэх болно. тэд нэг удаа хийгдэх болно гэсэн баримт.
Цаашдын тохиргоонд бид ашиглах болно .
Зөвшөөрөл авахын тулд Зөвшөөрөл хэсгээс Үндсэн хэсгийг сонгоно уу
CMS сервер рүү тушаалуудыг зөв илгээхийн тулд та шаардлагатай кодчилолыг тохируулах хэрэгтэй
Бид Вэббриджийг командаар зааж өгдөг Шуудан параметртэй URL мөн утга
Вэб гүүрэнд бид шаардлагатай параметрүүдийг зааж өгдөг: зочны хандалт, хамгаалагдсан хандалт гэх мэт.
Бриджийн бүлгүүдийг дуудах
Анхдагч байдлаар, CMS нь өөрт байгаа хурлын нөөцийг үргэлж хамгийн үр ашигтайгаар ашигладаггүй.
Жишээлбэл, гурван оролцогчтой уулзалтын хувьд оролцогч бүр гурван өөр дуудлагын гүүрэн дээр байж болно. Эдгээр гурван оролцогч бие биетэйгээ харилцахын тулд Call Bridges нь нэг орон зай дахь бүх серверүүд болон үйлчлүүлэгчдийн хооронд автоматаар холболт үүсгэх бөгөөд ингэснээр бүх үйлчлүүлэгчид нэг сервер дээр байгаа мэт харагдана. Харамсалтай нь үүний сул тал нь 3 хүний нэг хурал одоо 9 медиа портыг ашиглах болно. Энэ нь нөөцийг үр ашиггүй зарцуулж байгаа нь ойлгомжтой. Нэмж дурдахад, Дуудлагын гүүр үнэхээр ачаалал ихтэй үед үндсэн механизм нь дуудлагыг үргэлжлүүлэн хүлээн авч, тухайн Дуудлагын гүүрний бүх захиалагчдад чанар муутай үйлчилгээ үзүүлэх явдал юм.
Эдгээр асуудлуудыг Call Bridge Group функцийг ашиглан шийддэг. Энэ функцийг Cisco Meeting Server программ хангамжийн 2.1 хувилбарт нэвтрүүлсэн бөгөөд WebRTC оролцогчдыг оруулаад дотогшоо болон гадагш чиглэсэн Cisco Meeting App (CMA) дуудлагын ачааллыг тэнцвэржүүлэх зорилгоор өргөтгөсөн.
Дахин холболтын асуудлыг шийдэхийн тулд дуудлагын гүүр бүрт тохируулж болох ачааллын гурван хязгаарыг нэвтрүүлсэн:
Ачааллын хязгаар — энэ нь тодорхой Call Bridge-ийн хамгийн их тоон ачаалал юм. Платформ бүр CMS96000-д 1000, виртуал машинд vCPU тутамд 1.25 GHz гэх мэт санал болгож буй ачааллын хязгаартай. Төрөл бүрийн дуудлага нь оролцогчийн нягтрал, фрэймийн хурдаас хамааран тодорхой хэмжээний нөөцийг зарцуулдаг.
NewConferenceLoadLimitBasisPoints (анхдагчаар 50% loadLimit) - серверийн ачааллын хязгаарыг тогтоосны дараа шинэ хурал хийхээс татгалздаг.
ExistingConferenceLoadLimitBasisPoints (loadLimit-ийн өгөгдмөл 80%) - серверийн ачааллын утга бөгөөд үүний дараа одоо байгаа хуралд нэгдэх оролцогчид татгалзах болно.
Энэ функц нь дуудлагыг түгээх, ачааллыг тэнцвэржүүлэхэд зориулагдсан байсан ч TURN серверүүд, вэб гүүр серверүүд болон дуу хураагч зэрэг бусад бүлгүүдийг мөн дуудлагын гүүрний бүлгүүдэд хуваарилах боломжтой бөгөөд ингэснээр тэдгээрийг оновчтой ашиглах зорилгоор зөв бүлэглэж болно. Хэрэв эдгээр объектуудын аль нэг нь дуудлагын бүлэгт хуваарилагдаагүй бол тэдгээр нь ямар нэгэн давуу эрхгүйгээр бүх серверт ашиглах боломжтой гэж үздэг.
Эдгээр параметрүүдийг энд тохируулсан болно: :445/api/v1/систем/тохиргоо/кластер
Дараа нь бид callbridge бүрд аль callbridge бүлэгт хамаарахыг зааж өгнө:
Анхны дуудлагын гүүр
Хоёр дахь дуудлагын гүүр
Гурав дахь дуудлагын гүүр
Тиймээс бид Cisco Meeting Server кластерын нөөцийг илүү үр ашигтай ашиглахын тулд Call Brdige бүлгийг тохируулсан.
Active Directory-ээс хэрэглэгчдийг импортлож байна
Вэб админ үйлчилгээ нь LDAP тохиргооны хэсэгтэй боловч нарийн төвөгтэй тохиргооны сонголтоор хангадаггүй бөгөөд мэдээлэл нь кластерийн мэдээллийн санд хадгалагдаагүй тул тохиргоог сервер бүр дээр вэб интерфэйсээр эсвэл гараар хийх шаардлагатай болно. API, бид гурван удаа "Бүү бос" гэж API-ээр дамжуулан өгөгдлийг тохируулах болно.
Хандахын тулд URL ашиглаж байна :445/api/v1/ldapServers нь LDAP серверийн объектыг үүсгэж, дараах параметрүүдийг зааж өгдөг:
- Серверийн IP
- портын дугаар
- Хэрэглэгчийн нэр
- нууц үг
- аюулгүй байдал
Secure - портоос хамааран үнэн эсвэл худал сонгох, 389 - аюулгүй биш, 636 - хамгаалагдсан.
LDAP эх сурвалжийн параметрүүдийг Cisco Meeting Server дээрх шинж чанаруудтай харьцуулах.
LDAP зураглал нь LDAP лавлах дахь шинж чанаруудыг CMS дэх шинж чанаруудтай харьцуулдаг. Бодит шинж чанарууд:
- jidMapping
- нэрийн зураглал
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Шинж чанаруудын тодорхойлолтIADB CMS-д хэрэглэгчийн нэвтрэх ID-г илэрхийлнэ. Энэ нь Microsoft Active Directory LDAP сервер тул CMS JID нь үндсэндээ хэрэглэгчийн Active Directory нэвтрэх ID болох LDAP дахь sAMAccountName-тай таардаг. Мөн та sAMAccountName-г авч, conf.pod6.cms.lab домайныг төгсгөлд нь нэмээрэй гэдгийг анхаарна уу, учир нь энэ нь таны хэрэглэгчид CMS-д нэвтрэхдээ ашиглах болно.
нэрийн зураглал Active Directory displayName талбарт байгаа зүйлийг хэрэглэгчийн CMS нэрийн талбартай тааруулна.
coSpaceNameMapping displayName талбар дээр үндэслэн CMS зайны нэрийг үүсгэдэг. Энэ шинж чанар нь coSpaceUriMapping шинж чанарын хамт хэрэглэгч бүрт орон зай үүсгэхэд шаардлагатай зүйл юм.
coSpaceUriMapping хэрэглэгчийн хувийн орон зайтай холбоотой URI-ийн хэрэглэгчийн хэсгийг тодорхойлдог. Зарим домэйныг орон зайд залгахаар тохируулж болно. Хэрэв хэрэглэгчийн хэсэг нь эдгээр домайнуудын аль нэгэнд энэ талбарт таарч байвал дуудлага тухайн хэрэглэгчийн орон зай руу чиглэнэ.
coSpaceSecondaryUriMapping орон зайд хүрэх хоёр дахь URI-г тодорхойлдог. Үүнийг coSpaceUriMapping параметрт тодорхойлсон үсэг, тоон URI-ийн оронд импортолсон хэрэглэгчийн зайд дуудлагыг чиглүүлэх тоон нэр нэмэхэд ашиглаж болно.
LDAP сервер болон LDAP зураглалыг тохируулсан. Одоо та LDAP эх сурвалж үүсгэн тэдгээрийг хооронд нь холбох хэрэгтэй.
Хандахын тулд URL ашиглаж байна :445/api/v1/ldapSource нь LDAP Source объектыг үүсгэж, дараах параметрүүдийг зааж өгнө.
- сервер
- зураглал
- baseDn
- шүүлтүүр
Одоо LDAP тохиргоо дууссан тул та гарын авлагын синхрончлолыг хийж болно.
Бид үүнийг сервер бүрийн вэб интерфэйс дээр дарж хийдэг Одоо синк хийх хэсэг Идэвхтэй лавлах
эсвэл тушаалаар API-ээр дамжуулан Шуудан хандахын тулд URL ашиглаж байна :445/api/v1/ldapSyncs
Түр зуурын хурал
Энэ юу вэ?Уламжлалт ойлголтод хоёр оролцогч хоорондоо ярилцаж байхад оролцогчдын нэг нь (Uniified CM-д бүртгэлтэй төхөөрөмж ашиглан) "Conference" товчийг дарж, нөгөө хүн рүү залгаж, гуравдагч этгээдтэй ярилцсаны дараа хурал гэдэг юм. , "Чуулган" товчийг дахин дарна. Гурван талт бага хуралд бүх оролцогчид нэгдэнэ.
Түр хурал нь CMS-ийн хуваарьтай бага хурлаас ялгагдах зүйл бол түр хурал нь зөвхөн CMS руу SIP дуудлага биш юм. Хурал санаачлагч хүн бүрийг нэг уулзалтад урихын тулд Хурлын товчийг хоёр дахь удаагаа товшиход Unified CM нь CMS-д API дуудлага хийх ёстой бөгөөд дараа нь бүх дуудлагыг дамжуулж шууд хурал үүсгэнэ. Энэ бүхэн оролцогчдын анзааралгүй явагддаг.
Энэ нь нэгдсэн CM нь дуудлагыг үргэлжлүүлэхийн тулд API итгэмжлэлүүд болон үйлчилгээний WebAdmin хаяг/порт, түүнчлэн SIP Trunk-ийг шууд CMS серверт тохируулах ёстой гэсэн үг юм.
Шаардлагатай бол CUCM нь CMS-д зайг динамикаар үүсгэж болох бөгөөд ингэснээр дуудлага бүр нь CMS-д хүрч, орон зайд зориулагдсан ирж буй дуудлагын дүрэмтэй таарч болно.
CUCM-тэй нэгтгэх нийтлэлд дурдсантай ижил аргаар тохируулсан Үүнээс гадна Cisco UCM дээр та CMS-д зориулж гурван их бие, гурван хурлын гүүр үүсгэх хэрэгтэй, SIP аюулгүй байдлын профайл дээр гурван сэдвийн нэр, маршрутын бүлэг, маршрутын жагсаалт, медиа нөөцийн бүлгүүд болон медиа нөөцийн бүлгүүдийн жагсаалтыг зааж, хэд хэдэн чиглүүлэлтийн дүрмийг нэмж оруулах хэрэгтэй. Cisco Meeting Server руу.
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-тэй холбогдсон хэвээр байгаа бөгөөд энэ нь дохиолол болон медиа хөдөлгөөний замд байх болно гэдгийг санаарай.
Дараа нь зөвхөн дамжуулсан дуудлага нь гарах дуудлагын дүрэмд хамаарна. Эдгээр тохиргоо нь дуудлагыг илгээх газар, trunk төрөл (шинэ Lync дуудлага эсвэл стандарт SIP дуудлага эсэх) болон дуудлага дамжуулах дүрмээр дамжуулалтыг сонгоогүй тохиолдолд хийж болох хөрвүүлэлтийг тодорхойлдог.
Түр зуурын бага хурлын үеэр юу болдог тухай бодит бүртгэл энд байна
Дэлгэцийн зураг нь үүнийг муу харуулж байна (би үүнийг яаж сайжруулахаа мэдэхгүй байна), би логийг дараах байдлаар бичнэ:
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 домайнаар импортолсон. Тиймээс та хамгийн багадаа энэ домайн руу орон зайг чиглүүлэхийн тулд дуудлага хийхийг хүсч байна. Та мөн CMS сервер бүрийн бүрэн эрхтэй домэйн нэр (болон магадгүй IP хаяг)-д зориулагдсан бүх зүйлд дүрмийг тохируулах хэрэгтэй болно. Манай гадаад дуудлагын удирдлага, Unified CM нь CMS сервер бүрт зориулагдсан SIP trunk-ийг тус тусад нь тохируулах болно. Эдгээр SIP trunk-ийн очих газар нь IP хаяг эсвэл серверийн FQDN эсэхээс хамаарч CMS-ийг өөрийн IP хаяг эсвэл FQDN руу чиглэсэн дуудлагыг хүлээн авахаар тохируулах шаардлагатай эсэхийг тодорхойлно.
Хамгийн чухал дотогшоо дүрэмтэй домэйн нь ямар ч хэрэглэгчийн орон зайд домэйн байдлаар ашиглагддаг. Хэрэглэгчид LDAP-ээр синк хийх үед CMS автоматаар зай үүсгэдэг, гэхдээ зөвхөн URI (coSpaceUriMapping)-ийн хэрэглэгчийн хэсэг, жишээ нь user.space. Хэсэг Энэ дүрэмд үндэслэн бүрэн URI-г үүсгэнэ. Үнэн хэрэгтээ, хэрэв та энэ үед Web Bridge руу нэвтрэх юм бол Space URI нь домэйнгүй болохыг харах болно. Энэ дүрмийг хамгийн чухал зүйл болгон тохируулснаар та үүсгэсэн зайн домайныг тохируулж байна conf.example.com.
Гарах дуудлагын дүрэм
Хэрэглэгчдэд нэгдсэн CM кластер руу гадагш дуудлага хийхийг зөвшөөрөхийн тулд та гадагшаа гарах дүрмийг тохируулах ёстой. Jabber гэх мэт Unified CM-д бүртгэгдсэн төгсгөлийн цэгүүдийн домэйн нь example.com юм. Энэ домэйны дуудлагыг нэгдсэн CM дуудлага боловсруулах зангилаа руу стандарт SIP дуудлага болгон чиглүүлэх ёстой. Үндсэн сервер нь cucm-01.example.com, нэмэлт сервер нь cucm-02.example.com юм.
Эхний дүрэм нь кластер серверүүдийн хоорондох дуудлагын хамгийн энгийн чиглүүлэлтийн талаар тайлбарладаг.
талбар Домэйн локал "@" тэмдгийн дараа залгаж буй хүний SIP-URI-д юу харагдахыг хариуцна. Хэрэв бид үүнийг хоосон орхивол "@" тэмдгийн дараа энэ дуудлага дамжих CUCM-ийн IP хаяг байх болно. Хэрэв бид домэйныг зааж өгвөл "@" тэмдгийн дараа домэйн байх болно. Энэ нь буцааж залгахын тулд зайлшгүй шаардлагатай, эс тэгвээс SIP-URI name@ip-address-ээр дахин залгах боломжгүй.
Заасан үед залгана уу Домэйн локал
Хэзээ залгана Үгүй заасан Домэйн локал
Автомат параметрт юу ч ажиллахгүй тул гарах дуудлагын хувьд Шифрлэгдсэн эсвэл Шифрлэгдээгүй гэж тодорхой зааж өгөхөө мартуузай.
Бичлэг хийх
Видео хурлыг Бичлэгийн сервер бичдэг. Дуу хураагуур нь Cisco Meeting Server-тэй яг адилхан. Дуу хураагч нь ямар ч лиценз суулгах шаардлагагүй. CallBridge үйлчилгээг ажиллуулж байгаа серверүүдэд бичлэг хийх лиценз шаардлагатай, i.e. Бичлэгийн лиценз шаардлагатай бөгөөд үүнийг Дуу хураагч ажиллаж байгаа серверт бус CallBridge бүрэлдэхүүн хэсэгт ашиглах ёстой. Дуу хураагч нь Өргөтгөх боломжтой Messaging and Presence Protocol (XMPP) клиент шиг ажилладаг тул XMPP серверийг CallBridge байршуулсан сервер дээр идэвхжүүлсэн байх ёстой.
Учир нь Бид кластертай бөгөөд лицензийг кластерын бүх гурван серверт "сунгах" шаардлагатай. Дараа нь бид кластерт багтсан бүх CMS серверүүдийн a-интерфэйсүүдийн MAC хаягуудыг лицензүүдэд таны хувийн дансанд холбодог (нэмдэг).
Энэ бол кластер дахь бүх сервер дээр байх ёстой зураг юм
Ерөнхийдөө дуу хураагчийг байрлуулах хэд хэдэн хувилбар байдаг ч бид үүнийг баримтална:
Дуу хураагчийг тохируулахын өмнө та видео хурал бичлэг хийх газрыг бэлтгэх хэрэгтэй. Үнэндээ энд , бүх бичлэгийг хэрхэн тохируулах талаар. Би чухал зүйл, нарийн ширийн зүйлд анхаарлаа хандуулдаг:
1. Сертификатыг кластерын эхний серверээс авсан нь дээр.
2. Recorder Trust-д буруу гэрчилгээ заасан тул “Бичлэгийн төхөөрөмж боломжгүй” алдаа гарч болзошгүй.
3. Бичлэг хийхээр заасан NFS лавлах нь үндсэн лавлах биш бол бичих ажиллахгүй байж магадгүй.
Заримдаа тодорхой нэг хэрэглэгч эсвэл орон зайн хурлыг автоматаар бичих шаардлагатай байдаг.
Үүний тулд хоёр CallProfiles үүсгэсэн:
Бичлэгийг идэвхгүй болгосон
Мөн автомат бичлэг хийх функцтэй
Дараа нь бид шаардлагатай зайд автомат бичлэг хийх функц бүхий CallProfile-г "хавсруулна".
CMS-д хэрэв CallProfile нь ямар ч орон зай эсвэл орон зайд тодорхой холбогдсон бол энэ CallProfile нь зөвхөн эдгээр тодорхой зайтай холбоотой ажилладаг болохыг тогтоосон. Хэрэв CallProfile нь ямар ч орон зайд холбогдоогүй бол анхдагч байдлаар энэ нь CallProfile тодорхой холбогдоогүй зайд хэрэглэгдэх болно.
Дараагийн удаа би байгууллагын дотоод сүлжээнээс гадуур CMS-д хэрхэн ханддаг талаар тайлбарлахыг хичээх болно.
Эх сурвалж:
Эх сурвалж: www.habr.com