<div>Ted correct me if I'm wrong but I thought the requirement for hub and spoke was due to the situation below.</div>
<div> </div>
<div>SiteA <-link to-> Site B <-link to-> Site C</div>
<div> </div>
<div>If site A calls Site C the CM or GK based CAC only deducts bandwidth from SiteA and SiteC and does not deduct bandwidth from SiteB even though the RTP stream must traverse Site B's links to reach SiteC. Therefore the CM or GK CAC is unable to accurately keep track of the available bandwidth to SiteB.
</div>
<div> </div>
<div>I think perhaps Craig is using a SP based full mesh VPN and is using CM based CAC under the assumption that the only bandwidth bottlenecks are the access links to each of his sites. If this is truely the case and there will never be any bandwidth issues in the SP cloud then CM or GK CAC should work in this situation.
</div>
<div> </div>
<div>My thoughts</div>
<div>Justin<br><br> </div>
<div><span class="gmail_quote">On 2/1/07, <b class="gmail_sendername">Ted Nugent</b> <<a href="mailto:tednugent69@yahoo.com">tednugent69@yahoo.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Honestly no offense intended however, I'm afraid that<br>you might need to take another look at the SRND and/or
<br>understand how Locations based CAC actually works.<br>Location based CAC uses the CallAgent (CM) as the<br>point of reference for all calculations and<br>adds/subtracts bandwidth in reference to the CM<br>Cluster Location (aka hub spoke). If you are using a
<br>partial or fully meshed topology your calls will<br>nullify these calculations. Let take for example the<br>stick figure topology below.<br><br> Site1<br>HQ < |<br> Site2<br><br>Links from HQ to Site1 and Site2 and another link
<br>between Site1 and Site2 directly. If a g729 call is<br>made from Site1 to Site2 and your not "forcing" the<br>voice path to hub spoke, the call is traversing the<br>direct link between Site1 and Site 2 however CM
<br>assumes the call goes from Site1 to HQ and then to<br>Site2 and ticks off 24kps from each location (link),<br>when in actuality the call is not touching these<br>links. This is a very simply scenario but I think you<br>
can under the basis.<br>If you don't believe me or the SRND then feel free to<br>take a look at your locations in perfmon. GK CAC is a<br>bit more forgiving in its zone configuration however<br>it suffers from the same probably that it is not aware
<br>of the topology.<br><br>If you feel I'm missing something then please<br>elaborate. I'm all ears.<br><br>SRND<br><a href="http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guide_chapter09186a00806e8c1e.html#wp1073144">
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guide_chapter09186a00806e8c1e.html#wp1073144</a><br><br><br><br><br><br><br>--- Craig M Staffin <<a href="mailto:cmstaffin@ra.rockwell.com">
cmstaffin@ra.rockwell.com</a>> wrote:<br><br>> Ted,<br>><br>> This really is not true. We have a full mesh<br>> network through VPN and we<br>> use CCM CAC and it works great. We have calls from<br>> and to many sites at
<br>> one point in time. How locations work in CCM is<br>> that you add all things<br>> physically at the site into one location and so on.<br>> There for even if you<br>> have 20 sites all connected any call out of that
<br>> site will count against<br>> the total. I also do not know why GK wouldn't be<br>> able to do the same<br>> thing as it works the same way.<br>><br>> Craig<br>><br>><br>><br>><br>> Ted Nugent <
<a href="mailto:tednugent69@yahoo.com">tednugent69@yahoo.com</a>><br>> Sent by: <a href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</a><br>> 02/01/2007 07:31 PM<br>><br>> To
<br>> embeleco <<a href="mailto:embeleco@gmail.com">embeleco@gmail.com</a>>,<br>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>> cc<br>><br>> Subject<br>> Re: [cisco-voip] CAC Recommendation for a VoIP
<br>> Network<br>><br>><br>><br>><br>><br>><br>> Unless you "force" the voice path to hub-spoke which<br>> could break your CAC if a link goes down your stuck<br>> using RSVP. Neither GK CAC nor Locations based CAC
<br>> are<br>> Topology aware and require a hub spoke topology of<br>> some sort.<br>><br>><br>> --- embeleco <<a href="mailto:embeleco@gmail.com">embeleco@gmail.com</a>> wrote:<br>><br>> > Hi.
<br>> ><br>> > I would like CAC recommendations for a VoIP<br>> network<br>> > that consist of 6-10<br>> > (backbone sites) sites connected in a fully mesh<br>> > topology (not<br>> > hub-and-spoke). Currently is a toll-by-pass
<br>> solution<br>> > consisting of Legacy<br>> > PBX connected to Cisco VoIP Gateways using<br>> > ISDN-PRI/Q.SIG signaling. Also<br>> > customer has Gatekeepers in order to centralized<br>> > dialplan. We are defining
<br>> > which CAC (Call Admission Control) to use with the<br>> > fully mesh topology.<br>> ><br>> > We were thinking to use CAC at the gatekeeper but<br>> > that will work best for<br>> > hub and spoke scenarios. It meas that gatekeepers
<br>> > will not know where the<br>> > call is going within the network... the other CAC<br>> > solution that we are<br>> > considering is RSVP.<br>> ><br>> ><br>> > Any suggestions? Recommendations? Which CAC
<br>> solution<br>> > to consider?<br>> ><br>> > Thanks in advanced.<br>> > > _______________________________________________<br>> > cisco-voip mailing list<br>> > <a href="mailto:cisco-voip@puck.nether.net">
cisco-voip@puck.nether.net</a><br>> ><br>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>> ><br>><br>><br>><br>><br>>
<br>><br>____________________________________________________________________________________<br>> Need Mail bonding?<br>> Go to the Yahoo! Mail Q&A for great tips from Yahoo!<br>> Answers users.<br>><br>
<a href="http://answers.yahoo.com/dir/?link=list&sid=396546091">http://answers.yahoo.com/dir/?link=list&sid=396546091</a><br>> _______________________________________________<br>> cisco-voip mailing list<br>
> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>><br>> > _______________________________________________
<br>> cisco-voip mailing list<br>> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip
</a><br>><br><br><br><br><br>____________________________________________________________________________________<br>Never miss an email again!<br>Yahoo! Toolbar alerts you the instant new Mail arrives.<br><a href="http://tools.search.yahoo.com/toolbar/features/mail/">
http://tools.search.yahoo.com/toolbar/features/mail/</a><br>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">
https://puck.nether.net/mailman/listinfo/cisco-voip</a><br></blockquote></div><br>