с помощью какого приложения можно просто расшарить экран ноутбука на cisco вкс

Просмотр рабочего стола клиента во время сеанса Webex Support

Откройте инструментальную панель представителя клиентской службы, панель пиктограмм или окно работы с несколькими сеансами.

На панели пиктограмм выберите пиктограмму Удаленное управление.

Отобразится сообщение о том, что клиент получил ваш запрос. Клиент должен предоставить вам полномочие, щелкнув ОК в окне сообщения, которое появится на экране.

После предоставления клиентом полномочия на просмотр его рабочего стола, рабочий стол будет отображен в окне на вашем экране.

Просматривая рабочий стол клиента, можно передать файлы на компьютер клиента или получить их с него.

Управление рабочим столом клиента

Можно управлять рабочим столом клиента в целях оказания помощи или для предоставления рекомендаций по устранению неполадок.

Откройте инструментальную панель представителя клиентской службы, панель пиктограмм или окно работы с несколькими сеансами.

На панели пиктограмм выберите пиктограмму Удаленное управление.

Клиент должен предоставить вам полномочие, щелкнув ОК в окне сообщения, которое появится на экране.

После предоставления клиентом полномочия на просмотр его рабочего стола, рабочий стол будет отображен в окне на вашем экране.

Щелкните кнопкой мыши для получения управления рабочим столом клиента.

Показ рабочего стола клиенту

Можно предоставить просмотр своего рабочего стола клиенту, чтобы продемонстрировать действия по устранению неполадок.

Откройте инструментальную панель представителя клиентской службы, панель пиктограмм или окно работы с несколькими сеансами.

На панели пиктограмм выберите пиктограмму Удаленное управление.

Отобразится сообщение о том, что клиент получил ваш запрос. Клиент должен предоставить вам полномочие, щелкнув ОК в окне сообщения, которое появится на экране.

Появится окно «Просмотр рабочего стола», указывающее на то, что вы предоставляете совместный доступ к рабочему столу.

Предоставление клиенту управления вашим рабочим столом

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

При передаче клиенту управления рабочим столом, он может открыть на вашем компьютере любые файлы или программы, которые не защищены паролем.

Откройте инструментальную панель представителя клиентской службы, панель пиктограмм или окно работы с несколькими сеансами.

На панели пиктограмм выберите пиктограмму Удаленное управление.

Клиент должен предоставить вам полномочие, щелкнув ОК в окне сообщения, которое появится на экране.

Попросите клиента щелкнуть мышью в любом месте окна совместного доступа для получения управления вашим рабочим столом.

Если клиент уже просматривает ваш рабочий стол, вы можете разрешить ему управлять им, не прерывая сеанс.

Остановка предоставления клиенту совместного доступа к рабочему столу

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

Нажмите кнопку Совместный доступ в строке заголовка любого открытого окна.

Совместный обзор с клиентом в ходе сеанса подключения по щелчку

Подготовка

Для совместного с клиентом обзора можно начать сеанс подключения по щелчку. Сеанс подключения по щелчку позволяет автоматически предоставлять в совместный доступ окно, в котором клиент начал сеанс.

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

Для совместного обзора требуется WebACD. Обратитесь к администратору сайта за дополнительной информацией.

Откройте инструментальную панель представителя клиентской службы, панель пиктограмм или окно работы с несколькими сеансами.

На панели пиктограмм выберите пиктограмму Удаленное управление.

Отобразится сообщение о том, что клиент получил ваш запрос. Ваш запрос отобразится в окне сообщения на экране клиента. Клиент должен предоставить вам полномочие, щелкнув ОК в окне сообщения.

Окно подключения по щелчку, с помощью которого клиент инициировал сеанс, автоматически выбирается в качестве окна совместного доступа.

Источник

Cisco Meeting Server — теперь вся видео-конференц-связь из одного места

Здесь мог бы быть ваш президент, но сейчас — просто тесты соединения

В сравнении с этой новой штукой от Циски предыдущие архитектуры ВКС реализовывались именно через то место, о котором вы сейчас, возможно, подумали. Чтобы рассказать про глубину проблемы, нужно немного окунуться в историю.

Итак, зачем людям нужны собственные ВКС-линки, когда есть скайп, веб-конференции с видеочатами и всякие другие приблуды? Главный аспект здесь — есть компании, которые никогда не пойдут на то, чтобы гонять трафик через кого-то, кроме себя. Чтобы было ещё понятнее, отмечу, что, например, у судов или у военных в России своя собственная сеть, физически не соединённая с Интернетом. Она ещё и децентрализованная на случай, если уничтожат пару узлов вместе с городами. Ни министерства, ни крупный бизнес не будут доверять чужим серверам и чужим сетям.

Дальше вендоры, видя потребность, начали делать свои ВКС-решения и максимально «привязывать» клиентов к ним проприетарным стеком протоколов, общей парадигмой, совместимостью железа и стандартов и так далее. Результат — появилось около 5–10 «религий», которые затем были слиты в несколько базовых слияниями-поглощениями.

