Дякуємо за відгук.

Webex CallingКрай

Щоб виконати SIP-реєстрацію або виклик, виконайте такі дії:

• Виявлення адреси хоста кінцевої точки SIP для активних вузлів Edge.

• Виконайте будь-які передумови, пов'язані з конфігурацією користувача та пристрою.

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

• Виконайте передумови завантаження кінцевої точки за допомогою конфігурації забезпечення, специфічної для регіону або центру обробки даних. Ця конфігурація допомагає отримати відповідний суфікс доменного імені для виявлення служби.

IPv4 проти IPv6

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

• Режим одного стека — вмикає лише один протокол IP (наприклад, IPv4) та ігнорує інші адреси протоколів.

• Режим подвійного стека — вибирає бажану версію IP через конфігурацію.

Клієнт вважає пріоритет для всіх бажаних адрес нижчим (тобто кращим), ніж всі адреси IP. Якщо вибрано IPv4, перед спробою отримати адресу IPv6 виконується спроба всіх IPv4-адрес. Якщо всі адреси не вдаються, цикл починається знову з бажаної адреси протоколу найнижчого пріоритету.

Мобільний клієнт, який реєструється після отримання push-повідомлення, може вирішити оптимізувати режим на основі попередніх реєстрацій.

Розкриття адреси хоста з DNS SRV адреси

У файлі конфігурації кінцевої точки, отриманому при забезпеченні, індикатор домену вказує ім'я домену для виявлення служби краю доступу. Прикладом доменного імені є:

wxc.edge.bcld.webex.com

У прикладі кінцева точка, яка виконує DNS SRV пошук для цього домену, може дати відповідь, подібну до наступної:

# nslookup -type=srv _sips._tcp. wxc.edge.bcld.webex.com
_sips._tcp.wxc.edge.bcld.webex.com SRV 5 100 5061 sip-edge1.us-dc1.bcld.webex.com.
_sips._tcp.wxc.edge.bcld.webex.com SRV 10 105 5061 sip-edge2.us-dc1. bcld.webex.com.

При цьому запис SRV вказує на 3 записи А.

sip-edge1.us-dc1.bcld.webex.com
sip-edge2.us-dc1.bcld.webex.com

У прикладі всі хости рекламуються для зв'язку з портом 5061 з різною вагою та пріоритетом.

Розглянемо ці вимоги до кінцевих точок.

• Кінцева точка повинна використовувати _sips._tcp(комбінацію служби та протоколу) як префікс для пошуку DNS SRV адреси хоста для ініціювання зв'язку на основі TLS.

• Кінцева точка повинна здійс DNS SRV нити пошук умов, описаних у Розв'язанні адреси хоста з розділу DNS SRV адреси.

• Кінцева точка повинна відповідати хосту, порту, вазі та пріоритету, як рекламуються для кожної адреси хоста. Крім того, він повинен створювати спорідненість хоста до порту при створенні з'єднання з сокетом під час реєстрації SIP.

• Залежно від використання DNS SRV запису, критерії вибору хостів на основі пріоритету та ваги пояснюються в RFC 2782.

Вимоги до безпечного SIP з MTL (взаємний TLS)

Вимоги детально пояснюються тут.

Підписаний сертифікат необхідний для успішної авторизації та аутентифікації дзвінків з магістралі. Сертифікат повинен відповідати наступним вимогам:

• Сертифікат повинен бути підписаний сертифікатором, зазначеним у розділі Які кореневі органи сертифікатів підтримуються для дзвінків на Cisco Webex аудіо- та відеоплатформи?

• Завантажте пакет довіри, зазначений у розділі Які органи кореневих сертифікатів підтримуються для дзвінків на Cisco Webex аудіо- та відеоплатформи? Перейдемо до куба.

• Сертифікат повинен бути дійсним завжди:

  • Підписані сертифікати завжди повинні мати дійсний термін дії.

  • Кореневі або проміжні сертифікати повинні мати термін дії і не можуть бути відкликані.

  • Підтримуються сертифікати, що містять лише розширене використання ключів автентифікації сервера (EKU). Webex Callingне перевіряє та не примусовує наявність EKU автентифікації клієнта під час встановлення рукостискання TLS.

    Деякі сторонні контролери кордонів сеансів (SBC) можуть застосовувати сувору перевірку EKU і можуть відхиляти сертифікати, які не включають EKU автентифікації клієнта. У таких випадках переконайтеся, що SBC налаштовано на прийом сертифікатів лише з автентифікацією сервера EKU або для відключення суворої перевірки EKU (якщо підтримується).

  • Сертифікати повинні містити повністю кваліфіковане доменне ім'я (FQDN) як загальне ім'я або альтернативне ім'я суб'єкта в сертифікаті з FQDN, вибраним у Центрі керування. Наприклад:

    • У магістралі, налаштованому з Центру керування вашої організації з використанням london.lgw.cisco.com:5061 як FQDN, має містити london.lgw.cisco.com у сертифікаті CN або SAN.

    • Центральний сервер, налаштований з Центру керування вашої організації за допомогою london.lgw.cisco.com, повинен містити london.lgw.cisco.com у сертифікаті CN або SAN. Записи, на які розв'язується адреса SRV (CN AME/запис A/ IP-адреса) є необов'язковими в SAN.

  • Ви можете спільно використовувати сертифікати з кількома локальними шлюзами, однак пере конайтеся, що вимоги FQDN задоволені.

Поза межами сфери застосування

Ця стаття не містить наведених нижче відомостей, пов'язаних із безпекою мережі:

• Вимоги F5 до CA та шифрів

• API на основі HTTP для завантаження правил брандмауера для Webex.

• API для комплекту довіри

• Вимоги до брандмауера та вимкнення ALG