I am not a Cisco employee, just another engineer but I must agree with you.

I too am a bit perplexed at the lack of in-depth documentation on the RSVP agent given how much Cisco has been promoting it in the product literature.

From what I do understand about the agent, it only proxies the RSVP requests for the call path. It doesn't require, as far as I can tell, that the router acting as the RSVP agent be part of the call path. It is supposed to be relatively simple to configure and remove the complexity of RSVP network design.

Thus, the local voice gateway(s) for CUCM are your RSVP agent(s) for CallManager 5.X or 6.X. The voice path does not necessarily need to traverse the gateway(s). My read is that the agent simply proxies the RSVP requests to the routers that will be a part of the RTP path.

This is my first time deploying RSVP agent as well and the one thing I am doing is to add: 'ip rsvp signalling dscp 24' (My customer's MPLS provider uses IP Precedence not DSCP so if you are using DSCP use 26 instead) to my RSVP interfaces so that the rsvp request will be queued and forwarded instead of accidentally being dropped during congestion.

Please reply, anyone, with your experience using the RSVP Agent. Love to hear about the benefits/problems with it.

I am considering deploying RSVP in a similar network configuration. 4 clusters and an ipsec tunnel overlay over MPLS. Can RSVP be used in this instance and what are the ramnifications?

Cisco has updated the RSVP agent information in the latest SRND for CUCM 7. I'd suggest reading it as a starting point for your design.

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/srnd/7x/cac.html#wp1043949

The new Unified Border Element is used in the SRND for calls that traverse clusters.

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/srnd/7x/cac.html#wp1044413