07 Jan Cut the Big Guys Some Slack
Cliff Schornak
In marketing, it’s axiomatic that the market leader enjoys the highest margins, but it doesn’t end there. It extends to giving the large company a ride when it comes to interoperability problems in the field. If there’s a problem, it must be the little guy. Right? In this case, the little guy is Commetrex. And even though we can make a very strong case for being the industry’s interop leader, we still must prove that it’s not our problem if the other vendor is much bigger then we are. Goes with the territory.
When this happens, it means our maximum fax-technology guru, Cliff Schornak, has to spend several hours of his time pouring over logs and capture files to figure out what the big guy has done wrong.
For example, the primary reason for interoperability failures in ECM operation in a T.38 gateway is improper handling of flag insertion and deletion. T.38 does not transfer the HDLC framing used in ECM operation. As a result, flags between frames are removed and must be reinserted at the transmitting (to the local analog terminal) gateway.
In the ITU G3 fax specs, a minimum of one flag must appear between ECM frames, but there is no maximum number of flags. In practice, T.30 designers are free to insert any number of flags, and they do. Some machines change between every pair of frames by factors of 8-10, creating a challenge for the T38 developer since the variability of the flags results in variability in the arrival of T.38 ECM packets. The delay introduced by variable flags in the original signal must be covered by reinsertion of flags in the re-modulated data. If the gateway does not reinsert the correct number of flags, on average, it will either underflow or overflow with data. The large equipment vendors screw this up just as much as the smaller vendors. When one of our customers experienced this, , we had to produce a five-page analysis before our assertion was believed.
Recently, in another customer situation, we encountered a problem that may have been exposed in another vendor’s equipment by BladeWare’s first-to-market T.38 V3 with G.711 V.34 support. Our customer had a problem with faxes sent by a particular fax terminal through the gateway of a large vendor. We extracted the image stream from a Wireshark capture and processed the image data with our stand-alone image-analysis tool, FaxTap for T.38. We were surprised to find that the negotiated image encoding and the actual image data were different. (MH negotiated and MMR actually used.) Now, this can happen if a SIP-T.38 option, “T38FaxTranscodingMMR” is negotiated, but it wasn’t. As a result, BladeWare received no valid lines in the entire image due to the difference between what was negotiated and what was transmitted.
In both of these examples, we notified the vendors involved. We never heard a word back from either. However, the first, which actually involved a major chip vendor that, unfortunately, does not use Commetrex’ T.38, solved their problem, by themselves, in several months. The second vendor hasn’t gotten back to either us or our customer and the problem remains unsolved.
No Comments