Planear desvío de medios con enrutamiento directo
Acerca de la omisión multimedia con enrutamiento directo
La omisión multimedia le permite acortar la ruta de acceso del tráfico multimedia y reducir el número de saltos en tránsito para mejorar el rendimiento. Con la omisión multimedia, los elementos multimedia se conservan entre el controlador de borde de sesión (SBC) y el cliente en lugar de enviarlo a través del teléfono de Microsoft Teams. Para configurar la omisión de medios, el SBC y el cliente deben estar en la misma ubicación o red.
Puede controlar la omisión de medios para cada SBC mediante el comando Set-CSOnlinePSTNGateway con el parámetro -MediaBypass establecido en true o false. Si habilita la omisión multimedia, no significa que todo el tráfico multimedia permanecerá dentro de la red corporativa. En este artículo se describe el flujo de llamadas en diferentes escenarios.
Los diagramas siguientes ilustran la diferencia en el flujo de llamadas con y sin omisión de medios.
Sin omisión multimedia, cuando un cliente realiza o recibe una llamada, la señalización y el flujo multimedia entre el SBC, Microsoft Teams Phone System y el cliente de Teams, como se muestra en el siguiente diagrama:
Pero supongamos que un usuario está en la misma compilación o red que el SBC. Por ejemplo, supongamos que un usuario que está en un edificio de Frankfurt realiza una llamada a un usuario de RTC:
Sin omisión de medios, los medios fluyen a través de Amsterdam o Dublín (donde se implementan los centros de datos de Microsoft) y de vuelta al SBC en Frankfurt.
El centro de datos en Europa se selecciona porque el SBC está en Europa y Microsoft usa el centro de datos más cercano al SBC. Aunque este enfoque no afecta a la calidad de las llamadas debido a la optimización del flujo de tráfico dentro de las redes de Microsoft en la mayoría de las geografías, el tráfico tiene un bucle innecesario.
Con la omisión de medios, los elementos multimedia se mantienen directamente entre el usuario de Teams y el SBC, tal y como se muestra en el siguiente diagrama:
La omisión de medios usa protocolos denominados Establecimiento de conectividad interactiva (ICE) en el cliente de Teams y ICE Lite en el SBC. Estos protocolos permiten que el enrutamiento directo use la ruta de acceso multimedia más directa para obtener una calidad óptima. ICE y ICE Lite son estándares WebRTC. Para obtener información detallada sobre estos protocolos, vea RFC 5245.
Flujo de llamadas y planeamiento del firewall
El flujo de llamadas y la planificación del firewall dependen de si el usuario tiene acceso directo a la dirección IP pública del SBC y de si el usuario está dentro o fuera de la red.
Flujo de llamadas si el usuario tiene acceso directo a la dirección IP pública de la SBC
Si el usuario tiene acceso directo a la dirección IP pública del SBC, el flujo de llamadas es el siguiente:
Para la omisión multimedia, el cliente de Teams debe tener acceso a la dirección IP pública del SBC incluso desde una red interna. Si no se desea un medio directo, los medios pueden fluir a través de los relés de transporte.
Este flujo es la solución recomendada cuando un usuario está en la misma compilación o red que SBC: quite los componentes de Microsoft Cloud de la ruta de acceso multimedia.
La señalización siempre fluye a través de la nube de Microsoft.
El siguiente diagrama muestra el flujo de llamadas cuando se habilita la omisión de medios, el cliente es interno y el cliente puede alcanzar la dirección IP pública del SBC (medios directos):
Las flechas y los valores numéricos de las rutas de acceso se ajustan a los flujos de llamada de Microsoft Teams.
La señalización SIP siempre toma las rutas 4 y 4' (dependiendo de la dirección del tráfico). Los medios se mantienen locales y toma la ruta 5b.
Flujo de llamadas si el usuario no tiene acceso a la dirección IP pública del SBC
En el escenario siguiente se describe el flujo de llamadas si el usuario no tiene acceso a la dirección IP pública del SBC.
Por ejemplo, supongamos que el usuario es externo y el administrador de inquilinos ha decidido no abrir la dirección IP pública del SBC a todos los usuarios de Internet, sino solo a Microsoft Cloud. Los componentes internos del tráfico pueden fluir a través de los relés de transporte de Teams. Tenga en cuenta lo siguiente:
Se utilizan relés de transporte de Teams.
Para la omisión multimedia, Microsoft usa una versión de retransmisión de transporte que requiere abrir los puertos 50 000 a 59 999 entre los relés de transporte de Teams y el SBC (en el futuro tenemos previsto pasar a la versión que requiere 3478-3481 puertos).
El siguiente diagrama muestra el flujo de llamadas cuando la omisión de medios está habilitada, el cliente es externo y el cliente no puede alcanzar la dirección IP pública del controlador de borde de sesión (el relé de transporte de Teams retransmite multimedia).
Las flechas y los valores numéricos de las rutas de acceso se ajustan a los flujos de llamada de Microsoft Teams.
Los medios se retransmiten a través de las rutas 3, 3', 4 y 4'.
Flujo de llamadas si un usuario está fuera de la red y tiene acceso a la DIRECCIÓN IP pública del SBC
Nota
Esta no es una configuración recomendada porque no aprovecha las ventajas de los relés de transporte de Teams. En su lugar, debe tener en cuenta el escenario anterior en el que el usuario no tiene acceso a la dirección IP pública del SBC.
El siguiente diagrama muestra el flujo de llamadas cuando se habilita la omisión de medios, el cliente es externo y el cliente puede alcanzar la dirección IP pública del SBC (medios directos).
Las flechas y los valores numéricos de las rutas de acceso se ajustan al artículo Flujos de llamadas de Microsoft Teams .
La señalización SIP siempre toma las rutas 3 y 3' (dependiendo de la dirección del tráfico). Flujos de medios mediante la ruta de acceso 2.
Uso de procesadores multimedia y relés de transporte
Hay dos componentes en la nube de Microsoft que pueden estar en la ruta de acceso del tráfico multimedia: procesadores multimedia y relés de transporte.
El procesador multimedia es un componente orientado al público que controla los medios en casos que no se omiten y controla los medios de las aplicaciones de voz.
Los procesadores multimedia siempre están en la ruta de acceso para las llamadas que no se omiten del usuario final, pero nunca en la ruta de acceso para las llamadas omitida. Los procesadores multimedia siempre están en la ruta de acceso para todas las aplicaciones de voz, como el parque de llamadas, el operador automático de organización y las colas de llamadas.
El relé de transporte se utiliza para conectar con el servicio de transporte más cercano para enviar el tráfico en tiempo real.
Las retransmisiones de transporte pueden estar o no en la ruta de acceso para las llamadas omitida (que provienen de usuarios finales o se destinan a ellas) en función de dónde se encuentre el usuario y cómo esté configurada la red.
El siguiente diagrama muestra dos flujos de llamada: uno con la omisión de medios habilitada y la segunda con la omisión de medios deshabilitada.
Nota
El diagrama solo muestra el tráfico que proviene de usuarios finales o que se destina a ellos.
El controlador de medios es un microservicio de Azure que asigna procesadores multimedia y crea ofertas de Protocolo de descripción de sesión (SDP).
El proxy SIP es un componente que traduce la señalización HTTP REST usada en Teams a SIP.
En la tabla siguiente se resume la diferencia entre los procesadores multimedia y los relés de transporte.
| Procesadores multimedia | Relés de transporte | |
|---|---|---|
| En la ruta de acceso multimedia para las llamadas no omitida para los usuarios finales | Siempre | Si el cliente no puede acceder directamente al procesador multimedia |
| En la ruta de acceso multimedia para llamadas omitida para usuarios finales | Nunca | Si el cliente no puede acceder al SBC en la dirección IP pública |
| En la ruta de acceso multimedia para aplicaciones de voz | Siempre | Nunca |
| Puede realizar la transcodificación (B2BUA)* | Sí | No, solo retransmite audio entre puntos de conexión |
Los intervalos IP son:
- 52.112.0.0/14 (direcciones IP de 52.112.0.0 a 52.115.255.255)
- 52.120.0.0/14 (direcciones IP de 52.120.0.0 a 52.123.255.255)
Nota
Los intervalos IP presentados en este documento son específicos del enrutamiento directo y pueden diferir de los recomendados para el cliente de Teams.
* Explicación de transcodificación:
El procesador multimedia es B2BUA, lo que significa que puede cambiar los códecs (por ejemplo, SILK del cliente de Teams a MP y G.711 entre MP y SBC).
Los relés de transporte no son B2BUA, lo que significa que el códec nunca se cambia entre el cliente y el SBC-- incluso si el tráfico fluye a través de los relés.
Uso de procesadores multimedia de Teams si el tronco está configurado para omisión multimedia
Los procesadores multimedia de Teams siempre se insertan en la ruta de acceso multimedia en los siguientes escenarios:
- La llamada se escala de 1:1 a una llamada grupal
- La llamada va a un usuario federado de Teams
- La llamada se desvía o se transfiere a un usuario de Skype Empresarial
Asegúrese de que su SBC tiene acceso a los rangos procesadores de medios y relés de transporte como se describe a continuación.
Señalización SIP: FQDN
Para la señalización SIP, los requisitos de FQDN y firewall son los mismos que para los casos sin omitir.
Enrutamiento directo se ofrece en los siguientes entornos de Microsoft 365 u Office 365:
- Microsoft 365 u Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
Obtenga más información sobre entornos de Office 365 y de la administración pública de EE. UU. , como GCC, GCC High y DoD.
Entornos GCC de Microsoft 365, Office 365 y Office 365
Los puntos de conexión para enrutamiento directo son los tres FQDN siguientes:
sip.pstnhub.microsoft.com , FQDN global, debe probarse primero. Cuando el SBC envía una solicitud para resolver este nombre, los servidores DNS de Microsoft Azure devuelven una dirección IP que apunta al centro de datos de Azure principal asignado al SBC. La asignación se basa en métricas de rendimiento de los centros de datos y la proximidad geográfica al SBC. La dirección IP devuelta corresponde al FQDN principal.
sip2.pstnhub.microsoft.com ( FQDN secundario ) se asigna geográficamente a la región de segunda prioridad.
sip3.pstnhub.microsoft.com ( FQDN terciario ) se asigna geográficamente a la tercera región de prioridad.
Debe colocar estos tres FQDN para:
Ofrezca una experiencia óptima (menos cargada y más cercana al centro de datos SBC asignado consultando el primer FQDN).
Proporcionar conmutación por error cuando se establece una conexión desde un SBC a un centro de datos que experimenta un problema temporal. Para obtener más información, consulte mecanismo de conmutación por error a continuación.
Los FQDN sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com y sip3.pstnhub.microsoft.com se resolverán en las direcciones IP de las siguientes subredes:
- 52.112.0.0/14
- 52.120.0.0/14
Debe abrir puertos para todos estos intervalos IP en el firewall para permitir el tráfico entrante y saliente hacia y desde las direcciones para la señalización.
Entorno de DoD GCC de Office 365
El punto de conexión para enrutamiento directo es el siguiente FQDN:
sip.pstnhub.dod.teams.microsoft.us : FQDN global. Como el entorno de DoD de Office 365 solo existe en los centros de datos de Ee. UU., no hay FQDN secundarios y terciarios.
El sip.pstnhub.dod.teams.microsoft.us fqdn se resolverá en una dirección IP desde la siguiente subred:
- 52.127.64.0/21
Debe abrir puertos para todos estos intervalos IP en el firewall para permitir el tráfico entrante y saliente hacia y desde las direcciones para la señalización. Si el firewall admite nombres DNS, el sip.pstnhub.dod.teams.microsoft.us FQDN se resuelve en todas estas subredes IP.
Entorno de Office 365 GCC High
El punto de conexión para enrutamiento directo es el siguiente FQDN:
sip.pstnhub.gov.teams.microsoft.us : FQDN global. Como el entorno GCC High existe solo en los centros de datos de EE. UU., no hay FQDN secundarios y terciarios.
El sip.pstnhub.gov.teams.microsoft.us FQDN se resolverá en una dirección IP desde la siguiente subred:
- 52.127.88.0/21
Debe abrir puertos para todos estos intervalos IP en el firewall para permitir el tráfico entrante y saliente hacia y desde las direcciones para la señalización. Si el firewall admite nombres DNS, el sip.pstnhub.gov.teams.microsoft.us FQDN se resuelve en todas estas subredes IP.
Señalización SIP: puertos
Los requisitos de puerto son los mismos para todos los entornos de Office 365 en los que se ofrece enrutamiento directo:
- Microsoft 365 u Office 365
- Office 365 GCC
- Office 365 GCC High
- Office 365 DoD
Debes usar los puertos siguientes:
| Tráfico | De | Hasta | Puerto de origen | Puerto de destino |
|---|---|---|---|---|
| SIP/TLS | SIP Proxy | SBC | 1024 - 65535 | Definido en el SBC |
| SIP/TLS | SBC | SIP Proxy | Definido en el SBC | 5061 |
Tráfico multimedia: intervalos de puertos y IP
El tráfico multimedia fluye entre el cliente de SBC y Teams si hay conectividad directa disponible o a través de retransmisiones de transporte de Teams si el cliente no puede llegar a la SBC con la dirección IP pública.
Requisitos para el tráfico multimedia directo (entre el cliente de Teams y el SBC)
El cliente debe tener acceso a los puertos especificados (ver tabla) en la dirección IP pública del SBC.
Nota
Si el cliente está en una red interna, los medios fluyen a la dirección IP pública del SBC. Puedes configurar el anclaje del pelo en el dispositivo NAT para que el tráfico nunca salga del equipo de red de la empresa.
| Tráfico | De | Hasta | Puerto de origen | Puerto de destino |
|---|---|---|---|---|
| UDP/SRTP | Cliente | SBC | 50000-50019 | Definido en el SBC |
| UDP/SRTP | SBC | Cliente | Definido en el SBC | 50000-50019 |
Nota
Si tiene un dispositivo de red que traduzca los puertos de origen del cliente, asegúrese de que los puertos traducidos se abran entre el equipo de red y el SBC.
Requisitos para usar relés de transporte
Los relés de transporte están en el mismo rango que los procesadores multimedia (para casos sin derivación):
Entornos GCC de Microsoft 365, Office 365 y Office 365
- 52.112.0.0 /14 (direcciones IP de 52.112.0.1 a 52.115.255.254)
Entorno de DoD GCC de Office 365
- 52.127.64.0/21
Entorno de Office 365 GCC High
- 52.127.88.0/21
El intervalo de puertos de los relés de transporte de Teams (aplicable a todos los entornos) se muestra en la tabla siguiente:
| Tráfico | De | Hasta | Puerto de origen | Puerto de destino |
|---|---|---|---|---|
| UDP/SRTP | Retransmisión de transporte | SBC | 50000-59999 | Definido en el SBC |
| UDP/SRTP | SBC | Retransmisión de transporte | Definido en el SBC | 50000–59999, 3478-3481 |
Nota
Microsoft recomienda al menos dos puertos por llamada simultánea en el SBC. Como Microsoft tiene dos versiones de relés de transporte, son necesarias las siguientes:
v4, que solo puede trabajar con el intervalo de puertos de 50000 a 59999
v6, que funciona con el intervalo de puertos 3478 a 3481
Requisitos para usar procesadores multimedia
Los procesadores multimedia siempre están en la ruta de acceso multimedia para las aplicaciones de voz y para los clientes web (por ejemplo, los clientes de Teams en Microsoft Edge o Google Chrome). Los requisitos son los mismos que para la configuración que no es de omisión.
El intervalo IP para el tráfico multimedia es:
Entornos GCC de Office 365 y Office 365
- 52.112.0.0 /14 (direcciones IP de 52.112.0.1 a 52.115.255.254)
Entorno de DoD GCC de Office 365
- 52.127.64.0/21
Entorno de Office 365 GCC High
- 52.127.88.0/21
El rango de puertos de los procesadores multimedia (aplicables a todos los entornos) se muestra en la tabla siguiente:
| Tráfico | De | Hasta | Puerto de origen | Puerto de destino |
|---|---|---|---|---|
| UDP/SRTP | Procesador multimedia | SBC | 3478-3481 y 49152-53247 | Definido en el SBC |
| UDP/SRTP | SBC | Procesador multimedia | Definido en el SBC | 3478-3481 y 49152-53247 |
Configurar troncos independientes para la omisión de medios y la omisión no multimedia
Si va a migrar a la omisión de medios desde la omisión de medios y desea confirmar la funcionalidad antes de migrar todo el uso a la omisión de medios, puede crear un tronco independiente y una directiva de enrutamiento de voz en línea independiente para redirigir al tronco de omisión de medios y asignarlo a usuarios específicos.
Pasos de configuración de alto nivel:
Identifique a los usuarios para probar la omisión de medios.
Crear dos troncos independientes con FQDN diferentes: uno habilitado para la omisión de medios; el otro no.
Ambos troncos apuntan al mismo SBC. Los puertos para la señalización SIP TLS deben ser diferentes. Los puertos para los medios deben ser los mismos.
Cree una nueva directiva de enrutamiento de voz en línea y asigne el tronco de omisión de medios a las rutas correspondientes asociadas con el uso de RTC para esta directiva.
Asigne la nueva directiva de enrutamiento de voz en línea a los usuarios que haya identificado para probar la omisión de medios.
En el ejemplo siguiente se muestra esta lógica.
| Conjunto de usuarios | Número de usuarios | FQDN de tronco asignado en OVRP | Omisión de medios habilitada |
|---|---|---|---|
| Usuarios con tronco de omisión no multimedia | 980 | sbc1.contoso.com:5061 | falso |
| Usuarios con tronco de omisión multimedia | 20 | sbc2.contoso.com:5060 | verdadero |
Ambos troncos pueden apuntar al mismo SBC con la misma dirección IP pública. Los puertos de señalización TLS en el SBC deben ser diferentes, como se muestra en el siguiente diagrama. Tenga en cuenta que tendrá que asegurarse de que su certificado admita ambos troncos. En SAN, debe tener dos nombres (sbc1.contoso.com y sbc2.contoso.com) o tener un certificado comodín.
Para obtener información sobre cómo configurar dos troncos en el mismo SBC, consulte la documentación proporcionada por su proveedor de SBC:
- Documentación de implementación de AudioCodes
- Documentación de implementación de Oracle
- Documentación de implementación de comunicaciones de la cinta de opciones
- Documentación de implementación de TE-Systems (anynode)
Puntos de conexión de cliente compatibles con la omisión de medios
La omisión de medios es compatible con todos los clientes de escritorio independientes de Teams, los clientes de Android e iOS y los dispositivos de teléfono de Teams.
Para todos los demás puntos de conexión que no admiten la omisión multimedia, convertiremos la llamada en no omisión incluso si se inició como una llamada de omisión. Esta conversión se realiza automáticamente y no requiere ninguna acción del administrador. Esto incluye los teléfonos 3PIP de Skype Empresarial y los clientes web de Teams que admiten llamadas de enrutamiento directo (clientes basados en WebRTC que se ejecutan en Microsoft Edge, Google Chrome y Mozilla Firefox).