[cisco-voip] Arc Enterprise v504.485 with CUCM702
FrogOnDSCP46EF
ciscoboy2006 at gmail.com
Mon May 18 12:51:34 EDT 2009
Comments are inline below:
On Mon, May 18, 2009 at 11:28 PM, Bennie Grant <Bennie.Grant at mettoni.com>wrote:
> It would be the same theory that I mentioned earlier – the CTI layer is
> getting confused for some reason when we see 2 devices with the same MAC
> address. I could see why this might happen, but I cant believe you’re the
> first person to be trying this configuration!
>
>
>
> I have the same question from my previous email:
>
> 1) Why do you have the same MAC address (this 888888888888 number) –
> I just want to understand the “real world application” for this config
>
<FROG> hey Bernie, its one device SEP8888888888 with 2 lines 2002 and 3002.
A user want operator to transfer a call on both DN's e.g. 9am to 2pm on 2002
DN (On same MAC/Device) and after 2pm to 3002. This is the application.
> 2) Could you try changing the MAC address of one of these devices by
> one digit, and see if this then works?
>
<frog>No, I can't change MAC. The situation is one IP phone device with
2DNs.
I have tried with 3 phones - same result
> Also, when the issue happens, could you look at the “ICDINIT.log” file –
> this file is the “initialization” file that is created when the Arc Server
> starts, and this may highlight some sort of error. However, from the earlier
> trace it does look like the CTI Manager is sending “out of service” events –
> so you may need to get TAC involved
>
> <frog> Can your TAC guys test this in the lab? - 1 phone/1mac with 2 lines
and associate both lines with ARC_TAPI user.
See if your lab version also getting the same issue.
>
>
> Thanks
>
>
>
> *Bennie Grant
> **VP - Operations
> **Arc Solutions (International) Inc
> *Part of the Mettoni group | www.mettoni.com
>
>
>
> *From:* FrogOnDSCP46EF [mailto:ciscoboy2006 at gmail.com]
> *Sent:* Sunday, May 17, 2009 11:57 AM
> *To:* Bennie Grant
> *Cc:* cisco-voip voyp list
> *Subject:* Re: [cisco-voip] Arc Enterprise v504.485 with CUCM702
>
>
>
> Hi Bernie,
> Thanks for your detailed msg.
> the version i am using is 5.0.2(485)
>
> My observation are when I associate ARC_TAPI user with a Phone device which
> has two different DN causes ARC CT-Server start/shutdown loop.
>
> The log I posted in previous mail had a device SEP888888888888 with 2002
> and 3002 DN (not shared one).
>
> If I deassociate 3002 from ARC_TAPI user then CT server is all good. I just
> tested it again and when I associated 3002 it start shutingdown / coming up
> automatically and its kinda loop.
>
> Somehow single MAC with 2 different DN are tricking CTserver.
>
> I have tried adding real phone with 2 DN and the CT server behaves the
> same.
>
> -frog
>
>
> On Mon, May 18, 2009 at 12:26 AM, Bennie Grant <Bennie.Grant at mettoni.com>
> wrote:
>
> 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
>
>
>
>
>
> *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:SEP888888888888"
> 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","TQueryForward('2002')"
>
> 17/5/2009
> 18:45:53.187|R|CT>"TQueryForward","TQueryForward(Response)","2002","TQueryForward()
> = SUCCESS"
> 17/5/2009
> 18:45:53.187|R|CT>"CTEE","SEVT_DEVICE","E:97","2002","SNo:SEP888888888888"
> 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.OutOfService:1","EventDelay:30000"
>
> 17/5/2009
> 18:45:53.187|R|CT>"CTEE","SEVT_MONITOR","E:10","2002","SNo:SEP888888888888"
> 17/5/2009
> 18:45:53.187|R|CT>"CTEE","SEVT_DEVICE","E:97","2002","SNo:SEP888888888888"
> 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.OutOfService: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)","CurrentIndex: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:SEP888888888888"
> 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","TQueryForward('3002')"
>
> 17/5/2009
> 18:45:53.203|R|CT>"TQueryForward","TQueryForward(Response)","3002","TQueryForward()
> = SUCCESS"
> 17/5/2009
> 18:45:53.203|R|CT>"CTEE","SEVT_DEVICE","E:97","3002","SNo:SEP888888888888"
> 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","GCTLS: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)","Shutdown.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
>
> *************************************************************************
>
>
>
>
> --
> 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
> *************************************************************************
>
>
--
Smile, you'll save someone else's day!
Frog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090519/978f2937/attachment.html>
More information about the cisco-voip
mailing list