Cisco Expressway 12.5.5. Видеоконференцсвязь вне офиса без использования VPN

  • Tutorial
Пришло время сделать так чтобы корпоративные сервисы связи были доступны вне офиса без дополнительных телодвижений со стороны пользователя вроде использования приложения Cisco Anyconnect и/или установки дополнительных VPN-туннелей.

В этом выпуске я покажу и объясню, как настроить Cisco Expressway сервера чтобы видеоконференцсвязь работала не только внутри, но и за пределами вашей организации.



Cisco Expressway обеспечивает безопасный межсетевой экран для передачи голоса и видео и поддерживает множество функций, таких как B2B вызовы и мобильный и удаленный доступ (MRA), а также возможности сервера TURN(Traversal Using Relay NAT). Таким образом, это то, что называется решением Single Edge и является предпочтительным пограничным решением Cisco для унифицированных коммуникаций и Cisco Meeting Server.

Лицензии


Серверы Cisco Expressway ставятся, как Core(Expressway-C) и Edge(Expressway-E). При установке с нуля они ещё не являются Expressway'ями как таковыми, они ещё пока VCS-серверы.

Для того чтобы наши свежеустановленные VCS-сервера стали Expressway'ями каждому нужно установить нужные лицензии.

На каждый сервер, независимо будет он Edge или Core требуется лицензия LIC-SW-EXP-K9 или проще говоря Release key.

Чтобы VCS-сервер стал Expressway'ем Core требуются лицензии:

  • LIC-EXP-GW
  • LIC-EXP-SERIES

Чтобы VCS-сервер стал Expressway'ем Edge требуются лицензии:

  • LIC-EXP-GW
  • LIC-EXP-SERIES
  • LIC-EXP-E
  • LIC-EXP-TURN

Опционально можно добавить следующие лицензии:

  • LIC-EXP-MSFT-PMP
  • LIC-EXP-RMS-PMP
  • LIC-EXP-DSK
  • LIC-EXP-ROOM
  • LIC-EXP-AN

LIC-EXP-MSFT-PMP — Microsoft Interoperability Option (Для Expressway-C) нужна для взаимодействия со Skype for Business

LIC-EXP-DSK — Expressway Desktop Endpoint License (Для Expressway-C) нужна для регистрации на Expressway персональных устройств.

LIC-EXP-ROOM — Expressway ROOM License для регистрации на Expressway кодеков видеоконференцсвязи.

LIC-EXP-AN — Advanced Networking опция дополнительного сетевого интерфейса(Как для Expressway-C, так и для Expressway-Е)

LIC-EXP-RMS-PMP — Rich Media Session лицензии (Как для Expressway-C, так и для Expressway-Е)

Потребление лицензии Rich Media Session в зависимости от типа соединения:

  • Соединения от/на Expressway зарегистрированным устройствам
  • Соединения на/от Expressway Non-Registered Endpoints
  • Соединения на/от через Traversal Zone
  • Соединения на/от Cisco Cloud Service
  • Соединения на/от UCM, Conductor, CMS, или Expressway через Neighbor Zone

В моём случае предполагается, что виртуальные машины уже установлены и сетевые интерфейсы на них настроены.

Немного забегая вперед скажу, что связку Expressway-С и Expressway-E можно разворачивать по нескольким сценариям.

Относительно доменов может быть два варианта:

Single domain
Это когда, как внутри, так и снаружи вашей сети один и тот же домен example.com.

Dual domain
Это когда внутри у вас домен example.local, а снаружи example.com.

Относительно топологии рекомендуется использовать два сетевых интерфейса по каждому в одну отдельную DMZ, но это достаточно редкий случай, мы рассмотрим два других варианта:
DMZ — что это?

1. DMZ с одним интерфейсом локальной сети Expressway-E.



В это варианте есть возможность задать белый ip-адрес, который вам выдал(или выдаст) провайдер. В таком варианте в дальнейшем не потребуется настройка NAT-Reflection на вашем firewall'е, которая в свою очередь нужна для нормальной работы Cisco Meeting Server'a за пределами сети.

2. DMZ с двумя интерфейсами локальной сети Expressway-E.


Для данного функционала должна быть активирована опция Advanced Networking в ключах лицензий.


Также в обоих случаях в зависимости от вашего сценария нужно указать за NAT'ом этот ip-адрес будет смотреть в Интернет или нет.

