External Users (EHDU) part of Multi-device groups not authorized to call in after group failing over

[danramirez]

Scenario is as follows:

MiVoice Business Express (8.0.2.202)
MiVB blade within MiVB Express is version 8.0 SP3 PR2 (14.0.3.37)

Above MiVB blade is clustered together with a CX Controller running same software load.

Both controllers (MiVBs) use a common MBG as SIP Proxy for connections to SIP Trunk Providers. In case of "primary" controller failure MBG sends incoming calls (arriving on SIP Trunks) to "secondary" controller.

IP Users and Multidevice Groups on primary controller, use the CX as secondary element for resiliency.

On the primary controller there are Personal Ring Groups which include EHDUs. These EHDUs use their mobile phones to dial into the DDI associated to the Hot Desking Access Number, they receive dial tone and they are allowed to contact any internal DN or even make outgoing calls using MiVB Resources.

If the primary controller fails and it's unavailable, Personal Ring Groups and all their members fail over to the CX.

After groups have failed over, if an EHDU memeber of a PRG dials into the DDI for Hotdesking Access, caller gets dial tone and he is allowed to access MiVB resources as when registered on the Primary.

Also, if I create a Multi-device group on the Primary controller, include an EHDU (Multidevice user license) as its only member and make this first and only member resilient, then the Multi-device group and the EHDU fail over to the CX and everything continues to work as expected, in a very similar way as the EHDU part of the PRG.

Up to here everything works as expected in case the primary controller is gone, i.e. Users and groups fail over, SIP Trunks, DDIs, and the MBG continues to do its job as a SIP Proxy.

Here is what it is not working as I expect:

If one user is added from the MiVoice Business Express using "Users and Services -> Quick Add and choosing UCCv4 Premium Role", that will create the user on the MiVB as a Multi-device user, and then the three members will be the Deskphone, the EHDU and a Softphone. Note I add a Secondary controller for both the deskphone and the EHDU to be the CX, this will automatically enable Resiliency for the Muti-device group.

If when Multi-device groups and members are on the primary controller, EHDUs can dial into the DDI for the External Hotdesking, then they get dial tone and access to all resources no problem whatsoever.

However, when the Multidevice group that has been created from the MiCollab fails over to the CX, EHDUs that dial into the DDI for external hotdesking number are not allowed to call in. Effect is similar to when calling a DDI that has nowhere to go on the MiVB.

CCS Trace gives a ;0; when terminating the call.

Why do everything work for PRG and manually created Multidevice Groups, but not for Multidevice groups created by te MiCollab??

Any idea how to make EHDUs fully resilient when created from MiCollab? I'm I missing anything?

Thank you, Regards,

Daniel

http://www.hatkanatelecom.com

 

[danramirez]

could the reason be that EHDU is not the prime DN therefore not the pilot number of the Multi-device Group?

those users created by MiCollab end up as follows on the MiVB:

Example:

Multidevice Group Pilot Number 7104

Members:

Prime DN 7104 (This is the Deskphone i.e. 6940)​

Other member 7*104 (This is the EHDU)​

Other member 71*04 (Softphone)​

http://www.hatkanatelecom.com

 

[danramirez]

I did the following test:

I have created a new template/role from MiCollab where EHDU is the primary number, then secondary is the deskpone and the other prone is the softphone.

I switched off the primary controller, both the Multidevice Group, desk phone and EHDU failed over to the secondary and now my EHDU is working fine when dialing the DDI associated with external hordesking.

I have raised a ticket with UK Support I'd like to hear their comments on this.

Have you seen anywhere on the help online that EHDUs part of Multi-device Groups have to be the prime member in order for EHDU resiliency to work correctly?

cheers,

daniel

http://www.hatkanatelecom.com

 

[danramirez]

ok, here is the cause of the problem:

This is a cluster which all CEID Digits are 4 digits long, i.e 7981, another member 7982 and so on.

Also, this cluster has got extensions of 4 digits each, i.e. 1001, or 2001, etc.

So ARS entries look something like this: ARS Digits dialled 7981 + 4 digits to follow, route .....


MiCollab creates MDUG where first member is 4 digits long, i.e 1001.
then second member is the EHDU which is assigned DN 1*001 (this is now 5 digits long)
third member is the soft phone 10*01 (again 5 digits long)

when EHDU fails over it cannot contact the DDI associated with external hotdesking access number and CCS Trace shows CRM ;0;

as it the 3300 did not what to do with that incoming call.

I changed digits to follow to UNK for the entries where the leading digits are the CEID digits.

I tested it and it works! and it looks that having UNK as the digits to follow does not add any delay when calling remote users across the cluster.

So my advise to myself is to set the digit to follow to unknown if on the other side you have variable lengths of DN

By the way, Mitel tested it and they couldn't reproduce my issue, either they were using DNs of a fixed length or they had their ARS digits to follow set to unknown.

cheers,

Daniel

http://www.hatkanatelecom.com