MXe - Upgraded from 4.0SP1 -> 4.2SP2 - NameTag not working now

[Cabarrus]

So we have two MXe controllers that were both running MCD 4.0SP1. One was upgraded to 4.2SP2 and one was upgraded to 4.2SP2 PR1. On the 4.2SP2 unit nametag huntgroups like *1166 that would forward directly to 1166 embedded voicemail box no longer work. When pressing transfer, *1166 and release, the call is immediatly rang back to the phone performing the transfer. Phone rep mentioned it might be related to Feature Access Code "Force Party Release" but I am not sure.

1) Would the PR1 fix that wasn't applied have anything to do with this?

2) Would the upgrade modify feature access codes and cause the problem?

Any suggestions/ideas, would be great.

thanks

 

[LoopyLou]

Typically an upgrade would not alter feature access codes so I would say you are probably right in that there is something different between the two loads.

Did you go to SDS and RDN as part of the upgrade or were you not using Opsman before the upgrade? Did your nametag groups have names in the tel dir before the upgrade?

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[Cabarrus]

We don't use opman, not sure what SDS / RDN is, we had local phone company techs perform upgrade, and im trying to get this resolved faster then waiting on them to resolve it.

The tel dir question is a good one. I recall the phone tech contacting Mitel since the upgrade prompted with a tel dir question. I do not recall anything specific i did when creating the nametag hunt group besides creating and going into call rerouting and change Day/Night modes to go directly into voicemail directory number.

Anything else you can suggest/have me look at, would be great..

thanks

 

[kwbMitel]

I think it is more likely that something was lost in the upgrade rather than something being different in the OS.

Check the existence of the huntgroup (Nametag)
Check the routing of the huntgroup (to voicemail assumed)
Check the destination of the routing for the huntgroup (access code ok?)

Locate Feature Extension *1166 (make sure of any features set against the group that might be interfering)


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

 

[Cabarrus]

The Hunt Group / Routing to hunt group is fine. Could you elaborate on "Check the destination of the routing for the huntgroup (access code ok?)" ?

The locate feature showed ok

 

[kwbMitel]

The huntgroup should be routed on an always condition Day/N1/N2 to an Always Rerouting Point.

What Number is it rerouted to?
Is that number a valid number? (Expected = VM Hunt Group DN)

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

 

[Cabarrus]

ill have to double check that when i get to site in am. I appreciate your help.

If you don't mind me asking a semi related question, since it appears I have bumped my head on something.

We have a simple menu node setup and pressing option 5 goes to extension 1207 which is a phone. If 1207 isnt picked up the call does not goto voicemail but rather back to the menu node. I figured i could create a *1207 nametag hunt group and point option 5 to that but it says the DN is in use. Could you tell me what i am missing? i did review the faqs.

thanks

 

[kwbMitel]

The last problem is caused by the use of nametag groups and using nametags to resolve the issue is counterproductive.

My first question would be do you need to use a nametag route to send the call to the original Menu Node. Usually, the answer is no.

By using nametag groups overly much you could simply be making the issue worse.

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

 

[Cabarrus]

I reread your faq post:

http://www.tek-tips.com/faqs.cfm?fid=7197

I see on the Update portion you do not recommend method for MLAA and that is what I have setup. I want the console to put our system in Night2 mode during lunch breaks which then forwards to a Menu node voicemail. The issue is if I set Night2 call rerouting to the menu node extension directly, the menu node voicemail doesnt pickup and play. If i send it to a Nametag hunt group i.e. the menu node voicemail extension is 7226 and the Nametag hunt group is *7226 the menu node voicemail does play. It doesnt appear I have any other choice but to use a Nametag hunt group?

If there are other options/alternatives to get this to work, that would be great.

thanks

thanks

 

[Cabarrus]

To fix the original issue for this thread i enabled: Public Network Access via DPNSS on the COS the VM Ports use. I assume this was changed during the upgrade, and not understanding how it is described in the help. Select "Yes" to permit devices to originate calls via DPNSS trunks to CO trunks. Select "No" to disable network access.

 

[kwbMitel]

There is another method of overriding VM integration that is not as simple as using nametags but does not have the drawbacks that you've seen here.

It involves setting up ACD paths and Vacant Agent groups.

There a FAQ for that as well (referenced in the Nametag FAQ)

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