<!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">
H.245 interruptions are usually caused by one of several things:<br>
<br>
1. a race condition inside ccm.exe processing of the required signals<br>
2. firewalls attempting to inspect the h.245 session or tearing down
perceived inactive sessions. This defect:<br>
CSCsq17141 CUCM - Allow TCP KeepAlives for H.323 should enable H.245
TCP KAs also <br>
helps counter that issue from inside CM. make sure you have the fix and
then enable the service parameter. Aside from that if there is any
firewall involved it needs to not teardown idle sessions at least for
h.245. If firewall is choking on parsing or inspection of h.245 that
is a separate issue to be addressed on the firewall itself.<br>
3. network congestion or dropped packets. Do you notice any delay in
call setup or only during transfers? CM traces will help to isolate
exactly what is happening to the h.245 session. Information from this
defect should make it amply clear:<br>
CSCsm26355 need clear messages for h245 tcp session failure <br>
<br>
View the bugs in Cisco BugToolkit to get complete details.<br>
<br>
/Wes<br>
<br>
On Thursday, November 19, 2009 10:29:35 AM, Jim Reed
<a class="moz-txt-link-rfc2396E" href="mailto:jreed@swiftnews.com"><jreed@swiftnews.com></a> wrote:<br>
<blockquote cite="mid:C72AB26F.2E261%25jreed@swiftnews.com" type="cite">
<title>Re: [cisco-voip] InterCluster Disconnects</title>
<font size="4"><font face="Verdana, Helvetica, Arial"><span
style="font-size: 14px;"><b>Wes,<br>
Thanks for that little tidbit. Which, of course, leads to the logical
question — Any ideas on what is causing that to be interrupted?
Latency across the MPLS? A misconfiguration in Call Manager or IPCC?
Etc. Etc.<br>
<br>
Thank You...<br>
</b></span></font></font><font face="Verdana, Helvetica, Arial"><b><font
size="2"><span style="font-size: 10px;">-- <br>
Jim Reed<br>
Technology Wrangler<br>
Swift Communications, Inc.<br>
970-683-5646 (Direct)<br>
775-772-7666 (Cell)<br>
<br>
</span></font><font size="1"><span style="font-size: 9px;"><i>“Not
only is it not right.<br>
It’s not even wrong.”<br>
</i> The Pauli Proverb<br>
Wolfgang Pauli<br>
</span></font></b><span style="font-size: 12px;"><br>
<br>
On 11/19/09 7:55 AM, "Wes Sisk" <a class="moz-txt-link-rfc2396E" href="mailto:wsisk@cisco.com"><wsisk@cisco.com></a> wrote:<br>
<br>
</span></font>
<blockquote><font face="Verdana, Helvetica, Arial"><span
style="font-size: 12px;">hold/unhold triggers h.245 communication over
the ICT to redirect the media. If this is failing in your script it
will likely fail for users performing hold, park, conference, and
transfer as well. You may have worked around it in the script but the
underlying problem is still present. Most likely h.245 TCP
communication between the clusters is being interrupted.<br>
<br>
/Wes<br>
<br>
On Wednesday, November 18, 2009 7:17:17 PM, Jim Reed <<font
color="#0000ff"><u><a class="moz-txt-link-abbreviated" href="mailto:jreed@swiftnews.com">jreed@swiftnews.com</a></u></font>> <<font
color="#0000ff"><u><a moz-do-not-send="true"
href="mailto:jreed@swiftnews.com">mailto:jreed@swiftnews.com</a></u></font>>
wrote:<br>
</span></font>
<blockquote><font face="Verdana, Helvetica, Arial"><span
style="font-size: 12px;"> Re: InterCluster Disconnects </span><font
size="4"><span style="font-size: 14px;"><b>Just as an FYI in case this
issue should affect someone else or they have seen it previously, in an
exchange between Anthony Holloway and myself on this issue, he pointed
me towards turning on the ENG trace in IPCC. This lead to the
suspicion that it was the Call Hold or Call Unhold steps that were
possibly causing the issue for the calls across the intercluster trunk.
Instead of placing the calls in queue on hold, running a thirty (30)
second delay during which hold music played, then taking the calls off
hold and playing a prompt that allowed the caller to continue to hold
or press 1 to leave a message, I replaced the Call Hold step with
thirty (30) seconds of music via a prompt set to be interruptible and
removed the Call Unhold step completely. Unfortunately, it was near
the end of the day and I could not run as many tests as I would have
liked. After hours calls go directly to voicemail if the caller
doesn’t know the extension of the person they’re trying to contact. I
will test in earnest tomorrow morning and if I can get forty (40) to
fifty (50) consecutive calls without a failure, I think it will
definitely point a finger at something to do with placing a call on
hold that goes across an intercluster trunk. But, playing the devils
advocate, I won’t say that’s the problem right now until I get those
forty (40) or fifty (50) consecutive, successful calls. If anyone has
any thoughts along this line, would greatly appreciate hearing them.<br>
<br>
Thank You...<br>
</b></span></font><b><font size="2"><span style="font-size: 10px;">-- <br>
Jim Reed<br>
Technology Wrangler<br>
Swift Communications, Inc.<br>
970-683-5646 (Direct)<br>
775-772-7666 (Cell)<br>
<br>
</span></font><font size="1"><span style="font-size: 9px;"><i>“Not
only is it not right.<br>
It’s not even wrong.”<br>
</i> The Pauli Proverb<br>
Wolfgang Pauli<br>
<br>
</span></font></b><span style="font-size: 12px;"> <br>
On 11/17/09 6:10 PM, "Alex Hannah" <<font color="#0000ff"><u><a class="moz-txt-link-abbreviated" href="mailto:alex.hannah@gmail.com">alex.hannah@gmail.com</a></u></font>>
<<font color="#0000ff"><u><a moz-do-not-send="true"
href="mailto:alex.hannah@gmail.com">mailto:alex.hannah@gmail.com</a></u></font>>
wrote:<br>
<br>
<br>
</span></font>
<blockquote><font face="Verdana, Helvetica, Arial"><span
style="font-size: 12px;">Gather and post the MIVRlogs located at
C:\prog files\wfavvid\logs\MIVR on the cluster you are having problems
with. MAKE certain you have a time date and pref an ext that called so
myself or others can parse the logs. Out of curiosity where are your
transcoders located? What codec goes across the trunk?<br>
<br>
Sent from my iPhone<br>
<br>
On Nov 17, 2009, at 7:19 PM, Jim Reed <<font color="#0000ff"><u><a class="moz-txt-link-abbreviated" href="mailto:jreed@swiftnews.com">jreed@swiftnews.com</a></u></font>>
wrote:<br>
<br>
<br>
</span></font>
<blockquote><font face="Verdana, Helvetica, Arial"><font
size="4"><span style="font-size: 14px;"><b>I will do my best to
explain this as clearly as possible. Please advise if additional
information is needed.<br>
<br>
We have two (2) separate VoIP systems that communicate via intercluster
trunks across an MPLS WAN. For purposes of this discussion, we'll call
them System GPC and System CMNM. System GPC is 4.5-Meg MPLS and system
CMNM is 9-Meg MPLS.<br>
<br>
When the contact center number is dialed on System GPC, the calls are
forwarded to an extension (aka route point) on System CMNM that puts
the caller into the contact center script.<br>
<br>
The caller hears the initial recording with no problem. That recording
instructs the caller to press 2 for option A; press 3 for option B;
press 4 for option C; etc. etc.<br>
<br>
On somewhat frequent occasions, when the caller makes their selection,
the call is disconnected.<br>
<br>
This does not happen on calls that are placed to numbers associated
directly with System CMNM.<br>
<br>
System CMNM has a toll free number associated with the contact center.
When I forward the calls from System GPC to that toll free number
instead of the route point on System CMNM, there are no disconnects.<br>
<br>
I have reset the intercluster trunks between the two systems. When I
look at the call statistics in the router(s), they show the code for
normal call clearing.<br>
<br>
Anyone got any thoughts on why the selection of the CSQ option in the
script is causing that disconnect?<br>
<br>
I have looked at the T1 controller stats and the serial interface stats
associated with that PRI controller and there are no errors. System
GPC has no calling issues locally for calls that come in on those same
PRI channels.<br>
<br>
Thank You...<br>
</b></span></font><b><font size="2"><span style="font-size: 10px;">-- <br>
Jim Reed<br>
Technology Wrangler<br>
Swift Communications, Inc.<br>
970-683-5646 (Direct)<br>
775-772-7666 (Cell)<br>
<br>
</span></font><font size="1"><span style="font-size: 9px;"><i>“Not
only is it not right.<br>
It’s not even wrong.”<br>
</i> The Pauli Proverb<br>
Wolfgang Pauli<br>
<br>
</span></font></b></font></blockquote>
<font face="Verdana, Helvetica, Arial"><span
style="font-size: 12px;"> <br>
<br>
</span></font></blockquote>
<font face="Verdana, Helvetica, Arial"><span
style="font-size: 12px;"> <br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<font color="#0000ff"><u><a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</u></font> <br>
</span></font></blockquote>
<font face="Verdana, Helvetica, Arial"><span
style="font-size: 12px;"><br>
<br>
</span></font></blockquote>
<font face="Verdana, Helvetica, Arial"><span style="font-size: 12px;"><br>
<br>
</span></font>
</blockquote>
<br>
</body>
</html>