Best Practices - Aastra Phones and Networking

General Help
1

We’re running FreePBX 2.10 behind a pfSense router with 12 Aastra telephones.

Things run well but call quality has been spotty at times. I believe this may be because of the network configuration. At present I have pfSense acting as the DNS and DHCP server for the network, should I move DNS duties to the free pbx server? Should the freepbx server be pointing to itself for DNS instead of pfsense? ( I presently have the freepbx server setup with a dynamic IP but that has a corresponding reservation on the pfSense box).

Is it best to set the telephones with static IPs and specific hostnames, or is dynamic and username as the hostname ok?

Otherwise calling is reliable, it’s just not 100% in terms of quality.

Thanks for any advice in advance.

2

It’s very rare that your LAN would cause audio problems - DNS/DHCP wouldn’t cause those issues. Dynamic IPs for the phones are fine. I’ve been told the PBXs first DNS/hosts entry should be 127.0.0.1.

Are you using SIP trunks? If so, the quality problems are almost certainly due to:

  1. Your ISP, even if bandwidth is high jitter can be a huge problem
  2. Your SIP trunk provider - if you’re using a cut-rate service
3

I have a feeling it may be the latter, voicemeup seems a little fly by night. Any advice for a better service in Canada?

Our internet is 10MB symmetrical and pings are generally under 30ms. However, I have noticed that pings to phones on the network are sometimes close to a hundred, but generally about 30-50 (this is from the info section of FreePBX).

Anything else to troubleshoot? SIP settings on the phones themselves, I am just using the LAN IP of the FreePBX box and leave ports at the default of 0 because they are the default 5060.

Thanks for your help!

4

Ping is not a meaningful indicator of VoIP performance. Ping measures latency, the time it takes for the packet to traverse the route. Latency, by itself does not cause any issues other than at the extreme end of the scale (over 300ms) the effect can be somewhat of a “simplex” or two way style conversation. Our trunks to Hong Kong run 340ms and it is not an issue.

Jitter on the other hand is death to voice quality. Packet loss is next. Meaningful test produce streams that are similar in size to the UDP RDP Datagrams. In this way the real world performance of the line can be assessed.

Wikipedia defines a Datagram as follows:

This is in contrast to TCP packets, whose delivery is guaranteed by the Layer 3 protocol TCP.

5

I think you only want 127.0.0.1 in your hosts when you have caching-nameserver setup. Something that I think is always a good idea to do.

6

As has already been said it’s likely to be jitter and/or packet loss on the line rather than anything to do with DHCP, DNS, or LAN setup. Are you using any prioritization on the WAN link? If not even with a 10Mb symmetrical like quality can suffer even if utilization is not very high as all traffic shares the same “queue” and voice packets will wait in line with any other sort of packets for service.

If you can give priority to 5060/UDP and especially the RTP range that you are using (something like 10000-20000/UDP). Have a look in /etc/asterisk/rtp.conf to confirm this.

7

We recommend Thinktel/Distributel or Burloak Networks for service in Canada.

8

Ping is a very useful indicator.

Sometimes sending progressively larger ping packets can show issues regular ping won’t.
ping -l 4000 xx.xx.xx.xx
ping -l 10000 xx.xx.xx.xx
ping -l 20000 xx.xx.xx.xx

You want to see a relatively linear increase in ping as you increase packet size.

But regular ping is still quite useful imho.

9

I am going to look into those other providers.

I went through pfSense, FreePBX and all of our Aastra phones this weekend with a fine toothcomb. I also re-terminated some sloppy cabling done by the telco, and it seems to have made a noticeable difference. The only issue now is with the odd outgoing call, where the caller from our office, doesn’t immediately hear the person they dialed. Seems to go right from ring to the called person finishing saying hello, so it skips a few seconds. Strange as otherwise the call is fine, and inbound calls have no such issue.

I’ve gone through pfSense and setup a manual outbound nat rule for port 5060, as suggested on their forum. Don’t know if this will resolve it. I also updated all of our extensions that fall within the LAN to Nat=no, which I understand is the desired setting. Any other idea or locations I could check for this problem?

Warm regards,

Andrew

10

Keep in mind that SIP is just signalling, the audio is assigned to a random port between 10000-2000 UDP (this can be constrained down in /etc/asterisk/rtp.conf).

An important test would be to watch SIP dialog in one window and do an RTP debug in another. If you see a delayed start in the RTP packets you know the issue is past the SIP point of the call setup.