Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
1708
Views
0
Helpful
13
Replies

Agent Desktop Issue

IT_Phillip
Level 1
Level 1

‎12-06-2010 12:03 PM - edited ‎03-14-2019 07:00 AM

I've been having some users get logged out of CAD for no reason.  Here is the jtapi log of when this happens.  Any ideas on what might be causing this???

929: Dec 03 14:42:36.306 CST %JTAPI-PROTOCOL-7-UNK:(P7-10.130.0.12) received Response: com.cisco.cti.protocol.GetLineInfoFetchResponse {
  sequenceNumber = 37
  info           = 2@[
com.cisco.cti.protocol.LineInfo {
    name             = 4799
    displayName      = Emily *********
    permanentLineID  = 1234577583
    maxNumberOfCalls = 4
    lineInstance     = 1
    busyTrigger      = 2
    },
com.cisco.cti.protocol.LineInfo {
    name             = 8799
    displayName      =
    permanentLineID  = 1846486595
    maxNumberOfCalls = 2
    lineInstance     = 2
    busyTrigger      = 1
    }]
  more           = false
  }
2930: Dec 03 14:42:36.306 CST %JTAPI-PROTOCOL-7-UNK:(P7-10.130.0.12) [(P7-10.130.0.12) DeviceLineUpdateThread] sending: com.cisco.cti.protocol.GetLineInfoCloseRequest {
  sequenceNumber    = 38
  enumerationHandle = 71832
  }
2931: Dec 03 14:42:36.316 CST %JTAPI-PROTOCOL-7-UNK:(P7-10.130.0.12) received Response: com.cisco.cti.protocol.GetLineInfoCloseResponse {
  sequenceNumber = 38
  }
2932: Dec 03 14:42:36.316 CST %JTAPI-CTI-7-UNK:(P7-3352) SEP001759C48420(0,0) refreshing lines: previous=2 current=2 created=0 removed=0
2933: Dec 03 14:42:37.943 CST %JTAPI-JTAPI-7-UNK:(P7-3352)[(P7-sa-ccm1) EventThread](P7-3352) Request: removeObserver
2934: Dec 03 14:42:37.943 CST %JTAPI-JTAPI-7-UNK:ProvObservationEndedEv event to com.spanlink.jtapiclient.splkJtapiObj@21d1f4
2935: Dec 03 14:42:37.943 CST %JTAPI-JTAPI-7-UNK:ProvObservationEndedEv [#68]
2936: Dec 03 14:42:37.943 CST %JTAPI-JTAPIIMPL-7-UNK:[com.spanlink.jtapiclient.splkJtapiObj@21d1f4]ObserverProxy.queueEvents: dispatching synchronously
2937: Dec 03 14:42:37.943 CST %JTAPI-JTAPIIMPL-7-UNK:[com.spanlink.jtapiclient.splkJtapiObj@21d1f4]ObserverProxy.deliverEvents()
2938: Dec 03 14:42:37.953 CST %JTAPI-JTAPIIMPL-7-UNK:[com.spanlink.jtapiclient.splkJtapiObj@21d1f4]delivering to providerChangedEvent
2939: Dec 03 14:42:37.953 CST %JTAPI-JTAPIIMPL-7-UNK:[com.spanlink.jtapiclient.splkJtapiObj@21d1f4]ObserverProxy.deliverEvents() completed
2940: Dec 03 14:42:37.953 CST %JTAPI-JTAPI-7-UNK:(P7-3352)[(P7-sa-ccm1) EventThread](P7-3352) Request: shutdown
2941: Dec 03 14:42:37.953 CST %JTAPI-MISC-7-UNK:Provider "(P7-3352)" changing state to SHUTDOWN
2942: Dec 03 14:42:37.953 CST %JTAPI-JTAPI-7-UNK:(P7-3352)[(P7-sa-ccm1) EventThread](P7-3352) Request: getObservers
2943: Dec 03 14:42:37.953 CST %JTAPI-PROTOCOL-7-UNK:(P7-10.130.0.12) [(P7-sa-ccm1) EventThread] sending: com.cisco.cti.protocol.ProviderCloseRequest {
  sequenceNumber = 39
  }
2944: Dec 03 14:42:38.154 CST %JTAPI-PROTOCOL-7-UNK:(P7-10.130.0.12) received Response: com.cisco.cti.protocol.ProviderCloseResponse {
  sequenceNumber = 39
  }
2945: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) shutting down
2946: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) ProviderRetryThread shutting down
2947: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) ProviderRetryThread exiting
2948: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) ProviderRetryThread finished shutting down
2949: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) ReceiveThread: shutting down
2950: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) ReceiveThread: stream closed
2951: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) ReceiveThread: exiting
2952: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) ReceiveThread: notifying handler of demise
2953: Dec 03 14:42:38.154 CST %JTAPI-PROTOCOL-7-UNK:(P7-10.130.0.12) received Event: com.cisco.cti.protocol.ProviderOutOfServiceEvent {
  eventSequence                 = 69
  PROVIDER_OUT_OF_SERVICE_EVENT = 200
  }
