<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Erick,<br>
<br>
Device name like XXX-XXXX should not be an issue, but any chance you
can try a simpler name just to confirm?<br>
<br>
Best bet is to capture CCM, CCM SDL, CTI, CTI SDL, TCDSrv over a period
of several hours. We will need these from all nodes in the cluster
since we are not sure why duplicate device opens are being attempted.
This will show the functional device and give some pointer to the
applicaiton controlling it, then we can find when the new deviceopens
start coming in. Open a TAC case and give us as many hours of traces
leading up to the event. If you're on 4.1 may I recommend the Trace
Collection Tool under application->install plugins? it will copy
and zip all traces from all nodes for you. if the zip won't attach to
case due to size, drop the traces on ftp-sj.cisco.com/incoming and put
the filename in the case. Pls send me the case number. <br>
<br>
/Wes<br>
<br>
Erick Bergquist wrote:
<blockquote
cite="mid20051012025256.10157.qmail@web34304.mail.mud.yahoo.com"
type="cite">
<pre wrap="">Thanks.
These are happening for a few out of the blue pretty
much, they recently upgraded from 3.3 to 4.1 and now
were seeing this occassionally. No service stops or
starts, etc at least from event logs. No reported
problems.
Looking at a few other event log entries, some of them
have the already open reason code, and some are for
invalid device name reason code.
All their AC pilot points have names like ###-#### (7
digit phone number for the pilot). Is this maybe
throwing it off now and then?
I can unicast the cti trace. It shows the
client/server heartbeat then these having errors out
of blue but can't figure out why other then the device
name not being liked occassionally.
--- Wes Sisk <a class="moz-txt-link-rfc2396E" href="mailto:wsisk@cisco.com"><wsisk@cisco.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I believe your error is
CTIERR_DEVICE_ALREADY_OPENED= 0x8CCC00A0;
We used to see this error alot with CER. What this
means is another CTI
Application has already performed a
'DeviceOpenRequest' for this
specific device.
In the AttendantConsole case, only 1 tcdsrv process
should be 'active'
in the cluster at any point in time. By 'active' i
mean actively
controlling the AC Pilot Points. When TCDSrv starts
up the tcdsrv
processes communicate with each other to determine
which be active and
controlling the Pilot Points. The other process
goes into a standby
mode incase the primary process fails.
Given that, I would check: are ther any firewalls or
ACL's between nodes
that would prevent tcdsrv processes from
communicating with each other?
if you stop tcdsrv on all nodes in the cluster
except 1, then restart
that tcd process, do the pilot points work? If they
still are not
working, then it's possible some other CTI
application tried to open the
device (what other global directory users have the
pilot point
associated to them?)
If all of this fails, stop CTIManager and TCD on all
nodes, then start
them back and collect traces from startup time. You
should be able to
find the multiple deviceopen requests for the same
device and see where
they initiated from.
It is possible that the internal ccm.exe process
believes this device is
open when it really isn't, but I have not seen this
case in quite some
time. Usually this results in
CTIERR_DEVICE_SHUTTING_DOWN =
0x8CCC009A; because an app was controlling the
device, but stopped, but
CM was not able to shutdown the device for some
reason.
HTH.
/Wes
</pre>
</blockquote>
<pre wrap=""><!---->
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
<a class="moz-txt-link-freetext" href="http://music.yahoo.com/unlimited/">http://music.yahoo.com/unlimited/</a>
</pre>
</blockquote>
</body>
</html>