<!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">
Correct. The most memory and CPU cycles are allocated during call
setup.&nbsp; 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.&nbsp; That overhead can become appreciable if
you, for example, hold and resume a call every 2 seconds.&nbsp; 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.&nbsp; Someone called a destination that streamed back dtmf and
added it into a conference of ~40 participants.&nbsp; Receiving dtmf on 1
leg of the conference caused ccm to replicate that dtmf to the 40
participants.&nbsp;&nbsp; Consider an automated system can pulse a digit in 200
msec.&nbsp; 200 msec * 10 digits = 2,000 msec or 2 seconds.&nbsp; Multiply that
by the 40 conference participants and cm had to propagate 400 DTMF in 2
seconds.&nbsp; 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">lelio@uoguelph.ca</a> wrote:<br>
<blockquote cite="mid:D10BD862-F91B-4F1B-A8D5-F67E5B3DCC11@uoguelph.ca"
 type="cite">
  <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,&nbsp;<span class="Apple-style-span" style="">Senior Analyst</span>
  <div><span class="Apple-style-span" style="">Computing &amp;
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 ;)&nbsp;</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 &lt;<a moz-do-not-send="true"
 href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>&gt; wrote:<br>
  <br>
  </div>
  <blockquote type="cite">
    <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.&nbsp; If you're getting route list exhausted in means CM
is trying to hunt through the routelist.&nbsp; Usually this only happens if
h225 setup fails for ICT.&nbsp; detailed SDL traces and careful eye will
spot the reason.&nbsp; 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 moz-do-not-send="true" class="moz-txt-link-rfc2396E"
 href="mailto:dwolgas1@rochester.rr.com">&lt;</a><a
 moz-do-not-send="true" href="mailto:dwolgas1@rochester.rr.com">dwolgas1@rochester.rr.com</a>&gt;
wrote:<br>
    <blockquote
 cite="mid:e4491a9c0903041206w3f3f4624ybe151fdf57bdad47@mail.gmail.com"
 type="cite">
      <div>We're now running 2 clusters with non-gatekeeper controlled
ICTs
between them.&nbsp; All of our PSTN gateways are currently homed to 1
cluster.&nbsp; We have 2 subscribers on each cluster, and the trunks point
to each sub on the other cluster.</div>
      <div>&nbsp;</div>
      <div>During traffic peaks, we get periodic RouteListExhausted
alerts
on the ICTs.&nbsp; I was thinking that a non-gatekeeper ICT (without any
location restrictions or CAC of any kind) would be essentially
unlimited.</div>
      <div>&nbsp;</div>
      <div>Any idea why this would happen?&nbsp; What should I be looking at
to
figure this out?<br clear="all">
      <br>
-- <br>
Dave Wolgast<br>
Livonia, NY<br>
      </div>
      <pre wrap=""><hr size="4" width="90%">
_______________________________________________
cisco-voip mailing list
<a moz-do-not-send="true" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a moz-do-not-send="true"
 href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
  </pre>
    </blockquote>
    <br>
    </div>
  </blockquote>
  <blockquote type="cite">
    <div><span>_______________________________________________</span><br>
    <span>cisco-voip mailing list</span><br>
    <span><a moz-do-not-send="true"
 href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a></span><br>
    <span><a moz-do-not-send="true"
 href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a></span><br>
    </div>
  </blockquote>
</blockquote>
<br>
</body>
</html>