Reply
Highlighted
Emerging Member
Posts: 65
Registered: ‎12-11-2014
Kudos: 5
Solutions: 1

Horrendous Voice Delay when using a PBX, hardly any delay when using direct SIP

Hey folks, I'm at a bit of a loss. 

 

TL;DR: when using a PBX (onsite Elastix, onsite Wazo, or off-site 3cx via OVH hosted ssd-vps) there is a 2-4 second delay on calls. When connecting phones directly to a sip trunk (flowroute, OnSip, Sip.US, or Google Voice via Simonics Gateway) there's hardly any delay at all.

 

*WHY the heck can't I use these phones with a PBX?! What am I doing WRONG?* Yes I'm sure you'll want all sorts of specs and stats to help determine it, but based on this, what information would be most helpful to get going?

 

We've currently got CenturyLink lines coming in, terminating on analog, plugged into Digium FXO card, assigned to Elastix/FreePBX virtual machine on server. Phones are controlled/provisioned from VOIP Controller, calls are handled incoming/outgoing through the Elastix/FreePBX. We've always had really crummy audio, 2 second delay in nearly all calls, etc. I've always just assumed it's because I'm virtualizing the PBX and it is what it is. Well now we need to port our numbers from CenturyLink - and fast - and I'm seeking an alternative. Problem is, all the alternatives have the exact same problem. Whenever I connect to a PBX to route calls, it's an AWFUL delay. 

 

But when I plug the sip credentials for a trunk directly into the device and bypass a PBX altogether, call quality is great - but I have no "phone system" to speak of for the business. This tells me though that basics like bandwidth and ISP connections are not the problem here. 

 

I've tried 3cx on OVH, I've tried local installs of Elastix and Wazo from NerdVittles, and they all have the same delay issues. 

 

Any recommendations? Need to get these numbers ported, costing me $30/day to keep my current service active and can't cancel until I find a new home for our phone system. And no, $20/35-month per user is not affordable for me, so I can't just "go mainstream" with another provider ... especially if its these UVP's that are the problem!

 

Thanks

AD

Ubiquiti Employee
Posts: 3,902
Registered: ‎08-04-2014
Kudos: 715
Solutions: 333
Contributions: 16

Re: Horrendous Voice Delay when using a PBX, hardly any delay when using direct SIP

@allandelmare, Could you please let me know what version your UVP's are on? This can be phone in the UVP App -> About -> "App version". Also, just to clarify that connecting the phones to OnSip, SIP.US, and Simonics GW are actual PBXs. So I believe the differences are you are seeing in latency is within the virtualization and FXO cards. Previously we had some audio latency issues in earlier versions, but was since fixed.
Devin B.
Skype: babb.devin
Emerging Member
Posts: 65
Registered: ‎12-11-2014
Kudos: 5
Solutions: 1

Re: Horrendous Voice Delay when using a PBX, hardly any delay when using direct SIP

@UBNT-Devin,

 

UVP: 5.0.13.656

 

Also note:

 

When I refer to OnSip, SIP.US, and FlowRoute, I'm referring to ONLY their SIP Trunks - no PBX service. So when I take the SIP username/password and server credentials and provision them to a UVP such that the UVP is directly connected to a trunk, the audio is fine. 

 

However, if I configure those trunks to an "trunk" in a PBX, and then provision the UVP to the PBX using internal SIP extension credentials, then placing calls through the PBX which utilizes those trunks causes a terrible delay.

 

This delay is present whenever using a PBX; it is not present when using a direct trunk-to-uvp ("standalone") sip connection.  

 

I've tried hosting my own PBX (Wazo, Elastix, 3cx) onsite, as well as a cloud-hosted 3cx, and in all scenarios, the PBX involvement causes the delays. I've also tested this with FXO card and analog lines to ensure that the problem does not revolve around pure SIP trunks from the other providers or latency issues between them (it does not).  So eliminating the FXO from the equation does not have an impact: it is the part about provisioning the UVP to a PBX instead of directly to a single trunk that causes the issue.

 

Thoughts?

 

 

Reply