Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    VOIP (latest snapshot as of July 4th) - Dropping calls!?

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    16 Posts 3 Posters 5.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      GVJosh
      last edited by

      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!

      1 Reply Last reply Reply Quote 0
      • F
        focalguy
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • G
          GVJosh
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • D
            danswartz
            last edited by

            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?

            1 Reply Last reply Reply Quote 0
            • G
              GVJosh
              last edited by

              @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.

              1 Reply Last reply Reply Quote 0
              • D
                danswartz
                last edited by

                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…

                1 Reply Last reply Reply Quote 0
                • G
                  GVJosh
                  last edited by

                  @danswartz:

                  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?

                  Capture.PNG
                  Capture.PNG_thumb

                  1 Reply Last reply Reply Quote 0
                  • D
                    danswartz
                    last edited by

                    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'?

                    1 Reply Last reply Reply Quote 0
                    • G
                      GVJosh
                      last edited by

                      Results:

                      $ pfctl -vs queue
                      No queue in use

                      1 Reply Last reply Reply Quote 0
                      • D
                        danswartz
                        last edited by

                        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?

                        1 Reply Last reply Reply Quote 0
                        • G
                          GVJosh
                          last edited by

                          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.

                          1 Reply Last reply Reply Quote 0
                          • D
                            danswartz
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • G
                              GVJosh
                              last edited by

                              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).

                              Capture.PNG
                              Capture.PNG_thumb

                              1 Reply Last reply Reply Quote 0
                              • D
                                danswartz
                                last edited by

                                Hmmm, that is odd.  When you say "bad garbled calls", is the audio bad both ways?

                                1 Reply Last reply Reply Quote 0
                                • G
                                  GVJosh
                                  last edited by

                                  Yes.

                                  1 Reply Last reply Reply Quote 0
                                  • G
                                    GVJosh
                                    last edited by

                                    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!

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.