EMEM RAD connects to NP after playing 1

[bribob]

vMCD 13.0.1.28

I need some help identifying if this behavior is normal, and if not, what the cause is.

Embedded VM has been configured, ports 1-10 (of 30) have been assigned DN 11961-11970. Port 1 is set to Primary Set 1, ports 2/3/4 to RAD Set 10, 5/6/7 to RAD Set 11, 8/9/10 to RAD Set 12. COS is configured (RAD, RAD Adv, Answer Plus timers) and assigned to the voicemail ports.

VM ports are in RAD Hunt Groups w/ Phase Timer Ring set to 3
HG 111962 = p2/3/4
HG 111965 = p5/6/7
HG 111968 = p8/9/10

When I call the Hunt Groups the RAD plays as expected, no issues there. When the RAD is done playing the call immediately connects to the NuPoint hunt group (which does not have a line group greeting), there is a brief period of dead air followed by 'I did not get your response in time...' The same happens when the EMEM VM (RAD) ports are called directly.

So my question is: Why does the call connect to NP after the EMEM RAD has finished playing? Which form is responsible for this behavior?


-b

 

[kwbMitel]

The RAD would normally hang up and you would receive dial tone.

What happens if you call the RAD port directly?

I've never used the phase timer so that kind of sticks out. Can you try it at default of zero?

Do you have any Intercept Handing on your system directed to the nupoint?



**********************************************
What's most important is that you realise ... There is no spoon.

 

[bribob]

I figured you'd be the first to respond...

Phase timer set to 0, same result.

Intercept Handling is not configured, Call Coverage Services IS configured but when the Voice Mail Number is removed the result is the same.


-b

 

[bribob]

Side note, the RAD is referenced in an ACD Express group. When waiting in the queue the RAD plays as expected then returns to MoH. This transfer/connect to NP behavior is only experienced when the RAD HG or port is called directly.


-b

 

[kwbMitel]

very odd

if you remove a port from the hunt group and call it directly does it do the same thing?

I really can't imagine what might cause this. I would be setting up 2 phones to emulate the setup where one is the caller and the other is the RAD to see if the EMEM is somehow injecting something into the process.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[bribob]

Port removed from the HG and called directly, same result.

Test (RAD) phone assigned COS of VM RAD ports and called directly (no HG). Answered call on RAD phone, after the Answer Plus Message Length Timer (8s) expired, caller phone connected to the NP MB of the RAD phone. Confirmed by leaving a message and the MWI turned on. So I'd call that the same result and elimination of EMEM as the cause.

I'mt starting to think his has something to do with the Call Coverage Services form, but the Post Call Destination tab is default to No.


-b

 

[kwbMitel]

I havent played with call recognition much so your theory is sound.

You don't have any weird setting in call rerouting do you? Such as #1 being defined to go to VM as first or 2nd alternative.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[sarond]

I would think Call Coverage is they only way this could happen.
Just change it to something different for the RAD's and HG's in the Station Attributes form as a test.

 

[LoopyLou]

Could it be the message length timer in that the message is done playing but the port is still up so it defaults to the basic behaviour of a voicemail port?

You can't duct tape stupid.

 

[mitelchi]

Do you have 1st Alternative programmed on RAD Hunt group?


Kelvin

 

[bribob]

@kwb & mitelchi: CRR Always + 1st alternative is default, no reroute

But guess what! I didn't think to check the 2nd alternative and it was set to the HG of the NP ports! When the hell did that happen...

Reverted CRR 2nd Alt 1 to Normal (Busy/DND/No Answer INTERNAL to be specific) and the EMEM RAD HG hangs up when finished playing and I hear dial tone.

I appreciate the reminder to double check the basics.


-b

 

[kwbMitel]

kwbmitel said on 8 Oct 15 22:01

You don't have any weird setting in call rerouting do you? Such as #1 being defined to go to VM as first [highlight #FCE94F]or 2nd alternative[/highlight].

This makes sense that this was the answer as I've seen that behaviour on timeout of RADs before when rerouting is set incorrectly.

**********************************************
What's most important is that you realise ... There is no spoon.

 

[bribob]

This is a 'I told ya so' star.


-b