Resolución de problemas del SBC en Teams Direct Routing: fallas de SIP OPTIONS, errores TLS, problemas de audio y desactivación de dominio

Microsoft Teams Direct Routing tiene un modo de falla frustrante: Teams rara vez le indica por qué algo dejó de funcionar. El troncal de Direct Routing del SBC pasa de “Active” a “Inactive” en el centro de administración, las llamadas dejan de conectarse, y la única señal operativa que recibe es la ausencia de una.El lado de Microsoft de la conexión es una caja negra; todo lo que se puede diagnosticar está en el suyo.

Esa es la razón de esta guía. Recorre las categorías de fallas que surgen en despliegues de producción reales (fallas de heartbeat SIP OPTIONS, errores de handshake TLS, problemas de audio en un solo sentido y sin audio, desactivación de dominio en Direct Routing, peculiaridades de NAT y firewall específicas de Teams DR) y le ofrece un orden de triaje que resuelve la mayoría de los incidentes en menos de una hora. Asume que el SBC ya está desplegado y funcionó correctamente en algún momento del pasado, y que usted tiene acceso al rastreo de llamada, la captura de paquetes y la configuración del perfil TLS del SBC. Si todavía se encuentra en una instalación desde cero, la guía de Teams Direct Routing cubre los requisitos y la configuración inicial; este artículo continúa donde aquel termina.

El modelo mental de tres capas para el triaje

Casi todos los problemas de Teams Direct Routing se reducen a una falla en una de tres capas, y el síntoma que usted observa le indica cuál debe examinar primero. Construir este modelo mental es la diferencia entre treinta minutos de triaje y tres horas de conjeturas.

Capa de señalización. El handshake TLS y el intercambio SIP entre el proxy SIP de Microsoft y su SBC. Las fallas aquí producen troncales marcados como “Inactive”, errores sostenidos de SIP OPTIONS y llamadas que nunca llegan al estado de timbre.

Capa de medios. El intercambio SRTP/RTP entre Teams (o el Teams Media Processor) y su SBC, y luego entre el SBC y el operador. Las fallas aquí producen llamadas que se conectan y se contestan normalmente pero no tienen audio, tienen audio en un solo sentido, o el audio se corta de manera aleatoria después de poner en espera o retomar una llamada.

Capa de aplicación. Las políticas de enrutamiento de Teams, las rutas de voz, los planes de marcado, la asignación de licencias de usuario y las reglas de enrutamiento del SBC. Las fallas aquí producen usuarios específicos o patrones de marcado específicos que fallan mientras todo lo demás funciona.

El error que comete la mayoría de los equipos es lanzarse a una captura de paquetes antes de clasificar en qué capa está la falla. La tabla de triaje rápido a continuación está diseñada para hacer esa clasificación de forma rápida, en dos columnas de toma de decisiones antes de abrir Wireshark.

Triaje rápido: del síntoma a la causa probable

Asocie lo que está observando con la causa más probable y la capa que debe investigar primero. La mayoría de los incidentes en producción coinciden con una de estas filas.

Una vez identificada la capa, la sección correspondiente a continuación contiene el detalle del diagnóstico.

Fallas de SIP OPTIONS: la interrupción más común

La falla de SIP OPTIONS es la causa más común de una interrupción de Teams DR que afecta a todo el sistema en lugar de a la llamada de un usuario específico. Comprender qué hace OPTIONS, y exactamente cómo reacciona Teams cuando deja de funcionar, le lleva a la causa raíz más rápido que una captura de paquetes.

Es un intercambio coordinado en ambos lados: Microsoft envía OPTIONS al FQDN de su SBC en el puerto TLS 5061, espera un 200 OK en pocos segundos y repite aproximadamente cada minuto. Su SBC hace lo mismo en la dirección inversa, enviando OPTIONS al proxy SIP regional de Microsoft y esperando un 200 OK de vuelta. Ambas direcciones deben tener éxito continuamente para que Teams considere el troncal como saludable. Si cualquiera de las dos direcciones falla de forma sostenida durante varios minutos, Teams cambia el FQDN a “Inactive” y deja de enrutar llamadas hacia o desde ese SBC.

OPTIONS falla por un problema de TLS o resolución DNS, no de SIP. La causa raíz más frecuente de una falla de OPTIONS no es la solicitud OPTIONS en sí, sino el handshake TLS que debe completarse exitosamente antes de que se pueda enviar cualquier solicitud SIP. Si TLS falla, ninguna solicitud OPTIONS se intercambia, el SBC no ve nada y Microsoft ve una ausencia total de respuesta. La sección de handshake TLS a continuación cubre esas causas raíz en detalle.

