nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Dropped and Garbled audio with SpectraLink 8440 Phones

unknown

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.

Find more posts tagged with

Accepted answers

All comments

unknown

Hi Steve - I've found this info re Spectralink

For optimal voice quality, Self-Healing and Background Scanning should also be disabled when Spectralink Compatibility is enabled on any AP

unknown

Hi Steve, you may nee to change the default DTIM settings through the CLI on the ZoneDirector. I've had a customer before with the polycomm phones and I found some documentation for the 8440's mention the DTIM value settings requires changing to '2' on your Voice SSID WLAN

unknown

Thank you for the responses, I have already made these changes with the same results. At this time the VIEW teams of SpectraLink and Ruckus are working together to solve this issue. Hopefully they will have a fix very soon.

unknown

Hi Steve

We're also experiencing problems, which Mitel and SpectraLink are looking into... which have been plaguing us since our system was installed back in February.

The WiFi part of our phone system consists of a Mitel 5000 HX, Ruckus ZD1112 + 11x ZF7363, SpectraLink 8440's and Cisco SG300-28P switches. Are you much the same?

Matty.

unknown

We have a 6 cabinet Toshiba CIX 670 PBX, a Ruckus ZD 3000 with 80 zf7363 and zf7762 APs, Cisco switches, and 95 SpectraLink 8440 phones. The best I could ever get is using 5 GHz on the inside APs and 2.4 GHz on the outside APs. To get you by while they fix this I suggest changing your APs to use 5 GHz only using channels 149-165 which is sub-band 4 on the phone. Use Auto for power on the phone and APs. You still get the hight Tx and Rx retries on the phone but it's less than 2.4 which seems to reduce the audio drops. Remember that 5 GHz has less range so if these phones are used outside, like mine, then they will not be able to go as far. That is why I had to keep my outside APs (zf7762) at 2.4 GHz. This is at a huge car dealership campus where it is spread out with multiple buildings and users walk all over the place outside too.

unknown

Hi Steve

Luckily for us, the majority of our phones are Mitel 5330e's which we have very little trouble with - and only 7 users on SpectraLink 8440's.

We're using 5 GHz sub-bands 1 and 2. For some reason, if we have all 4 sub bands enabled, we found that the phones would not work on channels 100+, so we decided to disable sub-bands 3 and 4.

We were advised to change our power settings to Auto both on the AP's and the phones, but that actually made things seem worse, so we changed the handsets back to their defaults, P5.

Have SpectraLink or Ruckus come back to you yet?

Cheers,

Matty Brown

unknown

I was using my co-worker's login when I started this post but now mine is fixed. SpectraLink made a site visit and we found one substantial issue. It seems that the Ruckus APs are not changing channels when another AP in close proximity is on the same channel. So we were getting co-channel interference. We then statically assigned the channels in an area and are currently testing this area before we static the channels for the whole campus. I don't think that is everything but is a big chunk of it. Ruckus did have a SpectraLink no-audio issue in an earlier software load. I would get the ZD to the latest and 4.3.0 on the 8440s. If you stay on 5 GHz the SpectraLink person recommended sub-band 1 and 4 only. If you have trouble having both enabled check in Services or System and there is a setting for optimize for compatibility or performance in the Ruckus ZD. That may need to be adjusted.

unknown

Yes, I noticed that too - back in June I pointed this out to our reseller, who in turn spoke to Ruckus, who replied "If there is no interference or less interference on the specific channel, Even though the APs are in auto mode, Unless the APs reach certain threshold value , They will not change the channel. They will remain in same channel."

I think the problem with this is that our WiFi is only really used for VoIP and therefor barely any bandwidth is used so I would think we're unlikely to hit their threshold values. I guess if we had laptops on WiFi sending file across the air, our AP's would move to cleaner channels.

I guess the only downside of manually configuring channels for your AP's is that if there are neighboring sites using 2.4GHz or 5GHz your AP's will not swap channels to avoid conflicts.

Let me know how your tests go - hopefully you're onto a winner there.

unknown

I noticed on Friday that a new firmware, v4.6.1 has been posted on SpectraLink's website on 02/10/2013.

We loaded it late on Friday to a couple of handsets and did a walk test. The results were promising - routes that would previously have resulted in high data loss were vastly improved. But we've been here before - I'm not getting my hopes up this time!!

All of our handsets have now been updated to the latest firmware... we'll see how it goes next week.

