[cisco-voip] CUCM Location question

[Wes Sisk]

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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>