Novedades del enrutamiento directo

  • Artículo
  • Se aplica a:
    Microsoft Teams

En este artículo se describen las novedades de enrutamiento directo. Vuelve a comprobarlo con frecuencia si hay actualizaciones.

Prueba de extensiones EKU de certificados SBC

El 5 de marzo de 2024 (a partir de las 9 a.m. UTC), Microsoft realizará una prueba de 24 horas de su infraestructura. Durante este tiempo, se requieren certificados de controladores de borde de sesión (SCS) para incluir autenticación de cliente y de servidor para sus extensiones de uso extendido de claves (EKU). Le pedimos que se asegure de que la extensión EKU de su certificado incluya autenticación de servidor y autenticación de cliente para evitar cualquier degradación del servicio.

Si la extensión EKU del certificado SBCs no incluye autenticación de servidor y cliente, los SBCs no podrán conectarse con la infraestructura de Microsoft.

Tenga en cuenta que el cambio final para solicitar autenticación de servidor y cliente para EKU se realizará el 19 de marzo de 2024.

Para obtener más información, vea Certificado de confianza público para el SBC.

Cambio de certificado SIP a entidad emisora de certificados MSPKI en nubes de DoD y GCCH

Microsoft 365 actualiza los servicios que potencian la mensajería, las reuniones, la telefonía, la voz y el vídeo para usar certificados TLS de un conjunto diferente de entidades emisoras de certificados raíz (CA). Entre los puntos de conexión afectados se incluyen los puntos de conexión SIP de enrutamiento directo de Microsoft Teams que se usan para el tráfico RTC en las implementaciones de Office 365 Administración Pública - GCC High (GCCH) y DoD. La transición a los certificados emitidos por la nueva CA para los puntos de conexión SIP comienza en mayo de 2024. Esto significa que es necesario tomar medidas antes de finales de abril de 2024.

La nueva CA raíz "DigiCert Global Root G2" es ampliamente confiable por los sistemas operativos que incluyen Windows, macOS, Android e iOS y por exploradores como Microsoft Edge, Chrome, Safari y Firefox. Sin embargo, es probable que su SBC tenga un almacén raíz de certificados que se haya configurado manualmente. Si es así, DEBE ACTUALIZAR SU ALMACÉN DE CA SBC PARA INCLUIR LA NUEVA CA PARA EVITAR EL IMPACTO EN EL SERVICIO. Los SBA que no tienen la nueva CA raíz en su lista de CA aceptables reciben errores de validación de certificado, que pueden afectar a la disponibilidad o la función del servicio. Tanto la CA antigua como la nueva CA DEBEN ser de confianza por el SBC: no quite la CA antigua. Consulte la documentación del proveedor de SBC sobre cómo actualizar la lista de certificados aceptados en su SBC. El SBC debe confiar tanto en los certificados raíz antiguos como en los nuevos. Hoy en día, los certificados TLS utilizados por las interfaces SIP de Microsoft encadenan hasta la ca raíz siguiente:

Nombre común de la CA: DigiCert Global Root CA Thumbprint (SHA1): a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436 El antiguo certificado de CA se puede descargar directamente desde DigiCert: http://cacerts.digicert.com/DigiCertGlobalRootCA.crt

Los nuevos certificados TLS usados por las interfaces SIP de Microsoft ahora se encadenan a la siguiente CA raíz: Nombre común de la CA: DigiCert Global Root G2 Thumbprint (SHA1): df3c24f9bfd666761b268073fe06d1cc8d4f82a4 El nuevo certificado de CA se puede descargar directamente desde DigiCert: https://cacerts.digicert.com/DigiCertGlobalRootG2.crt

Para obtener más detalles, consulte la guía técnica en https://docs.microsoft.com/en-us/microsoft-365/compliance/encryption-office-365-tls-certificates-changes?view=o365-worldwide Para probar y confirmar la configuración del certificado SBCs antes del cambio, Microsoft ha preparado un punto final de prueba que se puede usar para comprobar que los dispositivos SBC confían certificados emitidos desde la nueva CA raíz (DigiCert Global Root G2). Si su SBC puede establecer una conexión TLS a este punto de conexión, la conectividad a los servicios de Teams no debería verse afectada por el cambio. Estos puntos de conexión deben usarse solo para los mensajes ping de OPCIONES SIP y no para el tráfico de voz. No son puntos de conexión de producción y no están respaldados por una configuración redundante. Esto significa que experimentarán tiempo de inactividad que dura varias horas( esperamos aproximadamente un 95 % de disponibilidad.

FQDN del punto de conexión de prueba para GCCH: puerto de x.sip.pstnhub.infra.gov.teams.microsoft.us: 5061

FQDN del punto de conexión de prueba para DoD: puerto de x.sip.pstnhub.infra.dod.teams.microsoft.us: 5061

Conmutador final de certificado SIP a nueva entidad emisora de certificados MSPKI

Después de dos pruebas el 5 y 19 de septiembre, Microsoft realizará el cambio final a la nueva entidad emisora de certificados (CA) el 3 de octubre, a partir de las 10 a.m. UTC. Todos los puntos de conexión SIP de Microsoft se cambian gradualmente para usar certificados donde la cadena de certificados se une a entidad de certificación (CA) "DigiCert Global Root G2".

