Paradyne and Commetrex Ink Technology and Marketing Deal
Paradyne Corporation and Commetrex have entered into a joint technology and marketing agreement related to Paradyne's patented technologies that implement the ITU modem standards V.34, V.32bis, V.32, V.22bis, V.22, AT&T 212A, and AT&T 103J. Under the agreement, Commetrex will optimize the modems for execution on TI TMS320C6400 high-performance DSPs. Commetrex will also utilize the V.34 data-modem technology to produce a V.34 fax modem, which will be offered as an option in BladeWare's Multi-Modal Terminating Fax, the MSP series of PCI telephony boards, and with V.150 modem relay as an option in the company's OpenEndpoint product.
Paradyne was a leading contributor to the development of the ITU modem standards, and V.34 in particular. Paradyne was the first company to have a V.34 modem, and continues to offer the industry's highest-performance V.34 products. As a result of its early modem developments, Paradyne has 22 patents covering V.34 modem technology, which are included in the deal.
Commetrex will complete the conversion of Paradyne's V.34 data modem to the fax version in the second quarter, with 'C6400 optimizations also available by mid-year. 'C6400 optimizations for the V.34 data modem and fall-backs will be released throughout the second half.
PCM Synchronization and G.711 Modem Pass-Through
Commetrex' in-house testing shows that with IP packet loss of just 0.3%, non-T.38 faxes will have a failure rate on the order of one-in-seven pages. After all, most modems will interpret a 30-millisecond gap in the data (just 1-3 three lost packets) as a loss of carrier. And packet-loss-concealment techniques used for voice can only make matters worse for fax, depending on the modem and the concealment method. So you have to be concerned about packet loss when trying to send faxes over an IP network without the benefit of T.38. But what if your packet loss is much less than 0.1%? Are you out of the woods? Not necessarily. There's still the little-appreciated problem of end-to-end PCM-clock synchronization.
Most gateways will disable adaptive jitter buffering and switch to fixed jitter buffers for fax- or data-modem calls. This is necessary since an adaptive buffer shrinking or expanding requires that buffers get tossed or data inserted. But here's the catch: If the PCM clocks at both ends of an IP connection have a 50-PPM accuracy, the worse-case difference is 100 PPM. A 50-millisecond jitter buffer will be eaten up in only 8 seconds under these conditions, resulting in a dropped connection. Other than use T.38 gateways, which decouple the PCM clocks from each other, what can you do?
If the carriers on each end synchronize the PCM clocks to a reference standard, you're not likely to have that much of a problem. But what about delivering a fax to a terminal attached to a low-cost IP endpoint that does not support T.38? Here, the PCM clock is provided by a low-cost oscillator circuit, so the probability of sending a clean fax through such a terminal is low.
We recently ran into a situation where this was happening. The user, who was doing high-volume fax broadcasts, was having great results in one area code, and terrible results in another. We're investigating the problem. When we have the results, we'll post them here.
|
|
Anatomy of a T.38 Interop "Issue"
A new licensee of Commetrex' TeminatingT38 was verifying his integration into his UM system by sending and receiving faxes through several gateways. He reported that when sending V.17 faxes in ECM (error-correcting mode) through a particular gateway, partial pages were received by the analog terminal. No problem was observed when sending to the same terminal through different gateways.
Our customer repeated the test, sending to a fax terminal here at Commetrex where the failure also occurred. The customer did an Ethereal capture of the IP stream; Commetrex made a digital recording of the PSTN signal we received. We processed the recording with our FaxTap product.
Within a few hours we had narrowed the problem to the improper handling of flags between ECM frames. Commetrex has learned in the three years we have operated the T.38 Interoperability Test Lab, that the primary reason for interoperability failures in ECM operation in a gateway is improper handling of flag insertion. T.38 does not transfer the HDLC framing used in ECM operation. As a result, flags between frames must be correctly removed and reinserted at the transmitting gateway.
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. Running short should not be a problem. Extra flags can be used to make up the under run.
We are now working directly with the gateway developer to resolve the issue.
T.38 Test Version of BladeWare
Commetrex' T.38 Interoperability Test Lab is a no-fee service offered to vendors of fielded equipment and licenses of Commetrex' PowerRelay for T.38. But what about developers that, for some reason choose to develop their own relay or (gasp!) license it from a competitor? They need help too.
Well, we're not too proud to not offer it. In response to popular demand, Commetrex is offering a slimmed-down version of BladeWare with Multi-Modal Terminating Fax, which includes both G.711 pass-through and T.38 termination configured to support interop testing. Logging is enabled so there's nothing you can't determine about what's going on in your gateway.
And it only costs $3,000.
VON Spring 2005
Have you attended one of Jeff Pulver's VON events? If you're interested in packet telephony, the VON events are a must. The next one (we'll be exhibiting) is at the San Jose Convention Center March 7-10.
At VON Fall 2004, Mike Coffee, Commetrex' CEO, participated in a panel, "Interactive Media in IP Networks". Other panelists included representatives of Convedia, Eicon Networks, and Pactolus. Mike's presentation focused on the economics of IP media servers. If you would like a copy of his presentation, give him a call at 770-449-7775 X310 or e-mail at mcoffee@commetrex.com.
At VON Spring 2005 Mike will also participate on an interactive-media (media servers) panel Monday, March 7, at 3:00 PM. If you're interested in HMP-based media servers, make sure you attend the session. You can also see our BladeWare HMP media server jump through hoops at our booth, #122. In the meantime, why don't you register to attend (http://www.pulver.com) so you can check out the panel, BladeWare, and all our great products that we'll be exhibiting?
|
