Trouble with PJSIP and t38 UDPT to Cisco ATAs

Asterisk Asterisk Support
1

I’m trying to setup T38 Fax re-negotiation. I’ve set the following for my pjsip peers:

t38_udptl = yes
t38_udptl_ec = redundancy
fax_detect = yes
fax_detect_timeout = 30
t38_udptl_nat=no

Everything starts out fine when I place a fax call. It negotiates G711, both sides send/receive packets to the right IP. Then a re-invite happens and T38 is negotiated.

The problem is after T38 negotiation, Asterisk sends packets to the private IP (NAT) address of the ATA, despite having received and send RTP packets previously to the ATA. Furthermore, it’s also received a T38 packet from the ATA, but it persist in sending T38 UDPTL packets to the private 10.x.x.x IP of the ATA, which of course won’t get to it.

I know this is normal behavior of asterisk to “discover” where to send media packets, but it doesn’t seem to work right. It’s as if Asterisk forgets the IP it previously sent packets on when the re-invite happens. It’s doublly strange since my pcap reveals is got a T38 packet from the ATA with the right IP, but seems to ignore that, and sends it to 10.x.x.x anyway.

So I’m at a loss to explain this. This worked a while back when we were using chan_sip, but somehow there’s something miss-confied on Asterisk, or a bug in pjsip.

It’s worth noting that I’ve tried various things, and oddly, by luck, this worked maybe 1/10 times. Why I don’t know.

Tried:

  • Setting t38_udptl_nat=yes
  • Restarting asterisk
  • Reloading pjsip
  • Verifying the above settings took hold (they did)
  • Restarting the ATA
  • Limiting to ONLY setting t38_udptl = yes, no-go.

Nothing seems to work. Of course when I turn off t38_udptl, the fax will work, but only over G711. Anyone have any ideas?

2

RTP is completely separate from UDPTL, and you can’t use the same IP address/port, there’s no guarantee it’ll be the same (and most times it isn’t).

The t38_udptl_nat should have resulted in the source address being used for subsequent packets. I would suggest getting a debug log[1] ensuring that option is set.

[1] Collecting Debug Information - Asterisk Documentation

3

Yup, we’ve got different port assignments for T38, and Asterisk is “doing the right thing” and using the correct ports assigned.

The pcap shows that the ATA sent the T38 packet on a port in the 4000-4999 range, and we allow these ranges through the firewall. So at least I can’t find anything wrong with this piece. I’ve also confirmed Asterisk is listening on that port at the time the call is placed.

I tried turning on debug mode, but all I got was what I saw in the pcap. I tried turning on udptl debug as well. The one thing missing was Asterisk seeing the (single) packet from the ATA in the udptl log. I did see UDPTL from the PSTN side, which works fine.

Is their some other debug mode I can turn on to verify the setting the t38_udptl_nat is taking effect? I didn’t see any way to view this in the debug messages, or in the pjsip show options.

4

There is no other debug, and if it doesn’t appear with udptl debug turned on then it was likely never received by Asterisk, and the NAT support wouldn’t have triggered. If Asterisk doesn’t receive the packet, it can’t switch.

5

My pcap is on the asterisk server itself. So I know the packet got to the server. I can see Asterisk listening.

I’m not sure why it wouldn’t get the packet, unless there’s some sort of timing issue of Asterisk binding to the port, after the packet was sent and received by the OS. Issue seems to be on both Asterisk 16 on CentOS 6, and Asterisk 16 on asterisk 20 on Ubuntu 20.04.

I’m sort of at a loss at this point.

6

If there was a binding issue then it would show up in the pcap. The code itself for reading is extremely simple:

There are some off-nominals you could throw log statements in to see if they’re executing instead, but based on the information you’ve provided I don’t see why they would.

Additionally a pcap occurs before any local firewall rules are applied, which has in the past given the false impression that local firewall is not a problem when it actually was.

7

Yeah, I thought it might be the local firewall, despite their being a rule listed in IPTables that allows the traffic through. I cleared out all the iptable rules via iptables -F, confirmed they were all gone, tried another fax, and got the same results. I’ve also confirmed that IPTables was empty after the call completed.

So I just don’t know what could prevent Asterisk from getting that single T38 packet.

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.