FAXing with T.38 Trunk

I have an ATA attached to a fax machine that I’m not able to reliably send or receive T.38 faxes with. The trunks (Broadvox) are configured for T.38 and so is the ATA (Linksys SPA3102).

Here is the environment:
AsteriskNOW 1.7.1

Here is the layout of the network:
Broadvox --> WAN --> Firewall (NAT) --> ATA --> FAX Machine

I have verified by taking captures that the transmission switches over to T.38 but most attempts result in a hangup around 30 seconds into the call.

There are a variety of issues found in the Asterisk logs (included below) but in the research I’ve done I haven’t found any resolution.

Can anyone help point me in the right direction?

WARNING[5836] udptl.c: (SIP/4232879579): UDPTL asked to send 41 bytes of IFP when far end only prepared to accept 38 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration.

WARNING[22599] rtp.c: RTP Read too short [Mar 24 14:44:58] WARNING[22599] rtp.c: RTP Read too short [Mar 24 14:44:58] WARNING[22599] rtp.c: RTP Read too short [Mar 24 14:44:58] WARNING[22599] rtp.c: RTP Read too short [Mar 24 14:45:04] WARNING[22599] rtp.c: RTP Read too short

WARNING[24064] udptl.c: T38FaxUdpEC in udptl.conf is no longer supported; use the t38pt_udptl configuration option in sip.conf instead.

WARNING[24064] udptl.c: T38FaxMaxDatagram in udptl.conf is no longer supported; value is now supplied by T.38 applications.

I suggest you ask this in the Asterisk forums, I doubt anyone here has any expertise in this area.

Hi gatorHeel,

i’m not an expert in T.38 faxing but maybe this can help.

Add a maxdatagram to the t38pt_udptl= parameter in sip_additional_custom.conf like so :


This wil tell the devices the udptl datagram size in bytes, just play with the value until it works, also remember the SPA2102 supports Syslog wich will help alot for debugging T.38 internally in the SPA, see : https://supportforums.cisco.com/docs/DOC-9897

Hope this helps, otherwise maybe on the asterisk forums you have better luck.


Thanks for the suggestions. It appears that the changing “FAX Passthru Method” to “NSE” instead of “ReINVITE” worked (at least with our provider - Broadvox).

Sorry for posting to an old thread, but for nexvortex as a provider, this happens when you try to initiate the call with t.38 directly. They require you to first initiate in G.711u and then renegotiate to t.38 for outbound faxing.