Configuración de fax T.38 en SBC: guía de configuración para ProSBC

El fax que “siempre funciona en la línea analógica” deja de funcionar el día que alguien reemplaza el PRI con una troncal SIP, y el ticket llega al ingeniero de red que no ha abierto el menú de fax del SBC en un año. T.38 se suponía que iba a resolver esto. En la práctica, la confiabilidad de T.38 se reduce a un puñado de ajustes en el SBC, un camino de tono limpio desde el terminal originante, y una NIC que no descarte silenciosamente paquetes con checksums UDP incorrectos.

Esta guía recorre el panel exacto de Fax Settings de ProSBC, los controles de NAT y codec que lo acompañan, y los pasos de verificación que convierten una implementación de T.38 inestable en una confiable. Para los fundamentos conceptuales sobre qué es T.38, cómo UDPTL difiere de RTP, y por qué el fax falla en redes VoIP en primer lugar, el artículo explicativo de fax sobre IP (T.38) es la pieza complementaria que conviene leer primero.

Lista de verificación previa antes de cambiar un solo ajuste

La mayoría de los tickets de “T.38 no funciona” se resuelven con uno de tres problemas que ningún ajuste del SBC corregirá: un terminal que no puede hacer T.38, un tono que nunca llega al SBC, o una NIC que descarta paquetes silenciosamente. Confirme estos antes de tocar el panel Fax Settings.

Ambos terminales pueden realmente negociar T.38 o G.711 passthrough. Un ATA, un servidor de fax o una pasarela PRI que solo admite fax G.711 nunca aceptará un re-INVITE T.38, sin importar cómo esté configurado el SBC. Confirme la compatibilidad en ambos tramos en la documentación del dispositivo antes de depurar el medio.

La ruta del fax está identificada de extremo a extremo. Conozca desde qué NAP se origina el fax, qué NAP lo termina, el operador en el medio, y si los mensajes re-INVITE atraviesan algún firewall o dispositivo NAT que pueda reescribir el SDP. La manipulación de encabezados SIP más arriba en la ruta puede eliminar o reescribir atributos que ProSBC necesita ver intactos.

Los offloads de NIC están desactivados si alguna vez ha visto errores de checksum UDP. Generic Receive Offload y UDP checksum offload en la NIC del SBC son un asesino conocido de T.38. Los tickets llegan con el síntoma “T.38 negocia, luego la página nunca se completa.” La solución está en la capa del SO (desactive los offloads relevantes con ethtool), no en el panel Fax Settings.

Un número de fax de prueba que falle de la misma manera cada vez. Las fallas intermitentes producen trazas intermitentes. Una llamada de prueba reproducible desde una máquina de fax conocida a un destino conocido, idealmente con un documento de una sola página, es lo que hace útil una captura de tbsigtrace.

Dónde se encuentran realmente los ajustes de fax de ProSBC

El comportamiento de fax en ProSBC se configura por perfil de NAP, no de forma global. La ruta en el portal web es Configuration By Web Portal Category → NAP Profiles → Fax Settings, y dentro de ese panel cinco páginas de modos distintos cubren las variantes operativas que podría necesitar.

• Configure Fax T38 para relay T.38 de extremo a extremo entre dos terminales que ambos lo negocian.
• Configure Fax Passthrough para fax G.711 desde analógico mantenido en audio de extremo a extremo.
• Configuring Fax Relay para el modo interno de relay de fax/módem utilizado en implementaciones estilo pasarela.
• Configure Fax NSE para interoperabilidad con Cisco Named Signaling Events, donde el extremo remoto espera señalización de fax/módem basada en NSE.
• Configure Fax VBD para passthrough de datos de banda de voz utilizado en algunos entornos legados.

Los perfiles tienen nombre (una convención común vista en implementaciones reales es algo como FAX_ISDN para el perfil histórico del lado PRI), y el mismo perfil puede asignarse a múltiples NAP. Si reconfigura un NAP de PRI a un terminal SIP, el mismo perfil de fax lo acompaña. Este es el patrón recomendado: configurar una vez, asignar según sea necesario.

