OK. I’ve been chasing a problem with a new installation of the Distro (up-to-date, Asterisk 16.17.0). In my sngrep I’m seeing traffic that is “odd” as far as I can tell, in that is serves no useful purpose. The machine sits directly on the Internet in my network (no VM, straight hardware) and is running a very locked down Integrated Firewall.
I’m still struggling with the sngrep options and features, but the call goes (from what I can tell) normally until I get to the SDP ACK. The ACK, Via, From To, CalloID, CSeq headers all look right, but there there are two Route: headers.
The first one is back to the provider and appears to make perfect sense.
The second one is t SIP packet to 10.255.0.1;transport=tcp.
I’m wondering if this is meaningful? I don’t recognize the address, I’m not using a VPN on that system, and the local network address is not nearly that network. The default route is going to send the message out over the default gateway and (I assume) is tieing up resource in the network stack that could explain the packet loss and other offness that happens as the day wears on.
The system is getting a Record-Route: header for the same address during the “Ringing” message from the provider, so I was able to glean where it’s coming from.
In the same “180 Ringing” packet, there’s also a 'Contact:
<sip:[email protected]:5070; transport=tcp> header, which is another address in the same non-routable address block and using TCP, which I have rather severely locked down.
I’ve got a request with my provider to see what they think about these apparently random 10.255.0.1 TCP entries.