[cisco-voip] Arc Enterprise v504.485 with CUCM702
Bennie Grant
Bennie.Grant at mettoni.com
Mon May 18 22:33:14 EDT 2009
OK, I think I understand now:
This is an IP Communicator with 2 lines on it. Arc is a "Device" centric
application, so isn't too specific around how many "lines" you
specifically have on a device. However, I know that associating a
"device with multiple lines" to the CUCM user should not cause such an
issue. Again, it sounds that the CTI Manager is getting confused -
reporting devices as Out_of_Service, and therefore the Arc Server cannot
start...
Could you try the following:
1) Start the Arc Server WITHOUT the IPC associated (should start
fine from what I understand)
a. Test the system - put calls into queues and make sure it all
works fine
2) THEN, associate the IPC device - DO NOT RESTART THE ARC SERVER
a. Test the system again - put calls into queues again, does it
still work as it did before?
3) If it does still work, stop/start the Arc Server - does it come
back up?
a. If not, send me the ICDInit.log file as mentioned before -
should give an indication as to where the problem is
b. If not, download the "TAPI Softphone" from www.julmar.com
(freeware) - try and control a CTI Port or IP Phone through this
application and make a call to another device - does it work?
i.
This application is nothing to do with Arc, and something we use to
narrow down issues like this - i.e. if it is a general CTI issue, or if
its specific to Arc applications
If possible, could you try this with real hardphone (i.e. valid MAC
address) instead of a softphone - wouldn't mind seeing if this is
related to a dummy MAC address or not.
Either way, this is a CTI issue - the Arc Server doesn't seem to be able
to control the CTI Ports ("Host PBX Gateway" devices) when you have this
device associated - the ICDInit.log file should confirm this. Therefore,
I don't think VMWare will have a bearing on this - it "shouldn't" make a
difference
On a different note, do you need to have this device associated anyway?
You don't need to associate the device in order to be able to transfer
to it?
Thanks
Bennie Grant
VP - Operations
Arc Solutions (International) Inc
Part of the Mettoni group | www.mettoni.com <http://www.mettoni.com/>
From: FrogOnDSCP46EF [mailto:ciscoboy2006 at gmail.com]
Sent: Monday, May 18, 2009 10:06 PM
To: Jason Burns
Cc: Bennie Grant; cisco-voip voyp list
Subject: Re: [cisco-voip] Arc Enterprise v504.485 with CUCM702
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
<http://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
<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
************************************************************************
*
--
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
*************************************************************************
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/20090519/915f7b0c/attachment.html>
More information about the cisco-voip
mailing list