Elección del modo correcto

La causa principal de fallas de fax es elegir el modo incorrecto para los terminales involucrados. La decisión está determinada por lo que cada tramo admite, no por lo que el SBC prefiere.

Fax T38 es la elección correcta cuando ambos tramos pueden negociar T.38. El SBC detecta el tono de fax, envía un re-INVITE y cambia el tramo de medios a UDPTL. Esta es la opción más resiliente sobre redes con pérdidas porque la redundancia UDPTL reconstruye los paquetes perdidos localmente sin retransmisión.

Fax Passthrough aplica cuando ambos tramos prefieren G.711 y la red entre ellos es confiable. No se emite re-INVITE, no se requiere transcodificación, y los módems de fax negocian sobre un flujo de audio G.711 ininterrumpido. Passthrough es sensible a la pérdida de paquetes; fax passthrough se vuelve cada vez menos confiable a medida que aumentan la pérdida de paquetes y el jitter.

Fax NSE y Fax VBD existen para casos específicos de interoperabilidad con fabricantes. Use Fax NSE cuando el extremo remoto es una pasarela Cisco que espera señalización NSE. Use Fax VBD cuando la implementación especifica comportamiento de datos de banda de voz en una troncal particular. Si ni el fabricante ni la especificación requieren estos modos, déjelos de lado.

Fax Relay es el modo interno de relay de fax/módem utilizado en topologías estilo pasarela donde ProSBC actúa como el terminal de relay en lugar de negociar con una pasarela downstream. Este es el escenario menos común en implementaciones modernas de SBC, pero permanece documentado para migraciones legadas.

Configuración de Fax T38 campo por campo

La página Configure Fax T38 expone un conjunto compacto de campos, y los mismos campos aparecen en los intercambios de soporte al cliente con suficiente frecuencia como para que su función sea bien comprendida. La lista a continuación documenta cada campo con el valor predeterminado seguro y la razón para desviarse de él.

Enable Fax/Modem Relay es el interruptor maestro. Debe estar marcado para que cualquier comportamiento T.38 surta efecto. Si está desmarcado, todos los demás campos del panel son inertes.

Detection Mode controla qué tan agresivamente ProSBC escucha los tonos de fax en el flujo de audio. Standard es el valor predeterminado documentado y el valor observado en implementaciones funcionales; recurra a una alternativa solo si un fabricante lo requiere explícitamente.

Relay Mode selecciona entre T38 (re-INVITE a UDPTL) y Passthrough (mantener el tramo en G.711 de principio a fin). Este es el campo único que cambia el modo operativo del perfil. Configúrelo en T38 para el recorrido de Fax T38; cámbielo a Passthrough cuando genuinamente desee preservar el tramo de audio de extremo a extremo.

Modem vs Fax Distinction toma un umbral en milisegundos y controla cómo el detector distingue un tono de fax de un tono de módem. Un valor de 0 ms trata todos los tonos detectados como fax, lo cual es el punto de partida correcto para implementaciones exclusivas de fax. Auméntelo solo cuando tenga tráfico de módem en la misma troncal y necesite que ProSBC enrute los dos de manera diferente.

Prevent direct invite in T.38 maneja el caso donde el lado originante abre la llamada con T.38 ya en su SDP inicial en lugar de comenzar en audio y hacer re-INVITE. Marque esta casilla cuando el extremo remoto solo puede manejar la secuencia de audio primero y tiene una pasarela upstream que siempre emite INVITE directos en T.38. Déjela desmarcada cuando ambos lados manejan T.38 directo sin problemas.

Detection Type cubre el ajuste del detector. “Silence suppression off” es el valor predeterminado seguro documentado; la supresión de silencio interactúa mal con los tonos de fax y es la fuente de más tickets de falla de los que resuelve.

