FAX Pro required for T38 options for registered SIP extensions

Good afternoon. After reading up on why we were having issues with T38, I discovered that FPBX doesn’t offer those options unless you purchase the FAX pro module (even though I have no interest in the FAX server function).

So, upon purchasing, I was expecting to see some T38 options within a given SIP extension (such as, one used for an ATA tied to a FAX machine). After not being able to find such a field, I read that those options had been moved from the extensions section over to the User Management section…

Upon looking there, I see nothing that pertains to allowing a SIP endpoint to function as a T38 gateway. I only see items on outbound and inbound routes (which I could have achieved simply by adding the appropriate lines to the SIP config fields).

Any thoughts on what I’m missing here? The way everything is worded is that the FAX Pro module gives me the ability to control the per-extension FAX settings to enable T38 (whether that’s actually on the extensions page or user admin page makes no difference to me, as long as the control exists). However, I’ve found nothing in the GUI that functions on a per-extension basis.

What am I missing, on why that control is missing?


This has never been the case. Please post where you believe our documentation states that

“… so that it can be clarified.” is what I’m sure he meant to add to the end of that sentence. If it’s confusing for one person, it bears looking at, but without knowing what section of the vast array of documents and documentation, it would be impossible to find otherwise…

The only per-extension fax setting to ever exist was “t38gateway” and that’s been removed for a long time (as its in the outbound routes now)

Im trying to figure out what other settings would be expected per extension

ecm - R/W Error Correction Mode (ECM) enable with 'yes', disable with 'no'.
error - R/O FAX transmission error code upon failure.
filename - R/O Filename of the first file of the FAX transmission.
filenames - R/O Filenames of all of the files in the FAX transmission (comma separated).
headerinfo - R/W FAX header information.
localstationid - R/W Local Station Identification.
minrate - R/W Minimum transfer rate set before transmission.
maxrate - R/W Maximum transfer rate set before transmission.
modem - R/W Modem type (v17/v27/v29).
gateway - R/W T38 fax gateway, with optional fax activity timeout in seconds (yes[,timeout]/no)
faxdetect - R/W Enable FAX detect with optional timeout in seconds (yes,t38,cng[,timeout]/no)
pages - R/O Number of pages transferred.
rate - R/O Negotiated transmission rate.
remotestationid - R/O Remote Station Identification after transmission.
resolution - R/O Negotiated image resolution after transmission.
sessionid - R/O Session ID of the FAX transmission.
status - R/O Result Status of the FAX transmission.
statusstr - R/O Verbose Result Status of the FAX transmission.
t38timeout - R/W The timeout used for T.38 negotiation.

Out of 19 options only 9 are writable.


Fax Pro Features
Individual inbound fax to e-mail accounts for unlimited users
Outbound faxing capability
< snip >
Ability to configure and manage Asterisk T38 gateway options on each extension and outbound route to take advantage of this feature in Asterisk 10 and newer

and also:

In version 13+ of the PBX GUI, user-level fax options have moved to the User Management module and are no longer found in the Extensions module.

A dedicated FAX device (like an ATA) should have a setting on the device (extension) itself, and all the wording bolded above suggests that’s what I was supposed to have access to with this module. Sadly, there’s no “trial” for a module (that works free for 14 days or something - THAT would be wonderful so you could test before buying).

Andrew, if what you’re saying is true (which I’m sure it is, of course), then now I’ve got to go get a credit back on the two systems I just purchased that module for, as it isn’t going to do for me what I needed it to. :frowning:

I was wanting a simple way to deploy a SIP ATA and have it work reliably on T38 FAX (Passthru just doesn’t reliably cut it).

What I am specifically asking you is what options did you expect to see? As the options I listed above are the only options available and most seem to pertain to when Asterisk is processing a fax (inbound or outbound) not a pass-thru type environment.

If you detail what you are looking for then I’m sure we can actually do something to help you.

Even if I added back “t38gateway” it doesn’t seem like that would be the option that would do it for you. Are you saying that’s all you need?

There is nothing factually wrong with this.

Unfortunately all I can see removed is t38gateway. So if we added this back you would no longer want a credit?

What I am specifically asking you is what options did you expect to see? As the options I listed above are the only options available and most seem to pertain to when Asterisk is processing a fax (inbound or outbound) not a pass-thru type environment.

I was expecting that somewhere in the extension’s settings would be an option for a T38 gateway, which in theory would signify that every call to/from that device is likely a FAX call, and should be handled accordingly (whether that be from another ATA, an inbound trunk, or outbound call). I understand the idea of doing it at the DID level (for inbound), but find that a bit cumbersome if you need the capability between extensions (as you wouldn’t have an easy way to achieve that). On the outbound side, my dislike of requiring dedicated outbound route patterns may be caused by a combination of how we deploy the system, and a lack of understanding of the possible implications of a device-level setting for FAX Gateway.

