Weird traffic showing up in sngrep


(Dave Burgess) #1

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:19999999999@10.13.41.4: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.

Any suggestions?


(Andrew) #2

I’ve seen the Record-Route: <sip:10.255.0.1;… but have not spent much time trying to figure it out. What’s the result of netstat -rn on that machine?

EDIT: Is it your loopback interface?


#3

IMO it’s very unlikely that the signaling you are observing is in any way abnormal or malicious. It is typical of larger providers that have one or more proxies between you and their servers. These proxies usually perform load balancing, security and/or failover functions. The connections between the proxies and servers are internal to the provider network and use private IP addresses, such as the 10.x.x.x you are seeing.

These six slides: https://www.tech-invite.com/fo-sip/tinv-fo-sip-dialog.html are a fairly good explanation, though they unfortunately don’t show Via headers or a PRACK resulting from 180 Ringing.

The first one is where Asterisk should send the ACK. The proxy (at your provider) receiving it does have a route to 10.255.0.1 and forwards it on to the server there, after removing the first Route header.


(Simon Telephonics) #4

I was going to help answer this question but Stewart1 has it nicely wrapped up.

If you are going to dig deep into SIP and want something more readable than RFC 3261 and its cousins, I recommend the textbook by Alan B. Johnston, “SIP: Understanding the Session Initiation Protocol.” (Fourth Edition) Try to find it used. :slight_smile:


(Dave Burgess) #5

I’ve been through the network settings on this machine and the 10.255.x.x network is entirely unrepresented. The loopback interface is 127.0.0.1 and points to the lo0 interface, as do all of the “local” addresses for the server. @Stewart1 explains it below, so I’m good with that.

Having said that - something I’ve now seen twice that I’d love to hear more about.

In this example: I totally agree. On other examples, though, I’m seeing the 10.255.0.1 interface listed first in the SIP message back. I want to believe that the order shouldn’t matter, but there have been so many “one ring and hang up” calls that I’m beginning to wonder. I’ve also read some reports that Asterisk versions after 15.0 might have problems with Record-Route order. I’ve been struggling with this for almost a month and everything I’ve tried (reviewing the network settings, double-checking the SIP settings, etc.) just doesn’t yield any improvements. Having failed every thing I’ve tried so far (including replacing hardware) I’m here as a last act of desperation…


(Simon Telephonics) #6

Would you be interested/willing to post the SIP of a dialog setup?

One thing you might want to check, if you are using PJSIP, is that you have disabled Rewrite Contact in the trunk settings. Your provider wants that internal IP address preserved in the Contact header, and Asterisk rewriting it would definitely cause call setup to fail.


(Dave Burgess) #7

I’m pretty sure that’s disabled; I’ve been following the other discussions we’ve had on that option being used. I will double check it as soon as I can.

I’d be glad to post the SIP dialog setup - I’ve been using sngrep now for about 15 hours, so with that kind of experience, I’m confident I can make that happen. :slight_smile: I’m at my “day” office right now, so I’m going to have to get one of the customer reps to help me out.

Thanks.


#8

Just do a
pjsip set logger on
wait for the next failed call and find it in the Asterisk log.