Configuração de fax T.38 no SBC: guia de setup para o ProSBC

O fax que “sempre funciona na linha analógica” para de funcionar no dia em que alguém substitui o PRI por um tronco SIP, e o chamado chega ao engenheiro de rede que não abria o menu de fax do SBC há um ano. O T.38 deveria resolver isso. Na prática, a confiabilidade do T.38 depende de um punhado de configurações no SBC, de um caminho de tom limpo a partir do terminal de origem e de uma NIC que não descarte silenciosamente pacotes com checksums UDP inválidos.

Este guia percorre o painel exato de Fax Settings do ProSBC, os controles de NAT e codec relacionados, e as etapas de verificação que transformam uma implantação T.38 instável em uma confiável. Para o contexto conceitual sobre o que é o T.38, como o UDPTL difere do RTP e por que o fax falha em redes VoIP, o explicativo sobre Fax over IP (T.38) é o artigo complementar a ser lido primeiro.

Checklist pré-configuração antes de alterar qualquer parâmetro

A maioria dos chamados “T.38 não funciona” se resolve em um de três problemas que nenhuma configuração de SBC corrige: um terminal que não suporta T.38, um tom que nunca chega ao SBC ou uma NIC descartando pacotes silenciosamente. Confirme esses pontos antes de tocar no painel de Fax Settings.

Ambos os terminais conseguem de fato negociar T.38 ou G.711 passthrough. Um ATA, um servidor de fax ou um gateway PRI que suporta apenas fax G.711 nunca aceitará um re-INVITE T.38, independentemente de como o SBC esteja configurado. Confirme o suporte em ambas as pernas na documentação do dispositivo antes de depurar o meio do caminho.

O caminho do fax está identificado de ponta a ponta. Saiba de qual NAP o fax se origina, qual NAP o termina, a operadora entre eles e se mensagens re-INVITE atravessam algum firewall ou dispositivo NAT que possa reescrever o SDP. A manipulação de cabeçalhos SIP mais adiante no caminho pode remover ou reescrever atributos que o ProSBC precisa receber intactos.

Offloads de NIC estão desabilitados se você já viu erros de checksum UDP. Generic Receive Offload e UDP checksum offload na NIC do SBC são um problema conhecido que elimina o T.38. Os chamados chegam com o sintoma “T.38 negocia, mas a página nunca é concluída.” A correção está na camada do SO (desabilitar os offloads relevantes com ethtool), não no painel de Fax Settings.

Um número de fax de teste que falha da mesma forma toda vez. Falhas intermitentes produzem rastreamentos intermitentes. Uma chamada de teste reproduzível de uma máquina de fax conhecida para um destino conhecido, idealmente com um documento de uma página, é o que torna uma captura tbsigtrace útil.

Onde ficam as configurações de fax do ProSBC

O comportamento de fax no ProSBC é configurado por perfil de NAP, não globalmente. O caminho no Web Portal é Configuration By Web Portal Category → NAP Profiles → Fax Settings, e dentro desse painel cinco páginas de modo distintas cobrem as variantes operacionais que você pode precisar.

• Configure Fax T38 para relay T.38 de ponta a ponta entre dois terminais que negociam o protocolo.
• Configure Fax Passthrough para fax G.711 fax-from-analog mantido em áudio de ponta a ponta.
• Configuring Fax Relay para o modo interno de relay de fax/modem usado em implantações estilo gateway.
• Configure Fax NSE para interoperabilidade com Cisco Named Signaling Events, quando o lado remoto espera sinalização de fax/modem baseada em NSE.
• Configure Fax VBD para passthrough de voice-band-data usado em alguns ambientes legados.

Os perfis são nomeados (uma convenção comum vista em implantações reais é algo como FAX_ISDN para o perfil histórico do lado PRI), e o mesmo perfil pode ser vinculado a múltiplos NAPs. Se você reconfigurar um NAP de PRI para um terminal SIP, o mesmo perfil de fax o acompanha. Este é o padrão recomendado: configure uma vez, vincule conforme necessário.

Escolhendo o modo correto

A principal causa de falhas de fax é escolher o modo errado para os terminais envolvidos. A decisão é moldada pelo que cada perna suporta, não pelo que o SBC prefere.

Fax T38 é a escolha certa quando ambas as pernas conseguem negociar T.38. O SBC detecta o tom de fax, envia um re-INVITE e alterna a perna de mídia para UDPTL. Esta é a opção mais resiliente em redes com perda de pacotes porque a redundância UDPTL reconstrói pacotes perdidos localmente sem retransmissão.

Fax Passthrough se aplica quando ambas as pernas preferem G.711 e a rede entre elas é confiável. Nenhum re-INVITE é emitido, nenhuma transcodificação é necessária, e os modems de fax negociam sobre um fluxo de áudio G.711 ininterrupto. O passthrough é sensível a perda de pacotes e jitter; o fax passthrough se torna cada vez menos confiável à medida que a perda de pacotes e o jitter aumentam.

Fax NSE e Fax VBD existem para casos específicos de interoperabilidade entre fornecedores. Use Fax NSE quando o lado remoto é um gateway Cisco que espera sinalização NSE. Use Fax VBD quando a implantação especifica comportamento voice-band-data em um tronco específico. Se nem o fornecedor nem a especificação exigem esses modos, deixe-os de lado.

Fax Relay é o modo interno de relay de fax/modem usado em topologias estilo gateway onde o ProSBC atua como terminal de relay em vez de negociar com um gateway downstream. Este é o cenário menos comum em implantações modernas de SBC, mas permanece documentado para migrações de sistemas legados.

Configurando Fax T38 campo por campo

A página Configure Fax T38 expõe um conjunto compacto de campos, e os mesmos campos aparecem em trocas com o suporte ao cliente com frequência suficiente para que sua função seja bem compreendida. A lista abaixo documenta cada campo com o valor padrão seguro e o motivo para desviar dele.

Enable Fax/Modem Relay é o toggle principal. Ele deve estar marcado para que qualquer comportamento T.38 tenha efeito. Se estiver desmarcado, todos os outros campos no painel ficam inertes.

Detection Mode controla quão agressivamente o ProSBC escuta tons de fax no fluxo de áudio. Standard é o valor padrão documentado e o valor visto em implantações funcionais; recorra a uma alternativa apenas se um fornecedor a exigir explicitamente.

Relay Mode seleciona entre T38 (re-INVITE para UDPTL) e Passthrough (manter a perna em G.711 do início ao fim). Este é o campo que alterna o modo operacional do perfil. Defina como T38 para o passo a passo do Fax T38; mude para Passthrough quando você genuinamente quiser preservar a perna de áudio de ponta a ponta.

Modem vs Fax Distinction recebe um limiar em milissegundos e controla como o detector distingue um tom de fax de um tom de modem. Um valor de 0 ms trata todos os tons detectados como fax, que é o ponto de partida correto para implantações somente fax. Aumente-o apenas quando você tiver tráfego de modem no mesmo tronco e precisar que o ProSBC roteie os dois de forma diferente.

Prevent direct invite in T.38 lida com o caso em que o lado originador abre a chamada com T.38 já em seu SDP inicial em vez de iniciar em áudio e enviar re-INVITE. Marque esta opção quando o lado remoto só consegue lidar com a sequência audio-first e você tem um gateway upstream que sempre emite INVITEs T.38 diretos. Deixe desmarcado quando ambos os lados lidam com T.38 direto sem problemas.

Detection Type cobre o ajuste do detector. “Silence suppression off” é o valor padrão seguro documentado; a supressão de silêncio interage mal com tons de fax e é a origem de mais chamados de falha do que os que resolve.

Codec seleciona o codec da perna de áudio usado antes do re-INVITE. PCMU (G.711 µ-law) é o padrão documentado e o codec em que implantações funcionais convergem. Configure-o para corresponder ao codec da perna voltada para a operadora; não liste G.729 aqui, pois o fax não sobrevive à compressão com perdas.

Atributos SDP do T.38 que você verá na rede

Quando o re-INVITE é disparado e a perna de mídia alterna para UDPTL, o corpo SDP anuncia um conjunto específico de atributos T.38. Conhecer os valores padrão torna o rastreamento do fluxo da chamada muito mais rápido, porque cada valor abaixo é algo que você pode pesquisar em uma captura e confirmar em relação à expectativa.

• m=image <port> udptl t38 é a linha de mídia que sinaliza a troca de áudio RTP para UDPTL.
• a=T38FaxVersion:0 é a versão oferecida por padrão. A maioria dos terminais de fax negocia a versão 0 com sucesso; substituições de versão existem, mas raramente são necessárias.
• a=T38MaxBitRate:14400 é a taxa de bits máxima do modem oferecida, correspondendo ao fax V.17 padrão.
• a=T38FaxRateManagement:transferredTCF coloca o gerenciamento do Training Check Frame no lado remoto em vez de localmente.
• a=T38FaxMaxBuffer:200 e a=T38FaxMaxDatagram:200 descrevem os tamanhos de buffer e datagrama oferecidos.
• a=T38FaxUdpEC:t38UDPRedundancy declara a redundância UDPTL como método de correção de erros, a opção que compensa a perda de pacotes carregando cópias de pacotes IFP anteriores.

Capture uma chamada de fax bem-sucedida em sua própria implantação primeiro para confirmar exatamente o que o ProSBC oferece em seu ambiente. A normalização do lado da operadora pode reescrever qualquer um desses valores antes que eles saiam do SBC, e os valores que você vê na perna voltada para a operadora podem diferir dos valores que você vê na perna voltada para o terminal.

