[cisco-voip] CAC Recommendation for a VoIP Network

[Ted Nugent]

Justin,
Yes Thanks, I like your example better then my stick
figure but I think the premise is the same, all
calculation are based off of CM as a reference point
and therefore "assumes" hub-spoke, CM being the hub.

If the SP VPN/MPLS solution is what Craig was
referring to then I also agree the "mesh" topology
should be irrelevant and my answer to the initial
question still stands. If we're talking about a
customer owned mesh topology and you're not "forcing"
the voice path to hub-spoke (granted not ideal) then
CM location calculation will not be accurate. There
are certainly some situation that you can fudge it to
make it work but its obviously not ideal and RSVP is
really the only viable solution.





--- Justin Steinberg <jsteinberg at gmail.com> wrote:

> Ted correct me if I'm wrong but I thought the
> requirement for hub and spoke
> was due to the situation below.
> 
> SiteA <-link to-> Site B <-link to-> Site C
> 
> 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.
> 
> 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.
> 
> My thoughts
> Justin
> 
> 
> On 2/1/07, Ted Nugent <tednugent69 at yahoo.com> wrote:
> >
> > Honestly no offense intended however, I'm afraid
> that
> > you might need to take another look at the SRND
> and/or
> > understand how Locations based CAC actually works.
> > Location based CAC uses the CallAgent (CM) as the
> > point of reference for all calculations and
> > adds/subtracts bandwidth in reference to the CM
> > Cluster Location (aka hub spoke). If you are using
> a
> > partial or fully meshed topology your calls will
> > nullify these calculations. Let take for example
> the
> > stick figure topology below.
> >
> >      Site1
> > HQ <    |
> >      Site2
> >
> > Links from HQ to Site1 and Site2 and another link
> > between Site1 and Site2 directly. If a g729 call
> is
> > made from Site1 to Site2 and your not "forcing"
> the
> > voice path to hub spoke, the call is traversing
> the
> > direct link between Site1 and Site 2 however CM
> > assumes the call goes from Site1 to HQ and then to
> > Site2 and ticks off 24kps from each location
> (link),
> > when in actuality the call is not touching these
> > links. This is a very simply scenario but I think
> you
> > can under the basis.
> > If you don't believe me or the SRND then feel free
> to
> > take a look at your locations in perfmon. GK CAC
> is a
> > bit more forgiving in its zone configuration
> however
> > it suffers from the same probably that it is not
> aware
> > of the topology.
> >
> > If you feel I'm missing something then please
> > elaborate. I'm all ears.
> >
> > SRND
> >
> >
>
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guide_chapter09186a00806e8c1e.html#wp1073144
> >
> >
> >
> >
> >
> >
> > --- Craig M Staffin <cmstaffin at ra.rockwell.com>
> wrote:
> >
> > > Ted,
> > >
> > > This really is not true.  We have a full mesh
> > > network through VPN and we
> > > use CCM CAC and it works great.  We have calls
> from
> > > and to many sites at
> > > one point in time.  How locations work in CCM is
> > > that you add all things
> > > physically at the site into one location and so
> on.
> > > There for even if you
> > > have 20 sites all connected any call out of that
> > > site will count against
> > > the total.  I also do not know why GK wouldn't
> be
> > > able to do the same
> > > thing as it works the same way.
> > >
> > > Craig
> > >
> > >
> > >
> > >
> > > Ted Nugent <tednugent69 at yahoo.com>
> > > Sent by: cisco-voip-bounces at puck.nether.net
> > > 02/01/2007 07:31 PM
> > >
> > > To
> > > embeleco <embeleco at gmail.com>,
> > > cisco-voip at puck.nether.net
> > > cc
> > >
> > > Subject
> > > Re: [cisco-voip] CAC Recommendation for a VoIP
> > > Network
> > >
> > >
> > >
> > >
> > >
> > >
> > > Unless you "force" the voice path to hub-spoke
> which
> > > could break your CAC if a link goes down your
> stuck
> > > using RSVP. Neither GK CAC nor Locations based
> CAC
> > > are
> > > Topology aware and require a hub spoke topology
> of
> > > some sort.
> > >
> > >
> > > --- embeleco <embeleco at gmail.com> wrote:
> > >
> > > > Hi.
> > > >
> > > > I would like CAC recommendations for a VoIP
> > > network
> > > > that consist of 6-10
> > > > (backbone sites) sites connected in a fully
> mesh
> > > > topology (not
> > > > hub-and-spoke). Currently is a toll-by-pass
> > > solution
> > > > consisting of Legacy
> > > > PBX connected to Cisco VoIP Gateways using
> > > > ISDN-PRI/Q.SIG signaling. Also
> > > > customer has Gatekeepers in order to
> centralized
> > > > dialplan. We are defining
> > > > which CAC (Call Admission Control) to use with
> the
> > > > fully mesh topology.
> > > >
> > > > We were thinking to use CAC at the gatekeeper
> but
> > > > that will work best for
> > > > hub and spoke scenarios. It meas that
> gatekeepers
> > > > will not know where the
> > > > call is going within the network... the other
> CAC
> > > > solution that we are
> > > > considering is RSVP.
> > > >
> > > >
> > > > Any suggestions? Recommendations? Which CAC
> > > solution
> > > > to consider?
> > > >
> > > > Thanks in advanced.
> > > > >
> _______________________________________________
> > > > cisco-voip mailing list
> > > > cisco-voip at puck.nether.net
> > > >
> > >
> https://puck.nether.net/mailman/listinfo/cisco-voip
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
____________________________________________________________________________________
> 
=== message truncated ===



 
____________________________________________________________________________________
Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/features_spam.html