<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Verdana; font-size: 10pt; color: #000000'>Thanks Wes!<br><br>----- Original Message -----<br>From: "Wes Sisk" <wsisk@cisco.com><br>To: lelio@uoguelph.ca<br>Cc: "Dave Wolgast" <dwolgas1@rochester.rr.com>, "Cisco VOIP Newsletter - puck.nether.net" <cisco-voip@puck.nether.net><br>Sent: Thursday, March 5, 2009 9:02:21 AM GMT -05:00 US/Canada Eastern<br>Subject: Re: [cisco-voip] ICT Capacity?<br><br>
<link href="/zimbra/css/msgview.css?v=081117021119" rel="stylesheet">
Correct. The most memory and CPU cycles are allocated during call
setup. There is incremental processing activity after that for
h225/h245 TCP keepalives, media redirection such as hold and resume,
and h245 events such as DTMF. That overhead can become appreciable if
you, for example, hold and resume a call every 2 seconds. Otherwise
the resources for those activities are negligible compared to the
resources for initial call setup including call routing, tcp
establishment for h225, and tcp establishment for h225.<br>
<br>
That said, you can get into some fun scenarios with h245 events:
CSCec11536. Someone called a destination that streamed back dtmf and
added it into a conference of ~40 participants. Receiving dtmf on 1
leg of the conference caused ccm to replicate that dtmf to the 40
participants. Consider an automated system can pulse a digit in 200
msec. 200 msec * 10 digits = 2,000 msec or 2 seconds. Multiply that
by the 40 conference participants and cm had to propagate 400 DTMF in 2
seconds. The CPU definitely spiked on ccm and the usual negative
implications ensued.<br>
<br>
Adventures in voice.<br>
<br>
<br>
/Wes<br>
<br>
On Wednesday, March 04, 2009 11:02:24 PM, <a class="moz-txt-link-abbreviated" href="mailto:lelio@uoguelph.ca" target="_blank">lelio@uoguelph.ca</a> wrote:<br>
<blockquote cite="mid:D10BD862-F91B-4F1B-A8D5-F67E5B3DCC11@uoguelph.ca">
<div>Wes, by 4 calls per second, do you mean call setup? And once
it's set up it doesn't affect CM any more?</div>
<div><br>
Lelio Fulgenzi, <span class="Apple-style-span" style="">Senior Analyst</span>
<div><span class="Apple-style-span" style="">Computing &
Communications</span></div>
<div><span class="Apple-style-span" style="">University of Guelph</span></div>
<div><span class="Apple-style-span" style="">519-824-4120 x56354</span></div>
<div><span class="Apple-style-span" style=""><br>
</span></div>
<div><span class="Apple-style-span" style="">...sent from my iPod -
please pardon my fat fingers ;) </span></div>
<div><span class="Apple-style-span" style=""><br>
</span></div>
<div><span class="Apple-style-span" style="">[XKJ2000]</span></div>
</div>
<div><br>
On Mar 4, 2009, at 10:55 PM, Wes Sisk <<a href="mailto:wsisk@cisco.com" target="_blank">wsisk@cisco.com</a>> wrote:<br>
<br>
</div>
<blockquote>
<div>ICT capacity should be unlimited with a couple exceptions:<br>
1. call rate - CM can only accept ~4call per second for h.323<br>
2. locations bandwidth configuration - allows you to limit total calls
if you desire<br>
<br>
after that you can route essentially unlimited calls over ICT until you
literally crush CM. If you're getting route list exhausted in means CM
is trying to hunt through the routelist. Usually this only happens if
h225 setup fails for ICT. detailed SDL traces and careful eye will
spot the reason. Otherwise a packet capture looking at traffic on
TCP:1720 will provide pretty directly clues.<br>
<br>
every call establishes a new TCP session to the remote cluster on
tcp:1720.<br>
<br>
/wes<br>
<br>
On Wednesday, March 04, 2009 3:06:11 PM, Dave Wolgast
<a class="moz-txt-link-rfc2396E" href="mailto:dwolgas1@rochester.rr.com" target="_blank"><</a><a href="mailto:dwolgas1@rochester.rr.com" target="_blank">dwolgas1@rochester.rr.com</a>>
wrote:<br>
<blockquote cite="mid:e4491a9c0903041206w3f3f4624ybe151fdf57bdad47@mail.gmail.com">
<div>We're now running 2 clusters with non-gatekeeper controlled
ICTs
between them. All of our PSTN gateways are currently homed to 1
cluster. We have 2 subscribers on each cluster, and the trunks point
to each sub on the other cluster.</div>
<div> </div>
<div>During traffic peaks, we get periodic RouteListExhausted
alerts
on the ICTs. I was thinking that a non-gatekeeper ICT (without any
location restrictions or CAC of any kind) would be essentially
unlimited.</div>
<div> </div>
<div>Any idea why this would happen? What should I be looking at
to
figure this out?<br clear="all">
<br>
-- <br>
Dave Wolgast<br>
Livonia, NY<br>
</div>
<pre><hr size="4" width="90%">
_______________________________________________
cisco-voip mailing list
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
<blockquote>
<div><span>_______________________________________________</span><br>
<span>cisco-voip mailing list</span><br>
<span><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a></span><br>
<span><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br>
</div>
</blockquote>
</blockquote>
<br>
</div></body></html>