VOIP (latest snapshot as of July 4th) - Dropping calls!?
-
We had a WatchGuard XTM 2 device at our branch office across the river and it was nothing but trouble. So, I put in an old Intel Pentium III with 512 MB of RAM and a basic IDE hard drive and installed the latest snapshot of v2.0-RC3 as of July 4th.
I was able to properly load balance our WAN (cable & dsl), setup a IPSec VPN, and everything else I wanted fairly painlessly. I then create a rule in the firewall (LAN) and set is as the top rule as follows:
Action: PASS
Interface: LAN
Protocol: ANY
Source: ANY
Destination: Single Host - (our phones public IP)
Gateway: DSLGW (one I created for the DSL interface)Basically, what I did was say that anything destined for our phone systems IP public IP address should go over the DSL connection and we have all other traffic going (via the load balance Tier 1) going over the cable connection. That way we have a nice clean and clear DSL connection to dedicate to our phones.
I can actually test and see this working properly. When I check the phone system I can see that all client software and hardphones are indeed connecting via the DSL connection.
The problem is that since making the switch the phones are laggy, dropped calls/voice, but we can send/receive fine. I made sure SIP/ALG was turned off on the DSL modem but can't seem to find any other reason why the calls would suck so bad.
I took a look at the guidance provided by the pfSense team here: http://doc.pfsense.org/index.php/VoIP_Configuration
I changed the firewall to be conservative and checked the box to disable firewall scrub. The only thing I haven't done is try the siproxd package. I'm not sure this would help since all the clients are able to register just fine, just call quality sucks.
Any help is much appreciated!
-
This may not help but you may want to at least update to the latest snapshot:
http://forum.pfsense.org/index.php/topic,38687.0.html
-
Thank you for pointing that out. I've made the change and sure enough a newer version is available. ;) Not sure if it does help though in terms of my specific issue.
-
What is the upload speed for the DSL? Is the bad audio in? out? both? Are you 100% no non-voip traffic is going out that interface?
-
@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!