Cisco Meeting Server 2.5.2. Video konfrans qeydi ilə Ölçəklənən və Dayanıqlı rejimdə çoxluq

Bu buraxılışda mən əvəzetmə klaster rejimində CMS serverinin qurulmasının bəzi incəliklərini göstərəcəyəm və izah edəcəyəm.


ТеорияÜmumiyyətlə, CMS server yerləşdirməsinin üç növü var:

• Tək Kombinə(Tək birləşdirilmiş), yəni. bütün lazımi xidmətləri işləyən bir serverdir. Əksər hallarda, bu cür yerləşdirmə yalnız daxili müştəri girişi üçün və tək server miqyası və ehtiyat məhdudiyyətlərinin kritik problem olmadığı kiçik mühitlərdə və ya CMS-in yalnız müəyyən funksiyaları yerinə yetirdiyi vəziyyətlərdə, məsələn, Cisco-da xüsusi konfranslar kimi tətbiq edilir. UCM.

  Təxmini iş sxemi:
  

• tək parçalanma(Single Shared) xarici giriş üçün ayrıca server əlavə edərək əvvəlki yerləşdirmə növünü genişləndirir. Köhnə yerləşdirmələrdə bu, xarici müştərilərin daxil ola biləcəyi silahsızlaşdırılmış şəbəkə seqmentində (DMZ) CMS serverini və daxili müştərilərin CMS-ə daxil olduğu şəbəkə nüvəsində tək CMS serverini yerləşdirmək demək idi. Bu xüsusi yerləşdirmə modeli indi sözdə tiplə əvəz olunur tək kənarserverlərdən ibarət olan Cisco Expressway, eyni Firewall bypass imkanlarının çoxuna sahib olan və ya olacaq, belə ki, müştərilərə xüsusi CMS kənar server əlavə etmək lazım deyil.

  Təxmini iş sxemi:
  

• Ölçəklənən və Davamlı(Ölçələnə bilən və Xətaya Dözümlü) Bu növə hər bir komponent üçün ehtiyat daxildir ki, bu da sistemin sizin ehtiyaclarınızla maksimum gücünə qədər böyüməsinə imkan verir və nasazlıq halında ehtiyat təmin edir. O, həmçinin təhlükəsiz xarici girişi təmin etmək üçün Single Edge konsepsiyasından istifadə edir. Bu epizodda bəhs edəcəyimiz növdür. Bu tip klasteri necə yerləşdirməyi başa düşsək, nəinki digər yerləşdirmə növlərini başa düşəcəyik, həm də ehtiyacların potensial artımını nəzərə alaraq CMS serverlərinin klasterlərinin necə yaradılacağını anlaya bilərik.

Yerləşdirməyə keçməzdən əvvəl bəzi əsas şeyləri başa düşməlisiniz, yəni

CMS-in əsas proqram komponentləri:

• Database: yığım planı, istifadəçi boşluqları və istifadəçilərin özləri kimi bəzi konfiqurasiyaları birləşdirməyə imkan verir. Yalnız yüksək əlçatanlıq (tək master) üçün klasterləşdirməni dəstəkləyir.
• zəng körpüsü: zənglərin və multimedia proseslərinin idarə edilməsi və emalı üzərində tam nəzarəti gətirən audio və video konfrans üçün xidmət. Yüksək əlçatanlıq və genişlənmə üçün klasterləşdirməni dəstəkləyir.
• XMPP server: Cisco Meeting Application və/və ya WebRTC-dən istifadə edərək müştərilərin qeydiyyatı və autentifikasiyasına cavabdehdir(real vaxt rabitəsi və ya sadəcə brauzerdə), həmçinin komponentlərarası siqnalizasiya. Yalnız yüksək əlçatanlıq üçün qruplaşdırıla bilər.
• veb körpü: WebRTC-yə müştəri girişini təmin edir.
• yük balanslaşdırıcısı: Single Split rejimində Cisco Meeting Apps üçün vahid əlaqə nöqtəsi təmin edir. Daxil olan əlaqələr üçün xarici interfeys və portu dinləyir. Eyni şəkildə, yük balanslaşdırıcısı XMPP serverindən daxil olan TLS bağlantılarını qəbul edir, onun vasitəsilə TCP bağlantılarını xarici müştərilərdən dəyişə bilər.
  Bizim ssenarimizdə buna ehtiyac olmayacaq.
• serveri TURN: İmkan verən Firewall bypass texnologiyasını təmin edir
  Cisco Meeting App və ya SIP cihazlarından istifadə edərək xarici müştəriləri birləşdirmək üçün CMS-imizi Firewall və ya NAT arxasında asın. Bizim ssenarimizdə buna ehtiyac olmayacaq.
• Veb Admin: Ad hoc Unified CM konfransları daxil olmaqla, inzibati interfeys və API girişi.

Konfiqurasiya rejimləri

Əksər digər Cisco məhsullarından fərqli olaraq, Cisco Meeting Server hər cür yerləşdirməni təmin etmək üçün üç konfiqurasiya metodunu dəstəkləyir.

• Komanda xətti (CLI): İlkin konfiqurasiya tapşırıqları və sertifikatlar üçün MMP kimi tanınan komanda xətti interfeysi.
• Veb Administratoru: Əsasən CallBridge ilə əlaqəli konfiqurasiya üçün, xüsusən də bir qruplaşdırılmamış serveri konfiqurasiya edərkən.
• REST API: Ən mürəkkəb konfiqurasiya və klaster verilənlər bazası tapşırıqları üçün istifadə olunur.

Yuxarıda göstərilənlərə əlavə olaraq, protokol SFTP faylları (adətən lisenziyaları, sertifikatları və ya jurnalları) CMS-ə və ya ondan köçürmək üçün.

Cisco-nun yerləşdirmə təlimatlarında, klasterin yerləşdirilməsinə ehtiyac olduğu ingilis və ağ dillərdə yazılıb. ən azı üç verilənlər bazası kontekstində serverlər (qovşaqlar). Çünki yalnız tək sayda qovşaqlarla yeni Database Master seçmək mexanizmi işləyəcək və ümumiyyətlə Database Master CMS serverinin verilənlər bazasının əksəriyyəti ilə əlaqəyə malikdir.

