T38 Fax Detection Using g729 and Asterisk VoIP Software
Using T.38 termination with Eutelia provider could present a scenario where you can receive faxes using g729, but not being able to receive it, even if you are able to receive it while using alaw. This makes you to start suspecting of your VoIP Software.
It might be the case that the remote endpoint, Eutelia, will need to detect the Fax Tones and send the T.38 ReINVITE to you, they may not have T.38 enabled. If that’s the case, your Asterisk installation will need to detect the Fax Tones so as to make the decision the incoming call is a fax and then switch to the fax extension. For Asterisk to detect the Fax Tones you will need to set faxdetect to either yes or cng, you will also require using alaw or ulaw codec.
It might be suggested that you configure your incoming calls from Eutelia to go directly to the fax receive function whilst having the g729 codec enabled, I expect you will then see T.38 re-invite come from Asterisk.
This sample could possibly work:
sip.conf
preferred_codec_only=no
disallow=all
allow=alaw,g729 ; alaw required for T.30 facsimile if T.38 fails to negotiate
faxdetect=no
t38pt_udptl=yes,redundancy,maxdatagram=400
[eutelia]
language=it
type=peer
host=voip.eutelia.it
username=my-eutelia-number
fromuser=my-eutelia-number
secret=my-secret
qualify=yes ;ping per controllo stato
directmedia=no ;asterisk viene sempre usato come media proxy
dtmfmode=auto
insecure=invite,port
context=eutelia-in
callbackextension=s
faxdetect=yes
t38pt_udptl=yes,redundancy
maxdatagram=400
N.B. callbackextension is used in the peer config rather than register in the general section.
I use extensions.ael rather than the .conf version hence I would use something like this
The point is simple, fax tone detection and T.30 signalling will require a high bandwidth codec, g729 will not work, there are plenty of articles out there on this. Having the g729 codec allows you to have it in your handset configuration as the only codec and thus your voice conversations will use the lower bandwidth codec.
T.38 bandwidth consumption has been observed at around 5Kbps and 10Kbps, a g711a voice conversation consumes around 10Kbps bandwidth with a packetisation time of 20ms.
Another option to reduce the amount of data traversing the internet is to enable VAD, it appears as though this may now work in Asterisk 1.8.
As Kevin P. Fleming puts it: ” ‘Be strict in what you send, and liberal in what you accept.‘ It’s there to compensate for calling endpoints that do initiate the switch to T.38 even though that’s not the recommended behavior.
And after spending a couple of years working on T.38, yes, I am sure. It is the receiver’s responsibility to switch to T.38 because only the receiver can determine whether a FAX terminal has answered the call. If the sender switches to T.38 based on CNG detection, the session could switch to T.38 when it was answered by a person, or even before the call has been answered.”
For a a comprehensive resource that confronts the need for information on transporting alternative, non-voice communications over the IP protocol, you might consider reading the following resource:
It begins with the basic theory and operation of fax, modem, and text telephony, then educates you on all of the current transport options that are available in order to tune your pbx phone system.
This article has been composed from the feedbacks of Larry Moore (lmoore@DELETE_MEstarwon.com.au) and Kevin P. Fleming, at the Asterisk Users mailing list.