OPTIONS falla porque el SBC dejó de enviar o la resolución DNS falló. La dirección inversa (SBC hacia Microsoft) se interrumpe si el NAP saliente hacia Microsoft está mal configurado, si su perfil TLS apunta al certificado equivocado, o si una regla de enrutamiento bloquea el método SIP OPTIONS en la ruta de salida. La señal en el registro del SBC es “no response” o “timeout” contra la dirección del proxy SIP de Microsoft, sin un 200 OK entrante correspondiente.

El 200 OK que parece correcto pero no lo es. Un SBC puede responder al OPTIONS de Microsoft con un 200 OK que contiene encabezados Contact o Via que Teams no acepta. Teams trata la respuesta como malformada y puede seguir marcando el FQDN como “Inactive” a pesar del aparente éxito. Si el registro del SBC muestra que OPTIONS se recibe y se envía un 200 OK, pero el troncal sigue “Inactive”, capture el 200 OK completo en un rastreo de paquetes e inspeccione cada encabezado. El encabezado Contact debe referirse al FQDN del SBC, no a su IP, y la cadena del encabezado Via debe ser válida.

Cómo decide Teams desactivar. Microsoft no publica umbrales exactos, pero en la práctica una falla sostenida de OPTIONS (varios minutos consecutivos de falla en cualquier dirección) es suficiente para cambiar el troncal a “Inactive”. La recuperación no siempre es inmediata cuando se corrige la causa: Teams típicamente espera un éxito sostenido antes de volver a “Active”, lo que puede tomar de cinco a quince minutos después de que la corrección real esté implementada. No asuma que su corrección no funcionó solo porque el centro de administración tarda en actualizarse.

Fallas de handshake TLS

Las fallas de TLS son la causa raíz más común de una interrupción de Direct Routing, y tienen un conjunto reducido de desencadenantes bien conocidos. La tabla a continuación los resume, con la señal de registro que puede usar para confirmar cada uno y la corrección correspondiente.

Dos de estos desencadenantes merecen un análisis más detallado. La actualización de CA raíz de Microsoft que entró en vigor durante 2026 causó una ola de fallas “Unknown CA” en despliegues de Direct Routing porque el almacén de confianza del SBC no contenía las nuevas raíces de DigiCert y Microsoft 2017 que Microsoft comenzó a presentar en sus certificados de servidor. Si su SBC tiene la configuración de confianza anterior y su troncal ha estado intermitente o inactivo desde principios de 2026, esa es la causa más probable y la resolución es importar las siete CA raíz requeridas en el almacén de confianza.

El otro desencadenante a vigilar es el desajuste de FQDN después de una renovación de certificado. Las renovaciones a veces omiten una entrada de Subject Alternative Name (SAN), especialmente en despliegues multi-tenant donde el SBC presenta un certificado comodín que cubre varios subdominios. Después de cada renovación de certificado, ejecute una prueba TLS contra el FQDN del SBC en el puerto 5061 y confirme que el certificado servido incluye cada FQDN registrado para ese SBC en Teams. La guía de configuración de TLS y SRTP del SBC cubre los patrones de configuración completos; este artículo se enfoca en lo que los rompe.

Problemas de audio en un solo sentido y sin audio

Cuando la señalización funciona (las llamadas se conectan, el teléfono del destinatario suena, ambos lados contestan) pero falta audio en una o ambas direcciones, el problema está en la ruta de medios. La parte difícil del triaje de medios es que hay varias causas distintas que producen el mismo síntoma general, y solo una captura de paquetes o un reporte MOS por llamada permite diferenciarlas.

Desajuste en el contexto criptográfico SRTP. Ambos extremos acuerdan SRTP en el SDP, pero la clave criptográfica, la suite de cifrado o la longitud de la etiqueta de autenticación no coinciden. El lado de Teams requiere AES-CM con HMAC-SHA1; si el SDP del lado del operador ofrece un cifrado diferente u omite el atributo criptográfico, el SBC negocia contextos inconsistentes en cada tramo y debe realizar el recifrado SRTP por sí mismo, con un costo en rendimiento y latencia. La corrección es imponer la lista de cifrado AES-CM en ambos perfiles NAP y confirmar que el SBC está realizando la reescritura criptográfica entre tramos en lugar de pasar el SDP sin modificar. La descripción general de SRTP cubre las opciones de cifrado en detalle.

