[cisco-voip] Arc Enterprise v504.485 with CUCM702
Jason Burns
burns.jason at gmail.com
Mon May 18 21:22:49 EDT 2009
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090518/ce53bc90/attachment.html>
More information about the cisco-voip
mailing list