SIP RE-INVITE - T.38 Issues

[xehqter]

I'm using t38fax.com to terminate faxes (using T.38 not G.711) using an HT812 (Grandstream), SPA112 (Cisco) and FSP 2.4 (Software T.38 Fax integration for Microsoft Fax Services).
They all work perfectly when connecting to their server (sip.t38fax.com) directly. However if I put 3cx in the mix everything goes south fast.

Using 3CX would be ideal as my client would only need to pay for 1 sip trunk and it would streamline the whole setup beautifully.

When I use Wireshark I'm noticing that 3CX isn't issuing a Re-Invite to hand off the call to t38fax directly but is instead doing a G.711 pass-through (RTP traffic is being delivered through 3CX as G.711 to the ATA) which I believe is whats causing all the instability with faxing (They frequently fax and receive 50+ page documents at a time).

The ATAs are configured per all documentation I can find on the internet (3cx and t38fax.com)
In 3CX the ATAs are Authenticated via Advanced -> Fax and detected.
Enable G.711 to T.38 Fallback [BETA] is DISABLED in Settings -> Fax Server
In SIP Trunks I've tried Enabling / Disabling Supports Re-Invite & PBX Delivers Audio

We're using 3CX 16.0.676
Am I missing something blatantly obvious here?

 

[Felix Barbier]

I had the same issue before.
Try to change jitter buffer to fixed and try medium if it fails, try to change it to high and one of these option will probably work.

 

[eddv123]

I have had some similar sorts of issues before (not completely identical to yours) but where I have been sending T38 FAX's from 3CX gateway to gateway (at each end) but in all 3 cases where T38 has been sent but then emerges at the other end as either G711 Pass-through or a VoIP call.

In all cases it was the provider related, who is the provider in this case ? and what template on 3CX is being used also.

It assisted me greatly that we use Twilio as our provider and you have a feature on the platform where you can trace their end also.

 

[xehqter]

t38fax.com is the T.38 provider, I'm using SIP Generic w/ SIP RE-Invite Enabled as the template.
VoIP.ms is the telephony provider (using the 3CX provided template)

Ironically their prior fax machine won't receive ANY faxes using an ATA w/ G.711 Pass-Through so it makes for good testing.

The only combination that works is:
t38fax.com -> ata -> old fax

these combinations DON'T work:
t38fax.com -> 3cx -> ata -> old fax
VoIp.ms -> ata -> old fax

I tried https://www.faxback.com/ 's T.38 verification app and FSP (Disabling G.711 Audio Faxing) and they both choke when 3CX enters the mix.

 

[eddv123]

And where is the gateway in regards to the phone system (local/remote) and how is it connected to 3CX ?

This is a guide I wrote for successfully configured FAX with 3CX (G711 Passthrough) however the bit I want you to look at is the baud rate. This can be altered on 3CX and the FAX endpoint maybe worth having a tweak, but please answer the above first as if in STUN or SBC modes this is not good for FAX.

 

[xehqter]

Great Article...

And where is the gateway in regards to the phone system (local/remote) and how is it connected to 3CX ?

The FXS (ATA) is connected directly to the 3CX system (via a Fax Extension) on the same local network which connects to the SIP trunk over open internet (No VPN)

This is a guide I wrote for successfully configured FAX with 3CX (G711 Passthrough)

I'd prefer to avoid using G.711 pass-through and stick with T.38. During my initial testing I found G.711 unreliable, frequent disconnects and compatibility issues with transmitting fax machines were common.

however the bit I want you to look at is the baud rate. This can be altered on 3CX and the FAX endpoint maybe worth having a tweak

Wouldn't 3CX's baud rate setting be for its internal fax to email feature?

Neither fax machine supports altering the baud rate, FSP supports modifying the baud rate for G.711 Over VoIP but lowering it made no difference.

Enabling/Disabling ECM (Error Correction) is the only relevant setting on all the physical and software faxes. Oddly disabling Error Correction over G.711 seemed to decrease disconnects for pass-through.

t38fax.com explicitly says they support ECM and to enable it, so we do, when connecting the ATA directly to them.

I attached a copy of the Outbound T.38 Fax Log from the primary outbound fax machine using a Grandstream HT812 FXS ATA.

Mode (First Group):

EC	G3 w/ Error Correction
G3	G3 wo/ Error Correction

1st Numeric Code

0	2400
1	4800
2	7200
3	9600
4	12000
5	14400
6	V.34

Most of the status codes are errors dialing (no answer, busy, etc), 0xB0 - 0A are Transmission or Handshake errors.. best I can tell 00 are mid fax transmission errors. I can make the assumption that some of the errors are generated on the recipients side as well..

With T.38 most of the faxes are negotiated at V.34 or 14.4 (Faster Faxing = Less Minutes) Fewer Transmission retries = Less Redials, etc.

When I use G.711 Pass-Through almost every fax has a transmission error, some to the extent where after 6 retries it fails the fax which is why I'm really trying to avoid using Pass-Through and have 3CX hand off the T.38 call to t38fax.com instead of doing G.711 Pass-Through at all.

On the receiving end G.711 Pass-Through via 3CX just isn't an option, 50% of the faxes are dropped and we get weird transmission errors (eg: only the cover page will be received from certain fax numbers).