Network dudes.. help please - SIP issues, ICMP messages

Forums › IT Pro and developers › Network dudes.. help please - SIP issues, ICMP messages

chevrolux

4962 posts

Uber Geek
+1 received by user: 2638
Inactive user

#225403 16-Nov-2017 20:46

So I have a super random fault with a SIP trunk. It's only cropping up very randomly and been really hard to get any decent info..

But I finally managed to make it fault with a packet capture running. My only annoyance was I did the capture off the PPPoE interface and not LAN bridge so I don't know what actually got to the LAN.

So the PBX receives an INVITE from the SIP proxy, but then right after that, the router "replies" with an "ICMP 590 Destination unreachable (port unreachable)"

I kind of take that for what it is, the port was unreachable. My thought process goes there was no state in the sessions table that matched so it couldn't get through the NAT.

Do people agree? Maybe just pull my registration timer (currently 120) and notfy timer (currently 30s) right down? Increase the UDP timeout (currently 1m) in the sessions table?

My main annoyance is this is my standard router config and a standard PBX config in use on 300+ other sites. Also a VERY basic network.

ArcticSilver

731 posts

Ultimate Geek
+1 received by user: 148

#1903071 17-Nov-2017 00:52

It’s late and havent really had much of a think on it but in the interest of helping I’ll throw my initial thoughts below:

My first thought is that you could be right, if the Nat is timing out just before it re-establishes the session it could mean the majority of calls work but the odd one drops.

Unreachable may not mean the Nat translation has expired it could also mean the packet couldn’t reach the destination, maybe the switch inbetween went down? Maybe there is a loop?

In order to narrow it down further we’ll need to know more about the problem.

What exactly happens? What specifically are you trying to fix?

ArcticSilver

731 posts

Ultimate Geek
+1 received by user: 148

#1903072 17-Nov-2017 01:05

Also, when you say he PBX receives the invite did you packet capture this on the PBX?

What are you doing while packet capturing? Initiating a incoming call?

The ICMP590 message in reply, is that going out the WAN to your SIP trunk provider? Where is this destined?

chevrolux

4962 posts

Uber Geek
+1 received by user: 2638
Inactive user

#1903114 17-Nov-2017 08:20

ArcticSilver: Also, when you say he PBX receives the invite did you packet capture this on the PBX?

What are you doing while packet capturing? Initiating a incoming call?

The ICMP590 message in reply, is that going out the WAN to your SIP trunk provider? Where is this destined?

The issue is incoming calls are failing - but only very randomly which is why I think it may be a timing issue.

Yea sorry should have been clearer. I only got a capture from the PPPoE interface. And I really wish I had something running on the PBX interface too because that probably would have been more interesting. The problem has been trying to actually capture the behavior because it is so random.

So I know the WAN interface of the router receives the INVITE, and the the router replies with the ICMP 590.

Mattmannz

471 posts

Ultimate Geek
+1 received by user: 88

#1903119 17-Nov-2017 08:38

Without a packet capture from the PABX ethernet port it's hard to say exactly what the issue is. The ICMP unreachable message could be being generated by the PABX, obviously it will always come from the router when looking at a packet capture on the WAN port.

chevrolux

4962 posts

Uber Geek
+1 received by user: 2638
Inactive user

#1903128 17-Nov-2017 09:14

Mattmannz:

Without a packet capture from the PABX ethernet port it's hard to say exactly what the issue is. The ICMP unreachable message could be being generated by the PABX, obviously it will always come from the router when looking at a packet capture on the WAN port.

Yep agreed. I've got a raspberry Pi with a network monitoring package on it that is going to let me run much more prolonged captures than I can do on the router. So will get that in place on a mirrored port to the PBX and see what's happening there.

rphenix

990 posts

Ultimate Geek
+1 received by user: 127

ID Verified

Lifetime subscriber

#1903147 17-Nov-2017 10:22

If you can - set your NAT Session timeout timeout to 90 seconds on the router.

set qualify on your sip trunk - the default is 60 seconds for most devices when qualify is enabled. This will keep the UDP session in the nat translation table on your router. Trying to set qualify below 60 seconds often wont help - because it wont be accepted in many cases its easier to set the Nat Session timeout higher.

Lego

Shop now for Lego sets and other gifts (affiliate link).

MadEngineer

4591 posts

Uber Geek
+1 received by user: 2570

Trusted

#1903150 17-Nov-2017 10:24

Does the router have an IP helper for the SIP protocol?

You're not on Atlantis anymore, Duncan Idaho.

rphenix

990 posts

Ultimate Geek
+1 received by user: 127

ID Verified

Lifetime subscriber

#1903152 17-Nov-2017 10:27

MadEngineer: Does the router have an IP helper for the SIP protocol?

Agreed look for this if you havent already SIP ALG is always the first thing you should turn off.

MadEngineer

4591 posts

Uber Geek
+1 received by user: 2570

Trusted

#1903161 17-Nov-2017 10:50

This is mikrotik specific but may be of interest: https://mum.mikrotik.com/presentations/US17/presentation_4321_1496084451.pdf as it has good explanations and example sniffs

You're not on Atlantis anymore, Duncan Idaho.

vulcannz

436 posts

Ultimate Geek
+1 received by user: 136
Inactive user

#1903166 17-Nov-2017 10:59

rphenix:

MadEngineer: Does the router have an IP helper for the SIP protocol?
Agreed look for this if you havent already SIP ALG is always the first thing you should turn off.

Turning off the SIP ALG is not a smart idea unless you known that is the issue. Turning off the SIP ALG may result in things like NAPT being applied to SIP traffic which will break everything SIP related.

MadEngineer

4591 posts

Uber Geek
+1 received by user: 2570

Trusted

#1903172 17-Nov-2017 11:28

^+1

You're not on Atlantis anymore, Duncan Idaho.