Can every extension be auto voice/fax?

Of course, even better to keep latency down would be if the faxing portion could be offloaded to another server but the user not requiring a separate account, such as avantfax seems to require.

What light is there to shed, unless you have had some major breakthrough faxing and SIP don't work together.

No what I mean is the only reliable faxing is via TFM trunks BRI/PRI or analog

I have never achieved consistent results with SIP, IAX or H.323 nor have I ever heard anyone who has.

Several people have PRI's and analog cards that can share timing, that works fine.

If you have something working well I am sure the community would like to hear about it!

PS: Yes, it is so far 100% consistent, we've even sent 20 page docs and everything comes in fine. I've read what you say also and expected that but so far, all tests are perfect.

Specifically to your Question, what detection method are you using - NVFax or Zaptel? Because you have to use NVFax on SIP trunks - Zaptel doesn't work for detection on SIP trunks (as you have seen).

Since we started messing with Trixbox in 2006, FAXing has been a requirement, not an option, and we have found the following to be the reliable methods of receiving FAXes on Trixbox (to the extensions - Unified Messaging meaning you Voice number is your FAX number):

1) TDM PRI - We have used both Digium and Sangoma PRI Interfaces in almost every variation of the 1 and 2 span cards and it is completely reliable - assuming you are using a REAL TDM PRI that is coming out of the nearest Central Office - MANY of the carriers will try to say that a Dynamic Access or Integrated or whatever they call it product is a real PRI - it's a lie (like so many things the carriers say) - if you have an Adran or Cisco box on the wall that is a VoIP interface and are connecting your PRI feed to a jack on the back of the box, it is not a true TDM PRI - the problem with the dynamic circuits is that the signal is converted from Digital TDM (at the CO) to IP to be pumped out to the Adtran/Cisco/Whatever and then re-converted to a PRI - this is where the signal degrades, latency is increased, and FAXing gets to be unreliable.

To reiterate, a TRUE TDM PRI will allow Trixbox extensions to receive FAXes reliably 100% of the time - we have over 100 systems installed here in Albuqueruqe, and I would guess 70% of them are using PRI's and receiving FAXes to the extensions. We even have one box set up at a real estate office with a fractional PRI (11 channels) that it used for nothing but FAX-2-EMail - it is not unusual for it to be receiving 5-8 faxes simultaneously during the weekdays - the realtors even use it as a simple Scan-2-PDF function and send the faxes to themselves - it has been working for almost two years, and have never had a complaint.

2) SIP Trunks - We have not had reliable results with FAX reception over SIP trunks that are coming accross the open Internet - Latency and Jitter on an uncontrolled circuit is more than any FAX can handle (that I have seen - we have tried AT&T, Voxitas, and Bandwidth.com) and I wouldn't even try.

BUT...

