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

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

Ось технічні характеристики та вимоги високого рівня TelSP:

• Партнер планує використовувати sip.telsp.com як домен верхнього рівня, яким користуються всі клієнти, якими вони керують.

• Партнер володіє sip.telsp.com і може адмініструвати інфраструктуру DNS та органи сертифікатів, керувати DNS-адресами та підписувати сертифікати для цього домену та його піддоменів.

• Партнер може розгорнути два окремих контролера кордону сеансу (фізичний або віртуальний) як локальні шлюзи для спільного доступу PSTN серед кінцевих клієнтів.

• Партнер має два фізичні сайти, і обидва ці сайти мають спільне підключення PSTN:

  • Маямі

  • Чикаго

• TelSP керує своїми локальними шлюзами від імені двох клієнтів CuSTA та CustB, як вони згадуються далі.

Бажаний сценарій полягає у створенні/припиненні PSTN для обох клієнтів, які використовують шлюзи Майамі та Чикаго, що надаються партнером, як показано на ілюстрації:

Спрощений приклад розгортання

У наведеному нижче спрощеному прикладі показано, як ідентифікація Peer cert дозволяє одному сертифікату підтримувати декілька стовбурів клієнтів:

• Сертифікат —sip. telsp.com

• Стовбури

  • замовник.сіп.телсп.com

  • кустб.сіп.телсп.com

• Ідентичність сертифіката однолітків —sip.telsp.com

• Результат

  • Використовується єдиний сертифікат

  • Підтримується кілька стовбурів клієнтів

Пов'язування місцезнаходження клієнта до магістралі та шлюзу

У наступних розділах наведено детальні відображення конфігурації для роз гортання, описаного вище.

Webex Callingдозволяє створювати стовбури та спільно використовувати багажник у кількох місцях. При створенні стовбура пов'язуйте стовбур з місцем розташування.

Для CUsta деталі багажника наступні:

На ілюстрації показано асоціацію місцезнаходження клієнта до шлюзу та магістралі для CUsta:

У цьому розгортанні магістраль, пов'язаний з місцем розташування, є основним підключенням PSTN для цього місця. Інший магістраль використовується як вторинне з'єднання PSTN або маршрут для певних записів плану набору номера. Реалізація первинного та вторинного зв'язку підключення PSTN здійснюється через концепцію групи маршрутів. Докладніші відомості див. у розділі Налаштування магістралей шлюзів у розділі Контрольний центр.

Для CustB створюється аналогі чна настройка з наступними стовбурами:

На ілюстрації показано асоціацію місцезнаходження клієнта до шлюзу та магістралі для CustB:

На ілюстрації показано третє місце розташування, а саме Нью-Йорк, яке ви можете додати пізніше і вказати на магістраль trunk_chicago як його основ не з'єднання PSTN.

Під час розгортання локального шлюзу, який має спільний доступ до декількох магістралей, Cisco наказує використовувати унікальний FQDN для кожного магістралі. Докладніші відомості див. у розділі Налаштування магістралей, груп маршрутів та планів набору телефонів для дзвінків через WebEx.

Використання IP-адреси та відомого порту на магістралі є ідеальним вибором. Однак придбання публічної адреси IPv4 може бути складним завданням для деяких партнерів, які бажають використовувати одну адресу на шлюз на сайті.

Тому прочитайте ці важливі вказівки:

• Cisco не визначає IP-адресу для кожного магістралі.

• Адреса магістралі може передаватися на унікальну IP-адресу або адресу, спільну між іншим магістраллю.

