Mike's Musings...

Smart ATA: It's Just Amazing

2012-02-09T10:41:00.000-05:00

We were in Miami Beach last week at ITEXPO. Great duty. The weather let us know why folks go there in February. It was perfect. And so was the show.

Commetrex was a major participant with a booth focusing on our (actually NetGen Communications') Smart ATA. We also had three speaking assignments. And lookout for our video interview on www.tmcnet.com.

And a little comment on Smart ATA's sales proposition. If you know me, you know I've been around awhile. I moved from engineering to marketing over 25 years ago, so I have an informed perspective. And I can say this: I have never marketed a product with a sales proposition that is received with the enthusiasm that Smart ATA's proposition is received. It's just amazing.

Check it out at www.netgencommunications.com.

What does great OEM developer support look like?

2011-11-10T13:51:00.001-05:00

What does great OEM developer support look like? Here’s but a small sample. It’s a response by our support guy to a question from a T.38 relay licensee.

Commetrex Support: The reason there are no image data in the outgoing PCM is that the recordings are not accurately clocked. The sampling frequency is too fast. For example, in the ANSam, the phase reversals should be exactly 3600 samples apart, but they aren’t. The V.21 receiver can track the signal because the symbols are so big (26.666 samples/symbol). However, the high-speed image modems can only track about one-symbol-per-second drift. That's about +/-3 samples per second for 9600.

So V.21 gets decoded but the high-speed signals are not.

The Rodney Dangerfield of Technologies?

2011-11-03T17:02:00.003-04:00

Fax just don’t get no respect! Every business uses fax, but, until recently, making FoIP work has been, at best, an afterthought by our industry. Item: wideband voice, a relatively new technology, is considered a major driver of ENUM, which allows pure-IP routing for HD (or wideband) voice. But there is only now strong evidence, after one year of testing by the SIP and i3 Forums, that pure-IP routing will be required for reliable FoIP over international routes. In both cases, analog TDM call segments muck up the works, but only HD voice is mentioned as a driver of ENUM in telecom forums.

I guess that, even though fax is a pervasive medium in business, it’s just not sexy; HD voice is sexy, but it’s barely deployed. But at Commetrex we are working to turn this around. We realize that unless and until the industry deploys reliable international FoIP, telephony’s global transition to IP cannot and will not be complete.

There are those that say that if we drag it out long enough, fax, a 161-year-old commercial technology, will go away. Don’t hold your breath. Others are working to promulgate alternative proprietary technologies, but the international carriers aren’t going along. They are investing in finding the answers, both interim and otherwise.

The interim answer that has been advanced is for on-ramp (calling) gateways to insert “user=fax” in the initial SIP Invite, thereby alerting the carrier’s routing software to route the call over routes tested to be fax-friendly…no TDM segments. The longer-term solution is to move away from SS-7 to ENUM, a technology that joins E.164 telephone numbers to the Internets Domain Name System (DNS), which gives the carrier’s routing software even more information for “intelligent routing.”

So what do you think?

ITEXPO West 2011

2011-09-19T16:42:00.001-04:00

Just returned from ITEXPO. It was in blazing-hot Austin, TX, which is a very cool town. And it was very cool for Commetrex and NetGen Communications, our sister company, which is producing and marketing Smart ATA, which we announced at the show. It also turned out to be way cool for the ITSPs who stopped at our booth when they learned about Smart ATA, and what it could do for their success with FoIP.

Smart ATA truly redefines the state of the art in ATAs. If you know Commetrex, you know we wouldn’t bother to develop and market just another ATA, but one that solves big problems for users of FoIP…and it does. Smart ATA is a full-function voice-fax ATA, but in FoIP, it does what no other ATA does: it solves the late-T.38 re-Invite problem, and it solves the G.711 clock-sync problem. This means an improvement of transaction success rate of 5-10%. And, oh yes, it is the industry’s first and only ATA with T.38 version 3 and V.34.

ITSPs that support FoIP know how problematic it is. One thing we learned at the show, it doesn’t matter which ATA they use, they have problems that seemed to bring several that stopped at our booth nearly to tears. Once they learned what we had accomplished, those tears turned to tears of joy. Every ITSP was ready for a trial.

So, the response to Smart ATA was overwhelming.

The Smart ATA Story: Solving Three Big FoIP Problems for the Industry

2011-08-25T15:39:00.003-04:00

If you read our newsletters, you may remember that Commetrex has developed a new FoIP technology, Smart FoIP, which, among other things, improves the success of FoIP session establishment by up to 10% in SIP networks. Now, instead of talking about technology, we’re talking about a product that uses the technology to solve major problems for the industry.

We’ve exhibited at many industry conferences, most notably at the ITEXPOs produced by TMC, and we’ve been frustrated because we’ve not had the Smart FoIP-based products IP service providers have been asking for. These are the guys that tell their business subscribers to keep their POTS lines for fax. Many have tried FoIP, but their customers are frustrated by low connect rates, particularly for outbound calls. Well, now we have what they need—Smart ATA--and we are formally announcing it at ITEXPO West 2011.

Smart ATA is the industry’s first ATA to feature Smart FoIP to solve the late T.38 re-Invite problem. But Smart ATA doesn’t just solve one big problem for the industry; it solves three. Smart ATA is also the industry’s first ATA with T.38 V3 with V.34. And it also eliminates PCM clock-sync problems in G.711 mode, as explained in the following stories. So, Smart ATA solves three big problems that have long perplexed the industry:

SIP session establishment failures for outbound calls,
Finally! V.34 in an ATA,
Elimination of G.711 failures due to lack of G.711 PCM-clock synchronization.

We have designed, developed, and are marketing Smart ATA with New Rock Technologies (Shanghai), our long-time partner, which has used Commetrex’ media technologies in their medium-density gateways for the last five years. So, when they told us they were re-purposing their gateway software for an ATA, we suggested that we work together to produce not just another ATAA, but the ATA that the industry was demanding … one that finally “makes FoIP work”, and adds V.34.

ITEXPO West 2011 will be held in Austin, Texas, September 13-15. So be sure to visit booth 722 to get the full Smart ATA story. Not going to the show? Then send us an email at sales@commetrex.com for more info on Smart ATA now!

FoIP Needs ENUM!

2011-07-05T09:45:00.003-04:00

Two years ago we did some serious outbound testing with the cooperation of Copia International, one of our enterprise-fax server OEMs. Copia’s CopiaFacts is a full-function server for the enterprise, but it has a bunch of features that the mission-critical fax-broadcast guys find to be really helpful. So we were able to gather some very beneficial data as Copia performs evals for broadcast customers. Two years ago, Smart FoIP fell out of the data. Now, we’re doing it again, but this time we’re doing it as part of our work with the SIP Forum FoIP Task Group.

We’ve reported on several occasions how we installed CopiaFacts servers, based, of course, on BladeWare, in 13 global carrier locations in Europe, Asia, Australia, and North America. The results were sobering: Taking all failures into account, we only saw a nominal 50-percent completion rate. Whoa! What’s going on here? We knew carrier-based FoIP was “problematic”, but this is beyond that.

Yes, we fixed some BladeWare problems all this testing exposed, and yes, there were plenty of configuration problems in the on-ramp network, but the big problem appears to be trying to use SS-7, a call-routing system devised for the PSTN, to route calls that really needed IP-specific routing. That’s because the SS-7 network will throw an FoIP call that was transiting networks in T.38 mode into a TDM (PSTN) network without a second thought. Although this can work, nearly half the time is doesn’t. So, what’s the answer? Commetrex’ view is that the carriers need to move to ENUM as soon as possible.

Our testing over international routes has clearly shown that FoIP needs intelligent routing. This means each carrier’s routing algorithms must select a path that is not only IP, but supports T.38. ENUM is the first step to take as it will identify the destination IP network. Then, it’s up to the carriers involved to route the call over interconnects that have been proven to effectively support FoIP.

FoIP Presentation at ITEXPO East 2011

2011-02-07T14:31:00.009-05:00

Here’s a summary of my talk at ITEXPO given on 2/3/11.

“Telefacsimile” went commercial 150 years ago. Seems like yesterday, doesn’t it? G3 fax, made possible by the microprocessor, is now 31. And T.38 turned 12 last October…a mere kid. So, for those of you thinking fax will soon go away, don’t hold your breath. After 150 years, it’s kinda established in the world of business and telephony. And now, it’s just beginning to work its way onto IP-carrier networks. Here’s the deal: the incumbent carriers know the global telecom network must soon transition to an all-IP transport, and that transition cannot complete unless and until real-time G3 and Super-G3 fax can be reliably transported by their IP networks.

For 13 years, T.38, the ITU standard for real-time IP fax, has been incubating in enterprise networks. It’s been used for intra-enterprise gateway connections, ATA-to-gateway routes, and to allow T.38-capable fax servers to connect with the PSTN. But the boundary of the IP T.38-based fax was the edge of the enterprise network; it didn’t venture out into the wide area. T.38 Interoperability was accelerated by Commetrex’ T.38 Interop Test Lab in 2002-2004. Then, there were numerous SIPit events sponsored by the SIP Forum. And if an interop issue did arise in the enterprise network, the customer could crack the whip and get the two vendors involved to work things out. We call this T.38 Phase I.

But here we are in Phase II. SIP trunking and direct SIP peering by mission-critical fax servers have pushed the boundaries of SIP and T.38 beyond the enterprise network and into the service-provider domain and from there to the IP carrier. Goodbye comfortable Phase I.

Some early adopters of T.38 in ITSP applications, after being frustrated by the lower-than-PSTN fax-transaction success rates, devised proprietary solutions to the problem. Early on, Cisco offered gateways with built-in fax send-receive. Clients and servers within the IP network would use non-real-time carriage, such as T.37, between the gateway and the user. Others offer ATAs that do essentially the same thing by terminating the premises fax terminal’s fax in the ATA, and e-mailing it to a hosted server. Still others have proprietary ATAs that use HTML-like protocols to convey the fax in near real time to hosted servers capable of handling the proprietary protocol. But the need for these stop-gap proprietary techniques will be obviated by a solution to the tandem-carrier signaling problems now being encountered in many Phase II deployments. This is the current goal of the SIP Forum’s FoIP Task Group (TG).

The TG, formed in September 2008 with a goal of resolving the Phase II and lingering Phase I problems, has produced proposals to the ITU, which have been accepted, that improve T.38, and have been included in the 2010 update to the standard. We have also developed the procedures necessary to move to effective T.38 V3 with V.34 support. Now, the challenge is to solve the problems encountered when several carriers are involved on a fax call and the session attempts to switch from G.711 to T.38. But, the equipment vendors, which make up the bulk of the TG membership, can’t solve the problems without the complete cooperation of the carriers; the carriers can’t solve the problems without the equipment vendors.

In 2008, 36 carriers, operating in 80 countries serving over 1.5-billion subscribers, formed the i3 Forum. The goal of the i3 Forum is to develop collaborative recommendations for the coming industry-wide transition of voice and related services to IP. According to the i3 Website: “The forum's effort to expedite global IP-based voice implementation will enhance worldwide communications by supporting widespread access to innovative high-quality IP-based services and applications.”

At a joint I3 and SIP Forum TG meeting in Warsaw held in June 2010, the two organizations decided to work together to solve the problem. The critical agreement was to conduct joint testing to measure the extent of the problems, their cause, and, ultimately, their solution.

Commetrex agreed to provide its BladeWare telephony platform with both T.38 and G.711 pass-through support. Copia International, a fax-server OEM that bases its product on BladeWare, offered to provide its CopiaFacts server and to assist the i3 carriers in installing it to access their IP networks. Today, that has been accomplished at 14 different carrier locations. And testing has begun.

We are working to complete the initial round of tests in Q1, analysis in Q2, recommendations in Q3, and retest in Q4.

Stay tuned for more updates in the coming days.

Cut the Big Guys Some Slack

2011-01-07T13:50:00.005-05:00

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.

Smart FoIP in Gateways

2010-11-08T10:08:00.005-05:00

The wide-scale deployment of V.34 fax terminals is making the design of FoIP-capable IP-PSTN gateways much more of a challenge since V.34 terminals employ a completely different start-up sequence than non-V.34 machines. Moreover, since gateways typically begin calls in G.711 pass-through mode (rather than T.38), V.34-capable endpoints can actually “hear each other” well in advance of the resolution of the SIP signaling resolving the session’s setup. This means the gateways must take an “activist” role to ensure that T.38 is “given a chance” prior to the endpoints going on their merry way, leaving the gateways behind.

Because this technology isn’t widely understood, it’s probably safe to say that there are no T.38 V3 gateways with V.34 support that can actually establish a T.38-based V.34 session outside the lab.

If you’re a gateway developer, you probably know that a called V.34 terminal has a completely different answer tone than a V.17 terminal, and, to make matters worse, it’s the same tone as a V.34/V.90 data modem.And if the calling terminal hears that tone and its response reaches the called terminal prior to T.38 being established, it’s too late for the two gateways to do anything about it. The endpoint machines are off to the races in G.711 mode. If the SIP peers then attempt to switch to T.38, the session will fail. The only hope, then, is for the session to continue in G.711 pass-through mode, where it at least has a fighting chance.

Commetrex’ "Smart FoIP" gives it much more than a fighting chance. With Smart FoIP’s patent-pending technology, even G.711 sessions are reliable. (Yes, you read that correctly.)

So, gateway developers, you need not despair, because Commetrex’ Smart FoIP is here. Smart FoIP handles the four fax-session configurations you need to be concerned about:

- Called GW, V34 fax supported

- Called GW, V34 fax not supported

- Calling GW, V34 fax supported

- Calling GW, V34 fax not supported

And Smart FoIP encapsulates the media technologies you need to do it: V.8 modems, ANSam generation-detection, and call classification…all in one handy module.

There’s only one company with the mantra: “We make FoIP work!”

So, if you intend to do anything about moving to V.34 fax support in your gateway, there’s only one place to go if you want it to actually work.

T.38’s not the Problem!

2010-09-16T16:08:00.003-04:00

Whenever I hear someone tell me that T.38 isn’t capable of bringing reliable real-time fax to IP-carrier networks, I resist the temptation to roll my eyes. Instead, with missionary zeal, I explain that if T.38 provides reliable fax in enterprise IP networks, and, if real-time fax is problematic in carrier networks, it’s not because there is a problem with T.38, there’s a problem with the way it’s being used…possibly abused. You might argue that it doesn’t matter why, either it does the job or it doesn’t. Good point. Read on.

I sometimes relate that once, when we operated the very popular T.38 Interop Lab (2002-2004), we sent an error-free 1,000-page fax over the open Internet from our offices in the US to a testing partner in Australia. Open Internet! No errors! How could that be, you say. Easy, I say. T.38 works, but you need to know how to use it. Here, there was no signaling involved. It was a nailed-up connection. What about packet loss? We used a redundancy level of 3 for both negotiation and image. What about clock drift? 1000 pages could take 10 hours, enough time for clock drift to overrun or under run any reasonable-sized jitter buffer, but our T.38 eliminates clock drift as a problem.

Then, I explain that it’s not T.38 that’s causing the problems, it’s configuration and signaling. For example, in an effort to save on bandwidth, the carriers I’ve dealt with default their redundancy depth to zero—no redundancy. Most users don’t call them on this since they just don’t know about it.

Then there’s slow network signaling. Ten percent of the calls in one network we tested took over six seconds for the SIP re-Invite to T.38 to arrive, averaging over 8 seconds. For many of those calls, that’s plenty of time for the G.711 pass-through session to pass the point of no return, so the call will fail if the G.711 stream suddenly vanishes.

At Commetrex, “We Make FoIP Work!” So, who better than Commetrex to work closely with several carriers to solve this problem, and make FoIP work without qualification.

The Skinny on FoIP for TMCnet.com

2010-09-09T10:10:00.001-04:00

I was recently interviewed by Erik Linask, Group Editorial Director at TMCnet.com (Technology Marketing Corporation). TMC is “The World’s Largest Communications and Technology Community”, so we are particularly pleased by the interview, which is now featured on their website, www.tmcnet.com. (We’ve also highlighted the interview on our homepage at www.commetrex.com.) You should find the interview interesting if you are following the move of the global telecom infrastructure to IP, and how it is going to support fax, which, of course, it must. I also shared with Erik why we believe that, for the enterprise-fax OEM, Commetrex offers the industry’s broadest product line.

Take a look and tell me what you think.

What Gives with V.34 Fax?

2010-08-25T11:40:00.004-04:00

Currently, there are not many V.34-capable gateways available, and only one V.34-capable FoIP fax server. This is so despite the fact that over half of the machines installed in the last five years support V.34. So, what gives?

Well, for one thing (and trust us when we say this) it’s difficult to implement. It’s still heavily encumbered with patents. And another is that, compared with V.17, it’s a resource hog, both MIPS and RAM, which can give an embedded-system designer pause. Then, there’s the added complexity of handling V.34 in SIP signaling. Lots of moving parts.

But we’ve stolen a march on our competitors and now done it all. BladeWare is shipping with T.38 version 3 with V.34, G.711 pass-through IP fax with V.34, and V.34 in PSTN applications on all of the Sangoma telephony boards. But with some HMP servers only supporting 60 or 120 ports of T.38, which is easy on the MIPS, what kind of capacity can you get with V.34 on an HMP system? Well, the answer is plenty with BladeWare.

Over the years we’ve been able to do a pretty good job of optimizing our ANSI-C-coded fax modems, so our V.34 got off to a good start. Then, Moore’s law and multi-core processors to the rescue! It turns out that our modems just love multi-core architectures. Both Linux and Windows do a fine job of putting the modems on one core, where they appear to fit into cache and just rip. The other core in a dual-core machine takes care of the application and file I/O, which is an important aspect of any fax application.

You want performance? Well, how about this! On a dual-core 3-GHz PC we can run 60 V.34 transmits sending to 60 V.34 receive channels and only use 30% of the computer’s MIPS. And, with the Sangoma digital boards supporting up to 8 spans in one PCI or PCI Express slot, who needs expensive fax boards.

So, if you’re looking for V.34, you know where to get it!

What's the Big Deal with FoIP Interop Anyway?

2010-07-29T17:00:00.004-04:00

I recently shared with you that the industry’s deployment of FoIP is proceeding in phases. Phase I, which extended from the early days of T.38 in the fall of 1998 to just a few years ago, was characterized by the need for interoperability between intra-enterprise network elements, such as between an ATA and a gateway. But those problems are trivial in comparison to what we are dealing with today. Let’s call it Phase II.

At industry events I hear a procession of VoIP Service Providers complain about how problematic their FoIP deployments are. These problems are relatively new and the result of enterprises extending the reach of their IP networks with SIP trunking and by connecting directly with IP carriers. And--no surprise--they are confronted with some major challenges.

Today’s real battles go way beyond simple interop and equipment configuration problems of Phase I. Try sending faxes to 1000 different machines from an ATA or an IP-based fax server. What’s your success rate? Sure, you can use equipment from suppliers that have set up an interop lab and cataloged the results. But, that just doesn't cut it. You need real hands-on experience to solve these problems. That’s because these problems aren’t interop problems, at least not in the usual sense.

So, who’s doing something about it? You guessed it, we are! As we speak, Commetrex is working in the trenches with carriers to identify and correct the problems within their networks that are keeping FoIP from achieving the transaction success rates of PSTN fax. I'll have lots more to say about this in the days to come, so follow this blog or check back often.

So, here’s the deal: If IP is going to replace TDM, our industry will have to solve these problems, and Commetrex is right out front, leading the way.

An Industry First: Commetrex Enhances BladeWare with G.711 Pass-Through Support for V.34

2010-06-14T13:33:00.002-04:00

Commetrex, inventor of T.38 fax termination now used in media servers everywhere, continues its record of innovation with the announcement of its industry-first support for V.34 G.711 pass-through in its BladeWare HMP telephony platform. This means that BladeWare users can elect to complete IP fax calls using V.34, rather than forcing a fallback to V.17 speeds, which take twice as long to transmit a page. This is important since there are few T.38 Version 3 V.34-capable gateways on the market, and none deployed in carrier networks. Indeed, many VoIP service providers have yet to support T.38 in any version. In these situations, BladeWare delivers faxes with one-half the connection time of any server on the market.

For example, here at Commetrex we use Cbeyond, an all-IP managed-services provider, for all of our communications over a 3-Mbit clear-channel pipe to Cbeyond’s private metro network. But they don’t support T.38. Instead, all faxes are handled with G.711 pass-through, including V.34, and they are virtually error-free. A BladeWare-based server is setup to use Cbeyond’s SIP trunking. It’s all software, all IP, and with V.34 support.

“But how can that be?” you say. “My vendor tells me that G.711 pass-through fax just doesn’t work.” Well, your vendor has a biased perspective since he can’t do it, and doesn’t want you to ask for it, knowing that only Commetrex supports V.34. Yes, there are networks where G.711 pass-through does not perform well, but there are many where it does. The example above is one. And how about when an IP PBX without T.38 support is being used as the gateway between the PSTN and the fax server? There, the IP connection is over a high-performance LAN. No packet loss need be dealt with, and Commetrex’ exclusive PCM-clock management software means even long G.711 faxes come through error-free.

Need a fax-resource platform to support IP and PSTN? Commetrex’ BladeWare provides the industry’s highest performance, richest feature set, highest scalability, and all at one-third the price. Contact us directly here.

Appliances…Appliances!

2010-05-03T11:45:00.002-04:00

What’s going on? Suddenly, is seems that nearly all of our enterprise-fax OEMs are using BladeWare as the platform for a new fax-server appliance. Makes a lot of sense. An “appliance” is usually intended to be a low-capacity and low–complexity and, therefore, a low-cost system that improves the productivity of the users. Since nearly all of these OEMs have traditionally targeted the large enterprise, these small boxes are critical to their plans to broaden their addressable market to include the small-medium enterprise (SME), which has simply been inaccessible due to their multi-line fax-board costs. But the times…they are a’changin’.

Our OEMs know that for every Fortune 1000 company there are 1,000 smaller companies that have in-place IT infrastructure and still have no computer-based fax. And it is those companies that could benefit from computer-based fax the most. The small business usually has few administrative employees. So, for example, the CEO sends his own fax and checks the fax machine himself to see if that important PO or contract has arrived. Send a fax? First print the document, then compose and print a cover page. Go to the printer, pick up the two printouts, go to the fax machine, key in the destination number. No fax answer; it’s the recipient’s voice number. Back to the office to look up the correct number, and so on. Fifteen minutes wasted.

The ability of a computer-based fax server to turn this time sink into a one-minute exercise is well documented. No printouts are required. (Save a tree!) Typically, no cover page needs to be filled in manually since the recipient is already in the server’s phone book. Inbound faxes are announced with a pop-up, end up in the recipient’s inbox, and don’t need to be printed.

Okay, the opportunity is there, how do we access it? Certainly, Internet-based fax services is one way. This is typically used in addition to the trusty ol’ standard fax machine. Another is for the fax-server function to “hitch a ride” on an IP PBX sale and installation, with the PBX deal effectively subsuming the sales and installation costs of the fax server. Another would be for the user to order the software on-line and self install the server. And, since IP makes physical location less-and-less important, hosted fax services, where all that must be done is to configure the users, is an increasingly attractive alternative. And, of course, there is the “appliance.”

So, what makes an appliance an appliance? Well, most people equate appliance with low acquisition cost and easy installation. But, you may ask, “How do I configure a low-cost system when I’m paying over $400 for a single fax send-receive channel.” Ahem! Consider using a vendor that offers superior function, performance, scalability, and configurability, but at one-third the cost. That’s how.

Develop one adapter/connector for BladeWare and you’re done. The same adapter is good for PSTN or IP connectivity and on the same system at the same time and with the same application. Oh, yes, when you want to use the same little box for your PSTN-capable appliance as you used for the all-software FoIP version, BladeWare’s MSP boards require only 2U rack space for both PCI and PCI Express. And, since BladeWare scales to over 120 ports on one server, and is seamlessly scalable well beyond that by adding more processor blades (that’s where we got the name), it’s just as good for the large enterprise as for the SME.

Is that cool, or what?

Wait! There’s more: We’ve teamed with Intel and Win Enterprises to offer a proof-of-concept (POC) system based on what Intel calls “Delray Beach” and BladeWare with optional PSTN boards pre-installed. This Intel “market-enabling reference design” is specifically focused on telephony-appliance applications. It features Intel’s low-cost high-value Atom processor. To support most POC requirements, the box includes a wide array of features: Ethernet connections for the wide area and 10 ports for connecting IP phones. Two POTS interfaces are included, as is a 160-Gig HDD and a compact-flash slot. Commetrex will deliver the box with BladeWare and telephony-interface boards pre-installed.

So, if you are interested in exploring the fax-appliance option, contact us at sales@commetrex.com.

What’s a Fax, Anyway?

2010-04-12T13:57:00.002-04:00

Quick! Define the term “fax”. Well, if you really try, you may find that defining fax is a little like defining “marketing”, a word everyone believes he knows how to define. Often, the more common the word the more difficulty one has in defining it. But the term fax (facsimile), as it is important in the world of telecommunications, is surrounded by patents, and is, therefore, the subject of intense legal scrutiny. So, the legal eagles arm wrestle over the definition.

So, what is it? Of course, “fax” (or facsimile) is a noun: you refer to the received image as “a fax” and refer to the terminal as “a fax.” It’s an adjective: “fax machine”. It’s a verb: “I faxed the document to you.” But the courts seem to be concerned with the process. What, really, constitutes the process or method of “faxing”?

You could resort to the dictionary and look up “facsimile” and talk about it being an exact copy of the subject document. You would also read about facsimile terminals that are used to send images over the telephone network. So let’s “drill down” as they say (or used to), and see what we find.

A few years ago I was an expert witness in pre-trial proceedings in a case that hinged on whether a fax terminal was a computer, so we had to be concerned with the legal definition of “computer” and “fax terminal”. I wrote”

With the exception of IP, the Internet Protocol, the Group 3 (G3) facsimile (fax) standard is the most popular computer-to-computer protocol ever. Although fax, the ability to transmit an image electronically over distance, has been in existence for over 100 years, G3 fax, the standard used hundreds of millions of times every day, was first published as an international standard in 1980. In this report we will use facsimile, fax, and G3 fax to mean an electronic device that implements the Group 3 fax standards specified and referenced in the ITU (International Telecommunications Union) T.4, or the Group 4 standard specified in the T.6 recommendation.

Not bad, if I do say so myself, since this is, essentially, what the US Central California District Court came up with a little later. That case hinged on whether a fax-image file e-mailed to an intended recipient by a store-and-forward computer system was a fax. There was a lot of legal verbiage around the judge’s so-called Markman ruling, but the key finding was that an e-mail with an attachment was not a fax. The court wrote:

For a machine to be a "fax" machine that sends "fax" messages, it must use a certain protocol-what the parties often refer to as a "digital dialogue"-to communicate. Otherwise, nothing distinguishes these machines from any other machine used for communication.

The court continued:

Given the foregoing, the Court finds that it is clear from the language of the claims that "facsimile protocol" means the standardized procedure that governs the transmitting and receiving of facsimile messages, excluding other protocols whereby the substance of a facsimile message is converted into a different format and then retransmitted using some other protocol.

So, the thing that makes a fax a fax is the protocol used to send the image from A to B. It’s interesting to compare the careful language of the court ruling with Wikipedia:

A fax (short for facsimile) is a document sent over a telephone line.

You might be wondering what the ITU recommendations say. T.4 is the top-level recommendation for G3 fax. It states:

This Recommendation defines the characteristics of Group 3 facsimile terminals, which enable documents to be transmitted on the general switched telephone network, international leased circuits, and the Integrated Services Digital Network (ISDN). These terminals enable black and white documents to be transmitted and also optionally color documents…The procedures (the "digital dialogue" of the ruling) to enable Group 3 facsimile terminals to communicate using the above capabilities are defined in ITU-T Recommendation T.30.

So, to summarize: a fax is an encoded image (as specified by T.4 and T.6) that is transmitted over the switched telephone network from one communications endpoint to another using the procedures defined in ITU recommendation T.30.

I did not find any explicit references that would help answer the natural questions regarding whether the circuit can include non-PSTN segments (e.g. IP) with the result still being a fax. I suspect that any court cases that exist or will exist will conclude that the critical item is that the endpoints use T.30.

If you know, please respond to this posting.

The Long-Fax-Failure Problem Revealed Commetrex Solves Problem That Has Plagued the Industry

2010-03-22T14:04:00.001-04:00

In my last blog post, I explained how slow signaling in carrier networks can result in the failure of a fax session and how Commetrex’ patent-applied-for technology solves the problem. But, you may have wondered, doesn’t Commetrex’ solution mean more G.711 pass-through faxes? And don’t they inevitably fail? That’s a good question because the answer is yes, they do inevitably fail unless the session includes a fax relay with Commetrex’ proprietary buffer-management technology.

Carriers have done a great job of virtually eliminating dropped packets, but PCM clock-synchronization problems remain. The problem results from jitter buffer under-run and over-run caused by the PCM clocks at opposite ends of the link not being equal, which is always the case. The question, of course, is how unequal are they and how long is the fax? The more unequal they are the quicker the session fails. Long-enough G.711 pass-through faxes and even long T.38 sessions can fail if the jitter buffers are not effectively handled. Commetrex’ relay technology and BladeWare media servers include proprietary buffer-management technology that eliminates PCM-clock-synchronization problems in G.711 pass-through and T.38 fax sessions.

In BladeWare, our HMP fax-server platform, terminating G.711 IP faxes use the incoming G.711 packet stream for timing purposes. For every 20ms of G.711 data it receives, for example, the system generates an equal amount of data for transmit, removing clock-synchronization errors. So BladeWare’s G.711 data are exactly in sync with the remote relay's sample clock, and we never overflow or underflow our G.711 buffers, nor does the remote gateway. Problem solved.

However, in relay-to-relay T.38 operations, there are two analog PCM sample clocks: one at the remote transmitting fax and the other at the local re-modulating modem. These two clocks always have a different rate. Bits generated at the transmitting endpoint fax terminal must be retransmitted by the off-ramp gateway’s local modem. If the remote fax is generating bits faster than the gateway’s local modem can send them out to the fax terminal, off-ramp overflow eventually occurs. Goodbye, fax session! In the reverse case, the on-ramp modem will run dry since the off-ramp gateway is sending the bits out faster than it receives them, and T.38 relay will have to spoof some bits to keep the transmitter running (provided you have a well designed relay, of course). Underflow is not as much of a problem, since the relay can insert additional flags in V.21 data or padding bits at the end of a line of image data (does your relay do that?). But overflow is a problem as valid data must be tossed, and modems just hate that.

Enter Commetrex innovation. Our T.38 relay uses a variable-delay jitter buffer. What that means is that the jitter buffer starts at zero delay for each sequence of incoming packets. If packets are delayed, the buffer will increase in length. This gives us the maximum protection against clock drift, as the clocks are re-synched at the start of each new modem operation. Problem solved for T.38!

But what about G.711 pass-through, you ask? More innovation is our answer. The new technology explained in last week’s post will also be included in a new release of our gateway software, which many of the industry’s OEM use. It allows their gateways to make the same intelligent decision of whether to accept a T.38 re-invite. This same package includes patent-applied-for fax-aware jitter-buffer management that is specific to G.711 pass-through fax and eliminates PCM-clock sync problems in gateways.

Bottom line? Performance matters. Experience matters. Rock-solid FoIP is finally here!

The Slow-Network-Signaling Problem Revealed!

2010-03-05T09:58:00.003-05:00

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!

I Confess…I’m a Stickler

2010-02-18T10:57:00.006-05:00

A stickler—someone who cringes when exposed to bad grammar and punctuation, and someone everyone hates. You know the type: we’re unable to read the newspaper without a red pen in hand. Doesn’t make me particularly proud, but knowing it will help you understand what motivated this blog post, since my problem also extends to technical misconceptions.

Exposed, as I am every day, to all things fax, I constantly hear people refer to TDM-based fax, or analog fax, as T.30, as opposed to the IP-based T.38. Actually, many also refer to G.711 pass-through IP fax as T.30. I cringe, but I’ve learned to let it pass and translate “T.30” to “TDM-based analog signal.” So, what’s the problem, you say?

The ITU T.30 recommendation is a computer-communications protocol used by two computers, typically communicating over some form of network, for the purpose of transfering an image from one to the other. In fact, a US Federal District Court ruled in a patent-infringement case, in effect, that the word “facsimile” or “fax” meant exactly that (two endpoint terminals exchanging image data in real time) ruling out, for example, an image file being delivered via e-mail, as is done by hosted fax services. Although the latest version of T.30 mentions V.34 due to the special requirements its use places on T.30, the image modems are actually specified in T.4, not T.30.

Granted, when T.30 first specified G3 fax in 1980, IP telephony didn’t exist, and a TDM-based voice infrastructure, the PSTN, was assumed. But that is no longer the case. Today, we have T.38 to take care of the situation where there is an IP network between the two computers (T.30 was not economically practicable prior to micros) using T.30 to communicate. The job of T.38 is to make this interposing IP network transparent to the two T.30 machines. It must overcome packet loss and PCM-clock synchronization problems, while maintaining the timing requirements of the T.30 “conversation.” The relationship of T.30 and T.38 is shown below.

Another Long Tail?

2010-02-15T12:48:00.013-05:00

Your product plans call for the development of a product that requires multi-channel media-processing resources. You’ve looked at the market and have concluded that a PC-based system could meet your functional, capacity, performance, and cost requirements. And with the financial constraints and lower-demand realities of today’s market and time-to-market delays not supporting in-house development, you are looking at what is available as a value-adding platform. But sometimes all the criteria that should be considered are not made obvious by only looking at the requirements of today’s product due to the long-tail ramifications of the initial selection.

“Long-tail ramifications”? Well, yes, but a “long tail” different from the one Chris Anderson wrote about a few years ago. The consequences of a platform’s selection will be around a long time, often much longer than imagined and well beyond that initial product. You and your channel partners will invest in the competencies required to support the new platform in marketing, product development, and customer service. You and your channel partners will also invest in product inventory, although software-only strategies can reduce that number, sometimes to zero. Since this big brontosaurus-like tail is so difficult to move, it will shape your marketing strategy, constraining your choices to those supported by today’s possibly narrowly focused selection. Once you’ve absorbed those large initial investments, moving to a new platform is a tough call. So, it pays to look beyond today’s requirements and do your best to cover tomorrow’s as well.

The best way to avoid being put into a box is to select a comprehensive, functionally open-ended telephony platform that requires no compromises today, yet has the architectural flexibility to support nearly any direction you care to take in the future.

Take, as an example (just to pick one at random), multi-line fax resources required for an enterprise server targeting the Fortune 1000 for use in IP networks. What requirements does this suggest?

The platform must be robust, capable of continuous operation.
The platform must be interoperable with a wide range of gateways and IP service providers.
Name recognition is more important than price since the system’s average ticket will be over $30,000.
The platform must support T.38; G.711 pass-through is not required, nor is support for other media.

You could meet these requirements by going with the incumbent, but what about the future? Let’s say you’ve discovered that with a growing partnership with a PBX manufacturer you see an opportunity to repurpose your enterprise-fax application for the small-medium enterprise as a software add-in to your partner’s UM subsystem. But the $450-plus per channel you’ve been paying for fax resources suddenly looms large, effectively nipping your idea in the bud.

Suppose you need to add voice to your product, possibly as a prompt to input an extension. Suddenly, your choice of a platform that can’t support voice shuts you out of that application.

Suppose you find that all the propaganda you’ve heard about G.711 pass-though being worthless in IP networks wasn’t true. Perhaps it’s as simple as the SIP-trunking service provider not offering T.38, yet always delivering error-free G.711 faxes or perhaps an enterprise customer using an IP PBX, which has yet to add T.38 support, as a gateway. Lack of G.711 support can hurt in unexpected ways.

Some software-only T.38 fax-resource products began as an emulation of a T.38-only hardware resource, so that’s all it does. Others are produced by organizations with no signal-processing skills, so they have no HMP fax modems. But there are fax-resource platforms that were built from the ground up as a scalable and extensible telephony platform, a platform that not only supports all the media-processing technologies you need now or in the future, but also what could become critical telephony functions for a new market initiative.

So, what might the additional requirements be? The best protection is to choose an open, extensible, general-purpose telephony platform-one that is architecturally open-ended. Of course, having the industry’s best fax technology at the best price is required for today’s requirement. But what about tomorrow’s?

Here are a few things to look for:

1. Extensible.

2. Scalable to tens of thousands of channels.

3. Support for both IP and TDM networks on the same platform at the same time.

4. Support for G.711 pass-through fax.

5. Support for SIP, but extensible to support other signaling (Woomera anyone?).

6. Support for voice.

7. Open and extensible in every dimension: media, system service, management, signaling, etc.

By the way, BladeWare and, BladeWare combined with Sangoma boards, meets these criteria…all of them.

What is Experience Worth?

2010-02-15T11:25:00.021-05:00

Commetrex has been developing and marketing fax-technology products for over 15 years, and BladeWare, our HMP media server has been supporting those fax technologies in the field for five years. And we are adding to our value as your fax-technology partner every time we help a customer solve a problem. If you’ve read our latest white paper, “The State of IP Fax”, you could guess that we spend plenty of time helping our customers make the transition to direct network-connected T.38. That white paper documents Commetrex’ experience in an industry that is trying to make the transition from the use of T.38 in enterprise IP islands to enterprises, service providers, and carriers interconnected via SIP.

It’s a challenge. It’s one we’ve taken on directly with our customers and as participants in the SIP Forum’s FoIP Interop Task Group.

Commetrex has made a corporate decision to do what we can to aid our customers and the industry to make this transition. We jump at the opportunity to work with our service-provider BladeWare customers in solving network-peering problems. For example, we are currently working with a fax-broadcast customer and his service providers to bring transaction-completion rates of a T.38-based broadcast even with that of TDM networks. We are working directly with a VoIP service provider to qualify a NAT-firewall solution. And another service provider is having trouble getting inbound faxes to succeed when the call was forwarded by his IP-carrier partners. And, our participating in the SIP Forum’s FoIP Task Group is intended to promulgate and broaden the benefit.

The fax-broadcast is proving to be quite a challenge because the evidence suggests that the problems, such as random timeouts, are being caused by the long-haul IP partners, and getting their cooperation is not easy.

The VoIP service provider is using an on-premises B2BUA in conjunction with a network-based TURN server to solve the NAT and firewall problems often encountered when a SOHO customer has independently obtained the DSL service and is currently using it for data only.

You might find the call-forwarding problem particularly interesting. Here, we have seven networks involved (yes…seven): An inbound fax call originates on the 1) PSTN, where it is handed to 2) Level(3), which passes it to 3) Bandwidth.com (no fax determination, as yet). Bandwidth.com determines that the call is to be forwarded and passes it to 4) XO Communications, Bandwidth.com’s “handoff” carrier for outbound 1+ calls. XO then passes it to 6) Global Crossing via (now get this) the 5) PSTN. Global Crossing sends it to 7) Intelemedia, our BladeWare customer, via the Global Crossing MPLS network. Whew! It should come as no surprise that this call-setup odyssey isn’t trouble-free. Inbound faxes that are dialed direct work; those calls that are forwarded never work. Specifically, BladeWare and the remote gateway give it a game try, but eventually the remote caller hangs up.

