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


  • A
    Beta Testers

    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

    , 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.


  • A
    Beta Testers

    ,

    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?


  • A
    Beta Testers

    I ended up replacing the UVP with a yealink phone and all is well.

    Obviously I don't want to ditch the investment in the UVP's. But until I can figure out what's going on, I can't continue to use them. I don't have the technical expertise or the time to fiddle with them any longer. Hopefully someone here can help me with a try-this-try-that. But otherwise, I'm afraid the UVP just working out for us…wish I knew why.

    UBNT, I love you guys. But really wish this wasn't so difficult.


  • Super Users

    Cute answer…

    We've been using UVP phones - there's one on my desk right now - for several years with Elastix and FreeSwitch PBXs and have had zero issues.   Including running over VPN tunnels.   They work fine if you know what you're doing - not being snarky here but I see so many "I couldn't get XXX to work so it must be junk!" posts that I really feel the need to push back sometimes...

    Jim


  • A
    Beta Testers

    I've seen lots of posts with folks who are digging into code and sound like they know exactly what they're doing. I don't pretend to be one of those people. To date, I haven't found threads with similar issues to mine to be resolved. In some cases, I see them winding up with the same outcome as myself.

    I understand many people use these phones happily. It appears though that there is a pretty good number of people who are having the same kinds of problems that I have, and from what I can tell, our "pool" of people are not finding resolution.

    As near as I can tell, the lack of g229 codec is problematic, but likely only relative where bandwidth/jitter/ping are issues.

    Since a "direct to trunk" provisioned UVP experiences 0 issues, the codec clearly isn't the problem. So that rules that out. It also begs the question of which settings could possible be wrong if the device is proven to work just fine directly on a trunk?

    My point here is that it's not like I've got a basic issue such as bandwidth, codec selection, or common network/device settings. The issue is with respect to how the UVP functions when introduced to any one of several PBX environments.

    This is where it's frustrating: I can't find anyone who even knows where to start in trying to diagnose and correct this. Meanwhile, simply changing the UVP out for another device fixes everything.

    Okay, so then it's not my network, my ISP, my PBX or my codecs. It literally has to do with SOMETHING related to the UVP. Maybe its a setting. Maybe its a particular setting in conjunction with other particular settings on any one of the PBXs.

    But clearly this is a UVP-specific issue; not "my" issue per say.


  • Super Users

    Don't blame you at all.   But people seem to forget that a ton of people beyond the posters and UBNT read the Forum, and I try really hard to make posts/responses useful for people outside the participants in the thread (or people reading 6 months from now) too.   And "runours fly faster than an eagle" and all that, so I try to tamp down things that might make people believe that a particular unit is "bad" just because someone can't get it to work in their particular situation.

    I understand that it's frustrating.   Yes other phones are simpler to set up and "just work".  Try running a Cisco SCCP phone on an Asterisk PBX - we do it all the time and most folks would say it's impossible- we had one site with 150 7940 SCCP phones running off one Asterisk PBX instead of a Call Manager for several years.   If all the UVP phones had the problem you had then nobody would ever use them - and there are tens of thousands of them out there.

    I just don't like people making things look like the unit is the problem when it's likely not.   Not trying to offend you here, just don't want mistaken ideas getting promulgated…

    Also sorry I never saw any of your posts - I am not usually very active in this part of the Forum - too many things to deal with in AirMax, and AirFiber, and EdgeOS, and GPON, and Alpha forums, and SunMax, and...  and not enough hours in the day - also have an ISP and consulting firm to run here in my spare time  :biggrin5:

    Jim


Posts 7Views 2
Log in to reply

Looks like your connection to Ubiquiti Networks Community was lost, please wait while we try to reconnect.