The Commetrex Outlook | October 2015

Does Your T.38 Stack Measure Up?

So, what distinguishes one T.38 stack from another? If they both conform to the ITU T.38 recommendation and are interoperable, shouldn’t they be the same…that is, indistinguishable? Yes, there’s price, compute-resource requirements, and ease of integration if you’re evaluating commercial stacks, but is there more? The answer is an emphatic yes.

You see, the T.38 spec doesn’t tell you how to make your T.38 resilient, and that’s the key to in-the-field performance. Of course, much of that resilience comes from effective integration with the analog modems if the stack is being used in a PSTN-IP gateway, rather than a fax server. For example, does the integration of the stack and the modems effectively handle line echoes? Your T.38 stack can be completely interoperable with other vendor’s T.38, but fail to work with certain fax terminals.

But the big differences show up when the T.38 stack is designed by someone who has previously designed a T.30 protocol engine and nursed it through at least a few years of field experience. That’s the only way all the tricks of the trade can be marshalled to design that “resilience” into the stack. It’s called “spoofing”. If it’s done correctly it can add several seconds to the round-trip-delay tolerance of the stack without creating fax-terminal-specific interop problems.

Here’s a few things to check on to see if your stack measures up:

• Does your stack support T.38 version 3 with V.34?
• Does it maintain the outgoing packet stream when idle to prevent half-duplex disconnects?
• Does it retransmit terminal frames, keeping poorly written relays from waiting forever if a terminal signal is lost?
• Does it use a Class 2-style interface with the modems, introducing hundreds of milliseconds of additional delay?
• Does it effectively resync in the presence of multiple lost packets?
• Does it effectively handle late T.38 reINVITEs?

We would be pleased to discuss your fax-technology requirements with you. Just give us a call at 770-449-7775 press 1 or email sales@commetrex.com.

FoIP Options For Service Providers

FoIP customer satisfaction, reliability, and support costs are problems yet to be solved by the majority of service providers and carriers. It’s probably safe to say that virtually every operating ITSP has voice all figured out–makes the sales process tough if you can’t offer voice. But many ITSPs avoid FoIP altogether, leaving the revenue with the incumbent by advising their customers to “Keep your POTS for fax.”

In the US and several countries around the world, there are hundreds-possibly thousands-of Internet telephony service providers (ITSPs) that accept the subscriber’s existing IP connection and route calls-regardless of type-to one of multiple carrier partners, as shown below.

Usually, the carrier will route the call without regard to the media type. But laissez-faire routing often results in low FoIP success rates. Often (e.g. 5%) all those tandem connections result in late T.38 reINVITEs, which is an immediate FoIP failure. And the more carriers that are involved, the higher the chance that one of them will mishandle a fax call with less-than-optimum network-element configuration or lethargic call set up. A proactive approach to FoIP routing is called for.

There are some operators that deliver reliable FoIP to the end user by avoiding carrier routing of a(n) FoIP call. The diagram below shows one example of this approach, which is used, for example, by Cbeyond/Birch, USA Digital, and, perhaps, by BabyTel.

Here, the call is routed to the ITSP’s gateway and then directly to the incumbent’s PSTN network, avoiding third-party routing of the FoIP call. This usually works.

Here’s another way to avoid third-party routing of FoIP calls: eliminate FoIP altogether. In the diagram below, FAXXBOCHSplaces a server appliance on the customer’s premises. The fax is terminated by the on-premises server and sent to a hosted server which then sends the fax using PSTN fax boards. There is no FoIP routing since there is no FoIP.

This works. It’s not really an end-to-end fax. It’s actually two faxes-one between the on-premises terminal and server, and one between the hosted PSTN server and the destination terminal. But for many users, it matters not.

FaxBack‘s solution to the FoIP problem is similar.  Here, a special ATA is substituted for the on-premises server.  Instead of relaying the fax in real time using G.711 pass through or T.38, the device serves as the T.30 correspondent of the fax terminal, receiving incremental strips of the image and sending them onward to the hosted FaxBack server using HTTPS.  The server then buffers these image elements and forwards them on to the destination terminal as a regular fax.

Again, this works, but with the same provisos of the FAXBOCHS solution.  The primary difference is that the entire fax need not be received prior to its being relayed, so it is closer to real time.

But what about real-time FoIP?  Well, there is a solution there, too.  It’s the patented Smart FoIP® from Commetrex and it’s available inNetGen Communication’s Smart ATA®.

T.38 ReInvites…What To Do?

It is well known by those concerned with optimizing FoIP in carrier networks that once the two gateways have successfully selected either T.38 or G.711 pass-through, chances are good that the image will be transferred.  Yes, there can be modem problems between a gateway and endpoint.  Yes, there can be interop problems.  But most FoIP problems occur prior to the image-transfer phase of the fax call.  Let’s call it the SIP phase, which is followed by the T.30 phase of the call.

Some of the factors affecting the success of the SIP phase are

• Is everyone on the same page regarding IP and port addresses?
• What about the service provider, do they require a calling terminal reINVITE?
• Is a T.38-only reINVITE allowed?
• Is a T.38 reINVITE required?
• Should a T.38 reINVITE be sent?
• Should a T.38 reINVITE be accepted

We have recently added Smart FoIP to BladeWare and we’re thinking about renaming it Brilliant FoIP since it does so much more than Smart FoIP, which makes sure that BladeWare does not accept a T.38 reINVITE that it ought to reject due to its late arrival.  Smart FoIP on BladeWare incorporates our 13 years of experience in making FoIP work in carrier networks to give you unprecedented control over BladWare’s behavior.