Fax

Fax, faxe,[1] telefax (abreviaturas do termo latino facsimile e telefacsimile) ou telecópia é

uma tecnologia das telecomunicaçõesusada para a transferência remota de documentos através da rede telefônica.
A ideia de transmitir e reproduzir documentos a longa distância foi patenteada por Alexander Bain em 1843. Da união
da ideia de Bain com aparelho telefônico criado por Alexander Graham Bell, o primeiro protótipo do fac-símile, mais
conhecido como fax, foi criado nos Laboratórios Bell em 1926.
Em 1947 Gabriel Casotti, especialista em telegrafia sem fio, produziu o primeiro aparelho de fax com a ajuda da
agência de notícias Associated Newspapers.
Em 1949, a Muirhead instalou o primeiro sistema de fax no Japão. E no ano 1973 ele começou a ser produzido em
grande escala.
Uma "máquina de fax" normalmente consiste de uma escâner, um modem, uma impressora e uma linha telefônica em
um só equipamento. A scanner converte o arquivo impresso em imagem digital, o modem envia esta imagem pela linha
telefônica para outra máquina de fax e impressora desta máquina produz uma cópia do documento recebido.
O grande sucesso do fax deve-se principalmente à sua grande vantagem sobre os correios quando a comunicação é a
longa distância, uma vez que a transferência de documentos daquele é quase instantânea.
Com a popularização da Internet nos anos 2000 surge um novo serviço no meio das telecomunicações: o fax pela
internet, também chamado de Internet Fax ou ainda Fax to Mail. O serviço funcionava através de um servidor de fax,
um software que permite o envio de fax a partir do computador via conexão na Internet. Com a popularização dos
scanners, no entanto, o Internet Fax foi perdendo sua utilidade, já que os scanners permitem a digitalização das
imagens e o envio por e-mail em conexões banda larga, muito mais rápidas e confiáveis que a conexão discada dos
faxes.
Em muitos ambientes corporativos, as máquinas de fax foram substituídas pelos servidores de fax e outros sistemas
computadorizados capazes de receber e armazenar faxeletrônicos que podem ser impressos ou reenviados via e-mail
para terceiros. Tais sistemas têm a vantagem de reduzir custos uma vez que diminuem impressões desnecessárias e
gastos com ligações telefônicas das máquinas de fax.

Modem
A palavra Modem vem da junção das palavras modulador e demodulador.[1][2] É um dispositivo eletrônico que modula
um sinal digitalnuma onda analógica, pronta a ser transmitida pela linha telefónica, e que demodula o sinal analógico e
reconverte-o para o formato digital original.[2] Utilizado para conexão à Internet, BBS, ou a outro computador.
O processo de conversão de sinais binários para analógicos é chamado de modulação/conversão digital-analógico.
Quando o sinal é recebido, um outro modem reverte o processo (chamado demodulação). Ambos os modems devem
estar a trabalhar de acordo com os mesmos padrões, que especificam, entre outras coisas, a velocidade de
transmissão (bps, baud), nível e algoritmo de compressão de dados, protocolo, etc.
O prefixo Fax deve-se ao facto de que o dispositivo pode ser utilizado para receber e enviar fac-símile.
Os primeiros modems analógicos eram externos. Ligados através das interfaces paralelas, onde a velocidade de
transmissão era de 300 bps (bits por segundo) e operavam em dois sinais diferentes, um tom alto que representava bit
1, enquanto o tom baixo representava o bit 0.[2]

Tipos de modems
Basicamente, existem modems para o acesso discado e banda larga.

Um modemADSLPT-DSL moderno. Fax modem antigo, de 14.400 bps.

Os modems para acesso discado geralmente são instalados internamente no computador (em slots PCI) ou ligados em

