Cisco Meeting Server 2.4.1. Интеграция с Cisco Unified Communications Manager 11.5 +6



Я работаю в одном крупном интеграторе, и настало для меня время понять, что такое CMS(Cisco Meeting Server) и как его интегрировать с CUCM(Cisco Unified Communications Manager).


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

Прежде чем приступить к настройке, рекомендуется выполнить следующее:
В DNS для IP-адреса CMS сервера должна быть создана запись с использованием alias'a, который мы хотим чтобы использовали конечные пользователи например:

meetingserver.example.com

Доменное имя XMPP. Это доменное имя, которое пользователь будет использовать для входа в систему Cisco Meeting App. В нашем случае после импорта из Active Directory это будет sAMAccountName пользователя.

Для поддержки пользователей Cisco Meeting App запись DNS SRV для доменного имени XMPP должна быть добавлена на DNS-сервер. Записи SRV для _xmpp-client._tcp. <Домен xmpp>
для TCP нужен порт 5222.

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

Предлагается использовать поддомен, такой как meet.example.com например.

IP-адрес, маска, шлюз, DNS, NTP, новый пользователь


Первое, что делаем, это задаём нужный нам IP-адрес нашего сервиса
(у CMS сервера несколько интерфейсов, выбираем самый первый — «a»)



Задаём DNS сервер(ы) зоны нашего домена(если нужно), командой «dns» проверяем



hostname нашего CMS и перезагружаем.



В целях безопасности рекомендуется создавать собственные учетные записи администратора в качестве имени пользователя.

«admin» не очень безопасен. Кроме того, рекомендуется использовать две учетные записи администратора на случай, если Вы теряете пароль для одной учетной записи. Если вы это сделаете, то вы все равно можете войти в систему с другой учетной записью
и сбросить потерянный пароль.


Здесь «root» имя пользователя, «admin» роль.



Немного забегая вперёд создадим ещё пользователя с ролью "appadmin", он нам нужен будет для того чтобы CUCM мог выполнять настройку CMS на уровне приложения через интерфейс Web Admin. Проще говоря чтобы зарегистрировался Conference Bridge.



Дальше задаём наш NTP сервер и временную зону(timezone), в нашем случае Europe/Moscow и перезагружаем



Сертификаты и лицензия для CMS


Теперь нам нужно сформировать запрос на выдачи сертификата для нашего CMS сервера.

Cisco Meeting Server использует сертификаты x.509 для настройки безопасных (TLS) соединений в своих службах и для некоторых задач аутентификации. В нашем случае сертификат требуется для служб Call Bridge, XMPP, Web Bridge и Web Admin. Сертификаты могут быть самоподписанными или подписанными внутренними или внешними центрами сертификации.

Использование самоподписанного сертификата возможно, но не рекомендуется, так как это приведет к появлению ошибок на веб-страницах и помешает зарегистрировать так называемый Conference Bridge нашего CMS сервера на CUCM'e(Cisco Unified Communications Manager).


Итак, формируем запрос:

pki csr Cert CN:example.com subjectAltName:callbridge.example.com,xmppserver.example.com,webbridge.example.com

Т.к. в нашем случае мы используем один и тот же сертификат для всех служб в AltName пишем «имена» этих служб.



Скачиваем, устанавливаем и запускаем WinSCP для того, чтобы получить файл нашего запроса, а заодно и закинуть на наш CMS сервер файл лицензии, без которой ничего у нас работать не будет.

Чтобы эту лицензию(причём демо-лицензию например на 90 дней) получить, нужно обратится к какому-либо партнёру Cisco(например интегратору в котором работаю я) и слёзно попросить демо-лицензию для целей обучения или демонстрации кому-нибудь его чтобы потом продать, ну либо купить полноценную лицензию и приложить к слёзному письму МАС-адрес интерфейса.

Чтобы посмотреть МАС-адрес, вводим команду "iface a"



