Last week I disabled SIP ALG (or “SIP Conntrack”) on my UniFi USG router:
Today I noticed that one of the accounts on my Yealink T42G phone was unregistered.
My telephony provider (voip.ms) did a trace and let me know that the Contact line of my REGISTER packets included the internal IP address of the phone rather than my public IP address. I suspected that SIP Conntrack had been replacing the IP address. Sure enough, when I temporarily turned SIP Conntrack back on in the router, the phone registered.
Leave SIP Conntrack Off
After that test, I turned SIP Conntrack back off in the USG. At this point, for reasons I don’t understand, the phone was still able to register. Some kind of “memory” in the router or on the voip.ms side? Strange. I could see the local IP in the Contact line but it still registered.
I did figure out, though, how to get the phone to fill in the public IP. In the T42G UI:
1. Under Network > NAT, enable STUN. I used stun1.l.google.com. The phone will reboot.
2. On the Account tab, choose the account you are updating. At the bottom, set NAT to “STUN”.
You should now see the public IP filled in in the REGISTER packets when you trace the traffic (see below).
To do this in a provisioning file, use lines like this to set it up for accounts 2, 3, and 4:
# Enable NAT at the phone level sip.nat_stun.enable = 1 sip.nat_stun.server = stun1.l.google.com sip.nat_stun.port = 19302 # Enable keep-alive and NAT at the account level account.2.nat.udp_update_enable = 1 account.2.nat.udp_update_time = 30 account.2.nat.nat_traversal = 1 account.3.nat.udp_update_enable = 1 account.3.nat.udp_update_time = 30 account.3.nat.nat_traversal = 1 account.4.nat.udp_update_enable = 1 account.4.nat.udp_update_time = 30 account.4.nat.nat_traversal = 1
Tracing from the USG
To trace packets headed for denver1.voip.ms from eth1, the LAN port of the USG:
sudo tcpdump dst host 126.96.36.199 -i eth1 -n -v
To trace packets going to to denver1.voip.ms from eth0, the WAN port of the USG:
sudo tcpdump dst host 188.8.131.52 -i eth0 -n -v
Theoretically, if the router is changing the packets, you would see the difference by comparing output from eth1 and eth0.