uma porta serial, enquanto os modems para acesso em banda larga podem ser USB, Wi-Fi ou Ethernet.
Os modemsADSL diferem dos modems para acesso discado porque não precisam converter o sinal de digital para
analógico e de analógico para digital porque o sinal é sempre digital (ADSL - Asymmetric Digital Subscriber Line).[3] O
exemplo mais familiar é um modem de banda de voz que transforma os dados digitais de um computador pessoal em
sinais elétricos modulados na frequência de voz do alcance de um canal telefónico. Estes sinais podem ser
 transmitidos através de linhas telefônicas e demodulados por outro modem no lado do receptor para recuperar os
dados digitais.
Os modems são geralmente classificados pela qualidade de dados que podem enviar em uma determinada unidade de
tempo, normalmente medido em bits por segundo (bit/s ou bps). Eles também podem ser classificados pela taxa de
símbolos medido em bauds, o número de vezes que o modem muda o estado do sinal por segundo. Por exemplo, o
ITU V.21 padrão utilizado-shift keying frequência de áudio, tons aka, para transportar 300 bits/s usando 300 baud,
enquanto o padrão ITU V.22 original permitia 1.200 bit / s com seiscentos baud usando modulação de fase .

FoIP - Fax sobre IP

1 Introdução
 
Devido à crescente utilização de redes de pacotes, surgiram tecnologias que permitiram sua utilização para aplicações anteriormente apenas possíveis de
serem utilizadas em redes de circuitos (PSTN – Public Switched Telephone Network). Dentre essas tecnologias podemos destacar o VoIP (Voz sobre IP) e o
FoIP (Fax sobre IP).
 
As duas tecnologias baseiam-se na utilização de um codificador (codec) que transforma o sinal analógico de voz (VoIP) ou do modem (FoIP) em uma
informação digital que pode ser transmitida através de uma rede de pacotes.
Neste artigo serão abordadas as tecnologias utilizadas para implementação de FoIP.
 
2 Opções de implementação
 
A implementação de FoIP pode utilizar três métodos distintos:

 In-band Faxing;
 Real Time Faxing; e

 Store and Forward Faxing.

No método In-band Faxing os tons Fax são codificados digitalmente por um codec da mesma forma que um sinal de voz, ou seja, utiliza os mesmos
mecanismos empregados para VoIP.
Na transmissão em Tempo Real a troca de informações acontece com a utilização de um protocolo específico para essa aplicação chamado T.38.
 
Já na transmissão com Store and Forward não ocorre troca de informações diretamente entre origem e destino, mas sim com sistemas intermediários que
recebem o documento a ser transmitido, enviam para outro sistema intermediário via protocolo SMTP, para depois transmitir para o dispositivo destino do
Fax.
 
2.1 In-Band Faxing (Usando um canal VoIP)
 
O método In-band Faxing não é muito utilizado devido sua ineficiência. Eventualmente os componentes podem ser configurados de tal forma que uma
grande porcentagem, ou até mesmo 100%, dos Faxes enviados cheguem com sucesso no destino. No entanto tais ambientes são muito raros e até mesmo uma
tentativa de reprodução de um ambiente estável não consegue atingir níveis aceitáveis de qualidade [UNDERWOOD].
 
O In-band Faxing baseia-se na codificação digital dos tons de Fax (ou modem) utilizando codecs de voz com maior taxa de amostragem.
 
O principal problema com este método é que os codecs criados para comunicação VoIP têm como objetivo primordial a codificação da voz humana.
Codificar de forma adequada qualquer outro tipo de som não é normalmente um requisito na criação desses codecs [UNDERWOOD].
 
Principalmente quando analisamos os codecs mais eficientes para o transporte de voz, observamos os resultados mais desastrosos nas transmissões de Fax.
Isso se deve ao fato de que esses codecs utilizam técnicas refinadas para compressão de áudio, que os permite utilizar uma taxa transferência bastante
pequena. Essa compressão envolve perdas normalmente imperceptíveis para interlocutores humanos, mas é fatal para Fax-modems. Por exemplo, analisando
o codec G729 que utiliza uma taxa de transferência de 8Kbps fica fácil deduzir que é impossível transmitir corretamente um sinal de Fax que está sendo
gerado a 9,6Kbps [UNDERWOOD].
 
