Inbound Fax to Email Issue

[SIP Connect]

Hello All,

I am hoping that someone out here can help me because the 3CX support now has stopped helping me.

The issue i am having is that a fair few of my customers are reporting that the faxes they are receiving by email is coming through corrupted. parts of the pages are cut off or it is unreadable.
This is not isolated to 1 installation, but across several.
I have a fax server that i setup a SIP trunk on that sends faxes to the email address of a specified extension (not 888). This way i can have 1 sip trunk and 1 extension per customer.

This issue isn't of every fax but it has been happening a lot recently. I have had this setup for a very long time and this issue has only started this year.

I have tried to rebuild the sip trunk, point the fax to 888, move the sip trunk to a different install, change codecs, change sip trunk settings but nothing has worked. The customer still receives corrupted faxes.
The weird thing is when i send a test fax i haven't been able to replicate the issue. I dont have a PSTN line to send faxes so im sending via a VoIP number and all my faxes come through fine. I have also confirmed that the bad faxes are coming from multiple different sources and not just 1 source so its not an issue with the person sending the faxes.
I think its an issue is a fax is being sent via a PSTN line but cant confirm.

3CX stopped helping when they have seen that my SIP trunk is not from the supported list. the SIP trunk supports fax as we have been using it for the past 5+ years on 3CX and on ATA's connected to fax machines.

Has anyone else had this issue and found a fix for it? im thinking its a 3CX issue receiving faxes from PSTN lines after an update or something like that but the support team wont investigate any further after seeing its a custom sip trunk.

Any help will be much appreciated.

 

[cobaltit]

3CX stopped helping when they have seen that my SIP trunk is not from the supported list. the SIP trunk supports fax as we have been using it for the past 5+ years on 3CX and on ATA's connected to fax machines.

So this reminds me of an article I read last month. My city council voted to renew the contract with a private company for parking enforcement. At the meeting members of public complained that the private company was giving tickets for parking too far from the curb which never happened when the city was doing enforcement. Never mind the fact that it was always a ticket-able offense. In this case congrats that it worked for 5 years. There's a reason why 3CX has supported providers. One of those is ongoing testing between those providers and 3CX.

Has anyone else had this issue and found a fix for it? im thinking its a 3CX issue receiving faxes from PSTN lines after an update or something like that but the support team wont investigate any further after seeing its a custom sip trunk.

Nope, don't have this issue, but then again I don't recommend faxing via 3CX. I have customers sign a disclaimer when they make me setup fax via 3CX. It's fine for occasional use but if you want any real faxing, you keep it on a POTS line or we setup HTTPS fax adapters that don't depend on VoIP. Your reasoning may be on track but your logic is flawed. 3CX has no way of knowing if an incoming fax is coming from VoIP, PSTN, your local copy shop, etc. It's just seeing fax tones and acting accordingly. Now it's possible your unsupported provider made some sort of change with out they interact with the PSTN, perhaps just for certain exchanges and that's the problem. But it's certainly nothing 3CX did.

If you really want to get to the bottom of this then I'd recommend first finding a way to recreate it and/or find the common denominator (besides this trunk provider). It could be they are all on the same ISP and that ISP is sweating a little under WFH traffic.. Then setup a trunk from a supported provider and see if you can recreate it on that. If you have the issue again then 3CX will help you. But you haven't even mentioned if you are using G.711 or T.38 so maybe you should fire up some wireshark and confirm that (or turn off g.711 fall back to make sure it's T.38)

Good luck!