Wireless Access

Since going to 6.4 from 6.3 we’ve had issues with our VOIP phones not able to receive calls. The phones can call out and once they do that they can start receiving calls again. I’ve got a debug trace from one of the phones showing it reconnecting once the user places a call. There’s numerous entries for the user_age called before this when it wasn’t working. Appears you can’t ping the phone either when it’s not receiving calls, but phone thinks it still connected. Any ideas?

What kind of phones are these?  Do you have QOS enabled on your network?

Spectralink 8440 phones

Customer is enabling a feature on the phones that does a ping to the SIP server periodically to see if that helps. 

Also do you think adjusting the following timers would help?

Configuration> Authentication> Advanced Tab

No QOS on the network for the voip as far as I know.

Neither of those timers have anything to do with voice quality.  How much time do you have to fix your issue?

Sorry... maybe I didn't make it clear.

Voice quality and using the wifi phone for outgoing calls is never a problem. 

The problem is that after the phone is idle for a period of time, it can no longer recieve calls. When it is in this state you can not ping the phone either. Once the user places a call and connection reistablishes, users can call the phone and you can then again ping the phone again (for a while).

This is why i was looking at the user timeout timers etc.

Is the phone still in the user table, when this happens?

Phones have started working properly after adjusting the above timers on the controller.

Which timers and what values?

Configuration>Authentication>Advanced Tab

User Idle Timeout-15300 (max)

Logon User Lifetime (min)- 255 (max)

Not sure if maxing out the above timers actualy fixed, most likely just masking the problem. We will find out for sure on Monday when they all come back to work and the phone has had a chance to sit idle all weekend.

What is the DHCP lease for those devices and your other devices?  Making the user idle timeout larger than the DHCP lease will cause issues, because the device will stay in the user table with the same ip address for the user idle-timeout, but could come back with a different DHCP address.   That will trigger the ip spoofing that thinks that mac address already has an ip address in the user table and might reject the other device.  In addition, your user table will be artifically inflated because it will show users that are no longer there.

I would return the user idle timeout to the default ASAP, unless you make it less than the DHCP lease.  EDIT  I am also not sure that this is related to your VOIP quality issue, so maybe if you open a different thread with the phone not responding, we can leave this thread solved and create a new one with the phone specific issue.