There are three symptoms which have been reported and I myself have tested and seen on site.
Short, 1-3 second audio dropouts whilst the phone is roaming in several locations around the hospital. This happens on multiple handsets. (I have a Meraki Packet Capture of this issue)
Large bi-directional audio dropouts when the phone moves into specific locations (I have been told that this happens in other locations in the hospital, however I only saw it happen once at the nurse’s station). We will be on a call (8821 <> Mobile) and the handset will move into a particular area and the audio in both directions will completely drop out but the call will sustain. Upon moving back out of that area, the audio is restored and the call continues as normal. This was replicable multiple times, however once we rebooted the handset, the problem went away and we couldn’t replicate it. This happened only on a single handset (that we tested). (I have a Meraki Packet Capture of this issue also).
This is the major issue and can happen when both moving or stationary. It has been reported and I have tested this happening on multiple handsets. The phone (whilst staying associated to the wireless network and having adequate RSSI signal strength and no channel overlap, interference or noise), will un-register from CUCM and therefore be unable to make or receive calls. This can happen during an active call or simply while the phone is just sitting there. I observed that sometimes by moving around, the phone will eventually register to CUCM and re-gain it’s call functionality, while other times a reboot of the phone is required – after which the phone behaves normally. This has happened in multiple locations around the hospital (at least three that I know of). The scenario where this was seen happening is that a nurse was sitting at her desk (directly next to an AP) and successfully making calls, when during one of her calls (as she remained sitting), the phone unregistered from Call Manager and had to be rebooted. (I have the ability to get RTMT logs of me replicating this event, however I don’t have Meraki Packet captures of this issue happening – my fault for not getting this).
Some key considerations
This entire environment (8821 handsets with Meraki APs) was tested and considered stable by both us and the customer as of January this year. Since that time, neither the 8821 handset firmware or the Meraki AP firmware, nor the CUCM firmware has changed since that time. We don’t know if anything within the Meraki Dashboard itself has changed and this would have to be something Meraki can tell us.
The wireless environment has been validated. Meraki Dashboard and phone configuration are both adhering to best practice based on Meraki and Cisco documentation.
Security has become one of the greatest concerns for every company alike. The industry is moving towards a fast paced and customer-oriented network infrastructure which automatically increases the vulnerabilities a network is exposed to. As the industry t...
We got some new Apple Macbook Air, when connected to wifi, we found the link speed was only 54Mbits, but other laptops like DELL or Panasonic were working fine, the link speed was at least 800 Mbits. we are using Cisco WLC 5504 and 2702I ap.and the funny ...
In today’s world where business needs to be up and available 24X7, one of the major challenges faced by a lot of companies is the seamless uptime of their network infrastructure. Any company’s primary focus is always on keeping its infrastructure ready fo...
As a network administrator keeping up with the methods of today is more challenging, and not relying solely on traditional ways of configuration and management is demanding. APIs have become a buzz word, and supporting it shows that your de...
We’re looking for network operators and engineers to complete a 2-minute icon preference study.
The icon choice will help us better represent information on a Cisco software product.
Click here: https://ciscoux.az1.qualtrics.com/jfe/form/SV_6saOh5...