Compartir vía


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:

Muestra la señalización y el flujo de medios sin derivación de medios.

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:

    Muestra la señalización y el flujo de medios con la omisión de medios.

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.

El diagrama muestra el flujo de llamada con la omisión de medios habilitada, el cliente es interno y el cliente puede llegar a la dirección IP pública del SBC.

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).

El 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 SBC.

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.

El diagrama muestra el flujo de llamada cuando la omisión de medios está habilitada, el cliente es externo y el cliente puede alcanzar la dirección IP pública del SBC.

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.

El diagrama muestra los flujos de llamada con la omisión de medios habilitada y deshabilitada.

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)* 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.

Muestra ambos troncos pueden señalar al mismo SBC con el mismo IP público.

Para obtener información sobre cómo configurar dos troncos en el mismo SBC, consulte la documentación proporcionada por su proveedor de SBC:

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).

Vea también

Configurar el desvío de medios con enrutamiento directo