Poor Audio Quality with .82 Firmware

Out of the blue, we began experiencing the issue described at Sangoma phones require a weekly reboot - phones would just start behaving like they had a process running away, consuming 100% of their CPU time. It only affected the s500 & s705 phones, which were both running the .72 firmware.

Seeing there was a fix in .78, I applied the latest revision - .82 as of this post. I immediately began receiving complaints of poor call quality. People sounded tinny, the first few seconds of the call were extremely quiet, customers saying they can’t hear us, etc.

I am about to go up and revert these phones to .79 or .78 to hopefully resolve the issues, but wanted to report it. Worst case, I’ll put .72 back on & they can live with rebooting their phones when it happens…

Is anyone else experiencing problems like this with .82 ? Is there a known easy way to trigger a reboot of the phone from the server command line? (My thought is to write something to interface with the phone’s GUI, but am hoping there’s a tool already available. If I could schedule the phones to reboot themselves say 2 hours before people get here, it should eliminate the issue with .72…)

Firmware version .78 also had ‘crackling’ audio & no audio at the beginning of calls for 1-3 seconds. I put .72 back on & call quality is again good.

Now to see if I can find a way to trigger a reboot of the s500 phones in an unattended way to eliminate the other issue…

There were audio related changes made in both .73 and .75. Did either one of those introduce it for you, and not specifically .78 or .82?

Hi @RealRuler2112

I recommend you open a phone hardware support ticket for this so the findings can be escalated properly

Unfortunately, our operators decided they were done with trying new firmwares, so I’m unable to try others @mdavenport … possibly if they experience further issues in the future, I can bump them up incrementally - the users (understandably) just want the phones to work.

We were not told that the support credits expire after 6 months when we bought the system @lgaetz, even though they’re priced and purchased as if they last a year. Because of this and other omissions during the sales process, management decided to drop support and just have me fix everything. (Lucky me… :roll_eyes: :cry: ) Because of this, I cannot open tickets with Sangoma & instead must rely on help from the forums; this is doubly bad as I enjoyed working with you, even though I didn’t like the end result much. Won’t be the first time & I’m sure not the last time I’m sabotaged by sales people not telling you everything though…

For those who are on an older firmware and experience the issue referenced in my original post, I found a very simple & easy way to trigger a reboot. It’s said to only work on Sangoma phones, but Sangoma phones are the only ones that are having the issue so it works out well.

fwconsole epm reboot <ext>

Simply create a script with as many of those lines as you need and create a cron job to run the script a couple of hours before the users arrive for work; the phone will have a fresh boot and not have the laggy / sluggish performance.

You don’t need support credit for a phone ticket.

As to your support experiences, please feel free to reach out to me via email, I can put you in touch with people in support. It’s my forum username @ sangoma.com.

Are you able to share the logic behind what problems you need support credits for & what problems you do not? This isn’t the first time I’ve run into this type of thing & do not understand what issues require support credits and which do not.

As a very general rule, if you have bugs or technical issues with paid products, the support is included in the purchase price. If you are seeking assistance with config, or setup or want bug support for free products, then credits are required.

Real, what other changes happened when this started happening, did you make updates to FreePBX?

The only deviation from the norm was that I was working remote for just shy of 3 weeks and my desk phone sat idle that entire length of time. When I returned, I noticed it would take literally 2-3 seconds to acknowledge key presses. A reboot of the phone fixed it, but then I heard our operators (whose phones had not sat for any appreciable length of time) were experiencing the same type of thing. No clue how/why my s705 sitting idle would affect their s500 phones, but they never experienced it in the time prior; IIRC, .72 was applied to their phones shortly after it was released. The timing might just be a coincidence, though the older I get the less I believe in coincidences like this. :wink: This is when I updated the firmware to .82, downgraded to .78 due to call quality problems, then downgraded again to the .72 they had been running on & wrote a script to reboot the operator phones nightly to avoid the slowdown issue. No changes or updates have been made to the system since well before the slowdown apart from changing the names on extensions & resetting VM passwords when people change.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.