Dropped and Garbled audio with SpectraLink 8440 Phones

[steve_dreher]

I have a site with 95 SpectraLink 8440 phones and 80 APs with a ZD 3000 running 9.6.1.0.15. We experience dropped audio for up to 8 seconds and then the call will come back. The SpectraLink phone logs show very high Tx and Rx retries. I was told this ZD load addressed dropped audio issues with SpectraLink but we continue to have issues. The SpectraLink phones are at 4.3.0 which is also the latest software. The inside APs are on the 5 GHz band to reduce interference with a separate customer WiFi and the outside APs are on 2.4.

[luke_sandberg]

I have been talking to one of our Ruckus reps about the new 9.7.0.0.220 release. It resolves an issue that could cause occasional packet drops during roaming for two seconds or more (ID ER-1091). There are also some other fixes and enhancements too. Also, I'm not sure if you all know that SpectraLink has confirmed the roaming issue with their phones. When not in a call the phone is triggered to roam only on extremely low signal strength. When you receive a call then the phone switches to an aggressive roam and searches for a high signal strength AP. If you answer the call quickly you may get no-audio for a second or two while the phone connects to the strongest AP. In talking with SpectraLink it is proving to be a difficult thing to change. So basically I am waiting for SpectraLink to let me know when it's ready. When it is I'll probably upgrade our ZD to 9.7.0.0.220 from 9.6.1.0 and then upgrade the phones to this new level and hopefully that will do it. My customer has stopped reporting problems now and is just living with the issues. One of the biggest improvements was statically assigning the channels on the APs. For 80 APs this took a while, but we had to because we were finding APs 50' apart on the same channels. The APs just seemed like they were constantly changing channels.

[mike_levesque_6]

this also sounds like a codec G.711 Issue try G.729 and QOS setting.

[kieth_hoover]

In case this helps... I got this from a high-level Ruckus engineer...

ZD/AP Configuration when supporting VoIP
• It's best to configure a separate WLAN for voice and for data. The AP will do a fine job handling prioritization, but when you hand off the traffic to the Ethernet switch it really helps to have already separated the traffic into different VLANs and/or subnets so that the core network can be easily configured to maintain that prioritization.
• For any VoIP system but Polycom/SpectraLink you can keep background scanning enabled, but you will want to change the default setting from a 20s interval to at least 300s. Polycom/SpectraLink states in their best practices guides that you should disable it altogether. If the customer does not and then has any issues at all and need to contact Polycom, they will not provide support until background scanning is completely disabled.
• Polycom/SpectraLink requires that channels are fixed. Do not allow the ZD to change channels through the older method (via background scans) or via ChannelFly. Their handsets only support 802.11h on the DFS channels, not on the lower or higher 5 GHz channels nor on 2.4 GHz channels, so they will not react well to ChannelFly at all.
• Polycom/SpectraLink handsets have a serious issue with being too close to an AP. This is problematic. They state in their best practices guide that you must turn down the APs to approximately the same power output as the handsets (reduce from max by 3 dB). This causes you to use more APs. But with more APs there are more locations where the handset can end up very close to an AP (within about 10 to 15 ft). Which, in turn, means that you have more locations where the phone does not perform well. Turning down the power more to reduce the problem means adding more phones, again increasing the occurrences of the problem. It's a vicious cycle. The problem is a hardware issue with their phones.
• Except for Polycom/SpectraLink and Vocera, it is best to leave the power output of the APs at the default setting. This will provide the best performance, decrease the number of APs required, and decrease self-interference issues.
• Vocera badges are very low power. It is best to decrease the AP power output by 3 dB when supporting Vocera.
• Many handsets are very picky about the DTIM setting. We default to a DTIM of 1, but many require that you have it set to 2. You may need to go into the ZD CLI to change it to match what the handsets require.
• Disable Load Balancing when supporting VoIP. The Load Balancing process induces jitter when the handsets roam.
• Polycom/SpectraLink handsets and Motorola TEAM phones do not support channel 165. You will need to blacklist that channel to keep APs from being configured to use it by the ZD. There might be others with this issue as well. I don't know.
• Don't use mesh with VoIP. It adds too much jitter.
• 5 GHz is a much better choice for VoIP than 2.4 GHz. Less interference, more channels to use, less of an issue with APs hearing each other. And, you can more readily affect the cell size to encourage smoother roaming. However, there are many VoIP handsets that do not yet support 5 GHz.
• Ascom is a great company to work with. Whenever they have a new handset, they call us to test with out equipment and then they just work.
• Cisco VoIP works very well over our APs as long as you disable CCX, a set of Cisco proprietary extensions to the SIP protocol. These extensions actually do improve roaming performance, but we do not support them and if they are enabled, roaming is very poor.
• ShoreTel is another good company to work with. They also have a system that makes it possible to use your cell phone and have it switch over to WiFi when WiFi is present without any user intervention — very cool stuff.
• Polycom/SpectraLink and Motorola TEAM phones do not support 802.11h in all 5 GHz channels (as they should by the standards). They only support those that require DFS.
• Most VoIP systems state that you need to have –65 dBm signal strength at all locations. However, it is more important that you have a good SNR. This is typically 10 dB at a minimum. If the noise floor is very low, I find that a –70 dBm signal can be great. If it is high, well, that just becomes very difficult as the phones have very weak antennas and are blocked often by the user's body. Test these things using the handset, not using a laptop.

[matty_brown]

Has anyone tried Ruckus 9.7.0.0.220?

We're still on 9.6.2.0.13. We barely get any dropped/garbled audio now. But we do seem to have an issue where at the start of a call, if the phone has been idle/in standby for a while, it takes several seconds for the phone to start ringing. However, if you ring it straight after it's already rang, or after it's just been used, it's fine.

Maybe what I need is the "Spectralink optimization" option found in 9.7+ to sort out the remaining issues? Or is it more of a Spectralink firmware thing?

[kieth_hoover]

I am running 9.7.0.0.220 with the optimization .... I'm not sure I've noticed much of a change.