RockBochs FaxxBochs Product Overview

One technically challenging issue with VoIP, and one that you are bound to run into sooner or later, is how to deal with the issue of faxing. We have discussed the issues with faxing in previous article and looked at why faxing is such a problem. One of the solutions given was to use a FAX service such as the FaxxBochs solution. But what exactly is the Faxxbochs solution and how does it solve your FAX issues? We first need to look at how the FaxxBochs system works and then we will see how it solves this nagging issues.
The FAX Problem
A FAX machine is basically a scanner that digitizes the page that is to be sent and then a modem-to-modem connection is established between FAX machines and the document is transmitted from one machine to another. Generally, this system works quite well and is usually quite reliable. The real problem is when using Voice over IP. If you are trying to send the modem-to-modem tones over a VoIP connection, any issues with that communication can cause the transmission to fail. This can be slow packet delivery, dropped packets, or jitter on the line. These very common issues just play havoc with FAX communication.
The supposed answer is T.38 which is a defined protocol for FAX transmission over IP. While, in theory, T.38 will eventually solve the problems we currently have, it is not deployed in enough places yet for it to have much of an impact. Some people think that just connecting a FAX machine to an ATA (analog telephone adapter) and connecting it to your IP PBx will solve the problem if the ATA is doing the T.38 conversion. Well sure, it might, but what if the remote FAX machine isn’t T.38 compatible (like well over 99.99% of existing FAX machines today)? What happens is the ATA is actually out of the loop and you are sending modem-to-modem tones over IP which puts us right back to square one.
On a LAN or high bandwidth/low latency connection, T.38 is pretty reliable. It’s sending T.38 over the last mile that introduces problems, as most internet connections do not employ QoS. Even if they do, there is no guarantee the QoS is carried throughout all the routes. Companies have developed workarounds to UDP jitter (a large problem with T.38) such as T.38 over TCP or HTTPS; however, even these solutions are not reliable over high latency connections where TCP would run into endless retransmit loops. Additionally, UDP jitter is only part of the problem.
Another large problem with T.38 is the fact it generally uses at least four T.30 processors throughout the fax path as follows:
Fax machine <–> T.38 gateway <– carrier –> T.38 gateway <–> Fax machine.
T.30 T.30 T.30 T.30
Each of the T.30 processors may come from multiple manufacturers who implement the ambiguous specification just a little bit differently, causing issues. FaxxBochs is able to get around this problem by controlling at least two of the T.30 processors, eliminating incompatibilities.
Lastly, along with T.30, T.38 itself is an ambiguous specification. This results in incompatibility problems between different manufacturer T.38 gateways and CPE devices.
A better solution is one that makes sure there is never an end-to-end connection and can act like a middle-man to ensure FAX transmission and reception.
The FaxxBochs Solution
FaxxBochs eliminates this issue by removing T.38 entirely between the FaxxBochs CPE and the FaxxBochs datacenter. As I explain in the video below, the FaxxBochs solution takes a very different approach. Your existing FAX machine connects to an FXS port on the FaxxBochs device. When you go to send a FAX, the FaxxBochs provides dialtone to the FAX machine and accepts the FAX as if your FAX machine was directly connected to another FAX machine. Once the FaxxBochs unit has the FAX, it encodes it and creates an encrypted connection to the FaxxBochs data center. Once the FAX is at the data center, it is archived into your web interface and then the system dials out to the remote FAX machine and delivers the FAX. This middle-man process ensures delivery since the FAX transmission is never done over VoIP.
While there is the cost of the FaxxBochs server and a monthly fee, for many people there will actually be a cost savings over maintaining a PSTN line just for the FAX machine. This savings is due to being able to place and receive unlimited FAXes and not having long distance fees.
In our testing at multiple locations, the FaxxBochs solution has performed perfectly every time and we are confident that it is the best solution for solving the FAX problem available today.
For pricing, please visit http://www.888voipstore.com/rockbochs/


If fax is made via a relay trought the faxbosch, how you get a real report of incoming/outgoing faxes?
what about if a client send you a fax, his machines received and OK, but your faxbosch or internet conection is down?
he will think have send you a fax and that's not real.
Eliminate the real time protocol inherent to fax to fax system is a problem for much more users.
my two cents
The only way to ensure reliable delivery is to eliminate the device to device connection as explained in the article. The sending fax machine will always get an Ok or Fax Sent message which is not exactly accurate since it has only been received by the Faxxbochs. This isn't really any different than using any FAX server package on a network. You send it and hope it goes out. With Faxxcbochs, you can check the web portal to ensure that the FAX was received there. If your connection is down, FAX's will catch up when the connection is reestablished.
I believe the Fax may possibly be queued in the FaxBochs servers, i'll have to check on this though. If that is the case, then even if your internet is down you still would receive the fax when it came back up.
I have actually tested this. I tried sending a fax while the ethernet connection was unplugged from the FaxxBochs unit. After it was received from the box, I even powered the box completely down. I then plugged it back in, powered it up, and the stored faxes went out properly.
As for failure notifications from the remote side, there is an upcoming feature that will print out a failure message to your fax machine if the remote side failed for some reason.