Планирование обхода сервера-посредника с прямой маршрутизацией
Сведения об обходе мультимедиа с помощью прямой маршрутизации
Обход мультимедиа позволяет сократить путь трафика мультимедиа и уменьшить количество прыжков при передаче для повышения производительности. При обходе мультимедиа носитель хранится между пограничным контроллером сеансов (SBC) и клиентом вместо отправки через Телефонная система Microsoft Teams. Чтобы настроить обход мультимедиа, SBC и клиент должны находиться в одном расположении или сети.
Вы можете управлять обходом мультимедиа для каждого SBC с помощью команды Set-CSOnlinePSTNGateway с параметром -MediaBypass , равным true или false. Если включить обход мультимедиа, это не означает, что весь мультимедийный трафик останется в корпоративной сети. В этой статье описывается поток вызовов в разных сценариях.
На приведенных ниже схемах показана разница в потоке вызовов с обходом и без нее.
Без обхода посредника, когда клиент выполняет или принимает вызов, сигнальные и мультимедийные потоки между SBC, Телефонная система Microsoft Teams и клиентом Teams, как показано на следующей схеме:
Но предположим, что пользователь находится в том же здании или сети, что и SBC. Например, предположим, что пользователь, который находится в здании во Франкфурте, звонит пользователю ТСОП:
Без обхода мультимедиа мультимедиа будут проходить через Амстердам или Дублин (где развернуты центры обработки данных Майкрософт) и обратно в SBC во Франкфурте.
Центр обработки данных в Европе выбран, так как SBC находится в Европе, а корпорация Майкрософт использует ближайший к SBC центр обработки данных. Хотя этот подход не влияет на качество вызовов из-за оптимизации потока трафика в сетях Майкрософт в большинстве географических регионов, трафик имеет ненужный цикл.
При обходе мультимедиа носитель хранится непосредственно между пользователем Teams и SBC, как показано на следующей схеме:
Обход мультимедиа использует протоколы интерактивного создания подключения (ICE) в клиенте Teams и ICE lite в SBC. Эти протоколы позволяют прямой маршрутизации использовать наиболее прямой путь к мультимедиа для оптимального качества. ICE и ICE Lite являются стандартами WebRTC. Подробные сведения об этих протоколах см. в статье RFC 5245.
Планирование потока вызовов и брандмауэра
Планирование потока вызовов и брандмауэра зависит от того, имеет ли пользователь прямой доступ к общедоступному IP-адресу SBC и находится ли пользователь в сети или за ее пределами.
Поток вызовов, если у пользователя есть прямой доступ к общедоступному IP-адресу SBC
Если пользователь имеет прямой доступ к общедоступному IP-адресу SBC, поток вызовов выглядит следующим образом:
Для обхода мультимедиа клиент Teams должен иметь доступ к общедоступному IP-адресу SBC даже из внутренней сети. Если прямой носитель не требуется, он может передаваться через ретрансляторы транспорта.
Этот поток рекомендуется, если пользователь находится в том же здании и (или) сети, что и SBC. Удалите компоненты Microsoft Cloud из пути к носителю.
Сигнализация всегда проходит через облако Майкрософт.
На следующей схеме показан поток вызовов, когда включен обход сервера-посредника, клиент является внутренним и клиент может связаться с общедоступным IP-адресом SBC (прямой носитель):
Стрелки и числовые значения путей соответствуют потокам вызовов Microsoft Teams.
Сигнал sip всегда принимает пути 4 и 4' (в зависимости от направления трафика). Носитель остается локальным и проходит путь 5b.
Поток вызовов, если у пользователя нет доступа к общедоступному IP-адресу SBC
В следующем сценарии описывается поток вызовов, если у пользователя нет доступа к общедоступному IP-адресу SBC.
Например, предположим, что пользователь является внешним, и администратор клиента решил не открывать общедоступный IP-адрес SBC для всех пользователей в Интернете, а только в Microsoft Cloud. Внутренние компоненты трафика могут передаваться через транспортные ретрансляторы Teams. Примите во внимание следующее:
Используются транспортные ретрансляторы Teams.
Для обхода мультимедиа корпорация Майкрософт использует версию транспортных ретрансляторов, которая требует открытия портов от 50 000 до 59 999 между транспортными ретрансляторами Teams и SBC (в будущем мы планируем перейти на версию, требующую портов 3478–3481).
На следующей схеме показан поток вызовов, когда включен обход мультимедиа, клиент является внешним, а клиент не может связаться с общедоступным IP-адресом пограничного контроллера сеансов (носитель ретранслятором транспорта Teams).
Стрелки и числовые значения путей соответствуют потокам вызовов Microsoft Teams.
Мультимедиа ретранслируются по путям 3, 3', 4 и 4'.
Поток вызовов, если пользователь находится за пределами сети и имеет доступ к общедоступному IP-адресу SBC
Примечание.
Эта конфигурация не рекомендуется, так как она не использует преимущества транспортных ретрансляторов Teams. Вместо этого следует рассмотреть предыдущий сценарий, в котором у пользователя нет доступа к общедоступному IP-адресу SBC.
На следующей схеме показан поток вызовов, когда включен обход сервера-посредника, клиент является внешним и клиент может связаться с общедоступным IP-адресом SBC (прямой носитель).
Стрелки и числовые значения путей соответствуют статьям о потоках вызовов Microsoft Teams .
Сигнал sip всегда принимает пути 3 и 3' (в зависимости от направления трафика). Потоки мультимедиа, использующие путь 2.
Использование обработчиков мультимедиа и транспортных ретрансляторов
В Microsoft Cloud есть два компонента, которые могут находиться в пути трафика мультимедиа: процессоры мультимедиа и транспортные ретрансляторы.
Обработчик мультимедиа — это общедоступный компонент, который обрабатывает мультимедиа в случаях без обхода и обрабатывает мультимедиа для голосовых приложений.
Обработчики мультимедиа всегда находятся в пути для вызовов без обхода пользователем, но никогда не находятся в пути для объеденных вызовов. Обработчики мультимедиа всегда находятся в пути для всех голосовых приложений, таких как парк вызовов, автосекретарь организации и очереди вызовов.
Транспортный ретранслятор используется для подключения к ближайшей транспортной службе для отправки трафика в режиме реального времени.
Транспортные ретрансляторы могут находиться в пути для обходных вызовов, исходящих от пользователей или предназначенных для конечных пользователей, в зависимости от того, где находится пользователь и как настроена сеть.
На следующей схеме показаны два потока вызовов: один с включенным обходом мультимедиа, а второй с отключенным обходом мультимедиа.
Примечание.
На схеме показан только трафик, исходящий от пользователей или предназначенный для конечных пользователей.
Контроллер мультимедиа — это микрослужба в Azure, которая назначает обработчики мультимедиа и создает предложения по протоколу описания сеансов (SDP).
Прокси-сервер SIP — это компонент, который преобразует сигналы REST HTTP, используемые в Teams, в SIP.
В следующей таблице представлена разница между обработчиками мультимедиа и ретрансляторами транспорта.
| Обработчики мультимедиа | Ретрансляторы транспорта | |
|---|---|---|
| В пути к мультимедиа для вызовов без обхода для конечных пользователей | Всегда | Если клиент не может напрямую связаться с обработчиком мультимедиа |
| В пути к мультимедиа для обходных вызовов для конечных пользователей | Нвер | Если клиенту не удается связаться с SBC по общедоступному IP-адресу |
| В пути к мультимедиа для голосовых приложений | Всегда | Нвер |
| Может выполнять перекодирование (B2BUA)* | Да | Нет, только ретрансляция звука между конечными точками |
Диапазоны IP-адресов:
- 52.112.0.0/14 (IP-адреса с 52.112.0.0 до 52.115.255.255)
- 52.120.0.0/14 (IP-адреса с 52.120.0.0 до 52.123.255.255)
Примечание.
Диапазоны IP-адресов, представленные в этом документе, относятся к прямой маршрутизации и могут отличаться от рекомендуемых для клиента Teams.
* Объяснение перекодирования:
Обработчик мультимедиа — это B2BUA, что означает, что он может изменять кодеки (например, silk from Teams client to MP и G.711 — mp и SBC).
Транспортные ретрансляторы не являются B2BUA, что означает, что кодек никогда не изменяется между клиентом и SBC, даже если трафик проходит через ретрансляторы.
Использование обработчиков мультимедиа Teams, если магистраль настроена для обхода мультимедиа
Обработчики мультимедиа Teams всегда вставляются в путь к носителю в следующих сценариях:
- Вызов перерасти с 1:1 на групповой вызов
- Вызов будет выполняться для федеративного пользователя Teams
- Вызов переадресован или передается пользователю Skype для бизнеса
Убедитесь, что SBC имеет доступ к диапазонам обработчиков мультимедиа и транспортных ретрансляторов, как описано ниже.
Сигнал sip: полные доменные имена
Для передачи сигналов SIP требования к полному доменному имени и брандмауэру совпадают с требованиями для случаев без обхода.
Прямая маршрутизация доступна в следующих средах Microsoft 365 или Office 365:
- Microsoft 365 или Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
Узнайте больше о средах Office 365 и государственных организаций США, таких как GCC, GCC High и DoD.
Microsoft 365, Office 365 и Office 365 среды GCC
Точками подключения для прямой маршрутизации являются следующие три полных доменных имени:
сначала необходимо попробовать sip.pstnhub.microsoft.com — глобальное полное доменное имя. Когда SBC отправляет запрос на разрешение этого имени, DNS-серверы Microsoft Azure возвращают IP-адрес, указывающий на основной центр обработки данных Azure, назначенный SBC. Назначение основано на метриках производительности центров обработки данных и географической близости к SBC. Возвращенный IP-адрес соответствует основному полному доменному имени.
sip2.pstnhub.microsoft.com — дополнительное полное доменное имя — географически сопоставляется со вторым приоритетным регионом.
sip3.pstnhub.microsoft.com — третичное полное доменное имя — географически сопоставляется с третьим приоритетным регионом.
Эти три полных доменных имени необходимо разместить в следующих целях:
Обеспечение оптимального взаимодействия (менее загруженное и ближайшее к центру обработки данных SBC, назначенному путем запроса первого полного доменного имени).
Обеспечение отработки отказа при установке подключения из SBC к центру обработки данных, в котором возникает временная проблема. Дополнительные сведения см. в разделе Механизм отработки отказа ниже.
Полные доменные имена sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com и sip3.pstnhub.microsoft.com будут разрешаться в IP-адреса из следующих подсетей:
- 52.112.0.0/14
- 52.120.0.0/14
Необходимо открыть порты для всех этих диапазонов IP-адресов в брандмауэре, чтобы разрешить входящий и исходящий трафик на адреса и из них для сигнализации.
Office 365 среде GCC DoD
Точка подключения для прямой маршрутизации — это следующее полное доменное имя:
sip.pstnhub.dod.teams.microsoft.us — глобальное полное доменное имя. Так как среда Office 365 DoD существует только в центрах обработки данных США, вторичные и третичные полные доменные имена отсутствуют.
Полное доменное имя sip.pstnhub.dod.teams.microsoft.us будет разрешено в IP-адрес из следующей подсети:
- 52.127.64.0/21
Необходимо открыть порты для всех этих диапазонов IP-адресов в брандмауэре, чтобы разрешить входящий и исходящий трафик на адреса и из них для сигнализации. Если брандмауэр поддерживает DNS-имена, полное доменное имя sip.pstnhub.dod.teams.microsoft.us разрешается во все эти IP-подсети.
Office 365 среда GCC High
Точка подключения для прямой маршрутизации — это следующее полное доменное имя:
sip.pstnhub.gov.teams.microsoft.us — глобальное полное доменное имя. Так как среда GCC High существует только в центрах обработки данных США, вторичные и третичные полные доменные имена отсутствуют.
Полное доменное имя sip.pstnhub.gov.teams.microsoft.us будет разрешено в IP-адрес из следующей подсети:
- 52.127.88.0/21
Необходимо открыть порты для всех этих диапазонов IP-адресов в брандмауэре, чтобы разрешить входящий и исходящий трафик на адреса и из них для сигнализации. Если брандмауэр поддерживает DNS-имена, полное доменное имя sip.pstnhub.gov.teams.microsoft.us разрешается во все эти IP-подсети.
Сигнал sip: порты
Требования к портам одинаковы для всех Office 365 сред, в которых предлагается прямая маршрутизация:
- Microsoft 365 или Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
Необходимо использовать следующие порты:
| Трафика | От | До | Исходный порт | Конечный порт |
|---|---|---|---|---|
| SIP/TLS | Прокси-сервер SIP | SBC | 1024 - 65535 | Определяется в SBC |
| SIP/TLS | SBC | Прокси-сервер SIP | Определяется в SBC | 5061 |
Трафик мультимедиа: диапазоны IP-адресов и портов
Трафик мультимедиа проходит между SBC и клиентом Teams, если доступно прямое подключение или через транспортные ретрансляторы Teams, если клиент не может связаться с SBC с помощью общедоступного IP-адреса.
Требования к прямому медиа-трафику (между клиентом Teams и SBC)
Клиент должен иметь доступ к указанным портам (см. таблицу) по общедоступному IP-адресу SBC.
Примечание.
Если клиент находится во внутренней сети, носитель передается на общедоступный IP-адрес SBC. Вы можете настроить закрепление волос на устройстве NAT, чтобы трафик никогда не покидал корпоративное сетевое оборудование.
| Трафика | От | До | Исходный порт | Конечный порт |
|---|---|---|---|---|
| UDP/SRTP | Клиент | SBC | 50000-50019 | Определяется в SBC |
| UDP/SRTP | SBC | Клиент | Определяется в SBC | 50000-50019 |
Примечание.
Если у вас есть сетевое устройство, которое преобразует исходные порты клиента, убедитесь, что переведенные порты открыты между сетевым оборудованием и SBC.
Требования к использованию транспортных ретрансляторов
Транспортные ретрансляторы находятся в том же диапазоне, что и обработчики мультимедиа (для случаев без обхода):
Microsoft 365, Office 365 и Office 365 среды GCC
- 52.112.0.0 /14 (IP-адреса от 52.112.0.1 до 52.115.255.254)
Office 365 среде GCC DoD
- 52.127.64.0/21
Office 365 среда GCC High
- 52.127.88.0/21
Диапазон портов транспортных ретрансляторов Teams (применимо ко всем средам) показан в следующей таблице:
| Трафика | От | До | Исходный порт | Конечный порт |
|---|---|---|---|---|
| UDP/SRTP | Транспортный ретранслятор | SBC | 50000–59999 | Определяется в SBC |
| UDP/SRTP | SBC | Транспортный ретранслятор | Определяется в SBC | 50000–59999, 3478-3481 |
Примечание.
Корпорация Майкрософт рекомендует по крайней мере два порта на один одновременный вызов в SBC. Так как корпорация Майкрософт использует две версии транспортных ретрансляторов, необходимо следующее:
версия 4, которая может работать только с диапазоном портов от 50000 до 59999
версия 6, которая работает с диапазоном портов от 3478 до 3481
Требования к использованию обработчиков мультимедиа
Обработчики мультимедиа всегда находятся в пути мультимедиа для голосовых приложений и веб-клиентов (например, клиентов Teams в Microsoft Edge или Google Chrome). Требования те же, что и для конфигурации без обхода.
Диапазон IP-адресов для трафика мультимедиа:
среды GCC для Office 365 и Office 365
- 52.112.0.0 /14 (IP-адреса от 52.112.0.1 до 52.115.255.254)
Office 365 среде GCC DoD
- 52.127.64.0/21
Office 365 среда GCC High
- 52.127.88.0/21
Диапазон портов обработчиков мультимедиа (применимо ко всем средам) показан в следующей таблице:
| Трафика | От | До | Исходный порт | Конечный порт |
|---|---|---|---|---|
| UDP/SRTP | Обработчик мультимедиа | SBC | 3478-3481 и 49152–53247 | Определяется в SBC |
| UDP/SRTP | SBC | Обработчик мультимедиа | Определяется в SBC | 3478-3481 и 49152–53247 |
Настройка отдельных магистралей для обхода сервера-посредника и обхода без посредников
Если вы переходите на обход мультимедиа с обхода, отличного от обхода мультимедиа, и хотите подтвердить функциональность перед переносом всего использования в обход мультимедиа, можно создать отдельную магистраль и отдельную политику маршрутизации голосовой связи через Интернет для маршрутизации в магистраль обхода мультимедиа и назначения определенным пользователям.
Общие шаги по настройке:
Определите пользователей для проверки обхода мультимедиа.
Создайте две отдельные магистрали с разными полными доменными именами: одно с поддержкой обхода мультимедиа; другой нет.
Оба магистрали указывают на один И тот же SBC. Порты для передачи сигналов SIP TLS должны отличаться. Порты для мультимедиа должны быть одинаковыми.
Создайте новую политику маршрутизации голосовой связи через Интернет и назначьте магистраль обхода мультимедиа соответствующим маршрутам, связанным с использованием ТСОП для этой политики.
Назначьте новую политику маршрутизации голосовой связи через Интернет пользователям, которых вы определили, для проверки обхода мультимедиа.
Эта логика показана в следующем примере.
| Набор пользователей | Число пользователей | Полное доменное имя магистрали, назначенное в OVRP | Включен обход мультимедиа |
|---|---|---|---|
| Пользователи с обходной магистралью без посредника | 980 | sbc1.contoso.com:5061 | false |
| Пользователи с обходной магистралью мультимедиа | 20 | sbc2.contoso.com:5060 | true |
Обе магистрали могут указывать на один SBC с тем же общедоступным IP-адресом. Порты передачи сигналов TLS в SBC должны отличаться, как показано на следующей схеме. Обратите внимание, что необходимо убедиться, что сертификат поддерживает обе магистрали. В SAN необходимо иметь два имени (sbc1.contoso.com и sbc2.contoso.com) или сертификат с подстановочными знаками.
Сведения о настройке двух магистралей в одном SBC см. в документации, предоставленной поставщиком SBC:
- Документация по развертыванию AudioCodes
- Документация по развертыванию Oracle
- Документация по развертыванию ленты Communications
- Документация по развертыванию TE-Systems (anynode)
Клиентские конечные точки, поддерживаемые обходом мультимедиа
Обход мультимедиа поддерживается всеми автономными классическими клиентами Teams, клиентами Android и iOS, а также устройствами Телефонная система Teams.
Для всех остальных конечных точек, которые не поддерживают обход мультимедиа, мы преобразуем вызов в non-bypass, даже если он запущен как обходной вызов. Это преобразование происходит автоматически и не требует никаких действий от администратора. Сюда входят Skype для бизнеса телефонов 3PIP и веб-клиентов Teams, поддерживающих прямые вызовы маршрутизации (клиенты на основе WebRTC, работающие в Microsoft Edge, Google Chrome, Mozilla Firefox).
См. также
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по