VoIP cannot connect when other QOS class saturated

[tcpmux]

Hi. I'm running Gargoyle stable (1.8.1) on a TP-LINK WR1043ND (v.2.1). On the WAN side is a field satellite Internet system with about 1500 kb/s down and 512 kb/s up. I'm running an event out in the field and trying to create a QoS situation where two VoIP phones (RingCentral/Cisco devices) will always run fine regardless of what else is going on.

I've got four QoS classes (the last two are not being used for anything yet). The main ones are VoIP and Normal. The two phones are given statics and set in the rules to go to VoIP class. Through testing, I know that all the phone traffic is in fact being classified as VoIP class, and the other data is being classified as Normal, at least when the phone data is going through. The ACC is currently turned on. I am not using any quotas.

My problem: The QoS works just fine whenever a phone call is already established. That is, I can make a phone call, and while the phone call is running, I can turn on YouTube videos, and although the normal class is saturated, the VoIP continues to received load and the call works fine. However, if I saturate the Normal class first (i.e., turn on a YouTube video) then the voip phones lose the ability to establish connections. So, it is as though the QoS is not able to adapt fast enough to the fact that the phones are trying to use data.

Is there something I could tweak here that would help?

[I had some nice screen shots prepared, but the board won't allow upload of even 30 KB images.)

QoS Download:

Rules:

Destination: 192.168.3.10 VoIP
Destination: 192.168.3.11 VoIP

Classes:

VoIP 10% 80 200 Yes 0.0
Normal 61% zero nolimit 0.0
Admin 19% zero nolimit 0.0
Throttled 10% zero nolimit 0.0

Total Download Bandwidth:
1500 kbits/s

QoS Upload:

Rules:

Source: 192.168.3.10 VoIP
Source: 192.168.3.11 VoIP

Classes:

VoIP 10% 80 nolimit 0.0
Normal 61% zero nolimit 0.0
Admin 19% zero nolimit 0.0
Throttled 10% zero nolimit 0.0

Total (Upload) Bandwidth:
512 kbits/s

[tcpmux]

I realized that I had the bandwidth settings to high. The available bandwidth on the WAN side is only 1024 down and 256 up. When I adjust the QoS bandwidth settings for that, it seems to work a little better now, but not perfectly. Will do some more testing tomorrow.