Cambio de la clave criptográfica SRTP durante los intercambios SDP. Microsoft Teams requiere que la clave criptográfica SRTP permanezca igual durante toda la duración de la llamada. No debe producirse una renegociación de la clave SRTP; de lo contrario, el audio puede cortarse o descifrarse incorrectamente, e incluso Teams podría cortar la llamada.

La ruta de medios del SBC nunca se abre hacia un lado. Si el SBC tiene múltiples interfaces de red (una interfaz pública hacia Teams y una interfaz privada hacia el operador), el enrutamiento de medios debe asociarse explícitamente a la interfaz correcta por cada NAP. Una configuración errónea produce una ruta RTP semiabierta: el SBC envía medios hacia un lado y los paquetes de retorno van a una interfaz obsoleta. La señal es “no RTP received” en un tramo del rastreo de llamada, mientras el otro tramo muestra conteos de paquetes normales.

La traducción NAT interrumpe el puerto RTP entrante. Cuando el SBC está detrás de un NAT, la dirección pública anunciada en el SDP debe coincidir con la dirección que el firewall realmente mapea. Un modo de falla común es que los medios del SBC están asociados a su dirección privada, el SDP anuncia esa dirección, y el extremo remoto intenta enviar RTP a un destino no enrutable. La corrección es establecer la dirección de medios externa del SBC explícitamente en el NAP hacia Teams y confirmar que el firewall tiene un mapeo de puertos estable para el rango de medios.

Desajuste en la oferta/respuesta de códecs. Teams DR requiere SILK, OPUS o G.711 en el lado de Teams. Si el lado del operador ofrece AMR, GSM o iLBC y el SBC no tiene un transcodificador de hardware, el SBC negocia G.711 en el lado de Teams y no logra entregar medios en el lado del operador. La señal es “no compatible codec” o un 488 Not Acceptable Here en un tramo. Puede alinear la lista de códecs en el troncal del operador o agregar un transcodificador.

Media bypass habilitado sin preparación del firewall. Media bypass cambia la ruta de medios: en lugar de que los medios fluyan a través del Media Processor regional de Microsoft, fluyen directamente entre el cliente Teams y el SBC. El firewall del SBC ahora debe aceptar medios de todo el rango de IP de medios de Microsoft (no solo el rango del proxy SIP), y desde la internet pública en lugar de dentro de la red controlada de Microsoft. El bypass que funcionaba en laboratorio frecuentemente falla en producción porque ese cambio de firewall nunca se realizó.

El audio se corta en un intervalo preciso. El audio que se corta en el mismo intervalo es casi siempre un problema del temporizador de sesión SIP (RFC 4028) y no un problema de medios. Uno de los lados no está renovando la sesión mediante re-INVITE o UPDATE, el temporizador expira y la llamada se termina. El temporizador de sesión es el mensajero, no la causa raíz, que casi siempre es un problema de interoperabilidad en SRTP durante la negociación SDP que afecta la secuencia de rollover de los paquetes RTP. El paso de resolución de problemas sigue siendo configurar el SBC para que renueve la sesión en el lado que no lo está haciendo.

Dominio de Direct Routing marcado como “Inactive”

El estado “Inactive” en Teams Admin Center es la única señal operativa visible que Microsoft le proporciona, y es consecuencia de cualquier falla que lo haya causado. Trate “Inactive” como un síntoma, no como un diagnóstico.

El estado se muestra bajo Voice → Direct Routing → SBCs en Teams Admin Center, por cada FQDN de SBC. La página muestra la salud actual del SBC y la hora del último intercambio exitoso de SIP OPTIONS en cada dirección. Cuando el FQDN está “Inactive”, Teams deja de enrutar nuevas llamadas salientes a ese SBC y rechaza los INVITE entrantes desde él. Las llamadas en curso generalmente continúan hasta su terminación natural.

La secuencia de recuperación es consistente en la mayoría de los casos:

