The Gateway Function
This brings us to the consideration of the interconnection of the IP fax server with the wide area network. You may see the following situations:
- The prospect has a corporate IP network with existing gateways.
- The prospect has no existing gateway function, and wants you to provide it.
- The prospect has a production-fax application and is negotiating a service agreement with an IP service provider.
- The prospect is using SIPconnect for SIP trunking.
It’s possible your customer has installed gateways in each office, and wants you to interconnect with the existing IP network. If that’s the case, you need to find out what gateways are installed. Do they all support T.38, the IP fax-relay protocol? If not, is it a mix of G.711 pass through and T.38? Is it a mix of vendors? Note that the older the gateway, the less chance there is that it will support T.38 and the greater the chance there will be interoperability “issues.”
If there are gateways and terminal adapters without T.38 support, look into the underlying network. If it’s a local LAN (no wide area involved), you’re probably okay, but you’ll need either MMTF or BladeWare with MMTF. It’s pretty easy to find out if you’re going to have problems with G.711 in a site visit with your BladeWare-based system installed on your laptop. It’s best to test by looping back via the PSTN. Send 50 faxes…you’ll know.
If you’re getting fancy and doing IP-based least-cost-routing between offices, be careful about non-T.38 inter-office calls. Does your customer have a service agreement in place for real-time voice service? If not, don’t count on error-free G.711 pass-through faxes (or even if there is one), but T.38 faxes should go through without a problem, even over the public Internet. (We’ve sent a 1000-page fax from Atlanta, Ga. to Melbourne, Australia, without a single error using T.38.) On the other hand, if the customer has, for example, an MPLS VPN with a real-time voice service-level agreement that would apply to all calls to and from your server, you might be able to accommodate non-T.38 fax traffic on your BladeWare-based fax server, handling faxes even from those older non-T.38 endpoints. Again, perform some tests.
Note that the scenarios above expose you to integration and interoperability problems that can eat your profits unless you approach that portion of the sale as a revenue generator. Include a professional-services component.
But there is a way to limit your exposure to the uncertainties of unknown gateway devices. Make the gateway part of your scope of supply. You can do that by qualifying and supplying an off-the-shelf gateway, preferably one with T.38 support. Another approach is to include the gateway as a PCI add-in board. Commetrex offers the MSP-H8 4-8-line analog interface and the MSP-640, with one-to-120 ports (quad E1/T1) on one board as a PSTN-IP gateways.
Some of this is shown in the diagram above. The BladeWare -based fax server, in the upper-left corner, serves the entire organization. (After all, IP renders geographic location somewhat irrelevant.) Office A has no legacy fax terminal, but does have client workstations that utilize the enterprise fax server. Office B has a PC with a resident MSP-H8 serving as a T.38 gateway for terminals “behind” the PC using the H8’s FXO interface while also connecting with the PSTN via a station port on the H8. Office C happens to have a Cisco IAD2400 without T.38 support, but the quality and performance of the IP connection to the fax server is such that G.711 does the job. Office D is also equipped with a local-server gateway. In this example, a fax can be sent in real-time directly between the terminals in offices B, C, and D.