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

    Trying to get VoIP Shaper correct BETA3

    Scheduled Pinned Locked Moved Traffic Shaping
    21 Posts 4 Posters 9.9k 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.
    • H
      hoba
      last edited by

      The payload usually runs from one phonenedpoint to the other phonenedpoint. Not all the VOIP-Traffic derives from the Asterisk only. I suggest doing some research by viewing either pftop from the shellmenu or doing some etherealing. I guess you are simply missing to assign some devices/traffic to the right queue.

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

        @hoba:

        The payload usually runs from one phonenedpoint to the other phonenedpoint. Not all the VOIP-Traffic derives from the Asterisk only. I suggest doing some research by viewing either pftop from the shellmenu or doing some etherealing. I guess you are simply missing to assign some devices/traffic to the right queue.

        I was checking out the pftop in shell (rate view) and the items on top (there was no other real activity) were these two:

        
        udp   Out 192.168.0.40:4569     72.34.43.5:4569        11596  2146K  2:2    152    60  19296  20148  14463 97 72.51.3.185:54987   
        udp   In  192.168.0.40:4569     72.34.43.5:4569        11596  2146K  2:2    152    60  19296  20148  14463 14
        
        

        That is my asterisk box to the IAX2 proxy.  Strangely I did not see any traffic coming from the phone (perhaps because of NAT?).  I am still stuck with only part of my traffic getting queued.

        Here is how I have setup my shaper:

        http://img109.imageshack.us/my.php?image=picture13go.png

        And the alias (phones and asterisk box)

        http://img428.imageshack.us/my.php?image=picture24hb.png

        You would think this would be enough?

        1 Reply Last reply Reply Quote 0
        • H
          hoba
          last edited by

          According to your pftop output the asterix is the only box that is talking to the outside. In case you are using IAX this is ok as the asterisk does protocol transformation (your phones most likely talk SIP I guess). Have you tried resetting the states? In case there were connections that were there before you edited the queues those will remain in the originally assigned queue when the connection was established.

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

            @hoba:

            According to your pftop output the asterix is the only box that is talking to the outside. In case you are using IAX this is ok as the asterisk does protocol transformation (your phones most likely talk SIP I guess). Have you tried resetting the states? In case there were connections that were there before you edited the queues those will remain in the originally assigned queue when the connection was established.

            Yes, all communications to our providers our done through IAX2.  The phones to talk through SIP on the LAN.

            I always reset the state when I've been messing with the Shaping.

            1 Reply Last reply Reply Quote 0
            • K
              kwag
              last edited by

              Hello all!,

              I'm having a similar problem with RC2, which I didn't have with BETA 3.
              My  "qVOIPDown" displays correctly while I'm processing a VoIP call on my Asterisk box (IP=10.0.0.10).
              However, the "qVOIPUp"  stays at zero, but the "qwanacks" shows the upload activity!

              After veryfying a call with tcpdump targetted to my destination point (another Asterisk box), here's a small sample of what I get:

              
              02:05:29.902050 IP 196.32.xxx.xxx.4569 > 10.0.0.10.4569: UDP, length 54
              02:05:29.906252 IP 10.0.0.10.4569 > 196.32.xxx.xxx.4569: UDP, length 54
              02:05:29.935439 IP 10.0.0.10.4569 > 196.32.xxx.xxx.4569: UDP, length 54
              02:05:29.942519 IP 196.32.xxx.xxx.4569 > 10.0.0.10.4569: UDP, length 54
              

              So it's clear that my box at 10.0.0.10 is talking with the destination on port 4569 UDP, as it should.

              I have a  shaper rule, actually the first rule under "Firewall: Shaper: Rules", that is set like this:

              
              In Interface: LAN
              Out Interface: WAN
              Source: (Alias) Asterisk -> 10.0.0.10
              Source port range: 4569
              Destination: Any
              Destination port range: Any
              

              So that rule should match anything out of my Asterisk box using IAX2 protocol on port 4569, but it doesn't!
              Is this a bug?
              As I said, this didn't happen on BETA 3. It is happening on RC2.

              Thanks,
              -Karl

              1 Reply Last reply Reply Quote 0
              • H
                hoba
                last edited by

                Did you make changes to your trafficshaper configuration after the states for your asterisk where generated? If yes try resetting the state table as traffic is assigned to queues on creating a state only.

                1 Reply Last reply Reply Quote 0
                • K
                  kwag
                  last edited by

                  @hoba:

                  Did you make changes to your trafficshaper configuration after the states for your asterisk where generated? If yes try resetting the state table as traffic is assigned to queues on creating a state only.

                  Hi hoba,

                  Yes, I did reset the states after I created the shaping, and I even did a reset on my Asterisk procesess (killed and restarted) just to make sure new sockets were created.
                  As a matter  of fact, I recall I even reset the Asterisk machine just to make sure!
                  Still, I can not get the UDP upstream to hit the qVOIPUpload queue  ::)
                  But it worked on BETA 3, so I'm really baffled  ???

                  -Karl

                  1 Reply Last reply Reply Quote 0
                  • H
                    hoba
                    last edited by

                    @kwag:

                    I have a  shaper rule, actually the first rule under "Firewall: Shaper: Rules", that is set like this:

                    
                    In Interface: LAN
                    Out Interface: WAN
                    Source: (Alias) Asterisk -> 10.0.0.10
                    Source port range: 4569
                    Destination: Any
                    Destination port range: Any
                    

                    Is that your only rule for the Asterisk traffic? That's only one direction. You need a second rule for the other direction. I suggest rerunning the trafficshaperwizard and entering the IP of the Asterisk at the VOIP page. It should create the correct rules. Reset states after that and retest.

                    1 Reply Last reply Reply Quote 0
                    • K
                      kwag
                      last edited by

                      @hoba:

                      @kwag:

                      I have a  shaper rule, actually the first rule under "Firewall: Shaper: Rules", that is set like this:

                      
                      In Interface: LAN
                      Out Interface: WAN
                      Source: (Alias) Asterisk -> 10.0.0.10 
                      Source port range: 4569
                      Destination: Any
                      Destination port range: Any
                      

                      Is that your only rule for the Asterisk traffic? That's only one direction. You need a second rule for the other direction. I suggest rerunning the trafficshaperwizard and entering the IP of the Asterisk at the VOIP page. It should create the correct rules. Reset states after that and retest.

                      The other part, the download queue, is already created and works fine. That part actually works with the "ToS" field set to "lowdelay".
                      But the Upload queue doesn't work, even as default settings from the wizard, which indeed set the rule to match with the "ToS" field.

                      -Karl

                      1 Reply Last reply Reply Quote 0
                      • S
                        sullrich
                        last edited by

                        You will have better luck if you define an alias that includes all of the host ip addresses that communicate via voip.  Include the ip address of the phone and the other endpoint (public address if need be).

                        In my case the voice over ip system terminates on a IPSEC connection so both of the ips in my alias are private.  But if you where using vonage or another carrier then the one IP address would most likely be public, etc.

                        1 Reply Last reply Reply Quote 0
                        • K
                          kwag
                          last edited by

                          Hi sullrich and hoba,

                          Thanks  for your replies :)
                          I finally figured out what was happening.
                          First of all, I did a factory default, and then proceeded to run the Shaping Wizard once again.
                          After that, I noticed exactly the same problem, and I decided to do a tcpdump -vvv host MyTargetHost to get more info, and there I saw the problem!
                          My downstream was ToS=0x18 and my upstream was ToS=0x10  :o
                          However, I believe there's a bug in the matching rules, because look what happens below.

                          For example, this works fine:

                          lowdelay    yes    no      don't care
                          throughput yes    no    don't care
                          reliability   yes    no    don't care
                          congestion yes    no    don't care

                          But this, or any other combination that includes more than one tos value, will  bomb:

                          lowdelay    yes    no    don't care
                          throughput yes    no    don't care
                          reliability   yes    no    don't care
                          congestion yes    no    don't care

                          PF will complain as to the syntax and skip the rule of the offending line when trying to add tos=lowdelay,throughput, etc., on the same line.

                          So I just fixed the ToS on my Asterisk box to tos=0x18, selected lowdelay yes - on the "IP Type of Service (TOS)", and bingo!, upstream/downstream are now showing a nice red line while any phone is in use ;)

                          BUT, the question still is, shouldn't 0x10 match? Because it doesn't!  ???
                          Isn't 0x10 = lowdelay? or do I have it all wrong?

                          Thanks,
                          -Karl

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