secondary element has the * on the secondary controller

[joekske]

Hello All,

I have a question about the location of the * when you do a locate feature extension.
Situation:
- locate feature extension on primary controller has the * on primary element
- locate feature extension on secondary controller has the * on secondary element (see attach printscreen)
- according to the All IP Telephones form on the primary controller, the phone has an IP and is in service on the primary controller
- according to the All IP Telephones form on the secondary controller, the phone is out of service and doesn't have an IP.

Could the * on the secondary controller be the cause that the phone is not ringing when a call is offered to a ring group (ring all) on the the primary controller?
If so, is there a way without rebooting the secondary controller to get the * back on primary element?
I have asked this a few time at Mitel as well but the response was never on point.

Regards

Jo

[lundah]

HST STATUS_HANDOFF should tell you if there's any active resiliency in effect. Run it on both and compare.

You can also force the secondary to push all failed over sets back via the "hsPushback" shell command, but getting to the shell will be a bit different depending on your software version (VxWorks or MSL/uBoot). There's a few other commands as well, listed in the Online help under Maintenance -> Commands -> HandoffService Shell Commands

[joekske]

Hello,

I have tried all those commands, but they don't work. (And I have tried this at multiple customers)
For now I have feedback from the customer that phone is ringing again.
I have had an answer form the MIVB guy from Mitel NL in the past:
If you have a phone that is registered on the secondary controller and you call  the number, the * will move back to primary element.

I have done this, and this seems to work, but this is not a solution for all customers as not all customers have licenses on the secondary controller to make a phone.

Still strange that this * does not move with the IP address of the phone, it was clear that the phone was on the primary controller (again?)

Regards

Jo

[lundah]

Might want to double check the resiliency options in Controller Registry Assignment then to ensure Return to Primary is enabled and the timers match, because I've never had an issue with this that at the very least an "hsPushback" didn't fix.

[joekske]

Hello Lundah,

Thank you for your reply. I have again this issue but for an other customer, this time no lic on sec controller to do the same as last time.
I have checked the "return to primary" and the timers. Return to primary is set to yes en de timers are set the same.

Can you tell me on how to do the hsPushback command? I have seen in the help file, but it tells only on how to do it on pre version 9 version if I'm not mistaken.
Will the hsPushback command work as for me the phone is back at the primary controller except for the * that is wrong.

Regards

Jo

[lundah]

Hello Lundah,

Thank you for your reply. I have again this issue but for an other customer, this time no lic on sec controller to do the same as last time.
I have checked the "return to primary" and the timers. Return to primary is set to yes en de timers are set the same.

Can you tell me on how to do the hsPushback command? I have seen in the help file, but it tells only on how to do it on pre version 9 version if I'm not mistaken.
Will the hsPushback command work as for me the phone is back at the primary controller except for the * that is wrong.

Regards

Jo

To use the HandoffService shell commands, you have to enter the RTC shell. On MiVB 9.0 and later, that's done from an SSH session to the MiVB by entering "mcdDebug" from the SSH/Linux shell. Use Ctrl-C to exit the RTC shell. This is listed in the release notes.