Так вот представим, что нам повезло и нам прислали файл с этой самой лицензией с расширением .lic. Переименовываем этот файл как "cms.lic"

Итак, запустили WinSCP. Создаём подключение к CMS.



Заходим:



и копируем себе файл Cert.csr, а на CMS копируем файл cms.lic и серт, который мы получили.



Т.к. в моём случае чтобы создать файл цепочки сертификатов, который примет наш CMS сервер (файл с расширением p7b он не примет), делаем следующее:

С помощью командной строки:

a. В операционной системе семейства UNIX: cat “сертификат посредника 1” “сертификат посредника 2” “сертификат посредника 3” “корневой сертификат” > ca-bundle

b. В Windows/DOS: copy “сертификат посредника 1” + “сертификат посредника 2” + “сертификат посредника 3” + “корневой сертификат” ca-bundle

И загружаем его и полученный сертификат для CMS сервера от центра сертификации также через WinSCP на CMS сервер



Перезагружаем, проверяем лицензии



Call Bridge, Web admin, XMPP, Web Bridge


Call Bridge



Настраиваем Call Bridge на a интерфейсе командой

callbridge listen a

Настраиваем Call Bridge для использования сертификата, ключа и цепочки сертификатов командой вида:

callbridge certs <keyfile> <certificatefile> <ca bundle>

Перезапускаем callbridge:

callbridge restart



Web Admin


Включаем службу веб-администратора:

webadmin listen a 445

445 порт выбран потому, что 443 порт используется для доступа пользователей в web-клиент

Настраиваем Web Admin службу с файлами сертификатов командой вида:

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

И включаем Web Admin командой:

webadmin enable



Если всё хорошо, то мы получим строки SUCCESS, в которых указано, что Web Admin правильно настроен для сети и сертификата. Проверяем работоспособность службы с помощью веб-браузера и вводим адрес веб-администратора, например: cms.example.com:445



XMPP


Включаем службу XMPP

xmpp listen a

Настраиваем Web Bridge службу с файлами сертификатов командой вида:

xmpp certs <keyfile> <certificatefile> <ca bundle>

Определяем домен XMPP для развертывания с помощью команды вида:

xmpp domain <domain name>

Включаем службу

xmpp enable

Проверяем CMS и CUCM



Добавляем Call Bridge в XMPP сервер командой вида:

xmpp callbridge add



Копируем Secret и вставляем сюда, остальное заполняем также(см. рисунок ниже)



Web Bridge


Включаем службу Web Bridge
webbridge listen a:443

Настраиваем Web Bridge службу с файлами сертификатов командой вида:
webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web Bridge поддерживает HTTPS. Он будет перенаправлять HTTP на HTTPS, если настроен для использования «httpredirect».
Чтобы включить перенаправление HTTP, используйте следующую команду:
webbridge http-redirect enable

Чтобы Call Bridge дал понять, что Web Bridge можно доверять соединениям из Call Bridge, используйте команду
webbridge trust <certfile>
с использованием сертификата выданного нам ранее центром сертификации



Настройка основных параметров вызова



Заходим Configuration > Callsettings и выставляем значения как указано ниже



Настройка правил входящих вызовов


Заходим Configuration > Incoming calls и задаём значения как указано ниже



Здесь определяется, как CMS обрабатывает входящие SIP звонки. Любой вызов, направляемый на CMS сервер, будет иметь проверенный псевдоним, правила в таблице соответствия вызовов, определяют, где CMS должен искать потенциальные совпадения. Каждое правило может быть установлено для соответствия любой комбинации пользователей, IVR или MicrosoftSkype / Lync. Cisco Meeting Server сопоставляет входящие звонки, проверяя значение после символа «@» со значениями в столбце домена.

Настройка правил исходящих вызовов


