T.38 forbidden by my ISP?


My ISP (SIPproviderA) also gives me 2 phone numbers via VoIP.
One ends with 2 and the other with 3.
My asterisk server ( - it is behind a NAT and a SIP-ALG) registered both numbers with SIPproviderA.
I try to use the computer, that also runs the asterisk server, for simulating two fax machines at phone2 and phone3.

When I try to send a fax in T.38 mode from phone3 to phone2:

  1. my asterisk server sends an INVITE packet (from phone3 to phone2).
  2. then there is some traffic that looks ok…
  3. then my asterisk server sends another INVITE packet (from phone2 to phone3) (this seems to be the “re-invite” that the people talk about so often).
  4. then my provider sends “SIP/2.0 403 Forbidden”

allow = !all,ulaw,alaw,gsm
canreinvite = yes
directmedia = no
faxdetect = yes
t38pt_udptl = yes,fec,maxdatagram=400
insecure = port,invite

same => n,ReceiveFax(${JOBFN}.ongoing,dfs)
same => n,SendFax(${TIFF},dfs)

how can i use T.38?
(that other fax mode (G.711?) is somewhat unreliable…
about 25% of the transmissions fail… or even 50%…)

why does asterisk send the keepalive packet multiple times in the same second to the same SIP server?
is it because the keepalive packets r sent per peer and not per UDP connection (i mean: the peers share the same UDP connection)?



appendix: tcpdump and some log messages

What are you trying to do here? The first is the deprecated name for the second, so you can’t set them to different values (the last one will win).

If the ITSP doesn’t support T.38, don’t route the call through them.

You have removed too much from your configuration, above.

It is generally advised that SIP-ALG should be disabled when using Asterisk.

i just disabled SIP-ALG in my router, that has the WAN leg…

then i changed the sip.conf:
alwaysauthreject = yes
directmedia = no
directrtpsetup = no
;canreinvite = yes

now it can do T.38 faxes via that that sip server of SIPproviderA… no more “Forbidden” on that second INVITE…

thx a lot… :slight_smile:

should i open another thread regarding the burst of keepalive packets?
or is it not worth thinking about it, because: the impact is so low?