DNS


В зависимости от того, кластер вы разворачиваете или нет, Single или Dual-Domain на внешнем и внутреннем DNS серверах нужно завести следующие записи:

Single Domain




Dual Domain




Обратите внимание, что если у Вас Dual-Domain, то на внутреннем DNS сервере требуется создать зону с внешним доменом и уже в нём создать записи выделенные красным. Делается это для того, чтобы пользователи могли логиниться в своих Cisco Jabber приложениях с одинаковым логином, как снаружи так и внутри корпоративной сети(с внешним доменом, обычно логины совпадают с адресом электронной корпоративной почты) независимо от того где они находятся внутри или снаружи корпоративной сети.

Также требуется создать домены и указать какие сервисы должны подерживаться для этого домена.

Сервисы
SIP registrations and provisioning on Expressway — Указывает, является ли Expressway доверенной для этого SIP-домена. Expressway действует как SIP-регистратор и сервер присутствия для данного домена, а также принимает запросы на регистрацию для любых SIP-клиентов, пытающихся зарегистрироваться с алиасом, который включает этот домен.

SIP registrations and provisioning on Unified CM — Указывает действует ли Expressway в качестве шлюза для CUCM для обеспечения безопасного прохождения брандмауэра и поддержки регистрации конечных устройств на CUCM.

IM and Presence Service — Указывает действует ли Expressway в качестве шлюза для IMP и поддерживает сервис мессенджинга и присутствия.

XMPP federation — Указывает, что федеративные службы XMPP будут предоставляться для этого локального домена. Проще говоря участвует ли этот домен в федерации с какими-либо другими доменами.

Обратите внимание, что если требуются статические маршруты для федеративных внешних доменов, они настраиваются на Expressway-E.


На Expressway-C нужно указать только внутренний домен, даже если используется сценарий Dual-Domain.


На Expressway-E, если используется сценарий Dual-Domain, нужно указать уже все(в моем случае их два, а может быть и больше) домены которые требуются.

Сертификаты


Серверы Expressway работают друг с другом и с остальными посредством сертификатов. Поэтому корневые и промежуточные сертификаты центров сертификации от которых получены сертификаты теми серверами которые будут работать с Expressway должны быть указаны как доверенные.

В меню Maintenance->Security->Trust CA certificate загружаем эти самые корневые и промежуточные сертификаты.

В нашем случае для Expressway-C сертификат будет выдан своим(серым) центром сертификации, который равносилен самоподписанному, а для Expressway-E сертификат будет выдан от белого центра сертификации Let's encrypt.

Эти сертификаты бесплатные, но каждые три месяца их нужно продлевать, но у Expressway есть функционал автоматического продления, об этом ниже.

Относительно бесплатного белого сертификата Let's Encrypt.

1. Проходим по ссылкам промежуточного сертификата и корневого сертификата

2. Требуется преобразовать цепочку .p7b в корневой сертификат, который примет наш Expressway, для этого для Windows 10:
Нажимаем правой кнопкой мыши на файл и выбираем Open with > Crypto Shell Extensions

Нажимаем правой кнопкой мыши на «DST Root CA X3», выбираем All Tasks, Export и Сохраняем.

Для linux конвертируем p7b формат в формат pem командой:
openssl pkcs7 -inform der -in
dstrootcax3.p7c -print_certs -out dstrootcax3.pem.


3. Копируем содержимое промежуточного сертификата в блокнот и сохраняем, например, как lets-encrypt-x3-cross-signed.pem.txt.

4. Загружаем оба сертификата в Trust CA на Expressway-E



Красным выделены корневой и промежуточный сертификаты «серого» центра сертификации.
Синим выделены корневой и промежуточный сертификаты «белого» центра сертификации Let's Encrypt.

5. Генерируем запрос на сертификат для Expressway-C.


Никаких SAN-имён для Expressway-C не требуется.

В поле Unified CM phone security profile names нужно указать Phone Security Profiles созданный в Unified CM, это требуется только для взаимодействия между Expressway-C и CUCM по TLS. В нашем сценарии это не понадобится.


6. Запрос скармливаем «серому» центру сертификации, получаем сертификат и загружаем его на Expressway-C.

7. Генерируем запрос на сертификат для Expressway-E. Точно также, как и для Expressway-C, только добавляем в SAN join.example.ru.

8. Нажимаем Deploy Pending Cert.

