For a SCCP integration with CCM the micro trace SkinnyTSP-12 will show you Skinny messages in/out of Unity. In particular, sounds like you are looking for the originalCdpnRedirectReason parameter which should show up in StationCallInfoMessage.
I enabled SkinnyTSP-12, but I cannot figure out under which process I may watch its activity.
I did ffind another microtrace under the AVCsMgr diags showing me 'CallInfo field Reason was retrieved as <1>' (meaning, I assume LINECALLREASON_DIRECT) for direct-to-the-pilot-number calls and '<4>' (meaning LINECALLREASON_FWDNOANSWER) for all calls that cover to voicemail using a coverage path - regardless of reason.
I specifically do NOT see any entries for 'CallInfo field Reason was retrieved as <2>' (meaning LINECALLREASON_FWDBUSY) when the handset is Ready/Offhook.
Does the fact that Unity is getting *some* reason codes - it is differentiating between Direct and ForwardNoAnswer - necessarily mean Unity is getting everything sent to it?
Is this getting beyond what is reasonable over the forum to the point I need to open a TAC case?
The Skinny TSP runs inside an svchost process so you'll need to look in the diag_svchost logs for those traces.
If Unity is getting some reason codes but not the ones you are expecting, then you'll probably need to look further upstream. i.e. perhaps check CCM traces and debug from the gateway. Somewhere in the gateway traces I'd think you could find what call info is being passed on your q.sig trunk.
The NOT FORMATTED is expected behavior for diags from the TSP. The TSP doesn't follow the same formating rules that UDT expects so they get flagged when UDT tries to format them. Unlike most other Unity diags, the TSP diags actaully don't require formatting. You can just grab the raw diag_svchost files out of the logs folder and view them just as easily.
Now, back to your case... looks like the incoming call has callType=1=TsInBoundCall rather than callType=3=TsForwardCall. Thus initially the TSP sees it as a direct call rather than a forwarded call. But then it also has originalCdpnRedirectReason=15=RfrCallFwdUnconditional, which indicates that maybe the callType was mismarked so we'll treat it as forwarded afterall. That part of it seems to be working fine.
Finally, the only two reason codes that will get you to the busy greeting are RfrCallFwdBusy and RfrCallDeflection. So the calls with RfrCallFwdUnconditional are expected to go to the standand greeting.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.