A week ago, a friend approached me about sending off a fax. Despite the march of technology, this particular form had to either be mailed back (taking a few days and costing a decent amount of money) or faxed. My friend had no access to a fax machine, so the task was handed over to me.
I thought about how I was going to achieve this. Due to the sensitive nature of the document, free online fax services were out of the question. I didn’t want to have to sign-up for “virtual fax” services from a VSP either just to send it off as a one-off fax either. I decided I’d have to do it the old fashioned way, as if I was faxing it from my own landline (which I don’t have).
As much as I do love voice-band modems and fax, getting this to work in my new location is especially challenging since I have no access to fixed-line internet at the moment. As a result, the only form of internet I get is wireless – whether that be by 4G/LTE or Wi-Fi. The variability in quality of service from such services doesn’t generally play well with VoIP when carrying data rather than voice.
Still, I decided it would be worth giving it a shot just to see if it could be done.
This one hand-drawn diagram with colour coding shows the whole set-up and the various potential issues related to it. We started with a physical document – this was scanned on a CanoScan LiDE 210 into a PDF file for transmission.
The first issue was to do with the choice of faxing software. In my experience, the most superior Windows-based faxing software would have to be Symantec WinFax Pro, which I still very much like for its halftoned image output, nice status information and support for ECM and 2D compression on send and receive. This is not something which Cheyenne Bitware or the built-in Windows Fax could do. Unfortunately, WinFax Pro doesn’t work well even with Windows XP SP3, so I decided that I’d use it under Windows 2000 Professional instead. This necessitated running it inside a VM, since I didn’t fancy going out to the garage to grab my Windows 2000 laptop to do the fax.
Because Windows 2000 was running inside a VM, I had to inject the PDF file into the vmdk disk. No big issue – mount it read-write and copy it in. The next step was to get something to open it – so I went trawling the internet to download an old version of Acrobat Reader 9 that would run. That was fine.
Next thing I needed was a modem. I had plenty of external serial modems with Rockwell chipsets that play well with the software. Unfortunately VMWare serial pass-through does strange things to the timing of the handshaking signals, so I had to instead use an FTDI USB to Serial cable and use VMWare USB pass-through. This allowed me to install the FTDI drivers under the VM to get a serial port working well-enough to fax. The modem power supply then decided to promptly die … so I had to substitute another 9V AC power adapter at the last moment.
Now I had the modem operational, the modem expects to talk to a phone line. I have no landline here – so I have to emulate one using my Grandstream HandyTone HT702 ATA. This was then connected with my SIP account with myNetFone, so I could route calls to the PSTN via my internet connection.
Therein, lies the crux of the problem. The internet connection is a Vodafone LTE mobile connection out of my Xiaomi Redmi Note 4X. This connection varies quite a lot for speed and reliability despite being a 5-bar signal and carrier-aggregated because the area I’m in has poor fixed line services and many people use LTE instead. The way Vodafone’s network works is that all of the data sessions go through their carrier grade NAT. The phone itself, when operating USB-tethered to my router also has its own local NAT (192.168.42.0/24). Both of these have no facility to do any port forwarding. Finally, my router is configured to further NAT this connection, because the phone only supports around 12 devices directly connected to its tethering. At least I’m not going over Wi-Fi tethering, otherwise I’d have Wi-Fi interference to deal with in addition. To ensure SIP works properly over a triple NAT connection is pretty hard … but somehow, it seems that regular keep-alive packets did the trick well enough.
After emerging from Vodafone’s CGN, the data has to traverse a further 9 hops over the internet to reach myNetFone‘s gateway, where the call could then be patched through to the PSTN. This adds even more latency, jitter and packet loss possibilities.
To test whether this would even be feasible, I attempted a few test calls to try and establish a voice-band modem connection to a known-good V.90/V.92 endpoint. Using G.711a passthrough, no calls were successful in establishing a V.90 connection, with a V.34bis connection at 26.4kbit/s symmetrical being the best that could be established but not sustained over long periods owing to the packet loss causing continuous retraining.
I had my doubts this was going to work. That’s when I decided to abandon the concept of G.711a passthrough and exploit the T.38 capabilities of the ATA and the VSP. By using T.38, instead of passing the call as packets of voice, the packets contain the demodulated data instead along with a back-up copy of the previous packet. This allows the stream to be better buffered without violating fax signal timing requirements and the signal to be regenerated in a “sensible” way even if some loss were to affect the call. Further to this, I decided to enable ECM and 2D compression to minimise the transmission size and allow for errored blocks to be re-requested, providing the recipient machine is capable of it.
In the end, it worked gloriously. Four pages were sent in eight minutes at fine resolution, ECM and 2D compression (MMR) was active and no blocks were re-requested at any time throughout the transmission. Who would’ve guessed that T.38 could work this well?
Against all odds and much to my surprise, the document was delivered successfully despite the very complicated setup and the limitations of the connectivity available. All bets are off as to whether I could do it twice, or at a different time of day, but at least it worked when I needed it to. That’s what counts in the end.
I suppose another option would be to use something like a software T.38 modem that emulates a fax modem on one side and communicates with a VSP using SIP and T.38 to send the fax, although this might not be quite the same for reliability and flexibility and is not something I’ve tried.
I just hope I don’t need to send any more faxes …