[cisco-voip] Redundancy -- Quality of Voice -- QoS vs RSVP

[Nick Matthews]

RSVP is good for CAC in non hub and spoke topologies - like partial
mesh and hierarchical, and any mix of those.  It has definite
configuration costs associated.

One alternative is call thresholding on the routers.  They can make
routing decisions based on how many calls have gone out a dial peer,
the bandwidth on an interface, CPU/memory utilization, etc.  It's
still hop by hop so you have some more options.

Regarding the versions - there have been enhancements, but since I
haven't seen it widely deployed I really have no idea what the
implications are.  My guess is you can get it to work on 7.1 if you
want, but there are some more specific abilities in 8.0+.

-nick

On Fri, Jun 24, 2011 at 5:07 PM, Scott Voll <svoll.voip at gmail.com> wrote:
> Correct..... because your routing over A and not B..... Now if A fails then
> your now routing over B and the same thing would be true.  if B has
> bandwidth then great if no, then fail.
> This was exactly what I was looking for.  A way to still do CAC but have
> redundant links for possible network failures.
> Scott
>
> On Fri, Jun 24, 2011 at 11:09 AM, Robert Kulagowski <rkulagow at gmail.com>
> wrote:
>>
>> Blind-leading-the-blind here, but when I looked at RSVP it was still
>> built over the underlying routing protocols.  If there are two links
>> into Site B, RSVP is still going to say, "OK, there's a path to Site B
>> over link A".  "Does Link A have bandwidth?"  If yes, great.  If no,
>> then the call "fails", even if there was bandwidth available on Link
>> B.
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>