Choppy calls from one office logging into another office

General Help
1

Hello,

I have a choppy calls and occasionally one way audio issue.
I have FreePBX running on a server in MainOffice. It sits behind a router with a local IP 192.168.1.252. My users inside MainOffice have no choppy calls (they dial out through a sip trunk and dahdi)

Now, we rented another small office - let’s call it SatOffice. In SatOffice I have Xlites sitting behind another router, connecting to FreePBX in MainOffice. (I opened 5060,8000-20000 in MainOffice Router).

Calls between extensions - choppy.
Inbound calls received on sip trunk at MainOffice that come to agents in SatOffice via IVR - choppy with crackling sounds.
Outbound calls that go to MainOffice FreePBX and then go out of MainOffice FreePBX via SIP trunk - disgustingly choppy.

Obviously, there’s some firewalling issue there. I’ve enabled stun.xten.com on the Xlites to see if it alleviates any issues. Nothing over the top in clarity.

But I’m wondering if there’s any of that canreinvite or nat=yes kinda stuff I need to do for the extensions (oh btw, we’re in device and user mode so should i do whatever to device AND user? let’s keep that in mind) that are in SatOffice.

Please please please help!
Thanks a ton in advance to the ones who read this, but couldn’t reply.

2

You can’t configure away packet loss. Check the path between locations first.

In FreePBX 2.8 you configure your NAT in the SIP settings module.

3

SIP_additional.conf

[root@pbx ~]# nano -w /etc/asterisk/sip_general_additional.conf
GNU nano 1.3.12 File: /etc/asterisk/sip_general_additional.conf

disallow=all
allow=ulaw
jbenable=no
srvlookup=no
maxexpiry=3600
minexpiry=60
defaultexpiry=120
allowguest=yes
registerattempts=0
maxcallbitrate=384
registertimeout=20
notifyhold=yes
g726nonstandard=no
t38pt_udptl=no
videosupport=no
canreinvite=no
rtptimeout=30
rtpholdtimeout=300
notifyringing=yes
checkmwi=10
rtpkeepalive=0
nat=yes

sip_nat.conf is empty

4

Sure, there’s the traditional packet loss here & there. But mostly it is because of ill-configured NAT.

SIP Settings has NAT set to Yes & IP is Public IP.

5

Packet loss monitoring by ping or traceroute is unfortunately, not a good indicator of the quality of connectivity between any two endpoints. (Like phone to FreePBX server).

For example, a router management tool called “Control Plane Policing” which is a feature of Cisco’s/Junipers/Etc will give ICMP Ping/Traceroute/Redirect/etc control messages a lower priority than routing plane traffic thus throw up high latency values making you think the path is high latency, or if the latency is too high, a timeout or “packet loss” as you might perceive it.

Choppiness and static are also caused by jitter which is to be expected when an internet connection is shared by voip and data.

For example, someone listening to Pandora on the same internet as your FreePBX extensions use to get back to the server will cause periodic swings in latency to the FreePBX box because of the downloading/buffering action of Pandora. Hence jitter. Hence on again off again choppiness.

Carbonite/Dropbox/SkyDrive/iMesh, type cloud based file backups also cause this.

A router/firewall thats QoS aware helps slightly if it can assign higher priority/shallow queue depth to QoS high priority flagged packets such as VoiP, but the real solutions to the choppiness/static is a longer list.

Here are a few things to check/try:

  1. Use a firewall/router at the remote ends that allows you to further restrict any traffic that doesnt go to/from your FreePBX. This gives VOIP traffic a “reserve” amount of bandwidth that Pandora or Youtube or Dropbox cannot touch. Usually this feature is called bandwidth management, or referred to as shaping. This obviously has to be at both ends to be effective.

