Ah, I understand your situation. Not that uncommon with carries that offer bandwidth limits less than physical interface bandwidth.
Generally, for what you're trying to mitigate, Bc is not (too much) the variable we're interesting in changing.
First, you need to fully understand, all a shaper really does for us, is move the congestion point from somewhere further upstream, where we can cannot manage it, to somewhere we can manage it. I.e. if your traffic is overrunning available bandwidth, that will still be true using a shaper (alone). Again, though, a shaper, allows us to manage congestion.
What you want to do, is set the average rate to be the provider's "up" bandwidth, although, say, about 15% less. (The latter, because, I believe many Cisco shapers don't account for L2 overhead, and 15%, usually covers that.)
Once all the congestion is at the shape, you can manage this congestion. For example, for your RTP UDP traffic, you might insure it gets dropped last and/or provide it additional buffer/queuing space and/or prioritize it over other traffic. I can suggest how you can do any all of the forging, but you need to define what this RTP traffic "needs".
Coming back to Bc (and Be), those might need adjustment too. You adjust them smaller to make a shaper behave "closer" to a physical link of the same bandwidth, which might be important if jitter is a RTP consideration.
