I’ve searched through a bunch of similar topics throughout the web but just wanted to clarify again regarding the faxing over IP topic.
My scenario
Cisco SPA122 registered to a FreePBX extension which then has dedicated inbound/outbound routes for inbound/outbound faxes. Using sip.us as the trunk provider. All extensions are pjsip.
I heard that T.38 faxing is more reliable. I configured my ATA per suggestions on the internet for optimal faxing with T38 enabled, I’ve also enabled T38 with Redundency in SIP Settings in FreePBX. Where else do I need to enable T38 to ensure that it is definitely the protocol to be used for faxing and not G711?
Also how can I check for sure, that the fax transmission is indeed using T38? Will asterisk -rvvv show it?
Can you guys post any other suggestions on using a Cisco SPA122 with FreePBX for faxing? I would really appreciate it.
I use a Cisco SPA122 too…but it is connected through a separate SIP-trunk with my trunk provider, just for faxing. You have to adjust the SIP settings of the SPA122…it does not work out of the box! Faxing is very tricky nowadays…
It’s just for outgoing faxes. My trunk provider has a fax-to-email service for incoming faxes.
With “nowadays” I meant since the analogue phone lines got completely replaced by virtualized versions.
In Germany/Austria it was still possible to have a real analogue phone line (just for the fax), but not anymore.
T.38 is nice, but the problem is that in real life it just works 90-95%…which is not good enough.
FAX has always been a best effort service. Generally with analog lines, you don’t have logs about the call failing or having to retransmit the fax 3 times to get it to fully complete. You also never knew when you missed another fax because your fax machine was busy with another fax.
“Traditional” faxing still had a fair amount of failures, half completed transmissions and faxes not being delivered because the fax line was busy or the classic “can’t receive or send faxes because memory buffer on machine is full”.
Not being aware of failures/problems is not the same as no failures/problems.
Analog phone lines did not get ‘completely replaced’ in many parts of the world, but G711 was never 100% either, T38 will complete a fax through your provider to their point of egress to the PSTN because there is no way to know if the far end is T38 compliant until the connection is negotiated They will then complete with T38 or G711 as appropriate, (some are better than others doing that). We see better than 99% completion with hundreds of pages a day . This is about the same success as we saw ten years a go with brooktrouts and and analog/PRI channeling (g711).
If you want well reported and persistent attempts to complete a fax, Hylafax still is a good choice IMHO
What about the speed? I am old enough to remember that 20 years ago or so, the speed of an office fax was around 33.000 b/s, wasn’t it? Now because of latency issues over the www, you have to decrease it to 14.000 or below.
Well…but the truth is that a technology of the 70s runs best in an analogue environment…which does not exist anymore. 33.000 cannot be achieved in the digital world
It doesn’t exist anymore in Germany/Austria perhaps, I get about 20 to 30 seconds per page over T38 depending on content, T38 supports effective compression, G711 at 33000 would be quite comparative at it’s ‘standard’ scan rate, which of course can’t ‘compress’ because it is a 64(/56)kbs bit stream in the PSTN world, slowed down by any ECM
30s per page sounds like 14.000 to me…33.000 was way faster…was it called G3 fax? Cant remember.
Are you located in the U.S.? I once lived in California for several years…and was surprised how bad the phone line infrastructure was. So it is definitely not a matter of location.
Of course 33 is quicker than 14 , I cant’ tell you how many complaints I get from clients watching their fax machine spitting out a 100 page fax over T38 ( I can’t tell you that because I have never got one )
They do like it when it arrives in their email box though.
The modems that could run at 33k didn’t come into existence until the PSTN backbone and medium to large business PABX connections were already digital. The original fax modems ran at 9.6kbps.
(56kbs modems were only possible when the sending end was digital, and the only analogue connection was the final hop to the receiver, although that constraint made them unsuitable for fax machines.)
What is actually degrading the signal is actually the use of packet switching over a network designed for data, not voice., not the transition from analogue to digital Voice calls went from analogue to time division multiplexed digital in the 80s, possibly even starting in the 70s, then to ATM, a packet switching technology optimised for voice, probably late 80s to 90s, but are now moving to IP, which was never optimised for voice.
@Charles_Darwin [I love your evolution work] Have you tried FreePBX Fax Pro, it’s all digital, but I’m using it for 31 schools with around 800 staff, and it’s been a champ. I ditched all my “real” hardware faxes (Built into printers), and the staff just uses the FAXPro UCP interface. The only thing I kept was the DIDs that pointed at the Old Fax hardware, and Just inbound routed them to the digital Fax box (FaxPRO).
No, I haven’t used FaxPro yet. Good to know that it works.
I actually dont have any problems with my configuration too, except that a fax sometimes needs 1-2 redials to get through. Problem is that pharmacies in Austria/Germany are not allowed to digitally send doctor’s prescriptions to health insurance companies (sometimes necessary for approval). They still have to use a fax and they have to use it a lot. Employees dont want to use a scanner and a computer for that…they have to take care of the customers in the pharmacy and dont have the time. Lots of enquiries during the Covid pandemic…lots of faxes. Funny thing is … there is already a high profile medical network in place (doctors, pharmacies, health insurance companies), but you still have to use 50 years old technology sometimes
(actually I don’t think C Darwin was right, but that’s a different story )
