[cisco-voip] Dropped calls on CUCM 6.1 cluster

[Wes Sisk]

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.com>
To: Damian Turburville <d_turburville at yahoo.com> 
Cc: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net> 
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.com>
To: Damian Turburville <d_turburville at yahoo.com> 
Cc: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net> 
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.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120510/b4078373/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 22811 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120510/b4078373/attachment.png>