Поделиться через

Требования к инфраструктуре прямой маршрутизации Azure

  • Статья

В этой статье описываются сведения о подключении инфраструктуры, лицензирования и пограничного контроллера сеанса (SBC), которые необходимо учитывать в качестве плана развертывания прямой маршрутизации Azure.

Требования к инфраструктуре

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

Требование к инфраструктуре Вам потребуется
Пограничный контроллер сеансов (SBC) Поддерживаемый SBC. Дополнительные сведения см. в разделе Поддерживаемые SBC.
Магистрали телефонной связи, подключенные к SBC Одна или несколько магистралей телефонной связи, подключенные к SBC. На одном конце SBC подключается к Службам коммуникации Azure (ACS) через прямую маршрутизацию. SBC также может подключаться к сторонним сущностям телефонии, таким как PBXs, аналоговые адаптеры телефонии. Любой параметр подключения общедоступной телефонной сети (ТСОП), подключенный к SBC, работает. (для настройки магистралей ТСОП к SBC обратитесь к поставщикам SBC или поставщикам магистралей).
Подписка Azure. Подписка Azure, используемая для создания ресурса служб коммуникации, а также конфигурации и подключения к SBC.
Маркер доступа Служб коммуникации Для совершения вызовов вам необходим допустимый маркер доступа с областью voip. См. раздел Маркеры доступа.
Общедоступный IP-адрес для SBC Общедоступный IP-адрес, который можно использовать для подключения к SBC. В зависимости от типа SBC может использовать преобразование сетевых адресов (NAT).
Полное доменное имя (FQDN) для SBC Дополнительные сведения см. в разделе "Сертификаты SBC" и доменные имена.
Общедоступная запись DNS для SBC Общедоступная запись DNS сопоставляет полное доменное имя SBC с общедоступным IP-адресом.
Открытый доверенный сертификат для SBC Сертификат для SBC, используемый для обмена данными с прямой маршрутизацией Azure. Дополнительные сведения см. в разделе "Сертификаты SBC" и доменные имена.
IP-адреса и порты брандмауэра для сигналов и мультимедиа SIP SBC обменивается данными со следующими службами в облаке:

прокси-сервер SIP, который обрабатывает сигналы;
обработчик мультимедиа, который обрабатывает данные мультимедиа.

Эти две службы имеют отдельные IP-адреса в Microsoft Cloud, как описано далее в этом документе.

Сертификаты И доменные имена SBC

Корпорация Майкрософт рекомендует запрашивать сертификат для SBC с помощью запроса на подписывание сертификатов (CSR). Конкретные инструкции по созданию CSR для SBC см. в инструкциях или документации, предоставленной поставщиками SBC.

Примечание.

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

Сертификат должен иметь полное доменное имя SBC в качестве общего имени (CN) или альтернативного имени субъекта (SAN). Сертификат должен быть выдан непосредственно из центра сертификации, а не промежуточного поставщика.

Кроме того, прямая маршрутизация служб коммуникации поддерживает дикую карта в CN и /или SAN, а также дикую карта должны соответствовать стандарту RFC HTTP Over TLS.

Клиенты, которые уже используют Office 365 и зарегистрированы в Центре Администратор Microsoft 365, могут использовать полное доменное имя SBC из того же домена.

Например, можно использовать *.contoso.com, что соответствует полному доменному имени SBC sbc.contoso.com, но не sbc.test.contoso.com.

Примечание.

Полное доменное имя SBC в Службы коммуникации Azure прямой маршрутизации должно отличаться от полного доменного имени SBC в прямой маршрутизации Teams.

Службы коммуникации доверяют только сертификатам, подписанным центрами сертификации (ЦС), которые входят в программу доверенных корневых сертификатов Майкрософт. Убедитесь, что сертификат SBC подписан ЦС, который является частью программы, и что расширение расширенного использования ключей (EKU) сертификата включает проверку подлинности сервера. Подробнее:

Требования к программе — доверенные корневые программы Майкрософт

Включенный список сертификатов ЦС

Внимание

Службы коммуникации Azure прямая маршрутизация поддерживает только TLS 1.2. Чтобы избежать влияния на службу, убедитесь, что ваши SBCs настроены для поддержки TLS1.2 и могут подключаться с помощью одного из следующих наборов шифров для сигналов SIP:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 то есть ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 т. е. ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 т. е. ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 т. е. ECDHE-RSA-AES128-SHA256

Для носителей SRTP поддерживается только AES_CM_128_HMAC_SHA1_80.

Связывание SBC работает на уровне ресурсов служб коммуникации. Это означает, что можно связать множество SBC с одним ресурсом Служб коммуникации. Тем не менее, вы не можете связать один SBC с несколькими ресурсами Служб коммуникации. Для связывания с различными ресурсами требуются уникальные полные доменные имена SBC.