Codec selecciona el codec del tramo de audio utilizado antes del re-INVITE. PCMU (G.711 µ-law) es el valor predeterminado documentado y el codec en el que convergen las implementaciones funcionales. Configúrelo para que coincida con el codec del tramo orientado al operador en su tramo de audio; no liste G.729 aquí, ya que el fax no puede sobrevivir a la compresión con pérdida.

Atributos SDP de T.38 que verá en la captura

Cuando el re-INVITE se dispara y el tramo de medios cambia a UDPTL, el cuerpo SDP anuncia un conjunto específico de atributos T.38. Conocer los valores predeterminados hace que trazar el flujo de llamada sea mucho más rápido, porque cada valor a continuación es algo que puede buscar en una captura y confirmar contra lo esperado.

• m=image <port> udptl t38 es la línea de medios que señala el cambio de audio RTP a UDPTL.
• a=T38FaxVersion:0 es la versión ofrecida por defecto. La mayoría de los terminales de fax negocian la versión 0 exitosamente; existen anulaciones de versión pero rara vez son necesarias.
• a=T38MaxBitRate:14400 es la tasa de bits máxima del módem ofrecida, coincidiendo con el estándar de fax V.17.
• a=T38FaxRateManagement:transferredTCF ubica la gestión del Training Check Frame en el extremo remoto en lugar de localmente.
• a=T38FaxMaxBuffer:200 y a=T38FaxMaxDatagram:200 describen los tamaños de búfer y datagrama ofrecidos.
• a=T38FaxUdpEC:t38UDPRedundancy declara la redundancia UDPTL como el método de corrección de errores, la opción que compensa la pérdida de paquetes transportando copias de paquetes IFP anteriores.

Capture una llamada de fax conocida y exitosa en su propia implementación primero para confirmar exactamente qué ofrece ProSBC en su entorno. La normalización del lado del operador puede reescribir cualquiera de estos valores antes de que salgan del SBC, y los valores que ve en el tramo orientado al operador pueden diferir de los que ve en el tramo orientado al terminal.

NAT, Force Passive Mode y la trampa en la que la mayoría cae

La configuración NAT a nivel de NAP interactúa con T.38 de una manera que atrapa a muchas implementaciones. El ajuste relevante es Remote Method for RTP en la página de configuración NAT del NAP, y uno de sus valores, Force Passive Mode, cambia cuándo ProSBC abre el puerto RTP.

Con Force Passive Mode configurado, ProSBC espera a que llegue el primer paquete RTP del extremo remoto antes de abrir su puerto RTP. El comportamiento es correcto para escenarios de recorrido de NAT donde el extremo remoto está detrás de un firewall con estado y ProSBC debe aprender la dirección traducida externamente a partir del tráfico observado. La desventaja es que si el extremo remoto nunca envía primero, el puerto nunca se abre, y la negociación T.38 parece completarse exitosamente a nivel SIP pero ningún paquete UDPTL fluye.

El diagnóstico es directo: una captura de tbsigtrace que muestra el intercambio de re-INVITE y 200 OK completándose limpiamente, ningún paquete UDPTL en ninguna dirección, y la llamada eventualmente agotando el tiempo de espera. La solución depende de la topología. Donde ProSBC realmente enfrenta un peer con NAT, Force Passive Mode es la elección correcta y el lado originante necesita configurarse para enviar el primer paquete. Donde ProSBC enfrenta una pasarela sin NAT, Force Passive Mode es la elección incorrecta y Remote Method debe configurarse a un valor que permita a ProSBC abrir el puerto inmediatamente.

Cuándo G.711 passthrough es la respuesta correcta

Fax Passthrough no es un respaldo para una implementación T.38 fallida; es una elección diferente con sus propias compensaciones. Las condiciones que favorecen passthrough son específicas y vale la pena verificarlas antes de cambiar el Relay Mode.

