Branch Site Phone keeps unregistering MGCP SIP and SCCP , FXO, PSTN

[Danik Therrien]

Hi Everyone, 

I need your help to help me find a solution to this problem. How can I tackle the problem? Is there a way to see what makes the phone unreg.?

NETWORK SCHEME

CUCM---HQ---Firewall (not asa)----Internet-----ipsec VPN on Router 881--- Switch---MGCP VG 2921

---2 POTS 

SITE DESC

In words, there is a VPN tunnel between the headquarter and the branch.

There is a 70 mbps internet connection at the branch and 200mbps at HQ.

PROBLEM DESC

Now, at random times, the phones will unregister,  stay like this between 3 and 5 min. then will comeback. It's really annoying because calls coming in can be lost during that time. 

Now we have check the VPN tunnel on the router and on the third-party firewall and it's all good, no errors. 

Internet seems to stay up. 

I have opened a TAC case to check the IPsec config and the VG but nothing. It doesn't explain why the phones go in a registering mode all the time. 

I"ll be as responsive as possible!

Thank you So much everyone!

D

[Jaime Valencia]

You probably want to start by reviewing CUCM traces at the time this happens, and phone logs to look for any pointers, most likely there's a problem with the connection, QoS does not protect the voice signaling and RTP, etc.

[Danik Therrien]

That is good to know!

I will see what I can do! Although, It hasn't occurred in the last two days. No clue why. But I asked the client to call me as soon as possible when ever it does happen. 

I will keep you posted!

[Mohammed al Baqari]

Hi,

Check in CUCM RTMT for reason of last rest. This will help you to confirm if the problem is related to connectivity or something at CUCM.

Now, you need to look at the monitoring for both sites to see if there are packet drops or link flapping. Also, you need to check the average latency between sites to make sure that its within supported limits.

Also, since this is a site to site vpn, you need to check your rekey timers and make sure that they aren't very low. This will keep the vpn tunnel to flap. You can verify the logs on cisco 881 router to see the vpn keeps going up/down.

On the firewall make sure that MGCP isn't inspected that the security box isn't dropping connections.

Now with centralized deployment similar to yours, SRST is very good option to overcome such problem. Also, it needs tuning for switchback  timers to avoid phones flapping between cucm and srst gateway.

Hope that helps you to look further.

[Danik Therrien]

Those are very good pointers. 

• Log from the vpn router attached to this post. I did replace the IPs.
• Ping time from the VG to the CUCM :Is it too much?

VG01#ping 10.1.1.55 rep 50
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.1.1.55 (CUCM), timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 136/139/144 ms
VG01#

• The firewall isn't inspecting anything since it's just a tunnel. But I will have my security engineer double check that.
• Timers : Which one should I be looking for?
• CUCM : When the problem reoccurs, I will check the logs right away!

Thank you so much again!

[Mohammed al Baqari]

Hi,

The latency is ok. Not very good but not too bad. However, I can see jitter which is expected over internet.

You security engineer needs to look for IKE SA Timers for phase 1 and phase 2. Best to post this in security forum.

[JEFF CALVIRD]

Danik, even though there's a VPN the firewall still has to make the decision when it's ingress so even though it's a quick match/forward process the firewall has to process based FIFO. :)

[JEFF CALVIRD · Accepted solution]

I hear about this a lot and have worked a similar issue with a client. What it comes down to is lack of QoS and hitting loss of TCP syncs to CUCM. The gateway drops or CUCM is not receiving them and thus the result is loss of registration. Remember you have a round trip delay to address and when that's exceeded you will drop. Firewalls don't actually do QoS no matter what the manufacture states it's always best effort because the bottom line is that the internet has no QoS. The size of the pipe doesn't mean you won't have delay it just means you reduce the possibility you'll have delay caused by congestion. However rules of Ethernet is busty traffic which means the firewall may have to adjust for traffic hitting it and being scanned for policies and add a time you won't see in a peer-to-peer trace.

In some cases you can adjust this by changing the timer values in CUCM to extend but that will only mask the greater issue.