[cisco-voip] CUCM Location question

[Erick Bergquist]

Ok. Thanks. That was the bug Id I was looking at, it was in the hot
issue RSS feeds also.

On Thu, Apr 17, 2008 at 11:35 AM, Wes Sisk <wsisk at cisco.com> wrote:
> 2104 is a safe place to land for now.  At the time of posting (20 Mar) 2104
> had been stable in deployments for at least 4 weeks with no major issues.
>
>  i believe you were looking at CSCsm95717.
>
>  /wes
>
>
>
>  Erick Bergquist wrote:
>
> > Ah, thanks. We're going to do proactive method. Whats the latest 5.1.3
> > ES you would go with?  I did some bug hunting yesterday and found a
> > bug involving cdcc leaks that was fixed in 5.1.3 2107 but didn't jot
> > down the id. It looks like 2104 is the latest on the download page.
> >
> > Erick
> >
> > On Tue, Apr 15, 2008 at 3:01 PM, Wes Sisk <wsisk at cisco.com> wrote:
> >
> >
> > > Cdcc = call dependent call control, a logical pointer to a call in CM's
> > > memory.
> > >
> > >  These types of issues are very interesting and challenging.  Most
> effective
> > > approach so far has been:
> > >  1. setup a trace archive server archive CM SDI and SDL and CTI SDI and
> SDL
> > > traces.
> > >  2. identify a period of low (no) utilization on the system, typically
> > > midnight/early AM, call the first low period T1
> > >  3. confirm counter value V1 at T1.
> > >  4. wait for next low period T2. check counter.  If a leak has occurred
> (V2
> > >
> > >
> > > > V1 with no obvious system activity)
> > > >
> > > >
> > >  collect all traces from T1 to T2.  Provide traces, T1, T2, V1, V2, to
> TAC.
> > >
> > >  TAC will run a series of scripts on these traces, especially CM SDL
> traces,
> > > to identify potential leaks.
> > >
> > >  It is certainly non-trivial to collect the diagnostics let alone
> perform
> > > the analysis.  If proactive upgrade is an option it is highly
> recommended.
> > > Something late in the 5.1.3branch on 6.1 would be a much better starting
> > > point.
> > >
> > >  /Wes
> > >
> > >
> > >
> > >  Erick Bergquist wrote:
> > >
> > >
> > >
> > > > Ok, it appears to have a bandwidth leak. A reboot has cleared the
> > > > issue and the bandwidth values in RTMT are good a day later.  What
> > > > does cdcc stand for?  I'm searching bug toolkit for bugs. This is on a
> > > > 5.1.1-3126-1 version cucm BTW.
> > > >
> > > > Thanks.
> > > >
> > > >
> > > > On Mon, Apr 14, 2008 at 9:22 AM, Wes Sisk <wsisk at cisco.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > > No, locations CAC does not include signaling.  sounds like a
> bandwidth
> > > > >
> > > > >
> > > >
> > > leak
> > >
> > >
> > > >
> > > > > has occurred. these are typically associated with cdcc leak as well.
> > > > >
> > > > >
> > > >
> > > /wes
> > >
> > >
> > > >
> > > > >  Erick Bergquist wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > Does signalling traffic count toward location bandwidth?
> > > > > >
> > > > > > Have a setup where a site has audio bandwidth set to 1544, and
> when
> > > > > > there are no phone calls active, it is using 39 bandwidth for
> > > > > > CallsInProgress object under Locations in RTMT.
> > > > > >
> > > > > > _______________________________________________
> > > > > > cisco-voip mailing list
> > > > > > cisco-voip at puck.nether.net
> > > > > > https://puck.nether.net/mailman/listinfo/cisco-voip
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>