[cisco-voip] CUCM Location question

[Wes Sisk]

it is from CM SDL. /wes

Erick Bergquist wrote:
> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>