VoIP quality issues switching from SG-8860 to XG-7100
-
Ok, so I've been wracking my brain over this one for the past few weeks, and have finally figured someone here might be able to help. We have had a VoIP solution from our CLEC/ISP. All was working fine until we upgraded from a single SG-8860 to dual XG-7100 units in an HA setup. Since then, we have been having voice quality issues(mostly stuttering, calls are NOT being dropped), provider says where all was working before the switch, the problem is on our end, and I wholeheartedly agree with them, and am running out of places to point the proverbial finger at.
Their system uses a dedicated SBC connection coming in on our dedicated wavelength circuit. The SBC uses a /27 that is connected to an interface separate from our internet. The first 3 IPs are designated for client use, as long as .1 is where data is connected through, so .2 is primary, .3 is secondary, and .1 is the CARP VIP. I have everything run into an EdgeSwitch, the SBC connection is on one VLAN, and the internet is on another, we have 500Mbps internet, and 10Mbps connection to the SBC. These then run into 2 ethernet ports on the XG-7100 setup as discrete interfaces in 802.1q VLAN mode. WAN is VLAN 4090 assigned to 1,9t,10t and the SBC is VLAN 4091 assigned to 2,9t,10t.
So far I have:
- Removed CARP setup(from both SBC and internal VoIP VLAN), and assigned the .1 to our primary firewall(no change)
- Added VLAN priorities to 4090 and 4091 to prioritize VoIP traffic(no change)
- Ran the SBC connection directly into the primary XG-7100, bypassing the EdgeSwitch(no change)
- Replaced the ethernet line running from demarc with CAT6a(no change)
- Tried playing around with siproxd(no change)
- Tried some traffic shaping(both PRIQ and CoDel), but where it is a separate interface, didn't expect any change(no change)
- Shut down primary firewall to rule out an issue with a single unit(no change)
I've all but given up on this one, does anyone else out there have any suggestions that I can try? My next thought is that this might be an issue with the onboard Marvell switch. Right now I have 2 DAC running from ix0 and ix1 to our core switches, I may migrate VLANs from ix1(has no untagged traffic) to ix0 and put a 1Gbps SFP in ix1 and run that to the EdgeSwitch to see if this changes anything.
What I've done so far has ruled out a problem with both our EdgeSwitch, and the line coming from the demarc room.
Thanks for any help.
- Marc
-
Is the jitter/loss always in the same direction - as in always outside or always inside users speaking?
I would packet capture at various points and playback in wireshark to see if you can identify where the jitter is occurring. Might require capturing the same call in two places unless some consistent behavior can be identified without doing so.
Undo whatever you did with siproxd and remove the package. It's a virtual certainly it's not anything that will fix.
All this pair does is forward a 10Mbps connection between your SBC and the voice VLAN? What are the ix0/ix1 connections to the core for?
Do you have this diagrammed out?
-
Hey @Derelict Thanks for the ideas. I've managed to find the issue, and it was an equipment problem on our ISP side.
I ran some packet captures on both the internal VoIP VLAN, and the external SBC interface(our phone comes in over the same fiber asour IP, but on a separate interface on the demarcation unit(T-340)), found a lot of dropped packets, moved onto our WAN switch, and saw that there was an EXCESSIVE amount of Tx/Rx errors and collisions on the demarcation interface. When I dug into the interface itself, found that it was only negotiating at half-duplex, which would explain the issues. When I went back through my old config files for the SG-8860, I found that I had to force it into full-duplex mode as the T-340 for some reason will not auto-negotiate to full-duplex, but if I force my side to full, it works just fine, and not a single error since.
Thanks again for chiming in.
- Marc
