Is transcoding mandatory for RSVP?

Unanswered Question
Feb 8th, 2010

Hi All

Forgive my ignorance but RSVP is not a technology I've really seen very much of in real world environments and in my ccie voice lab preparation I have been configuring it for some practice.

From what I understand, in order to have RSVP working you must have rsvp call agents registered on each remote gateway, and this is done with an enhanced ios transcoding resource registered against the CUCM for each site.

When I configure this, rsvp correctly allocates the bandwidth, and the call proceeds but for some reason, the phones decides its a good idea to terminate on the gateway / call agent / transcoder, rather than connecting directly end to end. When it does this, the call runs G711 from phone to gateway, then G729 across the WAN, then back to G711 for the gateway to phone leg again. The only explaination I have come up with is that since the rsvp agent is in the same region as the phone, the phone uses G711 and the two gateways then transcode the call to G729 across the WAN (as per expected inter region behavior).

I tried adding the transcoding resources to their own device pools. I duplicated all settings on the local phone location for each gateway except for the region, thinking that this would force G729, but then RSVP is not even attempted by the CUCM and the call is rejected due to insufficient bandwidth.

So my questions are:

Why are the phones terminating on the transcoders? Is this how it's supposed to work? Somehow I dont think so, as thats a much more expensive CAC solution than Locations, and not very scalable. I could be wrong though!

Why does the call-agent have to be in the same device pool / region as the phone in order to activate RSVP? Surely the fact that it's in the same location should be sufficient. Does this mean that RSVP is invoked based on region, and not on location and what implications does that have for the above scenario.


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)


This Discussion

Related Content