• Cisco рекомендує налаштувати кожне магістральне з'єднання унікальною комбінацією IP-адреси та портів на локальному шлюзі з наступних причин:

  1. Підтримка окремих посилань TCP-з'єднання на магістралі підтримує максимальну ємність одночасних викликів на магістралі. Обмін IP-адресами та комбінаціями портів між магістралями може негативно вплинути на ємність дзвінків.

  2. Забезпечує ізоляцію на рівні мережі між клієнтами

  3. Для контролерів кордону сеансу характерно повторно використовувати ефемерне з'єднання з сокетом TCP, якщо немає ізоляції як унікального орендаря, розділеного на IP-адресу, або унікальний порт прослуховування для орендаря.

  4. Підключення або з'єднання на магістралі через ізоляцію орендаря забезпечує кращу пропускну здатність, особливо в мережевих умовах з високою втратою даних. Тому трафік одного клієнта не впливає на іншого.

IP-адреса на шлюз: конфігурація магістралі та рекомендації

Зверніться до цих прикладів різних моделей планування:

Модель 1: Унікальна IP-адреса для кожного магістралі

У цій моделі всі магістралі, розміщені обома шлюзами, перетворюються на унікальну IP-адресу, і кожен з цих магістралей може використовувати або не використовувати один і той же порт, але в ідеалі один і той же порт.

Представлення інформації у табличному форматі:

У цій же моделі партнер може використовувати адресу SRV. Webex Callingдозволяє лише «_sips. _tcp» як комбінація служби та протоколу для виявлення адреси одноранга, якщо це запис SRV.

Зразок розв'язання запису SRV

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.custa.sip.telsp.com

Модель 2: Спільний IP на шлюз, унікальні порти прослуховування

У цій моделі всі магістралі, розміщені на локальному шлюзі Чикаго, розв'язуються на ту саму IP-адресу, а всі магістралі, розміщені на локальному шлюзі Майамі, розв'язуються на іншу IP-адресу. Однак при використанні одного і того ж IP кожен магістраль налаштовується за допомогою FQDN в концентраторі управління і налаштовується з унікальним портом.

У цій же моделі партнер використовує адресу SRV. Webex Callingдозволяє лише «_sips. _tcp» як комбінація служби та протоколу для виявлення адреси одноранга, якщо це запис SRV.

Інший зразок того, як вирішується запис SRV, виглядає наступним чином. У цьому прикладі існує 1 запис A на IP-адресу. Однак порт є унікальним для кожної адреси і представлений через пев ну конфігурацію DNS, що пов'язує адресу SRV з правильним портом.

nslookup -type=srv _sips._tcp.trunk.miami.custa.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custa.sip.telsp.com = 3600 50 5061 miami.sip.telsp.com

nslookup -type=srv _sips._tcp.trunk.miami.custb.sip.telsp.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_sips._tcp.trunk.miami.custb.sip.telsp.com = 3600 50 5062 miami.sip.telsp.com

Для магістралей на основі SRV ідентичність сертифіката Peer спочатку заповнюється з налаштованих значень SRV і може бути налаштована відповідно до тих самих правил перевірки.

Партнер володіє telsp.com і його субдоменами. Тому DNS-сервер і повнова ження отримувати сертифікати підписані затвердженим органом сертифікатів лежить у партнера.

• Cisco Webexочікує, що партнер опублікує адресу FQDN або SRV, включаючи записи A у відкритому доступі.

• Cisco Webexочікує, що партнер скористається одним із органів сертифікації, зазначених у цьому документі.

При налаштуванні магістралей за допомогою FQDN або SRV:

• Кожен магістраль повинен мати унікальний FQDN для маршрутизації та ідентифікації

• Записи DNS (запис A або SRV) повинні бути правильно налаштовані та розв'язані

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

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

Налаштування шлюзу

Використовуйте ці ресурси для налаштування локального шлюзу.

Щоб налаштувати Cisco CUBE, скористайтеся цією процедурою: Н алаштування локального шлюзу на Cisco IOS XE для Webex Calling

Ви можете налаштувати схвалені сторонні SBC, див.: Початок роботи з локальним шлюзом

Налаштуйте шлюз, розміщений партнерами, відповідно до наступних рекомендацій: Поч аток роботи з локальним шлюзом

