Благодарим вас за обратную связь.

Рассмотрим гипотетического партнера Webex под названием TelSP, чтобы проиллюстрировать различные модели развертываний, которые этот партнер может использовать.

Ниже приведены основные спецификации и требования TelSP:

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

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

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

• У партнера есть два физических сайта, и оба этих сайта используют подключение к PSTN:

  • Майами

  • Чикаго

• TelSP управляет своими локальными шлюзами от имени двух клиентов CustA и CustB, как указано в настоящем документе.

Желательный сценарий заключается в том, чтобы оба клиента, использующие шлюзы Майами и Чикаго, предоставленные партнером, могли начать или прекратить работу PSTN, как показано на рисунке:

Пример упрощенного развертывания

В следующем упрощенном примере показано, как система идентификации одноранговых сертификатов позволяет использовать один сертификат для поддержки нескольких клиентских магистралей:

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

• Сундуки

  • custa.sip.telsp.com

  • custb.sip.telsp.com

• Удостоверение личности коллег — sip.telsp.com

• Результат

  • Используется один сертификат

  • Поддерживается несколько клиентских транков

Привязка местоположения клиента к магистрали и шлюзу

В следующих разделах представлены подробные сопоставления конфигураций для описанного выше развертывания.

Webex Callingпозволяет создавать магистрали и совместно использовать магистраль в нескольких местах. При создании магистрали свяжите магистраль с местоположением.

Для CustA сведения о магистрали следующие:

На рисунке показана связь местоположения клиента с Gateway и Trunk для CustA:

В этом развертывании магистраль, связанная с местоположением , является основным подключением PSTN для этого местоположения. Другая магистраль используется в качестве дополнительного PSTN-соединения или маршрута для определенных записей абонентского плана. Реализация взаимосвязи между основным и вторичным PSTN осуществляется с помощью концепции группы маршрутов. Подробнее см. в разделе Настройка магистралей шлюзов в разделе Control Hub.

Для CustB создана аналогичная настройка со следующими магистралями:

На рисунке показана связь местоположения клиента с Gateway и Trunk для CustB:

На рисунке показан третий населенный пункт, а именно Нью-Йорк, который можно добавить позже и указать магистраль trunk_chicago в качестве основного соединения PSTN.

При развертывании локального шлюза с несколькими магистралями Cisco предписывает использовать уникальное полное доменное имя для каждой магистрали. Дополнительные сведения см. в разделе Настройка магистралей, групп маршрутов и тарифных планов для 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-адреса каждая магистраль настраивается с использованием полного доменного имени в концентраторе управления и имеет уникальный порт.

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

Другой пример разрешения записи SRV выглядит следующим образом. В этом примере на каждый IP-адрес приходится 1 запись A. Однако порт уникален для каждого адреса и представлен в виде специальной конфигурации 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 идентификатор сертификата однорангового узла изначально формируется на основе настроенных значений SRV и может быть настроен в соответствии с теми же правилами проверки.

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

• Cisco Webexожидает, что партнер опубликует полное доменное имя или адрес SRV, включая записи A, в открытом доступе.

• Cisco Webexожидает, что партнер воспользуется услугами одного из центров сертификации, перечисленных в этом документе.

При настройке магистралей с использованием FQDN или SRV выполните следующие действия:

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

• Записи DNS (A Record или SRV) должны быть правильно настроены и разрешимы

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

  Поле «Идентификатор сертификата партнера» предварительно заполняется из полного доменного имени магистрали. Его можно заменить общим доменом, принадлежащим партнерам, для использования одного сертификата в нескольких клиентских магистралях.

Настройте шлюз

Используйте эти ресурсы для настройки локального шлюза.

Чтобы настроить Cisco CUBE, используйте следующую процедуру: Настройте локальный шлюз на Cisco IOS XE для Webex Calling

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

Настройте шлюз, размещенный партнером, в соответствии со следующими рекомендациями: Начните с локального шлюза

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

Настройте классы голоса, точки вызова и группы адресатов вызова для входящего и исходящего трафика магистрали, как показано на рисунке:

При подготовке магистрального канала Control Hub предоставляет возможность настроить идентификатор однорангового сертификата на странице «Добавить магистраль». Это усовершенствование упрощает рабочий процесс, позволяя партнерам настраивать и повторно использовать один домен верхнего уровня в нескольких организациях-заказчиках. Такой подход устраняет необходимость использования отдельных сертификатов для каждого клиента или магистрали, что снижает эксплуатационные затраты и упрощает процесс настройки.