SIP trunks over a dedicated T1 with MPLS and the trunks coming from the same provider that is providing the T1 works perfectly with the provider we use, Paetec (formerly McLeod) - this was a revalation to us, and we were not expecting it, but since switching a customer that needed better bandwith (4 x T1's bonded into a 6-Meg Circuit) we are believers - here is our setup:

Carrier - Paetec
Circuit - MPLS T1 (1.542Mbps - Synchronus)
CPE - Adtran 908e
Trixbox 2.6.0.7 (with all patches, and updates) Running on a Dell PowerEdge 1800 (Hyperthreader no less!)

The customer asked us after the install if they could use FAXing, and we said probably not, but that it was worth trying, so we did - it worked GREAT and actually convinced us to switch our own circuit - up until that point, we had a true fractional TDM PRI (6 channels for voice) and the rest (1Mbps) as Internet Access - now we have a full T1 and up to 17 simultaneous Voice conversations (we only use G.711) for less money and it works FABULOUS!

Don't waste your time with FAX with SIP trunks over the internet - you will be dissappointed - POTS has been spotty also - sometimes it works, sometimes it doesn't - but TDM PRI and SIP on a MPLS T1 with trunks from the same carrier works reliably - we are doing it all over town, and it just works!

Don't believe what everyone else says - there is SO much mis-information floating around about the subject that it is hard to figure out - we have done all the testing and testing and testing and what I have posted here works reliably.

Greg

I understand that it's best to use pstn or pri lines but in this case, I need to keep trunks virtual, meaning, I can't have hardware in the boxes. That will change down the road but up front at least, I need to take advantage of wholesale level pricing which I can't get with physical pri's.
I also have a need to keep pri hardware out of the boxes to keep things simpler for those helping me.

Here is another thought/question;

Is is possible to forward only fax calls to a second pbx? I'm not sure how the system would be able to recognize that it is a fax call and send it, without answering? Probably can't be done.

Something like;

pbx1: Has a users DID on a SIP extension
pbx2: Has a second extension which is IAX for same user.

When fax call comes in to a certain SIP DID on pbx1, have that call recognized as a fax call through nvfax or something else, redirected to the other extension on the second system, where all of those extensions are IAX and accept fax.

This would also help in that faxing over the system would not bog down the voip calls/server.

As for the problem with fax over the Internet not being reliable, perhaps I could use a PRI to SIP gateway on the local lan to get my SIP and keep faxing reliable.

Mike

Using FreePBX, any inbound route can use NVFax detection, and therefore receive FAXes - In case someone comes along later and reads this post, let's make this as clear as possible:

You have the following numbers: (505) 998-5420 through (505) 998-5424, so you have the following possible inbound routes:
(505) 998-5420
(505) 998-5421
(505) 998-5422
(505) 998-5423
(505) 998-5424

Any (or all) of those numbers can listen for a FAX at the beginning of the call (we have found 6 seconds works the best) and if they hear a FAX machine, switch to FAX receive mode, and receive it and send it off to a e-mail address (or a distribution e-mail address). If the NVFax detection fails, the call is then processed according to whatever you have set up on the Inbound Route.

It doesn't matter where the call came from, or ends up as far as FAX detection - here are some possible scenarios:

SIP-Trunk->Trixbox->NVFax->Polycom SIP Phone
PRI-Trunk->TE-122P->Trixbox->NVFax->IAX2 Soft Phone
POTS-Trunk->TDM413->Trixbox->NVFax->Grandstream-SIP-ATA->Analog FAX

What this diagram is trying to show, is that no matter where the call comes in, when a new call is presented to Trixbox (Asterisk) no matter what the source, it can be checked for the presence of FAX tones, and if they are sensed, a FAX can be received - if it doesn't hear the FAX tones, the call can be passed on to any destination you can reach from the box - all the Format translation is handled by Asterisk.

>>My problem however is that I need to make this happen over the users one DID and our environment is SIP/IAX. The incoming trunks are SIP, the users extensions are SIP, that's where the problems lie else I would not have started this thread.

That is the design of FreePBX - Specifically, my DID at the office is (505) 998-1423 - My extension is a Polycom 501 SIP phone, but the inbound route that sends calls to 1423 checks every call for six seconds and listens for FAX tones - if it hears them, my desk phone never rings - I just get the FAX - if not, then my extension rings.

So, if you are getting DID's, then every DID can be it's own receive FAX - just create a route and define where you want it to go.

Greg

You would only need a seperate extension if you were handing off processing to another device like HylaFAX - If you are going to use the built-in FAX reception features of Trixbox, then a single extension will do it - in the inbound route, the settings for a DID that received FAX would be as follows:

system
e-mail address
NVFax detection
6 seconds of detection.

And then the destination of the Inbound route would be the extension - this will let any DID check for FAX, receive it if it is there, or ring the extension if it is not.

Greg

What's this about the built-in fax capabilities? We've not seen anything about that ever? We know that you need nvfax for detect etc, and hylafax to intercept but you're saying asterisk has faxing built in? We'd love to know more about this if you can.

Mike

Asterisk 1.4 (in Trixbox) needs Newman Telecom's NVFAX Detection, the SpanDSP libraries, and FreePBX - all of these parts are included in any off-the-shelf Trixbox, and it will receive FAXes and send them to your E-Mail as a PDF - it has had this feature for as long as I have been using Trixbox (Trixbox 1.2.3 was the first I used).

Asterisk 1.6 still needs the SpanDSP libraries, but does not need the Newman stuff. Also, FAX in 1.6 is licensed on a Per-Port basis (simultaneous usage) for around $40.00/Port.

The implementation in 1.4 on Trixbox is totally free, but sending is a little challenging - receive works great.

As to Kelly's question, I usually see the errors you are seeing when the SpanDSP libraries get out of sync with the version of Asterisk/Zaptel you are using - Since I am unwilling to use the forked version of FreePBX, all our installs are based on the 2.6.0.7 .iso, yummed up to current (except the forked FreePBX) and then it get's interesting.

First, you must install gcc, gcc-c++, kernel-devel, and kernel-headers. After this is done, you need to make two symbolic links in /usr/src - linux and linux26 which should both be links to:
/usr/src/kernels/2.6.18-128.1.10.el5-i686.

Since it is compiled for another version of Asterisk, and I don't think they work very well anyway, we remove Oslec* and the module trixbox get's removed along with it - don't worry, you don't need it, so:

yum remove oslec*

We then compile the latest version of Zaptel (1.4.12.1), LibPRI (1.4.10), Asterisk (1.4.25.1), Asterisk-Addons (1.4.8).

Then it get's trickey - you need a MUCH more current version of SpanDSP (0.0.6pre12) - compile that from source.

Then you need the most current version of the agx-ast-addons (currently 1.4.24.3) but before you can compile that, you need to install cmake - current version for that is 2.6.4.

Finally, after you have compiled everything, you need to remove app_rxfax.so and app_txfax.so from the modules directory - they have been replaced by app_fax.so, and if they are there, Asterisk won't start.

It seems like a lot to go through, but honestly it only takes about 15 minutes and then you are in business - we HAD to move to the current version of Asterisk 1.4 because of DTMF issues with SIP trunking.

And yes, the Current version of Asterisk 1.4 WILL still work with Zaptel - don't believe what you read, it will compile against either one.

If this seems like too much, you might want to look as the newer Trixbox version, or perhaps even Elastix - we will not use the forked FreePBX and right now we are stuck with Asterisk 1.4 because i9 won't update iSymphony to be compatible with Asterisk 1.6 - we are stuck in several ways.

Kelly, I don't know what version of Trixbox you are using, nor which patches/updates you have applied but I have seen your symptom before and our solution is to compile from source - I know that most people don't like to go that way, but for us, it works.

Greg

you make sure that ECM is turned off - strangely enough, Error Correcting Mode is what causes errors on an ATA served on a PRI - as long as your turn off ECM you should be fine - even G3 seems to work fine - just ECM=NO.

You can also send out with Trixbox, but this involves creating a call file that references a .tiff file - I have played with a few implementations that sorta worked sometimes, but none that ever worked 100%.

If you have a Small Business Server, you can throw a Modem in it and give Outbound FAX to everybody - there are still several FAX softwares out there, that when coupled with a Modem hooked to an ATA would work fine.

Greg

Thanks Greg! I (and everyone else, I'm sure) appreciate the experience you bring to this forum. Your posts are always helpful and insightful. Have a great Friday!

Will

Scott - ATA's have to be stable and on the LAN - Yes, that has been our experience also - so much so that we won't even try a remote ATA deployment for FAXing - it's just not reliable!

Andrew - You could use any version that had Asterisk 1.4 in it, but beyond 2.6.0.7, they all have the forked FreePBX in them - there are instructions for removing it and restoring the non-forked version, and I have tried it and it seemed to work, but I haven't installed one anywhere to be sure over time - I have never used 2.6.2.2 - we have been using 2.6.0.7 since last year, and although the prep time is somewhat more, the results are consistent.

If you don't care about the forked FreePBX, then you might want to experiment with the latest-and-greatest trixbox - the FAX support in Asterisk 1.6 is finally supported and approved by the Digium crew, so I think your results would be consistent, and if you have problems, the Asterisk/Digium developer community would help - they don't work on FAXing at all with the 1.4 tree - that has fallen to Antonio Gallo with the agx-ast-addons project (here: http://sourceforge.net/projects/agx-ast-addons/) and he has done a great job. If you do decide to go the compiling route, make sure you check out the subversion tree to compile from - his posted downloads are out of date.

Greg

P.S. - I am working on a howto to bring 2.6.0.7 up to date with all the patches and updates and then to compile to current Zaptel/LibPRI/Asterisk/Addons/SpanDSP/AGX-AST-Addons for my employee's use in prepping a box - compiling is discouraged by the trixbox folks, but I will post it when it is ready - It's not for everybody, but if you need it, you REALLY need it!