[cisco-voip] Arc Enterprise v504.485 with CUCM702
FrogOnDSCP46EF
ciscoboy2006 at gmail.com
Mon May 18 22:05:41 EDT 2009
Hi Jason,
Yes, its IP communicator and I have also tested with IPBLUE.
CCM reckonises this device as a VALID and It registers okay with CCM. I have
tested another real phone with real MAC and issue is the same.
Just did a fresh install and it's happening again. This could be coz I am
runing them in a VMWARE win2003?
On Tue, May 19, 2009 at 11:22 AM, Jason Burns <burns.jason at gmail.com> wrote:
> Is this device Cisco IP Communicator? Is that why is has Device Name
> SEP888888888888? I think the reason Bennie asked the question again is that
> 8888.8888.8888 is not a valid MAC address to be assigned to a physical
> device.
>
> On Mon, May 18, 2009 at 12:51 PM, FrogOnDSCP46EF <ciscoboy2006 at gmail.com>wrote:
>
>> 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
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
--
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/38713227/attachment.html>
More information about the cisco-voip
mailing list