Planear la optimización de medios locales para el enrutamiento directo
La voz de la red telefónica conmutada (RTC) se considera una aplicación crítica para la empresa con altas expectativas de calidad de voz. Enrutamiento directo para Teléfono Microsoft Teams le permite controlar los flujos de tráfico multimedia para dar cabida a una multitud de topologías de red y configuraciones de telefonía local para varias empresas de todo el mundo.
La Optimización de medios locales para enrutamiento directo te permite administrar la calidad de voz mediante:
Controlar cómo fluye el tráfico multimedia entre los clientes de Teams y los controladores de borde de sesión de cliente (SCS).
Mantener los medios locales dentro de los límites de las subredes de red corporativas.
Permitir transmisiones multimedia entre los clientes de Teams y los SBCs incluso si los SBCs están detrás de los firewalls corporativos con ips privadas y no son visibles para Microsoft directamente.
La Optimización de medios locales admite dos escenarios:
Centralización de todos los troncos locales a través de un SBC centralizado conectado al tronco del Protocolo de inicio de sesión (SIP) principal. Este escenario proporciona servicios de telefonía a todas las sucursales locales de la compañía.
Una topología de red virtual de LOSC. En este escenario, los SBC de las sucursales locales están conectados a un SBC proxy centralizado que es visible y con el que se comunica, Teléfono Teams a través de su dirección IP externa. En una topología de red virtual, los SDC intermedios se comunican a través de direcciones IP internas y no son directamente visibles para Teléfono Teams.
En este artículo se describen la funcionalidad de las características y los escenarios y soluciones de los clientes. Para obtener más información sobre la configuración, consulta Configurar optimización de medios locales.
Nota
Si quieres mantener los medios locales dentro de los límites de la intranet, se recomienda optimización de medios locales. Sin embargo, si ya tiene Media Bypass y solo usa las direcciones IP públicas de sus SBCs, no es necesario pasar a Optimización de medios local. Puede seguir usando la omisión de medios. Para obtener más información, vea Planear la omisión de medios.
Para obtener información sobre qué proveedores de SBC admiten optimización de medios locales, consulte Controladores de borde de sesión certificados para enrutamiento directo.
Escenarios de clientes admitidos
Para esta discusión, supongamos que Contoso ejecuta varias empresas en todo el mundo tal y como se indica a continuación. (Tenga en cuenta que las regiones de Europa y APAC solo se usan como ejemplos. Una empresa puede tener varias regiones diferentes con requisitos similares).
En Europa, Contoso tiene oficinas en aproximadamente 30 países o regiones. Cada oficina tiene su propia central de sucursal privada (PBX).
Se ofreció a Contoso una opción para centralizar los troncos en una sola ubicación ,Amsterdam, para las 30 oficinas europeas. Contoso implementó el SBC en Ámsterdam, proporcionó suficiente ancho de banda para ejecutar llamadas a través de la ubicación centralizada, conectó un tronco SIP central a la ubicación centralizada y comenzó a servir a todas las ubicaciones europeas desde Amsterdam.
En la región de APAC, Contoso tiene varias oficinas en diferentes países o regiones.
En muchos países o regiones, la compañía todavía tiene troncos de multiplexación por división temporal (TDM) en sucursales locales. La centralización de los troncos TDM no es una opción en la región de APAC, así que cambiar a SIP no es posible. Suponga que hay más de 50 sucursales de Contoso en toda la región de APAC con cientos de puertas de enlace (SDC). En este escenario, no es posible emparejar todas las puertas de enlace a la interfaz de enrutamiento directo debido a la falta de direcciones IP públicas y/o a las interrupciones locales de Internet. Además, algunos países o regiones imponen requisitos normativos que no se pueden cumplir sin tener conectividad de red RTC local.
En función de sus requisitos empresariales, Contoso implementó dos soluciones con optimización de medios locales para enrutamiento directo:
En Europa, todos los troncos están centralizados y los flujos de medios entre el SBC central y los usuarios, en función de la ubicación del usuario.
Si un usuario está conectado a la subred local de una red corporativa (es decir, el usuario es interno), los flujos de medios entre la DIRECCIÓN IP interna del SBC central y el cliente de Teams del usuario.
Si un usuario está fuera de los límites de la red corporativa (por ejemplo, si el usuario usa una conexión de Internet inalámbrica pública), se considera que es externo. En este caso, los medios fluyen entre la DIRECCIÓN IP externa del SBC central y el cliente de Teams.
En la región de APAC, un SBC de proxy centralizado está emparejado con Microsoft Direct Routing, que dirige los medios entre la interfaz de Enrutamiento directo y los SBC de bajada de las sucursales locales.
Los S SBC descendentes de las sucursales locales no son visibles directamente para el enrutamiento directo en APAC, pero se emparejan mediante el cmdlet Set-CSOnlinePSTNGateway para crear una topología de red virtual dentro de Teléfono Teams. Los medios siempre permanecen locales cuando es posible. Los usuarios externos tienen medios que fluyen entre el cliente de Teams y la DIRECCIÓN IP pública del servidor proxy SBC.
SBC central con troncos centralizados
Para crear una solución donde se proporcionan servicios RTC a todas las sucursales locales a través de una única SBC central con un tronco SIP centralizado conectado, el administrador de inquilinos de Contoso empareja un SBC (centralsbc.contoso.com) al servicio. El SBC tiene un tronco del SIP centralizado conectado a él.
Cuando un usuario está en la red interna de la empresa, el SBC proporciona la DIRECCIÓN IP interna del SBC para los medios.
Cuando un usuario está fuera de la red corporativa, el SBC proporciona la IP externa (pública) del SBC.
Nota
Todos los valores incluidos en ejemplos, tablas o diagramas se presentan únicamente con fines ilustrativos.
Tabla 1. Parámetros de red de ejemplo para SBCs
| Ubicación | SBC FQDN | Subred interna | NAT externo (IP de confianza) | Dirección IP externa de SBC | Dirección IP interna de SBC |
|---|---|---|---|---|---|
| Ámsterdam | centralsbc.contoso.com | 192.168.5.0/24 | 172.16.76.73 | 172.16.76.71 | 192.168.5.5 |
| Alemania | No implementado | 192.168.6.0/24 | 172.16.76.74 | No implementado | No implementado |
| Francia | No implementado | 192.168.7.0/24 | 172.16.76.75 | No implementado | No implementado |
Usuario interno
El siguiente diagrama muestra el flujo de tráfico cuando un usuario está conectado a la red corporativa en la sucursal o el sitio del usuario.
Mientras esté en local, el usuario se asigna a la sucursal local en Alemania. El usuario realiza una llamada telefónica de enrutamiento directo a través de Teams.
El cliente de Teams del usuario se comunica con Teléfono Teams directamente a través de la API de REST, pero los elementos multimedia generados durante la llamada fluyen a la dirección IP interna del SBC central.
El SBC redirige el flujo a Teléfono Teams y a la red RTC conectada.
El SBC central es visible para Teléfono Teams solo a través de la dirección IP externa.
Diagrama 1. Flujo de tráfico cuando el usuario está en el sitio "principal" con un SBC centralizado y con un tronco SIP centralizado conectado
Usuario externo
El siguiente diagrama muestra el flujo de tráfico cuando un usuario no se encuentra en un entorno local y no está conectado a la red corporativa (es decir, el dispositivo del usuario está conectado a Internet a través de un dispositivo móvil o Wi-Fi público). El usuario realiza una llamada de enrutamiento directo por teléfono a través de Teams:
El cliente de Teams del usuario se comunica con Teléfono Teams directamente a través de la API de REST, pero, en este caso, los medios generados durante la llamada fluyen a la dirección IP externa de la SBC central.
El SBC redirige el flujo a Teléfono Teams y a la red RTC conectada.
El SBC central es visible para Teléfono Teams solo a través de la dirección IP externa.
En este caso, el comportamiento es similar tanto si el usuario es local en la sucursal de Alemania como en cualquier otra sucursal. El usuario se considera externo porque está fuera de los límites de la red corporativa.
Diagrama 2. Flujo de tráfico cuando el usuario es externo con un SBC centralizado y con un tronco sip centralizado conectado
SBC de proxy con SBCs conectados en bajada
Para crear una solución en la que los servicios RTC se proporcionan en todas las sucursales locales de la región de APAC donde la centralización de los troncos TDM no es una opción, el administrador de Contoso empareja un SBC (proxysbc.contoso.com), también denominado SBC de proxy, al servicio de enrutamiento directo.
Posteriormente, el administrador de Contoso agrega algunos SBC de bajada, lo que indica que se puede llegar a ellos a través de la proxysbc.contoso.com SBC del proxy. Los SBCs descendentes no tienen IP públicas; sin embargo, se pueden asignar a rutas de voz. La tabla siguiente muestra parámetros de red y configuración de ejemplo.
Cuando un usuario está en la sucursal local donde se encuentra la SBC descendente, el tráfico multimedia fluye directamente entre el usuario y la SBC local descendente. Si un usuario está fuera de la oficina (en un internet público), los elementos multimedia fluyen desde el usuario a la DIRECCIÓN IP pública del servidor proxy SBC, que lo proxya a las SBC correspondientes aguas abajo.
Tabla 2. Información de red SBC de ejemplo
| Ubicación | SBC FQDN | Subred interna | NAT externo (IP de confianza) | Dirección IP externa de SBC | Dirección IP interna de SBC |
|---|---|---|---|---|---|
| Vietnam | VNsbc.contoso.com | 192.168.1.0/24 | 172.16.240.110 | Ninguna | 192.168.1.5 |
| Indonesia | IDsbc.contoso.com | 192.168.2.0/24 | 172.16.240.120 | Ninguna | 192.168.2.5 |
| Singapur | proxysbc.contoso.com | 192.168.3.0/24 | 172.16.240.130 | 172.16.240.133 | 192.168.3.5 |
Usuario interno
El siguiente diagrama muestra el flujo de tráfico de alto nivel para el escenario cuando un usuario está dentro de la oficina en la región de APAC. El usuario, que está asignado a una sucursal local en Vietnam y es local, realiza una llamada telefónica de enrutamiento directo a través de Teams.
El cliente de Teams del usuario se comunica con Teléfono Teams directamente a través de la API rest, pero los elementos multimedia generados durante la llamada fluyen a la dirección IP interna del SBC local.
El SBC local redirige el flujo al servidor proxy SBC en Singapur y a la red RTC local conectada.
El servidor proxy SBC es visible para Teléfono Teams solo a través de la dirección IP externa y enruta el flujo desde el SBC descendente (en este caso el SBC local en Vietnam) a Teléfono Teams.
El SBC descendente de la sucursal local no es visible para Teléfono Teams directamente, pero se asigna dentro de la topología de red virtual que define el administrador de Contoso al configurar optimización de medios locales.
Nota
El comportamiento puede ser diferente para los usuarios locales y no locales en función del modo de optimización de medios locales configurado.
Para obtener más información sobre los posibles modos y el comportamiento relevante, consulta Configurar optimización de medios locales.
Diagrama 3. Flujo de tráfico cuando el usuario está en la red "doméstica" con un SBC de proxy y con SBCs conectados
Usuario externo
El siguiente diagrama muestra el flujo de tráfico cuando un usuario está fuera de los límites de la red corporativa. El usuario no está en un entorno local (no está dentro de los límites de la red corporativa). El usuario realiza una llamada telefónica de enrutamiento directo a través de Teams a un número de teléfono en Vietnam.
El cliente de Teams del usuario se comunica con Teléfono Teams directamente a través de la API rest, pero los elementos multimedia generados durante la llamada fluyen en primer lugar a la dirección IP externa del servidor proxy SBC en Singapur.
En función de las directivas de configuración y voz (consulte Configurar optimización de medios locales), el proxy SBC redirige el flujo al SBC descendente en Vietnam.
El SBC aguas abajo en Vietnam redirige el flujo a la red RTC local conectada.
El servidor proxy SBC es visible para Teléfono Teams solo a través de la dirección IP externa.
El SBC descendente de la sucursal local no es visible para Teléfono Teams directamente, pero se asigna dentro de la topología de red virtual que define el administrador de Contoso al configurar optimización de medios locales. En el ejemplo, el usuario se considera externo porque está fuera de los límites de la red corporativa.
Diagrama 4. Flujo de tráfico cuando el usuario es externo con un SBC de proxy y con SBCs conectados aguas abajo
Modos de optimización de medios locales
La Optimización de medios locales admite dos modos:
Modo 1: Omitir siempre. En este caso, si el usuario es interno, los medios fluyen a través de la dirección IP interna de SBC de la corriente abajo local independientemente de la ubicación real del usuario interno; por ejemplo, dentro de la misma sucursal donde se encuentra la SBC descendente o en alguna otra sucursal.
Modo 2: Solo para usuarios locales. En este modo, los medios fluyen directamente a la dirección IP interna de la SBC de bajada local solo cuando los genera el usuario interno ubicado en la misma sucursal que la SBC descendente.
Para distinguir entre modos de optimización de medios locales, el administrador de inquilinos debe establecer el parámetro -BypassMode en 'Always' o 'OnlyForLocalUsers' para cada SBC mediante el cmdlet de Set-CSonlinePSTNGateway. Para obtener más información, consulta Configurar optimización de medios locales.
Nota
Cuando los usuarios son internos, se requiere conectividad multimedia entre el usuario y el SBC a través de la dirección IP interna. No hay ninguna reserva a los relés de transporte público para los medios en este caso, ya que el SBC proporcionará una IP interna para la conectividad multimedia.
Modo 1: Omitir siempre
Si tiene una buena conexión entre sucursales, el modo recomendado es Omitir siempre.
Por ejemplo, supongamos que una compañía tiene un tronco SIP centralizado en Ámsterdam, que sirve a 30 países o regiones y tiene una buena conectividad entre los 30 sitios y los usuarios locales. También hay una rama en Alemania donde se implementa un SBC local.
El SBC en Alemania se puede configurar en modo "Siempre bypass". Los usuarios, independientemente de su ubicación, se conectarán al SBC directamente a través de la dirección IP interna del SBC; por ejemplo, de Francia a Alemania. Consulte el diagrama siguiente para obtener referencia.
A continuación se describen dos escenarios:
Escenario 1. El usuario está en la misma ubicación que el SBC definido en la directiva de enrutamiento de voz en línea.
Escenario 2. El usuario y las puertas de enlace están en sitios diferentes.
Escenario 1. El usuario está en la misma ubicación que el SBC definido en la directiva de enrutamiento de voz en línea
El SBC en Ámsterdam está configurado para ser un proxy SBC para un SBC local aguas abajo en Alemania. El usuario está en Alemania dentro de la misma subred que la red corporativa de la SBC local. Ambos SBCs (proxy y aguas abajo) están configurados para el modo Siempre omitido. Las directivas de enrutamiento de voz en línea especifican que las llamadas dentro de Alemania (con el código de área +49) deben redirigirse al SBC local en Alemania. Todas las demás llamadas deben redirigirse al servidor proxy SBC en Ámsterdam. Sin embargo, si falla el SBC en Alemania, las llamadas en Alemania también deben redirigirse al servidor proxy SBC en Ámsterdam. En la tabla siguiente se resume la configuración de ejemplo.
Tabla 3. Configuración de ejemplo para el escenario 1
| Ubicación física del usuario | El usuario realiza una llamada a un número | Directiva de enrutamiento de voz en línea | Modo configurado para SBC | Flujo de medios |
|---|---|---|---|---|
| Alemania | +49 1 437 2800 | Prioridad 1: ^+49(\d{8})$ -DEsbc.contoso.com Prioridad 2: .* - proxysbc.contoso.com |
DEsbc.contoso.com: omitir siempre proxysbc.contoso.com: omitir siempre |
Usuario de <Teams:> DEsbc.contoso.com |
El diagrama siguiente muestra el flujo de tráfico de alto nivel para el usuario interno en Alemania que realiza una llamada telefónica de enrutamiento directo a través de Teams al número de Alemania.
El cliente de Teams del usuario se comunica con Teléfono Teams directamente a través de la API rest.
Los medios generados durante la llamada fluyen a la dirección IP interna del SBC local.
El SBC local redirige el flujo al servidor proxy SBC en Ámsterdam y a la red RTC local conectada.
El proxy SBC es visible para Teléfono Teams a través de la dirección IP externa solamente y enruta el flujo desde el SBC descendente (en este caso, el SBC local en Alemania) a Teléfono Teams.
El SBC descendente de la sucursal local no es visible para Teléfono Teams directamente, pero se asigna dentro de la topología de red virtual que define el administrador de Contoso al configurar optimización de medios locales.
Diagrama 5. Flujo de tráfico con el modo "Omitir siempre" y el usuario se encuentra en el sitio "principal"
Escenario 2: El usuario y las puertas de enlace están en diferentes sitios
El SBC en Ámsterdam está configurado para ser un proxy SBC para un SBC local aguas abajo en Alemania. Ambos SBCs (proxy y aguas abajo) están configurados para el modo Siempre omitido. El usuario interno en Francia, ubicado en la sucursal local, está realizando una llamada de enrutamiento directo a Alemania. Las directivas de enrutamiento de voz en línea especifican que las llamadas a Alemania (con el código de área +49) deben redirigirse al SBC local de Alemania. Todas las demás llamadas deben redirigirse al servidor proxy SBC en Ámsterdam. Sin embargo, si el SBC en Alemania falla, todas las llamadas en Alemania deben redirigirse al servidor proxy SBC en Ámsterdam. En la tabla siguiente se resume la configuración de ejemplo.
Tabla 4. Configuración de ejemplo para el escenario 2
| Ubicación física del usuario | El usuario realiza una llamada a un número | Directiva de enrutamiento de voz en línea | Modo configurado para SBC | Flujo de medios |
|---|---|---|---|---|
| Francia | +49 1 437 2800 | Prioridad 1: ^+49(\d{8})$ -DEsbc.contoso.com Prioridad 2: .* - proxysbc.contoso.com |
DEsbc.contoso.com: omitir siempre proxysbc.contoso.com: omitir siempre | Usuario de <Teams: > DEsbc.contoso.com |
El siguiente diagrama muestra el flujo de tráfico de alto nivel cuando el usuario interno alemán situado en Francia realiza una llamada de enrutamiento directo por teléfono a través de Teams al número de Alemania.
El cliente de Teams del usuario se comunica con Teléfono Teams directamente a través de la API rest.
Los medios generados durante la llamada fluyen directamente al SBC en la dirección IP interna de Alemania.
El SBC en Alemania redirige el flujo al servidor proxy SBC en Ámsterdam y a la red RTC local conectada.
Diagrama 6. Flujo de tráfico con el modo "Omitir siempre" y el usuario no está en el sitio "principal" sino en la red interna
Modo 2: Solo para usuarios locales
Si hay conexiones incorrectas entre las sucursales locales pero buenas conexiones entre cada sucursal local y la oficina regional, el modo recomendado es "Solo para usuarios locales".
Por ejemplo, en la región de APAC, supongamos que Contoso tiene varias oficinas en diferentes países o regiones. Para muchos países o regiones, cambiar a SIP no es posible porque la compañía todavía tiene troncos TDM en muchas sucursales locales. La centralización de los troncos TDM no es una opción en la región de APAC. Además, hay más de 50 sucursales de Contoso en toda la región de APAC con cientos de puertas de enlace (SFC).
Para crear una solución en la que los servicios RTC se proporcionan en todas las sucursales locales de la región de APAC donde la centralización de los troncos TDM no es una opción, el administrador de Contoso empareja un SBC regional en Singapur como el SBC proxy al servicio de enrutamiento directo. La conexión directa entre las sucursales locales no es buena, pero hay una buena conexión entre cada sucursal local y la SBC regional en Singapur. Para el SBC regional, el administrador elige el modo "Omitir siempre". Para los SBCs locales que se encuentran en bajada, el administrador elige el modo "Solo para usuarios locales".
A continuación se describen dos escenarios:
Escenario 1. El usuario está en la misma ubicación que el SBC definido en la directiva de enrutamiento de voz en línea
Escenario 2. El usuario y las puertas de enlace están en sitios diferentes
Escenario 1. El usuario está en la misma ubicación que el SBC definido en la directiva de enrutamiento de voz en línea
Suponga que el SBC en Singapur está configurado para ser un SBC proxy para los SBC locales aguas abajo en Vietnam e Indonesia. El usuario está en Vietnam dentro de la misma ubicación que el SBC local. Las directivas de enrutamiento de voz en línea especifican que las llamadas en Vietnam (con código de área +84) deben redirigirse al SBC local en Vietnam. Todas las demás llamadas deben redirigirse al servidor proxy SBC de Singapur. Sin embargo, si el SBC en Vietnam falla, las llamadas en Vietnam deben redirigirse al servidor proxy SBC en Singapur. En la tabla siguiente se resume la configuración de ejemplo.
Tabla 5. Configuración de ejemplo para el escenario 1 del modo "Solo para usuarios locales"
| Ubicación física del usuario | El usuario realiza una llamada a un número | Directiva de enrutamiento de voz en línea | Modo configurado para SBC | Flujo de medios |
|---|---|---|---|---|
| Vietnam | +84 4 3926 3000 | Prioridad 1: ^+84(\d{9})$ -VNsbc.contoso.com Prioridad 2: .* - proxysbc.contoso.com |
VNsbc.contoso.com: solo para usuarios locales proxysbc.contoso.com: omitir siempre |
Usuario de <Teams:> VNsbc.contoso.com |
En el siguiente diagrama, un usuario asignado a la sucursal local en Vietnam, mientras está en local, realiza una llamada telefónica de enrutamiento directo a través de Teams.
El cliente de Teams del usuario se comunica con Teléfono Teams directamente a través de la API rest.
Los medios generados durante la llamada fluyen a la dirección IP interna del SBC local.
El SBC local redirige el flujo al servidor proxy SBC en Singapur y a la red RTC local conectada.
El proxy SBC es visible para Teléfono Teams solo a través de la dirección IP externa y enruta el flujo desde el SBC descendente (en este caso, el SBC local en Vietnam) a Teléfono Teams.
El SBC descendente en la sucursal local no es visible para Teléfono Teams directamente, pero se asigna dentro de la topología de red virtual.
Diagrama 7. Flujo de tráfico con el modo "Solo para usuarios locales" y el usuario está en el sitio "principal"
Escenario 2. El usuario y las puertas de enlace están en sitios diferentes
Suponga que el SBC en Singapur está configurado para ser un SBC proxy para los SBC locales aguas abajo en Vietnam e Indonesia. El usuario interno en Indonesia, ubicado en la sucursal local, está realizando una llamada de enrutamiento directo a Vietnam. Las directivas de enrutamiento de voz en línea especifican que las llamadas a Vietnam (con código de área +84) deben redirigirse al SBC local en Vietnam. Todas las demás llamadas deben redirigirse al servidor proxy SBC de Singapur. Sin embargo, si el SBC en Vietnam falla, las llamadas a Vietnam deben redirigirse al servidor proxy SBC en Singapur. El proxy SBC en Singapur se establece en modo "Siempre omito", y el SBC local en Vietnam se establece en modo "Solo para usuarios locales". En la tabla siguiente se resume la configuración de ejemplo.
Tabla 6. Configuración de usuario
| Ubicación física del usuario | El usuario realiza una llamada a un número | Directiva de enrutamiento de voz en línea | Modo configurado para SBC | Flujo de medios |
|---|---|---|---|---|
| Indonesia | +84 4 3926 3000 | Prioridad 1: ^+84(\d{9})$ -VNsbc.contoso.com Prioridad 2: .* - proxysbc.contoso.com |
VNsbc.contoso.com: solo para usuarios locales proxysbc.contoso.com: omitir siempre |
Usuario de <Teams (> proxysbc.contoso.com <)> VNsbc.contoso.com |
En el siguiente diagrama, el usuario interno, mientras se encuentra de forma local en la sucursal indonesia, realiza una llamada de enrutamiento directo de teléfono a través de Teams a un número en Vietnam.
El cliente de Teams del usuario se comunica con Teléfono Teams directamente a través de la API rest.
Medios generados durante los flujos de llamada a la dirección IP interna del proxy SBC en primer lugar.
El servidor proxy SBC en Singapur redirige el flujo a la dirección IP interna de la SBC descendente en Vietnam y a Teléfono Teams.
El SBC aguas abajo en Vietnam enruta el flujo a la red RTC local conectada.
El servidor proxy SBC es visible para Teléfono Teams solo a través de la dirección IP externa.
Los S SBC descendentes de las sucursales locales no son visibles para Teléfono Teams directamente, pero se asignan dentro de la topología de red virtual.
Diagrama 8. Flujo de tráfico con el modo "Solo para usuarios locales" y el usuario no está en el sitio "principal" sino en la red interna
Comportamientos conocidos
La siguiente es una lista de comportamientos que pueden observarse al usar Optimización de medios locales.
| Comportamientos del producto | Notas |
|---|---|
| El cliente de Teams no se identifica como interno cuando la IP pública del cliente de Teams coincide con la lista IP de confianza del cliente, pero no coincide con el sitio de red. | La optimización de medios locales requiere un sitio de red coincidente para cada conexión realizada a partir de una IP de confianza enumerada. |
| El usuario de Teams pone la llamada en espera. La música se reproduce al final de LA RTC y la optimización de medios locales funciona. El usuario de Teams reanuda la llamada. La llamada a RTC se reanuda, pero optimización de medios locales no funciona y la llamada continúa a través de Central (Proxy) SBC. | Cuando un usuario estaciona una llamada para iniciar música en espera (MoH), el controlador de llamadas escala de 1:1 a una llamada multiparte para invocar el controlador multimedia y el procesador multimedia (que sirve como mezclador AVMCU) a través del cual El MoH llega a un usuario que ha sido puesto en espera. La desviación a una llamada individual después de reanudar la llamada nunca se produce según el diseño. |
| Mientras se establece una llamada, es posible que el usuario escuche un silencio durante unos segundos. | Esto puede ocurrir en algunos casos debido a la complejidad de la arquitectura de Optimización de medios locales, |
| Aplicaciones de voz (por ejemplo, Operador automático y Cola de llamadas). | Las aplicaciones de voz se pueden implementar en un entorno con LMO configurado. Sin embargo, las llamadas que implican aplicaciones de voz no se optimizarán para optimización de medios locales. En su lugar, fluirán a través del SBC del proxy, excepto para las transferencias desde el operador automático a los usuarios de optimización de medios locales. En estos casos, la llamada seguirá la ruta optimizada de Optimización de medios locales, ya que se trata de una llamada directa 1:1. Para ver Location-Based escenarios de enrutamiento, consulte Aplicaciones de voz (operador automático o cola de llamadas). |
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de