A situação torna-se ainda mais complicada quando tentamos codificar sinais de Fax mais recentes que utilizam padrões de transmissão mais velozes como
V.17 (14,4Kbps) e V.34bis (33,6Kbps). Este último tornou a utilização canais VoIP para transmissão de Fax inviável pois, apesar dos codecs u-law e A-law
utilizarem uma taxa de transferência que manteria a qualidade de sinal necessária, o atraso inserido no canal VoIP, mesmo que estável, impede que os
canceladores de eco da maioria dos modems funcione adequadamente [UNDERWOOD]. Os padrões que utilizam taxas de transferência menores não usam
cancelamento de eco e portanto não são afetados por essa questão [UNDERWOOD].
 
Outra questão que interfere no In-band Faxing é o “jitter”, ou seja, a diferença entre os atrasos de chegadas dos pacotes. Nas redes de circuito o atraso de
chagada das informações é constante e os dispositivos de Fax-modems confiam nessa constância. No entanto, quando a sinalização dos modems é
transportada por uma rede de pacotes, o atraso de chegada passa a ter variações. Eventualmente essa variação de atraso pode ser minimizada com a utilização
de QoS (Quality of Service) e o jitter mínimo resultante seria contornado pelo jitter buffer no destino. Essa é uma solução que normalmente resolve esse
problema, mas não há garantias. Isso se deve ao fato de que existem muitas variações de implementação de jitter buffers, inclusive algumas mais modernas
utilizam algoritmos que modificam dinamicamente o tamanho do buffer, causando distorção no sinal dos modems [UNDERWOOD].
 
Existe ainda outro elemento presente nos codecs de voz que é nocivo à sinalização dos Fax-modems: a supressão de silêncio. Esse mecanismo possui um
detector de voz que monitora continuamente a transmissão. Alguns desses mecanismos são focados especificamente na voz humana e tendem a rejeitar
qualquer outro tipo de som, como por exemplo, os tons de Fax. Dessa forma eles podem não alternar corretamente o canal de áudio entre “transmitindo” e
“não-transmitindo” em função da sinalização do modem iniciar ou parar. Além disso, os supressores de silêncio costumam inserir um “ruído de conforto”
que simula o som de fundo normalmente ouvido durante uma conversa. Isso pode fazer com que um intervalo que deveria realmente ser de silêncio, contenha
algum ruído que dificulta o modem de detectar as fronteiras entre os sinais transmitidos [UNDERWOOD].
 
2.2 Real Time Faxing (T.38)
 
Este método de transmissão de Fax é definido por uma recomendação do ITU-T chamada T.38. Essa recomendação define os procedimentos que devem ser
aplicados para permitir a transmissão de mensagens de Fax entre terminais em que parte do caminho de transmissão, ou todo ele, inclua uma rede de pacotes,
como por exemplo, a Internet [ITU/T.38].
 
Na pratica, o uso mais comum do Real Time Faxing é como um sistema de encaminhamento entre redes de PSTN, onde um terminal de Fax padrão (T.30)
envia um documento através de uma rede PSTN para um gateway T.38. Por sua vez, esse gateway converte ou encapsula o protocolo T.30 em uma stream de
dados T.38. Essa stream é enviada para um terminal que possua o protocolo T.38 ou para outro gateway, que se encarregará de converter ou desencapsular a
stream de dados e entregar via rede PSTN a um terminal de Fax T.30. Todo esse processo ocorre de forma transparente para os terminais de fax T.30, como
se eles estivessem utilizando apenas uma rede PSTN para se comunicar.
 
A figura 1 ilustra o cenário em que o Real Time Faxing (T.38) é utilizado entre redes PSTN.
 