9. В итоге, если всё сделано правильно, будет вот такая картина.



Однако, в версии 12.5.6 при работе кластера с этим делом BUG.

В описание бага также описано и решении и по его обходу, пофиксят в 12.5.7 версии.

Зоны


Зона – это абстрактный набор чего угодно (доменов, ip-адресов, устройств, сервисов), к которым применим определенный набор правил. Зоны нужны для управления пропускной способностью, аутентификацией и маршрутизацией звонков, и это применяется сразу ко всему, что есть в зоне. Создавая Dial-plan'ы необходимо указать из какой зоны в какую передать звонок (а не в какой домен).

Существует несколько типов зон.

  • Neighbor — нужна, например, для связи с CMS, CUCM или другим Expressway-C.
  • Localzone — зона в которую входят устройства зарегистрированные на Expressway'ях.
  • ENUM — для E.164-запросов.
  • DNS — для DNS-запросов.
  • Webex — нужна для сценариев, в которых вызовы, инициированные в корпоративной сети, через сеть компании поступают в Интернет, а затем в облако. Аналогично через Интернет происходит маршрутизация вызовов, инициированных в Webex во время совещания, которые в дальнейшем поступают в локальную систему маршрутизации.
  • Traversal(Client, Server) — нужна для маршрутизации вызовов между Expressway-C и Expressway-E для обхода Firewall'a(отсюда и слово traversal(обходная)).
  • UC Traversal — нужна вывода во внешний мир Jabber'a со всем его функционалом.
  • Default — то, что не попало ни в одну зону, попадает в Default-зону, и работает согласно правилам Default-зоны, которую, вообще говоря, можно не заполнять правилами, и всё будет просто отклоняться.

Итак создаём Neighbor зоны для CUCM и Cisco Meeting Server'a на Expressway-C.

Зона для CUCM


Для каждого CUCM-сервера в кластере publisher'a и subscriber'a(ов) создаётся отдельная зона. Если создать одну зону и указать все сервера в полях address, то звонки будут проходить каждые 1/n раз, где n — количество серверов в кластере CUCM. Тоже самое и с зонами для CMS.

В нашем случае сервера всего два.

Первая зона:



Вторая зона:




Также требуется создать SIP Trunk Security Profile и Trunk c CUCM до Expressway.

SIP Trunk Security Profile



Обратите внимение, что мы здесь указываем порт 5065, иначе работать ничего не будет, по какой причине так сделано, мне пока узнать не удалось.

Trunk



Обратите внимание, что мы здесь указываем порт 5060, если мы укажем порт 5065 всё работать будет, но транк в статусе Full Services не будет, статус будет Unknown. Также требуется указать нужный CSS(это в зависимости от вашей конфигурации), созданный нами ранее SIP Trunk Security Profile и Standart SIP Profile For Cisco VCS в качестве SIP Profile.

Зона для CMS


Если сервер один и никакого кластера не подразумевается, то достаточно Zone Profile оставить в значении Default.



Если у вас кластер, то в полях address нужно указать FQDN каждого сервера, входящего в кластер и поставить параметр Meeting Server load balancing в состояние ON.





Зона UC Traversal на Expressway-C


В моём случае никаких H.323 протоколов не используется, поэтому создаём именно UC Traversal зону, а не просто Traversal.

На Expressway-C в зоне UC Traversal настраивается клиентское подключение, т.к.
относительно нашего обходного для Firewall'a туннеля, который строится между Expressway-C и Expressway-E, Expressway-C выступает клиентом и устанавливает туннель из внутренней сети к Expressway-E, который находится в сети DMZ, чтобы сигнализация могла проходить через корпоративный Firewall в обоих направлениях. И поэтому мы должны указать логин и пароль, который мы создадим на Expressway-E, на котором настраивается серверная часть UC Traversal зоны.



В итоге на Expressway-C должна быть примерно такая картина.



Соседские зоны(а также правила для этих зон) CEtcp… создаются автоматически, если явно задать CUCM в Expressway-C(Configuration---Unified Communications---Unified CM servers)



Также в CUCM версии 12.5, автоматически появится Expressway.






Зона UC Traversal на Expressway-E


