Issues with t38 fax machine

We are running FreePBX and Asterisk 13.30.0 with spandsp 0.0.6, IAXmodem, Hylafax+ 7.0.0 and Faxpro 13.0.44 on CentOS 6. Long time running machine that does well on iaxmodem/hylafax.

The client wants to eliminate POTS and so added fax boards to their Canon Imagerunner MFP. Setup seems easy enough and it will send a few pages fine but when it comes to 30 page documents, it’s rare to get past 20. I’ve checked the bandwidth, latency and jitter which all well within specs required. Things are so bad I installed a SPA112 and while it does better, it trains down to 12000 baud before it reliably sends data. note the canon fax board is pretty bad and trains down to 4800 most of the time.

I’ve changed the error correction from redundant, fec, and adjusted maxdatagrams trying to find a difference and/or sweet spot, no luck. The vendor got a Canon tech online and proceeded to spend 8 hours “testing” faxes in and out. They found the same thing I’ve been telling them all along. The SPA appears to work better than the Canon Fax Board. Big help!

The last test I performed was to connect an SPA112 to the switch the FreePBX box is running on and viola, it ran perfect with 14400 connects and fast page transfers. So it appears the switch network is faulty somewhere, somehow. I don’t manage that part but they tell me they have prioritized for VoIP… it seems pretty obvious to me.

My question is when you have a “perfect” path, latency under 1ms, zero jitter and 124Mb bandwidth (iperf), can the switch interfere that much? There are four hops between the FreePBX and the problem printer.

When you run a fax through the spa112 does it actually show a t.38 call or is it doing g711? Whats the t.38 redudancy level set to on the spa112. As well as the jitter buffer adjust and level settings.

What are your ping and jitter levels. As well as like a max ping vs min. Try running WinMtr for 20 minutes straight to replicate a 30 page fax.

4 hops? Meaning 4 switches or do you mean routers?

Honestly I run spa’s all the time over public Internet without issues.

How does the ata/fax machine combo perform when connecting straight to the t38 provider, bypassing asterisk?


fax show sessions shows the call is in gateway mode:

Channel                        Tech       FAXID      Type  Operation  State           File(s)
SIP/242-0000022c               Spandsp    135        none  gateway    Active

Here are the changes for the SPA

Network Jitter Level: Very High
Call Waiting Serv: No
Three Way Conf Serv: No
Three Way Call Serv:  No
Prefered Codec: G711u
FAX Enable T38: Yes
FAX T38 Redundancy: 1
FAX Passtru method: ReINVITE
Silence Supp: Disable
Echo Cancel: Disable
FAX Enable T38: Yes
FAX Tone Detect Mode: caller or callee

Here’s the output from mtr run for 20 minutes in report mode…

HOST: vz200                       Loss% Drop   Best   Avg  Wrst  StDev  Javg Jmax Jint
  1.                   0.2%    2    0.4   2.1 210.5   11.4   3.6 210. 34.1
  2.                 0.1%    1    0.1   0.1   1.2    0.1   0.1  1.1  1.6
  3.                 0.0%    0    0.6   1.4  23.7    2.0   1.6 22.4 18.6
  4.                 0.0%    0    2.3   6.1  80.6    8.8   5.1 77.9 76.8

Hop 1 is a Cisco switch, hop 2 is a centos 5 linux router, hop3 is a pfsense box and hop 4 is the spa112.

dicko, we don’t have a provider. just trying to get these canon t38 fax boards to talk. The SPA was installed to test a known good device for comparison. It works better but still not reliable.

Also here’s the fax stat

FAX Statistics:

Current Sessions     : 3
Reserved Sessions    : 0
Transmit Attempts    : 0
Receive Attempts     : 200
Completed FAXes      : 198
Failed FAXes         : 44

Spandsp G.711
Success              : 154
Switched to T.38     : 0
Call Dropped         : 13
No FAX               : 0
Negotiation Failed   : 0
Train Failure        : 0
Retries Exceeded     : 7
Protocol Error       : 1
TX Protocol Error    : 0
RX Protocol Error    : 23
File Error           : 0
Memory Error         : 0
Unknown Error        : 0

Spandsp T.38
Success              : 0
Call Dropped         : 0
No FAX               : 0
Negotiation Failed   : 0
Train Failure        : 0
Retries Exceeded     : 0
Protocol Error       : 0
TX Protocol Error    : 0
RX Protocol Error    : 0
File Error           : 0
Memory Error         : 0
Unknown Error        : 0

It doesnt look like youre using t38 at all. If its in gateway mode, it means t.38 is not being passed through on both ends.

ata settings should be callee only, extemely high, jitter adjust no, redundancy 3.

What ports do you have open for your udptl?

Any type of packet loss like that will screw up a G711 call. If your udptl ports arent open through the firewall t38 will not work only g711. What speed is the fax machine set to? T38 only works with 14400 and lower.

Yes, the packet loss is a problem and I wondered if t.38 was working at all. In the logs I see T.30 packets followed by T.38 but as this is all new to me I’m not sure what I’m looking for. I’d expect the fax stat to show t.38 calls yet only g.711 is listed. The funny thing is BOTH the canon fax board and the ata do the same thing, no t.38 session is listed in fax stat.

udptl_custom.conf is setup with udptlstart=4000 and udptlend=4999. No firewall in the way

Here’s an excerpt of the log

<--- SIP read from UDP: --->

SIP/2.0 200 OK
Via: SIP/2.0/UDP;branch=z9hG4bK2676cab7
Call-ID: [email protected]
From: sip:[email protected];tag=as1dd6a599
To: sip:[email protected];tag=1742323444
CSeq: 102 INVITE
Contact: sip:
Require: timer
Supported: timer,100rel
Session-Expires: 300;refresher=uac
Content-Type: application/sdp
Content-Length: 296

o=- 251853569 251853570 IN IP4
c=IN IP4
t=0 0
m=image 49152 udptl t38
a=T38VendorInfo:0 0 17
[2020-01-16 23:20:58] VERBOSE[11742] chan_sip.c: — (13 headers 13 lines) —
[2020-01-16 23:20:58] VERBOSE[11742][C-00000001] chan_sip.c: Got T.38 offer in SDP in dialog [email protected]
[2020-01-16 23:20:58] VERBOSE[11742][C-00000001] chan_sip.c: Capabilities: us - (ulaw), peer - audio=(nothing)/video=(nothing)/text=(nothing), combined - (nothing)
[2020-01-16 23:20:58] VERBOSE[11742][C-00000001] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x0 (nothing), combined - 0x0 (nothing)
[2020-01-16 23:20:58] VERBOSE[11742][C-00000001] chan_sip.c: Got T.38 Re-invite without audio. Keeping RTP active during T.38 session.
[2020-01-16 23:20:58] VERBOSE[11742][C-00000001] chan_sip.c: set_destination: Parsing sip: for address/port to send to
[2020-01-16 23:20:58] VERBOSE[11742][C-00000001] chan_sip.c: set_destination: set destination to
[2020-01-16 23:20:58] VERBOSE[11742][C-00000001] chan_sip.c: Transmitting (no NAT) to

I hope I haven’t missed something obvious … ack!

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