RNA and the Busy Greeting

[tonyw1538]

A user pointed out that for some unknown period of time the Busy greeting on our Unity 4.1 system integrated with our Avaya S8700 'via' CCM 4.1.3 (and a Qsig link to a cLAN card) does not work.

Testing reveals that all calls covering to voice mail cover with a 'Ring No Answer' from Unity's perspective versus whatever a 'Busy' code is.

My question: Does anybody remember the Microtraces that show the reason code as it comes in? I would like to be sure Unity is getting what it needs before I march forward with a TAC case.

Thank you,

[eschulz]

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.

-Eric

[tonyw1538]

Thanks Eric,

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?

[eschulz]

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.

[tonyw1538]

Thank you again Eric. I found the traces.

A couple of interesting things there - First, the Source' field is *NOT FORMATTED**, don't know if that's a big deal or indicative of a problem.

More interesting, perhaps, is that I am getting the message 'Received non-redirected call with a redirection reason. Change callType to TsForwardCall.' Perhaps in context that will make more sense?

I have attached the trace file to this thread. If you have time and inclination to have a look it will be most appreciated!

- Tony -

[eschulz]

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.