what would you suggest, are the best settings in the "Client Roaming Section" of the WLC Configuration for the following requirements:
VoIP over WLAN deployment, 802.11a, WLC 4402, 25 - 30 access points (mainly 1252, a few 1130), 7925G phones.
In the moment the settings are set to default, that means: Min. Rssi = -85; Hysteresis = 3; Scan Tresh. = -72; Trans. Time = 5
Unfortunately we are not completely satisfied with the roaming behavior of our phones, so there is the question,
if the roaming behavior of the phones can be improved. Sometimes it looks like the phone takes too much time to make a roaming decision.
Solved! Go to Solution.
Frank, those settings only apply to Intel clients and are not used by 7925Gs. For the phones, I would recommend:
thanks for your answer.
The phones are already running on firmware 1.3.4 SR1.
And meanwhile, I think I know the 7925G Deployment Guide by heart.
But sometimes the phone simply makes the wrong roaming decision.
Unfortunately it's not 1 out of hundred, it's one out of 10 decisions that's wrong.
Maybe it would be a suggestive feature in the future if one can set "default roaming routes" for the phone.
So your wireless network was properly surveyed for and channel/power settings for aps are configured properly? Do you have your WLAN set up for CCKM and WMM? Do you have qos set up for voice?
Our wireless wireless network has been surveyed twice.
The first time to figure out the positions of the Access Points and because there have been changes in amount of APs
and position of some APs, a second time to figure out the ideal power level and channel settings for the changed environment.
The amount of APs and some positions changed, because sometimes there have been two APs in the same office
with an RSSI, let's say 60-65 and the phone was permanently changing the AP, what impacted the quality of the phone call.
The WMM and QOS settings are set for the WLAN, as described in the 7925G Deployment Guide.
CCKM is not set, because we are using WPA2-PSK.
Isn't CCKM of note only, when using 802.1x authentication?
Frank, what version of code are you running on the WLCs/APs? If 220.127.116.11 thru 18.104.22.168,then do please note that the APs are susceptible to:
CSCta29484: Radio stops beaconing for 10-second period (fixed in 22.214.171.124)
CSCte89891 Radio may stop transmitting beacons periodically (affects 126.96.36.199 too)
If the phone doesn't receive beacons for one second, it'll roam to another AP.
188.8.131.52 is not susceptible to those known beaconing problems.
I would recommend opening a TAC case, and being prepared to collect multichannel, NTP-sychronized wireless packet traces, coordinated with phone traces, WLC/AP debugs, and wired packet traces.
have you been able to solve your problems. We have the same issues with 7921 (1.3.4SR1) and 184.108.40.206, but we are not able to solve the problems.
at the moment we are redesigning the problematic spots in our network
and this will hopefully help to resolve our problems.
thanks for the feedback. Actually we are working with the TAC and hopefully we gonna have a solution today or tomorrow.
As soon as I now more I will post it here.
no not at all, we are working with the TAC since 2 weeks and with the business unit (developers) voice and wireless since 2 days, but actually we do not have a solution.
how are you doing with your VoIP design? We also redesigned some spots, but we still have voice gaps and it is annoying.
In the meantime, we decided to request for help at another distributor.
They sent their wifi specialist and after one day of testing he was sure,
that this isn't a problem of a wrong configuration or missing coverage or something else,
but it's a failure of one of the components in the wifi network.
Therefore he opened a cisco TAC case and meanwhile cisco is analyzing several debug logs and protocols.
According to the statement of the wifi specialist, cisco should be able to find the failure this week.
We will see......
thanks for your feedback, exactly the same process as we are running through.
We arranged a site survey with another wireless specialist (third opinion) and the specialist is also sure, that this can not be a design (configuration or coverage) problem. You can stand next to an access point but the phone will not roam to it in the first 20 - 30 seconds, only after this time the phone can see the access point and roams to it.
It would be nice, if you send me the feedback of Cisco, maybe this would help to force our case. Do you have a case opened at Cisco?
if you wish, you can contact me directly by email (f.wagner AT lissmac.com),
i'll send you my contact information and we could exchange information via phone.
thanks a lot for your contact information. I will send you a mail or will call you as soon as possible. We got a great message today, there are two Cisco engineers (business unit) comming onsite this week and I hope we are going to solve our problems!
As soon as I know more, I will contact you. But as a hint, if I forget it (this happens a lot at the moment ;-)) just reply to this post and I will contact you.
Just following up on this old thread in case anyone stumbles across it ...
The scanning/roaming algorithms in the 792x phones are greatly enhanced in the 1.4.2 (and above) firmware. Anyone encountering problems such as are described in this thread should be sure that they are running current firmware.
How was the meeting with the Cisco engineers?
Did it help analyzing or even solving your problems?
it was very interesting and we saw, that even these experts had to acknowledge, that this building is not easy to cover by wireless. They said that the building is like a bunker and we also found out, that the elevator is interfering the 802.11a band massively.
We found these key points:
- we have RF coverage problem at some spots, but even Cisco had to say, that it is not helpful to install more access points on specific locations --> they are talking with their advanced services to find a solution for that
- on other spots we will install additional access points to improve the coverage
- the wireless expert found two bugs on the phone load, they phone unit is working on it
We should get some answers until Friday.
I will update this post.
actually we god a recommendation for improving the RF situation with external antennas. We ordered the hardware and after that, we will do some onsite tests to see, if it gets better.
On the other side Cisco is working on theses bugs:
CSCtg74904 11n APs stop transmitting and receiving with spike in noise/interference
CSCti74211 CCKM timestamp validation fails on roaming after coverage problem
CSCti74400 7925 reaching max retries causes long connection drop
We are waiting for the firmware they will hopefully provide for us. This are all the news I have at the moment, sorry for not providing any more information.
oh no, that are good news for me.
Because in this moment, I've here an SE who is making another (the third) one) site survey for Cisco for our TAC case.
And now I've got 3 Bug IDs I can give him.
Maybe we are running into the same problems as you.
By the way, you are also using firmare 7.0.98 on your controller, aren't you. Which kind of controller do you have?
What kind of access point do you have? Are you phoning over 2,4 or 5 GHz?
And have you tested with 7921 phones or 7925 phones?
> By the way, you are also using firmare 7.0.98 on your controller, aren't you.
Yes we are using 7.0.98 as controller software.
> Which kind of controller do you have?
We have the 5508(-100) controllers.
> What kind of access point do you have?
Actually we are using the 1142N (dual band), but now we plan to test with the 1262 and the external antennas AIR-ANT5160NP-R.
> Are you phoning over 2,4 or 5 GHz?
We are using 2.4 GHz for data / clients and 5 GHz for the ip phones.
> And have you tested with 7921 phones or 7925 phones?
Yes we tested also with 7921 - it was a little better because of the diversity antenna in the 7921, but we also faced the noted bugs.
We've got exactly the same issues here.
The only difference ist, that we are using 1252 here with a 4402-50 controller.