August 15, 2019 at 1:17 pm #5487
First time posting here. Been a field tech and support engineer for various Mitel dealers and worked for Inter-Tel and Mitel directly as well for the last 19 years. I have experience working with the legacy equipment and technology such as loop start and ground start lines, BRI, ISDN, PBX systems like the SX50, SX200 and SX2000 but I also have extensive experience working with VoIP. I’ve been working on Mitel VoIP systems like the 200ICP and 3300ICP (MiVB), and Inter-Tel 5000 since they came on the scene. I am also pretty competent when it comes to how OS and applications work. I have a pretty good grasp on how machines in general operate and communicate internally sending and receiving instructions, how calls are processed, and clients request resources. So please don’t worry about going over my head. I am desperate to understand how BCA works and how it can fixed on our shoreTel connect system (Build 21.88.x). We have constant issues with BCA “locking up”. It seems the only fix is to either reboot the voice switch or move the BCA back and forth between two voice switches to force things to update. It’s been going on long before I came to the company, and based on google searches, seems to be a problem since ShoreTel implemented them.
The vendor, despite their best effort does not know how to fix this without having to go through the steps outlined above. I’d love to find out if there is away to clear the “Stuck” calls without rebooting and without having to jump through a bunch of programming trickery. It would be great if there was a way to force the call stack or switch to update things by logging into the Shell and issuing a command or two. Or by deleting a temp file, clearing a buffer, stopping and starting a service.
As best I can tell, it looks like the BCA depend on SIP messages between the phones and switch. And so Mitel seems to think they can skirt the issue by blaming everything on network delay. It isn’t really acceptable. In 19 years I’ve never encountered a customer network (Mitel included) who didn’t have delay or congestion or dropped connections at some point.
So blaming things on poor network performance is not cool at all. My response….fix your code!!!! I’ve never personally encountered an issue with Mitel or Inter-Tel systems where a call key is “stuck” due to dropped/delayed packets. I am sure someone could create a routine that would perform a refresh of the status every couple seconds. And until Mitel can fix this, I’d love if someone has a guaranteed workaround that takes only a minute or so to execute.
Side note, despite the headaches this has caused, I blame that issue mostly on ShoreTel. Seems they knew about this long before Mitel bought them. Unfortunately, Mitel is going to suffer the wrath of many upset customers if they don’t address it. As far as customers are concerned, this is a Mitel issue. Mitel themselves have always had a great product line. They were a great company to work for. So it’s unfortunate to see the lack of ownership surrounding this issue.August 18, 2019 at 2:48 pm #5493
I agree – as a long time ShoreTel/Mitel Partner Sales and Support Engineer, this feature has not been as stable and workable as the users in certain industries we support have needed it to work. Moving users to another switch (if available) or reboot the switch that hosts the users phone seem to be the only work around when lines get “stuck”.
>> Work Around = We have found that users on older model MGCP phone have less issues so we have admin assistants and bosses on IP655 or IP565/IP265 phone rather that new SIP based IP4xx model phones with less reports of stuck lines. Robert, please contact me to share notes – I’m based in Southern CA.
You must be logged in to reply to this topic.