И теперь Циско делает неожиданный поворот, предлагая виртуализованный сервер, который может работать с подавляющим большинством стандартов и — внимание! — может даже ставиться на инфраструктуру «другой религии». Вот про это чудо я и скажу пару слов.

Проблема инфраструктуры

Зачем вообще в ВКС-сети нужна серверная инфраструктура? Она же отлично децентрализуется, верно? И да и нет. Соединения «как в скайпе» — камера с камерой (то есть один на один) вполне работают децентрализованно (и российские суды — это отличный пример такой p2p-сети). Однако для крупных совещаний, например, когда генеральный директор сотового оператора или нефтяной компании опрашивает руководителей областей, нужно куда больше «окон». Обычная ситуация — 10–15 человек, и у каждого свой терминал. В итоге связь на таких конференциях идёт через центральный узел или что-то, что может играть его роль. Там происходит микширование каналов, и каждый из терминалов пользователей отдаёт один поток и получает один поток (с одной или несколькими картинками).

Зачем нужен терминал пользователя?

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

Стоимость такого «железного» терминала сейчас приближается к стоимости купленного ноутбука нужной мощности и дополнительной периферии — теми самыми приличными камерами, микрофонами и внешним экраном.

Теперь история про купленных мальчиков

Жили-были мальчики, которые писали софт для зоопарка различных модулей по управлению конференциями. В какой-то момент их компания стала чем-то вроде посредника между «религиями» и запилила хороший сервер многоточки (Codian MCU) для организации связи. В этот момент к нему подкралась Тандберг и коварно купила его компанию со всеми наработками. А потом Тандберг купила Циска… Но мальчики из Codian оказались не промах — они взяли и основали новую компанию, зная, что Циске точно нужно. И сделали чудо-железку — митинг-сервер Acano, который решал все нюансы проблемной настройки. То есть переписали центральный компонент сети за Циску, только по-умному, сильнее, выше и быстрее. И начали продавать как крутое железное решение.

Циска купила мальчиков во второй раз. Поскольку Acano не знали, кому продаваться, у них была почти готовая виртуализация и под MS Hyper-V, и под VMware Циска оставила оба решения, превратив железку в обычное ПО, то есть виртуальную машину на одном из ваших апликейшн-серверов. Так появился текущий продукт.

Зачем эта штука реально нужна?

Теперь с использованием одного изделия можно интегрировать в рамках виртуальных переговорных комнат огромное количество участников с оборудованием любого типа или вообще без оборудования. Раньше это потребовало бы серьёзных танцев с бубном и моря страданий. Сейчас море страданий вынесено в часть «конфигурация и интеграция», а танцы с бубном отсутствуют.

До этого ситуации решались разным набором оборудования и ПО — кучей специализированного железа вроде отдельных плат балансировки и серверов интеграции. В итоге у нормального админа после долгой настройки работало, но было много точек отказа. Получалось довольно дорого и не всегда стабильно.

Пример того, что делает митинг-сервер, — хорошее интеллектуальное резервирование и каскадирование. И это ни фига не настроишь самостоятельно. Например, система позволяет в авторежиме подключать пользователей туда, где больше доступных ресурсов, либо где ближе по географии. Все участники набирают один номер, но каждый идёт на свой сервер. И между серверами автосвязь. Что позволяет экономить полосу пропускания канала. Это очень круто, когда по 10 участников в трёх городах — десятикратная экономия на полосе.

Циска говорит, что 30% возможностей сервера доступно из коробки, а 70% настраивается через API, поэтому роль интегратора выходит на первый план. Настроить сложно (нужны зачатки интеллекта и хорошее знание кипы инструкций), поэтому просто купить нельзя — устанавливать могут только сертифицированные сотрудники, которые прошли обучение и прочитали «Отче наш». Ну, или зарезали котёнка.

В итоге Циска смогла сделать три важные вещи:

Основные фишки CMS

Хорошая интеграция со скайпом для бизнеса, между сервером скайпа и сервером Циски устанавливается одно соединение в 5 потоков (для скайпа это разные разрешения):

Организация конференций с помощью стандартного плагина Skype for Business Outlook plugin, подключение видеотерминалов Cisco через OBTP (One Button To Push), остальных аудио- и видеоучастников через IVR, участники традиционной ВКС собираются на CMS, SfB на AV MCU, трансляция до 5 изображений в обе стороны, полнодуплексный обмен контентом.

Очень интересная лицензионная политика. Циска продаёт теперь не видеопорты, а конференции. Без ограничения числа участников. Циска даже предлагает конверсию существующих портовых лицензий. Например, если есть полностью амортизированные ВКС-сервера Cisco TelePresence MCU — можно перейти на новые лицензии даже с 7-летнего ветерана. Лицензии делятся на общие и персональные. Или, если проще, на дорогие и дешёвые. Поэтому в мёде неограниченных участников конференции есть и ложка дёгтя. Прикол в том, что звонок из скайпфорбизнеса в терминал Циско — это уже общая конференция. Одна конференция по list price — 12 тысяч долларов. Если хотите вместо логотипа Циско видеть свой — ещё 20 тысяч за брендирование всей инфраструктуры. Русский IVR — часть брендирования, то есть по умолчанию всё английское. Многоязычности нет, надо выбирать один язык.