Elija passthrough cuando ambos terminales prefieren el comportamiento de fax-desde-analógico en G.711, cuando la red entre ellos muestra pérdida de paquetes confiablemente por debajo del 1 %, cuando el operador en el medio elimina el SDP de T.38 o siempre ofrece G.711, o cuando un extremo es un ATA analógico que no implementa T.38 en absoluto. La configuración está en el mismo panel Fax Settings; el cambio es simplemente Relay Mode configurado en Passthrough en lugar de T38, con el codec del tramo de audio mantenido en PCMU y la supresión de silencio desactivada.

La compensación es la sensibilidad a la pérdida de paquetes. T.38 con redundancia UDPTL reconstruye los paquetes faltantes sin retransmisión. G.711 passthrough no: las muestras perdidas se convierten en cortes de audio, y un módem de fax que intenta entrenar a través de un corte de audio simplemente fallará. Si su transporte ocasionalmente pierde paquetes, T.38 degradará graciosamente donde passthrough no lo hará. La comparación de codecs G.711 versus G.729 cubre el contexto más amplio de codecs si está evaluando otras rutas de audio en la misma troncal.

Verificación de la llamada de fax

La receta de verificación que el soporte de TelcoBridges solicita al resolver problemas de fax es el mismo procedimiento que usted debería ejecutar antes de abrir un ticket. Produce los artefactos que prueban lo que realmente ocurrió en la red.

1. Eleve los niveles de traza en los procesos relevantesUse tbx_cli_tools_remote para configurar el nivel de traza en 1 para gateway, toolpack_engine y tbsyslog. Escriba T y luego 1 en el prompt de cada uno. El nivel de traza 1 es suficiente para la negociación de fax sin inundar los logs.
2. Inicie una captura de paquetes con tbrouterLa captura debe cubrir ambos NAP involucrados en la ruta del fax. Confirme que la captura está ejecutándose antes de realizar la llamada.
3. Realice la llamada de fax que fallaUse el número de prueba reproducible identificado durante la lista de verificación previa. Un documento de una sola página es suficiente y produce una traza más limpia que una transmisión de múltiples páginas.
4. Detenga la captura y exporte la traza de la llamadaDetenga tbrouter, exporte la traza de la llamada desde el portal web y genere un tbreport con alcance a la ventana de fecha y hora de la llamada que falló.
5. Inspeccione lo que la traza realmente muestraEl patrón completo es: 200 OK en el INVITE de audio inicial, tono de fax detectado, re-INVITE con SDP T.38, 200 OK en el re-INVITE con atributos T.38 coincidentes, la línea m cambiando a m=image <port> udptl t38, CNG llegando antes del primer frame DIS, y paquetes IFP fluyendo en ambas direcciones con la estructura de redundancia UDPTL intacta.

Una traza que se detiene antes de uno de estos hitos le indica exactamente dónde mirar a continuación. Sin re-INVITE significa que el detector del tramo de audio nunca se activó. Un re-INVITE sin tráfico UDPTL significa un problema de NAT o puerto RTP, con Force Passive Mode en la parte superior de la lista de sospechosos. UDPTL fluyendo pero páginas fallando generalmente apunta a errores de checksum UDP en la NIC o CNG llegando después del frame DIS.

Patrones de falla comunes y cómo corregirlos

La mayoría de las fallas de fax en producción coinciden con uno de un número reducido de patrones. La lista a continuación está extraída de resoluciones de soporte en implementaciones reales de ProSBC y mapea cada patrón a la solución.

Errores de checksum UDP en la NIC del SBC son el asesino de fax más común. El síntoma es una negociación T.38 que se completa limpiamente seguida de paquetes IFP que el kernel descarta antes de que la aplicación los vea. La solución está en la capa del SO: desactive UDP checksum offload y Generic Receive Offload en la interfaz. La documentación de resolución de problemas del SBC de TelcoBridges documenta los pasos; la misma solución que resuelve problemas de DTMF también resuelve la pérdida de paquetes T.38.