Si los controladores de borde de sesión (SBCs) no están correctamente configurados con la nueva entidad emisora de certificados, las llamadas entrantes y salientes de enrutamiento directo provocarán un error después del cambio. Trabaje directamente con su proveedor de SBC para obtener más información sobre la configuración de SBC.

El requisito de cambio y la prueba se comunicaron a los clientes de enrutamiento directo a través de las publicaciones del Centro de mensajes, así como los incidentes de estado del servicio en el Portal de Microsoft Administración (MC540239, TM614271, MC663640, TM674073 MC674729).

El certificado SIP a la entidad emisora de certificados MSPKI cambia las pruebas adicionales

El 19 de septiembre (a partir de las 16:00 UTC), Microsoft realizará una prueba de 24 horas en la que todos los puntos de conexión SIP de Microsoft se cambiarán para usar certificados, donde la cadena de certificados se resumirá en la entidad de certificación (CA) "DigiCert Global Root G2". Debe agregarse una nueva entidad de certificación (CA) a la configuración de SBC y conservar la antigua CA de Baltimore; no reemplaces la ca antigua. Si su SBC no confía en esta entidad de certificación, no podrá conectarse a los puntos de conexión SIP de Teams durante la prueba. El cambio final a la nueva entidad de certificación (CA) se realizará el 3 de octubre.

Si desea probar y confirmar la configuración del certificado SBCs antes del cambio, Microsoft ha preparado un punto final de prueba que puede usar para comprobar que los dispositivos SBC confían en los certificados emitidos desde la nueva CA raíz (DigiCert Global Root G2). Este punto de conexión solo debe usarse para los mensajes ping de OPCIONES SIP y no para el tráfico de voz. Si su SBC puede establecer una conexión TLS a este punto de conexión, la conectividad a los servicios de Teams no debería verse afectada por el cambio.

FQDN del punto de conexión de prueba: sip.mspki.pstnhub.microsoft.com

Puerto: 5061

Prueba de cambio de certificado SIP a entidad emisora de certificados MSPKI

El 5 de septiembre (a partir de las 9 a.m. UTC), Microsoft realizará una prueba de 24 horas en la que todos los puntos de conexión SIP de Microsoft se cambiarán para usar certificados donde la cadena de certificados se resumirá en entidad de certificación (CA) "DigiCert Global Root G2". Si su SBC no confía en esta entidad de certificación, es posible que no pueda conectarse a los puntos de conexión SIP de Teams.

Si desea probar y confirmar la configuración del certificado SBCs antes del cambio, Microsoft ha preparado un punto final de prueba que se puede usar para comprobar que los dispositivos SBC confían en los certificados emitidos desde la nueva CA raíz (DigiCert Global Root G2). Este punto de conexión solo debe usarse para los mensajes ping de OPCIONES SIP y no para el tráfico de voz. Si su SBC puede establecer una conexión TLS a este punto de conexión, la conectividad a los servicios de Teams no debería verse afectada por el cambio.

FQDN del punto de conexión de prueba: sip.mspki.pstnhub.microsoft.com

Puerto: 5061

Cambio de certificado SIP a entidad emisora de certificados MSPKI

Microsoft 365 actualiza los servicios que potencian la mensajería, las reuniones, la telefonía, la voz y el vídeo para usar certificados TLS de un conjunto diferente de entidades emisoras de certificados raíz (CA). Este cambio se está realizando porque la CA raíz actual expira en mayo de 2025. Entre los puntos de conexión afectados se incluyen todos los puntos de conexión SIP de Microsoft usados para el tráfico RTC que usan la conectividad TLS. La transición a los certificados emitidos por la nueva CA comienza a finales de agosto.

La nueva CA raíz "DigiCert Global Root G2" es ampliamente confiable por los sistemas operativos que incluyen Windows, macOS, Android e iOS y por exploradores como Microsoft Edge, Chrome, Safari y Firefox. Sin embargo, es probable que su SBC tenga un almacén raíz de certificados configurado manualmente y que deba actualizarse. Los SBA que no tienen la nueva CA raíz en su lista de CA aceptables reciben errores de validación de certificado, que pueden afectar a la disponibilidad o la función del servicio. Consulte la documentación del proveedor de SBC sobre cómo actualizar la lista de certificados aceptados en su SBC.

Hoy en día, los certificados TLS utilizados por las interfaces SIP de Microsoft encadenan hasta la ca raíz siguiente:

Nombre común de la CA: Baltimore CyberTrust Root Thumbprint (SHA1): d4de20d05e66fc53fe1a50882c78db2852cae474

Los nuevos certificados TLS utilizados por las interfaces SIP de Microsoft ahora se encadenan a la siguiente CA raíz:

Nombre común de la CA: Huella digital de DigiCert Global Root G2 (SHA1): df3c24f9bfd666761b268073fe06d1cc8d4f82a4

El nuevo certificado de CA se puede descargar directamente desde DigiCert: DigiCert Global Root G2.

Para obtener más información, vea Cambios de certificados de Office TLS