Figura 1 – Uso de T.38 entre redes PSTN [WIKI/T.38].

 
A recomendação T.38 define o uso tanto do TCP quanto do UDP para o transporte de pacotes IFP (Internet Facsimile Protocol). No entanto as
implementações tendem a utilizar o protocolo UDP, pois o TCP requer a transmissão de pacotes de reconhecimento (ACKs) e conseqüentemente efetua
retransmissões no caso de alguma perda de pacote ser detectada [WIKI/T.38]. Esse comportamento do TCP introduz um maior atraso no recebimento dos
pacotes. Quando o T.38 está usando o protocolo UDP, usa-se transmissão redundante de pacotes para contornar o problema de perda de pacotes.

As implementações que utilizam o TCP como protocolo de transporte devem preceder os pacotes do (IFP) com o cabeçalho TPKT (Transport Protocol Data
Unit Packet) definido na RFC 1006. A figura 2 exibe a estrutura dos pacotes de uma implementação baseada em TCP.
Figura 2 – Estrutura do pacote T.38 TCP/TPKT/IP [ITU/T.38].
 
Para as implementações que utilizam UDP como protocolo de transporte, os pacotes IFP pode ser encapsulados em UDPTL (Facsimile UDP Transport
Layer) ou em RTP (Real Time Protocol).
 
O cabeçalho UDPTL representa as informações adicionais de cabeçalho requeridas para o controle de erro sobre UDP. A figura 3 exibe a estrutura da um
pacote utilizando UDP + UDPTL.
 
 

Figura 3 – Estrutura do pacote T.38 UDP/UDPTL/IP [ITU/T.38].

 
A utilização do RTP para encapsular sinais T.38 somente deve ocorrer se ambos os gateways negociarem essa capacidade durante o estabelecimento da
chamada. Com a encapsulação RTP, podem ser usados os mecanismos opcionais de redundância e FEC (Forward Error Correction) descritos nas RFCs 2198
e 2733, respectivamente. A figura 4 exibe a estrutura de um pacote utilizando UDP + RTP.
 
 

Figura 4 – Estrutura do pacote T.38 UDP/RTP/IP [ITU/T.38].

 
O T.38 não é um protocolo de estabelecimento de chamadas, para isso ele deve ser utilizado em conjunto com algum outro protocolo que efetue o
gerenciamento de chamadas, como por exemplo H.323, SIP, H.248 e MGCP. Os dispositivos envolvidos em uma transmissão T.38 devem utilizar o mesmo
protocolo de gerenciamento de chamadas para o estabelecimento da mesma.
 
2.2.1 Estabelecimento de chamadas com H.323
 
O estabelecimento de chamadas T.38 utilizando o protocolo H.323 está definido no Anexo B da recomendação ITU-T/T.38. Esse anexo define que o
estabelecimento de chamadas T.38 deve ser baseado Fast Connect Procedure (Procedimento de Conexão Rápida) que está definido na recomendação H.323
do ITU-T. As implementações podem operar em dois ambientes distintos e compatíveis do H.323:

1. Apenas Fax sobre IP: Neste ambiente não é provido nenhum suporte à voz. Os procedimentos e requisitos da recomendação T.38 Anexo B devem
se aplicar a implementações operando neste ambiente, a menos que elas sejam substituídas por uma implementação do H.323 Anexo D.
2. Fax e voz sobre IP. Implementações neste ambiente devem utilizar os métodos descritos no Anexo D da recomendação H.323.

As implementações do T.38 Anexo B usam apenas o Fast Connect Procedure para estabelecimento de chamadas e não suportam negociação H.245. Por sua
vez, as implementações do H.323 Anexo D suportam tanto o Fast Connect Procedure quanto o procedimento normal do H.323 para estabelecimento de
chamadas. A maioria das implementações do H.323 também suporta negociação H.245.

O Anexo D da recomendação H.323 requer que os pacotes de fax T.38 sejam enviados em portas TCP/UDP diferentes das usadas pelo H.225.0 de
sinalização. Todas as portas requeridas são reservadas/conectadas durante o processo de fastStart. Uma implementação mínima do T.38 Anexo B requer uma
porta TCP para sinalização da chamada e, ou uma porta UDP para o UDPTL, ou duas portas UDP para o RTP (uma para o RTP e outra para o RTCP), ou
uma porta TCP para informação de fax T.38.