При настройке магистралей в Control Hub определите идентификатор однорангового сертификата, чтобы во всех организациях-заказчиках можно было использовать один сертификат для домена верхнего уровня. Убедитесь, что CN или SAN сертификата включает этот домен верхнего уровня. В локальном шлюзе, использующем идентификацию однорангового сертификата, используется один сертификат, в CN или SAN которого содержится общий домен партнера (например, sip.telsp.com). Подстановочные сертификаты (например, *.sip.telsp.com) не поддерживаются . Webex Callingпринимает этот сертификат для каждой магистрали клиента, в которой это значение явно указано в качестве идентификатора сертификата партнера. Сертификат должен содержать точно настроенное значение идентификатора однорангового сертификата в CN или SAN. Это избавляет от необходимости настраивать отдельные сертификаты или записи CN/SAN для отдельных магистральных полных доменных имен.

Проверка домена и использование сертификатов

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

• Проверка домена (для каждого клиента). Каждая клиентская организация должна самостоятельно проверить домен (например, sip.telsp.com), добавив уникальную TXT-запись в DNS. Это гарантирует, что домен принадлежит партнеру, и предотвращает его несанкционированное использование.

• Управление сертификатами (глобальное). Один сертификат, выданный для домена верхнего уровня партнера, можно использовать во всех клиентских магистралях с помощью сертификата Peer Cert Identity. Нет необходимости хранить отдельные сертификаты для каждого клиента или для каждой магистрали.

Поведение при идентификации в соответствии с сертификатами коллег

Идентичность однорангового сертификата определяет идентификатор, Webex Calling ожидаемый от сертификата, представленного локальным шлюзом.

При настройке:

• Webex Callingпроверяет сертификат, сопоставляя настроенный идентификатор однорангового сертификата с CN или SAN в сертификате

• Если значения совпадают, соединение TLS принимается

• Если значения не совпадают, соединение отклоняется

Аутентификация разрешена только для магистралей, явно настроенных на совпадающий идентификатор сертификата однорангового узла.

Сама по себе проверка сертификата — это не единственная проверка, выполняемая во время аутентификации. Помимо проверки сертификата CN или SAN на соответствие настроенному идентификатору однорангового сертификата, Webex Calling также проверяется, что полное доменное имя магистрали явно настроено и связано с соответствующим идентификатором сертификата однорангового сервера в Control Hub.

Идентификатор однорангового сертификата предварительно заполняется на основе значений FQDN/SRV магистрали. Если вы сохраните значения по умолчанию, существующее поведение сертификатов по каждой магистрали останется неизменным. Существующие магистрали на основе сертификатов продолжают работать без изменений. Вы можете использовать общий идентификатор однорангового сертификата на новых или существующих магистралях в удобном для вас темпе, и обе модели могут сосуществовать.

1. Допустимый пример конфигурации:

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

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

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

   • Полное доменное имя магистрали — trunk.miami.custa.sip.telsp.com

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

2. Пример сбоя соединения:

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

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

   • Идентификатор однорангового сертификата — custb.sip.telsp.com

   • Полное доменное имя магистрали — trunk.miami.custb.sip.telsp.com

   Результат — соединение прерывается при рукопожатии по протоколу TLS из-за отсутствия идентификатора однорангового сертификата (custb.sip.telsp.com) в CN или SAN сертификата. Полное доменное имя магистрали правильно является субдоменом идентификатора сертификата однорангового сервера, но сертификат не содержит этого идентификатора.

3. Пример неправильной конфигурации:

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

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

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

   • Полное доменное имя магистрали — trunk.miami.custb.sip.telsp.com

   Результат — Control Hub отклоняет эту конфигурацию, чтобы сэкономить время, поскольку полное доменное имя магистрали (trunk.miami.custb.sip.telsp.com) не совпадает с настроенным идентификатором сертификата однорангового сервера (custa.sip.telsp.com) или не является его субдоменом.

В Центре партнеров можно запустить концентратор управления для CustA или CustB и настроить шлюз. Используйте следующую процедуру для настройки для каждого клиента:

1. Создайте транк — добавьте магистраль в разделе Вызовы/Маршрутизация вызовов/Транк для каждого совместного шлюза партнера. Сведения о настройке магистрали см. в разделе Настройка магистральных каналов, групп маршрутов и телефонных планов для Webex Calling

2. Добавьте домен и подтвердите — добавьте и подтвердите следующий домен, который используется для создания магистрали, в разделе Управление/Настройки организации/Домены.

   Клиент B	Клиент C
   sip.telsp.com	sip.telsp.com

   При добавлении домена генерируется токен, который помещается в TXT-запись домена на DNS-сервере партнера. Эта запись позволяет Control Hub подтвердить, что домен принадлежит партнеру. Подробнее см. в разделе Управление доменами

   Общий домен используется для верификации каждого клиента. Однако, поскольку эта проверка осуществляется на уровне организации-заказчика, убедитесь, что для проверки в каждой организации-заказчике создан и используется отдельный токен . Потому что в организациях-заказчиках используется один домен, и каждая организация-заказчик должна независимо проверять домен с помощью уникальной TXT-записи, даже если она используется совместно с одним и тем же доменом.

   Для идентификации однорангового сертификата требуется только верификация домена. Не передавайте общий домен организации-заказчику. На домен может претендовать только одна организация, в то время как один и тот же домен может быть проверен в нескольких организациях.