The problem begins with BladeWare receiving a “No Signal” T.38 packet after receiving a V.21 preamble. Now, this may not mean anything to you, but the reason for it may. All you need to do is take a look at the figure below. Note the gap in the data about 25-percent into the plot. That 40-msecond gap is what caused the no-signal. And it doesn’t have to be T.38. BladeWare supports G.711 pass-through fax, so Intelemedia tried the same call with G.711 and had 100-percent failures when the call was forwarded. Well, “duh”, you may say, G.711 doesn’t work over the Internet. Hold on. Intelemedia is getting 100-percent—so far—success rate with G.711 pass-through with Global Crossing’s MPLS when the call is not forwarded.

Here is the picture of the call in the frequency domain (higher frequencies plot as higher amplitude):

Our guess is there is a jitter buffer somewhere that is filling up or the call is transferred between boxes, somehow leaving the gap. And the signal is not just interrupted. For some 60-ms after the break, the signal has glitches, likely due to a single packet being repeated by the packet-loss-concealment logic of a tandem network entity. Here’s the gap up close showing the glitches following the gap at approximate 10-msecond intervals.

Although this is not really a BladeWare problem, it does indicate a common network-failure mode that BladeWare could handle with a slight modification, which we installed for our customer. It solved the problem.

That’s the value of experience.