И напоследок — данному изделию Циско придан наивысший приоритет — выпускать обновления они хотят в два раза быстрее в два раза большей командой (да-да, я тоже вспомнил анекдот про 9 женщин и месяц).

Кому это нужно

Очень многим! Например, компаниям, где много разного оборудования (в госструктурах и других территориально распределённых организациях), благодаря всеядности, CMS связывает всё вместе (может использоваться любая система управления вызовами — хоть Поликом, хоть Cisco, хоть вообще без неё; терминалы — любой производитель и т. д.). Безусловно, решение понадобится тем компаниям, у которых уже развёрнуто решение Cisco TelePresence — обновляться имеет смысл только на CMS. А также компаниям, которые хотят быстро и просто организовать общение через Интернет — вне зависимости от того, на каком вендоре сделано их решение ВКС.

Резюме

Почти все аспекты настройки и все аспекты эксплуатации могут быть реализованы через API.

CMS является эдаким медиакомбайном, который напрямую понимает практически все актуальные на данный момент открытые стандарты и протоколы связи, что позволяет использовать его для совместных конференций с разнородными участниками, в качестве шлюза между такими разнородными участниками, собственное приложение Cisco Meeting App позволяет его пользователю самостоятельно приглашать абонентов в конференцию и управлять ими (отключать звук/видео, выкидывать из конференции) — но это не уникальная концепция (ранее было реализовано Vidyo). Пользователи видеотерминалов Cisco TelePresence могут самостоятельно выбирать экранную раскладку из меню видеотерминала, а также видеть список участников конференции (т. н. roster list). Что важно — без использования DTMF. Можно использовать не только совместно с оборудованием Cisco для ВКС, но и использовать системы управления вызовами других вендоров и работать со сторонними терминалами или вообще без терминалов, через браузер.

Источник

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

Пришло время сделать так чтобы корпоративные сервисы связи были доступны вне офиса без дополнительных телодвижений со стороны пользователя вроде использования приложения 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-DSK — Expressway Desktop Endpoint License (Для Expressway-C) нужна для регистрации на Expressway персональных устройств.

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

LIC-TP-ROOM — Есть ещё такая лицензия для CUCM, чтобы зарегистрировать кодек на CallManager’е, опционально в неё входит лицензия LIC-EXP-ROOM.

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

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

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

Немного забегая вперед скажу, что связку 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-адрес будет смотреть в Интернет или нет.

В зависимости от того, кластер вы разворачиваете или нет, 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.

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

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

Update: Промежуточный сертификат поменяли на вот этот.

По предыдущему будет вот такая ошибка:

CME deploy operation failed: The trust chain for the pending certificate is missing or invalid.

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, example.ru или collab-edge.example.ru, если DNS запись типа А example.ru указывает на IP-адрес сайта организации. Также надо не забыть создать DNS запись типа А collab-edge.example.ru на внешнем DNS сервере, иначе запрос будет отклонён.

Иначе без example.ru или collab-edge.example.ru клиенты Cisco Jabber будут ругаться о том, что сертификат не доверенный.

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

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

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

В описание бага также описано и решении и по его обходу, пофиксят в 12.5.7 версии.
UPD: Версии 12.5.7 и 12.5.8 отозваны по причине багов и косяков с безопасностью, обновите до 12.5.9.

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

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

Зона для 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, иначе работать ничего не будет, по какой причине так сделано, мне пока узнать не удалось.

Обратите внимание, что мы здесь указываем порт 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 расшифровывается как 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.

В поле 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-Reflection требуется для MRA, т.к. если Expressway-C инициирует связь с Expressway-E «стучась» в серый ip-адрес Expressway-E, то при звонке на/с джаббер(а), который находится вне корпоративной сети, на Expressway-C будет требоваться RMS лицензия, т.е. звонок будет восприниматься, как B2B. Чтобы этого избежать требуется на внутреннем DNS-сервере создать А-запись Expressway-E, которая указывает на его белый ip-адрес, а NAT-Reflection поможет перенаправить трафик в интерфейс Expressway-E на серый ip-адрес.

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

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

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

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

Указываем CMS

Чтобы Expressway-C корректно увидел наш кластер CMS нужно на внутреннем DNS сервере в зоне для внешнего домена(если у нас Dual-Domain сценарий) создать каталог join, в нем каталог _tls, и уже в нем три DNS записи типа SRV _cms-web с соответствующими приоритетами, которые соответственно указывают на DNS записи типа А cms01.internal-domain.ru, cms02.internal-domain.ru, cms03.internal-domain.ru.

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

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

Включаем MRA

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

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

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

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

Маршрутизация на 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-адресом в сети Интернет) адреса назначения и успешного звонка.

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

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

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

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

Итак проведём тестовые звонки. Позвоним в конференцию с 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-адресов, необходимость в этом есть потому, что я описываю реальную боевую настройку, которая сейчас работает, отсюда некоторые вопросы безопасности.

Источник