Terminais em conformidade com T.38 Anexo B não são requeridos a suportar a recomendação H.245, com exceção de algumas funções necessárias para
suportar a sinalização fastStart. Um terminal H.323 pode utilizar a mensagem do tipo Facility para determinar se o terminal T.38 Anexo B suporta ou não a
recomendação H.245.

As implementações H.323 possuem um procedimento de estabelecimento de chamada de múltiplas fases, que incluem:

 RAS (Registration, Admissions and Status) sinalização usando UDP entre o terminal e o gatekeeper.
 H.225.0 sinalização de chamada que ocorre ou diretamente entre os terminais, ou entre os terminais e o gatekeeper, dependendo do modelo de
chamada em uso. Utiliza TCP.

 H.245 negociação de capacidades e administração do canal lógico usando TCP.

Embora o suporte ao RAS seja obrigatório, um terminal H.323 não é obrigado a usar o RAS a menos que um gatekeeper esteja presente na rede e provendo
serviços ao terminal. Dessa forma, uma implementação T.38 Anexo B pode ser usada com ou sem um gatekeeper. Ele poderia obter o endereço IP do
destinatário de qualquer forma desejada, como LDAP ou um catalogo pessoal. No entando se há um gatekeeper provendo serviços no ambiente, ele deverá se
registrar e operar de acordo com a recomendação H.323.

Implementações em conformidade com T.38 Anexo B devem também estar em conformidade com a sinalização RAS do H.323. A sinalização RAS permite a
uma implementação T.38 iniciar uma chamada, usando as portas TCP padrão do H.323, e prove alocação dinâmica das portas a serem usadas para as
mensagens T.38.

As implementações em acordo com o T.38 Anexo B utilizam as mensagens de estabelecimento de chamada do H.323 conforme descritas no capitulo 8.1.1 da
recomendação H.323 [ITU/H.323], sendo assim, o texto inicial do capítulo 8.1 também são relevantes para uma implementação T.38. O resto do capitulo 8.1
aplica-se apenas se um ou ambos os terminais estiverem registrados em um gatekeeper.
As implementações em acordo com o T.38 Anexo B devem iniciar as chamadas abrindo uma sessão TCP/IP e enviando uma mensagem H.225.0 SETUP com
os campos de conexão rápida preenchidos como descrito no capítulo 8.1.7 da recomendação H.323.

O terminal de destino responde com uma mensagem H.225.0 ALERTING, CALL PROCEEDING, PROGRESS, ou CONNECT de acordo com o
procedimento de conexão rápida do H.323. As implementações do T.38 Anexo B não devem incluir quaisquer elementos de vídeo, voz ou dados na estrutura
fastStart. Este deve conter apenas elementos pertinentes a transmissão de fax.

2.2.2 Estabelecimento de chamadas com SIP

O procedimentos para estabelecer chamadas T.38 utilizando o protocolo SIP/SDP (RFCs 2543 e 2327, respectivamente) são definidos no Anexo D da
recomendação ITU-T/T.38.

De forma semelhante às definições para o estabelecimento de chamadas utilizando o H.323, as implementações em conformidade com o T.38 Anexo D
também podem operar em dois ambientes distintos e compatíveis:

 Apenas Fax sobre IP. Neste ambiente não é provido nenhum suporte a voz. Os procedimentos do capítulo 2.2.3 do T.38 Anexo D devem ser
 aplicados nas implementações que operam nesse ambiente;
 Fax e voz sobre IP. Todos os procedimentos do T.38 Anexo D devem ser aplicados nas implementações operando nesse ambiente.

Os pacotes de Fax T.38 são enviados em portas TCP/UDP diferentes das utilizadas pelo SIP para sinalização de chamadas. Uma implementação mínima do
T.38 Anexo D requer uma porta TCP/UDP (5060 por padrão) para sinalização da chamada e uma porta TCP ou UDP para as informações de Fax T.38.

