[cisco-voip] CUCM Location question

Thu Apr 17 22:19:57 EDT 2008

Well, mobility manager redirects the call, so the potential is there.
I'll see what the posted ES is when the time comes to doing this (2-3
weeks) since it is about 4 weeks since 2104 was posted. Is that trace
snippet from a CCM or CTI SDL trace?  Thanks.

On Thu, Apr 17, 2008 at 2:30 PM, Wes Sisk <wsisk at cisco.com> wrote:
> Hi Erick,
>
>  Weak Release-note there.  I will update it with some additional details:
>
>  <B>Conditions:</B>
>  Call is redirected several times and at the end we get back an
>  SsRedirectCallErr and we receive a CcRelInd signal in Cdcc but since we are
> in
>  await_redirect_failure_restore state, we just put that release signal on
> the
>  saved queue and then no further activity:
>
>  11:12:21.364|001|SdlSig-O|SsRedirectCallErr|NA
>  RemoteSignal|UnknownProcessName(2,200,18,1)|Cdcc(1,100,159,779)|(2,200,1
>  5,1).11120-(PP-B1788:10.239.239.2)|[R:NP - HP: 0, NP: 1, LP: 0, VLP: 0,
>  LZP: 0 DBP: 0]Type=16777245 Key=8768 Node=1 Party=32645909
>  RedirectCallErr=12
>
>  Looks like this is triggered by cascaded call redirects. If that is likely
> in your cluster then may be better off opening TAC case and getting ES with
> with this fix.
>
>
>
>  /Wes
>
>
>  Erick Bergquist wrote:
>
> > 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>