For this discussion, I assume you're running your IPSec/GRE tunnel across the Internet.

If your truly want to "dedicate" bandwidth, you need something like RSVP, but if you prioritize your voice application traffic (which I'll refer to as VoIP), I think you'll accomplish what you desire.

What you can do is insure your VoIP goes to the head of the line as it's injected into the tunnel. This can be accomplished by using CBWFQ and placing your VoIP traffic into a defined LLQ class, minimally with a 2 Mbps cap.

If your platform supports CBWFQ at the tunnel interface, you can place the CBWFQ there, otherwise you'll place it on your outbound physical interface. If the latter, you need to insure the VoIP packets have either a IP Precedence tag or DSCP marking that's in the outer packet so CBWFQ can recognized the encrypted VoIP packets and send them first. To do this, you need to have the packets marked before they enter the tunnel and might need to use the command "qos pre-classify" to copy the tags.

Usually besides the tunnel ingress being a bandwidth bottleneck, so often is the egress. If only your one tunnel is running across the egress, and its physical bandwidth matches the ingress side, you're fine.

If the egress side is less than the ingress, and again there's only traffic from the one tunnel, you need to shape the ingress to be no more then the egress. You will need at least enough bandwidth on egress to match your VoIP cap.

If you have other traffic on the egress link, you would need your ISP to also honor your VoIP markings (another instance you'll need the markings in the outer packet) by sending them first, and also have enough bandwidth for all your VoIP traffic.