AppError and SDLErrors - part of dropped call issue?

[melissa.karpicke]

We have a CUCM, PCCE, and agents with Spok integration and Telstrat call recording.  we have complaints of dropped calls or hangups.  in call traces we normall see a "bye" but both parties insist they are being hung up on.  I found the following and was wondering if it's part of the problem or if Im going down the wrong rabbit hole.

35200080.000 |08:44:08.469 |SdlSig-I |CtiStopReceptionNotify                 |ready                          |CTIDeviceLineMgr(3,200,13,1)     |SIPStationD(11,100,189,2675)     |3,100,251,1232691.96101^167.251.102.176^* |[R:N-H:0,N:1,L:0,V:0,Z:0,D:0]  DH=3|867 CH=3|64123571 MConnType=3

35200080.001 |08:44:08.469 |AppError |DeviceHandle 3|867

35200080.002 |08:44:08.469 |AppError |DeviceHandle FOUND 3|867

35200080.003 |08:44:08.469 |AppError |ThirdParty FOUND DH=3|867

35200121.000 |08:44:08.897 |SdlSig-I |SsDataInd                              |ready                          |CTIDeviceLineMgr(3,200,13,1)     |Cdcc(3,100,39,14544865)          |3,100,255,1.22151606^167.251.103.175^*   |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] SsType=16777260 SsKey=0 SsNode=3 SsParty=64119728 DevId=(0,0,0) BCC=6 OtherParty=64120601 NodeOtherParty=3 clearType = 0 CSS=4f844e15-caa2-edfe-7863-ff66aeed1670 CNumInfo = 0 CNameInfo = 0 ssDevType=8 ssOtherDevType=8 FDataType=0 opId=0 ssType=0 SsKey=0 invokeId=0 resultExp=F bpda=F ssCause = 16 ssUserState = 2 ssOtherUserState = 2 PL=5 PLDmn=0 isMultiForkingEnabled=F networkDomain= delayAPTimer=F geolocInfo={geolocPkid=, filterPkid=, geolocVal=, devType=8} cfwdTimerAction=0 matchInterceptPartition= matchInterceptPattern=

35200121.001 |08:44:08.897 |SdlError |SsDataInd                              |ready                          |CTIDeviceLineMgr(3,200,13,1)     |                                 |                                         |Error:  Description: A transition is not defined for the input signal. Check state machine definition in initStateMachine().

[Tanay Chaturvedi]

It doesnt looks to be. You might need to track the call from start to finish and tear up in both CCM and CTI SDL logs to see if the calls are being disconnected properly or something else is causing the disconnect.

[Maren Mahoney]

First, I approve of attaching the trace file to your post. Please next time put the trace into Notepad++ (https://notepad-plus-plus.org) or another text editor. MS Word (and other standard word-processing apps) don't handle the extremely long lines in trace files well. There were a couple of errors related to this in your word doc.

It is difficult to parse your trace file without knowing the originating caller ID, the pilot dialed, and the agent reached. Also, as @Tanay Chaturvedi pointed out, having the SIP trace from the gateway/sbc/cube (is that the device at 167.251.103.175?) in addition to the trace from the CallManager service (and also the CTI Manager service) will be what is needed to start diagnosing the problem.

I did note the same three errors you did regarding the "Check state machine" at and after timestamp 08:44:08.897. Did you see the set of error output just after timestamp 08:44:47.536? 

When you can, please provide the full set of trace files and we will see what we can do to help.

Maren