T38 State Values
Hello,
We have a problem where one fax ATA connected to Asterisk works, and another ATA with the same model and firmware does not. Both are configured to use T38.
Basically the call comes in to Asterisk which then does a Dial to the ATA
that’s registered via SIP, and once that’s set up then there’s a re-INVITE
from the ATA to switch to T38. The ATA sends a “t30ind: no-signal” after the 200 OK, and both work up until this point. But then in the working scenario Asterisk sends a “t30ind: cng” back to the ATA, and in the not-working scenario Asterisk does not send any T38 data at all.
We’ve noticed that in the working scenario when the 200 OK is sent from Asterisk to the ATA, Asterisk logs:
[Mar 17 16:07:50] DEBUG[53838][C-0013e292] chan_sip.c: T38 state changed to
2 on channel SIP/xx.xx.246.70:5060-0030dde1
[Mar 17 16:07:50] DEBUG[6862][C-0013e292] chan_sip.c: T38 state changed to
1 on channel SIP/product-local-bw70-0030ddd9
Whereas in the not working scenario it logs:
[Mar 17 16:23:05] DEBUG[53838][C-0013e39a] chan_sip.c: T38 state changed to
3 on channel SIP/product-local-bw70-0030e0a0
[Mar 17 16:23:05] DEBUG[24973][C-0013e39a] chan_sip.c: T38 state changed to
3 on channel SIP/xx.xx.246.70:5060-0030e0a1
Notice the difference in the “T38 state changed to” values. Does anyone know what a value of 1, 2, or 3 means? I tried to find out from the Asterisk source code but it wasn’t obvious.
Thank you in advance for any tips.
4 thoughts on - T38 State Values
The states you are referring to are chan_sip specific. They are defined here[1].
0 = Disabled
1 = We’ve sent a reinvite to switch to T.38
2 = They’ve sent a reinvite to switch to T38
3 = T38 was negotiated and is active
4 = T38 negotiation failed/was rejected
[1]
https://github.com/asterisk/asterisk/blob/master/channels/sip/include/sip.h#L662
Hi Joshua,
Thanks very much for that information. I guess in that case the ‘not working’ scenario has a T38 state of ‘T38 was negotiated and is active’, which doesn’t help us find the problem much.
In this case the T38 is passthrough, and in the not working scenario in a PCAP we see:
PSTN -> Asterisk: ‘t30ind: cng’ packet is received Asterisk -> ATA: ‘t30ind: cng’ is not sent
Would you have any suggestion on what could prevent the ‘t30ind: cng’ being passed through? The Asterisk T38 settings in sip.conf are:
t38pt_udptl = yes t38_udptl = yes t38pt_rtp = no t38pt_tcp = no
Thanks again.
Nope. You could see if increasing the core debug and enabling udptl debug on the console sheds any light, otherwise it’s just digging into things.
Hi Joshua,
Thank you for that. In the end it seems to have been a firewall blocking the UDPTL ports.