ie If your remote office is on a T1 for internet, you can reserve 200Kb of bandwidth for the use of traffic to/from your freePBX box and guarantee at least 1 call at g.711 codec will have better quality.

  1. Make sure your ISP(s) is/are “well connected” at both ends. For example if your remote site is a DSL, perhaps a cable modem might give less hops/ISP transitions and better voip performance. If you have a thin pipe like a T1, consider having voip use the T1 and get a fast broadband like DSL or Cable for the bursty internet.

  2. If you can take a small hit on the voice quality, buy the license and implement g.729 codec from Digium. This codec is particularly designed to handle the burstiness of the internet. It provides what used to be called “toll quality” while reducing chatter/static artifacts in the voice. Its only $10/concurrent channel which is cheap for what it does. Most SIP trunk providers and SIP equipment manufacturers support G.729 for this reason. It also uses little tiny packets compared to g.711 so queuing is easier on the routers in the path. Sorta like dropping BB’s down a funnel as opposed to golf balls. BB’s blend together easier to get through the narrow opening at the bottom of the funnel.

  3. To alleviate NAT issues/one way audio, eliminate them by using VPN tunnels between offices. Be certain your VPN solution supports keepalives of its own to prevent idling out and re-establishing causing ringing issues with your extensions or more audio issues. If you are using SRTP for voice privacy/security, then your VPN tunnel doesnt need to be max level of encryption bits. ie DES or 3DES is good enough and AES 256 would be overkill and could cause voice quality issues with the added latency. Many phones now support VPN’s within them to avoid having an external VPN router/firewall. Or for individual remotes like at home.

Like Skyking said, you cant simply configure away VOIP quality issues. It takes a little work :slight_smile:

p.s. I forgot something else. If you have a dynamic IP address on the remote ends, consider getting a static IP from your ISP, or use the VPN option which eliminates issues when the IP address changes like on PPOE connections to your ISP with dynamic addresses.

6

Public IPs both ends & high QoS quality. VPN might be the solution if my configs are right. I’m trying to make sure configs atleast are correct.

Both offices have bandwidth management. This is a corporate style internet connection - so cloud stuff is definitely not in motion here.

7

Here is an idea of how I test too.

Upload some music that doesnt skip any beats and doesnt have a heavy beat, such as Mozart, to a conference bridge in FreePBX.

(Music with heavy beat or wide dynamic range will cause clipping distortion and gating effect perceived as sound level dropout or false choppiness, or graininess so, no RAP/HIP Hop :slight_smile:

If your phones can do G722 (and extension is configured), then your test music should sound dynamite.

Then if you can, at a remote site with a fast laptop or desktop, install a torrent program like uTorrent and download 3-4 different linux distros at the same time, which have DVD sized ISO’s. This allows you to nuke and un-nuke the pipe at will while you listen to Mozart (Marriage of Figaro works really good because of the wide dynamic range and no overdriven distortion like heavy metal) on the speakerphone or headset/handset in the conference bridge to listen for quality issues. You can pause and continue all the torrents with one mouse click for testing.

If your firewall isnt up to it, ie too small a cpu, etc, this can freeze/reboot your phone, stop or pause the music playback from the conference bridge, freeze/reboot/zombie your firewall causing you to need to reboot it, etc.

I had 2000+ connections downloading the last Linux Mint when it just came out. That hammers the internet, firewall, switches and even phone if your test machine is plugged into a phone.

Then, you can adjust shaping, queuing, whatever and quickly find problems.

Also, another handy tool is the built in FreePBX echo at *43. With your torrents running, your voice should have minimal delay coming back to you and should be clear as a bell without static and choppiness.

If you map *43 as a misc destination, then you can assign a DID to it and use loopback/hairpin calls to add the FXO, PRI, or other TDM trunk into the loop and hear the entire path while testing.

That can eliminate low sound levels on your dial tone trunks as a cause too. (This does happen more often than you think. Asking your carrier to bump up or down the level on your trunks makes a difference)

Although in your case, intercom calls between extensions dont traverse trunks :slight_smile:

Another thing is *60 and listen to Allison tell you the time in a loop and GSM codec.

If toggling the torrents on/off ruins the quality of the music, echo test, or allison telling you the time, then something in your infrastructure is not working right.

If you download free voice prompt replacements in native Asterisk format, then the voice prompts sound MUCH better and therefore are much more indicative of quality issues if they exist.

This website has free super high quality voice prompts for Asterisk/Freepbx. Pick “Asterisk Native” for the best quality.

http://www.voicevector.com/Downloads.php

Good luck :slight_smile:

8

I would create a ring group with fake members and the no answer option of “put on hold forever”.

I find Handel’s water music suite very nice music on hold and provides great testing content. Several renditions including the Warsaw synmphony are in the public domain.

9

Guys, you’re asking me to check the connection by listening to music - but isn’t it aready apparent that quality is bad based on voice?