Elastix 2.5 Audio Issues
-
Are there calling issues extension to extension or only when going out to the trunk provider?
-
I am trying to get the client to try right now for extension to extension.
-
I believe that there are two ISPs hooked up to that system. I would validate that it is definitely going over the FIOS line and not the other one. Issue could easily be caused by it flip flopping to the backup line which is very slow and saturated.
-
@GregoryHall said:
My other thought was to completely rebuild the Elastix VM with the legacy adapter and export then import the settings from the old one to the new and test.
If this is an option, move to VMware. Don't spend time troubleshooting on HyperV. That's not been tested.
-
I feel like the Legacy Adapter is the way to go on Hyper-V and I think I am going to try and add the legacy adapter to the existing Elastix and remove the other advanced adapter and see if it plays nice. I would like confirmation again that switching out a NIC on CentOS is as straightforward as doing it on Windows?
-
@GregoryHall said:
I also found a setting for the QoS / CoS that will look for DSCP tags and prioritize that traffic but I cannot for the life of me find where to set that in the FreePBX. A networking friend of mine told me to set this in the VOIP phones and match that tag on the Switches so that they know it is high priority / expedited forwarding but I cannot find in the phone interface where to set that.
There is no way that the switching fabric is saturated, just not a realistic concern. QoS might be needed on the router but that would be exclusively for the audio that is sent, not received. So people calling into the office might hear things better, but it does not affect what people hear in the office itself.
Don't even look at QoS on the switches, keep the switches as vanilla as possible. In this setup, any configuration there is just asking for issues.
-
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?
-
Ext. to ext has the same call quality issues.
-
@GregoryHall said:
Internet Pipe is Verizon FIOS with 100/100 so I know that is not a issue unless I am not setting MTU correctly for the FIOS?
If the 100Mb/s WAN link isn't an issue, the 40,000Mb/s switching fabric definitely isn't.
-
The call quality is horrible. You hear about one syllable from a word then it breaks up. If the other person talks it goes totally dead then comes back.
-
@scottalanmiller I made sure that the second line is only active during failover. All speed tests are way higher then the second ISP can provide so I am confident this is all over the FIOS line.
-
I really want to try the legacy nic but I want someone to second that...
-
@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.