1. Confirme que el FQDN del SBC resuelve públicamente y que el SBC es alcanzable en TCP/TLS 5061 desde la internet pública.
2. Confirme la resolución DNS del SBC.
3. Confirme que el certificado del SBC no ha expirado e incluye el FQDN registrado en su SAN.
4. Confirme que el almacén de confianza del SBC incluye las CA raíz actuales de Microsoft (la cadena DigiCert Global Root G2 más las raíces Microsoft 2017, según lo requerido por la actualización de CA raíz de 2026).
5. Inspeccione el rastreo de llamada del SBC en busca de OPTIONS entrantes y salientes. Confirme que ambas direcciones están presentes y devuelven 200 OK.
6. Si ambas direcciones se ven saludables en el SBC y el troncal sigue “Inactive”, capture un rastreo de paquetes de la respuesta 200 OK e inspeccione cada encabezado. Los encabezados Contact o Via malformados son el problema silencioso de una respuesta que por lo demás es válida.

Si el FQDN nunca pasó a “Active” desde el inicio (un SBC nuevo que se está agregando), la causa raíz más probable es un desajuste de FQDN entre el SAN del certificado y el valor registrado en Teams, o que el DNS aún no se ha propagado para el FQDN. Ambos producen un “Inactive” indefinido sin recuperación; no hay una falla de la cual recuperarse porque la ruta de confianza nunca se estableció.

NAT y firewall: peculiaridades específicas de Teams DR

Las reglas genéricas de firewall para SIP no son suficientes para Teams Direct Routing. Microsoft utiliza un conjunto específico de direcciones de señalización, el rango de direcciones de medios es mucho mayor de lo que la mayoría de los equipos esperan, y la función de firewall con mayor probabilidad de interferir (SIP ALG) está habilitada por defecto en muchos firewalls empresariales. Tres cosas rompen Teams DR más que cualquier otra.

SIP ALG debe estar deshabilitado. Los SIP Application Layer Gateway reescriben encabezados SIP y direcciones SDP en tránsito, lo cual casi nunca es compatible con mTLS (el firewall no puede ver dentro del flujo cifrado para reescribirlo) y nunca es compatible con el comportamiento predecible de SDP que Teams espera. Si el firewall en la interfaz pública del SBC tiene SIP ALG habilitado, Teams DR funcionará de forma intermitente o no funcionará en absoluto, y el modo de falla se asemeja a un problema de medios o de encabezados SIP. Deshabilite SIP ALG en el firewall, sin excepciones. La descripción general de seguridad del SBC explica por qué la aplicación de políticas SIP debe residir en el SBC, no en el firewall.

El rango de direcciones de señalización de Microsoft debe ser alcanzable. La señalización de Teams DR proviene de un rango de IP documentado de Microsoft (los FQDN del proxy SIP sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com y sip3.pstnhub.microsoft.com resuelven dentro de ese rango). El firewall debe permitir TLS entrante en el puerto 5061 desde esas direcciones hacia el FQDN de su SBC. Microsoft actualiza este rango periódicamente; si su firewall usa una lista de permitidos estática, verá interrupciones intermitentes cuando Microsoft amplíe el rango. Puede usar reglas de permitidos basadas en FQDN o suscribirse al feed de URLs y rangos de direcciones IP de Microsoft.

El rango de direcciones de medios es mayor de lo que la gente espera. El Teams Media Processor usa un rango de direcciones; media bypass usa otro (la dirección del cliente Teams, que puede estar en cualquier parte de la internet pública). Si el firewall de su SBC solo abre el rango del Media Processor, media bypass fallará. Si desea usar bypass, el rango de puertos de medios del SBC debe ser accesible desde cualquier IP de origen, con el filtrado SIP del SBC realizando la validación por llamada en lugar del firewall.

Una peculiaridad adicional que aparece repetidamente: NAT asimétrico en un SBC con múltiples interfaces. Si el SBC tiene interfaces pública y privada separadas y la asociación de medios está mal configurada, el RTP sale por una interfaz y los paquetes de retorno llegan por la otra. El SBC los descarta porque el origen no coincide con la sesión establecida. Asocie los medios explícitamente a la interfaz correcta en el NAP hacia Teams.

Lectura de rastreos SIP para Teams DR

Una vez que la capa está identificada y las causas obvias se han eliminado, la herramienta de diagnóstico es el rastreo SIP. Las dos funciones de ProSBC más utilizadas para el triaje de Teams DR son el rastreo de llamada por NAP (que registra la señalización SIP a nivel de grupo de troncales) y la captura Wireshark en vivo (que proporciona visibilidad completa a nivel de paquetes sobre la mensajería SIP, la resolución DNS y los medios). Ambas se ejecutan en el SBC sin sondas externas.

Hay una lista breve de elementos a inspeccionar primero en cualquier rastreo de Teams DR.

