488 Not Acceptable Here for Inbound Fax

[kevinm207 (Kevin)]

This FreePBX instance has been running in production for over 3 years (FreePBX 15, Asterisk 16). It’s for a doctor’s office that receives a LOT of faxes. I recently changed the SIP trunk provider, and it may simply be a coincidence, but there is one particular sender who is getting a “488 Not Acceptable” from FreePBX when trying to send a fax to the clinic. Seems like all other inbound faxes through the same trunk to the same inbound route are working fine.

For clarity, I do NOT have T.38 pass-through enabled. I have the following codecs enabled in the following order on the trunk: ulaw, alaw, gsm, g726, g722, h264, mpeg4. I’m unable to find the particular failed call in the call logs for some reason; not sure what I’m doing wrong there. The only way I knew what the response from FreePBX was by reaching out to the trunk provider and asking them to check the logs on their side.

If they are sending the fax using T.38, and I don’t have T.38 pass-through enabled, could that be the cause of the issue? Would I benefit in anyway in enabling T.38 on the system? I only have the one trunk, with all of the DIDs (voice and fax alike) connected to the same trunk, so if I was to enable T.38 on this trunk, will that cause any issues?

Also, just for clarity, I’m only using PJSIP, I’m not using ChanSIP for anything.

Thanks for any help!

[comtech]

Providing Great Debug - Support Services - Documentation (freepbx.org)

if you can’t find the call, ask them to submit another fax.

[billsimon]

Any sender that initiates T.38 with you should fall back to G.711 if you give a 488 Not Acceptable response to their invite. Only ulaw and alaw codecs, which are in your list, are suitable for faxing.

If you are willing to post the SIP trace you got from the provider, that would help us evaluate.

Chances are low that you will see many end-to-end T.38 calls across the PSTN; for that reason, I do not enable T.38 on trunks.