Təcrübə göstərir ki, iki server (qovşaq) həqiqətən kifayət deyil. Seçim mexanizmi Master yenidən işə salındıqda işləyir, Slave server yalnız yenidən işə salınan server qaldırıldıqdan sonra Master olur. Bununla belə, əgər iki serverdən ibarət çoxluqda Master server qəfildən “çıxırsa”, onda Slave server Master olmayacaq, Slave isə “çıxırsa”, qalan Master server Slave olacaq.

Ancaq XMPP kontekstində həqiqətən üç serverdən ibarət bir çoxluq toplamaq lazım olacaq, çünki məsələn, XMMP-nin Lider statusunda olduğu serverlərdən birində XMPP xidmətini deaktiv etsəniz, qalan XMPP serverində o, İzləyici statusunda qalacaq və CallBridge-in XMPP ilə əlaqələri kəsiləcək, çünki CallBridge yalnız Lider statuslu XMPP-yə qoşulur. Və bu kritikdir, çünki. heç bir zəng getməyəcək.

Həmçinin eyni yerləşdirmə təlimatlarında bir XMPP serveri olan klaster nümayiş etdirilir.

Və yuxarıda göstərilənləri nəzərə alaraq, niyə aydın olur: o, uğursuzluq rejimində olduğu üçün işləyir.

Bizim vəziyyətimizdə XMPP serveri hər üç qovşaqda mövcud olacaq.

Hər üç serverimizin işlədiyi güman edilir.

DNS qeydləri

Serverləri konfiqurasiya etməyə başlamazdan əvvəl DNS qeydləri yaratmalısınız А и SRV növləri:

Qeyd edək ki, DNS qeydlərimizdə example.com və iki domen var conf.example.com. Example.com, Cisco Unified Communication Manager-in bütün abunəçilərinin öz URI-ləri üçün istifadə edə biləcəyi, infrastrukturunuzda mövcud ola biləcək və ya mövcud olma ehtimalı olan bir domendir. Və ya example.com domeni istifadəçilərin e-poçt ünvanları üçün istifadə etdiyi eyni domenlə uyğun gəlir. Və ya laptopunuzdakı Jabber müştərisinin URI-si ola bilər [e-poçt qorunur]. Domen conf.example.com Cisco Meeting Server istifadəçiləri üçün konfiqurasiya ediləcək domendir. Cisco Meeting Server domeni olacaq conf.example.com, buna görə də eyni Jabber istifadəçisi Cisco Meeting Server-a daxil olmaq üçün URI user@ istifadə etməlidirconf.example.com.

Əsas konfiqurasiya

Aşağıda təsvir edilən bütün parametrlər bir serverdə göstərilir, lakin onlar klasterdəki hər bir serverdə edilməlidir.

QoS

Çünki CMS yaradır real-vaxt gecikmələrə və paket itkisinə həssas olan trafik, əksər hallarda xidmət keyfiyyətini (QoS) konfiqurasiya etmək tövsiyə olunur. Bunu etmək üçün CMS, yaratdığı fərqli xidmət kodları (DSCP) ilə markalanma paketlərini dəstəkləyir. DSCP əsaslı trafikin prioritetləşdirilməsi trafikin infrastrukturunuzun şəbəkə komponentləri tərəfindən necə idarə olunmasından asılı olsa da, bizim vəziyyətimizdə biz CMS-imizi QoS ən yaxşı təcrübələrinə əsaslanaraq tipik DSCP prioritetləşdirməsi ilə konfiqurasiya edəcəyik.

Hər bir serverdə bu əmrləri daxil edin

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

Beləliklə, bütün video trafiki AF41 (DSCP 0x22), bütün səs trafiki EF (DSCP 0x2E), SIP və XMPP kimi digər aşağı gecikmə trafiki AF31 (DSCP 0x1A) ilə etiketləndi.

Yoxlayırıq:

NTP

Şəbəkə Vaxt Protokolu (NTP) yalnız dəqiq zəng və konfrans vaxt markalarını təmin etmək üçün deyil, həm də sertifikatları yoxlamaq üçün vacibdir.

kimi bir əmrlə infrastrukturunuza NTP server əlavə edin

ntp server add <server>

Bizim vəziyyətimizdə iki belə server var, buna görə də iki komanda olacaq.
Yoxlayırıq:

Və serverimiz üçün vaxt qurşağını təyin edin

DNS

DNS serverləri CMS-ə aşağıdakı kimi bir əmrlə əlavə olunur:

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

Bizim vəziyyətimizdə iki belə server var, buna görə də iki komanda olacaq.
Yoxlayırıq:

Şəbəkə interfeysi konfiqurasiyası

Formanın əmri ilə interfeysi konfiqurasiya edirik:

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

Yoxlayırıq:

Server adı (Host adı)

Server adı forma əmri ilə təyin olunur:

hostname <name>

Və yenidən başladıq.


Bu, əsas konfiqurasiyanı tamamlayır.

Sertifikat

ТеорияCisco Meeting Server müxtəlif komponentlər arasında şifrələnmiş rabitə tələb edir və nəticədə bütün CMS yerləşdirmələri üçün X.509 sertifikatları tələb olunur. Onlar bir xidmətin/serverin digər serverlər/xidmətlər tərəfindən etibarlı olmasını təmin etməyə kömək edir.

Hər bir xidmət sertifikat tələb edir, lakin hər bir xidmət üçün ayrıca sertifikatların yaradılması çaşdırıcı və həddən artıq mürəkkəb ola bilər. Xoşbəxtlikdən, biz açıq/özəl açar cütü sertifikatı yarada və sonra onu çoxsaylı xidmətlərdə təkrar istifadə edə bilərik. Bizim vəziyyətimizdə eyni sertifikat Call Bridge, XMPP Server, Web Bridge və Web Admin üçün istifadə olunacaq. Beləliklə, siz klasterdəki hər bir server üçün açıq və özəl açar cütü sertifikatı yaratmalısınız.

