Планирование оптимизации локального носителя для прямой маршрутизации
Голосовая связь с телефонной сетью общего пользования (ТСОП) считается критически важным для бизнеса приложением с высокими ожиданиями в отношении качества голосовой связи. Прямая маршрутизация для Телефонная система Microsoft Teams позволяет управлять потоками трафика мультимедиа для размещения множества сетевых топологий и локальных телефоний для различных предприятий по всему миру.
Оптимизация локального мультимедиа для прямой маршрутизации позволяет управлять качеством голосовой связи с помощью:
Управление тем, как трафик мультимедиа проходит между клиентами Teams и пограничными контроллерами сеансов (SBC).
Сохранение локального носителя в пределах подсетей корпоративной сети.
Разрешение потоков мультимедиа между клиентами Teams и SBC, даже если они находятся за корпоративными брандмауэрами с частными IP-адресами и не видны корпорации Майкрософт напрямую.
Локальная оптимизация мультимедиа поддерживает два сценария:
Централизация всех локальных магистралей через централизованный SBC, подключенный к магистрали SIP main. Этот сценарий предоставляет услуги телефонии для всех локальных филиалов компании.
Топология виртуальной сети SBC. В этом сценарии контроллеры SBC в локальных филиалах подключены к централизованному прокси-серверу SBC, который виден и взаимодействует с ним Телефонная система Teams через его внешний IP-адрес. В топологии виртуальной сети подчиненные SBC взаимодействуют через внутренние IP-адреса и не видны напрямую Телефонная система Teams.
В этой статье описаны функциональные возможности, сценарии и решения клиентов. Дополнительные сведения о конфигурации см. в разделе Настройка оптимизации локального носителя.
Примечание.
Если вы хотите сохранить носитель локальным в пределах интрасети, рекомендуется использовать оптимизацию локальных носителей. Однако если у вас уже есть обход мультимедиа и вы используете только общедоступные IP-адреса SBC, вам не нужно переходить на локальный медиа-оптимизации. Вы можете продолжать использовать обход мультимедиа. Дополнительные сведения см. в статье Планирование обхода сервера-посредника.
Сведения о том, какие поставщики SBC поддерживают оптимизацию локального носителя, см. в разделе Контроллеры границ сеансов, сертифицированные для прямой маршрутизации.
Поддерживаемые сценарии клиентов
Для этого обсуждения предположим, что contoso управляет несколькими компаниями по всему миру, как показано ниже. (Обратите внимание, что регионы Европы и APAC используются только в качестве примеров. У компании может быть несколько разных регионов с аналогичными требованиями.)
В Европе компания Contoso имеет офисы примерно в 30 странах и регионах. У каждого офиса есть собственный УАТС.
Компании Contoso была предложена возможность централизации магистралей в одном расположении - Амстердаме - для всех 30 европейских офисов. Компания Contoso развернула SBC в Амстердаме, обеспечила достаточную пропускную способность для выполнения вызовов через централизованное расположение, подключила центральную магистраль SIP к централизованному расположению и начала обслуживать все европейские расположения из Амстердама.
В регионе APAC компания Contoso имеет несколько офисов в разных странах или регионах.
Во многих странах и регионах компания по-прежнему имеет магистрали мультиплексирования по времени (TDM) в местных филиалах. Централизация магистралей TDM не является вариантом в регионе APAC, поэтому переключение на SIP невозможно. Предположим, что в регионе APAC имеется более 50 филиалов Contoso с сотнями шлюзов (SBC). В этом сценарии невозможно связать все шлюзы с интерфейсом прямой маршрутизации из-за отсутствия общедоступных IP-адресов и (или) локальных интернет-адресов. Кроме того, в некоторых странах и регионах применяются нормативные требования, которые невозможно выполнить без подключения к локальной сети ТСОП.
Основываясь на своих бизнес-требованиях, Компания Contoso реализовала два решения с оптимизацией локального мультимедиа для прямой маршрутизации:
В Европе все магистрали централизованы, а мультимедиа передаются между центральным SBC и пользователями в зависимости от расположения пользователя.
Если пользователь подключен к локальной подсети корпоративной сети (то есть пользователь является внутренним), мультимедиа передаются между внутренним IP-адресом центрального SBC и клиентом Teams пользователя.
Если пользователь находится за пределами корпоративной сети ( например, если пользователь использует общедоступное беспроводное подключение к Интернету), он считается внешним. В этом случае мультимедиа передаются между внешним IP-адресом центрального SBC и клиентом Teams.
В регионе APAC централизованный прокси-сервер SBC связан с прямой маршрутизацией (Майкрософт), которая направляет мультимедиа между интерфейсом прямой маршрутизации и подчиненными SBC в локальных филиалах.
Подчиненные SBC в локальных филиалах напрямую не видны прямой маршрутизации в APAC, но они объединяются с помощью командлета Set-CSOnlinePSTNGateway для создания топологии виртуальной сети в Телефонная система Teams. Носитель всегда остается локальным, когда это возможно. Внешние пользователи имеют мультимедиа, передаваемые между клиентом Teams и общедоступным IP-адресом прокси-сервера SBC.
Центральный SBC с централизованными магистрали
Чтобы создать решение, в котором службы ТСОП предоставляются всем локальным филиалам через единый центральный SBC с подключенной централизованной магистралью SIP, администратор клиента Contoso связывает один SBC (centralsbc.contoso.com) со службой. SBC имеет централизованную магистраль SIP, подключенную к нему.
Когда пользователь находится во внутренней сети компании, SBC предоставляет внутренний IP-адрес SBC для мультимедиа.
Если пользователь находится за пределами корпоративной сети, SBC предоставляет внешний (общедоступный) IP-адрес SBC.
Примечание.
Все значения в примерах, таблицах или схемах отображаются только в целях иллюстрации.
Таблица 1. Пример параметров сети для SBC
| Местоположение | Полное доменное имя SBC | Внутренняя подсеть | Внешний NAT (доверенный IP-адрес) | Внешний IP-адрес SBC | Внутренний IP-адрес SBC |
|---|---|---|---|---|---|
| Амстердам | centralsbc.contoso.com | 192.168.5.0/24 | 172.16.76.73 | 172.16.76.71 | 192.168.5.5 |
| Германия | Не развернуто | 192.168.6.0/24 | 172.16.76.74 | Не развернуто | Не развернуто |
| Франция | Не развернуто | 192.168.7.0/24 | 172.16.76.75 | Не развернуто | Не развернуто |
Внутренний пользователь
На следующей схеме показан поток трафика, когда пользователь подключен к корпоративной сети в домашнем филиале или на сайте пользователя.
В локальной среде пользователь назначается в местный филиал в Германии. Пользователь выполняет телефонный звонок с прямой маршрутизацией через Teams.
Клиент Teams пользователя взаимодействует с Телефонная система Teams напрямую через REST API, но носитель, созданный во время вызова, передается на внутренний IP-адрес центрального SBC.
SBC перенаправляет поток в Телефонная система Teams и подключенную сеть ТСОП.
Центральный SBC отображается для Телефонная система Teams только через внешний IP-адрес.
Схема 1. Поток трафика, когда пользователь находится на "домашнем" сайте с централизованным SBC и подключенной централизованной магистралью SIP
Внешний пользователь
На следующей схеме показан поток трафика, если пользователь не находится в локальной среде и не подключен к корпоративной сети (то есть устройство пользователя подключено к Интернету через мобильное устройство или общедоступный Wi-Fi). Пользователь выполняет телефонный звонок с прямой маршрутизацией через Teams:
Клиент Teams пользователя взаимодействует с Телефонная система Teams напрямую через REST API, но в этом случае носитель, созданный во время вызова, передается на внешний IP-адрес центрального SBC.
SBC перенаправляет поток в Телефонная система Teams и подключенную сеть ТСОП.
Центральный SBC отображается для Телефонная система Teams только через внешний IP-адрес.
В этом случае поведение аналогично тому, является ли пользователь локальным в филиале в Германии или в любом другом филиале. Пользователь считается внешним, так как он находится за пределами корпоративной сети.
Схема 2. Поток трафика, когда пользователь является внешним с централизованным SBC и подключенной централизованной магистралью SIP
Прокси-сервер SBC с подключенными подчиненными SBC
Чтобы создать решение, в котором службы ТСОП предоставляются во всех локальных филиалах в регионе APAC, где централизация магистралей TDM не является вариантом, администратор Contoso связывает один SBC (proxysbc.contoso.com), также называемый прокси-сервером SBC, со службой прямой маршрутизации.
После этого администратор Contoso добавляет несколько подчиненных SBC, указывая, что они могут быть доступны через прокси-proxysbc.contoso.com SBC. Подчиненные SBC не имеют общедоступных IP-адресов; однако они могут быть назначены голосовому маршруту. В таблице ниже приведены примеры параметров сети и конфигурации.
Когда пользователь находится в локальном филиале, где расположен подчиненный SBC, трафик мультимедиа напрямую передается между пользователем и локальным подчиненным SBC. Если пользователь находится за пределами офиса (в общедоступном Интернете), мультимедиа передаются от пользователя к общедоступному IP-адресу прокси-сервера SBC, который передает его в соответствующие подчиненные SBC.s.
Таблица 2. Пример сведений о сети SBC
| Местоположение | Полное доменное имя SBC | Внутренняя подсеть | Внешний NAT (доверенный IP-адрес) | Внешний IP-адрес SBC | Внутренний IP-адрес SBC |
|---|---|---|---|---|---|
| Вьетнам | VNsbc.contoso.com | 192.168.1.0/24 | 172.16.240.110 | Нет | 192.168.1.5 |
| Индонезия | IDsbc.contoso.com | 192.168.2.0/24 | 172.16.240.120 | Нет | 192.168.2.5 |
| Сингапур | proxysbc.contoso.com | 192.168.3.0/24 | 172.16.240.130 | 172.16.240.133 | 192.168.3.5 |
Внутренний пользователь
На следующей схеме показан высокоуровневый поток трафика для сценария, когда пользователь находится в офисе в регионе APAC. Пользователь, который назначен в местный филиал во Вьетнаме и находится в локальной среде, выполняет телефонный звонок с прямой маршрутизацией через Teams.
Клиент Teams пользователя взаимодействует с Телефонная система Teams напрямую через REST API, но мультимедиа, созданные во время вызовов, передаются на внутренний IP-адрес локального SBC.
Локальный SBC перенаправляет поток в прокси-сервер SBC в Сингапуре и в подключенную локальную сеть ТСОП.
Прокси-сервер SBC отображается для Телефонная система Teams только через внешний IP-адрес и направляет поток из подчиненного SBC (в данном случае локального SBC во Вьетнаме) в Телефонная система Teams.
Подчиненный SBC в локальном филиале не виден для Телефонная система Teams напрямую, но сопоставляется в топологии виртуальной сети, определенной администратором Contoso при настройке оптимизации локального носителя.
Примечание.
Поведение может отличаться для локальных пользователей и других пользователей в зависимости от настроенного режима оптимизации локального носителя.
Дополнительные сведения о возможных режимах и соответствующем поведении см. в разделе Настройка оптимизации локального носителя.
Схема 3. Поток трафика, когда пользователь находится в "домашней" сети с прокси-сервером SBC и подключенными подчиненными SBC
Внешний пользователь
На следующей схеме показан поток трафика, когда пользователь находится за пределами корпоративной сети. Пользователь не находится в локальной среде (не находится в пределах корпоративной сети). Пользователь выполняет телефонный звонок прямой маршрутизации через Teams на номер телефона во Вьетнаме.
Клиент Teams пользователя взаимодействует с Телефонная система Teams напрямую через REST API, но носитель, созданный во время вызова, сначала передается на внешний IP-адрес прокси-сервера SBC в Сингапуре.
В зависимости от конфигурации и политик голосовой связи (см . раздел Настройка оптимизации локального носителя) прокси-сервер SBC перенаправляет поток в подчиненный SBC во Вьетнаме.
Подчиненный SBC во Вьетнаме перенаправляет поток в подключенную локальную сеть ТСОП.
Прокси-сервер SBC отображается только для Телефонная система Teams через внешний IP-адрес.
Подчиненный SBC в локальном филиале не отображается для Телефонная система Teams напрямую, но сопоставляется в топологии виртуальной сети, определенной администратором Contoso при настройке оптимизации локального мультимедиа. В этом примере пользователь считается внешним, так как он находится за пределами корпоративной сети.
Схема 4. Поток трафика, когда пользователь является внешним с прокси-сервером SBC и подключенными подчиненными SBC
Режимы локальной оптимизации мультимедиа
Локальная оптимизация мультимедиа поддерживает два режима:
Режим 1. Всегда обход. В этом случае, если пользователь является внутренним, носитель проходит через внутренний IP-адрес локального подчиненного SBC независимо от фактического расположения внутреннего пользователя. например, в том же филиале, где находится подчиненный SBC, или в другом филиале.
Режим 2. Только для локальных пользователей. В этом режиме мультимедиа передаются непосредственно на внутренний IP-адрес локального подчиненного SBC, только если он создается внутренним пользователем, расположенным в том же филиале, что и подчиненный SBC.
Чтобы различать режимы оптимизации локального мультимедиа, администратор клиента должен задать для параметра -BypassMode значение Always или OnlyForLocalUsers для каждого SBC с помощью командлета Set-CSonlinePSTNGateway. Дополнительные сведения см. в разделе Настройка оптимизации локального носителя.
Примечание.
Если пользователи являются внутренними, требуется подключение к мультимедиа между пользователем и SBC по внутреннему IP-адресу. В этом случае нет резервного использования ретрансляторов общественного транспорта для мультимедиа, так как SBC будет предоставлять внутренний IP-адрес для подключения к мультимедиа.
Режим 1. Всегда обход
Если между филиалами установлено хорошее подключение, рекомендуемый режим — Всегда обход.
Например, предположим, что компания имеет централизованную магистраль SIP в Амстердаме, которая обслуживает 30 стран и регионов и имеет хорошую связь между всеми 30 сайтами и местными пользователями. Существует также филиал в Германии, где развернут локальный SBC.
SBC в Германии можно настроить в режиме "Всегда обход". Пользователи, независимо от их расположения, будут подключаться к SBC напрямую через внутренний IP-адрес SBC; например, из Франции в Германию. См. приведенную ниже схему.
Ниже описаны два сценария.
Сценарий 1. Пользователь находится в том же расположении, что и SBC, определенный в политике маршрутизации голосовой связи.
Сценарий 2. Пользователь и шлюзы находятся на разных сайтах.
Сценарий 1. Пользователь находится в том же расположении, что и SBC, определенный в политике маршрутизации голосовой связи через Интернет.
SBC в Амстердаме настроен как прокси-сервер SBC для локального подчиненного SBC в Германии. Пользователь находится в Германии в той же подсети, что и корпоративная сеть локального SBC. Оба SBC (прокси-сервер и подчиненный) настроены в режиме постоянного обхода. Политики маршрутизации голосовой связи через Интернет указывают, что звонки в Пределах Германии (с кодом региона +49) должны быть перенаправлены в местный SBC в Германии. Все остальные вызовы должны быть перенаправлены на прокси-сервер SBC в Амстердаме. Однако в случае сбоя SBC в Германии вызовы в Германии также должны быть перенаправлены на прокси-сервер SBC в Амстердаме. В следующей таблице приведен пример конфигурации.
Таблица 3. Пример конфигурации для сценария 1
| Физическое расположение пользователя | Пользователь делает звонок на номер | Политика маршрутизации голосовой связи через Интернет | Режим, настроенный для SBC | Поток мультимедиа |
|---|---|---|---|---|
| Германия | +49 1 437 2800 | Приоритет 1: ^+49(\d{8})$ -DEsbc.contoso.com Приоритет 2: .* — proxysbc.contoso.com |
DEsbc.contoso.com — Always Bypass proxysbc.contoso.com — всегда обход |
Пользователь <Teams —> DEsbc.contoso.com |
На приведенной ниже схеме показан поток трафика высокого уровня для внутреннего пользователя в Германии, выполняющего телефонный звонок с прямой маршрутизацией через Teams на номер в Германии.
Клиент Teams пользователя взаимодействует с Телефонная система Teams напрямую через REST API.
Носитель, созданный во время вызова, передается на внутренний IP-адрес локального SBC.
Локальный SBC перенаправляет поток в прокси-сервер SBC в Амстердаме и в подключенную локальную сеть ТСОП.
Прокси-сервер SBC отображается для Телефонная система Teams только через внешний IP-адрес и направляет поток из подчиненного SBC (в данном случае локального SBC в Германии) в Телефонная система Teams.
Подчиненный SBC в локальном филиале не виден для Телефонная система Teams напрямую, но сопоставляется в топологии виртуальной сети, определенной администратором Contoso при настройке оптимизации локального носителя.
Схема 5. Поток трафика с режимом Always Bypass, и пользователь находится на "домашнем" сайте
Сценарий 2. Пользователь и шлюзы находятся на разных сайтах
SBC в Амстердаме настроен как прокси-сервер SBC для локального подчиненного SBC в Германии. Оба SBC (прокси-сервер и подчиненный) настроены в режиме постоянного обхода. Внутренний пользователь во Франции, расположенный в местном филиале, выполняет прямой вызов маршрутизации в Германию. Политики маршрутизации голосовой связи через Интернет указывают, что звонки в Германию (с кодом региона +49) должны направляться в местный SBC в Германии. Все остальные вызовы должны быть перенаправлены на прокси-сервер SBC в Амстердаме. Однако в случае сбоя SBC в Германии все вызовы в Германии должны быть перенаправлены на прокси-сервер SBC в Амстердаме. В следующей таблице приведен пример конфигурации.
Таблица 4. Пример конфигурации для сценария 2
| Физическое расположение пользователя | Пользователь делает звонок на номер | Политика маршрутизации голосовой связи через Интернет | Режим, настроенный для SBC | Поток мультимедиа |
|---|---|---|---|---|
| Франция | +49 1 437 2800 | Приоритет 1: ^+49(\d{8})$ -DEsbc.contoso.com Приоритет 2: .* — proxysbc.contoso.com |
DEsbc.contoso.com — Always Bypass proxysbc.contoso.com — Always Bypass | Пользователь <Teams — > DEsbc.contoso.com |
На следующей схеме показан поток трафика высокого уровня, когда внутренний немецкий пользователь, расположенный во Франции, совершает телефонный звонок прямой маршрутизации через Teams на номер в Германии.
Клиент Teams пользователя взаимодействует с Телефонная система Teams напрямую через REST API.
Носитель, созданный во время вызова, передается непосредственно в SBC по внутреннему IP-адресу Германии.
SBC в Германии перенаправляет поток в прокси-сервер SBC в Амстердаме и в подключенную локальную сеть ТСОП.
Схема 6. Поток трафика в режиме Always Bypass, и пользователь не на "домашнем" сайте, а во внутренней сети
Режим 2. Только для локальных пользователей
Если между местными филиалами есть плохие подключения, но между каждым локальным филиалом и региональным офисом есть хорошие подключения, рекомендуемый режим — "Только для локальных пользователей".
Например, в регионе APAC предположим, что у Contoso есть несколько офисов в разных странах или регионах. Во многих странах и регионах переключение на SIP невозможно, так как компания по-прежнему имеет магистрали TDM во многих местных филиалах. Централизация магистралей TDM не является вариантом в регионе APAC. Кроме того, существует более 50 филиалов Contoso в регионе APAC с сотнями шлюзов (SBC).
Чтобы создать решение, в котором службы ТСОП предоставляются во всех локальных филиалах в регионе APAC, где централизация магистралей TDM не является вариантом, администратор Contoso связывает один региональный SBC в Сингапуре в качестве прокси-сервера SBC со службой прямой маршрутизации. Прямая связь между местными филиалами не является хорошей, но есть хорошая связь между каждым местным филиалом и региональным SBC в Сингапуре. Для регионального SBC администратор выбирает режим Always Bypass. Для локальных подчиненных SBC администратор выбирает режим "Только для локальных пользователей".
Ниже описаны два сценария.
Сценарий 1. Пользователь находится в том же расположении, что и SBC, определенный в политике маршрутизации голосовой связи через Интернет.
Сценарий 2. Пользователь и шлюзы находятся на разных сайтах
Сценарий 1. Пользователь находится в том же расположении, что и SBC, определенный в политике маршрутизации голосовой связи через Интернет.
Предположим, что SBC в Сингапуре настроен как прокси-сервер SBC для локальных подчиненных SBC во Вьетнаме и Индонезии. Пользователь находится во Вьетнаме в том же расположении, что и локальный SBC. Политики маршрутизации голосовой связи через Интернет указывают, что звонки во Вьетнаме (с кодом региона +84) должны быть перенаправлены в местный SBC во Вьетнаме. Все остальные вызовы должны быть перенаправлены на прокси-сервер SBC в Сингапуре. Если SBC во Вьетнаме не удается, однако, звонки во Вьетнаме должны быть перенаправлены на прокси SBC в Сингапуре. В следующей таблице приведен пример конфигурации.
Таблица 5. Пример конфигурации для режима "Только для локальных пользователей", сценарий 1
| Физическое расположение пользователя | Пользователь делает звонок на номер | Политика маршрутизации голосовой связи через Интернет | Режим, настроенный для SBC | Поток мультимедиа |
|---|---|---|---|---|
| Вьетнам | +84 4 3926 3000 | Приоритет 1: ^+84(\d{9})$ -VNsbc.contoso.com Приоритет 2: .* — proxysbc.contoso.com |
VNsbc.contoso.com — только для локальных пользователей proxysbc.contoso.com — всегда обход |
Пользователь <Teams —> VNsbc.contoso.com |
На следующей схеме пользователь, назначенный локальному филиалу во Вьетнаме, выполняет телефонный звонок с прямой маршрутизацией через Teams.
Клиент Teams пользователя взаимодействует с Телефонная система Teams напрямую через REST API.
Носитель, созданный во время вызова, передается на внутренний IP-адрес локального SBC.
Локальный SBC перенаправляет поток в прокси-сервер SBC в Сингапуре и в подключенную локальную сеть ТСОП.
Прокси-сервер SBC отображается для Телефонная система Teams только через внешний IP-адрес и направляет поток из подчиненного SBC (в данном случае локального SBC во Вьетнаме) на Телефонная система Teams.
Подчиненный SBC в локальном филиале не виден Телефонная система Teams напрямую, но сопоставлен в топологии виртуальной сети.
Схема 7. Поток трафика в режиме "Только для локальных пользователей" и пользователь находится на "домашнем" сайте
Сценарий 2. Пользователь и шлюзы находятся на разных сайтах
Предположим, что SBC в Сингапуре настроен как прокси-сервер SBC для локальных подчиненных SBC во Вьетнаме и Индонезии. Внутренний пользователь в Индонезии, расположенный в местном филиале, выполняет прямой вызов маршрутизации во Вьетнам. Политики маршрутизации голосовой связи через Интернет указывают, что звонки во Вьетнам (с кодом региона +84) должны быть перенаправлены в местный SBC во Вьетнаме. Все остальные вызовы должны быть перенаправлены на прокси-сервер SBC в Сингапуре. Если SBC во Вьетнаме не удается, однако, звонки во Вьетнам должны быть перенаправлены на прокси SBC в Сингапуре. Для прокси-сервера SBC в Сингапуре установлен режим Always Bypass, а для локального SBC во Вьетнаме — режим "Только для локальных пользователей". В следующей таблице приведен пример конфигурации.
Таблица 6. Пользовательская конфигурация
| Физическое расположение пользователя | Пользователь делает звонок на номер | Политика маршрутизации голосовой связи через Интернет | Режим, настроенный для SBC | Поток мультимедиа |
|---|---|---|---|---|
| Индонезия | +84 4 3926 3000 | Приоритет 1: ^+84(\d{9})$ -VNsbc.contoso.com Приоритет 2: .* — proxysbc.contoso.com |
VNsbc.contoso.com — только для локальных пользователей proxysbc.contoso.com — всегда обход |
Пользователь <Teams —> proxysbc.contoso.com <—> VNsbc.contoso.com |
На следующей схеме внутренний пользователь, находясь в индонезийском филиале, совершает телефонный звонок прямой маршрутизации через Teams на номер во Вьетнаме.
Клиент Teams пользователя взаимодействует с Телефонная система Teams напрямую через REST API.
Носитель, созданный во время потоков вызовов, сначала проксировать внутренний IP-адрес SBC.
Прокси-сервер SBC в Сингапуре перенаправляет поток на внутренний IP-адрес подчиненного SBC во Вьетнаме и на Телефонная система Teams.
Подчиненный SBC во Вьетнаме направляет поток в подключенную локальную сеть ТСОП.
Прокси-сервер SBC отображается только для Телефонная система Teams через внешний IP-адрес.
Подчиненные SBC в локальных филиалах не видны Телефонная система Teams напрямую, но сопоставлены в топологии виртуальной сети.
Схема 8. Поток трафика в режиме "Только для локальных пользователей", и пользователь не на "домашнем" сайте, а во внутренней сети
Известные варианты поведения
Ниже приведен список поведений, которые могут наблюдаться при использовании оптимизации локального носителя.
| Поведение продукта | Notes |
|---|---|
| Клиент Teams не определяется как внутренний , если общедоступный IP-адрес клиента Teams соответствует списку доверенных IP-адресов клиента, но не соответствует сетевому сайту. | Для оптимизации локального мультимедиа требуется соответствующий сетевой сайт для каждого подключения, выполненного из указанного доверенного IP-адреса. |
| Пользователь Teams помещает вызов на удержание. Музыка воспроизводится в конце ТСОП, а оптимизация локального носителя работает. Пользователь Teams возобновляет вызов. Вызов к ТСОП возобновляется, но оптимизация локального носителя не работает, и вызов продолжается через центральный (прокси-сервер) SBC. | Когда пользователь паркует вызов для запуска музыки на удержании (MoH), он перерастает с 1:1 в многопартийный вызов контроллера вызовов для вызова контроллера мультимедиа и обработчика мультимедиа (выступающего в качестве микшера AVMCU), через который MoH достигает пользователя, который был поставлен на удержание. Деэскалация до вызова 1:1 после возобновления вызова никогда не происходит в расчете. |
| Во время установки вызова пользователь может слышать молчание в течение нескольких секунд. | В некоторых случаях это может произойти из-за сложности архитектуры локальной оптимизации мультимедиа. |
| Голосовые приложения (например, автосекретарь и очередь вызовов). | Голосовые приложения можно развертывать в среде с настроенным LMO. Однако вызовы с использованием голосовых приложений не будут оптимизированы для оптимизации локального мультимедиа. Вместо этого они будут проходить через прокси-сервер SBC, за исключением передачи от автосекретаря пользователям локальной оптимизации мультимедиа. В таких случаях вызов будет следовать пути оптимизации локального мультимедиа, так как это прямой вызов 1:1. Сценарии маршрутизации Location-Based см. в разделе Голосовые приложения (автосекретарь или очередь вызовов). |