unknown

I checked that out, but it's for the Microsoft Lync support and we are not using that. So it looks like the latest for me is still the 4.3.0.

unknown

All that means is that the firmware additionally supports Microsoft Lync 2013. It doesn't mean that you have to be using Lync to run the firmware. See page 7 of the release notes to check if the firmware is compatible with your hardware. Ours are - yet we never asked for Lync support.

On a side note, the new firmware kind of fixes one issue and causes another. No more large packet losses, but the phones seem to have trouble handing off (roaming) to other access points.

Will these phones ever work properly?? 😞

unknown

Hello, I would like to join this convo. I have a zd with 16 access points. 7363s. It seems like forcing channels on individual access points helped, but its still not perfect. I updated to 4.6 firmware, but that made it much worse for me so I downgraded.

keith_redfield

First of all, thanks everyone for contributing your experiences here - I think this is a good example of how forums like this can enhance overall resolution.

Our engineering team has been working with Spectralink on this issue. There are several contributing factors - best practice guidelines, a high number of independent variables in the environment and some software quality issues.

I have anecdotal reports from other sources that turning down the transmit power on the APs seems to help.

We also have a new version of 9.5 (9.5MR3) coming out in the next few days and that has some fixes that also look promising.

I'm not going to declare victory (yet), but I think we are getting close. We appreciate your patience while we work through this issue.

unknown

Here's hoping! Do us a favour and post something here to let us know when the new firmware is available to download!

I presume a new version of 9.6 will incorporate the same fixes, too?

keith_redfield

It will go in the company announcements area as usual.

Yes, the next version of 9.6 (9.6.2) should have these as well, but it's still a ways off.

michael_brado

I suggest to provide a ZD debug, and AP support info, gathered when a phone

with a known MAC address is on the AP or APs, and open a ticket with Ruckus

Tech Support.

If you are running ZD 9.6.1.0.15, latest Spectralink code, and still appear to have

short silence or one-way audio, do the problems seem to be related to roaming and

can you collect the ZD debug, and AP support info of the To and From APs the

phone roamed between? This is the info that can provide some clues to identify

a known issue/bug, or normal poor client connection in the face of interference.

unknown

9.5MR3 has been released... look here for the announcement and here for the release notes.

unknown

Did anyone try this release and see if the problems went away?

unknown

Yes, I tried this release. It seems to work well, except since installing the firmware, phones are unable to roam to/from two of our AP's. Further investigation is needed to figure out what went wrong.

unknown

I updated, it didn't do anything for me still garbled and choppy. ugh

unknown

The 9.5MR3 firmware continues to give us good call quality 99% of the time. Still some issues with roaming between AP's though, especially when the phone is not in a call. Phones can lose signal when moving from one area to another and standing directly beneath an AP. Is roaming somewhat limited whenever you're not on a call? Also - is rebooting after losing/regaining a connection normal?... not quite sure why it does that, though I guess that's a SpectraLink issue rather than something Ruckus can help with.

All our SpectraLink 8440's are on firmware 4.6.1.0011.

unknown

Hello There,

I am wondering is there a way to soft test a 8450 phone.

unknown

Hi guys, after some testing, I am on the same page as Matty Brown, we have good quality 99% of the time, but we have troble roaming while on call. Sometimes, headset has to be restarted to regain access to the wireless. Running 9.5MR3 and phones are on 4.6.1.0011

unknown

Well, we're still having problems with our Ruckus/Spectralink equipment and we're shutting down for Christmas at 5pm today. Hopefully a solution to the problem will be released early 2014...?

Happy Christmas everybody!! 🙂

unknown

Wait a minute...

"Spectralink Optimization"??

Have Ruckus finally come up with a solution?

keith_redfield

That change is a set of best-practice settings enabled with 1 click. It's not a fix to anything per se, but might be worth a try.

joe_statter

Hi Guy's the Spectralink issues and the ASCOM /ALU 8118 phone problems have now been mostly resolved in the new 9.6.2 MR available on the support site.

unknown

We've been running 9.6.2.0.13 for the past two days with some success. It was someone at Ruckus that recommended that we try this release.

As far as I know, Spectralink/Ruckus are still a way away from gaining VIEW certification, but this release seems a step in the right direction.

Spectralink 8440's still on 4.6.1.0011.

unknown

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.

unknown

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.

unknown

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.

unknown

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?