Bununla belə, verilənlər bazasının klasterləşdirilməsi bəzi xüsusi sertifikat tələblərinə malikdir və buna görə də digər xidmətlərdən fərqli olan öz sertifikatlarını tələb edir. CMS digər serverlər tərəfindən istifadə edilən sertifikatlara bənzəyən server sertifikatından istifadə edir, lakin verilənlər bazası bağlantıları üçün istifadə olunan müştəri sertifikatı da var. Verilənlər bazası sertifikatları həm autentifikasiya, həm də şifrələmə üçün istifadə olunur. Müştərinin verilənlər bazasına qoşulması üçün istifadəçi adı və parol təqdim etmək əvəzinə, serverin etibar etdiyi müştəri sertifikatını təqdim edir. Verilənlər bazası klasterindəki hər bir server eyni ictimai/özəl açar cütündən istifadə edəcək. Bu, klasterdəki bütün serverlərə məlumatları şifrələməyə imkan verir ki, onlar yalnız eyni açar cütündən istifadə edən digər serverlər tərəfindən deşifrə olunsun.

Artıqlığın işləməsi üçün verilənlər bazası klasterləri ən azı 3 serverdən, maksimum 5-ə qədər, klasterin hər hansı üzvləri arasında maksimum gediş-gəliş müddəti 200 ms-dən ibarət olmalıdır. Bu hədd Zəng Körpüsü qruplaşması ilə müqayisədə daha məhdudlaşdırıcıdır, ona görə də coğrafi cəhətdən səpələnmiş yerləşdirmələrdə çox vaxt məhdudlaşdırıcı amildir.

CMS üçün verilənlər bazası rolunun bir sıra unikal tələbləri var. Digər rollardan fərqli olaraq, müştəri və server sertifikatı tələb olunur, burada müştəri sertifikatının serverə təqdim olunan xüsusi CN sahəsi var.

CMS bir master və bir neçə eyni replika ilə postgres verilənlər bazasından istifadə edir. İstənilən vaxtda yalnız bir əsas verilənlər bazası var (“verilənlər bazası serveri”). Qalan klaster üzvləri replikalar və ya “verilənlər bazası müştəriləri”dir.

Verilənlər bazası klasteri xüsusi server sertifikatı və müştəri sertifikatı tələb edir. Onlar sertifikatlarla, adətən daxili özəl CA ilə imzalanmalıdır. Verilənlər bazası klasterinin hər hansı bir üzvü master ola biləcəyi üçün verilənlər bazası serveri və müştəri sertifikatı cütləri (ictimai və şəxsi açarları ehtiva edən) bütün serverlərə kopyalanmalıdır ki, onlar müştəri və ya verilənlər bazası serverinin şəxsiyyətini qəbul edə bilsinlər. Bundan əlavə, müştəri və server sertifikatlarının yoxlanılmasını təmin etmək üçün kök CA sertifikatı yüklənməlidir.

Beləliklə, verilənlər bazası istisna olmaqla, bütün server xidmətləri tərəfindən istifadə ediləcək sertifikat üçün sorğu (bunun üçün ayrıca sorğu olacaq) kimi bir əmrlə formalaşdırırıq:

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

CN-də serverlərimizin ümumiləşdirilmiş adını yazırıq. Məsələn, əgər serverlərimizin host adları server 01, server 02, server 03, sonra CN olacaq server.example.com

Qalan iki serverdə eyni şeyi edirik, fərqlə əmrlər müvafiq "hostnames" ehtiva edir.

Verilənlər bazası xidməti tərəfindən forma əmrləri ilə istifadə olunacaq sertifikatlar üçün iki sorğu formalaşdırırıq:

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

pki csr dbclusterclient CN:postgres

hara dbcluster server и dbclusterclient sorğularımızın və gələcək sertifikatlarımızın adları, hostname1(2)(3) müvafiq serverlərin adları.

Biz bu proseduru yalnız bir serverdə (!) həyata keçiririk və biz sertifikatları və müvafiq .açar-faylları digər serverlərə yükləyəcəyik.

AD CS-də müştəri sertifikatı rejimini aktivləşdirin

Siz həmçinin hər bir server üçün sertifikatları bir faylda birləşdirməlisiniz*NIX-də:

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

Windows/DOS-da:

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

Və hər serverə yükləyin:
1. “Fərdi” server sertifikatı.
2. Kök sertifikatı (varsa, aralıq sertifikatlarla birlikdə).
3. Verilənlər bazasının “server” və “müştəri” sertifikatı üçün sorğunun yaradılması zamanı yaradılan verilənlər bazası (“server” və “klient”) və .key uzantılı fayllar üçün sertifikatlar. Bu fayllar bütün serverlərdə eyni olmalıdır.
4. Hər üç "fərdi" sertifikatın faylı.

Nəticədə, hər bir serverdə təxminən eyni fayl şəkli əldə edilməlidir.

Verilənlər bazası klasteri

İndi CMS serverlərinə yüklənmiş bütün sertifikatlarınız olduğundan, siz üç qovşaqda verilənlər bazası klasterini qura və aktivləşdirə bilərsiniz. İlk addım verilənlər bazası klasterinin master node kimi bir serveri seçmək və onu tam şəkildə konfiqurasiya etməkdir.

Master verilənlər bazası

Verilənlər bazasının təkrarlanmasının qurulmasında ilk addım verilənlər bazası üçün istifadə olunacaq sertifikatların müəyyən edilməsidir. Bu, aşağıdakı kimi bir əmrlə edilir:

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

İndi CMS-ə əmrlə verilənlər bazası klasterləşdirilməsi üçün hansı interfeysdən istifadə edəcəyini söyləyək:

database cluster localnode a

Sonra komanda ilə əsas serverdə klaster verilənlər bazasını işə salırıq:

database cluster initialize

Müştəri verilənlər bazası qovşaqları

Eyni proseduru yerinə yetiririk, yalnız əmr yerinə verilənlər bazası klasterinin işə salınması kimi bir əmr daxil edin:

database cluster join <ip address existing master>

burada ip ünvanı, klasterin işə salındığı CMS serverinin mövcud master ip ünvanı, sadəcə Master.

Verilənlər bazası klasterimizin bütün serverlərdə necə işlədiyini əmrlə yoxlayırıq:

database cluster status