Встановлюйте кожен багажник відповідно до відповідної інструкції до пристрою SBC. Щоб отримати інструкції Cisco CUBE, див. розділ: Н алаштування локального шлюзу на Cisco IOS XE для Webex Calling

Налаштуйте класи голосу, наберіть однолітні групи та наберіть групи однорантів для вхідного та вихідного трафіку для магістралі відповідно до зображення:

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

Під час налаштування магістралей у Центрі керування визначте ідентифікацію Peer cert, щоб увімкнути використання єдиного сертифіката для вашого домену верхнього рівня у всіх організаціях клієнтів . Переконайтеся, що CN або SAN сертифіката включає цей домен верхнього рівня. За допомогою ідентифікації Peer cert локальний шлюз використовує єдиний сертифікат, CN або SAN якого містить спільний домен партнера (наприклад, sip.telsp.com). Сертифікати підстановки (наприклад, *.sip.telsp.com) не підтримуються. Webex Callingприймає цей сертифікат для кожного магістралі клієнта, явно налаштованого з цим значен ням як ідентифікатором Peer cert. Сертифікат повинен містити точно налаштоване значення ідентичності Peer cert у своєму CN або SAN. Це виключає необхідність налаштування окремих сертифікатів або записів CN/SAN для окремих магістральних FQDN.

Перевірка домену та використання сертифікатів

Важливо розуміти, чим відрізняється перевірка домену від використання сертифікатів:

• Перевірка домену (на клієнта) —Кожна організація-клієн т повинна самостійно перевірити домен (наприклад, sip.telsp.com), додавши унікальний запис T XT в DNS. Це гарантує, що партнер володіє доменом і запобігає несанкціонованому використанню.

• Керування сертифікатами (глобальний) — єдиний сертифікат, виданий для домен у верхнього рівня партнера, може бути наданий у всіх магістралях клієнтів за допомогою ідентифікації Peer cert. Немає вимоги зберігати окремі сертифікати на кожного клієнта або на багажник.

Поведінка ідентичності сертифікатів однолітків

Ідентичність сертифіката однорангового сертифіката визначає іденти Webex Calling чність, яку очікує в сертифікаті, представленому локальним шлюзом.

При налаштуванні:

• Webex Callingпідтверджує сертифікат шляхом узгодження налаштованого ідентифікатора Peer cert з CN або SAN у сертифікаті

• Якщо значення збігаються, підключення TLS приймається

• Якщо значення не збігаються, з'єднання відхиляється

Тільки магістралі, явно налаштовані з відповідною ідентифікацією сертифіката Peer, можуть здійснювати ав тентифікацію.

Сама перевірка сертифіката не є єдиною перевіркою, що виконується під час аутентифікації. О крім перевірки сертифіката CN або SAN відповідно до налаштованої ідентичності Peer cert, він Webex Calling також перевіряє, чи магістральний FQDN явно налаштовано та пов'язано з відповідною ідентифікацією сертифіката однорангового сертифіката в Центрі керування.

Ідентичність сертифікату Peer попередньо заповнюється за основними значеннями FQDN/SRV. Якщо ви збережете типові значення, поведінка існуючого сертифіката для кожного магістралі не зміниться. Існуючі стовбу ри на основі сертифікатів продовжують працювати без змін. Ви можете прийняти спільну ідентичність сертифікації Peer на нових або існуючих стовбурах у своєму власному темпі, і обидві моделі можуть співіснувати.

1. Допустимий приклад конфігурації:

   • Сертифікат CN —sip.tel sp.com

   • Сертифікат SAN —custa.sip. telsp.com

   • Ідентичність сертифіката однолітків —custa.sip.telsp.com

   • Багажник FQDN — магістрал.міамі.куста.sip.telsp.com

   Результат — Підключення досягається успіхом, оскільки ідентичність сертифіката однорангового сертифіката (custa.sip.telsp.com) відповідає значенню SAN у сертифікаті, а основний FQDN (trunk.miami.custa.sip.telsp.com) є піддоменом налаштованої ідентичності сертифіката однорангового сертифіката.

