<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Another interesting apprach:<br>
use CDR data to find calls active when the problem occurred (where
datetimeconnect < value and value < (datetimeconnect +
duration)). This will give the origdevicename, destdevicename,
callingpartynumber, and finalcalledpartynumber.<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cdr_defs/4_x/cdr413.html">http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cdr_defs/4_x/cdr413.html</a><br>
<br>
/Wes<br>
<br>
Wes Sisk wrote:
<blockquote cite="mid:4818CFD6.9060804@cisco.com" type="cite">
<pre wrap="">Hi Kevin,
Good catch on the phones, that is a frequent trigger. Other info inline
[ws]:
</pre>
<blockquote type="cite">
<pre wrap="">1. Anyway to see the number of inter location calls active and there DN's ?
</pre>
</blockquote>
<pre wrap=""><!---->ws: perfmon counter (RTMT counters in 5.x and later) will show active
calls per region/location and available b/w. Unfortunately it does not
correlate to device/dn.
</pre>
<blockquote type="cite">
<pre wrap="">2. Anyway to see which calls are currently making up the
inter-location calculation ?
</pre>
</blockquote>
<pre wrap=""><!---->ws: CM SDI traces. For traces turn up detailed CM SDI traces and set
the CM service parameter "Locations Trace Details Flag". For CDR effort see:
<a class="moz-txt-link-freetext" href="http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cdr_defs/4_x/cdr413.html">http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cdr_defs/4_x/cdr413.html</a>
</pre>
<blockquote type="cite">
<pre wrap="">3. Any other possible reasons to get the "Congestion" messages ?
</pre>
</blockquote>
<pre wrap=""><!---->ws: this is strictly determined by CM's internal bandwidth accounting
(well, until 6.x and RSVP agents). So this very likely has nothing to do
with actual interface or link usage, it's just what CM believes is
happening based on configuration.
</pre>
<blockquote type="cite">
<pre wrap="">4. Any other hints most welcome ?
</pre>
</blockquote>
<pre wrap=""><!---->ws: wait until after hours or low period of utilization and check
perfmon counters for avail/used bandwidth per location. If CM
encoutnered a Cdcc or bandwith leak you will see bandwith used even at
times when no calls are active. If perfmon counters shows calls active,
does it make sense? A Cdcc leak could leave a 'call' active and
bandwidth reserved. Recovery is either restart CM service or click
"resync bandwidth" on the locations bandwidth page. With the location
trace details flag enabled the locations bw table is printed in SDI
traces every time locations b/w is reallocated. In the table you see
the Cdcc value for every 'active' call. Example: cdccPID=(2.22.83776).
If you look in the table and see two entries cdccPID=(2.22.83776) and
cdccPID=(2.22.83) This would imply 2 active calls. The last number is a
monotonically increasing sequence number for every call. This would
imply that the '83rd' call is up and consuming bandwidth and the
'83776th' call is up and consuming bandwidth. Logically this does not
make sense. It is extremely unlikely that both the 83rd call and the
83776th call should be active at the same time. Think of it in terms of
hours, if both of these were active and your call volume were 83,000
calls per day, then that 83rd call would have been up and connected for
>24 hours. That is extremely unlikely. If it is true, you're going to
have a nice phone bill ;)
/Wes
_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
</body>
</html>