Expressway-E обычно находится в демилитаризованной зоне и имеет интерфейс, к которому можно напрямую подключиться из Интернета (некоторых случаях этот адрес интерфейса находится за NAT'ом). Большинство политик Firewall'ов не разрешают подключения из DMZ во внутреннюю сеть. Однако большинство политик Firewall'ов позволяют подключаться из внутренней сети к сети DMZ и Интернету. Expressway-E настроен, как сервер обхода, где он может принимать соединения, инициированные от клиентов обхода firewall'a, таких как Expressway-C, которые находятся во внутренней сети. Это соединение затем используется для двунаправленной связи, позволяя отправлять сообщения с Expressway-E на Expressway-C.

Для работы обходного соединения на Expressway-E должен быть пользователь, которого позже будет использовать Expressway-C для аутентификации. Назовём его uctraversal.





Настраиваем UC Traversal Zone'у.



DNS Зона


Зона DNS сначала выполняет различные поиски DNS SRV-записей, пытаясь найти место назначения для вызываемого домена. Для SIP он ищет _sips._tcp. домен и/или _sip.tcp. домен в зависимости от настроек безопасности и шифрования. Если какой-либо из этих поисков SRV-записи дает сбой, Expressway можно настроить так, чтобы он также выполнял стандартные запросы записи A, чтобы найти пункт назначения звонка. Эти поиски позволяют Expressway направлять звонки в пункты назначения, которые не определены явно. Можно просто зарегистрировать эти записи DNS SRV на публичном DNS-сервере, а затем автоматически получать вызовы от внешних клиентов и/или звонить им, если у них сделано тоже самое. Это часто называют открытой федерацией или Business-to-Business(B2B) звонками.



TURN


TURN расшифровывается как Traversal Using Relays around NAT. По сути, это устройство, которое находится в публичном доступе в Интернете и отправляет и получает мультимедиа. Для правильного функционирования он должен быть доступен, как внешним устройствам в Интернете, так и внутренним устройствам, таким как CMS, чтобы аудио и видео трафик мог поступать и выходить из организации. Сервер TURN в этом случае действует, как точка привязки для носителя, которому доверяет межсетевой экран.

К слову, CMS может быть развернут в качестве пограничного устройства и функционировать в качестве сервера TURN, но, поскольку Expressway-E также имеет возможности сервера TURN, то лучше настраивать его на Expressway, а не плодить лишние сервера CMS или настраивать лишний функционал, тем самым повысив нагрузку на CMS сервере… Независимо от того, какое устройство используется в качестве сервера TURN для привязки мультимедиа, сервер TURN должен быть настроен в базе данных CMS, чтобы Call Bridge'ы знали, куда отправлять мультимедиа, и, поскольку сервер TURN находится в публичном доступе Интернете, веб-клиент может знать куда отправлять свой трафик. Expressway-E, действующий в качестве сервера TURN, будет соединять трафик, полученный на его внутренних и внешних интерфейсах, так, чтобы пользователи могли устанавливать двустороннюю связь.

Для любого устройства для использования сервера TURN требуется аутентификация. Требуется настроить набор учетных данных аутентификации на Expressway-E, чтобы использовать для его для функционала TURN.

Создаём учетку «Traversal...»





Включаем TURN на Expressway-E.



TURN на Cisco Meeting Server

Если никакого кластера нет, то достаточно указать в Web-интерфейса CMS адреса TURN CMA и TURN CMS.



Порт 5222 или порт 5223
В поле ServerAddress вообще лучше указать защищенный 5223 порт, однако, в данном случае я указал порт 5222 из-за того, что к CMS я прикрутил wild-сертификат, а в нём, как известно в CN и SAN указываются только домен и "*.домен".






поэтому фактический адрес web-portal'a CMS не совпадает с CN и SAN в сертификате, поэтому 5223 порт указать невозможно, а возможно 5222.

TURN CMS(serverAddress) — IP-адрес, с которого CMS должен ожидать получения трафика при подключении клиентов в конференцию.

TURN CMA(clientAddress) — IP-адрес, на который клиенты(как внутренние так и внешние) должны отправлять трафик для участия в конференции.

И TURN CMA(clientAddress) и TURN CMS(serverAddress) могут быть одним и тем же адресом, если Expressway-E имеет белый ip-адрес и ни за каким NAT'ом он не расположен. Если же Expressway-E работает за NAT'ом, таким образом TURN CMA — это белый ip-адрес в который NAT'ится Expressway. TURN CMS(serverAddress) — это ip-адрес во внутренний сети организации, который имеет Expressway-E. Для этой же цели и открывается порт 3478 между от Cisco Meeting Server'a в сторону Expressway-E.

Если же Expressway-E всё таки находится за NAT'ом, то в таком случае на Firewall'e требуется настроить так называемый NAT-Reflection. Его суть сводится к тому, что внутренние клиенты и/или устройства подключаясь в конференцию по TURN CMA(clientAddress) перенаправлялись на адрес Cisco Meeting Server'a и всё работало.

Схема работы при работе через NAT








Если же дело обстоит с кластером, то на любом из серверов CMS-кластера нужно настроить TURN с помощью Postman'a, и эти настройки автоматически применятся на остальных серверах CMS-кластера.

Создаём TURN-сервера и указываем им следующие параметры:

  • serverAddress
  • clientAddress
  • username
  • password
  • type

Про первые два параметра я уже писал. Третий и четвертый это логин и пароль от учетки, которую мы создали на Expressway-E. Последний же type это тип TURN- сервера, в нашем случае это expressway, но может быть и CMS.





Если кластер, то создаются два(в моем случае) или более TURN-серверов, их число равно числу сервреров в кластере Expressway.



В status'e мы можем посмотреть доступен ли в итоге на TURN для CMS'a и прочее, см. ниже.



Указываем CMS


Пишем join.example.com, чтобы Expressway «увидел» все сервера кластера CMS.



Далее нам требуется включить режим MRA(Mobile and Remote Access).

Включаем MRA


На Expressway-C



На Expressway-E



На Expressway-E(на всех если кластер) рекомендуется поменять порт по умолчанию с 443, на, например, 445. Если оставить его без изменений, то вместо подключения к CMS извне пользователи будут подключаться к веб-администратору Expressway-E.

Вообще чтобы всё это дело работало в Firewall'ах должны быть открыты порты. Собственно вот они.





Проверяем доступность web-портала снаружи, просто зайдя по нашему адресу join.example.com. Я допилил ещё и брэндинг, но об этом позже.



Маршрутизацию звонков можно организовать по разному.

  1. Маршрутизировать звонки на Cisco UCM.
  2. Маршрутизировать звонки на Cisco Expressway-C. (Предпочтительнее).

Разница в том, кто будет выступать в качестве центрального узла маршрутизации звонков. Вообще всё это дело можно гибко настроить с помощью приоритетов на тех же CMS и Expressway. В нашем случае будет второй вариант. См. картинку ниже. Изображение взято из Deployment guide'a, всё что с внешней стороны Firewall'a, сейчас нас не интересует.



Маршрутизация на CMS


Входящие звонки



Исходящие звонки



В качестве SIP-proxy можно указать и CUCM(в качестве первого варианта), но для этого нужно и сам CUCM настроить соответсвующим образом… Транки, SIP Route Pattern'ы, Route List'ы и прочее.

Business to Business звонки


Business to Business (B2B) звонки являются основной особенностью продукта Expressway. В2В позволяет пользователям осуществлять видеовызовы, отправлять и принимать вызовы от/к предприятий, внешних видеосервисов или клиентов через Интернет, при этом безопасным образом обходя корпоративные Firewall'ы.

В основе B2B звонков лежит возможность маршрутизации вызовов через Expressway. Хотя тоже самое можно сделать на основе домена, CUCM и большинстве других объектов управления SIP-вызовами, Expressway также имеет понятие зоны DNS. Таким образом с помощью этой зоны не нужно явно определять удаленный пункт назначения вызова. Вместо этого Expressway DNS, чтобы найти пункт назначения вызова за пределами сети организации. DNS зона у нас уже настроена.

Создаём правило поиска для входящих звонков на Expressway-E.

В моей организации требуется разрешить входящие звонки только в специально предназначенную конференцию, SIP-URI которой meeting@example.ru
Сделаем это с помощью регулярного выражения "meeting@example\.ru\.*"



Про параметры можно почитать в документации и/или подсказки в самом Expressway.
Если совсем по простому, то мы входящий SIP-звонок из DefaultZone в адресе назначения которого meeting@example.ru направляем в зону UC Traversal.

Создаём правило поиска для исходящих звонков на Expressway-E.

Сделаем это с помощью регулярного выражения "(?!.*@%localdomains%.*$).*"



Опять же, если совсем по простому, то мы входящий(именно входящий, потому что пришёл он со стороны Expressway-C, хотя для нас, как для абонентов он является исходящим) SIP-звонок из UC Traversal зоны, в адресе назначения которого что угодно, но не с локальным доменом(-ами) после @, направляем в зону DNS для успешного поиска(сопоставления значения после @ с его ip-адресом в сети Интернет) адреса назначения и успешного звонка.

Transforms

При Dual-Domain нужно преобразовать внешний домен во внутренний. Делаем это с помощью регулярного выражения "(.*)external.ru((:|;).*)?" и "1\@internal.ru"



Создаём правила поиска на Expressway-С



Регулярные выражения соответственно:

  • .*@example.ru
  • .*@example.ru
  • .*@example.ru
  • .*@(cucm-01\.|cucm-02\.)?example\.ru\.*
  • .*@(cucm-01\.|cucm-02\.)?example\.ru\.*
  • (?!.*@(cucm-01\.|cucm-02\.)?example\.ru\.*

Transforms

Также необходимо добавить трансформаций для корректной работы маршрутизации звонков.

  1. Отрезаем ":5060" порт URI звонящего.
  2. Преобразуем алиас назначения к виду URI.
  3. Заменяем IP-адрес на доменное имя при звонках с CUCM-Publisher'a.
  4. Заменяем IP-адрес на доменное имя при звонках с CUCM-Subscriber'a.



Итак проведём тестовые звонки. Позвоним в конференцию с Cisco RoomKit Mini изнутри организации и снаружи B2B-звонком с Cisco RoomKit Plus, при этом через web также в нее присоединимся.

Присоединямся через web в конференцию.






Звоним снаружи.



Звоним изнутри



В итоге конференция собралась.



К слову 1900@external.ru и 999@internal.ru зарегистрированны на своих CUCM.

Как это всё выглядело для Expressway и CMS.

Входящий звонок на Expressway-E





Детальный разбор того, что как проходил вызов через Expressway-E



Входящий звонок на Expressway-С





Детальный разбор того, что как проходил вызов через Expressway-C


Входящий звонок на CMS





Заранее прощу прощения за замазывание некоторых имён и IP-адресов, необходимость в этом есть потому, что я описываю реальную боевую настройку, которая сейчас работает, отсюда некоторые вопросы безопасности.

Источники:

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 4

    0
    В этом выпуске я покажу и объясню, как настроить

    Ваше объяснение это 6 ссылок на сайт cisco?
      0
      Да что-то криво сначала опубликовал, исправил
      0
      в ВКС-продуктах Cisco черт разберешься. Вопрос раз — по текущей идеалогии где endpoint-ы регистрировать, на vcs-c или на cucm? Вопрос два — зачем вы купили Acano и сделали CMS, если VCS-E итак умеет транскодить RDP и прочие протоколы SfB и умеет в skype-interoperability? Вопрос три — если есть CMS со своими мобильным клиентом и то что брать — jabber или cms? Вопрос четыре — зачем нужна связка VCS-C <-> VCS-E, если CMS умеет тоже самое — преодолевать фаерволл? )
        0
        Сразу говорю, что гуру в ВКС себя не считаю, но попробую ответить, поправьте меня, если я не прав.

        1. Где-то на цисковских ресурсах я читал, что конечные устройства нужно регистрировать на CUCM. Однако, различие регистрации на CUCM и Expressway заключается в том, что на Expressway конечному устройству можно присвоить видеоадрес в формате «что-угодно@домен», на CUCM же в формате «номер@ip-адрес/домен».

        2. Skype-interoperability, как я понимаю используется когда у вас в организации и SfB и CMS и друг с другом их надо подружить/интегрировать, делается это на Expressway-C, на Expressway-E это небезопасно, т.к. он в DMZ располгается.

        3. CMA и Jabber это же достаточно разные вещи, в Jabber кроме, как таковой ВКС можно же ещё и позвонить как обычным end-point'ом, и как мессенджер использовать и клиента голосовой почты и прочие плюшки, на CMA же вы просто логинитесь с учеткой CMS'a или гостем и подключаетесь в конференцию — не более.

        4. Потому что в таком случае вы ограничиваете себя только CMS'ом. Никакие Jabber'ы с его функционалом без Expressway-C и Expressway-E без VPN работать не будут, да и XMPP федерации по моему тоже установить с партнерами не получится.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое