Dropped and Garbled audio with SpectraLink 8440 Phones

  • 2
  • Question
  • Updated 5 years ago
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.
Photo of Steve Dreher

Steve Dreher

  • 3 Posts
  • 1 Reply Like

Posted 6 years ago

  • 2
Photo of Michael Daracz

Michael Daracz

  • 7 Posts
  • 0 Reply Likes
I second Mattys Comment, My spectralinks are usable, but from time to time I still have garbled dropped audio. Its far far far less though.
Photo of Luke Sandberg

Luke Sandberg

  • 3 Posts
  • 1 Reply Like
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.
Photo of Mike Levesque

Mike Levesque

  • 1 Post
  • 1 Reply Like
this also sounds like a codec G.711 Issue try G.729 and QOS setting.
Photo of Keith Hoover

Keith Hoover

  • 15 Posts
  • 2 Reply Likes
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.
Photo of Matty Brown

Matty Brown

  • 34 Posts
  • 3 Reply Likes
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?
Photo of Keith Hoover

Keith Hoover

  • 15 Posts
  • 2 Reply Likes
I am running 9.7.0.0.220 with the optimization .... I'm not sure I've noticed much of a change.
Photo of Matty Brown

Matty Brown

  • 34 Posts
  • 3 Reply Likes
We're continuing to use 9.6.2.0.13 on our ZF7363's with statically assigned channels. We've also recently updated our SpectraLink 8440's to 4.6.1J.0034 and added "<apps apps.telNotification.heartbeatTimeoutSeconds="30"></apps>" to our site.cfg file.

Our phones are now working perfectly. (Hope I haven't just jinxed it!)

Is everyone else now happy with the call quality of their SpectraLink 8440's and Ruckus AP's?
Photo of Scott Moran

Scott Moran

  • 3 Posts
  • 0 Reply Likes
Matty,

Are you using 2.4GHz or 5.GHz? Or both?

We're running Ruckus 9.7.1.0 build 17 and v4.6.1.0011 on our 8440's and the performance is still only fair > okay.

Did you find a major improvement once you upgraded the 8440's to 4.6.1J.0034?

Thanks,
Scott
Photo of Matty Brown

Matty Brown

  • 34 Posts
  • 3 Reply Likes
Hi Scott

I've disabled 2.4GHz on our phones and only have sub-bands 1 and 2 enabled on the phones, which means that the 5GHz channels we had available to us were 36,40,44,48,52,56,60,64 (I'd previously found that the phones wouldn't connect to AP's on channels 100+, even if all sub-bands were enabled).

When we moved over to 5GHz last year we noticed a dramatic improvement.

The call quality was already good before updating to 4.6.1J.0034. The difference I noticed with this firmware was that calls are now going through more reliably and ringing straight away. Since we use Xarios Phone Manager, I used to be able to see a call coming in on the call banner on my PC up to 8 seconds before my phone started ringing!

Matty Brown
Photo of Scott Moran

Scott Moran

  • 3 Posts
  • 0 Reply Likes
Hi Matty,

Thanks for the response.

We've found the voice quality far superior on 5GHz, but we have issues with the 8440's randomly being disconnected from the network - even when they have ample signal. It seems it's the roaming that's letting us down because anyone using the phone while they're stationary are affected to a much much lesser extent.

Would you care to share some screenshots of Ruckus config for your SIP wireless network? There are so many settings in there that can affect the handsets, it's hard to know where to start. Especially regarding CAC, because we've got conflicting documentation from Spectralink.

We've only been able to use sub-band 3 (in Australia), so I think all of our channels are 100+ but I'd have to double check. I wonder if that's a contributing factor for our roaming issue(s)?

Scott
Photo of Scott Moran

Scott Moran

  • 3 Posts
  • 0 Reply Likes
Which codec are you using Matty?
Photo of Matty Brown

Matty Brown

  • 34 Posts
  • 3 Reply Likes
The WLAN our phones are connected to are configured like this:
https://www.dropbox.com/s/0iplgrs58ifr7r6/Voice%20VLAN.png

Our AP's are configured all the same, except for the channel numbers that are assigned to them:
https://www.dropbox.com/s/73nda2w5hezu1g4/System%20Default%20AP%20Group.png

Audio Codec Priorities are as per the defaults, as far as I can remember:
https://www.dropbox.com/s/fyl66zfa5pf6ksq/SL8440%20Audio%20Codec%20Priority.png
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 52 Reply Likes
Matty - great news! - thanks for sharing your observations!