Заходим в Configuration >Outbound calls.
Domain name: Оставляем пустым. Обратите внимание, что это позволяет нам сопоставить все домены.
SIP Proxy to use: вводим полное доменное имя нашего CUCM'a(можно использовать IP-адрес, но рекомендуется полное доменное имя)
Local contact domain: Оставляем пустым, здесь настройка требуется только когда настраивается SIP Trunk для Skype for Business
Local from domain: Вводим SIP-домен Cisco Meeting Server'a (например: cms.example.com)
Trunk type: Standard SIP
Behavior: Continue
Priority: 1
Encryption: Auto или Unencrypted
Нажмите Add New, чтобы сохранить изменения.



Создаём Space


Space это пространство где будут хранится пользователи

Заходим в Configuration > Spaces



Для вторичного URI используйте значение E.164, которое будет совместимо с вашим dial-plan'ом, который будет маршрутизироваться на CMS сервер. Для CallID значением может быть любой номер, который еще не используется, в этом примере для простоты установлено то же значение, что и для вторичного URI.

Настройка Web Bridge для Call Bridge


Чтобы разрешить гостевой доступ к Web Bridge, необходимо настроить Call Bridge для определения адреса Web Bridge.

Заходим Configuration > General

Устанавливаем для гостевой учетной записи URL-адрес HTTPS CMS сервера. Например:
meetingserver.example.com



Поле External Access используется если вы решите добавить веб-прокси Cisco Expressway. Это адрес, который используется в приглашениях для внешних пользователей.

Сертификаты для CUCM


Также выполняем запрос с CUCM'a для служб Tomcat(это web-сервер CUCM) и CallManager
Заходим Cisco Unified OS Administration--Security-Certificate Management и нажимаем Generate CSR



Выбираем сначала Tomcat для Web-сервера. Это чтобы ошибка не возникала в браузере.



Нажимаем Generate

Потом CallManager, это для того, чтобы CMS и CUCM проверяли сертификаты друг друга для регистрации моста конференций(Conference Bridge).



Нажимаем Generate

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







Далее загружаем в Tomcat trust и CallManager trust корневой и промежуточный сертификаты, либо одним файлом, как я писал выше, либо по очереди сначала корневой, потом промежуточный







И нажимаем Upload





Также загружаем полученные сертификаты от центра сертификации, которые он сформировал на основе нашего запроса





Далее идём перезапускать службы Cisco Tomcat, Cisco CallManager и Cisco TFTP

Служба Cisco Tomcat перезапускается из консоли.



Остальные можно и через Web-интерфейс





Нажимаем Restart и ждём.

SIP trunk security profile


Теперь создаём SIP trunk security profile

В нашем случае звонки будут не шифрованные поэтому выбираем те значения которые указаны ниже и вводим CN сертификата Call Bridge. Это должно быть полное доменное имя нашего CMS сервера.

Напротив Accept Replaces Header установите галочку, если собираетесь использовать групповые мосты звонков.



Conference Bridge


Создаём Conference Bridge, как указано ниже, логин и пароль забиваем пользователя с ролью appadmin, которого мы создали в самом начале.



Создаём Media Resource Group и добавляем в неё наш Conference Bridge



Создаём Media Resource Group List и добавляем в него нашу Media Resource Group



Заходим в Standard SIP Profile For TelePresence Conferencing и проверяем стоят ли галочки напротив: Allow iX Application Media, Use Fully Qualified Domain Name in SIP Requests, и Allow Presentation Sharing use BFCP.





SIP Trunk


Далее создаём SIP Trunk на CMS сервер



Для того что звонок из приложения или Wеb интерфейса CMS сервера прошёл нужно выставить нужный Calling Search Space, иначе CMS в логах скажет, что не нашёл такого номера.Номер телефона и сам телефонный аппарат должны быть в этих Calling Search Space'ах.



Media Resource Group List — Выбираем созданный нами ранее.

Галочка SRTP Allowed разрешает прохождение шифрованных звонков, её в принципе можно не ставить.

