The Slow-Network-Signaling Problem Revealed!

05 Mar The Slow-Network-Signaling Problem Revealed!

All T.38 implementations are the same if they conform to the T.38 recommendation, right? Wrong! You could easily have a widely interoperable T.38 and have an intolerably low transaction success rate. Problem is, it is difficult to verify interoperability, and it’s even more difficult to determine performance. And to make matters worse, the parameters of T.38 performance aren’t even widely known.

As explained in the SIP Forum’s FoIP Interop Task Group’s problem statement (see www.sipforum.org):

T.38 implementations vary as to features, interoperability, and performance. Features are usually quite obvious: Does the implementation support T.38 V3? ECM? Both UDPTL and TCP? Determining interoperability is more difficult, but can be readily done with T.38-specific test tools and time-in-market of the T.38 implementation. But by far the most difficult characteristic to determine is performance.

The TG has noted that few equipment vendors and even fewer enterprises and service providers understand the differences between interoperability and performance, and, if they did, doubt they could adequately test performance with the tools available today. The TG has indentified three metrics of T.38 relay performance:

1. The delay tolerance of the relay. Some handle a fraction of a second; some up to five seconds. Packet-delay tolerance is the relay’s ability to keep the two T.30 end-point terminals engaged in the transaction in spite of packet delays. T.38 does not give any guidance on how to improve delay tolerance, but, as we know, it is improved through so-called spoofing techniques implemented by skilled T.38 relay developers. Better relays can handle up to five seconds of round-trip delay in the IP path.
2. The Task Group identified multi-TDM-hop delays, which is exacerbated by high gateway latencies, as a problem. Part of the delay is the result of requirements of the T.38 recommendation. The requirement to suppress HDLC framing and CRC octets forces a delay of three HDLC payload octets (80ms) into the relay. To this you add IP transmit data buffering of, say, 40ms and PCM buffering. The PCM jitter buffer should be deep enough to accommodate the expected network delay, 160ms being a typical minimum. Performance can be affected by things such as whether the jitter buffer is dynamic, for example by emitting packets immediately if there are no errors.
3. A relay’s ability to handle the situation that occurs when packet loss exceeds the redundancy or FEC settings is also a dimension of performance, not interop. How does the relay handle the modem signal when lost packets cannot be recovered? The high-speed modem of the receiving fax terminal will see the error, possibly producing a bad line or lines, depending on the mode. But how does the relay handle the control frames that cannot be recovered in time? What does the relay do when the V.21-preamble signal is missing? What about a missing V.21 octet? T.38 doesn’t say, but the answers will determine whether the session succeeds or fails. This has to do with relay performance, not interoperability

I couldn’t have said it better myself.

Not mentioned by the FoIP Task Group is the effect on performance of how a gateway handles late-arriving T.38 re-invites, which is a result of signaling delays within the carrier network. Commetrex has determined that if an on-ramp gateway (the calling end) blindly accepts a T.38 re-invite from its off-ramp peer, the on-ramp gateway can actually cause a session, which would have otherwise succeeded, to immediately fail.

Commetrex to the rescue! Commetrex’ licensed fax-relay software includes patent-applied-for technology that puts intelligence into whether to accept a T.38 re-invite, eliminating this as a cause of failed sessions, boosting transaction success rate by, typically, 10%.

On one large-footprint network we tested, fully 10-percent of the T.38 re-invites took over five seconds to arrive, with most of those resulting in transaction failures, which averaged over 8 seconds. Applying our new technology took care of the problem, boosting an IP-based fax-broadcast server’s transaction success rate to equal that of a multi-line intelligent ISDN fax board.

Of course, refusing a T.38 re-invite means continuing the session in what is called “G.711 pass-through mode,” so you’d better have a server that supports both T.38 and G.711 pass through. Of course, gateways and ATAs support both, and they are plagued by this problem, unless, of course, they have Commetrex technology inside.

And if you’re thinking that G.711 won’t work, you should tune in for next week’s blog post to learn about how Commetrex fax-technology innovation has solved that problem, as well.

Bottom line: Experience matters … performance matters. FoIP is finally here!