Fax gateway

I have been gone from the sip arena for some 5 years. Been busy with other activities, but I really need to address my fax needs and MAYBE things are better now. Better be with the planning to ‘shutdown’ the PSTN (well actually to no longer mandate its existence).

I need ‘simple’ fax outbound from a all-in-one printer via its RJ11 jack and its simple, call this fax number interface. The fax gateway may actually use T.38/SIP trunking to contact that fax line, or if known the number is really an efaxmail number (how would one know?) send the email tiff/pdf.

I am a long time Centos user, but for this system, I will be building on an ARM platform. At this point there is no public info if RHEL/Centos 7 will support ARM (its base, Fedora 19 does). So I may well be building this on Fedora 20 (which comes with Asterisk 11).

Current hardware considerations are:

Cubietruck (maybe Cubieboard2 if I can get away with 1GB memory) arm board with a sata drive (pulled from old notebook)
USB-to-FXS dongle (which one?)

Testing will be from my HP 8600 with my 14+ page expense reports.

Why a PBX solution when perhaps an ATA to some SIP service could do? Which ATA to get? IPv6 support is mandatory. And I would probably play with a few other features.

thank you

Why is IPV6 support mandatory?

I am not sure what the question is and how it relates to FreePBX.

If you are looking for a SIP carrier that supports t.38 I know of none better than our own Sipstation. It is integrated via a FreePBX module. The SpanDSP library that is included in the FreePBX distro does not have an ARM target binary.

Even though I have 64 IPv4 addresses here, I am looking forward to the day I will turn them in; I do have a /48 IPv6 allocation. If I am looking forward to the death of PSTN by the FCC (and Michigan gov), I need to watch for the strangulation of IPv4 as well. Does Sipstation support IPv6 connectivity (within a 1 year window)?

I realize that I will have to work with the Fedora ARM community to compile everything FreePBX needs. Hopefully that list exists in the Development track. Of course one of my Intel buddies may decide to get me one of their development armbuster boards (my term, not Intel’s to the best of my knowledge), so I still might end up the Centos 6 route.

You are right. I did not phrase a question as such!

5 years ago FAX/T.38 was a painful experience. What is the most successful approach now?

Does the pbx service work as fax passthrough to T.38 (maintain connection to originating client to provide fax status) or a store and forward service (with fax reply notification of delivery)?

I suppose that direct fax over VoIP is not an issue in this setup, as the pbx will only have SIPtrunking outbound and might as well be T.38 and let the other end deal with the joys of fax machines still on the PSTN. (this one is not really a question)

What USB-to-FXS dongles work with FreePBX and fax devices (eg HP 8600)? (I do have a couple Digium FXS PCI boards, but small ARM boards tend not to have pci).

Is there any service that assists FreePBX to determine that a destination fax number is really email and to send email directly?

BTW, where in Ohio? I am a NE Ohio boy, but left ~45 years ago.

I live in Avon Lake, offices in Cleveland.

t.38 blows still (my technical term). Nobody owns the whole network so it’s hit or miss and it always misses when the customer needs it most. I don’t need the money or the heartache so anyone that can’t deal with our inbound fax to email and outbound PDF to fax (we use PRI’s for connectivity) we make sure they keep a POTS line for FAX. I also highly recommend POTS for 911 and we usually program the phones to directly send 911 to the gateway so the line dual purpose (or triple if use for alarm reporting).

It’s fun to play with t.38 but it is what it is.

We are the oldest ISP in CLE still under local ownership. We have a ton of IPV4 space thankfully. I don’t know of any VoIP wholesalers that are doing V6 so right now it is not even on my planning radar. I may be wrong, but it sure doesn’t feel like it. Just no sense of urgency like the on that surrounded code splits in the 90’s when the PSTN e.164 numbers were going to exhaust. It still hasn’t happened.