Qalan üçüncü serverdə də eyni şeyi edirik.

Nəticədə məlum olur ki, birinci serverimiz Master, qalanları isə Slavesdir.

Veb Admin Xidməti

Veb administrator xidmətini aktivləşdirin:

webadmin listen a 445

445-ci port seçilmişdir, çünki 443-cü port istifadəçinin veb müştəriyə girişi üçün istifadə olunur

Veb Admin xidmətini sertifikat faylları ilə aşağıdakı əmrlə konfiqurasiya edirik:

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

Və əmrlə Veb Admini aktivləşdirin:

webadmin enable

Hər şey qaydasındadırsa, Veb Admininin şəbəkə və sertifikat üçün düzgün konfiqurasiya edildiyini göstərən UĞUR sətirləri alacağıq. Veb brauzerindən istifadə edərək xidmətin sağlamlığını yoxlayırıq və veb administratorun ünvanını daxil edirik, məsələn: cms.example.com: 445

Bridge Cluster-ə zəng edin

Call Bridge hər bir CMS yerləşdirməsində mövcud olan yeganə xidmətdir. Call Bridge əsas konfrans mexanizmidir. O, həmçinin SIP interfeysini təmin edir ki, zənglər Cisco Unified CM kimi ona və ya ondan yönləndirilə bilsin.

Aşağıdakı əmrlər müvafiq sertifikatlarla hər bir serverdə işlədilməlidir.
Belə ki:

Sertifikatları Zəng Körpüsü xidməti ilə aşağıdakı kimi bir əmrlə əlaqələndirin:

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

CallBridge xidmətlərini əmrlə ehtiyac duyduğumuz interfeysə bağlayırıq:

callbridge listen a

Və əmrlə xidməti yenidən başladın:

callbridge restart

İndi Zəng Körpülərimizi konfiqurasiya etdikdən sonra Zəng Körpüsü qruplaşmasını qura bilərik. Zəng Körpüsü qruplaşması verilənlər bazası və ya XMPP klasterindən fərqlidir. Call Bridge Cluster heç bir məhdudiyyət olmadan 2 ilə 8 nodu dəstəkləyə bilər. O, nəinki artıqlığı, həm də yük balansını təmin edir ki, konfranslar ağıllı zəng paylanmasından istifadə edərək Zəng Körpüsü serverləri arasında aktiv şəkildə paylana bilsin. CMS əlavə funksiyalara, Zəng Körpüsü qruplarına və sonrakı idarəetmə üçün istifadə edilə bilən əlaqəli funksiyalara malikdir.

Zəng körpüsünün qruplaşdırılması əsasən veb admin interfeysi vasitəsilə konfiqurasiya edilir
Hər bir klaster serverində aşağıdakı prosedur yerinə yetirilməlidir.
Belə ki,

1. Konfiqurasiya> Klasterdə internetdən keçirik.
2. Məqalədə: körpü şəxsiyyətinə zəng edin unikal ad olaraq server adına uyğun callbridge[01,02,03] daxil edin. Bu adlar ixtiyaridir, lakin bu klaster üçün unikal olmalıdır. Onlar təsviri xarakter daşıyır ki, onlar server identifikatorlarıdır [01,02,03].
3.B Çoxluqlu Zəng Körpüləri serverlərimizin veb admin URL-lərini klasterə daxil edin, sm[01,02,03].example.com:445, Ünvan sahəsində. Portu göstərdiyinizə əmin olun. Peer link SIP domenini boş qoya bilərsiniz.
4. Biz hər server üçün CallBridge-in etibarına sertifikat əlavə edirik, onun faylında ən əvvəl bu fayla birləşdirdiyimiz serverlərimizin bütün sertifikatları var, belə bir əmrlə:

callbridge trust cluster <trusted cluster certificate bundle>

Və əmrlə xidməti yenidən başladın:

callbridge restart

Nəticədə, hər bir serverdə aşağıdakı şəkli almalısınız:

XMPP çoxluğu

CMS-dəki XMPP xidməti CMA WebRTC Veb Müştərisi də daxil olmaqla Cisco Meeting Apps (CMA) üçün bütün qeydiyyat və autentifikasiyanı idarə etmək üçün istifadə olunur. Zəng körpüsünün özü də autentifikasiya məqsədləri üçün XMPP müştərisi kimi çıxış edir və buna görə də digər müştərilər kimi konfiqurasiya edilməlidir. XMPP uğursuzluğu 2.1 versiyasından bəri istehsal mühitlərində dəstəklənən bir xüsusiyyətdir

Aşağıdakı əmrlər müvafiq sertifikatlarla hər bir serverdə işlədilməlidir.
Belə ki:

Sertifikatları XMPP xidməti ilə aşağıdakı kimi bir əmrlə əlaqələndirin:

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

Sonra əmrlə dinləmə interfeysini təyin edin:

xmpp listen a

XMPP xidməti unikal domen tələb edir. Bu istifadəçilər üçün girişdir. Başqa sözlə, istifadəçi CMA proqramından istifadə edərək (və ya WebRTC müştərisi vasitəsilə) daxil olmağa çalışdıqda userID@logindomain daxil olur. Bizim vəziyyətimizdə userid@ olacaqconf.example.com. Niyə sadəcə example.com deyil? Xüsusi yerləşdirməmizdə biz Jabber istifadəçilərinin Unified CM-də example.com kimi istifadə edəcəyi Vahid CM domenimizi seçdik, ona görə də CMS istifadəçiləri üçün SIP domenləri vasitəsilə CMS-ə və ondan gələn zəngləri yönləndirmək üçün bizə fərqli domen lazımdır.

XMPP domenini aşağıdakı kimi bir əmrlə qurun:

xmpp domain <domain>

Və XMPP xidmətini əmrlə aktivləşdirin:

xmpp enable