The way we deploy systems has us creating (essentially) 8 dedicated outbound routes:

With the extension routes module, we basically checkbox which routes a user is allowed to call, thus creating a mimic of an old PBX term called FRL (Facility Restriction Level). By having to assign the FAX gateway elements to the outbound routes, in theory that would mean I’d have to duplicate 4-5 of those outbound routes to again create the restriction levels for FAX, and then I’d also have to worry about a user getting confused about assigning non-FAX routes to a FAX device. To me, it was simply easier to checkbox an extension and say “hey, this is a FAX device, so treat wherever it calls as such”.

Now, there’s a part of me that simply says I could turn on FAX Gateway for all existing routes, but there’s another part of me (and this is that lack of understanding I spoke of a few paragraphs back) that thinks doing so may screw me because media may always want to be anchored at the server, always listening for the CNG tones - if so, then yeah, dedicated routes make sense in the current software design and I would have to duplicate the FAX-relevant routes.

In all honesty, I understand and appreciate the power of the FAX Pro module, but it’s main functionality really is the FAX server portion, which our current FAX solution has an important leg up on - we can send emails to it for sending (like [email protected]), which for our deployments is much more important than the web portal (though I love there is an actual web portal as well). My point is, I actually don’t like that the module is required just to turn on the capability for an ATA - but, it is what it is.

What I’ve noticed is that when I program an ATA for T38, calls never complete, they tend to drop at the reinvite (with no audio). When I set the ATA for PassThru, then the audio doesn’t disappear, but FAXes are hit and miss (even to the same number multiple times). My thoguht was, because I didn’t have true T38 support on the extension available as an option to me, that was likely why the ATA being in T38 mode was causing the dead air, so I got the module expecting I’d now have “FAX Gateway” available to me on the SIP extension (based on the documentation I referenced. My ultimate goal is to be able to have reliable FAXing with our Grandstream HT802 ATAs registered to FPBX13, and using a T38-capable carrier, which we just haven’t been able to pull off the “reliable” part as of yet.

Hope this clarifies a bit.


If all you need is the T38 gateway option let’s get it back in for you. I will work on this in a second as I am not sure why it was removed. Probably by mistake.

Does having it on, force anchor the media to always pass through the server? Because, if so, I could see a certain perspective thinking it would be better to dial a special code in order to make a FAX call (calling the outbound route), and when you don’t dial that code, then media can flow direct…

If that’s the case, it might make more sense to do it as a FAX Feature Code (for outbound calls). Just a thought.

Thanks, Andrew - I will be curious to know why it was removed as well, because it may have been a mistake, as you say, or it could have been a shift in callflow design logic.


I reviewed the code and this was removed by mistake. I am working on getting it added back

1 Like

Thanks for the link - so it listens for 10 sec and then removes itself from the path if no FAX found. PERFECT.

Thanks for getting this added back in.

1 Like

faxpro version (edge)

So the old way this was done never supported anything but sip, so now it supports pjsip, sip, iax2 and dahdi (does it work there? dunno)

Normally we wouldn’t prioritize this so quickly but you paid for a feature that is listed in the wiki and documentation and marketing materials that didn’t exist. Oversight on our part. Sorry about that, hope it works for you!

Beautiful!!! Thank you. Installed, and it’s there. I’ll do tests next week.

Thanks so much!!!

Sadly, we’re getting T38 negotiation errors with all “gateway” attempts. If we receive the call using the fax-2-email function, it is received by the system (though it doesn’t email the user). But, attempts to 3 different model ATAs (that all “claim” to support T38) end up failing with T38 negotiation errors. :frowning:

I did a text search in both the extensions.conf and extensions_additional.conf figuring I’d see elements of this:
exten => 1,1,NoOp()
exten => 1,n,Set(FAXOPT(gateway)=yes)
exten => 1,n,Dial(SIP/mypeer,20)

I searched for “(gateway)” specifically and found no match. Found a few “FAXOPT” entries though, so I guess it’s possible it’s based on a variable, but if not, I’m wondering if setting a station to gateway=yes in the GUI isn’t really making the appropriate config change.

Not sure where to go from here…

It’s set at the extension level. So it would be in sip_additional.conf not in the dialplan.

Ah, and sure enough, it’s in there for our test extensions.

So, this may fall more under an asterisk issue on why it’s not working, I take it?

Maybe post a log if you want?? You could also try adding that setting right in the dialplan through extensions_additional.conf and then do dialplan reload (or core reload) from Asterisk. If you find the right combination then let me know?

Honestly, I’m not sure I’d know which log to post. I could turn on SIP Debug messaging, or just grab a scrape from a verbose output from the asterisk console during a call setup attempt… Lol . Not sure if the asterisk console ends up writing to a file or if it’s only a cut/paste option.

It usually writes to /var/log/asterisk/full