Elastix 2.5 Audio Issues
-
@Minion-Queen said:
Ext. to ext has the same call quality issues.
Okay, this means that either there is a networking issue on the switches (look for saturation on the uplink) or that the issue is with the VM itself. Get a pair of phones moved to the same switch as the PBX to eliminate as many variables as possible and test again.
This eliminates the trunk provider, the router, the WAN link, etc.
-
@GregoryHall said:
I really want to try the legacy nic but I want someone to second that...
Can't hurt at this point.
-
@scottalanmiller ok I am going to try that now
-
@GregoryHall said:
The ESX host is very overloaded and I fear that would introduce a hole new can of worms that will need to be addressed. Especially if all I need to do is switch over to the legacy adapter on the existing setup and be done with this...
Advice?
Switch the adapter, but I would make a secondary VM for testing as well. Pretty quick and easy once all of the config is done like it is.
The VMware box should not be that overloaded. What capacity issues is it facing?
-
@NetworkNerd said:
I specifically remember getting burned when using VMXNet3 on an Elastix VM on VMWare and having to have someone change it to the Intel E1000 on VMWare so things would work as expected. That did not affect the VM configuration / cause it to have problems after the change was made.
Likely this is because of the CentOS 5 base. Once this updates to CentOS 6/7 that shouldn't be an issue. The VMXNet 3 driver is super fast and solid.
-
I have FreePBX V 2.11 running under HyperV with the updated virtual network adapter and haven't seen this issue. I've had several calls going at once during testing and didn't have major jitter related issues.
-
Seems to me that if you are having Extension to Extension quality issues, then you can cut out the EdgeMax and FIOS. Focus on what is between the extensions. How many extensions are there, and does it occur on all of them? As @scottalanmiller stated, keep the switch configuration to the bare min so that if you have a failure and end up with a different model you don't deal with re-config issues.
What is your resource load - 4GB may not be enough and you could be losing bits in the buffer.
What other devices are connected to the NetGears? Wireless? Desktops?
-
@coliver said:
I have FreePBX V 2.11 running under HyperV with the updated virtual network adapter and haven't seen this issue. I've had several calls going at once during testing and didn't have major jitter related issues.
This is Elastix 2.5, not FreePBX. Don't know what version of HyperV is being used.
-
@g.jacobse said:
What is your resource load - 4GB may not be enough and you could be losing bits in the buffer.
4GB is way too much. Should not have gone over 1GB and should really be more like 800MB. Anything over 1GB is just wasted.
-
@scottalanmiller said:
@g.jacobse said:
What is your resource load - 4GB may not be enough and you could be losing bits in the buffer.
4GB is way too much. Should not have gone over 1GB and should really be more like 800MB. Anything over 1GB is just wasted.
I would agree not to go over 1 GB RAM for a small install. And I'd do this too: http://www.scottalanmiller.com/linux/2012/09/02/improving-elastix-memory-usage/.
-
Crap internal call quality does usually point to something local. If someone is on site, can you take two phones and plug them into the switch directly while removing all the others? Maybe something is flooding the switch with shitty packets.
Another spot to check would be the Hyper-V interfaces. Are you sharing a single NIC with the rest of the environment? Is it setup properly to the switch with regards to speed and duplex? Are you having any throughput issues through SMB or other local protocols?
See @Minion-Queen, this is what happens when you try to get a hold of me in the morning.
-
@PSX_Defector said:
See @Minion-Queen, this is what happens when you try to get a hold of me in the morning.
Sae here, I spent an hour playing Ingress this morning
-
We are moving this to their backup cloud system for now. My team traced it down to Hyper-v (they can fill in details later) and decided to put it on it's own box.
-
@Minion-Queen said:
We are moving this to their backup cloud system for now. My team traced it down to Hyper-v (they can fill in details later) and decided to put it on it's own box.
I would be interested in hearing those details.
-
Was it just the nic driver or single nic shared by many vms?