VOIP (latest snapshot as of July 4th) - Dropping calls!?
-
@danswarts:
Thank you for your reply. The upload speed for the DSL is 1 Mbps. Each call made averages around 80 Kbps and even with only one or two calls going we have very bad quality. As for the audio, it is bad both ways.
As for traffic on the WAN connections, I have created a load balance on the gateways with the cable connection being TIER1 and the DSL connection being TIER5. Then, I created a rule in the firewall as described in my original post so that anything headed for our phone server is directed over the DSL connection.
The load balance and rule I created seem to be working perfectly. All Internet traffic and VPN traffic are heading over the cable connection. Our VPN can be very busy at times and I'm thinking that I should setup QoS but I haven't figured that out yet as pfSense doesn't make it as easy (yet vastly more powerful) as do more commercial routers.
I know the phones use DHCP with a setting of 0 (zero) as their QoS marking. How would I configure the router to honor that setting and ensure that VOIP/SIP traffic is the #1 priority?
I'm going to setup a SmokePing server (FreeBSD) here in just a bit over at that branch office and put it on the DSL line to get an idea of the quality of the line. Perhaps that's the other issue as well.
-
I guess I am confused. If the DSL is only for voip, why do you need any load balancing setup? And if only VOIP uses the DSL, QoS would be pointless. I'm still not convinced there is no extraneous traffic hitting the DSL…
-
Of course, I could have just setup a seperate router and put it on the DSL connection and then connected a switch with all of the phones to it. Then I would have a physically seperation between the VOIP network and the data network.
However, in order to provide some type of failover (that is, should the DSL line go down) and to keep the phones working we decided to put them on the same router and use multi-wan. That way, I could just disable the firewall rule if the DSL connection fails and then the cable connection could be used as a backup.
Our cable connection is always busy though due to surfing and VPN traffic and so it isn't ideal but we could limit those items if we needed to in order to keep phone service active.
The idea behind setting up a load balance was to force all traffic over the cable connection and only use the DSL connection if the cable goes down. Then the firewall rule forces all traffic destined to a single IP address (which the phones are) over the DSL connection.
The graphs from the router indicate that my setup is working as I want it to. I've attached a screenshot so you can see. Does that make sense?
-
That all looks fine, but I don't see how it proves no unwanted traffic is going out the DSL and causing issues. Have you done 'pfctl -vs queue'?
-
Results:
$ pfctl -vs queue
No queue in use -
Oh, sorry. I misread - I thought you did have shaping. Looking at the traffic graphs during a crappy call, how high does outbound DSL usage get?
-
About 80 Kbps or so. I made two calls and it went up to 140 Kbps or so according to the graphs and phones seem to be working OK today. I'm finishing up the SmokePing server here today. Also, yesterday there was a lot of VPN traffic due to DFS syncing and calls were bad, today I got a report that calls were great, and there was little to no data on the VPN. I think you might be right about the QoS stuff but I'm still unsure how to set that up.
-
See here is the point I keep going back to. Lots of traffic in the VPN, and calls are bad. What this tells me is that contrary to what you think, non-VOIP traffic IS going out the DSL line.
-
OK, but why wouldn't the pfSense graphs reflect this? Is this a bug in v2? I have attached historical graphs for review as well. But aren't my rules correct, shouldn't this not be the case? You can see in the graphs the larger amount of traffic on cable only and hardly anything on the DSL (except for phone calls).
-
Hmmm, that is odd. When you say "bad garbled calls", is the audio bad both ways?
-
Yes.
-
I figured out how to get QoS going on the router and things seem to have improved. I will monitor the situation and update this ticket if problems continue. Thanks to everyone for their help!