XMPP xidmətində siz XMPP xidmətində qeydiyyatdan keçərkən istifadə olunacaq hər bir Zəng körpüsü üçün etimadnamə yaratmalısınız. Bu adlar ixtiyaridir (və zəng körpüsünün qruplaşdırılması üçün konfiqurasiya etdiyiniz unikal adlarla əlaqəli deyil). Siz bir XMPP serverinə üç zəng körpüsü əlavə etməli və sonra bu etimadnamələri klasterdəki digər XMPP serverlərinə daxil etməlisiniz, çünki bu konfiqurasiya klaster verilənlər bazasına uyğun gəlmir. Daha sonra biz hər bir Zəng körpüsünü XMPP xidmətində qeydiyyatdan keçmək üçün bu ad və sirrdən istifadə etmək üçün konfiqurasiya edəcəyik.

İndi biz ilk serverdə XMPP xidmətini üç Callbridge01, callbridge02 və callbridge03 Zəng Körpüsü ilə qurmalıyıq. Hər bir hesaba təsadüfi parollar təyin ediləcək. Daha sonra onlar bu XMPP serverinə daxil olmaq üçün digər Zəng Körpüsü serverlərinə daxil ediləcəklər. Aşağıdakı əmrləri daxil edin:

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

Nəticədə əmrlə nə baş verdiyini yoxlayırıq:

xmpp callbridge list

Aşağıda təsvir edilən addımlardan sonra eyni şəkil digər serverlərdə də olmalıdır.

Sonra, qalan iki serverə eyni parametrləri yalnız əmrlərlə əlavə edirik

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

Məsələn, əlavə boşluqlar təsadüfən daxil olmasın deyə, çox diqqətlə Secret əlavə edirik.


Nəticədə, hər bir serverdə eyni şəkil olmalıdır:

Bundan sonra, klasterin bütün serverlərində, formanın əmri ilə əvvəllər yaradılmış hər üç sertifikatı ehtiva edən bir faylı etibarla təyin edirik:

xmpp cluster trust <trust bundle>

Komanda ilə bütün klaster serverlərində klaster xmpp rejimini aktivləşdirin:

xmpp cluster enable

Klasterin ilk serverində biz əmrlə xmpp klasterinin yaradılmasına başlayırıq:

xmpp cluster initialize

Digər serverlərdə biz xmpp-ə aşağıdakı kimi bir əmrlə klaster əlavə edirik:

xmpp cluster join <ip address head xmpp server>

Hər bir serverdə hər serverdə XMPP klasterinin yaradılmasının müvəffəqiyyətini əmrlərlə yoxlayırıq:

xmpp status
xmpp cluster status

Birinci server:

İkinci server:

Üçüncü server:

Zəng körpüsü XMPP-yə qoşulur

İndi XMPP klasteri işləyir, XMPP klasterinə qoşulmaq üçün Zəng Körpüsü xidmətlərini konfiqurasiya etməliyik. Bu konfiqurasiya veb administrator vasitəsilə həyata keçirilir.

Biz hər serverə Konfiqurasiya> Ümumi və sahədə gedirik Unikal Zəng Körpüsü adı serverə uyğun gələn Zəng körpüsünün unikal adlarını yazırıq callbridge[01,02,03]. Bəli Domain conf.example.com və müvafiq parollar, siz onlara casusluq edə bilərsiniz
əmri ilə istənilən klaster serverində:

xmpp callbridge list

"Server" sahəsini boş buraxın. callbridge üçün DNS SRV axtarışını həyata keçirəcək _xmpp-component._tcp.conf.example.commövcud XMPP serverini tapmaq üçün. Zəng körpülərini XMPP-yə qoşmaq üçün IP ünvanları hər bir serverdə fərqli ola bilər, bu, yazma sorğusuna hansı dəyərlərin qaytarılmasından asılıdır. _xmpp-component._tcp.conf.example.com callbridge, bu da öz növbəsində bu DNS qeydinin prioritet parametrlərindən asılıdır.

Sonra, Zəng Gəlin xidmətinin XMPP xidmətinə uğurla qoşulduğunu görmək üçün Status > Ümumi bölməsinə keçin.

veb körpü

Hər bir klaster serverində Web Bridge xidmətini əmrlə aktivləşdirin:

webbridge listen a:443

Web Bridge xidmətini sertifikat faylları ilə aşağıdakı əmrlə konfiqurasiya edirik:

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

Web Bridge HTTPS-i dəstəkləyir. "http-yönləndirmə" istifadə etmək üçün konfiqurasiya olunarsa, o, HTTP-ni HTTPS-ə yönləndirəcək.
HTTP yönləndirməsini aktivləşdirmək üçün aşağıdakı əmrdən istifadə edin:

webbridge http-redirect enable

Zəng Körpüsünə Web Bridge-in Zəng Körpüsündən bağlantılar üçün etibar edilə biləcəyini söyləmək üçün əmrdən istifadə edin:

webbridge trust <certfile>

klasterdəki hər bir serverdən hər üç sertifikatı ehtiva edən fayl haradadır.

Belə bir şəkil klasterin hər bir serverində olmalıdır.


İndi "appadmin" rolu olan bir istifadəçi yaratmalıyıq, bizə lazımdır ki, klasterimizi (!) konfiqurasiya edə bilək, klasterin hər bir serverini ayrıca deyil, buna görə də parametrlər hər bir serverə bərabər şəkildə tətbiq olunacaq. bir dəfə düzəldiləcəklər.


Əlavə fərdiləşdirmə üçün istifadə edəcəyik Poçtalyon.

Avtorizasiya üçün Avtorizasiya bölməsində Əsas seçin

Əmrləri CMS serverlərinə düzgün göndərmək üçün istədiyiniz kodlaşdırmanı təyin etməlisiniz

Komanda ilə Webbridge-i təyin edin POST parametri ilə url və məna cms.example.com



Veb-körpünün özündə biz lazım olan parametrləri müəyyənləşdiririk: qonaq girişi, təhlükəsiz giriş və s.

Bridge qruplarına zəng edin

Varsayılan olaraq, CMS həmişə onun üçün mövcud olan konfrans resurslarından maksimum istifadə etmir.

