Unreachable \ lagged

I’m having problems with Cisco Phones going to an UNREACHABLE or LAGGED state. The phones are are behind a FIREWALL so are NATed. When I remove the “qualify” statement in the sip.cnf file, obviously, these statements disappear but everynow and then the phone will go directly to voicemail when called.

The phone will then not ring until it registers. I’ve reduced the register from 120, 100 and then 60. The phone consistently have this problem.

I’m at a loss at the moment and need to get these phones rolled out. Does any one have any idea what might be causing these problems?


More Notes; although the Cisco phones are on a different network when I ping between the devices it’s a constant 6ms~7ms. I’ve increased teh qualify to 3000ms and this appears to help but why would it that long to qualify?

athb/cathb D N 2633 OK (276 ms)
saml/saml D N 2123 OK (356 ms)
time/time D N 1189 OK (188 ms)
jimm/jimm D N 1061 OK (146 ms)
nickc/nickc D N 2762 OK (189 ms)

Everynow and then the qualifies have actaully gone above 3000ms?

Any ideas?

I’d appreciate any inputs.

it sounds like a NAT issue. when the phones register or make a call, they open a NAT hole. which closes after inactivity. hence the calls going to VM.

what does a sip.conf entry for the phone look like ?

to overcome the issues with NAT, you can utilise STUN, configure the firewall (and phones) to use port-forwarded addresses, or maybe a VPN will do the job. is the Asterisk server behind another NAT too ?

I thought it was a NAT issue too, I’ve heard about STUN but not sure how it works? Do I need to install another server? Should it be on the LAN with the phones or on a public IP, or both?

The firewall I’m using is an old Netscreen 5. I’m going to try and get it replaced with a 5GT that suggests it supports SIP ALG do you think that might help?

The SIP conf entry looks like this:

callerid=“Matthew Arrundale” <8876>

The Asterisk server is not behind a NAT only the phones. I thought that would be ok?

By using a VPN then the communication will be over TCP instead of UDP, do you see that being a problem?


routing the packets over a vpn should not have anything to do with tcp!

Surely when using a VPN this will encapsulate the UDP transmission inside a IPSEC packet, hence the UDP will be encapsulated in a TCP packet; connection orientated as oppose to connectionless.

ipsec is not based on tcp, so no.

Guy apologies, I do not know the “complete” ins/outs of network protocols but my understanding is that the advantage of using UDP is that it is connectionless. However, if you use VPN then that advantage is lost.

If I’m wrong and and there is somethings else i should be aware of, then I am more than happy for suggestions on my problem because i really need to get it fixed.


there are public STUN servers out there you can maybe change the phones to use. that way they know their public IP address. dunno the names, but search on the forum here and they should show up.

It’s ok, I’ve got their names, just not sure how it works. However, this will be a great way to find out if this is the problem or not. I appreciate the input and I’ll let you know how I get on.


Just to let you know, this was fixed by reducing the registration. I’m using an old netscreen which doesn’t support SIP NAT.

THe underlying problem seems to be that UDP sessions have a "fixed’ timeout of 60secs. The registration was set to 120 secs. I have changed the registration, until I replace netscreen later next week, to 45secs.

Problem appears to be fixed!