VOIP phones and latency issues
Firebox T40 on 12.6.1
A customer has been having choppy voip issues for months. We normally don't configure QOS of any kind and have never really had a need too. They were on a 25/25 MB fiber connection which should be adequate as 90% of the work they do is internet based. We got them to upgrade to a 50/50 and still the same issues. The VOIP carrier is saying the phones are showing 2000ms pings a lot when reaching out to the PBX. When I am onsite I have no issues with pings. Pings from PC's are normal. I have triple checked the ports and verified with them what needs to be open. We have the outgoing policy disabled and only allow ports we specify. I even setup a guaranteed bandwidth traffic management action of 15MB (From ->To) and applied it to the 4 policies I have setup that deal with phone traffic. My understanding of QOS is very little. I have no idea how to set it up or what the options mean. Would it make a difference do you think? What is best practice when using VOIP phones on a watchguard? Personally im leaning toward an ISP issue because my speedtest results vary day to day. Last night 38/38 was all I could get but even that should be enough for 8 or so phones. They told me the phones themselves only reach out on port 5060 to the pbx system and I have a rule allowing Any-Trusted to the DNS hostname of the PBX TCP/UDP 5060. I am at a loss of what else to do on the firewall to potentially figure out the cause. I am probably going there tomorrow to troubleshoot more in person and make some calls while watching traffic to see what I can see. Was just hoping if anyone had any ideas they would share them before I go on site.
Thanks
Comments
@Chaospinhead
Your outbound policies, are the packet filters or proxy policies?
Proxies may slow things down a bit depending upon the model # of your Firebox and cause latency issues.
The rule you have using a DNS lookup to find the PBX host may also cause latency as the DNS lookup takes time.
Try creating a packet filter policy that not only allows TCP/UDP 5060, but also
5061, 5062, and 5090. Have this point to the IP of the PBX host and enable logging on this policy. Make sure your SIP traffic runs through this policy by disabling the other policies, or placing it above them.
If the issue keeps persisting you can enable diagnostic logging on the policy or perform a TCP dump while making multiple test calls.
Your ISP may be the culprit, but in my experience they would rather blame you than admit to any network issues, so you need to make sure it isn't you.
It's usually something simple.
I set up my Fireboxes with a packet filter policy allowing the IP range of the phones (assigned statically or via DHCP reservations) to go out unrestricted to the FQDNs and IPs of the VoIP provider.
Ask them what they recommend for the UDP timeout. By default, it is 30 seconds, and the VoIP providers I have dealt with all wanted it at 300 seconds minimum. As far as I know, that timeout is global and it has to be set via the CLI because UDP timeout is not exist to the web UI or to Policy Manager.
You can use the formats below to set it via CLI. The default is 30 seconds. Maximum is 10 minutes.
Any of these examples work:
global-setting udp-timeout hour 0 minute 9 seconds 59
global-setting udp-timeout minute 0 second 50
global-setting udp-timeout minute 3
global-setting udp-timeout minute 10
global-setting udp-timeout second 59
So as long as the unit value does not exceed the possible maximum for that particular unit, then it works. For example, let's say that one wants a 60 second global UDP timeout.
The command would be:
global-setting udp-timeout second 60
Let's say that one wants a 90 second global UDP timeout.
The command would be:
global-setting udp-timeout minute 1 second 30
Using "global-setting udp-timeout second 90" would fail.
Gregg Hill