2. Приклад збою підключення:

   • Сертифікат CN —sip.tel sp.com

   • Сертифікат SAN —custa.sip. telsp.com

   • Ідентичність сертифіката однолітків —custb.sip.telsp.com

   • Багажник FQDN — магістрал.міамі.custb.sip.telsp.com

   Результат — з'єднання не вдається при рукостисканні TLS, оскільки ідентичність сертифіката однорангового сертифіката (custb.sip.telsp.com) відсутня в CN або SAN сертифіката. Основний FQDN корек тно є піддоменом ідентичності Peer cert, але сертифікат не має цієї ідентичності.

3. Невірний приклад конфігурації:

   • Сертифікат CN —sip.tel sp.com

   • Сертифікат SAN —custa.sip. telsp.com

   • Ідентичність сертифіката однолітків —custa.sip.telsp.com

   • Багажник FQDN — магістрал.міамі.custb.sip.telsp.com

   Результат — Центр керування відхиляє цю конфігурацію під час збереження, оскільки магістральний FQDN (trunk.miami.custb.sip.telsp.com) не дорівнює або є піддоменом налаштованого ідентифікатора Peer Certificate (custa.sip.telsp.com).

З Центру партнерів ви можете запустити Контрольний центр для CUSTa або CustB та налаштувати шлюз. Скористайтеся цією процедурою, щоб налаштувати для кожного клієнта:

1. Створіть магістраль. Додайте магістраль у розділі Дзвінки/Маршрутизація викликів/магістраль для кожного спільного шлюзу партнера. Щоб налаштувати магістраль, див. розділ Налаш тування магістралей, груп маршрутів та планів набору номерів для Webex Calling

2. Додати домен і перевірити. Додайте та перевірте наступний домен, який використовується для створення магістралі в розділі Керування/Параметри організації/Домен и.

   КлієнтB	КлієнтiRC
   сайп.телсп.com	сайп.телсп.com

   При додаванні домену створюється маркер і поміщається в запис TXT для домену на DNS-сервері партнера. Цей запис дозволяє Control Hub перевіряти, що до мен належить партнеру. Докладніші відомості див. у розділі Керування доменами

   Загальний домен використовується для перевірки кожного клієнта. Однак, оскільки ця перевірка відбувається на рівні організації клієнта, переконайтеся, що для кожної організаці ї-клієнта генерується та використовується інший токен для перевірки. Оскільки один домен використовується в організаціях клієнтів, і кожна організація-клієнт повинна самостійно перевіряти домен за допомогою унікального запису TXT, навіть якщо спільний домен використовується.

   Для ідентифікації Peer cert потрібна лише перевірка домену. Не претендуйте на спільний домен в організації-замовника. Домен може претендувати лише однією організацією, тоді як один і той же домен може бути перевірений у кількох організаціях.

