Can I 'force' a SIP trunk to initiate T.38 on inbound call?

Asterisk Asterisk Fax
1

Hi - I’ve been using spandsp for quite some time as a fax solution for Asterisk. Outbound calls are working fine; our upstream SIP/DID provider supports T.38 and I’m really happy with the outcome.

However, we’ve always had some problems with inbound T.38 - seemingly an issue with the path that each DID/incoming call takes within our providers network. Some ranges work fine, others… never.

Our provider has just moved to new infrastructure, and I’m taking this opportunity to move all inbound fax DID’s to a single Asterisk server and a dedicated SIP trunk. It’s 1-2ms away from the SIP provider, and yet so far all inbound faxes are being done as G.711 calls. I asked the provider why, and their answer was:

“Our network doesn’t proactively offer T.38. If your end is configured to initiate a T.38 session once the call is established we will support and use that, otherwise we’ll continue to use G.711.”

My question to the community is, therefore, how can I configure an asterisk trunk to always initiate T.38 once the call is established? The closest thing I can find in the docs is to set a FAXOPT(gateway=yes), but I’m not sure this is correct?

I did a Pcap on an inbound call, and all I saw was our side accepting the SDP offer of ulaw, nothing T.38-specific.

Any clues? Basic configs below:

Connected to Asterisk 13.19.0 currently running on hostname (pid = 1196)
ls01*CLI> fax show capabilities

Registered FAX Technology Modules:

Type : Spandsp
Description : Spandsp FAX Driver
Capabilities : SEND RECEIVE T.38 G.711 GATEWAY

sip.conf:

[inbound-fax]
type=peer
host=sip.hostname.com
username=123456778
fromuser=123456778
secret=ofcourseideletedthis
t38pt_udptl=yes,redundancy,maxdatagram=400
;t38pt_udptl=yes,none,maxdatagram=400
context=inbound
t38pt_rtp=no
t38pt_tcp=no
;faxdetect=t38 - this seemed to have no effect?
qualify=yes
disallow=all
allow=ulaw
;allow=alaw

2

A trunk can’t be forced to initiate it, the application (or other side) has to be configured to request that a switch to T.38 occur. This is because there are attributes provided by what is handling the T.38 frames that is handled during the negotiation.

3

Thanks Joshua for the response. So there’s nothing I can do in, say, the dialplan to help this along?

4

Whatever is handling the channel has to do it. Be it ReceiveFax or the gateway for example (which I believe triggers based on things).

5

Further reading of the docs (and a poke into the res_fax.c source) suggests that while the SendFax() has an option ‘z’ which suggests it is used to send a T.38 reinvite to the remote end (if not already received), the same option isn’t available for ReceiveFax().

There are no other documented FAXOPT/ReceiveFax() options I can find (?) that suggest it would implement something similar.

I’m gradually working through various FAXOPT() settings and looking though packet captures - nothing yet suggests that the Asterisk side is attempting to send a t.38 Reinvite. Freeswitch (also using spandsp libraries) appears to have a configuration option to this - that’ll be my next option (though a pain as I really like Asterisk!)

regards

Mark