Unity 4.0.4sr1 not connecting calls from CCM 4.1(3)

[ewaizel]

Hi Everybody

I don't know if I'm missing something really obvious;

Unity Voice Mail ports register into CCM. Nevertheless, when I call any of these port from a phone registrered into CCM, there is not answer from Unity (no default or any other greeting).

As part of the Unity Integration all 16 ports are enabled and allowed to answer.

In fact, this is a new server I just finished installing. I'm restoring a DiRT backup done in another server that is working fine (the new server will use the same IP and name as the old one).

TSP ver is 8.0(1b)

Any ideas?

Any traces that I can start?

[eschulz]

I suppose you could look at the Skinny diags from Unity. Turn on the Skinny macro traces in UDT, reproduce the failure then look through the diag_svchost diags. The first thing I'd search for is lines containing callState=4=TsRingIn. This indicates a call being offered to Unity. If you don't see any of these then the problem is outside of Unity. In this case then you should start looking for a misconfiguration in CCM or look at CCM detailed traces to determine where the calls are being sent.

If you are seeing the callState=4=TsRingIn but Unity does not answer (Send StationOffHookMessage) then you might look to the Unity event log. Something typically shows up there in most cases when a call is offered to but not answered by Unity.

-Eric

[Ginger Dillon]

Hi -

From the IP phone, you should only be able to dial the first Unity port. This is how it works on our CCM 4.1(3) and Unity 4.0(5) system as a result of the hunt list/line group configuration. If the IP phone is voicemail enabled, dialing the first port (same result as pressing the Messages button), you should hear Unity say, "Enter your password". If the phone is not voicemail enabled, you should still get the Unity Opening Greeting. If neither of these happen when you dial the first Unity port, then I would validate the voicemail profile in CCM for the DN. You could also check the Line group configuration to see if all of your Unity ports are selected in the section Selected DN/Route Partition. One last thing I would recommend, using Unity's UTIM, you can test your configuration to CCM and validate the integration is functioning properly.

Best wishes, Ginger

[ewaizel]

Thanks for your ideas.

So far, this is not a CCM issue. CCM config did not change between my old and new Unity servers.

Additionally, after capturing traces, I do see the call being received by Unity (in svchost trace there is a callState=4=TsRingIn event). However the call never gets connected.

After analyzing all events and comparing the old and new Unity servers traces, in the new server (the one that does not answer) I can see a message "Processing StationSetLampMessage" after that the trace never reaches TSPI_lineGetCallInfo and TSPI_lineGetCallStatus as happend in the old Unity server. We're obviously not reaching the connect state.

The call then gets disconnected when I release the call (after no answer).

There are no important messages in the Event log. I can simply see that all 16 ports registered into CCM.

More ideas?

[eschulz]

Nope. :( Common causes for Unity to 'ignore' incoming calls are 1) ports not enabled for Answering, 2) Unity is an configured for Failover and is currently Inactiver, and 3) Unity ports failed to initialize properly during startup. You've already checked 1 is not the case and event log messages would have appeared for 2 and 3 so these are ruled out. I don't have any other guesses on what is happening. You might open a TAC case so they can have a closer look at those diag files.

[ewaizel]

Thanks

Just found that I made a mistake with the conffiguration of the MWI extensions (swapped these by mistake).

I'll check if this was the problem

[ewaizel]

Yes,

This was the problem.

Incredible how a little problem (swapping MWI ext numbers) can result in such a strange problem and that Unity has no easy way to let us detect it.