SIP Information > Destination address — Указываем FQDN или IP-адрес нашего CMS сервера.
SIP Information > Destination Port — стандартный SIP порт 5060, 5061 — для шифрованных звонков
SIP Trunk Security Profile — Выбираем профиль, созданный нами ранее.
SIP Profile — Выбираем Standard SIP Profile For TelePresence Conferencing
Normalization Script — Ничего не выбираем. Скрипт не нужен в нешифрованных звонках. Выбираем cisco-telepresence-conductor-interop только в случае шифрования.

Настройки выделенные зелёным нужно выбрать тоже с умом/ Для полного понимания разберитесь, что такое Calling Search Space.



Всё остальное оставляем по умолчанию.



SIP route pattern


Создаём SIP route pattern для возможности звонков на sip адреса вида zhopin.n@examle.com



Проверяем CMS и CUCM



Trunk поднялся



А вот Conference Bridge не поднялся. Это из-за того, что версии TLS на CUCM и CMS не совпадают. Решается это проблема установлением минимальной версии TLS 1.0 на CMS сервере командами:

tls webadmin min-tls-version 1.0
webadmin restart



Проверяем Conference Bridge



Наше настройка была выполнена на транках без Media Termination Point (MTP).
Отключите MTP, если это не окажет негативного влияния на работу сервисов.

Отключение MTP может иметь негативное влияние, если вы используете телефоны которые работают по SCCP протоколу и вам необходимо отправить DTMF на CMS сервер.

Если вышеуказанное имеет значение для ваших сервисов, вам может потребоваться увеличить емкость MTP на Cisco Unified Communications Manager в зависимости от количества одновременных вызовов.


Импорт пользователей из Active Directory


Теперь импортируем пользователей из Active Directory.

Заходим как на рисунке ниже, забиваем значения.

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



Проверяем логи



Всё хорошо.

Заходим в пользователей



Всё замечательно импортировалось.

Проверка работоспособности


Теперь самое сладкое. Заходим в web-интерфейс чтобы позвонить, по адресу cms.example.com
Вводим логин/пароль пользователя из Active Directory



Зашли



Проверим видеозвонок с IP-фона(у меня Cisco E20) на нашу учётную запись.

У меня запущен и Web и десктопная версии Cisco Meeting клиента, и обе звонят









Проверим видеозвонок из нашей учётной записи на IP-фон.





Всё замечательно, видеозвонок в обе стороны прошёл.

С шифрованными звонками немного сложнее, но об этом как-нибудь в другой раз.

Ссылки на материалы:

