wsisk at cisco
May 10, 2012, 7:51 AM
Post #11 of 11
(1083 views)
Permalink
|
aggregated:
cause count
41 309
47 100
18 29
17 13
50 10
95 5
102 5
111 5
27 4
34 3
38 3
63 3
19 1
87 1
41 and 47 are caused by codec negotiation failure and devices unregistering or losing call control session during call. Also h.245 session for h.323 call failing to establish.
18 = "Connection cannot be completed because the destination does not respond to the call." This sounds like calling a destination that does not have voicemail so the call rings until timeout.
17 = "Called system acknowledges the connection request but is unable to accept the call because all B channels are in use." Typically referred to as "user busy".
it's all down hill from there.
So, now look for patterns in the orig_devicename or dest_devicename for the calls with origcause_value or destcause_value equal to 41 or 47.
Regards,
Wes
On May 10, 2012, at 4:51 AM, Damian Turburville wrote:
Wes,
That is exactly what we are seeing. See below
admin:run sql select count(*) as count,origcause_value from car:tbl_billing_data where origcause_value not in (0,16,126,128,393216,458752) group by origcause_value order by count asc
count origcause_value
===== ===============
1 87
1 34
1 111
3 38
3 63
4 27
5 102
5 95
6 17
10 50
29 18
74 47
150 41
admin:run sql select count(*) as count,destcause_value from car:tbl_billing_data where destcause_value not in (0,16,126,128,393216,458752) group by destcause_value order by count asc
count destcause_value
===== ===============
1 19
2 34
4 111
7 17
26 47
159 41
DT
From: Wes Sisk <wsisk [at] cisco>
To: Damian Turburville <d_turburville [at] yahoo>
Cc: "cisco-voip [at] puck" <cisco-voip [at] puck>
Sent: Wednesday, 9 May 2012, 16:12
Subject: Re: [cisco-voip] Dropped calls on CUCM 6.1 cluster
It is possible. It seems a little less likely. CM is involved in call setup and then largely out of the picture.
I can imagine a way that server performance would impact an active call:
* call is setup between h.323 gateway and sccp phone
* media is directly between phone and gateway
* keepalives still occur on the signaling channels between phone and cm and gw and cm
* server performance degrades so keepalives are dropped or otherwise not processed
* phone or gateway signaling session aborts
* because it is h.323 call preservation is disabled by default. When the signaling session aborts the call is dropped.
This would appear in CDR's with cause codes in the 40's range like 41 and 47.
here is a sample of CDR aggregation from a cluster that experienced this exact issue:
+--------------------+-----------------+----------+
| destdevicename | destcause_value | count(*) |
+--------------------+-----------------+----------+
| ICT-Development | 41 | 6 |
| ICT-site1 | 41 | 74 |
| ICT-site1 | 47 | 2351 |
| ICT-site2 | 41 | 3 |
In this case packets were dropping in the WAN between this site and site1.
Regards,
Wes
On May 9, 2012, at 10:32 AM, Damian Turburville wrote:
Cheers Wes and Kiran,
On a possibly related note our Publisher server has started popping up Virtual Memory errors as copied below
Available virtual memory below 30 Percent.
tomcat (884 MB) uses most of the memory.
Could this be related? Is it something major that needs to be sorted?
Cheers,
DT
From: Wes Sisk <wsisk [at] cisco>
To: Damian Turburville <d_turburville [at] yahoo>
Cc: "cisco-voip [at] puck" <cisco-voip [at] puck>
Sent: Thursday, 3 May 2012, 16:08
Subject: Re: [cisco-voip] Dropped calls on CUCM 6.1 cluster
Maybe something like this:
Dropped Call Troubleshooting in CUCM
https://supportforums.cisco.com/docs/DOC-1208
Regards,
Wes
On May 3, 2012, at 4:34 AM, Damian Turburville wrote:
Hi,
We are getting calls disconnected mid-call on random handsets in our CUCM 6.1 cluster( 1 pub 2 subs), actually it seems to be phones on one particular subscriber that are experiencing the issue but that might be a red herring. The users say it is happening on all types of calls but we are trying to get more detailed info from them atm.
Does anyone have any ideas how can I start to track this down? Please be as basic as possible so I can understand :-)
Many thanks,
DT
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip
|
image001.png
