Simple hunt group route to vmpro but it just doesnt seem right 5

[R3LzX]

ok so I always route to vmpro after deciding if im going to do night mode or fallback to whatever for whatever is needed etc etc. I set up my Leave and im good to go. Simple... no problem it works

But I recently ran into a strange scenario where the previous programmer gave the module the exact same name as the huntgroup so when its in fallback its actually routing to the Auto Attendant module because it has the same name. I have been working with ipo since about 2003 or 4 and ive never seen or done things this way. lots of congestion counts on vmpro on this server as well (which i am isolating and tracking). Is this something any of you guys have done on larger deployments (20 vmpro ports and up) and is it best practice? I initially want to say its not but curiosity has me.

thanks in advance

 

[holdmusic34]

I think the technician didn't work on the early Avayas. Ahhhh 2003. <sips whiskey and leans back in chair>

It was a topsy-turvy time my young Padawan. A time where a space counted as a character. Duplicate names could open the seventh portal of hell and would crash a system. At a minimum you would have to work after hours to solve it. Then SIP came along.

So I don't think it's best practise, but I don't have that customer. It may be best practise for him. A wise technician uses all the tools available to him at the time. I however, am foetal at the thought of duplicates.

Use Main, Overflow, <Department>, <Department Oflow>, Night for your HGs.
Use MainAA, OverlowAA etc if modules are required to back end them.



Are you keeping up with the Commodore? Because the Commodore is keeping up with you.

 

[intrigrant]

Although Avaya encourages the use of huntgroups with the same name as the module, I never do that. Spooky things start to happen.
The same accounts if the system name equals a group name or a VM module name.

 

[IPGuru]

if incomming calls go direct to an AA (VM:<name>)

then haveing the modle name match the group name means if the VM Por iss ot of service the call should route to the group.
this did not always work & I cant remember when it was introduced

personaly I never use it, instead I use the fallback destination in the incomming call route to handle failure

If you are ringing the group first & only wating to ad a menu if the group does not answer then I would make sure that modules do not share the same name as the group & use the leave start point as you describe.

Personaly I would consier the above to be "Best Practice" and never have a name clash between modules & Group/user names
some of the MVP's on the right might disagree slightly but I doubt it

of course just because it is not the way I would do it does not make it wrong


Do things on the cheap & it will cost you dear

 

[sizbut]

It was never introduced, it was always there are a default behaviour. Which is part of the problem as it means there are no control around whether you want it or not and a lot of people are unaware it even exists even though their system may occasionally use the feature.

Stuck in a never ending cycle of file copying.

 

[budbyrd]

If you point an ICR to a VM module it will flag an informational error in the error pane suggesting naming the module with a group name. But, we never do. A system that it is hit or miss, with out rhyme or reason, whether it is going to route by name or number, or both, it is best to choose your fall back manually.

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'

 

[R3LzX]

Yes there is definitely a reason "they" are no longer there and "we" are now there. In addition to this they had win7 and winxp vmpro refurbished PC boxes with nic cards that were rejecting traffic resulting in congestion counts in the thousands. Once we spun up a virtual 2012 and created a VLAN on it, all was normal, and of course removed this reverse name match route to a module as well.


Thanks again for everyones responses.

 

[IPGuru]

Personal tip

If possible use Application sever in prefrence to a windows server (even on a VM).

its quicker to install (at least if you include installing IIS & all the necessary windows updates before you start)
It easier to install (if you include configureing IIS & SMTP services)
One-X is installed as standard & just needs initialising
Call Recorder is available

It's more robust ( especialy if you dont disable windows updates n a windows server)



Do things on the cheap & it will cost you dear

 

[intrigrant]

IP Office and VM Pro are a evolution of its predecessor Alchemy Argent Office with VM Pro.
That system did not had the option to create modules and the only way to access VM was using the <name>.leave start point and using the shortcode action VM Node to get there.

Still today you can access a particular start point using the name.leave or name.collect or whatever method is available through shortcode's, the default action has always been the .leave start point when the ".action" has left out, so a shortcode with only the name of a user or a group will always endup in the leave action of that user or group unless otherwise specified.

In VM Pro Manager you can create a VM box without creating a user in Manager and have the .collect and .leave actions availabble were you can create a call flow while there is no user assigned. Avaya calls that a "phantom mailbox" but you wont find a word about it in the documentation as they disencourage the use of this method.
And, as it is not documented Avaya has the freedom to change that way of working without notice so i hardly ever use it.

To go back on topic, follow the advise of the MPV's here and never use a action name similar to a group name and always keep the system name unique, instead use the ICR fallback option to route a call to a particular group. It will save you some headaches and keeps the customer happy.