Don't cap the other bandwidth, set the Voip queue to have 320Kbps of realtime bandwidth.
i.e.  320Kbps is reserved for the Voip queue.
Since your phones should have static IPs, set their IPs into an alias and use a firewall rule to mask the source as the alias and pipe all the traffic into the Voip queue.

This is rudimentary, of course, since the 320Kbps is forever reserved for the voip purpose but tweaking for a more fair share is very heavily dependent on the specific traffic type you see on the network.

Example:
Assuming each voip packet is 1.6kb and you need 30ms max. for clear calls.  This is for one way, you need another similar queue for the other direction.

qVoipUp & qVoipdown
realtime (m1 d m2): 6.4KbKb 30 160Kb
bandwidth (m1 d m2): 160Kb 100 160Kb

Assuming the phones are using 192.168.1.100 to 192.168.1.104 as their IPs:
Alias IPs 192.168.1.100 to 192.168.1.104 as 'voipips'

Set the firewall rules to:
voip outbound
Protocol:  Any
Source port:  ANY
Source IP:  voipips
Dest. port:  ANY
Dest. IP:  ANY
Queue:  qVoipUp

voip inbound
Protocol:  Any
Source port:  ANY
Source IP:  ANY
Dest. port:  ANY
Dest. IP:  voipips
Queue:  qVoipDown

No, if you put the "voip IP", it applies to all traffic wrt that host, AFAIK.  yes, for IAX2, you can prioritize UDP/4569 though.

In 2.0 you can use the traffic shaper wizard to setup rules that will affect all WANs, and give some priority to different traffic.

Though if your downloads are on port 80 and the streaming video is also on port 80, it may not really be possible to differentiate accurately in an easy way.

You're probably best paying for the commercial support service that's available since it sounds like you're massively out of your depth.

@changhe:

I got an answer from the moderator heiko in the german speaking part of this forum:

@heiko:

Hallo,

nicht möglich auf 1.23, nur mit einer Spzialversion der 1.2 von Ermal. Drer Traffic Shaper is in der 2.0 komplett überarbeitet und bietet dort auch IPSec TS etc.

Regards
Heiko

Translation:

It is not possible with 1.23. There is a special version of 1.2 from Ermal, which can do it. The traffic shaper is completely reviseded in 2.0 and has traffic shaping inside it's IPSec tunnels etc.

mh, okay. i'm now strugled over this post. i need also this shaping inside the vpn tunnel, because the tunnel use the full bandwith.

regards

ermal,

When we discussed this the other day, you said with multi-wan it was better to put the limiters on floating rules (unless I misunderstood something, which when it comes to shaping is quite possible).

Or perhaps that was specific to what the other person was trying to do.

P2P trafic can't  detect any rules  :-[

Oh yeah, good point.

I assume you mean NNTP?  If so, that is port 119, if memory serves.  Can't you just penalize that?

@jimp:

You probably want the Limiters feature, but that is only available in pfSense 2.0.

if it can give a global limit and a exception on certain ip/macs than i have to wait till 2.0

and going through the wizard for a third time is resulting in ~80ms while downloading. i think i'll just monitor it for a bit, seems to be ok.

I was able to solve this problem by turning off the FTP userland helper on the LAN interface.

For 99% of the users on the network, blocking/shaping bittorrent traffic using commonly-used ports seems to be effective. For the 1% who got through, you can use other means of tracking them down.