[cisco-voip] Arc Enterprise v504.485 with CUCM702
Bennie Grant
Bennie.Grant at mettoni.com
Sun May 17 10:26:41 EDT 2009
Hey Frog
Couple of things for you:
The CTI Server is not essential. This is a new module that allows the
BLF to scale clusterwide - using the TAPI Superprovider feature on the
CUCM. If you don't want/need this, then you don't need the CTI Server.
However, the CTI Server does also act as the Server module for the Arc
Click-to-Dial product, so if you want that you'll need this module too
To do with the Arc Server shutting down automatically - it is worth
understanding "why" or "when" this will happen. The Arc Server will only
automatically shut itself down if the CTI communication with the CUCM is
not working:
1) Either it cannot see ANY CTI Devices
2) It can see the devices, but cannot control the Host PBX Gateway
(CTI Ports) - because they are "out of service", Cisco TAPI Wave Driver
not installed correctly, etc etc
Specifically, if the Arc Server cannot see/control the Host PBX Gateway
devices FOR ANY REASON, then it will automatically shut down the server
module and try and restart itself. This is because these devices are
used for queuing the calls - if these devices are not available, then
the Arc Server cannot work. Therefore it shuts itself down and tries to
reinitialize the CTI Ports (on earlier versions of CUCM, there was a bug
that this often fixed)
So, associating two devices with the same DN;s should have no impact on
this whatsoever - I've seen it done literally hundreds of times with no
impact.
However, the CTI Port devices must remain with unique DNs - so if the
other devices has the same DN as the CTI ports, then this will cause
problems with the Cisco CTI Layer, and therefore Arc will not be able to
control the CTI Ports, and therefore the server will not start...
Looking at the trace below, you can see that the CTI layer (Cisco CTI
Manager Service) is stating that the devices are "out_of_service" (OOS)
- which means that we cannot control them. The question is, why are
these devices going out of service when you associate the extra
device/line? This is something I haven't seen before, and something that
TAC/DE would need to get involved in if it is proven that this is the
case. Because the devices are out of service, Arc has no way to control
anything on the CUCM and that's why it isn't working...
All that being said though, why do you have the same MAC address (this
888888888888 number) - I can understand shared DN's/lines - but of
course this is impossible in reality. It may be possible that you've
stumbled across a CTI bug where multiple duplicate MAC addresses cause
the Cisco TSP to make devices OOS or something similar.
What are these devices you're associating, are they regular phones or
something else? Could you try changing the MAC address of one of these
devices by one digit, and see if this then works?
On a separate note, which version of Arc Enterprise do you have - there
is no version 504 out there? Our latest is v5.0.2...
Thanks
Bennie Grant
VP - Operations
Arc Solutions (International) Inc
Part of the Mettoni group | www.mettoni.com <http://www.mettoni.com/>
From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of FrogOnDSCP46EF
Sent: Sunday, May 17, 2009 5:12 AM
To: cisco-voip voyp list
Subject: [cisco-voip] Arc Enterprise v504.485 with CUCM702
Hi Guys,
I was playing with the Arc 504 enterprise "arc connect CT server"
integration with CCM702.10000,18
When there is a double line from same MAC address/device, ARC CT server
is going banana. It is keep shutting down the arc ct server and
restarting it.
Once I de-associated the 2nd line from ARC TAPI user in CCM, of same
device then its okay. it doesn't shut/restart.
Q1: Is there any fix for this bug for Arc console? End user can easily
do this kind of mistake (associate both phone lines) and can loose the
whole console.
Q2: is CTI server from ARC is a must to install? I found its working
without Arc CTI server. Calls are routed.
Is ARC CTI server in Enterprise v5 for pulling users info from ccm
without a need of associatng each and every ccm phone manually? It pulls
using application user all devices from ccm?
or is there any other purpose?
Here are the ccm and arc server logs:
CCM CTI SDL traces
============================================================
000016201| 2009/05/17 08:56:26.304| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | Send CTI Server Heartbeat
000016202| 2009/05/17 08:56:26.573| 001| SdlSig |
CtiClientHeartbeatTimer | ready |
CTIHandler(1,200,16,15) | SdlTimerService(1,200,3,1) |
(1,200,15,1).1450-(*:*) | [R:HP - HP: 0, NP: 0, LP: 0,
VLP: 0, LZP: 0 DBP: 0]
000016203| 2009/05/17 08:56:56.130| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | [CTI-APP]
[CTIHandler::processIncomingMessage] CTI Client Heartbeat (
application name=CiscoTSP001-142.2.64.51)
000016204| 2009/05/17 08:56:56.130| 001| SdlSig | CtiHeartbeat
| ready | CTIHandler(1,200,16,15) |
CTIHandler(1,200,16,15) | (1,200,15,1).1510-(*:*)
| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]
000016205| 2009/05/17 08:56:56.320| 001| SdlSig |
CtiServerHeartbeatTimer | ready |
CTIHandler(1,200,16,15) | SdlTimerService(1,200,3,1) |
(1,200,15,1).1450-(*:*) | [R:HP - HP: 0, NP: 0, LP: 0,
VLP: 0, LZP: 0 DBP: 0]
000016206| 2009/05/17 08:56:56.320| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | [CTI-APP]
[CTIHandler::OutputCtiMessage ] CTI Server Heartbeat (
application name=CiscoTSP001-142.2.64.51)
000016207| 2009/05/17 08:56:56.320| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | Send CTI Server Heartbeat
000016208| 2009/05/17 08:56:56.578| 001| SdlSig |
CtiClientHeartbeatTimer | ready |
CTIHandler(1,200,16,15) | SdlTimerService(1,200,3,1) |
(1,200,15,1).1450-(*:*) | [R:HP - HP: 0, NP: 0, LP: 0,
VLP: 0, LZP: 0 DBP: 0]
000016209| 2009/05/17 08:57:26.153| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | [CTI-APP]
[CTIHandler::processIncomingMessage] CTI Client Heartbeat (
application name=CiscoTSP001-142.2.64.51)
000016210| 2009/05/17 08:57:26.153| 001| SdlSig | CtiHeartbeat
| ready | CTIHandler(1,200,16,15) |
CTIHandler(1,200,16,15) | (1,200,15,1).1511-(*:*)
| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]
000016211| 2009/05/17 08:57:26.338| 001| SdlSig |
CtiServerHeartbeatTimer | ready |
CTIHandler(1,200,16,15) | SdlTimerService(1,200,3,1) |
(1,200,15,1).1450-(*:*) | [R:HP - HP: 0, NP: 0, LP: 0,
VLP: 0, LZP: 0 DBP: 0]
000016212| 2009/05/17 08:57:26.338| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | [CTI-APP]
[CTIHandler::OutputCtiMessage ] CTI Server Heartbeat (
application name=CiscoTSP001-142.2.64.51)
000016213| 2009/05/17 08:57:26.338| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | Send CTI Server Heartbeat
000016214| 2009/05/17 08:57:26.592| 001| SdlSig |
CtiClientHeartbeatTimer | ready |
CTIHandler(1,200,16,15) | SdlTimerService(1,200,3,1) |
(1,200,15,1).1450-(*:*) | [R:HP - HP: 0, NP: 0, LP: 0,
VLP: 0, LZP: 0 DBP: 0]
000016215| 2009/05/17 08:57:56.132| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | [CTI-APP]
[CTIHandler::processIncomingMessage] CTI Client Heartbeat (
application name=CiscoTSP001-142.2.64.51)
000016216| 2009/05/17 08:57:56.132| 001| SdlSig | CtiHeartbeat
| ready | CTIHandler(1,200,16,15) |
CTIHandler(1,200,16,15) | (1,200,15,1).1512-(*:*)
| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]
000016217| 2009/05/17 08:57:56.349| 001| SdlSig |
CtiServerHeartbeatTimer | ready |
CTIHandler(1,200,16,15) | SdlTimerService(1,200,3,1) |
(1,200,15,1).1450-(*:*) | [R:HP - HP: 0, NP: 0, LP: 0,
VLP: 0, LZP: 0 DBP: 0]
000016218| 2009/05/17 08:57:56.350| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | [CTI-APP]
[CTIHandler::OutputCtiMessage ] CTI Server Heartbeat (
application name=CiscoTSP001-142.2.64.51)
000016219| 2009/05/17 08:57:56.350| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | Send CTI Server Heartbeat
000016220| 2009/05/17 08:57:56.598| 001| SdlSig |
CtiClientHeartbeatTimer | ready |
CTIHandler(1,200,16,15) | SdlTimerService(1,200,3,1) |
(1,200,15,1).1450-(*:*) | [R:HP - HP: 0, NP: 0, LP: 0,
VLP: 0, LZP: 0 DBP: 0]
000016221| 2009/05/17 08:58:26.133| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | [CTI-APP]
[CTIHandler::processIncomingMessage] CTI Client Heartbeat (
application name=CiscoTSP001-142.2.64.51)
000016222| 2009/05/17 08:58:26.133| 001| SdlSig | CtiHeartbeat
| ready | CTIHandler(1,200,16,15) |
CTIHandler(1,200,16,15) | (1,200,15,1).1513-(*:*)
| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]
000016223| 2009/05/17 08:58:26.358| 001| SdlSig |
CtiServerHeartbeatTimer | ready |
CTIHandler(1,200,16,15) | SdlTimerService(1,200,3,1) |
(1,200,15,1).1450-(*:*) | [R:HP - HP: 0, NP: 0, LP: 0,
VLP: 0, LZP: 0 DBP: 0]
000016224| 2009/05/17 08:58:26.358| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | [CTI-APP]
[CTIHandler::OutputCtiMessage ] CTI Server Heartbeat (
application name=CiscoTSP001-142.2.64.51)
000016225| 2009/05/17 08:58:26.358| 001| AppInfo |
| | CTIHandler(1,200,16,15) |
| | Send CTI Server Heartbeat
000016226| 2009/05/17 08:58:26.614|
ARC logs:
==================================================================
17/5/2009 18:45:53.187|R|XML>Reply, ET=304, TR=, OS=2002, RT=, RE=, RD=
17/5/2009 18:45:53.187|R|XML>DeviceStatus, Received, "2002",
Capability=N, Service=N, MAC=SEP888888888888
17/5/2009 18:45:53.187|M|"DeviceFeatureNE","RouterEvent","2002""
17/5/2009 18:45:53.187|R|XML>Reply, ET=304, TR=, OS=2002, RT=, RE=, RD=
17/5/2009 18:45:53.187|R|XML>DeviceStatus, Received, "2002",
Capability=N, Service=N, MAC=SEP888888888888
17/5/2009 18:45:53.187|M|"DeviceFeatureNE","RouterEvent","2002""
17/5/2009 18:45:53.187|R|XML>Reply, ET=304, TR=, OS=3002, RT=, RE=, RD=
17/5/2009 18:45:53.187|R|XML>DeviceStatus, Received, "3002",
Capability=Y, Service=N, MAC=SEP888888888888
17/5/2009 18:45:53.187|M|"DeviceFeatureNE","RouterEvent","3002""
17/5/2009 18:45:53.187|R|XML>Reply, ET=304, TR=, OS=2002, RT=, RE=, RD=
17/5/2009 18:45:53.187|R|XML>DeviceStatus, Received, "2002",
Capability=N, Service=N, MAC=SEP888888888888
17/5/2009 18:45:53.187|M|"DeviceFeatureNE","RouterEvent","2002""
17/5/2009 18:45:53.187|R|XML>Reply, ET=304, TR=, OS=3002, RT=, RE=, RD=
17/5/2009 18:45:53.187|R|XML>DeviceStatus, Received, "3002",
Capability=Y, Service=N, MAC=SEP888888888888
17/5/2009 18:45:53.187|M|"DeviceFeatureNE","RouterEvent","3002""
17/5/2009 18:45:53.187|R|"TimerEvent","Event Relay [41]"
17/5/2009 18:45:53.187|R|CT>"CTCE","Invalid","I:13","S:0","E:0
[0x00000000]"
17/5/2009
18:45:53.187|R|CT>"CTEE","SEVT_MONITOR","E:10","2002","SNo:SEP8888888888
88"
17/5/2009 18:45:53.187|R|CT>"CTEE","SEVT_MONITOR","2002","State:Y"
17/5/2009 18:45:53.187|M|"DeviceFeatureNE","RouterEvent","2002""
17/5/2009
18:45:53.187|R|CT>"TQueryForward","TQueryForward(Request)","2002","TQuer
yForward('2002')"
17/5/2009
18:45:53.187|R|CT>"TQueryForward","TQueryForward(Response)","2002","TQue
ryForward() = SUCCESS"
17/5/2009
18:45:53.187|R|CT>"CTEE","SEVT_DEVICE","E:97","2002","SNo:SEP88888888888
8"
17/5/2009
18:45:53.187|R|CT>"CTEE","SEVT_DEVICE","EEVT_OUTOFSERVICE","2002"
17/5/2009 18:45:53.187|R|"DeviceFailureEvent","2002"
17/5/2009
18:45:53.187|R|"TIEnv.CTLAShutdownDP","Generate(teShutdown)","Devices.Ou
tOfService:1","EventDelay:30000"
17/5/2009
18:45:53.187|R|CT>"CTEE","SEVT_MONITOR","E:10","2002","SNo:SEP8888888888
88"
17/5/2009
18:45:53.187|R|CT>"CTEE","SEVT_DEVICE","E:97","2002","SNo:SEP88888888888
8"
17/5/2009
18:45:53.187|R|CT>"CTEE","SEVT_DEVICE","EEVT_OUTOFSERVICE","2002"
17/5/2009 18:45:53.187|R|"DeviceFailureEvent","2002"
17/5/2009
18:45:53.187|R|"TIEnv.CTLAShutdownDP","Already(teShutdown)","Devices.Out
OfService:1"
17/5/2009 18:45:53.187|R|"teMonitorBLFDevices","EventNotify"
17/5/2009
18:45:53.187|R|CT>"MonitorDevice","MonitorStartDevice(Request)","3002","
MonitorStartDevice('3002','',MT_MONITOR)"
17/5/2009
18:45:53.187|R|CT>"MonitorDevice","MonitorStartDevice(Response)","3002",
"MonitorStartDevice() = FAILURE(15)"
17/5/2009
18:45:53.187|R|"TimerEvent","Recycle","Generate(teMonitorBLFDevices)","C
urrentIndex:1","BLFDevicesCount:2"
17/5/2009 18:45:53.203|R|"TimerEvent","Event Relay [41]"
17/5/2009 18:45:53.203|R|"teMonitorBLFDevices","EventNotify"
17/5/2009 18:45:53.203|R|"teMonitorBLFDevices","No More BLF Device Left
to be Monitored","CurrentIndex:2","BLFDevicesCount:2"
17/5/2009 18:45:53.203|R|CT>"CTCE","Invalid","I:15","S:0","E:0
[0x00000000]"
17/5/2009
18:45:53.203|R|CT>"CTEE","SEVT_MONITOR","E:10","3002","SNo:SEP8888888888
88"
17/5/2009 18:45:53.203|R|CT>"CTEE","SEVT_MONITOR","3002","State:Y"
17/5/2009 18:45:53.203|M|"DeviceFeatureNE","RouterEvent","3002""
17/5/2009
18:45:53.203|R|CT>"TQueryForward","TQueryForward(Request)","3002","TQuer
yForward('3002')"
17/5/2009
18:45:53.203|R|CT>"TQueryForward","TQueryForward(Response)","3002","TQue
ryForward() = SUCCESS"
17/5/2009
18:45:53.203|R|CT>"CTEE","SEVT_DEVICE","E:97","3002","SNo:SEP88888888888
8"
17/5/2009
18:45:53.203|R|CT>"CTEE","SEVT_DEVICE","EEVT_OUTOFSERVICE","3002"
17/5/2009 18:45:53.203|R|"DeviceFailureEvent","3002"
17/5/2009 18:45:56.656|M|"InitializeICDSystemLog","Initialize","Success"
17/5/2009
18:46:23.203|R|"TimerEvent","teShutdown","Status:Y","RT:1","CTLF:Y","GCT
LS:4""
17/5/2009
18:46:23.203|R|"TIEnv.CTLAShutdownDP","Error(Event.Iteration)","Devices.
OutOfService:1"
17/5/2009
18:46:23.203|R|"TIEnv.CTLAShutdownDP","AutoRestartOnDeviceFail.Disabled"
,"Devices.OutOfService:1","EventDelay:30000"
17/5/2009
18:46:23.203|R|"TIEnv.CTLAShutdownDP","Error(NoGatewayDevices)","Shutdow
n.Imminent","gctlsFail"
17/5/2009
18:46:23.203|M|"CTServerStatusNE","RouterEvent","CTServerStatus","1","1"
,""
17/5/2009 18:46:23.203|M|"CTServerStatusNE","Server
Shutdown\Restarted","CT Link Error"
17/5/2009 18:46:23.234|M|"StopEMSCalendarClient","Started"
17/5/2009 18:46:23.234|CL|"StopEMSClient","Current Client
State:EMSUnknown","Last Client State:EMSUnknown"
17/5/2009 18:46:23.234|CL|"DisconnectRecovery: Started "
17/5/2009 18:46:23.234|CL|"DisconnectRecovery: End "
17/5/2009 18:46:23.234|CL|"StopEMSClient","Success"
17/5/2009 18:46:23.234|M|"StopEMSCalendarClient","Success"
17/5/2009 18:46:23.234|M|"StopEMSCalendarClient","Shutdown","Started"
17/5/2009 18:46:23.234|M|"StopEMSCalendarClient","Shutdown","Success"
17/5/2009
18:46:23.234|M|"PMS>ShutdownPresenceManager","Status=pssStopped"
17/5/2009 18:46:23.234|M|"ShutdownServices","Shutdown","Started"
17/5/2009 18:46:23.234|M|"VoiceServerClient","ShutdownMonitor","Success"
17/5/2009 18:46:23.234|R|"TIEnv","Destructor","Terminating event
services..."
17/5/2009
18:46:23.234|R|"FilterPriorityRoutingExecution.RouteManager.Stopped"
17/5/2009 18:46:23.234|R|XML>Status, mssRunning -> mssShutdownREQ
17/5/2009 18:46:23.234|R|XML>Reply, ET=301, TR=, OS=, RT=, RE=, RD=
17/5/2009 18:46:23.234|R|XML>Status, mssShutdownREQ -> mssShutdown
17/5/2009 18:46:23.234|R|XML>Reply, ET=304, TR=, OS=2002, RT=, RE=, RD=
17/5/2009 18:46:23.234|R|XML>DeviceStatus, Received, "2002",
Capability=N, Service=N, MAC=SEP888888888888
17/5/2009 18:46:23.234|M|"DeviceFeatureNE","RouterEvent","2002""
17/5/2009 18:46:23.234|R|XML>Reply, ET=304, TR=, OS=3002, RT=, RE=, RD=
17/5/2009 18:46:23.234|R|XML>DeviceStatus, Received, "3002",
Capability=Y, Service=N, MAC=SEP888888888888
17/5/2009 18:46:23.234|M|"DeviceFeatureNE","RouterEvent","3002""
17/5/2009 18:46:23.234|R|XML>Reply, ET=301, TR=, OS=, RT=, RE=, RD=
17/5/2009 18:46:23.234|R|XML>Status, mssShutdown -> mssStopped
17/5/2009 18:46:23.234|R|XML>Failover
17/5/2009 18:46:23.234|R|XML>FailoverDevices
17/5/2009 18:46:25.250|R|XML>TPGShutDown=0[0x00000000]
17/5/2009 18:46:25.250|R|"ICD Routing Thread","Shutdown Started"
17/5/2009 18:46:25.250|R|"ICD Routing Thread","Shutdown CT Calls"
17/5/2009 18:46:25.250|R|"ICD Routing Thread","Shutdown CT Link"
17/5/2009
18:46:25.250|R|CT>"ICDRouter","TLogOutServer","TLogOutServer(Request)","
TLogOutServer()"
17/5/2009
18:46:26.937|R|CT>"ICDRouter","TLogOutServer","TLogOutServer(Response)",
"TLogOutServer() = 0"
17/5/2009 18:46:27.031|R|"ICD Routing Thread","Shutdown Complete"
17/5/2009 18:46:27.031|R|"TIEnv","Destructor","Terminating callbacks..."
17/5/2009 18:46:27.031|R|"TIEnv","Destructor","Terminating event
objects..."
17/5/2009 18:46:27.031|M|"ICDRouter","Shutdown","Success"
17/5/2009 18:46:27.046|M|"ICDCommunications","Shutdown","Success"
17/5/2009 18:46:27.046|M|"ShutdownDBObjects","Shutdown","Start"
17/5/2009 18:46:27.046|M|"ShutdownDBObjects","Shutdown","Terminate Call
Objects..."
17/5/2009 18:46:27.046|M|"ShutdownDBObjects","Shutdown","Terminate Agent
Objects..."
17/5/2009
18:46:27.046|M|"ShutdownDBConnectionObject","Shutdown","SID:","CLF:10","
CLF:1"
17/5/2009 18:46:27.046|M|"ShutdownDBObjects","Shutdown","Complete"
17/5/2009 18:46:27.046|M|"ICDDataBase","ShutdownDBObjects","Success"
17/5/2009 18:46:27.046|M|"ICDDataBase","Shutdown","Success"
17/5/2009 18:46:27.046|M|"RecordInterface","Shutdown","Success"
17/5/2009 18:46:27.046|M|"ICDDataBase","Shutdown","Success"
17/5/2009 18:46:27.046|M|"COM>SetCOMEnvironment.CoUninitialize"
17/5/2009 18:46:27.046|M|"ShutdownServices","Shutdown","Completed"
17/5/2009 18:46:27.046|M|"ShutdownVoiceServices","Shutdown","Started"
17/5/2009 18:46:27.046|M|"VoiceServerClient","Shutdown","Success"
17/5/2009 18:46:27.046|M|"ShutdownVoiceServices","Shutdown","Completed"
17/5/2009 18:46:27.046|M|"Voice Process Error
Logging","Uninitialize","Disabled","Ok"
--
Smile, you'll save someone else's day!
Frog
*************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager. http://www.mettoni.com
Mettoni Ltd
Registered in England and Wales: 4485956
9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN
*************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090517/d82c9ecc/attachment.html>
More information about the cisco-voip
mailing list