Trying to get VoIP Shaper correct BETA3

datafirm

@sullrich:

Try using an alias to dephine your phones. Search for forum, its been covered a couple times in the last month.

So you want to prioritize the traffic to the phones, not the asterisk box?

sullrich

You can put the asterisk box in the alias too, ;)

datafirm

@sullrich:

You can put the asterisk box in the alias too, ;)

That is what I had originally. That's why I tried to explain the problem in detail.

Any more ideas?

datafirm

@sullrich:

Try using an alias to dephine your phones. Search for forum, its been covered a couple times in the last month.

Isn't it strange that a full stream of traffic from the phone/server is getting put in qlanacks?

sullrich

Seems strange yes, its working great here.

datafirm

@sullrich:

Seems strange yes, its working great here.

Do you have a similar setup to what I described above?

sullrich

No, I have one that I described.

Phone and pbx subnet is in an alias and I use it during the wizard in the red field.

datafirm

@sullrich:

No, I have one that I described.

Phone and pbx subnet is in an alias and I use it during the wizard in the red field.

FYI - Aliases in the red field have never worked for me.

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.

datafirm

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

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.

datafirm

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

kwag

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

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.

kwag

@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

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.

kwag

@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

sullrich

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.

kwag

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