Məsələn, üç iştirakçı ilə görüş üçün hər bir iştirakçı üç fərqli Call Bridge'ax ola bilər. Bu üç iştirakçının bir-biri ilə əlaqə saxlaması üçün Zəng Körpüləri avtomatik olaraq eyni Məkandakı bütün serverlər və müştərilər arasında əlaqə yaradacaq, beləliklə, bütün müştərilər eyni serverdəymiş kimi görünür. Təəssüf ki, bunun mənfi tərəfi odur ki, bir 3 nəfərlik konfrans indi 9 media portunu istehlak edəcəkdir. Bu, təbii ki, resursların səmərəsiz istifadəsidir. Həmçinin, Zəng Körpüsü həqiqətən sıx olduqda, standart mexanizm zəngləri qəbul etməyə davam etmək və həmin Zəng Körpüsünün bütün abunəçilərinə aşağı keyfiyyətli xidmət göstərməkdir.

Bu problemlər Call Bridge Group funksiyasından istifadə etməklə həll edilir. Bu funksiya Cisco Meeting Server Proqramının 2.1 versiyasında təqdim edilib və WebRTC iştirakçıları da daxil olmaqla, Cisco Meeting App (CMA) daxil olan və gedən zənglər üçün yük balansını dəstəkləmək üçün genişləndirilib.

Yenidən qoşulma problemini həll etmək üçün hər Zəng Körpüsü üçün üç konfiqurasiya edilə bilən yük limiti tətbiq edilmişdir:

yük limiti xüsusi Zəng körpüsü üçün maksimum ədədi yükdür. Hər platformanın tövsiyə olunan yükləmə limiti var, məsələn, CMS96000 üçün 1000 və virtual maşın üçün virtual prosessor üçün 1.25 GHz. Müxtəlif zənglər iştirakçının həlli və kadr sürətindən asılı olaraq müəyyən miqdarda resurs sərf edir.
NewConferenceLoadLimitBasisPoints (standart 50% loadLimit) - yeni konfransların rədd edildiyi server yükləmə limitini təyin edir.
Mövcud KonfransYük LimitiBasisPoints (default loadLimit-in 80%-i) - Server yükləmə dəyəri bundan sonra mövcud konfransa qoşulan iştirakçılar rədd ediləcək.

Bu funksiya zənglərin paylanması və yük balansı üçün nəzərdə tutulsa da, TURN serverləri, Veb Körpü serverləri və yazıcı kimi digər qruplar da Zəng Körpüsü Qruplarına təyin edilə bilər ki, onlar da optimal istifadə üçün düzgün qruplaşdırıla bilsinlər. Əgər bu obyektlərdən hər hansı biri zəng qrupuna təyin edilməyibsə, onların heç bir xüsusi prioritet olmadan bütün serverlər üçün əlçatan olduğu güman edilir.

Bu parametrlər burada konfiqurasiya edilir: cms.example.com:445/api/v1/sistem/konfiqurasiya/klaster

Sonra, hər bir zəng körpüsünə hansı callbridge qrupuna aid olduğunu göstəririk:

İlk zəng körpüsü

İkinci zəng körpüsü

Üçüncü zəng körpüsü


Beləliklə, biz Call Brdige qrupunu Cisco Meeting Server klasterinin resurslarından daha səmərəli istifadə etmək üçün konfiqurasiya etdik.

İstifadəçilərin Active Directory-dən idxalı

Veb İdarəetmə xidmətində LDAP konfiqurasiya bölməsi var, lakin o, mürəkkəb konfiqurasiya seçimlərini təmin etmir və məlumat klaster verilənlər bazasında saxlanmır, ona görə də konfiqurasiya ya Veb interfeysi vasitəsilə hər bir serverdə əl ilə aparılmalı, və ya API vasitəsilə və biz "üç dəfə qalxmırıq" deyə, biz hələ də API vasitəsilə məlumatları təyin edəcəyik.

Giriş üçün URL istifadə edin cms01.example.com:445/api/v1/ldapServers aşağıdakı kimi parametrləri təyin edərək LDAP Server obyekti yaradır:

• Server IP
• port nömrəsi
• istifadəçi adı
• parol
• təmin etmək

Secure - portdan asılı olaraq doğru və ya yalan, 389 - təhlükəsiz deyil, 636 - təhlükəsiz.


LDAP Mənbə Seçimlərinin Cisco Görüş Serverində Atributlara Xəritəçəkmə.
LDAP xəritələşdirilməsi LDAP kataloqundakı atributları CMS-dəki atributlarla əlaqələndirir. Əslində atributlar:

• jidMapping
• ad Xəritəçəkmə
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Atributların təsviriJID CMS-də istifadəçinin giriş ID-sini təmsil edir. Bu, Microsoft Active Directory LDAP serveri olduğundan, CMS JID mahiyyətcə istifadəçinin Active Directory giriş ID-si olan LDAP-da sAMAccountName ilə xəritələnir. Həmçinin nəzərə alın ki, siz sAMAccountName götürürsünüz və onun sonuna conf.pod6.cms.lab domenini əlavə edirsiniz, çünki bu, istifadəçilərinizin CMS-ə daxil olmaq üçün istifadə edəcəyi girişdir.

ad Xəritəçəkmə Active Directory displayName sahəsində olanları istifadəçinin CMS adı sahəsinə uyğunlaşdırır.

coSpaceNameMapping displayName sahəsinə əsaslanan boşluq'a CMS adı yaradır. Bu atribut coSpaceUriMapping atributu ilə birlikdə hər bir istifadəçi üçün yer yaratmaq üçün tələb olunandır.

coSpaceUriMapping istifadəçinin şəxsi məkanı ilə əlaqəli URI-nin istifadəçi hissəsini müəyyən edir. Bəzi domenlər məkana təyin olunmaq üçün konfiqurasiya edilə bilər. Əgər istifadəçi hissəsi bu domenlərdən biri üçün bu sahəyə uyğun gəlirsə, zəng həmin istifadəçinin sahəsinə yönəldiləcək.

coSpaceSecondaryUriMapping kosmosa çatmaq üçün ikinci URI-ni təyin edir. Bu, coSpaceUriMapping parametrində göstərilən alfanümerik URI-yə alternativ olaraq idxal edilmiş istifadəçinin məkanına zəngləri yönləndirmək üçün rəqəmsal ləqəb əlavə etmək üçün istifadə edilə bilər.

LDAP serveri və LDAP xəritəsi konfiqurasiya edilib. İndi LDAP mənbəyi yaratmaqla onları bir-birinə bağlamalıyıq.

Giriş üçün URL istifadə edin cms01.example.com:445/api/v1/ldapSource aşağıdakı kimi parametrləri təyin edərək LDAP Mənbə obyekti yaradır:

• server
• Xəritəçəkmə
• əsaslıDn
• Süzgəc

İndi LDAP quraşdırması tamamlandığından, siz əl ilə sinxronizasiya əməliyyatını yerinə yetirə bilərsiniz.

Bunu ya hər serverin Veb interfeysində klikləməklə edirik İndi sinxronlaşdırın bölmə Active Directory


və ya API əmri ilə POST daxil olmaq üçün URL istifadə edin cms01.example.com:445/api/v1/ldapSyncs

Xüsusi konfranslar

Bu nədir?Konfransın ənənəvi konsepsiyasında bu, iki iştirakçının bir-biri ilə danışması və iştirakçılardan birinin (Vahid CM-də qeydiyyatdan keçmiş cihazdan istifadə edərək) “Konfrans” düyməsini basması, digər şəxsə zəng etməsi və bu üçüncü şəxslə danışdıqdan sonra partiya, üç partiyalı konfransın bütün iştirakçılarına qoşulmaq üçün yenidən "Konfrans" düyməsini sıxır.

Ad-Hoc konfransı və planlaşdırılmış CMS konfransı arasındakı fərq, Ad-Hoc konfransının yalnız CMS-ə SIP zəngi olmamasıdır. Konfransın təşəbbüskarı hamını eyni görüşə dəvət etmək üçün Konfrans düyməsini ikinci dəfə kliklədikdə, Vahid CM bütün zənglərin ötürüldüyü anında konfrans yaratmaq üçün CMS-ə API çağırışı etməlidir. Bütün bunlar iştirakçılara görünməz şəkildə baş verir.

Bu o deməkdir ki, Vahid CM çağırışı davam etdirmək üçün API etimadnaməsini və WebAdmin xidmət ünvanını/portunu, həmçinin SIP Trunk-ı birbaşa CMS serverinə konfiqurasiya etməlidir.

Lazım gələrsə, CUCM dinamik olaraq CMS-də boşluq yarada bilər ki, hər bir zəng CMS-ə çata bilsin və boşluqlar üçün nəzərdə tutulmuş gələn zəng qaydasına uyğun gəlsin.

CUCM ilə inteqrasiya məqalədə təsvir edildiyi kimi konfiqurasiya edilmişdir əvvəllər istisna olmaqla, Cisco UCM-də siz CMS üçün üç magistral, üç Konfrans Körpüsü yaratmalı, SIP Təhlükəsizlik Profilində, Marşrut Qrupunda, Marşrut Siyahısında, Media Resurs Qrupunda və Media Resurs Qrupu Siyahısında üç Mövzu Adını təyin etməli və Cisco-ya bəzi marşrutlaşdırma qaydaları əlavə etməlisiniz. Görüş Serveri.

SIP Təhlükəsizlik Profili:


Gövdələr:


Hər bir gövdə eyni görünür:




Konfrans körpüsü


Hər Konfrans Körpüsü eyni görünür:


Marşrut Qrupu


marşrut siyahısı


Media Resurs Qrupu


Media Resurs Qrupunun Siyahısı

Zəng qaydaları

Unified CM və ya Expressway kimi daha təkmil zəng nəzarət sistemlərindən fərqli olaraq, yeni zənglər üçün CMS yalnız SIP Request-URI sahəsində domeni axtarır. Beləliklə, əgər SIP INVITE qurtum üçündürsə: [e-poçt qorunur], CMS yalnız domain.com ilə maraqlanır. Zəngin hara yönəldiləcəyini müəyyən etmək üçün CMS bu qaydalara əməl edir:

1. Birincisi, CMS SIP domenini daxil olan zənglərin idarə edilməsi qaydalarında konfiqurasiya edilmiş domenlərlə əlaqələndirməyə çalışır. Bu zənglər daha sonra (“hədəf”) boşluqlara və ya xüsusi istifadəçilərə, daxili IVR-lərə və ya birbaşa inteqrasiya olunmuş Microsoft Lync/Skype for Business (S4B) təyinatlarına yönləndirilə bilər.
2. Əgər daxil olan zənglərin idarə edilməsi qaydalarında uyğunluq yoxdursa, CMS zəng yönləndirmə cədvəlində konfiqurasiya edilmiş domeni uyğunlaşdırmağa çalışacaq. Uyğunluq müəyyən edilərsə, qayda zəngi açıq şəkildə rədd edə və ya zəngi yönləndirə bilər. Bu müddət ərzində CMS domeni yenidən yaza bilər ki, bu da bəzən Lync domenlərinə zəng etmək üçün faydalıdır. Siz həmçinin keçid atmağı seçə bilərsiniz, bu o deməkdir ki, sahələrin heç biri əlavə olaraq dəyişdirilməyəcək və ya daxili CMS yığım planından istifadə edin. Zəngin yönləndirilməsi qaydalarında uyğunluq yoxdursa, defolt olaraq zəngdən imtina istifadə olunur. Nəzərə alın ki, CMS-də zəng “yönləndirilsə” də, media hələ də CMS-ə bağlıdır, yəni o, siqnalizasiya və media trafiki yolunda olacaq.
Sonra yalnız yönləndirilmiş zənglər gedən zəng qaydalarına tabedir. Bu parametrlər zənglərin göndərildiyi təyinat yerlərini, magistralın növünü (istər yeni Lync zəngi, istərsə də standart SIP) və zəng yönləndirmə qaydasında transfer seçilmədikdə həyata keçirilə biləcək hər hansı tərcümələri müəyyən edir.

Budur Ad-Hoc konfransı zamanı baş verənlərin faktiki qeydi

Ekran görüntüsü zəif görünür (bunu daha yaxşı necə edəcəyimi bilmirəm), ona görə də jurnalı belə yazacağam:

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 konfransın özü:


