Resumo

  • t38(stop) informa que o procedimento T.38 terminou sem erro percebido pelo gateway. O próprio RFC 5347 diz que isso não significa necessariamente que o fax foi transmitido com sucesso; entrega precisa de evidência de outra camada.
  • O sucesso de ModifyConnection também tem escopo limitado. Se a opção fax for omitida, uma conexão antes estrita pode aceitar uma descrição remota sem T.38 e depois emitir nopfax(start); repetir t38 explicitamente faria a mesma alteração falhar.
  • Seleção usa a RemoteConnectionDescriptor da ordem atual, enquanto envio usa a descrição remota mais recentemente recebida. Capacidade anunciada, permissão atual, evento do procedimento e resultado da página devem permanecer separados.

Um evento verde tem um sujeito estreito

t38(start) afirma que o fax foi detectado e o procedimento T.38 controlado pelo Call Agent começou. t38(stop) afirma que esse procedimento terminou sem erro detectado pelo gateway. O sujeito das duas frases é o procedimento, não o documento.

O gateway não confirma quantas páginas chegaram, se o conteúdo manteve integridade, se o aplicativo remoto aceitou a sessão, se o número alcançou o destinatário correto ou se alguém recebeu a mensagem. Mesmo uma terminação limpa pode acompanhar um resultado comercial desconhecido ou negativo.

t38(failure) indica que o procedimento terminou de forma anormal. Ele é útil para localizar falha, mas a ausência desse evento não completa o conjunto de provas. Os eventos gwfax têm a mesma limitação para métodos controlados pelo gateway.

Um modelo de dados honesto reserva estados diferentes para procedimento e documento. A automação pode correlacioná-los, mas não deve copiar stop para delivered sem uma confirmação que esteja autorizada a fazer essa afirmação.

nopfax(start) não terá um final simétrico

Quando o fax é detectado e nenhum procedimento especial está em vigor, o gateway emite nopfax(start). Não existem formas stop ou failure correspondentes. No modo sem tratamento especial, não se espera que o gateway deduza do fluxo de mídia quando o fax terminou.

Essa assimetria revela o limite de observação. Seria simples desenhar um estado “nopfax concluído”, mas o dispositivo não possui necessariamente evidência para sustentá-lo. A falta do evento não é um defeito do relatório; é uma recusa em afirmar além do que o gateway sabe.

O sistema de operações precisa preservar esse desconhecido. Preencher o fim por tempo, encerramento de chamada ou ausência de pacotes cria uma inferência própria que deve ser rotulada, não uma conclusão atribuída ao RFC.

O mesmo cuidado vale para gwfax(stop): ele fecha o método delegado, não a obrigação de entrega. O recibo empresarial pode surgir de outro protocolo, de um aplicativo, de uma confirmação humana ou pode simplesmente não existir.

A ordem bem-sucedida também diz menos do que parece

O exemplo central do RFC começa com conexão estabelecida sob T.38 Strict. Depois, o Call Agent envia ModifyConnection com uma RemoteConnectionDescriptor que não oferece suporte T.38.

Se a fax LocalConnectionOption for omitida, a ordem é aceita. O valor atual permanece, porém o novo sucesso não depende de satisfazer a exigência T.38. Quando o fax for detectado, o procedimento não será invocado e aparecerá nopfax(start).

Se t38 for repetido explicitamente na mesma ordem, a alteração deverá falhar. O erro 532 é recomendado quando nenhum dos procedimentos pedidos pode ser atendido. A falha protege a condição explícita; o verde protege apenas a continuidade da alteração.

Portanto, o livro-razão deve registrar presença e valor. Manter somente “fax=t38” após a transação não permite saber se T.38 foi uma condição de aceitação ou uma preferência herdada que perdeu força executável.

Seleção e transmissão consultam provas diferentes

Uma RemoteConnectionDescriptor antiga não pode orientar a seleção de procedimento na ordem atual. Apenas a descrição incluída nessa ordem participa da escolha. Essa regra impede que evidência vencida atravesse transações.

Na hora de transmitir mídia, a referência muda. A descrição remota recebida mais recentemente precisa conter a linha image/t38 e transporte aceitável. O gateway pode iniciar o procedimento antes dessa autorização, mas deve esperar para transmitir. Se o prazo expirar, ocorre stop ou failure.

Uma linha do tempo é indispensável: descrição anexada à ordem, seleção, novas descrições recebidas, autorização efetiva, primeiro pacote e eventual timeout. Um campo único chamado “SDP negociado” destrói justamente a diferença temporal.

Quando áudio RTP e T.38 reutilizam o mesmo endereço e porta, a sinalização explícita também determina qual formato o receptor espera. Inspecionar bytes não deve substituir o estado sinalizado como forma de demultiplexação.

Capacidade não é autorização

Uma declaração SDP pode anunciar capacidades atuais ou latentes. Mostrar T.38 significa que o equipamento talvez consiga executá-lo; não significa que o Call Agent autorizou o uso naquela ordem.

