Cisco 8821 handset rings but cannot answer call

[Arne Bier]

Hello voip experts

My Cisco IP telephony is a bit rusty, but I wanted to check whether my understanding was still valid.  We have a customer reporting that their Cisco 8821 handset rings, but they failed to answer it - press the call answer button but phone continues to ring.  They say it's the Wi-Fi.  My understanding is that if a VoIP endpoint is ringing, then it proves that there is an IP connection to the phone because the ringtone is delivered in real time via RTP (UDP).  Is my understanding still valid?

If pressing the call answer button doesn't answer the call, then it may mean that the signalling is not getting back to the Call Manager (perhaps it is a Wi-Fi issue, esp if the phone can receive the UDP stream, but its Tx power is not strong enough to talk back to a distant AP).  Or perhaps the phone has a bug - but that is less likely.

Phone load: sip8821.11-0-3SR6-15

Cisco WLC: 8.2.166.0

regards

Arne

[Leo Laohoo]

Still a wireless issue Arne. In order "not" to be a wireless, the client needs to press the green button and the call flows. Only then is it not a wireless issue.
Going back to the issue, if the GREEN button is pressed, the call cannot be answered? Is CAC enabled?

[Arne Bier]

Hi @Leo Laohoo  - the user presses Green button - call still continues to ring.  User presses Red button - call still continues to ring.

My question is still: "if a phone is ringing, then it means RTP is streaming to the phone?  Yes or No?" - if yes, then surely it means that the handset has a working IP connection back to the Call Manager, right?  What/who streams the ringtone to the handset?

CAC is enabled on the WLC.

[Leo Laohoo]

I had issue like this before.
If CAC is enabled, turn it off. See if it makes a difference.

Also try turning off WMM.

[Arne Bier]

Ok will keep that in mind in an ever growing list of things to try. But still doesn’t answer my original question. 

[Leo Laohoo]

---

@Arne Bier wrote:

"if a phone is ringing, then it means RTP is streaming to the phone?  Yes or No?" - if yes, then surely it means that the handset has a working IP connection back to the Call Manager, right?

---

Phone rings is one thing.  

Picking up the call is another thing.  

Just because the phone ring doesn't mean the end-to-end is correct.  It only means the call going to the call manager is working fine.  

Picking up the call, however, is totally different because this means the data path gets "extended" from the call manager to the phone.  

And my experience is if the call drops after the green button is depressed, or in your case the call doesn't get answered, then something else is wrong.  And this is still part of a wireless issue.

[Arne Bier]

When someone answers a call then the Call Manager connects the endpoints.  It doesn't extend the call to the Call Manager.  Call Manager is not in the data path.

I did some more research and the SIP signalling tells the phone to ring.  I don't think there is RTP involved in making a phone ring.

[Leo Laohoo]

One of the mistakes I made was disabled 12 Mbps data rate on the WLC.
So the phone rings, however when I pick up the call, the call drops immediately.
From that time on, we make sure that we pick up the call and make outgoing calls to ensure the wireless and wireless phones are working fine.

[Maren Mahoney]

Is this problem on just this one phone, or is this true for all of the customer's wireless phones?

Is the phone's path to the CUCM via an internal LAN/WAN or is there a CUBE or other signaling proxy in the path?

What firmware are the 8821's running?

If the phone answered and the the call dropped, I could see the problem being as Leo is describing. But your scenario - rings but cannot answer despite pressing the answer button on the phone -  says to me that the 200OK message is not getting from the phone back to CUCM or CUCM's ACK is not reaching the phone. (Or some other signaling problem.) If this is only happening on the 8821 wireless phones I could see some weird WLC problem causing it, but I'm thinking it might be firmware.

Maren

[Arne Bier]

It's only happening with the 8821.  And happening on all of the handsets.  WLC version is 8.5.140.0 and we have implemented all of the best practices as per the 8821 Deployment Guide.   802.11r (FT-X) made things worse - CCKM is a lot better.

The phones connect to a CUCM - but I cannot tell (yet) whether it's on premise or not.

The firmware on these devices is appalling.  We loaded 11.0(4)MR1 and that causes the phones to disassociate after a few minutes.  User wasn't even moving around at the time.  MR3 roaming is unpredictable and not good at all.  MR2 seems the best out of the lot but it seems to favour APs that have a far worse RSSI than an AP that is 2m away from the phone.  We have a TAC case to investigate.

All the while, the 7925G is having no issues.

We took some Ekahau Site Survey data today and we will analyze it in the morning.  But the 7925G's seem happy.

Bug report in MR1 claims to have fixed the issue of "random phone freezing" - we have not tested receiving calls to see if the issue went away.  The main focus right now is on the roaming behaviour of the 8821's

[Maren Mahoney]

With it being all of the 8821s and none of the 7925's, and with different behavior depending on firmware on your 8821s, this smacks of a firmware issue. Hopefully TAC will be able to help you with this.

The only other thing I can think of that would make it *not* a firmware problem is that the 8821s are SIP and the 7925s are SCCP. There may be some weird scenario that makes the SIP messages not path correctly through the wireless network, if such a thing is even possible. (Not my area of expertise.)

Let us know how this works out.

Maren

[Leo Laohoo]

Are the APs 2800/3800?  If they are, then have a look at CSCvn05881.

[Dennis Mink]

What this proves is that the phone. Receives an invite over wifi. Be it tcp or udp. This prettymuch prompt thw phone to ring.based on it local ring tone. Not rtp.does the calling party a actually get a ring back tone? (I.e. does the wifi phone actually gets its sip ringing message and ack back to cucm?

[Arne Bier]

Short update on this topic. I was unable to reproduce the inability to answer a call. I believe the issue was due to poor roaming and bad timing (phone rings and then roaming fails, thus no ability to send sip back to cucm). We spent many days with TAC and tried all latest versions of phone code. Made no difference to roaming. CCKM and 802.11r were both terrible and I could hear voice drops when roaming between APs. TAC checked that we followed all best practices (5GHz only, 8 20MHz channels, AP density and cell overlap, etc)..The end of this story is that when we put same phones on PSK SSID ( no FT!) then the phones performed perfectly. Amazing. No single drop in audio when roaming. All Issues seem resolved because now the phones finally have decent connection to the wifi. I have no idea why anyone needs fast roaming, when basic PSK is just perfect. FT and CCKM adds so much complexity, that it seems the software cannot handle it. 

To make matters worse, when implementing voice roaming with FlexGroups, confusion reigns within TAC about whether crossing between flex groups is an issue with voice roaming. My take away is: just keep it simple. It seems to work better that way.