Я работаю в одном крупном интеграторе, и настало для меня время понять, что такое CMS(Cisco Meeting Server) и как его интегрировать с CUCM(Cisco Unified Communications Manager).
В данном посте предполагается, что CMS и CUCM уже развёрнуты на виртуальных машинах.
Прежде чем приступить к настройке, рекомендуется выполнить следующее:
В DNS для IP-адреса CMS сервера должна быть создана запись с использованием alias'a, который мы хотим чтобы использовали конечные пользователи например:
Доменное имя 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-адрес нашего сервиса
(у CMS сервера несколько интерфейсов, выбираем самый первый — «a»)
Задаём DNS сервер(ы) зоны нашего домена(если нужно), командой «dns» проверяем
hostname нашего CMS и перезагружаем.
В целях безопасности рекомендуется создавать собственные учетные записи администратора в качестве имени пользователя.
«admin» не очень безопасен. Кроме того, рекомендуется использовать две учетные записи администратора на случай, если Вы теряете пароль для одной учетной записи. Если вы это сделаете, то вы все равно можете войти в систему с другой учетной записью
и сбросить потерянный пароль.
Здесь «root» имя пользователя, «admin» роль.
Немного забегая вперёд создадим ещё пользователя с ролью "appadmin", он нам нужен будет для того чтобы CUCM мог выполнять настройку CMS на уровне приложения через интерфейс Web Admin. Проще говоря чтобы зарегистрировался Conference Bridge.
Дальше задаём наш NTP сервер и временную зону(timezone), в нашем случае Europe/Moscow и перезагружаем
Теперь нам нужно сформировать запрос на выдачи сертификата для нашего CMS сервера.
Cisco Meeting Server использует сертификаты x.509 для настройки безопасных (TLS) соединений в своих службах и для некоторых задач аутентификации. В нашем случае сертификат требуется для служб Call Bridge, XMPP, Web Bridge и Web Admin. Сертификаты могут быть самоподписанными или подписанными внутренними или внешними центрами сертификации.
Использование самоподписанного сертификата возможно, но не рекомендуется, так как это приведет к появлению ошибок на веб-страницах и помешает зарегистрировать так называемый Conference Bridge нашего CMS сервера на CUCM'e(Cisco Unified Communications Manager).
Итак, формируем запрос:
Т.к. в нашем случае мы используем один и тот же сертификат для всех служб в 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 на a интерфейсе командой
Настраиваем Call Bridge для использования сертификата, ключа и цепочки сертификатов командой вида:
Перезапускаем callbridge:
Включаем службу веб-администратора:
445 порт выбран потому, что 443 порт используется для доступа пользователей в web-клиент
Настраиваем Web Admin службу с файлами сертификатов командой вида:
И включаем Web Admin командой:
Если всё хорошо, то мы получим строки SUCCESS, в которых указано, что Web Admin правильно настроен для сети и сертификата. Проверяем работоспособность службы с помощью веб-браузера и вводим адрес веб-администратора, например: cms.example.com:445
Включаем службу XMPP
Настраиваем XMPP службу с файлами сертификатов командой вида:
Определяем домен XMPP для развертывания с помощью команды вида:
Включаем службу
Проверяем CMS и CUCM
Добавляем Call Bridge в XMPP сервер командой вида:
Копируем Secret и вставляем сюда, остальное заполняем также(см. рисунок ниже)
Включаем службу Web Bridge
Настраиваем Web Bridge службу с файлами сертификатов командой вида:
Web Bridge поддерживает HTTPS. Он будет перенаправлять HTTP на HTTPS, если настроен для использования «httpredirect».
Чтобы включить перенаправление HTTP, используйте следующую команду:
Чтобы Call Bridge дал понять, что Web Bridge можно доверять соединениям из Call Bridge, используйте команду
Заходим 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 это пространство где будут хранится пользователи
Заходим в Configuration > Spaces
Для вторичного URI используйте значение E.164, которое будет совместимо с вашим dial-plan'ом, который будет маршрутизироваться на CMS сервер. Для CallID значением может быть любой номер, который еще не используется, в этом примере для простоты установлено то же значение, что и для вторичного URI.
Чтобы разрешить гостевой доступ к Web Bridge, необходимо настроить Call Bridge для определения адреса Web Bridge.
Заходим Configuration > General
Устанавливаем для гостевой учетной записи URL-адрес HTTPS CMS сервера. Например:
meetingserver.example.com
Поле External Access используется если вы решите добавить веб-прокси Cisco Expressway. Это адрес, который используется в приглашениях для внешних пользователей.
Также выполняем запрос с 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
В нашем случае звонки будут не шифрованные поэтому выбираем те значения которые указаны ниже и вводим CN сертификата Call Bridge. Это должно быть полное доменное имя нашего CMS сервера.
Напротив Accept Replaces Header установите галочку, если собираетесь использовать групповые мосты звонков.
Создаём 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 на 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 адреса вида zhopin.n@example.com
Проверяем CMS и CUCM
Trunk поднялся
А вот Conference Bridge не поднялся. Это из-за того, что версии TLS на CUCM и CMS не совпадают. Решается это проблема установлением минимальной версии TLS 1.0 на CMS сервере командами:
Проверяем Conference Bridge
Наше настройка была выполнена на транках без Media Termination Point (MTP).
Отключите MTP, если это не окажет негативного влияния на работу сервисов.
Отключение MTP может иметь негативное влияние, если вы используете телефоны которые работают по SCCP протоколу и вам необходимо отправить DTMF на CMS сервер.
Если вышеуказанное имеет значение для ваших сервисов, вам может потребоваться увеличить емкость MTP на Cisco Unified Communications Manager в зависимости от количества одновременных вызовов.
Теперь импортируем пользователей из Active Directory.
Заходим как на рисунке ниже, забиваем значения.
Очень важен фильтр, задайте такой же как у меня, либо те какие вашей душе угодны.
Проверяем логи
Всё хорошо.
Заходим в пользователей
Всё замечательно импортировалось.
Теперь самое сладкое. Заходим в web-интерфейс чтобы позвонить, по адресу cms.example.com
Вводим логин/пароль пользователя из Active Directory
Зашли
Проверим видеозвонок с IP-фона(у меня Cisco E20) на нашу учётную запись.
У меня запущен и Web и десктопная версии Cisco Meeting клиента, и обе звонят
Проверим видеозвонок из нашей учётной записи на IP-фон.
Всё замечательно, видеозвонок в обе стороны прошёл.
С шифрованными звонками немного сложнее, но об этом как-нибудь в другой раз.
Ссылки на материалы:
В данном посте предполагается, что 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,xmpp.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 445445 порт выбран потому, что 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Настраиваем XMPP службу с файлами сертификатов командой вида:
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@example.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
