10% Trunk Call Quality Issues with FIOS/EdgeRouter (thought might be SNG7, was NOT)

Rolling out a new server for a client. Thought I would roll with SNG7. Having a strange issue where every so many calls out of a SIP trunk (tried 2 different providers) creates distorted audio with about 10% packet loss. External extension calls from the Internet to the system are always perfect, it’s just trunk calls and it’s about 1 in 10 that are affected. Still in the testing phase, and thinking about trying the 10.13.66 to eliminate the new version as the issue.

The call always stays at 10% packet loss and never recovers to a normal call. Hang up and try again and it’s perfect with 0% loss. Keep calling and eventually I’ll get a lossy call.

When I do a sip show channelstats on a buggy call: 3c44f6ec1b8 00:00:22 0000000481 0000000056 (10.43%) 0.0000 0000001105 0000000000 ( 0.00%) 0.0014

I’m using chap_sip, tried Vitelity and Flowroute trunks.

I’m eliminated the EdgeRouter firewall, QOS and FIOS internet at the location as sources of the issue… at least I think,

Note I will update this post if in fact the new version WAS NOT the issue, if I end up trying the legacy distro. I don’t want to create misinformation.

It is edgerouter actually there is an issue with UDP packets from lan to wan… there is a bug in the edgerouter X, Lite and Pro.

You have to disable one of the cores. It screws up the re-ordering of packets when all cores try to reassemble it.

1 Like

Do you have a link for this bug? That’s pretty significant.

1 Like

Wasn’t SNG7, tried previous build, same issue.

So there you go… not a problem with the OS

Which model Edgerouter do you have?

Several of our employees use edge routers. Much of our development and testing that involves phones pass through edge routers to our development systems. This is something that should work purely as a bi-product of our test flow.

The packet loss does not occur on slower connections. It occurs anything above 25Mb and above. So if the connection is been utilized above the 20 - 25 Mb mark it will start loosing packets. The currently have a work around for it by upgrading to the beta software of 1.9.7 which will allow you to disable one of the cpu cores and that will solve the packet loss. This also occurs on the Unifi Security Gateways from Ubiquiti since the use the same OS, it is alot more complicated to apply the temp fix on the Unifi Line.

To eliminate the possibility of this being an EdgeRouter issue, I went ahead and installed 1.9.7beta2 on the ER POE5 that’s at the customer location. They have FIOS 75/75 service. There was no change. About 10% of calls experience 10% packet loss on the receiving end, even with the beta and disabling one of the receiving cores, which was the purported fix. I removed all QOS on the EdgeRouter and the problem persists.

Here’s a good call:
Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter 6b85d3864fb 00:00:14 0000000683 0000000000 ( 0.00%) 0.0000 0000000710 0000000000 ( 0.00%) 0.0023 f131f661606 00:00:14 0000000689 0000000000 ( 0.00%) 0.0000 0000000652 0000000000 ( 0.00%) 0.0021

Hang up, call back, perfect calls x 6… then try again and:

Peer Call ID Duration Recv: Pack Lost ( %) Jitter Send: Pack Lost ( %) Jitter efc5eadc89c 00:00:19 0000000831 0000000083 ( 9.08%) 0.0000 0000000829 0000000000 ( 0.00%) 0.0036 5b356cdf56e 00:00:19 0000000829 0000000075 ( 8.30%) 0.0000 0000000831 0000000000 ( 0.00%) 0.0028

I ran an EdgeRouter POE5 on my home cable connection for a few years and never had an issue with SIP, although I was 350/25.

I think this is some weird issue with their FIOS, and it may honestly not be fixable. Huge bummer. I might try to go direct with DSLReports and FIOS support… calling tech support is useless.

And I will add that this happens with the circuit at basically idle. I was essentially just me and a g722 call + trunk call g711.

What’s really strange:

My testing extension -> FIOS -> PBX — never a problem
My testing extension -> FIOS -> PBX -> Out to Trunk — 10% calls receiving packet loss, others perfect

Pretty nuts. Glad I use Mikrotik.

So the way u have it setup is:

FIOS ONT —> Fios Quantum Gateway --> EdgeRouter ----> PBX ?


FIOS ONT —> Edgerouter —> PBX?

“even with the beta and disabling one of the receiving cores”

Yes I did, and rebooted just to make sure it stuck. I’ve never seen this issue and I have several FreePBX installs behind EdgeRouters, and I actually ran my own home office install behind the same ERPOE that’s at the client location.

And our FIOS is static IP. Was installed ages ago when it was still Verizon. They gave us just an Ethernet handoff… it runs to some equipment closet in the industrial park where this client is… not your typically Actiontec gateway.

What’s really strange is how this only affects a minority of the calls, and it’s always 10% packet loss… and from what I gather it’s ONLY outbound calling that’s affected.

Baffled and bummed

I think I’ve narrowed this down to a problem with FIOS. I’ll update the thread once I’ve contacted them.

Now I have a quick question or 2 for you. Now You said it doesn’t do it on inbound calls. Now for outbound calls is it the same number you are calling or different. What I think it might be the cause the Underline carrier that is handling the outgoing call, there switch for that specific route might be having issues. I’ve expierenced this with Onvoy and Bandwidth.com. Now incoming might be from Level 3, wether you use viteity or Flowroute. For outgoing they have different carriers that they utilize maybe one of those carriers is having issues. Log into the asterisk console and see which media server is handling the call, and from there you can determine which carrier it is. Hope this info helps.

Once you do that install MTR on the machine and run the command mtr and the Ip of the media server u get. You will get a detailed description where the packet loss occurs


Thanks for your help with this. We’ve narrowed it down to Frontier. I did a number of MTR dumps and uploaded to DSLReports Frontier Direct forum to bypass useless tier 1 phone support. So it has nothing to do with anything local to us, it’s the circuit that’s the issue.