T38 Faxing and T38pt_udptl= values and devices #2

I start here a new T.38 related thread because the original one is closed…

At first, a great thanks to user petersonz for his great information regarding this matter!!

It is really inapprehensible why FreePBX doesn’t create a functional udptl.conf file. Because mine udptl.conf was totally empty I followed user petersonz steps, and copied his entire udptl.conf 1:1 into mine.

The only little problem is that my SIP provider (sipcall in Swiss) uses T.38 with redundancy and not FEC. Therefore I need to modify some parameters. At the moment it looks like:

;
; UDPTL Configuration (UDPTL is one of the transports for T.38)
;
[general]
;
; UDPTL start and UDPTL end configure start and end addresses
;
udptlstart=4000
udptlend=4999
;
; Whether to enable or disable UDP checksums on UDPTL traffic
;
udptlchecksums=no
;
; The error correction type to be sent
;
;T38FaxUdpEC = t38UDPFEC
T38FaxUdpEC = t38UDPRedundancy
;
; The maximum length of a UDPTL packet
;
; The number of error correction entries in a UDPTL packet
;
; udptlfecentries = 3
;
; The span over which parity is calculated for FEC in a UDPTL packet
;
; udptlfecspan = 3

Is it right? Is it correct that I have disabled the udptlfecentries and udptlfecspan values? I think they are FEC related and are not necessary with redundancy. Should I have to replace them with any redundancy related parameter?

Many thanks for any hints!!

Yes, I know, this thread here is old. However, - I found recently (and finally) the effective reason why T.38 doesn’t work (in my case). :disappointed:

It was not my fault, not Asterisk’s fault, and also not FreePBX’s fault. It is the sole fault of my VoIP provider sipcall.ch.

Despite T.38 is stated as “supported”, my provider does simply not support T.38. Their corresponding T.38 gateway has some grave negotiation problems, - the gateway “exceeds the T4 timer of the T.30 protocol”. Therefore, fax calls with T.38 do not work.

So no matter what I do & try, I cannot solve this problem.

I have contacted one more time my provider. Until now, they never give me any helpful hint. They never were able to recognize the root of this T.38 faxing issue. They always recommend as a workaround G.711 VoIP faxing. :confused:

Well, I think this is my last attempt in this matter. I am not really optimistic, - this error seems to be known now for over 6 years (in the mentioned wiki). That’s really a shame, - together I’ve wasted days (if not a week) on that problem. :angry:

It is really frustrating that T.38 makes so often troubles. And in a lot of cases the provider are simply incapable. It seems that they itself don’t understand how T.38 should / must work.

Whatever, what more can be said? Well, if someone want’s to use T.38 it is better the check first if the VoIP provider REALLY supports T.38.

We are now fine with T.37 (fax to e-mail). Unbelievable but true, that one works great! :wink:

Well, - we have now 2019 and I am happy to note here that my FoIP (faxing over IP) is working meanwhile stable and reliable. :smiley:

It looks that my provider Sipcall.ch has resolved their T.38 issues. Furthermore I was able to find out the correct T.38 faxing parameters. And finally I have also discovered a strange “Free Fax For Asterisk” installation bug. Also this problem needed his time to be solved…

So after five years, this story has come finally to an end! :smiley:

More detailed information can be found at the following thread:

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.