Nuevos puntos de conexión SIP de enrutamiento directo

Microsoft presentará nuevos IP de señalización para los puntos de conexión SIP de enrutamiento directo de Teams. Para asegurarse de que este cambio no afecta a la disponibilidad del servicio, asegúrese de que el controlador de borde de sesión y el firewall están configurados para usar las subredes recomendadas 52.112.0.0/14 y 52.122.0.0/15 para las reglas de clasificación y ACL. Para obtener más información, consulte Entornos GCC de Microsoft 365, Office 365 y Office 365.

Trunk demoting logic based on SIP Options

Una nueva característica basada en las opciones del SIP se introduce para el estado del tronco. Cuando se habilita en la configuración de la puerta de enlace (vea el cmdlet de Set-CsOnlinePSTNGateway y el parámetro SendSipOptions), la lógica de enrutamiento para las llamadas salientes degrada los troncos que no envían opciones SIP periódicamente (el período esperado es una opción SIP enviada por el SBC por minuto) al back-end de Microsoft. Estos troncos degradados se ponen al final de la lista de troncos disponibles para la llamada saliente y se intentan en último lugar, que potencialmente disminuye el tiempo de configuración de la llamada.

Cualquier tronco habilitado para esa característica que no envíe al menos una opción SIP dentro de cinco minutos a cualquiera de los servidores proxy SIP regionales de Microsoft (NOAM, EMEA, APAC, OCEA) se considera degradado. Si un tronco envía opciones SIP solo a un subconjunto de servidores proxy sip regionales de Microsoft, estas rutas se prueban primero y el resto se degradan.

Nota

Cualquier SBC (configurado en el inquilino del cliente o del operador con SendSipOptions establecido entrue) que no envíe OPCIONES SIP se disminuirá. Los clientes que no quieran ese comportamiento deben establecer SendSipOptions en false en su configuración de SBC. Lo mismo se aplica a los troncos del operador en los que la configuración de SBC se encuentra en el operador o en el inquilino del cliente. En estos casos, cuando SendSipOptions se establece en true, el SBC envía OPCIONES SIP.

Compatibilidad con SIP

El 1 de junio de 2022, Microsoft quitará la compatibilidad con fqdN de sip-all.pstnhub.microsoft.com y sip-all.pstnhub.gov.teams.microsoft.us de la configuración de enrutamiento directo.

Si no se realiza ninguna acción antes del 1 de junio, los usuarios no podrán realizar ni recibir llamadas a través del enrutamiento directo.

Para evitar el impacto en el servicio:

  • Utilice las subredes recomendadas: (52.112.0.0/14 y 52.120.0.0/14) para cualquier clasificación o reglas ACL.
  • Deje de usar el FQDN de sip-all al configurar los controles de borde de sesión para el enrutamiento directo.

Para obtener más información, consulte Planear el enrutamiento directo.

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.

Certificados TLS

Microsoft 365 está actualizando Teams y otros servicios para usar un conjunto diferente de entidades de certificación raíz (CA).

Para obtener más información y una lista completa de los servicios afectados, consulte Cambios de certificados TLS en los servicios de Microsoft 365, incluido Microsoft Teams.

Entidades emisoras de certificados

A partir del 1 de febrero de 2022, la interfaz SIP de enrutamiento directo solo confiará en certificados firmados por entidades de certificación (CA) que forman parte del Programa de certificados raíz de confianza de Microsoft. Siga estos pasos para evitar el impacto en el servicio:

  • Asegúrese de que su certificado SBC esté firmado por una CA que formen parte del Programa de certificados raíz de confianza de Microsoft.
  • Compruebe que la extensión de uso de claves extendida (EKU) de su certificado incluya "Autenticación de servidor".

Para obtener más información sobre el Programa de certificados raíz de confianza de Microsoft, consulte Requisitos del programa: programa raíz de confianza de Microsoft.

Para obtener una lista de CA de confianza, consulte Lista de certificados de CA incluidos de Microsoft.

Reemplazar encabezados

A partir de abril de 2022, El enrutamiento directo rechaza las solicitudes SIP que tienen encabezados Replaces definidos. No hay cambios en los flujos en los que Microsoft envía el encabezado Replaces al controlador de borde de sesión (SBC).

Compruebe las configuraciones de SBC y asegúrese de que no está usando los encabezados Replaces en las solicitudes SIP.

TLS1.0 y 1.1

Para proporcionar el mejor cifrado de su clase a nuestros clientes, Microsoft planea desusar las versiones 1.0 y 1.1 de la Seguridad de la capa de transporte (TLS). El 3 de abril de 2022, Microsoft forzará el uso de TLS1.2 para la interfaz SIP de enrutamiento directo.

Para evitar cualquier impacto en el servicio, asegúrese de que sus SBCs están configurados para admitir TLS1.2 y puede conectarse mediante uno de los siguientes conjuntos de cifrado:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 es decir, ECDHE-RSA-AES256-GCM-SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 es decir, ECDHE-RSA-AES128-GCM-SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 es decir, ECDHE-RSA-AES256-SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 es decir, ECDHE-RSA-AES128-SHA256