12-03-2015 12:20 PM
We have a case where the provider seems to go down and jtapi shows ProviderOutOfServiceEvent being queued (jtapi_4_11.log):
29513148: Jul 25 00:35:21.201 EDT %JTAPI-PROTOCOL-7-UNK:(P1-10.64.137.37) received Event: com.cisco.cti.protocol.ProviderOutOfServiceEvent {
eventSequence = 1502156
PROVIDER_OUT_OF_SERVICE_EVENT = 200
}
29513149: Jul 25 00:35:21.201 EDT %JTAPI-MISC-7-UNK:(P1-10.64.137.37) EventThread: queuing com.cisco.cti.protocol.ProviderOutOfServiceEvent
29513150: Jul 25 00:35:21.201 EDT %JTAPI-MISC-7-UNK:(P1-10.64.137.37) ReceiveThread: shutting down
29513151: Jul 25 00:35:21.201 EDT %JTAPI-MISC-7-UNK:(P1-10.64.137.37) ReceiveThread:java.lang.NullPointerException
29513152: Jul 25 00:35:21.201 EDT %JTAPI-MISC-7-UNK:(P1-10.64.137.37) ReceiveThread: finished shutting down
29513153: Jul 25 00:35:21.201 EDT %JTAPI-MISC-7-UNK:(P1-10.64.137.37) EventThread: shutting down
29513154: Jul 25 00:35:21.201 EDT %JTAPI-MISC-7-UNK:(P1-10.64.137.37) EventThread: waiting for exit
29513155: Jul 25 00:35:21.201 EDT %JTAPI-CTIIMPL-7-UNK:(P1-10.64.137.37) EventThread handling event com.cisco.cti.protocol.ProviderOutOfServiceEvent[1502156]
However, the event never gets dequeued and sent. Don't know if it's related but I also notice this exception:
29513220: Jul 25 00:35:21.201 EDT %JTAPI-CTIIMPL-7-UNK:(P1-10.64.137.37) caught java.lang.NullPointerException
java.lang.NullPointerException
at com.cisco.jtapi.JTAPICallInfo.getfwdDestinationPartyPartition(CTQF)
at com.cisco.jtapi.CallManager.INITIAL_CAUSE(CTQF)
at com.cisco.jtapi.CallManager.CTQF(CTQF)
at com.cisco.jtapi.CallManager.I(CTQF)
at com.cisco.jtapi.CallManager.I(CTQF)
at com.cisco.jtapi.RouteAddressCallObserver.callClosed(CTQF)
at com.cisco.jtapi.LineObserverImpl.CallClosed(CTQF)
at com.cisco.cti.client.implementation.Call.CallOrphanStatusEvent(CTQF)
at com.cisco.cti.client.implementation.Call.I(CTQF)
at com.cisco.cti.client.implementation.Line.simulateCallClosedEv(CTQF)
at com.cisco.cti.client.implementation.Line.CallFwdDestination(CTQF)
at com.cisco.cti.client.implementation.Line.Close(CTQF)
at com.cisco.cti.client.implementation.Device.Z(CTQF)
at com.cisco.cti.client.implementation.Provider.OpenParkDns(CTQF)
at com.cisco.cti.client.implementation.Provider.I(CTQF)
at com.cisco.cti.client.implementation.Provider$EventThread.messageReceived(CTQF)
at com.cisco.cti.util.MessageThread.append(CTQF)
at com.cisco.cti.util.MessageThread.CTQF(CTQF)
at com.cisco.cti.util.MessageThread.run(CTQF)
The environment has 4 providers. The other 3 also go down but in those cases ProviderOutOfServiceEvent is queued and sent. Here's one of those providers (jtapi_3_19.log):
20579355: Jul 25 00:30:06.552 EDT %JTAPI-PROTOCOL-7-UNK:(P1-10.64.137.35) received Event: com.cisco.cti.protocol.ProviderOutOfServiceEvent {
eventSequence = 1027792
PROVIDER_OUT_OF_SERVICE_EVENT = 200
}
20579356: Jul 25 00:30:06.552 EDT %JTAPI-MISC-7-UNK:(P1-10.64.137.35) EventThread: queuing com.cisco.cti.protocol.ProviderOutOfServiceEvent
20579357: Jul 25 00:30:06.552 EDT %JTAPI-CTIIMPL-7-UNK:(P1-10.64.137.35) EventThread handling event com.cisco.cti.protocol.ProviderOutOfServiceEvent[1027792]
...
20580020: Jul 25 00:30:06.583 EDT %JTAPI-JTAPI-7-UNK:(P1-4027ts03) ProvOutOfServiceEv [#2665653] Cause:100 CallCtlCause:0 CiscoCause:0 FeatReason:12
The end result is that some DNs go out of service but we are never notified about them. Any incoming calls may get redirected to them which results in ConnFailedEvent with CiscoCause=CAUSE_USERBUSY .
What would be the cause of this?
Thanks!
12-07-2015 08:39 AM
Any ideas out there? Thanks.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide