Cisco Meeting Server 2.5.2. Klaster w trybie skalowalnym i odpornym z funkcją nagrywania wideokonferencji

W tym odcinku pokażę i wyjaśnię niektóre niuanse konfiguracji serwera CMS w trybie klastra odpornego na awarie.


TeoriaIstnieją trzy typy wdrożenia serwera CMS:

• Single Combined(Jednolity kombinowany), czyli to jeden serwer, na którym uruchomione są wszystkie potrzebne usługi. W większości przypadków ten typ wdrożenia dotyczy jedynie dostępu wewnętrznego i w małych środowiskach, gdzie ograniczenia skalowalności i nadmiarowości jednego serwera nie stanowią krytycznego problemu, lub w sytuacjach, gdy CMS wykonuje tylko określone funkcje, takie jak specjalne konferencje na Cisco UCM.

  Przykładowy schemat działania:
  

• Single Split(Jednolity podzielony) rozszerza poprzedni typ wdrożenia, dodając oddzielny serwer dla dostępu zewnętrznego. W przestarzałych wdrożeniach oznaczało to wdrożenie serwera CMS w strefie demilitarizowanej (DMZ), gdzie klienci zewnętrzni mogli uzyskać do niego dostęp, oraz jednego serwera CMS w rdzeniu sieci, gdzie uzyskują dostęp do CMS klienci wewnętrzni. Ten konkretny model wdrożenia jest teraz wypierany przez tak zwany typ Single Edge, który składa się z serwerów Cisco Expressway, które mają lub będą miały wiele możliwości omijania zapory sieciowej, więc klienci nie muszą dodawać dedykowanego serwera brzegowego CMS.

  Przykładowy schemat działania:
  

• Scalable and Resilient(Skalowalny i odporny na awarie) ten typ zapewnia nadmiarowość dla każdego komponentu, co pozwala systemowi rosnąć wraz z Twoimi potrzebami do maksymalnej pojemności, zapewniając jednocześnie nadmiarowość w przypadku awarii. Wykorzystuje również koncepcję Single Edge, aby zapewnić bezpieczny dostęp zewnętrzny. To typ, który omówimy w tym odcinku. Jeśli zrozumiemy, jak wdrożyć klaster tego typu, zrozumiemy nie tylko inne typy wdrożeń, ale także będziemy mogli zrozumieć, jak tworzyć klastry serwerów CMS z uwzględnieniem potencjalnego wzrostu potrzeb.

Zanim przejdziemy do wdrożenia, musimy zrozumieć kilka podstawowych rzeczy, a mianowicie

Podstawowe komponenty oprogramowania CMS:

• Baza danych: pozwala łączyć niektóre konfiguracje, takie jak grupy abonentów, przestrzenie dla użytkowników i samych użytkowników. Obsługuje klastrowanie tylko dla wysokiej dostępności (jeden główny).
• Call Bridge: to usługa do konferencji audio- i wideo, która zapewnia pełną kontrolę nad zarządzaniem oraz przetwarzaniem połączeń i procesami multimedialnymi. Obsługuje klasteryzację dla wysokiej dostępności i skalowalności.
• serwer XMPP: odpowiada za rejestrację i uwierzytelnianie klientów korzystających z aplikacji Cisco Meeting Application i/lub WebRTC (komunikacji w czasie rzeczywistym, czyli po prostu w przeglądarce), a także międzykomponentową sygnalizację. Może być klasteryzowany tylko w celu zapewnienia wysokiej dostępności.
• Web Bridge: zapewnia dostęp klientów w WebRTC.
• Loadbalancer: zapewnia jedyną punktu połączenia dla aplikacji Cisco Meeting App w trybie Single Split. Nasłuchuje na zewnętrznym interfejsie i porcie dla przychodzących połączeń. Równocześnie, balansujący obciążenie akceptuje przychodzące połączenia TLS z serwera XMPP, przez które może przełączać połączenia TCP od zewnętrznych klientów.
  W naszym scenariuszu nie będzie to potrzebne.
• serwer TURN: zapewnia technologię omijania zapory sieciowej (Firewall), która pozwala
  na umiejscowienie naszego CMS za zaporą sieciową lub NAT-em dla połączenia z zewnętrznymi klientami korzystającymi z aplikacji Cisco Meeting App lub urządzeń SIP. W naszym scenariuszu nie będzie to potrzebne.
• Web Admin: interfejs administracyjny oraz dostęp do API, w tym dla specjalnych konferencji Unified CM.

Tryby konfiguracji

W przeciwieństwie do większości innych produktów Cisco, Cisco Meeting Server obsługuje trzy metody konfiguracji, umożliwiające wdrożenie dowolnego rodzaju rozwiązań.

• Interfejs wiersza poleceń (CLI): interfejs wiersza poleceń, znany jako MMP, do wstępnej konfiguracji i certyfikatów.
• Web Administrator: głównie do konfiguracji związanej z CallBridge, szczególnie podczas konfiguracji jednego serwera nieklasteryzowanego.
• REST API: stosowany do najtrudniejszych zadań konfiguracyjnych oraz zadań związanych z bazą danych klasterową.

Oprócz powyższego, używany jest protokół SFTP do przesyłania plików – zazwyczaj licencji, certyfikatów lub dzienników – do i z serwera CMS.

W przewodnikach wdrożeniowych od Cisco czarno na białym jest napisane, że klaster należy wdrożyć min. z trzech serwerów (węzłów) w kontekście baz danych. Ponieważ tylko przy nieparzystej liczbie węzłów uruchomi się mechanizm wyboru nowego Mistrza bazy danych, a w ogóle Mistrz bazy danych ma połączenie z większością bazy danych CMS serwera.

Jak pokazuje praktyka, dwóch serwerów (węzłów) naprawdę nie wystarcza. Mechanizm wyboru działa podczas ponownego uruchamiania serwera Master; serwer Slave staje się Masterem wyłącznie po uruchomieniu ponownie serwera. Jeśli jednak w klastrze z dwóch serwerów serwer Master nagle „zgaśnie”, to serwer Slave nie stanie się Masterem, a jeśli zgaśnie serwer Slave, to pozostały serwer Master stanie się Slave'em.

W kontekście XMPP naprawdę warto byłoby zbudować klaster z trzech serwerów, ponieważ, na przykład, wyłączenie usługi XMPP na jednym z serwerów, na którym XMPP jest w statusie Lidera, sprawi, że na pozostałym serwerze XMPP pozostanie w statusie Obserwatora, a połączenie CallBridge z XMPP zostaną zerwane, ponieważ CallBridge łączy się wyłącznie z XMPP w statusie Lidera. Jest to krytyczne, ponieważ żadne połączenie nie przejdzie.

W tych samych przewodnikach wdrażania pokazany jest klaster z jednym serwerem XMPP.

Biorąc pod uwagę powyższe, staje się jasne, dlaczego: działa w trybie przełączania awaryjnego.

W naszym przypadku serwer XMPP będzie obecny na wszystkich trzech węzłach.

Zakłada się, że wszystkie trzy nasze serwery są uruchomione.

Rekordy DNS

Zanim zaczniemy konfigurować serwery, musimy utworzyć rekordy DNS. A i SRV rodzaje:

Zauważ, że w naszych rekordach DNS występują dwie domeny example.com oraz conf.example.com. Example.com jest domeną, z której mogą korzystać wszyscy abonenci Cisco Unified Communication Managera, który najprawdopodobniej znajduje się w twojej infrastrukturze lub z dużym prawdopodobieństwem tam będzie. Albo domena example.com odpowiada domenie, której użytkownicy używają dla swoich adresów e-mail. Może klient Jabber na twoim laptopie mieć URI user@example.com. Domena conf.example.com — to domena, która będzie skonfigurowana dla użytkowników Cisco Meeting Servera. Domena Cisco Meeting Servera to conf.example.com, dlatego dla tego samego użytkownika Jabber do zalogowania się do Cisco Meeting Servera będzie trzeba użyć URI user@conf.example.com.

Podstawowa konfiguracja

Wszystkie poniżej opisane ustawienia pokazano na jednym serwerze, ale należy je przeprowadzić na każdym serwerze klastra.

QoS

Ponieważ CMS generuje streaming). Dlatego potrzebny jest inny scenariusz wstawiania, a same zapytania — z pewną specyfiką. Ruch wrażliwy na opóźnienia i utraty pakietów w większości przypadków zaleca się skonfigurować jakość usług (QoS). W tym celu CMS obsługuje oznaczanie pakietów kodami zróżnicowanych usług (DSCP), które generuje. Chociaż priorytetyzacja ruchu na podstawie DSCP zależy od tego, w jaki sposób ruch jest przetwarzany przez komponenty sieciowe Twojej infrastruktury, w naszym przypadku skonfigurujemy nasz CMS z typowym przydziałem priorytetów DSCP na podstawie najlepszych praktyk QoS.

Na każdym serwerze wprowadźmy te polecenia

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

W ten sposób cały ruch wideo był oznaczony AF41 (DSCP 0x22), cały ruch głosowy oznaczony EF (DSCP 0x2E), a inne rodzaje ruchu o niskich opóźnieniach, takie jak SIP i XMPP, korzystają z AF31 (DSCP 0x1A).

Sprawdzamy:

NTP

Protokół czasowy sieci (NTP) jest ważny nie tylko dla zapewnienia dokładnych znaczników czasowych połączeń i konferencji, ale także dla weryfikacji certyfikatów.

Dodajemy serwery NTP do naszej infrastruktury poleceniem w postaci

ntp server add

W naszym przypadku takich serwerów jest dwa, więc będzie dwa polecenia.
Sprawdzamy:

I ustawiamy strefę czasową dla naszego serwera

DNS

Serwery DNS w CMS dodajemy poleceniem w postaci:

dns add forwardzone

W naszym przypadku takich serwerów jest dwa, więc będzie dwa polecenia.
Sprawdzamy:

Konfiguracja interfejsu sieciowego

Konfigurujemy interfejs poleceniem w postaci:

ipv4  add 
 /

Sprawdzamy:

Nazwa serwera (Hostname)

Nazwa serwera ustawiamy poleceniem w postaci:

hostname

I restartujemy.


Na tym podstawowa konfiguracja się kończy.

Certyfikaty

TeoriaCisco Meeting Server wymaga szyfrowanej komunikacji między różnymi komponentami, w związku z czym certyfikaty X.509 są wymagane dla wszystkich wdrożeń CMS. Pomagają one zapewnić zaufanie do usług/serwera innym serwerom/usługom.

Każda usługa wymaga certyfikatu, jednak tworzenie oddzielnych certyfikatów dla każdej usługi może prowadzić do zamieszania i niepotrzebnej złożoności. Na szczęście możemy wygenerować parę kluczy certyfikatu, a następnie ponownie je wykorzystać dla kilku usług. W naszym przypadku ten sam certyfikat będzie używany dla Call Bridge, serwera XMPP, Web Bridge i Web Admin. W ten sposób należy stworzyć parę kluczy publicznych i prywatnych dla każdego serwera w klastrze.

Klasteryzacja bazy danych ma jednak pewne szczególne wymagania dotyczące certyfikatów, dlatego wymaga swoich własnych certyfikatów, różniących się od certyfikatów innych usług. CMS wykorzystuje certyfikat serwera, który jest podobny do certyfikatów używanych przez inne serwery, ale istnieje także certyfikat klienta, który jest używany do połączeń z bazą danych. Certyfikaty bazy danych są wykorzystywane zarówno do uwierzytelniania, jak i szyfrowania. Zamiast podawać nazwę użytkownika i hasło do połączenia klienta z bazą danych, klient przedstawia certyfikat, któremu ufa serwer. Każdy serwer w klastrze bazy danych będzie używać tej samej pary kluczy publicznego i prywatnego. Pozwala to wszystkim serwerom w klastrze szyfrować dane w taki sposób, aby mogły być deszyfrowane tylko przez inne serwery, które również używają tej samej pary kluczy.

Aby replikacja działała, klastry baz danych muszą składać się z co najmniej 3 serwerów, ale nie więcej niż 5, z maksymalnym czasem przejścia sygnału w obu kierunkach wynoszącym 200 ms między dowolnymi członkami klastra. Ten limit jest bardziej restrykcyjny niż w przypadku klasteryzacji Call Bridge, dlatego często stanowi czynnik ograniczający w geograficznie rozproszonych wdrożeniach.

Rola bazy danych dla CMS ma szereg unikalnych wymagań. W przeciwieństwie do innych ról, wymaga zarówno certyfikatu klienta, jak i serwera, gdzie certyfikat klienta ma określone pole CN, które jest przedstawiane serwerowi.

CMS korzysta z bazy danych Postgres z jednym głównym i kilkoma w pełni identycznymi replikami. W każdym momencie istnieje tylko jedna główna baza danych („serwer bazy danych”). Pozostałe człony klastra są replikami lub „klientami bazy danych.”

Dla klastra bazy danych wymagane są certyfikat dedykowanego serwera oraz certyfikat klienta. Muszą one być podpisane certyfikatami, zazwyczaj wewnętrznym prywatnym centrum certyfikacji. Ponieważ każdy z członków klastra bazy danych może stać się głównym, pary certyfikatów serwera bazy danych i klienta (zawierające klucze publiczne i prywatne) powinny być skopiowane na wszystkie serwery, aby mogły zaakceptować tożsamość klienta lub serwera bazy danych. Ponadto, certyfikat główny CA musi zostać załadowany, aby zapewnić, że certyfikaty klienta i serwera mogą być weryfikowane.

Zatem formułujemy żądanie certyfikatu, które będzie używane przez wszystkie usługi serwera z wyjątkiem database (dla tego będzie osobne żądanie) komendą w postaci:

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

W CN wpisujemy ogólne nazwy naszych serwerów. Na przykład, jeżeli hostname’y naszych serwerów server01, server02, server03, to CN będzie server.example.com

To samo robimy na pozostałych dwóch serwerach, z tą różnicą, że w komendach będą odpowiednie „hostname’y”

Formułujemy dwa żądania dla certyfikatów, które będą używane przez usługę database komendami w postaci:

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

pki csr dbclusterclient CN:postgres

gdzie dbclusterserver i dbclusterclient nazwy naszych żądań i przyszłych certyfikatów, hostname1(2)(3) nazwy odpowiednich serwerów.

Tę procedurę wykonujemy tylko na jednym serwerze (!), a certyfikaty i odpowiednie pliki .key przeniesiemy na inne serwery.

Włączenie trybu certyfikatu klienta w AD CS

Jeszcze musimy połączyć w jeden plik certyfikaty dla każdego serweraW *NIX:

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

W Windows/DOS:

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

I załadować na każdy serwer:
1. „Indywidualny” certyfikat serwera.
2. Certyfikat główny (razem z pośrednimi, jeśli takie są).
3. Certyfikaty dla bazy danych („serwerowy” i „klientski”) oraz pliki z rozszerzeniem .key, które zostały wygenerowane podczas tworzenia żądania dla „serwerowego” i „klientskiego” certyfikatu bazy danych. Te pliki muszą być identyczne na wszystkich serwerach.
4. Plik wszystkich trzech „indywidualnych” certyfikatów.

W rezultacie powinna powstać mniej więcej taka struktura plików na każdym serwerze.

Klastrowa Baza Danych

Teraz, gdy wszystkie certyfikaty są załadowane na serwery CMS, możesz skonfigurować i włączyć klastrowanie bazy danych między trzema węzłami. Pierwszym krokiem jest wybranie jednego serwera jako głównego węzła klastra bazy danych i jego pełna konfiguracja.

Główna Baza Danych

Pierwszym krokiem w konfiguracji replikacji bazy danych jest wskazanie certyfikatów, które będą używane dla bazy danych. Robi się to za pomocą polecenia w postaci:

database cluster certs

Teraz wskażmy CMS, jaki interfejs użyć do klastrowania baz danych poleceniem:

database cluster localnode a

Następnie inicjalizujemy bazę danych klastra na głównym serwerze poleceniem:

database cluster initialize

Węzły Bazy Danych Klienta

Wykonujemy tę samą procedurę, tylko zamiast polecenia database cluster initialize wprowadzamy polecenie w postaci:

database cluster join

gdzie ip address existing master to adres IP serwera CMS, na którym została przeprowadzona inicjalizacja klastra, po prostu główny serwer.

Sprawdzamy, jak działa nasz klaster bazy danych na wszystkich serwerach poleceniem:

database cluster status

To samo robimy na pozostałym, trzecim serwerze.

W rezultacie okazuje się, że nasz pierwszy serwer jest Głównym, a pozostałe to Podrzędne.

Usługa Web Admin

Włączamy usługę web-administratora:

webadmin listen a 445

Port 445 został wybrany, ponieważ port 443 jest używany do dostępu użytkowników do interfejsu webowego.

Konfigurujemy usługę Web Admin z plikami certyfikatów poleceniem w postaci:

webadmin certs

I włączamy Web Admin poleceniem:

webadmin enable

Jeśli wszystko jest w porządku, otrzymamy linie SUCCESS, w których zostanie wskazane, że Web Admin jest prawidłowo skonfigurowany dla sieci i certyfikatu. Sprawdzamy działanie usługi za pomocą przeglądarki internetowej, wpisując adres web-administratora, na przykład: cms.example.com:445

Klastrowanie Call Bridge

Call Bridge jest jedyną usługą obecna w każdym wdrożeniu CMS. Call Bridge jest podstawowym mechanizmem konferencyjnym. Zapewnia również interfejs SIP, dzięki czemu połączenia mogą być routowane do niego lub z niego, na przykład z Cisco Unified CM.

Poniższe polecenia należy wykonać na każdym serwerze z odpowiednimi certyfikatami.
A zatem:

Łączymy certyfikaty z usługą Call Bridge poleceniem w postaci:

callbridge certs  []

Przypisujemy usługi CallBridge do odpowiedniego interfejsu poleceniem:

callbridge listen a

I uruchamiamy usługę poleceniem:

callbridge restart

Teraz, gdy mamy skonfigurowane mosty połączeń, możemy skonfigurować klaster mostów połączeń. Klaster mostów połączeń różni się od klasteryzacji baz danych lub XMPP. Klaster mostów połączeń może obsługiwać od 2 do 8 węzłów bez jakichkolwiek ograniczeń. Zapewnia nie tylko nadmiarowość, ale także rozkład obciążenia, dzięki czemu konferencje mogą być aktywnie rozdzielane pomiędzy serwerami mostów połączeń za pomocą inteligentnego rozdzielania połączeń. CMS ma dodatkowe funkcje, grupy mostów połączeń i związane z nimi funkcje, które można wykorzystać do dalszego zarządzania.

Klasteryzacja mostu połączeń jest skonfigurowana głównie przez interfejs webowego administratora
Poniższą procedurę należy przeprowadzić na każdym serwerze klastra.
Otóż

1. Logujemy się przez web do Configuration > Cluster.
2. W Tożsamości mostu połączeń jako unikalną nazwę wprowadzamy callbridge[01,02,03] odpowiadającą nazwie serwera. Te nazwy są dowolne, ale muszą być unikalne dla tego klastra. Mają charakter opisowy, ponieważ wskazują, że są to identyfikatory serwerów [01,02,03].
3. W Klasteryzowanych mostach połączeń wprowadzamy adresy URL webowego administratora naszych serwerów w klastrze, cms[01,02,03].example.com:445, w polu Address. Koniecznie podaj port. Możesz pozostawić pole Peer link SIP domain puste.
4. Dodajemy do zaufanie mostowi połączeń certyfikat każdego serwera, plik którego zawiera wszystkie certyfikaty naszych serwerów, które połączyliśmy w tym pliku na samym początku, poleceniem typu:

callbridge trust cluster

I uruchamiamy usługę poleceniem:

callbridge restart

W rezultacie na każdym serwerze powinna wyglądać taka sytuacja:

Klaster XMPP

Usługa XMPP w CMS jest używana do obsługi całej rejestracji i autoryzacji dla aplikacji Cisco Meeting Apps (CMA), w tym dla klienta webowego CMA WebRTC. Sam most połączeń również działa jako klient XMPP do celów autoryzacji i dlatego musi być skonfigurowany jak inne klienci. Odporność na błędy XMPP to funkcja, która jest wspierana w środowiskach produkcyjnych od wersji 2.1

Poniższe polecenia należy wykonać na każdym serwerze z odpowiednimi certyfikatami.
A zatem:

Łączymy certyfikaty ze usługą XMPP poleceniem typu:

xmpp certs  []

Następnie określamy interfejs nasłuchujący poleceniem:

xmpp listen a

Dla usługi XMPP wymagana jest unikalna domena. To jest login dla użytkowników. Innymi słowy, gdy użytkownik próbuje zalogować się za pomocą aplikacji CMA (lub przez klienta WebRTC), wpisuje userID@logindomain. W naszym przypadku będzie to userid@conf.example.com. Dlaczego to nie po prostu example.com? W naszej konkretnej instalacji wybraliśmy naszą domenę Unified CM, która będzie używana przez użytkowników Jabber w Unified CM, jako example.com, dlatego potrzebujemy innej domeny dla użytkowników CMS, aby kierować połączenia do CMS i z CMS przez domeny SIP.

Skonfiguruj domenę XMPP za pomocą polecenia w swoim rodzaju:

xmpp domain

A włączamy usługę XMPP poleceniem:

xmpp enable

W usłudze XMPP należy utworzyć dane uwierzytelniające dla każdego Call Bridge, które będą używane przy rejestracji w usłudze XMPP. Te nazwy są dowolne (i nie są związane z unikalnymi nazwami, które skonfigurowałeś do klastrowania mostów połączeń). Na jednym serwerze XMPP należy dodać trzy mosty połączeń, a następnie wprowadzić te dane uwierzytelniające na innych serwerach XMPP w klastrze, ponieważ ta konfiguracja nie trafia do bazy danych klastra. Później skonfigurujemy każdy Call Bridge, aby używał tej nazwy i hasła do rejestracji w usłudze XMPP.

Teraz musimy skonfigurować usługę XMPP na pierwszym serwerze z trzema mostami połączeń callbridge01, callbridge02 i callbridge03. Każdemu z kont zostaną przypisane losowe hasła. Później będą one wprowadzane na innych serwerach Call Bridge, aby zalogować się na tym serwerze XMPP. Wprowadzamy następujące polecenia:

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

Na koniec sprawdzamy, co się udało poleceniem:

xmpp callbridge list

Dokładnie taki sam obraz powinien być na pozostałych serwerach po działaniach opisanych poniżej.

Następnie dodajemy na pozostałych dwóch serwerach dokładnie takie same ustawienia, tylko poleceniami

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

Sekret dodajemy bardzo ostrożnie, aby przypadkowo nie wpadły do niego na przykład zbędne spacje.


W wyniku tego na każdym serwerze powinna być ta sama sytuacja:

Następnie na wszystkich serwerach klastra wskazujemy zaufany plik zawierający wszystkie trzy certyfikaty, utworzony wcześniej poleceniem w swoim rodzaju:

xmpp cluster trust

Włączamy tryb xmpp klastra na wszystkich serwerach klastra poleceniem:

xmpp cluster enable

Na pierwszym serwerze klastra inicjujemy utworzenie klastra xmpp komendą:

xmpp cluster initialize

Na pozostałych serwerach dodajemy do klastra xmpp komendą:

xmpp cluster join

Sprawdzamy na każdym serwerze skuteczność utworzenia klastra XMPP komendami:

xmpp status
xmpp cluster status

Pierwszy serwer:

Drugi serwer:

Trzeci serwer:

Podłączenie Call Bridge do XMPP

Teraz, gdy klaster XMPP jest uruchomiony, musimy skonfigurować usługi Call Bridge, aby podłączyć je do klastra XMPP. Ta konfiguracja odbywa się przez panel administracyjny.

Wchodzimy na każdym serwerze w Configuration > General i w polu Unique Call Bridge name piszemy odpowiednie unikalne nazwy Call Bridge dla każdego serwera callbridge[01,02,03]. W polu Domena conf.example.ru i odpowiednie hasła, które można sprawdzić
na dowolnym serwerze klastra komendą:

xmpp callbridge list

Pole „Serwer” pozostawiamy puste, Callbridge wykona wyszukiwanie DNS SRV dla _xmpp-component._tcp.conf.example.com, aby znaleźć dostępny serwer XMPP. Adresy IP połączeń callbridge'ów z XMPP mogą się różnić na każdym serwerze, zależy to od wartości zwracanych w odpowiedzi na zapytanie o rekord _xmpp-component._tcp.conf.example.com callbridge'a, co z kolei zależy od ustawień priorytetów dla danego rekordu DNS.

Następnie przechodzimy do Status > General, aby upewnić się, że usługa Call Bridge została pomyślnie podłączona do usługi XMPP.

Web Bridge

Na każdym serwerze klastra włączamy usługę Web Bridge komendą:

webbridge listen a:443

Konfigurujemy usługę Web Bridge z plikami certyfikatów komendą:

webbridge certs

Web Bridge wspiera HTTPS. Będzie przekierowywał HTTP na HTTPS, jeśli jest skonfigurowany do użycia „http-redirect”.
Aby włączyć przekierowanie HTTP, użyj następującej komendy:

webbridge http-redirect enable

Aby Call Bridge dał znać, że Web Bridge może ufać połączeniom z Call Bridge, użyj komendy:

webbridge trust

gdzie to jest plik zawierający wszystkie trzy certyfikaty z każdego serwera w klastrze.

Taki obraz powinien być na każdym serwerze klastra.


Teraz musimy stworzyć użytkownika z rolą „appadmin”, potrzebujemy go, aby móc konfigurować nasz klaster(!), a nie każdy serwer klastra z osobna, w ten sposób ustawienia będą stosowane jednakowo na każdym serwerze, chociaż będą dokonywane tylko raz.


Do dalszej konfiguracji będziemy używać Postman.

Do autoryzacji wybieramy Basic w sekcji Autorization

Aby prawidłowo wysłać polecenia do serwerów CMS, należy ustawić odpowiednie kodowanie.

Podajemy Webbridge’y za pomocą polecenia. POST z parametrem url i wartością cms.example.com



W samym webbridge’u wskazujemy potrzebne parametry: dostęp gościnny, dostęp chroniony i inne.

Grupy Call Bridge.

Domyślnie CMS nie zawsze maksymalnie efektywnie wykorzystuje dostępne zasoby konferencyjne.

Na przykład, podczas spotkania z trzema uczestnikami każdy uczestnik może znaleźć się na trzech różnych Call Bridge’ach. Aby ci trzej uczestnicy mogli rozmawiać ze sobą, Call Bridge’y automatycznie ustanowią połączenia między wszystkimi serwerami i klientami w tej samej przestrzeni, tak aby wyglądało to tak, jakby wszyscy klienci byli na jednym serwerze. Niestety, wadą tego rozwiązania jest to, że jedna konferencja z 3 osobami teraz wykorzysta 9 portów multimedialnych. To oczywiście jest nieefektywne wykorzystanie zasobów. Ponadto, gdy Call Bridge rzeczywiście jest obciążony, mechanizm domyślny polega na tym, aby nadal przyjmować połączenia i świadczyć usługi z obniżoną jakością dla wszystkich abonentów tego Call Bridge’a.

Te problemy są rozwiązywane dzięki funkcji Grupa Call Bridge. Funkcja ta została wprowadzona w wersji 2.1 oprogramowania Cisco Meeting Server i została rozszerzona, aby wspierać balansowanie obciążenia zarówno dla połączeń przychodzących, jak i wychodzących, oraz aplikację Cisco Meeting App (CMA), w tym uczestników WebRTC.

Aby rozwiązać problem z ponownym połączeniem, wprowadzono trzy konfigurowalne ograniczenia obciążenia dla każdego Call Bridge:

LoadLimit — to maksymalne obciążenie liczbowe dla konkretnego Call Bridge. Każda platforma ma zalecaną wartość maksymalną obciążenia, na przykład 96000 dla CMS1000 i 1,25 GHz na wirtualny procesor dla maszyny wirtualnej. Różne połączenia konsumują określoną ilość zasobów w zależności od rozdzielczości i liczby klatek uczestnika.
NewConferenceLoadLimitBasisPoints (domyślnie 50% loadLimit) — ustawia limit obciążenia serwera, po przekroczeniu którego nowe konferencje są odrzucane.
ExistingConferenceLoadLimitBasisPoints (domyślnie 80% od loadLimit) — wartość obciążenia serwera, po przekroczeniu której uczestnicy dołączający do istniejącej konferencji będą odrzucani.

Choć ta funkcja została opracowana do rozdzielania połączeń i obciążenia, inne grupy, takie jak serwery TURN, serwery Web Bridge i urządzenia rejestrujące, również mogą być przypisane do grup Call Bridge, aby mogły być prawidłowo grupowane dla optymalnego wykorzystania. Jeśli żaden z tych obiektów nie jest przypisany do grupy połączeń, zakłada się, że są one dostępne dla wszystkich serwerów bez żadnych określonych priorytetów.

Te opcje są konfigurowane tutaj: cms.example.com:445/api/v1/system/configuration/cluster

Następnie wskazujemy każdemu callbridge’owi, do jakiej grupy callbridge należy:

Pierwszy callbridge

Drugi callbridge

Trzeci callbridge


W ten sposób skonfigurowaliśmy grupę Call Bridge dla bardziej efektywnego wykorzystania zasobów klastra Cisco Meeting Server.

Importowanie użytkowników z Active Directory

Usługa Web Admin ma sekcję konfiguracji LDAP, ale nie предоставляет skomplikowanych opcji konfiguracji, a informacje nie są przechowywane w bazie danych klastra, dlatego konfigurację należy przeprowadzać ręcznie na każdym serwerze przez interfejs internetowy lub za pośrednictwem API. Aby nie wstawać trzy razy, dane zostaną wpisane przez API.

Korzystając z adresu URL do uzyskania dostępu cms01.example.com:445/api/v1/ldapServers tworzymy obiekt serwera LDAP, określając takie parametry jak:

• adres IP serwera
• numer portu
• nazwa użytkownika
• hasło
• bezpieczny

Bezpieczny — true lub false wybieramy w zależności od portu, 389 — niezabezpieczony, 636 — zabezpieczony.


Mapowanie parametrów źródła LDAP na atrybuty w Cisco Meeting Server.
Mapowanie LDAP przypisuje atrybuty w katalogu LDAP do atrybutów w CMS. Właściwe atrybuty to:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Opis atrybutówJID reprezentuje identyfikator logowania użytkownika w CMS. Ponieważ jest to serwer LDAP Microsoft Active Directory, JID CMS jest przypisywane do sAMAccountName w LDAP, który zasadniczo jest identyfikatorem logowania użytkownika w Active Directory. Zwróć również uwagę, że bierzesz sAMAccountName i dodajesz do niego domenę conf.pod6.cms.lab, ponieważ to jest login, którego Twoi użytkownicy będą używać do logowania się w CMS.

nameMapping przypisuje to, co znajduje się w polu displayName Active Directory, do pola imienia użytkownika CMS.

coSpaceNameMapping tworzy nazwę przestrzeni CMS na podstawie pola displayName. Ten atrybut wraz z atrybutem coSpaceUriMapping są wymagane do utworzenia przestrzeni dla każdego użytkownika.

coSpaceUriMapping określa użytkownikową część URI związaną z osobistą przestrzenią użytkownika. Niektóre domeny mogą być skonfigurowane dla zestawu w przestrzeni. Jeśli użytkownikowa część pokrywa się z tym polem dla jednej z tych domen, wywołanie zostanie skierowane do tej przestrzeni użytkownika.

coSpaceSecondaryUriMapping określa drugi URI, aby dotrzeć do przestrzeni. Może to być wykorzystane do dodania numerycznego pseudonimu do routingu wywołań w przestrzeni zaimportowanego użytkownika jako alternatywy dla alfanumerycznego URI określonego w parametrze coSpaceUriMapping.

Serwer LDAP i mapowanie LDAP zostały skonfigurowane. Teraz należy połączyć je razem, tworząc źródło LDAP.

Korzystając z adresu URL do uzyskania dostępu cms01.example.com:445/api/v1/ldapSource tworzymy obiekt LDAP Source, podając takie parametry, jak:

• server
• mapping
• baseDn
• filter

Teraz, gdy konfiguracja LDAP została zakończona, można wykonać operację ręcznej synchronizacji.

Robimy to albo w interfejsie Web każdego serwera, naciskając Sync now w sekcji Active Directory


albo przez API, używając polecenia POST używając adresu URL, aby uzyskać dostęp cms01.example.com:445/api/v1/ldapSyncs

Konferencje Ad-Hoc

Co to jest?W tradycyjnym rozumieniu konferencja to sytuacja, gdy dwóch uczestników rozmawia ze sobą, a jeden z uczestników (korzystający z urządzenia zarejestrowanego w Unified CM) naciska przycisk „Konferencja”, dzwoni do drugiej osoby, a po rozmowie z tą trzecią stroną ponownie naciska przycisk „Konferencja”, aby dołączyć do wszystkich uczestników konferencji trójstronnej.

Konferencję Ad-Hoc od planowanej konferencji w CMS odróżnia fakt, że konferencja Ad-Hoc to nie tylko wywołanie SIP do CMS. Gdy inicjator konferencji ponownie naciska przycisk „Konferencja”, aby zaprosić wszystkich do tej samej sesji, Unified CM musi wykonać wywołanie API do CMS, aby stworzyć konferencję „w locie”, do której następnie przekazywane są wszystkie wywołania. Całość odbywa się w sposób niewidoczny dla uczestników.

Oznacza to, że Unified CM musi skonfigurować dane logowania do API oraz adres / port WebAdmin usługi, a także SIP-Trunk bezpośrednio na serwerze CMS, aby kontynuować wywołanie.

W razie potrzeby CUCM może dynamicznie tworzyć przestrzeń w CMS, aby każde wywołanie mogło dotrzeć do CMS i odpowiadać zasadzie przychodzących wywołań, która jest przeznaczona dla przestrzeni.

Integracja z CUCM jest konfigurowana w taki sam sposób, jak opisano w artykule wcześniej Z wyjątkiem tego, że na Cisco UCM należy utworzyć trzy trunki dla CMS, trzy Conference Bridge’y, w profilu bezpieczeństwa SIP wskazać trzy Subject Name’y, Route Group, Route List, Media Resource Group i Media Resource Group List, a w Cisco Meeting Server nieco dodać reguł routingu.

Profil bezpieczeństwa SIP:


Trunki:


Każdy trunk wygląda identycznie:




Conference Bridge


Każdy Conference Bridge wygląda identycznie:


Route Group


Route List


Media Resource Group


Media Resource Group List

Reguły połączeń

W przeciwieństwie do bardziej zaawansowanych systemów zarządzania połączeniami, takich jak Unified CM czy Expressway, CMS przegląda domenę tylko w polu SIP Request-URI dla nowych połączeń. Zatem, jeśli SIP INVITE jest przeznaczony dla sip: user@domain.com, CMS zajmuje się tylko domain.com. CMS kieruje się tymi zasadami przy określaniu, dokąd wysłać połączenie:

1. Najpierw CMS stara się dopasować domenę SIP do domen skonfigurowanych w regułach obsługi przychodzących połączeń. Następnie te połączenia mogą być kierowane do ('docelowych') obszarów lub konkretnych użytkowników, wewnętrznego IVR lub bezpośrednio zintegrowanych odbiorców Microsoft Lync/Skype dla biznesu (S4B).
2. Jeśli w regułach obsługi przychodzących połączeń nie ma dopasowań, CMS spróbuje dopasować domenę skonfigurowaną w tabeli przekierowania połączeń. Jeśli dopasowanie zostanie ustalone, reguła może wyraźnie odrzucić połączenie lub je przekierować. W tym czasie CMS może przepisać domenę, co czasami jest przydatne dla połączeń do domen Lync. Można również wybrać pass through, co oznacza, że żadne z pól nie zostanie dodatkowo zmienione, lub użyć wewnętrznej grupy abonentów CMS. Jeśli w regułach przekierowania połączeń nie ma dopasowań, domyślnie stosowane jest odrzucenie połączenia. Pamiętaj, że w CMS, chociaż połączenie jest 'przekierowane', multimedia nadal są związane z CMS, co oznacza, że będą znajdują się na ścieżce sygnalizacji i ruchu multimedialnego.
Wtedy tylko przekierowane połączenia są podległe regułom wychodzącym. Te opcje określają odbiorców, do których wysyłać połączenia, typ łącza (czy to nowe połączenie Lync, czy standardowe SIP) oraz wszelkie transformacje, które mogą być wykonane, jeśli w regule przekierowania połączenia nie wybrano przekazywania.

Oto właściwie dziennik tego, co dzieje się podczas konferencji Ad-Hoc

Na zrzucie ekranu widać źle (nie wiem jak to zrobić lepiej), więc napiszę dziennik tak:

Info	127.0.0.1:35870: Użytkownik API "api" utworzył nową przestrzeń 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	wywołanie utworzenia nie powiodło się, nie znaleziono coSpace -- próba pobrania z bazy danych

Info	API "001036270012" GUID przestrzeni: 7986bb6c-af4e-488d-9190-a75f16844e44  GUID wywołania: 93bfb890-646c-4364-8795-9587bfdc55ba  GUID korelatora wywołań: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66  Wewnętrzny G

Info	127.0.0.1:35872: Użytkownik API "api" utworzył nowe wywołanie 93bfb890-646c-4364-8795-9587bfdc55ba

Info	wywołanie 7: przychodzące wywołanie SIP od "sip:672@172.x.x.x" do lokalnego URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	API noga wywołania bc0be45e-ce8f-411c-be04-594e0220c38e w wywołaniu 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API wywołanie 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	konferencja 434f88d0-8441-41e1-b6ee-6d1c63b5b098 ma kontrolę/medium GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	konferencja 434f88d0-8441-41e1-b6ee-6d1c63b5b098 nazwana "001036270012"

Info	wywołanie 7: skonfigurowane - API noga wywołania bc0be45e-ce8f-411c-be04-594e0220c38e z identyfikatorem wywołania SIP "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"

Info	wywołanie 7: konfigurowanie sesji UDT RTP dla DTLS (połączone medium i kontrola)
Info	konferencja "001036270012": niezaszyfrowane nogi wywołania są teraz obecne

Info	uczestnik "672@172.x.x.x" dołączył do przestrzeni 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	uczestnik "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) dołączył do konferencji 434f88d0-8441-41e1-b6ee-6d1c63b5b098 za pośrednictwem SIP

Info	wywołanie 8: przychodzące wywołanie SIP od "sip:690@172.x.x.x" do lokalnego URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	API noga wywołania db61b242-1c6f-49bd-8339-091f62f5777a w wywołaniu 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API wywołanie 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	wywołanie 8: skonfigurowane - API noga wywołania db61b242-1c6f-49bd-8339-091f62f5777a z identyfikatorem wywołania SIP "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"

Info	wywołanie 8: konfigurowanie sesji UDT RTP dla DTLS (połączone medium i kontrola)

Info	wywołanie 9: przychodzące wywołanie SIP od "sip:673@172.x.x.x" do lokalnego URI "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"

Info	API noga wywołania 37a6e86d-d457-47cf-be24-1dbe20ccf98a w wywołaniu 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API wywołanie 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	wywołanie 9: skonfigurowane - API noga wywołania 37a6e86d-d457-47cf-be24-1dbe20ccf98a z identyfikatorem wywołania SIP "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"

Info	wywołanie 9: konfigurowanie sesji UDT RTP dla DTLS (połączone medium i kontrola)
Info	wywołanie 8: kompensacja za niezgodność typów payload po stronie odbiorcy

Info	uczestnik "690@172.x.x.x" dołączył do przestrzeni 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	uczestnik "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) dołączył do konferencji 434f88d0-8441-41e1-b6ee-6d1c63b5b098 za pośrednictwem SIP

Info	wywołanie 7: kompensacja za niezgodność typów payload po stronie odbiorcy
Info	wywołanie 8: tryb niezgodności typów payload 1/0
Info	wywołanie 8: odpowiadanie na ofertę w trybie niezgodności typów payload
Info	wywołanie 8: otrzymano pojedynczą ofertę kodeka
Info	wywołanie 8: tryb niezgodności typów payload 1/0
Info	wywołanie 8: odpowiadanie na ofertę w trybie niezgodności typów payload
Info	wywołanie 8: wysyłanie odpowiedzi na dodatkową ofertę pojedynczego kodeka
Info	wywołanie 9: kompensacja za niezgodność typów payload po stronie odbiorcy

Info	uczestnik "673@172.x.x.x" dołączył do przestrzeni 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	uczestnik "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) dołączył do konferencji 434f88d0-8441-41e1-b6ee-6d1c63b5b098 za pośrednictwem SIP

Info	wywołanie 9: BFCP (rola klienta) teraz aktywne
Info	wywołanie 9: wysyłanie powitania BFCP jako klienta po otrzymaniu powitania, gdy BFCP nie było aktywne
Info	wywołanie 9: BFCP (rola klienta) teraz aktywne
Info	wywołanie 7: kończenie; zdalne zakończenie SIP - połączenie trwało 0:13
Info	wywołanie 7: niszczenie nogi wywołania API bc0be45e-ce8f-411c-be04-594e0220c38e

Info	uczestnik "672@x.x.x" opuścił przestrzeń 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	wywołanie 9: wstrzymane
Info	wywołanie 9: tryb niezgodności typów payload 1/0
Info	wywołanie 9: odpowiadanie na ofertę w trybie niezgodności typów payload
Info	wywołanie 8: wstrzymane
Info	wywołanie 8: otrzymano pojedynczą ofertę kodeka
Info	wywołanie 8: tryb niezgodności typów payload 1/0
Info	wywołanie 8: odpowiadanie na ofertę w trybie niezgodności typów payload
Info	wywołanie 8: wysyłanie odpowiedzi na dodatkową ofertę pojedynczego kodeka
Info	wywołanie 9: kończenie; zdalne zakończenie SIP - połączenie trwało 0:12

Konferencja Ad-Hoc:


Zasady połączeń przychodzących
Ustawienia parametrów połączeń przychodzących są konieczne, aby umożliwić odbieranie połączeń w CMS. Jak widzieliście w ustawieniach LDAP, wszyscy użytkownicy zostali zaimportowani z domeną conf.pod6.cms.lab. Dlatego przynajmniej chcecie, aby połączenia do tej domeny były przeznaczone dla przestrzeni. Będziecie również musieli ustawić zasady dla wszystkiego, co jest przeznaczone dla pełnej nazwy domeny (i być może nawet dla adresu IP) każdego z serwerów CMS. W naszym zewnętrznym kontrolerze połączeń, Unified CM, zostaną skonfigurowane magistrale SIP, przeznaczone dla każdego z serwerów CMS indywidualnie. W zależności od tego, czy przeznaczenie tych magistrali SIP jest adresem IP, czy pełną nazwą domeny serwera, określi, czy trzeba skonfigurować CMS do odbierania połączeń skierowanych na jego adres IP lub pełną nazwę domeny.

Domena mająca zasadę ruchu przychodzącego o najwyższym priorytecie jest używana jako domena dla wszelkich przestrzeni użytkowników. Gdy użytkownicy synchronizują się przez LDAP, CMS automatycznie tworzy przestrzenie, ale tylko na podstawie części użytkownika URI (coSpaceUriMapping), na przykład user.space. Część domena pełnego URI jest tworzona na podstawie tej zasady. Faktycznie, gdybyście zalogowali się do Web Bridge na tym etapie, zobaczylibyście, że przestrzeń URI nie ma domeny. Ustawiając tę zasadę jako najwyższy priorytet, definiujecie domenę dla generowanych przestrzeni jako conf.example.com.


Zasady połączeń wychodzących

Aby umożliwić użytkownikom wykonywanie połączeń wychodzących w klastrze Unified CM, należy skonfigurować zasady połączeń wychodzących. Domeną punktów końcowych zarejestrowanych w Unified CM, takich jak Jabber, jest example.com. Połączenia do tej domeny powinny być kierowane jako standardowe połączenia SIP do węzłów przetwarzania połączeń Unified CM. Jako główny występuje serwer cucm-01.example.com, a jako dodatkowy cucm-02.example.com.

Pierwsza zasada opisuje najprostsze routowanie połączeń między serwerami klastra.

Pole Local from domain odpowiada za to, co będzie wyświetlane w SIP-URI dzwoniącego u tego, do kogo dzwonią, po symbolu „@”. Jeśli go pozostawimy pustym, to po symbolu „@” będzie adres IP CUCM’a, przez który przechodzi to połączenie. Jeśli jednak podamy domenę, to po symbolu „@” pojawi się ta domena. To jest potrzebne, aby była możliwość oddzwonienia, w przeciwnym razie dodzwonienie się z powrotem przez SIP-URI imię@adres-IP nie będzie możliwe.

Połączenie, kiedy jest podane Local from domain


Połączenie, kiedy NIE jest Local from domain


Obowiązkowo wyraźnie określ Encrypted lub Unencrypted dla połączeń wychodzących, dlatego przy parametrze Auto nic nie działa.

Nagrywanie

Nagranie wideokonferencji jest prowadzone przez serwer Record. Recorder jest dokładnie takim samym Cisco Meeting Server. Recorder nie wymaga instalowania na sobie żadnych licencji. Licencje na nagranie są wymagane dla serwerów, na których uruchomione są usługi CallBridge, tzn. licencja Recording jest konieczna i powinna być odnoszona do komponentu CallBridge, a nie do serwera, na którym uruchomiony jest Recorder. Recorder zachowuje się jak klient rozszerzonego protokołu wymiany wiadomości i obecności (XMPP), dlatego serwer XMPP musi być włączony na serwerze, na którym stacjonuje CallBridge.

Ponieważ mamy klaster i licencję należy „rozciągnąć” na wszystkie trzy serwery klastra. Tak więc po prostu w panelu użytkownika w licencjach kojarzymy (dodajemy) adresy MAC interfejsów a wszystkich serwerów CMS wchodzących w skład klastra.

I taka scena powinna być na każdym serwerze klastra

Właściwie jest kilka scenariuszy umiejscowienia Recorder’a, ale będziemy się trzymać następującego:


Zanim skonfigurujesz Recorder, musisz przygotować miejsce, w którym będą zapisywane wideokonferencje. Oto to link, jak skonfigurować całe Recording. Skupię się na ważnych punktach i detalach:

1. Lepiej podsunąć certyfikat z pierwszego serwera w klastrze.
2. Błąd „Recorder unavailable” może wystąpić, ponieważ podany certyfikat w Recorder Trust jest błędny.
3. Nagrywanie może nie działać, jeśli dla nagrania wskazany nie został katalog główny w NFS.

Czasami zachodzi potrzeba automatycznego nagrywania konferencji jednego konkretnego użytkownika lub space’a.

W tym celu tworzy się dwa CallProfile’y:
Z wyłączoną funkcją nagrywania


I z automatyczną funkcją nagrywania


Następnie do odpowiedniego space’u „przyczepiamy” CallProfile z automatyczną funkcją nagrywania.


W CMS przyjęto, że jeśli CallProfile jest wyraźnie powiązany z jakimiś space'ami lub space'em, to działa on tylko w odniesieniu do tych konkretnych space'ów. A jeśli CallProfile nie jest powiązany z żadnym space'em, to domyślnie stosuje się do tych space'ów, do których wyraźnie nie jest przypisany żaden CallProfile.

Następnym razem postaram się opisać, w jaki sposób uzyskuje się dostęp do CMS poza wewnętrzną siecią organizacji.

Źródła:

• 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

Źródło: habr.com