O Anexo B do T.38 indica que o procedimento FastCall Setup é o mecanismo básico para estabelecimento de chamadas T.38. O método descrito no Anexo D
foi criado para ser usado em conjunto com esse mecanismo em um modelo de gateway decomposto. O Anexo D também pode ser usado se o gateway
transmissor tem ciência que o gateway de destino suporta o mecanismo de estabelecimento de chamadas do T.38 Anexo D.

De acordo com a sessão 1 da RFC 2543, o SIP suporta um procedimento de cinco fases para o estabelecimento e encerramento de chamadas:

 User location: determinação do sistema final utilizado para a comunicação;

 User capabilities: determinação da mídia que será usada e seus parâmetros;

 User availability: determinação da disposição do sistema chamado em aceitar a comunicação;

 Call setup: estabelecimento dos parâmetros da chamada em ambos os sistemas de origem e destino;

 Call handling: inclui transferência e finalização das chamadas.

O SIP também pode ser usado em conjunto com outros protocolos de estabelecimento e sinalização de chamadas, como por exemplo executando a função de
integração de H.248 para H.323.

O SIP pode convidar usuários para sessões com ou sem reserva de recursos. O SIP não efetua reserva de recursos, mas pode transportar ao sistema convidado
as informações necessárias para efetuá-las.
Para conexões do tipo apenas fax, o gateway transmissor envia uma requisição do tipo SIP INVITE (com as opções apropriadas configuradas) para abrir uma
chamada T.38 com o servidor SIP de destino. O servidor de destino será também o gateway de destino; no entanto, ele pode também agir como proxy ou
redirecionar a chamada para o gateway verdadeiramente de destino através de SIP ou por outros meios. Em qualquer caso uma resposta será enviada ao
gateway de origem informando se a requisição foi aceita, redirecionada ou se falhou.

Se for aceita (ou o redirecionamento do INVITE for aceito), a chamada de fax T.38 prossegue.
Uma vez que a chamada foi estabelecida, a chamada pode ser encerrada com o comando SIP BYE.

Para conexões do tipo faz e voz, inicialmente é enviado o comando SIP INVITE requisitando uma chamada de voz de acordo com a RFC 2543. Então ao
chamada de voz é completada.

Uma vez que o gateway de destino detecta que a chamada trata-se de uma transmissão de fax, ele envia uma requisição do tipo SIP INVITE para o gateway
de origem (essa requisição possui o mesmo identificador (Call-ID) da conexão de voz existente), para iniciar uma conexão T.38. Quando o estabelecimento
da chamada de fax é finalizado, a chamada de fax T.38 prossegue com um pacote indicador de flags T.38 V.21.

Note que durante a troca para o canal de fax e durante a chamada de fax pode ser útil deixar o canal de voz mudo. O canal de voz pode ser usado novamente
quando o final da transmissão do fax for detectada. De forma alternativa, algumas implementações podem optar por substituir o canal de voz pelo canal de
fax.
Quando a chamada for completada, ela pode ser desconectada com o comando SIP BYE.

Existem várias capacidades que precisam ser negociadas para determinar que opções os gateways suportam e usam.

O protocolo SDP (Session Description Protocol) prove mecanismos para descrever sessões para o SIP. Existem vários parâmetros específicos do T.38 que
podem ser negociados durante o estabelecimento da stream de mídia T.38. Por razões históricas essa negociação é feita de forma diferente para o transporte
UDPTL/TCP e para o transporte RTP.

2.3 Store and Forward Faxing (T.37)

Este método de transmissão é definido principalmente pela recomendação T.37 do ITU-T, que faz referencia a várias outras recomendações e padrões.
Dentre elas podemos destacar a RFC 2305 (A Simple Mode of Facsimile Using Internet Mail), que propõe um modo de transmitir documentos de Fax através
de uma rede de pacotes, como a Internet, utilizando padrões como MIME (Multipurpose Internet Mail Extensions) e SMTP (Simple Mail Transfer Protocol).

