Newsletter

Grab a Hammer and See If It Works
    It's taken a long time, but it appears that gateway and endpoint vendors are finally finding out that a fax call can't be handled as a voice call. True, most figured out some time ago that dynamic jitter buffers and G.723.1 didn't work. Now, the link between T.38 and customer satisfaction is becoming clear. And carriers are now deploying hosted enterprise fax based on fax media servers that terminate T.38 sessions. The Hammer FX from Empirix, equipped with Commetrex' exclusive Multi-Modal Terminating Fax (MMTF), is designed to allow them to test their applications.
    Hammer FX not only allows you to test voice-based applications, such as IP PBX, VoIP gateways, and audio conferencing systems. But with MMTF, Hammer FX can inject T.38 fax transactions into the network and monitor for proper results.
    MMTF combines Commetrex' TerminatingT38, which, for years, has been the reference standard in the T.38 Interoperability Test Lab, with Commetrex' fax modems. This allows Hammer FX to send-receive T.38-based faxes and to perform the same functional tests on gateways and endpoints that have yet to add support for T.38.
    Empirix' Hammer Call Analyzer (HCA) also includes TerminatingT38. With HCA, users can analyze and decode T.38 transactions over UDP or TCP with both SIP and H.323 protocols. HCA also provides valuable fax-quality metrics, including transmission times, quantity of T.38 Indicator and Data packets, and HDLC events.
    To learn more about how Empirix is using Commetrex technology to Hammer T.38 sessions, go to http://www.empirix.com or call 1-800-Hammer-IT.
    To learn more about MMTF, contact Cliff Schornak at cschornak@commetrex.com or 770-449-7775 X330

Are You Bidding on Networx? Team
    The US General Services Administration (GSA) has solicited proposals for the "Networx" program (http://www.gsa.gov/networx) that will provide "comprehensive, best-value telecommunications and networking services and technical solutions to all federal agencies. Notice the last phrase: "to all federal agencies." This is a very big procurement that will probably result in billions of dollars in business to many telecom equipment, solutions, and service providers. GSA is looking at this procurement strategically. According to its Website, "Networx will introduce new technology, new industry partners, and new ways to achieve a more efficient and effective government."
    The bid documents are available in two versions: "Enterprise" and "Universal." The specification for each is in Section C. Section C.2.4.5 Internet Facsimile Service (IFS) of each of these specifies a comprehensive, advanced set of fax facilities. We believe that these requirements may be uniquely supported by Commetrex' "Open Telecommunications Framework, A New Architecture for Fax Telephony", which is fully described at http://www.commetrex.com/whitepapers/OTF2.html.
    If you are bidding on Networx, and would like to increase your bid score, Commetrex can offer you a 100% conformant solution. We've also explained how OTF does this in a written response to section C.2.4.5. If you are a qualified bidder, and would like a copy of our response, contact Mike Coffee at 770-449-7775 X310 or mcoffee@commetrex.com.

T.38 Version 0, 1, 2, 3: Should You Care?
    T.38, the ITU recommendation for real-time fax over IP, was first determined in June 1998. Since then, there have been corrections, amendments, and new versions. Hope this orientation helps you understand the differences.
    One of the most interesting had to do with the ASN.1 (Abstract Syntax Notation) used in T.38. ASN.1 is a notational language that formalizes the specification of communications protocols, and reduces the amount of signaling data that must be transmitted relative to text-based protocols. It's similar to a programming language in that the binary output is precisely described by the input. So don't make a mistake. If you do and the mistake makes it through the review process (sometimes they are not obvious) you have a problem. And that's just what happened in the first-what later become known as Version 0-T.38. A comma followed by a return and an ellipsis on the next line is what was omitted.
    Of course the typo was discovered, and, in 2002, Version 2 of T.38 corrected the error. But wait! By that time several companies, including Commetrex, had implemented the ASN.1 specified in the first version. So gateways that implemented the first and "corrected" version of T.38 (V2) were not interoperable, clearly a bad outcome for the correction. So, in July 2003, a correction (Corrigendum in ITU speak) was issued. It recommends that version numbers be a mandatory attribute in T.38 to indicate which ASN.1 syntax is used.
    So the responsible committee decided on version numbers that would allow corresponding gateways to use the same encoding. (If no version number is provided by a gateway, Version 0 is assumed.) So the corrected corrected version became Version 2 along with its Corrigendum.
    Earlier, Version 1 added TCP; later, version 3 added V.34 support.
    The chart below details the versions and the major changes of each:

Ver	Form	Date	Changes
0	T.38	June 98	T.38 w/ASN.1 error
-	Corrigendum	April 99	Noted ASN.1 incompatibilities
1	T.38	Nov 2000	TCP and IAF support
2	T.38	2002	Updated Recomendation changing ASN.1 syntax
-	Corrigendum	July 2003	Made version numbers a mandatory attribute. Tied version num. Negotiated to ASN.1 syntax used.
3	T.38	July 2004	Added V.34 support

Not Your Father's UM System
    Many unified/integrated-messaging vendors define the functional scope of UM to be whatever they provide, typically voice and e-mail. Those that support fax expand the definition accordingly. Now, vendors of messaging systems to the mobile operator must go well beyond voice to support video. Not only is video support required, vendors must support a plethora of terminal devices: PCs, black phones, 2-, 2.5-, and 3-G mobile phones, fax terminals, and PDAs. Moreover, video presents vendors with a whole new set of problems, not the least of which is video transcoding.
    MPEG1, MPEG4, and H.263 are typical of the mix. A message stored in one format may not be supported by the endpoint device retrieving the message; transcoding is required. Those of us with a voice-transcoding background may look at video transcoding as a straightforward exercise. But there's much more to video transcoding than just the large doses of MIPS required.
    While speech codecs encode and decode a stream of speech data, modern video codecs do more than simply encode the video feed; they "describe" video scenes. One way a codec reduces bandwidth is to describe the scene, delineating background and the moving portions, and then only send information on the changes over time for the moving portion of a scene. A talking head, for example, may have a static background with only small changes in facial features over time. Moreover, there are big differences in frame rates, data rates, and resolution between the standards. All of this must be resolved in the transcoding process.
    But, one approach to go from one encoded format to another would be to do it by "brute-force." This involves decoding the stream all the way down to composite video and then re-encode the stream (e.g. RGB, YUV, YcbCr) into the desired encoded format. Since video codecs are not lossless, this technique degrades the image quality. It also requires as many MIPS as the original encode-decode, and we all know about how MIPS-intensive video is.
    A better method is to "map" the scene descriptions from one format to those of the target format without resorting to decoding and re-encoding the motion estimation, preserving both video quality and MIPS. This requires a deep understanding of the source and destination codec standards. It also means you can't mix and match. A voice transcoder can handle all combinations of all codecs as long as every transform has a linear PCM input. But the video transcoding approach described above means each transcoder supports a single input to a single output.
    We will have more to say about video in the future, but in the meantime, if you're interested in video transcoding and would like to talk with a leading industry expert, contact Jian Liu, Director, Signal Processing Technologies, at jliu@commetrex.com.