Também não é seguro tratar ausência de declaração como prova de incapacidade. Um par pode suportar T.38 sem expressá-lo pelo mecanismo esperado. Strict evita tentativas contra pares sem prova utilizável, mas pode rejeitar um caso que funcionaria.

Loose tolera a falta de declaração e reduz esse falso negativo. Em compensação, pode tentar T.38 contra um par realmente incapaz e causar falha do fax. O RFC não oferece uma escolha universal: cada modo aceita uma classe diferente de erro.

A política precisa indicar população de equipamentos, qualidade das declarações, custo de falso positivo e custo de falso negativo. “Suporta T.38” não é uma propriedade suficiente para decidir sem contexto transacional.

Uma lista de preferência contém regras de fluxo

t38 pede Strict sob controle do Call Agent; t38-loose pede a modalidade flexível; gw delega seleção e detalhes ao gateway; off dispensa procedimento especial, além de ajustes locais.

A lista separada por ponto e vírgula parece ordenar alternativas. Contudo, t38-loose e off sempre podem ser suportados, tornando inalcançáveis as entradas posteriores.

gw traz uma exceção: se a escolha própria do gateway terminaria em nenhum tratamento especial, pode haver passagem para um procedimento posterior que não seja off. Um validador puramente sintático não vê nenhuma dessas consequências.

O controle deve guardar a ordem exata, marcar ramos mortos, explicar descartes, registrar a passagem especial e mostrar o procedimento efetivo. Uma lista longa não é prova de resiliência se suas últimas opções nunca puderem executar.

Delegação pode adiar o conhecimento

No modo controlado pelo gateway, um tratamento especial só existe quando ambos os pares suportam o mesmo método e o indicam no SDP trocado. O fornecedor define os detalhes. Sem método comum, nenhum tratamento especial ocorre.

O Call Agent talvez descubra isso apenas quando a transmissão fax começa e recebe nopfax(start). A ordem anterior foi uma delegação válida, mas não um recibo de que algo especial havia sido selecionado.

Quando um método delegado realmente começa, gwfax(start) fornece a evidência. A partir daí, o Call Agent deve evitar ordens conflitantes até o término. Delegar exige confirmar a execução e respeitar o período em que o delegado controla o procedimento.

O painel deve separar “gw configurado”, “método comum encontrado”, “gwfax iniciado” e “procedimento terminado”. A primeira etapa não permite preencher automaticamente as demais.

Detectar fax também pode produzir falso positivo

A implementação deve reconhecer ao menos o preâmbulo V.21. A detecção do tom CNG do T.30 é opcional. O RFC registra relatos de modems emitindo CNG em chamadas não fax, o que causava disparos falsos, e recomenda opção para desabilitar essa detecção.

Uma cadeia pode ter autorização correta, método correto e terminação limpa, mas ter começado por uma observação errada. A consistência das etapas seguintes não prova que existia um documento fax no início.

O gateway de origem, o de destino ou ambos simultaneamente podem iniciar a mudança T.38. O registro precisa identificar detector, sinal, lado iniciador, instante e resolução da simultaneidade.

Confiança de detecção e autoridade do método devem permanecer independentes. Sinal forte não autoriza procedimento negado; autorização expressa não torna verdadeira uma detecção falsa.

Tolerância melhora interoperabilidade, não aumenta a prova

O RFC recomenda tolerar variações de maiúsculas em UDPTL e atributos T.38, além de algumas codificações booleanas historicamente incorretas. Aceitar essas formas permite conversar com implementações antigas. Não demonstra que as partes concordaram sobre política ou que houve entrega.

Contadores de conexão devem incluir pacotes e octetos fax. Ao mesmo tempo, cálculos de jitter e atraso médio podem ser suspensos durante o fax, inclusive T.38. A observabilidade pode ficar mais pobre justamente durante a transição importante.

Reutilizar endereço e porta entre áudio e fax reduz interação com QoS, NAT e firewall. Também torna impossível usar a cinco-tupla como identidade permanente do tipo de mídia.

Essas concessões são úteis, porém exigem um histórico de sinalização ainda melhor. Tolerância de sintaxe, permissão de mídia, execução do procedimento e resultado documental não podem ocupar a mesma coluna.

O status histórico limita as conclusões

RFC 5347 foi publicado em outubro de 2008 como Informational; não é Internet Standard. A busca de errata do RFC Editor mostra seis registros mantidos para atualização do documento. Uma leitura operacional deve apresentar esse estado.

O texto não comprova comportamento de produto atual, implantação contemporânea ou adoção de mercado. Também não afirma que T.38 seja necessário para todo fax bem-sucedido.

Sua contribuição duradoura está na disciplina das fronteiras. O documento mostra exatamente como comando, política, capacidade, mídia, evento e resultado podem ser verdadeiros separadamente sem sustentarem uma única afirmação verde.