De uma forma simplificada, o T.37 define um procedimento para receber um Fax em um gateway; criar uma mensagem de e-mail; anexar o Fax ao e-mail
como uma imagem no formato TIFF; enviar esse e-mail para algum gateway remoto; efetuar uma ligação dial-up a partir do gateway remoto para o
dispositivo de Fax de destino e entregá-lo. O Fax pode alternativamente ser entregue como uma mensagem de e-mail com o Fax em anexo diretamente na
caixa postal do destinatário [UNDERWOOD].

O Store and Forwarding pode operar em dois modos segundo a definição do ITU-T [ITU/T.37]:

 Simple Mode;
 Full Mode.

A interoperabilidade garantida através da comunicação em Simple Mode. Todos os terminais em conformidade com a recomendação T.37, e capazes de
recepção devem ser capazes de receber em Simple Mode. É recomendado também que terminais em conformidade com a recomendação T.37, e capazes de
transmitir, devem ser capazes de, no mínimo, transmitir em Simple Mode.

2.3.1 Simple Mode

Este modo suporta apenas a transferências de imagens. Negociação de capacidades e confirmação de recebimento não são requisitos do Simple Mode, mas
podem ser conseguidos utilizando funções de Email que não fazem parte do escopo da recomendação do Simple Mode.

A recomendação T.37 define os seguintes requisitos de implementação para o Simple Mode:

 
Transmissor

Requerido Enviar a imagem como um único arquivo MIME RCF 2301 Perfil S com múltipla paginas. RFC 2305 § 2.2.3

Prover notificação em caso de falha local na transmissão. RFC 2305 § 2.3.1

Prover um endereço de retorno de Internet Mail que seja compatível com MIME. RFC 2049

Altamente recomendado Incluir o Message-ID. RFC 2305 § 2.2.1

Usar Base64 para codificar a imagem.  

Opcional Usar outros perfis do TIFF caso haja conhecimento prévio de que tal perfil é suportado pelo destinatário. RFC 2305 § 4

Prover notificação no recebimento de DSN ou outras notificações. RFC 1894

Tabela 1. Requisitos do transmissor T.37 em Simple Mode [ITU/T.37].

 
Receptor

Requerido Ser compatível com MIME, exceto por não ser requerido a oferecer para colocar o anexo MIME em um arquivo e pode RFC 2305 § 2.2.2
imprimir o arquivo recebido ao invés de exibi-lo.

Ser capaz de processar múltiplas imagens MIME RFC 2301 Perfil S em uma única mensagem. RFC 2305 § 2.2.4

Prover notificação em caso de recebimento ou problemas de processamento. RFC 2305 § 2.3.2

Opcional Usar outros perfis TIFF. RFC 2305 § 4

Tabela 2. Requisitos do receptor T.37 em Simple Mode [ITU/T.37].

2.3.2 Full Mode

Este modo suporta as mesmas funcionalidades do Simple Mode, adicionando duas novas funcionalidades: a negociação de capacidades e a notificação de
entrega.

O Full Mode é descrito na primeira correção da recomendação T.37 [ITU/T.37-AM1], e define os seguintes requisitos de implementação:

 
Transmissor

Requerido Enviar a imagem como um único arquivo MIME RCF 2301 com múltipla paginas. RFC 2305 § 2.2.3

Prover informações no caso de problemas no encaminhamento. RFC 2305 § 2.3.1

Prover um endereço de retorno no cabeçalho do envelope SMTP. RFC 2305 § 2.3.1

Requisitar Notificação de Estado de Entrega (DSN), caso o remetente deseje confirmação de entrega. RFC 2532 § 2.1.1

Requisitar confirmação de leitura (MDN), caso o remetente deseje confirmação de leitura. RFC 2532 § 2.1.2

Altamente Incluir o Message-ID. RFC 2305 § 2.2.1

recomendado

Usar Base64 para codificar a imagem.  

Ser capaz de reconhecer e processar as etiquetas de características conforme definido na RFC 2531, quando RFC 2532 § 3
revisando as capacidades apresentadas pelo recipiente potencial.

