Inbound faxes cut off

[boba1120]

Hi all, I'm having an issue where my faxes are received but the pages are randomly cut off. I don't see any pattern, it's not the same number of pages or amount cut off, and it doesn't happen every time. The provider is a Comcast PRI trunk running through a Patton 4960 gateway provisioned by 3CX.

Any thoughts or suggestions greatly appreciated.

Thanks!

 

[craigreilly]

are you on v10 or v11?

 

[boba1120]

v10 sp6, I think I may have upgrade insurance to 11, but I haven't really explored it yet.

 

[craigreilly]

I think there are issues with how Analog lines and 3cx (SIP) play as far as faxing goes - but I understand that v11 handles this issue. Hopefully someone else will chime in.

You also do not mention if the "fax" is a real fax on an Analog adapter or 3cx digital fax to email.

 

[lneblett]

So, one of the PRI channels is a DID dedicated to a fax. You did not indicate if the fax is a phyiscal device connnected to 3CX with an ATA or if simply using the built-in 3CX fax server.

When you say you receive the fax, but the pages are randomly cut-off....does this mean that you get all the information that the page has to offer, or that some infomation is cut-off as a consequence of the random cutting? There used to be (maybe still are) machines that had a roll of paper and these would be cut by the fax machine as each page was completed. So, in the case of an 8.5x11' standard letter page, if the page only contained info on the first 6", then the receivng machine would cut the page at that point rather than using up an additional 5.5 " inches of blank paper.

I am guessing you mean that the fax is not completing the transfer of information so some pages are missing info; yet the fax sends/receives all the pages (say 30 of 30) regardless. In essence, it looks like a completed fax, but printed info/data is not there.

If on an ATA with a physical fax machine, you can try and slow down the receive rate and see if any difference.

 

[boba1120]

Sorry for delayed response, for some reason I don't get notification emails from the forum even though the settings look right...

Anyway, it is a fax being received by the 3CX fax server and sent to email. The PDF attachment isn't missing data, the result I get is that the last page received has the appearance of being physically cut, as in it may be significantly shorter than 11", where the source most definitely was not. The source TIFFs in the folder on the server look the same.

So to clarify, it does *not* look like a completed fax. I didn't see anything related to faxing in the v11 release notes, but I guess it can't hurt to try it if I'm entitled.

 

[lneblett]

Well, if there is no loss of data and the fax does indeed contain all the info, but merely has an appearance of being cut, perhaps it is nothing more than how the protocol works. In other words, as the fax is scanned perhaps the blank area of the last page is detected by the sending fax and an end-of-text/message type of transmission is sent which would effectively eliminate the need for sending and receiving further null data.

Does it do it to all messages or is it simply that the vast majority of faxes come from one machine/number? If the TIFF appears the same as the resulting PDF, then I don't know that there is a real problem unless data is missing.

V11 has some enhancements to the setting up for faxing, but nothing that I know of that address this issue. This seems cosmetic in nature where it might be construed by some as missing data. In any event, if entitled to V11, then there are a number of enhancements elsewhere to make considering an upgrade worthwhile.

 

[GManNAtl]

I am currently using a Sangoma A101 and have been suffering with fax problems for 8 months. I have opened dozens of tickets with both Sangoma and 3CX and cannot get the issue resolved. The last round of captures and days worth of emails resulted in Sangoma escalating it as a bug. Then they came back and wanted the recordings from a failed fax saying that it seemed the external fax machine is the problem. If this is the case then every fax machine in the South Eastern United States has a problem, but my install of 3CX and Sangoma does not. Once again tonight I will be spending more time collecting info for them to look at. I have rebuilt the server from the ground up 5 times now and the problem is mostly random although faxes with images are a major problem and can rarely be received properly. I was actually considering eating the cost of a new Patton gateway in hopes that it would solve the problem, but seeing as you are having the same issue I'll hold off. I just figured 2K out of pocket is much better than being sued by my customer. Fortunately, I have a very good, long term relationship with this customer or I would have probably already been sued, but patience is running thin.

Good Luck

 

[lneblett]

