I wanted to get some ideas or assistants on an ongoing issue we having. We have all of our main offices in Texas along with our phone system but our call center works from all over the place including S. America. They have issues sometimes with call quality and disconnections but stateside we have no issues what so ever.
Would it be best to implement another Freepbx server in S.America and connect it to our main phone server or what would be the best option.
South America is a very large area with much variation in infrastructure quality. You could get better advice by telling us:
Which cities are your agents in?
How are they connected to the internet (Fiber, cable, DSL, cellular, fixed wireless, etc.)?
What device(s) are they using (IP phones, softphones, mobile SIP apps)?
How are they connected to the ISP (Wi-Fi, Ethernet)?
Upload and download speeds?
Do the impairments affect what the agent hears, what the (presumably stateside) customer hears, or both?
Vultr (for example) has data centers in São Paulo and Santiago. Like most cloud providers, they offer a small credit at sign-up so you could download the FreePBX ISO and set up a test server in one of those cities, in a couple of hours and at no cost. However, IMO the problem is most likely in the last mile and a closer server won’t help.
I would start by testing to determine where your present system is failing. For example, while on a call, run pings from the agent location to your Texas server, looking for packet loss and jitter. The results would suggest what further testing is appropriate.
Not sure that moving a PBX system closer to your agents would solve your issues completely as the connection still needs to get back to your system stateside.
If the issue is on the leg that’s connecting the agents to the internet then you’ll need to address that no matter where your PBX sits as they may experience the same issues trying to get connected to your system hosted inside the country.
You’ll really need to do a bit of legwork to figure out where the packet loss (assuming it’s packet loss here that’s responsible for bad call quality) is occurring and then address the problem connections.
I would start by capturing SIP traffic on both the PBX and agent side if at all possible and comparing the captures to each other on the bad calls to be able to start narrowing down the problem connections and then replacing things from there.
Assuming that the outbound path is affected (on a poor quality call, the customer can’t hear the agent well), I recommend that you first capture traffic on your TX PBX, which you can then analyze when you get a report of a bad call:
Look at the RTP from the agent for lost or greatly delayed packets. If you see such, you can try to determine whether the problem is local (weak or overcrowded Wi-Fi, or link saturation from unrelated traffic), the internet connection (e.g. heavy traffic from users on the same node), or routing over the internet. From the agent’s PC, you could run three continuous pings, one to the local router, one to ISP first gateway, and one to your PBX, each recording to a file. When trouble is seen, stop the pings and examine the relevant section for loss and delays.
If ping to ISP gateway is good but ping to PBX has heavy loss or jitter, then an intermediate PBX close to the agents will probably help. (First make sure that the connection between the two PBXes is clean.)