NAT, Force Passive Mode e a armadilha que a maioria enfrenta

A configuração NAT no nível do NAP interage com o T.38 de uma forma que surpreende muitas implantações. A configuração relevante é Remote Method for RTP na página de configuração NAT do NAP, e um de seus valores, Force Passive Mode, altera quando o ProSBC abre a porta RTP.

Com Force Passive Mode definido, o ProSBC aguarda a chegada do primeiro pacote RTP do lado remoto antes de abrir sua porta RTP. O comportamento é correto para cenários de travessia de NAT onde o lado remoto está atrás de um firewall stateful e o ProSBC deve aprender o endereço traduzido externamente a partir do tráfego observado. A desvantagem é que, se o lado remoto nunca enviar primeiro, a porta nunca abre, e a negociação T.38 parece ter sucesso na camada SIP, mas nenhum pacote UDPTL flui.

O diagnóstico é direto: uma captura tbsigtrace que mostra a troca de re-INVITE e 200 OK completando normalmente, nenhum pacote UDPTL em qualquer direção, e a chamada eventualmente expirando. A correção depende da topologia. Quando o ProSBC realmente enfrenta um peer com NAT, Force Passive Mode é a escolha correta e o lado de origem precisa ser configurado para enviar o primeiro pacote. Quando o ProSBC enfrenta um gateway sem NAT, Force Passive Mode é a escolha errada e o Remote Method deve ser definido para um valor que permita ao ProSBC abrir a porta imediatamente.

Quando o passthrough G.711 é a resposta certa

O Fax Passthrough não é um fallback para uma implantação T.38 com falhas; é uma escolha diferente com seus próprios trade-offs. As condições que favorecem o passthrough são específicas e vale a pena verificá-las antes de alterar o Relay Mode.

Escolha passthrough quando ambos os terminais preferem o comportamento fax-from-analog G.711, quando a rede entre eles apresenta perda de pacotes consistentemente abaixo de 1%, quando a operadora no meio remove o SDP T.38 ou sempre oferece G.711, ou quando um lado é um ATA analógico que não implementa T.38. A configuração está no mesmo painel de Fax Settings; a mudança é simplesmente Relay Mode definido como Passthrough em vez de T38, com o codec da perna de áudio mantido em PCMU e supressão de silêncio desligada.

O trade-off é a sensibilidade à perda de pacotes. T.38 com redundância UDPTL reconstrói pacotes perdidos sem retransmissão. G.711 passthrough não: amostras perdidas se tornam falhas de áudio, e um modem de fax tentando treinar através de uma falha de áudio simplesmente falhará. Se seu transporte ocasionalmente perde pacotes, o T.38 degradará graciosamente onde o passthrough não degradará. A comparação de codecs G.711 versus G.729 cobre o contexto mais amplo de codecs se você estiver avaliando outros caminhos de áudio no mesmo tronco.

Verificando a chamada de fax

A receita de verificação que o suporte da TelcoBridges solicita ao solucionar problemas de fax é o mesmo procedimento que você deve executar antes de abrir um chamado. Ele produz os artefatos que comprovam o que realmente aconteceu na rede.

1. Aumente os níveis de rastreamento nos processos relevantesUse tbx_cli_tools_remote para definir o nível de rastreamento como 1 em gateway, toolpack_engine e tbsyslog. Digite T e depois 1 no prompt para cada um. O nível de rastreamento 1 é suficiente para a negociação de fax sem sobrecarregar os logs.
2. Inicie uma captura de pacotes com tbrouterA captura deve cobrir ambos os NAPs envolvidos no caminho do fax. Confirme que a captura está em execução antes de realizar a chamada.
3. Realize a chamada de fax com falhaUse o número de teste reproduzível identificado durante o checklist pré-configuração. Um documento de uma página é suficiente e produz um rastreamento mais limpo do que uma transmissão de múltiplas páginas.
4. Pare a captura e exporte o rastreamento da chamadaPare o tbrouter, exporte o rastreamento da chamada pelo Web Portal e gere um tbreport delimitado à janela de data e hora da chamada com falha.
5. Inspecione o que o rastreamento realmente mostraO padrão completo é: 200 OK no INVITE de áudio inicial, tom de fax detectado, re-INVITE com SDP T.38, 200 OK no re-INVITE com atributos T.38 correspondentes, a m-line alternando para m=image <port> udptl t38, CNG chegando antes do primeiro frame DIS, e pacotes IFP fluindo em ambas as direções com a estrutura de redundância UDPTL intacta.

