<!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">
if using the headless agent then all necessary ports and network
actions should be open.<br>
<br>
if using managed csa, it is easy to miss some things that will
interfere with cm functionality.<br>
<br>
if headless csa the csa security log is a pretty good tattle tale for
any blocked actions.<br>
<br>
you could also use this:<br>
<a class="moz-txt-link-freetext" href="http://supportwiki.cisco.com/ViewWiki/index.php/Dropped_Call_Troubleshooting_in_CUCM">http://supportwiki.cisco.com/ViewWiki/index.php/Dropped_Call_Troubleshooting_in_CUCM</a><br>
to identify the call disconnect codes from the originating cluster.<br>
<br>
any cause code in the 40's would mean the h245 could not setup, most
likely because it was blocked.<br>
<br>
/wes<br>
<br>
On Wednesday, March 18, 2009 7:48:54 PM, Jim Reed
<a class="moz-txt-link-rfc2396E" href="mailto:jreed@swiftnews.com"><jreed@swiftnews.com></a> wrote:<br>
<blockquote cite="mid:C5E6E486.1ABF6%25jreed@swiftnews.com" type="cite">
<title>Re: Intercluster Dialing Issue</title>
<font size="4"><font face="Verdana, Helvetica, Arial"><span
style="font-size: 14px;"><b>Okay, gang, just looking for some opinion
here. Thinking this might be a routing issue, I tried doing a
traceroute between the Call Managers in the two clusters. When the
traceroute didn’t complete successfully, I remembered that Cisco
Security Agent was running on the far end cluster. As soon as I turned
it off, the traceroute completed — as I suspected it would. However,
interestingly enough, as soon as I turned it off, the calls between the
two clusters are now ringing through immediately and remote dial tone
is also working again. What is there in the CSA setup that would
hamper intercluster dialing? Just picking your collective brains to
see if anyone has run into this before or if any of you have any ideas
on why this might happen.<br>
<br>
Thanks in advance...<br>
</b></span></font></font><font face="Verdana, Helvetica, Arial"><font
size="2"><span style="font-size: 10px;">-- <br>
Jim Reed<br>
Swift Communications, Inc.<br>
970-683-5646 (Direct)<br>
775-772-7666 (Cell)<br>
<br>
</span></font><span style="font-size: 12px;"><br>
<br>
On 3/17/09 10:54 AM, "Jim Reed" <a class="moz-txt-link-rfc2396E" href="mailto:jreed@swiftnews.com"><jreed@swiftnews.com></a> wrote:<br>
</span></font>
<blockquote><font face="Verdana, Helvetica, Arial"><font size="4"><span
style="font-size: 14px;"><b><br>
We have two (2) Call Manager clusters connected via an MPLS WAN. When
I try to directly dial a five (5) digit extension on cluster B from
cluster A, the first time I dial the call can take up to forty-five
(45) seconds to connect. If I dial an extension, immediately hang up
and then immediately dial that same extension again, the call goes
right through. My first thought was that I had a conflicting dial
pattern that was waiting for more digits before timing out and
completing the call but that does not appear to be the case. Just
wondering if anyone else has run into a similar issue and what they may
have found the issue to be. This worked without issue for quite some
time so its likely some change that we made when adding another
location has caused the issue but thus far I have not been able to
track it down.<br>
<br>
Thank You...<br>
</b></span></font></font></blockquote>
<font face="Verdana, Helvetica, Arial"><font size="2"><span
style="font-size: 10px;"><br>
<br>
</span></font></font>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
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>
<br>
</body>
</html>