topic Re: AppError and SDLErrors - part of dropped call issue? in Collaboration Applications

AppError and SDLErrors - part of dropped call issue?

melissa.karpicke — Thu, 13 Nov 2025 14:00:09 GMT

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.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=

Re: AppError and SDLErrors - part of dropped call issue?

Tanay Chaturvedi — Fri, 14 Nov 2025 18:53:47 GMT

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.

Re: AppError and SDLErrors - part of dropped call issue?

Maren Mahoney — Fri, 14 Nov 2025 20:49:01 GMT

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