Anyway microphone send volumes can be changed from End Point Manager?
We have a bunch of Sangoma S500 phones. Our problem is the microphone is too sensitive (can’t be closer than two inch of the handset).
We adjusted the HandSet Send Volume setting in the web interface of the phone. Phones perform better but that setting is lost when the phone is rebooted. Anyway we can make these settings stick?
Same problem here across two installs. It’s hard to tell them “you’re using it wrong”
Can you tell me the issue ID you opened?
You can change this with a basefile edit…
P20083
EPM Default Value: 0
Description: HandSetSendVolume
P20084
EPM Default Value: 0
Description: HeadSetSendVolume
6 = -6dB
5 = -4dB
4 = -2dB
Anything but 6 (or -6dB) is really loud unless you are 2" away from the handset.
I logged an issue not for the EPM, but for the phone itself: https://issues.freepbx.org/browse/TELE-642
This is definitely an issue, although it can be worked around fairly easily via a basefile edit.
Mike
With over 70K phones shipped world wide this forum post is the first time this has been mentioned. I find it odd that 2 people have reported this out of 70K. I wonder whats different in your setup that causes the volume to be so high. Is this on calls out a trunk or on even ext to ext calls.
Maybe it’s an Avaya conversion thing, as both of these clients came from that platform. It happens on all calls regardless of trunk or extension to extension.
Maybe allowing an EPM setting (versus basefile edit) would make all parties happy.
I guess they are “using it wrong”
I never said or thought someone is using it wrong. I am trying to understand why you have 2 customers having this problem and nobody else really is. Something has to be different somewhere. Just trying to understand what
In my case it has nothing to do with Avaya. Per Sangoma tech support we updated firmware from 1.31 to 1.37 and the auto gain control feature worked fine again.
I think EPM should have an option to do this automatically (update firmware). Maybe it does and I don’t know of it. I do agree a “roll firmware back option” should be available but I think auto-update should be available and should be the default option.
This latest firmware also partially addressed the “receiving call while dialing issue”. In 1.31 the phone (S500) simply wiped the dialing effort and displayed the regular “incoming call” interface. We’ve open a ticket many months ago and it looks like “something” has been done about this. In 1.37 the dialing effort is no longer wiped. The phone simply rings and the icon and the BLF LED is updated on the matching line button. Pretty good I would say. The issue is if one decides to cancel dialing the interface no longer updates the context sensitive soft buttons and caller id for picking up the call and subsequently handling it. The only way to pick up the phone is to press the line button or, I think as I have not tried it, pick up the handset.
We’ve now tested Digium, Yealink and Polycom phones. All of which have very solid core functionality. Their only issues stem from compatibility with EPM. Don’t mind me venting my frustration but it really feels like we are beta testing some early product releases. AGC and handling calls while dialing is core stuff not new and sophisticated features.
We contacted E4 technologies, the East Coast Sangoma rep from which we bought the phones. They in turned opened (per their admission) a ticket with Sangoma but I am not privy to the ticket number.
In my humble opinion this seems to be an issue with AGC not working. So no need to add interface settings for manually adjusting the send volume, devs just need to make sure AGC works properly.
Like I mentioned, firmware 1.37 corrected the problem for me.
One client was on 1.36 (which I moved to 1.37 today), yesterday I upgraded the other to 1.37.
In both cases I did a basefile edit on install to put the handset send volume at it’s lowest setting which seemed to alleviate the issue.
I don’t know, I’ve dealth with Polycoms and Ciscos and never had something as basic as this be an issue… but it could be something with how the users in both cases were used to interacting with the phone when coming from Avaya equipment. I just sound silly saying, “hold the phone differently”
I too lean towards Sangoma phones for a better user experience and better EPM compatibility like you.
I asked a colleague who did a deployment of S500s for a church/school and they said no issues like mine.
Who knows!?
The employees are moving from a Digium Switchvox setup and before that (3 years ago) from an old school PRI based PBX machine with Panasonic phones. Most of the guys are career salesmen with 20+ years on the job. There was no way I was going to tell them to remember to keep the phone a certain distance from their face.
Just to cross all the T’s, an individual reboot request sent from EPM is required for the phone to reboot and upgrade to the latest firmware. “Save latest changes and upgrade phones” option from EPM will no cause the phones to reboot for most changes. You can also reboot the phone manually.
We would not force firmware updates. We use to do that and took holly hell for it.
Firmware management is done right from EPM and is easy as drag and drop a firmware into the slot and tell the phones to reboot.
Maybe go back to forcing updates but with better quality assurance?
It has nothing to do with QA. You will never ever ever catch everything and customers dont want to be forced to update. Its a set it and forget it and only want to update when I want something new or to fix something.
I continue to have this issue at my two sites utilizing FreePBX (both 13 and 14), Vitelity SIP trunks or PRI and S500 phones. Send volumes are very loud when people are talking close to the phone. It’s like there’s no AGC on these phones - god forbid the person on the S500 end starts talking a little louder; it sounds like they have the handset in their mouth. I’ve deployed 40 phones in total and they all exhibit the same issue. I have upgraded the firmware to the latest as of this writing and have made the basefile adjustment listed above. One of the owners of the businesses I sold this system to really tuned into this problem and can’t stand it. I look like a real jerk for recommending these phones.
I was reminded of this today when I was talking to someone at one of the above sites. Sounded great until she got a little louder… same problem.
I don’t know, but I think this will be my last S500 install.
I don’t know what to tell you. We have AGC and the only place someone has ever complained of this is on this thread with well into 100k phones sold and installed if it was a problem we would be hearing it from everyone.
You can try and contact support and let them get logs with you and a sample recording from the PBX and PCAP from the phone and include that in the ticket and we can take a look.
I would direct you to a ticket I opened, #772027
Please listen to the 16 call examples and relevant portions of the conversations I provided across two completely different sites. The only common denominator is both sites are using S500s. The problem can be easily reproduced and it only took about 4 hours of calls at these two fairly low-volume sites (only recording a handful of extensions) to provide these examples. External calls, internal calls, all share the same issue. The LANs are flat, small, and pretty basic.
This problem is not a figment of my imagination. These sites are literally 100% Sangoma!
I just deployed a new site with Yealinks, on FreePBX 14. If there were any problem this particular client would be screaming from the mountaintops and excoriating me… they are that type of client. They do not share the same issues as the above two although they share a very similar infrastructure and same SIP provider to the other sites with S500 phones.
I am having this same issue with my s500 phones. Even with a -6db volume set in the phones web based gui the s500’s have a feedback/senstive/hot Microphone for the person on the other end of the line to my employee who is on the sangoma phones. The s700’s have it but to a far lesser extent. Have you found any work arounds?
We narrowed it down to G722. If you use G711 the issue doesn’t occur. In the grand scheme it doesn’t really matter since the PSTN is G711 anyway.