Opcional Usar outros perfis do TIFF caso haja conhecimento prévio de que tal perfil é suportado pelo destinatário. RFC 2305 § 4

Prover notificação no recebimento de DSN ou outras notificações. RFC 1894

Requisitar um DSN positivo e um MDN, se a capacidade de resposta DSN/MDN é desejada. RFC 2532 § 3.3

Enviar uma mensagem contendo tanto uma imagem com quantidade mínima de características do TIFF, quanto RFC 2532 § 3
uma imagem com tantas características de qualidade quanto suportadas, usando multipart/alternative.

Sobrescrever manualmente as configurações padrão. RFC 2532 § 3.1

Acessar uma arvore de diretório com as capacidades do destinatário. RFC 2532 § 3.2

Usar quaisquer dos perfis TIFF definidos na RFC 2301 quando enviando para um recipiente com as capacidades RFC 2532 § 3
correspondentes, baseado na resposta DSN/MDN.
Tabela 3. Requisitos do transmissor T.37 em Full Mode [ITU/T.37-AM1].

 
Receptor

Requerido Ser compatível com MIME, exceto por não ser requerido a oferecer para colocar o anexo MIME em um arquivo e RFC 2305 § 2.2.2
pode imprimir o arquivo recebido ao invés de exibi-lo.

Ser capaz de processar múltiplas imagens MIME RFC 2301 Perfil S em uma única mensagem. RFC 2305 § 2.2.4

Prover notificação em caso de recebimento ou problemas de processamento. RFC 2305 § 2.3.2

Implementar MDN (Message Disposition Notification). RFC 2532 § 2.2

Indicar as características de mídia suportadas nas mensagens DSN e/ou MDN de acordo com RFC 2530. RFC 2532 § 2.2

Ser configurável para silenciosamente ignorar uma requisição de MDN RFC 2532 § 2.2.1

Não gerar uma mensagem de MDN não solicitada, para indicar sucesso de processamento. RFC 2532 § 2.2.1

Possibilitar a um operador desabilitar respostas automáticas de MDN. RFC 2532 § 2.2.1

Não gerar DSN quando usando POP3 ou IMAP. RFC 2532 § 2.2.2

Altamente Se o MTA determinar que a mensagem não pode ser processada, rejeitar a mensagem com código de erro 5.6.1. RFC 2530
recomendado

Opcional Ser capaz de processar qualquer perfil TIFF. RFC 2305 § 4

Sistema automatizado que possa ser configurado para sempre responder a uma requisição MDN. RFC 2532 § 2.2.1

Tabela 4. Requisitos do receptor T.37 em Full Mode [ITU/T.37-AM1].

3 Conclusão

O uso de canais VoIP para aplicações de Fax, ou qualquer outra aplicação que utilize modems, não é confiável. Essa é uma característica que não irá
melhorar com o tempo, pelo contrário, a tendência é que fique cada vez pior. Isso se deve à própria evolução dos equipamentos de comunicação VoIP que
buscam otimizar a transmissão da voz humana, com codecs que utilizam algoritmos elaborados de compactação com perda, supressão de silencio, introdução
de som de fundo, etc.

A utilização de Real Time Faxing com o protocolo T.38 introduz uma confiabilidade muito maior nas transmissões de faz sobre redes IP, permitindo
inclusive que os terminais de fax negociem suas capacidades. No entanto sua utilização na pratica ainda possui alguns impedimentos, pois uma grande
quantidade de dispositivos ainda não o suportam. E ainda existem dispositivos que dizem suportar o T.38 mas possuem implementações defeituosas que
geram muitos problemas de utilização.

O Store and Forward (T.37) é uma especificação muito simples, que utiliza que utiliza protocolos largamente difundidos, e que apenas define alguns detalhes
necessários para que esses protocolos sejam unidos para trabalhar como uma aplicação de fax. Por esse motivo é o método mais confiável e utilizado
atualmente para aplicações de fax sobre redes IP.

http://www.fassi.eti.br/artigos/convergencia/foip
http://www.fassi.eti.br/artigos/convergencia/foip