3. Настройте адрес SBC с помощью полного доменного имени—

   Для шлюза в Майами:

   Параметр	Клиент B	Клиент C
   Местоположение	Денвер	Бостон
   Название багажника	trunk_miami	trunk_miami
   Тип магистрали	На основе сертификата	На основе сертификата
   Тип устройства	например Cisco Unified Border Element(или другое поддерживаемое устройство)	например Cisco Unified Border Element(или другое поддерживаемое устройство)
   Тип адреса SBC	FQDN	FQDN
   Имя хоста	lgw.miami	lgw.miami
   домен	sip.telsp.com	sip.telsp.com
   Порт	5061	5062
   FQDN	lgw.miami.customerb.sip.telsp.com:5061	lgw.miami.customerc.sip.telsp.com:5062
   Максимальное количество одновременных вызовов (250-6500)	500	500

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

   Параметр	Клиент B	Клиент C
   Местоположение	Детройт	Даллас
   Название багажника	trunk_chicago	trunk_chicago
   Тип магистрали	На основе сертификата	На основе сертификата
   Тип устройства	например Cisco Unified Border Element(или другое поддерживаемое устройство)	например Cisco Unified Border Element(или другое поддерживаемое устройство)
   Тип адреса SBC	FQDN	FQDN
   Имя хоста	lgw.chicago	lgw.chicago
   домен	sip.telsp.com	sip.telsp.com
   Порт	5061	5062
   FQDN	lgw.Chicago. customerb.sip.telsp.com:5061	lgw.Chicago.customerc.sip.telsp.com:5062
   Максимальное количество одновременных вызовов (250-6500)	500	500

   • (Необязательно) Названия магистралей не обязательно должны быть уникальными в разных организациях-заказчиках. Повторное использование одного и того же имени (например, trunk_miami) упрощает отслеживание магистрали.

   • Некоторые SBC позволяют настраивать один и тот же порт, но такая конфигурация может повлиять на пропускную способность. Поэтому используйте разные порты.

4. Идентификация однорангового сертификата—

   • Префикс — префикс необязателен. Оставьте поле пустым, чтобы присвоить идентификационный номер однорангового сертификата только домену. Эта модель совместного сертификата используется в данной статье (идентификатор однорангового сертификата — sip.telsp.com, охватывающий все магистрали клиентов). При желании можно ввести префикс для определения более конкретного идентификатора сертификата (например, префикс: CustomerB, домен: CustomerB.sip.telsp.com для сертификата для каждого клиента). Само полное доменное имя магистрали по-прежнему определяется полями «Адрес SBC», «Имя хоста» и «Домен». Оно должно совпадать с полученным идентификатором сертификата партнера или являться его субдоменом.

     Пример:

     Префикс — CustomerB

     Домен — sip.telsp.com

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

   • Домен: выберите домен из списка доменов, проверенных в организации-заказчике. Полученный идентификатор однорангового сертификата (префикс + домен) должен соответствовать CN или SAN сертификата, предоставленного вашим SBC. Webex Callingиспользует это значение для аутентификации соединения TLS.

     

     Control Hub отклоняет эту конфигурацию, чтобы сэкономить время, поскольку полное доменное имя магистрали не соответствует настроенному идентификатору сертификата однорангового узла.

     Если идентификатор однорангового сертификата не совпадает с идентификатором сертификата CN или SAN в сертификате, представленном SBC, соединение TLS Webex Calling отклоняется, и магистраль не устанавливается.

5. Использование магистралей — выберите любое произвольное местоположение магистрали, учитывая следующее:

   • Магистраль можно использовать в любом месте для подключения к сети PSTN.

   • Доступ к магистрали можно получить через маршрутную группу.

   • Магистраль можно использовать в любом тарифном плане.

6. Ознакомьтесь с определениями магистралей и соответствующими местоположениями:

   

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

   

   Можно определить вторую группу маршрутов rg_chicago_miami, которая маршрутизирует вызовы на магистраль trunk_chicago в качестве основного варианта и на магистраль trunk_miami в качестве дополнительного варианта.

7. Определенные магистрали и группы маршрутов теперь доступны в опции Calling Connection PSTN для каждого местоположения. На изображении показано местоположение в Денвере.

   

8. В определении телефонного плана можно использовать магистрали и маршрутные группы. Например, диапазон локальных номеров в Чикаго для клиента разделен на маршрутную группу rg_chicago_miami (для всех населенных пунктов), как показано на рисунке:

   

   

Масштабируемое предоставление услуг с помощью API

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

• Подтвердите домен

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