Если поддержка взаимной tls (MTLS) включена для прямого подключения маршрутизации в SBC, необходимо установить корневой каталог Baltimore CyberTrust и сертификаты DigiCert Global Root G2 в доверенном корневом хранилище SBC контекста TLS прямой маршрутизации. (Это связано с тем, что сертификаты службы Майкрософт используют один из этих двух корневых сертификатов.) Чтобы скачать эти корневые сертификаты, ознакомьтесь с цепочками шифрования Office 365. Дополнительные сведения см. в разделе "Изменения сертификата TLS Office".

Сигнал SIP: полное доменное имя

Точки подключения для прямой маршрутизации Служб коммуникации представлены следующими тремя полными доменными именами:

  • sip.pstnhub.microsoft.com — глобальное полное доменное имя — необходимо сначала попробовать. Когда SBC отправляет запрос на разрешение этого имени, DNS-серверы Microsoft Azure возвращают IP-адрес, указывающий на основной центр обработки данных Azure, назначенный SBC. Назначение основано на метриках производительности центров обработки данных и географической близости к SBC. Возвращенный IP-адрес соответствует основному полному доменному имени.
  • sip2.pstnhub.microsoft.com — дополнительное полное доменное имя — географически сопоставляется со вторым приоритетным регионом.
  • sip3.pstnhub.microsoft.com — полное доменное имя tertiary — географически сопоставляется с третьим приоритетным регионом.

Для выполнения этих трех полных доменных имен необходимо:

  • Обеспечение оптимального взаимодействия (менее загруженный и ближайший к SBC центр обработки данных назначается путем отправки запроса к первому полному доменному имени).
  • Обеспечение отработки отказа, если SBC подключается к центру обработки данных с временными проблемами. Дополнительные сведения см . в разделе "Механизм отработки отказа".

Полное доменное имя — sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com и sip3.pstnhub.microsoft.com — разрешается на один из следующих IP-адресов:

  • 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
  • 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

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

Сигнал SIP: порты

Используйте следующие порты для прямой маршрутизации Служб коммуникации:

Трафик С дт. По Исходный порт Порт назначения
SIP/TLS Прокси-сервер SIP SBC 1024–65535 Определен на SBC
SIP/TLS SBC Прокси-сервер SIP Определен на SBC 5061

Механизм отработки отказа для передачи сигналов SIP

SBC отправляет запрос DNS для разрешения sip.pstnhub.microsoft.com. В зависимости от расположения SBC и метрик производительности центра обработки данных выбирается основной центр обработки данных. Если основной центр обработки данных испытывает проблему, SBC пытается sip2.pstnhub.microsoft.com, которая разрешает второй назначенный центр обработки данных и, в редких случаях, когда центры обработки данных в двух регионах недоступны, SBC повторяет последнее полное доменное имя (sip3.pstnhub.microsoft.com), которое предоставляет ip-адрес третьего центра обработки данных.

Трафик мультимедиа: диапазоны IP-адресов и портов

Мультимедийный трафик передается в отдельную службу, которая называется обработчиком мультимедиа, и из нее. Диапазоны IP-адресов для трафика мультимедиа совпадают с сигналами:

  • 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
  • 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Диапазоны портов

Диапазоны портов процессоров мультимедиа показаны в следующей таблице:

Трафик С дт. По Исходный порт Порт назначения
UDP/SRTP Обработчик мультимедиа SBC 49152–53247 Определен на SBC
UDP/SRTP SBC Обработчик мультимедиа Определен на SBC 49152–53247

Примечание.

Корпорация Майкрософт рекомендует включить по меньшей мере два порта на каждый параллельный вызов на SBC.

Трафик мультимедиа: география обработчиков мультимедиа

Обработчики мультимедиа помещаются в те же центры обработки данных, что и прокси-серверы SIP:

  • NOAM (южная часть США, два в западной части США и восточная часть США)
  • Европа (Запад ЕС, Север ЕС, Швеция, Центральная Франция)
  • Азия (центр обработки данных Сингапура)
  • Япония (центры обработки данных в Восточной Японии и Западной Японии).
  • Австралия (центры обработки данных в Восточной Австралии и Юго-Восточной Австралии).
  • LATAM (Южная Бразилия)
  • Африка (Северная Африка)

Трафик мультимедиа: кодеки

Нога между SBC и облачным обработчиком мультимедиа.

Интерфейс прямой маршрутизации Azure на участке между пограничным контроллером сеансов и облачным обработчиком мультимедиа может использовать следующие кодеки:

  • SILK, G.711, G.722, G.729.

Вы можете принудительно использовать конкретный кодек на пограничном контроллере сеансов, исключив из предложения нежелательные кодеки.

Участок между приложением пакета SDK для вызовов Служб коммуникации и облачным обработчиком мультимедиа

На участке между облачным обработчиком мультимедиа и приложением пакета SDK для вызовов Служб коммуникации используется G.722. Работа над добавлением дополнительных кодеков на этом этапе выполняется.

Поддерживаемые пограничные контроллеры сеансов (SBC)

Следующие шаги

Концептуальная документация

Краткие руководства