Um rastreamento que para antes de um desses marcos indica exatamente onde procurar a seguir. Nenhum re-INVITE significa que o detector da perna de áudio nunca disparou. Um re-INVITE sem tráfego UDPTL significa um problema de NAT ou porta RTP, com Force Passive Mode no topo da lista de suspeitos. UDPTL fluindo mas páginas falhando geralmente aponta para erros de checksum UDP na NIC ou CNG chegando após o frame DIS.

Padrões de falha comuns e como corrigi-los

A maioria das falhas de fax em produção corresponde a um de um pequeno número de padrões. A lista abaixo é baseada em resoluções de suporte em implantações reais do ProSBC e mapeia cada padrão para a correção.

Erros de checksum UDP na NIC do SBC são o problema mais comum que elimina o fax. O sintoma é a negociação T.38 completando normalmente seguida de pacotes IFP que o kernel descarta antes que a aplicação os veja. A correção está na camada do SO: desabilite o UDP checksum offload e o Generic Receive Offload na interface. A documentação de Troubleshooting do SBC da TelcoBridges documenta os passos; a mesma correção que resolve problemas de DTMF também resolve perda de pacotes T.38.

CNG chegando após DIS significa que o lado originador enviou o setup da chamada mais rápido que seu tom, e o detector do ProSBC perdeu o CNG completamente ou o detectou tarde demais para acionar o re-INVITE. O ProSBC não fabricará um CNG; a correção está no terminal de origem ou no gateway upstream, frequentemente ajustando o timing de geração de tom daquele dispositivo ou alterando seu modo de fax.

Pacotes T.38 ainda aparecendo quando você queria passthrough indica que o campo Relay Mode ainda está definido como T38. Alternar o campo de T38 para Passthrough suprime o re-INVITE e mantém a perna em G.711.

Um cabeçalho Diversion inserido por um script de roteamento quebra a aceitação do lado remoto. Várias implantações do ProSBC usam scripts Ruby para consulta STIR/SHAKEN (o script ClearIP é um exemplo). Versões mais antigas do script injetam um cabeçalho Diversion que alguns gateways de fax rejeitam. A correção é atualizar para o script atual; o suporte da TelcoBridges já enviou versões corrigidas para o caminho ClearIP, e o mesmo princípio se aplica a qualquer script de roteamento personalizado que modifique a linha de requisição em chamadas de fax.

RTP parado após re-INVITE remete à configuração NAT do NAP. Force Passive Mode exige que o lado remoto envie o primeiro pacote RTP; se ele não enviar, nenhum RTP flui em qualquer direção. A correção é alinhar o Force Passive Mode com a topologia NAT real ou garantir que o lado remoto esteja configurado para iniciar o RTP.

A camada SIP reporta um MEGACO Error 442 (erro de sintaxe no comando) nos rastreamentos internos. Isso indica um SDP malformado, frequentemente um espaço ou caractere perdido entre atributos, no caminho entre o controlador de media gateway do SBC e seu media gateway. É um sintoma interno e não uma falha voltada para o cliente, mas se aparecer nos rastreamentos de suporte junto com um fax com falha, o SDP precisa ser examinado e a origem da malformação identificada.

Notas específicas por fornecedor

A biblioteca de documentação do ProSBC inclui uma página de configuração dedicada para 3CX como receptor de faxes T.38 (“Configuration for 3CX PBX Server with the ProSBC to receive T38 Faxes” na seção de provisionamento do 3CX). A página é a referência correta quando o 3CX está no lado receptor de um caminho de fax; a configuração nela se integra com as configurações Fax T38 no lado do ProSBC.

Para outras integrações com PBX (Asterisk, FreePBX, FreeSWITCH, FusionPBX, VitalPBX, Yeastar, Wildix, Brekeke, Sippy, Cisco UCM, Avaya IP Office, VoIP.ms), as páginas de integração por fornecedor na documentação do ProSBC são a fonte autorizada. O comportamento de fax interage com o próprio tratamento de fax de cada PBX, e o caminho mais seguro é o padrão de integração documentado para aquele fornecedor específico em vez de uma suposição genérica de que “T.38 deveria simplesmente funcionar.”

Perguntas frequentes

Conclusão

Fax T.38 confiável em um SBC se resume a quatro coisas feitas corretamente. O modo certo para o que cada terminal realmente suporta, com Fax T38 como padrão e Passthrough como alternativa considerada. Um caminho de tom limpo para que o CNG chegue ao ProSBC antes do frame DIS. Uma configuração NAT que não prenda a porta RTP atrás de um Force Passive Mode inadequado. E uma NIC com UDP checksum offload desabilitado, para que o kernel não descarte silenciosamente os pacotes que a aplicação está tentando receber.

O painel de Fax Settings do ProSBC expõe os controles; tbsigtrace e tbreport fornecem a prova. Uma vez que esses se alinham com um rastreamento de referência bem-sucedido, o T.38 deixa de ser um recurso instável e passa a fazer parte da linha de base padrão do SIP trunking.