Kevin,
First, I want to correct this:
Ultimately the Signalling traffic has to take priority over Voice
Also, unless you're really rewriting your DSCP values on voice traffic, you're using the wrong values. Voice signaling (control traffic) is DSCP AF31 or CS3 depending on where it is coming from. RTP voice payload is DSCP EF.
You never want to put your signaling traffic in a priority queue. The reason for this is that during a burst where the priority queue is exceeded, it can starve the signaling traffic completely, and cause issues like calls not being presented to the other side, or MGCP registration issues. I often see issues where customer throw MGCP traffic in a priority queue, and due to the burst of traffic when the PRIs register (AUEP/response), the traffic is dropped at the edge and the endpoint never registers. We actually make mention in the CUCM SRND to not put signaling traffic in a priority queue for this reason.
You are correct that you want to shape your interface to the speed of the link though, so that you move the congestion point to the router in which you can control QoS.
Here is a sample config which should work for you:
class-map match-any voice-control
match ip dscp af31
match ip dscp cs3
match protocol mgcp
match protocol h323
match protocol sip
match protocol skinny
class-map match-any voice-RTP
match ip rtp 16384 16383
!
!
policy-map Voice-QoS
class voice-RTP
priority [bandwidth-value]
set dscp ef
class voice-control
bandwidth [bandwidth-value]
set dscp 0
class class-default
fair-queue
Note that I'm matching the priority queue based on RTP port range for Cisco products instead of DSCP EF. I prefer this way due to a) some people have DSCP trustings misconfigured in the LAN and the DSCP/EF ends up getting stripped on a L3 switchport before it hits the QoS router and b) it prevents rogue traffic with DSCP/EF that isn't voice RTP from getting put in the priority queue. This is also why I throw NBAR matching on for the signaling protocols. It's a safety mechanism, since often times when I help people with QoS, I'm not looking at all of their DSCP trusting configuration upstream from the WAN edge.
Your RTP queue shouldn't be bursting to 400%. RTP traffic is a consistent flow, and is really just based on codec and call quantity. Priority queue size depends on the amount of calls which you want to sustain, and the codec/L2 overhead being used. Calculate that here, and set the size for whatever the maximum you're willing to support before you run into call quality issues. You can use CAC to control that only that amount of calls are allowed to be setup across the link, if desired:
http://tools.cisco.com/Support/VBC/do/CodecCalc1.do
The size of the priority queue should always match (or be less than) what the provider has provisioned for the priority queue. That way, if there is congestion, you'll see it drop on your counters instead of it being dropped in the cloud where you don't have visibility.
For a rough estimate of the BW used for signaling traffic, use .25k per IP phone/endpoint at the site. Note that we're stripping the DSCP on the signaling queue, since your provider doesn't have another queue provisioned, and we *dont* want the potential for that traffic to get dropped in the pri queue and starved.
After applying it, watch the output of 'sh policy-map int' to make sure you aren't taking drops on your priority queue or signaling queue. If you see drops, the queue sizes either need to be raised for the amount of calls you push through the circuit, or you need to configure CAC to limit the amount of calls to what you have provisioned.