Daxil olan zəng qaydaları
CMS-də zəng qəbul etmək üçün daxil olan zəng parametrlərini konfiqurasiya etmək tələb olunur. LDAP quraşdırmasında gördüyünüz kimi, bütün istifadəçilər conf.pod6.cms.lab domeni ilə idxal edilib. Beləliklə, ən azı boşluqları hədəfləmək üçün bu domenə zəng etmək istəyirsiniz. Siz həmçinin hər bir CMS serverinin FQDN (və bəlkə də IP ünvanı) üçün olan hər şey üçün qaydalar qurmalısınız. Xarici zəng nəzarətimiz, Birləşdirilmiş CM, hər bir CMS serverinə ayrı-ayrılıqda həsr olunmuş SIP magistrallarını quraşdıracaq. Bu SIP magistrallarının təyinat yerinin IP ünvanı və ya serverin FQDN-si olması CMS-in onun IP ünvanına və ya FQDN-ə yönəldilmiş zəngləri qəbul etmək üçün konfiqurasiya edilməsinin lazım olub-olmadığını müəyyən edəcək.

Ən yüksək prioritet daxilolma qaydasına malik olan domen istənilən istifadəçi məkanı üçün domen kimi istifadə olunur. İstifadəçilər LDAP vasitəsilə sinxronizasiya etdikdə, CMS avtomatik olaraq boşluqlar yaradır, lakin yalnız user.space kimi URI-nin (coSpaceUriMapping) istifadəçi hissəsini yaradır. Hissə domain tam URI bu qayda əsasında yaradılır. Əslində, bu anda Web Bridge-ə daxil olsanız, Space URI-nin domeni olmadığını görərdiniz. Bu qaydanı ən yüksək prioritet kimi təyin etməklə, yaradılan boşluqlar üçün domeni təyin edirsiniz conf.example.com.


Gedən zəng qaydaları

İstifadəçilərə Vahid CM klasterinə gedən zənglər etməyə icazə vermək üçün siz çıxış qaydalarını konfiqurasiya etməlisiniz. Jabber kimi Unified CM-də qeydiyyatdan keçmiş son nöqtələrin domeni example.com-dur. Bu domenə edilən zənglər standart SIP zəngləri kimi Vahid CM zəng emalı qovşaqlarına yönləndirilməlidir. Əsas server cucm-01.example.com, ikinci server isə cucm-02.example.com-dur.

Birinci qayda klaster serverləri arasında ən sadə zəng marşrutunu təsvir edir.

Sahə Domendən yerli “@” simvolundan sonra zəng edənin SIP-URI-də nə göstəriləcəyinə görə cavabdehdir. Onu boş qoysaq, "@" simvolundan sonra bu zəngin keçdiyi CUCM'a-nın ip-ünvanı olacaq. Bir domen təyin etsək, “@” simvolundan sonra əslində domen olacaq. Bu, geri zəng edə bilmək üçün lazımdır, əks halda SIP-URI name@ip-ünvanından istifadə edərək geri zəng etmək mümkün olmayacaq.

Göstərilən zaman zəng edin Domendən yerli


nə vaxt zəng edin EDİLMƏDİ göstərilib Domendən yerli


Çıxan zənglər üçün Şifrələnmiş və ya Şifrələnməmiş parametrləri açıq şəkildə göstərdiyinizə əmin olun, çünki heç bir şey Avtomatik parametrlə işləmir.

Qeyd

Video konfranslar Record-server tərəfindən qeydə alınır. Recorder eyni Cisco Meeting Serverdir. Recorder öz üzərində heç bir lisenziyanın quraşdırılmasını tələb etmir. CallBridge xidmətləri ilə işləyən serverlər üçün qeyd lisenziyaları tələb olunur, yəni. Qeydiyyat lisenziyası tələb olunur və Recorder ilə işləyən serverə deyil, CallBridge komponentinə tətbiq edilməlidir. Qeydiyyatçı özünü Genişləndirilə bilən Mesajlaşma və Mövcudluq Protokolu (XMPP) müştərisi kimi aparır, ona görə də XMPP serveri CallBridge-i yerləşdirən serverdə aktivləşdirilməlidir.

Çünki bizim klasterimiz var və lisenziyanın hər üç klaster serverinə “uzanması” lazımdır. Sonra sadəcə olaraq lisenziyalardakı şəxsi hesabda klasterə daxil olan bütün CMS serverlərinin a-interfeyslərinin MAC ünvanlarını əlaqələndiririk (əlavə edirik).

Və bu şəkil hər bir klaster serverində olmalıdır

Ümumiyyətlə, Recorder yerləşdirmək üçün bir neçə ssenari var, lakin biz buna sadiq qalacağıq:


Recorder quraşdırmadan əvvəl, həqiqətən video konfransların yazılacağı yer hazırlamalısınız. Əslində burada əlaqəbütün qeydi necə qurmaq olar. Mən vacib məqamlara və detallara diqqət yetirəcəyəm:

1. Sertifikatı klasterdəki ilk serverdən çıxarmaq daha yaxşıdır.
2. Recorder Trust-da səhv sertifikat göstərildiyi üçün "Recorder unavailable" xətası baş verə bilər.
3. Göstərilən yazı NFS-də kök kataloq deyilsə, yazı getməyə bilər.

Bəzən müəyyən bir istifadəçinin və ya məkanın konfransını avtomatik qeyd etməyə ehtiyac var.

Bunun üçün iki CallProfiles yaradılır:
Qeydiyyat funksiyası deaktiv edilmiş halda


Və avtomatik qeyd funksiyası ilə


Bundan əlavə, lazımi boş yerə CallProfile-ni avtomatik qeyd funksiyası ilə "bağlayırıq".


CMS-də o qədər müəyyən edilmişdir ki, əgər CallProfile bəzi boşluqlara və ya boşluqlara açıq şəkildə bağlıdırsa, bu CallProfile yalnız bu xüsusi boşluqlar üçün işləyir. Əgər CallProfile heç bir boşluğa bağlı deyilsə, defolt olaraq o, heç bir CallProfile-in açıq şəkildə bağlanmadığı boşluqlara tətbiq edilir.

Növbəti dəfə mən CMS-ə təşkilatın daxili şəbəkəsindən kənarda necə daxil olduğunu təsvir etməyə çalışacağam.

Mənbə:

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

Mənbə: www.habr.com