Solved Issues with outgoing FAX to T.38

[apitsos]

Hi there!

I am having an issue with a 3CX installation I just made. I am using Grandstream HT802 and connected an analog FAX device on port #1. I use (voice/normal) extension and not "FAX" extension.

I can receive faxes on this number, but when I am sending, the line is dropped.

I contacted the provider (who supports FAX over PCMA / G.711 A-law codec) and they told me that they see on the logs that my system is not making a re-invite. More specifically they explained to me that I am sending with G.711 A-law codec and the fax on the other side requests to turn it into T.38. My PBX tries and fails. But it's not retries to send it with G.711 codec. I am really not an expert on that field and I am not sure if I explain all these correctly, but this is in a summary what I have understand.

In addition, I have enabled the option "Enable G.711 to T.38 Fallback [BETA]" under FAX Server in 3CX Settings.

I would really appreciate any kind of help, as I have spent already two days trying to solve the problems.

 

[Saqqara]

Have you tried changing the fax sending transmission mode - Step 3 https://www.3cx.com/voip-gateways/grandstream-ht-fxs/

You may have to re provision the HT802 after the change

 

[apitsos]

Hi Saqqara,

Thanks a lot for the tip. I just changed the configuration and reprovisioned the FXS adapter with the xml configuration file. I ran tests again and guess what. Now I can send, but I can't receive!

Any ideas?

 

[Saqqara]

You may have to setup the HT802 with a fax extension - Step 1 in the url.

 

[apitsos]

I just did that. Now I can receive, but I can't send. I can't even place a call.

I checked the Activity Log and I see that:

06/09/2020 1:23:17 PM - [Flow] Target endpoint for 0xxxxxxxxxxx can not be built!

 

[apitsos]

Is there any possibility someone to assist me with that?

 

[YiannisH_3CX]

Hello @apitsos

The error you are now getting may suggest that you do not have an outbound rule that matches the call you are trying to make from the specific extension. Review your outbound rules and try again.

I contacted the provider (who supports FAX over PCMA / G.711 A-law codec) and they told me that they see on the logs that my system is not making a re-invite. More specifically they explained to me that I am sending with G.711 A-law codec and the fax on the other side requests to turn it into T.38. My PBX tries and fails. But it's not retries to send it with G.711 codec. I am really not an expert on that field and I am not sure if I explain all these correctly, but this is in a summary what I have understand.

In addition, I have enabled the option "Enable G.711 to T.38 Fallback [BETA]" under FAX Server in 3CX Settings.

This statement is a bit confusing because you state that your provider supports Fax via G711 but you later state that they expect a re-invite to T.38. So do they support T.38 or not?

How the PBX works in regards to Fax. (short description)

When receiving a Fax you have 2 options, you either set the destination to be the 3CX fax server or you set up an ATA with a fax extension and send it there. The 3CX PBX fax server has 2 options, it will either re-invite to T38 once it receives a call ("Enable G.711 to T.38 Fallback [BETA]" option OFF ) or it will wait for a few seconds and will attempt to detect fax tones through G711 ("Enable G.711 to T.38 Fallback [BETA]" option ON) before re-inviting to T38.
The PBX will not re-invite to G711 after T38 fails as we do not support this functionality.

When choosing the second option you rely on the ATA to handle the communication to the provider and you can set it up to to accept Fax via T.38 or G711. The ATA will re-invite to T.38 once it receives a call if set for T.38 or wait for audio Fax tones when set for G711

When sending a Fax you can only send it via an ATA. In that case it is expected that the provider will send a T38 re-invite (if supported) and the ATA will receive the re-invite and handle it. If the ATA is setup for audio Fax then it should not receive a T38 re-invite as it may cause the Fax transmission to fail. The behaviour mostly depends on the ATA device.

 

[Saqqara]

As stated, you need to make an outbound rule for the fax extension to be able to dial out on the correct sip

https://www.3cx.com/docs/manual/sip-trunks/#h.3evqdta9sabf

 

[apitsos]

Hi @YiannisH_3CX!

I would like to thank you very much for the detailed explanation. Once again your support was great. Your explanation really helped me to understand a few more things. I can say that bringing a FAX to a normal operation is most probably the most difficult thing to configure in a 3CX system.

Finally, we managed to find a configuration that works, but we had to go into the configuration of the FXS adapter (ATA device) and change it after the provisioning. It was really a very strange configuration, because at 3CX we configured the "FAX Transmission mode" of the FXS with the option "Fax in Audio G711(Pass Through)", but within the Grandstream HT802 we configured the FXS port #1 "Fax Mode" as "T.38", with the option "Re-INVITE After Fax Tone Detected" disabled!

With that strange configuration we make our device able to send and receive faxes without errors. We also tested send and receive with simple analog FAX device behind an analog ISDN line and with a 3CX FAX server (for sending) and with a FRITZ!Box software (for receiving). So I believe we ran all the necessary tests in order to make sure that the Faxes will be delivered and received without problems.

The provider, who is "BITel" (local telephony provider in Bielefeld, Germany) supports both G711 and T.38 codecs. But as I said above, making FAX to operate normally seems really hard. And I say that, because we applied to this case (this client) the exactly same hardware, configuration, VoIP provider and setup in general with the one we did a couple of months ago to another client, and nothing worked as expected! Why? Nobody can say... not even the VoIP provider.

I also would like to thank @Saqqara for his help. His tips also made me realize the problems that each protocol was occurring and were also the start of the road trip to the solution.

I would like also to clarify that the outbound rules were correctly configured from the beginning. There was no problem regarding outbound rule not allowing outgoing calls. But it's always good to exclude possible mistakes and your comments and advises are always welcome!

I believe this thread could be closed with the indication of "Solved".