2954: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) EventThread: queuing com.cisco.cti.protocol.ProviderOutOfServiceEvent
2955: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) EventThread: shutting down
2956: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) EventThread: waiting for exit
2957: Dec 03 14:42:38.154 CST %JTAPI-CTIIMPL-7-UNK:(P7-10.130.0.12) EventThread handling event com.cisco.cti.protocol.ProviderOutOfServiceEvent[69]
2958: Dec 03 14:42:38.154 CST %JTAPI-CTIIMPL-7-UNK:(P7-10.130.0.12) deviceMap is empty? -false
2959: Dec 03 14:42:38.154 CST %JTAPI-CTIIMPL-7-UNK:(P7-10.130.0.12) lineMap is empty? -true
2960: Dec 03 14:42:38.154 CST %JTAPI-CTIIMPL-7-UNK:(P7-10.130.0.12) callMap is empty? -true
2961: Dec 03 14:42:38.154 CST %JTAPI-CTIIMPL-7-UNK:(P7-10.130.0.12) clearing park DN map
2962: Dec 03 14:42:38.154 CST %JTAPI-JTAPI-7-UNK:(P7-3352)[(P7-10.130.0.12) EventThread](P7-3352) Request: getCalls
2963: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) EventThread: exiting
2964: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) EventThread: finished shutting down
2965: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) HeartbeatSendThread shutting down
2966: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) HeartbeatSendThread waiting for exit
2967: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) HeartbeatSendThread exiting
2968: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) HeartbeatSendThread finished shutting down
2969: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) HeartbeatReceiveThread shutting down
2970: Dec 03 14:42:38.154 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) HeartbeatReceiveThread waiting for exit
2971: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) HeartbeatReceiveThread server heartbeat or message not received for 60600 mili-second
2972: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) HeartbeatReceiveThread exiting
2973: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) HeartbeatReceiveThread finished shutting down
2974: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) DeviceLineUpdateThread: shutting down
2975: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:[com.cisco.cti.util.BlockingQueue@4e8cee]BlockingQueue:take() Threadname=(P7-10.130.0.12) DeviceLineUpdateThread  Thread interrupted
2976: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) DeviceLineUpdateThread: exiting
2977: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) DeviceLineUpdateThread: waiting for exit
2978: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) DeviceLineUpdateThread: finished shutting down
2979: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) ReceiveThread: waiting for exit
2980: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) ReceiveThread: finished shutting down
2981: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-10.130.0.12) finished shutting down
2982: Dec 03 14:42:38.164 CST %JTAPI-JTAPI-7-UNK:(P7-3352)[(P7-sa-ccm1) EventThread][8799]Request: getCallObservers()
2983: Dec 03 14:42:38.164 CST %JTAPI-JTAPIIMPL-7-UNK:[com.spanlink.jtapiclient.splkJtapiObj@21d1f4]ObserverProxy.deliverEvents() completed
2984: Dec 03 14:42:38.164 CST %JTAPI-CTI-7-UNK:(P7-3352) DeviceMap: closing device "SEP001759C48420"
2985: Dec 03 14:42:38.164 CST %JTAPI-JTAPIIMPL-7-UNK:(P7-3352) Terminal "SEP001759C48420" out of service
2986: Dec 03 14:42:38.164 CST %JTAPI-JTAPI-7-UNK:(P7-3352) [SEP001759C48420] CiscoTermOutOfServiceEv [#69]
2987: Dec 03 14:42:38.164 CST %JTAPI-CTIIMPL-7-UNK:(P7-10.130.0.12) deviceMap is empty? -false
2988: Dec 03 14:42:38.164 CST %JTAPI-CTIIMPL-7-UNK:(P7-10.130.0.12) lineMap is empty? -true
2989: Dec 03 14:42:38.164 CST %JTAPI-CTIIMPL-7-UNK:(P7-10.130.0.12) callMap is empty? -true
2990: Dec 03 14:42:38.164 CST %JTAPI-CTIIMPL-7-UNK:(P7-10.130.0.12) clearing park DN map
2991: Dec 03 14:42:38.164 CST %JTAPI-JTAPI-7-UNK:(P7-3352)[(P7-sa-ccm1) EventThread](P7-3352) Request: getCalls
2992: Dec 03 14:42:38.164 CST %JTAPI-MISC-7-UNK:(P7-sa-ccm1) EventThread: exiting

Labels:
0 Helpful
13 Replies 13

david.macias
VIP
VIP

‎12-06-2010 01:07 PM

Look like the phone is losing connectivity.  Does the user notice the phone registering or doing anything weird?  Are these remote users?

david

Blog
0 Helpful

IT_Phillip
Level 1
Level 1
In response to david.macias

‎12-06-2010 01:12 PM

No, these are not remote users.  The user does not notice anything happening with the phone itself, it stays registered the whole time.  I have ran a continuous ping when the user get this error and there are no time outs.  This issue is very random.  Most of last week the users would see this 1-2 times an hour, but today it has only happened once or twice all day.

0 Helpful

david.macias
VIP
VIP
In response to IT_Phillip

‎12-06-2010 01:23 PM

Move the user to another phone and see what happens.

david

Blog
0 Helpful

IT_Phillip
Level 1
Level 1
In response to david.macias

‎12-06-2010 01:39 PM

Forgot to mention that we have already tried that, as well as many other things on the user's end.  Here is a list of everything we have done on the user's end.

  • Uninstall and reinstall Cisco Agent Desktop - Been done numerous time
  • A complete format of the hard drive and a reinstall of Windows and CAD - Been done 2 times
  • Swapped out hard drive and put into different laptop, no difference
  • Uninstalled all security software, made no difference
  • Upgraded all Windows drivers
  • Had user work on wireless connection instead of wired
  • Tried a couple different phones

After trying all this it is hard to believe that this problem stems from the user's end.  Is there anything on the server end that might cause this?  And if so where is the first place to look?

0 Helpful

david.macias
VIP
VIP
In response to IT_Phillip

‎12-06-2010 01:46 PM

So, it only happens to some users, but not to all users?  Is it the same users every time?  What happens if the users changes IDs from a users who doesn't have this problem?

david

Blog
0 Helpful

cndilip123
Level 1
Level 1
In response to david.macias

‎12-06-2010 10:43 PM

As David says it looks like IP Phones loosing connection to the call manager. If it's affecting just a few phones, it could be the way they are wired-up or the switch they connect to.

If you have access to the call manager you can find out the "StationAlarmMessage" generated for these phones from the call manager event-viewer, SDL logs. Look for "Last=xxxx", to understand why the IP Phone de-registered from the call manager.

- Dilip

0 Helpful

IT_Phillip
Level 1
Level 1
In response to cndilip123

‎12-07-2010 07:15 AM

Yes, this only happens to some users and not all of them.  I have talked with my server guys and the only error message they are seeing with this is a heartbeat error with the CTI Manager.  The user doesn't experience any disconnect from the network when this happens though.  Is there any way to configure a different heartbeat timer per user to test this?  If you have any other thoughts please let me know.  Thanks.

0 Helpful

IT_Phillip
Level 1
Level 1
In response to IT_Phillip

‎12-15-2010 07:27 AM

bump

0 Helpful

thomascollins
Level 3
Level 3
In response to IT_Phillip

‎12-15-2010 07:35 AM

Just curious -- what's your switching environment?  QoS setup? Have you done packet captures to see where the heartbeat loss is coming from?

0 Helpful

david.macias
VIP
VIP
In response to thomascollins

‎12-15-2010 08:04 AM

Did you swap out agent IDs from an affected user to an unaffected user?

david

Blog
0 Helpful

IT_Phillip
Level 1
Level 1
In response to david.macias

‎12-28-2010 02:17 PM

Sorry it took me so long to reply.  We tried swapping out the agent IDs from an unaffected user and had the same results.

Yes, Qos is utilized, as well as seperate VLAN for voice traffic. 

How could I setup a packet capture to see where is heartbeat failure is coming from?

0 Helpful

IT_Phillip
Level 1
Level 1
In response to IT_Phillip

‎01-05-2011 07:41 AM

bump

0 Helpful

Edward Umansky
Level 4
Level 4
In response to IT_Phillip

‎01-10-2011 12:51 PM

You should go ahead and open a TAC case. Trying to troubleshoot sporadic phone registration issues via the forum isn't going to work well.

0 Helpful
Customers Also Viewed These Support Documents