VPN phone not registering

[inet33]

I am having a tough time with some VPN phone users connecting to the IP Office. They are all connected to a Cisco 2811 via an IPSEC tunnel and used to work fine for the past few months. Suddenly we're getting issues with the users connecting, and the problem goes away sometimes. I don't think there's an issue with the VPN tunnel as they negotiate fine and the sessions are active. The phone goes through and discovers and downloads the settings, but when it goes to registering, the phone seems to either get stuck at registering, or sometimes say registration failed or keep on looping in registering.

I read in another post that it could be a DSCP issue with certain providers, so I did try to downgrade the SIG DSCP from 34 to 26, but that didn't do anything.

Anyone have any other suggestions?

Here's my log from the monitor:
532278mS H323Evt: Recv GRQ from c0a86f83
532278mS H323Evt: e_H225_AliasAddress_dialedDigits alias
532278mS H323Evt: found number <2203>
532379mS H323Evt: Recv: RegistrationRequest 192.168.123.131; Endpoints registered: 4; Endpoints in registration: 0
532379mS H323Evt: e_H225_AliasAddress_dialedDigits alias
532380mS H323Evt: found number <2203>
532380mS H323Evt: RRQ --- CallSigProtocol is H323AnnexL_P. Go for Avaya VPN phone
532380mS H323Evt: RRQ --- Register extn 2203 using product IP_Phone_VPN, version 6.2009
535352mS H323Evt: Recv: RegistrationRequest 192.168.123.131; Endpoints registered: 4; Endpoints in registration: 1
535353mS H323Evt: e_H225_AliasAddress_dialedDigits alias
535353mS H323Evt: found number <2203>
535353mS H323Evt: RRQ --- CallSigProtocol is H323AnnexL_P. Go for Avaya VPN phone
535353mS H323Evt: RRQ --- Treat this as a forced login, the phone was probably rebooted (same_cs_addr 1)
535354mS H323Evt: GK: Unregister endpoint Acme_530fd05733c72c95 for extension 2203
535355mS H323Evt: RRQ --- Register extn 2203 using product IP_Phone_VPN, version 6.2009

Kev

 

[gwebster]

What type of phone and are you running the latest software on it?

 

[inet33]

I finally figured it out, and it was a Cisco configuration issue after all. There were two default static routes and one of the routes was causing the issue. Somehow that made it intermittent as some of the encapsulated packets were being dropped.

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 <-- this caused the issue.
ip route 0.0.0.0 0.0.0.0 123.111.12.12