El intercambio de OPTIONS. Confirme que OPTIONS se está recibiendo de Microsoft y se devuelve con un 200 OK. Confirme que OPTIONS se está enviando desde el SBC hacia Microsoft y que un 200 OK regresa. Si cualquier dirección está ausente, la relación de confianza está rota y el troncal estará “Inactive” sin importar cómo se vea el tráfico de llamadas.

El handshake TLS. Si tiene captura a nivel de paquetes, el handshake TLS le indica inmediatamente si el problema es validación de certificados, negociación de cifrado o desajuste de versión. Un handshake que se completa pero es seguido inmediatamente por una alerta TLS de Microsoft significa que el certificado pasó pero algo dentro del intercambio SIP fue inaceptable.

Los encabezados del 200 OK. Inspeccione los encabezados Contact y Via en el 200 OK de OPTIONS. Contact debe ser el FQDN de su SBC sobre el transporte configurado. Via debe reflejar el SBC, no un sistema posterior.

El SDP en el establecimiento de llamada. Para los casos de falla de audio, el SDP tanto en el INVITE como en el 200 OK de respuesta le indica la lista de códecs que cada lado ofreció, el atributo criptográfico SRTP y la dirección de medios. Compare la dirección anunciada con la dirección desde la que los medios realmente llegan. Las mejores prácticas de monitoreo VoIP cubren qué rastrear continuamente para que este tipo de triaje comience desde una línea base más completa.

Confirmación de reescritura de encabezados. Teams tiene un dialecto SIP específico, y un despliegue funcional de Teams DR casi siempre depende de la manipulación de encabezados SIP en el SBC para normalizar entre Teams y el operador. Si los encabezados no se están reescribiendo, el rastreo mostrará los encabezados de Teams pasando sin cambios al operador (o viceversa), y uno de los lados rechazará la llamada. Confirme que las reglas de reescritura en los NAP correspondientes están cargadas.

La guía de triaje

Cuando llega un incidente de Teams DR y solo sabe que “las llamadas no funcionan”, los pasos a continuación resuelven la mayoría de los casos en menos de una hora. Están ordenados por probabilidad, no por severidad.

1. Abra Teams Admin Center y verifique el estado del FQDN del SBC. Si muestra “Inactive”, el problema es de señalización y pase al paso 2. Si muestra “Active”, el problema es de medios o aplicación y pase al paso 5.
2. Confirme que el certificado del SBC no ha expirado y que el FQDN registrado coincide con un Subject Alternative Name en el certificado servido. La mayoría de los incidentes “Inactive” en la práctica son problemas de certificados.
3. Confirme que el almacén de confianza del SBC contiene las CA raíz actuales de Microsoft (la actualización de CA raíz de 2026 es el cambio más reciente a implementar). Las raíces faltantes producen fallas de handshake “Unknown CA” e “Inactive” inmediato.
4. Inspeccione el rastreo de llamada del SBC en busca de OPTIONS entrantes y salientes. Si el OPTIONS saliente está ausente, el NAP de salida hacia Microsoft está mal configurado. Si el OPTIONS entrante llega pero el 200 OK tiene un Contact o Via malformado, la respuesta es el problema.
5. Si el troncal está “Active” pero las llamadas entrantes no llegan al usuario, la causa está en la capa de aplicación de Teams (política de enrutamiento de voz, ruta de voz, plan de marcado, asignación de licencia, indicador de usuario habilitado para Teams Phone). El SBC está saludable; la configuración de Teams no lo está.
6. Si falta audio en llamadas que se conectan, capture un rastreo a nivel RTP y confirme que los medios llegan al SBC desde ambas direcciones. Medios faltantes en un lado indican un problema de ruta de medios o NAT; medios presentes pero sin audio indican un problema de contexto criptográfico SRTP.
7. Si el audio se corta en intervalos regulares, la causa típicamente son los temporizadores de sesión RFC 4028, no la ruta de medios. Configure el SBC para que renueve la sesión.
8. Si los problemas son nuevos y aparecieron sin un catalizador, verifique si el certificado expira en los próximos 30 días, si el timeout del NAT es menor que el intervalo de OPTIONS, y si hubo cambios recientes en el firewall o la configuración del operador.

Si llega al final de la guía y el problema no se ha resuelto, el siguiente paso es una captura de paquetes filtrada a la dirección del proxy SIP de Microsoft y las direcciones de medios relevantes. En ese punto, los datos necesarios para una escalación de soporte, ya sea a TelcoBridges, a su operador o a Microsoft, están disponibles.

Preguntas frecuentes