3. Налаштуйте адресу SBC за допомогою FQDN—

   Для шлюзу Майамі:

   Параметр	КлієнтB	КлієнтiRC
   Розташування	Денвер	Бостон
   Назва багажника	багажник_майамі	багажник_майамі
   Тип багажника	На основі сертифіката	На основі сертифіката
   Тип пристрою	напр Cisco Unified Border Element(або інший підтримуваний пристрій)	напр Cisco Unified Border Element(або інший підтримуваний пристрій)
   Тип адреси SBC	FQDN	FQDN
   Ім'я хоста	lgw.майамі	lgw.майамі
   Домен	сайп.телсп.com	сайп.телсп.com
   Порт	5061	5062
   FQDN	льгв.майамі.замовник.сіп.телсп.com:5061	льгв.майамі.замовник.сіп.телсп.com:5062
   Максимальна кількість одночасних дзвінків (250-6500)	500	500

   Для шлюзу Чикаго:

   Параметр	КлієнтB	КлієнтiRC
   Розташування	Детройт	Даллас
   Назва багажника	багажник_чикаго	багажник_чикаго
   Тип багажника	На основі сертифіката	На основі сертифіката
   Тип пристрою	напр Cisco Unified Border Element(або інший підтримуваний пристрій)	напр Cisco Unified Border Element(або інший підтримуваний пристрій)
   Тип адреси SBC	FQDN	FQDN
   Ім'я хоста	lgw.чикаго	lgw.чикаго
   Домен	сайп.телсп.com	сайп.телсп.com
   Порт	5061	5062
   FQDN	льгв.чикаго.замовник.сіп.телсп.com:5061	LGW.Chicago.Customerc.sip.telsp.com:5062
   Максимальна кількість одночасних дзвінків (250-6500)	500	500

   • (Необов'язково) Назви магістралей не повинні бути унікальними в організаціях клієнтів. Повторне використання однойменної назви (наприклад, trunk_miami) полегшує відстеження багажника.

   • Деякі SBC дозволяють налаштувати той самий порт, але ця конфігурація може вплинути на ємність. Тому використовуйте різні порти.

4. Ідентичність сертифіката однолітків—

   • Префікс — Префікс необов'язковий. Залиште його порожнім, щоб встановити ідентичність сертифікату Peer лише для домену. Це модель спільного сертифіката, яка використовується в цій статті (ідентичність сертифікатів Peer — sip.tel sp.com, що охоплює всі стовбури клієнтів). За бажанням введіть префікс для визначення більш конкретного ідентифікатора сертифіката (наприклад, префікс: CustomerB, Домен: Customerb.sip.telsp.com для сертифіката для кожного клієнта). Сам магістральний FQDN залишається визначеним адресою SBC іменем хоста та полями домену і повинен дорівнювати або дорівнювати піддомену отриманої ідентичності сертифікату Peer.

     Приклад:

     Префікс-замовникB

     Домен—sip.telsp.com

     Результ—замовник.sip.telsp.com

   • Домен: Виберіть домен зі списку доменів, перевірених в організації-замовника. Отриманий ідентифікатор Peer cert (префікс + домен) повинен відповідати CN або SAN сертифіката, який представляє ваш SBC. Webex Callingвикористовує це значення для автентифікації з'єднання TLS.

     

     Контрольний центр відхиляє цю конфігурацію під час економії, оскільки основний FQDN не відповідає налаштованому ідентифікатору Peer cert.

     Якщо ідентифікація Peer cert не відповідає CN або SAN у сертифікаті, представленому SBC, Webex Calling відхиляє з'єднання TLS, і магістраль не встановлюється.

5. Використання багажників — Виберіть будь-яке довільне місце для багажника, завдяки наступному:

   • Будь-яке місце може використовувати магістраль у з'єднанні PSTN.

   • Ви можете отримати доступ до магістралі через групу маршрутів.

   • Будь-який план циферблата може використовувати багажник.

6. Перегляньте визначення магістралі з пов'язаними розташуваннями:

   

   Ці стовбури можна використовувати для створення груп маршрутів. На зображенні визначено групу маршрутів rg_miami_chicago, яка спрямовує виклики до магістралі trunk_ miami як основний параметр та до магі стралі trunk_ chicago як вторинний параметр.

   

   Ви можете визначити другу групу маршрутів rg_chicago_miami, яка спрямовує виклики до магістралі trunk_chicago як основний параметр і до магістралі trunk_ miami як вторинний параметр.

7. Визначені магістралі та групи маршрутів тепер доступні у параметрі PSTN виклику з'єднання для кожного місцезнаходження. На зображенні дивіться місцезнаходження Денвер а.

   

8. Ви можете використовувати стовбури та групи маршрутів у визначенні плану набору номера. Наприклад, локальний діапазон номерів у Чикаго для клієнта розділений, щоб завершити групу маршрутів rg_chicago_miami (для всіх місць) на зображенні:

   

   

Надання у масштабі за допомогою API

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

• Перевірка домену

• Маршрутизація дзвінків