Poor FXS support for FAX in 3cx, provisioning Grandstream ht802 leaves much to be desired

[LariFari]

3cx version: 16.0.3.676 on premise in a hyper-v vm
FXS Grandstream ht802 firmware: 1.0.13.7
Provider: deutsche telekom, sip-trunk ngn
FXS resides in the same local subnet as the 3cx server

Goals:

1. Use codecs G722, ALAW, ULAW, G729 in this order for voice extensions internally and externally
2. Use only ALAW for FAX device connected to HT802 (would like to allow G722,ULAW too)
3. Don't allow transcoding on any FAX connection
4. no T.38, since nobody seems to be offering T.38

Problems:

1. incoming FAX calls often fail after about 10 seconds
2. sometimes the calls take longer, but in the end no fax is received, about a quarter of all fax calls lead to successfull fax reception.
3. in the 3cx FXS configuration of the HT802 i can add ALAW, ULAW, G729 but not G722. (why?)
4. 3cx doesn't reveal which codec is chosen, or if transcoding takes place, no matter what debugging level - we're still forced to do a full network trace in .pcap format just to hunt down codec selection problems!
5. a FAX extension is defined and the HT802 provisioned with the template file from 3cx but at a closer look many settings in the HT802 are not at all optimized for FAX:

5.a) jitter buffer is set to dynamic whereas it seems wise to use a static jitter buffer for fax (Changing it manually to static and big does work a lot better)
5.b) LEC and Echo Cancellation are enabled (why?)
5.c) Codec list still contains unwanted codecs (why?)

1. 5.c) occasionally making the 3cx transcode fax calls eg. from ALAW to G722, which I only found out using wireshark. The 3cx logs are useless!
2. HT802 dial/free/busy tones and SLIC settings just stay at ther default, instead of beeing provisioned according to the locale.

@3cx: Please add codec selection debugging to the logs, improve the FXS / FAX extension provisioning mechanism, make it clear, which codec will be selected when, and positively suppress transcoding on fax calls!

 

[leejor]

Why are you trying Codecs other than G711?

Came across this in regards to Deutsche-Telekom and faxing...

https://service.swyx.net/hc/en-gb/a...Telekom-SIP-Trunk-and-SIP-Trunk-Pure-Germany-

Scroll down to the Fax part.

 

[eddv123]

no T.38, since nobody seems to be offering T.38

I am going to assume since you are using Deutsche-Telekom you are German based:
https://www.3cx.com/partners/sip-trunks/deutschland/

This list gives all German based 3CX supported providers and what method of FAX they support, can see plenty of T.38 support.

 

[LariFari]

@eddv123: Perhaps since many providers (including Deutsche Telekom) discouraged or made it impossible to use T.38 in the past, and it's still debated (even in this forum), whether Telekom SIP Trunk does accept T.38 Re-Invites, I could see T.38 being offered only in a very small amount of FAX calls and call cancellation upon T.38 re-invites.

So we have to rely on G.711(a).

According to their website, 3cx wouldn't touch RTP streams, when both call-legs were external.

But we have 3cx installed locally on premise sitting in the same local ipv4 subnet with the ht802 SIP ATA. And in this very setting I caught 3cx not only routing all RTP streams, which might increase timing glitches, but even transcoding about half of all incoming FAX calls, which led to a far too high amount of transmissions getting cancelled after a random time, possibly due to encoding artefacts or timing issues.

What I still would like to know is:

How can I force 3cx to not transcode FAX transmission? Even better, how can I force 3cx to not route RTP to internal clients?
And how can I make 3cx build a grandstream ht802 provisioning file that reliably restricts FAX codecs to a sane choice and uses FAX-optimized settings for other options too?

After many hours of testing and reading wireshark logs, it seems to me, that neither of them is possible in 3cx Version 16.0.3.

The workaround is to "302" redirect all FAX calls to another trunk that our SIP ATA is directly connected to, completely bypassing the 3cx server. Beware: A "normal" redirect would not only use up two lines but still transcode some connections, thereby causing FAX transmission to fail in most cases.

 

[eddv123]

To confirm as there are a few different meanings for transcoding but I assume possibly that you mean compress the media ? https://www.wowza.com/blog/what-is-transcoding-and-why-its-critical-for-streaming

If so then with G711 for FAX it wont be, compression only occurs for codecs such as G729 or iLBC, if compression is occurring make sure it is not set on your SIP trunk. With that being said however, let me know if you mean something else here.

Funnily enough, I have just finished a guide this week for full FAX (in/outbound) solution with 3CX, Twilio and a Patton FXS gateway. This covers G711 Pass-through FAX (since the SIP Trunking provider doesn't support T.38 either). It needs a bit of tidying still, but it will show you the setup and hopefully assist perhaps.

 

[LariFari]

Hi eddv123,

thanks for sharing your guide! It's really nice, I like how it's made! In my case the 3cx is set up locally, not cloud based. So this might cause the difference in handling rtp streams.
BTW: Didn't know that patton gateways have these nice debug capabilities. I've been using cheap grandstream ht80x so far, because the (to me) even more outdated looking patton web-interface was quite a deterrent, when I had to set it up one time.

 

[LariFari]

To confirm as there are a few different meanings for transcoding but I assume possibly that you mean compress the media ? https://www.wowza.com/blog/what-is-transcoding-and-why-its-critical-for-streaming

If so then with G711 for FAX it wont be, compression only occurs for codecs such as G729 or iLBC, if compression is occurring make sure it is not set on your SIP trunk. With that being said however, let me know if you mean something else here.

Funnily enough, I have just finished a guide this week for full FAX (in/outbound) solution with 3CX, Twilio and a Patton FXS gateway. This covers G711 Pass-through FAX (since the SIP Trunking provider doesn't support T.38 either). It needs a bit of tidying still, but it will show you the setup and hopefully assist perhaps.

I mean transcoding in the same sense as described in the wowza blog, "decompressing (decoding) it; and then somehow altering and recompressing". Eg. like in decode from G.711u then encode to G.722. It took some wireshark captures to find out that the locally installed 3cx indeed messes with the rtp data even when it should "know" that this is meant to be a fax transfer.
Juggling around with limiting codec choice and changing codec priority in four places (3cx settings, 3cx trunk settings, 3cx fax extension settings, manually changing ht802 settings) seemed to make no difference. And I don't want to ban G.722 for other extensions.

 

[eddv123]

Local should be as good if not better than VPN. Interesting point about the audio streams as the FXS/DECT section or FAX extension do not have a "PBX delivers audio" setting, the trunk does but this is normally on by default.

The Pattons are fantastic if you know the command line settings, I much prefer paying the little extra money for the extra functionality you get.

So as a test, if you set your PBX codecs, local extensions, trunk and ATA/Gateway to G711 what happens ? if you run the wireshark capture from the PBX also feel free to PM it to me.