Re: [hylafax-users] faxing over sip

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

A J Stiles wrote:

> A fax is just a collection of zeros and ones.  These are conventionally sent 
> over a circuit-switched analogue connection using a modem.  There's no real 
> reason why the raw zeros and ones that make up a fax image shouldn't be sent 
> over a packet-switched digital connection.  In practice, that doesn't happen; 
> and they end up being transformed into a different stream of zeros and ones, 
> representing the sounds that would have been made by a modem had it been fed 
> the original zeros and ones.
>  

Essentially this is true.  The fax image and all of the fax protocol 
communication is digital (ones and zeros).  Because fax predates the 
internet and because the PSTN was (and still is) more pervasive, this 
digital information was originally modulated (into analogue audio) and 
"reliably" transmitted over the PSTN.  Since then we now very often see 
(and use) digital PSTN circuits, but instead of an analogue audio stream 
a digital representation (usually uLaw, alaw, or slinear) of that audio 
stream is communicated over the circuit.  So these days in most cases 
the scenario is like this:

The sender's fax machine makes a digital representation of the analogue 
source material by scanning it.  This digital information is 
communicated by modulation to the receiver.  The sender's telco will 
inevitably digitize the modulated audio and it will remain in this 
digitized format until it hits the receiver's telco where it will be 
made analogue and sent to the receiver's fax machine.  The receiving fax 
machine demodulates the audio into digital information and then 
reproduces it onto paper in an analogue format.

So yes... the fax goes from analogue to digital to analogue to digital 
to analogue to digital and then again to analogue (typically six 
transitions).

If one had digital PSTN connections on both ends of the call, in theory 
one could then skip the whole modulation process.  Thus the sender would 
digitize the image and that digital information would be communicated 
over the digital PSTN to the receiver who would print it onto paper.  
This "theory" exists in reality, and it is called "G4 Fax", and yes, the 
digital information is communicated at 64 Kb.  However, it is an 
extremely rare thing, and it largely only exists where ISDN circuits are 
popular to homes and small businesses.  (I understand that this is the 
case in some parts of Europe.)  In practice G4 Fax is rather cumbersome, 
however, because it requires both endpoints to support G4 Fax.  So if 
one endpoint doesn't support G4 Fax then either the communication cannot 
occur or the communication will need to transition to "plain" G3 that I 
described above.

In theory one could use the internet in that "G4 Fax" scenario to 
replace the PSTN.  I say "in theory" because in all of the attempts to 
fax-over-internet nobody does it that way.  It would need to be done on 
TCP/IP as data loss/corruption is unacceptable in most of the fax image 
formats (loss is inherant in nearly any internet-run UDP/IP 
connection).  Of course, the critical problem in implementing this 
theoretical fax scenario is that you will want to communicate with so 
many old-school PSTN-connected fax machines, and thus yet another 
gateway device will be required.

T.37 is very simple: take the fax image and wrap it up in a formatted 
SMTP message.  The problem with T.37 is twofold:  first, as someone 
already said, image formatting and negotiation does not occur, and so 
it's impossible to know for certain that the receiver will be able to 
view your JBIG-encoded or ITULAB JPEG-encoded fax image; and second, 
it's not done real-time, and so the sender doesn't know immediately (if 
ever) if the receiver got it.  Add the congestion and problems that 
plague SMTP these days (e.g. spam) and T.37 seems rather unreliable.

The idea behind T.38 is comparatively rather simple, too:  skip the 
entire modulation/demodulation process (like with G4 Fax), but 
communicate over a VoIP channel instead of the PSTN.  The problems with 
this are, unfortunately, plentiful - not impossible to work around - but 
certainly plentiful.  First, VoIP channels use UDP/IP as a medium (to 
keep the call as real-time as possible)... and so packet loss (jitter) 
is almost inevitable unless you can control the entire network path and 
ensure that loss will nearly never occur.  T.38 compensates for UDP 
jitter by allowing T.38 endpoints to add "redundancy" into their data 
communication.  Thus every piece of data may be retransmitted several 
times in sequence in an expectation that not all packets will be lost.  
Unfortunately not all T.38 equipment/software uses enough redundancy by 
default for many applications to work without a hitch.  Furthermore, 
redundancy does not guarantee against packet loss, so jitter may still 
occur depite even large amounts of redundancy.  Second, there are a few 
technical complications to T.38 gatewaying that makes T.38 a bit 
difficult for implementors to get right (the gateway often has to 
compensate for "quirks" on both ends of the call... and even disparities 
between function support)... and so T.38 equipment/software is not 
without it's fair share of bugs itself.

> There will be naysayers on this mailing list, but I have seen with my own eyes 
> a fax machine connected to an Asterisk PABX via a Grandstream Handytone 286 
> ATA  (analogue telephone attachment adaptor; essentially a VoIP phone without 
> a phone in it, just an RJ-11 socket where a standard phone can be plugged 
> in).  And, amazingly, it worked.

I don't think that anyone is saying that it won't ever work.  What we've 
been saying is that it's not reliable.  Because you cannot usually 
control all the factors involved, and because many of them will work 
against you (i.e. UDP) by their nature, it's difficult (if not 
impossible) to reliably reproduce that working scenario in any other 
arbitrary environment.  It may work for you at one place, but it may not 
work at another, and if it does then it's misleading to indicate to 
others that they should be able to expect the same outcome as you.

I try to cover this in detail here:

http://hylafax.sourceforge.net/docs/fax-over-voip.pdf

> If that horrendous bodge could work, 
> there's no reason why using Hylafax in conjunction with iaxmodem shouldn't 
> work -- provided that packets are getting through to the Asterisk server fast 
> enough.
>  

Well, first of all, IAXmodem was intended to work over the loopback 
adapter.  It was never intended to be used over a WAN, and even to some 
extent never over a LAN, either.  I have tried to compensate for things 
in IAXmodem as much as I can, but there's only so much that can be done.

> It *won't* work -- or will work very badly -- if you have variable latency, 
> because this introduces exactly those sorts of "impossible" errors which fax 
> machines simply were not built to handle.

Sure, variable latency is something to handle.  It means that packets 
ordered ABCD may arrive as CBDA... however, a fixed-length, short buffer 
in the device can easily overcome the vast majority of this kind of 
thing.  I've done that in iaxmodem's "jitterbuffer"... however, over 
time I've found that in most cases if a UDP packet is late... well, it 
won't come at all... it got dropped.  So in most cases if C arrives 
before A or B it means that A and B aren't coming at all, and I've found 
that the DSP actually can cope without them far better than it can cope 
with any packet-loss concealment that such a buffer use would typically 
imply.

Thanks,

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*