More Reliable Way to Handle Interoffice Calls?

Details: Our head office is located in Canada. We have a branch office in the US, and a branch office in the UK. All three locations have their own Asterisk server, and each has a T1 PRIs for calling out through PSTN.

Our phones in the UK and US offices have two lines configured, one to their local server, and one to the server in Canada.

Each location has no quality problems making calls through their local T1 PRI, as you would expect.

The problem is with interoffice calls with the second line that connects back to the Canada server, which does through a VPN tunnel.

In general, the remote extensions connecting through the VPN is not reliable enough in terms of voice quality. The delay, jitter, and voice drops are significant enough to be more than an annoyance to some users.

It gets even worse when, for example, one user in the US is talking to another user in the UK. Both legs are connected to the server in Canada. In this case, the VoIP traffic is going through two VPNs.

Does anyone have any suggestions on what we can do to improve things here?

Thanks!

Use QoS and G729 Codecs for internet calls

Hello,
Also you should use passive and active monitoring and submit support ticket to provider when connection get worse,
You could try to use SIP TLS and SRTP for secure your call (like I know this features are already implemented in Asterisk 1.8 ).

Hope it will help.

Thanks for the replies… I had tried tweaking QoS and using G729, but it didn’t seem to help much.

I was wondering if there was a better way to link the different offices together, or is this already the ideal way to do it, and it is what it is?

Just to eliminate a possible cause, have you tried without the VPN? You could use an encrypted IAX channel.

Ian.

What if you interconnect all 3 servers with SIP trunks? That way you would only have 1 line per local extension and Asterisk servers would be doing the inter-continent call routing :wink:

[quote=“pmlco”]Just to eliminate a possible cause, have you tried without the VPN? You could use an encrypted IAX channel.

Ian.[/quote]

Agreed, isolating the root cause to the channel is done by removing the VPN from the equation. I posted a similar problem. You might want to try the Visualware VOIP test between the two points (minus any complications such as VPN, Encryption etc.) to verify that it is possible for good VOIP. If it isn’t, then no system change will solve the problem.

It should be possible to run the Visualware VOIP test through the VPN because it is web based. I suggest posting the results if this does not provide clarity.