We have a small deployment of 7921g and 7925g phones. The 7925g phones while stationary when set to use the a band roam (while idle or in call) to distant APs with much weaker signal strength. That of course impacts negatively the quality of the call. The 7921 phones do not exhibit this behavior.
Access points and coverage:
Meraki MR14 & MR24 set to select their own channels (channel spreading) and auto reduce power according to the RF environment to avoid co-channel interference. Currently the APs transmit on channels 1, 6, 11 and 36, 44, 149 and 157.
Coverage has sufficient overlap for seamless roaming but it is really irrelevant in this case since the 7925 phones roam while stationary.
Initially 1.4.2 now the 7925s run 1.4.2ES.1
The phones have been configured to continuously update the AP list (CUCM setting) and channels on which the APs do not transmit have been excluded (through the web interface of the phones)
Subscribing to this thread as we also have issues with roaming on 7925 phones as well as WoWs.
RSSI values above -80 and devices are not roaming to closer/stronger AP until they drop their connection.
188.8.131.52 5508 controller
7925 phones 1.4.1(sr1) & 1.4.2 - 80211a
Phones and WoWs on A radio only with data rates below 12 disabled, and 54
WPA+PSK on phones
WPA2 802.1a EAP-TLS on WoWs
Since you are seeing unexpected roaming and you believe that is the reason for the choppy audio, we need to gather phone logs as well as correlated WLAN sniffer traces.
The phone should have Kernel, WLAN Driver, WLAN manager set to DEBUG level.
You can increae the # of files and file size to 10 /250 kb or enable syslog via USB.
Be aware that with this increased logging, audio quality can be impacted, but since we are troubleshooting unexpected roaming it should be ok.
Just want to be sure you don't enable this debug level on many phones / production user phones, where we make things worse.
Once you get the logs, attach them to the case by replying to your SR thread with email@example.com copied.
For the comment about 7921 and 7925 RSSI, they are different chipsets (although same vendor) and different antenna type.
So will not be 1 to 1 exactly.
Will need to ensure that the 7925 downstream RSSI is -67 dBm or better as well as the upstream signal (from 7925 to the AP).
But since the issues don't seem signal related, let's not focus here, but instead focus on the unexpected roams.
So yes we need all 3 modules enabled at DEBUG level as mentioned above.
Get that info and attach it to the SR and let your assigned TAC engineer know.
I already reached out to the TAC engineer assigned to your case.
I have also noticed roaming issue with 7925G phones.
My phones have got configured scan mode for auto-RSSI, no power save.
When I use survey tool on the phones I can see all aps around with RSSI from -70 to -30dbm. The phone not always connects to the ap with the best noticed signal. When the call is placed the phones roam to the next ap randomly or when the ap drop the connection. Sometimes the phone handles connection to the ap with very low RSSI and reconnects to the nearest ap with the best signal only when is manualy kicked from the connected ap.
Other issue is that the all phones still uses power save mode even this mode is manualy disabled in the phones configuration ( I can see it in aps status) Phones leave power save mode only when the call is placed.
Need to ensure you are using the 1.4(3)SR1 release / firmware 1.4.3SR.2 on your 792x phones.
Also it is not best practice to deploy the 792x phones configured with Auto-RSSI mode in an enterprise setting where frequent roams will occur.
Auto-RSSI will roam to the strongest signal but may not always be the best decision (e.g. "Dirty" 2.4 GHz channels).
Is best to hard code to 802.11a or 802.11bg depending on your current coverage.
If you don't have full coverage if the desired band then use Auto-a or Auto-bg mode.
As for the power save comment, this is because that option is called On Call Power Save Mode and NOT idle (not on call) power save mode.
If the 792x stayed active in idle mode as well then the battery life would be significantly impacted.
Sent from Cisco Technical Support iPhone App
I would make sure you get the most recent code for the phones 1.4.3 SR1. I would also make sure you get a baseline and verify the wlc is setup correctly for a voice deployment. see the 7925 deployment guide below. I would also make sure you are not doing auto RSSI. If you havet he appropriate coverage for a, the set the phone for 802.11a and the voice wlan for A only also. I would also do a voice wireless site survey to make sure of the RF and also proper ap placement.