Debugging T.38 Issues

Home » Asterisk Users » Debugging T.38 Issues
Asterisk Users 2 Comments

Hello list,

We’re currently facing some issues concerning T.38 gateway faxing. This is a device used almost exclusively for receiving faxes. Calls are incoming to asterisk on a SIP trunk (sangoma netborder) using G711A. Gateway mode is activated in the asterisk dialplan towards a Cisco SPA 112 running firmware 1.3.5. We are using asterisk 1.8.13.0
with the T.38 gateway patch applied (I know I know, we should move to asterisk 11. I’m trying that tonight after business hours).

The issue we’re seeing is that faxes incoming from some specific fax machines consistenly fail. I have indentified 2 types of failures:
– Incoming call is sent to SPA112, reinvite to T.38 is initiated and accepted. One T.38 packet is sent from the SPA112 to asterisk
(t30ind: no-signal, see pcap output below) followed by 20 seconds of nothingness and then the call is hung up.
– Incoming call is sent to SPA112, reinvite to T.38 is initiated and accepted. A number of T.38 packets is sent from the SPA112 to asterisk
(it repeats NSF,CSI,DIS signals 3 times) followed ba call hangup.

In none of the above 2 cases do I see T.38 packets flowing from asterisk to the SPA112.

In the logs I see these things that indicate T.38 gateway being started:
[Oct 14 14:16:17] DEBUG[11426] res_fax.c: SIP/SDSD0005-0007cb05 is attempting to negotiate T.38 but SIP/SOV20001-0007cb04 does not support it
[Oct 14 14:16:17] DEBUG[11426] res_fax.c: starting T.38 gateway for T.38 channel SIP/SDSD0005-0007cb05 and G.711 channel SIP/SOV20001-0007cb04
[Oct 14 14:16:17] DEBUG[11426] res_fax.c: Requesting a new FAX session from ‘Spandsp FAX Driver’.
[Oct 14 14:16:17] DEBUG[11426] res_fax.c: channel
‘SIP/SOV20001-0007cb04’ using FAX session ‘660’
[Oct 14 14:16:17] DEBUG[11426] chan_sip.c: T38 state changed to 3 on channel SIP/SDSD0005-0007cb05

PCAP text output of 1st case:
216.025063 192.168.196.3 -> 192.168.196.94 RTP PT=ITU-T G.711 PCMA, SSRC=0x6118CC28, SeqH77, Time79871936
216.042133 192.168.196.94 -> 192.168.196.3 RTP PT=ITU-T G.711 PCMA, SSRC=0x205734A, Seq

2 thoughts on - Debugging T.38 Issues

  • It’s been a while since I played with a Cisco SPA8800 with T.38 and with incoming faxes. There were settings in the SIP configurations for the SPA8800 to get it working with T.38 with asterisk, I don’t know if the same will apply for this device.

    If memory serves me you don’t need, or perhaps, shouldn’t use the T.38
    Gateway feature for the incoming call unless you are expecting your endpoint to be running T.30, in your case the SPA-112.

    A quick glance over the data sheet for this device suggests it supports T.38 thus providing you have T.38 enabled on the SPA-211 I would advise against attempting to use the gateway feature for the incoming call.

    In my experience Cisco use UDP redundancy and the default value is 1, you may want to experiment with this value and set it to 3. You may want to adjust the values in asterisk’s udptl.conf by setting udptlfecentries
    & udptlfecspan to the same value, don’t forget to restart asterisk after the change, I can’t remember if you can force an unload and reload of the udptl module in asterisk.

    You have not provided any information relating to the SPA-112’s configuration in sip.conf so here are some settings I have;

    [9003]
    ; Cisco SPA8800 FXS Port 3
    ; Analogue FAX Modem attached type=friend call-limit=2
    qualify=yes canreinvite=no
    ;directmedia=no host=dynamic context