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:
RAN-Deny
TEST NUMBERS
SVC-EmergencyTEST
SBC-Emergency
LCL-7&10digit
TFN-TollFree
LD-11digit
LD-International
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.
Thanks…