T.38 is an ITU standard for sending FAX across IP networks in a real-time mode. T.38 faxing has been hyped a lot, while others pondered if T.38 was dead. Regardless of which camp you stand in, we can all agree that T.38 hasn't exactly taken off, including on the Asterisk IP-PBX. Faxing support in general on the Asterisk platform has been sorely lacking and one of Asterisk's weaknesses. Though there are some workarounds such as Hylafax and IAXmodem. IAXmodem is used to interface Asterisk with HylaFax.
However, as of Asterisk 1.4, Asterisk allows the passthrough of T.38 UDPTL data. Asterisk does not actually decode the T.38 protocol, it simply passes the T.38 data to a T.38 PSTN gateway. For termination you'd need something like the Gridborg HMP Server or CallWeaver. I should also mention that AudioCodes has helped write articles for TMC as well as held webinars on TMC discussing T.38 networking faxing used in conjunction with SIP, which are worth exploring. AudioCodes also makes voice TDM hardware which runs on the Asterisk platform.
The other issue with T.38 is that T.38 capabilities vary greatly between VoIP providers. Some do not support it at all, while others support it fully, up to and including V.34 FAX (high speed 33,600bps faxing). Similarly, some IP-FAX hardware supports some capabilities of T.38, but not all. Most don't support the higher speed V.34 spec.
One interesting solution that was launched last week at ITEXPO was a new V.34 T.38 Fax-over-IP endpoint and gateway from Dialogic. They claim to be the industry’s first Fax Over IP Endpoint and Gateway solution supporting V.34 T.38. In theory you could use the T.38 passthrough function in Asterisk v1.4+ to send the V.34 T.38 fax traffic to the Dialogic fax gateway. Still, I'd like to see an integrated solution on Asterisk for sending/receiving faxes. One less server to manage plus less electricity utilization. We want to be green don't we?
In any event, here's the Dialogic release in case you missed it:
Dialogic Corporation ("Dialogic"), a global provider of world-class products and technologies for media and signal processing, today announced that it has released the industry’s first Fax Over IP Endpoint and Gateway solution supporting V.34 T.38.
The award winning Dialogic® Brooktrout® SR140 Fax Software and Dialogic® 3000 & 4000 Media Gateway Series (DMG3000 & DMG4000) enables enterprises to deploy fax server solutions confidently into existing Voice over IP (VoIP) installations, while leveraging their existing IP infrastructure. The addition of V.34 T.38 allows these products to transmit fax data at 33.6 kbps, surpassing the rest of the industry which currently transmits fax traffic over T.38 at a maximum of 14.4 kbps.
“The addition of rapid V.34 speeds to our highly reliable Brooktrout SR140 T.38 Fax over IP based fax server solutions is a significant break through in our industry, said Tom Linhard, President at FaxCore, Inc. A FoIP endpoint to gateway solution supporting V.34 T.38 will allow FaxCore and Dialogic’s mutual customers to send and receive faxes much faster. This will save them money by lowering both network bandwidth and telecom expenses.”
Dialogic Corporation is the market segment leader in fax and fax-over-IP platforms, offering one of the fullest featured and broadest fax solution portfolios on the market today. The Brooktrout SR140 and DMG3000 & DMG4000 platforms support real-time FoIP, providing companies with the ability to integrate fax servers into their VoIP network. In addition to capturing the benefits of IP-based communications, these products have excellent performance, reliability and scalability, attributes that enterprises have come to expect from the Dialogic Brooktrout Circuit Switch based fax product line.
“Dialogic’s fax technology is the engine of the modern fax server that delivers document management, business process automation and compliance with industry mandates, such as Sarbanes Oxley and HIPAA," stated Jim Machi, Senior Vice President of Marketing for Dialogic. By implementing V.34 T.38 fax on their IP network, enterprise customers will not only benefit from the savings achieved by automating fax document processing and ensuring the integrity of internal control procedures and transactions for regulatory compliance, but can also expect to have lower operating costs than if they were using comparable FoIP solutions currently on the market.”
However, as of Asterisk 1.4, Asterisk allows the passthrough of T.38 UDPTL data. Asterisk does not actually decode the T.38 protocol, it simply passes the T.38 data to a T.38 PSTN gateway. For termination you'd need something like the Gridborg HMP Server or CallWeaver. I should also mention that AudioCodes has helped write articles for TMC as well as held webinars on TMC discussing T.38 networking faxing used in conjunction with SIP, which are worth exploring. AudioCodes also makes voice TDM hardware which runs on the Asterisk platform.
The other issue with T.38 is that T.38 capabilities vary greatly between VoIP providers. Some do not support it at all, while others support it fully, up to and including V.34 FAX (high speed 33,600bps faxing). Similarly, some IP-FAX hardware supports some capabilities of T.38, but not all. Most don't support the higher speed V.34 spec.
One interesting solution that was launched last week at ITEXPO was a new V.34 T.38 Fax-over-IP endpoint and gateway from Dialogic. They claim to be the industry’s first Fax Over IP Endpoint and Gateway solution supporting V.34 T.38. In theory you could use the T.38 passthrough function in Asterisk v1.4+ to send the V.34 T.38 fax traffic to the Dialogic fax gateway. Still, I'd like to see an integrated solution on Asterisk for sending/receiving faxes. One less server to manage plus less electricity utilization. We want to be green don't we?
In any event, here's the Dialogic release in case you missed it:
Dialogic Corporation ("Dialogic"), a global provider of world-class products and technologies for media and signal processing, today announced that it has released the industry’s first Fax Over IP Endpoint and Gateway solution supporting V.34 T.38.The award winning Dialogic® Brooktrout® SR140 Fax Software and Dialogic® 3000 & 4000 Media Gateway Series (DMG3000 & DMG4000) enables enterprises to deploy fax server solutions confidently into existing Voice over IP (VoIP) installations, while leveraging their existing IP infrastructure. The addition of V.34 T.38 allows these products to transmit fax data at 33.6 kbps, surpassing the rest of the industry which currently transmits fax traffic over T.38 at a maximum of 14.4 kbps.
“The addition of rapid V.34 speeds to our highly reliable Brooktrout SR140 T.38 Fax over IP based fax server solutions is a significant break through in our industry, said Tom Linhard, President at FaxCore, Inc. A FoIP endpoint to gateway solution supporting V.34 T.38 will allow FaxCore and Dialogic’s mutual customers to send and receive faxes much faster. This will save them money by lowering both network bandwidth and telecom expenses.”
Dialogic Corporation is the market segment leader in fax and fax-over-IP platforms, offering one of the fullest featured and broadest fax solution portfolios on the market today. The Brooktrout SR140 and DMG3000 & DMG4000 platforms support real-time FoIP, providing companies with the ability to integrate fax servers into their VoIP network. In addition to capturing the benefits of IP-based communications, these products have excellent performance, reliability and scalability, attributes that enterprises have come to expect from the Dialogic Brooktrout Circuit Switch based fax product line.
“Dialogic’s fax technology is the engine of the modern fax server that delivers document management, business process automation and compliance with industry mandates, such as Sarbanes Oxley and HIPAA," stated Jim Machi, Senior Vice President of Marketing for Dialogic. By implementing V.34 T.38 fax on their IP network, enterprise customers will not only benefit from the savings achieved by automating fax document processing and ensuring the integrity of internal control procedures and transactions for regulatory compliance, but can also expect to have lower operating costs than if they were using comparable FoIP solutions currently on the market.”
Technorati
Del.icio.us
Slashdot
Digg
There actually is full fledged t.38 support for asterisk:
http://www.attractel.com/faxterisk.php
2 week trial licenses are available.
Also have a look at our zoiper softphone which can receive, and in the next version, somewhere next week also transmit faxes over t.38.
Tom, geeks don't send faxes; business people do. So only a techie (not techie journalists) that extrapolates his personal use of fax to the world at large, and does not understand the technical problems regarding real-time IP fax, would ponder whether T.38 is dead.
The examples you offer are not examples of the need for or the effectiveness of T.38, but of the always-long-ramp of new technologies endemic to telecom. Level(3) does not support T.38, not because it doesn't make sense, but because the circa 1998 gateways they use don't have T.38 support. But they are migrating to gateways that do (and that are based on Commetrex' T.38). Who does? Global Crossing does because last year they upgraded their gateways to T.38 support (yes, Commetrex technology again). iBasis has supported T.38 for sometime. So does Gafachi. And, eventually, all of the IP transport wholesellers will. It just takes time and money, not the realization that all businesses use fax and all businesses expect their carriers to deliver clean faxes.
You're correct that all Asterisk can do today is pass faxes through. But several companies are working on adding inherent T.38 termination support to Asterisk, and, I imagine, Digium will eventually do something.
However, some of the vendors of proprietary IP PBXs are adding fax support, so Asterisk is in danger of falling behind the curve.
So, what's the hold up? Well, primarily it's that a great value-adding solution requires a great T.30, T.38, fax modems (for G.711 pass-through)and their integration, and that ain't free. Beyond that, there's the need for either a fax application or effective integration with third-party UM products.
T.38 has been incubating, has birthed, and is now entering childhood. That's telephony.
As Mike Coffee said, FAX is something that won't go away. Most engineers may think it makes dinosaurs look like the latest thing, but the volumes of FAXes being sent each day is still huge.
I say this as someone who has implemented T.38 - T.38 is horrible in concept and specification. In a sane world, FAX over IP would be entirely by T.37 - the store and forward FoIP protocol - as the world gradually migrates all FAX to e-mail. However, people have this strange, and incorrect, perception of FAX as something real time, and direct to the recipient. This is in spite of the fact that many of them receive their own FAXes through a FAX mailbox. :-) Somehow, they see the non-real time behaviour of T.37 as a second rate choice.
That said, T.38 is a workable way to make real time FoIP succeed in a large percentage of cases. As Mike said, telecoms protocols tend to have a long gestation time, but I think T.38 has been held back by being so loosely defined. It offers numerous ways to encode each step of the transaction, and there are numerous grey areas. Like too many other specs, T.38 is gradually settling down to a reasonable level of interoperability through implementors gradually work around the weirdness in each other's implementations. It doesn't help that even the biggest vendors keep producing new firmware revisions which are quirkier that their predecessor, but it seems to be getting better.
One area where current T.38 support is at odds with heavy business FAX users is V.34. Businesses sending large volumes of FAX tend to do so because it transfers signed black and white documents well. Their core requirement is to send black and white images quickly. The hardcore of volume FAXing seems to be migrating to JBIG + V.34. A lot of T.38 implementations still inhibit the ECM mode of FAXing needed for JBIG, and very few T.38 implementations support V.34. ECM suppression puzzles me, as I know from experience its not a big deal.
Steve, there are two reasons some gateways that do support T.38 don't support ECM: they can't make it work reliably and it requires a significant increase in per-channel memory. If you're building a DSP board to support thousands of channels, as some of our licensees do, adding the RAM needed for each channel to hold the frames it might need to retransmit (ECM is an ARQ protocol) can drive the cost of the gateway up significantly.
Hi Mike,
In your first point are you referring to design or deployment?
It seems common for operators to inhibit ECM when deploying T.38 gateways which support it. Their reason seems to be that their revenue is per page, and minimising trunk time is king. The consequence that FAXes may be corrupt, especially if there is packet loss, doesn't cut much ice with them. Such is the race to the bottom in the VoIP world.
As far as making ECM mode work reliably, I don't really see an issue. Its implementation is actually simpler than non-ECM mode, as the means to doing flow control is a natural part of the protocol. In non-ECM mode you need to play tricks, which the ancient T.30 protocol just fortuitously allows. In ECM mode a retry or two overcomes much of the packet loss drawback of T.38.
I don't really follow your point about memory usage. In ECM mode, the robust way to do flow control is to buffer a whole FCD frame (260 octets), and flow control with flag octets if you don't have a whole frame ready to go. This is not really a huge buffer. Most boxes I've tested against, which support ECM, seem to use this scheme. In non-ECM mode, the robust way to do flow control is to monitor the bit stream for EOL conditions. At an EOL, an almost unlimited number of zero bits can be safely inserted. So, the common practice seems to be to buffer until an EOL, and pad with zero bits on the output side if no EOL is currently sitting in the input buffer. This is pretty simple, but the worst case length of a row is fairly long. I've tried to mimic the tests described on your inter-operability test lab web page (some of which I don't understand. Is there anything which describes the rationale behind those tests? For example, why is TCP mode tested with FEC?). The torture test page in your tests seems to serve two purposes - to try a long unbroken transmission, and to try a worst case row. It would be best to try that with the largest possible image, though your web site seems to imply you use an A4 page at normal horizontal resolution. To handle that test well requires buffering comparable to ECM mode.