www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-3/Cisco-Meeting-Server-Single-Server-Simplified-Setup-Guide.pdf
www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-4/Cisco-Meeting-Server-2-4-Deployments-with-CUCM.pdf
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

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (7):

  1. Geks0geN
    /#19517152

    Доброго дня.
    Спасибо за статью. Сам все планирую написать что-то аналогичное по CMS, да все лень и руки не доходят. Поэтому немного покритикую и дополню.
    В целом настройка конкретно этой части строго по мануалам, ничего интересного и сложного нет. Больше того, интеграция с CUCM — это самая простая и беспроблемная часть настройки CMS. Самый ад начинается дальше, когда приходится настраивать нужный функционал через API. А так же сделать работоспособной конференцию через Expressway. Да не просто через Expressway, а стоящим за МЭ.
    Касательно интеграции с CUCM. Важно помнить, что:
    — нужно правильно создать сертификаты с нужными именами в SAN'ах, потому что иначе не заработает;
    — не знаю, как в версии 2.4.1, а в версии 2.1-2.3 был следующий баг — если случайно ввести пароль неверно при создании Conference Bridge, то ошибки никакой не возникало, мост регистрировался, но видеоконференции при видимой работоспособности соединения не работали. Только в логах вместе с ТАС удавалось выяснить, что проблема таки есть именно в неправильном пароле;
    — Если вдруг через полгода вы приходите на работу, а у вас не работает видеоконференцсвязь, в первую очередь проверьте пароли пользователя с правами API, которого как раз и указывают при создании Conference Bridge. По умолчанию все пароли действительны в течение 184 дней (6 месяцев по документации), после чего они становятся неактивными, и требуется вручную поправить их везде.
    — Не увидел в статье настройки маршрутизации звонков для ad-hoc конференций через Spaces. Но, возможно, не планировалось.
    — Самый большой минус лично для меня — необходимость интеграции с AD. Т.е. без нее, конечно, все будет работать. Но управление конференциями, смены паролей на spaces, резервирование слота — все это делается через специальную управлялку (Cisco Meeting Manager), которая даже не устанавливается без AD (требуется указать контроллеры доменов на этапе установки). Грусть прям.
    Еще много вопросов есть, которые лично я, даже общаясь с ТАС, не закрыл полностью. Поэтому, если будет интересно, пишите, возможно поможем друг другу.

    • s_dubinin
      /#19517178

      Обязательно, напишу. А по поводу паролей это очень ценная информация. Но читая мануалы я вижу, что версия 2.3 очень сильно отличается от 2.4. Так что возможно уже там эти премудрости не пригодятся, я надеюсь. Кстати уже обновился до версии 2.5.
      На счёт интересного и сложного:
      я убил три дня чтобы найти информацию почему-же не поднимается Conference Bridge. Как я уже описал дело было в версии TLS. Казалось бы всё просто, а внезапно натыкаешься на такие мелкие, но очень важные детали.

      • Geks0geN
        /#19517304

        Это тоже раздражает. Я делал установку совсем недавно — версия была 2.4.1. 2.5 не было. Теперь получается, что появилась 2.5 буквально за одну неделю…
        Вообще сам по себе продукт показался довольно глючным. И документация к нему местами допускает очень большие двусмысленности. И даже ТАС ломает голову и не знает, как решить, в чем проблема.

  2. Karroplan
    /#19517340

    у CMS основная проблема не в том, как его интегрировать, а в том «нафига ж он нужен??» ;) смотрите, была вся линейка VCS-C, VCS-E и прочих устройств ВКС, а была отдельно телеофния и UC в виде CUCM с jabber-ом. И у всего этого была проблема — нормально позвонить в Skype/Skype for business — сложно. Нормально собрать конференцию с устройствами Polycom, так чтоб всё шарилось в высоком качестве и не глючило — сложно.
    Внезапно, появляется Acacno, с хорошим транскодером, который знает чужие кодеки и, оба-на, у ней внутре неонка, то есть свой UC. Циска это дело покупает, закапывает в подпол Expressway (vcs-c, vcs-e) и говорит «так, отныне регистрируем устройства на CUCM, сбоку ставим транскодер CMS». ЭЭЭэээээ, а UC на чем делать? На жаббере или на CMS? А когда половина в жаббере, а половина в CMS, а третья половина позвонила из HQ по SfB и все дружно набились в конференцию — скоко лицензий надо? и каких?
    и еще, какой лимит людей в конференции CMS? 1000 можно? а 5000? никаких документов по перфомансу, кроме «1 конфа в full-hd требует 1,15 vcpu». дайте две.
    а, ну и как всегда — SMP-лицензия — 12k$ GPL… пипец.

    • Geks0geN
      /#19517408

      Согласен со всем=)
      А разве Expressway закопан? Живее всех живых для MRA и B2B… По крайней мере так позиционируется.

      • Karroplan
        /#19517510

        я, наверное, резковато выразился. да, он продается, но в основном VCS-E, как средство преодоления фаерволла… а вот VCS-C уже не рекомендуют, сами Cisco говорят, что регистрировать устройства надо на CUCM. Если раньше было просто, вот VCS-C, вот маршруты в сторону Skype через CMS, вот наружу в VCS-E, то теперь вроде как CUCM, на CMS как медиа-ресурс, и транки во все стороны. как быть с UC — нипанятнааа.

  3. newborn83
    /#19519208

    Напишите ещё про интеграцию с TMS и TMSxe, там тоже много неочевидных и непонятных моментов.