[cisco-voip] CTI Manager Reason Codes

[Erick Bergquist]

Yea, turned all those on earlier and awaiting next
occurrance. But there was defiantly some CTI errors in
event log and cti trace that was there from previous
with reason codes about invalid device name. 

Will open TAC if needed next time a error occurs. 

Any way (or SQL query) to see if the pilot points are
associated to more then one user without looking at
each user?

--- Wes Sisk <wsisk at cisco.com> wrote:


---------------------------------
    Erick,

Device name like XXX-XXXX should not be an issue, but
any chance youcan try a simpler name just to confirm?

Best bet is to capture CCM, CCM SDL, CTI, CTI SDL,
TCDSrv over a periodof several hours.  We will need
these from all nodes in the clustersince we are not
sure why duplicate device opens are being attempted.
This will show the functional device and give some
pointer to theapplicaiton controlling it, then we can
find when the new deviceopensstart coming in.  Open a
TAC case and give us as many hours of tracesleading up
to the event.  If you're on 4.1 may I recommend the
TraceCollection Tool under application->install
plugins?  it will copyand zip all traces from all
nodes for you.  if the zip won't attach tocase due to
size, drop the traces on ftp-sj.cisco.com/incoming and
putthe filename in the case.  Pls send me the case
number.  

/Wes

Erick Bergquist wrote:  
Thanks.These are happening for a few out of the blue
prettymuch, they recently upgraded from 3.3 to 4.1 and
nowwere seeing this occassionally. No service stops
orstarts, etc at least from event logs. No
reportedproblems.Looking at a few other event log
entries, some of themhave the already open reason
code, and some are forinvalid device name reason
code.All their AC pilot points have names like
###-#### (7digit phone number for the pilot). Is this
maybethrowing it off now and then?I can unicast the
cti trace. It shows theclient/server heartbeat then
these having errors outof blue but can't figure out
why other then the devicename not being liked
occassionally. --- Wes Sisk <wsisk at cisco.com> wrote:  
      
I believe your error isCTIERR_DEVICE_ALREADY_OPENED= 
0x8CCC00A0;We used to see this error alot with CER. 
What thismeans is another CTI Application has already
performed a'DeviceOpenRequest' for this specific
device.In the AttendantConsole case, only 1 tcdsrv
processshould be 'active' in the cluster at any point
in time.  By 'active' imean actively controlling the
AC Pilot Points.  When TCDSrv startsup the tcdsrv
processes communicate with each other to
determinewhich be active and controlling the Pilot
Points.  The other processgoes into a standby mode
incase the primary process fails.Given that, I would
check: are ther any firewalls orACL's between nodes
that would prevent tcdsrv processes fromcommunicating
with each other?if you stop tcdsrv on all nodes in the
clusterexcept 1, then restart that tcd process, do the
pilot points work?  If theystill are not working, then
it's possible some other CTIapplication tried to open
the device (what other global directory users have
thepilot point associated to them?)If all of this
fails, stop CTIManager and TCD on allnodes, then start
them back and collect traces from startup time. 
Youshould be able to find the multiple deviceopen
requests for the samedevice and see where they
initiated from.It is possible that the internal
ccm.exe processbelieves this device is open when it
really isn't, but I have not seen thiscase in quite
some time.  Usually this results
inCTIERR_DEVICE_SHUTTING_DOWN  =  0x8CCC009A; because
an app was controlling thedevice, but stopped, but CM
was not able to shutdown the device for
somereason.HTH./Wes    
    
		__________________________________ Yahoo! Music
Unlimited Access over 1 million songs. Try it
free.http://music.yahoo.com/unlimited/  




		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/