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

Ось загальні характеристики & вимоги TelSP:

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

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

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

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

  • Маямі

  • Чикаго

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

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

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

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

Для CustA деталі транкеру такі:

На ілюстрації показано зв'язок розташування клієнта зі шлюзом та магістральною лінією для CustA:

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

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

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

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

Під час розгортання локального шлюзу, який спільно використовує кілька транків, Cisco РОБИТЬ використовувати унікальне повне доменне ім'я (FQDN) для кожного транку. Див. Налаштування транзитних ліній, груп маршрутів та планів набору для Webex Calling.

Використання 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

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

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

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

Якщо як адресу транкової лінії використовується повне доменне ім’я (FQDN), налаштуйте підписані сертифікати із значенням Загальне ім’я (CN) або Альтернативний номер суб’єкта (SAN) як повні доменні імена для транкових ліній.

Використайте один із цих методів для створення повних доменів (FQDN) у сертифікаті:

• Виберіть одне з FQDN як загальне ім'я (CN), а решту як альтернативний номер суб'єкта (SAN).

• Розмістіть домен верхнього рівня (sip.telsp.com) як CN, а всі FQDN як SAN.

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

Якщо як адресу транкової лінії використовується SRV, налаштуйте підписані сертифікати з CN або SAN на частину адреси SRV, що відповідає хосту. Запис A або CNAME, до якого звертається адреса SRV, не є обов'язковим.

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

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

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

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

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

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

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

З Центру партнерів ви можете запустити Центр керування для клієнта A або клієнта B та налаштувати шлюз. Використайте цю процедуру для налаштування для кожного клієнта:

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

2. Додати домен і перевірити – додати та перевірити наступний домен, який використовується для створення транку в розділі Management/Organization Settings/Domains.

   КлієнтA	КлієнтБ
   sip.telsp.com	sip.telsp.com

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

   Оскільки загальний домен використовується для перевірки кожного клієнта. Однак, оскільки ця перевірка відбувається на рівні організації клієнта, переконайтеся, що для кожної організації клієнта генерується та використовується окремий токен для перевірки. Оскільки один домен використовується в різних організаціях клієнтів, жодна організація не може претендувати на право власності на домен.
3. Налаштування адреси SBC з повним доменом (FQDN) —

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

   Параметр	КлієнтA	КлієнтБ
   Розташування	Денвер	Бостон
   Ім’я транка	trunk_miami	trunk_miami
   Тип багажника	На основі сертифіката	На основі сертифіката
   Тип пристрою	наприклад, Cisco Unified Border Element (або інший підтримуваний пристрій)	наприклад, Cisco Unified Border Element (або інший підтримуваний пристрій)
   Тип адреси SBC	Повне доменне ім’я	Повне доменне ім’я
   Ім’я хоста	trunk.miami.custa	trunk.miami.custb
   Домен	sip.telsp.com	sip.telsp.com
   Порт	5061	5062
   Повне доменне ім’я	trunk.miami.custa.sip.telsp.com:5061	trunk.miami.custb.sip.telsp.com:5062
   Максимальна кількість одночасних викликів (250-6500)	500	500

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

   Параметр	КлієнтA	КлієнтБ
   Розташування	Детройт	Даллас
   Ім’я транка	trunk_chicago	trunk_chicago
   Тип багажника	На основі сертифіката	На основі сертифіката
   Тип пристрою	наприклад, Cisco Unified Border Element (або інший підтримуваний пристрій)	наприклад, Cisco Unified Border Element (або інший підтримуваний пристрій)
   Тип адреси SBC	Повне доменне ім’я	Повне доменне ім’я
   Ім’я хоста	trunk.chicago.custa	trunk.chicago.custb
   Домен	sip.telsp.com	sip.telsp.com
   Порт	5061	5062
   Повне доменне ім’я	trunk.chicago.custa.sip.telsp.com:5061	trunk.chicago.custb.sip.telsp.com:5062
   Максимальна кількість одночасних викликів (250-6500)	500	500

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

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

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

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

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

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

5. Див. визначення магістральних ліній з пов'язаними розташуваннями:

   

   Ви можете використовувати ці транкінги для створення груп маршрутів. На зображенні визначено групу маршрутів rg_miami_chicago, яка спрямовує виклики до транку trunk_miami як основного параметра та до транку trunk_chicago як додаткового параметра.

   

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

6. Визначені групи транків та маршрутів тепер доступні в опції З’єднання для викликів PSTN для кожного розташування. На зображенні ви можете побачити розташування в Денвері.

   

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