remote (tunnel proxy) voice quality troubleshooting

[cfive]

Hi,

I have 3CX v10 installed at head office. A bunch of extensions on the lan, and 8 PSTN lines connected via Patton 4114's. Voice quality is quite good to/from the PSTN and extensions on the lan.

I also have 2 remote sites, each with 5 users. These users all have Grandstream 1200 deskphones, configured to connect to the head office via 3CX proxy installed on a PC at each location, over the public internet. One location has SL, about 2mb down and 1up, the other has a wireless service about 11mb down and 4 up. The head office has cable, 6 down and 1 up.

Voice quality at the remote sites is variable, mostly bad at the SL side, and better at the wireless service side. I'm attempting to maximize the voice quality - get it as good as I can at the remote sites.

1. I've installed network monitor and voip analyses software on the 3CX server itself, which gives great information for the lan connected equipment, and the call segments that are on the lan. But as we're using the proxy tunnel, I can't seem to get a look inside the tunnel traffic for voip analyses. Is there a way?

2. When I do an analyses on the internet connection at the head office (which the remotes must come in on), I measure jitter at 42.9 ms, while other paramaters are fine. I suspect this is the single largest factor affecting the voice quality of the remotes. I'll do what I can to rectify this, but are there any configuration changes I can do to help deal with high jitter? (I do have 'traffic shaping' ability at the head office router, and am prioritizing 3cx traffic between the 3cx server and the internet).

3. I haven't done much analyses of the internet connection from the remote end, yet, but will. In the mean time, in 3cx server I have 'pbx delivers audio' selected for the remote extensions. The extensions are set to use g711 (PCM) (default) codec. I have available 8 - 729 codec calls; should I try this for the remotes?

4. Does the 3xc server activity log (verbose) show what codec is used for each call? I cannot see it.

Any advise from those experienced with getting remotes to work over the public internet would be appreciated!.

Thanks - Les

 

[eagle2]

Try implementing some QoS on routers, I suppose you don't have enough bandwidth for calls because of other Internet usage.
Depending on routers / your LAN this may be port based, internal IP / MAC address based, TOS (26 and 46), etc.
Wireshark may help you to analyze the situation.

Also try configuring codecs priority at your remote extensions, putting G.711A/µ codec in lowest priority, while G.729A (if licensed) and other low-band codec (GSM, etc.) in higher priority. Generally I'm not satisfied by GSM codec, neither G.726.

Regards

 

[cfive]

Thanks for the response, Orlin.

Bandwidth doesn't *seem* to be an issue, at least according to the tests I ran. I have however prioritized at least the traffice at the main office (3cx server) location.

But Jitter certainly raised a red flag at the main office internet connection.

I tried GSM, but I think the voice quality is bad to start with ;-). I'll try G729A though, as this site has a 16 call license and I believe that allows for 8x G729.

Thanks again, Les.

 

[eagle2]

Hi Les,

bandwidth may be a problem, if you don't have QoS (Quality of Service, or prioritization).

Even you have 1 Mbit/s upload and a G.711 call uses only 88 kbit/s, still you may not have free bandwidth for VoIP call (typical indication is great jitter) - the simple reason for this may be an application sending large files (i.e. upload, you may have torrents running, etc. or even an e-mail client sending something).

With 1 Mbit/s, if properly configured, you should be able to make even 8 simultaneous calls with G.711a/µ codec, so most probably the problem is insufficient bandwidth in given moment, unless you are not using this internet connection for anything else.

The problem may be also at the other site (similar download issue).

Kind regards,
Orlin.

 

[cfive]

Orlin,

Yes, that makes sense - I currently only have the traffic prioritized at the head office end. I'll double check that, and see what I can do at the remote ends.

Thanks again, Les.