Is this not two different issues? One seems to be related to the internal fax server and, unless I read the response wrong, does not involve a loss of message/data, but is cosmetic in its appearance. Your issue seems to be related to getting an external fax machine to work and does involve a loss of message.

Am i incorrect?

 

[GManNAtl]

No, I am having the exact same problem. Faxes just completely get cut-off using the inbound fax server. I do have other problems like parts of a page being compressed to the point an fax is not legible, and EOP not being detected properly. Primarily, faxes just flat out fail and get cut-off. Here is the last response from 3CX after extensive captures and logging . . .

this will be a question to Sangoma.
The issue is from the the gateway it self as i can see.
As already noticed, to make a pcap is not very easy with an host card...

T.38 must end with an EOP which i can not see here.
I do see 3 pages (MPS followed by MCF) and then BYE which is not right.
The Fax Server needs to know when to put an end to the fax page and there is non...

And right end would be at the last page

From GW: EOP
From PBX: MCF
From PBX: DCN
From GW: SIP BYE
From PBX: SIP ACK

The fax in question they were looking at was one I sent from my own fax server (connected to POTS lines). When I watch it being sent from my server it just flat errors out in the middle of the page, and attempts to resend. This is done in the middle of the night with absolutely 0 traffic on the system so I know it is not a QoS problem, or other network problem. Not to mention that the A101 is installed on the same server so the traffic doesn't even traverse the network at all.

Here is what Sangoma has said. . . .

Our engineers have reviewed the trace and they do see there is no T.30 indicator EOP in the trace. So what we need at this point is to enable call recording to see if the fax machine sending did indeed send this tone. Also note as a T.38 gateway, we do not detect these tones but yet just pass them through.

They seem to think it is the external fax machine that is failing. However, like I said I get dozens of these failed faxes every day from different numbers. This customer relies heavily on faxing and receives a fairly high volume of faxes during the day and most do come in fine, but the problem still persists on an unacceptable number of faxes. If the fax is complex in any way (Images, complex forms, lots of compressed small type) it seems to fail more often.

I just got a new capture last night with the recording as Sangoma has requested, so I am opening the ticket again with them today. I will keep my fingers crossed that they can find out something as tensions are rising. If anyone has any suggestions I am all ears.

 

[lneblett]

In my opinion, not exactly the same.

1. You indicate that you used your own fax server which is connected to POTS lines. While your internal network may not be stressed and you may have more than enough internal resources to handle, this does not take into account how the external network handled. The implication here is that upi went from an analog signal (POTS) to a T1 inteface (digital). The other poster indicated "The PDF attachment isn't missing data, the result I get is that the last page received has the appearance of being physically cut, as in it may be significantly shorter than 11", where the source most definitely was not. The source TIFFs in the folder on the server look the same". He indicated that data is not missing just that the last page is apparently not getting processed correctly. You seem to be indicating that faxes fail which implies loss of data requiring a or mutiple resends. Regardless of the interpretation, you do seem to have a problem.

I don't have a PRI and therefore may not be of much help. I use SIP and have good success receiving,,,,,,,,most of the time. In any event, I did come across this which may or may not help:

http://www.voipsupply.com/blog/voip-faxing-with-the-sangoma-fax-sync-cable

 

[GManNAtl]

My result is the same as described. The last page is simply cut off short. The link you sent me is for faxing from FXS ports going out on another A101 board in the same system. Originally, I had FXS cards to support our legacy outbound fax server and the T1 sync cable and this hardly worked at all. About 50% of our outbound faxes were failing even with the sync, so we just bit the bullet and ordered 4 POTS lines to support the outbound faxing. Works perfect now even though it costs us an extra $120ish a month for the lines.

Overall though I did make some good progress on this today and I don't think the problem is quite as widespread as I had originally thought. I am going to stay on this issue and will post back anything relevant that others can use. I really don't think the disconnect here is on the PRI side, but in the T.30/T.38 signalling between NetBorder and 3CX. So my findings may be relevant even for users on direct SIP Trunking or others using Patton or other PRI gateways. Despite mine and my customers frustration on this issue, with the diligent work I've made on this issue over the past week or two I am optimistic now that it can be resolved.

 

[lneblett]

Well. Sorry I wasn;t much help, but I am hopeful you get it solved.