CNG llegando después del DIS significa que el lado originante envió la configuración de llamada más rápido que su tono, y el detector de ProSBC o no detectó el CNG en absoluto o lo detectó demasiado tarde para activar el re-INVITE. ProSBC no fabricará un CNG; la solución está en el terminal originante o la pasarela upstream, frecuentemente ajustando la temporización de generación de tonos de ese dispositivo o cambiando su modo de fax.

Paquetes T.38 aún apareciendo cuando se deseaba passthrough indica que el campo Relay Mode todavía está configurado en T38. Cambiar el campo de T38 a Passthrough suprime el re-INVITE y mantiene el tramo en G.711.

Un encabezado Diversion insertado por un script de enrutamiento rompe la aceptación del extremo remoto. Varias implementaciones de ProSBC usan scripts Ruby para consultas STIR/SHAKEN (el script de ClearIP es un ejemplo). Las versiones anteriores del script inyectan un encabezado Diversion que algunas pasarelas de manejo de fax rechazan. La solución es actualizar al script actual; el soporte de TelcoBridges ha distribuido versiones corregidas para la ruta de ClearIP, y el mismo principio aplica a cualquier script de enrutamiento personalizado que toque la línea de solicitud en llamadas de fax.

RTP estancado después del re-INVITE se remonta a la configuración NAT del NAP. Force Passive Mode requiere que el extremo remoto envíe el primer paquete RTP; si no lo hace, no fluye RTP en ninguna dirección. La solución es alinear Force Passive Mode con la topología NAT real o asegurar que el extremo remoto esté configurado para iniciar RTP.

La capa SIP reporta un MEGACO Error 442 (error de sintaxis en el comando) en trazas internas. Esto indica un SDP malformado, frecuentemente un espacio o carácter suelto entre atributos, en la ruta entre el controlador de pasarela de medios del SBC y su pasarela de medios. Es un síntoma interno más que una falla visible para el cliente, pero si aparece en las trazas de soporte junto con un fax fallido, el SDP necesita ser examinado y la fuente de la malformación identificada.

Notas específicas por fabricante

La biblioteca de documentación de ProSBC incluye una página de configuración dedicada para 3CX como receptor de faxes T.38 (“Configuration for 3CX PBX Server with the ProSBC to receive T38 Faxes” bajo la sección de aprovisionamiento de 3CX). La página es la referencia correcta cuando 3CX está en el lado receptor de una ruta de fax; la configuración allí se interconecta con los ajustes de Fax T38 en el lado de ProSBC.

Para otras integraciones de PBX (Asterisk, FreePBX, FreeSWITCH, FusionPBX, VitalPBX, Yeastar, Wildix, Brekeke, Sippy, Cisco UCM, Avaya IP Office, VoIP.ms), las páginas de integración por fabricante en la documentación de ProSBC son la fuente autorizada. El comportamiento de fax interactúa con el manejo de fax propio de cada PBX, y la ruta más segura es el patrón de integración documentado para ese fabricante específico en lugar de una suposición genérica de que “T.38 debería simplemente funcionar.”

Preguntas frecuentes

Conclusión

Un fax T.38 confiable en un SBC se reduce a cuatro cosas hechas correctamente. El modo correcto para lo que cada terminal realmente admite, con Fax T38 como predeterminado y Passthrough como la alternativa considerada. Un camino de tono limpio para que CNG llegue a ProSBC antes del frame DIS. Una configuración NAT que no deje varado el puerto RTP detrás de un desajuste de Force Passive Mode. Y una NIC con UDP checksum offload desactivado, para que el kernel no descarte silenciosamente los paquetes que la aplicación está intentando recibir.

El panel Fax Settings de ProSBC expone los controles; tbsigtrace y tbreport proporcionan la prueba. Una vez que estos se alinean contra una traza conocida y exitosa, T.38 deja de ser una funcionalidad inestable y pasa a ser parte de la línea base estándar del SIP trunking.