I have free equipment so I should be able to assist in testing. Put me on the testers list, not sure how much help I can be on the development side.<br><br><div class="gmail_quote">On Thu, Dec 3, 2009 at 12:21 PM, Kevin P. Fleming <span dir="ltr"><<a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Over the past year, some of us at Digium have spent many (MANY) hours<br>
working on FAX support in Asterisk (even though we'd all prefer to see<br>
FAX go away as the obsolete technology that it should be <G>). Some of<br>
this work was part of our release of our commercial FAX for Asterisk<br>
product, some of it was driven by our desires to have solid FAX support<br>
in our commercial PBX products, but most of it was driven by the need to<br>
get open source Asterisk (and its community of users) able to use FAX<br>
reliably with as many non-Asterisk endpoints as possible.<br>
<br>
In Asterisk 1.4 and prior releases, there was limited support for FAX of<br>
any kind; Asterisk 1.4 can pass through T.38 sessions on SIP channels,<br>
but that's all. With an open source addon (based on Steve Underwood's<br>
excellent spandsp library), it can have dialplan applications to send<br>
and receive FAX over audio (G.711 TDM) links.<br>
<br>
During the development of Asterisk 1.6.0, Steve's FAX dialplan<br>
applications were merged into asterisk-addons, and then directly into<br>
the Asterisk source tree, where they became the 'app_fax' module. In<br>
addition, the T.38 negotiation process was redesigned to allow Asterisk<br>
applications to actually be T.38 endpoints; this resulted in the ability<br>
to send and receive FAX over audio *and* T.38 links.<br>
<br>
Once this got into the community's hands, we started seeing large<br>
numbers of bug reports because users could not successfully FAX over<br>
T.38 with various ATAs and service providers. I won't go into the gory<br>
details of why this was the case, except to repeat a recent quote from<br>
Steve himself on IRC: "The T.38 spec was written after a night of heavy<br>
drinking as a joke.". While that's not technically true, it is true that<br>
compliance with the T.38 recommendation, primarily in the SIP/SDP<br>
negotiations area, is very poor across the industry. Producing a T.38<br>
endpoint the interoperates widely is a complex and difficult process,<br>
that can only be achieved through hours and hours (and hours) of testing.<br>
<br>
As these problem reports got more severe, we took a significant step: we<br>
rewrote the T.38 negotiation mechanisms in Asterisk *again*. These<br>
changes first appeared in the 1.6.0.14 and 1.6.1.5 releases. The in-tree<br>
app_fax application was updated to support these changes along with<br>
them, so open source FAX users got the benefits of these changes<br>
immediately... and the result has been wonderful. We get very few T.38<br>
negotiation-related bug reports now, and in nearly every case we can<br>
point to a misconfiguration or severely broken far endpoint that is the<br>
cause of the problem. For many, many people, FAX over T.38 in Asterisk<br>
1.6.0 and 1.6.1 'just works' now.<br>
<br>
While all of this was going on, Digium was also working on our<br>
commercial Fax for Asterisk product, which provides comparable<br>
functionality to app_fax, but uses a commercial FAX stack. When we began<br>
the development of this product, we knew that we wanted as many portions<br>
of it as possible to end up open source, so rather than build it as a<br>
monolithic module, we built two modules: res_fax and res_fax_digium.<br>
res_fax is similar to app_fax, in that it provides dialplan<br>
applications, dialplan functions, and other associated components to<br>
send and receive FAX. However, it does not actually include any FAX<br>
stack; for that, it provides a plugin interface that allows one (or<br>
more) additional modules to be loaded to actually provide the FAX<br>
technology implementation. It *does* handle all T.38 negotiations,<br>
however, using the 3rd generation T.38 implementation in Asterisk.<br>
<br>
Of course, res_fax_digium is Digium's commercial plugin module for<br>
res_fax, and we have been delivering the combination of those two<br>
modules to our Fax For Asterisk customers for quite a few months now.<br>
(Unfortunately it has taken longer to get these modules updated to match<br>
Asterisk's T.38 API than we would have liked, but that's not important<br>
for open source users). Recently, with a final set of changes to the<br>
UDPTL stack in Asterisk, we've reached the point where we think we've<br>
implemented all the parts of the T.38 recommendation that we can<br>
implement, in as compatible and interoperable a way as we can, with a<br>
few configuration options that provide the ability to override broken<br>
behavior by far endpoints when necessary. In fact, the combination of<br>
the very most recent Asterisk open source releases and either app_fax or<br>
res_fax+res_fax_digium now successfully interoperates with quite a few<br>
T.38 ATAs we have in our lab and a couple of service providers, and<br>
we're testing more of both as I write this. In nearly every case, this<br>
works *without* requiring any configuration changes in Asterisk or the<br>
FAX applications, which is good news for end users indeed. We've even<br>
extended (and fixed) the 'faxdetect' functionality in chan_sip so that<br>
it works as users expect it to, in a similar way to the faxdetect<br>
feature in chan_dahdi.<br>
<br>
Now that this point has been reached, it's time for us to act on our<br>
plan to open source res_fax; to that end, I've created a new branch in<br>
Subversion (/svn/asterisk/team/group/res_fax) based on Asterisk trunk,<br>
and merged the most recent version of res_fax into it, updating it to<br>
compile against trunk's recent API changes. By the time Asterisk 1.8 is<br>
released, res_fax will *replace* app_fax, as it provides the identical<br>
dialplan applications (same names, options and operations), but has<br>
additional features and compatibility functionality. To achieve this,<br>
though, we're going to need a res_fax_spandsp plugin module, so that the<br>
combination of res_fax + res_fax_spandsp provides the same functionality<br>
as app_fax did, and it will be a seamless transition for Asterisk 1.6.x<br>
FAX users to move to Asterisk 1.8 when they are ready. We've tasked one<br>
of our developers to start working on this over the next few weeks, and<br>
I'm sure you'll see some initial steps toward that end shortly. For<br>
those of you who have contributed improvements to app_fax and use it<br>
heavily (or even those who just use it and can provide testing), I'd<br>
encourage you to reply in this thread if you are interested and willing<br>
to assist in this effort.<br>
<br>
Now, on to even more interesting stuff: as I've worked on this over the<br>
past 6-8 months, I've also spent time finally trying to understand how<br>
best to fit TDM-T.38 FAX relay into Asterisk. I know that there are<br>
number of community developers who have been working on this, and there<br>
are multiple patches in the issue tracker that provide this<br>
functionality in various forms. There was also an attempt by Daniel<br>
Ferenci to start a discussion on this list about the best long-term<br>
approach for relay support, but he didn't really get any responses.<br>
<br>
Once res_fax and res_fax_spandsp are ready for users to use, it'll be<br>
time for them to be extended to support FAX relay as well. I would like<br>
to propose that this be implemented by res_fax providing a new API, a<br>
'FAX relay session', that a channel driver (one which services TDM<br>
channels) can use to offer T.38 support to the rest of Asterisk, as if<br>
it supported T.38 natively. We can start a separate thread here to talk<br>
about particulars, but I believe this is the cleanest approach with the<br>
least impact on existing code in Asterisk, and I'd like to get opinions<br>
from other interested parties and discussion going.<br>
<br>
In summary, it appears that Asterisk 1.6.x has achieved pretty solid FAX<br>
support (especially over T.38), and that with Asterisk 1.8 we'll be able<br>
to improve it further and begin moving towards FAX relay support as<br>
well. For all of you who still insist on using this obsolete technology,<br>
I hope this has provided what you need to be able to keep using Asterisk<br>
in every place that it makes sense in your networks!<br>
<br>
--<br>
Kevin P. Fleming<br>
Digium, Inc. | Director of Software Technologies<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
skype: kpfleming | jabber: <a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a><br>
Check us out at <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</blockquote></div><br>